UNIVERSIDAD PRIVADA DEL NORTE

UNIVERSIDAD PRIVADA DEL NORTE

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA DE SISTEMAS

“IMPLEMENTACIÓN DE MOPROSOFT EN EL PROCESO DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA EMPRESA

E-VOLUTION HYPERMEDIA S.R.L.”

TESIS

PRESENTADO PARA OPTAR EL TITULO PROFESIONAL DE:

INGENIERO DE SISTEMAS

Autor :

Br. Roxana Lisettte Quintanilla Portugal

Asesor :

Ing. Jorge Sanchez Castro.

TRUJILLO - PERU

A Dios Padre, ya decía Don Bosco que, la educación es cosa del corazón y sólo Dios es su dueño y nosotros no podremos triunfar en nada si Dios no nos enseña el arte de ganarnos los corazones y nos pone en la mano su llave.

A mi hermano Beto, quién siempre estuvo a mi lado incluso a la distancia, diciéndome que es muy importante tener un sistema de vida para triunfar en la ingeniería de sistemas.

A todos los que me dieron una sonrisa o una mano en el momento que talvez menos esperé, a todos los que en esta ciudad me hicieron sentir como en casa.

A mis padres, por su amor inmenso, por dejar que tome mis decisiones y porque me dan la herencia mas grande, Mi Profesión.

A mi hermana Margui, por ser como yo quisiera ser, por sus cariños, sus experiencias y sus mensajes espirituales.

Agradezco a Alfred Kobayashi Gerente de la Empresa E-volution Hypermedia, quién vio en mi las facultades para resolver problemas en el proceso de madurez de una pequeña empresa de software, que en la actualidad ya va viendo los frutos de su trabajo.

A Daniel Hugo Céspedes y Eddy Maidana colaboradores de Competisoft, quienes me brindaron su amistad y fuerte soporte con tantas dudas que tuve desde el inicio de esta investigación, de ahí que siempre es importante ver hacia afuera y que es lo que piensan otras personas más allá de nuestra Universidad.

Al Ing. Cesar Liza por guiarme en toda mi carrera universitaria, sus enseñanzas siempre han sido de inspiración para continuar este camino.

Al Ing. Jorge Sánchez por su asesoría, sus enseñanzas y compresión.

SEÑORES MIEMBROS DEL JURADO

Cumpliendo con los requisitos estipulados en el reglamento General de Graduados y Títulos de la Universidad, para optar por el título de Ingeniero de Sistemas; someto vuestra disposición la presente tesis, titulada:

“Implementación de MoProSoft en el Proceso de Desarrollo y Mantenimiento de Software de la Empresa E-volution Hypermedia S.R.L.”

La presente tesis es fruto de mis conocimientos, oportunidades, observación, dedicación y esfuerzo constante. Como Bachiller pido a ustedes, las disculpas del caso en cualquier error cometido en dicha ejecución.

Esperando que el presente trabajo de investigación sirva de ayuda y/o referencia para el desarrollo de futuros trabajos o proyectos en el cual se implemente modelos de mejora para el desarrollo de software, que permita mejorar la productividad, eficiencia, eficacia, calidad y competitividad en el producto que realicen las empresas de software y/o empresas con áreas internas de desarrollo de software.

Trujillo, Setiembre de 2008

QUINTANILLA PORTUGAL, Roxana Lisette

- A -

APE.- Proceso de Administración de proyecto específico del modelo de procesos de MoProSoft. Pertenece a la categoría de Operación, en la cual también se encuentra el proceso de Desarrollo y mantenimiento de Software DMS. El proceso de APE Establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados.

- B -

Base de Conocimiento.- La base de conocimiento es un repositorio que debe contener cualquier documento y producto generado por la organización con potencial valor de reuso para iteraciones subsecuentes de procesos o proyectos.

Booking.- Término que se refiere a reserva y puede también indicar el Dpto. de reservas de un agente turístico.

- C -

Capacidad del proceso.- es la determinación, de si dicho proceso es capaz de satisfacer las especificaciones que generalmente se establecen con el cliente, dada la variación natural.

Check-in.- Proceso de inscripción en un hotel o medio de transporte. Sinónimos:

Registro (en hotel), facturación (en transporte).

Check-out.- Proceso de salida de un establecimiento hotelero con la correspondiente liquidación de la cuenta de gastos. Sinónimo: Salida.

CMMI.- Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos.

de la Pequeña y Mediana Industria del Software de Iberoamérica, haciendo uso de MoProSoft. El objetivo general es incrementar el nivel de competitividad de las PYMES Iberoamericanas productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre al que establecer un mecanismo de evaluación y certificación de la industria del software reconocido en toda Iberoamérica.

Configuración del software.- Conjunto consistente de productos de software, su propósito es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. Los productos incluidos son: Software distribuido al cliente, documentos de requerimientos del software, Código, elementos requeridos para crearlos (ejm . compilador)

CYTED.- Programa Iberoamericano de ciencia y tecnología para el desarrollo, tiene como objetivo principal contribuir al desarrollo armónico de la Región Iberoamericana mediante el establecimiento de mecanismos de cooperación entre grupos de investigación de las Universidades, Centros de I+D y Empresas innovadoras de los países iberoamericanos, que pretenden la consecución de resultados científicos y tecnológicos transferibles a los sistemas productivos y a las políticas sociales.

- D -

DMS.- Proceso de Desarrollo y Mantenimientos de Software, parte de la Categoría de Operación del modelo MoProSoft. El propósito de Desarrollo y Mantenimiento de Software es la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevo o modificado cumpliendo con los requerimientos especificados

- E -

Evalprosoft.- El Método de Evaluación usa como modelo referencia el modelo de procesos de MoProSoft. El modelo de capacidades, que se utiliza para calificar el nivel de capacidad de los procesos. EvalProSoft, aplica a las organizaciones dedicadas al

modelo de procesos de referencia a MoProSoft para la implantación de sus procesos

- F -

Firmware.- Software almacenado en memoria. Programas esenciales que permanecen incluso cuando se apaga el sistema. El firmware es más fácil de cambiar que el hardware pero más permanente que el software almacenado en un disco.

- G -

Guía de ajuste.- Las guías de ajuste sugieren modificaciones al proceso que no deben afectar los objetivos del mismo. Se puede usar para adecuar el proceso en función de las estrategias de la organización. Posteriormente sustituir las guias de ajuste del modelo por las guías que apliquen en la organización.

- I -

ISO 9000.- Una serie de normas (9000, 9001, 9002, 9003) emitidas por la International Standards Organización para el aseguramiento de la calidad constante.. Es un modelo para definir las líneas básicas de un sistema de calidad y que se ha impuesto como estándar mundial. En su conjunto proporcionan guías para la gestión de la calidad y requisitos generales para el aseguramiento de la calidad, describiendo qué elementos deberían comprender los sistemas de calidad, pero no cómo una organización específica implanta estos elementos.

ISO/IEC 15504.- Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

- M -

MoProSoft- Modelo y norma técnica mexicana para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software

la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la capacidad de las organizaciones que desarrollan o mantienen software para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Es también aplicable en áreas internas de desarrollo de software de las empresas de diversos giros.

Mejora de procesos.- La mejora de los procesos, significa optimizar la efectividad y la eficiencia, mejorando también los controles, reforzando los mecanismos internos para responder a las contingencias y las demandas de nuevos y futuros clientes. La mejora de procesos es un reto para toda empresa de estructura tradicional y para sistemas jerárquicos convencionales.

- N -

NTP.- Norma técnica peruana.

- P -

Producto.- Un producto en MoProSoft y que convencionalmente es llamado artefacto, es un producto tangible resultante del proceso de desarrollo de software. Algunos productos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la descripción de la función, la arquitectura o el diseño del software. Otros se enfocan en el proceso de desarrollo en sí mismo, como planes de proyecto, casos de negocios o enfoque de riesgos. El código fuente compilado para el testeo se suele considerar un producto, ya que el ejecutable es necesario para el plan de testeo.

PDS.- En el plan de desarrollo de software se proporciona la información necesaria para controlar el proyecto. Se describe además el detalle de las iteraciones individuales, los planes de cada iteración y los documentos que se aportan en forma separada. Posteriormente, el avance del proyecto y el seguimiento de cada una de las iteraciones ocasionarán el ajuste de este documento produciendo nuevas versiones actualizadas.

Stakeholder.- Cualquier persona que puede resultar afectada por la realización de los objetivos de una organización, desde el punto de vista de la responsabilidad social de la empresa.

- U -

Ucumari.- Nombre del software de administración hotelera OnDemand de la Empresa E-volution Hypermedia S.R.L.

- W -

Workflow.- Sistema de automatización de procesos. Permite automatizar de forma integrada todos los flujos de datos y procesos administrativos, controles de autorización, verificaciones de datos y contacto de personas involucradas

CAPÍTULO I.PLAN DE INVESTIGACIÓN...1

1.1.EL PROBLEMA...1

1.2.HIPÓTESIS...4

1.3.OBJETIVOS...4

1.4.DISEÑO DE CONTRASTACIÓN...5

CAPITULO II.MARCO TEÓRICO...10

2.1.COMPETISOFT...10

2.2.MOPROSOFT...16

2.3.PROCESO DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE ...21

2.3.1.1.Propósito...21

2.3.1.2.Descripción...22

2.3.1.3.Objetivos...23

2.3.1.4.Indicadores...24

2.3.1.5.Metas Cuantitativas...24

2.3.1.6.Responsabilidad y Autoridad...24

2.3.1.7.Procesos relacionados...24

2.3.1.8.Entradas...25

2.3.1.9.Salidas ...25

2.3.1.10.Productos Internos...28

2.3.2.1.Roles, Involucrados y Capacitación...29

2.3.2.2.Actividades...30

2.3.2.3.Verificaciones y Validaciones...34

2.3.2.4.Incorporación a la Base de Conocimiento...38

2.4.NTP – PROCESOS DEL CICLO DE VIDA DEL SOFTWARE ...41

2.4.1.1.Organización [03]...41

2.4.1.2.Proceso de Desarrollo [03]...45

2.4.1.3.Proceso de Mantenimiento [03]...48

2.4.1.4.Proceso de Gestión de la configuración [03]...50

2.4.1.5.Proceso de verificación [03]...51

2.4.1.6.Proceso de Validación [03]...53

2.5.METODO DE EVALUACIÓN DE PROCESOS PARA LA INDUSTRIA DE

SOFTWARE EVALPROSOFT. ...55

2.5.3.1.Nivel 0, Proceso incompleto...56

2.5.3.2.Nivel 1, Proceso Realizado...56

2.5.3.3.Nivel 2 – Proceso Administrado...56

2.5.3.4.Nivel 3 – Proceso establecido...58

2.5.3.5.Nivel 4 – Proceso predecible...59

2.5.3.6.Nivel 5 – Optimizando el proceso...61

2.5.3.7.Calificación de los atributos del proceso [04]...62

2.6.CUESTIONARIO DE EVALUACIÓN DEL PROCESO DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE [01]...63

CAPITULO III.METODOLOGÍA...65

3.1.Introducción...65

3.2.Flujos de trabajo de DMS...66

CAPITULO IV.DESARROLLO...73

4.1.FASE DE INICIO...73

4.1.1.1.Introducción...73

4.1.1.2.Vista General del Proyecto...75

4.1.1.3.Organización del proyecto...81

4.1.1.4.Gestión del proceso...83

4.1.1.5.Referencias...87

4.2.FASE DE REQUERIMIENTOS...88

4.2.1.1.Introducción...88

4.2.4.1.Introducción...105

4.2.4.2.Requerimientos de pruebas...106

4.2.6.1.Introducción...116

4.2.6.2.Funciones Principales...116

4.3.FASE DE ANÁLISIS Y DISEÑO...122

4.3.1.1.Introducción...122

4.3.1.2.Arquitectura...123

4.3.1.3.Arquitectura de Datos...126

4.4.1.1.Introducción...133

4.4.1.2.Requerimientos...133

4.4.1.3.Instalación...133

4.4.1.4.Recomendaciones...134

4.5.AUTOEVALUACIÓN DEL PROCESO...135

CAPITULO V.CONCLUSIONES Y RECOMENDACIONES...144

5.1.CONCLUSIONES...144

5.2.RECOMENDACIONES...146

Tabla N° 1: Indicadores de medición del proceso... 6

Tabla N° 2: Proporción de muestras por fases ... 8

Tabla N° 3: Guía coloreada por niveles de capacidad...19

Tabla N° 4: Entradas del Proceso de DMS...22

Tabla N° 5: Salidas del Proceso de DMS...25

Tabla N° 6: Productos Internos del Proceso de DMS...25

Tabla N° 7: Roles del Equipo de Trabajo del Proceso de DMS ...26

Tabla N° 8: Actividades del Proceso de DMS...31

Tabla N° 9: Verificaciones y Validaciones de Productos de DMS...34

Tabla N° 10: Productos para el proceso de DMS...35

Tabla N° 11: Calificación de procesos de MoProSoft...57

Tabla N° 12: Niveles de capacidad de procesos...58

Tabla N° 13: Cuestionario para la evaluación del proceso...60

Tabla N° 14: Participantes del proyecto...77

Tabla N° 15: Roles y Responsabilidades del proyecto ...78

Tabla N° 16: Fases e Iteraciones del proyecto...79

Tabla N° 17: Hitos del proyecto ...80

Tabla N° 18: Definiciones del sistema Ucumari...84

Tabla N° 19: Abreviaturas de ERS...84

Tabla N° 20: Definiciones del sistema Ucumari...100

Tabla N° 21: Abreviaturas de plan de pruebas de sistemas...101

Tabla N° 22: Roles y Capacitación de Pruebas de sistema...103

Tabla N° 23: Clases Equivalente de UC 2.1.7...104

Tabla N° 24: pruebas Unitarias 001...104

Tabla N° 25: pruebas Unitarias 002...105

Tabla N° 26: pruebas de caso de uso 003...105

Tabla N° 27: Clases Equivalentes UC 2.1.1...106

Tabla N° 28: pruebas unitarias 004...106

Tabla N° 29: pruebas de casos de uso 005...107

Tabla N° 30: Clases Equivalentes UC 5.1.2...108

Tabla N° 31: pruebas unitarias 006...108

Tabla N° 32: pruebas unitarias 007...109

Tabla N° 33: pruebas unitarias 008...109

Tabla N° 35: pruebas de caso de uso 010...110

Tabla N° 36: definiciones de análisis y diseño...118

Tabla N° 37: abreviaturas de análisis y diseño...119

Tabla N° 38: Cronograma del proyecto piloto Ucumari...146

Figura N° 1: Categoría de procesos de MoProSoft...17

Figura N° 2: Flujo de trabajo de DMS...37

Figura N° 3: Estructura NTP para procesos del ciclo de vida de software...40

Figura N° 4: Flujo de Trabajo de Fase de Inicio de DMS...63

Figura N° 5: Flujo de Trabajo de Análisis y Diseño de DMS...64

Figura N° 6: Flujo de Trabajo de Fase de Construcción de DMS...65

Figura N° 7: Flujo de Trabajo de Fase de Integración y pruebas de DMS...66

Figura N° 8: Flujo de Trabajo de DMS de Fase de Cierre ...67

Figura N° 9: Diagrama del paquete de casos de uso de Reservas ...87

Figura N° 10: Diagrama del paquete de casos de uso de Booking...87

Figura N° 11: Diagrama del paquete de casos de uso de gestión de recursos...88

Figura N° 12: Diagrama del paquete de casos de uso de servicios comunes...88

Figura N° 13: prototipo de búsqueda de habitación...92

Figura N° 14: prototipo de reserva de habitación...93

Figura N° 15: prototipo reserva satisfactoria...93

Figura N° 16: prototipo de login de usuario...94

Figura N° 17: prototipo de alta de usuario...94

Figura N° 18: verificación y validación de ERS...98

Figura N° 19: verificación y validación de Casos de Uso...99

Figura N° 20: verificación y validación de Plan de pruebas de sistema...111

Figura N° 21: funcionalidad UC 2.17……… 113

Figura N° 22: funcionalidad 2 de UC 2.17...113

Figura N° 23: funcionalidad UC 5.1.2...114

Figura N° 24: funcionalidad UC 2.1.1...115

Figura N° 25: funcionalidad3 de UC 2.1.1...116

Figura N° 26: Verificación y validación de manual de usuario ...117

Figura N° 27: Arquitectura del sistema...120

Figura N° 28: Arquitectura lógica...121

Figura N° 29 Arquitectura de implementación...122

Figura N° 30: Diagrama de Clases Ucumari...123

Figura N° 31: Diagrama Entidad- Relación Ucumari...124

Figura N° 32: Verificación y validación de análisis y diseño ...126

Figura N° 33: Registro de Rastreo...127

Figura N° 35: Distribución de actividades de DMS según la autoevaluación...139

Figura Nº 35: Vista Arquitectónica Proyecto Ucumari ...118

Figura Nº 36: Componentes hacer reserva...130

Figura Nº 37: componentes Alta de Cliente...131

La presente tesis tiene como objetivo principal la “Implementación de MoProSoft en el proceso de desarrollo y mantenimiento de software de la empresa E-volution Hypermedia S.R.L.”

La empresa E-volution Hypermedia S.R.L. se dedica al desarrollo de aplicaciones Web

“software as a service” utilizando tecnología open source. La implementación de MoProSoft en el proceso de desarrollo y mantenimiento de software de la empresa, es una forma integrada e incremental para la mejora de las capacidades para el desarrollo de productos software en el tiempo y costos adecuados. Asimismo permitirá a la empresa y al proceso siguiente en el nivel jerárquico, denominado Administración de proyecto de Software (APE) medir el avance y tener proyecciones para próximos proyectos de software. Para la tesis se utilizado la metodología que propone el modelo MoProSoft para el proceso de DMS. En el transcurso encontraremos cinco capítulos los cuales los describiremos brevemente a continuación:

Capitulo I: Plan de Investigación, Identificación de la Realidad Problemática, Formulación del problema, Hipótesis y Objetivos. Lo cual nos da una visión general del desarrollo de la presente tesis.

Capitulo II: Marco Teórico, Encontramos la descripción de los conceptos más resaltantes y de los cuales se parte para el desarrollo.

Capitulo III: Metodología, La descripción de los pasos que involucra la metodología propuesta por el modelo MoProSoft.

Capitulo IV: Desarrollo, El desarrollo paso por paso de los ítems de la metodología mencionada en el capítulo III, en el que se encuentran los productos desarrollados en las etapas del ciclo de vida de software de MoProSoft y finalmente la evaluación de la adherencia del proceso de DMS en la Empresa E-volution Hypermedia S.R.L.

Capitulo V: Conclusiones y Recomendaciones, Como su nombre lo dice son las conclusiones a las que llega el presente autor de la tesis al termino de la misma y lo que se recomiendo para el buen uso de la metodología implementada.

This thesis has as its main objective the "Implementation of MoProSoft in the process of developing and maintaining software in the company E-volution Hypermedia SRL".

The company E-volution Hypermedia S.R.L. is dedicated to the development of Web applications “software as a service” using open source technology. The implementation of MoProSoft in the process of developing and maintaining software company, is integrated and incremental to improve capabilities for the development of software products in the appropriate time and costs. Also enable to the company and the process in the next tier, called Project Management Software (APE) measure progress and have projections for future software projects. For the thesis was used the methodology proposed by the MoProSoft model for the process of DMS. You will find five chapters which are described briefly below:

Chapter I: Research Plan, Issue Identification of Reality, Formulation of the problem, assumptions and objectives. This gives us an overview of the development of this thesis.

Chapter II: Theoretical Framework, found the description of the most outstanding and which is the base for development.

Chapter III: Methodology, description of the steps involved in the methodology proposed by the model MoProSoft.

Chapter IV: Development, step by step development of the methodology of the items mentioned in Chapter III, in which products are developed in stages of the life cycle of software from MoProSoft and finally assessing the adhesion process DMS in the Company E-volution Hypermedia S.R.L.

Chapter V: Conclusions and Recommendations, as its name says are the conclusions reached by the author of this thesis to finish it and to recommend what is the proper use of the methodology implemented.

PARTE PRIMERA: INTRODUCCIÓN CAPÍTULO I.PLAN DE INVESTIGACIÓN

1.1. EL PROBLEMA

1.1.1.Realidad Problemática

E-volution Hypermedia SRL, es una empresa dedicada al sector del software, con una orientación clara a desarrollar soluciones basadas en Software Libre la cual ha logrado posicionarse en el ámbito local.

Debido a ser la única empresa en provincias con esta clara orientación.

En la Actualidad, se viene llevando a través del convenio con Competisoft, la implementación del modelo de calidad para Desarrollo de software MoProSoft. Dicho modelo que ha sido creado en México y es norma en ese país (NMX-059/01-NYCE-2005), es dirigido especialmente para PYMES de desarrollo de software, proveyendo un modelo robusto y de varios niveles de madurez.

Sin embargo a pesar de que la empresa ya ha empezado un primer ciclo de madurez desde el mes de agosto de 2007, el perfil de las capacidades de los procesos aun no han alcanzado los objetivos que se tenían para una primera evaluación. Tal es así que el proceso de DMS (Desarrollo y Mantenimiento de Software) tenía establecido la meta de 85% con respecto al nivel 1, del cual se logró el 71.1%, lo que implica que está “Ampliamente Alcanzado”, según la ISO/IEC 15504, pero lo ideal hubiera sido que el proceso este “Completamente Alcanzado”.

La ausencia de proyectos o un proyecto piloto completo en la empresa, que permita probar las mejoras en formatos y procedimientos con la implementación de buenas practicas para el proceso de desarrollo de software, hacen que al evaluarse el perfil de capacidades del proceso de DMS, este no cumpla con la calificación esperada para el primer ciclo de mejora. A su vez, los instrumentos y mejoras incorporados para las actividades del proceso de DMS no han logrado que se pueda cumplir con un proyecto en tiempo promedio, 5 meses, que es lo que se estima

para proyectos medianos en la empresa; además de los sobrecostos que esto ocasiona.

En este sentido se propone la realización de un 2do ciclo de mejora siguiendo el modelo de calidad de procesos MoProSoft para la mejora del proceso de DMS y así elevar la capacidad del proceso al nivel 2. Se ha designado como piloto el proyecto de Gestión Hotelera onDemand llamado desde ahora UCUMARI. De esta manera se podrá verificar la mejora de la empresa en el proceso de DMS a través de este proyecto.

1.1.2.Antecedentes

El año 2007 a través del marco de trabajo del convenio de COMPETISOFT y la PUCP, se han venido realizando evaluaciones para los ciclos de mejora de los procesos en el grupo de Empresas de Desarrollo Software del convenio de COMPETISOFT. En tal sentido así como E-volution Hypermedia SRL., varias empresas en la ciudad de Lima han participado del proyecto.

Existen antecedentes también en México, donde MoProSoft es norma mexicana NMX-I-059/02-NYCE-2005. Se tiene así las siguientes empresas:

En el país de México [URL 01]:

• [URL 02] http://www.magnabyte.com

Magnabyte – Mayorista de Equipos Informáticos.

Magnabyte tiene el Nivel 2 de Madurez de Procesos según MoProSoft.

• [URL 03] http://www.expert.com.mx/

Expert - Sistemas Computacionales S.A.

Expert - tiene el Nivel 1 de Madurez de Procesos según MoProSoft.

• [URL 04] http://www.softtek.com/mexico/

Valores Corporativos Softtek S.A. – servicios de TI nearshore Softtek - tiene el Nivel 2 de Madurez de Procesos según MoProSoft.

• [URL 05] http://www.psycowin.com/

PSW Global Solutions - Herramientas de Conocimiento y Tecnología enfocados a la consolidación del Desarrollo Organizacional de Clase Mundial.

PSW - tiene el Nivel 1 de Madurez de Procesos según MoProSoft.

Información de Empresas con nivel 3, 4 o 5 no se encuentran disponibles, de igual manera información de las empresas que están implementando MoProSoft en Lima, mantienen su información en privado teniendo un Alias como nombre, tales como: Empresa Alfa, Empresa Beta, etc. De esta manera E-volution Hypermedia es llamado Empresa Gamma.

La existencia de proyectos académicos referentes al tema aún están en realización con respecto al primer ciclo de mejora del proyecto Competisoft, por lo que la universidad PUCP no actualiza aún la información en su biblioteca virtual.

El proyecto piloto para la implementación de MoProSoft es una aplicación Web onDemand para reservas hoteleras; para tal fin se encontró proyectos académicos referentes al tema:

• [TES 01] LAM PEÑA, Alana

“Desarrollo de un sistema Web de reservaciones online para mejorar la atención al cliente en el hotel Las Terrazas de Trujillo”

UPN, 2007

• [TES 02] FACUNDO TORRES, Freddy

“Implementación de un sistema de información web para el Hotel Torre Blanca de Trujillo aplicando tecnología .Net dentro del marco Microsoft Solution Framework (MSF)” UPN, 2006

1.1.3.Formulación Del Problema

¿De que manera se podrá mejorar las capacidades el proceso de Desarrollo y Mantenimiento de Software de la Empresa de Software E- volution Hypermedia S.R.L.?

1.2. HIPÓTESIS

La implementación del modelo MoProSoft permitirá mejorar las capacidades del proceso de Desarrollo y Mantenimiento de Software de la Empresa E- volution Hypermedia S.R.L.

1.2.1.Variable independiente

1.2.2.Variable dependiente

Capacidades del proceso de desarrollo y mantenimiento de software de la empresa E-volution Hypermedia S.R.L

1.3. OBJETIVOS

1.3.1.Objetivo General

Implementar el modelo MoProSoft para mejorar las capacidades del proceso de Desarrollo y Mantenimiento de Software de la Empresa E- volution Hypermedia S.R.L.

1.3.2.Objetivos Específicos

• Asegurar que el proyecto este alineado con los objetivos y estrategias de la organización, como el de lograr que los entregables se realicen utilizando herramientas de software libre.

• Desarrollar el proceso de DMS, implementando las buenas prácticas del modelo MoProSoft al nivel 2 de capacidad de procesos.

• Evaluar la adherencia del proceso de DMS al nivel 2 de capacidad de MoProSoft.

• Realizar informe de la implementación del proceso de DMS.

1.4. DISEÑO DE CONTRASTACIÓN

Para la contrastación de la hipótesis se utilizará el Método de diseño de Sucesión, llamado también Pre – Test / Post – Test o en Línea. Este modelo trata de superar las limitaciones de un anterior, en cuanto a identificar una base de comparación o línea de referencia.

Veamos en qué consiste:

• Una medición de la variable dependiente previa a la aplicación de la variable independiente (Pre-test)

• La aplicación de la variable independiente

• La nueva medición de la variable dependiente, después de la aplicación de la variable independiente (Post-test)

Formalización:

M1 X M2

Donde:

Al final se establecerán las diferencias entre M2 y M1, para determinar si hay mejoramiento o no en los resultados obtenidos según nuestros indicadores:

Ítem Indicador Instrumento Operatividad

1 Nivel de cumplimiento de las actividades del proceso.

Checklist de verificación de actividades

Lograr que los productos de salida sean consistentes con los productos e entrada en cada fase de un ciclo de desarrollo

2 Cantidad de productos validados y verificados

Verificación de productos generados en la configuración de software

Sustentar la realización de ciclos posteriores o proyectos de mantenimiento futuros 3 Logro de las actividades

según lo establecido en el plan de desarrollo

Verificación del plan de desarrollo actual

Llevar a cabo las actividades de las fases de un ciclo

Tabla N° 1: Indicadores de medición del proceso Fuente: Elaboración propia

M1 : Problema antes de la implementación del modelo MoProSoft para DMS

X : Implementación del modelo MoProSoft para DMS

M2 : Problema después de la implementación del modelo MoProSoft para DMS

1.4.1.Población

La población en estudio está constituida por las actividades del proceso de DMS de MoProSoft donde la población de actividades para DMS es de 67.

1.4.2.Muestra

• Error Muestral.- Es una medida de la variabilidad de las estimaciones de muestras repetidas en torno al valor de la población, nos da una noción clara de hasta dónde y con qué probabilidad una estimación basada en una muestra se aleja del valor que se hubiera obtenido por medio de un censo completo.

• Nivel de Confianza.- Probabilidad de que la estimación efectuada se ajuste a la realidad.

• Varianza Poblacional.- Cuando una población es más homogénea la varianza es menor y el número de entrevistas necesarias para construir un modelo reducido del universo, o de la población, será más pequeño.

En la presente investigación en donde la población presenta divisiones en las fases de desarrollo, la mejor forma de realizar el muestreo es a través del muestreo por estratos en donde los elementos muestrales tienen la misma probabilidad de ser escogidos.

Para determinar la muestra se usa la siguiente formula:

q p z e N

q p z n N

×

× +

×

−

×

×

= × ₂² ₂

)

1

(

En donde:

n Muestra

N Tamaño de la población 67 67

Z Confianza 95% 1,96

p Probabilidad de éxito 50% 0.50

q Probabilidad de fracaso 50% 0.50

E Precisión o máximo Error aceptado 5% 0.05

n = 67 * 1.96^2 * 0.50 *0.50 66 * 0.05^2 + 1.96^2 + 0.50 *0.50

n = 64.3468 4.2566

n = 15.11694779

n = 15

Realizando el redondeo respectivo y adicionando un plus de 10 % tenemos:

n = 16.62796846 * 1.1

n = 16.62864257

n = 17

Muestra por fases del proceso:

Fases actividades % Muestra

Fase de Inicio 2 2.9 0

Fase de Requerimientos 18 26.8 5

Fase de Análisis y Diseño 16 23.8 4

Fase de Construcción 10 14.9 3

Fase de pruebas e integración 16 23.8 4

Fase de Cierre 5 7.4 1

Total 67 100.00% 17

Tabla N° 2: Proporción de muestras por fases Fuente: Elaboración propia

La muestra por fases se obtiene de multiplicar el porcentaje relativo de cada fase por el total de muestras a tomar, lo cual nos indica el número de muestras que tendremos que tomar para cada caso.

Una vez obtenido las muestra de la población de actividades de DMS, se procederá a la aplicación de encuestas checklist para la verificación del cumplimiento de actividades, de manera que pueda medirse la adherencia del proceso de DMS en la empresa.

PARTE SEGUNDA: MATERIALES Y MÉTODOS CAPITULO II.MARCO TEÓRICO

2.1. COMPETISOFT 2.1.1.Definición [01]

COMPETISOFT, COMPETISOFT 506PI287- Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica, financiado por CYTED con el código 3789.

El Programa CYTED se define como un programa internacional de cooperación científica y tecnológica multilateral, de ámbito iberoamericano, cuyo objetivo principal contribuir al desarrollo de la Región Iberoamericana mediante el establecimiento de mecanismos de cooperación entre grupos de investigación de las Universidades, Centros de I+D y Empresas innovadoras de los países iberoamericanos, que pretenden la consecución de resultados científicos y tecnológicos transferibles a los sistemas productivos y a las políticas sociales.

La primera versión del trabajo en conjunto es concebido para convertirse en un referente para todas las PYMES dedicadas al sector informático de Iberoamérica. En su desarrollo han participado más de 100 investigadores de 24 entidades y 13 países de ambos lados del Atlántico.

2.1.2.Objetivos del proyecto Competisoft [01]

El proyecto COMPETISOFT tiene el siguiente objetivo general:

• Incrementar el nivel de competitividad de las PYMES Iberoamericanas productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre la que

establecer un mecanismo de evaluación y certificación de la industria del software reconocido en toda Iberoamérica.

Para lograr ese objetivo general se plantearon los siguientes objetivos específicos:

• Desarrollar un Marco Metodológico común ajustado a la realidad socio-económica de las PYMES iberoamericanas, orientado a la mejora continua de sus procesos. Este Marco compuesto por un Modelo de Procesos, un Modelo de Capacidades y un Método de Evaluación, será validado mediante su aplicación controlada, en empresas y organizaciones de diferentes países de la región CYTED.

• Difundir la cultura de la mejora de procesos en el sector informático iberoamericano y más específicamente formar, tanto a investigadores y/o docentes universitarios (formación de formadores) como a profesionales de un buen número de PYMES productoras de software, mediante los cursos que se organizaran en este proyecto CYTED y mediante la difusión -a través de la Web del proyecto- de los materiales de formación que se elaborarán; así como mediante la supervisión y desarrollo de tesis de postgrado para estudiantes y docentes de la región.

• Incidir en los diferentes organismos de normalización y certificación de los países iberoamericanos, para que asuman que los principios metodológicos objeto de este proyecto CYTED pueden ser la base para establecer un mecanismo común y mutuamente reconocido de evaluación y certificación de la industria del software Iberoamericana.

2.1.3.Requerimientos [01]

Proporcionar a la industria de software iberoamericana, que en su gran mayoría es pequeña y mediana, un modelo basado en las mejores prácticas internacionales con las siguientes características:

• Fácil de entender

• Fácil de aplicar

• No costoso en su adopción

• Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 o CMM®1 V1.1

2.1.4.Alcances [01]

COMPETISOFT está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software.

Las organizaciones, que no cuenten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo a sus necesidades. Mientras que las organizaciones, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir.

2.1.5.Criterios Empleados [01]

Para la elaboración de COMPETISOFT, fueron aplicados los siguientes criterios:

a. Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software (Alta Dirección, Gestión y Operación).

b. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización.

c. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización.

d. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software.

e. Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos.

f. Integrar los elementos para la administración de proyectos en un sólo proceso.

g. Integrar los elementos para la ingeniería de productos de software en un solo marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración).

h. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas.

i. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMMI V.1.1. Usar como marco general ISO/IEC 15504 - Software Process Assesment e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK, SWEBOK y otros más especializados.

j. Crear un método de para evaluar los procesos software del modelo de procesos descrito en la parte I (MoProSoft)

k. Basar el modelo de evaluación en los principios de las normas internacionales ISO/IEC 15504-2 Performing an assesment e ISO/IEC 15504-4 Guiance on performing.

l. La prioridad más alta es satisfacer las necesidades de mejora es a través de la entrega temprana y continua de mejoras significativas al proceso de desarrollo. Entregar con frecuencia mejoras del proceso de software (desde 2 hasta 6 meses)

m. No hay requisitos de mejora totalmente estables por parte de la organización. Por ello, el diagnóstico es una actividad continua. Aún así, requisitos de mejora que surjan deberán ser priorizados y acogidos en la medida en que sea factible realizarlos.

n. Un programa de mejora debe basarse en la colaboración efectiva entre los consultores, grupo de mejora, la alta gerencia, el grupo de desarrollo, el grupo SQA, marketing y demás dependencias relacionadas con el proyecto SPI. La forma más eficiente y efectiva de comunicar información dentro de un equipo de mejora es mediante la conversación cara a cara.

o. Construir proyectos en torno a individuos motivados hacia la mejora de procesos individuales, grupales y organizacionales. Darles la oportunidad y el respaldo que necesitan y procurarles confianza para que realicen las tareas. PMCompetiSoft promueve la conformación efectiva de los grupos propuestos por su infraestructura, se preocupa por la calidad del trabajo humano a realizar.

p. Promover el desarrollo sostenido. El trabajo deberá ser continuo e indefinido. La madurez del proceso, como el desempeño promedio de los proyectos, debe ser la medida primaria y liviana de la mejora del progreso. Las mediciones base para medir el desempeño son la productividad y la calidad.

q. Promover una infraestructura técnica y de gestión, adecuada para soportar la mejora del proceso. PMCompetiSoft promueve la conformación de una infraestructura organizacional dinámica, basada en objetivos, no en estrategias de control.

r. Promover el aprendizaje continuo como una disciplina clave. El objetivo de esta disciplina es que permita conocer el trabajo, reflexionar acerca de este y ajustar el trabajo a través de iteraciones cortas y concisas.

2.1.6.Enfoque basado en procesos [01]

El desarrollo y mantenimiento de software se lleva a cabo a través de una serie de actividades realizadas por equipos de trabajo. La Ingeniería de Software se ha dedicado a identificar las mejores prácticas para realizar estas actividades

Recopilando las experiencias exitosas de la industria de software a nivel mundial. Estas prácticas se han organizado por áreas de aplicación, y se han dado a conocer como áreas clave de procesos, en caso de CMMI, o como procesos de software en ISO/IEC 15504.

El modelo que se propone está enfocado en procesos y considera los tres niveles básicos de la estructura de una organización que son: la Alta Dirección, Gestión y Operación. El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua.

2.2. MOPROSOFT 2.2.1.Definición [02]

Modelo de Procesos nombrado MoProSoft, surgió por iniciativa de la Secretaria de Economía de México con la contribución de académicos y empresarios mexicanos encabezados por la Dra. Hanna Oktaba, lo que se pretende con MoProSoft es la creación de un modelo de procesos especialmente para la industria mexicana de TI que en su mayoría está compuesta por PYMES (empresas con menos de 100 empleados).

Este modelo está fundamentado en ISO 9000, SW-CMM y el reporte técnico ISO/IEC TR 15504, con lo cual la adopción de este modelo habilita la obtención de un certificado ISO 9000 y reduce la brecha para la obtención de un certificado como CMMI nivel 2.

El modelo de procesos MoProSoft está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software. Las organizaciones, que no cuenten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo a sus necesidades. Mientras que las organizaciones, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir.

El propósito de la actual norma mexicana (NMX-059/01-NYCE-2005) es presentar un Modelo de Procesos para la Industria de Software (MoProSoft) en que fomente la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permitirá elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad.

2.2.2.Criterios empleados [02]

a. Para la elaboración del modelo de procesos MoProSoft, fueron aplicados los siguientes criterios:

b. Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software (Alta Dirección, Gestión y Operación).

c. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización.

d. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización.

e. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software.

f. Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos.

g. Integrar los elementos para la administración de proyectos en un sólo proceso.

h. Integrar los elementos para la ingeniería de productos de software en un solo marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración).

i. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos,

incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas.

j. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM! V.1.1. Usar como marco general ISO/IEC 15504 - Software Process Assesment e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK, SWEBOK y otros más especializados.

2.2.3.Enfoque basado en procesos [02]

El desarrollo y mantenimiento de software se lleva a cabo a través de una serie de actividades realizadas por equipos de trabajo. La Ingeniería de Software se ha dedicado a identificar las mejores prácticas para realizar estas actividades recopilando las experiencias exitosas de la industria de software a nivel mundial. Estas prácticas se han organizado por áreas de aplicación, y se han dado a conocer como áreas clave de procesos, en caso de CMM, o como procesos de software en ISO/IEC 15504.

El modelo que se propone está enfocado en procesos y considera los tres niveles básicos de la estructura de una organización que son: la Alta Dirección, Gestión y Operación. El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua. Se tiene así:

Figura N° 1: Categoría de procesos de MoProSoft Fuente: [URL 02]

2.2.4.Uso del modelo de procesos [02]

Para usar este modelo en una organización que no cuenta con procesos establecidos ni documentados se debe generar una instancia de cada uno de los procesos, tomando en cuenta las siguientes consideraciones:

• Definir las metas cuantitativas de acuerdo a las estrategias de la organización.

• Revisar los nombres de los roles y los productos (entradas, salidas o internos) y en su caso sustituirlos por los que se acostumbran en la organización.

• Para cada producto definir el estándar de documentación cumpliendo con las características mencionadas en la descripción del producto.

• Definir los recursos de infraestructura de cada proceso.

• Analizar si las mediciones de cada proceso son aplicables dentro del contexto de organización y en su caso modificarlas.

• Usar las guías de ajuste para adecuar el proceso en función de las estrategias de la organización.

• Posteriormente sustituir las guías de ajuste del modelo por las guías que apliquen en la organización.

• Para usar este modelo en una organización que cuente con procesos establecidos o documentados, se debe establecer la correspondencia entre estos procesos entre estos procesos y el modelo MoProSoft para identificar las coincidencias y discrepancias.

La organización debe analizar las discrepancias y planificar las actividades de ajuste de los procesos para lograr la cobertura completa de MoProSoft.

2.2.5.Implementación y mejora continua [02]

La organización debe establecer la estrategia de implantación de los procesos definidos. Puede decidir probarlos en proyectos piloto o implantarlos al mismo tiempo en toda la organización.

Con el transcurso del tiempo, los procesos deben evolucionar con base a las sugerencias de mejora e ir alcanzando los objetivos del plan estratégico de la organización con metas cuantitativas cada vez más

ambiciosas. De esta manera la organización puede ir logrando la madurez a través de la mejora continua de sus procesos.

2.2.6.Niveles de capacidad [02]

El objetivo de presentar la versión de MoProSoft coloreada por niveles de capacidades es ofrecer una guía que oriente a los que quieren adoptar este modelo. Las partes coloreadas sugieren un orden de la implementación de las prácticas de los procesos de MoProSoft partiendo de las prácticas básicas, correspondientes a nivel 1, e incorporando las prácticas que corresponden a los niveles más avanzados.

La siguiente tabla refleja la correspondencia entre los niveles de capacidad de procesos y los colores del marcador

Nivel Capacidad de Proceso Color

1 Realizado amarillo

2 Gestionado azul

3 Establecido verde

4 Predecible rosa

5 Optimizado ninguno

Tabla N° 3: Guía coloreada por niveles de capacidad Fuente: [02]

2.3. PROCESO DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE

2.3.1.Definición general del proceso [02]

2.3.1.1.Propósito

El propósito de Desarrollo y Mantenimiento de Software es la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevo o modificado cumpliendo con los requerimientos especificados.

2.3.1.2.Descripción

El proceso de Desarrollo y Mantenimiento de Software se compone de uno o más ciclos de desarrollo. Cada ciclo está compuesto de las siguientes fases:

a.

Revisión del Plan de Desarrollo por los miembros del Equipo de Trabajo para lograr un entendimiento común del proyecto y para obtener el compromiso de su realización

b.

Conjunto de actividades cuya finalidad es obtener la documentación de la Especificación de Requerimientos y Plan de Pruebas de Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.

c.

Conjunto de actividades en las cuales se analizan los requerimientos especificados para producir una descripción de la estructura de los componentes de software, la cual servirá de base para la construcción. Como resultado se obtiene la documentación del Análisis y Diseño y Plan de Pruebas de Integración

d.

Conjunto de actividades para producir Componente(s) de software que correspondan al Análisis y Diseño, así como la

realización de pruebas unitarias. Se obtienen el (los) Componente(s) de software probados

e.

Conjunto de actividades para integrar y probar los componentes de software, basados en los planes de Pruebas de Integración y de Sistema, con la finalidad de obtener el Software que satisfaga los requerimientos especificados.

Como resultado se obtiene el producto de Software probado y documentado

f.

Integración final de la Configuración de Software generada en las fases para su entrega. Identificación y documentación de las Lecciones Aprendidas. Generación del Reporte de Mediciones y Sugerencias de Mejora.

2.3.1.3.Objetivos

O1 Lograr que los productos de salida sean consistentes con los productos de entrada en cada fase de un ciclo de desarrollo mediante las actividades de verificación, validación o prueba.

O2 Sustentar la realización de ciclos posteriores o proyectos de mantenimiento futuros mediante la integración de la Configuración de Software del ciclo actual.

O3 Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del Plan de Desarrollo actual.

2.3.1.4.Indicadores

I1 (O1) En cada fase de un ciclo se efectúan todas las actividades de verificación, validación o prueba, así como las correcciones correspondientes.

I2 (O2) La Configuración de Software está integrada por los productos generados en el ciclo.

I3 (O3) Las actividades planificadas en cada fase de un ciclo se realizan conforme a lo establecido en el Plan de Desarrollo.

2.3.1.5.Metas Cuantitativas

Valor numérico o rango de satisfacción por indicador.

2.3.1.6.Responsabilidad y Autoridad

• Responsable:

Responsable de Desarrollo y Mantenimiento de Software

• Autoridad:

Responsable de Administración del Proyecto Específico

2.3.1.7.Procesos relacionados

• Administración de Proyectos Específicos

• Conocimiento de la organización

2.3.1.8.Entradas

Nombre Fuente

Plan de Desarrollo

• Descripción del producto

• Entregables

• Proceso Especifico

• Equipo de Trabajo

• calendario

Administración de Proyectos Específicos

Tabla N° 4: Entradas del Proceso de DMS Fuente: [02]

2.3.1.9.Salidas

Nombre Descripción Destino

Especificación de

Requerimientos Se compone de una introducción y una descripción de requerimientos Introducción:

Descripción general del software y su uso en el ámbito de negocio del cliente.

Descripción de requerimientos:

* Funcionales:

Necesidades establecidas que debe satisfacer el software cuando es usado en condiciones específicas.

Las funcionalidades deben ser adecuadas, exactas y seguras.

* Interfaz con usuario:

Definición de aquellas características de la interfaz de usuario que permiten que el software sea fácil de entender, aprender, que genere satisfacción y con el cual el usuario pueda

desempeñar su tarea

eficientemente. Incluyendo la APE

descripción del prototipo de la interfaz.

* Interfaces externas:

Definición de las interfaces con otro software o con hardware.

* Confiabilidad:

Especificación del nivel de desempeño del software con respecto a la madurez, tolerancia a fallas y recuperación.

* Eficiencia:

Especificación del nivel de desempeño del software con respecto al tiempo y a la utilización de recursos.

* Mantenimiento

Análisis y Diseño Este documento contiene la descripción textual y Administración de grafica de la estructura de los componentes de Proyectos Específicos software. El cual consta de las siguientes partes:

Arquitectónica:

Contiene la estructura interna del sistema, es decir la descomposición del sistema en subsistemas. Así como la identificación de los componentes que integran los subsistemas y las relaciones de interacción entre ellos.

Detallada:

Contiene el detalle de los componentes que permita de manera evidente su construcción y prueba en el ambiente de programación.

APE

Componente Conjunto de unidades de código

relacionadas. APE

Software Sistema de software, destinado a un cliente o usuario, constituido por componentes agrupados en subsistemas, posiblemente anidados.

APE

Configuración

del software Conjunto consistente de productos de software, que incluye:

• Especificación de Requerimientos

• Análisis y Diseño

• Software

• Registro de Rastreo

• Plan de Pruebas de Sistema

• Reporte de Pruebas de Sistema

• Plan de Pruebas de Integración

• Reporte de Pruebas de Integración

• Manual de Usuario

• Manual de Operación

• Manual de Mantenimiento

APE

Manual de

usuario Documento electrónico o impreso que describe la forma de uso del software con base a la interfaz del usuario. Éste deberá ser redactado en términos comprensibles a los usuarios.

APE

Manual de

operación Documento electrónico o impreso que contenga la información indispensable para la instalación y administración del software, así como el ambiente de operación (sistema operativo, base de datos, servidores, etc.). deberá ser para el personal responsable de la operación.

APE

Manual de

Mantenimiento Documento electrónico o impreso que describe la Administración de Configuración de Software y el

APE

desarrollo y pruebas (compiladores, herramientas de análisis y diseño, construcción y pruebas). Este deberá ser redactado en términos comprensibles al personal de mantenimiento.

Reporte de

Actividades Registro periódico de actividades, fechas de inicio y fin, responsables y mediciones, tales como:

• tiempo de producción, de corrección, de verificación y de validación,

• defectos encontrados en verificación, validación o prueba,

• tamaño de productos.

APE

Registro de

Rastreo Relación entre los requerimientos, elementos análisis y diseño, componentes y planes de pruebas.

APE

Plan de pruebas

de sistema Registro de participantes, fecha, lugar, duración y de defectos encontrados.

APE

Plan de pruebas

de integración Descripción que contiene:

* El orden de integración de los componentes o subsistemas, guiado por la parte arquitectónica del Análisis y Diseño.

* Pruebas que se aplicarán para verificar la interacción entre los componentes.

APE

Tabla N° 5: Salidas del Proceso de DMS Fuente: [02]

2.3.1.10.Productos Internos

Nombre Descripción

Reporte (s) de Verificación

Registro de participantes, fecha, lugar, duración y defectos encontrados.

Reporte (s) de Validación Registro de participantes, fecha,

lugar, duración y defectos encontrados.

Tabla N° 6: Productos Internos del Proceso de DMS

Fuente: [02]

2.3.2.Practicas [02]

2.3.2.1.Roles, Involucrados y Capacitación

Rol Abreviatura Capacitación

Responsable de

Administración del proyecto especifico

RAPE Capacidad de Liderazgo con experiencia en la toma de decisiones, planificación

estratégica, manejo de personal y desarrollo de software

Responsable de Desarrollo y Mantenimiento de Software

RDM Conocimiento y Experiencia en el desarrollo y mantenimiento de software

Analista AN Conocimiento y experiencia en la obtención, especificación y análisis de los requerimientos

Diseñador de Interfaz de usuario

DU Conocimiento en diseño de interfaces de usuario y criterios ergonómicos

Diseñador DI Conocimiento y experiencia en el diseño de la estructura de los componentes de software

Programador PR Conocimientos y/o experiencia en la programacion, integracion y

pruebas unitarias Responsable

de pruebas RPU Conocimiento y experiencia en la planificación y realización de pruebas de integracion y de sistema Revisor RE Conocimiento en las técnicas de

revisión y experiencia en el desarrollo y mantenimiento de software

Responsable

de manuales RM Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software

Equipo de

Trabajo ET Conocimiento y experiencia deacuerdo a su rol

Cliente CL Interpretación del estándar de la especificación de requerimientos

Usuario US Ninguno

Tabla N° 7: Roles del Equipo de Trabajo del Proceso de DMS Fuente: [02]

2.3.2.2.Actividades

Rol Descripción

A.1.Realización de la Fase de Inicio (O3)

ET A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para lograr un entendimiento común y obtener su compromiso con el proyecto.

RDM A1.2. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.

A.2. Realización de Fase de Requerimientos (O1,O3) RDM

AN

A.2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.

AN CL US DU

A2.2. Documentar o modificar la Especificación de Requerimientos.

• Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requerimientos.

• Analizar los requerimientos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto.

• Elaborar o modificar el prototipo de la interfaz con el usuario.

• Generar o actualizar la Especificación de Requerimientos.

RE A2.3. Verificar la Especificación de Requerimientos AN

DU

A2.4.Corregir los defectos encontrados en la Especificación Requerimientos con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

CL US RPU

A2.5. Validar la Especificación de Requerimientos

AN DU

A2.6. Corregir los defectos encontrados en la Especificación de Requerimientos con base en el Reporte de Validación y obtener la aprobación de las correcciones

RPU A2.7. Elaborar o modificar Plan de Pruebas de Sistema.

AN

RE A2.8. Verificar el Plan de Pruebas de Sistema (Ver2).

RPU A2.9. Corregir los defectos encontrados en el Plan de Pruebas de Sistema con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

RM A2.10. Documentar la versión preliminar del Manual de Usuario o modificar el manual existente.

RE A2.11. Verificar el Manual de Usuario (Ver3).

RM A212. Corregir los defectos encontrados en el Manual de Usuario con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

RDM A2.13. Incorporar Especificación de Requerimientos, Plan de pruebas del sistema y Manual de usuario como linea base a la configuración del software

RDM A2.14. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsables por actividad

A.2. Realización de Fase de Análisis y Diseño (O1,O3) RDM

AN DI

A3.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.

AN DI DU

A3.2. Documentar o modificar el Análisis y Diseño:

• Analizar la Especificación de Requerimientos para generar la descripción de la estructura interna del sistema y su descomposición en sub. sistemas, y éstos a su vez en componentes, definiendo las interfaces entre ellos.

• Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la Especificación de Requerimientos de forma que se puedan prever los recursos para su implementación.

• Describir el detalle de los componentes que permita su construcción de manera evidente.

• Generar o actualizar el Análisis y Diseño.

• Generar o modificar el Registro de Rastreo.

RE A3.3. Verificar el Analisis y Diseno y el registro de Rastreo (Ver4)

AN A3.4.Corregir los defectos encontrados en el Análisis y

DI DU

Diseño y en el Registro de Rastreo con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

CL RPU

A3.5. Validar el Analisis y Diseno (Val2) AN

DI DU

A3.6. Corregir los defectos encontrados en el Análisis y Diseño con base en el Reporte de Validación y obtener la aprobación de las correcciones.

RPU A3.7.Elaborar o modificar Plan de Pruebas de Integración.

RE A3.8. Verificar el Plan de Pruebas de Integración (Ver5).

RPU A3.9. Corregir los defectos encontrados en el Plan de Pruebas de Integración con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

RMD A3.10. Incorporar A y D, Registro de Rastreo y Plan de pruebas de Integracion como linea base a la configuracion del software

A3.11.

.

A.2. Realización de Fase de Construcción (O1,O3)

RDM A4.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.

PR A4.2. Construir o modificar el(los) Componente(s) de software:

• Implementar o modificar Componente(s) con base a la parte detallada del Análisis y Diseño.

• Definir y aplicar pruebas unitarias para verificar que el funcionamiento de cada componente esté acorde con la parte detallada del Análisis y Diseño.

• Corregir los defectos encontrados hasta lograr pruebas unitarias exitosas (sin defectos).

• Actualizar el Registro de Rastreo, incorporando los componentes construidos o modificados.

RE A4.3. Verificar el registro de Rastreo (Ver6)

PR A4.4.Corregir los defectos encontrados en el Registro de Rastreo con base en el Reporte de Verificación y obtener la aprobación de las correcciones.

RDM A4.5. Incorporar Componentes y Registro de Rastreo como líneas base a la Configuración de Software.

RDM A4.6 Elaborar reporte de Actividades, registrando las