ESCUELA POLITÉCNICA DEL EJÉRCITO
DPTO. DE CIENCIAS DE LA COMPUTACIÓN
CARRERA DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
ELABORACIÓN DEL ESTÁNDAR DE APLICACIÓN DE LA
NORMA ISO/IEC 12207, AL DESARROLLO DE
APLICACIONES DE SOFTWARE PARA LA UTIC DE LA
ESPE
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS E INFORMÁTICA
POR:
SR. ANDRÉS GALLEGOS VELÁSQUEZ
SR. PABLO ANDERSON ORTIZ RODRÍGUEZ
SANGOLQUÍ, Agosto del 2011
CERTIFICACIÓN
Certifico que el presente trabajo fue realizado en su totalidad por el Sr(s).
GALLEGOS VELÁSQUEZ ANDRÉS y ORTIZ RODRÍGUEZ PABLO ANDERSON,
como requerimiento parcial a la obtención del título de INGENIERO(S) EN
SISTEMAS E INFORMÁTICA.
_________________
Agosto del 2011
_________________
ING. MARIO RON
i
DEDICATORIA
Esta tesis va dedicado principalmente a Dios por acompañarme y guiarme a lo
largo de toda mi vida, colmándome de muchas bendiciones. A mis padres y
hermanos, quienes me han dado su cariño, comprensión,
y siempre me
motivaron para alcanzar mis metas enseñándome a ser constante.
Andrés Gallegos Velásquez
ii
DEDICATORIA
Este trabajo se lo dedico a mis padres y a mi hermana, que me han sabido
comprender y apoyar en este largo camino, siempre han sido mi más grande
motivación para seguir adelante
y cumplir todas las metas que
me he
trazado.
A mis abuelos, por sus consejos que me hicieron reflexionar sobre las cosas
importantes de la vida.
Pablo Anderson Ortiz Rodríguez
iii
AGRADECIMIENTOS
Agradezco principalmente a mis padres por ser la ayuda moral, espiritual, que a
pesar de cualquier dificultad, siempre han sido el ejemplo a seguir día a día, a mis
hermanos por apoyarme y ayudarme a conseguir cualquier meta planteada. A
toda mi familia y amigos por
colaborar de cualquier forma para que ésta
culminación de carrera universitaria haya llegado a su mejor fin. A mis maestros
por haberme impartido todos sus conocimientos y enseñanzas, agradeciendo de
igual manera a mi Director, Codirector y Colaborador de esta tesis.
Y sobre todo agradezco a Dios.
Andrés Gallegos Velásquez
iv
AGRADECIMIENTO
Agradezco a Dios, por haber sido mi refugio en los momentos más difíciles,
por permitirme estar vivo y por ayudarme a superar todas las adversidades
que se me han presentado.
Agradezco a mis padres; a mi madre, por sus consejos, su apoyo, paciencia y
ayuda incondicional; a mi padre, por su esfuerzo y sacrifico desinteresado,
para que yo pueda seguir adelante.
A mi querida hermana, por su paciencia, comprensión; por ser mi amiga y en
momentos como mi madre, por su ejemplo para que pudiera seguir el camino
correcto.
A mi Director, Codirector, y Colaborador de tesis, por su apoyo y ayuda, para
seguir adelante y culminar este proyecto.
A todos mis amigos, por brindarme su amistad y apoyarme en todo momento.
Pablo Anderson Ortiz Rodríguez
v
ÍNDICE
ÍNDICE DE FIGURAS ................................................................................................................... xii
ÍNDICE DE TABLAS .....................................................................................................................xiii
RESUMEN ......................................................................................................................................xiv
CAPÍTULO I ...................................................................................................................................... 1
1.
INTRODUCCIÓN ..................................................................................................................... 1
1.1.-
Antecedentes ................................................................................................................ 1
1.2.-
Planteamiento del Problema ...................................................................................... 2
1.3.-
Justificación .................................................................................................................. 5
1.4.-
Objetivos........................................................................................................................ 6
1.4.1.-
Objetivo General ...................................................................................................... 6
1.4.2.-
Objetivos Específicos .............................................................................................. 6
1.5.-
Alcance o Meta............................................................................................................. 7
1.6.-
Metodología .................................................................................................................. 7
1.6.1.1.7.-
Metodología de Investigación ................................................................................ 7
Factibilidad .................................................................................................................... 9
1.7.1.-
Factibilidad Técnica ................................................................................................. 9
1.7.2.-
Factibilidad Operativa.............................................................................................. 9
1.7.3.-
Factibilidad Económica ......................................................................................... 10
CAPÍTULO II ................................................................................................................................... 11
2.
MARCO TEÓRICO ................................................................................................................ 11
2.1.-
Tecnologías de la Información y Comunicación (TIC) ......................................... 11
2.1.1.-
Antecedentes .......................................................................................................... 11
2.1.2.-
Definición TIC ......................................................................................................... 12
2.1.3.-
Características de las TIC .................................................................................... 14
2.1.4.-
Ventajas y Desventajas de las TIC ..................................................................... 15
2.1.4.1.-
Ventajas........................................................................................................... 15
2.1.4.2.-
Desventajas .................................................................................................... 16
2.1.5.-
Objetivos de las TIC en las Instituciones ........................................................... 16
2.1.6.-
Tareas del Departamento de TIC dentro de una Institución ........................... 17
2.1.7.-
Servicios del Departamento de TIC dentro de una Institución ....................... 17
vi
2.2.-
Software ...................................................................................................................... 19
2.2.1.-
Antecedentes .......................................................................................................... 19
2.2.2.-
Definición de Software .......................................................................................... 20
2.2.3.-
Producto Software ................................................................................................. 20
2.2.4.-
Clasificación del Software .................................................................................... 21
2.2.4.1.-
Software de Sistemas ................................................................................... 22
2.2.4.2.-
Software de Tiempo Real ............................................................................. 22
2.2.4.3.-
Software de Gestión ...................................................................................... 23
2.2.4.4.-
Software de Ingeniería y Científico ............................................................. 23
2.2.4.5.-
Software Empotrado ...................................................................................... 24
2.2.4.6.-
Software de Computadores Personales..................................................... 24
2.2.4.7.-
Software Basado en Web ............................................................................. 25
2.2.5.-
Proceso de Creación de Software....................................................................... 25
2.2.6.-
Proceso, Métodos y Herramientas ...................................................................... 27
2.2.6.1.-
Proceso............................................................................................................ 27
2.2.6.2.-
Métodos ........................................................................................................... 27
2.2.6.3.-
Herramientas .................................................................................................. 28
2.2.7.-
Fases Principales del Desarrollo de Software................................................... 28
2.2.7.1.-
Fase de Definición ......................................................................................... 28
2.2.7.2.-
Fase de Desarrollo......................................................................................... 29
2.2.7.3.-
Fase de Mantenimiento................................................................................. 33
2.2.8.-
Ciclo de Vida de Software .................................................................................... 34
2.2.8.1.-
Modelos del Ciclo de Vida del Software ..................................................... 35
2.2.8.1.1.- Modelo Lineal ........................................................................................... 35
2.2.8.1.2.- Modelo Cascada ...................................................................................... 36
2.2.8.1.3.- Modelo Evolutivo ...................................................................................... 37
2.2.8.1.4.- Modelo Incremental ................................................................................. 37
2.2.8.1.5.- Modelo Espiral .......................................................................................... 38
2.3.-
Norma ISO/IEC 12207 .............................................................................................. 40
2.3.1.-
Introducción ............................................................................................................ 40
2.3.2.-
Definiciones Importantes ...................................................................................... 41
2.3.2.1.-
Estándar .......................................................................................................... 41
2.3.2.2.-
ISO ................................................................................................................... 41
2.3.2.3.-
IEC.................................................................................................................... 42
vii
2.3.3.-
Norma ISO/IEC 12207:2008 ................................................................................ 42
2.3.3.1.-
Propósito ......................................................................................................... 43
2.3.3.2.-
Limitaciones .................................................................................................... 43
2.3.3.3.-
Conformidad ................................................................................................... 44
2.3.3.3.1.- Uso Correcto ............................................................................................. 44
2.3.3.3.2.- Conformidad Completa ........................................................................... 44
2.3.3.3.3.- Conformidad a la Medida ........................................................................ 45
2.3.3.4.- Recomendaciones de la Norma ISO/EC 12207:2008 para los Procesos
del Ciclo de Vida del Software ......................................................................................... 45
2.3.3.5.-
Organización de la Norma ISO/IEC 12207:2008 ...................................... 46
2.3.3.5.1.- Categorías del Proceso de Ciclo de Vida del Software ..................... 46
2.3.3.5.2.- Estructura de los Procesos del Ciclo de Vida del Software según la
Norma ISO/IEC 12207 .................................................................................................. 49
CAPÍTULO III .................................................................................................................................. 52
3.
ANÁLISIS UTIC ESPE Y PROCESO DE DESARROLLO DE SOFTWARE ................ 52
3.1.-
Funciones de la UTIC de la ESPE .......................................................................... 52
3.2.Gestión del Departamento de Tecnología de la Información y Comunicación
(UTIC-ESPE) .............................................................................................................................. 53
3.2.1.-
GT.1 Gestión Estratégica de Tecnologías de Información.............................. 53
3.2.2.-
GT.2 Gestión y Soporte Técnico ......................................................................... 53
3.2.3.-
GT.3 Administración de Redes, Comunicaciones y Servicio .......................... 54
3.2.4.-
GT.4 Desarrollo, Implantación y Mantenimiento de Aplicativos ..................... 54
3.2.5.-
GT5 Administración de Aplicativos y Base de Datos ....................................... 54
3.3.-
Árbol de Gestión y Tecnología Informática (UTIC-ESPE) ................................... 55
3.4.-
Análisis del GT.4 (Desarrollo, Implantación y Mantenimiento de Aplicativos) . 56
3.4.1.-
Objetivo.................................................................................................................... 57
3.4.2.-
Alcance .................................................................................................................... 57
3.4.3.-
Responsable ........................................................................................................... 57
3.4.4.-
Requisitos Legales ................................................................................................ 57
3.4.5.-
Políticas Internas.................................................................................................... 58
3.4.6.-
Subprocesos ........................................................................................................... 58
3.4.7.-
Registros Controlados ........................................................................................... 59
3.4.8.-
Documentos Controlados ..................................................................................... 60
3.4.9.-
Instrucciones Aclaratorias .................................................................................... 60
3.4.10.-
Procesos para el Desarrollo de Software en la UTIC de la ESPE ............. 61
viii
3.4.10.1.- Análisis y Diseño para el Desarrollo de Aplicativos ................................. 62
3.4.10.2.- Construcción de Aplicativos ........................................................................ 63
3.4.10.3.- Implantación de Aplicativos ......................................................................... 64
3.5.Análisis Crítico de los Procesos más Importantes y Urgentes de la Norma
ISO/IEC 12207:2008, referentes al Desarrollo de Software ............................................... 65
3.6.Comparación de los Procesos de la UTIC ESPE vs Procesos Norma ISO/IEC
12207:2008. ................................................................................................................................ 69
CAPÍTULO IV ................................................................................................................................. 86
4. ESTÁNDAR DE APLICACIÓN BASADO EN LA NORMA ISO/IEC 12207, AL
PROCESO DE DESARROLLO DE SOFTWARE EN LA UTIC DE LA ESPE ..................... 86
4.1.-
Términos y Definiciones............................................................................................ 87
4.2.-
Procesos Específicos del Software ....................................................................... 100
4.2.1.-
Proceso de Implementación del Software ....................................................... 100
4.2.1.1.-
Propósito ....................................................................................................... 100
4.2.1.2.-
Actividades y Tareas ................................................................................... 101
4.2.1.2.1.- Implementación del Software ............................................................... 101
4.2.2.-
Proceso de Análisis de Requerimientos del Software ................................... 102
4.2.2.1.-
Propósito ....................................................................................................... 102
4.2.2.2.-
Actividades y Tareas ................................................................................... 103
4.2.2.2.1.- Análisis de Requerimientos del Software........................................... 103
4.2.3.-
Proceso de Diseño de Arquitectura del Software ........................................... 105
4.2.3.1.-
Propósito ....................................................................................................... 105
4.2.3.2.-
Actividades y Tareas ................................................................................... 105
4.2.3.2.1.- Diseño de Arquitectura del Software .................................................. 105
4.2.4.-
Proceso de Diseño Detallado del Software ..................................................... 107
4.2.4.1.-
Propósito ....................................................................................................... 107
4.2.4.2.-
Actividades y Tareas ................................................................................... 107
4.2.4.2.1.- Diseño Detallado del Software............................................................. 107
4.2.5.-
Proceso de Construcción del Software ............................................................ 109
4.2.5.1.-
Propósito ....................................................................................................... 109
4.2.5.2.-
Actividades y Tareas ................................................................................... 110
4.2.5.2.1.- Construcción del Software.................................................................... 110
4.2.6.-
Proceso de Integración del Software ................................................................ 111
4.2.6.1.-
Propósito ....................................................................................................... 111
4.2.6.2.-
Actividades y Tareas ................................................................................... 112
ix
4.2.6.2.1.- Integración del Software ....................................................................... 112
4.2.7.-
Proceso de Pruebas del Software ..................................................................... 114
4.2.7.1.-
Propósito ....................................................................................................... 114
4.2.7.2.-
Actividades y Tareas ................................................................................... 114
4.2.7.2.1.- Pruebas del Software ............................................................................ 114
4.3.-
Procesos de Apoyo.................................................................................................. 116
4.3.1.-
Proceso de Gestión de la Documentación del Software ............................... 116
4.3.1.1.-
Propósito ....................................................................................................... 116
4.3.1.2.-
Actividades y Tareas ................................................................................... 116
4.3.1.2.1.- Implementación del Proceso ................................................................ 116
4.3.1.2.2.- Diseño y Desarrollo ............................................................................... 117
4.3.1.2.3.- Producción .............................................................................................. 118
4.3.1.2.4.- Mantenimiento ........................................................................................ 118
4.3.2.-
Proceso de Gestión de la Configuración del Software .................................. 119
4.3.2.1.-
Propósito ....................................................................................................... 119
4.3.2.2.-
Actividades y Tareas ................................................................................... 119
4.3.2.2.1.- Implementación del Proceso ................................................................ 119
4.3.2.2.2.- Identificación de la Configuración ....................................................... 120
4.3.2.2.3.- Control de la Configuración .................................................................. 120
4.3.2.2.4.- Determinación del Estado de la Configuración ................................. 121
4.3.2.2.5.- Evaluación de la Configuración ........................................................... 121
4.3.2.2.6.- Gestión de Releases y Entrega ........................................................... 121
4.3.3.-
Proceso de Resolución de Problemas del Software ...................................... 122
4.3.3.1.-
Propósito ....................................................................................................... 122
4.3.3.2.-
Actividades y Tareas ................................................................................... 122
4.3.3.2.1.- Implementación del Proceso ................................................................ 122
4.3.3.2.2.- Solución de problemas.......................................................................... 123
4.3.4.-
Proceso de Revisión Conjunta del Software ................................................... 124
4.3.4.1.-
Propósito ....................................................................................................... 124
4.3.4.2.-
Actividades y Tareas ................................................................................... 124
4.3.4.2.1.- Implementación del Proceso ................................................................ 124
4.3.4.2.2.- Revisiones de la Gestión del Proyecto ............................................... 126
4.3.4.2.3.- Revisiones Técnicas .............................................................................. 126
4.3.5.-
Proceso de Validación del Software ................................................................. 127
x
4.3.5.1.-
Propósito ....................................................................................................... 127
4.3.5.2.-
Actividades y tareas..................................................................................... 128
4.3.5.2.1.- Implementación del proceso ................................................................ 128
4.3.5.2.2.- Validación ................................................................................................ 129
CAPÍTULO V ................................................................................................................................ 131
5.
CONCLUSIONES Y RECOMENDACIONES .................................................................. 131
5.1.-
Conclusiones ............................................................................................................ 131
5.2.-
Recomendaciones ................................................................................................... 132
ANEXOS ....................................................................................................................................... 134
ANEXO A: RESUMEN DEL ESTÁNDAR DE APLICACIÓN BASADO EN LA NORMA
ISO/IEC 12207 ............................................................................................................................. 134
ANEXO B: PLAN DE GESTIÓN DE LA DOCUMENTACIÓN ............................................... 139
ANEXO C: PLAN DE GESTIÓN DE LA CONFIGURACIÓN ................................................ 141
ANEXO D: ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE (ERS) ............ 147
ANEXO E: DISEÑO DE ARQUITECTURA DE ALTO NIVEL Y DETALLADO .................. 153
ANEXO F: PLAN DE PRUEBAS ............................................................................................... 162
ANEXO G: FORMATO ENCUESTA ......................................................................................... 169
BIBLIOGRAFÍA ............................................................................................................................ 174
xi
ÍNDICE DE FIGURAS
Figura 2.1: (Convergencia Tecnologías de Información y Comunicación) ........................... 12
Figura 2.2: (Servicios de las TIC dentro de una Institución) ................................................... 18
Figura 2.3: (Tareas para Captura y Análisis de Requisitos) ................................................... 29
Figura 2.4 (Ejemplo Resultado Pruebas Unitarias JUnit) ........................................................ 30
Figura 2.5: (Metodología de Integración TOP_DOWN) ........................................................... 31
Figura 2.6: (Representación Modelo Lineal) ............................................................................. 36
Figura 2.6: (Representación Modelo Cascada) ........................................................................ 36
Figura 2.8: (Representación Modelo Evolutivo) ........................................................................ 37
Figura 2.9: (Representación Modelo Incremental) ................................................................... 38
Figura 2.10: (Representación Modelo Espiral).......................................................................... 39
Figura 2.11: (Ciclo de Vida de los Procesos de Software de 12207) .................................... 47
Figura 2.12: (Selección de Elemento(s) de la Norma que se ajustan a necesidades de la
Organización) ................................................................................................................................. 48
Figura 2.13: (Estructura de los Procesos de ISO/IEC 12207:2008) ...................................... 50
Figura 3.1: (Estructura UTIC ESPE) ........................................................................................... 55
Figura 3.2: (Árbol Productos/Servicios UTIC ESPE) ............................................................... 56
Figura 3.3: (Diagrama Análisis y Diseño para el Desarrollo de Aplicativos) ........................ 62
Figura 3.4: (Diagrama Construcción de Aplicativos) ................................................................ 63
Figura 3.6: (Diagrama de Análisis de Requerimientos) ........................................................... 70
Figura 3.7: (Diagrama de Proceso de Diseño de Alto Nivel) .................................................. 71
Figura 3.8: (Diagrama de Proceso de Diseño Detallado de Software) ................................. 72
Figura 3.9: (Diagrama Proceso de Construcción de Software) .............................................. 73
Figura 3.10: (Diagrama Proceso De Integración) ..................................................................... 74
Figura 3.11: (Diagrama Proceso De Pruebas) .......................................................................... 75
xii
ÍNDICE DE TABLAS
Tabla 1.1: (Descripción Factibilidad Económica)...................................................................... 10
Tabla 3.1: (Subprocesos GT4 y Periodicidad) .......................................................................... 58
Tabla 3.2: (Registros Controlados GT4) .................................................................................... 59
Tabla 3.3: (Matriz de Importancia Urgencia Procesos ISO/IEC 12207:2008)...................... 67
Tabla 3.4: (Matriz de Importancia Urgencia Procesos de Apoyo ISO/IEC 12207:2008).... 68
Tabla 3.5: (Cuadro Comparativo Desarrollo de Software UTIC-ESPE vs Estándar de
Aplicación Norma ISO/IEC 12207).............................................................................................. 77
xiii
RESUMEN
El desarrollo de software es un proceso muy complejo que requiere de una
metodología eficiente y sistemática, durante este proceso pueden presentarse
diversos problemas como son: no cumplir con los requerimientos del cliente, mal
manejo de los tiempos que conlleva un desarrollo, no contar con un lenguaje
unificado que permita en un futuro el crecimiento del aplicativo, entre otros; por
esto se han desarrollado normas y estándares aplicables para el control y
mejoramiento de la calidad del software ya que en el mundo globalizado de hoy,
es un requisito indispensable para mantenerse compitiendo en el mercado. La
norma ISO/IEC 12207, que es la base de la presente tesis, establece un análisis
del ciclo de vida del software, incluye procesos y actividades que se aplican desde
la definición de requisitos, hasta la finalización de su uso. Para esta tesis, se
utilizó la investigación contrastiva para establecer semejanzas y diferencias entre
los procesos de la UTIC e ISO/IEC 12207 y la investigación aplicativa para la
elaboración de este estándar de aplicación de desarrollo de software para la UTIC
de la ESPE. Este estándar de aplicación, permitirá a la UTIC mejorar la
funcionalidad y rendimiento del software, satisfaciendo los requerimientos de
calidad exigidos por cliente.
xiv
CAPÍTULO I
1. INTRODUCCIÓN
El presente capítulo, describe y justifica las motivaciones, que llevaron a
elaborar la presente tesis.
1.1.- Antecedentes
El desarrollo de software es un proceso muy complejo que requiere de una
metodología eficiente y sistemática, durante este proceso pueden presentarse
diversos problemas como son: no cumplir con los requerimientos del cliente, mal
manejo de los tiempos que conlleva un desarrollo, no contar con un lenguaje
unificado que permita en un futuro el crecimiento del aplicativo, entre otros; por
esto se han desarrollado normas y estándares aplicables para el control y
mejoramiento de la calidad del software ya que en el mundo globalizado de hoy,
es un requisito indispensable para mantenerse compitiendo en el mercado.
Los sistemas de gestión de la calidad basados en las normas ISO, reflejan el
consenso internacional en este tema y han cobrado una gran popularidad, por lo
que muchas organizaciones han decidido tomar el camino de implantarlos. “La
ISO (International Standarization Organization) es la entidad encargada de facilitar
-1-
la normalización en el mundo” 1 , su función principal es orientar, coordinar,
simplificar y unificar los usos para conseguir menores costos y efectividad.
La norma ISO/IEC 12207, que es la base de la presente tesis, establece un
análisis del ciclo de vida del software que incluye procesos y actividades que se
aplican desde la definición de requisitos, pasando por la adquisición y
configuración de los servicios del sistema, hasta la finalización de su uso.
1.2.- Planteamiento del Problema
Las tecnologías de información y comunicación; y propiamente la industria
del software, se han incrementado considerablemente, debido a la importancia
que tienen en las empresas y organizaciones para poder competir en el mercado
global.
Las empresas y organizaciones ecuatorianas, forman parte de este
fenómeno global, obligándolas a mejorar y estar a la par, en el crecimiento de las
tecnologías de la Información y el desarrollo de software de calidad.
1
Tomado de: http://s3.amazonaws.com/lcp/ncastillo_unefai/myfiles/Objetivo-1.2-normalizacion.pdf
-2-
Importancia de la Industria
Las Tecnologías de la Información y más propiamente el software es
transversal a todos los sectores:
Genera competitividad para todos los sectores.
Es generadora intensiva de empleo.
Es generadora de valor e impacto con nivel de ganancias tempranas.
Tiene la capacidad de atraer inversiones.
Demanda recurso humano de alto valor agregado.
Se ajusta a requerimientos del mercado (Sector Público y Privado).
Produce soluciones que aportan valor.
Datos Estadísticas
Empresas de software por registro: 265
Registradas en AESOFT2: 77
Facturación Total de la Industria:
2005:US$ 62 millones
2006:US$ 99 millones
2007: US$130 millones.
2
AESOFT: Asociación Ecuatoriana de Software
http://aesoft.com.ec/index.php?option=com_content&task=view&id=108&Itemid=3&date=2011-0201
-3-
Exportaciones:
2005: US$ 10.1 millones
2006: US$ 19 millones
2007: US$ 24 millones (*)
(*) Estimado
Por Región:
Quito: 85%
Guayaquil: 11%
Cuenca: 2%
Resto del país: 2%
Estos datos, exponen el impacto de la industria del software en el Ecuador,
mostrando la importancia de mejorar la calidad de software que se desarrolla en
el país.
Para desarrollar software de calidad, es indispensable tomar medidas para
controlar y mejorar aspectos como: análisis de requerimientos del software,
documentación que se debe generar, procesos que intervienen en el desarrollo de
un aplicativo, entre otros; dichas medidas deben estar establecidas en un
documento formal para que los participantes del desarrollo de software las
implementen.
-4-
Para desarrollar software dentro de la Unidad de Tecnologías de la
Información UTIC de la ESPE, se sugiere implementar un plan de aplicación, el
cual permita mejorar la calidad de todo el proceso de desarrollo de software.
Este proyecto de investigación, busca aportar a la UTIC de la ESPE, un
estándar de aplicación en el proceso de desarrollo de software, basado en la
Norma ISO/IEC 12207, que permita mejorar el método de desarrollo de software
utilizado actualmente.
1.3.- Justificación
La elaboración del estándar de aplicación basado en la norma ISO/IEC
12207, para el desarrollo de de software, dentro de la UTIC de la ESPE, busca
estandarizar y mejorar el proceso manejado actualmente.
El personal de la UTIC encargada de la parte de desarrollo, podrá tener
acceso a un modelo guía que le indique los pasos a seguir en un proyecto de
desarrollo, y facilite la comunicación entre los involucrados en el proyecto debido
al lenguaje unificado que maneja.
-5-
1.4.- Objetivos
1.4.1.- Objetivo General
•
Elaborar un estándar de aplicación basado en la norma ISO/IEC
12207 al desarrollo de aplicaciones de software, elaboradas por la
Unidad de Tecnología de la Información UTIC de la Escuela
Politécnica del Ejército ESPE.
1.4.2.- Objetivos Específicos
•
Presentar el marco teórico de las Tecnologías de Información y
Comunicación, las funciones que desempeñan y su importancia.
•
Presentar el marco teórico de la norma ISO/IEC 12207, su propósito,
su mecanismo de implementación y su importancia.
•
Presentar un marco teórico sobre el software, y su proceso de
desarrollo.
•
Conocer la estructura y el proceso que se lleva en la UTIC de la
ESPE, para el desarrollo de software.
•
Determinar los procesos de la norma ISO/IEC 12207 de mayor
importancia y urgencia en la UTIC de la ESPE aplicables al desarrollo
de software.
-6-
1.5.- Alcance o Meta
El alcance del proyecto, está basado en los procesos y tareas que se
consideren prioritarios y aplicables contemplados en la norma ISO/IEC 12207, los
cuales indican las acciones que se debieron tomar, para obtener un desarrollo de
calidad.
Como primera parte, se describió los procesos actuales que se llevan para el
desarrollo de aplicaciones de software en la UTIC de la ESPE, para así poder
determinar falencias y aciertos que tienen estos procesos, en contraste al que
sugiere la norma ISO/IEC 12207.
La presente tesis, se desarrolló en la Escuela Politécnica del Ejército
(ESPE), para lo cual se realizó un análisis del proceso actual de desarrollo de
aplicaciones de software en la UTIC, que será considerado para determinar los
procesos que deben ser aplicados de la norma ISO/IEC 12207.
1.6.- Metodología
1.6.1.- Metodología de Investigación
La metodología seleccionada dentro de este plan estuvo basada en la
Investigación Contrastiva e Investigación Aplicativa.
-7-
La investigación contrastiva, luego de un análisis previo del objeto de
estudio, cubre la necesidad de buscar los errores de las teorías del mismo, con la
finalidad de desecharlas, reajustarlas o incrementar su veracidad. Su objetivo
central está en proveer pruebas en contra a una teoría previamente construida o,
en su defecto, en proveer argumentos a su favor.
La investigación aplicativa, parte del hecho de que, dentro de la secuencia
de trabajo, existen teorías cuya veracidad ha aumentado gracias a un cierto
número de aplicaciones y además, del hecho de que en el mundo de las
necesidades de desarrollo existen requerimientos que pueden ser satisfechos
aprovechando esas teorías. Su objetivo central está en proveer tecnologías o
esquemas de acción derivados de los conocimientos teóricos construidos
anteriormente.
En resumen, la investigación contrastiva, se utilizó en la primera etapa de la
tesis, para establecer las semejanzas y diferencias encontradas entre el proceso
de desarrollo de software que lleva la UTIC de la ESPE, con la de la norma
ISO/IEC 12207; y en la segunda parte del proyecto, se utilizó la investigación
aplicativa, ya que el fin de la tesis es elaborar un estándar de aplicación de la
norma ISO/IEC 12207, al proceso de desarrollo de aplicaciones de software que
se lleva en la UTIC de la ESPE.
-8-
1.7.- Factibilidad
1.7.1.- Factibilidad Técnica
Los desarrolladores contarán con los conocimientos necesarios y suficientes
acerca de: ingeniería de software, estándares, desarrollo de software. Dentro de
la UTIC, existe el personal con los conocimientos necesarios para brindar la
asesoría necesaria para la satisfactoria realización de este proyecto.
•
Información: recopilada de la UTIC de la ESPE, normas y estándares
ISO.
•
Asesoramiento: Del personal, que se encuentra trabajando en el
desarrollo de software en la UTIC, así como del Director y Codirector
de tesis.
1.7.2.- Factibilidad Operativa
Al ser necesario, generar software de calidad en la UTIC de la ESPE, se
elaboró un plan de aplicación, que está basado en la norma ISO/IEC 12207, con
este fin, la Escuela Politécnica del Ejército, brindó el apoyo logístico,
proporcionado por parte del personal que trabaja dentro de la UTIC. Así como
también de la información que se disponga de los procesos que se manejan
actualmente en el desarrollo de aplicaciones de software.
-9-
1.7.3.- Factibilidad Económica
Todos los gastos contemplados en la Tabla 1.1, fueron asumidos por los
estudiantes ejecutores de este proyecto.
Tabla 1.1: (Descripción Factibilidad Económica)
INGRESOS
Aporte
$ 2.970
EGRESOS
Computadores personales
$ 1.800
SERVICIOS
Uso de equipos (energía eléctrica)
$ 100
Uso de internet
$ 200
Movilización
$ 220
OTROS RECURSOS
Material bibliográfico
$ 400
Material de oficina y copias
$ 120
Varios
$ 130
TOTAL
$ 2.970
-10-
CAPÍTULO II
2. MARCO TEÓRICO
La presente tesis, requiere del conocimiento previo de tres grandes temas
que en conjunto aportan para el entendimiento y solución del problema.
2.1.- Tecnologías de la Información y Comunicación (TIC)
2.1.1.- Antecedentes
La información y la comunicación, han sufrido cambios significativos dentro
de la sociedad, que son constatables a simple vista, la unión de los computadores
y las comunicaciones, desencadenaron una revolución a comienzo de los años
noventa, donde internet pasó de ser una herramienta creada con fines científicos,
a una red de fácil acceso y uso; nunca antes se había tenido acceso a tanta
información acumulada, ni tantos soportes diferentes o métodos tan sofisticados
para producir, reproducir y transmitir información;
se han desarrollado
instrumentos que cada vez son más poderoso y rápidos, que permiten la
comunicación en variadas formas, desde un mensaje de texto, hasta una
videoconferencia entre dos personas que se encuentre en diferentes puntos del
planeta.
Las Tecnologías de Información y Comunicación nacen de la convergencia
tecnológica de la electrónica, la informática (Software) y la infraestructura de
-11-
telecomunicaciones representadas, que rompieron los esquemas tradicionales de
comunicación y de acceso a la información
información.
ELECTRÓNICA
TELECOMUNICACIONES
INFORMÁTICA
TIC
Figura 2.1: (Convergencia Tecnologías de Información y Comunicación)
2.1.2.- Definición TIC
Para poder definir a las TIC (Tecnologías de Información y Comunicación),
es importante conocer previamente que la Tecnología, “es
es el conjunto de teorías y
técnicas que permiten el aprovechamiento práctico del conocimiento científico3,
en consecuencia las Tecnologías de la Información
Información y la Comunicación ,
conforman un conjunto de técnicas y elementos que tienen la función de:
procesar, almacenar, sintetizar,
ntetizar, recuperar y presentar la información,
información por medio
de herramientas computacionales e informáticas, brindando así una gran variedad
vari
de formas de comunicación.
Según la Asociación Americana de las Tecnologías de la Información ITAA4
por sus siglas en inglés son “el estudio, el diseño, el desarrollo, el fomento, el
mantenimiento y la administración de la información por medio de sistemas
3
4
Tomado de: http://definicion.de/tecnologia/
ITAA: Information Technology Association of America.
America
-12-
informáticos, esto incluye todos los sistemas informáticos, no solamente la
computadora este es solo un medio más, el más versátil, pero no el único;
también los teléfonos celulares, la televisión, la radio, los periódicos digitales, etc.”
Las Tecnologías de la información y Comunicación, tratan sobre el empleo
de computadores principalmente y software informático para transformar,
almacenar, gestionar, proteger, difundir y localizar los datos necesarios para
cualquier actividad que realice el ser humano.
Los
instrumentos
tecnológicos
como:
internet,
software,
redes
de
comunicación, bases de datos, entre otros, se han transformado en elementos
prioritarios en el desarrollo de la civilización, poseen característica que ayudan a
la comunicación sin fronteras geográficas y el fácil acceso a cualquier tipo de
información.
El uso de las TIC también es dual, ya que pueden servir como medio de
información y de entretenimiento, puede ser utilizado para beneficio o destrucción
de la sociedad, en cualquiera de los dos aspectos, depende de los usuarios que
ofrezcan contenidos de calidad, ya que es la audiencia quien determina y exige el
tipo de información que desea. Por tal motivo, se habla de la implicación de las
tecnologías dentro de la construcción de la sociedad.
-13-
2.1.3.- Características de las TIC
Las TIC tienen como características principales las siguientes:
Transforman la información, contenida en un medio físico a un digital,
almacenando gran cantidad de información en pequeño medios
físicos de almacenamiento.
Crean y dan apertura a nuevas formas de comunicación.
Aportan con métodos y herramientas tecnológicas, que facilitan el
aprendizaje en el campo educativo.
Permiten transmitir información, de manera inmediata a lugares
alejados.
Permiten transmitir información de manera dinámica.
Aportan beneficios económicos a largo plazo, debido a que minimizan
los tiempos de ejecución y mejoran la efectividad del desarrollo de
procesos y tareas.
Facilitan a través del software, la implantación de modelos de gestión
dentro de una organización.
Permiten la planificación de los recursos de una empresa, mediante la
implementación de sistemas ERP (Enterprise Resource Planning)5.
Permiten la automatización y seguimiento de procesos que
involucran documentos, información y tareas en las cuales intervienen diferentes
participantes, dentro de una empresa mediante software Workflow6.
5
ERP: Software de información centralizado orientado a registrar e integrar la mayoría de los
procesos de negocio.
6
Workflow: Permite la implementación, automatización y seguimiento de procesos administrativos
en donde se involucren documentos, información o tareas que pasen de un participante a otro(s).
-14-
2.1.4.- Ventajas y Desventajas de las TIC
Las ventajas y desventajas de las TIC, se pueden presentar desde diferentes
perspectivas, dependiendo del campo en el cual se estén aplicando, entre las
cuales podemos mencionar las siguientes:
2.1.4.1.- Ventajas
Integran la administración de la empresa, finanzas, talento humano,
etc.
Facilitan el análisis de la cadena de valor, ya sea de un producto o un
servicio con el fin de identificar que actividades no están generando
valor, para eliminarlas y disminuir costos.
Integran nuevas tecnologías y herramientas de vanguardia como el
software, aprovechando herramientas como Internet.
Proporcionan ventajas competitivas, si es que la competencia no
cuenta con el uso de las TIC, o si su departamento es menos
eficiente.
Permiten que la información que maneje una empresa, esté
disponible para todos los usuarios en tiempo real.
Permiten trabajar con un mismo sistema en puntos distantes.
Permiten el aprendizaje interactivo y la educación a distancia.
-15-
2.1.4.2.- Desventajas
Incrementar el riesgo a la pérdida de información.
Generan pérdidas de puestos de trabajo, en ciertos casos.
Exponen la información a robo de fuentes externas.
2.1.5.- Objetivos de las TIC en las Instituciones
Las Tecnologías de Información y Comunicación juegan un papel
estratégico muy importante en el crecimiento, madurez y evolución de una
institución, las actuales y futuras necesidades que se presentan, están basadas
en un gran porcentaje en las TIC, debido a que todas las actividades que se
manejan dentro de una institución, van apoyadas de la mano de estas.
Su evolución ha sido significativa dentro de una organización, al punto de
convertirse en un departamento que interrelaciona a todos los integrantes de una
institución que además facilita y genera información a través de programas
informáticos; información que es de vital importancia para el desempeño de la
institución.
Como objetivos de las Tecnologías de la Información que se plantean
dentro de una institución, se pueden mencionar las siguientes tareas y servicios
que brinda.
-16-
2.1.6.- Tareas del Departamento de TIC dentro de una Institución
Dentro de un departamento de Tecnologías de Información, se ejecutan
diversas tareas, entre las más importantes se pueden mencionar:
Monitorear, analizar la prospectiva tecnológica.
Planificar del desarrollo tecnológico.
Diseñar de estrategias de desarrollo tecnológico.
Identificar, evaluar y seleccionar las tecnologías.
Adaptar e innovar tecnología.
Negociar, adquirir y contratar tecnologías.
Comercializar tecnologías de la empresa.
Financiar el desarrollo tecnológico.
2.1.7.- Servicios del Departamento de TIC dentro de una Institución
Los departamentos de Tecnologías de la Información, dentro de una
institución proporcionan diferentes servicios a la empresa, entre los principales se
encuentran los siguientes:
Administración de aplicativos.
Desarrollo de software a la medida.
Adquisición de hardware y software para la institución.
Soporte y Mantenimiento del hardware y software de la institución.
Creación, manejo y administración de Base de Datos.
-17-
Administración de los servicios y redes de comunicación.
Desarrollo y administración de proyectos de Tecnologías de
Información
APLICATIVOS
(Administración,
Desarrollo,
Adquisición)
REDES DE
COMUNICACIÓN
(Adminsitración)
PROYECTOS DE TI
(Gestión,
Administraión,
Desarrollo)
DEPARTAMENTO
TIC
SOPORTE Y
MANTENIMIENTO
(Hardware y
Software)
BASE DE DATOS
(Creación, Manejo,
Administración)
Figura
ura 2.2: (Servicios de las TIC dentro de una Institución)
En la actualidad se está viviendo la “Sociedad de la Información” en la que
todo está basado en generar, difundir y acceder a información a través de
diferentes dispositivos que son manejados por programas informáticos.
El conocer e implementar las tecnologías de información y comunicación,
permiten facilitar tareas que antes se tornaban muy difíciles y lentas como la
correspondencia, facilitada ahora por el correo electrónico, además de tener
acceso a gran información de manera fácil y entablar comunicación con diversos
puntos del planeta, es ahí donde radica su importancia.
-18-
2.2.- Software
2.2.1.- Antecedentes
En el comienzo de la era de las computadoras, el software se consideraba
como un agregado del computador, los desarrollos de software que se realizaban,
no contaban con una metodología definida y el software era manejado por una
sola persona u organización, la misma que se encargaba de la administración y
corrección de errores, si se presentaban dentro de la aplicación.
A mediados de la década de los sesenta hasta finales de los setenta,
aparecen los programas multiusuario y ya se comienza a ver al software no como
un agregado del computador, sino como un producto, se cambio drásticamente la
forma de desarrollarlo, implementándose técnicas como la conocida estructura de
programación orientada a objetos, que ayuda a la creación de software de mejor
calidad y con un tiempo de vida más extenso, software que interactúan por medio
de redes de área local y área extendida con sistemas más grandes, aplicaciones
distribuidas, haciendo más importante y globalizada la utilización del software.
El software se ha convertido en una herramienta indispensable, por ejemplo
en el campo comercial, es importante para la toma de decisiones; en el campo
científico, es un apoyo fundamental en la realización de investigaciones y en otra
gran diversidad de campos como: telecomunicaciones, medicina, industria,
ingeniería, en fin; en el mundo actual a tomado una gran magnitud en el desarrollo
social y tecnológico que su uso es casi obligatorio.
-19-
2.2.2.- Definición de Software
Existen muchas definiciones de software, entre las cuales podemos
mencionar algunas de las que más se apegan a su significado:
“Se conoce como al equipamiento lógico o soporte lógico de una
computadora digital, y comprende el conjunto de los componentes lógicos
necesarios para hacer posible la realización de una tarea específica, en
contraposición a los componentes físicos del sistema (hardware).”7
“El software es un conjunto de programas elaborados por el hombre, que
controlan la actuación del computador, haciendo que éste siga en sus acciones
una serie de esquemas lógicos predeterminados.”8
En conclusión se puede definir al software como: Conjunto de componentes
o programas lógicos elaborados por el hombre, creados para realizar tareas, que
son presentadas a través de un computador; es el vínculo entre el hardware y el
hombre.
2.2.3.- Producto Software
El software como producto final, es visto desde dos puntos de vista, para el
desarrollador o ingeniero de software, son los datos, programas, documentos que
configuran todo el software, y desde el punto de vista de los usuarios, es la
7
Tomado de: http://es.wikipedia.org/wiki/Software
Tomado de: http://www.bloginformatico.com/concepto-y-tipos-de-software.php
8
-20-
información que se obtiene mediante la interacción con el software que facilita sus
tareas.
2.2.4.- Clasificación del Software
El software es aplicable en cualquier campo en el cual previamente se
hayan definido los requisitos necesarios para crearlo, por lo tanto su clasificación
está determinada en base a la estructura, naturaleza y la forma de entrada y
salida de información que requiere:
Software de Sistemas.
Software de Tiempo Real.
Software de Gestión.
Software de Ingeniería y Científico.
Software Empotrado.
Software de Computadores Personales.
Software basado en Web.
Software de Inteligencia Artificial.
-21-
2.2.4.1.- Software de Sistemas
Este tipo de software, está encargado de administrar los recursos que posee
un computador, permitiendo el control e interacción con el sistema operativo y
sirve como soporte para el funcionamiento de diferentes programas. Ejemplo:
Sistemas Operativos.
Entorno de escritorio.
BIOS.
Controlador de Dispositivos.
2.2.4.2.- Software de Tiempo Real
Este tipo de software, que coordina, analiza, y controla sucesos del mundo
real conforme se vayan presentando. Ejemplo:
Software que permite Optimización de consumo de gasolina en
automóviles.
Software que permite Interactuar con juegos.
-22-
2.2.4.3.- Software de Gestión
Este tipo de software se encarga de reestructurar datos de tipo comercial
existentes en diversas bases de datos, para facilitar operaciones comerciales y de
toma de decisiones.
Sistemas de base de datos orientados a un objeto.
Programas de creación de bases de datos relacionales.
Programas de creación de bases de datos distribuidas.
2.2.4.4.- Software de Ingeniería y Científico
Este tipo de software tiene como característica principal el uso de
algoritmos de manejo numérico, ahora las nuevas aplicaciones van más allá,
llegando al diseño asistido por computadora, simulación de sistemas y otras
aplicaciones iterativas.
Programas para fabricación automática.
Programas de análisis de presión de automotores.
-23-
2.2.4.5.- Software Empotrado
Este tipo de software reside en memoria solo de lectura, utilizado para
controlar los sistemas de mercados industriales y de consumo, sus funciones son
limitadas.
Programa control del tablero de un automóvil.
Programa que controla el botón de un horno microondas.
2.2.4.6.- Software de Computadores Personales
Este tipo de software se refiere a programas que se pueden encontrar en
un ordenador personal para manejo del usuario.
Hojas de cálculo.
Procesadores de Texto.
Multimedia.
-24-
2.2.4.7.- Software Basado en Web
Este tipo de software maneja instrucciones de ejecución como la HTML,
java y datos de diversos formatos, su acceso es por medio de la red a través de
un modem.
Servicio Web de los bancos.
Correo electrónico.
2.2.5.- Proceso de Creación de Software
El proceso de creación de software, es el conjunto de pasos lógicos y
secuenciales con el fin de lograr un objetivo, el producto software; lo realizan los
ingenieros de software y sus gestores que adaptan el proceso a sus necesidades
y lo siguen.
La duración de un proceso de desarrollo es indistinta, puede variar
dependiendo de diversos factores como son:
Tamaño del aplicativo.
Grado de dificultad.
Especificación de los Requisitos, etc.
Todo proyecto de desarrollo de software debe involucrar una buena
planificación y gestión de recursos tanto humanos como tecnológicos, para
-25-
obtener un producto final; como se menciono anteriormente, desde el punto de
vista del ingeniero de software, serán todos los documentos, datos y programas
que son consecuencia de las actividades de ingeniería de software definidas por
el proceso.
El proceso que se maneje para el desarrollo de software, dependerá del
tipo de software que se vaya a construir, un proceso puede ser el apropiado para
un sistema contable, y para la creación de un sitio web, puede ser otro proceso
totalmente diferente el apropiado.
Para crear software de calidad, es necesario implementar la ingeniería de
software, la cual se entiende como el análisis, diseño, construcción, verificación y
gestión del software, de la cual se deben cuestionar y responder las siguientes
preguntas:
¿Cuál es el problema a resolver?
¿Cuáles son las características del software que se utilizan para
resolver el problema?
¿Qué realizará el software?
¿Cómo se construirá el software?
¿Qué enfoque se va a utilizar para contemplar los errores que se
cometan en el diseño y en la construcción del software?
¿Cómo
se
apoyará
el
software
cuando
usuarios
correcciones, adaptaciones y mejoras de la entidad?
-26-
soliciten
2.2.6.- Proceso, Métodos y Herramientas
Para el desarrollo de un software de calidad, es importante la aplicación de
la ingeniería de software, debido a que proporciona una estructura multicapas que
está enfocada hacia la calidad del producto final y se mencionan a continuación.
2.2.6.1.- Proceso
Es el que ayuda a establecer un marco de trabajo, para un grupo de áreas
claves, las cuales son la base del control de gestión de proyectos de software y
son los que establecen el contexto en el que se aplican los métodos técnicos, se
obtienen productos del trabajo (modelos, métodos, documentación, datos).
2.2.6.2.- Métodos
Son los que indican cómo construir técnicamente el software, estos
abarcan una gran variedad de tareas como son la especificación de requisitos,
diseño del software, pruebas. Los métodos de la ingeniería del software dependen
de un conjunto de principios básicos que rigen cada área de la tecnología e
incluyen actividades de modelado y otras técnicas descriptivas.
-27-
2.2.6.3.- Herramientas
Son aquellas que proporcionan una guía automática y semiautomática para
el proceso y para los métodos.
2.2.7.- Fases Principales del Desarrollo de Software
El
desarrollo
de
aplicativos
mediante
la
ingeniería
de
software,
independientemente de la complejidad, dimensión y del campo en el que se vaya
a aplicar, se puede dividir en tres grandes faces:
Fase de Definición.
Fase de Desarrollo.
Fase de Mantenimiento.
2.2.7.1.- Fase de Definición
“Qué se va desarrollar”, aquí se definen los requerimientos funcionales y no
funcionales (complementarios) del software, esta fase es muy importante porque
aquí el desarrollador debe tratar de identificar cuáles van a ser las funciones que
desempeñe el software, que información requiere procesar, como va a
comportarse el sistema, como debe ser el interfaz que va a manejar el usuario,
todas las validaciones que se deben realizar, en fin establecer los requisitos
claves, existe una rama de la ingeniera de software que se dedica exclusivamente
-28-
a los requerimientos del software denominada ingeniería de requisitos, la cual
permite:
Comprender el problema.
Facilitar la obtención de las necesidades del cliente/usuario.
Validar con el cliente/usuario.
Garantizar las especificaciones de requisitos.
Figura 2.3: (Tareas para Captura y Análisis de Requisitos)
2.2.7.2.- Fase de Desarrollo
“Cómo se va a desarrollar”, es la implementación de los requisitos
obtenidos en la fase anterior, aquí se define que arquitectura se va a manejar
para implementar las funciones que requiere el software, la estructuración de los
datos, generación de código que dependiendo de la forma de trabajo y lenguaje
elegido puede adoptar varios estados como: código fuente (programador), código
-29-
objeto (código fuente compilado), código ejecutable (resultado de enlazar código
objeto con rutinas y bibliotecas necesarias) y las pruebas que se van a
implementar.
Se pueden realizar varias pruebas en el software como por ejemplo:
Pruebas Unitarias
Este tipo de pruebas se realiza en secciones del software: procedimientos,
funciones, módulos, son utilizadas para asegurar el funcionamiento por partes del
código.
Figura 2.4 (Ejemplo Resultado Pruebas Unitarias JUnit)
-30-
Pruebas de Integración
Este tipo de pruebas se realizan luego de que se concluyó con las pruebas
unitarias con resultados exitosos, lo que hacen es comprobar que todo el sistema
y subsistemas en conjunto funcionan correctamente.
Existen diversas metodologías para integrar el software, entre las más
utilizadas esta:
Integración TOP-DOWN
El sistema se construye por fases empezando por los componentes que
llaman a otros componentes.
1
2
4
3
5
6
7
Módulo reemplazado por un stub
Stub
Figura 2.5: (Metodología de Integración TOP_DOWN)
A medida que se integran los módulos, se realizan pruebas de regresión
para capturar y corregir nuevos errores.
-31-
Ventajas
La lógica de control del sistema se prueba relativamente pronto.
Los grandes problemas conceptuales de diseño se identifican
rápidamente.
Se puede obtener un sistema que funcione parcialmente en un
momento temprano del proyecto.
La codificación puede comenzar antes de que los detalles de diseño a
bajo nivel estén completos.
Inconvenientes
Los problemas de interfaces a bajo nivel se detectan tarde.
Gran número de stubs9 a mantener.
No se puede aplicar en diseños orientados a objetos y sistemas
interactivos.
Pruebas de Regresión
Son cualquier tipo de pruebas, que tratan de descubrir las causas de
errores nuevos, carencias de funcionalidad o cambios funcionales con
respecto al funcionamiento que se espera del software.
9
Stub: En el contexto del testeo del software, un trozo de código usado como sustituto de alguna
otra funcionalidad. Un stub puede simular el comportamiento de código existente (tal como un
procedimiento en una máquina remota) o ser el sustituto temporal para un código aún no
desarrollado.
-32-
2.2.7.3.- Fase de Mantenimiento
En esta fase se maneja la corrección de errores que se detecten en el
software, implementaciones que se vayan realizando debido a los nuevos
requerimientos del cliente, y cambios en el software debido a las modificaciones
que se presenten en su entorno, en esta fase se presentan cuatro tipos de
cambios:
Corrección
Se realiza para corregir errores que el cliente encuentre en el software, es
muy probable que se presenten.
Adaptación
Debido a cambios que se puedan presentar en el entorno exterior del
software, será necesario hacer adaptaciones al mismo, se pueden presentar en:
cambios de sistema operativo, equipo, reglas de negocio que van cambiando en
la empresa, entre otros.
Mejora
Cuando el cliente a medida que utiliza el software, va descubriendo
funciones extras que van a ser de su beneficio; este mantenimiento vas mas allá
de los requerimientos iniciales.
-33-
Prevención
Este mantenimiento consiste en realizar cambios con la finalidad de que el
software se pueda adaptar, corregir y realizar mejoras de manera más fácil,
debido a que el software se deteriora por los cambios que se generan en su
entorno.
Entre las actividades típicas de esta categoría se incluyen:
Seguimiento y control del proyecto de software.
Revisiones técnicas formales.
Garantía de calidad del software.
Gestión de configuración del software.
Preparación y producción de documentos.
Gestión de reutilización.
Mediciones.
Gestión de riesgos.
Estas actividades se aplican durante todo el Ciclo de Vida del Software 2.2.8.
2.2.8.- Ciclo de Vida de Software
El ciclo de vida del software, es un término que define todo el proceso del
desarrollo de software, desde su etapa de inicio hasta su etapa de finalización, en
estas etapas se describen todas las actividades que se deben realizar cuando se
-34-
está creando software, las mismas que tratan de seguir un orden secuencial y
coherente entre cada etapa.
2.2.8.1.- Modelos del Ciclo de Vida del Software
Los modelos de ciclo de vida de software, tienen como finalidad facilitar a
los ingenieros de software, la organización de las actividades que se deben
ejecutar en el desarrollo de un proyecto, permitiendo minimizar tiempos, costos,
establecer plazos de entrega, etc., que determinan la calidad del producto final
que se entrega al cliente, entre algunos de los modelos más importantes podemos
mencionar:
2.2.8.1.1.- Modelo Lineal
Este modelo de ciclo de vida del software, se realiza de manera lineal,
porque cada etapa se realiza una sola vez y su ordenamiento está basado en la
espera de la culminación de una etapa para comenzar con la siguiente.
Es conocido también como modelo lineal secuencial, modelo clásico o
modelo tradicional, es muy difícil de implantar de forma pura debido a su
exigencia, puesto que no hay como retroceder entre una fase y otra, lo que
implica que cada fase debe estar sin errores, algo que es muy difícil que se
cumpla en un desarrollo de software, este modelo puede ser aplicable en
desarrollos muy cortos y de baja complejidad.
-35-
ANÁLISIS
DISEÑO
IMPLEMENTACIÓN
INTEGRACIÓN Y PRUEBAS
OPERACIPON Y
MANTENIMIENTO
Figura 2.6: (Representación Modelo Lineal)
2.2.8.1.2.- Modelo Cascada
Es
s una variación que se utiliza en el modelo lineal, que consiste en la
retroalimentación de etapas, por ejemplo, si se pasa de la fase de definición de
requerimientos al análisis de diseño de software, puede haber algunas
modificaciones posteriores en las especificaciones, para conllevar estos cambios,
se realiza una retroalimentación entre las fases para poder
poder continuar con el
modelo.
ANÁLISIS
DISEÑO
IMPLEMENTACIÓN
INTEGRACIÓN Y PRUEBAS
OPERACIPON Y
MANTENIMIENTO
Figura 2.6:
2.6 (Representación Modelo Cascada)
-36-
2.2.8.1.3.- Modelo Evolutivo
El modelo de ciclo de vida evolutivo, acepta que los requerimientos pueden
cambiar en cualquier momento durante el desarrollo, en la práctica, es muy difícil
que se puedan entregar todos los requerimientos al comienzo del desarrollo, en
este modelo se realiza la iteración de los ciclos: requisitos, desarrollo, evaluación.
Es un modelo muy útil, cuando no se conoce los requerimientos al inicio de
un proyecto, no están completos o se desconoce de la mayoría ellos.
Figura 2.8: (Representación Modelo Evolutivo)
2.2.8.1.4.- Modelo Incremental
El modelo de ciclo de vida incremental, está basado en la construcción en
incrementos, que se retroalimentan con los anteriores para ir mejorando y
ampliando el desarrollo, mientras se realiza un incremento, se puede empezar
-37-
otro en cualquier momento,
momento el modelo sugiere un enfoque incremental, como
forma para reducir la repetición del trabajo y así retrasar la toma de decisiones en
los requerimientos, hasta adquirir experiencia con el sistema.
Por lo general se construye un incremento sobre otro que ya fue terminado,
a medida que se va avanzando se obtiene un producto software con mayores y
mejoradas funcionalidades, hasta el cumplimiento de la totalidad del proyecto.
1 INCREMENTO
• Analisis - Diseño Implementación 2 INCREMENTO
Pruebas
• Analisis - Diseño Implementación - Pruebas
3 INCREMENTO
• Analisis - Diseño Implementación - Pruebas
4 INCREMENTO
• Analisis - Diseño Implementación - Pruebas
Tiempo de Calendario
2.9 (Representación Modelo Incremental)
Figura 2.9:
2.2.8.1.5.- Modelo Espiral
El modelo de ciclo de vida en Espiral, consiste en una serie de ciclos que
se repiten, es decir que en cada fase de este modelo van a existir los mismos
ciclos, con la finalidad de obtener un software, que va creciendo hasta obtener el
final en el último ciclo
iclo del proceso, en esta parte tiene similitud al modelo
-38-
incremental. Se divide en regiones de tarea, que son el número de actividades del
marco de trabajo.
Todos los circuitos, representan puntos de inicio de los proyectos que están
relacionados, por ejemplo el proyecto de desarrollo de conceptos comienza en el
origen de la espiral y culmina en la última tarea del circuito marcada de color
verde como muestra la Figura 2.10, a medida que el ciclo se cumple, se sigue
obteniendo prototipos del desarrollo, que van ganando la satisfacción del cliente o
usuario, es muy útil para el desarrollo de sistemas operativos complejos.
Figura 2.10: (Representación Modelo Espiral)
La gran demanda y utilización del software, la diversidad de campos donde
tiene aplicación, la importancia de la información que maneja y genera, la
-39-
complejidad de las operaciones que puede realizar, han llevado a crear diversas
formas de desarrollarlo, con la finalidad de mejorar el producto, para satisfacer las
necesidades para las cuales fue creado.
2.3.- Norma ISO/IEC 12207
2.3.1.- Introducción
La Norma ISO/IEC 12207, fue la primera norma internacional que
proporcionó un amplio conjunto de procesos de ciclo de vida del software, el cual
forma parte de un sistema mayor, se realizó su primera publicación el 1 de agosto
de 1995, la misma que fue precedido en noviembre del 2002 por la norma
ISO/15288 que trata los procesos del ciclo de vida de un sistema.
Según esta norma, el software y sus procesos de diseño, no deben estar
desvinculados de los sistemas, por el contrario deben ser tomados como una
parte integral de los procesos de diseño de sistemas, la norma puede ser
utilizada:
•
Por una organización: para ayudar a establecer un entorno de
trabajo.
•
Por un proyecto: para ayudar a seleccionar una infraestructura y
emplear todos los elementos que comprenden un conjunto de ciclo
de vida establecido.
-40-
•
Por un comprador o proveedor: para ayudar a desarrollar un acuerdo
sobre los procesos y actividades que se van a manejar.
•
Por las organizaciones y asesores: para realizar evaluaciones que
puedan servir de apoyo para mejorar los procesos de la
organización.
2.3.2.- Definiciones Importantes
Antes de entrar en materia de la norma, es necesario conocer las
definiciones de términos que facilitaran el entendimiento de la misma.
2.3.2.1.- Estándar
Un estándar es un modelo o conjunto de reglas y procedimientos
documentados que se siguen con la finalidad de cumplir un objetivo.
2.3.2.2.- ISO
Son las siglas de (International Organization for Standardization), proviene
del griego (isos), que significa igual, la Organización Internacional de
Estandarización, es un organismo que promueve el desarrollo de normas
internacionales de comercio y comunicación, para todas las ramas de la industria
con excepción de la electrónica, su principal objetivo es el de estandarizar
productos y seguridad para organizaciones o empresas a nivel internacional.
-41-
Todos los países que son miembros de esta organización, están
representados por sus respectivas instituciones de normalización, que se
comprometen a respetar las reglas que son establecidas por ISO, que son
relativas al conjunto de normas nacionales, estas normas son voluntarias y su
sede principal se encuentra en Ginebra.
2.3.2.3.- IEC
La Comisión Electrónica Internacional IEC (International Electronic
Comission), es una organización que se encarga de la normalización en el campo
eléctrico, electrónico y en todas las tecnologías que se encuentren relacionadas,
existen numerosas normas que se elaboran conjuntamente con la ISO conocidas
como normas ISO/IEC, como es el caso de la norma ISO/IEC 12207.
2.3.3.- Norma ISO/IEC 12207:2008
La norma ISO/IEC 12207:2008 la cual será tomada como referencia para
elaborar el estándar de aplicación de desarrollo de software, implanta un marco
común para los procesos de ciclo de vida de software, estableciendo dentro de
estos procesos, terminologías bien definidas que hacen referencia a la industria
del software.
Está conformada por procesos, actividades y tareas que se deben aplicar
durante la adquisición, suministros, desarrollo, operación, mantenimiento y
eliminación de productos o servicios de software.
-42-
Esta norma se emplea para definir, controlar y mejorar los procesos del
ciclo de vida de software, su aplicación se puede realizar sola o en conjunto con
otras normas, dependiendo de las necesidades existentes.
2.3.3.1.- Propósito
El objetivo de la norma ISO/IEC 12207, es proporcionar un conjunto de
procesos
bien
definidos,
que
permitan
facilitar
la
comunicación
entre
compradores, proveedores y demás inmersos en el ciclo de vida del software.
Está escrita, encaminada a los adquirientes de sistemas, productos de
software y servicios, proveedores, desarrolladores, operadores, gerentes,
directores de control de calidad y usuarios.
Está propuesta, para ser aplicada en una situación en la cual participan dos
partes, donde ambas partes pertenecen a la misma organización, dicha situación
puede variar desde un simple acuerdo informal, hasta un contrato que este
jurídicamente establecido, también puede ser establecida en una única parte a
través de la auto imposición establecida de los procesos.
2.3.3.2.- Limitaciones
No detalla el ciclo de vida de los procesos, en términos de métodos o
procedimientos necesarios para cumplir con los requisitos y los resultados de un
proceso.
-43-
No posee documentación detallada en términos de nombre, formato,
contenido explícito y medios de grabación, puede requerir de la elaboración de
documentos adicionales de características semejantes a la norma, sin embargo,
esto no implica que la documentación sea desarrollada por separada o en
conjunto, de alguna manera, esta decisión queda a criterio del usuario de la
norma; la norma ISO/IEC 15289 aborda contenido de elementos de información
para el proceso de ciclo de vida (documentación).
2.3.3.3.- Conformidad
2.3.3.3.1.- Uso Correcto
La aplicación de esta norma en general, consiste en seleccionar un
conjunto de procesos y adecuarlos para determinada organización o proyecto, en
vista de que no en toda organización o proyecto será necesaria la inclusión de
todos los procesos establecidos en la norma.
Existen dos formas en las cuales se puede afirmar que una implementación
se ajusta a esta norma. Cualquier declaración de conformidad puede ser citada en
una sola de las dos formas que se muestran a continuación:
2.3.3.3.2.- Conformidad Completa
Se denomina una conformidad completa, cuando se demuestra que todos
los procesos establecidos por la norma, han sido satisfechos usando los
resultados como evidencia de esto.
-44-
2.3.3.3.3.- Conformidad a la Medida
Se denomina conformidad a la medida, cuando esta norma utiliza como
base un conjunto de procesos específicos, y estos han sido satisfechos usando
los resultados como evidencia de esto.
2.3.3.4.- Recomendaciones de la Norma ISO/EC 12207:2008 para
los Procesos del Ciclo de Vida del Software
La norma recomienda un marco común para los procesos de ciclo de vida
del software, que nace de una idea o una necesidad, que puede ser satisfecha en
parte o en su totalidad por el software y que culmina con la jubilación del mismo.
La creación de un sistema o de un software, puede estar conformado por
diversos modelos de ciclo de vida, como los mencionados en el numeral 2.2.8.1
del presente capítulo, los cuales constan de etapas que representan la vida del
software, desde su concepción, hasta la culminación de su uso o para representar
el estado actual de un proyecto de desarrollo.
Esta norma, no requiere la implementación de un modelo de ciclo de vida
de software, pero recomienda que para cada proyecto se defina el modelo de
ciclo de vida apropiado, de manera preferencial un modelo que haya sido
establecido por la organización para manejar diversos proyectos.
-45-
Esta norma, no requiere de un conjunto de etapas determinadas, por
ejemplo en una fase de ciclo de un sistema interviene: concepto, desarrollo,
producción, utilización, apoyo y jubilación, o en el caso de ciclo de vida de un
producto software: desarrollo, operación y mantenimiento.
2.3.3.5.- Organización de la Norma ISO/IEC 12207:2008
2.3.3.5.1.- Categorías del Proceso de Ciclo de Vida del Software
La ISO/IEC 12207:2008, agrupa las actividades que se pueden realizar
durante el proceso de ciclo de vida, de un sistema de software en siete (7) etapas,
cada uno de estos grupos, se describen en función del propósito y resultados que
se desean obtener, se enumeran las actividades y tareas que se deben seguir
para el cumplimiento de dichos resultados.
Procesos de Acuerdo.
Procesos Organizativos de Habilitación del Proyecto.
Procesos de Proyecto.
Procesos Técnicos.
Procesos de Implementación del Software.
Procesos de Soporte de Software.
Procesos de Reutilización del Software10
10
Tomado de: Norma ISO/IEC 12207:2008
-46-
Figura 2.11: (Ciclo de Vida de los Procesos de Software de 12207)
-47-
-48-
Figura 2.12: (Selección de Elemento(s) de la Norma que se ajustan a necesidades de la Organización)
2.3.3.5.2.- Estructura de los Procesos del Ciclo de Vida del
Software según la Norma ISO/IEC 12207
Los procesos de la Norma ISO/IEC 12207 están distribuidos de la siguiente
manera:
Procesos del Contexto del sistema:
Procesos de Acuerdo.
Procesos de Proyecto.
Procesos Técnicos.
Procesos Específicos del Software:
SW. Procesos de Implementación.
SW. Procesos de Apoyo.
Procesos de Reutilización del Software:
Proceso de Ingeniería del Dominio.
Proceso de Gestión de Reúso de Activos.
Proceso de Gestión de Reúso del Programa.
-49-
La estructura de los procesos se detalla con más precisión en la Figura
2.13.
Figura 2.13: (Estructura de los Procesos de ISO/IEC 12207:2008)
La norma ISO/IEC 12207 define cuarenta y tres procesos que pueden
aplicarse durante la adquisición, suministro, desarrollo, operación, mantenimiento
y evolución de productos software.
-50-
Para el caso de la presente tesis, el uso de la norma está enfocada a la
etapa de desarrollo de software, para lo cual se evaluó los procesos que pueden
ser implementos en la UTIC de la ESPE y el estándar de aplicación resultante
quedó como base de una estructura, que puede ser adaptada a una estructura de
nivel superior, que abarque todas las etapas del proceso de ciclo de vida del
software dado por norma ISO/IEC 12207 y otras relacionadas a esta.
-51-
CAPÍTULO III
3. ANÁLISIS UTIC ESPE Y PROCESO DE DESARROLLO DE
SOFTWARE
El presente capítulo, pretende mostrar la estructura de la UTIC (Unidad de
Tecnologías de la Información) de la ESPE, las funciones que desempeña dentro
de la institución y específicamente cómo manejan el proceso de desarrollo de
software; la información acerca de la UTIC, se tomó del sitio de Gestión de
Tecnología de la Información y Comunicaciones11, y de la ayuda del personal de
la unidad.
3.1.- Funciones de la UTIC de la ESPE
La UTIC, está encargada de gestionar todo lo relacionado a las
Tecnologías de la Información que se manejan dentro de la ESPE, su estructura
se descompone en macro procesos, procesos y subprocesos, que engloban todas
las actividades que se realizan dentro de la unidad.
11
Tomado de: http://sgc.espe.edu.ec/Paginas/mapa.html
-52-
3.2.- Gestión del Departamento de Tecnología de la Información y
Comunicaciones (UTIC-ESPE)
La gestión que se realiza dentro del departamento, está distribuida en los
cinco procesos que se mencionan a continuación; estos, reflejan todas las
actividades que se despeñan en la UTIC:
GT.1 Gestión Estratégica de Tecnologías de Información.
GT.2 Gestión y Soporte Técnico.
GT.3 Administración de Redes, Comunicaciones y Servicio.
GT.4 Desarrollo, Implantación y Mantenimiento de Aplicativos.
GT.5 Administración de Aplicativos y Base de Datos.
3.2.1.- GT.1 Gestión Estratégica de Tecnologías de Información
El objetivo de este proceso es el de controlar y ejecutar todos los proyectos
relacionados con tecnologías de información y comunicación de la ESPE, y del
plan de contingencia, optimizando recursos en base a las exigencias tecnológicas
y dando prioridad a las necesidades de la institución.
3.2.2.- GT.2 Gestión y Soporte Técnico
El objetivo de este proceso es el de dar asistencia técnica de primer nivel y
segundo nivel (avanzada), la cual incluye: instalación, actualización de equipos
y/o elementos informáticos, con la finalidad de conservar los equipos informáticos
-53-
funcionando en correcto estado, actualizados y que satisfagan los requerimientos
de los clientes.
3.2.3.- GT.3 Administración de Redes, Comunicaciones y Servicio
El objetivo de este proceso es el de proporcionar a la comunidad politécnica
todos los servicios integrados de red, internet, intranet y comunicaciones de
acuerdo a los avances tecnológicos, elaborando un seguimiento y registrando las
actividades de la red, detección de eventos y ejecutando las acciones que sean
necesarias para garantizar los servicios de comunicación requeridos en la ESPE.
3.2.4.- GT.4 Desarrollo, Implantación y Mantenimiento de Aplicativos
El objetivo de este proceso, inicia con la recepción de un requerimiento o el
identificar la necesidad de un nuevo aplicativo o actualización/modificación de uno
ya existente, y termina con la implantación de un nuevo aplicativo o la
actualización de uno ya existente (una nueva versión).
3.2.5.- GT5 Administración de Aplicativos y Base de Datos
Se encarga de administrar todos los aplicativos (sistemas informáticos) de la
ESPE, para garantizar su disponibilidad y permanente operatividad, además de
garantizar la integridad, confidencialidad y seguridad de la información que se
almacena en la base de datos.
-54-
3.3.- Árbol de Gestión y Tecnología Informática (UTIC-ESPE)
La UTIC se encuentra estructurada jerárquicamente por macroprocesos,
procesos y subprocesos que cumplen funciones determinadas dentro del
departamento como se puede ver en la Figura 3.1.
Figura 3.1: (Estructura UTIC ESPE)
-55-
Todos los servicios que brinda el departamento, dan como resultado la
salida de un producto que es de beneficio para la institución Figura 3.2.
Figura 3.2: (Árbol Productos/Servicios UTIC ESPE)
3.4.- Análisis del GT.4 (Desarrollo, Implantación y Mantenimiento de
Aplicativos)
El GT.4 abarca todo lo referente al manejo de desarrollo de software dentro
de la institución, por lo cual es el área en donde más se centrara el análisis dentro
de la UTIC.
-56-
3.4.1.- Objetivo
Gestionar la implantación o mantenimiento de aplicativos, en base al análisis
de requerimientos institucionales y de usuario.
3.4.2.- Alcance
Este proceso inicia con la recepción de un requerimiento o la identificación
de una necesidad de un nuevo aplicativo o actualización/modificación de uno
existente; y termina con la implantación de un nuevo aplicativo o la actualización
de uno ya existente (nueva versión).
3.4.3.- Responsable
Coordinador de GT4 / Director de UTIC / Especialista de TI.
3.4.4.- Requisitos Legales
Reglamentos de la Escuela Politécnica del Ejército.
Ordenes de Rectorado.
Directivas.
-57-
3.4.5.- Políticas Internas
Implementar aplicativos sobre requerimientos institucionales y del
usuario.
Se deberá mantener un respaldo de todas las versiones de un
aplicativo.
Los aplicativos adquiridos y en general tercerizados deberán incluir la
garantía técnica.
3.4.6.- Subprocesos
El proceso Desarrollo, Implantación y Mantenimiento de Aplicativos está
compuesto por los siguientes subprocesos:
Tabla 3.1: (Subprocesos GT4 y Periodicidad)
NOMBRE
PERIODICIDAD
Análisis y Diseño para el Desarrollo de Aplicativos.
Continua.
Construcción de Aplicativos.
Continua.
Implantación de Aplicativos.
Continua.
NOTA: La periodicidad depende de la recepción y priorización de los
requerimientos.
-58-
3.4.7.- Registros Controlados
Tabla 3.2: (Registros Controlados GT4)
REGISTRO
Memorando (de
contestación).
Requerimientos de
Aplicativos.
Especificaciones
Técnicas (archivo
digital).
Modelos.
Bitácora del
aplicativo.
Manual del
aplicativo.
UBICACIÓN
Unida de
Tecnología y
Telecomunicaci
ones UTIC.
Desarrollo,
Implantación y
Mantenimiento
de
Aplicativos.
Desarrollo,
Implantación y
Mantenimiento
de
Aplicativos.
Desarrollo,
Implantación y
Mantenimiento
de
Aplicativos.
Desarrollo,
Implantación y
Mantenimiento
de
Aplicativos.
Desarrollo,
Implantación y
Mantenimiento
de
Aplicativos.
RECUPERACIÓN
ORDEN
ACCESO
Cronológico
Abierto
Aplicativo,
fecha
Abierto
Aplicativo,
fecha
Abierto
Aplicativo,
fecha
Abierto
Aplicativo,
fecha
Abierto
Aplicativo,
fecha
Abierto
-59-
RETENCIÓN
Tres años.
Tres años, se
enviará a
disposición en
enero de cada
año siempre y
cuando haya sido
finalizado.
Tres años, se
enviará a
disposición en
enero de cada
año siempre y
cuando haya sido
finalizado.
Tres años, se
enviará a
disposición en
enero de cada
año siempre y
cuando haya sido
finalizado.
Indefinida, copia
cada 3 meses a
Archivo General y
cada 6 meses a
ESPE-Idiomas.
Tres años, se
enviará a
disposición en
enero de cada
año siempre y
cuando haya sido
finalizado.
DISPOSICIÓN
Archivo General
Archivo General
Archivo General
Archivo General
Archivo
General/ESPE
IDIOMAS
Archivo general
3.4.8.- Documentos Controlados
No existen.
3.4.9.- Instrucciones Aclaratorias
Análisis y Diseño para Desarrollo de Aplicativos
Instrucción aclaratoria Figura 3.3.
6. Las tendencias actuales para la construcción de aplicativos determinan
que de cualquier fase del desarrollo del aplicativo se puede retomar a cualquiera
de las fases anteriores.
Construcción de Aplicativo
Instrucciones aclaratorias Figura 3.4.
5. Probar versión del aplicativo: pruebas internas y de integración.
6. Almacenar versión en archivo de versiones de aplicativo (respaldos):
en ocasiones se requiere verificar en una determinada fecha como funcionó el
aplicativo o una versión anterior del mismo.
Implantación de Aplicativos
Instrucciones aclaratorias Figura 3.5.
-60-
4. Autorizar Liberación: En ciertos casos el nuevo aplicativo se libera
cuando se requiere una actualización masiva para inicio de otro proceso como por
ejemplo matriculas.
5. Liberar la Versión: Poner en funcionamiento el nuevo aplicativo o nueva
versión en el área real.
3.4.10.- Procesos para el Desarrollo de Software en la UTIC de la
ESPE
En las siguientes figuras, se muestra el orden en el cual se desarrollan los
subprocesos que conforman el GT4, y los pasos a seguir para cumplir con el
objetivo de cada uno de ellos.
NOTA Los flujogramas presentado a continuación, poseen salidas
de proceso (evidencia documental), que hacen referencia a
aclaraciones realizadas en la parte de Instrucciones Aclaratorias
3.4.9.
-61-
3.4.10.1.- Análisis y Diseño para el Desarrollo de Aplicativos
Figura 3.3: (Diagrama Análisis y Diseño para el Desarrollo de Aplicativos)
-62-
3.4.10.2.- Construcción de Aplicativos
Figura 3.4: (Diagrama Construcción de Aplicativos)
-63-
3.4.10.3.- Implantación de Aplicativos
Figura 3.5: (Diagrama Implantación de Aplicativos)
-64-
3.5.- Análisis Crítico de los Procesos más Importantes y Urgentes de la
Norma ISO/IEC 12207:2008, referentes al Desarrollo de Software
En base a una encuesta realizado al personal del GT4 de la UTIC de la
ESPE, se determinó el nivel en el que los encuestados consideran importante y
urgente el implementar dentro de la unidad, los procesos que propone la norma
ISO/IEC 12207:2008 para el desarrollo de software.
Criterio de Evaluación
La evaluación se la realizó determinando el grado de importancia y
urgencia de cada proceso bajo los siguientes parámetros de calificación:
A = Alta
M = Media
B = Baja
Ponderación de cada Respuesta
La ponderación de cada respuesta es la siguiente:
Alta = 7
Media = 5
Baja = 3
-65-
Los resultados se obtienen a partir de una media aritmética (valor
resultante de la suma de todos los valores dividido entre el número de sumandos),
realizada con los valores asignados por los encuestados en cada una de las
preguntas:
Fórmula:
_
x=
a1 + a2 + ...a n
1 n
a
=
∑
1
n i =1
n
Encuestados:
Área de trabajo: UTIC – Tecnologías de Información
Cargo: Técnico especialista 2
Iniciales: TE121
Área de trabajo: UTIC – Tecnologías de Información
Cargo: Especialista Tecnologías de Información 3
Iniciales: TE2
Comentario: Todas las actividades relacionadas al software y que
describen son altamente importantes, la urgencia dependerá del proyecto
específico, que trate en cada actividad.
12
TE: Técnico Especialista UTIC ESPE
-66-
Área de trabajo: UTIC – Tecnologías de Información
Cargo: Técnico Especialista
Iniciales: TE3
Área de trabajo: UTIC – Tecnologías de Información
Cargo: Técnico Especialista TIC
Iniciales: TE4
Tabla 3.3: (Matriz de Importancia Urgencia Procesos ISO/IEC 12207:2008)
PROCESOS DE IMPLEMENTACIÓN
IMPORTANCIA
ENCUESTADOS
URGENCIA
MEDIA
T1
T2
T3
T4
Proceso de Implementación de
Software.
7
7
5
7
Proceso de Análisis de
Requerimientos del Software.
7
7
7
Proceso de Diseño de Arquitectura
del Software.
7
7
Proceso de Diseño Detallado del
Software.
7
Proceso de Construcción del
Software.
X
MEDIA
X
T1
T2
T3
T4
7
7
7
5
7
7
7
7
7
7
7
7
7
7
7
7
7
5
7
7
7
7
7
7
7
7
5
7
7
7
5
7
7
7
7
7
7
7
7
7
Proceso de Integración del
Software.
7
7
7
7
7
7
5
7
7
7
Proceso de Sistema de Calificación
de Pruebas.
7
7
5
7
7
7
3
5
7
7
PROCESOS
-67-
Tabla 3.4: (Matriz de Importancia Urgencia Procesos de Apoyo ISO/IEC
12207:2008)
PROCESOS DE APOYO
IMPORTANCIA
ENCUESTADOS
T1
PROCESOS
Proceso de Gestión de la
7
Documentación del Software.
URGENCIA
MEDIA
T2
T3
T4
7
5
5
X
MEDIA
X
T1
T2
T3
T4
6
7
7
5
5
6
Proceso de Gestión de la
Configuración del Software.
3
3
5
5
4
7
5
5
7
6
Proceso de Aseguramiento de la
calidad del Software.
7
7
5
7
7
7
3
5
5
5
Proceso de Verificación del
Software.
5
7
5
7
6
6
3
5
5
4
Proceso de Validación del
Software.
5
7
7
7
7
7
3
7
5
6
Proceso de Revisión del Software.
5
7
7
5
6
5
3
5
7
5
Proceso de Auditoría del Software.
5
7
5
5
6
5
3
5
7
5
Proceso de Resolución del
Problemas del Software.
5
7
5
5
6
5
5
5
5
5
Los resultados obtenidos de la encuesta, reflejados en las matrices de
Importancia y Urgencia Tabla 3.3, Tabla 3.4 de los procesos de Implementación y
Apoyo de ISO/IEC 12207:2008 respectivamente; demuestran que dichos
procesos son de interés del personal del GT4 de la UTIC, como opción de mejora
en la calidad del software que se desarrolla en la ESPE.
-68-
3.6.- Comparación de los Procesos de la UTIC ESPE vs Procesos Norma
ISO/IEC 12207:2008.
Para realizar la comparación de los dos procesos, se elaboró diagramas de
flujo correspondientes a cada uno de los procesos que maneja la norma,
presentados en las Figuras 3.6, 3.7, 3,8, 3.9, 3.10 y 3.11, y a continuación se
muestra una tabla comparativa, contrastando ambas metodologías, Tabla 3.5.
-69-
Actividades / Tareas
Responsable
Figura 3.6: (Diagrama de Análisis de Requerimientos)
-70-
Actividades / Tareas
Responsable
Figura 3.7: (Diagrama de Proceso de Diseño de Alto Nivel)
-71-
Actividades / Tareas
Responsable
Figura 3.8: (Diagrama de Proceso de Diseño Detallado de Software)
-72-
Actividades / Tareas
Responsable
Figura 3.9: (Diagrama Proceso de Construcción de Software)
-73-
Actividades / Tareas
Responsable
Figura 3.10: (Diagrama Proceso De Integración)
-74-
Actividades / Tareas
Responsable
Figura 3.11: (Diagrama Proceso De Pruebas)
-75-
El análisis comparativo tiene como finalidad el visualizar, las similitudes y
diferencias que existen entre la norma ISO/IEC 12207 y el proceso que se lleva
actualmente en la UTIC, mediante la elaboración de una tabla comparativa que
evidencie la estructura y metodología planteada por cada uno.
En la Tabla 3.5 se hace una comparación entre los procesos que se
realizan en la UTIC e ISO/IEC 12207 y la metodología implementada en cada
caso, para poder determinar las facilidades y dificultades que presenta el método
actual de la UTIC, para implementar el propuesto por ISO/IEC 12207.
.
-76-
ANÁLISIS
REQUERIMIENTOS
PROCESOS
Determinación de
Especificaciones
Técnicas del Aplicativo.
Análisis infraestructura
de telecomunicaciones
GT3 (ADMINISTRACIÓN
DE REDES Y
•
•
TELECOMUNICACIONES).
Realizar levantamiento
de información y
requerimientos de
usuario.
•
-77-
•
Especificaciones Técnicas
(archivo digital): a)
Desarrollo Implantación y
Mantenimiento de
Aplicativos.
•
•
Requerimiento de
aplicativos: a) Desarrollo
Implantación y
Mantenimiento de
Aplicativos.
Documentos Resultantes
Interfaces Externas.
Especificaciones
Funcionales y de
Capacidad.
Identificación de
requerimientos por parte
de los interesados.
Procedimientos
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documentos de Especificación de
Requerimientos del software.
Documentos Resultantes
PROCESO DE ANÁLISIS DE REQUERIMIENTOS DESOFTWARE
ANÁLISIS Y DISEÑO PARA EL DESARROLLO DE
APLICATIVOS
Procedimientos
NORMA ISO/IEC 12207
UTIC ESPE
Tabla 3.5: (Cuadro Comparativo Desarrollo de Software UTIC-ESPE vs Estándar de Aplicación Norma ISO/IEC 12207)
PROCESOS
Análisis Diseño de
Modelos.
Análisis Diseño de
Interfaces.
Análisis Diseño de
Componentes.
•
•
•
UTIC ESPE
-78-
Especiaciones de de
seguridad de acceso.
Definición de datos y
requerimientos de bases
de datos.
Requerimientos de
instalación y aceptación
del producto software.
Documentación usuario.
Evaluación de
Requerimientos de
software.
•
•
•
•
•
Requerimientos de
seguridad física.
Requerimientos de
seguridad .
Requerimientos de
Validación.
•
•
•
Documento de Evaluación de
Requerimientos de software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
Documento Análisis de
Requerimientos de Software.
NORMA ISO/IEC 12207
DISEÑO DE
SOFTWARE
PROCESOS
Diseñar Modelos y o
actualizar.
Diseño de interfaces de
la aplicación.
Diseño de
componentes de la
aplicación.
•
•
•
-79-
Modelos: a) Desarrollo
Implantación y
Mantenimientos de
Aplicativos.
Documentos Resultantes
Desarrollo y Diseño de
Alto Nivel BBDD.
Actualización
Documentación usuario si
existen cambios.
Definición Requerimientos
Preliminares de Prueba.
Planificación para la
Integración de Software.
•
•
•
Desarrollo Interfaces
Externas de alto nivel.
Desarrollo Estructura Alto
Nivel.
•
•
•
Procedimientos
Documento de Plan de Integración
de Software.
Documento de Plan de Integración
de Software.
Documento Diseño de Alto Nivel de
Software.
Documento Diseño de Alto Nivel de
Software.
Documento Diseño de Alto Nivel de
Software.
Documentos Resultantes
PROCESO DE DISEÑO DE ARQUITECTURA DE SOFTWARE
ANÁLISIS Y DISEÑO PARA EL DESARROLLO DE
APLICATIVOS
Procedimientos
NORMA ISO/IEC 12207
UTIC ESPE
PROCESOS
UTIC ESPE
-80-
Documento de Evaluación de
Arquitectura de software.
Diseño Refinado de
Componente.
Diseño Detallado de
interfaces externas.
Desarrollo Detallado de
DDBB.
Definición de
Requerimientos de
Prueba, planificación de
las pruebas de unidades.
Actualizar
Requerimientos de
Prueba y plan de
Aplicación.
•
•
•
•
Documento de Plan de Integración de
Software.
Documento de Plan de Pruebas de
Unidades.
Documento Diseño Detallado de Alto
Nivel de Software.
Documento Diseño Detallado de Alto
Nivel de Software.
Documento Diseño Detallado de
Software.
PROCESO DE DISEÑO DETALLADO DE ARQUITECTURA DE
SOFTWARE
Evaluación arquitectura de
elemento software,
diseño de interfaz y DDBB.
•
•
NORMA ISO/IEC 12207
CONSTRUCCIÓN DE
SOFTWARE
PROCESOS
Analizar el Diseño del
Aplicativo.
Construir o modificar la
base de datos si
requiere.
Construir o modificar
las interfaces de
aplicativos si requiere.
Construir o modificar
componentes si
requiere.
Generar versión del
Aplicativo.
•
•
•
•
•
Procedimientos
-81-
Bitácora del aplicativo: a)
Desarrollo Implantación y
Mantenimiento de
Documentos Resultantes
CONSTRUCCIÓN DE APLICATIVOS
UTIC ESPE
•
•
•
•
•
•
Documento de Evaluación Diseño
Detallado De Software.
Actualizar
requerimientos de
prueba y plan de
Actualizar
Documentación de
usuario si es necesario.
Probar Unidades de
Software y DDBB.
Plan de pruebas de
Unidad y DDBB.
Desarrollo de Unidades
de Software y de la
DDBB.
Procedimientos
Documento de Plan de Integración de
Software.
Documento de Pruebas de Unidad de
Software y DDBB.
Documento Plan de Pruebas de
Software.
Documentos Resultantes
PROCESO DE CONSTRUCCIÓN DE SOFTWARE
Evaluación Diseño
Detallado de Software.
NORMA ISO/IEC 12207
PROCESOS
Probar Versión del
Aplicativo .
Almacenar Versión el
Archivos de Versiones
del Aplicativo
(respaldos).
•
•
-82-
Bitácora del aplicativo: a)
Desarrollo Implantación y
Mantenimiento de
Aplicativos.
Aplicativos
UTIC ESPE
Documento de Evaluación de
Construcción de Software.
Desarrollo del Plan de
Integración.
Integración de Unidades
de Software y
Componentes del
Software.
Actualización
Documentación de
Usuario.
•
•
Procedimientos
Documento Plan de Integración.
Documento Plan de Integración.
Documentos Resultantes
PROCESO DE INTEGRACIÓN DE SOFTWARE
Evaluación Código
Fuente y Resultado de
las Pruebas.
•
•
integración.
NORMA ISO/IEC 12207
IMPLEMENTACIÓN
DEL SOFTWARE
PROCESOS
Instalar y o Configurar
la Versión del
Aplicativo.
Configuración de BBDD
si requiere.
Realizar pruebas
Finales de la Versión .
Autorizar liberación.
•
•
•
Receptar la Versión del
Aplicativo.
•
•
Procedimientos
-83-
Bitácora del aplicativo: a)
Desarrollo Implantación y
Documentos Resultantes
IMPLANTACIÓN DE APLICATIVOS
UTIC ESPE
•
•
•
•
•
Evaluación del Plan de
Integración de Software.
•
Documento Pruebas de Integración.
Documento Plan de Pruebas de
Software.
Liberación Producto
Preparar Producto
Software Entregable.
Brindar Soporte
Auditoría de ser
requerida.
Actualizar
Documentación Usuario.
Pruebas de Validación
Elemento Software.
Procedimientos
Documento Manual de Usuario.
Documento Plan de Pruebas de
Software.
Documentos Resultantes
PROCESO DE PRUEBAS DEL SOFTWARE
Prepara Requerimientos
de Validación del
Elemento Software.
•
NORMA ISO/IEC 12207
PROCESOS
Liberar y Notificar la
liberación de la versión.
Capacitación del
aplicativo a GT5.
•
•
-84-
Manual del aplicativo: a)
Desarrollo Implantación y
Mantenimiento de
Aplicativos.
Mantenimiento de
Aplicativos.
UTIC ESPE
Software Entregable.
NORMA ISO/IEC 12207
La UTIC de la ESPE, manejan tres grandes procesos para el desarrollo de
software: Análisis y Diseño para el Desarrollo de Aplicativos, Construcción de
Aplicativos, e Implantación de Aplicativos, que abarcan desde el levantamiento de
requerimientos hasta la liberación del software; el plan de aplicación basado en la
norma ISO/IEC 12207, maneja seis procesos para el desarrollo de software:
Análisis de Requerimientos de Software, Diseño de Arquitectura de Software,
Diseño Detallado de Arquitectura de Software, Construcción de Software,
Integración del Software, y Pruebas de Software, que a su vez se complementan
con cuatro procesos de apoyo: Documentación, Gestión de la Configuración,
Resolución de Problemas, Revisión Conjunta, que complementan las tareas
realizadas por los procesos principales, dando como resultados información de
mayor calidad y de mejor entendimiento.
El cuadro comparativo Tabla 3.5, muestra la manera óptima de acoplar el
estándar de aplicación basado en ISO/IEC 12207, en la estructura actual que
maneja la UTIC de la ESPE.
En base al análisis realizado a la UTIC de la ESPE y a la norma ISO/IEC
12207, se ha obtenido los procesos que se implementaron en el Estándar de
Aplicación de Desarrollo de Software, como sugerencia de mejora del proceso,
para beneficio de la unidad.
-85-
CAPÍTULO IV
4. ESTÁNDAR DE APLICACIÓN BASADO EN LA NORMA ISO/IEC
12207, AL PROCESO DE DESARROLLO DE SOFTWARE EN LA
UTIC DE LA ESPE
El presente estándar de aplicación, está dirigido al personal encargado del
desarrollo de aplicaciones de software en la ESPE, el cual se encuentra en la
Unidad de Tecnologías de Información y Comunicaciones de la Institución (UTIC
ESPE).
La norma ISO/IEC 12207:2008, de la cual este estándar de aplicación esta
basado, consta de una lista de términos y definiciones, que proporcionan un
lenguaje unificado entre todos los involucrados en el proceso de desarrollo de
software. Maneja una estructura definida por procesos principales y de apoyo,
cada uno de ellos posee actividades y tareas a seguir para cumplir con el objetivo
de cada proceso.
-86-
4.1.- Términos y Definiciones
Los términos y definiciones descritos a continuación, se utilizarán en todos
los procesos, actividades y tareas que describe ISO/IEC 12207 para el desarrollo
de aplicaciones de software.
Actividad conjunto de tareas de cohesión de un proceso.
Acuerdo reconocimiento mutuo de los términos y condiciones en que se
llevó a cabo una relación de trabajo.
Adquirente interesado que obtiene o adquiere un sistema, producto o
servicio software de un proveedor.
NOTA: el adquiriente podría ser uno de los siguientes: el comprador,
cliente, propietario, adjudicatario.
Adquisición el proceso de obtención de un sistema, producto de software
o servicio de software.
Aseguramiento de la Calidad todas las actividades planificadas y
sistemáticas implementadas dentro del sistema de calidad, y demostradas de ser
necesario, proporcionan la confianza de que una entidad va a cumplir con los
requisitos de calidad.
-87-
NOTA 1 hay propósitos para el aseguramiento de la calidad tanto
internos como externos:
a) Garantía de la calidad interna: dentro de una organización, el
aseguramiento de la calidad proporciona confianza para la
gestión.
b) Garantía de calidad externa: en las situaciones contractuales,
la garantía de calidad proporciona confianza a los clientes u
otros.
NOTA 2: algunos de controles de calidad y acciones de
aseguramiento de calidad están relacionados.
NOTA 3: a menos que los requisitos de calidad reflejen plenamente
las necesidades del usuario, el aseguramiento de la calidad no
proveerá la confianza adecuada.
Auditoría evaluación independiente de productos de software y procesos
realizados por una persona autorizada con el fin de evaluar el cumplimiento de los
requisitos.
Calificación proceso para demostrar si una entidad es capaz de cumplir
con los requisitos especificados.
Capacidad de Prueba medida en que una prueba objetiva y viable puede
ser diseñada para determinar si se cumple un requisito.
-88-
Ciclo de Vida evolución de un sistema, producto, servicio, proyecto u otra
entidad realizada por un humano, desde la concepción hasta su retiro.
Cliente organización o persona que recibe un producto o servicio.
NOTA 1 un cliente puede ser interno o externo a la organización.
NOTA 2 adaptado de la norma ISO 9000: 2005.
NOTA 3 otros términos comúnmente utilizados para el cliente es
adquiriente, comprador, y el adjudicatario.
Cobertura de las Pruebas grado al cual los casos de prueba, prueban los
requisitos para el producto de software o el sistema.
Contrato un acuerdo vinculante entre dos partes, en especial aplicable por
ley, o de un acuerdo interno similar total dentro de una organización.
Declaración de Trabajo documento utilizado por el adquirente como medio
para describir y especificar las tareas que deben realizarse en el marco del
contrato.
-89-
Desarrollador organización que realiza tareas de desarrollo (incluyendo el
análisis de requerimientos, diseño, prueba a través de aceptación) durante un
proceso de ciclo de vida.
NOTA en esta norma internacional, el desarrollador y ejecutor de los
términos son sinónimos.
Ejecutor organización que realiza las tareas de implementación.
NOTA: en esta norma internacional, el desarrollador y ejecutor de los
términos son sinónimos.
Elemento de Configuración entidad dentro de una configuración que
satisface una función de uso final y que pueden ser identificados de forma única a
un determinado punto de referencia.
Elemento de Software código fuente, código objeto, código de control,
datos de control, o una colección de los anteriores.
NOTA un elemento de software puede ser visto como un elemento
del sistema de la norma ISO/IEC 15288:2008.
Elemento del Sistema miembro de un conjunto de elementos que
constituye un sistema.
-90-
NOTA un elemento del sistema es una parte discreta de un sistema
que puede ser implementado para satisfacer los requisitos
especificados. Un elemento del sistema puede ser de hardware,
software, datos, los humanos, los procesos (por ejemplo, los
procesos de prestar servicio a los usuarios), procedimientos (por
ejemplo, las instrucciones del operador), instalaciones, materiales, y
entidades de origen natural (por ejemplo, el agua, los organismos,
minerales), o cualquier combinación.
Elemento no Entregable producto de hardware o software que no está
obligado a ser entregado en virtud del contrato, pero puede ser empleado en el
desarrollo de un producto de software.
Etapa el período de ciclo de vida de una entidad que se relaciona con el
estado de su descripción o realización.
NOTA 1 a los efectos de esta norma internacional, las etapas se
relacionan con avances importantes y principales objetivos de la
entidad a través de su ciclo de vida.
NOTA 2 las etapas pueden superponerse.
Evaluación determinación sistemática de la medida en que una entidad
cumpla con los criterios especificados.
-91-
Firmware la combinación de un dispositivo de hardware e instrucciones de
ordenador o los datos de ordenador que residen como el software sólo para leer
sobre el dispositivo de hardware.
NOTA el software no puede ser fácilmente modificado bajo el
programa de control.
Infraestructura medios físicos o equipos para facilitar la ejecución de una
acción, por ejemplo, los edificios, instrumentos, herramientas.
Interesado individuo u organización que tenga derecho, participación,
demanda o interés en un sistema o en su posesión de las características que
satisfagan sus necesidades y expectativas.
Lanzamiento versión particular de un elemento de configuración que está
disponible para un fin específico (por ejemplo, la prueba liberación).
Línea Base especificación o producto que ha sido formalmente revisado y
acordado, que posteriormente sirve como base para un mayor desarrollo, y que
sólo se puede modificar a través de procedimientos formales de control de
cambio.
Modelo de Ciclo de Vida marco de los procesos y actividades
relacionadas con el ciclo de vida que pueden ser organizados en etapas, que
-92-
también actúa como una referencia común para la comunicación y la
comprensión.
Monitoreo seguimiento de la situación del estado de las actividades de un
proveedor y de sus resultados por el adquiriente o de un tercero.
Operador entidad que realiza la operación de un sistema.
NOTA 1 el papel de operador y el papel de usuario pueden ser
establecidos, de forma simultánea o secuencial, en el mismo
individuo u organización.
NOTA 2 en el contexto de esta definición en específico, el término
entidad significa un individuo o una organización.
Organización persona o grupo de personas e instalaciones con una
disposición de responsabilidades, autoridades y relaciones.
NOTA 1 adaptado de la norma ISO 9000:2005.
NOTA 2 un grupo de personas organizadas para un fin específico,
como
un
club,
sindicato,
corporación
o
sociedad
es
una
organización.
NOTA 3 una identificada parte de una organización (incluso tan
pequeños como una sola persona) o de un grupo identificado de las
organizaciones pueden ser consideradas como una organización si
tiene responsabilidades, autoridades y relaciones.
-93-
NOTA 4 una forma de una entidad de organización a menudo se
llama una empresa, de modo que los aspectos organizativos de esta
norma internacional se aplican a una empresa también.
Partes son las organizaciones que entran en un contrato o acuerdo.
NOTA en esta norma internacional, las partes de acuerdo son
llamadas el adquirente y el proveedor.
Portafolio de Proyectos conjunto de proyectos que aborden los objetivos
estratégicos de la organización.
Proceso conjunto de actividades interrelacionadas o que interactúan, que
transforma los insumos en productos [ISO 9000:2005].
Producto resultado de un proceso, de [ISO 9000:2005].
Producto
de
Software
conjunto
de
programas
de
computación,
procedimientos y, posiblemente, la documentación y los datos.
Producto Pre elaborado <off the shelf> ya desarrollado y disponible.
-94-
Propósito del Proceso objetivo de alto nivel de la implementación del
proceso y los resultados.
NOTA la aplicación del proceso debe proporcionar beneficios
tangibles a las partes interesadas.
Proveedor organización o individuo que llega a un acuerdo con el
comprador para el suministro de un producto o servicio.
NOTA 1 el "proveedor" podría ser un contratista, productor,
vendedor o proveedor.
NOTA 2 a veces el adquirente y el proveedor son parte de la misma
organización.
Proyecto
esfuerzo con fechas de inicio y finalización definidas,
comprometiéndose a entregar el producto o servicio de acuerdo a lo especificado
tanto en recursos y en requisitos.
NOTA 1 adaptado de la norma ISO 9000:2005.
NOTA 2: un proyecto puede ser visto como un proceso exclusivo
que constará de actividades coordinadas y controladas y puede ser
integrado de las actividades de los procesos de proyectos y
procesos técnicos definidos en esta norma internacional.
-95-
Pruebas de Calificación pruebas, realizadas por el desarrollador y testigo
del adquirente (según corresponda), para demostrar que un producto de software
satisface sus especificaciones y está listo para su uso en su entorno de destino o
la integración en su sistema que lo contiene.
Recurso activo que es utilizado o consumido durante la ejecución de un
proceso.
Requisito de Calificación conjunto de criterios o condiciones que deben
cumplirse para poder optar a un producto de software que cumplen con sus
especificaciones y está listo para su uso en su entorno de destino o la integración
con su sistema que lo contiene.
Resultado del Proceso resultado observable al alcanzar el propósito de
un proceso.
NOTA un resultado se describe como lo siguiente:
o Producción de un artefacto.
o Un cambio significativo en el estado.
o Reunión de las limitaciones.
o Acuerdo en las limitaciones especificadas, por ejemplo, los
requisitos, objetivos, etc.
-96-
Retiro el retiro del soporte activo por parte de la organización de
mantenimiento y operación, parcial o total remplazo por un nuevo sistema, o
instalación de un sistema actualizado.
Seguridad protección de la información y de los datos de tal manera que
personas y sistemas no autorizados no puedan leerlos ni modificarlos y personas
o sistemas autorizados no tengan negado el acceso.
Servicio ejecución de las actividades, el trabajo, o de los derechos
asociados con un producto.
Sistema combinación de elementos organizados que interactúan para
lograr uno o más fines establecidos.
NOTA 1 un sistema puede ser considerado como un producto, o
como los servicios que presta.
NOTA 2 en la práctica, la interpretación de su significado suele ser
aclarado por el uso de un nombre de asociación, por ejemplo,
sistemas de aeronaves.
Sistema Habilitante sistema que soporta un sistema de interés durante
sus primeras etapas del ciclo de vida, pero no necesariamente contribuye en
forma directa a su función durante la operación.
-97-
NOTA 1: por ejemplo, cuando un sistema de interés entra en la fase
de producción, un sistema de producción habilitante es necesario.
NOTA 2: cada sistema habilitante tiene un ciclo de vida propio.
Esta norma internacional es aplicable a cada sistema habilitante cuando,
por derecho propio, es tratada como un sistema de interés.
Tarea requisito, recomendación o acción autorizada, destinada a contribuir
a la consecución de uno o más resultados del proceso.
Unidad de Software separadamente un pedazo de código compilable.
Usuario individuo o grupo que se beneficia de un sistema durante su
utilización.
NOTA la función de usuario y el papel de operador pueden ser
desarrollados, de forma simultánea o secuencial, en el mismo
individuo u organización.
Validación la confirmación, a través de la provisión de pruebas objetivas,
que las exigencias para un uso específico o aplicación han sido realizadas.
NOTA la validación en el contexto de ciclo de vida es el conjunto de
actividades que aseguran y ganan la confianza que un sistema es
capaz de acoplarse a su uso previsto, metas y objetivos.
-98-
Verificación la confirmación, mediante la aportación de pruebas objetivas,
que los requisitos especificados se han cumplido ISO 9000:2005.
NOTA verificación en un contexto de ciclo de vida es un conjunto de
actividades que compara un producto del ciclo de vida en contra de
las características exigidas para ese producto. Esto puede incluir,
pero no limita, requisitos especificados, descripción del diseño y el
propio sistema.
Versión instancias identificadas de un elemento.
NOTA la modificación de una versión de un producto de software,
dando como resultado una nueva versión, requiere la acción de la
administración de configuración.
-99-
4.2.- Procesos Específicos del Software
4.2.1.- Proceso de Implementación del Software
4.2.1.1.- Propósito
El propósito del proceso de Implementación de Software, es producir un
elemento específico del sistema, implementado como un producto o servicio de
software, que se encuentra conformado por los siguientes procesos de nivel
inferior:
•
Proceso de Análisis de Requerimientos del Software.
•
Proceso de Diseño de Arquitectura del Software.
•
Proceso de Diseño Detallado del Software.
•
Proceso de Construcción del Software.
•
Proceso de Integración del Software.
•
Proceso de Pruebas del Software.
Estos a su vez se complementan con los procesos de apoyo descritos a
continuación:
•
Proceso de Gestión de Documentación del Software.
•
Proceso de Gestión de la Configuración del Software.
•
Proceso de Resolución de Problemas del Software.
•
Proceso de Revisión Conjunta del Software.
•
Proceso de Validación del Software.
-100-
4.2.1.2.- Actividades y Tareas
4.2.1.2.1.- Implementación del Software
•
Si no está estipulado en el contrato o acuerdo, el desarrollador deberá
definir o seleccionar un modelo de ciclo de vida apropiado para el
ámbito, magnitud y complejidad del proyecto. El modelo de ciclo de
vida debe estar compuesto de etapas, propósito y resultados para
cada una de estas etapas.
•
El desarrollador deberá:
Documentar las salidas que genere el proceso, según el Proceso
de Gestión de la Documentación del Software 4.3.1.
Poner las salidas en base al Proceso de Gestión de la
Configuración del Software 4.3.2.
Documentar y solucionar los problemas y no conformidades
encontradas en los productos software y tareas, de acuerdo con el
Proceso de Resolución de Problemas del Software 4.3.3.
Establecer una línea base para cada elemento de configuración
con los elementos apropiados, como los determinados por el
adquiriente y el proveedor.
•
El desarrollador deberá seleccionar, adaptar y usar aquellas normas,
métodos, herramientas y lenguajes de programación (si no están
-101-
estipulados en el contrato o acuerdo) que estén documentados, sean
pertinentes y estén establecidos por la organización para llevar a cabo
las actividades del proceso de desarrollo.
•
El desarrollador deberá preparar planes para realizar las actividades
del proceso de desarrollo. Los planes deberían incluir normas
específicas, métodos, herramientas, acciones y responsabilidades
asociadas con el desarrollo y calificación de todos los requerimientos.
Si fuese necesario, se pueden preparar planes separados. Se
deberán documentar y ejecutar estos planes.
•
Para el desarrollo y mantenimiento del producto software, se pueden
emplear elementos no entregables. Sin embargo, se deberá asegurar
que la operación y mantenimiento del producto software entregable,
luego de entregado al adquiriente, sea independiente de dichos
elementos, de otra manera se deberán considerar como entregables.
4.2.2.- Proceso de Análisis de Requerimientos del Software
4.2.2.1.- Propósito
El propósito del Proceso de Análisis de Requerimientos del Software, es el
de establecer los requisitos de un aplicativo de software que se va a desarrollar.
-102-
4.2.2.2.- Actividades y Tareas
4.2.2.2.1.- Análisis de Requerimientos del Software
Para cada elemento de software (o para cada elemento de configuración de
software), esta actividad consta del análisis de las siguientes tareas:
•
El desarrollador deberá realizar el levantamiento de requerimientos.
•
El desarrollador deberá establecer y documentar los requerimientos
de software (incluyendo las especificaciones de las características de
calidad).
•
Especificaciones funcionales y de capacidad, incluyendo rendimiento,
características físicas y condiciones del entorno en donde el elemento
software ha de funcionar.
•
Interfaces externas al elemento software.
•
Especificaciones
de
seguridad
física,
incluyendo
aquellas
relacionadas con los métodos de operación y mantenimiento,
influencias del entorno y daño a las personas.
•
Especificaciones de seguridad de acceso, incluyendo aquellas que
comprometen información confidencial.
-103-
•
Definición de datos y requerimientos de las bases de datos.
•
Requerimientos de instalación y aceptación del producto software
entregado, en el lugar o lugares de operación y mantenimiento.
•
Requerimientos de documentación de usuario.
•
Requerimientos de operación y ejecución por parte del usuario.
•
Requerimientos de mantenimiento por parte del usuario.
•
El desarrollador deberá evaluar y documentar los requerimientos de
software teniendo en cuenta los criterios que se enumera a
continuación:
Trazabilidad de los requerimientos del sistema y el diseño del
sistema.
Consistencia externa con los requerimientos del sistema.
Consistencia interna.
Capacidad de ser probado.
Viabilidad del diseño software.
Viabilidad de la operación y mantenimiento.
El desarrollador deberá llevar a cabo revisiones conjuntas de
acuerdo con el Proceso de Revisión Conjunta del Software
4.3.4.
-104-
4.2.3.- Proceso de Diseño de Arquitectura del Software
4.2.3.1.- Propósito
El propósito del Proceso de Diseño de Arquitectura del Software, es proveer
un diseño para el software que se implemente y pueda ser verificado en base a
los requerimientos.
4.2.3.2.- Actividades y Tareas
4.2.3.2.1.- Diseño de Arquitectura del Software
Para cada elemento software (o para cada elemento de configuración de
software, si se ha identificado) esta actividad consta de las siguientes tareas:
•
El desarrollador deberá transformar los requerimientos para el
elemento software, en una arquitectura que describa su estructura a
un alto nivel y que identifique los componentes del software. Debe
asegurarse de que todos los requerimientos para el elemento
software, se asignen a sus componentes de software. Se deberá
documentar la arquitectura del elemento software.
•
El desarrollador deberá desarrollar y documentar un diseño a alto
nivel para las interfaces externas al elemento software, y para las
interfaces entre los componentes software del elemento software.
-105-
•
El desarrollador deberá desarrollar y documentar un diseño de alto
nivel para la base de datos.
•
Conviene que el desarrollador documente y desarrolle versiones
preliminares de la documentación de usuario.
•
El desarrollador deberá definir y documentar los requerimientos
preliminares de pruebas y la planificación para la integración del
software.
•
El desarrollador deberá evaluar la arquitectura del elemento software
y de los diseños de su interfaz y base de datos, teniendo en cuenta
los criterios enumerados a continuación. Se deberán documentar los
resultados de las evaluaciones.
Seguimiento hacia los requerimientos del elemento software.
Consistencia externa con los requerimientos del elemento
software.
Consistencia interna entre los componentes software.
Adecuación de los métodos de diseño y normas usadas.
Viabilidad del diseño detallado.
Viabilidad de la operación y mantenimiento.
•
El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo
con el Proceso de Revisión Conjunta del Software 4.3.4.
-106-
4.2.4.- Proceso de Diseño Detallado del Software
4.2.4.1.- Propósito
El propósito de este proceso, es proveer un diseño para el software que
implemente y que pueda ser verificado en base a los requerimientos, y que la
arquitectura del software sea lo suficientemente detallada para permitir su
codificación y prueba.
4.2.4.2.- Actividades y Tareas
4.2.4.2.1.- Diseño Detallado del Software
Para cada elemento software (o para cada elemento de configuración
software, si se ha identificado), esta actividad consta de las siguientes tareas:
•
El desarrollador deberá preparar un diseño detallado para cada
componente de software del elemento software. Se deberá refinar los
componentes de software hasta los niveles más bajos, que contienen
las unidades software que pueden ser codificadas, compiladas y
probadas. Se deberá asegurar que todos los requerimientos del
software están asignados desde los componentes software hacia las
unidades software. Se deberá documentar el diseño detallado.
-107-
•
El desarrollador deberá preparar y documentar un diseño detallado de
las interfaces externas al elemento software, y entre los componentes
software y las unidades software. El diseño detallado de las interfaces
deberá permitir la codificación sin necesidad de más información.
•
El desarrollador deberá preparar y documentar el diseño detallado
para la base de datos.
•
El desarrollador deberá actualizar la documentación de usuario si es
necesario.
•
El desarrollador deberá definir y documentar los requerimientos de
prueba y planificar la prueba de las unidades. Se deberían incluir en
los requerimientos de prueba, situaciones que fuercen a las unidades
software hasta los límites de los requerimientos del software.
•
El desarrollador deberá actualizar los requerimientos de prueba y el
plan para la integración del software.
•
El desarrollador deberá evaluar el diseño detallado del software y los
requerimientos
de
prueba,
teniendo
en
cuenta
los
criterios
enumerados a continuación. Se deberán documentar los resultados
de la evaluación.
-108-
Seguimiento hacia los requerimientos del elemento software.
Consistencia externa con el diseño de la arquitectura.
Consistencia interna entre los componentes de software y las
unidades de software.
Adecuación de los métodos de diseño y normas usadas.
Viabilidad de las pruebas.
Viabilidad de la operación y mantenimiento.
El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo con el
Proceso de Revisión Conjunta del Software 4.3.4.
4.2.5.- Proceso de Construcción del Software
4.2.5.1.- Propósito
El propósito del Proceso de Construcción del Software, es el de desarrollar
unidades de software ejecutables que reflejen adecuadamente el diseño de
software.
-109-
4.2.5.2.- Actividades y Tareas
4.2.5.2.1.- Construcción del Software
•
El desarrollador deberá documentar y desarrollar las siguientes
tareas:
Cada unidad software y base de datos.
Procedimientos de prueba y datos para probar cada unidad
de software y la base de datos.
•
El desarrollador deberá probar cada unidad de software y base de
datos asegurando que satisfacen sus requerimientos. Se deberán
documentar los resultados de las pruebas.
•
El desarrollador deberá actualizar la documentación de usuario, si es
necesario.
•
El desarrollador deberá actualizar los requerimientos de prueba y el
plan, para la integración del software.
•
El desarrollador deberá evaluar el código software y los resultados de
las pruebas teniendo en cuenta los criterios enumerados a
continuación. Se deberán documentar los resultados de las
evaluaciones.
-110-
Seguimiento hacia los requerimientos y el diseño del
elemento software.
Consistencia externa con los requerimientos y el diseño del
elemento software.
Consistencia interna entre los requerimientos de las unidades.
Cobertura de pruebas de las unidades.
Adecuación de los métodos de codificación y normas usadas.
Viabilidad de la integración del software y de las pruebas.
Viabilidad de la operación y mantenimiento.
4.2.6.- Proceso de Integración del Software
4.2.6.1.- Propósito
El propósito del Proceso de Integración, es el de combinar unidades y
componentes de software, produciendo elementos de software integrados,
consistentes al diseño del software, que demuestre que los requerimientos
funcionales y no funcionales del software, sean satisfechos en una plataforma
operacional.
-111-
4.2.6.2.- Actividades y Tareas
4.2.6.2.1.- Integración del Software
Para cada elemento de software (o para cada elemento de configuración de
software, si se ha identificado), esta actividad consta de las siguientes tareas:
•
El desarrollador deberá preparar un plan de integración, para integrar
las unidades y los componentes de software en el elemento software.
El plan deberá incluir requerimientos de prueba, procedimientos,
datos, responsabilidades y plazos. Se deberá documentar el plan.
•
El desarrollador deberá integrar las unidades y los componentes de
software y probarlos a medida que se agrupan de acuerdo con el plan
de integración. Se deberá asegurar que cada agrupación satisface los
requerimientos del elemento software, y que el elemento software
está integrado al final de la actividad de integración. Se deberá
documentar los resultados de la integración y de las pruebas.
•
El desarrollador deberá actualizar la documentación de usuario, si es
necesario.
•
El
desarrollador
deberá
preparar
y
documentar,
para
cada
requerimiento de validación del elemento software, un conjunto de
pruebas, casos de prueba (entradas, salidas, criterios de prueba) y
-112-
procedimientos de prueba, para llevar a cabo las pruebas de
validación del software. El desarrollador deberá asegurar que el
elemento software integrado, está listo para las pruebas de validación
del software.
•
El desarrollador deberá evaluar el plan de integración, el diseño, el
código, las pruebas, y los resultados de las pruebas, teniendo en
cuenta los criterios enumerados a continuación. Se deberán
documentar los resultados de las evaluaciones.
Seguimiento hacia los requerimientos del sistema.
Consistencia externa con los requerimientos del sistema.
Consistencia interna.
Cobertura de las pruebas de los requerimientos del elemento
software.
Adecuación de las normas de prueba y de los métodos
usados.
Conformidad con los resultados esperados.
Viabilidad de las pruebas de validación del software.
Viabilidad de la operación y mantenimiento.
El desarrollador debería llevar a cabo revisiones conjuntas de acuerdo con el
Proceso de Revisión Conjunta del Software 4.3.4.
-113-
4.2.7.- Proceso de Pruebas del Software
4.2.7.1.- Propósito
El propósito del Proceso de Pruebas del Software, es el de confirmar que el
producto de software integrado cumple con los requerimientos definidos.
4.2.7.2.- Actividades y Tareas
4.2.7.2.1.- Pruebas del Software
Para cada elemento software (o para cada elemento de configuración del
software, si se ha identificado), esta actividad consta de las siguientes tareas:
•
El desarrollador deberá llevar a cabo pruebas de validación, de
acuerdo con los requerimientos de validación para el elemento
software. Se deberá asegurar que se prueba la conformidad de la
implementación de cada requerimiento de software. Se deberán
documentar los resultados de las pruebas de validación.
•
El desarrollador deberá actualizar la documentación de usuario, si es
necesario.
•
El desarrollador deberá evaluar el diseño, el código, las pruebas, los
resultados de las pruebas y la documentación de usuario teniendo en
-114-
cuenta los criterios enumerados a continuación. Se deberán
documentar los resultados de las evaluaciones.
Cobertura de las pruebas de los requerimientos del elemento
software.
Conformidad con los resultados esperados.
Viabilidad de la integración del sistema y las pruebas, si se
llevan a cabo.
Viabilidad de la operación y mantenimiento.
•
El desarrollador deberá proporcionar soporte a las auditorías, de
acuerdo con el proceso de auditoría que la organización lleve
internamente. Se deberán documentar los resultados de las
auditorías.
•
Tras la finalización exitosa de las auditorías, si se llevan a cabo, el
desarrollador deberá actualizar y preparar el producto software
entregable para la integración del sistema, pruebas de validación del
sistema, instalación del software o apoyo a la aceptación del software,
como proceda.
NOTA: El plan de pruebas del software, se pueden usar en el
Proceso de Validación del Software 4.3.6.
-115-
4.3.- Procesos de Apoyo
4.3.1.- Proceso de Gestión de la Documentación del Software
4.3.1.1.- Propósito
El propósito del Proceso de Gestión de la Documentación del Software, es el
de registrar la documentación producida por un proceso o actividad del ciclo de
vida. El proceso contiene un conjunto de actividades para: planificar, diseñar,
desarrollar, producir, editar, distribuir y mantener aquellos documentos que
necesitan todos los involucrados tales como: gerentes, ingenieros y usuarios del
sistema o producto software.
4.3.1.2.- Actividades y Tareas
Este proceso consta de las siguientes actividades:
4.3.1.2.1.- Implementación del Proceso
•
Se deberá preparar, documentar e implementar, un plan que
identifique los documentos que se van a producir. Para cada
documento identificado, se deberá considerar lo siguiente:
Título o nombre.
Propósito.
-116-
Audiencia a la que se dirige.
Procedimientos y responsabilidades para las entradas,
desarrollo, revisión, modificación, aprobación, producción,
almacenamiento, distribución, mantenimiento y gestión de la
configuración.
Plazos para las versiones intermedias y final.
4.3.1.2.2.- Diseño y Desarrollo
•
Cada documento identificado se deberá diseñar de acuerdo con las
normas de documentación aplicables para el formato, descripción del
contenido, numeración de páginas, situación de las figuras y tablas,
marcas de propiedad y seguridad, empaquetado y otros elementos de
presentación.
•
Se deberá confirmar la fuente y adecuación de los datos de entrada
para los documentos. Se pueden usar herramientas automáticas de
documentación.
•
Se deberán revisar y corregir los documentos preparados de acuerdo
con el formato, contenido técnico y estilo de presentación frente a sus
normas de documentación. Personal autorizado deberá aprobar su
adecuación antes de que sean hechos públicos.
-117-
4.3.1.2.3.- Producción
•
Los documentos se deberán producir y poner a disponibilidad de
acuerdo con el plan. La producción y distribución de los documentos
puede hacerse usando papel, medios electrónicos u otros medios. Se
deberán almacenar los originales de acuerdo con los requerimientos
de conservación de registros, seguridad de acceso, mantenimiento y
copias de seguridad.
•
Se deberán establecer controles de acuerdo con el Proceso de
Gestión de la Configuración del Software 4.3.2.
4.3.1.2.4.- Mantenimiento
•
Se deberán llevar a cabo las tareas que se requieran cuando se
realice
la
modificación
de
la
documentación.
Para
aquellos
documentos que están bajo la gestión de la configuración, las
modificaciones se deberán administrar de acuerdo con el Proceso de
Gestión de la Configuración del Software 4.3.2.
-118-
4.3.2.- Proceso de Gestión de la Configuración del Software
4.3.2.1.- Propósito
El propósito del Proceso de Gestión de la Configuración consiste en
procedimientos técnicos y administrativos a lo largo del ciclo de vida del software
para: identificar, definir y establecer la línea base de los elementos software en un
sistema; controlar modificaciones y releases 13 de los elementos; registrar e
informar del estado de los elementos y peticiones de modificación; asegurar la
completitud, consistencia y corrección de los elementos; y controlar el
almacenamiento, manipulación y entrega de los elementos.
4.3.2.2.- Actividades y Tareas
Este proceso consta de las siguientes actividades:
4.3.2.2.1.- Implementación del Proceso
•
Se deberá preparar un Plan de Gestión de la Configuración. El plan
deberá describir: las actividades de gestión de la configuración;
procedimientos y plazos para llevar a cabo dichas actividades; la
organización u organizaciones responsables de llevar a cabo dichas
actividades; sus relaciones con otras organizaciones, tales como las
13
Release: Es una versión de lanzamiento, es decir, que el software se hace público.
-119-
de desarrollo o mantenimiento del software. Se deberá documentar e
implementar en el plan.
4.3.2.2.2.- Identificación de la Configuración
•
Se deberá establecer un esquema para la identificación de los
elementos software (y sus versiones) que van a ser controlados por el
proyecto. Se deberá identificar para cada elemento software y sus
versiones: la documentación que establece la línea de referencia, las
referencias a las versiones y otros detalles de identificación.
4.3.2.2.3.- Control de la Configuración
•
Se deberá llevar a cabo lo siguiente: identificación y registro de las
peticiones de cambio, análisis y evaluación de los cambios,
aprobación o rechazo de la petición, e implementación, verificación y
release del elemento software modificado. Deberá existir un rastro
auditable mediante el cual se pueda rastrear cada modificación, las
razones para la modificación y la autorización de la modificación. Se
deberá controlar y auditar todos los accesos a los elementos software
controlado que manejen funciones críticas para la seguridad tanto
física como de acceso.
-120-
4.3.2.2.4.- Determinación del Estado de la Configuración
•
Se debe implementar un esquema para la identificación de los
elementos de software y sus versiones que van a ser controladas a lo
largo del proyecto. Para cada elemento de software y sus versiones,
se debe identificar lo siguiente: La documentación que establece su
línea base, la referencia a versiones, y otros detalles de identificación.
4.3.2.2.5.- Evaluación de la Configuración
•
Se deberá determinar y asegurar lo siguiente: completitud funcional
de los elementos software frente a sus requerimientos y completitud
física de los elementos software (si su diseño y código reflejan una
descripción técnica actualizada).
4.3.2.2.6.- Gestión de Releases y Entrega
•
El release y entrega de los productos software y de la documentación
se deberá controlar formalmente. Se deberán guardar copias
maestras del código y la documentación durante toda la vida del
producto software. El código y la documentación que contengan
funciones críticas de seguridad física o de acceso, se deberá
manipular, almacenar, empaquetar y entregar de acuerdo con las
políticas de las organizaciones involucradas.
-121-
4.3.3.- Proceso de Resolución de Problemas del Software
4.3.3.1.- Propósito
El propósito del Proceso de Resolución de Problemas del Software es
analizar y resolver problemas (incluidas las no conformidades), cualquiera que
sea su naturaleza u origen, que se descubran durante la ejecución de los
procesos de desarrollo, mantenimiento u otros.
4.3.3.2.- Actividades y Tareas
Este proceso consta de las siguientes actividades:
4.3.3.2.1.- Implementación del Proceso
•
Se deberá establecer un Proceso de Resolución de Problemas del
Software para manejar todos los problemas (incluyendo las no
conformidades) detectados en los productos y actividades de
software. El proceso deberá cumplir los siguientes requerimientos:
•
El proceso deberá ser un bucle cerrado, asegurando que: se informa
rápidamente de todos los problemas detectados y se introducen en el
proceso de solución de problemas; se inician acciones sobre ellos; se
informa a las partes implicadas según sea necesario acerca de la
existencia de los problemas; las causas se identifican, analizan y,
-122-
donde sea posible, se eliminan; se consigue una solución y la
eliminación; se hace un seguimiento y se informa del estado; se
mantienen registros de los problemas tal como se estipule en el
contrato o acuerdo.
•
El proceso deberá contener un esquema para categorizar y priorizar
los problemas. Conviene que cada problema se clasifique por
categoría y prioridad para facilitar el análisis de tendencias y la
solución del problema.
•
Se deberán llevar a cabo análisis para detectar tendencias; en los
problemas informados.
•
Se deberán evaluar las soluciones y las disposiciones para evaluar
que los problemas han sido resueltos, las tendencias adversas han
sido invertidas y los cambios han sido implementados correctamente
en los productos y actividades de software apropiados; y determinar si
se han introducido problemas adicionales.
4.3.3.2.2.- Solución de Problemas
•
Cuando se han detectado problemas (incluyendo no conformidades)
en un producto o actividad software, se deberá preparar para cada
problema detectado un informe describiendo el problema. El informe
del problema se deberá usar como parte del proceso en bucle cerrado
-123-
descrito anteriormente: desde la detección del problema, pasando por
la investigación, análisis y solución del problema y su causa, hasta la
detección de tendencias en los problemas.
4.3.4.- Proceso de Revisión Conjunta del Software
4.3.4.1.- Propósito
El propósito del Proceso de Revisión Conjunta es evaluar el estado y los
productos de una actividad de un proyecto, según sea adecuado. Las revisiones
conjuntas están a nivel tanto de gestión del proyecto como técnico y se mantienen
a lo largo de la vida del contrato. Este proceso puede ser empleado por cualquiera
de las dos partes, donde una de ellas (la revisora) revisa a la otra parte (la
revisada).
4.3.4.2.- Actividades y Tareas
Lista de actividades. Este proceso consta de las siguientes actividades:
4.3.4.2.1.- Implementación del Proceso
•
Se
deberán
llevar
a
cabo
revisiones
periódicas
en
hitos
predeterminados tal como se especifica en los planes del proyecto.
Se pueden llevar a cabo revisiones para un fin especifico cuando se
considere necesario por cualquiera de las partes.
-124-
•
Las partes deberán acordar todos los recursos necesarios para llevar
a cabo las revisiones. Estos recursos incluyen personal, ubicación,
instalaciones, hardware, software y herramientas.
•
Las partes deberán acordar para cada revisión los siguientes
elementos: agenda de la reunión, productos software (y resultados de
una actividad) y problemas a revisar; alcance y procedimientos y
criterios de entrada y salida para la revisión.
•
Se deberán registrar los problemas detectados durante las revisiones
y pasarlos al Proceso de Resolución de Problemas del Software 4.3.4,
según se requiera.
•
Se deberá documentar y distribuir los resultados de las revisiones. La
parte revisora informará a la parte revisada sobre la adecuación (por
ejemplo, aprobación, no-aprobación o aprobación condicionada) de
los resultados de la revisión.
•
Las partes deberán ponerse de acuerdo sobre los resultados de la
revisión y en la responsabilidad sobre cualquier punto de acción y sus
criterios de finalización.
-125-
4.3.4.2.2.- Revisiones de la Gestión del Proyecto
•
Se deberá evaluar el estado del proyecto con relación a los planes,
plazos, normas y guías del proyecto aplicables.
•
El resultado de la revisión deberá discutirse entre las dos partes y
deberá conseguir lo siguiente:
Hacer que las actividades progresen de acuerdo con el plan,
basándose en una evaluación del estado de la actividad o
producto software.
Mantenimiento del control global del proyecto a través de la
adecuada asignación de recursos.
Cambio de la gestión del proyecto o determinación de la
necesidad de una planificación alternativa.
Evaluación y gestión de los elementos de riesgo que puedan
amenazar el éxito del proyecto.
4.3.4.2.3.- Revisiones Técnicas
•
Se deberán mantener revisiones técnicas para evaluar los productos
o servicios y proporcionar evidencia de que:
Son completos.
Cumplen con sus normas y especificaciones.
-126-
Los cambios se implementan adecuadamente y afectan sólo a
aquellas áreas identificadas por el proceso de gestión de la
configuración.
Se están adhiriendo a los plazos aplicables.
Están listos para la siguiente actividad.
El desarrollo, operación o mantenimiento se lleva a cabo de
acuerdo con los planes, plazos, normas y guías del proyecto.
4.3.5.- Proceso de Validación del Software
4.3.5.1.- Propósito
El propósito del Proceso de Validación es determinar si los requerimientos y
el sistema o producto software, tal como se ha construido, cumplen con su uso
específico previsto.
Este proceso se puede ejecutar con diversos grados de independencia. El
grado de independencia puede variar desde la misma persona o diferentes
personas dentro de la misma organización, hasta una persona de una distinta
organización con un grado de separación variable. En el caso en que el proceso
se ejecute por una organización independiente del proveedor, desarrollador,
operador o responsable de mantenimiento, se llama proceso de validación
independiente.
-127-
4.3.5.2.- Actividades y Tareas
Este proceso consta de las siguientes actividades:
4.3.5.2.1.- Implementación del Proceso
•
Se deberá determinar si el proyecto merece un esfuerzo de
validación, y el grado de independencia organizativa necesaria para
dicho esfuerzo.
•
Si el proyecto merece un esfuerzo independiente, se deberá
seleccionar una organización calificada responsable de llevar a cabo
este esfuerzo. Se deberá garantizar a esta organización la
independencia y autoridad para llevar a cabo las actividades de
validación, caso contrario la validación se hará mediante un proceso
interno.
•
Se deberá preparar y documentar un plan de validación. El plan
deberá incluir (sin estar limitado a ello) lo siguiente:
Elementos sujetos a validación.
Tareas de validación a llevar a cabo.
Recursos, responsabilidades y plazos para la validación.
Procedimientos para hacer llegar los informes de validación al
adquiriente y a otras partes.
-128-
•
Se deberá implementar el plan de validación. Los problemas y las no
conformidades detectadas por el esfuerzo de validación, se deberán
pasar al Proceso de Solución de Problemas. Se deberán resolver
todos los problemas y no conformidades. Se deberá poner a
disposición del adquiriente y otras organizaciones involucradas los
resultados de las actividades de validación.
4.3.5.2.2.- Validación
•
Preparar los requerimientos de prueba, casos de prueba y
especificaciones de prueba seleccionados para analizar los resultados
de las pruebas.
•
Asegurar que estos requerimientos de prueba, casos de prueba y
especificaciones de prueba reflejan los requerimientos particulares
para el uso específico previsto.
•
Llevar a cabo las pruebas de los 2 literales anteriores, incluyendo:
Pruebas con sobrecarga, límites y entradas excepcionales.
Pruebas del producto software respecto a su habilidad para
aislar y minimizar el efecto de errores; esto es, degradación
elegante por fallos, petición de asistencia del operador ante
sobrecargas y situaciones límite y excepcionales.
-129-
Pruebas de usuarios representativos que pueden llevar a
cabo con éxito sus tareas previstas usando el producto
software.
•
Validar que el producto software satisface su uso previsto.
•
Probar el producto software, cuando sea apropiado, en áreas
seleccionadas del entorno de destino.
-130-
CAPÍTULO V
5. CONCLUSIONES Y RECOMENDACIONES
5.1.- Conclusiones
•
Se realizó un análisis previo de la estructura de las UTIC de la ESPE, para
determinar qué área o áreas de la unidad, están encargadas del desarrollo
de software, y qué método utilizan para hacerlo, además de comprender el
aporte del resto de áreas para la consecución de proyectos de desarrollo
de software.
•
No se puede implementar de una sola vez, todos los procesos que
contempla la norma ISO/IEC 12207 en la UTIC de la ESPE, se debe
generar un plan de aplicación que contemple procesos de la norma,
destinados a un área específica de la unidad, los cuales sirvan de base
para posteriormente implementar el resto de procesos, una vez que la
UTIC adquiera experiencia en el manejo de la norma, con el estándar
implementado.
•
El estándar de aplicación propuesto, proporciona a la UTIC de la ESPE, la
generación de documentación sobre todo el transcurso de desarrollo de
software, y maneja un lenguaje unificado sobre dicha documentación, para
-131-
facilitar el entendimiento de la misma, entre todos los involucrados de
unidad y externos a ella, en el desarrollo de un proyecto de software.
•
La implementación del estándar propuesto no genera muchos conflictos
para adaptarlo dentro de la UTIC de la ESPE, debido a que el estándar
está orientado en base al proceso actual, para que el impacto del cambio
no sea tan drástico.
•
Para el éxito de la implementación del estándar, es necesario realizarlo lo
más conciso y claro posible, para facilitar al personal de la UTIC su
entendimiento y fácil aplicación en proyectos de desarrollo, tomando como
base las necesidades de la unidad.
•
ISO/IEC 12207 aporta en un futuro a la UTIC, procesos de implementación
para el suministro, operación, mantenimiento y la eliminación de los
productos software, tomando como base para su implementación el
estándar de aplicación, motivo de la presente tesis.
5.2.- Recomendaciones
•
Se recomienda al DCC a futuro, la inclusión de temas de certificaciones
ISO a procesos relacionados a Desarrollo de Software dentro de la malla
curricular.
•
Se recomienda la certificación de estándares de calidad, para mejorar los
procesos dentro de la UTIC, aumentar la confianza que la ESPE deposita
-132-
en la unidad, generar competitividad, entre otros beneficios que aportan las
certificaciones.
•
Se recomienda considerar el uso de otros estándares, propuestos por
ISO/IEC 12207 tales como ISO/IEC 15288 e ISO 9001, que complementan
su implementación y aporte en la calidad del producto software.
•
Para empezar un proyecto de software, es recomendable al personal de
desarrollo de la UTIC, elegir un modelo de ciclo de vida adecuado, basado
en un análisis previo, dependiendo del tipo de desarrollo que se vaya a
realizar.
•
Se recomienda al personal de desarrollo de la unidad e involucrados en el
desarrollo de software, la utilización del Resumen del Estándar de
Aplicación, como manual de bolsillo, para guiarse en el proceso de
desarrollo propuesto por ISO/IEC 12207, además de la utilización de las
plantillas propuestas en los anexos adjuntos a la tesis.
-133-
ANEXOS
ANEXO A: RESUMEN DEL ESTÁNDAR DE APLICACIÓN
BASADO EN LA NORMA ISO/IEC 12207
El Anexo A, es un instructivo que resume todo el Estándar de Aplicación basado
en la Norma ISO/IEC 12207, para la UTIC de la ESPE; todos los procesos
contemplados en este resumen, se profundizan en el Capítulo IV de esta tesis; se
sugiere el uso de las plantillas anexas que se listan a continuación, estas sirven
de apoyo para ejecutar los procesos y registrar los resultados generados por
estos.
ANEXO B: PLAN DE GESTIÓN DE LA DOCUMENTACIÓN.
ANEXO C: PLAN DE GESTIÓN DE LA CONFIGURACIÓN.
ANEXO D: ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE (ERS).
ANEXO E: DISEÑO DE ARQUITECTURA DE ALTO NIVEL Y DETALLADO.
ANEXO F: PLAN DE PRUEBAS.
A.1.- Procesos Específicos del Software
A.1.1.- Proceso de Implementación del Software
A.1.1.1.- Implementación del Software
Si no está estipulado en el contrato o acuerdo, el desarrollador deberá definir o
seleccionar un modelo de ciclo de vida apropiado para la magnitud y complejidad
del proyecto, este proceso trabaja con procesos de nivel inferior y de apoyo para
el desarrollo de software.
A.1.2.- Proceso de Análisis de Requerimientos del Software
A.1.2.1.- Análisis de Requerimientos del Software
Se sugiere uso: ANEXO D.
Tareas:
•
•
Levantar requerimientos.
Establecer y documentar requerimientos para:
o Especificaciones funcionales y de capacidad.
-134-
•
o Interfaces externas al elemento software.
o Especificaciones de seguridad física.
o Especificaciones de seguridad de acceso.
o Definición de datos y requerimientos de las bases de datos.
o Instalación y aceptación del producto software.
o Documentación de usuario.
o Operación y ejecución por parte del usuario.
o Mantenimiento por parte del usuario.
Evaluar los requerimientos de software.
A.1.3.- Proceso de Diseño de Arquitectura del Software
A.1.3.1.- Diseño de Arquitectura del Software
Se sugiere uso: ANEXO E.
Tareas:
•
•
Desarrollar y documentar:
o Transformar los requerimientos, en una arquitectura que describa su
estructura a un alto nivel e identifique los componentes del software.
o Diseño interfaces.
o Diseño base de datos.
o Versiones preliminares documentación de usuario (de ser
necesario).
o Definir requerimientos preliminares de prueba y la planificación para
la integración del software Se sugiere uso: ANEXO F.
Evaluar la arquitectura del elemento software y de sus interfaces.
A.1.4.- Proceso de Diseño Detallado del Software
A.1.4.1.- Diseño Detallado del Software
Se sugiere uso: ANEXO E.
Tareas:
•
•
•
•
•
Desarrollar y documentar diseño detallado para:
o Cada componente del elemento software.
o Interfaces.
o Base de datos.
Actualizar documentación de usuario (de ser necesario).
Definir requerimientos de prueba y planificar pruebas unitarias Se sugiere
uso: ANEXO F.
Actualizar los requerimientos de prueba y el plan para la integración del
software. Se sugiere uso: ANEXO F.
Evaluar diseño detallado del software.
-135-
A.1.5.- Proceso de Construcción del Software
A.1.5.1.- Construcción del Software
Tareas:
•
•
•
•
•
Desarrollar y documentar:
o Cada unidad software y base de datos.
o Procedimientos de prueba unitarias Se sugiere uso: ANEXO F.
Ejecución de pruebas unitarias al software y base de datos Se sugiere uso:
ANEXO F.
Actualizar documentación de usuario (si es necesario).
Actualizar requerimientos de prueba de integración Se sugiere uso: ANEXO F.
Evaluar código software y resultados de las pruebas.
A.1.6.- Proceso de Integración del Software
A.1.6.1.- Integración del Software
Se sugiere uso: ANEXO F.
Tareas:
•
•
•
•
•
Preparar Plan de Integración.
Ejecutar las pruebas de integración.
Actualizar documentación de usuario (si es necesario).
Preparar pruebas de validación del software.
Evaluar plan de integración, diseño, código, pruebas y resultados de las
pruebas.
A.1.7.- Proceso de Pruebas del Software
A.1.7.1.- Pruebas del Software
Se sugiere uso: ANEXO F.
Tareas:
•
•
•
•
Llevar a cabo pruebas de validación.
Actualizar la documentación de usuario (si es necesario).
Evaluar el diseño, el código, las pruebas, los resultados de las pruebas y la
documentación.
Proporcionar soporte a las auditorias (si se realizan).
A.2.- Procesos de Apoyo
A.2.1.- Proceso de Gestión de la Documentación del Software
A.2.1.1.- Implementación del Proceso
-136-
•
Elaborar Plan de Documentación Se sugiere uso: ANEXO B.
A.2.1.2.- Diseño y Desarrollo
•
•
•
Los documentos se deben diseñar de acuerdo a las normas aplicables de
documentación.
Confirmar fuente y adecuación de los datos.
Revisar y corregir documentos preparados de acuerdo al formato.
A.2.1.3.- Producción
•
Los documentos se deberán producir y poner a disponibilidad de acuerdo
al plan.
A.2.1.4.- Mantenimiento
•
Llevar a cabo las tareas de modificación requeridas en base al Proceso de
Gestión de la Configuración del Software A.2.2.
A.2.2.- Proceso de Gestión de la Configuración del Software
Se sugiere uso: ANEXO C.
A.2.2.1.- Implementación del Proceso
•
Preparar Plan de Gestión de la Configuración.
A.2.2.2.- Identificación de la Configuración
•
Establecer esquema para la identificación de los elementos.
A.2.2.3.- Control de la Configuración
•
Implementar esquema para la identificación de requerimientos de software.
A.2.2.4.- Evaluación de la Configuración
•
Evaluar elementos de software y sus requerimientos.
A.2.2.5.- Gestión de Releases y Entrega
•
•
Guardar copias de seguridad.
Controlar formalmente releases y entrega de los productos software,
además de la documentación.
A.2.3.- Proceso de Resolución de Problemas del Software
A.2.3.1.- Implementación del Proceso
•
Establecer un proceso de resolución de problemas.
-137-
•
•
•
•
Establecer un bucle cerrado, donde se resuelvan los problemas.
Establecer esquema para categorizar y priorizar las pruebas.
Analizar las tendencias en los problemas informados.
Evaluar las soluciones a los problemas.
A.2.3.2.- Solución de Problemas
•
Prepara informes de problemas detectados, debe formar parte del bucle
cerrado.
A.2.4.- Proceso de Revisión Conjunta del Software
A.2.4.1.- Implementación del Proceso
•
•
•
•
Llevar a cabo revisiones periódicas y cuando se considere necesario.
Acordar: agenda de la reunión.
Registrar los problemas detectados durante las revisiones y pasarlos al
Proceso de Resolución de Problemas del Software A.2.3.
Documentar y distribuir los resultados de las revisiones.
Las partes deberán ponerse de acuerdo sobre los resultados de la revisión
y en la responsabilidad sobre cualquier punto de acción y sus criterios de
finalización.
A.2.4.2.- Revisiones de la Gestión del Proyecto
•
•
Se deberá evaluar el estado del proyecto con relación a los planes, plazos,
normas y guías del proyecto aplicables.
El resultado de la revisión deberá discutirse entre las dos partes.
A.2.4.3.- Revisiones Técnicas
•
Se deberán mantener revisiones técnicas para evaluar los productos o
servicios software.
A.2.5.- Proceso de Validación del Software
A.2.5.1.- Implementación del proceso
•
•
•
Determinar si el proyecto merece un esfuerzo de validación.
Si el proyecto merece un esfuerzo independiente, se deberá seleccionar
una organización calificada responsable.
Preparar y documentar un plan de validación. Se sugiere uso: ANEXO F.
A.2.5.2.- Validación
•
•
Definir las pruebas de validación. Se sugiere uso: ANEXO F.
Implementar el plan de validación. Se sugiere uso: ANEXO F.
-138-
ANEXO B: PLAN DE GESTIÓN DE LA DOCUMENTACIÓN
NOMBRE
FECHA
MOTIVO DE CAMBIO
VERSIÓN
[Nombre del Producto Software]
[Fecha de
Cambio]
[Descripción Motivo del Cambio]
[Versión del
Producto
Software]
1.- Introducción
1.1.- Propósito
Proporcionar una guía de documentación de un proyecto de software, cumpliendo los términos que
propone ISO/IEC 12207:2008.
1.2.- Uso Correcto
Está diseñado para ayudar a personas con limitaciones de conocimiento de los requisitos de
documentación y métodos para implementar el plan de documentación, el proceso que se ofrece puede ser
aplicado utilizando medios electrónicos.
Esta plantilla puede ser fácilmente modificada dependiendo del proyecto.
Este modelo supone que el usuario tiene un formato estándar para los documentos, por ejemplo, cubiertas,
tabla de contenidos, encabezados, pies de página, el estilo y el formato (por ejemplo, tipo de letra,
márgenes, justificación y espaciado.
1.3.- Ámbito
[Identificar la política, objetivos, fines, supuestos, limitaciones, riesgos y dependencias; y una visión general
de este plan.]
[Identificar a los usuarios de este plan, el alcance y las limitaciones de la gestión de la documentación, y
debe contener una descripción clara y concisa de la metodología de la gestión de la documentación. Es de
suma importancia para los lectores de este plan para comprender claramente la terminología y
metodología utilizada.]
Este plan debe encajar, en cualquier otro plan.
2.- Documentación Visión General
Para cada documento identificado, se deberá considerar en lo posible lo siguiente, dentro de cada
documento:
-139-
Documentos
Título o Nombre
[Establecer el nombre del documento]
Propósito
[Establecer el propósito del Documento]
Audiencia a la que se dirige
[Establecer a quien va dirigido el presente documento]
Procedimientos y Responsabilidades
[Para las entradas, desarrollo, revisión, modificación, aprobación, producción, almacenamiento,
distribución, mantenimiento y gestión de la configuración]
Responsables
[Establecer las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante
las fases del proyecto, de acuerdo con los roles y responsabilidades se establece los niveles de jerarquía que
dictan aprobaciones en cambios, etc.]
3.- Consideraciones Adicionales
•
•
•
Cada documento identificado se deberá diseñar de acuerdo con las normas de documentación
aplicables para el formato, descripción del contenido, numeración de páginas, situación de las
figuras y tablas, marcas de propiedad y seguridad, empaquetado y otros elementos de
presentación.
Se deberá confirmar la fuente y adecuación de los datos de entrada para los documentos. Se
pueden usar herramientas automáticas de documentación.
Se deberán revisar y corregir los documentos preparados de acuerdo con el formato, contenido
técnico y estilo de presentación frente a sus normas de documentación. Personal autorizado
deberá aprobar su adecuación antes de que sean hechos públicos.
-140-
ANEXO C: PLAN DE GESTIÓN DE LA CONFIGURACIÓN
NOMBRE
FECHA
MOTIVO DE CAMBIO
VERSIÓN
[Nombre del Producto Software]
[Fecha de
Cambio]
[Descripción Motivo del Cambio]
[Versión del
Producto
Software]
1.- Introducción
1.1.- Propósito
El propósito de este documento es establecer los elementos necesarios para administrar los documentos y
las fuentes que son elaborados por el equipo del proyecto.
1.2.- Uso Correcto
El uso de este documento facilita la administración de configuración y documenta los cambios que se
puedan presentar en un proyecto.
1.3.- Ámbito
El ámbito de este documento es el proyecto [Nombre de Proyecto] de [Nombre de Cliente] y establece un
plan para administrar los productos de trabajo del proyecto, incluyendo tanto los entregables de software
como la documentación del proyecto.
1.4.- Definiciones Acrónimos y Abreviaturas
[Definir todos los términos, acrónimos, y abreviaciones requeridas para interpretar correctamente este
Plan de Administración de Configuración. Esta información puede entregarse como una referencia al
Glosario del proyecto.]
1.5.- Referencias
[Proveer una lista completa de todos los documentos a los que se haga una referencia en cualquier parte
de este Plan de Administración de Configuración. Identificar cada documento por título, edición (si es
aplicable, fecha y editorial. Especificar las fuentes de donde se pueden obtener estas referencias. Esta
información puede ser entregada como una referencia a un apéndice o a otro documento.]
1.6.- Resumen Ejecutivo
[Describir el resto del contenido del Plan de Administración de Configuración, además explicar cómo está
organizado este documento.]
2.- Administración de la Configuración
2.1.- Organización, Responsables e Interfaces
[Describir quien será responsable de llevar a cabo las diferentes actividades de Administración de
Configuración (Configuration Management, CM). Se puede hacer referencia a un documento de Asignación
de Roles, para determinar roles responsables para CM. Interfaces: se necesita describir en qué manera se
va comunicar con otros grupos y afectados. Por ejemplo: reuniones semanal, e-mail, video conferencias...]
-141-
2.2.- Herramientas, Entorno e Infraestructura
[Describir el entorno computacional y las herramientas software que serán utilizadas para cumplir las
funciones de administración de la configuración a través del proyecto o del ciclo de vida del producto.
Describir las herramientas y procedimientos requeridos para ser utilizados en los ítems de configuración de
control de versión generados a través del proyecto o del ciclo de vida del producto.
Los elementos involucrados en fijar el entorno de administración de configuración incluyen:
•
•
•
Tamaño anticipado de la data del producto (aprox.).
Distribución del equipo del producto - se puede mostrar usando modelo de despliegue.
Ubicación física de las maquinas servidores y clientes - se puede mostrar usando modelo de
despliegue.]
2.2.1.- Herramientas
Actividad
Herramienta
[Nombre de la actividad que se va cubrir usando
herramienta. Por ejemplo: Administración de
Requerimientos]
[Nombre de la herramienta que se va usar para la
actividad.
Por
ejemplo:
para actividad
Administración de Requerimientos, herramienta
puede ser: MS Excel, MS Office, Requisite Pro,
DOORS... Se puede agregar y dirección donde se
puede encontrar de la instalación de la
herramienta.]
[…………………………]
[…………………………]
2.2.2.- Ubicación Física de las Máquinas, Servidores y Clientes
IP
Nombre
Responsable
[Por ejemplo: 1P:192.168.0.33]
[Por ejemplo SCM SERVER]
[Nombre de administrador de la
maquina o nombre de usuario si
maquina es estación del trabajo]
[…………………………]
[…………………………]
[…………………………]
2.2.3.- Ubicación Física de los Documentos y Líneas Base
Dirección
Tipo de Documento
[La dirección donde se va guardar las líneas base. Se
recomienda usar nombres relativos \\<nombre de
servidor>\<direccion> Por ejemplo: para línea base de
requerimientos: \\CM SERVER\Reqs\]
[…………………………]
[Nombre del tipo de documento que se va guardar
dentro de la línea base. Por ejemplo: para la
Administración de Requerimientos, puede ser:
.DOC, .TXT y como base de datos PROYECT1.mdf ]
[…………………………]
3.- Programa de Administración de la Configuración
3.1.- Identificación de la Configuración
3.1.1.- Métodos de Identificación
[Describir cómo serán nombrados, marcados y numerados los artefactos del proyecto o del producto. El
esquema de identificación necesita cubrir el hardware, software de sistema, productos comerciales, y
todos los artefactos desarrollados para la aplicación, listados en la estructura de directorios del producto;
por ejemplo, planes, modelos, componentes, software de testing, resultados y data, ejecutables, etc.]
-142-
3.1.2.- Línea Base del Proyecto
Las línea base proveen un estándar oficial en el cual se basarán los trabajos subsecuentes y a los cuales
solo se le pueden aplicar cambios autorizados.
[Describir en qué puntos durante el proyecto o el ciclo de vida del producto se han establecido línea base.]
La mayoría de las línea base comunes deberían estar al final de cada fase de Concepción, Elaboración,
Construcción, y Transición. Las línea base también pueden ser generadas al final de las iteraciones con las
diferentes fases o incluso más frecuentemente.
[Describir quién autoriza una línea base.]
Se puede hacer referencia a el documento "Política, estándar y procedimiento de CM" general, si proyecto
no tiene algunas cosas especificas y si este documento existe dentro de la organización.
3.2.- Configuración y Control de Cambios
3.2.1.- Comité de Control de Cambios CCC
[Describir los miembros y procedimientos para el proceso de petición de cambios y aprobaciones que deben
ser seguidos por el CCC. Se puede hacer referencia a el documento "Política, estándar y procedimiento de
CM" general, si el proyecto no tiene algunas cosas especificas y si este documento existe dentro de la
organización.]
3.2.2.- Proceso de Petición de Cambios y Aprobación
[Describir los procesos por los cuales los problemas y cambios se han enviado, revisado y dispuesto.]
[Diligenciar la Solicitud de Cambio]
SOLICITUD DE CAMBIO
ID Solicitud
[Número de la Solicitud de Cambio]
Fecha
[Fecha de Diligenciamiento de la Solicitud]
Datos Solicitante
Solicitante
Teléfono(s)/Extensión(s)
/Correo Electrónico
[Persona que inicia la inquietud de la solicitud]
[Datos de la Persona que genera la solicitud]
Identificación
Aplicación
Línea Base Aplicativo
Descripción del Cambio
Solicitad
[Componente de software sobre el cual recae la solicitud]
[Escribir el número de la versión del aplicativo para el cual se solicita el
cambio]
[Describir el cambio que se desea, lo más detallada y claramente posible]
Clasificación
Prioridad De acuerdo con la solicitud, se prioriza la solicitud de cambio de acuerdo con la siguiente tabla.
Tipo
[Descripción]
Crítico
[Interrumpe el funcionamiento del aplicativo]
[Comportamiento diferente a las especificaciones funcionales y/o
degradación del desempeño del sistema]
[Mejoras de forma o adición de funcionalidad a considerar para próximas
versiones del software]
Importante
Deseable
Tipo Se hace una primera clasificación de la solicitud de cambio de acuerdo con el tipo de cambio en la
siguiente tabla.
Tipo
[Descripción]
Adición
[Incorporación nueva funcionalidad al sistema]
Mejora
[Modificación para aumentar el rendimiento técnico del sistema]
Defecto
[Defectos encontrados en la aplicación]
-143-
Evaluación
Responsable
Planeación
Fecha de Asignación
[Nombre de la persona a quien se le asigna la evaluación funcional de la
solicitud]
[Fecha en que se hace la asignación de la evaluación]
Seguimiento
Observaciones
Adicionales
Estado de la Solicitud
[Cualquier otra información que podría ayudar a aclarar la solicitud. La
solicitud será actualizada sobre el mismo formato al recibir información
adicional o al ocurrir un cambio de estado. Por ejemplo el por qué es
importante realizar el cambio, objetivos, ventajas, relación con normas y/o
documentación que sustente el cambio ó el motivo por el cual se rechaza la
solicitud dado que este sea el caso]
[corresponde a los posibles estados en los que se encuentra la solicitud,
estos pueden ser:
•
•
•
•
•
En planeación
Aprobada
Abierta
Cerrada
Rechazada]
3.2.3.- Planeación Implementación del Cambio
Una vez que ha sido asignado un responsable a la solicitud de cambio, este debe diligenciar un formato con
el plan de ejecución del cambio.
Plan Implementación del Cambio
Responsable
[persona quien realiza la planeación del cambio]
Línea Base de Partida
[línea base de la aplicación sobre la cual se solicita el cambio]
Línea Base de Liberar
[línea base de la aplicación que se creará al ejecutar el cambio]
Planeación
Elemento de
Configuración para
Modificar
Responsable
[Se listan los elementos de configuración que se tienen que modificar para
efectuar el cambio; por cada uno de ellos se anota:]
[Responsable de petición de cambio]
Nro. Horas Estimadas
[Hora estimada para realizar el cambio]
Nro. Horas Reales
[Hora que dura el cambio]
Requerimientos
[Lista de requerimientos que se verán afectados por el cambio.]
Justificación
Descripción de la
Actividad
[Se describe cómo se efectuó el proceso de evaluación, las consideraciones
tenidas en cuenta.]
Recomendación
[Dependiendo si el cambio es conveniente o no, se señala en el formato
(como resumen del la planeación)]
Aprobación
Aprobación/Rechazo
por
[Firma de la gerencia del comité de control de cambios.]
Fecha de Decisión
[Fecha en la cual se reúne el comité de control de cambios para aprobar o
rechazar la solicitud.]
3.2.4.- Implementar el Cambio
[Ejecutar y proceder a efectuar la entrega del cambio]
-144-
3.2.5.- Entrega Cambios
[Entregar el cambio efectuado, las pruebas desarrolladas, y la actualización del formulario de
requerimientos]
[Realizar una inspección por parte de un miembro del proyecto asociada con las siguientes actividades:
•
•
•
Revisar documento de requerimientos de la solicitud que se cumpla completamente.
Efectuar pruebas de usuario.
Correr pruebas automáticas.
Si no se cumplieran se devuelve la solicitud]
3.2.6.- Integración de Cambios
• [El administrador de la configuración debe integrar los cambios, generando una nueva versión, los
desarrolladores y usuarios deben verificar la correcta implementación de los cambios, si existieran
errores se devuelve la solicitud]
3.2.7.- Auditoría de las Configuraciones
[Se lleva a cabo por el administrador de la configuración y comprende las siguientes verificaciones:
• Todos los elementos de configuración requeridos se han cumplido.
• Las versiones actuales están acordes a los requisitos especificados.
• La documentación técnica esta completa y describe adecuadamente los elementos de
configuración.
• Todas las solicitudes de cambio han sido resueltas]
3.2.8.- Informe de Estado
Muestra el estado en la que se encuentra una solicitud de cambio.
Informe de Estado
Número de Solicitud
[Identificador de la Solicitud de Cambio]
Resumen de la Solicitud
[Breve descripción de la Solicitud]
Prioridad
[Prioridad dada por el Comité de Control de Cambios]
Estado
[Debe iniciar en qué estado se encuentra la solicitud]
Fecha
[Fecha en la cual se asigna es estado de la solicitud]
Responsable
[Corresponde a la persona encargada de implementar el cambio]
3.3.- Almacenamiento de la información del Proyecto
[Administrar el depósito de las líneas de base del producto, proveer la manipulación del producto
(recuperación y almacenamiento) y los controles necesarios para asegurar que se preserve la integridad del
mismo.]
3.4.- Administración de Versiones
[Toda la información del proyecto es almacenada en un repositorio que puede estar ubicado en la
institución y ser administrado mediante una herramienta de administración de repositorios.] Ubicación
física del repositorio 2.3.
3.4.1.- Generación de Versiones
Una vez se han determinado los cambios que se liberan en una versión, se procede a generarla, para lo
cual se deben cumplir las siguientes características:
Duplicar la base de datos de producción para correr las pruebas sobre estos datos.
Ejecutar todo el set de pruebas de usuario.
3.4.2.- Reportes e Intervenciones
[Describir el contenido, formato, y propósito de los reportes requeridos e intervenciones requeridas.
Los reporte son usados para evaluar la “calidad del producto” en cualquier momento dado del proyecto o
del ciclo de vida de producto. El reporte de los defectos basados en las peticiones de cambios puede
proveer indicadores de calidad muy útiles y, de este modo, alertar a administradores y desarrolladores
acerca de áreas particulares críticas de desarrollo. Los defectos son clasificados según su importancia (alto,
medio, y bajo) y deben ser reportados según la siguiente base:
-145-
•
•
•
Antigüedad (Reportes basados en el tiempo): ¿Hace cuanto se han establecido estos defectos?
¿Cuál es el” tiempo de retraso” desde que los defectos fueron encontrados hasta que fueron
reparados?
Distribución (Reportes basados en números): ¿Cuantos defectos existen en cada categoría,
ordenados por autor, prioridad, y estado de reparación?
Tendencias (Reportes basados en Tiempo y Número): ¿Cuál es el número de defectos
acumulativos encontrados y cuales se han solucionado después del tiempo? ¿Cuál es el ratio de
defectos descubiertos y reparados? ¿Cuál es el “Boquete de Calidad” en términos de defectos
reportados y reparados? ¿Cuál es el tiempo de resolución promedio de un defecto?
Para los reportes si no se usa alguna herramienta tales como ClearQuest, BugTracker, BugZila, o similar se
puede usar MS Excel.]
-146-
ANEXO D: ESPECIFICACIÓN DE REQUERIMIENTOS DE
SOFTWARE (ERS)
NOMBRE
FECHA
MOTIVO DE CAMBIO
VERSIÓN
[Nombre del Producto Software]
[Fecha de
Cambio]
[Descripción Motivo del Cambio]
[Versión del
Producto
Software]
1.- Introducción
1.1.- Propósito
[Identificar el producto cuyos requerimientos de software se detallan en este documento, incluyendo la
revisión o el número de versión. Describe el alcance del producto que está regulado por la presente
especificación de requerimientos]
1.2.- Uso Correcto
[El uso de este documento, describe y analiza en su totalidad los requerimientos de manera organizada que
el usuario solicite del proyecto de desarrollo.]
1.3.- Documentos en Convenio
[Describir todas las normas o los convenios con documentos que se siguieron al escribir esta ERS, como
fuentes o destacando que tienen un significado especial. Por ejemplo, deberá indicarse si las prioridades
para los requisitos de nivel superior se supone que son heredadas por los requisitos detallados, o si cada
requisito debe tener su propia prioridad.]
1.4.- Audiencia Deseada y Sugerencias de Lectura
[Describir los diferentes tipos de lectores al que el documento está destinado, como desarrolladores,
administradores de proyectos, personal de marketing, los usuarios, evaluadores, y escritores de
documentación. Describe lo que el resto del presente ERS contiene y cómo se organiza. Sugiere una
secuencia para la lectura del documento, comenzando por las secciones de información general y
procediendo a través las secciones que son más pertinentes para cada tipo de lector]
1.5.- Ámbito del Proyecto
[Proporcionar una breve descripción del software que se especifica y su finalidad, incluyendo beneficios
pertinentes, objetivos y metas. Relaciona el software a los objetivos institucionales o estrategias de
negocios]
1.6.- Referencias
[Mencionar cualquier otro documento o direcciones web a la que se refiere el presente ERS. Estos pueden
incluir guías de estilo de interfaz de usuario, los contratos, normas, especificaciones de requisitos del
sistema, documentos de casos de uso, o un documento de visión y alcance]
-147-
2.- Descripción General
2.1.- Perspectiva del Producto
[Describir el contexto y el origen del producto que se especifican en el presente ERS. Por ejemplo, indica si
el presente producto es una continuación en el miembro de una familia de productos, un reemplazo de
cierto sistema existente, o un nuevo producto.]
2.2.- Clases de Uso y Características
[Identificar las distintas clases de usuarios que utilizarán este producto, pueden ser diferenciados según la
frecuencia de uso, un subconjunto de las funciones de producto utilizado, la experiencia técnica, privilegios
o niveles de protección, nivel educativo, la experiencia. Describir las características pertinentes de cada
clase de usuario]
3.- Requerimientos Funcionales y de Capacidad
3.1.- Características del Producto
[Resumir las características principales que el producto contiene o las funciones importantes que realiza o
permite al usuario realizar. Organizar funciones para que sean comprensibles para cualquier lector de ERS.
Una imagen de los principales grupos de los requisitos relacionados y cómo se relacionan, como un
diagrama de flujo de datos a nivel superior o un diagrama de clase es a menudo eficaz.]
3.2.- Capacidad
[Este debe ser dividido en subpárrafos para detallar los requerimientos asociados a la capacidad del
elemento de configuración del software. La palabra "capacidad" puede ser reemplazada por "Función",
"sujeto", "objeto", o cualquier otra utilidad para la presentación de los requisitos.]
3.3.- Capacidad del Elemento de Configuración del Software
[Identificar un elemento de configuración de software requerido, y debe enumerar los requerimientos
asociados con la capacidad. De ser posible, la capacidad puede ser más claramente especificada
dividiéndola en las partes que la constituyen, estas partes deben estar especificadas en subpárrafos. Los
requerimientos deben especificar el comportamiento requerido por el elemento de configuración e incluir
parámetros aplicables, como: tiempos de respuesta, tiempos de transición, otras restricciones de tiempos,
secuencias, precisión capacidades de (cuanto), prioridades, requerimientos de operación continua y
derivaciones permisibles basados en las condiciones de operación.]
[Los requerimientos deben incluir el comportamiento bajo condiciones no esperadas o no permitidas,
manejo de errores y cualquier provisión a ser incorporada al elemento de configuración de software que
provee la continuidad de operación en eventos de emergencia]
3.4.- Entorno de Funcionamiento
[Describir el entorno en el que el software funcionará, incluyendo la plataforma de hardware, sistemas
operativos y versiones, y cualquier otro componente de software o aplicaciones con las que deben coexistir
pacíficamente]
[Detallar lo que el software debe de hacer. Se encuentran muy ligados al modelo conceptual propuesto. Se
concretarán las operaciones de tratamiento de información que realiza el sistema, tales como
almacenamiento de información, generación de informes, cálculos, estadísticas, operaciones, se deben
responder a las preguntas]
¿Qué hará el sistema?
¿Cuándo lo hará?
¿Existen varios modos de operación?
¿Cómo y cuándo puede cambiarse o mejorarse el sistema?
¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?
-148-
3.5.- Diseño y Restricciones de Implementación
[Describir los elementos o aspectos que limitarán las opciones disponibles para los desarrolladores. Estas
pueden incluir: las políticas corporativas o reglamentarias; limitaciones de hardware (requisitos de tiempo,
los requisitos de memoria); interfaces con otras aplicaciones, tecnologías, herramientas y bases de datos
que se utilizarán; operaciones paralelas, los requisitos de lenguaje, los protocolos de comunicación, las
consideraciones de seguridad, las convenciones de diseño o estándares de programación (por ejemplo, si la
organización del cliente será responsable del mantenimiento del software suministrado).]
3.6.- Suposiciones y Dependencias
[Indicar cualquier factor que se asuma (en lugar de los hechos que se conocen) que puedan afectar a los
requisitos establecidos en la ERS. Estos podrían incluir terceras partes o componentes comerciales que va a
utilizar, las cuestiones relacionadas con el desarrollo o Entorno de Funcionamiento o limitaciones. El
proyecto podría verse afectado si estas suposiciones son incorrectas, no se comparten, o cambian. También
identifica las dependencias que el proyecto tenga de factores externos, tales como componentes de
software que tiene la intención de volver a utilizar de otro proyecto]
3.7.- Características del Sistema
[Ilustrar la organización de los requisitos funcionales para el producto por características del Sistema, los
principales servicios que ofrece el producto. Es posible que se prefiera organizar esta sección por el caso de
uso, modo de operación, clase de usuario, el objeto jerarquía de clases, funcionales, o combinaciones de
estos, cualquiera que sea permita el sentido más lógico para su producto.]
3.8.- Características del Sistema 1
[No titular "Característica del Sistema 1." Establecer el nombre de la característica en sólo unas pocas
palabras.]
3.8.1.- Descripción y Prioridades
[Proporcionar una breve descripción de la función e indicar si es de alta, media o baja prioridad. También
puede incluir clasificaciones específicas, componentes prioritarios, como beneficio, penalizaciones, el costo
y riesgo (cada uno valorado en una escala relativa de un mínimo de 1 y un máximo de 9).]
3.8.2.- Estímulo/ Respuesta a Secuencias
[Listar las secuencias de las acciones del usuario y las respuestas del sistema que estimulan el
comportamiento definido para esta función. Estos corresponden a los elementos de diálogo asociado con
casos de uso.]
3.8.3.- Requerimientos Funcionales
[Listar los requisitos funcionales detallados relacionados con esta función.]
[Estas son las capacidades de software que deben estar presentes para que el usuario pueda llevar a cabo
los servicios prestados por la entidad, o para ejecutar el caso de uso. Incluye cómo el producto debe
responder a condiciones de error esperado o entradas inválidas. Los requisitos deben ser concisos,
completos, sin ambigüedades, verificables, y necesarios.]
3.8.4.- Requerimientos No Funcionales
[Listar los requisitos no funcionales detallados relacionados con esta función.]
[Especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, se refieren a todos los requisitos que ni describen información a guardar, ni
funciones a realizar.]
[Cada requisito debería ser identificado con un número de secuencia o una etiqueta significativa de algún
tipo.]
REQ-1:
REQ-2:
-149-
3.8.5.- Características del Sistema 2
[Y así en adelante, n características del sistema]
4.- Requerimientos de Interfaz Externa
4.1.- Interfaz de Usuario
[Describir las características lógicas de cada interfaz entre el producto de software y los usuarios. Esto
puede incluir imágenes de muestra de la pantalla, todas las normas de interfaz gráfica de usuario o
producto guías de estilo familiar que ha de seguir, las limitaciones de pantalla de diseño, los botones y
funciones estándar (por ejemplo, ayuda) que aparecen en cada pantalla, atajos de teclado, las normas de
error de mensaje de la pantalla, y etc. Define los componentes de software que se necesita una interfaz de
usuario. Los detalles del diseño de la interfaz de usuario deben ser documentados en las especificaciones
de interfaz de usuario por separado.]
4.2.- Interfaz de Hardware
[Proporcionar una breve descripción de la función del hardware e indican si es de alta, media o baja
prioridad. También podría incluir clasificaciones específicas, componentes prioritarios, como beneficia, la
pena, el costo y riesgo (cada uno valorado en una escala relativa de un mínimo de 1 y un máximo de 9]
4.3.- Interfaz de Software
[Describir las conexiones entre este producto y otros componentes de software específicos (Nombre y
versión), incluyendo bases de datos, sistemas operativos, herramientas, bibliotecas y componentes
comerciales integrados. Identificar los elementos de datos o mensajes que entran en el sistema y describe
el propósito de cada uno. Describir los servicios necesarios y la naturaleza de las comunicaciones. Se
refieren a los documentos que describen detalles de aplicación, protocolos de interfaz de programación.
Identifica los datos que serán compartidos a través de componentes de software. Si el mecanismo de
intercambio de datos deben ser implementadas de una manera específica (por ejemplo, el uso de un área
de datos global en un sistema operativo multitarea), esto como una restricción de la aplicación.]
4.4.- Interfaz de Comunicaciones
[Describir los requisitos relacionados con las funciones de comunicación requeridas por este producto,
incluyendo el correo electrónico, navegador web, protocolos de red de servidor de comunicaciones,
formularios electrónicos, y así sucesivamente. Define cualquier formato de mensaje correspondiente.
Identifica los estándares de comunicación que se utilizarán, como FTP o HTTP. Especifica cualquier
comunicación o de seguridad de cifrado cuestiones, los datos de tasas de transferencia y los mecanismos
de sincronización.]
4.5.- Requerimientos de Seguridad Física
[Especificar los requisitos que tienen que ver con la posible pérdida, daño o perjuicio que pudieran
derivarse de la utilización del producto. Definir las salvaguardias o las acciones que se deben tomar, así
como las acciones que deba evitarse. Se refieren a todas las políticas externas o las regulaciones de
seguridad que puedan afectar al hardware y los medios de almacenamiento de datos. Define las
certificaciones de seguridad que deben cumplirse.]
5.- Requerimientos de Seguridad de Acceso
[Especificar los requisitos con respecto a las cuestiones de seguridad o privacidad que rodean el uso del
producto o la protección de los datos utilizados o generados por el producto. Definir los requisitos de
identidad de autenticación de usuario. Se refiere a todas las políticas externas o una normativa que
contenga las cuestiones de seguridad que afectan al producto. Define las certificaciones de seguridad o de
privacidad que deben ser satisfechas.]
6.- Requerimientos de Base de Datos
[El análisis de requerimientos para una base de datos incorpora las mismas tareas que el análisis de
requerimientos del software]
-150-
[Requerimientos administrativos: se requiere mucho más para el desarrollo de sistemas de bases de datos
que únicamente seleccionan un modelo lógico de base de datos. La bases de datos es una disciplina
organizacional, un método, más que una herramienta o una tecnología. Requiere de un cambio conceptual
y organizacional.]
[Esto debe especificar los requisitos lógicos para cualquier información que será puesta en una base de
datos. Esto puede incluir lo siguiente:
•
•
•
•
•
Tipos de información usadas por varias funciones;
Frecuencia de uso;
Entidades de los datos y sus relaciones;
Restricciones de integridad;
Requerimientos en la retención de datos.]
7.- Requerimientos de Instalación y Aceptación del Software
7.1.- Requerimientos de Recursos del Sistema
[Este párrafo debe dividirse en los siguientes subpárrafos.]
7.2.- Requerimientos de Hardware del Computador
[Especificar los requerimientos de de cualquier elemento de hardware que debe ser utilizado por el
elemento de configuración de software. Los requerimientos deben incluir, de ser aplicable, número de cada
tipo de equipo, tamaño, capacidad y otras características requeridas como procesadores, memorias,
dispositivos I/O, almacenamiento auxiliar, comunicaciones, equipos de red u otro equipo.]
7.3.- Utilización de los Recursos de Hardware
[Especificar la utilización máxima permisible de cada elemento de hardware del elemento de configuración
de software, por ejemplo la capacidad máxima de almacenamiento, capacidad del procesador,
comunicaciones, redes, etc. Debe incluir medidas de medición bajo estas condiciones, con porcentajes
establecidos previamente.]
7.4.- Requisitos de Software
[Especifica los requisitos, en su caso, en relación con programas informáticos que deben ser utilizados por,
el sistema. Los ejemplos incluyen sistemas operativos, sistemas de bases de datos, comunicaciones /
software de red, software de dispositivos de entrada y salida.]
7.5.- Requisitos de Equipos de Comunicación
[Este apartado especifica los requisitos adicionales, en su caso, en relación con el equipo de
comunicaciones que deben ser utilizados por el sistema. Los ejemplos incluyen ubicaciones geográficas
vinculadas; topología de configuración y red, las técnicas de transmisión, las tasas de transferencia de
datos, portales, requieren de tiempos de uso del sistema, el tipo y volumen de datos a transmitir.]
8.- Requerimientos de Aceptación
[Si hay Requerimientos de Aceptación para el producto en distintas circunstancias, establecerlas aquí y
explicar su razón de ser, para ayudar al desarrollador a entender la intención y tomar decisiones
adecuadas de diseño. Especifica las relaciones de tiempo para los sistemas de tiempo real. Hace dichos
requisitos lo más específicos posibles. Es posible que necesite establecer Requerimientos de Aceptación
para los distintos requisitos funcionales o características.]
9.- Documentación de Usuario
[Lista de la Documentación de Usuario componentes (tales como manuales de usuario, ayuda en línea y
tutoriales) que será entregado junto con el software. Identifica cualquier documentación de Usuario
conocida formatos de entrega o las normas.]
-151-
[Se componen de los siguientes documentos entre otros:
•
•
•
•
La guía de instalación: Cómo instalar el software.
El tutorial: explica, paso a paso, cómo usar las diferentes características del software.
La guía de referencia: da una completa descripción a todas las características del software.
Los apéndices: trucos y pistas, lecturas sugeridas, direcciones de contacto e información general.]
10.-Evaluación de Requerimientos del Software
[Especificar las características de calidad adicional para el producto que va a ser importante para
cualquiera de los clientes o los desarrolladores. Algunos a considerar son: la adaptabilidad, la
disponibilidad, exactitud, flexibilidad, interoperabilidad, mantenibilidad, portabilidad, confiabilidad,
reusabilidad, robustez, capacidad de prueba, y la usabilidad. Se debe escribir estos para ser específicos,
cuantitativos y verificables cuando sea posible. Por lo menos, aclarar la relación, referencias para varios
atributos, tales como la facilidad de uso sobre la facilidad de aprendizaje.]
Provisiones de calificación:
Esta sección define un conjunto de métodos calificación que deben de ser utilizados para asegurar que un
requerimiento ha sido cumplido.
Los métodos de calificación pueden incluir:
•
Demonstración: La operación del sistema en desarrollo, o parte de este, recae en operaciones
funcionales observables, la operación funcional de este no requiere el uso de ningún instrumento
de prueba especial.
• Pruebas: La operación del sistema en desarrollo, o parte de este, usando un instrumento o
cualquier otro tipo de equipo especial de pruebas para recoger información luego del análisis.
• Análisis: El proceso de datos acumulados obtenidos de otro método de calificación.
• Inspección: La exanimación visual del código el sistema de software, documentación, etc.
• Métodos de calificación especiales: Cualquier método de calificación especial para el sistema de
software, por ejemplo herramientas especiales, técnicas, procedimientos y límites de aceptación
• Trazabilidad de requerimientos. Este párrafo debe incluir: Trazabilidad de cada requerimiento de
sistemas (o subsistema si es aplicable), que concierna al software en desarrollo.
11.-Otros Requerimientos
[Define cualquier otro requerimiento no contemplado en otra parte del ERS. Esto podría incluir requisitos
de base de datos, los requisitos de internacionalización, los requisitos legales, los objetivos de reutilización
para el proyecto, y así sucesivamente. Añadir cualquier nuevo artículo que tengan relación con el
proyecto.]
Glosario
[Define todos los términos necesarios para interpretar adecuadamente el ERS, incluyendo siglas y
abreviaturas. Es posible que desee crear un glosario independiente que abarca varios proyectos o de toda
la organización, y sólo incluyen términos específicos de un solo proyecto en cada uno de ERS.]
Análisis de Modelos
[Opcionalmente, puede incluir cualquiera de los modelos de análisis pertinentes, tales como diagramas de
flujo de datos, diagramas de clases, diagramas de transición de estados, o diagramas de entidad-relación.]
Lista de Problemas
[Esta es una lista dinámica de las cuestiones abiertas, requisitos que quedan por resolver, incluyendo TBD,
en espera de las decisiones, la información que se necesita, a la espera de resolución de conflictos, y
similares.]
-152-
ANEXO E: DISEÑO DE ARQUITECTURA DE ALTO NIVEL Y
DETALLADO
NOMBRE
FECHA
MOTIVO DE CAMBIO
VERSIÓN
[Nombre del Producto Software]
[Fecha de
Cambio]
[Descripción Motivo del Cambio]
[Versión del
Producto
Software]
1.- Introducción
1.1.- Propósito
[Describir la manifestación técnica de los requisitos del sistema, y lista de los objetivos que pretende lograr
el diseño]
1.2.- Uso Correcto
[No debe abarcar más de una sola página, donde se especifica:
•
•
•
•
De qué es el nuevo sistema.
El entorno social y tecnológico en el que el sistema funcionará.
Sus ventajas sobre sistemas anteriores.
Quiénes son los usuarios potenciales, y cómo se beneficiarán de ella]
2.- Arquitectura
2.1.- Introducción
[Deberá contener detalles como por ejemplo:
•
•
•
•
•
•
Tipo de sistema (distribuido, cliente-servidor, etc.)
En qué plataforma (s) el sistema va a correr.
Las entradas y salidas principales
Qué interfaces de usuario, el sistema tiene y en qué forma (web, interfaz gráfica de usuario de
Windows, etc.)
Las distancias entre los componentes en los ordenadores diferentes, en una LAN, en la web.
Una estimación aproximada del número de casos de cada parte (Módulos, hilos, procesos
•
, clientes, etc.)
Un diagrama de bloque de los módulos y las relaciones entre ellos puede ser muy útil aquí. Tratar de
destacar los aspectos dinámicos a pesar de que este punto de vista es en su mayoría es estáticos: incluyen
flechas para indicar el flujo de Datos y/o control, varios cuadros para indicar varias instancias de un hilo o
un Módulo, etc.
-153-
En una fase inicial de desarrollo, tendrá que elegir las principales tecnologías y elementos en los que se va
a basar el diseño. Las áreas en las que deben tomarse estas decisiones son, entre otras:
•
•
Las tecnologías de base; por ejemplo, la elección entre una base de datos y un sistema de
archivos, la elección entre una aplicación de red y un cliente web, etc.
El método de integración; por ejemplo, la elección entre un bus de servicio de empresa o un canal
punto a punto.]
3.- Interfaces
3.1.- Diagramas de Casos de Uso
[Definir mediante una notación gráfica, el comportamiento del sistema al afrontar un requisito o una tarea
de negocio]
FICHA TÉCNICA: DIAGRAMA DE CASOS DE USO
Fase en la que se usa:
Diseño de Software
Metodología:
UML
Nombre del producto:
Diagrama de Caso de uso
Herramientas para construirlo: [Sistema que se está
Desarrollando]
Definición del producto: Diagrama que permite especificar los requisitos funcionales de un sistema
Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en funciones y definir
los actores o roles que tendrán acceso a dichas funciones.
Nivel de detalle requerido para Diseño: a nivel de funciones que realizan alguna transacción que
involucra un conjunto de datos.
Símbolos Y Significado
Nombre del símbolo
Actor o Rol
Significado
Es quien interactúa con el
sistema. Puede acceder a una o
más funciones. En un sistema.
Paquete de casos de uso
Es un conjunto de casos de uso
agrupados según un cierto
criterio, el cual puede ser: grupos
de funciones, por usuarios, o por
fases del proceso organizacional
a quien los casos de uso dan
soporte.
Caso de uso
Función que el sistema pone a la
disposición de los actores.
Produce un resultado de valor
para los actores.
Relación de
Usado para establecer una
asociación bidireccional entre un
actor y un caso de uso.
Comunicación
-154-
Símbolo
Relación include
Usado para establecer la relación
entre 2 casos de uso, en el cual
un caso de uso contiene o
incluye al otro
Relación extend
Usado para establecer la relación
entre 2 casos de uso en la cual
uno extiende el comportamiento
del otro. El caso de uso 2 se
realiza si dentro del caso de uso
1 se da cierta condición.
Relación de
generalización
Usado para establecer la relación
“es un” entre actores o casos de
uso, generales y específicos.
Insumos: Requisitos Funcionales del Sistema, Diagramas de Procesos, Diagramas de actividades.
Elementos asociados a un caso de uso: Reglas del negocio que aplican para cada caso de uso.
Relaciones entre casos de uso: extend, include y actores que participan en cada caso de uso.
3.2.- Organización de Casos de Uso
FICHA TÉCNICA DEL PRODUCTO: ORGANIZACIÓN DE CASOS DE USO
Fase en la que se usa: Diseño de Software
Nombre del producto: Diagrama de
Paquetes de Casos de Uso
Metodología:
UML
Herramientas para construirlo:
[Sistema que se está Desarrollando]
Definición del producto: Los paquetes ofrecen un mecanismo general para la organización de los
modelos/subsistemas agrupando elementos de modelado. Puede ser usado para agrupar funcionalmente
los casos de usos de un sistema.
Utilidad para el cliente del proceso de diseño: Permite estructurar el sistema en subsistemas o módulos.
Nivel de Detalle Requerido para Diseño: Alto
-155-
Nombre del símbolo
Símbolos Utilizados y su Significado
Significado
Actor o Rol
Es quien interactúa con el sistema.
Puede acceder a uno o más
paquetes. En algunos casos, el actor
es un sistema.
Paquete
Es un conjunto de paquetes o de
casos de uso
agrupados según un cierto criterio, el
cual puede ser:
Relación de comunicación
Usado para establecer una asociación
bidireccional entre un actor y un
paquete.
Se muestran a partir del segundo
nivel.
Estereotipo
Usado para identificar el tipo de
paquete, si se trata de
Relación de dependencia
Usada para denotar cuando un caso
de uso de un caso de uso de otro
paquete. Se muestran a partir del
segundo nivel.
Símbolo
<< subsistema >>
Insumos: Cadena de Valor de Procesos, Diagrama de Procesos, Diagrama de Jerarquía de Procesos,
Diagrama de Actividades, Inventario de Procesos, Árbol de Procesos
3.3.- Escenarios de Casos de Prueba
FICHA TÉCNICA DEL PRODUCTO: ESCENARIOS CASOS DE USO
Fase en la que se usa: Diseño de Software
Nombre del producto: Escenario de caso de uso
(realización del caso de uso detallado)
Metodología:
Herramientas para construirlo:
[Sistema que se está Desarrollando]
UML
Escenario
Flujo de eventos normal o
especificación del caso de uso
Flujo de eventos
excepcionales o alternativos.
Flujo alternativo o puntos de
Símbolos y Significado
Significado
Conjunto de pasos escrito
en lenguaje natural que
muestra el flujo de eventos
principal, a través de una
secuencia de acciones que
ocurren entre los actores y
el sistema.
Flujo alternativo:
Conjunto de pasos que
describen el flujo de
-156-
Estructura
Numeración de los pasos: números
ordinales: 1., 2., ..n.
Frases empleadas:
“El usuario < acción >”
Ejemplo: “El usuario selecciona
Guardar.
“El sistema <acción>”
Ejemplo: “El sistema guarda el número,
fecha de la orden en la Base de Datos”.
Numeración de pasos de un flujo
alternativo:
extensión. Puntos de
excepción.
acciones al ocurrir una
cierta condición. Se utiliza
para mostrar las diferentes
opciones posibles de un
conjunto donde todas
tienen la misma posibilidad
de ser seleccionadas por el
usuario.
Flujo excepcional:
Conjunto de pasos que
describen las acciones que
se deben realizar en caso de
ocurrir alguna condición
excepcional, diferente al
flujo normal de eventos. Por
lo general, se utiliza para
manejar condiciones de
validación, manejo de
errores, etc.
Precondiciones o condiciones
de entrada
Pos condiciones o condiciones
de salida
Describen la condición previa
al conjunto de acciones del
flujo feliz, o lo que debe
ocurrir antes que se ejecute
este flujo.
Describe el estado final
obtenido después de
ejecutarse el flujo normal de
eventos.
Números ordinales seguidos de una
letra. Cuando haya más de una acción
dentro de un flujo excepcional, se
incorporan números.
Ejemplo: flujo normal:
2.- El sistema muestra la información
de la orden en pantalla.
Flujo excepcional:
2.a.- Si la orden no existe, el sistema
muestra un mensaje de advertencia.
Numeración de pasos de un flujo
alternativo:
Ejemplo: flujo normal:
3.- El usuario selecciona una opción.
Flujo alternativo:
3a.1.- Si el usuario selecciona
“Guardar”:
3a.2.- El sistema guarda los datos
suministrados en la Base de Datos.
3b.1.- Si el usuario selecciona
“Imprimir”:
3b.2.- El sistema activa el caso de uso
“Imprimir orden”.
Ejemplo:
“El usuario Ingresó al sistema de
Órdenes de Pago”
* El usuario registró los datos de la
solicitud de autorización para la
* El sistema almacenó los datos de la
solicitud y actualizó el estado de la
misma.
3.4.- Diagrama de Componentes
[Representa como un sistema de software es dividido en componentes y muestra la dependencia entre
estos.]
Las vistas centrales de un modelo arquitectónico son los diagramas de componentes, donde se muestran
los elementos primarios del sistema y cómo dependen unos de otros.
Un diagrama de componentes típico de un sistema grande podría incluir componentes como estos:
•
•
•
•
•
•
Presentación: Componente que proporciona acceso al usuario, normalmente mediante la
ejecución en un explorador web.
Componentes de servicio Web: Proporciona una conexión entre los clientes y los servidores.
Controladores de casos de uso: Dirige al usuario a través de los pasos de cada escenario.
Núcleo del negocio: Contiene clases que se basan en clases del modelo de requisitos, implementa
las operaciones clave e impone las restricciones del negocio.
Base de datos: Almacena los objetos del negocio.
Componentes de registro y control de errores.
Además de los propios componentes, puede mostrar las dependencias entre ellos. Una flecha de
dependencia entre dos componentes indica que los cambios que se realicen en el diseño de uno de ellos
pueden afectar al diseño del otro.
-157-
3.5.- Diseño Lógico de la Base de Datos
[Describir las partes significativas de la arquitectura lógica del modelo de la base de datos, como su
descomposición en paquetes, subsistemas y clases. Sus elementos son: objetos, entidades, nodos,
relaciones, enlaces, que realmente no tienen presencia real en la física del sistema. Por ello para acceder a
los datos tiene que haber una posibilidad de traducir la estructura lógica en la estructura física.]
3.6.- Diseño Físico de la Base de Datos
[Describir el modelo físico de la base de datos que refleja la distribución de las tablas en la base de datos,
se puede establecer los tipos de datos a utilizar en cada tabla y las restricciones claves primarias y
foráneas]
3.7.- Diagrama de Secuencia
[Ilustrar la integración de un conjunto de o objetos en una aplicación, a través del tiempo y se modela un
diagrama de secuencia para cada método de la clase]
[Representación utilizando formato UML]
Un diagrama de secuencia de muestra la interacción de un conjunto de objetos a través del tiempo. Se
modela para cada caso de uso, se puede prescindir si el caso de uso es muy sencillo.
-158-
Fase en la que se usa:
Diseño de Software
FICHA TÉCNICA: DIAGRAMA DE SECUENCIA
Nombre del producto:
Diagrama de Secuencia Detallado
Metodología:
Herramientas para construirlo: [Sistema que se está
Desarrollando]
UML
Definición del producto: Diagrama que describe la dinámica de una aplicación o una parte de ella,
mostrando las interacciones entre los objetos desde el punto de vista temporal, insistiendo en la
cronología del envío de mensajes.
Utilidad para el cliente del proceso de diseño: Permite conocer en detalle para cada evento del sistema
o hilo de operación, cuáles métodos se requieren de las instancias de las clases involucradas en la
realización del caso de uso, así como el ordenamiento de los mensajes entre los objetos. Facilita la
programación orientada a objetos.
Nivel de detalle requerido para Programación: Se puede obtener uno o más diagramas de secuencia
detallados para un caso de uso, tomando en cuenta que por cada uno de éstos existen varios eventos
del sistema o hilos de operación. El nivel de detalle debe incluir: métodos utilizados por clase, atributos
o parámetros que se pasan a través de los mensajes, valores de retorno, condiciones sobre los mensajes
e iteraciones, tipos de mensajes (síncronos, asíncronos, de retorno). También se necesita identificar la
clase controladora que resolverá el evento del sistema, y debe estar previamente definida con todas sus
operaciones, y debidamente documentada.
Símbolos y Significado
Símbolo
Nombre del Símbolo
Significado
Representa al actor que inicia
los eventos del sistema ó
Actor
recibe mensajes del sistema a
través de la clase
controladora.
Línea de vida
Ejecución ó caja de activación
Uso de la Interacción
Línea de vida asociada a un
objeto. Representa la duración
de la vida de un objeto dentro
del diagrama de secuencia.
Indica la duración. Es un
elemento opcional que se
puede utilizar para apilar
operaciones que se activan
durante una temporada dada
en el objeto que emite los
mensajes.
Identifica una referencia que
se hace de una interacción, la
cual puede definirse como un
pedazo del diagrama de
secuencia que es utilizado en
otra parte, así como la
referencia a otro diagrama de
secuencia que es utilizado en
otra parte, así como la
referencia a otro diagrama de
secuencia.
-159-
Alternativas de Interacción
Mensajes entre objetos
Elementos de un mensaje
Se utiliza para demarcar
dentro del diagrama de
secuencia, la sección de
acciones dada una u otra
condición. Las condiciones se
separan por líneas punteadas.
Establecen el tipo de
comunicación entre objetos
del diagrama; existen varios
tipos:
a) Indefinido: puede ser un
flujo síncrono o asíncrono
b) Síncrono: el objeto que
envía un mensaje espera una
respuesta.
c) Asíncrono: el objeto que
manda el mensaje no
espera la respuesta del otro
objeto, sino que continúa su
ejecución.
d) Retorno: muestra el retorno
a partir de una llamada de un
objeto; pueden mostrarse los
valores que retorna. Algunos
diseñadores excluyen este
tipo de mensajes.
e) Creación de objeto: indica
el inicio de vida del objeto a
quien se envía el mensaje.
f) Destrucción de objeto:
indica la destrucción explícita
del objeto o la finalización de
su línea de vida.
g) Mensaje “this”: es un
mensaje que envía un objeto a
sí mismo.
Nota: para los mensajes
indefinidos, asíncronos o tipo
“this” se puede incluir la caja
de duración.
Método: el método indica la
acción que realizará la clase
que recibe dadas las
condiciones y parámetros de
la clase que envía. En el
ejemplo, “Calcular” es un
método del objeto b.
Argumentos o parámetros: si
el método requiere de
argumentos para su ejecución,
éstos se hacen explícitos.
Valor de retorno o variable de
retorno: es el valor que
retorna el método invocado.
-160-
3.8.- Prototipo de Pantallas
[Describir los prototipos de pantallas del proyecto, para evaluar la posicion de la información sobre la
pantalla: encabezados, botones, mensajes]
-161-
ANEXO F: PLAN DE PRUEBAS
NOMBRE
FECHA
MOTIVO DE CAMBIO
VERSIÓN
[Nombre del Producto Software]
[Fecha de
Cambio]
[Descripción Motivo del Cambio]
[Versión del
Producto
Software]
1.- Introducción
1.1.- Propósito
El propósito del plan de pruebas es proveer la información necesaria para planear y controlar los esfuerzos
de pruebas de un proyecto o iteración específicas. Describe el enfoque para probar el software y es el plan
general generado y utilizado por administradores para dirigir el esfuerzo de pruebas.
Este plan de pruebas soporta los siguientes objetivos
•
•
•
•
•
•
•
Identificar los ítems a probar.
Describe, en términos generales, el enfoque de pruebas a ser usado.
Identifica los recursos requeridos y provee un estimado de sus esfuerzos.
Lista los entregables de las pruebas del proyecto.
Identificar los tipos de pruebas a utilizar en la ejecución de las mismas.
Diseñar cada una de las pruebas de cada uno de las interacciones a probar.
Describe los tipos de pruebas que se van a ejecutar, el diseño, el orden de ejecución y los
entregables en cada una de las de los interacciones del proyecto.
1.2.- Uso Correcto
El presente plan de pruebas, puede ser utilizado para diferentes tipos de prueba como: unitarias, de
integración, del sistema, de carga, que se realizan para probar el funcionamiento del software.
1.3.- Objetivos
•
•
•
•
•
Asegurar el desarrollo de productos de alta calidad.
Enfoque en la prevención de defectos, tanto como la detección.
Identificar fallas dentro de la misma fase del desarrollo donde se producen para minimizar costos.
Aprendizaje conjunto de buenas prácticas de desarrollo.
Recopilar mediciones de calidad del producto y del proceso.
1.4.- Alcance
[Definir las pruebas unitarias, de integración, de validación, instalación, Análisis y Datos con el fin de ver la
funcionalidad, utilidad y desempeño de todos los módulos del sistema y de verificar la correcta migración
de las aplicaciones anteriores al nuevo sistema.]
-162-
1.5.- Documentación Disponible
Documentos
Disponible
Revisado/Aprobado
Observaciones
Plan de Gestión del
Proyecto
[…………………………]
Cronograma del
Proyecto
[…………………………]
Casos de Uso
[…………………………]
Requerimientos no
Funcionales
[…………………………]
Especificación de
Diseño
[…………………………]
2.- Estrategia de Pruebas
En este capítulo se describen el modelo de ejecución, las técnicas, herramientas, criterios de aceptación
que se utilizarán en la realización de las pruebas y ejecución de las mismas.
2.1.- Modelo de Ejecución de Pruebas
[En este parte del capítulo se define el modelo estándar de la ejecución de las pruebas]
2.2.- Contenido del Plan de pruebas
El plan de pruebas deberá contener en su formato la siguiente información:
Plan de Pruebas
Objetivo de la Prueba
Estrategia
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
[Definir claramente lo que se quiere alcanzar al realizar la prueba.]
[Procedimientos utilizados en el desarrollo de la prueba para lograr el
objetivo.
[Aplica para las pruebas unitarias, de integración, carga y de regresión. Se
refiere al software utilizado para la automatización de las pruebas
mencionadas.]
[Se establecen de acuerdo a la prueba que se está realizando, para verificar el
encargado de la pruebas.]
[Se establecen de acuerdo a la prueba que se está realizando, para verificar si
la ejecución de las pruebas fueron o no exitosas.]
[Datos adicionales.]
[Documento entregable que se proporcionara después de cada ejecución de
cada tipo de prueba.]
Este formato aplica para cada tipo de prueba a la que se someterá al software como: Pruebas Unitarias,
Pruebas de Integración, Pruebas de validación, Pruebas de Datos y Pruebas de Instalación; de la siguiente
forma.
Entregable
-163-
Pruebas Unitarias
Plan de Pruebas Unitarias
Objetivo de la Prueba
Estrategia
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
Entregable
Validar las piezas individuales del software como una unidad independiente.
Sugerencia:
Se efectúan para los servicios del negocio y para la lógica del mismo que
tengan complejidad alta.
[Lista de herramientas informáticas que se van a utilizar para las pruebas, ej.:
Jmeter]
[Lista de responsables de ejecución de pruebas]
El 90% de las pruebas realizadas sean exitosas.
Detectar errores en la realización de las pruebas.
Módulo: pieza de código que cumple:
Bloque básico de programa.
Implementa función independiente simple.
Puede probarse por separado.
No hay entregable como documento si no como validación de la correcta
implementación.
Acta de aprobación de la ejecución de las respectivas pruebas.
Pruebas de Integración
Plan de Pruebas Integración
Objetivo de la Prueba
Estrategia
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
Validar la integración entre los diferentes módulos que componen la solución
con el fin de garantizar que su operación integrada es correcta
Sugerencia: Pruebas de Integración Incremental Ascendente
Combinación de módulos de bajo nivel en grupos que realicen una misma
función o subfunción especifica, con el fin de reducir el número de pasos de
integración.
Se escribe para cada módulo, un módulo impulsor o conductor, con el fin de
simular la llamada a los módulos, introducir datos de pruebas y recoger
resultados.
Se prueba cada módulo mediante su impulsor.
Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel
superior en la jerarquía.
[Lista de herramientas informáticas que se van a utilizar para las pruebas, ej.:
Jmeter.]
[Lista de responsables de ejecución de pruebas]
La cobertura total de lo probado sea mayor al 70% del total de los módulos.
El 90% de las pruebas realizadas sean exitosas.
Detectar errores en la realización de las pruebas.
Módulo Impulsor: Transmite o impulsa los datos de prueba al módulo que se
está probando y muestra los resultados de los casos de prueba.
Resultado Pruebas de Integración.
Acta de aprobación de la ejecución de las respectivas pruebas que contenga :
Entregable
Resultados de la ejecución de los scripts de pruebas.
Análisis de los defectos encontrados durante el proceso de pruebas.
-164-
Pruebas de Validación
Plan de Pruebas de Validación
Objetivo de la Prueba
Estrategia
Validar aquellos volúmenes de datos máximos (por lo general las
transacciones o informes) que pueden ser completados dentro de un período
específico en el tiempo, y con un nivel de concurrencia dado (carga,
concurrencia y desempeño).
Validar los requerimientos no funcionales de cada proyecto.
Sugerencia: Realizar Set de Pruebas a partir de los Requerimientos no
funcionales.
Realizar pruebas de rendimiento básico. Consiste en probar la aplicación.
Simulando la carga esperada en el entorno de producción.
Realizar las pruebas de concurrencia: verificar el comportamiento de la
aplicación en condiciones de sobrecarga de usuarios, lo cual supone la base
para identificar potenciales problemas de rendimiento o cuellos de botella,
antes de su pase a producción.
Realizar pruebas de requerimientos no funcionales: Consiste en probar la
aplicación con cada uno de los requerimientos no funcionales establecidos en
el proyecto.
Realizar pruebas de carga: Altos volúmenes de información (datos).
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
Entregable
[Lista de herramientas informáticas que se van a utilizar para las pruebas, ej.:
Jmeter.]
[Lista de responsables de ejecución de pruebas]
(Los Criterios de Aceptación deben ser definidos en los documentos de
requerimientos no funcionales.)
Que los reportes generados por las herramientas de automatización de
pruebas contengan las mínimas variables que permitan un análisis acertado
de la prueba.
Haber tenido en cuenta la mayoría de escenarios a los que puede ser
expuesta la aplicación a probar.
[Lista de observaciones]
Resultado Pruebas de Validación.
Acta de aprobación de la ejecución de las respectivas pruebas.
Resultados de la ejecución de los scripts de pruebas.
Análisis de los defectos encontrados durante el proceso de pruebas.
Pruebas de Datos
Plan de Pruebas de Datos
Objetivo de la Prueba
Verificar la calidad de la información, como los scripts que se ejecuten en la
base de datos.
Ejecutar los scripts o el código generado en la fase de desarrollo,
enmarcándolos en un contexto de semántica del negocio que permita
resolver los problemas lógicos así como los errores físicos.
El objeto es asegurar que la migración está correcta antes de poblar el
sistema destino.
-165-
Sugerencia:
Una vez se tiene listo el mapeo el siguiente paso es chequear si los datos
cumplen las validaciones del sistema destino, incluyendo reglas de negocio,
restricciones de semántica o sintácticas.
Se ejecutar los mapas de migración para identificar
Estrategia
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
Entregable
•
•
El número de registros que se espera que el script cree.
Si efectivamente ese número de registros se crearon, si no explicar el
por qué no fue así.
• Si los datos fueron cargados en los campos correctos.
• Si el formato de los datos fue el adecuado.
Realizar pruebas de rendimiento básico. Consiste en probar la base de datos
simulando la carga esperada en el entorno de producción.
No aplican.
[Lista de responsables de ejecución de pruebas]
Los datos deben cumplir con las validaciones del sistema destino, incluyendo
reglas de negocio, restricciones de semántica o sintácticas. Verificar el
número de registros que se espera que el script cree.
• Si los datos fueron cargados en los campos correctos.
• Si el formato de los datos fue el adecuado.
Si el sistema destino permite limpiar los datos cargados si la carga no fue
satisfactoria y existe el procedimiento para hacerlo, mediante el uso de la
capa intermedia de transformación.
Lista de observaciones.
Resultado Pruebas de calidad de migración.
Acta de aprobación de la ejecución de las respectivas pruebas.
Resultados de la ejecución de los scripts de pruebas.
Análisis de los defectos encontrados durante el proceso de pruebas.
Plan de Pruebas de Instalación
Plan de Pruebas de Instalación
Objetivo de la Prueba
Estrategia
Herramientas Requeridas
Responsables
Criterios de Evaluación
Observaciones
Entregable
Verificar la instalación de la aplicación en diferentes entornos de hardware y
software, siguiendo un procedimiento definido.
Sugerencia:
Basados en el Plan de Control de la Configuración (recursos de hardwaresoftware) para la aplicación, simular un entorno de producción para realizar
las pruebas.
[Lista de herramientas informáticas que se van a utilizar para las pruebas, ej.:
Jmeter,]
[Lista de responsables de ejecución de pruebas]
Que el sistema funcione correctamente en el entorno de pruebas producción.
Que el proceso de instalación no presente fallas en el momento de su
ejecución.
Que se haya tenido un manual claro de instalación.
Esta prueba no incluye el correcto funcionamiento de la consola
administrativa del servidor donde se realiza el despliegue, así como del
software base.
Resultado Pruebas de Instalación.
Acta de aprobación de la ejecución de las respectivas pruebas.
-166-
3.- Entregables
3.1.- Resultados de las pruebas
• Resultado Pruebas de Integración: [En este informe se entregarán los resultados de las pruebas
realizadas por los desarrolladores y el Jefe técnico de la validación de la integración entre los diferentes
módulos que componen la solución con el fin de garantizar que su operación integrada es correcta.]
• Resultado Pruebas de Validación: [En este informe se entregarán los resultados de las pruebas
realizadas por el Analistas de pruebas y el Jefe técnico de la validación de los requerimientos no funcionales
del Proyecto.]
• Resultado Pruebas de Instalación: [En este informe se entregarán los resultados de las pruebas
realizadas por el analista de Pruebas y el Jefe técnico de la validación de la instalación de la aplicación en
diferentes entornos de hardware y software.]
• Resultado Pruebas Unitarias: [En este informe se entregarán los resultados de las pruebas realizadas
por los desarrolladores de migración sobre la validación de las piezas individuales de la aplicación de
Migración y de los script que se utilizaran en la migración.]
• Resultado Pruebas de datos : [En este informe se entregarán los resultados de las pruebas realizadas
por el Analista de Pruebas, el Asesor en arquitectura de datos y el Jefe de Proyecto con el fin de la
verificación de la calidad de la información, así como de los script que se ejecuten en la base de datos.]
4.- Formato Universal Set de Pruebas
Identificador Universal:
[Identificador del proyecto]
Información General
Identificador de caso de uso:
[Identificador del caso de uso a probar]
Nombre de caso de uso:
[Nombre del caso de uso a probar]
Descripción Prueba:
[Descripción de la prueba que se va a realizar]
Responsable:
[Nombre de persona que ejecuta la prueba]
Prerrequisitos
[Prerrequisitos que se deben cumplir para iniciar la prueba]
Descripción de Casos de Prueba
Caso: [Explicación breve del caso de prueba a ejecutar*.]
Instrucciones de Prueba
[Pasos que se deben seguir para poder realizar correctamente la prueba]
Escenarios de prueba
Campo
Valor
[Nombre
de
campo a
probar]
[Dato de
prueba]
Tipo
escenario
[Correcto/I
ncorrecto]
Respuesta esperada de la aplicación
[Descripción completa de respuesta que
debe dar la aplicación al usar el campo
especificado con el dato de prueba]
-167-
Coincide (Si/No)
[sí/no, según la
respuesta obtenida]
Criterios de Aceptación
[Lista de chequeo de las
condiciones que se deben cumplir
para aprobar el caso de uso que se
está probando.]
•
A partir de este punto, se debe repetir el uso del formato para escribir tantos casos de prueba
como sean necesarios, para un mismo caso de uso.
-168-
ANEXO G: FORMATO ENCUESTA
ENCUESTA
“ELABORACIÓN DEL ESTÁNDAR DE APLICACIÓN DE LA NORMA ISO/IEC
12207, PARA EL DESARROLLO DE APLICACIONES SOFTWARE EN LA UTIC
DE LA ESPE”
Área de trabajo:
Cargo:
Horario de trabajo:
Fecha:
La presente encuesta, tiene como objetivo conocer la IMPORTANCIA y
URGENCIA de la aplicación de los procesos de la Norma ISO/IEC 12207, al
desarrollo de software dentro de la UTIC (Unidad de Tecnología de Información y
Comunicaciones) de la ESPE.
Sírvase llenar la encuesta, marcando con una X la calificación asignada en base a
estos criterios de evaluación:
A = ALTO M = MEDIO B = BAJO
Procesos Específicos del Software
Proceso de Implementación del Software
El propósito de este proceso es el producir un elemento específico del sistema,
implementado como un producto o servicio de software.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de Implementación del Software
-169-
URGENCIA
A
M
B
Proceso de Análisis de Requerimientos del Software
El propósito de este proceso es establecer requisitos para los elementos del
sistema de software.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Análisis de Requerimientos del
Software
Proceso de Diseño de Arquitectura del Software
El propósito de este proceso es el proveer un diseño de software que pueda ser
implementado y verificado con los requerimientos.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de
Software
Diseño
de
Arquitectura
URGENCIA
A
M
B
del
Proceso de Diseño Detallado del Software
El propósito de este proceso es el proveer un diseño para el software que se
implemente y pueda ser verificado con los requerimientos y la arquitectura
además de que sea suficientemente detallado para permitir codificación y
pruebas.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Diseño Detallado del Software
Proceso de Construcción del Software
El propósito de este proceso es el de producir módulos funcionales de software
que reflejen apropiadamente el diseño del mismo.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de Construcción del Software
-170-
URGENCIA
A
M
B
Proceso de Integración del Software
El propósito de este proceso, es el de combinar los módulos del software con los
componentes del mismo, produciendo ítems de software integrados, consistentes
con el diseño de software, que demuestren que los requerimientos de software
tanto funcionales como no funcionales serán satisfechos en un equivalente o
completa plataforma operacional.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Integración del Software
Proceso Sistema de Calificación de Pruebas
El propósito de este proceso es el de confirmar que los productos integrados de
software empaten con los requerimientos definidos.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso Sistema de Calificación de Pruebas
Proceso de Apoyo de Software
Proceso de Gestión de Documentación del Software
El propósito de este proceso es el desarrollar y mantener un historial de la
información del software producida por cada proceso.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Gestión de Documentación del
Software
Proceso de Gestión de Configuración del Software
El propósito de este proceso es establecer ítems para un proceso o proyecto que
los haga disponibles para ciertas partes.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de Gestión de Configuración del
Software
-171-
URGENCIA
A
M
B
Proceso de Aseguramiento de la Calidad del Software
El propósito de este proceso es de proveer la seguridad de que el producto
software cumpla con los planes predefinidos.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Aseguramiento de la Calidad del
Software
Proceso de Verificación del Software
El propósito de este proceso es el confirmar que cada producto y/o servicio de
software de un proyecto o proceso refleje apropiadamente los requerimientos
específicos.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Verificación del Software
Proceso de Validación del Software
El propósito de este proceso es el de confirmar de que los requerimientos para un
uso específico de un producto software sean satisfechos en su totalidad.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Validación del Software
Proceso de Revisión del Software
El propósito de este proceso es el de evaluar el estado y los productos de una
actividad de un proyecto, según sea adecuado. Las revisiones conjuntas están a
nivel tanto de gestión del proyecto como técnico y se mantiene a lo largo de la
vida del contrato. Este contrato puede ser empleado por cualquiera de las dos
partes, donde una de ellas (la revisora) revisa a la otra parte (la revisada).
Las revisiones del software son tanto para la administración del proyecto para
niveles técnicos que se mantienen a lo largo de la vida del proyecto.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de Revisión del Software
-172-
URGENCIA
A
M
B
Proceso de Auditoría del Software
El propósito de este proceso es el de independientemente determinar el
cumplimiento de seleccionados productos y procesos con los requerimientos,
planes y acuerdos de una manera apropiada.
IMPORTANCIA
A
M
B
PROCESOS
URGENCIA
A
M
B
Proceso de Auditoría del Software
Proceso de Resolución de Problemas de Software
El propósito de este procesos es el de asegurarse que todos los problemas que
se descubran sean identificados, analizados, gestionados y controlados hasta
llegar al resolverlos.
IMPORTANCIA
A
M
B
PROCESOS
Proceso de Resolución de Problemas de
Software
Sugerencias y Comentarios:
-173-
URGENCIA
A
M
B
BIBLIOGRAFÍA
•
Internacional ISO/IEC 15504; www.iso.15504.es
•
ISO IEC 12207, Systems and Software Engineering Software Life Cycle
Processess, Ed.Second Edition, 2008.
•
Software Engineering Process Technology (SEPT), http://www.12207.com/
•
ISO IEC Information Technology Software Product Evaluation.
•
Roger S. Pressman Adaptado por Darrel Ince, Ingeniería de Software Un
Enfoque Práctico, Contreras Martínez, C.W., Redes Eléctricas. Madrid:
Deusto, 2004. Sworn, J., Microelectronics, 2ed. London: McGraw-Hill, 1998.
•
Modelos de Gestión de Calidad de Software
http://juanmarcosteoria2.blogspot.com/2008/01/normas-iso-12207.html
•
ISO/IEC 12207 Wikipedia Enciclopedia Libre,
http://es.wikipedia.org/wiki/ISO/IEC_12207
•
Sommerville, I., “Ingeniería del Software. Sexta edición”. Editorial Addison
Wesley, 2002.
•
Lawrence, S., “Ingeniería del Software”. Editorial Prentice-Hall, 2002.
•
MÉTRICA Versión 3”. Ministerio de Administraciones Públicas, 2001.
•
Clasificación del Software,
http://www.mitecnologico.com/Main/ClasificacionDelSoftware
•
Software de Sistemas,
http://www.todosconsoftwarelegal.es/frontend/100por100/Software-DeSistemas-vn2683-vst404
•
Software, Clasificación, Modelos, http://es.wikipedia.org/wiki/Software
•
SAPIV2, “Sistema Web de Integración de los Servicios Virtuales de las Áreas
de Investigación y Vinculación con la Colectividad de la Escuela Politécnica
del Ejército”
-174-
•
Sistema de Gestión de la Calidad ESPE, http://sgc.espe.edu.ec/
•
Workflow, Procesos documentales y transaccionales,
http://www.workflow.com.mx/
•
Planificación de Recursos Empresariales ERP,
http://es.wikipedia.org/wiki/Planificaci%C3%B3n_de_recursos_empresarial
es
•
AESOFT Asociación Ecuatoriana de Software,
http://aesoft.com.ec/index.php?option=com_content&task=view&id=108&Ite
mid=3&date=2011-02-01
•
ISO/IEC 15271, Information technology — Guide for ISO/IEC 12207
(Software Life Cycle Processes), Technologies de l'information — Guide
pour l'ISO/CEI 12207 (Processus du cycle de vie du logiciel).
-175-
BIOGRAFÍA
INFORMACIÓN
PERSONAL
Nombre
Dirección
Teléfono Domicilio
Celular
Estado Civil
Nacionalidad
Lugar y Fecha de
Nacimiento
Cedulad de identidad
INSTRUCCIÓN
FORMACIÓN
Andrés Gallegos Velásquez
Urb. Monjas Orquídeas, Rosseaut 1249 y Escudero
2606-588
087408393
Soltero
Ecuatoriana
Quito, Noviembre 08 de 1984
1718928169
Y
Educación Primaria
1990-1995
Institución
Educación Secundaria
1996-2003
Institución
Titulo
Educación Superior
2004-2010
Institución
Titulo
Colegio “Giovanni Antonio Farina”
Unidad Educativa “La Salle”
Bachiller en Ciencias Básicas
Escuela Politécnica del Ejército
Ingeniero en Sistemas e Informática
-176-
BIOGRAFÍA
INFORMACION
PERSONAL
Nombre
Dirección
Teléfono Domicilio
Celular
Estado Civil
Nacionalidad
Lugar y Fecha de
Nacimiento
Cedulad de identidad
INSTRUCCIÓN
FORMACIÓN
Pablo Anderson Ortiz Rodríguez
Mallorca N2455 y Barcelona, La Floresta
3227-451
087016705
Soltero
Ecuatoriana
Loja, Septiembre 18 de 1985
1715427793
Y
Educación Primaria
1990-1995
Institución
Educación Secundaria
1996-2003
Institución
Titulo
Educación Superior
2004-2009
Institución
Titulo
Escuela Particular Francisco Febres Cordero “La Salle”
Colegio Particular Hermano Miguel “La Salle”
Bachiller en Físico Matemático.
Escuela Politécnica del Ejército
Ingeniero en Sistemas e Informática
-177-
HOJA DE LEGALIZACIÓN DE FIRMAS
ELABORAD(O) POR
______________________
Andrés Gallegos Velásquez
_________________________
Pablo Anderson Ortiz Rodríguez
DIRECTOR DE LA CARRERA
____________________
Ing. Mauricio Campaña
Lugar y fecha: ________________________________
-178-