0% encontró este documento útil (0 votos)
25 vistas6 páginas

Fases del Desarrollo de Software y Modelo V

Cargado por

Emerson Rivera
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
25 vistas6 páginas

Fases del Desarrollo de Software y Modelo V

Cargado por

Emerson Rivera
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Emerson Rivera

2009-24451
SQM
Tarea 1

Fases de Vida de desarrollo de Software

Fase de Identificación de Problemas, oportunidades y objetivo


El analista se involucra en la identificación de los problemas, de las oportunidades y objetivos. Esta
fase es crucial para el proyecto, pues nadie está dispuesto a desperdiciar su tiempo dedicándolo al
problema equivocado. Este proceso lo hace el analista o la misma empresa contratante.

Captura, análisis y especificación de requisitos


Al inicio de un desarrollo, esta es la primera fase que se realiza, y, según el modelo de proceso
adoptado, puede casi terminar para pasar a la próxima etapa (caso de Modelo Cascada
Realimentado) o puede hacerse parcialmente para luego retomarla (caso Modelo Iterativo
Incremental u otros de carácter evolutivo). Durante esta fase, se adquieren, reúnen y especifican
las características funcionales y no funcionales que deberá cumplir el futuro programa o sistema a
desarrollar.

Fases de Análisis
En esta etapa se debe entender y comprender de forma detallada cual es la problemática a
resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se
obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es
conocida como la del QUÉ se va a solucionar.
Fase de Diseño
Una vez que se tiene la suficiente información del problema a solucionar, es importante
determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo
el CÓMO se va a solucionar. Se basa en la especificación de requisitos producido por el análisis de
los requerimientos (fase de análisis), el diseño define cómo estos requisitos se cumplirán

Fase de Codificación del software


Durante esta etapa se realizan las tareas que comúnmente se conocen como programación; que
consiste, esencialmente, en llevar a código fuente, en el lenguaje de programación elegido, todo lo
diseñado en la fase anterior.

Fase de Pruebas (unitarias y de integración)


Los errores humanos dentro de la programación de los computadores son muchos y aumentan
considerablemente con la complejidad del problema. Cuando se termina de escribir un programa
de computador, es necesario realizar las debidas pruebas que garanticen el correcto
funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se
pueda enfrentar.

Fase de Instalación y paso a producción


La instalación del Software es el proceso por el cual los programas desarrollados son transferidos
apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello
con el propósito de ser ya utilizados por el usuario final. Constituye la etapa final en el desarrollo
propiamente dicho del software. Luego de ésta el producto entrará en la fase de funcionamiento y
producción, para el que fuera diseñado.

Fase de Mantenimiento
El mantenimiento de Software es el proceso de control, mejora y optimización del software ya
desarrollado e instalado, que también incluye depuración de errores y defectos que puedan
haberse filtrado de la fase de pruebas de control y beta test. Esta fase es la última (antes de iterar,
según el modelo empleado) que se aplica al ciclo de vida del desarrollo de software. La fase de
mantenimiento es la que viene después de que el software está operativo y en producción.

Modelo V
Es una representación gráfica del ciclo de vida del desarrollo de sistemas. En él se resumen las
principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el
marco del sistema informático de validación.
Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un
proyecto. Se describen las actividades y resultados que deben producirse durante el desarrollo del
producto. El lado izquierdo de la V representa la descomposición de las necesidades, y la creación
de las especificaciones del sistema. El lado derecho de la V representa la integración de las piezas y
su verificación. V significa «Verificación y validación». Es muy similar al modelo de la cascada
clásico ya que es muy rígido y contiene una gran cantidad de iteraciones.
Objetivos
El Método-V fue desarrollado para regular el proceso de desarrollo de software por la
Administración Federal Alemana. Describe las actividades y los resultados que se producen
durante el desarrollo del software.
Proporciona una guía para la planificación y realización de proyectos.
Los siguientes objetivos están destinados a ser alcanzados durante la ejecución del proyecto:

Minimización de los riesgos del proyecto


Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques
estandarizados, describe los resultados correspondientes y funciones de responsabilidad. Permite
una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos,
reduciendo así los riesgos del proyecto.

Mejora y Garantía de Calidad


Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean
completos y contengan la calidad deseada. Los resultados provisionales definidos se puede
comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la
legibilidad, comprensibilidad y verificabilidad.

Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida
El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser
calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de
procesos estandarizados. Reduciendo la dependencia en los proveedores y el esfuerzo para las
siguientes actividades y proyectos.

Mejora de la comunicación entre todos los inversionistas


La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base
para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por
fricción entre el usuario, comprador, proveedor y desarrollador.
La corriente de especificación (parte izquierda, Project definition) consiste principalmente
de:

 Conceptos de operaciones: que debe hacer el sistema a grandes rasgos.


 Requisitos del sistema y arquitectura del mismo.
 Diseño detallado.
La corriente de pruebas (parte derecha, Project test and integration), por su parte, suele
consistir de:

 Integración de las distintas partes, prueba y verificación de las mismas.


 Verificación y validación del sistema en conjunto.
 Mantenimiento del sistema.
La corriente de desarrollo puede consistir (depende del tipo de sistema y del alcance del
desarrollo) en personalización, configuración o codificación.

Diferencias:
 Modelo V realiza un análisis de Riesgos
 Modelo V maneja Costos
 Cascada es de una sola pasada
 Modelo V son iteraciones

Diferencia entre Verificación y Validación

• Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el


producto satisface los requerimientos del usuario

• Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que


el producto conforma su especificación inicial.

En la Validación el resultado final del desarrollo software se debe ajustar a lo que el


usuario quería (sus necesidades)? En la mayoría de las ocasiones el producto desarrollado
no casa con la ideas del cliente, normalmente porque a éste suele faltarle capacidad
técnica de expresión.
En la Verificación el código que estamos construyendo debe estar en armonía con la
especificación que hemos tomado del usuario. El resultado final del desarrollo software
debe concordar con la especificación (requisitos) del sistema, por lo que debemos
asegurarnos que el desarrollo final coincida con dicha especificación.

Principios Generales de Prueba

Principios de la actividad de la prueba


a) Principio de libertad de prueba. Para alcanzar la verdad concreta no se requiere la
utilización de un medio de prueba determinado. Todos los medios de prueba son
admisibles, es decir, se puede probar con los medios de prueba típicos como también con
aquellos que no han sido contemplados en la ley (atípicos) siempre y cuando no recaigan
en la ilicitud.
b) Principio de pertinencia En virtud del cual debe existir relación entre el hecho o
circunstancia que se quiere acreditar con el elemento de prueba que se pretende utilizar.
c) Principio de conducencia y utilidad. Se refiere este principio a la relevancia que
tienen los hechos probados, si estos van a ser útiles para resolver el caso en particular.
Una razón de inutilidad de la prueba es la superabundancia, es decir, cantidad excesiva de
elementos de prueba referidos al mismo hecho.
d) Principio de legitimidad. Tiene que ver con alguna prohibición o impedimento que
expresamente declare el ordenamiento jurídico, procesal, respecto a un medio de prueba.
Están prohibidos aquellos medios de prueba que van contra la dignidad o integridad de las
personas, o que se hubieren obtenido por medios ilícitos o que violente de alguna manera
los derechos de alguna de las partes.

Beneficios de Herramientas CASE

1. Facilidad para la revisión de aplicaciones


La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por
mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para
las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza
el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para
los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a
modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.

2. Soporte para el desarrollo de prototipos de sistemas


En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se
desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y
composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con
rapidez para alterar la presentación y las características de la interface. Sin embargo, no se
prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del
prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las
características de entrada y salida son desarrolladas junto con el código orientado hacia los
procedimientos y archivos de datos.

3. Generación de código
La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar
un programa. Sin embargo, la generación del código también asegura una estructura estándar y
consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la
ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de
la generación del código permiten volver a utilizar el software y las estructuras estándares para
generar dicho código, así como el cambio de una especificación modular, lo que significa volver a
generar el código y los enlaces con otros módulos.

4. Mejora en la habilidad para satisfacer los requerimientos del usuario


Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda
relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la
calidad de las prácticas de desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo,
una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y
cantidad de interacción entre los encargados del desarrollo y el usuario. Las
descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las
pantallas, contribuyen a un intercambio de ideas más efectivo.

5. Soporte interactivo para el proceso de desarrollo


La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las
herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas,
elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y
revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.

También podría gustarte