El Ciclo de Vida del Software y el Desarrollo Informtico

El Ciclo de Vida del Software y el Desarrollo InformticoApuntes de Ingeniera de Software Carrera de Ingeniera en Computacin e InformticaInstituto Profesional La Araucana

El Ciclo de Vida del Software y el Desarrollo InformticoApuntes de Ingeniera de Software

Prof. Andrs Muoz OrdenesCarrera de Ingeniera en Computacin e InformticaInstituto Profesional La Araucana

Tabla de contenidoIntroduccin6Resumen Ejecutivo7Agredecimientos7Unidad I. Una Mirada General a la Ingeniera del Software8Qu es la Ingeniera de Software?9Proceso, Mtodos y Herramientas9Cul es el producto de la Ingeniera de Software?10El Software11Caractersticas del Software11Ciclo de Vida del Software11Aplicaciones del Software12Qu es el Proceso del Software?13El Modelo Lineal Secuencial14El Modelo de Construccin de Prototipos15El Modelo Iterativo Incremental16El Modelo Espiral17El Modelo de Desarrollo Rpido de Aplicaciones (RAD)18El Modelo de Espiral Win-Win19El Modelo de Desarrollo Concurrente20El Modelo de Desarrollo Basado en Componentes21El Modelo de Mtodos Formales22El Modelo del Marco de Trabajo para soluciones Microsoft (MSF)22Qu son los Modelos de Calidad?23Qu son los Estndares de Documentacin?24Tipos de Estndares25Reglas para la Documentacin26Gestin del Proyecto26Especificacin de Requerimientos27Diseo del Sistema28Desarrollo28Pruebas del Software29Otros mbitos29Reflexiones30Unidad II. la Ingeniera de Requisitos37Necesidades o Requisitos/Requerimientos?38Caractersticas de los Requerimientos39Tipos de Requerimientos39Ingeniera de Requerimientos41Stakeholders41El Proceso Iterativo de la Obtencin de Requerimientos42Tcnicas de Identificacin y Anlisis de Requerimientos43Entrevistas con Stakeholders43Tcnicas para Facilitar la Especificacin de una Aplicacin (TFEA)44Despliegue de la Funcin de Calidad (DFC)45Casos de Uso47Tcnicas de Formalizacin y Modelamiento de Requerimientos47Especificaciones en Lenguaje Natural48Especificaciones en Lenguaje Estructurado48Especificaciones con Modelos Grficos50Reflexiones53Unidad III. El Modelamiento del Software57Qu es el Diseo?58Abstraccin58Refinamiento59Modularidad59Arquitectura de Software60Ocultacin de Informacin61Cohesin61Acoplamiento62Principios Bsicos del Diseo62Factores de Calidad64Modelos de Diseo65Modelo de Diseo de la Arquitectura del Software66Decisiones de Diseo66Estilos Arquitectnicos Estndares68Modelo de Diseo de Datos74Modelamiento de Datos durante el Diseo75Modelo de Diseo de Interfaz de Usuario77Interaccin v/s Presentacin77El Proceso de Diseo de la Interfaz79Modelo de Diseo de Componentes79Notaciones para el Diseo de Componentes80Estilos de Diseo de Componentes81Reflexiones84Unidad IV: Dando Valor a la Codificacin93qu es la Codificacin?94Codificacin o Programacin94Lenguajes de Programacin94Algoritmos94Estilos de Programacin95Factores de Calidad96Metodologa para la Estandarizacin de Programas97Estndares de Codificacin97Documentacin del Cdigo99Especificacin Funcional99Comentarios en los Programas100Reflexiones102Unidad V: La Calidad En Ingeniera de Software105Qu es la Calidad del Software?106Calidad107Control de Calidad107Garanta de Calidad107CostOS de Calidad108Fiabilidad108Disponibilidad109Seguridad109Revisiones del Software109Pruebas del Software110El Plan de Aseguramiento de Calidad (SQA)110La Deteccin de Errores111Diseo de los Casos de Prueba112Prueba de Caja Negra113Prueba del Camino Bsico114Prueba de Entornos Especializados, Arquitecturas y Aplicaciones114Estrategias de Prueba115Prueba de Unidad116Prueba de Integracin116Prueba de Validacin117Prueba de Sistema117La Garanta de Calidad118Estndares de Calidad119Tipos de Estndares de Calidad120Estndares de Proceso120Estndares de Producto121El Control de la Calidad122Enfoques del Control de Calidad122Las Revisiones del Software122Revisiones Informales123Revisiones Formales124Las Mtricas del Software126Factores de Calidad127Mtricas para los Factores de Calidad129Reflexiones134Anexos141Metodologas giles de Programacin142El Manifiesto gil142XP (Extreme Programming)143Otras Metodologas giles145Estndares de Codificacin147Estndar de Codificacin para Java147Estndar de Codificacin para PHP149Estndar de Codificacin para .NET150Estndares de Proceso154CMMI154reas de Proceso155Evaluacin156ISO 9000157Marco Conceptual de las Normas ISO 9000158Norma ISO 9001158Proceso de Certificacin160SPICE (ISO/IEC 15504)160Caractersticas161Dimensiones SPICE161Bibliografa163Tabla de Ilustraciones164

Introduccin

Resumen EjecutivoEste documento contiene una compilacin de clases y apuntes del curso de Ingeniera de Software dictado por el profesor Andrs Muoz O. durante 2 aos a alumnos de sexto semestre de la carrera de Ingeniera en Computacin en Informtica del Instituto Profesional La Araucana.Los contenidos principales se dividen en 6 unidades: En la Unidad I se describen los conceptos y principios bsicos de la ingeniera de software. En la Unidad II se estudian las tcnicas asociadas a la ingeniera de requisitos. En la Unidad III se estudian los modelos y tcnicas de especificacin del diseo de software. En la Unidad IV se estudian las tcnicas de documentacin durante la codificacin del software. En la Unidad V se estudian las tcnicas y principios de la calidad del software. En la Unidad VI se estudian las tcnicas para el mantenimiento del software.El contenido de este documento puede ser utilizado como apuntes de curso, material de apoyo para otros profesores como tambin de alumnos de carreras a fines o similares, solo con la debida citacin del autor.Cualquier colaboracin para mejorar este apunte, por favor enviarla a andmunoz@gmail.com.AgredecimientosAgradezco profundamente a mis alumnos del instituto de los aos 2008 y 2009, quienes recibieron este apunte clase a clase, y por supuesto fueron informando todo tipo de errores e inconsistencias que encontraban. Adems, agradecer el apoyo y confianza de los profesores Ral Rojas y Nelson Carvallo, quienes me dieron la oportunidad de lograr desarrollar este ramo. Tambin al profesor Daniel Muoz G., quien tambin dict el curso y me entreg parte de la informacin que aqu se encuentra descrita.Y por ltimo, a mi esposa quin fue comprensiva cuando trabajaba dedicadamente en estos apuntes en la comodidad de mi hogar.A todos, muchas gracias.Profesor Andrs Muoz O.

Unidad I. Una Mirada General a la Ingeniera del SoftwareEl objetivo de esta unidad es entender algunos conceptos de la ingeniera de software, las ventajas de aplicar este enfoque y los principios que cien los siguientes captulos de este apunte.

Qu es la Ingeniera de Software?Aunque muchos autores han desarrollado definiciones personales de la ingeniera del software, una definicin propuesta por Fritz Bauer en una conferencia de gran influencia sobre estos temas va a servir como base de estudio:La ingeniera del software es el establecimiento y uso de principios robustos de la ingeniera, a fin de obtener econmicamente software que sea fiable y que funcione eficientemente sobre mquinas reales.Casi todos tendran la tentacin de seguir esta definicin. No dice mucho sobre los aspectos tcnicos de la calidad del software: no se enfrenta directamente con la necesidad de la satisfaccin del cliente o de la entrega oportuna del producto, omite la mencin de la importancia de mediciones y mtricas y tampoco expresa la importancia de un proceso avanzado.Y, sin embargo, la definicin de Bauer nos proporciona una lnea base. Cules son los principios robustos de la ingeniera aplicables al desarrollo de software? Cmo construimos el software econmicamente para que sea fiable? Qu se necesita para crear programas de computador que funcionen eficientemente, no en una mquina sino en mquinas reales? Estas son cuestiones que siguen siendo el reto para los ingenieros del software.El IEEE ha desarrollado una definicin ms completa:La ingeniera del software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software.Proceso, Mtodos y HerramientasCualquier enfoque de ingeniera (incluida la ingeniera del software) debe apoyarse sobre un compromiso de organizacin de calidad.Se dice que la ingeniera del software es una tecnologa multicapa, ya que se basa en 3 capas bsicas: proceso, mtodos y herramientas. El proceso de la ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera del software. El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para la entrega efectiva de la tecnologa de la ingeniera del software. Las reas claves del proceso forman la base del control de gestin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los mtodos de la ingeniera del software indican cmo construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del software dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la ingeniera del software proporcionan un enfoque automtico o semi-automtico para el proceso y para los mtodos. Cuando se integran herramientas, para que la informacin creada por una herramienta la pueda utilizar otra se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computador (CASE).

Ilustracin 1. Capas Fundamentales de la Ingeniera de SoftwareCul es el producto de la Ingeniera de Software?En primer lugar, debemos contestarnos esta pregunta bsica: Cul es el producto que se obtiene de la labor de ingeniera de software? La respuesta ms lgica es: Software, por supuesto!Y efectivamente, de la labor de ingeniera de software se obtiene software, pero ese no es el nico producto que se obtiene. Adems del software, se obtienen varios otros artefactos, como son documentos, cdigo fuente, aprobaciones del usuario, etc.Los artefactos que se producen dentro del proceso se definen al principio y van a depender de la metodologa que se utilice, del marco legal, de las normativas internas de las compaas involucradas, de las negociaciones iniciales, etc.Algunos de estos artefactos se consideran especialmente dado que dentro de la definicin inicial se establece que se har entrega de ellos y se define cundo, cmo y/o a quin se har esta entrega. Por este motivo se los denomina entregables.El software es, claramente, el principal de estos entregables.El SoftwareEn 1970, menos del uno por ciento de las personas podra haber descrito inteligentemente lo que significa software. Hoy, la mayora de los profesionales y muchas personas, en general, piensan que comprenden el software. Pero lo entienden realmente?Caractersticas del SoftwarePara poder comprender lo que es el software (y consecuentemente, la ingeniera del software), es importante examinar las caractersticas del software que lo diferencian de otras cosas que los hombres pueden construir. Cuando se construye un hardware, el proceso creativo humano (anlisis, diseo, construccin, prueba) se traduce en una forma fsica. Si construimos un nuevo computador, nuestro boceto inicial, diagramas formales de diseo y prototipo de prueba evolucionan hacia un producto fsico.El software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto, el software tiene unas caractersticas considerablemente distintas a las del hardware.Aunque existen similitudes entre el desarrollo del software y la construccin del hardware, ambas actividades son fundamentalmente diferentes. Ambas actividades dependen de las personas, pero la relacin entre las personas dedicadas y el trabajo dedicado es completamente diferente para el software Los costes del software se encuentran en la ingeniera. Esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de construccin.Un aspecto claro en la diferencia entre la construccin de hardware y el desarrollo del software est en el mantenimiento. Cuando el hardware se estropea, se sustituye alguna pieza por otra nueva. En cambio, no hay piezas de repuesto para el software: cada fallo en el software implica un problema en el diseo en la forma en que este fue llevado a su forma final, por lo tanto, el mantenimiento del software tiene una complejidad mucho mayor a la del mantenimiento del hardware.Otra clara diferencia est relacionada con el hecho de que la construccin en la industria est ms automatizada y consiste normalmente en ensamblar componentes, mientras que el desarrollo de software est hecho a medida. En la construccin de hardware, por ejemplo, la reutilizacin de componentes es una parte natural del proceso de ingeniera. En el mundo del software, en cambio, slo ha comenzado a lograrse.Ciclo de Vida del SoftwareEl software pasa por varias etapas desde su concepcin hasta su evolucin debido a los cambios de su entorno, conformando lo que llamamos ciclo de vida. Estas etapas se pueden agrupar en tres grandes fases: La fase de definicin se centra sobre el qu. Es decir, durante la definicin, el que desarrolla el software intenta identificar qu informacin ha de ser procesada, qu funcionalidades y rendimientos se desean, qu interfaces van a ser establecidas, qu restricciones existen y qu criterios de validacin se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Esta fase contempla las etapas de levantamiento y anlisis de requerimientos. La fase de desarrollo se centra en cmo. Es decir, durante el desarrollo de, un ingeniero del software intenta definir cmo han de disearse las bases de datos, cmo han de estructurarse las funcionalidades dentro de una arquitectura de software, cmo han de implementarse los detalles de implementacin, cmo han de caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin y cmo han de realizarse las pruebas. Esta fase contempla las etapas de diseo, construccin, pruebas e instalacin. La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas a medida que evoluciona el entrono del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Esta fase contempla las etapas de operacin, mantenimiento y retiro.Aplicaciones del SoftwareEl software ha tenido una gran expansin en las reas en que es aplicable, debido a que, si una labor se puede describir y explicar su lgica, es factible de automatizar mediante software.Es difcil establecer categoras genricas para las aplicaciones del software que sean significativas. Conforme aumenta la complejidad del software, es ms difcil establecer compartimentos ntidamente separados. Las siguientes reas del software indican la amplitud de las aplicaciones potenciales: Software de Sistemas: El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas (por ejemplo: compiladores, editores y utilidades de gestin de archivos) procesan estructuras de informacin complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo: ciertos componentes del sistema operativo, utilidades de manejo de perifricos) procesan datos en gran medida indeterminados. En cualquier caso, el rea del software de sistemas se caracteriza por una fuerte interaccin con el hardware del computador, una gran utilizacin por mltiples usuarios, y una sofisticada gestin de procesos y recursos. Software de Tiempo Real: El software que coordina/analiza/controla sucesos del mundo real conforme ocurren se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisicin de datos que recolecta y da formato a la informacin recibida del entorno, un componente de anlisis que transforma la informacin segn lo requiera la aplicacin, un componente de control/salida que responda al ambiente externo y un componente de monitorizacin que coordina todos los dems de forma de poder tener respuesta en tiempo real (normalmente, en fracciones de segundo). Software de Gestin: El proceso de la informacin comercial constituye la mayor de las reas de aplicacin del software. Los sistemas discretos (por ejemplo: nminas, cuentas de haberes, dbitos, inventarios, etc.) han evolucionado hacia el software de sistemas de informacin de gestin, que accede a una o ms bases de datos que contienen informacin comercial. Las aplicaciones en esta rea reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Adems, las aplicaciones de software de gestin tambin realizan clculo interactivo. Software de Ingeniera y Cientfico: El software de ingeniera y cientfico est caracterizado por lo algoritmos de manejo de nmeros. Las aplicaciones van desde la astronoma a la vulcanologa, desde el anlisis de la presin en un motor a la simulacin de reacciones en un acelerador de partculas. Sin embargo, las nuevas aplicaciones del rea cientfica han ido tomando caractersticas del software de tiempo real y del software de sistemas. Software Empotrado: Los productos inteligentes se han convertido en algo comn en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de slo lectura y se utiliza para controlar productos y sistema de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy bsicas y limitadas (por ejemplo: el control de las teclas de un microondas) o suministrar una funcin significativa y con capacidad de control (por ejemplo: funciones computarizadas en un automvil, tales como control de la gasolina, sistemas de frenado inteligente, etc.). Software de Computadores Personales: El mercado de los computadores personales ha germinado en las pasadas dos dcadas. Software como los procesadores de texto, hojas de clculo, editores de imgenes, multimedia, entretenimiento, etc. son algunos de los cientos de aplicaciones que se pueden encontrar para este mercado. Software de Inteligencia Artificial: El software de inteligencia artificial hace uso de algoritmos no numricos para resolver problemas complejos para los que no son adecuados el clculo o el anlisis directo. Los sistemas expertos, tambin llamados sistemas basados en el conocimiento, reconocimiento de patrones, redes neuronales, etc. son representativos de esta categora.Qu es el Proceso del Software?Para resolver los problemas reales de una industria, un ingeniero de software o un equipo de ingenieros deben incorporar una estrategia de desarrollo que acompae al proceso, mtodos y herramientas con las fases genricas del ciclo de vida del software. Esta estrategia a menudo se llama modelo de proceso o paradigma de ingeniera de software. La seleccin de un modelo de proceso de ingeniera del software adecuado depende de la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse y los controles y entregas que se requieren. En las secciones siguientes se tratan algunos modelos de procesos clsicos para la ingeniera del software[footnoteRef:1]. Cada uno representa un intento de ordenar una actividad inherentemente catica. Es importante recordar que cada uno de los modelos se ha caracterizado de forma que ayuden al control y a la coordinacin de un proyecto de software real. [1: Probablemente solo es un extracto de los ms conocidos o usados modelos, sin embargo la ingeniera de software est en constante evolucin, lo cual hace impredecible cul ser el modelo de desarrollo que utilizaremos el da de maana.]

El Modelo Lineal SecuencialLlamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. Modelado segn el ciclo de ingeniera convencional, el modelo lineal secuencial comprende las siguientes actividades: Ingeniera y modelado de Sistemas/Informacin: Como el software siempre forma parte de un sistema ms grande, el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algn subgrupo de estos requisitos. Esta visin del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniera y el anlisis de sistemas comprenden los requisitos que se recogen en el nivel del sistema con una pequea parte del anlisis y de diseo. La ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa estratgico y en el nivel del rea de negocio. Anlisis de los requisitos del software: El proceso de reunin de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del programa a construirse, el ingeniero de software debe comprender el dominio de informacin del software, as como la funcionalidad requerida, comportamiento, rendimiento e interconexin. Diseo: El diseo del software es realmente un proceso de muchos pasos que se centran en varios atributos distintos del programa, dependiendo de la tecnologa que se est utilizando (procedural, orientada a objetos, funcional, lgica). El proceso del diseo traduce requisitos en una representacin del software donde se pueda evaluar su calidad antes de que comience la codificacin. Generacin del cdigo: El diseo se debe traducir en una forma legible por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo en una forma detallada, la generacin de cdigo se realiza mecnicamente. Pruebas: Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado y en los procesos externos funcionales, es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento: El software indudablemente sufrir cambios despus de ser entregado al cliente. Se producirn cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entrono o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.El modelo lineal secuencial es el paradigma ms antiguo y ms extensamente utilizado en la ingeniera del software. Sin embargo, la crtica del paradigma ha puesto en duda su eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen:1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. Aunque el modelo lineal puede acoplar interaccin, lo hace indirectamente. Como resultado, los cambios pueden causar mucha confusin.2. Es difcil que el cliente exponga explcitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar el flujo real de requerimientos.3. El cliente debe tener paciencia. Una versin de trabajo del programa no estar disponible hasta que el proyecto est muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se ve el programa.El ciclo de vida clsico sigue siendo el modelo de proceso ms extensamente utilizado por la ingeniera del software.El Modelo de Construccin de PrototiposUn cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptacin de un sistema operativo, o de la forma en que debera tomarse la interaccin hombre-mquina. En estas y en otras muchas situaciones, un paradigma de construccin de prototipos puede ofrecer el mejor enfoque.El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.Lo ideal sera que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas (por ejemplo: generadores de informes, gestores de ventanas, etc.) que permiten generar rpidamente programas de trabajo.Pero qu hacemos con el prototipo una vez que ha servido para el propsito descrito anteriormente? Brooks proporciona una respuesta:En la mayora de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es ms inteligente, y construir una versin rediseada en la que se resuelvan estos problemas Cuando se utiliza un concepto nuevo de sistema o una tecnologa nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque incluso la mejor planificacin no es omnisciente como para que est perfecta la primera vez. Por lo tanto la pregunta de la gestin no es si construir un sistema piloto y tirarlo. Tendremos que hacerlo. La nica pregunta es si planificar de antemano construir un desechable, o prometer entregrselo a los clientesEl prototipo puede servir como primer sistema, el que Brooks recomienda tirar. Aunque esta puede ser una visin idealizada, es verdad que a los clientes y a los que desarrollan les gusta el paradigma de construccin de prototipos. A los usuarios les gusta el sistema real y a los que desarrollan les gusta construir algo inmediatamente. Sin embargo, la construccin de prototipos tambin puede ser problemtica por las siguientes razones:1. El cliente ve lo que parece ser una versin de trabajo del software, sin tener conocimiento de que el prototipo tambin est pegado con chicle, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen unos pequeos ajustes para que se pueda hacer del prototipo un producto final. De forma demasiado frecuente la gestin de desarrollo del software es muy lenta.2. El desarrollador, a menudo, hace compromisos de implementacin para hacer que el prototipo funcione rpidamente. Se puede utilizar un sistema operativo o lenguaje de programacin inadecuado simplemente porque est disponible y porque es conocido; una solucin eficiente se puede implementar simplemente para demostrar la capacidad. Despus de algn tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La seleccin menos ideal ahora es una parte integral del sistema.Aunque pueden surgir problemas, la construccin de prototipos puede ser un paradigma efectivo para la ingeniera del software. La clave es definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya para servir como un mecanismo de definicin de requisitos.El Modelo Iterativo IncrementalEl modelo iterativo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Por ejemplo, un software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin ms sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pgina en el cuarto. Se debera tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos.Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.El desarrollo incremental es particularmente til cuando la dotacin de personal no est disponible para una implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas.El modelo iterativo incremental es, adems, la base de las metodologas ms actuales, en particular debido a que, asociada a UML, la metodologa del proceso unificado (UP) est definida como un proceso iterativo incremental. Esto implica que muchas de las metodologas basadas en UP (RUP, XP. dX, etc.) son, en esencia, incrementales.El Modelo EspiralEl modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.El modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Un modelo de seis regiones puede contener: Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. Planificacin: las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y de gestin. Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y accin: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentacin y prctica) Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.Cada una de las regiones est compuesta por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las caractersticas del proyecto que va a emprenderse. Para proyectos pequeos, el nmero de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y ms crticos cada regin de tareas contiene tareas de trabajo que se definen para lograr un nivel ms alto de formalidad. En todos los casos, se aplican las actividades de proteccin (por ejemplo: gestin de configuracin del software y garanta de calidad del software) mencionadas ms adelante en este apunte.Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. El coste y la planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el software.A diferencia del modelo de proceso clsico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemticos. Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difcil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con esta habilidad para el xito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. El Modelo de Desarrollo Rpido de Aplicaciones (RAD)RAD es un modelo lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto, basndose en una construccin basada en componentes. Estos ciclos debes ser suficientemente cortos (60 a 90 das por ejemplo) para obtener componentes totalmente funcionales, pero requiere un alto entendimiento de los requisitos, adems de lmites bien definidos para el alcance del proyecto. El RAD utilizado para sistemas de informacin (gestin) podra contener las siguientes fases: Modelado de Gestin: Modela el mbito de la gestin de la informacin (Qu informacin conducen? A dnde va la informacin? Quin la procesa? Quin la genera? Qu informacin genera?). Modelado de Datos: Modelado del grupo de objetos que define la informacin del modelado de gestin. Modelado de Proceso: Modelado de los procesos de transformacin de la informacin. Generacin de Aplicaciones: Se construye el software (preferentemente con lenguajes de cuarta generacin y reutilizacin de componentes de software. Pruebas y Entrega: Se pruebas los componentes nuevos[footnoteRef:2]. [2: Como el proceso enfatiza la reutilizacin de componentes, la mayora ya vienen probadas, es por eso que las pruebas se centran en las componentes nuevas y en la integracin.]

Al igual que otros modelos, RAD tiene deficiencias: Para proyectos a grandes escalas, la cantidad de recursos humanos necesarios tiene que ser equivalente al nmero de equipos que se puedan formar. Requiere de compromisos de realizacin rpida de aplicaciones, sin l los desarrollos no se pueden realizar en el tiempo esperado. Si un sistema no es modularizable, no se puede hacer con RAD. Si el proyecto tiene riesgos tcnicos altos, RAD no es apropiado para l.El Modelo de Espiral Win-WinEl Espiral Win-Win enfatiza en el concepto de obtener los beneficios para ambos lados del proyecto: clientes y desarrolladores. Este paradigma supone que el cliente gana cuando cubre la mayor cantidad de necesidades y el desarrollador gana cuando obtiene presupuestos y fechas de entrega realistas.En el espiral del modelo, no se definen solo las tareas de acuerdo a su caracterstica o misin, sino que de acuerdo al nivel de negociacin que se deba realizar. De esta forma, al principio de cada actividad, se deberan realizar algunos acuerdos, por ejemplo: Identificar algunos sistemas claves para directivos. Determinar condiciones de satisfaccin de los directivos. Negociacin de las condiciones de victoria de los directivos.Adems, para complementar el ciclo alrededor de la espiral, se definen 3 puntos de fijacin, los cuales definen el lmite entre la negociacin y el resto del trabajo en el desarrollo del software. Estos puntos son: Los Objetivos del Ciclo de Vida (OCV), que definen un conjunto de metas para cada actividad. La Arquitectura del Ciclo de Vida (ACV), que define objetivos que se deben conocer mientras se define la arquitectura del software y el sistema. La Capacidad Operativa Inicial (COI), que representa los objetivos asociados a la preparacin de la instalacin/distribucin del software.El Modelo de Desarrollo ConcurrenteEl modelo de Desarrollo Concurrente ms que una metodologa formal como las anteriormente descritas, se preocupa de un problema clave en el proceso de desarrollo: las actividades del proceso por naturaleza no son lineales.En efecto, cuando estamos hablando de que todas las actividades deben ser concurrentes, ya que estn activas durante el proceso o iteracin del desarrollo. Sin embargo, lo que plantea el autor es que dichas actividades en realidad se encuentran en diferentes estados: Bajo desarrollo Cambios en espera Bajo modificacin Bajo revisin En lnea base RealizadoEn el siguiente esquema se muestra un diagrama de estados en donde se ven las diferentes transiciones entre los estados:

Ilustracin 2. Diagrama de Estados del Modelo ConcurrenteDe esta manera, si en un espiral se definen 3 actividades: modelado de prototipo, especificacin de requisitos y diseo, entonces pueden encontrarse en diferentes estados, pero existen siempre las 3 actividades durante el proceso de desarrollo.El Modelo de Desarrollo Basado en ComponentesEl modelo de Desarrollo Basado en Componentes es un modelo inherentemente evolutivo, que por lo general utiliza los principios del desarrollo espiral pero que en la fase de ingeniera incorpora una actividad adicional de bsqueda de las componentes en la biblioteca o diccionario.

Ilustracin 3. Proceso para el Desarrollo Basado en ComponentesEn el diagrama se muestra un flujo que define la actividad entre la ingeniera y la construccin-adaptacin. Este flujo indica 6 pasos que es necesario seguir en el modelo de desarrollo basado en componentes: Se identifican componentes candidatos para el requerimiento. Se buscan los componentes en la biblioteca. Extraer las componentes si estn disponibles en la biblioteca. Construir componentes si no estn disponibles en la biblioteca. Poner componentes nuevos en la biblioteca. Construir la iteracin del sistema.Es natural entender que est orientado a la reutilizacin, ya que pretende compartir a travs del proyecto (y ms all) una biblioteca de elementos que son reusables. El Proceso Unificado de Desarrollo es el mejor ejemplo de un modelo de desarrollo basado en componentes, ya que en cada iteracin, las clases quedan disponibles para la siguiente iteracin del proceso y as sucesivamente hasta construir el sistema por completo.El Modelo de Mtodos FormalesEl modelo de Mtodos Formales es una metodologa orientada a desarrollar software 100% libre de errores (y no es esa la misma intencin de la IS?). Este modelo utiliza notacin matemtica y rigurosa para especificar, desarrollar y verificar el software a lo largo del proceso de desarrollo.Dada su aplicabilidad, se plantean algunas preocupaciones en los proyectos: Es caro y toma mucho tiempo (ms de lo necesario). Se requiere un estudio detallado del proyecto, ya que no existen los antecedentes necesarios en el equipo de trabajo. Es difcil utilizarlo con clientes con bajos conocimientos tcnicos.Lo que por supuesto impacta tanto en la planificacin, costos y confianza hacia el proyecto. Sin embargo, existen partidarios en mbitos de desarrollo de software de alta seguridad como aeronuticos o mdicos, ya que un error puede ser fatal.El Modelo del Marco de Trabajo para soluciones Microsoft (MSF)El Modelo del Marce de Trabajo para Soluciones Microsoft (Microsoft Solutions Framework, MSF) es un enfoque evolutivo que saca las caractersticas incrementales del modelo espiral y las etapas de un enfoque lineal-secuencial. A pesar de estar en el mbito de la ingeniera de software, la forma en la que fue concebido tambin es aplicable a otros proyectos de tecnologas de informacin (infraestructura, redes, etc).MSF pas por un proceso de evolucin, el cual comenz el ao 1993 con su primera versin (MSF 1.0), la cual con el tiempo fue cambiando y mejorndose hasta la versin actual (MSF 4.0) vigente desde el ao 2005. Su centro son las mejores prcticas aplicadas en el desarrollo de herramientas Microsoft, reunidas en un conjunto de principios y procesos aplicables en otros mbitos de desarrollo o implementacin de tecnologas de informacin.Este modelo se basa en 8 principios bsicos: Fomenta la comunicacin abierta, en cualquier parte del equipo de trabajo. Trabaja en beneficio de la visin compartida del proyecto. Permite autonoma en el equipo de trabajo. Establece un claro modelo de rendicin de cuentas y responsabilidad. Se centra en entregar valor al negocio. Mantiene una visin gil, siempre predispuesta al cambio. La importancia de la inversin en la calidad del producto. Aprendizaje de todas las experiencias.Dependiendo de las caractersticas del proyecto, MSF permite enfoques de distinta ndole, ya sea estructurado (como enfoques de tipo cascada) como gil (enfoque ms parecido a RAD)[footnoteRef:3]. [3: Mayor informacin en http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework ]

Qu son los Modelos de Calidad?Una definicin abierta de calidad podra ser la siguiente:Es un conjunto de herramientas y caractersticas inherentes de un objeto que confiere la capacidad de satisfacer las necesidades explcitas e implcitas de un problema[footnoteRef:4] [4: Definicin clsica de calidad en http://es.wikipedia.org/wiki/Calidad ]

Esta definicin es aplicable a cualquier mbito, ya que tanto los productos tangibles como refrigeradores, automviles, casas, etc. deben cumplir con ella para ser de calidad. Por ejemplo si estamos hablando de un automvil, existen caractersticas que son claramente parte de lo que debe hacer (debe tener el volante a la izquierda, al menos en nuestro pas, cumplir con cierta cantidad de emisiones de CO2, poseer habitculo indeformable, entre otras). Sin embargo, existen otras que no son parte de lo que uno pide en un auto (debe tener parabrisas adelante, tubo de escape, puertas y ruedas, algo que parece obvio). En el software pasa lo mismo, ya que los requerimientos (necesidades explcitas) y las caractersticas naturales (necesidades implcitas, como libre de errores) deben ser cumplidos para ser un software de calidad.La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede, supere las expectativas de los usuarios.La certificacin es la consecuencia de un proceso de aseguramiento de la calidad, pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en funcin de la normalizacin.Existen algunas mtricas para la calidad del software (nmero de errores, fallos en la codificacin o diseo, tamao del producto informtico, costos v/s esfuerzos, etc). Sin embargo, no se puede medir la calidad de forma correcta debido a su naturaleza. La certificacin se da a los procesos por lo que la correcta consecucin de los mismos garantizara un buen software. Sin embargo, El hecho de que una empresa tenga certificacin en calidad de software no garantiza que su software sea de calidad.No se puede medir al software como tal, sino los atributos que la conforman, tales mtodos de medida deben ser exactos. El usuario final mide la calidad del software segn lo que tenga o no, es en ese sentido de que la calidad del software depende de quien la juzgue. Qu son los Estndares de Documentacin?Antes de entrar en el detalle de los estndares de documentacin en ingeniera de software, debemos definir a qu nos queremos referir cuando hablamos de estndar:es una especificacin que regula la realizacin de ciertos procesos o la fabricacin de componentes para garantizar la interoperabilidad.De esta manera, podemos definir que un estndar de documento no es ms que una plantilla que nos permite definir, de manera nica y universal, un cierto tipo de documentos, de manera de que sea legible en cualquier mbito.Tal como ya se ha mencionado anteriormente, uno de los productos del proceso de desarrollo son los documentos (de planificacin, de anlisis, de diseo, de planes de prueba, de contratos, de acuerdos, de minutas, etc.), los cuales contienen una parte importante del software que se desea o se ha construido: la memoria del proceso de desarrollo.Con el desarrollo del rea de ingeniera de software se han definido que, segn el proceso de desarrollo elegido, se pueden elaborar ciertos estndares de documentacin, los cuales poseen no solo informacin en lenguaje natural, sino que es descrita en lenguaje de alto nivel (como UML) hasta lenguaje de ms de bajo nivel (como Pseudocdigos o de programacin).

Ilustracin 4. Esquema para las Diferentes Vistas del SoftwareTodo esto corresponde a un objetivo particular: orientar cada documento para un pblico objetivo especfico. De esta manera, los documentos asociados a procesos ms tcnicos, poseen diagramas o cdigos respectivos a dichos profesionales, en cambio si los documentos estn orientados al anlisis de negocio, el lenguaje debe ser ms cercano al dominio en el cual se est desarrollando.Tipos de EstndaresExisten 3 tipos de estndares de documentacin que permiten mejor fluidez de la informacin a lo largo del proyecto: Estndares de Proceso de Documentacin: Define el proceso a seguir para la produccin de un documento. Esto implica definir los flujos de trabajo necesarios en la generacin de un documento y las herramientas necesarias para esto. Tambin define procedimientos de comprobacin y refinamiento que aseguren que los documentos son de calidad. Estndares del Documento: Define la estructura y presentacin del documento. Todos los documentos deben tener una estructura y un estilo bien definidos, a lo largo del proyecto, manteniendo la consistencia del flujo de informacin. An cuando por cada proyecto se puede utilizar estndares diferentes, la recomendacin es que siempre se mantenga el mismo estndar para la organizacin. Algunos puntos a definirse en estos estndares son: Identificacin de Documentos, Estructura de Documentos, Presentacin de Documentos, Actualizacin de Documentos, etc. Estndares para el Intercambio de Documentos: Asegura que todas las copias electrnicas del documento sean compatibles. La importancia de estos estndares radica en el control que se debe llevar para que las versiones y copias de los documentos sean compatibles y fieles al proyecto. Estos estndares definen herramientas, tipos de letra e incluso estilos del texto para los documentos.Reglas para la DocumentacinAhora veamos algunas reglas bsicas y recomendaciones de acuerdo al ciclo de vida de desarrollo de software.Gestin del ProyectoLa gestin del proyecto es una parte esencial de la ingeniera de software. Una buena gestin no garantiza el xito del proyecto, sin embargo una mala gestin usualmente asegura el fracaso del mismo.Los gestores son responsables de la planificacin y temporalizacin del desarrollo del desarrollo del proyecto, es decir, supervisar y asegurar que se lleve a cabo conforme a los estndares y necesidades requeridas (tiempo y presupuesto).Las actividades de gestin incluyen: Redaccin de la propuesta Planificacin y calendarizacin del proyecto Estimacin del costo del proyecto Supervisin y revisin del proyecto Seleccin y evaluacin del personal Redaccin y presentacin de informesPara hacer tangible estas labores, los gestores deben describir algunos documentos estndares a todo proyecto: Plan del Proyecto: Describe la estrategia a travs de la cual se desarrollar el proyecto. Mnimamente, este documento debe contener una introduccin, la organizacin de proyecto, el anlisis de riesgo (del proyecto, producto y negocio), los requerimientos de recursos (HW y SW), la divisin del trabajo, el programa del proyecto (red de actividades o carta Gantt) y los mecanismos de supervisin e informe. Plan de Calidad: Describe procedimientos y estndares de calidad que se utilizarn en el proyecto. Plan de Validacin: Describe los enfoques, recursos y la programacin utilizados para la validacin del sistema. Plan de Gestin de Configuraciones: Describe los procedimientos de gestin de configuraciones y las estructuras a realizar. Plan de Mantenimiento: Describe los requerimientos de mantenimiento del sistema, los costes del mantenimiento y el esfuerzo predecido. Plan de Desarrollo Personal: Describe cmo se desarrollan las habilidades y experiencia de los miembros del equipo de proyecto.Especificacin de RequerimientosLa ingeniera de requerimientos es el proceso a travs del cual se capturan las necesidades del usuario y se convierten en requerimientos formales, a travs de una especificacin. Este proceso tiene 4 grandes pasos: Estudio de viabilidad, a travs del cual se evala si el sistema es til para el negocio. Obtencin y anlisis, a travs del cual se descubren las necesidades. Especificacin, a travs del cual se transforman las necesidades en un requerimiento formal. Validacin, a travs del cual se verifican que los requerimientos definen realmente el sistema que quiere el cliente.Para este proceso, es importante definir un documento ad-hoc que permita desarrollar la especificacin formal de los requerimientos obtenidos y que se puedan validar finalmente. A este documento generalmente se le llama Especificacin de Requerimientos del Software. Esta especificacin contiene normalmente los siguientes captulos: Introduccin: en donde se describe el propsito del documento, alcance del producto, definiciones bsicas (acrnimos y abreviaturas) y referencias. Descripcin General: en donde se detalla la perspectiva y funciones del producto, caractersticas del usuario, restricciones generales, suposiciones y dependencias. Requerimientos Especficos: en donde se describen los requerimientos funcionales, no funcionales y de interfaz, en detalle. Dependiendo del detalle, se utilizan distintas tcnicas de especificacin como diagramas, lenguajes estructurados o incluso algebraicos y pseudocdigo. Apndices e ndice: en donde se describen las referencias internas del documento.Esta estructura de documento se utiliza como estndar para la IEEE y el Departamento de Defensa de los EEUU (IEEE/ANSI 830-1998). Otra estructura ms completa, propone captulos en donde ya se modelan algunos temas no funcionales o se proponen modelos de solucin: Prefacio, ndice, Introduccin, Glosario, Definicin de Requerimientos del Usuario, Arquitectura del Sistema, Especificacin de Requerimientos del Sistema, Modelos del Sistema, Evolucin del Sistema, Apndices. Sin embargo, sea cual sea la especificacin, lo importante es la declaracin de sta de manera formal y validable.

Diseo del SistemaEl diseo corresponde a la definicin completa de los planos del sistema. Como tal es el objetivo de esta fase, es importante que esos planos se formalicen a travs de documentos que permitan mantener una estructura ordenada de las diferentes capas o vistas del sistema.En su forma ms bsica, el diseo toma como base tres grandes reas: El diseo Arquitectnico, a travs del cual se describen aquellas definiciones de la arquitectura que se deben considerar en la implementacin del sistema. El diseo de Software, a travs del cual se definen los diferentes planos del sistema, utilizando diferentes tcnicas. El diseo de Interfaces de Usuario, a travs del cual se describen los medios con los cuales el usuario tendr contacto para su comunicacin con el sistema.La descripcin de cada uno de los diseos del sistema es un tema ampliamente abordado por las metodologas de desarrollo. De esta forma, no existe un lenguaje estndar para documentar los diseos en general, sino que existen algunos requisitos bsicos que se esperan de esta fase (por ejemplo, especificacin a travs de UML como lo indica RUP).Dependiendo del proceso de desarrollo, el Documento de Diseo de Software (SDD en ingls) puede tener diferentes estructuras, como por ejemplo: Introduccin: en donde se describe el propsito del documento, alcance del producto, definiciones bsicas (acrnimos y abreviaturas) y referencias. Arquitectura del Sistema: en donde se detalla la arquitectura actual y la arquitectura propuesta, detallando descomposicin de los subsistemas y su diseo particular. Diseo Detallado del Sistema: en donde se detalla la especificacin tcnica del diseo, incorporando el detalle ms especfico que es necesario considerar para la implementacin del sistema. Apndices e ndice: en donde se describen las referencias internas del documento.DesarrolloLa implementacin de los sistemas constituye la etapa ms dura dentro del ciclo de vida, ya que es donde se transforma el diseo en un producto final. Por esta razn, tambin se transforma en un problema cuando se trata de intervenir.La documentacin durante el desarrollo es clave para orientar y permitir el mantenimiento de los sistemas, ya que tienen como misin definir los elementos bsicos en un lenguaje comprensible por los futuros expertos que lo deben intervenir. A esto se le llama Documentacin del Cdigo o de Programas.Existen varias tcnicas de documentacin del cdigo: Documentacin del Contenido: Tiene por objetivo describir las clases o programas sin ninguna ambigedad, desde el punto de vista del objetivo que tiene dentro del sistema. En ella se describen cosas como por ejemplo: descripcin funcional, salidas del programa, datos de prueba, programador, parmetros, datos de control, etc. Comentarios en los Programas: Tienen por objetivo describir in-line, utilizando textos entre las lneas de cdigo, algunas ideas que permitan orientar para qu sirve cada parte del programa en detalle. En este tipo de documentacin tambin se estila incluir definicin ms funcional como encabezados de los programas, permitiendo entender el funcionamiento de cada una de las partes del programa de acuerdo al uso que se le va a dar.Pruebas del SoftwareLas pruebas del software corresponden al proceso de verificacin y validacin de ste: Verificacin: estamos construyendo el producto correcto? Validacin: estamos construyendo el producto correctamente?A lo largo de todo el proyecto, la verificacin y validacin es muy importante, ya que nos permitir realizar lo necesario para obtener calidad. La documentacin de cada una de esas verificaciones es clave en esta materia. De esta manera podemos definir un conjunto de documentos que nos permiten mantener control de las verificaciones: Plan de Pruebas de Aceptacin: Definen las pruebas funcionales necesarias que se deben realizar para aceptar que el sistema es veraz. Plan de Pruebas de Integracin del Sistema: Definen un primer nivel de pruebas tcnicas necesarias que se deben realizar para acepar que el sistema es vlido. Plan de Pruebas de Integracin de Subsistemas: Definen un segundo nivel de detalle de pruebas tcnicas necesarias que se deben realizar para acepar que el sistema es vlido.Todos estos planes es recomendable plasmar su resultado en documentos ad-hoc de pruebas con sus resultados, de modo que se mantenga control de las incidencias y cmo se van corrigiendo los problemas detectados a lo largo del proyecto.Otros mbitosDentro del ciclo de vida del software, tambin existen otros mbitos donde es importante documentar con estndares el trabajo. A continuacin una mirada a algunos: Gestin del Personal: Utilizando formalizaciones para la mejora del proceso de la gestin de los recursos humanos. Costos del Proyecto: Utilizando tcnicas de estimaciones de costos, formalizar la necesidad de recursos de ste (en trminos de tiempo y dinero). Gestin de Calidad: Utilizando tcnicas de calidad de software, se deben formalizar las estimaciones y cmo estas impactan en el producto. Gestin de Configuraciones: Utilizando distintas herramientas que permiten registrar y gestionar el cdigo para la evolucin del software.Gran parte de esta informacin ser revisada a lo largo del curso, pero enunciar su importancia no est de ms, ya que permite dimensionar la necesidad de la documentacin en las distintas etapas del ciclo de vida.ReflexionesAhora veamos algunas preguntas clave respecto a esta unidad. Qu es la Ingeniera de Software?Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento de un software. Esta definicin tiene 2 partes claves: una tiene que ver con el proceso sistemtico y disciplinado, una clave muy importante, adems de ser cuantificable, es decir, que puede ser medido; y por otro lado tambin est la clave de que este enfoque va apuntado tanto al desarrollo como a la operacin y mantenimiento del software, es decir, a su ciclo de vida. Cules son los pilares fundamentales o capas de la Ingeniera de Software?Son 3 capas: Proceso, que define un marco de trabajo a travs del cual permite establecer una entrega efectiva de la tecnologa. Mtodos, que definen las especificaciones de cmo construir tcnicamente el software desde un enfoque funcional hasta un enfoque de calidad. Herramientas, que proporcionan un nivel de automatizacin para el proceso y los mtodos utilizados en el desarrollo del software. Cules son los principales productos de la Ingeniera de Software?El producto principal es el software y adems de una serie de artefactos que lo sustentan como documentos, cdigo fuente, contratos, aprobaciones, etc. Cul es la principal caracterstica que diferencia el software del hardware?El software se diferencia del hardware en que el producto de la ingeniera de software no es un producto fsico, y si se estropea se convierte en un problema de diseo (y no de reemplazo de la pieza estropeada). Qu es el ciclo de vida del software?Es un conjunto de etapas o fases por las que pasa el software desde que nace la necesidad hasta que se hace inservible. Cules son las fases del ciclo de vida del software?Las fases en las que se puede dividir el ciclo de vida del software son: Definicin: es la fase en la que se convierte la necesidad en su formalizacin. Desarrollo: es la fase en donde se implementa lo formalizado en la etapa de definicin, y esto va en todas las dimensiones (diseo lgico, diseo fsico, construccin, etc). Mantenimiento: es la fase en la que el software requiere adaptarse a su entorno para lograr sobrevivir a los cambios. Cul es la clasificacin de los softwares de aplicacin?Los softwares se pueden clasificar de acuerdo a su aplicacin: Software de Sistemas: centrado en el apoyo de otros softwares. Software de Tiempo Real: centrado en el control de sucesos del mundo real. Software de Gestin: centrado en el apoyo a las reas comerciales. Software de Ingeniera y Cientfico: centrado en el manejo numrico. Software Empotrado: centrado en el control de productos y sistemas industriales. Software de Computadoras Personales: centrado en apoyar al usuario personal. Software de Inteligencia Artificial: centrado en resolver problemas complejos a travs de aprendizaje y redes neuronales. De qu depende la seleccin de un modelo de desarrollo de software?La seleccin de un modelo tiene que ver con la naturaleza del proyecto, herramientas y los entregables comprometidos en l. Cules son las etapas del modelo en cascada o lineal secuencial?Las etapas del modelo en cascada son: Ingeniera y Modelado de Sistema/Informacin: abarca el anlisis de requisitos de sistema (hardware-software) y los estratgicos y de negocio del cliente. Anlisis de Requisitos: abarca el anlisis de los requisitos funcionales y no funcionales que afectan al diseo y desarrollo del software directamente. Diseo: abarca el proceso de llevar los requisitos a una representacin del software donde se pueda evaluar su calidad antes de la construccin. Generacin de Cdigo: abarca el proceso de construccin fsica del software. Pruebas: abarca el proceso de deteccin de errores, tanto desde el nivel interno y lgico funcional como los procesos lgicos externos. Mantenimiento: abarca el proceso de evolucin del software de acuerdo a los cambios en el entorno de ste. En qu se diferencia la etapa de mantenimiento de las otras en el modelo en cascada?El mantenimiento no es ms que una serie de procesos en cascada que se realizan de acuerdo a los cambios del software posterior al despliegue de ste. Cules son las etapas que caracterizan el modelo de construccin de prototipos?Las etapas del modelo de construccin de prototipos son: Comunicacin con Cliente: en donde se conversa y se capturan los objetivos centrales del software. Diseo y Construccin del Prototipo: en donde se construye el prototipo de acuerdo a lo capturado con el cliente. Evaluacin del Cliente: en donde se pone a prueba la satisfaccin del prototipo de acuerdo a lo esgrimido por el cliente. Dnde debe terminar el ciclo de construccin de prototipo?El ciclo de construccin de prototipo debe terminar cuando la evaluacin del cliente es de acuerdo a lo esperado, es decir, se ha entendido el objetivo del cliente. Qu hay que hacer despus con el prototipo, luego que es validado por el cliente?La teora nos dice que debe ser descartado para comenzar con el diseo desde cero. Por lo tanto, para mantener esta lgica, el proyecto debe ser planificado considerando desde el principio que el prototipo es desechable. Cul es la filosofa del proceso iterativo incremental?En esencia, el proceso iterativo incremental define un software a partir de iteraciones desarrolladas en base a algunos requerimientos o fracciones del software utilizando cascadas, pero en menor tiempo que un proceso lineal-secuencial. Cul es la diferencia entre el modelo en espiral y el iterativo incremental?Los modelos incrementales y en espiral son ambos evolutivos. La diferencia radica en las fases de desarrollo que definen. En el primero, el software va evolucionando con el tiempo en cada vuelta, desde etapas muy precarias, en donde el resultado puede ser un boceto o cualquier producto que represente el software muy bsicamente (como un prototipo no funcional), y el segundo se basa en requerimientos particulares o mdulos que se pueden ir desarrollando con cascadas iterativas. Cmo encaja el mantenimiento en un modelo evolutivo como espiral o incremental?En ambos casos, el mantenimiento funciona igual como se define en el proceso lineal-secuencial: como nuevas aplicaciones del mismo modelo. En el caso de los modelos evolutivos, se aplica la filosofa de nuevas iteraciones del mismo modelo en las diferentes evoluciones del software, lo que lo hace mucho ms continuo que el modelo lineal-secuencial. Cul es la esencia de la metodologa de desarrollo rpido de aplicaciones (RAD)?El RAD se basa en definir etapas cortas (60 a 90 das) de acuerdo a requerimientos altamente comprendidos y lmites bien definidos. En qu se diferencia metodologa espiral win-win de la espiral tradicional?A pesar de que ambas metodologas utilizan la misma filosofa (desarrollo evolutivo en espiral), se diferencian en la definicin de las condiciones de cada una de las actividades. En la primera, el espritu est en cumplir y negociar las expectativas en torno a las actividades, en cambio en la segunda, se definen a travs de etapas formales con objetivos tradicionales. Para qu sirve el modelo de desarrollo concurrente?Se aplica el enfoque de desarrollo concurrente cuando es necesario paralelizar las actividades, es decir, permitir que actividades del proceso se puedan hacer con cierto nivel de concurrencia. Cul es la esencia del modelo de desarrollo basado con componentes?El modelo de desarrollo basado en componentes es un proceso evolutivo y se basa en la reutilizacin de componentes desarrollados a travs del proyecto utilizando una biblioteca al momento de analizar y disear los requerimientos en cada iteracin. Cundo es til utilizar un enfoque de mtodos formales?Cuando el proyecto es en torno a desarrollos que requieren obtener productos con baja tasa de errores. De qu tipo de metodologa es el MSF?El Microsoft Solutions Framework es un enfoque evolutivo de desarrollo que utiliza tcnicas de cascada para la definicin de las actividades. Qu es la calidad del software?

La calidad es una forma de medir que tan ad-hoc es el software de acuerdo a los requerimientos y a las necesidades naturales de ste. Permite certificar tanto el producto como el proceso de desarrollo de ste.

Para qu se certifican los procesos de desarrollo de software?

Para mantener los procesos de desarrollo uniformes, es decir, que cumplan con los requisitos bsicos para obtener software de calidad (gestin, planificacin, documentacin, etc).

Qu es CMMI?

El Capability Maturity Model Integration es un modelo que permite certificar diferentes procesos (produccin, adquisicin y de servicios) para que sean eficaces.

Cules son los tipos de CMMI que existen?

Existen 3 tipos:

CMMI-DEV: que es para certificar procesos de desarrollo de productos. CMMI-ACQ: que es para certificar la cadena de suministros (SCM). CMMI-SVC: que es para certificar la entrega de servicios.

Cules son los niveles de madurez en los que se evala CMMI?

Los niveles de madurez son 6:

Nivel 0: Incompleto Nivel 1: Ejecutado Nivel 2: Gestionado Nivel 3: Definido Nivel 4: Cuantitativamente Gestionado Nivel 5: Optimizado

Qu es SCAMPI?

Es un modelo para evaluar los procesos segn CMMI, para determinar que tan bien los procesos se comparan con las mejores prcticas CMMI, informar a los clientes y cumplir con los requerimientos contractuales.

Cules son los beneficios de las normas ISO 9000?

Los beneficios de las normas ISO 9000 son:

Mejorar la satisfaccin del cliente. Mejorar continuamente los procesos. Reducir los rechazos e incidencias en la produccin. Aumentar la productividad.

A qu mbito se aplica la norma ISO 9001:2000?

Se aplican a cualquier mbito organizacional ya que puede certificar procesos internos administrativos (normas, definiciones, sistemas de gestin) y tambin en procesos productivos (direccin, recursos, realizacin y medicin).

Qu captulos debe cumplir una empresa de desarrollo de software para certificar su proceso de desarrollo segn la norma ISO 9001:2000?

Adems de cumplir con los captulos bsicos organizaciones, debe cumplir con los captulos especficos para el desarrollo que son:

Responsabilidad de direccin. Gestin de recursos. Realizacin del producto. Medicin, anlisis y mejora.

Qu es la norma ISO/IEC 15504 (SPICE)?

Es un modelo de evaluacin de procesos de desarrollo y mantenimiento de procesos productivos de sistemas y productos de software.

Cules son las caractersticas del modelo SPICE?

Las caractersticas del modelo SPICE contienen:

Establece un marco para mtodos de evaluacin. Comprende la evaluacin, mejoramiento y determinacin de capacidades de los procesos. Est alineado con el estndar que define los procesos del ciclo de vida del desarrollo, operacin y mantenimiento del software. Es equivalente y tiene compatibilidad con CMMI.

Cules son las dos dimensiones en que se separa el modelo SPICE?

Se separa en:

Dimensin de Proceso: que agrupa los procesos de acuerdo a su naturaleza (Cliente-Proveedor, Ingeniera, Soporte, Gestin y Organizacin). Dimensin de Capacidad: que define el nivel de madurez de cada uno de los procesos (de 0 5, al igual que CMMI).

En qu se diferencian los procesos y de las capacidades de SPICE?

Los procesos definen cules son los mbitos de evaluacin de SPICE y las capacidades el nivel de madurez de los procesos.

Cules son los niveles de madurez del modelo SPICE?

Los 6 niveles de madurez de SPICE son:

Nivel 0: Incompleto Nivel 1: Realizado (equivalente a Ejecutado de CMMI) Nivel 2: Gestionado Nivel 3: Establecido (equivalente a Definido de CMMI) Nivel 4: Predecible (equivalente a Cuantitativ. Gestionado de CMMI) Nivel 5: En Optimizacin (equivalente a Optimizado de CMMI)

Qu es la estandarizacin?

La estandarizacin es un conjunto de reglas que permiten la fabricacin de artefactos orientados a la interoperatividad.

Cules son los tipos de estndares de documento que existen?

Existen 3 tipos de estndares de documento: los de Proceso de Documentos, los de Documentos en s y los de Intercambio de Documentos.

En qu fases del ciclo de vida de software se necesita la creacin de un estndar de documentacin?

En todas las etapas del ciclo de vida es importante la creacin de un estndar, ya que cada fase genera algn producto que es parte la memoria del proyecto, la cual debe ser registrada.

Nombre algunos ejemplos de documentos estndares en el ciclo de vida de desarrollo de software.

Especificacin de requerimientos Documento de diseo Plan de pruebas Carta Gantt Especificacin de Programas

Unidad II. la Ingeniera de RequisitosEl objetivo de esta unidad es revisar las tcnicas de identificacin, clasificacin, negociacin, especificacin, modelado, validacin y gestin de los requisitos en un proyecto de software.

Necesidades o Requisitos/Requerimientos?Existe una amplia discusin lingstica respecto a los trminos requerimiento y necesidad, ya que tienen interpretaciones muy similares, an cuando su enfoque puede ser totalmente diferente ya que uno existe como una consecuencia de otro.Cuando hablamos de una necesidad queremos decir que existe una carencia o la exigencia de algo (producto, servicio, funcin, etc). Por ejemplo, cuando se le pide a un artista pintar un cuadro, esto nace de una necesidad (porque yo quiero tener un cuadro en mi sala) pero no es un requerimiento, porque es algo que yo (como cliente) deseo tener, es una carencia o algo que mi entorno exige (una pared vaca, por ejemplo). De esta manera, el artista podra pintar lo que a l le plazca, an cuando no sea lo que nosotros esperamos.Sin embargo, cuando hablamos de un requerimiento, lo que queremos decir al artista es algo ms preciso: yo deseo un cuadro de 50 centmetros de alto y 80 centmetros de ancho, en donde est representada una casa de campo en un ambiente otoal, en donde se vean los animales de la granja y un da claro, esto se asemeja ms a un requerimiento, ya que estamos dando la informacin necesaria para que nuestro interlocutor pueda realizar la labor o resuelva nuestra necesidad (el tener un cuadro en mi sala).Si esto lo llevamos a un mundo ms industrial, de una manera formal podemos decir que: Un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio.Los requerimientos para un sistema son la descripcin de los servicios que ste debe proporcionar y sus restricciones operativas. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniera de requerimientos.El trmino requerimiento no se utiliza de forma constante en la industria del software. En algunos casos, un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. En el otro extremo, es una definicin detallada y formal de una funcin del sistema. Si una compaa desea establecer un contrato para un proyecto de desarrollo de software grande, debe definir sus necesidades de una forma suficientemente abstracta para establecer a partir de ella una solucin. Los requerimientos deben redactarse de tal forma que varios contratistas puedan licitar el contrato, ofreciendo, quizs, formas diferentes de cumplir las necesidades de los clientes en la organizacin. Una vez que el contrato se asigna, el contratista debe redactar una definicin del sistema para el cliente ms detalladamente, de forma que este comprenda y pueda validar lo que el software har. Ambos documentos se pueden denominar documento de requerimientos.Algunos de los problemas que surgen durante el proceso de ingeniera de requerimientos son resultado de no hacer una clara separacin entre estos diferentes niveles de descripcin. Caractersticas de los RequerimientosLos requerimientos para que sean tratados como tal, deben poseer algunas caractersticas bsicas. Estas caractersticas son: Necesario: Lo que pida un requerimiento debe ser necesario para el producto. Sin ambigedad: El texto debe ser claro, preciso y tener una nica interpretacin posible. Conciso: Debe redactarse en un lenguaje comprensible para los usuarios en lugar de uno de tipo tcnico y especializado, aunque an as debe referenciar los aspectos importantes. Consistente: Ningn requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos tambin debe ser consistente. Completo: Los requerimientos deben contener en s mismos toda la informacin necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle. Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles. Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis, demostracin o testeo.De esta manera, cuando existe una necesidad que se pueda documentar como requerimiento, es importante que esta documentacin cumpla con las caractersticas antes mencionadas.Tipos de RequerimientosEn la disciplina de ingeniera de software, los requerimientos se distinguen utilizando la denominacin de requerimientos del usuario para designar los requerimientos abstractos de alto nivel y de requerimientos del sistema para designar la descripcin detallada de lo que el sistema debe hacer. Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporciones y de las restricciones bajo las cuales debe funcionar. Los requerimientos del sistema establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificacin funcional) debe ser preciso. Debe definir exactamente qu es lo que se va a implementar. Puede ser parte del contrato entre el comprador del sistema y los desarrolladores del software.Por otro lado, a menudo los requerimientos de sistemas de software se clasifican en funcionales y no funciones, o como requerimientos del dominio: Requerimientos funcionales: son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que ste debe reaccionar a entradas particulares y de cmo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin pueden declarar explcitamente lo que el sistema no debe hacer. Requerimientos no funcionales: son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estndares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a caractersticas o servicios individuales del sistema. Requerimientos del dominio: son requerimientos que provienen del dominio de aplicacin del sistema y que reflejan las caractersticas y restricciones de ese dominio. Pueden ser funcionales o no funcionales.En realidad, la distincin entre diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones. Por ejemplo, un requerimiento del usuario sobre seguridad podra parecer un requerimiento no funcional. Sin embargo, cuando se desarrolla en detalle, puede generar otros requerimientos que son claramente funcionales, como la necesidad de incluir en el sistema recursos para la autentificacin del usuario.Una posible taxonoma dentro de la clase de requerimientos no funcionales se puede ver en el siguiente rbol:

Ilustracin 5. Taxonoma de Clasificacin de los RequerimientosEsta no es la nica clasificacin posible, ya que depende de otros factores, pero es una buena propuesta.Ingeniera de RequerimientosEl desafo de la ingeniera del sistema (y de los ingenieros del software) es importante: Cmo podemos asegurar que hemos especificado un sistema que recoge las necesidades del cliente y satisface sus expectativas? No hay una respuesta segura a esta difcil pregunta, pero un slido proceso de ingeniera de requisitos es la mejor solucin de que disponemos actualmente.La ingeniera de requisitos o de requerimientos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solucin razonable, especificando la solucin sin ambigedad, validando la especificacin y gestionando los requisitos para que se transformen en un sistema operacional. El proceso de ingeniera de requisitos puede ser descrito en 6 pasos distintos. Identificacin de Requisitos: Tcnica para preguntar al cliente, a los usuarios y a los que estn involucrados en los objetivos del sistema o producto y sean expertos, investigar cmo los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cmo el sistema o producto va a ser utilizado en el da a da. Anlisis y Negociacin de Requisitos: Los requisitos se agrupan por categoras y se organizan en subconjuntos, se estudia cada requisito en relacin con el resto, se examinan los requisitos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes/usuarios. Especificacin de Requisitos: La especificacin es un documento formal con los requisitos ya analizados y negociados. Puede ser un documento escrito, un modelo grfico, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o una combinacin de lo anteriormente citado. Modelado del Sistema: Evaluar los componentes del sistema y sus relaciones entre s; determinar cmo estn reflejados los requisitos, y valorar como se ha concebido la esttica en el sistema. Validacin de Requisitos: Examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estndares establecidos para el proceso, el proyecto y el producto. Gestin de Requisitos: Un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.StakeholdersLa obtencin y anlisis de requerimientos pueden afectar a varias personas de la organizacin. El trmino stakeholder se utiliza para referirse a cualquier persona o grupo que se ver afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuentran los usuarios finales que interactan con el sistema y todos aqullos en la organizacin que se pueden ver afectados por su instalacin. Otros stakeholders del sistema pueden ser los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes del negocio, los expertos en el dominio del sistema y los representantes de los trabajadores.Obtener y comprender los requerimientos de los stakeholders es difcil por varias razones: Los stakeholders a menudo no conocen lo que desean obtener del sistema informtico, excepto en trminos muy generales. Puede resultarles difcil expresar lo que quieren que haga el sistema, o pueden hacer demandas irreales, debido a que no conocen el costo de sus peticiones. Los stakeholders expresan los requerimientos con sus propios trminos de forma natural y con un conocimiento implcito de su propio trabajo. Los ingenieros de requerimientos, sin experiencia en el dominio del cliente, deben comprender estos requerimientos. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar de varias formas. Los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos. Los factores polticos pueden influir en los requerimientos del sistema. Por ejemplo, los directivos pueden solicitar requerimientos especficos del sistema que incrementarn su influencia en la organizacin. El entorno econmico y de negocios en el que se lleva a cabo el anlisis es dinmico. Inevitablemente, cambia durante el proceso de anlisis. Por lo tanto, la importancia de ciertos requerimientos puede cambiar. Pueden emerger nuevos requerimientos de nuevos stakeholders que no haban sido consultados previamente.El Proceso Iterativo de la Obtencin de RequerimientosSe puede pensar que las actividades para la obtencin de requerimientos (captura y formalizacin) van dentro de una espiral, de forma que las actividades se entrelazan a medida que el proceso avanza desde el anillo interior a los exteriores de la espiral.Las actividades del proceso son: Descubrimiento de requerimientos: es el proceso de interactuar con los stakeholders del sistema para recopilar sus requerimientos. Los requerimientos del dominio de los stakeholders y la documentacin tambin se descubren durante esta actividad. Clasificacin y organizacin de requerimientos: esta actividad toma la recopilacin no estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en grupos coherentes. Ordenacin por prioridades y negociacin de requerimientos: inevitablemente, cuando existen muchos stakeholders involucrados, los requerimientos entrarn en conflicto. Esta actividad se refiere a ordenar segn las prioridades los requerimientos y a encontrar y resolver los requerimientos en conflicto a travs de la negociacin. Documentacin de requerimientos: se documentan los requerimientos y se entra en la siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos formales o informales.