Ellen Lujan Méndez Xavier Profesor Orientador M.Sc. Luís Gilberto Salinas San Lorenzo, 2009

“Modelo de procesos para el desarrollo de software”

Ing. de requerimientos – Análisis - Diseño

Ellen Lujan Méndez Xavier

Profesor OrientadorM.Sc. Luís Gilberto Salinas

San Lorenzo, 2009

Universidad Nacional de AsunciónFacultad Politécnica

1

Contenido

• Introducción.

• Análisis actual e informes oficiales.

• Objetivo principal y específico.

• Modelos de procesos tradicionales.

• Modelos de mejora de procesos.

• Bases del modelo propuesto.

• Procesos.

• Caso de prueba.

• Conclusiones y aportes.

• Trabajos futuros.2

Introducción

3

Análisis actual e informes oficiales

Internacional (The Chaos Report 2007-2009)35% - 32% proyectos exitosos.46% - 44% sobrepasan costos y plazos,

parcialmente requerimientos.19% - 24% no llegan a culminarse.

Reportes nacionales

El 83% de las empresas del sector no posee certificación de ningún tipo. El 17% ha declarado que sus empresas poseen la certificación de calidad ISO

9001:2000.

4


Si9%

No91%

Documentación de procesos

5


6

CMMI26%

ISO 1550419%ISO 9001

24%

MP-S.BR2%

MO-PROSO

FT5%

ISO 12207

2%No Posee

22%

Conocimiento de Modelos de Calidad

Objetivos

7

Principal

• Presentar un modelo de procesos para las fases de relevamiento de requerimientos y análisis que se

ajusten al mercado de desarrollo de software, con el fin de mejorar el

proceso de desarrollo.

Objetivos

8

Específicos• Realizar un estudio sobre diversos modelos de procesos que rigen a nivel

mundial y regional

• Definir características principales y diferencias de cada modelo comparando

cada entorno con el estado actual del país.

• Desarrollar procesos para estandarizar y documentar las fases correspondientes al

alcance de este trabajo.

Objetivos

9

Específicos• Proponer un modelo de procesos básico para las fases de requerimientos y análisis,

utilizando paradigmas existentes en la ingeniería de software.

• Realizar pruebas de implementación de los procesos para evaluar la adaptabilidad del

mismo.

• Iniciar la utilización de modelos de procesos para impulsar a las empresas a las

certificaciones más rigurosas existentes a nivel mundial.

Modelos de procesos tradicionales


Modelo en cascada

11

Requerimientos / análisis

Diseño

Codificación y pruebas unitarias

Pruebas de integración

Operación y mantenimient

o


Entrega por Etapas

12

Concepto de Software


Diseño global

Etapa 1. Diseño detallado, codificación, depuración, prueba y

entrega

Etapa 2. Diseño detallado, codificación, depuración, prueba y

entrega

Etapa n. Diseño detallado, codificación, depuración, prueba y

entrega


Modelo de entrega evolutiva

13

Concepto de Software


Diseño global

Desarrollar versión

Entregar Versión

Reducir la realimentación del cliente

Incorporar la realimentación del cliente

Entregar

versión final

Modelos de mejora de procesos

Normas internacionales ISO/IEC 12207

15

Procesos del contexto del

sistema

Procesos de acuerdo

Procesos organizacionales del

proyecto

Procesos del proyecto

Procesos técnicos

Procesos específicos del

softwareProcesos de

implementación del software

Procesos de soporte del software

Procesos de reutilización del

software

Normas internacionales ISO/IEC 15504

16

Parte 1. Conceptos y vocabularios

Parte 2. Realización de la

evaluación (Normativa)

Parte 7. Evaluación de la madurez de una

organización

Parte 5. Un ejemplo de modelo de

evaluación de procesos

Parte 6. Un ejemplo de modelo de

evaluación del ciclo de vida del sistema

Parte 3. Guía para la realización de la evaluación

Parte 4. Guía sobre el uso para

la mejora y determinación de la capacidad del

proceso.

A nivel regional

17

MOPROSOFT MPS.BR PERUANA

1 Definición de propósitos del proceso

2 Definición de Entradas/Salidas de cada proceso

3 Definición de roles

4 Definición específica de actividades

5 Definición específica de validaciones y verificaciones por actividad

6 Definición de estructura de documentos

7 Descripción de tareas por actividad

8 Definición de criterios de evaluación de requerimientos

9 Fundamentación teórica del proceso

10 Definición de objetivos y resultados esperados

11 Sugerencia de herramientas y métodos para lograr objetivos

12 Utilización de gráficos para definir tareas del proceso

A nivel regional Light MECPDS

18

Framework de medida

• Niveles de capacidad• Atributos del proceso• Escala de valor

Modelo de procesos de referencia

• Dominio y alcance• Propósitos del proceso• Salidas del proceso

Modelo de evaluación de

procesos• Propósitos• Alcance• Indicadores• Mapeo

Bases del modelo propuesto


Incorporación de tres procesos relacionados con el desarrollo de software como parte un modelo de calidad inicial.

20

Objetivo

• Definir las principales actividades y tareas relacionadas con cada proceso, incluyendo los roles involucrados y recomendaciones.


21

Relevamiento de requerimientos

Administración de

requerimientos

Análisis y diseño

Matríz de evaluación

ISO 12207MOPROSOF

TMPS-BR

CMMI

ISO 9000

CMMI

ISO 12207

Light MECPDS

ISO 15504


Patrón de descripción de procesos Nombre del proceso Propósito y objetivos Fundamentación teórica Roles Actividades Flujos Alternos Recomendaciones Diagrama de flujo de procesos Matriz de evaluación

22


Nivel 0 – Incompleto Nivel 1 – Realizado Nivel 2 -

Administrado

No Implementado (0-50%)

Parcialmente Implementado (51%-84%)

Implementado (85%-100%)

23

Id Descripción Evaluación

I PI NI

NIVEL 2

NIVEL 1

1.1 ...........

1.2 ...........

1.3 ...........

2.1 ...........

.... .......

Procesos


Propósito y objetivos Obtención de datos de requerimientos claros y bien

definidos

Roles Líder de proyecto

Encargado de documentación

Equipo de requerimientos

Cliente

Usuario

25


Recomendaciones Documentación de requerimientos Formulario de registro de solicitudes de

clientes Documento de estudio de factibilidad y

viabilidad

26


27

Inicio

RR.1. Presentar las necesidades y

características requeridas

RR.2. Registrar necesidades del

cliente

RR.3. Redactar/Modificar documento BASE de requerimientos

RR.4. Analizar la documentación

BASE

RR.5. Realizar estudio de

viabilidad de implementación

Factible

RR.6. Análisis general y

detallado de requerimientos

RR.7. Redactar/Modificar de documentación

OFICIAL

RR.8. Verificar documentación

Correcto

RR.9. Presentar documentación oficial al Cliente

RR.10. Aceptación de documentacion

presentada

Fin

RR.5.a. Replantear la

implementación según realidad y

necesidades

RR.5.b. Analizar estudio de viabilidad


Inicio


cliente



BASE



Factible




OFICIAL


Correcto



presentada

Fin



necesidades


RR.1. Presentar las necesidades y características

requeridas

27


Inicio





BASE



Factible




OFICIAL


Correcto



presentada

Fin



necesidades


RR.2. Registrar

necesidades del cliente

27


Inicio




cliente


BASE



Factible




OFICIAL


Correcto



presentada

Fin



necesidades



27


Inicio




cliente




Factible




OFICIAL


Correcto



presentada

Fin



necesidades


27

RR.4. Analizar la

documentación BASE


Inicio




cliente



BASE

Factible




OFICIAL


Correcto



presentada

Fin



necesidades




27


Inicio




cliente



BASE






OFICIAL


Correcto



presentada

Fin



necesidades


Factible

27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto



presentada

Fin

RR.5.a. Replantear la implementación según realidad y

necesidades


27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto



presentada

Fin



necesidades

RR.5.b. Analizar

estudio de viabilidad

27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto



presentada

Fin



necesidades


27


Inicio




cliente



BASE



Factible




Correcto



presentada

Fin



necesidades


27


OFICIAL


Inicio




cliente



BASE



Factible




OFICIAL

Correcto



presentada

Fin



necesidades



27


Inicio




cliente



BASE



Factible




OFICIAL

RR.8. Verificar documentación Correcto



presentada

Fin



necesidades


27


Inicio




cliente



BASE



Factible




Correcto



presentada

Fin



necesidades



OFICIAL

27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto

RR.9. Presentar documentación

oficial al Cliente


presentada

Fin



necesidades


27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto


RR.10. Aceptación de documentación

presentada

Fin



necesidades


27


Inicio




cliente



BASE



Factible




OFICIAL


Correcto


RR.10. Aceptación de documentación

presentada

Fin



necesidades


27


28


I PI NI

NIVEL 2

NIVEL 1

1.1 Estudio de viabilidad de implementación y documentaciones de fundamentación

1.2 Documentaciones detallas por reuniones con clientes (Formulario y otros)

1.3 Documentación formal de requerimientos de sistema y del software


2.1 Control de versiones de documentaciones.

2.2 Control de integridad de documentaciones.

2.3 Control de consistencias entre documentación formal y formularios y registro por reuniones o solicitudes.

2.4 Control de cronograma de trabajo

2.5 Documentación de tareas realizadas por roles o usuarios.

2.6 Estabilidad de los requerimientos durante el proceso.

Administración de requerimientos

Propósito y objetivos Administrar los posibles cambios de requerimientos durante

la evolución del ciclo de desarrollo del proyecto.

Roles Líder de proyecto

Encargado de documentación

Equipo de requerimientos

Cliente

Usuario

29


Recomendaciones Formulario de cambio o ingreso de

nuevos requerimientos Documento de estudio de

implementación

30


31

Inicio

AR.1. Presentar modificaciones y/o


AR.2. Registrar necesidades del

cliente

AR.3. Realizar estudio de

implementaciónFactible

AR.3.a. Replantear la implementación según realidad y

necesidades

AR.3.b. Coordinar nuevos cambios

según necesidades

AR.4. Administrar los nuevos

requerimientos según avance del

proyecto

AR.5. Documentar nuevos

requerimientos e implicancias en el

proyecto

AR.6. Verificar consistencia del

proyecto

AR.7. Registrar nuevos

requerimientos o modificaciones

Fin


31

Inicio


cliente



AR.3.a. Replantear la


necesidades

AR.3.b. Coordinar

nuevos cambios según

necesidades

AR.4. Administrar los

nuevos requerimientos

según avance del proyecto

AR.5. Documentar

nuevos requerimientos e implicancias en

el proyecto


proyecto



Fin




31

Inicio

AR.1. Presentar modificaciones

y/o características

requeridas





necesidades

AR.3.b. Coordinar


necesidades




AR.5. Documentar


el proyecto


proyecto



Fin

AR.2. Registrar

necesidades del cliente


31

Inicio



requeridas


clienteFactible



necesidades

AR.3.b. Coordinar


necesidades




AR.5. Documentar


el proyecto


proyecto



Fin


implementación


31

Inicio



requeridas


cliente


implementación



necesidades

AR.3.b. Coordinar


necesidades




AR.5. Documentar


el proyecto


proyecto



Fin

Factible


31

Inicio



requeridas


cliente




necesidades

AR.3.b. Coordinar


necesidades




AR.5. Documentar


el proyecto


proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades



proyecto



proyecto


proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades

AR.4. Administrar los nuevos requerimientos




proyecto


proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades



proyecto

AR.5. Documentar nuevos requerimientos e

implicancias en el proyecto


proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades



proyecto



proyecto

AR.6. Verificar

consistencia del proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades



proyecto



proyecto


proyecto



Fin


31

Inicio




cliente




necesidades


según necesidades



proyecto



proyecto


proyecto



Fin


32


I PI NI

NIVEL 2

NIVEL 1

1.1 Registro de modificaciones requeridas por el cliente

1.2 Estudio de factibilidad de implementación

1.3 Registro de nuevos requerimientos

1.4 Negociación o replanteamiento de cambio.

1.5 Documentación de consistencia del proyecto.

2.1 Administración de nuevos requerimientos

2.2 Documentación detallada de los cambios.

2.3 Documentación detallada de estudio de factibilidad


2.5 Documentación de taras realizadas por roles y usuarios.

Análisis y diseño

Propósito y objetivos Realizar el análisis detallado de los requerimientos

obtenidos en el proceso de relevamiento de requerimientos

y realizar el diseño detallado de la implementación del

proyecto.

Roles Líder de proyecto Analistas Diseñadores Encargado de documentaciones Cliente

33

Análisis y diseño

34

Inicio

AD.1.Realizar distribución de

actividades

AD.2. Analizar Especificación de Requerimientos

AD.3 Generar/Modificar Documentación

AD.4 Realizar corrección y

estructuración de documentación

AD.5. Verificar consistencia con

Documentación de requerimientos

Consistente

AD.6. Generar Diseño del Proyecto

AD.7. Verificar procesos y

funcionalidades principales

Culminado

AD.8. Añadir Diseño al

Documento Analisis-Diseño

AD.9. Realizar corrección y

estructuración de Documentación

Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades






Consistente




Culminado





Análisis y Diseño

Fin


Análisis y diseño

34

Inicio


actividades






Consistente




Culminado





Análisis y Diseño

Fin


Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades





Consistente




Culminado





Análisis y Diseño

Fin



Análisis y diseño

34

Inicio


actividades






Documentación de requerimientos Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades






Consistente




Culminado





Análisis y Diseño

Fin


Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades







Consistente








Análisis y Diseño

Fin

Culminado

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado


Documento Análisis-Diseño



Análisis y Diseño

Fin

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado



FinAD.9. Realizar corrección y estructuración de

Documentación Análisis y Diseño

Análisis y diseño

34

Inicio


actividades







Consistente




Culminado





Análisis y DiseñoFin

Análisis y diseño

35


I PI NI

NIVEL 2

NIVEL 1

1.1 Distribución de trabajos y/o actividades.

1.2 Documentación de análisis/diseño del proyecto

1.3 Utilización de modelos actuales y claros para el análisis y diseño del proyecto

1.4 Documentación de cambios.

2.1 Distribución detallada de trabajos y/o actividades

2.2 Control de integridad de documentaciones

2.3 Modelos detallados según proyecto.


2.5 Administración de actividades designadas a cada rol.

2.6 Control de trazabilidad entre los requerimientos y diseño

Caso de prueba

36

Caso de prueba

FactPo – Sistema de Facturacion de Podas Empresas dedicadas a la poda.

Análisis de Puntos de Función Lenguaje orientado a objetos Seguridad, modularidad, comunicacion a

datos, complejidad.

37

Caso de prueba

Relevamiento de Requerimientos Reuniones con el cliente:2

Sistema existente. Materiales proporcionados por el cliente

Estudio de viabilidad básico Documento de requerimientos.

38

Caso de prueba

39

Id DescripciónEvaluación

ObservaciónI PI NI

NIVEL 1

1.1 Estudio de viabilidad de implementación y documentaciones de fundamentación

100% Documento de estudio de viabilidad en formato definido

1.2 Documentaciones detallas por reuniones con clientes (Formulario y otros)

92,5% Documentaciones por escrito de características y redacción de documentación de reunión con el cliente


100% ERS

1.4 Evaluación y validación de los requerimientos con el cliente.

100% Aceptación de ERS por parte del cliente

Caso de Prueba

40


ObservaciónI PI NI

NIVEL 2

2.1 Control de versiones de documentaciones.

95% Utilización de SVN y planilla de versiones en ERS

2.2 Control de integridad de documentaciones.

80% Verificaciones de documentación por rol

2.3 Control de consistencias entre documentación formal y formularios y registro por reuniones o solicitudes.

50% Verificaciones de documentación por roles definidos en el proceso

2.4 Control de cronograma de trabajo 66,67% Cronograma adjunto a ERS con principales fases del proceso

2.5 Documentación de tareas realizadas por roles o usuarios.

100% Planilla de control de versiones en ERS

2.6 Estabilidad de los requerimientos durante el proceso.

-- No se presentan variaciones de requerimientos a los presentados por el cliente en las reuniones.

Caso de Prueba

Análisis y diseño Descripción detallada de casos de uso Diagrama de clases Diagrama físico de base de datos Diagrama de estados Diagrama de componentes y despliegue

41

Caso de Prueba

42


ObservaciónI PI NI

NIVEL 1

1.1 Distribución de trabajos y/o actividades. 100%

1.2 Documentación de análisis/diseño del proyecto

100%

1.3 Utilización de modelos actuales y claros para el análisis y diseño del proyecto

100%

1.4 Documentación de cambios. 100%

Caso de Prueba

43


ObservaciónI PI NI

NIVEL 2

2.1 Distribución detallada de trabajos y/o actividades

100% Documentación de distribución de trabajo

2.2 Control de integridad de documentaciones

0%No se puede verificar el control de documentaciones

2.3 Modelos detallados según proyecto. 60%

Detalle de casos de uso y general de diagramas de actividades.

2.4 Control de cronograma de trabajo 95% Se mantiene cronograma ERS con cierta irregularidad de trabajo según SVN

2.5 Administración de actividades designadas a cada rol.

33,33% No puede verificarse seguimiento de actividades realizadas.

2.6 Control de trazabilidad entre los requerimientos y diseño 0%

No puede verificarse seguimiento de actividades realizadas.

Caso de Prueba

Administración de requerimientos Incorporación de nuevos requerimientos

a los definidos inicialmente Inclusión del requerimiento en fase de

diseño. Modificaciones de requerimientos

funcionales y no funcionales Modificaciones de casos de usos Modificaciones de diseño físico de BD

44

Caso de Prueba

45

Id Descripción Evaluación Observación

I PI NI

NIVEL 1

1.1 Registro de modificaciones requeridas por el cliente

100% Formulario de solicitud de cambios según formato definido

1.2 Estudio de factibilidad de implementación

100% Documento de modificaciones según formato definido.

1.3 Registro de nuevos requerimientos 100% Se incluye en ERS con registro en planilla de cambios.

1.4 Negociación o replanteamiento de cambio.

--

1.5 Documentación de consistencia del proyecto.


Caso de Prueba

46

Id Descripción Evaluación Observación

I PI NI

NIVEL 2

2.1 Administración de nuevos requerimientos


2.2 Documentación detallada de los cambios.


2.3 Documentación detallada de estudio de factibilidad

25% Documento de modificaciones según formato definido. Estudio de factibilidad básico

2.4 Control de cronograma de trabajo 100% Se ajusta a cronograma definido en ERS

2.5 Documentación de tareas realizadas por roles y usuarios.

100% Según planilla de cambios en documento de salida y ERS

Conclusiones

Conclusiones

48

•Procesos implementados han llegado a los objetivos principales de los procesos definidos.

Objetivos

•Tiempos especificados para cada proceso han sido cumplidos.

Cronograma

•Estudio de factibilidad detallado.

•Control de trazabilidad de requerimientos y diseño

• Control de integridad de documentación

Para el NIVEL 2, falta de aplicabilidad en:

Conclusiones

49

•Orientados a recomendaciones

Documentaciones de los procesos

•Aplicables a distintos modelos, variadas metodologías y tecnologías ya que no se encuentra relacionado a un enfoque o estándar específico

Definición de los procesos

Conclusiones

PrincipalPresentar un modelo de procesos para las

fases de relevamiento y análisis que se ajusten al mercado de desarrollo de

software, con el fin de mejorar el proceso de desarrollo.

50

1- Definición de procesos para las fases Relevamiento de Requerimientos Administración de Requerimientos Análisis y diseño

2- Definición de matrices de evaluación para cada proceso

Específicos Realizar un estudio sobre diversos modelos

de procesos que rigen a nivel mundial y regional

Conclusiones

51

Presentación de normas y estándares como son

ISO/IEC 12207 ISO/IEC 15504 MPS.BR Moprosoft Norma Peruana Light MECPDS

Conclusiones

Específicos Definir características principales y

diferencias de cada modelo comparando cada entorno con el estado actual del país.

52

1- Comparación de modelos regionales MPS.BR Moprosoft Norma Peruana

Conclusiones

Específicos Desarrollar procesos para estandarizar y

documentar las fases correspondientes al alcance de este trabajo.

53

1- Definición de procesos Relevamiento de requerimientos Administración de requerimientos Análisis y diseño

2- Matriz de evaluación

Específicos Proponer un modelo de procesos básico

para las fases de requerimientos y análisis, utilizando paradigmas existentes en la ingeniería de software

Conclusiones

54

1- Definición de procesos

2- Propuestas de documentaciones según buenas

prácticas de la ingeniería de software y estándares vigentes.

Específicos Realizar pruebas de implementación de los

procesos para evaluar la adaptabilidad del mismo.

Conclusiones

55

1- Aplicación de los procesos en un proyecto real.

2- Evaluación de procesos de acuerdo a método y matriz definida para cada proceso

3- Documentación de resultados.

Conclusiones

Específicos Iniciar la utilización de modelos de

procesos para impulsar a las empresas a las certificaciones más rigurosas existentes a nivel mundial.

56

1- Caso de estudio desarrollado a pedido de empresas

actualmente activas.

2- Utilización de procesos con varios grupos de desarrollo.

3- Iniciación práctica del modelo

Aportes

Aportes

58

Inicio del estudio de un modelo aplicable a empresas y proyectos realizados a nivel

nacional.

Definición y documentación de procesos aplicables a la realidad del mercado de desarrollo de software a nivel nacional.

Implementación y estudio de aplicabilidad de los procesos definidos en un caso de

estudio real.

Fase inicial del proceso de creación de un modelo en el marco del convenio FP-

UNA / CTIP

Trabajos futuros

Trabajos futuros

60

Definición total del proceso de desarrollo de proyectos.

Definición de diversos tipos de procesos relacionados indirectamente con el

proceso de desarrollo.

Estudio de un proceso de evaluación formal para los procesos.

Documentaciones de aplicabilidad en otros proyectos

“Modelo de procesos para el desarrollo de software”

Ing. de requerimientos – Análisis - Diseño

Ellen Lujan Méndez Xavier

Gracias por su atención!!

San Lorenzo, 2009

Universidad Nacional de AsunciónFacultad Politécnica

Documents

Ellen Lujan Méndez Xavier Profesor Orientador M.Sc. Luís Gilberto Salinas San Lorenzo, 2009