Guia Completa - Apuntes 1-5 PDF

Preview

Summary

Grupo 1 - Software Requirements Software Requirements Capitulo 1 Lo esencial del requerimiento de software Uno de los problemas con la industria del software es la falta de definiciones comunes para términos que usamos para describir aspectos de nuestro trabajo. Distintos observadores pueden describ...

Description

Grupo 1 - Software Requirements

Software Requirements Capitulo 1 Lo esencial del requerimiento de software Uno de los problemas con la industria del software es la falta de definiciones comunes para términos que usamos para describir aspectos de nuestro trabajo. Distintos observadores pueden describir la misma premisa como un requerimiento de usuario, requerimiento del sistema, requerimiento técnico, requerimiento de negocio, o requerimiento de producto. A un desarrollador, una definición de cliente de requerimiento, puede sonarle como un concepto de producto de alto nivel. La noción del desarrollador de los requerimientos puede sonar a un usuario como un diseño detallado de la interfase de usuario. Esta diversidad de definiciones puede llevar a problemas confusos y problemáticos de comunicación. El concepto clave es que los requerimientos deben ser documentados. Una vez estuve en un proyecto que sufrió una rotación importante de desarrolladores. El cliente principal estaba cansado de tener que escuchar a cada nueva analista de requerimientos decir “Tenemos que hablar sobre sus requerimientos”. La reacción del cliente era, “Ya le di los requerimientos a los anteriores analistas. Ahora armen el sistema!”. En realidad, nadie nunca había documentado los requerimientos, entonces cada nuevo analista tenía que empezar de cero. Decir que ya se tienen los requerimientos cuando solo se tiene una pila de papelitos con notas, mails y conversaciones grabadas es una locura. Algunas interpretaciones de requerimientos El consultor Brian Lawrence sugiere que un requerimiento es “Cualquier cosa que maneje las decisiones de diseño.” (Lawrence 1997). Varios tipos de información encajan en esta categoría. La IEEE Estándar Glossary of Software Engineering Terminology (1990) define un requerimiento como: 1. Una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo. 2. Una condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de sistema para satisfacer un contrato, especificación u otro documento impuesto formalmente. 3. Una representación documentada de una condición o capacidad como las del punto 1 y 2. Esta definición engloba tanto la visión del usuario (El comportamiento externo del sistema) como la del desarrollador (Algunas características internas). El termino usuario debería generalizarse como stakeholder ya que no todos los stakeholders son usuarios. Yo entiendo un requerimiento como una propiedad que el producto debe tener para tener valor para un cierto stakeholder. La siguiente definición reconoce la diversidad de tipos de requerimientos: Los requerimientos son… una especificación de lo que se debería implementar. Son descripciones de cómo debería comportarse un sistema, o de alguna propiedad o atributo del sistema. Pueden ser un constraint (Regla que restringe valores en una base de datos) en el proceso de desarrollo del sistema. Nota: No asuma que todos sus stakeholder de proyectos comparten la misma noción de lo que son los requerimientos. Establezca definiciones de entrada como para saber que se está hablando de lo mismo. 1

Grupo 1 - Software Requirements

Niveles de Requerimientos Esta sección presenta definiciones que voy a usar para algunos términos encontrados comúnmente en el dominio de ingeniería de requerimientos. Los requerimientos de software incluyen tres niveles distintos: requerimientos de negocio, requerimiento de usuario, y requerimiento funcionales. Además, cada sistema tiene una variedad de requerimientos no funcionales. El modelo de la figura 1-1 ilustra una manera de pensar sobre estos diversos tipos de requerimientos. Como con todos los modelos, no incluye todo, pero provee un esquema organizado de ayuda. Los óvalos representan tipos de información de requerimientos y los rectángulos indican containers (documentos, diagramas, o bases de datos) en los que se almacena esa información.

Documento de visión y alcance

Documento de casos de uso

Especificación de los requerimientos de Software

Figura 1-1 Relación entre varios tipos de información de requerimientos. Los Requerimientos de negocio representan objetivos de alto nivel de la organización o del cliente que pide el sistema. Los Requerimientos de negocio usualmente vienen del sponsor que financia, del cliente que adquiere, el encargado de los usuarios, el departamento de marketing, o algún visionario del producto. Los requerimientos de negocio describen porque una organización está implementando el sistema – Los objetivos que la organización espera cumplir. Me gusta guardar los requerimientos de negocio en un documento de visión y alcance, a veces llamado documento de requerimientos de mercado. Crear tal documento es un tema del capítulo 5, “Estableciendo la visión y alcance del proyecto”. Los Requerimientos de Usuario describen las metas de los usuarios o las tareas que los usuarios deberían poder realizar con el producto. Buenas maneras de representar requerimientos de usuario es con casos de uso, descripciones de situaciones, y tablas de decisión. Los requerimientos 2

Grupo 1 - Software Requirements

de usuario entonces describen lo que el usuario debería ser capaz de hacer con el sistema. Un ejemplo de un caso de uso es hacer una reserva usando una aerolínea, un auto rentado, o el sitio Web de un hotel. Los Requerimientos Funcionales especifican la funcionalidad del software que los desarrolladores deberán incluir en el sistema para que los usuarios pueda cumplir con sus tareas, así satisfaciendo los requerimientos de negocio. Algunas veces se los llaman requerimientos de comportamiento, son premisas tradicionales del estilo “Debería”: “El sistema debería enviar por mail una confirmación de reserva al usuario.” Como dice el capitulo 10 (“Documentando los requerimientos”), los requerimientos funcionales describen lo que el desarrollador tendrá que implementar. El termino Requerimientos de sistema describe los requerimientos de mayor nivel para un producto que contiene múltiples subsistemas – Esto es, un sistema (IEEE 1998C). Un sistema puede ser todo software o incluir subsistemas de software y de hardware. La gente es parte de un sistema también, es por eso que ciertas funciones del sistema deberían estar asignadas a seres humanos. Mi equipo una vez realizo software para controlar un aparato de laboratorio que automatizaba la tediosa adición de cantidades precisas de químicos a un conjunto de cubiletes. Los requerimientos para el sistema en su totalidad, nos condujeron a derivar requerimientos funcionales de software a enviar señales al hardware para mover los sensores de posición y demás. Las Reglas de Negocio incluyen las políticas del negocio, regulaciones gubernamentales, estándares de la industria, prácticas contables, y algoritmos computacionales. Como verán en el capítulo 9, “Jugando por las reglas”, las reglas de negocio no son en sí requerimientos de software ya que existen mas allá de los limites de cualquier sistema especifico. De cualquier manera, usualmente quien puede realizar ciertos casos de uso o dicen que el sistema debe tener cierta funcionalidad para cumplir con las reglas pertinentes. Algunas veces, las reglas de negocio son el origen de atributos específicos de cualidades que son implementadas en la funcionalidad. Es por eso que se puede encontrar el origen de ciertos requerimientos funcionales en alguna regla particular de negocios. Los requerimientos funcionales son documentados en una Especificación de requerimientos de software (SRS), que describe como totalmente necesario un comportamiento esperado del sistema. Me voy a referir al SRS como un documento, aunque pueda ser una base de datos o una hoja de balance que contenga los requerimientos e información almacenada en una herramienta de manejo comercial. El SRS se usa en el desarrollo, testing, control de calidad, gerencia del proyecto, y funciones relacionadas del proyecto. Además de los requerimientos funcionales, el SRS contiene requerimientos no funcionales. Esto incluye metas de performance y descripciones de atributos de calidad. Los atributos de calidad aumentan la descripción de la funcionalidad del producto, mediante la descripción de las características del producto en varias dimensiones que son importantes o para los usuarios o para los desarrolladores. Estas características incluyen usabilidad, portabilidad, integridad, eficiencia y robustez. Algunos otros requerimientos no funcionales describen interfaces externas entre el sistema y el mundo exterior, y constraints de diseño e implementación. Los Constraints imponen restricciones a las opciones habilitadas para el desarrollador para diseñar y construir el producto. La gente suele hablar de las características del producto. Una característica es un set de requerimientos funcionales lógicamente relacionados que proveen una capacidad al usuario y permiten la satisfacción de un objetivo de negocio. En el territorio del software comercial, una característica es un grupo de requerimientos reconocibles para un stakeholder que hace una apuesta en una decisión de adquisición. Una lista de un cliente de características deseadas no es 3

Grupo 1 - Software Requirements

equivalente a una descripción de las necesidades relacionadas con las tareas de los usuarios. Corrección de ortografía, grabación macro, ventanas movibles, y actualizaciones online de códigos de impuesto son ejemplos de características de producto. Una característica puede comprender múltiples casos de uso, y cada caso de uso requiere que múltiples requerimientos funcionales sean implementados para permitir que el usuario realice la tarea. Para obtener una mejor idea sobre los distintos tipos de requerimientos estuve discutiendo. Imagínese un programa que procese palabras. Un requerimiento de negocio podría decir: “El producto permitirá a los usuarios corregir eficiente los errores de ortografía en un documento”. La tapa de la caja del producto anuncia que un corrector de ortografía está incluido como una característica que satisface este requerimiento de negocio. Los requerimientos de usuario correspondientes podrían incluir tareas –casos de uso- como: “Encontrar errores de ortografía” y “Agregar palabra a diccionario global”. El corrector de ortografía tiene varios requerimientos funcionales, que lidian con operaciones tales como encontrar y subrayar una palabra mal escrita, mostrar cuadros de dialogo con el reemplazo sugerido, y reemplazar globalmente las palabras mal escritas con las correcciones. El atributo de calidad llamado usabilidad especificaría que es lo que significa “eficientemente” en el requerimiento de negocios. Los encargados o el área de marketing definen los requerimientos de negocios para software que ayudaran a la compañía a operar de manera más eficiente (para sistemas de información) o competir de manera exitosa en el mercado (para producción comercial). Todos los requerimientos de usuario deberían alinearse con los requerimientos de negocios. Los requerimientos de usuario permiten que el analista derive bit de funcionalidad que permitirán a los usuarios realizar sus tareas con el producto. Los desarrolladores usan los requerimientos funcionales y no funcionales para diseñar soluciones que implementen la funcionalidad necesaria y alcancen la calidad especificada y objetivos de performance, dentro de los límites que imponen los Constraints. Aunque el modelo en la figura 1-1 muestre un diagrama de flujo top-down de requerimientos, usted debería esperar ciclos e iteración entre requerimientos de negocio, usuario y funcionales. Siempre que alguien proponga una nueva característica, un caso de uso, o un requerimiento funcional, el analista debe preguntar: “ Esta esto dentro del alcance?” SI la respuesta es “Si”, entonces el requerimiento pertenece a la especificación. Si la respuesta es “no”, entonces no. Si la respuesta fuere “No, pero debería ser”, el dueño de los requerimientos de negocio debería decidir si aumentar o no el alcance del proyecto para acomodar el nuevo requerimiento. Esta es una decisión de negocios que tiene implicaciones en el calendario y presupuesto del proyecto. Que NO son los requerimientos Las Especificaciones de requerimientos no incluyen detalles de diseño o implementación (además de los Constraints), información de planes de proyecto, o información de testing. Hay que separar tales ítems de los requerimientos para que las actividades de requerimientos puedan estar enfocadas en la comprensión de lo que el equipo intenta construir. Los proyectos típicamente tienen otro tipos de requerimientos, incluyendo requerimientos de entorno de desarrollo, limitaciones de horario y presupuesto, necesidad de tutoriales para ayudar a nuevos usuarios o requerimientos para lanzar un producto y moverlo al entorno soportado. Estos son requerimientos de proyecto pero no requerimientos de producto, no entran en el alcance de este libro.

4

Grupo 1 - Software Requirements

Desarrollo y administración de requerimientos La confusión sobre la terminología de requerimientos se extiende incluso hasta la llamada disciplina completa. Algunos autores llaman al dominio entero ingeniería de requerimientos; otros se refieren a él cómo administración de requerimientos. Yo encuentro más práctico separar el INGENIERÍA EN REQUERIMIENTOS

Administración de Requerimientos

Desarrollo de requerimientos

Elicitación

Análisis

Especificación

Validación

dominio de ingeniería de requerimientos de software y administración de requerimientos, como se muestra en la figura 1-2. Figura 1.2 Subcomponentes del dominio de la ingeniería en requerimientos. Desarrollo de Requerimientos Podemos subdividir desarrollo de requerimientos en: Elicitación, análisis, especificación y validación. Estas son subdisciplinas que engloban todas las actividades relacionadas con la recolección, evaluación y documentación de requerimientos para un software o un producto que incluya software, incluyendo lo siguiente: Identificar los tipos de usuarios. Elicitar necesidades de los individuos que representar cada tipo de usuario. Entender tareas y metas de usuarios, y objetivos de negocios con los que las tareas se relacionan. Analizar la información recibida de los usuarios para distinguir sus metas de trabajo de los requerimientos funcionales, requerimientos no funcionales, reglas de negocio, soluciones sugeridas e información extraña. Asignar porciones de requerimientos de alto nivel a componente de software definidos en la arquitectura del sistema. Entender la importancia relativa de los atributos de calidad. Negociar prioridades de implementación. Traducir las necesidades de usuarios recolectadas a especificaciones escritas de requerimientos y modelos. Revisar la documentación de requerimientos para asegurar un entendimiento común de los requerimientos dados por el usuario y corregir cualquier problema antes de que el grupo de desarrollo los acepte. No asuma requerimientos Si no escribe tanto los requerimientos implícitos como los asumidos, no se sorprenda si el software 5

Grupo 1 - Software Requirements

no cumple con las expectativas del usuario. Periódicamente pregúntese “¿Que estamos asumiendo?” para traer a la superficie los problemas ocultos. Si usted se encuentra con un requerimiento asumido escríbalo y confirme si es preciso. Si usted esta desarrollando un sistema de reemplazo revise previamente las características del sistema para determinar si las mismas serán reemplazadas por el nuevo sistema. No asuma si lo hará o no.

6

Grupo 1 - Software Requirements

Capitulo 3 Buenas prácticas para ingeniería de requerimientos Hace diez o quince años, yo era un fanático de las metodologías de desarrollo de software – sets empaquetados de modelos y técnicas que proporcionan soluciones holística para nuestras dificultades de proyecto. Hoy, prefiero identificar y aplicar las mejores prácticas de la industria. Antes que adquirir una solución de paño entero, el acercamiento a la mejor práctica almacena en su kit de herramientas de software una variedad de técnicas que puede aplicar a diversos problemas. Incluso si usted adopta una metodología comercial, adáptela como mejor se adecue a sus necesidades y aumente sus componentes con otras prácticas efectivas de su kit. La noción de las mejores prácticas es debatible: Quien decide que es mejor y en base a qué? Una forma de encararlo es convocar un cuerpo de expertos o investigadores de la industria para analizar proyectos de distintas organizaciones. Estos expertos buscan practicas cuya efectividad de performance este asociada con proyectos exitosos y están mal realizadas o ni siquiera presentes en proyectos fallidos. Esto significa que los expertos llegan a un consenso sobre las actividades que llegan a resultados superiores. Tales actividades son etiquetadas como buenas prácticas. Esto implica que representan formas eficientes para profesionales del software de aumentar las posibilidades de ser exitosos en ciertos tipos de proyecto y en ciertos tipos de situaciones. La tabla 3-1 lista aproximadamente 50 practicas, agrupadas en siete categorías, que pueden ayudar a la mayoría de los grupos de desarrollo a hacer un mejor trabajo con sus actividades de requerimientos. Varias de las prácticas contribuyen a más de una categoría, pero cada práctica aparece solo una vez en la tabla. Estas prácticas no son adecuadas para todas las situaciones, por eso es que hay que utilizar buen criterio, sentido común y experiencia en vez de seguir ciegamente las recomendaciones. Note que no todos los ítems fueron calificados como las mejores prácticas de la industria, es por eso que titule este capítulo “Buenas prácticas para Ingeniería de requerimientos” no “Las mejores prácticas”. Dudo que todas estas prácticas vayan alguna vez a ser evaluadas sistemáticamente para ese propósito. Sin embargo, muchos otros profesionales y yo, hemos encontrado estas técnicas lo suficientemente efectivas. Cada práctica es descrita brevemente en este capítulo. También son provistas referencias a otros capítulos del libro, como para poder obtener más información de cada técnica. El final de este capítulo sugiere un proceso de desarrollo de requerimientos, una serie de actividades que suelen resultar efectivas para muchos proyectos de software.

7

Grupo 1 - Software Requirements

Conocimiento

Administración de Requerimientos

Administración de proyectos

Entrene analistas de Seleccione ciclos de vida Defina el proceso de control de cambios requerimientos apropiados. Instruya a usuarios y directivos Planes de base en Determine la tabla de control de cambios sobre los requerimientos requerimientos (?) Entrene a los desarrolladores en el dominio de aplicación (?) Realice el análisis de impacto de los cambios. Renegocie compromisos Línea de base y control de versiones de los Gestione los riesgos de requerimientos. (Baseline?) requerimientos Cree un glosario Rastree el esfuerzo de los Mantenga un historial de cambios. requerimientos (?) Rastree el estado de los requerimientos Revise lecciones pasadas. Mida la volatilidad de los requerimientos Use una herramienta de administración de requerimientos. Cree una matriz requerimientos

Elicitación

de

Análisis

Defina el proceso desarrollo de requerimientos

Dibuje el diagrama de contexto

Defina visión y alcance Identifique clases de usuarios Seleccione productos magníficos (?)

Cree prototipos

Focalice un grupo

Modele los requerimientos Cree un diccionario de datos Distribuya requerimientos en los subsistemas Aplique funciones de desarrollo de calidad

Identifique casos de uso Identifique eventos y respuestas del sistema Observe a los usuarios trabajando Examine los reportes de problemas Recicle requerimientos

trazabilidad

Analice factibilidad Priorice requerimientos

de

Especificación

Validación

Adopte template de SRS Identifique fuente...