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)
