Embed Size (px)
DESCRIPTION
nvvjgbhjgh
Citation preview
1
Fundamentos de desarrollo de sistemas
INSTITUTO TECNOLÓGICO
DE ACAPULCO
Profesor. Daniel Solís Chávez
Integrantes del Equipo:
Ana Alexis Vargas Beltrán
No. De control 09320776
Basilio Isaac Moctezuma Saucedo
No. De control 09320746
Luis Antonio Huerta Silva
No. de control 09320741
Manuel Pérez Nava
No. De control 09320787
Horario: Lunes a Viernes de 11:00-12:00 pm.
Acapulco Gro. A 17 de Mayo del 2012
INGENIERIA EN SISTEMAS
COMPUTACIONALES
2
ÍNDICE DE CONTENIDO
UNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE ........................ 3
3.1 EL ENFOQUE ESTRUCTURADO .................................................................... 4
3.1.1 DIAGRAMAS DE FLUJOS DE DATOS. .............................................. 5
3.1.2 DICCIONARIOS DE DATOS. ............................................................ 13
3.1.3 DISEÑO DE MÓDULOS .................................................................... 18
3.1.4 DESCOMPOSICIÓN EN PROCESOS .............................................. 21
3.2 EL ENFOQUE ORIENTADO A OBJETOS ...................................................... 23
3.2.1 ANÁLISIS. .......................................................................................... 27
3.2.2 DISEÑO. ............................................................................................ 30
UNIDAD IV MODELOS DEL PROCESO DE SOFTWARE................................... 34
4.1 MODELO DE CASCADA ................................................................................. 35
4.2 MODELO DE ESPIRAL ................................................................................... 40
4.3 MODELO INCREMENTAL .............................................................................. 42
4.4 PROCESO DE DESARROLLO UNIFICADO .................................................. 45
4.5 PROCESO SOFTWARE PERSONAL ............................................................. 47
BIBLIOGRAFÍA .................................................................................................... 50
3
UNIDAD III
PARADIGMAS DE LA INGENIERÍA DE SOFTWARE
La ingeniería de software está compuesta por una serie de pasos de
abarcan los métodos, las herramientas y los procedimientos, estos pasos se
denominan frecuentemente paradigmas de la ingeniería de software. La elección
de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la
naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los
controles y entregas requeridos.
En un nivel técnico, la ingeniería del software empieza con una serie de tareas
de modelado que llevan a una especificación completa de los requisitos y a una
representación del diseño general del software a construir.
El modelo de análisis, realmente un conjunto de modelos, es la primera
representación técnica de un sistema. Con los años se han propuesto muchos
métodos para el modelado del análisis. Sin embargo, ahora dos tendencias
dominan el panorama del modelado del análisis. El primero, análisis estructurado,
es un método de modelado clásico. El otro enfoque, análisis orientado a objetos.
El análisis estructurado es una actividad de construcción de modelos. Mediante
una notación que satisfaga los principios de análisis operacional, creamos
modelos que representan el contenido y flujo de la información (datos y control);
partimos el sistema funcionalmente, y según los distintos comportamientos
establecemos la esencia de lo que se debe construir. El análisis estructurado no
es un método sencillo aplicado siempre de la misma forma por todos los que lo
usan.
Un paradigma de programación es un modelo básico de diseño y desarrollo
de programas, que permite producir programas con una directriz específica, tales
como: estructura modular, fuerte cohesión, alta rentabilidad, etc.
4
Existen tres categorías de paradigmas de programación:
a) Los que soportan técnicas de programación de bajo nivel (ejemplo: copia de
ficheros frente estructuras de datos compartidos)
b) Los que soportan métodos de diseño de algoritmos (ejemplo: divide y
vencerás, programación dinámica, etc.)
c) Los que soportan soluciones de programación de alto nivel, como los
descritos en el punto anterior
Los paradigmas relacionados con la programación de alto nivel se agrupan en tres
categorías de acuerdo con la solución que aportan para resolver el problema:
a) Solución procedimental u operacional. Describe etapa a etapa el modo de
construir la solución. Es decir señala la forma de obtener la solución.
b) Solución demostrativa. Es una variante de la procedimental. Especifica la
solución describiendo ejemplos y permitiendo que el sistema generalice la
solución de estos ejemplos para otros casos. Aunque es fundamentalmente
procedimental, el hecho de producir resultados muy diferentes a ésta, hace
que sea tratada como una categoría separada.
c) Solución declarativa. Señala las características que debe tener la solución,
sin describir cómo procesarla. Es decir señala qué se desea obtener pero
no cómo obtenerlo.
3.1 EL ENFOQUE ESTRUCTURADO
La primera aparición del enfoque de análisis estructurado fue como
complemento de otro tema importante - el «diseño estructurado»-. Los
investigadores, necesitaban una notación gráfica para representar los datos y los
procesos que los transforman. Esos procesos quedarían finalmente establecidos
en una arquitectura de diseño.
5
En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos)
como principal herramienta para entender al sistema antes de plasmarlo a código
fuente. DFD es un diagrama en el q participan procesos (métodos), flujo de datos
(argumentos) y archivos (base de datos).
Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. Otra
desventaja es que una porción de código en lenguaje estructurado es difícil que
pueda servir en otros proyectos.
3.1.1 DIAGRAMAS DE FLUJOS DE DATOS.
A medida que la información se mueve a través del software, es modificada por
una serie de transformaciones.
El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la
información y las transformaciones que se aplican a los datos al moverse desde la
entrada hasta la salida. En la Figura 3.1 se muestra la forma básica de un
diagrama de flujo de datos. El DFD es también conocido como grafo de flujo de
datos o como diagrama de burbujas.
6
Figura 3.1 Refinamiento del flujo de información
Un diagrama de flujo de datos (DFD) es una representación gráfica de los
procesos que se realizan con los datos en su organización, con el uso de tan solo
cuatro símbolos, se puede crear una descripción grafica de los procesos que, con
el tiempo, contribuirán a desarrollar una sólida documentación del sistema.
Se puede usar el diagrama de flujo de datos para representar un sistema o
un software a cualquier nivel de abstracción. De hecho, los DFDs pueden ser
divididos en niveles que representen un mayor flujo de información y un mayor
detalle funcional. Por consiguiente, el DFD proporciona un mecanismo para el
modelado funcional, así como el modelado del flujo de información. Al hacer esto,
se cumple el segundo principio de análisis operacional.
Un DFD de nivel O, también denominado modelo fundamental del sistema o
modelo de contexto, representa al elemento de software completo como una sola
burbuja con datos de entrada y de salida representados por flechas de entrada y
de salida, respectivamente. Al dividir el DFD de nivel O para mostrar más detalles,
aparecen representados procesos (burbujas) y caminos de flujo de información
adicionales.
La notación básica que se usa para desarrollar un DFD no es en sí misma
suficiente para describir los requisitos del software.
En seguida mencionan las ventajas sobre las explicaciones descriptivas en
relación con la forma en que los datos se mueven a través del sistema:
7
1. Libertad para emprender la implementación técnica del sistema en las
primeras etapas.
2. Comprensión más profunda de la interrelación entre sistemas y
subsistemas.
3. Comunicación con los usuarios sobre el conocimiento del sistema actual
mediante diagramas de flujos de datos.
4. Análisis de un sistema propuesto para determinar si se han definido los
datos y procesos necesarios.
La ventaja más grande es la libertad conceptual para utilizar los cuatro
símbolos, los DFD’s hacen énfasis en el procesamiento o la transformación
conforme estos pasan por una variedad de procesos. En los DFD’s lógicos no hay
distinción entre procesos manuales o automatizados. Los procesos tampoco se
representan gráficamente en orden cronológico. En vez de ello, se agrupan solo si
el análisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se
agrupan, y los procesos automatizados también se pueden agrupar.
3.1.1.1 Simbología
En los diagramas de flujos de datos se usan cuatro símbolos básicos para
graficar el movimiento de los datos: Un cuadrado doble, una flecha, un rectángulo
con esquinas redondeadas(o una burbuja) y un rectángulo abierto (cerrado en el
lado izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a
continuación. Con la combinación de estos cuatro símbolos se puede describir
gráficamente un sistema completo y varios subsistemas.
8
El cuadrado doble se usa para describir una entidad externa que puede enviar
datos al sistema o recibirlos de él. La entidad externa, o solo entidad, también se
llama origen o destino de datos, y se considera externa al sistema descrito. A cada
entidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, se
considera fuera de los límites de este. La misma entidad se podría usar más de
una vez en un diagrama de flujo de datos en particular para evitar que las líneas
se crucen en el flujo de datos.
La flecha muestra el movimiento de los datos de un punto a otro, con la punta de
la flecha señalando hacia el destino de los datos. Los flujos de datos que ocurren
simultáneamente se pueden describir mediante flechas paralelas. Una flecha
también puede se debe describir con un nombre, debido a que representan los
datos de un apersona, lugar o cosa.
Rectángulo con esquinas redondeadas se usa para mostrar la presencia de un
proceso de transformación. Los procesos siempre denotan un cambio en los datos
o una transformación de estos; por lo tanto el flujo de datos que sale de un
proceso siempre se designa de forma diferente al que entra en el. Los procesos
representan trabajo que se realiza en el tema.
A un proceso se le debe de asignar un número de identificación único y
exclusivo, que indique su nivel en el diagrama. Podría haber varios flujos
de datos que entren y salgan de cada proceso. Los procesos con solo un
9
flujo de entrada y salida se deben examinar en busca de flujos de datos
perdidos.
El rectángulo abierto representa un almacén de datos. Estos símbolos se dibujan
con el espacio suficiente para que quepan las letras de identificación como se
muestra en la figura. En los diagramas de flujo de datos lógicos no se especifica el
tipo de almacenamiento a un lugar. En este punto el símbolo del almacén de
datos simplemente muestra un lugar de depósito para los datos que permite
examinar, agregar y recuperar datos.
3.1.1.2 Desarrollo de Diagramas de Flujos de Datos
Los diagramas de flujos de datos se pueden y deben dibujar de manera
sistemática. Primero se deben visualizar los flujos de datos desde una perspectiva
jerárquica de arriba a bajo. En seguida se describen los pasos a seguir.
Lista de actividades
Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa
del sistema de la organización en una lista con las cuatro categorías de entidad
externa, flujo de datos, procesos, y almacén de datos. Esta lista a su vez ayudara
a determinar los límites del sistema que describirá. Una vez que se haya
recopilado una lista básica de elementos de datos se empieza a dibujar el
diagrama de contexto.
Creación de diagrama de contexto
Con un enfoque jerárquico de arriba hacia abajo para diagramar el
movimiento de los datos, los diagramas van de lo general a lo específico. Aunque
el primer diagrama ayuda a entender el movimiento básico de los datos, lo general
de su naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar
un panorama global que incluya las entradas básicas, el sistema general y las
10
salidas. Al proceso se le asigna el numero cero. En este diagrama se muestran
todas las entidades externas, así como los flujos de datos principales que van
desde y hacia dichas entidades. El diagrama no contiene ningún almacén de
datos. Es bastante simple la creación ya que se conocen las entidades externas y
el flujo de datos desde y hacia ellas.
Dibujo del diagrama 0 (el siguiente nivel)
Al ampliar los programas se puede lograr un mayor detalle que con los diagramas
de contexto. Las entradas y salidas especificadas en el primer diagrama
permanecen constantes en todos los diagramas que le siguen. Sin embargo, el
resto del diagrama original se amplia para incluir de tres a nueve procesos y
mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada
diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para
representar subprocesos, en este paso se empiezan a completar los detalles del
movimiento de los datos. El manejo de excepciones se ignora en los primero dos o
tres niveles del diagrama de flujo de datos.
11
El diagrama cero es la ampliación del diagrama de contexto y puede incluir
hasta nueve procesos, esto se hace porque si se agregan más procesos producirá
un diagrama difícil de entender. Por lo general, cada proceso se numero con un
entero, empezando en la esquina superior izquierda del diagrama y terminando en
la esquina inferior derecha. En el diagrama cero se incluyen los principales
almacenes de datos del sistema (que representan a los archivos maestros) y todas
las entidades externas. La figura 3.2 representa gráficamente el diagrama de
contexto y el diagrama cero.
Debido a que un diagrama de flujo de datos es bidimensional, se puede
empezar en cualquier punto del diagrama e ir hacia delante o hacia atrás. Si no
esta seguro de lo que podría incluir en cualquier punto, tome una entidad externa,
un proceso o un almacén de datos diferente y empiece a dibujar el flujo a partir de
él:
1. Empezamos con el flujo de datos de una entidad en el lado de la entrada. Se
hacen preguntas como: ¿Qué sucede con los datos que entran en el sistema?
¿Se almacenan? ¿Esta entrada es para varios procesos?
2. Trabajamos hacia atrás a partir de un flujo de datos de salida. Examinamos los
campos de salida de un documento o pantalla. Se pregunta sobre cada campo
de la salida: "¿De dónde viene?" o "¿Se calcula o almacena en un archivo?"
Examinamos el flujo de datos desde o hacia un almacén de datos. Se
pregunta: "¿Qué procesos ponen los datos en el almacén?" o "¿Qué procesos
usan los datos?" Observamos que un almacén de datos utilizado en el sistema
en el que se esta trabajando podría ser producido por un sistema diferente. Por
lo tanto, desde su punto de vista, tal vez no haya ningún flujo de datos hacia el
almacén de datos.
3. Analizamos un proceso bien definido. Vea qué entrada de datos necesita el
proceso y qué salida produce. Se hace un vínculo la entrada y la salida con los
almacenes de datos y las entidades adecuadas.
4. Tome nota de cualquier área confusa en donde no esté seguro de lo que se
debe incluir o de la entrada o la salida que se requiera. Al conocer las áreas
12
problemáticas podrá realizar una lista de preguntas para las entrevistas de
seguimiento con los usuarios clave.
Creación de diagramas hijos (niveles mas detallados)
Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un
diagrama hijo más detallado. El proceso del Diagrama cero a partir del cual se
realiza la ampliación se llama proceso padre, y el diagrama que se produce se
llama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibrio
vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir
entrada que el proceso padre no produzca o reciba también.
Por lo regular las entidades no se muestran en los diagramas hijos debajo
del diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujo
de datos de interfaz y se representa con una flecha que parte de un área vacía del
diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacén
de datos, también el diagrama hijo podría incluir el almacén de datos. Además,
este diagrama de nivel inferior podría contener almacenes de datos que no se
muestran en el proceso padre. En un diagrama hijo se podrían incluir un flujo de
datos de nivel inferior, como una línea de error, aunque no se podría hacer lo
mismo en el proceso padre.
Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel de
complejidad. Cuando no se amplia un proceso, se dice que es funcionalmente
primitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detallados
de un diagrama de flujos de datos hijo.
13
3.1.2 DICCIONARIOS DE DATOS.
El modelo de análisis acompaña representaciones de objetos de datos,
funciones y control. En cada representación los objetos de datos y/o elementos de
control juegan un papel importante. Por consiguiente, es necesario proporcionar
un enfoque organizado para representar las características de cada objeto de
datos y elemento de control. Esto se realiza con el diccionario de datos.
3
Proceso
Entrada B
Registro A
Entidad 2
El flujo de datos
coincidente
Registro
de
transacción
D1 Almacén de
Datos 1
D5 Archivo de
Transacción 1
Flujo de
datos D
Registro A
Flujo de datos
Z detallado
Registro
de
transacción
Flujo de datos D
D1 Almacén de
Datos 1
4
Proceso
3
Proceso
3
Proceso
3.1
Proceso
Entrada B
Error
En un diagrama
hijo detallado se
podrían agregar
líneas de error
En los diagramas
de nivel inferior se
podrían agregar
archivos de
transacciones
El flujo de salida
debe coincidir con
el proceso padre
El flujo de datos
del proceso padre
debe coincidir con
el diagrama hijo
Figura 3.3 Representación del diagrama de contexto y del diagrama cero
Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed
14
Se ha propuesto el diccionario de datos como gramática casi formal para describir
el contenido de los objetos definidos durante el análisis estructurado. Esta
importante notación de modelado ha sido definida de la siguiente forma:
El diccionario de datos es un listado organizado de todos los elementos de
datos que son pertinentes para el sistema, con definiciones precisas y rigurosas
que permiten que el usuario y el analista del sistema tengan una misma
comprensión de las entradas, salidas, de las componentes de los almacenes y
también de los cálculos intermedios.
Actualmente, casi siempre se implementa el diccionario de datos como parte de
una «herramienta CASE de análisis y diseño estructurados». Aunque el formato
del diccionario varía entre las distintas herramientas, la mayoría contiene la
siguiente información:
Nombre: el nombre principal del elemento de datos o de control, del almacén
de datos, o de una entidad externa.
Alias: otros nombres usados para la primera entrada.
Donde se usa / como se usa: un listado de los procesos que usan el
elemento de datos o de control y cómo lo usan (por ejemplo, como entrada al
proceso, como salida del proceso, como almacén de datos, como entidad
externa).
Descripción del contenido: el contenido representado mediante una
notación.
Información adicional: otra información sobre los tipos de datos, los valores
implícitos (si se conocen), las restricciones o limitaciones, etc.
Una vez que se introducen en el diccionario de datos un nombre y sus alias,
se debe revisar la consistencia de las denominaciones. Esto mejora la
consistencia del modelo de análisis y ayuda a reducir errores.
La información de «dónde se usa/cómo se usa» se registra automáticamente a
partir de los modelos de flujo. Cuando se crea una entrada del diccionario, la
herramienta CASE inspecciona los DFD y los DFC para determinar los procesos
15
que usan el dato o la información de control y cómo lo usan. Aunque esto pueda
no parecer importante, realmente es una de las mayores ventajas del diccionario.
Durante el análisis, hay una corriente casi continua de cambios. Al poder tratar el
diccionario de datos como una base de datos, el analista puede hacer preguntas
basadas en «dónde se usa/cómo se usan y obtener respuestas a peticiones
similares a las anteriores.
La notación utilizada para desarrollar una descripción de contenido se indica en la
siguiente tabla:
La notación permite al ingeniero del software representar una composición de
datos en una de las tres alternativas fundamentales que pueden ser construidas
1. Como una secuencia de elementos de datos.
2. Como una selección de entre un conjunto de elementos de datos.
3. Como una agrupación repetitiva de elementos de datos. Cada entrada de
elemento de datos que aparezca como parte de una secuencia, una selección o
una repetición puede a su vez ser otro elemento de datos compuestos que
necesite un mayor refinamiento en el diccionario.
Además de proporcionar documentación y eliminar la redundancia, el diccionario
datos se podría usar para:
1. Validar la integridad y exactitud del diagrama de flujo de datos.
2. Proporcionar un punto de partida para desarrollar pantallas e informes,
3. Determinar el contenido de los datos almacenados en archivos.
4. Desarrollar la lógica para los procesos del diagrama de flujo de datos.
16
3.1.2.2 Creación del Diccionario de Datos
Las entradas del diccionario de datos se podrían crear después de
completar el diagrama de flujo de datos, o se podrían construir conforme se
desarrolle el diagrama de flujo de datos. El uso de notación algebraica y registros
estructurales permite desarrollar el diccionario de datos y los diagramas de flujos
de datos mediante un enfoque jerárquico de arriba a bajo.
Después de realizar varias entrevistas adicionales para descubrir los
detalles del sistema, se puede extender el diagrama de flujo de datos y se crearan
los diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir
los nuevos registros estructurales y elementos recabados en las entrevistas,
observación y análisis de documentos posteriores.
Cada nivel de un diagrama de flujo de datos debe usar datos adecuados
para el nivel. El diagrama 0 debe incluir únicamente formularios, pantallas
informes y registros. Conforme se creen los diagramas hijos, el flujo de datos que
entre y salga de los procesos será cada vez mas detallado, incluyendo los
registros estructurales y los elementos.
Análisis de las entradas y salidas
Un paso importante en la creación del diccionario de datos es identificar y
categorizar el flujo de datos de entrada y salida del sistema. Campos comúnmente
incluidos:
1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en
un diagrama lógico, el nombre debe identificar el propósito de los datos.
2. El contacto del usuario responsable para la clarificación de detalles
adicionales, retroalimentación del diseño y aprobación final
3. Si los datos son de entrada o salida
4. El formato de flujo de datos. En la fase del diseño lógico, el formato podría
ser indeterminado.
5. Elementos que indican la secuencia de los datos en un informe o pantalla.
17
6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o
derivados y sus criterios de edición.
Desarrollo de almacenes de datos
Otra actividad es el desarrollo de los almacenes de datos. Esta información
se describe en estructuras de datos. Sin embargo la información podría estar
almacenada en diferentes lugares, y el almacén de datos podría ser diferente en
cada lugar. Mientras que los flujos de datos representan datos en movimiento, los
almacenes de datos representan datos en reposo.
Los almacenes de datos contienen información de una naturaleza
permanente o semipermanente.
Cuando los almacenes de datos se crean para un solo informe o pantalla nos
referimos a ellos como “vistas del usuario”, porque representan la manera en que
el usuario quiere ver la información.
Uso del diccionario de datos
El diccionario de datos ideal es automatizado, interactivo, en línea y
evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los
sistemas de la organización, se agregan elementos de datos al diccionario de
datos. El diccionario de datos no es un fin en si mismo y nunca debe serlo,
siempre debe verse como una actividad paralela al análisis y diseño de sistemas.
El diccionario de datos debe vincular a varios programas de sistemas para
que cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo
mismo en la base de datos. El diccionario de datos se vuelve una curiosidad
histórica sino se mantiene actualizado.
18
3.1.3 DISEÑO DE MÓDULOS
La arquitectura de computadora expresa la modularidad; es decir, el
software se divide en componentes nombrados y abordados por separado,
llamados frecuentemente módulos, que se integran para satisfacer los requisitos
del problema.
Se ha afirmado que “La modularidad es el único atributo del software que
permite gestionar un programa intelectualmente”. El software monolítico no puede
ser entendido fácilmente por el lector. La cantidad de rutas de control, la amplitud
de referencias, la cantidad de variables y la complejidad global hará que el
entendimiento este muy cerca de ser imposible. Para ilustrar este punto, tomemos
en consideración el siguiente argumento basado en observaciones humanas sobre
la resolución de problemas.
Pensemos que C(x) es una función que define la complejidad percibida de
un problema x, y que E(x) es una función que define el esfuerzo (oportuno) que se
requiere para resolver un problema x. para dos problemas p1 y p2, si
C(p1) > C(p2) (3.1a)
Implica que
E(p1) > E(p2) (3.1b)
En general, este resultado es por intuición obvio. Se tarda más en resolver un
problema difícil.
Mediante la experimentación humana en la resolución de problemas se ha
averiguado otra característica interesante. Esta es,
C(p1 + p2) > C(p1) + C(p2) (3.2)
La ecuación 3.2 implica que la complejidad percibida de un problema que
combina p1 y p2, es mayor que la complejidad percibida cuando se considera cada
19
problema por separado. Teniendo en cuenta la ecuación (3.2) y la condición
implicada por la ecuación (3.1) se establece que
E(p1 + p2) > E(p1) + E(p2) (3.3)
Es más fácil resolver un problema complejo cuando se rompe en piezas
manejables. El resultado expresado en la ecuación 3.3 implica que es importante
en lo que respecta a la modularidad y al software. Es, de hecho, un argumento
para la modularidad.
Es posible concluir de la ecuación (3.3) que si subdividimos el software
indefinidamente, el esfuerzo que se requiere para desarrollarlo sería mínimo.
Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusión sea
falsa. Como muestra la figura 3.4, el esfuerzo para desarrollar un módulo software
individual disminuye a medida que aumenta el número total de módulos. Dado el
mismo conjunto de requisitos: tener más módulos conduce a un tamaño menor de
módulo. Sin embargo, a medida que aumenta el número de módulos, también
crece el esfuerzo asociado con la integración de módulos. Estas características
conducen también a la curva total del costo o esfuerzo que se muestra en la
figura. Existe un número M de módulos que daría como resultado un costo mínimo
de desarrollo, aunque no tenemos la sofisticación necesaria para predecir M con
seguridad.
20
Las curvas de la Figura 3.4 proporcionan en efecto una guía útil cuando se tiene
en consideración la modularidad. La modularidad deberá aplicarse, pero teniendo
cuidado de estar próximo a M. Se deberá evitar modularizar de más o de menos.
Cuando se tiene en consideración la modularidad surge otra pregunta
importante. ¿Cómo se define un modulo con un tamaño adecuado? La respuesta
se, encuentra en los métodos utilizados para definir los módulos dentro de un
sistema. Meyer define cinco criterios que nos permitirán evaluar un método de
diseño en relación con la habilidad de definir un sistema modular efectivo:
Capacidad de descomposición modular. Si un método de diseño
proporciona un mecanismo sistemático para descomponer el problema en
subproblemas, reducirá la complejidad de todo el problema, consiguiendo de
esta manera una solución modular efectiva.
Capacidad de empleo de componentes modulares. Si un método de diseño
permite ensamblar los componentes de diseño (reusables) existentes en un
sistema nuevo, producirá una solución modular que no inventa nada ya
inventado.
Capacidad de comprensión modular. Si un módulo se puede comprender
como una unidad autónoma (sin referencias a otros módulos) será más fácil de
construir y de cambiar.
Continuidad modular. Si pequeños cambios en los requisitos del sistema
provocan cambios en los módulos individuales, en vez de cambios
generalizados en el sistema, se minimizará el impacto de los efectos
secundarios de los cambios.
Protección modular. Si dentro de un módulo se produce una condición
absurda y sus efectos se limitan a ese módulo, se minimizará el impacto de los
efectos secundarios inducidos por los errores.
Es importante destacar que un sistema se puede diseñar modularmente,
incluso aunque su implementación deba ser “monolítica”. Existen situaciones (por
ejemplo, software en tiempo real, software empotrado) en donde no es admisible
21
que los subprogramas introduzcan sobrecargas de memoria y de velocidad por
mínimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones
el software podrá y deberá diseñarse con modularidad como filosofía
predominante. El código se puede desarrollar “en línea”. Aunque el código fuente
del programa puede no tener un aspecto modular a primera vista, se ha mantenido
la filosofía y el programa proporcionará los beneficios de un sistema modular.
3.1.4 DESCOMPOSICIÓN EN PROCESOS
Las fases que generalmente caracterizan al proceso del software son:
definición desarrollo y soporte, se aplican a todo software. El problema es
seleccionar el modelo de proceso apropiado para la ingeniería del software que
debe aplicar el equipo. El gestor del proyecto debe decidir que modelo de proceso
es el más adecuado para:
1. Los clientes que han solicitado el producto y la gente que realizara el
trabajo.
2. Las características del producto.
3. El entorno del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo de proceso, el equipo define entonces un
plan de proyecto preliminar basado en conjunto de actividades estructurales. Una
vez establecido el plan preliminar, empieza la descomposición del proceso. Es
decir, se debe crear un plan completo reflejando las tareas requeridas a las
personas para cubrir las actividades estructurales.
Un proyecto cuando es relativamente pequeño se debe realizar con un enfoque
secuencial lineal. Si hay limites de tiempo muy severos y le problema se puede
compartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo mas
apropiado es tomar una estrategia incremental.
Una vez que hemos elegido el modelo de proceso, la Estructura Común de
Procesos (ECP) se adapta a él. En todos los casos, la ECP (comunicación con el
22
cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega y
evaluación del cliente) puede adaptarse al paradigma. Funcionara para modelos
lineales, para modelos iterativos e incrementales, para modelos de evolución e
incluso para modelos concurrentes o de ensamblaje de componentes. El ECP es
invariable y sirve como base para todo el trabajo de software realizado por una
organización.
Un proyecto simple requiere las siguientes tareas para la actividad de
comunicación con el cliente:
1. Desarrollar una lista de aspectos que se deben aclarar
2. Reunirse con el cliente para aclarar los aspectos de la lista
3. Desarrollar en conjunto una exposición del ámbito del proyecto
4. Revisar el alcance del proyecto con todos los implicados
5. Modificar el alcance del proyecto cuando se requiera.
Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48
horas. Representan una descomposición del problema apropiado para proyectos
pequeños relativamente sencillos.
Si se considera un proyecto más complejo que tenga un ámbito más amplio y un
mayor impacto comercial. Un proyecto como ése podría requerir las siguientes
tareas para la actividad de comunicación con el cliente:
1. Revisar la petición del cliente
2. Planificar y programar una reunión formal con el cliente
3. Realizar una investigación para definir soluciones propuestas y
enfoques existentes.
4. Prepara un plan de trabajo y una agenda para la reunión formal
5. Realizar la reunión
6. Desarrollar conjuntamente mini-especificaciones que reflejen la
información, función y características de comportamiento del
software
23
7. Revisar todas las mini-especificaciones para comprobar su
corrección , su consistencia la ausencia de ambigüedades
8. Ensamblar las mini-especificaciones de un documento de alcance
del proyecto
9. revisar ese documento general con todo lo que pueda afectar
10. modificar el documento de alcance del proyecto cuando se
requiera
Ambos proyectos realizan la actividad estructural que denominamos comunicación
con el cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de
ingeniería del software que el segundo.
3.2 EL ENFOQUE ORIENTADO A OBJETOS
El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO)
constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan
en los conceptos de la programación orientada a objetos, que han sido codificados
en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de
modelación en el cual los objetos generados no solo incluyen código referente a
los datos sino también instrucciones acerca de las operaciones que se realizaran
sobre los datos.
EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y
modelado de software que permite construir más fácilmente sistemas complejos a
partir de componentes individuales.
Objetos + Mensajes = Programa
El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que
comienza con la comunicación con el usuario. Es en esta parte donde se define el
dominio del problema y se identifican las clases básicas del problema. La
planificación y el análisis de riesgos establecen una base para el plan de proyecto
24
El trabajo técnico asociado con la ingeniería del software OO sigue las siguientes
tareas:
1. Identificar clases candidatas
2. Buscar clases en biblioteca
3. Extraer nuevas clases si existen
4. Desarrollar las clases sino existen
5. Añadir las nuevas clases a la biblioteca
6. Construir n-esima iteración del sistema
La ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases
se buscan en una biblioteca (de clases existentes) antes de construirse
Las Características del Enfoque Orientado a Objetos son:
a) Objeto: Los datos están cuantificados en entidades discretas y
distinguibles llamadas objetos.
b) Clase: Los objetos con la misma estructura de datos (atributos) y
comportamiento (operaciones) se agrupa para formar una clase.
c) Atributo: Describen la clase o el objeto de alguna manera
d) Mensajes: Medio por el cual interactúan los objetos
e) Polimorfismo: Una misma operación puede comportarse de modos
distintos en distintas clases.
f) Herencia: Compartir atributos y operaciones entre clases tomando
como base una relación jerárquica.
Objeto
Un objeto es una unidad de código compuesto de variables y métodos
relacionados. Encapsula datos, operaciones, otros objetos, constantes y otra
información relacionada. Pueden ser: Entidades externas, ocurrencias o eventos,
papeles o roles, unidades organizacionales, lugares, estructuras.
25
Los Objetos tienen características y comportamientos. Mantiene sus
características en una o más "variables", e implementa su comportamiento con
"métodos". Un método es una función o subrutina asociada a un objeto. Cuando a
las características del objeto le ponemos valores decimos que el objeto tiene
estados. Las variables almacenan los estados de un objeto en un determinado
momento.
Para ser considerado como valido un objeto debe de tener las siguientes
características:
Información retenida
Servicio necesario
Atributos múltiples
Atributos comunes
Operaciones comunes
Requisitos esenciales
Clase
La clase es un modelo o prototipo que define las variables y métodos comunes a
todos los objetos de cierta clase.
Es una descripción generalizada que describe una colección de objetos con
características similares.
Todos los objetos que existen dentro de una heredan sus atributos y las
operaciones disponibles para la manipulación de los atributos.
Una superclase es una colección de clases y una instancia de una clase.
Una instancia de una clase es otra forma de llamar a un objeto. En realidad no
existe diferencia entre un objeto y una instancia. Sólo que el objeto es un término
más general, pero los objetos y las instancias son ambas representación de una
clase.
26
Atributo
Los Atributos están asociados a clases y objetos, ellos describen la clase y el
objeto de alguna manera. Un atributo puede tomar un valor definido por un
dominio enumerado. En la mayoría de los casos, un dominio es simplemente un
conjunto de valores específicos. En situaciones más complejas el dominio puede
ser un conjunto de clases.
Mensajes
Los mensajes son el medio a través del cual los objetos intercambian información.
Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor.
El comportamiento se realiza cuando se ejecuta una operación.
El medio empleado para que un objeto interactúe con otro son los mensajes. Los
mensajes son invocaciones a los métodos de los objetos.
Encapsulamiento
El encapsulamiento significa que toda la información de un objeto se encuentra
empaquetada bajo un nombre y puede reutilizarse como una especificación o
componente de un programa.
Consiste en unir en la clase las características y comportamientos, esto es, las
variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes
estructurados esto era imposible. Es evidente que el encapsulamiento se logra
gracias a la abstracción y el ocultamiento.
La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya
que tendremos a las clases como cajas negras donde sólo se conoce el
comportamiento pero no los detalles internos, y esto es conveniente porque nos
interesará será conocer qué hace la clase pero no será necesario saber cómo lo
hace.
27
EL Ocultamiento es la capacidad de ocultar los detalles internos del
comportamiento de una clase y exponer sólo los detalles que sean necesarios
para el resto del sistema.
El ocultamiento permite: restringir y controlar el uso de la Clase. Restringir porque
habrá cierto comportamiento privado de la Clase que no podrá ser accedido por
otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el
estado de nuestra Clase y es en estos mecanismos dónde se validarán que
algunas condiciones se cumplan.
Herencia
La herencia consiste en que una clase puede heredar sus variables y métodos a
varias subclases (la clase que hereda es llamada superclase o clase padre). Esto
significa que una subclase, aparte de los atributos y métodos propios, tiene
incorporados los atributos y métodos heredados de la superclase. La herencia
reduce el trabajo de la programación usando fácilmente objetos comunes. Solo es
necesario declarar que la clase A hereda de la clase B y después proporcionar
cualquier detalle adicional. Los atributos y comportamientos de la clase B son
parte de la clase A y no requiere ninguna programación adicional.
Polimorfismo
El polimorfismo permite que un número de operaciones diferentes tengan el
mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno
más independiente.
3.2.1 ANÁLISIS.
El análisis utiliza una combinación de texto y de diagramas, para
representar los requisitos de datos, funciones y comportamientos, que es
relativamente fácil de entender y mas importante aun, sencillo para revisar su
corrección, completitud y consistencia. El ingeniero del software o analista es el
responsable de construir el modelo utilizando los requisitos definidos por el cliente.
Lo cual es importante para validar los requerimientos del software desde
28
diferentes puntos de vista. El análisis representa los requisitos de tres
dimensiones, por esa razón, se incrementa la probabilidad de encontrar errores,
descubrir inconsistencias y detectar omisiones.
El objetivo del análisis orientado a objetos es desarrollar una serie de
modelos que describan el software de computadora al trabajar para satisfacer un
conjunto de requisitos definidos por el cliente. El AOO, como los métodos de
análisis convencional, forma un modelo de análisis multiparte para satisfacer este
objetivo. El modelo de análisis ilustra información, funcionamiento y
comportamiento dentro del contexto de los elementos del modelo de objetos.
El análisis orientado a objetos (AOO) ha sido muy exitoso en derribar
problemas que se resisten al análisis estructurado, como las interfaces de usuario.
Los partidarios del AOO argumentan que los objetos dentro de un sistema son
más fundamentales (importantes, necesarios) para su naturaleza que las
funciones que proporciona. Las especificaciones basadas en los objetos serán
más adaptables que las especificaciones basadas en las funciones.
La popularidad de las tecnologías de objetos ha generado docenas de métodos de
A00 desde finales de los 80 y durante los 90'. Cada uno de ellos introduce un
proceso para el análisis de un producto o sistema, un conjunto de modelos que
evoluciona fuera del proceso, y una notación que posibilita al ingeniero del
software crear cada modelo de una manera consistente. Entre los más
ampliamente utilizados se encuentran:
El método de Booch. Abarca un microproceso de desarrollo» y un
«macroproceso de desarrollo». El nivel micro define un conjunto de tareas de
análisis que se reaplican en cada etapa en el macro proceso. Por esto se
mantienen un enfoque evolutivo. El microproceso de desarrollo identifica clases
y objetos y la semántica de dichas clases y objetos, define las relaciones entre
29
clases y objetos y realiza una serie de refinamientos para elaborar el modelo
del análisis.
El método de Rumbaugh. Rumbaugh y sus colegas desarrollaron la Técnica
de Modelado de Objetos (OMT) para el análisis, diseño del sistema y diseño a
nivel de objetos. La actividad de análisis crea tres modelos: el modelo de
objetos (una representación de objetos, clases, jerarquías y relaciones), el
modelo dinámico (una representación del comportamiento del sistema y los
objetos) y el modelo funcional (una representación a alto nivel del flujo de
información a través del sistema similar al DFD).
El método de Jacobson. También llamado OOSE (en español Ingeniería del
Software Orientada a Objetos),el método de Jacobson es una versión
simplificada de Objectory, un método patentado, también desarrollado por
Jacobson. Este método se diferencia de los otros por la importancia que da al
caso de uso una descripción o escenario que describe cómo el usuario
interactúa con el producto o sistema.
El método de Coad y Yourdon. El método de Coad y Yourdon se considera,
con frecuencia, como uno de los métodos del A00 más sencillos de aprender.
La notación del modelado es relativamente simple y las reglas para desarrollar el
modelo de análisis son evidentes.
El método de Wirfs-Brock. El método de Wirfs-Brock propone un proceso
continuo que comienza con la valoración de una especificación del cliente y
termina con el diseño. A continuación se esbozan brevemente las tareas
relacionadas con el análisis de Wirfs-Brock:
o Evaluar la especificación del cliente.
o Usar un análisis gramatical para extraer clases candidatas de la
especificación.
o Agrupar las clases en un intento de determinar superclases.
o Definir responsabilidades para cada clase.
o Asignar responsabilidades a cada clase.
30
o Identificar relaciones entre clases.
o Definir colaboraciones entre clases basándose en sus
responsabilidades.
o Construir representaciones jerárquicas de clases para mostrar
relaciones de herencia.
o Construir un gafo de colaboraciones para el sistema.
Aunque la terminología y etapas del proceso para cada uno de estos métodos de
AOO difieren, los procesos generales de AOO son en realidad muy similares. Para
realizar un análisis orientado a objetos, un ingeniero del software debería ejecutar
las siguientes etapas genéricas:
1. Obtener los requisitos del cliente para el sistema.
2. Identificar escenarios o casos de uso.
3. Seleccionar clases y objetos usando los requisitos básicos como guías.
4. Identificar atributos y operaciones para cada objeto del sistema.
5. Definir estructuras y jerarquías que organicen las clases.
6. Construir un modelo objeto-relación.
7. Construir un modelo objeto-comportamiento.
8. Revisar el modelo de análisis OO con relación a los casos de uso/escenarios
3.2.2 DISEÑO.
El diseño orientado a objetos transforma el modelo de análisis creado
usando análisis orientado a objetos, en un modelo de diseño que sirve como
anteproyecto para la construcción de software. El trabajo de diseñador de software
puede ser intimidante.
Gamma y sus colegas proveen un panorama razonablemente exacto del DOO
cuando declaran que:
31
El diseño de software orientado a objetos es difícil, y el diseño de software
reusable orientado a objetos es aun más difícil. Se deben identificar los objetos
pertinentes, clasificarlos dentro de las clases en la granularidad correcta, definir
interfaces de clases y jerarquías de herencia y establecer relaciones clave entre
ellos. El diseño debe ser específico al problema que se tiene entre manos, pero
suficientemente general para adaptarse a problemas y requerimientos futuros.
Además se deberá evitar el rediseño, o por lo menos minimizarlo.
El DOO debe describir la organización específica de los datos de los atributos y el
detalle procedural de cada operación. Estos representan datos y piezas
algorítmicas de un sistema OO y son los que contribuyen a la modularidad global.
¿Qué es? El diseño de software Orientado a objetos requiere la definición de una
arquitectura de software multicapa, la especificación de subsistemas que realizan
funciones necesarias y proveen soporte de infraestructura, una descripción de
objetos (clases), que son los bloques de construcción del sistema, y una
descripción de los mecanismos de comunicación, que permiten que los datos
Buyan entre las capas, subsistemas y objetos. El Diseño Orientado a Objetos
(DOO), cumple todos estos requisitos.
¿Quién lo hace? El DOO lo realiza un ingeniero de software.
¿Por qué es importante? Un sistema orientado a objetos utiliza las definiciones
de las clases derivadas del modelo de análisis. Algunas de estas definiciones
tendrán que ser construidas desde el principio, pero muchas otras pueden ser
reutilizadas, si se reconocen los patrones de diseño apropiados. El DOO establece
anteproyecto de diseño, que permite al ingeniero de software definir la arquitectura
OO. En forma que maximice la reutilización; de esta manera, se mejora la
velocidad del desarrollo y la calidad del producto terminado.
¿Cuáles son los pasos? El DOO se divide en dos grandes actividades: diseño
del sistema y diseño de objetos.
32
Diseño de sistema: crea la arquitectura del producto definiendo una serie de
capas, que cumplen funciones específicas del sistema e identifica las clases que
son encapsuladas por los subsistemas que residen en cada capa. Además, el
diseño de sistemas incorpora la especificación de tres componentes: la interfaz
usuario, la gestión de datos y los mecanismos de administración de tareas.
El diseño de objetos: se centra en los detalles internos de cada clase, definición
atributos operaciones y detalles de los mensajes.
¿Cuál es el producto obtenido? El modelo de DOO avara arquitectura de
software, descripción de la interfaz de usuario, componentes de gestión de datos
mecanismos de administración de tareas y descripciones detalladas de cada una
de las clases usadas en el sistema.
¿Cómo puedo estar seguro que lo he hecho correctamente? En cada etapa,
los elementos del modelo de diseño orientado a objetos son revisados por
claridad, corrección, integridad y consistencia con los requisitos del cliente y entre
ellos.
El concepto de una pirámide de diseño para el software convencional. Cuatro
capas de diseño: datos, arquitectura, interfaz y nivel de componentes fueron
definidas y discutidas.
Para sistemas orientados a objetos, podemos también definir una pirámide, pero
las capas son un poco diferentes.
Refiriéndose a la Figura 3.3, las cuatro capas de la pirámide de diseño OO son:
La capa subsistema. Contiene una representación de cada uno de los
subsistemas, para permitir al software conseguir sus requisitos definidos por el
cliente e implementar la infraestructura que soporte los requerimientos del
cliente.
33
La capa de clases y objetos. Contiene la jerarquía de clases, que permiten al
sistema ser creado usando generalizaciones y cada vez especializaciones más
acertadas. Esta capa también contiene representaciones.
La capa de mensajes. Contiene detalles de diseño, que permite a cada objeto
comunicarse con sus colaboradores. Esta capa establece interfaces externas e
internas para el sistema.
La capa de responsabilidades. Contiene estructuras de datos y diseños
algorítmicos, para todos los atributos y operaciones de cada objeto.
La pirámide de diseño se centra exclusivamente en el diseño de un
producto o sistema específico. Observe, sin embargo, que existe otra capa de
diseño, y que esta capa forma los cimientos sobre los que la pirámide se sostiene.
La capa fundamental se centra en el diseño de los objetos del dominio (llamados
patrones de diseño). Los objetos del dominio juegan un papel clave, en la
construcción de la infraestructura del sistema OO aportando soporte para las
actividades de interfaz hombre/máquina, administración (gestión) de tareas y
gestión (administración) de datos.
Los objetos del dominio se pueden usar, además, para desarrollar el diseño de la
aplicación en sí misma.
34
UNIDAD IV
MODELOS DE PROCESO DE SOFTWARE:
Introducción:
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta
inicialmente disperso, el desarrollo de software implícito, latente e incompleto en
gran medida es un proceso social de aprendizaje. Es un dialogo en el que se
reúne el conocimiento y se incluye en el software para convertirse en software.
Proporciona una iteración entre los usuarios y los diseñadores, entre los usuarios
y las herramientas de desarrollo, y entre los diseñadores y las herramientas de
desarrollo (tecnología). Es un proceso interactivo donde la herramienta de
desarrollo se usa como medio de comunicación, con cada iteración del dialogo se
obtiene mayor conocimiento.
Desde un punto de vista técnico se puede decir que el proceso de software
es un marco de trabajo de las tareas que se requieren para construir software de
alta calidad.
Aun más importante es que la Ingeniería del Software la realizan personas
creativas, con conocimiento, que deberían trabajar dentro de un proceso del
software definido y avanzado que es apropiado para los productos que construyen
y para las demandas de su mercado.
Los estándares establecen los diferentes procesos implicados a la hora de
desarrollar y mantener un Sistema desde que surge la idea o necesidad de
desarrollar las aplicaciones hasta que éstas se retiran de explotación. Sin
embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de
vida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por lo
que cada empresa deberá utilizar los métodos, técnicas y herramientas que
considere oportuno.
35
Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de
procesos del Software es una simplificación o abstracción de un proceso real.
Podemos definir un modelo de procesos del Software como una representación
abstracta de alto nivel de un proceso Software.
Cada modelo es una descripción de un proceso Software que se presenta desde
una perspectiva particular. Alternativamente, a veces se usan los términos Ciclo
de Vida y Modelo de Ciclo de Vida.
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.
Según las fases y el modo en que se produzca este encadenamiento, tenemos
diferentes modelos de proceso. Un modelo es más adecuado que otro para
desarrollar un proyecto dependiendo de un conjunto de características de éste.
Existe una gran variedad de modelos diferentes entre los que tenemos los que se
describen a continuación.
4.1 MODELO DE CASCADA
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970,
Pressman lo presenta como ciclo de vida clásico). Se denomina modelo en
cascada porque su característica principal es que no se comienza con un paso
hasta que no se ha terminado el anterior. Establece que el software debe ser
construido, rigurosamente, a través de una transformación sucesiva de
documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué se
quiere y después, cuando se conozca todo lo que se quiere, empezar a
construirlo.
También conocido como modelo lineal secuencial sugiere un enfoque
sistemático, secuencial para el desarrollo del software que comienza en un nivel
de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento.
36
El primer paso es conseguir un documento con la especificación completa,
exacta, no ambigua de los requisitos del sistema software que debe ser
desarrollado. Este documento inicial es transformado en un documento de
análisis, supuestamente alejado de la máquina. Después, a partir del análisis, se
obtiene otro documento, el diseño. Y por último, del diseño se obtiene el
documento final: el código. Para asegurar que no se introducen equivocaciones al
transformar un documento (modelo) en otro, se hacen pruebas, al terminar cada
uno. Las pruebas son planificadas desde el principio y se documentan como se
vayan realizando. Antes de la entrega del sistema software, se valida que
satisface los requisitos definidos en el documento inicial.
Está basado en el ciclo convencional de una ingeniería, tiene las siguientes
actividades que se muestran en la figura 4.1 del modelo de cascada:
Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida
del Software, de forma tal que el inicio de cada etapa debe esperar a la
finalización de la inmediatamente anterior. La palabra cascada sugiere, mediante
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
Figura 4.1 Modelo de Cascada
Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril de
2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>
37
la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases más avanzadas de un proyecto.
Modelo en Cascada: El más conocido, está basado en el ciclo convencional de
una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
- Ingeniería y Análisis del Sistema
- Análisis de los Requisitos
- Diseño
- Codificación
- Prueba
- Mantenimiento
4.1.1 Actividades
Ingeniería y Análisis del Sistema
El trabajo comienza estableciendo los requisitos de todos los elementos del
sistema y luego asignando algún subconjunto de estos requisitos al software.
Análisis de los requisitos del software
Análisis: Se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (Documento de Especificación de Requisitos), que contiene la especificación
completa de lo que debe hacer el sistema sin entrar en detalles internos (debe
comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas).
38
Diseño
Se enfoca en cuatro atributos distintos del programa: la estructura de los
datos, la arquitectura del software, el detalle procedimental y la caracterización de
la interfaz. El proceso de diseño traduce los requisitos en una representación del
software con la calidad requerida antes de que comience la codificación. Como
resultado surge el SDD (Documento de Diseño del Software), que contiene la
descripción de la estructura global del sistema y la especificación de lo que debe
hacer cada una de sus partes, así como la manera en que se combinan unas con
otras.
Codificación
Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe
traducirse en una forma legible para la maquina, haciendo uso de prototipos así
como pruebas y ensayos para corregir errores. El paso de codificación realiza esta
tarea. Si el diseño se realiza de una manera detallada la codificación puede
realizarse mecánicamente.
Prueba
Se centra en la lógica interna del software, y en las funciones externas, realizando
pruebas que aseguren que la entrada definida produce los resultados que
realmente se requieren. Se comprueba que funciona correctamente antes de ser
puesto en explotación.
Mantenimiento
El software sufrirá cambios después de que se entrega al cliente. Los cambios
ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
39
Desventajas
Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un error
importante no detectado hasta que el programa este funcionando puede ser
desastroso.
Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las
especificaciones y en el diseño. Bajo riesgo para desarrollos bien
comprendidos utilizando tecnología conocida
Este modelo, que se lleva a cabo de forma descendente, exige que para pasar a la
siguiente fase hay que concluir correctamente la anterior, de manera que los
posibles errores sean fácilmente detectables. Así, la salida de una fase es la
entrada de la siguiente.
La Ventajas de este método radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.
Se tiene todo bien organizado y no se mezclan las fases.
Es perfecto para proyectos que son rígidos.
Ideal para proyectos donde se especifiquen muy bien los requerimientos.
Ideal para proyectos en que se conozca muy bien la herramienta a utilizar.
Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de
desarrollar el Software.
40
4.2 MODELO DE ESPIRAL
Propuesto originalmente por Boehm en 1988, es un modelo de proceso de
software evolutivo ha sido desarrollado para cubrir las mejores características
tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al
mismo tiempo un nuevo elemento: el análisis de riesgo. Proporciona el potencial
para el desarrollo rápido de versiones incrementales del software. En este modelo
el software se desarrolla en una serie de versiones incrementales. Durante las
primeras iteraciones, la versión incremental podría ser un modelo en papel o un
prototipo. En las últimas iteraciones, se producen versiones cada vez mas
completas del sistema diseñado.
El modelo representado mediante la espiral de la figura 4.2 define cuatro
actividades principales, también llamadas regiones de tareas o sectores:
1. Planificación. Durante la primera vuelta alrededor de la espiral se
definen los objetivos, las alternativas y las restricciones, se analizan e
identifican los riesgos. Si el análisis de riesgo indica que hay una
incertidumbre en los requisitos, se puede usar la creación de prototipos
en el cuadrante de ingeniería para dar asistencia tanto al encargado de
desarrollo como al cliente.
2. Análisis de riesgo. El proyecto se revisa y se toma la decisión de si se
debe continuar con un ciclo posterior de la espiral. Si se decide continuar,
se desarrollan los planes para la siguiente fase del proyecto.
3. Ingeniería. En este sector se desarrolla y se valida. Después de la
evaluación de riesgos, se elige un modelo para el desarrollo del sistema.
4. Evaluación del cliente. El cliente evalúa el trabajo de ingeniería
(cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la
base de los comentarios del cliente se produce la siguiente fase de
planificación y de análisis de riesgo. En cada bucle alrededor de la
espiral, la culminación del análisis de riesgo resulta en una decisión de
"seguir o no seguir".
41
Con cada iteración alrededor de la espiral (comenzando en el centro y
siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada
vez más completas y, al final, el propio sistema operacional.
Un ciclo en espiral inicia con la elaboración de objetivos, como el
rendimiento y la funcionalidad. Después se enumeran formas alternativas de
alcanzar estos objetivos y las restricciones impuestas en cada una de ellas. Cada
alternativa se evalúa contra cada objetivo y se identifican las fuentes de riesgo del
proyecto. Lo siguiente es resolver los riesgos mediante actividades de recopilación
de información como la de detallar más el análisis, la construcción de prototipos y
la simulación. Ya que se evaluaron los riesgos, se lleva a cabo cierto desarrollo,
seguido de una actividad de planificación para la siguiente fase.
El paradigma del modelo en espiral para la Ingeniería de Software es
actualmente el enfoque más realista para el desarrollo de software y de sistemas a
gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente
entender y reaccionar a los riesgos en cada nivel. Utiliza la creación de prototipos
como un mecanismo de reducción de riesgo, pero, lo que es más importante
permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en
cualquier etapa de la evolución de prototipos.
42
4.3 MODELO INCREMENTAL
El modelo incremental aplica secuencias lineales de forma escalonada
mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de
pasos de desarrollo. Cada secuencia lineal produce un incremento del software.
El modelo incremental entrega el software en partes pequeñas, pero utilizables,
llamadas “incrementos”. En general, cada incremento se construye sobre aquel
que ya ha sido entregado.
Al igual que los otros métodos de modelado, el Modelo Incremental es de
naturaleza interactiva pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
43
El Modelo Incremental es particularmente útil cuando no se cuenta con una
dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se añadir personal, de ser necesario.
Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con
cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los Sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo
de datos en un proceso comprendido por varias fases secuenciales, siendo la
entrada de cada una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el intérprete
de comandos, ya que se pueden concatenar comandos fácilmente con tuberías
(pipe). Es una arquitectura muy natural en el paradigma de programación
funcional, ya que equivale a la composición de funciones matemáticas.
Interprete de comandos.
Parte fundamental de un Sistema Operativo que ordena la ejecución de mandatos
obtenidos del usuario por medio de una interfaz alfanumérica.
44
Características.
Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con
cierta frecuencia.
El usuario se involucre más.
Difícil de evaluar el costo total.
Difícil de aplicar a los Sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser muy positivo.
Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya
que se implementa la funcionalidad parcial.
También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada
incremento.
Permite entregar al cliente un producto más rápido en comparación del
modelo de cascada.
Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.
Desventajas:
El modelo Incremental no es recomendable para casos de Sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de
alto índice de riesgos.
45
Requiere de mucha planeación, tanto administrativa como técnica.
Requiere de metas claras para conocer el estado del proyecto.
Conclusión:
Un modelo incremental lleva a pensar en un desarrollo modular, con entregas
parciales del producto de Software denominados “incrementos” del Sistema, que
son escogidos en base a prioridades predefinidas de algún modo.
El modelo permite una implementación con refinamientos sucesivos (ampliación
y/o mejora).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos
requisitos o bien se mejora la versión previamente implementada del producto de
Software.
4.4 PROCESO DE DESARROLLO UNIFICADO
El Proceso Unificado de Desarrollo de Software o simplemente Proceso
Unificado es un marco de desarrollo de Software iterativo e incremental.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos específicos. De
la misma forma, el RUP también es un marco de trabajo extensible, por lo que
muchas veces resulta imposible decir si un refinamiento particular del proceso ha
sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres
suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que
incluye aquellos elementos que son comunes a la mayoría de los refinamientos
existentes.
46
Características:
- Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto
de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada
una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio
sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen
como resultado un incremento del producto desarrollado que añade o mejora las
funcionalidades del Sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada
una de ellas varía a lo largo del proyecto.
- Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el
camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el
proceso dirigido por casos de uso es el RUP
- Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra todos los
aspectos del Sistema. Por dicho motivo existen múltiples modelos y vistas que
definen la arquitectura de Software de un Sistema. La analogía con la construcción
es clara, cuando construyes un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanería, etc.
47
- Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar
los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de
cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados
en un orden que asegure que los riesgos principales son considerados primero.
4.5 PROCESO SOFTWARE PERSONAL
Es un modelo complejo con mucha terminología propia, pensado
principalmente para el desarrollo de grandes proyectos. Es un proceso que puede
adaptarse y extenderse en función de las necesidades de cada empresa. Es el
resultado de esfuerzo de las tres últimas décadas en desarrollo de software y de la
experiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh.
El PSP se caracteriza porque es de uso personal y se aplica a programas
pequeños de menos de 10.000 líneas de código. Se centra en la administración
del tiempo y en la administración de la calidad a través de la eliminación temprana
de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo,
Administración de configuraciones y Administración de requerimientos.
El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un
desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y
las capas que se manejan en cada uno:
Nivel 1 - Inicial:
- Seguimiento y control de proyectos
- Planeación de los proyectos
Nivel 2 - Repetible:
48
- Revisión entre colegas.
- Ingeniería del producto de Software.
- Manejo integrado del Software.
- Definición del proceso de Software.
- Foco del proceso de Software.
Nivel 3 - Definido:
- Control de calidad.
- Administración cuantitativa del proyecto.
Nivel 4 - Controlado:
- Administración de los cambios del proceso.
- Administración del cambio tecnológico.
- Prevención de defectos.
- El PSP tiene varias fases:
PSP0: Proceso Base.
PSP0.1: Complementos al proceso base.
PSP1 y PSP1.1: Planeación personal.
PSP2 y PSP2.1: Control de calidad personal.
PSP3: Programas más grandes.
49
El Proceso Personal Software, conocido por sus siglas como PSP es una
alternativa dirigida a los ingenieros de Sistemas, que les permite mejorar la forma
en la que construyen Software. Considerando aspectos como la planeación,
calidad, estimación de costos y productividad, PSP es una metodología que vale la
pena revisar cuando el ingeniero de Software está interesado en aumentar la
calidad de los productos de Software que desarrolla dentro de un contexto de
trabajo individual.
Atendiendo a la premisa de que existe una fuerte relación entre las
habilidades de los ingenieros de Software y la calidad de los productos que
desarrollan, las actividades establecidas en PSP están orientadas al conocimiento,
administración y mejora de sus habilidades al construir programas.
En PSP todas las tareas y actividades que el ingeniero de Software debe
realizar durante el proceso de desarrollo de un producto de Software, están
puntualmente definidas en un conjunto de documentos conocidos como scripts.
Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en
que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los
scripts generará en su realización un conjunto de datos, fundamentalmente de
carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el
análisis de la información estadística generada en cada uno de éstos, permitirán al
Ingeniero de Software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de autoaprendizaje y auto-mejora.
Los scripts se organizan en cuatro niveles, identificados del 0 al 3,
atendiéndose en cada nivel un conjunto de aspectos a mejorar del Proceso de
Desarrollo de Software. Al primer nivel se le conoce como 0 o de medición
personal, al segundo como nivel 1 o de planeación personal, al tercero, como nivel
2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de
estos niveles, con excepción del 3, tiene una versión que los extiende,
50
introduciendo tareas y actividades para un mejor manejo de los aspectos de
interés en nivel, o bien para incluir nuevos aspectos.
BIBLIOGRAFÍA
[1] Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edición.
[2] Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición
REFERENCIAS WEB
[3] Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid,
“Análisis y selección de estrategias de desarrollo de software” [En línea], Madrid
España [Consulta: Mayo de 2006], <http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/
estrategias.pdf>
[4] Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas
Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-
ModeloV.doc>
[5] Tesis doctorales en Zarza, “Ingeniería de Software” [En línea], España [Consulta: Mayo
de 2006], <http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102-
102210//05Capitulo05.pdf>
[6] Mundo Geek, “Ciclos de vida del software” [En línea], [Consulta: Mayo de 2006],
<http://mundogeek.net/archivos/2004/05/20>
