You are on page 1of 5

Anlisis de requisitos Extraer los requisitos de un producto de software es la primera etapa para crearlo.

Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aun no est formalizada, ya se habla de la Ingeniera de Requisitos. La IEEE Std. 830-1998 normaliza la creacin de las Especificaciones de Requisitos Software (Software Requirements Specification). Diseo y arquitectura Se refiere a determinar como funcionar de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementacin tecnolgica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizar el sistema, y se

transforman las entidades definidas en el anlisis de requisitos en clases de diseo, obteniendo un modelo cercano a la programacin orientada a objetos. Programacin Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no es necesariamente la porcin ms larga. La complejidad y la duracin de esta etapa est intimamente ligada al o a los lenguajes de programacin utilizados. Pruebas Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral,para as llegar al objetivo. Se considera una buena practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un area de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un area de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara. Documentacin Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. Mantenimiento Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento. Enfoques de desarrollo de software Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

Modelo en cascada Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el diseo, implementacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo. Los principios bsicos del modelo de cascada son los siguientes:1

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases. Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases antes de comenzar la prxima fase.

Prototipado El prototipado es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar. Incremental Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro. Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental Se definen los requisitos antes de proceder con lo evolutivo, se realiza un miniCascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final.

Espiral Los principios bsicos son:

La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de la continuacin del proyecto durante todo el ciclo de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la prxima iteracin.3 Cada ciclo comienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.3

Rapid Application Development (RAD) El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo interativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. Principios bsicos:

Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin. Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y tcnicas orientada a objetos. Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica. La participacin activa de los usuarios es imprescindible.

Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

You might also like