TP N°2 Modelado de Procesos y de Sistemas

INGENIERA DEL SOFTWARE
TRABAJO PRCTICO N 2:
MODELADO DE PROCESOS Y
DE SISTEMAS
Profesores:
Ing. Belloni, Edgardo
Ing. Amatte, Fernando
Grupo Nro: 2
Integrantes:
Alegre, Gustavo Fabin Mat: 66436
Armoa, Guido Sebastin Mat: 66400
Candia, Gabriel Jos Mat: 66424
Candia Ripoll, Mauro Mat: 66268
Dehner, Gabriel Andrs Mat: 66501
Guidici, Alejandro Manuel Mat: 66313
Onufrijczuk, Juan Marcos Mat: 66311
Ao: 2017
1.- Seleccionar UNO de los 3 Casos de Estudio siendo tratados por el grupo hasta el
momento en la cursada. Observando consistencia con el Proceso de Desarrollo global
seleccionado en el TP N 1 para tal caso de estudio:
(a) Extender descripcin del caso de estudio seleccionado aportada en el TP N 1.
DESCRIPCIN DEL CASO DE ESTUDIO
Sistema meteorolgico para zonas hostiles

(The wilderness weather system)
Este caso de estudio se basa en el software de estaciones meteorolgicas que

recogen informacin del entorno en reas remotas que no cuentan con una infraestructura
local (energa, comunicaciones, carreteras, etc.). Estas estaciones forman parte de un
sistema nacional de informacin meteorolgica destinado a captar y analizar dicha
informacin de manera detallada para ayudar a entender tanto el cambio climtico local
como nacional y apoyar al servicio nacional de prediccin del tiempo.
Una caracterstica importante de la estacin meteorolgica es que tiene que ser
totalmente autnoma, ya que la energa y las comunicaciones no son de fcil acceso. Por
ello, el sistema debe contar con la capacidad de generar energa (utilizando paneles solares
o energa elica). Por otro lado, debe poder ser desplegado lejos de una carretera, lo cual
hace que el acceso para las reparaciones sea difcil y costoso. Su comunicacin se realiza
va satlite, con lo que deben tener la capacidad de reconfigurarse para hacer frente a
problemas con los instrumentos y actualizaciones de software. Los requisitos de tiempo son
tales que no se necesitan respuestas muy rpidas, por lo que no es imperante basarse en
uno de los estilos arquitectnicos para los sistemas de tiempo real.
Las estaciones meteorolgicas forman parte de un sistema ms amplio (Figura 1), el
cual recopila datos de estas estaciones y los pone a disposicin de otros sistemas para su
procesamiento. Estos sistemas son:
1. El sistema de estacin meteorolgica, responsable de recopilar datos meteorolgicos,
llevar a cabo un tratamiento inicial de los datos y transmitirlos al sistema de gestin y
archivado de datos.
2. El sistema de gestin y archivado de datos, recopila los datos de todas las estaciones
meteorolgicas, lleva a cabo su procesamiento, su anlisis y los archiva de forma que
puedan ser recuperados por otros sistemas, como sistemas de previsin meteorolgica.
3. El sistema de mantenimiento de la estacin, puede comunicarse por satlite con
todas las estaciones meteorolgicas para monitorizar su estado y proporcionar reportes
sobre problemas. Puede actualizar el software embebido en estos sistemas. En caso de
problemas en las estaciones meteorolgicas, este sistema tambin puede controlarlos
remotamente.
Pag.1
Ingeniera de Software TP N 2 Ao 2017 Grupo N 2
Integrantes: Alegre Armoa Candia Candia Ripoll Dehner Guidici Onufrijczuk
Figura 1. Entorno de la estacin meteorolgica.
La estacin meteorolgica incluye una serie de instrumentos que miden parmetros

meteorolgicos tales como la velocidad y la direccin del viento, las temperaturas del suelo
y del aire, la presin baromtrica y la precipitacin durante un perodo de 24 horas. Cada
uno de estos instrumentos est controlado por un sistema de software que toma lecturas de
parmetros peridicamente, y gestiona los datos recogidos de los instrumentos.
El sistema de estacin meteorolgica funciona recogiendo mediciones
meteorolgicas a intervalos frecuentes. Sin embargo, debido a que el ancho de banda con
el satlite es relativamente estrecho, la estacin meteorolgica lleva a cabo cierto
procesamiento local y agregacin (examinacin o estudio) de los datos. A continuacin,
transmite estos datos agregados cuando los solicite el sistema de gestin y archivado de
datos. Si, por cualquier razn, es imposible establecer una conexin, la estacin
meteorolgica mantiene los datos localmente hasta que sta pueda realizarse.
El software de la estacin no se ocupa slo de la recopilacin de datos, sino que
adems debe:
I. Monitorear los instrumentos, el hardware de alimentacin y de comunicacin, y
reportar los fallos al sistema de gestin y archivado de datos.
II. Administrar la alimentacin del sistema, asegurndose de que las bateras se
carguen siempre que las condiciones ambientales as lo permitan, pero cuidando
que los generadores se apaguen en condiciones climticas potencialmente dainas,
tales como fuertes vientos.
III. Permitir una reconfiguracin dinmica que posibilite que las partes del software se
sustituyan por versiones nuevas, y que los instrumentos de reserva sean
reemplazados en el sistema en caso de fallo.
El software instalado es complejo, ya que las estaciones meteorolgicas tienen que
ser autosuficientes y desatendidas, por ms que la funcionalidad de recoleccin de datos
sea bastante simple.
Arquitectura
En la Figura 2 se puede apreciar la arquitectura del sistema de la estacin
meteorolgica.
Pag.2
Figura 2. Arquitectura de alto nivel de la estacin meteorolgica.
La estacin meteorolgica est compuesta por subsistemas independientes que se
comunican mediante la difusin de mensajes en una infraestructura comn, que se muestra
como enlace de comunicacin. Cada subsistema escucha los mensajes en esa
infraestructura y recoge los mensajes que estn destinados a ellos.
Subsistema Administrador de errores / fallas (Fault Manager)

Un administrador de fallas puede intentar reparar una unidad defectuosa
automticamente, pero si esto es imposible, el sistema se reconfigura automticamente
para sacar la unidad de servicio. El sistema debe continuar funcionando con las unidades
de trabajo restantes.
Subsistema Administrador de configuracin (Configuration Manager)

El administrador de configuracin se encarga de establecer el valor de variables en
funcin de las peticiones requeridas por el usuario, como ser: frecuencia de recoleccin de
datos, reinicio de algn determinado instrumento, etc.
El sistema presenta una configuracin predeterminada (default).
Subsistema Administrador de Energa (Power Manager)

Es un sistema que puede gestionar la potencia de energa utilizada por la estacin
en funcin de las necesidades, permitiendo un bajo consumo para la ejecucin de las
operaciones esenciales, o un alto consumo para el rendimiento mximo del sistema. Esto se
realiza en funcin de la energa disponible.
Subsistema Comunicaciones (Communications)

Cuando el subsistema de comunicaciones recibe un comando de control, tal como
apagado, el comando es recogido por cada uno de los otros subsistemas, que luego se
apagan de la manera correcta. El principal beneficio de esta arquitectura es que es fcil
Pag.3
soportar diferentes configuraciones de subsistemas porque el remitente de un mensaje no
necesita dirigir el mensaje a un subsistema en particular.
Subsistema Recopilacin de Datos (Data Collection)

Como puede apreciarse en la Figura 3, este subsistema permite la recoleccin de
datos de su entorno utilizando un conjunto de sensores (Transmisor y Receptor) los cuales
se ocupan de gestionar las comunicaciones. Adems, WeatherData (Datos del tiempo)
mantiene estos datos por un tiempo de manera encapsulada y luego los transmite al
sistema de informacin meteorolgica.
Figura 3. Arquitectura del sistema de recoleccin de datos.
Subsistema Instrumentos (Instruments)

Se requerirn instrumentos encargados de recolectar datos meteorolgicos a una
frecuencia especfica, que almacenan localmente los datos recopilados. Por ejemplo,
Termmetro de tierra, Anemmetro, Barmetro, etc.
Pag.4
(b) Analizar y Determinar el/los proceso/s de Ingeniera de Requerimientos
convenientes de aplicar al caso de estudio seleccionado. Justificar brevemente dicho
anlisis y determinacin.
Los procesos de ingeniera de requerimientos pueden incluir cuatro actividades de

alto nivel. stas se centran en evaluar si el sistema es til para el negocio (estudio
de factibilidad), descubrir requerimientos (elicitacin y anlisis), convertir estos
requisitos en alguna forma estndar (especificacin) y verificar que los requisitos
realmente definen el sistema que el cliente desea (validacin) [1].
Considerando el proceso de desarrollo de software seleccionado, determinamos la

necesidad de realizar las siguientes actividades en este caso de estudio-:
Elicitacin y anlisis
-Descubrimiento de requerimientos: existen requerimientos claros (ya descubiertos) en el
caso de estudio, y como ya se mencion en Trabajo prctico N 1, estos requerimientos no
tendern a sufrir abruptos cambios conforme avancemos en el desarrollo del sistema.
-Clasificacin y organizacin de requerimientos: consideramos necesaria esta actividad
para poder agrupar y clasificar los requerimientos relacionados, ya que esto servir para
un mejor desarrollo, teniendo en cuenta los distintos subsistemas existentes y la importancia
de determinar cules requerimientos corresponden a cada subsistema.
-Priorizacin y negociacin de requerimientos: al comprender el modelo de proceso
seleccionado (el modelo en espiral, que es un modelo iterativo), esta actividad se hace an
ms importante teniendo en cuenta la trascendencia de determinar cules requerimientos
deben realizarse en las primeras iteraciones y cules en las iteraciones posteriores.
Tcnicas utilizadas para la actividad de Elicitacin y Anlisis, instanciadas en RUP

(que compone al modelo en espiral seleccionado en el TP1):
Las tcnicas de captura de requisitos utilizadas en RUP se pueden describir
mediante un diagrama de actividad de la siguiente manera [2].
Figura 4. Flujo de trabajo para la captura de requisitos en forma de casos de uso.
Pag.5
A continuacin se detallan dichas actividades:
(1) Encontrar actores y casos de uso: nos permite delimitar el
sistema de su entorno, esbozar quin y qu (actores) interactan con
el sistema, y qu funcionalidad (casos de uso) se espera del sistema.
Adems nos otorga la posibilidad de capturar y definir un glosario de
trminos comunes esenciales para la creacin de descripciones
detalladas de las funcionalidades del sistema.
La actividad tiene como entradas un Modelo de Negocio (o de Dominio) si lo hubiera, una
lista de Requisitos Adicionales y otra lista de Caractersticas del nuevo sistema.
Desde un punto de vista de alto nivel, la actividad consta de cuatro pasos. [2]
1. Encontrar Actores.
2. Encontrar Casos de Uso.
3. Describir brevemente Cada caso de Uso.
4. Describir el modelo de Casos de Uso en su totalidad.
Dichos pasos no tienen un orden en particular, sino que a menudo se realizan de manera
simultnea.
El diagrama de actividades (figura 5) muestra las entradas y resultados de esta actividad,
segn se define en [2].
Figura 5. Las entradas y los resultados de identificar actores y casos de uso.
(2) Priorizar casos de uso: esta actividad tiene como propsito

proporcionar entradas a la priorizacin de casos de uso para
determinar cules son necesarios para el desarrollo (anlisis, diseo,
implementacin, etc) en las primeras iteraciones, y cules pueden
dejarse para ms tarde. Estos resultados se recogen en la vista de la
arquitectura del modelo de casos de uso como se muestra en la
siguiente imagen.
Pag.6
Figura 6. Las entradas y los resultados de priorizar los casos de uso.
Para esto suele ser til usar tres categoras: imprescindible,

importante y deseable.
Los requerimientos imprescindibles son aquellos que, si no se
implementan, hacen que el sistema no tenga sentido.
Los importantes son aquellos que haran que el usuario se
sienta decepcionado si no se implementan.
Los deseables son aquellos que el usuario querra tener, si
hubiese tiempo disponible. Al evaluar un requerimiento debo
tambin analizar su costo o complejidad.
Una vez hecha esta categorizacin de los requerimientos, podemos
tomar como estrategia general el incluir los imprescindibles, discutir
los importantes y descartar los deseables cuyo costo no sea bajo.
(3) Detallar un caso de uso: Se utilizan los resultados obtenidos en

la primera actividad, como se muestra en la figura 7.
Como resultado, esta actividad permite obtener la descripcin
detallada de un caso de uso en particular en forma de texto y diagramas.
Figura 7. Las entradas y los resultados de detallar cada caso de uso.
Se descompone de la siguiente manera:
Pag.7
Estructuracin de la descripcin de casos de uso: en el cual se
describe un camino estndar del caso de uso, y todos los
caminos alternativos posibles.
Formalizacin de la descripcin de casos de uso: se puede
utilizar una tcnica de modelado visual para describir los casos
de uso. Ejemplos de tcnicas de modelado visual son
diagramas de estados de UML, diagramas de actividad,
diagramas de interaccin, etc.
(4) Prototipar la interfaz de usuario: tiene como objetivo construir un
prototipo de interfaz de usuario. En la figura 8 se muestran las
entradas y los resultados de prototipar la interfaz de usuario.
Figura 8. Las entradas y los resultados prototipar la interfaz de usuario.
Primero se debe determinar qu interfaces de usuario se necesita.

Luego, se crea un diseo fsico de la interfaz de usuario y se desarrollarn prototipos que
ilustren cmo pueden utilizar el sistema los usuarios.
Como resultado final de esta actividad, se tiene un conjunto de
esquemas de interfaces de usuario y prototipos de interfaces de usuario que especifican la
apariencia de esas interfaces de cara a los actores ms importantes.
Crear el diseo lgico de una interfaz de usuario.
Creacin de un diseo y un prototipo fsicos de interfaz de
usuario.
(5) Estructurar el modelo de casos de uso: el propsito de esta
actividad es extraer descripciones de funcionalidad GENERALES y
COMPARTIDAS que pueden ser utilizadas por descripciones ms
especficas. Adems, se busca extraer descripciones de funcionalidad
ADICIONALES u OPCIONALES que pueden extender descripciones
ms especficas. En la figura 9 se describen las entradas y resultados
de esta actividad.
Pag.8
Figura 9. Las entradas y los resultados de encontrar generalizaciones en el modelo de
casos de uso.
Esta actividad consta de las siguientes actividades:

Identificacin de descripciones de funcionalidad compartidas.
Identificacin de descripciones de funcionalidad adicionales y
opcionales.
Identificacin de otras relaciones entre casos de uso.
Determinamos, adems, que las siguientes actividades no se realizarn en este caso

de estudio:
Estudio de Factibilidad: esta actividad se centra en evaluar si el sistema es

til para el negocio [1]. Sin embargo, al poner en consideracin las
caractersticas que dieron pie a la solicitud del sistema (necesidad de recoger
informacin del entorno en reas remotas), es evidente que la viabilidad del
sistema est asegurada, dado que el sistema de informacin no tendra
utilidad sin esta capacidad de obtener la informacin de todas las zonas
(remotas y no remotas). Por otro lado, la solicitud proviene de un rgano de
toma de decisiones, por lo que tampoco debera invertirse tiempo en esta
actividad.
Validacin: consiste en revisar que los requerimientos realmente definen el

sistema que el cliente desea [1]. No obstante, debido a que los
requerimientos ya se encuentran determinados por el cliente en un
documento claro, rgido y consistente, consideramos que sera
contraproducente realizar actividad.
2.- Resumir con Diagramas UML, y muy breve descripcin de actividades fundamentales
involucradas, tanto el Proceso de Desarrollo Global como el Proceso de Ingeniera de
Requerimientos que consideran convenientes de aplicar al caso de estudio seleccionado.
Pag.9
Descripcin de actividades fundamentales:
Como ya se mencion en el trabajo prctico n 1, optamos por utilizar el modelo en Espiral
de Boehm y emplear RUP en la actividad de desarrollo y validacin. Por lo tanto, se
especifica lo siguiente:
1. Establecimiento de objetivos, limitaciones y restricciones: Se definen los objetivos

especficos para esa fase del proyecto. Las restricciones en el proceso y el producto se
identifican y se elabora un plan de gestin detallado. Los riesgos del proyecto estn
identificados. Se pueden planificar estrategias alternativas, segn estos riesgos.
2. Anlisis y reduccin de riesgos: Para cada uno de los riesgos identificados del
proyecto, se lleva a cabo un anlisis detallado. Se toman medidas para reducir el riesgo.
Por ejemplo, si existe el riesgo de que los requisitos sean inapropiados, se puede
desarrollar un sistema prototipo.
3. Desarrollo y validacin: en esta etapa elegimos RUP como modelo de desarrollo para el
sistema. Se identificarn los requerimientos y se establecer la arquitectura necesaria para
el proyecto. Luego se validar el mismo.
El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un
sistema. Cada ciclo concluye con una versin del producto para los clientes. Cada ciclo
consta de cuatro fases: inicio, elaboracin, construccin y transicin. Cada fase se
subdivide a su vez en iteraciones. Esto se visualiza en la figura 10.
Figura 10. Un ciclo de RUP con sus iteraciones.

Fase de inicio: se desarrolla una descripcin del producto final a partir de una
buena idea y se presenta el anlisis de negocio para el producto.
Fase de elaboracin: se especifican en detalle la mayora de los casos de uso del
producto y se disea la arquitectura del sistema.
Pag.10
Fase de construccin: se crea el producto (software terminado). En esta fase, la
lnea base de la arquitectura crece hasta convertirse en el sistema completo.
Fase de transicin: cubre el perodo durante el cual el producto se convierte en
versin beta.
Fase de Inicio
El objetivo de esta fase de inicio es desarrollar el anlisis de negocio hasta el punto

necesario para justificar la puesta en marcha del proyecto. Este debe responder a:
Compensaran las ganancias procedentes del uso o la venta del producto software,
los costes de su desarrollo?
Llegar el producto al mercado (o su aplicacin interna) a tiempo de obtener esas
ganancias?
Actividades de la fase de inicio:

Definir el mbito del proyecto
Resolver ambigedades en los requisitos recopilados en esta fase
Determinar la arquitectura candidata
Mitigar los riesgos crticos
Elaborar un plan base del proyecto
Establecer un modelo de negocios
Definir objetivos del ciclo de vida
Criterios de evaluacin para las 5 actividades ms importantes:

Definir el mbito del proyecto
Est claro lo que va formar parte del sistema?
Se han identificado todos los actores?
Se ha expuesto la naturaleza general de las interfaces con estos actores?
Puede, lo que est incluido en el mbito, constituir por s mismo un sistema
que funcione?
Resolver ambigedades en los requisitos recopilados en esta fase
Se han identificado y detallado los requisitos del limitado nmero de casos
de uso necesarios para alcanzar los objetivos de esta fase?
Se han identificado y detallado los requisito adicionales?
Determinar la arquitectura candidata
Satisface esta arquitectura las necesidades de los usuarios?
Es verosmil que funcione?
Mitigar los riesgos crticos
Se han identificado todos los riesgos crticos?
Se han mitigado los riesgos identificados o existe un plan para mitigarlos?
Establecer un modelo de negocios
Es el caso de negocios inicial lo suficientemente bueno como para justificar
que sigamos hacia adelante con el proyecto?
Pag.11
Tareas incluidas dentro de cada disciplina, para la fase de inicio:
Disciplina Tareas
Requisitos Enumerar los requisitos candidatos a figurar en la lista de

caractersticas del sistema
Comprender el contexto del sistema
Representar los requisitos funcionales pertinentes como casos
de uso
Recoger los requisitos no funcionales
Encontrar actores y casos de uso
Definir la prioridad de los casos de uso
Detallar un caso de uso
Elaborar un prototipo de la interfaz de usuario
Estructurar el modelo de casos de uso
Anlisis Anlisis de la arquitectura

Analizar un caso de uso
Analizar una clase y analizar un paquete
Diseo Diseo de la arquitectura

Disear un caso de uso
Disear una clase y disear un subsistema
Implementacin Prototipo de demostracin
Pruebas Desarrollo de planes provisionales de pruebas
Puede que todo el trabajo fsico realizado en esta fase sea descartado. Lo nico que
normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo.
Productos de esta fase:

Una lista de caractersticas.
Una primera versin del modelo de negocios (o del dominio) que describe el
contexto del sistema.
Un esbozo de los modelos que representan una primera versin del modelo de
casos de uso, el modelo de anlisis y el modelo de diseo. Respecto al modelo de
implementacin y el modelo de pruebas, puede existir algo rudimentario. Tambin se
genera una primera versin de los requisitos adicionales.
Un primer esquema de la descripcin de una arquitectura candidata, que perfila las
vistas de los modelos de casos de uso, anlisis, diseo e implementacin.
Posiblemente, un prototipo exploratorio que muestra el uso del nuevo sistema.
Una lista inicial de riesgos y una clasificacin de casos de uso.
Los rudimentos de un plan para el proyecto en su totalidad, incluyendo el plan
general de las fases.
Un primer borrador de anlisis de negocio, que incluye: contexto del negocio y
criterios de xito.
Pag.12
La fase de inicio finaliza con el HIto de Objetivos del ciclo de vida. Este hito es alcanzado
cuando el equipo de proyectos los stakeholders llegan a un acuerdo sobre:
Cul es el conjunto de necesidades del negocio, y que conjunto de funciones
satisfacen estas necesidades
Una planificacin preliminar de iteraciones
Una arquitectura preliminar
Pag.13
Pag.14
Fase de Transicin
La fase de transicin cubre el periodo durante el cual el producto se convierte en versiones

betas hasta llegar al producto final ejecutable con todos sus documentos y artefactos.
Instalar esta versin en los lugares elegidos dependiendo el cliente (mercado general o
cliente nico).
Las iteraciones en esta fase continan agregando caractersticas al software. Sin embargo,
las caractersticas se agregan a un sistema que el usuario se encuentra utilizando
activamente.
Actuar a partir de la informacin recogida en las instalaciones de pruebas y adaptar el
producto corregido a las circunstancias de los usuarios.
Los artefactos construidos en esta fase son los mismos que en la fase de construccin. El
equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del
sistema desarrollado en la fase anterior. Y determinar cundo se acaba el proyecto.
Actividades de la fase de transicin:

Implantar producto en entorno de operacin
Implantar en mercado general
Implantar en cliente nico
Recibir informacin por parte del usuario
Modificar sistema o artefactos relacionados
Modificar el manual de usuario y de capacitacin
Preparar produccin del producto
Proporcionar ayuda al cliente
Realizar el empaquetado del producto
Producir producto ejecutable
Finalizar con el lanzamiento del producto software al mercado
Resultados de la fase:
El propio software ejecutable, incluyendo el software de instalacin.
Documentos legales, como contratos, licencias, renuncias de derechos y garantas.
La versin completa y corregida de lnea base de la versin del producto, incluyendo
todos los modelos del sistema.
La descripcin completa y actualizada de la arquitectura.
Manuales y material de formacin de usuario final, del operador y del administrador
del sistema.
Referencias (incluyendo referencias de la web) para la ayuda del cliente, acerca de
dnde encontrar ms informacin cmo informar de defectos o donde encontrar
informacin sobre defectos y actualizarlos.
La fase de transicin finaliza con el hito de Lanzamiento del Producto. Este hito se alcanza
cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre:
Se han alcanzado los objetivos fijados en la fase de inicio.
El usuario est satisfecho con los resultados obtenidos.
Pag.15
4. Planificacin: El proyecto se revisa y se toma la decisin de continuar con un nuevo
ciclo de la espiral. Si se decide continuar, se elaboran planes para la prxima fase del
proyecto.
A continuacin, se prosigue a detallar el modelo de proceso elegido mediante un diagrama

de clases.
Aclaracin: Cabe destacar que dentro de las disciplinas prximamente representadas, en
RUP se podra incluir la planificacin, pero en la estructura la obviamos ya que esto ser
comprendido por las planificaciones propias del modelo en espiral.
Figura 11. Diagrama de clases del Modelo en Espiral con RUP en el desarrollo y validacin.
A su vez, se puede apreciar en un diagrama que resume las actividades realizadas en este
modelo de procesos.
Pag.16
Figura 12. Diagrama de actividades del Modelo en Espiral con RUP.
La ingeniera de requerimientos utilizada fue descrita en el punto 1.b. Se resumir con UML
cada una de las actividades de las tcnicas de captura de requisitos utilizadas en RUP.
Pag.17
En la figura 13 se muestra mediante un diagrama de actividades un resumen de la
ingeniera de requerimientos.
Figura 13. Diagrama de actividades de la ingeniera de requerimientos en RUP.

1) Encontrar actores y casos de uso
Pag.18
Figura 14. Diagrama de actividades que detalla el workflow de encontrar actores y casos
de uso.
Pag.19
2) Priorizar casos de uso.
Figura 15. Diagrama de actividades que detalla el workflow de priorizar casos de uso.
3) Detallar un caso de uso.
Pag.20
Figura 16. Diagrama de actividades que detalla el workflow de detallar un caso de uso.
4) Prototipar la interfaz de usuario.
Pag.21
Figura 17. Diagrama de actividades que detalla el workflow de prototipar la interfaz de
usuario.
5) Estructurar el modelo de casos de uso.
Pag.22
Figura 18. Diagrama de actividades que detalla el workflow de estructurar el modelo de
casos de uso.
Pag.23
Pag.24
3.- Identificar y especificar Requerimientos para el caso de estudio seleccionado.
Justificar la tcnica de especificacin utilizada en cada caso o de forma general:
(a) Identificar y definir Requerimientos de Usuario.
Requerimientos de Usuario:
o El Sistema de Gestin y Archivado de Datos debe poder solicitar reportes de los
datos capturados por la Estacin Meteorolgica.
o El Sistema de Mantenimiento de la Estacin debe poder solicitar reportes del
estado de la Estacin Meteorolgica que permitan su monitoreo.
o El Sistema de Mantenimiento de la Estacin debe poder actualizar el software de
la Estacin Meteorolgica de forma remota.
o El Sistema de Mantenimiento de la Estacin debe poder controlar remotamente la
Estacin Meteorolgica, en caso de problemas en la misma.
o El Sistema de Mantenimiento de la Estacin debe poder configurar los parmetros
de la Estacin Meteorolgica que rigen su funcionamiento (por ej.: frecuencia de
recoleccin de datos).
(b) Identificar y especificar Requerimientos del Sistema. Incluir Requerimientos
Funcionales, No Funcionales indicando sub-clasificaciones y mtricas
correspondientes, y de Dominio.
Requerimientos del Sistema:

Requerimientos Funcionales:
o El sistema de la Estacin Meteorolgica debe poder recolectar de forma
peridica los siguientes datos del clima: velocidad y direccin del viento,
temperatura del suelo y del aire, presin baromtrica y precipitaciones.
o El sistema debe poder realizar un procesamiento local a modo de sntesis
sobre los datos capturados.
o El sistema debe poder almacenar los ltimos datos capturados para que
stos no se pierdan en caso de no poder reportarlos a tiempo.
l sistema debe poder reportar los datos capturados.
o E
o El sistema debe poder reportar su estado para permitir un monitoreo remoto
del mismo (por ej.: nivel de energa, tiempo de carga, nivel de seal).
o El sistema debe poder reportar fallas (por ej.: instrumentos defectuosos,
fallas de software).
o El sistema debe poder funcionar de manera autnoma, incorporando los
siguientes requerimientos:
El sistema debe poder generar la energa necesaria para su
funcionamiento mediante paneles solares y energa elica, cargando
Pag.25
siempre que las condiciones climticas lo permitan, y apagando los
generadores en condiciones climticas adversas.
El sistema debe poder gestionar la potencia suministrada al sistema
funcionando a bajo consumo (funciones elementales) o alto consumo
(todas las funciones) segn la energa disponible.
El sistema debe poder reconfigurarse automticamente en caso de
falla mediante el monitoreo de sus instrumentos, reemplazando los
defectuosos por otros de reserva, o deshabilitando aquellos
defectuosos si no hubiera solucin; todo mientras los dems
instrumentos continan con su operacin.
l sistema debe poder actualizar el software embebido de manera remota.
o E
o El sistema debe poder ser controlado de manera remota en caso de que
ocurran problemas no anticipados.
o El sistema debe admitir la configuracin remota de sus parmetros (por
ej.: frecuencia de recoleccin de datos).
Requerimientos No Funcionales:
Requerimientos de Producto:
o D
isponibilidad:
El sistema de la Estacin Meteorolgica debe recolectar datos segn

la frecuencia establecida durante las 24hs del da.
El sistema debe contar con instrumentos redundantes que puedan ser
reemplazados sin necesidad de detener el sistema.
o C
onfiabilidad:
El sistema debe poder actualizar remotamente el software embebido

en caso de que se descubran fallas en su funcionamiento.
o E
ficiencia:
El sistema debe contar con espacio de almacenamiento suficiente

como para mantener los datos recolectados durante las ltimas 24hs
en caso que no pueda establecer comunicacin con el sistema
remoto.
AC VAN LAS ESPECIFICACIONES (dropbox, carpeta Requerimientos, archivo

Especificaciones - V2).
(c) Construir Diagrama de Casos de Uso (o el diagrama que resultase equivalente en

el proceso utilizado) correspondiente.
Pag.26
Figura 19. Diagrama de casos de uso del sistema de la estacin meteorolgica.
Pag.27
BIBLIOGRAFA CONSULTADA
[1] Ian Sommerville. SOFTWARE ENGINEERING. Ninth Edition.

[2] Rumbaugh, Booch, Jacobson. RUP.
Pag.28

TP N°2 Modelado de Procesos y de Sistemas

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TP N°2 Modelado de Procesos y de Sistemas

Diunggah oleh

Hak Cipta:

Format Tersedia

INGENIERA DEL SOFTWARE

DESCRIPCIN DEL CASO DE ESTUDIO

Sistema meteorolgico para zonas hostiles

Este caso de estudio se basa en el software de estaciones meteorolgicas que

La estacin meteorolgica incluye una serie de instrumentos que miden parmetros

Subsistema Administrador de errores / fallas (Fault Manager)

Subsistema Administrador de configuracin (Configuration Manager)

Subsistema Administrador de Energa (Power Manager)

Subsistema Comunicaciones (Communications)

Subsistema Recopilacin de Datos (Data Collection)

Figura 3. Arquitectura del sistema de recoleccin de datos.

Subsistema Instrumentos (Instruments)

Los procesos de ingeniera de requerimientos pueden incluir cuatro actividades de

Considerando el proceso de desarrollo de software seleccionado, determinamos la

Tcnicas utilizadas para la actividad de Elicitacin y Anlisis, instanciadas en RUP

Figura 4. Flujo de trabajo para la captura de requisitos en forma de casos de uso.

Figura 5. Las entradas y los resultados de identificar actores y casos de uso.

(2) Priorizar casos de uso: esta actividad tiene como propsito

Para esto suele ser til usar tres categoras: imprescindible,

(3) Detallar un caso de uso: Se utilizan los resultados obtenidos en

Figura 7. Las entradas y los resultados de detallar cada caso de uso.

Se descompone de la siguiente manera:

Figura 8. Las entradas y los resultados prototipar la interfaz de usuario.

Primero se debe determinar qu interfaces de usuario se necesita.

Esta actividad consta de las siguientes actividades:

Determinamos, adems, que las siguientes actividades no se realizarn en este caso

Estudio de Factibilidad: esta actividad se centra en evaluar si el sistema es

Validacin: consiste en revisar que los requerimientos realmente definen el

1. Establecimiento de objetivos, limitaciones y restricciones: Se definen los objetivos

Figura 10. Un ciclo de RUP con sus iteraciones.

El objetivo de esta fase de inicio es desarrollar el anlisis de negocio hasta el punto

Actividades de la fase de inicio:

Criterios de evaluacin para las 5 actividades ms importantes:

Requisitos Enumerar los requisitos candidatos a figurar en la lista de

Anlisis Anlisis de la arquitectura

Diseo Diseo de la arquitectura

Implementacin Prototipo de demostracin

Pruebas Desarrollo de planes provisionales de pruebas

Productos de esta fase:

La fase de transicin cubre el periodo durante el cual el producto se convierte en versiones

Actividades de la fase de transicin:

A continuacin, se prosigue a detallar el modelo de proceso elegido mediante un diagrama

Figura 13. Diagrama de actividades de la ingeniera de requerimientos en RUP.

(a) Identificar y definir Requerimientos de Usuario.

Requerimientos del Sistema:

El sistema de la Estacin Meteorolgica debe recolectar datos segn

El sistema debe poder actualizar remotamente el software embebido

El sistema debe contar con espacio de almacenamiento suficiente

AC VAN LAS ESPECIFICACIONES (dropbox, carpeta Requerimientos, archivo

(c) Construir Diagrama de Casos de Uso (o el diagrama que resultase equivalente en

[1] Ian Sommerville. SOFTWARE ENGINEERING. Ninth Edition.

Anda mungkin juga menyukai