Apuntes Ingenieria Sistemas 4

Instituto ProIesional La Araucana
Ingenieria en Computacion e InIormatica

Apuntes de Ingenieria de Sistemas: IV parte
Ingenieria de Sistemas Sergio Merino M. smerinostpI(iplaaraucana.cl
1
Herramientas y Metodologas de Anlisis y Diseo Estructurado
Introduccin
El desarrollo de sistemas pequeos. en la cual participan una o dos personas. es una tarea simple.
Los cambios naturales que surgen durante el ciclo de desarrollo del sistema no producen una gran
propagacion de cambios en el sistema. Sin embargo. si el sistema es grande y en su desarrollo
participan varios grupos de personas desarrollando una tarea especiIica. hay que tener en cuenta no
solo la comunicacion con el usuario sino tambien la inter-relacion entre los distintos grupos de
trabaio.
Algunos de los problemas comunes que los desarrolladores encuentran en la construccion de
soItware de cierta compleiidad son los siguientes:
El dominio de aplicacion no es conocido.
La comunicacion con el usuario.
La comunicacion con el grupo de desarrollo.
La carencia de buena documentacion.
Por esta razon. es necesario seguir una serie de pasos sistematicos para que los diIerentes grupos de
desarrollo posean una buena comunicacion. Estos pasos son brindados por los modelos de ciclo de
vida. los cuales estan constituidos por diIerentes etapas:
Especificacin de requerimientos: Se realizan entrevistas con el usuario identiIicando los
requerimientos y necesidades del usuario.
Anlisis: Modela los requerimientos del usuario.
Diseo: Se modela la solucion del sistema. teniendo en cuenta el ambiente de implementacion a
utilizar. por eiemplo. si el sistema es centralizado o distribuido. la base de datos a utilizar. lenguaie
de programacion. perIormance deseada. etc.
Implementacin: Dado el lenguaie de programacion elegido se implementa el sistema.
Testeo o Prueba: En esta etapa se veriIica y valida el sistema teniendo en cuenta algunos criterios
determinados por el grupo correspondiente.
Mantenimiento: Es la etapa mas diIicil de desarrollo del sistema. actualiza y modiIica el sistema si
surgen nuevos requerimientos.

2
Existen varios metodos para describir el ciclo de vida de un sistema. uno de ellos es el desarrollo
estructurado en Cascada (Iig. 1).

En un principio Iue de gran utilidad pero el problema es que para pasar de una etapa a la otra habia
que terminar la primera. produciendo un gran problema si algun cambio era requerido. La etapa de
Mantenimiento consumia el 80 del costo de produccion.
Debido a los nuevos requerimientos en el desarrollo de soItware. surgieron muchos otros modelos
que trataban de solucionar los problemas existentes. los cuales se basaron en el modelo en Cascada.
Por eiemplo. el Modelo en Espiral. en el cual el sistema se desarrolla incrementalmente (Iig.2).
Los modelos propuestos poseen basicamente las mismas etapas. pero varian en:
los metodos y herramientas utilizadas en cada actividad.
los controles requeridos. paralelismo en las actividades y
en las salidas de cada etapa.

Especificacin de
Requerimientos
Anlisis
Diseo
Implementacin
Testeo
Mantenimiento
Q Qu u ? ?
C C m mo o? ?
Fig. 1 Modelo de Ciclo de Vida en Cascada
Anlisis
Diseo
Implementacin
Test
Fig. 2 Modelo de Ciclo de Vida en Espiral
3
No es aconseiable elegir un modelo y seguirlo al detalle sino que se debe adaptar a las caracteristicas
del proyecto que esta siendo desarrollado.
Los metodos de desarrollo de soItware pueden dividirse en dos grupos: Iuncion/dato y orientados a
obietos.

Orientado a Funcin/Dato: Aquellos metodos en los cuales las Iunciones y/o los datos son tratados
como entidades independientes. Estos sistemas resultan diIiciles de mantener. El mayor problema es
que las Iunciones generalmente dependen de la estructura de los datos. A menudo diIerentes tipos de
datos tienen distintos Iormatos y se necesita veriIicar el tipo del dato (con sentencias II-Then o
CASE). produciendo programas diIiciles de leer y modiIicar. Si se desea hacer alguna modiIicacion
en la estructura de los datos se debe modiIicar en todos los lugares donde es utilizado.
Otro problema es que una persona no piensa naturalmente en terminos de una estructura. La
especiIicacion de requerimientos se hace en lenguaie comun. se especiIica la Iuncionalidad que debe
tener el sistema y no en como se deben estructurar los datos.
Orientado a Objetos: Son aquellos metodos en los cuales datos y Iunciones estan altamente
relacionados. El enIasis esta centrado en la abstraccion de datos. Se piensa en Iorma natural. los
obietos son mapeados a entidades del mundo real. Los programas son Iacilmente mantenibles y
extensibles por medio de la construccion de subclases.
Varios metodos de desarrollo de soItware han sido propuestos para cada uno de estos grupo. algunos
de los cuales son descriptos en la Iig. 3.

E En nf fa as si is s e en n l la a t tr ra an ns sf fo or rm ma ac ci i n n d de e d da at to os s. .
F Fu un nc ci io on ne es s y y d da at to os s t tr ra at ta ad do os s c co om mo o
e en nt ti id da ad de es s s se ep pa ar ra ad da as s. .
D Di if f c ci il l d de e e en nt te en nd de er r y y m mo od di if fi ic ca ar r. .
F Fu un nc ci io on ne es s, , u us su ua al lm me en nt te e, , d de ep pe en nd di ie en nt te es s d de e
l la a e es st tr ru uc ct tu ur ra a d de e l lo os s d da at to os s. .
E En nf fa as si is s e en n l la a a ab bs st tr ra ac cc ci i n n d de e d da at to os s. .
F Fu un nc ci io on ne es s y y d da at to os s e en nc ca ap ps su ul la ad do os s e en n
e en nt ti id da ad de es s f fu ue er rt te em me en nt te e r re el la ac ci io on na ad da as s. .
F Fa ac ci il li id da ad de es s d de e m ma an nt te en ni im mi ie en nt to o. .
M Ma ap pe eo o d di ir re ec ct to o a a e en nt ti id da ad de es s d de el l m mu un nd do o
r re ea al l. .
Orientado a Funcin/Dato . Orientado a Objetos .
4
Donde:
SADT: Structured Analysis and Design Technique |Ross85|
RDD: Requirement Driven Design |AlIord85|
SA/SD: Structured Analysis and Structured Design
|Yourdon&Constantine79|
OOSE: Obiect-Oriented SoItware Engineering |Jacobson94|
OOA: Obiect-Oriented Analysis |Goldberg|
OMT: Obiect Modelling Technique |Rumbaugh93|
UP: UniIied Process |Booch&Jacobson&Rumbaugh98|
Catalysis: Catalysis |D`Souza98|

S
A
D
T
S S
A A
D D
T T
R
D
D
R R
D D
D D
S
A
/
S
D
S S
A A
/ /
S S
D D
Function/Data Oriented
O Or ri ie en nt ta ad do o a a F Fu un nc ci i n n/ /D Da at to o
Booch Booch Booch
OOSE OOSE OOSE
OMT OMT OMT
UML U U P P Catalysis
C Ca at ta al ly ys si is s
Object Oriented
O Or ri ie en nt ta ad do o a a O Ob bj je et to os s
Software Development Methods
M M t to od do os s d de e D De es sa ar rr ro ol ll lo o d de e S So of ft tw wa ar re e
Fig. 3 Mtodos de Desarrollo de Software
5
Los Modelos del Sistema - Enfoque Estructurado

La siguiente Iigura describe todos los modelos desarrollados durante el ciclo de desarrollo de un sistema.
basandose en el enIoque estructurado. Abarca las actividades de Analisis y Diseo. La actividad de analisis se
construye el Modelo Esencial. en tanto la actividad de diseo construye el Modelo de Implementacion.

Los Modelos del Anlisis

El Modelo Esencial

Puede ser considerado como la aplicacion de la metodologia de Analisis EstructuradoModerno de Yourdon.
La idea Iundamental con la que el modelo esencial es concebido es la de Tecnologia Perfecta en la cual no
hay restricciones de cantidad de memoria. tamao del disco o velocidad del procesador. Dos modelos
componen el modelo esencial:
6

El Modelo del Ambiente: Declaracion de los obietivos. Creacion de un Diagrama de Contexto y de
una Lista de Eventos. describe los estimulos que recibe el sistema y las respuestas generadas por los
estimulos. DeIinicion del Diccionario de Datos inicial. Tabla de Estimulo-Respuesta.
El Modelo de Comportamiento: Creacion de un DFD. y un ERD por cada uno de los eventos de la
Lista de Eventos. Los DFDs por eventos se unen en un unico DFD (el Modelo Funcional) y los ERDs
por eventos se unen en un unico ERD (el Modelo de Datos). Se acostumbra. tambien. modelar el
comportamiento externo del sistema con DTE. arboles de pantallas o menues. etc. La creacion
simultanea del modelo de datos. modelo Iuncional y modelo de interIaz o comportamiento externo.
ayuda en la validacion y completitud del modelo esencial (descubriendo. por eiemplo. eventos no
considerados).

Todos los criterios de modelado y. principalmente de validacion. descriptos en la metodologia de Analisis
Estructurado Moderno pueden (y deben) ser aplicados en esta etapa para obtener un modelo esencial de
calidad y que sea consistente.

El Modelo de Implementacin

A partir de esta etapa. el modelo esencial es instanciado en una tecnologia dada. Se debe considerar ahora. las
imperIecciones de la tecnologia y determinar: la cantidad de procesadores necesarios. las cualidades de estos
procesadores. el tamao de disco necesario de acuerdo al volumen de la inIormacion a ser almacenada. etc.
Luego se disea la solucion sobre la base de esas restricciones tecnologicas.

La creacion del modelo de implementacion se Iundamenta en la creacion de tres modelos. uno de ellos en
Iorma independiente (el modelo de implementacion usuario o de la interIaz hombre-maquina) y los otros dos
en Iorma encadenada en un proceso incremental de reIinamiento e incorporacion de detalles:

El Modelo de Implantacin del Usuario

Es el punto de inIlexion entre la etapa de analisis y la etapa de diseo. El modelo de implementacion del
usuario especiIica un coniunto de restricciones que el usuario deseara imponer al grupo de desarrollo y
condicionaran al diseador.

DeIine la interIaz hombre-maquina que es modelada en todos sus detalles. estilo (arboles de menues.
lenguaies de comandos. manipulacion directa. etc.). layout y Iormato de pantallas. Iormato de inIormes y
listados. diseo de pantallas para el ingreso de datos y presentacion de resultados. estilo de mensaies de error.
secuencialidad. etc.

La creacion de este modelo es independiente del resto de los modelos que conIorman el de implementacion. y
puede ser desarrollado en paralelo. Las interIaces deben ser diseadas para cada uno de los procesadores (del
modelo de procesadores) y para cada una de las tareas (del modelo de tareas).

Los aspectos mas importantes que se especiIican en el modelo de implementacion del usuario son:

Delimitacion de la frontera de automatizacion. distribucion del modelo esencial entre personas y
maquinas: el usuario puede tomar diIerentes actitudes Irente a este punto. pero lo que debe tenerse
presente es que siempre es el usuario el que Iinalmente tiene la responsabilidad de Iiiar la Irontera de
automatizacion. El usuario puede Iiiar entre las siguientes alternativas:

7
Al usuario no le interesa donde esta la Irontera de automatizacion. deiando librado al diseador la
desicion de establecerla.
El usuario escoge un sistema totalmente automatizado
El usuario escoge un sistema totalmente manual

Detalle de la interaccion humano-maquina. especiIica todos los aspectos del diseo de la interIaz entre el
sistema y el entorno. Los aspectos mas importantes a considerar en este punto son:
Eleccion de dispositivos de E/S
Formato de las entradas que Iluyen desde los terminadores hasta el sistema
Formato de las salidas que Iluyen desde el sistema hacia los terminadores
Secuencia y tiempos de entradas y salidas en un sistema en linea. navegaciones de pantalla
Metodos de codiIicacion a utilizar para el ingreso de datos

Actividades de apovo manual que se podrian requerir. actividades no esenciales` que deben agregarse al
sistema por no disponerse de una tecnologia perIecta e ideal. Pueden representarse como burbuias
adicionales en el modelo esencial. Los casos tipicos son:

Controles de posibles Iallas humanas/tecnicas (ingreso de datos al sistema. realizacion de calculos.
dispositivos de almacenamiento. salida de datos del sistema)
Operacion del sistema en produccion

Restricciones operativas que el usuario desea imponer al sistema. son restricciones que aIectaran la
conIiguracion de hw. sistema operativo. telecomunicaciones. lenguaie de programacion. Los aspectos
tipicos son:
Volumen de los datos
Tiempo de respuesta en sistemas On-line
Restricciones politicas sobre modalidades de implantacion
Restricciones ambientales
Restricciones de seguridad y conIiabilidad (mtbI. mttr)
Restricciones de seguridad (controles de acceso al sistema)
Agregado de procesos de arranque y apagado del sistema.

El Modelo de Distribucin

Describe todas las decisiones relativas a la arquitectura de hardware (modelo de procesadores) y a la
estructuracion general de la arquitectura de soItware (modelo de tareas). Se incorporan. en los modelos
creados hasta este punto algunas Distorsiones (requerimientos no esenciales) destinadas a optimizar el uso de
esa tecnologia. El criterio Iundamental es: Minimizar todo lo posible las distorsiones agregadas.

El Modelo de Procesadores

Asigna el modelo esencial a distintos procesadores y determina la arquitectura de comunicacion entre ellos.
Implica la asignacion de procesos y almacenes a los procesadores.

El modelo comportamental (modelo de datos. modelo Iuncional y modelo de comportamiento externo o de
interIaz) es subdividido por procesadores. Se aplican criterios cualitativos (por eiemplo: necesidad de
monitores de alta resolucion graIica) y cuantitativos (por eiemplo: velocidad del procesador. volumen de
inIormacion almacenada. etc.) para seleccionar los procesadores. sistemas operativos. soItware y hardware de
red. etc. Las distorsiones agregadas corresponden a la particion del DFD. ERD. DTE en procesadores.
8
reIinamiento de procesos y entidades o depositos de datos (para asociar parte en un procesador y parte en
otro) y a la incorporacion de procesos para el control de la comunicacion entre procesadores (siempre que la
tecnologia no solucione el problema de manera transparente).

Segun la cantidad de procesadores utilizados y las Iorma de comunicacion entre ellos se tienen distintas
conIiguraciones.

Tipos de configuracion tipicas.
- Centralizada (host based)
- Descentralizada
- Mixta
- Distribuida / C-S

Centralizada. Asigna el modelo esencial completo a un unico procesador central.
Descentralizada. Se asignan partes del modelo esencial a diIerentes procesadores los cuales trabaian en
Iorma independiente.

En el caso de almacenes que deban ser compartidos por procesos asignados a diIerentes procesadores. los
mismos deberan duplicarse. y mantenerse copias actualizadas en cada procesador.

Mixta. Puede darse una combinacion de los casos anteriores. Es comun la existencia de un sistema central
que consolida toda la inIormacion de la organizacion y que en diIerentes unidades operativas que no este
conectadas a dicho procesador central existan sistemas satelites que implementan algunos procesos con
almacenes con datos locales.

Distribuida. Se asignan partes del modelo esencial a diIerentes procesadores los cuales estan comunicados de
alguna Iorma y sobre los que corre un sistema operativo distribuido. En este caso el usuario ve al coniunto de
procesadores como un unico recurso computacional.

Cliente/Servidor. Se distribuyen partes del proceso en diIerentes procesadores. El esquema mas generico de
distribucion cliente-servidor distribuye el modelo del sistema en tres niveles: presentacion. logica del
negocio. y acceso a base de datos.

Los dos esquemas cliente-servidor mas utilizados en la actualidad son:

C/S 2 niveles: Servidor de B.D. / Aplicacion-Presentacion en Estacion de Trabaio
C/S 3 niveles: Servidor de B.D. / Servidor de Aplicacion / Presentacion en Est.Trab.

Tipos de configuracion de comunicacion entre procesadores.
o Conexion directa entre procesadores (canal / red local / otros)
o Enlace de telecomunicaciones entre procesadores
o Enlace indirecto: los datos son transIeridos de un procesador a otro via algun medio de
almacenamiento (cinta. cd. dskte. etc)

Factores que influven en la configuracion de procesadores.
o Costo
o EIiciencia
o Seguridad (procesadores y datos en lugares seguros)
o ConIiabilidad (separar los procesos en varios procesadores. proc.redundantes)
o Restricciones politicas y operacionales.
9

El Modelo de 1areas

Los modelos resultantes de la creacion del modelo de procesadores son estudiados por separado (un
procesador por vez). para determinar tareas diIerentes (que seran programas diIerentes de manera tal que se
pueden eiecutar concurrentemente o no). La distorsion agregada en esta etapa representa la subdivision del
modelo Iuncional de un procesador (el DFD) en distintos DFDs (uno por tarea) agrupando procesos batch.
interactivos o de tiempo real. partes del DFD aisladas del resto (comunicacion solamente a traves de
depositos de datos). etc. Ademas. es probable que sea necesario agregar procesos de control de concurrencia
y sincronizacion para el acceso a recursos compartidos (como por eiemplo los depositos de datos).

Dentro de cada procesador deIinido en el modelo anterior. deben asignarse procesos a diIerentes tareas o
particiones.

En muchos sistemas operativos modernos. el maneio de tareas es transparente al desarrollador.

Las tareas pueden categorizarse tipicamente en Interactivas. Batch. y en Tiempo Real.

Para la mayoria de los sistemas administrativos es importante determinar que partes del modelo esencial se
asignaran a tareas interactivas y cuales a tareas batch.

La comunicacion entre tareas normalmentes es provista via el sistema operativo.

El Modelo de Programas

Para cada tarea debe desarrollarse un modelo de programa. De esto se encarga principalmente el Diseo
Estructurado.

La estructura del programa que implementa cada una de las tareas resultantes de las etapas de modelado de
procesadores y tareas. es diseada mediante la aplicacion de las tecnicas y estrategias descriptas por el Diseo
Estructurado (por eiemplo: Analisis de TransIormaciones y Transacciones) y meiorada con la aplicacion de
criterios de calidad (por eiemplo: Cohesion. Acoplamiento. etc.).

Secuencia de Creacin de los Modelos
10

MODELO FUNCIONAL
CARAC1ERIS1ICAS CEAERALES.
El modelo Iuncional especiIica lo que sucede. el modelo dinamico cuando sucede. y el modelo de
obietos sobre que entidades sucede.
DeIine el signiIicado de:
Las operaciones y restricciones del Modelo de Obietos.
Las acciones del Modelo Dinamico.
Solo expresa que valores de salida se derivan de que valores de entrada.
Consta de multiples DFD s que muestran el Iluio de valores desde las entradas externas. pasando por
las operaciones y almacenes internos. hasta las salidas externas.
DIACRAMAS DE FLU1OS DE DA1OS (DFD'S).
Notacion clasica para deIinir el Modelo Funcional a traves de multiples DFDs.
Un DFD muestra la relacion Iuncional de los valores que calcula el sistema.
Sus elementos Iundamentales son:
Procesos.
11
Fluios de Datos (y en ocasiones. de control).
Entidades Externas (Actores).
Almacenes de Datos.
Ejemplo de DFD.

PROCESO.
Un proceso es una transIormacion de datos.
Los procesos de mas baio nivel son Iunciones puras sin eIectos laterales.
Pueden especiIicarse matematicamente o en lenguaie natural.
Un DFD entero puede verse como un proceso de mas alto nivel.
El Sistema puede verse como un proceso que se va descomponiendo por niveles.
Los procesos deIinen patrones de entradas y salidas.
Se corresponden con operaciones de clases.
El obieto destino suele ser uno de los obietos de entrada. sobre todo si esa misma clase es tambien un
Iluio de salida.
Se representan mediante elipses que contienen una descripcion de la transIormacion. normalmente su
nombre.
12

ACTORES.
Son obietos activos que conducen el DFD produciendo o consumiendo sus valores (terminadores).
DeIinen los limites (el contexto) del sistema.
Pueden ser usuarios del sistema.
O elementos hardware en Sistemas de TR.
Representados por un cuadrado con el nombre del actor.

FLU1O DE DATOS.
Representan valores o coniuntos de valores que se transmiten de un calculo a otro.
Conectan la salida de un actor o proceso con la entrada de otro.
Pueden descomponerse o duplicarse para ser entrada de diIerentes procesos.
Varios Iluios de datos pueden unirse en uno para convertirse en un dato agregado.

ALMACENES DE DATOS.
Obietos pasivos que almacenan datos.
13
Solo responden a peticiones de obtener. eliminar o actualizar datos.
Suelen ser coniuntos de datos heterogeneos a los que se puede acceder en orden diIerente al de insercion.
Se representan por un par de lineas paralelas que contienen el nombre del almacen.

FLU1OS DE CONTROL.
Un DFD no expresa relaciones temporales. de control. ni orden de eiecucion. Solo muestra los posibles
caminos de computo.
Existen Iunciones de decision que no proporcionan datos pero si son desencadenantes de otro proceso.
Un Iluio de control es un valor logico que expresa un evento necesario para un calculo.
Solo debemos usarlos cuando sean utiles. ya que duplican inIormacion del Modelo Dinamico.
Existen Metodos basados en DFD`s con notaciones extendidas para denotar el control. como CODARTS.
para diseo de sistemas de TR distribuidos.
14

Aiveles de descomposicin de un DFD.
o El proceso de deIinicion del Modelo Funcional es usualmente descendente (top-down).
o Cualquier proceso puede descomponerse como un nuevo DFD que detalla su
Iuncionamiento.
o Cada entrada o salida del proceso debe existir en el nuevo DFD.
o El nuevo DFD puede contener Almacenes que no se mostraban en el DFD de nivel superior.
o Podemos estudiar separadamente cada DFD en cualquier nivel del arbol.

Restricciones de un DFD.
o Muestran relaciones en un instante de tiempo:
Entre dos obietos (Ei.: Irecuencia y longitud de onda).
Entre valores de un mismo obieto.
o Estas relaciones pueden ser:
Funciones totales: un valor se calcula a partir del otro.
Funciones parciales: un valor impone restricciones al otro.
o Una restriccion sobre los valores (estado) de un obieto a lo largo del tiempo es un
invariante.
Eiemplo: una transIormacion de coordenadas podria especiIicar que el Iactor de escala para las
coordenadas x e v sea el mismo.

Especificacin de Operaciones.
o Cada proceso de baio nivel es una operacion en un obieto.
15
Un proceso de mas alto nivel puede tambien ser una operacion.
Las implementaciones pueden organizarse de otras maneras por motivos de
optimizacion.
o La especiIicacion de una operacion incluye:
Signatura (interIaz): Parametros y valores de retorno.
TransIormacion: EIectos de la operacion.
o Formas de EspeciIicar Operaciones.
Funciones matematicas o lenguaies Iuncionales.
Tablas de valores de E/S (si sus rangos son Iinitos y reducidos).
Pre y postcondiciones de un sistema axiomatico.
Tablas de decision.
Pseudocodigo.
Lenguaie natural.
Consistencias con otros Modelos.
o Muchas veces. hay una correspondencia por niveles.
Un proceso de alto nivel se corresponde con una operacion en un obieto compuesto. y sus
procesos de segundo nivel corresponden con operaciones sobre los obietos contenidos.
o Los Procesos indican relaciones Iuncionales entre clases.
De entre los Iluios de datos entrantes a un Proceso. suele haber uno que es el obieto destino
de la operacion. y los demas son parametros. es decir. obietos que son utilizados por el obieto
destino. Se dice entonces que el obieto destino es un cliente de los demas. que son
proveedores.

o Los almacenes de datos son clases de obietos pasivos.
Si la entrada de un proceso viene de un almacen de datos. este suele ser el destinatario de la
operacion.
Si la salida de un proceso es un almacen de datos. el almacen es el obieto destino.
o Los actores son clases del Modelo de Obietos. y sus Iluios de datos. operaciones.
Por su caracter activo. suelen necesitar una deIinicion dinamica.
o Los Iluios de datos son valores del M.O.
Bien sean datos basicos: numeros. cadenas. etc.
Bien obietos. que pueden ser los responsables de las operaciones que representan los
procesos o parametros de operaciones sobre otros obietos.

16
Trabajo Prctico Nro. 1

Introduccin a las Metodologas y a los Modelos de Ciclos de Vida

Lista de Conceptos Tratados:
Metodologia de desarrollo de soItware; Modelo de ciclo de vida; Etapa; Rol; Modelo de caracteristicas de un
sistema de soItware; Tipos de sistemas de soItware.

Ejercicio 1.1
Describa brevemente que signiIican los siguientes terminos:

a) Metodologa de desarrollo de soItware.
b) Modelo de Ciclo de Vida para el desarrollo de soItware.
c) Etapa dentro de un ciclo de vida.
d) Rol que puede cumplir una persona en el desarrollo de soItware.
e) Modelo/Diagrama de las caracteristicas de un sistema de soItware y sus partes componentes.

Ejercicio 1.2
Describa brevemente en que situaciones es imprescindible seguir una metodologia. para el desarrollo de
soItware. y en cuales situaciones no lo seria tanto.

Ejercicio 1.3
Enumere las categorias mas comunes de metodologias existentes. para el desarrollo de soItware. iunto con
sus caracteristicas principales.

Ejercicio 1.4
Enumere los modelos de ciclo de vida mas comunes. para el desarrollo de soItware. iunto con sus
caracteristicas principales.

Ejercicio 1.5
Enumere las etapas mas comunes que comprenden los diIerentes modelos de ciclo de vida existentes para el
desarrollo de soItware. Describa brevemente el proposito de cada una.

Ejercicio 1.6
Enumere los roles mas comunes que puede cumplir una persona en el desarrollo de soItware. Describa
brevemente las responsabilidades principales de cada uno.

Ejercicio 1.7
Enumere los Iactores que inIluyen a la hora de elegir un modelo de ciclo de vida para el desarrollo de un
sistema.

Ejercicio 1.8
Considere el desarrollo de un sistema cuyo dominio de aplicacion es conocido. sus obietivos y requerimientos
Iuncionales son estables y simples de comprender desde un principio. la tecnologia a utilizar ya esta
predeterminada y es bien conocida por el equipo de desarrollo. Que tipo de modelo de ciclo de vida elegiria
para el desarrollo de dicho sistema?.

Ejercicio 1.9
17
Una vez elegido el modelo de ciclo de vida. para el desarrollo del sistema planteado en el eiercicio anterior.
Que etapas escogeria para dicho modelo de ciclo de vida. teniendo en cuenta que el desarrollo lo realizan
una o pocas personas?.

Ejercicio 1.10
Considere ahora el desarrollo de un sistema cuyo dominio de aplicacion no es muy conocido por el equipo de
desarrollo. En este caso. el cliente tampoco tiene muy claro que es lo que quiere. de manera que los obietivos
y requerimientos Iuncionales del sistema son inestables y diIiciles de comprender. Ademas. el equipo de
desarrollo va a utilizar una tecnologia que le resulta completamente nueva. Discuta que modelo de ciclo de
vida es mas apropiado y que etapas se deberian utilizar para desarrollar este sistema.

Ejercicio 1.11
Considere ahora que el dominio del sistema a desarrollar es el de Control de TraIico Ferroviario de una gran
ciudad. En cual de los tipos de sistemas que conoce ubicaria a este sistema?; Que tipo de metodologia de
desarrollo de soItware utilizaria en este caso?; Por que?; Cuales son los Iactores a tener en cuenta para
elegir este tipo de metodologias?.

Bibliografa de Apoyo Sugerida
Herramientas de Analisis y Diseo Estructurado. Apunte de la catedra Metodologias de Desarrollo de
SoItware I. C. Marcos y E. Belloni. DCyS. Fac. de Cs. Exactas. UNICEN.
Metodologia ASML Dra. Claudia Marcos / Ing Edgardo Belloni UNICEN
http://www.exa.unicen.edu.ar/
'Analisis Estructurado Moderno Ed.Yourdon ISBN: 9688803030

Apuntes Ingenieria Sistemas 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apuntes Ingenieria Sistemas 4

Uploaded by

Copyright:

Available Formats

Instituto ProIesional La Araucana

Ingenieria en Computacion e InIormatica

You might also like