Capítulo 2 - Procesos de software

Técnicas de análisis y diseño de sistemas de información

Análisis de Sistemas Informáticos
Richard Rivera, PhD.
ESFOT - EPN

1
Tópicos cubiertos

 Modelos de proceso de software

 Actividades de proceso
 Lidiando con el cambio
 La mejora de procesos

2
El proceso de software

 Un conjunto estructurado de actividades requeridas para

desarrollar un sistema de software.
 Muchos procesos de software diferentes, pero todos
implican:
▪ Especificación: definición de lo que debe hacer el sistema;
▪ Diseño e implementación: definición de la organización del
sistema e implementación del sistema;
▪ Validación: comprobar que hace lo que el cliente quiere;
▪ Evolución: cambiar el sistema en respuesta a las necesidades
cambiantes del cliente.
 Un modelo de proceso de software es una
representación abstracta de un proceso. Presenta una
descripción de un proceso desde una perspectiva 3
Descripciones de procesos de software

 Cuando describimos y discutimos procesos,

generalmente hablamos de las actividades en estos
procesos, como especificar un modelo de datos, diseñar
una interfaz de usuario, etc. y el orden de estas
actividades.
 Las descripciones del proceso también pueden incluir:
▪ Productos, que son los resultados de una actividad de proceso;
▪ Roles, que reflejan las responsabilidades de las personas
involucradas en el proceso;
▪ Condiciones previas y posteriores, que son declaraciones que
son ciertas antes y después de que se haya promulgado una
actividad de proceso o se haya producido un producto.

4
Procesos ágiles y basados ​en planes.

 Los procesos impulsados ​por el plan son procesos en

los que todas las actividades del proceso se planifican
por adelantado y el progreso se mide con respecto a
este plan.
 En los procesos ágiles, la planificación es incremental y
es más fácil cambiar el proceso para reflejar los
requisitos cambiantes del cliente.
 En la práctica, la mayoría de los procesos prácticos
incluyen elementos de enfoques ágiles y basados ​en
planes.
 No hay procesos de software correctos o incorrectos.
5
Modelos de proceso de software

6
Modelos de proceso de software

 El modelo de cascada
▪ Modelo basado en planes. Fases separadas y distintas de
especificación y desarrollo.
 Desarrollo incremental
▪ La especificación, el desarrollo y la validación están
intercalados. Puede ser planificado o ágil.
 Integración y configuración
▪ El sistema se ensambla a partir de componentes configurables
existentes. Puede ser planificado o ágil.
 En la práctica, la mayoría de los sistemas grandes se
desarrollan utilizando un proceso que incorpora
elementos de todos estos modelos.
7
El modelo de cascada

8
Fases del modelo de cascada

 Hay fases separadas identificadas en el modelo de

cascada:
▪ Análisis y definición de requisitos.
▪ Diseño de sistemas y software.
▪ Implementación y pruebas unitarias
▪ Integración y prueba del sistema
▪ Operación y mantenimiento
 El principal inconveniente del modelo de cascada es la
dificultad de acomodar el cambio una vez que el proceso
está en marcha. En principio, una fase tiene que estar
completa antes de pasar a la siguiente fase.

9
Problemas del modelo de cascada

 La división inflexible del proyecto en etapas distintas

dificulta la respuesta a los requisitos cambiantes del
cliente.
▪ Por lo tanto, este modelo solo es apropiado cuando los
requisitos se entienden bien y los cambios serán bastante
limitados durante el proceso de diseño.
▪ Pocos sistemas comerciales tienen requisitos estables.
 El modelo de cascada se utiliza principalmente para
grandes proyectos de ingeniería de sistemas donde se
desarrolla un sistema en varios sitios.
▪ En esas circunstancias, la naturaleza impulsada por el plan del
modelo de cascada ayuda a coordinar el trabajo.

10
Desarrollo incremental

11
Beneficios de desarrollo incremental

 Se reduce el costo de acomodar los requisitos

cambiantes del cliente.
▪ La cantidad de análisis y documentación que debe rehacerse es
mucho menor que la requerida con el modelo en cascada.
 Es más fácil obtener comentarios de los clientes sobre el
trabajo de desarrollo que se ha realizado.
▪ Los clientes pueden comentar las demostraciones del software y
ver cuánto se ha implementado.
 Es posible una entrega e implementación más rápida de
software útil para el cliente.
▪ Los clientes pueden usar y obtener valor del software antes de
lo que es posible con un proceso en cascada.
12
Problemas de desarrollo incremental

 El proceso no es visible.
▪ Los gerentes necesitan entregas regulares para medir el
progreso. Si los sistemas se desarrollan rápidamente, no es
rentable producir documentos que reflejen cada versión del
sistema.
 La estructura del sistema tiende a degradarse a medida
que se agregan nuevos incrementos.
▪ A menos que se gaste tiempo y dinero en la refactorización para
mejorar el software, el cambio regular tiende a corromper su
estructura. Incorporar más cambios de software se vuelve cada
vez más difícil y costoso.

13
Integración y configuración

 Basado en la reutilización de software donde los

sistemas se integran a partir de componentes existentes
o sistemas de aplicación (a veces llamados sistemas
COTS -Comerciales comerciales).
 Los elementos reutilizados se pueden configurar para
adaptar su comportamiento y funcionalidad a los
requisitos de un usuario
 La reutilización es ahora el enfoque estándar para
construir muchos tipos de sistemas comerciales
▪ Reutilización cubierta con más profundidad en el Capítulo 15.

14
Tipos de software reutilizable

 Sistemas de aplicaciones independientes (a veces

llamados COTS) que están configurados para su uso en
un entorno particular.
 Colecciones de objetos que se desarrollan como un
paquete para integrarse con un marco de componentes
como .NET o J2EE.
 Servicios web que se desarrollan de acuerdo con los
estándares de servicio y que están disponibles para la
invocación remota.

15
Ingeniería de software orientada a la
reutilización

16
Etapas clave del proceso

 Especificación de requisitos
 Descubrimiento y evaluación de software
 Refinamiento de requisitos
 Configuración del sistema de aplicación
 Adaptación e integración de componentes.

17
Ventajas y desventajas

 Costos y riesgos reducidos a medida que se desarrolla

menos software desde cero
 Entrega y despliegue más rápidos del sistema.
 Pero los compromisos de requisitos son inevitables, por
lo que el sistema puede no satisfacer las necesidades
reales de los usuarios
 Pérdida de control sobre la evolución de los elementos
del sistema reutilizados.

18
Flujos del proceso

19
Actividades de proceso

20
Actividades de proceso

 Los procesos de software reales son secuencias

entrelazadas de actividades técnicas, de colaboración y
de gestión con el objetivo general de especificar,
diseñar, implementar y probar un sistema de software.
 Las cuatro actividades básicas del proceso de
especificación, desarrollo, validación y evolución se
organizan de manera diferente en diferentes procesos
de desarrollo.
 Por ejemplo, en el modelo de cascada, se organizan en
secuencia, mientras que en el desarrollo incremental se
intercalan.

21
El proceso de ingeniería de requisitos.

22
Especificación de software

 El proceso de establecer qué servicios se requieren y

las limitaciones en la operación y desarrollo del sistema.
 Proceso de ingeniería de requisitos
▪ Obtención y análisis de requisitos.
• ¿Qué requieren o esperan los interesados ​del sistema?
▪ Especificación de requisitos
• Definiendo los requisitos en detalle
▪ Validación de requerimientos
• Comprobación de la validez de los requisitos.

23
Diseño e implementación de software.

 El proceso de convertir la especificación del sistema en

un sistema ejecutable.
 Diseño de software
▪ Diseñe una estructura de software que realice la especificación;
 Implementación
▪ Traducir esta estructura en un programa ejecutable;
 Las actividades de diseño e implementación están
estrechamente relacionadas y pueden estar
entrelazadas.

24
Un modelo general del proceso de diseño.

25
Actividades de diseño

 Actividades de diseño
 Diseño arquitectónico, donde identifica la estructura
general del sistema, los componentes principales
(subsistemas o módulos), sus relaciones y cómo se
distribuyen.
 Diseño de base de datos, donde diseña las estructuras
de datos del sistema y cómo se deben representar en
una base de datos.
 Diseño de interfaz, donde define las interfaces entre los
componentes del sistema.
 Selección y diseño de componentes, donde busca
componentes reutilizables. Si no está disponible, diseñe
26
cómo funcionará.
Implementación del sistema

 El software se implementa desarrollando un programa o

programas o configurando un sistema de aplicación.
 El diseño y la implementación son actividades
intercaladas para la mayoría de los tipos de sistemas de
software.
 La programación es una actividad individual sin proceso
estándar.
 La depuración es la actividad de encontrar fallas del
programa y corregirlas.

27
Validación de software

 La verificación y validación (V & V) pretende mostrar que

un sistema cumple con sus especificaciones y cumple
con los requisitos del cliente del sistema.
 Implica procesos de verificación y revisión y pruebas del
sistema.
 La prueba del sistema implica la ejecución del sistema
con casos de prueba que se derivan de la especificación
de los datos reales que el sistema procesará.
 La prueba es la actividad de V&V más utilizada.

28
Etapas de prueba

29
Etapas de prueba

 Prueba de componentes
▪ Los componentes individuales se prueban de forma
independiente;
▪ Los componentes pueden ser funciones u objetos o
agrupaciones coherentes de estas entidades.
 Prueba del sistema
▪ Prueba del sistema en su conjunto. La prueba de las
propiedades emergentes es particularmente importante.
 Prueba del cliente
▪ Prueba con datos del cliente para verificar que el sistema
cumpla con las necesidades del cliente.

30
Fases de prueba en un proceso de software
basado en planes (modelo V)

31
Evolución del software

 El software es inherentemente flexible y puede cambiar.

 A medida que los requisitos cambian a través de
circunstancias comerciales cambiantes, el software que
respalda al negocio también debe evolucionar y cambiar.
 Aunque ha habido una demarcación entre desarrollo y
evolución (mantenimiento), esto es cada vez más
irrelevante ya que cada vez menos sistemas son
completamente nuevos.

32
Evolución del sistema

33
Lidiando con el cambio

34
Lidiando con el cambio

 El cambio es inevitable en todos los grandes proyectos

de software.
▪ Los cambios comerciales conducen a requisitos de sistema
nuevos y modificados
▪ Las nuevas tecnologías abren nuevas posibilidades para
mejorar las implementaciones
▪ El cambio de plataformas requiere cambios de aplicación
 El cambio lleva al retrabajo, por lo que los costos del
cambio incluyen tanto el retrabajo (por ejemplo, volver a
analizar los requisitos) como los costos de implementar
nuevas funciones

35
Reducir los costos de retrabajo

 Anticipación al cambio, donde el proceso del software

incluye actividades que pueden anticipar posibles
cambios antes de que se requiera una revisión
significativa.
▪ Por ejemplo, se puede desarrollar un prototipo de sistema para
mostrar algunas características clave del sistema a los clientes.
 Tolerancia al cambio, donde el proceso está diseñado
para que los cambios se puedan acomodar a un costo
relativamente bajo.
▪ Esto normalmente implica alguna forma de desarrollo
incremental. Los cambios propuestos pueden implementarse en
incrementos que aún no se han desarrollado. Si esto es
imposible, entonces solo un incremento (una pequeña parte del
sistema) puede haber sido alterado para incorporar el cambio. 36
Hacer frente a los requisitos cambiantes

 Creación de prototipos del sistema, donde se desarrolla

rápidamente una versión del sistema o parte del sistema
para verificar los requisitos del cliente y la viabilidad de
las decisiones de diseño. Este enfoque apoya la
anticipación del cambio.
 Entrega incremental, donde los incrementos del sistema
se entregan al cliente para comentarios y
experimentación. Esto apoya tanto la evitación del
cambio como la tolerancia al cambio.

37
Prototipos de software

 Un prototipo es una versión inicial de un sistema

utilizado para demostrar conceptos y probar opciones de
diseño.
 Un prototipo se puede usar en:
▪ El proceso de ingeniería de requisitos para ayudar con la
obtención y validación de requisitos;
▪ En procesos de diseño para explorar opciones y desarrollar un
diseño de interfaz de usuario;
▪ En el proceso de prueba para ejecutar pruebas consecutivas.

38
Beneficios de la creación de prototipos

 Mejora de la usabilidad del sistema.

 Una coincidencia más cercana a las necesidades reales
de los usuarios.
 Calidad de diseño mejorada.
 Mantenimiento mejorado.
 Esfuerzo de desarrollo reducido.

39
El proceso de desarrollo de prototipos.

40
Desarrollo de prototipos

 Puede basarse en lenguajes o herramientas de creación

rápida de prototipos
 Puede implicar dejar de lado la funcionalidad
▪ El prototipo debe enfocarse en áreas del producto que no se
comprenden bien;
▪ La comprobación de errores y la recuperación pueden no estar
incluidas en el prototipo;
▪ Centrarse en requisitos funcionales en lugar de no funcionales,
como la fiabilidad y la seguridad.

41
Prototipos desechables

 Los prototipos deben descartarse después del

desarrollo, ya que no son una buena base para un
sistema de producción:
▪ Puede ser imposible ajustar el sistema para cumplir con los
requisitos no funcionales;
▪ Los prototipos son normalmente indocumentados;
▪ La estructura del prototipo generalmente se degrada a través del
cambio rápido;
▪ El prototipo probablemente no cumpla con los estándares
normales de calidad organizacional.

42
Entrega incremental

 En lugar de entregar el sistema como una entrega única,

el desarrollo y la entrega se desglosan en incrementos
con cada incremento entregando parte de la
funcionalidad requerida.
 Los requisitos del usuario tienen prioridad y los
requisitos de mayor prioridad se incluyen en los
primeros incrementos.
 Una vez que se inicia el desarrollo de un incremento, los
requisitos se congelan, aunque los requisitos para
incrementos posteriores pueden seguir evolucionando.

43
Desarrollo incremental y entrega

 Desarrollo incremental
▪ Desarrolle el sistema en incrementos y evalúe cada incremento
antes de proceder al desarrollo del siguiente incremento;
▪ Enfoque normal utilizado en métodos ágiles;
▪ Evaluación realizada por el intermediario del usuario / cliente.
 Entrega incremental
▪ Implemente un incremento para uso de los usuarios finales;
▪ Evaluación más realista sobre el uso práctico del software;
▪ Difícil de implementar para sistemas de reemplazo ya que los
incrementos tienen menos funcionalidad que el sistema que se
reemplaza.

44
Entrega incremental

45
Ventajas incrementales de entrega

 El valor del cliente se puede entregar con cada

incremento para que la funcionalidad del sistema esté
disponible antes.
 Los primeros incrementos actúan como un prototipo
para ayudar a obtener requisitos para incrementos
posteriores.
 Menor riesgo de fracaso general del proyecto.
 Los servicios del sistema de mayor prioridad tienden a
recibir la mayoría de las pruebas.

46
Problemas de entrega incrementales

 La mayoría de los sistemas requieren un conjunto de

instalaciones básicas que son utilizadas por diferentes
partes del sistema.
▪ Como los requisitos no se definen en detalle hasta que se
implemente un incremento, puede ser difícil identificar las
instalaciones comunes que son necesarias para todos los
incrementos.
 La esencia de los procesos iterativos es que la
especificación se desarrolla junto con el software.
▪ Sin embargo, esto entra en conflicto con el modelo de
adquisición de muchas organizaciones, donde la especificación
completa del sistema es parte del contrato de desarrollo del
sistema.
47
La mejora de procesos

48
La mejora de procesos

 Muchas compañías de software han recurrido a la

mejora de procesos de software como una forma de
mejorar la calidad de su software, reduciendo costos o
acelerando sus procesos de desarrollo.
 La mejora del proceso significa comprender los
procesos existentes y cambiar estos procesos para
aumentar la calidad del producto y / o reducir los costos
y el tiempo de desarrollo.

49
Enfoques de mejora

 El enfoque de madurez del proceso, que se centra en

mejorar la gestión de procesos y proyectos e introducir
buenas prácticas de ingeniería de software.
▪ El nivel de madurez del proceso refleja la medida en que se han
adoptado buenas prácticas técnicas y de gestión en los
procesos de desarrollo de software organizacional.
 El enfoque ágil, que se centra en el desarrollo iterativo y
la reducción de los gastos generales en el proceso del
software.
▪ Las características principales de los métodos ágiles son la
entrega rápida de funcionalidad y capacidad de respuesta a los
requisitos cambiantes del cliente.

50
El ciclo de mejora del proceso.

Analizar Cambiar

Medir

51
Actividades de mejora de procesos

 Medida de proceso
▪ Mide uno o más atributos del proceso de software o producto.
Estas mediciones forman una línea de base que lo ayuda a
decidir si las mejoras del proceso han sido efectivas.
 Análisis de proceso
▪ Se evalúa el proceso actual y se identifican las debilidades y los
cuellos de botella del proceso. Se pueden desarrollar modelos
de proceso (a veces llamados mapas de proceso) que describen
el proceso.
 Cambio de proceso
▪ Se proponen cambios en el proceso para abordar algunas de las
debilidades identificadas del proceso. Estos se introducen y se
reanuda el ciclo para recopilar datos sobre la efectividad de los
cambios. 52
Medida de proceso

 Siempre que sea posible, se deben recopilar datos

cuantitativos del proceso.
▪ Sin embargo, cuando las organizaciones no tienen estándares
de proceso claramente definidos, esto es muy difícil ya que no
sabe qué medir. Es posible que deba definirse un proceso antes
de que sea posible cualquier medición.
 Las mediciones del proceso deben utilizarse para
evaluar las mejoras del proceso.
▪ Pero esto no significa que las mediciones deban impulsar las
mejoras. El impulsor de la mejora debe ser los objetivos de la
organización.

53
Métricas de proceso

 Tiempo necesario para completar las actividades del

proceso.
▪ P.ej. Calendario de tiempo o esfuerzo para completar una
actividad o proceso.
 Recursos necesarios para procesos o actividades.
▪ P.ej. Esfuerzo total en persona-días.
 Número de ocurrencias de un evento en particular.
▪ P.ej. Número de defectos descubiertos.

54
Niveles de madurez de capacidad

55
El modelo de madurez de capacidad SEI

 1. Inicial (No gestionado)

▪ Esencialmente descontrolado
 2. Repetible Procedimientos de gestión del producto
definidos y utilizados.
 3. Definido
▪ Procedimientos y estrategias de gestión de procesos definidos y
utilizados
 4. Administrado cuantitativamente
▪ Estrategias de gestión de calidad definidas y utilizadas
 5. Optimizando
▪ Estrategias de mejora de procesos definidas y utilizadas
56
Puntos clave

 Los procesos de software son las actividades

involucradas en la producción de un sistema de
software. Los modelos de proceso de software son
representaciones abstractas de estos procesos.
 Los modelos de procesos generales describen la
organización de los procesos de software.
 Los ejemplos de estos modelos generales incluyen el
modelo de "cascada", el desarrollo incremental y el
desarrollo orientado a la reutilización.
 La ingeniería de requisitos es el proceso de desarrollar
una especificación de software.
57
Puntos clave

 Los procesos de diseño e implementación se ocupan de

transformar una especificación de requisitos en un
sistema de software ejecutable.
 La validación de software es el proceso de verificar que
el sistema cumple con sus especificaciones y que
satisface las necesidades reales deusuarios del sistema.
 La evolución del software tiene lugar cuando cambia los
sistemas de software existentes para cumplir con los
nuevos requisitos. El software debe evolucionar para
seguir siendo útil.
 Los procesos deben incluir actividades como la creación
de prototipos y la entrega incremental para hacer frente
58
al cambio.
Puntos clave

 Los procesos pueden estructurarse para el desarrollo y

la entrega iterativos, de modo que se puedan realizar
cambios sin interrumpir el sistema en su conjunto.
 Los enfoques principales para la mejora de procesos
son enfoques ágiles, orientados a reducir los gastos
generales del proceso y enfoques basados en la
madurez basados en una mejor gestión de procesos y el
uso de buenas prácticas de ingeniería de software.
 El marco de madurez del proceso SEI identifica los
niveles de madurez que corresponden esencialmente al
uso de buenas prácticas de ingeniería de software.

59