Características del software a medida:
Características del software a medida:
* Tiene su tiempo de desarrollo.
* Se adapta a las necesidades específicas de la empresa.
* Es probable que pueda contener errores y se deba mejorar.
* En general, es más caro que el software estándar.
Ventajas de un sistema a medida
1- La reducción de los gastos
Aunque el costo inicial de adquisición de programas de software a medida, especialmente para las grandes empresas, puede ser más elevado, lo cierto es que después de que el software está en funcionamiento, el costo, de mantener las operaciones comerciales se reduce significativamente y
durante un largo período, lo cual conduce a ahorros que finalmente se traducen en beneficios. La mayoría de los programas de software personalizados tienen la capacidad de resolver eficientemente y simplificar problemas puntuales y la sistematización ayuda a reducir el gasto en las empresas. Al final, las soluciones de software están consideradas como métodos efectivos con los que las empresas pueden reducir al mínimo los gastos y aumentar los beneficios.
2- Ahorro de tiempo
Estos programas, en cuestión de segundos o minutos, realizan procesos que podrían haber durado semanas o meses manualmente. En el sector empresarial, las habilidades en la gestión del tiempo son esenciales.
Al resolver los problemas de una manera más rápida y eficiente, el negocio puede llegar a aumentar su producción y optimizar los ingresos.
3- Garantía de calidad
Dado que estos programas rara vez cometen errores se consideran fiables y consistentes a la hora de producir resultados.
4- Facilidad de mantenimiento
Los programas de software a medida que se desarrollen cumpliendo los estándares de programación, pueden ser muy fáciles de mantener y actualizar. Un código bien escrito y documentado debe ser fácil de modificar.
¿Cuál es la diferencia entre el software estándar y a medida?
El software a medida (el que desarrollamos en Neosystems) es aquel que se diseña a medida del usuario, de la empresa y de su forma de trabajar. Es decir, busca complacer todas las necesidades y adaptarse lo mejor posible a lo que una empresa necesita. El software estándar o "enlatado",
es un software genérico, que resuelve múltiples necesidades, y la empresa probablemente sólo empleará algunas. En general, es un software que no se adapta completamente al vocabulario, necesidades y funciones que necesita la empresa.
1.1 Propósito
1.2 Alcance
1.3 Resumen
2. Vista General del Proyecto
2.1 Propósito, Alcance y Objetivos
2.2 Suposiciones y Restricciones
1.1 Entregables del proyecto
1. Organización del Proyecto
1.1 Participantes en el Proyecto
2. Gestión del Proceso
2.1 Estimaciones del Proyecto
2.2.1 Plan de las Fases
2.2.2 Calendario del Proyecto
1.1.1 Matriz de roles y responsabilidades
2. Infraestructura necesaria
Plan de Desarrollo de Software
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.
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”
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
a) Uso de tecnología Microsoft
b) 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”.
1.1 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 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 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.
1. Organización del Proyecto
1.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
|
Marcela García Alonso
|
Analista 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.
|
José Raymundo Ceja Vázquez
|
Diseñador de sistemas
|
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
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
|
Gonzalo Rosas Cabrera
|
2. Gestión del Proceso
2.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, papelería, cursos, etc.)
|
$ www semanales (aprox.)
|
$ www.ww
|
Costo Total
|
$ xxx.xx
| |
Tiempo total para el desarrollo del proyecto
|
30 semanas (7 meses y medio)
| |
En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.
2.2.1 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
|
Hito
|
Fase de Inicio
|
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.
|
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 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.
|
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 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.
|
2.2.2 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.
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.
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.
|
1.1.1 Matriz de roles y responsabilidades
Esta matriz es una propuesta de las responsabilidades solamente con respecto a los artefactos considerados para este ejercicio.
Artefactos
|
Roles
| ||||
Líder de proyecto
|
Analista
|
Diseñador
|
Desarrollador
|
Tester
| |
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 implementación
|
A
|
A
|
A
|
R
| |
Plan de prueba
|
A
|
R
| |||
Casos de prueba
|
A
|
R
| |||
sistema
|
A
|
R
| |||
Plan de implantación
|
A
|
R
| |||
Documentación para el usuario
|
A
|
R
| |||
Clave: R= Responsable; A = Aprobación necesaria; P = Participación necesaria;
1.2 Seguimiento y Control del Proyecto
Control de Plazos
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.
2. 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: 82 - 144 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
|
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 www.miempresa.com) 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. 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.
Comments
Post a Comment