Constructores de vivienda asociados ERP. Sistema ERP Constructores de vivienda asociados Plan de Desarrollo Software. Versión 0.1

Transcripción

1 Constructores de vivienda asociados ERP Sistema ERP Constructores de vivienda asociados Plan de Desarrollo Software Versión 0.1

2 Historial de Revisiones Fecha Versión Descripción Autor 22/06/ Versión preliminar como propuesta de desarrollo. Sergio Valero Orea 29/06/ Versión revisada por el profesor Sergio Valero Orea Confidencial ITZOFT, 2009 Página 2 de 16

3 Tabla de Contenidos 1. Introducción Propósito Alcance Resumen Vista General del Proyecto Propósito, Alcance y Objetivos Suposiciones y Restricciones Entregables del proyecto Organización del Proyecto Participantes en el Proyecto Gestión del Proceso Estimaciones del Proyecto Plan del Proyecto Plan de las Fases Calendario del Proyecto Matriz de roles y responsabilidades Seguimiento y Control del Proyecto Infraestructura necesaria ANEXO 1 Plan de gestión de riesgos ANEXO 2 Plan de gestión de la configuración ANEXO 3 Plan de aseguramiento de la calidad ANEXO 4 Modelo del dominio ANEXO 5 Modelo de casos de uso Confidencial ITZOFT, 2009 Página 3 de 16

4 Plan de Desarrollo de Software 1. Introducción Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la propuesta elaborada como respuesta al proyecto de creación de un ERP a la medida para inmobiliarias y constructoras que brinde información en tiempo real de la situación financiera y de su estado de cada uno de los desarrollos ubicados en cualquier parte de la República. Este documento provee una visión global del enfoque de desarrollo propuesto. El proyecto ha sido basado en una metodología de Rational Unified Process (RUP), Es importante destacar esto puesto que utilizaremos la terminología de dicha metodología en este documento. Se incluirá el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla un plan de negocio para determinar qué recursos deben ser asignados al proyecto. El enfoque desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP. 1.1 Propósito El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo del software. Los usuarios del Plan de Desarrollo del Software son: El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y para realizar su seguimiento. Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer, cuándo deben hacerlo y qué otras actividades dependen de ello. 1.2 Alcance El Plan de Desarrollo del Software describe el plan global usado para el desarrollo del Sistema ERP para constructores de vivienda y asociados. El detalle de las iteraciones individuales se describe en los planes de cada iteración, documentos que se aportan en forma separada. Durante el proceso de desarrollo en el artefacto Visión se definen las características del producto a desarrollar, lo cual constituye la base para la planificación de las iteraciones. Para la versión 0.1 del Plan de Desarrollo del Software, nos hemos basado en la captura de requisitos por medio del stakeholder representante de la empresa para hacer una estimación aproximada, una vez comenzado el proyecto y durante la fase de Inicio se generará la primera versión del artefacto Visión, el cual se utilizará para refinar este documento. Posteriormente, el avance del proyecto y el seguimiento en cada una de las iteraciones ocasionará el ajuste de este documento produciendo nuevas versiones actualizadas. Confidencial ITZOFT, 2009 Página 4 de 16

5 1.3 Resumen Después de esta introducción, el resto del documento está organizado en las siguientes secciones: Vista General del Proyecto proporciona una descripción del propósito, alcance y objetivos del proyecto, estableciendo los artefactos que serán producidos y utilizados durante el proyecto.. Organización del Proyecto describe la estructura organizacional del equipo de desarrollo. Gestión del Proceso explica los costos y planificación estimada, define las fases e hitos del proyecto y describe cómo se realizará su seguimiento. Infraestructura proporciona los requerimientos necesarios para poder implementar la solución propuesta. Son los requisitos para que el sistema funcione adecuadamente. 2. Vista General del Proyecto 2.1 Propósito, Alcance y Objetivos La información que a continuación se incluye ha sido extraída de las diferentes reuniones que se han celebrado en clase desde el inicio del proyecto. Constructores de vivienda asociados es una empresa que se dedica al desarrollo de proyectos inmobiliarios. La entrada en un mercado competitivo como en el que encuentra inmersa esta empresa conllevará una previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello, Constructores de vivienda asociados considera necesario el desarrollo de un nuevo sistema de planificación empresarial (ERP) para el control adecuado de cada uno de sus procesos. Dicho sistema deberá proporcionar información en tiempo real de la situación financiera y el estado de cada uno de los desarrollos ubicados en cualquier parte de la República. Las características requeridas del sistema deberán ser las siguientes: Planeación de proyectos de inversión (Conformación de presupuestos). Se deberá llevar a cabo la gestión de: o gestión de proyectos o presupuestos o gastos o compras asociadas o informes de presupuestos o gastos internos y facturables o informes de actividades o informe de rentabilidad de proyectos o registro de servicios o estimaciones Control de almacenes por obra (entradas/salidas). Se deberá controlar: o almacenes por obra y su respectivo stock Confidencial ITZOFT, 2009 Página 5 de 16

6 o atributos del producto en almacén o movimientos entre almacenes o inventario de obras (físico) o movimientos en obra o lotes, números de serie, bultos, etiquetas o entradas, salidas, inventarios y transportes. Compras y proveedores. Se deberá gestionar: o pedidos de compras o gestión de órdenes de compra en base a presupuesto o recepción de mercancías o verificación de facturas de proveedores o evaluación de proveedores o planificación de compras o relación entre pedidos o notas de entrega y facturas o informes de pedidos de compra Control de avance de obra (visualización gráfica). Se debe gestionar: o planos de ubicación de las viviendas o tipo de vivienda o avance de la construcción del desarrollo o estado de la vivienda Comercialización de viviendas (Preventa, Postventa, comisiones). Se deberá controlar: o proceso de facturación o facturas clientes o manejo de comisiones o procesos de venta Administración de créditos o gestión de créditos o manejo de cuentas o presupuestos estimados y ejecutados Administración de trámites notariales y permisos de construcción o Almacén de datos para documentos legales (digital) o Órdenes de construcción Nómina. Se deberá gestionar: o registro y control de empleados o manejo de percepciones y deducciones o emisión de reportes de nómina o manejo de recibos de honorarios o nómina semanal, catorcenal, quincenal y mensual o manejo de impuestos 2.2 Suposiciones y Restricciones Las suposiciones y restricciones respecto del sistema, y que se derivan directamente de los requerimientos de la empresa son: a) Uso de la metodología RUP Confidencial ITZOFT, 2009 Página 6 de 16

7 b) Uso de tecnología Microsoft c) Uso de la herramienta Enterprise Architect Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del proyecto, particularmente una vez establecido el artefacto Visión. 2.3 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. 1) Plan de Desarrollo del Software Es el presente documento. Disciplina modelado del negocio 2) Modelo de Casos de Uso del Negocio Este modelo permite visualizar el alcance de la organización, representando lo que abarca y cuáles son sus límites. Así mismo, modela las actividades y procesos que ejecuta una organización, señala gráficamente las funciones y metas que persigue el negocio, y también permite identificar cuáles son los roles y entregables de la organización. Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.), permite situar al sistema en el contexto organizacional haciendo énfasis en los objetivos en este ámbito. Este modelo se representaremos con un diagrama de clases conceptuales. Disciplina ingeniería de requerimientos 3) 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. 4) Documento de especificación de requerimientos El objetivo de este artefacto es documentar todos los requerimientos del sistema, describir las funciones del sistema, los requerimientos no funcionales, las características del diseño y otros elementos necesarios para proporcionar una descripción completa y comprensiva de los Confidencial ITZOFT, 2009 Página 7 de 16

8 requerimientos para el software a desarrollar. Disciplina análisis y diseño 5) Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Este modelo se basa en la descripción de elementos o usuarios externos al sistema (actores) y de la funcionalidad del sistema (casos de uso). Un modelo de casos de uso describe los requerimientos funcionales de un actor (usuarios, sistema, dispositivo, etc.) en términos que éste interactúa con el sistema. El modelo de caso de uso es una técnica efectiva y la ves simple para modelar los requerimientos del sistema desde la perspectiva del usuario. Este modelo lo representaremos con el modelo de casos de uso. 6) Especificaciones de Casos de Uso Para efectos del presente proyecto, solamente se describirá el flujo de eventos principal para cada caso de uso. Se realizará una descripción breve y sencilla utilizando una plantilla de documento. 7) Modelo de diseño Es una abstracción del Modelo de Implementación y su código fuente, el cual fundamentalmente se emplea para representar y documentar su diseño. Es usado como entrada esencial en las actividades relacionadas a implementación. Representa a los casos de uso en el dominio de la solución. El modelo de diseño lo representaremos con los diagramas de clases, diagramas de secuencia y el modelo de datos. 8) Modelo de datos Describe la representación física y lógica de los datos constantes utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos constantes. Usualmente describirá los diferentes elementos componentes de la estructura de una base de datos relacional. Disciplina implementación 9) Modelo de implementación El Modelo de Implementación es comprendido por un conjunto de componentes y subsistemas que constituyen la composición física de la implementación del sistema. Entre los componentes podemos encontrar datos, archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe la relación que existe desde los paquetes y clases del modelo de diseño a subsistemas y componentes físicos. Para representar los diagramas del Modelo de Implementación emplearemos el diagrama de UML de Componentes. Disciplina pruebas 10) Plan de prueba Es la colección formada por los casos de prueba y procedimientos de prueba. Este artefacto incluye el propósito de las pruebas, qué elemento se va a probar, las herramientas a utilizar y con Confidencial ITZOFT, 2009 Página 8 de 16

9 qué recursos, así como el documento que va hacer entregado. Al tener el resultado de las pruebas se puede comparar lo obtenido con lo esperado. 11) Casos de prueba Este artefacto define un conjunto de datos de entradas, condiciones de ejecución y resultados esperados de las pruebas, identificados para hacer una evaluación de los aspectos específicos de un elemento objeto de prueba. Cada Caso de de Prueba está asociado a un escenario de un Caso de Uso en particular. Disciplina implantación 12) Sistema Este artefacto es el producto final, es decir, el sistema ya funcionando que puede ser instalado y ser utilizado por el cliente. Un Sistema se diferencia de una unidad de implantación, ya que el sistema puede contener varias unidades de implantación. Cabe destacar que dichas unidades de implantación que reúne el sistema pueden ser exportadas a una unidad de almacenamiento. 13) Plan de implantación El objetivo principal de este artefacto es asegurar que el sistema llegue satisfactoriamente al conjunto de usuarios para el cual fue destinado. Este artefacto debe definir un conjunto de tareas que defina una transición sencilla para el cliente, para ello se debe minimizar el impacto que la implantación del sistema pueda llegar a causar en el personal del cliente, los sistemas de producción existentes y en todas las rutinas del negocio. 14) Documentación para el usuario Este artefacto provee una ayuda a las personas que manipularán directamente el producto, acerca del uso que le debe dar al sistema y su instalación. Dicho artefacto debe ser discutido y aprobado por el cliente. 3. Organización del Proyecto 3.1 Participantes en el Proyecto Nombre Descripción Responsabilidades Sergio Valero Orea Líder del proyecto Establecer las condiciones de trabajo Dirigir y asignar recursos Coordinar las interacciones con los clientes y usuarios finales Planificar las iteraciones Definir la organización del proyecto Confidencial ITZOFT, 2009 Página 9 de 16

10 Marcela García Alonso José Raymundo Ceja Vázquez Analista de sistemas Diseñador de sistemas Se encarga de dirigir el proceso de captura de requerimientos, definir los actores y casos de uso y estructurar el modelo de casos de uso, estableciendo la forma en que funcionará el sistema y cuáles son las restricciones del mismo. Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; debe construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista técnico del proyecto; definirá los lineamientos generales del diseño y la implementación. Alejandro Salvador Vargas Desarrollador Responsable de la codificación de de los componentes en código fuente en algún lenguaje de programación durante cada iteración Gonzalo Rosas Cabrera Responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante los cambios y mantenerlas bajo el control de la configuración de las mismas mediante la herramienta utilizada 4. Gestión del Proceso 4.1 Estimaciones del Proyecto La estimación de esfuerzo para el proyecto, se basó en la técnica de estimación de casos de uso. Para llegar a la estimación fue necesario generar nuestro modelo de casos de uso. Para realizar la estimación determinamos el número de actores y casos de uso identificados en el sistema ERP para la constructora de vivienda asociados. De esta forma, identificamos nuestros puntos de caso de uso no ajustados, y después se determinaron los puntos de casos de uso basados en factores técnicos y ambientales. La estimación final se muestra en la siguiente tabla. - Líder de proyecto $ xxx.xx mensuales $ xxx.xx - Analista de sistemas $ yyy.yy mensuales $ yyy.yy - Diseñador de sistemas $ zzz.zz mensuales $ zzz.zz - Desarrollador (2) $ vvv.vv mensuales c/u $ vvv.vv - Otros gastos (contratación de personal, $ www semanales (aprox.) $ Confidencial ITZOFT, 2009 Página 10 de 16

11 papelería, cursos, etc.) Costo Total Tiempo total para el desarrollo del proyecto $ xxx.xx 30 semanas (7 meses y medio) 4.2 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. La siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada fase (para las fases de Elaboración, Construcción y Transición solo fueron tomadas como referencias). Fase No. Iteraciones Duración Fase de Inicio 1 3 semanas Fase de Elaboración 1 9 semanas Fase de Construcción 2 14 semanas Fase de Transición 2 4 semanas Los hitos que marcan el final de cada fase se describen en la siguiente tabla. Descripción Fase de Inicio Fase de Elaboración Fase de Construcción Hito En esta fase desarrollará 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. 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 release 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. Durante la fase de construcción se terminan de analizar y diseñar Confidencial ITZOFT, 2009 Página 11 de 16

12 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 release 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 release 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. 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 A continuación se presenta un calendario de las principales tareas y actividades programadas del proyecto. 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 en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque, en ella lo ensombrecido marca el énfasis de cada disciplina (workflow) en un momento determinado del desarrollo. Confidencial ITZOFT, 2009 Página 12 de 16

13 Para este proyecto se ha establecido el siguiente calendario. 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/Actividades Artefacto Inicio Fin Modelado del Negocio - Describir el negocio actual - Desarrollar el modelo del dominio Requerimientos - Realizar entrevistas - Analizar el problema - Clasificar y priorizar requerimientos Análisis y Diseño - Especificación de casos de uso - Realización de casos de uso - Realización de los diagramas de clases - Realización de los diagramas de secuencia - Realización del modelo de datos - Realizar prototipos Implementación - Estructurar el modelo de implementación - Planificar la integración - Implementar componentes Pruebas - Definir misión de pruebas - Validar estabilidad de componentes Implantación - Planificar la implantación - Desarrollar el material de apoyo - Modelo de casos de uso de negocio - Documento de visión - Especificación de requerimientos de software - Modelo de casos de uso - Especificaciones de casos de uso - Modelo de diseño - Modelo de datos - Modelo de implementación - Plan de pruebas - Casos de pruebas - Sistema - Plan de implantación - Documentación para el usuario 8-Jun Jun Jun Jul Sep Jun Jul Dic Ene Nov Ene Matriz de roles y responsabilidades Esta matriz es una propuesta de las responsabilidades solamente con respecto a los artefactos considerados para este ejercicio. Confidencial ITZOFT, 2009 Página 13 de 16

14 Artefactos Líder de proyecto Modelo de casos de uso de negocio A R Doc. Visión A R Doc. Especificación de requerimientos A R A Modelo de casos de uso A P R Especificación de casos de uso A R A Modelo de diseño A P R Modelo de datos A P R Modelo de Roles Analista Diseñador Desarrollador Tester A A A R implementación Plan de prueba A R Casos de prueba A R sistema A R Plan de implantación Documentación para el usuario A A Clave: R= Responsable; A = Aprobación necesaria; P = Participación necesaria; R R 4.3 Seguimiento y Control del Proyecto Gestión de Requisitos Los requisitos del sistema son especificados en el artefacto Visión. 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. Control de Plazos El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto y por el Coordinador de Calidad. Control de Calidad 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á un plan de aseguramiento de calidad. Este es un documento generado por separado.. Gestión de Riesgos Confidencial ITZOFT, 2009 Página 14 de 16

15 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. 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. 5. Infraestructura necesaria De acuerdo con los requerimientos solicitados por cliente, tomando en cuenta que el ERP debe ser desarrollado utilizando tecnología de la empresa Microsoft, y para el correcto funcionamiento del sistema ERP para constructores de vivienda asociados, se recomienda adquirir los siguientes equipos y licencias con las características mínimas mostradas: Cant. Equipo/Licencia Características 1 Equipo de cómputo servidor Procesador Intel Xeon E5502, 1.86Ghz, 4M Cache, 4.86 GT/s QPI, Memoria RAM de 2GB Memory (2x1GB), 1066MHz Single Ranked UDIMMs for 1 Processor, Adv ECC, Disco Duro 160GB 7.2K RPM SATA 3.5" Hot Plug Hard Drive, DVD-ROM, SATA, Internal, tarjeta de red Embedded Broadcom NetXtreme II 5709 Gigabit Ethernet NIC Monitor, teclado y ratón compatibles. 1 No break. Capacidad: 420 VA Tecnología: interactiva Regulación: SI Tiempo de respaldo: 13 min. Voltaje de entrada: 120 VOLTS Voltaje de salida: 120 VOLTS Conexión de entrada: NEMA 5-15 P Conexión de salida: (4) NEMA 5-15 R Rango de entrada: VOLTS 1 Windows small business server 2008 Sistema operativo para soportar las aplicaciones 1 SQL server 2008 Gestor de base de datos 1 McAfee Total Protection Service Antivirus Confidencial ITZOFT, 2009 Página 15 de 16

16 Cabe señalar también, que la naturaleza y ejecución del sistema será en un ambiente web que deberá tener presencia pública sobre Internet. De esta forma, se sugieren una de dos cosas: 1. Adquirir los derechos de algún dominio (ejemplo ante NIC México y contratar un plan con un ISP para adquirir una conexión a Internet y una IP pública para gestionar el DNS y tener presencia mundial teniendo los derechos del dominio y el control total de la aplicación. 2. Contratar un plan de hospedaje de alguna empresa que brinde esos servicios con las características recomendadas de hardware y software, pagando una renta mensual a la empresa contratada y ahorrando los costos por la adquisición del equipo. 6. ANEXO 1 Plan de gestión de riesgos 7. ANEXO 2 Plan de gestión de la configuración 8. ANEXO 3 Plan de aseguramiento de la calidad 9. ANEXO 4 Modelo del dominio 10. ANEXO 5 Modelo de casos de uso Confidencial ITZOFT, 2009 Página 16 de 16