Mantenimiento de software GUION

Fase de requisitos: Etapa en que consiste en la extracción y obtención de

requisitos del sistema o producto SW que se desea desarrollar por medio de
consultas mediante los stakeholders para que de esta manera se puedan
especificar las características operacionales del software (función, datos y
rendimientos), indicar la interfaz del software con otros elementos del sistema y
establecer las restricciones que debe cumplir el software.
Fase de diseño: El diseño de software es un proceso para transformar los
requisitos del usuario en una forma adecuada. En esta etapa en general se refiere
al establecimiento de las estructuras de datos, la arquitectura general de software,
representaciones de interfaz, algoritmos y diagramas.
Fase de codificación: 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 que se realizó en la fase
de diseño.
Fase de pruebas: Una vez que se haya generado código, comienzan las pruebas
de software o sistema que se ha desarrollado. El proceso de pruebas se centra en
los procesos lógicos internos del software, asegurando que todas las sentencias
se han comprobado, y en los procesos externos funcionales, es decir, la
realización de las pruebas para la detección de errores.
Fase de mantenimiento: El Mantenimiento de software es el proceso de modificar
un producto de software después de que se haya entregado al cliente. El objetivo
principal del mantenimiento del software es modificar y actualizar la aplicación de
software después de la entrega para corregir fallas y mejorar el rendimiento.
Propósitos de la fase de mantenimiento
Corregir errores: Nuestro programa nunca será perfecto incluso aunque haya
pasado correctamente por la fase de pruebas, siempre tarde o temprano se
encontrarán errores no detectados antes, y su propósito siempre será la constante
identificación y corrección de los mismos.
Mejorar el diseño: Consiste en el mejoramiento ya sea de la interfaz gráfica para
facilitar su uso del mismo o mejorar ciertas estructuras internas del programa
como refactorización para hacer mejorar el entendimiento para otros mas futuros
cambios.
Agregar nuevas características o funciones: Consiste en agregar funciones o
características al programa desarrollado que no existían anteriormente, esto ayuda
a mantener el programa mas activo y atraer a más audiencias.
Adaptarlo a nuevos sistemas y componentes: Consiste en adaptar el software a
nuevos entornos de hardware diferentes o a nuevos sistemas operativos para
aumentar su portabilidad, distribución y accesibilidad.
Tipos de mantenimiento
Mantenimiento preventivo:
Este tipo de mantenimiento incluye modificaciones y actualizaciones para evitar
futuros problemas del software. Su objetivo es atender problemas que no son
significativos en este momento pero que pueden causar serios problemas en el
futuro.
Mantenimiento correctivo:
El mantenimiento correctivo de un producto de software puede ser esencial para
corregir algunos errores observados mientras el sistema está en uso o para
mejorar el rendimiento del sistema.
Mantenimiento adaptativo:
Esto incluye modificaciones y actualizaciones cuando los clientes necesitan que el
producto se ejecute en nuevas plataformas, en nuevos sistemas operativos, o
cuando necesitan que el producto interactúe con nuevo hardware y software.
Mantenimiento perfecto:
Un producto de software necesita mantenimiento para admitir las nuevas
características que los usuarios desean o para cambiar los diferentes tipos de
funcionalidades del sistema de acuerdo con las demandas del cliente.

Modelo iterativo
En cada ciclo, iteración, se revisa y mejora el producto. Un ejemplo de desarrollo
iterativo es aquel basado en refactorizaciones (te dejo el post de introducción a la
refactorización), en el que cada ciclo mejora más la calidad del producto.
Es importante señalar que este ciclo no implica añadir funcionalidades en el
producto, pero si la revisión y la mejora.
Ventajas
Una de las principales ventajas que ofrece este modelo es que no hace falta que los
requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir
refinando en cada una de las iteraciones.
Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo
en pequeños ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las
entregas.
Inconvenientes
La primera de las ventajas que ofrece este modelo, el no ser necesario tener los
requisitos definidos desde el principio, puede verse también como un inconveniente
ya que pueden surgir problemas relacionados con la arquitectura.
Modelo espiral
Características
La fuerza impulsora más importante del desarrollo en espiral es el análisis y la
evaluación de riesgos. Cualquier riesgo que amenace el proyecto debe ser
identificado desde el principio. El progreso del proyecto depende decisivamente de
cómo se puedan eliminar los riesgos. El proyecto se considera exitoso sólo
cuando no hay riesgos. El objetivo del ciclo es producir un producto en continua
mejora. El software o la aplicación se perfecciona constantemente. El modelo en
espiral es incremental, pero no necesariamente repetitivo. Las repeticiones
ocurren sólo cuando los riesgos, errores o conflictos amenazan el proyecto.
Entonces el producto tiene que pasar por un ciclo de nuevo, llamado una iteración
o repetición.
- Contiene una nueva etapa que es el análisis de riesgos, no incluida
anteriormente.
- Este modelo es el indicado para desarrollar software con diferentes
versiones actualizadas como se hace con los programas modernos de
PC´s.
- La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de
construcción de prototipos
- Consiste en más en agregación de características del sistema.
Ventajas y desventajas
El modelo de desarrollo en espiral se utiliza a menudo para proyectos más
grandes que están sujetos a riesgos. Dado que estos riesgos tienen un impacto
monetario directo, el control de los presupuestos de los clientes y de las empresas
promotoras es fundamental. El modelo en espiral se utiliza especialmente en los
nuevos entornos técnicos, ya que éstos suponen un riesgo.[2]
Los conflictos entre los requisitos de un software y su diseño se evitan
eficazmente mediante el enfoque cíclico, ya que los requisitos pueden
comprobarse constantemente y, si es necesario, modificarse.[3]
Se puede obtener feedback de los usuarios, desarrolladores y clientes en las
primeras fases del proyecto. Sin embargo, esta estructura también requiere una
gestión que tenga en cuenta los ciclos del producto y pueda responder
rápidamente a los riesgos. El control de tales proyectos es, por lo tanto,
relativamente complejo y también requiere una buena documentación para que se
registren todos los cambios.
Aunque el software se prueba bajo varios aspectos durante el ciclo de desarrollo y
prueba (unidad, prueba de aceptación e integración), a menudo sucede que los
prototipos se transfieren al sistema de producción. Por lo tanto, existe el riesgo de
que se introduzcan otros errores e incoherencias conceptuales en el producto final
posterior.
En los lugares donde se toman decisiones sobre los ciclos siguientes, existe el
riesgo de que se formen bucles y el proyecto tarde más tiempo si se toman
decisiones equivocadas. Por esta razón, las alternativas y su evaluación son
importantes.
Modelo V
Características
- Minimización de los riesgos del proyecto
- Mejora y Garantía de Calidad
- Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo
de Vida
En los 4 niveles lógicos comenzando desde el 1, para cada fase del desarrollo,
existe una fase correspondiente o paralela de verificación o validación.
Esta estructura obedece que desde el principio para cada fase del desarrollo debe
existir un resultado verificable.
En la misma estructura se advierte también que la proximidad entre una fase del
desarrollo y su fase de verificación correspondiente va decreciendo a medida que
aumenta el nivel dentro de la V, es decir de arriba hacia abajo en donde se
localiza la punta. La longitud de esta separación intenta ser proporcional a la
distancia en el tiempo entre una fase y su homóloga de verificación.
NIVEL 1 está orientado al cliente. El inicio del proyecto y el fin del proyecto
constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y
especificaciones, se traduce en un documento de requisitos y especificaciones.
NIVEL 2 se dedica a las características funcionales del sistema propuesto. Puede
considerarse el sistema como una caja negra, y caracterizarla únicamente con
aquellas funciones que son directa o indirectamente visibles por el usuario final, se
traduce en un documento de análisis funcional.
NIVEL 3 define los componentes hardware y software del sistema final, a cuyo
conjunto se denomina arquitectura del sistema.
NIVEL 4 es la fase de implementación, en la que se desarrollan los elementos
unitarios o módulos del programa.