(Microsoft PowerPoint - 1 introd

Vista previa del material en texto

CAPITULO ICAPITULO I
1.1 CONCEPTOS BASICOS
Resumen preparado por Miguel Cotaña
Ingeniería del Software
INF - 163
Mg. Sc. Miguel Cotaña M.
mickycotana@gmail.com
La Paz - Bolivia
CONTENIDOCONTENIDO
1. Introducción 
2. Modelos ágiles
3. Ingeniería Web
4. Formulación y planeación
5. Modelado de análisis
6. Modelado de diseño
7. Pruebas IWeb
1. Introducción 
2. Modelos ágiles
3. Ingeniería Web
4. Formulación y planeación
5. Modelado de análisis
6. Modelado de diseño
7. Pruebas IWeb
Método:Método:
Procedimiento para alcanzar un determinado fin
Los métodos de la I.S. indican “cómo”
construir técnicamente el software.
Metodología:Metodología:
En un proyecto de desarrollo de software la 
metodología define Quién debe hacer Qué, 
Cuándo y Cómo debe hacerlo
Procedimiento:Procedimiento:
Método de ejecutar algunas cosas
1. INTRODUCCION1. INTRODUCCION
Proceso:Proceso:
Conjunto de las fases sucesivas de un 
fenomeno natural o de una operación artificial
Una secuencia de pasos desarrollados para un 
proposito dado (por ejemplo, el proceso de 
desarrollo de software).
Herramientas:Herramientas:
Las herramientas de la I.S. proporcionan un 
enfoque automático o semi-automático para el 
proceso y para los métodos
Modelo:Modelo:
Es la representación formal de un sistema
SISTEMASSISTEMAS
Intuitivamente decimos que cuando 
no hay “Sistema” se produce el:
““Efecto 2+2=3Efecto 2+2=3””
Enfoque de sistemasEnfoque de sistemas
Vision sistémica:Vision sistémica:
La visión sistémica nos ayuda a ““verver”” el el 
todotodo, apreciar su energía y descubrir sus 
caractercaracteríísticas distintivassticas distintivas, aquellas que 
son propias del conjuntopropias del conjunto y que no 
existen en las partes. 
Esta visión permite ubicar al sistema en 
su entornoentorno o realidado realidad dinámica, integral, 
compleja e incierta, entre otras 
características.
Pensamiento sistemico:Pensamiento sistemico:
“El pensamiento sistémico es la 
disciplinadisciplina que integra las demintegra las demáás ramass ramas, 
fusionándolas en un todo coherente de 
teoría y práctica. .....Al enfatizar cada 
una de las demás disciplinas, el 
pensamiento sistémico nos recuerda 
continuamente que el todo puede el todo puede 
superar la suma de las partessuperar la suma de las partes”, Peter
Senge
““Efecto 2+2=5Efecto 2+2=5””
Definiciones de SistemaDefiniciones de Sistema
Se origina en la palabra griega sunistsunistáánainai, que 
significa: causa que mantiene la unidadcausa que mantiene la unidad.
Conjunto de reglas o principiosreglas o principios sobre una 
materia enlazados entre senlazados entre síí. 
Conjunto de cosas que ordenadamente y 
relacionadas entre sí, contribuyen a 
determinado objetivoobjetivo. (Diccionario de la RAE)
Sistema es cualquier procesoproceso que convierte 
inputs en outputs. (H. Eisner)
¡¡ESTE ES UN SISTEMA!ESTE ES UN SISTEMA!
• Hay un conjunto de elementos : : las piedraspiedras
• Están interrelacionados interrelacionados entre sí : : la posiciposicióón relativa entre n relativa entre 
ellasellas
• Tienen un objetivo comobjetivo comúún : trasmitir n : trasmitir una informaciinformacióónn
•• Alguien necesita resolver una necesidad o problemaAlguien necesita resolver una necesidad o problema
SISTEMASSISTEMAS
INGENIERIAINGENIERIA
INGENIERIAINGENIERIA
DEDE
SISTEMASSISTEMAS
Ingeniería de Sistemas
(Ingenierizar un sistema)
Ingeniería de Sistemas
(Origen teórico-científico)
++
““INGENIERINGENIERÍÍA DE SISTEMASA DE SISTEMAS””
•• COMPONENTESCOMPONENTES
•• INTERRELACIONES internasINTERRELACIONES internas
•• INTERRELACIONES con sistema INTERRELACIONES con sistema 
superiorsuperior
•• OBJETIVO COMOBJETIVO COMÚÚNN
•• FORMULACION del PROBLEMAFORMULACION del PROBLEMA
•• MODELOS REPRESENTATIVOSMODELOS REPRESENTATIVOS
•• ALTERNATIVAS de SOLUCIALTERNATIVAS de SOLUCIÓÓNN
•• VALIDACIVALIDACIÓÓN por N por 
EXPERIMENTACIONEXPERIMENTACION
TEORTEORÍÍA DE A DE 
SISTEMASSISTEMAS
BertalanffyBertalanffy
METODO METODO 
CIENTCIENTÍÍFICOFICO
GalileoGalileo
� “El disediseññoo, producciproduccióónn y mantenimientomantenimiento de sistemas 
dentro de las restriccionesrestricciones de costo y tiempocosto y tiempo”, Sage
(1992)
� “Una aproximaciaproximacióón interdisciplinarian interdisciplinaria para 
posibilitar la realización de sistemas exitosos” INCOSE. 
(1999)
� “Las acciones tacciones téécnicas y de controlcnicas y de control asociadas a los 
procesos de desarrolloprocesos de desarrollo de un sistema y sus sistema y sus 
capacidadescapacidades” R. Stevens, P. Brook y S. Arnold.
Definicion de Ingenieria de Sistemas:Definicion de Ingenieria de Sistemas:
� Conozca el problema, el cliente y el usuario del 
sistema
� Use criterios de efectividad basados en las 
necesidades
� Establezca y administre los requerimientos
� Identifique y evalúe distintas alternativas de solución
� Verifique y valide los requerimientos y el desempeño
� Mantenga la integridad del sistema
� Use un proceso estructurado y documentado
Principios de la Ingenieria de Sistemas:Principios de la Ingenieria de Sistemas:
Esfuerzos InnecesariosEsfuerzos Innecesarios
Cumplir con los Principios
de Ingeniería de Sistemas podría evitar: 
Cumplir con los Principios
de Ingeniería de Sistemas podría evitar: 
########¿¿¿¿¿¿¿¿?{[/&#?{[/&#?{[/&#?{[/&#?{[/&#?{[/&#?{[/&#?{[/&#
FustracionesFustraciones
Cumplir con los Principios
de Ingeniería de Sistemas podría evitar: 
DesprestigioDesprestigio
SoftwareSoftware
El software se forma con:
Las instrucciones (programas de 
ordenador) que cuando se ejecutan
proporcionan las características, 
funciones y el grado de comportamiento
deseado;
Las estructuras de datos que permiten
que los programas manipulen
adecuadamente la información;
Los documentos que describen la 
operación y el uso de los programas
Características:Características:
El software se desarrolla o construye, 
no se manufactura en sentido clásico
(a pesar de las similitudes entre el 
desarrollo de Sw y la manufactura del 
Hw, ambas son diferentes);
El software no se desgasta, pero se 
deteriora (cuando un componente del 
Hw se desgasta se sustituye con un 
repuesto. Pero en Sw no existen
repuestos). El software es inmune a 
los males ambientales (polvo, 
vibración, temperatura);
Curva de fallos de HardwareCurva de fallos de Hardware
TiempoTiempoTiempoTiempo
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
Defectos fabricación
(ej: mortalidad infantil)
Estropeado
(desgaste)
Obsolescencia
Curva real de fallos de SoftwareCurva real de fallos de Software
TiempoTiempoTiempoTiempo
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
In
d
ic
e
 d
e
 f
a
ll
o
s
Defectos fabricaciDefectos fabricaciDefectos fabricaciDefectos fabricacióóóónnnn
Curva ideal
Cambio Cambio Cambio
Cu
rva
 
rea
lObsolescencia
A pesar de que la industria tiene una
tendencia hacia la construcción por
componentes, la mayoría del software aún
se construye a medida. 
Un componente Hw (tornillo) se puede
reutilizar.
Un componente de Sw se debe diseñar e 
implementar de forma que pueda utilizarse
en muchos programas (creación de 
ventanas gráficas, menús desplegables) 
diferentes (encapsulan tanto los datos como
el proceso)
Categorias del SoftwareCategorias del Software
Software de sistemas
Software de aplicación
Software científico y de ingeniería
Software empotrado
Software de línea de productos
Software basadas en Web
Software de Inteligencia Artificial
La construcción del software de 
ordenador es un proceso iterativo
de aprendizaje y el resultado es
una materialización del 
conocimiento recolectado, 
depurado y organizado conforme
el proceso estuvo en ejecución
EL PROCESOEL PROCESO
Existen mecanismos de evaluación del 
proceso de software que permiten a las
organizaciones determinar la 
“madurez” del proceso de software. 
No obstante, la calidad, el tiempo
requerido, laviabilidad a largo plazo
del producto que se construye son los 
mejores indicadores de la eficacia del 
proceso que se utiliza.
Tres aspectos del procesoTres aspectos del proceso
1.- Definición del proceso
Un proceso debe estar definido (documento que
especifica actividades y procedimientos del 
proceso)
2.- Aprendizaje del proceso
El conocimiento del proceso debe ser 
transferido a las personas (agentes) que lo 
ejecutarán
3.- Resultados del proceso
Manifestación de los productos, como resultado
de la ejecución de las actividades definidas por
el proceso
Consideraciones acerca de los procesosConsideraciones acerca de los procesos
Los comportamientos, actividades y 
tareas que desempeñamos para lograr
un objetivo representan la ejecución 
del proceso para alcanzar dicho
objetivo.
Un proceso disciplinado se 
manifestará en patrones ordenados y 
consistentes de comportamiento
individual o grupal
Por tanto, un proceso da forma a las
acciones y reacciones y tomamos
frente a una determinada situación.
Proceso internalizado y proceso institucionalizadoProceso internalizado y proceso institucionalizado
Cuando un proceso es desarrollado
profesional y naturalmente por una
persona, se dice que el proceso esta
“internalizado” por la persona.
En las organizaciones los procesos
son comunes a grupos de personas. 
Para obtener disciplina en los procesos, 
estos deben ser establecidos como
“institucionalizados” en la 
organización.
Ingenieria del softwareIngenieria del software
[Ingeniería de software es] el 
establecimiento y uso de principios
de ingeniería adecuados para obtener
económicamente software que sea 
confiable y trabaje eficientemente en 
máquinas reales (Fritz Bauer)
teoria practica
Resolucion
de 
problemas
Administracion
y gestion
Pruebas y
control de
calidad
DefinicionDefinicion
La ingeniería de software no es ciencia
informática.
“Un científico construye con el objetivo de 
aprender, un ingeniero aprende con el objetivo
de construir”
La distinción entre ingeniería y ciencia
en el software es el mismo que en otras
disciplinas
“Los científicos aprenden lo que es verdadero y 
cómo extender el conocimiento en su campo”
“Los ingenieros aprenden lo que es verdadero, lo 
que es útil y cómo aplicar conocimiento bién
entendido para resolver problemas prácticos”
Científicos
� Conocimientos enfocados y especializados
� Reportan básicamente a sus colegas científicos
� No necesitan licencia
Ingenieros
� Conocimientos comprobados, efectivos y confiables
de ámbito más general
� Se necesita un amplio entendimiento de todos los 
factores que intervienen en el desarrollo del producto.
� Responsabilidad con el publico
� Generalmente necesitan licencia para ejercer
Ingenieria del software: tecnologia estratificadaIngenieria del software: tecnologia estratificada
Definicion segun el IEEEDefinicion segun el IEEE
La ingenieria de software es la 
aplicación de un enfoque sistemático, 
disciplinado y cuantificable al 
desarrollo, operación y mantenimiento
del software; es decir, la aplicación de 
la ingeniería al software
La I.S. es una tecnología estratificadaLa I.S. es una tecnología estratificada
Cualquier enfoque de la ingeniería debe
estar sustentado en un compromiso con 
la calidad.
La gestión de la calidad Total, Sigma 
Seis y enfoques similares fomentan una
cultura de mejora continua del proceso, 
y es esta cultura la que al final conduce 
al desarrollo de enfoques muy efectivos
para la I.S.
El enfoque de calidad soporta a la I.S.El enfoque de calidad soporta a la I.S.
Software EngineeringIngeniería de Software
enfoqueenfoque de de ““calidadcalidad””
modelomodelo de de procesoproceso
mméétodostodos
herramientasherramientas
MARCO DE TRABAJO PARA EL PROCESOMARCO DE TRABAJO PARA EL PROCESO
Un marco de trabajo establece la base 
para un proceso de software completo al 
identificar un numero pequeño de 
actividades del marco de trabajo 
aplicables a todos los proyectos de 
software, sin importar su tamaño y 
complejidad.
Abarca un conjunto de actividades 
sombrilla aplicables a lo largo del 
proceso del software.
Cada actividad dentro del marco de 
trabajo contiene un conjunto de 
acciones de ingeniería del software; es 
decir, una serie de tareas relacionadas 
que produce un producto del trabajo en 
la I.S. (por ejemplo, el diseño es una 
acción de la I.S.). 
Cada acción la forman tareas de trabajo 
individuales que completan alguna parte 
del trabajo implicado por la acción.
Marco de trabajo del proceso de softwareMarco de trabajo del proceso de software
Actividades sombrilla
Marco de trabajo del proceso
Actividad del marco de trabajo #1
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Accion de la ingenieria de software # 1.k
Accion de la ingenieria de software # 1.1
Conjunto
de tareas
.
Conjunto
de tareas
.
.
Actividad del marco de trabajo #n
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Accion de la ingenieria de software # n.m
Accion de la ingenieria de software # n.1
Conjunto
de tareas
.
Conjunto
de tareas
.
.
Aplicacion del marco de trabajo en proyectosAplicacion del marco de trabajo en proyectos
Comunicación. Implica una intensa colaboración 
y comunicación con los clientes; 
Planeación. Establece un plan para el trabajo de 
la ingeniería del software. Describe las tareas
técnicas, los riesgos probables, etc. 
Modelado. Abarca la creación de modelos que
permiten al desarrollador y al cliente entender
mejor los requisitos del software y el diseño.
Construcción. Esta actividad combina la 
generación del codigo y la realización de pruebas
necesarias para descubrir errores en el código.
Despliegue. Se entrega al cliente, quién evalua
el producto recibido y proporciona información
basada en su evaluación.
Los modelos prescriptivos de proceso 
se propusieron originalmente para 
ordenar el caos del desarrollo de 
software. Estos modelos 
convencionales han traído consigo 
cierta cantidad de estructuras útiles.
El trabajo de la IS y el producto 
resultante aún permanecen “al borde 
del caos”
MODELOS PRESCRIPTIVOSMODELOS PRESCRIPTIVOS
Los modelos prescriptivos de proceso 
definen un conjunto distinto de 
actividades, acciones, tareas 
fundamentos y productos de trabajo 
que se requieren para desarrollar 
software de alta calidad.
Estos modelos son una guía para el 
trabajo de la IS.
Los modelos prescriptivos de proceso 
proporcionan estabilidad, control y 
organización a una actividad que si no 
se controla puede volverse caótica.
El proceso conduce a un equipo de 
software a través de un conjunto de 
actividades del marco de trabajo que se 
organizan en un flujo de proceso, el cual 
puede ser lineal, incremental o 
evolutivo.
Cualquier organización de IS debe 
describir un conjunto único de actividades 
dentro del marco de trabajo.
También debe llenar cada actividad del 
marco de trabajo con un conjunto de 
acciones de IS, y definir cada acción en 
cuanto a un conjunto de tareas que 
identifique el trabajo (y los productos del 
trabajo) que deben completarse para 
alcanzar las metas de desarrollo.
Luego, la organización debe adaptar 
el modelo de proceso resultante y 
ajustarlo a cada proyecto, a las 
personas que lo realizarán, y el 
ambiente en el que se ejecutará el 
trabajo. Sin importar el modelo de 
proceso seleccionado, los ingenieros 
de software han elegido de manera 
tradicional un marco de trabajo.
Se les llama “prescriptivos” porque 
prescriben un conjunto de elementos del 
proceso:
Actividades del marco de trabajo, 
Acciones de la IS,
Tareas,
Productos del trabajo,
Aseguramiento de la calidad,
Mecanismos de control del cambio para 
cada proyecto.Cada modelo de proceso 
prescribe también un “flujo de 
trabajo”; esto es, la forma en 
la cual los elementos del 
proceso se interrelacionan 
entre sí.
Modelo en cascadaModelo en cascada
Algunas veces llamado el ciclo de vida 
clásico, sugiere un enfoque sistemático 
secuencial hacia el desarrollo de software. 
Se considera 5 etapas:
Construcción
código
prueba
Comunicación
Inicio proyecto
Recopilación req Planeación
estimación
itinerario
seguimiento
Modelado
análisis
diseño
Despliegue
Entrega
Soporte
retroalimentacion
Modelos de procesos incrementalesModelos de procesos incrementales
En algunas ocasiones los requisitos iniciales 
del software están bien definidos en forma 
razonable, pero el enfoque global del 
esfuerzo de desarrollo excluye un proceso 
puramente lineal. Además existe la 
necesidad de proporcionar en forma rápida 
un conjunto limitado de funcionalidad para 
el usuario y después refinarla y expandirla 
en las entregas posteriores. Entonces, en 
estos casos se elige el modelo incremental.
El modelo incremental aplica secuencias 
lineales de manera escalonada conforme 
avanza el tiempo en el calendario. Cada 
secuencia lineal produce “incrementos”
del software.
Se debe tener en cuenta que el flujo del 
proceso de cualquier incremento puede 
incorporar el paradigma de construcción de 
prototipos.
El modelo incremental:El modelo incremental:
Al utilizar el modelo incremental, el primer 
incremento es un “producto esencial”, se 
incorporan requisitos básicos. Este producto 
queda en manos del cliente (o se somete a 
una evaluación). Como resultado de la 
evaluación se desarrolla un plan para el 
siguiente incremento. El plan afronta la 
modificación del producto esencial afin de 
satisfacer necesidades del cliente. Este 
procesos se repite hasta la entrega final.
Este modelo se enfoca en la entrega de un 
producto operacional con cada 
incremento. Los primeros incrementos son 
versiones incompletas del producto final, 
pero proporcionan al usuario la 
funcionalidad que necesita y una 
plataforma para evaluarlo.
El modelo incremental es útil sobre todo 
cuando el personal necesario para una 
implementación completa no está
disponible
Combina elementos del modelo en cascada 
aplicado en forma iterativa.
Incremento #1
Entrega del 1er.
incremento
Incremento #2
Entrega del 2do.
incremento
Incremento #n
Entrega del n-ésimo
incremento
Tiempo del calendario de proyecto
F
u
n
c
io
n
a
li
d
a
d
 y
 c
a
ra
c
té
rí
s
ti
c
a
s
d
e
l 
S
w
El modelo DRAEl modelo DRA
El Desarrollo Rápido de Aplicaciones es un 
modelo de proceso de software incremental 
que resalta un ciclo de desarrollo corto. El 
modelo DRA es una adaptación a “alta 
velocidad” del modelo en cascada en el 
que se logra el desarrollo rápido mediante 
un enfoque de construcción basado en 
componentes. Si se entiende los requisitos y 
el dominio del proyecto. El proceso DRA 
permite crear un sistema completamente 
funcional dentro de un periodo muy corto.
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
despliegue
integración
entrega
retroalimentación
60 – 90 días
planeación
comunicación
Equipo #1
Equipo #2
Equipo #n
Modelos de procesos evolutivosModelos de procesos evolutivos
El software, al igual que todos los sistemas 
complejos, evolucionan con el tiempo. Los 
requisitos de los negocios y productos a 
menudo cambian conforme se realiza el 
desarrollo; por lo tanto, la ruta lineal que 
conduce a un producto final no será real; 
las fechas tope del mercado imposibilitan la 
conclusión de un producto completo.
Por lo que se debe presentar una versión 
limitada para liberar la presión competitiva 
y de negocios; se tiene claro un conjunto de 
requisitos del producto o sistema esencial. 
Pero todavía se deben definir los detalles de 
las extensiones del producto. Por lo que se 
necesita un modelo de proceso que haya 
sido diseñado de manera explícita para 
incluir un producto que evoluciones con el 
tiempo
Construcción de prototiposConstrucción de prototipos
Con frecuencia un cliente define un conjunto de 
objetivos generales para el software, pero no 
identifica los requisitos detallados de entrada, 
procesamiento o salida. En otros casos, el 
responsable del desarrollo de software está
inseguro de la eficacia de un algoritmo, de la 
adaptabilidad de un SO. En estas y en otras 
situaciones , un paradigma de construcción 
de prototipos puede ofrecer el mejor enfoque
Plan rápido
Modelado
Diseño rápido
Construcción
del prototipo
Desarrollo
Entrega y 
retroalimentación
comunicación
Modelo de construcción de prototipos
El modelo en espiralEl modelo en espiral
El modelo en espiral que Boehm propuso 
originalmente, es un modelo de proceso de 
software evolutivo que conjuga la 
naturaleza iterativa de la construcción de 
prototipos con los aspectos controlados y 
sistemáticos del modelo en cascada.
Proporciona el material para el desarrollo 
rápido de versiones incrementales del 
software.
comunicación
Planeación
construcción
despliegue
modelado
Entrega
retroalimentación
Codigo
construcción
Analisis
diseño
Estimación
Itinerario
Analisis de riesgos
Reingeniería
Mantenimiento
de la Aplicación
Mejora de
la Aplicación
Desarrollo de
la Nueva Aplicación
Desarrollo del
concepto
Modelos especializados de procesoModelos especializados de proceso
Desarrollo basado en componentesDesarrollo basado en componentes
Los nuevos componentes de software 
comerciales (NCSC), desarrollados por 
vendedores que los ofrecen como productos, se 
pueden emplear cuando el software está en 
proceso de construcción. Estos componentes 
proporcionan funcionalidad dirigida con 
interfaces bien definidas que permiten que el 
componente se integre en el software.
El modelo de desarrollo basado en 
componentes (DBC) incorpora muchas de las 
características del modelo en espiral. Es 
evolutivo por naturaleza y exige un enfoque 
iterativo para la creación del software. 
Sin embargo, el modelo configura aplicaciones 
a partir de componentes de software 
empaquetados previamente.
Desarrollo del software orientado a aspectosDesarrollo del software orientado a aspectos
Independientemente del proceso de 
software que se elija, los constructores de 
software complejo implementan de manera 
invariable un conjunto específico de 
características, funciones y contenido de 
información. Estas características 
específicas del software se modelan como 
componentes (por ejemplo, clases 
orientadas a objetos) y después se 
construyen dentro del contexto de una 
arquitectura de sistema.
Conforme los sistemas basados en 
computadora se vuelven más elaborados (y 
complejos), ciertos “intereses” abarcan 
toda la arquitectura. Algunos intereses son 
propiedades de alto nivel de un sistema 
(por ejemplo, seguridad, falta de 
tolerancia). Otros intereses afectan las 
funciones (como la palicación de reglas de 
negocios), mientras que otros son 
sistemáticos (como la sincronización de 
tareas o la gestión de memoria).
Cuando los intereses se relacionan con 
múltiples funciones, características e 
información del sistema, con 
frecuencia se denominan “intereses 
generales”. Los requerimientos de 
aspectos definen estos intereses 
generales que ejercen un impacto a 
través de la arquitectura del software.