UNIDAD 4. INGENIERÍA DE REQUERIMIENTOS. La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detall detallad ados, os, incluy incluyen endo do todas todas las interf interface aces s con con gente, gente, máquin máquinas as y otros otros sistem sistemas. as. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante… Entonces, la tarea más importante que el ingeniero de soft softwa ware re hace hace para para el clie client nte e es la extr extrac acci ción ón iter iterat ativ iva a y el refi refina nami mien ento to de los los requerimientos del producto. [ Frederick Frederick P. Brooks, 1987]
INTRODUCCIÓN A través de los años se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos de control con los los que que se cont contar ará á dura durant nte e la etap etapa a de desa desarro rroll llo. o. Adem Además ás la espe especi cifi fica caci ción ón de requer requerimi imient entos os es la base base que que permit permite e verific verificar ar si se alcanz alcanzaro aron n o no los objetivo objetivos s establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va a estar verificando si se están cumpliendo las metas trazadas.
¿Qué es requerimiento? Un requerimiento es una descripción de una condición o capacidad que debe cumplir un sistema. Ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estándar, especificación u otro documento formalmente impuesto al inicio del proceso.
Ingeniería de requerimientos (ver (ver definiciones: ingeniería) ingeniería) * Es el proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un siste istem ma. La meta eta de la ingen ngenie ierí ría a de req requeri uerim mien ientos tos (IR) (IR) es entre ntrega garr una una especificación de requisitos de software correcta y completa. El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
Tipos de requisitos Requisitos funcionales: Dicen qué debe hacer el sistema, en el sentido de servicios proporcionados al usuario.
Requisitos no funcionales: Habl Hablan an de características del sist istema, como puede ser la fiabilid lidad, mantenibilidad, sistema operativo, plataforma hardware, etc.
4.1 OBTENCIÓN DE REQUISITOS 4.1.1 OBJETIVO
Lo que queremos conseguir cuando hacemos algo.
4.1.2 METAS Fin u objetivo que se quiere lograr.
4.1.3 ALCANCES Y LIMITACIONES Alcances El alcance es el tamaño del proyecto. Cuando observe algún proyecto, observe siempre su alcance. Algunos gerentes de proyecto se especializan sólo en proyectos de cierto tamaño, considerando que los pequeños son demasiado insignificantes para su talento, y que los enormes duran demasiado o son demasiado problemáticos como para que les interese participar en ellos.
El alcance del proyecto puede incluir una o más de las consideraciones siguientes: 1. Cuánto se debe lograr en el proyecto 2. Duración de la “ventana” del proyecto (cuándo se debe concluir) 3. Compromiso de recurso (los usuales: dinero, personal, suministros, equipo) Con excepción de los proyectos más simples, cuando se reduce el alcance con frecuencia surgen subproyectos adicionales. Hacerlo demasiado amplio añade complejidad, porque deben manejarse muchos elementos dispares al mismo tiempo.
Limitaciones También conocidas como restricciones, son un factor importante cuando se establece el plan de un proyecto y cuando ya está encaminado. Las restricciones a los proyectos son
muy amplias. Al igual que las restricciones con las que se topa un gerente cuando enfrenta alguna tarea, se debe identificar las restricciones de antemano o un proyecto costoso puede irse por la borda, después de sufrir consecuencias que pudiera haber evitado. Hay tres clases de restricciones o limitaciones en los proyectos: 1. Aquellas que se pueden prever: Si usted sabe que es probable que en el camino suceda algo que pueda afectar al proyecto (mal tiempo, asuntos de trabajo o la partida de un miembro clave del proyecto) puede incluirlo en el programa. 2. Aquellas que surgen a medio proyecto: Los gerentes experimentados de proyectos introducen cierta holgura en el cálculo del tiempo para incluir contingencias, y reacciones en forma proactiva cuando sucede lo inesperado. Es posible que sobrevenga cualquier desastre en n proyecto, desde causas de fuerza mayor (fuerzas naturales) hasta un empleado clave que presento un curriculum vitae falso y que no sabe nada del proyecto en gestión. 3. Proyectos que parten de malos planes o carecen de apoyo: Cualquier empresa que comienza un proyecto debe estar comprometida a terminarlo. Es triste decir que algunos proyectos nunca llegan a su conclusión.
4.1.4 JUSTIFICACIÓN La justificación de un proyecto se hace definiendo claramente la necesidad social a la que se responde o se satisface con él. Tiene por objetivo lograr un entendimiento claro de las necesidades del proyecto y del ambiente en que operará.
4.2 TÉCNICAS PARA OBTENER INFORMACIÓN SOBRE EL PROYECTO. Técnicas y Herramientas utilizadas en las actividades de Ingeniería de Requerimientos: • • • • • • • • • • • •
• • •
Entrevistas y cuestionarios Sistemas existentes Grabaciones de video y de audio Brainstorming (tormenta de ideas) Arqueología de documentos Aprendiz. Observación Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso) Prototipos Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas) Cadena de valor Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases Conceptual Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram) Glosario Diagrama de actividad
• • • • •
Documento ESRE, Casos de uso Lista de requerimientos Casos de uso Casa de calidad o QFD (Quality Function Deployment) Checklist (lista de verificación)
4.3 ESPECIFICACIONES DEL PROYECTO Y CONTRATO Antes de precipitarse e iniciar el proyecto en sí, el contratista o el equipo tienen que dedicar tiempo suficiente a planear en forma apropiada el proyecto. Es necesario preparar un programa o un plan general que muestre cómo se realizarán las tareas dentro del presupuesto y en el tiempo señalado. El intentar realizar un proyecto sin un plan es como intentar armar la bicicleta de un niño sin leer primero las instrucciones. Las personas que piensan que la planeación es innecesaria o que es una pérdida de tiempo, invariablemente después, necesitarán dedicar más tiempo para volver a hacer las cosas. Es importante planear el trabajo y después trabajar el plan. De lo contrario, el resultado será caos y frustración y el riesgo de fracaso será más alto. Ejemplo: Especificación de requisitos
TIPOS DE CONTRATO (leer apuntes teóricos sobre contratos informáticos)
Antes de seguir adelante con el proyecto se tiene que firmar un contrato entre el cliente y el contratista. Un contrato es un vehículo para establecer buenas comunicaciones entre el cliente y el contratista y llegar a una comprensión mutua con claras expectativas que aseguren el éxito del proyecto. Es un convenio entre el contratista, quien acepta proporcionar un producto o servicio (productos o servicios por entregar) y el cliente, quien está de acuerdo en pagarle una cierta cantidad a cambio de ello. El contrato tiene que exponer con claridad las partidas que se espera que proporcione el contratista. También especificará que el resultado del proyecto cumplirá con ciertas especificaciones, o que se proporcionará cierta documentación. El contrato también tiene que precisar las condiciones en las que el cliente hará pagos al contratista. Básicamente son dos los tipos de contratos que existen: de precio fijo y de reembolso del costo.
CONTRATOS DE PRECIO FIJO En un contrato de precio fijo, el cliente y el contratista acuerdan un precio para el trabajo propuesto. El precio permanece fijo a menos de que el cliente y el contratista estén de acuerdo en cambios, este tipo de contrato proporciona bajos riesgos para el cliente, puesto que éste no pagará más que el precio fijo, con independencia de cuánto cueste en realidad el proyecto. Sin embargo, un contrato de precio fijo es de alto riesgo para el contratista, porque si el costo de terminar el proyecto es superior a lo que se planeó originalmente, él tendrá una utilidad inferior a la prevista o incluso perderá dinero. El contratista que presenta una licitación para un proyecto de precio fijo, tiene que desarrollar estimados de costos exactos y completos e incluir los suficientes costos de contingencia. Sin embargo, necesita tener cuidado de no exagerar el precio del proyecto propuesto, pues de lo contrario quizá se seleccione a un contratista competidor con un precio inferior. Los contratos de precio fijo son los más adecuados para proyectos que estén bien definidos y que representen poco riesgo: Entre los ejemplos se incluye la construcción de
una casa modelo estándar, y el diseño y la producción de un folleto para el que el cliente ha proporcionado especificaciones detalladas con relación al formato, contenido, (biografías, color, número de páginas y número de ejemplares.
CONTRATOS DE REEMBOLSO DEL COSTO En un contrato de reembolso del costo, el cliente acepta pagar al contratista todos los costos reales (mano de obra, materiales, etc.), con independencia de la cantidad, más alguna utilidad acordada. Este tipo de contrato representa un alto riesgo para el cliente, puesto que los costos del contratista pueden exceder el costó propuesto —como en el caso en que un servicio de reparación de automóviles proporciona un estimado para reparar una transmisión, pero presenta una cuenta final que es más alta que el estimado original—. Por lo general, en los contratos de reembolso del costo el cliente requiere que, durante el proyecto, el contratista compare periódicamente los gastos reales con el presupuesto presentado y que vuelva a preparar un pronóstico de cuál será el costo a la terminación, comparándolo con el precio original propuesto. Esto le permite al cliente llevar a cabo la acción necesaria si parece que el proyecto superará los costos originales del presupuesto presentado. Este tipo de contrato tiene poco riesgo para el contratista, porque todos los costos serán reembolsados por el cliente. Y no puede perder dinero. Sin embargo, si los costos del contratista exceden el presupuesto, resultará dañada su reputación, lo que a su vez daña sus posibilidades de obtener contratos en el futuro. Los contratos de reembolso del costo son los muy apropiados para proyectos que incluyen riesgos. Entre los ejemplos se incluye el desarrollo de un nuevo dispositivo automático para ayudar durante las cirugías o para la limpieza ambiental de una localidad contaminada.
CLAUSULAS DEL CONTRATO A continuación se presentan algunas cláusulas que se pueden incluir en los contratos de proyectos: 1. Exposición falsa de los costos. Afirma que es ilegal para el contratista exagerar las horas o los costos gastados en el proyecto. 2. Aviso de exceso en los costos o demoras en el programa. Presenta las circunstancias bajo las cuales el contratista tiene que notificar de inmediato al cliente de cualquier exceso real o previsto en los costos o en las demoras del programa, presentando por escrito tanto las razones como un plan para tomar una acción correctiva para hacer que dé nuevo los costos queden dentro del presupuesto o que el programa vuelva a estar de acuerdo con lo previsto. 3. Aprobación de los subcontratistas. Señala cuándo el contratista necesita obtener la aprobación por adelantado del cliente, antes de contratar a un subcontratista para que realice una tarea del proyecto. 4. El equipo o la información a proporcionar por el cliente. Relaciona las partidas (por ejemplo, las piezas para realizar pruebas) que proporcionará el cliente al contratista durante el proyecto y las fechas en que las tendrá a su disposición.
