tesis de maestría en proceso metodolÓgico...
TRANSCRIPT
I
TESIS de Maestría en
Ingeniería en Sistemas de Información
"PROCESO METODOLÓGICO PARA LA MEJORA CONTINUA
DE LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE
BASADO EN EL ÁREA DE PROCESO DE MANEJO DE
REQUERIMIENTOS DE CMMI DEV V1.3”
Tesista: Ing. Boris Paredes Castañeda
Director: Dr. Alejandro Hossian
Codirector: Mg. Fernanda Scalone
Ciudad Autónoma de Buenos Aires, 2015
II
DEDICATORIA
A Dios TodoPoderoso, quien me ha dado fortaleza todo este tiempo para continuar cuando
a punto de caer he estado; por ello, con toda la humildad que de mi corazón puede emanar,
dedico primeramente al creador de todas las cosas.
A mi mamalolita, Zoila Bazán(Q.E.P.D), porque siempre ha sembrado en mí rectitud y
regalarme mucho cariño.
A mi padre Juan Francisco y a mi madre Lilia Gladis, porque me dieron vida, educación
y apoyo incondicionalmente.
A mi esposa Aurora por su apoyo y aliento para continuar, cuando parecía que me iba a
rendir.
A mis hijos Lilia y Joan quienes me inspiraron y motivaron para cumplir con este
objetivo.
III
AGRADECIMIENTOS
Agradezco a Dios y a la Virgen María, por protegerme durante todo mi andar y darme
fuerzas para superar obstáculos y dificultades a lo largo de toda mi vida.
A la Universidad Tecnológica Nacional, por haberme dado la oportunidad de ser uno de
sus integrantes y brindarme todos los conocimientos a través de sus reconocidos maestros.
A mi director de Tesis Ing. Dr. Alejandro Hossian, por su asesoría y dedicación en el
desarrollo de la tesis.
A mi codirectora de Tesis. Mg. Lic. Fernanda Scalone, quien con su amplia experiencia y
paciencia hizo posible la culminación de la tesis.
A la docente Dra. Paola Britos, por su orientación y valiosa colaboración en el desarrollo del
proyecto de tesis.
A la Mg. Ing. Estela Pineda, por su colaboración en la tesis.
IV
INDICE
INDICE DE FIGURAS ............................................................................................................ VI
RESUMEN ............................................................................................................................ VIII
ABSTRACT ............................................................................................................................. IX
CAPITULO 1. INTRODUCCION ............................................................................................ 1
1.1. Objetivos .......................................................................................................................... 1
1.1.1. Objetivo general ....................................................................................................... 1 1.1.2. Objetivos específicos ............................................................................................... 1
1.2. Alcance............................................................................................................................. 1
1.3. Fundamentos del trabajo ................................................................................................. 2
1.4. Metodología de Desarrollo de la Tesis ............................................................................ 3
1.5. Estructura del trabajo ....................................................................................................... 4
CAPITULO 2. ESTADO DE LA CUESTION .......................................................................... 6
2.1. Elicitación de requerimientos de software ...................................................................... 6
2.1.1. El proceso de elicitación. ......................................................................................... 6
2.1.2. Fuentes de los requerimientos. ................................................................................. 9 2.1.3. Técnicas de elicitación. .......................................................................................... 11 2.1.4. Identificación de los participantes en la elicitación de requerimientos. ............... 15
2.2. Requerimientos de Software ......................................................................................... 17
2.2.1. Definición de requerimiento. ................................................................................. 17
2.2.2. Características de los requerimientos. ................................................................... 18
2.2.3. Importancia de los Requerimientos ....................................................................... 18 2.2.4. Dificultades para definir los requerimientos ......................................................... 19 2.2.5. Clasificación de los requerimientos. ...................................................................... 19
2.3. Ingeniería de Requerimientos ....................................................................................... 20
2.3.1 Definición de Ingeniería de Requerimientos .......................................................... 20
2.3.2. Importancia de la Ingeniería de Requerimientos ................................................... 22 2.3.3. Estructura de la Ingeniería de Requerimientos. ..................................................... 22 2.3.4. Proceso de la Ingeniería de Requerimientos. ........................................................ 24 2.3.5. Clasificación de los Requerimientos ..................................................................... 30 2.3.6. Documento de los requerimientos. ........................................................................ 30
2.4. Modelo de Madurez de Capacidades Integrado. CMMI-DEV v1.3 ............................ 31
2.4.1 Componentes del CMMI-DEV V1.3. ..................................................................... 32 2.4.2. Áreas de Proceso de Ingeniería CMMi Dev v1.3. ................................................ 37 2.4.3. Gestión de Requerimientos (REQM) en el CMMI-DEV V1.3. ........................... 38
2.5. Ciclo de Deming ............................................................................................................ 44
2.5.1. Análisis de las fases del ciclo de Deming. ............................................................. 47
CAPITULO 3. PROBLEMA ................................................................................................... 50
V
3.1. Introducción ................................................................................................................... 50
3.2. Descripción del problema ............................................................................................. 50
3.3 Preguntas de investigación ............................................................................................. 52
CAPITULO 4. SOLUCIÓN ..................................................................................................... 53
4.1 Análisis del proceso metodológico planteado ............................................................... 53
4.2. Solución Propuesta ........................................................................................................ 53
CAPITULO 5. VALIDACION DE LA SOLUCION PROPUESTA ...................................... 66
5.1 Planteo de Caso de Estudio 1 y Formularios ................................................................ 66
5.2 Planteo de Caso de Estudio 2 y Formularios ................................................................ 74
CAPITULO 6. CONCLUSIONES Y APORTACIONES DE ESTA TESIS .......................... 82
6.1 Conclusiones y Aportes .................................................................................................. 82
6.1.1 Valoración sobre la investigación documental ....................................................... 82
6.1.2 Valoración del problema. ........................................................................................ 82 6.1.3. Valoración de la Solución ...................................................................................... 83 6.1.4. Valoración del caso de Estudio. ............................................................................. 83
6.1.5. Respuesta a los interrogantes de investigación. .................................................... 84 6.1.6. Aportes de la Tesis. ................................................................................................. 84
6.2. Futuras Líneas de investigación. ................................................................................... 84
CAPITULO 7. REFERENCIAS .............................................................................................. 86
ANEXO – GLOSARIO DE TERMINOS ............................................................................... 88
VI
INDICE DE FIGURAS
N° Figura Pág.
1 Modelo de Cascada del proceso de educción. 7
2 El proceso de adquisición y análisis de requerimientos 9
3 Posibles fuentes de requerimientos 10
4 Estructura de la Ingeniería de Requerimientos. 23
5 Gestión de Requerimientos. 24
6 Proceso de Ingeniería de Requerimientos. 25
7 Proceso de Ingeniería de Requerimientos 28
8 Proceso de Obtención y Análisis de Requerimientos 29
9 Componentes del Modelo CMMI (CMMI-DEV v1.3) 33
10 Comparativa de los Niveles de Capacidad y de Madurez 35
11 Elementos de un Áreas de Procesos (CMMi Dev v1.3) 36
12 Ciclo de Mejora Continua basado en PDCA 46
13 Interacción Analista – Usuario 52
14 Solución propuesta 54
15 Template del Tab N° 1 57
16 Template del Tab N° 2 58
17 Template del Tab N° 3 59
18 Template del Tab N° 4 59
19 Template del Tab N° 5 60
20 Template del Tab N° 6 61
21 Template del Tab N° 7 62
22 Template del Tab N° 8 63
23 Template del Tab N° 9 64
24 Template del Tab N° 10 64
25 Template del Tab N° 11 65
26 Tab1 Plan Caso Estudio 1 68
27 Tab2 Informes Plan 68
28 Tab3 Ejecución del Plan 69
VII
29 Tab4 Informes Ejecución 69
30 Tab5 Control 70
31 Tab6 Informes Control 70
32 Tab7 Evaluación 71
33 Tab8 Informes Evaluación 71
34 Tab9 Mejoras 72
35 Tab10 Informes Mejora 72
36 Tab11 Resumen 73
37 Tab1Plan 76
38 Tab2 Informes Plan 76
39 Tab3 Ejecución 77
40 Tab4 Informes Ejecución 77
41 Tab5 Control 78
42 Tab6 Informes Control 78
43 Tab7 Evaluación 79
44 Tab8 Informes Evaluación 79
45 Tab9 Mejoras 80
46 Tab10 Informes Mejora 80
47 Tab11 Resumen 81
VIII
RESUMEN
Este trabajo de tesis consiste en desarrollar un proceso metodológico para mejorar la
elicitación de requerimientos de software en la cual está basada del área de proceso de
Manejo de Requerimientos de CMMi para Desarrollo v1.3.
Este proceso metodológico tiene establecido un alcance, el cual consiste en considerar la
elicitación de requerimientos como parte de la ingeniería de requerimientos. La propuesta
de este proceso metodológico plantea la integración del área de proceso de Manejo de
Requerimientos de CMMi Dev. con el ciclo de Deming. De esta forma, se aplica cada paso
de este Ciclo (Planificación – Ejecución – Control – Mejora) al Manejo de Requerimientos.
Es decir, se planifican estimativamente los requerimientos a desarrollar, se implementan las
prácticas específicas del área de proceso mencionada, se controlan los requerimientos
implementados y, en caso de ser necesario, se realizan mejoras a los requerimientos
controlados. La futura planificación de la mejora a implementar permite reiniciar el Ciclo
de Deming.
IX
ABSTRACT
This professional thesis consists of a development of a methodological process to improve
software requirements elicitation which is based on the Requirements Management Process
Area of CMMI for Development v1.3.
This methodological process has established a scope which is to consider the elicitation of
requirements as part of Requirements Engineering. The purpose of this methodological
process is to establish the integration of Requirements Management Process Area of
CMMI Dev with Deming cycle.
In this manner, each step of Deming cycle (Plan, Do, Control and Act) is applied to
Requirements Management Process Area. It means, the requirements of development are
planned at a flat rate, the specific practices of the process area are implemented, the
implemented requirements are checked and, if necessary, controlled requirements are
improved. The improvement planning future to implement allows to restart the Deming
Cycle.
1
CAPITULO 1. INTRODUCCION
En este capítulo la presente tesis de investigación plantea el desarrollo de un trabajo
estableciendo los objetivos, el alcance y los fundamentos. Y para finalizar, este trabajo de
investigación describe un proceso metodológico para el desarrollo de la tesis.
1.1. Objetivos
1.1.1. Objetivo general
Desarrollar un proceso metodológico para la mejora continua de la elicitación de
requerimientos de Software basado en el área de proceso de REQM de CMMI DEV
v1.3.
1.1.2. Objetivos específicos
Proponer un proceso metodológico basado en el ciclo de Deming.
Integrar el área de proceso REQM de CMMI DEV v1.3 al ciclo de Deming.
Proponer mejoras acerca de la elicitación de requerimientos teniendo en cuenta el
proceso metodológico desarrollado en el punto primero.
1.2. Alcance
El alcance de este trabajo de tesis consiste en:
A partir de las necesidades del cliente, se debe determinar cuáles son los futuros
requerimientos funcionales o técnicos del producto a desarrollar y también cómo son
administrados teniendo en cuenta la KPA REQM de CMMi.
Esta KPA es implementada en la etapa “Ejecución” del ciclo de Deming. El resto de las
etapas del ciclo de Deming, aplicadas a la Gestión de Requerimientos, son ejecutadas de
acuerdo a su finalidad implícita, es decir, Planificar, Controlar, Evaluar y Mejorar la Gestión
de Requerimientos.
Los requerimientos son administrados mediante el desarrollo de un proceso metodológico
teniendo en cuenta la elicitación de los requerimientos de software.
2
1.3. Fundamentos del trabajo
Existe una tendencia mundial en elaborar normas y modelos de procesos de Ingeniería de
sistemas y de software que luego son adoptadas por la industria del software: Software
Engineering Body of Knowledge (SWEBOK), Application and Management of the Systems
Engineering Process (ISO/IEC 26702), Guide for Developing System Requirements
Specifications (IEEE std. 1233), Capability Maturity Model Integration (CMMI DEV),
Quality Management Systems - Requirements (ISO 9001), Service Management (ISO
20000), Process Assessment (ISO/IEC 15504) y Modelo de Proceso de Software
(Moprosoft). Actualmente esta tendencia se está acentuando en la Industria del Software,
considerando como ejemplo el modelo CMMI del SEI, y los nuevos modelos
COMPETISOFT (Iberoamericano), e ITMark (ESI Center).
Esta tendencia responde a las siguientes necesidades detectadas en la industria de desarrollo del
software: falta de un proceso formal, falta de comunicación directa de las empresas con sus
clientes, carencia de planificación, etc. Estas necesidades se han resuelto con éxito, dado que
las empresas que las adoptan mejoran la capacidad de sus procesos, lo que se traduce en
mejoras en los productos entregados y una mayor satisfacción de los clientes. Las
organizaciones que no adoptan buenas prácticas de calidad, brindan un servicio cuya calidad
depende de la idoneidad de su personal, con el riesgo que esto implica.
Dentro de los procesos de desarrollo de software, la Ingeniería de Requerimientos (IR) es
particularmente crítica debido a que los errores que se presentan en esta etapa originan
inevitablemente problemas posteriores que afectan a todo el ciclo de vida.
Por tal razón, se propone desarrollar un proceso metodológico que permita mejorar
continuamente la elicitación de requerimientos del software (tomando en cuenta el KPA
ReqM CMMi) basado en el ciclo de Deming o ciclo de mejora contínua conformado por las
siguientes etapas: Planificación, Ejecución, Control, Evaluación y Mejora. Estas etapas
permiten plantear una retroalimentación basada en las observaciones o no conformidades
detectadas, las cuales son planificadas nuevamente para su futura corrección. Este ciclo puede
ser aplicado en pequeños y grandes proyectos con el fin de obtener excelentes resultados en
la gestión de proyectos de desarrollo de software. Estas etapas pertenecientes al ciclo de
Deming pueden ser aplicadas a los procesos de conceptualización, diseño, ejecución y
evaluación de proyectos de desarrollo de software, centrados en la orientación por objetivos,
3
en la orientación hacia grupos beneficiarios y en poder facilitar la participación y
comunicación entre las partes interesadas.
Este proceso metodológico propuesto permitiría integrar el ciclo de Deming y el área de
proceso de gestión de requerimientos de CMMI con la finalidad de implementar cada etapa
de Deming teniendo en cuenta esta área de proceso. En la “Planificación” se realiza un plan
respecto de los futuros requerimientos. En la “Ejecución” se implementan los componentes
del área de proceso de Gestión de Requerimientos de CMMI. En el “Control” se realizan
revisiones respecto de las implementaciones llevadas a cabo. En el caso que las revisiones no
sean satisfactorias, se implementan acciones de mejora. En la “Evaluación”, se realizan
evaluaciones cuantitativas usando métricas o indicadores. Por último, en la “Mejora”, en
caso de tener controles o evaluaciones insatisfactorias, se implementan las acciones
correctivas y/o preventivas correspondientes. Dichas mejoras deben ser planificadas
nuevamente para su futura implementación.
Por lo tanto se propone llevar a cabo un proceso metodológico que integre el ciclo de Deming
con la elicitación de requerimientos de desarrollo de software perteneciente al área de
proceso de Gestión de Requerimientos de CMMI, como alternativa para un mejor
entendimiento y negociación con los involucrados y para el problema a resolver, ya que la
elicitación es una de las actividades más problemáticas y con mayores índices de fallas y
fracasos en el proceso de desarrollo de software. Dicha elicitación es implementada en la
parte “Ejecución”, según el ciclo de Deming, teniendo en cuenta las prácticas específicas del
área de proceso de Gestión de Requerimientos de CMMI DEV v1.3.
1.4. Metodología de Desarrollo de la Tesis
Mediante esta metodología de desarrollo de la tesis se pretende desarrollar un proceso
metodológico que permita mejorar continuamente la elicitación de requerimientos de
Software basado en el área de proceso de Gestión de Requerimientos de CMMi para
Desarrollo.
Para ello, se realizan los siguientes pasos metodológicos:
En el primer paso se realiza un estudio de la teoría de la elicitación de requerimientos de
Software.
El segundo paso consiste en el estudio y análisis de los requerimientos de software.
El tercer paso se basa en el estudio de la Ingeniería de Requerimientos, la cual contempla el
proceso de elicitación. Este proceso es analizado desde el punto de vista del desarrollo de
4
software con el fin de identificar los elementos a tener en cuenta para integrarlos al nuevo
proceso metodológico.
En el cuarto paso se hace el análisis y estudio del área de proceso de Gestión de
Requerimientos del modelo de CMMi Dev v1.3.
En el quinto paso se estudia el ciclo de mejora continua de Deming.
En un paso posterior se construye el proceso metodológico propuesto.
Finalmente una vez culminado lo anterior, se elabora el informe final con las conclusiones del
proyecto de tesis.
1.5. Estructura del trabajo
Esta tesis está conformada por siete capítulos:
Capítulo 1. En este capítulo se presenta una introducción al trabajo de investigación y se
establecen los objetivos generales y específicos. También se define el alcance, los
fundamentos, la metodología utilizada para dicha investigación y la estructura temática de
esta Tesis.
Capítulo 2. Se desarrolla el estado de arte, describiendo en forma general la teoría de
elicitación de requerimientos de software, el estudio y análisis de los requerimientos del
software, la Ingeniería de Requerimientos, el Modelo de Madurez de Capacidades Integrado,
el área de proceso de Gestión de Requerimientos del modelo de CMMi para Desarrollo v1.3,
la teoría del Ciclo de Deming y también se describe el proceso metodológico.
Capítulo 3. Se desarrolla la problemática que intenta solucionar este trabajo de investigación
haciendo referencia a los diferentes inconvenientes que tiene lugar en el proceso de elictación
de requerimientos; así como también, aquellas dificultades por los propios requerimientos en
sí. Por último, se formulan las preguntas relacionadas a la investigación del proyecto.
Capítulo 4. Solución Propuesta. En este capítulo se plantea una solución alternativa para la
problemática mencionada en el capítulo anterior. Dicha solución consiste en un proceso
metodológico que tiene como objetivo la mejora continua de la elicitación de requerimientos
de software, el cual está basado en el área de proceso de Gestión de Requerimientos de
CMMI para Desarrollo v1.3.
Capítulo 5. Validación de la solución propuesta. Se describen 2 casos de estudio para la
validación de la solución propuesta.
5
Capítulo 6. Conclusiones y futuras líneas de investigación. Este trabajo de investigación
plantea conclusiones y las futuras problemáticas a resolver. Dicha problemática podría ser
resuelta por medio de futuras investigaciones que aporten valor a la investigación planteada;
y para finalizar se da respuesta a las preguntas de investigación.
Capítulo 7. Referencias. Contiene la bibliografía, sitios de internet y/o artículos tenidos en
cuenta para el desarrollo de este trabajo de investigación.
Anexo. Contiene los términos y siglas utilizadas en este trabajo de investigación como
soporte para la lectura de este trabajo.
6
CAPITULO 2. ESTADO DE LA CUESTION
En este capítulo se presenta el estado de la cuestión sobre distintas teorías relacionadas al
desarrollo de la tesis.
2.1. Elicitación de requerimientos de software
La elicitación de requerimientos es un paso del ciclo de vida de los requerimientos en el ciclo
de vida de Software y consiste en la indagación o levantamiento de los requerimientos por
medio de técnicas conocidas y recomendadas.
En la mayoría de los casos, al comenzar un proyecto de software, el analista conoce muy
poco acerca del problema a resolver. La elicitación de requerimientos es el proceso que
consiste en adquirir todo el conocimiento y es el primer paso en el proceso de la Ingeniería de
Requerimientos que se relaciona directamente con el dominio del problema y el usuario,
recabando la información del conocimiento del negocio.
“La elicitación de requerimientos es el proceso de adquirir (“eliciting”) [sonsacar] todo el
conocimiento relevante necesario para producir un modelo de los requerimientos de un
dominio de problema”. (Loucopoulos & Karakostas (1995)).
Conforme a SWEBOK (2004), la actividad de elicitación de requerimientos se puede definir
como la captura de los requisitos. En este sentido, esta fuente hace referencia al origen de
estos requisitos y a la tarea de recolección de los mismos. Cabe destacar en esta línea de
razonamiento, la importancia que reviste la tarea que desarrolla los stakeholders, que son las
partes más interesadas en que el proyecto se lleve a cabo con éxito; así como también, la
solidez de los vínculos que debe haber entre equipo de desarrollo y el cliente.
Por otra parte y en línea con lo expuesto, SWEBOK hace mención a que una adecuada
comunicación entre los usuarios del proyecto y los ingenieros de software, constituyen una de
las piedras basales en las prácticas de Ingeniería de Software.
2.1.1. El proceso de elicitación.
Existen algunos modelos que consideran todo el proceso de Requisitos, pero no existen
muchos modelos que describan la educción modelando su ejecución. Estos modelos destacan
dos vistas diferentes del proceso.
7
Uno de los modelos destacados es el de Christel y Kang, en el que se describe el proceso de
educción en cinco pasos (cascada), con posibilidad de volver a etapas anteriores. En la
siguiente figura se muestra la estructura del modelo de cascada de educción de Christel y
Kang:
Figura 1. Modelo de Cascada del proceso de educción. (Christel y Kang, 1992)
De acuerdo a lo planteado por la Ing. Luz Estela Pineda Forero (2013), se puede decir que la
Figura 1 está formada por los siguientes pasos:
Identificación de las partes interesadas en múltiples niveles, contexto operacional y el
contexto del problema.
Obtención y clasificación de requisitos. Captura de la información por medio de
vistas multidisciplinarias.
Evaluación y fundamentación. Responde a las preguntas “cómo” y “qué”. Justifica la
determinación de cada requerimiento.
Priorización. Determina las funciones críticas y su importancia.
Integración y validación. Resuelve conflictos, validar que los requerimientos están de
acuerdo con los objetivos inicialmente establecidos. Obtener autorización /
verificación para mover al siguiente paso del desarrollo.
También indican que la obtención de requerimientos incluye las siguientes actividades
Identificación de actores. Se identifican los diferentes tipos de usuarios que soportará
el sistema futuro.
Identificación de escenarios. Se desarrollan un conjunto de escenarios detallados para
la funcionalidad que proporcionará el sistema. Estos escenarios se utilizan para la
8
comunicación entre usurarios y desarrolladores para profundizar la comprensión del
dominio de aplicación.
Identificación de casos de uso. Se elaboran casos de uso que representan por
completo al sistema futuro, éstos son derivados de los escenarios.
Refinamiento de los casos de uso. Se asegura que la especificación del sistema esté
completa, y cada caso de uso este detallado, así como el comportamiento del sistema
en presencia de errores y condiciones específicas.
Identificación de las relaciones entre casos de uso. Se consolida el modelo de caso de
uso sin redundancias, asegurando que la especificación del sistema sea consistente.
Identificación de requerimientos no funcionales. Se acuerdan con el cliente las
restricciones en el desempeño del sistema, la documentación, recursos que se
consumen, seguridad y calidad.
Según Sommerville (2011), refiere que en este proceso los ingenieros del software trabajan
con clientes y usuarios finales del sistema para descubrir el dominio de la aplicación, qué
servicios debe proporcionar el sistema, el desempeño de éste, las restricciones de hardware,
etc.
En la figura 2 se muestra el modelo del proceso de adquisición y análisis de requerimientos.
Las actividades del proceso son:
• Descubrimiento de requerimientos. Aquí es donde los participantes del sistema interactúan
para descubrir sus requerimientos. En esta actividad también se descubren los requerimientos
de dominio de los participantes y la documentación.
• Clasificación y organización de requerimientos. En esta actividad toma la compilación no
estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en grupos
coherentes. La forma más común de agrupar requerimientos es usar un modelo de la
arquitectura del sistema, para identificar subsistemas y asociar los requerimientos con cada
subsistema.
• Priorización y negociación de requerimientos. Los requerimientos entran en conflictos
cuando participan distintos participantes, de modo que deben ser priorizados los mismos y a
la vez llegar a la resolución de los conflictos de requerimientos a través de la negociación.
Por lo general, los participantes se reúnen para resolver las diferencias y estar de acuerdo con
el compromiso de los requerimientos.
9
• Especificación de requerimientos. Los requerimientos se documentan e ingresan en el
siguiente ciclo de la espiral. Pueden producirse documentos de requerimientos formales o
informales.
Figura 2. El proceso de adquisición y análisis de requerimientos. (Sommerville, 2011)
2.1.2. Fuentes de los requerimientos.
El fin del proceso de elicitación de requerimientos es obtener el conocimiento para construir
una especificación del sistema de software. Aunque el conocimiento es generalmente
obtenido de los usuarios, hay otras fuentes.
Loucopoulos propone seis fuentes de donde elicitar requerimientos.
1. Expertos del dominio
2. Literatura sobre el dominio
3. Software existente acerca del dominio
4. Software de otros dominios
5. Estándares nacionales e internacionales
6. Otros stakeholders del sistema de información que albergarán el sistema de software
Sin embargo, nosotros usamos una taxonomía de fuentes de 4 categorías, la cual incluye los 6
de Loucopoulos.
Personas
Formularios
Conocimiento adquirido de desarrollos previos
Productos del mundo real
1. Descubrimiento de
Requerimientos
3. Priorización y
negociación de
Requerimientos
2. Clasificación y
organización de
Requerimientos
4. Especificación de
Requerimientos
10
Las personas conforman distintos tipos de fuentes según el número del cual se elicita, la
estructura de la información obtenida de ellos y el autor de esta información.
Es distinto elicitar información de una sola persona, que de dos o tres personas, o de un
grupo. Son distintas fuentes las anotaciones libres que se escriben como resultado de las
entrevistas en las minutas. Y existe diferencia si uno mismo realiza las anotaciones que si las
hace un tercero.
La segunda categoría la integran los formularios de uso en la organización.
El conocimiento adquirido por la organización de desarrollo en desarrollos previos es la
tercera categoría. Consideramos los elementos generados a lo largo de todo el proceso de
desarrollo del software: documentos de especificación de requerimientos, diagramas ER,
documentos de diseño estructurado, documentos de diseño orientado a objetos, prototipos,
aplicaciones, guías del usuario y guías del operador.
La cuarta categoría la integran productos externos al sistema de software que inciden sobre el
sistema de información. Los productos que incluimos son: leyes, reglamentos, tratados,
normas internas, estándares generales, información institucional, publicidad y la opción otros,
para que se indique cualquier elemento no tomado en cuenta. Se corresponde con las
categorías 2 a 5 de Loucopoulos.
Conforme a Pfleeger (2002), el modelo de proceso de requerimientos puede ser descripto
según Volere (Robertson y Robertson (1999)), a partir del cual se hace mención a distintas
fuentes de requerimientos, tal como se puede visualizar en Figura 3.
Figura 3. Posibles fuentes de requerimientos (Robertson y Robertson 1999).
Dominio del
modelo
Requerimientos
utilizables
Modelo de la
situación actual
Tipos de
Requerimientos
recomendados
Deseos y necesidades de
los interesados
Documentos
existentes
Organización y
sistemas actuales
Extraer
Requerimientos
11
De acuerdo a lo planteado por la Ing. Luz Estela Pineda Forero (2013), se puede decir que
SWEBOK (2004) describe como fuentes de requerimientos las siguientes:
Metas: se refiere a los objetivos totales, de alto nivel del software.
Conocimiento del dominio: Conocimiento sobre el uso del dominio.
Stakeholders: Identificar, representar y manejar “puntos de vista” de todos los
interesados.
El entorno operacional. Ambiente en el cual el software será ejecutado.
El entorno de la organización. Estructura, cultura, y política interna de la
organización.
2.1.3. Técnicas de elicitación.
La elección de la técnica de elicitación depende del tiempo y de los recursos que dispone el
ingeniero de requerimientos y, por supuesto, de la clase de información que se necesita
elicitar.
Se detallan en este punto la clasificación de técnicas de elicitación de requerimientos de
Loucopoulos (1995) y la clasificación de Nuseibeh y Easterbrook (2000).
Según Loucopoulos las técnicas de elicitación pueden clasificarse en Originadas en el
Usuario, Análisis de Objetivo y Meta, Escenarios, Análisis de Formularios, Lenguaje Natural,
Reuso de Requerimientos y Análisis de Tareas.
Originadas en el usuario
Este enfoque es el más intuitivo y directo, dado que los usuarios tienen la posibilidad de
expresar qué quieren. Sin embargo, en la práctica se presentan dificultades por diferentes
motivos:
• Los usuarios no siempre tienen una idea clara de lo que quieren.
• Pueden presentar dificultad en expresar lo que quieren o en transmitir su conocimiento.
• Pueden tener diferencias con el analista al utilizar un vocabulario diferente.
• Pueden no desear un sistema de software o un nuevo sistema de software.
Para superar estos problemas potenciales, existen técnicas que posibilitan y facilitan la
comunicación entre el analista y los usuarios:
• Entrevistas de comienzo y final abierto: es la forma de interacción más simple entre
analistas y usuarios. El analista simplemente permite que el usuario hable sobre sus tareas.
12
Son apropiadas para obtener una visión global del dominio del problema, pero inadecuadas
para obtener información detallada.
• Entrevistas estructuradas: direccionan al usuario hacia aspectos específicos de
requerimientos a elicitar, a través de la realización de preguntas cerradas, abiertas, de
sondeo y de guía. Son útiles para obtener información detallada.
• Brainstorming: el nombre "tormenta de ideas" pretende ser una traducción circunstancial
de "brainstorming" y dar una imagen de esfuerzo y creatividad cooperativa con la finalidad
de encontrar una trayectoria factible, consensual y efectiva para un problema planteado. Es
una técnica de elicitación grupal, que permite generar numerosas alternativas gracias al
esfuerzo mental, y al aplazamiento del juicio o aceptación de las ideas generadas, pues la
creación de ideas es más productiva si se excluye la crítica.
• Escenarios
Los Escenarios son descripciones parciales del comportamiento del Sistema, que permiten
asegurar la comunicación entre usuarios y analistas, facilitando la captura de requerimientos.
• Análisis de Objetivos
Los fundamentos de un sistema de software están establecidos por los objetivos de la
organización donde el software funcionará. Usualmente estos objetivos son definidos como
las metas a ser cumplidas por el sistema y su entorno, aunque algunos autores distinguen los
objetivos del sistema de los objetivos de la organización.
• Análisis de Formularios
La metodología de Análisis de Formularios no considera al usuario como fuente primaria de
conocimiento acerca de un dominio del problema dado. Un formulario es una colección
estructurada de variables que está formateada para dar soporte al ingreso de datos y a su
recuperación.
Es una fuente importante pues es un modelo formal, ya que no tiene las inconsistencias que
posee la expresión del mismo conocimiento en lenguaje natural. A menudo, contiene
información sobre la organización, y su análisis puede automatizarse.
• Lenguaje Natural
El lenguaje natural es una fuente importante de información, debido a que en la mayoría de
los dominios es el modo más común de representación de conocimiento. Existen dos
categorías: interacción directa con el usuario utilizando lenguaje natural y elicitación de
requerimientos desde un documento en lenguaje natural. El mayor atractivo del lenguaje
13
natural reside en su vocabulario preexistente, informalidad y sintaxis. La existencia de un
vocabulario de miles de palabras predefinidas usadas para describir cualquier concepto
posible, hace que el lenguaje natural sea un medio de comunicación eficiente. Es familiar
tanto para el usuario como para el analista y no requiere tiempo de aprendizaje.
No obstante, existen dos claras limitaciones: el lenguaje natural es muy complejo y es a la
vez ambiguo.
• Reuso de Requerimientos
La técnica de Reuso de Requerimientos parte de la idea de que los requerimientos que ya han
sido capturados para alguna aplicación, pueden ser reusados en la especificación de otra
aplicación similar.
Entre las razones que consideran atrayente a esta metodología se encuentran: el ahorro de
tiempo con la consecuente mejora de productividad, el nivel significativo de similitud entre
sistemas que pertenecen a una misma área de aplicación, y la potencial obtención de mejoras
(calidad).
No obstante, estas características atrayentes contrastan con una serie de cuestiones prácticas
de aplicabilidad. La primera de ellas es que los documentos de requerimientos de sistemas
existentes no siempre se encuentran fácilmente disponibles. Otro inconveniente es la
dificultad aparente de adecuar un requerimiento antiguo en el contexto de especificación de
un nuevo sistema. Por lo tanto, para que la idea de reusabilidad de requerimientos sea posible,
existen algunos prerrequisitos de aplicación:
• Los requerimientos de sistemas existentes deben ser fácilmente accesibles,
• La selección, testeo y adecuación de un viejo requerimiento en el contexto de un nuevo
modelo de requerimientos no debe ser una tarea compleja
• El “costo” debe ser menor que obtener los requerimientos desde “cero”
• Análisis de Tareas
El Análisis de Tareas es una técnica efectiva para elicitar requerimientos de usuarios, en
particular aquellos requerimientos que reflejan la interacción hombre-máquina.
El término “Análisis de Tareas” se refiere a un conjunto de métodos que analizan y describen
el modo en que los usuarios realizan sus trabajos en términos de:
• Actividades que ejecutan y cómo están estructuradas,
• El conocimiento requerido para ejecutar esas actividades
14
El análisis de tareas es una herramienta valiosa para el proceso de elicitación de
requerimientos. Sin embargo, no produce directamente los requerimientos para un nuevo
sistema debido a que se refiere a tareas del sistema existente (no del sistema deseado), y por
lo tanto incluye muchos elementos que no formarán parte del sistema de software futuro.
Pero por otra parte, puede ser considerado como base para el futuro sistema.
Nuseibeh y Easterbrook (2000) clasifican las técnicas de elicitación de requerimientos en:
Tradicionales, de Elicitación Grupales, Prototipos, Orientadas por Modelos, Cognitivas y
Contextuales.
• Técnicas Tradicionales
Las técnicas tradicionales abarcan una amplia clase de métodos de recolección de datos
genéricos, incluyendo el uso de cuestionarios, entrevistas (de comienzo y final abierto,
estructuradas), y el análisis de documentación existente (diagramas organizacionales,
modelos o normas de procesos y otros manuales de sistemas existentes).
• Técnicas de Elicitación Grupales
Las técnicas de elicitación grupales proponen promover un acuerdo con los stakeholders,
mientras explotan la dinámica de grupo para elicitar una mejor comprensión de las
necesidades. Estas incluyen la “tormenta de ideas” (Brainstorming) como así también
RAD/JAD.
• Prototipos
Un prototipo es un modelo del producto final de software, que permite efectuar una
evaluación sobre determinados atributos del mismo, sin necesidad de que esté disponible. Se
trata, simplemente, de testear haciendo uso del modelo.
Se utiliza cuando existe incertidumbre acerca de los requerimientos, o cuando es necesaria
una respuesta temprana de los stakeholders. La técnica de prototipación se puede combinar
con otras técnicas (base para un grupo de discusión) o como base de un cuestionario o
análisis de un protocolo.
• Técnicas Orientadas por Modelos
Las técnicas orientadas por modelos proveen un modelo específico del tipo de información a
capturar, y utilizan este modelo para orientar el proceso de elicitación. Abarcan los métodos
basados en escenarios y los métodos basados en objetivos.
• Técnicas Cognitivas
15
Las técnicas cognitivas incluyen un conjunto de adquisición de técnicas originariamente
desarrolladas para la adquisición de conocimiento destinado a sistemas basados en
conocimiento.
Dichas técnicas abarcan:
• Análisis de protocolo (en el cual el experto piensa en voz alta mientras realiza su tarea, para
así proveer al observador de perspectivas en los sistemas cognitivos que se utilizan para
realizar la tarea)
• “Laddering” (se estructura y realizan las investigaciones de contenido de conocimiento para
elicitar la de los stakeholders),
• La distribución de tarjetas (se pide que los stakeholders distribuyan las tarjetas en grupos,
cada una de las cuales tiene el nombre de alguna entidad de dominio), y
• Grillas de repertorio (se construye una matriz de atributos para las entidades, solicitándole a
los stakeholders los atributos aplicables a las entidades y los valores para las celdas en cada
entidad).
• Técnicas Contextuales
Las técnicas contextuales surgieron en la década de 1990 como una alternativa tanto de las
técnicas tradicionales como de las cognitivas.
Incluyen el uso de métodos etnográficos (observación de los participantes). También incluyen
la etnometodología y el análisis de conversación, las cuales aplican un análisis minucioso
para identificar los patrones en la conversación e interacción.
2.1.4. Identificación de los participantes en la elicitación de requerimientos.
Según Sommerville y Sawyer (Som97) definen participante a cualquier individuo que se
beneficie en forma directa o indirecta del sistema en desarrollo. Vale destacar que los
participantes tienen diferentes puntos de vistas respecto del sistema y obtienen beneficios
cuando éste se desarrolla con éxito y corre distintos riesgos si fracasa el esfuerzo de
construcción.
A medida que los participantes recopilan información, los mismos aportan al proceso de
Ingeniería de Requerimientos y éstos pueden ser inconsistentes entre sí porque participan
muchos individuos.
Jeffrey L. Whitten y Lonnie D. Bentley (2008), refieren que los sistemas de comunicación y
colaboración resaltan la comunicación y la colaboración entre los involucrados, y éstos
16
pueden ser clasificados en cinco grupos. Pero antes, debemos señalar que estos grupos en
realidad definen “papeles” jugados en el desarrollo de sistemas pero en la práctica, cualquier
participante puede tener más de uno de estos papeles.
Propietarios de sistema
Usuarios de sistema
Diseñadores de sistema
Constructores de sistema
Analistas de sistemas y administradores de proyecto
Propietarios del sistema.
Los propietarios del sistema tienden a estar involucrados en la línea de fondo, es decir, ven
costos y beneficios de los sistemas.
Los usuarios del sistema.
Los usuarios del sistema constituyen la vasta mayoría de los trabajadores de la información
en cualquier sistema de información. A diferencia de los propietarios del sistema, los usuarios
del sistema tienden a estar menos preocupados con los costos y los beneficios del sistema,
más bien están preocupados por la funcionalidad que el sistema provee a sus puestos y, la
facilidad de aprendizaje y uso del sistema
Existen muchas clases de usuarios de sistemas, cada clase debe participar directamente en
cualquier proyecto de desarrollo de sistema de información que los afecte. Estos usuarios del
sistema son: Usuarios Internos del Sistema y Usuarios Externos del Sistema.
Usuarios Internos del Sistema: los usuarios internos del sistema son empleados del negocio
para el cual se construyen la mayoría de los sistemas de información. Los usuarios internos
del sistema constituyen el mayor porcentaje de usuarios de sistemas de información en la
mayoría de las empresas. Dentro de los usuarios internos del sistema podemos mencionar:
trabajadores de oficina y servicios, personal técnico y profesional, supervisores y
administrativos.
Usuarios Externos del Sistema: los usuarios externos del sistema pueden incluir otros
negocios o consumidores directos. Estos usuarios externos del sistema constituyen un
porcentaje cada vez más grande de usuarios de sistemas para los sistemas de información
modernos. Algunos de estos usuarios incluyen: clientes, proveedores, socios y empleados.
17
Estos tipos de usuarios externos son denominados también usuarios remotos y usuarios
móviles porque se conectan a través de computadoras portátiles y teléfonos inteligentes.
Diseñadores del sistema.
Los diseñadores del sistema son especialistas en tecnología de sistema de información. Los
diseñadores de sistemas actuales tienden a enfocarse en especialidades técnicas. Entre los
diseñadores podemos destacar: administradores de bases de datos, arquitectos de redes,
artistas gráficos, expertos en seguridad y especialistas en tecnología.
Constructores del sistema.
Los constructores del sistema son otra categoría de especialistas de tecnología para sistemas
de información, cuyo papel es construir el sistema de acuerdo con las especificaciones de los
diseñadores del sistema. En las organizaciones pequeñas o con sistemas de información
pequeños, los diseñadores de sistemas o constructores de sistemas con frecuencia son las
mismas personas. Entre los constructores de sistema son: programadores de aplicaciones,
programadores de sistemas, programadores de bases de datos, administradores de red,
administrador de seguridad, webmasters e integradores de software.
Analista de sistemas
El analista de sistemas crea puentes para acortar comunicación entre participantes técnicos y
no técnicos para las soluciones de negocios basadas en la computadora y quienes entiendan la
tecnología de información. Los analistas de sistemas como especialistas facilitan el desarrollo
de los sistemas de información a través de la interacción con los demás participantes.
Podemos destacar que los analistas de sistemas pueden desempeñarse como consultores de
sistemas, arquitecto de sistemas, ingeniero de información, analista de información e
integrador de sistemas, cuyo papel es estudiar los problemas y oportunidades de negocio y
luego transforman los requerimientos de negocios y de información en especificaciones de
sistemas de información que serán implementados por diversos especialistas técnicos.
2.2. Requerimientos de Software
2.2.1. Definición de requerimiento.
Según el Instituto de Ingeniería Electrónica y Eléctrica (IEEE), define requerimiento como:
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un
objetivo.
18
(2) Una condición o capacidad que debe estar presente en un sistema o componentes
del sistema para satisfacer un contrato, estándar, especificación u otro documento
formal.
(3) Una representación documentada de una condición o capacidad documentada
como las descritas en (1) y (2).
Estas definiciones constituyen una definición clásica de requerimientos como elementos de
un producto. Sin embargo, hay otros autores que son más específicos frente a la relación de
los requerimientos con relación al sistema que van a representar: “…Los requerimientos son
una especificación de lo que debe ser implementado. Estos son descripciones de cómo el
sistema se debe comportar, de las propiedades y atributos del mismo. Deben ser una
restricción del proceso de desarrollo del sistema…”(Sommerville y Sawyer, 2000).
2.2.2. Características de los requerimientos.
Las características de los requerimientos son sus propiedades principales. Un conjunto de
requerimientos en estado de madurez, deben presentar una serie de atributos tanto
individualmente como en grupo.
Veamos las características más importantes:
Necesario: Si su omisión provoca una deficiencia en el sistema a construir, y además su
capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras
capacidades del producto o del proceso.
Conciso: Si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que
vayan a consultarlos en un futuro.
Completo: Si no necesita ampliar detalles en su redacción, es decir, si se proporciona la
información suficiente para su comprensión.
Consistente: Si no es contradictorio con otro requerimiento.
No ambiguo: Cuando tiene una sola interpretación. El lenguaje usado en su definición, no
debe causar confusiones al lector.
2.2.3. Importancia de los Requerimientos
“La parte más difícil de construir un sistema es precisamente saber qué construir.
Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos
19
técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas.
Ninguna otra parte del trabajo afecta tanto el sistema.
Ninguna es tan difícil de corregir más adelante... Entonces, la tarea más importante que el
ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los
requerimientos del producto." [Alex Osborne Brainstorm].
Los requerimientos se deben descubrir antes de empezar a construir un producto, y que puede
ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un
requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o
cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. Así
que si no se tienen los requerimientos correctos, no se puede diseñar o construir el producto
correcto y, consecuentemente, el producto no permitirá a los usuarios finales realizar su
trabajo.
2.2.4. Dificultades para definir los requerimientos
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo)
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más
estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras
partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
2.2.5. Clasificación de los requerimientos.
El Instituto de Ingeniería Electrónica y Eléctrica (IEEE-830, 1998) divide los requerimientos en
funcionales y no funcionales, a continuación se describe en que consiste cada uno de estos tipos
de requerimientos.
Los requerimientos funcionales: describen una interacción entre el sistema y su ambiente,
describen cómo debe comportarse el sistema ante determinado estímulo. Son declaraciones de
los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a
20
entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos
casos, también pueden declarar explícitamente lo que el sistema no debe hacer. Los
requerimientos funcionales de un sistema describen lo que el sistema debe hacer.
Los requerimientos no funcionales: describen una restricción sobre el sistema que limita
nuestras elecciones en la construcción de una solución al problema. Restringen los servicios o
funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el tipo de proceso de
desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Los
requerimientos no funcionales ponen límites y restricciones al sistema.
2.3. Ingeniería de Requerimientos
2.3.1 Definición de Ingeniería de Requerimientos
Ortas, A (2001) utiliza la Ingeniería de Requerimientos para definir todas las actividades
involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos
para un producto determinado. El uso del término "ingeniería" implica que se deben utilizar
técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén
completos y sean consistentes y relevantes.
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de
software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de
requerimientos es entregar una especificación de requerimientos de software correcta y
completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y
definimos sistemas de software complejos.
Existen varias definiciones de requerimientos, de entre las cuales podemos citar las
siguientes:
Los Requerimientos fueron definidos por la IEEE como [IEEE90]:
1. Condición o capacidad requerida por un usuario para resolver un problema o alcanzar un
objetivo.
2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente de un
sistema para satisfacer un contrato, un standard, una especificación u otro documento
formalmente impuesto
21
3. Representación documentada de una condición o capacidad como en 1 o 2.
Según Zave:
• Rama de la ingeniería del software que trata el establecimiento de los objetivos, funciones y
restricciones de los sistemas software.
Según Boehm:
• Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa,
consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las
partes involucradas y en dónde se describen las funciones que realizará el sistema.
Según Loucopoulos:
• Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y
cooperativo de análisis del problema, documentando los resultados en una variedad de
formatos y probando la exactitud del conocimiento adquirido
Según Leite:
• Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y
modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos,
herramientas y actores, cuyo producto es un modelo del cual se genera un documento de
requerimientos.
Se desarrollan sistemas de software para satisfacer una necesidad percibida por un cliente.
Pueden formularse las necesidades reales del cliente como requerimientos. Los
requerimientos son desarrollados conjuntamente por el cliente, usuario y diseñadores del
sistema de software. La ingeniería de requerimientos es un proceso de descubrimiento,
refinamiento, modelización, especificación y validación de lo que se desea construir. En este
proceso tanto el cliente como el analista juegan un papel muy importante.
Cuando nos encontramos al frente de un proyecto de desarrollo de sistemas es importante
dejar claramente definidos los requerimientos del software, en forma consistente y compacta,
22
esta tarea es difícil básicamente porque consiste en la traducción de unas ideas vagas de
necesidades de software en un conjunto concreto de funciones y restricciones. Además el
analista debe extraer información dialogando con muchas personas y cada una de ellas se
expresa de una forma distinta, tiene conocimientos informáticos y técnicos distintos, y tiene
unas necesidades y una idea del proyecto muy particulares.
2.3.2. Importancia de la Ingeniería de Requerimientos
Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son [13, [7]]:
• Permite gestionar las necesidades del proyecto en forma estructurada:
Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR
proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento,
tales como estimación de costos, tiempo y recursos necesarios.
• Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar
errores por un mal desarrollo no descubierto a tiempo, es sumamente caro.
• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un
conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
• Mejora la comunicación entre equipos: La especificación de requerimientos representa una
forma de consenso entre clientes y desarrolladores, si este consenso no ocurre, el proyecto no
será exitoso.
• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a
considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema,
por lo que se lo involucra durante todo el desarrollo del proyecto.
2.3.3. Estructura de la Ingeniería de Requerimientos.
Boehm (1981), describe que la "Ingeniería de Requerimientos es la disciplina para desarrollar
una especificación completa, consistente y no ambigua, la cual servirá como base para
acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones
que realizará el sistema".
Según Oberg (2003), define a la Ingeniería de requerimientos como un enfoque sistémico
para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso
23
que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y
el equipo del proyecto.
Como se puede apreciar en cada una de estas definiciones, todos los procesos con la
Ingeniería de Requerimientos están relacionados con identificar, modelar, comunicar y
documentar los requerimientos de un sistema o producto de software.
Todo requerimiento debe describir lo que realmente se debe hacer y cómo se debe llevar a
cabo, si esto queremos llevarlo a la realidad es difícil de hacerlo, por esto existen muchas
técnicas disponibles para la aplicación de la Ingeniería de Requerimientos, con el fin de
asegurar que los requerimientos obtenidos cuenten, al final del proceso de Ingeniería de
Requerimientos, con las características necesarias para ser implementadas. Por esto, el
proceso de Ingeniería de Requerimientos describe de manera detallada y precisa cada uno de
los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso presenta dos
grandes ramas: El Desarrollo de Requerimientos y la Administración de Requerimientos.
Figura 4. Estructura de la Ingeniería de Requerimientos. (Wiegers, 2000)
Cada una de estas actividades que conforman el Desarrollo de Requerimientos son:
Recolección: proceso por el cual los clientes (compradores y/o usuarios) y el desarrollador
(contratista) de un sistema de software; descubren, revisan, articulan, y entienden las
necesidades de los usuarios del sistema y las restricciones que se dan sobre el software y el
desarrollo del mismo.
Análisis: Es el proceso de analizar las necesidades de los clientes y los usuarios para llegar a
una definición de los requerimientos de software.
24
Especificación: Consiste en el desarrollo de un documento que de manera clara y precisa
contenga y especifique cada uno de los requerimientos del sistema de software.
Verificación: es el proceso de asegurar que la especificación de requerimientos de software
sea acorde con los requerimientos del sistema, conforme a los estándares de documentación
de la fase de requerimientos, y que a su vez este documento sea una base sólida para la
arquitectura y el diseño.
Cada una de estas actividades está enfocada a permitir el análisis y documentación de los
requerimientos de un sistema.
Por otra parte, la necesidad de recrear un proceso iterativo sobre el desarrollo de
requerimientos nos conduce a la necesidad de ejercer control y establecer una línea base para
la administración de los requerimientos; esto con el fin de mantener la consistencia de lo que
se especifica respecto a lo que se desarrolla. Estas son las tareas de la Administración de
requerimientos.
Figura 5. Gestión de Requerimientos. (Mead, 2000)
2.3.4. Proceso de la Ingeniería de Requerimientos.
La Ingeniería de Requerimientos es el proceso sistemático de desarrollar requerimientos a
través de un proceso cooperativo e iterativo de analizar el problema, documentar las
observaciones resultantes en una variedad de formatos de representación y chequear la
precisión de la comprensión obtenida.
Los tres aspectos fundamentales de la Ingeniería de Requerimientos que plantea Loucopoulos
(1995) son:
Comprender el problema.
25
Describir el problema
Acordar sobre la naturaleza del problema.
Además, Loucopoulos plantea tres etapas para comprender, describir y acordar el problema:
Elicitación de Requerimientos
Especificación de Requerimientos
Validación de Requerimientos
Aclaramos que en este proceso cada etapa necesita de otra etapa y no es necesario que cada
etapa empiece o termine. Es importante mencionar que el papel del usuario es crucial en todo
este proceso, tanto para transmitir conocimiento como para certificar que el analista
comprende el problema, en el marco de un dominio de problema específico.
Elicitacion de Requerimientos:
Generalmente, al empezar un proyecto, el analista conoce muy poco o casi nada acerca del
problema a resolver. La elicitación de requerimientos es el proceso que consiste en
adquirir/obtener todo el conocimiento relevante, necesario para producir un modelo de
requerimientos (especificación) de un dominio de problema.
Estas etapas se ilustran en la Figura 6.
Figura 6. Proceso de Ingeniería de Requerimientos. (Loucopoulos & Karakostas, 1995)
26
El analista debe realizar la especificación de requerimientos y subsecuentemente su
validación con el usuario, solamente después de comprender la naturaleza, características y
límites de un problema. La “captura” de conocimiento es un problema en sí mismo dado que
el conocimiento no siempre está disponible en un formato que pueda ser usado por el analista,
y además, no es fácil elicitar conocimiento desde su fuente, especialmente cuando la fuente es
un “experto” humano.
Una de las metas más importantes de la elicitación es descubrir cuál es el problema que se
debe resolver y, por consiguiente, identificar los límites del sistema. Estos límites definen, a
un alto nivel, dónde se adecuará el sistema final entregado en el ambiente operacional actual.
La identificación y el acuerdo de los límites de un sistema afectan todas las tareas posteriores
a la elicitación. Las actividades que abarcan las tareas del analista incluyen la identificación
de todas las fuentes de conocimiento de requerimientos, adquirir conocimiento, decidir sobre
la relevancia del conocimiento de un problema, y comprender su significado y cómo éste
impacta sobre los requerimientos de software.
Especificación de Requerimientos:
Una especificación de requerimientos puede ser vista como un contrato entre usuarios y
desarrolladores de software, el cual define el comportamiento funcional del artefacto de
software sin mostrar cómo será obtenido ese comportamiento.
Es importante ver la especificación como un proceso complejo que requiere “feedback” desde
el analista al usuario y viceversa. El proceso es analítico debido a que diferentes clases de
conocimiento que el analista elicita de un dominio de problema, debe ser examinado y
posteriormente vinculado de algún modo. Por lo tanto, la especificación de requerimientos
puede ser descripta en términos de dos actividades principales:
• Análisis y asimilación de conocimiento de requerimientos.
• Síntesis y organización de conocimiento en un modelo de requerimientos lógico y
coherente.
Se considera que la especificación de requerimientos produce una variedad de modelos, los
cuales corresponden a diferentes visiones del problema. Es así como la especificación de
requerimientos produce:
• Modelos orientados al usuario, especificando el comportamiento y características no
funcionales del software que servirá como punto de entendimiento entre el analista, el
cliente y el usuario.
27
• Modelos orientados al desarrollador, especificando propiedades funcionales y no
funcionales del sistema de software, así como restricciones sobre recursos, restricciones
sobre diseño, etc. Estos modelos son importantes de considerar en etapas de desarrollo
posteriores.
Esta diferencia de modelos es muy útil, ya que las notaciones de especificación claras para
desarrolladores pueden ser difíciles de comprender por los usuarios.
La especificación de requerimientos es el proceso central de ingeniería de requerimientos.
Actúa como medio de control para los procesos de elicitación y de validación.
Durante la especificación puede surgir la necesidad de mayor información acerca del
problema. Esta necesidad dispara nuevamente el proceso de elicitación en búsqueda de
información. Por otra parte, algún cambio en el dominio del problema debe producir cambios
en la especificación. De este modo, puede requerirse elicitación durante la especificación.
Validación de Requerimientos:
El proceso de validación de requerimientos certifica la corrección del modelo/especificación
de requerimientos contra las intenciones de los usuarios (por lo que la participación de los
usuarios es crucial). Validar, luego de la fase de especificación de requerimientos, puede
ayudar a evitar costosas correcciones después del desarrollo.
Otra definición [Locoupoulos95] indica que la validación establece y justifica la convicción
del analista y del usuario, de que el modelo de requerimientos especifica una solución de
software la cual es correcta para las necesidades del usuario.
La validación de requerimientos es más una actividad de “debugging” que de probar
corrección. La meta consiste en identificar y corregir errores en la fase de requerimientos y
no cuando el software está desarrollado, pues los errores que sobreviven a la fase de
requerimientos pueden tener consecuencias catastróficas para el proyecto de software. Por lo
tanto, es una actividad siempre presente en el proceso de requerimientos. Es una actividad no
estructurada, por lo que no tiene una solución algorítmica.
Para Sommervile (2005), la meta del proceso de ingeniería de requerimientos es crear y
mantener un documento del sistema. El proceso general comprende 4 subprocesos, la cual
trata de la evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el
descubrimiento de requerimientos (obtención y análisis); la transformación de estos
requerimientos en formularios estándar (especificación); y la verificación de que los
requerimientos realmente definen el sistema que quiere el cliente (validación).
28
En la figura 7 se muestra también el documento que elabora cada etapa del proceso de la
ingeniería de requerimientos. Las actividades que se muestran en este proceso, se refieren al
descubrimiento, documentación y verificación de requerimientos.
Figura 7. Proceso de Ingeniería de Requerimientos. (Sommerville, 2005)
Estudio de Viabilidad
Cuando se empieza un sistema nuevo, el proceso de ingeniería de requerimientos debe
empezar con un estudio de viabilidad, cuya entrada es un conjunto de requerimientos de
negocio, una descripción resumida del sistema y de cómo éste pretende contribuir a los
procesos del negocio. Los resultados del estudio de viabilidad debería ser un informe que
recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de
desarrollo del sistema. Realizar un estudio de viabilidad comprende la evaluación y
recopilación de la información, y la redacción de informes. En un estudio de viabilidad, se
pueden consultar las fuentes de información, como los jefes de los departamentos donde se
utilizará el sistema, los ingenieros de software, los expertos en tecnología y los usuarios
finales del sistema.
Obtención y análisis de requerimientos
En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales
del sistema para determinar el dominio de la aplicación, que servicios debe proporcionar el
sistema, el rendimiento del sistema, etc.
En la figura 8 se muestra un modelo muy general del proceso de obtención y análisis de
requerimientos, cuyas actividades son:
Descubrimiento de requerimientos: es el proceso de interactuar con los stakeholders del
sistema para recopilar sus requerimientos.
29
Clasificación y organización de requerimientos: esta actividad toma la recopilación no
estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en
grupos coherentes.
Ordenación por prioridades y negociación de requerimientos: se refiere a ordenar según las
prioridades los requerimientos y a encontrar y resolver los requerimientos en conflictos a
través de la negociación.
Documentación de requerimientos: se documentan los requerimientos y se ingresa en la
siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos formales o
informales.
Figura 8. Proceso de Obtención y Análisis de Requerimientos. (Sommerville, 2005)
Validación de requerimientos: la validación de requerimientos trata de mostrar que éstos
definen el sistema que el cliente desea. La validación de requerimientos es importante debido
a que los errores en el documento de requerimientos pueden conducir a importantes costes al
repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema
esté en uso. Durante el proceso de validación de requerimientos, se deben llevar a cabo
verificaciones sobre requerimientos en el documento de requerimientos y éstas comprenden:
Verificación de validez
Verificación de consistencia
Verificación de completitud
Verificación de realismo
30
Verificabilidad.
No debe subestimarse los problemas en la validación de requerimientos y es difícil demostrar
que un conjunto de requerimientos cumpla las necesidades del usuario.
2.3.5. Clasificación de los Requerimientos
Los requerimientos se pueden clasificar en funcionales y no funcionales [8], los cuales se
definen a continuación:
• Los requerimientos funcionales
Definen las funciones que el sistema será capaz de realizar. Describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas, especifican los servicios que
debe proporcionar la aplicación (por ejemplo, “la aplicación debe calcular el valor del
portafolio de inversión del usuario”) [5]
• Los requerimientos no funcionales
Tienen que ver con características que de una u otra forma puedan limitar el sistema, como
por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez
2 del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
es el cómo, cuándo y cuánto del qué. [5]
2.3.6. Documento de los requerimientos.
El documento de requerimientos es la presentación integral de todos los productos del
proceso de la Ingeniería de Software. Este documento puede utilizarse como contrato entre el
cliente y el proveedor de software. Este documento jamás se termina por lo que debe ser
constantemente revisado y actualizado. Por el lado de la empresa desarrolladora este
documento es la fuente primordial a partir de la cual se define la arquitectura y el diseño del
sistema (y a partir de estos las restantes descripciones del sistema).
Existen dos tipos de documentos de requerimientos, el documento de especificación de
requerimientos cubre exactamente lo mismo que el documento de definición de los
requerimientos, la diferencia entre estos dos tipos de documentos la marca el lector, es decir,
a quien están dirigidos, el nivel en el que están escritos depende si se trata del cliente o de las
personas que van a desarrollar el sistema.
Normalmente, la definición de los requerimientos está redactada en lenguaje natural, mientras
que la especificación de los requerimientos se redacta de una forma más técnica, por ejemplo,
puede definir un requerimiento que se hizo en lenguaje natural, como una serie de
ecuaciones, un diagrama de flujo de datos, casos de uso, etc.
31
2.4. Modelo de Madurez de Capacidades Integrado. CMMI-DEV v1.3
CMMi es un modelo de calidad y de madurez de mejora de procesos de una organización y
un modelo de referencia que abarca las actividades de desarrollo y mantenimiento aplicadas a
productos y servicios. Los CMMs se centran en mejorar los procesos de una organización, los
mismos contienen los elementos esenciales de los procesos eficaces de una o más disciplinas
y describen un camino evolutivo de mejora desde procesos ad hoc e inmaduros a procesos
disciplinados y maduros con calidad y eficacia mejoradas.
CMMi contiene prácticas que cubren la Administración de Proyectos, Administración de
Procesos, Ingeniería de Sistemas, Ingeniería de Hardware, Ingeniería de Software, y otros
Procesos de Soporte utilizados en el desarrollo y mantenimiento.
CMMi fue desarrollado para ser implementado en cualquier entorno; y debe ser adaptado al
contexto y necesidades de la organización.
CMMI- DEV está basado en el CMMI Model Foundation o CMF (es decir, componentes del
modelo comunes a todos los modelos y constelaciones CMMI) e incorpora el trabajo
realizado por organizaciones de desarrollo para adaptar CMMI para su uso en el desarrollo de
productos y servicios.
Veamos las constelaciones que conforman CMMi.
CMMi para Adquisición: esta constelación sirve como guía para mejorar el proceso de
adquisición de productos y servicios.
CMMi para Servicios: hace referencia a la gestión de servicios internos en una
organización.
CMMi para el Desarrollo: hace referencia a cómo medir, monitorear y administrar el
proceso de desarrollo y mantenimiento de productos y servicios.
CMMI® para Desarrollo (CMMI-DEV) proporciona una oportunidad para evitar o eliminar
nichos y barreras. CMMI para Desarrollo consta de buenas prácticas que tratan las
actividades de desarrollo aplicadas a productos y servicios. Aborda las prácticas que cubren el
ciclo de vida del producto desde la concepción hasta la entrega y el mantenimiento.
CMMI para Desarrollo es un modelo de referencia que cubre las actividades para desarrollar
tanto productos como servicios.
32
2.4.1 Componentes del CMMI-DEV V1.3.
Este modelo contiene prácticas que cubren la gestión de proyectos, la gestión de procesos, la
ingeniería de sistemas, la ingeniería de hardware, la ingeniería de software y otros procesos
de soporte utilizados en el desarrollo y mantenimiento de un producto software.
El CMMI para Desarrollo propone dos rutas para la mejora, estas están asociadas con dos
tipos de niveles (niveles de capacidad y niveles de madurez), los niveles corresponden a las
dos aproximaciones de mejora de procesos denominadas representaciones.
La primera ruta de mejora permite a las organizaciones mejorar de forma incremental
seleccionando aquellos procesos que corresponden a un área individual o a un grupo de
Áreas de proceso previamente seleccionadas por la organización, ésta se denomina
Representación Continua.
La otra ruta permite a las organizaciones mejorar un conjunto de procesos relacionados entre
sí y organizados por niveles, ésta se denomina Representación por Etapas.
El uso de la representación continua permite alcanzar niveles de capacidad, el uso de la
representación por etapas permite alcanzar niveles de madurez. Ambas representaciones
proporcionan caminos distintos para mejorar los procesos con el fin de lograr los objetivos de
negocio de una determinada organización.
Representación por Etapas Representación Continua
Está organizada por áreas de proceso en
cinco niveles de madurez con el fin de
apoyar y dirigir la mejora de proceso. El
modelo indica qué áreas de proceso son
necesarias para alcanzar cada nivel de
madurez.
Dentro de cada área de proceso primero se
especifica las metas y las practicas
específicas.
En la representación por etapas los niveles de
madurez proporcionan un orden
recomendado para acercarse a la mejora del
proceso en etapas. Los niveles de madurez
están organizadas por áreas de procesos
dentro de las cuales existen metas genéricas
y específicas así como prácticas genéricas y
específicas.
Utiliza seis niveles de capacidad como principios de
organización para los componentes del modelo. La
representación continua agrupa áreas de proceso por
categorías de afinidad y señala los niveles de
capacidad para la mejora dentro de cada área de
proceso.
Una representación equivalente se usa para relacionar
niveles de capacidad de las áreas de proceso con los
niveles de madurez de la representación por etapas.
En la representación continua las metas específicas
están organizadas en prácticas específicas y las metas
genéricas están organizadas en prácticas genéricas.
Cada práctica específica y genérica corresponde a un
nivel de capacidad.
Tabla 1: Representaciones del CMMI
33
Los componentes para ambas representaciones están formados por áreas de proceso, metas
específicas, prácticas específicas, metas genéricas y prácticas genéricas.
Los modelos del CMMI se diseñan para describir niveles discretos de la mejora de proceso.
En la representación continua los niveles de capacidad proporcionan un orden recomendado
para aproximarse a una mejora dentro de cada área de proceso.
Al mismo tiempo la representación continua permite una cierta flexibilidad en el orden en
que se aplican las áreas de proceso.
Figura 9: Componentes del modelo CMMI (CMMI-DEV v1.3)
Niveles de Madurez (Representación por Etapas): Los niveles de madurez consisten un
sistema predefinido de áreas de proceso y son medidos por el logro de las metas específicas y
genéricas que se aplican a un conjunto predefinido de áreas. Un nivel de madurez es un
planteamiento evolutivo definido para la mejora del proceso, cada nivel de madurez estabiliza
una parte importante de los proceso de la organización.
34
En la representación por etapas hay cinco niveles de madurez identificados por los números
del 1 al 5.
1. Inicial
2. Gestionado
3. Definido
4. Gestionado Cuantitativamente.
5. En optimización
Nivel de Madurez 1: Inicial.
Los procesos son generalmente provisionados y caóticos, la organización no proporciona un
ambiente estable, el éxito depende de la capacidad y los esfuerzos heroicos de la gente.
Nivel de Madurez 2: Gestionado.
Una organización está en el Nivel 2 de madurez cuando alcanza todas las metas específicas y
genéricas de las áreas de proceso de este nivel. Es decir que para una organización se
garantiza que los requisitos están gestionados y que los procesos estén planificados,
realizados, medidos, y controlados.
Nivel de Madurez 3: Definido
Una organización está en el nivel 3 de madurez cuando alcanza todas las metas específicas y
genéricas de las áreas de proceso de los niveles 2 y 3. En el nivel 3 los procesos se
caracterizan y se entienden bien, además se detallan en estándares, procedimientos,
herramientas y métodos.
Nivel de Madurez 4: Gestionado Cuantitativamente
Una organización está en Nivel 4 de madurez cuando alcanza todas las metas específicas y
genéricas de las áreas de proceso asignadas a los niveles 2, 3, 4 y las metas genéricas
asignadas a los niveles 2 y 3. En el Nivel4 se seleccionan los subprocesos que contribuyen
perceptiblemente al rendimiento del proceso global, estos subprocesos son controlados
utilizando técnicas estadísticas y cuantitativas.
Nivel de Madurez 5: En Optimización
En el Nivel 5 una organización ha alcanzado todas las metas específicas de las áreas de
proceso asignadas a los niveles 2, 3, 4, 5 y las metas genéricas asignadas a los niveles 2 y 3.
Los procesos se mejoran continuamente basados en una comprensión cuantitativa de las
causas comunes de la variación inherente a los procesos.
Niveles de Capacidad (Representación Continua)
El modelo CMMI representación continua refleja los niveles de capacidad en su diseño y
contenido, un nivel de capacidad consiste de prácticas genéricas y específicas afines entre sí
35
para un área de proceso. Estas prácticas pueden mejorar los procesos organizacionales
asociados a esa área de proceso siempre y cuando se satisfagan las metas genéricas y
específicas para un área de proceso en un nivel particular de capacidad, si se alcanza ese nivel
se obtienen los beneficios de la mejora del proceso.
Los niveles de capacidad permiten seguir, evaluar, y demostrar el progreso mientras que se
mejoran los procesos asociados a un área de proceso. Los niveles de capacidad se construyen
uno tras otro proporcionando un orden recomendado para acercarse a la mejora del proceso.
Comparación de los Modelos de Representación
La representación continua utiliza niveles de capacidad para medir la mejora de proceso,
mientras que la representación por etapas utiliza niveles de madurez. La diferencia principal
entre niveles de madurez y de capacidad es cómo se aplican.
Los niveles de madurez se aplican a la madurez total de una organización, existen cinco
niveles de la madurez numerados del 1 al 5, cada nivel abarca un sistema predefinido de áreas
de proceso.
Los niveles de capacidad se aplican a la mejora del proceso de una organización para cada
área de proceso, existen seis niveles de capacidad numerados del 0 al 5, cada nivel
corresponde a una meta genérica y a un sistema de prácticas genéricas y específicas.
Existe una equivalencia de la representación continua contra la representación por etapas.
Esta permite traducir los valores de la representación continua a su correspondiente nivel de
madurez.
Figura 10: Comparativa de los Niveles de Capacidad y de Madurez
Una de las áreas que abarca CMMi es gestión de requisitos y su objetivo es gestionar los
requisitos del proyecto y sus componentes, e identificar las inconsistencias entre los
requisitos, los productos y los planes del proyecto. El CMMi sirve como guía para
36
implementar una buena gestión de requisitos porque establece practicas mínimas que se
deben llevar a cabo para mantener actualizados, documentados, organizados y accesibles los
requisitos de un sistema.
Para dar soporte a aquellos que utilizan la representación continua, las áreas de procesos se
organizan en cuatro categorías: Gestión de Procesos, Gestión de Proyectos, Ingeniería y
Soporte. Estas categorías hacen hincapié en algunas de las relaciones clave que existen entre
las áreas de proceso.
Un área de proceso es un grupo de prácticas relacionadas dentro de un área que, cuando se
implementa conjuntamente, satisface un conjunto de metas consideradas importantes para
mejorar esa área.
Figura 11: Elementos de un Área de Procesos (CMMi Dev v1.3)
37
La tabla 2 proporciona un listado de las Áreas de Proceso de CMMi Dev y de sus categorías y
niveles de madurez:
Tabla 2: Área de procesos, categorías y niveles de madurez (CMMI-DEV, V1.3)
2.4.2. Áreas de Proceso de Ingeniería CMMi Dev v1.3.
Las áreas de proceso de Ingeniería CMMi Dev v1.3 cubren las actividades de desarrollo y de
mantenimiento que se utilizan en todas las disciplinas de Ingeniería.
Las áreas de proceso de Ingeniería también integran los procesos asociados con diferentes
disciplinas de ingeniería en un único proceso de desarrollo de producto, dando soporte a una
estrategia de mejora de procesos orientada al producto. Esta estrategia se dirige más a los
objetivos de negocio esenciales que a las disciplinas técnicas específicas. Este enfoque a
procesos, evita de manera eficaz la tendencia hacia una mentalidad “compartimentada” de la
38
organización.
Las cinco áreas de proceso de Ingeniería que son aplicados a cualquier producto o servicio
dentro del dominio de desarrollo (p. ej., productos software, productos hardware, servicios,
procesos) son:
Integración del Producto (PI).
Desarrollo de Requisitos (RD).
Solución Técnica (TS).
Validación (VAL).
Verificación (VER).
Integración del Producto (PI): contiene las prácticas específicas asociadas con la generación
de una estrategia de integración, integrando los componentes de producto y entregando el
producto al cliente. La Integración del Producto utiliza las prácticas específicas tanto de
Verificación como de Validación, en la implementación del proceso de integración del
producto.
Desarrollo de Requisitos (RD): identifica las necesidades del cliente y las transforma en
requisitos del producto. También proporciona los requisitos al área de proceso Solución
Técnica, donde los requisitos se convierten en la arquitectura del producto, los diseños de los
componentes de producto y los componentes del producto.
Solución Técnica (TS): desarrolla los paquetes de datos técnicos relativos a los componentes
de producto para que se utilicen por el área de proceso Integración del Producto. Esta área se
basa en las prácticas específicas del área de proceso Verificación para realizar la verificación
del diseño y las revisiones entre pares durante el diseño y antes de la construcción final.
Validación (VAL): valida de manera incremental los productos frente a las necesidades del
cliente
Verificación (VER): asegura que los productos de trabajo seleccionados cumplan los
requisitos especificados, selecciona los productos de trabajo y métodos de verificación que
se usa para verificar los productos de trabajo frente a los requisitos especificados.
2.4.3. Gestión de Requerimientos (REQM) en el CMMI-DEV V1.3.
El propósito de la Gestión de Requerimientos es gestionar los requerimientos de los
productos y los componentes de producto del proyecto y asegurar la alineación entre esos
requerimientos, y los planes y los productos de trabajo del proyecto.
39
Los procesos de gestión de requisitos gestionan todos los requisitos recibidos o generados por
el proyecto, incluyendo tanto los requisitos técnicos como los no técnicos, así como los
requisitos impuestos al proyecto por la organización.
El proyecto realiza los pasos apropiados para asegurar que el conjunto de requisitos
aprobados se gestiona para dar soporte a las necesidades de planificación y de ejecución del
proyecto. Cuando un proyecto recibe requisitos de un proveedor de requisitos aprobado, éstos
se revisan con dicho proveedor para resolver las cuestiones y para prevenir malentendidos
antes de que los requisitos se incorporen en los planes del proyecto. Una vez que el proveedor
y el receptor de los requisitos alcanzan un acuerdo, se obtiene un compromiso sobre los
requisitos por parte de los participantes en el proyecto. El proyecto gestiona los cambios a los
requisitos a medida que evolucionan e identifica inconsistencias que ocurren entre los planes,
los productos de trabajo y los requisitos.
Una parte de la gestión de requisitos es documentar los cambios de los requisitos y su análisis
razonado, y mantener la trazabilidad bidireccional entre los requisitos fuente, todos los
requisitos de producto y de componente de producto, y otros productos de trabajo
especificados (véase la definición de “trazabilidad bidireccional” en el glosario).
Todos los proyectos tienen requisitos. En el caso de actividades de mantenimiento, los
cambios se basan en los cambios de los requisitos, al diseño o a la implementación existente.
En proyectos que entregan incrementos de la capacidad del producto, los cambios también se
pueden deber a la evolución de las necesidades del cliente, a la madurez u obsolescencia de la
tecnología y a la evolución de los estándares.
En ambos casos, los cambios a los requisitos, si existen, podrían documentarse en peticiones
de cambio del cliente o de los usuarios finales, o podrían tomar la forma de nuevos requisitos
recibidos del proceso de desarrollo de requisitos. Independientemente de su fuente o forma,
las actividades que son dirigidas por cambios en los requisitos se gestionan
consecuentemente.
Resumen de metas y prácticas específicas
SG 1 Gestionar los requisitos.
SP 1.1 Comprender los requisitos.
SP 1.2 Obtener el compromiso sobre los requisitos.
SP 1.3 Gestionar los cambios a los requisitos.
SP 1.4 Mantener la trazabilidad bidireccional de los requisitos.
40
SP 1.5 Asegurar el alineamiento entre el trabajo del proyecto y los requisitos.
Prácticas específicas por meta.
SG 1 Gestionar los requisitos.
Los requisitos se gestionan y las inconsistencias con los planes y productos de trabajo del
proyecto se identifican. El proyecto mantiene un conjunto actual y aprobado de requisitos
durante la vida del proyecto haciendo lo siguiente:
• Gestionando todos los cambios en los requisitos.
• Manteniendo las relaciones entre los requisitos, los planes del proyecto y los productos de
trabajo.
• Asegurando la alineación entre los requisitos, los planes del proyecto y los productos de
trabajo.
• Tomando acciones correctivas.
SP 1.1 Comprender los requisitos
Desarrollar una comprensión del significado de los requisitos con los proveedores de los
requisitos.
A medida que madura el proyecto y se derivan los requisitos, todas las actividades o
disciplinas recibirán requisitos. Para evitar el flujo continuo de requisitos, se establecen
criterios para designar los canales apropiados o las fuentes oficiales desde las que se reciben
los requisitos.
Aquellos que reciben los requisitos, los analizan con el proveedor para asegurar que se
alcanza una comprensión compatible y compartida del significado de los requisitos. El
resultado de estos análisis y diálogos es un conjunto de requisitos aprobados.
Ejemplos de productos de trabajo
1. Listas de criterios para distinguir a los proveedores apropiados de requisitos.
2. Criterios para la evaluación y la aceptación de los requisitos.
3. Resultados del análisis frente a los criterios.
4. Un conjunto de requisitos aprobados.
Subprácticas
1. Establecer criterios para distinguir a los proveedores apropiados de requisitos.
2. Establecer criterios objetivos para la evaluación y aceptación de los requisitos.
3. Analizar los requisitos para asegurar que se cumplen los criterios establecidos.
41
4. Alcanzar una comprensión de los requisitos con los proveedores de requisitos para que los
participantes del proyecto puedan comprometerse con ellos.
SP 1.2 Obtener el compromiso sobre los requisitos
Obtener el compromiso de los participantes del proyecto sobre los requisitos.
La práctica específica anterior se ocupó de alcanzar una comprensión con los proveedores de
los requisitos. Esta práctica específica se ocupa de los acuerdos y compromisos entre aquellos
que llevan a cabo las actividades necesarias para implementar los requisitos. Los requisitos
evolucionan a lo largo del proyecto. A medida que los requisitos evolucionan, esta práctica
específica asegura que los participantes del proyecto se comprometen con los requisitos
actuales y aprobados, y con los cambios resultantes en los planes, actividades y productos de
trabajo del proyecto.
Ejemplos de productos de trabajo
1. Evaluaciones del impacto de los requisitos.
2. Compromisos documentados de los requisitos y de sus cambios.
Subprácticas
1. Evaluar el impacto de los requisitos sobre los compromisos existentes.
El impacto sobre los participantes del proyecto se debería evaluar cuando cambian los
requisitos o al principio de un nuevo requisito.
2. Negociar y registrar los compromisos.
Los cambios en los compromisos existentes se deberían negociar antes de que los
participantes del proyecto se comprometan con un nuevo requisito o un cambio en un
requisito.
SP 1.3 Gestionar los cambios de los requisitos
Gestionar los cambios de los requisitos a medida que evolucionan durante el proyecto.
Los requisitos cambian por diversas razones. A medida que cambian las necesidades y avanza
el trabajo, es posible que se tengan que hacer cambios en los requisitos existentes. Es esencial
gestionar estas adiciones y cambios, eficiente y eficazmente. Para analizar con eficacia el
impacto de los cambios, es necesario que se conozca la fuente de cada requisito y que esté
documentado el análisis razonado de cualquier cambio. El proyecto puede querer seguir
medidas apropiadas de volatilidad de los requisitos para juzgar si es necesario un enfoque
nuevo o modificado para el control de cambios.
42
Ejemplos de productos de trabajo
1. Petición de cambio de requisitos.
2. Informes de impacto del cambio de requisitos.
3. Estado de los requisitos.
4. Base de datos de requisitos.
Subprácticas
1. Documentar todos los requisitos y los cambios de los requisitos que se reciben o generan
por el proyecto.
2. Mantener una historia de cambios de los requisitos, incluyendo el análisis razonado de los
cambios.
Mantener la historia de cambios ayuda a seguir la volatilidad de los requisitos.
3. Evaluar el impacto de los cambios de requisitos desde el punto de vista de las partes
interesadas relevantes.
Los cambios de los requisitos que afectan a la arquitectura del producto pueden afectar a
muchas partes interesadas.
4. Poner a disposición del proyecto los requisitos y los datos de los cambios.
SP 1.4 Mantener la trazabilidad bidireccional de los requisitos
Mantener la trazabilidad bidireccional entre los requisitos y los productos de trabajo.
La intención de esta práctica específica es mantener la trazabilidad bidireccional de los
requisitos (véase la definición de “trazabilidad bidireccional” en el glosario). Cuando se
gestionan bien los requisitos, se puede establecer la trazabilidad desde un requisito fuente
hasta sus requisitos de más bajo nivel y desde estos requisitos de más bajo nivel de vuelta
hasta sus requisitos fuente. Esta trazabilidad bidireccional ayuda a determinar si todos los
requisitos fuente se han tratado totalmente y si todos los requisitos de nivel más bajo pueden
trazarse hacia una fuente válida.
La trazabilidad de los requisitos también cubre las relaciones a otras entidades, tales como
productos de trabajo intermedios y finales, cambios en la documentación del diseño y planes
de pruebas. La trazabilidad puede cubrir relaciones horizontales, tales como relaciones entre
interfaces, así como relaciones verticales. La trazabilidad es particularmente necesaria al
evaluar el impacto de los cambios de los requisitos sobre las actividades del proyecto y los
productos de trabajo.
43
La trazabilidad bidireccional no siempre está automatizada. Ésta se puede hacer manualmente
utilizando hojas de cálculo, bases de datos u otras herramientas comunes.
Ejemplos de productos de trabajo
1. Matriz de trazabilidad de los requisitos.
2. Sistema de seguimiento de los requisitos.
Subprácticas
1. Mantener la trazabilidad de los requisitos para asegurar que la fuente de los requisitos de
nivel más bajo (es decir, inferidos) está documentada.
2. Mantener la trazabilidad de los requisitos desde un requisito a sus requisitos inferidos y a
la asignación a los productos de trabajo.
Los productos de trabajo para los cuales la trazabilidad se puede mantener incluyen la
arquitectura, los componentes de producto, las iteraciones de desarrollo (o incrementos),
las funciones, las interfaces, los objetos, las personas, los procesos y otros productos de
trabajo.
3. Generar una matriz de trazabilidad de requisitos.
SP 1.5 Asegurar el alineamiento entre el trabajo del proyecto y los requisitos
Asegurar que los planes del proyecto y los productos de trabajo permanecen alineados con los
requisitos.
Esta práctica específica encuentra las inconsistencias entre los requisitos, los planes del
proyecto y los productos de trabajo, e inicia acciones correctivas para resolverlas.
Ejemplos de productos de trabajo
1. Documentación de inconsistencias entre los requisitos y los planes del proyecto y los
productos de trabajo, incluyendo fuentes y condiciones.
2. Acciones correctivas.
Subprácticas
1. Revisar los planes del proyecto, las actividades y los productos de trabajo en cuanto a la
consistencia con los requisitos y los cambios realizados sobre ellos.
2. Identificar la fuente de la inconsistencia (si existe).
3. Identificar cualquier cambio que se debería realizar a los planes y a los productos de
trabajo resultantes de los cambios de la línea base de requisitos.
4. Iniciar cualquier acción correctiva necesaria.
44
2.5. Ciclo de Deming
En muchas organizaciones los procesos y los proyectos se han estado visualizando de una
manera lineal, donde se comienza a trabajar con los pedidos del cliente y, una a vez
culminado cada trabajo se inicia el siguiente y así sucesivamente hasta lograr el producto
final. En otras palabras, el proceso de la organización tiene un inicio y fin, el cual no es otro
que obtener los resultados previstos según sus objetivos.
Hoy en día, las organizaciones en sus diferentes magnitudes requieren de una transformación
en la manera de pensar y actuar.
W. Edward Deming establece:” La administración se encuentra en un estado estable y solo
una transformación profunda es necesaria para salir del estado actual y no unos simples
remiendos al sistema de gestión actual.
Podemos decir entonces que bajo este enfoque, la empresa tiene que verse como un sistema
integrado donde intervienen procesos, recursos y controles orientados al logro de los
objetivos y metas de la organización.
Las bases de este cambio son la adopción de una nueva filosofía de calidad, el compromiso
gerencial y la búsqueda incesante del mejoramiento. A este proceso se le denomina Mejora
Continua. La Mejora Continua es algo más que aplicar una serie de herramientas o técnicas
que se pueden aprender en un seminario o curso, es una visión total y diferente de la
organización y un modo de vida organizacional que debe aprenderse, reaprenderse y refinarse
con el tiempo en un medio propicio”.
La Mejora Continua es también conocida como Kaizen, una palabra de origen japonés, donde
Kai" significa cambio y "Zen" significa para mejor. La mejora continua debe ser parte de la
filosofía y la planificación de cada organización y también debe ser tomada en serio desde la
Alta Dirección. Tener la voluntad de querer mejorar de forma continua es necesario, tanto en
lo personal, como en lo profesional y organizacional.
Preocuparse por la mejora continua significa preocuparse por la supervivencia, pues esta
contribuye mucho a que una organización avance.
45
La Mejora Continua consiste en desarrollar ciclos de mejora en todos los niveles, donde se
ejecutan las funciones y los procesos de la organización. Con la aplicación de una modalidad
circular, el proceso o proyecto no termina cuando se obtiene el resultado deseado, sino que
más bien, se inicia un nuevo desafío no sólo para el responsable de cada proceso o proyecto
emprendido, sino también para la propia organización.
Además, permite identificar las oportunidades de mejora y se aplican análisis con métodos
más simples y eficientes para reducir costos, eliminar desperdicios y mejorar la calidad de los
productos y los servicios.
Hace años, W.Edward Deming presentó a los japoneses el ciclo PHVA Planifique – Haga –
Verifique y Actúe (en inglés PDCA Plan-do-check-act), el cual lo recibieron de buen grado
como una metodología para llevar a la práctica lo que ellos ya conocían como KaiZen.
Recientemente, este ciclo es adoptado por la familia de normas ISO 9000, como se señala en
el apartado 0.2 (nota), de la norma ISO 9001:2008, común ciclo de mejora continua. Este
ciclo es también denominado de Deming, en honor del hombre que lo popularizó, y el cual
fue sugerido por primera vez por Walter Shewart a comienzos del siglo veinte).
Basado en un concepto ideado por Walter A. Shewhart, el Ciclo PDCA constituye una
estrategia de mejora continua de la calidad en cuatro pasos, también se lo denomina espiral de
mejora continua y es muy utilizado por los diversos sistemas utilizados en las organizaciones
para gestionar aspectos tales como calidad (ISO 9000), medio ambiente (ISO 14000), salud y
seguridad ocupacional (OHSAS 18000), o inocuidad alimentaria (ISO 22000).
Las siglas PDCA son el acrónimo de las palabras inglesas Plan, Do, Check, Act, equivalentes
en español a Planificar, Hacer, Verificar, y Actuar. (Figura 12)
46
Figura 12: Ciclo de Mejora Continua basado en PDCA
La interpretación de este ciclo es muy sencilla: cuando se busca obtener algo, lo primero que
hay que hacer es planificar cómo conseguirlo, después se procede a realizar las acciones
planificadas (hacer), a continuación se comprueba qué tal se ha hecho (verificar) y finalmente
se implementan los cambios pertinentes para no volver a incurrir en los mismos errores
(actuar). Nuevamente se empieza el ciclo planificando su ejecución pero introduciendo las
mejoras provenientes de la experiencia anterior.
El ciclo PHVA es un ciclo dinámico que puede ser empleado dentro de los procesos de la
Organización. Es una herramienta de simple aplicación y, cuando se utiliza adecuadamente,
puede ayudar mucho en la realización de las actividades de una manera más organizada y
eficaz. Por tanto, adoptar la filosofía del ciclo PHVA proporciona una guía básica para la
gestión de las actividades y los procesos, la estructura básica de un sistema, y es aplicable a
cualquier organización.
A través del ciclo PHVA la empresa planea, estableciendo objetivos, definiendo los métodos
para alcanzar los objetivos y definiendo los indicadores para verificar que en efecto, éstos
fueron logrados. Luego, la empresa implementa y realiza todas sus actividades según los
procedimientos y conforme a los requisitos de los clientes y a las normas técnicas
establecidas, comprobando, monitoreando y controlando la calidad de los productos y el
desempeño de todos los procesos clave.
47
Luego, se mantiene esta estrategia de acuerdo a los resultados obtenidos, haciendo girar de
nuevo el ciclo PHVA mediante la realización de una nueva planificación que permita adecuar
la Política y los objetivos de la Calidad, así como ajustar los procesos a las nuevas
circunstancias del mercado.
2.5.1. Análisis de las fases del ciclo de Deming.
2.5.1.1 Plan (Planificar)
Consiste en formular un Plan sobre cómo proceder. Es la fase más influyente y define una
secuencia lógica de actividades:
Definir el tema, seleccionar el tema a estudiar y definir los objetivos.
Se deben utilizar todas las fuentes disponibles, indicaciones procedentes de clientes,
datos y hechos, políticas de dirección, sugerencias de distintas fuentes.
Seleccionar uno de los temas en función de los criterios de prioridad.
El tipo y la entidad del problema deben describirse de una forma clara.
Definir los objetivos cuantitativamente.
Observar y documentar la situación actual, se deben recoger datos.
Utilizar datos y hechos.
Medir la diferencia en que los datos obtenidos difieren de los esperados.
Analizar la situación actual, analizar los datos recogidos.
Procesar y estratificar los datos obtenidos para tener una mayor y clara información.
Determinar las causas posibles, decisiones orientadas por los datos y determinar las
causas reales.
Encontrar las posibles causas del problema
Algunas herramientas útiles para tal fin son: El diagrama de causa y efecto; el
Brainstorming (tormenta de ideas).
Hay que verificar la influencia real de las causas probables a través del análisis del
mayor número posible de datos o casos similares.
48
Determinar las medidas correctivas, acciones de modificación.
Una vez definidas las causas será necesario eliminar los efectos negativos del
problema.
Lo ideal es adoptar siempre medidas destinadas a eliminar las causas, teniendo
presente los posibles efectos derivados de las medidas correctoras.
En esta primera fase se elabora un diseño de las soluciones del problema, un diseño
aún teórico que tendrá que ser ratificado por los hechos.
2.5.1.2 Do (Hacer)
Significa hacer lo que se ha determinado en el plan. Para ello, se deben preparar las pruebas o
test, indicando cómo deben desarrollarse a través de procedimientos y explicarlo a las
personas que van a llevar a cabo la ejecución de las pruebas o test.
La fase de Hacer incluye:
La verificación y aplicación de las medidas correctivas definidas en el plan.
La introducción de las modificaciones al plan inicial, si no ha sido positivo el resultado de
las medidas correctivas.
Anotar el trabajo desarrollado y de los resultados obtenidos.
La formación del personal que deba aplicar las soluciones propuestas; es necesario para una
adecuada comprensión y familiarización con las medidas correctivas que se hayan definido.
2.5.1.3 Check (Controlar)
Se verifica si se ha alcanzado el objetivo. Es necesario controlar si lo que se ha definido se
desarrolla correctamente. Lo primero que se debe hacer es contestar a las siguientes
preguntas:
¿Qué vamos a controlar?
¿Cuándo lo haremos?
¿Dónde se piensa controlar?
En la fase Check se puede controlar las causas, sobre todo las críticas, por ejemplo:
Se controla si la calidad de las materias primas corresponden a las especificaciones.
49
Si la maquinaria, los equipos, etc. operan en la forma programada y especificada.
2.5.1.4 Act (Actuar)
La fase Actuar sirve para normalizar la solución del problema y establecer las condiciones
que permiten mantenerlo.
Pueden darse dos situaciones:
Se ha alcanzado el objetivo
No modificar la situación y normalizar las medidas correctivas, modificaciones
aplicadas (procesos, operaciones y procedimientos).
Ampliar la comprensión y la formación.
Verificar si las medidas correctivas normalizadas se aplican correctamente y si resultan
eficaces.
Continuar operando en la forma establecida.
Sí, no se ha alcanzado el objetivo, se debe:
Examinar todo el ciclo desarrollado para identificar errores.
Empezar un nuevo ciclo PDCA.
50
CAPITULO 3. PROBLEMA
En este capítulo se presenta el problema que se pretende resolver en este trabajo de tesis. Para
ello, se desarrolla la problemática que intenta solucionar este trabajo de investigación (3.1)
junto con la justificación expuesta para llevar a cabo su resolución (sección 3.2) finalizando
con las preguntas de investigación que se intenta responder mediante este trabajo de tesis
(sección 3.3).
3.1. Introducción
En muchas empresas la elicitación de requisitos no lo han considerado parte del ciclo de vida
de desarrollo de software hasta hace relativamente pocos años. Se acostumbraba asumir que
el cliente proporcionaba los requisitos, de forma que el ciclo de vida comenzaba siempre por
el análisis de unos requisitos ya dados, ya que las actividades de elicitación y validación no se
consideraban necesarias. Últimamente las organizaciones desarrolladoras de software han
detectado que los problemas en los requisitos son unos de los principales factores de los
fracasos de los proyectos de software (GAO 1979, TSG 1995, ESP1996).
A nivel de investigación, la elicitación es sin duda la actividad a la que menos atención se ha
prestado en la ingeniería de requisitos como lo dicen Christel y Kang (1992) y Goguen y
Linde (1993).
3.2. Descripción del problema
La mayor parte de los problemas de organizaciones desarrolladoras de software están
relacionados a la ingeniería de requisitos, y dentro de ésta, con la elicitación de dichos
requisitos.
La tarea de captura de los requisitos es compleja desde el mismo momento en que deben
acceder a las fuentes de información (Chatzoglou and Macaulay 1997b). Davis (1993), refiere
a que “Es trabajo de los analistas descubrir no sólo lo que los usuarios dicen que quieren sino
lo que ellos realmente necesitan”.
51
De acuerdo a lo planteado por la Ing. Luz Estela Pineda Forero (2013), Browne and Rogich
(2001) mencionan las siguientes dificultades durante el proceso de elicitación:
Dificultades del conocimiento, resultantes de las restricciones humanas como
procesadores de información.
Dificultades de estructuración, resultantes de la variedad y complejidad de los
requisitos de información.
Dificultades de comunicación, que se deben a la complejidad de la interacción entre
usuarios y analistas al definir requisitos.
Por otro lado Vasulek and Fryback (1987) clasifica los obstáculos para este proceso de
elicitación en tres tipos:
Obstáculos “en”. Se corresponde con las dificultades que provienen de limitaciones
cognitivas o de comportamiento individual de los participantes.
Obstáculos “entre (varios)”. Referidos a aquellos obstáculos que representan
inconsistencias o diferencias de prioridades o contenidos entre los usuarios.
Obstáculos y “entre (dos)”. Son las limitaciones psicológicas o de comunicación de la
interacción analista-usuario. Algunos intentos de resolver estas limitaciones han
arrojado propuestas de herramientas sin resultados conocidos [Valenti et al. 1998].
Christel and Kang (1992) clasifican los problemas del proceso de educción en tres tipos:
Problemas de alcance, relacionados con la obtención de poca o mucha información.
Problemas de entendimiento, en o entre los grupos de usuarios y desarrolladores.
Problemas de volatilidad, referidos a la naturaleza cambiante de los requisitos.
La participación del usuario es importante, pero también lo es determinar cuánto y cómo debe
hacerlo (Saiedian and Dale 2000). En muchos casos, la participación se torna perjudicial por
la falta de cooperación, la abierta hostilidad y la falta de disponibilidad de los usuarios (El
Emam and Madhavji 1995a).
52
La interacción entre usuario y analista provoca diversos problemas de comunicación que
supeditan a calidad de los resultados a la habilidad del analista para instar al usuario a dar una
descripción detallada y objetiva del dominio de aplicación (Cucchiarelli et al. 1994).
Esta interacción analista-usuario presenta dificultades por la pobreza en la calidad de la
comunicación, resistencias a expresarse, diferencia de terminología y de perspectivas
(Saiedian and Dale 2000). Esto se ilustra en la Figura 13.
Usuario Elicitación Analista
Figura 13: Interacción Analista – Usuario
Por lo tanto, debido a los problemas y dificultades mencionados anteriormente, se considera
que la implementación de una KPA del modelo de calidad de CMMi puede ayudar a mejorar
al proceso de elictación de requerimientos.
3.3 Preguntas de investigación
1. ¿Cómo se puede disminuir la mala comprensión y la falta de documentación de los
requerimientos durante el desarrollo del software?
2. ¿ Por qué la trazabilidad del futuro sistema no es mantenida durante el todo del ciclo de
desarrollo de software?.
3. ¿Aporta algún beneficio la aplicación del proceso metodológico propuesto a los proyectos
de desarrollo del software y al proceso de elicitación de los requerimientos de software?
53
CAPITULO 4. SOLUCIÓN
En este capítulo se desarrolla la propuesta del proceso metodológico para la mejora continua
de la elicitación de requerimientos de Software basado en el área de proceso de REQM de
CMMI DEV v1.3.
4.1 Análisis del proceso metodológico planteado
Cuando nos encontramos o estamos al frente de un desarrollo de sistemas o de software, es
muy importante dejar claramente definidos los requerimientos en forma consistente y
compacta, ya que en ésta primera etapa de la elicitación de requerimientos es la tarea más
difícil, básicamente porque consiste en la traducción de ideas vagas o generalizadas de
necesidades de software a un conjunto concreto de funciones y restricciones.
Debido a este planteo, debemos pensar en un proceso metodológico que permita mejorar
continuamente la elicitación de requerimientos de software, el cual está basado en el ciclo de
Deming o ciclo de mejora continua conformado por las siguientes etapas: Planificación,
Ejecución, Control y Mejora. Estas etapas permiten plantear una retroalimentación basada en
las observaciones o no conformidades detectadas, las cuales serán planificadas nuevamente
para su futura corrección. Este ciclo puede ser aplicado en pequeños y grandes proyectos con
el fin de obtener excelentes resultados en la gestión de proyectos de desarrollo de software.
Estas etapas pertenecientes al ciclo de Deming pueden ser aplicadas a los procesos de
conceptualización, diseño, ejecución y evaluación de proyectos de desarrollo de software,
centrado en la orientación por objetivos, la orientación hacia grupos beneficiarios y facilita la
participación y la comunicación entre las partes interesadas.
4.2. Solución Propuesta
Teniendo en cuenta lo expresado en el punto anterior, se plantea definir un proceso
metodológico que permita integrar el ciclo de Deming y el área de proceso de manejo de
requerimiento de CMMI con la finalidad de implementar cada etapa de Deming teniendo en
cuenta esta área de proceso. En la “Planificación” se realiza un plan respecto de los futuros
requerimientos. En la “Ejecución” se implementan los componentes del área de proceso IR de
CMMI. En el “Control” se realizan revisiones respecto de las implementaciones realizadas.
En la “Evaluación”, se realizan evaluaciones cuantitativas usando métricas o indicadores.
Dicha Evaluación forma parte de la etapa de Mejora Por último, en la “Mejora”, en caso de
54
tener controles o evaluaciones insatisfactorias, se implementan las acciones correctivas y/o
preventivas correspondientes. Dichas mejoras deben ser planificadas nuevamente para su
futura implementación. Esto se ilustra en el gráfico tradicional del Ciclo de Deming en la
Figura 14.
Figura 14: Solución propuesta
Esta solución propuesta es una alternativa para un mejor entendimiento y negociación con los
involucrados y del problema a resolver, ya que la elicitación es una de las actividades más
problemáticas y con mayores índices de fallas y fracasos en el proceso de desarrollo de
software.
Dicha elicitación es implementada en la parte “Ejecución”, según el ciclo de Deming,
teniendo en cuenta las practicas especificas del área de proceso de Manejo de Requerimientos
de CMMI para Desarrollo v1.3.
55
4.2.1. Proceso metodológico para la mejora continua de la elicitación de requerimientos
de software basada en el área de proceso de Gestión de Requerimientos de CMMi para
Desarrollo v1.3.
Este trabajo plantea un proceso metodológico que es implementado usando una planilla
Excel, el cual especifica por medio de sus tabs cada una de las etapas del proceso
metodológico mencionado:
Tab N° 1 “Plan”
Tab N° 2 “Informes Plan”
Tab N° 3 “Ejecucion”
Tab N° 4 “Informes Ejecución”
Tab N° 5 “Control”
Tab N° 6 “Informes Control”
Tab N° 7 “Evaluación”
Tab N° 8 “Informes Evaluación”
Tab N° 9 “Mejoras”
Tab N° 10 “Informes Mejoras”
Tab N° 11 “Resumen”
Todos estos Tabs se ilustran desde la Figura 14 a la 25 respectivamente.
Tab N° 1 – “Plan”
Este tab permite registrar la planificación de las tareas basadas en la KPA, el cual está
formado por los siguientes campos:
#: Número de la tarea
Tarea: Nombre de la tarea teniendo en cuenta la KPA de CMMi
# Tarea Predecesora: número de la tarea relacionada a la tarea que se está definiendo
Iniciales Responsable: Iniciales del responsable de la tarea definida
SP Definida CMMi: abreviatura de la práctica especifica relacionada a la tarea
definida
% Avance Duración: % de avance de la tarea definida
Planificación estimada: tiempo estimado de la planificación
56
Duración estimada tarea: tiempo de duración de la tarea definida
Fecha comienzo estimada: fecha de inicio estimada de la tarea definida
Fecha finalización estimada: fecha de finalización estimada de la tarea definida
Planificación real: tiempo real de la planificación
Duración real tarea: tiempo de duración de la tarea definida
Fecha comienzo real: fecha de inicio real de la tarea definida
Fecha finalización real: fecha de finalización real de la tarea definida
57
Tab N° 1 – “Plan”
Figura 15: Template Tab N° 1
58
Tab N° 2 – “Informes Plan”
Este tab permite visualizar la situación actual de las tareas definidas en el plan. Este
informe está formado por los siguientes campos:
Administración de las tareas: Estado de la tarea definida
Cantidad: Cantidad de tareas que se encuentran en determinado estado
%: porcentaje de tareas que se encuentran en determinado estado.
Figura 16: Template Tab N° 2
Tab N° 3 – “Ejecución”
Este tab permite registrar los productos de trabajo obtenido de las tareas ejecutadas y
establecidas en el plan. Este tab está formado por los siguientes campos:
#: Número del producto del trabajo
Producto de trabajo: Nombre del producto de trabajo resultante de la ejecución de una
práctica especifica de la KPA
# Tarea Ejecutada Asociada: número de la tarea relacionada al producto de trabajo
definido
Iniciales Responsable: Iniciales del responsable del producto de trabajo
SP Definida CMMi: abreviatura de la práctica especifica relacionada al producto de
trabajo definido
Fecha última actualización: fecha de la última actualización del producto de trabajo
definido
SP Definida CMMi: abreviatura de la práctica especifica relacionada al producto de
trabajo definido
Fecha última actualización: fecha de la última actualización del producto de trabajo
definido
59
Estado del producto de trabajo: estado actual del producto de trabajo definido
Figura 17: Template Tab N° 3
Tab N° 4 – “Informes Ejecución”
Este tab permite visualizar el estado de los productos de trabajo a realizar. Este informe
está formado por los siguientes campos:
Estado de los productos de trabajo: Estados posibles de un producto de trabajo
Cantidad: Cantidad de veces que se repite el estado de un producto de trabajo
%: porcentaje de productos de trabajo que tiene un estado determinado
Figura 18: Template Tab N° 4
60
Tab N° 5 – “Control”
Este tab permite llevar a cabo un registro de control de todos los productos de trabajo
obtenidos de las tareas ejecutadas y establecidas en el plan. Este tab está formado por los
siguientes campos:
#: Número del producto del trabajo.
Control: Nombre del producto de trabajo resultante de la ejecución.
Producto de trabajo: Nombre del producto de trabajo resultante de la ejecución de una
práctica especifica de la KPA
# Tarea Ejecutada: número de la tarea relacionada al producto de trabajo definido
Iniciales Responsable: Iniciales del responsable del producto de trabajo
SP Definida CMMi: abreviatura de la práctica especifica relacionada al producto de
trabajo definido
Fecha control: fecha del último control del producto de trabajo definido
Resultado del Control: Resultado del producto de trabajo
Mejora Continua: Número de la mejora relacionado al control realizado
Figura 19: Template Tab N° 5
61
Tab N° 6 – “ Informes de Control”
Este tab permite visualizar el estado de los productos de trabajo a realizar. Este informe
está formado por los siguientes campos:
Resultado del Control: Estados posibles de un producto de trabajo
Cantidad: Cantidad de veces que se repite el estado de un producto de trabajo
%: porcentaje de productos de trabajo que tiene un estado determinado
Figura 20: Template Tab N° 6
Tab N° 7 – “Evaluación”
Este tab permite llevar a cabo un registro de todos los productos de trabajo evaluados
establecidos en el plan. Este tab está formado por los siguientes campos:
#: Número del producto del trabajo a evaluar.
Evaluación: Nombre del producto de trabajo
#Producto de trabajo: Nombre del producto de trabajo a evaluar
Indicador/Métrica: Nombre de la métrica que se utilizará en la evaluación.
Algunos de los posibles indicadores o métricas serían:
- Cantidad de proveedores apropiados de requisitos
- Cantidad de proveedores no apropiados de requisitos
- Cantidad de criterios de evaluación definidos
- Cantidad de criterios de evaluación utilizados
- Cantidad de análisis satisfactorios de los criterios
- Cantidad de análisis insatisfactorios de los criterios
- Cantidad de evaluaciones satisfactorias del impacto de los requisitos
62
- Cantidad de evaluaciones insatisfactorias del impacto de los requisitos
- Cantidad de compromisos documentados de los requisitos y sus cambios
- Cantidad de compromisos no documentados de los requisitos y sus cambios
- Cantidad de peticiones realizadas de cambio de requisitos
- Cantidad de peticiones faltantes de cambio de requisitos
- Cantidad de informes emitidos sobre el impacto del cambio de requisitos
- Cantidad de requisitos pendientes
- Cantidad de requisitos cumplidos
- Cantidad de requisitos actualizados en la base de datos
- Cantidad de requisitos ingresados a la base de datos
# Tarea Ejecutada: número de la tarea relacionada al producto de trabajo definido
Iniciales Responsable: Iniciales del responsable del producto de trabajo evaluado
SP Definida CMMi: abreviatura de la práctica especifica relacionada al producto de
trabajo definido
Fecha evaluación: fecha de la evaluación del producto de trabajo definido
Valor esperado indicador: Valor esperado que se obtiene al realizar la evaluación usando
la métrica o indicador.
Valor real indicador: Valor real del indicador evaluado
Resultado de la evaluación: resultado de la evaluación realizada
Mejora Asociada: Mejora relacionada a la evaluación
Figura 21: Template Tab N° 7
63
Tab N° 8 – “Informe Evaluación”
Este tab permite visualizar el estado de los productos de trabajo evaluados. Este informe
está formado por los siguientes campos:
Resultado de la evaluación: Estados posibles de un producto de trabajo
Cantidad: Cantidad de veces que se repite el estado de un producto de trabajo
%: porcentaje de productos de trabajo que tiene un estado determinado
Figura 22: Template Tab N° 8
Tab N° 9 – “Mejoras”
Este tab permite llevar a cabo un registro de mejora de todos los productos de trabajo
establecidos en el plan. Este tab está formado por los siguientes campos:
#: Número del producto del trabajo a evaluar.
Mejora: Nombre del producto de trabajo a mejorar.
#Producto de trabajo: Nombre del producto de trabajo a mejorar.
Iniciales Responsable: iniciales del responsable de la mejora de producto de trabajo.
Tarea Asociada: número de la tarea relacionada al producto de trabajo a mejorar.
SP CMMi Asociada: abreviatura de la práctica especifica relacionada al producto de
trabajo a mejorar.
Fecha última actualización: fecha ultima del producto de trabajo actualizado.
N° Control: Número de control relacionado a la mejora
N° Evaluación: Número de evaluación relacionada a la mejora
Estado de la mejora: Estado de la mejora a implementar
64
Figura 23: Template Tab N° 9
Tab N° 10 – “Informes Mejoras”
Este tab permite visualizar el estado de las mejoras de los productos de trabajo. Este
informe está formado por los siguientes campos:
Estado de las Mejoras de los productos de trabajo: Estados posibles de un producto de
trabajo
Cantidad: Cantidad de veces que se repite el estado de un producto de trabajo
%: porcentaje de productos de trabajo que tiene un estado determinado
Figura 24: Template Tab N° 10
65
Tab N° 11 – “Resumen”
Este tab permite visualizar el resumen de los productos de trabajo. Este informe está
formado por los siguientes campos:
Administración de las tareas:
Estado de los productos de trabajo:
Resultado del Control:
Resultado de la Evaluación:
Estado de las Mejoras de los productos de trabajo: Estados posibles de un producto de
trabajo
Cantidad: Cantidad de veces que se repite el estado de un producto de trabajo
%: porcentaje de productos de trabajo que tiene un estado determinado
Figura 25: Template Tab N° 11
66
CAPITULO 5. VALIDACION DE LA SOLUCION PROPUESTA
En este capítulo se procede a validar la presente propuesta correspondiente al proceso
metodológico planteado en el desarrollo de la tesis.
5.1 Planteo de Caso de Estudio 1 y Formularios
SISTEMA DE ADMINISTRACIÓN DE PÓLIZAS DE SEGURO
En esta subsección se plantea el caso de una compañía de seguros cuyo sistema principal
es el sistema de administración de pólizas.
El área de proceso de Gestión de Requerimiento perteneciente a CMMi para Desarrollo
v1.3 es tenida en cuenta para la administración de los requerimientos luego de ser
aprobados por las partes interesadas.
En el tab “Plan” se especifican las tareas que conforman el área de proceso de Gestión de
Requerimientos.
Los componentes de esta área de proceso (SG: Objetivo Específico y SP: Práctica
Específica) pasaron a formar las tareas de este plan de proyecto. Cada tarea de este plan de
proyecto tiene asignado una tarea predecesora, la cual permite analizar la situación de cada
tarea definida.
En esta planificación se tiene en cuenta solo las tareas y subtareas que conforman las 3
primeras prácticas específicas de CMMi para Desarrollo (de 2 a 14).
En la columna “% Avance Duración” se observa que la mayoría de las tareas están
atrasadas excepto las tareas del 4 al 8.
En el tab “Informes Plan” se da conocer la situación actual de la información registrada en
el tab Plan (tarea en Procesos, Atrasadas y Terminadas).
En el tab “Ejecución” se especifican los productos de trabajo de las tareas establecidas en
el tab Plan. Respecto del estado de los productos de trabajo planteados se observa que la
mayoría están pendientes y luego existen una menor cantidad que están en el resto de los
estados definidos.
Los posibles productos pendientes pueden implicar una re-planificación de las tareas
específicas.
En el tab “Informes Ejecución” se determina que la mayoría de los productos están
67
pendientes, no hay que actualizar ninguno y el resto de los estados presentan una sola
ocurrencia.
En el tab “Control” se realizan los controles de los productos de trabajo especificados. En
este caso se observa que el resultado de los controles realizados en su mayoría fue
“Satisfactorio c/Observación”. Existen tres casos de control Insatisfactorio y un solo caso
de control Satisfactorio. Cabe mencionar que para los dos primeros casos se deben
implementar las acciones de mejora respectivas.
En el tab “Informes Control” se observa que la mayoría ha sido satisfactorio con
observaciones, luego 3 casos Insatisfactorio y 1 solo Satisfactorio, por lo tanto se deberán
implementar las acciones de mejoras necesarias.
En el tab “Evaluación”, se observa 1 solo caso Satisfactorio y el resto ha sido
“Satisfactorio c/Observación” por lo tanto para estos últimos casos se deberán implementar
las acciones de mejoras necesarias.
En el tab “Informes Evaluación” se observa que solo hubo 1 sola evaluación Satisfactoria y
el resto fueron evaluaciones Satisfactoria con Observaciones.
En el tab “Mejoras” se determina que la mayoría de los productos fueron evaluados y que
el resto está pendiente (1), Implementado (2) y Controlado (1).
En el tab de “Informes Mejoras” se visualiza gráficamente lo explicado en el párrafo
anterior.
En el tab “Resumen” se tiene una sinopsis de los resultados obtenidos de cada uno de los
tabs desarrollados. Por lo tanto se puede decir que el 78% de las tareas están en proceso, el
62% de los productos están pendientes, el 60% de los controles ha sido Satisfactorios con
Observaciones, el 90% de las evaluaciones ha sido Satisfactorios con Observaciones y el
60% de las mejoras han sido hasta la fecha Evaluadas.
Como conclusión se puede decir que se debería plantear una re-planificación de las tareas
establecidas con un control exhaustivo de los productos de trabajo que se generan en las
mismas.
68
Formularios del Caso de Estudio 1
Tab1: Plan.
Figura 26: Plan Caso de Estudio 1
Tab2: Informes Plan
Figura 27: Informes del Plan
69
Tab3: Ejecución
Figura 28: Ejecución del Plan
Tab4: Informes Ejecución
Figura 29: Informes de Ejecución
70
Tab5: Control
Figura 30: Control de Producto de Trabajo
Tab6: Informes Control
Figura 31: Informes de Control
71
Tab7: Evaluación
Figura 32: Evaluación de Productos de Trabajo
Tab8: Informe Evaluación
Figura 33: Informe de Evaluación
72
Tab9: Mejoras
Figura 34: Mejoras de Producto de Trabajo
Tab10: Informe de Mejoras
Figura 35: Informes de Mejoras
73
Tab11: Resumen
Figura 36: Resumen de Informe
74
5.2 Planteo de Caso de Estudio 2 y Formularios
SISTEMA DE ADMINISTRACION DE EXALUMNOS
En esta subsección se plantea el caso de una universidad cuyo sistema es la administración
de egresados, fundamental para no perder contactos con los mismos y seguir ofreciendo los
servicios de la universidad.
El área de proceso de Gestión de Requerimiento perteneciente a CMMi para Desarrollo
v1.3 es tenida en cuenta para la administración de los requerimientos de este sistema luego
de ser aprobados por las partes interesadas.
En el tab “Plan” se especifican las tareas que conforman el área de proceso de Gestión de
Requerimientos.
Los componentes de esta área de proceso (SG: Objetivo Específico y SP: Práctica
Específica) pasaron a formar las tareas de este plan de proyecto. Cada tarea de este plan de
proyecto tiene asignado una tarea predecesora, la cual permite analizar la situación de cada
tarea definida.
En esta planificación se tiene en cuenta solo las tareas y subtareas que conforman las 3
primeras prácticas específicas de CMMi para Desarrollo (de 2 a 14).
En la columna “% Avance Duración” se observa que la mayoría de las tareas fueron
terminadas a tiempo y muy pocas están atrasadas.
En el tab “Informes Plan” se da conocer que la mayoría de las tareas están terminadas y en
proceso; y muy pocas son las tareas atrasadas.
En el tab “Ejecución” se especifican los productos de trabajo de las tareas establecidas en
el tab Plan. Respecto del estado de los productos de trabajo planteados se observa que la
mayoría están terminadas, no existe ningún caso actualizado y existe una menor cantidad
que ésta en el resto de los estados definidos.
En el tab de “Informes Ejecución” se visualiza gráficamente lo explicado en el párrafo
anterior.
En el tab “Control” se realizan los controles de los productos de trabajo especificados. En
75
este caso se observa que el resultado de los controles realizados en su mayoría fue
“Satisfactorio”. Existen solo 2 casos de control Satisfactorio c/Observación. Cabe
mencionar que para estos dos casos se deberán implementar las acciones de mejora
respectivas.
En el tab de “Informes Control” se visualiza gráficamente lo explicado en el párrafo
anterior.
En el tab “Evaluación”, se observa que en la mayoría el resultado ha sido Satisfactorio, 3
casos “Satisfactorio c/Observación” y 1 solo Insatisfactorio. Por lo tanto para estos 2
últimos casos se deberán implementar las acciones de mejoras necesarias.
En el tab de “Informes Control” se visualiza gráficamente lo explicado en el párrafo
anterior.
En el tab “Mejoras” se determina que la mayoría de los productos fueron implementados y
que el resto está Pendiente (1), Evaluado (2) y Controlado (1).
En el tab de “Informes Mejoras” se visualiza gráficamente lo explicado en el párrafo
anterior.
En el tab “Resumen” se tiene una sinopsis de los resultados obtenidos de cada uno de los
tabs desarrollados. Por lo tanto se puede decir que el 48% de las tareas están realizadas, el
46% de los productos están terminados, el 70% de los controles ha sido Satisfactorios, el
60% de las evaluaciones ha sido Satisfactorios y el 60% de las mejoras han sido hasta la
fecha Implementadas.
Como conclusión se puede decir que se debería seguir con un control y seguimiento
exhaustivo de las tareas para determinar aquellos riesgos que puedan impedir el normal
desarrollo del proyecto.
76
Formularios del Caso de Estudio 2
Tab1: Plan
Figura 37: Plan Caso de Estudio 2
Tab2: Informes Plan
Figura 38: Informes del Plan
77
Tab3: Ejecución
Figura 39: Ejecución del Plan
Tab4: Informes Ejecución
Figura 40: Informes de Ejecución
78
Tab5: Control
Figura 41: Control de Producto de Trabajo
Tab6: Informes Control
Figura 42: Informes de Control
79
Tab7: Evaluación
Figura 43: Evaluación de Productos de Trabajo
Tab8: Informes Evaluación
Figura 44: Informes de Evaluación
80
Tab9: Mejoras
Figura 45: Mejoras de Producto de Trabajo
Tab10: Informes Mejora
Figura 46: Informes de Mejoras
81
Tab11: Resumen
Figura 47: Resumen de Informes
82
CAPITULO 6. CONCLUSIONES Y APORTACIONES DE ESTA TESIS
6.1 Conclusiones y Aportes
A partir de este trabajo de investigación se obtuvieron distintas conclusiones (6.1.1 a 6.1.5)
y aportes (6.1.6):
6.1.1 Valoración sobre la investigación documental
En el desarrollo de la investigación de este trabajo se plantean diferentes capítulos.
En el capítulo1 se determina la estructura y los componentes que tendría el trabajo.
En el capítulo2 se determina la situación actual respecto de la elicitación de requerimientos
de software, requerimientos de software, ingeniería de requerimientos, modelo de madurez
de capacidades Integrado CMMI para Desarrollo v1.3 y ciclo de Deming.
En el capítulo 3 se plantea la definición de un posible problema que puede tener la
elicitación de requerimientos.
En el capítulo 4 se plantea una posible solución al problema definido en el capitulo3.
En el capitulo5 se realiza una validación de la solución planteada en el cap. 4 a través de 2
casos de estudio.
En la última parte se realizan las conclusiones, las aportaciones de este trabajo de
investigación y se determina las futuras líneas de investigación.
6.1.2 Valoración del problema.
En el capítulo 3, se plantea las dificultades y problemas de la elicitación de requerimientos
en un proceso de desarrollo de software tales como:
Dificultades cognitivas, resultantes de las restricciones humanas como
procesadores de Información.
Dificultades de estructuración, resultantes de la variedad y complejidad de los
requisitos de información.
Dificultades de comunicación, que se deben a la complejidad de la interacción entre
usuarios y analistas al definir requisitos.
Problemas de alcance, relacionados con la obtención de poca o mucha información.
Problemas de entendimiento, en o entre los grupos de usuarios y desarrolladores.
83
Problemas de volatilidad, referidos a la naturaleza cambiante de los requisitos.
Estas dificultades y problemas pueden alterar en normal desarrollo de un proyecto
provocando aumentos en los tiempos, en los costos y satisfacción por parte del cliente.
6.1.3. Valoración de la Solución
En el capítulo 4, se propone una posible solución que plantea el concepto de mejora
continua aplicado a la elicitación de requerimiento. A pesar de los posibles problemas que
se presente esta solución podría disminuir las consecuencias de los problemas planteados.
Esta mejora continua se implementa a través de la herramienta de ciclo de Deming, el cual
permite que por medio de la retroalimentación aquellos defectos o errores encontrados
puedan ser tratados nuevamente a través de la ejecución de sus 4 fases: Planificación,
Ejecución, Control, Evaluación y Mejora.
6.1.4. Valoración del caso de Estudio.
En el capítulo 5 se plantean 2 casos de estudio que permite la puesta en práctica de la
solución planteada en el capítulo 4. En ambos casos, se espera implementar las mejoras
pertinentes para el normal desarrollo de los proyectos.
El proceso metodológico propuesto permite trabajar de manera ordenada para de esta
forma poder cumplir con los objetivos establecidos. Este proceso metodológico plantea
etapas que generan entregables los cuales permite evaluar el desarrollo de la elicitación de
requerimientos.
Este proceso metodológico puede ser aplicable a todo tipo de proyecto (implantación de
ERP, desarrollo de un aplicativo, implantación de un modelo/estándar de calidad, entre
otros) que requiera de la elicitación de requerimientos como parte componente de su
desarrollo.
El proceso metodológico propuesto plantea posibles templates (diseños predefinidos) que
pueden ser modificados y/o implementados para la gestión de la elicitación de
requerimientos.
84
6.1.5. Respuesta a los interrogantes de investigación.
Las respuestas a las interrogantes de investigación realizadas en la sección 3.3 se pueden
resumir en:
1.- La mala comprensión de los requerimientos puede disminuir por medio de reuniones o
revisiones por pares que permitan confirmar los requerimientos establecidos. En algunos
casos, se pueden establecer “acuerdos entre las partes” que certifiquen los requerimientos
establecidos. Desde el inicio del proyecto y durante su desarrollo se deberán generar los
documentos relacionados a la elicitación de requerimientos. Dichos documentos deberán
ser actualizados y/o revisados periódicamente.
2.- La trazabilidad del futuro sistema debe ser mantenida durante todo el ciclo de
desarrollo del aplicativo. Cada persona que conforma el equipo de desarrollo deberá
mantener la trazabilidad del sistema e informarla.
3.- La aplicación del proceso metodológico propuesto tiene como beneficio que se aplica la
filosofía de la mejora continua, la cual puede ser implementada tanto al proceso de
elicitación como al proyecto de desarrollo de software.
6.1.6. Aportes de la Tesis.
Esta tesis genera los siguientes aportes:
1. Mejorar la calidad de la elicitación de requerimientos por medio de un documento.
2. Plantear un proceso metodológico que ayude a la elicitación de los requerimientos.
3. Debido al ciclo de Deming, la elicitación de requerimiento es evaluada de manera
continua.
4. La implementación de ciclo de Deming genera información de cada etapa lo cual
permite tomar decisiones e implementar futuras mejoras
6.2. Futuras Líneas de investigación.
Podemos citar posibles líneas de investigación a la solución planteadas:
1. Automatización del proceso metodológico planteado a través de un aplicativo a medida.
2. Plantear una mejora al proceso metodológico propuesto, la cual permita establecer un
tablero de control operativo basado en los indicadores y/o métricas utilizados en las
evaluaciones realizadas que forman parte del proceso metodológico. Este tipo de tablero de
control es una herramienta de calidad que ayuda a la toma de decisiones.
85
3. Integrar el proceso metodológico propuesto a la ingeniería de requerimientos, de tal
forma de poder aplicar el concepto de mejora continua en la elicitación de requerimientos
de CMMI DEV (Constelación de CMMI para Desarrollo).
4. Integrar el proceso metodológico propuesto a las siguientes áreas de procesos de
CMMi. (Manejo de Requerimientos y Desarrollo de requerimientos.)
5. Integrar el proceso metodológico propuesta al punto relacionado a gestión de
requerimientos perteneciente a la ISO 12207, la cual hace referencia a procesos de
desarrollo de software.
6. Integrar este proceso metodológico a metodologías de desarrollo que permitan controlar
y/o evaluar la calidad de un software.
De esta forma se puede decir que la evaluación contínua de la elicitación de requerimientos
puede ser una herramienta de ayuda para los actuales paradigmas de desarrollo de software
o para todo proceso de desarrollo de software.
86
CAPITULO 7. REFERENCIAS
Boehm, Barry: “Software Engineering”, IEEE Transactions on Computers Dic. 1976.
Boehm, Barry: “Software Engineering Economic”. New Jersey, Prentice Hall, 1981.
Bruegge, B., & Dutoit, A. (2002). Ingeniería del software orientado a objetos.
Pearson Educación. México.
Christel, M. G. & Kang, K. C. (1992). Issues in Requirements Elicitation. Technical
Report CMU/SEI-92-TR-12. ESC-TR-92-012. Requirements Engineering Project,
Carnegie Mellon University. USA.
CMMI para Desarrollo, Version 1.3, 2010. Mejora de los procesos para el
desarrollo de mejores productos y servicios.
Davis, A. (1992). Software Requirements: Objects, Functions and States. Prentice-Hall
Finkelstein, A. (1994) Requirements Engineering: a review and research agenda. Proc
1st Asian & Pacific Software Engineering Conference, IEEE CS Press.
IEEE International Symposium on Requirements Engineering 1995.
IEEE-Std.’610’ (1990) IEEE Standard Glossary of Software Engineering Terminology.
IEEE Computer Society Press
Jackson, M. (1995). Software Requirements & Specifications. Addison-Wesley
Kotonya, G., Sommerville, P. (1997). Requirements Engineering: Processes and
Techniques. John Wiley & sons.
Kotonya, G. & Sommerville, I. (1998). Requirements engineering: processes and
techniques. UK. John Wiley & Sons.
Leite, J., Hadad, G., Doorn, J., Kaplan, G., “A Scenario Construction Process”,
Requirements Engineering Journal, Vol. 5, Nro. 1, 2000, pp 36-61
Loucopoulos, P. and Karakostas, V. (1995) System Requirements Engineering,
McGraw Hill, London, 1995.
Loucopoulos P. Karakostas V., System Requirements Engineering, McGraw-Hill
International series in Software Engineering, ISBN 0-07-707843-8, 1995.
Nuseibeh B., Easterbrook S., Requirements Engineering: A Roadmap, ICSE2000,
2000, Limerick, Irlanda.
Oberg, Roger; Probasco, Leslee y Ericsson, Maria. RATIONAL SOFTWARE.Applying
requirements management with use cases [online].
87
Osborn, A. F. (1962). Developments in creative education. In S. J. Parnes & H. F.
Harding (Eds.),A source book for creative thinking (pp. 19-29). New York: Scribners.
Pfleeger Shari Lawrence, Ingeniería del Software. Editorial Prentice Hall Argentina,
2002. ISBN 9789879460719.
Pineda Forero, Estela. “Metodología para la elicitación de requerimientos de software
basada en el marco lógico (2013)".
Pohl, K. (1996). Requirements Engineering: An Overview. En “Encyclopedia of
Computer Science and Technology”, Vol. 36, Marcel Dekker Inc., New York
Pressman R. (2010). Ingeniería del software. Un enfoque práctico. Editorial Mc Graw
Hill. Séptima edición.
Sommerville, I. (2011). Ingeniería de software. 9 Edición. México. Pearson
Sommerville, I., Sawyer, P. (1997). Requirements Engineering: A Good Practice Guide.
John Wiley & sons.
Standard IEEE 830-1993: Recommended Practice for Software Requirements
Specifications. Institute of Electronic and Electrical Engineers Press.
Thayer, R. & Dorfam, M. (2000). Software Requirements Engineering. 2 ed. Los
Alamitos, California: IEEE Computer Science Press.
Yourdon, E. (2000). Análisis Estructurado Moderno. México: Pearson. ISBN 968-880-
330-0.
Whitten. J, & Bentley. L. (2008). Análisis de sistemas: diseño y métodos. Séptima
edición. Mc Graw Hill. España.
Wiegers, K. (2003). Software Requirements. 2 ed. Washington: Microsoft Press. ISBN
0-7356-1879-8. Página web vigente al 20/04/2012.
Zave, P. (1994); Call for Papers and Associated Classification Scheme;
88
ANEXO – GLOSARIO DE TERMINOS
CMMi: Es un modelo de calidad y de madurez de mejora de procesos de una
organización y un modelo de referencia que abarca las actividades de desarrollo y
mantenimiento aplicadas a productos y servicios.
CMMI-DEV: Es una constelación de CMMi basada en el CMMI Model Foundation o
CMF (es decir, componentes del modelo comunes a todos los modelos y constelaciones
CMMI ) e incorpora el trabajo realizado por organizaciones de desarrollo para adaptar
CMMI para su uso en el desarrollo de productos y servicios
Elicitación de requerimientos: Es un paso del ciclo de vida de los requerimientos en
el ciclo de vida de Software y consiste en la indagación o levantamiento de los
requerimientos por medio de técnicas conocidas y recomendadas.
Ingeniería de Requerimientos: Permite definir todas las actividades involucradas en
el descubrimiento, documentación y mantenimiento de los requerimientos para un
producto determinado. (Ortas, A (2001))
Mejora Continua: Consiste en desarrollar ciclos de mejora en todos los niveles, donde
se ejecutan las funciones y los procesos de la organización.
Requerimiento:
o Es una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
o Es una condición o capacidad que debe estar presente en un sistema o
componentes del sistema para satisfacer un contrato, estándar, especificación u
otro documento formal.
o Es una representación documentada de una condición o capacidad documentada
como las descritas en (1) y (2).
Requerimientos de la organización: Son los requerimientos que se derivan de las
políticas y procedimientos existentes en la organización del cliente y del desarrollador.
Entre estos se incluyen los requerimientos del proceso operacional, requerimientos del
proceso de desarrollo, estándares del entorno o del proceso a utilizar y requerimientos
ambientales.
89
Requerimientos del producto. Son los requerimientos que especifican o restringen el
comportamiento de un software. Entre estos encontramos: requerimientos de
rendimiento, requerimientos de fiabilidad, requerimientos de seguridad, y
requerimientos de usabilidad
Requerimientos externos. Son aquellos que incluye los requerimientos que se derivan
de los factores externos del sistema y del proceso de desarrollo. Se incluyen
requerimientos regulatorios, requerimientos legislativos, requerimientos éticos.
Requerimientos funcionales. Son los requerimientos que se relacionan con los
servicios que el sistema debe proveer, cómo el sistema debe reaccionar a entradas
particulares y cómo el sistema debe comportarse bajo situaciones particulares.
Requerimientos no funcionales. Son limitaciones sobre los servicios y
funcionalidades ofrecidos por el sistema. Estos incluyen restricciones en el tiempo que
debe demorar un proceso y restricciones sobre el proceso de desarrollo y estándares.