plan de aplicación norma iso/iec...

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

i

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

ii

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

iii

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

iv

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.


v

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.


vi

Í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.- Metodología de Investigación ................................................................................ 7

1.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

vii

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

viii

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

ix

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.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.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.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.1.- Construcción del Software .................................................................... 110

4.2.6.- Proceso de Integración del Software ................................................................ 111

4.2.6.1.- Propósito ....................................................................................................... 111


x

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.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.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.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.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.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

xi

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

xii

Í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

xiii

Í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

xiv

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.

-1-

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

-2-

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

-3-

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-02-01

-4-

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.

-5-

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.

-6-

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.

-7-

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.

-8-

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.

-9-

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.

-10-

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)

$ 2.970

$ 1.800

$ 100

$ 200

$ 220

$ 400

$ 120

$ 130

$ 2.970

Material bibliográfico

Material de oficina y copias

Varios

INGRESOS

EGRESOS

SERVICIOS

OTROS RECURSOS

TOTAL

Aporte

Computadores personales

Uso de equipos (energía eléctrica)

Uso de internet

Movilización

-11-

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

telecomunicaciones representadas, que rompieron los esquemas tradicionales de

comunicación y de acceso a la información

Figura 2.1: (Convergencia Tecnologías de Información y Comunicación)

2.1.2.- Definición TIC

Para poder definir a las TIC

es importante conocer previamente que la Tecnología,

técnicas que permiten el aprovechamiento práctico del conocimiento científico

en consecuencia las Tecnologías de la Info

conforman un conjunto de técnicas y elementos que tienen la función de:

procesar, almacenar, sintetizar, recuperar

de herramientas computacionales e informáticas, brindando así una gran vari

de formas de comunicación.

Según la Asociación Americana de las Tecnologías de la Información

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 Tomado de: http://definicion.de/tecnologia/4 ITAA: Information Technology Association of America

ELECTRÓNICA INFORMÁTICA

-12-


comunicación y de acceso a la información.


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 el conjunto de teorías y

que permiten el aprovechamiento práctico del conocimiento científico

en consecuencia las Tecnologías de la Información y la Comunicación


ntetizar, recuperar y presentar la información

de herramientas computacionales e informáticas, brindando así una gran vari

de formas de comunicación.

Según la Asociación Americana de las Tecnologías de la Información

son “el estudio, el diseño, el desarrollo, el fomento, el


http://definicion.de/tecnologia/

Association of America.

INFORMÁTICA TELECOMUNICACIONES



(Tecnologías de Información y Comunicación),

es el conjunto de teorías y

que permiten el aprovechamiento práctico del conocimiento científico3,

rmación y la Comunicación ,


la información, por medio

de herramientas computacionales e informáticas, brindando así una gran variedad

Según la Asociación Americana de las Tecnologías de la Información ITAA4

son “el estudio, el diseño, el desarrollo, el fomento, el


TIC

-13-

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.

-14-

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).

-15-

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.

-16-

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.

-17-

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.

� Administración de los servicios y redes de comunicación.

� Desarrollo y administración de proyectos de Tecnologías de

Información

Figura 2.2: (Servicios de las TIC

En la actualidad se está

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

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.

BASE DE DATOS (Creación, Manejo,

Administración)

PROYECTOS DE TI (Gestión,

Administraión, Desarrollo)

-18-

Administración de los servicios y redes de comunicación.

Desarrollo y administración de proyectos de Tecnologías de

ura 2.2: (Servicios de las TIC dentro de una Institución)

se está viviendo la “Sociedad de la Información” en la que



El conocer e implementar las tecnologías de información y comunicación,


facilitada ahora por el correo electrónico, además de tener


del planeta, es ahí donde radica su importancia.

DEPARTAMENTO TIC

APLICATIVOS (Administración,

Desarrollo, Adquisición)

REDES DE COMUNICACIÓN (Adminsitración)

SOPORTE Y MANTENIMIENTO

(Hardware y Software)

BASE DE DATOS (Creación, Manejo,

Administración)

PROYECTOS DE TI

Desarrollo y administración de proyectos de Tecnologías de

dentro de una Institución)

viviendo la “Sociedad de la Información” en la que



comunicación,


facilitada ahora por el correo electrónico, además de tener


-19-

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.

-20-

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

7Tomado de: http://es.wikipedia.org/wiki/Software 8Tomado de: http://www.bloginformatico.com/concepto-y-tipos-de-software.php

-21-

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.

-22-

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.

-23-

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.

-24-

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.

-25-

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

-26-

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 soliciten

correcciones, adaptaciones y mejoras de la entidad?

-27-

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.

-28-

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

-29-

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

-30-

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)

-31-

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.

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.

1

2 3

6 74 5

Stub

Módulo reemplazado por un stub

-32-

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.

-33-

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.

-34-

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

-35-

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.

Figura

2.2.8.1.2.- Modelo Cascada

Es una variación que se utiliza en el modelo lineal, que consiste en la

retroalimentación de etapas, por

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 po

modelo.

Figura 2.6

ANÁLISIS

-36-

Figura 2.6: (Representación Modelo Lineal)

Modelo Cascada

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



se realiza una retroalimentación entre las fases para poder continuar con el

2.6: (Representación Modelo Cascada)

ANÁLISIS

DISEÑO

IMPLEMENTACIÓN

INTEGRACIÓN Y PRUEBAS

OPERACIPON Y MANTENIMIENTO

ANÁLISIS

DISEÑO

IMPLEMENTACIÓN

INTEGRACIÓN Y PRUEBAS

OPERACIPON Y MANTENIMIENTO

s una variación que se utiliza en el modelo lineal, que consiste en la

ejemplo, si se pasa de la fase de definición de



der continuar con el

-37-

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

otro en cualquier momento

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.

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 del proceso, en esta parte tiene similitud al modelo

1 INCREMENTO

• Analisis Implementación Pruebas2 INCREMENTO

• Analisis Implementación

-38-

otro en cualquier momento, el modelo sugiere un enfoque incremental, como


los requerimientos, hasta adquirir experiencia con el sistema.




Tiempo de Calendario

2.9: (Representación Modelo Incremental)

Modelo Espiral




iclo del proceso, en esta parte tiene similitud al modelo

1 INCREMENTO

Analisis - Diseño -Implementación -Pruebas2 INCREMENTO

Analisis - Diseño -Implementación - Pruebas

3 INCREMENTO

• Analisis - Diseño -Implementación - Pruebas

4 INCREMENTO

• Analisis - Diseño -Implementación - Pruebas

un enfoque incremental, como








iclo del proceso, en esta parte tiene similitud al modelo

-39-

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

-40-

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.

-41-

• 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.

-42-

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.

-43-

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.

-44-

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.

-45-

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.

-46-

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

-47-

Figura 2.11: (Ciclo de Vida de los Procesos de Software de 12207)

-48-

Fig

ura

2.1

2: (Sel

ecc

ión d

e Ele

men

to(s

) de la

Norm

a que

se a

just

an a

nec

esid

ades

de

la O

rgan

izac

ión)

-49-

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.

-50-

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.

-51-

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.

-52-

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

-53-

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

-54-

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.

-55-

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)

-56-

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.

-57-

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.

-58-

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.

-59-

3.4.7.- Registros Controlados

Tabla 3.2: (Registros Controlados GT4)

REGISTRO UBICACIÓN RECUPERACIÓN

RETENCIÓN DISPOSICIÓN ORDEN ACCESO

Memorando (de

contestación).

Unida de Tecnología y Telecomunicaciones UTIC.

Cronológico Abierto Tres años. Archivo General

Requerimientos de

Aplicativos.

Desarrollo, Implantación y Mantenimiento de Aplicativos.

Aplicativo,

fecha Abierto

Tres años, se enviará a disposición en enero de cada año siempre y cuando haya sido finalizado.

Archivo General

Especificaciones

Técnicas (archivo

digital).


Aplicativo,

fecha Abierto


Archivo General

Modelos.


Aplicativo,

fecha Abierto


Archivo General

Bitácora del

aplicativo.


Aplicativo,

fecha Abierto

Indefinida, copia cada 3 meses a Archivo General y cada 6 meses a ESPE-Idiomas.

Archivo

General/ESPE

IDIOMAS

Manual del

aplicativo.


Aplicativo,

fecha Abierto


Archivo general

-60-

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.

-61-

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.

-62-

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)

-63-

3.4.10.2.- Construcción de Aplicativos

Figura 3.4: (Diagrama Construcción de Aplicativos)

-64-

3.4.10.3.- Implantación de Aplicativos

Figura 3.5: (Diagrama Implantación de Aplicativos)

-65-

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

-66-

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:

∑ =

++==

n

i

n

n

aaaa

nx

1

211

_ ...1

Encuestados:

Área de trabajo: UTIC – Tecnologías de Información

Cargo: Técnico especialista 2

Iniciales: TE121


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

-67-


Cargo: Técnico Especialista

Iniciales: TE3


Cargo: Técnico Especialista TIC

Iniciales: TE4

Tabla 3.3: (Matriz de Importancia Urgencia Procesos ISO/IEC 12207:2008)

PROCESOS DE IMPLEMENTACIÓN

IMPORTANCIA MEDIA URGENCIA MEDIA

ENCUESTADOS PROCESOS T1 T2 T3 T4

X T1 T2 T3 T4

X

Proceso de Implementación de

Software.

7 7 5 7 7 7 7 5 7 7

Proceso de Análisis de

Requerimientos del Software.

7 7 7 7 7 7 7 7 7 7

Proceso de Diseño de Arquitectura

del Software.

7 7 7 7 7 7 5 7 7 7

Proceso de Diseño Detallado del

Software.

7 7 7 7 7 7 5 7 7 7

Proceso de Construcción del

Software.

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

-68-

Tabla 3.4: (Matriz de Importancia Urgencia Procesos de Apoyo ISO/IEC 12207:2008)

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.

PROCESOS DE APOYO

IMPORTANCIA MEDIA URGENCIA MEDIA

ENCUESTADOS PROCESOS

T1 T2 T3 T4 X

T1 T2 T3 T4 X

Proceso de Gestión de la

Documentación del Software.

7 7 5 5 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

-69-

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.

-70-

Figura 3.6: (Diagrama de Análisis de Requerimientos)

Actividades / Tareas Responsable

-71-

Figura 3.7: (Diagrama de Proceso de Diseño de Alto Nivel)


-72-

Figura 3.8: (Diagrama de Proceso de Diseño Detallado de Software)


-73-

Figura 3.9: (Diagrama Proceso de Construcción de Software)


-74-

Figura 3.10: (Diagrama Proceso De Integración)


-75-

Figura 3.11: (Diagrama Proceso De Pruebas)


-76-

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.

.

-77-

Tab

la 3

.5: (C

uad

ro C

om

par

ativ

o D

esar

rollo d

e Softw

are

UTIC

-ESPE v

s Est

ándar

de

Aplica

ción N

orm

a IS

O/IE

C 1

2207

)

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

AN

ÁLI

SIS

Y D

ISEÑ

O P

AR

A E

L D

ESA

RR

OLL

O D

E

AP

LIC

ATI

VO

S

PR

OC

ESO

DE

AN

ÁLI

SIS

DE

REQ

UER

IMIE

NTO

S D

ESO

FTW

AR

E

P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s

AN

ÁLI

SIS

REQ

UER

IMIE

NTO

S

•

Re

aliz

ar le

van

tam

ien

to

de

info

rmac

ión

y

req

uer

imie

nto

s d

e

usu

ario

.

Req

ue

rim

ien

to d

e

aplic

ativ

os:

a)

Des

arro

llo

Imp

lan

taci

ón

y

Man

ten

imie

nto

de

Ap

licat

ivo

s.

•

Iden

tifi

caci

ón

de

req

uer

imie

nto

s p

or

par

te

de

los

inte

resa

do

s.

Do

cum

ento

s d

e E

spec

ific

ació

n d

e

Req

uer

imie

nto

s d

el s

oft

war

e.

•

Det

erm

inac

ión

de

Esp

ecif

icac

ion

es

Técn

icas

de

l Ap

licat

ivo

.

Esp

ecif

icac

ion

es T

écn

icas

(arc

hiv

o d

igit

al):

a)

De

sarr

ollo

Imp

lan

taci

ón

y

Man

ten

imie

nto

de

Ap

licat

ivo

s.

•

Esp

ecif

icac

ion

es

Fun

cio

nal

es y

de

Cap

acid

ad.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

An

ális

is in

frae

stru

ctu

ra

de

tele

com

un

icac

ion

es

GT3

(A

DM

INIS

TRA

CIÓ

N

DE

RED

ES Y

TELE

CO

MU

NIC

AC

ION

ES).

•

Inte

rfac

es E

xter

nas

. D

ocu

men

to A

nál

isis

de

Req

uer

imie

nto

s d

e S

oft

war

e.

-78-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

•

An

ális

is D

iseñ

o d

e

Mo

del

os.

•

Re

qu

erim

ien

tos

de

Val

idac

ión

.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

An

ális

is D

iseñ

o d

e

Inte

rfac

es.

•

Re

qu

erim

ien

tos

de

segu

rid

ad .

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

An

ális

is D

iseñ

o d

e

Co

mp

on

ente

s.

•

Re

qu

erim

ien

tos

de

segu

rid

ad f

ísic

a.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

Esp

ecia

cio

ne

s d

e d

e

segu

rid

ad d

e a

cces

o.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

Def

inic

ión

de

dat

os

y

req

uer

imie

nto

s d

e b

ases

de

dat

os.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

Re

qu

erim

ien

tos

de

inst

alac

ión

y a

cep

taci

ón

d

el p

rod

uct

o s

oft

war

e.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

Do

cum

enta

ció

n u

suar

io.

Do

cum

ento

An

ális

is d

e

Req

uer

imie

nto

s d

e S

oft

war

e.

•

Eval

uac

ión

de

Re

qu

erim

ien

tos

de

soft

war

e.

Do

cum

ento

de

Eval

uac

ión

de

Req

uer

imie

nto

s d

e s

oft

war

e.

-79-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

AN

ÁLI

SIS

Y D

ISEÑ

O P

AR

A E

L D

ESA

RR

OLL

O D

E

AP

LIC

ATI

VO

S

PR

OC

ESO

DE

DIS

EÑO

DE

AR

QU

ITEC

TUR

A D

E SO

FTW

AR

E

P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s

DIS

EÑO

DE

SOFT

WA

RE

•

Dis

eñar

Mo

del

os

y o

actu

aliz

ar.

Mo

de

los:

a)

Des

arro

llo

Imp

lan

taci

ón

y

Man

ten

imie

nto

s d

e

Ap

licat

ivo

s.

•

Des

arro

llo E

stru

ctu

ra A

lto

Niv

el.

Do

cum

ento

Dis

eño

de

Alt

o N

ive

l de

Soft

war

e.

•

Dis

eño

de

inte

rfac

es d

e

la a

plic

ació

n.

•

Des

arro

llo In

terf

aces

Exte

rnas

de

alto

niv

el.

Do

cum

ento

Dis

eño

de

Alt

o N

ive

l de

Soft

war

e.

•

Dis

eño

de

com

po

nen

tes

de

la

aplic

ació

n.

•

Des

arro

llo y

Dis

eño

de

Alt

o N

ivel

BB

DD

.

Do

cum

ento

Dis

eño

de

Alt

o N

ive

l de

Soft

war

e.

•

Act

ual

izac

ión

Do

cum

enta

ció

n u

suar

io s

i

exi

sten

cam

bio

s.

•

Def

inic

ión

Req

uer

imie

nto

s

Pre

limin

are

s d

e P

rueb

a.

Do

cum

ento

de

Pla

n d

e In

tegr

ació

n

de

Soft

war

e.

•

Pla

nif

icac

ión

par

a la

Inte

grac

ión

de

Soft

war

e.

Do

cum

ento

de

Pla

n d

e In

tegr

ació

n

de

Soft

war

e.

-80-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

•

Eval

uac

ión

arq

uit

ect

ura

de

ele

me

nto

so

ftw

are,

dis

eño

de

inte

rfaz

y D

DB

B.

Do

cum

ento

de

Eval

uac

ión

de

Arq

uit

ectu

ra d

e so

ftw

are.

PR

OC

ESO

DE

DIS

EÑO

DET

ALL

AD

O D

E A

RQ

UIT

ECTU

RA

DE

SOFT

WA

RE

•

Dis

eño

Ref

inad

o d

e

Co

mp

on

ente

.

Do

cum

ento

Dis

eño

Det

alla

do

de

Soft

war

e.

•

Dis

eño

Det

alla

do

de

inte

rfac

es e

xter

nas

.

Do

cum

ento

Dis

eño

Det

alla

do

de

Alt

o

Niv

el d

e So

ftw

are.

•

Des

arro

llo D

etal

lad

o d

e

DD

BB

.

Do

cum

ento

Dis

eño

Det

alla

do

de

Alt

o

Niv

el d

e So

ftw

are.

•

Def

inic

ión

de

Re

qu

erim

ien

tos

de

Pru

eba,

pla

nif

icac

ión

de

las

pru

ebas

de

un

idad

es.

Do

cum

ento

de

Pla

n d

e P

rue

bas

de

Un

idad

es.

•

Act

ual

izar

Re

qu

erim

ien

tos

de

Pru

eba

y p

lan

de

Ap

licac

ión

.

Do

cum

ento

de

Pla

n d

e In

tegr

ació

n d

e

Soft

war

e.

-81-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

•

Eval

uac

ión

Dis

eñ

o

Det

alla

do

de

Soft

war

e.

Do

cum

ento

de

Eval

uac

ión

Dis

eño

Det

alla

do

De

So

ftw

are

.

CO

NST

RU

CC

IÓN

DE

AP

LIC

ATI

VO

S

PR

OC

ESO

DE

CO

NST

RU

CC

IÓN

DE

SOFT

WA

RE

P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s

CO

NST

RU

CC

IÓN

DE

SOFT

WA

RE

•

An

aliz

ar e

l Dis

eñ

o d

el

Ap

licat

ivo

.

•

Des

arro

llo d

e U

nid

ades

de

Soft

war

e y

de

la

DD

BB

.

•

Co

nst

ruir

o m

od

ific

ar la

bas

e d

e d

ato

s si

req

uie

re.

•

Pla

n d

e p

rueb

as d

e

Un

idad

y D

DB

B.

Do

cum

ento

Pla

n d

e P

rueb

as d

e

Soft

war

e.

•

Co

nst

ruir

o m

od

ific

ar

las

inte

rfac

es d

e

aplic

ativ

os

si r

equ

iere

.

•

Pro

bar

Un

idad

es d

e

Soft

war

e y

DD

BB

.

Do

cum

ento

de

Pru

ebas

de

Un

idad

de

Soft

war

e y

DD

BB

.

•

Co

nst

ruir

o m

od

ific

ar

com

po

nen

tes

si

req

uie

re.

•

Act

ual

izar

Do

cum

enta

ció

n d

e

usu

ario

si e

s n

ece

sari

o.

•

Gen

era

r ve

rsió

n d

el

Ap

licat

ivo

.

Bit

áco

ra d

el a

plic

ativ

o: a

)

De

sarr

ollo

Imp

lan

taci

ón

y

Man

ten

imie

nto

de

•

Act

ual

izar

req

uer

imie

nto

s d

e

pru

eba

y p

lan

de

Do

cum

ento

de

Pla

n d

e In

tegr

ació

n d

e

Soft

war

e.

-82-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

Ap

licat

ivo

s in

tegr

ació

n.

•

Pro

bar

Ver

sió

n d

el

Ap

licat

ivo

.

•

Eval

uac

ión

Có

dig

o

Fuen

te y

Res

ult

ado

de

las

Pru

ebas

.

Do

cum

ento

de

Eval

uac

ión

de

Co

nst

rucc

ión

de

Soft

war

e.

•

Alm

acen

ar V

ersi

ón

el

Arc

hiv

os

de

Ver

sio

ne

s

del

Ap

licat

ivo

(res

pal

do

s).

Bit

áco

ra d

el a

plic

ativ

o: a

)

De

sarr

ollo

Imp

lan

taci

ón

y

Man

ten

imie

nto

de

Ap

licat

ivo

s.

PR

OC

ESO

DE

INTE

GR

AC

IÓN

DE

SOFT

WA

RE

P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s

•

Des

arro

llo d

el P

lan

de

Inte

grac

ión

.

Do

cum

ento

Pla

n d

e In

tegr

ació

n.

•

Inte

grac

ión

de

Un

idad

es

de

Soft

war

e y

Co

mp

on

ente

s d

el

Soft

war

e.

Do

cum

ento

Pla

n d

e In

tegr

ació

n.

•

Act

ual

izac

ión

Do

cum

enta

ció

n d

e

Usu

ario

.

-83-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

•

Pre

par

a R

equ

erim

ien

tos

de

Val

idac

ión

de

l

Elem

en

to S

oft

war

e.

Do

cum

ento

Pla

n d

e P

rueb

as d

e

Soft

war

e.

•

Eval

uac

ión

de

l Pla

n d

e

Inte

grac

ión

de

Soft

war

e.

Do

cum

ento

Pru

ebas

de

Inte

grac

ión

.

IMP

LAN

TAC

IÓN

DE

AP

LIC

ATI

VO

S

PR

OC

ESO

DE

PR

UEB

AS

DEL

SO

FTW

AR

E

P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s P

roce

dim

ien

tos

Do

cum

en

tos

Res

ult

ante

s

•

Re

cep

tar

la V

ersi

ón

del

Ap

licat

ivo

.

•

Pru

ebas

de

Val

idac

ión

Elem

en

to S

oft

war

e.

Do

cum

ento

Pla

n d

e P

rueb

as d

e

Soft

war

e.

IMP

LEM

ENTA

CIÓ

N

DEL

SO

FTW

AR

E

•

Inst

alar

y o

Co

nfi

gura

r

la V

ersi

ón

del

Ap

licat

ivo

.

•

Act

ual

izar

Do

cum

enta

ció

n U

suar

io.

•

Co

nfi

gura

ció

n d

e B

BD

D

si r

equ

iere

.

•

Bri

nd

ar S

op

ort

e

Au

dit

orí

a d

e s

er

req

uer

ida.

•

Re

aliz

ar p

rueb

as

Fin

ales

de

la V

ersi

ón

.

•

Pre

par

ar P

rod

uct

o

Soft

war

e En

treg

able

.

Do

cum

ento

Man

ual

de

Usu

ario

.

•

Au

tori

zar

liber

ació

n.

Bit

áco

ra d

el a

plic

ativ

o: a

)

De

sarr

ollo

Imp

lan

taci

ón

y

•

Lib

erac

ión

Pro

du

cto

-84-

PR

OC

ESO

S U

TIC

ESP

E N

OR

MA

ISO

/IEC

12

207

Man

ten

imie

nto

de

Ap

licat

ivo

s.

Soft

war

e En

treg

able

.

•

Lib

erar

y N

oti

fica

r la

liber

ació

n d

e la

ver

sió

n.

Man

ual

del

ap

licat

ivo

: a)

De

sarr

ollo

Imp

lan

taci

ón

y

Man

ten

imie

nto

de

Ap

licat

ivo

s.

•

Cap

acit

ació

n d

el

aplic

ativ

o a

GT5

.

-85-

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.

-86-

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.

-87-

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.

-88-

� 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.

-89-

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.

-90-

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.

-91-

� 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.

-92-

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

-93-

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.

-94-

� 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.

-95-

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.

-96-

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.

-97-

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.

-98-

� 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.

-99-

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.

-100-

4.2.- Procesos Específicos del Software

4.2.1.- Proceso de Implementación del Software


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.

-101-

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

-102-

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


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.

-103-


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.

-104-

• 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.

-105-

4.2.3.- Proceso de Diseño de Arquitectura del Software


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.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.

-106-

• 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.


• El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo

con el Proceso de Revisión Conjunta del Software 4.3.4.

-107-

4.2.4.- Proceso de Diseño Detallado del Software


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.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.

-108-

• 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.

-109-

� 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.


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


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.

-110-


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.

-111-

� 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.


4.2.6.- Proceso de Integración del Software


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.

-112-


4.2.6.2.1.- Integración del Software

Para cada elemento de software (o para cada elemento de configuración de


• 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.


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

-113-

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.


El desarrollador debería llevar a cabo revisiones conjuntas de acuerdo con el

Proceso de Revisión Conjunta del Software 4.3.4.

-114-

4.2.7.- Proceso de Pruebas del Software


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.1.- Pruebas del Software

Para cada elemento software (o para cada elemento de configuración del


• 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.


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

-115-

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.


• 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.

-116-

4.3.- Procesos de Apoyo

4.3.1.- Proceso de Gestión de la Documentación del Software


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.


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.

-117-

� 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.

-118-

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.

-119-

4.3.2.- Proceso de Gestión de la Configuración del Software


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.




• 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.

-120-

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.

-121-

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.

-122-

4.3.3.- Proceso de Resolución de Problemas del Software


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.




• 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,

-123-

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

-124-

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


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).


Lista de actividades. Este proceso consta de las siguientes actividades:


• 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.

-125-

• 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.

-126-

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.

-127-

� 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


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.

-128-




• 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.

-129-

• 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.

-130-

� 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.

-131-

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

-132-

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

-133-

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.

-134-

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.

-135-

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.

-136-

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

-137-

• 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.


• 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


• Establecer un proceso de resolución de problemas.

-138-

• 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


• 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.

-139-

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:

-140-

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.

-141-

ANEXO C: PLAN DE GESTIÓN DE LA CONFIGURACIÓN




[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...]

-142-

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.]

-143-

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 [Persona que inicia la inquietud de la solicitud]

Teléfono(s)/Extensión(s)/Correo Electrónico

[Datos de la Persona que genera la solicitud]

Identificación

Aplicación [Componente de software sobre el cual recae la solicitud]

Línea Base Aplicativo [Escribir el número de la versión del aplicativo para el cual se solicita el

cambio]

Descripción del Cambio Solicitad

[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]

Importante [Comportamiento diferente a las especificaciones funcionales y/o

degradación del desempeño del sistema]

Deseable [Mejoras de forma o adición de funcionalidad a considerar para próximas

versiones del software]

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]

-144-

Evaluación

Responsable Planeación

[Nombre de la persona a quien se le asigna la evaluación funcional de la

solicitud]

Fecha de Asignación [Fecha en que se hace la asignación de la evaluación]

Seguimiento

Observaciones Adicionales

[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]

Estado de la Solicitud

[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

[Se listan los elementos de configuración que se tienen que modificar para

efectuar el cambio; por cada uno de ellos se anota:]

Responsable [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]

-145-

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:

-146-

• 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.]

-147-

ANEXO D: ESPECIFICACIÓN DE REQUERIMIENTOS DE

SOFTWARE (ERS)




[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]

-148-

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?

-149-

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:

-150-

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]

-151-

[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.]

-152-

[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.]

-153-

ANEXO E: DISEÑO DE ARQUITECTURA DE ALTO NIVEL Y

DETALLADO




[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.

-154-

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

Nombre del producto:

Diagrama de Caso de uso

Metodología:

UML

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 Significado Símbolo

Actor o Rol

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 Comunicación

Usado para establecer una asociación bidireccional entre un actor y un caso de uso.

-155-

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


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

-156-

Símbolos Utilizados y su Significado

Nombre del símbolo Significado Símbolo

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

<< subsistema >>

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.

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


Nombre del producto: Escenario de caso de uso (realización del caso de uso detallado)

Metodología:

UML

Herramientas para construirlo: [Sistema que se está Desarrollando]

Símbolos y Significado

Escenario Significado Estructura

Flujo de eventos normal o especificación del caso de uso

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.

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”.

Flujo de eventos excepcionales o alternativos. Flujo alternativo o puntos de

Flujo alternativo: Conjunto de pasos que describen el flujo de

Numeración de pasos de un flujo alternativo:

-157-

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.

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”.

Precondiciones o condiciones de entrada

Describen la condición previa al conjunto de acciones del flujo feliz, o lo que debe ocurrir antes que se ejecute este flujo.

Ejemplo:

“El usuario Ingresó al sistema de

Órdenes de Pago”

Pos condiciones o condiciones de salida

Describe el estado final obtenido después de ejecutarse el flujo normal de eventos.

* 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.

-158-

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.

-159-

FICHA TÉCNICA: DIAGRAMA DE SECUENCIA


Nombre del producto:

Diagrama de Secuencia Detallado

Metodología:

UML Herramientas para construirlo: [Sistema que se está

Desarrollando]

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

Nombre del Símbolo Significado Símbolo

Actor

Representa al actor que inicia los eventos del sistema ó recibe mensajes del sistema a través de la clase controladora.

Línea de vida

Línea de vida asociada a un objeto. Representa la duración de la vida de un objeto dentro del diagrama de secuencia.

Ejecución ó caja de activación

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.

Uso de la Interacción

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.

-160-

Alternativas de Interacción

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.

Mensajes entre objetos

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.

Elementos de un mensaje

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.

-161-

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]

-162-

ANEXO F: PLAN DE PRUEBAS




[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.]

-163-

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 [Definir claramente lo que se quiere alcanzar al realizar la prueba.]

Estrategia [Procedimientos utilizados en el desarrollo de la prueba para lograr el

objetivo.

Herramientas Requeridas [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.]

Responsables [Se establecen de acuerdo a la prueba que se está realizando, para verificar el

encargado de la pruebas.]

Criterios de Evaluación [Se establecen de acuerdo a la prueba que se está realizando, para verificar si

la ejecución de las pruebas fueron o no exitosas.]

Observaciones [Datos adicionales.]

Entregable [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.

-164-

Pruebas Unitarias

Plan de Pruebas Unitarias

Objetivo de la Prueba Validar las piezas individuales del software como una unidad independiente.

Estrategia Sugerencia: Se efectúan para los servicios del negocio y para la lógica del mismo que

tengan complejidad alta.

Herramientas Requeridas [Lista de herramientas informáticas que se van a utilizar para las pruebas, ej.:

Jmeter]

Responsables [Lista de responsables de ejecución de pruebas]

Criterios de Evaluación El 90% de las pruebas realizadas sean exitosas.

Detectar errores en la realización de las pruebas.

Observaciones

Módulo: pieza de código que cumple:

Bloque básico de programa.

Implementa función independiente simple.

Puede probarse por separado.

Entregable

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 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

Estrategia

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.


Jmeter.]


Criterios de Evaluación 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.

Observaciones 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.

Entregable

Resultado Pruebas de Integración.

Acta de aprobación de la ejecución de las respectivas pruebas que contenga :

Resultados de la ejecución de los scripts de pruebas.

Análisis de los defectos encontrados durante el proceso de pruebas.

-165-

Pruebas de Validación

Plan de Pruebas de Validación

Objetivo de la Prueba

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.

Estrategia 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).


Jmeter.]


Criterios de Evaluación

(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.

Observaciones [Lista de observaciones]

Entregable

Resultado Pruebas de Validación.




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.

-166-

Estrategia

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

• 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.

Herramientas Requeridas No aplican.



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.

Observaciones Lista de observaciones.

Entregable

Resultado Pruebas de calidad de migración.




Plan de Pruebas de Instalación

Plan de Pruebas de Instalación

Objetivo de la Prueba Verificar la instalación de la aplicación en diferentes entornos de hardware y

software, siguiendo un procedimiento definido.

Estrategia

Sugerencia:

Basados en el Plan de Control de la Configuración (recursos de hardware-

software) para la aplicación, simular un entorno de producción para realizar

las pruebas.


Jmeter,]



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.

Observaciones Esta prueba no incluye el correcto funcionamiento de la consola

administrativa del servidor donde se realiza el despliegue, así como del

software base.

Entregable

Resultado Pruebas de Instalación.


-167-

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

Respuesta esperada de la aplicación Coincide (Si/No) Campo Valor

Tipo escenario

[Nombre

de

campo a

probar]

[Dato de

prueba]

[Correcto/I

ncorrecto] [Descripción completa de respuesta que

debe dar la aplicación al usar el campo

especificado con el dato de prueba]

[sí/no, según la

respuesta obtenida]

-168-

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.

-169-

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.

PROCESOS IMPORTANCIA URGENCIA A M B A M B

Proceso de Implementación del Software

-170-

Proceso de Análisis de Requerimientos del Software

El propósito de este proceso es establecer requisitos para los elementos del sistema de software.


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.


Proceso de Diseño de Arquitectura del Software

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.


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.


Proceso de Construcción del Software

-171-

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.


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.


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.


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.


Proceso de Gestión de Configuración del Software

-172-

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.


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.


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.


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.


Proceso de Revisión del Software

-173-

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.


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.


Proceso de Resolución de Problemas de Software

Sugerencias y Comentarios:

-174-

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-De-Sistemas-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”

-175-

• 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_empresariales

• AESOFT Asociación Ecuatoriana de Software, http://aesoft.com.ec/index.php?option=com_content&task=view&id=108&Itemid=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).

-176-

BIOGRAFÍA

INFORMACIÓN PERSONAL

Nombre Andrés Gallegos Velásquez Dirección Urb. Monjas Orquídeas, Rosseaut 1249 y Escudero

Teléfono Domicilio 2606-588 Celular 087408393

Estado Civil Soltero Nacionalidad Ecuatoriana

Lugar y Fecha de Nacimiento

Quito, Noviembre 08 de 1984

Cedulad de identidad 1718928169

INSTRUCCIÓN Y FORMACIÓN

Educación Primaria 1990-1995 Institución

Colegio “Giovanni Antonio Farina”

Educación Secundaria 1996-2003 Institución

Titulo

Unidad Educativa “La Salle” Bachiller en Ciencias Básicas

Educación Superior 2004-2010 Institución

Titulo

Escuela Politécnica del Ejército Ingeniero en Sistemas e Informática

-177-

BIOGRAFÍA

INFORMACION PERSONAL

Nombre Pablo Anderson Ortiz Rodríguez Dirección Mallorca N2455 y Barcelona, La Floresta

Teléfono Domicilio 3227-451 Celular 087016705

Estado Civil Soltero Nacionalidad Ecuatoriana

Lugar y Fecha de Nacimiento

Loja, Septiembre 18 de 1985

Cedulad de identidad 1715427793

INSTRUCCIÓN Y FORMACIÓN

Educación Primaria 1990-1995 Institución

Escuela Particular Francisco Febres Cordero “La Salle”

Educación Secundaria 1996-2003 Institución

Titulo

Colegio Particular Hermano Miguel “La Salle” Bachiller en Físico Matemático.

Educación Superior 2004-2009 Institución

Titulo

Escuela Politécnica del Ejército Ingeniero en Sistemas e Informática

-178-

HOJA DE LEGALIZACIÓN DE FIRMAS

ELABORAD(O) POR

______________________


_________________________


DIRECTOR DE LA CARRERA

____________________

Ing. Mauricio Campaña

Lugar y fecha: ________________________________

plan de aplicación norma iso/iec...

Documents