REPRESENTACIÓN EN EL NÚCLEO DE SEMAT DE PRÁCTICAS

REPRESENTACIÓN EN EL NÚCLEO DE SEMAT DE PRÁCTICAS DE MÉTODOS DE

DESARROLLO BASADOS EN PLANES

Autor:

Ing. Leidy Diana Jiménez Pinzón

Director:

Ph.D. Carlos Mario Zapata Jaramillo

MAESTRÍA EN INGENIERÍA DE SISTEMAS

Universidad Nacional de Colombia

Sede Medellín

2016

DEDICATORIA

A mis padres por su apoyo absoluto en todos los proyectos que me propongo, por sus constantes

palabras, valiosos consejos y por enseñarme a perseguir mis sueños hasta cumplirlos.

A Esteban Arango, por su acompañamiento en todo este proceso, su ayuda y amor incondicional.

AGRADECIMIENTOS

Al docente Carlos Mario Zapata Jaramillo, quien me ha acompañado desde mi proceso de formación

como ingeniera de sistemas, y quien ha contribuido a mi formación personal y profesional durante el

desarrollo de esta Tesis de maestría. En todos estos años me permitió conocer a un excelente

docente y ser humano. Gracias a su paciencia, apoyo invaluable, enseñanzas y críticas constructivas

se hizo posible la realización de esta Tesis.

iv

Contenido

1. INTRODUCCIÓN ............................................................................................................................... 1

1.1 Justificación ......................................................................................................................... 1

1.2 Planteamiento del problema .............................................................................................. 2

1.3 Objetivo general .................................................................................................................. 2

1.4 Objetivos específicos ........................................................................................................... 2

1.5 Metodología ........................................................................................................................ 3

Observación ................................................................................................................. 3

Descripción .................................................................................................................. 3

Revisión ....................................................................................................................... 3

Integración .................................................................................................................. 4

Clasificación ................................................................................................................. 4

Conclusión ................................................................................................................... 4

1.6 Estructura de la Tesis .......................................................................................................... 5

2 MARCO TEÓRICO ......................................................................................................................... 5

2.1 Semat (Software Engineering method and theory) ............................................................. 5

Alfas ............................................................................................................................. 6

Espacios de actividad ................................................................................................ 11

Competencias ............................................................................................................ 12

Elementos del núcleo de Semat ................................................................................ 14

2.2 CDM (Custom Development Method) ............................................................................... 16

Definición de fases, actividades, entregables y responsables .................................. 19

2.3 UNC-Method ..................................................................................................................... 23

Definición de fases, actividades, artefactos y responsables ..................................... 23

2.4 RUP .................................................................................................................................... 25

Disciplinas, actividades, artefactos y roles [9] .......................................................... 28

2.5 Prácticas de ingeniería de software .................................................................................. 29

Desarrollo iterativo ................................................................................................... 30

Gestión de requisitos ................................................................................................ 30

Modelado visual ........................................................................................................ 30

Desarrollo basado en componentes ......................................................................... 30

Verificación continua de la calidad ........................................................................... 31

v

Control de cambios de software ............................................................................... 31

Modelado de objetos de dominio ............................................................................. 31

Visibilidad del progreso y resultados ........................................................................ 31

Establecimiento de actividades para satisfacer las prácticas de calidad requeridas 31

Gestión de valor agregado ........................................................................................ 32

Planificación del proceso ........................................................................................... 32

Suministro de recursos .............................................................................................. 32

Formación del personal ............................................................................................. 32

Monitoreo y control del proceso .............................................................................. 32

Asignación de responsabilidad .................................................................................. 33

Determinación de estimaciones de esfuerzo de trabajo y costo .............................. 33

3 ANTECEDENTES ......................................................................................................................... 33

4 CAPÍTULO 4. PROPUESTA DE SOLUCIÓN ................................................................................... 36

4.1 Representación de las prácticas en el núcleo de Semat ................................................... 36

4.2 Representación gráfica del método CDM ......................................................................... 37

Fase: Definición ......................................................................................................... 41

Fase: Modelado de requisitos ................................................................................... 52

Fase: Diseño de sistema y generación ...................................................................... 55

Fase: Transición a la producción ............................................................................... 58

4.3 Representación gráfica del UNC-Method ......................................................................... 62

Fase: Contexto del software ...................................................................................... 63

Fase: Análisis del problema ....................................................................................... 68

Fase: propuestas de solución .................................................................................... 69

Fase: esquema conceptual ........................................................................................ 70

4.4 Representación gráfica del método RUP .......................................................................... 72

Fase: Inicio ................................................................................................................. 73

Fase: Elaboración ...................................................................................................... 98

Fase: Construcción .................................................................................................. 104

Fase: Transición ....................................................................................................... 109

5 VALIDACIÓN ............................................................................................................................ 117

5.1 Validación del método CDM ........................................................................................... 117

5.2 Validación del UNC-METHOD .......................................................................................... 121

Caso de estudio 1 .................................................................................................... 121

vi

5.3 Validación de RUP ........................................................................................................... 126

6 CONCLUSIONES ....................................................................................................................... 136

7 ANEXOS ................................................................................................................................... 140

FIGURAS

Figura 1. Alfas del núcleo ............................................................................................................ 6

Figura 2. Espacios de actividad del núcleo ......................................................................... 11

Figura 3. Competencias del núcleo ......................................................................................... 13

Figura 4. Estructura de CDM ..................................................................................................... 16

Figura 5. Orden de acción de las tareas de la fase Definición ......................................... 19

Figura 6. Orden de acción de tareas de la fase Modelado de requisitos ............... ¡Error!

Marcador no definido.

Figura 7. Orden de acción de tareas de la fase Diseño de sistema y generación ...... 22

Figura 8. Orden de acción de tareas de la fase Transición a la producción ................ 23

Figura 9. Estructura de RUP ...................................................................................................... 26

Figura 10. Elementos de método RUP .................................................................................... 34

Figura 11. Componentes del método RUP ............................................................................ 34

Figura 12. Artefactos y actividades de la disciplina requisitos ....................................... 35

Figura 13. Resultados del trabajo sobre la estructura RUP en Semat ........................... 36

Figura 14. Práctica del área de conocimiento clientes ...................................................... 37

Figura 15. Prácticas del área de conocimiento solución ................................................... 37

Figura 16. Prácticas del área de conocimiento esfuerzo ................................................... 37

Figura 17. Prácticas de los métodos CDM y PJM ................................................................ 38

Figura 18. Definición de prácticas mediante los alfas ....................................................... 41

Figura 19. Definición de prácticas mediante espacios de actividad .............................. 41

Figura 20. Secuencia de actividades en la fase Definición ............................................... 44

Figura 21. Definición de la práctica Modelado de objetos de dominio .......................... 45

Figura 22. Definición de la práctica Modelado de objetos de dominio .......................... 46

Figura 23. Definición de la práctica Gestión de requisitos ............................................... 47

Figura 24. Definición de la práctica Asignación de responsabilidades ........................ 48

Figura 25. Definición de la práctica Suministro de recursos ........................................... 49

Figura 26. Definición de la práctica Monitoreo y control de recursos ........................... 49

Figura 27. Definición de la práctica Planificación del proceso ........................................ 50

Figura 28. Definición de la práctica Planificación del proceso ........................................ 51

Figura 29. Competencias de los métodos CDM y PJM ...................................................... 61

Figura 30. Roles del método CDM y PJM ............................................................................... 61

Figura 31. Progreso de un proyecto al aplicar la metodología CDM Fast Track ......... 62

Figura 32. Prácticas del UNC-Method ..................................................................................... 62

Figura 33. Secuencia de actividades en la fase contexto del software

........................................................................................................................................................... 65

Figura 34. Representación gráfica de las prácticas Asignación de responsabilidades

y Formación de personal............................................................................................................ 65

vii

Figura 35. Representación gráfica de la práctica Modelado de objetos del dominio 66

Figura 36. Representación gráfica de la práctica Modelado visual ................................ 67

Figura 37. Representación gráfica de la práctica Monitoreo y control del proceso .. 67

Figura 38. Competencias del UNC-Method ........................................................................... 71

Figura 39. Roles del UNC-Method ............................................................................................ 71

Figura 40. Progreso de un proyecto al aplicar el UNC-Method........................................ 71

Figura 41. Mejores prácticas del método RUP ..................................................................... 72

Figura 42. Secuencia de actividades en la fase inicio ........................................................ 79

Figura 43. Representación gráfica de la práctica Gestión de requisitos ...................... 85

Figura 44. Representación gráfica de la práctica Modelado visual ................................ 89

Figura 45. Representación gráfica de la práctica Control de cambios de software... 97

Figura 46. Recursos del método RUP ................................................................................... 115

Figura 47. Competencias del método RUP .......................................................................... 116

Figura 48. Roles del método RUP .......................................................................................... 116

Figura 49. Progreso de un proyecto al aplicar la metodología RUP ............................ 117

Figura 50. Diálogo controlado ................................................................................................ 122

Figura 51. Actividad Desarrollar entrevista interesado-analista y producto de trabajo

Diálogo controlado .................................................................................................................... 122

Figura 52. Esquema pre-conceptual ..................................................................................... 122

Figura 53. Actividad Establecer un vocabulario común y producto de trabajo

Esquema pre-conceptual ......................................................................................................... 122

Figura 54. Organigrama ............................................................................................................ 122

Figura 55. Actividad Identificar los actores internos y externos de la organización y

producto de trabajo Organigrama ......................................................................................... 122

Figura 56. Modelo del dominio ............................................................................................... 123

Figura 57. Actividad Establecer un vocabulario común y producto de trabajo Modelo

del dominio .................................................................................................................................. 123

Figura 58. Actividad Establecer limitaciones del proceso y producto de trabajo

Reglas del negocio .................................................................................................................... 123

Figura 59. Reglas del negocio ................................................................................................ 123

Figura 60. Actividad Caracterizar el dominio del problema y producto de trabajo

Diagrama de procesos .............................................................................................................. 124

Figura 61. Diagrama de procesos .......................................................................................... 124


Tabla explicativa del diagrama de procesos ...................................................................... 124

Figura 63. Tabla explicativa de procesos ............................................................................ 124


Diagrama de objetivos .............................................................................................................. 125

Figura 65. Diagrama de objetivos .......................................................................................... 125


Diagrama causa-efecto ............................................................................................................. 125

Figura 67. Diagrama de causa y efecto ................................................................................ 125

Figura 68. Actividad Desarrollar el diccionario de datos y producto de trabajo

Diccionario de datos ................................................................................................................. 126

Figura 69. Diccionario de datos .............................................................................................. 126

viii

Figura 70. Representación en Semat de actividades, roles y productos de trabajo de

la disciplina requisitos .............................................................................................................. 128


la disciplina gestión de proyectos ......................................................................................... 130


la disciplina análisis y diseño ................................................................................................. 132


la disciplina despliegue ............................................................................................................ 133


la disciplina implementación .................................................................................................. 134


la disciplina entorno .................................................................................................................. 135

TABLAS

Tabla 1. Conceptos principales de Semat ............................................................................... 5

Tabla 2. Estados del alfa Oportunidad ..................................................................................... 7

Tabla 3. (Parte 1/2) Estados del alfa Interesados ................................................................... 7

Tabla 3. (Parte 2/2) Estados del alfa Interesados ................................................................... 8

Tabla 4. Estados del alfa Requisitos ......................................................................................... 8

Tabla 5. Estados del alfa Sistema de software ....................................................................... 9

Tabla 6. (Parte 1/2) Estados del alfa Trabajo........................................................................... 9

Tabla 6. (Parte 2/2) Estados del alfa Trabajo......................................................................... 10

Tabla 7. Estados del alfa Equipo .............................................................................................. 10

Tabla 8. (Parte 1/2) Estados del alfa Forma de trabajo ....................................................... 10

Tabla 8. (Parte 2/2) Estados del alfa Forma de trabajo ....................................................... 11

Tabla 9. (Parte 1/2) Sintaxis gráfica de elementos del núcleo ......................................... 15

Tabla 9. (Parte 2/2) Sintaxis gráfica de elementos del núcleo ......................................... 16

Tabla 10. (Parte 1/2) Fases del modelo CDM ........................................................................ 17

Tabla 10. (Parte 2/2) Fases del modelo CDM ........................................................................ 18

Tabla 11. Tareas, entregables del PJM ................................................................................... 18

Tabla 12. Procesos, tareas, entregables y responsables de la fase Definición .......... 19

Tabla 13. Procesos, tareas, entregables y responsables de la fase Modelado de

requisitos ........................................................................................................................................ 20

Tabla 14. Procesos, tareas, entregables y responsables de la fase Diseño de

sistema y generación .................................................................................................................. 21

Tabla 15. Procesos, tareas, entregables y responsables de la fase Transición a la

producción ..................................................................................................................................... 22

Tabla 16. Fases del UNC-Method ............................................................................................. 23

Tabla 17. Actividades, entregables y responsables en la fase del contexto del

software .......................................................................................................................................... 24

Tabla 18. Actividades, entregables y responsables en la fase análisis del problema.

Síntesis del autor ......................................................................................................................... 24

ix

Tabla 19. Actividades, entregables y responsables en la fase propuestas de

solución .......................................................................................................................................... 25

Tabla 20. Actividades, entregables y responsables en la fase esquema conceptual 25

Tabla 21. Objetivos de las fases del método RUP ............................................................... 27

Tabla 22. (Parte 1/2) Descripción de principales tareas..................................................... 38

Tabla 22. (Parte 2/2) Descripción de principales tareas..................................................... 39

Tabla 23. (Parte 1/2) Descripción de principales entregables .......................................... 39

Tabla 23. (Parte 2/2) Descripción de principales entregables .......................................... 40

Tabla 24. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la

fase definición ............................................................................................................................... 41

Tabla 24. (Parte de 2/4) Espacios de actividad, alfas, productos de trabajo y roles en

la fase definición .......................................................................................................................... 42






fase modelado de requisitos ..................................................................................................... 52






fase diseño de sistema y generación ..................................................................................... 55






fase transición a la producción ................................................................................................ 58







Tabla 28. Descripción de entregables del UNC-Method .................................................... 63

Tabla 29. Espacios de actividad, alfas, productos de trabajo, actividades y roles de

la fase análisis del problema ..................................................................................................... 63






la fase propuestas de solución ................................................................................................ 69

x


la fase esquema conceptual ...................................................................................................... 70

Tabla 33. (Parte 1/2) Descripción de principales artefactos ............................................. 72

Tabla 33. (Parte 2/2) Descripción de principales artefactos ............................................. 73


fase inicio ....................................................................................................................................... 73


fase inicio ....................................................................................................................................... 74


fase inicio ....................................................................................................................................... 75


fase inicio ....................................................................................................................................... 76


fase inicio ....................................................................................................................................... 77


fase inicio ....................................................................................................................................... 78


fase elaboración ........................................................................................................................... 98


fase elaboración ........................................................................................................................... 99

Tabla 35. (Parte3/7) Espacios de actividad, alfas, productos de trabajo y roles en la

fase elaboración ......................................................................................................................... 100





Tabla 35. (Parte 6/7)Espacios de actividad, alfas, productos de trabajo y roles en la


Tabla 35. (Parte 7/7)Espacios de actividad, alfas, productos de trabajo y roles en la



fase construcción ....................................................................................................................... 104












fase transición ............................................................................................................................. 109


fase transición ............................................................................................................................. 110

xi


fase transición ............................................................................................................................. 111


fase transición ............................................................................................................................. 112


fase transición ............................................................................................................................. 113


fase transición ............................................................................................................................. 114


fase transición ............................................................................................................................. 115

Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method 117

Tabla 39. Productos de trabajo asociados a la práctica Modelado de objetos del

dominio ......................................................................................................................................... 118

Tabla 40. Productos de trabajo asociados a la práctica Gestión de requisitos ........ 119

Tabla 41. Productos de trabajo asociados a la práctica Verificación continua de la

calidad ........................................................................................................................................... 119

Tabla 42. Productos de trabajo asociados a la práctica Desarrollo basado en

componentes ............................................................................................................................... 120

Tabla 43. Productos de trabajo asociados a la práctica Desarrollo basado en

componentes ............................................................................................................................... 120

Tabla 44. Roles, artefactos y actividades de la disciplina requisitos .......................... 127

Tabla 45. Roles, artefactos y actividades de la disciplina gestión de proyectos ..... 129

Tabla 46. Roles, artefactos y actividades de la disciplina análisis y diseño .............. 131

Tabla 45. Roles, artefactos y actividades de la disciplina despliegue ......................... 133

Tabla 48. Roles, artefactos y actividades de la disciplina implementación ............... 134

Tabla 49. Roles, artefactos y actividades de la disciplina entorno ............................... 135

ANEXOS

Anexo A. Fase 2 del UNC-Method: Análisis del problema .............................................. 140

Anexo B. Fase 3 del UNC-Method: Propuesta de solución ............................................. 143

Anexo C. Fase 4 del UNC-Method: Esquema conceptual ............................................... 146

Anexo D. Fase 2 del CDM: Modelado de requisitos………………………………………………160

Anexo E. Fase 3 del CDM: Diseño de sistema y generación………………………………….168

Anexo F. Fase 4 de CMD: Transición a la producción……………………………...…………...176

Anexo G. Fase 2 de RUP: Elaboración………………………………………………………………….183

Anexo H. Fase 3 de RUP: Construcción……………………………………………………………….200

Anexo I. Fase 4 de RUP: Transición……………………………………………………………………..215

Anexo J. Validación del UNC-Method: Caso de estudio 2………………………………….....229

xii

RESUMEN

Los ingenieros de software utilizan métodos para asegurar la entrega de un producto de calidad,

respetando el tiempo y presupuesto planteados. La existencia de prácticas replicadas con pequeñas

modificaciones y la separación entre las prácticas industriales y de investigación académica, hacen

que la cantidad de métodos incremente en el tiempo. Generalmente, cuando se adopta un nuevo

método para el desarrollo, los existentes se excluyen completamente sin tener en cuenta que algunas

prácticas pueden ser útiles aún para el desarrollo.

Un determinado método no se adapta a todo tipo de proyecto, sino que cada tipo de proyecto tiene

un método que se ajusta mejor. Actualmente, el uso frecuente de las prácticas y técnicas que un

método define depende de la moda o tendencia de desarrollo del momento. De acuerdo con la

literatura, existen dos tipos de métodos (basados en planes y ágiles) que se diferencian por la forma

de trabajo, la inversión de tiempo y la obtención de herramientas para llevar a cabo el desarrollo del

software. Aun así, son métodos que comprenden prácticas similares.

Semat (Software Engineering Method and Theory) es una iniciativa que responde al llamado de la

acción de los métodos y la teoría de la ingeniería de software, creando un marco de pensamiento

que permite la agrupación de prácticas pertenecientes a distintos métodos, conformando así una

base teórica común con principios probados. Lo anterior con el fin permitir al ingeniero de software

organizar sus propios métodos, utilizando las prácticas de acuerdo a las necesidades de sus

proyectos.

Por ello, en esta Tesis de Maestría se propone la representación en el núcleo de Semat de las

prácticas de tres métodos basados en planes: Rational Unified Process (RUP), Custom Development

Method (CDM) y UNC-METHOD. Así, se definen las prácticas existentes y a ellas se les agregan las

actividades, roles y productos de trabajo propios de cada método, mediante la definición de los alfas,

espacios de actividad y competencias requeridas.

PALABRAS CLAVE: Semat, RUP, CDM, UNC-Method, prácticas, representación gráfica.

xiii

ABSTRACT

Software engineers use methods for ensuring the delivery of a quality, on-time, on-budget product.

The existence of practices replicated with minor modifications and the gap between industry practices

and academic research increase the number of methods over time. Commonly, when a new

development method is adopted, software engineers don’t use more the practices of the previous

methods.

A particular method is unsuitable for all types of projects, since each project type has a method fitting

best. Currently, the frequent use of the practices and techniques for defining a method depends on

either fashion or development trends. Some methods based on plans and some others are agile.

They differ in the way of working, the time invested on development, and the tools they use. Even so,

all of the methods comprise similar practices.

Semat (Software Engineering Method and Theory) is an initiative that allows grouping practices from

different methods to form a base common theoretical with proven principles, thus software engineers

can organizing their own methods and using practices according to the needs of their projects.

Consequently, in this M.Sc. Thesis we propose the representation of practices coming from three

methods based on plans—Rational Unified Process (RUP), Custom Development Method (CDM) and

UNC-METHOD—by using the Semat Essence kernel.

KEY WORDS: Semat, RUP, CDM, UNC-Method, practices, graphical representation.

1

1. INTRODUCCIÓN

1.1 Justificación

La ingeniería de software es una disciplina que comprende el estudio de métodos de desarrollo para

la producción, mantenimiento y creación de la documentación de los sistemas de software. El interés

creciente por definir nuevos métodos y la separación de la industria y la investigación académica,

permiten una amplia existencia de métodos que especifican artefactos, roles, actividades, técnicas

y prácticas para definir una forma de trabajo. Algunos métodos se excluyen completamente cuando

se adopta uno nuevo, sin tener en cuenta que contienen prácticas útiles para el desarrollo, o que los

nuevos métodos sólo proponen prácticas ya existentes con pequeñas modificaciones [1].

En la literatura se encuentran dos tipos de métodos de desarrollo de software: los métodos basados

en planes, que permiten seguir una planificación bien definida del proyecto, considerando los

términos de formación e inversión de tiempo y compra de herramientas como parte de su forma de

trabajo, y los métodos ágiles, que se concentran en el factor humano, dándole más importancia a la

colaboración del cliente y al desarrollo incremental con iteraciones muy cortas, plazos reducidos,

requisitos volátiles y aplicación de nuevas tecnologías [2]. Sin embargo, en ambos tipos de métodos

se asegura la generación de un producto de calidad, por lo cual comparten algunas prácticas

similares [3].

Los equipos requieren encontrar un balance entre las entregas, la satisfacción del interesado y la

forma de trabajar al momento de desarrollar software. Por ello, requieren de una marco de

pensamiento como Semat (Software Engineering Method and Theory), una iniciativa que existe como

una base teórica, que agrupa prácticas de distintos métodos de desarrollo de software definidas con

los mismos elementos. Así, se permite que, a partir del entendimiento de las bases de la ingeniería

de software, las prácticas se midan y comparen, logrando que los desarrolladores puedan

representar métodos exactamente de manera que se adapten a sus fines. Lo anterior implica que,

en algunos casos, la representación y aplicación parcial de un método sea suficiente para el

desarrollo de software [1] [4].

Por ello, surge la necesidad de estudiar los métodos de desarrollo existentes, para su inclusión en

el núcleo de Semat. En esta Tesis de Maestría se propone la representación de métodos basados

en planes como CDM (Custom Development Method), RUP (Rational Unified Process) y UNC-

Method, identificando las prácticas que tienen en común y asociando a éstas prácticas ya existentes

de otros métodos con sus actividades correspondientes. De esta forma se logra la unificación y

complementación de las prácticas mediante la representación de los alfas, los productos de trabajo

y espacios de actividad asociados, las etapas del ciclo de vida de un producto de software (requisitos,

2

análisis, diseño, codificación, prueba, implementación y mantenimiento), la especificación de roles

con la asignación de funciones [5] y habilidades para llevar a cabo las actividades definidas en cada

metodología.

1.2 Planteamiento del problema

En Semat, un método es una definición de lo que se debe hacer y una guía activa para un equipo y

su forma de trabajo. En cualquier momento durante el desarrollo de software, el método se puede

consultar para definir qué hacer a continuación. Además, el método se puede ajustar en cualquier

momento y regresar a pasos anteriores para saber qué hacer a continuación, en caso que se deba

reevaluar el proceso de desarrollo de software [4].

La existencia de distintos métodos de desarrollo se debe a que los equipos buscan una forma de

producir mejor el software, por lo que se generan nuevas ideas o se modifican prácticas existentes

para la definición de nuevos métodos. Semat conforma una base teórica que agrupa prácticas

definidas bajo los mismos elementos, lo cual permite unificar las prácticas existentes y que los

desarrolladores puedan crear sus propios métodos de acuerdo con lo que necesiten. De allí la

importancia de incluir en el núcleo de Semat los métodos de desarrollo existentes.

1.3 Objetivo general

Representar en el núcleo de Semat las prácticas comunes de tres métodos basados en planes (RUP,

CDM y UNC-Method) que posibilite su comparación e integración para el desarrollo de aplicaciones

de software.

1.4 Objetivos específicos

Caracterizar la estructura de los métodos de desarrollo basados en planes tales como RUP,

CDM y UNC-Method.

Identificar en cada metodología los elementos esenciales de la ingeniería de software como

los artefactos, actividades y roles.

Identificar las prácticas comunes de los métodos de desarrollo de software basados en

planes que se puedan representar en el núcleo de Semat.

Diferenciar los siguientes conceptos: método, práctica, actividad, alfa, estado, competencia

y espacio de actividad.

Representar los elementos estudiados de la estructura de los métodos escogidos con los

elementos del núcleo de Semat.

Validar con un estudio de laboratorio las representaciones del objetivo específico anterior.

3

1.5 Metodología

La metodología que se utiliza para llevar a cabo los objetivos específicos planteados en esta Tesis

comprende las siguientes fases:

Observación

Observación del comportamiento, partes y componentes del objeto de estudio:

En este caso se tienen cuatro diferentes objetos de estudio: Semat, RUP, CDM y UNC-Method. Para

esta fase es importante recolectar toda la información posible. Por ello, para esta Tesis se toman en

consideración las siguientes fuentes o tipos de documentos: Artículos, ponencias, revistas

electrónicas y páginas web oficiales.

Al final de esta primera fase se debe tener un conocimiento pleno de Semat y todos los elementos

de su núcleo y de la estructura de los tres métodos basados en planes escogidos para su

representación en el núcleo de Semat.

El objetivo específico por alcanzar con esta fase es:

Caracterizar la estructura de los métodos de desarrollo basados en planes tales como RUP,

CDM y UNC-Method.

Descripción

Identificación de todos los elementos, partes y componentes para poder entender los objetos de

estudio:

Con la fase anterior, se conocen los elementos del núcleo de Semat que se utilizarán en la

representación. Así, en esta fase se pretende identificar los elementos de los tres métodos. Como

son métodos basados en planes, tienen una estructura similar, es decir, sus elementos son los

siguientes: fases, artefactos, actividades y roles. En este paso, se deben identificar los elementos en

cada uno de los métodos de manera ordenada para su representación en el núcleo.


Identificar en cada metodología los elementos esenciales de la ingeniería de software como

los artefactos, actividades y roles.

Revisión

Revisión rigurosa de cada uno de los elementos de un todo:

En Semat existen diferentes símbolos que representan los elementos esenciales de la ingeniería de

software. En la fase anterior se identificaron las actividades, fases, roles y artefactos de los métodos.

4

Aparte de estos elementos, se deben estudiar los demás elementos que componen el núcleo de

Semat: método, práctica, alfa, estado, competencias y espacio de actividad.


Diferenciar los siguientes conceptos: método, práctica, actividad, alfa, estado, competencia

y espacio de actividad.

Integración

Integración de los componentes a fin de identificarlos, registrarlos y establecer sus relaciones con

los demás:

Al identificar la finalidad de los elementos de Semat en la fase anterior, se debe profundizar sobre

cada una de las clasificaciones o categorías que contienen algunos elementos como los alfas, los

espacios de actividades y las competencias.

Esta fase se hace con el fin de reconocer la finalidad de cada una de las clasificaciones, para, más

adelante, poder relacionar los elementos de los métodos y las categorías de estos elementos.

Clasificación

Ordenación de cada una de las partes por clases para conocer sus características, detalles y

comportamiento:

En esta fase ya se conocen los elementos de los métodos, los elementos de Semat y se entiende la

finalidad de cada uno de los elementos del núcleo. Por lo tanto, en este paso se pretende identificar

las prácticas de los tres métodos que se van a representar en Semat.

El objetivo específico por alcanzar en esta fase es:

Identificar las prácticas comunes de los métodos de desarrollo de software basados en

planes que se van a representar en Semat.

Conclusión

Analizar los resultados obtenidos:

Teniendo claros los elementos de cada uno de los objetos de estudio, en esta fase se realiza la

representación con la sintaxis gráfica de Semat. Los objetivos específicos por alcanzar en esta fase

son:

Representar los elementos estudiados de la estructura de los métodos escogidos con los

elementos del núcleo de Semat.

Validar con un estudio de laboratorio las representaciones del objetivo específico anterior.

5

1.6 Estructura de la Tesis

Esta Tesis se organiza de la siguiente manera: en el Capítulo 2 se presenta el Marco Teórico

relacionado con la sintaxis gráfica de los elementos del núcleo de Semat y los métodos basados en

planes como Custom Development Method (CDM), Rational Unified Process (RUP) y UNC-Method;

en el Capítulo 3 se describen las distintas representaciones gráficas que ya existen en la literatura

de los métodos basados en planes sujetas a estudio; en el Capítulo 4 se propone la representación

de las prácticas de los métodos CDM, RUP y UNC-Method; en el Capítulo 5 se presenta la validación

de la representación propuesta y, finalmente, en el Capítulo 6 se plantean las conclusiones obtenidas

y se presenta el trabajo futuro que se puede derivar de esta Tesis.

2 MARCO TEÓRICO

2.1 Semat (Software Engineering method and theory)

Semat es una iniciativa de Ivar Jacobson, Bertrand Meyer y Richard Soley [1]. Este marco de

pensamiento muestra que, a partir del análisis de todos los métodos desarrollo, se pueden definir

elementos comunes, es decir, se puede definir un núcleo con “las cosas con las que se trabaja” y

“las cosas que siempre se hacen” en el desarrollo de software. Semat tiene dos objetivos principales:

encontrar un núcleo de elementos ampliamente aceptados y definir una base teórica sólida, con el

propósito de redefinir la forma en que las personas trabajan con los métodos de desarrollo de

software. Así, se permite la definición de medidas que no dependan de las prácticas para evaluar la

calidad del software y los métodos que se utilizan para producirlo, la composición y comparación de

prácticas que se puedan definir y aplicar de manera independiente (así su origen sea diverso) que

se ajusten a las necesidades ya sea de la organización, de un proyecto o equipo de trabajo [1].

Semat incluye algunos conceptos principales [4], que se pueden visualizar en la Tabla 1:

Tabla 1. Conceptos principales de Semat. Extraído de Jacobson et al. [4]

Descripción Símbolo

Método Un método se define como una composición de prácticas y es dinámico debido a que soporta las actividades diarias durante el desarrollo de software.

Práctica

Una práctica se define como un enfoque que se repite con un propósito específico y a su vez proporciona una forma de verificar cualquier aspecto del trabajo que se realiza. Por lo cual una práctica puede pertenecer a distintos métodos.

Núcleo El núcleo se genera a partir de métodos. Los métodos específicos contienen las prácticas y éstos se incluyen en el núcleo.

Lenguaje Sirve para definir los métodos, las prácticas y los elementos del núcleo.

6

El núcleo de Semat se describe usando un pequeño conjunto de elementos, los cuales se agrupan

en tres áreas de conocimiento: cliente, solución y esfuerzo. Cada área de conocimiento se enfoca

en un aspecto específico de la ingeniería de software y se distingue con un color, el cual permite

comprender, a nivel gráfico, la relación de las áreas de conocimiento con cada uno de los elementos

agrupados en ellas. Los elementos que componen cada una de las áreas de conocimiento y que, a

su vez, definen el núcleo son: alfas, espacios de actividad y competencias [4].

Alfas

Los alfas se pueden definir como la representación de las “cosas esenciales para trabajar” y proveen

una descripción de la clase de cosas que un equipo debe gestionar, usar y producir en cualquier

esfuerzo de desarrollo de software. Un alfa representa un indicador crítico para monitorear y seguir

una línea de progreso que mide la salud del proyecto (véase la Figura 1). Esto se logra debido a que

un alfa se caracteriza con un conjunto de estados, donde cada estado tiene una lista de chequeo

que especifica los criterios necesarios para alcanzar un estado [4].

Figura 1. Alfas del núcleo [1]

En el área de conocimiento cliente, el equipo necesita comprender los interesados, lo que incluye:

Alfa Oportunidad: “Es el conjunto de circunstancias adecuado para desarrollar o modificar un

sistema de software. La oportunidad articula la razón para la creación de lo nuevo o modificado

del sistema de software”. En la Tabla 2 se especifican sus estados y listas de chequeo.

7

Estado Lista de chequeo

Identificado

• Se identificó una oportunidad que una solución basada en un software podía tratar

• Un interesado quiere hacer una inversión en un mejor valor potencial de comprensión

• Se identificaron otros interesados que quieren compartir la oportunidad

Con solución requerida

• Se confirmó la necesidad de una solución basada en software • Se identificaron las necesidades de los interesados • Se identificaron los problemas y las causas raíz subyacentes • Se propuso al menos una solución basada en software

Con valor establecido

• El valor de tratar la oportunidad se cuantificó en términos absolutos o en los retornos o de ahorros por periodo de tiempo (por ejemplo, por año)

• El impacto de la solución de los interesados se entiende • El valor que el sistema de software ofrece a las partes interesadas que

financian y utilizan el sistema de softwareLos criterios de éxito para juzgar el sistema de software son claros

• Los resultados deseados que se requieren de la solución son claros y cuantificados

Viable

• Se esbozó una solución • Las indicaciones y la solución se pueden desarrollar y desplegar dentro de las

restricciones • Los riesgos son manejables

Tratada

• Se produjo una solución que trata la oportunidad de forma demostrable • Un sistema usable está disponible • Los interesados acuerdan el despliegue de valor • La solución que satisface los interesados trata la oportunidad

Con beneficio acumulado

• El uso operacional están creando beneficios tangibles • El perfil de retorno de la inversión es al menos tan bueno como se anticipó

Tabla 2. Estados del alfa Oportunidad. Extraído de Jacobson et al. [4]

Alfa Interesados: “Las personas, grupos u organizaciones que afectan o se afectan con un

sistema de software. Los interesados proporcionan la oportunidad y son la fuente de los

requisitos y la financiación para el software sistema”. En la Tabla 3 se especifican sus estados y

listas de chequeo:


Reconocido • Se identificaron los interesados • Existe un acuerdo entre los grupos de interesados que se van a representar • Se definieron las responsabilidades de los representantes de los interesados

Representado

• Se citaron los representantes de los interesados • Los representantes de los interesados aceptan las responsabilidades y los

autorizaron • Se acordó el enfoque de la colaboración • Los representantes aceptan la forma de trabajo

Involucrado

• Los representantes de los interesados aceptan sus responsabilidades • Los representantes de los interesados entregan retroalimentación y

participan de las decisiones temporales • Los representantes de los interesados se comunican inmediatamente con el

grupo de interesados

Tabla 3. (Parte 1/2) Estados del alfa Interesados. Extraído de Jacobson et al. [4]

8


De acuerdo • Los representantes de los interesados están de acuerdo en que el equipo valora y respeta su ingreso

• Los representantes de los interesados están de acuerdo en el balance de las diversas prioridades

• Los representantes de los interesados están de acuerdo con un mínimo de expectativas de despliegue

Satisfecho para despliegue

• Los representantes de los interesados proveen retroalimentación sobre el sistema desde la perspectiva del grupo de interesados

• Los representantes de los interesados confirman que el sistema está listo para el despliegue

Satisfecho en uso

• El sistema alcanzó o excedió las expectativas mínimas de los interesados • Las necesidades y expectativas de los interesados se están cumpliendo

Tabla 3. (Parte 2/2) Estados del alfa Interesados. Extraído de Jacobson et al. [4]

En el área de conocimiento solución, el equipo necesita establecer los requisitos e implementar,

construir, probar y mantener un sistema de software que cumpla con ellos, incluyendo:

Alfa Requisitos: “Lo que el sistema de software debe hacer para tratar la oportunidad y satisfacer

a los interesados”. En la Tabla 4 se especifican sus estados y listas de chequeo.


Concebido • La necesidad de un nuevo sistema es clara • Se identificaron los usuarios • Se identificaron los promotores iniciales

Acotado

• Se acordaron el propósito y la extensión del sistema • Los criterios de éxito son claros • Se acordaron los mecanismos para manejar los requisitos • Se identificaron las restricciones y suposiciones

Coherente

• La visión general es clara y la comparten todos los involucrados • Se explicaron importantes escenarios de uso • Las prioridades son claras • Se trataron los conflictos • Se comprende el conflicto

Aceptable • Los requisitos describen una solución aceptable para los interesados • La tasa de cambio para acordar requisitos es baja • El valor es claro

Tratado • Suficientes requisitos se implementaron para que el nuevo sistema se acepte • Los interesados acuerdan que el sistema vale la pena realizando trabajo

operativo

Cumplido • El sistema satisface completamente los requisitos y las necesidades • No hay ítems excepcionales que impidan que el sistema se considere

completo

Tabla 4. Estados del alfa Requisitos. Extraído de Jacobson et al. [4]

Alfa Sistema de software: “Un sistema se compone de software, hardware y los datos que

proporciona el valor primario de la ejecución del software”. En la Tabla 5 se especifican sus

estados y listas de chequeo.

9


Con arquitectura seleccionada

• Se seleccionó la arquitectura que trata los riesgos técnicos clave • Se acordaron los criterios para seleccionar la arquitectura • Se seleccionaron las plataformas, tecnologías y lenguajes • Se tomaron las decisiones de compra, construcción y reuso

Demostrable • Se demostraron las características clave de la arquitectura • Los interesados relevantes acordaron que la arquitectura es apropiada • Se ejercieron la interfaz crítica y las configuraciones del sistema

Usable

• El sistema es usable y tiene las características de calidad deseadas • Los usuarios pueden operar el sistema • Se aceptaron los niveles de defectos • Se conoció el contenido de liberación

Listo

• Se puso a disposición la documentación de usuario • Los representantes de los interesados aceptaron el sistema • Los representantes de los interesados quieren que se haga operacional el

sistema

Operacional

• El sistema se usó en un ambiente operacional • El sistema está disponible para los usuarios previstos • Al menos un ejemplo del sistema es completamente operacional • El sistema es compatible con los niveles de servicio acordados

Retirado • No se da más soporte al sistema • No se producirán más actualizaciones al sistema • Se reemplazó o se descontinuó el sistema

Tabla 5. Estados del alfa Sistema de software. Extraído de Jacobson et al. [4]

En el área de conocimiento esfuerzo, se tienen que establecer el equipo y su forma de trabajo y se

tiene que hacer el trabajo, incluyendo:

Alfa Trabajo: “Actividad que implica un esfuerzo mental o físico realizado con el fin de lograr un

resultado. En el contexto de la ingeniería de software, el trabajo es todo lo que hace el equipo

para cumplir con las metas de producción de un sistema de software que coincida con los

requisitos”. En la Tabla 6 se especifican sus estados y listas de chequeo.


Iniciado

• Se conoce el iniciador del trabajo • Se aclaran las restricciones del trabajo • Se aclaran el patrocinio y el modelo de financiación • Se aclara la prioridad del trabajo

Preparado

• Se estimaron el costo y el esfuerzo • La financiación y los recursos trabajan en su lugar • Se comprendieron los criterios de aceptación • Se acordaron los procedimientos de gobierno • Se comprendió la exposición al riesgo • Se aclararon las dependencias

Comenzado

• Se comenzó el trabajo de desarrollo • Se monitoreó el proceso de desarrollo • Se hizo la división en ítems accionables con una clara definición • Los miembros del equipo están aceptando y progresando en los ítems de

trabajo

Tabla 6. (Parte 1/2) Estados del alfa Trabajo. Extraído de Jacobson et al. [4]

10


Bajo control • El trabajo va bien; se están manejando los riesgos • El trabajo y el re-trabajo no planteados están bajo control • Se completaron lo ítems de trabajo dentro de los estimados • Se hizo seguimiento de las mediciones

Concluido • Se terminó el trabajo que produce resultados • Se están consiguiendo los resultados de trabajo • El cliente aceptó el sistema de software resultante

Cerrado • Todas las tareas de limpieza remanentes se completaron y el trabajo se cerró oficialmente

• Todo se archivó • Se dispone de lecciones aprendidas y de métricas

Tabla 6. (Parte 2/2) Estados del alfa Trabajo. Extraído de Jacobson et al. [4]

Alfa Equipo: “Un grupo de personas que participa activamente en el desarrollo, mantenimiento o

entrega de un sistema de software”. En la Tabla 7 se especifican sus estados y listas de chequeo.


Sembrado

• La misión del equipo es clara • El equipo sabe cómo crecer para lograr su misión • Se identificaron las competencias requeridas • Se determinó el tamaño del equipo

Formado

• El equipo tiene suficientes recursos para iniciar la misión • Se comprendieron la organización del equipo y las responsabilidades

individuales • Los miembros saben cómo ejecutar el trabajo

Colaborando

• Los miembros están trabajando como una unidad • La comunicación es abierta y honesta • Los miembros se enfocan en la misión del equipo • El éxito del equipo se antepone a los objetivos personales

Ejecutando

• El equipo está trabajando eficiente y efectivamente • Se adapta al contexto cambiante • Se producen salidas de alta calidad • Se realizan mínimos retrocesos y marchas atrás • Se eliminó continuamente el desperdicio

Suspendido • El equipo ya no cuenta • Se entregaron las responsabilidades • Los miembros están disponibles para otras asignaciones

Tabla 7. Estados del alfa Equipo. Extraído de Jacobson et al. [4]

Alfa Forma de trabajo: “El conjunto adaptado de prácticas y herramientas que utiliza un equipo

de orientar y apoyar su trabajo”. En la Tabla 8 se especifican sus estados y listas de chequeo.


Con principios establecidos

• Se establecieron los principios y restricciones • Se comprometieron los principios y restricciones • Se acordaron las prácticas y herramientas • Se comprendió el contexto en que el equipo debe operar

Tabla 8. (Parte 1/2) Estados del alfa Forma de trabajo. Extraído de Jacobson et al. [4]

11


Con bases establecidas

• Prácticas clave y herramientas listas • Se analizaron y comprendieron las brechas entre prácticas y herramientas • Se analizaron y comprendieron las brechas de capacidad • Se integraron las prácticas seleccionadas y las herramientas

En uso • Algunos miembros del equipo están usando la forma de trabajo • Se inspeccionó regularmente el uso de prácticas y herramientas • Los procedimientos están en su lugar para manejar retroalimentación

En su lugar • Todos los miembros del equipo están usando la forma de trabajo • Todos los miembros tienen acceso a las prácticas y herramientas para hacer

su trabajo • El equipo completo se involucró en la inspección y adaptación de la forma de

trabajo

Trabajando bien

• La forma de trabajo está trabajando bien para el equipo • Los miembros del equipo están progresando según el plan • El equipo aplica naturalmente prácticas sin pensar en ellas • Las herramientas soportan naturalmente la forma de trabajo

Retirado • El equipo no usa más la forma de trabajo • Se compartieron las lecciones aprendidas para uso futuro

Tabla 8. (Parte 2/2) Estados del alfa Forma de trabajo. Extraído de Jacobson et al. [4]

Espacios de actividad

Los espacios de actividad complementan los alfas, ya que proporcionan el conjunto de actividades

esenciales que normalmente se hacen en ingeniería de software (véase la Fig. 2) [4].

Figura 2. Espacios de actividad del núcleo [1]

En el área de conocimiento clientes, el equipo tiene que entender la oportunidad y hacer participar a

los interesados:

Explorar las posibilidades: “explorar las posibilidades que presenta la creación de un nuevo o

mejorado sistema de software. Esto incluye el análisis de la oportunidad por abordar y la

identificación de los interesados”.

12

Comprender las necesidades de los interesados: “colaborar con los interesados para conocer

sus necesidades y garantizar los resultados. Esto incluye la identificación y el trabajo con los

representantes de los interesados para avanzar en la oportunidad”.

Asegurar la satisfacción de los interesados: “compartir los resultados de la labor de desarrollo

con los interesados que pueden aportar su aceptación del sistema producido y verificar que la

oportunidad se aborde con éxito”.

Utilizar el sistema: “Observar el uso del sistema en un entorno real y beneficiar a los interesados”.

En el área de conocimiento solución, el equipo tiene que desarrollar una solución apropiada para

aprovechar la oportunidad y satisfacer los interesados:

Comprender los requisitos: “comprender lo que el sistema producido debe hacer”.

Darle forma al sistema: “darle forma al sistema de modo que sea fácil de desarrollar, modificar y

mantener. Esto incluye el diseño general”.

Implementar el Sistema: “construir un sistema mediante la implementación, pruebas e

integración de uno o más elementos del sistema. Esto incluye la corrección de errores y pruebas

unitarias”.

Probar el sistema: “verificar que el sistema producido cumple con los requisitos de los

interesados”.

Desplegar el sistema: “tomar el sistema probado y hacer que esté disponible para su uso fuera

del equipo de desarrollo”.

Operar el sistema: “Apoyar el uso del sistema de software en el entorno de producción”.

En el área de conocimiento esfuerzo, se tiene que formar el equipo tiene y avanzar el trabajo de

acuerdo con la forma de trabajo:

Prepararse para hacer el trabajo: “establecer el equipo y su entorno de trabajo. Entender y

comprometerse a completar el trabajo”.

Coordinar actividades: “coordinar y dirigir el trabajo del equipo. Esto incluye la planificación del

trabajo y reconfiguración del equipo”.

Apoyar el equipo: “ayudar a los miembros del equipo para ayudarse a sí mismos, colaborar y

mejorar su forma de trabajar”.

Seguimiento del progreso: “medir y evaluar los progresos realizados por el equipo”.

Finalizar el trabajo: “finalizar el esfuerzo de ingeniería de software”.

Competencias

Las competencias representan las habilidades clave que se requieren para el desarrollo de software

[4] y se muestran en la Figura 3.

13

Figura 3. Competencias del núcleo. Traducido de [4]

En el área de conocimiento cliente, el equipo tiene que ser capaz de demostrar una clara

comprensión del negocio y de algunos aspectos técnicos de su dominio. Además, debe tener la

capacidad de comunicar con precisión las opiniones de sus interesados.

Representación del interesado: “esta competencia encapsula la capacidad de recopilar,

comunicar y balancear las necesidades de otras partes interesadas y con precisión representar

sus puntos de vista”.

En el área de conocimiento solución el equipo tiene que ser capaz de capturar y analizar las

necesidades, de construir y operar un sistema de software que cumple con los requisitos.

Análisis: “esta competencia encapsula la capacidad de entender las oportunidades, las

necesidades de sus interesados y transformarlas en un conjunto de requisitos consistente”.

Desarrollo: “esta competencia encapsula la capacidad de diseñar y programar sistemas de

software de forma eficaz, siguiendo las reglas y normas que acuerda el equipo”.

Pruebas: “esta competencia encapsula la posibilidad de probar un sistema, verificando que es

usable y que cumple los requisitos”.

En el área de conocimiento esfuerzo, el equipo tiene que ser capaz de organizarse y gestionar su

carga de trabajo.

Liderazgo: “esta competencia permite a una persona inspirar y motivar a un grupo de personas

para lograr éxito en su trabajo y cumplir sus objetivos”.

Gestión: “esta competencia encapsula la capacidad de coordinar, planificar y realizar un

seguimiento del trabajo que realiza un equipo”.

14

Elementos del núcleo de Semat

La sintaxis gráfica del lenguaje de Semat proporciona una forma visual para cada uno de sus

elementos, donde cada uno de estos elementos corresponde a un aspecto específico de un núcleo

o método, tal como se muestra a continuación [4]. Adicionalmente, se presentan elementos del

lenguaje necesarios para la asociación entre algunos elementos del núcleo (véase la Tabla 9).

2.1.4.1 Producto de trabajo

Un producto de trabajo es un artefacto de valor y relevancia para un esfuerzo de la ingeniería de

software. Es una concreta representación de un alfa como resultado de un esfuerzo y, en algunos

casos, es necesario como entrada para un esfuerzo posterior. Puede ser de diferentes tipos como

modelos, documentos, código, especificaciones, pruebas y ejecutables, entre otros.

2.1.4.2 Actividad

Una actividad define una o más clases de productos de trabajo y una o más clases de tareas, y

brinda una guía sobre cómo se usan estos elementos cuando se utiliza una práctica.

2.1.4.3 Patrón

Un patrón es una descripción de una estructura en una práctica.

2.1.4.4 Asociación del alfa

Una asociación de un alfa se visualiza como una línea continua para conectar dos alfas. La línea

puede tener uno o más segmentos.

2.1.4.5 Sucesor de estados

Una asociación de sucesor de estados se visualiza como una línea sólida con una flecha abierta que

conecta un estado con su sucesor. La línea puede tener uno o más segmentos conectados.

2.1.4.6 Alpha Containment

Un alpha containment se visualiza como una línea continua vertical para conectar un alfa con un

subalfa con un diamante relleno en la punta hacia el lado del alfa.

2.1.4.7 Manifiesto de producto de trabajo

Un manifiesto de producto de trabajo se visualiza como una línea continua horizontal para conectar

un alfa con un producto de trabajo con un diamante relleno en la punta hacia el lado del alfa. La línea

puede tener uno o más segmentos pero los productos de trabajo se deben ubicar al mismo nivel. Se

puede hacer uso de los límites que siguen la estructura (“<Límite inferior>..<Límite superior>”) y se

deben ubicar hacia el lado del producto de trabajo.

2.1.4.8 Asociación de actividad (“Parte de”)

Una asociación de actividad se visualiza como una línea continua horizontal para conectar un

espacio de actividad con una actividad con un diamante relleno en la punta hacia el lado del espacio

15

de actividad. La línea puede tener uno o más segmentos pero las actividades se deben ubicar al

mismo nivel.

2.1.4.9 Asociación de actividad (NO “Parte de”)

Una asociación de actividad se visualiza como una línea sólida (puede ser curva) con una punta

triangular que conecta dos actividades y/o espacios de actividades. La línea puede tener uno o más

segmentos conectados.

2.1.4.10 Asociación de patrón

Una asociación de patrón se visualiza como una línea sólida con punta de diamante relleno hacia el

lado del patrón, originada desde un círculo que se conecta a su vez con cada uno de los elementos

asociados con el patrón. El nombre de la asociación se pone dentro del círculo.

Elemento Símbolo Ejemplo

Producto de trabajo

Actividad

Patrón

Asociación de alfas

Sucesor de estados

Alpha Containment

Manifiesto de producto de trabajo

Tabla 9. (Parte 1/2) Sintaxis gráfica de elementos del núcleo. Extraído de Jacobson et al. [4]

16

Elemento Símbolo Ejemplo

Asociación de actividad (“Parte de”)

Asociación de actividad (“No Parte de”)

Asociación de patrón

Tabla 9. (Parte 2/2) Sintaxis gráfica de elementos del núcleo. Extraído de Jacobson et al. [4]

2.2 CDM (Custom Development Method)

CDM es un método de desarrollo diseñado para modelar aplicaciones de software durante cuatro

fases que comprenden el ciclo de vida del método. Tal como se puede ver en la Figura 4, CDM tiene

asociados once procesos [6]:

Figura 4. Estructura de CDM. Traducido de [6]

17

Los modelos utilizados en CDM se encuentran agrupados en tareas y las tareas se agrupan en

procesos. Un conjunto de procesos conforman una fase y cada proceso se puede asociar con una

tarea requisito previo y tiene un resultado clave que surge luego de ejecutar el proceso [7].

En la Tabla 10 se especifican los objetivos de cada fase del método.

Fase Descripción

Definición

En esta fase se establece una base sólida y viable para el proyecto. Los objetivos de esta fase son:

Obtener un claro entendimiento de los beneficios empresariales que el nuevo sistema debe alcanzar.

Identificar el promotor del proyecto.

Definir el alcance del proyecto, partir y priorizar el alcance.

Determinar los plazos, actividades, productos y recursos necesarios.

Identificar los desarrolladores que van a participar en el proyecto.

Identificar adecuadamente al usuario embajador que va a participar durante todo el ciclo de vida del proyecto.

Educar al promotor, el usuario embajador y otros interesados, explicarles el impacto en la organización, los respectivos papeles y responsabilidades en el proyecto.

Crear un equipo de proyecto que integren los desarrolladores y el usuario embajador.

Desarrollar procesos de negocio de alto nivel, la función y los modelos de datos.

Modelado de Requisitos

Se busca capturar los modelos de los procesos del negocio que describe el usuario. Los objetivos de esta fase son:

Acordar un aspecto común de la aplicación.

Establecer normas de generación de código inicial.

Obtener conocimiento detallado de los procesos de negocios, funciones e información para cumplir con los objetivos de negocio.

Generar un prototipo funcional con los acuerdos del usuario embajador para comunicar la comprensión de los desarrolladores.

Acordar la estrategia de validación detallada y participación de los usuarios durante todo el proyecto, comprobando su disponibilidad.

Diseño de Sistema y Generación

En esta fase se especifica el diseño del sistema y se realiza la entrega de una aplicación que cumpla de manera óptima con los requisitos del negocio. Los objetivos de esta fase son:

Reiterativamente, producir una base de datos física y los módulos de la aplicación.

Obtener mejoras a las exigencias del usuario embajador durante cada iteración.

Precisar los datos y modelos de funcionamiento.

Entregar documentación inicial para colaborar con el usuario embajador en la validación del sistema de aplicación.

Definir las futuras mejoras para una mayor funcionalidad.

Tabla 10. (Parte 1/2) Fases del modelo CDM [6]

18

Fase Descripción

Transición a la Producción

Se obtiene del usuario la aceptación del nuevo sistema. Los objetivos de esta fase son:

Facilitar la validación de la preproducción, a fin de confirmar que los requisitos de negocio se cumplieron.

Completar documentación técnica y operativa.

Proporcionar un corte suave a la nueva aplicación.

Gestionar el desarrollo.

Supervisar el rendimiento del sistema de producción y resolver los problemas detectados.

Tabla 10. (Parte 2/2) Fases del modelo CDM [6]

CDM Fast Track utiliza el Método de Gestión de Proyectos (PJM) de Oracle™ para proporcionar un

marco en el que los proyectos se pueden planificar, estimar, controlar y hacer seguimiento de una

manera consistente. En la Tabla 11 se encuentran las tareas y productos de trabajos asociados que

realiza el gerente del proyecto durante su ejecución:

Tarea Entregables

Recordar y revisar planes de proyecto

Plan de gestión del alcance del proyecto

Estrategias de control y presentación de informes, normas y procedimientos

Plan de gestión de proyectos

Trabajo de las estrategias de gestión, normas y procedimientos

Plan de trabajo

Plan de financiación

Las estrategias de gestión de los recursos, normas y procedimientos

Dotación de personal y plan de su organización

Guía de la orientación proyecto

Organización preparada

Plan de recursos físicos

Infraestructura preparada

Estrategias de gestión de la calidad, normas y procedimientos

Gestión de la configuración, estrategias, normas

Realizar auditoría de calidad Auditoría de calidad

Lanzar recursos físicos Lanzamiento de recursos físicos

Realizar evaluación de calidad Reporte de calidad

Auditar entregables principales Línea base auditada

Aceptar seguridad del cliente del proyecto

Aceptación del cliente

Lanzar personal Personal lanzado

Lanzar recursos físicos Recursos físicos

Concluir gestión de la configuración Preparación de la gestión de producción

Tabla 11. Tareas, entregables del PJM [6]

19

Definición de fases, actividades, entregables y responsables

2.2.1.1 Fase: Definición

En la Tabla 12 se especifican los procesos, tareas, entregables y responsables de esta fase. El orden

de acción de las tareas se muestra en la Figura 5.

Proceso Tarea Entregables Responsable

Definición de requisitos del

negocio

Implementar las normas de definición de requisitos y directrices

Normas de definición de requisitos del negocio y directrices

Desarrollador principal de la aplicación

Crear el modelo de proceso del contexto

Modelo de proceso del contexto


Documentar la estructura actual y futura de la organización

Definición de la estructura actual y futura de la organización


Obtener descripciones del negocio de alto nivel

Descripciones del negocio de alto nivel


Desarrollar glosario Glosario Desarrollador

Examen de sistemas existentes

Obtener material de referencia ya existente

Material de referencia ya existente

Desarrollador

Crear modelo de alto nivel del Sistema de datos existente

Modelo de alto nivel del sistema de datos existente

Desarrollador

Crear el modelo de proceso del sistema existente

Modelo de proceso del sistema existente


Arquitectura Técnica

Definir la arquitectura del sistema

Definición de la arquitectura del sistema

Desarrollador principal del sistema

Documentación Especificar documentación de requisitos

Documentación de requisitos

Escritor técnico

Pruebas Determinar los requisitos de pruebas

Requisitos de pruebas Tester principal

Formación Lanzar el proyecto Equipo de Proyecto Integrado

Gerente de Proyecto

Tabla 12. Procesos, tareas, entregables y responsables de la fase Definición [6]

Figura 5. Orden de acción de las tareas de la fase Definición. Traducido de [6]

20

2.2.1.2 Fase: Modelado de Requisitos





negocio

Crear modelo detallado del proceso de negocio

Modelo detallado del proceso de negocio

Desarrollador

Recopilar información detallada del negocio

Información detallada del negocio

Desarrollador

Construir modelo de datos del negocio

Modelo de datos del negocio Desarrollador

Validar prototipo funcional Prototipo funcional validado Usuario embajador

Redefinir requisitos Lista MoSCoW redefinida Usuario embajador

Arquitectura técnica

Definir los requisitos operacionales detallados del sistema

Requisitos operacionales detallados del sistema


Crear arquitectura técnica Arquitectura Técnica Desarrollador principal del sistema

Determinar problemas de rendimiento

Problemas de rendimiento Desarrollador principal del sistema

Diseño y construcción de la base de datos

Implementar normas base de datos y directrices

Normas de la base de datos y directrices


Crear diseño lógico de base de datos

Diseño lógico de base de datos


Desarrollo de la aplicación

Diseñar aplicación Diseño de la aplicación Desarrollador principal de la aplicación

Crear entorno de desarrollo inicial

Entorno de desarrollo inicial Gerente de configuración

Desarrollar prototipo funcional

Prototipo funcional Desarrollador

Conversión de datos

Definir estrategia de conversión de datos

Estrategia de conversión de datos

Desarrollador

Tabla 13. Procesos, tareas, entregables y responsables de la fase Modelado de requisitos [6]

21

Figura 6. Orden de acción de tareas de la fase Modelado de requisitos. Traducido de [6]

2.2.1.3 Fase: Diseño de Sistema y Generación



Tabla 14. Procesos, tareas, entregables y responsables de la fase Diseño de sistema y

generación. Elaboración propia del autor basado en [6]



negocio

Redefinir los requisitos Lista MoSCoW redefinida Usuario embajador

Revisar modelos de requisitos

Modelo de requisitos del negocio rested

Desarrollador

Arquitectura técnica

Desarrollar la definición de hardware y software

Definición de hardware y software


Desarrollar arquitectura de distribución

Arquitectura de distribución Desarrollador principal del sistema

Desarrollar estrategia de reserva y recuperación

Estrategia de reserva y recuperación


Diseño y construcción de la base de datos

Crear esquema de autorización de objetos de base de datos

Esquema de autorización de objetos de base de datos


Crear diseño físico de la base

Diseño físico de la base Desarrollador principal del sistema

Desarrollo de la aplicación

Desarrollar (grupo de) módulos

Módulos documentados Desarrollador

Estrenar aplicación Código de la aplicación Desarrollador principal de la aplicación

Pruebas

Crear escenarios de prueba Escenarios de pruebas Tester principal

Crear modelo de prueba de la arquitectura del sistema

Modelo de prueba de la arquitectura del sistema

Tester principal

22

Figura 7. Orden de acción de tareas de la fase Diseño de sistema y generación. Traducido de

[6]

2.2.1.4 Fase: Transición a la Producción




Conversión de datos

Limpieza de los datos Datos limpios Administrador de los datos del cliente

Convertir y verificar los datos de producción

Datos convertidos y verificados Líder de equipo de conversión de datos

Documentación

Completar referencia del usuario

Referencia del usuario Usuario embajador

Completar guía de usuario

Guía de usuario Usuario embajador

Completar referencia técnica

Referencia técnica detallada Escritor técnico

Completar guía operacional del sistema

Guía operacional del sistema Desarrollador principal del sistema

Generar texto de ayuda en línea

Texto de ayuda en línea Desarrollador

Pruebas Realizar validación preproducción

Resultados de la validación preproducción

Coordinador de validación

Formación

Entrenar administradores

Administradores entrenados Entrenador

Entrenar equipo de validación

Equipo de validación entrenado Entrenador

Tabla 15. Procesos, tareas, entregables y responsables de la fase Transición a la

producción. Elaboración propia del autor basado en [6]

23

Figura 8. Orden de acción de tareas de la fase Transición a la producción. Traducido de [6]

2.3 UNC-Method

UNC-Method (método de la Universidad Nacional de Colombia para el desarrollo de software basado

en problemas) mezcla una lista de objetos bien conocidos (como los diagramas de UML y las

interfaces gráficas de usuario) y los enfoques no tradicionales (por ejemplo, diagrama de causa y

efecto, diagramas de objetivos de KAOS y los esquemas preconceptuales) utilizados en el intento

de superar los problemas [8].

En la Tabla 16 se especifican las cuatro fases que este método comprende [9]:

Fase Descripción

Contexto del software En esta fase se capturan, entienden y representan gráficamente actores, objetivos, responsabilidades, funciones y estructura de lo relacionado con el problema

Análisis del problema En esta fase se detallan las funciones principales de la organización, problemas y objetivos

Propuestas de solución En esta fase el equipo debe proponer un conjunto de soluciones para los problemas de la organización

Esquema conceptual En esta fase el equipo específica y prepara el proceso de diseño del sistema

Tabla 16. Fases del UNC-Method. Elaboración propia del autor basado en [9]

Definición de fases, actividades, artefactos y responsables

En esta Sección se especifican los elementos de UNC-METHOD considerados para el desarrollo de

un sistema de software [9]:

2.3.1.1 Fase: Contexto del software

En la Tabla 17 se especifican las actividades, entregables y responsables de esta fase.

24

Actividades Entregables Responsable

Desarrollar entrevista interesado-analista

Archivos digitales Analista Interesado Director del proyecto Diálogo controlado

Revisar documentación Archivos digitales Analista

Interesado Diálogo controlado

Resumir la información relacionada con los actores, los objetos y las funciones

Tarjetas de educción Analista

Identificar los actores internos y externos en la organización

Organigrama Analista

Realizar tabla de trazabilidad documental

Tabla de trazabilidad documental Analista

Establecer un vocabulario común

Esquema preconceptual Analista

Esquemas preconceptuales ejecutables Analista

Modelo del dominio Analista

Gestionar la elaboración de tareas

Tablero Kanban Analista

Reportar el progreso del proyecto

Reporte de avance de los alfas Analista

Explicar el método Guía UNC-Method Director del proyecto

Definir roles y responsabilidades

Lista de roles y responsabilidades Director del proyecto

Tabla 17. Actividades, entregables y responsables en la fase del contexto del software.

Síntesis del autor. Elaboración propia del autor basado en [10]

2.3.1.2 Fase: Análisis del problema

En la Tabla 18 se especifican las actividades, entregables y responsables de esta fase.


Establecer reglas del negocio

Reglas del negocio Analista

Caracterizar el dominio del problema

Tabla explicativa del diagrama de procesos

Analista

Diagrama de procesos Analista

Diagrama de objetivos Analista

Diagrama causa-efecto Analista

Desarrollar el diccionario de datos

Diccionario de datos Analista





Tabla 18. Actividades, entregables y responsables en la fase análisis del problema. Síntesis

del autor. Elaboración propia del autor basado en [10]

25

2.3.1.3 Fase: Propuestas de solución En la Tabla 19 se especifican las actividades, entregables y responsables de esta fase.


Desarrollar nuevo organigrama

Organigrama Analista

Desarrollar nuevo diagrama de procesos

Diagrama de procesos Analista

Especificar la funcionalidad de la aplicación de software

Casos de uso Analista

Diagrama de flujo de interfaz de usuario

Analista

Establecer el valor de la solución

Estimación del valor de la solución Analista

Tabla explicativa del diagrama de procesos

Analista

Establecer factores críticos de éxito

Factores críticos de éxito Analista

Hoja de vida del indicador Analista





Tabla 19. Actividades, entregables y responsables en la fase propuestas de solución.

Síntesis del autor. Elaboración propia del autor basado en [10]

2.3.1.4 Fase: Esquema conceptual En la Tabla 20 se especifican las actividades, entregables y responsables de esta fase.



Especificaciones basadas en el esquema preconceptual

Analista

Diagrama de clases Analista

Diagramas de comunicación Analista

Diagramas de máquina de estados Analista

Proporcionar las bases para la construcción de la aplicación final

Ejemplo de código fuente Desarrollador

Desarrollar prototipo Alfa Prototipo Alfa Desarrollador





Tabla 20. Actividades, entregables y responsables en la fase esquema conceptual. Síntesis

del autor. Elaboración propia del autor basado en [10]

2.4 RUP

RUP es un método que integra los aspectos que se requieren durante el proceso de desarrollo de

software para el análisis, desarrollo y documentación de sistemas orientados a objetos. Este método

26

proporciona un acercamiento disciplinado a la asignación de tareas y responsabilidades de un

proyecto en una organización [11]. Con el método RUP se realiza un levantamiento exhaustivo de

requisitos, se busca detectar defectos en las fases iniciales, intentando reducir al número de cambios

tanto como sea posible, se realiza el análisis y diseño del sistema y se intenta anticipar futuras

necesidades [12].

Las características principales de RUP son [13]:

Guiado por casos de Uso: el método describe la secuencia completa de interacciones entre el

usuario y el sistema.

Centrado en arquitectura: Comprende las diferentes vistas del sistema en desarrollo, las cuales

corresponden a los modelos del sistema, como los modelos de casos de uso, de análisis, de

diseño, de despliegue e implementación.

Iterativo e Incremental: una iteración se compone de los requisitos, el análisis, el diseño, la

implementación y las pruebas. Cada iteración sólo entrega una parte pequeña pero funcional del

sistema, los requisitos y modelos se desarrollan de forma progresiva.

Desarrollo basado en componentes: la creación de sistemas de software requiere la división del

sistema en componentes definidas.

Lenguaje de modelado único: se adopta UML para el desarrollo de todos los modelos.

Proceso integrado: RUP establece una estructura que abarca ciclos, fases, flujos de trabajo,

mitigación de riesgos, control de calidad y gestión de proyectos.

El proceso del RUP se ejecuta en tres perspectivas [11] [14] [15], tal como se aprecia en la Figura 9:

Figura 9. Estructura de RUP [15]

27

La perspectiva estática contiene los siguientes elementos:

Rol: individuo o grupo de individuos que llevan a cabo actividades y producen artefactos.

Actividad: es una unidad de trabajo que realiza un rol.

Artefacto: es un trozo de información que un proceso produce, modifica o usa. Es un producto

tangibles de un proyecto y se va creando y usando hasta obtener el producto final.

Flujo de trabajo: define la secuencia de actividades que realizan los roles.

La perspectiva dinámica contiene las fases del modelo sobre el tiempo. En la Tabla 21 se especifican

los objetivos de cada fase del método.

Fase Descripción

Inicio

En esta fase se identifican las entidades externas que interactúan con el sistema y sus respectivas iteraciones. Los objetivos principales de esta fase son:

Establecer el alcance del proyecto de software y las condiciones, incluyendo un concepto operacional, criterios de aceptación y descripciones de lo que debe ser parte o no del producto.

Discriminar los casos de uso críticos del sistema, es decir, los escenarios principales de la conducta que impulsarán la funcionalidad del sistema.

Proponer al menos una arquitectura candidata contra algunos de los escenarios principales.

Estimar el costo total y el calendario para todo el proyecto.

Estimar los riesgos.

Elaboración

Tiene como fin desarrollar un entendimiento del dominio del problema, crear un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riesgos clave. Al finalizar esta fase, se debe tener el modelo de requisitos del sistema (UML), una arquitectura y un plan de desarrollo. Los objetivos principales de esta fase son:

Definir y validar la línea base.

Definir la línea base de la visión.

Definir la línea base de un plan de alta fidelidad para la fase de construcción.

Demostrar que la arquitectura de referencia apoyará la visión a un costo y tiempo razonable.

Construcción

Su objetivo es el diseño del sistema, la programación, las pruebas y la integración de todas las partes del sistema software. Al final de esta fase se debe tener un software operativo con su respectiva documentación. Los objetivos principales de esta fase son:

Minimizar los costos de desarrollo optimizando recursos.

Lograr la adecuada calidad tan rápido como sea posible.

Lograr versiones ejecutables (alfa, beta y otras) tan rápido como sea posible.

Transición

En esta fase, el sistema de software se entrega a los interesados para sus respectivas pruebas en un entorno real. Al terminar esta fase, se debe tener un software documentado y funcionando correctamente. Los objetivos principales de esta fase son:

Lograr soporte a usuarios.

Lograr la participación de las partes interesadas.

Lograr la línea base del producto final lo más rápido y rentable como sea posible.

Tabla 21. Objetivos de las fases del método RUP. Elaboración propia del autor basado en

[16]

28

Disciplinas, actividades, artefactos y roles [16]

Este método presenta nueve disciplinas: modelo empresarial, requisitos, análisis y diseño,

implementación, pruebas, despliegue, gestión de cambios de configuración, gestión de proyectos y

entornos (véase la Fig. 9). A lo largo de las cuatro fases de RUP se presentan actividades, roles y

artefactos necesarios en el desarrollo del proyecto.

2.4.1.1 Fase: Inicio

Dentro de esta fase, los roles realizan las siguientes actividades esenciales:

Formular el alcance del proyecto, es decir, captar el contexto, las necesidades importantes

y las limitaciones para cumplir los criterios de aceptación del producto final.

Planificar y preparar un caso de negocio y evaluar alternativas para la gestión de riesgos, la

dotación de personal, el plan de proyecto y las compensaciones entre costos, el cronograma

y la rentabilidad.

Sintetizar una arquitectura candidata.

En esta fase se producen, esencialmente, los siguientes artefactos:

Documento de visión: una visión general de los requisitos del proyecto, características clave

y limitaciones principales

Modelo de casos de uso: enumera todos los casos de uso y actores que se pueden identificar

en la primera etapa

Glosario inicial del proyecto

Caso de negocio inicial:

o Contexto de negocios

o Criterios de éxito

o Previsión financiera

Evaluación inicial de riesgos

Plan de proyecto: muestra las fases e iteraciones

2.4.1.2 Fase: Elaboración

Las actividades esenciales de la fase de elaboración son las siguientes:

Elaborar la visión, una comprensión sólida que se establece de los casos de uso críticos que

impulsan las decisiones arquitectónicas y de planificación.

Elaborar el proceso, la infraestructura y el entorno de desarrollo y alistar las herramientas.

Elaborar arquitectura y seleccionar los componentes. Los componentes de arquitectura

seleccionados se integran y evalúan respecto de los escenarios principales.

En esta fase se producen esencialmente los siguientes artefactos:

Modelo de casos de uso (por lo menos 80% completo)

29

Requisitos adicionales: capturan los requisitos no funcionales y los requisitos que no se

asocian con un caso de uso específico

Descripción de la arquitectura software

Prototipo de arquitectura ejecutable

Lista de riesgos revisada y el caso de negocio revisado

Plan de desarrollo para el proyecto

Caso de desarrollo actualizado: especifica el proceso que se utilizará

Manual de usuario preliminar (opcional)

2.4.1.3 Fase: Construcción


Gestionar los recursos y especificar el control de los recursos y la optimización de procesos.

Desarrollar los componentes completamente y las pruebas definidas en la evaluación de

criterios.

Evaluar las versiones de los productos con los criterios de aceptación.

En esta fase se producen, esencialmente, los siguientes artefactos:

Producto de software integrado en las plataformas adecuadas

Manual de usuario

Descripción de la versión actual

2.4.1.4 Fase: Transición


Implementar ingeniería, es decir, paquetes comerciales, producción y despliegue de ventas.

Capacitar el personal.

Corregir errores y mejorar el rendimiento y la usabilidad.

Evaluar las líneas base de despliegue descritas en la visión y los criterios de aceptación para

el producto.

2.5 Prácticas de ingeniería de software

El método RUP define las seis mejores prácticas para el desarrollo de software, las cuales se definen

a continuación [3] [14] [17]:

30

Mejores prácticas de RUP

2.5.1.1 Desarrollo iterativo

El enfoque iterativo permite una comprensión creciente del problema mediante refinamientos

sucesivos, llegando a una solución efectiva luego de múltiples iteraciones acotadas en complejidad.

Adicionalmente, ayuda a atacar los riesgos mediante la producción de versiones ejecutables

progresivas y frecuentes que permiten la opinión e involucramiento del usuario. Por medio de las

iteraciones que generan las versiones ejecutables, se logran detectar en forma temprana los

desajustes e inconsistencias entre los requisitos, el diseño, el desarrollo y la implementación del

sistema, manteniendo al equipo de desarrollo enfocado en producir resultados.

2.5.1.2 Gestión de requisitos

La práctica de gestión de requisitos permite adquirir, organizar y documentar cómo funciona el

sistema, incluyendo sus restricciones. La gestión de requisitos permite:

Analizar el problema de interesado

Comprender las necesidades del interesado

Manejar el alcance del proyecto

Definir el sistema

Establecer y mantener un acuerdo entre el interesado y el equipo de trabajo en relación con

los requisitos cambiantes

Utilizar los casos de uso y los escenarios ayuda a capturar los requisitos funcionales, asegurar el

diseño, implementación y prueba del sistema, logrando así que el sistema satisfaga las necesidades

del usuario.

2.5.1.3 Modelado visual

Esta práctica permite modelar software visualmente para capturar el diseño del software, es decir, la

estructura y el comportamiento de arquitecturas y componentes. Las abstracciones visuales ayudan

a comunicar diferentes aspectos del software mejorando la comunicación en el equipo; comprender

los requisitos, ver como los elementos del sistema se relacionan entre sí y mantener la consistencia

entre diseño e implementación. El estándar UML (Lenguaje de Modelado Unificado), es la base para

un modelado visual exitoso.

2.5.1.4 Desarrollo basado en componentes

Esta práctica describe cómo diseñar una arquitectura flexible, que se acople con los cambios,

comprensible intuitivamente y que origine una más efectiva reutilización del software. Esta práctica

permite obtener el control intelectual del proyecto con el fin de mantener la complejidad e integridad

del mismo. El propósito es disminuir los riesgos de desempeño, capacidad y confiabilidad.

31

2.5.1.5 Verificación continua de la calidad

Durante el desarrollo de software es necesario evaluar la calidad de un sistema respecto de sus

requisitos de funcionalidad. Los artefactos que producen las actividades se deben evaluar cuando

se generan y al finalizar cada iteración, ya que la calidad del producto implica construirlo

correctamente y que sea admisible para el interesado. La actividad fundamental es el testing, el cual

permite encontrar las fallas antes de la puesta en producción. Esta práctica permite la planeación,

diseño, implementación, ejecución y evaluación de todos los tipos de testing.

2.5.1.6 Control de cambios de software

Esta práctica describe cómo controlar, encontrar y monitorear los cambios durante el desarrollo

iterativo del software de forma exitosa. Es una guía que permite establecer espacios para cada

desarrollador, proporcionando el aislamiento de los cambios hechos en otros espacios mientras se

controlan los cambios de todos los elementos del software. Esta práctica permite conocer cómo

automatizar la integración y administrar las versiones.

Prácticas de la metodología FDD (Feature Driven Development)

La metodología define mejores prácticas reconocidas en la industria para el desarrollo de software

orientado a funcionalidades. Algunas de esas prácticas se definen a continuación [3] [18]:

2.5.2.1 Modelado de objetos de dominio

Esta práctica consiste en explorar y explicar el dominio del problema a resolver. El modelado

resultante provee un marco de trabajo global en el cual agregar funcionalidades.

2.5.2.2 Visibilidad del progreso y resultados

Son frecuentes, apropiados y específicos reportes de progresos a todos los niveles organizativos,

dentro y fuera del proyecto, basándose en el trabajo o partes terminadas, lo cual permite a los

gerentes o directores dirigir correctamente el proyecto.

Prácticas de Software Quality Assurance (SQA)

Según Galin [19], Software Quality Assurance “comprende un conjunto de acciones necesarias para

proporcionar la confianza de que el proceso de desarrollo de software o mantenimiento de un

producto de sistema de software se ajusta a los requisitos establecidos durante su permanencia

dentro de la programación y el presupuesto”. A continuación, se especifica una de sus prácticas [20]:

2.5.3.1 Establecimiento de actividades para satisfacer las prácticas de calidad requeridas

Esta práctica tiene asociadas las siguientes subprácticas que la definen:

Actividades para revisar la calidad de los productos generados al final de cada fase de

desarrollo del software.

32

Actividades para revisar la calidad de los productos generados al final de cada cambio

producido en mantenimiento.

Actividades para administrar el control de cambios durante el desarrollo y mantenimiento.

Práctica de Project Management Body of Knowledge (PMBOK)

PMBOK establece que realizar el análisis del valor agregado es "un método objetivo para medir el

desempeño del proyecto en lo referente al alcance, tiempo y costo". PMI incluye el estándar del

método del valor agregado como práctica para la dirección de proyectos [21].

2.5.4.1 Gestión de valor agregado

La gestión del valor agregado es una técnica de gestión de proyectos que permite establecer el

presupuesto y el calendario de ejecución para controlar la ejecución de un proyecto.

Prácticas CMMI

CMMI (Capability Maturity Model Integration) es un modelo de madurez de mejora de los procesos

para el desarrollo de productos y servicios. Comprende las mejores prácticas que abarcan las

actividades de desarrollo y mantenimiento del ciclo de vida del proyecto [22] [23].

2.5.5.1 Planificación del proceso

El propósito de esta práctica genérica es determinar lo que se requiere para realizar un proceso y

alcanzar los objetivos establecidos durante el desarrollo del proyecto, mediante la realización de

planes y descripciones del proceso.

2.5.5.2 Suministro de recursos

El propósito de esta práctica genérica es asegurar que los recursos que son necesarios durante el

desarrollo del proyecto o proceso, que se definan en el plan, se encuentren disponibles cuando se

requieran. Los recursos incluyen instalaciones físicas y herramientas apropiadas.

2.5.5.3 Formación del personal

Es una práctica genérica que comprende el área de la planificación del proyecto. El propósito es

asegurar que las personas del equipo tengan habilidades y experiencia para llevar a cabo las

actividades del proceso mediante una formación apropiada. Dentro de esta práctica se realiza la

práctica específica “Planificar el conocimiento y habilidades necesarias”.

2.5.5.4 Monitoreo y control del proceso

El propósito de esta práctica genérica es realizar el monitoreo y control del proceso a diario, lo cual

implica medir atributos del proceso o de los productos de trabajo para tener una visibilidad apropiada

del proyecto. Esta práctica se encuentra definida en las siguiente subprácticas:

Evaluar el progreso y rendimiento reales. Revisar los logros y resultados del proceso.

33

Revisar las actividades, el estado y los resultados del proceso.

Identificar y evaluar los efectos de las desviaciones importantes dentro del plan

Identificar problemas.

Tomar acciones correctivas cuando no se satisfacen los requisitos.

2.5.5.5 Asignación de responsabilidad

Es una práctica genérica que asegura que existen responsabilidades para realizar un proceso, con

las cuales se logran resultados durante el desarrollo del proyecto. Esta práctica presenta las

siguientes subprácticas:

Asignar la responsabilidad y la autoridad en su totalidad para realizar el proceso.

Asignar la responsabilidad y la autoridad para realizar las tareas específicas del proceso.

Confirmar que las personas a las que se les asignó responsabilidad y autoridad las

comprenden y las aceptan.

2.5.5.6 Determinación de estimaciones de esfuerzo de trabajo y costo

Esta práctica establece estimaciones de esfuerzo y costo mediante la estimación de atributos de

productos de trabajo y tareas, estableciendo tiempos entre tareas y los riesgos que el proyecto

incluya. Algunos productos típicos de trabajo de esta práctica son:

Estimación racional.

Estimaciones del esfuerzo para el proyecto.

Estimaciones del costo del proyecto.

3 ANTECEDENTES

Las representaciones de la estructura de RUP existentes en la literatura presentan, en general, la

jerarquización de los elementos del método, con el fin de dar a entender el funcionamiento del

método de forma general. Por ello, estas representaciones especifican los elementos y la interacción

entre los mismos, tal como se puede apreciar en la Figuras 10 y 11, donde se visualiza la estructura

de RUP pero no se especifican todos los elementos del método.

34

Figura 10. Elementos de método RUP. Traducido de [15]

RUP consta de elementos como fases, las cuales comprenden disciplinas. Cada una de las

disciplinas agrupa actividades que se dividen en tareas, mientras las tareas se dividen en pasos. Los

diferentes roles son los encargados de llevar a cabo las tareas y de producir y utilizar los artefactos

correspondientes a cada tarea [15].

Figura 11. Componentes del método RUP. Traducido de [24]

Sin embargo, estas representaciones se enfocan únicamente en la visualización de los elementos

del método que conforman la estructura de RUP y la relación entre los mismos. En ambas

representaciones, el nivel de especificación de elementos es menor.

35

En la literatura se encontraron otras representaciones donde se pueden visualizar los elementos de

los métodos, como los artefactos y las actividades con las que se asocian (véase la Fig. 12).

Figura 12. Artefactos y actividades de la disciplina requisitos. Traducido de [15]

Sin embargo, como RUP se divide en disciplinas, se muestran las representaciones de cada una por

separado y este trabajo se enfocan únicamente en la disciplina de requisitos y modelado empresarial.

Adicionalmente, se encontró una representación de RUP con los elementos del núcleo de Semat.

Tal como se puede ver en la Figura 13, en este trabajo se caracterizan las seis mejores prácticas

propuestas en la metodología de acuerdo con las tres áreas de interés que Semat define. Se define

la asociación a la práctica “Develop Software Iteratively” los alfas asociados y definen los alfas

“Opportunity”, “Software system” y “Way of working” mediante los productos de trabajo que se

generan, de acuerdo con las actividades que especifica el método. Sin embargo, en este trabajo no

se representa el método completo, sino una parte específica de RUP. Adicionalmente, sólo se

presenta la secuencia de actividades en la representación propia del método y no con los elementos

del núcleo de Semat. Tampoco se incluyen las competencias requeridas para cada actividad ni la

definición de la práctica mediante los espacios de actividad.

36

Figura 13. Resultados del trabajo sobre la estructura RUP en Semat [25]

CDM consta de elementos como fases. Cada fase es un conjunto de procesos, cada proceso es un

conjunto de tareas y las tareas se pueden clasificar como tareas requisito o tareas resultantes de

acuerdo al proceso que se ejecute. Del método CDM no se encontraron representaciones gráficas

de los elementos que lo componen. Sin embargo, existe la representación de dos dimensiones que

permite visualizar algunos elementos del método, tal como se aprecia en la Figura 5, donde se

identifican los procesos y las fases del método.

Del UNC-Method, no se encontraron representaciones gráficas de sus elementos en la literatura.

4 CAPÍTULO 4. PROPUESTA DE SOLUCIÓN

4.1 Representación de las prácticas en el núcleo de Semat

A continuación, se presenta la caracterización de las prácticas encontradas en la literatura, de

acuerdo con las áreas propuestas en el estándar de Semat.

En el área de conocimiento cliente se incluye a los interesados, por lo cual la práctica perteneciente

a este grupo se muestra en la Figura 14:

37

Figura 14. Práctica del área de conocimiento clientes. Elaboración propia del autor.

En el área de conocimiento solución, el equipo necesita establecer los requisitos e implementar,

construir, probar y mantener un sistema de software, por lo cual las prácticas pertenecientes a este

grupo se muestran en la Figura 15:

Figura 15. Prácticas del área de conocimiento solución. Elaboración propia del autor.

En el área de conocimiento esfuerzo, se tiene que establecer el equipo, su forma de trabajo y se

tiene que hacer el trabajo, por lo cual las prácticas pertenecientes a este grupo se muestran en la

Figura 16:

Figura 16. Prácticas del área de conocimiento esfuerzo. Elaboración propia del autor.

4.2 Representación gráfica del método CDM

Para realizar la representación de los distintos conceptos del método CDM Fast Track con los

elementos del núcleo de Semat, se proponen las siguientes especificaciones:

Una tarea en CDM, al generar un servicio o entregable, se representa en Semat como una

actividad.

38

Un entregable, por su definición, se representa en Semat como un producto de trabajo.

El responsable es el rol en Semat, el cual se representa mediante el símbolo patrón.

Debido a que en la literatura no se encuentran especificadas las prácticas del método CDM, se

propone la asociación con prácticas de la ingeniería de software ya existentes para su inclusión en

el núcleo de Semat. El conjunto de actividades asociadas con los productos de trabajo y las

actividades de este método se visualizan en la Figura 17.

Figura 17. Prácticas de los métodos CDM y PJM. Elaboración propia del autor.

A continuación, se presentan las actividades, el rol que las realiza y los productos de trabajo por

fases, organizados en tablas (véanse las Tablas 24, 25, 26 y 27). Además, se muestra la asociación

con los alfas cuyos estados se afectan al realizar cada actividad. Se especifica el espacio de

actividad al que pertenece cada actividad establecida en la metodología CDM y en la metodología

de gestión de proyectos PJM. Adicionalmente, se propone la representación con los elementos del

núcleo de Semat.

Para llevar a cabo esta representación se toma en consideración la descripción de actividades y

productos de trabajo, los cuales se definen en la Tabla 22 y en la Tabla 23 respectivamente.

Actividad Descripción

Detallar el negocio y objetivos del sistema

Si la organización del cliente estableció un programa de reutilización, se deben escoger asesores.


Se pueden buscar las normas actuales de construcción de modelos y directrices que, o bien se utilizan en toda la empresa o se usaron en un proyecto anterior.

Documentar las interfaces del sistema existente

Obtener información acerca de las interfaces existentes para la identificación de las oportunidades de reutilización.

Obtener arquitectura técnica existente

Obtener información acerca de los componentes del sistema existente y arquitecturas de red que puede reutilizar.

Crear arquitectura técnica Al crear la arquitectura técnica, debe decidir qué componentes reutilizados se integrarán y cómo se encajan en la arquitectura.

Tabla 22. (Parte 1/2) Descripción de principales tareas. Elaboración propia del autor

basado en [10]

39

Actividad Descripción


Buscar normas y directrices existentes de bases de datos utilizadas en la empresa, en proyectos actuales o anteriores.

Desarrollar prototipo look and feel

No se debe relacionar con el dominio del negocio; se deben reutilizar módulos de un proyecto anterior, si es posible.


Describir cualquier compra de componentes

Diseñar módulos de conversión de datos

Se deben tratar de reutilizar los scripts y programas.

Desarrollar listas de chequeo de prueba del módulo

Obtener y adaptar las listas existentes y tipos de módulos que se probarán en el proyecto.

Tabla 22. (Parte 2/2) Descripción de principales tareas Elaboración propia del autor

basado en [10]

Producto de trabajo Descripción

Negocio y objetivos del sistema

Documento en el que consten los beneficios empresariales que el cliente quiere ganar de la solución.

Modelo de proceso del contexto

El modelo de proceso, las unidades de negocio, las áreas funcionales y las relaciones entre estos ámbitos.

Lista de alto nivel MoSCoW Lista de ponderación y en orden de prioridad de los procesos de negocio y de las principales funciones de la empresa.

Procesos de particiones de alto nivel del negocio y funciones

Descripción de cómo el sistema se está partiendo.

Material de referencia ya existente

Materiales de referencia que se relacionan con los objetivos empresariales del proyecto.

Interfaces del sistema existente

Informe con la lista de interfaces del sistema existente.

Plan de capacidad existente Plan con los requisitos actuales y futuros de capacidad de almacenamiento en disco y la infraestructura en general.


Se definen los requisitos de hardware y software del proyecto y entornos de producción.

Conversión de datos de los requisitos

Descripciones de alto nivel para cada uno de los sistemas de origen y los requisitos funcionales para convertir y cargar los datos.

Documentación de requisitos Documentación que se necesitará durante y al final del proyecto.

Requisitos de pruebas Requisitos para la realización de pruebas. Son los requisitos para el proceso de desarrollo en lugar del sistema que se está produciendo.

Equipo de proyecto integrado Equipo de desarrolladores, usuarios, administradores y participantes en el proyecto que entienden el proyecto y sus funciones.

Modelo detallado del proceso de negocio

Modelo de los acontecimientos y de los procesos de negocio necesarios para cumplir con los objetivos empresariales definidos.

Modelo detallado de la función del negocio

Jerarquía de funciones incluyendo sus descripciones basadas en las descripciones del negocio.

Prototipo funcional validado Prototipo generado con las decisiones de los espacios de trabajo y las peticiones de cambio registradas.

Lista MoSCoW redefinida Lista detallada de prioridades que cambia durante las iteraciones si los usuarios cambian sus prioridades.

Tabla 23. (Parte 1/2) Descripción de principales entregables. Elaboración propia del autor

basado en [10]

40

Producto de trabajo Descripción

Descripción de la función del sistema existente

Un informe completo de las descripciones de las funciones correspondientes al sistema existente.

Modelo de datos del sistema existente

Definición y modelo entidad-relación de la estructura lógica de la información del sistema actual.

Descripción de procedimientos operacionales existentes

Informe con las copias de la documentación del cliente y de los procedimientos existentes relevantes para el nuevo sistema.

Arquitectura técnica Hardware, software, herramientas y requisitos de configuración necesarios para apoyar el desarrollo y la validación.

Problemas de rendimiento Los requisitos cuantitativos para mejorar el rendimiento del sistema.

Prototipo look and feel Prototipo funcional que sólo se crea con el fin de lograr un acuerdo sobre el aspecto de la aplicación.

Plan de trabajo de conversión de datos

Plan de trabajo para la conversión de datos.

Requisitos de formación Los tipos de capacitación (cursos formales, talleres o tutoriales) que se deben preparar para el nuevo sistema.

Modelo de requisitos del negocio rested

La combinación de la salida de tareas: crear modelo detallado del proceso de negocio, recopilar información detallada del negocio, construir modelo de datos del negocio y construir modelo detallado de la función del negocio.

Datos convertidos y verificados

Datos de producción convertidos y verificados. Debe incluir todo lo que sea necesario para la aplicación en producción.

Referencia del usuario Descripciones detalladas de la utilización de cada función del sistema.

Guía de usuario Guía de procedimiento completa para el uso de la aplicación para responder a todos los eventos de negocios.

Referencia técnica detallada Describe los componentes técnicos de la aplicación. Se utiliza en el mantenimiento de la aplicación.

Guía de operaciones del sistema

Guía completa que contiene las tareas y procedimientos requeridos para mantener el sistema operando y funcionando para los usuarios.

Resultados de la validación de preproducción

Una declaración de usuario que confirma que el sistema está listo para ir a producción. Los usuarios aceptan el nuevo sistema, la conversión de datos y documentación, para su uso en producción.

Capacitación de los usuarios Los usuarios capacitados para utilizar el nuevo sistema tienen sesiones de entrenamiento y pueden resolver nuevos problemas de negocio.

Capacitación de administradores

Los administradores del sistema, los administradores de la base de datos y personal de operaciones que son capaces de mantener el sistema día a día y con éxito.

Sistema en producción Los usuarios tienen acceso y el negocio se está ejecutando en el nuevo sistema.

Plan de mejora Manejo de mejoras funcionales y no funcionales.

Tabla 23. (Parte 2/2) Descripción de principales entregables [10]

Las prácticas asociadas con este método se definen mediante alfas y espacios de trabajo, tal como

se puede ver en las Figuras 18 y 19, respectivamente.

41

Figura 18. Definición de prácticas mediante los alfas

Figura 19. Definición de prácticas mediante espacios de actividad

Fase: Definición

En la Tabla 24 se presentan los productos de trabajo, actividades y roles de esta fase asociados con

los alfas y espacios de actividad que Semat propone.

Espacio de actividad

Alfa Producto de trabajo Actividad Rol

Explorar posibilidades

Oportunidad, Interesados



Promotor del proyecto

Oportunidad Modelo de proceso del contexto

Crear el modelo de proceso del contexto


Oportunidad Modelo de proceso de negocio de alto nivel

Crear el modelo de proceso de negocio de alto nivel


Tabla 24. (Parte 1/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase

definición. Elaboración propia del autor.

42




Oportunidad Descripciones del negocio de alto nivel

Obtener descripciones del negocio de alto nivel


Oportunidad


Documentar la estructura actual y futura de la organización


Oportunidad Modelo compuesto de función del negocio

Crear el modelo compuesto de función del negocio


Oportunidad Modelo de datos del negocio de alto nivel

Crear el modelo de datos del negocio de alto nivel


Oportunidad Procesos divididos de alto nivel del negocio y funciones

Definir las particiones Gerente de proyecto

Comprender las necesidades de los interesados

Interesados Lista de alto nivel MoSCoW

Crear lista MoSCoW Usuario embajador

Oportunidad Material de referencia ya existente


Desarrollador




Promotor del proyecto

Interesados Equipo de proyecto Integrado

Lanzar el proyecto Gerente de proyecto

Interesados Modelo de alto nivel del sistema de datos existente

Crear modelo de alto nivel del sistema de datos existente

Desarrollador

Interesados Modelo de proceso del sistema existente



Interesados Interfaces del sistema existente

Documentar los Interfaces del sistema existente

Desarrollador

Interesados Arquitectura Técnica Existente



Comprender los requisitos

Oportunidad Material de referencia ya existente


Desarrollador

Requisitos Modelo de alto nivel del sistema de datos existente

Crear modelo de alto nivel del sistema de datos existente

Desarrollador

Requisitos Modelo de proceso del sistema existente



Requisitos Interfaces del sistema existente

Documentar las Interfaces del sistema existente

Desarrollador

Requisitos Arquitectura técnica existente



Requisitos Glosario Desarrollar glosario Desarrollador

Tabla 24. (Parte de 2/4) Espacios de actividad, alfas, productos de trabajo y roles en la fase


43




Requisitos Conversión de datos de los requisitos

Documentar la conversión de datos de los requisitos

Desarrollador

Requisitos Documentación de requisitos

Especificar documentación de requisitos

Escritor técnico

Requisitos Requisitos de pruebas

Determinar los requisitos de pruebas

Tester principal

Darle forma al sistema

Sistema de software


Definir la arquitectura del sistema


Prepararse para hacer el trabajo

Forma de trabajo

Plan de capacidad existente

Obtener el plan de capacidad existente


Forma de trabajo

Normas de definición de requisitos del negocio y directrices



Equipo Equipo de proyecto integrado

Lanzar el proyecto Gerente de proyecto

Forma de trabajo

Plan de gestión del alcance del Proyecto

Establecer el alcance, los objetivos y el enfoque

Gerente de proyecto

Forma de trabajo


Definir las estrategias de control y presentación de informes, las normas y los procedimientos

Gerente de proyecto

Forma de trabajo


Establecer planes de gestión

Gerente de proyecto

Forma de trabajo


Definir el trabajo Las estrategias de gestión, normas y procedimientos

Gerente de proyecto

Forma de trabajo

Plan de trabajo Establecer plan de trabajo Gerente de proyecto

Forma de trabajo, trabajo

Plan de financiación Establecer plan de financiación

Gerente de proyecto

Forma de trabajo


Definir las estrategias de gestión de los recursos , normas y procedimientos

Gerente de proyecto

Forma de trabajo


Creación de un proyecto guía de orientación

Gerente de proyecto

Trabajo Organización preparada

Aplicar organización Gerente de proyecto

Forma de trabajo


Establecer plan de recursos físicos

Gerente de proyecto

Trabajo Infraestructura preparada

Establecer la infraestructura

Gerente de proyecto

Forma de trabajo

Estrategias de ges-tión de calidad, nor-mas y procedimientos

Definir estrategias de gestión de la calidad, normas y procedimientos

Gerente de proyecto



44




Forma de trabajo

Gestión de la configuración las estrategias, normas y procedimientos

Definir las estrategias de gestión de configuración , normas y procedimientos

gerente de proyecto

Coordinar actividades

Equipo Dotación de personal y plan de su organización

Establecer personal y organización plan

gerente de proyecto

Apoyar el equipo

Equipo Equipo de proyecto integrado

Lanzar el proyecto gerente de proyecto

Seguimiento del progreso

Trabajo Línea base auditada Auditar entregables principales

gerente de proyecto

Trabajo Reporte de calidad Realizar evaluación de calidad

gerente de proyecto

Trabajo Auditoría de calidad Realizar auditoría de calidad

gerente de proyecto

Trabajo Lanzamiento de recursos físicos

Lanzar recursos físicos gerente de proyecto



Las prácticas definidas con los elementos del núcleo de Semat en la primera fase de CDM Fast Track

y PJM se visualizan en las Figuras 21-28 y la secuencia de actividades se muestra en la Figura 20.

Figura 20. Secuencia de actividades en la fase Definición. Elaboración propia del autor.

45

Figura 21. Definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.

46

Figura 22. Definición de la práctica Modelado de objetos de dominio

47

Figura 23. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

48

Figura 24. Definición de la práctica Asignación de responsabilidades. Elaboración propia del autor.

49

Figura 25. Definición de la práctica Suministro de recursos. Elaboración propia del autor.

Figura 26. Definición de la práctica Monitoreo y control de recursos. Elaboración propia del autor.

50

Figura 27. Definición de la práctica Planificación del proceso. Elaboración propia del autor.

51

Figura 28. Definición de la práctica Planificación del proceso. Elaboración propia del autor.

52

Fase: Modelado de requisitos






Interesados Información detallada del negocio


Desarrollador

Interesados Prototipo funcional validado

Validar prototipo funcional

Usuario embajador

Interesados Lista MoSCoW redefinida

Redefinir requisitos Usuario embajador

Interesados Descripción de la función del sistema existente

Producir descripción de la función del sistema existente

Desarrollador

Interesados Modelo de datos del sistema existente

Generar modelo de datos del sistema existente

Desarrollador

Asegurar la satisfacción de los interesados

Oportunidad, interesados

Prototipo funcional validado


Usuario embajador


Prototipo look and feel

Desarrollar prototipo look and feel



Requisitos de la interfaz usuario

Validar look and feel Usuario embajador


Prototipo funcional Desarrollar prototipo funcional

Desarrollador


Requisitos Modelo detallado del proceso de negocio

Crear modelo detallado del proceso de negocio

Desarrollador

Requisitos Información detallada del negocio


Desarrollador

Requisitos Modelo de datos del negocio

Construir modelo de datos del negocio

Desarrollador

Requisitos Modelo detallado de la función del negocio

Construir modelo detallado de la función del negocio

Desarrollador

Requisitos Lista MoSCoW redefinida

Redefinir requisitos Usuario embajador

Requisitos Descripción de la función del sistema existente

Producir descripción de la función del sistema existente

Desarrollador

Requisitos Modelo de datos del sistema existente

Generar modelo de datos del sistema existente

Desarrollador

Requisitos

Descripción de los procedimientos operacionales existentes

Elaborar descripción de los procedimientos operacionales existentes



modelado de requisitos. Elaboración propia del autor.

53




Requisitos Requisitos operacionales detallados del sistema

Definir los requisitos operacionales detallados del sistema


Requisitos Requisitos de formación

Crear requisitos de formación



Sistema de software

Arquitectura técnica Crear arquitectura técnica


Sistema de software

Problemas de rendimiento

Determinar problemas de rendimiento


Implementar el sistema

Sistema de software

Diseño lógico de base de datos

Crear diseño lógico de base de datos


Sistema de software

Base de datos ddl del prototipo funcional

Crear base de datos ddl del prototipo funcional


Sistema de software

Diseño de la aplicación Diseñar aplicación Desarrollador principal de la aplicación

Sistema de software

Entorno de desarrollo inicial


Gerente de configuración

Sistema de software

Prototipo funcional Desarrollar prototipo funcional

Desarrollador

Sistema de software

Prototipo look and feel Desarrollar prototipo look and feel


Sistema de software

Prototipo funcional validado


Usuario embajador


Forma de trabajo

Normas de la base de datos y directrices



Forma de trabajo

Normas de desarrollo de la aplicación y directrices

Implementar normas de desarrollo de la aplicación y directrices


Forma de trabajo

Estrategia de conversión de datos

Definir estrategia de conversión de datos

Desarrollador

Forma de trabajo

Plan de trabajo de conversión de datos

Definir plan de trabajo de conversión de datos

Líder de equipo de conversión de datos

Forma de trabajo

Normas de documentación

Determinar las normas de la documentación

Escritor técnico

Forma de trabajo

Documentación de procedimientos y entorno

Crear documentación de procedimientos y entorno

Administrador del sistema



54




Forma de trabajo

Estrategia de pruebas Desarrollar estrategia de pruebas

Tester principal


Trabajo Entorno de desarrollo inicial




Establecer personal y plan de organización

Gerente de proyecto


Forma de trabajo



Gerente de proyecto

Forma de trabajo


Forma de trabajo


Forma de trabajo

Plan de trabajo



Forma de trabajo


Forma de trabajo



Forma de trabajo



Forma de trabajo


Forma de trabajo



Gerente de proyecto


Lanzar recursos físicos

Gerente de proyecto


Gerente de proyecto

Trabajo Línea base auditado Auditar entregables principales

Gerente de proyecto



55

Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase del método CDM

Fast Track se visualizan en la Sección ANEXOS.

Fase: Diseño de sistema y generación





Asegurar la satisfacción de los interesados

Interesados Lista MoSCoW redefinida

Redefinir los requisitos Usuario embajador


Requisitos Lista MoSCoW redefinida

Redefinir los requisitos Usuario embajador


Requisitos Modelo de requisitos del negocio rested

Revisar modelo de requisitos

Desarrollador

Requisitos Definición de hardware y software



Requisitos Arquitectura de distribución

Desarrollar arquitectura de distribución


Requisitos

Esquema de autorización de objetos de base de datos

Crear esquema de autorización de objetos de base de datos


Requisitos Diseño físico de la base

Crear diseño físico de la base


Sistema de software

Ddl de la producción de la base de datos

Crear ddl de la producción de la base de datos


Requisitos Módulos documentados

Desarrollar (grupo de) módulos

Desarrollador

Requisitos Diseño del módulo de conversión de datos

Diseñar módulos de conversión de datos

Desarrollador


Sistema de software

Código de la aplicación

Estrenar aplicación Desarrollador principal de la aplicación

Requisitos Módulos de conversión

Codificar módulos de conversión

Desarrollador

Sistema de software

Materiales de referencia de usuario

Ensamblar materiales de referencia de usuario

Desarrollador

Sistema de software

Guía del usuario inicial

Producir guía del usuario inicial

Usuario embajador

Sistema de software

Materiales técnicos de referencia

Ensamblar materiales técnicos de referencia

Desarrollador


diseño de sistema y generación. Elaboración propia del autor.

56




Sistema de software

Guía de operaciones inicial del sistema

Producir guía de operaciones inicial del sistema


Requisitos Pruebas de escenarios

Crear pruebas de escenarios

Tester principal

Requisitos Modelo de prueba de la arquitectura del sistema

Crear modelo de prueba de la arquitectura del sistema

Tester principal

Probar el sistema

Requisitos, sistema de software

Requisitos validados Validar requisitos Usuario embajador


Datos probados convertidos y verificados

Conversión inicial y la verificación de los datos



Resultados de la prueba del módulo de conversión

Realizar prueba del módulo de conversión

Desarrollador


Resultados de las pruebas del sistema

Desarrollar pruebas del sistema

Tester principal


Resultados de la prueba de integración de sistemas

Realizar prueba de integración de sistemas


Sistema de software

Listas de chequeo de prueba del módulo

Desarrollar listas de chequeo de prueba del módulo

Tester principal

Sistema de software

Secuencia de pruebas para la integración de sistemas

Desarrollar la secuencia de pruebas para la integración de sistemas



Forma de trabajo

Estrategia de reserva y recuperación

Desarrollar estrategia de reserva y recuperación


Forma de trabajo

Estrategia de control y seguridad

Desarrollar de estrategia seguridad


Forma de trabajo

Plan de capacidad Crear plan de capacidad


Forma de trabajo

Estrategia de formación

Definir estrategia de formación

Usuario embajador

Forma de trabajo

Plan de formación Crear plan de formación

Usuario embajador

Forma de trabajo

Estrategia cut-over Definir estrategia cut-over

Gerente de proyecto

Forma de trabajo

Plan de integración Planear integración Tester principal



57




Trabajo Entorno de desarrollo inicial




Establecer personal y organización plan

Gerente de proyecto


Forma de trabajo



Gerente de proyecto

Forma de trabajo


Forma de trabajo


Forma de trabajo

Plan de trabajo



Forma de trabajo


Forma de trabajo



Forma de trabajo



Forma de trabajo


Forma de trabajo



Gerente de proyecto


Lanzar recursos físicos Gerente de proyecto


Gerente de proyecto

Trabajo Línea base auditado Auditar entregables principales

Gerente de proyecto



58

Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase del método CDM

Fast Track se visualizan en la sección ANEXOS.

Fase: Transición a la producción

En la tabla 27 se presentan los productos de trabajo, actividades y roles de esta fase asociados a






Futuras mejoras funcionales

Determinar futuras mejoras funcionales

Usuario embajador


Plan de mejoras Planear mejoras Usuario embajador

Utilizar el sistema

Interesados Usuarios entrenados Entrenar usuarios Entrenador

Interesados Administradores entrenados

Entrenar administradores

Entrenador

Interesados Equipo de validación entrenado

Entrenar equipo de validación

Entrenador

Interesados Entorno de mantenimiento del cliente

Establecer entorno de mantenimiento del cliente



Sistema de software

Referencia del usuario Completar referencia del usuario

Usuario embajador

Sistema de software

Guía de usuario Completar guía de usuario

Usuario embajador

Sistema de software

Referencia técnica detallada

Completar referencia técnica

Escritor técnico

Sistema de software

Guía operacional del sistema

Completar guía operacional del sistema


Sistema de software

Texto de ayuda en línea

Generar texto de ayuda en línea

Desarrollador

Sistema de software

Materiales de formación

Crear materiales de formación

Usuario embajador

Sistema de software

Materiales de clase de usuario

Producir materiales de clase de usuario

Usuario embajador

Sistema de software

Sistema en producción

Comenzar la producción


Sistema de software

Datos limpios Limpiar los datos Administrador de los datos del cliente

Sistema de software





transición a la producción. Elaboración propia del autor.

59



Probar el sistema


Resultados de la validación preproducción

Realizar validación preproducción



Resultados de las pruebas de actualización

Probar actualización Tester principal

Sistema de software

Datos limpios Limpiar los datos Administrador de los datos del cliente

Sistema de software




Operar el sistema

Sistema de software

Sistema heredado apagado

Apagar sistema heredado


Sistema de software

Evaluación del sistema

Auditar sistema Auditor interno

Sistema de software

Métricas de rendimiento

Especificar las métricas de rendimiento

Desarrollador

Sistema de software

Estadísticas del rendimiento

Medir el rendimiento del sistema


Sistema de software

Excepciones de rendimiento

Acordar excepciones de rendimiento

Gerente de proyecto

Sistema de software

Correcciones fallidas Analizar los problemas Desarrollador

Sistema de software

Registro de problemas

Supervisar y responder a los problemas del sistema

Personal de soporte is

Sistema de software

Scripts actualizados y procedimiento

Actualizar scripts y procedimiento

Desarrollador

Sistema de software

Aplicación actualizada Realizar cambios en la aplicación

Desarrollador

Sistema de software

Aplicación del sistema actualizada

Actualización de la aplicación sistema

Desarrollador

Sistema de software

Correcciones de rendimiento

Analizar excepciones de rendimiento

Desarrollador


Forma de trabajo

Entorno de formación Crear entorno de formación

Desarrollador dba

Forma de trabajo

Plan de instalación Desarrollar plan de instalación

Desarrollador

Forma de trabajo

Entorno de producción

Preparar entorno de producción

Productor dba

Forma de trabajo

Estrategia de actualización y plan

Preparar estrategia de actualización de la aplicación y plan

Gerente de proyecto


Trabajo Resultados de la validación preproducción





60




Trabajo Resultados de la validación preproducción



Forma de trabajo



Gerente de proyecto

Forma de trabajo


Forma de trabajo


Forma de trabajo

Plan de trabajo



Forma de trabajo


Forma de trabajo



Forma de trabajo



Forma de trabajo


Forma de trabajo


Forma de trabajo


Forma de trabajo


Finalizar proyecto

Trabajo Aceptación del cliente Aceptar seguridad del cliente del proyecto

Gerente de proyecto

Equipo Personal lanzado Lanzar personal Gerente de proyecto



61



Finalizar proyecto

Trabajo Aceptación del cliente Aceptar seguridad del cliente del proyecto

Gerente de proyecto

Equipo Personal lanzado Lanzar personal Gerente de proyecto

Trabajo Recursos físicos Lanzar recursos físicos Gerente de proyecto

Trabajo Reporte de calidad Realizar evaluación de la calidad

Gerente de proyecto

Trabajo Línea base auditada Auditar entregables clave

Gerente de proyecto

Trabajo Preparación de la gestión de produccción

Concluir configuración de gestión de la configuración

Gerente de proyecto



Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase del método CDM

Fast Track se visualizan en la sección ANEXOS.

El grupo de competencias asociadas con los roles existentes en el método CDM Fast Track se

visualizan en la Figura 29.

Figura 29. Competencias de los métodos CDM y PJM. Elaboración propia del autor.

El grupo de roles existentes en el método CDM se visualizan en la Figura 30.

Figura 30. Roles del método CDM y PJM. Elaboración propia del autor.

El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas, al aplicar el

método se encuentra que, de acuerdo con lo que Semat propone, en la Figura 31 se especifica los

estados que afectan la ejecución de actividades de los métodos CDM y PJM durante sus cuatro

fases.

62

Figura 31. Progreso de un proyecto al aplicar la metodología CDM Fast Track. Elaboración

propia del autor.

4.3 Representación gráfica del UNC-Method

Debido a que en la literatura no se especifican las prácticas del UNC-Method, se propone la

asociación con prácticas de la ingeniería de software ya existentes para su inclusión en el núcleo de

Semat. El conjunto de prácticas asociadas con las actividades y productos de trabajo de este método

se presentan en la Figura 32.

Figura 32. Prácticas del UNC-Method. Elaboración propia del autor.

63

Para llevar a cabo la representación de los elementos de este método, se presenta en la Tabla 28 la

descripción de algunos de los productos de trabajo que se definen en el método [8] [9] [26]:

Entregable Descripción

Esquema pre-conceptual Permite representar el modelo verbal del problema

Diagrama causa y efecto Permite realizar una estructura y jerarquización de los problemas que el interesado establece en el diálogo controlado

Diagrama de objetivos Permite identificar los objetivos gerenciales y específicos de una organización

Diagrama de procesos Permite visualizar cómo una organización satisface sus objetivos, ya que define las actividades de la organización y cómo se llevan a cabo

Tabla explicativa de procesos Clarifica la información que se encuentra modelada en el diagrama de procesos

Diagrama de casos de uso Permite modelar aspectos funcionales del sistema, para reconocer sus límites, los actores y las acciones que se realizan

Reglas del negocio Aspectos de la organización que afectan su comportamiento

Tarjetas de educción Información reunida en el diálogo controlado y organizada estructuralmente

Organigrama La jerarquía y las relaciones de los actores y las funciones dentro de la organización

Diccionario de datos Los almacenes y actores del diagrama de procesos

Esquema pre-conceptual basado en especificaciones

Especifica las operaciones, eventos, límites, derivaciones y consultas necesarias

Tabla 28. Descripción de entregables del UNC-Method. Elaboración propia del autor basado

en [10]

Fase: Contexto del software






Oportunidad Archivos digitales Desarrollar entrevista interesado-analista

Analista

Interesado

Director del proyecto


Dialogo controlado Desarrollar entrevista interesado-analista

Analista

Interesado

Director del proyecto

Oportunidad Dialogo controlado Revisar documentación Analista

Tabla 29. (Parte 1/2) Espacios de actividad, alfas, productos de trabajo, actividades y roles

de la fase análisis del problema. Elaboración propia del autor.

64




Oportunidad Tarjetas de educción

Resumir la información relacionada con los actores, los objetos y las funciones

Analista

Oportunidad

Modelo del dominio, Organigrama, Tarjetas de educción

Verificar consistencia Analista

Interesados Organigrama Identificar los actores internos y externos en la organización

Analista

Oportunidad Modelo del dominio Establecer un vocabulario común

Analista


Requisitos Esquema pre-conceptual

Establecer un vocabulario común

Analista

Requisitos Esquemas pre-conceptuales ejecutables

Analista

Requisitos

Esquemas pre-conceptuales ejecutables, Esquemas pre-conceptuales ejecutables, Tabla de trazabilidad documental


Requisitos Tabla de trazabilidad documental

Estructurar información de la organización

Analista


Forma de trabajo

Guía UNC-Method Explicar el método Director del proyecto

Trabajo Tablero Kanban Gestionar la elaboración de tareas

Analista

Trabajo Reporte de avance de los alfas


Analista

Equipo Lista de roles y responsabilidades


Director del

proyecto


Equipo Lista de roles y responsabilidades


Director del

proyecto

Tabla 29. (Parte 2/2) Espacios de actividad, alfas, productos de trabajo, actividades y roles

de la fase análisis del problema. Elaboración propia del autor.

Las prácticas definidas con los elementos del núcleo de Semat en la primera fase del UNC-Method

se visualizan en las Figuras 34-37 y la secuencia de actividades se muestra en la Figura 33.

65

Figura 33. Secuencia de

actividades en la fase

contexto del software

Figura 34. Representación gráfica de las prácticas Asignación de responsabilidades y Formación de personal. Elaboración propia del autor.

66

Figura 35. Representación gráfica de la práctica Modelado de objetos del dominio. Elaboración propia del autor.

67

Figura 36. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.

Figura 37. Representación gráfica de la práctica Monitoreo y control del proceso. Elaboración propia del autor.

68

Fase: Análisis del problema






Interesados Reglas del negocio Establecer limitaciones del proceso

Analista


Oportunidad Reglas del negocio Establecer limitaciones del proceso

Analista

Oportunidad Tabla explicativa del diagrama de procesos


Analista

Oportunidad Diagrama de procesos

Analista

Oportunidad Diagrama de objetivos

Analista

Oportunidad Diagrama de causa y efecto

Analista

Oportunidad

Diagrama de procesos, Diagrama de objetivos, Diagrama de causa y efecto, Tabla explicativa del diagrama de procesos



Requisitos Tabla explicativa del diagrama de procesos


Analista

Requisitos Diagrama de procesos

Analista

Requisitos Diccionario de datos

Desarrollar el diccionario de datos

Analista

Requisitos

Diagrama de procesos, Tabla explicativa del diagrama de procesos


Apoyar el equipo

Equipo, Forma de trabajo

Tablero Kanban Gestionar la elaboración de tareas

Analista


Reporte de avance de los alfas


Analista

Tabla 30. Espacios de actividad, alfas, productos de trabajo, actividades y roles de la fase

análisis del problema. Elaboración propia del autor.

Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase del UNC-Method

se visualizan en la Sección ANEXOS.

69

Fase: propuestas de solución






Oportunidad Factores críticos de éxito

Establecer factores críticos de éxito

Analista


Requisitos Casos de uso Especificar la funcionalidad de la aplicación de software

Analista

Requisitos Diagrama de flujo de interfaz de usuario

Analista

Requisitos Organigrama Desarrollar nuevo organigrama

Analista

Requisitos Diagrama de procesos

Desarrollar nuevo diagrama de procesos

Analista

Requisitos

Diagrama de procesos, Organigrama, Casos de uso, Diagrama de flujo de interfaz de usuario



Sistema de software

Casos de uso Especificar la funcionalidad de la aplicación de software

Analista


Trabajo Valoración de la propuesta Establecer el valor de la

solución

Analista

Trabajo Costeo de la propuesta

Analista




Analista




Analista

Apoyar el equipo



Analista




Analista


propuestas de solución. Elaboración propia del autor.

Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase del UNC-Method

se visualizan en la Sección ANEXOS.

70

Fase: esquema conceptual







Prototipo Alfa Desarrollar prototipo Alfa

Desarrollador


Requisitos

Especificaciones basados en el esquema pre-conceptual


Analista

Requisitos Diagrama de clases Analista

Requisitos Diagramas de comunicación

Analista

Requisitos Diagramas de máquina de estados

Analista

Requisitos

Especificaciones basados en el esquema pre-conceptual, Diagrama de clases, Diagramas de comunicación, Diagrama de máquina de estados



Requisitos Ejemplo de código fuente

Proporcionar las bases para la construcción de la aplicación final

Desarrollador

Requisitos Prototipo Alfa Desarrollar prototipo Alfa

Desarrollador



Analista

Trabajo Reporte de avance de los alfas


Analista



Analista


esquema conceptual. Elaboración propia del autor.

Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase del UNC-Method se

visualizan en la Sección ANEXOS.

71

El grupo de competencias asociadas con los roles existentes en el UNC-Method se visualizan en la

Figura 38.

Figura 38. Competencias del UNC-Method. Elaboración propia del autor.

El grupo de roles existentes en el UNC-Method se visualizan en la Figura 39.

Figura 39. Roles del UNC-Method. Elaboración propia del autor.

El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas. Al aplicar el

método se encuentra que, de acuerdo con lo que Semat propone, en la Figura 40 se especifican los

estados que afectan la ejecución de actividades del UNC-Method durante sus cuatro fases.

Figura 40. Progreso de un proyecto al aplicar el UNC-Method. Elaboración propia del autor.

72

4.4 Representación gráfica del método RUP

En la Figura 41 se representan seis mejores prácticas que se exponen en el método RUP. Cada

práctica se incluye en el núcleo de Semat y tiene un color asociado que depende del área de interés.

Figura 41. Mejores prácticas del método RUP. Elaboración propia del autor.

Para llevar a cabo esta representación se toma en consideración la descripción de productos de

trabajo, los cuales se definen en la Tabla 33.

Artefacto Descripción

Visión Contiene los requisitos del proyecto básicos, características clave y las limitaciones principales.

Lista de riesgos Riesgos del proyecto inicial identificados.

Plan de desarrollo de software

Especifica duración y objetivos, estimaciones de recursos (específicamente los de tiempo, personal y costos entorno de desarrollo)

Plan de iteración Plan para primera iteración.

Herramientas Todas las herramientas para apoyar el proyecto. Se instalan las herramientas necesarias para el trabajo en la primera fase.

Glosario Términos importantes definidos.

Modelo de casos de uso Actores importantes, casos de uso identificados y los flujos de eventos descritos sólo para los casos de uso más críticos.

Repositorio del proyecto El entorno de gestión de la configuración se debe establecer.

Prototipos Uno o más prototipos arquitectónicos ejecutables para explorar la funcionalidad crítica y escenarios de gran importancia.

Lista de riesgos actualizado y revisado

Nuevos riesgos relacionados principalmente con el manejo de los requisitos no funcionales.

Caso desarrollo refinada El entorno de desarrollo, los procesos, herramientas y soporte de automatización necesarios para apoyar el equipo de construcción.

Documento de arquitectura de software

Descripciones detalladas de los casos de uso arquitectónicamente significativos, la identificación de los mecanismos clave y elementos de diseño, la definición de la vista del proceso y de la vista de despliegue.

Modelo de diseño Las realizaciones de casos de uso para los escenarios de gran importancia arquitectónica y el comportamiento requerido asignado a los elementos de diseño apropiados.

Modelo de datos Elementos importantes como entidades, relaciones, tablas definidos y revisados.

Tabla 33. (Parte 1/2) Descripción de principales artefactos Elaboración propia del autor

basado en [16]

73

Artefacto Descripción

Modelo de implementación Creación de la estructura inicial y componentes principales identificados y prototipos.

Visión refinada Comprensión de los casos más críticos que impulsan las decisiones arquitectónicas y de planificación.

Especificaciones suplementarias de requisitos

Requisitos no funcionales documentados y revisados.

Test Suite Pruebas de implementación y ejecución para validar la estabilidad de la construcción.

Automatización de pruebas de arquitectura

Composición de diversos mecanismos y elementos de software clave que incorporan las características fundamentales del sistema de software.

El sistema El sistema mismo ejecutable, listo para comenzar las pruebas "beta".

Materiales de capacitación Manuales y otros materiales de capacitación. Anteproyecto, basado en casos de uso si el sistema tiene robusta interfaz de usuario.

Producto completo El producto final de acuerdo con los requisitos y que debe ser utilizable para el cliente.

Tabla 33. (Parte 2/2) Descripción de principales artefactos. Elaboración propia del autor

basado en [16]

Fase: Inicio






Oportunidad Visión Desarrollar visión Analista de sistemas

Oportunidad Lista de riesgos Identificar y evaluar los

riesgos Gerente de proyecto

Oportunidad Caso de negocio Desarrollar caso de

negocio Gerente de proyecto


Glosario de negocio Capturar un vocabulario

común de negocio Analista proceso-negocio


Reglas del negocio Mantener reglas de

negocio Analista proceso-negocio


Visión del negocio Establecer y ajustar

objetivos Analista proceso-negocio


Evaluación de la organización objetivo

Evaluar organización

objetivo Analista proceso-negocio


Modelo de objetos del negocio, Trabajadores del negocio, entidades del negocio, realización de casos de uso de negocio

Encontrar las entidades y

los trabajadores del

negocio

Diseñador de negocios


inicio. Elaboración propia del autor.

74




Oportunidad Plan de gestión de requisitos, atributos de requisitos, visión

Manejar dependencias Analista de software


Actores del negocio, modelo de caso de uso del negocio, especificación de negocio suplementaria, caso de uso de negocio

Encontrar los actores del

negocio y casos de uso Analista proceso-negocio

Oportunidad

Modelo de casos de uso de negocio, casos de uso de negocio

Estructurar el modelo de

caso de uso del negocio Analista proceso-negocio


Documento de arquitectura de negocios

Definir la arquitectura de

negocios Analista proceso-negocio

Oportunidad

Casos de uso del negocio, especificación de negocio suplementaria

Detallar caso de uso del

negocio Diseñador de negocio

Oportunidad Trabajadores de negocio, unidad de organización

Detallar un trabajador de

negocios Diseñador de negocio

Oportunidad Entidades de negocio, unidad de organización

Detallar una entidad de

negocio Diseñador de negocio


Interesados Revisión de registros Revisar el modelo de caso de uso del negocio

Revisor del modelo de negocio

Interesados Revisión de registros Revisar el modelo de objetos del negocio


Oportunidad Lista de riesgos, caso de negocio, visión

Evaluar viabilidad de la prueba de concepto arquitectónico

Arquitecto de software


Requisitos

Modelo de análisis, especificaciones suplementarias, modelo de casos de uso

Definir requisitos de automatización

Diseñador de negocio

Requisitos Glosario Capturar un vocabulario común

Analista de software

Requisitos

Casos de uso, actores, modelo de casos de uso, especificaciones suplementarias

Encontrar los actores y casos de uso




75




Requisitos Casos de uso, especificaciones suplementarias

Detallar un

caso de uso

Especificador de requisitos

Requisitos Modelo de casos de uso

Obtener solicitudes de

los interesados Analista de software

Requisitos

Especificación de requisitos, especificaciones suplementarias

Detallar los requisitos del software


Requisitos Clase límite, actores, guión gráfico de casos de uso

Modelar la interfaz de usuario

Diseñador interfaz-usuario

Requisitos Modelo de caso de uso, caso de uso

Estructurar el modelo de caso de uso

Analista de sistemas

Requisitos

Realización de casos de uso, Modelo de despliegue, modelo de diseño

Analizar la arquitectura Arquitecto de software


Sistema de software

Documento de arquitectura de software, atributos de requisitos

Priorizar casos de uso Arquitecto de software

Sistema de software

Prototipo interfaz- usuario

Realizar prototipo de la interfaz de usuario


Sistema de software



Sistema de software

Infraestructura para el desarrollo

Dar soporte de desarrollo Administrador del sistema


Sistema de software

Unidad de desarrollo Crear unidad de desarrollo


Sistema de software

Prototipo interfaz- usuario



Probar el sistema

Sistema de software




Trabajo Revisión de registros Revisar el modelo de caso de uso del negocio


Trabajo Revisión de registros Revisar el modelo de objetos del negocio


Forma de trabajo

Plan de desarrollo de software, plan de iteración

Iniciar proyecto Gerente de proyecto



76




Trabajo Revisión de registros Revisar el modelo de caso de uso del negocio


Forma de trabajo

Base de datos con las mediciones del proyecto, plan de medidas

Desarrollar plan de medición

Gerente de proyecto

Trabajo Revisión de registros Revisar el modelo de objetos del negocio


Forma de trabajo

Plan de desarrollo de software, plan de iteración

Iniciar proyecto Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo

Plan de gestión de riesgos

Desarrollar plan de gestión de riesgos

Gerente de proyecto

Forma de trabajo

Plan de aceptación del producto

Desarrollar plan de aceptación del producto

Gerente de proyecto

Forma de trabajo

Plan de resolución de problemas

Desarrollar plan de resolución de problemas

Gerente de proyecto

Forma de trabajo

Plan de evaluación de calidad

Desarrollar plan de evaluación de calidad

Gerente de proyecto

Forma de trabajo

Plan de medidas, plan de desarrollo de software

Definir monitoreo y procesos de control

Gerente de proyecto

Forma de trabajo


Definir grupo de trabajo y organización del proyecto

Gerente de proyecto

Forma de trabajo


Planear fases e iteraciones

Gerente de proyecto

Forma de trabajo


Compilar plan de desarrollo de software

Gerente de proyecto

Trabajo Plan de iteración Desarrollar plan de iteración

Gerente de proyecto

Equipo Orden de trabajo Iniciar iteración Gerente de proyecto

Equipo Plan de desarrollo de software

Adquirir personal Gerente de proyecto

Forma de trabajo

Plan de gestión de requisitos

Desarrollar Plan de gestión de requisitos


Forma de trabajo

Plan de gestión de requisitos, atributos de requisitos, visión


Forma de trabajo

Plan de pruebas Identificar motivadores de pruebas

Gerente de pruebas



77




Forma de trabajo

Lista de ideas de pruebas

Identificar ideas de prueba

Analista de pruebas

Forma de trabajo

Plan de pruebas Acordar misión Gerente de pruebas

Forma de trabajo

Plan de pruebas Identificar objetivos de Prueba

Analista de pruebas

Forma de trabajo

Plan de pruebas Definir evaluación y trazabilidad necesarias

Analista de pruebas

Forma de trabajo

Plan de pruebas, arquitectura de automatización de pruebas, especificación de interfaz de prueba, configuración del medio de pruebas, solicitud de cambios

Definir enfoque de

prueba Diseñador de pruebas

Forma de trabajo

Evaluación organización de desarrollo

Evaluar organización actual

Ingeniero de procesos

Forma de trabajo

Caso de desarrollo Desarrollar caso de desarrollo


Forma de trabajo

Plan de gestión de configuración

Establecer políticas de gestión de configuración


Forma de trabajo


Escribir plan de gestión de configuración


Forma de trabajo


Establecer proceso de cambio de control

Gerente de control de cambios


Equipo

Orden de trabajo, plan de desarrollo de software, plan de iteración

Programar y asignar el Trabajo

Gerente de proyecto

Equipo Solicitud de cambio, orden de trabajo, lista de problemas

Manejar excepciones y Problemas

Gerente de proyecto

Apoyar el equipo

Forma de trabajo

Solicitud de cambio Lanzar caso desarrollo Ingeniero de procesos

Forma de trabajo

Solicitud de cambio

Verificar de la configuración de herramientas e instalación

Especialista de herramientas

Forma de trabajo

Solicitud de cambio Presentar solicitud de cambio

Cualquier rol

Forma de trabajo

Solicitud de cambio Actualizar solicitud de cambio

Cualquier rol


Trabajo Revisión de registros Revisar aprobación de proyectos

Revisor del proyecto



78




Trabajo Solicitud de cambio, evaluación de o iteración

Evaluar iteración Gerente de proyecto

Trabajo Revisión de registros Revisar planeación del proyecto


Trabajo Revisión de registros Revisar el plan de iteración


Trabajo Revisión de registros Revisar criterio de evaluación de la iteración


Trabajo Revisión de registros Revisar aceptación de iteración


Trabajo Revisión de registros Revisar proyecto (PRA) Revisor del proyecto

Trabajo

Base de datos con las medidas del proyecto, lista de riesgo, lista de problemas

Monitorear estado de proyecto

Gerente de proyecto

Trabajo Revisión de registros Revisar requisitos Revisor de requisitos

Forma de trabajo

Solicitud de cambio Confirmar solicitud de cambio duplicado o rechazado


Forma de trabajo

Solicitud de cambio Revisar solicitud de cambio


Forma de trabajo

Base de datos de medidas del proyecto

Informar sobre estado de

configuración


Trabajo Resultados de auditoría de configuración

Realizar auditoría de

configuración




79

Figura 42. Secuencia de actividades en la fase inicio. Elaboración propia del autor.

80

81

82

83

84

85

Figura 43. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.

86

87

88

89

Figura 44. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.

90

91

92

93

94

95

96

97

Figura 45. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.

98

Fase: Elaboración






Oportunidad Lista de riesgos Identificar y evaluar los riesgos

Gerente de proyecto

Oportunidad Caso de negocio Desarrollar caso de negocio

Gerente de proyecto

Oportunidad Visión Desarrollar visión Analista de sistemas

Oportunidad Plan de gestión de requisitos, atributos de requisitos, visión



Requisitos Glosario Capturar un vocabulario común


Requisitos

Casos de uso, actores, modelo de casos de uso, especificaciones suplementarias

Encontrar los actores y casos de uso


Requisitos Modelo de casos de uso, solicitud del interesado

Obtener solicitudes de los interesados


Requisitos

Casos de uso, atributos de requisitos, especificaciones suplementarias

Detallar un caso de uso


Requisitos

Especificación de requisitos, especificaciones suplementarias, atributos de requisitos

Detallar los requisitos del software


Requisitos Clase límite, actores, guión gráfico de casos de uso

Modelar la interfaz de usuario





Requisitos

Realización de casos de uso, Modelo de despliegue, modelo de diseño


Requisitos

Modelo de diseño, modelo de análisis, realización de casos de uso

Analizar casos de uso Diseñador

Requisitos

Capsula, interfaz, modelo de diseño, protocolo, clase de diseño

Identificar elementos de diseño



elaboración. Elaboración propia del autor.

99




Requisitos Realización de casos de uso

Diseñar de caso de uso Diseñador

Requisitos Cápsula, protocolo Diseñar cápsula Diseñador de cápsula

Requisitos Clase diseñada Diseñar de clase Diseñador

Requisitos Paquete de diseño Diseñar de subsistema Diseñador

Requisitos Realización de casos de uso, capsula, clase diseño, interfaz

Diseñar clase de pruebas y paquetes

Diseñador

Requisitos Modelo de datos Diseñar base de datos Diseñador de base de datos


Sistema de software

Documento de arquitectura de software, atributos de requisitos

Priorizar casos de uso Arquitecto de software

Sistema de software

Prototipo interfaz- ususario



Sistema de software


Dar soporte de desarrollo


Sistema de software



Sistema de software

Modelo de datos Diseñar base de datos Diseñador de base de datos

Sistema de software

Paquete diseñado, clase diseñada, modelo diseñado, documento de arquitectura de software

Identificar mecanismos de diseño


Sistema de software

Capsula, interfaz, clase diseñada, modelo diseñado



Sistema de software


Incorporar elementos de diseño existente


Sistema de software


Describir arquitectura tiempo real


Sistema de software

Documento de arquitectura de software, modelo de despliegue

Describir distribución Arquitecto de software



100




Sistema de software

Modelo de implementación, documento de arquitectura de software

Estructurar el modelo de implementación


Sistema de software



Sistema de software

Componente, componente de prueba

Implementar componente

Implementador

Sistema de software

Componente Fijar un defecto Implementador

Sistema de software

Componente, componente de prueba, resultados de prueba

Implementar componente de pruebas y subsistema

Implementador

Sistema de software


Realizar pruebas unitarias

Implementador

Sistema de software

Construcción, subsistema de implementación

Integrar subsistema Integrador

Sistema de software

Construcción Integrar sistema Integrador

Probar el sistema

Sistema de software



Sistema de software

Registro de cambios, plan de prueba, configuración de ambiente de pruebas

Definir configuraciones de ambiente de pruebas

Diseñador de pruebas

Sistema de software

Registro de cambios, especificación de interfaz de prueba

Identificar mecanismos de pruebas


Sistema de software

Registro de cambios, especificación de interfaz de prueba, componente de pruebas, configuración de ambiente de pruebas

Definir elementos de pruebas


Sistema de software

Caso de prueba Definir detalles de pruebas

Analista de pruebas

Sistema de software

Registro de cambios, configuración de ambiente de pruebas, Pruebas de script, test suite

Implementar prueba Suite

Tester

Sistema de software

Registro de cambios, test script

Implementar pruebas Tester

Sistema de software

Configuración de ambiente de pruebas, test log

Ejecutar pruebas Suite Tester

Tabla 35. (Parte3/7) Espacios de actividad, alfas, productos de trabajo y roles en la fase


101



Probar el sistema

Sistema de software

Configuración de ambiente de pruebas, test script, test suite

Estructurar la implementación de pruebas


Sistema de software

Registro de cambios, configuración de ambiente de pruebas, test script, test suite

Analizar fallos de pruebas

Tester

Sistema de software

Lista de idas de prueba Identificar ideas de pruebas

Analista de pruebas






Gerente de proyecto

Forma de trabajo


Desarrollar plan de Medición

Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo

Plan de gestión de requisitos

Desarrollar plan de gestión de requisitos


Forma de trabajo

Plan de gestión de requisitos, atributos de requisitos, visión


Forma de trabajo


Gerente de pruebas



102




Forma de trabajo


Definir enfoque de prueba


Forma de trabajo

Plan de pruebas Identificar objetivos de prueba

Analista de pruebas

Forma de trabajo


Forma de trabajo


Analista de pruebas

Forma de trabajo



Analista de pruebas

Forma de trabajo

Plan de pruebas Definir enfoque de prueba


Forma de trabajo



Forma de trabajo


Forma de trabajo

Plan de construcción integrada

Planear la integración Integrador

Forma de trabajo


Planear integración de subsistema

Integrador


Equipo

Orden de trabajo, plan de desarrollo de software, plan de iteración

Programar y asignar el trabajo

Gerente de proyecto


Manejar excepciones y problemas

Gerente de proyecto

Apoyar el equipo

Forma de trabajo

Solicitud de cambio Lanzar caso desarrollo Ingeniero de procesos

Forma de trabajo

Solicitud de cambio Verificar de la configu-ración de herramientas e instalación


Forma de trabajo


Cualquier rol

Forma de trabajo


Cualquier rol


Trabajo Solicitud de cambio, e-valuación de o iteración


Trabajo Evaluación de estado Reportar estado Gerente de proyecto





103






Trabajo



Gerente de proyecto





Forma de trabajo


Informar sobre estado de configuración





Trabajo



Gerente de proyecto





Forma de trabajo


Informar sobre estado

de configuración Gerente de configuración



Configuración


Forma de trabajo



Forma de trabajo

Solicitud de cambio Revisar solicitud de

cambio



Solicitud de cambio, revisión de registros

Revisar el diseño Revisor de diseño



Revisar la arquitectura Revisor de arquitectura

Trabajo Revisión de registros Revisar código Revisor de código

Forma de trabajo

Solicitud de cambios, lista de problemas, plan de pruebas

Obtener comentarios

de pruebas Gerente de pruebas

Tabla 35. (Parte 6/7)Espacios de actividad, alfas, productos de trabajo y roles en la fase


104




Forma de trabajo


Obtener comentarios de pruebas

Gerente de pruebas


Resultados de pruebas, Solicitud de cambio, resumen de evaluación de prueba

Verificar cambios en

construcción Analista de pruebas



Determinar resultados

de pruebas Analista de pruebas


Resultados de pruebas, Solicitud de cambio, lista de problemas, plan de pruebas

Evaluar esfuerzo de

pruebas Gerente de pruebas



Evaluar calidad Gerente de pruebas

Tabla 35. (Parte 7/7)Espacios de actividad, alfas, productos de trabajo y roles en la fase


Las prácticas definidas con los elementos del núcleo de Semat en la segunda fase de RUP se

visualizan en la sección ANEXOS.

Fase: Construcción

En la tabla 36 se presentan los productos de trabajo, actividades y roles de esta fase asociados a






Gerente de proyecto


Gerente de proyecto





Requisitos Cápsula, protocolo Diseñar cápsula Diseñador de cápsula

Requisitos Realización de casos de uso

Diseñar caso de uso Diseñador

Requisitos Clase diseño Diseñar clase Diseñador

Requisitos Paquete de diseño Diseñar subsistema Diseñador

Requisitos Modelo de datos Diseñar base de datos Diseñador de base de datos


construcción. Elaboración propia del autor.

105




Requisitos Realización de casos de uso, capsula, clase diseño, interfaz

Diseñar clase de pruebas y paquetes

Diseñador


Sistema de software




Sistema de software



Sistema de software


Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software



Sistema de software



Implementador

Sistema de software


Sistema de software



Implementador

Sistema de software



Implementador



106




Sistema de software


Sistema de software



Probar el sistema

Sistema de software



Sistema de software

Registro de cambios, plan de prueba, configuración de ambiente de pruebas

Definir configuraciones de ambiente de pruebas


Sistema de software

Registro de cambios, especificación de interfaz de prueba

Identificar mecanismos de pruebas


Sistema de software

Registro de cambios, especificación de interfaz de prueba, componente de pruebas, configuración de ambiente de pruebas

Definir elementos de pruebas


Sistema de software

Caso de prueba Definir detalles de pruebas

Analista de pruebas

Sistema de software

Registro de cambios, configuración de ambiente de pruebas, Pruebas de script, test suite

Implementar prueba Suite

Tester

Sistema de software

Registro de cambios, test script

Implementar pruebas Tester

Sistema de software



Sistema de software



Tester

Sistema de software




Sistema de software

Lista de idas de prueba

Identificar ideas de pruebas

Analista de pruebas






Gerente de proyecto



107




Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo


Gerente de pruebas

Forma de trabajo


Analista de pruebas

Forma de trabajo


Forma de trabajo


Analista de pruebas

Forma de trabajo



Analista de pruebas

Forma de trabajo

Plan de pruebas Definir enfoque de prueba


Forma de trabajo


Definir enfoque de prueba


Forma de trabajo



Forma de trabajo



Gerente de proyecto

Forma de trabajo

Solicitud de cambio Diseñar base de datos Diseñador de base de datos



108




Forma de trabajo



Integrador




Gerente de proyecto

Forma de trabajo

Solicitud de cambio

Verificar la configuración de herramientas e instalación


Apoyar al equipo

Forma de trabajo


Cualquier rol

Forma de trabajo

Solicitud de cambio Lanzar caso de desarrollo


Forma de trabajo


Cualquier rol










Trabajo



Gerente de proyecto






Forma de trabajo



Forma de trabajo


cambio


Forma de trabajo






configuración




109




Forma de trabajo



Gerente de pruebas



Revisar el diseño Revisor de diseño















Evaluar esfuerzo de







Las prácticas definidas con los elementos del núcleo de Semat en la tercera fase de RUP se

visualizan en la sección ANEXOS.

Fase: Transición

En la Tabla 37 se presentan los productos de trabajo, actividades y roles de esta fase asociados a






Gerente de proyecto


Gerente de proyecto


transición. Elaboración propia del autor.

110





Estructurar el Modelo de caso de uso



Sistema de software




Sistema de software



Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software



Sistema de software



Implementador

Sistema de software


Sistema de software



Implementador

Sistema de software



Implementador

Sistema de software





111





Estructurar el Modelo de caso de uso



Sistema de software




Sistema de software



Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software




Sistema de software



Sistema de software



Implementador

Sistema de software


Sistema de software



Implementador

Sistema de software



Implementador

Sistema de software



Sistema de software




112



Probar el sistema

Sistema de software



Sistema de software



Tester

Sistema de software




Sistema de software

Lista de idas de prueba

Identificar ideas de pruebas

Analista de pruebas

Desplegar el sistema

Sistema de software

Artefactos de instalación

Desplegar los artefactos de instalación

Implementador

Sistema de software

Producto Lanzar versión solo de fabricantes

Gerente de despliegue

Sistema de software

Estilos gráficos del producto

Crear estilos gráficos del producto

Artista gráfico

Operar el sistema

Sistema de software

Lista de materiales Definir lista de materiales


Sistema de software

Material de entrenamiento

Desarrollar material de entrenamiento

Desarrollador de curso

Sistema de software

Material de soporte para el usuario final

Desarrollar material de soporte

Escritor técnico

Sistema de software

Notas Escribir notas Gerente de despliegue

Sistema de software

Producto Verificar el producto manufacturado







Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto



113




Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo



Gerente de proyecto

Forma de trabajo


Gerente de pruebas

Forma de trabajo


Analista de pruebas

Forma de trabajo


Forma de trabajo


Analista de pruebas

Forma de trabajo



Analista de pruebas

Forma de trabajo

Plan de pruebas Definir Enfoque de prueba


Forma de trabajo


Definir Enfoque de prueba


Forma de trabajo



Forma de trabajo


Desarrollar plan de Medición

Gerente de proyecto

Forma de trabajo



Integrador

Forma de trabajo

Plan de despliegue Desarrollar plan de despliegue



Forma de trabajo

Solicitud de cambio

Verificar de la configuración de herramientas e instalación




Gerente de proyecto

Apoyar al equipo

Forma de trabajo

Solicitud de cambio Lanzar caso de desarrollo




114



Apoyar al equipo

Forma de trabajo


Cualquier rol

Forma de trabajo


Cualquier rol










Trabajo



Gerente de proyecto






Forma de trabajo



Forma de trabajo


cambio


Forma de trabajo






configuración Gerente de configuración





Forma de trabajo

Solicitud de cambio Gestionar las pruebas

de aceptabilidad Gerente de despliegue

Forma de trabajo


Obtener comentarios

de pruebas Gerente de pruebas



115




Forma de trabajo



Gerente de pruebas











Evaluar esfuerzo de





Finalizar proyecto

Trabajo Revisión de registros Revisar aceptación de

proyecto Revisor de proyecto

Trabajo, Forma de trabajo

Evaluación de estados, lista de problemas, plan de desarrollo de software

Preparar el cierre del

proyecto Gerente de proyecto



Las prácticas definidas con los elementos del núcleo de Semat en la cuarta fase de RUP se visualizan

en la sección ANEXOS.

En RUP se exponen algunas directrices que en Semat se consideran recursos, este grupo se

visualiza en la Figura 46.

Figura 46. Recursos del método RUP. Elaboración propia del autor.

116

El grupo de competencias asociadas a los roles existentes en el método RUP se visualizan en la

Figura 47.

Figura 47. Competencias del método RUP. Elaboración propia del autor.

El grupo de roles existentes en la metodología RUP se visualizan en la Figura 48.

Figura 48. Roles del método RUP. Elaboración propia del autor.

El progreso del proyecto se mide mediante el cumplimiento de los estados de los alfas, al aplicar la

metodología se encuentra que de acuerdo a lo que Semat propone, en la Figura 49 se especifica los

estados que afectan la ejecución de actividades de RUP durante sus cuatro fases.

117

Figura 49. Progreso de un proyecto al aplicar la metodología RUP. Elaboración

propia del autor.

5 VALIDACIÓN

5.1 Validación del método CDM

En la literatura no se encontraron proyectos donde se aplica este método de desarrollo. Para realizar

la validación del método CDM Fast Track, se realiza un análisis de sus prácticas, haciendo una

comparación con los otros dos métodos representados en el núcleo de Semat en esta Tesis (véase

la Tabla 38).

PRÁCTICAS CDM UNC-METHOD RUP

Modelado de objetos de dominio X X X

Gestión de requisitos X X

Verificación continua de la calidad X X X

Modelado visual X X

Control de cambios de software X

Desarrollo basado en componentes X X

Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method.

Elaboración propia del autor.

118

PRÁCTICAS CDM UNC-METHOD RUP

Establecimiento de actividades para satisfacer las prácticas de calidad requeridas

Asignación de responsabilidad X X

Desarrollo iterativo X

Determinación de estimaciones de esfuerzo de trabajo y costo

X

Gestión de valor agregado

Visibilidad del progreso y resultados

Visualización del flujo de trabajo X

Formación del personal X

Suministro de recursos X

Planificación del proceso X

Monitoreo y control de procesos X

Tabla 38. Comparación de prácticas entre los métodos RUP, CDM y UNC-Method.


1. Práctica Modelado de objetos de dominio:

Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades que se

relacionan con el modelado del dominio. En la Tabla 39 se presentan algunos modelos y documentos

asociados con esta práctica.

Los productos de trabajo que comprende esta práctica se asocian con los alfas oportunidad e

interesados en los tres métodos.

Los productos de trabajo en los tres métodos se relacionan con el comportamiento de la

organización a la cual se le desarrollará la aplicación.

El método CDM Fast Track comprende un producto de trabajo “Definición de la estructura actual

y futura de la organización”, similar al “Organigrama” del UNC-Method.

Los modelos de CDM Fast Track provee un marco de trabajo global del negocio al igual que

RUP con el modelo de objeto del negocio y los casos de uso del negocio, y el UNC-Method con

el modelo del dominio.

CDM UNC-METHOD RUP

Modelo de proceso del contexto Dialogo controlado Modelo de objeto del negocio

Modelo de proceso de negocio de alto nivel

Modelo del dominio Modelo de casos de uso del negocio

Modelo compuesto de función del negocio

Cartas de educción Glosario del negocio

Negocio y objetivos del sistema Archivos digitales Visión del negocio

Descripciones del negocio de alto nivel

Reglas del negocio Reglas del negocio


Organigrama Evaluación de la organización objetivo

Tabla 39. Productos de trabajo asociados a la práctica Modelado de objetos del dominio.


119

2. Práctica Gestión de requisitos:

Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades y

productos de trabajo que se relacionan con el diseño del sistema. En la Tabla 40 se presentan

algunos documentos asociados con esta práctica.

Los productos de trabajo que comprende esta práctica se asocian con los alfa requisitos en los

dos métodos.

Los productos de trabajo en los dos métodos se relacionan con el diseño del sistema y las

actividades relacionadas con la educción de requisitos (documentos y modelos del sistema

existente y documentos del sistema a desarrollar).

Los métodos CDM Fast Track y RUP comprenden para este caso el mismo producto de trabajo,

el glosario.

CDM RUP

Glosario Glosario

Documentación de requisitos Atributos de requisitos

Interfaces del sistema existente Especificación de requisitos

Requisitos de formación Especificaciones suplementarias

Tabla 40. Productos de trabajo asociados a la práctica Gestión de requisitos. Elaboración

propia del autor.

3. La práctica Verificación continua de la calidad

Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar las actividades y

productos de trabajo que se relacionan con la verificación continua de la calidad de la aplicación que

se desarrolla. En la Tabla 41 se presentan algunos documentos asociados con esta práctica.

Los productos de trabajo que comprende esta práctica se asocian con el alfa sistema de software

en los dos métodos.

Los productos de trabajo en los dos métodos se relacionan con la validación del sistema de

software que se desarrolla, comprende las actividades relacionadas con el testing.

CDM RUP

Requisitos Validados Configuración de ambiente de pruebas

Resultados de la prueba del módulo de conversión

Caso de prueba

Resultados de las pruebas del sistema Pruebas de script

Resultados de la Prueba de Integración de sistemas

Test suite

Resultados de la Validación Preproducción Test log

Tabla 41. Productos de trabajo asociados a la práctica Verificación continua de la calidad.


4. La práctica Desarrollo basado en componentes

120

Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar el desarrollo de la

aplicación por partes para luego ser integrado. En la Tabla 42 se presentan algunos documentos

asociados con esta práctica.

Los productos de trabajo que comprende esta práctica se asocian con el alfa sistema de software

en los dos métodos.

Los productos de trabajo en los dos métodos se relacionan con la creación de componentes o

módulos que permitan trabajar por separado el desarrollo de la aplicación y luego realizar la

integración del mismo para obtener una aplicación funcional.

CDM RUP

Módulos documentados Componente

Módulo de conversión de datos Componente de prueba

Tabla 42. Productos de trabajo asociados a la práctica Desarrollo basado en componentes


5. La práctica Asignación de responsabilidad

Esta práctica se incluye en el núcleo de Semat con el objetivo de organizar los productos de trabajo

a actividades asociadas con la asignación de responsabilidades durante el desarrollo del proyecto.

En la Tabla 43 se presentan algunos documentos asociados con esta práctica.

Los productos de trabajo que comprende esta práctica se asocian con el alfa equipo en los dos

métodos.

Los productos de trabajo en los dos métodos se relacionan con la conformación del equipo de

trabajo que se va a desarrollar la aplicación, la asignación del trabajo de cada integrante dejando

en claro su organización.

CDM UNC-METHOD

Equipo de Proyecto Integrado Lista de roles y responsabilidades

Dotación de personal y Plan de su Organización

Tabla 43. Productos de trabajo asociados a la práctica Desarrollo basado en componentes.


Las otras prácticas como Suministro de recursos, Planificación del proceso y Monitoreo y control de

procesos se incluyeron por ser prácticas orientadas a la administración de proyectos. En el

documento original se propone el método PJM para complementar el método CDM, esto debido a

que CDM Fast Track es una versión que carece de actividades y productos de trabajo propios que

se relacionen con esta área del desarrollo.

A la práctica Suministro de recursos pertenece el siguiente producto de trabajo:

Lanzamiento de recursos físicos

121

Dotación de personal y plan de su organización

A la práctica Planificación del proceso pertenecen los siguientes productos de trabajo:



Organización preparada

Normas de definición de requisitos y directrices

Estrategias de control y presentación de informes, las normas y los procedimientos

Plan de trabajo

A la práctica Monitoreo y control de procesos pertenecen los siguientes productos de trabajo:

Auditoría de calidad

Reporte de calidad

Línea base auditada

5.2 Validación del UNC-METHOD

Para realizar la validación del UNC-Method se propone un análisis de laboratorio, para lo cual se

hace seguimiento a dos ejemplos de ejecución del método.

Caso de estudio 1: El primer ejemplo se basa en Zapata et al. [27], donde se especifica paso a paso

la aplicación del método, incluyendo los cuatro entregables correspondientes a las cuatro fases del

proceso de educción de requisitos. Se analizan las dos primeras fases del método siguiendo la

aplicación del proyecto que se desarrolló para el Departamento de Ciencias de la Computación y de

la Decisión de la Universidad Nacional de Colombia.

Caso de estudio 2: El segundo ejemplo se toma de Zapata [10]. En este libro se especifica paso a

paso la aplicación del método, los cuatro entregables correspondientes a las cuatro fases del proceso

de educción de requisitos, siguiendo la aplicación del proyecto ZenPhotoTM. La validación paso a

paso se expone en la sección ANEXOS.

Caso de estudio 1

En la primera fase Contexto del Software se presentan los siguientes productos de trabajo de

acuerdo con la secuencia de actividades que se visualiza en la Figura 33.

122

1. Se establece un diálogo controlado en lenguaje

natural, tal como se aprecia en la Figura 50.

Figura 50. Diálogo controlado [10]

Figura 51. Actividad Desarrollar entrevista

interesado-analista y producto de trabajo

Diálogo controlado. Elaboración propia

del autor.

2. A partir del diálogo controlado, se propone el

esquema preconceptual del mismo, incluyendo las

frases del diálogo que cumplen con las relaciones

dinámicas y estructurales que el esquema

preconceptual define (véase la Figura 52).

Figura 52. Esquema pre-conceptual [10]

Figura 53. Actividad Establecer un

vocabulario común y producto de trabajo

Esquema pre-conceptual. Elaboración

propia del autor.

3. Para conocer al interesado, se propone realizar el

organigrama de la empresa a la que se va a realizar

la aplicación, tal como se muestra en la Figura 54.

Figura 54. Organigrama [10]

Figura 55. Actividad Identificar los actores

internos y externos de la organización y

producto de trabajo Organigrama.


123

4. El modelo del dominio, se ilustra en la Figura 56.

Figura 56. Modelo del dominio [10]

Figura 57. Actividad Establecer un

vocabulario común y producto de trabajo

Modelo del dominio. Elaboración propia

del autor.

En la segunda fase, Análisis del problema, se esperan los siguientes productos de trabajo de

acuerdo con la secuencia de actividades que se visualiza en el Anexo A.1.

1. Lo primero que se establece son las reglas del negocio, necesarias para complementar la tabla

explicativa del diagrama de procesos (véase la Figura 59).

Figura 58. Actividad Establecer limitaciones del proceso y producto de trabajo Reglas del

negocio. Elaboración propia del autor.

Figura 59. Reglas del negocio [10]

2. Luego, se propone la representación del diagrama de procesos (véase la Figura 61).

124

Figura 60. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama

de procesos. Elaboración propia del autor.

Figura 61. Diagrama de procesos [10]

3. La tabla explicativa del diagrama de procesos (véase la Figura 63).

Figura 62. Actividad Caracterizar el dominio del problema y producto de trabajo Tabla

explicativa del diagrama de procesos. Elaboración propia del autor.

Figura 63. Tabla explicativa de procesos [10]

125

4. El diagrama de objetivos (véase las Figuras 65).


de objetivos. Elaboración propia del autor.

Figura 65. Diagrama de objetivos [10]

5. El diagrama causa-efecto (véase la Figura 67).


causa-efecto. Elaboración propia del autor.

Figura 67. Diagrama de causa y efecto [10]

126

6. Se desarrolla el diccionario de datos, tal como se muestra en la Figura 69.

Figura 68. Actividad Desarrollar el diccionario de datos y producto de trabajo Diccionario

de datos. Elaboración propia del autor.

Figura 69. Diccionario de datos [10]

5.3 Validación de RUP

Para realizar la validación de RUP se siguen dos proyectos que aplican el método en el proceso de

desarrollo de software. De acuerdo a en [28], se evidencian las experiencias de cuatro proyectos,

sin embargo se seleccionaron dos de ellos (A Y D). Las casillas coloreadas comprenden los roles,

artefactos y actividades que cada equipo utilizó para el desarrollo.

Las actividades presentes en las Tablas 44, 45, 46, 47, 48 y 49 son flujos de trabajo definidos en el

método RUP, es decir, cada uno de los elementos de la lista son un conjunto de actividades que en

muchos casos, tienen actividades en común. Por tal razón, las representaciones de los productos de

trabajo que se utilizaron durante el desarrollo se relacionan con más de una actividad, las cuales los

originan o modifican durante las fases del proyecto.

127

Tabla 44. Roles, artefactos y actividades

de la disciplina requisitos [28]

Requisitos A D

Roles

Analista de sistema

Especificador de casos de uso

Diseñador de interfaz de usuario

Arquitecto Artefactos

Glosario

Visión

Modelo de caso de uso

Especificaciones suplementarias Actividades

Analizar el problema Entender las necesidades de los interesados

Definir el sistema

Gestionar el alcance del sistema

Redefinir la definición del sistema

Gestionar requisitos cambiantes

128

Figura 70. Representación en Semat de actividades, roles y productos de trabajo de la disciplina requisitos. Elaboración propia del autor

129

Gestión de proyectos A D

Roles

Gerente de proyecto




Artefactos

Lista de riesgos

Caso de negocio

Plan de iteración


Base de datos de las medidas del proyecto

Solicitud de cambio

Orden de trabajo

Evaluación de iteración

Actividades

Concebir un nuevo proyecto

Planear próxima iteración

Gestionar iteración

Evaluar el objetivo y riesgo de proyecto

Desarrollar el plan de desarrollo de software


de la disciplina gestión de proyectos

[28]

130

Figura 71. Representación en Semat de actividades, roles y productos de trabajo de la disciplina gestión de proyectos. Elaboración

propia del autor.

131

Análisis y diseño A D

Roles

Ingeniero de seguridad

Integrador

Diseñador de base de datos


Diseñador de software

Artefactos


Modelo de diseño

Realización de casos de uso

Lista de riesgos

Visión

Solicitud de cambio

Interfaz

Subsistema de diseño

Especificaciones suplementarias

Clase de diseño

Modelo de datos

Clase de componente

Actividades

Definir una arquitectura candidata

Desarrollar síntesis de arquitectura

Analizar comportamiento

Redefinir la arquitectura

Diseñar componente

Diseñar la base de datos


de la disciplina análisis y diseño [28]

132

Figura 72. Representación en Semat de actividades, roles y productos de trabajo de la disciplina análisis y diseño. Elaboración propia

del autor.

133

Despliegue A D

Roles


Desarrollador de curso

Artefactos

Plan de despliegue

Lista de materiales

Material de entrenamiento

Infraestructura de despliegue

Producto

Unidad de despliegue

Actividades

Planear despliegue

Gestionar prueba de aceptación

Producir unidad de despliegue

Producir pruebas beta

Producto de paquete

Proveer acceso de sitio de descarga


de la disciplina despliegue [28]

Figura 73. Representación en Semat de actividades, roles y productos de trabajo de la disciplina despliegue. Elaboración propia del autor.

134

Implementación A D

Roles

Implementador


Integrador

Revisor de código

Tester

Artefactos

Subsistema de implementación


Componente

Componente de prueba

Construcción

Actividades

Estructurar el modelo de implementación

Planear la integración

Implemetar componentes

Integrar cada subsistema

Integrar el sistema


de la disciplina implementación [28]

Figura 74. Representación en Semat de actividades, roles y productos de trabajo de la disciplina implementación. Elaboración propia del autor.

135

Entorno A D

Roles

Gerente de proyecto

Integrador


Tester

Artefactos

Plan CM

Solicitud de cambio

Actividades

Planear configuración y cambios del proyecto

Crear ambiente CM de proyectos

Cambiar y deliverar items de configuración

Gestionar líneas bases

Monitoriar y reportar estado de configuración

Gestionar solicitud de cambios


de la disciplina entorno [28]

Figura 75. Representación en Semat de actividades, roles y productos de trabajo de la disciplina entorno. Elaboración propia del aurot.

136

6 CONCLUSIONES

La ingeniería de software tiene prácticas inmaduras. Los problemas específicos incluyen:

La falta de una adecuada y ampliamente aceptada base teórica.

El gran número de métodos y variantes de método, con diferencias poco entendidas y

amplificadas artificialmente.

La falta de evaluación y validación experimental creíbles.

La división entre la práctica de la industria y la investigación académica.

Las ventajas de utilizar el lenguaje de Semat para representar las diferentes prácticas son, entre

otras:

Es útil para investigadores y practicantes.

En Semat se pueden incluir todos los métodos y prácticas pertinentes.

Semat incluye un núcleo de elementos ampliamente acordados, extensible para usos

específicos y que se organiza mediante Alfas, que son elementos esenciales de esfuerzo de

ingeniería de que son relevantes para la evaluación del progreso y salud de las tareas.

Se clarifican las competencias pertinentes con cada actividad.

Se puede visualizar el progreso del proyecto a medida que el equipo de trabajo realiza sus

tareas diarias.

Se pueden representar las prácticas de manera independiente sin importar el método de

origen.

Sirve para equipos pequeños y para grandes organizaciones.

Las prácticas definidas en esta Tesis pertenecen a distintas metodologías de desarrollo, ya sean

métodos basados en planes o metodologías ágiles. La clasificación en Semat se realizó mediante

su definición, la cual presenta características que permitieron escoger el área de interés (Cliente,

solución o esfuerzo) al que pertenecen.

Rational Unified Process es un método que define seis mejores prácticas que abarcan aspectos

generales del desarrollo de software. Por ejemplo, la práctica gestión de requisitos agrupa no sólo la

creación de los documentos necesarios para definir el sistema, sino que incluye la creación de

documentos del negocio o empresa para la cual se realiza la aplicación. Esto podría separarse en

dos prácticas propuestas en la Tesis para lograr la separación de intereses, las prácticas Gestión de

requisitos y Modelado de objetos de dominio respectivamente.

137

El método RUP define como artefactos diferentes directrices, que determinan cómo hacer el trabajo

durante el desarrollo de software. En Semat, este tipo de artefactos como no se crean o se modifican

en el tiempo, se definen como recursos y se representan mediante el elemento patrón.

La práctica Modelado visual se define como la agrupación de actividades, que involucran la creación

o modificación de modelos necesarios para definir el sistema. En RUP se utilizan los diagramas UML.

Sin embargo, el UNC-Method y Custom Development Method definen otros tipos de diagramas o

esquemas.

El UNC-Method es método de desarrollo que se enfoca principalmente en la educción de requisitos,

la definición del sistema hasta llegar a un prototipo alfa y al conocimiento del tiempo y valor que el

desarrollo de la aplicación puede tomar. Por esta razón, en el progreso o avance del proyecto,

medido mediante los alfas, no se alcanza a cumplir la lista de chequeo de los últimos estados.

CDM Fast Track es una metodología que no define actividades o artefactos para la administración

del proyecto, por lo cual utilizan las actividades definidas en PJM, de esta forma se complementa el

progreso o avance reflejado en el cumplimiento de todos los estados de los alfas definidos en el

núcleo.

7 BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN

[1] I. Jacobson, P. Ng, P.E. McMahon, I. Spence y S. Lidman. “The Essence of Software

Engineering: The SEMAT Núcleo”. Communications of the ACM, vol. 55, no. 12, pp. 42-49, 2012.

[2] A. O Duarte y M. Rojas. “Las metodologías de Desarrollo Ágil como una Oportunidad para la

Ingeniería del Software Educativo”. Avances en Sistemas e Informática, vol. 5, no. 2, 2009.

[3] R. Úbeda. “Métodos ágiles para el desarrollo de software”. Tesis de Maestría. Universidad

Politécnica de Cataluña, 2009.

[4] Essence –Kernel and Language for Software Engineering Methods. V 1.3, 2013.

[5] C. M. Zapata, F. I. Caraballo, K. Villamizar. “Conocimiento en coaching: su representación

mediante un esquema preconceptual”. Revista Universidad EAFIT, vol. 46, no. 158, pp. 22-33,

2010.

[6] Oracle Method SM. CDM Fast Track Method Handbook. Versión 1.2.0, 2000.

[7] F. I. Caraballo. “Método para la educción de problemas y objetivos en el Coaching ágil”. Tesis

de maetría, Escuela de sistemas, Universidad Nacional de Colombia, Medellín, Colombia, 2012.

[8] C. M. Zapata, S. S. Villegas y I. F. Arango. “Reglas de consistencia entre modelos de requisitos

de Un-Método”. Revista Universidad EAFIT, vol. 42, no. 141, pp. 40-59, 2012.

138

[9] C.M. Zapata. “The UNC-Method revisited: elements of the new approach”. Saarbrüken: Lambert

Academic Publishing.

[10] C. M. Zapata. “Unc-Method Revisited: Elements of the New Approach Eliciting Software

Requirements in a Complete, Consistent, and Correct Way”. LAP Lambert Academic Publishing,

Germany, 2012.

[11] O. A. Pérez. “Cuatro enfoques metodológicos para el desarrollo de Software RUP–MSF–XP-

SCRUM”. Revista Inventum, no. 10, 2011.

[12] C. Larman. “Estructura” en UML y Patrones: Una introducción al análisis y diseño orientado a

objetos y al proceso unificado, segunda edición, Prentice-Hall, 2002.

[13] I. Jacobson, G. Booch y J. Rumbaugh. “El proceso unificado de Desarrollo de software”, Pearson

Education S.A., Madrid, España, 2000.

[14] P. Kruchten. “Static structue: Process description” en The Rational Process Unified: an

introduction, Addison Wesley, 2003, pp. 336.

[15] J. Passing. “Requirements engineering in the Rational Unified Process”, Seminar Requirements

Engineering, Summer term, Hasso Plattner Insitute for Software Systems Engineering, p. 16,

2006.

[16] P. Kruchten, “Procesos de las disciplinas” en Rational Unified Process, The: An Introduction,

tercera edición, Addison Wesley, 2003.

[17] H. A. Fernández. “Procesos de ingeniería de software”. Vínculos, vol. 10, pp. 26-39, 2013.

[18] A. Navarro, J. D. Fernández y J. Morales. “Revisión de metodologías ágiles para el desarrollo de

software A review of agile methodologies for software development. Prospect”. vol. 11, no. 2, pp.

30-39, 2013.

[19] D. M. Owens y, D. Khazanchi. “Software Quality Assurance. Handbook of Research on

Technology Project Management”, Planning, and Operations, 2009.

[20] L. Guzmán y M. Visconti. “Propuesta de Herramientas Genéricas para Implantación de Prácticas

en SQA y SCM”, Actas VIII Encuentro Chileno de Computación, Santiago, Chile, 2000.

[21] Y. Gascón y A. Marcano. “Método de valor ganado en la gerencia de proyectos”. 9th Latin

American and Caribbean Conference for Engineering and Technology Medellín, Colombia, 2011.

[22] M. B. Chrissis, M. Konrad y S. Srhum. “Guía para la integración de procesos y la mejora de

productos”, Segunda edición, 2009.

[23] H. Arboledaa, A. Paz y R. Casallas. “Metodología para implantar el Modelo Integrado de

Capacidad de Madurez en grupos pequeños y emergentes”. Estudios Gerenciales, vol. 29, no.

127, pp. 177–188, 2013.

[24] R. Habraken. “Using qualitative research methodologies in IS development studies”. Tesis de

maestría, Universidad Radboud, Nijmegen, 2005.

139

[25] C. M. Zapata, G. González, R. Manjarrés, F. A. Vargas y W. Arévalo. Software engineering:

methods, modeling, and teaching´, vol. 3, Medellín: Centro Editorial de la Facultad de Minas,

2014.

[26] C. M. Zapata, L. A. Lezcano y P. A. Tamayo. “Validación del método para la obtención automática

del diagrama de objetivos desde esquemas preconceptuales”. Revista EIA, vol. 8, pp. 21-39,

2007.

[27] C. M. Zapata. “Un modelo de diálogo para la generación automática de especificaciones en un-

LENCEP”, Universidad Nacional de Colombia Sede Medellín. Facultad de Minas, Medellín, 2010.

[28] G. K. Hanssen, H. Westerheim y F. O. Bjørnson. “Using Rational Unified Process in an SME – A

Case Study”. Software Process Improvement, Springer Berlin Heidelberg, pp. 142-150, 2005.

140

ANEXOS Anexo A. Fase 2 del UNC-Method: Análisis del problema

Anexo A.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.

141

Anexo A.2. Definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.

142

Anexo A.3. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

143

Anexo B. Fase 3 del UNC-Method: Propuesta de solución

Anexo B.1. Secuencia de actividades en la fase y definición de la práctica Modelado visual. Elaboración propia del autor.

144

Anexo B.2. Definición de las prácticas Gestión de requisitos y Monitoreo y control del proceso. Elaboración propia del autor.

145

Anexo B.3. Definición de la práctica Determinación de estimaciones de esfuerzo de trabajo y costo. Elaboración propia del autor.

146

Anexo C. Fase 4 del UNC-Method: Esquema conceptual

Anexo C.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.

147

Anexo C.2. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

148

Anexo C.3. Definición de la práctica Modelado visual. Elaboración propia del autor.

149

Anexo D. Fase 2 de CDM: Modelado de requisitos

150

Anexo D.1. Secuencia de actividades en la fase y definición de la práctica Modelado de objetos de dominio. Elaboración propia del autor.

151

152

Anexo D.2. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

153

154

155

Anexo D.3. Definición de la práctica Planificación del proceso. Elaboración propia del autor.

156

Anexo D.4. Definición de la práctica Suministro de recursos. Elaboración propia del autor.

Anexo D.5. Definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.

157

Anexo E. Fase 3 de CDM: Diseño de sistemas y generación

Anexo E.1. Secuencia de actividades en la fase y definición de la práctica Monitoreo y control del proceso. Elaboración propia del auto

158

Anexo E.2. Definición de la práctica Verificación continua de la calidad. Elaboración propia del autor.

159

160

Anexo E.3. Definición de la práctica Planificación del proceso. Elaboración propia del autor.

161

Anexo E.4. Definición de la práctica Suministro de recursos. Elaboración propia del autor.

162

Anexo E.5. Definición de la práctica Desarrollo basado en componentes. Elaboración propia del autor.

163

164

Anexo E.5. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

165

Anexo F. Fase 4 de CDM: Transición a la producción

166

Anexo F.1. Secuencia de actividades en la fase y definición de la práctica Planificación del proceso. Elaboración propia del autor.

167

Anexo F.2. Definición de la práctica Monitoreo y control del proceso. Elaboración propia del autor.

168

169

Anexo F.3. Definición de la práctica Gestión de requisitos. Elaboración propia del autor.

170

171

Anexo F.4. Definición de la práctica Verificación continua de la calidad. Elaboración propia del autor.

172

Anexo G. Fase 2 de RUP: Elaboración

173

174

175

Anexo G.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.

176

177

178

179

Anexo G.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.

180

Anexo G.3. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.

181

Anexo G.4. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.

182

183

184

185

186

187

188

Anexo G.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.

189

Anexo H. Fase 3 de RUP: Construcción

190

191

Anexo H.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.

192

193

194

Anexo H.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.

195

Anexo H.3. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.

196

Anexo H.4. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.

197

198

199

200

201

202

203

Anexo H.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.

204

Anexo I. Fase 4 de RUP: Transición

205

Anexo I.1. Representación gráfica de la práctica Gestión de requisitos. Elaboración propia del autor.

206

207

208

Anexo I.2. Representación gráfica de la práctica Modelado visual. Elaboración propia del autor.

209

Anexo I.3. Representación gráfica de la práctica Verificación continua de la calidad. Elaboración propia del autor.

210

Anexo I.4. Representación gráfica de la práctica Desarrollo basado en componentes. Elaboración propia del autor.

211

212

213

214

215

216

217

Anexo I.5. Representación gráfica de la práctica Control de cambios de software. Elaboración propia del autor.

218

Anexo J. Validación del UNC-Method (Caso de estudio 2)

En esta sección se presenta el caso de estudio 2 de validación del UNC-Method, para su desarrollo

se expone en paralelo el producto de trabajo y su representación en Semat, especificando el alfa

asociado, la actividad y el rol relacionado.

En la primera fase Contexto del Software se presentan los siguientes productos de trabajo de

acuerdo con la secuencia de actividades que se visualiza en la Figura 33.

1. Se establece un diálogo controlado en lenguaje

natural, tal como se aprecia en el Anexo J.1.

Anexo J.1. Diálogo controlado [10]

2. A partir del diálogo controlado, se propone el

esquema preconceptual del mismo, incluyendo las

frases del diálogo que cumplen con las relaciones

dinámicas y estructurales que el esquema

preconceptual define (véase el Anexo J.2).

Anexo J.2. Esquema pre-conceptual [10]

Anexo J.3. Actividad Desarrollar entrevista

interesado-analista y producto de trabajo

Diálogo controlado. Elaboración propia del

autor.

Anexo J.4. Actividad Establecer un vocabulario

común y producto de trabajo Esquema pre-

conceptual. Elaboración propia del autor.

219

3. Para conocer al interesado, se propone realizar el

organigrama de la empresa a la que se va a realizar

la aplicación, tal como se muestra en el Anexo J.5.

Anexo J.5. Organigrama [10]

4. Se presentan las tarjetas de educción (véase el

Anexo J.7).

Anexo J.7. Tarjetas de educción [10]

5. El modelo del dominio, se expresa a continuación:

Anexo J.9. Modelo del dominio [10]

Anexo J.6. Actividad Identificar los actores

internos y externos de la organización y

producto de trabajo Organigrama. Elaboración

propia del autor.

Anexo J.8. Actividad Resumir la información

relacionada con los actores, los objetos y las

funciones y producto de trabajo Tarjetas de

educción. Elaboración propia del autor.

Anexo J.10. Actividad Establecer un vocabulario

común y producto de trabajo Modelo del

dominio. Elaboración propia del autor.

220

En la segunda fase, Análisis del problema, se esperan los siguientes productos de trabajo de acuerdo

con la secuencia de actividades que se visualiza en el Anexo A.1.

1. Lo primero que se establece son las reglas del negocio, necesarias para complementar la tabla

explicativa del diagrama de procesos (véase el Anexo J.12).

Anexo J.11. Actividad Establecer limitaciones del proceso y producto de trabajo Reglas del

negocio. Elaboración propia del autor.

Anexo J.12. Reglas del negocio [10]

2. Luego, se propone la representación del diagrama de procesos (véase el Anexo J.14).

Anexo J.13. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama de

procesos. Elaboración propia del autor.

221

Anexo J.14. Diagrama de procesos [10]

3. La tabla explicativa del diagrama de procesos (véase el Anexo J.16)

Anexo J.15. Actividad Caracterizar el dominio del problema y producto de trabajo Tabla

explicativa del diagrama de procesos. Elaboración propia del autor.

Anexo J.16. Tabla explicativa de procesos [10]

4. El diagrama de objetivos (véase el Anexo J.18).

Anexo J.17. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama de

objetivos. Elaboración propia del autor.

222

Anexo D.18. Diagrama de objetivos [10]

5. El diagrama causa-efecto (véase el Anexo J.20).

Anexo J.19. Actividad Caracterizar el dominio del problema y producto de trabajo Diagrama

causa-efecto. Elaboración propia del autor.

Anexo J.20. Diagrama de causa-efecto [10]

6. Se desarrolla el diccionario de datos, tal como se muestra en el Anexo J.22.

Anexo J.21. Actividad Desarrollar el diccionario de datos y producto de trabajo Diccionario de

datos. Elaboración propia del autor.

223

Anexo J.22. Diccionario de datos [10]

En la tercera fase Propuestas de solución los siguientes productos de trabajo de acuerdo con la

secuencia de actividades que se visualiza en el Anexo B.1

De acuerdo al ejemplo, el diagrama de procesos y organigrama expuestos en las fases anteriores son

válidos.

1. Casos de uso:

Anexo J.23. Casos de uso [10]

Anexo J.24. Actividad Especificar la

funcionalidad de la aplicación de software y

producto de trabajo Casos de uso. Elaboración

propia del autor.

2. Diagrama de interfaz de usuario:

Anexo J.25. Diagrama de interfaz de usuário

[10] Anexo J.26. Actividad Especificar la


producto de trabajo Diagrama de flujo de

interfaz de usuario. Elaboración propia del

autor.

224

3.Factores críticos de éxito:

Anexo J.27. Factores críticos de éxito [10]

Anexo J.28. Actividad Establecer factores

críticos de éxito y producto de trabajo Factores

críticos de éxito. Elaboración propia del autor.

Adicionalmente, en esta fase se establece el valor de la solución. Tal como se puede ver en los Anexos

K.30 y K.31, se generan dos productos de trabajo: el costeo de la solución y la valoración de la

propuesta.

4. Valoración de la propuesta:

Anexo J.29. Actividad Establecer el valor de la solución y productos de trabajo Valoración de

la propuesta y Costeo de la propuesta. Elaboración propia del autor.

Anexo J.30. Tabla de valoración de la propuesta [10]

5. Costeo de la solución:

225

Anexo D.31. Costeo de la solución [10]

En la fase Esquema conceptual se presentan los siguientes productos de trabajo de acuerdo con la

secuencia de actividades que se visualiza en el Anexo C.1.

Para proporcionar las bases para la construcción de la aplicación final y desarrollar el prototipo alfa,

se requiere especificar la funcionalidad de la aplicación de software y conocer el esquema

preconceptual. A continuación se modela el comportamiento de la aplicación (véaselos Anexos K.32,

K.34, K.36 y K.38) y se muestra el código fuente (véase el Anexo J.40).

1. Esquema preconceptual basado en

especificaciones:

Anexo J.32. Esquema pre-conceptual con

especificaciones [10]



producto de trabajo Especificaciones basadas

en el esquema preconceptual. Elaboración

propia del autor.

2. Diagrama de clases:

Anexo J.34. Diagrama de clases [10]



producto de trabajo Especificaciones basadas

en el Diagrama de clases. Elaboración propia

del autor.

226

3. Diagrama de comunicaciones:

Anexo J.36. Diagrama de comunicaciones [10]



producto de trabajo Diagrama de

comunicaciones. Elaboración propia del autor.

4. Diagrama de máquina de estados:

Anexo J.38. Diagrama de máquina de estados [10]

5. Ejemplos de código:

Anexo J.40. Código fuente [10]



producto de trabajo Diagrama de máquinas de

estado. Elaboración propia del autor.

Anexo J.41. Actividad Proporcionar las bases

para la construcción de la aplicación final y

producto de trabajo Ejemplo de código fuente.


Documents

REPRESENTACIÓN EN EL NÚCLEO DE SEMAT DE PRÁCTICAS