Está en la página 1de 15

Instituto Profesional La Araucana

Apuntes de Ingeniería de Sistemas: VIII parte

Herramientas y Metodologías de Análisis y Diseño Estructurado


Introducción
El desarrollo de sistemas pequeños, 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
propagación de cambios en el sistema. Sin embargo, si el sistema es grande y en su desarrollo
participan varios grupos de personas desarrollando una tarea específica, hay que tener en cuenta no
solo la comunicación con el usuario sino también la inter-relación entre los distintos grupos de
trabajo.
Algunos de los problemas comunes que los desarrolladores encuentran en la construcción de
software de cierta complejidad son los siguientes:
 El dominio de aplicación no es conocido.
 La comunicación con el usuario.
 La comunicación con el grupo de desarrollo.
 La carencia de buena documentación.
Por esta razón, es necesario seguir una serie de pasos sistemáticos para que los diferentes grupos de
desarrollo posean una buena comunicación. Estos pasos son brindados por los modelos de ciclo de
vida, los cuales están constituidos por diferentes etapas:
Especificación de requerimientos: Se realizan entrevistas con el usuario identificando los
requerimientos y necesidades del usuario.
Análisis: Modela los requerimientos del usuario.
Diseño: Se modela la solución del sistema, teniendo en cuenta el ambiente de implementación a
utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje
de programación, performance deseada, etc.
Implementación: Dado el lenguaje de programación elegido se implementa el sistema.
Testeo o Prueba: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios
determinados por el grupo correspondiente.
Mantenimiento: Es la etapa más difícil de desarrollo del sistema, actualiza y modifica el sistema si
surgen nuevos requerimientos.
Existen varios métodos para describir el ciclo de vida de un sistema, uno de ellos es el desarrollo
estructurado en Cascada (fig. 1).

Especificación de
Requerimientos

Análisis
Qué?
?t?
Diseño

Cómo?
Implementación
Código
Testeo

Mantenimiento

Fig. 1 Modelo de Ciclo de Vida en Cascada

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 1


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
En un principio fue de gran utilidad pero el problema es que para pasar de una etapa a la otra había
que terminar la primera, produciendo un gran problema si algún cambio era requerido. La etapa de
Mantenimiento consumía el 80% del costo de producción.
Debido a los nuevos requerimientos en el desarrollo de software, surgieron muchos otros modelos
que trataban de solucionar los problemas existentes, los cuales se basaron en el modelo en Cascada.
Por ejemplo, el Modelo en Espiral, en el cual el sistema se desarrolla incrementalmente (fig.2).
Los modelos propuestos poseen básicamente las mismas etapas, pero varían en:
 los métodos y herramientas utilizadas en cada actividad,
 los controles requeridos, paralelismo en las actividades y
 en las salidas de cada etapa.

No es aconsejable elegir un modelo y seguirlo al detalle sino que se debe adaptar a las características
del proyecto que esta siendo desarrollado.
Los métodos de desarrollo de software pueden dividirse en dos grupos: función/dato y orientados a
objetos.

Orientado a Función/Dato . Orientado a Objetos .


Enfasis en la transformación de datos. Enfasis en la abstracción de datos.
Funciones y datos tratados como entidades Funciones y datos encapsulados en
separadas. entidades fuertemente relacionadas.
Difícil de entender y modificar. Facilidades de mantenimiento.
Funciones, usualmente, dependientes de la Mapeo directo a entidades del mundo real.
estructura de los datos.

Orientado a Función/Dato: Aquellos métodos en los cuales las funciones y/o los datos son tratados
como entidades independientes. Estos sistemas resultan difíciles de mantener. El mayor problema es
que las funciones generalmente dependen de la estructura de los datos. A menudo diferentes tipos de
datos tienen distintos formatos y se necesita verificar el tipo del dato (con sentencias If-Then o
Diseño
Implementación

Análisis

Test

Fig. 2 Modelo de Ciclo de Vida en Espiral


CASE), produciendo programas difíciles de leer y modificar. Si se desea hacer alguna modificación
en la estructura de los datos se debe modificar en todos los lugares donde es utilizado.
Otro problema es que una persona no piensa naturalmente en términos de una estructura. La
especificación de requerimientos se hace en lenguaje común, se especifica la funcionalidad que debe
tener el sistema y no en cómo se deben estructurar los datos.
Orientado a Objetos: Son aquellos métodos en los cuales datos y funciones están altamente
relacionados. El énfasis está centrado en la abstracción de datos. Se piensa en forma natural, los

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 2


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
objetos son mapeados a entidades del mundo real. Los programas son fácilmente mantenibles y
extensibles por medio de la construcción de subclases.
Varios métodos de desarrollo de software han sido propuestos para cada uno de estos grupo, algunos
de los cuales son descriptos en la fig. 3.

Métodos de Desarrollo
Software Developmentde Software
Methods

Orientado a Función/Dato
Function/Data Oriented Orientado a Objetos
Object Oriented

SS R
R S
S Booch
Booch OMT
OMT OOSE
OOSE
AA D
D A
A
D
D D
D //
TT S
S
D
D U PUML Catalysis
Catalysis

Fig. 3 Métodos de Desarrollo de Software

Donde:
SADT: Structured Analysis and Design Technique [Ross85]
RDD: Requirement Driven Design [Alford85]
SA/SD: Structured Analysis and Structured Design
[Yourdon&Constantine79]
OOSE: Object-Oriented Software Engineering [Jacobson94]
OOA: Object-Oriented Analysis [Goldberg]
OMT: Object Modelling Technique [Rumbaugh93]
UP: Unified Process [Booch&Jacobson&Rumbaugh98]
Catalysis: Catalysis [D’Souza98]

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 3


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Los Modelos del Sistema – Enfoque Estructurado

La siguiente figura describe todos los modelos desarrollados durante el ciclo de desarrollo de un sistema,
basándose en el enfoque estructurado. Abarca las actividades de Análisis y Diseño. La actividad de análisis se
construye el Modelo Esencial, en tanto la actividad de diseño construye el Modelo de Implementación.

Los Modelos del Análisis

El Modelo Esencial

Puede ser considerado como la aplicación de la metodología de Análisis EstructuradoModerno de Yourdon.


La idea fundamental con la que el modelo esencial es concebido es la de Tecnología Perfecta en la cual no
hay restricciones de cantidad de memoria, tamaño del disco o velocidad del procesador. Dos modelos
componen el modelo esencial:

 El Modelo del Ambiente: Declaración de los objetivos. Creación de un Diagrama de Contexto y de


una Lista de Eventos, describe los estímulos que recibe el sistema y las respuestas generadas por los
estímulos. Definición del Diccionario de Datos inicial. Tabla de Estimulo-Respuesta.
 El Modelo de Comportamiento: Creación 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 único DFD (el Modelo Funcional) y los ERDs
por eventos se unen en un único ERD (el Modelo de Datos). Se acostumbra, también, modelar el
comportamiento externo del sistema con DTE, árboles de pantallas o menúes, etc. La creación
simultánea del modelo de datos, modelo funcional y modelo de interfaz o comportamiento externo,
ayuda en la validación y completitud del modelo esencial (descubriendo, por ejemplo, eventos no
considerados).

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 4


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Todos los criterios de modelado y, principalmente de validación, descriptos en la metodología de Análisis
Estructurado Moderno pueden (y deben) ser aplicados en esta etapa para obtener un modelo esencial de
calidad y que sea consistente.

El Modelo de Implementación

A partir de esta etapa, el modelo esencial es instanciado en una tecnología dada. Se debe considerar ahora, las
imperfecciones de la tecnología y determinar: la cantidad de procesadores necesarios, las cualidades de estos
procesadores, el tamaño de disco necesario de acuerdo al volumen de la información a ser almacenada, etc.
Luego se diseña la solución sobre la base de esas restricciones tecnológicas.

La creación del modelo de implementación se fundamenta en la creación de tres modelos, uno de ellos en
forma independiente (el modelo de implementación usuario o de la interfaz hombre-máquina) y los otros dos
en forma encadenada en un proceso incremental de refinamiento e incorporación de detalles:

El Modelo de Implantación del Usuario

Es el punto de inflexión entre la etapa de análisis y la etapa de diseño. El modelo de implementación del
usuario especifica un conjunto de restricciones que el usuario deseará imponer al grupo de desarrollo y
condicionarán al diseñador.

Define la interfaz hombre-máquina que es modelada en todos sus detalles, estilo (árboles de menúes,
lenguajes de comandos, manipulación directa, etc.), layout y formato de pantallas, formato de informes y
listados, diseño de pantallas para el ingreso de datos y presentación de resultados, estilo de mensajes de error,
secuencialidad, etc.

La creación de este modelo es independiente del resto de los modelos que conforman el de implementación, y
puede ser desarrollado en paralelo. Las interfaces deben ser diseñadas para cada uno de los procesadores (del
modelo de procesadores) y para cada una de las tareas (del modelo de tareas).

Los aspectos más importantes que se especifican en el modelo de implementación del usuario son:

 Delimitación de la frontera de automatización: distribución del modelo esencial entre personas y


máquinas: el usuario puede tomar diferentes actitudes frente a este punto, pero lo que debe tenerse
presente es que siempre es el usuario el que finalmente tiene la responsabilidad de fijar la frontera de
automatización. El usuario puede fijar entre las siguientes alternativas:

 Al usuario no le interesa donde está la frontera de automatización, dejando librado al diseñador la


desición de establecerla.
 El usuario escoge un sistema totalmente automatizado
 El usuario escoge un sistema totalmente manual

 Detalle de la interacción humano-máquina: especifica todos los aspectos del diseño de la interfaz entre el
sistema y el entorno. Los aspectos mas importantes a considerar en este punto son:
 Elección de dispositivos de E/S
 Formato de las entradas que fluyen desde los terminadores hasta el sistema
 Formato de las salidas que fluyen desde el sistema hacia los terminadores
 Secuencia y tiempos de entradas y salidas en un sistema en línea, navegaciones de pantalla
 Métodos de codificación a utilizar para el ingreso de datos

 Actividades de apoyo manual que se podrían requerir: actividades ‘no esenciales’ que deben agregarse al
sistema por no disponerse de una tecnología perfecta e ideal. Pueden representarse como burbujas
adicionales en el modelo esencial. Los casos típicos son:

 Controles de posibles fallas humanas/técnicas (ingreso de datos al sistema, realización de cálculos,


dispositivos de almacenamiento, salida de datos del sistema)
 Operación del sistema en producción

 Restricciones operativas que el usuario desea imponer al sistema: son restricciones que afectarán la
configuración de hw, sistema operativo, telecomunicaciones, lenguaje de programación. Los aspectos
típicos son:
 Volumen de los datos

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 5


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
 Tiempo de respuesta en sistemas On-line
 Restricciones políticas sobre modalidades de implantación
 Restricciones ambientales
 Restricciones de seguridad y confiabilidad (mtbf, mttr)
 Restricciones de seguridad (controles de acceso al sistema)
 Agregado de procesos de arranque y apagado del sistema.

El Modelo de Distribución

Describe todas las decisiones relativas a la arquitectura de hardware (modelo de procesadores) y a la


estructuración general de la arquitectura de software (modelo de tareas). Se incorporan, en los modelos
creados hasta este punto algunas Distorsiones (requerimientos no esenciales) destinadas a optimizar el uso de
esa tecnología. El criterio fundamental es: Minimizar todo lo posible las distorsiones agregadas.

El Modelo de Procesadores

Asigna el modelo esencial a distintos procesadores y determina la arquitectura de comunicación entre ellos.
Implica la asignación de procesos y almacenes a los procesadores.

El modelo comportamental (modelo de datos, modelo funcional y modelo de comportamiento externo o de


interfaz) es subdividido por procesadores. Se aplican criterios cualitativos (por ejemplo: necesidad de
monitores de alta resolución gráfica) y cuantitativos (por ejemplo: velocidad del procesador, volumen de
información almacenada, etc.) para seleccionar los procesadores, sistemas operativos, software y hardware de
red, etc. Las distorsiones agregadas corresponden a la partición del DFD, ERD, DTE en procesadores,
refinamiento de procesos y entidades o depósitos de datos (para asociar parte en un procesador y parte en
otro) y a la incorporación de procesos para el control de la comunicación entre procesadores (siempre que la
tecnología no solucione el problema de manera transparente).

Según la cantidad de procesadores utilizados y las forma de comunicación entre ellos se tienen distintas
configuraciones.

Tipos de configuración típicas:


- Centralizada (host based)
- Descentralizada
- Mixta
- Distribuida / C-S

Centralizada: Asigna el modelo esencial completo a un único procesador central.


Descentralizada: Se asignan partes del modelo esencial a diferentes procesadores los cuales trabajan en
forma independiente.

En el caso de almacenes que deban ser compartidos por procesos asignados a diferentes procesadores, los
mismos deberán duplicarse, y mantenerse copias actualizadas en cada procesador.

Mixta: Puede darse una combinación de los casos anteriores. Es común la existencia de un sistema central
que consolida toda la información de la organización y que en diferentes unidades operativas que no este
conectadas a dicho procesador central existan sistemas satélites que implementan algunos procesos con
almacenes con datos locales.

Distribuida: Se asignan partes del modelo esencial a diferentes procesadores los cuales están comunicados de
alguna forma y sobre los que corre un sistema operativo distribuido. En este caso el usuario ve al conjunto de
procesadores como un único recurso computacional.

Cliente/Servidor: Se distribuyen partes del proceso en diferentes procesadores. El esquema más genérico de
distribución cliente-servidor distribuye el modelo del sistema en tres niveles: presentación, lógica del
negocio, y acceso a base de datos.

Los dos esquemas cliente-servidor más utilizados en la actualidad son:

 C/S 2 niveles: Servidor de B.D. / Aplicación-Presentación en Estación de Trabajo


 C/S 3 niveles: Servidor de B.D. / Servidor de Aplicación / Presentación en Est.Trab.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 6


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Tipos de configuración de comunicación entre procesadores:
o Conexión directa entre procesadores (canal / red local / otros)
o Enlace de telecomunicaciones entre procesadores
o Enlace indirecto: los datos son transferidos de un procesador a otro via algún medio de
almacenamiento (cinta, cd, dskte, etc)

Factores que influyen en la configuración de procesadores:


o Costo
o Eficiencia
o Seguridad (procesadores y datos en lugares seguros)
o Confiabilidad (separar los procesos en varios procesadores, proc.redundantes)
o Restricciones políticas y operacionales.

El Modelo de Tareas

Los modelos resultantes de la creación del modelo de procesadores son estudiados por separado (un
procesador por vez), para determinar tareas diferentes (que serán programas diferentes de manera tal que se
pueden ejecutar concurrentemente o no). La distorsión agregada en esta etapa representa la subdivisión del
modelo funcional 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 (comunicación solamente a través de
depósitos de datos), etc. Además, es probable que sea necesario agregar procesos de control de concurrencia y
sincronización para el acceso a recursos compartidos (como por ejemplo los depósitos de datos).

Dentro de cada procesador definido en el modelo anterior, deben asignarse procesos a diferentes tareas o
particiones.

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

Las tareas pueden categorizarse típicamente en Interactivas, Batch, y en Tiempo Real.

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

La comunicación 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 Diseño
Estructurado.

La estructura del programa que implementa cada una de las tareas resultantes de las etapas de modelado de
procesadores y tareas, es diseñada mediante la aplicación de las técnicas y estrategias descriptas por el
Diseño Estructurado (por ejemplo: Análisis de Transformaciones y Transacciones) y mejorada con la
aplicación de criterios de calidad (por ejemplo: Cohesión, Acoplamiento, etc.).

Secuencia de Creación de los Modelos

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 7


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte

MODELO FUNCIONAL.

CARACTERISTICAS GENERALES.

 El modelo funcional especifica lo que sucede, el modelo dinámico cuándo sucede, y el modelo de
objetos sobre qué entidades sucede.
 Define el significado de:

 Las operaciones y restricciones del Modelo de Objetos.

 Las acciones del Modelo Dinámico.

 Sólo expresa qué valores de salida se derivan de qué valores de entrada.

 Consta de múltiples DFD´ s que muestran el flujo de valores desde las entradas externas, pasando por
las operaciones y almacenes internos, hasta las salidas externas.

DIAGRAMAS DE FLUJOS DE DATOS (DFD'S).

 Notación clásica para definir el Modelo Funcional a través de múltiples DFDs.


 Un DFD muestra la relación funcional de los valores que calcula el sistema.

 Sus elementos fundamentales son:

Procesos.

Flujos de Datos (y en ocasiones, de control).

Entidades Externas (Actores).

Almacenes de Datos.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 8


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Ejemplo de DFD.

PROCESO.

Un proceso es una transformación de datos.

Los procesos de más bajo nivel son funciones puras sin efectos laterales.

Pueden especificarse matemáticamente o en lenguaje natural.

Un DFD entero puede verse como un proceso de más alto nivel.

El Sistema puede verse como un proceso que se va descomponiendo por niveles.

Los procesos definen patrones de entradas y salidas.

Se corresponden con operaciones de clases.

El objeto destino suele ser uno de los objetos de entrada, sobre todo si esa misma clase es también un
flujo de salida.

Se representan mediante elipses que contienen una descripción de la transformación, normalmente su


nombre.

ACTORES.

Son objetos activos que conducen el DFD produciendo o consumiendo sus valores (terminadores).

Definen los límites (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.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 9


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte

FLUJO DE DATOS.

Representan valores o conjuntos de valores que se transmiten de un cálculo a otro.

Conectan la salida de un actor o proceso con la entrada de otro.

Pueden descomponerse o duplicarse para ser entrada de diferentes procesos.

Varios flujos de datos pueden unirse en uno para convertirse en un dato agregado.

ALMACENES DE DATOS.

Objetos pasivos que almacenan datos.

Sólo responden a peticiones de obtener, eliminar o actualizar datos.

Suelen ser conjuntos de datos heterogéneos a los que se puede acceder en orden diferente al de inserción.

Se representan por un par de líneas paralelas que contienen el nombre del almacén.

FLUJOS DE CONTROL.

Un DFD no expresa relaciones temporales, de control, ni orden de ejecución. Sólo muestra los posibles
caminos de cómputo.

Existen funciones de decisión que no proporcionan datos pero sí son desencadenantes de otro proceso.

Un flujo de control es un valor lógico que expresa un evento necesario para un cálculo.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 10


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Sólo debemos usarlos cuando sean útiles, ya que duplican información del Modelo Dinámico.

Existen Métodos basados en DFD’s con notaciones extendidas para denotar el control, como CODARTS,
para diseño de sistemas de TR distribuidos.

 Niveles de descomposición de un DFD.


o El proceso de definición del Modelo Funcional es usualmente descendente (top-down).

o Cualquier proceso puede descomponerse como un nuevo DFD que detalla su


funcionamiento.

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

 Restricciones de un DFD.
o Muestran relaciones en un instante de tiempo:

 Entre dos objetos (Ej.: frecuencia y longitud de onda).

 Entre valores de un mismo objeto.

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 restricción sobre los valores (estado) de un objeto a lo largo del tiempo es un
invariante.

Ejemplo: una transformación de coordenadas podría especificar que el factor de escala para las
coordenadas x e y sea el mismo.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 11


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte

 Especificación de Operaciones.
o Cada proceso de bajo nivel es una operación en un objeto.

 Un proceso de más alto nivel puede también ser una operación.

 Las implementaciones pueden organizarse de otras maneras por motivos de


optimización.

o La especificación de una operación incluye:

 Signatura (interfaz): Parámetros y valores de retorno.

 Transformación: Efectos de la operación.

o Formas de Especificar Operaciones.

 Funciones matemáticas o lenguajes funcionales.

 Tablas de valores de E/S (si sus rangos son finitos y reducidos).

 Pre y postcondiciones de un sistema axiomático.

 Tablas de decisión.

 Pseudocódigo.

 Lenguaje natural.

 Consistencias con otros Modelos.

o Muchas veces, hay una correspondencia por niveles.

Un proceso de alto nivel se corresponde con una operación en un objeto compuesto, y sus
procesos de segundo nivel corresponden con operaciones sobre los objetos contenidos.

o Los Procesos indican relaciones funcionales entre clases.

De entre los flujos de datos entrantes a un Proceso, suele haber uno que es el objeto destino
de la operación, y los demás son parámetros, es decir, objetos que son utilizados por el objeto
destino. Se dice entonces que el objeto destino es un cliente de los demás, que son
proveedores.

o Los almacenes de datos son clases de objetos pasivos.

Si la entrada de un proceso viene de un almacén de datos, éste suele ser el destinatario de la


operación.

Si la salida de un proceso es un almacén de datos, el almacén es el objeto destino.

o Los actores son clases del Modelo de Objetos, y sus flujos de datos, operaciones.

Por su carácter activo, suelen necesitar una definición dinámica.

o Los flujos de datos son valores del M.O.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 12


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Bien sean datos básicos: números, cadenas, etc.

Bien objetos, que pueden ser los responsables de las operaciones que representan los
procesos o parámetros de operaciones sobre otros objetos.

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 13


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
Trabajo Práctico Nro. 1

Introducción a las Metodologías y a los Modelos de Ciclos de Vida

Lista de Conceptos Tratados:


Metodología de desarrollo de software; Modelo de ciclo de vida; Etapa; Rol; Modelo de características de un
sistema de software; Tipos de sistemas de software.

Ejercicio 1.1
Describa brevemente qué significan los siguientes términos:

a) Metodología de desarrollo de software.


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

Ejercicio 1.2
Describa brevemente en qué situaciones es imprescindible seguir una metodología, para el desarrollo de
software, y en cuáles situaciones no lo sería tanto.

Ejercicio 1.3
Enumere las categorías más comunes de metodologías existentes, para el desarrollo de software, junto con
sus características principales.

Ejercicio 1.4
Enumere los modelos de ciclo de vida más comunes, para el desarrollo de software, junto con sus
características principales.

Ejercicio 1.5
Enumere las etapas más comunes que comprenden los diferentes modelos de ciclo de vida existentes para el
desarrollo de software. Describa brevemente el propósito de cada una.

Ejercicio 1.6
Enumere los roles más comunes que puede cumplir una persona en el desarrollo de software. Describa
brevemente las responsabilidades principales de cada uno.

Ejercicio 1.7
Enumere los factores que influyen 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 aplicación es conocido, sus objetivos y requerimientos
funcionales son estables y simples de comprender desde un principio, la tecnología a utilizar ya esta
predeterminada y es bien conocida por el equipo de desarrollo. ¿Qué tipo de modelo de ciclo de vida elegiría
para el desarrollo de dicho sistema?.

Ejercicio 1.9
Una vez elegido el modelo de ciclo de vida, para el desarrollo del sistema planteado en el ejercicio anterior,
¿Qué etapas escogería 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 aplicación no es muy conocido por el equipo de
desarrollo. En este caso, el cliente tampoco tiene muy claro qué es lo que quiere, de manera que los objetivos
y requerimientos funcionales del sistema son inestables y difíciles de comprender. Además, el equipo de
desarrollo va a utilizar una tecnología que le resulta completamente nueva. Discuta qué modelo de ciclo de
vida es más apropiado y qué etapas se deberían utilizar para desarrollar este sistema.

Ejercicio 1.11
Considere ahora que el dominio del sistema a desarrollar es el de Control de Tráfico Ferroviario de una gran
ciudad. ¿En cuál de los tipos de sistemas que conoce ubicaría a este sistema?; ¿Qué tipo de metodología de

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 14


Instituto Profesional La Araucana
Apuntes de Ingeniería de Sistemas: VIII parte
desarrollo de software utilizaría en este caso?; ¿Por qué?; ¿Cuáles son los factores a tener en cuenta para
elegir este tipo de metodologías?.

Bibliografía de Apoyo Sugerida


 Herramientas de Análisis y Diseño Estructurado. Apunte de la cátedra Metodologías de Desarrollo de
Software I. C. Marcos y E. Belloni. DCyS, Fac. de Cs. Exactas, UNICEN.
 Metodología ASML – Dra. Claudia Marcos / Ing Edgardo Belloni – UNICEN
http://www.exa.unicen.edu.ar/
 “Análisis Estructurado Moderno” – Ed.Yourdon – ISBN: 9688803030

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 15