El Proceso

Objetivos
 Describir las capas de la Ingeniería del
Software
 Definir el proceso del software
 Describir los modelos de ciclo de vida
para el proceso del software

2
Overview
 Proceso de software
como un marco de
trabajo de las tareas
que se requieren para
construir software de
alta calidad

3
IS: Tecnología Estratificada 1/9
 Proceso, Métodos y Herramientas
 Tecnología multicapa

tools
methods
process model
a “quality” focus

4
IS: Tecnología Estratificada 2/9
 Capa de proceso
 Fundamento de la IS
 Mantiene unidas las capas de tecnología
 Permite desarrollo racional y oportuno
 Define un marco de trabajo
 Base del control de gestión de proyectos
 Establece el contexto
 En que se aplican los métodos técnicos
 Se obtienen los productos del trabajo
 Se establecen hitos
 Se asegura la calidad
 El cambio se gestiona adecuadamente

5
IS: Tecnología Estratificada 3/9
 Los métodos
 Indican “como” construir técnicamente el software
 Incluyen una gran gama de tareas
 Análisis de requisitos
 Diseño
 Construcción de programas
 Pruebas
 Mantenimiento
 Dependen de un conjunto de principios básicos que
gobiernan cada área de la tecnología
 Actividades de modelado y técnicas descriptivas

6
IS: Tecnología Estratificada 4/9
 Las herramientas
 Proporcionan un enfoque automático o semi-
automático para el proceso y los métodos
 Ingeniería del Software Asistida por
Computadora (CASE)

7
IS: Tecnología Estratificada 5/9
 Una visión general de la IS
 IS es el análisis, diseño, construcción, verificación y gestión de
entidades técnicas
 Debe cuestionar y responder las siguientes preguntas:
 ¿Cuál es el problema a resolver?
 ¿Cuáles son las características de la entidad que se utiliza para
resolver el problema?
 ¿Cómo se realizará la entidad (y la solución)?
 ¿Cómo se construirá la entidad?
 ¿Qué enfoque se va a utilizar para no contemplar los errores que se
cometieron en el diseño y en la construcción de la entidad?
 ¿Cómo se apoyará la entidad cuando usuarios soliciten
correcciones, adaptaciones y mejoras de la entidad?

8
IS: Tecnología Estratificada 6/9
 El trabajo asociado a la IS se puede dividir
en tres fases genéricas
 Independientes del área de aplicación,
tamaño o complejidad del proyecto
 Relacionadas con una o varias de las
cuestiones mencionadas anteriormente

9
IS: Tecnología Estratificada 7/9
 Fase de definición
 Se centra sobre el ¿Qué?
 Intentar identificar los requisitos clave
 Qué información debe ser procesada
 Qué función y rendimiento se desea
 Qué comportamiento del sistema
 Qué interfaces se establecerán
 Qué criterios de validación se necesitan
 Los métodos aplicados varían dependiendo del paradigma
aplicado
 Tres tareas principales
 Ingeniería de información o de sistemas
 Planificación del proyecto de software
 Análisis de requisitos

10
IS: Tecnología Estratificada 8/9
 Fase de desarrollo
 Se centra en el ¿Cómo?
 Intenta definir
 Cómo han de diseñarse las estructuras de datos
 Cómo ha de implementarse la funcionalidad dentro de la arquitectura de
software
 Cómo han de implementarse los detalles procedimentales
 Cómo se caracterizarán las interfaces
 Cómo ha de traducirse el diseño en un lenguaje de programación
 Cómo ha de realizarse la prueba
 Los métodos aplicados varían
 Tareas principales
 Diseño del software
 Generación de código
 Prueba del software

11
IS: Tecnología Estratificada 9/9
 Fase de mantenimiento
 Se centra en el cambio asociado a
 La corrección de errores
 Adaptaciones requeridas a medida que evoluciona el entorno
 Cambios debido a las mejoras producidas por los requisitos
cambiantes del cliente
 Cuatro tipos de cambios
 Corrección: corregir defectos
 Adaptación: acomodarlo a su entorno
 Mejora: más allá de los requisitos funcionales originales
 Prevención: con la finalidad de corregir, adaptar y mejorar más
fácilmente (reingeniería del software)
 Asistentes técnicos a distancia, teléfonos de ayuda y sitios Web

12
El Proceso del Software 1/6
 Marco común del proceso
 Actividades del marco de trabajo
 Aplicablesa todos los proyectos de software
 Independiente del tamaño o complejidad
 Conjunto de tareas de IS
 Actividades de protección

13
El Proceso del Software 2/6

14
El Proceso del Software 3/6
 Nivel de “madurez del proceso”
 SEI Cannegie Mellon University
 Cinco grados  conformidad con un
modelo de madurez en la capacidad de
desarrollo de software (CMM)
 Proporciona un medida de la efectividad
global de las prácticas de IS de una
compañía

15
El Proceso del Software 4/6
 Nivel 1: Inicial
 Según el caso
 Caótico
 Pocos procesos definidos
 Éxito depende del esfuerzo individual
 Nivel 2: Repetible
 Establece procesos de
 Gestión del proyecto para seguimiento del coste
 Planificación
 Funcionalidad
 Repetir éxitos anteriores con aplicaciones similares
 Disciplina necesaria para el proceso

16
El Proceso del Software 5/6
 Nivel 3: Definido
 Se documentan los procesos de gestión e ingeniería
 Se estandariza e integra un proceso para toda la
organización
 Todos los proyectos utilizan una versión
documentada y aprobada del proceso
 Desarrollo
 Mantenimiento
 Incluye características del nivel 2.

17
El Proceso del Software 6/6
 Nivel 4: Gestionado
 Se recopilan medidas detalladas
 Del proceso del software
 De la calidad del producto
 Se comprenden y controlan cuantitativamente los productos y el
proceso del software  medidas detalladas
 Incluye todas las características del nivel 3
 Nivel 5: Optimización
 Retroalimentación cuantitativa del proceso, ideas y tecnologías
innovadoras
 Incluye las características del nivel 4

18
Trabajo de investigación grupal
 Documentar de manera más detallada
cada uno de los cinco niveles del CMM
 Buscar empresas de desarrollo que se
encuentran en cada uno de los niveles
 Exposición grupal

19
El Ciclo de Vida (CV) 1/5
 También llamado modelo de proceso del software o paradigma de
ingeniería del software
 Un modelo del ciclo de vida es un modelo prescriptivo de lo que
pasaría entre la “primera chispa” y el “último aliento”.
 Sirve para establecer el orden en que se especifica, se realizan los
prototipos, se diseña, implementa, revisa, prueba y se realizan otras
actividades en un proyecto.
 Establece los criterios que se utilizan para determinar el paso de
una actividad a otra.
 El modelo de ciclo de vida apropiado puede orientar su proyecto y
ayudarle a asegurar que cada paso lo acerque mas a la
consecución del objetivo.

20
El Ciclo de Vida (CV) 2/5
 Del modelo de ciclo de vida que seleccione dependerá:
 Aumentar la velocidad de desarrollo.
 Mejorar la calidad, el control y el seguimiento.
 Minimizar gastos y riesgos.
 Mejorar las relaciones con los clientes.
 Existen varios modelos de ciclo de vida disponibles.
 Una alternativa que a veces se pasa por alto es la
opción de comprar software comercial disponible.
Aunque raramente va a satisfacer sus necesidades,
debe considerarse que:
 Está disponible inmediatamente para “cubrir” necesidades.
 Podría ser adaptado.
21
El Ciclo de Vida (CV) 3/5
 Se selecciona según la naturaleza del
proyecto y de la aplicación, los métodos, y
las herramientas a utilizar, y los controles
y entregas que se requieren
 “Frecuentemente, el trabajo del software
sigue la primera ley del ciclismo: no
importa a donde vayas, ya sea a la
montaña y contra el viento”

22
El Ciclo de Vida (CV) 4/5
 Según Raccoon es un bucle de resolución
de problemas

23
El Ciclo de Vida (CV) 5/5
 En realidad existen interferencias entre las
etapas

24
Conceptos Básicos 1/3
 ¿Qué es un Requerimiento?
 “Unacondición o capacidad la cual el sistema
debe satisfacer”

25
Conceptos Básicos 2/3
 Requerimientos Funcionales
 Están íntimamente relacionados con los procesos de
negocios de la empresa
 Pensar en lo que el sistema debe hacer a favor de los
usuarios
 Son las acciones que el sistema debe ser capaz de
ejecutar
 Expresar el comportamiento del sistema en función
de las entradas y salidas que deben tener los
resultados esperados

26
Conceptos Básicos 3/3
 Requerimientos No Funcionales
 Son características que el sistema debe tener, principalmente
relacionados con la calidad
 También son todas las características que debe tener el sistema
pero que no forman parte de los requerimientos funcionales
 Podrían ser requisitos de:
 Utilización: estética, facilidad de uso, doc. Usuario, etc.
 Fiabilidad: tolerancia a fallas, recuperación, precisión, predecible
 Performance: transacciones, velocidad, disponib, precisión, tiempo
de respuesta, tiempo de recuperación, cant. memoria
 Soporte: pruebas, mantenimiento, actualización de versiones

27
CV Cascada Pura 1/4
 Padre de todos los modelos de ciclo de vida.
 Un proyecto progresa a través de una secuencia ordenada de
pasos partiendo del concepto inicial del software hasta la
prueba.
 Al final de cada etapa se realiza una revisión para determinar
si se está preparado para pasar a la siguiente etapa.
 Es dirigido por documentos que pasan de una etapa a otra.
 Las etapas son discontinuas, no se solapan.
 También llamado lineal secuencial

28
CV Cascada Pura 2/4

29
CV Cascada Pura 3/4
 Ventajas:
 Se utiliza adecuadamente para ciclos de productos en los que
se tiene una definición estable del producto y cuando se trabaja
con metodologías conocidas.
 Si se está construyendo una versión de mantenimiento (nueva
versión de un programa existente) bien definida de un producto
existente o migrando un producto existente a una nueva
plataforma, puede ser la elección correcta.
 Funciona bien con proyectos complejos pero que se entienden
bien, cuando los requerimientos de calidad dominan sobre los
de costos y planificación, o cuando se dispone de personal poco
calificado o inexperto.

30
CV Cascada Pura 4/4
 Desventajas:
 Dificultad para especificar claramente los requerimientos al
comienzo del proyecto.
 Olvidar una especificación puede suponer un error costoso. Los
errores no se perciben hasta que se prueba el sistema.
 No es flexible para realizar cambios.
 Algunas herramientas, métodos y actividades abarcan varias
etapas de la cascada; pueden ser difíciles de ajustar en las
etapas discontinuas.
 Se puede volver hacia atrás (“ciclo de vida del salmón”), pero se
puede morir en el intento.
 Pocos signos visibles hasta el final, da la impresión de ser lento.

31
Ciclo de vida del salmón

32
CV Codificar y Corregir 1/3
 Poco útil pero lamentablemente bastante común.
 Combinado con poca planificación da paso al enfoque
de “codificar a destajo”.
 Empieza con una idea general de los que se necesita
construir. Se puede tener o no una especificación
formal.
 Se utiliza cualquier combinación de diseño, codificación,
depuración y métodos de prueba no formales hasta que
se tiene el producto para entregarlo, esto siempre y
cuando se llegue a terminar.
 Se puede aplicar a proyectos pequeños que tendrán una
vida corta.
33
CV Codificar y Corregir 2/3

34
CV Codificar y Corregir 3/3
 Ventajas:
 No conlleva gestión; pues sólo se considera la especificación
pura.
 Muestra inmediatamente indicios de progreso.
 Puede ser utilizado por cualquier persona con conocimientos de
programación.
 Desventajas:
 No se puede aplicar a proyectos grandes.
 No ofrece medios de evaluación del progreso del desarrollo.
 No proporciona medios de evaluación de la calidad o
identificación de riesgos.

35
CV Construcción de Prototipos 1/4
 El cliente define los objetivos generales del
software pero no identifica los requerimientos
 Entrada
 Proceso
 Salida
 El responsable no está seguro de
 La eficacia de un algoritmo
 Capacidad de adaptación de un sistema operativo
 Forma de interacción hombre - máquina

36
CV Construcción de Prototipos 2/4
 Comienza con la recolección de los requerimientos
 Trabajo desarrollador – cliente
 Objetivos
 Requisitos conocidos
 Áreas importantes para desarrollo
 “Diseño rápido”  centrado en representación de los
aspectos del software visibles para el cliente/usuario
(p.e: E/S)
 El cliente/usuario evalúa el prototipo  refina los
requisitos

37
CV Construcción de Prototipos 3/4

38
CV Construcción de Prototipos 4/4
 Puede ser problemática por las siguientes razones:
 El cliente puede confundir el prototipo con la versión final
 Gestión de desarrollo es muy lenta
 Compromisos de implementación con sistemas operativos,
lenguajes ,etc. no adecuados sólo con la finalidad de que el
prototipo se desarrolle rápido y aceptablemente
 Puede ser efectivo
 Definir reglas de juego
 El prototipo sólo sirve para identificar requisitos

39
CV Desarrollo Rápido de
Aplicaciones (DRA) 1/4
 Se basa en el lineal secuencial
 Enfatiza ciclo de desarrollo extremadamente
corto
 Adaptación del lineal secuencial a “alta
velocidad”  construcción basada en
componentes
 Si se comprenden bien los requisitos y se
delimita el ámbito del proyecto  periodos
cortos de tiempo

40
CV Desarrollo Rápido de
Aplicaciones (DRA) 2/4
 Modelado del negocio
 Flujo de información entre las funciones
 Modelado de datos
 El flujo de información se refina como un conjunto de objetos
con sus atributos y relaciones
 Modelado del proceso
 Objetos de datos implementan una función de gestión
 Generación de aplicaciones
 Herramientas de cuarta generación  reutilización
 Pruebas y entrega
 Reduce tiempo de prueba

41
CV Desarrollo Rápido de
Aplicaciones (DRA) 3/4

42
CV Desarrollo Rápido de
Aplicaciones (DRA) 4/4
 Inconvenientes
 Proyectos grandes requieren de mucho personal
 Clientes y desarrolladores comprometidos: rapidez y
tiempo
 No es para todos los tipos de aplicaciones
 No es adecuado cuando los riesgos técnicos son
altos
 Nueva aplicación con tecnologías nuevas
 Software nuevo requiere alto grado de interoperabilidad con
programas ya existentes

43
CV Cascada Modificada 1/6
 Cascada con fases solapadas (Sashimi)
 Descrito por Peter DeGrace.
 Permite el solapamiento de las fases del modelo de cascada.
 Reduce sustancialmente la documentación necesaria.
 Es bueno para proyectos pequeños y bien definidos.
 Desventajas:
 Debido al solapamiento los hitos son más ambiguos.
 Problemas al tener tareas en paralelo, mala comunicación,
suposiciones incorrectas e ineficacia.

44
CV Cascada Modificada 2/6

Cascada con fases solapadas

45
CV Cascada Modificada 3/6
 Cascada con subproyectos.
 ¿Porqué retrasar la implementación de las áreas que son fáciles
de diseñar sólo porque estamos esperando el diseño de un área
difícil?
 Consiste en dividir el sistema en subsistemas lógicamente
independientes, cada uno de los cuales siga su “propio ritmo”.
 Desventajas:
 Se puede tener problemas cuando existen interdependencias
imprevistas entre los subsistemas.

46
CV Cascada Modificada 4/6

Cascada con subproyectos

47
CV Cascada Modificada 5/6
 Cascada con reducción de riesgos.
 Se coloca una espiral en lo alto de la cascada para controlar el
riesgo de los requerimientos.
 No está limitado a los requerimientos. Puede utilizarse para
reducir el riesgo de la arquitectura o cualquier otro riesgo del
proyecto.

48
CV Cascada Modificada 6/6

Cascada con reducción de riegos

49
CV Prototipado Evolutivo 1/3
 Se desarrolla el concepto del sistema a medida que
avanza el proyecto.
 Se empieza desarrollando los aspectos más visibles del
sistema.
 Se utiliza especialmente cuando los requerimientos
cambian con rapidez, cuando el cliente es reacio a
especificar el conjunto de requerimientos o cuando ni
usted ni el cliente identifican de forma apropiada el área
de aplicación. También cuando los desarrolladores no
están seguros de la arquitectura o algoritmos
adecuados.
50
CV Prototipado Evolutivo 2/3
 Desventajas:
 Imposibilidad de conocer al inicio el tiempo que tardará en crear
un producto aceptable.
 Puede convertirse en excusa para realizar el desarrollo con el
modelo Codificar y Corregir.

51
CV Prototipado Evolutivo 3/3

52
CV Entrega por etapas 1/2
 También conocido como “implementación incremental”.
 Se conoce desde el principio lo que se va a construir.
 El software se entrega por etapas sucesivas a lo largo
del proyecto.
 Ventajas:
 Proporcionar funcionalidad en manos del cliente antes de
entregar el 100% del proyecto al final del mismo.
 Proporciona signos tangibles de progreso a los clientes.
 Desventajas:
 No funciona sin una planificación adecuada.

53
CV Entrega por etapas 2/2

54
CV Diseño por planificación 1/2
 Al principio no siempre se conoce si se tendrá el
producto para la última entrega.
 Puede ser válida la estrategia para asegurase que se
tiene un producto para entregar en una fecha
determinada.
 Garantiza que se tendrá “algo”.
 Uno de los elementos críticos es priorizar las
prestaciones y planificar las etapas.
 Desventajas:
 Si no se completan todas las etapas, se desperdiciará tiempo en
la especificación, arquitectura y diseño de requerimientos
faltantes que no se van a entregar.
55
CV Diseño por planificación 2/2

56
CV Entrega Evolutiva 1/2
 Se encuentra entre el prototipado evolutivo y la entrega
por etapas.
 Se desarrolla una versión del producto, se muestra al
cliente y se refina el producto en función de la
retroalimentación del cliente.
 Si se lleva a cabo una planificación para adaptarse a la
mayoría de solicitudes de los clientes se parecerá más
al prototipado evolutivo.
 Si se lleva a cabo una planificación para adaptarse a
pocas solicitudes de los clientes se parecerá más a la
entrega por etapas.

57
CV Entrega Evolutiva 2/2

58
CV Espiral 1/3
 Grado bastante elevado de sofisticación.
 Ciclo de vida orientado a minimizar riesgos.
 Parte de una escala pequeña en medio de la espiral.
Cada iteración (no interacción) supone que el programa
pasa a una escala superior.
 Es como si todo el proyecto se dividiera en pequeños
mini proyectos con el objetivo de controlar uno o más
riesgos importantes.

59
CV Espiral 2/3
 Cada iteración lleva consigo los siguientes pasos:
1. Determinar objetivos, alternativas y límites.
2. Identificar y resolver riesgos.
3. Evaluar las alternativas.
4. Generar las entregas de esta iteración y comprobar que son
correctas.
5. Planificar la siguiente iteración.
6. Establecer un enfoque para la siguiente iteración (si se decide
ejecutarla).
 Se puede “configurar” según sea necesario.
 Proporciona un nivel alto de control de gestión.
 Única desventaja es que es un modelo complicado.
60
CV Espiral 3/3

61
CV Espiral WINWIN 1/2
 Espiral Victoria & Victoria
 El cliente y el desarrollador entran en un
proceso de negociación
 Ambos deben “ganar”
 El cliente obtiene un producto o sistema que satisface
la mayor parte de sus necesidades
 El desarrollador gana trabajando para conseguir
presupuestos y lograr una fecha de entrega realista

62
CV Espiral WINWIN 2/2

63
CV Desarrollo Basado en
Componentes 1/2
 Incorpora muchas características del CV en espiral
 Es evolutivo y exige un enfoque iterativo
 Configura aplicaciones desde componentes preparados de software
llamados “clases”  OO
 Inicialmente se deben identificar las clases candidatas
 Las clases creadas en proyectos anteriores están almacenadas en
bibliotecas o repositorios
 Se examina el repositorio para determinar si las clases candidatas
ya existen
 Si ya existe se la utiliza
 Sino existe se la crea aplicando los métodos OO
 Con todas las clase definidas se ensambla la aplicación
 Conduce a la reutilización del software  RUP + UML

64
CV Desarrollo Basado en
Componentes 2/2

65
CV Diseño por herramientas 1/3
 Para este modelo se debe incluir un requerimiento
dentro del producto sólo si las herramientas de software
son capaces de dar el soporte para la implementación.
 Son “herramientas”:
 Librerías de código y clases.
 Generadores de código.
 Lenguajes de desarrollo rápido, entre otras que reducen de
manera espectacular el tiempo de implementación.
 En muchos de los casos no será posible implementar
toda la funcionalidad que se considera ideal incluir.

66
CV Diseño por herramientas 2/3
 Se puede combinar con otros modelos de ciclo de vida.
 Desventajas:
 Se pierde mucho control sobre el producto.
 Puede que no sea posible llevar a cabo la implementación de
todos los requerimientos del producto y que algunos
requerimientos no se puedan implementar de la manera
deseada.

67
CV Diseño por herramientas 3/3

68
Actividades para el caso de estudio
 Trabajar en grupo
 Responder a las siguientes preguntas
detalladamente:
 ¿Qué le parece la elección del ciclo de vida?
 ¿Qué ciclo de vida hubiera elegido usted? ¿Porqué?
 Elaborar un cuadro comparativo entre el ciclo de vida
seleccionado por Bill y el que usted seleccionó
 Elaborar una lista de los errores clásicos que se
cometieron
 Prepare una exposición

69