2. ir fase de requisitos analisis y diseño oo
DESCRIPTION
Analisis y Diseño Orientado a ObjetosTRANSCRIPT
-
1Ingeniera de Requisitos:Desarrollo de Requisitos
wFactura
Febrero 2010
Objetivos Conocer las distintas fuentes de requisitos.
Explicar algunas tcnicas de recoleccin de requisitos.
Entender como se pueden aplicar estas tcnicas para la obtencinde requisitos tanto de alto nivel (requisitos de negocio, features) como de bajo nivel (requisitos de usuario, requisitos funcionales, etc).
Entender los casos de uso como tcnica para recolectar requisitosde usuario.
Conocer la importancia de priorizar los requisitos antes de desarrollarlos.
Aplicar tcnicas de Aseguramiento de la Calidad en los requisitos de software.
-
2Contenido
Introduccin
Fuentes de requisitos de software.
Planeacin y recomendaciones para la recoleccin de requisitos.
Tcnicas de recoleccin de requisitos.
Anlisis de Requisitos
Especificacin de Requisitos
Validacin y/o Verificacin de Requisitos
Fase de Requisitosen Moprosoft
-
3Ingeniera de Requisitos: Fundamentos
Introduccin a la Ingeniera de Requisitos
Definicin de Requisito de SW (1)
Una condicin que debe ser cumplida para que el cliente
encuentre ACEPTABLE el producto o servicio proporcionado.
Una condicin o capacidad necesitada por un usuario para
solucionar un problema o lograr un objetivo.
IEEE Standard Glossary of Software Engineering Terminology (1990)
Constituyen la definicin del sistema que se va a construir o mejorar
-
4Definicin de Requisito de SW (2)
La siguiente definicin reconoce la diversidad de tipos de
requisitos.
Los requisitos son una especificacin de lo que debe estar
implementado. Son descripciones de cmo el sistema debe
comportarse, o una propiedad o atributo del sistema. Puede ser una
restriccin en el proceso de desarrollo del sistema.
Karl Wiegers piensa que:
Un requisito es una propiedad que un producto debe tener para
proveer valor a un stakeholder.
Lo que los Requisitos NO SON! (1)
Las especificaciones de Requisitos no incluyen: Detalles de diseo o implementacin
Informacin de planeacin de proyecto, o informacin de pruebas.
Una solicitud informal de alguien en una reunin, un pasillo o un elevador o una llamada telefnica
Solicitudes de clientes por medio de encuestas, correos electrnicos o buzones de sugerencias
Observaciones o comentarios durante reuniones de ventas o de publicidad
-
5Lo que los Requisitos NO SON! (2)
Para que sea un requisito: Debe ser solicitado formalmente
Debe ser documentado
Debe ser analizado formalmente para verificar el impacto en el proyecto
Debe ser aprobado
Problemas de Requisitos(1)
La mayor consecuencia de los problemas de requisitos es el RETRABAJO rehacer algo que se pensaba que estaba listo.
El retrabajo puede consumir de 30 a 50% del costo de desarrollo total.
Boehm, B. and Papaccio, P. Understanding and Controlling
Software Costs, IEEE Transactions on Software
Engineering, 1998, vol. 14 no. 10, pp. 1462-1476.
Todo proyecto tiene requisitos !
-
6Problemas de Requisitos(2)
Algunos de los riesgos de requisitos ms comunes:
Participacin insuficiente del usuario
Requisitos que crecen sutlmente
Requisitos ambiguos
Requisitos Gold plating
Especificacin mnima
Pasar por alto clases de usuarios
Planeacin incorrecta
Beneficios de un procesode IR de buena calidad
Las organizaciones que implementan un buen proceso de IR pueden cosechar mltiples beneficios.
Los posibles beneficios que se podran disfrutar en cuanto ahorro de tiempo y dinero: Menos defectos en los requisitos Reducir el retrabajo Disminucin de propiedades innecesarias Rpido desarrollo Disminucin de la falta de comunicacin Menos caos Estimaciones ms aproximadas Satisfaccin del cliente y del equipo
-
7Caractersticas deexcelentes requisitos
La mejor manera de checar si la sentencia de unrequisito tiene estas caractersticas es poner a variosstakeholders a revisar cuidadosamente el SRS(documento de especificacin de requisitos). Completo Correcto Factible Necesario Priorizado No ambiguo Verificable Rastreable
Niveles de Requisitos
Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.9
-
8Proceso de Desarrollo de Requerimientos de SW
Ingeniera de Requisitos
Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos
Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos
Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos
ElicitacinElicitacinElicitacinElicitacin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
-
9Proceso de Desarrollo de Requisitos
ElicitacinElicitacinElicitacinElicitacin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacin
Deberas utilizar un desarrollo iterativo para los proyectos que
quieres que salgan bien.Martin Fowler
Desarrollo de Requisitos
Descubrimiento y Recoleccin
-
10
Ingeniera de Requisitos
Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos
Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos
Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos
RecoleccinRecoleccinRecoleccinRecoleccin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
Fuentes de Requisitos Entrevistas y discusiones con usuarios potenciales
Documentos que describen los productos actuales
SRSs
Reportes de problemas y solicitudes de mejoras para un sistema actual (mesa de servicio)
Encuestas de mercado y cuestionarios de usuarios
Anlisis de escenarios de tareas de usuarios
Modelo de negocio
-
11
Stakeholders
Los stakeholders son los individuos, grupos, uorganizaciones quines estn activamenteinvolucrados en un proyecto, son afectados por suresultado, o son capaces de influenciar en l.
Por qu son importanteslos requisitos?
Un proceso efectivo de IR se enfoca en la interseccin deintereses de todos los stakeholders.
Analistas
Testers
Legal Staff
Clientes $$Usuarios
DesarrolladoresProject Managers
-
12
Stakeholders (clases de usuarios) De los stakeholders hay un subconjunto que representa a
los usuarios finales del sistema. Es importante identificar todas las clases distintas de
usuarios. Pues esta es una fuente vital de requisitos, puescada clase tiene necesidades distintas para usarlo. Porejemplo: La frecuencia con la que ellos usan el producto Su experiencia en el dominio de la aplicacin y su expertise en sistemas
de cmputo Las caractersticas que utilizan Las tareas que ejecutan para soportar sus procesos de negocio Sus privilegios de acceso o niveles de seguridad
Clases de usuarios
Una jerarqua de clientes y usuarios(stakeholders)
WiegersWiegers, Karl E., , Karl E., Software RequirementsSoftware Requirements, 2nd edition, Microsoft Press, 2003, 2nd edition, Microsoft Press, 2003
-
13
Buscando a los usuariosrepresentativos
Todo tipo de proyecto necesita usuarios representativos apropiadospara proveer la voz del cliente.
Cada clase de usuario necesita ser representado.
Un Product Champion es un miembro clave de la comunidad deusuarios a la cual sirve como la interfase principal entre miembros deuna clase de usuarios y el analista de requerimientos del proyecto.
El enfoque de Product Champion provee una forma efectiva deestructurar la relacin cliente-desarrollador.
Ejemplo
Listar al menos cinco clases distintas de stakeholders para el sistema de ATM.
Nombre Representa Rol Champion
Director General Ejecutivo de la compaa Sponsor del proyecto Juan Prez
Equipo de Desarrollo Personas del rea de Sistemas
Sern quienes desarrollarn el software de ATM
Luis Garca
Gerente de Sucursal Persona a cargo de una sucursal del banco
Facilitador para la instalacin del ATM en su sucursal
Pedro Torres
Administrador del ATM Empleado de sucursal delrea de soporte tcnico
Dar mantenimiento al ATM
Hugo Ruiz
Cliente del Banco Persona que tiene una cuenta en el banco
Usuario del ATM. Podr realizar operaciones bancarias con l.
-
14
Ejercicio
Listar al menos cinco clases distintas de stakeholders para uno de los sistemas que estn desarrollando. Al menos uno debe ser un usuario final (deseable poner dos).
Nombre Representa Rol Champion
Diagrama de Contexto
La descripcin del alcance establece el lmite y conexin entre el sistema que se est desarrollando y todo lo dems en el universo.
Identifica los terminadores fuera del sistema que interfacean con l de alguna manera, tambin como datos, flujos de control entre los terminadores y el sistema.
-
15
Ejemplo de Diagrama de Contexto (1)
UsuariosUsuarios
SistemasSistemasLegadosLegados
Otras AplicacionesOtras Aplicaciones
El Nuevo SistemaEl Nuevo Sistema
ComunicacionesComunicacionesSoporteSoporte
ReportesReportes
Definicin de Elicitation(Del Merrian Webster On Line Dictionary)
1 : Sacar a relucir (algo latente o potencial)
2 : Provocar o prolongar (como informacin o una respuesta)
-
16
Recoleccin
El corazn de la ingeniera de requisitos es la recoleccin, el proceso de identificar las necesidades y restricciones de los distintos stakeholders para un sistema de software.
La recoleccin se enfoca en descubrir los requisitos de usuario.
Recomendaciones en la Recoleccin
Usar el vocabulario del dominio de la aplicacin en vezde usar la jerga computacional.
Los clientes deberan entender que una discusin acercade cierta posible funcionalidad no es un compromisopara incluirla en el producto.
Plantear y clarificar cualquier suposicin que el clientepueda tener.
Registar sabiamente toda la informacin obtenida.
-
17
Escoger entre muchastcnicas de recoleccin
Entrevistas
Cuestionarios
Talleres de Recoleccin de Requisitos
Lluvia de Ideas
Observar como trabajan los usuarios
Prototipos
Casos de uso (Escenarios)
Entrevistas - Preguntas libres
Son preguntas alto nivel, abstractas que pueden preguntarse al inicio de un proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales
Preguntas libres:
Son siempre apropiadas
Ayudan a entender la perspectiva de los afectados
No estn influenciadas por el conocimiento de la solucin
-
18
Tipos de preguntas libresUsuario
Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes? Cules son sus backgrounds,
capacidades, ambientes? Cul es su funcin? Qu necesita para realizar sus
actividades?
ProductoProductoProductoProducto Qu problemas del negocio podra
resolver o crear este producto? En qu ambiente se usar el
producto? Cules son sus expectativas para el
fcil uso, lo confiable, y el rendimiento del mismo?
ProcesoProcesoProcesoProceso Cul es la razn por la que se
quiere resolver este problema? Cul es el valor de una solucin
exitosa? Cmo usted resuelve el
problema ahora? Cmo piensa que debera ser?
MetaMetaMetaMeta----PreguntasPreguntasPreguntasPreguntas Estoy preguntando demasiado? Son mis preguntas relevantes? Es usted la persona correcta para
resolver estas preguntas? Son sus respuestas requerimientos
(necesidades)? Puedo hacerle ms preguntas
despus? Hay algo ms que yo debera
preguntarle?
Tipos de preguntas comodn Es importante que el analista ponga atencin a lo que un usuario responde en una
entrevista y para ahondar en las respuestas puede apoyarse de preguntas tales como:
Quin?
Cundo?
Dnde?
Por qu?
Cmo? (sta es vital)
La manera en que lo hace es la mejor manera?
Ejemplo: Si el usuario comenta yo ejecut la nmina, se podra indagar mucho ms que slo eso con las preguntas:
Quin ms lo hace?
Cundo o con qu frecuencia lo hace?
Dnde lo hace?
Por qu lo hace?
Cmo lo hace?
Se podra mejorar?
-
19
Lluvia de Ideas
Reglas para la Lluvia de IdeasReglas para la Lluvia de IdeasReglas para la Lluvia de IdeasReglas para la Lluvia de Ideas Prepare el ambiente de trabajo Diga el objetivo claramente Genere tantas ideas como sea
posible Deje volar la imaginacin No critique ni discuta Mezcle y combine ideas
Ejercicio
Features Versin 1 Versin 2
Realizar una lluvia de ideas (brainstorming) para recolectar lasnecesidades para el sistema elegido que estn desarrollandoactualmente.
-
20
Workshops de Recoleccin Workshops de grupos colaborativos son una tcnica
altamente efectiva para reunir a usuarios y desarrolladores
Tips de recomendaciones para conducir sesiones de recoleccin efectivas son: Establecer reglas base (iniciar y terminar a tiempo, una
conversacin a la vez, enfocarse en issues no en personas)
No salirse del alcance (usar documento de visin y alcance)
Apuntar ideas o elementos para una consideracin posterior (llevar una lista de issues que son importantes y se pueden discutir despus)
Discusin Timebox (poner lmite de tiempo a cada punto)
Mantener un equipo pequeo e incluir a los participantes correctos
Mantener involucrados a todos (fomentar la participacin de todos los integrantes)
Reduccin de riesgos a travs de prototipos
IKIWISI Ill Know It When I See It
Propsitos:
Clarificar y completar los requerimientos
Explorar alternativas de diseo
Prototipo Horizontal
Forma Final, funciones y tecnologa
Bote lo menos que pueda
Prototipo Vertical (pruebas de concepto)
Validan la factibilidad tecnolgica; exponen los riesgos potenciales
Desechables
Eliminan riesgos de requisitos mal entendidos
Bote todo exceptuando el conocimiento ganado
Evolutivo
Este prototipo se llega a convertir en el producto final
-
21
Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber que han completado la construccin bajo el que han completado la construccin bajo el que han completado la construccin bajo el que han completado la construccin bajo el presupuesto y antes de tiempopresupuesto y antes de tiempopresupuesto y antes de tiempopresupuesto y antes de tiempo
Los prototipos son excelentes pero
Puntos a considerar de los prototipos
No incluir validaciones de entrada de datos exhaustivas, manejo de errores, o documentacin de cdigo en prototipos desechables.
No hacer prototipos para requerimientos que ya estn entendidos, a menos que se quieran para explorar alternativas de diseo.
Es riesgoso usar datos dummy en los prototipos pues los usuarios pueden distraerse al ver datos no reales dentro de los mismos.
Nunca esperar que un prototipo reemplace completamente a un SRS !!!
-
22
Aplicacin de tcnicas de recoleccin
EXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOR
EXPE
RIENC
IA DE
LEX
PERIE
NCIA
DEL
EXPE
RIENC
IA DE
LEX
PERIE
NCIA
DEL
CLIEN
TE/ U
SUAR
IOCL
IENTE
/ USU
ARIO
CLIEN
TE/ U
SUAR
IOCL
IENTE
/ USU
ARIO
BAJOBAJOBAJOBAJO ALTOALTOALTOALTOBAJOBAJOBAJOBAJO
ALTOALTOALTOALTO
ProblemaProblemaProblemaProblema EnredadoEnredadoEnredadoEnredadoLluviaLluviaLluviaLluvia de Ideasde Ideasde Ideasde Ideas
ActuacinActuacinActuacinActuacin de Rolesde Rolesde Rolesde RolesBosquejosBosquejosBosquejosBosquejos
EntrevistasEntrevistasEntrevistasEntrevistasTalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos
AlcanzarlosAlcanzarlosAlcanzarlosAlcanzarlosEntrevistasEntrevistasEntrevistasEntrevistas
InvestigacinInvestigacinInvestigacinInvestigacinBosquejosBosquejosBosquejosBosquejos
TalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos
MadurosMadurosMadurosMadurosAnlisisAnlisisAnlisisAnlisis OrientadoOrientadoOrientadoOrientado a a a a ObjetosObjetosObjetosObjetos
EspecificacinEspecificacinEspecificacinEspecificacin de de de de RequerimientosRequerimientosRequerimientosRequerimientosPrototiposPrototiposPrototiposPrototipos HorizontalesHorizontalesHorizontalesHorizontales
CasosCasosCasosCasos de de de de usousousousoReingenieraReingenieraReingenieraReingeniera de de de de ProcesosProcesosProcesosProcesos del del del del NegocioNegocioNegocioNegocio
TalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientosVendiendoVendiendoVendiendoVendiendo////EnseandoEnseandoEnseandoEnseando
PrototipoPrototipoPrototipoPrototipo EvolutivoEvolutivoEvolutivoEvolutivoEspecificacinEspecificacinEspecificacinEspecificacin de de de de RequerimientosRequerimientosRequerimientosRequerimientos
BosquejosBosquejosBosquejosBosquejosCasosCasosCasosCasos de de de de usousousouso
ReingenieraReingenieraReingenieraReingeniera de de de de ProcesosProcesosProcesosProcesos del del del del NegocioNegocioNegocioNegocioTalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos
Algunas precaucionesacerca de la recoleccin
Usar Product Champions para validar la entrada de varios usuarios.
El documento de Visin y Alcance puede cambiar despus del proceso de recoleccin.
No incluir informacin acerca de la solucin dentro de los requisitos (no especificar nada que tenga que ver con el diseo ni construccin de la solucin).
-
23
Dudas o comentarios ?
Entendiendo los requisitos
del Usuario:
Casos de Uso
-
24
Casos de Uso
Por qu usar un Modelo de Casos de Uso para entender las necesidades de los afectados? Para llegar a un acuerdo con el usuario de lo que el sistema debe hacer
Para identificar quien interactuar con el sistema
Para identificar las interfases que el sistema debe tener
Para ayudar a verificar que no faltan requerimientos
Para verificar que los desarrolladores entienden los requerimientos
Actores y Casos de UsoDefinen los Lmites y las Funciones
Receptor de lallamada
Persona queLlama
AdministradorDe Facturacin
Llamada Internacional
Facturar al cliente
Llamada Local
Cliente
Un sistema telefnico simpleUn sistema telefnico simpleUn sistema telefnico simpleUn sistema telefnico simple
Un modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo hace
-
25
Como Encontrar Actores
Pregntese lo siguiente: Qu grupos de usuarios ayudan al sistema a realizar sus
tareas?
Qu grupos de usuarios se necesitan para ejecutar lasopciones mas obvias del sistema?
Qu grupos de usuarios se requieren para desarrollarlas funciones secundarias tales como mantenimiento yadministracin?
Interactuar el sistema con otro sistema o hardwareexterno?
Como encontrar casos de uso
Para cada actor pregntese lo siguiente: Cules son las tareas primarias que el actor quiere que el
sistema desarrolle? Crear, almacenar, cambiar, remover o leer datos en
el sistema? Tendr el actor que informar al sistema de cambios
sbitos externos? Tendr el actor que estar informado de ciertas
ocurrencias en el sistema? Tendr el actor que desarrollar la inicializacin o
terminacin del sistema? Ponga un nombre a los casos de uso que ha encontrado
-
26
Modelo del Diagrama de Casos de UsoUna solucin simple para una Mquina de Reciclaje
Operador
Cliente
Administrador
Imprimir Reporte Diario
Cambiar Valores de Fondos
Reciclar Objetos
Mquina de Reciclaje
Agregar Nuevo Tipo de Objeto
Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer (casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)
Ejercicio Identifique Actores para el ATM
-
27
Ejercicio Identificar Casos de Uso para el ATM
Desarrollo de Requisitos
Anlisis
-
28
Ingeniera de Requisitos
Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos
Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos
Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos
RecoleccinRecoleccinRecoleccinRecoleccin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
Anlisis de Requisitos
Esta etapa dentro del proceso de Desarrollo de Requisitos se enfoca principalmente a analizarlos para: Detectar y resolver conflictos entre requisitos
Clasificar los requisitos de acuerdo al nivel
Separar los requisitos de manera modular (que llegarn a formar parte de componentes de software)
Priorizar los requisitos
Crear el modelo conceptual
-
29
Anlisis de Requerimientos
Priorizacin de requisitos basada en Importancia y Urgencia
Importante No Importante
Urgente Prioridad Alta No hacer estos !
No Urgente Prioridad Media Prioridad Baja
Dudas o comentarios ?
-
30
Desarrollo de Requisitos
Especificacin
Ingeniera de Requisitos
Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos
Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos
Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos
RecoleccinRecoleccinRecoleccinRecoleccin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
-
31
Documento de Especificacin de Requisitos de Software (SRS)
Para Moprosoft, este documento debe llevar:1. Introduccin2. Funcionales3. Interfaz con Usuario4. Interfaces con otro Software o Hardware5. Confiabilidad6. Eficiencia7. Mantenimiento8. Portabilidad9. Interoperatividad10. Reusabilidad11. Restricciones de Diseo y Construccin12. Legales y Reglamentarios
Algunas guas para la especificacin de requisitos funcionales
Usar siempre palabras como debe, deber, permitir, podr y NO palabras como podra, debera, tal vez.
Asignar un identificador nico a cada requisito.
Para los Requisitos No Funcionales que son Atributos de Calidad, especificar mtricas de cmo el requisito se debe cumplir y no dejar frases tales como que lo haga rpido, que lo haga bien, entre otras. Mejor cosas como que responda en menos de 30 segundos, que se inserten el 100% de los registros, etc.
JAMS SUPONER O ASUMIR ALGO!!! (Si no se est seguro de algo preguntar al usuario llamndolo por telfono, o preguntndole en persona).
Especificar todo lo ms claro posible pues hay que tomar en cuenta que los que disearn el sistema son otras personas.
Cuidar el no incluir palabras ambiguas, un sntoma sera que dos personas entendieran cosas distintas del requisito.
-
32
Ejercicio
Liste los problemas que encuentre en la especificacin delsiguiente requisito. Proponga una mejor redaccin de serposible (en caso que sea necesario puede descomponerloen varios requisitos).
El clculo de la nmina puede ejecutarse una vez al mes sin que nadie
tenga que activarla. Este proceso se debera ejecutar lo ms rpido posible
para que el da de la ejecucin antes de la hora de la comida todos los
empleados tengan su sueldo depositado. La cantidad a depositar para cada
empleado es simplemente la resta entre su sueldo asignado y las
deducciones. Adems, la informacin de los empleados incluyendo su sueldo,
no debera poder ser vista por el personal encargado de administrar la base
de datos que no tengan que ver con dicha informacin.
Posible Solucin
RF-1. El sistema deber ejecutar de manera automtica el clculo de lanmina el ltimo da de cada mes natural. Es imprescindible que suejecucin quede lista antes de la 1 pm. Ver RN-1 para el clculo del sueldo.
Ver RNF-1 para polticas de seguridad.
RN-1. El sueldo mensual de un empleado se calcula por medio de lasiguiente frmula:
Sueldo Total = Sueldo_Asignado Total_Deducciones
donde Total_Deducciones se obtiene
RNF-1. nicamente el personal de recursos humanos podr ver y/oactualizar la informacin personal de los empleados. Ni siquiera el personalde bases de datos lo debe poder hacer.
-
33
Atributos de Calidad (1) Los atributos de calidad son difciles de definir porque los usuarios se
enfocan ms en proporcionar sus requisitos funcionales (de comportamiento).
Una manera de clasificar a los atributos de calidad es con aquellas caractersticas que son evidentes en tiempo de ejecucin de las que no lo son.
Atributos importantes para los usuarios Atributos importantes para los
desarrolladores
DisponibilidadEficienciaIntegridadConfiabilidadEscalabilidadUsabilidad
Fcil de mantenerFcil de evolucionarPortabilidadReusabilidadFcil de probar
Atributos de Calidad (2)
Un usuario no podr responder a preguntas tales como: Cules son tus requisitos de disponibilidad?
Qu tan confiable debe ser el software?
Buscar otro estilo de preguntas relacionndolas con el dominio del problema. Por ejemplo. Qu tan importante es asegurar que ciertos usuarios no puedan ver
cierta informacin? Podra cualquier persona tener acceso a la informacin de los clientes?
Qu tan grave sera que el sistema no estuviera disponible (se cayera) en horas de trabajo en un da entre semana? y qu tan grave sera que se cayera un fin de semana en la madrugada?
-
34
Especificacin de Atributos de Calidad (Requisitos No Funcionales)
Interfase con el UsuarioIU1. Un usuario entrenado deber ser capaz de registrar una peticin
completa de un producto de un vendedor en un promedio de 4 a 6 minutos.
IU2. Un usuario quien nunca ha utilizado el sistema antes, deber ser capaz de registrar una solicitud de un pedido de manera correcta en un tiempo no mayor a 10 minutos.
Interfases ExternasIE1. El sistema deber ser capaz de comunicarse con el mdulo de RH.
IE2. El sistema interactuar con el sistema de nmina ya existente en la empresa.
Especificacin de Atributos de Calidad (Requisitos No Funcionales)
Confiabilidad Confiabilidad
CC1. No ms de 5 ejecuciones experimentales de 1000 pueden ser perdidas debido a fallas en el software.
Disponibilidad
CD1. El sistema estar disponible el 99.5 % del tiempo en das de trabajo entre las 6 am y las 12 am, y al menos el 99.95 % del tiempo en das de trabajo entre 4 pm y 6 pm.
Robustez
CR1. Si el editor falla antes que el usuario guarde el archivo, el editor deber ser capaz de recuperar todos los cambios hechos en el archivo editado hasta un minuto antes de la falla, en la prxima vez que se inicie el programa.
Integridad
CI1. Slo usuarios con privilegios de acceso de auditor sern capaces de ver histricos de las transacciones de los clientes.
-
35
Especificacin de Atributos de Calidad (Requisitos No Funcionales)
EficienciaE1. Toda pgina web deber ser cargada a lo ms en 15 segundos sobre
una conexin por modem de 50 KBps.
E2. La autorizacin de una peticin de retiro en un ATM no deber tomar ms de 10 segundos.
MantenimientoM1. Un programador deber ser capaz de modificar los reportes existentes
con 20 horas o menos de esfuerzo en desarrollo.
M2. Las llamadas a funciones no debern pasar de 2 niveles de anidamiento.
PortabilidadP1. El mdulo de facturacin deber ser capaz de ejecutarse sobre
cualquier terminal PC con sistema operativo Linux o Windows.
Especificacin de Atributos de Calidad (Requisitos No Funcionales)
Restricciones de Diseo y ConstruccinRDC1. El sistema deber ser desarrollado sobre la plataforma J2EE la cual
es la infraestructura tecnolgica de la empresa.
RDC2. Todo el mdulo de inventarios deber ser construido utilizando las libreras existentes en la empresa.
Legales y ReglamentariosLR1. El sistema deber implementar las regulaciones del gobierno actual.
LR2. El costo unitario del producto ser de $50 en compras de 100 o ms unidades, y en compras de menos unidades el costo unitario ser de $70.
LR3. Por cada tres retardos que un empleado acumule a lo largo del mes actual, se le descontar un da de sueldo.
-
36
Trade-Offs de Atributos de Calidad
Tarea
Hacer un documento de especificacin de requisitos parael Sistema ATM. Este documento deber tener al menosun caso de uso y al menos un requisito no funcional encada punto de la norma.
NOTA: Esto debe ser hecho por la persona o personasque jugarn el rol de Analistas en el proyecto deMoprosoft.
-
37
Desarrollo de Requisitos
Validacin
Ingeniera de Requisitos
Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos
Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos
Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos
RecoleccinRecoleccinRecoleccinRecoleccin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
-
38
Validacin de Requisitos
La fase de validacin es la cuarta y ltima del rea deDesarrollo de Requisitos.
Las actividades de la validacin de requisitosintentan asegurar que: El documento de especificacin de requisitos (SRS) describe las
capacidades y caractersticas del sistema que cumplirn las necesidades de los stakeholders.
Los requisitos estn completos y son de alta calidad.
Todas las representaciones son consistentes con las dems.
Los requisitos proveen una base adecuada para proceder con el diseo y la construccin.
Los requisitos son especificados de acuerdo a los estndares establecidos.
Validaciones y Verificaciones en Moprosoft
Verificacin o
Validacin
Producto Rol Descripcin
Verificacin Especificacin de Requisitos
RE Verificar la claridad de redaccin de la Especificacin de Requisitos y su consistencia con la descripcin del producto y con el estndar de documentacin requerido en el proceso.Adicionalmente revisar que los requisitos sean completos y no ambiguos o contradictorios. Los defectos encontrados se documentan en un Reporte de Verificacin.
Validacin Especificacin de Requisitos
CL,US,RPU
Validar que la especificacin de requisitos cumple con las necesidades y expectativas acordadas. Los defectos encontrados se documentan en un Reporte de Validacin.
Verificacin Plan de Pruebas de Sistema
RE Verificar consistencia del plan de pruebas del sistema con la especificacin de requisitos y con el estndar de documentacin requerido.
Verificacin Manual de Usuario RE Verificar consistencia del manual de usuario con la especificacin de requisitos y con el estndar de documentacin requerido.
-
39
La calidad es gratis: Inspecciones de Software
Las inspecciones de software son la mejor tcnica que existe para remover defectos antes de llegar a la fase de pruebas. (Inventadas por Michael Fagan a mediados de los 70s).
Para maximizar la calidad del producto se deben realizar ms inspecciones.
Las inspecciones son costosas: consumen tiempo y recursos.
Sin embargo Por cada hora invertida en una inspeccin, se ahorra
alrededor de 10 horas de retrabajo en el testing. Por cada dlar invertido en inspecciones, se ahorran de 3 a
10 dlares en la fase de pruebas.
Inspeccin de Software: Roles (1) Autor
Creador del producto a inspeccionar.
Rol pasivo y no puede llevar otro rol de la inspeccin.
Debe dejar su ego afuera de la inspeccin y tambin ver defectos que otros no ven.
Moderador Lder de la inspeccin.
Planea y coordina las actividades de la inspeccin con el autor.
Distribuye el material a ser inspeccionado a los inspectores das antes de la reunin.
Dirige el proceso de inspeccin y mantiene el enfoque en encontrar defectos en vez de resolver problemas.
Se asegura que el autor realice las modificaciones despus de la inspeccin.
-
40
Inspeccin de Software: Roles (2)
Lector Debe parafrasear un requisito del SRS a la vez.
Los otros participantes detectan defectos potenciales.
Debe nombrar con sus propias palabras cada requisito, con esto se pueden detectar ambigedades si los otros participantes lo haban entendido de otra manera.
Escritor (apuntador) Usa formatos para registrar los defectos encontrados durante la
reunin de inspeccin.
Inspeccin de Software: Roles (3)
Inspector Es quien encuentra errores, omisiones e inconsistencias en los
productos inspeccionados.
Los inspectores pueden ser:
Autores de productos de trabajo antecesores del producto inspeccionado: (usuarios, cliente, otros analistas).
Personas que trabajarn en base al producto de trabajo inspeccionado: (diseadores, arquitectos, programadores, testers, etc).
Personas que son responsables por productos de trabajo que interfasean al producto inspeccionado.
Tratar de limitar la inspeccin a 6 o menos inspectores.
-
41
Inspeccin de Software:Criterios de Entrada
El documento cumple el estndar de la plantilla. El documento no tiene faltas de ortografa. El documento ya no tiene errores de formato. Cualquier otro documento referenciado debe estar disponible
para los inspectores. Issues incompletos deben ser marcados como TBD (To Be
Determined). Puntos que no apliquen deben ser explcitamente
mencionados.
Inspeccin de Software:Fases de la Inspeccin (1)
1. Planificacin. Cuando el autor termina su producto de trabajo se forma un grupo de inspeccin y se designa un moderador. ste ltimo asigna roles y planifica los tiempos y recursos necesarios.
2. Overview. Si los inspectores no estn familiarizados se da una vista general del producto a inspeccionar. Es opcional.
3. Preparacin. Los inspectores se preparan individualmente para la evaluacin en la reunin estudiando los productos de trabajo y el material relacionado.
4. Junta de Inspeccin. Los inspectores se renen. El moderador lleva la reunin. Es importante que no dure ms de 2 horas.
5. Retrabajo. El autor corrige todos los defectos encontrados por los inspectores.
6. Seguimiento. El moderador checa las correcciones del autor. Si est satisfecho la inspeccin est completa.
-
42
Inspeccin de Software:Fases de la Inspeccin (2)
Inspeccin de Software:Criterios de Salida
Todos los defectos encontrados han sido removidos.
Cualquier cambio hecho al producto inspeccionado fue realizado correctamente.
El documento inspeccionado ha sido puesto bajo gestin de la configuracin.
El documento ha sido corregido ortogrficamente.
-
43
Ejercicio
Lleva a cabo un proceso de inspeccin con el SRS que les ser proporcionado y cumpliendo los tiempos siguientes: Planificacin (5 minutos)
Overview (5 minutos)
Preparacin Individual (10 minutos)
Reunin de Inspeccin (20 minutos)
Retrabajo (5 minutos)
Seguimiento (10 minutos)
Resumen
Introduccin
Fuentes de requisitos de software.
Planeacin y recomendaciones para la recoleccin de requisitos.
Tcnicas de recoleccin de requisitos.
Anlisis de Requisitos
Especificacin de Requisitos
Inspeccin de software para validacin de requisitos
-
44
Dudas o comentarios ?