UNIDAD 4. INGENIERA DE REQUERIMIENTOS. La parte ms difcil de construir un sistema es precisamente saber qu construir.

Ninguna otra parte del trabajo conceptual es tan difcil como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con gente, mquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difcil de corregir ms adelante Entonces, la tarea ms importante que el ingeniero de software hace para el cliente es la extraccin iterativa y el refinamiento de los requerimientos del producto. [Frederick P. Brooks, 1987] INTRODUCCIN A travs de los aos 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 planeacin, bsicamente en lo que se refiere a las estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la elaboracin de cronogramas que ser uno de los principales mecanismos de control con los que se contar durante la etapa de desarrollo. Adems la especificacin de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos 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 estn cumpliendo las metas trazadas. Qu es requerimiento? Un requerimiento es una descripcin de una condicin o capacidad que debe cumplir un sistema. Ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso. Ingeniera de requerimientos (ver definiciones: ingeniera) * Es el proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades 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: Hablan de caractersticas del sistema, como puede ser la fiabilidad, mantenibilidad, sistema operativo, plataforma hardware, etc. 4.1 OBTENCIN 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 tamao del proyecto. Cuando observe algn proyecto, observe siempre su alcance. Algunos gerentes de proyecto se especializan slo en proyectos de cierto tamao, considerando que los pequeos son demasiado insignificantes para su talento, y que los enormes duran demasiado o son demasiado problemticos como para que les interese participar en ellos.

El alcance del proyecto puede incluir una o ms de las consideraciones siguientes: 1. Cunto se debe lograr en el proyecto 2. Duracin de la ventana del proyecto (cundo se debe concluir) 3. Compromiso de recurso (los usuales: dinero, personal, suministros, equipo) Con excepcin de los proyectos ms simples, cuando se reduce el alcance con frecuencia surgen subproyectos adicionales. Hacerlo demasiado amplio aade complejidad, porque deben manejarse muchos elementos dispares al mismo tiempo. Limitaciones Tambin 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, despus 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 clculo 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 gestin. 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 conclusin. 4.1.4 JUSTIFICACIN La justificacin 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 TCNICAS PARA OBTENER INFORMACIN SOBRE EL PROYECTO. Tcnicas y Herramientas utilizadas en las actividades de Ingeniera de Requerimientos:

Entrevistas y cuestionarios Sistemas existentes Grabaciones de video y de audio Brainstorming (tormenta de ideas) Arqueologa de documentos Aprendiz. Observacin Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso) Prototipos Anlisis 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 verificacin)

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 cmo se realizarn las tareas dentro del presupuesto y en el tiempo sealado. El intentar realizar un proyecto sin un plan es como intentar armar la bicicleta de un nio sin leer primero las instrucciones. Las personas que piensan que la planeacin es innecesaria o que es una prdida de tiempo, invariablemente despus, necesitarn dedicar ms tiempo para volver a hacer las cosas. Es importante planear el trabajo y despus trabajar el plan. De lo contrario, el resultado ser caos y frustracin y el riesgo de fracaso ser ms alto. Ejemplo: Especificacin de requisitos TIPOS DE CONTRATO (leer apuntes tericos sobre contratos informticos) Antes de seguir adelante con el proyecto se tiene que firmar un contrato entre el cliente y el contratista. Un contrato es un vehculo para establecer buenas comunicaciones entre el cliente y el contratista y llegar a una comprensin 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. Tambin especificar que el resultado del proyecto cumplir con ciertas especificaciones, o que se proporcionar cierta documentacin. El contrato tambin tiene que precisar las condiciones en las que el cliente har pagos al contratista. Bsicamente 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 estn de acuerdo en cambios, este tipo de contrato proporciona bajos riesgos para el cliente, puesto que ste no pagar ms que el precio fijo, con independencia de cunto 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 licitacin 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 ms adecuados para proyectos que estn bien definidos y que representen poco riesgo: Entre los ejemplos se incluye la construccin de

una casa modelo estndar, y el diseo y la produccin de un folleto para el que el cliente ha proporcionado especificaciones detalladas con relacin al formato, contenido, (biografas, color, nmero de pginas y nmero 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, ms 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 reparacin de automviles proporciona un estimado para reparar una transmisin, pero presenta una cuenta final que es ms 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 peridicamente los gastos reales con el presupuesto presentado y que vuelva a preparar un pronstico de cul ser el costo a la terminacin, comparndolo con el precio original propuesto. Esto le permite al cliente llevar a cabo la accin 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 sern reembolsados por el cliente. Y no puede perder dinero. Sin embargo, si los costos del contratista exceden el presupuesto, resultar daada su reputacin, lo que a su vez daa 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 automtico para ayudar durante las cirugas o para la limpieza ambiental de una localidad contaminada. CLAUSULAS DEL CONTRATO A continuacin se presentan algunas clusulas que se pueden incluir en los contratos de proyectos: 1. Exposicin 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 accin 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. Aprobacin de los subcontratistas. Seala cundo el contratista necesita obtener la aprobacin por adelantado del cliente, antes de contratar a un subcontratista para que realice una tarea del proyecto. 4. El equipo o la informacin 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 disposicin.