Sie sind auf Seite 1von 33

Universidad Jurez Autnoma de Tabasco

Divisin Acadmica de Informtica y Sistemas

Licenciado en Sistemas Computacionales

Asignatura:
Fundamentos de Ingeniera de Software

TRABAJO DE INVESTIGACIN

Profesor:
Dr. Rubn Jernimo Yedra

Alumna:
Estefany Len Ramos
CONTENIDO
1. INGENIERA DE SOFTWARE .............................................................................................. 2
a) MTODOS CONVENCIONALES ..................................................................................... 2
b) MTODOS FORMALES ..................................................................................................... 8
c) REUTLIZACIN DE SOFTWARE ................................................................................. 11
g) INGENIERA DE SOFTWARE ASISTIDA POR COMPUTADORA ......................... 14
2. PROCESOS DEL SOFTWARE Y MTRICAS .................................................................. 22
PARADIGMAS DE LA INGENIERA DE SOFTWARE .............................................. 22
MODELO LINEAL SECUENCIAL ................................................................................. 25
MODELO DE MTODOS FORMALES ......................................................................... 28
DESARROLLO BASADO EN COMPONENTES .......................................................... 29
REFERENCIAS .............................................................................................................................. 32

1
1. INGENIERA DE SOFTWARE

a) MTODOS CONVENCIONALES

- METODOS DE PRUEBA DEL SOFTWARE


Mtodo de prueba del software
La prueba del software es un elemento crucial para garantizar la calidad de un software y
permite validar las especificaciones, el diseo y de la programacin.
Las pruebas de software se fundamentan en cuatro elementos:
Las directrices a seguir
Los principios a ser considerados
Su facilidad; y,
Las clases de pruebas
DIRECTRICES DE LA PRUEBA
Proceso de ejecucin de un programa con la intencin de descubrir un error;
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces; y,
Una prueba tiene xito si descubre un error no detectado hasta entonces. Sin embargo
de esto, la prueba no puede asegurar la ausencia de defectos, solo puede demostrar que
existen defectos de software.
PRINCIPIOS DE LA PRUEBA
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos
del cliente;
Las pruebas deberan planificarse mucho antes de que empiecen (la planificacin
puede comenzar al final de la fase de anlisis y la definicin de casos de prueba al
final de la fase de diseo);
El principio de Pareto es aplicable a la prueba de software (80% de los errores
descubiertos durante las pruebas surgen al hacer un seguimiento de solo el 20% de
todos los mdulos del programa);
Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande;
No son posibles las pruebas exhaustivas; y,
Para ser ms efectivas, las pruebas deberan ser conducidas por un equipo
independiente.
FACILIDAD DE LA PRUEBA
Un software debe ser diseado con facilidad para hacer pruebas en mente, es decir, que
permita ser probado ms fcilmente, para esto, Roger Pressman recomienda considerar
los siguientes parmetros determinados por James Bach:

2
Operatividad: Cuanto mejor funcione el software, ms eficientemente se puede
probar;
Observabilidad: Lo que se ve es lo que se prueba;
Controlabilidad: Cuanto mejor se pueda controlar el software, ms se puede
automatizar y optimizar;
Capacidad de descomposicin: Si se controla el alcance de las pruebas, se puede
aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin;
Simplicidad: Cuanto menos haya que probar, ms rpidamente podremos probarlo;
Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas; y,
Facilidad de la comprensin: Cuanta ms informacin tengamos, ms inteligentes
sern las pruebas.
Adems, segn Kaner, Falk y Nguyen una buena prueba debe tener los siguientes atributos:
Alta probabilidad de encontrar un error;
Falta de redundancia;
Ser la mejor de todas las propuestas; y,
No debera ser ni demasiado sencilla ni demasiado compleja.

CLASES DE PRUEBAS
El diseo de caso de pruebas se basa en los tipos de prueba existentes, que bsicamente
son dos:
Pruebas de caja blanca; y,
Pruebas de caja negra

Pruebas de caja blanca


Las pruebas de caja blanca constituyen un minucioso examen de los detalles
procedimentales, usando la estructura de control del diseo procedimental para crear casos
de pruebas con lo cual:
Se garantiza que se recorra por lo menos una vez los caminos independientes de
cada mdulo;
Se ejecuten todas las decisiones lgicas en sus opciones verdadera y falsa;
Se ejerciten todos los bucles en sus lmites y con sus bucles operacionales; y,
Se usen las estructuras internas de datos para asegurar su validez.
Todo esto debido a que:
Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales
a la probabilidad de que se ejecute un camino del programa;
Cualquier camino lgico puede ejecutarse de forma normal independientemente de
nuestras suposiciones; y,
Los errores tipogrficos son aleatorios y no siempre pueden ser descubiertos por
los compiladores y ambientes integrados de desarrollo.
Por otro lado, existen bsicamente dos tipos de pruebas de caja blanca:
Camino bsico; y,
Estructura de control.

3
Pruebas de caja negra
Las pruebas de caja negra permiten obtener conjuntos de entrada que ejerciten los
requisitos funcionales del software, complementndose con las pruebas de caja blanca,
obteniendo errores en las siguientes categoras:
Funciones incorrectas o inexistentes;
Errores de interfaz;
Errores en la estructura de datos;
Rendimiento; e
Inicializacin y terminacin.
Por lo tanto, este tipo de pruebas se disean para:
Determinar cmo se prueba la validez funcional;
Establecer qu clase de entradas proporcionarn unos buenos casos de prueba;
Fijar si el sistema es particularmente sensible a ciertos valores de entrada;
Determinar la forma en que se aslan los lmites de una clase de datos;
Establecer el volumen y nivel de datos soportar el sistema; y,
Fijar los efectos que tendrn combinaciones especficas de datos sobre el sistema
Existen bsicamente cuatro tipos de pruebas de caja negra:
Basadas en grafos;
Particin equivalente;
Anlisis de valores lmites; y,
Pruebas de comparacin.

Prueba de entornos especializados


Dada la complejidad de los sistemas actuales, se deben realizar pruebas especficas en las
siguientes reas:
Interfaces grficas de usuario;
Arquitectura cliente / servidor;
Documentacin y ayuda; y,
Sistemas de tiempo real

Estrategia de prueba del software


La prueba de software es un conjunto de actividades que pueden ser planificadas por
adelantado, mediante algn tipo de esquema. En general, segn Pressman, en la seccin
17.1, de su libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, la mayora de
esquemas propuestos tienen las siguientes caractersticas:
Las pruebas comienza a nivel de mdulos y trabajan hacia fuera hasta integrar todo
el sistema;
Segn el momento y caractersticas son apropiadas diferentes tcnicas de prueba;
La prueba la lleva a cabo el responsable del desarrollo y un grupo independiente de
pruebas; y,

4
La prueba y la depuracin son actividades diferentes, pero la depuracin debe ser
parte de la estrategia de prueba.
En general, se puede hablar de la aplicacin de los siguientes conceptos:
Verificacin: Conjunto de actividades que aseguran que el software implementa
correctamente una funcin especfica; y,
Validacin: Conjunto de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente.
Es importante indicar que la prueba constituye el ltimo bastin desde el que se puede
evaluar la calidad de una aplicacin y por ende descubrir los posibles errores pero si la
calidad no est ah antes de comenzar la prueba, no estar cuando est termine. La calidad
se incorpora al software durante todo el proceso de ingeniera del software, que incluye la
aplicacin adecuada de los mtodos y herramientas, revisiones tcnicas formales efectivas
y una slida gestin y medicin, que permiten que la prueba la confirme.

- IMPLANTACIN (CONVERSIN)
Por lo general al hablar de modelos de desarrollo de software se considera cuatro grandes
fases: Anlisis, diseo, codificacin y prueba. Sin embargo, desde un punto de vista
sistmico, se debe considerar 2 fases adicionales: la implantacin (conversin) y la
produccin y mantenimiento, como se ve en la figura 4.1
FIGURA 4.1: PROCESO DE DESARROLLO DE SISTEMAS

La implantacin (conversin) es el proceso de cambiar desde un sistema antiguo hacia un


nuevo sistema, que no es otra cosa que alimentar de datos al nuevo sistema, tomando en
cuenta que hablar de un sistema antiguo incluye sistemas de carcter manual. Existen

5
bsicamente cuatro estrategias que permiten que este proceso se realice de forma eficiente
y son:
En paralelo: Cuando se utiliza ambos sistemas al mismo tiempo hasta que el nuevo
sistema se muestre estable. Este esquema es ms seguro y permite realizar
comparaciones de resultados, pero se debe considerar que el nuevo sistema talvez
contempla procesos que el anterior no tena y que se requiere el doble de tiempo.

Cambio directo: Cuando se determina que el nuevo sistema debe reemplazar por
completo al anterior y se usa el mismo en vez del otro para el desarrollo de
actividades diarias. Esta estrategia es la ms riesgosa pero obliga a que la
organizacin acepte el cambio.

Estudio piloto: Cuando se introduce el nuevo sistema en un rea limitada de la


organizacin hasta probar la funcionalidad del mismo, luego de lo cual se propaga
el sistema al resto de la organizacin. Este tipo de estrategia presente un nivel de
riesgo intermedio, pero su eficiencia depende de la correcta seleccin del rea de
prueba.

Por fases: Cuando el sistema es introducido en la organizacin en etapas basadas


en las funciones del mismo o las reas de la organizacin.
A ms de determinar una estrategia de conversin, es importante contar con:
Plan de conversin: Que determine el calendario de actividades que se requieren
para instalar el nuevo sistema;
Documentacin: Tcnica y de usuario que determine de forma clara y precisa el
funcionamiento y uso del sistema; y,

Esquema de capacitacin: Que determine los mecanismos de capacitacin de uso


del sistema, en funcin de los niveles de uso y acceso, nmero de participantes,
nmero de instructores y materiales necesarios.

- PRODUCCIN
Se considera que un sistema est en produccin luego de ha sido instalado completamente
y la fase de conversin ha concluido, lo que no implica que el sistema sea un esttico,
puesto que se pueden presentar cambios debido, entre otros a:
Determinacin que no se consideraron algunos requerimientos necesarios que
deberan ser implementados;
Determinacin de que el sistema no responde de forma eficiente a los
requerimientos del usuario final;
Falta de parametrizacin del sistema que impide la adaptacin del mismo a nuevas
normativas legales o cambio inesperado de las mismas que no puede ser soportado
por el esquema de parametrizacin usado;
Nuevos requerimientos; y
Cambio de hardware, software, documentacin.

6
- MANTENIMIENTO
El mantenimiento est conformado por los cambios en hardware, software, documentacin
o procedimientos de un sistema en produccin que se realizan para corregir errores,
mejorar procesos o implementar nuevos requerimientos y si estos cambios no son
implementados de forma eficiente, el sistema puede dejar de ser til y los costos
incrementarse innecesariamente.

7
b) MTODOS FORMALES

Qu son los mtodos formales?


Los mtodos formales (FM, por sus siglas en ingls) representan un conjunto de tendencias
de desarrollo de software y hardware en donde la especificacin, verificacin y diseo de
componentes se realiza mediante notaciones, lenguajes, herramientas y tcnicas basadas
en teoras con solida fundamentacin matemtica. El uso de notaciones y lenguajes
formales permite plantear de manera clara los requerimientos de un sistema, generando
especificaciones que definen el comportamiento en trminos del que debe hacer y no del
como lo hace. Gracias al correcto proceso de especificacin, propiedades derivadas de
cada mdulo pueden ser verificadas mediante tcnicas de razonamiento asociadas a los
modelos formales, como probadores de teoremas y verificadores de modelos.
A partir de las especificaciones, la implementacin de un sistema puede ser generada de
manera casi automtica. Es necesario bajar en el grado de abstraccin de las
especificaciones mediante tcnicas como refinamiento o concretizacin (reification). En
este proceso, denominado diseo formal, es necesario garantizar que cada nivel de
abstraccin generado cumple con las propiedades verificadas en los grados en las
abstracciones de ms alto nivel. En los niveles ms bajos es posible encontrar notaciones
y estructuras muy cercanas a los lenguajes de programacin, generando del ultimo nivel
una implementacin que puede ser verificada e instanciada en un lenguaje de
programacin.
Teniendo en cuenta los niveles de abstraccin y las caractersticas propias de cada sistema,
una variedad significativa de modelos han sido propuestos. En los procesos de
especificacin, tres grandes corrientes pueden ser identificadas: Lenguajes basados en
modelos y estados (e.g., VDM [16], Z [26] o sus posteriores extensiones en el mtodo B
[27]), Lenguajes de especificacin para sistemas concurrentes (el caso de CSP [13] o el
clculo [21 ) o especificaciones para sistemas temporales (e.g., TLZ[19], LOTOS [9] y los
clculos basados en tcc [25, 22]). Para los procesos de verificacin, dos grandes enfoques
son reconocidos: los verificadores de modelos, que realizan una bsqueda exhaustiva
sobre los estados posibles de una especificacin para encontrar posibles fallas no
consideradas, y los probadores de teoremas, en donde la especificacin y sus propiedades
deseables se formalizan como formulas lgicas, y se prueban mediante una serie de
axiomas y reglas de inferencia presentes en cada probador.
Los mtodos formales difieren en la manera y tiempos de cada una de las fases del ciclo
de vida del software. Su utilizacin requiere mayor tiempo en el desarrollo de especificacin
y la construccin de diseos correctos, lo que aumenta el tiempo de las fases de anlisis y
diseo; sin embargo, los 2 mtodos usados, correctos por construccin, disminuyen el
tiempo de verificacin del software, al requerir una cantidad de casos de prueba mucho ms
reducida que cubre todo el panorama de prueba, a diferencia de validaciones en base a
simulaciones que son incompletas e ineficientes.

Ventajas

Se comprende mejor el sistema.

8
La comunicacin con el cliente mejora ya que se dispone de una descripcin clara
y no ambigua de los requisitos del usuario.
El sistema se describe de manera ms precisa.
El sistema se asegura matemticamente que es correcto segn las
especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad

Desventajas

El desarrollo de herramientas que apoyen la aplicacin de mtodos formales es


complicado y los programas resultantes son incmodos para los usuarios.
Los investigadores por lo general no conocen la realidad industrial.
Es escasa la colaboracin entre la industria y el mundo acadmico, que en
ocasiones se muestra demasiado dogmtico.
Se considera que la aplicacin de mtodos formales encarece los productos y
ralentiza su desarrollo.

Entrenamiento

Los mtodos formales requieren de un nivel avanzado en matemticas. Ms que seguir una
notacin especfica, el mayor problema se presenta en los modelos mentales del equipo
desarrollador. Tpicamente, los modelos de licitacin de requerimientos plantean sus metas
en lenguaje natural, en busca de un correcto entendimiento entre el cliente y el equipo de
desarrollo. Sin embargo, la traduccin de los pliegos de requerimientos a especificaciones
formales tienden a resultar fallidas, generando solo especificaciones ambiguas e
incompletas. Es necesario un entrenamiento a nivel de todo el equipo de desarrollo, de
manera que cualquiera se encuentre en capacidad de definir y entender especificaciones
por s mismo.

Pluralidad de Modelos

Una de las dificultades en usar modelos formales es la ausencia de una metodologa nica
para el desarrollo de software. Diversos modelos han sido propuestos desde las
matemticas, cada uno especialmente diseado para las necesidades de un entorno
especfico: Refinamiento y mquinas de estados finitos para modelos secuenciales, redes
de Petri y algebras de procesos para computacin distribuida, lgicas temporales lineales
y ramificadas para computacin dinmica y modelos de eventos para computacin en
tiempo real son solo algunas de las mltiples ramas existentes. Esta multiplicidad de
enfoques tiene ventajas y desventajas: Es posible aprovechar cada uno de los formalismos
para expresar con mayor nivel de claridad una especificacin de un sistema; sin embargo,
la misma pluralidad de modelos exige un conocimiento experto en cada uno de los modelos
existentes para lograr el mayor aprovechamiento de los mtodos formales en la
especificacin de dichos sistemas.

Clasificacin

La clasificacin ms comn se realiza en base al modelo matemtico subyacente en cada


mtodo, de esta manera podran clasificarse en:

9
Especificaciones basadas en lgica de primer orden y teora de conjuntos: permiten
especificar el sistema mediante un concepto formal de estados y operaciones sobre
estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades
se expresan en lgica de primer orden. La semntica de los lenguajes est basada en
la teora de conjuntos. Los mtodos de este tipo ms conocidos son: Z, VDM y B.

Especificaciones algebraicas: proponen una descripcin de estructuras de datos


estableciendo tipos y operaciones sobre esos tipos. Para cada tipo se define un
conjunto de valores y operaciones sobre dichos valores. Las operaciones de un tipo se
definen a travs de un conjunto de axiomas o ecuaciones que especifican las
restricciones que deben satisfacer las operaciones. Mtodos ms conocidos: Larch,
OBJ, TADs.

Especificacin de comportamiento.

Mtodos basados en lgebra de procesos: modelan la interaccin entre procesos


concurrentes. Esto ha potenciado su difusin en la especificacin de sistemas de
comunicacin (protocolos y servicios de telecomunicaciones) y de sistemas distribuidos
y concurrentes. Los ms conocidos son: CCS,CSP y LOTOS.

Mtodos basados en Redes de Petri: una red de petri es un formalismo basado en


autmatas, es decir, un modelo formal basado en flujos de informacin. Permiten
expresar eventos concurrentes. Los formalismos basados en redes de petri establecen
la nocin de estado de un sistema mediante lugares que pueden contener marcas. Un
conjunto de transiciones (con pre y post condiciones) describe la evolucin del sistema
entendida como la produccin y consumo de marcas en varios puntos de la red.

Mtodos basados en lgica temporal: se usan para especificar sistemas concurrentes


y reactivos. Los sistemas reactivos son aquellos que mantienen una continua
interaccin con su entorno respondiendo a los estmulos externos y produciendo
salidas en respuestas a los mismos, por lo tanto el orden de los eventos en el sistema
no es predecible y su ejecucin no tiene por qu terminar.

10
c) REUTLIZACIN DE SOFTWARE

Qu es la reutilizacin de Software?

Es el proceso de creacin de sistemas de software a partir de un software existente, en


lugar de tener que redisear desde el principio.
En los aos 60, se construyeron bibliotecas de subrutinas cientficas reutilizables con un
dominio de aplicacin limitado, en la actualidad se crean componentes comunes a varios
procesos con el fin de poder utilizarlos en la construccin de software.
Podemos definirla como el empleo de elementos de software u otros de nivel superior,
creados en desarrollo anteriores, para de este modo reducir los tiempos y simplificar el
desarrollo del software, mejorando la calidad y reduciendo su costo.
Elementos que intervienen en la reutilizacin
Especificaciones de requerimientos previamente concebidas
Diseos previamente definidos (Estructuras de datos, algoritmos, etc.)
Cdigo probado y depurado con anterioridad
Planes y casos de prueba previamente utilizados
Personal cualificado (aprovechamiento de la experiencia de los ingenieros
de un proyecto a otro)
Paquetes de software de propsito general

Conceptos de reutilizacin de software

La reutilizacin de software aparece como una alternativa para desarrollar


aplicaciones y sistemas SW de una manera ms eficiente, productiva y rpida.
La idea es reutilizar elementos y componentes SW en lugar de tener que
desarrollarlos desde un principio.
Surge formalmente de 1968
La idea principal era producir componentes de software como si de componentes
elctricos se tratara.
El objetivo es reutilizar lo existente sin tener que volver a redisearlo desde el
principio.

Dificultades de la reutilizacin

En muchas empresas no existe plan de reutilizacin (No se considera prioritario)


Escasa formacin
Resistencia del personal
Pobre soporte metodolgico
Uso de mtodos que no promueven la reutilizacin (Estructurados)
Necesario mtodos para:

11
o Desarrollo para reutilizacin
o Desarrollo con reutilizacin
Quin soporta los gastos adicionales de la reutilizacin?

Ventajas

Reducir el tiempo de desarrollo.


Reducir los costos.
Incrementar la productividad.
No tener que reinventar las soluciones.
Facilitar la comparticin de productos del ciclo de vida.
Mayor fiabilidad
Mayor eficiencia (Aunque al principio pueda parecer que no)
Consistencia y la familiaridad, los patrones dentro del software sern ms
consistentes, tendiendo a facilitar el mantenimiento del producto.

Desventajas

Necesidad de invertir antes de obtener resultados.


Carencia de mtodos adecuados.
Necesidad de formar al personal.
Convencer a los manager.
Dificultad para institucionalizar los procesos.

Categoras de recurso de software

1. Componentes ya desarrollados
El software existente se puede adquirir de una tercera parte o provenir de uno
desarrollado internamente para un proyecto anterior. Llamados componentes CCYD
(componentes comercialmente ya desarrollados), estos componentes estn listos para
utilizarse en el proyecto actual y se han validado totalmente.

2. Componentes ya experimentados
Especificaciones, diseos, cdigo o datos de prueba existentes desarrollados para
proyectos anteriores que son similares al software que se va a construir para
el proyecto actual. Los miembros del equipo de software actual ya han tenido la
experiencia completa en el rea de la aplicacin representada para estos
componentes. Las modificaciones, por tanto, requeridas para componentes de total
experiencia, tendrn un riesgo relativamente bajo.

12
3. Componentes con experiencia parcial
Especificaciones, diseos, cdigo o datos de prueba existentes desarrollados para
proyectos anteriores que se relacionan con el software que se va a construir para el
proyecto actual, pero que requerirn una modificacin sustancial. Los miembros del
equipo de software actual han limitado su experiencia slo al rea de aplicacin
representada por estos componentes. Las modificaciones, por tanto, requeridas para
componentes de experiencia parcial tendrn bastante grado de riesgo.

4. Componentes nuevos
Los componentes de software que el equipo de software debe construir
especficamente para las necesidades del proyecto actual.

Tipos de reutilizacin

Oportunista
El ingeniero de software reutiliza piezas que l sabe que se ajustan al problema

Sistemtica
Esfuerzo a nivel organizacional y planificado de antemano
Todo componente reutilizado ha de ser ideado, a priori, para ser reutilizado
Implica inversiones iniciales para recoger frutos en el futuro
Disear componentes genricos para que sean reutilizados con facilidad

Bottom-Up
Se desarrollan pequeos componentes para una determinada aplicacin
Se incorpora a un repositorio

Top-Down
Se determinan las piezas necesarias que encajan unas con otras
Se van desarrollando poco a poco
Requiere alta inversin a comienzo
Se recogern beneficios en el futuro

Anlisis de escenarios para la reutilizacin

Existen al menos 4 escenarios en los que un proyecto de software requerir elementos de


reutilizacin.
1. El proyecto es similar a un anterior (reutilizacin de un proyecto existente).
2. Mismo proyecto con configuracin diferente (reutilizan productos actuales)
3. Caractersticas de uso basado en productos existentes
4. Nueva Arquitectura con capacidades o elementos existentes

13
g) INGENIERA DE SOFTWARE ASISTIDA POR
COMPUTADORA

Qu significa CASE?

El taller de ingeniera del software se denomina un entorno de apoyo integrado a proyectos,


y el conjunto de herramientas que llena ese taller se denomina ingeniera del software
asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de
automatizar actividades manuales y de mejorar su visin general de la ingeniera. Al igual
que las herramientas de ingeniera y de diseo asistidos por computadora que utilizan los
ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad
se disee antes de llegar a construir el producto.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software
Asistida por Computadora) son diversas aplicaciones informticas o programas informticos
destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de
las mismas en trminos de tiempo y de dinero.
Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el proceso de realizar un diseo del proyecto, clculo de costos,
implementacin de parte del cdigo automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre otras.
Bloques bsicos del case

La ingeniera del software asistida por computadora puede ser tan simple como una nica
herramienta que permita desarrollar una actividad especfica, o tan compleja como un
entorno que integre distintas herramientas, una base de datos, personas, hardware, una
red, sistemas operativos, estndares y muchos otros componentes. Los bloques de
construccin de CASE se ilustran en la figura 2.1. Cada bloque de construccin forma un
fundamento para el siguiente, estando las herramientas situadas en la parte superior del
montn. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos
tiene relativamente poco que ver con las herramientas de ingeniera del software en s. Ms
bien, los entornos que tienen xito para la ingeniera del software se construyen basndose
en una arquitectura de entorno que abarca un hardware adecuado y un software de sistema
adecuado. Adems, la arquitectura de entorno debe considerar los patrones de trabajo
humanos que se aplican durante el proceso de ingeniera del software.
Figura. 2.1

Herramientas CASE
Marco de Integracin
Servicios de Portabilidad
Sistema Operativo
Plataforma Hardware
Arquitectura de entorno
14
La arquitectura del entorno, que constan de una plataforma hardware y de un apoyo de
sistema operativo (incluyendo el software de red y de gestin de la base de datos),
constituye los fundamentos CASE. Pero el entorno CASE en s requiere otros bloques de
construccin. Existe un conjunto de servicios de portabilidad que proporciona un puente
entre las herramientas CASE y su marco de referencia de integracin y la arquitectura del
entorno. El marco de referencia de integracin es una coleccin de programas
especializados que capacitan a las herramientas CASE individuales para comunicarse entre
s, para crear una base de datos del proyecto y para mostrar el mismo aspecto al usuario
final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas
CASE y su marco de referencia de integracin migren entre distintas plataformas del
hardware y sistemas operativos sin un mantenimiento adaptativo que resulte significativo.
Los bloques de construccin representados en la figura 2.1 representan un fundamento
exhaustivo para la integracin de herramientas CASE. Sin embargo, la mayor parte de las
herramientas CASE que se utilizan en la actualidad no han sido construidas empleando
todos los bloques de construccin que se describen ms arriba. De hecho, algunas
herramientas CASE siguen siendo soluciones puntuales. Esto es, se utiliza una herramienta
para que preste su apoyo en una actividad de ingeniera del software concreta, pero esta
herramienta no se comunica directamente con otras, no est unida a una base de datos del
proyecto y no forma parte de un entorno integrado CASE (I-CASE). Aun cuando esta
situacin no es ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque
se trate de una solucin puntual.

Objetivos

1. Mejorar la productividad del software.


2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informticos.
4. Mejorar la planificacin de un proyecto.
5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la
bsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las
pruebas de errores y la gestin del proyecto.
7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la
documentacin.
8. Gestin global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.

Taxonoma de herramientas CASE

Existe un cierto nmero de riesgos que son inherentes siempre que se intenta efectuar una
categorizacin de las herramientas CASE. Existe una sutil implicacin consistente en que
para crear un entorno CASE efectivo uno debe de implementar todas las categoras de

15
herramientas. Se puede crear una confusin al ubicar una herramienta especfica dentro de
una categora, cuando otras personas pueden creer que pertenece a otra categora.
Las herramientas CASE se pueden clasificar por su funcin, por su papel como
instrumentos para administradores o personal tcnico, por su utilizacin en los distintos
pasos del proceso de ingeniera del software, por la arquitectura de entorno (hardware y
software) que les presta su apoyo, o incluso por su origen o su coste. La taxonoma que se
presenta ms abajo utiliza como criterio principal la funcin:
Herramientas de la ingeniera de la informacin. Al modelar los requisitos de informacin
estratgica de una organizacin, las herramientas de la ingeniera de la informacin
proporcionan un metamodelo del cual se derivan sistemas de informacin especficos. En
lugar de centrarse en los requisitos de una aplicacin especfica, estas herramientas CASE
modelan la informacin de negocios cuando sta se transfiere entre distintas entidades
organizativas en el seno de una compaa. El objetivo primordial de las herramientas de
esta categora consiste en representar objetos de datos de negocios, sus relaciones, y la
forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de
la compaa.
Modelado de procesos y herramientas de administracin. Si una organizacin intenta
mejorar un proceso de negocios (o de software) lo primero que debe de hacer es entenderlo.
Las herramientas de modelado de procesos se utilizan para representar los elementos clave
del proceso de modo que sea posible entenderlo mejor. Estas herramientas tambin
pueden proporcionar vnculos con descripciones de procesos que ayuden a quienes estn
implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese
proceso. Adems, las herramientas de administracin de procesos pueden proporcionar
vnculos con otras herramientas que proporcionen un apoyo para actividades de proceso
ya definidas.
Herramientas de planificacin de proyectos. Las herramientas de esta categora se
concentran en dos reas primordiales: estimacin de esfuerzos de proyecto y de costes de
software, y planificacin de proyectos. Las herramientas de planificacin de proyectos
capacitan al administrador para definir todas las tareas del proyecto (la estructura de
desglose de tareas), para crear una red de tareas (normalmente empleando una entrada
grfica), para representar las interdependencias entre tareas y para modelar la cantidad de
paralelismo que sea posible para ese proyecto.
Herramientas de anlisis de riesgos. La identificacin de riesgos potenciales y el
desarrollo de un plan para mitigar, monitorizar y administrar esos riesgos tiene una
importancia fundamental en los grandes proyectos. Las herramientas de anlisis de riesgos
capacitan al administrador del proyecto para construir una tabla de riesgos proporcionando
una gua detallada en la identificacin y anlisis de riesgos.
Herramientas de administracin de proyectos. La planificacin del proyecto y el plan del
proyecto deben de seguirse y de monitorizarse de forma continua. Adems, el gestor
deber de utilizar las herramientas que recojan mtricas que en ltima instancia
proporcionen una indicacin de la calidad del producto del software. Las herramientas de
esta categora suelen ser extensiones de herramientas de planificacin de proyectos.
Herramientas de seguimiento de requisitos. Cuando se desarrollan grandes sistemas,
el sistema proporcionado suele no satisfacer los requerimientos especificados por el cliente.
El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque
sistemtico para el aislamiento de requisitos, comenzando por la solicitud del cliente de una

16
propuesta (RFP) o especificacin. Las herramientas de trazado de requisitos tpicas
combinan una evaluacin de textos por interaccin humana, con un sistema de gestin de
bases de datos que almacena y categoriza todos y cada uno de los requisitos del sistema
que se analizan a partir de la RFP o especificacin original.
Herramientas de mtricas y gestin. Las mtricas de software mejoran la capacidad del
administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero
para mejorar la calidad del software que se produce. Las mtricas y herramientas de medida
actuales se centran en procesos, proyectos y caractersticas del producto. Las herramientas
orientadas tcnicamente determinan mtricas tcnicas que proporcionan una mejor visin
de la calidad del diseo o del cdigo. Muchas de las herramientas mtricas avanzadas
mantienen una base de datos de medidas de medias de la industria. Basndose en
caractersticas de proyectos y de productos proporcionados por el usuario, estas
herramientas califican los nmeros locales frente a los valores medios de la industria (y
frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras.
Herramientas de documentacin. Las herramientas de produccin de documentos y
autoedicin prestan su apoyo a casi todos los aspectos de la ingeniera, y representan una
importante oportunidad de aprovechamiento para todos los desarrolladores de software. La
mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad
de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de
documentacin en s resulta bastante deficiente. No es infrecuente que una organizacin
de desarrollo de software invierta hasta un 20 o un 30 por ciento de su esfuerzo global de
desarrollo de software en la documentacin. Por esta razn, las herramientas de
documentacin suponen una oportunidad importante para mejorar la productividad.
Herramientas de software de sistema. CASE es una tecnologa de estaciones de trabajo.
Por tanto, el entorno CASE debe adaptarse a un software de sistema de red de alta calidad,
al correo electrnico, a los boletines electrnicos y a otras capacidades de comunicaciones.
Herramientas de control de calidad. La mayor parte de las herramientas CASE que
afirman que tienen como principal inters el control de calidad son en realidad herramientas
mtricas que hacen una auditora del cdigo fuente para determinar si se ajusta o no a
ciertos estndares del lenguaje. Otras herramientas extraen mtricas tcnicas en un
esfuerzo por extrapolar la calidad del software que se est construyendo.
Herramientas de gestin de base de datos. El software de gestin de bases de datos
sirve como fundamento para establecer una base de datos CASE (depsito), que tambin
se denominar base de datos del proyecto. Dado el nfasis acerca de los objetos de
configuracin, las herramientas de gestin de bases de datos para CASE pueden
evolucionar a partir de los sistemas de gestin de bases de datos relacionales (SGBDR)
para transformarse en sistemas de gestin de bases de datos orientadas a objetos
(SGBDOO).
Herramientas de gestin de configuracin de software. La gestin de configuracin de
software (GCS) se encuentra en el ncleo de todos los entornos CASE. Las herramientas
pueden ofrecer su asistencia en las cinco tareas principales de GCS: identificacin, control
de versiones, control de cambios, auditora y contabilidad de estados. La base de datos
CASE proporciona un mecanismo para identificar todos los elementos de configuracin y
relacionarlo con otros elementos.
Herramientas de anlisis y diseo. Las herramientas de anlisis y diseo capacitan al
ingeniero del software para crear modelos del sistema que haya que construir. Los modelos

17
contienen una representacin de los datos, de la funcin y del comportamiento (en el nivel
de anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos
e interfaz. Al efectuar una comprobacin de la consistencia y validez del modelo, las
herramientas de anlisis y diseo proporcionan al ingeniero de software un cierto grado de
visin en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes de
que se propaguen al diseo, o lo que es peor, a la propia implementacin.
Herramientas PRO/SIM. Las herramientas PRO/SIM (de prototipos y simulacin)
proporcionan al ingeniero de software la capacidad de predecir el comportamiento de un
sistema en tiempo real antes de llegar a construirlo. Adems, capacitan al ingeniero del
software para desarrollar simulaciones del sistema en tiempo real que permitirn al cliente
obtener ideas acerca de su funcionamiento, comportamiento, y respuesta antes de la
verdadera implementacin.
Herramientas de desarrollo y diseo de interfaz. Las herramientas de desarrollo y diseo
de interfaz son en realidad un conjunto de primitivas de componente de programas tales
como mens, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento,
controladores de dispositivos etc. Sin embargo, estos conjuntos de herramientas se estn
viendo sustituidos por herramientas de generacin de prototipos de interfaz que permiten
una rpida creacin en pantalla de sofisticadas interfaces de usuario, que se ajustan al
estndar de interfaz que se haya adoptado para el software.
Herramientas de generacin de prototipos. Se pueden utilizar toda una gama de
herramientas de generacin de prototipos. Los generadores de pantallas permiten al
ingeniero de software definir rpidamente la disposicin de la pantalla para aplicaciones
interactivas. Otras herramientas de prototipos CASE ms sofisticadas permiten la creacin
de un diseo de datos, acoplado con las disposiciones de la pantalla y de los informes
simultneamente. Muchas herramientas de anlisis y diseo proporciona extensiones
PRO/SIM generan un esqueleto de cdigo fuente en Ada y C para las aplicaciones de
ingeniera (en tiempo real). Por ltimo, una gama de herramientas de cuarta generacin
poseen tambin caractersticas de generacin de prototipos.
Herramientas de programacin. La categora de herramientas de programacin abarca
los compiladores, editores, y depuradores que estn disponibles para prestar su apoyo en
la mayora de los lenguajes de programacin convencionales. Adems, los entornos de
programacin orientados a objetos (OO), los lenguajes de cuarta generacin, los entornos
de programacin grfica, los generadores de aplicaciones, y los lenguajes de consulta de
bases de datos residen tambin en esta categora.
Herramientas de integracin y comprobacin. En su directorio de herramientas de
comprobacin de software, Software Quality Engineering define las siguientes categoras
de herramientas de comprobacin:
Adquisicin de datos: herramientas que adquieren datos que se utilizarn durante la
comprobacin.
Medida esttica: herramientas que analizan el cdigo fuente sin ejecutar casos de
prueba.
Medida dinmica: herramientas que analizan el cdigo fuente durante la ejecucin.
Simulacin: herramientas que simulan las funciones del hardware o de otros elementos
externos.
Administracin de comprobaciones: herramientas que prestan su asistencia en la
planificacin, desarrollo y control de comprobaciones.

18
Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los lmites
de las categoras anteriores.

Debera tenerse en cuenta que muchas de las herramientas de comprobacin poseen


caractersticas que abarcan dos o ms de las categoras anteriores.
Herramientas de anlisis esttico. Las herramientas de anlisis esttico prestan su
asistencia al ingeniero del software a efectos de derivar casos prcticos. Se utilizan tres
tipos distintos de herramientas estticas de comprobacin en la industria: Herramientas de
comprobacin basadas en cdigo, lenguajes de comprobacin especializados, y
herramientas de comprobacin basadas en requisitos. Las herramientas de comprobacin
basadas en cdigo admiten un cdigo fuente (o PDL) como entrada, y efectan un cierto
nmero de anlisis que dan lugar a la generacin de casos de prueba. Los lenguajes de
comprobacin especializados capacitan el ingeniero del software para escribir detalladas
especificaciones de comprobacin que describirn todos los casos de prueba y la logstica
de su ejecucin. Las herramientas de comprobacin basadas en requisitos aslan requisitos
especficos del usuario y sugieren casos de prueba (o clases de comprobaciones) que
ejerciten estos requisitos.
Herramientas de anlisis dinmico. Las herramientas de anlisis dinmico interactan
con un programa que se est ejecutando, comprueban la cobertura de rutas, comprueban
las afirmaciones acerca del valor de variables especficas y en general instrumentan el flujo
de ejecucin del programa. Las herramientas dinmicas pueden ser bien intrusivas, bien no
intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar
mediante sondas que se insertan (instrucciones adicionales) y que efectan las actividades
mencionadas anteriormente. Las herramientas de comprobacin no intrusivas utilizan un
procesador hardware por separado que funciona en paralelo con el procesador que
contenga el programa que se est comprobando.
Herramientas de gestin de comprobacin. Las herramientas de gestin de
comprobacin se utilizan para comprobar y coordinar la comprobacin de software para
cada uno de los pasos principales de comprobacin. Las herramientas de esta categora
administran y coordinan la comprobacin de regresiones, efectan comparaciones que
determinan las diferencias entre la salida real y la esperada, y efectan comprobaciones
por lotes de programas con interfaces interactivas entre hombre y mquina. Adems de las
funciones indicadas anteriormente, muchas herramientas de gestin de comprobaciones
sirven tambin como controladores de comprobacin genricos. Un controlador de
comprobacin lee uno o ms casos de prueba de algn archivo de pruebas, da formato a
los datos de prueba para que se ajusten a las necesidades del software que se est
probando, e invoca entonces al software que sea preciso comprobar.
Herramientas de comprobacin cliente/servidor. El entorno C/S exige unas
herramientas de comprobacin especializadas que ejerciten la interfaz grfica de usuario y
los requisitos de comunicaciones en red para el cliente y el servidor.
Herramientas de reingeniera. La categora de herramientas de reingeniera se puede
subdividir en las funciones siguientes:
Herramientas de ingeniera inversa para producir especificaciones: se toma el
cdigo fuente como entrada y se generan modelos grficos de anlisis y diseo
estructurados, listas de utilizacin y otras informaciones de diseo.

19
Herramientas de reestructuracin y anlisis de cdigo: se analiza la sintaxis del
programa, se genera una grfica de control de flujo y se genera automticamente un
programa estructurado; y
Herramientas de reingeniera para sistemas en lnea: se utilizan para modificar
sistemas de bases de datos en lnea (por ejemplo para convertir archivos IDMS o DB2
traducindolos a un formato de entidades y relaciones).

Muchas de las herramientas anteriores estn limitadas a lenguajes de programacin


especficos (aun cuando se abarcan la mayora de los lenguajes principales) y requieren un
cierto grado de interaccin con el ingeniero del software.
Las herramientas de ingeniera inversa y progresiva de la prxima generacin harn un uso
mucho mayor de tcnicas de inteligencia artificial, aplicando una base de conocimientos
que sea especfica del dominio de la aplicacin. El componente de inteligencia artificial
asistir en la descomposicin y reconstruccin del sistema, pero seguir requiriendo una
interaccin con un ingeniero de software a lo largo del ciclo de la reingeniera.

Tipos

La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que
cubren:
Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin,
anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas
UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y


diseo de la aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de


cdigo, crean programas de deteccin de errores, soportan la depuracin de
programas y pruebas. Adems automatizan la documentacin completa de la
aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de
aplicaciones.

Entornos CASE Integrados

Requisitos de un entorno CASE integrado:


Proporcionar un mecanismo para compartir la informacin de la ingeniera del
software entre todas las herramientas dentro del entorno.
Hacer posible que un cambio de un elemento de informacin se siga hasta los
dems elementos de informacin relacionados.
Proporcionar un control de versiones y una gestin de configuracin general para
toda la informacin de la ingeniera del software.

20
Permitir un acceso directo y no secuencial a cualquier herramienta del entorno.
Establecer un apoyo automatizado para el modelo de procesos de software que
se haya seleccionado, integrando herramientas CASE y elementos de
configuracin del software en una estructura estndar de desglose de trabajo.
Permitir que los usuarios de cada una de las herramientas puedan experimentar
con el aspecto e interaccin de la interfaz hombre-mquina.
Dar soporte a la comunicacin entre ingenieros del software.
Recoger mtricas tanto tcnicas como de gestin que se puedan utilizar para
mejorar el proceso y el producto.

21
2. PROCESOS DEL SOFTWARE Y MTRICAS

PARADIGMAS DE LA INGENIERA DE SOFTWARE


Para la Ingeniera de Software el paradigma es una agrupacin de mtodos, herramientas
y procedimientos con el fin de describir u modelo.

Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas,


que permite producir programas con una directriz especfica, tales como: estructura
modular, fuerte cohesin, alta rentabilidad, etc.

Existen tres categoras de paradigmas de programacin:


a) Los que soportan tcnicas de programacin de bajo nivel (ejemplo: copia de ficheros
frente estructuras de datos compartidos)

b) Los que soportan mtodos de diseo de algoritmos (ejemplo: divide y vencers,


programacin dinmica, etc.)

c) Los que soportan soluciones de programacin de alto nivel, como los descritos en
el punto anterior

Los paradigmas relacionados con la programacin de alto nivel se agrupan en tres


categoras de acuerdo con la solucin que aportan para resolver el problema:
a) Solucin procedimental u operacional. Describe etapa a etapa el modo de construir
la solucin. Es decir seala la forma de obtener la solucin.

b) Solucin demostrativa. Es una variante de la procedimental. Especifica la solucin


describiendo ejemplos y permitiendo que el sistema generalice la solucin de estos
ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho
de producir resultados muy diferentes a sta, hace que sea tratada como una
categora separada.

c) Solucin declarativa. Seala las caractersticas que debe tener la solucin, sin
describir cmo procesarla. Es decir seala qu se desea obtener pero no cmo
obtenerlo.

Paradigmas de la Ingeniera de Software

La ingeniera del Software define paradigmas de desarrollo estructurado como base a


seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al problema
por resolver, entonces el desarrollador se ver obligado a combinar los paradigmas o definir
uno nuevo.

22
Para resolver los problemas reales de una industria, un ingeniero del software o un equipo
de ingenieros deben incorporar una estrategia de desarrollo que acompae al proceso,
mtodos, capas de herramientas.

La estrategia a menudo se llama modelo de proceso o paradigma de ingeniera del software.


Se selecciona un modelo de proceso para la ingeniera del software segn la naturaleza del
proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, y los controles y
entregas que se requieren.

Raccoon [RAC95] sugiere un << modelo del caos >> que describa el << desarrollo del
software como una extensin desde le usuario hasta el desarrollador y la tecnologa >>.
Conforme progresa el trabajo hacia un sistema completo, las etapas descritas a
continuacin se aplican recursivamente a las necesidades, del usuario y a la especificacin
tcnica del desarrollador del software.

Fases generales del proceso de Desarrollo de Software

Independientemente del procedimiento de desarrollo, la aplicacin del software y el tamao


del proyecto; el desarrollo de software contiene tres fases genricas definicin, desarrollo y
mantenimiento, desde la concepcin de desarrollo estructurado de software.

Fase general Descripcin


Parte fundamental del desarrollo de software.
Identifica los requisitos clave del sistema.
De definicin. Producto final: el ERS , documento base para el control del
cumplimiento de requerimientos de usuario.

Referida a cmo han de disearse los componentes del


software.
Comprende etapas como diseo de estructuras, modelo de
De desarrollo. requisitos, diseo de interfaz, estructura de la base de
datos, codificacin y prueba por parte del programador y del
cliente.

Fase post implantacin.


Aplica las etapas de las fases de definicin y desarrollo
De mantenimiento
sobre el software final.

Los paradigmas de la ingeniera de software conservan estas fases generales, variando los
mtodos, las herramientas y procedimientos para aplicarlos.

23
La ingeniera de software tiene varios modelos o paradigmas de desarrollo en los cuales se
puede apoyar para la realizacin de software, de los cuales podemos destacar a stos por
ser los ms utilizados y los ms completos:

Modelo en cascada o Clsico (modelo tradicional)


Modelo en espiral (modelo evolutivo)
Modelo de prototipos
Desarrollo por etapas
Desarrollo iterativo y creciente o Interativo Incremental
RAD (Rapid Application Development)

24
MODELO LINEAL SECUENCIAL

Llamado algunas veces "ciclo de vida bsico" o "modelo en cascada", el modelo lineal
secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que
comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas
y mantenimiento.

Es un ciclo de vida en sentido amplio, que incluye no slo las etapas de ingeniera sino toda
la vida del producto: las pruebas, el uso (la vida til del software) y el mantenimiento.

Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia
abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades,
el diseo, implantacin, pruebas (validacin), la integracin, y mantenimiento.

La primera descripcin formal del modelo de cascada se cita a menudo a un artculo


publicado por Winston Royce en 1970, aunque Royce no utiliz el trmino "cascada" en
este artculo.

Es el paradigma ms antiguo y fue el ms utilizado durante la hegemona del mtodo


estructurado. El nmero de etapas propuestas vara de acuerdo al proyecto a desarrollar,
aunque existen etapas comunes para este paradigma.

Este paradigma concibe las fases de desarrollo como proceso independientes en el tiempo,
es decir, no se pueden realizar de manera simultnea; cada fase empieza cuando se ha
terminado la fase anterior y para poder pasar a otra fase es necesario haber conseguido
todos los objetivos de la etapa previa.

Las etapas de este paradigma se desarrollan en forma secuencial y cuando se detecta


algn error en alguna etapa, lo ms probable ser abandonar todo lo avanzado y regresar
a la etapa primera de anlisis de requisitos del sistema; pues, aunque la vuelta atrs por
etapas es posible, sta demanda mucho esfuerzo y puede terminar en el colapso.

25
Ventajas

Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor
que ninguno.

Facilita la gestin del desarrollo

Desventajas

En general, establecer todos los requisitos al principio del proceso


de desarrolloes un mito inalcanzable, Los usuarios no pueden imaginarse lo que
quieren hasta que no ven un sistema funcionando.

Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado


cambia, todo cambia.

El usuario debe esperar mucho tiempo hasta ver los resultados

Los errores de anlisis y diseo son costosos de eliminar, y se propagan a las fases
siguientes con un efecto conocido como bola de nieve.

Se genera mucho mantenimiento inicial debido al perodo de congelacin de


requisitos y ste recae, en su mayor parte.

Etapas del modelo lineal secuencial

1. Ingeniera del sistema: Anlisis de las caractersticas y el comportamiento del sistema


del cual el software va a formar parte.

Para un sistema nuevo: Se debe analizar cules son los requisitos funciones del sistema,
y luego asignar un subconjunto de estos requisitos y funciones al software.

Para un sistema ya existente: se debe analizar el funcionamiento de la organizacin y


sus operaciones y se asigna al software aquellas funciones que se van a automatizar.

Est formado por diagramas y por descripciones en lenguaje natural.

2. Anlisis: Se debe comprender cules son los datos que se van a manejar, cul
va a ser la funcin que tiene que cumplir el software, cules son las interfaces
requeridas y cul es el rendimiento y otros requisitos no funcionales que se
esperan lograr.

Los requisitos, tanto del sistema como del software deben documentarse y revisarse con
el cliente. Como resultado de la fase de anlisis, se obtiene la especificacin de
requisitos del software.

26
Tambin est formado por diagramas y descripciones en lenguaje natural.

3. Diseo: El diseo se aplica a cuatro caractersticas distintas del software: la


estructura de los datos, la arquitectura de las aplicaciones, la estructura interna
de los programas y las interfaces.

El diseo es el proceso que traduce los requisitos en una representacin del software de
forma que pueda conocerse la arquitectura, funcionalidad e incluso la calidad del mismo
antes de comenzar la codificacin.

En el diseo, los requisitos del software se traducen a una serie de diagramas que
representan la estructura del sistema software, de sus datos, de sus programas y de sus
interfaces.

4. Codificacin: Consiste en la traduccin del diseo a un formato que sea comprensible


para la mquina. Si el diseo es lo suficientemente detallado, la codificacin es
relativamente sencilla, y puede hacerse de forma automtica, usando generadores de
cdigo.

Se traducen los diagramas de diseo a un lenguaje fuente, que luego se traduce - se


compila - para obtener un programa ejecutable.

5. Prueba: El objetivo es comprobar que no se hayan producido errores en alguna de las


fases anteriores, especialmente en la codificacin. Se deben probar todas las
sentencias, y todos los mdulos que forman parte del sistema.

6. Utilizacin: El software se entrega al cliente y comienza la vida til del mismo.

7. Mantenimiento: El software sufrir cambios a lo largo de su vida til. Estos cambios


pueden ser debidos a tres causas:
Que, durante la utilizacin, el cliente detecte errores en el software: los errores
latentes.
Que se produzcan cambios en alguno de los componentes del sistema.
Que el cliente requiera modificaciones funcionales no contempladas en el
proyecto.
El mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya
existente y no a uno nuevo.

27
MODELO DE MTODOS FORMALES

El modelo de mtodos formales acompaa a un conjunto de actividades que conducen a la


especificacin matemtica del software de computadora. Los mtodos formales permiten
que un ingeniero del software especifique, desarrolle y verifique un sistema basado en
computadora aplicando una notacin rigurosa y matemtica.

La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms


fcilmente, no mediante una revisin a propsito para el caso, sino mediante la aplicacin
del anlisis matemtico. Cuando se utilizan mtodos formales durante el diseo, sirven
como base para la verificacin de programas y por consiguiente permiten que el ingeniero
del software descubra y corrija errores que no se pudieron detectar de otra manera.

Aunque todava no hay un enfoque establecido, los modelos de mtodos formales ofrecen
la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran
preocupacin sobre su aplicabilidad en un entorno de gestin

Grfico de los modelos de mtodos formales

Ventajas e Inconvenientes
Si bien los mtodos formales constituyen un acercamiento alternativo a las
metodologas de desarrollo de software, existen un numero de diferencias
signicativas que deben de ser consideradas

Ofrece un fundamento para entornos de especificacin que dan lugar a modelos


de anlisis ms completos, consistentes y carentes de ambigedad, que aquellos
que se producen empleando mtodos convencionales u orientados a objetos.

al pensar en instaurar los mtodos formales en un equipo de desarrollo de


software

28
DESARROLLO BASADO EN COMPONENTES
El desarrollo de software basado en componentes permite reutilizar piezas de cdigo
preelaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como
las mejoras a la calidad, la reduccin del ciclo de desarrollo y el mayor retorno sobre la
inversin.

La reutilizacin de software es un proceso de la Ingeniera de Software que conlleva al uso


recurrente de activos de software en la especificacin, anlisis, diseo, implementacin y
pruebas de una aplicacin o sistema de software.

Un componente es una unidad de composicin de aplicaciones software, que posee un


conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con otros componentes de forma
independiente, en tiempo y espacio

Caractersticas de un Componente

Identificable: Debe tener una identificacin que permita acceder fcilmente a sus
servicios que permita su clasificacin.

Auto contenido: Un componente no debe requerir de la utilizacin de otros para


finiquitar la funcin para la cual fue diseado.

Puede ser remplazado por otro componente: Se puede remplazar por nuevas
versiones u otro componente que lo remplace y mejore.

Con acceso solamente a travs de su interfaz: Debe asegurar que estas no


cambiaran a lo largo de su implementacin.

Sus servicios no varan: Las funcionalidades ofrecidas en su interfaz no deben variar,


pero su implementacin s.

Bien Documentado: Un componente debe estar correctamente documentado


para facilitar su bsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.

Es genrico: Sus servicios deben servir para varias aplicaciones.

Reutilizado dinmicamente: Puede ser cargado en tiempo de ejecucin en una


aplicacin.

Independiente de la plataforma: Hardware, Software, S.O.

Beneficios del Desarrollo de Software basado en Componentes


En esencia, un componente es una pieza de cdigo preelaborado que encapsula alguna
funcionalidad expuesta a travs de interfaces estndar. Los componentes son los
"ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea .

29
Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en
nuestra sala. Cada componente de aquel aparato ha sido diseado para acoplarse
perfectamente con sus pares, las conexiones son estndar y el protocolo de comunicacin
est ya preestablecido. Al unirse las partes, obtenemos msica para nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos
componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

El uso de este paradigma posee algunas ventajas:

1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de


software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno
de los componentes antes de probar el conjunto completo de componentes
ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes segn
sea necesario, sin afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organizacin, la calidad de una aplicacin basada
en componentes mejorar con el paso del tiempo.

De la misma manera, el optar por comprar componentes de terceros en lugar de


desarrollarlos, posee algunas ventajas:

1. Ciclos de desarrollo ms cortos. La adicin de una pieza dada de funcionalidad


tomar das en lugar de meses o aos.
2. Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversin
puede ser ms favorable que desarrollando los componentes uno mismo.
3. Funcionalidad mejorada. Para usar un componente que contenga una pieza de
funcionalidad, solo se necesita entender su naturaleza, ms no sus detalles internos.
As, una funcionalidad que sera imprctica de implementar en la empresa, se vuelve
ahora completamente asequible.

Desventajas

Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere


experiencia en la identificacin de riesgos.

Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste
dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

Etapas

El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas


del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la
creacin del software.

30
Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones
desde componentes preparados de software (llamados clases).

La actividad de la ingeniera comienza con la identificacin de clases candidatas. Esto se


lleva a cabo examinando los datos que se van a manejar por parte de la aplicacin y el
algoritmo que se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos
correspondientes se empaquetan en una clase.

Las clases creadas en los proyectos de ingeniera del software anteriores, se almacenan
en una biblioteca de clases o diccionario de datos.

Una vez identificadas las clases candidatas, la biblioteca de clases se examina para
determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca
y se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los
mtodos orientados a objetos.

Se compone as la primera iteracin de la aplicacin a construirse, mediante las clases


extradas de la biblioteca y las clases nuevas construidas para cumplir las necesidades
nicas de la aplicacin. El flujo del proceso vuelve a la espiral y volver a introducir por
ltimo la iteracin ensambladora de componentes a travs de la actividad de ingeniera.

31
REFERENCIAS
http://www.docsity.com/es/metodos_convencionales_de_la_ingenieria_de_software_-
_apuntes_-_ingenieria_del_software/327399/

http://homepages.lasige.di.fc.ul.pt/~halopez/Publications_files/FMNotes.pdf

http://jurifa-ingenieriadesoftware.blogspot.mx/2012/09/reutilizacion-de-software.html

http://kennycoleman15.blogspot.mx/2010/12/ingenieria-de-software-asistidas-por.html

http://ingenieraupoliana.blogspot.mx/2010/12/asistida-por-computadoras.html

http://www.sites.upiicsa.ipn.mx/polilibros/portal/polilibros/P_proceso/ANALISIS_Y_DISEn
O_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20I/1.5.htm

http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/leccin_11__
el_modelo_lineal_secuencial.html

http://quintomodelos.blogspot.mx/

https://msdn.microsoft.com/es-es/library/bb972268.aspx

https://matriarm.wordpress.com/desarrollo-basado-en-componentes/

Ingeniera de Software un Enfoque prctico - Sptima Edicin - Pressman Roger S.

32