Examen Transversal 2010

re

Programa de Capacitación

Administración de Recursos Informáticos

Alumnos : NataliaFranciscoFelipeAngelRicardoMiguel

Profesor : chavez

Santiago

2010

DuocUCInstituto ProfesionalEscuela de Informática y Telecomunicaciones Sede Antonio Varas.

Adm de Recursos InformáticosEscuela de Ingeniería

Sede Antonio Varas

INDICE

1. INTRODUCCIÓN

El presente documento de proyecto esta ideado con el objetivo de ser

presentado en respuesta a la publicación realizada por la Municipalidad

de Santiago, relativa a la realización de cursos de capacitación en

software de productividad, este documento fue realizado por la empresa

SICOMIN en base a dicha publicación y los requerimientos en ella

contemplados.

Se describirán ciertos puntos que permitirán tomar una decisión para la

realización de este proyecto de la mejor manera posible. Se

establecerán los objetivos, metodología de desarrollo, la estructura de la

organización, el plan de recursos, el plan de presupuesto, el plan de

riesgos, planificación general del proyecto, métodos de control de

avance y duración del mismo.

2


Sede Antonio Varas

2. DESCRIPCIÓN DE LA SITUACIÓN PROPUESTA

La Municipalidad de Santiago, en su proceso de ayuda y de formación a la

comunidad, ha dispuesto de cursos sobre: Windows, Word, Excel,

PowerPoint, Internet y correo electrónico. Estos cursos se enmarcan en la

política municipal de apoyar la inserción laboral de los habitantes de la

comunidad, por lo que tendrán un bajo costo y serán gratuitos para aquellos

habitantes que se encuentren sin fuente laboral.

Para el proceso anterior la Municipalidad solicita el desarrollo personalizado

de un software de gestión de las actividades de capacitación que realizará

(cursos, calendarización, inscripciones, relatores, etc) con el propósito de

disponer de información oportuna y actualizada de la gestión de

capacitación.

3


Sede Antonio Varas

3. DESCRIPCIÓN DE OBJETIVOS Y ÁMBITOS DEL

PROYECTO

SICOMIN con respecto al software de gestión y en base a la necesidad

propuesta por la Municipalidad de Santiago, desarrollará una Suite de

Gestión de capacitación enfocada a cubrir esta necesidad. La solución se

basa en un software compuesto por tres módulos principales: Módulo 1

Inscripciones y Matrículas, Módulo 2 Cursos y Calendarios, Módulo 3

Profesores y Alumnos, los que serán especificados más adelante. Con

respecto a la habilitación de la sala de capacitación, se evaluará el mejor

material y mano de obra disponible, de acuerdo a los requerimientos y

especificaciones entregadas por la municipalidad, que permitan dictar los

cursos en un ambiente óptimo y que permita a los alumnos disponer del

mejor material posible, lo que será considerado nuestro objetivo general.

El proyecto estará divido en 5 conjuntos de procesos (según la metodología

de PMBOK) en la que se establecerán los siguientes objetivos específicos

para cada uno de ellos:

• Definir el proyecto a desarrollar (inicio)

• Planificar el desarrollo de software e implementación de la sala de

capacitación (planificación)

• Ejecutar el desarrollo de software y habilitación de la sala de

capacitación (ejecución)

• Controlar el progreso y calidad del software y sala de capacitación

(control)

• Cerrar el proyecto (cierre)

4


Sede Antonio Varas

4. DESCRIPCIÓN DE LA METODOLOGÍA DE

DESARROLLO DE SOFTWARE

4.1 Introducción:

Este plan de desarrollo de software es una versión preparada por SICOMIN

que se enmarca dentro del proyecto de cursos de capacitación de formación

en materia computacional. La información que se detalla fue extraída de la

licitación del proyecto a través del portal ChileCompras.

4.2Propuesta:

En base a la necesidad que existe por parte de la Municipalidad de

Santiago, se desarrollará una Suite de Gestión de capacitación enfocada a

cubrir esta necesidad. La solución se basa en un software compuesto por

tres módulos principales:

Módulo 1 Inscripciones y Matrículas:

• Procedimiento de ingreso alumno nuevo al sistema

• Evaluación y clasificación de alumnos inscritos

• Asignar valores (en caso corresponda) para matrículas y cuotas.

• Asignar y reserva de cupo en curso seleccionado.

• Controlar cantidad de alumnos por cursos y cupos de los mismos.

Módulo 2 Cursos y Calendarios:

• Gestión de nuevos cursos.

• Reserva de cupos en cursos, a través de la inscripción.

• Gestión de consulta de cursos.

• Gestión calendarización de cursos.

5


Sede Antonio Varas

• Gestión (mantenedor) de actividades, materias, calificaciones,

asistencia por curso.

Módulo 3 Profesores y Alumnos.

• Gestión (mantenedor) de información de alumnos.

• Gestión (mantenedor) de información de profesores.

Todos estos interrelacionados entre sí, compartiendo la misma información

y almacenados en una sola Base de Datos, permitiéndole al usuario poder

tener control absoluto sobre cada proceso de admisión, generar informes,

enviar alertas por Mail y tener historiales de información sobre cada

módulo. Esta suite será desarrollada sobre software OpenSource lo que

implica que los costos de instalación y mantención serán accesibles para el

cliente.

4.3Beneficios:

Centralización de toda la información y acceso rápido a ella. Al usar

herramientas de OpenSource los costos de desarrollo y producción se

reducen drásticamente. Permitirá la jerarquización de usuarios, generando

diferentes tipos de perfiles de acuerdo a la necesidad que se requiera. Por

Ej. Un usuario que tenga privilegios solo para generar cursos, mientras que

otros tendrán acceso a matricular alumnos etc. Esto permitirá la delegación

de tareas.

4.4Metodología de desarrollo:

Para el desarrollo de la aplicación se utilizará la metodología RUP (Rational

Unified Process) cuyos principales objetivos son asegurar la producción del

6


Sede Antonio Varas

software de calidad dentro de plazos y presupuestos predecibles, además

se dirige a través de casos de usos, centrado en la arquitectura, iterativo

(mini proyectos) e incremental (versiones). Entre las ventajas que posee

esta metodología se podrían mencionar las siguientes:

• Aumenta la productividad de los desarrolladores.

• Se centra en la producción y mantenimiento de modelos de

sistemas.

• Sirve de guía para utilizar UML en forma más efectiva.

• Posee herramientas de apoyo a todo el proceso.

• Implementa mejoras prácticas en la ingeniería de software.

Fig: Esfuerzo en actividades según fase del proyecto, según RUP.

4.5 Etapas del desarrollo:

7


Sede Antonio Varas

Para el desarrollo del proyecto (y como define la metodología RUP) se

centrará en 4 etapas o fases principales: Inicio – Elaboración – Construcción

– Transición, cada una de estas etapas finaliza con un hito bien definido, las

cuales pueden tener una o más iteraciones.

A continuación se detalla un breve resumen de cada etapa y los hitos de

cada una de ellas.

Fase Inicio:

En esta fase desarrollará los requisitos del producto desde la perspectiva

del usuario, los cuales serán establecidos en el entregable 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 o entregable 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 entrega 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. La revisión y entrega de todos los

artefactos hasta este punto de desarrollo también se incluye como hito. La

8


Sede Antonio Varas

primera iteración (en caso corresponda) 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.

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 las iteraciones, cada una produciendo una entrega 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 un entregable (beta), 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 entregas 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.

4.6 Entregables del desarrollo:

9


Sede Antonio Varas

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 se proponen para este proyecto.

Es preciso destacar que de acuerdo a la filosofía 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 se

podría 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.

Plan de Desarrollo del Software: Es el presente documento.

Modelo de Casos de Uso del Negocio: 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 representa con un Diagrama de Casos de Uso

usando estereotipos específicos para este modelo.

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 10


Sede Antonio Varas

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. 11


Sede Antonio Varas

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 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 y 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 (donde se utiliza un perfil UML para

Modelado de Datos, para conseguir la representación de tablas, claves,

etc.).

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

12


Sede Antonio Varas

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 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.

Solicitud de Cambio: Los cambios propuestos para los artefactos se

formalizan mediante este documento. Mediante este documento 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 baseline (el estado del conjunto de los artefactos en un

momento determinado del proyecto) establecida. En este caso al final de

cada iteración se establecerá una baseline.

Plan de Iteración: Es un conjunto de actividades y tareas ordenadas

temporalmente, con recursos asignados, dependencias entre ellas. Se

realiza para cada iteración, y para todas las fases.

13


Sede Antonio Varas

Evaluación de Iteración: Este documento incluye le 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: 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 release al final de

cada iteración.

14


Sede Antonio Varas

5. DESCRIPCIÓN DE LA ESTRUCTURA

ORGANIZACIONAL DEL EQUIPO DEL PROYECTO

5.1 Organigrama:

El siguiente diagrama ilustra la forma en que está estructurado el grupo de

trabajo para el proyecto, además corresponde al equipo de trabajo

SICOMIN.

Jefe de Proyecto

Consultor Contraparte Cliente

Jefe de Desarrollo Arquitecto

Programador ProgramadorAnalista QA Interno

5.2 Descripción de cargos:

Jefe de Proyecto: Su función principal es la planificación y coordinación de

las actividades del proyecto. Entre éstas, se encarga de la gestión

financiera y la comunicación con el cliente.

Consultor: Su función principal corresponde a apoyar a la comprensión de

los temas de administración y gestión de los cursos, además de los temas

15


Sede Antonio Varas

relativos a la municipalidad. Se comunica directamente con el jefe de

proyecto y puede comunicarse con el Jefe de Desarrollo si este lo requiere.

Contraparte Cliente: Su función principal es verificar el avance desde el

punto de vista del cliente (municipalidad), además de definir los

requerimientos y su prioridad. Se comunica directamente con el Gerente de

proyecto.

Jefe de desarrollo: Su función principal es coordinar el desarrollo del

software, fijar las metas, coordinar el avance, solucionar cualquier problema

en que puede impedir el avance del desarrollo y establecer que los recursos

necesarios para el desarrollo estén disponible para sus subalternos. Se

comunica directamente con el gerente de proyectos, al cual debe entregar

los estados de avance y reportar los posibles problemas ó riesgos que se

puedan presentar en el desarrollo.

Arquitecto: Su función principal es la definición de la plataforma adecuada

para el desarrollo del proyecto, esto desde el punto de vista de los

requerimientos de hardware y software para el montaje. Además se

encarga del modelamiento de las estructuras de clases del software,

aplicando patrones de diseño, el modelamiento del modelo en la base de

datos relacional y la instalación y optimización de la aplicación en los

servidores del cliente. Se comunica directamente con el Jefe de Desarrollo.

Analista: Su función principal es la generación de documentación

necesaria para el desarrollo del software como la generación de diagramas

de casos de uso, diagramas de actividades y modelamiento de procesos de

negocio. Se comunica directamente con el Jefe de desarrollo al cual debe

entregar los modelos.

16


Sede Antonio Varas

Programador: Encargados de la codificación de la aplicación en un

lenguaje determinado. Se comunica directamente con el jefe de desarrollo

al cual debe entregar los programas ó scripts finalizados.

QA Interno: Encargado de realizar las pruebas en forma interna de la

aplicación, además de verificar el cumplimiento de los requerimientos.

Puede interactuar con los programadores, Diseñador y el Analista.

Descripción del plan de Recursos

En la siguiente tabla se enumeran y detallan los recursos que se utilizaran para el desarrollo del proyecto:

Información del Proyecto

Necesidades de Recursos Humanos Software

Necesidad Recurso Cantidad

Administración del proyecto

Jefe de Proyecto 372 HH

Requerimientos Analista de Sistemas

6 HH

Diseño General Analista de Sistemas

13 HH

Diseño detallado de Interfaz Usuario

Analista de Sistemas

12HH

17

Proyecto :Desarrollo SW Gestión

actividades de

capacitaciónVentana de

Tiempo Proyecto:

10-12-2010 a 07-03-2010


Sede Antonio Varas

Diseño detallado de la Base de Datos


12 HH

Desarrollo Programadores Computacionales

240 HH

Documentación Técnica


24 HH

Planeación de QA Analista QA 10 HH

Pruebas QA Analista QA 40 HH

Control de Cambios y Liberación


10 HH

Necesidades Infraestructura Software


Estaciones de trabajo de desarrollo

PC 2.9 MHz, 2 gb RAM

4

Servidor DB Desarrollo

1

Estaciones de Trabajo para pruebas

2

Servidor de Pruebas 1

Software herramienta de desarrollo

Open Source

Software para Generación documentación

Open source

Proveedor de Luz Eléctrica

Chilectra

Proveedor de Internet

VTR

Proveedor de Teléfono

VTR

18


Sede Antonio Varas

Proveedor de Agua Potable

Aguas Andinas

19


Sede Antonio Varas

Información del Proyecto

Necesidades de Recursos Humanos Capacitaciones


Administración del Personal Director de Capacitaciones

1

Capacitación SW Profesor SW productividad

4

Administración cursos Secretaria 2

Necesidades Infraestructura Capacitaciones


Estación de trabajo para Profesos

PC 2.9 MHz, 2 gb RAM

4

Estaciones de trabajo alumnos

Licencias software de productividad

20

Proyecto :Capacitaciones software de

productividadVentana de

Tiempo Proyecto:

10-12-2010 a 07-03-2010


Sede Antonio Varas

21


Sede Antonio Varas

Descripción del plan Presupuestario

22


Sede Antonio Varas

Descripción plan de Riesgo

El siguiente plan detallara como se estructurara y realizara la gestión de riesgo:

• Planificación de la gestión de riesgos.• Identificación de riesgos.• Análisis cualitativo de riesgos.• Análisis cuantitativo de riesgos.• Planificación de la respuesta a los riesgos.• Seguimiento y control de riesgos.

Definición para cada punto anterior.

Planificación de la gestión de riesgos

Los integrantes del equipo de proyecto deberán centrar sus esfuerzos en planificar la cantidad de riesgo existente. Cuando se planifica el proyecto el tiempo deberá estar alineado específicamente con el plan de la gerencia del riesgo, el cuál indicará al equipo como abordar el riesgo. Por ejemplo, se debería especificar el tipo de factores potenciales de riesgo que se enfrentarán en las reuniones semanales.

En organizaciones que han desarrollado consecuencia de los procesos de manipulación del riesgo, el plan se enfocará en la adopción de estos procesos dentro de un contexto específico del proyecto dado.

Identificación de riesgos

Es un proceso para descubrir los eventos potenciales de riesgo, para evitar incidentes inesperados, el cuál debería realizarse sistemáticamente. Se deben enfocar tanto los riesgos internos como externos, los predecibles versus los no predecibles, sobre los que tenemos una medida de control versus los incontrolables, y aquellos técnicos versus los no técnicos.

A medida que el equipo gana experiencia identificando riesgos, se deberían documentar los hallazgos, como mínimo deberán hacer “checklists" (listas de revisión) de los factores de riesgos que se observaran en los proyectos típicos. Si fuera posible, los diferentes factores de riesgos se deben sopesar de acuerdo a su importancia.

Análisis cualitativo de riesgos

Los modelos de escenarios de riesgo desde el punto de vista cualitativo pueden llevarnos a predecir los eventos que pueden ocurrir en nuestros proyectos, así como su impacto en el coste o en el inventario o en los recursos que se necesitan asociar a la incidencia de un evento de riesgo particular.

23


Sede Antonio Varas

Análisis cuantitativo de riesgos

Ciertamente, un análisis cualitativo de riesgo bien hecho proveerá al analista de riesgo un buen sentido de lo que encontrará en sus proyectos, ellos tendrán una mejor percepción si pueden conducir un análisis cuantitativo de riesgo por el modelo de escenarios de riesgo, haciendo una serie de análisis, que lo ayudaran a predecir cosas como el impacto en el coste y la programación de los recursos que necesitan si ocurre un evento particular de riesgo.

Planificación de la respuesta a los riesgos

La identificación y el análisis de los riesgos nos proporciona un conocimiento de cómo ocurren en el proyecto, el planificador del riesgo nos construye acciones que se deben tomar para evitarlos o para frenar sus impactos. Estas estrategias incluyen: transferencia de riesgo (también llamado riesgo desviado), disminuir el riesgo, evitarlo y la aceptación del riesgo.

Con la transferencia: planeamos transferir las consecuencias de la situación de riesgo a otro lugar, comúnmente hacemos esto cuando tomamos un seguro. Otro estándar de riesgo transfiere técnicas que incluyen garantías y contratos.

La disminución del riesgo: se enfoca en reducir el riesgo ajustando problemas que puedan elevar los niveles de riesgo.

La evasión del riesgo se reconoce como la forma de navegar por lo que hay que evitar hacer cosas que nos puedan molestar.

Seguimiento y control de riesgos

Tratar de anticiparnos antes de que ocurran eventos incómodos de riesgo. Esta es la naturaleza fundamental de asumir el riesgo, un gran ejercicio intelectual. Hay que tener claro ¡El riesgo siempre existe, pero puede ser controlado o asumido!. Con la monitorización y control, tomamos conductas para delinear el riesgo y así intentar resolver los problemas que se presenten.

24

Documents

Examen Transversal 2010