2. UNIDAD 4
MODELOS DE PROCESOS DE SOFTWARE
Este enfoque metodológico que ordena rigurosamente las etapas del
ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a
la finalización de la inmediatamente anterior. la palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para
introducir un cambio en las fases más avanzadas de un proyecto.
Modelo en Cascada: El mas conocido, esta basado en el ciclo
convencional de una ingeniería, el paradigma del ciclo de vida abarca las
siguientes actividades:
- Ingeniería y Análisis del Sistema
- Análisis de los Requisitos
- Diseño
- Codificación
- Prueba
- Mantenimiento
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA
Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algún subconjunto de estos requisitos al software.
2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN
Se lleva a cabo teniendo den cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de un
problema.
- Defina las funciones que debe realizar el Software.
- Represente el comportamiento del Software a consecuencias de
acontecimientos externos.
3. - Divida en forma jerárquica los modelos que representa la información,
funciones y comportamiento.
Se analizan las necesidades de los usuarios finales del Software para
determinar que objetivos debe cubrir.
3.- DISEÑO
Traduce los requisitos en una representación del Software con la calidad
requerida antes de que comience la codificación.
- Diseño del sistema: Se descompone y organiza el sistema en elementos
que pueda elaborarse por separado, aprovechando los ventajas del desarrollo en
equipo, así como la manera en que se combinan unos con otros.
- Diseño del Programa: Es la fase en donde se realizan los algoritmos
necesarios para el cumplimiento de los requerimientos del usuario así como
también los análisis necesarios para saber que herramientas usar en la etapa de
Codificación.
4.- CODIFICACIÓN
El diseño debe traducirse en una forma legible para la maquina. Se
implementa el código fuente. Dependiendo del lenguaje de programación y su
versión se crean las librerías y componentes reutilizables dentro del mismo
proyecto para hacer que la programación sea un proceso mucha más rápido.
5.- PRUEBA
Los elementos, ya programados, se ensamblan para componer el sistema
y se comprueba que funciona correctamente antes de ser puesto en explotación.
Las pruebas de Software, testing o beta testing es un proceso usado para
identificar posibles fallos. En general, los usuarios distinguen entre errores de
programación ( o “bugs” ) y defectos de forma. en un defecto de forma, el
programa no realiza lo que el usuario espera. Por el contrario, un error de
programación puede describirse como un fallo en la semántica de un programa
de ordenador. A la versión del producto de pruebas y que es anterior a la versión
final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing.
Finalmente y antes de salir al mercado, es cada vez más habitual que se realice
una fase de RTM testing (Release To Marquet), dónde se comprueba cada
funcionalidad del programa completo en entornos de producción.
4. 6.- IMPLANTACIÓN
El Software obtenido se pone en producción. Se implantan los niveles
Software y Hardware que componen el proyecto. La implantación es la fase con
más duración y con más cambios en el ciclo de elaboración de un proyecto. Es
una de las fases finales del proyecto. Durante la explotación del sistema
Software pueden surgir cambios, bien para corregir errores o bien para
introducir mejorar. Todo ello recoge en los Documentos de Cambios.
7.- MANTENIMIENTO
El Software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debido a que hayan encontrado errores, a que el Software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
Ventajas:
- Se tiene todo bien organizado y no se mezclan las fases.
- Es perfecto para proyectos que son rigidos.
- Idieal para proyectos donde se especifiquen muy bien los
requerimientos.
- Ideal para proyectos en que se conozca muy bien la herramienta a
utilizar.
- Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la
hora de desarrollar el Software.
Desventajas:
- Difícilmente un cliente va a establecer al principio todos los
requerimientos necesaríos, por lo que provoca un gran atraso trabajando en este
modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
- Los resultados y/o mejoras no son visibles, el producto se ve recién
cuando este esté finalizado.
5. 4.2 MODELOS DE ESPIRAL
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por
Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software.
Las actividades de este modelo son una espiral, cada bucle es una
actividad.
Para cada actividad habrá cuatro tareas:
No. 1
Planificación:
Determinación de objetivos, alternativas y restricciones.
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si
continuamos con las fases siguientes y planificamos la próxima actividad.
No. 2
Análisis de riesgo:
Análisis de alternativas e identificación/resolución de riesgos.
No. 3
Ingeniería:
Desarrollo del producto del “siguiente nivel”
Tareas de la actividad propia y se prueba.
Análisis de alternativas e identificación resolución de riesgos.
No.4
Evaluación del cliente:
Valorización de los resultados de la ingeniería.
Ventajas:
6. - El análisis del riesgo se hace de forma explícita y clara. Une los mejores
elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento, etc.
- Además es posible tener en cuenta mejoras y nuevos requerimientos sin
romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas:
- Genera mucho tiempo en el desarrollo del sistema.
- Modelo costoso.
- Requiere experiencia en la identificación de riesgos.
CONCLUCION:
El paradigma del modelo en espiral para la ingeniería de software es
actualmente el enfoque más realista para el desarrollo de software y de sistemas
a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en
cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de
reducción de riesgo, pero, lo que es más importante permite a quien lo
desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la
evolución de prototipos.
4.3 MODELOS INCREMENTAL
El Modelo Incremental combina elementos del MLS con la filosofía
interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño,
Código y Prueba. Sin embargo, para la producción del Software, se usa el
principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de
programación. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte
7. mejor a sus necesidades reales. El proceso se repite hasta que se elabore el
producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de
naturaleza interactiva pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con
una dotación de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se añadir• personal, de ser
necesario. Por otro lado los incrementos se pueden planear para gestionar
riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con
cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir
transformando un flujo de datos en un proceso comprendido por varias fases
secuenciales, siendo la entrada de cada una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el
intérprete de comandos, ya que se pueden concatenar comandos fácilmente con
tuberías (pipe).
8. También es una arquitectura muy natural en el paradigma de
programación funcional, ya que equivale a la composición de funciones
matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de
mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con
cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial,
ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite entregar al cliente un producto más rápido en comparación del
modelo de cascada.
9. - Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de
alto índice de riesgos.
- Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.
Conclusión:
Un modelo incremental lleva a pensar en un desarrollo modular, con
entregas parciales del producto Software denominados “incrementos” del
sistema, que son escogidos en base a prioridades predefinidas de algún modo.
El modelo permite una implementación con refinanciamientos sucesivos
(ampliación y/o mejora).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos
requisitos o bien se mejora la versión previamente implementada del producto
software.
4.4 PROCESO DE DESARROLLO UNIFICADO
El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo software iterativo e incremental. El
refinamiento más conocido y documentado del Proceso Unificado es el Proceso
Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de
trabajo extensible que puede ser adaptado a organizaciones o proyectos
específicos. De la misma forma, el Proceso Unificado de Rational, también es un
marco de trabajo extensible, por lo que muchas veces resulta imposible decir si
un refinamiento particular del proceso ha sido derivado del Proceso Unificado o
del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
10. Características:
- Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental
compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y
Transición. Cada una de estas fases es a su vez dividida en una serie de
iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes).
Estas iteraciones ofrecen como resultado un incremento del producto
desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.
- Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los
requisitos funcionales y para definir los contenidos de las iteraciones.
- Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra
todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y
vistas que definen la arquitectura de software de un sistema
- Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en
identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los
resultados de cada iteración, en especial los de la fase de Elaboración, deben ser
seleccionados en un orden que asegure que los riesgos principales son
considerados primero.
4.5 PROCESO DE SOFTWARE PERSONAL
El Proceso Personal Software, conocido por sus siglas como PSP, es una
metodología de reciente creación, proveniente del Instituto de Ingeniería del
Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que
les permite mejorar la forma en la que construyen software. Considerando
aspectos como la planeación, calidad, estimación de costos y productividad, PSP
es una metodología que vale la pena revisar cuando el ingeniero de software está
interesado en aumentar la calidad de los productos de software que desarrolla
dentro de un contexto de trabajo individual.
11. Atendiendo a la premisa de que existe una fuerte relación entre las
habilidades de los ingenieros de software y la calidad de los productos que
desarrollan, las actividades establecidas en PSP están orientadas al
conocimiento, administración y mejora de sus habilidades al construir
programas.
En PSP todas las tareas y actividades que el ingeniero de software debe
realizar durante el proceso de desarrollo de un producto de software, están
puntualmente definidas en un conjunto de documentos conocidos como scripts.
Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en
que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los
scripts generará en su realización un conjunto de datos, fundamentalmente de
carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el
análisis de la información estadística generada en cada uno de éstos, permitirán
al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de autoaprendizaje y auto-mejora.
Los scripts se organizan en cuatro niveles, identificados del 0 al 3,
atendiéndose en cada nivel un conjunto de aspectos a mejorar del proceso de
desarrollo de software. Al primer nivel se le conoce como 0 o de medición
personal, al segundo como nivel 1 o de planeación personal, al tercero, como
nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada
uno de estos niveles, con excepción del 3, tiene una versión que los extiende,
introduciendo tareas y actividades para un mejor manejo de los aspectos de
interés en nivel, o bien para incluir nuevos aspectos.
