INSTITUTO POLITÉCNICO NACIONAL - · PDF fileSe revisaron los métodos...
217
INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN PROPUESTA DE UNA GUÍA PARA INTERPRETAR LOS PROCESOS DE MOPROSOFT DE LA CATEGORÍA DE OPERACIÓN USANDO UNA COMBINACIÓN DE MÉTODOS ÁGILES TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA P R E S E N T A ALLAN BALAM RUEDA GUTIÉRREZ DIRECTOR M. C. GUILLERMO PÉREZ VÁZQUEZ MÉXICO D.F. JULIO 2010
-
Upload
nguyentruc -
Category
Documents
-
view
231 -
download
0
Transcript of INSTITUTO POLITÉCNICO NACIONAL - · PDF fileSe revisaron los métodos...
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
PROPUESTA DE UNA GUÍA PARA INTERPRETAR LOS PROCESOS DE MOPROSOFT DE LA CATEGORÍA DE OPERACIÓN USANDO
UNA COMBINACIÓN DE MÉTODOS ÁGILES
TESIS
QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA
P R E S E N T A
ALLAN BALAM RUEDA GUTIÉRREZ
DIRECTOR
M. C. GUILLERMO PÉREZ VÁZQUEZ
MÉXICO D.F.
JULIO 2010
i
INSTITUTO POLITÉCNICO NACIONAL
SECRETARÍA DE INVESTIGACIÓN Y POSGRADO
CARTA DE CESIÓN DE DERECHOS
En la Ciudad de México, Distrito Federal, el día 30 del mes de julio del año 2010, el que
suscribe Allan Balam Rueda Gutiérrez, alumno del Programa de Maestría en Ciencias en
Informática con número de registro B071663, adscrito a la Unidad Profesional
Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas, manifiesta que es autor
intelectual del presente trabajo de Tesis bajo la dirección del M. en C. Guillermo Pérez
Vázquez y cede los derechos del trabajo titulado PROPUESTA DE UNA GUÍA PARA
INTERPRETAR LOS PROCESOS DE MOPROSOFT DE LA CATEGORÍA DE
OPERACIÓN USANDO UNA COMBINACIÓN DE MÉTODOS ÁGILES, al Instituto
Politécnico Nacional para su difusión, con fines académicos y de investigación.
Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos del
trabajo sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido
escribiendo a la siguiente dirección [email protected]. Si el permiso se otorga, el usuario
deberá dar el agradecimiento correspondiente y citar la fuente del mismo.
ii
AGRADECIMIENTOS
A todas las personas que hicieron posible el desarrollo de este proyecto,
a Dios, a mi Esposa, a mis Padres y Hermanos,
a mis Compañeros de trabajo y Amigos,
a mis Profesores del posgrado.
Gracias por su apoyo incondicional a lo largo de este camino.
iii
RESUMEN
En este trabajo de tesis, se presenta una propuesta de una guía para poder implementar los
procesos de la Categoría de Operación del Modelo de Procesos para la Industria del Software
(MoProSoft), utilizando para ello una combinación de métodos ágiles. La Categoría de
Operación abarca los procesos, Administración de Proyectos Específicos y Desarrollo y
Mantenimiento de Software.
Para realizar esta guía fue necesario consultar y analizar la norma mexicana NMX-I-
059-NYCE-2005. Se revisaron los métodos ágiles Scrum y Programación Extrema (XP) para
analizar las prácticas que utilizan y que pueden cumplir de manera ágil con los requisitos que
dice la norma en la parte 2.
Se llevó a cabo la implementación de esta guía en una empresa que tiene un área
específica para desarrollar software y sistemas de información y se llevó a cabo un proyecto
piloto para el desarrollo de un sistema de información en línea utilizando los procesos que se
definieron a partir de esta guía.
iv
ABSTRACT
This thesis presents a proposal for a guide to implement the Operation Category Processes of
Process Model for Software Industry (MoProSoft), using a combination of agile methods. This
category covers Specific Projects Management process and Software Development and
Maintenance process.
Analyze and review the Mexican standard NMX-I-059-NYCE-2005 was needed in
order to development this guide. The Scrum and Extreme Programming (XP) agile methods’
practices were reviewed and analyze to meet with the requirements is the part two of the
standard.
The implementation of this guide was carried out in a company that has a specific area
to develop software and information systems and conducted a pilot project for the
development of an information system online using the processes defined from this guide.
v
CONTENIDO
CONTENIDO .............................................................................................................................. v
ÍNDICE DE TABLAS .............................................................................................................. vii
ÍNDICE DE FIGURAS ........................................................................................................... viii
ÍNDICE DE ANEXOS ............................................................................................................... ix
GLOSARIO Y ACRÓNIMOS .................................................................................................... x
INTRODUCCIÓN .................................................................................................................... xiv
CAPÍTULO 1 LA INDUSTRIA DEL SOFTWARE EN MÉXICO...................................... 1
1.1 Conceptos e historia de la Ingeniería de Software ........................................................ 1
1.2 Antecedentes de la Industria de Software ..................................................................... 6
1.3 Las Tecnologías de Información ................................................................................... 8
1.4 El Mercado del Software .............................................................................................. 9
1.5 Empresas que desarrollan Software ............................................................................ 10
CAPÍTULO 2 METODOLOGÍAS DE DESARROLLO DE SOFTWARE ....................... 13
2.1 Metodologías tradicionales ......................................................................................... 13
2.1.1 El modelo en cascada .......................................................................................... 15
2.1.2 El modelo de desarrollo evolutivo ....................................................................... 18
2.1.3 El modelo de construcción de prototipos ............................................................ 20
2.1.4 El modelo DRA ................................................................................................... 22
2.1.5 El modelo en espiral ............................................................................................ 24
2.1.6 El modelo incremental ......................................................................................... 27
2.1.7 El modelo de desarrollo basado en componentes ................................................ 30
2.1.8 El modelo de proceso unificado .......................................................................... 32
2.2 Métodos Ágiles ........................................................................................................... 36
2.2.1 El Manifiesto Ágil ............................................................................................... 37
2.2.2 Programación Extrema (Extreme Programming) ................................................ 40
2.2.3 Scrum ................................................................................................................... 47
2.2.4 Crystal .................................................................................................................. 53
2.2.5 Desarrollo dirigido por rasgos (Feature Driven Development) ........................... 54
2.2.6 Otros métodos ...................................................................................................... 57
vi
CAPÍTULO 3 MODELOS Y ESTÁNDARES DE CALIDAD DEL SOFTWARE ........... 61
3.1 Calidad del software ................................................................................................... 61
3.2 ISO 9000 ..................................................................................................................... 67
3.3 ISO/IEC 15504 ........................................................................................................... 68
3.4 SW-CMM ................................................................................................................... 70
3.5 CMMI ......................................................................................................................... 72
3.6 Otros modelos ............................................................................................................. 78
3.7 MoProSoft ................................................................................................................... 81
3.7.1 Estructura ............................................................................................................. 82
3.7.2 Roles .................................................................................................................... 86
3.7.3 Productos ............................................................................................................. 87
3.7.4 Normatividad de MoProSoft ............................................................................... 88
CAPÍTULO 4 PROPUESTA DE LA GUÍA ..................................................................... 101
4.1 Consideraciones previas ........................................................................................... 101
4.2 Administración de Proyectos Específicos ................................................................. 102
4.3 Desarrollo y Mantenimiento de Software ................................................................. 121
4.4 Implementación ........................................................................................................ 140
4.4.1 Implementación de los procesos ........................................................................ 140
4.4.2 Desarrollo de un proyecto piloto ....................................................................... 146
CONCLUSIONES ................................................................................................................... 148
REFERENCIAS ...................................................................................................................... 152
vii
ÍNDICE DE TABLAS
Tabla 1.1 Personas involucradas en la elaboración de software................................................ 11
Tabla 2.1 Actividades en el modelo en cascada ........................................................................ 16
Tabla 2.2 Regiones de tareas del modelo en espiral .................................................................. 25
Tabla 3.1 Elementos típicos del Proceso de Software ............................................................... 64
Tabla 3.2 Clasificación de los Modelos de Procesos................................................................. 66
Tabla 3.3 Modelo de Capacidad de Procesos ............................................................................ 69
Tabla 3.4 Niveles de Madurez de CMM ................................................................................... 71
Tabla 3.5 Niveles de Capacidad de CMMI ............................................................................... 73
Tabla 3.6 Áreas de Proceso de CMMI ...................................................................................... 75
Tabla 3.7 Categoría de procesos y Procesos de MoProSoft ...................................................... 83
Tabla 3.8 Roles de MoProSoft .................................................................................................. 86
Tabla 3.9 Productos ................................................................................................................... 87
Tabla 3.10 Procesos de MoProSoft ........................................................................................... 90
Tabla 3.11 Actividades de EvalProSoft ..................................................................................... 98
viii
ÍNDICE DE FIGURAS
Figura 2.1 Modelo en cascada ................................................................................................... 16
Figura 2.2 Modelo de desarrollo evolutivo ............................................................................... 19
Figura 2.3 Modelo de construcción de prototipos ..................................................................... 21
Figura 2.4 Modelo DRA ............................................................................................................ 23
Figura 2.5 El modelo en espiral ................................................................................................. 25
Figura 2.6 Modelo incremental ................................................................................................. 28
Figura 2.7 Modelo basado en componentes .............................................................................. 31
Figura 2.8 Fases de RUP ........................................................................................................... 35
Figura 2.9 Proceso de XP .......................................................................................................... 41
Figura 2.10 Proceso de Scrum ................................................................................................... 49
Figura 3.1 Proceso de Software ................................................................................................. 64
Figura 3.2 Niveles de Madurez con KPAs de CMM ................................................................. 72
Figura 3.3 Representación Continua de CMMI ........................................................................ 74
Figura 3.4 Representación Escalonada de CMMI ..................................................................... 75
Figura 3.5 Diagrama de Categoría de Procesos de MoProSoft ................................................. 85
Figura 3.6 Diagrama de Relación entre Procesos ...................................................................... 85
Figura 3.7 Clasificación General de Roles ................................................................................ 86
Figura 3.8 Configuración y Productos de Software .................................................................. 87
Figura 3.9 Clasificación general de productos .......................................................................... 88
Figura 3.10 Relación entre los elementos de EvalProSoft ........................................................ 97
Figura 4.1 Actividades de APE por Nivel de Capacidad ........................................................ 102
Figura 4.2 Actividades de DMS por Nivel de Capacidad ....................................................... 121
Figura 4.3 Diagrama del Proceso de Administración de Proyectos Específicos. .................... 142
Figura 4.4 Diagrama del Proceso de Desarrollo y Mantenimiento de Software ..................... 145
ix
ÍNDICE DE ANEXOS
Anexo 1 Formato de Visión de Producto ................................................................................ 157
Anexo 2 Formato de Product Backlog (Requisitos del Cliente) ............................................. 158
Anexo 3 Formato de Tarjeta de Producto ................................................................................ 159
Anexo 4 Formato de Arquitectura/Diseño de Alto Nivel ........................................................ 160
Anexo 5 Formato Sprint Backlog ............................................................................................ 161
Anexo 6 Formato de Tarjetas CRC ......................................................................................... 162
Anexo 7 Formato de Prueba de aceptación ............................................................................. 163
Anexo 8 Visión del Proyecto ................................................................................................... 164
Anexo 9 Product Backlog ........................................................................................................ 166
Anexo 10 Tarjetas de Producto ............................................................................................... 167
Anexo 11 Diseño de Alto Nivel/Arquitectura ......................................................................... 172
Anexo 12 Sprint Backlog ........................................................................................................ 175
Anexo 13 Tarjetas CRC ........................................................................................................... 180
Anexo 14 Pruebas de Aceptación ............................................................................................ 181
Anexo 15 Manual de Usuario .................................................................................................. 190
x
GLOSARIO Y ACRÓNIMOS
A
AM Agile Modeling
ASD Adaptative Software Development
B
Benchmarking Proceso sistemático y continuo para evaluar comparativamente los productos,
servicios y procesos de trabajo en las organizaciones.
Business
Monitor
Es una firma de análisis de eventos políticos, económicos, financieros,
empresariales que se dedica a realizar pronósticos anuales y trimestrales.
C
CANIETI Cámara Nacional de la Industria Electrónica, de Telecomunicaciones y de
Tecnologías de la Información.
Clúster Es un anglicismo muy utilizado en TI para referirse a grupo, segmento o
conglomeración.
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
Code And Fix Codifica y Corrige
Concurrencia Se refiere a la simultaneidad en la ejecución de múltiples tareas interactivas,
como procesos e hilos de ejecución.
COTS Commercial Off-The-Shelf
D
DRA Desarrollo Rápido de Aplicaciones
DSDM Dynamic System Develpment Method
E
EFQM European Foundation for Quality Management
Easel
Corporation
Empresa que en los macro-juegos de compras y fusiones se integraría en
VMARK, luego en Informix y finalmente en Ascential Software Corporation
ESI European Software Institute
EvalProSoft Evaluacion de Procesos de Software
F
xi
Fabrica de
Software
Empresa cuya misión es el desarrollo de software para sus clientes de acuerdo
a los requerimientos específicos que solicita.
FDD Feauture Driven Development
Framework En términos de desarrollo de software, es una estructura de soporte definida
en la cual otro proyecto de software puede ser organizado y desarrollado.
En términos generales, es un conjunto estandarizado de conceptos, prácticas y
criterios para enfocar un tipo de problemática particular, que sirve como
referencia para enfrentar y resolver nuevos problemas de índole similar.
G
Gartner Es un proyecto de investigación de tecnología de la información y de firma
consultiva con sede en Stamford, Connecticut, Estados Unidos.
H
Hacker Programador con grandes habilidades, experto en sistemas informáticos,
gurú.
I
IDE Integrated Development Environment
IEEE Institute of Electrical and Electronics Engineers
ISD Internet Speed Development
ISO International Organization for Standardization
ITIL IT Infraestructure Library
M
MDD Model Driven Development
MoProSoft Modelo de Procesos para el desarrollo de Software
N
NACCB National Accreditation Council for Certification Bodies
Nearshore Es el proceso de subcontratar o externalizar una actividad con salarios más
bajos que en el propio país.
NeoIT Desde octubre 2009 cambio su nombre a NeoAdvisor. Es una firma que
ayuda a la transformación organizacional mediante el aprovechamiento de la
globalización y el outsourcing.
Nielsen Es una empresa de información y medios a nivel global, holandés-
xii
Company estadounidense con sede en Nueva York.
O
OGC Office of Government Commerce
Outsourcing Tercerización, contratar servicios a terceros.
P
Plug-In Pequeño programa que añade alguna función a otro programa.
ProSoft Programa para el Desarrollo de la Industria del Software
PP Pragmatic Programming
PRM Performance Reference Mode
PSP Personal Software Process
R
Ingeniería
Round-Trip
Se refiere a la realización de cambios a través de herramientas.
RUP Rational Unified Process
S
SEI Software Engineering Institute
SOS Systems Of Systems
SWEDAC Swedish Board for Accreditation and Conformity Assessment
SwTQM Software Total Quality Management
T
TDD Test Driven Development
TI Tecnologías de la Información
TIC Tecnologías de la Información y Comunicación
TSP Team Software Process
U
UKAS United Kingdom Accreditation Service
UNE Unificación de Normas Españolas
UML Unified Modeling Language
V
VISA Visa es una empresa internacional de tecnología de pagos que permite a los
consumidores, empresas, instituciones financieras y gobiernos a utilizar la
xiii
moneda digital en lugar de efectivo y cheques.
X
XP Extreme Programming
xiv
INTRODUCCIÓN
Las tecnologías de información y comunicación han adquirido una gran importancia en los
últimos años debido a diferentes factores, entre los que destacan, los avances en las
telecomunicaciones, el uso y la dependencia de internet para realizar las actividades
relacionadas con la vida diaria y el trabajo, el desarrollo acelerado de nuevas computadoras
personales y la demanda de programas especializados o de propósito específico. Los factores
mencionados se encuentran asociados al desarrollo y uso de una tecnología creciente y
multifuncional, esta tecnología lleva por nombre, software. El software es un elemento dual,
es decir, es un producto y un servicio que debido a su gran dinamismo económico favorece la
creación de nuevas áreas de trabajo en las empresas y la creación de nuevas oportunidades de
empleo.
En nuestro país se cuenta con una reducida industria de software que se enfoca
principalmente al desarrollo de software a la medida. Por tal motivo, la Secretaria de
Economía de nuestro país publicó el Plan Nacional de Desarrollo 2001-2006, que en su rama
de desarrollo de la Industria del Software incluyó dentro de sus objetivos principales, colocar a
México en la cabeza de desarrollo de software en Latinoamérica para el año 2010 y así poder
aumentar la competitividad del país. Y gracias al potencial con el que cuenta México para
desarrollar esta industria, la Secretaria de Economía, en coordinación con organismos
empresariales y empresas del sector, diseñó el Programa para el Desarrollo de la Industria del
Software (ProSoft).
Dentro de las estrategias de este programa se encuentra una que es de gran
importancia, la cual tiene como objetivo, alcanzar niveles internacionales en capacidad de
procesos. Esta estrategia propone la definición de un modelo de procesos y de evaluación
apropiado para la industria mexicana de software. Este modelo propuesto tiene por nombre
MoProSoft, que significa Modelo de Procesos para el desarrollo de Software, y está dirigido a
la pequeña y mediana empresa y a las áreas internas de desarrollo de software. Su objetivo
principal es incorporar las mejores prácticas en la gestión de ingeniería de software. Esta
incorporación permitirá a la industria eventualmente elevar la capacidad de ofrecer productos
y servicios de software con calidad.
xv
MoProSoft tiene tres categorías de procesos, la primera es la Categoría de Alta
Dirección, la segunda es la Categoría de Gerencia y la tercera es la Categoría de Operación.
Ésta última está integrada por dos procesos, el primero de ellos es la Administración de
Proyectos Específicos y el segundo es el Desarrollo y Mantenimiento de Software. Esta
Categoría realiza las actividades de acuerdo a los elementos proporcionados por la Categoría
de Gerencia y entrega a ésta la información y productos generados.
Cabe mencionar que los procesos de la Categoría de Operación del Modelo MoProSoft
pueden ser implementados por diferentes modelos de desarrollo de software, como el modelo
espiral, secuencial, construcción de prototipos entre otros. Pero debido a los cambios que el
desarrollo de software ha sufrido en los últimos años, se ha propiciado la aparición de nuevas
metodologías de desarrollo de software más ligeras, a las cuales se les ha dado el nombre de
metodologías o métodos ágiles porque han dado lugar a que las actividades involucradas en el
desarrollo de software sean rápidas e incrementales. Estas metodologías de desarrollo tratan de
evadir los caminos burocráticos de las metodologías pesadas enfocándose más a la gente y a
los resultados que se esperan obtener.
Elegir las mejores prácticas para el desarrollo de software es un proceso difícil de
ejecutar, por lo tanto, podemos recurrir a los modelos de procesos como MoProSoft, que nos
van a guiar a elevar la capacidad de nuestras organizaciones para ofrecer productos con
calidad. Sin embargo, MoProSoft no establece que método de desarrollo de software se debe
implementar y tampoco dice como se debe desarrollar el software. Esto da lugar a que muchas
organizaciones adopten cualesquiera modelos tradicionales de desarrollo de software. Si las
organizaciones adoptan este modelo de procesos, éstas deben cumplir con los lineamientos
que tiene cada proceso de operación sí se está desarrollando software y por lo tanto, se debe
respetar los productos de entrada y los productos de salida.
Por consiguiente, este trabajo de investigación tiene como objetivo proponer una guía
para interpretar únicamente los procesos de la Categoría de Operación del modelo MoProSoft,
que abarcan la Administración de Proyectos Específicos y el Desarrollo y Mantenimiento de
Software, utilizando para ello una combinación de los Métodos Ágiles más utilizados para el
desarrollo de software y la administración de proyectos de acuerdo a los estudios de Scott
Ambler.
xvi
En el primer capítulo se expone la situación de nuestro país con respecto a la industria
del software, así como también los antecedentes de la ingeniería de software, su historia y el
comportamiento del mercado exclusivamente para el software.
En el segundo capítulo se tratan a detalle los modelos tradicionales de procesos para el
desarrollo de software, como el modelo en espiral, el modelo en cascada, entre otros. Así
como también las metodologías que están tomando gran importancia y popularidad alrededor
del mundo, las cuales son llamadas Ágiles.
En el tercer capítulo se muestran aspectos relacionados con los modelos de procesos
que ayudan al desarrollo de software con calidad, sus definiciones y los distintos modelos que
existen actualmente en el mercado mundial, incluyendo el modelo MoProSoft, el cual es parte
importante en esta investigación.
El cuarto capítulo expone la propuesta de la guía para interpretar únicamente los
procesos de la Categoría de Operación de MoProSoft, los cuales son, la Administración de
Proyectos Específicos y el Desarrollo y Mantenimiento de Software. Además presenta también
su implementación en el desarrollo de un proyecto para una empresa pública descentralizada
cuyo objetivo es prestar el servicio público de energía eléctrica en la zona centro del país, y
que necesita desarrollar aplicaciones y sistemas de información para las tareas administrativas,
técnicas y operativas donde los trabajadores están involucrados de manera permanente.
1
CAPÍTULO 1 LA INDUSTRIA DEL SOFTWARE EN MÉXICO
México cuenta con una industria de software muy moderada que se enfoca principalmente al
desarrollo de software personalizado, es decir, se desarrolla de acuerdo a una serie de
especificaciones y requerimientos que el cliente expide para satisfacer ciertas necesidades.
Esto propicia a que las organizaciones cuenten con su propio departamento de sistemas, el
cual, es el encargado de desarrollar este tipo de software.
En este capítulo se muestra el comportamiento que nuestro país ha tenido en los últimos
años y las tendencias que los indicadores muestran en relación con las tecnologías de
información y comunicación, en especial, sobre el desarrollo de software.
1.1 Conceptos e historia de la Ingeniería de Software
Las computadoras y los programas de software están transformando a la sociedad moderna.
Hoy en día el software se ha convertido en el alma mater, es la máquina que conduce a la toma
de decisiones comerciales, sirve como base para la investigación científica y de resolución de
problemas de ingeniería, además es el factor clave que diferencia los productos y servicios
actuales, es decir, está contenido en sistemas de todo tipo, por ejemplo: en los medios de
transporte, los servicios médicos, de telecomunicaciones, sistemas militares, procesos
industriales, entretenimiento, productos de oficina, y otros mas, y en la mayoría de estos
ejemplos, las personas encomiendan su trabajo, bienestar social, su seguridad, entretenimiento
e incluso sus propias vidas en manos del software1.
Esto hace que las actividades relacionadas con los servicios en esta sociedad moderna
estén creciendo de manera muy importante. El software está tomando un rol preponderante y
cada vez más y más organizaciones dependen de los procesos de procesamiento de datos y de
las capacidades del personal más altamente calificado para utilizar y dominar las diferentes
herramientas de software que hay en el mercado actual2.
Antes de revisar la situación actual de nuestro país con respecto al desarrollo de
software y de estudiar un breve resumen de la historia de la ingeniería de software, es
1 Pressman, R. 1998. Ingeniería de Software. Un Enfoque Práctico: Mc Graw Hill. 2 Oktaba, H. and M. Piattini. 2008. Software Process Improvement for Small and Medium Enterprises:
Techniques and Case Studies: Information Science Reference.
2
importante tener claro el concepto de software. En primera instancia, el software son los
programas de computadora y la documentación asociada a él, así como la configuración de
datos que se necesitan para hacer que estos programas operen de manera correcta. Los
productos de software se pueden desarrollar para algún cliente en particular o para un mercado
en general.
Por otro lado, la ingeniería de software es una disciplina o rama de la ingeniería que
comprende todos los aspectos de la producción de software. A diferencia de las ciencias de la
computación, la cual comprende la teoría y los fundamentos, la ingeniería de software
comprende las formas prácticas para desarrollar y entregar un software de utilidad. Y a
diferencia de la ingeniería de sistemas, la cual se refiere a todos los aspectos del desarrollo de
sistemas informáticos, incluyendo hardware, software e ingeniería de procesos, la ingeniería
de software es parte de este proceso3.
Gracias a la ingeniería de software, existen en nuestros días, métodos y técnicas para
desarrollar y mantener el software de calidad de todo tipo y que día con día es cada vez más
frecuente la consideración de la ingeniería del software como una nueva rama de la
ingeniería4.
A finales de los sesentas se identificó al desarrollo de software como una actividad
caótica en la construcción de grandes sistemas, por esta razón, nació el término “crisis de
software”, que describía esta situación, y se acordó la necesidad de establecer procesos de
ingeniería para el desarrollo de software. Fue la primera vez que se habló de la Ingeniería de
Software5.
Para entrar más a detalle acerca de esta nueva rama de la ingeniería, La Dra. Hanna
Oktaba6 hace un recuento de su historia, que abarca desde los años cincuentas hasta nuestra
época actual y menciona los factores que posiblemente afecten en un futuro la forma de
desarrollar el software.
Años cincuentas.- Se aplica el mismo proceso de desarrollo tanto en software como en hardware, es un tipo cascada rigurosa. 3 Sommerville, L. 2005. Ingeniería del Software:5: Pearson. 4 IEEE. 1993. Standars Collection: Software Engineering. no. IEEE Standard 610.12-1990. 5 Palacio, J. 2008. Flexibilidad con Scrum: safeCreative. 6 Oktaba, H. 2006. Historia y Futuro de la Ingeniería de Software. Revista Software Gurú, México.
3
Lo que si se debe hacer Lo que no se debe hacer
§ Se debe usar el método científico para
aprender a través de la experiencia.
§ No comprometerse mucho antes de
entender la complejidad de un proyecto
§ Seguir de forma muy rigurosa el proceso
de desarrollo secuencial.
§ Ignorar las matemáticas, las ciencias de
la computación, las ciencias sociales,
económicas y administrativas.
Años sesentas.- El desarrollo de software es una tarea artesanal. Las propiedades de
software, tales como: fácil de modificar, fácil de copiar, no se gasta, es invisible, fomentaron
el proceso de desarrollo tipo codifica y corrige (code and fix). Se inició la cultura del hacker,
es decir, experto en programación, y la del vaquero (cowboy) que hace desarrollos heroicos de
última hora.
Lo que si se debe hacer Lo que no se debe hacer
§ Atreverse a hacer prototipos novedosos
y no limitarse a repetir lo que ya se
conoce.
§ Respetar que el software es diferente. No
se puede incrementar la velocidad de su
desarrollo de manera infinita.
§ Programación al estilo vaquero. Parches
de último minuto o trabajo de última
noche pueden traer consigo
consecuencias muy graves.
Años setentas.- Se identifican las diferentes etapas del desarrollo: requerimientos,
análisis, diseño, codificación y pruebas. Se introduce la programación estructurada y métodos
formales para especificar software. Se identifican principios de diseño, como modularidad,
encapsulación, abstracción de tipos de datos, acoplamiento débil y alta cohesión, entre otros.
Se publica el modelo de cascada y se definen los conceptos de verificación y validación.
Lo que si se debe hacer Lo que no se debe hacer
§ Eliminación temprana de defectos y su
prevención a través del análisis de
causas.
§ Determinación temprana del propósito
de sistema para tener una visión
compartida con el cliente.
§ Desarrollo descendente a toda costa
(top-down). Los requerimientos
emergentes y los cambios lo hacen poco
realista, para la mayoría de los casos.
4
Años ochentas.-Se busca la productividad y escalabilidad de sistemas y equipos de
desarrollo. La Orientación a Objetos renace con fuerza a través de las múltiples propuestas de
lenguajes de programación. Se crea el primer modelo de madurez de capacidades de procesos
llamado CMM (Capability Maturity Model) y los primeros estándares. Nace el concepto de
Fábricas de Software y se generan las primeras herramientas para incrementar la productividad
a través de la programación por el usuario.
Lo que si se debe hacer Lo que no se debe hacer
§ Existen muchos caminos para
incrementar la productividad, estos
caminos incluyen la selección del
personal, capacitación, herramientas,
reutilización, mejora de procesos, etc.
§ Lo que es bueno para el producto es
bueno para el proceso, por ejemplo:
arquitectura, composición y adaptación.
§ Creer que hay una solución mágica que
se puede aplicar para resolver cualquier
clase de problemas.
Años noventas.-La concurrencia adquiere mayor importancia con respecto a procesos
secuenciales. La Orientación a Objetos se extiende a las fases de análisis y diseño. Se acuerda
la creación del Lenguaje de Modelado Unificado (UML) y se genera el primer proceso
comercial de desarrollo orientado a objetos llamado Rational Unified Process (RUP). Los
diseñadores y los arquitectos de software empiezan a recaudar las mejores experiencias a
través de patrones de diseño y de arquitectura. Se define el Modelo Espiral para el desarrollo
basado en el análisis de riesgos y su vertiente conocida como desarrollo iterativo e
incremental. El Software Libre toma fuerza y se crean los primeros ejemplos exitosos. La
usabilidad de sistemas se convierte en el foco de atención e investigación. El Software
empieza a ocupar la posición crítica en el mercado competitivo y en la sociedad web.
Lo que si se debe hacer Lo que no se debe hacer
§ El tiempo es dinero. La gente invierte en
software esperando retorno de inversión,
mientras más rápido se desarrolle el
software, más rápido se recupera la
inversión, pero eso sólo pasa en el caso
§ Hacer las cosas demasiado rápido. Los
productos muy ambiciosos a menudo
traen como consecuencia las
especificaciones incompletas, que
resultan en mucho re-trabajo.
5
cuando el software tiene calidad.
§ El software tiene que ser útil para la
gente, es la parte crucial de la definición
de Ingeniería.
Actualidad.-Los temas nuevos son la agilidad en el desarrollo y el valor para el
cliente. Se redacta el Manifiesto Ágil en respuesta al estilo promovido por CMM. Surgen los
dispositivos móviles y las agendas electrónicas que involucran el ciclo: Aprendizaje-
Seguridad-Mejorar su uso. Las cualidades prioritarias de sistemas son: Seguridad/Privacidad,
Usabilidad y Confiabilidad. Se incrementa la propagación de software empaquetado COTS
(Commercial Off The Shelf). Crece el entendimiento de las bondades del código abierto. El
desarrollo dirigido por modelos (MDD, Model Driven Development) toma fuerza. Se integra
el proceso de desarrollo de software con el de sistemas.
Lo que si se debe hacer Lo que no se debe hacer
§ Cuando los cambios son frecuentes la
adaptabilidad del proceso debe ser más
importante que la repetición.
§ Primero hay que considerar y satisfacer
los asuntos que son de valor para el
cliente.
§ Enamorarse de tus propios lemas. Decir
al cliente “no lo vas a necesitar”, no
siempre es cierto.
Perspectivas para el 2010 - 2020.-Las tendencias que van a afectar, en el futuro
próximo, la forma de desarrollar software son las siguientes:
Globalización. La conectividad global proporcionada por el Internet y las
comunicaciones de banda ancha causará la evolución de las principales economías hacia redes
de economías. En consecuencia, se requerirá de nuevos procesos de desarrollo para la
colaboración global exitosa. Los retos claves serán: la colaboración multicultural, lograr las
visiones compartidas y la confianza, definir mecanismos de contratación, incentivos, entregas
y la sincronización de cambios, que aprovechen múltiples zonas horarias.
Algunos problemas relacionados con diferencias culturales fueron identificados en un estudio
sobre la adopción de procesos. Por ejemplo, SW-CMM que proviene de la cultura
Individualista/Masculina/Corto plazo tuvo muy baja aceptación en la cultura de Tailandia que
es Colectiva/Feminista/Largo plazo.
6
Sistemas de sistemas. La habilidad de las organizaciones de competir, adaptarse y
sobrevivir en el mercado y en la sociedad globalizada va a depender, en gran medida, de su
habilidad para integrar sistemas de software en sistemas de sistemas (Systems Of Systems -
SOS). Un SOS integra múltiples sistemas desarrollados independientemente y se caracteriza
por su gran tamaño. Los retos para el desarrollo de SOS son: lograr acuerdos a tiempo con
diversos involucrados, resolver rápido los conflictos en los requerimientos y coordinar
actividades de múltiples proveedores.
Abundancia computacional. La Ley de Moore seguirá vigente al menos durante los
próximos veinte años. Con esto, se va a tener una abundancia de aparatos pequeños pero con
gran poder de procesamiento. La Ingeniería de Software tendrá que enfrentarse con los
problemas de cómo manejar el desarrollo para esta abundancia computacional, y finalmente,
como integrar estos dispositivos a los SOS. Esto va a requerir de nuevos niveles de abstracción
para la programación y nuevas herramientas con mayor poder basado en el uso del
conocimiento.
Autonomía computacional. Es una visión en la cual la Inteligencia Artificial alcanza
plenamente sus objetivos. Las máquinas se vuelven autónomas, evalúan las situaciones y
determinan la mejor opción para actuar.
Combinación de biología y computación. Aquí habrá una influencia mutua. La
computación basada en biología utiliza fenómenos moleculares o biológicos para resolver
problemas computacionales. Mientras que la biología computacional tratará de mejorar las
capacidades humanas, incorporando dispositivos al cuerpo humano.
1.2 Antecedentes de la Industria de Software
México tiene un nivel de gasto en tecnologías de la información y comunicaciones (TIC) de
3.2% del PIB, ubicándose en el lugar 50 a nivel mundial, este rezago es aún mayor en
términos de gasto en software, que es 6 veces inferior al promedio mundial y 9 veces menor
que el de Estados Unidos. En países como la India, Irlanda y Singapur han sido exitosos en
desarrollar su industria de software como motor de su crecimiento económico. México cuenta
con un gran potencial para desarrollar esta industria dada su cercanía geográfica con el
7
mercado de software más grande del mundo que es Estados Unidos, la red de tratados
comerciales más extensa de mundo y afinidad con la cultura de negocios occidental7.
El Plan Nacional de Desarrollo 2001-2006 planteó la estrategia de impulsar el
desarrollo de la industria de tecnologías de información, así como fomentar y difundir la
industria de desarrollo de software. Derivado de este mandato la Secretaría de Economía lanzó
el Programa para el Desarrollo de la Industria de Software (ProSoft) como un programa
prioritario incluido dentro de la Política Económica para la Competitividad del Gobierno
Federal por el efecto transversal de las tecnologías de información en la competitividad de
todas las empresas y sectores.
El ProSoft tiene como una estrategia desarrollar el mercado interno de tecnologías de
información. Actualmente, la demanda se concentra principalmente en el Gobierno Federal,
las instituciones de educación superior, el sector financiero, las industrias electrónica,
automotriz y de bienes de consumo, las tiendas departamentales y de autoservicio y las
grandes empresas de servicios.
En la mayoría de los casos son las grandes empresas públicas, privadas y corporativas
quienes invierten en software y servicios, ya sea a través de la adquisición o subcontratación
de proveedores externos o mediante departamentos de sistemas dirigidos a desarrollar y
proporcionar internamente el software y los servicios necesarios para su administración y
operación. Por su gran capacidad de compra y el elevado volumen de autoconsumo, estos
sectores representan un importante mercado para la industria local de software y servicios
relacionados. Un factor fundamental para lograr que las empresas de software y servicios se
conviertan en proveedores de las grandes empresas públicas y privadas es conocer cuáles son
las capacidades de sus departamentos internos de sistemas, cuáles son sus demandas y cómo
las están satisfaciendo, ya sea mediante desarrollo interno u oferta externa, y cómo se toma la
decisión entre ambas alternativas a fin de que puedan desarrollar estrategias para atacar esas
oportunidades de negocio.
7 Economía, S. d. Programa para el Desarrollo de la Industria del Software (PROSOFT).
http://www.economia.gob.mx/?P=1128&NLanguage=es.
8
1.3 Las Tecnologías de Información
La aparición de las Tecnologías de Información y su rápida evolución, cuyo aprovechamiento
se ha dado en mayor medida en los países desarrollados, ha provocado un importante
crecimiento de la productividad en prácticamente todos los sectores económicos. Un estudio
del Banco Mundial con base en empresas de 56 países en desarrollo, concluye que las
compañías que utilizan las TI crecen más rápido, invierten más, y son más productivas y más
rentables que las que no las usan.
De acuerdo con estudio realizado por VISA y Nielsen Company, las pequeñas y
medianas empresas mexicanas son las menos tecnológicas de Latinoamérica. De las empresas
encuestadas, más del 50% declara tener un teléfono celular para su empresa, el 40% utiliza su
computadora para usos empresariales, sólo el 25% utiliza Internet y es para buscar
información, no para realizar negocios online, el 7% busca proveedores en internet, el 8%
anuncia su negocio y solo el 4% usa el internet para hacer sus compras y pedidos a sus
proveedores. Información reciente apunta que estas empresas no hacen uso eficiente de las
tecnologías disponibles, lo que provoca que la brecha digital se amplíe cada vez mas frente a
las grandes empresas, causando un deterioro en su competitividad. Además, destaca también
que sólo el 10% de las pequeñas y medianas empresas en México tiene página web8.
Para impulsar el crecimiento de TI en México, existen programas apoyados por
ProSoft, uno de los más importantes es el MéxicoIT. Este es un programa de promoción de la
iniciativa privada de Tecnologías de Información de México, cuyo objetivo es impulsar el
crecimiento de esta industria, así como promover, fortalecer y posicionar su presencia en el
mercado internacional. El programa es ejecutado por la Cámara Nacional de la Industria
Electrónica, de Telecomunicaciones y de Tecnologías de la Información (CANIETI). Las
estrategias del programa se dirigen al mercado global, pero hay un especial interés en el
mercado de Estados Unidos, gracias a su gran demanda en servicios de IT. De igual manera
MéxicoIT promueve la alternativa “nearshore” (proceso de subcontratar o externalizar una
actividad con salarios más bajos que en el propio país), aprovechando la cercanía geográfica
que nuestro país tiene con EU.
8 VISA and N. Company. 2008. Perspectivas de las Pymes en México.
9
MéxicoIT ha creado una estrategia de comunicación integral de mercadotecnia y
relaciones públicas en Estados Unidos, para dar a conocer las capacidades del país como
destino. La idea es que con ello, las empresas afiliadas a MéxicoIT entren en el radar de
analistas como Gartner, IDC, NeoIT, entre otros. MéxicoIT planea tener un representante
permanente en Estados Unidos para seguir generando leads. Otro objetivo del programa es
presentar a México como un país atractivo para la inversión extranjera, propiciando así la
creación de empresas de TI. Actualmente, hay más de 12 empresas que aprovechan los
servicios del programa, pero existen más de 150 empresas mexicanas que tienen potencial para
exportar. Un reporte de la consultora AT Kearney posicionó a México en el lugar 11, de entre
los 50 países del mundo con mejores ofertas en servicios de outsourcing de TI. En el reporte
de 2009 de Gartner, se proyecta que para 2013 México va a ser el segundo país proveedor de
servicios IT en el mundo, sólo detrás de la India9.
Además de MéxicoIT, la Secretaría de Economía dio a conocer la iniciativa México
First, la cual es respaldada por el Banco Mundial. Esta iniciativa tiene por objetivo desarrollar
suficiente capital humano especializado en el sector de TI en el país. El Banco Mundial
estableció un convenio con la Secretaría de Economía por 80 millones de dólares. De esa cifra
se destinarán 27 millones de dólares en los próximos 5 años para México First, ya que
actualmente pocos desarrolladores están certificados y se requiere contar con 60 mil
certificaciones hacia 2013 por lo que la meta es certificar aproximadamente a 12 mil personas
al año. Hay que recalcar que según MéxicoIT, en nuestro país existen casi 600 mil
profesionistas en la industria de TI, incluyendo aproximadamente 400 mil profesionistas
especializados en software. Además, cada año se gradúan 65 mil nuevos profesionistas
especializados en el sector.
Business Monitor estima que el mercado del sector de TI alcanzará 10 mil 195 millones
de dólares en 2013 por lo que crecerá 10 por ciento anual en el periodo 2009-201310.
1.4 El Mercado del Software
Apoyada en empresas que demandan más tecnología, la industria del software en México
aumentó su producción 42% en los últimos cinco años al pasar de 2 mil 358 a 3 mil 600
9 Editorial, E. 2010. MexicoIT. Software Guru. 10 Servicios de TI y Software. http://www.promexico.gob.mx/wb/Promexico/servicios.
10
millones de dólares. De acuerdo con un balance de la Comisión de Economía de la Cámara de
Diputados, este sector es uno de los que mejor han sobrellevado la crisis económica, lo que le
permitió generar, en ese lapso, más de 30 mil empleos directos de alta remuneración y
rentabilidad.
Rodrigo Pérez Alonso, secretario de la Comisión de Economía de la Cámara, dijo que
ese crecimiento de las tecnologías de la información permite que un mayor número de
empresas de todos los tamaños, estén en abierta posibilidad de incrementar su competitividad
sumándose a las cadenas productivas. Apuntó que en apoyo a ese desarrollo de las empresas
en México, se acordó ampliar en más de 70% los recursos al Programa para el Desarrollo de la
Industria del Software (ProSoft) y de 388.3 millones aprobados originalmente, se ejercerán en
el 2010 688.3 millones de pesos. Estableció que con esa aportación adicional de recursos a la
investigación y desarrollo tecnológico se verán beneficiadas las micro y pequeñas empresas
que podrán acceder a las nuevas tecnologías con paquetes diseñados a sus necesidades.
Pérez Alonso11 recordó que todavía en el 2002 no se contaba con clústers de TI,
integradoras de TI, parques tecnológicos e instituciones educativas vinculadas a este sector,
mientras que en este año ya se tienen en conjunto con la iniciativa privada y el gobierno, 24
parques tecnológicos a lo largo del país, 23 clusters de TI distribuidos en 20 estados. Más del
60 por ciento de los estados cuentan con capacidad productiva en TI. El gran tamaño de
México permite que varias ciudades se constituyan en centros proveedores de servicios, lo
cual le otorga a México una ventaja sobre otros países que dependen de la disponibilidad de
fuerza laboral concentrada en una sola ciudad.
Además, Business Monitor estima que el mercado del software alcanzará 10 mil 195
millones de dólares en 2013, lo que estima que el mercado de software en México crecerá 9
por ciento anual en el periodo 2009-201312.
1.5 Empresas que desarrollan Software
De una encuesta realizada en México a 114 empresas que desarrollan software, el 55%
desarrolla software a la medida, seguidas por el 33% cuyo giro no es específicamente el
11 SIPSE. Subió 42% la industria del software en México. http://www.sipse.com/noticias/imprimir?21013. 12 Servicios de TI y Software. http://www.promexico.gob.mx/wb/Promexico/servicios.
11
software pero lo desarrollan y adquieren, y finalmente 12% que pertenecen al giro de
desarrollo de software empaquetado.
Con base en estos resultados se establece que alrededor del 88% de las empresas de
software en México (+- 10%) lo desarrolla de acuerdo con las especificaciones del cliente
(requerimientos de software) y sólo el 12% restante desarrolla software para un mercado
conocido13.
Como se aprecia en la tabla 1.1, el número de personas involucradas en la elaboración
de software es muy pequeño, ya que más de un tercio de las empresas encuestadas cuentan con
menos de cinco personas para la realización de software.
Tabla 1.1 Personas involucradas en la elaboración de software
Número de personas % de Empresas
Menos de 5 36%
6 a 10 28%
11 a 20 15%
Más de 20 21%
Elaboración con fuente de: Gasca, Edna Gutiérrez and Agustín Francisco Gutiérrez. 2008.
Acerca de la implementación de los modelos de calidad en la construcción de software en
México. Revista Digital Universitaria 9, no. 9.
El resultado muestra que son pocos los recursos humanos asignados por las empresas
para la ejecución del proceso de desarrollo y mantenimiento de software. Según MoProSoft,
este proceso requiere de al menos nueve roles diferentes. Esto provoca que las personas
desempeñen distintos roles, lo cual se traduce en documentación incompleta y la
concentración en actividades operativas, como la codificación del producto para cumplir con
los requerimientos del cliente.
Por otra parte, la investigación también muestra que 71% de las empresas utilizan un
proceso o metodología, mientras que el 29% restante considera al desarrollo de software como
un proceso creativo que no puede ajustarse a una metodología. Al ampliar la respuesta
definiendo cuál metodología utilizan, aparecen en primer lugar las metodologías propias,
13 Gasca, E. G. and A. F. Gutiérrez. 2008. Acerca de la implementación de los modelos de calidad en la
construcción de software en México. Revista Digital Universitaria 9, no. 9.
12
seguido de las metodologías ágiles entre las que destacaron XP, SCRUM y metodología en
espiral, y en tercer lugar los modelos y normas de calidad, tal como: CMMI e ISO 9000.
La investigación también muestra que el 53% de las empresas que participaron en la
encuesta, consideran que la documentación generada por ellos no es de calidad. Esto está
referido a que sólo se documenta el manual de usuario por falta de recursos humanos
especializados, y por considerar a la documentación como elemento accesorio y no como la
evidencia de la realización de un proceso, ejecutándose una vez terminado el producto
software. Algunas empresas incluso, carecen de documentación, por considerar que sus
productos son pequeños. Finalmente, las que sí cuentan con ella argumentan que los
documentos generados en el proceso están desfasados contra la funcionalidad implantada en el
producto.
Resalta también el alto porcentaje de empresas que no utilizan algún modelo. Se
descubrió que el 86% de las empresas encuestadas ha considerado utilizar un modelo de
aseguramiento de calidad de software, es sólo que en el momento de la encuesta no lo había
logrado implementar. Entre este grupo, 44% se inclina por MoProSoft como opción, 26% por
CMMI y el resto no refiere modelos14.
Finalmente, hay que destacar el número de empresas que han logrado la verificación en
MoProSoft, la cual iba en aumento hasta el 2008 y declinó en el 2009. En el año 2006 se
verificaron 5 empresas, en el año 2007 se verificaron 7, en el año 2008 se verificaron 104 y en
el año 2009 se verificaron 6715. En el logro de estas verificaciones el programa ProSoft ha
tenido mucho que ver, es decir, en el año 2007 apoyo a 1 empresa, en el año 2008 a 6
empresas16.
14 Gutiérrez, E. 2009. Implementación de modelos de calidad. Software Guru. 15 NYCE, G. 2010. MoProSoft - Un modelo de éxito. Gaceta NYCE 1. 16 Evaluación de impacto del programa para el desarrollo de la industria del software (PROSOFT). 2009.
Secretaría de Economía.
13
CAPÍTULO 2 METODOLOGÍAS DE DESARROLLO DE SOFTWARE
Debido a la gran necesidad de que los proyectos de desarrollo de software tengan éxito y a la
necesidad de obtener un producto de gran valor para los clientes, se han generado grandes
cambios en las metodologías adoptadas por los equipos de desarrollo para cumplir sus
objetivos, ya que unas se adaptan mejor que otras al contexto del proyecto, brindando así
mejores ventajas.
Es por ello de la importancia de contar con una metodología robusta que ajustada en un
equipo de desarrollo cumpla con sus metas, y satisfaga mas allá de las necesidades definidas al
inicio del proyecto de desarrollo de software.
El que un producto tenga éxito depende en gran parte de la metodología que el equipo
de desarrollo seleccione, ya sea una metodología tradicional o una metodología ágil, donde los
equipos maximicen su potencial, aumenten la calidad del producto con los recursos y tiempos
establecidos17.
En este capítulo se describen las metodologías tradicionales que se han utilizado en las
últimas décadas para el desarrollo de software y las nuevas metodologías que han surgido en
los últimos años y que se han caracterizado por denominarse metodologías ligeras o métodos
ágiles.
2.1 Metodologías tradicionales
Al inicio desarrollar software era una actividad artesanal en su totalidad, la fuerte necesidad de
mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la
concepción y fundamentos de metodologías existentes en otras áreas y adaptarlas al desarrollo
de software. Esta nueva etapa de adaptación contenía el desarrollo dividido en etapas de
manera secuencial que de gran manera mejoraba la necesidad latente en el campo del
software18.
17 Figueroa, R. G., C. J. Solís, and A. A. Cabrera. 2006. Metodologías tradicionales versus metodologías ágiles.
Universidad Técnica Particular de Loja. 18 Figueroa, R. G., C. J. Solís, and A. A. Cabrera. 2006. Metodologías tradicionales versus metodologías ágiles.
Universidad Técnica Particular de Loja.
14
En primera instancia, un proceso de software es un modelo que describe un enfoque
encaminado hacia la producción y evolución del software. Estos modelos son con frecuencia
llamados modelos de ciclos de vida. Al igual que como cualquier otro, un modelo de procesos
es una abstracción, pero en este caso el modelo describe el proceso de traslación, de un
concepto de un sistema a la especificación de requerimientos, después al diseño y después al
código para terminar finalmente en un proceso de compilación y ensamblado almacenados en
un programa.
Un buen modelo de procesos ayudará a minimizar los problemas asociados con cada
translación. Un proceso de software también proporciona un marco de desarrollo de software
común, tanto dentro de un proyecto o varios proyectos. El proceso permite la mejora de la
productividad y proporciona una cultura común, un lenguaje común y habilidades comunes
entre los miembros de la organización. Estos beneficios fomentan un alto nivel de trazabilidad
y comunicación eficaz a lo largo del proyecto. De hecho es muy difícil aplicar los principios
de administración de proyectos correctos cuando un modelo de procesos no está en su lugar19.
Por otra parte, una metodología de desarrollo de software es todo lo que se hace
regularmente para obtener un producto de software20. Una metodología describe el “cómo”, es
decir, identifica el cómo realizar las actividades que están involucradas en un ciclo de
desarrollo de software, el cómo representar esas actividades y productos que se obtienen y el
cómo generar esos productos21. Además de incluir también al personal que se contrata, los
recursos que se contratan o rentan para que ese personal realice sus actividades, el cómo
trabaja ese personal de forma conjunta, lo que ellos producen y como colaboran entre ellos
para producir ese producto22.
19 Laplante, P. A. 2007. What every engineer should know about software engineering:23-24: CRC Press. 20 Cockburn, A. 2006. Agile Software Development: The Cooperative Game (Agile Software Development
Series). 21 Laplante, P. A. 2007. What every engineer should know about software engineering:23-24: CRC Press. 22 Cockburn, A. 2006. Agile Software Development: The Cooperative Game (Agile Software Development
Series).
15
Las metodologías tradicionales o también llamadas metodologías formales, se enfocan
principalmente en documentación, planificación y procesos, es decir, plantillas, técnicas de
administración, revisiones, y otros documentos formales23.
En general las metodologías llevan a cabo una serie de procesos comunes que son
buenas prácticas para lograr sus objetivos independientemente de cómo hayan sido diseñadas.
La mayoría de las fases que agrupan estos procesos son las siguientes:
§ Análisis
§ Especificación
§ Diseño
§ Programación
§ Prueba
§ Documentación
§ Mantenimiento
§ Reingeniería
Asimismo las diferentes metodologías tienen diversos ciclos de vida del desarrollo de
software, los modelos más comúnmente utilizados son los siguientes:
§ El modelo en cascada
§ El modelo de desarrollo evolutivo
§ El modelo de construcción de prototipos
§ El modelo DRA (Desarrollo Rápido de Aplicaciones)
§ El modelo en espiral
§ El modelo incremental
§ El modelo de desarrollo basado en componentes
§ El modelo de proceso unificado
2.1.1 El modelo en cascada
Los términos cascada, convencional y lineal secuencial son usados para describir un modelo
secuencial de no superposición y actividades distintivas relacionadas al desarrollo de software.
Colectivamente los periodos en los cuales esas actividades ocurren son a menudo conocidas
23 Figueroa, R. G., C. J. Solís, and A. A. Cabrera. 2006. Metodologías tradicionales versus metodologías ágiles.
Universidad Técnica Particular de Loja.
16
como fases o etapas. Si bien, este modelo es muy simplista y se remonta por lo menos 30 años,
hoy en nuestros días este modelo es muy popular.
El número de fases o etapas usadas en este modelo difiere entre sus diferentes
variantes. Por ejemplo, el desarrollo de cierto producto de software conlleva a realizar varias
actividades que contemplan la siguiente secuencia:
Concepción
Especificación de requerimientos
Especificación de diseño
Desarrollo de código
Pruebas
Mantenimiento
La representación en cascada de esta secuencia se muestra en la figura 2.1.
Concepción
Requerimientos
Diseño
Código
Pruebas
Mantenimiento
Figura 2.1 Modelo en cascada24
La tabla 2.1 resume las actividades en cada periodo y los productos de salida de esas
actividades25.
Tabla 2.1 Actividades en el modelo en cascada
Fase Actividad Salida
24 Elaboración con fuente de: Laplante, P. A. 2007. What every engineer should know about software
engineering: CRC Press. 25 Laplante, P. A. 2007. What every engineer should know about software engineering:25: CRC Press.
17
Concepción Define las metas del
proyecto
Papel blanco
Requerimientos Decide que es lo que el
software debe hacer
Especificación de
requerimientos de software
Diseño Muestra como el software
va a satisfacer los
requerimientos
Descripción del diseño de
software
Desarrollo Construye el sistema Código del programa
Pruebas Demuestra la satisfacción
de los requerimientos
Reportes de las pruebas
Mantenimiento Sistema de mantenimiento Reportes de peticiones de
cambios
Elaboración con fuente de: Laplante, Phillip A. 2007. What every engineer should know about
software engineering:25: CRC Press.
En principio, el resultado de cada fase es uno o más documentos aprobados. La
siguiente fase no debe empezar hasta que la fase previa haya finalizado en la práctica, estas
etapas se superponen y proporcionan más información que las otras. Durante el diseño se
identifican los problemas con requerimientos; durante el diseño del código se encuentran
problemas, y así sucesivamente. El proceso del software no es un modelo lineal simple, si no
que implica una serie de interacciones de las actividades de desarrollo. Debido a los costos de
producción y aprobación de documentos, las iteraciones son costosas e implican rehacer el
trabajo. Por lo tanto, después de un número reducido de interacciones, es normal congelar
partes del desarrollo, como la especificación y continuar con las siguientes etapas. Los
problemas se posponen para su resolución, se pasan por alto o se programan. Este
congelamiento prematuro de requerimientos puede implicar que el sistema no haga lo que el
usuario desea. También puede conducir a sistemas mal estructurados debido a que los
problemas de diseño se resuelven mediante parches al momento de su implementación.
Durante la fase final del ciclo de vida, el software se pone en funcionamiento, se descubre
errores y omisiones en los requerimientos originales del software. Los errores de
programación y de diseño emergen y se identifica la necesidad de una nueva funcionalidad.
18
Por lo tanto el sistema debe evolucionar para mantenerse útil. Hacer estos cambios puede
implicar repetir etapas previas del proceso.
Las ventajas de este modelo son que la documentación se produce en cada fase y que
ésta armoniza con otros modelos del proceso de ingeniería26.
El modelo en cascada o lineal secuencial es el más utilizado y el más antiguo en la
ingeniería de software. Sin embargo, las críticas que ha recibido este modelo han hecho que
sea dudosa su eficiencia. Entre los problemas en los que se ve envuelto este modelo son:
1. Los proyectos reales difícilmente se apegan a la forma secuencial que propone el
modelo. Aunque el modelo en cascada puede acoplar la interacción, lo hace de forma
indirecta. Lo que provoca que los cambios causen confusión en el equipo de desarrollo.
2. Casi siempre es difícil que los clientes expongan explícitamente todos los
requerimientos. Debido a que el modelo en cascada lo requiere, tiene la incertidumbre
de acomodarlos al inicio del proyecto.
3. El cliente por lo regular es impaciente. Una versión beta del programa o un prototipo
no podrá estar disponible hasta que el proyecto este muy avanzado.
4. Los responsables del desarrollo del software siempre se retrasan innecesariamente. Es
decir, el tiempo que se pasa esperando puede sobrepasar el tiempo que se emplea para
el trabajo que se produce27.
2.1.2 El modelo de desarrollo evolutivo
Este modelo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los
comentarios de los usuarios y refinándola a través de las diferentes versiones hasta que se
desarrolla un sistema adecuado, como se muestra en la figura 2.2, las actividades de
especificación, desarrollo y validación se entrelazan en lugar de separarse, con una veloz
retroalimentación entre estas. Existen dos tipos de desarrollo evolutivo.
26 Sommerville, L. 2005. Ingeniería del Software:63: Pearson. 27 Pressman, R. 1998. Ingeniería de Software. Un Enfoque Práctico, 4 Edición:23: Mc Graw Hill.
19
Planteamiento delSistema
(Software)
Versión Inicial
Versiones intermedias
Versión Final
Especificación
Desarrollo
Validación
Figura 2.2 Modelo de desarrollo evolutivo28
1. El desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y al final entregar un sistema completo de acuerdo a las
necesidades del cliente. Primero se comienzan a desarrollar las partes del sistema que
son más comprensibles tanto para el desarrollado como los usuarios y después el
propio cliente va agregando más características para que el sistema vaya
evolucionando.
2. Prototipos desechables, donde los objetivos de los procesos de desarrollo son
comprender los requerimientos del cliente y después desarrollar una definición
mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar
con aquellos requerimientos que aun no son del todo comprendidos por los que van a
desarrollar el sistema.
Este tipo de modelo suele ser más efectivo que el modelo en cascada debido a que
satisface las necesidades inmediatas de los clientes, la ventaja de este modelo es la
especificación que se puede desarrollar en forma creciente. Tan rápido como los clientes o
usuarios puedan entender claramente el problema que desean resolver, este se puede
reflejar en el sistema de software. Por otro lado, desde el punto de vista de la ingeniería
este modelo o este enfoque tiene dos problemas:
1. El proceso no es visible, es decir que los administradores tienen que hacer revisiones y
entregas regulares para que de esta forma se pueda medir el progreso. Por ejemplo, si
28 Elaboración con fuente de: Sommerville, L. 2005. Ingeniería del Software: Pearson.
20
los sistemas de software se desarrollan rápidamente, no es rentable producir
documentos que muestren cada versión que se ha desarrollado del sistema.
2. Con frecuencia los sistemas tienen una estructura deficiente, es decir que los cambios
que se dan de forma continua tienden a corromper la estructura del software, por lo
tanto, hacer cambios en el sistema de software se convierte cada vez más en una tarea
difícil y costosa.
En sistemas de software pequeños y tal vez de tamaño medio, por ejemplo hasta
500,000 líneas de código, este modelo de desarrollo evolutivo es bueno. Sin embargo los
problemas se hacen particularmente agudos cuando se trata de sistemas grandes y complejos
con un periodo de vida largo, donde intervienen un mayor número de equipos de desarrollo y
que desarrollan cada una de las distintas partes del sistema29.
2.1.3 El modelo de construcción de prototipos
Existen circunstancias en las cuales por razones prácticas, no se puede utilizar un modelo
incremental. En estas situaciones se completa una declaración de los requerimientos del
software y es utilizada por el equipo de desarrollo como base para el software de sistema30. El
cliente, a menudo, define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable
del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la
capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la
interacción hombre-máquina. En estas y en otras muchas situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque31.
Un prototipo es una versión inicial del sistema de software que se utiliza para
demostrar conceptos, probar opciones de diseño y en general informarse más del sistema y sus
posibles soluciones. El desarrollo rápido e iterativo del prototipo es esencial ya que es
necesario que los que participan en el desarrollo del software puedan experimentar con el
prototipo en las primeras etapas del proceso. El prototipo del software se puede utilizar de
varias formas en el proceso de desarrollo de software:
29 Sommerville, L. 2005. Ingeniería del Software:63-64: Pearson. 30 Sommerville, L. 2005. Ingeniería del Software:373: Pearson. 31 Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico:21-22: McGraw Hill.
21
§ En el proceso de ingeniería de requerimientos, un prototipo puede ayudar en la
obtención y validación de requerimientos del sistema.
§ En el proceso de diseño de sistema, se puede utilizar un prototipo para explorar
soluciones de software particulares y para apoyar al diseño de las interfaces de usuario.
§ En el proceso de pruebas se puede utilizar un prototipo para ejecutar las pruebas back-
to-back con el sistema que se entregara al cliente, es decir pruebas de contraste con las
diferentes versiones del sistema.
Los equipos del sistema permiten a los usuarios ver como este apoya su trabajo.
Pueden adquirir nuevas ideas para los requerimientos y encontrar áreas fuertes y débiles en el
software. Entonces pueden proponer nuevos requerimientos del sistema. Además, a medida
que se desarrolla el prototipo, pueden aparecer errores y omisiones en los requerimientos
propuestos. Una función descrita en una especificación podría parecer útil y bien definida. Sin
embargo, cuando la función se combina con otra, a menudo los usuarios comprueban que su
visión inicial fue incorrecta o incompleta. La especificación del sistema podría modificarse
para reflejar el cambio en la comprensión de los requerimientos.
Figura 2.3 Modelo de construcción de prototipos32
Se puede utilizar un prototipo del sistema mientras se está diseñando el sistema para
llevar a cabo experimentos de diseño con el fin de verificar la viabilidad de un diseño
32 Elaboración con fuente de: Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico: McGraw Hill.
22
propuesto. Por ejemplo, un diseño de una base de datos puede ser prototipado y aprobado para
verificar que las consultas más comunes de los usuarios tienen el acceso a los datos más
eficientemente. El prototipado es también una parte fundamental del proceso de las interfaces
de usuario. Debido a la naturaleza dinámica de las interfaces de usuario, las descripciones
textuales y los diagramas no son suficientes para expresar los requerimientos de estas. Por lo
tanto, el prototipado rápido con la participación del usuario es la única forma razonable de
desarrollar interfaces gráficas de usuario para sistema software. La construcción de prototipos
puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas
del juego al comienzo, es decir, el cliente y el desarrollador se deben poner de acuerdo en que
el prototipo se construya para servir como un mecanismo de definición de requisitos.
2.1.4 El modelo DRA
El modelo DRA (Desarrollo Rápido de Aplicaciones) es un modelo de proceso del desarrollo
del software lineal secuencial que se enfoca en un ciclo de desarrollo demasiado corto. El
modelo DRA es una adaptación a alta velocidad del modelo lineal secuencial en el que se
logra el desarrollo rápido utilizando una construcción basada en componentes. Sí se
comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA da la
posibilidad al equipo de desarrollo de crear un sistema funcional dentro de períodos cortos de
tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el
enfoque DRA comprende las fases siguientes.
Modelado de Administración. El flujo de información entre las funciones de
administración se modela de forma que responda a las siguientes preguntas:
§ ¿Qué información conduce el proceso de administración?
§ ¿Qué información se genera?
§ ¿Quién la genera?
§ ¿A quién va dirigida la información?
§ ¿Quién la procesa?
Modelado de datos. El flujo de información definido como parte de la fase de modelado de
administración se refina como un conjunto de objetos de datos que son necesarios para apoyar
a la empresa. Se definen los atributos de cada uno de los objetos y las relaciones entre estos
objetos.
23
Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una
función de administración. Las descripciones del proceso se crean para agregar, modificar,
eliminar o recuperar un objeto de datos.
Generación de aplicaciones. En lugar de crear software con lenguajes de programación de
tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas
ya existentes siempre y cuando esto sea posible o crear componentes reutilizables cuando sea
necesario. De cualquier forma en todos los casos se utilizan herramientas para facilitar la
construcción del software.
Pruebas y entrega. Como el proceso DRA hace énfasis en la reutilización, muchos de los
componentes de los programas ya se han comprobado. Esto ayudará a reducir el tiempo de
pruebas. Sin embargo, todos los componentes nuevos deben ser probados, así como también
ejercitar todas las interfaces a fondo.
El modelo de proceso DRA se ilustra en la figura 2.4. Desafortunadamente, las
limitaciones de tiempo impuestas en un proyecto DRA demandan ámbito en escalas. Si una
aplicación de administración puede modularse de manera que permita completarse cada una de
las funciones principales en menos de tres meses utilizando por supuesto el esquema
presentado, es un candidato del DRA. Cada una de las funciones puede ser afrontada por un
equipo DRA separado y ser integradas en uno solo.
Figura 2.4 Modelo DRA33
33 Elaboración con fuente de: Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico: McGraw Hill.
24
De igual manera que todos los modelos de proceso, el modelo DRA tiene
inconvenientes. Para proyectos grandes, el DRA requiere recursos humanos suficientes como
para crear el número correcto de equipos DRA. El DRA requiere clientes y desarrolladores
comprometidos en las rápidas actividades que son necesarias para completar un sistema en un
periodo de tiempo corto. Si no hay compromiso por ninguna de las partes, los proyectos DRA
fracasarán. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se
puede seccionar en módulos de forma adecuada, la construcción de los componentes
necesarios para DRA será problemática. Si está en juego el desempeño, y se va a conseguir
convirtiendo interfaces en componentes de sistemas, el enfoque DRA tal vez no funcione. El
DRA no es adecuado cuando los riesgos técnicos son altos. Esto pasa cuando una nueva
aplicación hace uso de nuevas tecnologías, o cuando el software nuevo requiere un alto grado
de interoperabilidad con programas de computadora ya existentes34.
2.1.5 El modelo en espiral
Este modelo fue sugerido por B. Bohem35 y reconoce que el modelo en cascada no es una
representación objetiva ni tampoco una representación muy saludable. En cambio el modelo
en espiral representado en la figura 2.5 aumenta el modelo en cascada con una serie prototipos
estratégicos y actividades de evaluación de riesgos durante todo el ciclo de vida del
proyecto36.
34 Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico:22-23: McGraw Hill. 35 Boehm, B. W. 1988. A spiral model of software development and enhancement. Computer 21, no. 5: 61-72. 36 Laplante, P. A. 2007. What every engineer should know about software engineering:29: CRC Press.
25
Figura 2.5 El modelo en espiral37
El modelo se divide en un número de actividades estructurales, también llamadas
regiones de tareas. Generalmente existen entre tres y seis regiones de tareas, tal como se
muestra en la tabla 2.2.
Tabla 2.2 Regiones de tareas del modelo en espiral
Núm. Región Descripción
1 Comunicación con el
cliente
Recopilación de tareas para lograr la
comunicación entre el desarrollador y el cliente.
2 Planificación Las tareas que definen el tiempo, los recursos y
todo lo relacionado al proyecto.
3 Análisis de Riesgos Las tareas para evaluar los riesgos técnicos del
proyecto de administración.
4 Ingeniera La tareas que construyen las representaciones de
37 Elaboración con fuente de: Boehm, B. W. 1988. A spiral model of software development and enhancement.
Computer 21, no. 5: 61-72.
26
la aplicación
5 Construcción y adaptación Las tareas que se requieren para construir, probar,
instalar, y dar soporte al usuario.
6 Evaluación del cliente Las tareas para obtener retroalimentación con
respecto a las representaciones de la aplicación
implantadas e instaladas.
Elaboación con fuente de: Pressman, Roger. 1998. Ingeniería de software. Un enfoque
práctico: Mc Graw Hill.
Cada una de estas regiones a su vez tiene un conjunto de tareas que son capaces de
adaptarse a las características del proyecto que se va a iniciar. Si el proyecto es pequeño,
entonces el número de tareas es baja, pero por el contrario si el proyecto es grande, entonces
debe haber tareas que son definidas para alcanzar el nivel más alto de formalidad.
En este modelo el software que se desarrolla se hace mediante una serie de versiones
incrementales, en donde en las primeras iteraciones podría ser solo un modelo en papel o un
prototipo y durante las últimas versiones se puede hablar ya de versiones cada vez más
completas de ingeniería del sistema38.
El modelo refleja el concepto de que cada ciclo implica una progresión que se refiere a la
misma secuencia de pasos, para cada porción del producto y para cada uno de sus niveles de
elaboración, desde un concepto global de la operación de documento a la codificación de cada
programa. Cada ciclo del espiral comienza con la identificación de:
§ Los objetivos de la parte del producto elaborado (rendimiento, funcionalidad,
capacidad de adaptarse al cambio, etc.).
§ Los métodos alternativos de implementación de esta parte del producto (diseño A,
diseño B, reutilización, compra, etc.).
§ Las restricciones impuestas sobre la aplicación de las alternativas (costo, calendario,
interfaz).
Una vez identificado lo anterior, el siguiente paso es evaluar las alternativas en relación
con los objetivos y limitaciones. Con frecuencia, este proceso identificará las áreas de
incertidumbre que son importantes fuentes de riesgo del proyecto. Si es así, el próximo paso
38 Pressman, R. 1998. Ingeniería de Software. Un Enfoque Práctico: Mc Graw Hill.
27
debería incluir la formulación de una estrategia rentable para la solución de las fuentes de
riesgo. Esto puede implicar, prototipos, simulación, benchmarking, chequeo de referencias,
cuestionarios de administración de usuario, modelado analítico, o combinaciones de estos y
otros técnicas de soluciones de riesgo.
Una vez que los riesgos se evalúan, el próximo paso está determinado por los riesgos
restantes relativos. Si los riesgos de interfaz de usuario o de funcionamiento dominan el
desarrollo de programas o los riesgos de control de interface internos, el siguiente paso puede
ser un desarrollo evolutivo: un mínimo esfuerzo para especificar la naturaleza del producto, un
plan para el siguiente nivel de prototipos, y el desarrollo de un prototipo más detallado para
seguir resolviendo las principales cuestiones de riesgo39.
Cuando se inicia el proceso de desarrollo de software siguiendo este modelo, los
desarrolladores giran alrededor del espiral haciendo en dirección de las manecillas del reloj,
iniciando por el centro. El primer circuito del espiral produce el desarrollo de una
especificación de productos, los pasos siguientes pueden ser utilizados para desarrollar un
prototipo y así sucesivamente para obtener versiones más completas del software. A diferencia
del modelo en cascada que termina cuando se entrega el software, este modelo puede aplicarse
y por supuesto adaptarse durante toda la vida útil del software que se desarrolló.
El modelo en espiral tiene un enfoque realista que va más acorde con el desarrollador
de sistemas de software a gran escala. Es decir, como el software evoluciona a medida avanza
el proceso de desarrollo, el cliente y el desarrollador comprenden y reaccionan mejor ante los
posibles riesgos que puedan ocurrir en cada uno de los niéveles evolutivos.
Desafortunadamente, este modelo no ha sido utilizado tanto como el modelo en cascada y
podrían pasar muchos años antes de que se pueda determinar con exactitud la eficiencia de
utilizar este modelo40.
2.1.6 El modelo incremental
El modelo en cascada requiere que los clientes de un sistema cumplan con un conjunto de
requerimientos antes de que se inicie el diseño y que el diseñador cumpla con estrategias
particulares de diseño antes de la implementación. Cuando se hacen cambios en los
39 Boehm, B. W. 1988. A spiral model of software development and enhancement. Computer 21, no. 5: 61-72. 40 Pressman, R. 1998. Ingeniería de Software. Un Enfoque Práctico, 4 Edición:29: Mc Graw Hill.
28
requerimientos existen implicaciones en hacer nuevamente el trabajo de recopilación, diseño e
implementación. Sin embargo, la separación en el diseño e implantación deben dar lugar a
sistemas bien documentados susceptibles de cambios. Por otro lado, un modelo de desarrollo
evolutivo permite que los requerimientos y las decisiones de diseño se retrasen, pero también
origina un software que puede estar débilmente estructurado y difícil de comprender y
mantener. El modelo incremental, como se puede observar en la figura 2.6, es un enfoque
intermedio que combina las ventajas del modelo en cascada y modelo de desarrollo evolutivo.
En un modelo incremental los clientes identifican, de forma general, los servicios que el
sistema debe proporcionar. Se identifican cuales son los más importantes y cuales son menos.
Después se definen varios incrementos en donde cada incremento proporciona un subconjunto
de la funcionalidad final del sistema. La asignación de servicios a los incrementos depende de
la prioridad del servicio, desarrollando primero los de más alta prioridad.
Figura 2.6 Modelo incremental41
Una vez que los incrementos se han identificado, los requerimientos para los servicios
que se van a entregar en el primer incremento se definen en detalle y de desarrollan. Cuando
se está desarrollando el incremento, se puede hacer el análisis para los siguientes incrementos
pero no se pueden hacer cambios al incremento actual. Una vez que se ha concluido un
incremento, este se entrega al cliente para que lo pueda poner en servicio, lo que significa que
tiene una entrega temprana de parte de la funcionalidad del sistema. Se puede experimentar
con el sistema para que posiblemente se pueda clarificar los requerimientos posteriores y para
las últimas versiones del incremento actual. Y tan pronto como se terminen los nuevos
incrementos se deben integrar a los ya existentes de tal forma que la funcionalidad del sistema
mejore con cada incremento terminado y entregado42.
41 Elaboración con fuente de: Sommerville, L. 2005. Ingeniería del Software: Pearson. 42 Sommerville, L. 2005. Ingeniería del Software:66-67: Pearson.
29
Este modelo al igual que el modelo de construcción de prototipos y otros enfoques
evolutivos, es iterativo por naturaleza. Pero a diferencia del modelo de construcción de
prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada
incremento. Es decir, los primeros incrementos son versiones no completadas del producto
final, pero proporcionan al cliente la funcionalidad que precisa y también una plataforma para
la evaluación. El modelo incremental es muy útil cuando el número de personas asignadas al
desarrollo del sistema no esté completo o disponible para una implementación completa en la
fecha límite que se haya establecido para el proyecto. Los primeros incrementos se pueden
implementar con menos personas43.
Existe evidencia gracias a algunas encuestas realizadas, de que el modelo incremental
es bastante común en el área de desarrollo de software, la encuesta realizada nos dice que un
poco más del 20% de las empresas encuestadas lo utilizan44.
El modelo incremental tiene varias ventajas:
1. El cliente no tiene que esperar a que el sistema este terminado para poder hacer uso de
él y sacarle provecho. Es decir que el primer incremento debe satisfacer los
requerimientos más críticos.
2. Los incrementos iniciales pueden ser utilizados por los clientes como prototipos y
obtener alguna experiencia sobre el desarrollo de incrementos posteriores.
3. Existe un bajo riesgo en que el proyecto falle en su totalidad.
4. Debido a que los incrementos más críticos son los que se desarrollan primero, es
inevitable que los servicios más importantes sean a los que más se les haga pruebas.
Los que significa que es menos probable que se encuentren fallas en la funcionalidad
más importante del sistema.
Sin embargo el modelo también presenta algunas desventajas.
1. Los incrementos deben ser relativamente pequeños, es decir no más de 20,000 líneas
de código y cada uno debe entregar una funcionalidad del sistema.
2. A veces resulta difícil adaptar los requerimientos del cliente al tamaño apropiado para
cada incremento. 43 Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico:22: McGraw Hill. 44 Neill, C. J. and P. A. Laplante. 2003. Requirements Engineering: The State of the Practice. IEEE SOFTWARE:
40-45.
30
3. Muchos de los sistemas necesitan un conjunto de recursos que se utilizan en diferentes
partes del sistema. Esto se debe a que los requerimientos no se definen en detalle hasta
que un incremento se implementa, lo que resulta identificar los recursos comunes que
requieren todos los requerimientos45.
2.1.7 El modelo de desarrollo basado en componentes
Las técnicas de programación orientada a objetos proporcionan un nuevo enfoque más
confiable dentro de la ingeniería de software, las aplicaciones pueden ser construidas a gran
escala más que programadas, esto se logra por medio de la reutilización de frameworks de
componentes de software. Aunque el sueño de la industria del software basada en
componentes es muy viejo, parece que al fin estamos por realizar ese sueño. Las razones son
las siguientes:
1. Las aplicaciones modernas están creciendo cada vez más en términos de topología,
plataforma y evolución, por lo que la necesidad de un enfoque orientado a objetos en el
desarrollo de software es más penetrante que en el pasado.
2. Los objetos proporcionan un paradigma organizacional para descomponer grandes
aplicaciones en objetos que cooperan entre sí como un paradigma de reutilización para
construir aplicaciones utilizando componentes de software pre-construidos o pre-
empaquetados.
Por lo que un modelo basado en componentes incorpora muchas de las características
del modelo en espiral es evolutivo por naturaleza y exige un enfoque interactivo para la
creación del software46.
En la mayoría de los proyectos de software existe algo de reutilización de software. Por
lo general, esto sucede informalmente cuando las personas que trabajan en el proyecto
conocen diseños o código similares al requerido. Esta reutilización es independiente del
proceso de desarrollo que se utilice. Un enfoque basado en la reutilización se compone de una
gran base de componentes de software reutilizables y de algunos marcos de trabajo para la
integración de estos componentes. A menudo, estos componentes son sistemas que se pueden
45 Sommerville, L. 2005. Ingeniería del Software:67-68: Pearson. 46 Nierstrasz, O., S. Gibbs, and D. Tsichritzis. 1992. Component-oriented software development.
Communications of the ACM 35, no. 9: 160-165.
31
utilizar para proporcionar una funcionalidad específica. En la figura 2.7 se muestra el modelo
basado en componentes.
Figura 2.7 Modelo basado en componentes47
La etapa de especificación de requerimientos y validación son comparables con otros
modelos, sin embargo las etapas intermedias en el proceso orientado a la reutilización son
diferentes. Estas etapas son:
1. Análisis de componentes. Una vez obtenida la especificación de requerimientos, se
buscan los componentes para implementar esta especificación. Aunque no existe una
concordancia exacta, estos componentes pueden proporcionar parte de la funcionalidad
requerida.
2. Modificación de requerimientos. En esta etapa los requerimientos se analizan
utilizando información acerca de los componentes que se han encontrado. Después se
modifican estos componentes. Y si las modificaciones no son posibles entonces se
buscan otras alternativas.
3. Diseño de sistema con reutilización. En esta etapa se reutiliza un marco de trabajo para
el sistema. Los diseñadores tienen en cuenta los componentes que se reutilizan y
organizan en el marco de trabajo para que los satisfaga. Si los componentes
reutilizables no son los adecuados, entonces se tienen que diseñar nuevos
componentes.
4. Desarrollo e integración. Para desarrollar el sistema, el software que no se puede
adquirir se desarrolla y se integran con los componentes que ya tienen. En este modelo
47 Elaboración con fuente de: Sommerville, L. 2005. Ingeniería del Software: Pearson.
32
la integración de sistemas es parte del proceso de desarrollo, más que una actividad
separada48.
Según estudios de reutilización dados a conocer por QSM Associates, Inc., nos dice
que la reutilización de componentes y su integración conlleva a una reducción del 70% por de
tiempo de ciclo de desarrollo, un 84% del costo del proyecto y un índice de productividad del
26.2. Aunque estos resultados están en función de la robustez de la biblioteca de componentes,
no hay duda de que el modelo basado en componentes proporciona ventajas significativas para
los ingenieros de software.
El proceso unificado de desarrollo de software representa un número de modelos de
desarrollo basados en componentes que han sido propuestos en la industria. Utilizando el
Lenguaje de Modelado Unificado (UML), el proceso unificado define los componentes que se
utilizarán para construir el sistema y las interfaces que conectarán los componentes. Utilizando
una combinación del desarrollo incremental e iterativo, el proceso unificado define la función
del sistema aplicando un enfoque basado en escenarios (desde el punto de vista de1 usuario).
Entonces acopla la función con un marco de trabajo arquitectónico que identifica la forma que
tomará el software49.
2.1.8 El modelo de proceso unificado
El modelo de proceso unificado usa un enfoque orientado a objetos paras modelar una familia
de procesos de software usando el lenguaje de modelado unificado (UML) como notación. Así
como UML el proceso unificado es un metamodelo para definir procesos y sus componentes50.
IBM realizó una implementación de este modelo la cual tiene por nombre comercial, Rational
Unified Process (RUP). RUP es una infraestructura flexible de desarrollo de software que
proporciona prácticas recomendadas probadas y una arquitectura configurable. Es un proceso
práctico Las mejores prácticas del RUP, son un conjunto de procesos de ingeniería de software
que dan guía para conducir las actividades de desarrollo del equipo. Como una plataforma de
procesos que abarca todas las prácticas de la industria, el RUP permite seleccionar fácilmente
el conjunto de componentes de proceso que se ajustan a las necesidades específicas del
48 Sommerville, L. 2005. Ingeniería del Software:64-65: Pearson. 49 Pressman, R. 2002. Ingeniería de Software. Un enfoque práctico:28-29: McGraw Hill. 50 Laplante, P. A. 2007. What every engineer should know about software engineering:32: CRC Press.
33
proyecto. Se podrán alcanzar resultados predecibles unificando el equipo con procesos
comunes que optimicen la comunicación y creen un entendimiento común para todas las
tareas, responsabilidades y artefactos. Desde un único sitio web centralizado de intercambio,
el RUP, las plataformas, herramientas y expertos de dominios proveen los componentes de
proceso necesarios para el éxito51.
El RUP proporciona una disciplina enfocada a la asignación de tareas y
responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción
de software de alta calidad que satisfaga las necesidades de sus usuarios finales dentro de un
calendario y presupuesto establecidos. El RUP es también un framework de procesos que
puede ser adoptado y extendido para adaptarse a las necesidades de una organización que
desarrolla software. El RUP recoge muchas de las mejores prácticas en materia de desarrollo
de software moderno en una forma que es adecuado para una amplia gama de proyectos y
organizaciones. Este modelo abarca seis prácticas:
1. Desarrollo de software iterativo
2. Administración de requerimientos
3. Usa una arquitectura basada en componentes
4. Modela el software de forma visual
5. Verifica continuamente la calidad del software
6. Administra el control de cambios52
Y además de estas seis prácticas, RUP maneja 6 principios clave:
1. Adaptación del proceso
2. Balancear prioridades
3. Colaboración entre equipos
4. Demostrar valor iterativamente
5. Elevar el nivel de abstracción
6. Enfocarse en la calidad53
51 IBM. http://www.rational.com.ar/herramientas/rup.html. 52 Kruchten, P. 2000. The Rational Unified Process: An Introduction:Chapter 1-2: Addison-Wesley Professional. 53 Gallego, P. G. 2007. Fundamentos de la metodología RUP. Universidad Tecnológica de Pereira.
34
La estructura dinámica de RUP se encarga del ciclo de vida de un proyecto. El RUP
proporciona un enfoque estructurado para el desarrollo iterativo, que consiste en dividir un
proyecto en cuatro fases, tal como se muestra en la figura 2.8:
1. Concepción
2. Elaboración
3. Construcción
4. Transición
Dentro de las cuales se realizan varias iteraciones en número variable según el
proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.
Las primeras iteraciones, es decir en las fases de concepción y elaboración se enfocan
más en la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una línea base de la arquitectura.
Durante la fase de concepción las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requerimientos. En la fase de elaboración, las iteraciones se
orientan al desarrollo de la línea base de la arquitectura, abarcan más los flujos de trabajo de
requerimientos, modelo de negocios, análisis, diseño y una parte de implementación orientado
a la línea base de la arquitectura. En la fase de construcción, se realiza la construcción del
producto por medio de una serie de iteraciones. Y finalmente en la fase de transición se
pretende garantizar que se tiene un producto preparado para su entrega al usuario final54.
54 Kroll, P. and P. Kruchten. 2003. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP:
Addison-Wesley Professional.
35
Figura 2.8 Fases de RUP55
El uso RUP proporciona varias ventajas a quienes lo utilizan como modelo de
desarrollo de software:
Unificación del equipo involucrado en el desarrollo del proyecto. Unifica todo el
equipo de desarrollo de software y optimiza su comunicación proveyendo a cada miembro de
una aproximación al desarrollo de software con una base de conocimiento de acuerdo a las
necesidades específicas del proyecto. La base de conocimiento unifica aún más al equipo
identificando y asignando responsabilidades, artefactos y tareas de forma que cada miembro
del equipo comprenda su contribución al proyecto. Unificando al equipo, se simplifica la
comunicación, asegurando la asignación de recursos en forma eficiente, la entrega de los
artefactos correctos, y el cumplimiento de los tiempos límite.
Entrega del software operativo con confianza. El RUP mantiene al equipo enfocado en
producir incrementalmente software operativo a tiempo, con las características requeridas y
con la calidad requerida. Las mejores prácticas probadas en la industria, contenidas en el RUP,
incorporan las lecciones aprendidas de cientos de líderes de la industria y miles de proyectos.
Ya no hay necesidad de re-inventar soluciones a desafíos de la ingeniería de software bien
conocidos. Siguiendo el acercamiento al desarrollo iterativo del RUP, es posible entregar a
tiempo y con confianza el software.
55 Fuente: IBM. http://www.rational.com.ar/herramientas/rup.html.
36
Control de nuevas herramientas y tecnologías. La plataforma del RUP permite
controlar nuevas herramientas y tecnologías en un único ambiente a través de contenido Plug-
In personalizado, mentores de herramientas y ayuda. Los Plug-Ins tecnológicos permiten
actualizar el proceso de desarrollo y personalizarlo a medida que la tecnología, herramientas y
plataformas evolucionan. Para controlar completamente las nuevas tecnologías e incrementar
la eficiencia en el uso de las herramientas56.
Pero por otro lado RUP es un proceso pesado, basado mucho en la documentación, en
la que no son deseables todos esos cambios volátiles y que involucran contar con un equipo de
desarrollo numeroso, inclusive para proyectos pequeños.
2.2 Métodos Ágiles
Durante mucho tiempo las empresas de software y las áreas informáticas de las
organizaciones, siguieron un proceso en cascada, estructurado y secuencial, en el desarrollo de
software. Este enfoque se ha basado en una detallada planificación para asegurar la calidad de
sus productos. Sin embargo, en los últimos años, se han popularizado otro tipo de
metodologías de desarrollo iterativas e incrementales, las cuales permiten a los desarrolladores
de software incorporar requerimientos cambiantes y la evolución de tecnologías a lo largo de
todo el proceso de desarrollo de sus productos. Siguiendo este modelo evolutivo, los
desarrolladores entregan regularmente nuevas versiones del software a los clientes para poder
reaccionar ágilmente a la retroalimentación de estos respecto de las funcionalidades
entregadas y eventuales problemas. Este proceso de desarrollo implica muchos ciclos de
"diseño-construcción-prueba", y cada ciclo incorpora e integra más funcionalidades al
producto en desarrollo. Los agilistas valoran más la respuesta a los cambios a través del uso de
iteraciones con los usuarios y los desarrolladores, que al seguimiento estricto de un plan,
argumentando que la rigidez de los planes o contratos muchas veces deriva en que cuando el
sistema es entregado el problema que se pretendía resolver cambió o ya no existe57.
56 IBM. http://www.rational.com.ar/herramientas/rup.html. 57 Leon, C. and B. Crawford. 2006. Métodos ágiles y creatividad en equipos de desarrollo de software.
Suplemento.
37
2.2.1 El Manifiesto Ágil
La palabra que generalmente se usa para cualificar una entidad con la habilidad no sólo de
enfrentar sino de prosperar en un contexto incierto es la agilidad. Esta habilidad ha sido
estudiada de manera amplia por diversas áreas del conocimiento. Veamos como ejemplo el
enfoque de dos de ellas. En la teoría de la complejidad, se estudian los sistemas ágiles
definiéndolos como los que tienen la habilidad de modificar su estructura interna y su
comportamiento para ser más eficientes y efectivos, considerando la retroalimentación de su
ambiente cambiante. En administración, se consideran negocios ágiles aquellos que ofrecen
soluciones de valor agregado para sus clientes configurando sus productos y servicios,
mientras se adaptan de manera reactiva a los cambios de su ambiente, innovan en forma
proactiva para causar cambios en el ambiente y cooperan de forma oportunista interna y
externamente con sus pares para aumentar su competitividad58.
Pensar en el significado de “ser ágil”, puede ser más complicado de lo que parece. El
desarrollo ágil no es un proceso específico que se pueda seguir fácilmente. El método ágil no
son prácticas de equipo ni nada por el estilo59. La agilidad no es un acuerdo que pueda ser
verificado en una lista de iniciativas de una organización. La agilidad es una forma de vida, es
una respuesta cambiante y emergente a la turbulencia de los negocios. Los críticos pueden
decir que, "la agilidad es simplemente esperar a que pasen cosas malas y luego responder. Se
trata de un nombre de fantasía, que se utiliza por la falta de planificación". Pero aun las
organizaciones ágiles, realizan la planificación. Tres características que ayudan a definir la
agilidad son: la creación y la respuesta al cambio, ser ágil y capaz de improvisar, y el
equilibrio entre flexibilidad y estructura. La agilidad es la capacidad para crear y responder al
cambio con el fin de beneficiarse en un turbulento ambiente de negocios. La agilidad no es
meramente una reacción, sino también una acción. En primer lugar las organizaciones ágiles
crean cambios, cambios que causan una intensa presión sobre los competidores. Esta creación
de cambios requiere innovación, la capacidad para crear nuevo conocimiento que proporcione
valor al negocio. En segundo lugar las organizaciones ágiles tiene la capacidad para reaccionar
58 Díaz, M. I. La incertidumbre y la ingeniería de software. 59 Warden, S. 2007. The Art of Agile Development:9: O'Reilly Media, Inc.
38
y responder rápida y efectivamente a los cambios previstos e imprevistos en el entorno
empresarial60.
Las metodologías de desarrollo de software ágil, han tomado este concepto de “ágil”,
cuando en el mes febrero del año 2001, después de una reunión celebrada en Utah (EUA),
nace el término “ágil” aplicado al desarrollo de software. En esta reunión participaron un
grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de algunas metodologías de desarrollo software. Su objetivo fue proponer los
valores y principios que deberían permitir a los equipos desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una
alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser
rígidos y dirigidos por la documentación que se genera en cada una de las actividades
desarrolladas.
Tras esta reunión se creó una organización sin ánimo de lucro, dedicada a promover los
conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para
que adopten dichos conceptos, ésta organización se llamó, “The Agile Alliance”. El punto de
inicio fue el “Manifiesto Ágil”, un documento que resume la filosofía ágil. Este manifiesto
propone cuatro valores y doce principios:
1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir un buen entorno. La mayoría de las veces se
comete el error de construir primero el entorno y esperar que el equipo se adapte
automáticamente a él. Es mejor crear el equipo y que éste configure su propio entorno de
desarrollo en base a sus necesidades.
2. Desarrollar software que funciona más que conseguir una buena
documentación. No producir documentos a menos que sean necesarios de forma inmediata
para tomar una decisión importante. Estos documentos deben ser cortos y centrarse en lo
fundamental.
60 Marchesi, M., G. Succi, D. Wells, L. Williams, and J. D. Wells. 2003. Extreme programming perspectives:
Addison-Wesley.
39
3. La colaboración con el cliente más que la negociación de un contrato. Se
propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.
4. Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos,
cambios en la tecnología, cambios en el equipo, entre otros) determina también el éxito o
fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, tienen que ver con las metas a seguir y la organización del mismo. Los
principios son:
1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
3. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo
que necesitan y confiar en ellos para conseguir finalizar el trabajo.
6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
7. El software que funciona es la medida principal de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por
sí mismos.
40
12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo,
y según esto ajusta su comportamiento61.
De acuerdo con Jim Highsmith y Alistair Cockburn, ambos miembros fundadores de dicha
alianza, lo nuevo de estos métodos no son las prácticas que utilizan, sino su reconocimiento de
la gente como principal factor de éxito de los proyectos. Adicionalmente, Cockburn define
estos métodos como el uso de reglas “ligeras pero suficientes” y la aplicación de técnicas
orientadas a las personas y su comunicación62.
2.2.2 Programación Extrema (Extreme Programming)
Programación Extrema es uno de los métodos ágiles más comúnmente usado y es conocido
popularmente como XP. Este método fue diseñado originalmente como una manera de apoyar
a los equipos de desarrollo de software pequeños que trabajan con requerimientos inciertos o
que son propensos a cambios contantes. Es decir, XP fue una respuesta a muchos de los
enfoques pesados de las metodologías tradicionales que son demasiado grandes para estos
pequeños grupos de desarrollo. Sin embargo, XP no tiene como intención solo desarrollar y
entregar un programa, como muchos creen, por el contrario, XP está diseñado bajo principios
de la ingeniería de software, pero se centra en la entrega oportuna de los programas y sistemas
informáticos que responden a las necesidades de los usuarios. Un aspecto importante de XP es
la potenciación del papel de los desarrolladores actuales, quienes deben ser capaces de
reaccionar inmediatamente a los cambios en los requerimientos del cliente, incluso aun,
cuando el ciclo de vida del desarrollo del proyecto se encuentre en las etapas finales.
XP también hace gran énfasis en el equipo de desarrollo de software y en el trabajo en
equipo. El equipo a su vez, incorpora la gestión, el personal técnico, y los usuarios finales de
todos lo que cooperaron para el bien común. Toma como uno de sus objetivos, que los equipos
de desarrollo se comuniquen constantemente y presten atención a toda la información
necesaria para asegurarse de que el software que está siendo desarrollado coincida con las
necesidades de los usuarios, para que se pueda conseguir elaborar un software con calidad.
XP se rige bajo los siguientes cinco principios:
61 Canós, J., P. Letelier, and M. C. Penadés. Metodologías Ágiles en el desarrollo de Software. 62 Diaz, S. 2007. Métodos Ágiles. Software Guru.
41
1. Comunicación.- Es bueno hablar (particularmente entre usuarios y
desarrolladores).
2. Simplicidad.- Mantener el sistema simple e incrementarlo cuando sea requerido.
3. Retroalimentación.- Permitir a los usuarios retroalimentación temprana y tardía.
4. Coraje.- Tener valor para afrontar los cambios.
5. Respeto.- Ninguna metodología funciona si no hay respeto entre los miembros del
equipo de desarrollo63.
De igual manera XP tiene un ciclo de vida o un proceso que consiste de cinco fases:
Exploración, Planeación, Iteraciones para liberación, Productionizing, Mantenimiento y
Muerte, tal como se ilustra en la figura 2.9.
FASE
DE
PRO
DU
CTI
ON
ZIN
G
FASE
DE
MA
NTE
NIM
IEN
TO
FASE
DE
MU
ERTE
Figura 2.9 Proceso de XP64
Fase de Exploración (Exploration Phase). En esta fase el cliente escribe las tarjetas
de historia (story cards) que se deben incluir en la primera liberación. Cada historia describe
una característica que va a ser añadida al sistema. Al mismo tiempo los miembros de equipo
del proyecto se familiarizan entre ellos mismos, con las herramientas, con la tecnología y con
las prácticas que se van a utilizar durante el desarrollo del proyecto. Se harán pruebas de la
tecnología que se va a utilizar y se exploran las posibles arquitecturas para construir un
prototipo del sistema. Esta fase se lleva a cabo entre pocas semanas y pocos meses,
dependiendo de cómo los programadores se familiaricen con la tecnología.
63 Hunt, J. 2006. Agile software construction:16: Springer. 64 Elaboración con fuente de: Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software.
42
Fase de Planeación (Planning Phase). En esta fase se establece el orden de prioridad
de las historias y se hace un compromiso del contenido de las primeras liberaciones que se
entregarán. Los programadores estiman primero cual es el esfuerzo que requiere cada historia
y en base a esto, cual es el horario que será acordado. El lapso de tiempo para la primera
entrega normalmente no excede los dos meses. La Fase de Planeación o Planificación se lleva
solo un par de días.
Fase de Iteraciones para Liberación (Iteration to Release Phase). Esta fase incluye
varias iteraciones antes de la primera entrega. El calendario establecido en la etapa de
planeación se divide en un número de iteraciones, cada iteración tomará de una a cuatro
semanas para su implementación. La primera iteración crea un sistema con la arquitectura de
todo el sistema. Esto se consigue mediante la selección de las historias que forzarán a construir
la estructura de todo el sistema. El cliente decide que historias se seleccionaran para cada
iteración. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteración.
Al final de la última iteración el sistema está listo para ponerlo en producción.
Fase de Productionizing (Productionizing Phase). Esta fase requiere pruebas y
verificaciones adicionales al desempeño del sistema antes de que pueda ser liberado al cliente.
En esta fase, se pueden encontrar cambios y se debe tomar la decisión si esos cambios se
incluirán en la versión actual. Durante esta fase, puede necesitarse que las iteraciones se
aceleren de tres semanas a un mes. Las ideas y sugerencias pospuestas son documentadas para
implementarlas más tarde, por ejemplo, en la fase de mantenimiento.
Fase de Mantenimiento (Maintenance Phase). Después que la primera versión es
liberada para el uso del cliente, el proyecto XP debe mantener el sistema ejecutándose en
producción mientras se producen al mismo tiempo nuevas iteraciones. Con el fin de lograr
esto, la Fase de Mantenimiento requiere de un gran esfuerzo para no dejar de realizar las tareas
de atención al cliente. De este modo, la velocidad de desarrollo puede desacelerarse después
de que el sistema sea puesto en producción. En esta fase se podrían requerir nuevas personas
en el equipo de desarrollo y así cambiar la estructura del equipo.
Fase de Muerte (Death Phase). Esta fase está próxima cuando el cliente ya no tiene
alguna historia que se deba implementar. Esto requiere que el sistema satisfaga las necesidades
del cliente en otros aspectos (por ejemplo, el desempeño y la confiabilidad). Este es el
momento en el proceso de XP cuando la documentación necesaria del sistema es finalmente
43
escrita, los cambios en la arquitectura, en el código o en el diseño ya no se hacen. La muerte
también puede ocurrir si el sistema no está dando los resultados esperados o si se vuelve
demasiado caro para hacer un mayor desarrollo65.
Por otra parte, los Roles y Responsabilidades de XP son:
Programador (Programmer). El programador escribe las pruebas unitarias y produce
el código del sistema.
Cliente (Customer). El cliente escribe las historias de usuario y las pruebas
funcionales para validar su implementación. Además, asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor
al negocio.
Encargado de pruebas (Tester). El tester ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento (Tracker). El tracker proporciona realimentación al
equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real
dedicado, con el fin de mejorar futuras estimaciones y realiza el seguimiento del progreso de
cada iteración.
Entrenador (Coach). El coach es responsable del proceso global. Debe proporcionar
las guías adecuadas al equipo de tal forma que se apliquen las prácticas XP y se siga el
proceso correctamente.
Consultor (Consultant). Es un miembro externo del equipo con un conocimiento
específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.
Manager (Big Boss). El manager es el vínculo entre los clientes y los programadores,
ayuda a que el equipo trabaje efectivamente creando para ello las condiciones adecuadas. Su
principal labor es la coordinación66.
Finalmente, algo realmente impresionante de XP es que entre las prácticas que propone
hay poca novedad. Cada uno de sus principios ha sido utilizado y discutido durante mucho
tiempo, sin embargo, cuando son puestos en conjunto, logran una perfecta armonía que hacen 65 Abrahamsson, P., O. Salo, S. Ronkainen, and J. Warsta. 2002. Agile Software Development Methods: Review
and Analysis, Espoo 2002:19-21: VTT Publications. 66 Canós, J., P. Letelier, and M. C. Penadés. Metodologías Ágiles en el desarrollo de Software.
44
de la Programación Extrema una disciplina organizada que ofrece una vía para incrementar
velocidad y eficiencia en el desarrollo de software. Para lograr entender qué es y cómo hacer
XP, debe prestarse atención a cada una de las siguientes prácticas de la Programación
Extrema:
Planeamiento del Juego (The Planning Game). El planeamiento del juego es la etapa
donde clientes y desarrolladores construyen un plan inicial para el desarrollo del proyecto y en
la medida que este avanza, se refina hasta su culminación. El proceso de planificación puede
verse como un juego, donde el cliente y los desarrolladores son los jugadores, las fichas son
pequeños requisitos escritos sobre tarjetas, y una serie de movimientos válidos que incluyen
cada una de las responsabilidades de los jugadores. La planificación será realizada
frecuentemente durante el proceso de desarrollo, permitirá que el equipo de trabajo
perfeccione su concepción acerca del sistema, y brindará un excelente control al desarrollo del
mismo.
Pruebas (Testing). Las pruebas son divididas en dos grupos durante la aplicación de la
Programación Extrema. El primero de ellos es el que comprende la escritura de pruebas
unitarias (Test Units), el segundo es la escritura de pruebas de aceptación (Acceptance Tests).
Los desarrolladores escribirán las pruebas unitarias en la medida que escriban el código. El
cliente escribirá las pruebas de aceptación mientras define los requisitos del sistema. Mantener
un conjunto de pruebas durante la construcción del proyecto, y correrlas a intervalos regulares
para validar los resultados obtenidos, asegurará mantener la calidad esperada del producto
final.
Programación en Parejas (Pair Programming). Una de las prácticas más discutidas es
la programación en parejas. Es decir, la producción de código en un proyecto con el empleo de
Programación Extrema será realizada en parejas de desarrolladores, los cuales compartirán una
misma computadora, monitor y teclado. Podría parecer ineficiente la utilización de dos
programadores en la realización de una misma tarea, pero la realidad ha demostrado todo lo
contrario. Investigaciones realizadas en este campo demuestran que dos programadores que
trabajan en conjunto generan, en el mismo espacio de tiempo, códigos de mejor calidad que el
producido cuando se trabaja de forma separada.
Refactorización (Refactoring). La refactorización es el proceso de cambiar un sistema de
software de modo que el comportamiento externo del código no sea alterado. En la aplicación
45
de la Programación Extrema, los miembros del equipo de desarrollo refactorizarán el código
del proyecto siempre y cuando sea necesario. El principal objetivo de la refactorización en XP
es lograr un código más simple y legible para eliminar cualquier vestigio de duplicados. La
refactorización eliminará fuentes potenciales de errores y disminuirá posibles problemas a
futuros desarrolladores guiándolos en la dirección correcta.
Diseño Simple (Simple Design). El diseño simple establece que las tareas deben ser
realizadas de la forma más simple posible. Para lograr un diseño simple, nunca serán
adicionadas características funcionales que no formen parte de la propuesta de requisitos
analizada en la planificación del juego. En la Programación Extrema un buen diseño es
esencial para asegurar el éxito.
Propiedad colectiva del código (Collective Code Ownership). La propiedad colectiva
del código establece que cualquier miembro del equipo de desarrollo tendrá la autoridad y la
capacidad de realizar cambios en el código del proyecto para lograr su mejoramiento. Cada
uno de los miembros del equipo de desarrollo rotará en la implementación de cada módulo, y
logrará una completa capacitación en todo el producto. Cada desarrollador estará informado de
las modificaciones realizadas en todas las secciones implementadas.
Integración continua (Continuous Integration). La integración continua estipula que
deberán realizarse cada día varias integraciones del código del proyecto. Esta práctica evitará
la mayor parte de los problemas que ocurren cuando un equipo integra el trabajo pasado largo
tiempo, y comienzan los errores sin que nadie sepa dónde y por qué. La Integración continua
mantendrá al equipo de desarrollo moviéndose, para evitar congelamientos de código y una
gran fuente potencial de errores. Una integración frecuente aumentará la posibilidad de
descubrir desde el principio los errores que surjan en el proyecto y de esta forma corregirlos
inmediatamente.
Cliente en el lugar (On-site Customer). El cliente en el lugar establece que para lograr el
funcionamiento óptimo, el equipo de Programación Extrema deberá contar con el cliente a su
lado durante todo el proceso de planificación para aclarar posibles dudas y tomar decisiones
críticas en las reglas de negocio de la aplicación. Una comunicación cara a cara entre el cliente
y el desarrollador elimina malentendidos, así como posibles cuellos de botella que retrasen el
desarrollo del proyecto.
46
Entregas pequeñas (Small Releases). Las entregas pequeñas son la planificación y la
entrega de versiones estables y funcionales del código del proyecto después de culminar cada
iteración, de esta forma se logra una constante retroalimentación por parte del cliente que
ayude a mantener al equipo de desarrollo al tanto de la actividad proyectada. La entrega de
versiones pequeñas conlleva al análisis más rápido y efectivo por parte del cliente, y evita
malentendidos con los requisitos por parte de los desarrolladores. Además, podrán tomarse
decisiones que no afecten o den al traste con el trabajo de varios días en caso de que el
resultado no satisfaga las necesidades proyectadas.
40 horas a la semana (40-hours Week). Las 40 horas a la semana establecen el tiempo
promedio de trabajo del equipo de desarrollo del proyecto en 5 días hábiles. Una persona
promedio, independientemente de su capacidad laboral, disminuye su rendimiento pasadas las
8 horas diarias de trabajo. Esto provoca que, paralelamente, disminuya la calidad del código
producido. Una sobredosis en el tiempo de desarrollo no es la respuesta adecuada a los
problemas en un proyecto, sino que es un síntoma de un problema aún más grave. La correcta
dosificación del tiempo logrará que los recursos humanos se comporten a su máxima
capacidad y mantengan sin irritaciones la calidad del producto final.
Estándares de código (Coding Standards). La aplicación de estándares de código logra
un ambiente familiar en el código entre cada uno de los miembros del equipo de desarrollo.
Sin la aplicación de estos será muy difícil la realización de refactorizaciones, construcción de
pruebas unitarias y la comprensión por parte de otros programadores. El objetivo de esta
práctica es lograr de cada pieza de código un espejo de sus vecinas en cuanto a claridad y
simplicidad, sin importar la persona que la realice.
Metáfora (Metaphor). La Metáfora es análoga o lo que la mayoría de las metodologías
llaman arquitectura. Brindará al equipo de desarrollo una visión común del funcionamiento del
sistema a través de una evocativa y simple descripción. Si no se encuentra una variante para la
construcción de la metáfora de un proyecto, el equipo de XP usará un sistema de nombres
comunes para asegurarse de que cada miembro comprende el modo de funcionamiento general
del sistema.
La Transición (Transition). La introducción de la Programación Extrema en una empresa
de desarrollo de software supone un paso de avance en materia de ingeniería, pero introduce
dificultades con las que los directivos encargados de equipos de proyecto tendrán que lidiar.
47
XP ha polarizado la industria de desarrollo de software, es difícil encontrar desarrolladores
neutrales sobre temas relacionados con la Programación Extrema, debido a que muchas de sus
prácticas difieren de las formas tradicionales de programación. Por ejemplo, la programación
en parejas y la introducción de pruebas unitarias, en la medida en que se desarrolla el sistema,
son prácticas que los desarrolladores que tratan de aplicar XP comentan las dificultades de
llevarlas a cabo. El éxito en la transición hacia el desarrollo de software guiado por la
Programación Extrema se encuentra centrado en tres conceptos fundamentales: métodos,
aprendizaje y dirección. El primero de ellos, se refiere a seguir los principios y estrategias de
la Programación Extrema. El segundo hace referencia a la necesidad de dejar a un lado los
viejos conceptos y salir en busca de nuevos conocimientos que propicien el desarrollo; y el
tercero resalta la necesidad de un líder en el equipo que vea el proceso como un todo y llame
la atención de los miembros para impedir el desvío por caminos errados67.
Los estudios demuestran que la mayoría de proyectos de software fracasan, porque
exceden sus plazos, superan su presupuesto, no se ajustan a las auténticas necesidades del
cliente, no presentan la calidad esperada según la percepción del cliente o, en muchos casos,
son abortados. Las metodologías tradicionales han tratado de poner un alto a esta situación
mediante un control intensivo del proceso. Al hacerlo, se está ignorando que las necesidades
del cliente y sus expectativas realmente cambian durante el desarrollo del proyecto68.
2.2.3 Scrum
Scrum es un proceso de desarrollo de software ágil, diseñado para añadir energía, enfoque,
claridad y transparencia a los miembros del equipo de desarrollo de software. Especula sobre
investigaciones de vida artificial para permitir a los equipos de desarrollo operar al filo del
caos para alentar a la rápida evolución del sistema. Capitaliza un mecanismo automático de
inclusión de arquitecturas. Imponiendo un conjunto de reglas simples que permiten una rápida
auto-organización de equipos de desarrollo de software para crear sistemas con arquitecturas
evolucionadas. Una implementación apropiada de Scrum fue diseñada para aumentar la
velocidad de desarrollo, alinear objetivos individuales y organizacionales, crear una cultura
67 Pino, S. L. V. d. Programación Extrema en pocos minutos: Planificando la Transición. Tono: Revista Técnica
de la Empresa de Telecomunicaciones de Cuba S.A.: 41-44. 68 Berrueta, D. 2006. Programación Extrema y Software Libre.
48
dirigida por ejecución y crear valores, logrando una comunicación estable y consistente del
funcionamiento en todos los niveles y mejora el desarrollo individual y la calidad de vida.
Scrum para los equipos de desarrollo de software comenzó en Easel Corporation en 1993 y fue
usado para construir la primera herramienta de análisis y diseño orientado a objetos que
incorporaba ingeniería round-trip. En un ambiente de desarrollo de la empresa Smalltalk, el
código es autogenerado desde una herramienta de diseño grafico y cuando sea hacen cambios
en este código desde el entorno de desarrollo integrado (IDE), estos cambios también son
reflejados en el diseño original.
Fue necesario un proceso de desarrollo para ayudar a los equipos empresariales donde
la visualización del diseño generaba inmediatamente el código trabajado. Esto condujo a una
revisión extensiva de la literatura de las ciencias de la computación y al diálogo con cientos de
líderes de equipos de desarrollo de software. Los factores clave que influyen en la
introducción de Scrum en Easel Corporation fueron problemas fundamentales inherentes en el
desarrollo de software.
La incertidumbre es inherente e inevitable en los procesos y productos de desarrollo de
software (Principio de incertidumbre de Ziv). Para un nuevo sistema de software los
requerimientos no serán completamente conocidos hasta después de que el usuario haya usado
el sistema (Principio de incertidumbre de requerimientos de Humphrey). No es posible
especificar completamente un sistema interactivo (Lema de Wegner). Los requerimientos
cambiantes y ambiguos, combinados con herramientas y tecnologías evolucionadas hacen
impredecible las estrategias de implementación69.
Scrum tiene por objetivo, controlar y administrar la producción de software usando
procesos iterativos, incrementales y ligeros. Uno de los aspectos interesantes de Scrum, es que
está enfocado en ayudar a la producción de un producto, en el que el software es tan solo un
ejemplo. Los beneficios de utilizar Scrum de acuerdo con los que proponen esta metodología
son:
1. El control y la administración del desarrollo trabajan de manera ágil.
2. Es reconocido explícitamente que los requerimientos pueden cambiar rápidamente
dentro de su enfoque iterativo e incremental para el desarrollo del producto. 69 Sutherland, J., A. Viktorov, J. Blount, and N. Puntikov. 2007. Distributed scrum: Agile project management
with outsourced development teams, 40:4597: IEEE.
49
3. Es posible seguir utilizando las prácticas de ingeniería dentro de Scrum (esto podría
facilitar a la introducción de métodos agiles en una organización).
4. Este es un enfoque basado en equipo que ayuda a mejorar la cooperación y la
comunicación.
5. Permite escalar de proyectos pequeños hacia proyectos muy grandes.
6. Ayuda a identificar y eliminar cualquier obstáculo que impida el buen desarrollo del
producto final.
En su núcleo, Scrum es un conjunto de reglas, procedimientos y prácticas que están
interrelacionadas y que trabajan juntas para mejorar el ambiente de desarrollo, reducir los
gastos de la organización y asegurarse que los entregables coincidan con los requerimientos
del usuario final.
Scrum se basa en las teorías actuales de control de proceso y específicamente tiene como
objetivo producir el mejor resultado final, con los recursos actuales y el tiempo disponible.
Tener en cuenta que el objetivo no es producir la mejor pieza de software dados los recursos
ilimitados, más que eso está basado en las realidades del mundo moderno y ayudará a producir
lo mejor que se pueda hacer dada la situación dentro de la cual se aplica.70
El proceso de Scrum incluye tres fases: la Fase de Pre-Game, la Fase de Desarrollo y la
Fase de Post-Game, tal como se muestra en la figura 2.10.
Figura 2.10 Proceso de Scrum71
70 Hunt, J. 2006. Agile software construction:25-26: Springer. 71 Elaboración con fuente de: Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software.
50
La Fase de Pre-Game incluye a su vez dos sub-fases, la fase de Planeación o
Planificación y la fase de Diseño de Alto Nivel de la Arquitectura.
Fase de Planeación. En esta fase se incluye la definición del sistema que se va a
desarrollar. Se crea el Product Backlog (ver sección de prácticas de Scrum), el cual contiene
todos los requerimientos de los que se sabe actualmente. Los requerimientos pueden ser
originados de los mismos clientes, los vendedores, el área comercial, el personal de apoyo o
los desarrolladores del software. Los requerimientos son ordenados de acuerdo a su prioridad
y se estima el esfuerzo que se necesita para llevar a cabo su implementación. El Product
Backlog se actualiza constantemente con más y nueva información detallada, de igual modo,
se actualizan las nuevas estimaciones y los nuevos órdenes de prioridad. Dentro de esta fase se
incluye también la definición del equipo de trabajo, herramientas y otros recursos, la
evaluación de riesgos y las cuestiones de control, las necesidades de capacitación y la
aprobación de la administración de la verificación.
Fase de Arquitectura. En esta fase, el diseño de alto nivel del sistema, incluyendo la
arquitectura, se planea de acuerdo a la información actual que hay en el Product Backlog. En
el caso cuando se trate de una mejora a un sistema existente, se identifican los problemas que
pueden aparecer al momento de implementar los nuevos cambios que hay en el Product
Backlog. Se realiza una reunión de revisión de diseño para revisar las propuestas de
implementación y se toman las decisiones en base a lo que se revisó. Además, se preparan los
planes preliminares para el contenido de las liberaciones.
Fase de Desarrollo. Esta fase también se conoce como fase de juego (Game-Phase) y
es la parte del enfoque ágil de Scrum. Esta fase es tratada como una caja negra, donde se
espera lo impredecible. Las diferentes variables técnicas y ambientales (como los plazos, la
calidad, requerimientos, recursos, implementación de tecnologías y herramientas e inclusive
los métodos de desarrollo) identificadas en Scrum, las cuales pueden cambiar durante el
proceso, son observadas y controladas a través de varias prácticas de Scrum durante los
Sprints (ver sección de prácticas de Scrum) de la fase de desarrollo. En lugar de tomar en
consideración estas cuestiones solo al comienzo del desarrollo del proyecto de software,
Scrum tiene por objetivo controlar constantemente, con la finalidad de ser capaces de
adaptarse con flexibilidad a los cambios. En esta fase el sistema se desarrolla mediante
Sprints. Los Sprints son ciclos iterativos donde la funcionalidad se desarrolla o se mejora para
51
producir nuevos incrementos. Cada Sprint incluye las fases tradicionales de desarrollo de
software: requerimientos, análisis, diseño, evolución y entrega. La arquitectura y el diseño del
sistema evolucionan durante el desarrollo del Sprint. Un Sprint tiene una duración estimada de
una semana a un mes. Puede haber por ejemplo, de tres a ocho Sprints en el proceso de
desarrollo de un sistema, antes de que el sistema esté listo para poner en marcha.
Fase de Post-Game. Esta fase contiene el cierre de la liberación. Se entra en esta fase
cuando se ha acordado con el cliente que los requerimientos han sido completados. Es decir,
no hay mas información ni más requisitos que pueda haber ni se pueden inventar otros nuevos.
El sistema está listo para la liberación final y su preparación se lleva a cabo en esta fase,
incluyendo las de integración, pruebas del sistema y documentación72.
Además de las fases de Scrum, existen también seis roles, los cuales tienen diferentes
tareas y propósitos durante el proceso y sus prácticas, estos roles son:
1. Scrum Master. Interactúa con el cliente y el equipo. Tiene la responsabilidad de
asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y
reglas de Scrum y que progrese de acuerdo a lo previsto. También coordina las
reuniones diarias, formula las tres preguntas canónicas y se encarga de eliminar
eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par.
2. Propietario del Producto (Product Owner). Es el responsable oficial del
proyecto, administración, control y visibilidad del Product Backlog. Es
seleccionado por el Scrum Master, el cliente y los ejecutivos a cargo. Toma las
decisiones finales de las tareas asignadas al registro y convierte sus elementos en
rasgos a desarrollar.
3. Equipo Scrum (Scrum Team). Tiene la facultad para reorganizarse y definir las
acciones necesarias o sugerir remoción de impedimentos para alcanzar las metas de
cada Sprint. Y puede participar en la estimación de esfuerzos y el Product Backlog.
4. Cliente (Customer). Participa en las tareas relacionadas con el Product Backlog.
5. Management. Está a cargo de las decisiones fundamentales y participa en la
definición de los objetivos y requerimientos. Por ejemplo, selecciona al propietario
del producto, evalúa el progreso y reduce el Backlog junto con el Scrum Master. 72 Abrahamsson, P., O. Salo, S. Ronkainen, and J. Warsta. 2002. Agile Software Development Methods: Review
and Analysis, Espoo 2002:29-30: VTT Publications.
52
6. Usuario (User). El tamaño del equipo total de Scrum no debería ser superior a diez
participantes. El número ideal es siete, más o menos dos, una cifra canónica en
ciencia cognitiva. Si hubiese más, lo más recomendable es formar varios equipos73.
Finalmente, dentro de Scrum hay varias prácticas que ayuda a alcanzar los objetivos y
a desarrollar de manera exitosas el proyecto de software, estas prácticas son:
Product Backlog (los requerimientos del cliente). El Product Backlog es el
inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben
incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo
aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo
que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el Product
Backlog.
Estimaciones (Effort Estimation). Cálculo del esfuerzo que se prevé necesario para
desarrollar una funcionalidad. Las estimaciones se pueden calcular en unidades relativas
(puntos de función) o en unidades absolutas (tiempo teórico).
Sprint (Iteracion). Se refiere a cada uno de los ciclos de desarrollo, el cual produce un
incremento terminado y operativo del producto. Estas iteraciones son la base del desarrollo
ágil, y Scrum gestiona su evolución a través de reuniones breves de seguimiento en las que
todo el equipo revisa el trabajo realizado desde la reunión anterior y el previsto hasta la
reunión siguiente.
Sprint Backlog. Es la lista de los trabajos que realizará el equipo durante el sprint para
generar el incremento previsto. El equipo asume el compromiso de la ejecución. Las tareas
están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.
Planificación del sprint (Sprint Planning meeting). Jornada de trabajo previa al
inicio de cada sprint en la que se determina cuál es el trabajo y los objetivos que se deben
cubrir con esa iteración. Esta reunión genera un Sprint Backlog o lista de tareas que se van a
realizar, y en ella también se determina el objetivo del sprint, es decir, es el lema que define la
finalidad de negocio que se va a lograr.
73 Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software.
53
Seguimiento del sprint. Es una breve reunión diaria para repasar al avance de cada
tarea, y al trabajo previsto para la jornada. En esta reunión sólo interviene el equipo, y cada
miembro responde a tres preguntas:
1. ¿Trabajo realizado desde la reunión anterior?
2. ¿Trabajo que se va a realizar hasta la próxima reunión de seguimiento?
3. ¿Impedimentos que se deben solventar para que pueda realizar el trabajo?
Revisión de sprint. Análisis y revisión del incremento generado. Esta reunión no debe
tomarse como un acontecimiento especial, sino como la presentación normal de los
resultados74.
2.2.4 Crystal
Los métodos ágiles Crystal los estableció el antropólogo de proyectos Alistair Cockburn.
Quien ha escrito los textos más utilizados, influyentes y recomendables acerca del arte de
escribir casos de uso. Cockburn relata que mucha gente piensa que el desarrollo de software es
una actividad de ingeniería. Esa comparación, dice, es de hecho más peligroso que útil, y nos
conduce en una dirección errónea. Comparar el software con la ingeniería nos lleva a
preguntarnos sobre especificaciones y modelos del software, sobre su completitud, corrección
y vigencia. Esas preguntas son inconducentes, debido a que cuando pasa cierto tiempo no nos
interesa que los modelos sean completos, que coincidan con el mundo real o que estén al día
con la versión actual del lenguaje. Hacer lo posible porque que así sea es perder el tiempo. En
contra de esa visión ingenieril, Cockburn ha modificado diversas visiones de forma
contradictorias que alternativamente lo motivaron a utilizar XP en el sentido más radical, a
entender el desarrollo de software como una forma comunitaria de poesía o a elaborar su
propia familia de metodologías Crystal.
La familia Crystal establece un código de color para marcar la complejidad de una
metodología, cuanto más oscuro es el color, más pesado es el método. Cuanto más crítico es
un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular que
Cockburn elaboró, se usa en muchos métodos ágiles para situar el rango de complejidad al
cual se aplica una metodología. Los parámetros son Comodidad (C), Dinero Discrecional (D),
Dinero Esencial (E) y Vidas (L). En otras palabras, la caída de un sistema que ocasione 74 Palacio, J. 2008. Flexibilidad con Scrum: safeCreative.
54
incomodidades indica que su nivel de criticalidad es C, mientras que si causa pérdidas de vidas
su nivel es L.
Los métodos se llaman Crystal evocando las facetas de una gema, cada faceta es otra
versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes de
éste tipo de metodología:
1. Crystal Clear (claro como el cristal) para equipos de 8 o menos integrantes.
2. Cristal Yellow (Amarillo) para equipos de 8 a 20 integrantes.
3. Crystal Orange (Naranja) para equipos de 20 a 50 integrantes.
4. Crystal Red (Rojo) para equipos de 50 a 100 integrantes.
Se habla también de seguir con Marrón, Azul y Violeta, pero la más exhaustivamente
documentada es Crystal Clear (CC), y es la que se describe a continuación.
Crystal Clear puede ser usada en proyectos pequeños de categoría D6, aunque con alguna
extensión se aplica también a niveles E8 a D10. El otro método elaborado en profundidad es el
Naranja, apto para proyectos de duración estimada en 2 años. Los otros dos aún se están
desarrollando. Como casi todos los otros métodos, Crystal Clear consiste en valores, técnicas y
procesos75.
2.2.5 Desarrollo dirigido por rasgos (Feature Driven Development)
Feature Driven Development (FDD) es un método ágil con un enfoque adaptativo para el
desarrollo de sistemas. El enfoque FDD no cubre por completo el proceso de desarrollo de
software, pero si se enfoca más en el diseño y las fases de construcción. Sin embargo, FDD ha
sido diseñado para trabajar con otras actividades relacionadas con el proyecto de desarrollo de
software y no requiere de algún modelo de procesos específico para ser usado. El método FDD
encarna en el desarrollo iterativo con las mejores prácticas que se han resultado ser muy
efectivas en la industria del software. Enfatiza en los aspectos de calidad a través del proceso e
incluye entregables frecuentes y tangibles a lo largo del todo el monitoreo del progreso del
proyecto.
FDD consiste en cinco procesos secuenciales y proporciona los métodos, las técnicas y
las guías necesarias para que los involucrados en el desarrollo del proyecto cumplan con lo
prometido y entreguen con éxito el sistema. Por consiguiente, FDD incluye los roles, los 75 Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software.
55
artefactos, las metas y los calendarios necesarios que necesita el proyecto. A diferencia de
otras metodologías ágiles, FDD pretende ser competente para el desarrollo de sistemas
críticos.
Como se mencionó antes, FDD consiste en cinco procesos secuenciales durante los
cuales se diseña y construye el sistema. La parte iterativa soporta desarrollo ágil con rápidas
adaptaciones a cambios en requerimientos y nuevas necesidades del negocio. Cada fase del
proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida. Típicamente, la
iteración de una característica requiere de una a tres semanas. Las fases son las siguientes:
Desarrollo de un modelo general. Cuando se comienza con este desarrollo, los
expertos de dominio ya están al tanto de la visión, el contexto y los requerimientos del sistema
a construir. Los requerimientos documentados tales como casos de uso o especificaciones
funcionales, deben existir en este escenario. Sin embargo, FDD no cubre este aspecto
explícitamente. Los expertos de dominio presentan algo llamado “tutorial (walkthrough)” en el
que los miembros del equipo y el arquitecto principal se informan de la descripción de alto
nivel del sistema.
Construir una lista de características. Las características, modelos de objeto y
documentación de requerimientos proporcionan la base para construir una amplia lista de
características. Las características son pequeños ítems útiles a los ojos del cliente. Son
similares a las tarjetas de historias de XP y se escriben en un lenguaje que todas las partes
puedan entender. Las funciones se agrupan conforme a diversas actividades en áreas de
dominio específicas. La lista de características se revisa por los usuarios y patrocinadores para
asegurar su validez y exhaustividad. Las características que requieran más de diez días se
descomponen en otras más pequeñas.
Plan por característica. Incluye la creación de un plan de alto nivel, en el que los
conjuntos de características se ponen en secuencia conforme a su prioridad y dependencia, y
se asigna a los programadores jefes. Las listas se priorizan en secciones que se llaman
“paquetes de diseño”. Luego se asignan las clases definidas en la selección del modelo general
a programadores individuales, es decir, propietarios de clases. Se pone fecha para los
conjuntos de rasgos o características.
Diseño y construcción por característica. Se selecciona un pequeño conjunto de
rasgos del conjunto y los propietarios de clases seleccionan los correspondientes equipos
56
dispuestos por características. Se procede luego iterativamente hasta que se producen las
características seleccionadas. Una iteración puede tomar de unos pocos días a un máximo de
dos semanas. Puede haber varios grupos trabajando en paralelo. El proceso iterativo incluye
inspección de diseño, codificación, prueba de unidad, integración e inspección de código.
Luego de una iteración exitosa, las características completas son promovidas para la
construcción principal.
FDD consiste en un conjunto de mejores prácticas y los desarrolladores del método
afirman que aun cuando las prácticas seleccionadas no son nuevas, se combinan de manera
original. Las prácticas canónicas son las siguientes:
Modelado de Objeto de Dominio. Exploración y explicación del dominio del
problema.
Desarrollo por característica. Desarrollar y dar seguimiento al progreso del proyecto
a través de una lista de pequeñas funciones descompuestas y valoradas por el cliente.
Propiedad individual de clases (código). Cada clase tiene una sola persona nominada
como responsable por su consistencia, performance e integridad conceptual.
Equipos de característica. Se refiere a equipos formados dinámicamente.
Inspección. Se refiere al uso de los mejores mecanismos de detección conocidos.
Builds regulares. Siempre se tiene un sistema disponible. Los builds forman la base a
partir de la cual se van agregando nuevos rasgos.
Administración de la configuración. Permite realizar seguimiento histórico de las
últimas versiones completas de código fuente.
Reporte de progreso. El progreso se reporta en base al trabajo completo de todos los
niveles de la organización76.
Hay tres categorías de rol en FDD: roles claves, roles de soporte y roles adicionales.
Los seis roles claves de un proyecto son:
1. Administrador del proyecto
2. Arquitecto jefe
3. Manager de desarrollo
4. Programador jefe 76 Abrahamsson, P., O. Salo, S. Ronkainen, and J. Warsta. 2002. Agile Software Development Methods: Review
and Analysis, Espoo 2002:47-54: VTT Publications.
57
5. Propietarios de clases
6. Experto de dominio
Los cinco roles de soporte son:
1. Administrador de entrega
2. Abogado/guru de lenguaje
3. Ingeniero de construcción
4. Herramientista (toolsmith)
5. Administrador del sistema
Los tres roles adicionales son los de verificadores, encargados del despliegue y escritores
técnicos. Un miembro de un equipo puede tener otros roles a cargo, y un solo rol puede ser
compartido por varias personas77.
2.2.6 Otros métodos
DSDM (Dynamic Systems Development Method). Es el método más antiguo de los auto-
denominados ágiles. Surgió en 1994 de los trabajos de Jennifer Stapleton (actual directora del
Consorcio DSDM). DSDM es el método ágil que más se aproxima a los métodos formales, de
hecho la implantación de un modelo DSDM en una organización la lleva a alcanzar lo que
CMM consideraría un nivel 2 de madurez. Sin embargo, los aspectos que DSDM critica a
CMM son:
§ Si bien es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que
funciona bien en unos entornos no tiene por qué servir para todos.
§ CMM no le da al diseño la importancia que debería tener.
§ CMM plantea un enfoque excesivo en los procesos, lo cual lo hace olvidar la
importancia que en la industria del software tiene el talento de las personas.
§ El tener procesos claramente definidos no significa tener buenos procesos.
En común con los métodos ágiles, DSDM considera imprescindible una implicación y una
relación estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con
métodos de desarrollo incremental y entregas evolutivas. DSDM cubre los aspectos de
administración de proyectos, desarrollo de los sistemas, soporte y mantenimiento y se
77 Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software.
58
autodefine como un marco de trabajo para desarrollo rápido más que como un método
específico para el desarrollo de sistemas78.
DSDM consiste en cinco fases:
1. Estudio de viabilidad.
2. Estudio del negocio.
3. Iteración del modelo funcional.
4. Iteración de diseño y versión.
5. Implementación.
En DSDM las prácticas se llaman Principios, y son nueve:
1. Es imperativo el compromiso activo del usuario.
2. Los equipos de DSDM deben tener el poder de tomar decisiones.
3. El foco radica en la frecuente entrega de productos.
4. El criterio esencial para la aceptación de los entregables es la adecuación a los
propósitos de negocios.
5. Se requiere desarrollo iterativo e incremental.
6. Todos los cambios durante el desarrollo son reversibles.
7. La línea de base de los requerimientos es de alto nivel. Esto permite que los
requerimientos de detalle se cambien según se necesite y que los esenciales se capten
tempranamente.
8. La prueba está integrada a través de todo el ciclo de vida. La prueba también es
incremental.
9. Es esencial una estrategia colaborativa y cooperativa entre todos los participantes. Las
responsabilidades son compartidas y la colaboración entre usuario y desarrolladores no
debe tener fisuras.
DSDM define quince roles. Los más importantes son:
Programadores y Programadores Senior. Son los únicos roles de desarrollo. El título de
Senior indica también nivel de liderazgo dentro del equipo. Equivale a Nivel 3 de
Cockburn. Ambos títulos cubren todos los roles de desarrollo, incluyendo analistas,
diseñadores, programadores y verificadores.
78 Bañares, J. P. 2006. Compendio de Ingeniería de Software II.
59
1. Coordinador técnico
2. Usuario embajador
3. Visionario
4. Patrocinador ejecutivo
5. Facilitador79
ASD (Adaptative Software Development). Método ágil que a diferencia de los
procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de técnicas
propias de las metodologías ágiles. No se trata de una metodología, sino de la implantación de
una cultura en la empresa, basada en la adaptabilidad.
PP (Pragmatic Programming). Pragmatic Programming es una colección de
aproximadamente 70 prácticas de programación, comunes en otros métodos ágiles, cuya
aplicación resulta útil para solucionar los problemas cotidianos.
AM (Agile Modeling). Este método ágil presenta un nuevo enfoque para realizar el
modelado y diseño de sistemas y basado en los principios de los métodos ágiles remarca la
conveniencia de reducir el volumen de la documentación80.
De acuerdo con Scott Ambler81 los desarrolladores agiles reconocen que la
documentación es una parte intrínseca de cualquier sistema, la creación y mantenimiento de
los cuales es un mal necesario para algunos y una tarea agradable para los demás, un aspecto
del desarrollo de software que se puede hacer ágil cuando así se decide. Hay varias razones
válidas para crear la documentación:
1. Los interesados del proyecto requieren la documentación
2. Para definir un Modelo de Contrato
3. Para apoyar la comunicación con un grupo externo
4. Para apoyar la memoria de la organización
5. Para efectos de auditoría
6. Para pensar en algo
79 Reynoso, C. 2004. Métodos Heterodoxos en Desarrollo de Software. 80 Bañares, J. P. 2006. Compendio de Ingeniería de Software II. 81 Ambler, S. Agile/Lean Documentation: Strategies for Agile Software Development.
http://www.agilemodeling.com/essays/agileDocumentation.htm.
60
Ambler asegura en base a su experiencia que los desarrolladores en entornos no ágiles
son a menudo obligados a crear la documentación por razones menos ideales, a menudo por
razones políticas y a veces debido a su ignorancia, y por consiguiente pudieron no haber sido
tan eficaces como posiblemente serían. Razones cuestionables para la creación de
documentación y la forma de combatirlas, incluyen:
1. El solicitante quiere ser visto para tener el control
2. El solicitante erróneamente piensa que la documentación tiene algo que ver con el
éxito del proyecto
3. El solicitante quiere justificar su existencia
4. El solicitante no conoce nada mejor
5. El proceso dice “crear el documento”
6. Alguien necesita tener la certeza de que todo está bien
7. Se está especificando el trabajo para otro grupo
8. Los contratos de desarrollo son rutinariamente sujetos a competencias
ISD (Internet Speed Development). Es el más reciente de los métodos ágiles, surgido
como respuesta para las situaciones que requieren ciclos de desarrollo muy breves con
entregas rápidas. Se centra en el talento de las personas sobre los procesos. ISD es un entorno
de gestión orientado al negocio82.
82 Bañares, J. P. 2006. Compendio de Ingeniería de Software II.
61
CAPÍTULO 3 MODELOS Y ESTÁNDARES DE CALIDAD DEL
SOFTWARE
La calidad es un término que ha adquirido gran relevancia con el paso del tiempo, ya que es
considerada como uno de los principales activos con los que cuenta un país para mejorar su
posición competitiva global. Para conseguir calidad en el software es necesario establecer un
programa de medidas a tomar con respecto a los proveedores o desarrolladores. También es
importante utilizar los modelos y métodos apropiados para controlar el proceso de desarrollo.
A la hora de definir la calidad del software se debe diferenciar entre la calidad del producto y
la calidad del proceso de desarrollo de éste (calidad de diseño y fabricación). No obstante, las
metas que se establezcan para la calidad del producto van a determinar los objetivos del
proceso de desarrollo, debido a que la calidad del primero va a depender, entre otros aspectos,
de éstos. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto83.
En este capítulo se exponen las características y atributos vinculados con la calidad del
software, los procesos, la madurez de los procesos y los modelos de procesos, entre los cuales
destaca el modelo mexicano MoProSoft.
3.1 Calidad del software
Roger Pressman dice que la calidad del software es la concordancia con los requerimientos
funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente.
El Departamento de Defensa de los Estados Unidos, dice que la calidad del software es
la capacidad de un producto software para satisfacer sus requerimientos específicos.
También se define como la capacidad del producto de software para permitirles a
usuarios específicos lograr las metas propuestas con eficacia, productividad, seguridad y
satisfacción, en contextos especificados de uso.
83 Mendoza, L., M. Pérez, A. Grimán, and T. Rojas. 2002. Algoritmo para la Evaluación de la Calidad Sistémica
del Software, 2das. Jornadas Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimiento (JIISIC
2002): 1-11.
62
La Norma UNE (Unificación de Normativas Españolas) 66-001-92 considera a la
calidad del software, como la totalidad de las características de un producto o servicio que le
confieren su aptitud para satisfacer unas necesidades expresadas o implícitas.
Del mismo modo, la calidad del software se define de otras maneras:
§ La totalidad de las funciones y características de un producto software que
influyen en su capacidad de satisfacer determinadas necesidades, por ejemplo,
el cumplimiento de las especificaciones.
§ El grado en el que el software posee una combinación de atributos deseada.
§ El grado en el que un cliente o usuario percibe que el software satisface sus
expectativas globales.
§ Aquellas características globales del software que determinan el grado en el que
el software que se está utilizando satisfará las expectativas del cliente.
El estándar IEEE (Institute of Electrical and Electronics Engineers) 729-83 dice que la
calidad del software puede ser entendida como el grado con el cual el usuario percibe que el
software satisface sus expectativas.
La definición según el estándar IEEE 610-1990 dice que la calidad del software es el
grado con el que un sistema, componente o proceso cumple los requerimientos especificados y
las necesidades o expectativas del cliente o usuario.
Se puede decir entonces que la calidad del software es el conjunto de cualidades que lo
caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad. Esto da lugar a que la obtención de un software con calidad implica que se deben
utilizar para ello metodologías o procedimientos estándares para el análisis, diseño,
programación y pruebas del software que permitan uniformar la filosofía de trabajo, con el fin
de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para las tareas de desarrollo como para el control de la calidad del
software84.
Uno de los conceptos más importantes que está muy vinculado a la calidad del
software, es el de “proceso”. Una definición simple es; un proceso es una serie de acciones
84 Lomprey, G. and S. Hernandez. La importancia de la calidad en el desarrollo de productos de software.
63
que conducen a un final. Esta definición parece coincidir con las ideas generales de la gente
sobre procesos85. Por otro lado, de acuerdo al vocabulario de la norma ISO 9000:200586, un
proceso es un conjunto de actividades mutuamente relacionadas o que interactúan, las cuales
transforman entradas en salidas. Kulpa y Johnson87 dicen que, un proceso es una serie de
pasos que ayudan a resolver un problema, los pasos deben ser definidos de tal forma que sean
inequívocos, es decir, fácilmente comprensible y que pueda ser seguido de manera coherente
por cualquier persona que utilice el proceso, Thomas H. Davenport88 dice que un proceso es
simplemente un conjunto de actividades mesurable y estructurado, diseñado para producir una
salida específica para un cliente o mercado en particular. Finalmente, la norma mexicana
NMX-I006/01-NYCE89 dice que un proceso es un conjunto de prácticas relacionadas entre sí,
llevadas a cabo a través de roles y por elementos automatizados, que utilizando recursos y a
partir de insumos producen un satisfactor de negocio para el cliente.
Ahora bien, la meta de la ingeniería de software es construir productos de software, o
mejorar los existentes, por lo tanto, en ingeniería de procesos, la meta es desarrollar procesos o
mejorar procesos existentes. Una definición de proceso de desarrollo de software dice que, es
un conjunto de actividades, métodos, prácticas y transformaciones que el personal usa para
desarrollar y mantener el software, y los productos asociados (planificación del proyecto,
diseño de documentos, código, casos de prueba, manuales de usuario, entre otros)90. Otra
definición nos dice que es un conjunto de personas, estructuras de organización, reglas,
políticas, actividades y sus procedimientos, componentes de software, metodologías, y
herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio,
innovar y extender un producto de software.
85 Ruvalcaba, M. 2004. Procesos de Software. Software Guru. 86 Sistemas de Gestión de Calidad. Fundamentos y Vocabulario. Norma NTC-ISO 9000:2005. 87 Kulpa, M. K. and K. A. Johnson. 2008. Interpreting the CMMI: a process improvement approach:19: Auerbach
Publications. 88 Davenport, T. H. 1993. Process Innovation: Reengineering work through Information Technology:5: Harvard
Business Press. 89 NMX-I-006-/01-NYCE. Normalización y Certificación Electrónica A. C. 90 Bedini, A. 2001. Extracto del libro en formato digital “Calidad Tradicional y de Software”: Universidad
Técnica Federico Santa María.
64
Implementar procesos de software efectivos en una organización tiene muchas
ventajas, ya que no solamente habilita a la organización a incrementar su productividad al
desarrollar software, si no también:
§ Permite estandarizar esfuerzos, promover reutilización, repetición y consistencia entre
proyectos.
§ Provee la oportunidad de introducir mejores prácticas de la industria.
§ Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
§ Establece la base para una mayor consistencia y mejoras futuras.
Un proceso de software también mejora los esfuerzos de mantenimiento y soporte:
§ Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
§ Define cómo lograr la transición del software a la operación, y cómo ejecutar los
esfuerzos de operación y soporte.
Se necesita de un proceso de software cuya funcionalidad esté probada en la práctica, y
personalizado para que cumpla con las necesidades específicas91.
Figura 3.1 Proceso de Software92
Los procesos de software están compuestos por varios elementos, los cuales se
muestran en la tabla 3.1.
Tabla 3.1 Elementos típicos del Proceso de Software
Elemento Descripción
Actividad Definen las acciones que se llevan a cabo en un momento dado del
desarrollo de software.
Flujo de trabajo Colección estructurada de actividades y elementos asociados
91 Ruvalcaba, M. 2004. Procesos de Software. Software Guru. 92 Elaboración con fuente de: Ruvalcaba, M. 2004. Procesos de Software. Software Guru.
65
(artefactos, roles), que producen un resultado de valor.
Rol Son responsables de llevar a cabo las actividades del proceso,
pueden ser personas o herramientas.
Producto o
Artefacto
Son las entradas y salidas de las actividades, pueden ser de diferentes
tipos, como documentos, modelos, componentes, planes, reportes,
etc.
Disciplina Conjunto integrado por actividades relativas a una rama particular de
conocimiento. Ejemplo, análisis y diseño.
Elaboración con fuente de: Ruvalcaba, Mara. 2004. Procesos de software. Software Guru.
Otro concepto importante dentro de la calidad de software es algo llamado, “gestión de la
calidad del software”. Esta gestión consiste en un conjunto de actividades que permiten dirigir
y controlar la organización en lo relativo a la calidad del software. La gestión de la calidad se
entiende en primera instancia, como el conjunto de actividades y medios necesarios para
definir e implantar un sistema de la calidad, y en segunda instancia, responsabilizarse de su
control, aseguramiento y mejora continua. En este sentido, la gestión de la calidad en
cualquier organización se centra en tres niveles de trabajo:
1. nivel de organización.
2. nivel de proyecto.
3. nivel de producto de software.
Para lograr una mejor gestión de la calidad de software se utilizan estándares (normas) y
modelos de calidad. Estos consisten en reunir todas las actividades y funciones de manera que
ninguna de ellas esté subordinada a las otras y que cada una se planee, se controle y se ejecute
de un modo formal y sistemático.
Los modelos de calidad son aquellos documentos que integran la mayor parte de las
mejores prácticas, proponen temas de administración en los que cada organización debe hacer
énfasis, integran diferentes prácticas dirigidas a los procesos clave y permiten medir los
avances en calidad. Los estándares de calidad son aquellos que permiten definir un conjunto
de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Los
estándares proporcionan los medios para que todos los procesos se realicen de la misma forma
y son una guía para lograr la productividad y la calidad. Los modelos y estándares de calidad
66
permiten que las organizaciones y las áreas encargadas de desarrollar software lleven a cabo
sus tareas y funciones teniendo en cuenta la calidad93.
Por lo tanto, el objetivo final de los modelos o estándares, es lograr una representación
clara de los procesos reales de desarrollo, con la cual poder trabajar para planificar las mejoras
a incluir en cada uno de esos procesos. Si la representación conceptual del proceso es buena,
los análisis de estos procesos sobre el papel permitirán a la empresa la posibilidad de
automatizarlos, controlar su eficiencia, comprobar las interacciones con otros procesos, y
ofrecer a la Dirección una nueva fuente de información, como puede ser la información actual
del estado de cada proceso en cualquier momento, el significado que debe darse a cada uno de
los puntos de decisión.
La mejora del producto final pasa, según estos modelos, por la mejora de los procesos
que llevan a su creación. La adopción del modelo o metodología adecuados podrá realizar esta
mejora con una correcta implantación, dotando implícitamente al producto final de una calidad
manifiesta94.
En la actualidad existe una gran variedad de modelos o estándares a nivel de proceso
para el desarrollo de software, y para entenderlos más fácilmente se pueden clasificar en dos
tipos: genéricos y específicos95, tal como se muestra en la tabla 3.2.
Tabla 3.2 Clasificación de los Modelos de Procesos
Modelos Genéricos Modelos Específicos
Abarcan todos los procesos relacionados con
el desarrollo de software
Están enfocados a la ingeniería de productos
de software
§ ISO 9000
§ ISO/IEC 15504
§ CMMI
§ MoProSoft
§ RUP (mencionado en la sección 2.1.8)
§ PSP
§ TSP
Nos dicen que debemos hacer (No el cómo). Nos dicen el cómo debemos hacer las cosas.
93 Scalone, F. 2006. Overview sobre Modelos/Estándares de Calidad del Software. Software Quality
Management. 94 INTECO. 2008. Estudio sobre la certificación de la calidad como medio para impulsar la industria de
desarrollo del software en España. 95 Ruvalcaba, M. 2004. Procesos de Software. Software Guru.
67
Se deben usar como referencia para definir
procesos en una organización y para
autoevaluación.
Es un medio para evaluar que tan bien o mal
esta la organización.
Se usan como guía para ejecutar proyectos.
Elaboración con fuente de: Ruvalcaba, Mara. 2004. Procesos de software. Software Guru.
Entre otros modelos o estándares a nivel de proceso se pueden mencionar también los
siguientes:
§ ITMark.
§ SwTQM
§ TickIT
§ ITIL
3.2 ISO 9000
ISO (International Organization for Standardization) 9000 es un conjunto de estándares
internacionales para sistemas de calidad. Diseñado para la gestión y aseguramiento de la
calidad, especifica los requisitos básicos para el desarrollo, producción, instalación y servicio
a nivel de sistema y a nivel de producto.
Las normas ISO 9000 son una serie de normas para el Aseguramiento de la Calidad,
que son aceptadas alrededor del mundo. Su importancia radica en que, cuando se adquiere un
producto o servicio de una empresa que está registrada en ISO 9000, se tiene la seguridad (alta
probabilidad) de que la calidad que se está recibiendo será como se esperaba. Permite contar
con la documentación de todas las actividades de la empresa, relativas a la calidad, por
escrito96. La ISO 9000: 2000 establece los requerimientos para la gestión de los sistemas de
calidad y está conformada por tres partes:
1. ISO 9000 Fundamentos y Vocabulario
2. ISO 9001 Requisitos
3. ISO 9004 Recomendaciones
La parte de Requisitos (ISO 9001:2000), está estructurado en 8 secciones:
1. Alcance 96 Mertens, L. and M. Baeza. La Norma ISO 9000 y la competencia laboral: México, OIT.
68
2. Normas para la consulta
3. Términos y Definiciones
4. Sistemas de Gestión de la Calidad
5. Responsabilidad de la Dirección
6. Gestión de los Recursos
7. Realización del Producto
8. Medidas, Análisis y Mejora
Aunque ISO 9001:2000 no otorga un estándar específico para los sistemas de
desarrollo de software, es decir, no abarca todos los procesos relacionados con el desarrollo de
software, varias organizaciones han optado por gestionar sus sistemas de calidad en base a esta
norma con la finalidad de obtener una certificación reconocida de manera internacional97.
3.3 ISO/IEC 15504
ISO/IEC 15504 (SPICE, Software Process Improvement and Capability dEtermination) es un
estándar internacional de evaluación y determinación de la capacidad y mejora continua de
procesos de ingeniería del software que ha emergido rápidamente y que tiene la filosofía de
desarrollar un conjunto de medidas de capacidad estructuradas para todos los procesos del
ciclo de vida y para todos los participantes. Es el resultado de un esfuerzo internacional de
trabajo y colaboración y tiene la innovación, en comparación con otros modelos, del proceso
paralelo de evaluación empírica del resultado.
ISO/IEC 15504 inicialmente absorbe la escala de puntuación de capacidad de CMM,
las actividades de proceso de ingeniería de ISO/IEC 12207, la representación de capacidad
basada en perfiles de atributos de BOOTSTRAP y la experiencia del sistema de gestión de la
calidad general de ISO 9001.
ISO/IEC desarrolla un modelo en dos dimensiones de evaluación de la capacidad del
proceso, donde se valora la organización de desarrollo software en la dimensión del proceso
contra los atributos del proceso en la dimensión de capacidad. La primera versión estructuraba
el modelo en nueve partes, pero en el curso de los debates y votaciones, en aras de reducir el
tamaño del estándar, se decide que se divida en cinco partes:
Parte 1. Conceptos y Vocabulario. 97 Ruvalcaba, M. 2004. Procesos de Software. Software Guru.
69
Parte 2. Realizando una Evaluación (Requisitos, normativa).
Parte 3. Guía para Realización de Evaluaciones.
Parte 4. Guía para el Uso de Resultados de Evaluaciones.
Parte 5. Un Modelo de Evaluación de Procesos Ejemplar.
La versión 1.0 inicialmente recogía treinta y cinco procesos agrupados en cinco
categorías (Cliente-Proveedor, Ingeniería, Proyecto, Soporte y Organización). Sin embargo, la
idea de expandir el ámbito de aplicación del estándar evitando restringirlo a un determinado
ciclo de vida, la compatibilidad con ISO/IEC 12207 e ISO/IEC 15288 y con cualquier modelo
posterior, permite la evolución del estándar para aceptar Modelos de Referencia de Procesos
(PRM’s) eliminando la inicial dimensión de procesos. La medida de capacidad mostrada en la
tabla, es aplicable a cualquier modelo de procesos plasmado en un PRM compatible con ISO
12207. Esto le confiere una infraestructura mucho más abierta, facilitando la compatibilidad98.
Tabla 3.3 Modelo de Capacidad de Procesos
Id. Nivel de
Capacidad
Atributos de Proceso y Descripción
CL[0] Incompleto El proceso no está implementado o falla en alcanzar su propósito.
No es fácil identificar los productos o salidas de los procesos.
CL[1]
Realizado El propósito del proceso se logra generalmente, aunque no sea
rigurosamente planificado ni llevado a cabo. Hay productos
identificables que testifican el alcance del propósito.
PA.1.1 Realización del Proceso.
CL[2] Gestionado El proceso es gestionado y los entregables resultado de
procedimientos específicos, planificados y seguidos, con
requisitos de calidad, tiempo y recursos.
PA.2.1
PA.2.2
Gestión de la Realización.
Gestión de los Productos del trabajo.
CL[3] Establecido Un proceso realizado y gestionado usando un proceso definido,
98 De la Villa, M., M. Ruiz, and I. Ramos. 2004. Modelos de evaluación y mejora de procesos: Análisis
comparativo.
70
basado en un principio de buenas prácticas de ingeniería del
software.
PA.3.1
PA.3.2
Definición del Proceso.
Despliegue del Proceso.
CL[4] Predecible El proceso definido es puesto consistentemente en práctica dentro
de límites de control establecidos para alcanzar metas del proceso
ya definidas. Entendimiento cuantitativo de la capacidad del
proceso y habilidad mejorada de predecir y gestionar el
rendimiento.
PA.4.1
PA.4.2
Medición del Proceso.
Control del Proceso.
CL[5] En optimización
Realización del proceso optimizada en la búsqueda de las
necesidades actuales y futuras del negocio. Objetivos
cuantitativos de eficiencia y efectividad se establecen en función
de los objetivos de la organización. Optimización puede llevar a
estudiar y adoptar ideas innovadoras o productos tecnológicos
novedosos que incluyan y modifiquen el proceso definido.
PA.5.1
PA.5.2
Innovación del Proceso.
Optimización del proceso.
Elaboración con fuente de: De la Villa, M., M. Ruiz, and I. Ramos. 2004. Modelos de
evaluación y mejora de procesos: Análisis comparativo.
3.4 SW-CMM
CMM es el acrónimo de Modelo de Madurez de Capacidades (Capability Maturity Model).
SW-CMM o CMM para Software surgió del departamento de defensa de los Estados Unidos
por la necesidad que se tenía de poder ser capaces de predecir el desempeño de su personal
contratista que desarrollaba el software. El desarrollo de un esquema de madurez de procesos
se inició a mediados de la década de los ochentas en el SEI. En 1987 se publicó por primera
vez una descripción inicial de este esquema y un cuestionario que permitía evaluar su madurez
(ver concepto de madurez en el punto 3.5). Después de varios años de experiencia con esta
71
descripción inicial y el cuestionario conllevó a la publicación en 1991 de modelo CMM para
Software versión 1.0, un marco de trabajo que describe los elementos clave de un proceso de
software efectivo. El CMM no es un modelo teórico sino que se basa en el desempeño real de
las prácticas exitosas de desarrollo de software.
El modelo CMM es un modelo escalonado que define 5 niveles de madurez de
proceso, tal como se muestra en la tabla 3.4.
Tabla 3.4 Niveles de Madurez de CMM
Nivel de Madurez Descripción
1. Inicial El proceso de software es caracterizado como impredecible y
ocasionalmente caótico. Están definidos algunos procesos y su éxito
depende del esfuerzo individual.
2. Repetible Se han establecido los procesos básicos para la administración de
proyectos, con la finalidad de darle seguimiento a los costos,
programación y funcionalidad para que de esta manera se puedan
repetir prácticas exitosas de otros proyectos.
3. Definido El proceso de software tanto para la gestión como para las
actividades de ingeniería se documenta, estandariza y se integra
dentro de un proceso de software estándar para la organización.
4. Administrado Se recogen medidas detalladas del proceso de software y calidad del
producto. Tanto el proceso de software y los productos son
cuantitativamente entendidos y controlados.
5. Optimizado La mejora continua de los procesos está habilitada por la
retroalimentación cuantitativa del proceso y del pilotaje de ideas y
tecnologías innovadoras.
Elaboración con fuente de: Mutafelija, B. and H. Stromberg. 2003. Systematic Process
Improvement using ISO 9001: 2000 and CMMI:35-39: Artech House on Demand.
72
Además, cada nivel de madurez incluye un número de áreas de proceso clave (KPAs
por sus siglas en ingles) y objetivos asociados a esta área. Los KPAs en cada nivel de madurez
se muestran en la figura 3.299.
Inicial (Nivel 1)
Optimizado (Nivel 5)Administración de cambios de procesosAdministración de cambio de tecnologíaPrevención de defectos
Administrado (Nivel 4)
Administración de la calidad del softwareAdministración de procesos cuantitativa
Definido (Nivel 3)Revisión entre colegasIngeniería de productos de softwareAdministración integral de software Programa de capacitaciónCoordinación intergrupalDefinición de los procesos de la organizaciónEnfoque en procesos de la organización
Repetible (Nivel 2)Administración de la configuración del softwareAseguramiento de la calidadAdministración de subcontratos de softwareSeguimiento y control del proyecto de softwarePlanificación del proyecto de softwareAdministración de requerimientos
Figura 3.2 Niveles de Madurez con KPAs de CMM100
3.5 CMMI
CMMI es en acrónimo de Modelo Integrado de Madurez y Capacidades (Capability Maturity
Model Integration). Algunos dicen que CMMI es un modelo, otros lo describen como un
conjunto de modelos, pero la mayoría está de acuerdo en que CMMI es una fusión de modelos
de mejora de procesos para la ingeniería de sistemas, la ingeniería de software, ingeniería de
hardware y de equipos de trabajo integrados. Algunos de los objetivos de CMMI son,
proporcionar un lenguaje común dentro de todo este conjunto de modelos y de cómo están las
áreas interrelacionadas101.
99 Mutafelija, B. and H. Stromberg. 2003. Systematic process improvement using ISO 9001: 2000 and CMMI:35-
39: Artech House on Demand. 100 Elaboración con fuente de: Mutafelija, B. and H. Stromberg. 2003. Systematic process improvement using
ISO 9001: 2000 and CMMI:35-39: Artech House on Demand. 101 Kulpa, M. K. and K. A. Johnson. 2008. Interpreting the CMMI: a process improvement approach:3: Auerbach
Publications.
73
Antes de revisar este modelo es importante revisar algunos conceptos para poder
entenderlo. El primero de ellos es el concepto de “Madurez”. Madurez es el atributo de las
organizaciones que desarrollan o mantienen los sistemas de software. En la medida que éstas
llevan a cabo su trabajo siguiendo procesos, y en la que éstos se encuentran homogéneamente
implantados, definidos con mayor o menor rigor; conocidos y ejecutados por todos los equipos
de la empresa; y medidos y mejorados de forma constante, las organizaciones serán más o
menos “maduras”. Otro concepto es el de “Capacidad”. Capacidad es un atributo de los
procesos. El nivel de capacidad de un proceso indica si sólo se ejecuta, o si también se
planifica, se encuentra organizativamente y formalmente definido, se mide y se mejora de
forma sistemática.
En CMMI se definen seis niveles para medir la capacidad de los procesos, por esta
razón son llamados niveles de capacidad, y se muestran en la tabla 3.5.
Tabla 3.5 Niveles de Capacidad de CMMI
Nivel de Capacidad Descripción
0. Incompleto El proceso no se realiza, o no se consiguen sus objetivos.
1. Ejecutado El proceso se ejecuta y se logra su objetivo.
2. Gestionado Además de ejecutarse, el proceso se planifica, se revisa y se evalúa
para comprobar que cumple los requisitos.
3. Definido Además de ser un proceso “gestionado” se ajusta a la política de
procesos que existe en la organización, alineada con las directivas de
la empresa.
4. Cuantitativamente
Gestionado
Además de ser un proceso definido se controla utilizando técnicas
cuantitativas.
5. Optimizado Además de ser un proceso cuantitativamente gestionado, de forma
sistemática se revisa y modifica para adaptarlo a los objetivos del
negocio.
Elaboración con fuente de: Palacio, Juan. 2006. Sinopsis de los modelos SW-CMM y CMMI.
Por otra parte CMMI define 5 Niveles de Madurez de los procesos, que son los mismos
que se describen en SW-CMM, a diferencia que se le han hecho revisiones a los nombres a los
niveles 2 y 4.
Nivel 1: Inicial
74
Nivel 2: Gestionado
Nivel 3: Definido
Nivel 4: Gestionado cuantitativamente
Nivel 5: Optimizado
Cabe mencionar que los modelos de calidad que centran su foco en la madurez de la
organización, presentan un modelo de mejora y evaluación “escalonado”. Los que enfocan las
actividades de mejora y evaluación en la capacidad de los diferentes procesos presentan un
modelo “continuo”. CMMI nació integrando tres modelos diferentes, con representaciones
diferentes:
SW-CMM: representación escalonada.
SE-CMM: representación continua.
IPD-CMM: modelo mixto.
Esto dio lugar a que el modelo CMMI se publicara con dos representaciones:
§ Representación Continua (Continuous Representation), figura 3.3
§ Representación Escalonada (Staged Representation), figura 3.4.
Figura 3.3 Representación Continua de CMMI102
102 Elaboración con fuente de: Palacio, Juan. 2006. Sinopsis de los modelos SW-CMM y CMMI.
75
Nivel de Madurez 1
Área de Proceso 1 Área de Proceso 2 Área de Proceso n
Objetivos GenéricosObjetivos Específicos
Prácticas Específicas Prácticas Genéricas
Nivel de Madurez nNivel de Madurez 2 . . .
. . .
Figura 3.4 Representación Escalonada de CMMI103
Estas dos representaciones son equivalentes, y cada organización puede seleccionar la
que mejor se adapte a sus características y prioridades de mejora. Por una parte la visión
continua de una organización mostrará la representación de nivel de capacidad de cada una de
las áreas de proceso del modelo, mientras que la visión escalonada definirá a la organización
dándole en su conjunto un nivel de madurez del 1 al 5.
CMMI identifica 25 áreas de procesos, que son mostradas en la tabla 3.6. Las áreas de
proceso son un conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para
conseguir un conjunto de objetivos. Si las áreas de proceso son vistas desde la Representación
Continua del modelo, se agrupan en 4 categorías según su finalidad:
1. Gestión de proyectos
2. Ingeniería
3. Gestión de procesos
4. Soporte (a las otras categorías)
Por lo contrario, si son vistas desde la Representación Escalonada, se clasifican en los
5 niveles de madurez. Al nivel de madurez 2 pertenecen las áreas de proceso cuyos objetivos
debe lograr la organización para alcanzarlo, con el nivel 3, 4 y 5.
Tabla 3.6 Áreas de Proceso de CMMI
Áreas de proceso Categoría Nivel de Madurez
103 Elaboración con fuente de: Palacio, Juan. 2006. Sinopsis de los modelos SW-CMM y CMMI.
76
Análisis y resolución de problemas
Gestión de la configuración
Análisis y resolución de decisiones
Gestión integral de proyecto
Gestión integral de proveedores
Gestión de equipos
Medición y análisis
Entorno organizativo para integración
Innovación y desarrollo
Definición de procesos
Procesos orientados a la organización
Rendimiento de los procesos de la org.
Formación
Integración de producto
Monitorización y control de proyecto
Planificación de proyecto
Gestión calidad procesos y productos
Gestión cuantitativa de proyectos
Desarrollo de requisitos
Gestión de requisitos
Gestión de riesgos
Gestión y acuerdo con proveedores
Solución técnica
Validación
Verificación
Soporte
Soporte
Soporte
Gestión de Proyectos
Gestión de Proyectos
Gestión de Proyectos
Soporte
Soporte
Gestión de Procesos
Gestión de Procesos
Gestión de Procesos
Gestión de Procesos
Gestión de Procesos
Ingeniería
Gestión de Proyectos
Gestión de Proyectos
Soporte
Gestión de Proyectos
Ingeniería
Ingeniería
Gestión de Proyectos
Gestión de Proyectos
Ingeniería
Ingeniería
Ingeniería
5
2
3
3
3
3
2
3
5
3
3
4
3
3
2
2
2
4
3
2
3
2
3
3
3
Elaboración con fuente de: Palacio, Juan. 2006. Sinopsis de los modelos SW-CMM y CMMI.
CMMI tiene además varios componentes. Estos componentes son; las áreas de proceso,
los componentes requeridos, los componentes esperados y los componentes informativos.
Dentro de los componentes requeridos se encuentran los objetivos genéricos y los
objetivos específicos. Los objetivos genéricos asociados a un nivel de capacidad establecen lo
que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos
77
objetivos en un área de proceso significa mejorar el control en la ejecución del área de
proceso. Los objetivos específicos se aplican a una única área de proceso y localizan las
particularidades que describen que se debe implementar para satisfacer el propósito del área de
proceso.
Dentro de los componentes esperados se encuentran las prácticas genéricas y las
prácticas específicas. Una práctica genérica se aplica a cualquier área de proceso porque puede
mejorar el funcionamiento y el control de cualquier proceso y una práctica específica es una
actividad que se considera importante en la realización del objetivo específico al cual está
asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta
específica de un área de proceso.
Y finalmente dentro de los componentes informativos se encuentran los siguientes:
§ Propósito
§ Notas introductorias
§ Referencias
§ Nombres
§ Tablas de relaciones práctica – objetivo
§ Prácticas
§ Productos típicos
§ Sub-prácticas
§ Ampliaciones de disciplina
§ Elaboraciones de prácticas genéricas104
CMMI se centra en la institucionalización. Los objetivos no pueden ser alcanzados sin
probar la institucionalización de los procesos. Los objetivos y prácticas genéricas apoyan la
institucionalización y la sofisticación incremental de los procesos. Los objetivos y prácticas
específicas sirven a la implementación del área de proceso. La Capacidad y Madurez de los
Procesos evoluciona. La mejora de procesos y la capacidad se construyen en etapas o
escenarios porque algunos procesos son ineficaces cuando otros no son estables. Por lo tanto,
no importa qué representación del CMMI se use, cada uno tiene niveles. Dentro de cada nivel
están los objetivos genéricos relacionados a todas las áreas de proceso en el que el nivel y
104 Palacio, J. 2006. Sinopsis de los modelos SW-CMM y CMMI.
78
objetivos específicos se relacionan únicamente a un área de proceso específico. Los objetivos
tienen prácticas asociadas con ellos. Las prácticas están asociadas con un solo objetivo105.
3.6 Otros modelos
IT Mark. El modelo IT Mark fue diseñado por el Instituto de Software Europeo (European
Software Institute, ESI). IT Mark evalúa y acredita la calidad de la empresa en tres grandes
áreas:
1. Área relacionada con la gestión general de la empresa (estratégica, comercial,
financiera y de marketing)
2. Área relacionada con la seguridad de la información
3. Área vinculada a la madurez de sus procesos software.
En los temas relativos a gestión se toma como referencia el modelo 10-Squared
(modelo utilizado para la evaluación de solicitudes de financiación a capital riesgo). Desde el
punto de vista de la seguridad se emplea el estándar ISO 17799 (denominada también como
ISO 27002, es un estándar para la seguridad de la información), en tanto que en el área
específica de software se incorpora una versión simplificada de CMMI.
SwTQM (Software Total Quality Management). La iniciativa SwTQM parte de la
Fundación Europea para la Gestión de la Calidad (European Foundation for Quality
Management, EFQM), fundación sin ánimo de lucro con sede en Bruselas que reúne a 700
organizaciones interesadas en la consecución de la excelencia a través de la calidad de sus
procesos, y el Instituto de Software Europeo, como modelo de excelencia para organizaciones
que desarrollan software de forma intensiva. La base principal del modelo es CMMI v1.1, y se
complementa con el modelo de excelencia de la Fundación Europea para la Gestión de la
Calidad.
El modelo se destina, según la información publicada por el Instituto de Software Europeo, a:
§ Organizaciones cuyo negocio principal es el desarrollo de sistemas de información
comerciales.
§ Organizaciones cuyo departamento de TI desarrolla software como parte integrante de
los productos finales de la organización.
105 Kulpa, M. K. and K. A. Johnson. 2008. Interpreting the CMMI: a process improvement approach:31-40:
Auerbach Publications.
79
§ Organizaciones cuyo departamento de TI desarrolla sistemas de información para la
mejora de sus procesos de negocio.
§ Departamentos o áreas de sistemas de información de grandes organizaciones que
trabajan como unidades de negocio independientes.
TickIT. En 1991, el Consejo Nacional de Acreditación de los Organismos de Certificación
(National Accreditation Council of Certification Bodies, NACCB), introdujo en el Reino
Unido el programa TickIT como respuesta a las quejas emitidas por las empresas dedicadas a
la elaboración de software con respecto a la calidad y consistencia de las evaluaciones para la
certificación ante la norma ISO 9001. El objetivo del programa TickIT era ayudar a las
organizaciones de software a crear sistemas de calidad que agregaran valor a sus empresas y
que cumplieran con la norma ISO 9001. Ha sido aprobada como norma por el Servicio de
Acreditacion del Reino Unido (United Kingdom Accreditation Service, UKAS) y el Consejo
Sueco para le Evaluación y Acreditación de la Conformidad (Swedish Board for Accreditation
and Conformity Assessment, SWEDAC).
En términos generales al proceso de desarrollo de software se adoptan normalmente los
siguientes elementos del modelo:
§ Análisis y especificación de los requerimientos del sistema de información asegurando
que sean revisados y acordados con el cliente.
§ Planificación, control y supervisión del avance del desarrollo respecto al plan
comunicando a las partes afectadas y que avise oportunamente de los problemas
potenciales.
ITIL (IT Infrastructure Library). ITIL es un marco de trabajo para la administración de
procesos de TI en una organización. Desarrollado en su primera versión a fines de la década
de los 80 por la Oficina de Comercio Gubernamental (Office of Government Commerce,
OGC), se ha convertido en un estándar de facto para servicios de TI.
La versión 3 de ITIL, (que consta de cinco libros principales y diversos suplementos
complementarios, cada uno de los cuales aportan guías para afrontar y resolver retos
específicos) se centra en el ciclo de vida de los servicios, y gira alrededor de conceptos como
estrategia, diseño, transición, operación y mejora continua del servicio. Siguiendo un esquema
de círculos concéntricos, en el nivel exterior se ofrece información que ayuda a los
80
departamentos de TI a adaptar el despliegue de los principios centrales de ITIL a las
condiciones económicas y estrategias organizativas de cada empresa.
PSP (Personal Software Proccess). El Proceso Personal de Software (PSP) fue propuesto
por Watts Humphrey (perteneciente al SEI) en 1995 y estaba dirigido a estudiantes. A partir de
1997, con el lanzamiento del libro "An introduction to the Personal Software Process", se
dirige ahora a ingenieros principiantes.
PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual y su
meta es la producción de software de calidad. PSP se diseñó para enseñar a profesionales a
cómo planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y
medido, a establecer metas mesurables, y a la utilización del rastreo constante para alcanzar
dichas metas106.
TSP (Team Software Process). TSP es un conjunto de procesos estructurados que indican
que hacer en cada fase del desarrollo de un proyecto y muestra cómo conectar cada fase para
construir un producto completo.
Sus objetivos principales son:
§ Integrar equipos independientes de alto rendimiento que planeen y registren su trabajo,
establezcan metas, y sean dueños de sus procesos y planes.
§ Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como
ayudarlos a alcanzar su máxima productividad.
§ Acelerar la mejora continua de procesos.
§ Proporcionar una guía para el mejoramiento en organizaciones maduras.
TSP tienen 4 fases principales:
1. Requerimientos
2. Diseño
3. Implementación
4. Pruebas
Cada fase comienza con un lanzamiento (launch) o relanzamiento (relaunch.). Además que
los proyectos de TSP pueden comenzar o terminar en cualquier fase. TSP muestra a los
equipos de trabajo, como aplicar conceptos de equipo para el desarrollo de sistemas de 106 INTECO. 2008. Estudio sobre la certificación de la calidad como medio para impulsar la industria de
desarrollo del software en España.
81
software. Este conduce a los equipos a tener administración total en los procesos basándose en
Características y Objetivos, Definición de Roles en el Equipo, Evaluación de Riesgos y
Producción de un plan completo de actividades. Seguido del lanzamiento, TSP provee un
marco de desarrollo totalmente mesurable y manejable, donde el seguimiento y reporte de
avance sea natural. En conclusión que el administrador de proyecto, conozca a detalle en
cualquier momento que es lo que el equipo está realizando o las actividades por realizar107.
3.7 MoProSoft
El 92% del total de las industrias de software en México cuentan con menos de 100 personas,
por lo consiguiente, la mayoría de las veces resulta difícil llevar a cabo la mejora de procesos
de software108. Por esta razón en el año 2002 el gobierno mexicano implementó el Programa
para el Desarrollo de la Industria de Software a través de la Secretaría de Economía. El
objetivo fundamental de ProSoft es elevar y extender la competitividad del país, mediante la
estrategia de promover el uso y aprovechamiento de la tecnología y de la información. A
través de ProSoft, México se ha propuesto las siguientes metas en relación a la industria de
software:
1. Lograr una producción anual de software y servicios relacionados por un valor de
5,000 millones de dólares.
2. Alcanzar el promedio mundial de gasto en tecnologías de información (actualmente
nuestro país gasta el 1.4% del PIB en TI, mientras que el promedio mundial es de
4.3%).
3. Convertirse en el líder latinoamericano de soporte y servicios basados en tecnologías
de información.
Para conseguir estas metas, se definieron las siguientes estrategias:
1. Promover exportaciones y atraer inversiones
2. Crear programas de educación y formación de personal competente
3. Contar con un marco legal promotor de la industria
107 Hernández, D., H. Gutiérrez, and G. Canedo. Creación de equipos de alto desempeño, usando Team, Software
Process (TSP) y Personal Software Process (PSP). Universidad de Guanajuato. 108 Oktaba, H. and M. Piattini. 2008. Software Process Improvement for Small and Medium Enterprises:
Techniques and Case Studies:170-171: Information Science Reference.
82
4. Desarrollar el mercado interno
5. Fortalecer a la industria local
6. Alcanzar niveles internacionales en capacidad de procesos
7. Promover la construcción de infraestructura física y de telecomunicaciones
De estas estrategias, es de particular importancia la número 6, la cual contiene los
siguientes puntos:
6.1 Definición de un modelo de procesos y de evaluación apropiado para la industria de
software mexicana.
6.2 Formación de instituciones de capacitación y asesoría en mejora de procesos.
6.3 Apoyo financiero para la capacitación y la evaluación de capacidad de procesos.
En el punto 6.1, ProSoft estableció que para alcanzar esta estrategia, el gobierno mexicano
debía darse a la tarea de construir un modelo de mejoras aplicable a México, lo que dio origen
a MoProSoft (Modelo de Procesos de Desarrollo de Software).
El objetivo principal de MoProSoft es incorporar las mejores prácticas en gestión e
ingeniería de software. Su incorporación en la industria eventualmente permitirá elevar la
capacidad de ofrecer productos y servicios de software con calidad. MoProSoft fue
desarrollado por expertos mexicanos que recopilaron las experiencias exitosas de la industria
de software a nivel mundial, y las adaptaron a las necesidades y características de las pequeñas
y medianas industrias mexicanas desarrolladoras de software109.
3.7.1 Estructura
MoProSoft tiene tres categorías de procesos: Alta Dirección, Gerencia y Operación que
reflejan la estructura de una organización.
La categoría de Alta Dirección aborda las prácticas de Alta Dirección relacionadas con
la gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de
Gerencia y se retroalimenta con la información generada por ellos y contiene el proceso de
Gestión de Negocio.
La categoría de Gerencia aborda las prácticas de gestión de procesos, proyectos y
recursos en función de los lineamientos establecidos en la Categoría de Alta Dirección.
109 Pilar, G. G. 2007. Moprosoft: Un camino hacia el éxito mundial en el desarrollo de software mexicano.
Software Engineering Process Improvement.
83
Proporciona los elementos para el funcionamiento de los procesos de la Categoría de
Operación, recibe y evalúa la información generada por éstos y comunica los resultados a la
Categoría de Alta Dirección y está integrada por los procesos de Gestión de Procesos, Gestión
de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de
Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y
Conocimiento de la Organización.
La Categoría de Operación aborda las prácticas de los proyectos de desarrollo y
mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los elementos
proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos
generados y está integrada por los procesos de Administración de Proyectos Específicos y de
Desarrollo y Mantenimiento de Software. La tabla 3.7 y la figura 3.5 muestran la categoría de
procesos y los procesos de MoProSoft y la figura 3.6 muestra la relación entre los procesos.
Tabla 3.7 Categoría de procesos y Procesos de MoProSoft
CATEGORÍA PROCESO PROPÓSITO
ALTA
DIRECCIÓN
(DIR)
Gestión de Negocio
(GN)
Establecer la razón de ser de la organización, sus
objetivos y las condiciones para lograrlos, para lo
cual es necesario considerar las necesidades de los
clientes, así como evaluar los resultados para
poder proponer cambios que permitan la mejora
continua. Adicionalmente habilita a la
organización para responder a un ambiente de
cambio y a sus miembros para trabajar en función
de los objetivos establecidos.
GERENCIA
(GER)
Gestión de Procesos
(GPR)
Establecer los procesos de la organización, en
función de los procesos requeridos identificados
en el plan estratégico. Así como definir, planificar,
e implantar las actividades de mejora en los
mismos.
Gestión de Proyectos
(GPY)
Asegurar que los proyectos contribuyan al
cumplimiento de los objetivos y estrategias de la
84
organización.
Gestión de Recursos
(GR)
Conseguir y dotar a la organización de los
recursos humanos, infraestructura, ambiente de
trabajo y proveedores, así como crear y mantener
la base de conocimiento de la organización. La
finalidad es apoyar el cumplimiento de los
objetivos del plan estratégico de la organización.
Recursos Humanos y
Ambiente de Trabajo
(RHAT)
Proporcionar los recursos humanos adecuados
para cumplir las responsabilidades asignadas a los
roles dentro de la organización, así como la
evaluación del ambiente de trabajo.
Bienes, Servicios e
Infraestructura
(BSI)
Proporcionar proveedores de bienes, servicios e
infraestructura que satisfagan los requisitos de
adquisición de los procesos y proyectos.
Conocimiento de la
Organización
(CO)
Mantener disponible y administrar la base de
conocimiento que contiene la información y los
productos generados por la organización.
OPERACIÓN
(OPE)
Administración de
Proyectos Específicos
(APE)
Es establecer y llevar a cabo sistemáticamente las
actividades que permitan cumplir con los objetivos
de un proyecto en tiempo y costo esperados.
Desarrollo y
Mantenimiento de
Software
(DMS)
La realización sistemática de las actividades de
análisis, diseño, construcción, integración y
pruebas de productos de software nuevos o
modificados cumpliendo con los requerimientos
especificados.
Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-
MoProSoft-Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
85
Figura 3.5 Diagrama de Categoría de Procesos de MoProSoft110
Figura 3.6 Diagrama de Relación entre Procesos111
110 Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-MoProSoft-Versión
1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
86
3.7.2 Roles
En cada proceso están definidos los roles responsables por la ejecución de las prácticas.
Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación
para desempeñarlos. En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de
Proceso y otros roles involucrados. Además se considera al Cliente y al Usuario como roles
externos a la organización.
Tabla 3.8 Roles de MoProSoft
Rol Descripción
Cliente Es el que solicita un producto de software y financia el proyecto para su
desarrollo o mantenimiento.
Usuario Es el que va a utilizar el producto de software.
Grupo Directivo Son los que dirigen a una organización y son responsables por su
funcionamiento exitoso.
Responsable de
Proceso
Es el encargado de la realización de las prácticas de un proceso y del
cumplimiento de sus objetivos
Involucrado
Otros roles con habilidades requeridas para la ejecución de actividades o
tareas específicas. Por ejemplo: Analista, Programador, Revisor, entre
otros.
Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-
MoProSoft-Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
Figura 3.7 Clasificación General de Roles
111 Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-MoProSoft-Versión
1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
87
3.7.3 Productos
Producto de Software
Es el producto que se genera en el proceso de Desarrollo y Mantenimiento de Software. Los
productos de software se clasifican de manera general como Especificación de
Requerimientos, Análisis y Diseño, Software, Prueba, Registro de Rastreo y Manual. Esta
clasificación puede ser especializada según las necesidades, por ejemplo, Prueba puede
significar Plan de Pruebas o Reporte de Pruebas, Manual puede ser especializado en Manual
de Usuario, Manual de Operación o Manual de Mantenimiento, mientras que el Software
puede ser un Componente, un Sistema de componentes o un Sistema compuesto de sistemas.
Configuración de Software
Es un conjunto consistente de productos de software. Configuración de software
Producto de software
Especificación de requerimientos Prueba Manual
Análisis y Diseño SoftwareRegistro de rastreo
Componente Sistema
11..*
Figura 3.8 Configuración y Productos de Software112
Tabla 3.9 Productos
Producto Descripción
Plan
Programa detallado de las actividades, responsables por realizarlas y
calendario.
Reporte
Informe del resultado de las actividades realizadas.
112 Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-MoProSoft-Versión
1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
88
Registro
Evidencia de actividades desempeñadas.
Lección Aprendida
Experiencia positiva o negativa obtenida durante la realización de
alguna actividad.
Otro Producto
Producto, distinto a los anteriores, que también es generado en los
procesos. Por ejemplo: Contrato, Propuestas Tecnológicas,
Documentación de Procesos, entre otros113.
Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-
MoProSoft-Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
Figura 3.9 Clasificación general de productos114
3.7.4 Normatividad de MoProSoft
Una de las normas que está basada en el modelo MoProSoft, es la norma mexicana NMX-I-
059-NYCE. Esta norma consta de cuatro partes:
1. La NMX-I-059/01-NYCE: Definición de Conceptos y productos. Contiene los
conceptos y descripciones de productos usados en las otras partes de la norma.
113 Oktaba, H. Modelo de Procesos para la Industria de Software-MoproSoft-Versión 1.3, Agosto de 2005. NMX-
059/01-NYCE-2005. 114 Elaboración con fuente de: Oktaba, H. Modelo de Procesos para la Industria de Software-MoProSoft-Versión
1.3, Agosto de 2005. NMX-059/01-NYCE-2005.
89
2. La NMX-I-059/02-NYCE: Requisitos de procesos (MoProSoft). Establece los
requisitos de los procesos a implantar en la organización a través del modelo de
procesos, MoProSoft.
3. La NMX-I-059/03-NYCE: Guía de implantación de procesos. Contiene una
propuesta práctica de implantación de MoProSoft descrito en la parte 02.
4. La NMX-I-059/04-NYCE: Directrices para la evaluación de procesos
(EvalProSoft). Esta parte hace uso de la norma NMX-I-059/02-NYCE y del capítulo 5
de la NMX-I-006/02-NYCE para obtener un perfil de nivel de capacidad de los
procesos implantados en una organización y un nivel de madurez de capacidades.
La NMX-I-059/01-NYCE (parte01) tiene por objeto definir los conceptos y describir los
productos para las demás partes de la norma, con la finalidad de que los usuarios se
familiaricen con la terminología y estructura de las cuatro partes que constituyen la norma.
Los conceptos se presentan en orden alfabético y están definidos en el punto 3.1, por
ejemplo:
3.1.1 Actividad
Conjunto de tareas especificas asignadas para su realización a uno o
más roles.
La descripción de los productos se encuentra en el punto 3.2, por ejemplo:
3.2.23 Manual de usuario
Documento electrónico o impreso que describe la forma de uso del
software con base a la interfaz de usuario. Este deberá ser redactado en
términos comprensibles a los usuarios.
En el punto 4 se describen los productos de cada proceso. Se enlistan las entradas, las
salidas y el proceso destino, por ejemplo:
4.8 Administración de proyectos específicos
4.8.1 Entradas
Nombre Fuente
Reporte de actividades Desarrollo y Mantenimiento de
Software
4.8.2 Salidas
90
Nombre Fuente
Documento de aceptación Gestión de Proyectos
La parte 01 de la norma coincide parcialmente con la Norma Internacional ISO/IEC
15504-1: 2004 Concepts and Vocabulary, en lo relativo a las definiciones115.
La NMX-I-059/02-NYCE (parte02) tiene por objetivo definir el modelo de procesos
para la industria del software. Ya que MoProSoft está dirigido a las organizaciones dedicadas
al desarrollo y mantenimiento de software. Es aplicable tanto para las organizaciones que
tienen procesos establecidos, así como para las que no cuentan con ellos.
MoProSoft cuenta con nueve procesos (que fueron mencionados en el capitulo 3.7.1 de
este documento) distribuidos en tres categorías y son presentados en el siguiente orden a partir
del punto 3 de la norma, ver tabla 3.10.
Tabla 3.10 Procesos de MoProSoft
3. CATEGORIA DE ALTA DIRECCION (DIR) 3.1 Gestión de Negocio
4. CATEGORIA DE GERENCIA (GER) 4.1 Gestión de Procesos
4.2 Gestión de Proyectos
4.3 Gestión de Recursos
4.4 Recursos Humanos y Ambiente
de Trabajo
4.5 Bienes, Servicios e
Infraestructura
4.6 Conocimiento de la
organización
5. CATEGORIA DE OPERACIÓN (OPE) 5.1 Administración de Proyectos
Específicos
5.2 Desarrollo y Mantenimiento de
Software
Cada uno de los nueve procesos tiene cinco elementos normativos, los cuales son:
1. Proceso
115 NMX-I-059-/01-NYCE-2005. Normalización y Certificación Electrónica A. C.
91
2. Categoría
3. Propósito
4. Objetivos
5. Actividades
Por ejemplo:
5 CATEGORIA DE OPERACIÓN (OPE)
5.1 Administración de Proyectos Específicos
5.1.1 Proceso
OPE.1 Administración de Proyectos Específicos
5.1.2 Categoría
Operación (OPE)
5.1.3 Propósito
El propósito de la Administración de Proyectos Específicos es
establecer y llevar a cabo sistemáticamente las actividades que
permitan cumplir con los objetivos de un proyecto en tiempo y costo
esperados.
5.1.4 Objetivos
O1 Lograr los objetivos del proyecto en tiempo y costo mediante la
coordinación y el manejo de recursos del mismo
O2 Mantener informado al cliente mediante la realización de reuniones
de avance del proyecto
O3 Atender las solicitudes de cambio del cliente mediante la recepción
y análisis de las mismas
5.1.5 Actividades
A1.(O1) Planificacion…
La parte 02 de la norma también cuenta con un apéndice, el cual tiene como propósito
establecer los criterios para la asignación de niveles de capacidad de procesos y el nivel de
madurez de capacidades de la organización. El apéndice está estructurado de la siguiente
forma:
§ Cada capítulo corresponde a un nivel de capacidad.
92
§ Al inicio de cada capítulo se indica el nivel de capacidad y sus atributos de proceso
(A.P.). Después se enlistan los productos de trabajo y las prácticas base esperadas por
cada uno de los nueve procesos.
§ Para cada producto de trabajo se utiliza la notación PR.An.PTm, siendo PR la clave del
proceso, An la actividad número n y PTm es el producto de trabajo número m.
Por ejemplo;
Nivel 1 Proceso Realizado
A.12 Proceso: Desarrollo y Mantenimiento de Software
A.12.1 Productos de trabajo esperados
DMS.A2.PT1 Especificación de Requisitos 1. Introducción
2. Funcionalidades
3. Interfaz de usuario
4. Interfaces con otro software y hardware
5. Confiabilidad
6. Eficiencia
7. Mantenimiento
8. Portabilidad
9. Interoperabilidad
10. Reusabilidad
11. Restricciones de Diseño
12. Legales y reglamentarios
La parte 02 de la norma coincide parcialmente con la Norma Internacional ISO/IEC
15504-2: 2003: Performing an assessment, en lo relativo al inciso 6.2116.
La NMX-I-059/03-NYCE (parte03) propone una extensión de los procesos de MoProSoft
con elementos que apoyan su implantación. Entre estos elementos están:
§ Indicadores y ejemplos de mediciones para evaluar el cumplimiento de los objetivos de
los procesos.
§ Los roles con la descripción de la capacitación requerida y asignación de tareas.
§ La descripción de las actividades a mayor detalle. 116 NMX-I-059-/02-NYCE-2005. Normalización y Certificación Electrónica A. C.
93
§ Los diagramas de flujo, entre otros.
Además, proporciona a las organizaciones de desarrollo y mantenimiento de software un
ejemplo de la implantación del modelo basado en las mejores prácticas de la ingeniería de
software.
Para documentar los procesos la norma define un patrón de procesos definidos en el punto
0.4 que contiene los 23 elementos. Estos elementos son:
0.4.1 Proceso
Nombre de proceso, precedido por el acrónimo establecido en la definición de los elementos
de la estructura del modelo de procesos.
0.4.2 Categoría
Nombre de la categoría a la que pertenece el proceso y el acrónimo entre paréntesis.
0.4.3 Propósito
Objetivos generales medibles y resultados esperados de la implantación efectiva del proceso.
Este elemento se presenta como texto dentro del cuadro. El texto es una cita del propósito del
proceso correspondiente de la NMX-I-059/02-NYCE.
0.4.4 Objetivos
Objetivos específicos cuya finalidad es asegurar el cumplimiento del propósito del proceso.
Los objetivos se identifican como O1, O2, etc. Este elemento se presenta como texto dentro
del cuadro. El texto es una cita de los objetivos del proceso correspondiente de la NMX-I-
059/02-NYCE.
0.4.5 Indicadores
Definición de los indicadores para evaluar la efectividad del cumplimiento de los objetivos
del proceso. Los indicadores se identifican como I1, I2, etc. y entre paréntesis se especifica
una o más identificaciones de los objetivos a los que dan respuesta.
0.4.6 Metas cuantitativas
Valor numérico o rango de satisfacción por indicador.
0.4.7 Mediciones
Mediciones que se establecen para evaluar los indicadores del proceso. Las mediciones se
identifican como M1, M2, etc. y entre paréntesis se especifica la identificación del indicador
que le corresponde.
0.4.8 Subprocesos
94
Lista de procesos de los cuales se compone el proceso en cuestión.
0.4.9 Procesos relacionados
Nombres de los procesos relacionados.
0.4.10 Entradas
Nombre Fuente
Nombre del producto o recurso. Referencia al origen del producto o recurso.
0.4.11 Salidas
Nombre Destino
Nombre del producto o recurso. Referencia al destinatario del producto o
recurso.
0.4.12 Productos internos
Nombre
Nombre del producto generado y utilizado en el propio proceso.
0.4.13 Responsabilidad y autoridad
Responsabilidad es el rol principal responsable por la ejecución del proceso. Autoridad es el
rol responsable por validar la ejecución del proceso y el cumplimiento de su propósito.
0.4.14 Roles involucrados y capacitación requerida
Rol Abreviatura Capacitación
Nombre del rol Abreviatura del rol Capacitación requerida por el rol para poder
ejecutar el proceso.
0.4.15 Actividades
La descripción de actividades utiliza el siguiente esquema: primero se presenta como texto
dentro del cuadro la cita de la actividad correspondiente de la NMX-I- 059/02-NYCE.
Seguida de una descripción detallada que incluye los roles y las tareas correspondientes a la
actividad.
La descripción detallada de la actividad se presenta de la siguiente forma, dando como
ejemplo la primera actividad:
Rol Descripción
A1. (O1, O2, ...) Nombre de la actividad
Abrev. A1.1 Descripción de tarea 1. Si la actividad es una verificación o validación se
95
del(los)
rol(es).
debe hacer referencia a la identificación de la misma.
0.4.16 Diagrama de flujo de trabajo
Diagrama de actividades, donde se especifican las actividades del flujo de trabajo y los
productos.
0.4.17 Verificaciones y validaciones
Se definen las verificaciones y validaciones asociadas a los productos generados en las
actividades.
En la verificación como en la validación se identifican los defectos que deben corregirse antes
de continuar con las actividades posteriores.
La validación de un producto puede ser interna (dentro de la organización) o externa (por el
cliente) con la finalidad de obtener su autorización.
Se deben efectuar las validaciones una vez que se hayan realizado las verificaciones asociadas
al producto.
La descripción de validaciones y verificaciones se presenta de la siguiente forma:
Verificación
o validación
Actividad Producto Rol Descripción
Identificación
de la
verificación o
validación,
por ejemplo
Ver1 o Val1
Identificación
de la tarea
Nombre
del
Producto
Abreviatura
del rol
responsable
de realizar la
verificación
o validación
Descripción
de la
verificación
o validación
que se debe
hacer al
producto
0.4.18 Incorporación a la Base de Conocimiento
Describe tipo de aprobación requerido para que un producto sea incorporado a la base de
conocimiento de la organización. Esta descripción se presenta de la siguiente forma:
Producto Forma de aprobación
Nombre de producto Identificación de la verificación, validación o descripción de otra
forma de aprobación, en caso de no requerirse alguna de éstas,
96
escribir la palabra Ninguna.
Estas aprobaciones definen el momento a partir del cual el
producto está bajo control de Conocimiento de la Organización.
0.4.19 Recursos de infraestructura
Recomienda el tipo de herramientas para apoyar la realización de las actividades.
Actividad Recurso
Identificación de la actividad o tarea Tipo de herramienta
0.4.20 Capacitación
Definición de las reglas para proporcionar a los roles involucrados en el proceso, la
capacitación necesaria.
0.4.21 Situaciones excepcionales
Definición de los mecanismos para el manejo de las situaciones excepcionales durante la
ejecución del proceso.
0.4.22 Lecciones aprendidas
Definición de los mecanismos para aprovechar las lecciones aprendidas durante la ejecución
del proceso.
0.4.23 Guías de ajuste
Descripción de posibles modificaciones al proceso que no deben afectar a los objetivos del
mismo.
La descripción de las guías de ajuste se presenta de la siguiente forma:
a) Identificación de la guía
Descripción
b) Identificación de la guía
Descripción
La parte 03 de la norma no tiene concordancia con alguna Norma Internacional, ya que
no existía referencia alguna cuando se elaboró117.
Finalmente, la NMX-I-059/04-NYCE (parte04) tiene como propósito aplicar las
Directrices para la Evaluación EvalProSoft, para obtener como resultado el perfil de capacidad
de los procesos y el nivel de madurez de capacidades de la organización.
117 NMX-I-059-/03-NYCE-2005. Normalización y Certificación Electrónica A. C.
97
EvalProSoft otorga a la organización solicitante:
a) Perfil del nivel de capacidad de los procesos implantados
b) Nivel de madurez de capacidades
El perfil del nivel de capacidad de los procesos implantados es el conjunto de los
niveles de capacidad alcanzados por los procesos que están dentro del alcance de la
evaluación. Cuando todos los procesos establecidos en la parte 02 de la norma están dentro del
alcance de la evaluación, se asigna a la organización un nivel de madurez de capacidades que
corresponde al máximo nivel de capacidad por todos los procesos evaluados y para realizar
esta evaluación es necesaria la intervención del Organismo de Certificación. La figura 3.10
muestra la relación de las partes involucradas.
Figura 3.10 Relación entre los elementos de EvalProSoft118
De acuerdo a esta parte de la norma, EvalProSoft tiene tres posibles usos:
a) Evaluación para determinar las capacidades de los procesos y madurez de la organización
con el fin de obtener un perfil del nivel de capacidad de los procesos implantados y un nivel de
madurez de capacidades.
b) Evaluación de capacidades del proveedor para obtener un perfil del nivel de capacidad de
los procesos implantados por el proveedor de desarrollo y mantenimiento de software.
c) Auto-evaluación de capacidades de proceso, es cuando una organización realiza una
evaluación por personal interno o externo que no necesariamente sea Evaluador Competente.
Por otra parte dentro de las directrices para la evaluación de procesos que se
encuentran en el punto 3 de la norma, están las siguientes:
a) La descripción de actividades de preparación de la evaluación, planificación, ejecución,
generación y entrega de resultados, cierre y notificación de los resultados de la evaluación. 118 Elaboración con fuente de: NMX-I-059-/04-NYCE-2005. Normalización y Certificación Electrónica A. C.
98
b) La descripción de roles involucrados en una evaluación que tienen responsabilidades
específicas y además los roles comparten la responsabilidad de guardar la confidencialidad de
la información resultante de la evaluación. Los roles involucrados son:
1. Organismo de Certificación
2. Promotor
3. Evaluador Competente
4. Representante de la Organización
5. Facilitador
6. Equipo de Evaluación
7. Participante de la Evaluación
c) Los productos de entrada para la evaluación:
1. Lista de Evaluadores Competentes
2. Datos de la Organización
3. Paquete de Evaluación
d) Los productos de salida del proceso de evaluación:
1. Acuerdo de la Evaluación
2. Plan de Evaluación
3. Cuestionario de la Evaluación
4. Reporte de Resultados
5. Reporte Estadístico
6. Encuesta de Satisfacción
Finalmente, la parte 04 de la norma anexa las actividades a realizar para llevar a cabo el
proceso de evaluación siguiendo las directrices de EvalProSoft. Las actividades se muestran
de forma resumida en la tabla 3.11.
Tabla 3.11 Actividades de EvalProSoft
Actividad Sub-Actividades
3.2.1 Preparación
de la evaluación
3.2.1.1 Seleccionar al Evaluador Competente
3.2.1.2 Establecer el Acuerdo de Evaluación
3.2.1.3 Notificar el inicio de la evaluación
99
3.2.2 Planificación
3.2.2.1 Confirmar compromiso
3.2.2.2 Identificar los proyectos y los Participantes de la Evaluación
3.2.2.3 Elaborar el Plan de Evaluación
3.2.2.4 Validar el Plan de Evaluación
3.2.3 Ejecución
3.2.3.1 Preparar al Equipo de Evaluación
3.2.3.2 Realizar la reunión de inicio
3.2.3.3 Ajustar los Cuestionarios de la Evaluación
3.2.3.4 Evaluar los proyectos
3.2.3.5 Evaluar los procesos de la Alta Dirección y Gerencia
3.2.3.6 Consolidar los Cuestionarios de la Evaluación
3.2.3.7 Corroborar los Cuestionarios de la Evaluación
3.2.4 Generación
de resultados
3.2.4.1 Elaborar la tabla del perfil de calificaciones de atributos
3.2.4.2 Generar el perfil de nivel de capacidad de los procesos
3.2.4.3 Asignar el nivel de madurez de capacidades
3.2.4.4 Elaborar el Reporte de Resultados
3.2.5 Entrega de
resultados
3.2.5.1 Presentar los Resultados de la Evaluación a la organización
3.2.5.2 Presentar los Resultados de la Evaluación al Promotor
3.2.6 Cierre de la
evaluación
3.2.6.1 Elaborar y entregar el Reporte Estadístico al Organismo de
Certificación
3.2.6.2 Entregar y solicitar las Encuestas de Satisfacción
3.2.6.3 Entregar la información y los productos generados a la
organización
3.2.7 Notificación
de los resultados de
la evaluación
3.2.7.1 Revisar y verificar los resultados de la evaluación
3.2.7.2 Registrar y notificar los resultados de la evaluación
3.2.7.3 Actualizar la información estadística de las evaluaciones
100
La parte 04 de la norma coincide parcialmente con la norma Internacional ISO/IEC
15504-2: 2003: Performing an assessment, en lo relativo a la sección 4 con respecto a la
ejecución de una evaluación, a la sección 5 con respecto al marco de medición de la capacidad
del proceso y a la sección 6.3 con respecto al modelo de proceso de evaluación119.
119 NMX-I-059-/04-NYCE-2005. Normalización y Certificación Electrónica A. C.
101
CAPÍTULO 4 PROPUESTA DE LA GUÍA
En este capítulo se propone una guía que ayuda a interpretar los Procesos de la Categoría de
Operación del Modelo Mexicano para el Desarrollo y Mantenimiento de Software
(MoProSoft) a través del uso de las Prácticas, Valores y Principios obtenidos de los dos
Métodos Agiles más utilizados a nivel mundial. Scrum y Extreme Programming son dos
métodos de desarrollo de software ágiles que han demostrado dar mayor visibilidad tanto del
seguimiento de los proyectos como de situaciones personales que de alguna manera afectan al
proyecto. Esta guía fue implementada en el área encargada del desarrollo de aplicaciones de
una empresa pública que brinda los servicios de energía eléctrica en la zona centro del país. Y
que necesita desarrollar aplicaciones de manera interna para las tareas administrativas,
técnicas y operativas donde los trabajadores están involucrados de manera permanente.
4.1 Consideraciones previas
§ Esta guía no intenta enseñar los métodos ágiles expuestos en el capítulo 2.2.
§ Las actividades y productos descritos por nivel de capacidad son los que se describen
en la Norma Mexicana NMX-I-059/02 - 2005 (Requisitos de procesos).
§ Hay que tener presente que los métodos ágiles hacen énfasis en temas técnicos y no en
temas de negocio como medir el rendimiento de los equipos y proyectos.
§ MoProSoft trabaja más sobre procesos y los métodos ágiles más sobre los valores de
trabajo de las personas.
§ Cuando se utiliza el desarrollo ágil las fases de desarrollo se consideran actividades.
§ Es posible que cuando se utilicen prácticas de validación y verificación basadas en
procesos, entremos en conflicto al entender si estamos utilizando agilidad o procesos.
§ No se deben considerar a los métodos ágiles como modelos de procesos completos.
§ El uso de métodos agiles se justifica cuando los proyectos de software están propensos
a constantes cambios (requerimientos) que no fueron definidos en el inicio.
§ Tener presente el Manifiesto Ágil para no perder de vista el concepto de “Agilidad”.
§ Para la finalidad de esta guía se hace uso de los métodos ágiles; Scrum y Extreme
Programming. Por un lado, Scrum se enfoca en las prácticas de organización y
administración de proyectos, por el otro, XP se centra más en las prácticas de
102
programación. Estos métodos ágiles se complementan entre ellos y pueden combinarse
porque tratan de áreas diferentes, pero a pesar de sus diferencias ambas comparten
varios aspectos, entre los que se encuentran:
§ Iteraciones
§ Incrementos
§ Desarrollo del producto funcionando en cada iteración
§ Equipos que se auto-organizan
4.2 Administración de Proyectos Específicos
Los objetivos del proceso Administración de Proyectos Específicos (APE) de MoProSoft son:
O1 Lograr los Objetivos del proyecto en tiempo y costo mediante la coordinación y el manejo
de los recursos del mismo.
O2 Mantener informado al Cliente mediante la realización de reuniones de avance del
proyecto.
O3 Atender las Solicitudes de Cambio del cliente mediante la recepción y análisis de las
mismas.
De acuerdo a la norma mexicana NMX-I-059/02 (Requisitos de Proceso), las
actividades que se deben realizar por nivel de capacidad son resumidas en la figura 4.1.
Figura 4.1 Actividades de APE por Nivel de Capacidad
103
Las actividades se describen a continuación:
A1 PLANIFICACIÓN (O1)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A1.1 Revisar con el Responsable de Gestión de Proyectos la Descripción del Proyecto.
A1.3 Definir conjuntamente con el Cliente el Protocolo de Entrega de cada uno de los
entregables especificados en la Descripción del Proyecto.
A1.4 Identificar el número de ciclos y las actividades específicas que deben llevarse a
cabo para producir los entregables y sus componentes identificados en la
Descripción del Proyecto. Identificar las actividades para llevar a cabo el Protocolo
de Entrega. Documentar el resultado como Ciclos y Actividades.
A1.5 Identificar y documentar la relación y dependencia de cada una de las actividades.
A1.6 Establecer el Tiempo Estimado para desarrollar cada actividad.
A1.7 Elaborar el Plan de Adquisiciones y Capacitación, definiendo las características y el
calendario en cuanto a recursos humanos, materiales, equipo y herramientas,
incluyendo la capacitación requerida para que el equipo de trabajo pueda
desempeñar el proyecto.
A1.8 Conformar el Equipo de Trabajo, asignando roles y responsabilidades basándose en
la Descripción del Proyecto.
A1.9 Asignar fechas de inicio y fin a cada una de las actividades para generar el
Calendario de trabajo tomando en cuenta los recursos asignados, la secuencia y
dependencia de las actividades.
A1.10 Evaluar y documentar el Costo Estimado del proyecto.
A1.11 Identificar, describir y evaluar los riesgos que pueden afectar el proyecto.
A1.12 Generar el Plan del Proyecto o actualizarlo antes de iniciar un nuevo ciclo.
A1.13 Generar el Plan de Desarrollo en función del Plan del Proyecto o actualizarlo antes
de iniciar un nuevo ciclo.
Nivel 2 - Proceso Administrado
# Descripción (¿qué se debe hacer?)
A1.4 Identificar las actividades específicas que deben llevarse a cabo para cumplir con los
104
objetivos del proyecto, definir las actividades para llevar a cabo revisiones
periódicas al producto o servicio que se está ofreciendo y para efectuar revisiones
entre colegas.
A1.6 Establecer el Tiempo Estimado para desarrollar cada actividad considerando la
información histórica.
A1.12 Además el Plan del Proyecto se puede actualizar a causa de Solicitud de Cambios
por parte del Cliente, Acciones Correctivas o Preventivas provenientes de Gestión
de Proyectos o Acciones Correctivas de este proceso.
A1.13 Además el Plan de Desarrollo se puede actualizar a causa de Solicitud de Cambios
por parte del Cliente, Acciones Correctivas o Preventivas provenientes de Gestión
de Proyectos o Acciones Correctivas de este proceso.
A1.14 Verificar el Plan del Proyecto y el Plan de Desarrollo.
A1.15 Corregir los defectos encontrados en el Plan del Proyecto y en el Plan de
Desarrollo con base en el Reporte de Verificación y obtener la aprobación de las
correcciones.
A1.16 Validar el Plan del Proyecto y el Plan de Desarrollo.
A1.17 Corregir los defectos encontrados en el Plan del Proyecto y Plan de Desarrollo con
base en el Reporte de Validación y obtener la aprobación de las correcciones.
Nivel 3 – Proceso Establecido
# Descripción (¿qué se debe hacer?)
A1.2 Con base en la Descripción del Proyecto, definir el Proceso Específico del proyecto
a partir del proceso de Desarrollo y Mantenimiento de Software de la organización o
a partir del acuerdo establecido con el Cliente. Se considera el alcance, la magnitud
y complejidad del proyecto.
A1.18 Dar inicio formal a un nuevo ciclo una vez que se haya asegurado el cumplimiento
de las condiciones iníciales del ciclo.
Nivel 4 – Proceso Predecible
# Descripción (¿qué se debe hacer?)
A1.6 Establecer el Tiempo Estimado para desarrollar cada actividad considerando la
información histórica y las Metas Cuantitativas para el Proyecto.
105
A1.10 Evaluar y documentar el Costo Estimado del proyecto, tomando en cuenta las Metas
Cuantitativas para el Proyecto.
A2 REALIZACIÓN (O1, O2, O3)
Nivel 1 - Proceso Realizado
# Descripción (¿qué se debe hacer?)
A2.1 Acordar con el Responsable de Desarrollo y Mantenimiento del proyecto la
asignación de tareas al Equipo de Trabajo incluyendo a los subcontratistas.
Nivel 2 - Proceso Administrado
# Descripción (¿qué se debe hacer?)
A2.2 Acordar la distribución de la información necesaria al equipo de trabajo con base en
el Plan de Comunicación e Implantación.
A2.3 Revisar con el Responsable de Desarrollo y Mantenimiento del proyecto la
Descripción del Producto, el Equipo de Trabajo y Calendario.
A2.4 Dar seguimiento al Plan de Adquisiciones y Capacitación. Aceptar o rechazar la
Asignación de Recursos humanos o subcontratistas. Distribuir los recursos a los
miembros del equipo para que puedan llevar a cabo las actividades.
A2.5 Manejar la relación con subcontratistas que implica planificar, revisar y auditar las
actividades, asegurando la calidad de los productos o servicios contratados y el
cumplimiento con los estándares y especificaciones acordadas.
A2.6 Recolectar y analizar los Reportes de Actividades y productos de trabajo.
A2.7 Registrar los costos y recursos reales del ciclo.
A2.8 Revisar el Registro de Rastreo de los requerimientos del usuario a través del ciclo.
A2.9 Revisar los productos generados durante el ciclo, que forman parte de la
Configuración de Software.
A2.10 Recibir y analizar las Solicitudes de Cambios e incorporar los cambios aprobados en
el Plan del Proyecto y en el Plan de Desarrollo. En caso de cambios a
requerimientos se incorporan al inicio de un nuevo ciclo.
A2.11 Conduce reuniones de revisión con el equipo de trabajo y con el Cliente, generando
Minutas con puntos tratados y acuerdos tomados.
106
Nivel 3 – Proceso Establecido
# Descripción (¿qué se debe hacer?)
A2.6 Recolectar y analizar los Reportes de Actividades, Reportes de Mediciones y
Sugerencias de Mejora y productos de trabajo.
A3 EVALUACIÓN Y CONTROL (O1)
Nivel 3 - Proceso Establecido
# Descripción (¿qué se debe hacer?)
A3.1 Evaluar el cumplimiento del Plan del Proyecto y el Plan de Desarrollo, con respecto
al alcance, costo, calendario, equipo de trabajo, proceso y se establecen Acciones
Correctivas.
A3.2 Dar seguimiento y controlar el Plan de Manejo de Riesgos. Identificar nuevos
riesgos y actualizar el plan.
A3.3 Generar el Reporte de Seguimiento del proyecto, considerando los Reportes de
Actividades.
A4 CIERRE (O1)
Nivel 1 - Proceso Realizado
# Descripción (¿qué se debe hacer?)
A4.1 Formalizar la terminación del ciclo o del proyecto de acuerdo al Protocolo de
Entrega establecido en el Plan del Proyecto y obtener el Documento de Aceptación.
Nivel 2 - Proceso Administrado
# Descripción (¿qué se debe hacer?)
A4.2 Efectuar el cierre con subcontratistas de acuerdo al contrato establecido.
Nivel 3 - Proceso Establecido
# Descripción (¿qué se debe hacer?)
A4.3 Generar el Reporte de Mediciones y Sugerencias de Mejora de este proceso, de
acuerdo al Plan de Mediciones de Procesos.
A4.4 Identificar las Lecciones Aprendidas e integrarlas a la Base de Conocimiento. Como
ejemplo, se pueden considerar mejores prácticas, experiencias exitosas de manejo de
107
riesgos problemas recurrentes, entre otras.
Para medir el grado de cumplimiento que cada Práctica o Valor Ágil a nivel de
Objetivos y a nivel de detalle de actividades, ayudan a cumplir con los requisitos de la Norma
se utilizará la siguiente nomenclatura:
r Insatisfactoria La actividad no se puede conducir a través de prácticas ágiles, por lo
que es necesario utilizar alguna otra actividad o práctica alternativa.
a Parcialmente
Satisfactoria
La actividad se puede conducir a través de prácticas ágiles, sin
embargo, es necesario utilizar una actividad o práctica
complementaria para cumplir con el requisito en el contexto de
MoProSoft.
aa Completamente
Satisfactoria
La actividad puede conducirse completamente de manera
satisfactoria a través de las Prácticas Ágiles.
Los acrónimos utilizados para hacer referencia al método, valor, práctica, principio,
etc., de los métodos ágiles son los siguientes:
V Valores
P Prácticas
Pr Principios
R Roles
A Artefactos
F Fase
S Scrum
XP Extreme Programming
Como se mencionó en las consideraciones, para el cumplimiento de los objetivos de
este proceso se hará uso de las Prácticas y Valores SCRUM, que es un método ágil cuyas
prácticas están enfocadas a la administración, mejora y mantenimiento de un producto nuevo o
existente.
Objetivo ¿Cómo lo cumple SCRUM?
O1
aa Scrum está enfocado en cómo los miembros del equipo deben funcionar para
lograr construir un sistema flexible en un ambiente cambiante. Es un método
ágil para administrar proyectos.
108
O2
aa Scrum realiza tres tipos de reuniones. Específicamente en las reuniones para la
planificación y revisión del sprint intervienen el Cliente, Usuarios, etc., y los
mantiene informados del avance del proyecto.
O3
aa Scrum al igual que el resto de los métodos ágiles, tienen la habilidad de
responder a los cambios que puedan surgir a los largo del proyecto
(requerimientos, tecnología, cambios en el equipo, entre otros). Ya que se
apoya en el enunciado cuatro del manifiesto ágil.
Conclusión
Scrum satisface los objetivos de manera general a través de las prácticas ágiles que propone
este método. Ya que la planificación y seguimiento de los proyectos se aplica a pequeñas
iteraciones. Además se involucran a todas las personas participantes en la planificación.
Dicha planificación puede cambiar ya que la meta es desarrollar el producto que satisfaga las
necesidades del cliente.
A continuación se muestran las Prácticas, Valores y Principios que ayudan a conducir
las actividades descritas en cada una de las fases que dicta la norma y las razones del porque
puede ser conducida a través de dichas Prácticas.
A1 PLANIFICACIÓN
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.1
aa
S.F.Pre-Game
S.F.Planeación
S.P.Pedido del Producto
Se establece la visión del producto, se
determinan las funcionalidades más importantes
para desarrollo inmediato en base a los
requisitos del producto que se conocen hasta el
momento.
A1.3
aa
S.P.Reunión de Planificación
S.P.Pedido de Sprint
Se determinan con el cliente en la reunión,
cuales son las funcionalidades que se van a
incorporar con el próximo incremento.
A1.4
aa
S.F.Pre-Game
S.F.Planeación
Se determinan las funcionalidades, las tareas, el
esfuerzo que se necesita para desarrollarlas y se
109
S.P.Reunión de Planificación
asignan estas tareas a los responsables
correspondientes según los roles.
A1.5
aa
S.F.Desarrollo
S.P.Reunión de Planificación
S.V.Auto-Organización
El equipo Scrum determina cuales son las tareas
que pueden complementar, durante el Sprint
partiendo de la que tiene más prioridad. El
equipo se auto-asigna las diferentes tareas
teniendo como criterio sus conocimientos.
A1.6
aa
S.F.Desarrollo
S.P.Reunión de Planificación
S.P.Estimación de esfuerzo
Se realizan las estimaciones de los
requerimientos del Product Backlog, pero las
estimaciones solo sirven para asignar los
requerimientos al Sprint Backlog.
A1.7
aa
S.F.Pre-Game
S.F.Planeación
XP.F.Exploración
XP.Programación en Pares
Se define el equipo del proyecto, las
herramientas y otros recursos, entrenamiento
necesario y una verificación para su aceptación.
Y la capacitación depende directamente de
S.R.Scrum Management.
En XP el entrenamiento se lleva a cabo en la
fase de exploración y se emplea como
entrenamiento la programación en parejas
guiado por el Entrenador.
A1.8
aa
S.F.Pre-Game
S.F.Planeación
S.V.Auto-Organización
XP.V.Comunicación
XP.V.Coraje
Se define en la Planeación el equipo del
proyecto y las responsabilidades de cada uno.
Los equipo tienen la capacidad de auto-
organizarse.
A1.9
aa
S.F.Pre-Game
S.F.Planeación
S.P.Reunión de Planificación
En el Pre-Game se define una fecha de entrega
aproximada. El calendario se genera a partir del
Product Backlog, el cual se divide en Sprints
Backlog, se hacen las estimaciones de esfuerzo,
110
la capacidad del equipo y su carga.
A1.10
aa
S.F.Pre-Game
S.F.Planeación
S.P.Reunión de Planificación
La estimación se lleva a cabo a nivel de Prodcut
Backlog y a nivel de Sprint Backlog. Scrum y
XP no tocan el tema de costos explícitamente,
sin embargo, se recomienda que el S.R.Product
Owner es quien deba calcular el presupuesto y
financiamiento del Proyecto en base a cada
Sprint Backlog
A1.11
aa
S.P.Reunión Diaria
S.V.Encuentros Diarios
Scrum considera a los riesgos como
impedimentos para el proyecto. La
identificación de los riesgos no se hace de forma
sistematizada. Los impedimentos se registran de
manera informal en Pizarrones y su
identificación se realiza de forma iterativa
durante las reuniones.
A1.12
aa
S.F.Pre-Game
S.F.Planeación
S.P.Sprint
En Scrum la planificación requiere de dos
elementos mínimos para comenzar un Proyecto.
El primero de ellos es la Visión del Proyecto,
que nos dice el porqué del proyecto y el estado
final que se desea conseguir. El segundo es el
Product Backlog, el cual define los
requerimientos del sistema, priorizados y
estimados. Estos dos elementos forman la base
del Plan de Proyecto. Los métodos ágiles no
siguen un Plan.
A1.13
aa
S.F.Desarrollo
S.F.Planeación
S.P.Sprint
S.V.Encuentros Diarios
Se lleva a cabo el desarrollo dividido en
Iteraciones (Sprints), cada iteración dura entre
una semana y 30 días y cada uno incluye las
fases tradicionales de desarrollo de software. El
S.R.Scrum Master actualiza las tareas
111
finalizadas y el tiempo que el equipo cree que le
tomará terminar las que no lo están.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.4
aa
S.F.Desarrollo
S.P.Reunión de planificación
S.P.Reunión Diaria
S.P.Reunión de Revisión
S.P.Sprint
S.V.Encuentros Diarios
XP.V.Comunicación
La reunión comprende dos fases. La primera
fase consiste en definir los objetivos y la
funcionalidad que se debe incluir en el Sprint
Backlog. La segunda fase consiste en establecer
cómo se implementa ésta funcionalidad durante
el Sprint, se determinan las tareas necesarias, se
estima el esfuerzo que necesita cada una y se
asignan a las personas del equipo.
Se reúnen diariamente todos los miembros del
equipo, dicen las tareas en las que están
trabajando para saber si hay algún impedimento.
Se realiza una reunión de revisión al final de
cada Sprint en la que el S.R.Scrum Team
presenta al S.R.Product Owner, S.R.Cliente,
etc., el incremento construido en el Sprint.
A1.6
aa
S.F.Pre-Game
S.F.Planeación
S.F.Desarrollo
S.P.Reunión de planificación
S.P.Estimación de esfuerzo
En Scrum las estimaciones se hacen en base a
“días de trabajo ideal”, es decir, el tiempo que
sería necesario para realizar un trabajo en
“condiciones ideales”: si no ocurre alguna
interrupción. Y esto a su vez es en función de
los históricos (Sprints Backlog Previos y
Products Backlog previos), la capacidad
disponible para el próximo Sprint Backlog y la
complejidad relativa de las tareas requeridas del
Sprint Backlog.
A1.12 S.F.Desarrollo En Scrum como en todos los Métodos Ágiles,
112
A1.13
aa
S.P.Reunión de planificación
S.P.Reunión diaria
S.P.Sprint
los cambios no solo son bienvenidos, sino que
son parte fundamental del desarrollo iterativo.
En el caso exclusivo de Scrum, un Sprint es el
proceso de adaptación a las variables que
cambian con el entorno. El S.R.Scrum Master es
quien debe definir los criterios para determinar
si hay una desviación significativa con respecto
a la planificación. El método Scrum se adapta
muy bien a los cambios.
A1.14
A1.15
A1.16
A1.17
aa
S.F.Desarrollo
S.P.Reunión de Planificación
S.P.Reunión de Revisión
S.P.Sprint
S.V.Encuentros Diarios
XP.V.Comunicación
Scrum hace la planificación por medio de los
Sprints Backlog, por lo que los planes son
revisados al comienzo y al final del desarrollo
de cada Sprint Backlog. Durante la reunión de
revisión que se hace al final del desarrollo de
cada Sprint Backlog, se muestran los avances y
se revisa el cumplimiento del Sprint Backlog.
Cuando se inicia el desarrollo del siguiente
Sprint Backlog durante la reunión de
planificación, se hacen los cambios de
requerimientos y las nuevas adaptaciones.
MoProSoft dice que es necesario verificar los
planes hasta que se encuentren libres de
defectos y recordemos que Scrum no siguen un
plan. Por otra parte, MoProSoft dice que la
validación se hace con respecto a los elementos
de los planes con la descripción del proyecto y
Scrum hace esta validación en la reunión de
revisión ya que el S.R.Product Owner y el
S.R.Scrum Team obtienen el feedback clave
para evolucionar y dar valor al producto.
113
Nivel 3 – Proceso Establecido
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.2
a S.F.Pre-Game
S.F.Desarrollo
S.F.Post-Game
XP.F.Planeación
XP.F.Liberación
S.A.Historias de Usuario
XP.A.Hisotiras de Usuario
En esta actividad se puede combinar Scrum y
XP mediante sus intersecciones de prácticas
ágiles, ya que ambas desarrollan el software de
manera iterativa. En cada iteración se realiza la
fase de análisis, diseño, construcción, pruebas y
entrega. Ambos métodos utilizan “Historias de
Usuario”, “Reuniones de Revisión” y “Juegos
de Planificación”.
Lo que permite a las organizaciones crear un
Proceso Especifico para el Proyecto en base a la
combinación de ambos métodos. Pero hay que
recordar que al momento de establecer un
proceso específico basado en métodos ágiles, las
fases se convierten actividades (con la finalidad
de no perder la naturaleza de la agilidad).
A1.18
aa
S.F.Desarrollo
S.F.Reunión de planificación
La reunión es organizada formalmente por el
S.R.Scrum Master. Los Clientes, Usuarios,
Gerentes, el Propietario del Producto y el
Equipo Scrum deciden sobre los objetivos y la
funcionalidad del nuevo Sprint Backlog. Y solo
el S.R.Scrum Master y el S.R.Scrum Team se
ponen de acuerdo en cómo el incremento del
producto es implementado durante el proceso.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.6
r No hay
A1.10 No hay
114
r
A2 REALIZACIÓN
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A2.1
aa
S.F.Desarrollo
S.P.Reunión de Planificación
Durante la segunda fase de esta reunión el
S.R.Scrum Master y el S.R.Scrum Team se
determinan cuales son las tareas que se pueden
completar durante el Sprint Backlog partiendo
de las que tiene más prioridad. Y se asignan
estas tareas al S.R.Scrum Team.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A2.2
aa
S.F.Desarrollo
S.P.Reunión Diaria
S.V.Encuentros Diarios
XP.Comunicación
XP.Pr.Trabajo en Equipo
En Scrum no existe un plan para comunicarse
entre los miembros del equipo, la comunicación
se realiza de forma directa “cara a cara” y se
hace en reuniones diarias de monitorización. El
S.R.Scrum Manager utiliza un pizarrón o la
pared de la oficina para que por medio de fichas
o Post-Its para que la comunicación sea más
rica, más fluida, más cómoda y más visual para
el equipo.
A2.3
aa
S.F.Pre-Game
S.F.Planeación
En la fase de Pre-Game se establece la visión
del proyecto y el Prodcut Backlog (Descripción
del producto), también se define el equipo de
trabajo y la infraestructura disponible y se
define una fecha de entrega aproximada, ya que
Scrum establece un calendario a partir del
Product Backlog, lo divide en Sprints y hace las
estimaciones del esfuerzo.
115
A2.4
aa
S.P.Reunión de Revisión
S.P.Reunión Diaria
En Scrum no hay un plan de capacitación y
adquisiciones. Durante las reuniones de revisión
cada desarrollador informa sobre su progreso y
otros parámetros para compararlas con las
estimaciones del plan. Se detectan problemas
derivados de la escasez de recursos, habilidades
o conocimientos. Durante las reuniones diarias
el S.R.Scrum Master es el responsable de
proporcionar nuevos recursos cuando los que se
tienen actualmente sean insuficientes o surjan
nuevos impedimentos relacionados con la
escasez de recursos.
A2.5
r No hay La administración de los subcontratistas esta
fuera del alcance de Scrum, ya que esta
actividad implica el aseguramiento de la calidad
de un producto que fue realizado por un tercero.
A2.6
aa
S.P.Reunión de Revisión
S.P.Reunión Diaria
En Scrum se hace una revisión diaria para
presentar el trabajo y la resolución a problemas
emergentes. En la reunión de revisión se
presenta el incremento del producto trabajado.
A2.7
aa
S.F.Desarrollo
S.F.Runión de planificación
El Product Backlog permite hacer estimaciones
a alto nivel de abstracción. Pero el Sprint
Backlog permite hacer estimación a bajo nivel,
por lo que son más precisas y reales.
A2.8
aa
S.P.Reunión de revisión
XP.P.Programación en Pares
XP.P.Refacgtoring
XP.V.Comunicación
XP.A.Tarjetas CRC
En un proyecto Scrum los requerimientos del
usuario no están definidos desde el inicio, por el
contrario, las funcionalidades, mejoras,
tecnología y corrección de errores se incorporan
al producto a través de las sucesivas iteraciones.
Logrando así la entrega de un producto
116
funcionando en cada iteración y no simplemente
módulos donde se tengan que rastrear o registrar
los requerimientos del usuario. Pero para esta
actividad se puede hacer uso de las tarjetas CRC
usadas en XP.
A2.9
aa
S.P.Reunión de Revisión
En la reunión de revisión, el S.R.Scrum Master
y el S.R.Scrum Team muestran el incremento
del producto trabajado durante el ciclo. Y hay
que recordar que todas las fases incluyen,
requerimientos, diseño, código, revisión y
documentación.
A2.10
aa
S.F.Desarrollo
S.P.Reunión de planificación
S.P.Sprint
XP.V.Retroalimentación
En Scrum como en todos los Métodos Agiles,
los cambios no solo son bienvenidos, sino que
son parte fundamental del desarrollo iterativo.
En el caso exclusivo de Scrum, un Sprint es el
proceso de adaptación a las variables que
cambian con el entorno.
Cuando se inicia el desarrollo del siguiente
Sprint Backlog, durante la reunión de
planificación se hacen los cambios de
requerimientos y las nuevas adaptaciones.
A2.11
aa
S.P.Reunión de revisión
S.P.Sprint
En Scrum se realizan las reuniones de manera
informal entre el Propietario del Producto y el
Equipo Scrum para obtener un feedback que
será clave para evolucionar el proyecto. El
S.R.Scrum Manager fija acuerdos para la
próxima reunión de preparación del siguiente
sprint.
Nivel 3 – Proceso Establecido
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
117
A2.6
a S.P.Reunión Diaria Las reuniones diarias permiten recolectar y
analizar el progreso del equipo (a medida
principal del progreso de todos los métodos
ágiles, es el código).
A3 EVALUACIÓN
Nivel 3 – Proceso Establecido
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A3.1
a S.P.Reunión Diaria
S.P.Reunión de Planificación
En Scrum la evaluación del cumplimiento de los
parámetros de planificación del proyecto, se
realizan en las reuniones diarias y en las
reuniones de revisión. Las reuniones diarias
permiten dar seguimiento al progreso del equipo
para evaluar los impedimentos de las tareas
planificadas. En las reuniones de revisión cada
miembro del equipo informa sobre su progreso
para compararlo con las estimaciones. Se
recolectan las medidas de esfuerzo y los
problemas derivados de la escasez de recursos.
Durante la reunión de revisión se identifican las
acciones correctivas que se van a adoptar en el
siguiente sprint y se toman acuerdos y
compromisos con las partes interesadas.
A3.2
aa
S.P.Reunión Diaria Scrum identifica los riesgos como
impedimentos. Esta identificación y su impacto
no se lleva a cabo de forma planificada ni
estrictamente documentada, es decir, los riesgos
son registrados de manera informal en los
pizarrones o paredes de la oficina y su
identificación la hace el equipo durante las
118
reuniones diarias.
A3.3
a S.P.Reunión Diaria
S.P.Reunion de revisión
El seguimiento del proyecto se hace en las
reuniones diarias y en las reuniones de revisión
todo se hace de manera informal no se genera
un reporte.
A4 CIERRE
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.1
aa S.F.Post-Game La fase de Post-Game es completada con la
aceptación de variables ambientales y con todos
los requisitos cumplidos. Esta fase incluye
integración, pruebas y documentación.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.2
r No hay No se cumple
Nivel 3 – Proceso Establecido
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.3
r No hay No se cumple
A4.4
a S.P.Reunión Diaria En las reuniones diarias los equipos recogen y
evalúan sus fortalezas y debilidades e
identifican las mejoras necesarias en reuniones
cara a cara, pero no hay un camino formal para
compartir esta información.
Conclusiones
El Proceso de Administración de Proyectos Específicos tendría niveles alcanzables de
capacidad de procesos utilizando una combinación de Métodos Ágiles sin perder de vista el
119
concepto de agilidad, como sigue:
Nivel 1 al 100%
Todas las actividades que dice el modelo MoProSoft se ejecutan de
manera ágil utilizando Scrum.
Nivel 2 al 90% Debido a que los métodos agiles no pueden corregir su ciclo de desarrollo
que ya fue definido en base al Manifiesto Ágil.
No maneja un protocolo de relación con contratistas, aunque el
manifiesto ágil dice que lo más importante son las personas, y algunos de
los principios básicos son la comunicación y el respeto, no implica que
los contratistas estén familiarizados con estos términos.
Nivel 3 al 30% En un proyecto de desarrollo de software no se puede determinar la
complejidad usando prácticas ágiles, ya que el producto evoluciona con
respecto al tiempo.
Por otro lado, el análisis y medición no está definida por ninguno de los
procesos ágiles ya que la única unidad de medida en un proyecto ágil es
el código. Aunque se pueden usar herramientas que pueden ayudar a
medir la velocidad del proyecto no aportan información relevante para
mejorar el proceso.
Finalmente, en los métodos agiles no existe una base de conocimiento, ya
que la comunicación entre los equipo de desarrollo es directa cara a cara,
lo que permite transmitir conocimiento con mayor precisión y riqueza.
Nivel 4 al 0% No es alcanzable usando una combinación de métodos ágiles.
A continuación se listan los productos esperados por nivel de capacidad del proceso de
Administración de Proyectos Específicos de acuerdo a MoProSoft, y los artefactos o productos
que pueden ser utilizados en su lugar. Ya que de acuerdo a la Norma NMX-I-059/01-2005
(Definición de Conceptos y Productos) pp. 10, los nombres de los productos pueden ser
sustituidos por los utilizados en la organización.
Nivel 1 - Proceso Realizado
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
APE.A1 Plan de Proyecto S.A.Vision de Proyecto
S.A.Product Backlog
120
APE.A1 Plan de Desarrollo S.A.Sprint Backlog
APE.A4 Documento de Aceptación S.A.Incremento
Nivel 2 - Proceso Administrado
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
APE.A1 Reportes de Verificación S.A.Incremento
APE.A1 Reportes de Validación S.A.Incremento
APE.A2 Minutas S.P.Reuniones
APE.A3 Reporte de Seguimiento S.P.Reunion Diaria
S.P.Reunión de Revisión
APE.A3 Acciones Correctivas S.A.Impedimentos
CO.A1 Plan de Administración de la Base
de Conocimiento
No hay
CO.A2 Diseño de la Base de
Conocimiento
No hay
Nivel 3 - Proceso Establecido
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
GPR.A2 Documentación del Proceso El Ciclo de Scrum y XP
GPR.A3 Reporte de Mediciones y
Sugerencias de Mejora
NO HAY
GPR.A3 Lecciones Aprendidas XP.V.Comunicación
GPR.A3 Plan de Mediciones del Proceso NO HAY
GPR.A3 Reporte Cualitativo y Cuantitativo
del Proceso
NO HAY
Conclusión
La mayoría de los productos esperados de MoProSoft son documentos que ayudan a controlar
el proceso, es necesario generar solo la documentación que se requiera de acuerdo a las
121
necesidades del área donde se implemente el modelo para no perder de vista la agilidad, ya
que muchos de los productos están implícitos en las practicas que propone Scrum.
4.3 Desarrollo y Mantenimiento de Software
De acuerdo a MoProSoft el propósito del proceso Desarrollo y Mantenimiento de Software es
la realización sistemática de las actividades de análisis, diseño, construcción, integración y
pruebas de productos de software cumpliendo con los requerimientos especificados.
Los objetivos del proceso Desarrollo y Mantenimiento de Software de MoProSoft son:
O1 Lograr que los productos de salida sean consistentes con los productos de entrada en cada
fase de un ciclo de desarrollo mediante las actividades de verificación, validación o prueba.
O2 Sustentar la realización de ciclos posteriores o proyectos de mantenimiento futuros
mediante la integración de la Configuración de Software del ciclo actual.
O3 Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del Plan de
Desarrollo actual.
De acuerdo a la norma mexicana NMX-I-059/02 (Requisitos de Proceso), las
actividades que se deben realizar por nivel de capacidad se resumen en la figura 4.2.
Figura 4.2 Actividades de DMS por Nivel de Capacidad
Las actividades se describen a continuación:
122
A1 REALIZACIÓN DE LA FASE DE INICIO (O3)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A1.1 Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para
lograr un entendimiento común y obtener su compromiso con el proyecto.
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A1.2 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
A2 REALIZACIÓN DE LA FASE DE REQUERIMIENTOS (O1, O3)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A2.1 Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al
Plan de Desarrollo actual.
A2.2 Documentar o modificar la Especificación de Requerimientos.
A2.10 Documentar la versión preliminar del Manual de Usuario o modificar el manual
existente.
A2.13 Incorporar Especificación de Requerimientos y Manual de Usuario a la
Configuración de Software.
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A2.3 Verificar la Especificación de Requerimientos.
A2.4 Corregir los defectos encontrados en la Especificación de Requerimientos con base
en el Reporte de Verificación y obtener la aprobación de las correcciones.
A2.5 Validar la Especificación de Requerimientos.
A2.6 Corregir los defectos encontrados en la Especificación de Requerimientos con base
en el Reporte de Validación y obtener la aprobación de las correcciones.
A2.7 Elaborar o modificar Plan de Pruebas de Sistema.
A2.8 Verificar el Plan de Pruebas de Sistema.
123
A2.9 Corregir los defectos encontrados en el Plan de Pruebas de Sistema con base en el
Reporte de Verificación y obtener la aprobación de las correcciones.
A2.11 Verificar el Manual de Usuario.
A2.12 Corregir los defectos encontrados en el Manual de Usuario con base en el Reporte
de Verificación y obtener la aprobación de las correcciones.
A2.13 Incorporar Especificación de Requerimientos, Plan de Pruebas de Sistema y Manual
de Usuario como líneas base a la Configuración de Software.
A2.14 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad
Nivel 4 - Proceso Predecible
# Descripción de la actividad (¿qué se debe hacer?)
A2.14 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
A3 REALIZACIÓN DE LA FASE ANÁLISIS Y DISEÑO (O1, O3)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A3.1 Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al
Plan de Desarrollo actual.
A3.2 Documentar o modificar el Análisis y Diseño.
A3.10 Documentar o modificar el Análisis y Diseño a la Configuración de Software.
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A3.3 Verificar el Análisis y Diseño y el Registro de Rastreo.
A3.4 Corregir los defectos encontrados en el Análisis y Diseño y en el Registro de
Rastreo con base en el Reporte de Verificación y obtener la aprobación de las
correcciones.
A3.5 Validar el Análisis y Diseño.
A3.6 Corregir los defectos encontrados en el Análisis y Diseño con base en el Reporte de
Validación y obtener la aprobación de las correcciones.
124
A3.7 Elaborar o modificar Plan de Pruebas de Integración.
A3.8 Verificar el Plan de Pruebas de Integración.
A3.9 Corregir los defectos encontrados en el Plan de Pruebas de Integración con base en
el Reporte de Verificación y obtener la aprobación de las correcciones.
A3.10 Incorporar Análisis y Diseño, Registro de Rastreo y Plan de Pruebas de Integración
como líneas base a la Configuración de Software.
A3.11 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad.
Nivel 4 - Proceso Predecible
# Descripción de la actividad (¿qué se debe hacer?)
A3.11 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
A4 REALIZACIÓN DE LA FASE DE CONSTRUCCIÓN (O1, O3)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A4.1 Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al
Plan de Desarrollo actual.
A4.2 Construir o modificar el(los) Componente(s) de software:
§ Implementar o modificar Componente(s) con base a la parte detallada del
Análisis y Diseño.
A4.5 Incorporar Componentes a la Configuración de Software.
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A4.2 Construir o modificar el(los) Componente(s) de software:
§ Definir y aplicar pruebas unitarias para verificar que el funcionamiento de
cada componente esté acorde con la parte detallada del Análisis y Diseño.
§ Corregir los defectos encontrados hasta lograr pruebas unitarias exitosas (sin
defectos).
§ Actualizar el Registro de Rastreo, incorporando los componentes construidos
125
o modificados.
A4.3 Verificar el Registro de Rastreo.
A4.4 Corregir los defectos encontrados en el Registro de Rastreo con base en el Reporte
de Verificación y obtener la aprobación de las correcciones.
A4.5 Incorporar Componentes y Registro de Rastreo como líneas base a la Configuración
de Software.
A4.6 Elaborar el Reporte de Actividades, registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad.
Nivel 4 - Proceso Predecible
# Descripción de la actividad (¿qué se debe hacer?)
A4.6 Elaborar el Reporte de Actividades, registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
A5 REALIZACIÓN DE LA FASE DE INTEGRACIÓN Y PRUEBAS (O1, O3)
Nivel 1 - Proceso Realizado
# Descripción de la actividad (¿qué se debe hacer?)
A5.1 Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al
Plan de Desarrollo actual.
A5.2 Realizar integración:
§ Integrar los componentes en subsistemas o en el sistema del Software
A5.3 Documentar el Manual de Operación o modificar el manual existente.
A5.8 Documentar el Manual de Usuario o modificar el existente.
A5.11 Incorporar Software, Manual de Operación y Manual de Usuario a la Configuración
de Software.
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A5.2 Realizar integración y pruebas.
§ Integrar los componentes en subsistemas o en el sistema del Software y
aplicar las pruebas siguiendo el Plan de Pruebas de Integración,
documentando los resultados en un Reporte de Pruebas de Integración.
126
§ Corregir los defectos encontrados, con base en Reporte de Pruebas de
Integración, hasta lograr una prueba de integración exitosa (sin defectos).
§ Actualizar el Registro de Rastreo.
A5.4 Verificar el Manual de Operación.
A5.5 Corregir los defectos encontrados en el Manual de Operación con base en el Reporte
de Verificación y obtener la aprobación de las correcciones.
A5.6 Realizar las pruebas de sistema siguiendo el Plan de Pruebas de Sistema,
documentando los resultados en un Reporte de Pruebas de Sistema.
A5.7 Corregir los defectos encontrados en las pruebas de sistema con base en el Reporte
de Pruebas de Sistema y obtener la aprobación de las correcciones.
A5.9 Verificar el Manual de Usuario.
A5.10 Corregir los defectos encontrados en el Manual de Usuario con base en el Reporte
de Verificación y obtener la aprobación de las correcciones.
A5.11 Incorporar Software, Reporte de Pruebas de Integración, Registro de Rastreo,
Manual de Operación y Manual de Usuario como líneas base a la Configuración de
Software.
A5.12 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad.
Nivel 4 - Proceso Predecible
# Descripción de la actividad (¿qué se debe hacer?)
A5.12 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
A6 REALIZACIÓN DE LA FASE DE CIERRE (O2)
Nivel 2 - Proceso Administrado
# Descripción de la actividad (¿qué se debe hacer?)
A6.1 Documentar el Manual de Mantenimiento o modificar el existente.
A6.2 Verificar el Manual de Mantenimiento.
A6.3 Corregir los defectos encontrados en el Manual de Mantenimiento con base en el
Reporte de Verificación y obtener la aprobación de las correcciones.
127
A6.4 Incorporar Manual de Mantenimiento como línea base a la Configuración de
Software.
A6.7 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad
Nivel 3 - Proceso Establecido
# Descripción de la actividad (¿qué se debe hacer?)
A6.5 Identificar las Lecciones Aprendidas e integrarlas a la Base de Conocimiento. Como
ejemplo, se pueden considerar mejores prácticas, experiencias exitosas de manejo de
riesgos, problemas recurrentes, entre otras.
A6.6 Generar el Reporte de Mediciones y Sugerencias de Mejora.
Nivel 4 - Proceso Predecible
# Descripción de la actividad (¿qué se debe hacer?)
A6.7 Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de
inicio y fin, responsable por actividad y mediciones requeridas.
La Programación Extrema (XP) tiene como objetivo principal “construir software”
utilizando grupos pequeño o medianos de programadores en donde los requerimientos no están
muy claros y que cambian rápidamente o suelen ser de alto riesgo. Por lo tanto, para
implementar el proceso de Desarrollo y Mantenimiento de Software se utilizaran las prácticas
de XP en combinación con algunas de Scrum.
Objetivo ¿Cómo lo cumple Extreme Programming?
O1
aa El producto se desarrolla en pequeñas iteraciones, y antes de liberar el producto
es sometido a una revisión continua mediante la planeación de pruebas e
integración continua, lo que asegura que el producto es consistente.
O2
aa
La realización de ciclos posteriores está relacionado al igual que en Scrum, a
los requerimientos del cliente, ya que él decide las historias que se
seleccionaran para cada iteración. Además Extreme Programming, hace uso de
la Refactorización y el uso de Estándares de Codificación, lo que hace posible
y más rápido el mantenimiento de un proyecto.
O3
aa
Al igual que en Scrum no existe un plan fijo para el proyecto. Antes de iniciar
un nuevo ciclo los programadores estiman cuanto esfuerzo requiere cada
128
historia y a partir de ahí se define un cronograma.
Conclusión
Utilizando las Prácticas Ágiles de Extreme Programming se puede lograr los objetivos de este
proceso de manera general, ya que estas prácticas permiten desarrollar un producto
consistente mediante la integración continua y planificación de pruebas. Y al igual que Scrum
no se basa en un Plan fijo, sino que se adapta a los cambios a través de las diferentes
iteraciones que se necesitan para construir cada parte del producto de software que el cliente
necesita. Y esto se logra gracias a las tecnologías que usan para la construcción y a la
aplicación disciplinada de las prácticas que utiliza este método.
A continuación se muestran las Prácticas, Valores y Principios que ayudan a conducir
las actividades descritas en cada una de las fases que dicta la norma y las razones del porque
puede ser conducida a través de dichas Prácticas.
A1 REALIZACIÓN DE LA FASE DE INICIO
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.1
aa
S.P.Reunión de Planificación
XP.V.Comunicación
XP.V.Retroalimentación
XP.V.Coraje
En las reuniones participan todos los miembros
del equipo, todos pueden opinar y comunicarse
cara a cara para lograr su entendimiento. Y el
compromiso tiene lugar de forma iterativa en
estas reuniones.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A1.2
aa
S.P.Reunión Diaria
S.P.Reunión de Revisión
En la reunión diaria todos los miembros del
equipo dicen las tareas en las que están
trabajando y cuánto tiempo les falta por
concluirlas. Cada uno sabe cuáles son sus
actividades, responsabilidades. Y la medición se
hace mediante el código.
129
A2 REALIZACIÓN DE LA FASE DE REQUERIMIENTOS
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A2.1
aa
S.F.Desarrollo
S.P.Reunión de planificación
S.P.Sprint
XP.F.Planeación
En la reunión de planificación del Sprint
Backlog se determinan las tareas, el esfuerzo
que necesita cada una, y se asignan a las
personas del equipo.
A2.2
aa
S.P.Sprint
S.A.Historias de Usuario
XP.A.Historias de Usuario
Las historias de usuario en ambos métodos
ágiles son la parte esencial de la especificación
de requerimientos y éstas son las que permiten
la evolución del producto.
A2.10
aa
S.P.Reunión de Revisión
S.F.Post-Game
XP.F.Muerte
El manual de usuario está incluido en la
liberación final del producto. Pero además
recordemos que en cada iteración se hace parte
de la documentación, entre ella el manual de
usuario.
A2.13
aa
XP.F.Liberación
XP.P.Metafora
XP.P.Diseño Simple
XP.V.Comunicación
Los requerimientos están presentes en cada
iteración, especialmente los requerimientos del
cliente.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A2.3
A2.4
A2.5
A2.6
aa
S.F.Reunión de Revisión
XP.P.Pruebas
XP.P.Refactorización
XP.P.Programación en Pares
XP.P.Integración Continua
XP.P.Estándares de
Codificación
Asegurar que el producto de software cumple
con las especificaciones y satisface las
necesidades del usuario, se le conoce como
Validación y Verificación.
La Validación tiene como objetivo asegurar que
el producto cumpla con las expectativas del
cliente y la Verificación es comprobar que el
producto de software este desarrollado de
130
acuerdo con sus especificaciones, es decir, que
cumpla con los requerimientos funcionales
definidos en la planificación del sprint para el
siguiente incremento.
En la reunión de planificación el propietario del
producto y el equipo obtienen un feedback clave
para evolucionar y dar valor al producto. No se
corrigen defectos se mejora el sistema utilizando
las prácticas de XP para obtener un producto
que satisfaga los requerimientos del cliente.
A2.7
A2.8
A2.9
aa
XP.P.Pruebas Las Pruebas son una práctica crucial en el uso
de XP. Por un lado están las pruebas unitarias,
las cuales se centran en que cada detalle técnico
esté funcionando correctamente. Y por otro,
están las pruebas de aceptación, que aseguran
que cada requerimiento del cliente está
funcionando correctamente.
A2.11
A2.12
aa
S.F.Post-Game
XP.F.Muerte
El manual de usuario dentro de la
documentación final del producto que se entrega
en la última fase tanto de Scrum como de XP.
A2.13
aa
XP.P.Diseño Simple
XP.P.Pruebas
XP.A.Historias de Usuario
XP.V.Comunicación
XP.V.Simplicidad
Los elementos que forman parte de la
configuración de software en XP son el código,
el diseño, las pruebas y los requerimientos
(Historias de Usuario). Y a través de la
Comunicación y la Simplicidad se puede
retroalimentar para que los proyectos sean
flexibles.
A2.14
aa
S.P.Reunión Diaria
S.P.Reunión de Revisión
En la reunión diaria todos los miembros del
equipo dicen las tareas en las que están
trabajando y cuánto tiempo les falta por
131
concluirlas. Cada uno sabe cuáles son sus
actividades y responsabilidades.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A2.14
r No hay
El software que funciona es la medida principal
de progreso.
A3 REALIZACIÓN DE LA FASE DE ANÁLISIS Y DISEÑO
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A3.1
aa
S.P.Reunión de planificación
En la reunión se determinan las tareas
necesarias, se estima el esfuerzo para realizarlas
y se asignan a cada miembro del equipo.
A3.2
A3.10
aa
XP.A.Historias de Usuario
XP.P.Diseño Simple
XP.P.Propiedad Colectiva
XP.V.Comunicación
XP.V.Simplicidad
El análisis se hace a través de las historias de
usuario, el diseño se desarrolla tan simple como
sea posible. Y a través de la comunicación cara
a cara y a la propiedad colectiva, los miembros
del equipo conocen parte del trabajo del otro.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A3.3
A3.4
aa
S.F.Reunión de Revisión
XP.A.Historias de Usuario
XP.P.Diseño Simple
XP.P.Pruebas
XP.P.Propiedad Colectiva
XP.P.Programación en Par
XP.P.Retroalimentación
XP.Pr.Particiapción del
Cliente
La Verificación se realiza a través de las
pruebas intensivas. Se usan comúnmente
herramientas o entornos de pruebas. Las pruebas
son planeadas y escritas antes de escribir el
código. Los métodos de Verificación son
principalmente probados y revisados en parejas
y se ejecutan constantemente. Y existen en XP
las Pruebas de Aceptación con el Cliente para
hacer la Verificación del Producto. No se lleva
un registro formal porque en cada iteración hay
132
una nueva versión del sistema.
A3.5
A3.6
aa
S.F.Reunión de Revisión
XP.A.Historias de Usuario
XP.P.Diseño Simple
XP.P.Pruebas
XP.P.Retroalimentación
XP.Pr.Particiapción del
Cliente
Tanto en Scrum como en XP, la Validación se
realiza a través de la participación del cliente en
las reuniones y en la revisión de los incrementos
que se desarrollan. Por lo que el principal
criterio de Validación no es el Análisis y
Diseño, sino la Aceptación del Cliente. Ya que
para lograr esto el Cliente es parte del Equipo y
es él quien debe Validar el Incremento en cada
Iteración.
A3.7
A3.8
A3.9
aa
XP.P.Integración Continua
XP.P.Programación en Pares
En XP debe existir una “computadora de
integración” en donde cada pareja de
programadores añade el componente junto con
las pruebas unitarias. Y esto se realiza en pocas
horas o a lo máximo un día. Por lo que no se
sigue un Plan de Pruebas de Integración.
A3.10
aa
XP.P.Diseño Simple
XP.P.Pruebas
XP.A.Historias de Usuario
XP.V.Comunicación
XP.V.Simplicidad
Los elementos que forman parte de la
configuración de software en XP son el código,
el diseño, las pruebas y los requerimientos
(Historias de Usuario). Y a través de la
Comunicación y la Simplicidad se puede
retroalimentar para que los proyectos sean
flexibles.
A3.11
aa
S.P.Reunión Diaria
S.P.Reunión de Revisión
En la reunión diaria todos los miembros del
equipo dicen las tareas en las que están
trabajando y cuánto tiempo les falta por
concluirlas. Cada uno sabe cuáles son sus
actividades y responsabilidades.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
133
A3.11
r No hay El software que funciona es la medida principal
de progreso.
A4 REALIZACIÓN DE LA FASE DE CONSTRUCCIÓN
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.1
aa
S.P.Reunión de planificación
En la reunión se determinan las tareas
necesarias, se estima el esfuerzo para realizarlas
y se asignan a cada miembro del equipo.
A4.2
aa
XP.P.Refactoring
XP.Estándares
XP.P.Programación en Pares
XP usa buenas prácticas para la construcción del
componente o software.
A4.5
aa
XP.P.Inetgración Continua
XP.V.Comunicación
El incremento construido se añade directamente
al sistema. Y todos los miembros del equipo
conocen la relación de clases del producto
software.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.2
aa
XP.P.Pruebas
XP.P.Integración Continua
XP, además de utilizar buenas prácticas de
construcción se software, utiliza pruebas
unitarias. Y para que sean exitosas primero son
planeadas y después se codifica para ejecutar
esas pruebas. La programación en parejas
permite encontrar más rápidamente los defectos
en el código y corregirlos para integrarlos de
manera rápida al incremento de la iteración.
A4.3
A4.4
A4.5
aa
XP.P.Refactoring
XP.P.Estándares de
codificación
XP.P.Programación en Pares
En los métodos ágiles no hay un registro de
rastreo, sin embargo, a través de las tarjetas
CRC se puede saber la relación de clases a nivel
de código, ya que en cada iteración se entrega
134
XP.P.Propiedad Colectiva
XP.P.Integración continua
XP.V.Comunicación
una versión probada del sistema. Por lo que si es
necesario hacer cambios o modificaciones se
utilizan las buenas Prácticas de XP. Todos los
miembros de equipo conocen parte del trabajo
del otro porque nadie es dueño del código, es
decir, todos los son.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A4.6
r No hay El software que funciona es la medida principal
de progreso.
A5 REALIZACIÓN DE LA FASE DE INTEGRACIÓN Y PRUEBAS
Nivel 1 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A5.1
aa
S.P.Reunión de planificación
En la reunión se determinan las tareas
necesarias, se estima el esfuerzo para realizarlas
y se asignan a cada miembro del equipo.
A5.2
aa
XP.P.Integración Continua En XP debe existir una “computadora de
integración” en donde cada pareja de
programadores añade el componente junto con
las pruebas unitarias. Y esto se realiza en pocas
horas o a lo máximo un día.
A5.3
A5.8
A5.11
aa
S.F.Post-Game
XP.F.Muerte
La elaboración o actualización de los manuales
de usuario y operación, están incluidos en la
liberación final del producto.
Nivel 2 – Proceso Administrado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A5.2
aa
XP.P.Integración Continua
XP.P.Pruebas
En XP debe existir una “computadora de
integración” en donde cada pareja de
135
XP.P.Programación en Pares programadores añade el componente junto con
las pruebas unitarias. Las pruebas unitarias se
centran en cada detalle técnico para que
funcione correctamente.
A5.4
A5.5
aa
S.F.Post-Game
XP.F.Muerte
El Manual de Operación está incluido dentro de
la documentación final del producto que se
entrega en la última fase tanto de Scrum como
de XP.
A5.6
A5.7
aa
XP.P.Pruebas Las pruebas son una Práctica crucial en los
proyectos XP. En XP primero se planifican las
pruebas y después de codifica. Se utilizan
pruebas automatizadas para garantizar el
funcionamiento del sistema.
A5.9
A5.10
aa
S.F.Post-Game
XP.F.Muerte
El Manual de Operación está incluido dentro de
la documentación final del producto que se
entrega en la última fase tanto de Scrum como
de XP.
A5.12
aa
S.P.Reunión Diaria
S.P.Reunión de Revisión
En la reunión diaria todos los miembros del
equipo dicen las tareas en las que están
trabajando y cuánto tiempo les falta por
concluirlas. Cada uno sabe cuáles son sus
actividades, responsabilidades.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A5.12
r No hay El software que funciona es la medida principal
de progreso.
A6 REALIZACIÓN DE LA FASE DE CIERRE
Nivel 2 – Proceso Realizado
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
136
A6.1
A6.2
A6.3
aa
S.F.Reunión de revisión
XP.P.Refactoring
En Scrum y XP el producto está en constante
evolución mediante la integración de nuevos
incrementos. No se hace un mantenimiento en
sí, sino se agrega valor al producto mediante
esta evolución. Además de que XP utiliza una
práctica crucial para ésta evolución que es el
Refactoring. A través del Refactoring es posible
reestructurar el sistema sin cambiar su
comportamiento, por ejemplo eliminando
código duplicado, simplificando funciones,
mejorando el código constantemente, si el
código se está volviendo complicado se debería
modificar el diseño y volver a uno más simple.
A6.4
aa
S.P.Reunión de revisión
La Configuración de Software está compuesta
por el código, diseño, pruebas, requerimientos,
por lo que la línea base esta creada al final de
cada iteración.
A6.7
aa
S.P.Reunión Diaria
En la reunión diaria todos los miembros del
equipo dicen las tareas en las que están
trabajando y cuánto tiempo les falta por
concluirlas. Cada uno sabe cuáles son sus
actividades, responsabilidades.
Nivel 3 – Proceso Establecido
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A6.5
a XP.P.Comunicación
XP.Propiedad Colectiva
La programación en parejas y la propiedad
colectiva de código promueven la comunicación
de conocimiento técnico a través de todo el
equipo.
A6.6
r No hay El software que funciona es la medida principal
de progreso. No hay elementos que conduzcan a
137
la mejora de las tareas.
Nivel 4 – Proceso Predecible
Actividad V, P, Pr, R, F, S, XP Razones de Cumplimiento
A6.7
r No hay Usando los métodos ágiles no se puede saber
cuáles medidas se requieren para el proceso.
Conclusiones
El Proceso de Desarrollo y Mantenimiento de Software tendría niveles alcanzables de
capacidad de procesos utilizando una combinación de Métodos Ágiles sin perder de vista el
concepto de agilidad, como sigue:
Nivel 1 al 100%
Todas las actividades que dice el modelo MoProSoft se ejecutan de
manera ágil en combinando Scrum y XP.
Nivel 2 al 100% Al estilo ágil de acuerdo al Principio 2 del Manifiesto, el software que
funciona es más importante que la documentación exhaustiva. Por esta
razón, se requiere hacer un mayor esfuerzo de interpretación para
alcanzar el nivel 2 de madurez, ya que la mayoría de las actividades dan
un seguimiento mediante la documentación de acuerdo a MoProSoft,
pero muchas de estas actividades inclusive son prácticamente mejores
implementadas a través de la agilidad ya que algunas actividades ya van
implícitas en las practicas de Scrum y XP.
Nivel 3 al 25% La medición no está definida por ninguno de los procesos ágiles ya que la
única unidad de medida en un proyecto ágil es el código. Aunque se
pueden usar herramientas que pueden ayudar a medir la velocidad del
proyecto no aportan información relevante para mejorar el proceso.
Por otra parte, en los métodos agiles no existe una base de conocimiento,
ya que la comunicación entre los equipo de desarrollo es directa cara a
cara, lo que permite transmitir conocimiento con mayor precisión y
riqueza.
Nivel 4 al 0% No es alcanzable usando una combinación de métodos ágiles.
138
A continuación se listan los productos esperados para el Desarrollo y Mantenimiento
de Software de acuerdo a MoProSoft, y los Artefactos o Prácticas que pueden utilizarse en su
lugar.
Nivel 1 - Proceso Realizado
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
DMS.A2 Especificación de Requisitos S.A.Historias de Usuario
DMS.A3 Análisis y Diseño S.F.Arquitectura, XP.P.Diseño Simple
DMS.A4 Componente S.A.Incremento
DMS.A4 Software S.A.Incremento
DMS.A5 Manual de Usuario S.A.Manual de Usuario
DMS.A5 Manual de Operación S.A.Manual de Operación
Nivel 2 - Proceso Administrado
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
DMS.A2...A5 Configuración de Software S.A.Vision Document
S.A.Prodcut Backlog
S.A.Sprint Backlog
DMS.A6 Manual de Mantenimiento XP.P.Refactoring
XP.P.Estandares de Codificación
XP.A.Tarjetas CRC
DMS.A2…A6 Reporte de Actividades S.P.Reunión Diaria
DMS.A3…A5 Registro de Rastreo S.A.Incremento
XP.P.Refactoring
XP.P.Estandares de Codificación
XP.A.Tarjetas CRC
DMS.A3 Plan de Pruebas S.A.Tests
DMS.A5 Reporte de Pruebas del Sistema S.A.Tests
DMS.A3 Plan de Pruebas e Integración S.P.Integración Continua
DMS.A5 Reporte de Pruebas e Integración S.P.Integración Continua
DMS.A2…A6 Reportes de Verificación S.A.Incremento
139
S.P.Reunión de Revisión
DMS.A2…A3 Reportes de Validación S.A.Incremento
S.P.Reunión de Revisión
CO.A1 Plan de Administración de la B.
C.
NO HAY
CO.A2 Diseño de la Base de
Conocimiento
NO HAY
Nivel 3 - Proceso Establecido
# Producto esperado (MoProSoft) Práctica o Artefacto Ágil (Scrum o XP)
GPR.A2 Documentación del Proceso El Ciclo Scrum y XP
GPR.A3 Reporte de Mediciones y
Sugerencias de Mejora
NO HAY
GPR.A3 Lecciones Aprendidas XP.V.Comunicación
GPR.A3 Plan de Mediciones del Proceso NO HAY
GPR.A3 Reporte Cualitativo y Cuantitativo
del Proceso
NO HAY
Conclusión
La mayoría de los productos esperados por los niveles 1 y 2 son generados de manera ágil por
Scrum y XP, muchos de estos productos están implícitos dentro de las prácticas ágiles de
estos métodos. Aunque si hay que recalcar que se debe hacer un esfuerzo de interpretación si
se desea no perder de vista la agilidad.
Finalmente los roles quienes son los responsables de llevar a cabo las actividades de
uno o más procesos de acuerdo a MoProSoft, son de manera natural conducidos a través de los
roles de Scrum y XP:
Rol (MoProSoft) Rol Scrum o XP
Grupo Directivo S.R.Scrum Director
XP.R.Director
Responsable del Proceso S.R.Scrum Manager
140
XP.R.Coach
Cliente S.R.Cliente
Involucrado S.R.Product Owner
S.R.Scrum Team
XP.R.Programador
XP.R.Tester
XP.R.Tacker
XP.R.Consultor
Los roles que proponen tanto MoProSoft y los métodos agiles son pocos, por lo tanto,
es posible hacer una correspondencia correcta para cumplir con los roles que propone la
norma.
4.4 Implementación
En base a la correspondencia de prácticas ágiles para el cumplimiento con los requisitos que
exige el modelo MoProSoft mostrados en los puntos 4.2 y 4.3, y a la necesidad que tiene el
Área de Ingeniería de Costos e Informática (UICI) de la empresa donde se llevó a cabo la
implementación, cuyos procesos implantados están más enfocados por generar
documentación, se implementan los procesos de Administración de Proyectos Específicos y
Desarrollo y Mantenimiento de Software con la finalidad de crear un ambiente de trabajo
flexible que dependa más de las personas y donde los procesos se asemejen mas a
procedimientos o rutinas de trabajo.
4.4.1 Implementación de los procesos
La Unidad de Ingeniería de Costos e Informática, es un área clave para la empresa. Ya que
uno de sus objetivos específicos es, proporcionar a las demás áreas herramientas tecnológicas
que ayuden a la realización de sus actividades de manera más eficiente y confiable.
Para los procesos se han definido los siguientes roles, de acuerdo al personal que
labora en el área y que tiene los conocimientos necesarios para el desarrollo de aplicaciones y
141
sistemas de información. Para la descripción de actividades y definición de plantillas de
artefactos se tomaron como referencia los propuestos por Scott Ambler120 y Juan Palacio121.
Nombre Acrónimo Descripción
Jefe del Área
Informática JAI
Encargado de la Jefatura del Área de Ingeniería de
Costos, Informática y Desarrollo de Aplicaciones
(Product Owner).
Equipo de Desarrollo EQU Equipo de Desarrollo (Scrum Team).
Scrum Manager SM Responsable de que la Metodología Scrum se aplique
en el desarrollo (Scrum Manager).
Área Usuaria AU Área Usuaria quien solicita el desarrollo o modificación
de un producto de Software (Cliente).
El proceso de Administración de Proyectos Específicos es implementado a través de la
interpretación de las mejores prácticas de Scrum y XP que menciona esta guía y es mostrado
en la figura 4.3.
120 Ambler, S. Agile Models Distilled: Potential Artifacts for Agile Modeling.
http://www.agilemodeling.com/artifacts/. 121 Palacio, J. 2008. Flexibilidad con Scrum: safeCreative.
142
Administración de Proyectos Específicos
SM
EQ
UJA
I, E
QU
JAI,
SM
, EQ
UA
U
INICIO
A1. SOLICITA NUEVO PRODUCTO DE SOFTWARE O
MODIFICACIÓN DE ALGUNO EXISTENTE
A3. SE DEFINE EL PRODUCTO QUE SE VA A DESARROLLAR
(ANEXO 2)
A5. SE DEFINE EL EQUIPO,
HERRAMIENTAS Y OTROS RECURSOS
A8. SE DEFINE EL DISEÑO DE ALTO
NIVEL(ANEXO 4)
A9. REUNIÓN PARA PLANIFICAR EL
SPRINT
A11. DEFINIR OBJETIVOS Y
FUNCIONALIDADES DEL SPRINT
A2. SE DEFINE LA VISIÓN DEL PROYECTO(ANEXO 1)
A12. SELECCIONA EL TRABAJO QUE
CONSIDERE PUEDA TERMINAR
A14. HACE ESTIMACIONES DEL SPRINT BACKLOG
A13. DESCOMPONE EL PRODUCT BACKLOG
EN TAREAS (ANEXO 5)
A15. DESARROLLA EL SPRINT
A16. REUNIÓN DIARIA
HAY IMPEDIMENTOS?
A18. RESUELVE IMPEDIMENTOS
SI
A19. ACTUALIZA GRAFICO DE AVANCE
NO
CONCLUYO SPRINT?
SI
NO
A20. REVISIÓN DE SPRINT
(INCREMENTO)
REQUERIMIENTOS COMPLETADOS?
A21. LIBERACIÓN DEL SISTEMA
INCLUYENDO DOCUMENTACIÓN
FINAL Y CAPACITACIÓN
SI
NO
FIN
SI
NO
A7. RESUELVE IMPEDIMENTOS
HAY IMPEDIMENTOS?
1 2
1
2
A4. ESTIMA Y PRIORIZA EL
PRODUCTO BACKLOG(ANEXO 3)
A10. PRODUCT BACKLOG DE MAYOR
PRIORIDAD
A6. PREGUNTA SI HAY ALGÚN IMPEDIMENTO
(RIESGO)
A17. PREGUNTA SI HAY ALGÚN
IMPEDIMENTO (RIESGO)
Figura 4.3 Diagrama del Proceso de Administración de Proyectos Específicos.
NO. ROL DESCRIPCIÓN DE LA ACTIVIDAD
A1 AU Solicita al Jefe de la unidad que se le desarrolle un nuevo
producto de software.
A2 JAI, SM, EQU, AU Establecen la visión del producto (Anexo 1).
A3 JAI, SM, EQU, AU
Definen los requisitos del sistema, es decir, el inventario de
características que se desea obtener y con esto, se construye el
Prodcut Backlog (Anexo 2)
A4 JAI, SM, EQU
Estiman y enlistan por orden de prioridad las características del
producto que se desea desarrollar auxiliándose de la Tarjeta de
Producto (Anexo3)
A5 JAI, SM, EQU
Definen el equipo de trabajo, evalúan las herramientas de
desarrollo con las que se cuenta en la empresa, así como sus
licencias y definen si son necesarios otros recursos.
A6 SM Analiza si existe algo que impida realizar el proyecto.
143
A7 SM Hace todo lo posible para resolver los impedimentos que suelen
surgir antes de iniciar con el desarrollo del proyecto.
A8 JAI, SM, EQU
Conceptualizan y analizan el proyecto para determinar si es una
mejora a un nuevo existente, y así realizar un diseño de
arquitectura. Se puede utilizar un diagrama de Modelo de
Dominio o los que sean necesarios para definir paquetes basados
en la lista del Product Backlog.
A9 JAI, SM, EQU
Se reúnen para iniciar con la planificación de la iteración. Al
llegar a esta actividad el equipo ya tiene conocimiento de las
tecnologías que se emplearan y juicios expertos para hacer
estimaciones del producto que se quiere desarrollar.
A10 JAI, EQU
Se reúnen para presentar las funcionalidades o requerimientos
que tienen más prioridad para su desarrollo. Se debe presentar
con un nivel de detalle suficiente para transmitir al equipo toda
la información necesaria.
A11 JAI, EQU
Definen el objetivo de la iteración para que todo el equipo
conozca las razones y los detalles con el nivel necesario para
poder estimar el trabajo.
A12 EQU
Selecciona las tareas que considere se puedan terminar en la
iteración sin dejar de tomar en cuenta la prioridad del Prodcut
Backlog.
A13 EQU Descompone la lista del Product Backlog en tareas.
A14 EQU Hace las estimaciones de las tareas, pero estas estimaciones solo
sirven para asignar las tareas a la iteración.
A15 EQU Desarrolla las tareas del Sprint Backlog.
A16 JAI, SM, EQU
Se reúnen no más de 15 minutos para decir las tareas que se
están desarrollando para actualizar el Sprint Backlog de las
tareas terminadas y los tiempos de trabajo que quedan. Para
ayudar a esta práctica, cada miembro debe responder a tres
preguntas:
144
¿Qué tarea trabajaron ayer?
¿Cuáles son las tareas en las que trabajaran hoy?
¿Qué necesitan para realizar su trabajo?
A17 SM Pregunta si hay algo que les impida continuar con su trabajo.
A18 SM Hace lo posible y lo necesario para resolver el impedimento en
el momento que se presente.
A19 SM Actualiza el gráfico del avance del sprint día a día que ayuda a
revelar de forma temprana posibles desviaciones.
A20 JAI, SM, EQU, AU
Revisan el incremento construido durante la iteración, para
generar una retro-alimentación entre todos para preparar el
desarrollo de la siguiente iteración. O si ya no hay mas
iteraciones se comienza la liberación.
A21 JAI, EQU
Hacen la liberación del sistema, incluyendo la documentación
final y la capacitación necesaria para los usuarios y clientes del
sistema.
El proceso descrito anteriormente proporciona los elementos necesarios para la
administración de los proyectos que se desarrollan de manera interna en la empresa donde se
llevo a cabo la implementación. Este proceso puede cambiar conforme se vayan desarrollando
más proyectos que ayuden a la mejora continua.
El proceso de Desarrollo y Mantenimiento de Software es implementado a través de la
interpretación de las mejores prácticas de Scrum y XP que menciona esta guía y es mostrado
en la figura 4.4.
145
PR
O, P
RO
, TES
AU
Figura 4.4 Diagrama del Proceso de Desarrollo y Mantenimiento de Software
NO. ROL DESCRIPCIÓN DE LA ACTIVIDAD
A1 PRO, PRO, TES Selecciona una o varias tareas del Sprint Backlog.
A2 PRO, PRO, TES
Comienza a desarrollar la tarea haciendo sus diseños lo más
simple posible para que el mayor valor al área usuario sea
entregado por el programa más sencillo que cumpla con los
requerimientos.
A3 PRO, PRO, TES, AU
Crea una prueba unitaria, es decir código adicional que
ejecuta un aspecto de una pieza de código producido. Se
pueden utilizar herramientas para hacer el TDD.
A4 PRO, PRO, TES Produce el código necesario para cumplir con la
funcionalidad que el producto debe tener.
A5 PRO, PRO, TES Prueban (Tester) el código construido con la prueba unitaria.
A6 PRO, PRO, TES Refactorizan sin piedad si la prueba falla, es decir, modifican
el código para que funcione la prueba unitaria.
146
A7 PRO, PRO, TES Llevan a cabo la integración continua en pocas horas o
máximo un día.
A8 PRO, PRO, TES
Hacen las pruebas necesarias a todo el sistema
inmediatamente después de que ya se integraron las nuevas
funcionalidades.
A9 PRO, PRO, TES Buscan los errores de programación cuando las pruebas de
integración fallaron.
A10 PRO, PRO, TES
Desechan el código y se vuelve a la actividad A2 sí después
de un cierto tiempo no se encontraron los errores al probar el
sistema completo.
A11 PRO, PRO, TES
Ejecutan las pruebas de aceptación con el área usuaria, para
ver si satisface los requerimientos que se establecieron en el
Product Backlog. Si las pruebas NO son aceptadas ir a la
actividad A2.
A12 PRO, PRO, TES Revisan si hay más tareas en el Sprint Backlog. Si hay más
tareas ir a la actividad A1. Si No hay más tareas terminar.
El proceso de Desarrollo y Mantenimiento de Software al igual que el proceso de
Administración de Proyectos Específicos, proporciona los elementos necesarios para la
construcción de los productos de software que se hace de manera interna en la empresa donde
se llevo a cabo la implementación. Este proceso puede cambiar conforme se vayan
desarrollando más proyectos que ayuden a la mejora continua.
4.4.2 Desarrollo de un proyecto piloto
Para poner en práctica los procesos implementados, se desarrollará un proyecto piloto
exclusivamente para el área de Bienes Informáticos de la empresa.
El objetivo final del sistema será llevar a cabo el control de inventario de bienes
informáticos de toda la entidad, entiéndase por bienes informáticos; el equipo de computo,
impresoras y equipo diverso (reguladores, scanner, etc.). El sistema debe permitir agregar y
modificar las características de cada equipo seriado que hay en la entidad. Debe también
permitir buscar los equipos registrados, asignar o re-asignar los equipos a los usuarios que lo
147
soliciten e identificarlo con único numero para cada resguardo y restringir el acceso mediante
la autenticación de usuarios.
Además el sistema debe estar disponible las 24 horas y debe poder ser operado desde
cualquier terminal con acceso a la intranet de la empresa.
De acuerdo a los requerimientos del área usuaria, las funcionalidades más importantes que
se identificaron durante la reunión fueron:
§ Como administrador, quiero decidir quién puede controlar el inventario y tener
acceso a la información que administra.
§ Como administrador o coordinador quiero registrar los nuevos equipos.
§ Como administrador o coordinador, quiero modificar la información registrada de
los equipos.
§ Como administrador o coordinador, quiero dar de baja un equipo.
§ Como administrador o coordinador, quiero asignar o re-asignar el equipo a un
empleado de cualquier área.
§ Como administrador o coordinador, quiero imprimir el resguardo del equipo que un
usuario tiene asignado.
§ Como usuario, quiero consultar la información desde cualquier lugar.
Se decidieron hacer tres iteraciones de una semana cada una, utilizando los procesos
propuestos se desarrolló la aplicación y se documentó lo más importante para el área
encargada del desarrollo de aplicaciones. La documentación se presenta al final del
documento, a partir del Anexo 8, y muestran los resultados obtenidos en el desarrollo del
proyecto piloto. Estos resultados mostraron que se puede desarrollar un producto de software
que cumpla con las expectativas del cliente, en este caso el área usuaria, utilizando procesos
que fueron definidos a partir de las prácticas ágiles expuestas en esta guía. Sin embargo, es
necesario seguir entrenando al equipo de desarrollo para que conozcan y dominen dichas
prácticas, ya que hay tener presente que en la agilidad todo depende del equipo de desarrollo,
el cual debe ser de muy alto nivel.
148
CONCLUSIONES
En la actualidad existe una gran variedad de metodologías, modelos y estándares para
desarrollar software. Por un lado están las modelos tradicionales como el modelo en
cascada, donde el desarrollo de un producto de software se hace dividido en etapas de
manera estructurada y secuencial, y donde se requiere de un gran esfuerzo para lograr
desarrollarlo con éxito. Por otro lado, existen lo modelos de procesos y estándares de
calidad, que no solamente se enfocan en la parte técnica del desarrollo sino que hace
mayor énfasis en la planificación y control del proyecto, en la especificación precisa de
requerimientos y el modelado, y que además imponen una disciplina para trabajar
sobre procesos, es decir, todo un conjunto de actividades, métodos, prácticas,
transformaciones y productos que las personas deben utilizar y generar para desarrollar
el software basados en un enfoque predictivo que intenta obtener la mayor parte de la
información al inicio del proyecto. Y finalmente están los métodos ágiles, los cuales se
ha popularizado en los últimos años porque permiten a los desarrolladores de software
incorporar cambios en los requerimientos y cambios en las tecnologías durante todo el
proceso de desarrollo de sus productos, obteniendo la información en cualquier parte
del ciclo de desarrollo y no solamente al inicio, lo que permite que el desarrollo de
productos software con requerimientos y variables desconocidos tengan éxito, ya que
su base de trabajo no son los procesos, sino los valores de trabajo de las personas, por
lo que a veces se les considera metodologías informales debido a la poca
documentación que generan en cada uno de sus proyectos. Por lo tanto se puede decir
que el objetivo o finalidad de cada una de estas maneras de desarrollar software es la
misma, es decir, que el proyecto de desarrollo de software tenga éxito y que se obtenga
un producto de software con calidad que no solamente satisfaga las necesidades del
cliente sino también que agrega valor a su negocio.
Si una organización desea utilizar alguno de los modelos o estándares de
calidad que existen en el mercado para agregar tal valor a su negocio, debe tener
completa certeza de porqué desea adoptar dicho modelo. Primeramente, se puede
implantar el modelo simplemente por tener en la empresa el sello de la certificación o
verificación, lo cual permitiría entrar en un en entorno mucho mejor de competitividad.
149
Segundo, se puede utilizar el modelo o estándar simplemente para inspirarse en él y
mejorar los procesos de la empresa internamente sin conseguir el sello. Y finalmente,
se puede adoptar el modelo o estándar para mejorar los procesos de la empresa y
evaluarse para obtener el sello de calidad.
Cualquiera que sea la razón para adoptar un modelo de procesos, se debe
considerar también el tamaño de la organización. Si es una pequeña o mediana
empresa, se puede entonces adoptar un modelo como MoProSoft, el cual se ajusta a las
necesidades de las empresas mexicanas. Este modelo se apoya bastante en el uso de
plantillas y documentos con la finalidad de controlar la forma en que el producto de
software construido y documentado y establece la forma en que el flujo de producción
se lleva a cabo, y así de esta manera, a través de sus nueve procesos poder sistematizar
las prácticas y homogeneizar sus productos de trabajo. La ventaja de este modelo es
que se pueden extraer parte de sus procesos para implementarlos en cualquier
organización, tal como se hizo en esta propuesta.
Se tomaron del modelo MoProSoft, el Proceso de Administración de Proyectos
Específicos y el Proceso de Desarrollo y Mantenimiento de Software para
implementarlos no como sugiere la norma, sino a través de las Prácticas, Valores y
Principios utilizados en los métodos agiles Scrum y Extreme Programming, tratando de
cumplir con los objetivos de cada proceso.
Tratar de implementar un modelo de procesos como MoProSoft a través de la
agilidad, resulta para algunos algo contraproducente, debido a que se podría pensar que
un modelo es mejor que otro y viceversa, además de que en la agilidad, de acuerdo al
manifiesto ágil, se valora a los individuos y su interacción, por encima de los procesos
y herramientas, lo que puede resultar en un enfrentamiento de razones para justificar el
uso de uno y uso de otro. De cualquier manera, el objetivo de esta propuesta no es una
mezcla de MoProSoft y Agilidad, sino un equilibrio en los procedimientos para tener
soluciones lo más claras posibles, pero no ineficientes. Es por ello, que solo se extrajo
la parte Operativa de MoProSoft, porque los métodos agiles hacen más énfasis en
temas técnicos, tecnologías y código y no se ocupa en los temas del negocio y procesos
como en las otras categorías de MoProSoft.
150
Para lo anterior hay que tener claro varias cosas. Cuando se tiene un modelo de
procesos, hay veces que la persona es quien ayuda al proceso ya que todo el peso del
conocimiento lo tiene el proceso y hay otras veces que el peso del conocimiento lo
tiene la persona, en los métodos agiles siempre el peso del conocimiento lo tienen las
personas a través de su talento y motivación ya que todo en la agilidad dependerá de
las personas que conformen el equipo de desarrollo, lo que podría ser un requisito
imprescindible, contar con un equipo de muy alto nivel. En el desarrollo de software no
nos ayuda mucho que el proceso tenga la mayor parte del conocimiento porque sería
muy difícil conseguir un producto de software con calidad si la persona no tiene
conocimientos y habilidades para el análisis, el diseño y uso de patrones, herramientas
y estándares para la construcción del software.
Otra cosa importante es que mientras en un modelo como MoProSoft se tienen
que hacer evaluaciones de los procesos para lograr la mejora, en los métodos agiles las
personas se comprometen a mejorar a través de la confianza que se les brinda y en
intervalos regulares, el equipo debe reflexionar para lograr ser más efectivos y
descubrir la manera de cambiar sus conducta para lograrlo. Y finalmente hay que tener
claro, que tener procesos claramente definidos no es sinónimo de tener buenos
procesos. En la agilidad los procesos son considerados procedimientos, rutinas de
trabajo o actividades, por lo que no existen las fases de desarrollo administración y
desarrollo como propone MoProSoft, por lo que puede resultar difícil tratar de hacer un
mapeo para encontrar la correspondencia entre las prácticas de cada fase de MoProSoft
y las prácticas de los métodos agiles.
Por lo anterior se llevó a cabo la implementación de la guía, tratando de no
perder de vista el concepto de agilidad basado en los cuatro principios del manifiesto
ágil y por supuesto cumplir al mismo tiempo con los objetivos de los procesos de
operación de MoProSoft. Los resultados obtenidos en el desarrollo del proyecto piloto
mostraron que se puede desarrollar un producto de software que logre satisfacer las
necesidades del cliente generando poca documentación para ello, basado en la
implementación de los dos procesos de operación utilizando las prácticas ágiles. Sin
embargo existen factores que se deben refinar, por ejemplo, los integrantes del equipo
deben conocer muy bien las prácticas de los métodos ágiles expuestos aquí, también
151
deben estar comprometidos con los valores para lograr una comunicación efectiva y
quitar los malos hábitos que durante varias décadas fueron formando a los
profesionistas que desarrollan software. Pero lo más importante que se descubrió en el
desarrollo del proyecto, es que se logró tener mayor visibilidad tanto del seguimiento
del proyecto como de algunas situaciones personales que de alguna manera afectan al
proyecto lo que nos brinda un modelo que es comprensible de seguir a nivel de
operación, teniendo en cuenta que MoProSoft nos propone un camino para estar mejor
organizados, inclusive a niveles más altos, como el de dirección y gerencial, pero los
métodos agiles no se ocupan de estos temas de negocio.
En resumen, los métodos ágiles ayudan a desarrollar productos de software de
manera incremental, es decir, que mediante una iteración se puede tener una versión
lista para ser utilizada por el cliente o usuario más que una versión solo funcional, en
los métodos ágiles el cliente es parte del equipo de desarrollo, se utilizan pocos
artefactos y pocos roles, se hace menos énfasis en la arquitectura del software y puede
ser utilizado por equipos muy pequeños de desarrollo. MoProSoft también puede ser
implementado por equipos pequeños de desarrollo, utiliza más artefactos pero pocos
roles, el cliente no es parte del equipo sino que interactúa con él mediante las
reuniones, tiene procesos más controlados con políticas y está basado en otros modelos
y estándares que se utilizan para organizaciones más grandes. Pero utilizando una
combinación de métodos ágiles se puede cumplir con los objetivos de MoProSoft para
la verificación, validación, integración, documentación y configuración exclusivamente
para la Categoría de Operación, aunque si hay que recalcar que lo hace de manera
distinta a la que propone el modelo.
Por consiguiente, si se decide utilizar MoProSoft como modelo de referencia, entonces
es posible adoptar los procesos de operación e implementarlos usando prácticas agiles.
Y esto es posible debido a que metodológicamente coinciden.
Pero si se pretende utilizar como estándar para recibir una verificación de la
conformidad, entonces será más difícil implementarlo con métodos ágiles ya que por el
momento no se podría alcanzar conformidad con la norma que rige el modelo porque la
forma de evaluación no está acorde para alcanzar la conformidad utilizando métodos
agiles.
152
REFERENCIAS
1. Pressman, R., Ingeniería de Software. Un Enfoque Práctico: Mc Graw Hill, 1998.
2. Oktaba, H. and Piattini, M., Software Process Improvement for Small and Medium
Enterprises: Techniques and Case Studies, 2008.
3. Sommerville, L., Ingeniería del Software: Pearson, 2005, p. 5.
4. IEEE, Standars Collection: Software Engineering, 1993(IEEE Standard 610.12-1990).
5. Palacio, J., Flexibilidad con Scrum, 2008.
6. Oktaba, H., Historia y Futuro de la Ingenieria de Software, Revista Software Gurú,
México.
7. Economía, S. d., Programa para el Desarrollo de la Industria del Software (PROSOFT).
8. VISA and Company, N., Perspectivas de las Pymes en México, 2008.
9. Editorial, E., MexicoIT, Software Guru, 2010.
10. Servicios de TI y Software.
11. SIPSE, Subió 42% la industria del software en México, 2009.
12. Gasca, E. G. and Gutiérrez, A. F., Acerca de la implementación de los modelos de
calidad en la construcción de software en México, Revista Digital Universitaria, 2008,
9(9).
13. Gutiérrez, E., Implementación de modelos de calidad, Software Guru, 2009.
14. NYCE, G., MoProSoft - Un modelo de éxito, Gaceta NYCE, 2010, 1.
15. Evaluación de impacto del programa para el desarrollo de la industria del software
(PROSOFT), Secretaría de Economía, 2009.
16. Figueroa, R. G., Solís, C. J. and Cabrera, A. A., Metodologías tradicionales versus
metodologías ágiles, Universidad Técnica Particular de Loja, 2006.
17. Laplante, P. A., What every engineer should know about software engineering: CRC
Press, 2007, pp. 23-24.
18. Cockburn, A., Agile Software Development: The Cooperative Game (Agile Software
Development Series), 2006.
19. Laplante, P. A., What every engineer should know about software engineering: CRC
Press, 2007, p. 25.
20. Sommerville, L., Ingeniería del Software: Pearson, 2005, p. 63.
153
21. Pressman, R., Ingeniería de Software. Un Enfoque Práctico: Mc Graw Hill, 1998, p.
23.
22. Sommerville, L., Ingeniería del Software: Pearson, 2005, pp. 63-64.
23. Sommerville, L., Ingeniería del Software: Pearson, 2005, p. 373.
24. Pressman, R., Ingeniería de Software. Un enfoque práctico: McGraw Hill, 2002, pp.
21-22.
25. Pressman, R., Ingeniería de Software. Un enfoque práctico: McGraw Hill, 2002, pp.
22-23.
26. Boehm, B. W., A spiral model of software development and enhancement, Computer,
1988, 21(5):61-72.
27. Laplante, P. A., What every engineer should know about software engineering: CRC
Press, 2007, p. 29.
28. Pressman, R., Ingeniería de Software. Un Enfoque Práctico: Mc Graw Hill, 1998, p.
29.
29. Sommerville, L., Ingeniería del Software: Pearson, 2005, pp. 66-67.
30. Pressman, R., Ingeniería de Software. Un enfoque práctico: McGraw Hill, 2002, p. 22.
31. Neill, C. J. and Laplante, P. A., Requirements Engineering: The State of the Practice,
IEEE SOFTWARE, 2003:40-45.
32. Sommerville, L., Ingeniería del Software: Pearson, 2005, pp. 67-68.
33. Nierstrasz, O., Gibbs, S. and Tsichritzis, D., Component-oriented software
development, Communications of the ACM, 1992, 35(9):160-165.
34. Sommerville, L., Ingeniería del Software: Pearson, 2005, pp. 64-65.
35. Pressman, R., Ingeniería de Software. Un enfoque práctico: McGraw Hill, 2002, pp.
28-29.
36. Laplante, P. A., What every engineer should know about software engineering: CRC
Press, 2007, p. 32.
37. IBM.
38. Kruchten, P., The Rational Unified Process: An Introduction: Addison-Wesley
Professional, 2000, pp. Chapter 1-2.
39. Gallego, P. G., Fundamentos de la metodología RUP, Universidad Tecnológica de
Pereira, 2007.
154
40. Kroll, P. and Kruchten, P., The Rational Unified Process Made Easy: A Practitioner's
Guide to the RUP: Addison-Wesley Professional, 2003.
41. Leon, C. and Crawford, B., Métodos ágiles y creatividad en equipos de desarrollo de
software, Suplemento, 2006.
42. Díaz, M. I., La incertidumbre y la ingeniería de software.
43. Warden, S., The Art of Agile Development: O'Reilly Media, Inc., 2007, p. 9.
44. Marchesi, M., Succi, G., Wells, D., Williams, L. and Wells, J. D., Extreme
programming perspectives: Addison-Wesley, 2003.
45. Canós, J., Letelier, P. and Penadés, M. C., Metodologías Ágiles en el desarrollo de
Software.
46. Diaz, S., Métodos Ágiles, Software Guru, 2007.
47. Hunt, J., Agile software construction: Springer, 2006, p. 16.
48. Abrahamsson, P., Salo, O., Ronkainen, S. and Warsta, J., Agile Software Development
Methods: Review and Analysis, Espoo 2002: VTT Publications, 2002, pp. 19-21.
49. Pino, S. L. V. d., Programación Extrema en pocos minutos: Planificando la Transición,
Tono: Revista Técnica de la Empresa de Telecomunicaciones de Cuba S.A.:41-44.
50. Berrueta, D., Programación Extrema y Software Libre, 2006.
51. Sutherland, J., Viktorov, A., Blount, J. and Puntikov, N., Distributed scrum: Agile
project management with outsourced development teams: IEEE, 2007, p. 4597.
52. Hunt, J., Agile software construction: Springer, 2006, pp. 25-26.
53. Abrahamsson, P., Salo, O., Ronkainen, S. and Warsta, J., Agile Software Development
Methods: Review and Analysis, Espoo 2002: VTT Publications, 2002, pp. 29-30.
54. Reynoso, C., Métodos Heterodoxos en Desarrollo de Software, 2004.
55. Abrahamsson, P., Salo, O., Ronkainen, S. and Warsta, J., Agile Software Development
Methods: Review and Analysis, Espoo 2002: VTT Publications, 2002, pp. 47-54.
56. Bañares, J. P., Compendio de Ingeniería de Software II, 2006.
57. Ambler, S., Agile/Lean Documentation: Strategies for Agile Software Development,
2010.
58. Mendoza, L., Pérez, M., Grimán, A. and Rojas, T., Algoritmo para la Evaluación de la
Calidad Sistémica del Software, 2das, Jornadas Iberoamericanas de Ingeniería del
Software e Ingeniería del Conocimiento (JIISIC 2002), 2002:1-11.
155
59. Lomprey, G. and Hernandez, S., La importancia de la calidad en el desarrollo de
productos de software.
60. Ruvalcaba, M., Procesos de Software, Software Guru, 2004.
61. Sistemas de Gestión de Calidad. Fundamentos y Vocabulario: Norma NTC-ISO
9000:2005.
62. Kulpa, M. K. and Johnson, K. A., Interpreting the CMMI: a process improvement
approach: Auerbach Publications, 2008, p. 19.
63. Davenport, T. H., Process Innovation: Reengineering work through Information
Technology: Harvard Business Press, 1993, p. 5.
64. NMX-I-006-/01-NYCE: Normalización y Certificación Electrónica A. C.
65. Bedini, A., Extracto del libro en formato digital “Calidad Tradicional y de Software”:
Universidad Técnica Federico Santa María.
66. Scalone, F., Overview sobre Modelos/Estándares de Calidad del Software, Software
Quality Management, 2006.
67. INTECO, Estudio sobre la certificación de la calidad como medio para impulsar la
industria de desarrollo del software en España, 2008.
68. Mertens, L. and Baeza, M., La Norma ISO 9000 y la competencia laboral: México,
OIT.
69. De la Villa, M., Ruiz, M. and Ramos, I., Modelos de evaluación y mejora de procesos:
Análisis comparativo, 2004.
70. Mutafelija, B. and Stromberg, H., Systematic process improvement using ISO 9001:
2000 and CMMI: Artech House on Demand, 2003, pp. 35-39.
71. Kulpa, M. K. and Johnson, K. A., Interpreting the CMMI: a process improvement
approach: Auerbach Publications, 2008, p. 3.
72. Palacio, J., Sinopsis de los modelos SW-CMM y CMMI, 2006.
73. Kulpa, M. K. and Johnson, K. A., Interpreting the CMMI: a process improvement
approach: Auerbach Publications, 2008, pp. 31-40.
74. Hernández, D., Gutiérrez, H. and Canedo, G., Creación de equipos de alto desempeño,
usando Team, Software Process (TSP) y Personal Software Process (PSP), Universidad
de Guanajuato.
156
75. Oktaba, H. and Piattini, M., Software Process Improvement for Small and Medium
Enterprises: Techniques and Case Studies: Information Science Reference, 2008, pp.
170-171.
76. Pilar, G. G., Moprosoft: Un camino hacia el éxito mundial en el desarrollo de software
mexicano, Software Engineering Process Improvement, 2007.
77. Oktaba, H., Modelo de Procesos para la Industria de Software-MoproSoft-Versión 1.3,
Agosto de 2005: NMX-059/01-NYCE-2005.
78. NMX-I-059-/01-NYCE-2005: Normalización y Certificación Electrónica A. C.
79. NMX-I-059-/02-NYCE-2005: Normalización y Certificación Electrónica A. C.
80. NMX-I-059-/03-NYCE-2005: Normalización y Certificación Electrónica A. C.
81. NMX-I-059-/04-NYCE-2005: Normalización y Certificación Electrónica A. C.
82. Ambler, S., Agile Models Distilled: Potential Artifacts for Agile Modeling, 2010.
157
Anexo 1 Formato de Visión de Producto
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS DOCUMENTO FECHA APE-01-VISION DEL PROYECTO PROYECTO PÁGINA NOMBRE DEL PROYECTO VISIÓN
1
EQUIPO DE TRABAJO
2
INFRAESTRUCTURA DE SOFTWARE Y HARDWARE
3
ARQUITECTURA TECNOLÓGICA DEL SISTEMA
4
1 El uso de métodos ágiles no fomenta la documentación innecesaria. Sin embargo, es importante que el
equipo completo comprenda la esencia del producto que se desea crear. La Visión del Proyecto debe ser lo
más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Una buena práctica
es preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto. La
Visión del Proyecto debe ser descompuesta en un conjunto levemente más detallado de Visiones
entregables, una por incremento construido. Una presentación debe funcionar para su propósito.
2 Muestra el equipo de trabajo que participara en el desarrollo de este proyecto.
3 Muestra los recursos de hardware y software que se necesitan para desarrollar el proyecto.
4 Muestra un diagrama de alto nivel de la composición tecnológica de cómo será construido e integrado el
sistema.
158
Anexo 2 Formato de Product Backlog (Requisitos del Cliente)
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS DOCUMENTO FECHA APE-02-PRODUCT BACKLOG PROYECTO PÁGINA NOMBRE DEL PROYECTO
Los métodos agiles prefieren la comunicación directa, antes que realizarla a través de documentos. El
PRODUCT BACKLOG no es un documento de requisitos, sino una herramienta que sirve de referencia para
el equipo. Se recomienda que el formato de lista incluya al menos la siguiente información para cada línea:
ID Nombre IMP. DESCRIPCIÓN
1 2 3 4
1 Identificador único del producto
2 Nombre de la funcionalidad del producto
3 Grado de importancia de acuerdo al propietario del producto
4 Descripción del producto
Si el proyecto, el funcionamiento del equipo o la organización lo requieren, se pueden utilizar otros
campos, como por ejemplo.
5 Observaciones
6 Notas
Se puede utilizar para su desarrollo:
§ Tablas de procesador de texto
§ Una hoja de cálculo (recomendable)
§ Una herramienta de administración de proyectos
159
Anexo 3 Formato de Tarjeta de Producto
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS DOCUMENTO FECHA APE-03-TARJETA DE PRODUCTO PROYECTO PÁGINA NOMBRE DEL PROYECTO
TARJETAS DE PRODUCTO
ID 1 IMPORTANCIA 6 NOMBRE 2 BREVE DESCRIPCIÓN ESTIMACIÓN 3 7 COMO DEMOSTRARLA 5 SPRINT 4
1 Identificador único del producto
2 Nombre del producto
3 Breve descripción del producto
4 Numero de Sprint al que pertenece este producto
5 Una descripción a alto nivel de como se demostrará en la revisión del Sprint
6 Grado de importancia
7 Puntos de estimación del producto
160
Anexo 4 Formato de Arquitectura/Diseño de Alto Nivel
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS DOCUMENTO FECHA APE-04-DISEÑO DE ALTO NIVEL PROYECTO PÁGINA NOMBRE DEL PROYECTO
El Diseño de Alto Nivel del producto de software incluye la arquitectura basada en la lista de los ítems del
PRODCUT BACKLOG. Si se trata del mejoramiento de un producto existente, se deben identificar los
cambios necesarios para la implementación de los requisitos que el cliente pide con los problemas que se
puedan generar.
161
Anexo 5 Formato Sprint Backlog
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS DOCUMENTO FECHA APE-05-SPRINT BACKLOG PROYECTO PÁGINA NOMBRE DEL PROYECTO
El SPRINT BACKLOG es una lista de tareas que define el trabajo que el equipo de desarrollo debe realizar
durante un sprint. Cada tarea identifica quién es responsable de hacer el trabajo y un estimado de la
cantidad de trabajo faltante para la tarea durante cualquier día de la iteración. Es también una
herramienta de apoyo para la comunicación directa del equipo. Se recomienda que el formato de lista
incluya al menos la siguiente información para cada línea:
SPRINT INICIO DURACIÓN
1 2 3 4
TAREAS PENDIENTES 5
HORAS DE TRABAJO PENDIENTES 6
PILA DE SPRINT
BACKLOG TAREA TIPO ESTADO RESPONSABLE ESFUERZO
7 8 9 10 11 12
1 Número de sprint (empieza desde cero)
2 Fecha de inicio del sprint (dd/Mes/aaaa)
3 Duración en días del sprint
4 Desde la fecha de inicio hasta la fecha que dura el sprint
5 Número de tareas pendientes hasta la fecha indicada
6 Horas de trabajo pendientes hasta la fecha indicada
7 Número de PRODUCT BACKLOG a que corresponde
8 Descripción o nombre de la tarea
Se puede utilizar para su desarrollo:
§ Tablas de procesador de texto
§ Una hoja de cálculo (recomendable)
§ Una herramienta de administración de proyectos
162
Anexo 6 Formato de Tarjetas CRC
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE DOCUMENTO FECHA DMS-01-TARJETAS CRC PROYECTO PÁGINA NOMBRE DEL PROYECTO
Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, sus
responsabilidades y sus colaboradores. Una clase es cualquier persona, evento, concepto, pantalla o
reporte. Las responsabilidades de una clase son las cosas que conoce y las que realiza (atributos y
métodos). Los colaboradores de una clase son las demás clases con las que se comunica para llevar a cabo
sus responsabilidades.
1
2 3
1 Nombre de la Clase
2 Responsabilidades
3 Colaboradores
163
Anexo 7 Formato de Prueba de aceptación
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE DOCUMENTO FECHA DMS-02-PRUEBA DE ACEPTACIÓN PROYECTO PÁGINA NOMBRE DEL PROYECTO
PRUEBA DE ACEPTACIÓN ID 1 DESCRIPCIÓN 2 SITUACIÓN 3 INSTRUCCIONES 4 RESULTADOS ESPERADOS
5
1 IDENTIFICADOR ÚNICO DEL PRODUCTO
2 DESCRIPCIÓN DELA PRUEBA
3 SITUACIÓN PARA EJECUTAR LA PRUEBA
4 INSTRUCCIONES PARA LLEVAR A CABO LA PRUEBA
5 RESULTADOS ESPERADOS DESPUÉS DE EJECUTAR LA PRUEBA
164
Anexo 8 Visión del Proyecto
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-01-VISION DEL PROYECTO ENERO 2010 PROYECTO PÁGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/2 VISIÓN
“OFRECER UNA HERRAMIENTA TECNOLÓGICA QUE SIRVA PARA TENER UN REGISTRO DE LOS BIENES INFORMÁTICOS QUE PERTENECEN A ESTA ENTIDAD, CON EL FIN DE TENER UN CONTROL DE LOS MISMOS Y CONTEMPLAR POSIBLES PLANES DE RENOVACIÓN PARA FUTURAS ADQUISICIONES”. EQUIPO DE TRABAJO
ROL NOMBRE Scrum Master Allan Prodcut Owner Rafael
Scrum Team
Idalia Netzer Norberto Erick
INFRAESTRUCTURA DE SOFTWARE Y HARDWARE
SOFTWARE
Sistema Operativo
Windows Server 2008. Ofrece productividad para virtualización de cargas de
trabajo y protección de redes. Y permite un alojamiento confiable de aplicaciones y
servicios web.
Sistema Gestor de
Base de Datos
MS-SQL-Server 2005. Por su compatibilidad nativa con el sistema operativo tanto
de desarrollo como de producción y para aprovechar la licencia que adquirió la
empresa para su explotación.
Servidor de
Aplicaciones
Internet Information Services (IIS). Ya que es el servidor de aplicaciones que incluye
el Windows 2003 Server y que tiene una compatibilidad completa con el Gestor de
Bases de Datos y el .NET Framework.
Plataforma de
Desarrollo
Microsoft .NET Framework. Ya es una nueva plataforma informática que simplifica
el desarrollo de aplicaciones en un entorno distribuido.
165
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-01-VISION DEL PROYECTO ENERO 2010 PROYECTO PÁGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/2
Hardware
Servidor
DELL PowerEdge 2950 con 2 Procesadores Intel Xeon, memorias DIMM DDR2 de
32GB, 6 Discos duro de 146 GB c/u y que tiene instalado Windows 2003 Server
como Sistema Operativo.
Terminales
Computadoras Dell con Sistema Operativo Windows XP Profesional, con procesador
Intel 2.0Ghz y memoria Ram de 1Gb. Todas tienen instalado las herramientas de
desarrollo.
ARQUITECTURA TECNOLÓGICA DEL SISTEMA
166
Anexo 9 Product Backlog
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-02-PRODUCT BACKLOG ENERO 2010 PROYECTO PÁGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/1
ID Nombre IMP. USUARIO DESCRIPCIÓN
H1 Log-In 100 USUARIO Control de acceso para el tipo de
usuario que ingresa.
H2 Alta de usuarios 90 ADMINISTRADOR Agrega nuevos usuarios para que
puedan ingresar al sistema.
H3 Modificación de usuarios 80 ADMINISTRADOR Modifica los datos de los usuarios
registros.
H4 Alta de equipo 70 COORDINADOR Agregar un nuevo registro de
equipo.
H5 Baja de equipo 60 COORDINADOR Hacer una baja lógica del equipo.
H6 Modificación de equipo 40 COORDINADOR Modificar las características de un
equipo.
H7 Asignación de equipo 30 COORDINADOR Se asigna o re-asigna un equipo a
un determinado usuario.
H8 Imprimir resguardo 20 COORDINADOR Se imprime el resguardo
administrativo correspondiente al
usuario.
H9 Consulta de resguardo 10 USUARIO Se puede consultar la información
del resguardo de algún equipo.
167
Anexo 10 Tarjetas de Producto
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-03-TARJETAS DE PRODUCTO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/5
TARJETA DE PRODUCTO ID H1 IMPORTANCIA 100 NOMBRE Log-In BREVE DESCRIPCIÓN ESTIMACIÓN Control de acceso para el tipo de usuario que
ingresa. 5
COMO DEMOSTRARLA Entrar al sistema, introducir usuario y contraseña. Si es usuario registrado aparece
un menú de opciones de acuerdo al perfile de acceso. Si no es usuario registrado enviar un mensaje de alerta.
SPRINT 1
TARJETA DE PRODUCTO
ID H2 IMPORTANCIA 90 NOMBRE Alta de usuarios BREVE DESCRIPCIÓN ESTIMACIÓN Agrega nuevos usuarios para que puedan ingresar
al sistema. 3
COMO DEMOSTRARLA Entrar al sistema como Administrador, entrar a la sección de USUARIOS, ingresar los
datos del usuario. Si ya existe enviar un mensaje de alerta. Si no existe enviar un mensaje de éxito.
SPRINT 1
168
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-03-TARJETAS DE PRODUCTO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/5
TARJETA DE PRODUCTO ID H3 IMPORTANCIA 80 NOMBRE Modificación de usuarios BREVE DESCRIPCIÓN ESTIMACIÓN Modifica los datos de los usuarios registros. 2 COMO DEMOSTRARLA Entrar al sistema como Administrador, entrar a la sección de USUARIOS, seleccionar
de un listado al usuario que se le actualizaran los datos, actualizar los datos. Enviar un mensaje de éxito.
SPRINT 1
TARJETA DE PRODUCTO
ID H4 IMPORTANCIA 70 NOMBRE Alta de equipo BREVE DESCRIPCIÓN ESTIMACIÓN Agregar un nuevo registro de equipo. 5 COMO DEMOSTRARLA Entrar al sistema como Administrador o Coordinador, entrar a la sección de ALTA,
seleccionar el tipo de equipo, introducir la información del equipo. Si el equipo ya existe informar al usuario. Si no existe enviar un mensaje de éxito.
SPRINT 2
169
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-03-TARJETAS DE PRODUCTO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 3/5
TARJETA DE PRODUCTO ID H5 IMPORTANCIA 60 NOMBRE Baja de equipo BREVE DESCRIPCIÓN ESTIMACIÓN Hacer una baja lógica del equipo. 2 COMO DEMOSTRARLA Entrar al sistema como Coordinador o Administrador, entrar a la sección de BAJA,
buscar el equipo por número económico, cambiar el estatus del equipo a BAJA (baja lógica). Enviar un mensaje de éxito de operación.
SPRINT 2
TARJETA DE PRODUCTO
ID H6 IMPORTANCIA 40 NOMBRE Modificación de equipo BREVE DESCRIPCIÓN ESTIMACIÓN Modificar las características de un equipo. 3 COMO DEMOSTRARLA Entrar al sistema como Coordinador o Administrador, entrar a la seccion de
MODIFICAR, buscar el equipo por número económico, actualizar la información del equipo. Enviar un mensaje de éxito de operación.
SPRINT 2
170
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-03-TARJETAS DE PRODUCTO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 4/5
TARJETA DE PRODUCTO ID H7 IMPORTANCIA 30 NOMBRE Asignación de equipo BREVE DESCRIPCIÓN ESTIMACIÓN Se asigna o re-asigna un equipo a un determinado
usuario. 5
COMO DEMOSTRARLA Entrar al sistema como Administrador o Coordinador, entrar a la sección de
ASIGNAR, buscar el equipo por número de resguardo, introducir los datos del empleado que tendrá el equipo a resguardo. Si ya está asignado debe desasignar el equipo automáticamente y después re-asignarlo. Enviar un mensaje de éxito.
SPRINT 3
TARJETA DE PRODUCTO
ID H8 IMPORTANCIA 20 NOMBRE Imprimir resguardo BREVE DESCRIPCIÓN ESTIMACIÓN Se imprime el resguardo administrativo
correspondiente al usuario. 3
COMO DEMOSTRARLA Entrar al sistema como Administrador o Coordinador, entrar a la sección de
IMPRIMIR, buscar el equipo por número de resguardo. Si no existe enviar un mensaje de alerta. Si existe mostrar el resguardo en un formato listo para imprimir.
SPRINT 3
171
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-03-TARJETAS DE PRODUCTO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 5/5
TARJETA DE PRODUCTO ID H9 IMPORTANCIA 10 NOMBRE Consulta de resguardo BREVE DESCRIPCIÓN ESTIMACIÓN Se puede consultar la información del resguardo
de algún equipo. 2
COMO DEMOSTRARLA Entrar al sistema, entrar a la sección de CONSULTA, buscar el quipo, presentar los
datos del equipo.
SPRINT 3
172
Anexo 11 Diseño de Alto Nivel/Arquitectura
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-04-DISEÑO DE ALTO NIVEL ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/3
MODELO DE DOMINIO
Resguardo
Equipo
Administrador
Coordinador
Empleado
CPU
Monitor
Teclado
Mouse
Impresora
EquipoVario
1
1
1 0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
1..*
asignatie
ne
auto
riza
asig
na
administra
administra
perte
nece
173
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-04-DISEÑO DE ALTO NIVEL ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/3
DIAGRAMA DE FLUJO DE DATOS
174
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-04-DISEÑO DE ALTO NIVEL ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 3/3
DIAGRAMA ENTIDAD-RELACIÓN
tbl_cpu
cpu_numero_resguardo int
cpu_numero_economico nvarchar(50)
cpu_numero_serie nvarchar(50)
cpu_marca nvarchar(50)
cpu_modelo nvarchar(50)
cpu_procesador nvarchar(50)
cpu_ram smallint
cpu_disco_duro smallint
cpu_fecha_alta datetime
cpu_tipo nvarchar(50)
cpu_observs nvarchar(100)
cpu_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_empleado
emp_nutra nvarchar(50)
emp_nombre nvarchar(100)
emp_area nvarchar(100)
emp_fecha_alta datetime
Nombre de columna Tipo de datos
tbl_equipo_vario
eqv_id int
eqv_numero_resguardo int
eqv_numero_economico nvarchar(50)
eqv_numero_serie nvarchar(50)
eqv_marca nvarchar(50)
eqv_modelo nvarchar(50)
eqv_descripcion nvarchar(50)
eqv_fecha_alta datetime
eqv_observs nvarchar(100)
eqv_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_impresora
imp_id int
imp_numero_resguardo int
imp_numero_economico nvarchar(50)
imp_numero_serie nvarchar(50)
imp_marca nvarchar(50)
imp_modelo nvarchar(50)
imp_tipo nvarchar(50)
imp_fecha_alta datetime
imp_observs nvarchar(100)
imp_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_monitor
mon_id int
mon_numero_resguardo int
mon_numero_economico nvarchar(50)
mon_numero_serie nvarchar(50)
mon_marca nvarchar(50)
mon_modelo nvarchar(50)
mon_tamanio smallint
mon_fecha_alta datetime
mon_observs nvarchar(100)
mon_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_mouse
mou_id int
mou_numero_resguardo int
mou_numero_serie nvarchar(50)
mou_numero_economico nvarchar(50)
mou_marca nvarchar(50)
mou_modelo nvarchar(50)
mou_fecha_alta datetime
mou_observs nvarchar(100)
mou_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_resguardo
res_nutra nvarchar(50)
res_numero_resguardo int
Nombre de columna Tipo de datos
tbl_teclado
tec_id int
tec_numero_resguardo int
tec_numero_economico nvarchar(50)
tec_numero_serie nvarchar(50)
tec_marca nvarchar(50)
tec_modelo nvarchar(50)
tec_fecha_alta datetime
tec_observs nvarchar(100)
tec_estatus nvarchar(50)
Nombre de columna Tipo de datos
tbl_usuario
usu_usuario nvarchar(50)
usu_password nvarchar(50)
usu_nutra nvarchar(50)
usu_nombre nvarchar(100)
usu_tipo nvarchar(20)
usu_activo bit
Nombre de columna Tipo de datos
175
Anexo 12 Sprint Backlog
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-05-SPRINT BACKLOG ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/5
SPRINT INICIO DURACIÓN1 4-ene-10 5
19 17 11 6 0
68 52 32 20 0
BACKLOG TIPO ESTADO RESPONSABLES
HT1ANÁLISIS Y
DISEÑOTERMINADA IDALIA Y
NETZER- - - - -
HT2ACTIVIDAD
TÉCNICATERMINADA IDALIA Y
NETZER- - - - -
HT3ACTIVIDAD
TÉCNICATERMINADA IDALIA Y
NETZER- - - - -
HT4ACTIVIDAD
TÉCNICATERMINADA IDALIA Y
NETZER- - - - -
HT5ACTIVIDAD
TÉCNICATERMINADA IDALIA Y
NETZER- - - - -
HT6DISEÑO TERMINADA ERICK Y
NORBERTO- - - - -
HT7CODIFICACIÓN TERMINADA ERICK Y
NORBERTO- - - - -
TAREAS PENDIENTES
HORAS DE TRABAJO PENDIENTES
04-e
ne
05-e
ne
06-e
ne
CONFIGURAR EL DIRECTORIO VIRTUAL
INSTALAR EL PROTOTIPO DE SOLUCIÓN EN LA COMPUTADORA DE INTEGRACIÓN
CREAR EL DISEÑO DE LA BASE DE DATOS
INSTALAR LA BASE DE DATOS
SCIBI - SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS
PILA DEL SPRINTESFUERZO
TAREA
CREAR DOCUMENTACIÓN NECESARIA
INSTALAR EL SERVIDOR DE BD DE DESARROLLO
INSTALAR Y CONFIGURAR EL DATA ACCESS APLICATION BLOCK DE LA E.L.
07-e
ne
08-e
ne
H1
H1T1ANÁLISIS Y
DISEÑOTERMINADA IDALIA Y
NETZER- - - - -
H1T2DISEÑO TERMINADA IDALIA Y
NETZER- - - - -
H1T3CODIFICACIÓN TERMINADA IDALIA Y
NETZER8 - - - -
H1T4CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 - - -
H1T5CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 - - -
H1T6CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 4 - -
H1T7PRUEBAS TERMINADA IDALIA Y
NETZER4 4 4 - -
H1T8PRUEBAS TERMINADA IDALIA Y
NETZER8 8 8 8 -
CREACIÓN DEL ENTITY DE USUARIO
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
CREACIÓN DE CONSULTA EN EL DAL DE USUARIO
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
LOG-IN DE USUARIOS
CREACIÓN DE FORMULARIO DE ACCESO
VALIDACIÓN DEL FORMULARIO
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA CONSULTA
176
UNIDAD DE INGENIERÍA DE COSTOS E
INFORMÁTICA DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-05-SPRINT BACKLOG ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/5
H2
H2T1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO- - - - -
H2T2DISEÑO TERMINADA ERICK Y
NORBERTO- - - - -
H2T3CODIFICACIÓN TERMINADA ERICK Y
NORBERTO6 - - - -
H2T4CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 - - -
H2T5CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 2 - - -
H2T6PRUEBAS TERMINADA ERICK Y
NORBERTO2 2 - - -
H2T7PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 - - -
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
CREACIÓN DEL FORMULARIO DE ALTA
VALIDACIÓN DEL FORMULARIO
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA INSERCIÓN
CREACIÓN DE INSERCIÓN EN EL DAL DE USUARIO
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
ALTA DE USUARIOS
H3
H3T1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO1 1 1 - -
H3T2ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO1 1 1 - -
H3T3DISEÑO TERMINADA ERICK Y
NORBERTO2 2 2 - -
H3T4CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 4 4 -
H3T5CODIFICACIÓN TERMINADA ERICK Y
NORBERTO2 2 2 2 -
H3T6CODIFICACIÓN TERMINADA ERICK Y
NORBERTO2 2 2 2 -
H3T7PRUEBAS TERMINADA ERICK Y
NORBERTO2 2 2 2 -
H3T8PRUEBAS TERMINADA ERICK Y
NORBERTO2 2 2 2 -
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA ACTUALIZACIÓN
CREACIÓN DE ACTUALIZACIÓN EN EL DAL DE USUARIO
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
CREACIÓN DE FORMULARIO DE MODIFICACIÓN
MODIFICACION DE USUARIOS
CREACIÓN DEL FORMULARIO DE BUSQUEDA
VALIDACIÓN DEL FORMULARIO
177
UNIDAD DE INGENIERÍA DE COSTOS E
INFORMÁTICA DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-05-SPRINT BACKLOG ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 3/5
SPRINT INICIO DURACIÓN2 11-ene-00 5
14 12 8 4 0
72 56 38 16 0
BACKLOG TIPO ESTADO RESPONSABLES
HT1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO- - - - -
H4
H4T1ANÁLISIS Y
DISEÑOTERMINADA IDALIA Y
NETZER- - - - -
H4T2DISEÑO TERMINADA IDALIA Y
NETZER- - - - -
H4T3CODIFICACIÓN TERMINADA IDALIA Y
NETZER6 - - - -
H4T4CODIFICACIÓN TERMINADA IDALIA Y
NETZER6 4 - - -
H4T5CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 - - -
H4T6CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 4 - -
H4T7PRUEBAS TERMINADA IDALIA Y
NETZER6 6 6 2 -
H4T8PRUEBAS TERMINADA IDALIA Y
NETZER6 6 6 6 -
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
ALTA DE EQUIPO
CREACIÓN DEL FORMULARIO DE ALTA
VALIDACIÓN DEL FORMULARIO
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS ENTITY DE CADA UNO DE LOS TIPO DE EQUIPO
CREACIÓN DE INSERCIÓN EN EL DAL DE EQUIPO
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA INSERCIÓN
TAREAS PENDIENTES
HORAS DE TRABAJO PENDIENTESPILA DEL SPRINT
ESFUERZOTAREA
CREAR DOCUMENTACIÓN NECESARIA
11-e
ne
12-e
ne
13-e
ne
14-e
ne
15-e
ne
SCIBI - SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS
H5
H5T1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO- - - - -
H5T2DISEÑO TERMINADA ERICK Y
NORBERTO- - - - -
H5T3CODIFICACIÓN TERMINADA ERICK Y
NORBERTO8 - - - -
H5T4PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 - - -
H5T5PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 - - -
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
BAJA DE EQUIPO
CREACIÓN DEL FORMULARIO DE BUSQUEDA
VALIDACIÓN DEL FORMULARIO
178
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-05-SPRINT BACKLOG ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 4/5
H6
H6T1CODIFICACIÓN TERMINADA ERICK Y
NORBERTO6 6 6 - -
H6T2CODIFICACIÓN TERMINADA ERICK Y
NORBERTO6 6 4 - -
H6T4CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 4 - -
H6T5PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 4 4 -
H6T6PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 4 4 -
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA ACTUALIZACIÓN
CREACIÓN DE ACTUALIZACIÓN EN EL DAL DE EQUIPO
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
MODIFICACION DE EQUIPO
SPRINT INICIO DURACIÓN3 18-ene-10 5
15 12 8 4 0
64 48 32 16 0
BACKLOG TIPO ESTADO RESPONSABLES
HT1ANÁLISIS Y
DISEÑOTERMINADA IDALIA Y
NETZER- - - - -
H7
H7T1ANÁLISIS Y
DISEÑOTERMINADA IDALIA Y
NETZER- - - - -
H7T2DISEÑO TERMINADA IDALIA Y
NETZER4 - - - -
H7T3CODIFICACIÓN TERMINADA IDALIA Y
NETZER8 4 - - -
H7T4CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 - - -
H7T5CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 4 - -
H7T6CODIFICACIÓN TERMINADA IDALIA Y
NETZER4 4 4 - -
H7T7PRUEBAS TERMINADA IDALIA Y
NETZER4 4 4 4 -
H7T8PRUEBAS TERMINADA IDALIA Y
NETZER4 4 4 4 -
CREACIÓN DE ASIGNACIÓN EN EL DAL DE EQUIPO
CREACIÓN Y EJECUCIÓN DE PRUEBAS UNITARIAS
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
ASIGNACIÓN DE EQUIPO
CREACIÓN DEL FORMULARIO DE ASIGNACIÓN
VALIDACIÓN DEL FORMULARIO
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA ASIGNACIÓN
CREACIÓN DE LOS ENTITY PARA EL EMPLEADO Y ASIGNACIÓN
TAREAS PENDIENTES
HORAS DE TRABAJO PENDIENTESPILA DEL SPRINT
ESFUERZOTAREA
CREAR DOCUMENTACIÓN NECESARIA
18-e
ne
19-e
ne
20-e
ne
21-e
ne
22-e
ne
SCIBI - SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS
179
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN ADMINISTRACIÓN DE PROYECTOS ESPECÍFICOS 1.3 DOCUMENTO FECHA APE-05-SPRINT BACKLOG ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 5/5
H8
H8T1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO- - - - -
H8T2DISEÑO TERMINADA ERICK Y
NORBERTO- - - - -
H8T3CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 - - - -
H8T4ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO4 - - - -
H8T5CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 - - -
H8T6PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 - - -
H9
H9T1ANÁLISIS Y
DISEÑOTERMINADA ERICK Y
NORBERTO4 4 4 - -
H9T2CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 4 - -
H9T3CODIFICACIÓN TERMINADA ERICK Y
NORBERTO4 4 4 4 -
H9T4PRUEBAS TERMINADA ERICK Y
NORBERTO4 4 4 4 -
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA CONSULTAS
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
CREACIÓN DE PRUEBAS DE ACEPTACIÓN
CREACIÓN DE FORMULARIO PARA PRESENTACIÓN DE INFORMACIÓN
CREACIÓN DEL MODELO DE NEGOCIO CON VALIDACIÓN DE DATOS
CREACIÓN DEL FORMATO PARA MODO DE IMPRESIÓN
CREACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS PARA CONSULTA DE RESG.
CONSULTA DE RESGUARDO
IMPRIMIR RESGUARDO
CREACIÓN DEL FORMULARIO DE BÚSQUEDA DE RESGUARDOS
VALIDACIÓN DEL FORMULARIO
180
Anexo 13 Tarjetas CRC
UNIDAD DE INGENIERÍA DE COSTOS E
INFORMÁTICA DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-01-TARJETAS CRC ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/1
181
Anexo 14 Pruebas de Aceptación
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H1
ID PRUEBA H1P1
DESCRIPCIÓN La pantalla de inicio permite al usuario ingresar al sistema mediante un nombre
de usuario y contraseña.
SITUACIÓN INICIAL 1. Tener en la base de datos registrado a un Administrador con nombre de usuario upruebaadm1 y contraseña pwdpruebaadm1 2. Tener en la base de datos registrado a un Coordinador con nombre de usuario upruebacdr1 y contraseña pwpruebadcd1r
INSTRUCCIONES Para Usuario upruebaadm1: 1. Entrar el sistema en la pantalla inicial 2. En el campo Nombre introducir upruebaadm1 3. En el campo Contraseña introducir pwdpruebaadm1 4. Presionar el botón INGRESAR Para Usuario upruebacdr1: 1. Entrar el sistema en la pantalla inicial 2. En el campo Nombre introducir upruebacdr1 3. En el campo Contraseña introducir pwpruebadcdr1 4. Presionar el botón INGRESAR
RESULTADOS ESPERADOS
Para Usuario upruebaadm1: Debe aparecer el menú con todas las opciones de operación del sistema. Para Usuario upruebacdr1: Debe aparecer el menú con todas las opciones de operación del sistema, excepto la opción de USUARIOS.
182
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H2 ID PRUEBA H2P1 DESCRIPCIÓN La pantalla de USUARIOS permite al Administrador agregar o modificar la
información de los usuarios que ingresan al sistema.
SITUACIÓN INICIAL 1. Tener en la base de datos registrado a un Coordinador con nombre de usuario upruebacdr1 y contraseña pwpruebadcdr1 2. No tener en la base de datos registrado a un Usuario con el nombre de usuario upruebacdr2
INSTRUCCIONES Para upruebacdr1: 1. Entrar al sistema como Administrador 2. Seleccionar el menú USUARIOS 3. Presionar el botón NUEVO. 4. Llenar el formulario de datos de USUARIO poniendo en el campo usuario upruebacdr1 5. Presionar el botón AGREGAR Para upruebacdr2: 1. Entrar al sistema como Administrador 2. Seleccionar el menú USUARIOS 3. Presionar el botón NUEVO 4. Llenar el formulario de datos de USUARIO poniendo en el campo usuario upruebacdr2 5. Presionar el botón AGREGAR.
RESULTADOS ESPERADOS
Para upruebacdr1: El sistema debe mostrar un mensaje de alerta porque está tratando de agregar un usuario que ya existe. Para upruebacdr2: El sistema de mostrar la lista de usuarios donde aparece el usuario upruebacdr2
183
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 3/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H3
ID PRUEBA H3P1
DESCRIPCIÓN La pantalla de USUARIOS permite al Administrador agregar o modificar la
información de los usuarios que ingresan al sistema.
SITUACIÓN INICIAL 1. Tener en la base de datos registrado a un Coordinador con nombre de usuario upruebacdr1 y contraseña pwpruebadcdr1
INSTRUCCIONES 1. Entrar al sistema como Administrador 2. Seleccionar el menú USUARIOS 3. Seleccionar de la lista de Usuarios registrados el usuario upruebacdr1 4. Modificar sus datos en el formulario 5. Presionar el botón ACTUALIZAR.
RESULTADOS ESPERADOS
Para upruebacdr2: El sistema de mostrar la lista de usuarios donde aparece el usuario upruebacdr2 con sus datos modificados o actualizados.
184
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 4/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H4 ID PRUEBA H4P1 DESCRIPCIÓN La pantalla ALTA permite agregar nuevos registros a la base de datos. Los equipos
pueden ser CPU, monitores, teclados, ratones, impresoras y equipo diverso.
SITUACIÓN INICIAL 1. La tabla CPU de la base de datos debe estar vacía.
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador 2. Seleccionar del menú la opción ALTA 3. Introducir los siguientes datos en los campos: ALTA DE EQUIPO: CPU NUMERO ECONÓMICO: 125001 NUMERO DE SERIE: 1B3244FA MARCA: DELL MODELO: OPTIPLEXGX20 PROCESADOR: INTEL CORE DUO MEMORIA RAM: 1024 DISCO DURO: 80 FECHA ALTA: 01/02/2010 TIPO: ESCRITORIO OBSERVACIONES: ESTATUS: ACTIVO 4. Presionar el botón AGREGAR
RESULTADOS ESPERADOS
El sistema muestra un mensaje de éxito y muestra el número de resguardo 1, porque el sistema genera el número consecutivamente.
185
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 5/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H4 ID PRUEBA H4P2 DESCRIPCIÓN La pantalla ALTA permite agregar nuevos registros a la base de datos. Los equipos
pueden ser CPU, monitores, teclados, ratones, impresoras y equipo diverso.
SITUACIÓN INICIAL 1. Debe existir en la tabla Monitor de la base de datos un registro con la siguiente información: NUMERO DE RESGUARDO: 1 NUMERO ECONÓMICO: 125002 NUMERO DE SERIE: 7D68A01 MARCA: DELL MODELO: IN1710N TAMAÑO: 17 FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador. 2. Seleccionar del menú la opción ALTA. 3. Introducir los siguientes datos en los campos: NUMERO DE RESGUARDO: 2 NUMERO ECONÓMICO: 125002 NUMERO DE SERIE: 7DTRA0E MARCA: DELL MODELO: IN1710N TAMAÑO: 17 FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO 4. Presionar el botón AGREGAR
RESULTADOS ESPERADOS
El sistema debe mostrar un mensaje de que el NUMERO ECONÓMICO 125002 ya está registrado en la base de datos. Por lo tanto no se puede llevar a cabo la operación.
186
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 6/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H6
ID PRUEBA H6P1
DESCRIPCIÓN La pantalla MODIFICACIÓN permite actualizar los registros de la base de datos. La
modificación puede ser de CPU, monitores, teclados, ratones, impresoras y equipo diverso.
SITUACIÓN INICIAL 1. Debe existir en la tabla Teclado de la base de datos un registro con la siguiente información: NUMERO DE RESGUARDO: 2 NUMERO ECONÓMICO: 125007 NUMERO DE SERIE: URTH-7UT5-0O9I MARCA: DELL MODELO: INSPIRON FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador 2. Seleccionar del menú la opción MODIFICACIÓN 3. Buscar el equipo con NUMERO ECONÓMICO: 125007 4. Introducir los siguientes datos en los campos NUMERO DE RESGUARDO: 1 NUMERO ECONÓMICO: 125007 NUMERO DE SERIE: URTH-7UT5-0O9I MARCA: DELL MODELO: INSPIRON FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO 5. Presionar el botón ACTUALIZAR
RESULTADOS ESPERADOS
El sistema debe mostrar un mensaje de éxito que se actualizó correctamente el registro.
187
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 7/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H6
ID PRUEBA H6P2
DESCRIPCIÓN La pantalla MODIFICACIÓN permite actualizar los registros de la base de datos. La
modificación puede ser de CPU, monitores, teclados, ratones, impresoras y equipo diverso.
SITUACIÓN INICIAL 1. Debe existir en la tabla Teclado de la base de datos un registro con la siguiente información: NUMERO DE RESGUARDO: 1 NUMERO ECONÓMICO: 125007 NUMERO DE SERIE: URTH-7UT5-0O9I MARCA: DELL MODELO: INSPIRON FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador 2. Seleccionar del menú la opción MODIFICACIÓN 3. Buscar el equipo con NUMERO ECONÓMICO: 125011 4. Introducir los siguientes datos en el formulario: NUMERO DE RESGUARDO: 3 NUMERO ECONÓMICO: 125007 NUMERO DE SERIE: UYU7-JUYH-8IU7 MARCA: DELL MODELO: INSPIRON FECHA DE ALTA: 01/02/2010 ESTATUS: ACTIVO 5. Presionar el botón ACTUALIZAR
RESULTADOS ESPERADOS
El sistema debe mostrar un mensaje de que el NUMERO ECONÓMICO 125011 ya está registrado en la base de datos. Por lo tanto no se puede llevar a cabo la actualización.
188
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 8/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H7 ID PRUEBA H7P1 DESCRIPCIÓN La pantalla de ASIGNACIÓN permite asignar un equipo a un empleado que
previamente los haya solicitado al área de Bienes Informáticos.
SITUACIÓN INICIAL 1. Debe existir en la tabla Teclado de la base de datos un registro en la tabla CPU con la siguiente información: NUMERO DE RESGUARDO: 1 ALTA DE EQUIPO: CPU NUMERO ECONÓMICO: 125001 NUMERO DE SERIE: 1B3244FA MARCA: DELL MODELO: OPTIPLEXGX20 PROCESADOR: INTEL CORE DUO MEMORIA RAM: 1024 DISCO DURO: 80 FECHA ALTA: 01/02/2010 TIPO: ESCRITORIO OBSERVACIONES: ESTATUS: ACTIVO
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador 2. Seleccionar del menú la opción ASIGNACIÓN 3. Buscar el equipo con NUMERO DE RESGUARDO 1 4. Introducir los siguientes datos en los campos del formulario del empleado NUTRA: 086730 NOMBRE: SANDRA GONZÁLEZ PÉREZ ÁREA: CONTROL DE GESTIÓN DE PROGRAMA DE OBRAS 5. Presionar el botón ASIGNAR
RESULTADOS ESPERADOS
El sistema debe mostrar un mensaje de éxito de asignación que el empleado con NUTRA: 086730 tiene asignado el RESGUARDO 1.
189
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-02-PRUEBAS DE ACEPTACIÓN ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 9/9
PRUEBA DE ACEPTACIÓN ID PRODUCTO H8 ID PRUEBA H8P1 DESCRIPCIÓN La pantalla de IMPRIMIR permite al usuario buscar un resguardo en la base de
datos y mostrarlo con un formato listo para imprimir. SITUACIÓN INICIAL 1. Deben existir un equipo con NUMERO DE RESGUARDO 1
2. El reguardo debe tener un monitor, un teclado, un mouse, una impresora y un regulador. 3. El resguardo debe estar asignado a un empleado
INSTRUCCIONES 1. Entrar al sistema como Administrador o Coordinador 2. Seleccionar del menú la opción IMPRIMIR 3. Buscar el equipo con NUMERO DE RESGUARDO : 1 4. Presionar el botón BUSCAR
RESULTADOS ESPERADOS
Deben aparecer en la pantalla los datos del equipo completo (CPU, monitor teclado, mouse, impresora y equipo vario) de acuerdo al formato establecido en la organización.
PRUEBA DE ACEPTACIÓN ID PRODUCTO H9 ID PRUEBA H9P1 DESCRIPCIÓN La pantalla de CONSULTA permite al usuario consultar la información de algún
resguardo que exista en la base de datos y mostrarlo en pantalla. SITUACIÓN INICIAL 1. Deben existir un equipo con NUMERO DE RESGUARDO 1
2. El reguardo debe tener un monitor, un teclado, un mouse, una impresora y un regulador. 3. Puede o no estar asignado a un empleado
INSTRUCCIONES 1. Entrar al sistema 2. Seleccionar del menú la opción CONSULTA 3. Buscar el equipo con NUMERO DE RESGUARDO : 1 4. Presionar el botón BUSCAR
RESULTADOS ESPERADOS
Deben aparecer en la pantalla los datos del equipo completo (CPU, monitor teclado, mouse, impresora y equipo vario).
190
Anexo 15 Manual de Usuario
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 1/10 1. Ingresar al sistema
Para ingresar al sistema es necesario abrir el navegador en una computadora con acceso a la intranet de la
organización y teclear la dirección http://10.35.16.8/BienesInformaticos/ y aparecerá la pantalla de inicio, ver
figura 1.
Figura 1. Pantalla de Inicio
Teclee su nombre de usuario y contraseña en el formulario de INICIAR SESIÓN, ver figura 2.
Figura 2. Iniciar Sesión
Si la información proporcionada es correcta aparecerá un menú en la parte superior con las opciones de
operación de acuerdo a su perfil, ver figura 3.
191
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/10
Figura 3. Menú
2. Alta de Equipo
Para agregar un equipo nuevo seleccione la opción ALTA del menú y aparecerá un formulario con los campos
necesarios para registrar un nuevo equipo, ver figura 4.
Figura 4. Formulario de CPU
Puede seleccionar el tipo de equipo que desee agregar en la opción alta de equipo. Los formularios para cada
uno de ellos son: Monitor figura 5, para Teclado figura 6, para Mouse figura 7, para Impresora figura 8, para
Equipo diverso figura 9.
192
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 2/10
Figura 5. Formulario de MONITOR
Figura 6. Formulario de TECLADO
193
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 4/10
Figura 7. Formulario de MOUSE
Figura 8. Formulario de IMPRESORA
194
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 5/10
Figura 9. Formulario de EQUIPO VARIO
Una vez seleccionado el tipo de equipo, introduzca la información necesaria en cada uno de los campos del
formulario. Los campos requerido mandaran un mensaje de alerta si no son llenados correctamente, ver figura
10.
Figura 10. Alerta de validación de campo
Cuando la información proporcionada este completa, de clic en el botón de AGREGAR para registrar el equipo
en el sistema. Si la operación tuvo éxito se desplegara un mensaje de que se agrego el registro, ver figura 11.
Figura 11. Mensaje de resultado
195
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 6/10 3. Modificación o Actualización de Equipos
Para actualizar o modificar la información relacionada con un equipo que previamente haya sido registrado,
seleccione la opción MODIFICACIÓN del menú. Aparecerá un formulario de búsqueda de equipo por NÚMERO
ECONÓMICO, ver figura 12.
Figura 12. Formulario de búsqueda de equipo
Teclee el NUMERO ECONÓMICO del equipo que va a modificar y presione el botón BUSCAR. El sistema buscara
el equipo y automáticamente aparecerá el formulario de datos para actualizar la información, ver figura 13.
Figura 12. Formulario de modificación de TECLADO
Teclee la nueva información del equipo y presione el botón de ACTUALIZAR para completar la operación. Si el
registro se actualiza satisfactoriamente se desplegará un mensaje, ver figura 14.
Figura 14. Mensaje de éxito
196
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 7/10 4. Asignación de Equipos (Resguardos)
Para asignar un equipo a un empleado del área, seleccione la opción ASIGNACIÓN del menú. Se desplegara un
formulario donde proporcionara el numero de resguardo y los datos del empleado al que se le asignara el
equipo, ver figura 15.
Figura 15. Formulario de ASIGNACIÓN
Si no sabe qué equipo es él que va a asignar porque desconoce sus características, entonces de clic en el botón
VER LISTA para que se muestre un listado con el equipo, ver figura 16.
Figura 16. Listado de equipo
Una vez que seleccionó el equipo y completó los datos del formulario, presione el botón ASIGNAR para asignar
el equipo al empleado.
Si el equipo ya estaba previamente asignado, el sistema automáticamente re-asignará el equipo al nuevo
empleado y se mostrará un mensaje de éxito de asignación, ver figura 17.
Figura 17. Mensaje de éxito de asignación
197
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 8/10 4. Administración de Usuarios
Para administrar la información de los usuarios que ingresan al sistema, elija la opción USUARIOS del menú. Se
mostrará un listado con los usuarios registrados en ese momento, ver figura 18.
Figura 18. Lista de usuarios
Si desea agregar un nuevo usuario, presione el botón NUEVO USUARIO. Si desea actualizar la información de un
usuario registrado previamente, seleccione el usuario de la lista y presione el botón EDITAR del usuario.
Dependiendo de la operación se desplegará un formulario para teclear la información, ver figura 19.
Figura 19. Formulario de USUARIO
Una vez terminado de teclear la información en los campos correspondientes, presione el botón AGREGAR para
agregar el usuario o el botón ACTUALIZAR para actualizar los datos del usuario.
El sistema mostrara un mensaje de éxito de alta o modificación de usuario, ve figura 20.
Figura 20. Mensaje de éxito
198
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 9/10 5. Impresión de Resguardos
Para imprimir un resguardo, elija la opción IMPRIMIR del menú, se mostrará un formulario para buscar el
número de resguardo, ver figura 21.
Figura 21. Buscar Resguardo
Teclee el numero de resguardo y presione el botón BUSCAR. Si existe el resguardo el sistema le mostrara el
resguardo con la información en un formato listo para imprimir, ver figura 22.
Figura 22. Resguardo administrativo
199
UNIDAD DE INGENIERÍA DE COSTOS E INFORMÁTICA
DESARROLLO DE APLICACIONES
NUMERO 820000-02
PROCESO VERSIÓN DESARROLLO Y MANTENIMIENTO DE SOFTWARE 1.3 DOCUMENTO FECHA DMS-03-MANUAL DE USUARIO ENERO 2010 PROYECTO PAGINA SCIBI-SISTEMA DE CONTROL DE INVENTARIO DE BIENES INFORMÁTICOS 10/10 6. Consulta de Equipo
Seleccione la opción CONSULTA del menú. Se mostrará un formulario donde se podrá buscar el equipo para
consultar por NUMERO DE RESGUARDO, NUMERO ECONÓMICO Y NUTRA DEL TRABAJADOR, ver figura 23.
Figura 23. Formulario de CONSULTA
Introduzca cualquiera de los campos y presione el botón BUSCAR. El sistema mostrará un listado con la
información relacionada al criterio de búsqueda, ver figura 24.
Figura 24. Listado de los resultados de la consulta
6. Salir del sistema
Para salir del sistema y terminar la sesión, seleccione la opción SALIR del menú. El sistema automáticamente lo
re-direccionará a la pantalla de inicio, limpiando de los archivos temporales información y borrando las cookies
de la sesión.
![TemaIV.010.ISO 15504 e ISO 12207 [Modo de compatibilidad]PS... · Esquema normalmente aplicado en software LOS 43 PROCESOS DEL MODELO DE PROCESOS DE REFERENCIA (ISO/IEC 12207:2008)](https://static.fdocuments.es/doc/165x107/5c5c9efc09d3f2dc448b9911/temaiv010iso-15504-e-iso-12207-modo-de-compatibilidad-ps-esquema-normalmente.jpg)