31-Procedimiento de Desarrollo Del Software[1]

Emisión: 15/08/2012 Revisión 1

Procedimiento P31

Proceso de Desarrollo del Software (RUP

Página 1 de 15

ÍNDICE: 1. OBJETO 2. ALCANCES 3. DESARROLLO 4. ANEXOS 5. REGISTROS 6. REFERENCIAS

Revisión N°°

Fecha

Aprobado por

Resumen de cambios

0

27/04/2011

Roberto Daniel Aparicio

Emisión inicial

1

15/08/2012

Roberto Daniel Aparicio

Se modifico el nombre del Ministerio de Educación por Ministerio de Educación, Ciencia y Tecnología, por aplicación de la Ley de Ministerios.

APROBÓ Nombre C.U. Roberto Daniel Aparicio Función Coordinador de la Dirección Informática

Gral.

de

SGC Certificado

Procedimiento P31


Emisión: 15/08/2012 Revisión 1 Página 2 de 15

1. Objeto El presente procedimientos tiene como objeto definir el proceso de desarrollo de software (PDS) utilizado en la dirección General de Informática del Ministerio de Educación, Ciencia y Tecnología. El mismo prevé una visión global del enfoque de desarrollo basado en la metodología RUP(El Proceso Racional Unificado, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos), ya que se procederá a cumplir únicamente con determinadas fases de la metodología, de acuerdo a la características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que serán generados. 2. Alcances El propósito del Proceso de Desarrollo de Software, basado en RUP, es proporcionar la información necesaria para controlar el proceso de ingeniería, asegurando un producto de alta calidad que cumpla con los requerimientos funcionales. De acuerdo a los roles que desempeñen los participantes dentro del proceso, lo utilizarán para organizar las necesidades de los recursos y para realizar su seguimiento o para entender lo qué deben hacer, cuándo deben hacerlo y qué otras actividades dependen de ello. El proceso de desarrollo de software describe el plan global usado para el desarrollo del proyecto, en el se definen los roles de los participantes, las actividades a realizar, los artefactos que serán generados, y la duración de las fases e iteraciones. 3. Desarrollo

a) Marco Teórico RUP es un proceso para el desarrollo de un proyecto de software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. Características esenciales: ● Está dirigido por los Casos de Uso: orientan el proyecto a la importancia para el

usuario y lo que este quiere. ● Está centrado en la arquitectura: relaciona la toma de decisiones, que indican

cómo tiene que ser construido el sistema y en qué orden. ● Es iterativo e incremental: divide el proyecto en mini proyectos donde los casos

de uso y la arquitectura cumplen sus objetivos de manera más depurada. Principios claves de RUP: ●

Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc. ● Proceso iterativo e Incremental: Los proyectos se entregan, aunque sea de un

modo interno, en etapas iteradas. En cada iteración se analiza el cumplimiento de los requisitos, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

Procedimiento P31



● Elevar el nivel de abstracción: Este principio dominante motiva el uso de

conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML. Indiscutiblemente, en el desarrollo de una aplicación se sigue un proceso en el cual se avanza paulatinamente en la comprensión de la funcionalidad requerida y cómo realizarla, hasta llegar a su construcción. Esto requiere la ejecución de un conjunto de actividades que se manejan como un proyecto, es decir, con un objetivo final, un plazo y un plan. Como en todo proyecto, es importante contar con puntos intermedios de control a lo largo de su ejecución, denominados hitos, que se establecen cuando se elabora el plan de trabajo y sirven de faro para verificar que el proyecto marcha adecuadamente. Puede verse entonces el desarrollo incremental e iterativo, planteado por RUP, como una serie de iteraciones, cada una de las cuales se realiza siguiendo el modelo en cascada. Por esta razón RUP organiza las actividades de desarrollo siguiendo dos criterios ortogonales como se muestra en la figura Nº1. En el eje vertical, se describen las actividades fundamentales y que en términos de RUP se denominan componentes. El nivel de intensidad del trabajo en cada componente se representa mediante la amplitud de la gráfica asociada. En el eje horizontal, se describen los criterios para la planeación y control en el tiempo. Corresponden a la dinámica del proceso de desarrollo pues establecen cuándo se deber realizar las acciones definidas por los componentes. Los componentes del proceso de desarrollo establecen cómo avanzar en la conceptualización y construcción del sistema, agrupando las actividades de acuerdo al nivel de abstracción en el que están localizadas y su naturaleza y establecen qué hay que hacer, quién debe hacerlo y cómo hacerlo.

Figura Nº 1 Cada componente se describe en los siguientes términos:


Procedimiento P31


Página 4 de 15

1. Artefactos: representan cualquier tipo de información generada, modificada o utilizada en el desarrollo del sistema. Por ejemplo: en el componente de Análisis se elaboran las Clases de Análisis. 2. Trabajadores: que corresponden a los roles (una misma persona puede desempeñar varios roles) que intervienen en el componente. Por ejemplo: En el componente Análisis el Arquitecto participa en la elaboración de las Clases de Análisis. 3. Flujos de trabajo y actividades: que deben ser adelantadas por los trabajadores para obtener los artefactos del componente. Existen dos tipos de componentes: los del proceso de ingeniería, que se refieren a las actividades relacionadas en forma directa con la obtención del producto, y los de soporte, que se refieren a las actividades administrativas del proceso. Los componentes del proceso de ingeniería son: 1. Modelado de la Organización: Consiste en la identificación y documentación de la estructura y funcionamiento de la organización en la cual operará la aplicación a desarrollar. Su objetivo es brindar un entendimiento a clientes y desarrolladores sobre cuál es el problema de la organización, identificar mejoras potenciales y establecer el impacto que la aplicación a desarrollar tendría sobre la organización. 2. Captura de Requisitos. Su propósito es obtener la descripción de para qué sirve el sistema, y lograr un acuerdo entre el equipo de desarrollo y el cliente, en este aspecto. 3. Análisis. En este componente se define la estructura (clases, paquetes, etc.) y comportamiento del sistema. Su propósito es obtener una descripción de cómo funciona el sistema. 4. Diseño. Mientras que Análisis se ha centrado en establecer la funcionalidad del sistema, el componente de Diseño se enfoca a lograr que esa funcionalidad se haga posible sobre una arquitectura física (computadores, redes, etc.) y un entorno de implementación (sistemas operativos, lenguajes de programación, etc.) dados. Su propósito es obtener una descripción de cómo se construye el sistema. 5. Implementación. Construcción del sistema, ejecutables, de configuración, librerías, etc.

obteniendo

los

archivos

6. Pruebas. Se verifican los modelos, prototipos y demás artefactos ejecutables del sistema bajo desarrollo. 7. Puesta en Servicio. En este componente se realizan las actividades requeridas para poner en funcionamiento el producto en las instalaciones del cliente.

b) Vista General del Proyecto (Plan de Desarrollo de Software) i) Propósito, Alcance y Objetivos

La información que incluye será extraída de las diferentes reuniones con los responsables y usuarios de las áreas o departamentos desde el inicio del

Procedimiento P31



proyecto, por ello en este artefacto se deberá incluir las razones por las que se considera necesario el desarrollo de un nuevo sistema, y proporcionar una propuesta para el desarrollo de todos los subsistemas implicados en la gestión y administración de las áreas y departamentos. ii) Suposiciones y Restricciones

En este apartado se describe las suposiciones y restricciones respecto del sistema, y que se derivan directamente de las entrevistas con los responsables y usuarios de las áreas o departamentos, esto debe contemplar lo siguiente: 1) Implicancias de los siguientes puntos críticos:

•

Compatibilidad.

•

Cumplimientos con Estándares.

•

Protección de información.

•

Gestión de flujos de trabajo, seguridad de transacciones e intercambio de información

•

Adaptación a la normativa de Protección de Datos

2) Para el caso de las restricciones, la legislación vigente que rige a los

procesos automatizados. Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del proyecto, particularmente una vez establecido el artefacto “Visión”. iii) Entregables del proyecto

A continuación se indican y describen cada uno de los artefactos que serán generados y utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la configuración de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto. Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos del proyecto están enfocados a conseguir un cierto grado de completitud y estabilidad de los artefactos. Esto será indicado en los objetivos de cada iteración.

• Plan de Desarrollo de software Este documento fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo, identifica las actividades, hitos y entregas del producto. Se debe tener un plan para guiar el desarrollo hacia las metas del proyecto. • Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos, permite situar al sistema en el contexto organizacional

Procedimiento P31



haciendo énfasis en los objetivos en este ámbito. Este modelo se representa con un Diagrama de Casos de Uso.

• Modelo de Objetos del Negocio Es un modelo que describe la realización de cada caso de uso del negocio, estableciendo los actores internos, la información que en términos generales manipulan y los flujos de trabajo (workflows) asociados al caso de uso del negocio. Para la representación de este modelo se utilizan Diagramas de Colaboración (para mostrar actores externos, internos y las entidades (información) que manipulan, un Diagrama de Clases para mostrar gráficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo. • Glosario Es un documento que define los principales términos usados en el proyecto. Permite establecer una terminología consensuada. . • Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso. • Visión Este documento define la visión del producto desde la perspectiva del cliente, especificando las necesidades y características del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema. • Especificaciones de Casos de Uso Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de Actividad. • Especificaciones Adicionales Este documento capturará todos los requisitos que no han sido incluidos como parte de los casos de uso y se refieren requisitos no-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas, aplicación de estándares, requisitos de calidad del producto, tales como: confiabilidad, desempeño, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc.

Procedimiento P31



• Prototipos de Interfaces de Usuario Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este artefacto, será desechado en la fase de Construcción en la medida que el resultado de las iteraciones vayan desarrollando el producto final. • Modelo de Análisis y Diseño Este modelo establece la realización de los casos de uso en clases, pasando desde una representación en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de implementación), de acuerdo al avance del proyecto. • Modelo de Datos Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases. • Modelo de Implementación Este modelo es una colección de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de ficheros necesarios para la implantación y despliegue del sistema. (Este modelo es sólo una versión preliminar al final de la fase de Elaboración, posteriormente tiene bastante refinamiento). • Modelo de Despliegue Este modelo muestra el despliegue de la configuración de tipos de nodos del sistema, en los cuales se hará el despliegue de los componentes. • Casos de Prueba Cada prueba es especificada mediante un documento que establece las condiciones de ejecución, las entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de regresión en cada iteración. Cada caso de prueba llevará asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podrá ser automatizable mediante un script de prueba.

Procedimiento P31



• Solicitud de Cambio Los cambios propuestos para los artefactos se formalizan en este documento. Mediante el cual, se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los requisitos del producto. Así se provee un registro de decisiones de cambios, de su evaluación e impacto, y se asegura que éstos sean conocidos por el equipo de desarrollo. Los cambios se establecen respecto de la última base line (el estado del conjunto de los artefactos en un momento determinado del proyecto) establecida. • Plan de Iteración Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos asignados y dependencias entre ellas. Se realiza para cada iteración, y para todas las fases. • Evaluación de Iteración Este documento incluye la evaluación de los resultados de cada iteración, el grado en el cual se han conseguido los objetivos de la iteración, las lecciones aprendidas y los cambios a ser realizados. • Lista de Riesgos Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones específicas de contingencia o para su mitigación. • Manual de Instalación Este documento incluye las instrucciones para realizar la instalación del producto. • Material de Apoyo al Usuario Final Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías de Mantenimiento y Sistema de Ayuda en Línea • Producto Constituido por los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos apropiados para facilitar su instalación. El producto, a partir de la primera iteración de la fase de Construcción, es desarrollado incremental e iterativamente, obteniéndose una nueva reléase al final de cada iteración. Los artefactos Manual de Instalación, Material de apoyo al Usuario Final y Producto se generarán a partir de la fase de Construcción, con lo cual se han


Procedimiento P31


Página 9 de 15

incluido aquí sólo para dar una visión global de todos los artefactos que se generan en el proceso de desarrollo. iv) Evolución del Plan de Desarrollo de software

Se propone que el Plan de Desarrollo de software se revise semanalmente y se refine antes del comienzo de cada iteración. Los periodos de revisión dependerán del tipo de proyecto de software.

c) Organización del Proyecto i) Participantes en el Proyecto

Describe el personal que el departamento o área designará como Responsable del Proyecto, Comité de Control y Seguimiento, y otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema. El personal propuesto para el proyecto, considerando las fases de Inicio, Elaboración y las iteraciones de la fase de Construcción, estará formado por los siguientes puestos de trabajo: • Jefe de Proyecto: Nombre del responsable, titulo y experiencia. • Analista de Sistemas: Nombre del responsable, titulo y experiencia. • Analistas – Programadores. Nombre del responsable, titulo y experiencia • Ingeniero de Software: Nombre del Responsable, titulo y experiencia La cantidad de profesionales asignados dependerá del proyecto de software a desarrollar. ii. Interfaces Externas

Los responsables del proyecto definirán quienes serán los participantes del proyecto que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada subsistema y según el plan establecido. El equipo de desarrollo interactuará activamente con los stackholders para la especificación y validación de los artefactos generados. iii. Roles y Responsabilidades

A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo propuesto durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP.

Puesto

Responsabilidad

Jefe de Proyecto

El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. También establece un conjunto de prácticas que aseguran la integridad y calidad de los artefactos del proyecto. Además, se encargará de supervisar el establecimiento de la arquitectura del sistema, Gestión de riesgos, Planificación y

Procedimiento P31



control del proyecto. Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante Analista de Sistemas entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos. Construcción de prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario

Programador

Ingeniero Software

Gestión de requisitos, gestión de configuración y cambios, de elaboración del modelo de datos, preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.

d) Gestión del Proyecto i) Estimaciones del Proyecto

El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado. ii) Plan del Proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto. •

Plan de las Fases

El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas, dependiendo del tipo de proyecto de software. La siguiente tabla muestra una posible distribución de tiempos y el número convenientes de iteraciones de cada fase.

Fase

Nro. Iteraciones

Duración

Fase de Inicio

1

3 semanas

Fase de Elaboración

1

2 semanas

Fase de Construcción

2

7 semanas

Procedimiento P31

Proceso de Desarrollo del Software (RUP Fase de Transición

-


-

Los hitos que marcan el final de cada fase se describen en la siguiente tabla. Descripción

Hito

Fase de Inicio

En esta fase se analizar los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta fase.

Fase de Elaboración

En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera reléase de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes, la revisión y entrega de todos los artefactos hasta este punto de desarrollo también se incluye como hito. La primera iteración tendrá como objetivo la identificación y especificación de los principales casos de uso, así como su realización preliminar en el Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrán una duración de una semana.

Fase de Construcción

Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una reléase a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la reléase 3.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta.

Procedimiento P31


Fase de Transición

•


En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto.

Calendario del Proyecto

En este artefacto de debe especificar un calendario de las principales tareas del proyecto, a modo de ejemplo se incluye en esta sección un calendario solo con las dos primeras fases. Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente pero van desarrollándose en mayor o menor grado, de acuerdo a la fase e iteración del proyecto. Se muestra el siguiente calendario para un proyecto genérico. La fecha de aprobación indica cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a revisión y aprobación, pero esto no quita la posibilidad de su posterior refinamiento y cambios. Disciplinas / Artefactos generados o modificados Comienzo durante la Fase de Elaboración

Aprobación

Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Semana 1 Objetos del Negocio

aprobado

Requisitos Glosario

Semana 1

aprobado

Visión

Semana 2

aprobado

Modelo de Casos de Uso

Semana 3

Semana 5

Especificación de Casos de Uso

Semana 3

Semana 5

Especificaciones Adicionales

Semana 3

Semana 5

Semana 2

Revisar en cada iteración

Análisis / Diseño Modelo de Análisis / Diseño

Procedimiento P31



Semana 2


Prototipos de Interfaces de Usuario

Semana 3


Modelo de Implementación

Semana 3


Semana 3


Modelo de Despliegue

Semana 3


Gestión de Cambios y Configuración

Durante todo el proyecto

Modelo de Datos Implementación

Pruebas Casos de Pruebas Funcionales Despliegue

Gestión del proyecto Plan de Desarrollo de software en su versión 2.0 y Semana 4 planes de las Iteraciones Ambiente


Durante todo el proyecto

iii) Seguimiento y Control del Proyecto (1) Gestión de Requisitos

Los requisitos del sistema son especificados en el artefacto Visión. Cada requisito tendrá una serie de atributos tales como importancia, estado, iteración donde se implementa, etc. Estos atributos permitirán realizar un efectivo seguimiento de cada requisito. Los cambios en los requisitos serán gestionados mediante una Solicitud de Cambio, las cuales serán evaluadas y distribuidas para asegurar la integridad del sistema y el correcto proceso de gestión de configuración y cambios. (2) Control de Plazos

El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto y por el Comité de Seguimiento y Control. (3) Control de Calidad

Procedimiento P31



Los defectos detectados en las revisiones y formalizados también en una Solicitud de Cambio tendrán un seguimiento para asegurar la conformidad respecto de la solución de dichas deficiencias. Para la revisión de cada artefacto y su correspondiente garantía de calidad se utilizarán las guías de revisión y checklist (listas de verificación) incluidas en RUP. (4) Gestión de Riesgos

A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las acciones establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista será evaluada al menos una vez en cada iteración. (5) Gestión de Configuración

Se realizará una gestión de configuración para llevar un registro de los artefactos generados y sus versiones. También se incluirá la gestión de las Solicitudes de Cambio y de las modificaciones que éstas produzcan, informando y publicando dichos cambios para que sean accesibles a todo los participantes en el proyecto. Al final de cada iteración se establecerá una baseline (un registro del estado de cada artefacto, estableciendo una versión), la cual podrá ser modificada sólo por una Solicitud de Cambio aprobada. 4. Anexos. N/A 5. Registros. REGISTRO Plan Desarrollo Software

RESPONSABLE CONFECCIÓN

ARCHIVO RESPONSABLE LUGAR

de Miembro del Miembro de Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento Diagrama de Miembro del Miembro Casos de Uso Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento Diagrama de Miembro del Miembro Colaboración Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento Diagrama de Miembro del Miembro Clases Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento Diagrama de Miembro del Miembro Actividades Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento Manual de Miembro del Miembro Especificaciones Departamento Desarrollo Departamento Adicionales y Mantenimiento Desarrollo Mantenimiento Manual de Miembro del Miembro Solicitud de Departamento Desarrollo Departamento Cambio y Mantenimiento Desarrollo Mantenimiento Registro de Miembro del Miembro Evaluación de Departamento Desarrollo Departamento Iteración y Mantenimiento Desarrollo Mantenimiento

TIEMPO DE RETENCIÓN

DISPOSICIÓN

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

Indefinido

Activo

del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento del Desarrollo y y Mantenimiento

Procedimiento P31

Proceso de Desarrollo del Software (RUP Registro Listado Riesgos Manual Instalación

del Miembro del Miembro de Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento de Miembro del Miembro Departamento Desarrollo Departamento y Mantenimiento Desarrollo Mantenimiento


del Desarrollo y y Mantenimiento

Indefinido

Activo

Indefinido

Activo

del Desarrollo y y Mantenimiento

6. Referencias. •

Libro: Ingeniería de Software - Ian Sommerville - Prentice Hill – Séptima Edición - 2005

•

Libro: El proceso unificado de desarrollo de software - Ivar Jacobson, Grady Booch y James Rumbaugh - Pearson Addisson-Wesley. Año 2000.

•

Libro: Aprendiendo UML En 24 Horas - Joseph Schmuller - Prentice Hall1era Edición – 2001.

•

Referencia WEB: Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software - Versión 3.0

•

Norma ISO 9001:2008.

•

Manual de la Calidad de la SECRETARIA DE GESTION ADMINISTRATIVA Y RRHH.

31-Procedimiento de Desarrollo Del Software[1]

Recommend Documents