Unidad II Metodologías

de desarrollo
 2.1Roles y
responsabilidades
 Es una figura que adquiere una
persona y que conlleva ciertas
responsabilidades o comportamientos
asociados.
En el desarrollo de software, los
integrantes de un equipo adquieren
Rol rol o roles según la función que
desempeñen.
El rol es independiente del puesto (o
por lo menos no hay ningún motivo
para que dependa de él) y una misma
persona puede desempeñar varios
roles al mismo tiempo.
 cliente

líder de proyecto/administrador

analista

roles arquitecto / de soFware

diseñador

programador

tester
 • Es la enHdad (o persona
representante) que Hene la
necesidad de un sistema o soFware
nuevo (o de la modificación de uno
ya existente).

• Una parte importante relaHva al

cliente es el usuario operador, que
Cliente es la persona concreta que va a
uHlizar el sistema. Puede, y es
además bastante probable, que el
cliente o dueño final del sistema a
construir no sea la misma persona
que el usuario.
•
 • El administrador de
proyecto es la
persona que
administra y controla
Líder del los recursos
proyecto o asignados a un
proyecto, con el
admiistrador propósito de que se
cumplan
correctamente los
planes.
 analista
La palabra “análisis” se
refiere a una caracterísHca
Rpicamente relacionada con
la inteligencia humana. Esta
se refiere a la habilidad de
poder estudiar un problema
de una complejidad
determinada,
descomponiendo el
problema en subproblemas
de menor complejidad.
 El rol de arquitecto es
uno de los mas
confusos que existen
(asumiendo a veces
roles de programador
arquitecto o diseñador), pero en
esencia debe
encargarse del sistema
a un nivel "macro".
 Diseñador
Es el responsable de converHr
los requisitos obtenidos por el
analista, en "algo" que se pueda
traducir en soFware, mediante
las guías e indicaciones de la
arquitectura de soFware.

Se encarga de definir el sistema

en un nivel detallado y
concreto. El diseñador indicará
qué componentes y de qué
forma se relacionan dentro del
sistema y en la lógica de
negocio.
 Los programadores deben
converHr la especificación del
sistema en código fuente
ejecutable uHlizando uno o
programador más lenguajes de
programación, así como
herramientas de soFware de
apoyo a la programación.
Tester

Es el encargado de validar que el

soFware cumpla con los criterios
de calidad establecidos, es decir
que el soFware funcione.
 Investigar el perfil de cada rol o
características

¿Con qué rol o roles cree usted que se

identifica? ¿ Por qué?.

AcHvidad 7 Para tarea

/ tarea 2
Complemente la acHvidad 7, invesHgando
funciones o responsabilidades, relación con
otros roles

*agregue referencias
Líder del proyecto /administrador
Analista

Diseñadores

Tester

ASC

Mantenimiento
 acHvidades
• Desarrollo eficiente de reuniones
• Desarrollo organizacional –visión, misión,
metas, objetivos
• Entregar un plan de trabajo general basado en
diagramas Gantt y de flujo de actividades,
apoyado con el plan de trabajo de cada rol
 Plan de trabajo
• Definir y establecer estándares a seguir por el
grupo.
• Definir una estructura organizacional y hacer un
diagrama organizacional.
• Capacitar al grupo en las metodologías y
estándares a uHlizar.
• Crear un modelo de ciclo de vida para el
proyecto.
• Definir un plan y protocolo para desarrollo de
reuniones.
• Definir una agenda de reuniones con cada rol.
• Construir un plan de trabajo específico que
contenga diagramas Gana y de flujo de
acHvidades.
• Definir protocolos para asignar y evaluar
acHvidades. Nótese que durante el proyecto,
será necesario redefinir tareas, y con ello,
miembros del equipo deberán alterar su carga
de trabajo para realizarlas.
• Realizar estimación de horas-hombre por
actividad y por persona.
• Realizar reuniones generales para evaluación y
planificación.
• Realizar un contrato con el cliente que defina
las características y condiciones en que se
desarrollará el producto.
 Analista
Administrador de proyecto

Diseñador

Programador

Tester

ASC

Documentador

ADC
 Actividades

Definir una
estructura básica
del sistema que
Entrevistar al
Verificar si los incluya fuentes de
cliente,
requisitos información,
ayudándole a
especificados son módulos de
identificar sus
los correctos procesamiento de
necesidades
información, y
resultados
esperados
 Actividades

Realizar el Analizar la Generar los

análisis de los estructura básica diagramas de la
requisitos. del sistema. arquitectura.
 Preparar un documento con preguntas a realizar al cliente
durante las entrevistas.

Determinar las fechas de reunión con el cliente.

Plan de Generar un documento de especificación de requisitos de

usuario en base a los acuerdos alcanzados en la primera

trabajo reunión.

Presentación del documento de especificación al cliente en

la siguiente reunión.

De ser necesario, realizar las modificaciones al documento

de especificación de requisitos de usuario y presentarlas al
cliente en la próxima reunión. Repetir esta actividad las
veces que sea necesario.
 Construir el documento de
requisitos de soFware.
Plan de
trabajo Revisar el documento con los
ingenieros de aseguramiento
de la calidad y cliente,
realizando modificaciones de
ser necesario.
Requerimientos Funcionales - no
funcionales
 Documentos

Usuarios de un documento de
requerimientos
Formas de escribir una especificación
Actividad 10 Leer el capitulo 4 de la bibliograia
-Beginning SoFware Engineering

Realizar un resumen conforme el

bloque asignado

Preparar una breve exposición

Exponerla en clases
 Tarea 3

Desarrollar con la información recabada los

requerimientos del Proyecto.
 Diseñador
Administrador de proyecto

Analista

Programador

Tester

ASC

Ing. de V&v

Documentador

ADC

Ing. de manto
 AcHvidades

Definir la Seleccionar una

técnica de
Descomposición administración de administración de
de subsistemas acceso arecursos almacenamiento de
globales datos
 Actividades

Especificaciones
Modelos de caso
de los documentación
de usos
requerimientos
 Que debe de contener
• Un diseño debe contener una organización jerárquica que haga un
uso inteligente del control entre los elementos del soFware.
• Un diseño debe ser modular. En otras palabras, el sistema debe
estar parHcionado lógicamente en elementos que realizan
funciones y subfunciones específicas.
• Un diseño debe contener abstracciones de datos y abstracciones
procedurales.
• Un diseño debe conducir a módulos (esto es, subruHnas o
procedimientos), que muestren caracterísHcas funcionales
independientes.
• Un diseño debe considerar interfaces que reduzcan la complejidad
de conexiones entre módulos y con el ambiente externo.
• Un diseño debiese ser construido usando un método repeHble,
guiado por la información obtenida durante la fase de requisitos de
soFware.
 Propiedades
Diseño Introducción
Paquete de diseño
Clases/objetos
Relaciones
Diagramas
Concurrencia
Capas
 Metodologías/herramientas
Metodología
Orientada a objetos
algorítmica
Herramientas
UML
 UML

Diagramas de Diagramas de Diagramas de

caso estados clase

Diagramas de
Diagramas de Diagramas de
entidad-
colaboración acHvidades
relación
 AcHvidad de
escape 11

IdenHfique cuáles de
Investigar cuales son
ellos se requieren
los requerimientos no
para el proyecto de
funcionales
vinculación WinePlan
 Programador
Administrador de proyecto

Analista

Diseñandor

Tester

ASC

Documentador

ADC

Ing. de mantenimiento
 Los programadores
deben converHr la
especificación del
sistema en código
fuente ejecutable
programador uHlizando uno o más
lenguajes de
programación, así
como herramientas de
soFware de apoyo a la
programación.
 • Menor cantidad de
Uno de los
principales
problemas de prueba.
objeHvos de los • Aumento de la
programadores productividad de los
durante su trabajo
debe ser la de programadores.
reducir la • Aumento de la eficiencia
complejidad del
soFware. Algunos
en el mantenimiento del
de los beneficios programa.
que implican la • Aumento de la eficiencia
reducción de la
complejidad del en la modificación del
programa son: programa.
 • Reducir el Hempo de
codificación
• Disminuir errores
• Disminuir el esfuerzo
Otro de corregir errores en
secciones de código
objeHvos que se encuentran
deficientes,
reemplazándolas
• Disminuir los costos
del ciclo de vida del
soFware
 Explorar
• Diferentes ambientes en que se
puede desarrollar el sistema
• Diferentes herramientas
• DisHntos esHlos de codificación

Interactuar
AcHvidades • Diseñadores
• Equipo de pruebas
• Administrador de la configuración
Otras
• Documentación
• Realizar los cambios solicitados
• Reuniones para revisiones
 Tester
Analista

Diseñandor

Programador

Validación y verificación

ADC
El téster es el
encargado de • Construir y aplicar los planes de
asegurar la prueba unitarios, de módulo, de
sistema, y aceptación parcial,
calidad de manteniéndolos actualizados
cada uno de durante el proyecto.
los productos • Coordinar las inspecciones, y/o
(documentos, caminatas.
• Velar por la adhesión al estándar
protoHpos, adoptado para el desarrollo.
etc). Entre sus • Velar por la calidad del producto
tareas están: final (cumplimiento de los
requisitos).
 Actividades

PARTICIPACIÓN EN EL INTERACCIÓN CON EL REALIZAR LAS PRUEBAS, INFORMAR SOBRE LOS

PROCESO DE DISEÑADOR APOYADOS POR LOS RESULTADOS OBTENIDOS
ESPECIFICACIÓN DEL PROGRAMADORES
SISTEMA
 Plan de trabajo

Coordinarse Ejecutar las

con los pruebas:
ParHcipar en la
Construir el diseñadores •bajo, mediano y Construir la
revisión de los
plan de para incluir la alto nivel documentación
requisitos del
pruebas prueba de de las pruebas
sistema
diseño en el
documento
 • InvesHgue cuáles son
las técnicas que
Ac#vidad existen para detectar
12 y corregir errores
• Describa 3 casos de
pruebas para cada una
de ellas.
• IdenHfique una para el
proyecto WinePlan
Aseguramiento de la calidad
Administrador de proyecto

Analista

Diseñandor

Programador

Tester

Documentador

ADC
 Actividades

revisar

Polí9cas de
Fase de diseño
Documentos Plan del Plan de control de
detallado y
de requisitos proyecto pruebas cambios,
arquitectónico
configuración
Administrador de la configuración
Si los roles producen un ítem
de configuración de soFware
que ha sido idenHficado y Si pertenecen al Cuerpo de
puesto en el repositorio de Control de Cambios
administración de la
configuración de soFware.

Si solicitan un cambio de ítem

Si la persona debe
de la configuración de
implementar un cambio.
software
 Preguntas
Problemáticas: Modificaciones simultaneas, código común, versiones

Tener un sistema de control que te responda a las siguientes preguntas

¿Cuál es mi ¿Cómo ¿Cómo le ¿Qué cambios ¿Los cambios

configuración ¿Cuál es mi controlo informo al han sido realizados por
de soFware estatus? cambios en mi resto de mis hechos a mi otros afectan
actual? configuración? cambios? soFware? mi software?
 Elementos
IdenHficación de la configuración

Auditoría de la configuración

Control de configuración

Contabilidad del estatus de configuración

 AcHvidades
Preparar el Plan de Administración de la Configuración de
Software de acuerdo al estándar en uso.

Las tareas iniciales son iden;ficar las líneas base que serán
usadas en el proyecto, y los items que serán parte de cada
línea base.

Mantener un registro de cómo evolucionó el sistema y donde

está el sistema en cualquier instante respecto a su línea base y
acuerdos escritos. Esta actividad es la Contabilidad del Estatus
de la Configuración de Software, y provee los medios para
seguir la historia del ciclo de vida del sistema de software.
 Actividades
Preparar el Plan de Administración de la Configuración de SoFware de acuerdo al estándar en
uso.

Las tareas iniciales son iden;ficar las líneas base que serán usadas en el proyecto, y los items
que serán parte de cada línea base.

Mantener un registro de cómo evolucionó el sistema y donde está el sistema en cualquier

instante respecto a su línea base y acuerdos escritos. Esta ac;vidad es la Contabilidad del
Estatus de la Configuración de SoFware, y provee los medios para seguir la historia del ciclo de
vida del sistema de soFware.

Realizar RTF y/o auditorías de configuración de soFware. Estos son losmedios para asegurar que
se implementó correctamente el cambio.

Auditar los items de configuración. ( especificaciones, control de interfaces, documentos)

 Plan de trabajo
Planificar las ac;vidades principales de la administración de configuración de
soFware, y como se realizarán durante el ciclo de vida del soFware.

Escribir un Plan de Administración de Configuración de SoFware.

Elaborar las plantillas necesarias para solicitar un cambio: Propuesta de

Cambio de Ingeniería.

Diseñar y elaborar el repositorio central para mantener los items de

configuración de software identificados.

Estudiar herramientas que serán usadasa para accedser al repositorio

Una vez que el Auditorías de configuración de
soFware.
proyecto
empiece, debe IdenHficación de configuración de
realizar las soFware.
cinco
actividades Control de versiones.
principales
durante el Control de cambios de soFware.
ciclo de vida
del software Contabilidad del estatus de
configuración del soFware
Validación y verificación
Analista

Diseñandor

Programador

Tester
 Validación se refiere al proceso de
evaluación del so9ware al final de su
proceso de desarrollo para
asegurarse que está libre de fallas y
cumple con sus requisitos. Una falla
se define como un comportamiento
incorrecto del producto.
Definición
Verificación se refiere al proceso de
determinar si el producto en una
determinada fase del proceso de
desarrollo cumple con los requisitos
establecidos en la fase anterior. .
 AcHvidades
Administración de V&V
Planificación
Coordinación
Reportar
Monitoreo
Evaluación
 Documentador
Administrador de proyecto

Validación y verificación

ASC

Programador

Ing de manto

ADC
 El documentador debe diseñar y
construir un repositorio de información
compar9do, donde se almacenará la
documentación.

Mantener el repositorio de información.

El documentador debe agregar todos los
acHvidades nuevos documentos generados y
remplazar los documentos que fueron
modificados en el proceso de desarrollo.

Especificar el formato que será usado

para elaborar la documentación. El
formato especificado debe contemplar al
menos lo siguiente: 9po de letras y
colores, estructura caracterís9cas de las
figuras, textos.
Ing de mantenimiento
Administrador de proyecto

Analista

Diseñandor

Programador

Tester

ASC

V&V
 Mantenimiento
correcHvo

Mantenimiento
Metas/actividades
adaptaHvo

Mantenimiento
perfecHvo.
 Actividad de
escape

2.2 y 2.3
Lectura
Clasificación y Resumen
caracterísHcas de
las metodologías Exposición
 2.2 roles y metodologías

tradicionales ágiles

•diferencias •diferencias
 Roles en metodologías de desarrollo de so3ware
tradicionales.

En las metodologías de software tradiciones, se

sigue una secuencia de fases más o menos
estricta (que puede repetirse en varias vueltas o
ciclos). Cada fase tiene una entrada y una salida,
en las primeras fases (análisis y diseño), se
convierte las requisitos de usuarios, en
documentación, en las fases de construcción, se
“convierte” la documentación en software
 Documento de análisis
Propósito
En esta sección se define el nombre o Rtulo del
soFware que se está especificado en el documento,
incluyendo su número de versión o Release.
Luego se describe cuales componentes o partes del
alcance del producto están incluidas en el
documento, estableciendo si este documento cubre
la totalidad del soFware, sólo una parte del
sistema, subsistema o subgrupo de procesos.
 Documento
Alcance del producto / Software
Se incluye una corta descripción del alcance del software que
se está especificando, incluyendo:

Su propósito u objetivo general.

Beneficios que brinda al área de negocio y organización.
Objetivos y metas. Es recomendable establecer la relación de
los objetivos del software con los objetivos corporativos y
estrategias de negocio.
Se puede hacer referencia a otros documentos, por ejemplo
una definición de alcance u acta de constitución del proyecto.
Referencias

Aquí se pueden incluir otros documentos impresos,

documentos electrónicos o direcciones electrónicas que
complementen la documentación de requerimientos de
soFware, por ejemplo: Documentos de visión, definición de
alcance, otros documentos de especificación de
requerimientos de soFware, flujogramas, políHcas,
procedimientos de la organización, entre otros.

Para cada referencia es recomendable incluir el Rtulo, autor,

versión, fecha y ubicación isica o electrónica.
Funcionalidades del producto
Lista de las funcionalidades del software que se están
especificando en el documento de requerimientos. Cada
funcionalidad puede estar compuesta por uno o varios
requerimientos funcionales de software.

Aquí solo se incluye una lista numerada de las principales

funcionalidades, la información detallada de
requerimientos funcionales se documenta en la sección 7
de este documento.
•
Clases y caracterís?cas de usuarios
En esta sección se clasifican los usuarios que uHlizaran el producto. La
clasificación puede ser en función a la frecuencia de uso, grupo de
funcionalidades uHlizadas, privilegios de seguridad, nivel de experiencia y
otros parámetros.

Se puede usar una lista para enumerar los usuarios Hpo que uHlizarán el
soFware, describiendo las caracterísHcas de cada uno.

Para cada Hpo de usuario, se pueden mencionar las funcionalidades de

producto (Sección 4) que le sean relevantes. Igualmente se puede hacer
mención de cuales usuarios uHlizan una mayor parte del sistema y con más
frecuencia, para disHnguirlos de usuarios ocasionales o que acceden a pocas
funcionalidades.
Entorno operativo
En esta sección se describe el entorno operativo
en el que se desenvolverá el sistema, software,
módulo o grupo de funcionalidades,
mencionando aspectos como la plataforma de
hardware, versiones de sistema operativo y
otros sistemas o componentes con los que debe
coexistir.
•
 Requerimientos funcionales
Los requerimientos funcionales de un sistema, son aquellos
que describen cualquier acHvidad que este deba realizar, en
otras palabras, el comportamiento o función parHcular de un
sistema o soFware cuando se cumplen ciertas condiciones.

En esta sección de la planHlla, ilustramos como organizar los

requerimientos funcionales de soFware por funcionalidad de
producto o sistema. Aquí se listan las funcionalidades y para
cada una a su vez se listan los requerimientos funcionales.

Los requerimientos funcionales también se pueden

documentar en una matriz de trazabilidad de requerimientos.
Sigue el siguiente enlace y te mostramos una planHlla
Matriz de trazabilidad
 Funcionalidad
En el Rtulo de la funcionalidad, se recomienda uHlizar nombres lo más
descripHvo posible para cada funcionalidad. No limitarse a nombrarlas
“Funcionalidad 1”. Un buen ejemplo podría ser “Autorización de
pedido de compra”.

Descripción: Descripción corta de la funcionalidad.

Prioridad: Nivel bajo, medio o alto de prioridad. Esta debe ser

establecida por el área funcional.

Acciones iniciadoras y comportamiento esperado: Secuencia de

acciones de usuario y respuestas esperadas del sistema para esta
funcionalidad.
 Requerimientos funcionales:
Lista detallada de los requerimientos funcionales
asociados a esta funcionalidad.

Para cada requerimiento funcional se establece

como debe mostrarse el soFware y cuales
comportamientos debe desempeñar para que el
usuario pueda realizar la función que necesita.

Es recomendable incluir como el soFware debe

responder a condiciones de error y entradas de
datos inválidas.
 Requerimientos- paso 1
• El analista debe idenHficar y listar los requerimientos clave del sistema a ser
construido. Durante este Paso, el analista no debería empezar detallando los
requerimientos idenHficados. La meta principal es ganar una visión integral de los
requerimientos del sistema.
• Si los requerimientos no funcionales no han sido definidos, se recomienda
capturarlos uHlizando la técnica de escenarios. Esto ayudará a capturarlos con toda
la información requerida para su priorización futura. Si se uHliza la técnica de
escenarios, asegurarse de tener la siguiente información:
• Lista de atributos de calidad involucrados en el requerimiento.
• Lista de componentes de negocio o metas involucradas en este escenario.
• Describir el esRmulo que inicia el escenario.
• Describir la fuente del esRmulo en el escenario.
• Describir el ambiente donde se lleva a cabo el escenario.
• Describir la respuesta recibida en el escenario.
• Describir cómo medir la respuesta.
•
 Requerimientos paso 2 priorizar
• Usando los requerimientos idenHficados en el Paso
anterior, el analista Hene que organizar y estructurar los
requerimientos idenHficados como corresponda (por
ejemplo, procesos de negocio o funciones de sistema).
• Una prioridad debe ser idenHficada por el cliente para las
funcionalidades clave del sistema. Prioridades pueden ser
definidas como:
• ‘Alta’ – una funcionalidad que %ene que ser implementada
• ‘Media’ - una funcionalidad que debería ser implementada
• ‘Baja’ - una funcionalidad que podría ser implementada
• El resultado de este Paso es una lista de requerimientos
organizados
 Ejemplos de requerimientos
• El sistema enviará un correo electrónico cuando se registre alguna de las
siguientes transacciones: pedido de venta de cliente, despacho de mercancía al
cliente, emisión de factura a cliente y registro de pago de cliente.
• Se permiHrá el registro de pedidos de compra con datos obligatorios incompletos,
los cuales podrán completarse posteriormente modificando el pedido. Antes de
poder aprobarse los datos del pedido deben estar completos.
• Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo
(workflow) de aprobación configurado en el sistema.
• El sistema permiHrá a los usuarios autorizados el ingresar planes y cronogramas
de proyecto.
• El sistema permiHrá aprobar, cambiar o actualizar planes y cronogramas
de proyecto.
• El sistema permiHrá el envío automaHzado de cartas de entrega de órdenes
directamente al almacén.
• A cada orden se le asignará un idenHficador único, que será uHlizado para
idenHficarla en todos los procesos subsecuentes que se realicen sobre esta.
•
 Exposición martes 20
• Introducción
• Definición – concepto
• Metodologías de esta clasificación
• Cuadro comparaHvo
• Roles que intervienen
• Conclusiones
• Incluyan diagramas, cuadros sipnóHcos.