Unidad 1

Ingeniera de Software
Unidad 1
Introduccin a la Ingeniera de
Software
Ingeniera en Computacin
Ingeniera de Software 1617B
Unidad 1
Contenido
Software
Importancia
Evolucin
Caractersticas
Dominios de aplicacin
La crisis del software
Causas
Consecuencias por fallas del software
Definiciones de la ingeniera de software
Paradigmas de ciclos de vida de la ingeniera de software
Modelos convencionales
Modelos recientes
Metodologas de desarrollo de software
Metodologas estructuradas
Metodologas orientadas a objetos
Herramientas CASE
La prctica de la ingeniera de software
Ingeniera de software
QU ES EL SOFTWARE?
Unidad 1
Software
Qu es el software?
La suma total de los programas de cmputo,
procedimientos, reglas de documentacin y datos
asociados que forman parte de las operaciones de un
sistema de cmputo [IEEE Computer Society Press, 1993].
Es un producto que disean y construyen los ingenieros
de software. Esto abarca programas que se ejecutan
dentro de una computadora de cualquier tamao y
arquitectura, documentos que comprenden formularios
virtuales e impresos y datos que combinan nmeros y
texto y tambin incluyen representaciones de la
informacin de audio, vdeo e imgenes [Pressman, 2002].
Software
Instrucciones que al codificarse y ejecutarse
proporcionan las caractersticas, funcin y
desempeo buscados
Estructuras de datos que permiten que los
programas manipulen en forma adecuada la
informacin
Informacin descriptiva tanto en papel como
en formas virtuales que describen la
operacin y uso de los programas
LA IMPORTANCIA DEL
SOFTWARE
Importancia del software
Las economas de los pases desarrollados
dependen en gran parte del software.
Ms y ms sistemas son actualmente controlados
por software
El software marca la diferencia. Lo que diferencia
una compaa de otra es la suficiencia, exactitud y
oportunidad de la informacin dada por el software.
Afecta casi todos los aspectos de nuestras vidas ha
invadido nuestro comercio, cultura y actividades
cotidianas
Nos permite construir sistemas complejos en
un tiempo razonable y con alta calidad
Ejemplo:
Dos consultorios dentales, ambos cuentan con los ltimos
modelos de computadora personal y destinadas a apoyar
las tareas y actividades relacionadas con el consultorio.
Pero uno de ellos cuenta con un dispositivo especial
conectado a la computadora y un SOFTWARE para
obtener radiografas de piezas dentales por computadora,
en un par de minutos la muestra radiogrfica est en
pantalla y el mdico puede obtener diferentes vistas de la
placa usando el software. Adems puede establecer una
conexin a travs de internet o va modem para enviar el
archivo de la radiografa a otro colega experto con el fin de
consultar y apoyar el diagnstico, todo esto en la misma
cita. En la forma tradicional la placa radiogrfica esta lista
en un par de das.
Es una tecnologa indispensable en los negocios,
ciencias e ingeniera que dio paso a la creacin de
nuevas ramas de investigacin como la nanotecnologa
y la Ing. Gentica.
El boom de stas se di con la inmersin del Internet a
nuestra vidas, fue el conducto idneo para
promocionarla
Ahora las podemos encontrar incrustadas en Ej.
Transportes, mdicos, telecomunicaciones, militares,
procesos industriales, entretenimiento, productos de
oficina, educacin, ingeniera gentica, etc.
Conforme aumenta su importancia, la comunidad de
programadores ha tratado de desarrollar tecnologas
que hagan mas fcil, rpida y barata la elaboracin de
programas de cmputo de alta calidad
El software tiene un papel dual:
Como producto: brinda el potencial de cmputo incorporado
en el hw de cmputo o redes, ya sea trabajando en un mvil o
en una computadora; es un transformador de informacin
Genricos
Hechos a la medida
Como vehculo: distribuye el producto, acta como la base
de control de la PC (SOs), la comunicacin de informacin
(redes) y la creacin y control de otros programas
(herramientas sw y entornos).
El software distribuye INFORMACIN
Sus capacidades de desarrollo y
caractersticas para contextos particulares no
ha encontrado lmites, pues es gracias al
avance tecnolgico que es capaz de
mejorarse da a dia.
El que posee la informacin y el
conocimiento y hace mejor uso de l, es
el que tiene el poder.
Evolucin del software
Unidad 1
Evolucin del software

Primeros aos (principios de los 50s a mediados de los 60s)
Lo ms importante era el hardware, el software solo era
un aadido a la medida.
El desarrollo del software era un proceso personalizado;
planeado y diseado en la mente de alguien.
Se utilizaba el procesamiento por lotes.
La segunda era (mediados de los 60s a finales de los 70s)
El software se considera un producto que se distribuye
para macro y mini computadoras.
Inicia la industria del software con la idea de desarrollar
el mejor paquete y as ganar mucho dinero.
La multiprogramacin y los sistemas multiusuario
introdujeron nuevos conceptos de interaccin hombre-
mquina.
Surgen los primeros sistemas de gestin de bases de
datos y tambin los sistemas de tiempo real.
El mantenimiento del software comenz a ser algo
crtico.
Unidad 1
Evolucin del software (2)

La tercera era (finales de los 70s principios de los 90s)
Crece considerablemente la presin sobre los
desarrolladores de software.
Se incrementa notablemente la complejidad debido a
los sistemas distribuidos.
Incrementa la demanda de acceso inmediato a los
datos.
El uso personal del software an no era comn.
La cuarta era (principios de los 90s mediados de los 2000?)
La industria del software es considerada la cuna de la
economa del mundo.
Dominan los sistemas cliente/servidor sobre los
centralizados.
Tienen gran auge las tecnologas orientadas a objetos.
Irrumpe con fuerza el Internet y el comercio electrnico.
Sistemas de cmputo personales realmente potentes.
Las redes neuronales artificiales, cmputo paralelo,
algoritmos genticos y sistemas expertos salen de los
laboratorios a aplicaciones prcticas.
Evolucin
Unidad 1
Evolucin del software (3)

En qu era se deberan ubicar
los siguientes?
Cmputo ubicuo
Cmputo mvil
Telfonos inteligentes
Cmputo en la nube
Cmputo GPU
Aplicaciones Web
Redes sociales
Unidad 1
Caractersticas del software

El software al ser un elemento lgico tiene
ciertas caractersticas que lo diferencian
claramente respecto al hardware [Pressman, 2002]. Mortalidad
infantil
Se estropea
El software se desarrolla, no se fabrica en un
ndice de fallos
sentido clsico.
El desarrollo y fabricacin generan un producto
pero desde enfoques diferentes.
El software no se estropea; pero se deteriora. Curva de fallos del hardware
Tiempo
Los fallos del hardware se dan al principio y al

final de su vida, mientras que en el software el
Cambio
mantenimiento dado a lo largo de su vida Incremento del ndice de
introduce nuevos fallos. Fallos por efectos laterales
ndice de fallos
Aunque la industria tiende a ensamblar
componentes, la mayora del software se
construye a la medida.
Esta situacin esta cambiando con el uso ms Tiempo
extendido de la programacin orientada a Curvas de fallos real e
objetos. Idealizado del software
NO SE ESTROPEA!!
Cuando un componente hw se desgasta es sustituido
por una refaccin, en cambio NO HAY REFACCIONES
PARA SW
Cada falla de este indica un error en el diseo o en el
proceso que tradujo el diseo a cdigo ejecutable por la
mquina
Entonces, las tareas de mantenimiento del software, que
incluyen la satisfaccin de peticiones de cambios,
involucran una complejidad considerablemente mayor
que el mantenimiento del HW
Unidad 1
Dominios de aplicacin del

software
Actualmente hay siete categoras de software [Pressman, 2010]
1. Software de sistemas
Conjunto de programas para servir a otros programas.
En general tienen una fuerte interaccin con el hardware, mltiples
usuarios, operacin concurrente, comparticin de recursos, estructuras
de datos complejas, entre otras.
Ejemplos: compiladores, editores, utilidades de gestin de archivos,
controladores, software de redes, etc.
2. Software de aplicacin
Programas aislados que resuelven una necesidad especfica de
negocios.
Procesan datos comerciales o tcnicos para facilitar las operaciones o
toma de decisiones de negocios o tcnicas.
Ejemplos: procesamiento de transacciones en puntos de venta, control
de procesos de manufactura en tiempo real.
3. Software de ingeniera y ciencias
Se ha caracterizado por algoritmos devoradores de nmeros.
Las aplicaciones van desde la astronoma a la vulcanologa, del anlisis
de tensiones en automviles a la dinmica orbital de un transbordador
espacial, de la biologa molecular a la manufactura automatizada.
Unidad 1
Dominios de aplicaciones del

software (2)
Categoras del software
4. Software incrustado
Reside dentro de un producto o sistema y se usa para implementar y controlar
funciones para el usuario final y para el sistema en s.
Ejecuta funciones limitadas y particulares o provee una capacidad de funcionamiento
y control.
Ejemplos: control del tablero de un microondas, funciones digitales en un automvil
como el control de combustible.
5. Software de lnea de productos
Es diseado para proporcionar una capacidad especfica para uso de muchos
consumidores diferentes.
Se centra en un mercado particular o a mercados masivos.
Ejemplos: control de inventario de productos, procesadores de textos, hoja de
clculo, etc.
6. Aplicaciones Web
Llamadas Webapps. Esta categora de software centrado en redes agrupa una
amplia gama de aplicaciones.
Van desde sencillas pginas dinmicas hasta ambientes de cmputo sofisticados
con integracin a bases de datos corporativas y aplicaciones de negocios.
7. Software de inteligencia artificial
Hace uso de algoritmos no numricos para resolver problemas complejos para
los que no son adecuados los anlisis directos.
Ejemplos: sistemas expertos o basados en conocimientos, reconocimiento de
patrones, imgenes, voz, redes neuronales artificiales, etc.
La crisis del sw
Acuado en los aos
70s
Trata el momento en la
historia del desarrollo de
software en la que fueron
tan demandados que no
poda cumplirse en
expectativas, debido a la
complejidad de los
problemas que en su
momento impedan su
realizacin por el escaso
crecimiento tecnolgico
La crisis del sw
finales de los 50s principios de los 60s
la potencia computacional era limitada
proceso de desarrollo artesanal, sin una metodologa
gua
se usaba lenguajes de bajo nivel para el desarrollo
finales de los 60s
potencial de las mquinas en aumento
aparecen lenguajes de programacin de alto nivel
el hardware estaba preparado para tratar con
software ms complejo, esto ltimo no estuvo a su
nivel
La crisis del sw
Se comenz a
percibir al software
como producto, pero
este exceda la
estimacin de costes,
habia retrasos en las
entregas, las
prestaciones no eran
las solicitadas, el
mantenimiento se
hacia
extremadamente
complicado
Se desarrollaba
software de mala
calidad
La crisis del sw
Durante esta etapa, solo del tiempo de desarrollo se
dedicaba a las fases de anlisis, diseo, codificacin y
pruebas; y mas de del tiempo se dedicaba a
correcciones y mantenimiento
Dedicndole poco tiempo al proceso de implementacin
es evidente que se arrastraban errores graves
El conjunto de las fases de anlisis y diseo abarcaban
el 8% del tiempo total de desarrollo de software
El 80% de los errores se producian en estas dos fases,
con lo que se incrementaba el coste de correccin de
errores conforme evolucionaban las fases de manera
bestial
Unidad 1
Causas de la crisis del

software
Muchas de las causas de la crisis del software se pueden encontrar en una
mitologa que surge durante los primeros aos del desarrollo del software.
Se tienen diferentes tipos de mitos segn los involucrados [Pressman, 2002]
De gestin
Los gestores de software normalmente estn bajo la presin de cumplir los
presupuestos, hacer que no se retrace el proyecto y mejorar la calidad; los
mitos le crean la falsa ilusin de una menor presin.
Del cliente
En los clientes que solicitan una aplicacin de software los mitos les crean
falsas expectativas y finalmente quedan insatisfechos.
De los desarrolladores
A pesar de que algunos tiene 50 aos, muchos de estos mitos an estn
vigentes; hay quien sigue pensando que la programacin es un arte.
De los ingenieros de software
Dentro del deseo de contar con prcticas ms disciplinadas puede
provocar querer definir los proyectos de construccin de software de manera
similar a como se definen muchos proyectos de otras ingenieras [Rubby
Casallas].
Unidad 1
Causas de la crisis del software

(2)
Mitos de gestin Realidad
1. Tenemos ya un libro que est 1. Esta bien que el libro exista,
lleno de estndares y pero se usa? se sabe de su
procedimientos para construir existencia? es completo?
software. 2. Ms que computadoras
2. Mi gente dispone de las actualizadas es ms til una
herramientas de desarrollo de herramienta CASE, aunque la
software ms avanzadas, mayora de los desarrolladores
despus de todo, les no las utilizan eficazmente.
compramos las computadoras 3. El desarrollo de software no es
ms modernas. un proceso mecnico y aadir
3. Si fallamos en la programacin ms gente a un proyecto de
podemos aadir ms software normalmente lo
programadores y adelantar el retraza an ms, sobretodo si
tiempo perdido no se ha planificado y
coordinado correctamente.
Unidad 1

(3)
Mitos del cliente Realidad
1. Una declaracin general de los 1. Una mala definicin inicial es
objetivos es suficiente para la principal causa de trabajo
comenzar a escribir los infructuoso. Es esencial una
programas, los detalles los descripcin detallada y formal
daremos ms adelante. del sistema, que solo puede
2. Los requisitos del software lograrse despus de una
cambian constantemente, pero exhaustiva comunicacin con
los cambios pueden adaptarse el cliente.
fcilmente, despus de todo el 2. Es verdad que los requisitos
software es flexible. cambian, pero el impacto vara
segn el momento en que se
60-100x
introduzca
Costo del cambio
1, 5-6x
Despus
1x de la
Desarrollo entrega
Definicin
Impacto del cambio
Unidad 1

(4)
Mitos de los desarrolladores Realidad
1. Una vez que escribimos el programa 1. Cuanto ms pronto se comience a
y hacemos que funcione, nuestro escribir cdigo, ms rpido tardar
trabajo ha terminado. en terminarlo. Los datos industriales
2. Hasta que no tengo el programa indican que entre el 60-80% del
ejecutndose, realmente no tengo esfuerzo dedicado a un programa se
forma de comprobar su calidad. realizar despus de la primera
3. Lo nico que se entrega al terminar entrega al cliente.
el proyecto es el programa 2. Desde el principio del proyecto se
funcionando. pueden aplicar mecanismos para
garantizar la calidad del software
(revisin tcnica formal) y detectar
ciertos defectos.
3. Un programa es solo una parte de
una configuracin de software que
incluye muchos elementos. La
documentacin proporciona un buen
fundamento para un buen desarrollo,
adems de guas para la importante
tarea de mantenimiento.
Unidad 1

(5)
Mitos de los ingenieros de software Realidad
1. Se deben tener todos los 1. Puede que se conozcan de manera
requerimientos del sistema claramente global los objetivos que pretende el
definidos antes de empezar el proyecto software, pero nunca se podr tener el
para que ste sea exitoso. detalle de los requerimientos al inicio
2. Disear completamente antes de del proyecto. Es imposible que el
empezar a programar para que sea ms cliente sepa detalladamente lo que
efectiva la labor de programacin y ms quiere. Los desarrollos incrementales
independiente. contribuyen en la solucin del
3. Para administrar en forma adecuada el problema.
proyecto, se debe tener un plan 2. Es imposible hacer un diseo completo
detallado de todo el proyecto desde el y detallado para un conjunto de
principio. requerimientos incompletos y
ambiguos. Cuando esto sucede se
puede caer en el ciclo programar
corregir. Las metodologas giles
pueden contribuir a la solucin del
problema.
3. Cuando no hay claridad en los
requerimientos y no se puede tener
completos los diseos, es una falacia
pretender planificar en detalle el
proyecto. El plan inicial debe contener
los grandes hitos y estrategias y se
debe detallar en permanentemente
cada vez ms en futuras iteraciones.
Unidad 1

(6)
Y en la formacin profesional de futuros desarrolladores de software?
Tambin existen mitos y problemas a la hora de desarrollar proyectos:
Evaluaciones parciales o de fin de semestre
Estancias o servicio social
Tesis
Por lo regular se trata de problemas de exceso de confianza, planeacin y poca disciplina
Nada ms encuentro como programar esto y ya prcticamente termine
Primero hago que jale y luego documento
Todava tengo tiempo, luego desarrollo los otros mdulos, mientras hago que este se vea bien
apantallador
Si no encuentro cmo, tengo a mi cuate que puede echarme la mano
Buscando en la red seguro encuentro algo ya hecho que me sirva
Con que le pegue en las tardes pero bien y puede que termine antes de tiempo
No hay que preocuparse, en una noche sale
Con esto que desarrolle paso la materia, al fin y los dems tampoco van a terminar
. (la lista es vasta)
Agustn Cernuda del Ro del Departamento de Informtica de la Universidad de Ovideo cita algunos
errores clsicos que influyen en la prdida de control de un proyecto:
Expectativas poco realistas
Hazaas, ilusiones
Planificacin excesivamente optimista
Gestin de riesgos insuficiente
Abandono de planeacin bajo presin
Escatimar en las actividades iniciales y/o en el control de la calidad, a favor de la codificacin
Programacin a destajo
Exceso de requisitos

Ingeniera de software Control insuficiente
Unidad 1
Es importante y apropiado aprovechar

los proyectos de evaluacin parcial o de
fin de semestre, los proyectos de
estancia profesional o servicio social y
los de tesis para que los futuros
desarrolladores de software afronten los
problemas y mitos relacionados con el
desarrollo de software para fomentar una
buena disciplina que les permita un
desempeo profesional exitoso.
Unidad 1
Reflexin
Si no hacen anlisis, hay tabla
Si no disean antes de programar, hay tabla
Si programan sin hacer pruebas, hay tabla
Si no comentan el cdigo, hay tabla
Si no emplean los estndares, hay tabla
Si cuelgan una aplicacin por un ciclo infinito, hay
tabla
Si reportan el mismo error dos veces, hay tabla
Si los casos de uso no estn bien escritos, hay tabla
Si no planean, hay tabla
Si no gestionan proactivamente los riesgos, hay
tabla
Si no versionan, hay tabla
Si preguntan por que todo esto, hay tabla
Unidad 1
Definiciones de ingeniera de
software
La ingeniera de software es el establecimiento y uso de principios
robustos de la ingeniera a fin de obtener econmicamente
software que sea fiable y que funcione eficientemente sobre
mquinas reales [Bauer, 1972].
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].
La ingeniera de software es el estudio de los principios y
metodologas para desarrollo y mantenimiento de sistemas de
software [Zelkovitz, 1978].
Ingeniera de software: (1) La aplicacin de un enfoque
sistemtico, disciplinado y cuantificable hacia el desarrollo,
operacin y mantenimiento del software; es decir, la aplicacin la
de la ingeniera al software. (2) El estudio de enfoques como en (1)
[IEEE, 1993].
La Ingeniera de Software es una disciplina de la Ingeniera que
concierne a todos los aspectos de la produccin de software
[Sommerville, 1995].
Unidad 1
Paradigmas de ciclos de vida

de la ingeniera de software
Cuando no se sigue un ciclo de vida y apenas se planea, se
tiende a seguir el enfoque de codificar y probar lo que genera:
una alta probabilidad de falla en el software, poca flexibilidad
para modificaciones, no satisfacer plenamente los requisito y
descontento de los clientes [Piattini].
Qu es un ciclo de vida:
Un modelo de ciclo de vida es un marco de referencia que
contiene los procesos, las actividades y las tareas involucradas
en el desarrollo, la explotacin y el mantenimiento de un
producto de software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso
[ISO/IEC 12207-1].
Ciclo de vida del software es una aproximacin lgica a la
adquisicin, suministro, el desarrollo, la explotacin y el
mantenimiento del software [IEEE 1074].
Unidad 1
Paradigmas de ciclos de vida de la

ingeniera de software (2)
Algunas de las ventajas que aporta el enfoque de ciclo de vida
[Piattini]:
En las primeras fases, aunque no haya lneas de cdigo, pensar el
diseo es avanzar en la construccin del sistema, pues
posteriormente resulta ms fcil la codificacin.
Asegura un desarrollo progresivo, con controles sistemticos, que
permite detectar precozmente los defectos.
Se controla el sobrepasar los plazos de entrega y los costes
excesivos mediante un adecuado seguimiento del progreso.
La documentacin se realiza de manera formal y estandarizada
simultneamente al desarrollo, lo que facilita la comunicacin
interna entre el equipo de desarrollo y la de ste con los usuarios.
Tambin aumenta la visibilidad y posibilidad de control para la
gestin del proyecto.
Supone una gua para el personal de desarrollo, marcando las
tareas a realizar en cada momento.
Minimiza la necesidad de rehacer el trabajo y los problemas de
puesta a punto.
Unidad 1
Paradigmas de ciclos de vida de la

ingeniera de software (3)
Actividades agrupadas en procesos que se pueden realizar
durante el ciclo de vida del software [ISO 12207-1].
PROCESOS PRINCIPALES PROCESOS DE SOPORTE
DOCUMENTACIN
ADQUISICIN
GESTIN DE LA CONFIGURACIN
SUMINISTRO ASEGURAMIENTO DE LA CALIDAD
VERIFICACIN
VALIDACIN
EXPLOTACIN
REVISIN CONJUNTA
DESARROLLO
AUDITORIA
MANTENIMIENTO
RESOLUCIN DE PROBLEMAS
PROCESOS DE LA ORGANIZACIN
GESTIN INFRAESTRUCTURA
MEJORA FORMACIN
Unidad 1
Ciclos de vida convencionales

Modelo secuencial (clsico)
Anlisis de los requisitos del software
Se debe comprender el dominio de la informacin, la funcin requerida, comportamiento,
rendimiento e interconexin.
Diseo
Proceso de muchos pasos centrado en cuatro atributos: estructura de datos, arquitectura
de software, representacin de la interfaz y detalle procedimental.
Generacin de cdigo
El diseo es traducido a formato legible por la mquina.
Pruebas
Deteccin de errores y asegurar que una entrada definida produce resultados esperados.
Mantenimiento
Cambios en el software que implican aplicar todos los pasos precedentes en orden.
Ingeniera de
sistemas de informacin
Anlisis Diseo Cdigo Prueba
Unidad 1

(2)
Modelo en cascada
Es una adaptacin del modelo secuencial
Sin embargo el modelo secuencial y cascada han sido criticados en varios aspectos:
No refleja el proceso real de desarrollo de software, por ejemplo cuando hay
redefinicin de requisitos en la fase de codificacin.
Se tardar mucho tiempo en pasar por todo el ciclo.
Acenta los problemas con el usuario final
Anlisis de
Requisitos
del Sistema
Anlisis de
Requisitos
del Software
Diseo
Preliminar
Diseo
Detallado
Codificacin
y Pruebas
Explotacin
y
Mantenimiento
Unidad 1

(3)
Modelo de construccin de prototipos
Paradigma:
Inicia con la recoleccin de requisitos
Se hace un diseo rpido de aspectos visibles para el cliente/usuario para generar un
prototipo.
El prototipo lo evala el cliente/usuario para refinar los requisitos.
Pudiera presentar problemas debido a:
El cliente solo ve el sistema por fuera y no la calidad por dentro; el mantenimiento no
es prioridad cuando se desarrolla rpido.
El desarrollador, con frecuencia, hace uso de las herramientas ms a la mano no de las
ms apropiadas.
Construir/revisar
la maqueta
Escuchar
al cliente
El cliente
prueba
la maqueta
Unidad 1

(4)
Modelo incremental
Combina elementos de los modelos secuencial, cascada y prototipos.
El sistema de software se crea aadiendo componentes funcionales, cada paso se
actualiza el sistema hasta cumplir con los requisitos.
Este modelo se ajusta ms a la incertidumbre del incremento de requisitos, sin
embargo persiste el problema para determinar si los requisitos son vlidos.
Anlisis de
Requisitos
del Sistema
Anlisis de
Requisitos
del Software Incremento 1
Diseo
Preliminar
Diseo
Detallado
Incremento 2 Codificacin
y Pruebas
Diseo Explotacin
Detallado y
Codificacin
Mantenimiento
Incremento n y Pruebas
Explotacin
y
Mantenimiento
Unidad 1

(5)
Modelo espiral
Evaluar alternativas, identificar
Anlisis y resolver los riesgos
de riesgos
Determinar: objetivos,
alternativas, restricciones Anlisis
de riesgos
Anlisis
de riesgos Prototipo
Prototipo 3 Operativo
Anlisis Prototipo 2
de
riesgos Prototipo 1
Simulaciones, modelos, benchmarks

Plan de Requisitos
Concepto de
Plan de Ciclo de Vida
operacin
Diseo
Requisitos detallado
Diseo
de software
Producto
Plan de desarrollo Validacin de Cdigo
SW
Requisitos
Pruebas
Unitarias
Plan de Integracin
Verificacin y Validacin
y Pruebas
del diseo Integracin
Planificar las fases siguientes Prueba y Prueba
de
Implementacin
Aceptacin Desarrollar, Verificar el
producto del siguiente nivel
Unidad 1

(6)
Modelo espiral
Paradigma
Combina los modelos secuencial y prototipos
Cada ciclo inicia con la identificacin de objetivos (ej. Rendimientos, funcionalidad),
alternativas principales de implementacin de esa porcin del producto (ej. Usar el
diseo A, reutilizar el mdulo X) y las restricciones para cada alternativa (ej.
Interfaces, costo).
El siguiente paso es evaluar las diferentes alternativas en funcin de los objetivos y
restricciones. Si existen riesgos se deben prevenir formulando una estrategia
(prototipos, simulacin).
Despus se revisan los resultados del anlisis de riesgos.
El siguiente paso consiste en planificar la fase posterior.
Una vez terminado el primer ciclo se volvera a empezar.
Cada ciclo se completa con una revisin de todos los productos generados durante
el ciclo.
Este modelo tambin presenta ciertas dificultades:
Cuando se debe subcontratar no se tiene la misma flexibilidad para ajustarse a
acuerdos por etapa, resolver caminos crticos, ajustar niveles de esfuerzo, etc.
Necesidad de contar con expertos en evaluacin de riesgos para identificar y
manejarlos.
Unidad 1
Modelos recientes (2)

Desarrollo basado en componentes
Incorpora muchas caractersticas del modelo espiral.
Configura aplicaciones desde componentes preparados de software
(clases).
Conduce a la reutilizacin del software.
Identificar
componentes
Anlisis candidatos
Planificacin
de riesgos
Construir Buscar
la Iteracin componentes en
del sistema la biblioteca
Comunicacin
con el cliente
Poner nuevos Extraer
componentes en componentes
la biblioteca si estn
disponibles
Extraer
componentes
Evaluacin si no estn
del cliente disponibles
Construccin y
adaptacin de la ingeniera
Unidad 1

Horas-hombre
Proceso unificado (UP) Workflow Incremento A Incremento B Incremento C Incremento D

de los requisitos
Caractersticas principales:
Workflow
Dirigido por casos de uso del anlisis
Centrado en la arquitectura
Workflow
Iterativo e incremental del diseo
Soporta el estndar UML Workflow de la
Se plantea un desarrollo por Implementacin
incrementos aplicando workflows Workflow
(flujo de trabajo) de requisitos, de pruebas
anlisis, diseo, implementacin y Tiempo
pruebas, presentes a lo largo del Horas-hombre
todo el ciclo de vida, sin embargo a Iteracin B.1 Iteracin B.2 Iteracin B.3
veces un workflow predomina ms de losWorkflow
requisitos
sobre los otros cuatro.
Workflow
Las iteraciones se dan dentro de los del anlisis
incrementos, el nmero de estas Workflow
varia dependiendo del incremento, y del diseo
en cada iteracin tambin se deben
repetir los cinco workflow. Workflow de la
Implementacin
Workflow
de pruebas
Tiempo
Unidad 1

Programacin extrema XP
Disciplina de desarrollo de software creada por Kent Beck para proyectos cortos con
requerimientos cambiantes o poco claros (respaldada por gran parte de la industria y
rechazada por otro tanto).
Se basa en la simplicidad, la comunicacin y el reciclado contino de cdigo.
Pretende:
La satisfaccin del cliente
Potenciar al mximo el trabajo en grupo
Reducir el costo del cambio en las etapas de vida del sistema
Combinar las que han demostrado ser las mejores practicas de desarrollo de software y llevarlas al
extremo.
Establece cuatro variables
Coste
Tiempo
Calidad
mbito
Plantea cuatro valores
Comunicacin
Sencillez
Retroalimentacin
Valenta
Define cuatro actividades bsicas
Codificar
Hacer pruebas
Escuchar
Disear
Metodologias vs ciclo de vida
Una metodologa puede seguir uno o varios
modelos de ciclo de vida, es decir, el ciclo
de vida indica qu es lo que hay que
obtener a lo largo del desarrollo
del proyecto pero no cmo hacerlo.
La metodologa indica cmo hay que
obtener los distintos productos parciales
y finales
Unidad 1
Metodologas de desarrollo de
software
Considerando una metodologa como un conjunto
de pasos y procedimientos que deben seguirse para
desarrollar software, entre otras, se tienen:
Proponen la creacin de modelos del sistema que
representen a los procesos, los flujos y las estructuras de
los datos de una manera descendente.
Metodologas orientadas a objetos
Trata a los procesos y los datos de forma conjunta,
agrupando as tanto la informacin como el procesamiento
(objetos).
Metodologas para sistemas de tiempo real
La informacin se procesa, ms orientada al control que a
los datos, en funcin del tiempo.
Unidad 1
Pasan de una visin general del problema (abstraccin cercana a las
personas) hasta llegar a un nivel de abstraccin ms sencillo
(abstraccin cercana al hardware).
Esta visin se puede enfocar en las funciones del sistema, estructura
de los datos o ambos, lo que da lugar a las siguientes metodologas:
Orientadas a los procesos
Se centra en la transformacin de los datos de entrada para generar la salida
esperada.
Orientadas a los datos
Estructuras de datos jerrquicas
Se centran en las entradas y salidas; primero se definen las estructuras de datos y, a
partir de stas, se derivan los componentes procedimentales.
Estructuras de datos no jerrquicas
Los tipos de datos son el corazn del sistema ya que son ms estables que los
procesos.
Mixtas
Se enfocan tanto en el proceso como en los datos tomando desde diversos
puntos de vista.
Unidad 1
(2)
Existen diversas metodologas estructuradas:
Orientadas a procesos:
De Marco.
Gane y Sarson
Yourdon/Constantine
Orientadas a datos jerrquicos
JSP y JSD
LCP
Orientadas a datos no jerrquicos
IE
Metodologas mixtas
Merise
SSADM
Mtrica
Las especificaciones estructuradas utilizan:
DFD (Diagramas de flujo de datos, Dataflow Diagram)
Diagramas E-R (Entidad-Relacin), o alternativamente DED (Diagramas de Estructura de Datos)
Diagramas HVE (Historia de vida de las entidades)
Diagramas de transicin de estados (STD, State Transition Diagram)
Diccionario de datos
Especificacin de procesos
Lenguaje estructurado
Pre y post condiciones
Tablas y rboles de decisin
Diagramas de estructura
Unidad 1
Metodologas orientadas a
objetos
De forma general:
El dominio del problema se caracteriza mediante un conjunto de objetos con
atributos y comportamientos especficos.
Los objetos son manipulados mediante una coleccin de mtodos y se
comunican mediante un protocolo de mensaje.
Los objetos son clasificados en clases y subclases.
Se retoman muchas de las ideas de las metodologas estructuradas
pero con el apoyo de lenguajes orientados a objetos.
En los 90s haba diversos enfoques orientados a objetos:
Booch
Rumbaugh
Jacobson
Otros ms (Shaler y Mellor, Coleman)
En el 95 comienza el mtodo unificado (Booch, Rumbaugh).
El mismo ao se une Jacobson
Nace Rational Rose
De ah surge UML aceptado por el OMG
(Object Management Group) en el 97
Unidad 1
Metodologas orientadas a
objetos (2)
Actualmente las especificaciones orientadas a objetos utilizan el lenguaje
estndar predominante UML (Unified Modeling Lenguage) el cual combina
notaciones provenientes desde:
Modelado orientado a objetos
Modelado de datos
Modelado de componentes
Modelado de flujos de trabajo (workflows)
Los diagramas que expresan grficamente las partes de un modelo son:
Herramientas CASE
CASE
Computer Aided Software Engineering
Ingeniera de software asistida por computadora
Proporcionan la posibilidad de automatizar

actividades manuales de la ingeniera de software
ayudando a garantizar que la calidad sea diseada
antes de construir el producto [Pressman].
Herramientas CASE (2)
Este enfoque de construir software persigue mejorar
la calidad y la productividad planteando los
siguientes objetivos [Piattini]:
Aplicacin prctica de metodologas de desarrollo de
software
Facilitar la realizacin de prototipos y y el desarrollo
conjunto de aplicaciones
Simplificar el mantenimiento de los programas
Mejorar y estandarizar la documentacin
Aumentar la portabilidad de las aplicaciones
Facilitar la reutilizacin de componentes software
Desarrollo y refinamiento visual utilizando grficos
Componentes de una herramienta CASE

Categoras de herramientas CASE
Existen numerosas clasificaciones, Piattini propone la
siguiente:
Inconvenientes por los cuales se han abandonado algunas herramientas CASE:
Deficiencias de la propia tecnologa
Soporte parcial del ciclo de vida
Incompatibilidad entre herramientas, inclusive entre versiones propias
Escasa integracin entre diferentes herramientas
Poca confianza entre vendedor/distribuidor
Escasa e inadecuado documentacin generada
Gran abundancia de herramientas
Funcionamiento deficiente en entornos multiusuario
Poca capacidad de adaptacin de los usuarios
Son costosas
Incorrecta implantacin
Solo soportan una metodologa (ej. Sistemas de gestin o de tiempo real)
No siempre soportan la tcnica ms adecuada
Funcionan o para proyectos pequeos o grandes
Se centran mucho en aspectos tcnicos dejando de lado aspectos de gestin
Deficiencias de la propia organizacin
Actitud (falsas expectativas)
Infravaloracin del esfuerzo requerido
Inconsistencia de herramientas respecto al nivel de madurez de la organizacin
Inadecuada capacitacin de los usuarios
No medir la productividad ni la rentabilidad que resulten de la aplicacin de la tecnologa.
Herramientas CASE
Ejemplos:
Microsoft Project: es un software
de administracin de proyectos diseado, desarrollado y
comercializado por Microsoft para asistir a administradores de
proyectos en el desarrollo de planes, asignacin de recursos a
tareas, dar seguimiento al progreso, administrar presupuesto y
analizar cargas de trabajo.
Rational Rose es una herramienta

de produccin y comercializacin establecidas por Rational
Software Corporation (actualmente parte de IBM). Rose es un
instrumento operativo conjunto que utiliza el Lenguaje Unificado
(UML) como medio para facilitar la captura de dominio de
la semntica, la arquitectura y el diseo.
Herramientas CASE
Jdeveloper: Este magnfico entorno integrado
desarrollado por Oracle trabaja con la ingeniera inversa,
es decir primero se crea l cdigo y despus el
diagrama.
MagicDraw: es una herramienta de modelaje con
completas caractersticas UML, sin duda es una de las
mejores herramientas CASE del mercado, que procura
mantenerse adems siempre al da con continuas
actualizaciones. Es desarrollada por No Magic, Inc.
Implementada totalmente en JAVA.
Herramientas CASE
Otras:
Visual paradigm
Microsoft Visio
Enterprise Architect
BoUML
CASEStudio
ArgoUML
Poseidon
EasyCASE
ERwin
La prctica de la ingeniera de
software
How to Solve It [Polya, 1945]
Simple sentido comn para resolver un problema.
Sin embargo, el problema est en que el sentido
comn es poco comn en el mundo del software
[Pressman, 2010].
La esencia de la solucin de problemas:
1. Entender el problema (comunicacin y anlisis)
2. Planear la solucin (modelado y diseo del
software)
3. Ejecutar el plan (generacin del cdigo)
4. Examinar la exactitud del resultado
En el contexto de la ingeniera de software, estas
etapas de sentido comn conducen a una serie
de preguntas esenciales.
software (2)
Entender el problema
Escuchamos por unos segundos y despus pensamos:
claro, s, entiendo, resolvamos esto. Ser esto correcto?,
o valdr la pena tomarse un poco ms de tiempo a
resolver estas preguntas:
Quines tienen que ver con la solucin del problema?, es
decir, Quines son los participantes?
Cules son las incgnitas?, Cules son las funciones y
caractersticas que se requieren para resolver el problema
en forma apropiada?
Puede fraccionarse el problema?, Es posible
representarlo con problemas ms pequeos que sean ms
fciles de entender?
Es posible representar grficamente el problema?,
Puede crearse un modelo del anlisis?
software (3)
Planear la solucin
Despus de entender el problema (o al menos eso se
supone) y ya queremos escribir cdigo. La cosa es
calmada, antes habr que hacer un diseo.
Ha visto antes problemas similares?, Hay patrones
reconocibles en una solucin potencial?, Hay algn
software existente que implemente los datos, las funciones
y caractersticas que se requieren?
Ha resuelto un problema similar? Si es as, son
reutilizables los elementos de la solucin?
Pueden definirse problemas ms pequeos? Si as fuera,
hay soluciones evidentes para stos?
Es capaz de representar una solucin en una forma que
lleve a su implementacin eficaz?, Es posible crear un
modelo del diseo?
software (4)
Ejecutar el plan
El diseo creado sirve como un mapa de carreteras para el
sistema que se quiere construir. Puede haber desviaciones
inesperadas y puede que encontremos un camino mejor a
medida que avanza, pero el plan nos permitir proceder
sin perdernos.
Se ajusta la solucin al plan?, El cdigo fuente puede
apegarse al modelo del diseo?
Es posible que cada parte componente sea una solucin
correcta?, El diseo y cdigo se han revisado, o mejor
an, se han hecho pruebas respecto a la correccin del
algoritmo?
software (5)
Examinar el resultado
No se puede estar seguro de que la solucin sea
perfecta, pero si de que se ha diseado un
nmero suficiente de pruebas para descubrir
tantos errores como sea posible.
Puede probarse cada parte componente de la
solucin?, Se ha implementado una estrategia
razonable para hacer pruebas?
La solucin produce resultados que se apegan a los
datos, funciones y caractersticas que se requieren?,
El software se ha validado contra todos los
requerimientos participantes?

Unidad 1

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Unidad 1

Caricato da

Copyright:

Formati disponibili

Ingeniera de Software

Evolucin del software

Evolucin del software (2)

Evolucin del software (3)

Caractersticas del software

El software se desarrolla, no se fabrica en un

Los fallos del hardware se dan al principio y al

Dominios de aplicacin del

Dominios de aplicaciones del

Causas de la crisis del

Causas de la crisis del software

Causas de la crisis del software

Causas de la crisis del software

Causas de la crisis del software

Causas de la crisis del software

Es importante y apropiado aprovechar

Paradigmas de ciclos de vida

Paradigmas de ciclos de vida de la

Paradigmas de ciclos de vida de la

SUMINISTRO ASEGURAMIENTO DE LA CALIDAD

Ciclos de vida convencionales

Anlisis Diseo Cdigo Prueba

Ciclos de vida convencionales

Ciclos de vida convencionales

Ciclos de vida convencionales

Ciclos de vida convencionales

Simulaciones, modelos, benchmarks

Ciclos de vida convencionales

Modelos recientes (2)

Modelos recientes (3)

Proceso unificado (UP) Workflow Incremento A Incremento B Incremento C Incremento D

pruebas, presentes a lo largo del Horas-hombre

Modelos recientes (4)

Proporcionan la posibilidad de automatizar

Componentes de una herramienta CASE

Rational Rose es una herramienta

Potrebbero piacerti anche