Procesos de Software

INGENIERA DE SOFTWARE
Prof. Ing. Johny Pretell

Sesin 02

1 /38

Agenda
01 La Ingeniera de SW - Capas
02 El Proceso de Ingeniera de SW

03 Modelos de Ciclo de Vida del SW

2 /38

Proceso del Software

Un conjunto coherente de polticas, estructuras organizacionales, tecnologas, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software.

Mario Piatini
3 /38

Ingeniera de Software
Es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad

4 /38

Capas de la Ingeniera de Software

Cualquier disciplina de ingeniera (incluida la Ing. de SW) debe descansar sobre un esfuerzo de organizacin de calidad.

La gestin total de la calidad y las filosofas similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la Ing. de SW.
5 /38

Capas de la Ingeniera de Software

El proceso (fundamento de la Ing. de SW) define un marco de trabajo para un conjunto de reas clave, las cuales forman la base del control de gestin de proyectos de software y establecen el contexto en el cual: se aplican los mtodos tcnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los mtodos de la Ing. de SW, indican cmo construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la Ing de SW, proporcionan un soporte automtico o semi-automtico para el proceso y los mtodos, a estas herramientas, se les llama herramientas CASE (Computer-Aided Software Engineering.
6 /38

Proceso de Ingeniera de Software

El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de lograr un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998]. El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998].
7 /38

Elementos del Proceso de Software

8 /38

Proceso de Software
Qu es un proceso de Software? Es un conjunto estructurado de actividades para: Especificar Disear Implementar Probar Mantener Software.

9 /38

Proceso de Software
.se basan en modelos, mtodos y herramientas que sirven como una gua para los ingenieros de Software durante el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos, procesos y productos mediante la evaluacin y medicin de los mismos . requiere de un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin
10 /38

Ciclo de Vida del Software

Un Concepto dado por IEEE 1074 es el ciclo de vida del software es una aproximacin lgica a la adquisicin el suministro, el desarrollo, la explotacin y el mantenimiento del software. Otro concepto dado por ISO 12207 Es un marco de referencia que contiene los procesos las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso

11 /38

Modelos del ciclo de vida del software

Existen varios modelos del ciclo de vida del software, sin embargo los mas utilizados son: Cascada, Prototipado, Incremental, Evolutivo y Espiral.

12 /38

Modelo Cascada
Definicin de Requerimientos

Diseo del Software y del Sistema

Implementacin y Prueba de unidades

Integracin y Prueba del Sistema Operacin y Mantenimiento

13 /38

Modelo Cascada
Se puede hacer uso de este modelo cuando se presenten las siguientes condiciones: Cuando los requisitos del problema se entienden razonablemente. Para hacer adaptaciones o mejoras bien definidas a un sistema existente. Limitadamente en proyectos nuevos, solo cuando los requisitos estn muy bien definidos y estables en forma razonable. El modelo en cascada sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software.

Problemas que se presentan al aplicar el modelo en cascada: Es raro que los proyectos reales sigan el flujo secuencial que propone el modelo. El modelo tiene iteracciones indirectas, lo cual confunde al equipo desarrollador. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explicita. El modelo lo requiere desde un principio. El Cliente debe tener paciencia. Una versin funcionando estar lista cuando el proyecto este muy avanzado.

14 /38

Modelo Incremental
Cuando hay una necesidad imperiosa de producir de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla y expandirla en entregas posteriores de software. En estos casos se elige un modelo de proceso diseado para producir el software de manera incremental.

15 /38

Modelo Incremental
El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa.

1. Combina elementos del modelo lineal con la filosofa de creacin de prototipos 2. El primer incremento a menudo es un producto esencial (ncleo) 3. A partir de la evaluacin se planea el siguiente incremento y as sucesivamente 4. Es interactivo por naturaleza 5. Aseguramiento de la calidad 6. Es til cuando el personal no es suficiente para la implementacin completa
Ventajas: Se puede financiar el proyecto por partes Apropiado para proyectos grandes de larga duracin No se necesita tanto personal al principio como para una implementacin completa Desventajas: Se necesitan pruebas de regresin Pueden aumentar el coste debido a las pruebas
16 /38

El Modelo DRA
Desarrollo rpido de aplicaciones (DRA) es un modelo que resalta un ciclo de desarrollo corto. Si se entienden bien los requisitos y se limita bien el mbito del proyecto, un equipo de desarrollo puede crear un sistema completamente funcional dentro de un periodo muy corto.

17 /38

El Modelo DRA

Inconvenientes: Para proyectos grandes requiere recursos humanos suficientes Los clientes y desarrolladores deben estar comprometidos en las rpidas actividades Si el sistema no se puede modularizar ser problemtico no es adecuado con riesgos tcnicos altos

18 /38

Modelo de Desarrollo Evolutivo

Actividades Concurrentes
Versin Inicial

Especificacin

Descripcin del sistema

Desarrollo

Versiones Intermedias

Validacin

Versin Final

19 /38

Modelo de Desarrollo Evolutivo

Conlleva el refinamiento sucesivo de una arquitectura OO, por el cual se aplica la experiencia y resultados de cada versin a la siguiente iteracin del anlisis y el diseo. Ventajas: Es ideal para sistemas que no tienen bien definidos los requerimientos. Los desarrolladores ven ms rpido el resultado de su trabajo.

Desventajas : Es difcil distinguirlo del proceso codifica y corrige

20 /38

Modelo Basado en Prototipos

Un paradigma de construccin de prototipos puede tomar un mejor enfoque: Cuando el cliente define los objetivos generales, pero no identifica los requisitos detallados de entrada, salida o procesamiento. Cuando el desarrollador de software esta inseguro de la eficacia de una algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin hombre-mquina.

21 /38

Construccin de Prototipos
Ventajas:
No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

Inconvenientes:
A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones: El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha sido construido. El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.

22 /38

El Modelo en Espiral
Determine objetivos alternativas y restricciones Anlisis de Riesgos Anlisis de Riesgos Anlisis de Riesgos Anlisis de Proto Riesgos tipo 3 Prototipo Prototipo 3 2 Evale alternativas, identifique y resuelva riesgos

Prototipo Operacional

REVISIN

Plan de requerimientos Concepto de Plan del ciclo de vida Operacin

Simulaciones, modelos y benchmarks

Planea la siguiente fase

Requeri Diseo mientos de Diseo del Detallado SW Plan de Validacin de Producto Codificacin Desarrollo Requerimientos Prueba de Unidades Plan de Integracin Diseo Prueba de y Prueba V &V Prueba de Integracin Desarrolla y verifica Aceptacin el siguiente nivel Servicio del producto

23 /38

El Modelo en Espiral
Ventajas Centra su atencin en la reutilizacin de componentes y eliminacin de errores en informacin descubierta en fases iniciales. Los objetivos de calidad son el primer objetivo. Integra desarrollo con mantenimiento. Provee un marco de desarrollo de hardware/software. Los desarrolladores observan los resultados de sus trabajos ms rpidamente. Puede modificar algunos requerimientos durante el desarrollo. Desventajas Es un modelo amplio y necesita de personal con experiencia, sino podra fracasar el modelo. Se debe aplicar a proyectos grandes.

24 /38

El Modelo de Desarrollo Concurrente

Consiste en avanzar una o ms fases del desarrollo del software en forma paralela. Ventajas: Hay una cierta aceleracin en el desarrollo del proyecto. Se intenta mantener a todo el personal del proyecto realizando la fase que le corresponde. Desventajas : Existe la posibilidad de avanzar alguna fase sin haber previsto que surjan algunos cambios o errores. No hay mucho control en el tiempo de cada fase

25 /38

El Modelo de Proceso Unificado

Proceso Unificado de Rational ( RUP ) Proceso dirigido por casos de uso Proceso centrado en la arquitectura Proceso Iterativo o incremental Modelado Visual UML Verificacin continua de Calidad Gestin de los cambios Administracin de Riesgos

26 /38

Proceso Unificado de Rational ( RUP )

27 /38

Modelo MSF
MICROSOFT SOLUTION FRAMEWORK ( MSF )
Es un modelo para el ciclo de vida de un software creado por la compaa Microsoft en el cual se nota un uso de framework. El framework es una estructura o un marco de trabajo utilizado para el desarrollo del sw. Este modelo adems posee una flexibilidad que hace posible que sea usado tanto en proyectos grandes como en proyectos pequeos (refirindose al alcance de los proyectos Es aplicable a proyectos de infraestructura o redes.
28 /38

Modelo XP
Programacin Extrema (XP)
Extreme Programing (XP) Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.

29 /38

Programacin Extrema (XP)

30 /38

Participantes en el Proceso de Desarrollo de Software

31 /38

LA CALIDAD DEL SOFTWARE

32 /38

El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. Las mejores prcticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres reas de inters cubiertas por los modelos de CMMI: Desarrollo, Adquisicin y Servicios. es un modelo para la mejora y evaluacin de procesos para el desarrollo, mantenimiento y operacin de sistemas.

33 /38

La versin actual de CMMI es la versin 1.3, liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versin 1.2 disponible: CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versin 1.2 fue liberado en agosto de 2006. En l se tratan procesos de desarrollo de productos y servicios. CMMI para la adquisicin (CMMI-ACQ o CMMI for Acquisition), Versin 1.2 fue liberado en noviembre de 2007. En l se tratan la gestin de la cadena de suministro, adquisicin y contratacin externa en los procesos del gobierno y la industria. CMMI para servicios (CMMI-SVC o CMMI for Services), est diseado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.
34 /38

Dentro de la constelacin CMMI-DEV, existen dos modelos: CMMI-DEV CMMI-DEV + IPPD (Integrated Product and Process Development) Independientemente de la constelacin\modelo que opta una organizacin, las prcticas CMMI deben adaptarse a cada organizacin en funcin de sus objetivos de negocio. Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organizacin es evaluada (por ejemplo, usando un mtodo de evaluacin como SCAMPI) y recibe una calificacin de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organizacin, puede coger reas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las reas de Proceso, obteniendo el "Perfil de Capacidad" de la Organizacin.

35 /38

NIVELES DEL MODELO DE MADUREZ CMMI

36 /38

CMMI propone 5 distintos modelos de madurez de las organizaciones:

Inicial - Estado inicial donde el desarrollo se basa en la heroicidad y

responsabilidad de los individuos. Los procedimientos son inexistentes o localizados a reas concretas. No existen plantillas definidas a nivel corporativo.

Gestionado - Se normalizan las buenas prcticas en el desarrollo de

proyectos (en base a la experiencia y al mtodo). En este nivel consolidado, las buenas prcticas se mantienen en los momentos de estrs. Estn definidos los productos a realizar. Se definen hitos para la revisin de los productos.
37 /38

Definido - La organizacin entera participa en el proceso eficiente de

proyecto software. Se conoce de antemano los procesos de construccin de software. Existen mtodos y plantillas bien definidas y documentados. Los procesos no solo afectan a los equipos de desarrollo sino a toda la organizacin relacionada. Los proyectos se pueden definir cualitativamente.

Cuantitativamente Gestionado
Se puede seguir con indicadores numricos (estadsticos) la evolucin de los proyectos. Las estadsticas son almacenadas para aprovechar su aportacin en siguientes proyectos. Los proyectos se pueden pedir cuantitativamente.

Optimizado
En base a criterios cuantitativos se pueden determinar las desviaciones ms comunes y optimizar procesos. En los siguientes proyectos se produce una reduccin de costes gracias a la anticipacin de problemas y la continua revisin de procesos conflictivos.
38 /38

Integracin de modelos (CMM-SW, SE-CMM, IPD-CMM) SE-CMM El Modelo de Madurez de Capacidades en la Ingeniera de Sistemas fue publicado por el SEI en noviembre de 1995. Est dedicado a las actividades de ingeniera de sistemas. Define 18 reas de proceso divididas en tres grupos: Ingeniera (7) Proyectos (5) Organizativas (6)

39 /38

No utiliza niveles de madurez generales sino que en cada rea de proceso una organizacin puede alcanzar un determinado nivel de madurez. Al igual que el SW-CMM, ha sido integrado en el CMMI. IPD-CMM El Modelo de Madurez de Capacidades para el Desarrollo Integrado de Productos fue propuesto como un borrador por el SEI en 1997, pero qued integrado en el CMMI al publicarse este en el ao 2000. P-CMM Modelo de Madurez de Capacidades para Recursos Humanos SA-CMM Modelo de Madurez de Capacidades para la Adquisicin de Software S3M Modelo de Madurez de Capacidades para el mantenimiento del software

40 /38

Para asegurar la evolucin por estos modelos de madurez, se deben cumplir una serie de requisitos y prcticas. Existen prcticas a realizar de modo particular (SP = prctica especfica) en cada requerimiento y otras que son globales (GP = Practica global) y van apareciendo repetitivamente en distintos puntos. Cada prctica tiene a su vez sub-prcticas y practicas opcionales....

41 /38

Nivel 2 El nivel 2 requiere que hayamos considerados las siguientes cosas: Gestin de requisitos Plan de Proyecto Monitorizacin y control del proyecto Gestin de acuerdos con proveedores Medida y anlisis Medidas de calidad en el proceso y producto Gestin de la configuracin A continuacin vamos a ver un ejemplo de las actividades detalladas, definidas por CMMI a realizar en el primer punto del nivel de madurez 2.

42 /38

Gestin de requisitos Podemos ver las distintas actividades a realizar en gestin de requisitos SG 1 Gestionar Requerimientos [PA146.IG101] SP 1.1 Obtener y comprender requerimientos SP 1.2 Obtener la aprobacin de los requerimientos SP 1.3 Gestionar los cambios en requisitos SP 1.4 Mantener una trazabilidad bidireccional de requisitos SP 1.5 Identificar inconsistencias entre el trabajo real a realizar y los requisitos.

43 /38

GG 2 Institucionalizar la gestin del proceso de toma de requerimientos [CL103.GL101] GP 2.1 (CO 1) Establecer las polticas de la organizacin GP 2.2 (AB 1) Planificar los procesos GP 2.3 (AB 2) Proporcionar los recursos adecuados GP 2.4 (AB 3) Asignar las responsabilidades GP 2.5 (AB 4) Formar al personal GP 2.6 (DI 1) Gestionar la configuracin GP 2.7 (DI 2) Identificar los actores importantes GP 2.8 (DI 3) Monitorizar y controlar los procesos GP 2.9 (VE 1) Evaluar objetivamente el cumplimiento GP 2.10 (VE 2) Revisar el proyectos con los responsables de mayor nivel.
.....................
44 /38

Existen herramientas para verificar el seguimiento de CMM/CMMI...

Una de la ms recomendada es CMM-Quest, por su sencillez. En la Web hay disponible una versin de evaluacin.

45 /38

Una vez descargado el fichero arranca la instalacin

Al completar la instalacin se lanza automticamente esta pantalla...

46 /38

Podemos abrir el proyecto que viene por defecto o crear uno nuevo

Al ser una versin de evaluacin, muchas de las ventanas de informacin desaparecen a los pocos segundo de mostrarse pero nos vale para hacernos una idea de cmo funciona.... Al crear uno nuevo y pulsar el botn "prepare" aparece una ventana como sta...

47 /38

La herramienta cubre toda la CMMI. Si se selecciona la parte de Gestin de Requerimientos, nos aparecen las prcticas a desarrollar.

48 /38

Podemos ir rellenando el factor de cumplimiento de distintos elementos, nos proporcionar grficas con indicadores
49 /38

Preguntas
Conclusiones Finales

50 /38