Upload
erick-ramos-c
View
4
Download
0
Embed Size (px)
DESCRIPTION
Introduccion a la Ingenieria de Software
Citation preview
Ing. Juan Carlos Carreño Gamarra
IS 453 Ingeniería de Software
INTRODUCCIÓN
La primera referencia que describe ampliamente el
procedimiento de la Ingeniería de Sistemas fue publicada
en 1950 por Melvin J. Kelly.
En opinión de Arthur D. Hall, "la función de Ingeniería de
Sistemas se había practicado durante muchos años en las
Organizaciones”.
¿Qué es ingeniería de SW?
“La aplicación de un enfoque sistemático,
disciplinado y cuantificable hacia el desarrollo,
operación y mantenimiento del Software, es
decir, la aplicación de la ingeniería al Software”
[IEEE]
Niveles de la Ingeniería de Software
Procesos de desarrollo de SW.
Ciclo de vida: Sucesión 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
•Comprender la naturaleza del dominio.
•Especificación de los requisitos
•Estructura de datos
•Arquitectura de SW
•Representaciones de la Interfaz
•Algoritmos
•Construcción del SW. En base al diseño
•Prueba de procesos lógicos internos.
•Pruebas funcionales
Análisis Prueba Diseño Código
Procesos de desarrollo de SW.
Cascada
Análisis
Diseño
Codificación y pruebas unitarias
Integración del sistema
Operación y mantenimiento
Procesos de desarrollo de SW.
Prototipos
Mecanismo de especificación de requisitos.
Cuando solo se tienen requisitos muy generales por parte del cliente, es práctico utilizar este paradigma.
Sistemas muy complejos de entender.
Prototipear consiste en construir una versión inicial de un producto, en la cual se describe la interacción hombre-máquina 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 versión final es el producto ya construido.
Desechable: Se usa sola para la captación de requerimientos y
funcionalidad.
Procesos de desarrollo de SW.
Modelos evolutivos
Modelos evolutivos son iterativos.
Permite al equipo de desarrollo generar versiones mas
completas del software.
Tipos de modelos:
Incremental
Espiral
Ensamblaje de componentes
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 versión
Desarrollo Segunda versión
Requerimientos
Desarrollo Primera versión
Desarrollo Segunda versión
Requerimientos
Modelos evolutivos: Espiral
Espiral se divide en 6 regiones, llamadas
regiones de tarea.
1. Comunicación con el cliente
2. Planificación
3. Análisis de riesgo
4. Ingeniería
5. Construcción y adaptación
6. Evaluación del cliente
Procesos de desarrollo de SW.
Modelos evolutivos: Espiral
Procesos de desarrollo de SW.
Modelos evolutivos: Componentes
Más adecuado para la construcción de SW orientado a
objeto.
Orientación a objetos encapsula datos y métodos.
Centrado a la construcción de componentes que no están
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 prácticas.
Consiste en un conjunto de templates, blueprints
y documentación que cubren todo el proceso de
desarrollo.
Metodologías de Análisis y Diseño
(OOA/OOD)
Booch (OOAD)
Rumbaugh (OMT)
Jacobson (OOSE)
UML (Unified Modelling Language)
Lenguaje visual
Unión de los tres anteriores
Estándar internacional (OMG)
Versión actual: 2.0
UP (Unified Process)
Metodología de diseño iterativo
Basada en casos de uso
Incorpora UML de forma natural
OOAD (Booch)
Tipos de relaciones
Herencia o Generalización
Agregación o Composición
Asociación
Metaclase
Instanciación (plantillas)
Cliente-Servidor (acceso)
OOAD (Grady Booch)
Clases ordinarias
Metaclases
Categorías de clases
Clases parametrizadas (plantillas)
Clases instanciadas (plantillas)
Utilidades de clase: subprogramas libres y clases estáticas
Tipos de clases
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, información, semántica, extensiones y
adaptaciones
VISTAS
Vista de Casos de Uso
Funcionalidad externa del sistema
Vista Lógica
Estructura estática y conducta dinámica del sistema
Vista de Componentes (software)
Organización de las componentes
Vista de Concurrencia
Comunicaciones y sincronización
Vista de Despliegue (deployment)
Arquitectura física
Las Vistas en UML
Casos uso
lógica
comp
despliegue
Conc
Vista de Casos de Uso
Dirigida al Análisis 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 Lógica
Describe la funcionalidad interna
Dirigida a diseñadores y desarrolladores
Define la estructura estática
Clases, objetos y relaciones
Define las colaboraciones dinámicas
Mensajes y funciones
Propiedades adicionales
Persistencia y concurrencia
Interfaces y estructura interna de las clases
Vista Lógica
Se plasma en diagramas
Estáticos
de Clases
de Objetos
Dinámicos
de Estado
de Secuencia
de Colaboración
de Actividad
Vista de Componentes
Describe los módulos del sistema y sus
dependencias
Dirigida a desarrolladores
Se plasma en diagramas
de Componentes
Vista de Concurrencia
Describe la división del sistema en procesos y procesadores
Dirigida a desarrolladores e integradores
Resuelve problemas de
uso eficiente de los recursos
ejecución en paralelo (hilos)
comunicación y sincronización de hilos
Se plasma en diagramas
dinámicos
de Componentes
de Despliegue
Vista de Despliegue
Muestra la distribución física del sistema
(ordenadores, dispositivos) y sus conexiones
Dirigida a desarrolladores, integradores y
probadores
Se plasma en
el diagrama de Despliegue
el mapa de asignación de componentes a la
arquitectura física
Tipos de Diagramas
De Casos de Uso
Estáticos
de Clases
de Objetos
Dinámicos
de Estado
de Secuencia
de Colaboración
de Actividad
De Componentes
De Despliegue (deployment)
ANALISIS Es un conjunto o disposición 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 lógico en la unión de las
partes.
Un método, plan o procedimiento de clasificación para hacer algo.
ANALISIS DE SISTEMAS
El análisis de sistemas es el estudio de una aplicación del sistema de
información y de empresa actual y la definición de las necesidades y las
prioridades de usuario para conseguir una aplicación nueva o mejorada
Función del ANALISIS La función del Análisis 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. Documentación
6. Procedimientos
Objetivos del Análisis
1. Identificación de las necesidades del Cliente.
Algunos autores suelen llamar a esta parte ¨ Análisis de
Requisitos ¨ y lo dividen en cinco partes:
Reconocimiento del problema.
Evaluación y Síntesis.
Modelado.
Especificación.
Revisión.
Objetivos del Análisis
2. Estudio de Viabilidad
Evalúe que conceptos tiene el cliente del sistema para establecer su
viabilidad.
Viabilidad económica.
Viabilidad Técnica.
Viabilidad Legal.
Objetivos del Análisis
3. Análisis Técnico y económico.
El Análisis económico incluye lo que se conoce
como, el análisis de costos – beneficios.
En el Análisis Técnico, el Analista evalúa los
principios técnicos del Sistema.
Objetivos del Análisis
4. Modelado de la arquitectura del Sistema
Todos los Sistemas basados en computadoras pueden
modelarse como transformación de la información
empleando una arquitectura del tipo entrada y salida.
Objetivos del Análisis
5. Especificaciones del Sistema
Describe la función y rendimiento de un Sistema
basado en computadoras y las dificultades que estarán
presente durante su desarrollo
DISEÑO DE SISTEMAS
El Diseño de Sistemas se define como el proceso de aplicar
ciertas técnicas y principios con el propósito de definir un
dispositivo, un proceso o un Sistema, con suficientes detalles
como para permitir su interpretación y realización física.
ETAPAS DEL DISEÑO
El Diseño de los datos.
El Diseño Arquitectónico.
El Diseño de la Interfaz.
El Diseño de procedimientos.
OTROS ELEMENTOS DEL DISEÑO
Diseño de Salida.
Diseño de Archivos.
Diseño de Interacciones con la Base de Datos.
Herramientas para el Diseño de Sistemas.
Herramientas de especificación.
Herramientas para presentación.
Herramientas para el desarrollo de Sistemas.
Herramientas para Ingeniería de Software.
Generadores de códigos.
Herramientas para pruebas.
Proyecto de Sistema o Software.
Es el Proceso de gestión para la creación de un
Sistema o software, la cual encierra un conjunto de
actividades, una de las cuales es la estimación,
Objetivos de la Planificación del
Proyecto.
El objetivo de la Planificación del proyecto de Software
es proporcionar un marco de trabajo que permita al
gestor hacer estimaciones razonables de recursos costos
y planificación temporal.
Actividades asociadas al proyecto
de software
1. Ámbito del Software.
En esta etapa se evalúa la función y el rendimiento que se
asignaron al Software durante la Ingeniería del Sistema de
Computadora para establecer un ámbito de proyecto que
no sea ambiguo, e incomprensible para directivos y
técnicos
2. Recursos
Recursos Humanos.
La Cantidad de personas requeridas para el desarrollo de
un proyecto de software solo puede ser determinado
después de hacer una estimación del esfuerzo de
desarrollo
Recursos o componentes de software
reutilizables.
Se debe estudiar la reutilización, esto es la creación y la
reutilización de bloques de construcción de Software.
El Autor Bennatan sugiere cuatro categorías de recursos de
software que se deberían tener en cuenta a medida que se avanza
con la planificación:
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 Ingeniería 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 estimación para mas adelante
Base las estimaciones en proyectos similares ya
terminados.
Utilice técnicas de descomposición relativamente
sencillas.
Desarrolle un modelo empírico para él calculo de
costos y esfuerzos del Software.
DIFERENTES MODELOS DE
ESTIMACION.
Los Modelos Empíricos
Donde los datos que soportan la mayoría de los
modelos de estimación obtienen una muestra
limitada de proyectos.
El Modelo COCOMO. Barry Boehm, en su libro clásico sobre economía de la
Ingeniería del Software, introduce una jerarquía de modelos
de estimación de Software con el nombre de COCOMO, por
su nombre en Ingles (Constructive, Cost, Model) modelo
constructivo de costos.
JERARQUÍA DE MODELOS DE
BOEHM
Modelo I. El Modelo COCOMO básico calcula el esfuerzo y
el costo del desarrollo de Software en función del tamaño del programa,
expresado en las líneas estimadas.
Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del
desarrollo de software en función del tamaño del programa y de un
conjunto de conductores de costos que incluyen la evaluación subjetiva del
producto, del hardware, del personal y de los atributos del proyecto.
JERARQUÍA DE MODELOS DE
BOEHM
Modelo III. El modelo COCOMO avanzado incorpora
todas las características de la versión intermedia y lleva a cabo una
evaluación del impacto de los conductores de costos en cada caso
(análisis, diseño, etc.) del proceso de ingeniería de Software.
Orientado a Objetos
En la programación 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 sólo pueden ser utilizadas
mediante los métodos diseñados para ese tipo de objeto.
En las técnicas orientadas a objetos con herramientas
CASE, el diseñador piensa en términos de objetos y su
comportamiento.
Se construyen tipos de objetos a partir de tipos de
objetos más sencillos. Una vez que los tipos de objetos
funcionan bien, el diseñador 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 cálculo se sale de control
sólo tiene un código de 400.000 líneas. Muy pronto se
utilizara software con 50 millones de líneas de código.
BENEICIOS DE LAS TECNICAS OO Reutilización
Estabilidad
El diseñador piensa en términos del comportamiento de objetos y no en detalle de bajo nivel.
Se construyen clases cada vez más complejas
Un diseño más rápido
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 estándares.
Dificultad en la estimación de costos.
Poca reutilización de código.
Proceso no definido.
Problemas actuales en el desarrollo de
SW
Curva típica de fallos de Software [Pressman].
Ín
dic
e d
e f
all
os
Tiempo
Cambio
Curva Real
Curva Ideal
Incremento del
índice de fallos
por efectos
laterales
Problemas actuales en el desarrollo de
SW
El impacto del cambio [Pressman]
Co
sto
s d
el
ca
mb
io
Fase
Definición Desarrollo Después de la
entrega
1 x
1.5 -6
60-100 x
Mitos del Software [Pressman]
Mitos de Gestión
Mito 1: Tenemos un libro lleno se estándares 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
también valiosa.
Mito 2: Tenemos todo lo que necesitamos, HW y SW de última generación. El desarrollo implica mucho mas que herramientas.
Mitos de Gestión
Mito 3: Si fallamos en la planificación, agregamos
más programadores y asunto solucionado.
En general mas gente agrega más caos no mas
eficiencia.
Mitos del Software [Pressman]
Mitos del cliente
Mito 1: Una declaración general de los objetivos es suficiente para comenzar a escribir programas, los detalles se dejan para más adelante. Una mala definición inicial es la principal causa de la pérdida de
trabajo en SW.
Mito 2: Los requisitos del proyecto cambian continuamente, pero estos pueden acomodarse fácil puesto que el software el flexible. El impacto del cambio varía según en el momento que se
introduzca.
Mitos del cliente
Mito 3: No es necesario involucrarse en el diseño 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 más pronto se comience a escribir código, más se tardará en terminarlo.
Mito 2: Hasta que no tengo el programa ejecutándose, 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 mantención es la
documentación.
ANÁLISIS Y DISEÑO OO
Es identificar el dominio del problema y su solución lógica dentro de la perspectiva de la Orientación a Objetos.
Análisis Orientado a Objeto: Identificar y definir los objetos (conceptos) dentro del dominio del problema.
Diseño Orientado a Objetos: Definir los objetos lógicos de Software (con atributos y métodos) que serán programados el un lenguaje de programación idóneo.
Diferencia con el modelo estructurado: El análisis y diseño estructurado son orientado a los procesos.
Características 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 términos de objetos, eventos y mecanismos de activación ( 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 depósito CASE debe contener una creciente biblioteca de tipos de objetos, algunos comprados y otros construidos en casa.
6. La creación de sistemas con un funcionamiento correcto es más fácil con las técnicas OO.
7. Las técnicas 00 se ajustan de manera natural a la tecnología CASE.
CICLO DE VIDA DEL SOFTWARE
Ciclo tradicional
Modelo en cascada
Análisis (qué)
Diseño (cómo)
Codificación (hacerlo)
Pruebas (¿funciona?)
Mantenimiento
CICLO DE VIDA DEL SW
Requisitos del usuario Sistema de software Proceso de desarrollo de software
Proceso de desarrollo de software: Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo
(quién hace qué, cuándo y cómo).
Objetivos: Asegurar la producción de software de calidad dentro de plazos
y presupuestos predecibles.
PROCESO DE DESARROLLO
DE SOFTWARE:
PROCESO DE DESARROLLO
DE SOFTWARE Planificación Construcción Aplicación
Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2
Perfeccionar
plan Análisis Diseño Construcción Pruebas
De dos semanas a dos meses
PROCESO DE DESARROLLO
DE SOFTWARE
Ciclo de Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2 desarrollo 3
Caso de uso A:
Versión
simplificada
-------
-------
Caso de uso A:
Versión
completa
-------
-------
Caso de uso B
-------
-------
-------
-------
Caso de uso C
-------
-------
-------
-------
PROCESO DE DESARROLLO
DE SOFTWARE
Planificación Construcción Aplicación
Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2
Perfeccionar
plan Análisis Diseño Construcción Pruebas
De dos semanas a dos meses
ANÁLISIS OO
Perfeccionar
plan Análisis Diseño Construcción Pruebas
Definir los
requisitos
Definir los casos
esenciales de uso
Crear diagramas
de casos de uso
Crear modelo
conceptual
Crear el
glosario
Definir diag.
de secuencia
Definir los
contratos
Algunas de las tareas a realizarse en la etapa de análisis
(dominio del problema) son las siguientes:
DISEÑO OO
Perfeccionar
plan Análisis Diseño Construcción Pruebas
Definir casos
reales de uso
Definir reportes,
interfaz de usuario,
secuencia de pantallas
Perfeccionar la
arquitectura
Definir diag.
de interacción Definir diagramas
diseño de clases
Definir esquema
base de datos
Algunas de las tareas a realizarse en la etapa de diseño
(dominio de la solución) son las siguientes:
Lenguajes y herramientas OO Lenguajes de programación más comunes que soportan la Orientación 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)