Professional Documents
Culture Documents
Relacin con otras asignaturas del plan de estudio Anteriores Asignaturas Posteriores Asignaturas Desarrollo de proyectos de software
Temas
Temas
Aportacin de la asignatura al perfil del egresado Selecciona entre tcnicas, modelos, mtodos y herramientas para realizar la planeacin y anlisis de un sistema de manera ptima.
OBJETIVO(S) GENERAL(ES) DEL CURSO El estudiante planificar, analizar y disear un proyecto software o sistema de informacin conforme a los requerimientos establecidos al inicio del mismo y aplicando tcnicas modernas y de acorde a las caractersticas intrnsecas del mismo.
Planificacin y Modelado
UNIDAD UNO
T E M A R I O
Temas 1. Procesos de la ingeniera de requerimientos. 1.1 Requerimientos de proceso. 1.2 Requerimientos de los usuarios (actores involucrados). 1.3 Requerimientos para el anlisis y negociacin. 1.4 Requerimientos para la gestin.
Unidades
2.1 Planificacin del tiempo. 2.2 Evaluacin del costo beneficio. 2.3 Estudio de viabilidad. 2.4 Planificacin de la documentacin. 2.5 Gestin de la configuracin del software. 3.1 Anlisis de riesgos. 3.2 Control de calidad. 4.1 Requerimientos funcionales y no funcionales. 4.2 Casos de uso. 4.3 Diseo de interfaz de usuario. 4.3.1 Reglas en el diseo de interfaz de usuario. 4.3.2 Integracin de la interfaz al caso de uso.
Planificacin y Modelado
UNIDAD UNO
UNIDAD
OBJETIVO EDUCACIONAL: El estudiante conocer y discriminar los tipos de requerimientos para un proyecto de software.
Mas del 30% de todos los proyectos de software son cancelados antes de su finalizacin. Mas del 70% de los proyectos restantes fallan al entregar y evaluar las caractersticas esperadas. Por qu los Proyectos de Software son exitosos?
Involucra a Usuarios Soporte Administracin Clara definicin de Requerimientos Apropiado Planeamiento Expectativas Realistas Hitos no Extensos Staff Competente de profesionales Propietario 15.9% 13.9% 13.0% 9.6% 8.2% 7.7% 7.2% 5.3%
Un requerimiento de software puede ser definido como: Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. Una capacidad del software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal.
Hito: Punto final de un proceso de software El final de una etapa y el comienzo de otra, dentro de un proceso. Por qu los Proyectos de Software fallan? Requerimientos Incompletos 13.1% Falta de Requerimientos 12.4% Falta de Recursos 10.6% Expectativas no Realistas 9.9% Cambio Requerimientos/Especificaciones 8.7% Falta de Planeamiento 8.1% No se especifico el tiempo adecuado 7.5%
1.1 Requerimientos de proceso. Qu es un Requerimiento? Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe conformar. Cmo identificamos los Requerimientos? Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocucin con usuarios o clientes.
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
Planificacin y Modelado
UNIDAD UNO
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 semiautomtico 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 computadora (CASE).
El fundamento de la ingeniera del software es la capa de proceso. 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.
El proceso de Ingeniera de Requerimientos es un conjunto estructurado de actividades, mediante las cules obtenemos, validamos y mantenemos el documento de especificacin de requerimientos (ERS)
Planificacin y Modelado
UNIDAD UNO
elementos del sistema, tales como grupos de datos, procesos y almacenamiento de datos. Herramientas automatizadas Prototipos: Hay de enfoque cerrado (desechable) y enfoque abierto (evolutivo)
Extracci n X X X X X X X X X X X X X X X X X X X X X X X X de X X X X X X X X X X Anli sis Especificac in Validac in
Herramienta Entrevistas y Cuestionario Sistemas existentes Grabaciones video/audio Brainstormin g Arqueologa de doctos. Aprendiz Observacin Prototipos FODA Diagrama de pescado Glosario Casos de uso Casa de Calidad QFD Checklist Diagramas FD Modelos clases
DE
Es el proceso que sirve para determinar el dominio de la aplicacin, cuales servicios debe proporcionar el sistema, as como su desempeo requerido, las restricciones de hardware, etc. Se trabaja estrechamente con los usuarios a fin de conocer la problemtica en detalle. Las actividades que cubre son: Comprensin del dominio Recoleccin de requerimientos Clasificacin de requerimientos Resolucin de conflictos Priorizacin Verificacin de requerimientos
C) HERRAMIENTAS DE EXTRACCIN Y ANLISIS Herramientas para recoleccin de datos: Capturan detalles que describen sistemas y procedimientos en uso. Documentan procesos y actividades de decisin. Herramientas para Diagramacin: Crean representaciones grficas de sistemas y actividades. Apoyan el dibujo y revisin de DFD e conos asociados con el anlisis estructurado. Herramientas para el Diccionario: Registran y mantienen descripciones de los
UNIDAD UNO
ENTREVISTAS Y CUESTIONARIOS: Se emplean para reunir informacin proveniente de personas o grupos, informacin que se obtiene conversando con el encuestado.
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
Planificacin y Modelado
La intencin en su aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema. No se debe detener a pensar si la idea es o no del todo utilizable. La intencin de este ejercicio es generar, en una primera instancia, muchas ideas. Luego se irn eliminando en base a distintos criterios como, por ejemplo, caro, impracticable, imposible, etc. APRENDIZ: Se basa en la idea del maestro y el aprendiz. El aprendiz es representado por el analista y el usuario/cliente cumple con el rol de maestro. El aprendiz se sienta con el maestro a aprender por medio de la observacin, haciendo preguntas como por qu hizo eso? y Qu significa eso?, y tambin realizando algn trabajo bajo la supervisin del maestro. La aplicacin de esta herramienta es muy til, ya que a veces es difcil para el cliente/usuario el explicar cmo realiza su trabajo. OBSERVACIN: Es sumamente difcil describir cmo hacer el nudo de un calzado deportivo, pero es sumamente fcil mostrar los pasos para hacerlo. Observar cmo se hacen las cosas es una buena manera de entender lo que estas requieren. Dentro de la estrategia de observar, se tienen que buscar estructuras y patrones. La estructura del trabajo para los usuarios suele ser invisible, por lo que ser nuestro trabajo realizar las abstracciones necesarias. ESPECIFICACIN Y DOCUMENTACIN DE LOS REQUERIMIENTOS Esta actividad se enfoca al proceso de documentacin del comportamiento deseado del sistema. La especificacin de requerimientos es un acuerdo aprobado entre
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
5. Por ltimo, se discute el ambiente en el cul operar el sistema. Se incluyen requerimientos para el soporte, la seguridad y la privacidad. DOCUMENTO: ESPECIFICACIN REQUERIMIENTOS DE
Se escribe desde la perspectiva del desarrollador. Reitera la definicin de los trminos tcnicos apropiados para el desarrollo del diseo de un sistema; es la contrapartida tcnica al documento de definicin de requerimientos, y es escrito por analistas de requerimientos. Por ejemplo, el cliente no puede comprender la definicin de un requerimiento en trminos de una relacin matemtica compleja definida con una serie de ecuaciones. D) VALIDACIN REQUERIMIENTOS DE LOS
Los requerimientos deben de ser: Especificados por escrito Posibles de probar o verificar Descritos como una caracterstica del sistema a entregar. Lo ms abstracto y conciso posible DEFINICIN DE
DOCUMENTO: REQUERIMIENTOS
Est escrita en trminos que el cliente puede entender. Es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Es escrito en forma conjunta por el cliente y el desarrollador. 1. Primero se perfila el propsito general del sistema. 2. Se describen los antecedentes y los objetivos del desarrollo del sistema. 3. Si el cliente tiene un nuevo enfoque propuesto para resolver el problema, se perfila una descripcin del enfoque. 4. Una vez registrada esta vista global del problema, se describen en detalle las caractersticas del sistema propuesto. Se definen el lmite del sistema y las interfaces que lo vinculan con el entorno.
Esta actividad tiene mucho en comn con el anlisis, ya que implica encontrar problemas con los requerimientos. Sin embargo, son procesos distintos puesto que la validacin comprende un bosquejo completo del documento de requerimientos, mientras que el anlisis implica trabajar con los requerimientos incompletos. Durante esta actividad se deben llevar a cabo diferentes tipos de verificacin en el documento de requerimientos que incluyen verificaciones de: Validez Consistencia Integridad Realismo Verificabilidad
Los requerimientos del proceso son a nivel organizacional, describen el cmo, es decir, describen los procedimientos y polticas que las organizaciones deben seguir as como las restricciones que deben obedecer, por
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
Planificacin y Modelado
UNIDAD UNO
Requerimientos del usuario: Son declaraciones, en lenguaje natural y en diagramas, de los servicios que el sistema provea y de las restricciones bajo las cuales debe operar. Requerimientos del sistema: establecen con detalle todos los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificacin funcional, debe ser preciso. Este sirve como un contrato entre el comprador del sistema y el desarrollador de software.
Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema Boehm 1979. Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones. 1.2 Requerimientos de los usuarios (actores involucrados). Algunos de los problemas que surgen durante el proceso de la ingeniera de requerimientos son el resultado de no hacer una clara separacin entre los diferentes niveles de descripcin. Esto se hace utilizando el trmino requerimientos del usuario, para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema, para designar la descripcin detallada de lo que el sistema debe hacer. Definicin:
Planificacin y Modelado UNIDAD UNO
Los requerimientos del usuario se redactan para el cliente y los contratistas administradores quienes no tienen un conocimiento tcnico detallado del sistema. La especificacin de requerimientos del sistema se orienta al personal tcnico y a los administradores del proyecto. Tambin lo utilizaran tanto el equipo del cliente como el del contratista. Los usuarios finales del sistema pueden leer ambos documentos.
Ejemplo: Definicin de requerimientos del usuario 1. El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas.
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
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 caractersticas o servicios individuales del sistema. 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. Cuando los requerimientos del usuario incluyen demasiada informacin, restringen la libertad del desarrollador del sistema a proveer soluciones innovadoras a los problemas del usuario y hace que los requerimientos sean difciles de comprender. La base asociada a los requerimientos es importante. Ayuda a los desarrolladores y mantenedores del sistema a entender por qu el requerimiento se incluye y a valorar el impacto de los cambios en ste. Para minimizar las malas interpretaciones al redactar los requerimientos del usuario, se recomienda seguir unas pautas sencillas para redactar requerimientos: 1. Inventar un formato estndar y asegurar que todos los requerimientos se adhieren al formato. P.e: poner en negrita el requerimiento inicial 2. Utilizar el lenguaje de forma consistente. Distinguir entre los requerimientos obligatorios(definirlos en futuro simple) y deseables (definirlos en futuro condicional). P.e.:
Los verificadores, que desarrollan los datos de prueba y sesiones de prueba para asegurar que el sistema satisface cada uno de los requerimientos.
10
REQUERIMIENTOS DEL SISTEMA: Estos son descripciones ms detalladas de los requerimientos de los usuarios. Sirven como base para definir el contrato de la especificacin del sistema y, por lo tanto, debe ser una especificacin completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseo del sistema. En principio los requerimientos del sistema debern establecer lo que ste har y no la manera en que se implementar. Sin embargo en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la informacin de diseo. A menudo se utiliza el lenguaje para redactar la especificacin de requerimientos del sistema, pero pueden surgir problemas, se recomienda usar los siguientes enfoques: Especificaciones en lenguaje estructurado La ventaja de este enfoque es que mantiene mucha de la expresividad y comprensin del lenguaje natural y asegura que cierto grado de uniformidad se imponga a la especificacin. Las notaciones del lenguaje estructurado delimitan la terminologa utilizada y emplean plantillas para especificar los requerimientos del sistema. Incorporan construcciones de control derivadas de los lenguajes de programacin y manifestaciones grficas para dividir la especificacin. Especificaciones de requerimientos usando un PDL Para contrarrestar las ambigedades inherentes en la especificacin en lenguaje
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
3. Resaltar el texto (con negritas e itlica) para ver las partes claves del requerimiento 4. Evitar, hasta donde sea posible, utilizar el lenguaje tcnico de computacin. Los participantes tambin son llamados stakeholders, este trmino se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requerimientos del sistema. Entre los stakeholders se encuentran los usuarios finales que interactan con el sistema y todos aquellos en la organizacin que se vern afectados por dicho sistema [SOM02]. Entre los stakeholders en el proceso de requerimientos pueden incluirse los siguientes [PLF02]: Los supervisores del contrato (gestores de negocios), quienes sugieren hitos de control y cronogramas que restringen el desarrollo del sistema. Los clientes y usuarios, quienes deben comprender los requerimientos de modo que puedan estar seguros de que el sistema satisface sus necesidades. Los gerentes de negocio, que pueden comprender las probables consecuencias de construir y utilizar el sistema. Ingenieros que utilizan los requerimientos como base para el desarrollo de una solucin aceptable que se implementar como un sistema basado en software; ingenieros de mantenimiento.
UNIDAD UNO
Planificacin y Modelado
considerar aquellos que cumplan con las caractersticas deseables de un requerimiento mencionadas en el prrafo anterior, en otras palabras, se pretende descartar aquellos requerimientos ambiguos, incompletos e inconsistentes. El planteamiento de las siguientes preguntas ayuda a identificar a buenos requerimientos: Cada requerimiento es consistente con los objetivos generales del sistema o producto? Tienen todos los requerimientos especificados el nivel adecuado de abstraccin?, es decir, algunos requerimientos tienen un nivel de detalle tcnico inapropiado en esta etapa? Cada requerimiento esta delimitado y sin ambigedad? Cada requerimiento tiene procedencia, es decir, existe un origen general o especfico conocido para cada requerimiento? Existen requerimientos incompatibles con otros requerimientos? Es posible lograr cada requerimiento en el entorno tcnico donde se integrar el sistema o producto? Se puede probar el requerimiento una vez implementado? Una vez identificados los requerimientos completos, consistentes y no ambiguos, se procede a clasificarlo. El analista debe hacerse la siguiente pregunta con cada uno de los requerimientos: El requerimiento es necesario o representa una caracterstica aadida que puede no ser esencial cuando se haya finalizado el sistema? La razn de esta pregunta se debe a que es comn en clientes y usuarios solicitar ms de lo que puede realizarse, consumiendo recursos de negocios limitados, cmo sera el sobrepasar el presupuesto y el tiempo requerido para el desarrollo del sistema. Los clientes o usuarios creen necesitar ciertos requerimientos que no son primordiales para el buen desempeo del
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
11
Anlisis y negociacin de requisitos Anlisis basado en checklists, lista de preguntas que se puede usar para cada requisito Mediante matrices, se pueden representar las relaciones entre requisitos: conflicto, solapamiento e independencia La negociacin guiada entre agentes (stakeholders) es el proceso para resolver conflictos y contradicciones Hay que tener presentes los diferentes puntos de vista
Una vez recopilados los requerimientos el producto obtenido configura la base del anlisis de requerimientos. De manera general en la actividad del anlisis y negociacin los requerimientos se agrupan por categoras y se organizan en subconjuntos, se estudia cada requerimiento en relacin con el resto, se examinan los requerimientos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes y/o usuarios y del negocio, y considerando tambin costo tiempo y esfuerzo que se llevar en realizar cada uno de los requerimientos. A continuacin se describen las actividades correspondientes al anlisis y negociacin de requerimientos [PRES02]. Durante la requerimientos, se
Planificacin y Modelado
UNIDAD UNO
El anlisis de requerimientos por categoras es til para que todos los participantes comprendan lo que realmente se necesita. Tambin es til cuando el proyecto est restringido en tiempo o recursos, por lo tanto, si el sistema tal como se encuentra definido costar demasiado o tomar demasiado tiempo desarrollarlo, los requerimientos opcionales se dejan de lado y los deseables pueden analizarse para su utilizacin o eliminacin posterior [PLF02]. En la actividad de anlisis y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los usuarios. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta, entre las principales estn las listadas a continuacin: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causan los cambios de requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones. Es importante destacar que la especificacin de requerimientos de software es el resultado final de las actividades de anlisis y evaluacin de requerimientos. La especificacin de requerimientos es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma en cmo har sus funciones, definiendo los requerimientos funcionales y los no funcionales, adems de todos los
L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
12
comienza al mismo tiempo que la obtencin inicial de requerimientos y la administracin activa debe iniciar tan pronto est lista la primera versin del documento de requerimientos. Antes de definir las etapas de la administracin de requerimientos se discute porque los requerimientos inevitablemente cambian. Conforme se desarrolla la definicin de requerimientos, se tiene una mejor comprensin de las necesidades del usuario. Con esta retroalimentacin del usuario y el surgimiento de cambios en los negocios tanto organizacionales como tcnicos inevitablemente conducen a cambios en los requerimientos de un sistema de software. Por lo tanto los requerimientos deben evolucionar con el tiempo. Desde una perspectiva evolutiva los requerimientos se dividen en dos clases: a) Requerimientos duraderos: son aquellos relativamente estables, resultan de la actividad principal de la organizacin y estn relacionados directamente con el dominio del sistema. b) Requerimientos voltiles: son aquellos que cambiarn probablemente durante el desarrollo del sistema o despus de que ste ya se haya puesto en operacin. Adems se clasifican en los siguientes: Requerimientos mutantes: cambian debido a los cambios en el ambiente en el que opera la organizacin. Requerimientos emergentes: resultan al incrementarse la comprensin del cliente en el desarrollo del sistema. Requerimientos consecutivos: resultan de la introduccin del sistema de cmputo, la cual puede cambiar los procesos de la organizacin. Requerimientos de compatibilidad: dependen de sistemas particulares o procesos de negocios dentro de la organizacin.
Agosto 2011 Enero 2012
13
requerimientos debido a que: La comunidad de usuarios es diversa y cada uno de ellos tienen diferentes requerimientos y prioridades pudiendo crear un conflicto. Es por esto que los requerimientos finales son comnmente un trmino medio. Quien paga por el sistema es raramente quien usa el sistema, y son stos quienes imponen nuevos requerimientos debido a restricciones de presupuesto y organizacionales. El entorno tcnico y de negocios es cambiante y se ve reflejado en el sistema. Los requerimientos no funcionales se ven afectados de forma especial por los cambios tecnolgicos. La gestin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo junto con el proceso de ingeniera de requerimientos. La planeacin
Planificacin y Modelado UNIDAD UNO
cambio existe la necesidad de rastrear el impacto que conlleva dicho cambio en otros requerimientos y el diseo del sistema. A menudo implica utilizar matrices de rastreo, sobre todo cuando se administra un pequeo nmero de requerimientos, hay que decir que stas son muy pesadas y caras de mantener. Existen tres tipos de informacin de rastreo: 1. Rastreo de la fuente, que vincula a los requerimientos con los usuarios que los propusieron y la razn de stos. 2. Rastreo de los requerimientos, que vincula los requerimientos dependientes en el documento de requerimientos. Lo que permite evaluar aquellos requerimientos afectados por un cambio. 3. Rastreo del diseo, que vincula los requerimientos a los mdulos de diseo en los cuales sern implementados. Sabiendo de la posible existencia de cambios en los requerimientos a continuacin se explica brevemente las etapas de la administracin de cambios stos. Esta administracin se aplica a todos los cambios propuestos en los requerimientos. Se puede utilizar un proceso formal para la administracin de cambios, de esta manera todos los cambios se tratan de manera consistente y todos los cambios se hacen de manera controlada en el documento de requerimientos. Las etapas principales en un proceso de administracin de cambios son las siguientes (figura siguiente): 1. Anlisis del problema administracin del cambio 2. Anlisis del cambio y costeo 3. Implementacin del cambio y
14
Como los requerimientos estn relacionados unos con otros y con el diseo del sistema, al momento de proponer un
Planificacin y Modelado UNIDAD UNO L.I. Jos Hernndez Rodrguez Agosto 2011 Enero 2012
15
En la administracin de cambios el proceso inicia con un problema de requerimientos identificado, o algunas veces con una propuesta de cambio especfica. Durante la primera etapa de la administracin de cambios, el problema o la propuesta de cambio se analiza para verificar que este vlida y en seguida se elabora una propuesta de cambio ms especfica. En la segunda etapa, se valora el efecto del cambio propuesto utilizando la informacin de rastreo y el conocimiento general de los requerimientos del sistema. Se estima el costo del cambio en trminos de modificaciones al documento de requerimientos, si es necesario, tambin se estima con respecto al diseo e implementacin. Despus del anlisis y estimacin de costos se decide si llevar a no acabo el cambio. En la ltima etapa, se modifica el documento de requerimientos, y en algunos casos el diseo e implementacin del sistema. Los cambios en los documentos se realizan minimizando las referencias externas y haciendo que las secciones del documento sean tan modulares como sea posible [SOM02].
Planificacin y Modelado
UNIDAD UNO