IS 453 Ingeniera de Software

Ing. Juan Carlos Carreo Gamarra

INTRODUCCIN
La

primera referencia que describe ampliamente el

procedimiento de la Ingeniera de Sistemas fue publicada

en 1950 por Melvin J. Kelly.
En opinin de Arthur D. Hall, "la funcin de Ingeniera de

Sistemas se haba practicado durante muchos aos en las

Organizaciones.

Qu es ingeniera de SW?

La aplicacin de un enfoque sistemtico,

disciplinado y cuantificable hacia el desarrollo,
operacin y mantenimiento del Software, es
decir, la aplicacin de la ingeniera al Software
[IEEE]

Niveles de la Ingeniera de Software

Procesos de desarrollo de SW.

Ciclo de vida: Sucesin de etapas por las

que atraviesa un producto software a lo largo

de su desarrollo y existencia.

Existen distintas formas o paradigmas de

ciclo de vida:

Secuencial, cascada.
Orientado a prototipos
Evolutivo
Incremental
Espiral
Componente

Procesos de desarrollo de SW.

Secuencial

Anlisis
Comprender
la naturaleza
del dominio.
Especificacin
de los
requisitos

Diseo
Estructura de
datos
Arquitectura de
SW
Representacion
es de la Interfaz
Algoritmos

Cdigo
Construccin
del SW. En
base al diseo

Prueba
Prueba de
procesos
lgicos
internos.
Pruebas
funcionales

Procesos de desarrollo de SW.

Cascada
Anlisis
Diseo

Codificacin y
pruebas unitarias
Operacin y
mantenimiento
Integracin del
sistema

Procesos de desarrollo de SW.

Prototipos
Mecanismo de especificacin de requisitos.
Cuando solo se tienen requisitos muy generales por

parte del cliente, es prctico utilizar este paradigma.

Sistemas muy complejos de entender.

Prototipear consiste en construir una versin inicial

de un producto, en la cual se describe la interaccin

hombre-mquina sin implementar completamente la
funcionalidad
del
sistema
(prototipo
sin
funcionalidad).

Procesos de desarrollo de SW.

Prototipos

Utilidad:
Ayuda a los analistas a establecer las

necesidades del cliente.

Ayuda a los desarrolladores a mejorar
los productos.
Ciclo
que primero, revisa los
requerimientos del cliente. Luego, se
construye un prototipo y finalemnte el
cliente lo prueba, para iniciar
nuevamente el ciclo.

Procesos de desarrollo de SW.

Prototipos
Clases de prototipos:
Vertical: desarrolla completamente algunas de las facetas del

producto.
Horizontal: desarrolla parcialmente todas las facetas del

producto.
Evolutivo: La versin final es el producto ya construido.
Desechable: Se usa sola para la captacin de requerimientos y

funcionalidad.

Procesos de desarrollo de SW.

Modelos evolutivos
Modelos evolutivos son iterativos.
Permite al equipo de desarrollo

completas del software.

Tipos de modelos:
Incremental
Espiral
Ensamblaje de componentes

generar versiones mas

Procesos de desarrollo de SW.

Modelos evolutivos: Incremental
Los riesgos asociados en el desarrollo de grandes

sistemas son altos.

Construir solo una parte del sistema, dejando otras

funciones para futuras versiones.

Requerimientos

Desarrollo
Primera
versin

Desarrollo
Segunda
versin

Requerimiento
s

Desarrollo
Primera
versin

Requerimiento
s

Desarrollo
Segunda
versin

Modelos evolutivos: Espiral

Espiral se divide en 6 regiones, llamadas

regiones de tarea.
1. Comunicacin con el cliente
2. Planificacin
3. Anlisis de riesgo
4. Ingeniera
5. Construccin y adaptacin

6. Evaluacin del cliente

Procesos de desarrollo de SW.

Modelos evolutivos: Espiral

Procesos de desarrollo de SW.

Modelos evolutivos: Componentes
Ms adecuado para la construccin de SW orientado a

objeto.
Orientacin a objetos encapsula datos y mtodos.
Centrado a la construccin de componentes que no estn

en una biblioteca de clases.

Si el componente no existe se sigue un paradigma de

desarrollo.

Procesos de desarrollo de SW.

Modelos evolutivos: Componentes

Procesos de desarrollo de SW.

RUP: Rational Unified Process
Proceso de desarrollo propuesto por Rational

basado en buenas prcticas.

Consiste en un conjunto de templates, blueprints

y documentacin que cubren todo el proceso de

desarrollo.

Metodologas de Anlisis y Diseo

(OOA/OOD)
Booch (OOAD)
Rumbaugh (OMT)
Jacobson (OOSE)
UML (Unified Modelling Language)

Lenguaje visual
Unin de los tres anteriores
Estndar internacional (OMG)
Versin actual: 2.0
UP (Unified Process)
Metodologa de diseo iterativo
Basada en casos de uso
Incorpora UML de forma natural

OOAD (Booch)
Tipos de relaciones
Herencia o Generalizacin
Agregacin o Composicin

Asociacin
Metaclase
Instanciacin (plantillas)
Cliente-Servidor (acceso)

OOAD (Grady Booch)

Tipos de clases
Clases ordinarias
Metaclases
Categoras de clases
Clases parametrizadas (plantillas)
Clases instanciadas (plantillas)
Utilidades de clase: subprogramas libres y clases estticas

Partes de UML
Vistas
Conjunto de diagramas
Diagramas
9 tipos de grafos
Combinan los elementos del modelo

Elementos del modelo

Clases, objetos, mensajes, relaciones
Mecanismos generales
Comentarios,

adaptaciones

informacin, semntica, extensiones y

VISTAS
Vista de Casos de Uso
Funcionalidad externa del sistema
Vista Lgica
Estructura esttica y conducta dinmica del sistema
Vista de Componentes (software)

Organizacin de las componentes

Vista de Concurrencia
Comunicaciones y sincronizacin
Vista de Despliegue (deployment)
Arquitectura fsica

Las Vistas en UML

lgica

Casos
uso
comp

Conc

despliegue

Vista de Casos de Uso

Dirigida al Anlisis de Requisitos (lo que quiere hacer el

usuario)
Describe la funcionalidad del sistema, como la perciben
los actores externos
Dirige el desarrollo de las otras vistas
Define los objetivos finales del sistema
Permite validar el sistema
Actor externo:
Usuario
Otro sistema
Se plasma en diagramas
de Casos de Uso
de Actividad

Vista Lgica
Describe la funcionalidad interna
Dirigida a diseadores y desarrolladores
Define la estructura esttica
Clases, objetos y relaciones
Define las colaboraciones dinmicas

Mensajes y funciones
Propiedades adicionales
Persistencia y concurrencia
Interfaces y estructura interna de las clases

Vista Lgica
Se plasma en diagramas
Estticos
de Clases
de Objetos
Dinmicos
de Estado
de Secuencia
de Colaboracin
de Actividad

Vista de Componentes
Describe los mdulos del sistema y sus

dependencias
Dirigida a desarrolladores
Se plasma en diagramas
de Componentes

Vista de Concurrencia
Describe la divisin del sistema en procesos y procesadores
Dirigida a desarrolladores e integradores
Resuelve problemas de
uso eficiente de los recursos
ejecucin en paralelo (hilos)
comunicacin y sincronizacin de hilos
Se plasma en diagramas
dinmicos
de Componentes
de Despliegue

Vista de Despliegue
Muestra

la distribucin fsica del sistema

(ordenadores, dispositivos) y sus conexiones
Dirigida a desarrolladores, integradores y
probadores
Se plasma en
el diagrama de Despliegue
el mapa de asignacin de componentes a la
arquitectura fsica

Tipos de Diagramas
De Casos de Uso
Estticos
de Clases
de Objetos
Dinmicos
de Estado
de Secuencia
de Colaboracin
de Actividad
De Componentes
De Despliegue (deployment)

ANALISIS
Es un conjunto o disposicin de procedimientos o programas

relacionados de manera que juntos forman una sola unidad.

Un conjunto de hechos, principios y reglas clasificadas y dispuestas

de manera ordenada mostrando un plan lgico en la unin de las

partes.
Un mtodo, plan o procedimiento de clasificacin para hacer algo.

ANALISIS DE SISTEMAS
El anlisis de sistemas es el estudio de una aplicacin del sistema de
informacin y de empresa actual y la definicin de las necesidades y las

prioridades de usuario para conseguir una aplicacin nueva o mejorada

Funcin del ANALISIS

La funcin del Anlisis puede ser dar soporte a las actividades de

un negocio, o desarrollar un producto que pueda venderse para

generar beneficios.
1. Software.
2. Hardware,
3. Personal
4. Base de Datos
5. Documentacin
6. Procedimientos

Objetivos del Anlisis

1. Identificacin de las necesidades del Cliente.

Algunos autores suelen llamar a esta parte Anlisis de

Requisitos y lo dividen en cinco partes:

Reconocimiento del problema.

Evaluacin y Sntesis.
Modelado.
Especificacin.
Revisin.

Objetivos del Anlisis

2.

Estudio deViabilidad
Evale que conceptos tiene el cliente del sistema para establecer su
viabilidad.

Viabilidad econmica.
Viabilidad Tcnica.
Viabilidad Legal.

Objetivos del Anlisis

3. Anlisis Tcnico y econmico.
El Anlisis econmico incluye lo que se conoce

como, el anlisis de costos beneficios.

En el Anlisis Tcnico, el Analista evala los

principios tcnicos del Sistema.

Objetivos del Anlisis

4. Modelado de la arquitectura del Sistema

Todos los Sistemas basados en computadoras pueden

modelarse como transformacin de la informacin
empleando una arquitectura del tipo entrada y salida.

Objetivos del Anlisis

5. Especificaciones del Sistema

Describe la funcin y rendimiento de un Sistema

basado en computadoras y las dificultades que estarn
presente durante su desarrollo

DISEO DE SISTEMAS
El Diseo de Sistemas se define como el proceso de aplicar

ciertas tcnicas y principios con el propsito de definir un

dispositivo, un proceso o un Sistema, con suficientes detalles
como para permitir su interpretacin y realizacin fsica.

ETAPAS DEL DISEO

El Diseo de los datos.

El Diseo Arquitectnico.
El Diseo de la Interfaz.
El Diseo de procedimientos.

OTROS ELEMENTOS DEL DISEO

Diseo de Salida.

Diseo de Archivos.

Diseo de Interacciones con la Base de Datos.

Herramientas para el Diseo de Sistemas.

Herramientas de especificacin.

Herramientas para presentacin.

Herramientas para el desarrollo de Sistemas.

Herramientas para Ingeniera de Software.

Generadores de cdigos.

Herramientas para pruebas.

Proyecto de Sistema o Software.

Es el Proceso de gestin para la creacin de un

Sistema o software, la cual encierra un conjunto de

actividades, una de las cuales es la estimacin,

Objetivos de la Planificacin del

Proyecto.
El objetivo de la Planificacin del proyecto de Software

es proporcionar un marco de trabajo que permita al

gestor hacer estimaciones razonables de recursos costos
y planificacin temporal.

Actividades asociadas al proyecto

de software
1.

mbito del Software.

En esta etapa se evala la funcin y el rendimiento que se
asignaron al Software durante la Ingeniera del Sistema de
Computadora para establecer un mbito de proyecto que
no sea ambiguo, e incomprensible para directivos y
tcnicos

2.

Recursos

Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de

un proyecto de software solo puede ser determinado

despus de hacer una estimacin del esfuerzo de

desarrollo

Recursos o componentes de software

reutilizables.
Se debe estudiar la reutilizacin, esto es la creacin y la

reutilizacin de bloques de construccin de Software.

El Autor Bennatan sugiere cuatro categoras de recursos de

software que se deberan tener en cuenta a medida que se avanza

con la planificacin:
Componentes ya desarrollados.
Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.

 Recursos de entorno.

El entorno es donde se apoya el proyecto de Software,

llamado a menudo entorno de Ingeniera de Software,
incorpora Hardware y Software.

3.

ESTIMACION DEL PROYECTO DE SOFTWARE.

Para realizar estimaciones seguras de costos y esfuerzos

tienen varias opciones posibles:

Deje la estimacin para mas adelante
Base las estimaciones en proyectos similares ya

terminados.
Utilice tcnicas de descomposicin relativamente
sencillas.
Desarrolle un modelo emprico para l calculo de
costos y esfuerzos del Software.

DIFERENTES MODELOS DE
ESTIMACION.
Los Modelos Empricos

Donde los datos que soportan la mayora de los

modelos de estimacin obtienen una muestra
limitada de proyectos.

El Modelo COCOMO.
Barry Boehm, en su libro clsico sobre economa de la

Ingeniera del Software, introduce una jerarqua de modelos

de estimacin de Software con el nombre de COCOMO, por
su nombre en Ingles (Constructive, Cost, Model) modelo
constructivo de costos.

JERARQUA DE MODELOS DE
BOEHM
Modelo I.

El Modelo COCOMO bsico calcula el esfuerzo y

el costo del desarrollo de Software en funcin del tamao del programa,
expresado en las lneas estimadas.

Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del

desarrollo de software en funcin del tamao del programa y de un

conjunto de conductores de costos que incluyen la evaluacin subjetiva del
producto, del hardware, del personal y de los atributos del proyecto.

JERARQUA DE MODELOS DE
BOEHM
Modelo III.

El modelo COCOMO avanzado incorpora

todas las caractersticas de la versin intermedia y lleva a cabo una
evaluacin del impacto de los conductores de costos en cada caso
(anlisis, diseo, etc.) del proceso de ingeniera de Software.

Orientado a Objetos
En la programacin convencional los datos asumen

cualquier estructura y los procesos hacen de los datos

todo lo que el programador desee.
En el mundo orientado a objetos las estructuras de datos

se relacionan con los objetos y slo pueden ser utilizadas

mediante los mtodos diseados para ese tipo de objeto.

 En las tcnicas orientadas a objetos con herramientas

CASE, el diseador piensa en trminos de objetos y su

comportamiento.
Se construyen tipos de objetos a partir de tipos de

objetos ms sencillos. Una vez que los tipos de objetos

funcionan bien, el diseador los considera como cajas
negras de modo que nadie pueda ver su interior.

LA VERDADERA INGENIERIA DEL

SOFTWARE
El software se vende no cuando est libre de errores. sino

cuando stos aparecen con una frecuencia bastante baja.

Cuando un programa para hojas de clculo se sale de control
slo tiene un cdigo de 400.000 lneas. Muy pronto se
utilizara software con 50 millones de lneas de cdigo.

BENEICIOS DE LAS TECNICAS OO

Reutilizacin
Estabilidad
El

diseador piensa en trminos del

comportamiento de objetos y no en detalle de
bajo nivel.
Se construyen clases cada vez ms complejas
Un diseo ms rpido
Mantenimiento mas sencillo
Mejores Herramientas CASE

Problemas actuales en el desarrollo de

SW
El desarrollo de software es un negocio riesgoso.
Muchas historias de fracaso [Larman]
31 % Proyectos no se concluyen
53 % Rebasa en un 200% el costo estimado
Carencia de estndares.

Dificultad en la estimacin de costos.

Poca reutilizacin de cdigo.
Proceso no definido.

Problemas actuales en el desarrollo de

SW
Curva tpica de fallos de Software [Pressman].

ndice de fallos

Incremento del
ndice de fallos
por efectos
laterales

Curva Real

Cambio
Curva Ideal
Tiempo

Problemas actuales en el desarrollo de

SW
El impacto del cambio [Pressman]

Costos del cambio

60-100 x

1.5 -6
1x

Fase
Definicin

Desarrollo

Despus de la
entrega

Mitos del Software [Pressman]

Mitos de Gestin
Mito 1: Tenemos un libro lleno se estndares y

procedimientos para construir software. Mi gente ya

tiene todo para hacer lo que tiene que hacer.
Saben que existe?, lo usan?, es completo?. Experiencia es

tambin valiosa.

Mito 2: Tenemos todo lo que necesitamos, HW y SW de

ltima generacin.

El desarrollo implica mucho mas que herramientas.

Mitos de Gestin
Mito 3: Si fallamos en la planificacin, agregamos

ms programadores y asunto solucionado.

En general mas gente agrega ms caos no mas

eficiencia.

Mitos del Software [Pressman]

Mitos del cliente
Mito 1: Una declaracin general de los objetivos es

suficiente para comenzar a escribir programas, los

detalles se dejan para ms adelante.
Una mala definicin inicial es la principal causa de la prdida de

trabajo en SW.

Mito

2: Los requisitos del proyecto cambian

continuamente, pero estos pueden acomodarse fcil
puesto que el software el flexible.
El impacto del cambio vara segn en el momento que se

introduzca.

Mitos del cliente

Mito 3: No es necesario involucrarse en el diseo del

SW. Basta con dar las especificaciones y ver los resultados

finales.

Mitos del Software [Pressman]

Mitos del desarrollador
Mito 1: Una vez que escribimos el programa y hacemos

que funcione nuestro trabajo ya est hecho.

-Cuanto ms pronto se comience a escribir cdigo, ms se

tardar en terminarlo.

Mito 2: Hasta que no tengo el programa ejecutndose,

realmente no tengo forma de comprobar su calidad.

Existen mecanismos efectivos para ser aplicados desde el

principio del proyecto durante todas las fases.

Mitos del desarrollador

Mito 3: Lo nico que se entrega al terminar el proyecto es el

programa funcionando.
Un parte fundamental para la mantencin es la

documentacin.

ANLISIS Y DISEO OO
Es identificar el dominio del problema y su solucin lgica dentro de la

perspectiva de la Orientacin a Objetos.

Anlisis Orientado a Objeto: Identificar y definir los objetos

(conceptos) dentro del dominio del problema.

Diseo Orientado a Objetos: Definir los objetos lgicos de Software

(con atributos y mtodos) que sern programados el un lenguaje de

programacin idneo.

Diferencia con el modelo estructurado: El anlisis y diseo

estructurado son orientado a los procesos.

Caractersticas Importantes del AyD OO

1. Cambian nuestra forma de pensar sobre los sistemas.

2. Los usuarios finales y las personas de las empresas piensan de manera natural en

trminos de objetos, eventos y mecanismos de activacin ( triggers).

3. Los sistemas suelen construirse a partir de objetos ya existentes.

4. La complejidad de los objetos que podemos utilizar sigue en aumento puesto que

nuevos objetos se construyen a partir de otros.

5. El depsito CASE debe contener una creciente biblioteca de tipos de objetos,

algunos comprados y otros construidos en casa.

6. La creacin de sistemas con un funcionamiento correcto es ms fcil con las tcnicas

OO.
7. Las tcnicas 00 se ajustan de manera natural a la tecnologa CASE.

CICLO DE VIDA DEL SOFTWARE

Ciclo tradicional
Modelo en cascada
Anlisis (qu)
Diseo (cmo)
Codificacin (hacerlo)
Pruebas (funciona?)
Mantenimiento

CICLO DE VIDA DEL SW

PROCESO DE DESARROLLO
DE SOFTWARE:
Requisitos del usuario

Proceso de desarrollo
de software

Sistema de software

Proceso de desarrollo de software:

Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo

(quin hace qu, cundo y cmo).

Objetivos:
Asegurar la produccin de software de calidad dentro de plazos

y presupuestos predecibles.

PROCESO DE DESARROLLO
DE SOFTWARE
Planificacin

Ciclo de
desarrollo 1

Perfeccionar
plan

Construccin

Ciclo de
desarrollo 2

Anlisis

Aplicacin

...

Diseo

Construccin

De dos semanas a dos meses

Pruebas

PROCESO DE DESARROLLO
DE SOFTWARE
Ciclo de
desarrollo 1

Ciclo de
desarrollo 2

Ciclo de
desarrollo 3

Caso de uso A:
Versin
simplificada
-------------

Caso de uso A:
Versin
completa
-------------

Caso de uso B
------------------------Caso de uso C
-------------------------

...

PROCESO DE DESARROLLO
DE SOFTWARE
Planificacin

Ciclo de
desarrollo 1

Perfeccionar
plan

Construccin

Ciclo de
desarrollo 2

Anlisis

Aplicacin

...

Diseo

Construccin

De dos semanas a dos meses

Pruebas

ANLISIS OO
Algunas de las tareas a realizarse en la etapa de anlisis
(dominio del problema) son las siguientes:

Perfeccionar
plan

Definir los
requisitos
Crear el
glosario

Anlisis

Diseo

Definir los casos

esenciales de uso
Definir diag.
de secuencia

Construccin

Crear diagramas
de casos de uso
Definir los
contratos

Pruebas

Crear modelo
conceptual

DISEO OO
Algunas de las tareas a realizarse en la etapa de diseo
(dominio de la solucin) son las siguientes:

Perfeccionar
plan

Anlisis

Diseo

Definir casos
reales de uso

Definir reportes,
interfaz de usuario,
secuencia de pantallas

Definir diag.
de interaccin

Definir diagramas
diseo de clases

Construccin

Perfeccionar la
arquitectura
Definir esquema
base de datos

Pruebas

Lenguajes y herramientas OO
Lenguajes de programacin ms comunes que soportan la Orientacin a

Objetos:

Java
C ++
C#
Plataforma .net
Smalltalk

Herramientas case:
Rational Rose.
Poseidon (Profesional Edition)

Herramientas de modelado
Visio 2002
Umbrella (Open Source)
Poseidon (Comunity Edition)