UNIDAD I: Introduccin a la Ingeniera de

Software.

INGENIERA DE
SOFTWARE I
Calendario de Exmenes
I parcial: 25 de marzo
Resc./Rep. I parcial: 08 de Abril
II parcial: 22 de Abril
Resc./Rep. II parcial: 13 de Mayo
Examen Final: 27 de Mayo
CONTENIDO
1.1. Definiciones
1.2. Evolucin del Software
1.3. Importancia del Software
1.4. Problemas del Software
1.5. Caracterstica del Software
1.6. Conceptos de Calidad
1.7. Mitos del Software
1.8. Distribucin del Esfuerzo en un Proyecto de
Programacin.
1.9. Administracin de Proyectos de Software
1.10. Paradigmas de la Ingeniera de Software
Tpica apariencia del
estudiante promedio
cuando le preguntan
acerca de Ingeniera de
Software
SOFTWARE

Es el conjunto de programas de cmputo,
documentos asociados y esquemas de
configuracin necesarios para que estos
programas operen. [Sommerville, 2001]
INGENIERA DEL SOFTWARE

La definicin de Ingeniera del Software de acuerdo a
los autores ms acreditados o bien a las definiciones
dadas por organismos internacionales profesionales
como la IEEE o ACM son:

1.Ingeniera del Software es el estudio de los
principios y metodologas para desarrollo y
mantenimiento de sistemas de software. [Zelkovitz,
1978]
INGENIERA DEL SOFTWARE
2. Ingeniera del Software es la aplicacin prctica del
conocimiento cientfico en el diseo y construccin de
programas de computadora y la documentacin asociada
requerida para desarrollar, operar y mantenerlos. Se
conoce tambin como desarrollo de software o
produccin de software. [Bohem, 1976]

3. Ingeniera del software trata del establecimiento de los
principios y mtodos de la ingeniera a fin de obtener
software de modo rentable que sea fiable y trabaje en
mquinas reales. [Bauer, 1972]
INGENIERA DEL SOFTWARE
4. La aplicacin de un enfoque sistemtico,
disciplinado y cuantificable al desarrollo,
operacin (funcionamiento) y
mantenimiento del software; es decir, la
aplicacin de ingeniera al software. 2. El
estudio de enfoques como en (1) [IEEE,
1993]
2.2. HISTORIA DE LA ING DE SW
Ingeniera del Software, es el trmino utilizado
por Fritz Bauer en la primera conferencia sobre
desarrollo de software patrocinada por el Comit de
Ciencia de la OTAN celebrada en Garmisch
(Alemania), en octubre de 1968, previamente haba
sido utilizado por el holands Edsger Dijkstra en su
obra The Humble Programmer.
Puede definirse segn Alan Davis como "la
aplicacin inteligente de principios probados,
tcnicas, lenguajes y herramientas para la creacin y
mantenimiento, dentro de un coste razonable, de
software que satisfaga las necesidades de los
usuarios".
HISTORIA DE LA ING DE SW (CONTINUACIN)
Su origen se debi a que el entorno de desarrollo de sistemas software
adoleca de:

Retrasos considerables en la planificacin

Poca productividad

Elevadas cargas de mantenimiento

Demandas cada vez ms desfasadas frente a las ofertas

Baja calidad y fiabilidad del producto

Dependencia de los realizadores

HISTORIA DE LA ING DE SW (CONTINUACIN)
Esto es lo que se ha denominado habitualmente "crisis del
software", que histricamente se gener en los siguientes pasos:

- Primera Fase. Los albores (1945-1955)

Programar no es una tarea diferenciada del diseo de una
mquina
Uso de lenguaje mquina y ensamblador.

- Segunda Fase. El florecimiento (1955-1965)

Aparecen multitud de lenguajes
Se pensaba que era posible hacer casi todo.
HISTORIA DE LA ING DE SW (CONTINUACIN)
- Tercera Fase. La crisis (1965-1970)

Desarrollo inacabable de grandes programas
Ineficiencia, errores, coste impredecible
Nada es posible.

- Cuarta Fase. Innovacin conceptual (1970-1980)

Fundamentos de programacin
Verificacin de programas
Metodologas de diseo.

- Quinta Fase. El diseo es el problema (1980-?)

Entornos de programacin
Especificacin formal
Programacin automtica.

HISTORIA DE LA ING DE SW (CONTINUACIN)
Cmo se define crisis?

La palabra crisis se define en el diccionario como "un punto decisivo en el
curso de algo; momento, etapa, o evento decisivo o crucial". Sin embargo
para el software no ha habido ningn punto crucial, slo una lenta
evolucin.

La crisis en la industria del software permanece durante muchos aos, lo
cual parece una contradiccin para el trmino. Lo que si se podra decir es
que hay un problema crnico en el desarrollo de software.

Que ha venido originado por una falta de:

Formalismo y metodologa

Herramientas de soporte

Administracin eficaz
HISTORIA DE LA ING DE SW (CONTINUACIN)
Actualmente est surgiendo una gran expectativa ante la evolucin de
la Ingeniera del Software, al ir apareciendo nuevos mtodos y
herramientas formales que van a permitir en el futuro un planteamiento
de ingeniera en el proceso de elaboracin de software.
Dicho planteamiento permitir dar respuesta a los problemas de:
- Administracin
- Calidad
- Productividad
- Fcil mantenimiento

Este ltimo es uno de los grandes problemas, pues puede llegar a
suponer un importe superior al 60% del total del coste del software.
PORQUE SE CREA LA INGENIERA DE
SOFTWARE??
La ingeniera de software se crea debido a las siguientes caractersticas:
El producto debe ser confiable y realizar slo las tareas especificadas en los requerimientos.
El producto debe ser robusto. Esto quiere decir que el software se comporta de manera
razonable, incluso en circunstancias no anticipadas desde el principio.
El producto de software debe ser lo ms reutilizable posible, de manera tal que pueda ser
incorporado en otro producto de software si se requiere.
El producto de software debe ser eficiente en el uso de los recursos del sistema.
Se requiere desarrollar el software en una manera que lo haga evolutivo, de forma tal que
se pueda agregar funcionalidad adicional sin efectos perjudiciales.
El producto de software debe cumplir con los requerimientos de rendimiento especificados,
es decir, debe cumplir algunas de las restricciones relacionadas al rendimiento.
El producto de software tendr mayor valor si es portable, es decir que puede trabajar bajo
diferentes plataformas de software y ambientes (hardware, sistemas operativos, etc.).
El producto de software debe ser utilizable, es decir, el aprendizaje de su uso debe ser los
suficientemente sencillo por parte de personas no especialistas.

escuela superior de ingeniera
informtica
ingeniera del software de
gestin
NATURALEZA Y PROBLEMAS DEL
DESARROLLO DE SOFTWARE
El software como elemento lgico.
Se desarrolla, no se fabrica:
Calidad del diseo.
Costes ms importantes en la ingeniera
Gestin especial de los proyectos
Se deteriora con el mantenimiento
Desarrollo a medida (ausencia de componentes)
La crisis del software: problemas que aparecen en el desarrollo del software al
desarrollar, mantener y atender la demanda de nuevas aplicaciones.


Insatisfaccin del cliente
Planificacin y estimaciones
imprecisas
Calidad
Sin tiempo para recoger
datos histricos
Baja productividad
Dificultad de mantener
el software existente
escuela superior de ingeniera
informtica
ingeniera del software de
gestin
NATURALEZA Y PROBLEMAS DEL
DESARROLLO DE SOFTWARE
Causas de la crisis del software
Naturaleza lgica del software
Mala gestin de los proyectos ( ausencia de
datos, deficiente comunicacin, ...)
Ausencia de entrenamiento formal en nuevas
tcnicas (programadores vs. ingenieros de
software)
Resistencia al cambio
Mitos del software:

MITOS DEL CLIENTE

- Requisitos establecidos como
una declaracin general de
objetivos
- Flexibilidad del software ante
los cambios

MITOS DE GESTIN

- Uso de estndares
- Uso de herramientas
- Mala planificacin: aumento
de programadores

MITOS DE LOS DESARROLLADORES

- Programa funcionando = fin del trabajo
- Calidad = el programa se ejecuta
sin errores
- Entrega al cliente: programa
funcionando
2.3. CARACTERSTICAS DEL SOFTWARE
El software se desarrolla o construye;
no se fabrica.
Aunque existen similitudes entre el desarrollo del software y
la construccin del hardware, ambas actividades son
fundamentalmente diferentes.
En ambas actividades la buena calidad se adquiere
mediante un buen diseo, pero la fase de construccin del
hardware puede introducir problemas de calidad que no
existen (o son fcilmente corregibles) en el software.
Ambas actividades dependen de las personas, pero la
relacin entre las personas dedicadas y el trabajo realizado
es completamente diferente para el software.
Ambas actividades requieren la construccin de un
producto pero los enfoques son diferentes.
Los costos del software se concentran en la ingeniera. Esto
significa que los proyectos de sw no se pueden manejar
como si fueran proyectos de fabricacin.








2.3. CARACTERSTICAS DEL SOFTWARE
El software no se desgasta






Tiempo
Se
estropea

n
d
i
c
e

d
e

F
a
l
l
o
s

Mortalidad
Infantil
Curva de Baera
Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 ed
Tiempo
Incremento del ndice de fallos
por efectos de laterales

n
d
i
c
e

d
e

f
a
l
l
o
s

Cambio
Curva real
Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 6 ed

CURVA DE FALLOS PARA EL SOFTWARE
2.3. CARACTERSTICAS DEL SOFTWARE
Aunque la industria tiene una
tendencia hacia la construccin por
componentes, la mayora del software
an se construye a la medida.
En el mundo del hardware, la reutilizacin
de componentes es una parte natural del
proceso de ingeniera. En el mundo del
software es el inicio.





2.7. SOFTWARE DE ALTA CALIDAD
Qu es calidad?

El grado en que un sistema, componente, o
proceso cumple con los requerimientos
especificados, y las necesidades y/o expectativas
del cliente o usuario.
ISO 9000: Calidad: grado en el que un conjunto de caractersticas inherentes cumple
con los requisitos
Real Academia de la Lengua Espaola: Propiedad o conjunto de propiedades
inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las
restantes de su especie
Philip Crosby: Calidad es cumplimiento de requisitos
Armand V. Feigenbaum: Satisfaccin de las expectativas del cliente.
Genichi Taguchi: Calidad es la menor prdida posible para la sociedad.
William Edwards Deming: Calidad es satisfaccin del cliente.
Walter A. Shewhart: La calidad como resultado de la interaccin de dos dimensiones:
dimensin subjetiva (lo que el cliente quiere) y dimensin objetiva (lo que se ofrece).
.
OTRAS DEFINICIONES DE CALIDAD
2.7. SOFTWARE DE ALTA CALIDAD
Qu es calidad de software?
Pressman (2002) se refiere a la calidad del
software como
La concordancia con los requisitos
funcionales y de rendimiento explcitamente
establecidos, con los estndares de
desarrollo explcitamente documentados, y
con las caractersticas implcitas que se
espera de todo software desarrollado
profesionalmente.

LAS DEFINICIONES ANTERIORES RESALTAN TRES
PUNTOS IMPORTANTES:
Los requisitos del software son la base de las
medidas de calidad. La falta de concordancia con los
requisitos es una falta de calidad.
Los estndares especificados definen un conjunto
de criterios de desarrollo que guan la forma en que
se aplica la ingeniera del software. Si no se siguen
esos criterios, casi siempre habr falta de calidad.
Existe un conjunto de requisitos implcitos que a
menudo no se mencionan. Si el software se ajusta a
sus requisitos explcitos pero falla en alcanzar los
requisitos implcitos, la calidad del software queda en
entredicho.

CONTROL DE CALIDAD
El control de calidad es una serie de
inspecciones, revisiones y pruebas
utilizadas a lo largo del proceso del
software para asegurar que cada producto
cumpla con los requisitos que le han sido
asignados.
GARANTA DE CALIDAD
La garanta de calidad consiste en la auditoria y las
funciones de informacin de la gestin. El objetivo
de la garanta de calidad es proporcionar la gestin
para informar de los datos necesarios sobre la
calidad del producto, por lo que se va adquiriendo
una visin ms profunda y segura de que la calidad
del producto esta cumpliendo sus objetivos.
COSTOS DE CALIDAD
El costo de la calidad incluye todos los
costos acarreados en la bsqueda de la
calidad o en bsqueda de las actividades
relacionadas en la obtencin de la calidad.

El costo de calidad se puede dividir en:
Costos de prevencin
Costos de evaluacin
Costos de fallos.

COSTOS DE PREVENCIN
En el costo de prevencin se incluye:

Planificacin de calidad,
Revisiones de tcnicas formales,
Equipo de pruebas,
Formacin.
COSTOS DE EVALUACIN
En el costo de evaluacin se incluyen actividades
para tener una visin mas profunda de la condicin
del producto la primera vez a travs de cada
proceso.
Algunos ejemplos de costos de evaluacin:
Inspeccin en el proceso y entre procesos,
Calibrado y mantenimiento del equipo,
Pruebas.

COSTOS DE FALLO
Los costos de fallo son los costos que
desapareceran si no surgieran defectos antes del
envi de un producto a los clientes.
Estos costos se pueden subdividir en costos de fallo
interno y costos de fallo externo.

Los internos se producen cuando se detecta un
error en el producto antes de su envi. Entre estos se
incluyen:
Revisin,
Reparacin,
Anlisis de las modalidades de fallos.


CONTINUACIN
Los costos de fallo externo son los que se
asocian a los defectos encontrados una vez
enviado el producto al cliente.

Algunos ejemplos de costos de fallo externo:
Resolucin de quejas,
Devolucin y sustitucin de productos,
Soporte de lnea de ayuda,
Trabajo de garanta.

May-14 Ing. de Software
Qu es
la Ing.
de Sw
- 32
CLIENTE
Patrocina el desarrollo
del sistema
USUARIO
Usa el
sistema
DESARROLLADOR
Construye
el
sistema
Obligacin
contractual
$$$,
necesidades
Sistema de software
Necesidades
2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD
(MCCALL)
Los factores que afectan la calidad del
software se pueden categorizar en dos
amplios grupos:

Factores que se pueden medir directamente (por
ejemplo, defectos por punto de funcin) y

Factores que se pueden medir solo indirectamente (por
ejemplo, facilidad de uso o de mantenimiento).

2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD
(MCCALL)
Facilidad de Mantenimiento
Flexibilidad
Facilidad de Prueba
Transicin del Producto Revisin del Producto
Operacin del Producto
Portabilidad
Reusabilidad
Interoperatividad
Correccin Fiabilidad Usabilidad Integridad Eficiencia
FACTORES DE CALIDAD DE MCCALL
Correccin. Hasta dnde satisface un programa su
especificacin y logra los objetivos propuestos por el
cliente. Hace lo que quiero?. Dicho de otra forma,
es la capacidad de los productos de software para
realizar con exactitud sus tareas, tal y como se
definen en las especificaciones.

La correccin es la cualidad principal. Si un sistema
no hace lo que se supone que debe hacer, poco
importan el resto de consideraciones que hagamos
sobre l si es rpido, si tiene una bonita interfaz de
usuario, etc.

FACTORES DE CALIDAD DE MCCALL
Fiabilidad. Hasta donde se puede esperar que
un programa lleve a cabo su funcin con la
exactitud requerida. Lo hace de forma fiable
todo el tiempo?.
Eficiencia. Es la capacidad de un sistema de
software para exigir la menor cantidad posible
de recursos hardware, tales como tiempo del
procesador, espacio ocupando memoria interna
y externa o ancho de banda utilizado en los
dispositivos de comunicacin. Se ejecutara en
mi hardware lo mejor que pueda?

FACTORES DE CALIDAD DE MCCALL
Integridad. Es la capacidad de los sistemas software
de proteger sus diversos componentes (programas,
datos, etc.) contra modificaciones y accesos no
autorizados. Hasta donde se puede controlar el
acceso al software o a los datos por personas no
autorizadas. Es Seguro?
Usabilidad (facilidad de manejo). Es la facilidad con
la cual personas con diferentes formaciones y
aptitudes pueden aprender a usar los productos de
software y aplicarlos a la resolucin de problemas.
Tambin cubre la facilidad de instalacin, de
operacin y de supervisin.

FACTORES DE CALIDAD DE MCCALL
Facilidad de mantenimiento. El esfuerzo
necesario para localizar y arreglar un error en
un programa. Puedo corregirlo.
Flexibilidad. El esfuerzo es necesario para
modificar un programa que ya esta en
funcionamiento. Puedo cambiarlo?.
Facilidad de prueba. El esfuerzo necesario
para probar un programa y asegurarse de que
realiza correctamente su funcin. Puedo
probarlo?.

FACTORES DE CALIDAD DE MCCALL
Portabilidad. Es la facilidad de transferir los
productos software a diferentes entornos hardware y
software.
Reusabilidad (capacidad de reutilizacin). Es la
capacidad de los elementos de software de servir
para la construccin de muchas aplicaciones
diferentes.
Interoperatividad. El esfuerzo necesario para
acoplar un sistema con otro. Interoperatividad es la
facilidad de combinar unos elementos de software
con otros. Podr hacerlo interactuar con otro
sistema?.
2.4. MITOS DEL SOFTWARE
Mitos de los administradores
Mitos de los Clientes
Mitos de los Desarrolladores
En la actualidad, la mayora de los profesionales
reconocidos en la ingeniera del software identifican los
mitos en su real dimensin: actitudes equivocadas que han
causado problemas serios a los administradores y al
personal tcnico por igual. Sin embargo, las antiguas
actitudes y viejos hbitos son difciles de modificar, por lo
que an subsisten creencias falsas sobre el software.
MITOS DE LOS ADMINISTRADORES
Mito 1. Ya se tiene un libro lleno de estndares y
procedimientos para la construccin de software. Esto
proporcionar a mi gente todo el conocimiento necesario?

Mito 2. Si se est atrasado en el itinerario es posible
contratar ms programadores para as terminar a tiempo.

Mito 3. Si decido subcontratar el proyecto de software a un
tercero, puedo relajarme y dejar que esa compaa lo
construya.
MITOS DE LOS CLIENTES
Mito 1. Un enunciado general de los objetivos es
suficiente para comenzar a escribir programas; los
detalles se pueden afinar despus.

Mito 2. Los requerimientos del proyecto cambian de
manera continua, pero el cambio puede ajustarse con
facilidad porque el software es flexible.

MITOS DE LOS DESARROLLADORES
Mito 1. Una vez que el programa ha sido escrito y puesto a
funcionar, el trabajo est terminado.

Mito 2. Mientras el programa no se est ejecutando, no existe
forma de evaluar su calidad.

Mito 3. El nico producto del trabajo que puede entregarse para
tener un proyecto exitoso es el programa en funcionamiento.

Mito 4. La Ing de Sw obligar a emprender la creacin de una
documentacin voluminosa e innecesaria y de manera
invariable tornar ms lento el proceso.
escuela superior de ingeniera
informtica
ingeniera del software de
gestin
DESARROLLO EVOLUTIVO
Recoleccin
y refinamiento de
requisitos
Diseo
rpido
Producto
Refinamiento
del prototipo
Evaluacin del
prototipo por
el cliente
Construccin
del prototipo
basado en:
desarrollo de una implementacin inicial
exposicin a comentarios y crtica del
usuario
refinamiento a travs de diferentes
versiones hasta llegar a un sistema
adecuado

dos tipos:
prototipado evolutivo:
trabajo con
cliente para
explorar sus
requerimientos y
entregar un
sistema final
evolucin
continua del
prototipo mediante
la agregacin de
funciones y
caractersticas
propuestas por el
cliente
prototipos desechables
comprensin de
las necesidades
del cliente
desarrollo de una
definicin
mejorada de los
requerimientos del
sistema
prototipos
centrados en la
experimentacin
de requisitos poco
claros o complejos
problemas
prisas del cliente
(utilizacin del
prototipo como
sistema final
pasar elecciones
debidas al prototipo a
la implementacin
final (entorno,
sistema operativo,...)
estructura deficiente
evolucin del proceso
difcil de gestionar
herramientas y
tcnicas especiales
poco adecuado para
grandes sistemas

escuela superior de ingeniera
informtica
ingeniera del software de
gestin
PROTOTIPADO CON LENGUAJES VISUALES
File Edit Views Layout Options Help
General
Index
Hypertext
display component
Date component
Range checking
script
Tree display
component
12th January 2000
3.876
Draw canvas
component
User prompt
component +
script
fuente: I. Sommerville, Software Engineering, 6th ed.,2000
escuela superior de ingeniera
informtica
ingeniera del software de
gestin
.
Concepto de
operacin
Anlisis de riesgos
An.
Riesgo.
Anlisis de riesgos
Anlisis de riesgos
-
PROGRESO
A TRAVS
DE LAS ITERACIONES
DESARROLLAR, VERIFICAR
PRODUCTO DE SIGUIENTE NIVEL
-
Codificar


PLANIFICAR SIGUIENTE
FASE
Simulaciones, modelos,
pruebas comparativas
Plan de
requerimientos
Plan de ciclo
de vida
Plan de
desarrollo
Plan de integracin
y prueba
REVISIN
Proto-
tipo 1
Prototipo 2
Prototipo 3
Prototipo
operativo
Requerimientos
de software
Validacin de
requerimientos
Diseo del
producto
Diseo de validacin
y verificacin
Diseo
detallado
Prueba de
unidad
Prueba de
integracin
Prueba de
aceptacin
Explotacin
EVALUAR ALTERNATIVAS,
IDENTIFICAR Y
RESOLVER RIESGOS
DETERMINAR
OBJETIVOS,
ALTERNATIVAS Y
RESTRICCIONES
MODELO EN ESPIRAL
propuesto por Barry
Boehm
organizacin en ciclos
primer ciclo:
factibilidad
segundo ciclo:
requerimiento
s
tercer ciclo:
diseo
...
cada ciclo se divide en 4
sectores
definicin de
objetivos,
restricciones
del producto y
proceso, plan
de
administracin
,...
evaluacin y
reduccin de
riesgos (por
ejemplo,
mejor
definicin de
requerimiento
s mediante
prototipos)
desarrollo y
validacin:
eleccin de un
modelo para el
desarrollo
planificacin:
el proyecto se
revisa y se
decide si se
contina con
el siguiente
ciclo. si es as,
se planifica la
siguiente fase
May-14 Ing. de Software
Qu es
la Ing.
de Sw
- 48
Mantenimiento
Diseo del Sistema
Anlisis y Definicin de
Requerimientos
Diseo del programa
Implementacin del
programa
Prueba Unitaria
Prueba de Integracin
Prueba del Sistema
Liberacin del Sistema
P
a
s
o

e
n

e
l

D
e
s
a
r
r
o
l
l
o

d
e

S
o
f
t
w
a
r
e

R
o
l
e
s

d
e

l
o
s

D
e
s
a
r
r
o
l
l
a
d
o
r
e
s

Analista
Diseador
Programador
Tester
Capacitador