construccion de software fundamentos y conceptos

CONSTRUCCION DE SOFTWARE
HORAS TEORICAS: 2 HORAS PRACTICAS : 4
PLAN : 2015
UNIVERSIDAD PERUANA LOS ANDES
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
ASIGNATURA
DOCENTE: MG. JOHN GUERRA FLORES
HUANCAYO – PERÚ
2024
TIPO DE ESTUDIOS : ESTUDIOS ESPECIFICOS

Mg. John Guerra Flores
CIP. 195997
John.guerra@unmsm.edu.pe
DOCTORANDO EN INGENIERÍA DE SISTEMAS E INFORMATICA DE LA
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS UNMSM | MAGISTER
EN INGENIERÍA DE SISTEMAS CON MENCION GERENCIA DE SISTEMAS
EMPRESARIALES UNCP | POSGRADO GERENCIA DE PROYECTOS Y
CALIDAD, PONTIFICIA UNIVERSIDAD CATOLICA DEL PERÚ PUCP |
POSGRADO EN SIMPLIFICACION ADMINISTRATIVA UNIVERSIDAD DE SAN
MARTIN DE PORRES | INGENIERO DE SISTEMAS Y COMPUTACION DE LA
UNIVERSIDAD PERUANA LOS ANDES, COLEGIADO Y HABILITADO
MIEMBRO DEL CIP DESDE EL AÑO 2017 | PREGRADO INGENIERIA
INDUSTRIAL UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS UPC |
GERENTE GENERAL DATALOGIC INGENIERÍA Y AUTOMATIZACIÓN EIRL.
INGENIERO CON ENFOQUE EN GERENCIA DE PROYECTOS, EXPERIENCIA
LIDERANDO ÁREAS DE OPERACIONES & TI, DESARROLLO DE SOFTWARE,
INTELIGENCIA DE NEGOCIOS, BUSINESS ANALYTICS & BIG DATA,
IMPLEMENTANDO FABRICAS DE DESARROLLO DE SOFTWARE Y TESTING
EN EL SECTOR COMERCIAL, RETAIL Y SERVICIOS.

Que es Software?
Programas de ordenador junto con toda la documentación y datos de
configuración
asociados requeridos para hacer que estos programas operen de manera correcta

Software- Hardware
Parte Lógica
Parte Fisica

características y evolución del software
• un poco de historia
• primeras décadas:
• desarrollar el hardware
• reducir costes de procesamiento y almacenamiento
• década de los ochenta:
• desarrollo de la microelectrónica
• mayor potencia de cálculo y reducción de costes
• objetivo actual: mejorar la calidad de las soluciones software.
 Orientación
por lotes
 Distribución
limitada
 Software a
medida
 Multiusuario
 Tiempo real
 Bases de datos
 Software como
producto
 Mayores gastos
de mantenimiento
 Sistemas distribuidos
 Inteligencia Artificial
 Hardware de bajo
coste
 Impacto en el
consumo
 Redes area local
y global
 Gran demanda
 Potentes sistemas
de sobremesa
 Tecnología de objetos
 Sistemas expertos
 Redes neuronales
 Cliente/servidor
 Tecnologías de
Internet.
1959 - 1965 1965 - 1975 1975 - 1989 1989 -
AUMENTAN los problemas del desarrollo de software:
 Subexplotación del potencial del hardware
 Incapacidad de atender a la demanda
 Incapacidad de mantener el software existente

Arquitectura de software
Llamadas al
Sistema
Controladores de Dispositivos
MAQUINA OPERATIVA
S.
O
MAQUINA SIMBOLICA
Compiladores Editores Interprete LC
Interfaces de Usuario
Usuario y Programas de Aplicaciones

Tipos de productos de Software
•Software del Sistema
•Controladores de
Dispositivos
•Sistemas Operativos
•Herramientas de
Diagnostico
•Software de Programación
•Compiladore
s
•Interpretes
•Enlazadores
•Depuradore
s
•Software de Aplicación
•Ofimática
•Software
Empresarial
•Video juegos
•Bases de Datos

• software
• programas
• archivos de configuración
• documentación de la estructura del sistema
• manuales de instalación y uso
• sitios web con información y actualizaciones
• tipos de software
• productos genéricos
• sistemas producidos por una organización y que se venden en el mercado abierto
• sistemas gestores de bases de datos, procesadores de texto, paquetes gráficos,...
• la organización controla la especificación
• productos personalizados
• desarrollados específicamente para un cliente
• aplicaciones de negocio, sistemas de control de tráfico aéreo, control de procesos de fabricación,...
• el cliente controla la especificación de la aplicación

• El software desde una perspectiva industrial
• El valor del software: de “elemento añadido” a principal elemento de coste
• El desarrollo del software:
• Algunas preguntas:
• ¿Por qué se tarda tanto? (y casi siempre más de lo previsto)
• ¿Por qué la productividad es tan baja?
• ¿Por qué cuesta tanto?
• ¿Por qué siempre quedan errores sin localizar?

naturaleza y problemas del desarrollo de
software
• El software como elemento lógico.
• Se desarrolla, no se fabrica:
• Calidad del diseño.
• Costes más importantes en la ingeniería
• Gestión 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.
Insatisfacción del cliente
Planificación y estimaciones
imprecisas
Calidad
Sin tiempo para recoger
datos históricos
Baja productividad
Dificultad de mantener
el software existente

naturaleza y problemas del desarrollo de
software
• Causas de la crisis del software
• Naturaleza lógica del software
• Mala gestión de los proyectos ( ausencia de datos, deficiente comunicación,
...)
• Ausencia de entrenamiento formal en nuevas técnicas (programadores vs.
ingenieros de software)
• Resistencia al cambio
• Mitos del software:
MITOS DEL CLIENTE
- Requisitos establecidos como
una declaración general de
objetivos
- Flexibilidad del software ante
los cambios
MITOS DE GESTIÓN
- Uso de estándares
- Uso de herramientas
- Mala planificación: aumento
de programadores
MITOS DE LOS DESARROLLADORES
- Programa funcionando = fin del trabajo
- Calidad = el programa se ejecuta
sin errores
- Entrega al cliente: programa
funcionando

la ingeniería del software
• definiciones
• establecimiento y uso de principios de ingeniería robustos, orientados a
obtener software económico, fiable, eficiente y que satisfaga las necesidades
del usuario
• disciplina que comprende todos los aspectos de la producción de software,
desde las etapas iniciales hasta el mantenimiento:
• “disciplina de ingeniería”: aplicación de teorías, métodos y herramientas para
solucionar problemas, y teniendo en cuenta restricciones financieras y organizativas
• “todos los aspectos de producción”: comprende procesos técnicos del desarrollo y
actividades como la administración de proyectos, desarrollo de herramientas, métodos y
teorías
• actividad de
• modelado
• solución de problemas
• adquisición de conocimiento
• dirigida por una fundamentación

•Disciplina de la Ingeniería que comprende todos los aspectos de la
producción de
softwar
e
desd
e
la
s
etapa
s
iniciales
de
la especificació
n
del sistema
,
Software
)
hast
a
el
mantenimiento de éste después de que se utiliza
(Ciclo de
vida
del
•Aspectos de la producción de
Software
•Procesos Técnicos del desarrollo de
Software
•Gestión de proyectos de
software
•Desarrollo de
Herramientas
•Teorías de apoyo a la producción de
software

Proceso del software
•Conjunto de actividades y resultados que producen un producto de
software
(incluida la documentación requerida)
1. Especificación del Software: Se define el
software a
restricciones sobre su operación.
producir y
las
2. Desarrollo de Software: Análisis, Diseño y
programación
3. Validación del Software: Donde el software se valida
para
lo que el cliente requiere (Pruebas y Validación).
asegurar que
es
4. Evolución del Software: Donde el software se modifica para
adaptarlo a
los cambios requeridos por el cliente y el mercado (mantenimiento).

Ciclo de vida del Software

Visión distinta de cada actor

• trata de ser la respuesta a la crisis del software
• combinación de elementos:
filosofía de coordinación,
control
y buena gestión
métodos completos para
todas las fases
mejores técnicas de
control de calidad
mejores elementos
de programación
herramientas para automatizar
los métodos

modelado
• modelado: método básico de la ciencia
• modelo
• representación abstracta de un sistema que da respuesta a preguntas sobre el sistema
• útiles cuando se manejan sistemas grandes, pequeños, complicados o caros para tener
una experiencia de primera mano
• permiten visualizar y comprender sistemas que no existen o que sólo se supone que
existen
• ejemplos:
• biología: modelos de dinosaurios a partir de restos
• física: modelos que representan cómo se reúnen materia y energía en los niveles subatómicos más
bajos
• el sistema en el mundo real serían dinosaurios o partículas subatómicas
escuela superior de ingeniería informática
ingeniería del software de gestión
modelos

modelado
• los ingenieros de software necesitan
• comprender el ambiente de funcionamiento del sistema: construyen modelos del
dominio del problema (sistemas de bolsa, control de tráfico aéreo,...)
• comprender los distintos sistemas que podrían construir para evaluar alternativas:
construyen modelos del dominio de la solución
• técnicas y herramientas para construir los modelos (por ejemplo, diagramas de UML)
Realizar transacción
Pagar recargo por saldo deudor
Comprador
Solicitar bienes o servicios
Confirmar pedido
Enviar factura al comprador
Sistema de
cuentas bancarias
Enviar aviso
iniciador
Vendedor
iniciador
iniciador
Pagar factura
iniciador
SISTEMA DE PAGOS Y
FACTURACIÓN
<<extend>>
iniciador
Hojear facturas
Planificar pago
factura
Rechazar
factura
Pagar factura en día
vencimiento
<<subsistema>>
Controlador del
brazo
<<subsistema>>
Sistema de
visión
<<subsistema>>
Sistema de identificación
de objetos
<<subsistema>>
<<subsistema>>
Sistema de
embalaje
<<subsistema>>
Sistema de selección
de embalajes
<<subsistema>>
Controlador del
asidero
<<subsistema>>
Controlador de cinta
transportadora
<<subsistema>>

solución de problemas
• los ingenieros de software buscan una solución adecuada, en varios pasos:
1. Formular el problema
2. Analizar el problema
3. Buscar soluciones
4. Decidir la solución más adecuada
5. Especificar la solución
• actividades básicas del desarrollo
1. obtención de requerimientos
2. análisis
3. diseño del sistema
4. implementación
• otras actividades del desarrollo para evaluar la adecuación de los modelos
• revisiones del análisis: el modelo del dominio del problema se compara con la realidad del cliente
• revisiones del diseño: el modelo del dominio de la solución se compara con los objetivos del proyecto
• pruebas: el sistema se valida contra el modelo del dominio de la solución
• administración del proyecto: se compara el modelo del proceso de desarrollo (calendario y presupuesto) con
la realidad (trabajos entregados y recursos gastados)

participantes y papeles
• participantes: todas las personas involucradas en el proyecto
• cliente: encarga y paga el sistema
• desarrolladores: construyen el sistema (analistas, diseñadores,
programadores,...)
• gerente o director del proyecto: planifica y calcula el presupuesto, coordina a
los desarrolladores y cliente
• usuarios finales: los que van a utilizar el sistema
• papel (rol)
• conjunto de responsabilidades en el proyecto o en el sistema
• asociado con un conjunto de tareas y se asigna a un participante
• un mismo participante puede cumplir varios papeles

otros conceptos de la ingeniería del software
• sistemas y modelos
• sistema: realidad subyacente
• modelo: cualquier abstracción de la realidad
• productos de trabajo
• artefacto o elemento que se produce durante el desarrollo (documento, fragmento de software,...)
• dos tipos:
• producto de trabajo interno: producto para el consumo interno del proyecto (por ejemplo, una revisión de la estructura de la base
de datos, resultados de pruebas para el gerente,...)
• entrega: producto de trabajo para un cliente (especificación de requisitos, manual de usuario, producto final,...)
• actividades, tareas y recursos
• actividad (o fase): conjunto de tareas que se realiza con un propósito específico (obtención de requisitos, entrega,
administración,...) que pueden componerse de otras actividades
• tarea: unidad elemental de trabajo que puede ser administrada; consumen recursos, dan como resultado productos
de trabajo y dependen de productos de trabajo producidos por otras tareas
• recursos: bienes que se utilizan para realizar el trabajo:
• tiempo, equipamiento y recursos humanos
• al planificar, el gerente divide el trabajo en tareas y les asigna recursos

• objetivos, requerimientos y restricciones
• objetivos:
• principios de alto nivel que se utilizan para guiar el proyecto
• definen los atributos realmente importantes del sistema (seguridad, fiabilidad,...)
• a veces hay conflicto entre objetivos (por ejemplo, seguridad y bajo coste) que
aumentan la complejidad del proyecto
• requerimientos
• características que debe tener el sistema
• requerimiento funcional: área de funcionalidad que debe soportar el sistema (por
ejemplo, proporcionar billetes de tren)
• requerimiento no funcional: restricción que se establece sobre el funcionamiento del
sistema (por ejemplo, proporcionar billetes de tren en menos de un segundo)
• otras restricciones: por ejemplo, utilización de un determinado lenguaje, de
una determinada plataforma o de un sistema antiguo que el cliente no
quiere retirar

• notaciones, métodos y metodologías
• notación: conjunto de reglas gráficas o de texto para representar un modelo
(UML, Unified Modelling Language, es una notación gráfica orientada a
objetos para representar modelos)
• método: técnica repetible para resolver un problema específico. Por ejemplo:
• un algoritmo de ordenación es un método para ordenar elementos en una lista
• la administración de la configuración es un método para el seguimiento de los cambios
• metodología: colección de métodos para la resolución de una clase de
problemas (OMT, metodología de Booch, Catalysis, Proceso Unificado de
Desarrollo,...)

actividades de desarrollo
• ingeniería de requerimientos
• el cliente y los desarrolladores definen el
propósito y objetivos del sistema
• resultado: descripción del sistema en
términos de participantes (actores) y
funciones (casos de uso)
• actores: entidades externas que interactúan
con el sistema (incluyen roles como usuarios
finales u otros sistemas con los que
interactúa el sistema)
• casos de uso: secuencias de eventos que
describen todas las acciones posibles entre
un actor y el sistema para una función
específica.
• se acuerdan requisitos no funcionales. Por
ejemplo:
• el distribuidor de billetes debe estar
disponible al menos un 95% del tiempo
• el distribuidor de billetes debe dar respuesta
en menos de un segundo después de
seleccionada la transacción
Nombre del caso de uso: CompraBillete
Actor participante: Iniciado por Viajero
Precondición:
1. El Viajero se para frente al distribuidor automático de billetes
Flujo de eventos:
2. El Viajero selecciona las estaciones de origen y destino
3. El DistribuidorDeBilletes muestra el precio del billete
4. El Viajero inserta una cantidad de dinero que, al menos, debe
ser igual que el precio del billete
5. El DistribuidorDeBilletes emite el billete especificado al Viajero y
devuelve el cambio si es necesario
Postcondición:
6. El Viajero coge el billete y el cambio
Requisitos especiales:
Si la transacción no ser termina después de un minuto de
inactividad, el DistribuidorDeBilletes devuelve todo el dinero
insertado
ReservaBilletes
CompraBillete
Viajero
Anulación reserva

• análisis
• se produce un modelo correcto, completo, consistente, claro, realista y
verificable
• transformación de los casos de uso en un modelo que describe por completo
el sistema y que se usará en el diseño
• descubrimiento y resolución con el cliente de ambigüedades e
inconsistencias en el modelo de casos de uso
Transacción
Moneda
BilleteTren
Zona
da como resultado
válido para
Saldo
cantidad pagada
Papel

• diseño
• diseño del sistema
• definición de los objetivos de diseño
• descomposición del sistema en subsistemas abordables por equipos
• selección de estrategias para la construcción (plataformas hardware
y software, almacenamiento de datos persistentes, control de
acceso,...)
• resultado: descripción de las estrategias, descomposición en
subsistema
• diseño de objetos:
• definición de objetos e interfaces de subsistemas, reestructuración
del modelo de objetos para lograr los objetivos de diseño,
optimización del modelo para mejorar el rendimiento,...
• resultado: modelo de objetos detallado
• actividades del diseño
• diseño arquitectónico
• especificación de los subsistemas
• diseño de interfaz
• diseño de componentes
• diseño de la estructura de datos
• diseño procedimental (algoritmos)
Comprador
IU Solicitud
de pago
Gestor de
pedidos
Confirmación
de pedidos
Planificador
de pagos
Solicitud
de pago
Procesamiento de
solicitudes de pago
Procesamiento
de facturas
Factura
Gestión facturas
comprador
Gestión de planificación
de pagos
Gestión de
cuentas

Validación
Usuarios
<<subsystem>>
Gestión Máquinas
Subgrupo
<<subsystem>>
Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Sistema
<<subsystem>>
Gestión
Instalaciones
<<subsystem>>
Mantenimientos
de Gestión
<<subsystem>>
Gestión Mantenimiento
Correctivo
<<subsystem>>
Gestión Trabajos
Externos
<<subsystem>>
Preventivo
<<subsystem>>

Validación
Usuarios
<<subsystem>>
Gestión Máquinas
Subgrupo
<<subsystem>>
Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Sistema
<<subsystem>>
Gestión
Instalaciones
<<subsystem>>
Mantenimientos
de Gestión
<<subsystem>>
Correctivo
<<subsystem>>
Gestión Trabajos
Externos
<<subsystem>>
Preventivo
<<subsystem>>
Gestión
Máquinas
<<subsystem>>
Gestión Características
Máquinas
Gestión Tareas
Máquinas
Alta Características-Maq
Baja Características-Maq
Modificación Características-Maq
Operario
(from Validación Usuarios)
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
Consulta Características-Maq
<<include>>
Alta Instalaciones
Baja Instalaciones
Modificación Instalaciones
Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
Consulta Instalaciones
<<include>>

Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
<<include>>
Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el
formulario.
Post-Condiciones 1. Los datos de la nueva característica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan
guardados si se produce algún error durante el
proceso.
Descripción 1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.
MENSAJES
: Administrador Opciones Frm
Cliente
CTRL Alta
Instalación
Form_Alta Validar Datos
INSTALACION
Resultado Alta
Visualizar Mensaje
Seleccionar
Crea()
Mostrar(Datos)
Introducir Datos()
Cubrir_Datos()
Comprobar()
Comprobar()
Obtener Datos
Crear_Alta()
Construir
Construir
Visualizar Resultado
Crea()
Si no Existe
Fin Si
Fin Si
Datos Correctos
...
Datos no Correctos
Mostrar

Visualizar
Formulario
Comprobar
Datos
Mensaje "Error
Datos"
Comprobar Existencia
de la Instalación
Visualizar Datos
Instalación
Guardar Datos
Instalación
Mensaje
"Error"
Datos Incorrectos
Datos Correctos
Si Existe
Mensaje "Instalación
guardada"
Administrador Validado
Seleccionar
Formulario
Introducir
Datos
Seleccionar
Guardar
No Existe
Error al Guardar
Instalación Guardada
Administrador (from Alta Máquinas)
Sistema (from Validar Usuario)
Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
<<include>>
Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el
formulario.
Post-Condiciones 1. Los datos de la nueva característica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan
guardados si se produce algún error durante el
proceso.
Descripción 1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.

Especificacion
DelProducto
descripción
precio
articuloID
CatalogoDe
Productos
1..n
1
Articulo
Encargado
LineaDeVenta
cantidad
1
n
1..n
0..1
Tienda
dirección
nombre
n
1
n
1
Pago
cantidad
Venta
fecha
hora
1
1..n
1
n
1
1
Cliente
1
1
Registro
1..n
1
1
1
1
1
Cajero
1
1
1
1
1
1
1
1
Pagada-mediante
1
1
Iniciada-por Registra-ventas-en
Iniciado-por
1..n
1
Alberga
Abastece
n
1
Capturada-en
1
1
1
n
Registra-completas
Contenida-en
1
1..n Utilizado-por
n
1
1..n
1
Contiene
Descrita-por
1
n
1..n
0..1
Registra-venta-de

Servidor SGBD
Red Local Impresora
Cliente
Cliente
ODBC
TCP/IP
TCP/IP
TCP/IP

• implementación
• traducción del modelo de diseño (por ejemplo, del modelo de objetos) en código fuente
• incluye:
• implementación de atributos y métodos de cada objeto
• integración de todos los objetos para que funcionen como un solo sistema
• pruebas
• pruebas de unidad: comparación del modelo de diseño con cada objeto y subsistema
• pruebas de integración: combinaciones de subsistemas y comparación con el modelo de
diseño del sistema
• pruebas del sistema: ejecución de casos típicos y excepcionales, y comparación con el
modelo de requerimientos
• objetivo: descubrir la mayor cantidad posible de errores que se puedan reparar antes de
entregar el sistema
• mantenimiento
• mejoras en el sistema (nuevas funciones, facilidad de uso,...)
• corrección de errores
• adaptación a cambios en el entorno (hardware, software, legislación,...)
• actividad más costosa del ciclo de vida de un producto software

• actividades de administración del desarrollo
• comunicación
• actividad crítica y costosa en tiempo
• intercambio de modelos y documentos, informes de evolución y calidad,
negociaciones, comunicación de decisiones,...
• herramientas y notaciones
• gestión de la configuración
• proceso que supervisa y controla los cambios en los productos de trabajo
• cambios: requerimientos, plataformas hardware y software, errores
encontrados, mejoras del sistema,...
• administración del proyecto
• objetivo: asegurar la entrega de un sistema de alta calidad a tiempo y dentro
del presupuesto
• planificación y presupuesto del proyecto
• contratación de desarrolladores y coordinación de equipos
• vigilancia de la evolución del proyecto
• detección de desviaciones e intervención

el proceso: modelos de desarrollo
• proceso
• conjunto ordenado de tareas, una serie de pasos que involucran actividades, restricciones y recursos, que producen
una salida determinada
• proceso de software: conjunto de actividades necesarias para transformar los requisitos de un usuario en un
sistema software
• características
• tiene una serie de actividades principales
• utiliza recursos, está sujeto a restricciones y genera productos intermedios y finales
• compuesto por subprocesos que se encadenan de alguna forma
• cada actividad tiene sus criterios de entrada y salida, que permiten conocer cuando comienza y termina dicha actividad
• existen principios orientadores que explican las metas de cada actividad
• cuando implica la construcción de un producto, se suele llamar ciclo de vida
• aportan consistencia y estructura sobre el conjunto de actividades, lo que permite realizar la misma tarea
correctamente de forma repetida
• existen diferentes modelos de proceso
Proceso de desarrollo
de Software
Requisitos
del usuario
Sistema software

modelo en cascada
Requerimentos
y Análisis
Diseño
Implementación
Pruebas
Mantenimiento
resultado de cada fase: uno o más
documentos aprobados
una fase comienza cuando la anterior
termina
en la práctica, las etapas se solapan
iteraciones de coste elevado y
reelaboración del trabajo: tendencia a
la congelación de partes del desarrollo
(especificaciones,...)
se retrasa la localización y corrección
de errores
pueden producir sistemas poco útiles
para usuarios o mal estructurados
inflexibilidad del modelo: dificultad
para responder a cambios en los
requerimientos

desarrollo evolutivo
• basado en:
• desarrollo de una implementación inicial
• exposición a comentarios y crítica del usuario
• refinamiento a través de diferentes versiones hasta
llegar a un sistema adecuado
Recolección
y refinamiento de
requisitos
Diseño
rápido
Producto
Refinamiento
del prototipo
Evaluación del
prototipo por
el cliente
Construcción
del prototipo
dos tipos:
prototipado evolutivo:
trabajo con cliente para explorar
sus requerimientos y entregar un
sistema final
evolución continua del prototipo
mediante la agregación de
funciones y características
propuestas por el cliente
prototipos desechables
comprensión de las necesidades
del cliente
desarrollo de una definición
mejorada de los requerimientos
del sistema
prototipos centrados en la
experimentación de requisitos
poco claros o complejos
problemas
prisas del cliente (utilización del
prototipo como sistema final
pasar elecciones debidas al prototipo a
la implementación final (entorno,
sistema operativo,...)
estructura deficiente
evolución del proceso difícil de
gestionar
herramientas y técnicas especiales
poco adecuado para grandes sistemas

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

desarrollo incremental
Definición general de
requerimientos
Asignación de requerimientos
a incrementos
Diseño de la arquitectura del
sistema
Desarrollo de incrementos
del sistema
Validar
incrementos
Integrar
incrementos
Validar
sistema
Sistema final
sistema incompleto
sistema completo
pasos
identificación y priorización de funciones y
servicios
definición de varios requerimientos que
proporcionan parte de la funcionalidad, según la
prioridad (los más importantes se entregan
antes)
definición detallada de requerimientos del
incremento y desarrollo con el proceso más
adecuado
congelación de requerimientos de incrementos
desarrollados
puesta en explotación de los incrementos
completados y entregados
ventajas
puesta en marcha temprana
los incrementos iniciales permiten refinar
requerimientos de incrementos posteriores
satisfacción del cliente (bajo riesgo de fallo)
sistema final muy probado y con pocos fallos
problemas
incrementos relativamente pequeños
adaptación de requerimientos a incrementos del
tamaño apropiado
identificación de recursos comunes a todos los
incrementos

modelo en espiral
.
Concepto de
operación
Análisis de riesgos
An.
Riesgo.
-
PROGRESO
A TRAVÉS
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 integración
y prueba
REVISIÓN
Proto-
tipo 1
Prototipo 2
Prototipo 3
Prototipo
operativo
Requerimientos
de software
Validación de
requerimientos
Diseño del
producto
Diseño de validación
y verificación
Diseño
detallado
Prueba de
unidad
Prueba de
integración
Prueba de
aceptación
Explotación
EVALUAR ALTERNATIVAS,
IDENTIFICAR Y
RESOLVER RIESGOS
DETERMINAR
OBJETIVOS,
ALTERNATIVAS Y
RESTRICCIONES
propuesto por Barry
Boehm
organización en ciclos
primer ciclo: factibilidad
segundo ciclo:
requerimientos
tercer ciclo: diseño
...
cada ciclo se divide en 4
sectores
definición de objetivos,
restricciones del producto
y proceso, plan de
administración,...
evaluación y reducción de
riesgos (por ejemplo,
mejor definición de
requerimientos mediante
prototipos)
desarrollo y validación:
elección de un modelo
para el desarrollo
planificación: el proyecto
se revisa y se decide si se
continúa con el siguiente
ciclo. si es así, se planifica
la siguiente fase

el proceso unificado de desarrollo
• proceso unificado de desarrollo
• propuesto por los autores de UML (lenguaje unificado de desarrollo)
• basado en componentes interconectados a través de interfaces
• utiliza UML para desarrollar los esquemas y diagramas de un sistema
software
• principales aspectos definitorios
• dirigido por casos de uso
• centrado en la arquitectura
• iterativo e incremental
Proceso de desarrollo
de Software
Requisitos
del usuario
Sistema software

el proceso unificado: dirigido por casos de
uso • para construir un sistema con éxito hay que conocer las necesidades y
deseos de los futuros usuarios
• usuario
• personas que trabajan y necesitan el sistema
• otros sistemas que interactúan con el que estamos desarrollando
• interacción:
• usuario inserta tarjeta en cajero automático
• usuario responde sobre la pantalla a las preguntas que realiza el cajero
• el usuario recibe una cantidad de dinero y su tarjeta
• una interacción así es un caso de uso
• fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante
• utilidad casos de uso
• herramienta para especificar los requisitos de un sistema: representan los requisitos
funcionales y juntos constituyen el modelo de casos de uso, que describe la
funcionalidad total del sistema
• guían el proceso de desarrollo (diseño, implementación y prueba)
• basándose en el modelo de casos de uso, se crean modelos de diseño e implementación
• se revisa cada modelo para que sean conformes al modelo de casos de uso
• se prueba la implementación para garantizar que los componentes del modelo de
implementación implementan correctamente los casos de uso
• no sólo inician el proceso de desarrollo sino que éste sigue un hilo de trabajo que
parte de los casos de uso
Retirar dinero
Ingresar dinero
Cliente del banco
Transferencia entre cuentas

el proceso unificado: centrado en la arquitectura
• la arquitectura de un sistema software se describe mediante
diferentes vistas del sistema en construcción
• influida por diversos factores
• necesidades de la empresa, tal y como las perciben los usuarios y clientes
• otros factores, como plataforma de explotación (arquitectura hardware,
sistema operativo, gestor de bases de datos, protocolos de
comunicación,...), componentes reutilizables, sistemas heredados,
requisitos no funcionales,...
• es una vista del diseño completo con las características más
importantes resaltadas, dejando los detalles de lado.
• hay una constante interacción entre los casos de uso y la
arquitectura, que evolucionan en paralelo
• los casos de uso deben encajar en la arquitectura cuando se realizan
• la arquitectura debe permitir el desarrollo de todos los casos de uso
requeridos
• el arquitecto
• realiza un esquema en borrador de la arquitectura que no es específica de
los casos de uso (por ejemplo, la plataforma)
• trabaja con un subconjunto de los casos de uso principales del sistema,
especificándolo en detalle y realizándolo en términos de subsistemas,
clases y componentes
• a medida que los casos de uso se especifican y maduran, se descubre más
de la arquitectura, lo que a su vez lleva a la maduración de más casos de
uso
• este proceso continúa hasta que se considera que se dispone de una
arquitectura estable
casos de
uso
arquitectura
guía
conduce
Capa específica
de la aplicación
Capa general de la
aplicación
Capa
intermedia
Capa de software
del sistema

el proceso unificado: iterativo e incremental
• el trabajo se divide en partes más pequeñas o miniproyectos
• miniproyecto: una iteración que resulta en un incremento
• iteración: pasos en el flujo de trabajo
• incremento: crecimiento del producto
• las iteraciones están controladas y planificadas
• factores para seleccionar lo que se implementará en una iteración
• la iteración se centra en un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora
• la iteración trata los riesgos más importantes
• las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la última
iteración
• en las primeras fases del ciclo de vida los incrementos implican modificaciones
• en las últimas fases los incrementos implican menos modificaciones y más añadidos a los modelos
• para cada iteración:
• identificación y especificación de los casos de uso relevantes
• creación de un diseño utilizando la arquitectura seleccionada como guía
• implementación del diseño mediante componentes
• verificación de que los componentes satisfacen los casos de uso
• si una iteración cumple con sus objetivos, el desarrollo continúa con la siguiente iteración. Si no, se revisan las decisiones previas y se
adopta un nuevo enfoque
• ventajas proceso iterativo controlado
• reducción del coste del riesgo a los costes de un solo incremento
• reducción del riesgo de no sacar al mercado el producto en el calendario previsto
• se acelera el ritmo del esfuerzo de desarrollo en su totalidad, para obtener resultados claros a corto plazo
• los requerimientos del usuario se van refinando en iteraciones sucesivas, por lo que se pueden acomodar mejor los cambios

la vida del proceso unificado
• el proceso unificado se repite a lo largo de una serie de ciclos
• cada ciclo concluye con una versión del producto y consta de cuatro fases
• inicio: descripción del producto final a partir de una idea inicial y análisis de negocio para el producto
• principales funciones del sistema y usuarios más importantes (modelo de casos de uso)
• posible arquitectura del sistema
• plan del proyecto, coste, identificación y priorización de riesgos
• elaboración:
• se especifican en detalle los principales casos de uso
• se diseña la arquitectura del sistema: vistas arquitectónicas del modelo de casos de uso, del modelo de análisis, del modelo de
diseño, del modelo de implementación y modelo de despliegue
• al final se pueden planificar las actividades y estimar recursos necesarios para finalizar el proyecto
• construcción:
• se crea el producto añadiendo el software a la arquitectura
• al final se dispone de todos los casos de uso acordados para el desarrollo aunque puede incorporar defectos
• transición
• periodo durante el cual el producto se convierte en versión beta, en la que usuarios prueban el producto e informan de
defectos y deficiencias
• se corrigen problemas e incorporan sugerencias
• incluye actividades como la formación del usuario, proporcionar una línea de ayuda y asistencia,...
• cada fase se divide a su vez en iteraciones

la vida del proceso unificado
Inicio Elaboración Construcción Transición
Requisitos
Análisis
Diseño
Implementación
Prueba
Flujos de trabajo
fundamentales
Fases
iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n
Iteraciones
una iteración en la
fase de elaboración

bibliografía
Bruegge, B., Dutoit, A.H., Ingeniería del Software Orientado a Objetos, cap. 1
Jacobson, I., Booch, G., Rumbaugh, J., El Proceso Unificado de Desarrollo de
Software, cap. 1
Pressman, R.S., Ingeniería del Software. Un enfoque práctico, cap. 1 y 2
Sommerville, I., Ingeniería de Software, cap. 1, 2 y 3

construccion de software fundamentos y conceptos

Recomendados

Recomendados

Más contenido relacionado

Similar a construccion de software fundamentos y conceptos

Similar a construccion de software fundamentos y conceptos (20)

Más de jguerraf0805910805

Más de jguerraf0805910805 (15)

Último

Último (20)

construccion de software fundamentos y conceptos

Notas del editor