Software Progam Management Plan by JNieves86

VIEWS: 29 PAGES: 15

Summary of a Software Engingeering Project to learn how to document a program under the reqs of the IEEE. (On Spanish)

More Info
									                            Universidad Politécnica De Puerto Rico
                          Departamento De Ingeniería En Computadoras
                           Especificación de requerimientos del software




                            Hospital Information & Security Systems
                                Software Project Management Plan

                                         Version 1.0




                                      Trinity developers
José A. Hernández Salvá                                        #67972      COE
Faustino Delgado Camacho                                       #58125      COE
Jesus J. Nieves Padilla                                        #49652      COE
Angel A. Rodriguez Orta                                        #60553      COE




                          CECS 4204 Sotware engineering Sección 22
                              Winter 2011 Febrero 2 del 2012
                               Profesor Luis Ortiz Ortiz

 Historial de Cambios


Versión           Autores                    Tarea Realizada     Fecha


  1.0           Jesús Nieves       Edición primera versión     2/01/2011
Prólogo
El Plan de Manejo De Proyecto del Software (SPMP en ingles) describe el plan que se propone
tomadas por Trinity Developers para completar la parte del software del proyecto Hospital
Information & Security System (HISS).

Como tal, sólo se refiere a la entrega del componente de software del proyecto
y tiene dependencias en las partes de hardware y de red, que Trinity ha dicho serán tratados como
proyectos separados para HISS.

Este plan está destinada a ser utilizada por el Comité Ejecutivo del hospital cliente con el
propósito de evaluar respuesta a la solicitud de propuesta emitida por Trinity para la entrega del
producto y del servicio ofrecido por HISS.
Tabla de Contenido
1.1 Resumen del Proyecto
1.1.1 Proposito, Alcance y Objetivos
El propósito del proyecto es analizar las necesidades de, diseñar, implementar y mantener
elsoftware para el servidor del hospital cliente y las máquinas cliente para pacientes y público
que estará compuesto por la red de la base de datos de pacientes, doctores y equipo de seguridad,
de acuerdo con los requisitos especificados por el cliente.

Todas las actividades directamente relacionadas con el propósito se consideran en el ámbito de
aplicación. Todas las actividades no directamente relacionadas con los efectos se consideran
fuera del ámbito de las funciones del sistema.

Los objetivos del proyecto son:
   • Completar el proyecto a la fecha establecida.
   • No exceder del presupuesto asignado para el proyecto.
   • Realizar a tiempo catálogo de la sección 1.1.3.
   • Cumplir con todo los requisitos propuestos en el SRS.


1.1.2 Restricciones y Supuesto
El proyecto asume que:
    • Este proyecto compone un proyecto mayor.
    • Este proyecto se enfatizará del lado software del proyecto.
    • El proyecto mayor ya está asumido con el hardware necesario y el software de Linux
       como sistema operativos, Oracle manejado la base de datos y Windows XP corriendo el
       servidor central.
    • Los terminales tienen disponible su documentación.
    • Un documento físico de la red será trabajado como otro proyecto.
    • Este plan asume que el proyecto está bajo los requisitos dentro del presupuesto.
    • Trinity Developers se compromenten al mantenimiento del sistema.

Las restricciones del proyecto incluye:
   • Presupuesto:
   • Tiempo:
   • Equipo: El hospital cliente contará con un administrador IT para el manejo interno y
        mantenimiento del sistema con asistentes adiestrando empleados del hospital.
   • Mantenimiento: Se diseña el sistema para que requiera un mantenimiento de al menos
        una porción del presupuesto anual para el sistema.

1.1.3 Metas del proyecto
Todos los elementos que figuran en esta sección son las metas del proyecto solicitada por el
hospital cliente que se van a cumplir antes de la finalización del proyecto.
    • El software físico y sus dependencias.
    • Documentación que incluye: Instalación, Manual de usuario y actualizaciones.
   •   Instalación.
   •   Training.
   •   Documentación del proyecto.
   •   Software Project Management Plan (SPMP)
   •   Software Requierments Specifications (SRS)
   •   Software Test Plan (STP)
   •   Software Design Description (SDD)

1.1.4 Programa Calendario y Presupuesto
El proyecto tiene programado con entrega para el 22 de Febrero del 2012 y puesto en
funcionamiento para el mes después.

El proyecto tiene como presupuesto $10,000.

1.2 Evolución del Plan
El plan es considerado como un documento dinámico y se actualiza mensualmente por defecto y
de forma no programada cada vez que sea necesario. Actualizaciones programadas en el plan se
producirá una vez al mes, en el último día hábil del mes.

Notificación de actualizaciones programadas y no programadas en el plan se comunicará vía e-
mail a todos los participantes en el proyecto de acuerdo con el Plan de Información.

Una vez que el plan inicial ha finalizado, una línea de base del plan se creará. Los cambios en el
plan llevará a cabo en contra de esta línea de base.
El plan sólo recibirá líneas de base más si un cambio significativo en el ámbito de aplicación se
produce.
2 Referencias
2.1 Software Requierments Specifications
Versión                                           1.2
Fecha                                             Diciembre 22, 2012
Autor                                             Trinity Developers
Acceso                                            /Trinity/Software/SRS


2.2 Software Design Specifications
Versión                                           1.2
Fecha                                             Diciembre 22, 2012
Autor                                             Trinity Developers
Acceso                                            /Trinity/Software/SDS


2.3 Software Test Plan
Versión                                           1.2
Fecha                                             Diciembre 22, 2012
Autor                                             Trinity Developers
Acceso                                            /Trinity/Software/STP


2.4 Software Design Description
Versión                                           1.2
Fecha                                             Diciembre 22, 2012
Autor                                             Trinity Developers
Acceso                                            /Trinity/Software/SRS


2.5 Quality Software Project Management
Futrell, R. T., Shafer, D. F., Shafer, L. I. (2002). Quality software project management . Upper
Saddle River, N.J.: Prentice Hall PTR.

2.6 IEEE Standard 1063 – 2001
2.7 IEEE Standard 830 – 1998
2.8 IEEE Standard 1016 – 1998
2.9 IEEE Standard 1058 – 2001

2.10 Trinity Standard Documentation
Versión                                           1.2
Fecha                                             Diciembre 22, 2012
Autor                                             Trinity Developers
Acceso                                            /Trinity/Software/Trinitysd
2.11 Trinity Test Plan Template
Versión                                         1.2
Fecha                                           Diciembre 22, 2012
Autor                                           Trinity Developers
Acceso                                          /Trinity/Software/Trinitytpt

3   Definiciones
                                    Definiciones

                            Termino general que se refiere a diferentes tipos de
                         programas usados para operar las computadoras y equipos
        Software
                                               relacionados

       Hardware            Describe el componente físico de una computadora y
                                           equipos relacionados.

                        Es un conjunto de datos pertenecientes a un mismo contexto
                          y almacenados sistemáticamente para su uso posterior.
     Base De Datos

                         Es el programa o conjunto de programas que controla las
                        gestiones y los recursos de cualquier equipo o computadora
    Sistema Operativo

                            Es una red que conecta computadoras y equipos con
                               conexión en un área relativamente pequeña y
          LAN
                            predeterminada de forma alámbrica o inalámbrica.

         Oracle           Sistema de gestión de base de datos relacional con SQL.



      Windows XP              Sistema operativo de Microsoft desde el 2001.

          Red           Sistema de comunicación entre computadoras que permite la
                            transmisión de datos de una maquina a la otra o de
                                         computadora a terminal.

        Interfaz          Es el medio que el usuario puede comunicarse con una
                                   máquina, equipo o una computadora.

          SDD                          Software Design Description
          SRS                        Software Requierments Specification

          STD                               Software Testing Design




4 Organización del Proyecto
4.1 Interfaces
A pesar de ser contratados externamente por el hospital cliente, nuestra organización es integral
con el hospital, debido al diseño del sistema está físicamente en las facilidades del hospital y
naturalmente representantes y equipo técnicos de Trinity Developers deben estar atentos a
cualquier eventualidad ya sea del lado hardware o software del proyecto.

Se negociaría con el hospital cliente separar un espacio de la planta física para que Trinity
Developers pueda tener presencia. Adicional nuestro plan de mercadeo incluye un presupuesto
para que del lado de recursos humanos, el hospital no se vea afectado ya que Trinity Developers
estará a cargo de la contratación del personal de administración IT del servicio o si el hospital ya
cuenta con un departamento de IT, se integraría de forma paralela para la mejor implementación
del sistema HISS.

4.2 Estructura Interna
El personal del hospital, aunque nuestro departamento IT estaría al pendiente del monitoreo del
sistema, será responsable por notificar cualquier anomalía dentro del sistema del que el
departamento IT no estuviera al pendiente o al momento no pudo ser monitoreado.

4.3 Responsabilidades
El mantenimiento físico de los terminales y componentes de Hardware será responsabilidad de
todo usuario incluyendo doctores, enfermeros, seguridad, pacientes y miembros IT.

El mantenimiento del software estará a cargo del departamento IT, mientras que cualquier
mantenimiento fuera de programa se debe solicitar con tiempo anticipado, pues se programarán
mantenimientos regulares.
5   Plan Administrativo

5.1 Plan Estimado
    • Programa, Costo y Recursos Estimados
Metodos:
       A. Entrada de recursos: Para el recurso identificado como necesario para completar la
          actividad, el recursos se solicitará un estimado de la cantidad de tiempo requerido
          para completarla actividad.

           Una estimación detallada se solicitará, desglosados en subactividad y será vinculado a
           la subactividad en métrica de "% completado".

       B. Cuando más de un recurso está asignado a la actividad, sus estimaciones serán
          recogidos de forma independiente y, si es muy diferente, las reuniones se realizará
          entre el director del proyecto y todos los recursos para que un acuerdo puede ser
          llegar a una estimación final.

Dato historico del proyecto:
       A. Trinity Developers podría referirse a proyectos pasados exitosamente como referencia
           a los futuros que estén en proceso para el actual financiamiento del desarrollo del
           programa.

Dato histórico del cliente:
       A. Trinity Developers podría referirse a proyectos pasados exitosamente del cliente
           adicional como referencia a los futuros que estén en proceso para el actual
           financiamiento del desarrollo del programa.

Estimados de costos para cada actividad se llevará a cabo mediante la multiplicación de la
cantidad de trabajo que se espera por la tarifa por hora para los recursos vinculados a la
actividad, multiplicado por el porcentaje de la participación que cada recurso tiene previsto
realizar a la actividad.

Las estimaciones resultantes para cada actividad de la hoja será enrollado para producir una
estimación para el mayor conjunto de actividades que la actividad es una parte.

   • Re -Estimados
Metodos:
      A. Entrada de recursos: La estimación de la cantidad de trabajo restante en la tarea se
         recogerán a partir de cada recurso. Una estimación detallada se solicita, que muestra
         el desglose de trabajo restante, junto con los hitos de identificación subactividad.
       A. Entrada de Hospital cliente: Se le pedirá el hospital que desarrolle un análisis de todos
          los trabajos completados por los recursos



Programación de Re-Estimados:
El tiempo ha sido asignado en la programación de actualizaciones mensuales SPMP.
Actualizaciones necesarias para la estimaciones de costos, el calendario y los recursos se
incluirán en estas actualizaciones. Sin embargo, sólo se llevará a cabo en circunstancias
extremas, como cuando cambio un amplio margen se ha introducido.

El propósito de estas actualizaciones mensuales es forzar el tiempo asignado y para proporcionar
una programación en la que los interesados podrán ver las actualizaciones del plan.

Una revisión del SPMP se publicará después de cada una de estas sesiones de actualización con
independencia de silos cambios significativos se han hecho por lo que es obvio para todos los
involucrados que la actualización programada se ha producido.

Actualizaciones improvisada con el plan de la estimación se realizará como las que sean
necesarias y comunicará a las áreas afectadas. En particular, la explicación detallada a
continuación para el manejo de la comunicación de estos tipos de actualizaciones:
   • Recursos: Si se requiere un aumento, que áreas se afectarán y la función en jerarquía a
       afectarse.
   • Costo: Si el aumento afecta y/o excede o no del presupuesto.
   • Programa: Si afecta las metas y si serán cumplidas a tiempo o no.
6   Plan de Proceso Gerencial

6.1 Tareas y Responsabilidades
                   NOMBRE                                      RESPONSABILIDAD
    Jesus J. Nieves Padilla                        Planificación y diseño Documentación,
    Faustino Delgado Camacho                       Codificación y Reportes
    José A. Hernández Salvá                        Codificación y programación
    Angel A. Rodriguez Orta                        Interface gráfica


6.2 Plan de Trabajo
6.2.1 Actividades
SPMP
SRS
Casos de Usos
Diagramas de Clase
Diagrama de Secuencias
Orden de Interface
Código
Constuir Base de Datos
Agrgar Tablat a Base De Datos
Crear procedimientos
Conectar interface a la base de datos
Crear Reporte de registros

6.3 Requisitos de plan de control
    Cada semana se revisará todas las tareas que competen a todos los miembros del equipo, no
    se tomará en cuenta un presupuesto fijo para implementar planes que se diseñen a ultimo
    momento, pues se toma en cuenta que la plataforma enfrentará el día a día de operación que
    siempre tiende a ser variable.

6.4 Contro de calidad
    Los métodos, procedimientos almacenados y las páginas web se pondrá a prueba a medida
    que se crean. Todos los artículos serán reexaminados cuando se conecta a otros objetos.

    Todo el sistema será probado sobre la terminación de la creación de un plan, además de los
    cursos a un plan, la eliminación de los cursos de un plan, además de un mayor, menor, y el
    énfasis, extracción de una mayor, menor, y el énfasis y la validación de los resultados.
   Pruebas de Límites se llevará a cabo siempre que sea posible y aplicable.




6.5 Plan de manejos de riesgos
                        Riesgo                                  Como se manejara
    Deficiencia en el conocimiento y               Se construye un prototipo y se cataloga todo
    entendimiento de un problema y su solución     lo erróneo que ocurra.
    Desconocimiento de técnicas y herramientas     Se actualizará los KB (Knowledge Base)
                                                   requeridos de los productos,
7   Proceso técnico

7.1 Modelo de proceso
    El modelo unificado será el modelo utilizado será utilizado para el manejo de este proyecto.

7.2 Plan de aceptación del producto
    Los clientes podrán probar el producto final / solicitud de admisión. Se hará una presentación
    hecho del producto terminado en el último día de clase (23 de Febrero de 2012).

7.3 Plan de proceso de soporte
    El cliente se le pedirá que especifique si ha encontrado en algún momento algún error o hay
    alguna parte del producto que requiere alguna mejora.

    Se le solicitará de manera mensual que el cliente someta información que el sistemas estará
    compilando del uso y manejo del producto para propósitos de calidad y de mejoramiento del
    producto, que será incluido de manera ordinaria para el seguimiento debido con el cliente.

    Adicional, el cliente puede de manera adelantada o de forma extraordinaria, reportar algún
    error, problema o sugerencia para la verificación y optimización del producto, sin afectar las
    operaciones de soporte.

    El método de soporte estará siendo negociado con el cliente.

7.4 Plan de manejo de configuraciones
    El control de versiones será administrado por la comprobación de documentos y el código
    será copiado en los servidores para acceso a los técnicos del producto.

    Las partes finales estará integrado por los métodos de planificación previa y tipos de
    devolución. Los componentes individuales se probaron antes de tiempo para asegurar que los
    valores correctos se devuelven para propósito de. Las personas responsables de los
    componentes estará presente cuando las partes son integrado. Los componentes se pondrá a
    prueba una vez más para asegurar el correcto funcionamiento cuando están conectadas entre
    sí.

7.5 Plan de validación y verificación
    Todos los módulos serán probados individualmente durante una y otra vez después de que se
    codifican utilizando valor límite pruebas para asegurar resultados correctos se devuelven.
   Módulos de mayor nivel se pondrá a prueba tanto con los talones y con el código
   completamente funcional en el módulos inferiores.

    Todos los módulos se pondrá a prueba con varios escenarios preparadas de antemano con
    datos en tiempo real en la prueba base de datos. Las pruebas se llevarán a cabo en un plan de
    estudiante de vacío, una parte completa plan de estudiante, y un "verificado" plan de los
    estudiantes. Todos los requisitos enumerados en el SRS será
    probado en el producto final.
7.6 Plan de documentación
    Todo el código se documentarán como se escribe.

   Un set en línea de instrucciones se proporcionarán para las funciones que requieran
   aclaración.

   Se intentará hacer la interfaz gráfica de usuario intuitiva. Este documento, junto con los otros
   documentos enumerados en las entregas también se proporcionará.

7.7 Plan de calidad
    El producto se pondrá a prueba como se especifica en el apartado 7.5. Los errores se
    corregirán de inmediato si descubierto durante codificación inicial del módulo. Errores
    detectados durante la codificación de diferentes módulos o durante la prueba final será
    documentado y presentado al grupo de corrección.

7.8 Auditorias
    Al momento cuando el proyecto este corriendo con el cliente, se determinará con el mismo
    las auditorias.

7.9 Plan de resolución de problemas
    Todo problemas será resuelto entre los involucrados del proyecto que incluye auditores,
    desarrolladores y el cliente del proyecto.

7.10 Plan de mejoras de proceso
    A lo largo de la evolución del proyecto y amparándose en el apartado 7.3, en conjunto con el
    cliente se determinaría y catalogaría todo lo que sea imprescindible mejorar al proyecto

								
To top