INGENIERIA DE REQUERIMIENTOS AVANZADA (requisitos) ALINEADO CON LAS MEJORES PRÁCTICAS Capítulo # 1 INGENIERIA DE REQUERIMIENTOS AVANZADA 1. INTRODUCCION ________________________________________________________________ 3 OBJETIVO GENERAL ________________________________________________________________ 5 OBJETIVOS ESPECÍFICOS. _________________________________________________________ 6 2. INGENIERÍA DE REQUISITOS ___________________________________________________ 7 3. CICLO DE VIDA DE LA ADMINISTRACIÓN DE UN PROYECTO _________________ 8 4. DEFINICIÓN DEL PROYECTO ____________________________________________________ 8 5. PLANEAMIENTO INICIAL – DESARROLLO DE REQUISITOS ___________________ 9 6. ESPECIFICACIONES ____________________________________________________________ 12 7. REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES. _____________________ 14 7.1 REQUERIMIENTOS FUNCIONALES __________________________________________________________ 14 7.2 REQUERIMIENTOS NO FUNCIONALES ________________________________________________________ 14 8. METODOLOGÍAS DE REQUERIMIENTOS _______________________________________ 15 8.1 METODOLOGÍA ESTRUCTURADA ___________________________________________________________ 15 8.2 METODOLOGÍA ORIENTADA A OBJETOS ______________________________________________________ 16 9. ESPECIFICACIÓN DE REQUERIMIENTOS ISO/IEEE 830 ______________________ 18 10. OBJETIVOS DE LA ERS. _______________________________________________________ 18 11. CARACTERÍSTICAS DE UN ERS _______________________________________________ 19 11.1 COMPROBACIÓN DE VALIDEZ ____________________________________________________________ 20 11.2 CONSISTENCIA ______________________________________________________________________ 20 11.4. COMPROBACIÓN DE TOTALIDAD _______________________________________________________ 20 11.5 COMPLETITUD ______________________________________________________________________ 21 11.6 VERIFICABILIDAD ____________________________________________________________________ 21 11.7 CLASIFICACIÓN _____________________________________________________________________ 21 11.8 MODIFICABILIDAD ___________________________________________________________________ 21 11.9 EXPLORABILIDAD (TRACEABILITY) _________________________________________________________ 22 11.10 UTILIZABLE DURANTE LAS TAREAS DE MANTENIMIENTO Y USO _____________________________________ 22 12. ESQUEMA DE LA ERS DEFINIDA EN EL IEEE 830-1998 _____________________ 23 I. INTRODUCCIÓN _______________________________________________________________________ 24 II. DESCRIPCIÓN DE LA INFORMACIÓN __________________________________________________________ 24 III DESCRIPCIÓN FUNCIONAL ________________________________________________________________ 24 IV DESCRIPCIÓN DEL COMPORTAMIENTO ________________________________________________________ 25 V SECCIÓN DE CRITERIOS DE VALIDACIÓN ________________________________________________________ 25 VI BIBLIOGRAFÍA. _______________________________________________________________________ 25 13. NATURALEZA DE LA INGENIERÍA DE REQUERIMIENTOS __________________ 26 13.1. MATEMÁTICAS ____________________________________________________________________ 26 13.2. CREACIÓN ________________________________________________________________________ 26 13.3. GESTIÓN DE PROYECTO _______________________________________________________________ 26 14. 1 PARTICIPANTES Y PAPELES _________________________________________________ 27 INGENIERIA DE REQUERIMIENTOS AVANZADA 14.1. CLIENTE _________________________________________________________________________ 27 14.2. DESARROLLADORES __________________________________________________________________ 27 14.3. GESTORES ________________________________________________________________________ 27 14.4. USUARIOS FINALES __________________________________________________________________ 28 14.5. CÓDIGO ÉTICO DE UN INGENIERO DE SOFTWARE _______________________________________________ 28 15. CONCLUSIONES _______________________________________________________________ 31 16. BIBLIOGRAFÍA _______________________________________________________________________ 32 2 INGENIERIA DE REQUERIMIENTOS AVANZADA 1. INTRODUCCION Dentro del campo de la Ingeniería del software se adscriben un sinnúmero de disciplinas, técnicas y metodologías que referencian a todas las actividades relacionadas con la fabricación del software y su gestión, entre las principales se pueden citar ingeniería de requerimientos avanzada, ingeniería de calidad (comúnmente control de calidad), la ingeniería de métodos, ingeniería de usabilidad, arquitectura de bases de datos, todas íntimamente relacionadas que se traslapan durante el ciclo de vida de un proyecto de software de tal forma que el software se comporte confiable y eficazmente, para que sea accesible en su desarrollo, control, mantenimiento y seguimiento y que cumpla con todos los componentes y necesidades que los usuarios o clientes han definido. Este documento aborda la ingeniería de requerimientos avanzada desde sus inicios, su evolución y modernización paralelamente auspiciada y soportada por las Normas Internacionales ISO (ISO.ORG) las cuales dan un soporte de autenticidad a través de la mejora de procesos, entre ellas se citan: ISO/IEC 9001:2000: Adopta un enfoque basado en procesos para el desarrolla, implementación y mejora la eficacia a través de un sistema de gestión de la calidad. (9001:2000, 2000) (Ginebra). ISO/IEC 9001:2008: Modificación de la ISO/IEC 9001:2000 (ISO.ORG) ISO/IEC 9000-3:2004: Se plantea una guía metodología a la aplicación de ISO 9001 para el desarrollo, la aplicación y mantenimiento de software. ISO/IEC 12207:1995: Comprende los procesos del ciclo de vida del desarrollo del software. 3 INGENIERIA DE REQUERIMIENTOS AVANZADA ISO/IEC 12207:2008: Desarrolla un marco común para los procesos de ciclo de vida de software, empleando terminologías claramente definidas. Contiene los procesos, actividades y tareas que se aplican durante la adquisición de un producto de software o servicios y el desarrollo, operación, mantenimiento. ISO/IEC 9126:2001: Establece las características para evaluar la calidad del producto software y establece los lineamientos de la calidad. ISO/IEC 15939:2007: Desarrolla un proceso de medición través de un modelo que contiene las actividades, es adaptable y flexible a los requerimientos de los usuarios. ISO/IEC 15504:2004: Desarrolla y proporciona un marco guía para la evaluación y mejorar la capacidad y madurez de los procesos. Se aliena y aplica junto ISO/OEC 12207. ISO/IEC 14598:1999: Establece pautas que soportan al proceso de evaluación del software. ISO/IEC 25000:2005: Implementa una guía para el uso de las nuevas series de estándares internacionales. El proceso de análisis de requerimientos es la etapa de la ingeniería del software que desarrolla y conecta la asignación del software a en al ámbito del sistema y el diseño y su mantenimiento. (Galeon.com). Los requisitos para un sistema son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su operación. Tales requerimientos reflejan las necesidades de los clientes por un sistema que atienda cierto propósito. Al proceso de descubrir, analizar, documentar y verificar estos requerimientos. 4 servicios y restricciones se le llama ingeniería de INGENIERIA DE REQUERIMIENTOS AVANZADA El cuadro N° 1 muestra el esquema general de los procesos de la ingeniería de requerimientos avanzada (IRA). Objetivo General Desarrollar un guía metodológica bajo las normas generalmente aceptadas que permitan formular procesos cualitativos y cuantitativos sostenibles para el desarrollo y calidad del software, y que mediante la orientación correcta de estos procedimientos tal forma que el software se comporte confiable y eficazmente, para que sea accesible en su desarrollo, control, mantenimiento y seguimiento para que cumpla con todos los componentes y necesidades que los usuarios o clientes han definido. 5 INGENIERIA DE REQUERIMIENTOS AVANZADA Objetivos Específicos. Definir una mejora continua y sostenible en el diseño de aplicaciones de manera tal que se ajusten a los requerimientos de las organizaciones. Especificar a una mayor calidad durante el desarrollar aplicaciones yanto simples como complejas. Definir los costos, el tiempo y el esfuerzo en el desarrollo de proyectos del software. Alinear las normas específicas mundialmente reconocidas como ISO, ITIL, CMMI. Organizar un equipo de trabajo multidisciplinaria bajo los estándares internacionales, en el desarrollo, mantenimiento y seguimiento en aplicaciones de software. Identificar mediante pruebas eficientes las posibles mejoras para una mejor adaptabilidad y aplicaciones de software. 6 continuidad en el funcionamiento de las INGENIERIA DE REQUERIMIENTOS AVANZADA 2. Ingeniería de Requisitos Durante el curso de un proyecto, coexisten dos ciclos de vida que son interdependientes. El ciclo de vida del proyecto, por un lado, podría describir las fases, entregables y actividades que deben ser completadas para producir un producto, servicio o resultado y cada área de aplicación tiene su ciclo de vida específico. Por otro lado, el ciclo de vida de desarrollo del proyecto o ciclo de vida de desarrollo del software que define las etapas que unen su inicio y su final. Para lograr visualizar la logística a utilizar en cada forma de la ingeniería del software y ubicar la etapa de la ingeniería del requerimientos avanzada primero se debe conocer las diferentes normas y metodologías desarrolladas para el ciclo de vida de desarrollo del software, que comprenden 5 elementos, o partes, (llamadas en algunos casos ciclos, etapas, fases), en cada una de estos ciclos se utiliza un tipo variante de ingeniería del software. 7 INGENIERIA DE REQUERIMIENTOS AVANZADA 3. Ciclo de Vida de la Administración de un Proyecto Uno de los retos más importantes para el Director del Proyecto consiste en alinear el ciclo de vida específico del proyecto con el ciclo de vida de su administración ya que estos dos ciclos se traslaparán. Tanto las actividades necesarias para crear el producto del proyecto como las requeridas para su adecuada administración pueden ser asociadas a través de los entregables o salidas de la administración del proyecto. 4. Definición del Proyecto En el caso de negocio se plasma la esencia del proyecto, la necesidad de la que este surge, el problema que debe resolverse, la oportunidad que debe ser aprovechada por la organización. En otras palabras, define algunos de los elementos principales del proyecto y proporciona la información necesaria para apoyar la decisión de iniciarlo y de llevarlo a cabo a través de todas las etapas de su ciclo de vida. El planeamiento inicial del proyecto abarca la definición del alcance inicial, el desarrollo de un cronograma de alto nivel, la identificación de estándares de calidad, la preparación de un presupuesto preliminar, la identificación inicial de riesgos y el desarrollo, a nivel preliminar, de un plan de comunicaciones. Ello supone también la ingeniería de requerimientos donde el punto inicial son los llamados levantamiento de requisitos, los cuales se abarcan en este documento como objetivo principal. 8 INGENIERIA DE REQUERIMIENTOS AVANZADA 5. Planeamiento Inicial – Desarrollo de Requisitos El análisis de requisitos es un proceso iterativo que se presenta como una espiral de actividades que incluye un estudio de factibilidad, adquisición y análisis de requerimientos, especificación de requerimientos (descubrimiento), validación de requerimientos (refinamiento), administración de requerimientos (modelización). Comienza con un refinamiento detallado del ambiente del programa que ha sido inicialmente establecido durante a ingeniería del sistema y refinado durante la planificación del proyecto de software. Dentro del ciclo de vida de un proyecto de software los requisitos son las partes principales del producto o la aplicación que se debe construir por lo que se deben identificar, desarrollar objetivamente y documentarlos. El análisis de requisitos es una condición o capacidad que ser alcanzada o procesada por un sistema o componente de un sistema, especificación u otros documentos formalmente impuesta. (Society) Dentro del detalle se debe comprender las condiciones que debe cumplir o al menos tener una aplicación o sistema en o parte de sus componentes para llegar a satisfacer las necesidades de una aplicación de software. El principal objetivo de los requerimientos es la participación de los analistas, y la participación del rol y responsabilidad de los actores iniciales o usuarios futuros duelos de la aplicación, debido principalmente al conocimiento de los procesos de la organización que se van a automatizar. La técnica de análisis más comúnmente usada para cubrir el vacío de comunicación entre el cliente y el técnico y conseguir que comience el proceso de comunicación, es dirigir una entrevista o revisión preliminar. La primera reunión entre las partes (el ingeniero de software y el cliente) es una proeza. A pesar de todo se sugiere que el analista inicie con unas preguntas independientes del contexto, el primer conjunto de preguntas se centran en el cliente: 9 INGENIERIA DE REQUERIMIENTOS AVANZADA Ejemplo: ¿Quién es el cliente dueño del proyecto? ¿Quién va a utilizar la solución? ¿Cómo se espera el retorno de la inversión de la solución? Las siguientes preguntas permiten al analistas conocer mejor el problema y al c cliente expresar su s ideas sobre la solución. ¿Cómo caracteriza una buena calidad que fuera generada por una solución satisfactoria? ¿Qué problemas resolverá esta solución? ¿Existe alguna forma de verificar y o describirme el ambiente donde se va a utilizar la solución? ¿Dentro del ambiente donde se desarrollara la solución existen limitaciones que afecten la forma en que va a trabajar la solución? La entrevista cierra con una serie de preguntas para logra cuantificar la efectividad de la reunión de la reunión, algunas de ellas son: ¿Es Usted la persona adecuada para responder a estas preguntas? ¿Son oficiales sus respuestas? ¿Las preguntas y cuestionamiento han sido relevantes mis preguntas para resolver su problema? ¿Considera que se deben incorporar más personal para proporcionar información adicional? El documento de requerimientos (llamado algunas veces especificación de requerimientos del software o SRS) es un comunicado oficial de lo que se deben implementar los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para un sistema, como una especificación detallada de los requerimientos del sistema. En ocasiones, los requerimientos del sistema y del usuario se integran en una sola descripción, En otros casos, los requerimientos del usuario se definen en una introducción a la especificación de los requerimientos del sistema. 10 INGENIERIA DE REQUERIMIENTOS AVANZADA Clientes y desarrolladores de software, constantemente tienen inconsistencias en su forma de pensar, como “nosotros y ellos”. No solamente deben trabajar en equipo para identificar y refinar los requisitos, también cada grupo de trabajo define su propio modelo o pensamiento y deben buscar el método de comunicación más apropiado. Con estos problemas presentes se ha desarrollado un enfoque orientado al equipo para la recopilación de requisitos que se aplica durante las primeras etapas de análisis y requisitos llamado Técnica para Facilitar la Especificación de la Aplicación (TFEA), comprende a creación mixta de un equipo de clientes y personas encargadas de desarrollo que trabajan juntos para el desarrollo e identificar el problema. (trackli.googlecode.com) Se han propuesto muchos enfoques diferentes para el método TFEA. Cada uno utiliza un guion ligeramente diferente, peeos tipos aplican alguna variación de las siguientes directrices básicas: Se lleva a cabo una reunión en un lugar neutral, a la que llegan tanto técnicos como clientes. Se establecen reglas para la preparación y participación. Se sugiere una agenda que sea lo suficientemente formal para que cubra todos los puntos importantes, pero lo suficientemente informal para estimular el flujo libre de ideas. Se acuerda la elección de un facilitador para controlar la reunión. (trackli.googlecode.com) Se utiliza una fórmula para la comunicación efectiva El objetivo es identificar el problema, proponer elementos de una solución, avaluar los diferentes enfoques y especifica car un conjunto preliminar de requisitos de la solución en un ambiente adecuada para alcanzar el objetivo. (trackli.googlecode.com) 11 INGENIERIA DE REQUERIMIENTOS AVANZADA 6. Especificaciones Los ingenieros del software se han visto forzados a trabajar con especificaciones incompletas, inconsistentes o mal establecidas, los requisitos del software se pueden analizar de varias formas diferente y las especificaciones puede ser vista como un proceso de representación de forma que conduzca finalmente a una correcta implementación del software. Balzar y Goldman sugieren y propones ocho principios para establecer y desarrollar las buenas especificaciones, entre ellas están: (Chelob) Principio # 1: Hacer una distinción entre funcionalidad e implementación. Una especificación es una descripción de cómo se desea realizar, no de cómo se va a realizar (implementar) Principio # 2: Se requiere utilizar un lenguaje para la especificación de sistema que este orientado al proceso. (Chelob) (Galeon.com) Se debe especificar el sistema completo de las partes que interactúan, en vez de solo un componente. Principio # 3: únicamente y especificación debe comprender y determinar todo el sistema como un todo del cual un determinado software es parte del componente. Un sistema está compuesto de muchos componentes que entrelazan e interactúan entre sí. Únicamente dentro del modelo del sistema como un todo y de la interacción entre sus componentes las partes deben definir el comportamiento de un componente específico y único. (Galeon.com) Principio # 4: similarmente una especificación debe comprender todo el ambiente en el que el sistema debe trabajar en la producción. (Galeon.com) Similarmente, La especificación del entorno permite especificar la interfaz del sistema de la misma forma que los propios sistemas, en vez de introducir un formalismo. 12 INGENIERIA DE REQUERIMIENTOS AVANZADA Principio # 5 Para cada especificación de un sistema debe existir un modelo cognitivo. (Galeon.com) La especificación de un sistema debe ser un modelo cognitivo en vez de un modelo de diseño o de implementación. (Galeon.com) El sistema como tal debe describir un sistema la percepción de los usuarios finales. (Chelob) Principio # 6. Cada especificación única del sistema debe ser operativa. La especificación debe ser completa y lo bastante formal para que puede usarse para determinar especificación, con casos si una de implementación prueba elegidos propuesta satisface arbitrariamente. la (Chelob) (Galeon.com) Principio # 7: La especificación del sistema deben ser tolerantes a la incompletita y ampliable. (Chelob), (Galeon.com) Ninguna especificación estará prácticamente completa. El medio ambiente en que se desarrolla es demasiado complejo y confuso. Una especificación en la mayoría de los casos es un modelo – abstracción- de alguna situación real. (Chelob) Principio # 8: Una especificación prácticamente debe estar localizada y acoplada. (Chelob) La especificación no es un objeto estático previamente compuesto, sino un objeto dinámico que sufre considerable modificaciones. (Chelob) 13 INGENIERIA DE REQUERIMIENTOS AVANZADA 7. Requerimientos Funcionales y no funcionales. Normalmente existen dos tipos de requerimientos siendo funcionales y no funcionales 7.1 Requerimientos Funcionales Los requerimientos funcionales son aquellos que se utilizan para lo que debe hacer el sistema. Tales requerimientos dependen del tipo de software que se está desarrollando, de los usuario esperados del software y del enfoque general que adopte la organización cuando se describen los requerimientos, Los requerimientos funcionales se describen en forma abstracta, los requerimientos funcionales más específicos del sistema detallan las funciones del sistema, sus entradas y salidas 7.2 Requerimientos No Funcionales Los requerimientos no funcionales, son requerimientos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios, pueden relacionarse emergentes del sistema, como fiabilidad, tiempo de resuelta u uso de almacenamiento, capacidad de los dispositivos. Los requerimientos no funcionales afectan más la arquitectura global de un sistema que los componentes individuales, como unos requerimientos de seguridad, surgen a través de las necesidades de los usuarios debido a las restricciones presupuestarias, políticas de la organización, necesidad de interoperabilidad con otro software. 14 INGENIERIA DE REQUERIMIENTOS AVANZADA 8. Metodologías de Requerimientos Teniendo el documento de especificación de requerimientos, el analista desarrollara el modelado de la nueva aplicación. (Piattini Velthuis, 1996). También se pueden utilizar variados tipos de metodologías entre las que más comúnmente existen: la metodología estructurada y la metodología orientada a objetos 8.1 Metodología Estructurada Es considera como la primera aproximación para el desarrollo del problema. En esta metodología predominan los procesos, por lo tanto su objetivo principal es especificar y descomponer la funcionalidad de las aplicaciones. De acuerdo a los movimiento la información se procesa y reprocesa durante la vida del software, esta es modificada por una serie de procesos la cual la y transforma en nueva información. Los diagramas de flujos de datos (DFD) que se desarrollan son una norma técnica para modelado gráfico que esquematiza un flujo de información de datos y las transformaciones que se aplican a los datos al moverse desde el inicio hasta el final de un proceso. (Galeon.com) (trackli.googlecode.com) La metodología estructurada se centra menos en la creación de símbolos gráficos adicionales y más en la representación y especificaciones de los aspectos del software orientado al control. Por tanto se basa en el modelo de flujo como primer elemento de presentación gráfica de un sistema basado en computadora. Usando como base diagramas de flujo de datos y de control, el analista separa las funciones que transforman el flujo. Después, crea un modelo de comportamiento usando un diagrama de transición de estados y un modelo de contenido de datos con un diccionario de requisitos. Las especificaciones de los procesos y del control proporcionan una elaboración adicional de los detalles 15 INGENIERIA DE REQUERIMIENTOS AVANZADA 8.2 Metodología Orientada a Objetos Los métodos orientados a objetos para el análisis de requisitos del software, permiten al analista obtener el modelo de un problema representando clases, objetos, atributos y operaciones como componentes principales de modelación. Los puntos de vista orientados a los objetos combinan la clasificación de objetos, la herencia de atributos y los mensajes de comunicación dentro del contexto de la notación de modelación. Los objetos modernizan casis cualquier aspecto identificable del ámbito del problema: entidades externas, casos, sucesos, papeles, unidades organizativas, lugares y estructuras pueden ser representadas por objetos. Un aspecto importante, se debe a que los objetos encapsulan datos y procesos. Las operaciones de procesamiento son parte del objeto son iniciadas pasando un mensaje al objeto. Una definición de una clase forma la base para la reusabilidad en los niveles de modelación, diseño e implementación. La metodología orientada a objetos proporciona una notación y un conjunto heurístico para construir un modelo AOO- Análisis orientado a objetos. Dentro de las metodologías más predominantes la orientación a objetos es las más recientes y utilizadas en la actualidad, debido a la crecientes ventajas, éntrelas cueles se destaca: La metodología se basa en componentes, o sea es más fácil de reutilizar el código para terceras soluciones. Su mantenimiento y seguimiento es más fácil debido 16 a que los cambios están más focalizados y localizados INGENIERIA DE REQUERIMIENTOS AVANZADA Dentro de las características de los lenguajes orientados a objetos se detallan: Objetos y clases: Un objeto está compuesta por una estructura de datos y de una colección de métodos, los que en sus primeras versiones eran llamados procedimientos o funciones, los cuales manipulan los datos o la información. Los datos estructurados dentro de un objeto son llamados atributos, estos objetos solo puede ser manejados por medio de su interfaz, lo que al final es una colección de funciones que se implementan y son visibles al exterior. Tanto los objetos como las clases contienen muchas características Herencia: Es un mecanismo básico por el que las clases hijas heredan el código de las clases padre. (Alvarez, 2014) Polimorfismo: El polimorfismo es la posibilidad de definir clases diferentes que tienen métodos o atributos llamados de forma idéntica, que se comportan de manera distinta. Este concepto se puede aplicar tanto a funciones como a tipos de datos. De aquí se deriva los conceptos defunciones polimórficas y tipos polimórficos. Funciones Poliformas: son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta. Tipos Poli fórmicos: Los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado. (EduRed) 17 INGENIERIA DE REQUERIMIENTOS AVANZADA 9. Especificación de Requerimientos ISO/IEEE 830 Las Especificaciones de Requerimientos de Software (ERS), es un plan o documento que describe en forma completa y con un nivel de detalle todas las iteraciones y elementos que se requiere para el desarrollo de un proyecto de software y sus aplicativos. El ERS condiciona todos aquellos elementos que se necesitan para construir una solución de software que cumplan con las normas o metodologías aceptadas en el ámbito internacional. 10. Objetivos de la ERS. Dentro de los objetivos de un ERS están desarrolladas las especificaciones de requisitos para el desarrollo de una aplicación de software, entre ellos: Guiar a los a los clientes/Usuarios para que logren describir de una manera clara y objetiva lo que se desea desarrollar para obtener un producto final mediante una aplicación de software, la participación debe ser en forma activa y consecuente en el desarrollo y levantamiento de la especificación de requisitos, ya que el cliente tiene visión global más amplia y detallada de los procesos que se realizan en las labores diarias. (Monferre Agut) (docslide.us/documents/9001.html) Hacer comprender y conceptualizar a los desarrolladores y analistas lo que se requiere concretamente debido a que en muchas ocasiones el cliente/usuario no sabe exactamente o no entiende lo que se requiere. (Monferre Agut) La ERS permite definir todos los requisitos que cumplan con la visión del producto a desarrollar y a los desarrolladores tener una línea base para desarrollar el documento de requerimientos. 18 INGENIERIA DE REQUERIMIENTOS AVANZADA Particularmente del condicionarse la línea base para definir y desarrollar de estándares y nomenclaturas de todo tipo para un ERS lo que puede ser utilizado para cada proyecto del ciclo de vida de sistemas. Con el documento de especificación de requisitos el ingeniero del software puede hacer referencia a la verificación y validación, así como identificar las mejoras y correcciones o actualizaciones en los procesos analizados. La ERS es un documento que detalla ciertos elementos, de una forma objetiva y de una determinada manera, el cuál debe cumplir con el estándar IEEE 830. Una ERS forma parte de los entregables del ciclo de vida del proyecto en su etapa inicial que debe definir correctamente todos los requerimientos necesarios para una mayor flexibilidad a los desarrolladores y analistas para la implementación de la solución del software. 11. Características de un ERS Dentro de características de un documento de especificación de requisitos software se indican las siguientes: 19 Validez Consistencia Ambigüedad Totalidad Completitud Realismo Verificabilidad Clasificación Modificabilidad Explorabilidad (traceability) Utilizable durante las tareas de mantenimiento y uso INGENIERIA DE REQUERIMIENTOS AVANZADA 11.1 Comprobación de validez Se deben considerar y analizar para identificar las funciones adicionales o diferentes que se requieran. Los sistemas tiene diversas participantes con diversas necesidades, y cualquier conjunto de requerimientos es inevitablemente un compromiso a través de la comunidad de participantes. 11.2 Consistencia Los requerimientos en el documento no deben estar en conflicto. Esto es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del sistema. Algunos casos son: Los requisitos que detallan el mismo objeto real bajo diferente terminología. Debe haber una característica específica para cada objeto real. Si se llega a un conflicto lógico entre dos requisitos determinadas. las dos acciones serían perfectamente válidas. 11.3. Ambigüedad No deben darse en una palabra o una frase los múltiples significados, de lo contrario se pueden incluir un glosario de significados. 11.4. Comprobación de Totalidad El documento de requerimientos debe incluir requerimientos que definan todas las funciones y restricciones pretendidas por el usuario del sistema. 20 INGENIERIA DE REQUERIMIENTOS AVANZADA 11.5 Completitud Una ERS tiene completitud si: Una descripción de la función o entidad a especificar. Una descripción de sus entradas y sus procedencias. Una descripción de sus salidas ya a donde se dirigen. Información sobre los datos requeridos para el cálculo u otras entidades en el sistema que se utilizan. Una descripción de la acción que se va a tomar. Se utiliza un determinado estándar. Por las razones suficientes si no se utiliza el estándar determinado o un aparte de él, se debe realizar la observación o nota qué no se ha utilizado dicho apartado. Normas APA: el documento d debe cumplir con la norma APA en lo que respecta a etiquetadas figuras, tablas, diagramas, términos y unidades de medida empleados. 11.6 Verificabilidad Significa que el requisito debe escribirse siempre de manera que sean verificable. 11.7 Clasificación No necesariamente todos los requisitos son igual o tienen la misma importancia. Estos se pueden clasificar por diversos criterios: Importancia: Los requisitos opcionales, requisitos o condicionales. Estabilidad: Diferentes formas de cambios que hacen un llamado a una requisito, por lo que deben establecer prioridades, de modo que de un requisito por su prioridad no emplee excesivos recursos. 11.8 Modificabilidad Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente. Siendo así, lo más recomendado es tener una organización coherente en la que aparezca el índice o una tabla de contenidos fácilmente accesible. (docslide.us/documents/9001.html) 21 INGENIERIA DE REQUERIMIENTOS AVANZADA A su vez también es recomendable evitar la redundancia, para que no aparezca un mismo requisito en varios lugares del ERS, de tal forma, que para modificar un error, será más cómodo si no tenemos que buscar el mismo requisito en varios lugares. (docslide.us/documents/9001.html) 11.9 Explorabilidad (traceability) Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito). (docslide.us/documents/9001.html) (docslide.us/documents/9001.html) Cuando un requisito de la ERS está integrado o desglosado debe detectar las referencias hacia atrás y adelante en el ciclo de vida. (Monferre Agut) Las referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del software. Si el código y los documentos deben ser modificados es primordial poder comparar el conjunto de requisitos que se ven afectados. 11.10 Utilizable durante las tareas de mantenimiento y uso Se debe considerar los procesos de mantenimiento incluyendo personal que nunca ha intervenido directamente en el desarrollo y logre realizar con capacidad su mantenimiento. (docslide.us/documents/9001.html)Así, dicha ERS actúa a modo de plano de la aplicación, permitiendo incluso modificaciones que no requieran un cambio en el diseño. (Monferre Agut) (docslide.us/documents/9001.html) En muchas circunstancias, el actores del desarrollo suponen algunos conocimientos que el personal nuevo que se encargue del mantenimiento no tiene por qué tener. (830) , por lo que ante esta cuestionamiento e imprescindible que la documentación este correcta y que las funciones estén detalladas tanto monitoreadas. 22 en su origen para que puedan ser modificadas, y INGENIERIA DE REQUERIMIENTOS AVANZADA 12. Esquema de la ERS definida en el IEEE 830-1998 La especificación de requisitos del software es el producto final refinado del desarrolló del análisis. La función y el comportamiento asignados al software como parte de la ingeniería de sistemas se refina, estableciendo una descripción completa de la información, una descripción funcional detallada, una indicación de los requisitos de rendimiento y de las restricciones de diseño, unos criterios de validación apropiados. A continuación se retrata un perfil del formato propuesto por el IEEE 8301998. I. Introducción a. Referencia del Sistemas b. Descripción General c. Restricciones el proyecto del Software II. Descripción de la Información a. Representación del flujo d la información. 1. Flujo de Datos 2. Flujo de Control b. Representación del contenido de la información c. Descripción de la interfaz del sistema III. Descripción Funcional a. Partición funcional b. Descripción funcional 1. Narrativa de procesamiento 2. Restricciones/limitaciones 3. Requisitos de rendimiento 4. Restricciones de diseño 5. Diagramas de soporte c. Descripción del control 1. Especificación del Control 2. Restricciones del diseño 23 INGENIERIA DE REQUERIMIENTOS AVANZADA IV. Descripción del comportamiento a. Estados del Sistema Sucesos y acciones V. Criterios de Validación a. Límites de rendimiento b. Clases de Pruebas c. Respuesta esperada del software d. Consideraciones especiales VI. Bibliográfica VII. Apéndice Descripción de los apartados. I. Introducción La introducción describe los fines y los objetivos del software, describiéndoles en el contexto de un sistema basado en computadora. Realmente la introducción puede no ser nada más que el ámbito del documento de planificación. II. Descripción de la Información La descripción de la información proporciona una descripción detallada del problema que del software debe resolver. Estarán documentados el flujo y la estructura de la información. Se describe el hardware, el software y las interfaces humanas, para los elementos externos del sistema las funciones internas del software. III Descripción Funcional La sección de descripción funcional proporciona una descripción de cada función requerida para resolver el problema. Para cada función se da una explicación del procedimiento, se establecen y justifican las restricciones de diseño, se establecen las características del comportamiento y se incluyen uno o más diagramas para representar gráficamente la estructura global del software y la interrelación entre funciones y otros elementos del sistema. 24 INGENIERIA DE REQUERIMIENTOS AVANZADA IV Descripción del comportamiento La sección de descripción del comportamiento examina el funcionamiento del software como una secuencia de los sucesos externos y de las características de control generadas internamente. V Sección de Criterios de Validación La sección de criterios de validación es probablemente la sección más importante e, irónicamente, más descuidada de la especificación de requisitos del software, ¿Cómo reconocer una implementación fructífera? ¿Qué clase de pruebas se deben dirigir para validar la función, el rendimiento y las restricciones? .Descuidamos esta sección porque para complementarla necesitamos un profundo entendimiento de los requisitos del software. Sin embargo, la especificación de los criterios de validación actúa como una revisación implícita de los requisitos. VI Bibliografía. La especificación de requisitos del software incluye una bibliografía y un apéndice. La bibliografía contiene referencias a todos los documentos relacionados con el software, Aquí s e incluye cualquier otro documento de ingeniería dl software, así como las referencias técnicas, los libros adquiridos y los estándares. El apéndice contiene información que complementa la especificación. En el apéndice se presentan las tablas de datos, la descripción detallada de los algoritmos, los diagramas, los gráficos y otro material. 25 INGENIERIA DE REQUERIMIENTOS AVANZADA 13. Naturaleza de la Ingeniería de Requerimientos La ingeniería de software es una disciplina que está orientada a aplicar conceptos y métodos de ingeniería al desarrollo de software de calidad. 13.1. Matemáticas Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales. 13.2. Creación Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la IS. 13.3. Gestión de Proyecto El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en gestión de proyectos. 26 INGENIERIA DE REQUERIMIENTOS AVANZADA 14. Participantes y papeles Para el desarrollo de un sistema de software es necesaria la colaboración de muchas personas con diversas competencias, capacidades e intereses. Al conjunto de personas involucradas en el proyecto se les conoce como participantes. Al conjunto de funciones y responsabilidades que hay dentro del proyecto o sistema se le conoce como roles o papeles. Los roles están asociados a las tareas que son asignadas a los participantes, en consecuencia, una persona puede desempeñar uno o múltiples roles, así también un mismo rol puede ser representado por un equipo.35 14.1. Cliente Es frecuente el uso de los términos "usuarios", "usuarios finales" y "clientes" como sinónimos, lo cual puede provocar confusión; estrictamente, el cliente (persona, empresa u organización) es quién especifica los requisitos del sistema,36 en tanto que el usuario es quien utiliza u opera finalmente el producto software, pudiendo ser o no el cliente. 14.2. Desarrolladores Esta clase de participantes están relacionados con todas las facetas del proceso de desarrollo del software. Su trabajo incluye la investigación, diseño, implementación, pruebas y depuración del software. 37 14.3. Gestores En el contexto de ingeniería de software, el gestor de desarrollo de software es un participante, que reporta al director ejecutivo de la empresa que presta el servicio de desarrollo. Es responsable del manejo y coordinación de los recursos y procesos para la correcta entrega de productos de software, mientras participa en la definición de la estrategia para el equipo de desarrolladores, dando iniciativas que promuevan la visión de la empresa. 38 27 INGENIERIA DE REQUERIMIENTOS AVANZADA 14.4. Usuarios finales El usuario final es quien interactúa con el producto de software una vez es entregado.39 Generalmente son los usuarios los que conocen el problema, ya que día a día operan los sistemas. 14.5. Código ético de un ingeniero de software Un ingeniero de software debe tener un código donde aseguran, en la medida posible, que los esfuerzos realizados se utilizarán para realizar el bien y deben comprometerse para que la ingeniería de software sea una profesión benéfica y respetada. Para el cumplimiento de esta norma, se toman en cuenta ocho principios relacionados con la conducta y las decisiones tomadas por el ingeniero; donde estos principios identifican las relaciones éticamente responsables de los individuos, grupos y organizaciones donde participen. Los principios a los que deben sujetarse son sobre la sociedad, cliente y empresario, producto, juicio, administración, profesión, colegas y por último el personal. Sociedad: Los ingenieros de software deben actuar de manera congruente con el interés social, aceptando la responsabilidad total de su trabajo, moderando los intereses con el bienestar social, aprobando el software solamente si se tiene una creencia bien fundamentada, cooperando en los esfuerzos para solucionar asuntos importantes de interés social, ser justo y veraz en todas las afirmaciones relativas al software o documentos asociados. Cliente y empresario: Se debe actuar de manera tal que se llegue a conciliar los mejores intereses de los clientes y empresarios, congruentemente con el interés social. Estos deberán prestar servicios en sus áreas de competencia, siendo honestos y francos sobre las limitaciones, no utilizar un software que se obtenga ilegalmente o sin ética, usar la propiedad de los clientes o empresarios de manera autorizada, mantener secreto cualquier documento de información confidencial. 28 INGENIERIA DE REQUERIMIENTOS AVANZADA Producto: Hay que asegurarse que los productos y sus modificaciones cumplan con los estándares profesionales más altos posibles, procurando la alta calidad, costos aceptables y una agenda razonable asegurando que los costos y beneficios sean claros y aceptados por el empresario y el cliente. Asegurar que las metas y objetivos de cualquier proyecto sean adecuados y alcanzables. Juicio: Se debe mantener una integridad e independencia en el juicio profesional, moderando todo juicio técnico por la necesidad de apoyar y mantener los valores humanos, mantener la objetividad profesional con respecto a cualquier software o documento relacionado, no involucrarse en prácticas financieras fraudulentas. Administración: Se deberá asegurar una buena administración para cualquier proyecto en el cual se trabaje, utilizando procedimientos efectivos para promover la calidad y reducir riesgos, asegurándose también que se conozcan las políticas y procedimientos del empresario para proteger contraseñas, archivos e información confidencial. Profesión: Se debe incrementar la integridad y reputación de la profesión en conjunto con el interés social, ayudando al desarrollo de un ambiente organizacional favorable para actuar, promoviendo el conocimiento público de la ingeniería de software, extendiendo el conocimiento de la ingeniería de software por medio de participaciones en organizaciones, reuniones y publicaciones profesionales. Colegas: Cada ingeniero deberá apoyar y ser justos con los colegas, motivando a sus colegas sujetándose al código, ayudando también a su desarrollo profesional, reconocer los trabajos de otros y abstenerse a atribuirse de méritos indebidos, revisar los trabajos de manera objetiva, sincera y propiamente documentada. 29 INGENIERIA DE REQUERIMIENTOS AVANZADA Personal: Los ingenieros de software participaran toda su vida en el aprendizaje con la práctica y promoverán un enfoque ético de la profesión, mejorando su conocimiento de los avances en el análisis, especificación, diseño, desarrollo, mantenimiento, pruebas del software y documentos relacionados en conjunto con administración del proceso de desarrollo. 40 30 INGENIERIA DE REQUERIMIENTOS AVANZADA 15. Conclusiones El análisis delos requisitos es e<l primer paso técnico del procesos de ingeniería de requerimientos. Es en este punto donde se refina la declaración general del ámbito del software en una especificación concreta que se convierte en la base de todas las actividades de ingeniero de requerimientos que siguen. En análisis debe centrarse en los ámbitos d información, funcional, y de comportamiento del problema. Para comprender mejor lo que se requiere, se crean modelos, se parte del problema y desarrollan representaciones que muestran la esencia de los requisitos y, posteriormente, los detalles de implementación. En muchos casos no es posible especificar completamente el problema en una etapa tan temprana. La construcción de prototipos constituye un método alternativo, que da como resultado un modelo ejecutable de software a partir del cual se pueda refinar los requerimientos. Para poder construir adecuadamente el prototipo, se necesitan técnicas y herramientas especiales 31 INGENIERIA DE REQUERIMIENTOS AVANZADA 16. Bibliografía 830, 4. /. (s.f.). 49587242 / ERS Según IEEE 830. Obtenido de http://es.scribd.com/doc/49587242/ERS-Segun-IEEE-830 9001:2000, I. (15 de 12 de 2000). Quality management systems -Requirements. Obtenido de http://www.iso.org/iso/catalogue_detail?csnumber=21823 Aguirre, C. (s.f.). NATURALEZA DE LA INGENIERÍA DE SOFTWARE. Obtenido de http://caro9a.blogspot.com/ Alvarez, M. A. (10 de 04 de 2014). Herencia en Programación Orientada a Objetos. Obtenido de http://www.desarrolloweb.com/articulos/herenciaen-programacion-orientada-objetos.html Chelob. (s.f.). Proceso de desarrollo de software. http://www.monografias.com/trabajos5/desof/desof.shtml. docslide.us/documents/9001.html. (s.f.). Especificación de Requisitos Software según. Obtenido de http://docslide.us/documents/9001.html EduRed. (s.f.). Polimorfismo (Informática). http://www.ecured.cu/Polimorfismo_ (Inform%C3%A1tica). F.J. Zarazaga , S., J. Nogueras , I., & M.A. , L. (s.f.). Necesidad de una metodología: La estructurada y la Orientada a Objetos. Obtenido de Ingeniería del Software I: https://sites.google.com/site/cursofpeanalistafuncional/necesidad-deuna-metodologia F.J. Zarazaga Soria, J. N. (s.f.). Necesidad de una metodología: La estructurada y la Orientada a Objetos. Obtenido de Ingeniería del Software I: https://sites.google.com/site/cursofpeanalistafuncional/necesidad-deuna-metodologia Flores, A. (s.f.). Esquema del ERS definida en el IEEE 830-1998. Obtenido de http://dsv666.blogspot.com/ Galeon.com, H. (s.f.). REQUERIMIENTOS DEL SOFTWARE. Obtenido de http://requerimientos.galeon.com/ 32 INGENIERIA DE REQUERIMIENTOS AVANZADA Ginebra, S. C. (s.f.). Número de referenciaISO 9001:2008(traducción oficial)© ISO 2008NORMA INTERNACIONAL Traducción oficial Official translación Traducción officielle. Obtenido de http://docslide.us/education/iso-90015584a66e071ba.html http://es.slideshare.net/AldoMamani/norma-830, http://es.slideshare.net/romulohuancaluque1/9001-2, http://dsv666.blogspot.com/, http://es.scribd.com/doc/49587242/ERSSegun-IEEE-8, & http://docslide.us/documents/9001.html. (s.f.). Especificación de Requerimientos de Software según el estándar IEEE830. Obtenido de http://es.slideshare.net/AldoMamani/norma-830 I, D. d. (s.f.). E78. INGENIERÍA DEL SOFTWARE 5º CURSO DE INGENIERÍA INFORMÁTICA 2000-2001. Obtenido de especificación de Requisitos Software según el estándar de IEEE 830: http://docslide.us/documents/9001.html InSlideShare. (s.f.). Especificación de Requisitos Software Según el Estándar IEEE830. Obtenido de http://es.slideshare.net/romulohuancaluque1/9001-29858820 International Organización for Standardization, I. (s.f.). We develop and publish International Standards. Obtenido de http://www.iso.org/iso/home.html ISO.ORG. (s.f.). ISO 9000 - Quality management. Obtenido de http://www.iso.org/iso/home/standards/managementstandards/iso_9000.htm Miguel Angel, A. (s.f.). Polimorfismo en Programación Orientada a Objetos. Obtenido de http://www.desarrolloweb.com/articulos/polimorfismo- programacion-orientada-objetos-concepto.html Monferre Agut, R. (s.f.). romulohuncaluque/9001-29858820 Especificación de Requisitos según el Estándar IEEE 830. Obtenido de E78 Ingeniería del Software: http://es.slideshare.net/romulohuancaluque1/9001-29858820 Monferrer Agut, R. (2001). Especificación de REquisitos Sotfwar. Obtenido de http://es.slideshare.net/romulohuancaluque1/9001-29858820 33 INGENIERIA DE REQUERIMIENTOS AVANZADA Piattini Velthuis, M. G. (01 de 09 de 1996). Análisis y Diseño detallado de aplicaciones Informáticas de Gestión. Obtenido de http://www.agapea.com/libros/Analisis-y-Diseno-detallado-deaplicaciones-Informaticas-de-Gestion--9788478972333-i.htm Pressman, R. S. (2005). Ingeniería del Software, Un Enfoque Práctico. México: Mc Graw Hill. scribd.com/doc/289109144/. (s.f.). scribd / wiki. Obtenido de http://es.scribd.com/doc/289109144/Wiki Society, I. C. (s.f.). 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology. Obtenido de https://standards.ieee.org/findstds/standard/610.12-1990.html Sommerville, I. (2005). Ingeniería del Software. Madrid, España: Pearson Educación, S.A. trackli.googlecode.com. (s.f.). EVOLUCION DE LA . Obtenido de http://trackli.googlecode.com/svn/trunk/Documentacion/Otra%20inform acion/CMC/ingenieriasoftwaretematica.doc 34
