Introducción a la Ingeniería

de Software

2,018 - 1
Contenido
• Introducción a la Ingeniería del Software.
• El proceso del software.
• Modelos de ciclo de vida.
• Lineales o Tradicionales.
• Evolutivos.
• Uso de Prototipos.
• BPMN.
 Ingeniería de Software
DEFINICIONES
 “Establecimiento y uso de principios de
ingeniería para obtener software económico que
trabaje de forma eficiente en máquinas reales”.
Fritz Baver, 1968.

 “La aplicación de métodos sistemáticos,

disciplinados y cuantificables para el desarrollo,
operación y mantenimiento de software; esto es,
la aplicación de la ingeniería al software.”.
IEEE, 1993.
 ¿Qué es el Software (SW)?
Conjunto de programas de cómputo (fuentes y
ejecutables), su documentación asociada, así
como los datos pertenecientes a la operación
del sistema.
Soporte lógico de un sistema informático, que
comprende el conjunto de los componentes
lógicos necesarios que hacen posible la
realización de tareas específicas.
Características del software:
 Se desarrolla, no se fabrica.
 Se obsoleta por la aparición de nuevas tecnologías.
 Se desarrolla a la medida.
 Posee un ciclo de vida.
 Aproximaciones

Ingeniería del Software III

 Situación actual
 La industria del software no ha acabado de salir de la fase
artesanal.
 Padecemos de “prisa patológica”, que es consecuencia
directa de:
 Desorganización
 Falta de planificación
 Alta dependencia de los “héroes”.
 Dedicamos nuestros esfuerzos de hoy a arreglar lo que se
hizo mal ayer.
 Situación actual
 El producto (software) es algo intangible y no restringido por
las leyes físicas.
 La disciplina, ingeniería del software, es relativamente
reciente y muchos de sus conceptos importantes están aún
inmaduros
 Carencia de un corpus de conocimiento aceptado
mayoritariamente que sirva como fundamento.
 Escasa presión del mercado.
 Situación actual
En una organización inmadura:
 Procesos software normalmente improvisados.
 Si se han especificado, no se siguen rigurosamente.
 Organización reactiva (resolver crisis inmediatas).
 Planes y presupuestos excedidos sistemáticamente, al
no estar basados en estimaciones realistas.
 Situación actual
En una organización inmadura (cont.):
 Si hay plazos rígidos, se sacrifican funcionalidad y calidad
del producto para satisfacer el plan.
 No existen bases objetivas para juzgar la calidad del
producto.
 Cuando los proyectos está fuera de plan, las revisiones o
pruebas se recortan o eliminan.
 Coste de demandas y litigios legales añadidos.
 Efecto ONDA (proveedores y clientes).
 Qué hacer ?

Artesanía Ingeniería

Cambio cultural de todos

los involucrados!
Perspectiva de la Calidad del Software
PRODUCTO
(Qué hacemos)

CLIENTE PROCESO
(Para quién lo (Cómo lo hacemos)
hacemos)
 Proceso de construcción de software

“El conjunto completo de actividades de

ingeniería de software necesarias para
transformar los requerimientos del usuario en
software.” [Humphrey]

Problema Solución

Requisitos Análisis Diseño Codificación Pruebas Liberación

Requerimientos Software
 Ciclos de Vida
El proceso que se sigue para construir,
entregar y hacer evolucionar el
software, desde la concepción de una
idea hasta la entrega y el retiro del
sistema.

Representa todas las actividades y

artefactos (productos intermedios)
necesarios para desarrollar una
aplicación
 Procesos del Ciclo de Vida
Implícita o explícitamente todos los
modelos de ciclo de vida cuentan por lo
menos con los siguientes procesos:

REQUERIMIENTOS DISEÑO IMPLEMENTACIÓN PRUEBAS MANTENIMIENTO

 Modelos Lineales o Tradicionales
Formados por un conjunto de fases o actividades
en las que que no tienen en cuenta la naturaleza
evolutiva del software.
Los modelos “Cascada” y “V” son conocidos
modelos tradicionales.
 Modelo en Cascada
Es el modelo mas antiguo, propuesto por
Winston Royce en 1970.
Llamado también “modelo clásico” o “modelo
lineal”.
Es un modelo orientado en las actividades.
Prescribe una ejecución secuencial de un
subconjunto de los procesos de desarrollo y de
administración.
Modelo en Cascada
 Modelo en Cascada - Fortalezas
Fácil entendimiento e implementación.
Ampliamente utilizado y conocido.
Refuerza buenos hábitos: definir antes
que diseñar, diseñar antes que codificar.
Identifica entregables e hitos.
Orientado a documentos.
Funciona bien en productos maduros y
equipos débiles.
 Modelo en Cascada - Debilidades
Espera requerimientos definidos
completamente al inicio del proyecto.
Dificultad para integrar administración del
riesgo.
No aprovecha la iteración, ni el desarrollo
exploratorio.
El software es entregado tarde en el proyecto.
Esto hace que se detecten errores graves muy
tarde.
Hacer cambios es difícil y costoso.
 Modelo en V
Es una variante de la representación del
modelo de la cascada, que busca hacer la
actividad de pruebas más efectiva y productiva.
Los planes (y casos de prueba) se van
elaborando a medida que se avanza en el
desarrollo del proyecto.
La versión actual del Método-V es el Método-V
XT que se terminó en Febrero del 2005
Modelo en V
 Modelos Evolutivos
Son modelos que se adaptan a la evolución que
sufren los requisitos del sistema en función del
tiempo.
Los modelos “Espiral” e “Incremental” (entre
otros) son dos de los más conocidos y utilizados
del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de
una implantación del sistema inicial, exponerla a
los comentarios del usuario, refinarla en N
versiones hasta que se desarrolle el sistema
adecuado.
 Modelo en Espiral
Fue propuesto inicialmente por Boehm en 1986.
Basado en las mismas actividades del modelo
de cascada, agregando: manejo de riesgos y
creación de prototipos.
Las actividades son organizadas en ciclos.
Una ventaja de este modelo es que se obtiene
una rápida realimentación del usuario, ya que
las actividades de especificación, desarrollo y
pruebas se ejecutan en cada iteración.
 Modelo en Espiral
 Un ciclo corresponde a la construcción de un
producto intermedio.
 Las actividades de cada ciclo son:
Determinar objetivos.
Especificar las restricciones.
Generar alternativas.
Identificar riesgos.
Resolver riesgos.
Desarrollar y verificar próximo nivel del producto.
Desarrollar el plan del ciclo.
Modelo en Espiral
 Modelo Incremental
Fue propuesto por Harlan Mills en el año 1980.
Durante el proceso se trata de llevar a cabo al
desarrollo en diferentes partes que al final
terminarán siendo la solución completa requerida
por el cliente.
Se relaciona con novedosas estrategias de
desarrollo de software y una programación
extrema.
Modelo Incremental
 Uso de Prototipos
Un prototipo es un modelo experimental de un
sistema o de un componente de un sistema que
tiene los suficientes elementos que permiten su
uso.
Características:
„Es una aplicación que funciona.
„Su finalidad es probar varias suposiciones con respecto
a las características requeridas por el sistema.
Se crean con rapidez.
„Evolucionan a través de un proceso iterativo.
„Tienen un costo bajo de desarrollo.
 Uso de Prototipos
Es una técnica que puede implementarse en el
contexto de cualquiera de los modelos de proceso.
Es clave que todos los participantes deben estar de
acuerdo en que el prototipo sirva como el
mecanismo para definir los requerimientos.
Después se descartará (al menos en parte) y se
hará la ingeniería del software real con la mirada
puesta en la calidad.
 Capas en la Ingeniería del Software

CASE
Como construir
Base del A
control de c
gestión del Herramientas
proyecto
Métodos
t
Proceso
i
t
Un enfoque de calidad
u
d
Los cimientos que son la base de la ingeniería del software
están orientados hacia la calidad. (Pressman)
Interrelación con otras Disciplinas
 Principales Estándares
Modelos con mejores prácticas:
CMMI: Capability Maturity Model Integration.
ISO/IEC 15504: Software Process Improvement
Capability Determination.
PMBOK: A Guide to the Project Management Body of
Knowledge.
Áreas de Conocimiento:
SWEBOK: Software Engineering Body of knowledge.
Procesos de Ciclo de Vida:
ISO/IEC 12207: Software Life Cycle Processes.
 Principales Estándares
Calidad de Software como producto:
ISO/IEC 25000: System and Software Quality
Requirements and Evaluation.
Estándares menores:
IEEE 830: Software Requirements Specifications.
ISO/IEC 14764: Software Maintenance.
Business Process
Management
Notation (BPMN)
 Introducción

• El objetivo principal de desarrollar BPMN es proveer

una notación que sea fácilmente entendible por todos
los usuarios de negocio: Los analistas, los
desarrolladores técnicos, y por supuesto, la gente de
negocio que manejará y monitoreará estos procesos.

• El análisis de los procesos de negocios es una manera

de mejorar el desempeño de los sistemas de trabajo, ya
que podemos cambiar el proceso de negocios
cambiando, eliminando o agregando pasos al proceso o
también cambiando los métodos de cómo se usan estos
pasos.
 Introducción

• BPMN define un Diagrama de Procesos de Negocio

(BPD), basado en la técnica de “flowcharting”
(diagramado de flujos) que ajusta modelos gráficos de
operación de procesos de negocio.

• Un modelo de procesos de negocio es una red de

objetos gráficos, correspondientes a actividades y
controles de flujo que definen el orden de ejecución
de éstas.
 Proceso de negocios
Un proceso de negocios es un conjunto de pasos o
actividades relacionadas en las que intervienen
gente, información y otros recursos para crear
valor.
 Las actividades de los procesos de negocios se
pueden identificar en el tiempo y el espacio.
Tiene un principio y un fin.
Tienen entradas y salidas.
Tiene un grado de formalización pero no necesitan
ser totalmente estructurados.
Proceso de Negocio
 Elementos

Un BPD (diagrama de procesos de negocio) se estructura

con un grupo de elementos gráficos.

Las cuatro categorías básicas de elementos son:

• Flow Objects (objetos de flujo)

• Connecting Objects (objetos de conexión)
• Swimlanes (Carriles)
• Artifacts (artefáctos)
Ejemplo con formas básicas

Ejemplo de Proceso de Negocio Simple

 Ejemplo con formas básicas y marcas internas
en las formas

Segmento de un Proceso con más detalles

Elementos centrales de los diagramas
Ejemplo
Elementos del Proceso
 El Proceso de SW y BPMN
Entre las formas de notaciones para definir
procesos de software, se incluyen:
Listas de textos de actividades y tareas descritas en
lenguaje natural.
Diagramas de flujo de datos
Gráficos de estado.
BPMN.
IDEF0.
Redes de Petri.
Diagramas de actividad UML.