Fase de Inicio

Introducción

El objetivo de la fase de inicio es la puesta en marcha del proyecto.

Se inicia el análisis de negocio hasta el punto necesario para justificar la puesta en
marcha del proyecto, en la fase de elaboración se completará dicho análisis.
Las actividades principales de la fase de inicio son las siguientes:
1. Delimitar el ámbito e identificar interfaces con sistemas remotos.
2. Describir una propuesta de arquitectura del sistema, llegándose a una descripción de
la arquitectura (primeras versiones de los modelos). Demostrado que es viable, se
construirá en la fase de elaboración.
3. Identificar riesgos críticos y determinar si se pueden mitigar en fases posteriores,
sólo se consideran los que afecten a la viabilidad, los no críticos simplemente se
apuntan.
4. Construcción de un prototipo que muestre que se pueden solucionar los problemas
del cliente y de los usuarios finales pero que no tiene porqué dar lugar al producto
final. (opcional)

Objetivos:
-Justificar la puesta en marcha del proyecto.
-Delimitar el ámbito y el alcance del sistema para discernir qué debemos cubrir con el
proyecto, comprender qué debe cubrir la arquitectura, definir los límites dentro de los
cuales debemos buscar los riesgos críticos y para delimitar las estimaciones de coste,
agenda y recuperación de la inversión (modelo de negocio)
-Identificar una arquitectura candidata.
-Identificar y mitigar riesgos críticos.
-Desarrollar el análisis inicial del negocio.
-Crear un entrono de desarrollo.

Antes de la fase de inicio

Petición de desarrollo de un sistema y descripción de éste cuyo nivel de detalle varía en
función del cliente y de si se trata de un sistema nuevo o de una modificación.

Planificación de la fase de inicio:

-Reunir la información recogida antes de comenzar el proyecto.
-Organizarla.
-Reunir un grupo de gente para que la trate.
-Descubrir que falla en términos de los objetivos de la fase de inicio.

Se desarrolla un plan provisional para clarificar los requisitos que conciernen a esos
objetivos iniciales y para detallar los correspondientes casos de uso.
Se desarrolla un plan para crear una arquitectura candidata sólo hasta el punto de
establecer si el proyecto es factible.
Ampliación de la descripción del sistema:
Interviene el equipo de desarrollo y el cliente ( y puede que los usuarios). Se busca la
mejor solución que integre todos los puntos de vista, no un consenso.

Establecimiento de los criterios de evaluación:

-Decidir el ámbito del sistema se define con precisión. Se identifican los actores
externos y la naturaleza de su interacción con el sistema. Criterios:
• ¿Está claro lo que va a formar parte del sistema?
• ¿Se han identificado todos los actores?
• ¿Se ha expuesto la naturaleza general de las interfaces?
• ¿Puede, lo que está incluido en el ámbito, constituir por sí mismo un sistema que
funcione?

-Resolver ambigüedades en los requisitos necesarios en esta fase

• ¿Se han identificado y detallado los requisitos (funcionales y no funcionales) del
limitado número de casos de uso necesarios para alcanzar los objetivos de esta
fase?
• ¿Se han identificado y detallado los requisitos adicionales?

-Determinar una arquitectura candidata se debe desarrollar una arquitectura fiable

para las funciones que puedan poner en peligro el desarrollo del sistema.
• ¿Satisface esta arquitectura las necesidades de los usuarios?
• ¿Es verosímil que funcione?
o ¿Puede usar de forma apropiada la tecnología sobre la que va a ser
construida?
o ¿Puede ser eficiente?
o ¿Puede explotar los recursos existentes?
o ¿Puede ser fiable y tolerante a fallos?
o ¿Será robusta y flexible al cambio?
o ¿Evolucionará fácilmente si se añaden requisitos?

-Mitigar riesgos críticos los riesgos críticos son aquellos que si no son mitigados
ponen en peligro el éxito del proyecto:
• ¿Se han identificado todos los riesgos críticos?
• ¿Se han mitigado los riesgos identificados o existe un plan para mitigarlos?

-Juzgar el valor del caso de negocios inicial.

La primer iteración de la fase de inicio debe incluir:
• Ajustar el Proceso Unificado al proyecto y seleccionar herramientas para la
automatización del proceso.
• Reunir gente con el talento necesario para el proyecto.
• Crear relaciones que den lugar a un equipo efectivo.
• Entender el dominio, que a menudo es desconocido para el equipo.
• Percibir la naturaleza del proyecto, que será más difícil si se trata de un desarrollo
nuevo que si se trata de la extensión de un producto ya existente.
• Familiarizar al equipo con las herramientas apropiadas para el proceso y el
proyecto.

Flujo de trabajo:

Dos grupos de actividades:

-Definición del ámbito del sistema (encontrara actores y casos de uso, asignar
prioridades a los casos de uso, detallar casos de uso, analizar casos de uso, estructurar el
modelo de casos de uso, construir un prototipo de interfaz de usuario, análisis de la
arquitectura).
-Esbozar arquitectura candidata (asignar prioridad a los casos de uso, análisis de la
arquitectura, diseño de la arquitectura).

-Recopilación de requisitos
1. Enumerar los requisitos candidatos a figurar en la lista de características del
sistema.
Se crea la lista de características, cada característica tiene un nombre
corto, una breve descripción y un conjunto de valores que incluye estado,
coste de implementación prioridad y nivel de riesgo asociado.

2. Comprender el contexto del sistema

Si el cliente no posee un modelo de negocio debemos alentarle a
desarrollarlo. Se entiende por modelo de negocio una descripción de los
procesos del sistema con objeto de comprenderlos, esta descripción debe
incluir trabajadores, responsabilidades y operaciones que se llevan a
cabo.

3. Representar los requisitos funcionales pertinentes como casos de uso

4. Recoger los requisitos no funcionales

Especifican propiedades del sistema, algunas hacen referencia a
fenómenos del mundo real, se relacionan con un caso de uso o una clase
concreta.
-Representar los requisitos como casos de uso:
• Encontrar actores y casos de uso los casos de uso se han ido ordenando en
función del riesgo asociado. Se seleccionan aquellos relacionados con el
ámbito del sistema y con la arquitectura, es decir, los que describan alguna
funcionalidad importante y crítica, o que impliquen algún requisito
importante que deba desarrollarse pronto dentro del ciclo de vida del
software. Se generará un glosario y un prototipo de interfaz de usuario.
• Determinar la prioridad de los casos de uso.
• Detallar un caso de uso aquellos necesarios para determinar el ámbito del
sistema, planificar como mitigar un riesgo crítico o planificar la línea de base
de la arquitectura.

-Análisis como objetivos generales analizar requisitos, refinarlos y estructurarlos en

un modelo de objetos que sirva como entrada al modelo de diseño. El resultado es un
modelo inicial de análisis para definir con precisión los casos de uso y que sirva como
guía en el establecimiento de la arquitectura candidata.
• Análisis de la arquitectura Clasificar los casos de uso, entenderlos y
refinarlos para construir una primera versión del modelo de análisis.
o Identificar paquetes de análisis
o Identificar clases de entidad
o Identificar requisitos especiales comunes
Persistencia
Distribución y concurrencia
Características de seguridad
Tolerancia a fallos
Gestión de transacciones

• Analizar un caso de uso analizar y refinar los casos de uso escogidos

detallando los más importantes.
o Identificación de clases de análisis
o Descripción de interacciones entre objetos del análisis
o Captura de requisitos especiales

• Analizar una clase y analizar un paquete se hace será mínimamente.

-Diseño como objetivo general esbozar el modelo de diseño de arquitectura

candidata. Se puede desarrollar un prototipo de demostración.
• Diseño de la arquitectura Realizar los casos de uso como colaboraciones
entre subsistemas o clases. Identificar mecanismos genéricos de diseño que
serán necesarios en las capas subyacentes de los subsistemas identificados.
Se elige el software del sistema y los marcos de trabajo que se emplearán en
la capa intermedia. Se llevan a cabo tanto los requisitos funcionales
representados por los casos de uso como los no funcionales. Si el sistema es
distribuido se incluye una versión reducida del modelo de despliegue.
o Identificar nodos y configuración de red
o Identificar subsistemas e interfaces
• Subsistemas de aplicación
• Subsistemas intermedios y de software del sistema
• Dependencias entre subsistemas
• Interfaces entre subsistemas
 o Identificar clase de diseño relevantes para la arquitectura
• Identificación de clases de diseño a partir de las clases de análisis.
• Identificación de clase activas
o Identificar mecanismo genéricos de diseño.
o Diseña un caso de uso si se hace es mínimamente.
o Diseñar un clase y diseñar un subsistema si se hace es mínimamente.

-Implementación Sólo necesaria si se va a realizar un prototipo de demostración.

-Pruebas Trabajo mínimo.

Ajuste del proyecto al entorno de desarrollo.

Se inicia en la fase de inicio y se culmina en la fase de elaboración.
Entrono de desarrollo
o Procesos configuración y mejora del proceso.
o Herramientas para llevarlo a cabo apoyo a los flujos de trabajo, herramientas
administrativas par la gestión de proyectos, gestión de la configuración y los
cambios, generación de documentación y herramientas on-line relacionadas con el
propio proceso. Se pueden desarrollar herramientas especiales.
o Servicios administración del sistema, copia de seguridad y telecomunicaciones.

Realización del análisis inicial de negocio

Costes económicos: exigencias de recursos del proyecto, costes de la inversión.
Estimaciones de beneficios y de aceptación (de mercado o interna).

• Esbozar una apuesta económica Simple estimación por el pequeño número de

casos de uso realizados. Se toman los casos de uso como medida de tamaño para
realizar las estimaciones. La cantidad de horas-personas necesarias para diseñar,
implementar y probar un caso de uso depende de:
o Estilo cantidad de características, potencia del caso de uso.
o Complejidad del sistema propuesto se puede simplificar reduciendo la
funcionalidad.
o Tamaño el caso de uso de un sistema pequeño es más fácil de implementar.
o Tipo de aplicación por ejemplo las de tiempo real son más complejas.

El análisis inicial de negocio sirve para determinar si se entra en la fase de

elaboración.
• Estimar la recuperación de la inversión Si es un software comercial deben
estimarla los expertos en ventas, si es para uso interno el cliente debe especificar el
ahorro esperado.

Evaluación de las iteraciones de la fase de inicio:

Se crea un grupo de evaluación que incluye representantes del cliente y / o de los
usuarios. Posibles criterios para realizar más iteraciones:
• Ampliación del modelo de casos de uso
• Desarrollo de un prototipo exploratorio.
• Sospecha de que no se hayan encontrado todos los riesgos críticos.
• Si no han sido mitigados todos los riesgos críticos o no han sido suficientemente
cubiertos por un plan de emergencia.

El resultado final de la evaluación determina si se sigue adelante o se abandona el

proyecto.

Planificación de la fase de elaboración

Se determina alrededor del 80% de los casos de uso incluyendo todos aquello que sea
importante para la arquitectura. Se necesitan ambos aspectos para realizar una apuesta
económica exacta. De los casos de uso identificados será necesario analizar
aproximadamente la mitad. Del conjunto de casos de uso analizados se selecciona la
parte más significativa para el diseño de la línea de base de la arquitectura, que incluye
una descripción de la arquitectura y nuevas versiones de todos los modelos.
Se determina el número de iteraciones y qué requisitos se implementarán y probarán en
cada iteración.

Productos de la fase de inicio

• Lista de características
• Primera versión del modelo de negocio
• Esbozo de los modelos de casos de uso, análisis, diseño y despliegue. Los de
implementación y pruebas serán rudimentarios. Primera versión de los requisitos
adicionales.
• Primer esquema de la descripción de la arquitectura candidata que perfila las vistas
de los modelos de casos de uso, análisis, diseño e implementación
• Prototipo exploratorio (opcional)
• Lista inicial de riesgos y clasificación de casos de uso
• Rudimentos de un plan para el proyecto en su totalidad, incluyendo el plan general
de las fases.
• Primer borrador del análisis de negocio, incluyendo el contexto del negocio y los
criterios de éxito como estimación de beneficios, reconocimiento de mercado y
estimación del proyecto.
Objetivos del ciclo de vida
En la fase de inicio se clarifican los objetivos del ciclo de vida del software dando
respuesta a las siguientes preguntas:
• ¿Se ha determinado con claridad el ámbito del sistema?¿Se ha determinado lo que
va a estar dentro del sistema y lo que va a estar fuera de él?
• ¿Se ha llegado a un acuerdo con todas las personas involucradas sobre los requisitos
fundamentales del sistema?
• ¿Se vislumbra una arquitectura que implemente estas características?
• ¿Se han identificado los riesgos críticos para el desarrollo exitoso del proyecto? ¿Se
prevé una forma de mitigarlos?
• ¿El uso del producto generará beneficios que justifiquen lo invertido en su
construcción?
• ¿Es factible para su organización llevar adelante el proyecto?
• ¿Están los inversores de acuerdo con los objetivos?
Desarrollo de la Fase de Inicio

PSI 2.1: Especificación del Ámbito y Alcance

De manera más concreta que en la actividad Inicio del Plan de Sistemas de

Información (PSI 1), en esta tarea se describe el ámbito de los procesos de la
organización a considerar. Igualmente, se definirá el alcance, es decir, los objetivos
específicos del Plan de Sistemas de Información. Puede ser necesario determinar
distintos objetivos para cada proceso del proyecto. Los responsables de los distintos
procesos de la organización afectados por el Plan de Sistemas de Información
participarán de forma activa en la definición de los objetivos, sin perder de vista los
resultados de la actividad anterior.

El proceso de anillamiento, del que se ocupará este Sistema de Información, se divide

en otros tres procesos claramente delimitados: la toma de datos, el almacenamiento y
tratamiento de los datos y la comunicación de los mismos.

Seguidamente se relata el proceso completo de anillamiento abarcando todas sus fases:

- Una vez en el campo, se realiza la toma de datos. El anillador captura un ejemplar,

el modo es irrelevante para este Sistema de Información, si procede lo anilla, ya
sea con la anilla oficial si el ejemplar no estaba anillado o con otros tipos de anillas
para controles propios del anillador. Posteriormente, con la ayuda de otro(s)
anillador(es), tras determinar la edad y el sexo del ejemplar, obtiene información
biométrica del ave como medidas del ala, la cola, parámetros de crecimiento o
cualquier otra medida que estime conveniente.

- La siguiente fase, almacenamiento y tratamiento de los datos, consiste en incluir en

una estructura común, una Base de Datos, todos los datos referentes al ejemplar
capturado obtenidos en la fase anterior. Los usuarios informáticos serán los
encargados de dicho trasvase de información. También en esta fase se procede al
tratamiento de los datos una vez han sido almacenados. Los anilladores deberán
establecer relaciones entre los datos almacenados y realizar los análisis que
consideren oportunos basados en dichas relaciones.

- La última fase es la de comunicación de los datos. Se distinguen dos tipos de

comunicación, la oficial, sujeta a determinadas normas, y la informal. Como se ha
indicado la comunicación, ya que está sujeta a unas normas, se vale de documentos
ya predeterminados que el anillador debe rellenar correctamente.

Tomando como referencia la mencionada separación en procesos se obtiene el

catálogo de objetivos:

- Como objetivos generales se deben considerar la fiabilidad. Dicho aspecto se puede

ver limitado por las trascripciones de datos, ralentizan los procesos y aumentan el
riesgo de errores en la comunicación de datos entre los tres procesos previamente
señalados.
- Como objetivos específicos de cada proceso se consideran la rapidez y sencillez en
la toma de datos, puesto que el anillador realiza dicha tarea con el ejemplar. El
almacenamiento deberá ser lo más flexible posible en cuanto a la relación entre los
datos para ofrecer más posibilidades de análisis. La comunicación, por último, como
se indicó anteriormente, está sujeta a unas normas que debe cumplir.

Puede consultar la lista definitiva de objetivos y su especificación en el modelo de

negocio y el catálogo de objetivos.

PSI 2.2: Organización del PSI

En esta tarea se tratan cuestiones relacionadas con la organización del trabajo para
llevar a cabo el Plan de Sistemas de Información. Se seleccionan los participantes,
valorando el número y perfil de profesionales de Sistemas y Tecnologías de la
Información y Comunicaciones (STIC) necesarios en función de los objetivos
perseguidos.
Asimismo, se determinan las funciones de los responsables de la dirección y
seguimiento del Plan de Sistemas de Información. Adicionalmente, se concretan
aspectos logísticos relacionados con el material, salas de reuniones, estándares de
documentación, etc.

En el PSI participarán los equipos, con sus respectivos responsables, de Investigación y

de Desarrollo de ISW2003.

Se llevara a cabo el trabajo en las instalaciones de ISW2003 tanto de investigación y

desarrollo de la aplicación, en el laboratorio, como las sesiones de trabajo, en la sala de
reuniones. Para mostrar el prototipo exploratorio se empleará un proyector en la sala de
reuniones con el fin de mostrar a los representantes de SILVEMA el aspecto externo y
la funcionalidad del prototipo.

Puede consultar la lista definitiva tanto de participantes como de estándares y normas de

documentación en los catálogos generales creados a tal efecto.
PSI 2.3: Definición del Plan de Trabajo

Se realiza una primera versión del plan de acción del proyecto completo. La precisión
será alta en cuanto a la planificación correspondiente a la fase de inicio, y mucho
menor en lo referente a las fases posteriores. En la fase de elaboración se reelaborará
el plan de forma más rigurosa puesto que de dicha planificación dependerá la
viabilidad del proyecto.

Como respuesta a la solicitud formal realizada por SILVEMA, documento SF1, y

atendiendo a descripciones generales, de objetivos, de procesos y de usuarios, así como
a la formación del equipo de trabajo, se define el plan de trabajo cronológicamente:

1. Análisis de fuentes externas. Tras un periodo concedido a cada miembro de Grupo

ISW2003 para recabar información, la puesta en común se realiza en una sesión de
trabajo el 25 de Abril del 2003. El objetivo es obtener una cierta preparación previa
a la primera toma de contacto con SILVEMA. Documento de referencia MA-1.

2. Primera toma de contacto. Entrevista encuadrada en el análisis de fuentes internas.

El objetivo es obtener una visión general del proceso de anillamiento, objeto del
Sistema de Información, y de la propia organización. La fecha de realización es el
28 de Abril del 2003, documento de referencia EAS-1.

3. Envío de documentación por parte de SILVEMA. Acordado en la entrevista

recogida en el EAS-1, es necesario para el estudio de información relevante,
validación de información ya recogida en el análisis de fuentes externas, estudio de
la situación actual e identificación de requisitos. Por tanto su envío, previsto para la
semana entre el 19 y el 23 de Mayo del 2003, es un punto crítico para el comienzo
de la fase de inicio.

4. Conclusión de la primera actividad del Plan de Sistemas de Información, encuadrada

en una fase preliminar, 7 de Noviembre del 2003.

5. Planificación de la fase de inicio, 7 de Noviembre del 2003.

6. Realización del modelo de negocio con el fin de entender el ámbito del Sistema de
Información, concluir antes del 19 de Noviembre del 2003.

7. Comienza la fase de inicio. Ajuste de la metodología al proyecto y selección de

herramientas que se emplearán a lo largo del proyecto. Planificación de la primera
iteración, Miércoles 19 de Noviembre del 2003.

8. Llevar a cabo las actividades propias de la fase de inicio pertenecientes a la captura

de requisitos, 25 de Noviembre del 2003.

9. Tareas de análisis correspondientes a la arquitectura candidata, 2 de Diciembre del

2003.

10. Diseño en función del análisis realizado anteriormente 3 de Diciembre del 2003.
11. Análisis inicial del negocio. Estimaciones de costes y beneficios con un margen de
error muy amplio, 4 de Diciembre del 2003.

12. Fin de la fase de inicio. Evaluación de la(s) iteración(es) llevadas a cabo, y

valoración de si es posible desarrollar el Sistema de Información, 4 de Diciembre
del 2003.

13. Planificación de la fase de elaboración, 8 de Enero del 2004.

14. Comienzo de la fase de elaboración. Ajuste del equipo de trabajo y del entorno de
desarrollo a la nueva fase. Planificación de la primera iteración, 8 de Enero del
2004.

15. Llevar a cabo las tareas propias de la recopilación de requisitos de esta fase,
identificación y definición rigurosa de la línea base de la arquitectura, 13 de Enero
del 2004.

16. Llevar a cabo las tareas propias del análisis de esta fase, análisis riguroso de los
casos de uso arquitectónicamente significativos y de aquéllos cuya comprensión sea
necesaria para llevar a cabo una apuesta económica fiable, 26 de Febrero del 2004.

17. Llevar a cabo las tareas propias del diseño de esta fase, identificación de la
arquitectura en capas y diseño de la arquitectura, 16 de Marzo del 2004.

18. Implementación del diseño realizado anteriormente. Se llega hasta un línea base de
la arquitectura ejecutable, 30 de Marzo del 2004.

19. Prueba rigurosa de la arquitectura; planificación, diseño, realización y aprobación, 1

de Abril del 2004.

20. Análisis final del negocio. En base a este análisis se firmará el contrato entre
SILVEMA y Grupo ISW2003. Por tanto se prepara una apuesta económica fiable
para lo cual será necesario, además de llevar a cabo correctamente las tareas
anteriores, tener identificados tanto los riesgos críticos, aquellos que comprometen
la viabilidad del proyecto, como su tratamiento. También debe actualizarse la
recuperación de la inversión aunque el margen de error en este apartado puede ser
bastante grande, 15 de Abril del 2004.

21. Fin de la fase de elaboración. Evaluación de la(s) iteración(es) llevadas a cabo, y

valoración de la viabilidad del proyecto en función del análisis del negocio, 15 de
Abril del 2004.

22. Planificación de la fase de construcción, 16 de Abril del 2004.

23. Comienzo de la fase de construcción. Asignación de personal y recursos para esta

fase. Establecimiento de criterios de evaluación. Planificación de la primera
iteración, 20 de Abril del 2004.

24. Culminación de las tareas de identificación de requisitos y se cierran los modelos de

análisis, diseño e implementación, 7 de Mayo del 2004.
25. Prueba rigurosa de cada componente, pruebas de integración de cada subsistema y
del sistema completo. Seguimiento de riesgos críticos. Actualizar lista de riesgos, 12
de Mayo del 2004.

26. Evaluación de pruebas, 13 de Mayo del 2004.

27. Revisión y actualización, si procede, del análisis del negocio, 17 de Mayo del
2004.

28. Fin de fase de la construcción. Evaluación de la(s) iteración(es) llevadas a cabo,

valoración de la capacidad operativa inicial del sistema, 18 de Mayo del 2004.

29. Planificación, en la medida de lo posible, de la fase de transición, 19 de Mayo del

2004.

30. Comienzo de la fase de transición. Preparación del entorno para las pruebas beta,
selección de los usuarios beta, y preparación de artefactos adicionales como
programas de instalación, de conversión o de migración de datos. Instalación de la
versión beta en los lugares escogidos. Determinar criterios de aceptación del
proyecto, 24 de Mayo del 2004.

31. Prueba del sistema. Corrección de errores y fallos en la medida de lo posible, 2 de

Junio del 2004.

32. Adaptación del sistema al entorno de usuario, y de la documentación a los futuros

usuarios, 4 de Junio del 2004.

33. Evaluación del criterio de aceptación, 7 de Junio del 2004.

34. Acordar responsable del mantenimiento, 7 de Junio del 2004.

35. Juzgar el acierto del análisis del negocio y estimar el éxito económico del proyecto
con mayor fiabilidad, 14 de Junio del 2004.

36. Fin de la fase de transición. Evaluación de la(s) iteración(es) llevadas a cabo, 15 de

Junio del 2004.

37. Evaluación del proceso de desarrollo en su totalidad. Hallazgos y examen del

proyecto, 18 de Junio del 2004.

38. Planificación a altísimo nivel del siguiente ciclo de desarrollo del sistema, 18 de
Junio del 2003.

39. Aceptación del sistema, 21 de Junio del 2004.

40. Si el mantenimiento es responsabilidad del Grupo ISW2003, planificación inicial

del mismo, 22 de Junio del 2004.
Puede consultar la planificación cerrada del proyecto en el apéndice correspondiente.
PSI 3.1: Selección y Análisis de Antecedentes

Se seleccionan las fuentes de información y documentación a considerar en este

estudio, teniendo en cuenta todos aquellos antecedentes de interés: plan estratégico de
sistemas de información, estudios previos, plan general informático, etc. y se analiza el
contenido de la información anterior. En el inicio y organización del Plan de Sistemas
de Información se habrá orientado sobre la existencia de estos antecedentes, para
facilitar al equipo de trabajo el desarrollo de esta actividad.
Asimismo, se debe entrevistar a las personas de la organización que puedan aportar
información adicional sobre antecedentes que deban ser considerados en el Plan de
Sistemas de Información, al margen de la documentación disponible. La información
recogida se tiene también en cuenta en la valoración de los mismos.

El anillamiento de aves en España es una actividad muy abierta en cuanto a que no está
sometida a una normativa excesivamente estricta, ya que dicha normativa, la oficial,
sólo se ocupa de la estandarización de los valores que se pueden asignar a cada dato
obtenido del ave capturada, y de la recepción de un conjunto de datos relevantes que se
consideran oficiales. Esta recepción es consecuencia del envío, por parte de los grupos
de anillamiento, de una serie de impresos creados a tal efecto, sin ocuparse la
normativa, del posterior tratamiento que estos datos reciban por parte de los diferentes
grupos de anillamiento. Como muestra del carácter abierto de la normativa que regula el
anillamiento de aves en España, puede reseñarse la existencia de un procedimiento
oficial, el control o captura de un ave ya anillada, que no está sometido a ningún tipo de
normativa en cuanto a su comunicación ni en cuanto a los datos que debe contener,
aunque sí en cuanto a los valores que pueden tomar estos datos.

Las fases propias del anillamiento de aves son las siguientes:

El primer paso es la toma de datos, realizada por los miembros de un determinado grupo
de anillamiento en el campo, consiste en la captura de un ejemplar del que se extraen
unos determinados datos catalogados como obligatorios, así como aquellos datos que
respondan a las necesidades del usuario. Dichos datos se transcriben a la hoja de campo
manualmente. Una vez obtenidos los datos se almacenan en una Base de Datos, previa
transcripción de la hoja de campo al ordenador. Las relaciones entre los datos
almacenados, necesarias para realizar análisis, debe establecerlas el propio usuario.
Finalmente, se deben comunicar aquellos datos determinados como oficiales a las
entidades de las que dependa el grupo de anillamiento, la Oficina de Anillamiento y la
Entidad Avaladora, transcribiendo los datos bien de las hojas de campo, bien de la Base
de Datos, a los impresos oficiales: la Hoja de Anillamiento, la Hoja de Balance Anual y
la Ficha de Recuperación. Además, también se debe comunicar la información referente
a cada control, captura de un ave ya anillada. Pese a ser información oficial esta
comunicación no está sujeta a ningún impreso o formato oficial.

Como se indicó anteriormente, tanto los datos como los impresos están sujetos a unas
determinadas normas y estándares. Si bien la hoja de campo y la información
perteneciente a un control no se deben ajustar a ningún formato determinado, los valores
de los datos que contengan deben ajustarse a los estándares antes referidos.
PSI 3.2: Valoración de Antecedentes

Se realiza la valoración de los antecedentes analizados en la tarea anterior y las

conclusiones se recogerán en el catálogo de requisitos. La realización de esta
valoración ayudará a establecer términos de referencia en cuanto a estándares,
procedimientos, normativas, etc., si es que existen.

El análisis de los antecedentes revela que cada operación a realizar con los datos
conlleva una trascripción, que, además de limitar la velocidad y comodidad del Sistema
de Información, comporta el riesgo de anular el trabajo realizado anteriormente en caso
de error en la trascripción de algún dato, afectando gravemente a la integridad del
Sistema de Información.

Si bien la toma de datos puede constituir una importante fuente de errores al apuntar
medidas con valores no definidos, se debe recordar que los datos están sujetos a
estándares, y dichos errores se arrastrarían durante todo el proceso, la mayor limitación
del Sistema de Información se encuentra en el proceso de almacenamiento y tratamiento
de los datos. Las relaciones entre los datos debe establecerlas el propio usuario. Este
aspecto se revela como un punto crítico del Sistema de Información, así, en el nuevo
Sistema de Información, se deben proporcionar las relaciones necesarias entre los datos
que permitan al usuario realizar los análisis que estime oportunos.

Puede consultar la lista definitiva de objetivos y su especificación en el modelo de

negocio y el catálogo de objetivos.
Puede consultar la lista definitiva de estándares y normas de documentación en el
catálogo general creado a tal efecto.

EVS 3.1: Identificación de las Directrices Técnicas y de Gestión

La realización de esta tarea permite considerar los términos de referencia para el

sistema en estudio desde el punto de vista de directrices tanto técnicas como de gestión.
Si el sistema en estudio pertenece al ámbito de un Plan de Sistemas de Información
vigente, éste proporciona un marco de referencia a considerar en esta tarea.
Con este fin, se recoge información sobre los estándares y procedimientos que deben
considerarse al proponer una solución, relativos a:

- Políticas técnicas:
o Gestión de Proyectos (seguimiento, revisión y aprobación final).
o Desarrollo de Sistemas (existencia de normativas, metodologías y técnicas de
programación).
o Arquitectura de Sistemas (centralizada, distribuida).
- Política de Seguridad (control de accesos, integridad de datos, disponibilidad de
aplicaciones).
- Directrices de Planificación.
- Directrices de Gestión de Cambios.
- Directrices de Gestión de Calidad.
Será necesario incorporar nuevas normas y estándares, y, por tanto, completar esta
tarea cuando se introduzcan las interfaces de calidad, seguridad, gestión de proyectos y
gestión de la configuración en la fase de elaboración. En cualquier caso el catálogo de
normas se mantendrá abierto a lo largo de todo el proyecto.

Puede consultar la lista definitiva de estándares y normas de documentación en el

catálogo general creado a tal efecto.

PSI 4.1: Estudio de los Procesos del PSI

Se estudia cada proceso de la organización incluido en el ámbito del Plan de Sistemas

de Información. Para cada uno de ellos, es necesario identificar las actividades o
funciones, la información implicada en ellas y las unidades organizativas que
participan en el desarrollo de cada actividad.
Para obtener esta información es necesario llevar a cabo sesiones de trabajo con los
usuarios implicados en cada uno de los procesos a analizar. Una vez contrastadas las
conclusiones, se elabora el modelo correspondiente a cada proceso. Si existe relación
entre los distintos modelos, se unifican en la medida de lo posible, con el fin de
proporcionar una visión global en el contexto de la organización y facilitar una
identificación de requisitos más objetiva.

Como se ha comentado suficientemente a lo largo del presente Plan de Sistemas de

Información, el anillamiento de aves se divide en tres procesos:

- El primero es la toma de datos, este proceso es fundamental puesto que las

siguientes fases del anillamiento se basarán, única y exclusivamente, en la
información obtenida en este proceso. Dentro de la toma de datos se pueden
distinguir distintas modalidades que pueden ser empleadas individualmente o en
combinación de varias durante una misma sesión: el anillamiento oficial (captura de
un ave sin anillar), el control (captura de un ave ya anillada), la recuperación de una
anilla (retirada de la anilla oficial del ave por diversos motivos), el anillamiento
PVC (anillamiento de un ave para control interno de SILVEMA), y el control de
colonias, consideración de aves en grupo y no individualmente. Todos los datos
están sometidos a una estandarización a la que se deben ajustar los valores
asignados.

- Una vez obtenidos todos los datos se procede a su almacenamiento en una Base de
Datos común, además se establecerán relaciones entre los distintos datos para
permitir la realización de análisis por parte de los usuarios.

- El último proceso es de la comunicación de los datos. Puede ser oficial, con la

Oficina de Anillamiento o con la Entidad Avaladora, o no oficial, entre los distintos
grupos de anillamiento. La comunicación oficial está sujeta a una normativa.

Puede consultar la especificación definitiva de los procesos en el modelo de procesos.

PSI 4.2: Análisis de las Necesidades de Información

Mediante sesiones de trabajo, se identifican las necesidades de información de cada

uno de los procesos analizados en la actividad anterior. Se elabora un modelo de
información que refleje las principales entidades y relaciones existentes entre ellas.
Todo esto se realiza con la perspectiva de lo que debe ser el proceso en cuanto a sus
actividades y funciones, así como a la información de entrada y salida para cada una
de ellas.
Los resultados del análisis realizado en esta tarea son la base para la identificación de
requisitos.

El diagrama de clases se realizó siguiendo el método recomendado por UML en lugar

de aplicar Entidad/Relación extendido, puesto que se parte de una definición del sistema
a muy alto nivel en la que no se valoran, porque no interesa y restaría claridad a la
definición, atributos u operaciones. Documento de referencia Modelo de Clases.

Colonia

1
Pertenece
Estadística
1..*

Nido
1..*

Se obtiene
1..*
Habita en

1..* 1..*

Ave 1..* Tomar Datos de 1..* Captura Realiza Anillador

1..* 1..*

1..*
Rellena

1..*

«hereda» Impreso Oficial «hereda»

«hereda»
«hereda»

Hoja de Balance Anual Hoja de Anillamiento Ficha de recuperación Control

Puede consultar la especificación definitiva de clases en el modelo de clases.

PSI 4.3: Catalogación de Requisitos

En esta tarea se analiza la información recogida en las tareas Estudio de los Procesos
del PSI (PSI 4.1) y Análisis de las Necesidades de Información (PSI 4.2). Se definen los
requisitos, incorporándolos al catálogo que se había comenzado a elaborar en la
actividad Estudio de la Información Relevante (PSI 3) y se les asignan prioridades. Los
criterios para asignar dichas prioridades deben ser definidos al comienzo de esta tarea,
considerando la opinión de los usuarios sobre los procesos de la organización, así
como los objetivos del Plan de Sistemas de Información.

Puede consultar la lista definitiva de requisitos en el catálogo creado a tal efecto.

PSI 5.1: Alcance y Objetivo del Estudio de los Sistemas de Información Actuales

A partir de la descripción general de los procesos de la organización afectados por el

Plan de Sistemas de Información se determina qué sistemas de información actuales se
encuentran dentro del ámbito del Plan de Sistemas de Información. Se seleccionan, de
los sistemas existentes, los que deben ser analizados, así como los objetivos del estudio
de cada uno. De esta forma, se establece el dominio de sistemas de información de la
organización a considerar. También se tienen en cuenta los objetivos definidos para el
Plan de Sistemas de Información, en función de los cuales se establece la amplitud y
profundidad con la que se deberá desarrollar esta actividad.
Los objetivos del Plan de Sistemas de Información se completan con los objetivos
definidos en esta tarea para el estudio de los sistemas de información actuales.
La información relativa a los sistemas de información que dan actualmente soporte a
los procesos afectados por el Plan de Sistemas de Información, se obtiene mediante
sesiones de trabajo con los usuarios y el apoyo del personal informático que se
considere necesario.

En la actualidad, la información tratada por SILVEMA no está informatizada. La

secuencia de procedimientos que realizan es la misma que la que se pretende desarrollar
en nuestro sistema.

Adaptaremos su sistema de información a un nivel tecnológico muy superior tomándolo

como modelo, con las ventajas que ello les aportará. Hasta el momento, SILVEMA
realizaba la captura de datos, almacenamiento, estudio y su distribución de una forma
totalmente manual. El nuevo sistema le aportará la informatización de una parte
(captura de datos) y la automatización de las restantes (almacenamiento, estudio y
distribución de la información).
PSI 5.2: Análisis de los Sistemas de Información Actuales

En esta tarea se lleva a cabo el estudio de los sistemas de información actuales

afectados por el PSI. Para cada sistema de información se recogen, al menos, las
características básicas relativas a datos, software de aplicación, procesos de la
organización a los que da soporte y de qué forma lo hace, flexibilidad, carencias,
riesgos y posibles amenazas

En función del tipo de sistema de información y de los objetivos de su estudio se

recopila además, para cada uno de ellos, información procedente de diversos puntos de
vista (la opinión de usuarios de los sistemas de información, de analistas de desarrollo,
de personal de operación, etc.).

Para realizar un análisis más completo de los sistemas de información actuales,

enviamos a uno de los componentes del equipo de investigación, Juan López, a una
jornada de campo con los miembros de SILVEMA.

La finalidad de este proceso es obtener la mayor información posible sobre como

desarrollan su labor los miembros de SILVEMA, además de para conocer mejor el
proceso de de anillamiento, para evitar posible detalles que saltasen fuera del modelo de
negocio.

Cuando el anillador realiza su trabajo de campo va equipado con numeroso material, en

forma de fichas de papel. Ya sea captura o recuperación la información que va
obteniendo durante la jornada de trabajo es pasada a las fichas.

Posteriormente esta información es pasada a limpio a otras fichas oficiales para su

almacenamiento permanente y hojas de cálculo (que solamente tienen vigencia anual).

La información almacenada es comunicada a los órganos superiores oficiales

encargados de coordinar las tareas de control ornitológico mediante correo ordinario.

PSI 5.3: Valoración de los Sistemas de Información Actuales

Una vez descritas las características de los sistemas de información actuales, se

analizan los problemas reales y potenciales, opiniones, etc. Se obtienen conclusiones y
una valoración, lo más objetiva posible, de cada uno de ellos. Es importante lograr esta
objetividad, ya que la valoración podrá influir en la decisión de la sustitución o mejora
de los sistemas de información en los próximos años.
Conviene señalar que esta valoración no se realiza en cuanto a cobertura de requisitos,
sino con respecto a aspectos intrínsecos o de eficiencia de cada sistema de información,
relativos a facilidad de mantenimiento, operatividad, nivel de servicio, costes, etc.

El actual sistema es muy ineficiente, ya que, además de tener que ir seleccionando de

entre las muchas fichas de trabajo con las que se encuentra el anillador, se pierde mucho
tiempo en la toma de datos en papel. Además posteriormente este proceso debe
repetirse, ya que debe posteriormente introducir los datos en un ordenador para su
almacenamiento y además se debe buscar uno a uno los datos con los que finalmente
cumplimentar los impresos oficiales.

Hemos comprobado que hay muchos datos en todas las fichas que se repiten
constantemente, como la localización, datos de los anilladotes, etc.., por lo que se
produce otra perdida de tiempo importante.

Además de que este sistema de trabajo apenas es operativo, se convierte en ciertamente

monótono y tedioso para el usuario final, debido al gasto de recursos, sobre todo de
tiempo, que éste debe realizar.

Es por ello que seguiremos el sistema de trabajo en la captura (mejorándolo

sensiblemente) y modificaremos el resto de procesos, que se llevarán a cabo
automáticamente.

PSI 6.1: Diagnóstico de la Situación Actual

Para llegar a un diagnóstico sobre la situación actual, se tiene en cuenta la valoración

de los sistemas de información actuales realizada en la actividad Estudio de los
Sistemas de Información Actuales (PSI 5), y se estudia la cobertura de requisitos que se
tiene con ellos. Esto permite determinar los requisitos del catálogo no cubiertos por los
sistemas de información actuales, estudiando su criticidad y prioridad.
En paralelo, se analiza el modelo de información obtenido en la tarea Análisis de las
Necesidades de Información (PSI 4.2). Se determina si existen entidades o relaciones
del mismo, que no aparecen recogidas en la situación actual o que, estando recogidas,
su tratamiento actual no responde a los nuevos requisitos.
Como resultado del análisis anterior, se seleccionan los sistemas de información a
conservar y se elabora, si procede, la relación de mejoras a realizar en cada uno de
ellos para cubrir los requisitos que le afectan.

El actual Sistema de Información cubre todas las fases del anillamiento de aves, captura
de datos, almacenamiento y tratamiento de datos y comunicación de datos, y cumple
todos los requisitos especificados menos uno, el establecimiento de relaciones entre los
distintos datos, pero en distinta medida.

Seguidamente se analizan las mejoras propuestas para cada subsistema encargado de

alguna de las fases del anillamiento de aves, así como el grado de cumplimiento de los
requisitos.

El subsistema encargado de la toma de datos presenta como primer requisito la

definición, a priori, de toda la información necesaria. Este requisito se cumple, además,
las características del Sistema de Información actual, toma de datos manual, ayudan a
subsanar en el mismo momento de la captura posibles omisiones de información
necesaria. Una vez definidos los datos, el siguiente requisito es asignarles valores
válidos, sujetos a unos estándares oficiales. El cumplimiento de este requisito es
responsabilidad del usuario en el Sistema de Información actual. Además, la captura de
datos, al realizarse en el campo y con el ave capturada, debe ser cómoda, para beneficio
del anillador, y rápida, para beneficio del ave. El grado de cumplimiento de este
requisito sería claramente aumentado introduciendo un dispositivo de captura de datos
automático en el Sistema de Información. Este dispositivo, además de hacer más rápida
la toma de datos la haría más fiable al permitir que el Sistema de Información
contemplara únicamente los valores válidos, disminuyendo la responsabilidad del
usuario. Ésta responsabilidad aumentaría, sin embargo, en la definición inicial de la
información a recabar en la toma de datos. Por último, este dispositivo permitiría una
comunicación con el subsistema encargado del almacenamiento y tratamiento de los
datos, volcado de datos, automática y, por tanto, más fiable.

El subsistema encargado del almacenamiento y tratamiento de los datos lleva asociado

el único requisito no contemplado en el Sistema de Información actual, el
establecimiento de relaciones entre los datos. Por tanto, se propone como mejora definir
una nueva estructura de almacenamiento de datos que permita establecer dichas
relaciones. Además el Sistema de Información actual cumple con el requisito de
almacenar los datos, pero de forma un tanto cuestionable, los datos sólo son
almacenados durante un determinado periodo de tiempo, transcurrido el cual, los datos
se imprimen, se archivan y se borran de la estructura de almacenamiento. Si bien al ser
impreso en papel queda constancia de ellos, el establecimiento de relaciones entre datos
de distintos periodos se hace casi impracticable. Se propone como mejora el
almacenamiento indefinido de los datos. Estas dos mejoras proporcionarán al usuario
las herramientas necesarias para realizar análisis con los datos, tarea ajena al Sistema de
Información actual.

El otro subsistema, el encargado de la comunicación de datos, se mantendrá en cuanto a

su ejecución, pero se propone como mejora para el rellenado de impresos el volcado
automático de datos desde la estructura de almacenamiento.

EVS 1.3: Especificación del Alcance del EVS

Se determinan las actividades y tareas a realizar, así como los participantes y su

responsabilidades en el trabajo del EVS que se lleve a cabo en esta fase.

Puede consultar la planificación cerrada del proyecto en el apéndice correspondiente.

EVS 2.1: Valoración del Estudio de la Situación Actual

En función de los objetivos establecidos para el estudio de la situación actual, y

considerando el contexto del sistema especificado en la descripción general del mismo,
se identifican los sistemas de información existentes que es necesario analizar con el fin
de determinar el alcance del sistema actual. Asimismo, se decide el nivel de detalle con
el que se va a llevar a cabo el estudio de cada uno de los sistemas de información
implicados. En el caso de haber realizado un Plan de Sistemas de Información que
afecte a dicho sistema, se toma como punto de partida para este análisis la arquitectura
de información propuesta.
Para poder abordar el estudio, se realiza previamente una valoración de la
información existente acerca de los sistemas de información afectados por el EVS. Se
debe decidir si se realizan o no los modelos lógicos del sistema actual o si se describe
el modelo físico, en función de los siguientes criterios:

- Si existen los modelos lógicos, y son fiables, se utilizan en la tarea Descripción de

los Sistemas de Información Existentes (EVS 2.3)

- Si no existen dichos modelos, o no son fiables, se considera el tiempo de vida

estimado para el sistema de información en función de la antigüedad, la
obsolescencia de la tecnología o la falta de adecuación funcional para determinar
sí se obtienen los modelos lógicos y físicos del sistema actual o por el contrario no
se elabora ningún modelo.

La información relativa a los sistemas de información que se decida analizar, se

obtiene mediante sesiones de trabajo con los Directores de Usuarios y el apoyo de los
profesionales de Sistemas y Tecnologías de la Información y Comunicaciones (STIC)
que se considere necesario.

El análisis del sistema actual se considera completado en el Plan de Sistemas de

Información.

EVS 2.2: Identificación de los Usuarios Participantes en el Estudio de la

Situación Actual

En función del nivel de detalle establecido para el estudio de la situación actual, se

identifican los usuarios participantes de cada una de las unidades organizativas
afectadas por dicho estudio. Se informa a los usuarios identificados como implicados
en el Estudio de la Situación Actual, se solicita su aceptación y se espera su
confirmación.

Puede consultar la lista definitiva de participantes en lo catálogo general creado a tal

efecto.
EVS 2.3: Descripción de los Sistemas de Información Existentes

En esta tarea se describen los sistemas de información existentes afectados, según el

alcance y nivel de detalle establecido en la tarea Valoración del Estudio de la Situación
Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este
estudio.
Si se ha decidido describir los sistemas a nivel lógico, y si existe un conocimiento
suficiente de los sistemas de información a especificar, puede hacerse directamente,
aplicando las técnicas de modelización y siguiendo un método descendente. Si no se
dispone del conocimiento suficiente, se construyen los modelos a partir de la
descripción del modelo físico, es decir, de forma ascendente.
Si se tiene que describir el modelo físico, se puede hacer mediante un Diagrama de
Representación en el que se recojan todos los componentes físicos y sus referencias
cruzadas. Otra opción es describir el modelo físico de forma más detallada, para lo que
es necesaria la utilización de herramientas de tipo scanner.
Es conveniente indicar la localización geográfica y física actual de los módulos y datos
de los sistemas de información afectados, evaluando al mismo tiempo la redundancia
en las distintas unidades organizativas.

Tras realizar el estudio de la situación actual en los puntos 5 y 6 del PSI, al no disponer
de una arquitectura de información informatizada, no procede a su tratamiento en este
punto.

EVS 2.4: Realización del Diagnóstico de la Situación Actual

Con el fin de elaborar el diagnóstico de la situación actual se analiza la información de

los sistemas de información existentes, obtenida en la tarea anterior y se identifican
problemas, deficiencias y mejoras. Estas últimas deben tenerse en cuenta en la
definición de los requisitos.

Al no haberse realizado ningún estudio en el punto anterior, no procede a su valoración.

EVS 3.2: Identificación de Requisitos

Para la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe

decidir qué tipo de sesiones de trabajo se realizarán y con qué frecuencia tendrán
lugar, en función de la disponibilidad de los usuarios participantes.
Si se ha realizado el Estudio de la Situación Actual (EVS 2), puede ser conveniente
seleccionar la información de los sistemas de información existentes que resulte de
interés para el desarrollo de dichas sesiones de trabajo.
Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los
usuarios participantes identificados al estudiar el alcance del Estudio de Viabilidad del
Sistema (EVS 1.3), y se realizan de acuerdo al plan previsto. La información obtenida
depende del tipo de sesión de trabajo seleccionado.
Llegados a este punto no han surgido nuevos requisitos puesto que no se realizó estudio
de la situación actual.

EVS 3.3: Catalogación de Requisitos

Se analiza la información obtenida en las sesiones de trabajo para la Identificación de

Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que
debe satisfacer el sistema, indicando sus prioridades.
Se incluirán también requisitos relativos a distribución geográfica y entorno
tecnológico.

No es necesario realizar catalogación puesto que no se identificaron nuevos requisitos

en la tarea anterior.

ASI 1.1: Determinación del Alcance del Sistema

Se indica qué procesos pertenecen al ámbito del Sistema de Información y se identifican

las entidades externas al sistema que aportan o reciben información. Puede ser
conveniente establecer el contexto del sistema a partir del modelo de negocio. El
modelo de negocio especifica los procesos a los que se quiere dar respuesta en el
sistema de información, en forma de casos de uso de alto nivel.
A medida que se van generando los productos anteriores, se recomienda la definición
de un glosario de términos del ámbito de negocio, con el fin de conseguir una mayor
precisión en la especificación del sistema de información. El glosario es un catálogo de
términos general y común a todos los procesos, y susceptible de ser entrada o salida en
cualquier tarea, de modo que por sencillez en las restantes tareas se omite la referencia
al mismo.

Puede consultar tanto el modelo de negocio como el glosario para ver las versiones
definitivas de ambos productos.

ASI 1.2: Identificación del Entorno Tecnológico

Identificación a muy alto nivel del entorno tecnológico necesario, sólo en términos de
viabilidad.

El subsistema toma de datos utilizará un dispositivo automático de captura de datos,

aunque con una plataforma de trabajo aún por seleccionar. Para ella ofrecemos tres
posibilidades:

- Ordenador PC Portátil.
- Tablet PC
- Pocket-PC

Independientemente de la plataforma seleccionada, se implementarán los cuestionarios

necesarios para almacenar la información, organizados de la misma forma que los
procesos a los que representan. Dichos formularios están formados por distintos campos
cada uno de los cuales representa un dato estimado necesario en la definición inicial de
información a recabar. Estos campos tienen como característica la censura de datos no
válidos para aquellos campos sujetos a un estándar. Cabe destacar que si se opta por
tomar datos de los ejemplares agrupados por colonias, los datos de cada ejemplar se
relacionan con los del nido en el que habita, y los datos de cada nido se relacionan con
la colonia a la que pertenece, dicha relación será transparente para el usuario, éste se
limitará a tomar los datos en el orden representado.

El volcado de datos hacia el subsistema de almacenamiento y tratamiento de datos será

automático, dependiendo de la arquitectura tecnológica seleccionada:

- Mediante conexión por red local en los casos de PC Portátil y Tablet PC.
- Mediante conexión con la base de sincronización en los casos de PocketPC.

El subsistema de almacenamiento y tratamiento de datos utilizará una estructura de

almacenamiento de datos, mediante un servidor de Bases de Datos aún por determinar,
donde se almacenarán los datos volcados desde la toma de datos. Estos datos se
almacenarán con una organización previamente definida por SILVEMA, documento
EAS-3. Sobre esta estructura de almacenamiento actuará una aplicación informática
encargada de implementar una serie de análisis estadísticos definidos por SILVEMA y
de la visualización tanto de datos como de los resultados de los análisis. El volcado de
datos hacia el subsistema de comunicación será a nivel lógico pues la misma aplicación
informática lleva a cabo tareas para dicho subsistema. El soporte hardware necesario
para el subsistema de almacenamiento y tratamiento de datos consta de un PC que
albergue la estructura de almacenamiento y la aplicación informática y una impresora
para la visualización de datos.

El subsistema de comunicación consta del mismo soporte hardware que el de

almacenamiento y tratamiento de datos. Este subsistema consta de una aplicación
informática, en realidad una función de la aplicación antes mencionada, que rellena los
impresos oficiales y los controles, impresos en papel o en archivo, en base a la
información almacenada en la estructura de almacenamiento.

ASI 1.4: Identificación de Usuarios y Participantes Finales

Identificación de algunos participantes en el plan de acción en base al esbozo realizado

en esta fase.

Puede consultar la lista definitiva de participantes en lo catálogo general creado a tal

efecto.
ASI 2.1: Obtención de Requisitos

Identificación de los requisitos funcionales derivados del modelo de negocio, así como
otros tipos de requisitos (rendimiento, seguridad, implantación, disponibilidad del
sistema) referentes a la arquitectura candidata en caso de desarrollarse un prototipo
exploratorio en esta fase.

Puede consultar tanto el modelo de negocio como el catálogo de requisitos para ver las
versiones definitivas de ambos productos.

ASI 2.2: Especificación de Casos de Uso

El objetivo de esta tarea es especificar cada caso de uso identificado en la tarea

anterior, desarrollando el escenario.

Para completar los casos de uso, es preciso especificar información relativa a:

- Descripción del escenario, es decir, cómo un actor interactúa con el sistema, y cual
es la respuesta obtenida.
- Precondiciones y poscondiciones.
- Identificación de interfaces de usuario.
- Condiciones de fallo que afectan al escenario, así como la respuesta del sistema
(escenarios secundarios).

En escenarios complejos, es posible utilizar como técnica de especificación los

diagramas de transición de estados, así como la división en casos de uso más simples,
actualizando el modelo de casos de uso.

Para la obtención de esta información es imprescindible la participación activa de los

usuarios.

Puede consultar el modelo de casos de uso para ver la versión definitiva.

ASI 2.3: Análisis de Requisitos

En esta tarea se estudia la información capturada previamente en esta actividad, para

detectar inconsistencias, ambigüedades, duplicidad o escasez de información, etc.
También se analizan las prioridades establecidas por el usuario y se asocian los
requisitos relacionados entre sí.
El análisis de los requisitos y de los casos de uso asociados permite identificar
funcionalidades o comportamientos comunes, reestructurando la información de los
casos de uso a través de las generalizaciones y relaciones entre ellos.
Mediante sesiones de trabajo con los usuarios, se contrastan las conclusiones del
análisis de la información recogida.
Con el fin de completar los requisitos tenidos en cuenta en los casos de uso
especificados se comentan los procesos internos del Sistema de Información en los que
no interviene usuario alguno.

Como se ha comentado durante el desarrollo de este proyecto es necesario que la

definición previa de la información a recabar, abarque todos los datos necesarios para el
rellenado de impresos oficiales y para la realización de los análisis definidos por
SILVEMA, ya que la toma de datos será la única vía de entrada de datos al Sistema de
Información, la entrada manual de datos relativos a controles y anillamientos consta de
datos ya incluidos en la definición oficial.

Debe haber una correspondencia total entre los subsistemas de toma de datos y de
almacenamiento y tratamiento de datos, tanto en la organización de los datos que se
vuelcan desde el primer subsistema hacia el segundo como en las relaciones que se
establecen entre los datos en el caso de tratar los ejemplares agrupados por colonias.

El subsistema de almacenamiento y tratamiento de datos tendrá implementados,

previamente, los análisis determinados por SILVEMA.

Las prioridades de los casos de uso viene determinada por la de los requisitos cuyo
cumplimiento representar, requisitos funcionales, además los requisitos relacionados
entre sí ya están asociados puesto que parten del modelo de negocio que obtiene dichos
requisitos a partir de los objetivos establecidos. Los objetivos están relacionados en una
estructura jerárquica puesto que en primer lugar se identificaron los objetivos generales
y posteriormente los específicos propios de cada objetivo general, por tanto, las
prioridades y las asociaciones de requisitos (y sus casos de uso) vienen determinadas
por la definición inicial de objetivos en el modelo de negocio.

ASI 2.4: Validación de Requisitos

Mediante esta tarea, los usuarios confirman que los requisitos especificados en el
catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos.

Puede consultar el documento de aceptación en el anexo de documentos.

ASI 3.1: Determinación de Subsistemas de Análisis

Se identifican y definen las dependencias entre subsistemas analizando los elementos

compartidos entre ellos o las interfaces entre subsistemas. En el caso de que se decida
abstraer un subsistema para su análisis como una unidad con una funcionalidad
concreta, se puede, opcionalmente, definir la interfaz de dicho subsistema para poder
delimitar su comportamiento y utilización en el modelo general del sistema. Por tanto,
se establece como obligatoria la asociación entre subsistemas indicando sólo la
dependencia.

Como se ha establecido desde un primer momento el Sistema de Información objeto de

este análisis se divide en tres subsistemas cada uno de ellos encargado de una de las
fases del proceso de anillamiento de aves, así se tienen los siguientes subsistemas;
subsistema de toma de datos, subsistema de almacenamiento y tratamiento de datos y
subsistema de comunicación.

Si bien el subsistema de almacenamiento y tratamiento de datos depende principalmente

de la información procedente del subsistema de toma de datos, pues la información
procedente de la entrada de datos manual es poco significativa, ambos subsistemas
dependen de la definición inicial de la información a recabar. La comunicación entre
ambos subsistemas se realiza en un único sentido, desde el subsistema de toma de datos
hacia el de almacenamiento y tratamiento de datos. Dicha comunicación se lleva a cabo
mediante una interfaz externa al Sistema de Información pues el volcado de datos se
basa en la conexión física, mediante la cual el Pocket-PC deposita de forma automática
la información recabada en la estructura de almacenamiento, una Base de Datos.

El subsistema de comunicación depende totalmente del subsistema de almacenamiento

y tratamiento de datos, pues este posee la información que va a tratar el subsistema de
comunicación. La comunicación es en un sentido desde el subsistema de
almacenamiento y tratamiento de datos hacia el de comunicación, opcionalmente se
podría considerar que la entrada de datos manual al subsistema de almacenamiento
forma parte del subsistema de comunicación en cuyo caso la comunicación sería en los
dos sentidos. La comunicación entre el subsistema de almacenamiento y tratamiento de
datos y el de comunicación es responsabilidad del Sistema de Información y se basa en
el rellenado de datos de impresos oficiales, y de impresos definidos por SILVEMA para
los controles. La aplicación informática que trabaja sobre el subsistema de
almacenamiento y tratamiento de datos implementará una función para cada caso.

Volcado Automático Rellenado de Impreso

Subsistema de
Subsistema de Toma de Subsistema de
Almacenamiento y
Datos Comunicación
Tratamiento

ASI 3.2:Integración de Subsistemas de Análisis

El objetivo de esta tarea es la coordinación en la elaboración de los distintos modelos

de análisis de cada subsistema, asegurando la ausencia de duplicidad de elementos y la
precisión en la utilización de los términos del glosario. Esta tarea se realiza en paralelo
con el resto de las actividades de elaboración de modelos del análisis, y permite tener
una visión global y unificada de los distintos modelos. En esta fase se realizará a muy
alto nivel, en posteriores fases se profundizará más.

Si bien la relación entre los subsistemas de toma de datos y de almacenamiento y

tratamiento de datos está perfectamente definida, en la relación entre el subsistema de
almacenamiento y tratamiento de datos y el subsistema de comunicación hay un proceso
cuya pertenencia a un subsistema u otro no está clara, es el proceso de introducción
manual de datos relativos a controles de aves anilladas por SILVEMA o a anillamientos
de aves controladas por SILVEMA, esta información es enviada por entidades
oficiales.
Finalmente se decide integrar el proceso de introducción manual de datos en el
subsistema de comunicación, con lo que la comunicación y dependencia entre ambos
subsistemas queda de la siguiente forma:

Subsistema de Tratamiento
y Almacenamiento
de Datos

Introducción Manual de Datos

Rellenado de impresos oficiales

Subsistema de
Comunicación
ASI 1.3: Especificación de Estándares y Normas

La realización de esta tarea permite considerar las referencias para el sistema de

información en estudio, desde el punto de vista de estándares, normativas, leyes o
recomendaciones, que deben tenerse en cuenta a lo largo de todo el proceso de
desarrollo.
El producto resultante se obtiene actualizando el catálogo de normas elaborado en el
proceso Estudio de Viabilidad del Sistema (EVS), incorporando toda la información
que, desde el punto de vista de la instalación, se considere necesario contemplar para
la elaboración de los distintos productos del ciclo de vida.

Puede consultar la versión definitiva del catálogo de normas.

ASI 8.1-8.3-8.4: Definición de Interfaz de Usuario

Definición de los principios que vayan a ser necesarios para esta fase. Definición de
alguna pantalla que sea necesaria para la comprensión de alguno de los casos de uso
seleccionados. Especificación del comportamiento del algunas interfaces necesaria
para la comprensión.

No procede, ya que aún se desconoce la plataforma final en la que se va a desarrollar el

proyecto, y no se ha identificado ningún caso especial que precise de una interfaz de
usuario especial por el momento.

ASI 8.5: Definición de los Formatos de Impresión

El objetivo de esta tarea es especificar los formatos y características de las salidas o

entradas impresas del sistema.

Se ofrecen dos soluciones para el problema de la impresión, que son las

siguientes:

- Imprimir directamente sobre el formulario oficial

- El sistema debe crear el formulario completo.

ASI 9.1..9.3: Análisis de Consistencia y Especificación de Requisitos

El objetivo de esta actividad es garantizar la calidad de los distintos modelos

generados en el proceso de Análisis del Sistema de Información, y asegurar que los
usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dicho
objetivo, se llevan a cabo las siguientes acciones:

- Verificación de la calidad técnica de cada modelo.

- Aseguramiento de la coherencia entre los distintos modelos.
- Validación del cumplimiento de los requisitos.

Esta actividad requiere una herramienta de apoyo para realizar el análisis de

consistencia.

No es necesario llevarlo a cabo en esta fase puesto que no se aplica la interfaz de

calidad, la validez de los distintos modelos se basa en el seguimiento de la metodología,
dicho seguimiento es fácilmente constatable puesto que se explica la metodología según
se van cumplimentando los modelos.

ASI 10.1: Definición del Alcance de las Pruebas

En función de la solución adoptada en el desarrollo de un sistema de información, es

posible que determinados niveles de pruebas sean especialmente críticos y otros no
sean necesarios. Por ejemplo, puede haber grandes diferencias en función de una
solución de desarrollo completo o un producto de mercado cerrado integrado con otros
sistemas.
En esta tarea se especifican y justifican de los niveles de pruebas a realizar, así como el
marco general de planificación de cada nivel de prueba, según el siguiente esquema:

- Definición de los perfiles implicados en los distintos niveles de prueba.

- Planificación temporal.
- Criterios de verificación y aceptación de cada nivel de prueba.
- Definición, generación y mantenimiento de verificaciones y casos de prueba.
- Análisis y evaluación de los resultados de cada nivel de prueba.
- Productos a entregar como resultado de la ejecución de las pruebas.

Se aporta la prueba de caja negra del proyecto 8.06/47.2077 realizado entre la

Universidad de Málaga y la Empresa Malagueña Mixta de Limpieza con resultado
satisfactorio para la prueba de transmisión de datos entre PocketPC y un PC de
sobremesa. En el resto de los casos este proceso no es necesario porque la comunicación
por red local se considera trivial.

ASI 10.2: Definición de Requisitos del Entorno de Pruebas

El objetivo de esta tarea es la definición o recopilación de los requisitos relativos al

entorno de pruebas, completando el plan de pruebas.
La realización de las pruebas aconseja disponer de un entorno de pruebas separado del
entorno de desarrollo y del entorno de operación, garantizando cierta independencia y
estabilidad en los datos y elementos a probar, de modo que los resultados obtenidos
sean objetivamente representativos, punto especialmente crítico en pruebas de
rendimiento.
No es objeto de MÉTRICA Versión 3 en general, ni de esta tarea en particular, la
especificación formal de entornos y procedimientos de pruebas en el ámbito de una
instalación.
Independientemente de la existencia o no de dichos entornos, en esta tarea se inicia la
definición de las especificaciones necesarias para la correcta ejecución de las distintas
pruebas del sistema de información. Entre ellas podemos citar las siguientes:
- Requisitos básicos de hardware y software base: sistemas operativos, gestores de
bases de datos, monitores de teleproceso, etc.
- Requisitos de configuración de entorno: librerías, bases de datos, ficheros,
procesos, comunicaciones, necesidades de almacenamiento, configuración de
accesos, etc.
- Herramientas auxiliares. Por ejemplo, de extracción de juegos de ensayo, análisis
de rendimiento y calidad, etc.
- Procedimientos para la realización de pruebas y migración de elementos entre
entornos.

No procede porque no vamos disponer de un entorno propio de pruebas en esta fase,

sino que nos vamos a basar en otros proyectos realizados por la organización.

ASI 10.3: Definición de Pruebas de Aceptación del Sistema

En esta tarea se realiza la especificación de las pruebas de aceptación del sistema,

labor fundamental para que el usuario valide el sistema, como último paso, previo a la
puesta en explotación.
Se debe insistir, principalmente, en los criterios de aceptación del sistema que sirven de
base para asegurar que satisface los requisitos exigidos.
Los criterios de aceptación deben ser definidos de forma clara, prestando especial
atención a aspectos como:

- Procesos críticos del sistema.

- Rendimiento del sistema.
- Seguridad.
- Disponibilidad.

No procede.

ASI 4.2: Descripción de la Interacción de Objetos

El objetivo de esta tarea es describir la cooperación entre los objetos utilizados para la
realización de un caso de uso, que ya fueron identificados en la tarea anterior.
Para representar esta información, se usan diagramas de interacción que contienen
instancias de los actores participantes, objetos, y la secuencia de mensajes
intercambiados entre ellos. Se pueden establecer criterios para determinar qué tipo de
objetos y mensajes se va a incluir en este diagrama, como por ejemplo: si se incluyen
objetos y llamadas a bases de datos, objetos de interfaz de usuario, de control, etc.
Estos diagramas pueden ser tanto de secuencia como de colaboración, y su uso
depende de si se quieren centrar en la secuencia cronológica o en cómo es la
comunicación entre los objetos.
En aquellos casos en los que se especifique más de un escenario para un caso de uso,
puede ser conveniente representar cada uno de ellos en un diagrama de interacción.
También es recomendable, sobre todo en el caso anterior, completar los diagramas con
una descripción textual.
El diagrama de clases se realizó siguiendo el método recomendado por UML en lugar
de aplicar Entidad/Relación extendido, puesto que se parte de una definición del sistema
a muy alto nivel en la que no se valoran, porque no interesa y restaría claridad a la
definición, atributos u operaciones. Documento de referencia Modelo de Clases.
Ver también en la Base de Datos Diccionario de Informaciones.

Puede consultar la versión definitiva los diagramas de secuencias en el modelo de

negocio y de los de colaboración en el modelo de procesos.

ASI 4.1: Identificación de Clases Asociadas a un Caso de Uso

Identificación de clases de análisis que intervengan en los casos de uso seleccionados

en esta fase.

Puede consultar la versión definitiva de los modelos de clases y casos de uso.

ASI 5: Análisis de Clases

El objetivo de esta actividad es describir aquellas clases cuya comprensión se estime

necesaria para la comprensión general del sistema, identificando las responsabilidades
que tienen asociadas, sus atributos, y las relaciones entre ellas. Para esto, se debe tener
en cuenta el catálogo de normas, de forma que el modelo de clases cumpla estos
criterios, con el fin de evitar posibles inconsistencias en el diseño.

Al no realizar ningún prototipo en esta fase, el análisis del diagrama de clases se

pospone a una fase siguiente en la que entraremos en mayor profundidad en la
estructura del diagrama de clases.

DSI 1.1: Definición de los Niveles de Arquitectura

En esta tarea se describen los niveles de la arquitectura software, mediante la

definición de las principales particiones físicas del sistema de información,
representadas como nodos y comunicaciones entre nodos.
Se entiende por nodo cada partición física o parte significativa del sistema de
información, con características propias de ejecución o función, e incluso de diseño y
construcción.

Vamos a realizar es este momento un posible diagrama de despliegue con las tres
posibles disposiciones de sistema en cuanto a la captura de datos que tenemos previstas,
a la espera de que se seleccione la mas adecuada. Los diagramas son los siguientes:

- Opción 1: Servidor de Datos + PC Portatil

 Comunicación por Red Local

Portátil

Servidor
 - Opción 2: Servidor de Datos + PocketPC

Sincronización

Servidor

- Opcion 3: Servidor de Datos + Tablet PC

Comunicación por Red Local

Servidor Tablet PC

En estos diagramas podemos comprobar como tanto la opción 1 como la opción 3

presentan similitudes a la hora de realizar la conexión con el servidor de datos, ya que
ambos se podrían comunicar mediante una red local, al tener ambos las mismas
características que un PC. Además, un Tablet PC nos ofrece la posibilidad de poder
escribir directamente sobre la pantalla, por ser esta táctil.

En cuanto a la conexión con el PocketPC, esta se realizará normalmente por la base de

sincronización, aunque tras realizarse la selección del entorno tecnológico por parte del
cliente se pueden llegar a estudiar otras opciones (inalámbrica, bluetooth…)

Una vez finalizadas las posibles opciones para el subsistema de captura de datos, vamos
a proceder a visualizar el sistema de cumplimentación de impresos oficiales, cuyos
requisitos son:
 Conexión

Impresora
Servidor

Aún no se ha especificado tipo de impresora, ya que no sabemos que opción se va a

tomar para la impresión de los elementos oficiales. En cuanto se conozca ello, se optará
por una impresora laser monocroma o de inyección de tinta (mucho mas económica
pero de mantenimiento mas elevado). El departamento de arquitectura tecnológica nos
ofrecerá la solución que mas se adapte a las necesidades del proyecto.

Tampoco hemos seleccionado el tipo de conexión que tomará la impresora, aunque lo

más normal es que se emplee la conexión USB en vez de la vetusta conexión de puerto
paralelo.

Por último, el sistema de estadísticas (almacenamiento de datos) sería el servidor que

aparece en todos los diagramas de despliegue anteriores. Este servidor integrará un
servidor de bases de datos, que será el que se encargue del control de toda la
información. Aún no está decidido con que servidor trabajaremos, ya que dependemos
de las posibilidades económicas del cliente.

DSI 1.2: Identificación de Requisitos de Diseño y Construcción

En esta tarea se realiza la especificación de los requisitos que están directamente

relacionados con la adopción o diseño de una arquitectura o infraestructura concreta,
y que pueden condicionar el diseño o la construcción del sistema de información, es
decir, se especifican los requisitos derivados de la tarea anterior.

Dentro de los requisitos que van a hacer decantarse por una arquitectura tecnológica u
otra son los siguientes:

- Portabilidad, ya que el sistema debe ser de fácil manejo, al tener que

manipular al ave.

- Velocidad de Proceso: no requerimos gran velocidad de proceso para el

sistema, ya que únicamente vamos a capturar datos que no requieren proceso
alguno, aunque no se debe ralentizar el proceso de anillamiento.
 - Capacidad de Almacenamiento: al tratar con información, debemos controlar
que no tengamos problemas para quedarnos sin espacio para poder incluir
nuevos datos.

- Capacidad de Sincronización: debemos ser capaces de trasladar la

información disponible en los dispositivos de captura al servidor de la forma
lo menos traumática posible.

- Tiempo de Uso: al ser las jornadas de anillamiento de larga duración, el

terminal de captura no debe ser un impedimento que haga que la duración de
estas se reduzca.

- Capacidad de Expansión: debemos ser capaces de integrar un GPS en la

plataforma que se seleccione para el terminal de captura de datos.

- Facilidad de uso: tenemos tener en cuenta la facilidad para introducir datos

en el sistema.

- Coste: las costes del sistema deben ajustarse a las posibilidades del cliente.

Prototipo

Es posible realizar un prototipo exploratorio en esta fase con el fin de demostrar la

viabilidad de llevar a cabo el sistema, es decir, con el fin de demostrar que es posible
desarrollar un sistema que cumpla los requisitos especificados inicialmente,
independientemente de su coste tanto económico como temporal.

No es necesario llevar a cabo el desarrollo de un prototipo exploratorio ya que se

dispone de otro proyecto que ha llevado a cabo la transmisión de datos entre un Pocket-
PC y ordenador de sobremesa, 8.06/47.2077 realizado entre la Universidad de Málaga y
la Empresa Malagueña Mixta de Limpieza, con resultado satisfactorio. Para el resto de
las opciones manejadas tampoco será necesario el desarrollo de un prototipo
exploratorio porque la comunicación por red local es trivial.
Resumen de la fase de inicio:

Hito: Objetivos del ciclo de vida.

Iteraciones: 1
1. Objetivos: Delimitación del alcance y el ámbito del sistema. Determinar si es
viable la realización del sistema.
Fecha de Inicio: Jueves 6 de Noviembre de 2003
Fecha de Fin: Jueves 4 de Diciembre de 2003
Consideraciones: Consecución de los objetivos. Se considera que el ritmo de
trabajo es bueno. No fue necesaria la construcción de un prototipo exploratorio
puesto que se tiene constancia, por proyectos anteriores, de la viabilidad de
compartir datos entre un dispositivo de captura de datos Pocket-PC y un ordenador
de sobremesa.
Construcciones: 8
1.1 Objetivos: Realizar las tareas previas que son necesarias para iniciar el proyecto.
Tareas: PSI 1.1, 1.2, 1.3 (Fase Preliminar), Planificación de la Fase de Inicio.
Fecha de Inicio: Jueves 6 de noviembre de 2003
Fecha de Fin: Viernes 7 de noviembre de 2003
Evaluación: Objetivo cubierto.
1.2 Objetivos: Establecer las bases para desarrollar el resto de tareas de esta fase.
Tareas: PSI 2.1, 2.2, 2.3, 3.1, 3.2, 4.1, EVS 3.1, Modelo de Negocio.
Fecha de Inicio: 19 de Noviembre del 2003
Fecha de Fin: 21 de Noviembre del 2003
Evaluación: Objetivo cubierto.
1.3 Objetivos: Identificación de subsistemas afectados y mejoras propuestas.
Tareas: PSI 5.1, PSI 5.2, PSI 5.3, PSI 6.1
Fecha de Inicio: 19 de Noviembre del 2003
Fecha de Fin: 21 de Noviembre del 2003
Evaluación: Objetivo cubierto.
1.4 Objetivos: Valoración de la situación actual.
Tareas: PSI 4.2, 4.3, EVS 1.3, 2.1, 2.2, 2.3, 2.4 3.2, 3.3, Definición inicial de la
estructura para la organización del proceso de desarrollo de software.
Fecha de Inicio: 24 de Noviembre del 2003
Fecha de Fin: 25 de Noviembre del 2003
Evaluación: Objetivo cubierto.
1.5 Objetivos: Modelo de clases.
Tareas: ASI 1.1, 1.2, 1.4, 1.3, 8.1, 8.3, 8.4, 8.5, 10.1, 10.2, 10.3, Construcción
de la estructura para la organización del proceso de desarrollo de software.
Fecha de Inicio: 26 de Noviembre del 2003
Fecha de Fin: 2 de Diciembre del 2003
Evaluación: Objetivo cubierto.
1.6 Objetivos: Modelo de casos de uso.
Tareas: ASI 2.1, 2.2, 2.3, 2.4, 3.1, 3.2, 4.2
Fecha de Inicio: 28 de Noviembre del 2003
Fecha de Fin: 2 de Diciembre del 2003
Evaluación: Objetivo cubierto.
 1.7 Objetivos: Partición física del sistema y los requisitos que comporta.
Tareas: DSI 1.1, DSI 1.2, Añadir apuesta económica al análisis de diseño.
Fecha de Inicio: 2 de Diciembre del 2003
Fecha de Fin: 2 de Diciembre del 2003
Evaluación: Objetivo cubierto.
1.8 Objetivos: Culminación de tareas pendientes.
Tareas: ASI 4.1, 5.1, 5.2, 5.3, ASI 9.1, 9.2, 9.3, Cierre de la fase de inicio.
Fecha de Inicio: 3 de Diciembre del 2003
Fecha de Fin: 4 de Diciembre del 2003
Evaluación: La actividad ASI 5 no se llevó a cabo porque se estimó que no
había ninguna clase cuyo análisis fuera necesario adelantar para mejorar la
comprensión del sistema. Objetivo cubierto.

EVALUACIÓN
Objetivos del ciclo de vida:
¿Se ha determinado con claridad el ámbito del sistema?
Sí, el ámbito se define con claridad en el modelo del negocio.

¿Se ha determinado lo que va a estar dentro del sistema y lo que va a estar fuera de él?
Sí, se determina en los modelos del negocio, y de procesos.

¿Se ha llegado a un acuerdo con todas las personas involucradas sobre los requisitos
fundamentales del sistema?
En espera de la contestación de SILVEMA al modelo del negocio que les será remitido.

¿Se vislumbra una arquitectura que implemente estas características?

Sí, no se realizará prototipo exploratorio porque para la alternativa del Pocket-PC se
dispone de un proyecto anterior que garantiza la transmisión de datos entre el Pocket-
PC y el ordenador de sobremesa, y para las demás alternativas la comunicación sería
por red local y se considera trivial.
Una vez resuelta la transmisión de datos entre los subsistemas de captura de datos y de
almacenamiento de los mismo no se vislumbra especial dificultad en ningún otro
aspecto del proyecto, tales como la generación de análisis o el cumplimento de impresos
oficiales.

¿Se han identificado los riesgos críticos para el desarrollo exitoso del proyecto?
No se identificado ningún riesgo que ponga en duda la continuidad del proyecto.

¿Se prevé una forma de tratarlos?

No procede.

¿El uso del producto generará beneficios que justifiquen lo invertido en su

construcción?
Los beneficios no serán económicos puesto que el sistema está enfocado a la captura y
tratamiento de datos de aves. Sin embargo, el fin último de la actividad de SILVEMA es
preservar la conservación de las aves y consideramos que un aumento en la fiabilidad,
rapidez de captura de datos y comodidad para acceder a los datos almacenados o para
obtener análisis de los mismo, ayudará a SILVEMA a cumplir sus objetivos.
¿Es factible para su organización llevar adelante el proyecto?
Sí, no se vislumbra ningún factor que lo ponga en duda.

¿Están los inversores de acuerdo con los objetivos?

En espera de la contestación de SILVEMA al modelo del negocio que les será remitido.

Ámbito del sistema:

¿Está claro lo que va a formar parte del sistema?
Sí, se ha delimitado claramente en los modelos de procesos, casos de uso y clases.

¿Se han identificado todos los actores?

Sí, consultar los modelos del negocio, de procesos y de casos de uso.

¿Se ha expuesto la naturaleza general de las interfaces?

Al no ser necesario realizar un prototipo exploratorio, y al no aparecer en el estudio del
sistema ninguna interfaz que necesitara de una especial atención en esta fase del
proyecto, no se han tratado las interfaces del sistema.

¿Puede, lo que está incluido en el ámbito, constituir por sí mismo un sistema que
funcione?
Sí, la estructura que tendrá el sistema está bastante clara; dispositivo de captura de
datos, estructura de almacenamiento, comunicación de datos entre los dos primeros,
aplicación para el análisis de los datos y para el cumplimento de los impresos oficiales.
El ámbito del sistema se considera suficiente para desarrollar dicha estructura.

Ambigüedades en los requisitos:

¿Se han identificado y detallado los requisitos de los casos de uso necesarios para
alcanzar los objetivos de esta fase?
Sí, modelo de casos de uso (incluye diccionario de actividades) y catálogo de requisitos.

¿Se han identificado y detallado los requisitos adicionales?

Sí, se han identificado los requisitos adicionales al entorno tecnológico propuesto.

Arquitectura candidata:

¿Satisface esta arquitectura las necesidades de los usuarios?

En espera de la contestación de SILVEMA al modelo del negocio que les será remitido,
pues el resto de modelos (procesos, casos de uso y clases) derivan del modelo de
negocio que sin embargo, es menos técnico y por tanto más comprensible para
SILVEMA.

¿Es factible que funcione?

Sí, se cuenta con las suficientes garantías, hecho que provocado que se descarte la
realización de un prototipo exploratorio como se describió anteriormente.

¿Puede usar de forma apropiada la tecnología sobre la que va a ser construida?

No se vislumbran problemas en este apartado.

¿Puede ser eficiente?

No se vislumbran problemas en este apartado.

¿Puede explotar los recursos existentes?

No se vislumbran problemas en este apartado.

¿Puede ser fiable y tolerante a fallos?

No se vislumbran problemas en este apartado.

¿Será robusta y flexible al cambio?

No se vislumbran problemas en este apartado.

¿Evolucionará fácilmente si se añaden requisitos?

No se vislumbran problemas en este apartado.

Mitigar riesgos críticos:

¿Se han identificado todos los riesgos críticos?

No se identificado ningún riesgo que ponga en duda la continuidad del proyecto.

¿Se han mitigado los riesgos identificados o existe un plan para mitigarlos?
No procede.

Juzgar el valor del análisis de negocio inicial.

En cuanto a la apuesta económica su precisión se supone reducida, sin embargo, dada la

inclusión de elementos técnicos con precios muy definidos tales como los dispositivos
de captura de datos, ordenador de sobremesa o impresora, hay un porcentaje que se
puede considerar fiable.
No se ha incluido recuperación de la inversión porque dicha recuperación nunca llegará
en el terreno económico y esta fase no permite realizar estimaciones de otro tipo de
beneficio.

PRODUCTOS GENERADOS

1. Lista de características. (Requisitos, hecho).

2. Primera versión del modelo de negocio. (Hecho).
3. Esbozo de los modelos de casos de uso, análisis, diseño y despliegue. Los de
implementación y pruebas serán rudimentarios. Primera versión de los requisitos
adicionales. (Hecho).
4. Primer esquema de la descripción de la arquitectura candidata que perfila las vistas
de los modelos de casos de uso, análisis, diseño e implementación. (La arquitectura
consta de la vista, completa, de los distintos modelos generados, se considera
hecho).
5. Prototipo exploratorio (opcional). (Se omite).
6. Lista inicial de riesgos y clasificación de casos de uso. (Hecho).
7. Rudimentos de un plan para el proyecto en su totalidad. (Hecho).
8. Primer borrador del análisis de negocio, incluyendo el contexto del negocio y los
criterios de éxito como estimación de beneficios, reconocimiento de mercado y
estimación del proyecto. (Hecho pero incluyendo sólo contexto y apuesta
económica).