Desarrollo de Software - IV - Ingeneria de Software-1 PDF

www.senati.edu.
pe
DESARROLLO DE SOFTWARE
SEMESTRE IV
Ingeniería de Software
Semana 7
Prof. Moisés García
www.senati.edu.pe
OBJETIVOS:
• Brindar a los participantes los conocimientos y experiencias
necesarias relacionadas a la ingeniería de software.
www.senati.edu.pe
Definiciones previas
www.senati.edu.pe
Sistema de Información:
• Organismo que recolecta, procesa, almacena y distribuye
información (Laudon y Laudon)
• Conjunto de elementos orientados al tratamiento y

administración de datos e información, organizados y listos
para su uso posterior, generados para cubrir una necesidad
o un objetivo
www.senati.edu.pe
Elementos: Equipos
Datos Personas
Sistema de
Información
Procedimi
Programas
entos
www.senati.edu.pe
Importancia:
• Son indispensables para ayudar a los gerentes a mantener
ordenada su compañía, a analizar todo lo que por ella pasa y a
crear nuevos productos que coloquen en un buen lugar a la
organización.
www.senati.edu.pe
Ciclo de Vida del Desarrollo de SI
Kendall y Kendall
www.senati.edu.pe
Ciclo de Vida del Software
ISO 12207:
Estándar para los procesos de ciclo de vida de software
• Definición: El proceso que se sigue para construir, entregar y hacer

evolucionar el software. Desde la concepción de una idea hasta la
entrega y el retiro del sistema.
www.senati.edu.pe
Ciclo de Vida del Software
• ISO 12207 PROCESOS PRINCIPALES PROCESOS DE APOYO
PROCESOS
ORGANIZATIVOS
• Adquisición • Documentación • Gestión
Especifica las
• Suministro • Gestión de la • Infraestructura
actividades que se • Desarrollo configuración • Mejora
pueden realizar. • Operación • Aseguramiento de • Recursos Humanos
• Mantenimiento calidad
• Destrucción • Verificación
No especifica • Validación
ningún modelo en • Revisión conjunta
concreto. • Auditoría
• Resolución de
problema
www.senati.edu.pe
Modelos: Ciclo de Vida en Cascada
• Permite cumplir con los plazos de entrega.

www.senati.edu.pe
Modelos: Ciclo de Vida Incremental
• Permite agregar componentes funcionales.

www.senati.edu.pe
Modelos: Prototipos
• Pantalla o Maqueta: sin
Especificaciones
Incompletas
Especificaciones
Completas funcionalidad.
• Funcional Evolutivo:
incluye los requisitos
Desarrollo Evaluación entendidos en cada
Selección del
Prototipo
del
Prototipo
del
Prototipo
iteración
Dificultad:
• Costos y Tiempos
• Usado cuando el cliente no sabe lo que quiere.
www.senati.edu.pe
Modelos: Ciclo de Vida Espiral
• Incorpora un análisis de riesgos

www.senati.edu.pe
Modelos: Ciclo de Vida en V
• Se enfoca en la calidad del software.

www.senati.edu.pe
¿Porqué Ingeniería de Software?
www.senati.edu.pe
¿Porque Ingeniería de Software?
• En los inicios del desarrollo del software (60’), crear un
software era una tarea artesanal.
 Exceso de costos  Mantenimiento casi imposible
 Retrasos de entrega  Modificaciones prohibitivas
 Prestaciones inadecuadas  Falta de fiabilidad
www.senati.edu.pe
• Frente a la inexistencia de técnicas establecidas para el desarrollo
de software y un rápido crecimiento de la demanda, surge:
“Crisis del Software”

Dificultad en escribir programas libres
de defectos, fácilmente comprensible,
y que sea verificable.
www.senati.edu.pe
Utilizado, pero luego de cambios Utilizado, tal como se entrego
3% 1%
Utilizado, pero con trabajo extra o Entregado y nunca usado

abandono 47%
19%
Pagado y nunca entregado

30% … 1970
www.senati.edu.pe
Informe CHAOS 2015
www.senati.edu.pe
56% 55%
52%
49% 50%
31%
29% 28% 29%
27%
22%
19% 19%
17% 17%
Exitoso Con Cambios Fallado Informe CHAOS 2015

2011 2012 2013 2014 2015
www.senati.edu.pe
Informe CHAOS 2015
62%
31% 32%
26%
24%
21%
17% 17% 17% 16%
Exitoso
11%
Con Cambios 9%
7% 6%
Fallado 2%
Grande Largo Mediano Moderado Pequeño
www.senati.edu.pe
www.senati.edu.pe
• A raíz de la “crisis del software” surge la necesidad de aplicar
una disciplina ingenieril que ofrezca:
 Formalización, con nuevos modelos de desarrollo y

especificación del ciclo de vida
 Utilización de nuevos paradigmas de programación,
arquitecturas, protocolos y modelos de computación.
 Una mayor inversión en planificación, análisis y diseño.
www.senati.edu.pe
• Aspectos que considera: El proceso
La
El control
administración
Proyecto
La
El seguimiento
planificación
www.senati.edu.pe
• La alternancia:
Controla
Proceso de Proceso de
Gestión Producción
Retroalimenta
Explota Explota
Tecnología de Tecnología de
Gestión Proporciona Proporciona
Producción
Entorno Justifica
Cumplimiento de estándares
www.senati.edu.pe
• Semejanzas con otras ingenierías:
 Las técnicas de gestión de proyectos de ingeniería, también

son aplicables a los proyectos de software.
 Muchos de los problemas que aparecen en los sistemas de
ingeniería, también aparecen en los sistemas de software:
(Tiempo, Recursos, Cambio de Especificaciones, … )
www.senati.edu.pe
• Diferencias con otras ingenierías:
 El software es intangible y flexible.

 El proceso de desarrollo de software NO es estándar
 Muchas veces los proyectos de software son unicos
www.senati.edu.pe
• A. Davis. “Aplicación de principios científicos para: la
transformación ordenada de una problema en una solución
software y el mantenimiento del mismo durante toda su vida útil.”
• R. Pressman. “Disciplina que integra métodos, herramientas y
procedimientos para el desarrollo de software de computador.”
• I. Sommerville. “Disciplina ingenieril que abarca todos los
aspectos de la producción de software.”
www.senati.edu.pe
• La Ingeniería del Software es aquella que ofrece métodos y
técnicas para desarrollar y mantener software de calidad.
www.senati.edu.pe
• Participantes en el desarrollo del software.
DIRECTIVOS USUARIOS
(Patrocinan el Proyecto) (Usan el sistema)
Tiene
Proporciona necesidades
financiamiento
Tiene obligaciones
contractuales
Proporciona sistema
de software
DESARROLLADOR
(Construye el Sistema)
www.senati.edu.pe
Requisitos / Requerimientos
www.senati.edu.pe
Requisitos/Requerimientos del Sistema
• Los requisitos expresan lo que el sistema debe hacer
para satisfacer las necesidades de sus clientes o
usuarios.
• Es algo que el sistema debe ser capaz de hacer (o una
restricción que debe cumplir) para que pueda cumplir
su propósito y satisfacer a sus usuarios.
• Los requerimientos se concentran en el cliente y el
problema a resolver.
www.senati.edu.pe
• Se estima que un alto porcentaje de proyectos de
desarrollo de software fallan por:
Requisitos incompletos
Falta de participación del usuario
Expectativas poco realistas
Cambios en los requisitos y las especificaciones
El sistema dejó de ser necesario
www.senati.edu.pe
• El costo por el cambio de requisitos:
www.senati.edu.pe
• Factores de éxito en el desarrollo de un sistema:
Factores
1 Usuarios involucrados con el proyecto 15,90%
Standish Group Report
2 Soporte de los Ejecutivos 13,90%
3 Requerimientos Claros 13,00% Encuesta realizada a
4 Planificación Adecuada 9,60% Gerentes Ejecutivos del área
5 Expectativas Realistas 8,20% de Desarrollo de Software y
TICs
6 Hitos pequeños y poco espaciados en el tiempo 7,70%
7 Personal competente 7,20%
8 Control sobre el proyecto por parte del personal 5,30%
9 Visión clara y objetivos 2,90%
10 Trabajo duro, personal enfocado y comprometido 2,40%
11 Otras 13,90%
www.senati.edu.pe
• Factores que amenazaron el Proyecto:
Factores
1 Falta de información de los usuarios 12,80%
2 Especificación de requerimientos incompleta 12,30%
3 Requerimientos y especificación compleja 11,80% Encuesta realizada a
4 Falta de soporte ejecutivo 7,50% Gerentes Ejecutivos del área
5 Mala tecnología, mal uso de la tecnología 7,00% de Desarrollo de Software y
TICs
6 Falta de recursos 6,40%
7 Expectativas poco realistas 5,90%
8 Objetivos poco claros 5,30%
9 Tiempos de desarrollo poco realistas (planificación) 4,30%
10 Tecnología nueva (desconocimiento) 3,70%
11 Otras 23,00%
www.senati.edu.pe
• Factores que acabaron/cancelaron el Proyecto:
Factores
1 Falta de información de los usuarios 13,10%
2 Especificación de requerimientos incompleta 12,40%
3 Falta de recursos 10,60% Encuesta realizada a
4 Expectativas poco realistas 9,90% Gerentes Ejecutivos del área
5 Falta de soporte ejecutivo 9,30% de Desarrollo de Software y
TICs
6 Requerimientos cambiantes 8,70%
7 Falta de planificación 8,10%
8 El proyecto no se necesitó más 7,50%
9 Falta de gestión adecuada de IT 6,20%
10 Problemas tecnológicos 4,30%
11 Otras 9,90%
www.senati.edu.pe
• Definen (o deberían definir):
Lo que el cliente quiere que haga...
Todo lo que el cliente quiere que haga...
Nada más aquello que el cliente quiere que haga...
www.senati.edu.pe
• ¡Los requisitos se
concentran en “qué”
debe hacer el sistema,
… y no en “cómo” debe
hacerlo!
www.senati.edu.pe
¿Qué definen los requisitos?
Aplicación Los datos que debe capturar y
almacenar
Las funciones que debe
ejecutar
La información que debe
producir
www.senati.edu.pe
Interacción La interfaz gráfica usuario-

Usuario-
Sistema sistema (GUI)
Atributos de Seguridad, facilidad de uso,
Calidad
documentación, utilidad, etc.
www.senati.edu.pe
RestriccionesLa plataforma de operación del
de Operación sistema
La tecnología de información
que debe usar
Las interfaces con otros
sistemas
www.senati.edu.pe
Tipos de Requisitos
Funcionales No Funcionales
De Usuario De Sistema
www.senati.edu.pe
Requisitos Funcionales
• Describe la funcionalidad o los servicios que se espera
que el sistema de software proveerá.
• La interacción entre el sistema de software y su
ambiente o contexto.
• Como el sistema deberá actuar bajo ciertos estímulos o
eventos.
www.senati.edu.pe
Requisitos Funcionales: Ejemplos
R-024:
El sistema debe permitir el registro de nuevos usuarios en el
foro, los nuevos usuarios deben ser aprobados o rechazados
por un moderador antes de poder publicar mensajes
R-101:
Los usuarios deben poder intercambiar mensajes y
comunicarse por medio del foro, toda la comunicación debe
estar moderada para evitar conductas inapropiadas por parte
de los usuarios, mensajes basura y publicidad no deseada
www.senati.edu.pe
Requisitos No Funcionales
• No se refieren directamente a las propiedades
funcionales del sistema, sino a sus propiedades
emergentes o a restricciones adicionales en el sistema o
en el proyecto de desarrollo de software.
www.senati.edu.pe
• Definen restricciones adicionales al sistema, tales como:
o La plataforma de operación del sistema
o La tecnología de información que debe usar
o Las interfaces con otros sistemas
o Interacción Usuario / Sistema
o Atributos de Calidad
www.senati.edu.pe
R-401:
El sistema debe ser utilizable por medio de una interfaz WEB
R-517:
Se debe utilizar RUP como proceso de desarrollo del software
R-581:
El tiempo de respuesta del sistema al solicitar un reporte
nunca debe ser mayor a 10 segundos
www.senati.edu.pe
Requisitos de Usuario
• Son aquellos que están dirigidos a los usuarios y clientes
(interesados en general) del sistema. Se redactan
usando lenguaje natural (generalmente) de forma “no
técnica” con el objetivo de que el personal no técnico
los pueda entender.
DER: Documento de Especificación de Requerimientos
www.senati.edu.pe
Requisitos de Sistema
• Son aquellos dirigidos a personal técnico: analistas,
programadores, arquitectos, ingenieros, etcétera.
• Generalmente están escritos en un lenguaje mucho más
técnico pero mucho más preciso que los requerimientos
de usuario.
DDR: Documento de Definición de Requerimientos
www.senati.edu.pe
¿ Y cómo se obtienen ?
www.senati.edu.pe
Ingeniería de Requisitos
• Es el proceso de establecer los servicios que debe
proporcionar un sistema, así como de las restricciones
sobre las cuales debe operar.
Ingeniería => Enfoque Sistemático
www.senati.edu.pe
Procesos de la Ingeniería de Requisitos
• Proceso de establecimiento de los servicios que debe
proporcionar un sistema, así como de las restricciones
sobre las cuales debe operar.
Captura Análisis Especificación Validación
www.senati.edu.pe
• Es la actividad por medio de la cual se obtienen

(capturan) los requerimientos.
 Entrevistas
 Observación Directa
 Modelo de Negocios
 Lectura / Análisis de Documentos
 Prototipos
www.senati.edu.pe
• Es la actividad por medio de la cual se extiende el

modelo de requisitos, se buscan y localizan errores,
inconsistencias, limitaciones, carencias, etcétera....
 Inspección de Documentos
 Discusiones / Entrevistas / Talleres
 Desarrollo de prototipos
… muchas de las técnicas de captura
www.senati.edu.pe
• Es la actividad por medio de la cual se documentan

(escriben / se ponen en “blanco y negro”) los
requerimientos
¡Si los requerimientos no están por escrito (de alguna manera), entonces NO SIRVEN!
www.senati.edu.pe
• Es la actividad por medio de la cual se VALIDAN los

requerimientos con el cliente.
 Inspección de Documentos
 Discusiones / Entrevistas / Talleres
… muchas de las técnicas de captura
!Esta actividad es crítica. Si los requerimientos no se han validado, entonces NO SIRVEN!
www.senati.edu.pe
¿ Cómo se documentan ?
Requisitos / Requerimientos
www.senati.edu.pe
Documentando requisitos
• Descripciones en Lenguaje Natural.
Se desea desarrollar un sistema de software para la comisaría de Los Olivos.
Entre los requerimientos, hay un proceso que consiste en la gestión de las armas y municiones de la armería
de la policía. El proceso contempla la entrega de armas a los agentes policiales, la devolución de las armas al
parque, las pruebas y validaciones de ley que se realizan a las armas después de la entrega y finalmente,
cualquier proceso de investigación posterior en caso de que el armamento haya sido disparado.
Después de conversar con el comisario sobre el funcionamiento del proceso en discusión, se puede resumir
la conversación de la siguiente forma: Es necesario un proceso que sirva para gestionar la entrega de
armamento del parque de armas a los “Agentes Policiales”. En general, los Agentes se presentan al
“Encargado del Parque de Armas” y solicitan cierto armamento. El Encargado del Parque busca el
armamento solicitado en el inventario y si éste se encuentra disponible se lo entrega al Agente. Si el
armamento no se encuentra disponible el proceso termina. La entrega ocurre sólo luego de que el Agente
llene y firme una “Planilla de Retiro de Armamento”. La planilla tiene información sobre la fecha en que se
entrega el arma al Agente, el serial del arma y la cantidad y tipo de munición entregada. Luego de llenar la
planilla, el Encargado entrega el arma y las municiones al Agente, quien debe revisarlas y poner en la
planilla cualquier observación o desacuerdo que corresponda al estado de las mismas en caso de ser
necesario.
www.senati.edu.pe
Documentando requisitos
• Plantilla VOLERE.
www.senati.edu.pe
Nº Req: RF-38 Tipo: Funcional Caso de Uso: CU-13
Descripción:
Los usuarios deben poder intercambiar mensajes y comunicarse por medio del foro, toda la comunicación debe estar moderada para
evitar conductas inapropiadas por parte de los usuarios, mensajes basura y publicidad no deseada.
Justificación del requisito:

Esta es la razón de ser del sistema, el objetivo principal de un foro WEB es permitir intercambiar mensajes entre usuarios.
Fuente: Unidad en la que se origina:
Pedro Moreno – Analista Académico Departamento Académico
Criterios de validación:
El usuario debe poder publicar un mensaje. El mensaje no debe aparecer hasta que un moderador lo acepte. Si un moderador acepta el
mensaje entonces éste aparece publicado. Si un moderador rechaza el mensaje entonces éste no es publicado.
Nivel de satisfacción del interesado: 3 Nivel de insatisfacción del interesado: 5

Dependencias: 35, 48 Conflictos: 55, 40
Prioridad: 05 Material de soporte: Términos y condiciones de uso
Histórico de cambios:
01-Marzo-2018 – Jose Hernandez
www.senati.edu.pe
10-Marzo-2018 – Maria Jimenez
Descripción:
Calcular el promedio diario, mensual y anual de precipitación en cada una de las estaciones climatológicas del país.

Es necesario para elaborar los reportes diarios, mensuales y anuales de precipitación.
Juan Peña – Especialista División de Climatología
Los valores obtenidos se compararán con los obtenidos en años pasados para determinar si hay inconsistencias.

Dependencias: 05, 18 Conflictos: 027
Prioridad: 03 Material de soporte: Manual de Precipitación
10-Febrero-2018 – Martha Castañeda
www.senati.edu.pe
Modelos Ágiles: Historias de Usuario
• Es una narración que describe una funcionalidad del
sistema que tiene valor para el usuario.
• Los requisitos se capturan teniendo en cuenta la visión
del cliente y del usuario.
• Se recoge en unas sencillas tarjetas de forma
esquemática y en un lenguaje claro que describa una
historia de interacción entre el usuario y el sistema
www.senati.edu.pe
Modelos Ágiles: Historias de Usuario
Alta de nuevos usuarios
Yo como administrador del sistema de ¿Quién?

foros web, quisiera poder aceptar o ¿Qué?
rechazar el registro de nuevos usuarios,
para así evitar spammers. ¿Por qué?
www.senati.edu.pe
Recuerde siempre:
• Que los requerimientos se pueden “priorizar”, es decir,
algunos requerimientos siempre serán mas importantes
para el cliente o más críticos para el negocio que otros.
• En función de estas prioridades se puede decidir cuales
requerimientos entregar, cuales no y así jugar con los
costos y los tiempos de desarrollo (afectando lo menos
posible la satisfacción del cliente / usuario).
www.senati.edu.pe
Cuadro Resumen de Requerimientos
No.REQ Descripción Caso de Uso Prioridad

RF-001 Login del usuario CU-05 5
RF-002 Registro de nuevo usuario CU-10, CU05 5
RF-003 Eliminar usuario CU-13 3
RF-004 Desafiliarse del foro CU-07 1
RF-005 Restricción de mensajes CU-08 5
www.senati.edu.pe
Documento ERS
www.senati.edu.pe
El estándar IEEE 830
• El estándar IEEE 830 define las características de una
buena Especificación de Requisitos de Software (ERS).
Institute Of Electrical And Electronics Engineers
www.senati.edu.pe
Utilidad del estándar IEEE 830:
• Un cliente describa claramente lo que quiere.
• Un proveedor entienda claramente lo que el cliente
quiere.
• Se establezcan bases para un contrato de desarrollo.
• Se reduzca el esfuerzo de análisis, diseño, y
programación, evitando re-procesos.
www.senati.edu.pe
El estándar IEEE 830: es útil para
• Se tenga una base o referencia para validar o probar el
software solicitado
• Se facilite el traspaso del software a otros
clientes/usuarios
• Se le puedan hacer mejoras (o innovaciones) a ese
software.
www.senati.edu.pe
Prácticas recomendadas para una
buena ERS
• Completa. Todos los requerimientos deben estar
reflejados en ella y todas las referencias deben
estar definidas.
• Consistente. Debe ser coherente con los propios
requerimientos y también con otros
documentos de especificación.
www.senati.edu.pe
buena ERS
• Inequívoca. La redacción debe ser clara de modo que no
se pueda mal interpretar.
• Correcta. El software debe cumplir con los requisitos de
la especificación.
www.senati.edu.pe
buena ERS
• Trazable. Se refiere a la posibilidad de verificar la
historia, ubicación o aplicación de un ítem a través
de su identificación almacenada y documentada.
• Priorizable. Los requisitos deben poder
organizarse jerárquicamente según su relevancia
para el negocio y clasificándolos en esenciales,
condicionales y opcionales.
www.senati.edu.pe
buena ERS
• Modificable. Aunque todo requerimiento es
modificable, se refiere a que debe ser fácilmente
modificable
• Verificable. Debe existir un método para poder probarlo
www.senati.edu.pe
Estructura Documento ERS (IEEE 830)
Introducción
Descripción General
Requisitos Específicos
Apéndices
www.senati.edu.pe
Introducción
• En esta sección se proporcionará una introducción a todo el
documento de Especificación de Requisitos Software(ERS).
Consta de las siguientes subsecciones:
Propósito, Ámbito del sistema, Definiciones, Referencias, Visión

general del documento.
www.senati.edu.pe
Descripción General
• En esta sección se describen todos aquellos factores que
afectan al producto y a sus requisitos. No se describe todo el
requisitos, sino su contexto.
• Esto permitirá definir con detalle los requisitos en la sección 3,
haciendo que sean más fáciles de entender.
• Esta sección consta de las siguientes subsecciones:
Perspectiva del producto, funciones del producto, características
de los usuarios, restricciones, factores que se asumen y futuros
requisitos.
www.senati.edu.pe
Requisitos Específicos
• Esta sección contiene los requisitos a un nivel de detalle
suficiente como para permitir a los diseñadores diseñar un
sistema que satisfaga estos requisitos, y que permita al equipo
de pruebas planificar y realizar las pruebas que demuestren si
el sistema satisface, o no, los requisitos. Todo requisito aquí
especificado describirá comportamientos externos del sistema,
perceptibles por parte de los usuarios, operadores y otros
sistemas. Esta es la sección más larga e importante de la ERS.
www.senati.edu.pe
Apéndices
• Pueden contener todo tipo de información relevante para la
ERS pero que, propiamente, no forme parte de la ERS.
www.senati.edu.pe
METODOLOGIAS
www.senati.edu.pe
www.senati.edu.pe
Proceso Racional Unificado
• Es un proceso de Ingeniería de Software que proporciona un
enfoque disciplinado para la asignación de tareas y
responsabilidades dentro de una organización de desarrollo.
www.senati.edu.pe
Proceso Racional Unificado
• Se tiene 2 dimensiones:
• Un eje horizontal que representa el tiempo (“n” iteraciones) y
muestra los aspectos del ciclo de vida del proceso (4 fases)
• Un eje vertical que representa las 9 disciplinas (flujos de
trabajo), las cuales agrupan actividades de una manera lógica
de acuerdo a su naturaleza.
www.senati.edu.pe
RUP - FASES
• FASES del desarrollo de un software:
FASE OBJETIVO Punto de Control
Inicio Entender que se va a construir. Objetivo del proyecto
Elaboración Entender cómo se va a construir Arquitectura de la Aplicación
Construcción Construir una versión Beta Versión Operativa Inicial
Transición Construir la versión Final Liberación de la versión final
www.senati.edu.pe
FASE DE INICIO
• Durante la fase inicial, se establece el modelo de negocio para el sistema y
delimitar el alcance del proyecto.
• Se debe identificar todas las entidades externas con las que el sistema va a
interactuar (actores) y definir la naturaleza de esta interacción a un alto
nivel.
• Esto implica identificar todos los casos de uso y la descripción de unos
pocos significativos.
• El modelo de negocio incluye criterios de éxito, evaluación de riesgos y
estimación de los recursos necesarios, y un plan de fases que muestra las
fechas de los hitos más importantes.
www.senati.edu.pe
Entregables en Fase de Inicio
• Un documento de visión: una visión general de los requisitos del proyecto básico, las
funciones principales y las limitaciones principales.
• Un modelo de casos de uso inicial (10% -20%) completa.
• Un glosario proyecto inicial.
• Un caso de negocio inicial: contexto empresarial, criterios de éxito (proyección de ingresos,
el reconocimiento del mercado, y así sucesivamente), y el pronóstico financiero.
• Una evaluación inicial de riesgos.
• Un plan del proyecto: que muestra fases e iteraciones.
• Un modelo de negocio (si es necesario).
• Uno o varios prototipos.
www.senati.edu.pe
FASE DE ELABORACION
• Analizar el dominio del problema, establecer una base arquitectónica
sólida, desarrollar el plan del proyecto, y eliminar los elementos de más
riesgo del proyecto.
• Las decisiones arquitectónicas deben tomarse teniendo en cuenta todo el
sistema: su alcance, funcionalidad principal y requisitos no funcionales,
como los requisitos de rendimiento.
• Esta es la fase más critica de las 4 fases.
• Se toma la decisión de comprometerse o no con las fases de construcción y
transición
www.senati.edu.pe
Entregables en la Fase de Elaboración
• Un modelado de casos de uso (por lo menos 80% completa): todos los casos de
uso y actores han sido identificados, y las descripciones de casos uso se han desarrollado.
• Captura de requisitos suplementarios, requisitos no funcionales y requisitos
que no están asociados con un caso de uso específico
• Descripción de la Arquitectura de Software.
• Un prototipo arquitectónico ejecutable
• Una lista revisada de riesgos y un modelo de negocio revisado.
• Un plan de desarrollo de todo el proyecto, mostrando iteraciones y criterios
de evaluación para cada iteración.
• Un caso de desarrollo actualizado especificando el proceso que se utilizará.
• Un manual de usuario preliminar (opcional).
www.senati.edu.pe
FASE DE CONSTRUCCION
• Se desarrollan todos los componentes y características restantes de la
aplicación y se integran en el producto.
• Todas las características se prueban exhaustivamente.
• Esta fase, en cierto sentido, es un proceso de fabricación
• Aquí se hace gestión de los recursos y el control de las operaciones para
optimizar los costes, los horarios y la calidad.
• En muchos casos se puedan generar actividades paralelas. Estas pueden
acelerar significativamente la disponibilidad de lanzamientos desplegables.
(A costa de la complejidad de la gestión de recursos y la sincronización del flujo de trabajo)
www.senati.edu.pe
Entregables en la Fase de Construcción
• El producto de software integrado en las plataformas adecuadas listo para ser
utilizado por los usuarios finales.
• Los manuales de usuario.
• Una descripción de la versión actual
www.senati.edu.pe
FASE DE TRANSISION
• El propósito de esta fase es hacer la transición del producto de software a
la comunidad de usuarios.
• Una vez que el producto ha sido entregado al usuario final, generalmente
surgen problemas por lo que se requiere el desarrollo de nuevas versiones,
corregir algunos problemas o finalizar las funciones que se pospusieron.
• Se ingresa a la fase de transición cuando una línea de base es lo
suficientemente madura como para desplegarse.
• Esto requiere que alguna parte del sistema, se haya completado a un nivel
aceptable de calidad y que la documentación del usuario esté disponible.
• Incluye varias iteraciones que incluyen versiones beta, así como versiones
de reparación de errores y mejoras.
www.senati.edu.pe
Entregables en la Fase de Transición
• “Versión beta" para ser validado por el usuario
• Operación en paralelo con el sistema heredado, que se está reemplazando.
• Conversión de las bases de datos en operación.
• Entrenamiento de usuarios finales y usuarios de mantenimiento.
• Lanzar el producto a los equipos de marketing, distribución y ventas de ser el
caso.
www.senati.edu.pe
ITERACIONES DE UNA FASE
• Cada fase en RUP se puede dividir en iteraciones.
• Una iteración es un ciclo de desarrollo completo que da algún resultado, y que
crece de manera gradual de iteración a iteración, hasta convertirse en el
sistema final.
• Beneficios de un enfoque iterativo
• Los riesgos se mitigan antes
• El cambio es más manejable
• Mayor nivel de reutilización
• El equipo del proyecto puede aprender a lo largo del camino
• Mejora de la calidad en general
www.senati.edu.pe
ESTRUCTURA ESTATICA DEL
PROCESO
• El RUP se representa utilizando cuatro elementos de
modelado:
• Trabajadores, el 'quién'
• Actividades, el 'cómo'
• Artefactos, el 'qué'
• Flujos de trabajo, el 'cuándo'
www.senati.edu.pe
Trabajadores, Actividades y Artefactos
Actividades
Trabajador
Análisis de Caso de Uso Análisis de Caso de Uso

Diseñador
Responsable de
Artefacto
Realización del Caso de Uso
www.senati.edu.pe
Personas y Trabajadores
Recurso Trabajador Actividades
Paul Diseñador Diseñando objetos
Mary Autor Caso de Uso Detallando caso de uso
Joe Diseñador Caso de Uso Diseñador Caso de Uso
Sylvia Revisor de Diseño Revisando el Diseño
Stefan Arquitecto Analizando la arquitectura

Diseñando la arquitectura
www.senati.edu.pe
Flujo de Trabajo
www.senati.edu.pe
Flujo de Trabajo (Disciplinas)
• En RUP hay 09 flujos de trabajo de procesos centrales:
DISCIPLINAS
• Representan una particionamiento de todos los
trabajadores y actividades en agrupaciones lógicas.
www.senati.edu.pe
Flujo de Trabajo (Disciplinas)
• Principales: • De apoyo:
• Modelado de • Gestión de proyectos
negocio • Configuración y gestión de
• Requisitos cambios
• Análisis y diseño • Entorno.
• Implementación
• Prueba
• Despliegue
www.senati.edu.pe
RUP
• El esfuerzo varía
en cada
disciplina y
según la fase.
www.senati.edu.pe
SCRUM
www.senati.edu.pe
Agilidad
En marzo de 2001, 17 profesionales del software, críticos de los modelos de producción
basados en procesos, se reunieron y postularon el:
www.senati.edu.pe
Métodos Ágiles
• Se denominan así a aquellos métodos que surgen como
alternativa a las metodologías formales, considerados
excesivamente “pesados” y rígidos por su carácter normativo y
fuerte dependencia de planificaciones detalladas, previas al
desarrollo.
www.senati.edu.pe
Scrum
• Es un modelo de desarrollo ágil caracterizado por:
• Adoptar una estrategia de desarrollo incremental, en lugar de
la planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de
las personas en equipos autoorganizados, que en la calidad de
los procesos empleados.
• Solapamiento de las diferentes fases del desarrollo, en lugar de
realizarlas una tras otra en un ciclo secuencial o de cascada.
www.senati.edu.pe
El Sprint
• Se denomina sprint a cada ciclo o iteración de trabajo que
produce una parte del producto terminado y funcionalmente
operativo.
www.senati.edu.pe
Iteraciones
1
Product Iteración 1
Backlog Sprint Entregable
Backlog (v1)
2
Iteración 2
Sprint Entregable
Backlog (v2)
3
Iteración 3
Sprint Entregable
... Backlog (v3)
www.senati.edu.pe
Roles de Scrum
www.senati.edu.pe
Product Owner
• Representa la voz del cliente y aporta la visión de negocio. Se
encarga de escribir las historias de usuario, les da prioridad y las
ubica en la lista de requisitos del producto (product backlog).
• Se encarga de decidir que va y que no va en el product backlog,
así como definir las prioridades de las distintas historias de
usuario
www.senati.edu.pe
Historias de Usuario
Alta de nuevos usuarios
Yo como administrador del sistema de ¿Quién?

foros web, quisiera poder aceptar o ¿Qué?
rechazar el registro de nuevos usuarios,
para así evitar spammers. ¿Por qué?
www.senati.edu.pe
Descripción:
Los usuarios deben poder intercambiar mensajes y comunicarse por medio del foro, toda la comunicación debe estar moderada para
evitar conductas inapropiadas por parte de los usuarios, mensajes basura y publicidad no deseada.

Esta es la razón de ser del sistema, el objetivo principal de un foro WEB es permitir intercambiar mensajes entre usuarios.
Pedro Moreno – Analista Académico Departamento Académico
El usuario debe poder publicar un mensaje. El mensaje no debe aparecer hasta que un moderador lo acepte. Si un moderador acepta el
mensaje entonces éste aparece publicado. Si un moderador rechaza el mensaje entonces éste no es publicado.

Dependencias: 35, 48 Conflictos: 55, 40
Prioridad: 05 Material de soporte: Términos y condiciones de uso
01-Marzo-2018 – Jose Hernandez
www.senati.edu.pe
10-Marzo-2018 – Maria Jimenez
Scrum Master
• Tiene como principal papel el de dejar el camino libre de
obstáculos e impedimentos para que el resto del equipo consiga
el objetivo del sprint.
• Organiza reuniones, hace seguimiento del trabajo que se está
llevando a cabo y apoya en la planificación de los sprints /
entregas
www.senati.edu.pe
Development Team
• Está compuesto por los roles tradicionales:
• Desarrolladores
• Funcionales
• ….
www.senati.edu.pe
Evento: Sprint Planning
• Es la planificación del Sprint. Este plan se crea mediante el
trabajo colaborativo del Equipo Scrum completo.
• La Planificación de Sprint tiene un máximo de duración de ocho
horas para un Sprint de un mes.
• Responde a:
• ¿Qué puede entregarse en el siguiente Sprint?
• ¿Cómo se conseguirá hacer el trabajo necesario para
entregar el incremento?
www.senati.edu.pe
Evento: Sprint Planning
Los requisitos del product backlog se
priorizan y se asignan al sprint backlog.
Product
Backlog
Sprint
Backlog
Lista de Requisitos Requisitos a trabajar

www.senati.edu.pe
Evento: Daily Scrum
• Es una reunión diaria de 15 minutos para el Equipo de Desarrollo.
• El Equipo de Desarrollo planea el trabajo para las siguientes 24
horas.
www.senati.edu.pe
Evento: Sprint Review
• Es la reunión que se realiza al finalizar el sprint y tiene una
duración máxima de 4 horas.
• Asiste todo el Equipo Scrum y los interesados clave, invitados por
el Product Owner.
• Si es necesario se agregan nuevos requerimientos al Product
Backlog y/o cambiar las prioridades y/o refinar los
requerimientos existentes.
www.senati.edu.pe
Evento: Sprint Review
• El Product Owner explica qué elementos del Product Backlog se
han “Terminado” y cuales no. Proyecta objetivos probables y
fechas de entrega en el tiempo.
• El Equipo de Desarrollo habla acerca de qué estuvo bien durante
el Sprint, qué problemas aparecieron y cómo fueron resueltos
esos problemas.
• El Equipo de Desarrollo hace una demostración del trabajo que
ha “Terminado” y responde preguntas.
www.senati.edu.pe
Evento: Sprint Retrospective
• Es una reunión posterior al Sprint Review de 3 horas como
máximo.
• Inspeccionar cómo fue el último Sprint en cuanto a personas,
relaciones, procesos y herramientas
• Identificar y ordenar los elementos más importantes que salieron
bien y las posibles mejoras
• Crear un plan para implementar las mejoras a la forma en la que
el Equipo Scrum desempeña su trabajo.
www.senati.edu.pe
Artefacto: Product Backlog
• El Product Backlog es una lista ordenada de todos los
requerimientos.
• El Product Owner es el responsable del Product Backlog,
incluyendo su contenido, disponibilidad y orden.
• El Product Backlog nunca está completo. La versión inicial solo
refleja los requisitos conocidos y mejor entendidos al principio.
• Ésta evoluciona a medida de que el producto y el entorno en el
que se usará, también lo hacen.
www.senati.edu.pe
Artefacto: Sprint Backlog
• Es el conjunto de elementos del Product Backlog, que se han
seleccionado para el Sprint.
• Es una predicción hecha por el Equipo de Desarrollo acerca de
qué funcionalidad formará parte del próximo Incremento
www.senati.edu.pe
Scrum
Scrum
www.senati.edu.pe
Herramienta CASE
(Computer Aided Software Engineering)
Ingeniería de Software Asistida por Computadora
www.senati.edu.pe
Herramienta CASE
• Son diversas aplicaciones informáticas o programas informáticos
destinadas a aumentar la productividad en el desarrollo de
software reduciendo el costo de las mismas en términos de
tiempo y de dinero.
• Upper CASE (U-CASE), herramientas que ayudan en las fases de
planificación, análisis de requisitos y estrategia del desarrollo,
usando, entre otros diagramas UML.
• Middle CASE (M-CASE), herramientas para automatizar tareas en
el análisis y diseño de la aplicación.
www.senati.edu.pe
Herramienta CASE
• Lower CASE (L-CASE), herramientas que semi-automatizan la
generación de código, crean programas de detección de errores,
soportan la depuración de programas y pruebas. Además
automatizan la documentación completa de la aplicación. Aquí
pueden incluirse las herramientas de desarrollo rápido de
aplicaciones.
• Algunos ejemplos: Erwin, Easy Case, Oracle Designer, Power
Designer
www.senati.edu.pe
www.senati.edu.pe

Desarrollo de Software - IV - Ingeneria de Software-1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Software - IV - Ingeneria de Software-1 PDF

Cargado por

Copyright:

Formatos disponibles

www.senati.edu.

• Conjunto de elementos orientados al tratamiento y

• Definición: El proceso que se sigue para construir, entregar y hacer

• Permite cumplir con los plazos de entrega.

• Permite agregar componentes funcionales.

• Incorpora un análisis de riesgos

• Se enfoca en la calidad del software.

“Crisis del Software”

Utilizado, pero con trabajo extra o Entregado y nunca usado

Pagado y nunca entregado

Exitoso Con Cambios Fallado Informe CHAOS 2015

Grande Largo Mediano Moderado Pequeño

 Formalización, con nuevos modelos de desarrollo y

 Las técnicas de gestión de proyectos de ingeniería, también

 El software es intangible y flexible.

Lo que el cliente quiere que haga...

Todo lo que el cliente quiere que haga...

Nada más aquello que el cliente quiere que haga...

Interacción La interfaz gráfica usuario-

DER: Documento de Especificación de Requerimientos

DDR: Documento de Definición de Requerimientos

Ingeniería => Enfoque Sistemático

Captura Análisis Especificación Validación

• Es la actividad por medio de la cual se obtienen

• Es la actividad por medio de la cual se extiende el

• Es la actividad por medio de la cual se documentan

• Es la actividad por medio de la cual se VALIDAN los

Justificación del requisito:

Nivel de satisfacción del interesado: 3 Nivel de insatisfacción del interesado: 5

Justificación del requisito:

Nivel de satisfacción del interesado: 5 Nivel de insatisfacción del interesado: 2

Yo como administrador del sistema de ¿Quién?

No.REQ Descripción Caso de Uso Prioridad

Institute Of Electrical And Electronics Engineers

Propósito, Ámbito del sistema, Definiciones, Referencias, Visión

Inicio Entender que se va a construir. Objetivo del proyecto

Elaboración Entender cómo se va a construir Arquitectura de la Aplicación

Construcción Construir una versión Beta Versión Operativa Inicial

Transición Construir la versión Final Liberación de la versión final

Análisis de Caso de Uso Análisis de Caso de Uso

Realización del Caso de Uso

Recurso Trabajador Actividades

Paul Diseñador Diseñando objetos

Mary Autor Caso de Uso Detallando caso de uso

Joe Diseñador Caso de Uso Diseñador Caso de Uso

Sylvia Revisor de Diseño Revisando el Diseño

Stefan Arquitecto Analizando la arquitectura

Yo como administrador del sistema de ¿Quién?

Justificación del requisito:

Nivel de satisfacción del interesado: 3 Nivel de insatisfacción del interesado: 5

Lista de Requisitos Requisitos a trabajar

También podría gustarte