M.C. María Guadalupe Monjarás Velasco

� Requerimientos de proceso.

� Requerimientos de los usuarios (actores involucrados).

Temario

involucrados).

� Requerimientos para el análisis y negociación.

� Requerimientos para la gestión.

� De acuerdo al IEEE:

� Una condición o capacidad que un usuario necesitapara resolver un problema o lograr un objetivo

� Propiedades o restricciones determinadas de forma

Qué son los requeriemientos

� Propiedades o restricciones determinadas de formaprecisa que deben satisfacerse.

� Una condición o capacidad que debe tener un sistemao un componente de un sistema para satisfacer uncontrato, una norma, una especificación u otrodocumento formal.

Los requerimientos/requisitos de un sistema describen los servicios que ha deofrecer el sistema y las restricciones asociadas a su funcionamiento.

Requerimientos funcionales

Expresan la naturaleza del funcionamiento del sistema (cómo interacciona elsistema con su entorno y cuáles van a ser su estado y funcionamiento).

NOTA: A veces, también es conveniente indicar lo que no hará el sistema.

Requerimientos funcionales y no funcionales

Requerimientos no funcionales

Restricciones en el espacio de posibles soluciones:· Rendimiento del sistema: fiabilidad, tiempo de respuesta, disponibilidad…· Interfaces: dispositivos de E/S, usabilidad, interoperabilidad…· Proceso de desarrollo: estándares, herramientas, plazo de entrega…

NOTA: La distinción entre requerimientos funcionales y no funcionales no siempre resulta evidente (p.ej. la seguridad puedeinterpretarse inicialmente como un requerimiento no funcional al principio pero, tras elaborarlo, conduce a la aparición derequerimientos funcionales como la necesidad de autentificar a los usuarios del sistema).

� La Ingeniería de Requerimientos es unconjunto de actividades en las cuáles,utilizando técnicas y herramientas, se analizaun problema y se concluye con laun problema y se concluye con laespecificación de una solución (Ortas 1997).

� La IR es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto (IBM Rational).

Ingeniería de Requerimientos

proyecto (IBM Rational).� Es un proceso de descubrimiento y

comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas necesidades (Duran 2000).

Visión del proyecto

� SRS: Software Requirement Specification

� Una especificación de Requerimientos de Software (ERS) es un documento que contiene Software (ERS) es un documento que contiene una descripción completa de qué hará el software sin describir cómo lo hará.

� De los requerimientos dependen todas las demás actividades del proceso de desarrollo de software

¿Por qué son importantes?

� Lo que se pretende con una buena Ingeniería de Requerimientos es reducir costos y retrasos del proyecto, mejorar la calidad del software, evitar el rechazo de los usuarios finales entre otras cuestiones.

� Entre más tarde detecte un error en el ciclo de vida del desarrollo de software, más caro costará repararlo.

� Proceso de Ingeniería de RequerimientosParticipación

del usuario

Estudio de

Requerimientosdel usuario

Retroalimentacióndel usuario

Especificaciónde requerimientos

Modelos a validarpor el usuarioEstudio de

factibilidad

Obtención y

análisisEspecificación Validación

Modelo derequerimientosConocimiento

Necesidad de másconocimiento

Resultado devalidación

� Para todos los sistemas nuevos, el proceso de la Ingeniería de Requerimientos empieza con el estudio de Factibilidad.

� La entrada de este es una descripción resumida � La entrada de este es una descripción resumida del sistema y de cómo se utilizará dentro de la organización. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la Ingeniería de Requerimientos y el proceso del desarrollo del sistema.

� Algunos autores manejan los conceptos de viabilidad y factibilidad. Cuando se habla de factibilidad se habla de que se puede hacer y cuando es viabilidad de que se puede llevar cuando es viabilidad de que se puede llevar acabo (sostener/mantener)

ORGANIZACIÓN¿SIRVE?

SISISISISISISISIINGENIERIA

DEREQUERIMIENTOS

� Es el proceso que sirve para determinar el dominio de la aplicación, cuales servicios debe proporcionar el sistema, así como su desempeño requerido, las restricciones de desempeño requerido, las restricciones de hardware, etc. Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle.

� Las actividades que cubre son:

� Comprensión del dominio

� Recolección de requerimientos� Clasificación de requerimientos� Clasificación de requerimientos

� Resolución de conflictos� Priorización� Verificación de requerimientos

Verificación de

Requerimientos

Comprensión

del dominioPriorización

Especificación de

Requerimientos

DOCUMENTO DEREQUERIMIENTOS

Recolección de

Requerimientos

Resolución de

conflictos

Clasificación

PROCESO DE OBTENCIONY ANÁLISIS DE

REQUERIMIENTOS

� Los requerimientos pueden ser funcionales(explícitos) o no funcionales (implícitos).

� Las características que deben perseguir los � Las características que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable.

� Los problemas que presenta la Ingeniería de Requerimientos son tress:

1. Los requerimientos no son obvios y provienen de muchas fuentes.

2. Son difíciles de expresar en palabras.

3. Un requerimiento puede cambiar en el 3. Un requerimiento puede cambiar en el transcurso del proyecto.

� El éxito de la obtención de requerimientos consiste en ponernos en los zapatos de nuestros clientes y no desarrollando a nuestros gustos.

� Para obtener requerimientos se siguen muchas técnicas. Las más populares son las entrevistas y cuestionarios.

� Tips para Diseñar Cuestionarios:

� Es necesario realizar un muestreo de los datos para encontrar necesidades.

� Las preguntas deben ser realmente significativas, sino no sirven.

� Se deberán poner escalas (preguntas cerradas) para cuantificar lo que se pretende.

� Con los resultados obtenidos se debe de � Con los resultados obtenidos se debe de realizar un análisis estadístico para poder sacar conclusiones. Por lo tanto, las preguntas de un cuestionario deben de estar orientadas hacia solucionar dichas dudas.

� Tips para realizar entrevistas:

� Utilizar una técnica de rombo de preguntas cerradas, abiertas y cerradas.

Observación del mundo.� Observación del mundo.� Tener un guión flexible (improvisación).

� Se debe tener facilidad de palabra y nunca perder el objetivo de la entrevista.

� Los Sistemas Existentes son otra buena forma de hacer extracción de requerimientos basándose en software ya existente dándole oportunidad a los clientes de observar oportunidad a los clientes de observar interfaces, funcionalidades para sus proyectos.

� Grabaciones de Audio y Video: Se pueden utilizar como registro histórico o para analizar con mayor detenimiento una entrevista.

� Permiten centralizarse en la entrevista más que en el registro.

� La Arqueología de Documentos ayuda a determinar posibles requerimientos sobre la base de inspeccionar la documentación utilizada por la empresa; por ejemplo, boletas, facturas, remisiones, etc.empresa; por ejemplo, boletas, facturas, remisiones, etc.

� Responde a preguntas como:� ¿Cuál es el propósito de este documento?

� ¿Quién lo usa? ¿Por qué? ¿Para qué?� ¿Cuáles son las tareas que realizan con este

documento?

� La técnica del aprendiz es otra buena técnica de Ing. De Requerimientos. El aprendiz es el analista Ing. De Requerimientos. El aprendiz es el analista mientras que el maestro es el cliente/usuario. El aprendiz se sienta con el maestro con el objetivo de aprender a través de la observación y de la realización de preguntas.

� El aprendiz se sienta con el maestro con el objetivo de aprender a través de la observación y de la realización de preguntas.

� Estas técnicas aunque muy básicos son parte fundamental de la elicitación de requerimientos. Se siguen utilizando ampliamente.

� Las Tecnologías de Información y Comunicaciones se pueden aplicar de forma fácil y sencilla a las herramientas de Ingeniería de Requerimientos.

� Entre estas nuevas tecnologías se encuentran los

blogs, wikis, redes sociales, podcasting, etc.

� Estas tecnologías serán utilizadas en el proyecto.

� En el proyecto en su primera entrega (SRS).

� Se tendrán que aplicar forzosamente las técnicas de entrevista (podcasting), técnicas de entrevista (podcasting), cuestionario (blog, foro de discusión, red social) y llevar un control de cambios con un Wiki.

� ¿Cómo implementarlo?

� La entrevista se graba el audio en MP3 y se sindicaliza con RSS (podcasting) si es video se hace algo similar subiéndolo a un sitio de videos, podcasting.

*Si se van a manejar diagramas se recomienda � *Si se van a manejar diagramas se recomienda subirlo a un albúm de fotos como flickr. Si se ocupa anexar documentos pueden subirse a portales de documentos como slideshare, scribd.

� Para el cuestionario en cualquier blog como blogspot, twitter; foro de discusión o grupo de red social. Deberá ser evidente que tanto el aplicador de la encuesta (ustedes) como el que la aplicador de la encuesta (ustedes) como el que la contesta (cliente/usuario final) son diferentes.

� En el Wiki se irá depurando el documento final de SRS. Todos deberán realizar observaciones.

� Cada parte vale 5% (para un total de 15%) de los 25 puntos.

� Recordar que para todos los trabajos en � Recordar que para todos los trabajos en equipo se deberá dejar bien claro cuales fueron las responsabilidades de cada quien dado que la calificación se manejará 70 rendimiento individual y 30% grupal.

� RFP (Request for Proposal) es un documento en donde se específica el desarrollo de un sistema o el uso de un bien o servicio.

� Las solicitudes de propuestas deben formularse en lenguaje claro, terminología integral y

RFP/ Solicitud de Propuesta

en lenguaje claro, terminología integral y formato estandarizado para facilitar la comprensión de los objetivos de los sistemas de la organización, por parte de los proveedores.

� ¿Quiénes participan durante el proceso de Ingeniería de Requerimientos?

� Los supervisores del contrato� Los clientes y los usuarios� Los gerentes del negocio� Los diseñadores

Stakeholders en Ing. Req.

� Los diseñadores� Los verificadores

� En metodologías a´giles como Scrum se llaman Product Owners.

Factores de Calidad de McCall

Estándar ISO 9126

� La especificación de requerimientos es un acuerdo aprobado entre usuarios y desarrolladores del software y debe tener al menos las siguientes características:

Documentación de Req.

menos las siguientes características:

� Contener todos los requerimientos deseados

� Cada requerimiento solo tiene una interpretación posible.

� El cumplimiento de cualquier requerimiento no debe provocar conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente.

� Prioridades definidas� Especificados por escrito

Documentación de Req.

� Especificados por escrito� Posibles de probar o verificar� Descritos como una característica del sistema a

entregar.� Lo más abstracto y conciso posible

� Descritos como una característica del sistema a entregar.

� Lo más abstracto y conciso posible

Documentación de Req.

EntendimientoEntendimientoEntendimientoEntendimiento

PrecisiónPrecisiónPrecisiónPrecisión

Lenguaje

naturalLenguaje

estructurado

Metodologías

(CASE,etc.) Especificaciones

Formales

� Los requerimientos deben escribirse de modo que sean significativos no sólo para los clientes, sino también para los diseñadores que integran el equipo de desarrollo.

Documentación de Req.

que integran el equipo de desarrollo.Definición de Requerimientos

Especificación de Requerimientos

Clases de documentos

de Requerimientos

� Está escrita en términos que el cliente puede entender. Es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Es escrito en forma conjunta por el cliente y el desarrollador.

Definición de Requerimientos

propuesto. Es escrito en forma conjunta por el cliente y el desarrollador.

� Primero se perfila el propósito general del sistema.

� Se describen los antecedentes y los objetivos del desarrollo del sistema.

� Si el cliente tiene un nuevo enfoque propuesto para resolver el problema, se perfila una descripción del enfoque.

Definición de Requerimientos

� Una vez registrada esta vista global del problema, se describen en detalle las características del sistema propuesto. Se definen el límite del sistema y las interfaces que lo vinculan con el entorno.

� Por último, se discute el ambiente en el cuál operará el sistema. Se incluyen requerimientos para el soporte, la seguridad y la privacidad.

Definición de Requerimientos

la privacidad.

� Se escribe desde la perspectiva del desarrollador. Es la contrapartida técnica al documento de definición de requerimientos, y es escrito por analistas de requerimientos.

Especificación Requerimientos

y es escrito por analistas de requerimientos.

� Por ejemplo, el cliente no puede comprender la definición de un requerimiento en términos de una relación matemática compleja definida con una serie de ecuaciones.

� Es una técnica de Ingeniería de requerimientos que consiste en describir de manera amplia y detallada cada forma de operación del sistema.

� Se pueden utilizar de todo tipo de organizadores gráficos, van más enfocadas al análisis y gráficos, van más enfocadas al análisis y especificación de requerimientos.

� Las técnicas mas utilizadas de este tipo son las historias de usuario y los casos de uso.

� Son realizadas por los usuarios en forma de descripción textual.

� Cuando se utiliza en forma gráfica enfocadas a interfaces se denominan spikes.Cuando se utiliza en forma gráfica enfocadas a interfaces se denominan spikes.

� Se derivan de técnicas como los sketches (borradores de la interfaz realizadas por los modeladores) y los storyboard (muestra de secuencia de navegación)

Historia de Usuario

Número: 1 Nombre: Enviar artículo

Usuario: Autor

Modificación de Historia Número: Iteración Asignada: 2

Prioridad en Negocio: Alta

(Alta / Media / Baja)Puntos Estimados:

Riesgo en Desarrollo:

(Alto / Medio / Bajo)Puntos Reales:

Descripción:

Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.

Observaciones:

� Los requerimientos del proceso son a nivel organizacional, describen el “cómo”, es decir, describen los procedimientos y políticas que las organizaciones deben seguir así como las las organizaciones deben seguir así como las restricciones que deben obedecer, por ejemplo, estándares usados en los procesos, los requerimientos de implementación, etc.

� Son todas sus necesidades, las cuales se traducen a los requerimientos de lo que esperan que un nuevo sistema realice y de las restricciones que lleva consigo. Un ejemplo de tales necesidades pueden ser las siguientes:

� Obtener soluciones a problemas en su trabajo bajo el sistema actualbajo el sistema actual

� Una interfaz más amigable, rápida de aprender, fácil de usar

� Un tiempo de respuesta más corto, etc.

Requerimientos de usuario Requerimientos del sistema

LENGUAJE COTIDIANO LENGUAJE TÉCNICO

� Cuando se están investigando los requerimientos, el analista se encuentra con el problema de la comunicación con el usuario pues el lenguaje cotidiano de ambos no es igual. Por ejemplo:pues el lenguaje cotidiano de ambos no es igual. Por ejemplo:

� Falta de claridad

� Conocen de manera muy general lo que desean obtener

� No saben expresar o explicar lo que quieren del sistema

� Usan terminologías distintas

Confunde los requerimientos funcionales y los no � Confunde los requerimientos funcionales y los no funcionales

� Confusión de requerimientos, pues expresan de varias formas un mismo requerimiento

� Una vez identificados los requerimientos completos, consistentes y no ambiguos, se procede a clasificarlos.

� El analista debe hacerse la siguiente pregunta con cada uno de los requerimientos: ¿El requerimiento es necesario o representa una característica añadida que puede no ser esencial cuando se haya finalizado el sistema?

� La razón de esta pregunta se debe a que es común en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados, cómo sería el sobrepasar el presupuesto y el tiempo requerido para el desarrollo del sistema.

� La clasificación de estos requerimientos es la siguiente:�requerimientos esenciales, aquellos que deben ser

absolutamente satisfechos.

�requerimientos deseables, que son importantes pero no indispensables.

�requerimientos opcionales, que son posibles pero que podrían eliminarse

� Después de hacerse la clasificación de requerimientos, el analista de sistemas realiza un requerimientos, el analista de sistemas realiza un proceso de negociación con clientes, usuarios y el resto de los involucrados para resolver los conflictos relacionados con ciertos requerimientos según su prioridad.

� Parte de la negociación de los requerimientos incluye identificar y analizar los riegos asociados a cada requerimiento además de efectuar estimaciones de costo, tiempo y efectuar estimaciones de costo, tiempo y esfuerzo. Estas estimaciones ayudarán a una mejor elección de cuáles requerimientos tienen mayor prioridad que otros.

� En esta actividad se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

� Documentar todos los requerimientos a un nivel de detalle apropiado.

� Mostrar todos los requerimientos a los involucrados en el sistema.

� Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.

� Establecer las relaciones entre requerimientos � Establecer las relaciones entre requerimientos que indiquen dependencias.

� Negociar con flexibilidad para que exista un beneficio mutuo.

� Enfocarse en intereses y no en posiciones

� La gestión de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo junto con el proceso de ingeniería de requerimientos.

� La planeación comienza al mismo tiempo que la obtención inicial de requerimientos y la administración activa debe iniciar tan pronto esté lista la primera versión del documento de requerimientos.

� Se pueden utilizar técnicas como la Lluvia de Ideas o análisis FODA, el cual consiste en hacer una relación entre elementos:

� Fortaleza: Factor interno positivo.� Oportunidades: Factor externo positivo.� Debilidades: Factor interno negativo.� Amenazas: Factor externo negativo.

FORTALEZAS

l Uso horario similar

l Afinidad cultural

l Proximidad y fácil traslado

l Menores costos de mano de obra

l Buena infraestructura aunque más costosa

l TLCAN

l Estabilidad política

l Bajo riesgo geopolítico

DEBILIDADES

l Oferta limitada de mano de obra calificada

l Escaso manejo del inglés

l Niveles de certificación de las empresas mexicanas

l Estructura de la industria de TI

l Temas de seguridad y corrupción

l Falta de experiencia de las empresas en proyectos

grandes de México

l Acceso a capital

FODA industria Sw en México

l Bajo riesgo geopolítico l Acceso a capital

l Carga y legislación laboral

OPORTUNIDADES

l Asociación con jugadores globales de desarrollo de

TI canadienses

l Amplio espacio para el apoyo efectivo del gobierno

l Generar una masa crítica de mano de obra calificada

AMENAZAS

l Alta competencia de países emergentes en el

mercado de TI (Brasil, Rusia, China y Filipinas)

l Incrementos en el costo de la mano de obra

l Constante innovación tecnológica

� Una rúbrica es un elemento que nos permite definir en forma tabular los requisitos que debe tener un producto en general y evaluarlos en base a un criterio determinado.base a un criterio determinado.

Rúbrica

Requisito A (100) B (85) C (70) Z (0)

Revisión de Fuentes

Bibliográficas (20%)

Consulta al menos tres

fuentes bibliográficas

formales y las cita

adecuadamente (libros,

revistas, artículos técnicos)

Consultó fuentes pero fueron

menos de tres o no estuvieron

bien citadas

Consulto alguna fuente

bibliográficas que no eran

formal

No citó o consulto fuentes

Presentación del Trabajo

(10%)

El trabajo se entrega con un

portada, índice, introducción,

Faltó una sección o está mal

planteada.

Faltaron dos secciones o están

mal planteadas

Faltaron 3 o más secciones

(10%) portada, índice, introducción,

desarrollo y conclusiones

propias

planteada. mal planteadas

Ejemplificación de las

funciones del SQA (70%)

Se cuentan con al menos tres

descripciones de puestos

ejemplificando con

organizadores gráficos u otro

tipo de evidencia sustancia las

funciones del SQA

Una descripción de puestos

no está ejemplificada

adecuadamente

Dos descripciones de la

funciones del SQA no están

ejemplificadas

adecuadamente

Tres descripciones no están

ejemplificadas

adecuadamente.

� Creado por HP utiliza una matriz de valoración.

� Funcional (Functional): características, capacidades y seguridad.

� Facilidad de Uso (Usability): factores humanos,

FURPS+

� Facilidad de Uso (Usability): factores humanos, ayuda, documentación.

� Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperación.

� Rendimiento (Performance): tiempos de respuesta, productividad, precisión, disponibilidad, uso de los recursos

FURPS+

� Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad.

� +:� Implementación: limitación de recursos,

lenguajes y herramientas, hardware � Interfaz: restricciones impuestas para la

FURPS+

� Interfaz: restricciones impuestas para la interacción humana

� Operaciones: gestión del sistema� Empaquetamiento� Legales: licencias, auditorias, etc.

FURPS+Req F U R P S +

Consultas a

través de un

celular

Deberán

realizarse a

través de

SMS/MMS,

la respuesta

será en

MMS

Pocos

movimiento

s del teclado

Optimizado

para

desplegar

información

importante

Soporte en

Plataformas

J2ME

Ejecutarse

con Equipos

Nokia serie

60

Sistema

Web de

Captura

Indicadores

Seguridad

por

autenticació

n y huella

digital

Optimizado

para

navegador

Opera

… ….

� Del problema asignado (proyecto) realizar larúbrica para especificar al menos 5requerimientos (de preferencia con FURPS).indicando las características de si se cumple ono la actividad.

Actividad

no la actividad.

� Para entregar por equipos como seintegraron en sus proyectos.

� Los prototipos son una excelente herramienta para la obtención de requerimientos dado que el cliente puede ver elementos funcionales en operación del

Prototipos

ver elementos funcionales en operación del proyecto.

� El problema es que es una técnica muy costosa, motivo por el cual su utilización está muy restringida.

Prototipos

Prototipos

Componentes/Prototipos

� No recarga de combustible

� Nuevo sistema de puntuación

Reglas 2011

� Tope presupuestal por equipo de 44 millones de euros.

� Los prototipos son versiones reducidas, demos o conjunto de pantallas (que no son totalmente operativos) de la aplicación pedida.

Prototipos

pedida.

� Esta técnica es útil cuando:

1. El área de aplicación no está bien definida (puede ser algo novedoso)

2. El costo del rechazo de la aplicación es muy alto.

3. Es necesario evaluar primeramente el

Prototipos

3. Es necesario evaluar primeramente el impacto del sistema en la organización.

� La técnica ayuda para visualizar la diferencia entre desarrolladores y usuarios.

� Aunque limitado, se dispone de un sistema funcional en las primeras etapas de desarrollo.

Prototipos

� Esta técnica se resume en: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea”

� Es una técnica costosa

� Chasis básico: $450,000.

� Motor: no se venden de manera individual

Llantas: 28 llantas por evento con un costo de � Llantas: 28 llantas por evento con un costo de $1,200 por juego, alrededor de $150,000 al año

� Costo equipo: 50 personas

� Otras partes: $150,000 de refacciones y $350,000 de partes de la caja de velocidades.

� Costo transporte: $500,000 al año de � Costo transporte: $500,000 al año de transporte.

� Total: mínimo 2 millones, en promedio de 5-10 millones de dólares

� En equipos de 2 Personas se deberá crear un prototipo de avión de papel el cual deberá ser aquel que en las pruebas de ensayo llegue más lejos. lejos.

� Ganará el equipo que con el recurso disponibley las restricciones de tiempo realice bien cada uno de los pasos indicados en la actividad.

� Paso 1: Poner nombre a los equipos.

� Paso 2: Escoger un líder de proyecto.

� Paso 3: Diferenciar roles entre los equipos de trabajo: diseñador, probador, constructor, etc. (Paso 1 a 3: 10%)

� Paso 4: Elaborar especificación de prototipo (50%).

� En este caso se debe tener un diseño claro que � En este caso se debe tener un diseño claro que permita la construcción a gran escala del mismo.

� Cada equipo es responsable de su material, todos los equipos cuentan con igual recurso.

� Paso 5: Personalizar su prototipo con algún detalle y mostrar las mejoras realizadas (la presentación se hace hasta el final) (10%)

� Paso 6: Construcción y elaboración del prototipo a gran escala (20%).

� Paso 7: Se escogerán una muestra aleatoria de dos aviones para la realización de la comprobación de la calidad (10%).

� Joint Application Development, Desarrollo Conjunto de Aplicaciones es una técnica que consiste en realizar sesiones conjuntas entre los analistas de sistemas y los expertos del dominio.

JAD

dominio.

� Con esta técnica se obtienen sistemas más enfocados a la realidad, muchas metodologías nuevas se fundamentan en esta premisa.

� ¿Por qué JAD funciona?

� Por que las entrevistas son lentas, difíciles de hacer y complicadas de obtener datos.

JAD

� Al ser muchos revisores del proyecto es más fácil detectar errores.

� Problema: se requiere de mucha organización

� Implementación Efectiva de SistemasInformáticos desde los puntos de vistaHumano y Técnico.

� Fue desarrollada en 1979 por E. Mumford, se

JAD

� Fue desarrollada en 1979 por E. Mumford, seenfoca en los aspectos sociales que estánpresentes en el desarrollo del software, dadoque un sistema no tendrá éxito sino esutilizado eficientemente por los empleados.

� Existen métodos que toman los puntos devistas de los usuarios para encontrar cosas encomún, un ejemplo es VORD (Definición deRequerimientos Orientados a Puntos de Vista).

� VORD consiste de los siguientes pasos:

VORD

VORD consiste de los siguientes pasos:

� Identificación de puntos de vista

� Estructuración de dichos puntos de vista

� Documentación de puntos de vista (refinación)

� Trazado del punto de vista (conversión a un

VORD

� Trazado del punto de vista (conversión a un diseño orientado a objetos)

� Es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Se centra en los siguientes aspectos:

Etnografía

aspectos:

� La forma en la que las personas trabajan y no como el sistema los hace trabajar

� Los requerimientos se derivan de la cooperación de muchas personas

� En los equipos de trabajo realizar un prototipo nofuncional del sistema en donde se muestren susinterfaces.

� Puede ser a través de bosquejos (spikes), utilizandoherramientas de diagramación (por ejemplo: Visio),utilizando herramientas RAD (Rapid Application

Actividad

utilizando herramientas RAD (Rapid ApplicationDevelopment) como Visual Basic, HTML, NetBeans,etc.

� Entregar al finalizar la clase o mucho a la siguiente.

¿Qué requerimientos hay?

� El estándar IEEE/ANSI 830-1998 sugiere el uso del siguiente formato para SRS:

1 Introducción1.1 Propósito del documento de requerimientos

SRS

1.1 Propósito del documento de requerimientos1.2 Alcance del producto1.3 Definiciones, acrónicos y abreviaturas1.4 Referencias1.5 Descripción del resto del documento

2. Descripción General2.1 Perspectiva del producto2.2 Funciones del producto2.3 Características del usuario2.4 Restricciones generales2.5 Suposiciones y dependencias

SRS

2.5 Suposiciones y dependencias

3. Requerimientos específicos: incluye requerimientos funcionales, no funcionales y de interfaz.* Es la parte medular.

� No hay estructura para esta sección. Debe incluir requerimientos del usuario y del sistema. Se debe incluir una sección para requerimientos cambiantes.

SRS

requerimientos cambiantes.

4. Apéndice (anexo de todo su proceso de obtención de requerimientos)

5. Índice

� La sección 3 contiene por categorías y ordenados por prioridad todos los requerimientos finales del software.

En la etapa de anexos deberá visualizarse la

SRS

� En la etapa de anexos deberá visualizarse la forma en como llegaron a obtener, analizar, especificar y validar requerimientos.

� Consultar documento de especificación de SRS en la página Web del sitio