Ingeniería de software

Ingeniería de
Software
MARTIN DIAZ.

Objetivo del curso
Comprender el proceso de desarrollo de software a partir de la
conceptualización de un modelo de desarrollo de software estandarizado
tipo RUP (Rational Unified Process) donde el estudiante aprenda a
construir y mantener Sistemas de Información, basado en los principios
que brinda la Ingeniería de Software, como marco de referencia en el
proceso de construcción durante las fases de planeación, análisis, diseño y
desarrollo de Proyectos de software de calidad.

Textos Guías
• Ingeniería del Software: Un enfoque práctico. Roger S. Pressman . Quinta Edición. 2001
• Proceso Unificado de Modelado Ed. Pearson.Software Engineering, Shari Lawrence Pfleeger
• El lenguaje Unificado de Modelado versión 2.3
 11.2 OTRAS REFERENCIAS
• Ingeniería de Software. Ian Sommerville. Sexta Edición. 2001.
• Software Engineering: theory and Prectice. Pfleeger, Shari Lawrence. 1998.
• Software Engineering and testing, BB. Agarval, S.P. Tayal, M. Gupta, series Computer
Science, 2009
 DIRECCIONES DE INTERES
 www.uml.org
 www.omg.org
 www.sparsystems.com
 http://www.sei.cmu.edu

Evaluación
 Todas las evaluaciones son en pareja:
 Parcial 1: Examen en papel
 Parcial 2: Proyecto, Sustentación
 Parcial Final: Proyecto, Sustentación
 Notas Formativas:
 2 talleres
 1 exposición

Herramientas de trabajo
 Gestión proyecto:
 dotproject, Microsoft project, pert-cpm, formulación de proyectos,
pmbook, pmi, estándares
 Ingeniería de Software (desarrollo)
 Herramienta case (EA. http://www.sparxsystems.com/
 Lenguaje Unificado de Modelado UML
 Entorno de desarrollo preferiblemente JAVA, JSP, PHP
 Base de Datos MYSQL, ORACLE, SQL SERVER-2008 (EXPRESS)
 Documentación importante, generada por la herramienta
 Objeto de estudio (sistemas de información organizacional)

Ingeniería de Software: Definición
 La Ingeniería del software es una disciplina que permite la aplicación de un enfoque
sistemático, ordenado y cuantificable para el desarrollo, operación y mantenimiento de
software.
 La ingeniería del software es la aplicación de métodos y conocimiento científico para crear
soluciones prácticas para el diseño, construcción, operación y mantenimiento de software.
 La ingeniería del software es una disciplina que tiene por objetivo la producción de
software libre de defectos que satisfacen las necesidades de usuarios y que son
entregados a tiempo y dentro de un presupuesto.
 La calidad del producto es clave.(objetivos, tiempo, presupuesto, satisface cliente)

La naturaleza del software
 El software se desarrolla o modifica con intelecto; no se manufactura en el
sentido clásico.
 El software no se “desgasta”
 Aunque la industria se mueve hacia la construcción basada en
componentes, la mayor parte del software se construye para un uso
individualizado.

La naturaleza del software
1. ¿Por qué se requiere tanto tiempo para terminar el software?
2. ¿Por qué son tan altos los costos de desarrollo?
3. ¿Por qué no podemos detectar todos los errores antes de entregar el
software a nuestros clientes?
4. ¿Por qué dedicamos tanto tiempo y esfuerzo a mantener los programas
existentes?
5. ¿Por qué seguimos con dificultades para medir el avance mientras se
desarrolla y mantiene el software?

Aplicaciones de Software
 Software de Sistemas: compiladores, editores y herramientas para administrar archivos.
 Software de aplicación: programas aislados que resuelven una necesidad específica de
negocios.
 Software de ingeniería y ciencias: Algoritmos para resolver problemas matemáticos
también llamados devoradores de números.
 Software incrustado: Software diseñado para un hardware especifico-
 Aplicaciones web.
 Software de inteligencia artificial: hace uso de algoritmos no numéricos para resolver
problemas complejos que no son fáciles de tratar computacionalmente o con el análisis
directo

Software Heredados
 ¿Qué hago si encuentro un sistema heredado de mala calidad?
 ¿Qué tipos de cambios se hacen a los sistemas heredados?
 El software debe adaptarse para que cumpla las necesidades de los nuevos
ambientes del cómputo y de la tecnología.
 El software debe ser mejorado para implementar nuevos requerimientos del
negocio.
 El software debe ampliarse para que sea operable con otros sistemas o bases
de datos modernos.
 La arquitectura del software debe rediseñarse para hacerla viable dentro de un
ambiente de redes

La practica del software
 Entender el problema.
 ¿Quiénes tienen que ver con la solución del problema? Es decir, ¿quiénes son los
participantes?
 ¿Cuáles son las incógnitas? ¿Cuáles datos, funciones y características se requieren para
resolver el problema en forma apropiada?
 ¿Puede fraccionarse el problema? ¿Es posible representarlo con problemas más pequeños
que sean más fáciles de entender?
 ¿Es posible representar gráficamente el problema? ¿Puede crearse un modelo de análisis?

 Planear la solución.
 ¿Ha visto antes problemas similares? ¿Hay patrones reconocibles en una solución potencial?
 ¿Hay algún software existente que implemente los datos, funciones y características que se
requieren?
 ¿Ha resuelto un problema similar? Si es así, ¿son reutilizables los elementos de la solución?
 ¿Pueden definirse problemas más pequeños? Si así fuera, ¿hay soluciones evidentes para
éstos?

 Ejecutar el plan
 ¿Se ajusta la solución al plan? ¿El código fuente puede apegarse al modelo del diseño?
 ¿Es probable que cada parte componente de la solución sea correcta? ¿El diseño y código se
han revisado o, mejor aún, se han hecho pruebas respecto de la corrección del algoritmo?

 Examinar el resultado
 ¿Puede probarse cada parte componente de la solución? ¿Se ha implementado una estrategia
razonable para hacer pruebas?
 ¿La solución produce resultados que se apegan a los datos, funciones y características que se
requieren? ¿El software se ha validado contra todos los requerimientos de los participantes?

Principios generales
 Primer principio: La razón de que exista todo.
 Segundo principio: MSE (Mantenlo sencillo, estúpido…)
 Tercer principio: Mantener la visión
 Cuarto principio: Otros consumirán lo que usted produce
 Quinto principio: Ábrase al futuro.
 Sexto principio: Planee por anticipado la reutilización.
 Séptimo principio: ¡Piense!

MITOS DEL SOFTWARE
 Tenemos un libro lleno de estándares y procedimientos para elaborar software.
¿No le dará a mi personal todo lo que necesita saber?
 Si nos atrasamos, podemos agregar más programadores y ponernos al
corriente
 Si decido subcontratar el proyecto de software a un tercero, puedo descansar y
dejar que esa compañía lo elabore.
 Para comenzar a escribir programas, es suficiente el enunciado general de los
objetivos —podremos entrar en detalles más adelante.
 Los requerimientos del software cambian continuamente, pero el cambio se
asimila con facilidad debido a que el software es flexible.

 Una vez que escribimos el programa y hacemos que funcione, nuestro
trabajo ha terminado.
 Hasta que no se haga “correr” el programa, no hay manera de evaluar su
calidad.
 El único producto del trabajo que se entrega en un proyecto exitoso es el
programa que funciona.
 La ingeniería de software hará que generemos documentación voluminosa
e innecesaria, e invariablemente nos retrasará.
MITOS DEL SOFTWARE

Modelos de proceso de software
 La Ingeniería de Software como disciplina
 Un modelo de proceso de software es una representación simplificada de un
proceso de software que conlleva una estrategia global para abordar el desarrollo
de software
 Modelos de proceso de software:
 Codificar y corregir (code-and-fix)
 Desarrollo en cascada
 Desarrollo evolutivo
 Desarrollo formal de sistemas
 Desarrollo basado en reutilización
 Desarrollo incremental
 Desarrollo en espiral

Modelos de proceso de software:
Codificar y corregir (code-and-fix)

Modelos de proceso de software: Desarrollo en
Cascada
[Ingeniería de Software. Sommerville I.., 2002]

Modelos de proceso de software: Desarrollo
evolutivo

[Balzer R. A 15 Year Perspective on Automatic Programming. IEEE Transactions on Software Engineering,
vol.11, núm.11, páginas 1257-1268, Noviembre 1985 ]
Modelos de proceso de software: Desarrollo formal
de sistemas
Especificación
Tranformación
Interactiva
Transformación
Automática
Optimización
Validación de
Especificación
Mantenimiento
Especificación
de alto nivel
(prototipo)
Desarrollo
FormalDesiciones
Especificación
de bajo nivel
Código
Fuente
Especificación
Informal

basado en reutilización

incremental

22/05/2017
DiseñodeSoftwareI
Modelo de Proceso de Espiral
Determine objetivos
alternativas y
restricciones
Evalúe alternativas,
identifique y resuelva
riesgos
Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos
Análisis
de
Riesgos
Planea la
siguiente fase
Desarrolla y verifica
el siguiente nivel
del producto
Prototipo
OperacionalPrototipo
3Prototipo
2Proto
tipo 3
Plan de requerimientos
Plan del ciclo de vida
REVISIÓN
Plan de
Desarrollo
Plan de Integración
y Prueba
Concepto de
Operación
Simulaciones, modelos y benchmarks
Requeri
mientos de
SW
Validación de
Requerimientos
Diseño
V &V
Servicio
Prueba de
Aceptación
Prueba de
Integración
Prueba de
Unidades
Codificación
Diseño
Detallado
Diseño
del
Producto

Modelos de proceso de software ¿Cuál es el más
adecuado?
Modelo de
proceso
Desempeño con
requisitos y
arquitectura no
predefinidos
Produce software
altamente fiable Gestión de
riesgos
Permite
correcciones
sobre la marcha
Visión del
progreso por el
Cliente y el Jefe
del proyecto
Codificar y
corregir
Bajo Bajo Bajo Alto Medio
Desarrollo
En cascada
Bajo Alto Bajo Bajo Bajo
Desarrollo
Evolutivo
Alto Medio Medio Alto Alto
Desarrollo formal
de sistemas Bajo Alto Bajo a Medio Bajo Bajo
Desarrollo basado
en reutilización Medio Bajo a Medio Bajo a Medio Alto Alto
Desarrollo
Incremental
Bajo Alto Medio Bajo Bajo
Desarrollo
Espiral
Alto Alto Alto Medio Medio

Introducción a
Rational Unified Process (RUP)

Dos Dimensiones
III. Proceso de Desarrollo de SW basado en UML

Fases e Hitos (Milestones)
tiempo
Objetivos
(Vision)
Arquitectura Capacidad
Operacional
Inicial
Release
del Producto
Inception Elaboration Construction Transition

Elementos en RUP
 Workflows (Disciplinas)
Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de Configuración y
Cambios)

... Elementos en RUP
Workflow, Workflow Detail , Workers, Actividades y Artefactos
Ejemplo
Workflow Detail:Analyse the ProblemWorkflow: Requirements
Actividades
Workers Artefactos

Workers
Analyst workers
 Business-Process Analyst
 Business Designer
 Business-Model Reviewer
 Requirements Reviewer
 System Analyst
 Use-Case Specifier
 User-Interface Designer
Developer workers
 Architect
 Architecture Reviewer
 Capsule Designer
 Code Reviewer
 Database Designer
 Design Reviewer
 Designer
 Implementer
 Integrator
Testing professional workers
 Test Designer
 Tester
Manager workers
 Change Control Manager
 Configuration Manager
 Deployment Manager
 Process Engineer
 Project Manager
 Project Reviewer
Other workers
 Any Worker
 Course Developer
 Graphic Artist
 Stakeholder
 System Administrator
 Technical Writer
 Tool Specialist

Workers, Actividades, Artefactos
Ejemplo: System Analyst Worker

Artefactos
 Resultado parcial o final que es producido y usado
durante el proyecto. Son las entradas y salidas de
las actividades
 Un artefacto puede ser un documento, un modelo o
un elemento de modelo
 Conjuntos de Artefactos Deployment Set
 Project Management Set
 Configuration & Change Management Set
 Environment Set
 Business Modeling Set
 Requirements Set
 Analysis & Design Set
 Implementation Set
 Test Set

Artefactos, Workers, Actividades
Ejemplo:Business Modeling Artifact Set

Características Esenciales de RUP
 Proceso Dirigido por los Casos de Uso
 Proceso Iterativo e Incremental
 Proceso Centrado en la Arquitectura

Requisitos
Capturar, definir y
validar los casos de uso
Realizar los
casos de uso
Verificar que se
satisfacen los casos
de uso
Proceso dirigido por los Casos de Uso
Análisis & Diseño
Implementación
Pruebas
Casos de Uso
integran el
trabajo

Caso de Uso Realización de Análisis Realización de Diseño
Caso de Prueba
X
«trace» «trace»
«trace»
«trace»
Pruebas Funcionales
Pruebas
Unitarias
... Proceso dirigido por los Casos de Uso
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

... Proceso dirigido por los Casos de Uso

 El ciclo de vida iterativo se basa en la evolución de prototipos
ejecutables que se muestran a los usuarios y clientes
 En el ciclo de vida iterativo a cada iteración se reproduce el
ciclo de vida en cascada a menor escala
 Los objetivos de una iteración se establecen en función de la
evaluación de las iteraciones precedentes
Proceso Iterativo e Incremental

 Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración
Análisis
Diseño
Codific.
Pruebas e
Integración
n veces
... Proceso Iterativo e Incremental

 Cada iteración comprende:
 Planificar la iteración (estudio de riesgos)
 Análisis de los Casos de Uso y escenarios
 Diseño de opciones arquitectónicas
 Codificación y pruebas. La integración del nuevo código con
el existente de iteraciones anteriores se hace gradualmente
durante la construcción
 Evaluación de la entrega ejecutable (evaluación del prototipo
en función de las pruebas y de los criterios definidos)
 Preparación de la entrega (documentación e instalación del
prototipo)

Proceso Iterativo e Incremental
Enfoque
Secuencial
Enfoque
Iterativo e
Incremental

Grado de Finalización de Artefactos

Proceso Centrado en la Arquitectura
 Arquitectura de un sistema es la organización o estructura de sus partes más
relevantes
 Un arquitectura ejecutable es una implementación parcial del sistema,
construida para demostrar algunas funciones y propiedades
 RUP establece refinamientos sucesivos de una arquitectura ejecutable,
construida como un prototipo evolutivo.

Esfuerzo y dedicación por Fases en RUP
Inicio Elaboración Construcción Transición
Esfuerzo 5 % 20 % 65 % 10%
Tiempo
Dedicado 10 % 30 % 50 % 10%

Distribución de Recursos por Fases en RUP

Fin
Introducción a
Rational Unified Process (RUP)

¿Qué es UML?
 UML = Unified Modeling Language
 Un lenguaje de propósito general para el modelado orientado a
objetos. Impulsado por el Object Management Group (OMG,
www.omg.org)
 Documento “OMG Unified Modeling Language Specification”
 UML combina notaciones provenientes desde:
 Modelado Orientado a Objetos
 Modelado de Datos
 Modelado de Componentes
 Modelado de Flujos de Trabajo (Workflows)
I. Introducción: UML

Participantes en UML 1.0
 Rational Software
(Grady Booch, Jim Rumbaugh y
Ivar Jacobson)
 Digital Equipment
 Hewlett-Packard
 i-Logix (David Harel)
 IBM
 ICON Computing
(Desmond D’Souza)
 Intellicorp and James
Martin & co. (James Odell)
 MCI Systemhouse
 Microsoft
 ObjecTime
 Oracle Corp.
 Platinium Technology
 Sterling Software
 Taskon
 Texas Instruments
 Unisys

Aspectos Novedosos
 Definición semi-formal del Metamodelo de UML
 Mecanismos de Extensión en UML:
 Stereotypes
 Constraints
 Tagged Values
Permiten adaptar los elementos de modelado,
asignándoles una semántica particular

Inconvenientes en UML
 Definición del proceso de desarrollo usando UML. UML no es una metodología
 No cubre todas las necesidades de especificación de un proyecto software. Por
ejemplo, no define los documentos textuales
 Ejemplos aislados
 “Monopolio de conceptos, técnicas y métodos en torno a UML y el OMG”

Perspectivas de UML
 UML es el lenguaje de modelado orientado a objetos estándar
predominante ahora y en los próximos años
 Razones:
 Participación de metodólogos influyentes
 Participación de importantes empresas
 Estándar del OMG
 Evidencias:
 Herramientas que proveen la notación UML
 “Edición” de libros (más de 300 en www.amazon.com)
 Congresos, cursos, “camisetas”, etc.

Ingeniería de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Ingeniería de software

Similar a Ingeniería de software (20)

Último

Último (20)

Ingeniería de software