Aspectos de la Ingeniería del

Software

Dr. Raimundo Vega

Código de Ética: principios
 1. PÚBLICO
 Los Ingenieros de Software deberán actuar consistentemente con
el interés público..
 2. CLIENTE y EMPLEADOR
 Los Ingenieros de Software deberán actuar de forma que
respondan a los intereses de sus clientes y empleadores siendo
consistentes con el interés público
 3. PRODUCTO
 Los Ingenieros de Software deberán asegurar que sus productos y
las modificaciones asociadas cumplan los más altos estándares
profesionales posibles.
Continuación......

 4. JUICIO
 Los Ingenieros de Software deberán mantener la
integridad e independencia en sus juicios profesionales.
 5. ADMINISTRACIÓN
 Los gerentes y lideres ingenieros de software deberán
suscribir y promocionar un enfoque ético en la
administración del desarrollo y mantenimiento del
software.
 6. PROFESIÓN
 Los Ingenieros de Software deberán mantener la
integridad y reputación de la profesión de acorde al
interés público.
Continuación......

 7. COLEGAS
 Los Ingenieros de Software debén ser imparciales y apoyar
a sus colegas.
 8. PERSONAL
 Durante toda su existencia, los ingenieros de software

deberán aprender prácticas de su profesión y promocionar

un enfoque ético en la práctica de su profesión.
Responsabilidad profesional y ética

 Confidencialidad
 El ingeniero de software deberá respetar la
confidencialidad de sus empleadores o clientes
independientemente de que hayan firmado un
acuerdo de confidencialidad.
 Competencia
 El ingeniero de software no debe falsificar su nivel
de competencia. No debe hacer trabajos que
esten fuera de su capacidad.
Continua..................
 Derecho de propiedad intelectual
 Los ingenieros de software deben estar
pendientes de las leyes locales que gobiernan el
uso de la propiedad intelectual, como patentes,
copyright etc. Deben asegurarse de que la
propiedad intelectual de los empleadores y
clientes este protegida.
 Uso inapropiado de los computadores
 Los ingenieros de software no deben utilizar sus
habilidades técnicas para utilizar de forma
inapropiada los computadores.
¿Cómo surge la Ingeniería del Software? (I)

 1955-1965: Programación de cualquier modo

 Programas pequeños, ninguna gestión, uso de
ensamblador
 1965-1975: Programación a pequeña escala
 Algoritmos, estructuras de datos, lenguajes de
programación de alto nivel, gestión individual.
 1975-actualidad: Programación a gran escala
 Bases de datos, programas que se ejecutan
continuamente, especificaciones complejas,
herramientas y entornos de desarrollo, gestión en
equipo.
¿Cómo surge la Ingeniería del Software? (II)

 Principales problemas que conducen a la “Crisis del

Software”:
 Expectativas: No responden a las expectativas de
los usuarios
 Fiabilidad: Fallan muy a menudo

 Coste: Difíciles de prever, superiores a lo esperado

 Facilidad de modificación: complejo, costoso y

propenso a errores
 Plazos: se entrega tarde

 Portabilidad: difícil, aún con la misma

funcionalidad
 Eficiencia: no se aprovechan óptimamente los
recursos
¿Cómo surge la Ingeniería del Software? (III)

 El Bank of America gastó US$23 M en un proyecto a 5 años. Se

terminó gastando mas de US$60 M para finalmente abandonar el
proyecto. Pérdidas totales estimadas en mas de US$1000 M.

 AllState (seguros) comenzó en 1982 un proyecto de automatización

integral de sus operaciones de 5 años de duración y US$ 8 M de
presupuesto. Fue abandonado en 1993 despues de gastar US$100 M.

 Blue Cross (Isapre Norteamericana) perdió mas de US$60 M en pagos

incorrectos debido a un error de software por el que habían pagado
mas de US$200 M.

 El 4 de julio de 1996 un cohete Ariane se desvió de su curso y explotó

a 3700 m. de altura. Causa: error de software.
¿Cómo surge la Ingeniería del Software? (IV)

 El software es mucho más difícil de construir de lo

que se pensaba.

 Conferencia de Garmish (1968): surge el término

INGENIERÍA DEL SOFTWARE
“Establecer y usar principios de ingeniería
orientados a obtener software de manera
económica, fiable y que funcione eficientemente
sobre máquinas reales” (Bauer)

 La ingeniería del software no es como otras

ingenierías
Algunas características de la Ingeniería
 Ataca problemas prácticos reales
 Genera soluciones razonables (costos, uso de recursos).
 Tiene su base en la ciencia
 Resultados repetibles
 Modelos matemáticos
 Área técnica bien entendida
 Codificación del conocimiento
 La experiencia de generaciones se escribe en enormes manuales y
se organiza para ser reusada
 Responsabilidad profesional
 Código de conducta
 Ética profesional
 Acreditación y monitoreo por parte de la sociedad profesional
 ¿Por qué es diferente? Características del
software

 El software se desarrolla, no se fabrica como en el

sentido clásico
 Control de calidad de distinta naturaleza
 Recursos humanos de distintas naturaleza
 Estructura de costo radicalmente distinta

 El software no se estropea (no se desgasta)

 ¿Por qué es diferente? Características del
software

 La mayoría de los proyecto implica partir de casi de

cero (no hay catálogos de componente a disposición
de los ingenieros)
 Falencias mas importantes
 Procesos no son repetible
 Compartir experiencia (codificación y reuso)
 Entrenamiento de profesionales
Principios de la Ingeniería del Software

 Una buena gestión es más importante que una buena

tecnología

 Las personas y el tiempo no son intercambiables

 Seleccionar el modelo de ciclo de vida adecuado

 Entregar productos al usuario lo más pronto posible

Principios de la Ingeniería del Software

 Determinar el problema antes de escribir los

requisitos

 Evaluar las alternativas de diseño

 Diseñar sin documentación es no diseñar

 Usar formalismos distintos para distintas fases

 Las técnicas son anteriores a las herramientas

Principios de la Ingeniería del Software

 Inspeccionar el código

 Primero hazlo correcto, después hazlo rápido

 La gente es la clave del éxito

 Introduce las mejoras con cuidado

 Asume tus responsabilidades

Componentes de la Ingeniería del Software

 Estándares (IEE830, otros)

 Métodos (paradigmas):
actividades necesarias para construir el software
 Técnicas:
formas concretas de llevar a cabo los métodos
 Formalismos:
notaciones utilizadas por las técnicas
 Herramientas:
implementan las técnicas
 Procedimientos:
establecen el orden en que se aplican los métodos
Tipos de software

 SOFTWARE: Programas computacionales y

documentación asociada
 Tipos de Software
 Software de sistemas (software básico)
 Software de tiempo real
 Software de gestión
 Software de ingeniería y científico
 Software empotrado
 Software de computadoras personales.
 Software de inteligencia artificial
Cuales son los atributos de un buen software

 Mantenibilidad
 El software debe escribirse de tal forma que pueda
evolucionar para cumplir las necesidades de cambios de
los clientes
 Confiabilidad
 Fiabilidad, seguridad, protección.
 Eficiencia
 Software no debe hacer que se malgasten los recursos
del sistema, memoria, ciclos de procesamientos.
Tiempos de respuestas y de procesamiento.
 Usabilidad
 El software deberá ser fácil de utilizar, sin esfuerzo
adicional por el usuario.
 El Proceso de Construcción de Software

Problema o necesidad Solución o software

Proceso
Software
Qué es el proceso software?

 Conjunto coherente de actividades para especificar,

diseñar, implementar y probar sistemas software.

 Actividades genericas en todo procesos software:

 Especificación (ERS) – Que haría el sistema y restricciones

de desarrollo.
 Desarrollo (Analísis-Diseño)– Producción del sistema
software
 Validación - Verificar que el software es el que desea el
cliente
 Evolución (mantenimiento) – Cambiar el software en
respuestas a cambios por demanda.
Modelo de proceso software

 Un modelo de proceso software (ciclo de vida) es una

representación abstracta de un proceso. Representa
una descripción de un proceso desde alguna
perspectiva en particular.
 Proceso Software vs. Ciclo de Vida

 El Proceso Software como proceso de

transformación: recibe unas entradas y genera unas
salidas
 El Producto Software va pasando por una serie de
estados a medida que se transforma:
 Necesidad

 Especificación de requisitos

 Diseño del sistema

 Código

 Sistema software operativo

 Ciclo de Vida: estados por los que pasa el producto

desde que nace hasta que muere
 Proceso Software vs. Ciclo de Vida

Proceso de construcción
Obtención Diseñar
Codificar Probar
requisitos sistema

Ciclo de vida Especific. Sistema

Necesidad Diseño Código
del producto requisitos software
 Ciclos de Vida (i)

 Modelo de ciclo de vida:

 abstracción de las fases o estados por los que pasa un
producto software a lo largo de su vida
 representa una posible aproximación a la producción de
software
 Debe:
 Determinar el orden de las fases
 Establecer los criterios de transición entre fases
Ciclos de Vida (ii)

 No hay un modelo de ciclo de vida

que sirva para todos los proyectos:
 cultura de la organización
 deseo de asumir riesgos
 área de aplicación
 volatilidad de los requisitos
 comprensión de los requisitos
 experiencia previa
Modelo de Ciclo de Vida Clásico o en Cascada (i)

Requisitos

Diseño

Codificación

Prueba

Operación
 Modelo de Ciclo de Vida Clásico o en Cascada (ii)

 Royce-1970
 Orden lineal en las transiciones entre fases
 Vuelta atrás al detectar Equivocaciones
 Asume que:
 Los requisitos se pueden conocer completamente y sin
ambigüedad al principio del proceso de desarrollo
 Los requisitos no varían
 Cada etapa implica una revisión
 No se pasa a la siguiente etapa hasta que se completa la
actual
Modelo de Ciclo de Vida Clásico o en Cascada (iii)

 Implica que:
 Los requisitos pueden quedarse obsoletos
 No hay un ejecutable que enseñar al
usuario hasta el final
 99% de recursos consumidos - errores
irremediables
 Coste de cada etapa
 Según Boehm (1975):
Tipo de Sistema Req y Diseno Implementar Pruebas

Sistemas de Control 46 20 34
Sistemas especiales 34 20 46
Sistemas Operativos 33 17 50
Sistemas científicos 45-53 27-36 15-23
Sistemas de Gestión 44 28 28
 Modelo de Ciclo de Vida Evolutivo
 Cuándo:
 El cliente no sabe bien lo que quiere
 No se comprende bien lo que quiere
 No se está seguro de la viabilidad de la solución
 Objetivo: producir una versión de
funcionalidad reducida en las fases iniciales
del proceso de desarrollo
 En papel, describiendo la interacción
 Ejecutable: (un prototipo que funcione) tiene su propio ciclo de
vida
 El prototipo es evaluado por el usuario y se
refina la especificación de requisitos
 Tipos de Prototipos
 Desechable:
 sólo se incorporan los aspectos peor entendidos o dudosos
 desarrollo ‘quick and dirty’
 Prototipo evolutivo:
 el prototipo se desarrolla rigurosamente
 fácil de ampliar y modificar
 se van incorporando las partes mejor entendidas
Prototipado
 Etapas:
 Análisis preliminar y especificación de requisitos
 Diseño e implementación del prototipo
 Prueba del prototipo
 Refinamiento iterativo del prototipo
 Refinamiento de la especificación de requisitos
 Diseño e implementación del sistema final
Modelo de Ciclo de Vida Iterativo

 Incremental

 Espiral
 Modelo de Ciclo de Vida en Espiral (i)
Costes acumulados
Evaluación de alternativas,
Determinación de objetivos, identificación de riesgos
alternativas, restricciones
Análisis
deriesgo
Análisis
deriesgo
Análisis
deriesgo
Análisis Prototipo Prototipo Prototipo
deriesgo
Revisión Prototipo operativo

Plan de requisitos Concepto de

Plan de ciclo de vida operación Requisitos
del softwaare
Diseño
Plan del desarrollo Validación de Diseño detallado
requisitos
Plan de la integración Validación y verificación PruebaCodificación
y prueba del diseño de
unidad
Prueba Integración
Implementaciónde y prueba
aceptación

Desarrollo, verificación del

Planificación de las próximas fases producto del próximo nivel
Modelo de Ciclo de Vida en Espiral (ii)

 Boehm - 1986
 Enfoque dirigido por el riesgo. En cada ciclo
se hace un análisis de riesgo:
 identificar situaciones que pueden causar el
fracaso
 centrarse primero en los aspectos de mayor riesgo
 Tipos de ciclos:
 Internos: prototipado
 Externos: clásico
Proceso unificado de desarrollo RUP
RUP
• Es un proceso de desarrollo de software
• Dirigido por casos de uso
• Centrado en la Arquitectura
• Iterativo e Incremental

• Utiliza UML para definir los sistemas software

• El sistema software en construcción está formado por

• Componentes software
• Interconectado a través de interfaces
Metodologías Ágiles
 Xp
 Scrum
Especificación de Requisitos
 Es el proceso de establecer que servicios son
los requeridos y las restriciones sobre la
operación y desarrollo de un sistema.
 Proceso de ingeniería de requerimiento.
 Estudio de factibilidad

 Educción y analisis de requerimientos.

 Especificación de requerimiento.

 Validación de requerimiento.
El proceso de ingeniería de requisitos

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
Diseño de Software e implementación

 El proceso de conversión de la especificación del

sistema en un sistema ejecutable
 Diseño de software
 Diseñar una estructura de software que da cuenta

de la especificación.
 Implementación
 Traducir esta estructura en un programa

ejecutable
 Las actividades de diseño e implementación están

estrechamente relacionados y pueden ser

intercaladas.
 Proceso de Diseño de Software

Requirements
specification

Design activities

Architectural Interface Comp onent Data Algorithm

Abstract
design design design structur
e design
specification
design

Software Data
System Interface Comp onent Algorithm
specification structure
architecture specification specification specification
specification

Design products
Metodos de Diseño
 Aproximación sistemática para desarrollar un
diseño de software.
 El diseño es usualmente documentado como
un conjunto de modelos gráficos (artefactos)
 Tipos de modelos
 Modelo Data-flow

 Modelo Entity-relation-attribute

 Modelo estructurado

 Modelo de Objeto.
Programación and depuración
(debugging)
 Traducir un diseño en un programa y eliminar
los errores de ese programa.
 La programación es una actividad personal no
hay un proceso generico.
 Los programadores llevan a cabo algunas
pruebas del programa para descubrir fallos en
él y eliminar estos fallos en el proceso de
depuración
El proceso de depuración.

Locate Design Repair Re-test

error error repair error program
Validación de software
 Asegurarse de que un sistema de
software satisface las necesidades de
un usuario.

 Probar el sistema involucra ejecutar el

sistema con casos de prueba que son
derivados de especificaciones reales.
Verificación y Validación
 Verificación:
"Estamos construyendo el producto correctamente "
El software debe ser conforme a su especificación
 Validación:
" Estamos construyendo el producto correcto"
El software debe hacer lo que el usuario realmente
necesita.
El proceso de prueba

Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing
Etapas de pruebas
 Prueba de unitarias
 Componentes individuales son testeados.
 Prueba de modulos
 Colección relacionada de componentes dependientes son probados.
 Prueba de sub-sistemas
 Los modulos son integrados en subsistemas y probados..El foco aquí debe
estar en las pruebas de interfaz.
 Testear sistema
 Testear sistema como un todo.
 Prueba de recepción.
 Testear con datos del cliente para recepción final del producto.