You are on page 1of 91

Universidad Peruana de Ciencias Aplicadas Facultad de Ingeniería Carrera de Ingeniería de Software

ARQUITECTURA PARA EL SOFTWARE DE ASEGURAMIENTO DE CALIDAD DE LOS PROYECTOS DE SOFTWARE BAJO EL MARCO DE CMMI: GESTIÓN DE PROCESOS Y METODOLOGÍAS

Trabajo de tesis presentado para optar el Título Profesional de Ingeniero de Software

Autores: Marisa Zacarías Barrutia Ángel Sueyoshi Zamami Asesor: Ing. Ilver Anache Pupo

Lima, 2008 Perú

A las personas que creyeron que todo en la vida se consigue en base a la perseverancia.

INTRODUCCIÓN El presente trabajo tiene como finalidad mostrar la arquitectura de software del subsistema de procesos y metodologías (GPM), así como mostrar la relación que existe entre los demás subsistemas los cuales son en su mayoría modelo de calidad de software (SGMCS),

subsistema de proyectos de software (GPS), subsistema de planeamiento SCAMPI (PPSCAMPI) y subsistema de ejecución de SCAMPI (EP-SCAMPI).

Se pretende mostrar un modelo de arquitectura de software para registrar no solo las metodologías sino los modelos de calidad CMMI, el registro de los proyectos de software y los modelos de planeamiento y ejecución de SCAMPI.

En el subsistema de procesos y metodologías se presentará la ejecución y administración del proyecto, los requerimientos funcionales, la arquitectura del software y finalmente las pruebas realizadas para el subsistema.

Finalmente se presentará los casos de uso y casos de prueba identificados en los requerimientos funcionales.

Realizar el matching de las metodologías registradas con los niveles de CMMI solicitados. Administrar las actualizaciones de las metodologías de software.Los objetivos del proyecto son los siguientes: • • • Proveer de un mecanismo de registro de metodologías de software. • Proveer a los subsistemas de SCAMPI y Proyectos de Software la información procesada de las metodologías con los niveles de CMMI. • Administrar las actualizaciones de las metodologías de software. .

.................................................................................................................. BIBLIOGRAFÍA......... FUNDAMENTACIÓN TEÓRICA.....................78 5......................................................................................................................10 CAPITULO 2.......................... PRUEBAS DEL SISTEMA..56 4..........................................................................................................................................................................................................................................................................................................90 ................ PRODUCTO..................................18 2............................................................................ DISEÑO ARQUITECTÓNICO..................................28 3.............................................................................................28 CAPITULO 4................................................................................................................ GESTIÓN DEL PROYECTO............................................................................................................................................................................. CONCLUSIONES Y RECOMENDACIONES........................18 CAPITULO 3..89 7...........................................................................................................78 6.........INDICE DE CONTENIDO CAPITULO 1..............................................................................................................................................................................................10 1..............................................................................56 CAPITULO 5....................................................

........52 Figura 3...................................................38 Figura 3...30 – Pantalla Buscar Rol.................................29 – Pantalla Buscar Proceso.............................46 Figura 3........34 Figura 3..........15 Figura 3......................................................................................................2 ...............Diagrama de Caso de Uso Especialista en Metodologías (Rol)...................49 Figura 3........................................50 Figura 3..........5 .....47 Figura 3....................34 – Pantalla Componentes en Relación a CMMI..Diagrama de los subsistemas......................37 Figura 3.25 – Pantalla Consultar Historial de Tabla de Procesos.............................................................44 Figura 3.................................Diagrama de Caso de Uso Especialista en Metodologías (Proceso).............................23 – Pantalla Asignación Niveles CMMI a Metodología........24 – Pantalla Asignación Niveles CMMI a Componente...............................................45 Figura 3...............................32 – Pantalla Buscar Componente....................................................................................33 Figura 3................................................................10 .......................................................12 Figura 1.................Fases e Iteraciones de la Metodología RUP........20 – Pantalla Mantenimiento de Procesos..........Metodología Extreme Programming........................1 ..........................................15 ..................48 Figura 3.............................................13 ....................................35 – Pantalla Componentes en Relación a CMMI.............................................................................53 Figura 3............................12 ..................................................................................................................................................................31 – Pantalla Buscar Tipo Componente.......................................................................41 Figura 3................................................................................................................Diagrama de servicios entre subsistemas....................40 Figura 3..................32 Figura 3................................57 Figura 4......8 ...............3 ...................................48 Figura 3......................35 Figura 3...................37 ......................................................................Diagrama de Caso de Uso Especialista en Metodologías (Componente)...............................................................................6 .Diagrama de Caso de Uso Especialista en Metodologías (Fase).........................58 Figura 4..........11 ....39 .................................Diagrama de Arquitectura General del Sistema..................................................................9 .......................................35 Figura 3..................38 ....19 – Pantalla Mantenimiento de Fases................47 Figura 3.............49 Figura 3......51 Figura 3............43 Figura 3................................................................16 – Pantalla Mantenimiento de Metodologías...................Diagrama de Arquitectura de la Aplicación...........................................................................36 Figura 3...............33 Figura 3...............................................22 – Pantalla Mantenimiento de Tipo de Componente.....................................................................................11 Figura 1............7 ......................................34 Figura 3........14 .36 – Pantalla Metodologías en Relación a CMMI.....Diagrama de Caso de Uso: Usuario de Metodología.....................................14 Figura 1..........................................................................................27 – Pantalla Buscar Metodología..........Diagrama de Caso de Uso GPS...............................................33 – Pantalla Metodologías en Relación a CMMI......Diagrama de Caso de Uso SGMCS..................................................................................................................................Diagrama de Caso de Uso Especialista en Metodologías (General)................................................INDICE DE GRAFICOS Figura 1...........4 ..........................................................18 – Pantalla Mantenimiento de Componentes.....................................28 – Pantalla Buscar Fase...37 Figura 3...Diagrama de Caso de Uso Especialista en Metodologías (Metodología)...26 – Pantalla Buscar Actividad........................21 – Pantalla Mantenimiento de Rol....................................................................................Diagrama de Caso de Uso: Especialista en Metodologías (Tipo de Componente).........................................................................35 Figura 3.............17 – Pantalla Mantenimiento de Actividades...........................................54 Figura 4........Metodología MSF............39 Figura 3........Diagrama de Caso de Uso Especialista en Metodologías (Actividad).......50 Figura 3.......60 ....................42 Figura 3......

......62 Figura 4......................Diagrama de clases publicados.....Diagrama de clases de diseño................................................................................Figura 4..70 Figura 4.......................................................................................45 – Diagrama de Despliegue..............44 – Diagrama de Componentes................................................................74 Figura 4..............................69 Figura 4............................................................Diagrama de clases consumido.....................................42 .........................72 Figura 4......75 .................................................................................41 ..................................................40 .......................................................................43 – Modelo de Datos.......

.......................1 – Equipo de Proyecto..Escenarios para Caso de Prueba de Componente en Relación de CMMI.................................................Escenarios para Caso de Prueba Mantenimiento de Metodología ..................80 Tabla 5.........................................................29 Tabla 4......Escenarios para Caso de Prueba de Metodologías en Relación de CMMI...13 .....................Escenarios para Caso de Prueba Mantenimiento de Fase.......................................Escenarios para Caso de Prueba de Asignación de Niveles de CMMI a Componente...79 Tabla 5.....Escenarios para Caso de Prueba Buscar Rol.............................85 Tabla 5.............14 ..................83 Tabla 5.....................................25 ...........................................10 .............Escenarios para Caso de Prueba Mantenimiento de Actividades...........................24 ......................................61 Tabla 4.......21 Tabla 2..........................22 ..Escenarios para Caso de Prueba de Historial de Tabla de Procesos.......................................................82 Tabla 5............................................................................................Escenarios para Caso de Prueba Buscar Proceso...81 Tabla 5............3 – Entregables del Proyecto.Escenarios para Caso de Prueba Buscar Metodología................................Escenarios para Caso de Prueba Buscar Fase..................84 Tabla 5..........79 Tabla 5..................9 ........................................29 Tabla 3..Características del Producto...............................20 .........................................................................................Escenarios para Caso de Prueba Buscar Componente..........26 ......2 – Stakeholders.......................................................................................................................23 ......................................18 ..........81 Tabla 5..........Escenarios para Caso de Prueba Mantenimiento de Componente...............................7 – Servicios Requeridos..........................16 ...............80 Tabla 5..................84 Tabla 5..................................................................83 Tabla 5........11 ...........Escenarios para Caso de Prueba Mantenimiento de Tipo de Componente..........................28 ..22 Tabla 2.........................................................5 – Resumen de Capacidades....26 Tabla 3................21 Tabla 2...INDICE DE TABLAS Tabla 2.................19 .........................................................................................................................................76 Tabla 5...................Herramientas.....79 Tabla 5......................................Escenarios para Caso de Prueba Mantenimiento de Roles...............................15 .........84 Tabla 5........................................6 .4 – Lista de Riesgos...........Escenarios para Caso de Prueba Buscar Tipo de Componente.............Escenarios para Caso de Prueba Mantenimiento de Procesos....21 .......................................17 ......................................................85 Tabla 5..............................84 Tabla 5..8 – Componentes del Diagrama de Despliegue........................82 Tabla 5.Escenarios para Caso de Prueba Buscar Actividad...............................................83 Tabla 5.....87 .........................27 ..........12 ...................................80 Tabla 5....................................................................Escenarios para Caso de Prueba de Asignación de Niveles de CMMI a Metodología...............................................................

2012 Página 9 . Fundamentación Teórica Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 1.

FUNDAMENTACIÓN TEÓRICA En este capítulo se describen los antecedentes del proyecto. que facilite la gestión de proyectos de software en el marco de un modelo de calidad internacionalmente reconocido.Capítulo 1. objetivos del sistema y los lineamientos a emplear sobre los cuales se basa el sistema. Gestor de Proyectos de Software. La UPC tiene la necesidad de contar con un “Sistema de Aseguramiento de la Calidad del Software”. 1. Gestor de Procesos y Metodologías. 2012 Página 10 .1 Antecedentes del Proyecto La Universidad Peruana de Ciencias Aplicadas (UPC) en sus talleres y/o proyectos de Ingeniería de Software ha requerido implementar un proceso de gestión de proyectos de software que sigan los estándares de calidad proporcionados por el CMMI. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. el dominio del problema. solución propuesta. Este sistema está dividido en cuatro subsistemas: • • • Gestor de Modelo de Calidad del Software. Fundamentación Teórica CAPITULO 1 1.

1 . se divide en 1.Diagrama de los subsistemas A continuación se presentará tres metodologías para el desarrollo de software con la finalidad de mostrar el alcance de la problemática a cubrir y que se plasman en los objetivos del proyecto. Fundamentación Teórica • Evaluador de Calidad del Software. llamado así por sus siglas en inglés Rational Unified Process.Capítulo 1.1 cuatro fases de desarrollo del software: 1 Rational Unified Process: 2004 http://www-306. A continuación se muestra la relación entre los subsistemas: Gestor de Modelo de Calidad de Software (SGMCS) Evaluador de Calidad de Software (SCAMPI) Seguridad Gestor de Procesos y Metodologias (GPM Gestor de Proyectos de Software (GPS) Figura 1. El módulo a desarrollar será el “Subsistema de Gestión de Procesos y Metodologías” con la finalidad de registrar las metodologías que en su mayoría pueden ser aplicables en los diferentes proyectos de Ingeniería de Software.com/software/rational/ Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Rational Unified Process (RUP)1 El proceso RUP.1. 2012 Página 11 .ibm.

Capítulo 1. Los objetivos de cada iteración se establecen en función al trabajo a desarrollar y a la meta a alcanzar. • Transición: El objetivo es llegar a entregar el producto al usuario: distribución. soporte y mantenimiento. Elaboración: En esta etapa el objetivo es determinar la arquitectura del proyecto. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Fases e Iteraciones de la Metodología RUP Fuente: Metodologías de desarrollo de software (http://www. Construcción: En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Fundamentación Teórica • • • Concepción: El objetivo en esta etapa es determinar la visión del proyecto. entrenamiento.2 . 2012 Página 12 . modelo o un producto de trabajo. Roles: Personas o entes involucrados en cada proceso.net) Los elementos del RUP son: • • • Actividades: Procesos que se llegan a determinar en cada iteración. Figura 1.informatizate. Artefactos: Documento. Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones. el cual consiste en reproducir el ciclo de vida en cascada a menor escala.

Los cambios de requisitos se pueden realizar en cualquier punto del proyecto y es un aspecto muy natural en esta metodología. funcionalidad extra y refactorización. así mismo crear test que prueben el funcionamiento de los distintos códigos implementados.extremeprogramming. iteraciones. • Codificación: La codificación debe hacerse ateniendo a estándares de codificación ya creados. • Diseño: Se elaboran diseños simples. • Pruebas: Para asegurar el funcionamiento final de una determinada historia de usuario se deben crear “Test de aceptación” y verificar cumplen su cometido. 2012 Página 13 . glosario de términos. release planning. La metodología XP se divide en 4 fases el desarrollo del software: • Planificación del Proyecto: Se ejecuta distintas actividades teniendo en cuenta las historias de usuario. 2 Extreme Programming: 2007 http://www.2 Extreme Programing (XP)2 Es una de las metodologías de desarrollo de software más exitosas en la actualidad de las metodologías ágiles.Capítulo 1. programación en pareja y reuniones diarias.1. El usuario final es parte del equipo de proyecto. El Extreme Programing generalmente se utiliza para proyectos pequeños en la que el tiempo de presentación de los entregables es uno de los principales riesgos que se deben mitigar. velocidad del proyecto.com Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. El Extreme Programing se diferencia del resto de metodologías porque le pone mayor énfasis a la adaptabilidad que en la “previsibilidad”. Fundamentación Teórica 1.

Metodología Extreme Programming Fuente: Metodologías de desarrollo de software (http://www. Modelo de Equipo. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas. • • • Software que funcione es más importante que documentación exhaustiva. Modelo de Diseño de Proceso y finalmente el modelo de Aplicación.3 Microsoft Solution Framework (MSF) Esta es una metodología flexible e interrelacionada con una serie de conceptos.1. 2012 Página 14 . al desarrollar y codificar los módulos del sistema La retroalimentación. Modelo de Gestión del Riesgo.informatizate. modelos y prácticas de uso. el desarrollo y la gestión de proyectos tecnológicos.Capítulo 1. concreta y frecuente del equipo de desarrollo.net) Las características que posee la metodología XP son: • • La respuesta ante el cambio es más importante que el seguimiento de un plan La comunicación entre los usuarios y los desarrolladores La simplicidad. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 1. el cliente y los usuarios finales. que controlan la planificación. MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto. Fundamentación Teórica Figura 1. Modelo de Proceso.3 .

• Planificación: Se elabora perfiles de usuarios actualizados. estructura del proyecto. • Desarrollo: Código fuente y archivo ejecutables.4 . elementos de soporte de funcionamiento. planteamiento de los riesgos. código fuente y archivos ejecutables. requerimientos candidatos. alcance. especificación funcional. • Estabilización: Se realiza la distribución final. Fundamentación Teórica Las fases y algunos de los entregables de cada una que posee la metodología MSF son las siguientes: • Visionado: Elaboración de la Visión.net) 3 Microsoft Solution Framework: 2007 http://www. notas de distribución. especificación para pruebas y casos funcional.Metodología MSF3 Fuente: Metodologías de desarrollo de software (http://www. casos de Uso detallados y escenarios de uso actuales.informatizate. lista Inicial de características a probar. • Distribución: Sistemas de operación y soporte Figura 1.mspx Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.com/technet/solutionaccelerators/msf/default.Capítulo 1. 2012 Página 15 . script de instalación.microsoft.

2 Lineamientos a Emplear Las metodologías presentadas anteriormente poseen algunas similitudes. • • Flexible: Utilizada en el ambiente de desarrollo de cualquier cliente. En dichas metodologías se muestran en común: • • • Fases: Periodo o etapa en la cual se divide el desarrollo de un proyecto de software. desarrollan los diversos talleres utilizando la metodología de tipo iterativa e incremental como Rational Unified Process (RUP). Las metodologías a desarrollar se encontraran relacionadas debidamente con el Modelo de Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. • Escalable: Puede organizar equipos tan pequeños entre 3 o 4 personas. Actividades: Son las tareas a realizar en una determinada fase del proyecto. Fundamentación Teórica La metodología MSF presenta las siguientes características: • Adaptable: Es parecido a un compás. Roles: Es la responsabilidad que tiene un individuo para la realización de una actividad. El subsistema Gestor de Procesos y Metodologías enfocará el desarrollo del mismo a las similitudes encontradas en las distintas metodologías mencionadas y enfocadas al cliente. así como también. usado en cualquier parte como un mapa. del cual su uso es limitado a un específico lugar. • Artefactos: Al desarrollar las actividades se elaboran de ser necesarios un conjunto de documentos.Capítulo 1. 2012 Página 16 . 1. Cabe indicar que las carreras de Computación de la UPC. la UPC. Tecnología Agnóstica: Usada para desarrollar soluciones basadas sobre cualquier tecnología. proyectos que requieren 50 personas a más.

Este modelo será brindado por el subsistema Gestor de Modelo de Calidad de Software.Capítulo 1. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Fundamentación Teórica Calidad de CMMI. 2012 Página 17 .

Gestión del Proyecto CAPITULO 2 2. así como Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 18 .2 Solución del Problema El Subsistema de Gestor de Procesos y Metodologías permitirá administrar las distintas metodologías y procesos que existen en el mercado para el desarrollo de software. Los impactos causados son: • Los jefes de proyectos toman demasiado tiempo en verificar si los proyectos desarrollados contienen un nivel de calidad adecuado.Capítulo 2. • Los alumnos no pueden verificar si sus proyectos asignados van siguiendo una metodología adecuada en base a los artefactos desarrollados. 2. GESTIÓN DEL PROYECTO En este capítulo se presentará el tema si como su alcance y las tareas que se realizarán para el desarrollo del proyecto. El problema afecta a las carreras de computación de la UPC. quienes se encargan de desarrollar productos de software.1 Dominio del Problema Los proyectos de software carecen de un control adecuado de las metodologías y procesos en relación a los niveles de calidad del CMMI para el desarrollo de software de las carreras de computación de la UPC. 2.

artefactos y roles de una metodología con los niveles de calidad del CMMI. actividades. 2. 2012 Página 19 . artefactos y productos aplicados en la UPC y ser capaz de adicionar otras metodologías que existan en el mercado actual • Administrar las actualizaciones de las versiones que puedan tener las metodologías registradas en el sistema Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. obteniendo un modelo común entre las distintas metodologías. Brindar una información adecuada de las metodologías y procesos de un proyecto determinado a los jefes de proyectos para que estos mismos puedan tomar las decisiones correspondientes y desarrollar un producto de software de calidad. El proyecto se encargará de trabajar los siguientes aspectos: • Registrar y actualizar las metodologías utilizadas para el desarrollo de Software. así como comparar dichas metodologías con los estándares de calidad del CMMI. actividades.Capítulo 2.3 Objetivos del Sistema El subsistema de gestor de procesos y metodologías es un subsistema que ofrece administrar las distintas metodologías y procesos que existen en el mercado para el desarrollo de software. Proporcionar una relación de metodologías y procesos para el desarrollo de software Relacionar procesos. relacionándolas con los estándares descritos en el CMMI. Gestión del Proyecto comparar dichas metodologías con los estándares de calidad del CMMI. • Registrar y actualizar las metodologías para el desarrollo de Software así como los roles. Así mismo podrá controlar si los diversos proyectos de software siguen una metodología existente.

• Diseñar los artefactos necesarios que son utilizados por cada una las metodologías a desarrollar así como los procesos de las mismas.4 Beneficios A continuación se listarán los beneficios del Subsistema Gestor de Procesos y Metodologías: • • • • Obtener un control de las metodologías registradas en el subsistema. Facilitar la información de los documentos necesarios que son consultados por el usuario para una determinada metodología 2. • Proporcionar a los demás subsistemas (Gestor de Modelo de Calidad y Gestor de Proyectos) la información proporcionada como metodologías y artefactos.5 Alcance El alcance del proyecto incluye lo siguiente: • Registrar una metodología con sus respectivos procesos. Comparar las metodologías registradas con los estándares de calidad del CMMI. Administración de las distintas versiones de una metodología.Capítulo 2. Comparar las metodologías registradas con los estándares de calidad del CMMI. Gestión del Proyecto • Solicitar y evaluar la información que provee el Sistema de Modelo de Calidad de Software para verificar que se cumplan los niveles de calidad con las metodologías registradas en el sistema a desarrollar. • Proveer la información adecuada al Subsistema de Gestión de Proyectos en base a sus requerimientos. artefactos. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 20 . 2. productos y roles. Otorgar un historial de versiones de una misma metodología. • • • Actualizar una metodología registrada.

Gestión del Proyecto El alcance del proyecto no incluye lo siguiente: • Evaluar los proyectos de Software en función a las metodologías registradas.6.2 Stakeholders Se presenta la relación de los usuarios involucrados en el Proyecto. 2012 Página 21 . 2. Stakeholder Comité de Proyecto Gerente de Proyecto Alumno Docente Tabla 2.1 – Equipo de Proyecto 2. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.2 – Stakeholders 2.6. Ilver Anache y Rosario Villalta UPC Ilver Anache Miguel Arrunategui Ludvik Medic Marisa Zacarias y Ángel Sueyoshi Tabla 2.1 Equipo de Proyecto Se presenta a las personas involucradas en el desarrollo del Proyecto.7 Entregables del Proyecto La relación de entregables del proyecto así como la fecha de entrega esta definida por el Comité de Proyectos. Comité de proyectos Auspiciador Jefe de proyecto Líder técnico Jefe de producto Participantes Ludvik Medic.Capítulo 2.6 Organización del Proyecto El proyecto está organizado de la forma siguiente: 2.

Gestión del Proyecto Artefactos Charter del Proyecto Memoria del Proyecto Documento de Visión Descripción Documento que contiene una información general del proyecto a desarrollar Documento que contiene una descripción general del producto que se va a desarrollar. Documento en el cual se prioriza los requerimientos del subsistema Documentos que detallan el funcionamiento de cada caso de uso. etc. Documento en cual se detallara el análisis a desarrollar en el subsistema Documento en el cual mostrará el modelo de la arquitectura del producto Contiene la información detallada (objetivo. Prototipo inicial del subsistema Documento que permite desarrollar el modelo a diseñar en el subsistema. Contiene la información del plan a desarrollar para la gestión de los cambios de los requerimientos. Modelo de despliegue.) para dicha iteración. Documento en el cual se mostrara la arquitectura de las pruebas a desarrollar Describe el plan de pruebas a elaborar. actividades. Tabla 2. contiene los siguientes modelos: Modelos de Análisis y Diseño. Modelo de casos de uso. Modelo de base de datos. etc. Documento que permite tener una visión integral de la arquitectura del proyecto. Documento que contiene el estudio del mercado para el producto y su funcionalidad Contiene los riesgos que puede tener el desarrollo del proyecto Contiene la información referente al desarrollo del proyecto. características. Documento que detalla la especificación de la funcionalidad requerida del subsistema Documento que detalla el modelo de los casos de uso a elaborar. 2012 Página 22 . objetivos.Capítulo 2. Modelo de Implementación.3 – Entregables del Proyecto Entrega Bloque 1 Bloque 1 Bloque 1 Lista de Riesgos Plan de Desarrollo de Software Documento SRS Modelo de Casos de Uso Plan de gestión de Cambios Priorización de los requerimientos Documentos Especificación de Casos de Uso Modelo de Análisis Modelo UML de la arquitectura Plan de Release Documento de Arquitectura de software Bloque 1 Bloque 1 Bloque 1 Bloque 1 Bloque 1 Bloque 2 Bloque 2 Bloque 2 Bloque 2 Bloque 2 Bloque 2 Primera Versión del Sistema Modelo de Diseño Arquitectura de las pruebas Plan General de Pruebas de Software Bloque 2 Bloque 3 Bloque 4 Bloque 4 2. alcances.8 Enfoque del Trabajo Los participantes del equipo de proyecto utilizaran las siguientes herramientas para el desarrollo del Subsistema Gestor de Procesos y Metodologías: Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

2012 Página 23 .Capítulo 2. Se utilizarán las siguientes herramientas de la suite Rational: • • Modelamiento: Rose Enterprise Edition Gestión de cambios: ClearQuest Gestión de requerimientos: RequisitePro Gestión de configuración: ClearCase Se elaborarán scripts de pruebas unitarias: Test Manager y Robot • • • 2. Se utilizará las herramientas del Rational XDE para el diseño del subsistema.9. 2.9. Para el lanzamiento de una nueva versión se coordinará con el comité del proyecto junto con el equipo de desarrollo.9 Plan de Soporte del Proceso Se presentan los planes para la administración de configuración y el plan de evaluación a seguir a lo largo del proyecto. 2.2 Plan de Evaluación Para la realización de la evaluación del proyecto el comité del proyecto presentará una vez por semana las correcciones de cada uno de los entregables y artefactos presentados con la Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Gestión del Proyecto • • • • • Se utilizará como metodología de desarrollo del sistema el RUP.1 Plan de Administración de Configuración Para la administración del subsistema a desarrollar se utilizará la herramienta Rational Clear Case para el manejo de las distintas versiones del producto.Net. Se utilizará como motor de base de datos Microsoft SQL Server. El lenguaje de modelación será el Unified Modeling Languaje (UML). El lenguaje de programación será Microsoft Visual .

2012 Página 24 . Además se pretende informar al usuario sobre los riesgos que se pueden correr durante el desarrollo del proyecto.2 Cambio en los requerimientos del cliente Es común encontrar en todo proyecto cambios en los requerimientos del cliente ocasionado por la falta de información del mismo cliente. • Mala definición la definición de los alcances y en los entregables a presentar en el plan de desarrollo de software. definiciones utilizadas y las referencias con la finalidad de eliminar o minimizar la probabilidad de riesgo que pueda afectar el desarrollo del proyecto. 2. 2. Al término de cada hito se presentará al comité del proyecto todos los entregables propuestos para ser evaluados.10.10. demasiada carga de trabajo trae como consecuencia el incumplimiento del calendario pactado.10 Riesgos del Proyecto A continuación se presentarán los riesgos vinculado al proyecto y también se detallarán los alcances. Este problema radica básicamente por los siguientes motivos: • Insuficiente personal para el proyecto.Capítulo 2. Gestión del Proyecto finalidad de obtener un buen producto y no modificar el calendario de proyecto. éste se puede presentar de dos formas: • Cambio en las interfaces del sistema Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. El éxito del proyecto depende mucho si se combaten los riesgos que se detallan en este documento 2.1 Incumplimiento del calendario de desarrollo del proyecto En todo proyecto de desarrollo de software es muy común el incumplimiento con el calendario establecido inicialmente. El proyecto a desarrollar hasta la etapa de elaboración cuenta con dos integrantes.

2. 2.10.4 Falta de integración con los otros subsistemas La falta de integración con los otros subsistemas es un riesgo que es muy común por la falta de comunicación por parte de los integrantes del proyecto.Capítulo 2. Gestión del Proyecto • Cambio en la funcionalidad del sistema 2.10. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.6 Pruebas insuficientes al subsistema Durante la fase de elaboración del proyecto no se tuvieron en consideración una cantidad de pruebas suficientes o un adecuado plan de pruebas.10. 2.3 Insuficiencia de información del negocio La falta de información sobre el negocio produce un mal diseño del software desde la etapa inicial. Según la metodología empleada (RUP) en la fase de concepción se considera como parte principal el conocimiento del negocio. 2012 Página 25 .5 Insuficiente tiempo para el cumplimiento del desarrollo del proyecto La falta de tiempo para el cumplimiento del calendario es uno de los riesgos mas comunes que se presentan en todo proyecto.10. Esto se debe básicamente a la falta de experiencia y una inadecuada definición en las fechas de entrega del producto parcial y final.

1 es el menos crítico y el 10 es el más crítico A continuación se presenta la matriz de prioridad de riesgos asociados al proyecto: Ítem 1 2 3 4 5 6 Riesgo Insuficiencia de información del negocio Falta de integración con los otros subsistemas Cambio en los requerimientos del cliente Insuficiente tiempo para el cumplimiento del desarrollo del proyecto Incumplimiento del calendario de desarrollo del proyecto Pruebas insuficientes al subsistema Tabla 2. 2012 Página 26 .4 – Lista de Riesgos Magnitud 10 10 8 8 6 6 Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 2. Gestión del Proyecto La magnitud del riesgo se mide en una escala del 1 al 10.

Producto Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 27 .Capítulo 3.

3. Mediante ello se realiza una adecuada priorización de las necesidades que deben ser satisfechas de manera inmediata.2 Capacidades y Características del Producto Se listará los beneficios del cliente en relación a las características soportadas por el Subsistema Gestor de Procesos y Metodologías Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 28 . así como comparar dichas metodologías con los estándares de calidad del CMMI. Así mismo podrá controlar si los diversos proyectos de desarrollo software siguen una metodología “existente”. Producto CAPITULO 3 3. PRODUCTO Se plasman las características funcionales y no funcionales con el fin de obtener una aproximación del sistema final.Capítulo 3.1 Perspectiva del Producto El subsistema de gestor de procesos y metodologías es un subsistema ofrecerá administrar las distintas metodologías y procesos que existen en el mercado para el desarrollo de software. 3.

Tabla 3. En cuanto al diseño de interfaces mas intuitivas. procesos y roles) El Sistema permitirá la administración de artefactos.6 . Producto Beneficios del cliente Registro de los procesos y metodologías Registro de las últimas versiones de las metodologías. roles y/o otros componentes en función a la metodología seleccionada en relación a los niveles de calidad requeridos. El subsistema generara reportes de artefactos de una determinada metodología. el subsistema podrá generar la lista de artefactos que deben realizar par alcanzar dicho objetivo. Configuración de metodologías en base a los estándares establecidos en el CMMI. Gestión de Componentes de las Metodologías Comparación de Metodologías Entrega de Información de Metodologías Gestión de Metodologías y Procesos Basado en estándares de la industria del software Tabla 3. delimitando sus accesos. En base al proyecto de software y al nivel deseado del CMMI. El Sistema permitirá comparar las metodologías en base a los estándares de calidad del CMMI. 2012 Página 29 . A cada usuario se le asignara ciertos roles. actividades.Características del Producto 3. actividades.Capítulo 3.5 – Resumen de Capacidades A continuación se presentan las características del producto: Característica Registro de Procesos y Metodologías Descripción El Sistema permitirá el registro de los procesos y metodologías (artefactos. Seguridad de la información Generación de reportes Características Soportadas Los docentes de la carrera de Ingeniería de Software podrán realizar el registro de las metodologías y procesos para el desarrollo de software. El Sistema brindará una información adecuada de las metodologías y procesos de un proyecto determinado a los jefes de proyectos para que estos mismos puedan tomar las decisiones correspondientes y desarrollar un producto de software de calidad. Configurar metodologías y procesos así como sus artefactos. procesos. Los docentes podrán establecer la relación que existe entre los artefactos de una metodología con los estándares establecidos del CMMI. procesos y roles de una metodología con los niveles de calidad del CMMI. actividades. El Sistema estará diseñado bajo los estándares más comunes de la industria del desarrollo del software. Los usuarios podrán actualizar las metodologías en función a las últimas versiones que existen en el mercado.3 Requerimientos No Funcionales A continuación se presentan los requerimientos no funcionales del producto: Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

Producto 3.3.3. 3. metas específicas. Estos usuarios estarán agrupados por perfiles para una mejor administración de los permisos. Los equipos se encuentran conectados a una red Lan que se encuentra disponible las 24 horas del día. 3. Además el Sistema será capaz de poder exportar los reportes en formatos de texto y hoja de cálculo.Capítulo 3. proceso.2 Supuestos de Software • • • Los terminales contarán con sistema operativo.5 Usabilidad Se debe garantizar cubrir los siguientes parámetros de uso para la interfaz del usuario. Windows XP Profesional. 3.3. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. a) Interfaz de Usuario Amigable El sistema se diseñará bajo los estándares de Microsoft GUI el cual es uno del os más utilizado en la industria de desarrollo de software. prácticas específicas y workproducts.3 Dependencia con el Módulo de Seguridad El Sistema se conectará a un módulo de seguridad en la cual se almacenarán la información de los usuarios y contraseñas encriptadas. 3. es decir versión.1 Supuestos de Hardware La UPC cuenta con equipos adecuados para la realización del proyecto. estructura. Se utilizará como motor de base de datos Microsoft SQL Server 2000.3. El servidor contará con Windows Server 2003 como sistema operativo.4 Facilidad de Uso En las interfaces se utilizará la misma jerarquía propuesta por el CMMI.3. Además se presentará los prototipos iniciales al cliente para su posterior aprobación. nivel. 2012 Página 30 .

Producto b) Intuitiva La información colocada en las pantallas debe tener una distribución adecuada con la finalidad de que el usuario pueda acceder fácilmente a la información.6 Confiabilidad Se deben cumplir los siguientes requisitos de confiabilidad: a) Disponibilidad de Hardware Se contará con un servidor de base de datos. un servidor de aplicaciones y un servidor Web. c) Compatibilidad El sistema será compatible con los browsers de Internet. Para ello se debe realizar las pruebas correspondientes.8 Interfaces Se utilizará Net Remoting con Security Socket Layer para la comunicación entre el cliente y el servidor. Se presentarán prototipos parciales al cliente hasta lograr su plena satisfacción. El servidor de base de datos necesitará los siguientes como requerimiento mínimo un procesador Intel Pentium IV de 3Ghz con 6 GB de memoria RAM.7 Requerimientos de Plataforma El cliente necesitará un procesador Intel Pentium D de 1. El servidor de aplicación necesitará los siguientes como requerimiento mínimo un procesador Intel Pentium D de 3Ghz con 4 GB de memoria RAM. 3.3.Capítulo 3. 3. 3. b) Backups en la Base de Datos Se realizará el backup incremental de la base datos diariamente y un backup total los días domingos y así tener la data completamente segura ante una posible caída en la base de datos.77 Ghz con 1GB de memoria RAM. 2012 Página 31 .3. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.3.

5 .Capítulo 3.4 Diagrama de Casos de Uso Se muestra el diagrama de caso de uso del actor Especialista en Metodologías Consultar Historial de Tabla Proces o Desarrollo As ignar Niveles de CMMI a Metodologías <<extend>> <<extend>> Especialista en Metodologías (f rom Actores) Asignar Niveles de CMMI a Componentes <<extend>> Buscar Metodologia Actualizar Actividad Figura 3. 2012 Página 32 . Producto 3.Diagrama de Caso de Uso Especialista en Metodologías (General) Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

Producto <<extend>> Buscar Metodologia <<extend>> Especialista en Metodologías (from Actores) Actualizar Actividad <<include>> Buscar Actividad <<extend>> Buscar Proceso Actualizar Componente Figura 3.Capítulo 3.6 .Diagrama de Caso de Uso Especialista en Metodologías (Componente) Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 33 .7 .Diagrama de Caso de Uso Especialista en Metodologías (Actividad) <<extend>> Buscar Componente <<extend>> Especialista en Metodologías (from Actores) Actualizar Componente Buscar Metodologia <<extend>> Buscar Proceso Figura 3.

Producto Especialista en Metodologías (from Actores) Actualizar Fase <<extend>> Buscar Metodologia Figura 3.Capítulo 3.8 .Diagrama de Caso de Uso Especialista en Metodologías (Fase) Buscar Proceso <<extend>> <<extend>> Especialista en Metodologías (from Actores) Actualizar Proceso Buscar Metodologia <<include>> Actualizar Fase Figura 3. 2012 Página 34 .Diagrama de Caso de Uso Especialista en Metodologías (Proceso) Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.9 .

10 .Diagrama de Caso de Uso Especialista en Metodologías (Metodología) <<extend>> Buscar Rol <<extend>> Especialista en Metodologías (from Actores) Actualizar Rol Buscar Metodologia <<include>> Actualizar Actividad Figura 3.Capítulo 3. Producto <<extend>> Especialista en Metodologías (from Actores) Actualizar Metodología Buscar Metodologia Figura 3. 2012 Página 35 .Diagrama de Caso de Uso Especialista en Metodologías (Rol) <<extend>> Especialista en Metodologías (from Actores) Actualizar Tipo de Componente Buscar Tipo Componente Figura 3.11 .Diagrama de Caso de Uso: Especialista en Metodologías (Tipo de Componente) Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.12 .

Producto Usuario de Metodología (from Actores) Consultar Metodologias en Funcion a CMMI (from CU .Capítulo 3.13 .Diagrama de Caso de Uso: Usuario de Metodología Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.GPM) Figura 3. 2012 Página 36 .GPM) Consultar Componentes en Funcion a CMMI (from CU .

GPM) Figura 3.Diagrama de Caso de Uso GPS Se muestra el diagrama de caso de uso del actor Gestor del Modelo Calidad de Software Asignar Niveles de CMMI a Metodologías (from CU .) Figura 3..Diagrama de Caso de Uso SGMCS Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.15 ...Capítulo 3.) Consultar Componentes en Funcion a CMMI (from CU ..GPM) Entregar Tabla Procesos de Desarrollo (from CU .GPM) GPS (from Actores Comunes) .Especiali sta Metodol ogias) SGMCS (from Actores Comunes) . Producto Se muestra el diagrama de caso de uso del actor Gestor de Proyectos de Software (GPS) Consultar Metodologias en Funcion a CMMI (from CU . 2012 Página 37 .14 .

16 – Pantalla Mantenimiento de Metodologías Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 3. Figura 3. 2012 Página 38 .1 Casos de Uso del actor: Especialista en Metodologías a) Caso de Uso: Actualizar Metodología Este caso de uso permite al especialista en metodologías crear. modificar o eliminar las metodologías que van a ser utilizadas para la evaluación de los proyectos y comparar con los niveles de CMMI.4. Producto 3.

Figura 3. Producto b) Caso de Uso: Actualizar Actividad El Especialista en Metodologías tendrá la opción de crear. 2012 Página 39 .17 – Pantalla Mantenimiento de Actividades Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. modificar. eliminar o buscar una actividad de una fase.Capítulo 3.

Figura 3. perteneciente a una metodología. modificar o eliminar los componentes de un tipo de componente. Producto c) Caso de Uso: Actualizar Componente Este caso de uso permite crear. 2012 Página 40 .18 – Pantalla Mantenimiento de Componentes Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 3.

eliminar o buscar una fase de una fase. 2012 Página 41 .19 – Pantalla Mantenimiento de Fases Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Producto d) Caso de Uso: Actualizar Fase El Especialista en Metodologías tendrá la opción de crear. Figura 3. modificar.Capítulo 3.

modificar. 2012 Página 42 .20 – Pantalla Mantenimiento de Procesos Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Producto e) Actualizar Proceso El Especialista en Metodologías tendrá la opción de crear. Figura 3. eliminar o buscar un proceso de una metodología.Capítulo 3.

21 – Pantalla Mantenimiento de Rol Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. modificar o eliminar un Rol perteneciente a una Actividad.Capítulo 3. 2012 Página 43 . Figura 3. Producto f) Caso de Uso: Actualizar Rol El Especialista en Metodologías tendrá la opción de crear.

modificar o eliminar un tipo de componente de una metodología. 2012 Página 44 .22 – Pantalla Mantenimiento de Tipo de Componente Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 3. Figura 3. Producto g) Caso de Uso: Actualizar Tipo de Componente El Especialista en Metodologías tendrá la opción de crear.

23 – Pantalla Asignación Niveles CMMI a Metodología Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Producto h) Caso de Uso: Asignar Niveles CMMI a Metodología El Especialista en Metodologías podrá asignar los niveles de CMMI correspondientes a una metodología.Capítulo 3. Figura 3. 2012 Página 45 .

Producto i) Caso de Uso: Asignar Niveles CMMI a Componente El Especialista en Metodologías podrá asignar los niveles de CMMI correspondientes a un componente.24 – Pantalla Asignación Niveles CMMI a Componente Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 3. Figura 3. 2012 Página 46 .

25 – Pantalla Consultar Historial de Tabla de Procesos k) Caso de Uso: Buscar Actividad El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de una actividad según el criterio establecido. 2012 Página 47 . Figura 3. Figura 3. Producto j) Caso de Uso: Consultar Historial de Tabla de Procesos El Especialista en Metodologías podrá visualizar la información de todas la configuraciones correspondientes entre la metodología con su respectivo nivel de CMMI.Capítulo 3.26 – Pantalla Buscar Actividad Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

27 – Pantalla Buscar Metodología m) Caso de Uso: Buscar Fase El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de una fase según el criterio establecido.28 – Pantalla Buscar Fase Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 3. Figura 3. Producto l) Caso de Uso: Buscar Metodología El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de una metodología según el criterio establecido. 2012 Página 48 . Figura 3.

29 – Pantalla Buscar Proceso o) Caso de Uso: Buscar Rol El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de una actividad según el criterio establecido.30 – Pantalla Buscar Rol Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Figura 3.Capítulo 3. 2012 Página 49 . Producto n) Caso de Uso: Buscar Proceso El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de un proceso según el criterio establecido. Figura 3.

Capítulo 3. Producto

p) Caso de Uso: Buscar Tipo Componente El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de un tipo de componente según el criterio establecido.

Figura 3.31 – Pantalla Buscar Tipo Componente

q) Caso de Uso: Buscar Componente El Especialista en Metodologías utilizara este caso de uso el cual permite la búsqueda de un componente según el criterio establecido.

Figura 3.32 – Pantalla Buscar Componente

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 50

Capítulo 3. Producto

3.4.2 Casos de Uso del actor: GPS a) Caso de Uso: Entregar Tabla de Procesos de Desarrollo El GPS (Gestor de Proyectos de Software) podrá visualizar la tabla de relaciones entre los componentes de una metodología con sus respectivos niveles de CMMI. b) Caso de Uso: Consultar Metodologías en Función de CMMI Este caso de uso permite al GPS (Gestor de Proyectos de Software) y al Usuario de la Metodología visualizar la información de las metodologías para el desarrollo de software en relación al modelo de CMMI.

Figura 3.33 – Pantalla Metodologías en Relación a CMMI

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 51

Capítulo 3. Producto

c) Caso de Uso: Consultar Componentes en Función de CMMI Este caso de uso permite a GPS visualizar la información de los componentes de una metodología con su respectiva área de CMMI.

Figura 3.34 – Pantalla Componentes en Relación a CMMI

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 52

4.Capítulo 3. Figura 3. 2012 Página 53 .35 – Pantalla Componentes en Relación a CMMI Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.3 Casos de Uso del actor: Usuario de Metodología a) Caso de Uso: Consultar Componentes en Función de CMMI Este caso de uso permite Usuario de la Metodología visualizar la información de los componentes de una metodología con su respectiva área de CMMI. Producto 3.

Capítulo 3. Producto

b) Caso de Uso: Consultar Metodologías en Función de CMMI Este caso de uso permite al GPS (Gestor de Proyectos de Software) y al Usuario de la Metodología visualizar la información de las metodologías para el desarrollo de software en relación al modelo de CMMI.

Figura 3.36 – Pantalla Metodologías en Relación a CMMI

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 54

Capítulo 4. Diseño Arquitectónico

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 55

Capítulo 4. Diseño Arquitectónico

CAPITULO 4

4.

DISEÑO ARQUITECTÓNICO

En este capítulo se especifican los diagramas de Vista Lógica, el cual contiene las clases de diseño del sistema. Además, se especifican el diagrama de componentes y de despliegue del sistema. 4.1 Arquitectura General del Sistema

La arquitectura general del sistema se ha diseñado de acuerdo a las expectativas de crecimiento y a los servicios que se quieren ofrecer, basado en los estándares internacionales y a las tendencias en los sistemas y servicios de información. Así mismo, su elaboración se basa en la arquitectura actual de la Universidad Peruana de Ciencias Aplicadas.

Subsistema de Gestor de Procesos y Metodologías

© Universidad Peruana de Ciencias Aplicadas, 2012

Página 56

Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Servidor de Base de Datos: Servidor de base de datos en SQL Server 2000. 2012 Página 57 . Zona Segura Servidor Web IIS y de Aplicaciones: Servidor Web que aloja los componentes de lógica de negocios. Usuarios Internos: Usuarios del subsistema que van a ingresar mediante la Lan Interna. El flujo de sus acciones no considera la verificación por un Firewall.Diagrama de Arquitectura General del Sistema Usuarios Usuarios Externos: Usuarios del subsistema que van a ingresar a través de la Internet.37 . Diseño Arquitectónico Figura 4. el cual permite consumir los servicios de otros subsistemas del Sistema de Aseguramiento de Calidad de Software. lógica de acceso a datos.Capítulo 4. El flujo de sus acciones considera la verificación por un Firewall. servicios Web internos y el Agente de Servicios. Zona Desmilitarizada (Insegura) Servidor Web IIS: Servidor Web aloja los servicios Web.

Capítulo 4. 2012 Página 58 . El componente hace referencia a una de las partes de la solución total. como las páginas Web.Diagrama de Arquitectura de la Aplicación Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. así mismo. existen varios tipos de componentes habituales.NET) y otros elementos de software.2 Arquitectura de la Aplicación La arquitectura de aplicación se basa en modelos de componentes por capas. como los componentes de software compilado (por ejemplo.38 . los ensamblados de Microsoft . A continuación presentamos la arquitectura de aplicación del subsistema a desarrollar: Figura 4. Diseño Arquitectónico 4.

Interfaz de Autenticación del Sistema: Es la interfaz encargada del ingreso del usuario y contraseña del usuario para el ingreso al sistema. Diseño Arquitectónico Capa de Presentación Los componentes de la interfaz de usuario del Subsistema de Gestión de Procesos y Metodologías.Capítulo 4. Interfaces de Consulta de Información: Son aquellas interfaces de consulta de tanto la información ingresada en el subsistema como el ingresado por otros subsistemas. 2012 Página 59 . se basan en interfaces en Windows Forms las cuales se han agrupado en las siguientes funcionalidades. Los componentes de la capa del negocio para el Subsistema de Gestión de Procesos y Metodologías son: Interfaces de Servicio (Web Services): Es el componente encargado de brindar los servicios Web especificadas en los contratos con los otros subsistemas utilizando el protocolo SOAP. Interfaces de Mantenimiento: Son aquellas interfaces con las funcionalidades de creación. Interfaces de Asignación de Información: Son aquellas interfaces encargadas de asociar la información ingresada en el Subsistema de Procesos y Metodologías con otros subsistemas externos. estableciéndose aquí las reglas que deben cumplirse. Capa de Lógica del Negocio Los componentes de la capa lógica del negocio se basan en las peticiones del usuario y lógica del negocio. Controlador de Dominio: Son los componentes encargados de manejar las entidades Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. modificación y eliminación de registros que se encuentran en la base de datos.

2012 Página 60 .3 Relación con otros subsistemas A continuación se muestran los servicios ofrecidos y solicitados por el Subsistema de Procesos y Metodologías. Auditoria: Es el componente encargado de manejar la auditoria del componente de controlador de dominio.Diagrama de servicios entre subsistemas Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Diseño Arquitectónico del negocio con la finalidad de proveer al sistema el acceso a las operaciones transaccionales y no transaccionales.39 . 4. Entidades del Negocio: Son los componentes encargados de manejar el acceso a la base de datos.Capítulo 4. Modulo Gestor de Procesos y Metodologías Interfaces de Servicios Web Services Entregar Tabla de Procesos de Desarrollo Sistema de Aseguramiento de Calidad .Otros Sub sistemas N E T R E M O T I N G Gestor de Modelo de Calidad de Software -Entregar Información de CMMI Gestor de Proyectos de Software -Consultar Tabla de Procesos de Desarrollo . Capa de Acceso a Datos Es la capa encargada del manejo de acceso a la base de datos mediante conexiones. la información se especifica mediante los contratos.Gestor de Modelo de Calidad de software Entregar Tabla de Procesos de Desarrollo .Gestor de Proyectos de Software Agente de Servicios Seguridad Figura 4.

Diseño Arquitectónico 4. 2012 Página 61 .3.Capítulo 4.3. 4.7 – Servicios Requeridos Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Esta tabla es conocida por el nombre “Tabla de Procesos de Desarrollo”.1 Servicios Ofrecidos El subsistema Gestor de Procesos y Metodologías ofrecerá un servicio al Subsistema Gestor de Proyectos de Software.2 Servicios Requeridos El subsistema Gestor de Procesos y Metodologías recibirá los siguientes servicios del Subsistema Gestor de Modelo de Calidad de Software: Proyecto SGMCS SGMCS SGMCS SGMCS SGMCS SGMCS SGMCS Servicio S1 S2 S3 S4 S5 S6 S7 Nombre del Servicio Requerido Solicitar Versiones de CMMI Solicitar Tipo de Representación Solicitar Nivel de Representación Solicitar Áreas de Proceso Solicitar Objetivos Solicitar Practicas Solicitar Workproducts Tabla 4. el cual es el siguiente: Entregar Tabla de Procesos de Desarrollo Brindar a los módulos GPS (Gestor de Proyectos de Software) la tabla de relaciones entre los componentes de una metodología con sus respectivos niveles de CMMI.

..) ISGM CS (from Interfaces) . Co m pon ente i d_m eto do logi a : Inte ger i d_versi on : Intege r i d_fa se : Integer i d_ti po_ com p onente : In teg er i d_com pon en te : Inte ger nom bre _co m p one nte : S tring descri pci on : S trin g es_e xte rno : Bool ean Grabar() Recu pe rar() 1 1 ...* Proceso (from C lases Entidades) i d_p roceso : In teger n om bre _proceso : String d escri pcion : S trin g 1 Grab ar() Recupe rar() i d_m e tod ologi a : Integer i d_version : Integ er i d_fase : Integer i d_activi d ad : Integer no m bre_acti vida d : String de scri pcio n : String 1 es_ 1..* hito : Boo l ea n es_ extern o : Boo l ea n Graba r() Re cup era r() AsignarActi vi dad Entrada() Cre arCom ponen te() 0..* 1.* Figura 4.. • SGMCS: Subsistema de Modelo de Calidad de Software.* i d_ version : Integer nom b re_versi on : String .* i d_m eto dolo gi a : Integer i d_ve rsion : Inte ge r i d_fa se : Inte ge r no m bre_fase : Strin g de scri pci on : S tring Grabar() Recu perar() Crea rActivi dad() 1 1 id_m etod ologi a : Integer id_version : Integer id_fase : Integ er id_activi d ad : Integer id_rol : In teger 1 nom bre_rol : String descrip ci on : S tring Gra ba r() Recupera r() 1..4 4.* 1 1 Actividad T ipo Co m p on ente i d _ti po_com po nen te : Intege r nom bre_ tip o_com ponente : S tring descri pci on : S tring Grab ar() Recuperar() 1... A continuación se describe las clases y actores identificados..Diagrama de clases de diseño En el presente diagrama de clases se muestran todas las clases identificadas para el Subsistema de Procesos y Metodologías.* Fase (from C lases Entidades) CCG PM GetM etodologi a() GetCom pon en tePracti ca() Com p onentePracti ca i d_ m etodo logi a : Inte ger nom bre_m etodo logia : Stri ng i d_ version_m etod ol o gia : Integ er nom bre_versi on : String i d_ activi dad : Inte ger nom bre_a cti vidad : String i d_ fase : Integ er nom bre_fase : String i d_ ti po_co m p onente : Integ er nom bre_tipo_com ponente : S tring i d_ com ponen te : Intege r nom bre_com p on ente : Stri ng i d_ represen tacion : In teger nom bre_represen taci on : Stri ng i d_ nivel : Inte ger nom bre_n i vel : S trin g i d_ area : Integer nom bre_a rea : String ti_obj eti vo : Sm all in t i d_ obje tivo : Integer nom bre_o bj e ti vo : Strin g resu m e n_ obje tivo : String ti_practica : Sm al li nt i d_ proceso : Integ er i d_ practi ca : In teg er nom bre_p ractica : S tring esta do : Sm al lint i d_ workpro duct : Integer nom bre_workp roduct : String ni vel _asoci aci on : 3.4.2 Ve rsi on 1. Diseño Arquitectónico 4...) M etod ol o gia i d _m e tod olo gi a : In teg er i d _version : Inte ger estado : Sm a l li n t 1 nom bre_m etod ol o gia : String descri pcio n : String Grabar() Re cup era r() CrearFase () 1 Ro l 1..Capítulo 4. representa el subsistema Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.1 Vista de Clases Diagrama de Clases de Diseño CCS eg uri d ad ( from C lases C ontroladoras) SG M CS (from Actores Comunes) ..) ICom ponente_Practica ( from Interfaces) GP S (from Actores Comunes) .* 0.. 2012 Página 62 ..40 .

Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. • GPS: Gestor de Proyectos de Software. • CCSeguridad: Clase controladora que maneja todo lo relacionado a la seguridad del acceso al Sistema de Aseguramiento de Calidad de Software. Los métodos de esta clase controladora son los siguientes: o GetMetodologia(Entero Id_Metodologia): Obtiene toda la información relacionada a las metodologías (fase. componente y tipo de componente) o GetComponentePractica (): Obtiene toda la tabla de procesos de desarrollo que contiene la información entre la relación de los niveles de calidad de CMMI contra los componentes de la metodología registrada en la base de datos. representa el subsistema que maneja todos los proyectos y el Subsistema de Procesos y Metodologías le entrega la información de los niveles de calidad de CMMI relacionado con los componentes de las metodologías. Los atributos contenidos en esta clase son los siguientes: o Id_Metodologia (Entero): Código de la metodología.Capítulo 4. rol. • CCGPM: Clase controladora que se relaciona con todas las entidades de los procesos y metodologías. proceso. • ISGMCS: Interfaz por la cual se comunican el Subsistema Gestor de Modelo de Calidad de Software con los otros subsistemas relacionados. 2012 Página 63 . Este subsistema se accede mediante la interfaz ISGMCS. Diseño Arquitectónico que contiene toda la información de los niveles de calidad de CMMI. • Componente_Practica: Clase que contiene la información de la tabla de procesos de desarrollo que contiene la relación de los niveles de calidad de CMMI contra los componentes de la metodología registrada en la base de datos.

o Id_Area (Entero): Código de área de proceso de CMMI. o TI_Objetivo (Entero Pequeño): Tipo de objetivo de CMMI (Genérico o Específico). o Id_Proceso (Entero): Código de proceso de la metodología. o Id_Version_Metodologia (Entero): Versión de la metodología. o Id_Actividad (Entero): Código de la actividad de la metodología. o Nombre_Actividad (Cadena): Nombre de la actividad de la metodología. o Nombre_Fase (Cadena): Nombre de la fase de la metodología. o Nombre_Area (Cadena): Nombre de área de proceso de CMMI. o Nombre_Tipo_Componente (Cadena): Nombre del tipo de componente. o Id_Representacion (Entero): Código de representación de CMMI. Nombre del componente. o Nombre_Representación (Cadena): Nombre de la representación de CMMI. o Id_Nivel (Entero): Código de nivel de CMMI. o Nombre_Nivel (Cadena): Nombre de nivel de CMMI. o Id_Objetivo (Entero): Código de objetivo ya sea genérico o específico según el campo TI_Objetivo.Capítulo 4. o Id_Tipo_Componente (Entero): Código del tipo de componente. o Id_Fase (Entero): Código de la fase de la metodología. o Nombre_Componente. o Nombre_Objetivo (Cadena): Nombre del objetivo ya sea genérico o Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. o Id_Componente (Entero): Código de componente. Diseño Arquitectónico o Nombre_Metodologia (Cadena): Nombre de la metodología. o Nombre_Version (Cadena): Nombre de la versión de la metodología. 2012 Página 64 .

o Nombre_Metodologia (Cadena): Nombre de la metodología. o Estado (Entero Pequeño): Estado del componente práctica que pueden tener los valores de activo o inactivo. • Metodología: Clase que contiene la información relacionada a las metodologías. Diseño Arquitectónico específico según el campo TI_Objetivo. Los atributos son los siguientes: o Id_Metodología (Entero): Código de la metodología. o Nombre_Practica (Cadena): Nombre de la práctica ya sea genérica o específica según el campo TI_Practica. o Nombre_Workproduct (Cadena): Nombre del workproduct de CMMI. o Estado (Entero Pequeño): Indicador si la metodología se encuentra activa o inactiva.2)): Porcentaje que determina el nivel de relación entre el componente de la metodología con el nivel de CMMI. Los métodos son los siguientes: Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 4. o Id_Practica (Entero): Código de práctica ya sea genérica o específica según el campo TI_Practica. o Nivel_Asociacion (Decimal (3. o Descripción (Cadena): Descripción de la metodología. o Id_Workproduct (Entero): Código de workproduct de CMMI. 2012 Página 65 . o Resumen_Objetivo: Descripción del objetivo ya sea genérico o específico según el campo TI_Objetivo. o TI_Practica (Entero Pequeño): Tipo de práctica de CMMI (Genérica o Específica). o Id_Version (Entero): Código de la versión de la metodología.

Los atributos son los siguientes: o Id_Metodologia (Entero): Código de la metodología. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. o Id_Actividad (Entero): Código de la actividad de la metodología. • Versión: Clase que contiene la información sobre la versión de la metodologías. o Nombre_Version (Cadena): Nombre de la versión de la metodología. o Descripcion (Cadena): Descripción de la fase de la metodología. Los atributos son los siguientes: o Id_Version (Entero): Código de la versión de la metodología. • Fase: Clase que contiene la información relacionada a las fases de la metodología. o Es_Hito (Booleano): Flag que indica si la actividad es un hito. o Nombre_Actividad (Cadena): Nombre de la actividad de la metodología. Los atributos son los siguientes: o Id_Metodología (Entero): Código de la metodología.Capítulo 4. • Actividad: Clase que contiene la información sobre las actividades de una metodología. o Id_Version (Entero): Código de la versión de la metodología. o Id_Fase (Entero): Código de fase de la metodología. 2012 Página 66 . Diseño Arquitectónico o Grabar(): Guarda la información de la metodología. o Nombre_Fase (Cadena): Nombre de la fase de la metodología. o Id_Version (Entero): Código de versión de la metodología. o Id_Fase (Entero): Código de fase de la metodología. o CrearFase(): Crea un objeto de la fase de la metodología. o Descripcion (Cadena): Descripción de la actividad de la metodología. o Recuperar(): Obtiene los datos de la metodología.

Los atributos son los siguientes: o Id_Metodología (Entero): Código de la metodología.Capítulo 4. o AsignarActividadEntrada(): Inserta los códigos de las actividades de entrada si es lo tuviera para una actividad. o Nombre_Rol (Cadena): Nombre del rol. o Id_Version (Entero): Código de la versión de la metodología. o CrearComponente(): Crea un componente para la metodología. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. o Descripcion (Cadena): Descripción del rol. o Id_Actividad (Entero): Código de la actividad de la metodología. Diseño Arquitectónico o Es_Externo (Booleano): Flag que indica si la actividad es externa. o Id_Fase (Entero): Código de fase de la metodología. Los métodos son los siguientes: o Grabar(): Guarda la información sobre los roles. o Id_Version (Entero): Código de la versión de la metodología. o Id_Rol (Entero): Código de rol. • Componente: Clase que contiene la información de los componentes de una metodología. Los métodos son los siguientes: o Grabar(): Guarda la información de la actividad de la metodología. Los atributos son los siguientes: o Id_Metodología (Entero): Código de la metodología. o Recuperar():Obtiene los datos de la actividad de la metodología. o Recuperar(): Obtiene la información de los roles. • Rol: Clase que contiene la información de los roles. 2012 Página 67 .

2012 Página 68 . o Grabar(): Guarda la información de los tipos de componentes. o Descripcion(Cadena): Descripción del tipo de componente. Diseño Arquitectónico o Id_Fase (Entero): Código de fase de la metodología. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. • Tipo_Componente: Clase que contiene la información de los tipos de componente. o Nombre_Componente (Cadena): Nombre del componente de la metodología. o Id_Componente (Entero): Código del componente. Los métodos son los siguientes. Los métodos son los siguientes: o Grabar(): Guarda la información de los componentes. o Es_Externo (Booleano): Flag que indica si la actividad es externa. o Recuperar(): Obtiene la información de los tipos de componente.Capítulo 4. o Descripcion (Cadena): Descripción del componente de la metodología. o Recuperar(): Obtiene la información de los componentes. o Id_Tipo_Componente (Entero): Código del tipo de componente. Los atributos son los siguientes: o Id_Tipo_Componente (Entero): Código de tipo de componente. o Nombre_Tipo_Componente (Cadena): Nombre del tipo de componente.

Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. La recuperación de la información se realizará por niveles.Capítulo 4.2 Diagrama de Clase (Consumido) INivelRepresent acion (from Interfaces) IAreaProces o (from Interfaces) .. Diseño Arquitectónico 4.41 .4.) WSSGMCS (from Cl ases Controladoras) IWorkproduct (from Interfaces) ICMMI_Versio n (from Interfaces) ITipoRepresent acion (from Interfaces) IMetas (from Interfaces) CCGPM (from Clases Controladoras) GetMetodologia() GetComponentePractica() Figura 4.Diagrama de clases consumido El Subsistema de Procesos y Metodologías tiene interacción con el Subsistema de Modelo de Calidad de Software para la obtención de los niveles de CMMI. cada nivel está representado por cada una de las interfaces. 2012 Página 69 ..

42 . IWorkproduct: Interfaz que manejan los workproducts. ITipoRepresentacion: Interfaz que maneja los tipos de representación de CMMI.4. INivelRepresentacion: Interfaz que maneja los niveles de representación de CMMI.3 Diagrama de Clases (Publicados) GPS (from Logical View) IComponente_ Practica (from Interfaces) CCSeguridad (from Cl ases Controladoras) CCGPM (from Cl ases Controladoras) GetMetodologia() GetComponentePractica() Figura 4. IMetas: Interfaz que maneja las metas específicas y/o genéricas. 4. 2012 Página 70 .Diagrama de clases publicados Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 4. IAreaProceso: Interfaz que maneja el área de proceso de CMMI. Diseño Arquitectónico Para obtener la información de los niveles de calidad de software se utiliza siete interfaces que son los siguientes: • • • • • • ICMMIVersion: Interfaz que maneja las versiones de CMMI.

Diseño Arquitectónico El Subsistema de Procesos y Metodologías publica la información la cual está contenida en la tabla de procesos de desarrollo que es la que maneja la información entre las niveles de CMMI contra los componentes de la metodología. • CCSeguridad: Clase controladora que maneja todo el entorno de seguridad del Sistema de Aseguramiento de Calidad de Software. IComponente_Practica: Interfaz que publica los métodos que contiene la tabla de procesos de desarrollo.Capítulo 4. • GPS: Paquete del Subsistema de Proyectos de Software. • Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Los componentes son los siguientes: • CCGPM: Clase controladora que es la que interactúa con todas las clases del Subsistema de Procesos y Metodologías. 2012 Página 71 .

Diseño Arquitectónico 4.5 Modelo de Datos G P M _ T B L _ V E R S IO N Id _ V e rs io n: inte g e r N O T N U L L N o m b re : va rc ha r(255) N O T N U L L D e s c rip c io n: va rc ha r(4000) N U L L F e c ha _ C re a c io n: s ma lld a te time N O T N U L L F e c ha _ M o d ific a c io n: s ma lld a te tim e N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L _ M E T O D O L O G IA Id _ M e to d o lo g ia : inte g e r N O T N U L L Id _ V e rs io n: inte g e r N O T N U L L (F K ) N o m b re : va rc ha r(255) N O T N U L L D e s c rip c io n: va rc ha r(4000) N U LL E s ta d o : s ma llint N O T N U L L F e c ha _ C re a c io n: s ma lld a te time N O T N U LL F e c ha _ M o d ific a c io n: s m a lld a te time N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U LL U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L _ A C T IV ID A D Id _ M e to d o lo g ia : inte g e r N O T N U LL (F K ) Id _ V e rs io n: inte g e r N O T N U L L (F K ) Id _ F a s e : inte g e r N O T N U LL (F K ) Id _ A c tivid a d : inte g e r N O T N U L L N o m b re : va rc ha r(255) N O T N U L L D e s c rip c io n: va rc ha r(4000) N O T N U L L E s _ H ito : b it N O T N U L L E s _ E xte rno : b it N O T N U LL F e c ha _ C re a c io n: s m a lld a te time N O T N U LL F e c ha _ M o d ific a c io n: s ma lld a te tim e N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L_ C O M P O N E N T E xA C T IV ID A D Id _ A c tivid a d : inte g e r N O T N U L L (F K ) Id _ F a s e : inte g e r N O T N U L L (F K ) Id _ M e to d o lo g ia : inte g e r N O T N U L L (F K ) Id _ V e rs io n: inte g e r N O T N U LL (F K ) Id _ C o m p o ne nte : inte g e r N O T N U L L (F K ) G P M _ T B L_ F A S E Id _ M e to d o lo g ia : inte g e r N O T N U LL (F K ) Id _ V e rs io n: inte g e r N O T N U L L (F K ) Id _ F a s e : inte g e r N O T N U LL N o m b re : va rc ha r(255) N O T N U L L D e s c rip c io n: va rc ha r(4000) N U L L F e c ha _ C re a c io n: s m a lld a te tim e N O T N U LL F e c ha _ M o d ific a c io n: s m a lld a te time N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U LL U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L _ A C T IV ID A D xR O L Id _ A c tivid a d : inte g e r N O T N U L L (F K ) Id _ R o l: inte g e r N O T N U L L (F K ) Id _ F a s e : inte g e r N O T N U L L (F K ) Id _ M e to d o lo g ia : inte g e r N O T N U L L (F K ) Id _ V e rs io n: inte g e r N O T N U L L (F K ) G P M _ T B L_ C O M P O N E N T E Id _ C o m p o ne nte : inte g e r N O T N U L L Id _ T ip o _ C o m p o ne nte : inte g e r N U L L (F K) N o m b re : va rc ha r(255) N O T N U LL D e s c rip c io n: va rc ha r(4000) N U L L E s _ E xte rno : b it N O T N U L L F e c ha _ C re a c io n: s ma lld a te time N O T N U L L F e c ha _ M o d ific a c io n: s ma lld a te tim e N O T N U LL U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U LL G P M _ T B L _ C O M P O N E N T E _ P R A C T IC A Id _ C o m p o ne nte _ P ra c tic a : inte g e r N O T N U L L Id _ M e to d o lo g ia : inte g e r N U L L N o mb re _ M e to d o lo g ia : va rc ha r(255) N U L L Id _ V e rs io n_ M e to d o lo g ia : inte g e r N U L L N o mb re _ V e rs io n: va rc ha r(255) N U L L Id _ F a s e : inte g e r N U L L N o mb re _ F a s e : va rc ha r(255) N U LL Id _ A c tivid a d : inte g e r N U L L N o mb re _ A c tivid a d : va rc ha r(255) N U LL Id _ R o l: inte g e r N U L L N o mb re _ R o l: va rc ha r(255) N U LL Id _ C o m p o ne nte : inte g e r N U L L N o mb re _ C o mp o ne nte : va rc ha r(255) N U L L Id _ T ip o _ C o mp o ne nte : inte g e r N U L L N o mb re _ T ip o _ C o m p o ne nte : va rc ha r(255) N U LL Id _ R e p re s e nta c io n: inte g e r N U L L N o mb re _ R e p re s e nta c io n: va rc ha r(255) N U L L Id _ N ive l: inte g e r N U L L N o mb re _ N ive l: va rc ha r(255) N U LL Id _ A re a : inte g e r N U L L N o mb re _ A re a : va rc ha r(255) N U LL T i_ O b je tivo : s ma llint N U LL Id _ O b je tivo : inte g e r N U L L N o mb re _ O b je tivo : va rc ha r(255) N U L L R e s ume n_ O b je tivo : va rc ha r(4000) N U L L T i_ P ra c tic a : s ma llint N U L L Id _ P ra c tic a : inte g e r N U L L N o mb re _ P ra c tic a : va rc ha r(255) N U L L Id _ W o rk p ro d uc t: inte g e r N U L L N o mb re _ W o rkp ro d uc t: va rc ha r(255) N U L L E s ta d o : s ma llint N U L L N ive l_ A s o c ia c io n: d e c ima l(3. 2012 Página 72 .Capítulo 4.43 – Modelo de Datos Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.2) N U LL F e c ha _ C re a c io n: d a te tim e N O T N U L L F e c ha _ M o d ific a c io n: d a te tim e N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L_ R O L Id _ R o l: inte g e r N O T N U LL N o mb re : va rc ha r(255) N O T N U L L D e s c rip c io n: va rc ha r(4000) N U L L F e c ha _ C re a c io n: s m a lld a te time N O T N U L L F e c ha _ M o d ific a c io n: s ma lld a te time N O T N U L L U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L_ T IP O _ C O M P O N E N T E Id _ T ip o _ C o mp o ne nte : inte g e r N O T N U L L N o m b re : va rc ha r(255) N U LL D e s c rip c io n: va rc ha r(4000) N U LL F e c ha _ C re a c io n: d a te time N O T N U L L F e c ha _ M o d ific a c io n: d a te tim e N O T N U LL U s ua rio _ C re a c io n: va rc ha r(20) N O T N U L L U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L G P M _ T B L _ LO G Id _ L o g : inte g e r N O T N U L L D e s c rip c io n: va rc ha r(4000) N U LL F e c ha _ C re a c io n: d a te time N O T N U L L F e c ha _ M o d ific a c io n: d a te time N O T N U LL U s ua rio _ C re a c io n: va rc ha r(20) N O T N U LL U s ua rio _ M o d ific a c io n: va rc ha r(20) N O T N U L L Figura 4.

• • gpm_tbl_fase: Tabla de fases de la metodología. • • gpm_tbl_metodologia: Tabla que contiene la información de las metodologías. gpm_tbl_actividadXrol: Tabla creada para la relación de muchos a muchos entre las actividades y los roles. 2012 Página 73 . gpm_tbl_componente_practica: Tabla que contiene la tabla de procesos de desarrollo que contiene la información de la relación entre los niveles de CMMI contra los componentes de la metodología. • gpm_tbl_componenteXactividad: Tabla creada para la relación de muchos a muchos entre los componentes y la actividad. • • gpm_tbl_componente: Tabla de componente de la metodología. Diseño Arquitectónico A continuación se presentan las tablas identificadas en el modelo de datos: • • gpm_tbl_actividad: Tabla de actividades de la metodología. • • gpm_tbl_rol: Tabla que contiene la información de los roles.Capítulo 4. • gpm_tbl_procesoXfase: Tabla creada para la relación de muchos a muchos entre el proceso y las fases de la metodología. gpm_tbl_tipo_componente: Tabla que contiene la información de los tipos de componente. gpm_tbl_log: Tabla de log para todas las operaciones de mantenimiento de la base de datos. gpm_tbl_proceso: Tabla que contiene la información de los procesos de las metodologías. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. • gpm_tbl_version: Tabla que contiene la información de las versiones de la metodología.

Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.44 – Diagrama de Componentes Los componentes necesarios para la instalación del subsistema GPM son los siguientes: • COM+ (Component Object Model): Componente instalado en el servidor de aplicaciones utilizado para la comunicación a la base de datos.Capítulo 4.exe Actividad Tipo de Componente Componente Net Remoting Seguridad. Es aquí en la que se utilizará el Net Remoting como medio de comunicación entre los otros subsistemas. exe Figura 4.6 Diagrama de Componentes DB_GPM <<Application>> COM+ Metodología Fase Rol Framework.dll GPM. Diseño Arquitectónico 4.exe SGMCS.exe GPS. 2012 Página 74 .

0 EXE GPM. 4. Este módulo es independiente al sistema a desarrollar.0: Conjunto de librerías utilizado para el funcionamiento de todo el sistema de aseguramiento de calidad de software. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.ini Te rm ina l2 Microsoft Windows XP Professional Microsoft Framework 2.Capítulo 4. • • DB_GPM: Nombre de la base de datos del Subsistema de Procesos y Metodologías.45 – Diagrama de Despliegue Capa de Presentación Características de Hardware: Sistema Operativo: Windows XP Professional. Seguridad: Módulo que maneja toda la capa de seguridad para todo el Sistema de Aseguramiento de Calidad de Software.ini TCP/IP Se rv idor de A plica cione s COM + / Se rv id or W e b IIS Se rv id o r BD SQL Server 2000 BD_GPM Acceso Datos 1433 TCP/IP GPM Lógica Negocio Agente Servicio GPS Agente Servicios nrComponentePractica SGMCS wsSGMCS Figura 4.7 Diagrama de Despliegue Subsistema de Procesos y Metodologías (GPM) Te rm ina l1 Microsoft Windows XP Professional Microsoft Framework 2. • Microsoft Framework 2.0 EXE GPM. Diseño Arquitectónico • Net Remoting: Componentes utilizados para la comunicación con los subsistemas Gestor de Proyectos de Software (GPS) y Gestor de Modelo de Calidad de Software (SGMCS). 2012 Página 75 .

GPM. 1 GB Microsoft Framework 2. Poca capacidad de procesamiento. 2012 Página 76 .76 Ghz.exe Capa de Lógica del Negocio Sistema Operativo: Servidor de Aplicaciones: Servidor Web: Microsoft Windows 2003 Server COM+ Internet Information Services (IIS) Capa de Acceso a Datos Motor de Base de Datos: Protocolo de Transferencia de Datos Microsoft SQL Server 2000 TCP/IP Tabla 4. Diseño Arquitectónico Características de Software: Procesador: Memoria RAM: Framework: Archivo de Configuración: Tipo de Cliente: Ejecutable: Intel Pentium D 1.Capítulo 4.8 – Componentes del Diagrama de Despliegue Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.ini Ligero.0 GPM.

Capítulo 5. 2012 Página 77 . Pruebas del Sistema Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

requisitos funcionales. 5. • Verificar que los datos obligatorios sean ingresados debidamente.1 Requerimientos para las Pruebas Las pruebas estarán basadas en los riesgos del proyecto. Verificar que las interfaces cumplan con los estándares especificados en el documento Desarrollo de Software. los presuntos fallos o defectos. 2012 Página 78 . PRUEBAS DEL SISTEMA En este capítulo se especifican las estrategias a realizar para implementar el plan de pruebas. Pruebas del Sistema CAPITULO 5 5. casos de uso. 5.Capítulo 5. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. lo que permitirá validar que el software cumpla los requerimientos de calidad esperados y organizar el despliegue de éstas.1 Pruebas Funcionales Se describen las pruebas a desarrollar para las interfaces de los usuarios: • • Verificar una sencilla navegación entre las interfaces. elementos de diseño.1.

9 . 2012 Página 79 .Escenarios para Caso de Prueba Mantenimiento de Metodología • Mantenimiento de Fase Describir el caso de pruebas para el caso de uso Actualizar Fase. Metodología y Versión existente (Creación) Modificación de Fase Fase.11 .Escenarios para Caso de Prueba Mantenimiento de Fase • Mantenimiento de Proceso Describir el caso de pruebas para el caso de uso Actualizar Proceso.Capítulo 5.Escenarios para Caso de Prueba Mantenimiento de Procesos Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 Escenario / Condición Creación de Metodología Metodología y Versión existente (Creación) Modificación de Metodología Metodología y Versión existente (Modificación) Información incompleta del Nombre de Metodología Información incompleta de la versión de Metodología Tabla 5.10 . Pruebas del Sistema Se realizarán las pruebas en las siguientes interfaces: • Mantenimiento de Metodología Describir el caso de pruebas para el caso de uso Actualizar Metodologías. Metodología y Versión existente (Modificación) Información incompleta del Nombre de la metodología Información incompleta del Nombre de Fase Tabla 5. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 Escenario / Condición Creación de Proceso Proceso existente (Creación) Modificación de Proceso Proceso existente (Modificación) Información incompleta del Nombre de Metodología Información incompleta del Proceso Información incompleta de las fases seleccionadas Tabla 5. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 Escenario / Condición Creación de Fase Fase.

Escenarios para Caso de Prueba Mantenimiento de Actividades • Mantenimiento de Rol Describir el caso de pruebas para el caso de uso Actualizar Rol.13 .Capítulo 5. Pruebas del Sistema • Mantenimiento de Actividades Describir el caso de pruebas para el caso de uso Actualizar Actividad. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 8 Escenario / Condición Creación de Actividad Actividad existente (Creación) Modificación de Actividad Actividad existente (Modificación) Información incompleta del Nombre de Metodología Información incompleta del proceso Información incompleta de la actividad Información incompleta de los componentes Tabla 5.Escenarios para Caso de Prueba Mantenimiento de Roles • Mantenimiento de Tipo de Componente Describir el caso de pruebas para el caso de uso Actualizar Tipo de Componente. 2012 Subsistema de Gestor de Procesos y Metodologías Página 80 .12 .Escenarios para Caso de Prueba Mantenimiento de Tipo de Componente • Mantenimiento de Componente © Universidad Peruana de Ciencias Aplicadas.14 . Los escenarios son los siguientes: Nº 1 2 3 4 5 Escenario / Condición Creación de Tipo de Componente Tipo de Componente existente (Creación) Modificación de Tipo de Componente Tipo de Componente existente (Modificación) Información incompleta del Tipo de Componente Tabla 5. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 8 Escenario / Condición Creación de Rol Rol y Actividad existente (Creación) Modificación de Rol Rol y Actividad existente (Modificación) Información incompleta del Nombre Metodología Información incompleta del Nombre del Proceso Información incompleta del Nombre del Rol Información incompleta de las Actividades Seleccionadas Tabla 5.

versión de CMMI.Capítulo 5. tipo de representación y nivel de 4 representación existente (Creación) 5 Información incompleta para el Nombre de la metodología 6 Información incompleta para la Versión de la metodología 7 Información incompleta para la Versión del CMMI 8 Información incompleta para el Tipo de Representación del CMMI 9 Información incompleta para el Área de Proceso del CMMI 10 Información incompleta para el Nivel de CMMI 11 Información incompleta para el Nivel de CMMI 12 Información incompleta para el Área de Proceso del CMMI Tabla 5.15 .Escenarios para Caso de Prueba Mantenimiento de Componente • Asignación de Niveles de CMMI a Metodología Describir el caso de pruebas para el caso de uso Actualizar Niveles de CMMI a Metodología.Escenarios para Caso de Prueba de Asignación de Niveles de CMMI a Metodología Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. tipo de representación y nivel de 3 representación existente (Creación) Metodología. versión de la metodología. Los escenarios son los siguientes: Nº Escenario / Condición 1 Asignación CMMI a Metodología 2 Asignación CMMI a Metodología Metodología. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 Escenario / Condición Creación de Componente Componente existente (Creación) Modificación de Componente Componente existente (Modificación) Información incompleta del Nombre de Metodología Información incompleta del proceso Información incompleta del componente Tabla 5. versión de la metodología.16 . 2012 Página 81 . versión de CMMI. Pruebas del Sistema Describir el caso de pruebas para el caso de uso Actualizar Componente.

17 .Escenarios para Caso de Prueba de Metodologías en Relación de CMMI Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Capítulo 5. Pruebas del Sistema • Asignación de Niveles de CMMI a Componente Describir el caso de pruebas para el caso de uso Actualizar Niveles de CMMI a Componente. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 8 Escenario / Condición Consulta de Metodologías Consulta de Metodologías Información incompleta para la Versión CMMI Información incompleta para el tipo de representación Información incompleta para el área de proceso Información incompleta para el nivel de CMMI Información incompleta para el nivel de CMMI Información incompleta para el área de proceso Tabla 5.Escenarios para Caso de Prueba de Asignación de Niveles de CMMI a Componente • Metodologías en Relación de CMMI Describir el caso de pruebas para el caso de uso Consultar Metodologías en Función a CMMI.18 . 2012 Página 82 . Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 8 9 10 11 12 Escenario / Condición Asignación de Nivel de CMMI a Componente Información incompleta del Nombre de Metodología Información incompleta de la versión de Metodología Información incompleta del proceso Información incompleta de la fase Información incompleta de la actividad Información incompleta del tipo de componente Información incompleta del componente Información incompleta del nivel de asociación Nivel de Asociación Incorrecta Nivel de Asociación de CMMI existente Aprobación de Nivel de Asociación de CMMI existente Tabla 5.

Pruebas del Sistema • Componente en Relación de CMMI Describir el caso de pruebas para el caso de uso Consultar Componentes en Función a CMMI. Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Metodología Metodología vacía Metodología no encontrada Tabla 5. Los escenarios son los siguientes: Nº Escenario / Condición 1 Consulta de una configuración de la tabla de procesos de desarrollo Tabla 5.Escenarios para Caso de Prueba de Historial de Tabla de Procesos • Buscar Metodología Describir el caso de pruebas para el caso de uso Buscar Metodología.Capítulo 5.21 .Escenarios para Caso de Prueba Buscar Metodología Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Los escenarios son los siguientes: Nº 1 2 3 4 5 6 7 8 9 Escenario / Condición Consulta de Componente en Función de CMMI Información incompleta de la versión de CMMI Información incompleta del tipo de representación Información incompleta del área de proceso Información incompleta del tipo de objetivo Información incompleta del objetivo Información incompleta de la práctica Información incompleta del workproduct Nivel de CMMI incorrecto Tabla 5.20 . 2012 Página 83 .19 .Escenarios para Caso de Prueba de Componente en Relación de CMMI • Historial de Tabla de Procesos Describir el caso de pruebas para el caso de uso Consultar Historial de Tabla de Procesos de Desarrollo.

Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Actividad Actividad no encontrada Actividad Vacía Tabla 5.Capítulo 5. Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Componente Componente no encontrado Componente Vacío Tabla 5.23 . 2012 Página 84 . Pruebas del Sistema • Buscar Fase Describir el caso de pruebas para el caso de uso Buscar Fase. Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Proceso Proceso no encontrado Proceso Vacío Tabla 5.22 . Los escenarios son: Nº 1 2 3 Escenario / Condición Buscar Fase Fase vacía Fase no encontrada Tabla 5.24 .Escenarios para Caso de Prueba Buscar Actividad • Buscar Componente Describir el caso de pruebas para el caso de uso Buscar Componente.25 .Escenarios para Caso de Prueba Buscar Fase • Buscar Proceso Describir el caso de pruebas para el caso de uso Buscar Proceso.Escenarios para Caso de Prueba Buscar Componente Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.Escenarios para Caso de Prueba Buscar Proceso • Buscar Actividad Describir el caso de pruebas para el caso de uso Buscar Actividad.

0 Verificar que los terminales tengan el archivo de configuración GPM. 2012 Página 85 .2 Pruebas de Conectividad Se realizará pruebas de conectividad entre los distintos componentes de Net Remoting de todos los subsistemas.Escenarios para Caso de Prueba Buscar Tipo de Componente 5.Capítulo 5.26 . Pruebas del Sistema • Buscar Rol Describir el caso de pruebas para el caso de uso Buscar Rol. Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Tipo de Componente Tipo de Componente vacío Tipo de Componente no encontrado Tabla 5. Los escenarios son los siguientes: Nº 1 2 3 Escenario / Condición Buscar Rol Rol vacío Rol no encontrado Tabla 5.27 .Escenarios para Caso de Prueba Buscar Rol • Buscar Tipo de Componente Describir el caso de pruebas para el caso de uso Buscar Tipo de Componente.3 Pruebas de Configuración Se describen las pruebas de configuración del sistema: • • Verificar que los terminales ejecuten el aplicativo en Windows XP Verificar que los terminales cuenten con 1GB en memoria RAM Verificar que los terminales tengan instalados Microsoft Framework 2.1. los subsistemas son los siguientes: • • Subsistema Gestor de Modelo de Calidad de Software Subsistema de Gestor de Proyectos de Software 5.1.ini • • Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

navegación sencilla a través de las funciones y verificar que las interfaces cumplan con los estándares respectivos. asegurar el acceso apropiado. Subsistema de Gestor de Procesos y Metodologías Página 86 . tamaño. • Técnica • Crear o modificar pruebas para cada una de las interfaces para verificar la navegación y el estado de los componentes.2 Verificar que el servidor de aplicaciones este instalado COM+ Verificar que el servidor de aplicaciones posea Internet Information Services (IIS) Estrategia de las Pruebas 5. 2012 Prueba de los flujos básicos y/o alternativos de los procesos.exe Verificar que los terminales tengan el componente GPM.1.1 Pruebas Funcionales Verificar la interacción de los usuarios con el Software. • • Se realizarán pruebas unitarias para la funcionalidad de los prototipos Se confeccionará un data pool por cada caso de uso para la realización de las pruebas funcionales © Universidad Peruana de Ciencias Aplicadas.2. posición y cursor) de cada interfase deben encontrarse conformes a los estándares. Pruebas del Sistema • • Verificar que los terminales tengan el archivo ejecutable GPM.Capítulo 5. incluyendo diversos métodos (teclado y mouse) • Los componentes (menús.dll Verificar que el servidor de aplicaciones posea como sistema operativo Microsoft Windows 2003 Server • • • 5.2.1 Tipos de Prueba 5. Objetivos • La navegación a través de la aplicación debe reflejar las funciones del negocio.

2. conexión de red.2. verificar los requerimientos de hardware en dichos equipos. utilizando Windows XP.Capítulo 5. Objetivos • Validar y verificar que la aplicación se conecte correctamente con los otros subsistemas.2 Pruebas de Conectividad Verificar que la aplicación se conecte con los otros subsistemas que tiene relación. Así mismo. Objetivos • Técnica • • Probar las distintas aplicaciones en las estaciones.3 Pruebas de Configuración Verificar que la aplicación funcione correctamente en los terminales. Ejecutar la aplicación en varias estaciones Validar y verificar que la aplicación funcione correctamente en las estaciones 5. Pruebas del Sistema 5. servidor de aplicaciones.28 .2.1. así como el software.2 Herramientas Las herramientas a utilizar para el desarrollo de las pruebas son las siguientes: Tipo de Prueba Pruebas Funcionales de Prototipo Casos de Prueba Pruebas Unitarias Herramienta Rational Robot Rational Robot Microsoft Word Rational Robot Tabla 5. Técnica • Ejecutar la aplicación en varias estaciones 5.1. 2012 Página 87 .Herramientas Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.

2012 Página 88 . priorizar e implementar los casos de uso Ejecutar las pruebas Verificar los resultados Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas.3 Tareas En esta sección se describirán las tareas para el desarrollo de las pruebas: • • • • Administración de Reportes Identificar.Capítulo 5. Pruebas del Sistema 5.2.

Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. 2012 Página 89 . La Universidad Peruana de Ciencias Aplicadas (UPC) podrá contar con un sistema capaz de administrar todos los proyectos de software que cuentan sus distintos talleres así como registrar los modelos de CMMI y metodologías para el desarrollo de software.Conclusiones y Recomendaciones 6. CONCLUSIONES Y RECOMENDACIONES Al concluir con la presentación de la arquitectura del subsistema de procesos y metodologías (GPM) se ha mostrado un modelo flexible para todo tipo de metodologías ya sean ágiles o pesadas.

Indianápolis: Wiley Publishing Inc. 1ra edición. IBÁÑEZ. BIBLIOGRAFÍA EVJEN. CRUZ. BOWEN. Pedro 2007 Modelo de Caso de Uso. Lima: UPC Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. Aarón 2007 Patrones de Diseño. Pedro 2007 Gestión de Requerimientos de Software con Caso de Uso. Aarón 2007 Modelo de Despliegue. Lima: UPC IBÁÑEZ. Pedro 2007 Establecer la Visión y el Alcance del Producto Software. Lima: UPC. Pedro 2007 Administración y Gestión del Cambio en los Proyectos. Lima: UPC. Bill 2006 Visual Basic 2005.extremeprogramming. Lima: UPC. Pedro 2007 Especificación. Christopher 2006 Visual Studio 2005 Team System. Lima: UPC CRUZ.Bibliografía 7. 2012 Página 90 . Indianápolis: Wiley Publishing Inc. CRUZ. Lima: UPC. Documentación y Validación de Requerimientos. CRUZ. 1ra edición. EXTREME PROGRAMMING 2007 http://www. CRUZ.com Información de la metodología Extreme Programing.

Lima: UPC VIDAURRE.net Metodologías de desarrollo de software METRICA 3 2007 http://www.com Información enciclopédica.com/Resources/PM. María 2004 http://www.uclm.com Información sobre Net Remoting NIWOT RIDGE RESOURCES 2007 http://www.com/software/rational/ Documentación de Rational Unified Process RATIONAL UNIFIED PROCESS 2007 http://www. Alex 2007 Técnicas de Pruebas Funcionales. Subsistema de Gestor de Procesos y Metodologías © Universidad Peruana de Ciencias Aplicadas. PA.htm Web Site Software Processes and Methodologies PRESSMAN.pdf Documentación de Rational Unified Process SOFTWARE ENGINEERING INSTITUTE 2006 CMMI for Development Version 1.microsoft.2.niwotridge.dsi.es/csi/metrica3/ Web Site Metrica 3 MICROSOFT CORPORATION 2007 http://www. Lima: UPC VIDAURRE.es/asignaturas/42541/pdf/M1tema4.ibm. Roger 2002 Ingeniería del Software: Un enfoque práctico. Alex 2007 Verificación – Métodos Estáticos.wikipedia. 5ta edición. Pittsburgh. Lima: UPC WIKIPEDIA 2007 http://www.csi. Alex 2007 Fundamentos de Pruebas de Software.Bibliografía MENDOZA. 2012 Página 91 . Carnegie Mellon VIDAURRE.map.informatizate.SWEResources/SWMethodologies. Madrid: McGraw Hill RATIONAL UNIFIED PROCESS 2004 http://www-306.