Subido por shinigv2

Introducción a la Ingeniería de Software - Proyecto

Anuncio
Instituto Tecnológico de Culiacán
Proyecto Integrador de Ingeniería de Software
PRIMERA UNIDAD
Introducción
¿ Qué es Ingeniería de Software ?
• El establecimiento y uso de principios de ingeniería
robustos, orientados a obtener software económico que
sea fiable y funcione de manera eficiente sobre máquinas
reales. (Fritz Bauer 1969)
• La ingeniería de software es la aplicación de un enfoque
sistemático, disciplinado y cuantificable al desarrollo,
operación y mantenimiento del software.[IEEE93]
Introducción
Orientación a Objetos
Vivimos en un mundo de objetos. Estos objetos existen en la
naturaleza, en entidades hechas por el hombre, en los
negocios y en los productos que usamos. Pueden ser
clasificados, descritos, organizados, combinados,
manipulados y creados. Por eso no es sorprendente que se
proponga una visión orientada a objetos para la creación de
software de computadora, una abstracción que modela el
mundo de forma tal que nos ayuda a entenderlo y
gobernarlo mejor.
Introducción
Orientación a Objetos
El término orientado a objetos significa que el software se
organiza como una colección de objetos que contienen tanto
estructuras de datos como comportamiento.
Introducción
OBJETOS BICICLETA
Bicicleta
Se hace una
abstracción que
resulta en
Tam.del cuadro
Tam. De la rueda
marchas
material
Cambiar marcha()
mover()
reparar()
Introducción
Orientación a Objetos
El atractivo intuitivo de la orientación a objetos es que
proporciona conceptos y herramientas con las cuales se
modela y representa el mundo real tan fielmente como sea
posible. Estos conceptos y herramientas orientados a objetos
son tecnologías que permiten que los problemas del mundo
real sean expresados de modo fácil y natural.
Introducción
Programar es divertido,
Pero desarrollar software de calidad es difícil.
Entre las ideas espléndidas, los requisitos y un producto software
funcionando, hay mucho más que sólo programar:
Debemos realizar los planos (análisis y diseño) que definen cómo
solucionar el problema para obtener un producto software.
Definir el modelo arquitectónico
Aplicar la ingeniería de usabilidad.
Diseñar la Base de Datos
Etcétera.
Introducción
Análisis
¿Qué es el análisis?
Es el estudio de un dominio que da como resultado los
modelos que describen sus características estáticas y
dinámicas. Se centra en las cuestiones del “que” en lugar
del “como”.
ESPACIO DEL PROBLEMA
Pone énfasis en una investigación del problema y los
requisitos, en vez de ponerlos en una solución.
“Análisis” es un término amplio, es más adecuado calificarlo
como análisis de requisitos (un estudio de los requisitos) o
análisis de objetos (estudios de objetos del dominio)
¿Qué es el análisis orientado a objetos?
Es un método de análisis que examina los requisitos desde la
perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio del problema (Booch 1994)
Introducción
Análisis
Análisis Orientado a Objetos.
Se presta especial atención a encontrar y describir los
objetos en el dominio del problema. Ejemplos:
En el caso del sistema de renta de auto: Auto,
Cliente, Aseguradora, etc.
En el caso del sistema de la biblioteca: Libro,
Biblioteca, Socio
En el caso del sistema de vuelos: Pasajeros,
Aviones,…
Introducción
Diseño
Diseño:
Pone énfasis en una solución conceptual que satisface los requisitos, en
vez de ponerlo en la implementación.
Diseño orientado a objetos
Se presta especial atención a la definición de los objetos software y en
cómo colaboran para satisfacer los requisitos. Ejemplos:
ESPACIO DE LA SOLUCIÓN
Objeto LIBRO
Titulo
GetCap(int c)
Atributo
Operación
Una habilidad crítica en el desarrollo OO es la asignación inteligente de
responsabilidades a los objetos software
Introducción
Análisis y Diseño
Introducción
Análisis y Diseño
El análisis y diseño se han resumido en las freses:
• Hacer lo correcto
(análisis)
• Hacerlo correcto
(diseño)
Proceso de desarrollo de software
Un proceso de desarrollo de software es un
conjunto de actividades necesarias para
transformar los requerimientos del usuario
en un sistema de software.
Requerimientos
del usuario
Proceso de Desarrollo de
Software
Sistema Software
Proceso de desarrollo de software:
Motivación
Hoy en día la tendencia del software es hacia sistemas
más grandes y complejos. Esta tendencia también ha
sido influenciada por el extensivo uso del internet para
intercambiar todo tipo de información. Queremos
software que esté mejor adaptado a
nuestra
necesidades, aunque éste sea cada vez más complejo.
En resumen queremos cada vez más.
También lo queremos más rápido,
el tiempo para
construirlo es otro factor importante. Nuestra demanda de
software complejo y poderoso no concuerda con el cómo
será desarrollado dicho software. Hoy en día, la gente
desarrolla software usando métodos que fueron usados
desde hace 35 años.
Proceso de desarrollo de software
La comunidad de desarrollo de software
necesita una manera de controlar el trabajo.
Se necesita un proceso que integre las
muchas facetas del desarrollo de software.
Proceso de desarrollo de software
Necesitamos un método común, un proceso que:
Proporcione una guía para el orden de las
actividades del equipo
Dirija las tareas de los desarrolladores
individualmente y del equipo como un todo.
Especifique que artefactos deben ser desarrollados
Ofrezca criterios para monitorear y medir las
actividades y productos de un proyecto.
El marco del Proceso Unificado (UP, del
inglés Unified Process)
La presencia de un proceso bien definido y
bien manejado es un discriminador clave
entre un proyecto productivo y exitoso y uno
que no lo es.
El proceso unificado, se ha convertido en
un proceso de desarrollo de software de
gran éxito para la construcción de sistemas
orientados a objetos.
El marco del Proceso Unificado
El UP utiliza el lenguaje unificado para la creación
de modelos (UML). De hecho, UML es una parte
integral del Proceso Unificado, fueron desarrollados
a la par.
Los aspectos que realmente distinguen al Proceso
Unificado se capturan en tras frases claves:
■ Conducido por casos de uso
■ Centrado en la arquitectura
■ Iterativo e incremental
El PU conducido por casos de uso
Ejemplo: uso de un cajero automático.
El usuario inserta una tarjeta, responde a las
preguntas que emite el cajero en su pantalla y
recibe una suma de efectivo.
En respuesta a la tarjeta del usuario y sus
preguntas, el sistema realiza una secuencia de
acciones que provee al usuario un resultado de
valor, llamado retiro de fondos.
Una interacción de este tipo es un caso de uso.
El PU conducido por casos de uso
Un caso de uso es una pieza de funcionalidad
en el sistema que da al usuario un resultado de
valor.
Los casos de uso capturan los requerimientos
funcionales.
Todos los casos de uso juntos, construyen el
modelo de casos de uso el cual describe la
funcionalidad completa del sistema.
El PU conducido por casos de uso
Los casos de uso no solo son una herramienta para
especificar los requerimientos de un sistema;
también conducen su :
■
■
■
Diseño,
Implementación y,
Prueba.
Es decir,
los casos de uso conducen el proceso
de desarrollo.
El PU centrado en la arquitectura
El rol de la arquitectura del software es similar en
naturaleza al rol que juega la arquitectura en la
construcción de un edificio.
El edificio es observado desde varios puntos de
vista: estructura, servicios, electricidad, etc.
Similarmente, la arquitectura en un sistema de
software se describe con
diferentes vistas del
sistema que será construido.
El concepto de arquitectura del software abarca los
aspectos estáticos y dinámicos del sistema.
El PU centrado en la arquitectura
La arquitectura está influenciada por otros factores tales como:
la plataforma sobre la cual se va a ejecutar el sistema
bloques reusables disponibles
consideraciones de distribución
sistemas heredados y requerimientos no funcionales
Requerimientos no funcionales: en la ingeniería de software es
un requerimiento que especifica criterios que pueden usarse
para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los
requerimientos funcionales.
A un sistema se le puede pedir que muestre en tiempo real la
cantidad de datos de una base de datos: ése es un
requerimiento funcional. En cuánto tiempo debería el sistema
actualizar su verificación interna de cantidad de datos es, en
cambio, un requerimiento no funcional.
El PU centrado en la arquitectura
¿Cómo se relacionan los casos de uso y la
arquitectura?
Cada producto tiene función y forma. Uno o el
otro no es suficiente. Estas dos fuerzas deben
estar balanceadas par obtener un producto
exitoso. En este caso la función corresponde a
los casos de uso y la forma a la arquitectura.
Se necesita, por lo tanto, la interacción entre los
casos de uso y la arquitectura.
El PU centrado en la arquitectura
El arquitecto moldea el sistema en una forma. Esa
forma, la arquitectura, debe ser diseñada de
manera tal, que permita al sistema evolucionar, no
solamente a través de su desarrollo inicial, sino a
través de futuras generaciones.
Para encontrar tal forma, los arquitectos deben
tener un entendimiento general de las funciones
claves, esto es,
los casos de uso claves del
sistema.
El PU es iterativo e incremental
Bajo este enfoque, el desarrollo se organiza en una
serie de mini-proyectos cortos, de duración fija (por
ejemplo, cuatro semanas) llamados iteraciones.
El resultado de cada uno es un sistema que puede
ser probado, integrado y ejecutado.
Cada iteración incluye sus propias actividades de
análisis de requisitos, diseño implementación y
pruebas.
El PU es iterativo e incremental
El ciclo de vida iterativo se basa en la ampliación y
refinamiento sucesivos del sistema mediante múltiples
iteraciones, con retroalimentación cíclica y adaptación
como elementos principales que nos conducen hacia un
sistema adecuado.
El sistema crece incrementalmente a lo largo del tiempo,
iteración tras iteración, por eso se dice que es iterativo e
incremental.
Proceso Iterativo Incremental: se dice que un proceso es
iterativo incremental cuando en cada iteración de sus
pasos se alcanza una mayor cercanía con los objetivos
finales. Esto es, se añade algo nuevo de valor en cada
iteración.
Requisitos
Requisitos
Diseño
Diseño
Implementación &
Prueba & Integración & más diseño
TIEMPO
Integración final &
Pruebas de sistema
Implementación &
Prueba & Integración & más diseño
La retroalimentación de la iteración N nos lle
va a refinar y
adaptar los requisitos y diseño
de la iteración N+1.
Integración final &
Pruebas de sistema
4 semanas (por ejemplo)
Se fija la duración de
Las iteraciones
El sistema crece
de manera incremental
El PU es iterativo e incremental
El resultado de cada iteración es un sistema
ejecutable, pero incompleto; no está
preparado par ser puesto en producción. El
sistema estaría listo después de muchas
iteraciones por ejemplo, 10 o 15.
El PU es iterativo e incremental
La salida de una iteración no es un
prototipo experimental o desechable, y el
desarrollo iterativo no es prototipado.
Más bien, la salida es un subconjunto con
calidad de producción del sistema final.
El PU es iterativo e incremental
Los desarrolladores basan la selección de lo
que será desarrollado en cada iteración
tomando en cuenta dos factores:
Primero:
La iteración trata con un grupo
de casos de uso que juntos amplían la
utilidad del producto, según lo desarrollado
hasta ahora.
Segundo: La iteración se ocupa de los
riesgos más importantes.
Beneficios del desarrollo iterativo
Mitigación tan pronto como sea posible de los riesgos
altos (técnicos, requisitos, objetivos, usabilidad y
demás).
Progreso visible en las primeras etapas.
Una temprana retroalimentación, compromiso de los
usuarios y adaptación que nos lleva a un sistema
refinado que se ajusta más a las necesidades reales del
personal involucrado.
Gestión de la complejidad, el equipo no se ve abrumado
por la “parálisis del análisis” o pasos muy largos y
complejos.
El conocimiento adquirido en una iteración se puede
utilizar metódicamente para mejorar el propio proceso
de desarrollo, iteración tras iteración.
EN RESUMEN
Los conceptos:
dirigido por casos de uso,
centrado en la arquitectura y
el desarrollo iterativo e incremental,
son igualmente importantes. La arquitectura
proporciona la estructura en la cual se guía el
trabajo en las iteraciones, mientras que los casos
de uso definen las metas y conducen el trabajo de
cada iteración. El quitar una de estas tres ideas
reduciría severamente el valor del proceso
unificado.
Las Fases del PU
Un proyecto con el PU organiza el trabajo y las
iteraciones en 4 fases fundamentales:
Inicio: visión aproximada, análisis del negocio,
estimaciones imprecisas de plazos y costos. Se define
la viabilidad del proyecto.
Elaboración: visión refinada, implementación iterativa
del núcleo central de la arquitectura, resolución de los
riesgos altos, identificación de más requisitos y
alcance, estimaciones más realistas.
Construcción: implementación iterativa del resto de
requisitos de menor riesgo y elementos más fáciles,
preparación para el despliegue.
Las Fases del PU
Transición: pruebas beta, despliegue.
La fase de inicio NO es una fase de requisitos; sino una
especie de fase de viabilidad, donde se lleva a cabo solo
el estudio suficiente para decidir si continuar o no.
La fase de elaboración NO es la fase de requisitos o de
diseño, sino una fase donde se implementa de manera
iterativa, la arquitectura, que constituye el núcleo central
y se mitigan las cuestiones de alto riesgo.
La vida del PU
Cada fase esta subdividida en iteraciones
Inicio
Iter.
#1
Elaboración
Construcción
Iter.
# 2..
Transición
Iter.
#n-1
versiones
Un ciclo con sus fases y sus iteraciones
Iter.
#n…
The UP Disciplines
Phases
Process Disciplines
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Disciplines
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iterations
Iter.
#m
Iter.
#m+1
Disciplinas del PU (flujos de trabajo)
Informalmente una disciplina es un conjunto de
actividades (y artefactos relacionados) en un área
determinada como las actividades en el análisis de
requisitos.
En el PU, un artefacto es el término general para
cualquier producto del trabajo: código, gráficos
Web, esquema de base de datos, documento de
texto, diagramas, modelos, etcétera.
Nos centraremos en 3 disciplinas: modelado del
negocio, requisitos y diseño.
Disciplinas del PU (flujos de trabajo)
Modelado del negocio
Una vez que los miembros del equipo de requisitos se
han familiarizado con el lenguaje, el siguiente paso es:
■
construir el modelo del negocio inicial, que es una descripción de
los procesos de una empresa (ejemplo: un banco incluye aceptar
depósitos de los clientes, conceder préstamos a los clientes y hacer
inversiones)
La razón para construir un modelo de negocios es que
proporciones una comprensión de los negocios del
cliente como un todo,
■
con este conocimiento es posible aconsejar al cliente respecto de
qué porciones del sistema de información computarizar.
Disciplinas del PU
modelado del negocio
Ejemplo: los procesos de negocios de una empresa de
servicios de banquetes incluyen:
comprar los ingredientes,
preparar los alimentos,
servir la comida
El proceso comprar ingredientes refinado
■
El encargado del servicio de banquetes ordena los ingredientes a
un mayorista
El mayorista entrega los ingredientes al encargado del servicios de
banquetes
El mayorista envía una factura al encargado de banquetes
El encargado de banquetes paga la factura
Disciplinas del PU
modelado del negocio
Pueden usarse una serie de técnicas para
obtener información necesaria para
construir el modelo de negocios,
principalmente la entrevista.
Disciplinas del PU
Requisitos: análisis de requisitos para la aplicación, escritura de
casos de uso e identificación de requisitos no funcionales.
El objetivo de esta disciplina es asegurar que los desarrolladores
construyan el sistema de información correcto,
Esto se logra al describir el sistema de información objetivo de una
manera suficientemente clara y precisa como para que los dos
involucrados principales (cliente y desarrolladores) puedan ponerse
de acuerdo en lo que debe y no debe hacer el sistema de
información.
Con el fin de lograr esto, lo requisitos tienen que ser comprendidos
por el cliente. Una manera de lograrlo es usar el PU, porque sus
diversos modelos ayudan al cliente a obtener la comprensión
detallada necesaria de lo que se va a desarrollar.
Disciplinas del PU
Análisis
El propósito de esta disciplina es examinar y refinar los
requisitos. Al hacerlo se logra la comprensión detallada de
los requisitos que deben tener para desarrollar
correctamente un sistema de información y darle
mantenimiento con facilidad.
¿por qué tener la disciplina de análisis?
El punto clave es que los artefactos de la disciplina de
requisitos deben expresarse en el lenguaje del cliente, es
decir en un idioma natural (español, inglés, armenio,…), pero
todos los lenguajes naturales de alguna manera son
imprecisos y conducen a malas interpretaciones.
Disciplinas del PU
Análisis
Ejemplo: se tiene el siguiente requisito
“Un registro de partes y un registro de las planta de fabricación de las
mismas se buscan en una base de datos. Si el registro contiene la
letra A justo después de la Q, entonces se calcula el costo de
transportar esa parte a la planta.”
A primera vista ese requisito parece perfectamente claro. Pero ¿a qué
se refiere el “registro” (registro de partes o registro de plantas).
Con la disciplina de requisitos se formula en el lenguaje del cliente y la
disciplina de análisis es un lenguaje más preciso que asegurará que
las disciplinas de diseño e implementación se llevarán a cabo
correctamente.
Disciplinas del PU
Diseño
En esta disciplina se refina los artefactos del
análisis hasta que el material esté en una forma en
que los programadores puedan implementar.
Además una serie de requisitos necesitan
familiarizarse en este momento, incluyendo la
elección del lenguaje de programación, así como la
reutilización y los problemas de portabilidad.
Disciplinas del PU
Implementación
El objetivo de esta disciplina es instaurar el sistema
de información deseado en el lenguaje deseado.
En cuanto el componente se ha codificado, el
programador lo prueba, una vez que el
programador está seguro de que el componente es
correcto, se pasa al grupo de aseguramiento de la
calidad para una prueba posterior.
Disciplinas del PU
Pruebas
Esta disciplina es responsabilidad del grupo de aseguramiento de la
calidad. Cada componente que se ha terminado se prueba, a esto se
le llama prueba de unidad.
Al final de cada iteración se realiza la prueba de integración. Aquí los
componentes que se han completado y a los cuales se les han
aplicado las prueba de unidad, se compilan y se ligan y luego se
prueban con varios casos de prueba.
Cuando el producto parece estar completo, se prueba en conjunto: a
esto se llama prueba de producto.
disciplinas y modelos
en el PU
requerimientos
Modelo de
casos de uso
Análisis
Modelo de
análisis
Diseño
Modelo de
diseño
Modelo de
distribución
Implementación
Modelo de
implementación
Prueba
Modelo de
pruebas
Buenas prácticas del PU adicionales
Lo fundamental para apreciar y aplicar el PU es el desarrollo iterativo
(fijando iteraciones cortas) y adaptable.
Uso de tecnologías de objetos (A/DOO Y POO).
Abordar cuestiones de alto riesgo en las primeras iteraciones.
Involucrar continuamente a los usuarios para evaluación,
retroalimentación y requisitos.
Construir en las primeras iteraciones una arquitectura que constituya
un núcleo central consistente.
Verificar la calidad continuamente; pruebas muy pronto, con
frecuencia y realistas.
Aplicar casos de uso.
Modelar software visualmente (UML).
Gestionar los requisitos con cuidado.
Manejar peticiones de cambio y gestión de configuraciones.
Descargar