Universidad de

Los Lagos

Curso Ingeniería de Software

INFT.1

Profesor : Hermón Alfaro F.

Hermon.alfaro@tm-mas.com
 Objetivos
 Descripción de las actividades técnicas e ingenieriles que se llevan a cabo
en el ciclo de vida de un producto software
 Descripción de los problemas, principios, métodos y tecnologías
asociadas con la Ingeniería del Software
 Presentación de la importancia de los requisitos en el ciclo de vida del
software
 Introducción a las técnicas básicas de elicitación, documentación,
especificación y prototipado de los requisitos de un sistema software
 Introducción a los métodos de análisis/diseño estructurado, y los
métodos de análisis/diseño orientado a objetos
 Estudio y comprensión de los fundamentos del diseño de sistemas
software
 Aplicar de forma práctica los conceptos teóricos sobre el desarrollo
estructurado y orientado a objetos
Motivación

3
 La Ingeniería del Software dentro del currículo de los
ingenieros en informática aporta la primera aproximación a
la práctica real del desarrollo de software
 Proyectos realizados por equipos de desarrollo
 Programación a gran escala (programming in large)
 Obtención (elicitación) de los requisitos
 Modelos de ciclo de vida
 Gestión de la configuración
 Calidad del software
 Mantenimiento
 ……
¿Ingeniería? de Software

5
Ingeniería vs Métodos Tradicionales
 Grandes Problemas Históricos
 Retraso respecto al potencial de hardware
 Insatisfacción de la demanda
 Bajo cumplimiento de compromisos – costos, plazos
 Baja calidad y satisfacción de clientes/usuarios
 Mantención de sistemas legados
 Percepciones de la Disciplina
 Ineficiencia Altos costos
 Baja confiabilidad
 Escasa ingeniería
 Crisis del Software
 Origina la disciplina “Ingeniería de Software” en los 60s
 Síntomas típicos
 funcionalidad incorrecta
 costos y plazos excedidos
 insatisfacción de clientes y usuarios
 poca o nula visibilidad de lo que ocurre
 Crisis del Software
 Algunas causas potenciales
 carácter lógico del software
 formación profesional (o falta de)
 entrenamiento y actualización
 resistencia al cambio
 Solución potencial
 incorporar enfoque ingenieril en la forma de un proceso de
software …
 Crisis del Software
 Algunos mitos bastantes arraigados también
 estándares y procedimientos bastan
 tecnología de punta basta
 más gente para ponerse al día
 programación inmediata
 fácil acomodo de los cambios
 programación: fin del trabajo
 calidad: sólo del ejecutable
 código es el único producto
 Ingeniería de Software
 “ Establecimiento y uso de principios con caracteres de
ingeniería apropiados para obtener, eficientemente,
software confiable, que opere eficaz y eficientemente
en máquinas reales “

Concepto se acuñó en 1968, en Conferencia de la OTAN en Alemania , con la intención de

que mediante el uso de filosofías y paradigmas de disciplinas ingenieriles establecidas se
resolviera la denominada crisis del software
 Ingeniería de Software
 Objetivos
 maximizar calidad
 maximizar productividad
 minimizar riesgos
 Ingeniería de Software
 Implicancias
 mejores técnicas de control de calidad
 mejores herramientas y métodos

 Todo en la forma de proceso de software adecuado al tipo

de problema que se resuelve y que permitan gestionar de
mejor manera los principales riesgos relevantes para todos
los stakeholders (involucrados o afectados)
Proceso de Software Para Gestionar
Riesgos
 Proceso de Software
Desarrollo de software
Operación

Construcción
Análisis Diseño y Pruebas Pruebas
Unitarias

Mantención

Procesos de apoyo: Gestión de proyectos,

Gestión de Configuración,
Gestión de Requerimientos,
Gestión de la Calidad, ……….
 Riesgos de Software
 Categorías - Top 10
 Métricas inadecuadas
 Medición inadecuada
 Presión excesiva de tiempo
 Malas prácticas de gestión
 Estimación imprecisa de costos
 Síndrome del “silver bullet”
 Requerimientos Baja calidad
 Baja productividad
 Cancelación de proyectos
 Proceso de Software
 Proveer un producto o un servicio, siempre consiste en
seguir una secuencia de pasos, para llevar a cabo un
conjunto de tareas
 Las tareas se ejecutan usualmente en el mismo orden
todas las veces
 Un proceso es una serie de pasos que involucran
actividades, restricciones y recursos, que producen una
salida esperada, de algún tipo.
 Un proceso involucra usualmente un conjunto de
herramientas y técnicas.
 Proceso de Software
 Es importante, pues impone consistencia y estructura al
conjunto de actividades
 Es más que un procedimiento, es un conjunto organizado
de éstos.
 La estructura del proceso guía la acción, permitiendo
examinar, entender, controlar y mejorar las actividades
comprendidas por éste.
 También es importante pues permite capturar y transmitir la
experiencia, a proyectos futuros
 Cada proceso puede ser descrito por una combinación de
diferentes medios.
 Un poco de Historia
 El modelo usado era de codificar-corregir:
 Escribir el código.
 Revisar y eliminar los errores o mejorar/aumentar la
funcionalidad.
 A medida que el hardware aumentó sus capacidades y
disminuyó sus costos, se amplió el ámbito de las
aplicaciones y se masificó el uso de computadores.
 Se incursionó en áreas donde los problemas no eran tan
bien acotados (ej. administrativos) y el desarrollo se tornó
más complejo.
 Un poco de Historia
 Aparece un problema aún mayor: había que mantener los
sistemas.
 Esto escapó de las manos de los usuarios- programadores,
quienes ya no pudieron controlar el proceso, pues sólo
dominaban su especialidad, no el desarrollo de software.
 Se incorporan tópicos organizacionales y psicológicos, así
como también la demanda por mayor calidad y
confiabilidad.
 Un poco de Historia
 Además, ahora el desarrollo se convierte en una actividad
de grupo, lo cual demanda planificar, organizar y
estructurar el trabajo en torno a “proyectos”.
 La comunicación entre humanos (usuario- desarrollador y
desarrollador-desarrollador) se convierte en un problema.
 Se hace necesario definir un “Proceso
 Un poco de Historia
 El proceso a la antigua, como “caja negra”.
 Modelos de Proceso de Software
 En la Ingeniería de Software se describen muchos Modelos
de Proceso.
 Unos son prescriptivos: establecen la forma en que debería
progresar el proceso de software.
 Otros son descriptivos: dicen la forma en que el proceso de
software progresa en la realidad.
 Algunos Modelos de
Proceso de Software
 Modelo en Cascada.
 Modelo en V.
 Modelo de Prototipación.
 Modelo en Espiral.
 RUP Métodos Ágiles.
 Modelo en Cascada
 Es el más antiguo.
 Debe completarse un
estado antes de
comenzar el siguiente.
 Es útil para que el
desarrollador visualice lo
que va a hacer.
 Su principal problema es
que no refleja la
realidad..
Modelo en Cascada
 Modelo en Cascada
 Análisis de Requerimientos:
 Se centra e intensifica especialmente en el software
 El ingeniero de software debe comprender el ámbito de la información
del software, así como la función, el rendimiento y las interfaces
requeridas
 Diseño (sistema y programa):
 Se enfoca en cuatro atributos: la estructura de los datos, la
arquitectura del software, el detalle procedimental y la caracterización
de la interfaz
 El proceso de diseño traduce los requisitos en una representación del
software con la calidad requerida antes de que comience la
codificación
 Codificación:
 El diseño debe traducirse en una forma legible para la maquina. Si el
diseño se realiza de una manera detallada la codificación puede
realizarse automáticamente
 Modelo en Cascada
 Prueba (unitario, integración, sistema, aceptación):
 una vez que se ha generado el código comienza la prueba del
programa.
 La prueba se centra en la lógica interna del software, y en las funciones
externas, realizando pruebas que aseguren que la entrada definida
produce los resultados requeridos

 Mantenimiento:
 el software sufrirá cambios después de que se entrega al cliente, los
cambios ocurrirán debido a que hayan encontrado errores, a que el
software deba adaptarse a cambios del entorno externo (sistema
operativo o dispositivos periféricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento
Modelo V
 Modelo V
 La primera mitad es similar al Modelo en Cascada, y la
otra mitad tiene como finalidad hacer pruebas e
integración asociado a cada una de las etapas de la
mitad anterior.
 Se puede identificar una ventaja principal con respecto
al Modelo Cascada más simple, y se refiere a que este
modelo involucra chequeos de cada una de las etapas
del modelo de cascada.
 Modelo de Prototipación
 Permite la construcción rápida del sistema (o parte de éste).
 Usuario y desarrollador tienen una visión común.
 Se reduce el riesgo y lo incierto del desarrollo
 Modelo en Espiral
 Se combinan las actividades de desarrollo con Análisis de
Riesgo.
 El modelo es de tipo iterativo:
 Planificación → Análisis de Riesgo → Ingeniería → Evaluación
→ Planificación →
 ..En cada iteración, se evalúan las diferentes alternativas y
se elige una.
 Los gestores del proyecto intentan eliminar o minimizar el
riesgo.
Modelo en Espiral
 RUP – Rational Unified Process
 Su objetivo es asegurar la producción de software de
calidad dentro de plazos y presupuestos predecibles.
 Dirigido por casos de uso, centrado en la arquitectura,
iterativo (mini-proyectos) e incremental (versiones)
 Cada ciclo de vida del software abarca 4 fases en el
siguiente orden: concepción/planificación, elaboración,
construcción y transición
 La esencia de RUP es la iteración, y cada iteración resulta
en un entregable preferentemente ejecutable
RUP – Rational Unified Process
Mapa Conceptual de RUP

37
Fases de RUP: Inception (Inicio)

• Se establece la oportunidad y alcance el proyecto.

• Se identifican todas las entidades externas con las que se

trata (actores) y se define la interacción a un alto nivel de
abstracción:
– Identificar todos los casos de uso
– Describir algunos en detalle

• La oportunidad del negocio incluye:

– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
38
Fases de RUP: Inception (Inicio)

Productos:

• Un documento de visión • Caso de negocio:

general: – Contexto
– Requerimientos generales del – Criterios de éxito
proyecto – Pronóstico financiero
– Características principales
• Identificación inicial de riesgos.
– Restricciones
• Plan de proyecto.
• Modelo inicial de casos de uso
• Uno o más prototipos.
(10% a 20 % listos).
• Glosario.

39
Fases de RUP: Inception (Inicio)

Hito:
Objetivos del
Ciclo de Vida

Inicio Elaboración Construcción Transición

• Las partes interesadas deben acordar el alcance y la

estimación de tiempo y costo.

• Comprensión de los requerimientos plasmados en casos

de uso.
40
Fases de RUP: Elaboración

• Objetivos:
– Analizar el dominio del problema
– Establecer una arquitectura base sólida
– Desarrollar un plan de proyecto
– Eliminar los elementos de mayor riesgo para el desarrollo
exitoso del proyecto

• Visión de “una milla de amplitud y una pulgada de

profundidad” porque las decisiones de arquitectura
requieren una visión global del sistema.

41
Fases de RUP: Elaboración
Productos:
• Es la parte más crítica del
proceso:
– Al final toda la ingeniería
“dura” está hecha
– Se puede decidir si vale la
pena seguir adelante
• A partir de aquí la arquitectura,
los requerimientos y los planes
de desarrollo son estables.
• Ya hay menos riesgos y se
puede planificar el resto del
proyecto con menor
incertidumbre.
• Se construye una arquitectura
ejecutable que contemple:
– Los casos de uso críticos
– Los riesgos identificados
42
 Fases de RUP: Elaboración

Productos:

• Modelo de casos de uso (80% • Un prototipo ejecutable de la

completo) con descripciones arquitectura.
detalladas. • Lista revisada de riesgos y del
• Otros requerimientos no funcio- caso de negocio.
nales o no asociados a casos de • Plan de desarrollo para el resto
uso. del proyecto.
• Descripción de la Arquitectura del • Un manual de usuario
Software. preliminar.

43
Fases de RUP: Elaboración

Hito: Arquitectura de
Ciclo de Vida

Inicio Elaboración Construcción Transición

• Condiciones de éxito de la elaboración:

– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos han sido
abordados y resueltos?
– ¿Es el plan del proyecto algo realista?
– ¿Están de acuerdo con el plan todas las personas involucradas?
44
Fases de RUP: Construcción

• En esta fase todas las componentes restantes se desarrollan

e incorporan al producto.

• Todo es probado en profundidad.

• El énfasis está en la producción eficiente y no ya en la

creación intelectual.

• Puede hacerse construcción en paralelo, pero esto exige

una planificación detallada y una arquitectura muy estable.

45
Fases de RUP: Construcción

Productos:

• El producto de software integrado y corriendo en la plataforma

adecuada.

• Manuales de usuario.

• Una descripción del “release” actual.

46
Fases de RUP: Construcción

Hito:
Capacidad
Operacional

Inicio Elaboración Construcción Transición

• Se obtiene un producto Beta que debe decidirse si puede

ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
– ¿El producto está maduro y estable para instalarlo en el ambiente
del cliente?
– ¿Están los interesados listos para recibirlo?
47
Fases de RUP: Transición

• El objetivo es traspasar el software desarrollado a la

comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
• Incluye:
– Pruebas Beta para validar el producto con las expectativas del
cliente
– Ejecución paralela con sistemas antiguos
– Conversión de datos
– Entrenamiento de usuarios
– Distribuir el producto

48
Fases de RUP: Transición

Objetivos:

• Obtener autosuficiencia de parte de los usuarios.

• Concordancia en los logros del producto de parte de las
personas involucradas.
• Lograr el concenso cuanto antes para liberar el producto al
mercado.

Inicio Elaboración Construcción Transición

Producto
49
 Métodos Ágiles
 Interés creciente en los métodos ágiles (inicialmente
llamados ligeros, lightweight) en los últimos años
 enfrentamiento de requerimientos cambiantes
 tiempos de desarrollo escasos
 clientes y usuarios cada vez más exigentes

 Caracterizados alternativamente como

 antídoto a la burocracia (métodos planificados, pesados)
 Métodos Ágiles
 Algunas características de los métodos ágiles
 Documentación mínima
 Ciclos iterativos breves
 Reacción rápida ante los cambios
 Estrecha relación con el cliente
 Diseño simple
 Satisfacción de necesidades inmediatas
 Foco en las personas
 Organización libre
 Procesos adaptables, no predictivos
 Métodos Ágiles
 El proceso de Desarrollo XP

 Fase inicial de captura de requerimientos es eliminada

 El ciclo de desarrollo de XP se divide en liberaciones cada una

de las cuales es medida en historias de usuario
 Historia de usuario: unidad funcional en un proyecto XP, debe ser
entendible tanto para el cliente como para los desarrolladores,
verificable y pequeña
 Métodos Ágiles
 El proceso de desarrollo XP
 Fase de Exploración
 Fase de Planificación
 Fase de Iteraciones y Entregas
 Fase de Producción
 Fase de Mantenimiento
 Fase de Muerte
Métodos Ágiles
 Principales Métodos Ágiles
 Extreme Programming, XP
 Scrum
 Crystal Family
 Feature-Driven Design
 Adaptive Software Development
 DSDM
 Otros
 Agilidad vs. Proceso
 Ultimamente, distintos trabajos han investigado la relación
entre modelos de proceso y métodos ágiles, observando lo
siguiente
 CMM/CMMI y XP pueden complementarse (foco en aspectos de
gestión vs. técnicos)
 Métodos ágiles calzan con la esencia del mejoramiento de
procesos bajo una interpretación menos literal (que CMMI, por
ejemplo)
 Métodos ágiles apuntan a gestión de proyectos, no a gestión
de procesos
 Bibliografía
 Pressman Roger. “Ingeniería del Software”. Tercera
 Software Engineering: Theory and Practice (2nd Ed.) Shari
Pfleeger, Prentice Hall (2001), Cap. 1&2
 The Software-Research Crisis. Robert L. Glass, IEEE
Software, Noviembre 1994
 Using Risk to Balance Agile and Plan-Driven Methods Barry
Boehm, Richard Turner, IEEE Computer, Junio 2003
 Agile Alliance§ http://www.agilealliance.com/
 What is extreme programming? http://www.xprogramming.com/
Anexos
Arquitectura de Sistemas Computacionales

Ingeniería
de Software

Estructuración
de los Procesos
Estructuración
de las Comuni
caciones

Ingeniería
de las
comunicaciones
Estructuración
de los Datos

Ingeniería
de la Información 59
Arquitectura de Sistemas Computacionales

Datos Función Comunicaciones

Nivel .
Conceptual
(Esquema
...
del Negocio)

Nivel
Lógico
(S.I.A)

Nivel
Físico
(Implementa
ción Compu
tacional)
60
61
ode
deDesarrollo.
Desarrollo.
an ninibebió
pan bebióagua.
agua.YYen
enlas
lastablas
tablasescribió
escribiólas
laspalabras
palabrasdel
delpacto,
pacto,los
lostrece
trecemandamientos:
mandamientos:

perativos.
perativos.

mente …”
nmente …”
es en
nes enun
unRequisito,
Requisito,las
lasmodelarás
modelaráscomo
comoatributos
atributosdel
delRequisito
Requisitoooen ennuevos
nuevosRequisitos,
Requisitos,pero
peronunca
nuncaenen
os en
dos enun
unRequisito
Requisitodificultan
dificultansu
sucomprensión
comprensiónyysu suposterior
posteriortrazabilidad.
trazabilidad.
ones se
ciones semezclarán
mezclaránsisiseseproporciona
proporcionademasiado
demasiadodetalle;
detalle;ese
esedetalle
detallese
seindicará
indicaráen
enCasos
Casosde deUso,
Uso,refin
ref
syypreviamente
previamentesesehaya
hayaaprobado
aprobadosusuuso.
uso.
elelde
depalabras
palabraspor
porfrase,
frase,usando “,” y “;” apropiadamente
usando “,” y “;” apropiadamenteen enlaladescripción
descripciónde
delos
losRequisitos
Requisitospara
parafome
fom

e medir.
de medir.En
Ensu
sulugar
lugarusarás
usarásunidades
unidadesfísicas
físicaspara
paramedir,
medir,por
porejemplo,
ejemplo,cómo
cómodederápido
rápidodebe
deberendir
rendirun
unR
o,abstente
abstentede
deexpresiones
expresionesdel
deltipo
tipo“sin
“sinsobrecargar
sobrecargardemasiado
demasiadoelelservidor”.
servidor”.

isión, claridad yyconcreción) como
cisión, claridad concreción) comoaatitimismo.
mismo.
62
 Los
Los13
13Mandamientos
Mandamientosen
enelelProceso
Procesode
deDefinición
Definiciónde Requisitos
de Requisitos
  Entonces
EntoncesJehovah
Jehovahdijo
dijoalalAnalista
AnalistaFuncional:
Funcional:

—
—Escribe
Escribeestas
estaspalabras,
palabras,porque
porqueconforme
conformeaaellas ellashehehecho
hechopacto
pactocontigo
contigoyyconconelelEquipo
Equipode deDesarroll
Desarrol
hovah cuarenta
ehovah cuarentadías
díasyycuarenta
cuarentanoches.
noches.No Nocomió
comiópan panninibebió
bebióagua.
agua.YYen enlas
lastablas
tablasescribió
escribiólaslaspalab
pala
No
Nopensarás
pensaráselelcómo,
cómo,tan tansólo
sóloelelqué
quéyyelelpor
porqué.
qué.
No
Notetepronunciarás
pronunciarásen entiempos
tiemposcondicionales;
condicionales;en entodo
todocaso,
caso,tetepronunciarás
pronunciarásen entiempos
tiemposimperativos.
imperativos.
Evitarás
Evitarásrecoger
recogerDetalles
DetallesdedeDiseño.
Diseño.
No
Notetepronunciarás
pronunciaráscon conexpresiones
expresionesvagas
vagasen ensignificado,
significado,como “generalmente
como “generalmente…”,“comúnmente
…”,“comúnmente…” …”
equisito. Si
Requisito. Siexisten
existendistintas
distintasopciones
opcionesen enununRequisito,
Requisito,laslasmodelarás
modelaráscomocomoatributos
atributosdeldelRequisito
Requisitoooene
a necesidad,
da necesidad,de deforma
formaindividual.
individual.Muchos
Muchosverbos
verbosconcentrados
concentradosen enununRequisito
Requisitodificultan
dificultansusucomprens
compren
uisito. Las
quisito. Lasnecesidades
necesidadesooinformaciones
informacionesse semezclarán
mezclaránsisise seproporciona
proporcionademasiado
demasiadodetalle;
detalle;ese
esedetalle
detal
alos
losAcrónimos,
Acrónimos,salvosalvoquequese serecojan
recojanenenGlosarios
GlosariosuuOntologías
Ontologíasde deTérminos
Términosyypreviamente
previamentese sehaya
hayaapa
mero
merode desílabas
sílabaspor
porpalabra
palabrayyelelde depalabras
palabraspor porfrase,
frase,usando “,” y “;” apropiadamente
usando “,” y “;” apropiadamenteen enlaladescripció
descripció
No
Nousarás
usaráspronombres.
pronombres.
No
Nousarás
usaráspseudocódigo: “si
pseudocódigo: “sifecha fechaes esmayor
mayorqueque…”, “iterar
…”, “iterarsobre
sobre…”,…”,etc.
etc.
e medir.
de medir.EnEnsu sulugar
lugarusarás
usarásunidades
unidadesfísicas
físicaspara
paramedir,
medir,por
porejemplo,
ejemplo,cómocómode derápido
rápidodebe
deberendir
rendirun
unR
uedan ser
puedan sermedidas
medidasde deforma
formasencilla.
sencilla.Como
Comocontraejemplo,
contraejemplo,abstente
abstentede deexpresiones
expresionesdel deltipo
tipo“sin
“sinsobr
sob
Estos
Estosdiez
diezmandamientos
mandamientosse seencierran
encierranen endos:
dos:
mbiguación y
mbiguación yaalo axiomático sobre
lo axiomático sobretodas todaslas lascosas
cosasyyaalaslas33C´s
C´s(concisión, claridad
(concisión, claridadyyconcreción
concreción
63