Captulo IV.

Fase de iniciacin

El propsito de la fase de iniciacin es determinar si vale la pena desarrollar el sistema de informacin deseado y en caso afirmativo, poner en marcha el proyecto. En otras palabras, su objetivo principal es determinar si el sistema es viable. En la primera parte de este captulo nos enfocaremos en el flujo de trabajo referente a la administracin del proyecto. Se identificar la necesidad de la solucin retomando la definicin del problema presentada en el primer captulo de este trabajo, poniendo especial nfasis en los sntomas que muestran la necesidad hasta el punto necesario para justificar la puesta en marcha del proyecto y poder proponer soluciones alternativas al problema. Se evaluarn las dos principales alternativas de solucin encontradas mediante el anlisis de tres variables: arquitectura, caractersticas e integracin, adems de comparar las ventajas contra las desventajas que ofrecen para finalizar seleccionado la propuesta ms viable. Despus describir la propuesta de solucin, se traducir la idea a trminos de factibilidad del proyecto, considerando las exigencias de recursos del proyecto, los costos de la inversin, las estimaciones de beneficios y la aceptacin de la institucin. Para realizar esto se desarrollar un estudio de factibilidad donde se abarquen cinco aspectos: econmico, tcnico, operativo, tico y legal. Para terminar esta primera parte abordaremos la fase de configuracin y cambios estableciendo las especificaciones en la cual deben realizarse. En la segunda parte del captulo, no enfocaremos en los flujos de trabajo de requerimientos y anlisis comenzando con el desarrollo del modelo de negocio.

93

Una vez que se tenga este artefacto, se delimitar el alcance el mbito del sistema propuesto comprendiendo el contexto del sistema mediante el modelo de dominio y recopilando los requisitos funcionales y no funcionales. Por ltimo basado en la informacin obtenida, se encontraran los actores y casos de uso del sistema y se realizar el artefacto principal de esta fase el modelo de casos de uso inicial.

Figura 29. Actividades en la fase de iniciacin. Los tamaos relativos a los polgonos en cada flujo slo indican en qu fase requieren ms atencin. [JACOBSON et. al. 2000].

No realizaremos otras fases de la metodologa en esta durante la fase de inicio, ya que los objetivos de la misma, es la puesta en marcha de proyecto, identificacin del alcance del sistema,
94

planeacin general de actividades y el establecimiento de la primera versin de la arquitectura, que en esta fase ser una vista del modelo de casos de uso. Tambin es importante recalcar que aunque en la prctica se pueden llevar a cabo varias iteraciones en cada flujo de trabajo (para refinar detalles, detectar fallas u omisiones, etc.), no sern plasmadas en el trabajo para efectos de claridad. Estas actividades de la fase de inicio se muestran grficamente en la Figura 29.

4.1 El flujo de trabajo de la gestin del proyecto

Este flujo de trabajo de soporte se desarrolla de manera paralela a los otros flujos en una iteracin tpica y no se detiene hasta el final del proyecto.

4.1.1 Planeacin de la fase de iniciacin

Antes de comenzar de lleno con la administracin del proyecto, se tiene que planear las actividades a realizar aunque no se tenga mucha informacin sobre la que basar un plan. Slo se reconoce lo que tiene que ser planificado si sabe lo que es necesario hacer. En otras palabras se limitar el esfuerzo a lo que sea necesario hacer para cumplir los objetivos clave mencionados al inicio del captulo. Hay que recordar que se proyectar el desarrollo hasta el punto de establecer que el proyecto es factible y tan pronto como se pueda, se realizar el plan global del proyecto tratando de especificar los trabajadores, tiempos y constatar cuantas iteraciones sern necesarias en cada fase69. La Tabla 6 muestra el plan de la fase de iniciacin en la metodologa del Proceso Unificado.

69

Para efectos de claridad, en este trabajo no se detallar cada iteracin en el desarrollo del sistema y se presentar

slo la iteracin final.

95

Tabla 6. Plan de fase. Institucin, 2010

Sistema de Informacin Formato: Plan de fase de iniciacin Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Plan de Fase de Iniciacin

1. Introduccin
Este documento contiene la descripcin formal del plan de la fase de iniciacin del desarrollo de software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 1.1 Propsito El propsito del plan es especificar las actividades, participantes, tiempo y presupuesto en esta fase del proyecto. 1.2 Alcance Se describen las actividades de la fase de iniciacin abarcando los flujos de trabajo necesarios. 1.3 Definiciones, Acrnimos y Abreviaciones Ver el glosario del proyecto. 1.4 Referencias Definicin del proyecto Glosario

1.5 Descripcin general Esta Plan de Iniciacin contiene la siguiente informacin: Personal y Responsabilidades provee la descripcin de los involucrados en la fase y de las actividades a realizar de cada uno. Criterio de aceptacin de trmino de la fase Identifica los criterio para determinar la aceptacin de los artefactos entregables y establecer el trmino de la fase. Calendario Especifica las fechas iniciales y finales para cada una de las actividades de entrega de productos. Plan Describe el plan de la fase.

96

2. Personal y Responsabilidades
2.1 Artefactos entregables 1. Alternativa de solucin 2. Identificacin de riesgos (Estudio de factibilidad) 3. Modelo del negocio 4. Modelo del dominio 5. Glosario 6. Modelo de casos de uso 7. Versin preliminar de la arquitectura (vista del modelo de casos de uso) 8. Plan para la fase de elaboracin 2.2 Personal En esta fase inicial no se requiere contar con todo el personal del Unidad de Desarrollo pues no se tiene an una idea clara de lo que se va a desarrollar. Solo se requiere la participacin del jefe del proyecto y un analista de requisitos como lo muestra los siguientes diagramas de actividad: Slo en caso de ser factible el proyecto Actividad obligatoria

97

Jefe de proyecto

Jefe de configuracin responsable de

Jefe de soporte

Alternativa de solucin

Plan de la fase

Estudio de factibilidad

Establecer el control de cambios

Estudio de factibilidad tcnica

Hardware / Software

Modelo del negocio (o modelo de dominio)

Analista de sistemas

Modelo de casos de uso (esbozado)

Modelo de casos de uso (esbozado)

Analista de sistemas

Modelo de casos de uso (estructurado)

Requisitos

Encontrar actores y casos de uso Glosario

Requisitos adicionales

Estructura del modelo de casos de uso Modelo de anlisis (esbozado)

Caso de uso (detallado)

Lista de caractersticas Glosario

98

En esta fase el equipo de trabajo es pequeo por lo que una misma persona puede desempear varios roles.

3. Criterio de aceptacin
En esta fase de iniciacin lo ms importante es establecer la factibilidad del proyecto y entonces comenzar a recaudar la mayor informacin posible sobre los requisitos de la solucin. Ya que en esta fase de iniciacin no ser requiere hacer ms de una iteracin, el criterio de aceptacin est en relacin con la entrega de cada uno de los artefactos listados en el punto 2.1 en las fechas establecidas en el cronograma de actividades del punto 4. Cada artefacto ser revisado con la organizacin cliente para corroborar el correcto entendimiento de los requisitos y en caso necesario, hacer las correcciones pertinentes.

4. Calendario
Este es el calendario de actividades para la fase de iniciacin que consta de 10 das hbiles de trabajo.

99

5. Plan de comunicacin
Ya que este desarrollo involucra a la organizacin cliente muy de cerca, se deber tener una comunicacin estrecha y efectiva entre los principales actores del proyecto. Siempre deber existir evidencia escrita de la comunicacin y como se muestra a continuacin: Reporte de avance por fase Director Secretario Director Unidad de Tecnologa Jefe de Unidad de Desarrollo Jefe de proyecto Asistente personal del Secretario Recibe Recibe Recibe Recibe Elabora Recibe Recibe Recibe Recibe Elabora Recibe Recibe Recibe Recibe Elabora Recibe Elabora Elabora /Recibe Elabora /Recibe Elabora /Recibe Elabora /Recibe Elabora /Recibe Plan de siguiente fase Minutas de acuerdos en juntas Solicitudes de cambios por oficio Avisos y comunicados por correo electrnico

100

6. Plan
Aunque no hay mucha informacin con la cul basar concretamente el plan, si se pueden definir varias actividades y en base a sus resultados, establecer las siguientes. 1. Se deber conformar un pequeo equipo de trabajo que se encargue de identificar la necesidad a resolver en la organizacin cliente (organizacin cliente) y proponer alternativas de solucin. Una vez que se haya seleccionado la alternativa de solucin en conjuncin con la organizacin cliente, se debe definir formalmente la propuesta de solucin. Se debern evaluar los riesgos crticos mediante un estudio de factibilidad que abarque los aspectos, tcnico, operativo, econmico, tico y legal. Si el proyecto no es factible en este punto encontrndose algn riesgo critico no superable, se deber descartar el proyecto. En caso contrario se deber iniciar la comprensin inicial del dominio por medio de entrevistas, cuestionarios y otros mecanismos en conjunto con la organizacin cliente. Elaborar el glosario inicial del proyecto. Elaborar el modelo de negocios inicial encontrando los actores y casos de uso que se traducirn en el modelo de casos de uso. Detectar los requisitos funcionales y no funcionales. Revisar los productos generados junto con el personal de la organizacin cliente. En caso de ser necesario, realizar otra iteracin para ajustar los modelos.

2.

3.

4.

5.

6. 7.

8. 9.

10. Elaborar el modelo de anlisis preliminar a partir de los casos de uso. 11. Terminar la fase elaborando el plan de la fase de elaboracin donde se elaborar entre otras cosas, el plan global del proyecto con toda la informacin recabada en esta fase.

La primera tarea que siempre se debe realizar antes de emprender el desarrollo de un proyecto, es darse cuenta de que existe un problema e identificar claramente las causas del mismo. Esto forma parte de la gestin del proyecto (Figura 30) y una forma muy clara de identificar la existencia de un problema es cuando las personas dentro de la organizacin no logran los objetivos de desempeo bsicos el cul es aqu el punto de partida de esta investigacin.

101

A continuacin se presenta la identificacin de la problemtica en la Institucin y la necesidad de la agilizacin del proceso de comunicacin escrita en la institucin.

Figura 30. Flujo de trabajo de la gestin del proyecto. Los tamaos relativos a los rectngulos, slo indican qu flujos de trabajo requieren ms atencin [JACOBSON et. al. 2000]

4.1.2 Identificacin y sntomas que muestran la necesidad

El planteamiento del problema fue presentado en el primer captulo de este trabajo, de donde se destacan los siguientes sntomas: Fuerte gasto anual en la cuenta 7209 material de oficina. Retraso en la atencin de oficios turnados en papel. Falta de un indicador de desempeo en relacin las solicitudes recibidas y solicitudes atendidas. Prdida de las solicitudes por traspapelo. Obtencin de la certificacin ISO-9001:2000, la cual exige un registro de las solicitudes recibidas por la institucin en su Sistema de calidad. Falta de espacio en el almacenamiento de los archivos histricos de la institucin. Retraso en el envo de solicitudes entre las regiones del estado.

Claramente puede observarse que los sntomas que exhiben el problema estn relacionados con los medios y la falta de herramientas para realizar el flujo de comunicacin escrita en la institucin la cual se lleva a cabo de la siguiente manera: cuando una persona interna o externa a la institucin requiere un servicio de alguna dependencia, debe hacerlo formalmente por medio de un oficio respaldado por un sello y firma de la dependencia solicitante.

102

Es aqu donde inicia el primer paso en el proceso de comunicacin. Si la solicitud se realiza dentro de la misma regin geogrfica del estado, el oficio (ms una copia como acuse de recibido) es llevado en persona por el mismo emisor o en su defecto mediante un mensajero o estudiante de servicio social o fax. Si la solicitud es hacia otra regin y no se cuenta con fax, slo se enva una copia por mensajera postal con entrega al siguiente da absorbiendo los gastos el emisor o la dependencia titular70. Una vez que el documento llega a la dependencia receptora, se le coloca el sello de la institucin, la fecha de recepcin y se firma de recibido en ambas copias del oficio y una de ellas es regresada en ese momento al emisor como acuse de recibo. A partir de este momento, el destinatario tiene 7 das hbiles para emitir una contestacin. La peticin es revisada y evaluada por el destinatario para su atencin. Ya sea que le corresponda o no al destinatario atender la solicitud, se debe emitir una respuesta (negativa o positiva) redactando un nuevo oficio (con su copia de acuse de recibido) con la atencin parcial o total a la solicitud. Este ciclo se repite entre emisor y receptor hasta que la peticin haya sido atendida en su totalidad. Hay ocasiones, en los que existe ms de un destinatario debido a que la naturaleza de la solicitud demanda que varias personas y/o dependencias se involucren en la resolucin de la misma. Cabe recalcar, que no existe ningn registro oficial de este intercambio de documentos y se corre el riesgo de que con el tiempo, se olviden aspectos de la primera solicitud. Este proceso es complementado con llamadas telefnicas y correos electrnicos para aclaraciones y/o comentarios, pero todo de manera informal.

70

Estos gastos son parte de la cuenta 7209 MATERIAL DE OFICINA.

103

Como se puede apreciar, el problema del proceso de comunicacin es que se hace de manera manual con herramientas de apoyo como telfono, fax y correo electrnico las cuales no son suficientes. El retraso en la atencin de solicitudes tiene que ver con que no existe un registro de las mismas, por lo que fuera del papel intercambiado por los involucrados en la comunicacin, no hay forma de revisar el estado de la solicitud por parte de terceros. Al no haber un indicador en este rubro, lgicamente no puede existir una evaluacin del desempeo lo que produce falta de atencin en el mismo por parte del trabajador. Actualmente el nico indicador que tiene el supervisor, son llamadas de usuarios quejndose por la falta de atencin a sus solicitudes. Es por todo lo anterior, que surge la necesidad de automatizar este proceso mediante una herramienta computarizada que se encargue del envi, recepcin, almacenamiento y control de flujo de las solicitudes dejando nicamente a los usuarios la redaccin e interpretacin de las mismas. Como consecuencia de esta automatizacin, se obtendr principalmente la reduccin del gasto anual en material de oficina, agilizacin en la atencin, consulta en tiempo real del estado de las solicitudes e indicadores cuantitativos y cualitativos de desempeo por dependencia.

4.1.3 Representacin grfica de la necesidad

En la Figura 31 se muestra de forma grfica el problema de la comunicacin en la institucin donde se puede observar como las copias de documentos en papel se incrementan conforme se involucran ms personas en el flujo de trabajo, la dispersin de los mismos y el intercambio de respuestas en papel que se requieren para solicitar y atender una peticin que trae consigo el problema del traslado fsico.

104

Figura 31. Diagrama de actividad del flujo de trabajo en la comunicacin escrita en la Institucin.

105

4.1.4 Identificacin y evaluacin de soluciones alternativas

En el inicio de esta investigacin (apartado de antecedentes) se estudiaron soluciones comerciales candidatas a ser la solucin a la necesidad en el flujo de comunicacin de la institucin. Todas ellas fueron descartadas por no considerarse factibles, ya que ninguna ofreca por completo la solucin al problema. Sin embargo, retomaremos la mejor de estas soluciones como una alternativa y la compararemos con el desarrollo de un producto de software propio evaluando el cumplimiento a la funcionalidad deseada como requerimientos de negocio en aspectos de arquitectura, contenido e integracin, como se muestra en la Figura 32. Hay que hacer notar, que no se toma en cuenta el factor de costo, ya que uno de los requisitos de la solucin, es que no conlleve un gasto extra en licencias o capacitacin para la institucin.

Grado de cumplimiento

Arquitectura o o o Componentes Personalizacin Seguridad Mdulos adicionales Admn. De documentos Base de datos Active Directory .NET

Contenido o o

Integracin o o o

Figura 32. Grado de cumplimiento en la funcionalidad.

4.1.4.1 Alternativas de solucin 1. Instalacin la herramienta de colaboracin Windows SharePoint Services 3.0 de manera institucional. 2. Desarrollo de una aplicacin propia, complementndola con componentes o herramientas ya desarrolladas por terceros.

106

4.1.4.2 Ventajas y desventajas de la alternativa de solucin 1 Instalacin la herramienta de colaboracin Windows SharePoint Services 3.0 de manera institucional. En la Tabla 7 se presenta una comparacin de ventajas y desventajas de esta herramienta y en la Tabla 8 se presenta la evaluacin del cumplimiento a la funcionalidad deseada como requerimientos del negocio en los aspectos de arquitectura, contenido e integracin.
Tabla 7. Comparacin de ventajas y desventajas de la alternativa 1.

Ventajas Soporte en lnea. Actualizaciones. Sin costo. Versin liberada con menor nmero de fallas. Disponible inmediatamente.

Desventajas Acoplamiento con los sistemas existentes. Curva de aprendizaje. Sin acceso al cdigo fuente. No funciona sobre otra plataforma diferente de Windows. Dependencia en funcionalidad y mejoras de terceros. Posible incompatibilidad en futuras versiones (las versiones 1.0, 2.0 y 3.0 son incompatibles entre s).

Tabla 8. Evaluacin de funcionalidad de la alternativa 1.

Arquitectura Windows Server 2003 x32. IIS 6.0 Basado en tecnologa Microsoft Windows 2003. Desarrollado sobre .NET. Personalizacin complicada y poco funcional.

Contenido Mdulo de gestin de documentos. Control de versiones. Alertas limitadas. Sin control del flujo de comunicacin. Lista de documentos confusa. Sin buzn de entrada y salida. Sin mdulo de digitalizacin.

Integracin

Integracin slo con productos Microsoft. Componentes de terceros costosos. Poca variedad de componentes. Soporte para Active Directory. Soporte nicamente con SQL Server.

107

4.1.4.3 Ventajas y desventajas de la alternativa de solucin 2 Desarrollo de una aplicacin propia, complementndola con componentes o herramientas ya desarrolladas por terceros. En la Tabla 9 se presenta una comparacin de ventajas y desventajas de la solucin propia y en la institucin. Tabla 10 se presenta la evaluacin del cumplimiento a la funcionalidad deseada como requerimientos del negocio en los aspectos de arquitectura, contenido e integracin.
Tabla 9. Comparacin de ventajas y desventajas de la alternativa 1.

Ventajas Hecho a la medida. Soporte interno. Integracin con los sistemas existentes. Actualizacin y mejora constante. Exclusin de pliza de uso y licencias. Sin costo. Seguridad propia. Acceso al cdigo fuente.

Desventajas Tiempo de desarrollo. Problemas en la obtencin de requisitos. Posible desarrollo para mejora infinito.

Tabla 10. Evaluacin de funcionalidad de la alternativa 1.

Desarrollo a la medida
Arquitectura Cualquier versin de Windows o Linux. IIS 6.0 o Apache 2. Desarrollado sobre .NET. Personalizacin a la medida y extensible sobre la misma plataforma de desarrollo. Contenido Mdulo de gestin de documentos. Control de versiones. Envo de alertas. Basado en el control del flujo de comunicacin. Buzn de entrada y salida. Mdulo de digitalizacin. Mdulos adicionales requeridos por el cliente. Integracin

Integracin con sistemas existentes. Independiente de plataforma. Integracin de componentes de terceros. Soporte para Active Directory. Soporte inicialmente con SQL Server pero extensible a cualquier otro motor.

108

4.1.4.4 Seleccin de la alternativa de solucin Despus de haber revisado las dos alternativas de solucin ms factibles para la necesidad que se tiene en la institucin analizando sus ventajas y desventajas se lleg a la siguiente conclusin: Alternativa 1. Esta alternativa se descarta debido a que no permite acoplarse a los sistemas internos y limitaran su crecimiento adems de que su mdulo de gestin de documentos no se acopla totalmente a las necesidades de la institucin. Alternativa 2 Se lleg a la determinacin que la alternativa 2 es la que ms se acerca al cumplimiento de los objetivos de los requerimientos de la institucin. Este desarrollo propio tiene la ventaja competitiva de cubrir los requerimientos especficos de comunicacin y puede integrarse con otros sistemas existentes. Adems de que el tiempo no es un factor dominante en la decisin y se cuenta con un Unidad de Desarrollo dedicado a este tipo de soluciones acadmicas.

4.1.5 Descripcin de la propuesta

La Tabla 11 muestra la descripcin del proyecto en la metodologa del Proceso Unificado.
Tabla 11. Formato de Descripcin del Proyecto. Institucin, 2010

Sistema de Informacin Formato: Descripcin del Proyecto Unidad de Tecnologa

Versin:

1.0

Fecha: 2da semana

Descripcin del Proyecto

1. Introduccin
Este documento contiene la descripcin formal del proyecto de software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 109

1.1 Propsito El propsito de la definicin es iniciar de manera formal el proyecto describiendo la solucin propuesta en un nivel muy general. 1.2 Alcance Se describen las caractersticas del proyecto de manera general. Los detalles de cada iteracin sern descritos en los documentos de Planes de Iteracin. 1.3 Definiciones, Acrnimos y Abreviaciones Ver el glosario del proyecto. 1.4 Referencias Planes de Iteracin Glosario

1.5 Descripcin general Esta Descripcin del Proyecto contiene la siguiente informacin: Descripcin General del Proyecto provee la descripcin del proyecto, alcance, y objetivos. Tambin define los entregables finales que el proyecto espera entregar.

2. Descripcin del proyecto

2.1 Propsito del proyecto, Alcance y Objetivos Se propone a travs de la Unidad de Tecnologa, el desarrollo de un producto propio que integre las capacidades de almacenamiento, recuperacin, llenado, seguridad, creacin, categorizacin, digitalizacin, integracin, indexacin, distribucin, control de flujo de trabajo, colaboracin y seguimiento de los documentos que circulan en las dependencias de la institucin. Permitiendo alojar la aplicacin en un servidor Web en Internet para ser accedida por el personal de la institucin y mediante su cuenta institucional, obtener vistas personalizadas del repositorio central de informacin de documentos. El objetivo del proyecto es mejorar la eficiencia en la toma de decisiones de los integrantes de la organizacin mediante el almacenamiento, administracin, digitalizacin, creacin y seguimiento electrnico de la comunicacin escrita actual, y con ello proporcionar una herramienta de medicin de la productividad, una mejora en el tiempo de atencin de las solicitudes y la reduccin del presupuesto en material de oficina que abarca la adquisicin de recursos para el envo de correspondencia. El alcance del proyecto deber abarcar todas las dependencias de la Institucin para utilizarse de manera institucional. En su primera etapa, la cual ser el objeto de estudio de esta investigacin, el sistema ser 110

implantado en la organizacin cliente para su piloteo y monitoreo de resultados. No se contemplarn los documentos oficiales y/o confidenciales. Debido a la naturaleza de estos documentos, la necesidad de firmas digitales para comprobar la identidad de los involucrados es obligatoria y no ser incorporada en esta etapa de la investigacin. Sin embargo, est contemplada en las siguientes etapas del proyecto 2.2 Enunciado del Problema El problema de afecta impactando en una solucin exitosa sera el retardo en la atencin de las solicitudes escrita en papel a los integrantes de la institucin productividad y efectividad en la toma de decisiones mediante un sistema de informacin que permita el almacenamiento, administracin, digitalizacin, creacin y seguimiento electrnico de la comunicacin escrita actual

2.3 Entregables del Proyecto Sistema de Informacin Documentacin del desarrollo del sistema Manual de usuario

4.1.5.1 Barreras de entrada y salida de la propuesta Las barreras de entrada y salida en los sistemas de informacin son las que nos muestran los puntos de aceptacin o rechazo hacia la propuesta. Las principales barreras de entrada detectadas en la institucin son: Aceptacin del personal a operar con el sistema debido a lo que implica realizar una tarea ms de las asignadas. Falta de cultura informtica, por parte de los clientes, donde en muchos de los casos el desconocimiento al manejo de equipo de cmputo y al conocimiento de la importancia y beneficios que el cambio les proporcionar. Las principales barreras de salida detectadas en la institucin son: Problemas en el acceso a la red.
111

Insatisfaccin de los usuarios con el uso de la herramienta.

Para saltar estas barreras detectadas, no se necesita de un esfuerzo o cambio considerable en la forma de trabajo en la institucin, por lo que son aceptables y pueden ser controladas.

4.1.6 Administracin del riesgo

El modo en que se est planificando este proyecto est influenciado en gran medida por los riesgos que se pueden percibir. Al principio es un poco difcil por la falta de informacin, pero siempre se pueden identificar muchos riesgos que estn siempre presentes en los proyectos de sistemas. La Tabla 12 contiene la lista de riesgos del proyecto en la metodologa del Proceso Unificado.
Tabla 12. Formato de Lista de Riesgos. Institucin, 2010

Sistema de Informacin Formato: Lista de riesgos Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Lista de riesgos
1. Introduccin
Este documento contiene la descripcin formal de la lista de riesgos del software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 1.1 Propsito El propsito de la definicin es identificar de manera formal la lista de riesgos. 1.2 Alcance Se describen los riesgos clasificndolos por prioridad y especificando la forma de mitigarlos. 1.3 Definiciones, Acrnimos y Abreviaciones Ver el glosario del proyecto. 1.4 Referencias 112

Planes de Iteracin Descripcin del proyecto Glosario

1.5 Descripcin general Esta Lista de Riesgos contiene la siguiente informacin: Riesgos Internos provee la descripcin de los riesgos inherentes al desarrollo del proyecto mismo. Riesgos Externos provee la descripcin de los riesgos no inherentes al desarrollo del proyecto mismo.

2. Lista de riesgos
2.1 Riesgos internos Descripcin Definicin incompleta del proyecto Prioridad Crtico Responsabilidad Jefe de proyecto Como evitarlo Hacer las iteraciones necesarias hasta que se obtengan los requisitos del proyecto completos Identificar claramente las actividades a realizar y dejar un espacio para eventos imprevistos Obtener toda la informacin posible de parte del modelo de dominio Revisar el contexto del sistema en busca de casos de uso no identificados Establecer desde las primeras iteraciones, la arquitectura candidata Contingencia Realizar otra iteracin poniendo especial nfasis en la captura de requisitos

Mala calendarizacin de actividades

Significativo

Jefe de proyecto

Ajustar el calendario restante de manera que no se vea afectado el progreso global

Elaborar un glosario incompleto

Rutinario

Analista de sistemas

Ajustar el glosario en la siguiente iteracin de la fase

Elaborar un modelo de negocios incompleto

Significativo

Analista de sistemas

Ajustar el modelo de negocio en la siguiente iteracin de la fase

Hardware no suficiente

Crtico

Jefe de soporte

Revisar el presupuesto para adquirir el hardware necesario o ajustar el desarrollo al equipo existente

113

Requisitos incompletos

Rutinario

Analista de sistemas

Hacer las iteraciones necesarias hasta que se obtengan los requisitos del proyecto completos Hacer las iteraciones necesarias hasta que se identifiquen los casos de uso del proyecto completos Establecer desde las primeras iteraciones, la arquitectura candidata Establecer la forma de realizar cambios haciendo el proyecto flexible Hacer las iteraciones necesarias hasta que se identifiquen las clases completas Hacer las iteraciones necesarias hasta que se obtengan los requisitos del proyecto completos Revisar muy de cerca la implementacin de los modelos en la etapa de diseo de la base de datos Trabajar conjuntamente con el personal de soporte

Ajustar la lista de requisitos en la siguiente iteracin de la fase

Modelo de casos de uso incompleto

Rutinario

Analista de sistemas

Ajustar el modelo de casos de uso en la siguiente iteracin de la fase

Arquitectura incompleta

Rutinario

Arquitecto

Ajustar la descripcin de la arquitectura en la siguiente iteracin de la fase

Cambios no previstos

Rutinario

Jefe de configuracin

Ajustar la modificacin en la siguiente iteracin en el flujo del cambio de la fase Ajustar el modelo del anlisis en la siguiente iteracin de la fase

Modelo de anlisis incompleto

Rutinario

Analista de sistemas

Diseo poco atractivo con funcionalidad no deseada

Crtico

Diseador

Ajustar el diseo en cada flujo de trabajo en la siguiente iteracin de la fase

Base de datos incompleta

Significativo

DBA

Ajustar el diagrama E-R, el modelo relacional y su implementacin fsica en la siguiente iteracin de la fase

Problemas de red

Significativo

Jefe de soporte

Trabajar localmente hasta solucionar el problema de conectividad

114

Sistema Web muy pesado

Crtico

Jefe de proyecto

Revisar que la implementacin de los modelos sea adecuada para el lenguaje de programacin seleccionado Revisar que la implementacin de los modelos sea adecuada para el lenguaje de programacin seleccionado Comunicacin constante entre desarrollos de capas de la aplicacin Elaborar el manual de usuario junto con el trmino de cada fase Especificar el modelo de pruebas de acuerdo a los requisitos a cumplir Establecer relaciones contractuales bien definidas con los integrantes del proyecto y contar con personal de respaldo Realizar mediciones de avance y evaluaciones de calidad en cada iteracin

Eliminar todo el multimedia no necesario, revisar la normalizacin de los datos y el acceso de red

Problemas para implementar los modelos en ASP.NET

Significativo

Ingeniero de componentes

Buscar una solucin de terceros o adecuar los modelos en la siguiente iteracin.

Problemas en la comunicacin entre capas de la aplicacin

Significativo

Integrador del sistema

Ajustar los cambios en las capas en la siguiente iteracin

Manual de usuario no terminado a tiempo

Significativo

Jefe de proyecto

Colocar notas explicativas (tooltips) en cada botn de la aplicacin Ajustar el modelo de pruebas en la siguiente iteracin de la fase

Modelo de pruebas no convincente

Significativo

Ingeniero de pruebas

Desercin de integrantes

Significativo

Jefe de proyecto

Delegar la responsabilidad a otro integrante temporalmente

No alcance de los objetivos

Critico

Jefe de proyecto

Ajustar los modelos a los cambios pertinentes en una fase de extensin para la siguiente versin del sistema

115

2.2 Riesgos externos Descripcin Retraso del proyecto por acusas administrativas Catstrofe natural Prioridad Crtico Responsabilidad Jefe de proyecto Contingencia Ajustar el calendario desde el inicio para contemplar retrasos no planeados Probabilidad Media

Critico

Jefe de proyecto

Encontrar otro lugar para continuar con el desarrollo Contar siempre con un respaldo de los entregables

Baja

Prdida de informacin fsica por dao Falta de apoyo por parte del director

Critico

Soporte

Baja

Significativo

Jefe de proyecto

Calendarizar una junta para presentar avances

Baja

4.2 El flujo de trabajo de la configuracin

Este flujo de trabajo va muy de la mano con los otros pues flujos de soporte pues debe trabajar conjuntamente con el flujo de soporte para el establecimiento del ambiente de configuracin de las herramientas de trabajo y con la administracin del proyecto en lo que se refiere a las versiones del producto controlando y administrando los cambios.

Figura 33. Flujo de trabajo de configuracin y administracin del cambio. Los tamaos relativos a los rectngulos, slo indican qu flujos de trabajo requieren ms atencin [JACOBSON et. al. 2000]

116

4.2.1 Administracin de cambios

Toda realizacin de cambios en los productos que genere el proyecto deber ser evaluada y aceptada por el comit de control de cambios. La Tabla 13 contiene el formato para la solicitud de cambios en la metodologa del Proceso Unificado.
Tabla 13. Formato para la administracin del cambio. Institucin, 2010

Sistema de Informacin Formato: Lista de riesgos Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Solicitud y aprobacin de cambios

1. Introduccin
Este documento contiene la solicitud de un cambio en el proyecto del software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 1.1 Propsito El propsito es mantener un registro de los cambios realizados al proyecto. 1.2 Alcance Se especifica el cambio a realizar. Debe contener el Vo. Bo. del jefe del proyecto. 1.3 Definiciones, Acrnimos y Abreviaciones Ver el glosario del proyecto. 1.4 Referencias Planes de Iteracin Descripcin del proyecto Glosario

117

2. Datos generales
2.1 Nombre del solicitante Nombre: Guillermo Vera Fecha: 3era semana Puesto: Personal Firma:

2.2 Prioridad (Alta, Media, Baja) Alta 2.3 Descripcin del cambio Agregar un nuevo caso de uso llamado Incorporar Correspondencia que modele la inclusin de un nuevo documento en papel al sistema de informacin. Esto con el objetivo de incorporar oficios existentes en papel fsico al sistema de informacin y poder reenviarlos dentro del mismo. 2.4 Causa del cambio Requisito reglamentario Necesidad del negocio Omisin de requerimientos Condicin de campo Omisin/Error de diseo Otro 2.5 Impacto del cambio Tiempo: 1 da Fecha de inicio: 3ra semana Fecha de terminacin estimada: 3era semana Responsable: Guillermo Vera Aprobado: S Comentarios: Sin comentarios X

3. Autorizaciones
Nombre: Encargado Fecha: 3era semana Puesto: Jefe de departamento Firma:

Nombre: Encargado Fecha: 3era semana

Puesto: Director Firma:

118

4.3 El flujo de trabajo del entorno

En este flujo de trabajo el nfasis reside en dar soporte al resto del trabajo especficamente en tener disponibles las herramientas para la realizacin de las actividades del proyecto como lo muestra la Figura 34. As que en esta fase de iniciacin, se debe determinar si todos los recursos necesarios estarn disponibles para el desarrollo de la solucin.

Figura 34. Flujo de trabajo del entorno. Los tamaos relativos a los rectngulos, slo indican qu flujos de trabajo requieren ms atencin [JACOBSON et. al. 2000]

4.3.1 Estudio de factibilidad

En este flujo de trabajo, se debe realizar un estudio de la factibilidad sobre cuatro puntos de vista: econmico, tcnico, operacional y legal para determinar la viabilidad de la alternativa de solucin elegida y estar seguros de contar con las herramientas necesarias con el proyecto. Este estudio puede ser tan extenso o corto como se requiera, y en esta investigacin como es una solucin interna, slo ser necesario un estudio sencillo. 4.3.1.1 Econmico Este estudio se refiere a los recursos financieros necesarios para llevar a cabo las actividades requeridas por el proyecto a desarrollar. Este es el elemento ms importante a considerar ya que por medio de este, se solventa todos los dems elementos, adems de que es lo ms complicado de conseguir. Desde este punto de vista econmico el proyecto es totalmente viable, ya que la institucin por medio de la Unidad de Tecnologa, se cuenta con una unidad de desarrollo de software encargada
119

a este tipo de desarrollos. Adems ya se cuenta con la infraestructura tecnolgica en materia de hardware y software requerido y no ser necesario adquirir nuevos equipos. Los detalles tcnicos se vern ms detallados en el siguiente apartado. Esto se traduce a que el desarrollo del proyecto no tendr un costo adicional ya actualmente se cuenta con el material tcnico y humano de base. 4.3.1.2 Tcnico La factibilidad tcnica va muy de la mano con el flujo de trabajo del entorno, el cul debe proporcionar las herramientas tecnolgicas necesarias para la realizacin de los dems flujos. Adems del aspecto de hardware y software, la factibilidad tcnica debe evaluar aspectos como el conocimiento, habilidades y experiencia que se requiere para realizar las actividades del proyecto. Generalmente todos estos aspectos, deben traducirse a elementos tangibles y medibles, por lo que los conocimientos y experiencia sern traducidos a certificaciones, estudios y proyectos realizados. Desde este punto de vista tcnico, el proyecto es totalmente viable y no es necesario adquirir ningn equipo de hardware o contratar nuevo personal. A continuacin se muestra en la Figura 35 el diagrama de la topologa de hardware sobre la que estar soportada la solucin.

Figura 35. Diagrama de red del equipo de hardware de la solucin.

120

La Tabla 14 muestra la descripcin tcnica detallada de cada equipo del diagrama de red presentado arriba.
Tabla 14. Equipo de red para la solucin.

Equipo

Caractersticas
HP Blade System c7000 Enclosure Espacio para 16 blades Soporte para fibra ptica 4Gb y Ethernet 1Gb Windows: Insight Control Environment for Blade System

Sistema Blade
Unidad de Cinta PowerVault 114T Cintas de 400GB (de informacin nativa), 800GB (de informacin comprimida) Tarjeta SCSI

Unidad de cinta

HP ProLiant BL460c blade server 4 procesadores Intel Xeon 5400 Sequence a 3.16 GHz Cach de 2X6 MB L2 4 GB PC2-5300 DDR2 en RAM Disco duro SATA de 130 GB Tarjeta de fibra ptica dual-port conectada al equipo SAN Tarjeta Ethernet 1Gb

Servidor blade

121

5 servidores Poweredge 1950 III esparcidos en las 5 regiones del estado Procesador Intel Xeon cudruple E5405 2.0 GHz Cach de 2X6 MB L2 2 GB DIMM en RAM 3 Discos duros SAS de 73 GB LDAP Tarjeta Ethernet 1Gb Windows 2003 Advanced Server como controlador de dominio

PowerEdge 2950 III server 2 Procesadores Intel Xeon cudruple E5405 2.0 GHz Cach de 2X6 MB L2 4 GB DIMM en RAM 3 Discos duros SAS de 73 GB Tarjeta de fibra ptica dual-port conectada al equipo SAN Servidor de bd Tarjeta Ethernet 1Gb Windows 2003 Advanced Server Base de datos HP StorageWorks 1500 cs Modular Smart Array Canal de fibra de 2 GB 12 discos duros HP MSA20 de 250 GB en RAID 5
Controladora MSA 1500cs

2 TB (1 LUN) dedicados para dominio 4 TB (2 LUN) dedicados para el servidor de bd

Arreglo MSA20

SAN

4.3.1.3 Operativo La factibilidad operativa tiene que ver con todo tipo de actividad relacionada con el desarrollo del proyecto y que dependen de los recursos humanos disponibles. En este estudio se deben identificar las actividades operativas necesarias para lograr el objetivo del proyecto y evaluar si existe algn problema que impida la continuacin del mismo.
122

Desde el punto de vista operativo, el proyecto es totalmente viable pues existe total apoyo por parte de las direcciones administrativas (en especial de la organizacin cliente) para desarrollar el nuevo sistema de informacin. El entorno administrativo puede soportar los cambios originados por la nueva solucin, la interfaz ser amigable (de fcil uso y entendimiento) para los usuarios, el diseo estar adaptado al ambiente organizacional y sobre todo, el usuario acepta que existe la necesidad de contar una herramienta que le ayude a realizar su comunicacin escrita. 4.3.1.4 tico y legal En el desarrollo de esta solucin, no se infringen barreras legales pues la informacin que ser intercambiada, es la misma que se viene haciendo en papel entre los miembros de la organizacin. Adems no se incluirn documentos que por su naturaleza legal, tengan que estar forzosamente en papel. La institucin cuenta con el respaldo para el uso del software comercial dado que cuenta con el licenciamiento para su desarrollo. En el aspecto tico, la alternativa de solucin surge de la necesidad de apoyar la comunicacin escrita entre los miembros de la institucin, adems de que pueda ser consultada en cualquier lugar y momento, haciendo ms gil y transparente la atencin de las solicitudes. Ya que se han realizado las actividades para verificar la factibilidad y poner en marcha en proyecto, se debe pasar a la obtencin de los requisitos de la solucin usando modelos que permitan estar seguros de lo que se necesita.

4.4 El flujo de trabajo de los requisitos

En la fase de inicio, el nfasis reside principalmente en el primer flujo de trabajo fundamental, el de requisitos como lo indica la Figura 36. Este flujo de trabajo incluye identificar y detallar los casos de uso pertinentes en esta fase. Esto incluye los siguientes aspectos [JACOBSON et. al. 2000]:

123

1. Comprensin inicial del dominio. 2. Comprender el contexto del sistema mediante el modelo de negocios inicial. 3. Representar los requisitos funcionales pertinentes como casos de uso. 4. Recoger los requisitos no funcionales relacionados.

Figura 36. El flujo de trabajo de los requisitos. Los tamaos relativos a los rectngulos, slo indican qu flujos de trabajo requieren ms atencin [JACOBSON et. al. 2000].

La nica frase que ningn analista de sistemas querr escuchar nunca de un cliente es: S que ste es el sistema de informacin que yo ped, pero no es lo que quera71. Se va a comenzar con una comprensin inicial del dominio del problema y se empelar la informacin existente para construir el modelo de negocios inicial. Esto se utilizar posteriormente para preparar el conjunto inicial de los requisitos del cliente. Luego, a la luz de lo que se ha aprendido sobre los requisitos del cliente, se obtendr una comprensin ms profunda del dominio y se emplear este conocimiento para refinar el modelo de negocios y por consiguiente, los requisitos del cliente. Se realizar una iteracin de este proceso contina hasta que est satisfecho con el conjunto de requisitos que se ha obtenido.

71

SCHACH, Stephen R. Anlisis y diseo orientado a objetos con UML y el proceso unificado. tr. Lorena Peralta

Rosales. Mxico:McGraw-Hill, 2005. p. 63.

124

4.4.1 Comprensin inicial del dominio

La entidad encargada de proporcionar la informacin requerida por el sistema es la organizacin cliente. Como se mencion en el apartado de definicin del problema, la Institucin requiere un sistema de informacin para automatizar la comunicacin escrita entre las dependencias, esto con el objetivo de mejorar los tiempos de respuesta, proporcionar seguimiento en los flujos de trabajo y contar con indicadores de eficiencia en la atencin de solicitudes. Se entrevistar a personal de la organizacin cliente (organizacin cliente), con el fin de obtener informacin detallada sobre cada aspecto de la comunicacin llevada a cabo a travs de papel. Antes de realizar lo antes mencionado, es necesario adquirir conocimiento del medio; es decir, la informacin sobre los tipos de documentos, descripcin de puestos y los procedimientos llevados para establecer la comunicacin escrita de forma general. sta informacin es bsica y permitir comprender los trminos tcnicos empleados por el personal de la organizacin cliente cuando se lleven a cabo las reuniones programadas. Asimismo, si previo a las reuniones con la organizacin cliente se tiene un panorama acerca de la comunicacin escrita en general, ser posible detectar cualquier aspecto inusual llevado a cabo en el procedimiento. Los conceptos bsicos adquiridos en nuestra pequea investigacin, se colocarn en un glosario que llamaremos Glosario inicial del sistema. Con el fin de aprender acerca del proceso de comunicacin escrita, se visitaron a secretarias de la Unidad de Tecnologa estableciendo una entrevista informal acerca de las labores que desempean. Se descubri que existe una gran variedad de formas en las que los documentos son clasificados; la primera es por tipo de documento, esto son: oficios, circulares y memorndums. El oficio es el tipo de documento ms comn mientras que las circulares se empelan con menos frecuencia y los memorndums son empleados para enviar menos informacin y de forma urgente. Esta informacin se incluye en el glosario mostrado en la Tabla 15. La segunda forma de clasificar un documento es por su origen. Si el documento proviene de personal propio de la Institucin, es considerado como correspondencia interna y debe contener cierta informacin de forma obligatoria como nombre y puesto del remitente, nombre y direccin
125

de la dependencia y un nmero de folio. Por otro lado, si el documento proviene de otra institucin, el formato puede variar y se considera correspondencia externa. La tercera forma de clasificar los documentos es por la confidencialidad de la informacin. Un documento que es entregado personalmente en sobre cerrado y solo puede ser ledo por el destinatario, se considera privado. No obstante, la mayora de la correspondencia no es de este tipo y es denominada pblica.
Tabla 15. Glosario inicial del sistema de informacin. Institucin, 2010

Sistema de Informacin Formato: Glosario de Negocio

Versin:

1.0

Fecha: 1era semana

Glosario de Negocio
1. Introduccin
Este documento contiene el glosario del negocio del proyecto de software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 1.1 Propsito El propsito del glosario del negocio es obtener un conocimiento ms detallado del proceso de comunicacin escrita en la Institucin. 1.2 Alcance Se describen los trminos relevantes en materia de correspondencia. 1.3 Descripcin general Este Glosario de Negocio contiene los trminos relevantes obtenidos mediante entrevistas a la organizacin cliente seguido de su descripcin.

2. Definiciones
Trmino Oficio Descripcin Un documento dirigido a una sola persona (en ocasiones con atencin a una segunda persona), donde se informa algo o se indica una solicitud. Solo puede tratarse un tema por oficio. Puede llevar copias y es el documento ms empleado. Un documento dirigido a una sola persona donde se informa acerca de un tema de forma breve y concisa. Normalmente se envan con carcter de urgente y

Memorndum

126

Circular Correspondencia Tipo de documento Otro tipo Documento Privado Documento Pblico Confidencialidad

Documento Urgente C.C.P.

No. De oficio

Remitente Destinatario

pueden no llevar sellos ni firmas. Es un documento dirigido a varias personas donde se proporciona informacin de todo tipo. Normalmente son avisos oficiales a la comunidad universitaria. Documentos enviados y recibidos donde para la comunicacin oficial escrita de las dependencias. Un criterio de clasificacin. El formato y redaccin con la que se elabora un documento. Vase tambin oficio, memorndum, circular. Un documento que no es oficio, un memo o circular. Un documento que solo puede ser ledo por el destinatario. Se enva en sobre cerrado y sellado. Vase tambin Documento Pblico. Un documento que se enva a una dependencia y no es oficial. Vase tambin pblico. Un criterio de clasificacin. Depende de la naturaleza de la informacin, e indica si el documento puede ser visto por alguien que no es el destinatario, Vase tambin Documento Privado y Documento Pblico Cuando la informacin de un documento debe ser vista y respondida en menos de 24 horas se considera y se marca como urgente. Siglas para denominar Con copia para. Se coloca al final de documento y este es recibido por las personas indicadas adems del destinatario con carcter de informativo. Nmero de control del documento para su control interno. Generalmente es un nmero consecutivo, seguido por una diagonal / y el ao en el que fue redactado, Por ejemplo: 0032/06 Persona que enva el documento. Persona a la que va dirigido el documento.

La Figura 37 muestra los acuerdos llegado en la primera reunin con el personal de la organizacin cliente.

INSTITUCIN
Organizacin cliente Minuta de Junta
MINUTA DE JUNTA NO. 1

1. DATOS GENERALES DE LA JUNTA

Fecha: 20 de mayo 2008 Hora: 12:30 hrs. Lugar: Sala de Juntas de la organizacin cliente

127

OBJETIVO DE LA JUNTA: DEFINIR ACCIONES PARA IMPLEMENTAR EL SISTEMA DE INFORMACIN

TEMAS A TRATAR

Expresar necesidades relativas a cada entidad para implementar el Sistema de informacin.

2. ASPECTOS ADICIONALES DE LA AGENDA

1. Nombre del solicitante: Asunto:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

3. ACUERDOS Se acord que tanto los Directores Generales, como el Director y el Jefe de Departamento podrn capturar una respuesta, dependiendo del grado de autoridad y si la respuesta fue solicitada a ellos. Se acord aplicar un cuestionario tanto Directores Generales, como a Directores y Jefes de Departamento para obtener sus opiniones sobre el sistema. Se establecieron los tipos de documento manejados por la Institucin. Oficio, circular, memorando, invitacin y otros. El sistema de informacin permitir enviar documentos con estado de urgente. No se incluirn en el sistema los documentos de carcter confidencial. El sistema de informacin generar reportes automticos de correspondencia atendida en tiempo y fuera de tiempo. El sistema de informacin indexar los documentos y permitir bsquedas. La peticin de generar automticamente un oficio con datos preestablecidos para turnar instrucciones, se platicara en la siguiente reunin. El sistema de informacin contar con la opcin de turnar a Dependencias tanto de nivel jerrquico superior e inferior. El sistema de informacin contar con la opcin que el mismo folio de recepcin se turne a ms de una dependencia de la organizacin cliente. El sistema de informacin se actualizar automticamente cada 20 minutos. Se acord que la peticin de clasificar la correspondencia en estado de pendiente, no se llevara a cabo, debido a que es responsabilidad compartida en el sistema de informacin. 3. ASISTENTES
NOMBRE FIRMA

Jefe proyecto Lic. Guillermo Vera Amaro Unidad de Desarrollo de software Asesor del Secretario
Figura 37.Minuta de reunin con el personal de la organizacin cliente.

4.4.2 Comprensin del contexto del sistema

Una vez que los miembros del equipo de solicitud de requisitos se han familiarizado con el lenguaje, el siguiente paso es construir el modelo de negocios inicial, que segn [SCHACH, 2005], es una descripcin de procesos de una empresa. Se pueden utilizar una serie de tcnicas
128

diferentes para obtener informacin necesaria para construir el modelo de negocios; en esta investigacin se utilizarn las entrevistas y el cuestionario. 4.4.2.1 Entrevista Para comprender exactamente las necesidades del cliente se ha entrevistado a la asistente personal del secretario, quien ha sido designada para proporcionar la informacin acerca de la correspondencia de la Institucin. Obteniendo as, la informacin de esta fuente. La Institucin cuenta con muchas dependencias a lo largo de la organizacin, que necesitan estar comunicndose por medios oficiales, como es la correspondencia. Sin embargo, conforme esta institucin crece, las respuestas a esta correspondencia se retrasan cada vez ms y principalmente en la organizacin cliente (organizacin cliente), lo que da como consecuencia un retraso en la entrega de recursos econmicos. Las personas que pueden enviar correspondencia dentro de la institucin son los puestos de mandos y medios superiores, los cuales abarcan los puestos de jefe de departamento, coordinador, director y director general. Los remitentes elaborar el documento a enviar siguiendo un formato de secciones establecido: fecha, nmero de folio, nombre y dependencia del destinatario, cuerpo del asunto (el cual debe tratar un solo tema), nombre, dependencia y firma del remitente e indicar de con copia para. Una vez enviada la correspondencia, se tiene un plazo mximo de 7 das para enviar una contestacin, pero desafortunadamente, casi nunca sucede de esta forma. La persona entrevistada opina que esto sucede dado que no se coloca una fecha lmite de respuesta dentro del documento, ignorando as el plazo lmite para la contestacin. Asimismo, opina que ninguna dependencia tiene un control organizado y estructurado de la correspondencia que se enva y se recibe y debido a esto se acumulan demasiadas solicitudes que no son respondidas a tiempo. Otro problema encontrado con la atencin de correspondencia segn la asistente del secretario, es que las respuestas a una solicitud son realizadas va telefnica dejando sin un registro oficial la comunicacin. Normalmente estas conversaciones son como dame 3

129

das y te llamo de vuelta para avisarte que ya se atendi. Cuando pasados los tres das no hay llamada de vuelta, no existe forma de comprobar el compromiso de entrega realizado. Finalmente se mencion que existe un informe que la organizacin cliente produce actualmente de forma manual: el informe muestra toda la correspondencia enviada en un periodo de tiempo por persona, dependencia, atendida en tiempo o no y el carcter urgente o normal. El sistema podra producir estos dos informes a peticin del cliente. Un consultor de la unidad administrativa le ha aconsejado a la Institucin por medio de la organizacin cliente, adquirir un sistema de informacin que a travs de una comunicacin en red entre todas las computadoras personales de las dependencias y de esta manera enviar y recibir la correspondencia de forma digital, hacia y desde cualquier parte del mundo. Con el fin de tener una evidencia y registro del flujo de trabajo entre las dependencias de la Institucin, el sistema necesita mantener un registro de toda la correspondencia enviada. Dado que esta informacin estar disponible en Internet por medio de cualquier computadora. Los directores generales podrn emplear estos datos para obtener informacin adicional sobre correspondencia. 4.4.2.2 Cuestionario Una forma de obtener conocimiento acerca de las actividades de la Institucin en materia de correspondencia, es el envo de un cuestionario a los directores, jefes de departamento y coordinadores de la organizacin cliente. El cuestionario tiene como finalidad obtener informacin concreta sobre ciertos aspectos encontrados en la entrevista con el personal de la organizacin cliente. El cuestionario consta de 15 preguntas y puede verle en el apndice A. Se entrevistaron a un total de 8 empleados de mandos y medios superiores y a 20 secretaras ejecutivas encargadas de la correspondencia en forma manual. A continuacin se detallan los resultados obtenidos. Uno de los aspectos ms importantes es que el 70% de las dependencias encuestadas, reciben de 10 a 20 documentos por semana, 20% reciben ms de 20 y el 10% de 1 a 5 o no saben. Segn las
130

personas encuestadas, la mayora de su correspondencia son solicitudes y entre el 40% y el 60% de la correspondencia recibida tiene carcter de urgente. La Figura 38 muestra algunos de estos datos.

Figura 38. Datos obtenidos del cuestionario aplicado a personal de la organizacin cliente.

Un dato importante es que solamente dos dependencias manejan correspondencia confidencial en un porcentaje entre 10% y 20%. Este tipo de correspondencia no ser incluida en el sistema de informacin en esta primera etapa. Ninguna dependencia tiene una persona encargada exclusivamente de la correspondencia, el 80% de los encuestados sealaron que su secretaria realiza este trabajo y el 20% que lo realiza su asistente. El tipo de documento ms utilizado es el oficio y menos utilizado es la invitacin. El 60% de las personas encuestadas no saban el plazo mximo para la atencin de correspondencia y 10% afirm que no existe tal plazo.

131

Modelo de casos de uso del negocio inicial

Segn Schach [SCHACH, 2005] un modelo es un conjunto de diagramas UML que representan uno o ms aspectos del sistema de informacin que se desea desarrollar. Un modelo de casos de uso del negocio describe los procesos de negocio de una empresa en trminos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes respectivamente. Un caso de uso hace un modelado de una interaccin entre el sistema de informacin y los usuarios de este (actores). Otro aspecto a considerar en un caso de uso es que muestra la interaccin entre el sistema de informacin y el entorno en el que opera. El modelo de negocios consiste en encontrar dos elementos importantes a partir del contexto del sistema: Encontrar los actores del negocio. Encontrar las actividades o casos de uso de esos actores.

A continuacin se describen estos dos elementos. 4.4.3.1 Encontrar a los actores Ahora que se tienen los datos iniciales necesarios, es posible construir el modelo de negocio inicial. Los usuarios que actualmente manejan la correspondencia de forma manual son los asistentes o secretarias y puestos de mandos y medios superiores de la Institucin, por lo tanto, ellos son los actores en los casos de uso. Un jefe de departamento puede iniciar el caso de uso Enviar un documento o Recibir un documento, pero tambin puede atender correspondencia. Lo mismo para directores y coordinadores. Sin embargo, la correspondencia tambin es enviada hacia personas externas de la Institucin, donde no es posible generalizar los puestos. As que llamaremos destinatario al sujeto que recibe la correspondencia y remitente al que la enva. Esto puede verse en la Figura 39.

132

Figura 39. Generalizacin del remitente y del destinatario en las especializaciones Director General, Director, Jefe de Departamento, Coordinador y Externo.

4.4.3.2 Encontrar los casos de uso La Institucin tiene 4 actividades principales en relacin a la comunicacin: envo de correspondencia, recepcin de correspondencia, atencin de correspondencia y produccin de informes, todo de forma manual. Los casos de uso Enviar correspondencia, Recibir correspondencia, Atender correspondencia y Producir informe se muestran diagrama de casos de uso de la Figura 40.

Figura 40. El diagrama de casos de uso del modelo de negocios inicial de la organizacin cliente.

Estos cuatro casos de uso que conforman el modelo de negocios inicial pueden incluirse o no dentro de la lista de requisitos iniciales que se determinarn en la siguiente seccin. Es importante mencionar que en el modelo de negocios, solo intentamos comprender el cmo funcionan los procedimientos de la institucin y no lo que har el sistema. Por ahora slo es
133

necesario explicar cada uno de los casos de uso, as que se aaden las descripciones de estos en la Tabla 16,

Tabla 17, Tabla 18y Tabla 19.

Tabla 16. La descripcin del caso de uso Enviar Correspondencia del modelo de negocios inicial de la organizacin cliente. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Especificacin de caso de uso: Enviar correspondencia

1. Enviar correspondencia
1.1 Breve Descripcin El caso de uso Enviar correspondencia permite a un Remitente enviar correspondencia a un Destinatario.

2. Flujo de Eventos
2.2 Flujo Bsico 1. El Remitente escoge el tipo de documento que enviar. Este puede ser oficio, memo, circular, invitacin y otro. 2. El Remitente escribe el nombre, puesto y dependencia de destinatario en el documento. 3. El Remitente redacta el tema a tratar en el documento. Se sugiere que sea menor a una cuartilla siempre que sea posible. 4. El Remitente colocar su nombre, puesto, dependencia y firma en el documento. 5. S hay que enviar copias a otros involucrados, se especifica en la parte inferior en la seccin Con Copia Para. 6. S la correspondencia va dirigida a una dependencia dentro de la ciudad, se enva con un mensajero. 7. S la correspondencia va dirigida a una dependencia en otra ciudad, se enva primero por fax y posteriormente el documento original por paquetera.

134

Tabla 17. La descripcin del caso de uso Recibir Correspondencia del modelo de negocios inicial de la organizacin cliente. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Especificacin de caso de uso: Recibir correspondencia

1. Enviar correspondencia
1.1 Breve Descripcin El caso de uso Recibir correspondencia permite a un Destinatario recibir la correspondencia de un Remitente.

2. Flujo de Eventos
2.2 Flujo Bsico 1. La correspondencia es recibida por el Destinatario en fax, paquetera o fsicamente de un mensajero. 2. Se coloca la fecha de recepcin y un sello de la dependencia que recibe.

Tabla 18. La descripcin del caso de uso Atender Correspondencia del modelo de negocios inicial de la organizacin cliente. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Especificacin de caso de uso: Atender correspondencia

1. Enviar correspondencia
1.1 Breve Descripcin

135

El caso de uso Atender correspondencia permite a un Destinatario responder a la correspondencia de un Remitente.

2. Flujo de Eventos
2.2 Flujo Bsico 1. La correspondencia es revisada por el Destinatario. 2. S el Destinatario tiene facultades para responder la solicitud, enva una respuesta siguiendo los pasos del caso de uso Enviar correspondencia. La respuestas pueden ser: 3. Solicitud atendida y aceptada. 4. Solicitud atendida pero rechazada. 5. S el Destinatario no tiene facultades para atender la solicitud, puede hacer dos cosas: 6. La turna a otra persona que puede atenderla y enva una respuesta de correspondencia turnada al Remitente siguiendo los pasos del caso de uso Enviar correspondencia. 7. Enva una respuesta al Remitente de solicitud no atendida por no tener facultades de hacerlo. 8. S el destinatario tiene facultades para responder la solicitud, pero necesita el Vo. Bo. de otras personas, enva el documento para su aprobacin a todos los involucrados. 9. Una vez que tiene el Vo. Bo. de las personas requeridas, se enva una respuesta siguiendo los pasos del caso de uso Enviar correspondencia.

Tabla 19. La descripcin del caso de uso Producir un informe del modelo de negocios inicial de la organizacin cliente. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

1.0

Fecha: 1era semana

Especificacin de caso de uso: Producir un informe

1. Enviar correspondencia
1.1 Breve Descripcin El caso de uso Producir un informe permite a un Remitente obtener informacin sobre el estado de la correspondencia enviada en un periodo de tiempo determinado.

2. Flujo de Eventos
136

2.2 Flujo Bsico 1. El Remitente solicita un informe de estado de correspondencia en un periodo de tiempo usualmente por mes. 2. El reporte se realiza manualmente en Excel y se le agregan grficos de barras especificando el estado de la correspondencia. 3. Finalmente se imprime en papel y se archiva.

Ahora nos encontramos listos para preparar los requisitos iniciales.

4.4.4 Requisitos iniciales o funcionales

Los cuatro casos de uso de la Figura 40 comprenden el modelo de negocios de la organizacin cliente. Sin embargo, a primera vista no es evidente si son todos los requisitos del sistema de informacin que se va a desarrollar. En esta etapa tan temprana, no hay suficiente informacin a disposicin para asegurar que este es lo nico que se necesitar. En situaciones como sta la mejor manera de proceder es preparar los requisitos iniciales con la informacin actual y si despus se obtiene ms, se iterar. En acuerdo con la organizacin cliente, podemos establecer que tres casos de uso Enviar correspondencia, Atender correspondencia y Producir informe sern parte del sistema de informacin, es decir, sern los requisitos iniciales. El caso de uso Recibir correspondencia ya no ser tomado en cuenta pues ya no es necesario colocar un sello y fecha de recepcin en papel. Ya que las versiones actuales de cada una de las descripciones de los casos de uso no tienen grandes detalles, es necesario obtener ms informacin sobre los procesos. Equipados con el conocimiento del dominio y la familiaridad con el modelo de negocios inicial, ahora se examina la documentacin relevante, concretamente a los registros manuales actuales de la organizacin cliente. El objetivo es determinar qu atributos son necesarios introducir cuando se realiza un documento. Se aprende que la organizacin cliente necesitar registrar los datos siguientes para cada documento que enve:

137

Descripcin del documento: No. de Folio (4 caracteres, seguidos por un nmero consecutivo, seguidos por el ao con formato yy). Fecha de creacin (dd/mm/yyyy). No. de oficio/memo s es un documento proveniente de una dependencia externa (dd/mm/yyyy). Fecha de oficio/memo s es un documento proveniente de una dependencia externa (dd/mm/yyyy). Nombre del remitente (hasta 150 caracteres) Puesto del remitente (hasta 100 caracteres) Dependencia remitente (hasta 150 caracteres). Asunto (texto). Observaciones (texto). Fecha de envo (dd/mm/yyyy). Se selecciona(n) la dependencia(s) y persona(s) a la(s) que se enva. Clasificar el documento como documento tendr respuesta o NO tendr respuesta. Establecer la prioridad del documento como Normal o Urgente. Con el fin de obligar a una respuesta en un tiempo establecido, se calcula la Fecha de compromiso sumando 7 das hbiles a la fecha de creacin (dd/mm/yyyy). Se selecciona(n) la dependencia(s) y persona(s) a la(s) que se enva como c.c.p..

Una actualizacin a la descripcin del caso de uso de los requisitos iniciales Enviar correspondencia refleja esta informacin en la Tabla 20.
Tabla 20. La descripcin del caso de uso Enviar Correspondencia de los requisitos iniciales del sistema de informacin de correspondencia. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

2.0

Fecha: 24/07/2008

Especificacin de caso de uso: Enviar correspondencia

1. Enviar correspondencia
1.1 Breve Descripcin El caso de uso Enviar correspondencia permite a un Remitente enviar correspondencia a un Destinatario.

138

2. Flujo de Eventos
2.2 Flujo Bsico 1. El Remitente introduce los detalles del documento que va a enviar. Estos son: No. de Folio Fecha de creacin No. de oficio/memo (s es un documento proveniente de una dependencia externa). Fecha de oficio/memo (s es un documento proveniente de una dependencia externa). Nombre del remitente Puesto del remitente Dependencia remitente Asunto Fecha de envo Observaciones 2. El Remitente selecciona el nombre, puesto y dependencia de destinatario. 3. El Remitente establece si el documento requerir respuesta o no. 4. El Remitente establece la prioridad del documento como: 5. Normal 6. Urgente 7. El sistema calcula la Fecha compromiso sumando 7 das hbiles a la fecha de creacin. 8. S hay que enviar copias a otros involucrados, se especifica en la parte inferior en la seccin Con Copia Para.

En el caso de la atencin de los documentos, necesitar registrar los datos siguientes:

Clasificar la peticin o asunto atendido como Si, No o Pendiente. En el caso de que la peticin se clasifique como No atendida, se deber especificar el Motivo de no haber sido atendida (texto). Asunto de la respuesta (texto). Fecha de envo (dd/mm/yyyy).

139

Se selecciona(n) la dependencia(s) y persona(s) a la(s) que se enva la respuesta como c.c.p..

Adems, tambin requieren que el sistema incluya indicaciones de desempeo marcados en la certificacin de calidad ISO-9001 que se encuentra en trmite actualmente, como: correspondencia atendida en tiempo, en proceso de atencin, vencido sin respuesta, entre otros. La lista completa de indicadores puede verse en la Figura 41.

Figura 41. Lista de indicadores de desempeo para la certificacin ISO-9001 de la organizacin cliente.

La actualizacin a la descripcin del caso de uso de los requisitos iniciales Atender correspondencia refleja esta informacin en la Tabla 21.
Tabla 21. La descripcin del caso de uso Atender Correspondencia de los requisitos iniciales del sistema de informacin de correspondencia. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

2.0

Fecha: 2da semana

Especificacin de caso de uso: Atender correspondencia

1. Enviar correspondencia
140

1.1 Breve Descripcin El caso de uso Atender correspondencia permite a un Destinatario responder a la correspondencia de un Remitente.

2. Flujo de Eventos
2.2 Flujo Bsico 1. La correspondencia es revisada por el Destinatario. 2. S el Destinatario tiene facultades para responder la solicitud, enva una respuesta siguiendo los pasos del caso de uso Enviar correspondencia. La respuestas pueden ser: 3. Solicitud atendida y aceptada. 4. Solicitud atendida pero rechazada. 5. S el Destinatario no tiene facultades para atender la solicitud, puede hacer dos cosas: 6. La turna a otra persona que puede atenderla y enva una respuesta de correspondencia turnada al Remitente siguiendo los pasos del caso de uso Enviar correspondencia. 7. Enva una respuesta al Remitente de solicitud no atendida por no tener facultades de hacerlo. 8. S el destinatario tiene facultades para responder la solicitud, pero necesita el Vo. Bo. de otras personas, enva el documento para su aprobacin a todos los involucrados. 9. Una vez que tiene el Vo. Bo. de las personas requeridas, se enva una respuesta siguiendo los pasos del caso de uso Enviar correspondencia.

Finalmente se considerarn los informes. Observando los registros manuales de la organizacin cliente, se determina que sus necesidades son las siguientes:
Se requiere un informe para mostrar toda la correspondencia recibida y enviada en un periodo de tiempo determinado. La salida debe tener el orden siguiente: Indicador de estado No. de folio Enviado por Dependencia remitente Destinatario Fecha de envo Fecha de compromiso Peticin o asunto atendido Resumen del asunto Resumen de la respuesta

141

Un segundo informe detectado debe mostrar grficos de barras donde se especifique en diferentes colores los porcentajes y cantidades de lo siguiente: Asuntos atendidos dentro de la fecha compromiso (verde) Asuntos atendidos fuera de la fecha de compromiso (amarillo) Asuntos en tiempo sin atender (azul) Asuntos sin atender a dos das de fecha compromiso (azul claro) Asunto solo informativo Asuntos en borrador (morado) Asuntos no atendidos (rojo)

La actualizacin a la descripcin del caso de uso de los requisitos iniciales Producir un informe refleja esta informacin en la Tabla 22
Tabla 22. La descripcin del caso de uso Producir un informe de los requisitos iniciales del sistema de informacin de correspondencia. Institucin, 2010

Sistema de Informacin Formato: Especificacin de caso de uso Unidad de Tecnologa

Versin:

2.0

Fecha: 2da semana

Especificacin de caso de uso: Producir un informe

1. Enviar correspondencia
1.1 Breve Descripcin El caso de uso Producir un informe permite a un Remitente obtener informacin sobre el estado de la correspondencia enviada en un periodo de tiempo determinado.

2. Flujo de Eventos
2.2 Flujo Bsico 1. Los siguientes informes deben generarse a peticin en pantalla o impresos: 2. Informe de correspondencia enviada o recibida en un rango de fechas especficas. 3. El sistema muestra toda la correspondencia enviada y recibida. La salida est en el orden siguiente:

Indicador de estado No. de folio Enviado por

142

Dependencia remitente Destinatario Fecha de envo Fecha de compromiso Peticin o asunto atendido Resumen del asunto Resumen de la respuesta

Este informe se ordena por fecha de creacin por omisin, pero puede ordenarse dando clic en el nombre de la columna. 4. Informe grfico de rendimiento por dependencia en un rango de fechas especficas: El sistema muestra un grfico de barras especificando por colores los porcentajes y nmero de documentos con los siguientes estados:

Asuntos atendidos dentro de la fecha compromiso (verde) Asuntos atendidos fuera de la fecha de compromiso (amarillo) Asuntos en tiempo sin atender (azul) Asuntos sin atender a dos das de fecha compromiso (azul claro) Asunto solo informativo Asuntos en borrador (morado) Asuntos no atendidos (rojo)

4.4.5 Requisitos adicionales o no funcionales

Los requisitos adicionales son fundamentalmente requisitos no funcionales que no pueden asociarse a ningn caso de uso en concreto. Algunos ejemplos son el rendimiento, las interfaces y los requisitos de diseo fsico, as como restricciones de implementacin [JACOBSON et. al. 2000]. 4.4.5.1 Requisitos de plataforma hardware
143

Desde este punto de vista tcnico, la Tabla 23 muestra los elementos requeridos para llevar a cabo el desarrollo.

144

Tabla 23. Comparacin entre los elementos tcnicos requeridos y los actuales. Requisitos Infraestructura disponibilidad. de red de alta Recursos actuales Se cuenta con una red institucional interconectada con fibra ptica totalmente operacional y de alta disponibilidad en las cinco regiones del estado. Sitio adecuado para alojar los servidores Web y de base de datos. Servidor Web para alojar la aplicacin. Se cuenta con un sitio principal en la acondicionado para alojar a los servidores institucionales. Se cuenta con un HP BladeSystem c700 Enclosure con capacidad para 16 blades. La aplicacin ser colocado en uno de los blades HP ProLiant BL460c con 4 procesadores Xeon, 4 GB en RAM y 135 GB en HD, sobre un Windows 2003 Advanced Server x32. Servidor de Base de datos. Se tiene un servidor institucional de base de datos en otro de los blades HP ProLiant BL460c con las mismas caractersticas de hardware sobre SQL Server 2005. El almacenamiento de los datos se realiza sobre un SAN HP StorageWorks 1500 cs Modular Smart Array conectado al blade por fibra ptica y con un LUN dedicado de 2 TB expansible a 20 TB. Equipo de trabajo La Unidad de Tecnologa cuenta con la Unidad de Desarrollo que se encarga del desarrollo de sistemas de este tipo en la institucin.

4.4.5.2 Requisitos de diseo de interfaz

Acceso al Sistema La interfaz deber estar desarrollada para Web y debe ser muy parecida a un programa de recepcin y envo de correo electrnico con la finalidad de que sea muy familiar de usar para el personal administrativo de la institucin. La mayora del personal ha sido capacitado en el uso del cliente de correo durante el ltimo ao y se pretende aprovechar esta capacitacin haciendo la interfaz del sistema de correspondencia lo ms parecida posible.

4.4.5.3 Restricciones en la plataforma software

Servidores Sistemas operativos Windows Server 2003. Servidor Web IIS 6.0.

145

Base de datos SQL. Clientes Cualquier sistema operativo con un navegador de Internet compatible con XHTML 1.0. Como Firefox 1.0 o superior o Microsoft Explorer 5.0 o superior.

4.4.5.4 Otros requisitos

Seguridad La transmisin debe ser segura, entendiendo por esto que slo las personas autorizadas pueden tener acceso a la informacin. La institucin est en proceso de trmite para obtener un certificado SSL de 1024 bits para el servidor Web. Cada actor del sistema podr ver slo su informacin y no la de los dems.

Disponibilidad El sistema ser publicado en Internet en el dominio http://dominio/ las 24 hrs.

Facilidad de Aprendizaje El tiempo de aprendizaje (mediante un manual de operacin con instrucciones paso a paso proporcionadas) para el manejo de la correspondencia no debe exceder de 20 minutos para el 90 por ciento de los usuarios. Es por ello que la interfaz ser similar a un cliente de correo comercial.

4.4.6 Descripcin de la Arquitectura

Booch define a la arquitectura como lo que especifica el arquitecto en la descripcin de la arquitectura y esta descripcin permite al arquitecto controlar el desarrollo del sistema desde la perspectiva tcnica [JACOBSON et. al. 2000]. En esta etapa temprana del proyecto, se debe definir qu tipo de arquitectura utilizar el sistema pues en cada fase del mismo se describe mediante vistas de los modelos. En esta fase, se describe de manera esttica como una vista del modelo de casos de uso visto en el apartado anterior.

146

4.4.6.1 Tipo de arquitectura Se implementar una arquitectura cliente-servidor de tres niveles donde la carga se divide precisamente en tres capas con reparto claro de funciones y en donde una capa solamente tiene relacin con la siguiente. Desde el punto de vista lgico, la arquitectura se conforma de las siguientes capas: Capa de presentacin. Se encarga de la interaccin directa con el usuario. Capa de aplicacin o lgica. Se dedica a implantar los requisitos y funcionalidades del negocio. Capa de datos. Se encarga de la persistencia de los datos.

Desde el punto de vista fsico, esta arquitectura en tres capas se construye de la siguiente manera: 1. Un servidor Web front-end que sirve contenido esttico. 2. Un servidor de aplicacin middle-end que procesa de generacin y proceso de contenido dinmico. En este caso el Framework .NET. 3. Un servidor back-end de almacenamiento de los datos. En este caso un el sistema gestor de bases de datos relacional SQL. La Figura 42 muestra estas tres capas grficamente.

Figura 42. Vista de la arquitectura fsica en tres capas.

147

4.4.6.2 Vista del modelo de casos de uso Nuestra primera seccin72 de la arquitectura es la vista del modelo de casos de uso, la cual presenta los actores y casos de uso ms importantes y se muestra en la Tabla 24.
Tabla 24. Vista de la arquitectura del modelo de casos de uso. Institucin, 2010

Sistema de Informacin Formato: Vista de la arquitectura del modelo de casos de uso Unidad de Tecnologa

Versin:

1.0

Fecha: 2da semana

Vista de la arquitectura del modelo de casos de uso

1. Introduccin
Este documento contiene la primera versin de la arquitectura en su vista lgica del proyecto de software llamado Sistema de Informacin que ser desarrollado por la Unidad de Tecnologa de la Institucin. 1.1 Propsito El propsito es construir la arquitectura del sistema basada en los modelos de cada fase. 1.2 Alcance Es una vista del modelo de casos de uso inicial del negocio que conforman la capa lgica de la arquitectura. 1.3 Descripcin general La vista se compone de la primera versin de los diagramas de casos de uso y sus descripciones. Esto es un bosquejo del documento de especificaciones que se refinara en la fase de elaboracin.

72

La descripcin de la arquitectura consta de 5 secciones, una para cada modelo: vista del modelo de casos de uso,

vista del modelo de anlisis, vista del modelo de diseo, vista del modelo de despliegue y una vista del modelo de implementacin.

148

2. Vista grfica de la arquitectura

Con la informacin obtenida hasta ahora parece que todo es satisfactorio, al menos por ahora. Sin embargo, en el transcurso del anlisis orientado a objetos o en la fase de elaboracin pueden aparecer fallas, se pueden necesitar otros requisitos o puede suceder que los existentes ya no se apliquen.

4.5 Resumen del captulo

En este captulo dedicado a la primera fase de iniciacin del proyecto, se comenz con el flujo de trabajo de la gestin del proyecto en el cual se mostr la planeacin de la fase, la identificacin de la necesidad y la evaluacin de soluciones alternativas y para seleccionar una y realizar la descripcin de la propuesta de solucin tomando en cuenta los riesgos del proyecto. Posteriormente se mostr el flujo de trabajo de la configuracin en donde se especific el control y a evaluacin de los cambios durante todo el proyecto. No abordaremos ms en este flujo pues el objetivo no es mostrar la administracin de los cambios.

149

Se abord tambin el flujo de trabajo del entorno en donde a pesar de tener cierta certeza de la viabilidad del proyecto por ser interno, se realiz un estudio de factibilidad tomando en cuenta los aspectos econmico, tcnico, operativo, tico y legal. El flujo de trabajo de los requisitos es donde se comienza realmente a trabajar pensando ms en el producto de software a construir realizando la comprensin inicial del dominio y del contexto del sistema utilizando herramientas como la entrevista y el cuestionario con el nico objetivo de construir nuestro modelo de casos de uso del negocio que es el primer modelo entregable del proyecto. Este modelo consta de la lista de los actores y los casos de uso del sistema. Parte de este modelo, son los requisitos iniciales o funcionales que afectan directamente el comportamiento de los casos de uso y los requisitos adicionales o no funcionales que son el entorno en donde se implantaran los mismos como la plataforma de hardware y software. Para terminar el captulo se elabor otro entregable importante de esta fase, descripcin de la Arquitectura la cul es una vista del modelo de casos de uso donde identificamos los actores y sus acciones ms relevantes en trminos tcnicos y separados en tres capas funcionales bien delimitadas: presentacin, aplicacin y almacenamiento. En el siguiente captulo se comenzar a realizar el anlisis y diseo del proyecto basndose en los requisitos encontrados hasta ahora. Se debe recalcar que aunque en la fase de elaboracin se pondr especial inters en los flujos de trabajo de anlisis y diseo, es posible que se abarque todava un poco de los requisitos para refinarlos y/o complementarlos. En esta metodologa siempre es posible regresar entre flujos de trabajo por medio de iteraciones y es esta caracterstica lo que la distingue por su gran flexibilidad y tolerancia a los cambios.

150