Fases genéricas del proceso de desarrollo de software

Fase Pasos Documentos

Definición
Análisis del Sistema Documento de Especificación del Sistema
Planificación del Documento de Plan de Proyecto
Proyecto
Análisis de Documento de Especificación de
Requerimientos Requerimientos (DFDs)
Desarrollo
Diseño preliminar Cartas de Estructura
Diseño detallado PDL
Codificación Documento del código con comentarios
externos e internos
Manual del usuario*
Pruebas Documento de las corridas de prueba
Mantenimiento
* Se va desarrollando en todos los pasos anteriores e incluso puede sufrir modificaciones durante el
mantenimiento.

Análisis del Sistema

1. identificar las necesidades
2. estudiar la viabilidad
3. análisis económico
4. análisis técnico
5. identificar restricciones de costo y tiempo

Resultado: Definición del sistema

Formato demostrativo del Documento de Especificación del Sistema

1. Definición del problema

2. Justificación del sistema
3. Restricciones del sistema y del proyecto*
4. Funciones que se proporcionarán (hardware/software/personal)
5. Características del usuario*
6. Ambientes de desarrollo/operación/mantenimiento
7. Estrategias de solución*
8. Prioridades para las características del sistema
9. Criterios de aceptación del sistema*
10. Fuentes de información*
11. Glosario*
* Pueden no ser necesarios para sistemas medianos o pequeños.

1
Planificación del Proyecto

1. Alcance
2. estimaciones de recursos humanos, software y hardware
3. estimaciones de costos
4. planificación temporal (PERT-Gantt)
5. planificación organizativa
6. seguimiento y control

Resultado: Elección del paradigma (Prototipos, Fases, 4GL)

Formato demostrativo del Documento de Plan del proyecto

1. Modelo del ciclo de vida. Terminología, Logros, Productos finales.

2. Estructura organizacional. Estructura de administración, de equipos, de distribución de trabajo, definición
de puestos.
3. Requisitos preliminares de personal y recursos. Programación de personal y recursos.*
4. Programación preliminar del proyecto (PERT-Gantt)
5. Estimación preliminar de costos.
6. Mecanismos de supervisión y control del proyecto.*
7. Herramientas y técnicas que se emplearán.
8. Lenguajes de programación.
9. Requisitos de pruebas.
10. Documentos de apoyo necesarios.*
11. Formas de demostración y entrega.
12. Programación de entrenamiento y materiales.*
13. Plan de instalación.*
14. Consideraciones de mantenimiento.
15. Método y tiempo de la entrega final.
16. Método y tiempo del pago.
17. Fuentes de información
* Pueden no ser necesarios para sistemas medianos o pequeños.

2
Análisis de Requerimientos

1. descripción de la información
2. representación del contenido (Diccionario de Datos)
3. descripción funcional informal o formal
4. descripción del comportamiento (diagramas de transición de estados)

Resultado: Modelo funcional realizado con alguna metodología (orientada al flujo de datos, orientada a las
estructuras de datos, orientada a objetos)

Diseño preliminar

1. Arquitectónico (Cartas de estructura)

2. De datos
3. De la interface

• refinamiento
• modularidad
• ocultamiento de la información
• abstracción de datos
• independencia funcional: cohesión y acoplamiento

Diseño detallado

• Procedimental: notaciones tabulares (Tablas de decisión), textuales (PDL) o gráficas (NS, DF)
• Algoritmos

Codificación

• lenguaje
• estilo

Pruebas

• De Unidad: de caja blanca, de caja negra

• De Integración: ascendente, descendente, mixta

Mantenimiento

• Correctivo
• Adaptativo
• Perfectivo

3
El Modelo Esencial
• Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo
mínimo posible acerca de cómo se implementará.
• Esto supone tecnología perfecta y que se puede obtener fácilmente y sin costo.
• Esto significa evitar describir implementaciones específicas de procesos en el sistema.
• Lo mismo se da para los flujos y almacenes de datos. El modelo debe describir el contenido sin describir
el medio u organización física de los datos.

El modelo esencial consiste de dos componentes principales:

1. Modelo ambiental.
Define la frontera entre el sistema y el resto del mundo. Consiste en el diagrama de contexto, una lista de acontecimientos y
una descripción breve del propósito del sistema.
2. Modelo de comportamiento.
Describe el comportamiento que se requiere del sistema para que interactúe de forma exitosa con el ambiente. Consiste de los
diagramas de flujo de datos, de entidad relación, de transición de estados y diccionarios y especificaciones de proceso.

El Modelo Ambiental.

• Además de determinar qué está en el interior del sistema y qué en el exterior, también define las
interfaces entre el sistema y el ambiente. Se necesita saber qué información entra al sistema desde el
ambiente exterior y qué información produce al ambiente externo.
• Como las entradas y las salidas no se producen al azar, otro aspecto crítico del modelo ambiental consiste
en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. Sólo
aquellos que (1) ocurren en el ambiente exterior y (2) requieren una respuesta del sistema.

La Declaración de Propósitos

• Es una declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo
superior, la administración de los usuarios, y otros que no están directamente involucrados con el
desarrollo del sistema.
• La intención no es dar una descripción completa y detallada del sistema.

El Diagrama de Contexto

Es un caso especial de DFD donde una burbuja representa todo el sistema.

Enfatiza varias características importantes del sistema:

• Las personas, organizaciones y sistemas con los que se comunica el sistema (terminadores).
• Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma.
• Los datos que el sistema produce y se envían al mundo exterior.
• Los almacenes de datos que el sistema comparte con otros sistemas.
• La frontera entre el sistema y el resto del mundo.

La Lista de Acontecimientos

Es una lista narrativa de los “estímulos” que ocurren en el mundo exterior a los cuales el sistema debe
responder.

Cada acontecimiento puede ser de flujo, temporal o de control.

• El acontecimiento orientado a flujo es el que se asocia a un flujo de datos, el sistema “se da cuenta de
que” ha ocurrido el acontecimiento cuando llega algún dato o posiblemente varios. Esto se corresponde
con un flujo de datos del diagrama de contexto.
• Los acontecimientos temporales arrancan con la llegada de un momento dado en el tiempo. No se inician
con flujos de datos de entrada, pero podrían requerir que el sistema solicite entradas.

El Diccionario de Datos Inicial

Define todos los flujos y almacenes externos.

El Modelo de Entidad - Relación de los almacenes externos

Construcción del Modelo Ambiental.

4
Construcción del Diagrama de Contexto

La parte más fácil del diagrama de contexto es el proceso.

• Los terminadores se comunican directamente con el sistema a través de flujos de datos o a través de
almacenes externos.
• Los terminadores no se comunican entre sí.
• Algunos terminadores tienen un buen número de entradas y salidas.
• Cuando el terminador es una persona individual, es preferible poner el rol que desempeña más que su
identidad.
• Es importante distinguir entre fuentes y manejadores.

Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema. Se
incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba
responder el sistema, o si se ocupan (como datos) para producir una respuesta. También se muestran cuando
el sistema produce datos para responder a un acontecimiento.
El diagrama de contexto no muestra los mensajes y medios específicos de coordinación que el sistema y los
terminadores pasan entre sí para indicar que están listos para las entradas o salidas. En lugar de eso, debe
suponerse que las entradas son causadas e iniciadas por los terminadores y que las salidas son causadas e
iniciadas por el sistema.

Construcción de la Lista de Acontecimientos

• No confundir un acontecimiento y un flujo relacionado con un acontecimiento.

• Describir los acontecimientos desde el punto de vista del sistema.
• La manera de identificar los acontecimientos relevantes para un sistema es examinar cada terminador y
preguntar qué efecto pueden tener sus acciones sobre el sistema.

1.2.3 ¿Qué se hace primero, el diagrama de contexto o la lista de acontecimientos?

En realidad no importa mientras finalmente se produzcan ambos y se revisen para asegurar que sean
consistentes.

1.2.4 Cuando se terminen ambas componentes del modelo ambiental será posible confirmar lo siguiente:
• El sistema necesita cada flujo de entrada del diagrama de contexto para reconocer que ha ocurrido un
acontecimiento, lo necesita para producir una respuesta a un acontecimiento, o ambas cosas.
• Cada flujo de salida debe ser respuesta a un acontecimiento.
• Cada acontecimiento no temporal debe tener entradas a partir de las cuales el sistema pueda detectarlo.
• Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar los datos que
luego serán salidas (como respuesta o parte de una respuesta a algún otro acontecimiento).

5
UNIDAD N° 1: "Concepto de Software e Ingeniería de Software".
La importancia del software.
Durante las tres primeras décadas de la informática, el principal desafío era el desarrollo del hardware, de
forma que se reduzca el costo de procesamiento y almacenamiento. Hoy el problema es diferente, es mejorar
la calidad y reducir el costo de las soluciones basadas en computadoras, soluciones que se implementan con
el software. La importancia de las grandes computadoras en la década de los 80 está hoy en una computadora
personal. Las capacidades del procesamiento y almacenamiento del hardware moderno presentan una gran
potencia de cálculo. El software es el mecanismo que nos facilita aprovechar, utilizar y explorar este
material.
La evolución del software. Un rendimiento en el hardware, una reducción de costos y tamaño han dado lugar
a sistemas informáticos más sofisticados. A continuación se muestra la evolución dentro del contexto de las
áreas de aplicaciones:
∗ 1950 a 1965:
* Sistemas Batch: ejecución de un solo programa, dedicado a una aplicación específica; “orient. x lotes”.
* Diseño a medida: la misma persona que lo escribía lo ejecutaba y si fallaba lo reparaba.
* Sin documentación: el proceso era un proceso implícito realizado en la mente de una persona.
∗ Primera etapa:
Durante los primeros años de desarrollo de las computadoras, el hardware sufrió continuos cambios,
mientras que el software se contemplaba simplemente como un añadido.
Se aprendió mucho sobre la implementación pero relativamente poco sobre la ingeniería de las
computadoras.
∗ 1960 a 1975:
* Multiprogramación, Multiusuario: introdujeron nuevos conceptos de interacción hombre – máquina.
* Técnicas interactivas: abrieron un nuevo mundo a aplicaciones.
* Tiempo Real: podía recoger, analizar y transformar datos de múltiples fuentes, controlando así los
procesos y produciendo salidas en milisegundos.
* Bases de Datos.
* Paquetes de Software.
∗ Segunda etapa:
el software comienza a distribuirse como un producto, se crean las bibliotecas de software. Estos
programas tenían que ser corregidos cuando se producían fallos, modificados si cambiaban los requisitos
de los usuarios o adaptados a nuevos dispositivos.
Esta actividad se llama “mantenimiento del software”. Este mantenimiento comenzó a absorber recursos
en una medida alarmante. Aún peor, la naturaleza personalizada de muchos programas lo hacían
imposible de mantener y así comienza la “crisis del software”.
∗ 1970 a la fecha:
* Sistemas Distribuidos: múltiples computadoras, cada una ejecutando funciones concurrentes y
comunicándose con alguna otra (aumenta la complejidad del software).
* Redes: área local y global.
* Microprocesadores: “productos inteligentes”.
* PC: computadoras personales.
* Sistemas expertos.
* Inteligencia Artificial.
∗ Tercera etapa:
Aparece una gran demanda del software.
∗ Cuarta etapa:
Está empezando ahora, la tecnología orientada a objetos está desplazando a las convencionales. Las
técnicas de cuarta generación para el desarrollo de software están cambiando la forma de construcción de
programas.
Los sistemas expertos y el software de inteligencia artificial se están trasladando de los laboratorios a las
aplicaciones prácticas.
El software de redes neuronales artificiales ha abierto excitantes posibilidades para el reconocimiento de
formas y habilidades de procesamiento de información al estilo humano.
∗ Problemas que se intensifican con el paso de era:
1) La sofisticación del hardware ha dejado desfasada nuestra capacidad de construir software que pueda
explotar el potencial del hardware.
2) La demanda supera la construcción de nuevos programas.
3) Nuestra capacidad de mantener los programas existentes está amenazada por el mal diseño y uso de
recursos inadecuado.
Como respuesta a esta crisis se ha adoptado la “Ingeniería de Software”.

6
Características del software.
Para poder entender el software analizaremos sus características:
− Es un elemento lógico:
1. Se desarrolla, no se fabrica en un sentido clásico.
2. No se estropea.
3. La mayoría se construye a medida en vez de ensamblar componentes existentes.
Comparación entre el software y el hardware:
ƒ SOFTWARE: Elemento Lógico
ƒ HARDWARE: Elemento Físico
Existen similitudes en su desarrollo pero son fundamentalmente diferentes. En ambos la buena calidad se
adquiere mediante un buen desarrollo. Ambos requieren la creación de un producto pero los métodos son
diferentes.
CURVA DE FALLOS:
Fallos por defectos no detectados Muchos fallos al principio de su vida, luego
No es susceptible a los cambios se estabiliza, se estropea con el paso del
del entorno (no se estropea se deteriora) tiempo.
Para entender mejor porque se deteriora:
Durante su vida, el software sufre cambios (mantenimiento conforme se hacen los cambios) se introducen
nuevos defectos haciendo que la curva tenga picos, antes de que vuelva a su estado original, se solicitan otros
cambios, haciendo que se cree otro pico.
Lentamente el nivel mínimo de fallos comienza a crecer y se deteriora debido a los cambios.

Componentes del software.

El software de computadoras es información que existe en dos formas básicas:
1. Componentes no ejecutables.
2. Componentes ejecutables (se traducen los requisitos del cliente a un código ejecutable).
Modelo (prototipo) de requisitos ⇒ diseño ⇒ a un lenguaje ⇒ traductor ⇒ código
La reusabilidad es una característica importante de los componentes de software de alta calidad.

7
Aplicaciones del software.
El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto
específico de pasos procedimentales (es decir un algoritmo). Existen excepciones como sistemas expertos y
redes neuronales.
Para determinar la naturaleza de una aplicación se debe considerar el contenido y el determinismo de la
información.
CONTENIDO: se refiere al significado y a la forma de su información de entrada y salida.
DETERMINISMO: se refiere a la predecibilidad del orden y del tiempo de llegada de los datos.
Posibilidad de aplicación:
∗ Software de Sistemas:
ƒ Sirve a otros programas. Ej. : compilador.
ƒ Fuerte interacción con el hardware.
ƒ Múltiples usuarios.
ƒ Estructuras de datos complejas y múltiples interfaces.
∗ Software de Tiempo Real:
ƒ Mide, analiza y controla sucesos del mundo real.
ƒ Este debe responder dentro de restricciones estrictas de tiempo.
∗ Software de Gestión: las aplicaciones de esta área reestructuran los datos existentes
en orden para facilitar las operaciones comerciales o gestiones
de toma de decisiones.
∗ Software de Ingeniería y Científico: caracterizado por los algoritmos de “manejo de
números”.
∗ Software empotrado: reside en memoria de solo lectura y se utiliza para control de
productos y sistemas de los marcados industriales y de
consumo. Pueden ejecutar funciones muy limitadas y curiosas
o suministrar una función significativa y con capacidad de
control.
∗ Software de PC: procesamiento de texto, hojas de cálculo, gráficos por
computadoras, juegos, gestión de BD, etc.
∗ Software de Inteligencia Artificial: hace uso de algoritmos no numéricos para
resolver problemas complejos para los que no son adecuados
el cálculo o el análisis. El área más atractiva es la de los
sistemas expertos también llamados sistemas basados en
conocimiento. Otra área es el reconocimiento de
patrones (imagen, voz) o redes neuronales que simulan la
estructura de proceso del cerebro.

Crisis del software.

Se refiere a un conjunto de problemas que aparecen en el desarrollo del software para computadoras. Los
problemas no están limitados al software que no funciona correctamente, es más, el mal barca los problemas
asociados a como desarrollarlo, como mantenerlo y como satisfacer las demandas.
Problemas:
1. Planificación y estimación de costos son frecuentemente muy imprecisas.
2. La productividad no se corresponde con la demanda.
3. La calidad, a veces, no llega a ser ni aceptable.
Tales problemas son solo las manifestaciones visibles de otros:
∗ No hay tiempo de recoger datos sobre el proceso de desarrollo sin datos históricos, las estimaciones no
han sido buenas.
∗ Es frecuente la insatisfacción del cliente, no hay suficiente indagación sobre los requisitos. Poca
comunicación con el cliente.
∗ La calidad es cuestionable. Recién se empieza a comprender la importancia de las pruebas.
∗ El software existente es muy difícil de mantener.
Todos los problemas descriptos pueden corregirse. La clave está en dar un enfoque de ingeniería al desarrollo
del software.

8
Ingeniería del software. Una definición.
∗ El establecimiento y uso de principios de ingeniería robustos para obtener económicamente software
fiable y eficiente.
∗ Disciplina tecnológica para producir y mantener software en tiempo y presupuesto.
Abarca un conjunto de tres elementos claves: métodos, herramientas y procedimientos, que facilitan el
control del proceso de desarrollo y suministran las bases para construir software de alta calidad.
MÉTODOS: indican “como” construir técnicamente el software, esto abarca un amplio espectro de tareas que
incluyen: planificación y estimación del proyecto, análisis de requisitos del sistema y del software, diseño de
estructura de datos, arquitectura de programas y procedimientos, algoritmos, codificación, prueba y
mantenimiento.
HERRAMIENTAS: suministran un soporte automático o semiautomático para los métodos. Cuando se integran
las herramientas de forma que la información creada por una, pueda ser usada por otra se establece un
sistema para el soporte del desarrollo del software, llamado ingeniería del software asistida por computadora
(CASE).
PROCEDIMIENTOS: son el pegamento que une a los métodos y herramientas y facilita un desarrollo racional y
oportuno del software de computadoras. Definen la secuencia en que se van a aplicar los métodos, las
entregas (documentos, informes, etc.) que se requieren, los controles que ayudan a asegurar la calidad y
coordinar los cambios que ayudan a los gestores a evaluar el progreso.

9
Paradigmas.
La ingeniería de software está compuesta por una serie de pasos que 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 se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los
métodos y herramientas a usar y los controles y entregas requeridas. Los paradigmas son tres: ciclo de vida
en fases, construcción de un prototipo y técnicas de cuarta generación.
Ciclo de vida en fases.
A veces llamado “modelo en cascada”, exige un enfoque sistemático y secuencial del desarrollo del software.

Análisis de
requisitos Diseño
Codificación
Prueba
Mantenimiento

a) Ingeniería del sistema: (Planeamiento). Debido a que el software es siempre parte de un sistema mayor,
primero debemos analizar con que elementos debe interrelacionarse (hardware, personas, bases de datos).
b) Análisis de requisitos: El proceso de recopilación de requisitos se centraliza e intensifica especialmente
para el software. Para comprender la naturaleza de los programas a construir debemos comprender el
ámbito de la información, así como la función, el rendimiento y las interfaces requeridas. Los requisitos
tanto del sistema como del software se documentan y revisan con el cliente.
c) Diseño: se enfoca sobre cuatro atributos distintos del sistema: la estructura de datos, la arquitectura del
software, el detalle procedimental y la caracterización de la interfaz. El diseño traduce los requisitos en
una representación del software que pueda ser establecida de forma que obtenga la calidad requerida ates
de comenzar la codificación. Se documenta y forma parte de la configuración del software.
d) Implementación: el diseño debe traducirse en una forma legible en la máquina: codificación y depuración
(verificación de errores).
e) Verificación:
Prueba de integración: se utiliza para probar todas las unidades del sistema en una unidad funcional.
Prueba de aceptación: para demostrar que el sistema implementado responde a las expectativas del
usuario.
f) Mantenimiento: el software sufrirá cambios después de entregado al cliente. Los cambios se deberán a
corrección, adaptación, aumentación.
Desventajas:
1) Los proyectos reales raramente siguen el flujo secuencial, siempre hay interacciones y se crean
problemas en la aplicación del paradigma.
2) Es difícil para el usuario definir todos los requisitos al principio.
3) El cliente debe tener paciencia, hasta la etapa final no ve el sistema. Un error importante no detectado
hasta que el programa este funcionando puede ser desastroso.

10
Construcción de Prototipos.
La construcción de prototipos es un proceso que facilita al programador la creación de un modelo del
software a construir. El modelo puede ser:
− Un modelo en papel: que describa la interacción hombre – máquina.
− Un prototipo que funcione: que implemente algún subconjunto de funciones del
software deseado.
− Un programa existente: que ejecute parte o toda la función deseada, pero que
tenga otras características a ser mejoradas en el nuevo
trabajo de desarrollo.
Comienzo

Parada Recolección y
Refinamiento de
requisitos
Producto Diseño
de ingeniería rápido

Refinamiento Construcción
del de prototipos
prototipo
Evaluación
del prototipo por
el cliente

Pasos:
1) Recolección de requisitos: el técnico y el cliente se reúnen y definen los objetivos globales para el
software, identifican todos los requisitos conocidos y perfilan las áreas en donde será necesario una
mayor definición. No tiene que ser completo como en el ciclo de vida en fases.
2) Diseño rápido: se enfoca sobre la representación de los aspectos del software visibles al usuario (ej.:
métodos de entrada y formato de salida).
3) Construcción del prototipo.
4) Evaluar y refinar los requerimientos: el prototipo construido es evaluado por el cliente / usuario y se
utiliza para refinar los requerimientos del software a desarrollar. Se produce un proceso interactivo en el
que el prototipo es afinado para que satisfaga las necesidades del cliente, al mismo tiempo que facilita al
que lo desarrolla una mejor comprensión de lo que hay que hacer.
5) Producto construido.
Podríamos hacer un modelo de prototipo para el punto de definición de requerimientos del ciclo de vida en
fases, para intentar mejorar la comunicación con el cliente. El prototipo sirve para los requerimientos y luego
se desecha.
La utilización de este paradigma puede ser problemática por las siguientes razones:
a) El cliente ve funcionando lo que parece una versión del software, ignorando que por el apuro en hacer
que funcione no se han considerado los aspectos de calidad y mantenimiento a largo plazo.
b) El técnico de desarrollo realiza frecuentemente ciertos compromisos de implementación para obtener un
prototipo que funcione rápido (ej.: un determinado lenguaje) quizás inapropiado para el sistema, luego
olvida cuales eran las razones por las cuales era inapropiado y termina utilizándolo.
Ventajas:
Aunque se presenten problemas, el prototipo es un paradigma efectivo para la ingeniería de software. Al
comienzo el técnico y el cliente deberán estar de acuerdo en que se construya para servir solo como un
mecanismo para la identificación de requerimientos; luego se descarta y se construye el software real con
miras a la calidad y mantenimiento.

11
Modelo en Espiral
El modelo en espiral para la ingeniería de Software 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, que falta en esos paradigmas. El modelo define cuatro actividades
principales:
1. Planificación: Determinación de objetivos, alternativas y restricciones.
2. Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos.
3. Ingeniería: Desarrollo del producto de “siguiente nivel”.
4. Evaluación del Cliente: Valoración de los resultados de la ingeniería.
Con cada iteración alrededor del espiral, comenzando en el centro y siguiendo hacia el exterior, se
construyen sucesivas versiones del software, cada vez más completas. Durante la primera vuelta alrededor
de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los
riesgos. Si el análisis de riesgo indica que hay incertidumbre en los requisitos, se puede usar la creación de
prototipos en el cuadrante de ingeniería, para dar asistencia tanto al encargado del desarrollo, como al
cliente. Se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos.
El cliente evalúa el trabajo de ingeniería y sugiere modificaciones. En base a 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”. Si los riesgos son
demasiado grandes, se puede dar por terminado el proyecto.
Sin embargo, en la mayoría de los casos se sigue avanzando alrededor del camino de la espiral, y ese camino
lleva a los desarrolladores hacia fuera, haciendo un modelo mas completo del sistema y, al final, al propio
sistema operacional. Cada vuelta alrededor de la espiral requiere ingeniería que se puede llevar a cabo
mediante el enfoque de vida clásico o de la creación de prototipos.
El paradigma del modelo en espiral utiliza un enfoque “evolutivo” para la ingeniería de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza
la creación de prototipos como un mecanismo de reducción del riesgo, pero, lo que es más importante,
permite al que lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución
del producto.
Puede ser difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Requiere una
considerable habilidad para la valoración del riesgo, y cuenta de esta habilidad para el éxito. Si no se
descubre un riesgo importante, indudablemente surgirán problemas.

12
Técnicas de cuarta generación.
Abarcan un conjunto de herramientas (lenguajes no procedimentales para consulta a B.D., generación de
informes, manipulación de datos, definición de pantallas, hojas de cálculo, etc.), que facilitan especificar
algunas características de alto nivel del sistema y luego la herramienta genera el código automáticamente
basándose en la especificación.
Pasos:
Recolección de
requisitos Estrategias
de diseño Implementación con
leng. De 4G Producto

Comienza con la recolección, el cliente describe los requisitos, que son a continuación traducidos
directamente a un prototipo operativo. Sin embargo en la práctica no se puede hacer eso. El cliente puede no
estar seguro de lo que necesita, puede ser incapaz o no desear especificar la información en la forma en que
una herramienta de cuarta generación puede aceptarla.
Para aplicaciones pequeñas se puede ir directamente desde el paso de recolección a implementación en un
lenguaje de cuarta generación. Sin embargo, es necesario mayor esfuerzo para desarrollar una estrategia de
diseño para el sistema. El uso de tecnología de cuarta generación sin diseño, para grandes proyectos, causará
dificultades (poca calidad, mantenimiento pobre, mala aceptación por el cliente).
La implementación en lenguajes de cuarta generación permite, al que desarrolla el software, centrarse en la
representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que
produce dichos resultados.
Para poder transformar una implementación con tecnología de cuarta generación en un producto, el que lo
desarrolla debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar el resto de
actividades de “transición” que se dan en los otros paradigmas.

Ventajas:
Los difusores aducen reducciones dramáticas en el tiempo de desarrollo del software Y una mejora en la
productividad de la gente que construye software.
Desventajas:
Los detractores aducen que las herramientas actuales de cuarta generación no son fáciles de usar, que el
código fuente es ineficiente y el mantenimiento está abierto a discusión.
Ambas posturas tienen su parte de razón. Aunque son difíciles los hechos de las suposiciones pues hay pocos
estudios controlados.
1. En la actualidad su ámbito está limitado a sistemas de información de gestión, concretamente al análisis
de información y a la obtención de informes relativos a grandes bases de datos.
2. En aplicaciones pequeñas los estudios indican que se reduce el tiempo requerido para producir software.
3. Para grandes trabajos exige el mismo o más tiempo de análisis, diseño y prueba.

13
Combinación de Paradigmas.
En muchos casos los paradigmas pueden y deben considerarse de forma que puedan utilizarse las ventajas de
cada uno en un único proyecto.
En todos los casos se comienza con la determinación de objetos, alternativas y restricciones, pasos que se
llaman “recolección preliminar de requisitos”. A partir de ese punto se puede tomar cualquier camino como
indica la figura. Por ejemplo, se pueden seguir los pasos del ciclo de vida si se puede especificar
completamente el sistema al principio de todo. Si los requisitos son inciertos, se puede usar un prototipo para
definir mejor los requerimientos. Usando el prototipo como guía, puede después seguir los pasos del modelo
de ciclo de vida clásico.
Alternativamente, el prototipo puede evolucionar hacia el sistema y volver al paradigma del ciclo de vida en
el momento de prueba.
Usar la tecnología de cuarta generación para implementar el prototipo o implementar el sistema en el paso de
la codificación del ciclo de vida.
No hay necesidad de ser dogmático en la elección del paradigma, la naturaleza de la aplicación debe dictar el
método a elegir.

Mediante la combinación de paradigmas, el todo puede ser mejor que la suma de las partes.

Recolección preliminar de requisitos

Análisis de Prototipado T4G Modelo en

requisitos espiral

Diseño Prototipado T4G

Interacción
n-ésima
Modelo en
Codificación espiral
n-ésima
T4G

Prueba

Sistema en operación

Mantenimiento

14
UNIDAD N° 2: "Ingeniería de Sistemas".
Ingeniería de Hardware y Software.
Un sistema basado en computadoras es un conjunto u ordenación de elementos organizados para llevar a
cabo algún método, procedimiento o control mediante el procesamiento de información.
Los elementos de un sistema basado en computadoras son:
Software: programas, estructuras de datos y la documentación asociada que sirve para realizar el método
lógico, procedimiento o control requerido.
Hardware: los dispositivos electrónicos (CPU, memoria) que proporcionan la capacidad de computación y
los dispositivos electrónicos (ej.: censores) que proporcionan las funciones del mundo exterior.
Gente: los individuos que son usuarios y operadores del software y hardware.
Base de Datos: una colección grande y organizada de información a la que se accede mediante el software.
Documentación: los manuales, los impresos y otra información descriptiva que explica el uso y/o la
operación del sistema.
Procedimientos: los pasos que definen el uso específico de cada elemento del sistema o el contexto
procedimental en que reside el sistema.
Procedimientos

Documentos Hardware

SISTEMA SALIDA
ENTRADA

Base de datos Software

Gente

La definición empieza con la etapa de análisis del sistema. Durante esta etapa se desarrolla una descripción
bien delimitada del alcance del esfuerzo. Para el software se definen los recursos necesarios y se establecen
las restricciones de tiempo y costo. La etapa de planificación tiene como propósito proveer de una indicación
preliminar de la viabilidad del proyecto en la relación de costo y tiempo establecido.
El siguiente paso es el análisis y definición de los requerimientos. En este paso el elemento del sistema
asignado al software se define en detalle. Los requerimientos se analizan y se definen de una de las dos
siguientes maneras:
− El análisis formal del dominio de la información puede ser usado para establecer una representación del
flujo de información y estructura. Estas representaciones se expanden luego para convertirse en una
especificación del software.
− Alternativamente se construye un prototipo de software y es evaluado por el cliente en un intento de
afianzar los requerimientos.

15
Fases Genéricas del software.
El proceso de desarrollo del software contiene tres fases genéricas independientes del paradigma elegido. Las
tres fases, definición, desarrollo y mantenimiento, se encuentran en todos los desarrollos del software
independientes del área de aplicación, tamaño del proyecto o complejidad.
1) DEFINICIÓN: (qué). El que desarrolla el software trata de identificar que información ha de ser procesada,
que función y rendimiento se desea, que interfaces hayan de establecerse, que criterios de validación se
usaran.
Se aplicarán estos tres pasos:
a) Análisis del sistema: trata de definir el papel de cada elemento del sistema, asignando el papel que
jugará el software.
b) Planificación del proyecto: permite analizar riesgos, asegurar los recursos, atenuar los costos,
planificar el trabajo.
c) Análisis de requerimientos: obtener de forma más detallada el dominio de la información y las
funciones más importantes del sistema (elección de metodologías).
2) DESARROLLO: (como). El que desarrolla el software intenta descubrir como han de diseñarse las
estructuras de datos y la arquitectura del software, como han de implementarse los detalles
procedimentales, como ha de trasladarse el diseño a un lenguaje de programación y como se realizarán
las pruebas.
Se aplicarán estos tres pasos:
a) Diseño: (arquitectónico, estructural o detallado). Trata de trasladar los requerimientos del software a
un conjunto de representaciones gráficas, tabulares etc. que permiten describir las estructuras de
datos, arquitectura y procedimientos algorítmicos.
b) Codificación: traslada la representación obtenida en el diseño a un lenguaje (puede ser convencional
o de cuarta generación).
c) Prueba: descubrir los errores en el sistema ya implementado.
3) MANTENIMIENTO: aplica nuevamente los pasos de las fases de definición y desarrollo, pero en el contexto
del software ya existente. En esta fase se encuentran tres tipos de cambios:
a) Corrección: corregir errores de software que descubrió el cliente.
b) Adaptación: realizar módulos para adaptar el sistema a nuevos entornos (por ej.: nueva CPU, nuevo
S.O.).
c) Ampliación: aumento del sistema desarrollado en función de nuevos requerimientos del usuario /
cliente.
Estas tres fases se complementan con:
Recursiones: se realizan durante cada paso para asegurar que se mantiene la calidad.
Documentación: permite que toda la información este disponible para su uso posterior.

16
Estrategias de Solución
El análisis de sistemas se centra en todos los elementos del sistema y no solo en el software y se realiza con
los siguientes objetivos:
1) Identificación de las necesidades:
El analista se entrevista con el cliente y su representante y los objetivos son:
a) Identificar los objetivos del sistema: el analista debe distinguir entre lo que “necesita” el cliente y lo
que “desea”.
b) Identificar funciones importantes.
c) Identificar información que se necesita, rendimiento requerido, límites de costo y tiempo.
Es decir, identificar necesidades del usuario: objetivos, posibilidad de desarrollo en cuanto a
equipamiento, restricciones de costo y tiempo, información a producir y el rendimiento requerido. La
información recogida se especifica en un “Documento de conceptos del sistema”.
2) Estudio de viabilidad:
Se centra en los siguientes puntos básicos: se realiza cuando hay duda de alguno de ellos, de lo contrario
no es necesario.
∗ VIABILIDAD ECONÓMICA: evaluar el costo frente al beneficio final.
∗ VIABILIDAD TÉCNICA: estudio de funcionalidad, rendimiento y restricciones que pueden afectar el
desarrollo del sistema. Las consideraciones que se asocian normalmente son:
− Riesgo de desarrollo: trata de ver si el elemento del sistema se puede realizar de manera que la
función y rendimiento se puedan alcanzar dentro de las restricciones definidas.
− Disponibilidad de recursos: si se tienen los recursos necesarios de hardware, software y personal.
− Tecnología: si está la tecnología adecuada.
∗ VIABILIDAD LEGAL: analizar si violamos la ley con el sistema.
∗ ALTERNATIVAS: una evaluación de enfoques alternativos para el desarrollo del sistema.
El estudio de viabilidad puede documentarse en un informe separado de los otros documentos
importantes de gestión e incluso como apéndice de la especificación del sistema.
3) Análisis económico:
El análisis de costo – beneficio señala los costos de desarrollo del proyecto y los contrasta con los
beneficios tangibles e intangibles del sistema. El análisis de beneficios dependerá de las características
del sistema.
4) Análisis técnico:
Comienza con una definición de viabilidad técnica del sistema propuesto: ¿Qué tecnologías se
requieren?, ¿Qué nuevos materiales, algoritmos y métodos se requieren?. La evaluación analítica no es
siempre posible, sin embargo la modelización es un mecanismo efectivo para el análisis técnico. El
analista comprueba el comportamiento del modelo y lo compara con el mundo real o al sistema esperado,
obteniendo información para la viabilidad técnica del sistema propuesto.
5) Asignación y compromisos:
Una vez que se ha respondido a las cuestiones relativas al análisis hay que considerar soluciones
alternativas. Cada función del sistema con su rendimiento requerido y sus características de interfaz, es
asignada a uno o más elementos del sistema.

17
Modelado de la Arquitectura del Sistema
Todos los sistemas basados en computadora pueden modelarse como la transformación de la información
empleando una arquitectura del tipo Interfaz de Usuario-Entrada-Proceso-Salida-Autocomprobación.
Mediante esta representación un ingeniero, para desarrollar un modelo de sistema, emplea un esquema de
arquitectura, asignando elementos a cada una de las cinco regiones de tratamiento del esquema:
1. Interfaz de Usuario
2. Entrada
3. Tratamiento y Control del Sistema
4. Salida
5. Mantenimiento y Autocomprobación

El resultado es un Diagrama de Contexto de Arquitectura (DCA):

El Diagrama de Contexto establece el límite de información entre el sistema que se está implementando y el
entorno en que va a operar. El DCA define todos los suministradores externos de información que emplea el
sistema, todos los consumidores externos de información creados por el sistema y todas las entidades que se
comunican a través de la interfaz o realiza mantenimiento y autocomprobación. En esencia el DCA sitúa a
cualquier sistema en el contexto de su entorno exterior.
Entre las regiones del DCA se especifica el flujo de información entre las mismas y en cada región se
especifican subsistemas y la información que fluye entre ellos, logrando llegar a
un Diagrama de Flujo de la Arquitectura o DFA.

18
Documento de Especificación del Sistema
Describe la función y el rendimiento de un sistema basado en computadora y las restricciones que
gobernarán su desarrollo.
La especificación del sistema es el primer documento en el proceso de ingeniería de sistemas de
computadoras:
1. Definición del problema: descripción del problema a resolver, situación del sistema actual, información,
archivos, etc.
2. Justificación del sistema: debe justificarse él ¿por qué? de una solución computarizada.
3. Objetivos del sistema: (lo que se quiere alcanzar). Cuantitativo: tiempo de respuesta que tiene que tener
el sistema, etc. Cualitativo: agilizar el control de stock, hacerlo más seguro, etc.
4. Restricciones del sistema: (capacidad del sistema para resolver el problema). Restricciones de hardware. ,
si ya existe hardware hacer restricciones, tipos de respuestas que se necesitan para determinadas
funciones, necesidad de confiabilidad, etc.
5. Funciones a proporcionar: asignar las funciones del sistema a ser provistas por el hardware , el software
(objetivos), el personal. Para cada función del software se discute: información de entrada, procesamiento
e información de salida.
6. Características del usuario: con un organismo de la empresa.
7. Ambiente: ambiente de desarrollo del sistema, de operación y de mantenimiento.
8. Características prioritarias: lista de funciones en cuanto a su prioridad.
9. Criterios de aceptación: pruebas a realizar.
10. Costo: contrato con el usuario.
11. Planificación temporal: cuando el cliente espera el sistema.
12. Términos específicos: a veces es necesario hacer un diccionario porque desconocemos términos del lugar
donde nos contratan.

19
UNIDAD N° 3: "Planificación del Proyecto".
La Planificación del Proyecto es un conjunto de actividades, cuyo objetivo es suministrar un marco de
trabajo que permita hacer estimaciones razonables de recursos, costos y tiempos.
La estimación es la base de todas las actividades de la planificación de proyectos y sirve como una guía para
una buena ingeniería de software. Las estimaciones se hacen dentro de un marco de tiempo limitado al
comienzo de un comienzo de software. Además, las estimaciones deberían definir los escenarios del
“mejor caso” y “peor caso” de forma que los resultados del proyecto puedan limitarse.
Toda estimación tiene un riesgo inherente, cuyo efecto es la incertidumbre. Las estimaciones se ven
afectadas por la familiaridad por esfuerzos similares anteriores, por lo que la disponibilidad de información
histórica también determina el riesgo de la estimación.
El tamaño del proyecto es otro factor importante que puede afectar a la precisión de las estimaciones,
ocasionadas generalmente cuando el cliente cambia los requisitos. Incrementos en el tamaño del proyecto
pueden tener un impacto geométrico en el coste y la planificación del proyecto.
El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por recursos,
costos y planificación temporal.
Las actividades asociadas con la planificación son:
1. Ámbito del Software
2. Recursos
3. Estimación de Costos y Esfuerzo
4. Métricas para el Software
5. Análisis de Riesgo
6. Planificación Temporal
7. Planificación Organizativa

El Documento del Plan de Proyecto incluye la documentación resultante de las actividades anteriores.

1. Ámbito del Software

El Ámbito del Software describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad del
software a implementar. Se evalúan las funciones descriptas en el enunciado el ámbito, y en algunos casos
se refinan para dar más detalles antes del comienzo de la estimación. Dado que las estimaciones del costo y
de la planificación temporal están orientadas a la función, muchas veces es útil llegar a un cierto grado de
descomposición. Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de
procesamiento. Las restricciones identifican los límites del software originados por el hardware disponible y
por otros sistemas existentes.

2. Recursos
Son los recursos requeridos para hacer el sistema, si lo ubicáramos en forma de pirámide en la base se
encuentra el Entorno de Desarrollo (herramientas de software y hardware). En un nivel más alto se ubican
los componentes de software reutilizables y en el nivel más alto se ubica los recursos humanos.
Cada recurso se especifica con las siguientes características:
− Descripción el recurso.
− Informe de disponibilidad.
− Fecha cronológica en que se requiere el recurso.
− Tiempo en el que será empleado.

Tipos de Recursos
∗ HUMANOS: Se debe seleccionar los recursos humanos según las habilidades técnicas que se requieren
para llevar a cabo el desarrollo. El número de personas requerido para un proyecto de software sólo
puede ser determinado después de hacer una estimación del esfuerzo de desarrollo.
∗ SOFTWARE REUTILIZABLE: La utilización de componentes de software existentes lleva a una
reducción importante del costo global.
∗ HARDWARE: Cada elemento de hardware debe ser especificado por el planificador del proyecto de
software.
Se deben considerar tres categorías:
− El sistema de desarrollo: es la computadora y periféricos asociados que se utilizan en la base de
desarrollo.
− La máquina objetivo: es un procesador que ejecutará software como parte del sistema basado en la
computadora.
− Otros elementos: del hardware del nuevo sistema.
∗ SOFTWARE: se utiliza como herramienta para el desarrollo de nuevo software. Existen herramientas
que facilitan la creación de nuevo software (metodologías, código, código reusable, etc.).

20
 3. Estimación de Costo y Esfuerzo
Los factores que influyen en el costo son:
• La capacidad de las personas que van a desarrollar el sistema
• Plazos para la finalización el sistema.
• Conocimiento del área en que se va a desarrollar el sistema
• Complejidad del software
ƒ Programa de aplicación
ƒ Programa de apoyo – ej. : compilador -, programa de sistema – ej. : S.O. –
También influyen:
• El tamaño del programa a desarrollar
• El tiempo disponible de las personas involucradas
• El nivel de confiabilidad determinado en la etapa de planificación
• El nivel tecnológico de lenguajes y equipos a usar.

Nunca será una ciencia exacta, son demasiadas las variables humanas, técnicas de entorno.
Para realizar estimaciones seguras de costo y esfuerzo hay varias opciones posibles:
1. Dejar la estimación para más adelante: 100% fiable al terminar el proyecto, no es práctica.
2. Basar la estimación en proyectos similares ya terminados: los proyectos terminados deben tener
características similares (el cliente, las condiciones de gestión, el Entorno de Desarrollo y los plazos).
En muchas ocasiones no suelen ser buenos indicadores de futuros resultados.
3. Utilizar técnicas de descomposición relativamente sencillas para generar las estimaciones de costo y
de esfuerzo de proyecto.

Modelos de Estimación
Existen técnicas para la estimación de coto y esfuerzo de dos tipos:
Top Down: se estiman los costos globales y después los parciales.
Bottom Up: se estiman los costos de las partes del sistema y luego se obtiene el costo total.
− TÉCNICAS DE DESCOMPOSICIÓN: descompone cada módulo, calcula el costo de cada uno (estimándolo
mediante LCD o PF) y luego resume en general para la estimación global del proyecto.
− ESTIMACIÓN BASADA EN EL PROCESO: es la técnica más común para estimar un proyecto.
o JUICIO EXPERTO: la estimación de todas las tareas, individualmente, la hace una persona
experta usando datos históricos de proyectos realizados con anterioridad, para luego obtener el
costo total.
o DELFI: es una extensión del Juicio Experto, distintas persona (expertas o no) hacen distintas
estimaciones y luego por medio de un coordinador se trata de consensuar el costo total.
− DISTRIBUCIÓN DE ESFUERZOS:

La figura muestra una distribución recomendada del esfuerzo donde se enfatiza el inicio (análisis y
diseño) y el final (prueba). Es solo una directriz. Las características de cada proyecto deben dictar la
distribución del esfuerzo. El esfuerzo gastado en la planificación rara vez supera el 3%. El análisis de
requerimientos puede ir entre el 10% y el 20%. Normalmente se aplica entre el 20% y el 30% para el
diseño del software. Las pruebas y posterior depuración pueden contabilizar del 30% al 50%, el grado
crítico del elemento del sistema de software a menudo dicta la cantidad de pruebas que se requieren. Por
ejemplo: si un fallo puede provocar la pérdida de una vida humana pueden considerarse porcentajes más
altos para la etapa de prueba.

21
 4. Métricas para el Software
Algunas razones por las que se mide el software son:
Ö Hacer una estimación del costo.
Ö Indicar la calidad del producto.
Ö Evaluar la productividad de la gente que desarrolla el producto.
Ö Evaluar los beneficios (en términos de productividad y calidad) derivados del uso de nuevos métodos
y herramientas de ingeniería de software.
Ö Ayudar a justificar el uso de nuevas herramientas o formación adicional.

Las métricas de software tienen un conjunto de características fundamentales que deberían cumplir:
ƒ Simple y fácil de calcular: debería ser relativamente fácil aprender a obtener la métrica y su cálculo
no debería demandar un gran esfuerzo.
ƒ Consistente y objetiva: debería siempre producir resultados sin ambigüedad.
ƒ Independiente del lenguaje de programación: deberían basarse en el modelo de análisis, modelo de
diseño o en la propia estructura del programa.
ƒ Ser un eficaz mecanismo para la realimentación de calidad: debería proporcionar al desarrollador de
software, información que le lleve a un producto final de mayor calidad.
ƒ Consistente en el empleo de unidades y tamaño: el cálculo matemático debería emplear medidas que
no conduzcan a extrañas combinaciones de unidades.

Las métricas pueden catalogarse en directas o indirectas.

Las directas son técnicas cuantitativas (medidas objetivas). Se obtienen del proceso o producto siendo
observado y no dependen de otras medidas. Ej.: el costo y el esfuerzo del proceso, de las líneas de código, el
tiempo de ejecución, el tamaño de memoria requerido, los defectos observados en un período de tiempo.
Las indirectas son técnicas cualitativas (medidas subjetivas), como calidad del software. Dependen de
medidas más elementales. Ej.: la funcionalidad, complejidad, eficiencia, fiabilidad, facilidad de
mantenimiento.

Podemos clasificar las métricas de software en:

− ORIENTADAS AL TAMAÑO: (directa) se utilizan las líneas de código como medida clave. Son bastante
polémicas. Ej. : LDC (líneas de código), KLDC (miles líneas de código). Los defensores ponen
énfasis en lo fácil que es obtener una medida. Los opositores sostienen que la medida depende del
lenguaje y que se pueden hacer programas más cortos y mejor diseñados.
− ORIENTADAS A LA FUNCIÓN: (indirecta) se centran en la utilidad o funcionalidad del programa. Un
ejemplo es el método denominado PF (punto de función) en la medición se involucran las interfaces
externas, número de archivos, número de peticiones de usuario, etc.
El análisis por puntos de función es un método para cuantificar el tamaño y la complejidad de un
sistema software en término de las funciones de usuario que este desarrolla (o desarrollará). Esto hace
que la medida sea independiente del lenguaje o herramienta utilizada en el desarrollo del proyecto.
El análisis por puntos de función está diseñado para medir aplicaciones de negocios; no es apropiado
para otro tipo de aplicaciones como aplicaciones técnicas o científicas. Esas aplicaciones
generalmente median con algoritmos complejos que el método de puntos de función no está diseñado
para manejar.
El enfoque de puntos de función tiene características que sobrellevan los principales problemas de
utilizar líneas de código como métrica del tamaño del software. Primero, los puntos de función son
independientes del lenguaje, herramientas o metodologías utilizadas en la implementación. Segundo,
los puntos de función pueden ser estimados a partir de la especificación de requisitos o
especificaciones de diseño, haciendo posible de este modo la estimación del esfuerzo de desarrollo en
etapas tempranas del mismo. Tercero, como los puntos de función están basados en una visión
externa del usuario del sistema, los usuarios no técnicos del software poseen un mejor entendimiento
de lo que los puntos de función están midiendo. El método resuelve muchas de las inconsistencias
que aparecen cuando se utiliza líneas de código como métrica del tamaño del software.
En resumen, los puntos de función aparecen con ventajas sustanciales por sobre las líneas de código,
para fines de estimación temprana del tamaño del software. Además es una medida ampliamente
utilizada, y con éxito, en muchas organizaciones que desarrollan software en forma masiva.
Esta métrica también es bastante polémica. Los defensores afirman que PF es independiente del
lenguaje de programación, los opositores afirman que el método requiere destreza porque los cálculos
se basan más en la subjetividad que en la objetividad.

22
También se pueden clasificar según la información que entregan:
¾ DE PRODUCTIVIDAD: se centran en el rendimiento del proceso de ingeniería de software.
¾ DE CALIDAD: proporciona una indicación de cómo se ajusta el software a los requisitos implícitos
y explícitos del cliente. Aunque existen muchas formas de medir la calidad, las métricas más
usadas incluyen: corrección, facilidad de mantenimiento, integridad y facilidad de uso.
¾ DE TÉCNICA: se centra en las características del software (por ejemplo: la complejidad lógica o el
grado de modularidad), más que en el proceso a través del cual ha sido desarrollado el software.

Ejemplos de Utilización de Métricas

Orientadas Al Tamaño
LDC - Líneas De Código
Medida directa del software y del proceso:
-- productividad = kldc / persona_mes
-- calidad = errores / kldc
-- costo = $ / kldc
Medida discutida porque depende del lenguaje y necesita una estimación compleja

Orientadas a la Función
PF - puntos de función
Medida indirecta del software y del proceso:
-- productividad = pf / persona_mes
-- calidad = errores / pf
-- costo = $ / pf
Medida independiente del lenguaje, de estimación más fácil pero subjetiva

Calculo del PF:

Parámetros Factor de Peso Resultado

# Entradas De Usuario
# Salidas Al Usuario
# Peticiones Al Usuario
# Archivos
# Interfaces Externas
Total
X … = …
X … = …
X … = …
X … = …
X … = …

PF=TOTAL*[0.65+0.01*SUM(Fi)]
i=1..14
Fi = Valores de ajuste de complejidad

Valores de ajuste de complejidad

0- sin influencia 1- incidental
2- moderado 3- medio
4- significativo 5- esencial

Se debe asignar un valor de ajuste de complejidad a cada una de las siguientes preguntas:
1- copias de seguridad?
2- comunicación de datos?
3- procesamiento distribuido?
4- rendimiento critico?
5- entorno existente?
6- entradas interactivas?
7- múltiples pantallas de entrada?
8- actualización de archivos interactiva?
9- e/s, archivos, peticiones son complejas?
10- procesamiento complejo?
11- Código reutilizable?
12- Se diseño instalación?
13- Es para distintas organizaciones?
14- fácilmente modificable?

23
 5. Análisis de Riesgo
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdida
asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riego:
ƒ Riesgos del Proyecto: Amenazan al Plan de Proyecto. Los riesgos del proyecto identifican los
problemas potenciales de presupuesto, planificación temporal, personal, recursos, cliente y requisitos
y su impacto en un proyecto de software.
ƒ Riesgos Técnicos: Amenazan la Calidad y la Planificación Temporal del software que hay que
producir. Identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de
mantenimiento.
ƒ Riesgos del Negocio: Amenazan la viabilidad del software a construir.
Los cinco principales riesgos de negocios son:
1. Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado).
2. Construir un producto que no encaja en la estrategia comercial general de la compañía (Riesgo
Estratégico).
3. Construir un producto que el departamento de venta no sabe como vender.
4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal
(Riesgo de Dirección).
5. Perder presupuesto o personal asignado (Riesgo de Presupuesto).

Otra forma de categorizar los riegos es:

¾ Riesgos Conocidos: Son todos aquellos que se pueden descubrir después de una cuidadosa
evaluación del Plan del Proyecto, del entorno técnico y comercial en que se desarrolla el proyecto
y otras fuentes de información fiables. Ejemplo: fechas de entrega poco realistas, falta de
especificación de requisitos o de ámbitos de software, o un entorno pobre de desarrollo.
¾ Riesgos Predecibles: Se extrapolan de la experiencia en proyectos anteriores, por ejemplo:
cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a
medida que atienden peticiones de mantenimiento.
¾ Riesgos Impredecibles: Son extremadamente difíciles de identificar por adelantado.

Identificación del Riego

La identificación del riego es un intento sistemático para especificar las amenazas al Plan de Proyecto.
Identificando los riegos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos
cuando sea posible y controlarlos cuando sea necesario. Un método para identificar riesgos es crear una lista
de comprobación de elementos de riesgo, que consiste en una serie de preguntas a posibles riegos y las
respuestas, analizadas en el Plan de Proyecto.

Proyección del Riesgo

La proyección del riego, también llamada estimación del riesgo, intenta medir cada riesgo de dos maneras:
- La probabilidad de que el riesgo sea real.
- Las consecuencias de los problemas asociados con el riesgo, si ocurriera.

Evaluación del Riesgo

Se intenta dar prioridades a los riesgos que no se habían cubierto y se empieza a pensar las maneras de
controlar y/o impedir los riesgos que sean más probables que aparezcan. La evaluación del riego definirá un
nivel de referencia del riesgo, que posee un único punto de referencia o punto de ruptura, que marcará la
decisión de seguir con el proyecto o dejarlo.

Tratamiento del Riesgo

Una estrategia eficaz para tratar los riesgos debe considerar tres aspectos:
1. Evitar el Riesgo: Se plantean las estrategias para evitar los riesgos.
2. Supervisar el Riesgo: Se identifican los factores que pueden proporcionar una indicación de si el
riesgo se está haciendo más o menos probable. A medida que progresa el proyecto, comienzan las
actividades de supervisión del riesgo. El jefe de proyecto supervisa estos factores.
3. Gestión del Riesgo y Planes de Contingencia: Asume que los esfuerzos de reducción ha fracasado y
que el riesgo se ha convertido en una realidad. Se establecen los Planes de Contingencia para el
riego.

24
 6. Planificación Temporal
Puede verse desde dos perspectivas diferentes:
− La fecha final ya está establecida, la establece el cliente.
− La fecha final es organizada por el que realiza el software.

Si un cliente solicita a un grupo de desarrollo de software la construcción de un producto en un tiempo

determinado, y después de una cuidadosa estimación y análisis de riesgo, el gestor de análisis de riesgo llega
a la conclusión de que el software, tal y como se ha pedido, requerirá más tiempo para crearlo que el
estipulado por el Cliente, se pueden seguir los siguientes pasos:
1. Realizar una estimación detallada usando información de proyectos anteriores.
2. Empleando un modelo incremental, establecer una estrategia de desarrollo que proporcione una
funcionalidad critica mínima para la fecha impuesta. Las demás funcionalidades se implementarán
más tarde.
3. Reunirse con el cliente y empleando la estimación detallada, explicarle porque la fecha límite
impuesta no es realista.
4. Ofertar la estrategia de desarrollo incremental como alternativa. Se puede también proponer al
cliente un aumento de personal, pero ello implicaría un aumento en los costos.

La Planificación Temporal objetiva de un proyecto es necesaria porque si se retrasa el proyecto, la solución

de sumar más personal al proyecto no es siempre aconsejable pues el personal agregado debe aprenderse el
sistema y la gente que les enseña es la misma que estaba trabajando, y el proyecto se retrasa todavía más.

Para desarrollar una Planificación Temporal del proyecto, se debe distribuir un conjunto de tareas a lo larga
de la duración del proyecto. El conjunto de tareas variará dependiendo del tipo de proyecto.

El propósito de controlar un proyecto es monitorear su progreso según un plan, detectando desviaciones si

las hay. Al planificar se debe ver como se relacionan el tiempo y el esfuerzo humano, como se divide el
trabajo, que acciones son paralelas, como representar la agenda, etc. Para mejorar el control se divide el
objetivo en submetas. Identificar las submetas permite asignar estimaciones, responsabilidades, fechas de
inicio y fin, establecer la red de tareas. etc., estableciendo un calendario. Hay técnicas para ayudar a
establecer estos calendarios como son los diagramas de Gantt y PERT.

La técnica de evaluación y revisión de programas (Pert) y el método de camino crítico (CPM) son dos
métodos de planificación temporal de proyectos que pueden aplicarse al desarrollo de software.
Ambas técnicas desarrollan una descripción de la red de tareas del proyecto, es decir una representación
gráfica o tabular de las tareas que deben acontecerse desde el principio hasta el final del proyecto.
La red se define desarrollando una red de tareas asociadas con el proyecto y una lista de ordenamientos que
indica en que orden debe ir cada tarea.
El camino crítico se puede definir como la cadena de tareas que determina la duración del proyecto. Tanto
Pert como CPM permiten determinar el camino crítico, establecer las dimensiones de tiempo más probables
para las tareas individuales, aplicando modelos estadísticos y calcular los tiempos límites de cada tarea,
estimando el tiempo total del proyecto.
Las limitaciones de tiempo que pueden discernirse de una red Pert o CPM pueden ser:
ƒ Tiempo Temprano: Lo antes posible que se puede comenzar una tarea cuando todas las tareas
precedentes se terminan con el mínimo de tiempo posible.
ƒ Tiempo Tardío: Lo más tarde que se puede iniciar la tarea sin que se retrase el tiempo mínimo
de finalización del proyecto.
ƒ Fecha más Temprana de Finalización: Es la suma del tiempo temprano de la tarea más la
duración de la tarea.
ƒ Fecha Límite de Finalización: Es el tiempo tardío de tarea más la duración de la tarea.
ƒ Margen Total: La cantidad de tiempo extra o atrasos permitidos en la planificación temporal de
las tareas, de manera que el camino crítico de la red se mantenga conforme con la planificación
temporal.

25
MÉTODO PERT
1. Establecer la lista de tareas.
2. Construir una red (grafo dirigido). Nodo: inicio y fin de cada tarea.

i j
t i, j: acontecimientos
t: tarea

3. Numerar los nodos

t0i t1i
Nro.

t0i tiempo temprano: Es el mayor valor que aparece en las puntas de las flechas que llegan a ese
nodo, es la suma de t0 del nodo anterior más la duración de la tarea.
t1i tiempo tardío: Se calcula como el menor valor de cada una de las flechas que de él parten.

4. Calcular el camino crítico.

El camino crítico lo forman las tareas críticas o nodos críticos.
Nodo crítico: cuando el tiempo temprano es igual al tiempo tardío (t0i = t1i).

No hay circuitos en el grafo y todos los nodos, excepto el primero y el final deben tener una tarea de la cuál
inicio o fin de duración. Ej.: pág. 68 carpeta.
Se empieza con los que no tienen ninguna dependencia, se calcula primero la fecha temprana, en cada uno de
los nodos la duración de la tarea.
El número (Nro.) indica que vamos a finalizar en el instante número y t0i = t1i indica que no vamos a
postergar su finalización.

GRÁFICO DE GANTT
Es un gráfico de tiempo que Permite establecer un calendario de las actividades o tareas. También se pueden
usar para la asignación de recursos.
1. Cada tarea tiene como entrada el esfuerzo, la duración y la fecha de inicio. Además se asignan las
tareas a individuos específicos. Como consecuencia de esta entrada se genera un gráfico de tiempo,
que permite vitalizar el desarrollo del proyecto, la concurrencia de tareas y las submetas importantes.

26
 7. Planificación Organizativa
Organización de las personas que están involucradas en el desarrollo del proyecto.

ORGANIZACIÓN DEL PROYECTO:

El proceso de la dirección denota el influjo interpersonal mediante el cual los gerentes o directores se
comunican con sus subalternos para la ejecución de un trabajo. No existe una estructura organizacional
perfecta para manejar los distintos tipos de proyectos. Existe una variada gama de estructuras
organizacionales:
− Organización Funcional: Es la forma de organización más común y se basa en la estructura
jerárquica básica. Esta organización generalmente se descompone en varias unidades funcionales
(equipos) diferentes, distribuyendo las tareas.
La razón de ser de esta estructura radica en las teorías de administración basadas en la
especialización, las cuales consideran que es más fácil dirigir a especialistas si estos son agrupados
según su especialidad y el jefe de departamento tiene conocimientos de esa disciplina en particular.
Este tipo de organización posee ventajas que descansan sobre su centralización de recursos similares,
ya que, por ejemplo, brinda caminos de integración claros y bien definidos para especialistas jóvenes
y además, la ayuda mutua es fácilmente encontrada gracias a la proximidad física. Sin embargo, este
tipo de organización posee debilidades. Por ejemplo, cuando se trabaja en proyectos múltiples,
generalmente surgen problemas por el uso de los recursos. Otro ejemplo a citar es el de que cada
departamento funcional pone énfasis en su especialidad más que en los objetivos del proyecto. Pese a
esto, la mayoría de las compañías usan este tipo de organización no sólo para sus proyectos, sino para
todas sus actividades.
− Organización por Proyecto: Representa el opuesto a la organización funcional. El mismo equipo
de personas realiza todo el desarrollo desde el análisis hasta el mantenimiento.
En una organización de proyecto, todos los recursos necesarios para realizar un proyecto son
separados de sus unidades funcionales regulares y se reúnen como una unidad independiente de
trabajo dirigida por un jefe de proyecto. Al jefe de proyecto se le concede una amplia autoridad sobre
los recursos del proyecto y pueden adquirir nuevos recursos ya sea dentro o fuera de la organización.
Todo el personal del proyecto esta bajo la autoridad del jefe de proyecto por el periodo que el
proyecto dure.
Las ventajas de este tipo de organización vienen de su objetivo único y su unidad de comando. Se
desarrolla un verdadero espíritu de equipo bajo el claro entendimiento de, y enfocado a, un objetivo
único. La comunicación informal es efectiva en un equipo fuertemente enlazado, y el director de
proyecto tiene todos los recursos bajo su disposición.
Sin embargo, la organización de proyecto no es la solución perfecta para todos los problemas de la
dirección de proyectos, ya que por lo general, las instalaciones se duplican y los recursos son
utilizados de forma ineficiente. Otro problema serio radica en que se produce inestabilidad laboral
luego de terminado el proyecto temporal.
− Organización Matricial: varios equipos de personas lleva a cabo distintas tareas, pero cada equipo
tiene un coordinador que controla el equipo y hay un jefe de todo el proyecto.
La organización de matriz es una estructura multidimensional que trata de maximizar los puntos
fuertes y minimizar los débiles tanto de la estructura funcional como la de proyectos. Combina la
estructura jerárquica vertical estandard con una estructura lateral u horizontal sobrepuesta de un
coordinador de proyecto.
Los mayores beneficios de la estructura de matriz son el balance de objetivos, la coordinación a través
de las líneas de los departamentos funcionales, y la visibilidad de los objetivos del proyecto a través
de la oficina del coordinador de proyecto.
La mayor desventaja es que el hombre en el medio trabaja para dos jefes. Verticalmente, responde al
jefe del departamento funcional. Horizontalmente, responde al coordinador de proyecto o jefe de
proyecto. En una situación de conflicto puede quedar atrapado en el medio.
El director de proyecto a menudo siente que no posee la autoridad suficiente sobre los departamentos
funcionales. Por otro lado, el jefe del departamento funcional a menudo siente que el coordinador de
proyecto esta interviniendo en su territorio.

La elección final de la Estructura de Organización deberá venir luego de considerar varios factores de la
naturaleza de la tarea a realizar, las necesidades de la organización y el ambiente del proyecto.
Es también posible ocupar las tres estructuras en una misma compañía, en diferentes proyectos. También
todas estas estructuras pueden ser utilizadas en un mismo proyecto en diferentes niveles –por ejemplo, una
organización global de matriz con estructura funcional en ingeniería y una organización de proyecto dentro
de otra sub-área funcional.
Aunque hay argumentos a favor y en contra de cada alternativa, la opción general cada vez se inclina más
hacia la organización en forma matricial, vislumbrándose como la más productiva.

27
ORGANIZACIÓN DE GRUPO:
Se refiere a la organización interna de los grupos de trabajo.
− Democrático: no hay un jefe general, todos participan de la toma de decisiones.
− Con jerarquía: existe una cabeza conductora.

Los equipos pueden estar asesorados por uno o más especialistas, por plantillas de soporte (ejecutivos) y por
un bibliotecario de software.

SEGUIMIENTO Y CONTROL:
Quien controla que el proyecto se cumpla.
− Interno: realizado por las personas que hacen el desarrollo.
− Externo: auditorias o empresas que realizan la verificación.

8. Documento del Plan de Proyecto

Proporciona una línea de base con información de costos y de agenda que se utilizará a lo largo del plan de
vida del software.
1. Modelo del ciclo de vida: se elige el paradigma a utilizar.
2. Estructura organizacional: se decide la estructura para nuestra organización. Estructura de
administración, de equipos, de distribución de trabajo, definición de puestos.
3. Personal y recursos: cuantas personas se necesitan y qué recursos físicos.
4. Plan temporal: Pert - Gantt.
5. Estimación de costos.
6. Revisión del proyecto: Mecanismos de supervisión y control del proyecto; cuantos, cuales y en que
momento se van a realizar.
7. Herramientas y técnicas.
8. Lenguaje de programación.
9. Pruebas: se determina que tipo y cuando se realizan las pruebas, depende del ciclo de vida utilizado.
10. Documentación.
11. Entregas: que entregas se harán (parciales o finales).
12. Entrenamientos y Materiales: quien, como y a quien se va a entrenar.
13. Plan de Instalación.
14. Mantenimiento: quien lo va a hacer.
15. Método y Tiempo de la Entrega Final.
16. Forma de pago.
El plan de proyecto se produce como culminación de la etapa de planificación.

28
UNIDAD N° 4: “Análisis de Requerimientos”.
Para realizar bien el desarrollo del software es esencial realizar una especificación completa de los
requerimientos de los usuarios. Independientemente de lo bien diseñado o codificado que este, un programa
pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La tarea del análisis de requisitos es un proceso de descubrimiento y refinamiento.
El análisis de requerimientos es la tarea que plantea la asignación de software al nivel de sistema y al diseño
de programas. Facilita al ingeniero de sistemas especificar la función y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el
programa.
El análisis de requisitos permite al ingeniero de software refinar la asignación del software y construir
modelos de los ámbitos del proceso, de los datos y del comportamiento que serán cubiertos por el software.
El análisis de requerimientos proporciona al diseñador una representación de la información y de las
funciones que se pueden traducir a un diseño de datos arquitectónico y procedimental.

Tareas del análisis.

El análisis se divide en cuatro áreas:
∗ RECONOCIMIENTO: el analista establece contrato con el cliente y la organización de desarrollo, estudia la
especificación y el plan de proyecto, de forma que se asegure el reconocimiento del problema.
∗ EVALUACIÓN Y SÍNTESIS: el analista debe evaluar el flujo y la estructura de la información, definir y
evaluar todas las funciones del software, entender el comportamiento del programa en el contexto de los
sucesos que afectan al sistema, establecer las características de la interfaz y de cubrir las restricciones de
diseño.
El analista se centra básicamente en el “que”, no en el “como”. ¿Qué datos produce y consume el
sistema? ¿Qué funciones debe realizar?.
∗ ESPECIFICACIÓN: para definir las características y atributos del software se escribe una especificación de
requerimientos formal. Además para los casos en que no se desarrolla un prototipo se realiza un manual
del usuario preliminar.

REVISIÓN: los documentos del análisis de requerimientos sirven como base para una revisión conducida por
el cliente y el técnico. La revisión de los requerimientos casi siempre produce modificaciones en la función,
comportamiento, representación de la información, ligaduras o criterios de validación.

Problemas del análisis de requisitos.

El análisis de requerimientos es una actividad de intensa comunicación.
Entre otros problemas se encuentra dificultad en la adquisición de información, el manejo de la complejidad
del problema, y a la gestión de los cambios que puedan ocurrir durante y después del análisis.
Los problemas subyacentes al análisis de requerimientos son atribuibles a muchas causas:
− Comunicación pobre: que hace difícil la adquisición de información.
− Técnicas y herramientas inadecuadas: que producen especificaciones inadecuadas o imprecisas.
− Análisis de requerimientos acotado: existe una tendencia a acotar el análisis de requerimientos,
conduciendo a un análisis inestable.
− Fallo en considerar alternativas antes de que se especifique el software.

29
Principios Fundamentales del Análisis.
En la pasada década, se desarrollaron varios métodos de análisis y especificación del software. Cada método
de análisis tiene única notación y punto de vista, pero todos ellos están relacionados por un conjunto de
principios fundamentales:
1) Dominio de la información:
El dominio de la información de un problema debe representarse y entenderse. El dominio de la
información tiene tres visiones diferentes de los datos que se procesan por los programas:
− EL FLUJO DE LA INFORMACIÓN: representa como cambian los datos y el control, a medida que se
mueven dentro de un sistema. La entrada se transforma en datos intermedios y después en datos de
salida.
− EL CONTENIDO DE LA INFORMACIÓN: representa los elementos de datos individuales, de datos o de
control, que componen otros elementos mayores de información.
− LA ESTRUCTURA DE LA INFORMACIÓN: representa la organización lógica de los distintos elementos
de datos o de control.
2) Dominio Funcional:
Deben definirse las funciones que debe realizar el software.
3) Comportamiento del Software:
Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos).
4) División del problema:
Normalmente los problemas son demasiado grandes y complejos para ser comprendidos como un todo.
Por eso, tendemos a particionarlos.
5) Alcance:
El proceso de análisis debería ir de la información esencial hasta el detalle de la implementación.

Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se examina el dominio de la

información de un modo que pueda entenderse completamente la función. La partición se aplica para reducir
la complejidad. Son necesarias las visiones esenciales y de implementación del software para acomodar las
restricciones lógicas impuestas por los requerimientos del procesamiento, y las restricciones físicas
impuestas por otros elementos del sistema.

Construcción de Prototipos.
En muchos casos no es posible especificar completamente un problema en una etapa tan temprana. La
construcción de prototipos ofrece un método alternativo que da como resultado un modelo ejecutable del
programa desde el cual pueden refinarse los requerimientos.
Para construir los prototipos se aplican los siguientes pasos:
1) Evaluar las peticiones del software para determinar si el software a desarrollar es un buen candidato para
la construcción de un prototipo. Los factores para saber si es un buen candidato son: área de aplicación,
complejidad de aplicación, características del cliente y del proyecto.
Es esencial que el cliente participe en la evaluación y refinamiento del prototipo y que sea capaz de tomar
decisiones de requerimiento de forma oportuna.
2) Desarrollar una representación abreviada de los requerimientos.
3) Crear una especificación de diseño abreviada para el prototipo, luego de revisar la representación de
requerimientos.
4) Construir el prototipo, probar y refinar.
5) Una vez probado el prototipo, se presenta al cliente. El cliente conduce la prueba y sugiere
modificaciones.
6) Modificaciones: los pasos 4 y 5 se repiten hasta que el prototipo haya evolucionado hacia el sistema de
producción, reuniendo todos los requerimientos del cliente y se perfeccionen sus errores o falencias.
Métodos y herramientas para la construcción.
Para que la construcción de prototipos sea efectiva, un prototipo debe desarrollarse rápidamente, de forma
que el cliente pueda comprobar los resultados y recomendar cambios. Para conseguir una construcción
rápida, existen tres clases genéricas de métodos y herramientas:
− TÉCNICAS DE CUARTA GENERACIÓN: son ideales debido a que facilitan código ejecutable rápidamente.
− COMPONENTES DE SOFTWARE REUSABLES: ensamblar en lugar de construir el prototipo, usando
componentes existentes.
− ESPECIFICACIÓN FORMAL: son lenguajes que facilitan al analista crear interactivamente una
especificación. Llaman a herramientas automáticas que traducen especificaciones en código ejecutable y
facilitan al cliente utilizar este código para refinar los requerimientos formales.

30
Características de la Especificación.
La forma de especificar tiene mucho que ver con la calidad de la solución.
− Puede ser en papel (DFD), ejecutable (prototipo) o formal (lenguaje formal).
− Total y Completa.
− Consistente.
− Sin ambigüedades.
− “Que” y no “como”.
− Funcionalidad.
− Verificable.
− Modificable.
− Formal.
− Refleje Dinamismo.
− Representación Adecuada del Problema.
− Por niveles.
− Notación Consistente.

Técnicas Formales de Especificación.

Una especificación es formal si está en un lenguaje cuyo vocabulario, sintaxis y semántica están definidos
formalmente, por lo que en general están basados en matemáticas. Las Técnicas Formales sirven para
especificar las características funcionales y de comportamiento del sistema. Una de las razones más fuertes
para usar especificaciones formales es que éstas ayudan a detectar errores y omisiones.

Características:
ƒ Concisas y no ambiguas
ƒ Apoyan el razonamiento formal
ƒ Dan una base para la verificación de resultados

Las especificaciones formales no se usan mucho por el esfuerzo que requiere escribirlas. Sin embargo existe
evidencia que al usarlas se incremente la calidad del sistema y se reducen los costos de desarrollo. En la
siguiente figura se ilustra como la especificación formal se relaciona con otras actividades de desarrollo.

Ventajas:
1. Desarrollar una especificación formal permite un buen entendimiento de los requerimientos del software y
proporciona la base para un diseño más confiable del software ayudando a reducir errores y omisiones.
2. Como las especificaciones formales están compuestas por entidades matemáticas, pueden analizarse
usando métodos matemáticos, por lo que puede probarse consistencia y completitud, así como demostrar que
la implementación se corresponde a la especificación.
3. Pueden procesarse automáticamente usando herramientas que ayuden a desarrollar, entender y depurarlas.

Las especificaciones pueden ayudar a definir los casos de prueba en la verificación, de hecho se inició su
estudio para apoyar la verificación de programas. Dependiendo del lenguaje formal que se use, se puede
construir un prototipo.

31
Razones por las que no se usan mucho:
1. No se adoptan nuevas técnicas que no se este claro que reduzcan costos.
2. Muchos desarrolladores no han sido entrenados en su uso, en matemáticas o lógica.
3. No se esta familiarizado con esas técnicas.
4. No son fáciles de usar para componentes interactivos de interfaces, procesamiento paralelo o sistemas
dirigidos por interrupciones.
5. Hay pocos sistemas especificados formalmente.
6. Mucho del esfuerzo de investigación se ha dedicado a notaciones y técnicas más que en herramientas de
soporte.
7. Los que desarrollan especificaciones formales no entienden a los que hacen ingeniería de software
práctica.
En general hay métodos formales maduros para sistemas secuenciales, hay avances en concurrencia que
requieren más refinamiento.

Existen dos técnicas:

Relacionales: se basan en definir las entidades y los atributos.
Orientadas a Estados: se basan en describir los estados de las entidades en un momento dado.

Relacionales.
− Ecuaciones implícitas: establecen las propiedades de una solución sin establecer el método para
resolverlo. Ej.: M * M’ = I (dice qué voy a hacer y no como).

− Relaciones recurrentes: se utiliza para especificar funciones recurrentes, para describir el valor de una
función en función de otros valores de la misma función. Ej. : Fibonacci f(0) = 0; f(1) = 1; f(n) = f(n – 1)
+ f(n – 2) con n > 1.

− Axiomas algebraicos: establecen las propiedades de una función definiendo un conjunto de axiomas y
también demuestran teoremas por medio de los axiomas.
Una especificación algebraica es una técnica en la que un objeto o tipo de datos se especifica en términos
de las operaciones definidas en este tipo (el álgebra). Este estilo de especificación esta basado en el uso
del álgebra y definen a un sistema como un álgebra heterogénea, por ejemplo, una colección de conjuntos
diferentes que tienen a un conjunto de operaciones definidas. Hay varias notaciones para especificaciones
algebraicas, todas con características comunes. Una característica importante que debe cumplir cualquier
lenguaje de especificación formal y en particular las algebraicas es promover la modularidad.
a) Sintaxis de operadores: (ej. : pila)
nuevo() → pila tope(pila) → elem
pone(pila, elem) → pila vacío(pila) → V o F
extrae(pila) → pila

Axiomas: (relación entre los operadores)

vacío(nuevo) = V tope(nuevo) = error
vacío(pone(pila, elem)) = F extrae(pone(pila, elem)) = pila
extrae(nuevo) = error tope(pone(pila, elem)) = elem
b) Teorema:
reemplazo (pila, elem) = error, si vacío(pila) = V
o pone(extrae(pila), elem)

− Expresiones regulares: se basan en la descripción de un alfabeto y reglas sobre dicho alfabeto. Ej. :
átomos = a, b, c (componentes del alfabeto)
alternación a|b = {a, b} (elige una de las dos)
composición (a b) = {a b}
iteración (a)* = {e, a, aa, aaa,...}
(a)+ = {a, aa, aaa,...} = (a)* - e

32
Orientadas a estados.
El estado siguiente se obtiene aplicándole un estímulo al estado anterior.

− Tablas de Decisión:
Trasladan las condiciones y acciones descriptas en un texto narrativo del procesamiento, a una forma
tabular. Permiten al módulo evaluar una combinación compleja de condiciones y seleccionar las acciones
apropiadas basándose en esas condiciones. Las reglas son 2n, donde n es el número de condiciones. Las
columnas son “reglas de decisión”.

Regla 1 Regla 2 … Regla “n”

Condición 1 Especificación Especificació Especificación Especificació
Condición 2 de n de de n de
… Condiciones Condiciones Condiciones Condiciones
Condición “k” (V,F) (V,F) (V,F) (V,F)
Acción 1 Especificación Especificació Especificación Especificació
Acción 2 de Acciones de n de Acciones de Acciones n de Acciones
… (X) de (X) de (X) de (X)
Acción “t”

Una tablas es completa si para cada posible decisión hay una acción, no se deja ninguna regla sin contemplar.
Una tabla es incompleta en caso contrario.
Una tabla es ambigua o contradictoria si para dos reglas iguales tenemos dos acciones distintas
(contradictoria) y cuando dos columnas de decisión dicen lo mismo (redundante).

Para desarrollar una tabla de decisión se aplican los siguientes pasos:

1. Hacer una lista de todas las acciones que pueden asociarse con un procedimiento específico ó
módulo.
2. Hacer una lista de todas las condiciones o decisiones tomadas durante la ejecución del
procedimiento.
3. Asociar conjuntos específicos de condiciones con acciones específicas, eliminando
combinaciones imposibles de condiciones; alternativamente, desarrollar cualquier permutación
posible de combinaciones.
4. Definir reglas indicando que acción o acciones ocurren para un conjunto de condiciones.

Ejemplo: Sistemas de facturación de un servicio público.

Si la cuenta del cliente se factura usando un método de tarifación fijo, se establece un cargo mensual
mínimo para consumos de 100 kWh (kilowatios-hora). En los demás casos, la facturación por
computadora aplica la tarifa A. Sin embargo, si la cuenta se factura usando un método de facturación
variable, se aplicará la tarifa A para consumos por debajo de 100 kWh, con un consumo adicional
facturado de acuerdo con la tarifa B.

1 2 3 4 5
Cuenta de Tarifa Fija V V F F F
Cuenta de Tarifa Variable F F V V F
Consumo < 100 KWH V F V F
Consumo >= 100 KWH F V F V
Cargo Mensual Mínimo X
Facturación Tarifa A X X
Facturación Tarifa B X
Otro Tratamiento X

33
− Tablas y Diagramas de Transición:
El Diagrama de Transición de Estados (DTE) representa el comportamiento de un sistema que muestra
los estados y los sucesos que hacen que el sistema cambie de estado. En lugar de un diagrama se puede
usar una representación tabular. Además el DTE indica que acciones (por ejemplo, activación de
procesos) se llevan a cabo como consecuencia de un suceso determinado. Un estado es un modo
observable de comportamiento. Un DTE indica como pasa un sistema de un estado a otro.
Se representan los estados de E/S posibles y en la tabla se refleja cuál es el estado resultante al aplicar
cierta entrada a un estado. Ej. :
a a
Estado Entrada
Actual a b b
S0 S1
S0 S0 S1
S1 S1 S0
b

Ej.: Se reciben telegramas que comienzan con INTEL y terminan con FINTEL. Cada telegrama está
formado por frases, cada frase está compuesta por palabras y termina con la palabra STOP. Al terminar
cada frase hay que imprimirla.

Palabras
Recibir
INTEL frase STOP

Recibir
telegrama Imprimir
Palabras frase
FINTEL

− Mecanismos de Estados Finitos:

Un Mecanismo de Estado Finito combina los DFD, las expresiones regulares (para flujos de datos) y las
tablas de transición para realizar la descripción más detallada de los procesos del DFD incluyendo los
distintos estados por los que puede pasar cada proceso. Los estados de cada proceso dependen de los
datos de entrada del mismo.

34
− Redes de Petri:
Se diseñaron para especificar y modelizar sistemas con componentes concurrentes o que requieren
paralelismo, sincronización, etc., sobre todo sistemas de tiempo real.
Tienen dos elementos fundamentales:
- Eventos: actividades que estoy modelizando.
- Condiciones: precondiciones o postcondiciones para esos eventos. De la validez o no de las
precondiciones depende la ejecución de la actividad para que se cumplan las postcondiciones.

En términos formales se define como una cuaterna:

C = (lugares, transiciones, arcos, tokens)
Lugares: condiciones (pre/post). Se definen como un conjunto {P1,..., Pn}. Representadas gráficamente
por círculos.
Transiciones: tareas {t1,..., tn}. Representadas gráficamente con una barra.
Arcos: relaciones entre condiciones y tareas. {(Pi, tj),..., (tk, P1)}. Conectan Lugares y Transiciones.
precond. para tj postcond. para tk
Tokens: marcaciones en los lugares o condiciones {M(Pi) = x}, donde x es la cantidad de Tokens o
marcaciones en los lugares.

Para habilitar las transiciones: una transición está habilitada cuando cada lugar (Pi) tiene al menos tantos
tokens como arcos a la transición
.
Cuando disparo una transición habilitada:
1. Remuevo los tokens de lugares de entrada (Precondiciones)
2. Distribuyo tokens en lugares de salida (Postcondiciones).
3. Cambio la marca.
Ej. :

1 token en P1 ⇒ puedo
habilitar t1, significa pasar un
token a P2, P3 y P4 ⇒ puedo
habilitar t2, esto implica
poner un token en P5.

Expresión de paralelismo:
Esto implica que se tienen que
ejecutar en forma paralela para
poder llegar al final. Empiezan y
terminan juntos.

Este se llega a ejecutar cuando los 3

anteriores terminan.

35
Expresión de exclusión mutua:
Puedo disparar t1 o t2. Pero sí primero
P1 • P2 • P3 • ejecuto una, después la otra ya no la
podré ejecutar.
t1 t2

Condición de bloqueo:
0 1 t1 y t2 están bloqueados pues para
1 0
P0 P1 P2 P3 para poder disparar t1 necesito
disparar t2 pero para t2 tengo que
t1 t2 disparar t1.

∴no lo puedo resolver.

Problema: sección crítica

Problema: productor - consumidor:

36
Redes de Petri
Ejemplo
C = (P, T, I, O)
P = {p1, p2, p3, p4, p5} T = {t1, t2,
t3, t4}
I (t1) = {p1} O (t1) = {p2, p3, p5}
I (t2) = {p2, p3, p5} O (t2) = {p5}
I (t3) = {p3} O (t3) = {p4}
I (t4) = {p4} O (t4) = {p2, p3}

Análisis de Redes de Petri

• Permiten evaluar el modelo
• Podemos verificar
– Ausencia de deadlock
– Alcanzabilidad
– Seguridad

Ejemplo: Fábrica y Pedidos

La fábrica espera hasta un pedido, lo produce y lo envía para su entrega.
Las condiciones son:
A. Fábrica esperando
B. Pedido esperando
C. Fábrica trabajando
D. Pedido completo
Las Eventos son:
1. Llega un pedido
2. La fábrica comienza con el pedido
3. La fábrica termina con el pedido
4. El pedido es enviado para su entrega

Precondiciones & Postcondiciones:

Eventos Precondiciones Postcondiciones

1 ninguna b
2 a, b c
3 c d, a
4 d ninguna
• Condiciones -> modelamos con sitios
• Eventos -> modelamos con transiciones
• Precondiciones -> Entradas a transiciones
• Postcondiciones -> Salidas de transiciones

Gráfico

37
Documento de Especificación de Requerimientos (SRD).
Objetivos.
1. Descripción de la información: flujo / contenido / estructura / interface / DFD.
2. Descripción funcional: partición del sistema, explicación de las funciones, rendimiento esperado de las
funciones, sugerencias de diseño, se pueden usar las técnicas formales para describir las funciones.
3. Criterios de validación: que criterios se van a tener en cuenta para validar el sistema, costo del
rendimiento, clases de test, respuesta esperada, consideraciones especiales.
4. Diccionario de datos asociados: el que desarrolla el software y el cliente deben realizar una revisión de la
especificación de requerimientos de software (y el prototipo). Debido a que la especificación constituye
el fundamento de la fase de desarrollo, se debe tener un cuidado extremo en realizar esta revisión.
Una vez completada la revisión queda terminada la especificación de requerimientos de software y se
convierte en un “contrato” para el desarrollador.

“Metodologías de Análisis de Requerimientos”.

ƒ Orientadas al Flujo de Datos.
ƒ Orientadas a la Estructura de Datos.
ƒ Orientadas al Objeto. (comparte las dos anteriores)

Orientados al Flujo 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 gráfica que describe el flujo de la
información y las transformaciones que se aplican a los datos conforme se mueven de la entrada a la salida.

Entidad Entidad
externa Inf. de e/ Inf. de s/ externa
Sistema
basado en
computadora
Entidad Entidad
externa Inf. de e/ Inf. de s/ externa

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 DFD’s pueden ser refinados en niveles que representan un mayor flujo de la
información y un mayor detalle funcional.
Un DFD de nivel 0 también se denomina modelo fundamental del sistema o modelo de contexto y
representa el elemento de software completo como una sola burbuja con datos de entrada y salida
representados por flechas de entrada y salida respectivamente.
A partir del DFD de Nivel 0 para mostrar más detalle aparecen representados procesos (burbujas) y caminos
de flujo de información adicionales. Cada uno de los procesos representados en el nivel 1 es una subfunción
del sistema general en el modelo del contexto.

Notación básica.
Entidad externa: un productor o consumidor de información
que reside fuera de los límites del sistema.
Función: un transformador de información que reside dentro IDENT
de los límites del sistema. Desc.
es lo que determina la función específica
Flujo de datos: un elemento o una colección de elementos. La
cabeza de la flecha indica la dirección del flujo de Elemento de
datos. datos
Archivo: un depósito de datos puede ser tan sencillo como un Almacén de Datos
buffer, una cola o tan sofisticado como una base de
datos relacional.

38
Flujos permitidos.
Función ↔ Archivo.
Función ↔ Función.
Función ↔ Entidad externa.
Archivo ↔ Entidad externa

Es importante señalar que el diagrama no proporciona ninguna indicación explícita de la secuencia de

procesamiento.
Podemos refinar cada una de las burbujas en distintos niveles para mostrar un mayor detalle.

Ej. :
NIVEL N
A B
F

F2
V X
A
F1 Z B
F4 F5

W F3 Y

Se debe mantener la continuidad del flujo de información, es decir que la entrada y la salida de cada
refinamiento deben ser las mismas.
La notación básica que se usa para desarrollar el DFD no es en si misma suficiente para describir los
requisitos. Para responder a esto se utiliza el diccionario de datos.
En el nivel 0 es el único nivel que se pueden pasar flujos sin nombrarlos.

Diccionario de datos.
Un análisis de dominio de información puede ser incompleto si solo se considera el flujo de datos. Como
cada flecha del DFD puede representar más de un elemento de información, el analista debe disponer de
algún método para representar el contenido de dichas flechas, este es el diccionario de datos.
Define los elementos de información sin ambigüedades, puede dar información sobre la función, la cual no
puede ser inmediatamente obvia a partir de un examen del DFD.
El diccionario de datos se expande hasta que todos los datos compuestos han sido representados como
elementales o son términos que pueden ser bien conocidos.

Estructuras:
• Funcionales: • Flujo de Datos:
o Nombre o Nombre
o Descripción(referencia a lo que hace) o Fuente
o Entrada o Destino
o Salida o Descripción
o Estructura de datos con que hice el flujo
o Volumen de información(estimación de
cuantos hace en el día)
• Archivos: • Estructura:
o Descripción o Nombre
o Nombre o Descripción
o Contenido o Descripción de campos
o Flujo de datos de E/S o Flujos relacionados
o Volumen
• Datos Elementales:
o Nombre Notación:
o Descripción = → compuesto por
o Alfanumérico + → secuencia
o Numérico [ ‘] → selección
[ ]n → n repeticiones
( ) → datos opcionales
* * → comentario

39
Orientados a las Estructuras de Datos.
Representan los requerimientos de software centrándose en las estructuras de datos en vez de en el flujo de
datos. Aunque cada método tiene un enfoque y una notación distinta, todos tienen algunas características
comunes:
1. Todos ayudan al analista en la identificación de los objetos de información clave (también llamadas
entidades o elementos) y de las operaciones (también llamadas acciones o procesos).
2. Todos asumen que la estructura de la información es jerárquica.
3. Todos requieren que se represente la estructura de datos usando las construcciones “secuencia, selección
y repetición”.
4. Todos proporcionan un conjunto de pasos para transformar una estructura jerárquica en una estructura de
programa.

Diagrama de Warnier.
CLP (construcción lógica de programas), presenta elementos para el análisis y el diseño. Comenzando con la
representación formal de las estructuras de datos, el método conduce a la derivación de procedimientos y
culmina con métodos sistemáticos, para la generación de pseudo código, verificación y optimización.
La notación para las estructuras de datos, usada en CLP, es el diagrama de Warnier que describe jerarquías,
repetición explícita e información condicional. Entonces el CLP comienza con la especificación de E/S
usando diagramas de Warnier.
Warnier ha desarrollado una técnica llamada organización detallada, en la que el conjunto de instrucciones
puede desarrollarse a partir de la organización lógica del programa.
Warnier define los siguientes tipos de instrucciones:
− Entrada y preparación de la entrada.
− Bifurcaciones.
− Salida y preparación de la salida.
− Llamadas a subprogramas.
Una organización detallada se desarrolla generando listas de instrucciones mediante tipo. La instrucción se
escribe y correlaciona con los bloques de procesamiento apropiados con una indicación numérica. Para cada
tipo de instrucciones se prepara una lista, después se agrupan y organizan las instrucciones con el mismo
identificador de bloque de procesamiento en una secuencia de entrada – procesamiento – salida. Ej. :
Organización de un periódico.
Sección Principal Diagrama de Warnier
Noticia Cabecera
Noticia Nacional Sección Noticia Cabecera
Noticia Local Principal Noticia Nacional
Sección Editorial Noticia Local
Columna editorial Sección Editoriales(1,3)
Cartas al director Periódico Editorial Cartas(1,1)
Caricatura satírica Caricaturas(0,1) {puede haber 1 o
Sección Secundaria Sección Not. Dep. ninguna}
Noticias Deportivas Secundaria Not. Econ. Perfil empresarial
Noticias Económicas Anuncios Perfil laboral
Anuncios por palabras
Se usa “{“ para diferenciar niveles.
Todos los nombres dentro de la llave indican secuencia
+ representa selección

40
Metodología de Jackson.
Primero identifico:
- Entidades (analizando los sustantivos)
- Acciones (analizando los verbos)

1. Modelar el problema especificando las estructuras de datos de entrada y salida.

SECUENCIA SELECCIÓN ITERACIÓN

0 0 N

2. Identificar puntos de correspondencia entre árboles de entrada y salida y obtener el modelo estructural.
3. Expandir el modelo estructural a un diseño detallado.
− Hacer lista de operaciones.
− Asociar operaciones con la estructura del programa.
− Desarrollar pseudo código.

41
Ejemplo:
1. Archivo de entrada Empezamos representando datos de
dto. Especialidad nombre entrada
01 perforaciones Juan Arch. de Empl.
01 perforaciones José
01 perforaciones NN
01 albañil NN Grupos de reg. por
01 albañil NN dto. y por * iteración
especialidad
01 pintor NN
02 albañil NN
02 soldadura NN Reg. de Empl. *

Dto. Espec. Nombre

Listado de Esp.

Título Línea por dto.

y espec.

Dto. Espec. Cant.

Reporte: Dto. Espec. Cant. Estructura de datos de salida

01 perf. 3
01 albañil 2
01 pintor 1
02 albañil 1
02 soldador 1

2. Identificar puntos de correspondencia

Hay correspondencia en el nivel
Grupos de reg. por Línea por dto.
* *
dto. y por y espec.
especialidad

Entonces el modelo estructural queda:

Procesar listado

1 3 9 10
Procesar titulo Procesar grupo por dto. y esp.
2
4 5 6 8
7 3 Procesar por reg. Imprimir línea

3. Expandir: Listado de operaciones

1 abrir archivos de empleados.
2 imprimir título
3 leer registro
4 cantidad empleados = 0
5 dto. actual = dto.
6 esp. actual = esp.
7 cant. emp = cant. emp. + 1
8 imprimir línea
9 cerrar archivo
10 terminar

42
Diagramas de Entidad – Relación (DER).
Es una notación gráfica para modelar datos. Es un modelo de red que describe con un alto nivel de
abstracción la distribución de datos almacenados en un sistema.
Es una herramienta efectiva de modelado de datos para comunicarse con los usuarios ejecutivos de mayor
nivel de una organización o el grupo de administración de bases de datos. Los componentes de un DER son:
− Entidades: objetos (concretos o conceptuales) de la aplicación.
Las entidades del mismo tipo se agrupan en un conjunto de entidades.
− Relaciones: asociaciones entre una o más
entidades. Las relaciones se definen en función
del grado, cardinalidad y dependencia de existencia.
− Atributos: describen propiedades de las entidades y relaciones. Son identificadores (sirven como clave) o
descriptores.
De acuerdo a su grado las relaciones pueden ser: unarias, binarias, ternarias o n-árias.
La cardinalidad de una relación puede ser:
− N:N de muchos a muchos – 1:N uno a muchos
− 1:1 uno a uno
La cardinalidad puede ser mandataria u opcional.
A las entidades que no tienen clave propia y no tienen existencia propia se las denomina entidades débiles.
Generalización:
En el DER es posible establecer jerarquías de generalización entre las entidades. Una entidad E es una
generalización de un grupo de entidades E1...En si cada objeto de E1...En es también un objeto de E.
En la generalización se utilizan los conceptos de herencia.
Especialización:
En una especialización existen entidades del super-tipo que no están en los subtipos. También existe el
concepto de herencia.

43
Orientados a los Objetos.
Introduce el concepto de objeto, clase, atributo, miembro, herencia. Para un objeto se definen sus atributos, y
de que clase es miembro.
Un objeto hereda todos los atributos y operaciones de la clase.
Las operaciones modifican uno o más atributos del objeto.
El objeto encapsula datos, operaciones y otros objetos. La encapsulación significa que toda esa información
esta empaquetada bajo un solo nombre y puede ser reutilizada como especificación o como componente de
otro programa.
Orientación a los objetos = objetos + clasificación + herencia + comunicación

Se deben:
− Identificar los objetos
− Especificar atributos
− Definir operaciones
− Comunicación entre objetos
Ejemplo:
A B

Op. 1 Op.3
Op. 2 OP. 4
Op.5
mensaje

Op. 6
Op. 7
Op. 8

44
UNIDAD N° 5: ”Diseño del software”.
Fase de desarrollo.
Traduce un conjunto de requerimientos en un software. El primer paso de esta fase se centra en el diseño. Se
desarrolla una estructura modular, se definen las interfaces, y se establecen las estructuras de datos. Los
criterios de diseño se utilizan para conseguir la calidad. Se realiza un primer borrador del “documento de
diseño”.
A continuación se consideran los aspectos procedimentales de cada componente modular del diseño del
software Después que se ha realizado el diseño se comienza a codificar. Se genera un programa usando un
lenguaje de programación apropiado. El código se revisa para mantener un estilo y claridad, pero debe ser
directamente asociable a una descripción de diseño detallada.
L etapa final del desarrollo está asociada a la prueba del software Se realizan tres tipos de pruebas:
∗ Las pruebas de unidad intentan validar el rendimiento funcional de un componente individual del
software.
∗ La prueba de integración es un método de construcción de la arquitectura de software a la vez que prueba
las funciones e interfaces.
∗ La prueba de validación prueba que se hayan cumplido todos los requerimientos.
Diseño.
Es el proceso de aplicar distintas técnicas y principios con el propósito de definir el sistema con los
suficientes detalles para permitir su realización física.
Usando una de las distintas metodologías de diseño se realiza (desde el punto de vista técnico) el diseño de
datos, arquitectónico y el diseño procedimental.
∗ Diseño de datos: transforma el modelo del campo de información creado durante el análisis, en las
estructuras de datos que se van a requerir para implementar el software.
∗ Diseño arquitectónico: define las relaciones entre los principales elementos estructurales del programa.
∗ Diseño procedimental: transforma los elementos estructurales en una descripción procedimental.
Es aquí donde se toman decisiones que afectaran finalmente al éxito de la implementación del programa y
con igual importancia a la facilidad de mantenimiento.
Sin diseño nos arriesgamos a construir un sistema inestable, un sistema que fallará cuando se realicen
pequeños cambios, que puede ser difícil de probar y cuya calidad puede no ser evaluada más tarde.
Desde el punto de vista de gestión de proyecto el diseño de software se realiza en dos pasos:
∗ Diseño preliminar: involucra el diseño de datos y arquitectónico, se refiere a la transformación de los
requerimientos de datos y arquitectura de software (se realiza un documento de diseño preliminar).
∗ Diseño detallado: involucra nuevamente el diseño de datos, pero ahora en detalle, aquí el refinamiento de
la representación arquitectónica conduce a una estructura de datos detallada y a representaciones
algorítmicas del software (diseño procedimental).

45
Fundamentos del diseño. proporcionan la base necesaria para que “funcione correctamente”.
Refinamiento: la arquitectura de un programa se desarrolla en niveles sucesivos de refinamientos de los
detalles procedimentales. Se desarrolla una jerarquía descomponiendo una declaración de una función muy
grande de una forma sucesiva hasta que alcancen las sentencias del lenguaje del programa.
El proceso de refinamiento es análogo al usado en el análisis de requerimientos. La diferencia está en el nivel
de detalle, no en el método.
Arquitectura del software: se refiere a dos características importantes de los programas:
− Estructura jerárquica de los módulos.
− Estructura de los datos.
La arquitectura del software se obtiene mediante un proceso de partición, que relaciona los elementos de una
solución de software como parte de un problema del mundo real definido en análisis de requisitos.
Cada método de diseño da como resultado una estructura distinta.
Modularidad: el software se divide en elementos con nombres y direcciones separados, llamados módulos,
que se integran para satisfacer los requerimientos del problema. Es más fácil resolver un problema complejo
cuando se lo parte en trozos manejables. El esfuerzo para desarrollar un módulo individual decrece conforme
el número de módulos se incrementa, pero aumenta el esfuerzo asociado con las interfaces entre ellos. La
modularidad mejora la calidad del diseño y a su vez facilita la implementación, depuración, pruebas,
documentación y mantenimiento del producto.
Abstracción: cuando se considera una solución modular a cualquier problema pueden formarse muchos
niveles de abstracción. En el nivel superior de abstracción se establece una solución en términos amplios, en
los niveles inferiores se toma orientación más detallada y en el nivel inferior se establece la solución de
forma que pueda implementarse directamente. Hay abstracción de datos (colección de datos que describe un
objeto) y de procedimientos (determina la secuencia de instrucciones que tienen una función limitada y
específica) y de control (al igual que la procedimental y de datos implica un mecanismo de control del
programa sin especificar los detalles internos).
Ocultamiento de información: oculta a otros módulos los detalles de implementación, mostrando solo las
interfaces. El ocultamiento implica que una modularidad efectiva pueda lograrse definiendo un conjunto de
módulos independientes que se comuniquen con los otros mediante la información necesaria para realizar la
función del software. Impide que se propaguen errores improductivos inadvertidamente.
Independencia funcional: Es una derivación directa del concepto de modularidad y de los conceptos de
abstracción y ocultamiento. Se trata de diseñar software de forma que cada módulo se centre en una
subfunción específica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras partes de la
estructura del software.La independencia funcional se mide con dos criterios: cohesión y acoplamiento.
COHESIÓN:
ALTA Funcional: cada módulo ejecuta una
función.
Secuencial: la salida de una tarea es la
entrada de otra en el mismo
módulo. Por eso importa la
SI Relación secuencia, la forma en que las
por tareas están asignadas.
datos Comunicacional: abarca módulos cuyas
tareas realizan actividades
sobre una misma estructura
de datos.
Función de Procedimiento: son módulos cuyas
única ? NO actividades están
Relación Relación relacionadas por el control y
por deben ejecutarse en un orden
control específico.
Temporal: un módulo contiene tareas que
están relacionadas porque se
ejecutan al mismo tiempo.
Lógica: son módulos que tienen tareas
Ni datos lógicamente relacionadas (ej.:
Ni control conjunto de tareas de entrada).
Coincidental: segmentación arbitraria del
código, un módulo que realiza
tareas debidamente
BAJA relacionadas ente si.

46
Lo importante es intentar conseguir una alta cohesión y saber reconocer la baja cohesión, de forma que se
pueda modificar el diseño para obtener mayor independencia funcional.
ACOPLAMIENTO:
El acoplamiento depende de la complejidad de las interfaces entre los módulos, del punto en que se hace una
entrada o referencia aun módulo y de los datos que pasan a través de la interfaz.
En el diseño de software buscamos el más bajo acoplamiento posible.
El acoplamiento es la interdependencia entre los módulos.

BAJO 1) Sin acoplamiento

2) De datos: hay relación entre los módulos por el pasaje de datos.
3) De estructura de datos: ambos módulos conocen la misma estructura.
4) De control: se pasan datos de control, son aquellos datos que significan algún
tipo de evaluación en el módulo receptor.
5) Externo: se refiere a módulos con interface en el mundo exterior (periféricos).
6) Globales o por áreas comunes: distintos módulos acceden al mismo conjunto
de datos.
7) Por contenido: un módulo utiliza información de datos o control contenida
ALTO dentro de otro módulo.

Criterios para obtener calidad en el diseño.

∗ Organización jerárquica: debe exhibir una organización jerárquica que haga uso inteligente del control de
cada uno de los elementos de software.
∗ Diseño modular: debe estar particionado lógicamente en elementos que realicen funciones y
subfunciones específicas.
∗ Debe contener una representación distinta y separable de los datos y procedimientos.
∗ Debe conducir a módulos que exhiban características funcionales independientes.
∗ Debe derivarse del análisis de requisitos.
∗ Debe reducir el acoplamiento y mejorar la cohesión.

Diseño de Datos.
Es la primera y quizás la más importante de las tres actividades de diseño. El impacto de la estructura de
datos sobre la estructura del programa y la complejidad procedimental hace que el diseño de datos tenga una
profunda influencia en la calidad del software.
Los datos bien diseñados conducen a una mejor estructura de programa, modularidad y reducción de la
complejidad procedimental.
PRINCIPIOS:
1) Aplicar metodologías de análisis de datos (Se deben desarrollar y revisar las representaciones de flujos y
contenido de datos.).
2) Identificar todas las estructuras de datos y las operaciones que se han de realizar sobre estas.
3) Usar diccionario de datos (para definir el diseño de los datos y el software).
4) Refinar el diseño (obtener una estructura de datos más detallada a medida que se avanza en el
refinamiento).
5) Ocultar la representación de la estructura de datos.
6) Desarrollar bibliotecas de estructuras de datos y operaciones.
Diseño Arquitectónico.
El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa modular y
representar las relaciones de control entre los módulos. Además el diseño arquitectónico mezcla la estructura
del programa y la estructura de datos y define las interfaces que facilitan el flujo de los datos a lo largo del
programa (se hace la carta de estructura derivada del DFD).
Diseño de la Interfaz.
El Diseño de Interfaz se concentra en tres áreas importantes:
1. El diseño de interfaces entre los módulos de software.
2. El diseño de interfaces entre el software y otros productores y consumidores no humanos de
información.
3. Entre el hombre y la computadora.

47
Diseño Procedimental o Detallado.
El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos,
el diseño procedimental debe especificar los detalles de los procedimientos sin ambigüedades. Es por ello
que no se usa un lenguaje natural sino que debe usarse una forma más restringida para tal especificación.
Programación Estructurada.
Cualquier programa, independientemente del área de aplicación o complejidad técnica, puede diseñarse e
implementarse usando solo las tres construcciones estructuradas: secuencia, condición y repetición.
El uso de las construcciones estructuradas reduce la complejidad, y por lo tanto facilita la legibilidad, prueba
y mantenimiento.
Herramientas para el Diseño Procedimental.
GRÁFICAS:
∗ Diagramas de flujo:
Es la herramienta gráfica más ampliamente usada (se pueden representar construcciones no
estructuradas).
Secuencia Condición Repetición Selección
F V V
F
V V
F
F
V

F
∗ Diagrama de Nassi Schneiderman:
Es un diagrama de cajas, surgió del deseo de desarrollar una representación del diseño procedimental que
no permitiera la violación de las construcciones estructuradas.

TABULARES:
∗ Tablas de decisión:
Dan una herramienta que traslada las acciones y condiciones (descriptas en un texto narrativo del
procesamiento) a una forma tabular.
TEXTUALES:
∗ PDL: (lenguaje de diseño de programas o lenguaje de pseudo código)
A primera vista se parece a Pascal o Ada, la diferencia es que se usa texto narrativo insertado
directamente dentro de la secuencia del lenguaje de diseño de programas.

48
“Metodologías de Diseño”.
Diseño orientado al flujo de datos.
Este diseño permite una cómoda transición de la información (por ejemplo, el DFD contenido en la
especificación de requisitos) a una descripción de diseño de estructura del programa.
Se realiza como parte de un proceso de 5 pasos:
1) Establecer el tipo de flujo de información.
2) Determinar los límites del flujo.
3) Convertir el DFD en la estructura del programa.
4) Definir la estructura de control mediante factorización.
5) Refinar la estructura.
El tipo de flujo s lo que determina el método de conversión requerido en el paso 3. Hay dos tipos de flujos:
de transformación y de transacción.
Flujo de Transformación.
La información entra al sistema mediante caminos que transforman los datos externos a una forma interna y
se identifica como flujo entrante.
En el interior del software se produce una transición. Los datos entrantes pasan a través del centro de
transformación moviéndose a lo largo de caminos que conducen ahora hacia la salida.

Flujo de Entrada Centro de transformación Flujo de salida

ANÁLISIS DE TRANSFORMACIÓN:
Es un conjunto de pasos que permiten a un DFD, con características de flujo de transformación convertirse
en una carta de estructura.
1. Revisar el DFD: nivel 0 del DFD e información complementaria.
2. Refinar el DFD: se examinan los siguientes niveles para obtener más niveles.
3. Determinar tipo de flujo: el diseñador selecciona una característica global del flujo basándose en la
naturaleza prevaleciente del DFD.
4. Identificar el centro de transformación: de esta manera se especifican los límites del flujo de llegada y
salida (que están abiertos a interpretaciones).
5. Realizar el primer nivel de factorización:

Flujo de Entrada Transformación Flujo de salida

M: Este módulo
coordina las acciones
de los de nivel inferior.

Controla la Controla el Controla la

llegada de flujo de salida de
información transformación información

6. Realizar el segundo nivel de factorización: se desarrollan los módulos de nivel inferior.

7. Se refina la estructura usando medidas heurísticas de diseño: con los dos pasos anteriores obtuve a partir
del DFD una carta de estructura, ahora la perfecciono usando criterios para el buen diseño.

49
Flujo de Transacción.
El flujo de transacción se caracteriza por el movimiento de datos a través de un camino de llegada que
convierte la información del mundo exterior en una transacción. Se evalúa la transacción y de acuerdo con su
valor el flujo sigue por uno de los muchos caminos de acción.

El centro del flujo de información

desde el que emanan los caminos
de acción se denomina Centro de
Transacción. La función decide a
que módulo mandar la información.

Hay que tener en cuenta que en el

DFD de un gran sistema, pueden
estar presentes los dos tipos , de
transformación y de transacción.
Por ejemplo, dentro de un flujo de
transacción, el flujo de la
información a través de un camino
de acción puede tener un flujo de
transformación.

ANÁLISIS DE TRANSACCIÓN:
Los pasos en el análisis de transacción son similares y en algunos casos idénticos a los pasos para el análisis
de transformaciones. La principal diferencia se refiere a la conversión de un DFD en carta de estructura.

1. Revisar el DFD.

2. Refinar el DFD.

3. Identificar tipo de flujo.

4. Identificar el centro de
transacción y las
características del flujo de
cada camino de acción.

5. Transformar el DFD en
una estructura de software
adecuada al procesamiento
de transacciones.
(Factorizar Transacción,
primer nivel)

6. Factorizar y refinar la estructura

de transacciones y la estructura
de cada camino de acción
(Factorizar caminos de acción,
segundo nivel).

7. Refinar usando unidades y

heurísticas de diseño.

CARTA DE ESTRUCTURA:
Árbol jerárquico.
Nombre
del Módulo Dato transferido Relación de control Selección Módulo E/S Iteración

50
Diseño Orientado a la Estructura de Datos.
Transforma una representación de la estructura de datos en una representación del software. Se aplica con
éxito a las aplicaciones que tengan una estructura jerárquica bien definida de la información.
1.- La Construcción Lógica de Programas (CLP) desarrollada por Warnier, da un método riguroso para el
diseño de software. Sobre el esquema de la relación entre la estructura de datos y la estructura procedimental,
Warnier desarrolla un conjunto de técnicas que realizan una transformación de la estructura de datos de E/S
en una representación procedimental detallada del software.
2.- El Desarrollo de Sistemas Estructurados de Datos (DSED), también llamado metodología de Warnier –
Orr, es una extensión de CLP y potencia el análisis, así como las capacidades de diseño. Estudia el flujo de
información y características funcionales, así como la jerarquía de datos.
3.- Las Metodologías de Desarrollo de Sistemas “Jackson” (DSJ) parten de que la “paralelización de la
estructura de los datos de entrada y salida (informe) que aseguran un diseño de calidad, desarrollando
técnicas pragmáticas para transformar los datos en estructuras de programa.”.
CARACTERÍSTICAS DE ESTAS ESTRUCTURAS:
Cada método orientado a la estructura de datos tiene su propio conjunto de reglas, sin embargo, deben
realizarse siempre las siguientes tareas de diseño.
1. Evaluar las características de la estructura de datos.
2. Representar los datos en términos de formas elementales tales como secuencia, selección y repetición.
3. Transformar la representación de la estructura de datos en una jerarquía de control para el software.
4. Refinar la estructura de software usando los criterios definidos como parte del método.
5. Desarrollar finalmente una descripción procedimental.

Diseño Orientado al Objeto.

El diseño orientado al objeto (DOO) permite al ingeniero de software indicar los objetos que se derivan de
cada clase y las interacciones entre ellos. Además, el DOO debe proporcionar una notación que refleje las
relaciones entre los objetos.
El primer intento en describir un método de DOO establece que este debe comenzar con una descripción en
lenguaje natural de la estrategia de solución, mediante una realización en software, de un problema real. A
partir de esta descripción el diseñador identifica objetos y operaciones.
Otras contribuciones introdujeron una notación más amplia para asistir a esa actividad y argumentaron que se
trataba realmente de una actividad de análisis.
Los métodos actuales de DOO combinan elementos de las tres categorías de diseño: diseño de datos,
arquitectónico y procedimental.
Los métodos de DOO se caracterizan por los siguientes pasos:
1. Definir el problema.
2. Desarrollar una estrategia informal para la realización en software del campo del problema del mundo
real.
3. Formalizar una estrategia mediante los siguientes subpasos:
a. Identificar objetos y sus atributos.
b. Identificar las operaciones que le puedo aplicar a los objetos.
c. Establecer interfaces para mostrar interacción entre objetos y operaciones.
d. Describir aspectos del diseño detallado que proporcionen una descripción de la implementación de
los objetos.
4. Volver a aplicar los pasos 2, 3 y 4 recursivamente. {los pasos 1,2 y 4 se realizan durante el análisis. Para
el diseño se añaden los siguientes pasos}.
5. Refinar el trabajo realizado en el análisis, buscando subclases, características de los mensajes y otros
detalles de elaboración.
6. Representar la/s estructura/s de datos asociada/s con los atributos del objeto.
7. Representar los detalles procedimentales asociados con cada operación.

51
Diseño de Tiempo Real.
Los sistemas de tiempo real generan alguna acción en respuesta a sucesos externos. Para realizar esta
función, ejecutan una adquisición y control de datos a alta velocidad bajo varias restricciones de tiempo y
fiabilidad. Debido a que estas restricciones son muy rigurosas los sistemas de tiempo real están
frecuentemente dedicados a una aplicación.
CARACTERÍSTICAS DE LOS SISTEMAS DE TIEMPO REAL:
− Responden al mundo real.
− En un tiempo prefijado.
− Debe ser fiable, reiniciable y reparable en fallas.
Análisis y Diseño.
Atributos dinámicos que no pueden separarse de los requisitos funcionales de un sistema de tiempo real.
∗ MANEJO DE INTERRUPCIONES:
− Se salva el estado del programa interrumpido.
− Se determina la naturaleza de la interrupción.
− Se sirve la interrupción.
− Se restaura el estado del programa interrumpido.
− Se vuelve al programa interrumpido.
∗ TIEMPO DE RESPUESTA: Es el tiempo en el que un sistema debe detectar un suceso interno o externo y
responder con una acción.
∗ MANEJO DE E/S: transferencia de datos y tiempo invertido.
Rendimiento dispositivos.
Transferencia Tamaño de buffers.
Bus de datos.
∗ ASIGNACIÓN DE RECURSOS Y MANEJO DE PRIORIDADES.
∗ SINCRONIZACIÓN DE TAREAS Y COMUNICACIÓN ENTRE TAREAS: un sistema multitarea debe suministrar un
mecanismo por el que las tareas se pasan información unas a otras, así como para asegurar su
sincronización.
Se utilizan para esto: semáforos, áreas compartidas, mensajes, técnicas cíclicas.

52
Método Ward.
El método de diseño Ward comienza con la aplicación de los principios fundamentales de análisis de
software aplicado en el contexto de la notación de flujo de datos. Se crean los DFDs, se define el
correspondiente diccionario de datos y se establecen las interfaces entre las principales funciones del sistema.
Análisis y diseño estructurado + conexión con el mundo real + mecanismo para representar comunicación y
sincronización de tareas + representación de la dependencia de estados.
Para hacer la conexión con el mundo real, al DFD agregamos:

DESCRIPCIÓN REPRESENTACIÓN
FLUJO DE CONTROL: Elemento de control o suceso: señales o
interrupciones. Toma un valor lógico o discreto.

PROCESOS DE CONTROL: burbujas que coordinan o sincronizan las

actividades de otras burbujas. Acepta control como entrada y produce
control como salida.

ALMACÉN DE CONTROL: depósitos de elementos de control, que se guardan

para ser utilizados por uno o más procesos

FLUJO DE DATOS CUASI CONTINUOS: Un objeto de datos que entra o sale

de un proceso de una forma “continua”.

PROCESO MÚLTIPLE: Múltiples ocurrencias equivalentes del mismo

proceso.

53
Documentación de Diseño.
En primer lugar se describe el Alcance del Diseño; la mayoría de la información se obtiene de la
Especificación del Sistema y del modelo de análisis (Especificación de los Requisitos de Software).

En segundo lugar se describe el Diseño Arquitectónico del Sistema, que indica como se ha obtenido la
Arquitectura del Programa del Modelo de Análisis. Se utilizan gráficos para la representación de la
Estructura del Programa, como los Diagramas de Flujo de Datos, Cartas de Estructura, que junto con los
conceptos de programación estructurada, permite al diseñador representar los detalles procedimentales,
facilitando su traducción al código.

En tercer lugar se describen detalladamente los Módulos que componen el sistema, indicando de cada uno de
ellos una descripción del proceso, descripción de la interfaz, lenguaje de diseño, módulos que lo componen,
estructuras de datos internas y por ultimo comentarios, restricciones y limitaciones.

Luego se especifica una sección de Diseño de Datos, que describe la estructura de los datos internos y
externos.

Y por último, si es necesario se describe el Diseño de Interfaz, con una “Especificación de la Interfaz
Hombre-Máquina” y las “Normas de Diseño” utilizadas.

Prototipo de Documento de Diseño

1. AMBITO
ƒ Objetivos
ƒ Hardware, Software e Interfaces Humanas
ƒ Funciones de Software
ƒ Bases de Datos Definidas Externamente
ƒ Restricciones y Limitaciones de Diseño
2. DOCUMENTO DE REFERENCIA
ƒ Documento de Software Existente
ƒ Documento del Sistema
ƒ Referencia Técnica
3. DESCRIPCIÓN DEL DISEÑO
ƒ Descripción de Datos (Flujo y Estructura)
ƒ Estructura de Programa Derivado
ƒ Interfaces Dentro de la Estructura
4. MÓDULOS
ƒ Texto Explicativo
ƒ Descripción de la Interfaz
ƒ Descripción en Lenguaje de Diseño
ƒ Módulos Usados
ƒ Organización de los Datos
5. ESTRUCTURA DE ARCHIVOS Y DATOS GLOBALES
ƒ Estructura de Archivos Externos (Estructura Lógica, Descripción Lógica de Registros y Métodos
de Acceso)
ƒ Datos Globales
ƒ Referencias Cruzadas Entre Archivos y Datos
6. PROVISIONES DE PRUEBAS
ƒ Directrices
ƒ Estrategias de Integración
7. EMPAQUETAMIENTO
ƒ Solapamiento del Programa
ƒ Transferencia
8. APENDICE

54
UNIDAD N° 6: ”Aspectos de la Implementación”.
Codificación.
Transforma el diseño en un lenguaje de programación. El proceso de transformación continúa cuando el
compilador acepta el código fuente como entrada y produce como salida un código objeto dependiente de la
máquina que luego es linkeditado para ser traducido a código máquina.
Las características del lenguaje de programación pueden influir en nuestra forma de pensar, tienen un
impacto directo sobre la calidad y la eficiencia de la traducción.

Característica de los lenguajes.

VISIÓN PSICOLÓGICA
Varias características psicológicas aparecen como resultado del diseño de un lenguaje de programación.
Aunque esas características no se pueden medir de forma cuantitativa se reconoce su manifestación en todos
los lenguajes de programación.
Las características psicológicas de un lenguaje tienen una gran importancia asociada a nuestra capacidad de
aprenderlo y de aplicarlo.
• Uniformidad.
Indica el grado en que un lenguaje usa una notación consistente, aplica restricciones aparentemente
arbitrarias o excepciones a reglas sintácticas. Por ejemplo: Fortran usa paréntesis para encerrar índices de
arrays, listas de parámetros en la llamada a un procedimiento y en las expresiones asimétricas para
modificar la precedencia.
A (i) Esta notación multiuso puede llevar a varios
subrutina Pepe (B) errores sutiles.
(2 + A) * D
• Ambigüedad.
Un compilador siempre interpreta una sentencia de una única manera, pero el lector humano puede
interpretar de distintas formas.
A = A / B * C un lector puede interpretarlo X = (A / B) * C
y otro X= A / (B * C).
• Compacto.
Lo compacto que sea un lenguaje es indicativo de la cantidad de información respecto del código que se
debe retener en la memoria humana. Un lenguaje compacto tiene muchos símbolos, abreviaturas,
operadores, etc. Cuantas más cosas de estas tiene más compacto es. Lo óptimo es que tenga pocas cosas y
con ellas se pude hacer mucho. APL, por ejemplo, es un lenguaje extremadamente compacto, se pueden
escribir procedimientos asimétricos y lógicos con relativamente poco código, desgraciadamente esto hace
que el lenguaje sea difícil de leer y comprender.
• Localización.
Relacionada con la memoria de los humanos. La localización se potencia cuando el lenguaje permite
identificar fácilmente sentencias en bloques, cuando las construcciones estructuradas se pueden
implementar directamente, cuando el diseño y el código resultante son altamente modulares y cohesivos.
• Linealidad.
Relacionada con la memoria secuencial que los humanos tenemos (por lo cual podemos reconocer el
siguiente elemento en una secuencia). Los grandes saltos, los grandes bucles violan el procesamiento
secuencial, nuevamente las construcciones estructuradas ayudan a la linealidad.
• Tradición.
Qué exista en los lenguajes es una característica muy importante que el programador debe tener en cuenta
para elegir en que programar. La tradición también afecta al grado de innovación durante el diseño de un
lenguaje.

55
VISIÓN DE LA INGENIERÍA DE SOFTWARE
Se centra en la necesidad que puede tener un proyecto específico de desarrollo de software.
• Facilidad de traducción del diseño detallado al código fuente.
En teoría la generación del código fuente a partir del diseño detallado debería ser algo directo. El grado
de facilidad indica cómo se aproxima un lenguaje a la representación del diseño.
• Eficiencia del compilador.
Aunque los rápidos avances en velocidad de procesamiento y densidad de memoria han comenzado a
disminuir la necesidad de un código super eficiente muchas aplicaciones todavía requieren programas
rápidos y ajustados en memoria.
• Portabilidad del código fuente.
Capacidad de que el código fuente sea transportado de un procesador a otro con ninguna o pocas
modificaciones. También la capacidad de permanecer inalterado cuando cambia su entorno de
funcionamiento.
• Disponibilidad de herramientas de desarrollo.
Que pueden acortar el tiempo requerido para la generación del código fuente y mejorar la calidad del
código. Tratar de tener la mayor cantidad de herramientas para escribir el código.
• Facilidad de mantenimiento.
Es críticamente importante para cualquier esfuerzo no trivial de desarrollo de software. El código debe
estar suficientemente documentado para que se pueda entender, ya que a partir de ahí comienza su
mantenimiento.

Criterios para la elección de un lenguaje.

La elección de un lenguaje para un proyecto específico debe tener en cuenta tanto las características de
ingeniería como las psicológicas. Entre los criterios que se aplican están:
ƒ Área de aplicación.
Es el criterio que más se aplica, a menudo C es un lenguaje elegido para el desarrollo de software de
sistemas, Ada y C para tiempo real, Cobol para desarrollos comerciales. Si queremos trabajar con
objetos, Smalltalk sería una buena elección, Fortran para campos específicos y de ingeniería, etc.
ƒ Complejidad algorítmica.
ƒ Entorno en que se ejecutará.
ƒ Consideraciones de rendimiento.
ƒ Complejidad de las estructuras de datos.
ƒ Staff de desarrollo → conocimiento del lenguaje.
ƒ Disponibilidad de un buen compilador.

56
Características técnicas de los lenguajes.
Los fundamentos de los lenguajes de programación se presentarán dentro del contexto de tres grandes áreas y
se puede juzgar la calidad global evaluando la potencia o debilidad de cada área.

TIPIFICACIÓN DE DATOS
Al hablar de tipos de datos nos referimos a una clase de objetos de datos junto con un conjunto de
operaciones para crearlos y manipularlos. Las operaciones que se pueden realizar sobre un tipo de datos
particular se controlan por la “comprobación de tipos” incluida en el compilador del lenguaje. Se definen 5
niveles de comprobación:
¾ NIVEL 0: Sin tipos.
No incluye medios explícitos para la tipificación de datos y por lo tanto no hacen ninguna comprobación
(Cobol).
¾ NIVEL 1: Conversión automática de tipos.
Es un mecanismo de comprobación de tipos que permite una conversión de operadores de tipos
incompatibles permitiendo una mezcla de tipos, por ejemplo PL/1 asigna 0 a FALSE y 1 a TRUE de esta
manera valores booleanos pueden intervenir en una expresión aritmética.
¾ NIVEL 2: Modo mixto.
Parecido a la conversión automática pero aquí se pueden mezclar tipos de una determinada categoría, por
ejemplo reales y enteros (Fortran).
¾ NIVEL 3: Verificación ligera de tipos.
Tiene todas las características de la fuerte comprobación de tipos pero se implementa de forma que
existan uno o más escapes (Simula).
¾ NIVEL 4: Fuerte comprobación de tipos.
Solo permite llevar a cabo operaciones entre objetos de datos que son del mismo tipo previamente
especificado (Ada).

MECANISMOS DE SUBPROGRAMA
Un subprograma es un componente de un programa compilado por separado que contiene datos y estructuras
de control. Dependiendo del lenguaje un subprograma puede llamarse subrutina, procedimiento, función u
otro nombre especializado. Un subprograma tiene un conjunto de características genéricas:
¾ Una sección de la especificación que incluye su nombre y la descripción de la interfaz.
¾ Una sección de implementación que incluye datos y las estructuras de control.
¾ Un mecanismo de activación que permite activarlo desde el programa principal.

ESTRUCTURAS DE CONTROL
los lenguajes modernos permiten al programador usar las construcciones lógicas de programación
estructurada: secuencia, repetición y condición. Además puede haber otras estructuras de control:
¾ La recursividad: crea una segunda activación del subprograma durante la primera.
¾ La concurrencia: da soporte a la creación de múltiples tareas, a la sincronización de tareas y a la
comunicación de tareas.
¾ El manejo de excepciones: atrapa los errores del sistema o los definidos por el usuario pasando el control
a un manipulador de excepciones.

57
Clases de lenguajes.
∗ PRIMERA GENERACIÓN: el código de máquina y su equivalente más humanamente legible, el lenguaje
ensamblador, representan la primer generación. Estos lenguajes dependientes de la máquina representan
el menor grado de abstracción.
∗ SEGUNDA GENERACIÓN: fue desarrollada afines de los 50 y principios de los 60 y han servido como base
para los lenguajes modernos (tercera generación). Ejemplos de ellos son: Fortran, Cobol, Basic y Algol.
∗ TERCERA GENERACIÓN: también llamados de programación moderna o estructurada, están caracterizados
por sus potentes posibilidades procedimentales y de estructuración de datos, pueden dividirse en dos
categorías:
− De propósito general: PL/1, Pascal, Modula2, C y Ada.
− Lenguajes especializados: Lisp, Prolog (sistemas expertos), APL (para manejo de vectores y
matrices), Forth, Smalltalk.
∗ CUARTA GENERACIÓN: combinan características procedurales y no procedurales, los podemos clasificar
en:
− Lenguajes de petición: asociados al uso de Bases de Datos, permiten al usuario manipular de forma
sofisticada la información contenida en la base de datos previamente creada.
− Generadores de programas: son más sofisticados que los anteriores, permiten al usuario crear
programas en lenguajes de tercera generación usando notablemente menos sentencias, son de muy
alto nivel, hacen un fuerte uso de la abstracción de datos y de procedimientos. La mayoría es para
desarrollos comerciales en Cobol.
− Otros L4G:
ƒ Lenguajes de soporte a la toma de decisiones: permiten que los no programadores lleven a cabo
una gran variedad de análisis (hojas de cálculo).
ƒ Lenguajes de prototipos: asisten en la creación de prototipos.
ƒ Lenguajes de especificación formal: se pueden considerar L4G si producen código ejecutable.

58
Estilo de codificación.
Los elementos de estilo incluyen la documentación interna (nivel de código fuente), los métodos de
declaración de datos, la aproximación a la construcción de sentencias y las técnicas de E/S.

DOCUMENTACIÓN DEL CÓDIGO

La elección de los nombres para los identificadores (variables y etiquetas) es importante, estos deben ser
mnemotécnicos. Un lenguaje que limita los nombres de los identificadores a unos pocos caracteres
implícitamente limita la comprensión.
− COMENTARIOS: la posibilidad de expresar comentarios en lenguaje natural como parte del listado del
código fuente es algo que aparece en todos los lenguajes de propósito general. Hay dos categorías de
comentarios: “de prólogo”(deben aparecer al principio de cada módulo) y “descriptivos”(se incluyen
por el cuerpo del código y se usan para describir las funciones de procesamiento).
− ORGANIZACIÓN VISUAL DEL PROGRAMA: la identación del código fuente realza las construcciones
lógicas y los bloques ayudando a la legibilidad.

DECLARACIÓN DE DATOS
Se pueden establecer varios métodos para hacer más compresibles los datos y más fáciles de manejar. El
orden de las declaraciones de datos se debe estandarizar incluso aunque el lenguaje de programación no
tenga requerimientos específicos. Por ejemplo: conviene declarar múltiples variables en una sola sentencia,
merece la pena ponerlas en orden alfabético, etc.

CONSTRUCCIÓN DE SENTENCIAS
Cada sentencia debe ser simple y directa, muchos lenguajes permiten colocar varias en un mismo renglón, el
ahorro de espacio que esto implica está difícilmente justificado por la pobre legibilidad del resultado. Las
sentencias del código fuente se pueden simplificar a: evitar el uso de complicadas comparaciones
condicionales, eliminar las comparaciones con condiciones negativas, evitar grandes anidamientos y usar
paréntesis para expresiones lógicas o aritmética.

TÉCNICAS DE E/S
El estilo variará de acuerdo al grado de interacción humana.
Ö E/S ORIENTADA A LOTES (poca interacción humana)serán deseables:
ƒ Organización lógica de la entrada.
ƒ Comprobación de errores de E/S significativos.
ƒ Buena recuperación de errores de E/S.
ƒ Formatos de informes de salida relacionados.
Ö E/S INTERACTIVA
ƒ Entrada simple y dirigida.
ƒ Extensa comprobación y recuperación de errores.
ƒ Salida humanizada.
ƒ Consistencia de formato de E/S.
Ö PRINCIPIOS GENERALES PARA LA E/S
ƒ Hacer invisibles a los usuarios los aspectos internos de la computadora.
ƒ Evitar que el usuario pueda hacer terminar anormalmente el programa.
ƒ Advertir al usuario cuando una petición puede traer consecuencias.
ƒ Proporcionar asistencia interactiva.
ƒ Adecuar los requerimientos de entrada a las posibilidades del usuario.
ƒ Adecuar los mensajes de salida a las velocidades de los dispositivos de salida.
ƒ Distinguir entre distintas clases de usuarios.
ƒ Mantener tiempos de respuesta consistentes.
ƒ Minimizar el trabajo extra del usuario en los casos de errores.

59
Eficiencia.
En primer lugar la eficiencia es un requerimiento de rendimiento y por lo tanto se debe establecer durante el
análisis de requerimientos del software. El software debe ser tan eficiente como se requiera y no como sea
humanamente posible. En segundo lugar la eficiencia se incrementa con el buen diseño y en tercer lugar la
eficiencia del código y la simplicidad del código van de la mano. En general no hay que sacrificar la claridad,
la legibilidad o la corrección en aras de una mejora de eficiencia que no sea esencial.

Eficiencia en el código.
La eficiencia del código fuente está ligada a la eficiencia de los algoritmos definidos durante el diseño
detallado. Sin embargo el estilo de codificación puede afectar la velocidad de ejecución y los requerimientos
de memoria. En el paso del diseño detallado al código debemos tener en cuenta este conjunto de directrices:
ƒ Simplificar expresiones aritméticas y lógicas.
ƒ Evaluar los bucles anidados intentando sacar fuera de ellos algunas sentencias.
ƒ Evitar arreglos multidimensionales.
ƒ Evitar el uso de punteros y listas complejas.
ƒ No mezclar tipos de datos.
ƒ Usar cuando sea posible aritmética entera y expresiones booleanas.

Eficiencia en memoria.
Las restricciones de memoria en el mundo de las grandes computadoras son generalmente algo del pasado, la
gestión de memoria virtual proporciona a las aplicaciones de software un espacio de direcciones lógicas
enorme.
Sin embargo, en las PC (microprocesadores) las restricciones de memoria son algo muy real. Si los
requerimientos del sistema demandan minimizar la memoria se deben evaluar los compiladores de lenguajes
de alto nivel y como último recurso usar Assembler.

Eficiencia de E/S.
Debemos distinguir entre dos tipos de E/S:
ƒ DIRIGIDA A LA PERSONA: se considera eficiente cuando la información se puede suministrar o comprender
con el mínimo esfuerzo intelectual.
ƒ DIRIGIDA A OTRO DISPOSITIVO: la eficiencia es interna, muy complicada, fuera de los alcances de la
materia.
Directrices para mejorar la E/S:
ƒ Minimizar el número de peticiones.
ƒ E/S con buffers para reducir el embotellamiento en la comunicación.
ƒ En memoria secundaria se debe seleccionar el método de acceso más simple dentro de lo aceptable y
debe hacerse por bloques.
ƒ Importante: “super eficiencia” en la E/S no vale la pena si no se puede comprender.

60
UNIDAD N° 7: ”Verificación y Validación”.
Verificación: garantía que el sistema es completo.
Validación: es la calidad del producto en su medio.

La verificación se refiere a un conjunto de actividades que aseguran que el software implementa

correctamente una función específica. “¿Estamos construyendo el producto correctamente?”.
La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requerimientos del cliente. “¿Estamos construyendo el producto correcto?”.

La verificación y la validación comprenden un amplio rango de actividades de SQA que incluyen revisiones
técnicas formales, auditorias de configuración y calidad, supervisión del rendimiento, simulación, estudio de
la viabilidad, revisión de la documentación, revisión de la base de datos, análisis de algoritmos, prueba de
desarrollo, prueba de cualificación y prueba de instalación.
Objetivos de las Pruebas
Luego de la codificación, se realiza la prueba. Es un proceso de ejecución de un programa con la intención de
descubrir un error, y tiene éxito si se encuentra un error que no ha sido detectado hasta entonces.
El objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, en la menor
cantidad de tiempo y esfuerzo. Si la prueba se lleva a cabo con éxito (de acuerdo al objetivo anteriormente
establecido), descubrirá errores en el software.

Principios de la Prueba
Los principios básicos que guían las pruebas de software son:
• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Los
defectos más graves desde el punto de vista del cliente son aquellos que impiden al programa cumplir
sus requisitos.
• Las pruebas deberían planificarse mucho antes de que empiecen. La definición detallada de los casos
de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado.
• El “Principio de Pareto” es aplicable a la prueba de software. Este principio implica que el 80% de
todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de sólo el 20% de
todos los módulos del programa. La complicación está en aislar estos módulos sospechosos y
probarlos concienzudamente.
• No son posibles las pruebas exhaustivas, pues es imposible ejecutar todas las combinaciones de
caminos existentes durante la prueba.
• Para ser más efectivas, deberían ser conducidas por un equipo independiente.

Diseño de Casos de Prueba

Se deben diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores, con la
mínima cantidad de esfuerzo y tiempo posible.
Existen varios métodos de diseño de prueba, que proporcionan un mecanismo de ayuda para asegurar la
mayor completitud de las pruebas, y mayor probabilidad de encontrar errores.
Cualquier producto de ingeniería puede ser probado de una de las dos formas:
1) Las pruebas de caja negra se pueden realizar sólo conociendo la función específica para el que fue
diseñado el producto. Se llevan a cabo para demostrar que cada función es completamente operativa.
Estas pruebas se llevan a cabo sobre la interfaz del software. Lo que pretenden demostrar es que la
entrada se acepta de forma adecuada y que se produce la salida correcta. No tiene mucho en cuenta la
estructura lógica del software.
2) La prueba de caja blanca se utiliza cuando se conoce el funcionamiento del producto, se prueba que
todas las piezas encajan, es decir, que las operaciones internas se ajustan a las especificaciones y que
todos los componentes internos se han comprobado en forma adecuada. Se comprueban los caminos
lógicos del software, proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o
bucles.
A primera vista parecería ser que una prueba de caja blanca muy profunda llevaría a tener programas 100%
correctos, sin embargo no es posible ya que la prueba exhaustiva es materialmente imposible por la enorme
cantidad de caminos lógicos posibles. Sin embargo, no debe ser desechada como impracticable.
Se puede elegir y ejecutar una serie de importantes caminos lógicos para los casos de prueba. Se pueden
combinar los atributos de la prueba de caja blanca con los de la prueba de caja negra para llegar a una
aproximación que valide la interfaz y asegure selectivamente que el funcionamiento interno del software es
correcto.

61
Técnicas de Prueba.

Prueba de Caja Blanca.

Mediante este método de prueba se garantiza que:
ƒ Se ejecutan todos los caminos independientes de cada módulo.
ƒ Se ejecutan todas las condiciones lógicas en true y false.
ƒ Se ejecutan todos los bucles en sus límites.
ƒ Se ejecutan todas las estructuras internas de datos para asegurar su validez.
¿Por que se realizan estas pruebas y no nos dedicamos directamente a ver si los requerimientos fueron
alcanzados?(usando pruebas de caja negra). La respuesta está en la naturaleza de los defectos del software:
ƒ Los casos especiales son los más factibles de errores.
ƒ A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse y resulta que se ejecuta
regularmente (el flujo de control intuitivo muchas veces es distinto del real).
ƒ Los errores tipográficos son aleatorios.

Prueba del camino básico.

Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecutan por lo menos
una vez cada sentencia del programa.
Se utilizan diagramas de flujo.
Construcciones estructuradas en forma de diagrama de flujo:
Sentencia If Until While Case

El grafo de flujo representa el flujo de control lógico. Cada nodo representa una o más sentencias
procedimentales. Un solo nodo puede corresponder a una secuencia de cuadros de proceso y a un rombo de
decisión. Una arista debe terminar en un nodo, cuando contabilizamos las regiones se cuenta también la
exterior. Cuando en el diseño procedural se encuentran condiciones compuestas (expresiones booleanas con
los operadores and, or, etc.) el grafo se complica un poco, por ejemplo:

If a or b a
then x
else y b x x
endif
y

Un camino independiente es cualquier camino que introduce por lo menos un nuevo conjunto de sentencias
de procesamiento o una condición. En términos del diagrama un camino independiente se debe mover por lo
menos por una arista que no haya sido recorrida anteriormente. El conjunto de caminos básicos no es único,
para saber el número de caminos independientes que hay que ejecutar para asegurar que todas las sentencias
del programa se ejecuten por lo menos una vez, tenemos que calcular la complejidad ciclomática, que se
calcula de la siguiente forma:
1. Número de regiones.
2. Número de aristas – número de nodos + 2.
3. Número de nodos predicados + 1.

PASOS A SEGUIR
1. Usar el diseño o el código para hacer el grafo de flujo.
2. Determinar la complejidad ciclomática.
3. Determinar un conjunto básico de caminos linealmente independientes.
4. Preparar los casos de prueba que fuercen la ejecución de cada camino.

62
Matrices de grafos.
Para desarrollar una herramienta de software que ayude en la prueba del camino básico puede ser bastante
útil una estructura de datos denominada matriz de grafos.
Es otra herramienta de software para esta prueba. Es una matriz cuadrada cuyas filas y columnas representan
los nodos del grafo y cada entrada de la matriz representa la conexión entre los nodos. Si hay conexión
ponemos en 1, sino un 0.
La suma de las filas nos da el peso de enlace.
Si el peso de enlace es mayor a 1 representa un nodo predicado.
Ejemplo:
1 1 2 3 4 5 1 2 3 4 5 conexiones
1 a 1 1 1
a 2 2 0
3 3 d b 3 1 1 2
e 4 c f 4 1 1 2
5 R2 b 5 g e 5 1 1 2
f 4 R1 d Matriz de grafo Matriz de conexiones

g R3 c nodos predicados = 3
complejidad ciclomática = 4
2
R1, R2, R3 y R4 = regiones

Prueba de Bucles.
Se centra en la validez de la construcción de bucles se pueden definir cuatro clases diferentes de bucles.

Simples Anidados Concatenados No estructurados

Además del análisis del camino básico que mide todos los caminos de un bucle, se recomienda una lista de
pruebas adicionales para cada clase de bucle.
SIMPLE: sea n el número máximo de pasos permitidos por el bucle, se deben hacer estas pruebas:
− Saltar totalmente el bucle.
− Pasar una sola vez por el bucle.
− Pasar dos veces por el bucle.
− Hacer m pasos por el bucle donde m < n.
− Hacer n-1, n y n+1pasos por el bucle.
ANIDADOS:
− Llevar a cabo las pruebas de bucle simples con el bucle más interior manteniendo los exteriores con los
valores mínimos en sus parámetros de iteración.
− Progresar hacia fuera, llevando a cabo las pruebas para el siguiente bucle, pero manteniendo los más
externos en los valores mínimos y los demás bucles anidados (internos) con valores típicos.
CONCATENADOS: cuando los bucles son independientes se pueden probar independientemente como los
simples, pero cuando existe dependencia entre ellos (por ejemplo si se usa un contador del bucle 1 como
valor inicial del bucle 2) se recomienda hacer el tratamiento como los anidados.
NO ESTRUCTURADOS: se deben rediseñar para ajustarlo a los requisitos de la programación estructurada.

63
Pruebas de Caja Negra.
Los métodos de prueba de caja negra se centran en los requerimientos funcionales del software. O sea, la
prueba de caja negra permite al ingeniero de software derivar conjuntos de condiciones de entrada que
ejerciten completamente todos los requerimientos funcionales de un programa.
Intenta encontrar errores de la siguiente categoría:
1) Funciones incorrectas o ausentes.
2) Errores de interfaz.
3) Errores en estructuras de datos o accesos a bases de datos externas.
4) Errores de rendimiento.
5) Errores de inicialización y terminación.

Partición equivalente.
Es un método de caja negra que consiste en particionar el dominio de la entrada de un programa en clases de
datos que puedan derivar clases de prueba.
Un caso de prueba descubre en forma inmediata una clase de error. Se basa en una clase de equivalencia de
una condición de entrada. Una clase de equivalencia representa un conjunto de entradas válidas o inválidas
para condiciones de entrada.
Los casos pueden ser seleccionados de forma que se ejecuten el mayor número de atributos de cada clase a la
vez.

Análisis de valores límites.

Los errores tienden a darse más en los valores límites del campo de entrada que en el centro.
El análisis de valores límites nos lleva a una elección de casos de prueba que ejecuten los valores límites.
Es una técnica que complementa a la partición equivalente. En lugar de seleccionar cualquier elemento de
una clase de equivalencia, este método lleva a la elección de casos de prueba en los bordes de las clases.
En lugar de centrarse solamente en las condiciones de entrada, este método deriva casos de prueba también
para el campo de salida.
Directrices:
1. Entrada rango [a, b] ⇒ casos de prueba a, b y por debajo y por encima de a y b.
2. Valores ⇒ casos de prueba por el valor máximo, mínimo y por debajo y por encima.
3. Aplicar 1 y 2 a la salida.
4. Si la estructura de datos tiene límites preestablecidos (ej.: array 100 entradas) hay que asegurarse una
prueba que analice su límite.

Técnica de grafo causa y efecto.

Son una técnica de diseño de casos de prueba que proporcionan una concisa representación de las
condiciones lógicas y sus correspondientes acciones.
Pasos:
1. Listas para cada módulo de causa (condiciones de entrada) y efecto (acciones) asegurando un
identificador a cada uno de ellos.
2. Se desarrolla el grafo de causa y efecto.
3. Se convierte el grafo a tablas de decisión.
4. Se convierten las reglas de la tabla de decisión a pruebas.

Prueba de validación de datos.

Hay casos en que varios equipos de ingeniería desarrollan separados versiones independientes de una
aplicación. En estas situaciones se debe probar cada versión con los mismos datos de prueba, para asegurar
que todos proporcionan una salida idéntica. Luego, se ejecutan todas las versiones en paralelo y se hace una
comparación en tiempo real de los resultados, para garantizar la consistencia.
Si las salidas de todas las implementaciones son idénticas entonces todas las implementaciones son correctas.
Si hay alguna diferente se investiga para descubrir el error.

64
Estrategias de Prueba.
La prueba es realmente una serie de cuatro pasos que se llevan a cabo secuencialmente.
Inicialmente la prueba se centra en cada módulo individual asegurando que funciona como una unidad, de
ahí el nombre de prueba de unidad (orientada a la caja blanca).
A continuación se debe ensamblar o integrar los módulos para formar el paquete de software completo, la
prueba de integración se dirige a todos los aspectos asociados con el doble problema de verificar y de
construcción del programa.
Finalmente se deben comprobar los criterios de validación (establecidos durante la fase de definición), en la
prueba de validación se usa exclusivamente pruebas de caja negra.
El software una vez validado, se debe combinar con otros elementos del sistema (hardware gente, bases de
datos), la prueba el sistema verifica que cada elemento encaja de forma adecuada.

Cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la
ejecución de pruebas y la recolección y evaluación de los datos resultantes.
Se han propuesto varias estrategias, todas ellas proporcionan al ingeniero de software una plantilla para la
prueba y todas tienen las siguientes características generales:
ƒ Comienza en el módulo y trabaja “hacia fuera”, hacia la integración del sistema completo.
ƒ La lleva acabo el que desarrolla el software y (para grandes proyectos) un grupo de prueba independiente.
ƒ La prueba y la depuración son actividades diferentes, pero la depuración puede entrar en cualquier
estrategia de prueba.

Prueba de Unidad.
La prueba de unidad centra el proceso de verificación del funcionamiento correcto en la menor unidad de
diseño del software, el módulo. Usando la descripción del diseño detallado la prueba de unidad siempre está
orientada a la caja blanca. Se puede realizar en paralelo para múltiples módulos.
El diseño de casos de prueba comienza una vez que se ha desarrollado, revisado y verificado en su sintaxis el
código fuente.
Debido a que el módulo no es un programa independiente se debe desarrollar para cada prueba de unidad un
software que conduzca y/o resguarde.
Conductor Resultados
Casos de
prueba
Módulo a
ser probado

Resguardo 1 Resguardo 2 Resguardo n

…

En la mayoría de los casos un conductor es un programa principal que acepta los datos de los casos de
prueba pasándolos al módulo que debe ser probado e imprime los resultados relevantes. Los resguardos
sirven para reemplazar a los módulos subordinados al que estamos probando (es decir llamado por él).
Los resguardos y conductores son software adicional. Si se mantiene simple el trabajo extra será pequeño.
Desgraciadamente muchos módulos requieren un gran soporte de este software adicional. La prueba de
unidad se simplifica cuando hay un alto grado de cohesión, si un módulo se dirige solo a una función ⇒ se
reduce el número de casos de prueba.

65
Prueba de Integración.
La prueba de integración es una técnica sistemática para construir la estructura del programa mientras que al
mismo tiempo se llevan a cabo pruebas para detectar errores asociados con la interacción. A menudo hay una
tendencia a la integración no incremental, a construir el programa de un paso, todos los módulos se
combinan por anticipado y se prueba todo el programa en conjunto, esto normalmente lleva al caos. La
integración incremental es la antítesis de la anterior. El programa se va construyendo y probando en
pequeños segmentos.
La integración incremental puede ser ascendente, descendente o una mezcla de ambas.

INTEGRACIÓN DESCENDENTE
Es una aproximación incremental a la construcción de la estructura de programas. Se integran los módulos
comenzando con el módulo de control principal y se van incorporando a la estructura los subordinados de
alguna de estas dos formas: primero en profundidad o primero en anchura.

M1

Este esquema muestra una integración

M2 M3 R4 descendiente primero en profundidad.
Ahora le toca incorporar el módulo 7, quien
al integrarse puede necesitar de otros
M5 M6 R7
resguardos.

M8

El proceso de integración lleva a cabo una serie de cinco pasos:

1. Se usa el módulo de control principal como conductor de la prueba, disponiendo resguardos para todos
los directamente subordinados a él.
2. Dependiendo de la aproximación de integración elegida (profundidad o anchura) se van sustituyéndolos
resguardos subordinados uno a uno por los módulos reales.
3. Se llevan a cabo pruebas cada vez que se integra un módulo.
4. Al terminar estas pruebas, se reemplaza otro resguardo con el módulo real.
5. Se hace la prueba de regresión (o sea, todas o algunas de las pruebas anteriores) para asegurarnos de no
haber introducido nuevos errores.
El proceso continúa desde el paso 2 hasta que se ha construido el programa.
La estrategia de integración descendente verifica los puntos de decisión o de control principales más pronto
en el proceso de prueba ( en una estructura de programa bien diseñada la toma de decisiones está en los
niveles superiores).
Si se selecciona la integración primero en profundidad, se puede ir implementando y demostrando las
funciones completas del software, ya que vamos agarrando cada rama (subfunción) y la vamos desarrollando
completamente. La demostración anticipada de las posibilidades funcionales es un generador de confianza
tanto para el encargado del desarrollo como para el cliente.

INTEGRACIÓN ASCENDENTE
Empieza la construcción y la prueba con los módulos atómicos (o sea con los módulos de los niveles más
bajos de la estructura). Dado que los módulos se integran de abajo hacia arriba los módulos subordinados ya
están integrados por lo tanto no se necesitan resguardos.
La integración ascendente se puede implementar siguiendo los pasos:
1. Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica del software.
2. Se describe u conductor para coordinar la entrada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los conductores y se combinan los grupos moviéndose hacia arriba por la estructura del
programa.

66
COMENTARIOS SOBRE LA PRUEBA DE INTEGRACIÓN
La principal desventaja de la aproximación descendente es la necesidad de resguardos y las dificultades de
prueba que pueden estar asociadas con ello. Los problemas asociados con los resguardos pueden quedar
desplazados por la ventaja de poder probar de antemano las principales funciones de control.
La principal desventaja de la aproximación ascendente es que el programa como entidad no existe hasta que
se ha añadido el último módulo. Este inconveniente se soslaya con la mayor facilidad de diseño de casos de
prueba y con la falta de resguardos.
En general el mejor compromiso puede ser una aproximación combinada que use la descendente para los
niveles superiores de la estructura del programa junto con la ascendente para los niveles subordinados.
A medida que progrese la prueba de integración, el encargado de la prueba debe identificar los módulos
críticos. Un módulo crítico es aquel que tiene alguna de estas características:
1. Está dirigido a varios requerimientos.
2. Tiene un mayor nivel de control (alto en la carta de estructura).
3. Es complejo o propenso a errores.
4. Tiene requerimientos de rendimiento muy definidos.
Los módulos críticos deben ser probados lo antes posible además las pruebas de regresión deben enfocarse
sobre estos módulos.

DOCUMENTO DE ESPECIFICACIÓN DE LA PRUEBA DE INTEGRACIÓN

1. Alcance: resume las características que van a ser probadas.
2. Plan: describe la estrategia general para la integración.
a. Fases de prueba.
b. Esquema.
c. Software adicional.
d. Entorno y recursos.
3. Procedimiento: se describe en forma detallada el procedimiento de prueba requerido para llevar a cabo el
plan descrito anteriormente.
a. Descripción fase n:
1) Orden de integración.
2) Propósito y módulos a ser probados.
3) Herramientas o técnicas especiales.
4) Descripción de software adicional.
5) Datos de los casos de prueba.
b. Resultados esperados.
4. Resultados Obtenidos.
5. Referencias.
6. Apéndices.

67
Prueba de Validación.
Tras la culminación de la prueba de integración, el software está completamente ensamblado como un
paquete. La validación se logra cuando el software funcione de acuerdo con las expectativas razonables del
cliente. Las expectativas razonables están definidas en la “Especificación de requerimientos del software”.
CRITERIOS PARA LA PRUEBA DE VALIDACIÓN:
La validación se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con
los requerimientos. Se intenta asegurar que:
− Se satisfacen todos los requerimientos funcionales.
− Se alcanzan todos los requerimientos de rendimiento.
− La documentación es correcta e inteligible.
− Se alcanzan otros requerimientos (portabilidad, compatibilidad, recuperación de errores, facilidad de
mantenimiento).
Como resultado de la prueba de validación puede descubrirse que existe una desviación de las
especificaciones y se crea una lista de deficiencias. Raramente estas desviaciones se pueden corregir antes de
terminar el plan, a menudo es necesario negociar con el cliente un método para resolver la deficiencia.
PRUEBAS ALFA Y BETA:
La mayoría de los desarrolladores de software llevan a cabo un proceso denominado prueba alfa y beta para
descubrir errores que sólo el usuario final puede descubrir (se debe a que nosotros no podemos predecir
cómo el cliente usará realmente el sistema).
La prueba alfa es conducida por el cliente en el lugar de desarrollo. Se usa el software de forma natural, con
el encargado del desarrollo supervisando al usuario y registrando errores y problemas de uso. Las pruebas
alfa se llevan a cabo en un entorno controlado.
La prueba beta se lleva a cabo en uno o más lugares de clientes por los usuarios finales del software. A
diferencia de la prueba alfa, el encargado del desarrollo no está presente. El cliente registra todos los
problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al
equipo de desarrollo.

Prueba del Sistema.

Estas pruebas caen fuera del alcance del proceso de ingeniería de software y no son conducidos únicamente
por el encargado del desarrollo, sin embargo el ingeniero de software debe anticiparse a los problemas de
interacción y:
1. Diseñar caminos de manejos de errores que prueben toda la información procedente de otros elementos
del sistema.
2. Llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado.
3. Registrar los resultados de las pruebas.
4. Participar en la planificación y el diseño de las pruebas del sistema para asegurarse de que el software es
probado adecuadamente.
Hay cuatro tipos de pruebas para hacer. Aunque cada una tiene un propósito distinto, todas trabajan para
verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones
apropiadas.
∗ PRUEBA DE RECUPERCIÓN: Muchos sistemas basados en computadoras deben recuperarse de fallas. En
algunos casos un sistema debe ser tolerante a fallas, es decir no se debe caer por esas fallas. La prueba de
recuperación fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo
apropiadamente.
∗ PRUEBA DE SEGURIDAD: Intenta verificar que los mecanismos de protección incorporados en el sistema lo
protegerán de la penetración impropia. Durante la prueba de seguridad, el encargado de la prueba juega el
papel de un individuo que desea penetrar en el sistema, donde “todo vale”. Con el suficiente tiempo y
recursos una buena prueba termina penetrando. La idea es que el costo de la penetración se mayor que el
valor de los datos obtenidos mediante la penetración.
∗ PRUEBA DE RESISTENCIA: Estas pruebas están diseñadas para enfrentar a los programas con situaciones
anormales (sobre carga del sistema). La prueba consiste en ejecutar el sistema de forma que demande
recursos de manera exagerada. Por ejemplo, incrementando la frecuencia de los datos de entrada,
encontrar casos de prueba que requieran un máximo de memoria, o que produzcan excesivas búsquedas
de datos en disco. Esencialmente el encargado de la prueba intenta tirar abajo el programa.
∗ PRUEBA DE RENDIMIENTO: Está diseñada para probar el rendimiento del software en tiempo de ejecución
dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del
proceso de prueba (incluso a nivel de unidad), sin embargo, hasta que no están completamente integrados
todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema.

68
Depuración.
La depuración aparece como una consecuencia de una prueba efectiva. O sea, cuando un caso de prueba
descubre un error, la depuración es el proceso que resulta en la eliminación del error. Lo difícil es encontrar
la causa de ese error, para lo cual puede ser necesario volver a realizar otras pruebas. Una vez encontrada la
causa se hacen correcciones para eliminar ese error.
El proceso de depuración comienza con la ejecución de un caso de prueba, se evalúan los resultados y sí
aparece una falta de correspondencia entre los esperados y los reales estamos ante la presencia de un síntoma
de error. En el proceso de depuración pueden pasar dos cosas: se encuentra la causa, se corrige y se elimina;
o no se encuentra la causa, en este caso la persona que realiza la depuración debe sospechar las causas,
diseñar un nuevo caso de prueba que ayude a validar sus sospechas y se realizan nuevas pruebas.
Varias características de los errores hacen que la depuración se difícil:
− El síntoma y la causa pueden ser geográficamente remotos entre sí.
− El síntoma puede desaparecer (temporalmente) al corregir otros errores.
− El síntoma puede estar causado por un error humano difícil de descubrir.
− El síntoma puede aparecer de forma intermitente.
CONSIDERACIONES PSICOLÓGICAS:
Desgraciadamente todo parece indicar que la habilidad en la depuración es un rasgo innato del ser humano.
Se han detectado grandes variaciones en la destreza para la depuración de distintos programadores con el
mismo bagaje educativo y experimental.
ENFOQUES DE LA DEPURACIÓN:
En general existen tres enfoques:
∗ FUERZA BRUTA: la más común y menos eficiente, se hacen volcados de memoria y se escriben sentencias
write por todo el programa. Confiamos en que en algún lugar de la gran cantidad de información
generada encontraremos alguna pista que nos lleve a la causa del error.
∗ VUELTA ATRÁS: se puede usar con éxito para pequeños programas. Partiendo del lugar donde se descubre
el síntoma, se recorre hacia atrás (manualmente) el código fuente hasta que se llega a la posición del
error.
∗ ELIMINACIÓN DE LA CAUSA: los datos relacionados con la ocurrencia del error son organizados para las
posibles causas. Se llega a una hipótesis de causas y se usan los datos anteriores para probar o revocar la
hipótesis.

69
UNIDAD N° 8: ”Mantenimiento”.
El software no trivial se debe mantener. El reconocimiento de este hecho es el primer paso hacia la
disminución de peso de una tarea que constituye del 50% al 70% del presupuesto de muchas grandes
empresas de software.
La fase de mantenimiento comienza antes de la distribución del software y continúa a lo largo de su vida útil.
Durante esta etapa se corrigen errores, se hacen adaptaciones y se implementan mejoras.
Después de la fase de desarrollo, se realiza una revisión de la configuración para asegurar que toda la
documentación está disponible y es la adecuada para las tareas de mantenimiento a seguir, se establece una
organización para el mantenimiento y se define un esquema para las modificaciones del sistema y los errores.
Las tareas relacionadas con el mantenimiento del software dependen del tipo de mantenimiento a realizar. En
todos los casos el mantenimiento del software incluye la configuración entera (o sea, todos los documentos
desarrollados en las fases de planificación y desarrollo), y no solo el código.

Tareas de mantenimiento.
ORGANIZACIÓN DEL MANTENIMIENTO:
Raramente existe una organización formal, de modo que el mantenimiento se lleva a cabo como se puede.
Un esquema de organización puede ser este.
Supervisor del
FPM
sistema
Petición de Controlador del
mantenimiento mantenimiento ICS
Equipo de
FPM
mantenimiento

Las peticiones del mantenimiento se dirigen hacia un controlador del mantenimiento que remite cada
petición a un supervisor del sistema para que la evalúe. Una vez evaluado el controlador de mantenimiento
debe determinar las acciones a realizar y las dirige al equipo de mantenimiento. La petición de
mantenimiento debe estar estandarizada.
Normalmente el equipo de desarrollo genera un formulario de petición de mantenimiento (FMP) que ha de
rellenar el usuario que requiere mantenimiento, de la siguiente manera:
− Para peticiones de mantenimiento correctivo (por error) ⇒ el FMP debe incluir una completa descripción
de las circunstancias que llevaron al error incluyendo datos de E/S.
− Para peticiones de mantenimiento perfectivo o ampliativo ⇒ una breve descripción de los cambios
(especificación de requerimientos abreviada).
El FMP es un documento generado exteriormente, internamente la organización de desarrollo genera un
informe de cambios del software (ICS) indicando:
− Esfuerzo requerido para los cambios.
− Naturaleza de las modificaciones.
− Prioridad de la petición.
− Otros datos sobre las modificaciones.

FLUJO DE SUCESOS:
Se tratan de manera distinta los distintos tipos de mantenimientos. Una vez llegada la petición de
mantenimiento se evalúa al tipo. Si es por un error hay que evaluarlo de inmediato y determinar si es crítico
o no, si es crítico hay que actuar de inmediato, sino se caracteriza por prioridad y se coloca en la cola de
prioridades.
Si el pedido es una mejora se evalúa, puesto que esta puede ser rechazada, si no lo es se caracteriza y coloca
en la cola de prioridades.

70
Tipos de Mantenimiento del Software.
Durante la fase de mantenimiento se encuentran cuatro tipos:
∗ MANTENIMIENTO CORRECTIVO: Modifica el software para corregir los defectos. El proceso incluye el
diagnóstico y corrección los errores. (20%).
∗ MANTENIMIENTO ADAPTATIVO: Con el paso del tiempo, es probable que cambie el entorno original
para que se desarrolló el software. El mantenimiento adaptativo produce modificaciones en el software
para acomodarlo a los cambios de su entorno externo. (20%).
∗ MANTENIMIENTO AMPLIATIVO O PERFECTIVO: A medida que se usa el software, se reciben de los
usuarios recomendaciones sobre nuevas posibilidades, sobre modificaciones de funciones ya existentes y
sobre mejoras en general. Para satisfacer estas peticiones se lleva a cabo el mantenimiento perfectivo.
Esta actividad contabiliza la mayor cantidad de esfuerzo gastado en el mantenimiento.(60%).
∗ MANTENIMIENTO PREVENTIVO: Hace cambios en los programas a fin de que se puedan corregir,
adaptar y mejorar más fácilmente.

Para adaptar o perfeccionar debemos determinar nuevos requerimientos, rediseñar, generar código y probar
el software (son las mismas tareas que se aplican en la fase de desarrollo).

Efectos secundarios del mantenimiento.

La modificación del software es peligrosa. Cada vez que se introduce un cambio en un complejo
procedimiento lógico, la posibilidad de error aumenta. La documentación del diseño y una cuidadosa prueba
de regresión ayudan a eliminar los errores, pero aparecerán efectos secundarios.
∗ EFECTOS SECUNDAIOS SOBRE EL CÓDIGO:
Cuando se modifica el código se introducen muchas veces errores de diferentes clases, estos errores
pueden provenir de anular o cambiar subprogramas, eliminar o cambiar un cuantificador, modificación de
apertura o cierre de archivos, modificar operadores lógicos, etc.
∗ EFECTOS SECUNDAIOS SOBRE LOS DATOS:
Durante el mantenimiento, a menudo se hacen cambios sobre determinados elementos de una estructura
de datos o sobre la propia estructura de datos. Cuando se cambian los datos, el diseño de software puede
no cuadrar con los datos y aparecen errores. Por ejemplo redefinir constantes, redefinir el formato de
archivos o registros, aumento o disminución del tamaño de un array, reorganización de parámetros de
subprogramas.
∗ EFECTOS SECUNDAIOS SOBRE LA DOCUMENTACIÓN:
Se dan cuando no se reflejan los cambios del código fuente en la documentación de diseño y en los
manuales del usuario. Si la documentación no refleja fielmente el estado actual del software es peor
incluso que la ausencia de ella. Algunas peticiones de mantenimiento pueden no requerir cambios en el
diseño o en el código, sino indican una falta de claridad en la documentación del usuario, en tales casos el
mantenimiento se centra en la documentación.

Ciclo de mantenimiento.
∗ ANÁLISIS: comprender el alcance y efecto de la modificación y las restricciones.
∗ DISEÑO: rediseñar para incorporar los cambios.
∗ IMPLEMENTACIÓN: recodificación, actualización de la documentación interna del código.
∗ ACTUALIZAR DOCUMENTACIÓN DE APOYO.
∗ DISTRIBUIR E INSTALAR LAS VERSIONES NUEVAS.

71
Ingeniería Inversa o Reingeniería.
INGENIERÍA INVERSA:
La ingeniería inversa para el software es el proceso de analizar un programa en un esfuerzo de crear una
representación del programa de mayor nivel de abstracción que el código fuente. La ingeniería inversa extrae
información del diseño de datos, arquitectónico y procedimental de un programa.
REINGENIERÍA INVERSA: (renovación o reclamación)
Además de recuperar la información de diseño de un software existente, usa esa información para alterar o
reconstruir el sistema existente, para mejorar la calidad general (añade nuevas funciones y/o mejoras de
rendimiento a la función del sistema ya existente).
Estas técnicas solo sirven para una clase limitada de aplicaciones y el coste (esfuerzo y dinero) puede ser
prohibitivo.
ELEMENTOS DE INGENIERÍA INVERSA:
1. El nivel de abstracción de un proceso de ingeniería inversa se refiere al nivel de sofisticación que se
puede extraer del código fuente.
Se busca representar el diseño procedimental (bajo nivel de abstracción), información de la estructura del
programa y de los datos, modelos de los flujos de datos y control y modelos de relaciones en entidades
(alto nivel de abstracción). A mayor nivel de abstracción se permitirá mayor comprensión del programa.
2. La completitud es el nivel de detalle que proporciona en el nivel de abstracción, generalmente decrece
cuando aumenta el nivel de abstracción.
3. Es importante el grado de interactividad del analista con las herramientas automáticas de la ingeniería
inversa, generalmente al aumentar el nivel de abstracción, la interactividad debe aumentar para que no
sufra la completitud.
4. La direccionalidad, si es en un solo sentido, la información extraída del código fuente se la proporciona
al ingeniero. Si es en ambos sentidos, la información alimenta una herramienta de reingeniería para
reestructurar o regenerar un programa antiguo.

Facilidad de Mantenimiento.
La facilidad de mantenimiento se puede definir como la facilidad para comprender, corregir, adaptar y/o
mejorar el software. En cada paso de la ingeniería del software se puede trabajar en miras a la facilidad del
mantenimiento.
∗ En el análisis:
− Señalar principios generales.
− Identificar posibles mejoras.
− Estimar recursos para mantenimiento (interno o externo).
− Especificar controles de calidad.
∗ Diseño arquitectónico:
− Claro.
− Modular.
− Fácil de modificar.
− Notación estándar.
∗ Diseño detallado:
− Notación para algoritmos, estructuras de datos e interfaces estándar.
− Especificar efectos colaterales.
− Especificar manejo de excepciones.
∗ Implementación:
− Estructurar una entrada y una salida.
− Identación.
− Comentarios.
− Codificación simple y clara.
∗ Pruebas:
− Anotaciones sobre las partes del programa que puedan necesitar mantenimiento preventivo.

72
UNIDAD N° 9: “Calidad”
“Calidad de un producto o servicio es el conjunto de características que le confieren la capacidad de
satisfacer las necesidades explícitas e implícitas del cliente” (Definición ISO).

En el desarrollo de software se pueden encontrar dos tipos de calidad:

™ Calidad de Diseño: Se refiere a las características que acompañan a los requisitos, las especificaciones y
al diseño de sistema. El grado de materiales, tolerancias, y especificaciones de rendimiento, todos
contribuyen a la calidad de diseño. Cuando se utilizan materiales de alto grado y se especifican
tolerancias más estrictas y niveles más altos de rendimiento, la calidad de diseño de un producto
aumenta, si el producto se fabrica de acuerdo con las especificaciones, pues usar el mejor material, el
mejor equipo, absolutamente cero defectos, libre de errores, pero que no satisfaga las necesidades del
cliente no se considera de alta calidad.
™ Calidad de Concordancia: Es el grado de cumplimiento de las especificaciones de diseño durante su
realización. Está centrado principalmente en la implementación, si la implementación sigue el diseño y
el sistema resultante cumple los objetivos de requisitos y rendimiento, la calidad de concordancia es alta.

Factores que determinan la calidad del software:

∗ Operación del sistema:
ƒ Corrección
ƒ Fiabilidad
ƒ Eficiencia
ƒ Integridad
ƒ Facilidad de uso
∗ Modificación y revisión:
ƒ Mantenimiento
ƒ Flexibilidad
ƒ Prueba
∗ Adaptación:
ƒ Probabilidad
ƒ Rentabilidad
ƒ Interacción con otro sistema

Calidad Total
La Gestión Total de Calidad es un enfoque sistemático de la eliminación de las causas raíz de defectos en
productos, que se compone de cuatro pasos:
1. El primer paso se refiere a un sistema de mejora continua del proceso (Calidad Total). El objetivo es
desarrollar un proceso que sea visible, repetible y medible (mensurable).
2. El segundo paso, invocado una vez que se ha alcanzado el primer paso, examina lo intangible que afecta
al proceso y trabaja para optimizar su impacto en el proceso. El proceso de software se puede ver
afectado por cambios reorganizativos (por ejemplo, cambios de turno). Puede ser que una estructura
organizativa estable sea importante para mejorar la calidad del software.
3. El tercer paso se centra en el usuario del producto, en esencia, examinando la forma que el usuario aplica
el producto. Esto conduce a la mejora en el producto mismo.
4. El cuarto paso está orientado a buscar la oportunidad en áreas relacionadas, observando la utilización del
producto en el mercado. Se puede ver como un intento de detectar productos nuevos y beneficiosos.

Control de Calidad
El Control de Calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del ciclo de
desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignado, es decir, que
los productos sean de calidad aceptable y cumplan con los criterios de completitud y correctitud establecidos.

Garantía de Calidad
El objetivo de la Garantía de Calidad es proporcionar los datos necesarios sobre la calidad del producto, y
asegurar que la calidad de producto está cumpliendo los objetivos.

73
Garantía de Calidad de Software. (SQA: Software Quality Assurance)
Los ingenieros de software afrontan la calidad y realizan garantía de calidad aplicando métodos técnicos
sólidos y medidas, realizando revisiones técnicas formales, y llevando a cabo pruebas de software bien
planificadas.
El propósito de un grupo SQA es proporcionar la garantía de que los procedimientos, las herramientas y las
técnicas utilizadas durante el desarrollo y la modificación del producto son adecuados para alcanzar el nivel
de confianza deseado en los productos.
El grupo SQA puede ser o no el mismo que el grupo de desarrollo del software, pero es aconsejable que sea
un grupo distinto para asegurar imparcialidad a la actividades de control de calidad.
Las actividades que realiza un grupo independiente SQA son:
Establecimiento de un Plan SQA para un Proyecto: El plan se desarrolla durante la planificación del
proyecto y es revisado por todas las partes interesadas. El plan identifica:
- Evaluaciones a realizar
- auditorias y Revisiones a Realizar
- Estándares que se pueden aplicar al proyecto
- Procedimientos para información y seguimiento de errores.
- Documentos producidos por el grupo SQA
- Realimentación de la información (FEEDBACK) proporcionada al equipo del proyecto de software.
Por cada proceso que realizará el equipo de ingeniería del software, el grupo de SQA revisa la
descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los
estándares impuestos externamente (por ejemplo ISO 9001) y a otras partes del proyecto del software.
Luego el grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y
verifica que se han hecho las correcciones e informa periódicamente de los resultados de su trabajo al
gestor del proyecto.
Debe también asegurar que las desviaciones del trabajo y los productos del software se documenten y se
manejen de acuerdo con un procedimiento establecido.
Finalmente, los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se
resuelven.
Además de estas actividades, el grupo de SQA coordina el control y la gestión de cambios y ayuda a
recopilar y a analizar las métricas del software.

En síntesis, las actividades SQA engloban:

∗ Métodos y herramientas de análisis, diseño, codificación y prueba.
∗ Revisiones técnicas formales que se aplican durante cada paso de la ingeniería del software.
∗ Estrategia de prueba.
∗ Control de la documentación del software y cambios realizados.
∗ Un procedimiento que asegure un ajuste a los estándares.
∗ Mecanismos de medida y de información.

74
El Plan SQA
El Plan SQA describe las actividades de SQA para cada proyecto de software.
En las secciones iniciales se describe el propósito y el alcance del documento e indican que actividades del
proceso del software son abarcadas por la garantía de calidad. Se listan todos los documentos señalados en el
Plan de SQA y se destacan todos los estándares aplicables.
La sección de gestión del plan describe la situación de la SQA dentro de la estructura organizativa; las
tareas y actividades de SQA y su emplazamiento a lo largo del proceso del software; y los papeles y
responsabilidades organizativas relativas a la calidad del producto.
La sección de documentación hace referencia cada uno de los productos de trabajo producidos como parte
del proceso de software. Entre estos se incluyen:
• Documentos del Proyecto (por ejemplo, plan del proyecto)
• Modelos (por ejemplo, DER’s, jerarquías de clases)
• Documentos Técnicos (por ejemplo, especificaciones, planes de prueba)
• Documentos de Usuario (por ejemplo, archivos de ayuda)
La sección de estándares, prácticas y convenciones lista todos los estándares y prácticas que se aplican
durante el proceso de software, por ejemplo estándares de documentos, estándares de comunicación y
directrices de revisión. Además se listan todos los proyectos, procesos, y en algunos casos métricas de
productos, que se obtienen del proceso de ingeniería de software.
La sección de revisiones y auditorias del plan identifica las revisiones y auditorias que se van a llevar a
cabo por el equipo de ingeniería de software, el grupo de SQA y el cliente.
La sección prueba hace referencia al plan y procedimientos de pruebas del software. También define
requisitos de mantenimiento de registros de prueba.
La sección de información sobre problemas y acción correctora define procedimientos para informar,
hacer seguimientos y resolver errores y defectos, e identifica las responsabilidades organizativas para éstas
actividades.
El resto del plan de SQA identifica las herramientas y métodos que soportan actividades y tareas de SQA;
hace referencia a los procedimientos de gestión de configuración de software para controlar el cambio,
define un enfoque de gestión de contratos; establece métodos para reunir, salvaguardar y mantener todos los
registros; se detallan los métodos para identificar, evaluar, supervisar y controlar riesgos.

Revisiones:
PFR: Factibilidad del Producto.
SRR: Requisitos del Software.
PDR: Diseño Preliminar.
CDR: Diseño Crítico.
ATR: Prueba de Aceptación.
PRR: Revisión Final.

Ventajas del SQA:

∗ Software con menos defectos.
∗ Mayor fiabilidad.
∗ Menor costo de mantenimiento.
∗ Costo total del ciclo disminuye.

Problemas del SQA:

∗ Difícil en organizaciones pequeñas.
∗ Representa cambios.
∗ Requiere gastos.

75
Revisiones Técnicas Formales. (RTF)
Las revisiones se aplican en varios momentos del desarrollo del software y sirven para detectar defectos, que
puedan así ser eliminados. Las revisiones del software sirven para “purificar” las actividades de ingeniería
del software que suceden como resultado del análisis, el diseño y la codificación. Una revisión técnica
formal (a veces denominada inspección) es el filtro más efectivo desde el punto de vista de garantía de
calidad y es llevada a cabo por los ingenieros de software.

Los Objetivos de la RTF son:

∗ Descubrir errores en la función, la lógica o la implementación.
∗ Verificar que el software alcanza los requisitos.
∗ Garantizar que el software sigue estándares predefinidos.
∗ Conseguir un software desarrollado de forma uniformemente.
∗ Hacer que los Proyectos sean más manejables.

La RTF incluye recorridos, inspecciones y otras tareas de revisión técnica de software. Cada RTF se lleva a
cabo mediante una reunión entre 3 a 5 personas para la revisión, preparada por adelantado (a lo sumo 2 hs. de
trabajo cada persona), de duración menor de 2 horas.
Cada RTF se centra en una parte específica del software (inspecciones de un módulo o grupo de módulos).
Al final de la revisión los participantes deciden si: aceptan el producto, rechazan el producto o aceptan el
producto provisionalmente.

Inspecciones: “Directrices para las revisiones”

∗ Revisar el producto.
∗ Fijar agenda y mantenerla.
∗ Limitar el debate.
∗ Enunciar el problema.
∗ Tomar notas.
∗ Limitar el número de participantes.
∗ Preparar revisión anticipada.
∗ Listar comprobaciones.
∗ Planificar tiempo.
∗ Entrenar a los revisores.
∗ Repasar revisiones anteriores.

76
Estándares de Calidad
Un sistema de garantía de calidad se puede definir como la estructura organizativa, responsabilidades,
procedimientos, procesos y recursos para implementar gestión de calidad.

CMM
En 1987 Watts Humphrey idea un Modelo de Maduración de las Organizaciones por Niveles (Managing
the Software Process). Es un modelo de calidad basado en el control estadístico de la calidad del proceso
de desarrollo de software, desarrollado por el Software Engineering Institute (SEI) de la Universidad de
Carnegie & Mellon.
Este modelo de calidad se basa en un conjunto de funciones de Ingeniería de Software que deberían estar
presentes conforme las organizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar
el estado actual de madurez del proceso se utiliza un cuestionario de evaluación y un esquema de 5 grados,
que determina la conformidad con el Modelo de Capacidad de Madurez (CMM)

Los cinco niveles definidos se obtienen como consecuencia de evaluar las respuestas del cuestionario de
evaluación basado en el CMM. Los resultados del cuestionario se filtran en un único grado numérico que
proporciona una indicación de la madurez del proceso de una organización.
Los cinco niveles que considera el CMM son:

Nivel 1: Informal
ƒ Proceso caótico.
ƒ No existen formalismos en los procedimientos, ni en la estimación de costos, ni en la planificación.
ƒ La Gerencia no comprende los aspectos clave.
ƒ Desafíos Clave:
o Gerenciamiento de proyectos.
o Planificación de Proyectos.
o Aseguramiento de Calidad del Software.
o Administración de Configuraciones.

77
Nivel 2: Repetible
ƒ Proceso centrado en el individuo.
ƒ El proceso depende de los individuos.
ƒ Dominio del proceso sólo en proyectos similares.
ƒ Ausencia de una estructura ordenada para el mejoramiento.
ƒ Desafíos Clave:
o Capacitación.
o Actividades Técnicas: Revisiones y Testing.
o Focalización en el Proceso: Estándares y Grupos de Proceso.

Nivel 3: Definido
ƒ Proceso con metodologías comunes.
ƒ Las mejoras son administradas por el grupo de proceso.
ƒ Desafíos Clave:
o Procesos de análisis y de mediciones.
o Planes de calidad.

Nivel 4: Gerenciado
ƒ Proceso medido.
ƒ Base de datos del proceso, para análisis.
ƒ Desafíos Clave:
o Cambios de tecnologías.
o Prevención de problemas

Nivel 5: Optimizado
ƒ Fuerte utilización de las mediciones para:
ƒ Identificar elementos débiles del proceso.
ƒ Justificar cambios de tecnología.
ƒ Prevención de defectos.
ƒ Realimentar el proceso de mejoras.
ƒ Desafíos Clave:
o Suavidad en la gestión del proceso.
o Mantenimiento del nivel óptimo.

En cada nivel del modelo se busca desarrollar en la organización las siguientes áreas clave de resultados:
Nivel 1: Inicial
Compromiso con la calidad
Nivel 2: Repetible
Planeación de Proyectos de Software
Seguimiento del Proyecto de Software
Administración de Requerimientos
Administración de la Configuración del Software
Aseguramiento de la Calidad del Software
Administración de Subcontratos de Software
Nivel 3: Definido
Enfocamiento en el Proceso de la Organización
Definición del Proceso de la Organización
Programa de Entrenamiento
Administración del Software Integrado
Ingeniería de Producto de Software
Coordinación Intergrupal
Revisiones entre Pares
Nivel 4: Administrado
Administración Cuantitativa del Proceso
Administración de la Calidad del Software
Nivel 5: Optimizado
Prevención de Defectos
Administración del Cambio Tecnológico
Administración del Cambio del Proceso

78
ISO 9000
Para identificarse con uno de los modelos de sistema de garantía de calidad de ISO 9000, el sistema de
calidad y las operaciones de una compañía son examinados minuciosamente por unos auditores externos para
ajustarlo a los estándares y a la operación efectiva. Después de un registro correcto, la compañía recibe un
certificado avalado por los auditores. Las auditorias de seguimiento cada 6 meses aseguran el ajuste
continuado a los estándares.

El enfoque de ISO en sistemas de garantía de calidad

Los modelos de garantía de calidad ISO 9000 tratan la empresa como una red de procesos interconectados.
Para que un sistema de calidad se ajuste a ISO, estos procesos deben afrontar áreas identificadas en el
estándar y se deben documentar y practicar como se ha descrito. Documentar un proceso ayuda a que una
organización lo entienda, controle y mejore.
ISO 9000 describe en términos generales, los elementos de un sistema de garantía de calidad. Estos
elementos incluyen la estructura organizativa, procedimientos, procesos y recursos necesarios para
implementar la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de
calidad. Sin embargo, ISO 9000 no describe como debería implementar una organización éstos elementos
del sistema de calidad. Por consiguiente, el reto se encuentra en diseñar e implementar un sistema de
garantía de calidad que cumpla los estándares y acople los productos, servicios y cultura de la compañía.

El estándar ISO 9001

ISO 9001 es el estándar de garantía de calidad que se aplica a la ingeniería del software. El estándar contiene
20 requisitos que deben estar presentes en un sistema de garantía de calidad efectiva. Como el estándar ISO
9001 es aplicable a todas las disciplinas de la ingeniería de software, se ha desarrollado un conjunto especial
de directrices ISO (ISO 9000-3) para ayudar a interpretar el estándar para su uso en el proceso de software.
Para que una organización de software se registre como ISO 9001, debe establecer normas y procedimientos
que afronten los requisitos señalados a continuación y que puedan demostrar que se están cumpliendo:
1. Responsabilidad de la gestión
2. Sistemas de calidad
3. Revisión de contratos
4. Control de diseño
5. Control de datos y documentos
6. Compras
7. Control del producto suministrado por el cliente
8. Identificación y posibilidad de seguimiento del producto
9. Control del proceso
10. Inspección y prueba
11. Control de inspección, medición y equipo de pruebas
12. Inspección y estado de prueba
13. Control de producto no aceptado
14. Acción correctora y preventiva
15. Tratamiento, almacenamiento, empaquetamiento, preservación y entrega
16. Control de registros de calidad
17. Auditorias internas de calidad
18. Formación
19. Servicios
20. Técnicas estadísticas

79
Una comparación entre CMM e ISO 9001
El modelo de Capacidad y Madurez para Software (CMM) desarrollado por el Instituto para la Ingeniería de
Software (SEI) y la serie de estándares ISO 9000, desarrollados por la Organización Internacional de
Estándares, comparten su preocupación por la calidad y la administración del proceso.
Ambos son impulsados por preocupaciones similares y están intuitivamente correlacionados. El estándar
específico de la serie ISO 9000 concerniente a las organizaciones de software es ISO 9001.
Algunas preguntas frecuentes sobre la relación entre ISO 9001 y CMM son:
· ¿A qué nivel del CMM puede considerar s e que una organización acata el ISO 9001?
· ¿Puede una organización nivel 2 ó 3 considerar s e conforme a ISO 9001?
· ¿Deben basarse mis esfuerzos de administración de calidad y mejor a de procesos en ISO 9001 o en CMM?
El propósito de este trabajo es comparar el CMM con ISO 9001, identificar sus diferencias y similitudes, y
responder esas preguntas.

Administración de la Responsabilidad
ISO 9001 requiere que la política de calidad sea definida, documentada, entendida, implementada y
mantenida; esas responsabilidades y las autoridades para toda la especificación del personal para lograr y
monitorear la calidad son definidas ; y los recursos internos par a verificación son definidos y entrenados. Un
administrador es designado par a asegurar que el programa de calidad es implementado y mantenido.
En CMM, la administración de responsabilidad para la política de calidad y las actividades de verificación
son dirigidas en principio por el Aseguramiento de Calidad de Software, aunque la Planeación de Proyectos
de Software y el Seguimiento y Vigilancia de Proyectos de Software también incluyen actividades que
identifican responsabilidades.
La administración de responsabilidad, tanto en la alta dirección como a nivel de la administración de
proyectos, está contemplada por la Verificación de la Implementación. Más genéricamente, los asuntos de
liderazgo son tratados por el aspecto de Compromiso con el Cumplimiento, y la estructura organizacional y
asuntos de recursos son tratados en el aspecto de Capacidad para el Cumplimiento.
Es posible argumentar que la política de calidad descrita por la Administración de Calidad de Software en el
nivel 4 es también tratada por esta cláusula, pero en el nivel 4 la política de calidad es cuantitativa. ISO 9001
es algo ambiguo en la medición del sistema de administración de calidad.

Sistema de Calidad
ISO 9001 requiere que se documente el sistema de calidad, incluyendo procedimientos e instrucciones. ISO
9000-3 caracteriza el sistema de calidad como un proceso integrado a través de todo el ciclo de desarrollo.
Las actividades del sistema de calidad son tratadas por CMM, en principio, por el Aseguramiento de Calidad
de Software. Los procedimientos que deben ser usados se distribuyen a lo largo de varias áreas claves de
proceso (KPA).
Los procedimientos específicos y estándares que un proyecto de software deben usar son especificados en el
Plan de Desarrollo de Software descrito por la Planeación de Proyectos de Software. La conformidad con
esos estándares y procedimientos es asegurada por el Aseguramiento de Calidad de Software y por las
prácticas de auditoria dadas por la Verificación de la Implementación. La Ingeniería de Producto de Software
requiere que s e definan las tareas de Ingeniería de Software, se integren y ejecuten consistentemente.
Es posible argumentar correspondencia con la Definición de Procesos Organizacionales, que describe
estándares, procedimientos y descripciones de procesos a nivel Organizacional. Ciertamente contribuye a
lograr esta cláusula, pero los estándares y procedimientos pueden tratar s e a nivel de proyecto.
ISO 9001 discute el sistema de calidad del proveedor, pero no discute la relación entre el soporte
organizacional y la implementación del proyecto como lo hace el CMM.

Revisión de Contratos
ISO 9001 requiere que los contratos se revisen para determinar s i los requerimientos son adecuadamente
definidos, están de acuerdo con la oferta y si pueden ser implementados. La revisión de requerimientos del
cliente se describe por CMM en la Administración de Requerimientos.
La organización de Software (proveedor) asegura que los requerimientos del sistema asignados al Software
son documentados y revisados, y que los requerimientos faltantes o ambiguos son aclarados. Dado que
CMM se restringe a la perspectiva del Software, los requerimientos del cliente como un todo están más allá
del alcance de esta KPA.
La Planeación de Proyectos de Software describe el desarrollo de una propuesta, una declaración de trabajo y
un plan de desarrollo de software.
El CMM también especifica explícitamente la adquisición de software a través de subcontratación de
organizaciones de software, tal y como s e describe en la Administración de Subcontratación de Software.
Los contratos pueden ser con un cliente o un subcontratista, esa distinción no se hace explícitamente en ISO
9001.

80
Control del Diseño
ISO 9001 requiere que los procedimientos de control y verificación del diseño se establezcan. Esto incluye
planeación de actividades de diseño, identificar entradas y salidas, verificar el diseño y controlar cambios al
diseño. ISO 9000-3 elabora esta cláusula basándose en los requerimientos del cliente, planeación del
desarrollo, planeación de calidad, diseño e implementación, pruebas y validación, y administración de la
configuración.
En CMM, las actividades del ciclo de desarrollo de análisis de requerimientos, diseño, codificación y pruebas
se describen por la Ingeniería de Producto de Software. La planeación de estas actividades se describe en la
Planeación de Proyectos de Software. El seguimiento y Vigilancia del Proyecto describe el control de ese
ciclo de desarrollo, y la Administración de la Configuración de Software describe la administración de la
configuración de los productos de software generados por esas actividades.
ISO 9001 requiere de mediciones para el control del diseño. Establece que el proveedor debe llevar a cabo
revisiones para asegurar que los requerimientos se cumplen y que los métodos de diseño se llevan a cabo
correctamente.
ISO 9001 permite flexibilidad en los controles específicos que se usan. En contraste, CMM implica un
mecanismo específico de control de calidad: las "peer reviews", que dan sopor te a los procesos a través del
ciclo de desarrollo, desde el análisis de requerimientos hasta las pruebas.

Control de Documentos
ISO 9001 requiere que los productos adquiridos sean conformes a sus requerimientos específicos. Esto
incluye la estimación de subcontratistas potenciales y verificación de productos adquiridos.
En CMM, esto es abordado por la Administración de Subcontratación de Software.

Identificación y Rastreo del Producto

ISO 9001 requiere que el producto sea identificable y rastreable durante todas las fases de producción,
entrega e instalación.
El CMM cubre esta cláusula primeramente en la Administración de Configuración de Software, pero la
Ingeniería de Productos de Software establece necesidades específicas de consistencia y rastreabilidad entre
los trabajos de producción de software.

Inspección y Pruebas
ISO 9001 requiere que los materiales entrantes sean inspeccionados y verificados antes de usar los y que se
lleven a cabo inspecciones y pruebas dentro del proceso. Inspección final y pruebas son llevadas a cabo
antes de liberar el producto terminado. Se guardan registros de las inspecciones y pruebas.
Los asuntos concernientes a la inspección de materiales de entrada en CMM son tratados por la Ingeniería de
Producto de Software. Las inspecciones dentro del proceso se llevan a cabo mediante las "peer reviews".

Inspección, medición y prueba de equipos

ISO 9001 requiere que el equipo usado para demostrar conformidad debe ser controlado, calibrado y
mantenido. Cuando se usa Hardware o Software de prueba, se checa antes de usar lo, y es revisado a
intervalos prescritos.
ISO 9000-3 aclara esta cláusula con cláusulas sobre validación y pruebas, reglas, prácticas, convenciones,
herramientas y técnicas.
Esta cláusula es genéricamente abordada en CMM bajo las prácticas de prueba en la Ingeniería de Productos
de Software.

Control de Productos no conformes

ISO 9001 requiere el control de productos no conformes par a prevenir su uso o instalación inadvertida. ISO
9000-3 mapea este concepto a cláusulas de diseño e implementación; pruebas y validación; replicación,
entrega e instalación; configuración y administración.
La no conformidad del producto no está específicamente abordada por CMM. La administración de la
configuración de software aborda el estatus de los artículos que contengan defectos conocidos aún no
arreglados.

Acciones Correctivas
ISO 9001 requiere que las causas de no conformidad de los productos se identifiquen. Las causas
potenciales de no conformidad son eliminadas; los procesos cambian como resultado de las acciones
correctivas.
Una lectura literal de esta cláusula implica muchas prácticas de Prevención de Defectos. Está cláusula es
conducida por las quejas de los clientes.

81
Manejo, Almacenamiento, Empaque y Entrega
ISO 9001 requiere que los procedimientos de manejo, almacenamiento, empaque y entrega sean establecidos
y mantenidos. ISO 9000-3 mapea estas cláusulas en aceptación, replicación, entrega e instalación.
Replicación, entrega e instalación no son cubiertos por el CMM. Las pruebas de aceptación se tratan en la
Ingeniería de Productos de Software y el la Administración de Configuración de Software. Entrega e
instalación del producto, de cualquier manera, no están descritos en CMM.

Registros de Calidad
ISO 9001 requiere que se recolecten y mantengan registros de calidad.
Las prácticas que definen los registros de calidad son distribuidas en CMM a través de muchas actividades.
Específicamente pertinentes a esta cláusula son las pruebas y "peer reviews" en la Ingeniería de Producto de
Software.

Auditorias de Calidad Internas

ISO 9001 requiere que las auditorias sean planeadas y ejecutadas. El resultado de las auditorias se comunica
a la administración, y las deficiencias encontradas se corrigen.
El proceso de auditoria es descrito por el Aseguramiento de Calidad de Software. Las auditorias específicas
en CMM se encuentran en las prácticas de auditoria en la Verificación de la Implementación.

Entrenamiento
ISO 9001 requiere que las necesidades de entrenamiento se identifiquen y que el entrenamiento se lleve a
cabo, dado que ciertas tareas requieren de personal calificado. Registros del entrenamiento son mantenidos.
Las necesidades específicas de entrenamiento en CMM son identificadas en las prácticas de orientación y
entrenamiento que se encuentran en la Capacidad para Ejecución. La infraestructura general de
entrenamiento se describe en el Programa de Entrenamiento.

Servicio
ISO 9001 requiere que las actividades de ser vicio se ejecuten tal y como se especificaron. ISO 9000-3
aborda esta cláusula como mantenimiento.
Aunque CMM está pensado para ser aplicado en ambientes tanto de desarrollo como de mantenimiento de
Software, las prácticas en CMM no están directamente relacionadas con loas aspectos únicos que
caracterizan el ambiente de mantenimiento. El mantenimiento está embebido a través de las prácticas del
CMM, y deben ser apropiadamente interpretadas en los contextos de desarrollo o mantenimiento.

Técnicas Estadísticas
ISO 9001 establece que, cuando sea posible, se deben identificar y usar técnicas estadísticas adecuadas para
verificar qué tan aceptable es la capacidad del proceso y las características del producto. ISO 9000-3
simplemente caracteriza esta cláusula como mediciones.
Las prácticas que describen las mediciones en CMM se distribuyen a través de varias KPA. Las mediciones
del producto son típicamente incorporadas a las prácticas de Actividades Ejecutadas, y las mediciones del
proceso son descritas por la Medición y Análisis.
La definición de procesos organizacionales describe que el establecimiento de una base de datos que
contenga datos de productos y del proceso.

82
Contrastando ISO 9001 y CMM
La mayor diferencia entre estos documentos es el énfasis que pone CMM en la mejor a continua del proceso.
ISO 9001 establece los criterios mínimos par a un sistema de calidad aceptable. Debe notar se que CMM se
enfoca estrictamente en Software, mientras que ISO 9001 tiene un alcance mucho mayor: hardware,
software, materiales procesados y servicios.
La mayor similitud es que tanto CMM como ISO 9001, en última instancia, se fundamentan en “Di lo que
haces, has lo que dices”. La premisa fundamental de ISO 9001 es que cada proceso importante debe ser
documentado y cada producto ser probado por medio de una actividad de control de calidad. ISO 9001
requiere que la documentación contenga instrucciones de qué se debe hacer y cómo se debe hacer. CMM
comparte este énfasis en los procesos que son documentados y prácticas que se ejecutan tal y como se
documentaron.
Una comparación preliminar de los conceptos de ISO 9001 y CMM podría sugerir que una organización
certificada en ISO 9001 se encontraría en un nivel de madurez 3 ó 4. En realidad, hay organizaciones de
nivel 1 certificadas. Una razón es la variabilidad de la interpretación. Dado el alto nivel de abstracción en
ISO 9001, es poco claro qué grado de sofisticación es requerido por una auditoria.
El lograr el nivel 2 implica dominar las KPA del nivel 2. Estas KPA de nivel 2 están fuertemente
relacionadas con ISO 9001, por lo tanto, una organización que obtiene y mantiene una certificación
ISO 9001 debería estar cerca del nivel 2.
Aunque hay asuntos específicos que no se tratan adecuadamente en CMM, en general se puede decir que los
requerimientos de ISO 9001 están contemplados por el CMM.
Es cierto que sujetar se a CMM puede ayudar a una organización a preparar se para una auditoria de
ISO 9001. Aunque ambos enfoques pueden usarse para estructurar un programa de mejora de procesos, la
guía más detallada y la mayor profundidad par a las organizaciones de software dada por CMM sugiere que
es la mejor opción.

83
UNIDAD N° 10: ”CASE”.
(Ingeniería de Software Asistida por Computadora).
Evolución histórica del CASE.
El CASE proporciona al ingeniero la capacidad de automatizar las actividades manuales y de mejorar su
enfoque de trabajo.

Objetivos del CASE.

El objetivo más importante del CASE (a largo plazo) es conseguir la generación automática de programas
desde una especificación a nivel de diseño. El CASE es el conjunto de herramientas que compone un
entorno de apoyo de proyectos integrados.

Bloques que componen el CASE.

El CASE puede ser tan simple como una única herramienta que permite desarrollar una actividad específica,
o tan compleja como un “entorno” que integre distintas herramientas, una base de datos, gente, hardware ,
una red, S.O., etc.
Cada bloque constituye la base del siguiente y las herramientas se sitúan en la cima de la pila.
Los buenos entornos de ingeniería de software se construyen sobre una arquitectura de entorno que engloba
los correspondientes sistemas e software y hardware. Además dicha arquitectura debe considerar los
patrones de trabajo humano que se aplican durante el proceso de ingeniería de software.
La arquitectura de entorno, compuesta por la plataforma de hardware y el soporte del S.O. (incluida la red y
la gestión de base de datos) constituye la base del CASE.
Un conjunto de servicios de portabilidad constituyen un puente entre las herramientas CASE y su marco de
integración y la arquitectura de entorno.
El marco de integración es un conjunto de programas especializados que permiten a cada herramienta
CASE comunicarse con las demás, para crear una base de datos de proyectos y mostrar una apariencia
homogénea al usuario final. Los servicios de portabilidad permiten que las herramientas CASE y su marco
de integración pueden migrar a través de diferentes plataformas de hardware y S.O. sin grandes esfuerzos de
adaptación.

Herramientas CASE

Marco de Integración

Servicios de Portabilidad

Sistema Operativo

Plataforma de Hardware

Arquitectura de Entorno

La mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construías empleando
los “bloques de construcción CASE”. Algunas herramientas CASE siguen siendo “soluciones puntuales”
que prestan apoyo a una actividad concreta (como por ejemplo: análisis y modelado), las cuales no se
comunican directamente con otras; no están unidas a una Base de Datos de Proyecto y no forma parte de un
“entorno integrado” ( I-CASE ).

84
Herramientas CASE
Las herramientas CASE se pueden clasificar:
• por su función,
• por su papel como instrumentos para administradores o personal técnicos,
• por su utilización en los distintos pasos del proceso de ingeniería de software,
• por la arquitectura de entorno (hardware y software) que les presta su apoyo, o incluso
• por su origen o su costo.

La clasificación siguiente utiliza como criterio principal la función.

1. -Herramientas de Ingeniería de la Información
Al modelar los requisitos de información estratégica de una organización, las herramientas de la ingeniería
de la información proporcionan un “metamodelo” del cual se derivan sistemas de información específicos.

2. -Modelado de Procesos y Herramientas de Administración

Se utilizan para representar los elementos claves del proceso de modo que sea posible entenderlo mejor.
También se denominan herramientas “de tecnología de proceso”.

3. -Herramientas de Planificación de Proyecto

Las herramientas de ésta categoría se concentran en dos áreas primordiales: estimación de esfuerzo de
proceso y de coste de software, y planificación de proyecto.
Las herramientas de estimación calculan el esfuerzo estimado, la duración del proyecto y el número
recomendado de personas empleando una o más técnicas de descomposición.
Las herramientas de planificación de proyectos capacitan al administrador para definir todas las tareas del
proyecto, para crear una red de tareas, para representar las interdependencias entre tareas y para modelar la
cantidad de paralelismo que sea posible para ese proyecto.

4. -Herramientas de Análisis de Riesgo

Capacitan al administrador del proyecto para construir una tabla de riesgos, proporcionando una guía
detalladas en la identificación y análisis de riesgos.

5. -Herramientas de Administración de Proyectos

Se utilizan para realizar un seguimiento y monitorización de forma continua de la planificación del proyecto
y el plan del proyecto.

6. -Herramientas de Seguimientos de Requisitos

El objetivo es proporcionar un enfoque sistemático para el aislamiento de requisitos en el desarrollo de
grandes sistemas.

7. -Herramientas de Métricas y Gestión

Las herramientas orientadas a la administración capturan métricas específicas del proyecto (por ejemplo,
LDC/persona/mes, defectos por puntos de función) que proporcionan una indicación global de productividad
o de calidad.

8. -Herramientas de Documentación
Son herramientas de producción de documentos y de autoedición.

9.Herramientas de Software de Sistema

CASE es una tecnología de estaciones de trabajo. Por tanto, el entorno CASE debe adaptarse a un software
de sistema en red de alta calidad, al correo electrónico, a los boletines electrónicos y a otras capacidades de
comunicación.

10.Herramientas de Control de Calidad

Son herramientas métricas que hacen una auditoria del código fuente para determinar si se ajusta o no a
ciertos estándares del lenguaje.

11.Herramientas de Gestión de Base de Datos

Mantienen la base de datos del proyecto.

12.-Herramientas de Gestión de Configuración de Software

85
La Gestión de Configuración de Software (GCS) se encuentra en el núcleo de todos los entornos CASE. Las
herramientas pueden ofrecer su asistencia en las 5 tareas principales de GCS: identificación, control de
versiones, control de cambios, auditoria y contabilidad de estados.

13.-Herramientas de Análisis y Diseño

Capacitan al ingeniero de software para crear modelos del sistema. Los modelos contienen una
representación de los datos, de la función y del comportamiento (en el nivel de análisis), así como
caracterizaciones del diseño de datos, arquitectura, procedimientos e interfaz.

14.-Herramientas PRO/SIM
Son herramientas de prototipos y simulación, proporcionan la capacidad de predecir el comportamiento de un
sistema en tiempo real antes de llegar a contruirlo.

15.-Herramientas de Desarrollo y Diseño de Interfaz

Son herramientas de generación de prototipos de interfaz que permiten una rápida creación en pantalla de
sofisticadas interfaces de usuarios.

16.-Herramientas de Generación de Prototipos

Permiten la creación de un diseño de datos, acoplado con las disposiciones de la pantalla y de los informes
simultáneamente.

17.-Herramientas de Programación
La categoría de herramientas de programación abarca los compiladores, editores y depuradores que están
disponibles para prestar su apoyo en la mayoría de los lenguajes de programación convencionales. Además,
los entornos de programación orientados a objetos, los lenguajes de cuarta generación, los entornos de
programación gráfica, los generadores de aplicaciones y los lenguajes de consulta de base de datos residen
también en esta categoría.

18.-Herramientas de Integración y Comprobación de Software

Existen las siguientes categorías de herramientas de integración y comprobación:
ƒ Adquisición de datos: herramientas que adquieren datos que se utilizarán durante la comprobación.
ƒ Medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba.
ƒ Medida dinámica: herramientas que analizan el código fuente durante la ejecución.
ƒ Simulación: herramientas que simulas las funciones del hardware o de otros elementos externos.
ƒ Administración de comprobaciones: herramientas que prestan su asistencia en la planificación,
desarrollo y control de las comprobaciones.
ƒ Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los límites de las
categorías anteriores.

19.-Herramientas de Análisis Estático

Prestan su asistencia al ingeniero de software a efectos de derivar casos de prueba.

20.-Herramientas de Depuración
Interactúan con un programa que se está ejecutando (Debug).

21.-Herramientas de Comprobación Cliente Servidor

Realizan comprobaciones especializadas en las comunicaciones en red para el cliente y el servidor.

22.-Herramientas de Reingeniería
Las herramientas de estas categorías se pueden subdividir en las funciones siguientes:
ƒ Herramientas de ingeniería inversa para producir especificaciones.
ƒ Herramientas de reestructuración y análisis de código.
ƒ Herramientas de reingeniería para sistemas en línea.

86
Integración de las Herramientas
Los beneficios del CASE integrado (I-CASE) incluyen:
1. Una transferencia suave de información (modelos, programas, documentos, datos) entre una
herramienta y otra, y entre un paso de ingeniería y el siguiente.
2. Una reducción del esfuerzo necesario para efectuar actividades globales, tales como la administración
de configuración de software, el control de calidad y la producción de documentos.
3. Un aumento del control del proyecto que se logra mediante una mejor planificación, monitorización y
comunicación.
4. Una mejor coordinación entre los miembros del personal que estén trabajando en grandes proyectos
de software.

Los requisitos del I-CASE son:

Ö Proporcionar un mecanismo para compartir la información de ingeniería del software entre todas las
herramientas que estén contenidas en el entorno.
Ö Hacer posible que un cambio de un elemento de información se siga hasta los demás elementos de
información relacionados.
Ö Proporcionar un control de versiones y una gestión de configuración general para toda la información
de la ingeniería de software.
Ö Permitir un acceso directo y no secuencia a cualquiera de las herramientas contenidas en el entorno.
Ö Establecer un apoyo automatizado para un contexto de procedimientos para el trabajo de la ingeniería
del software que integra las herramientas y los datos en una estructura de desglose de trabajo
estandarizada.
Ö Recoger métricas tanto de gestión como técnicas que se puedan utilizar para mejorar el proceso y el
producto.

El depósito de un Entorno CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la

integración entre datos y herramientas y entre datos y datos. Proporciona las funciones y herramientas de un
sistema de Gestión de Base de Datos y servicios que son específicos de un entorno CASE.
Muchos requisitos del depósito son iguales a los de las aplicaciones típicas que se construyen tomando como
base un Sistema de Gestión de Base de Datos (SGBD). Muchos de los depósitos CASE actuales hacen uso de
un SGBD (normalmente relacional u Orientado a Objetos) como tecnología de gestión de datos básica. Las
características de un SGBD estándar en un depósito CASE incluyen lo siguiente:
ƒ Almacenamiento de datos no redundante
ƒ Acceso de alto nivel
ƒ Independencia de datos
ƒ Control de transacciones
ƒ Seguridad
ƒ Apertura (mecanismo de importación/exportación sencillo)
ƒ Apoyo multiusuario
El entorno CASE también efectúa demandas especiales con respecto al depósito que van más allá de lo
disponible en un SGBD comercial:
ƒ Almacenamiento de estructuras de datos sofisticadas
ƒ Integridad
ƒ Interfaz de herramientas ricas en términos semánticos
ƒ Gestión de procesos/proyectos
También debe incluir:
ƒ Manejo de versiones de software
ƒ Seguimiento de dependencias y gestión de cambios
ƒ Gestión de requisitos
ƒ Gestión de configuración
ƒ Seguimiento de una auditoria

87
UNIDAD N° 11: ”Gestión de Configuración”.

La Gestión de Configuración de Software (GCS) es un conjunto de actividades desarrolladas para gestionar

los cambios a lo largo del ciclo de vida del software de computadora. La GCS es una actividad de garantía
de calidad del software que se aplica en todas las fases del proceso de ingeniería del software. La meta es
maximizar la productividad minimizando los errores.

Las actividades de GCS sirven para:

1. Identificar el cambio.
2. Controlar el cambio.
3. Garantizar que el cambio se implemente adecuadamente.
4. Informar del cambio a todos aquellos a los que les interese.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración de

software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen
después de que el software se ha entregado al cliente y esté en funcionamiento. La gestión de configuración
del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el
proyecto de desarrollo del software y termina sólo una vez que queda fuera de circulación.

Uno de los objetivos principales de la ingeniería del software es mejorar la facilidad con la que se pueden
implantar los cambios y reducir la cantidad de esfuerzo necesario para implementarlos.

Los elementos de configuración de software (ECS) componen toda la “información producida” como parte
del proceso de ingeniería de software, que colectivamente se denominan configuración del software.

Los ECS se pueden clasificar en tres amplias categorías:

1. Programas de computadoras, tanto en forma de código fuente como ejecutable.
2. Documentos que describen los programas de computadora, tanto técnicos como de usuario.
3. Datos, contenidos en el programa o externos a él.

El cambio de cualquier ECS se puede producir en cualquier momento del ciclo de vida del sistema y por
cualquier razón. Hay cuatro fuentes fundamentales de cambios:
• Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o
en las normas comerciales.
• Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas
de información, funcionalidades entregadas por productos o servicios entregados por un sistema
basado en computadora.
• Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del
proyecto o en las estructuras del equipo de ingeniería de software.
• Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o
producto.

88
Líneas Base

Una línea base es un concepto de gestión de configuración del software que ayuda a controlar los cambios.

Una línea base se define como una especificación o producto que se ha revisado formalmente y sobre los que
se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede
cambiarse solamente a través de procedimientos formales de control de cambios.

Antes de que un ECS se convierta en una línea base, los cambios sobre ese ECS se pueden llevar a cabo
rápida e informalmente. Una vez que se establece una línea base, se pueden llevar a cabo los cambios, pero
se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.

En el contexto de la ingeniería de software, definimos una línea base como un punto de referencia en el
desarrollo del software que queda marcado por el envío de uno o más elementos de configuración de
software y la aprobación del ECS obtenido mediante una revisión técnica formal.
Aunque se pueden definir las líneas base con cualquier nivel de detalle, las líneas base más comunes en la
ingeniería de software son:

Los ECS producidos por la ingeniería del software se revisan y una vez aprobados se colocan en una base de
datos de proyecto, y se convierten en una línea base del proyecto. Cuando del equipo de ingeniería de
software quiere hacer modificaciones en un ECS de línea base puede hacerlo sólo si se siguen los controles
de GCS.

El Proceso de GCS
La responsabilidad principal del GCS es el control de cambios. Sin embargo, también es responsable de la
identificación de los ECS individuales y de las distintas versiones del software, de las auditorias de la
configuración del software y de la generación de informes sobre todos los cambios realizados en la
configuración.

89
Identificación de Objetos en la Configuración de Software
Para controlar y gestionar los elementos de configuración, se debe identificar cada uno de forma única t
luego organizarlos mediante un enfoque orientado a objetos. Los objetos evolucionan a lo largo del proceso
de ingeniería del software. El grafo de evolución describe la historia de los cambios de un objeto. Por
ejemplo, el objeto de configuración 1.0 pasa la revisión y se convierte en el objeto 1.1

Control de Versiones
El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de
configuración creadas durante el proceso de ingeniería de software.
La gestión de configuración permite a un usuario especificar configuraciones alternativas del sistema de
software mediante la selección de las versiones adecuadas. Esto se puede gestionar asociando atributos a
cada versión del software y permitiendo luego especificar (y construir) una configuración describiendo el
conjunto de atributos deseado.
Los “atributos” que se mencionan pueden ser tan sencillos como un número específico de versión asociado a
cada objeto o tan complejo como una cadena de variables lógicas (indicadores) que especifiquen tipos de
cambios funcionales aplicados al sistema.
Una representación de las diferentes versiones de un sistema es el grafo de evolución. Cada nodo del grafo
es un nodo agregado, es decir, una versión completa del software. Cada versión del software es una
colección de ECS y cada versión puede estar compuesta de diferentes variantes.

Control de Cambios
El control de cambios combina los procedimientos humanos y las herramientas automáticas para
proporcionar un mecanismo para el control del cambio.
Se hace una petición de cambio y se evalúa para calcular el esfuerzo técnico, los posibles efectos
secundarios, el impacto global sobre otras funciones del sistema y los costes estimados. Los resultados de la
evaluación se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Un ACC
es una persona o grupo que toma la decisión final del estado y la prioridad del cambio. Para cada cambio
aprobado se genera una orden de cambio de ingeniería (OCI). La OCI describe el cambio a realizar, las
restricciones que se deben respetar y los criterios de revisión y auditoria. El objeto a cambiar es “dado de
baja” de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA.
Luego, el objeto es “dado de alta” en la base de datos y se usan los mecanismos de control de versión
apropiados para crear la siguiente versión del software.
Los procesos de “alta” y “baja” implementan dos elementos importantes del control de cambio:
Ö Control de Acceso: Gobierna el derecho de los ingenieros del software a acceder y modificar objetos
de configuración concretos.
Ö Control de Sincronización: Asegura que los cambios en paralelo, realizados por personas diferentes
no se sobrescriben mutuamente.

Estándares de GCS
Toda organización debe implementar un GCS, como el de línea base, o implementar uno propio para la
empresa, que debe ser un estándar para todos los proyectos dentro de la organización.

90