Planificación y Modelado

Instituto Tecnológico de Pachuca Autopista México Pachuca: Km 87.5, Código Postal 42080, Apartado Postal 276 Teléfonos: (771) 71-1 31 40, 71–130 73, 71–1 35 96 Fax: 71–1 33 9910/04/2008

José Fructuoso Gutiérrez Díaz
Planificación y modelado, trata de la planificación, análisis y diseño de proyectos de software o sistemas de información, conforme a los requerimientos establecidos al inicio del mismo y aplicando técnicas modernas y de acorde a las características intrínsecas del mismo.

Planificación y Modelado

Contenido
Procesos de la ingeniería de requerimientos......................................................4 1.1 Requerimientos de proceso.......................................................................7 1.1.1 Inicio.................................................................................................... 8 1.1.2 Obtención............................................................................................8 1.1.3 Elaboración..........................................................................................9 1.1.4 Negociación.........................................................................................9 1.1.5 Especificación....................................................................................10 1.1.6 Validación..........................................................................................11 1.1.7 Gestión de requerimientos.................................................................12 1.2 Requerimientos de los usuarios (actores involucrados)...........................14 1.2.1 Requerimientos de los usuarios.........................................................16 1.2.2 Actores involucrados..........................................................................19 1.3 Requerimientos para el análisis y la negociación.....................................26 1.3.1 Requerimientos para el análisis.........................................................26 1.3.2 Requerimientos para la negociación..................................................31 1.4 Requerimientos para la gestión...............................................................32 1.4.1 Requerimientos duraderos y volátiles................................................34 1.4.2Planificación de la gestión de requerimientos.....................................35 1.4.3 Gestión de cambio de los requerimientos..........................................36 Planificación del sistema...................................................................................37 2.1 Planificación del tiempo...........................................................................39 2.1.1 Gráficos de barras y redes de actividades.........................................41 2.2 Evaluación del costo beneficio.................................................................44 2.2.1 Productividad.....................................................................................45 2.2.2 Técnicas de estimación......................................................................46 2.2.3 Modelo algorítmico de costos...........................................................48 2.3 Estudio de viabilidad................................................................................49 2.4 Planificación de la documentación...........................................................50 2.4.1 El documento de requerimientos del software...................................51
2008

Contenido............................................................................................................ 2

2

Planificación y Modelado 2.5 Gestión de la configuración del software.................................................53 2.5.1. Líneas base.......................................................................................54 2.5.2 Elemento de configuración del software............................................56 2.5.4 Identificación de objetos en GCS.......................................................58 2.5.5 Control de versiones..........................................................................59 2.5.6 Control de cambios............................................................................61 2.5.7 Auditoria de la configuración.............................................................64 2.5.8 Informes de estado............................................................................65 Análisis del proyecto.........................................................................................66 3.1 Análisis de riesgos...................................................................................66 3.2 Control de calidad....................................................................................68 Análisis de los requerimientos..........................................................................70 4.1 Requerimientos funcionales y no funcionales..........................................72 4.1.1 Requerimientos funcionales...............................................................72 4.1.2 Requerimientos no funcionales..........................................................74 4.2 Casos de uso............................................................................................76 4.2.1 Los Casos de uso y el valor del sistema.............................................76 4.3 Diseño de interfaz de usuario..................................................................80 4.3.1 Reglas en el diseño de interfaz de usuario........................................83
2008

2.5.3 El proceso de la configuración del software.......................................58

2

Planificación y Modelado

Procesos de la ingeniería de requerimientos.
¿Qué son requerimientos? normalmente, un tema de ingeniería de software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE: 1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. 3. Una representación documentada de una condición o capacidad como en 1 y 2.

Los requerimientos pueden dividirse en funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con las características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etcétera. Características de los requerimientos. Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes. • Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad,

2

2008

Unidad 1

análisis. Son difíciles de expresar con palabras (el lenguaje es ambiguo). • • • Dificultades para definir los requerimientos. 2 2008 Conciso: Un requerimiento es conciso si es fácil de leer y entender. . Los requerimientos están relacionados unos con otros. Algunos son más difíciles. • • • • • • • • Los requerimientos no son obvios y vienen de muchas fuentes. • ser • Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en el futuro.Planificación y Modelado características físicas o factor de calidad no pueden reemplazados por otras capacidades del producto o del proceso. Cada requerimiento tienen funcionales específicas. no debe causar confusiones en el lector. Verificable: un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección. y a su vez se relacionan con otras partes del proceso. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. propiedades únicas y abarcan áreas Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. más importantes o más estables que otros. más riesgosos. es decir. Consistente: un requerimiento es consistente si no es contradictorio con otro requerimiento. Nunca son iguales. demostración o pruebas. El lenguaje usado en su definición. si se proporciona la información suficiente para su comprensión. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Existen muchos tipos de requerimientos y diferentes niveles de detalle.

Planificación y Modelado • Son difíciles de cuantificar. es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos. Administración de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. 2008 Nota: el proceso de recopilar. la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema” Boehm 1979. “Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Los principales beneficios que se obtienen de la ingeniería de requerimientos son: • Permite gestionar las necesidades del proyecto en forma estructurada: cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. rendimiento y limitaciones” STARTS Guide 1987. ya que el conjunto de requerimientos es particular para cada proyecto. tales como estimación de costos. • 2 . interfaces. Importancia de la ingeniería de requerimientos. Mejora la capacidad de predecir cronogramas de proyectos. consistente y no ambigua. “Ingeniería de requerimientos es un enfoque sistemático para recolectar. cuyo producto es un modelo del cual se genera un documento de requerimientos” Leite 1987. entre los clientes y el equipo del proyecto” Rational Software. Este proceso utiliza una combinación de métodos herramientas y actores. analizar y verificar las necesidades del cliente para un sistema es llamado ingeniería de requerimientos. ya sean hablados o escritos. tiempo y recursos necesarios. organizar y documentar los requerimientos del sistema. Ingeniería de requerimientos vs. así como sus resultados: la IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento. no ambiguas. incluyendo funciones. A continuación se darán algunas definiciones para ingeniería de requerimientos. “Ingeniería de requerimientos es la disciplina para desarrollar una especificación completa. consistentes y completas del comportamiento del sistema. a especificaciones precisas. “Ingeniería de requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes.

facilidad de uso.1 Requerimientos de proceso. desempeño. y administrar los requisitos conforme éstos se transformen en un sistema operacional. especialmente aquellas decisiones tomadas durante el análisis. el proyecto no será exitoso. Mejora la comunicación entre equipos: la especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores.). 2 . validación y gestión. analizar las necesidades. es sumamente caro. validar la especificación. elaboración. Evita rechazos de usuarios finales: la ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema. Mejora la calidad del software: la calidad del software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad. obtención. por lo que se le involucra durante todo el desarrollo del proyecto. proporciona un mecanismo apropiado para entender lo que el cliente quiere. Si este consenso no ocurre. La ingeniería de requerimientos. negociar una solución razonable. especificación.Planificación y Modelado • Disminuye los costos y retrasos del proyecto: muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo. Los requerimientos de proceso se llevan a cabo a través de siente distintas funciones: inicio. evaluar la factibilidad. especificar la solución sin ambigüedades. etcétera. 2008 • • • 1. confiabilidad. negociación.

y la efectividad de la comunicación preliminar entre el cliente y el desarrollador. la mayoría de los proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. ¿Cómo se inicia un proyecto de software? ¿Es un evento aislado que se convierte en el catalizador para un nuevo sistema o producto basado en computadora? ¿O la necesidad evoluciona con el tiempo? No existen respuestas definitivas para estas preguntas. y todas sirven para establecer una base sólida respecto al diseño y la construcción de lo que obtendrá el cliente. e identifican una descripción funcional del ámbito del proyecto.1 Inicio. gerentes de producto) definen un caso de negocios para la idea. Los participantes de la comunidad de negocios (es decir. Nota: Se debe esperar la realización de una parte del diseño durante el trabajo de los requisitos y una parte del trabajo de los requisitos durante el diseño. 1. una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniería de software. Nota: “Por lo general. tratan de identificar la amplitud y profundidad del mercado.1.Planificación y Modelado Resulta importante destacar que algunas de estas funciones de la ingeniería de requerimientos ocurren en paralelo y que todas deben adaptarse a las necesidades del proyecto. a los usuarios. Christel y Kang identifican una serie de problemas que ayudan a entender por qué es difícil la obtención de requisitos: 2 2008 . y otros interesados cuáles son los objetivos para el sistema o el producto. El objetivo es establecer una comprensión básica del problema. las personas que quieren una solución. los gerentes. 1. la naturaleza de la solución que se desea.2 Obtención. hacen un análisis preliminar de factibilidad. En algunos casos.1. Pero en general. es muy difícil. pero suficiente para suscitar conversaciones con la organización de ingeniería de software. gente de mercadotecnia. Toda esa información está sujeta a cambios (una situación probable). En verdad parece muy simple preguntarle al cliente. Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto. de qué forma el producto satisface las necesidades del negocio y por último cómo se utilizará el sistema o producto día a día. las semillas de los desastres más importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto” Capers Jones. qué es lo que se debe lograr. Todas están dirigidas a definir lo que el cliente quiere. Pero no es simple.

pero se debe saber cuándo detenerla. Se definen los atributos de cada clase de análisis y se identifican los servicios que requiere cada clase. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. La clave es describir el problema de una forma que establezca una base firme para el diseño. Esta actividad de la ingeniería de requerimientos se enfoca en el desarrollo de un modelo técnico refinado de las funciones. no comprenden del todo el dominio del problema. Cada escenario del usuario se analiza para obtener clases de análisis: entidades del dominio del negocio visibles para el usuario final. comprenden poco acerca de las capacidades y limitaciones de su ambiente de cómputo.1. especifican requisitos ambiguos o inestables. 2008 • Problemas de comprensión.Planificación y Modelado • Problemas de ámbito.3 Elaboración. las funciones y el comportamiento del problema. El límite del sistema está mal definido o los clientes/usuarios especifican detalles técnicos innecesarios que pueden confundir. Dados los recursos limitados del negocio. transcurre el tiempo. tienen dificultades al comunicar necesidades al ingeniero de sistemas. en lugar de clarificar.4 Negociación. El resultado final de la elaboración es un modelo de análisis que define el dominio de la información. Los clientes/usuarios no están seguros por completo de qué es lo que se necesita. Los problemas cambian conforme • Para ayudar a superar estos problemas. Problemas de volatilidad. Nota: la elaboración es buena. los objetivos generales del sistema. 1. La elaboración es una acción del modelado del análisis y se componen de una serie de tareas del modelado y refinamiento. características y restricciones del software. 1. La elaboración se conduce mediante la creación y el refinamiento de escenarios del usuario que describen la forma en que el usuario final (y otros actores interactúan con el sistema) interactuarán con el sistema. los ingenieros de requerimientos deben realizar en forma organizada la actividad de recopilación de requisitos. Si se trabaja más allá de ese punto. no resulta inusual que los clientes y usuarios pidan más de lo que se puede lograr. especifican requisitos que chocan con las necesidades de otros clientes/usuarios. omiten información que consideran “obvia”.1. También es relativamente 2 . Se identifican las relaciones y la colaboración entre las clases y se produce una variedad de diagramas de UML complementarios. se estará haciendo diseño.

usuarios y a otros interesados que ordenen sus requisitos y después discutan los conflictos relacionados con la prioridad. 2 . argumentan que esto conduce a que los requisitos sean presentados de manera más consistente y por ende más entendible. Por otro lado. podría ser que no se necesite más que escenarios de uso. Ambas partes ganan porque se solidifica un “trato” con el que las dos pueden vivir. Algunos sugieren que para una especificación se debe desarrollar y utilizar una “plantilla estándar”. una colección de escenarios de uso.Planificación y Modelado común que diferentes cliente o usuarios propongan requisitos que entran en conflicto entre sí al argumentar que su versión es “esencial para nuestras necesidades especiales”. algunas veces es necesario ser flexible mientras se desarrolla una especificación. un prototipo o cualquier combinación de estos. Se identifican y analizan los riesgos asociados con cada requisito. En el contexto de los sistemas basados en computadora (y en software).1. Mediante un enfoque iterativo. Una especificación puede ser un documento escrito. el término especificación tiene significados diferentes para personas distintas. un modelo matemático formal. 2008 El ingeniero de requerimientos debe conciliar estos conflictos por medio de un proceso de negociación. Se hacen “estimaciones” preliminares del esfuerzo requerido para su desarrollo y después se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Nota: la formalidad y el formato de una especificación varían con el tamaño y la complejidad del software que se va a construir. un conjunto de modelos gráficos.5 Especificación. Se pide a los clientes. 1. combinan o modifican de forma que cada parte alcance cierto grado de satisfacción. Sin embargo. Describe la función y el desempeño de un sistema basado en computadora y las restricciones que regirá su desarrollo. los requisitos se eliminan. Sirve como base para las actividades de ingeniería de software subsecuentes. Respecto de sistemas grandes el mejor enfoque podría ser un documento escrito que combinara descripciones en lenguaje natural y modelos gráficos. cuando dichos sistemas residan en ambientes técnicos que se comprendan bien. La especificación es el producto de trabajo final que genera la ingeniería de requerimientos. en cuanto a productos o sistemas más pequeños. Nota: en una negociación eficaz no debe haber ni ganador ni perdedor.

1. A continuación se muestra una lista de verificación para la validación de requisitos. que se han detectado inconsistencias. áreas que tal vez requieren una clasificación. una persona. usuarios y otros interesados que examinan la especificación y buscan errores en el contenido o en la interpretación. 2 2008 . y que los productos de trabajo cumplen con los estándares establecidos para el proceso. conflictos entre los requisitos. inconsistencias (que es un problema importante cuando se desarrollan productos o sistemas grandes). Se recomienda utilizar el modelo de análisis para asegurar que los requisitos se han establecido de madera consistente.Planificación y Modelado 1. clientes. El mecanismo primario para la validación de requerimientos es la revisión técnica formal. información faltante. omisiones y errores y que éstos han sido corregidos. El equipo de revisión que valida los requisitos incluye ingenieros de software. Nota: un interés clave durante la validación de requisitos es la consistencia. una regulación o un reglamento) está identificada? ¿El enunciado final del requisito ha sido examinado por la fuente original o comparándolo con ella? ¿El requisito está restringido en términos cuantitativos? • • • ¿El requisito es rastreable para los objetivos generales del sistema o producto? • • ¿La especificación está estructurada de una forma que conduzca a su comprensión. Enseguida se presenta un pequeño subconjunto de las preguntas que deben realizarse: • ¿El requisito se puede probar? Sí es así. proyecto y producto. La validación de requerimientos examina la especificación para asegurar que todos los requerimientos de software se han establecido de manera precisa. La calidad de los productos de trabajo procedentes de la Ingeniería de requerimientos se evalúa durante un paso de validación. Con frecuencia resulta útil examinar cada requisito frente a una serie de preguntas en forma de lista de verificación. o requisitos irreales (inalcanzables). ¿Se pueden especificar las pruebas (algunas veces llamadas criterios de validación) para ejecutar el requisito? ¿El requisito es rastreable para cualquier modelo de sistema que haya sido creado? • ¿Los requisitos están establecidos de manera clara? ¿Éstos pueden malinterpretarse? ¿La fuente del requisito (por ejemplo.6 Validación.

7 Gestión de requerimientos. Aspecto especifico del sistema o su ambiente A01 Requisito A02 A03 A04 A05  Aii R01 R02 R03        2 2008 . La gestión de requerimientos es un conjunto de actividades que ayudan al equipo de proyecto a identificar. Nota: cuando un sistema es grande y complejo.Planificación y Modelado referencia y traducción fácil en productos de trabajo más técnicos? • ¿Cuáles otros requisitos están relacionados con este? ¿Están registrados de manera clara por medio de una matriz de referencias cruzadas u otro mecanismo? ¿El requisito viola alguna restricción del dominio del sistema? • ¿Se ha creado un índice para la especificación? • • ¿Los requerimientos asociados con el rendimiento. Se sabe que los requerimientos para los sistemas basados en computadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema. el desempeño y las características operacionales se han establecido de manera clara? ¿Cuáles requerimientos parecen ser implícitos? 1.1. Muchas de estas actividades son idénticas a las actividades de la gestión de la configuración del software (CGS). Se recomienda el uso de las tablas de rastreabilidad para facilitar un poco el trabajo. controlar y rastrear los equipos y los cambios a éstos en cualquier momento mientras se desarrolla el proyecto. la determinación de las conexiones entre los requisitos puede ser una tarea redituable.

Herramientas de software para la ingeniería de requerimientos. estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requerimientos de forma que puede buscárseles con rapidez para entender cómo el cambio en un requisito afectará diferentes aspectos del sistema que se construirá. Establece categorías entre los requerimientos de acuerdo con los subsistemas que gobiernan. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad. • • • • En muchos casos. En la figura 1. Tabla de rastreabilidad de dependencia. Tabla de rastreabilidad del subsistema. Identifica la fuente de cada requerimiento. Tabla de rastreabilidad de la interfaz.Planificación y Modelado R04 R05        2008 Rnn   Figura 1. cada una de ellas relaciona los requisitos con uno o más aspectos del sistema o de su ambiente. 2 . Muestra la forma en que los requerimientos se relacionan con las interfaces internas y externas del sistema.1 se muestra de manera esquemática una tabla de rastreabilidad.1 tabla de rastreabilidad La gestión de requisitos comienza con la identificación. Entre las muchas tablas de rastreabilidad tenemos las siguientes: • Tabla de rastreabilidad de las características. Tabla de rastreabilidad de la fuente. Indica la forma en que los requisitos están relacionados entre sí. Cada requerimiento se asigna a un solo identificador. Muestra la manera en que los requerimientos se relacionan con las características del sistema/producto observables para el cliente.

Ian Sommerville. Por lo general.Planificación y Modelado Las herramientas de la ingeniería de requerimientos ayudan en la recopilación. La mecánica de las herramientas varia.2 Requerimientos de los usuarios (actores involucrados). De igual forma que 2 2008 . las herramientas de la ingeniería de requerimientos construyen una variedad de modelos gráficos (por ejemplo. funcionamiento y comportamiento de un sistema. para designar la descripción detallada de lo que es sistema debe de hacer. UML) que muestran los aspectos de información. Esto se hace utilizando el término requerimientos del usuario. gestión y validación de los requerimientos. 1. Pearson Educación). para designar los requerimientos abstractos de alto nivel. Mecánica. que algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. modelado. Estos modelos forman la base para todas las otras actividades en el proceso del software. establece en su Libro (Ingeniería de Software 6º edición. y requerimientos del sistema.

debe ser preciso.4 Se proveerán recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.2 ilustra la diferencia entre los requerimientos del usuario y del sistema. 1. El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas. Los requerimientos del sistema establecen con detalle los servicios y restricciones del sistema. 1. Definición de requerimientos del usuario. Esta especificación agrega detalle a la especificación de requerimientos del sistema. Muestra la manera en que un requerimiento del usuario se expande en varios requerimientos del sistema. algunas veces denominado especificación funcional. Administradores contratistas. 3. Diferentes niveles de especificación del sistema son de utilidad debido a que comunican la información del sistema a los diferentes tipos de lectores. Los requerimientos del usuario. archivo al archivo representado por el icono seleccionado.2 Cada tipo de archivo externo tendrá una herramienta asociada que será aplicada al archivo. los del sistema y la especificación del diseño del software se definen como se muestra a continuación: 1. Usuarios finales del sistema. La figura 1. se puede producir una descripción más detallada (una especificación del diseño del software) para establecer un puente entre la ingeniería de requerimientos y las actividades de diseño.2 Requerimientos del usuario y del sistema.5 Cuando un usuario selecciona un icono que representa un archivo externo.3 Cada tipo de archivo externo se representara como un icono especifico sobre la pantalla del usuario. Administradores clientes. 2 2008 . Ingenieros clientes. 2. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos externos.Planificación y Modelado en estos dos niveles de detalle. El documento de requerimientos del sistema. 1. Una especificación del diseño del software es una descripción abstracta del diseño del software que es una base para un diseño e implementación detallados. Requerimientos del usuario. 1. el efecto de esta selección es aplicar la herramienta asociada con este tipo de Figura 1. Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas. Especificación de los requerimientos del sistema. de los servicios que se espera que el diagrama provea y de las restricciones bajo las cuales debe operar. 1.

Los requerimientos de los usuarios para un sistema describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Confusión de requerimientos.3). las metas del sistema y la información para el diseño. Arquitectos del sistema. Algunas veces es difícil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y hacerlos fácil de leer. Desarrolladores del software Figura 1. . Conjunción de requerimientos. Falta de claridad. las características del diseño del sistema.2. Ingenieros clientes. representaciones y diagramas intuitivos sencillos. Deben redactarse utilizando el lenguaje natural. Los usuarios finales del sistema pueden leer ambos documentos. la especificación del diseño del software es un documento orientado a la implementación. Usuarios finales del sistema. También lo utilizaran tanto el equipo de cliente como el del contratista. La especificación de requerimientos del sistema se orienta al personal técnico y a los administradores del proyecto. en tanto sea posible. Por consiguiente. No se distinguen claramente los requerimientos funcionales y no funcionales. Diversos requerimientos diferentes se expresan de forma conjunta como un único requerimiento. 1. los requerimientos del usuario no se deben definir utilizando un modelo de implementación.3 Lectores de los diferentes tipos de especificaciones. Arquitectos del sistema. Desarrolladores del software. Únicamente especifican el comportamiento externo del sistema y evitan.1 Requerimientos de los usuarios. 2. 3. Finalmente. Sin embargo. pueden surgir diversos problemas cuando se redactan en lenguaje natural: 1. Debe redactarse por los ingenieros de software que desarrollaran el sistema. 2 2008 Requerimientos del sistema. Especificación del diseño del Los requerimientos del usuario se redactan para el cliente y los contratistas administradores quienes no tienen un conocimiento técnico detallado del sistema (vea la figura 1.Planificación y Modelado Ingenieros clientes (quizás).

es decir. Este requerimiento incluye tanto información conceptual como detallada. 1. ésta también incluye el detalle de que los recursos de control de la configuración que permiten el acceso a los objetos en una versión de grupo sin especificar su nombre completo. considere uno de los requerimientos para un entorno de programación Ada que se muestra en la figura 1.5 ilustra esta confusión.Planificación y Modelado La base de datos deberá ayudar a la generación y control de la configuración de objetos. los lectores no técnicos de los requerimientos del usuario se confundirán con los detalles que sólo son relevantes a los lectores técnicos. La opción de cuadrícula se proveerá en la vista de reducción de ajuste. el usuario activará una cuadricula en centímetros o en pulgadas. dicha cuadrícula estará desactivada. 3. De forma inicial.4 un requerimiento de una base de datos para un entorno de programación. Figura1. Entorno de Ayuda a la programación en Ada.4. Para ayudar a la ubicación de entidades en un diagrama. Ésta cuadrícula se podrá activar o desactivar en cualquier momento durante una sesión de edición y puesta en pulgadas y en centímetros. Recursos de la cuadrícula. 2 2008 . Expresa la existencia de recursos de control de la configuración como una parte inherente del APSE. Este ejemplo se tomó del documento de requerimientos para una herramienta CASE para editar modelos de diseño de software. Por otra parte. Para ilustrar algunos de estos problemas. pero el número de líneas de la cuadrícula a mostrar se reducirá para evitar saturar el diagrama más pequeño con líneas de cuadrícula. Un requerimiento de interfaz de usuario no funcional que define la manera en que esa cuadrícula es activada o desactivada por el usuario.5 Un requerimiento de usuario para un editor de cuadrícula. En el documento de requerimientos es una buena práctica separar los requerimientos del usuario de los detallados del sistema. La primera oración mezcla tres diferentes clases de requerimientos. objetos que a su vez son agrupaciones de otros de la base de datos. Los recursos para este control permitirán el acceso a los objetos en una versión de grupo utilizando un nombre incompleto. El usuario especifica que se desplegará una cuadrícula para que las entidades se coloquen de forma precisa en un diagrama. Nota: APSE significa. Se presenta la justificación de esto. Figura 1. mediante una opción en el panel de control. Este detalle podría ubicarse mejor en la especificación de requerimientos del sistema. Un requerimiento no funcional que provee información detallada de las unidades de la cuadrícula (centímetros o pulgadas). La figura 1. 2. Sin embargo. Un requerimiento funcional conceptual que establece que el sistema de edición proveerá una cuadrícula.

6 Una definición de un recurso para el editor de cuadrícula. de forma deliberada se rechaza esta opción cuando se hace una ubicación manual. restringen la libertad del desarrollador del sistema para proveer soluciones innovadoras a los problemas del usuario y hace que los requerimientos sean difíciles de comprender. El usuario selecciona el tipo de nodo a agregar. donde la alineación de entidades es responsabilidad del usuario. en la figura 1. Esta cuadrícula deberá ser pasiva. El usuario mueve el cursor a la proximidad de la posición del nodo en el diagrama e indica que el símbolo de dicho nodo debe agregarse en este punto. Sí en alguna etapa posterior se propone un cambio a esto. El editor deberá proporcionar un recurso a los usuarios para agregar a su diseño nodos de un tipo especifico. Sin embargo. no define sus unidades cuando se activa. La secuencia de acciones para agregar un nodo debería ser como se muestra a continuación: 1. como la de intercambiar unidades.Planificación y Modelado El requerimiento de la figura 1.5 también muestra un parte de la información de inicialización. El usuario es la mejor persona para decidir donde se deberían ubicar las entidades. Sin embargo. con énfasis en las características esenciales del sistema. La base asociada a los requerimientos es importante. Provee alguna información detallada. 3. Aunque en una cuadrícula activa pueda ser de utilidad que las entidades se ajusten a las líneas de la cuadrícula. la ubicación es imprecisa. Figura 1. Cuando los requerimientos del usuario incluyen demasiada información. Define que la cuadrícula está inicialmente desactivada. Adición de nodos a un diseño. 2 2008 . Fundamento: El usuario es la mejor persona para decidir dónde ubicar un nodo en un diagrama. Esto se ilustra en la figura 1.6 la base declara que es de utilidad que una cuadrícula activa situé automáticamente objetos a una línea de la cuadrícula. Recursos de la cuadrícula. Los requerimientos del usuario simplemente deben enfocarse a los recursos principales a proveer. entonces es claro que la utilización de una cuadrícula pasiva es mucho mejor que una decisión de implementación.6. 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 éstos. Fundamento: Una cuadrícula ayuda al usuario a crear un diagrama ordenado con entidades bien espaciadas. donde se redactan nuevamente los requerimientos para el editor de la cuadrícula. pero no el espacio entre las líneas de la cuadrícula. Por ejemplo. El editor deberá proporcionar un recurso para la cuadrícula donde una matriz de líneas horizontales y verticales proporciona un fondo para la ventana del editor. 2. Este enfoque da al usuario control directo sobre la selección del tipo de nodo y sobre la ubicación. Después el usuario arrastra el símbolo del nodo a su posición final.

1. Es necesario que la sucesión de acciones se especifique. Esta es una especificación más detallada de la función. distinguir entre los requerimientos deseables y los obligatorios. Dueños del sistema.Planificación y Modelado Figura 1. que también define parte del sistema de edición. Estandarizar el formato significa reducir la probabilidad de las omisiones y hacer que los requerimientos sean fáciles de verificar. Pero no es absolutamente esencial si existe buenas razones para hacerlo. Resalta el texto (con negritas o itálicas) para ver las partes claves del requerimiento. Algunas veces. Utilizar el lenguaje de forma consistente. Para minimizar las malas interpretaciones al redactar los requerimientos del usuario. 2 2008 En la figura 1. o cómo se selecciona el tipo. Usuarios del sistema.7 se muestra un ejemplo adicional de un requerimiento del usuario más específico. Por lo tanto. la definición incluye una lista de las acciones del usuario. utilizar el lenguaje “técnico” de computación. esto es necesario para que todas las funciones se proporcionen de forma consistente. y una referencia a la especificación detallada de los requerimientos para el sistema.7. 2.2. que incluye una declaración base para cada requerimiento del usuario. El formato incluye poner en negritas el requerimiento inicial. En este caso.2 Actores involucrados. por lo tanto es obligatorio que el sistema incluya un recurso para agregar nodos a un diseño. en particular. Es común definir estos últimos en futuro simple y los deseables en futuro condicional como se muestra en la figura 1. 4. 3. Los actores en los sistemas de información se dividen en cinco grupos: 1. se recomienda seguir unas pautas sencillas para redactar requerimientos: 1. . hasta donde sea posible. la definición no establece como se mueven el cursor y el símbolo.7 Requerimientos del usuario para la creación de nodos. en los requerimientos de usuario será inevitable utilizar términos técnicos detallados provenientes del dominio de aplicación del sistema. Los detalles de la implementación no deben incluirse en esta información adicional. Sin embargo. Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al formato. Evitar. 2.

pero para estudiarlos los separaremos en dos grandes clases: usuarios internos y usuarios externos dentro de los cuales se cuenta con más subdivisiones las cuales se explican a continuación: Usuarios internos. • • 2 . Diseñadores de sistemas. Abogados. 4.2 Usuario del sistema. Supervisores mandos medios y ejecutivos: son los empleados que toman decisiones.Planificación y Modelado 3. Dentro de este grupo tenemos. Constructores de sistemas. Este grupo es que paga por el sistema. 1.2. los dueños del sistema tienden a estar interesados en: • • • ¿Cuánto costara el sistema? ¿Cuál será el costo/beneficio? ¿Cuándo recuperaran la inversión y como la recuperaran? 2008 Y otras. Son aquellos empleados del negocio para el cual se está construyendo el sistema y son el mayor porcentaje de usuarios de un sistema.1 Dueños del sistema. las cuales son de interés económico primordialmente.2. científicos etcétera. Staff técnico y profesional: son empleados que realizan tareas especializadas ejemplo. pagos etcétera. Ellos capturan los datos en el sistema. en que sea fácil de aprender y de utilizar. Analistas de sistemas. ya sea decisiones del día a día (supervisores).2. Los usuarios del sistema son los que definen los requerimientos del negocio y las expectativas del sistema. procesan órdenes. Ellos ven a un sistema de información en términos de la funcionalidad que provee a sus trabajos. A continuación se exponen cada uno de estos grupos. 5. • Empleados administrativos y de servicios: realizan los procesos del día a día. de corto plazo (mandos medios) o largo plazo (ejecutivos). ingenieros. Para cualquier sistema de información grande o pequeño habrá uno o más dueños del sistema. Hay muchas clases de usuarios. 1. facturas.2.

3 Diseñadores del sistema. Socios: son cualquier organización a la cual nuestra compañía compre servicios o de la que sea socio. dentro de los cuales podemos mencionar: • Clientes: son cualquier organización o persona(s) que compren nuestros productos o servicios. se encargan de realizar el diseño de la base de datos. handhelds y smartphones (ya se con conexión en bases o vía inalámbrica) por lo que debemos tener presente el uso de estos dispositivos al momento de realizar el diseño del sistema.2. Son especialistas en bases de datos. • 2 2008 .Planificación y Modelado Usuarios Externos. de forma que se ha generado un aumento de usuarios externos.2. Ellos diseñan: bases de datos. Ejemplo: mantenimiento. ellos se conectan a la información de la compañía a través de laptos. como por ejemplo las compras online. Ejemplo: representantes de venta. pantallas. Empleados: son empleados que trabajan en el camino o en casa. redes y software que se puede adaptar a los requerimientos del usuario. 1. empleados que puedan trabajar remotamente en el sistema. y la coordinación de cambios en bases de datos corporativas. outsourcing. Surtidor o Proveedor: son cualquier organización en la cual nuestra compañía compre insumos. Hoy día nuestros clientes se pueden convertir en usuarios directos. etc. Hoy día nuestros proveedores pueden interactuar directamente con nuestros sistemas y determinar nuestra necesidad de insumos y crear de forma automática ordenes con dichas necesidades. manejo de la red. entradas y salidas del sistema. Un diseñador del sistema puede pertenecer a algunas de las siguientes especialidades: • Administrador de la base de datos. Se especializan en redes y telecomunicaciones. ya que pueden ejecutar órdenes y compras directamente al sistema. El uso de Internet ha permitido extender los límites de las organizaciones. Arquitectos de redes. • • • La cantidad de usuarios externos ha ido en aumento en los últimos tiempos. Son técnicos especializados que traducen los requerimientos de los usuarios del negocio en soluciones técnicas.

4 Constructores del sistema. Expertos en seguridad. Son especialistas en tecnologías y lenguajes de bases de datos. Su rol es la construcción del sistema de acuerdo a las especificaciones dadas por el diseñador de sistemas. Artistas gráficos. Son especialistas que diseñan. web. • • • • • 2 2008 . son especialistas que desarrollan.Planificación y Modelado • • Arquitectos web. Especialistas en tecnología. son especialistas que convierten los requerimientos de la compañía en lenguajes de programación. Son especialistas que codifican y dan mantenimiento a los servidores Web. Webmaster. modifican y prueban las estructuras de las bases de datos así como los programas que se utilizan para darles mantenimiento a las mismas. Programadores de sistemas. Son especialistas en la tecnología grafica y en métodos de diseño de interfaces fáciles de utilizar. Un constructor del sistema puede pertenecer a algunas de las siguientes especialidades: • Programador de aplicaciones. (en pc. Son expertos en la aplicación de tecnologías específicas que podrían ser utilizadas en un sistema.2. Tanto en paquetes de software como en hardware con características especificas. generalmente de un alto grado de complejidad. smartphones. Administradores de seguridad. implementan y manejan la seguridad y controles de privacidad de una red. prueban e implementan software a nivel de sistema operativo. Administradores de redes. Ellos desarrollan y prueban programas de computación que capturan y almacenan datos. • • 1. etc).2. se encargan de diseñar sitios web para las organizaciones. Programadores de bases de datos. Son especialistas que diseñan. instalan y optimizan las redes de computadoras. handheld. que construyen. Son en especialistas en tecnología y metodologías utilizadas para asegurar la integridad y la privacidad de los datos y la red.

este trabajo no implica un proyecto completo de sistemas. redes y otros paquetes de software. .2. con el propósito de mejorara los procesos de una organización.2. Con frecuencia. Es un especialista que estudia los problemas y necesidades de una organización para determinar cómo las personas. Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentro de la empresa en la cual labora de manera regular. En este rol el analista recurre a su experiencia profesional con el hardware y software de cómputo y al uso que se le da en el negocio. Esta contratación se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los demás miembros de una organización.5 Analista de sistemas. Son especialistas que integran paquetes de software con hardware.Planificación y Modelado • Integradores de software. el procesamiento de datos y su consiguiente producción de información. 2 2008 1. El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada. el Analista de Sistemas desempeña el rol de consultor para un negocio y. por tanto podría ser contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa. Muchas mejoras incluyen un mayor apoyo a las funciones de negocio a través del uso de sistemas de información computarizados. En su función de consultor externo. experto en soporte técnico y agente de cambio. Los tres principales roles del analista de sistemas son el de consultor. El analista desempeña diversos roles. El rol de experto en soporte técnico del analista de sistemas. usted dependerá en gran medida de los métodos sistemáticos que se deberá aprender de los libros sobre el análisis y diseño de sistemas de información. También se puede traducir en una desventaja porque alguien externo nunca conocerá la verdadera cultura organizacional. Con frecuencia. Roles del analista de sistemas. Además tendrá que apoyarse en los usuarios de los sistemas de información para entender la cultura organizacional desde el punto de vista que ellos tienen. El rol de consultor del analista de sistemas. Un analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo departamento. procesos y la tecnología de la información pueden en conjunto mejorar un negocio. datos. en ocasiones varios de ellos al mismo tiempo.

También es parte de su tarea enseñar a los usuarios el proceso del cambio. Hay una gran diversidad de personas trabajando como analistas de sistemas. usted tendrá que interactuar constantemente con quienes vaya a cambiar. Su presencia en el negocio inicia el cambio. Como analista de datos. el analista es un solucionador de problemas. Como analista. 2008 Cualidades del analista de sistemas. En primer lugar. El rol de agente de cambio del analista de sistemas. ya que las modificaciones a un sistema de información no solo afecta a este sino que provocan cambios en el resto de la organización. tan solo actúa como recurso para aquellos que si lo están. Es una persona que aborda como un reto el análisis de problemas y que disfruta al 2 . Si el cambio (es decir. usted es un agente de cambio si desempeña cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas y está presente en la empresa durante un largo periodo (de dos semanas a más de un año). la mayoría de los analistas de sistemas tienen algunas cualidades comunes. Sin su colaboración usted no podría entender lo que ocurre en una organización y el cambio real nunca se daría. No obstante. De las descripciones anteriores sobre los roles que desempeña el analista de sistemas. En su calidad de analista de sistemas desempeñando la función de agente de cambio debe promover un cambio que involucre el uso de los sistemas de información. El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio. Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio. De ahí que tenga que interactuar con los usuarios la administración desde el principio del proyecto. gran parte de sus actividades podrían ajustarse a este rol. el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de autorizarlo. Si usted es un analista de sistemas contratado por una empresa manufacturera o servicios. las mejoras al negocio que se pueden concretar mediante los sistemas de información) parece factible después de efectuar el análisis. ya sea interno o externo para la empresa. desarrolla un plan para el cambio y coopera con los demás para facilitar el cambio. usted no está a cargo del proyecto. por lo que cualquier descripción que intente ser general está destinada a quedarse corta en algún sentido. usted debe estar consciente de este hecho y utilizarlo como punto de partida para su análisis.Planificación y Modelado Como experto en soporte técnico. se deduce fácilmente que el analista exitoso debe contar con una amplia gama de cualidades. Una vez que se haya alcanzado el consenso acerca de los cambios por realizar.

Planificación y Modelado diseñar soluciones factibles. Cuando es necesario, el analista debe contar con la capacidad de afrontar sistemáticamente cualquier situación mediante la correcta aplicación de herramientas, técnicas y su experiencia.
2008

El analista también debe ser un comunicador con capacidad para relacionarse con los demás durante extensos periodos. Necesita suficiente experiencia en computación para programar, entender las capacidades de las computadoras, recabar los requisitos de información de los usuarios y comunicarlos a los programadores. Asimismo, debe tener una ética personal y profesional firme que le ayude a moldear las relaciones con sus clientes. El analista de sistemas debe ser una persona autodisciplinada y automotivada, con la capacidad de administrar y coordinar los innumerables recursos de un proyecto, incluyendo a otras personas. La profesión de analista de sistemas es muy exigente; pero es una profesión en constante evolución que siempre trae nuevos retos.

2

Planificación y Modelado

1.3 Requerimientos para el análisis y la negociación.
2008

Una vez recopilados los requerimientos, el producto obtenido configura la base de los requerimientos para el análisis. Los requerimientos se agrupan por categorías y se organizan en sub conjuntos, se estudia cada requerimiento en relación con el resto, se examinan los requerimientos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios. Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que esa versión es esencial por necesidades especiales. Nota: el ingeniero de requerimientos debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requerimientos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requerimiento serán identificados y analizados. Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requerimiento en el costo del proyecto y en el plazo de entrega. 1.3.1 Requerimientos para el análisis. En esta sección se presenta el análisis global de los requerimientos de una aplicación, que es un proceso de conceptualización y expresión de los conceptos en forma concreta. La mayor parte de los defectos encontrados en el software entregado se originan durante la obtención de los requerimientos para el análisis. En general, estos defectos también son los más caros de reparar. 1.3.1.1 Significado de requerimientos para el análisis. Para construir algo primero debe entenderse lo que debe ser “algo”. El proceso de entender y documentar este algo se llama “requerimientos para el análisis”. En general, los requerimientos expresan qué se supone debe hacer una aplicación: por lo común, no intentan expresar cómo lograr estas funciones. Por ejemplo, la siguiente afirmación es un requerimiento para una aplicación de contabilidad. El sistema debe permitir a los usuarios acceso a sus saldos. En términos generales, la siguiente afirmación no es un requerimiento para una aplicación.

2

Planificación y Modelado Los estados de cuenta del cliente se almacenarán en una tabla llamada “saldos” en una base de datos de Access™. Esta última afirmación se refiera a cómo debe de construirse la aplicación, y no a qué debe hacer la aplicación. Un requerimiento en un nivel con frecuencia se traduce en más de un requerimiento específico en el siguiente nivel más detallado. Además existen excepciones a la regla de que en los requerimientos se evite especificar cómo debe hacerse algo. Por ejemplo, el cliente del ejemplo del anterior podría, por alguna razón, querer que los estados de cuentas se almacenen en la base de datos de Access™ con el nombre indicado. En este caso, la segunda afirmación sería un requerimiento. La salida de los requerimientos para el análisis es un documento que se conoce como especificación de requerimientos o especificación de requerimientos de software (ERS). 1.3.1.2 Requerimientos C y requerimientos D. Durante algún tiempo se ha discutido quien es el “dueño” de los requerimientos: el cliente o el desarrollador. Para manejar este aspecto, el análisis de requerimientos se divide en dos niveles. El primer nivel documenta los deseos y necesidades del cliente y se expresa en un lenguaje claro para él. Los resultados suelen llamarse “requerimientos del cliente” o “requerimientos c”. La audiencia primaria para los requerimientos C es la comunidad del cliente y la secundaria es la comunidad del desarrollador. El segundo nivel documenta los requerimientos de manera específica y estructurada. Éstos se llaman “requerimientos del desarrollador” o “requerimientos D”. La audiencia primordial de éstos es la comunidad del desarrollador y la secundaria la del cliente. Aquí se menciona el estándar de IEEE para documentar los requerimientos. La distinción entre los tipos de requerimientos C y D en los títulos principales de la plantilla del documento estándar del IEEE se ilustra en la figura 1.8.

ERS (IEEE) 1. Introducción. 2. Descripción global. 3. Requerimient os específicos. 4. Información de apoyo.
Requerimientos D

Requerimientos C

2

2008

Planificación y Modelado

Figura 1.8 Requerimientos del cliente comparados con los requerimientos detallados.

Aunque las audiencias principales para los requerimientos C y D son diferentes, los clientes y desarrolladores trabajan juntos para crear productos exitosos. Una manera de asegurar una buena comunicación es hacer que representantes de los clientes trabajen junto con los desarrolladores. Algunas organizaciones de desarrollo se rehúsan a aceptar trabajos si no se hace esto. 1.3.1.3 Por qué deben escribirse los requerimientos. Aun para las personas sin experiencia puede ser evidente la necesidad de escribir lo que se supone debe hacer un programa cuando esté terminado. De cualquier forma, este proceso de escribir suele ignorarse o dejarse morir. En esas situaciones, se cree que el código fuente expresa todos los requerimientos: como el código fuente es imprescindible, ¿por qué no reducir el proceso completo a este documento esencial? La respuesta es que esto no funciona. La disciplina de ingeniería de software, los mejores ingenieros de software y este libro, insisten en escribir documentos con todo cuidado. Sin ellos, el equipo no sabe en realidad cuáles son las metas que intenta lograr, no puede inspeccionar y probar su trabajo de manera adecuada, no puede controlar su productividad, no obtiene datos adecuados de sus prácticas, no puede predecir el tamaño y esfuerzo de su siguiente trabajo y no puede satisfacer a sus clientes. En resumen, no existe la ingeniería profesional sin los requerimientos escritos. Para ilustrar estos puntos, considere el siguiente requerimiento para una aplicación científica. La aplicación debe desplegar la longitud del gene x12345 en la ventana del sistema (requerimiento 7824). La figura 1.9 muestra una lista de lo que debe hacerse con éste y los otros requerimientos. Cada requerimiento debe. Además, debe registrarse el tiempo para realizar cada paso, de manera que en futuro se pueda estimar el tiempo para implementar • Expresarse de modo adecuado. requerimientos similares en contextos similares. Considere el caos que resultaría si el requerimiento 7824 no estuviera escrito. Muy pocos de los pasos • Ser de acceso sencillo. de los figura 1.9 se podrían llevar a cabo de modo apropiado. No sería de sorprender que la aplicación en cuestión no fuera confiable. • Numerarse.
• • • • • • Acompañarse con pruebas que lo verifiquen. Tomarse en cuenta en el diseño. Tomarse en cuenta en el código. Probarse aislado.

Validarse con las pruebas después de construir la aplicación.

2

Probarse junto con otros requerimientos.

2008

• Aprovechar herramientas de expresión. Escribir requerimientos C en forma de documento estándar. Construir los requerimientos D. 4. El equipo recolecta las mediciones de las etapas de este proceso para facilitar la estimación de iteraciones y aplicaciones futuras. Figura 1.9 para todos y cada uno de los requerimientos. 2.11. • Calidad autoevaluada (escala 1 a 10). • Tasas de defectos en inspecciones. 1. Revisión con el cliente • Identificar deseos y necesidades. se obtiene una idea de por qué los ingenieros de software manejan de forma extensa los requerimientos individuales: son el acervo básico más importante de la profesión.10 es un mapa conceptual típico del proceso de requerimientos para el análisis descrito en este capítulo. • Bosquejar las GUI. inspeccionar los requerimientos C. Identificar “el cliente”. • Cantidad lograda. Existen varias formas para organizar la especificación de requerimientos de software. Para todas las etapas. Entrevistar representantes del cliente. También este es un estándar ANSI. Con la aprobación del cliente 5. 1. 3. Cuando se contemplan los pasos de la figura 1.9 lo que debe hacerse con cada requerimiento.1.Planificación y Modelado Figura 1.10 Mapa conceptual típico para los requerimientos C. El último paso de mapa reúne los requerimientos D detallados. supervisar métricas por ejemplo: • Tiempo indicado. Este mapa conceptual se consultará durante cada iteración. Minutos de interacción con el cliente por página. • Identificar el hardware. 2 2008 .4 mapa conceptual típico del proceso de requerimientos para el análisis. Páginas de requerimientos C. Se usará y modificará el estándar IEEE830-1993 que muestra la figura 1. La figura 1.3.

no un lujo. El análisis de requerimientos es una necesidad. 2.3 Definiciones. 2. Descripción general. Los ingenieros que usan un proceso iterativo bien organizado reúnen requerimientos. expresarse de una u otra forma. 1. Información de apoyo.2Interfaces de usuario. ¿Por qué tantos proyectos sufren daños por un análisis de requerimientos malo o falta del mismo? Una razón es que.5 Retos y beneficios del análisis de requerimientos. el que no se repara antes de terminar el documento de requerimientos) es muy costoso. Requerimientos específicos.6Restricciones de memoria. 1. Pero si alguien le proporcionara 2 2008 . Figura 1. 1.4 Referencias.2 Funciones de producto. En términos financieros.1 Perspectiva del producto.3 Características del usuario. 2.7Operaciones. por lo general.Planificación y Modelado Los ingenieros de software discuten los méritos de las distintas formas de documentación de los requerimientos.8Requerimientos de adaptación del sitio.1. 2. entonces el costo de encontrar y reparar ese mismo defecto al final del proceso de desarrollo es entre $2000 y $5000.3. si el costo de encontrar y reparar un defecto en la etapa de requerimientos es $100.1. 2. La desventaja del estándar IEEE es que es bastante antiguo y necesita modificarse y ampliarse (para reflejar los avances en el análisis y diseño orientados a objetos y el surgimiento de los aspectos de Internet).4 Restricciones. al principio de un proyecto los clientes no saben qué quieren o necesitan con exactitud. diseñan según éstos y los implementan mediante iteraciones coordinadas. 3.1.6 Distribución de requerimientos. La mayor parte de las organizaciones de desarrollo considera las pruebas una necesidad absoluta. 1. 2.5 Panorama. La ventaja del estándar IEEE es que abarca la mayor parte de los aspectos que deben 1.1.3Interfaces de hardware.5 Suposiciones y dependencias. Un requerimiento defectuoso (es decir. 2.2 Alcance 1.4Interfaces de software.1.1. ¿Quién rechazaría una inversión de $100 que garantiza un pago de $2000 a $5000 en un año o en dos? Piense que cada búsqueda de los defectos en los requerimientos desde el inicio es una inversión de este tipo.1Interfaces del sistema. 1. Dado el gran beneficio de detectar y reparar defectos en la etapa de requerimientos.11 Contenido del estándar IEEE 830-1993: especificación de requerimientos de software.5Interfaces de comunicación. 2.1. 2. 2. Se estima que repararlo es entre 20 y 50 veces más costo si se permite que pase durante todo el proceso de desarrollo. 2. Copyright © 1994 IEEE.1 Propósito. Considere sus defectos sobre las pruebas. 2. El daño que resulta de una mala experiencia del cliente con la aplicación es un factor por completo adicional al gasto involucrado. 4. 2.1. 2. Introducción. 2.1. acrónimos y abreviaturas.

El objetivo de esta negociación es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo. obtención y elaboración determinan los requisitos con el suficiente detalle como para emprender los pasos subsecuentes de la ingeniería de software. lo más seguro es que se negara. “un acuerdo es el arte de dividir el pastel de tal forma que cada uno piense que se quedó con la rebanada más grande”.Planificación y Modelado una caja negra con un cable morado.2 Requerimientos para la negociación. ¿realmente sorprende el porcentaje tan grande de proyectos de software que nunca terminan? Un problema más sutil se crea en las organizaciones que escriben los requerimientos para la iteración inicial. y el equipo de software gana al trabajar con presupuestos y límites de tiempo realistas y alcanzables. 1. Las mejores negociaciones son aquellas que buscan un resultado del tipo “ganar-ganar” esto es. (Esto subraya la importancia de la buena organización del documento.) Sin embargo. Cuando se considera la falta de efectividad general de los requerimientos no escritos. el cliente gana al obtener el sistema o producto que satisface la mayoría de sus necesidades. uno rosa y uno naranja que salen de ella. Muchas organizaciones no describen los requerimientos. Esta es la base de todo tipo de contratos. el cliente y el desarrollador entran en un proceso de negociación. En un contexto ideal de la ingeniería de requerimientos. Un beneficio importante del análisis de requerimientos es la comprensión y acuerdo de la aplicación que se construirá. el rendimiento y otras características del sistema o producto frente al costo y el tiempo de colocación en el mercado. gente. En realidad.3. las tareas de inicio. tiempo. y el gran número de requerimientos en cada aplicación real. esto sucede muy rara vez. 2008 2 . construyen con ellos en mente. sin requerimientos no es posible realizar pruebas adecuadas. La razón es que con frecuencia es más difícil actualizar un documento de requerimientos que escribir la primera versión. en el cual se le debe pedir al cliente un balance de la funcionalidad. y le pidiera que lo probara. junto con la realidad de la rotación de personal. Probarla será imposible ¡sin saber qué se supone que debe lograr! En otras palabras. pero no actualizan el documento de requerimientos en las interacciones que siguen. Esto no significa que no los usen –sólo quiere decir que los requerimientos existen en la mente de ciertos ingenieros de software—. la situación de que sea más difícil actualizar no altera el hecho de que no escribir los requerimientos ocasionará un alto grado de dificultad. Desgraciadamente. presupuesto) a las que está sometido el equipo de software.

cambiarlos persiste durante la vida se debe de tomar una que el deseo de 5. La consideración de las siguientes directrices puede resultar muy valiosa: 1. los cuales tienen cientos de requerimientos identificables. Si se quieren evitar los conflictos no Enfocarse en se estableció otra los requerimientos para los sistemas de computadora cambian yposición inflexible. Cuando existen situaciones de estancamiento no se debe tener requerimientos y los cambioscánones. 2.Planificación y Modelado Bohem define un conjunto de actividades de negociación en el inicio de cada iteración del proceso del software. 3.pactar. Estar listo para necesario esperar: se debe pactar dicho convenio y seguir adelante. Losque se vuelva personal. el cual se convierte en el criterio clave para continuar con las actividades subsecuentes de la ingeniería de software. 3. Las dos partes tendrán que haber llegado a un acuerdo. se definen las siguientes actividades: 2008 1. controlar y rastrear los que ayudan 6. No dejar requerimientos para la gestión es problema que debe ser del sistema. La conclusión exitosa de estos pasos iníciales asegura un resultado del tipo ganar-ganar. 1. Requerimientos para la se debe pensar en formular una respuesta Escuchar de manera activa. Una vez que se ha llegado a un acuerdo. al equipo de proyecto a identificar. que es lo que la otra parte quiere alcanzar. En lugar de la actividad sencilla de comunicación con el cliente. Diseñar una estrategia. Para ser exitoso. Decidir qué es lo que se desearía lograr. no gestión. Identificación de los interesados calve en el sistema o subsistema. ambos lados deben de tener el sentimiento de haber ganado o logrado algo. no es 7. temas anterioreslos intereses de que parte. Enfocarse en el un conjunto de actividades resuelto. 2. 2 . Es necesario escuchar es posible que se obtenga un conocimiento que ayudará a negociar de mejor manera la posición propia. El arte de la negociación. Ser creativo. Muchas de estas actividades son idénticas a las actividades de la gestión de la configuración del software (GCS). y qué es lo que se va a hacer para que ambas cosas sucedan. El aprendizaje del arte de la negociación efectiva es una actividad que sirve a través de la vida técnica y personal. En los proyectos pequeños esta función de la ingeniería de requerimientos es bastante menos formal. Nota: formalmente la recopilación de los requerimientos para la gestión se inicia sólo para proyectos grandes.4 mientras la otra parte está hablando. Determinación de las “Condiciones ganadoras” de los interesados. Negociación de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados (incluido el equipo de software). En 4. en cualquier momento mientras se a éstos miedo de pensar fuera de los desarrolla el proyecto. Reconocer que no es una competencia.

y puede haber una nueva legislación y regulaciones que deben ser implementadas en el sistema. El entorno de negocios y técnico del sistema cambia después de la instalación. inevitablemente surgen nuevos requerimientos. Esto puede estar en conflicto con los requerimientos de los usuarios finales y. Los clientes del sistema imponen requerimientos debido a las restricciones organizacionales y de presupuesto. Las personas que pagan por el sistema y los usuarios de éste raramente son la misma persona. Los requerimientos finales del sistema son inevitablemente un compromiso entre ellos. puede ser necesario que el sistema interactúe con otros sistemas. Normalmente. los sistemas grandes tienen una comunidad de usuarios diversa donde los usuarios tienen diversos requerimientos y prioridades. descubren nuevas necesidades y prioridades: 1. una vez que un sistema se ha instalado. las prioridades de negocio pueden cambiar con modificaciones consecuentes en la ayuda del sistema. 2008 2 .Planificación y Modelado Durante el proceso del software. Es difícil para los usuarios y clientes del sistema anticipar qué efecto tendrá el sistema nuevo en la organización. Es necesario mantenerse al tanto de los requerimientos particulares y mantener vínculos entre los requerimientos dependientes de forma que pueda evaluar el impacto de los cambios en los requerimientos. 2. Además. Cuando los usuarios finales tienen experiencia con un sistema. El proceso de gestión de requerimientos debería empezar en cuanto esté disponible una versión preliminar del documento de requerimientos. después de la entrega. y estos cambios se deben reflejar en el sistema. 3. pero se debería empezar a planificar cómo gestionar los requerimientos que cambian durante el proceso de obtención de requerimientos. Hay que establecer un proceso formal para implementar las propuestas de cambios y vincular éstos a los requerimientos del sistema. La gestión de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema. Se puede introducir nuevo hardware. Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante del problema. pueden tener que añadirse nuevas características de apoyo al usuario si el sistema tiene que cumplir su objetivo. la comprensión del problema por parte de los stakeholders está cambiando constantemente.

13. Harker y otros han indicado que los requerimientos volátiles se dividen en 5 clases. el entorno del sistema y los objetivos del negocio cambian. Estos requerimientos se pueden derivar de los modelos del dominio que muestran las entidades y relaciones que caracterizan un dominio de aplicación. Requerimientos volátiles.12 evolución de los requerimientos Desde una perspectiva evolutiva. los objetivos del negocio y otros sistemas de la organización. Utilizando estas como base. Un ejemplo serían los requerimientos resultantes de las políticas gubernamentales sobre la sanidad. Además. Conforme se van desarrollando la definición de los requerimientos.12). médicos. El desarrollo de requerimientos software centra su atención en las capacidades de este. normalmente tiene una mejor comprensión de las necesidades de los usuarios. en el hospital siempre habrá requerimientos que se refieren a los pacientes. Por ejemplo. 2. Requerimientos duraderos. Figura 1. Durante ese tiempo. Esto retroalimenta la información del usuario. y los requerimientos evolucionan para reflejar esto. enfermeras y tratamientos.Planificación y Modelado 1. 2 2008 .1 Requerimientos duraderos y volátiles La evolución durante el proceso de ingeniería de requerimientos y después de que un sistema esté en uso es inevitable.4. se ha desarrollado la clasificación mostrada en la figura 1. Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o después de que este se haya puesto en funcionamiento. los requerimientos se dividen en dos clases: 1. quien puede entonces posponer un cambio en los requerimientos (figura 1. Son requerimientos relativamente estables que se derivan de la actividad principal de la organización y que están relacionados directamente con el dominio del sistema. especificar y desarrollar un sistema grande puede llevar varios años.

2Planificación de la gestión de requerimientos. los requerimientos de compatibilidad del sistema encargado o entregado también pueden cambiar. Para cada proyecto la etapa de planificación establece el nivel de detalle necesario en la gestión de requerimientos. La planificación es una primera etapa esencial del proceso de gestión de requerimientos.13 clasificación de los requerimientos volátiles. en los sistemas hospitalarios. 2 2008 .Planificación y Modelado Requerimientos cambiarios Requerimientos que cambian debido a los cambios en el entorno en el que opera la organización. Requerimientos emergentes Requerimientos consecuentes Requerimientos de compatibilidad Figura 1. 1. La identificación de requerimientos. Requerimientos que son resultado de la introducción del sistema informático. La cual tiene un coste elevado. Cuando estos últimos cambian. el pago del cuidado del paciente puede cambiar y así requerir un tratamiento diferente la información a recopilar. Esta introducción puede cambiar los procesos de la organización y desarrollar nuevas formas de trabajar que generan nuevos requerimientos del sistema. Cada requerimiento se debe identificar de forma única de tal forma que puedan ser remitidos por otros requerimientos de manera que pueda utilizarse en las evaluaciones de rastreo. Por ejemplo. Durante la etapa de gestión de requerimientos. Requerimientos que emergen al incrementarse la comprensión del cliente en el desarrollo del sistema. El proceso de diseño puede revelar requerimientos emergentes nuevos. Requerimientos que dependen de sistemas particulares o procesos de negocios dentro de la organización. habrá que decidir sobre: 1.4.

Este es conjunto de actividades que evalúan el impacto y coste de los cambios. Ayuda de herramientas CASE. La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada. Coste de hacer un cambio se estima en términos de modificaciones al documento de requerimientos y. Si se requiere de forma urgente un cambio en los requerimientos del sistema. Análisis del problema y especificación del cambio. al diseño e implementación del sistema. y entre éstos y el diseño del sistema que se debe registrar y la manera en que estos registros se deben mantener. algunas veces. Políticas de rastreo. 1. Esta política define las relaciones entre los requerimientos. Durante esta etapa. 2 2008 . si es apropiado. Debe organizar el documento de requerimientos de modo que pueda hacer cambios en el sin tener que hacer grandes reorganizaciones o redactar nuevamente gran cantidad del mismo. 3. Se modifica el documento de requerimientos y. Existen 3 etapas principales en un proceso de gestión de cambio: 1.3 Gestión de cambio de los requerimientos Se debe aplicar a todos los cambios propuestos en los requerimientos. 3. Implementación del cambio. 2. el problema o la propuesta de cambio se analizan para verificar que esta es válida. Las herramientas que se pueden utilizar van desde sistemas de gestión de requerimientos especializados hasta hojas de cálculo y sistemas sencillos de bases de datos. existe siempre la tentación de hacer ese cambio al sistema y entonces modificar de forma retrospectiva el documento de requerimientos. La gestión de requerimientos comprende el procesamiento de grandes cantidades de información sobre los requerimientos. en su caso el diseño e implementación del sistema. Un proceso de gestión del cambio. El proceso empieza con la identificación de un problema en los requerimientos o. Análisis del cambio y cálculo de costes. con una propuesta de cambio específica. El efecto de un cambio propuesto se valora utilizando la información de rastreo y el conocimiento general de los requerimientos del sistema.4. 4.Planificación y Modelado 2.

pero la mala llevara al fracaso del proyecto. Unidad 2 Planificación del sistema La planeación de proyectos de software es una parte esencial de la ingeniería del software.Planificación y Modelado Esto conduce casi inevitablemente a que la especificación de requerimientos y la implementación del sistema se desfasen. preparado al inicio de un proyecto.1: Plan Plan de calidad Descripción Describe los procedimientos y estándares de calidad 2 2008 . para llevar a cabo mejor el sistema y tener un control sobre el trabajo algunos de estos planes se muestran en la figura 2. Este evolucionara conforme el proyecto progrese y la información disponible será mejor. El administrador del proyecto debe anticiparse a los problemas que podrían surgir. Este plan inicial debe ser el mejor posible de acuerdo con la información disponible. La administración efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. debe utilizarse como un conductor para el proyecto. La buena gestión no puede garantizar el éxito del proyecto. así como preparar soluciones tentativas a esos problemas. Los administradores tienen que preparar planes de trabajo. Un plan.

Planificación y Modelado que se utilizaran en un proyecto. 2 . Los gestores de software hacen el mismo trabajo que otros gestores. En algunas organizaciones. Figura 2. el estudio de la viabilidad. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estándares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto. los recursos y la programación utilizados para la validación del sistema. La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones organizacionales de tiempo y presupuesto. Plan de validación Describe el enfoque. El trabajo del gestor de proyectos de software es asegurar que estos cumplan dichas restricciones y entregar software que contribuya a las metas de la compañía de desarrollo de software. los costos de mantenimiento y el esfuerzo requerido. 2008 Plan de la Describe los procedimientos de administración de la administración de configuración y las estructuras a utilizarse. pero son proporcionados por separado. Los gestores de software son responsables de la planificación y temporalización del desarrollo de los proyectos. divide el trabajo y crea un calendario de trabajo. la planificación de la documentación. lo que hace la gestión de software particularmente difícil. la evaluación de costos. entre otros temas. el plan del proyecto es un único documento que incluye todos los diferentes tipos de planes mencionados anteriormente en la tabla. es necesario abordar temas como la planificación del tiempo. Plan de proyecto Este plan fija los recursos disponibles. La gestión de proyectos de software es un tema amplio y no puede tratarse en un solo tema. Sin embargo. en otros casos solo se refiere al proceso de desarrollo y en otros puede estar referenciado.1 planes de trabajo. Plan de desarrollo Describe cómo se desarrollan las habilidades y personal experiencia de los miembros del equipo del proyecto. la ingeniería del software es diferente en varios aspectos a otros tipos. la configuración Plan mantenimiento de Predice los requerimientos de mantenimiento del sistema.

Debe utilizarse una organización documental que permita reemplazar fácilmente las secciones. División del trabajo: describe la división del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad Programa del proyecto: describe las dependencias entre actividades. se deben incluir los estimados de los precios y las fechas de entrega. la gente involucrada y sus tareas en el equipo. Organización del proyecto: describe la forma en que el equipo de desarrollo de desarrollo está organizado. aunque pueden variar un poco según el tipo de proyecto o el lugar en que se quiera aplicar: 2008 • • Introducción: describe brevemente los objetivos del proyecto y expone las restricciones que afectan la administración del proyecto.Planificación y Modelado La estructura general de cualquier plan lleva los siguientes puntos. el tiempo estimado requerido para alcanzar cada hito y la asignación de la gente a las actividades. así como los mecanismos de supervisión del proyecto a utilizar. Mecanismos de supervisión e informe: describe la administración de informes y cuando deben producirse. Análisis de riesgo: describe los posibles riesgos del proyecto. en caso de existir un proyecto previo parecido. Requerimientos de recursos de hardware y software: describe el hardware y la ayuda de software requerida para llevar a cabo el desarrollo. se puede tomar como base su planificación adaptándola al 2 . 2. la probabilidad de que surjan estos riesgos y las estrategias de reducción de riesgos propuestas. La planificación es una parte muy demandante para los administradores de software.1 Planificación del tiempo. Algunas partes. ya que deben estimar el tiempo y los recursos para completar y programar las actividades en forma coherente. como el calendario del proyecto. • • • • • El plan de proyecto debe revisarse regularmente durante el proyecto. Si es necesario comprar hardware. cambiaran frecuentemente. otras serán más estables.

cada actividad debe durar por lo menos una semana.2). el calendario del proyecto se representa como un conjunto de gráficos que muestran la división del trabajo. se debe separar en actividades complementarias y considerar el tiempo para llevar acabo dichas actividades (figura 2. las dependencias de las actividades y la asignación del personal. y como máximo de 8 a 10 semanas. por lo que se llevara más tiempo del estimado inicialmente. las herramientas de administración 2 2008 . las estimaciones iníciales de tiempo pueden variar con las estimaciones finales.2 actividades complementarias de un proyecto. aunque esto se complica cuando el nuevo proyecto utiliza métodos de diseño y lenguajes de implementación diferentes. por lo que es recomendable ir actualizando la calendarización mediante se vaya progresando en dicho proyecto. se debe asignar personal para cada actividad a fin de que la persona que calendarizo pueda coordinarlas y evitar el atraso del proyecto. En la elaboración de la calendarización. Identificar actividades Identificar dependencias de actividades Estimar recursos para las actividades Asignar personas a las actividades Crear gráficos de proyecto Requerimient os de software Figura 2. se deben hacer mas subdivisiones. entonces se debe incrementar esta estimación para problemas no previstos. Un método es estimar como si no saliera nada mal. este aumento será a partir del tipo de proyecto. ya que pueden pasar distintas fallas o pudieran ser más complicadas. los administradores deben contemplar que cada etapa puede tener problemas. Por lo general. ya que durante el proceso pueden salir imprevistos que pueden ir retrasando el proyecto. Cabe destacar que algunas de dichas actividades complementarias pueden llevarse simultáneamente o paralelamente. de los parámetros y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. Si el proyecto es técnicamente complejo.Planificación y Modelado nuevo proyecto. si se estima más tiempo. Redes de actividades y gráficos de Normalmente. Para calendarizar el proyecto.

las cualesM6 representadas son M4 por la tabla de la figura 2. así como las que no tienen dependencia:7 por ejemplo. Duración (días) 8 15 15 10 10 5 20 25 15 15 7 15 días Dependencias T1 (M1) T2.1. Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 14/7/ 99 días Figura 2. la figura 2. se puede realizar una red de O M3 actividades. Los gráficos de barra y las redes de actividades son notaciones graficas que se utilizan para ilustrar la calendarización del proyecto. Dadas las dependencias y 1 INICI la duración estimada de las actividades. Los gráficos de barras muestran quien es responsable de cada actividad y cuando se debe comenzar y finalizar ésta. como Microsoft Project. es necesario llevar a cabo la actividad T1. ambos se generan automáticamente a partir de una base de datos de la información del proyecto utilizando una herramienta de administración de proyectos. así 9 T1 T6 25/7/99 como T2 se puede realizar de manera paralela a T1. T4 (M2) T1. las redes de actividades muestran las dependencias entre las diferentes actividades que conforman un proyecto.4 ilustra esto: días M8 T7 11/8/9 15 días T2 25/7/9 10 9 10 días 9 M7 10 días días 15 T1 T4 días M2 T5 2 T1 8 Se días considera M5 T8 FINA L 2 18/7/9 9 25 días 0 2008 . se utilizan para automatizar la producción de diagramas. T2 (M3) T1 (M1) T4 (M5) T3. 5/9/99 20 días 15 ya sea dependientes o paralelas unas de otras. 2. esta tabla nos enseña que actividades son 5 días días dependientes de otras. T7 (M7) T9 (M6) T9 T11 (M8) 25/8/9 9 T12 10 T3 4/8/99 M1 un conjunto de actividades. la cual muestra la sucesión de actividades que deben generarse. T6 (M4) T5. T1 4/7/9 para llevar a cabo la actividad T3.3 anterior.3 tabla de actividades.1 Gráficos de barras y redes de actividades.Planificación y Modelado de software.

El tiempo total se calcula en base a la trayectoria más larga de la red. también otra característica. Los gráficos de proyecto (figura 2.5) es otra manera de representar la información del calendario. Las actividades se representan con rectángulos.4 red de actividades. una actividad comienza cuando su hito precedente ha sido alcanzado. que es de 11 semanas o 55 días laborales. 2 2008 . en este caso esta remarcada la trayectoria más larga. Algunas de las actividades que se muestran son seguidas por una barra sombreada cuya longitud es calculada por una herramienta de calendarización. la red se debe lee de izquierda a derecha y de arriba hacia abajo. Cualquier aplazamiento en la trayectoria crítica provoca el retraso en el proyecto. es que antes de que pueda pasar de un hito a otro. los hitos y los productos a entregar por el proyecto se muestran con esquinas redondeadas. Todas las actividades deben terminar en hitos.Planificación y Modelado 19/9/9 Figura 2. es un grafico de barras que muestra el calendario y las fechas iníciales y finales de las actividades. Esto muestra que existe alguna flexibilidad en las fechas de terminación de estas actividades. todas las trayectorias deben completarse.

2 2008 .Planificación y Modelado Figura 2.5 ejemplo gráfica de proyecto.

calentar e iluminar las oficinas los costos de personal de apoyo como los contadores. Por lo tanto. incluyendo el mantenimiento los costos de viajes y capacitación los costos de esfuerzo (los costos de pago a los ingenieros de software 2008 En muchos proyectos. el costo dominante es el costo de esfuerzo. Sin embargo. son relativamente bajos para muchos proyectos. Estas pueden ser solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar. Los costos de esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. Si el gasto real es significativamente más grande que las estimaciones. secretarias. correos electrónicos y teleconferencias reduce los viajes requeridos. en las primeras etapas del proyecto se requieren algunas estimaciones de costos. los siguientes costos son parte de los costos de esfuerzo totales: • • los costos de proveer. Existen tres parámetros involucrados en el cálculo del costo total de un proyecto de desarrollo de software: • • • los costos de hardware y software. entonces el administrador del proyecto debe tomar algunas acciones. Las organizaciones calculan los costos de esfuerzos en términos de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organización y dividen este entre el número de personas productivas. La estimación y la calendarización del proyecto se llevan a cabo de forma conjunta. esto ayuda al proceso de planeación y permite la utilización efectiva de los recursos. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente. el uso de fax. limpiadores y técnicos 2 . antes de que se tenga la calendarización detallada.Planificación y Modelado 2. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos. Una vez que el proyecto se encamina. las estimaciones se actualizan de forma regular. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas.2 Evaluación del costo beneficio.

Una buena manera de enfocar la estimación de costos del proyecto durante las primeras etapas es desarrollar estimaciones de varias maneras independientes y después combinar los resultados. la rigidez absoluta en el costo no siempre se adopta. existen muchas soluciones diferentes con distintos atributos. Incluso se pueden ponderar las estimaciones obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas. 2008 Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud. Cuando se producen soluciones con diferentes atributos. El costo de un proyecto es de interés continuo y vital para los coparticipes. Por lo general. incluso el sistema más fantástico puede ser un desastre.2. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes para cumplir con un costo predeterminado. más preciso será el costo. Con el precio de producción equivocado. pero siempre existe la necesidad de estimar por lo menos un intervalo burdo a partir de un resumen de requerimientos para el producto y mas diseño se realice.1 Productividad. Sin embargo.Planificación y Modelado • • los costos de las redes y las comunicaciones los costos de los recursos centralizados como las bibliotecas. para cualquier problema de software. sin duda deben esperar. sin permitir desviaciones en ninguna circunstancia. 2. Si la estimación del costo se puede posponer hasta que el proyecto tome forma. no tiene sentido comparar estas tasas de producción. los recursos recreativos. los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software. Existen dos tipos de medidas utilizadas: 2 . Sin embargo. etc. estas estimaciones de productividad se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Estas estimaciones son necesarias para la estimación del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivos. Una solución podía ejecutarse de forma más eficiente mientras que otra podría ser más legible y fácil de mantener. tal vez el equipo tenga solo una idea vaga de su costo. La productividad en un sistema de manufactura se mide contando el número de unidades que se producen y dividiendo éste entre el número de personashora requeridas para producirlas. La estimación de costo más sencilla es la que proporciona un costo fijo desde el principio. Cuando se inicia un proyecto. El proceso de estimar costos con frecuencia comienza desde la concepción del proyecto y continúa aun después de iniciada la codificación.

Probablemente no se conozcan las personas involucradas en el proyecto y sus habilidades. Esta se calcula contando el número total de líneas del código fuente que se entrega.Planificación y Modelado Medidas relacionadas con el tamaño: estas se relacionan con el tamaño de alguna salida de una actividad. A pesar de esto. Para hacerlo. Los puntos de función y los puntos de objeto son las medidas más conocidas de este tipo. Los costos reales tendrían que compararse con los estimados del proyecto. Todos estos factores significan que en una primera etapa del proyecto es difícil producir una estimación precisa de los costos de desarrollo del sistema. Medidas relacionadas con la función: estas se relacionan con la funcionalidad total del software entregado. Por lo tanto. La mediad más común relacionada con el tamaño son las líneas de código fuente entregadas. La estimación se utiliza para definir el presupuesto del proyecto y el producto se ajusta para que las cifras del presupuesto se cumplan. las organizaciones necesitan hacer esfuerzos de software y estimaciones de los costos. Por lo general.6: Técnica Modelado Descripción Se desarrolla un modelo utilizando información histórica de 2 2008 . este tiempo incluye el tiempo requerido para el análisis y diseño. Otras medidas que se utilizan son el numero de instrucciones de código objeto entregado o el número de páginas de la documentación del sistema. Existe una dificultad para valorar la precisión de los diferentes enfoques de las técnicas de estimación de costos. No existe una forma simple de hacer una estimación precisa del esfuerzo requerido para desarrollar un sistema de software.2 Técnicas de estimación. Las estimaciones iníciales se hacen bajo la base de la definición de requerimientos de usuario de alto nivel. La cuenta se divide entre el tiempo total de programadores-mes requeridos para completar el proyecto.2. La productividad se expresa en términos de la cantidad de funcionalidad útil producida en un tiempo dado. No se conocen informes de experimentos controlados sobre los costos de los proyectos donde los costos estimados no se utilicen para ajustar el experimento. codificación. se utilizan una o más de las técnicas descritas en el cuadro de la figura 2. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologías de desarrollo. 2. Un experimento controlado no revelaría la estimación del costo al administrador del proyecto. las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. pruebas y documentación. Las líneas de código fuente por programador-mes son una métrica ampliamente utilizada en la medida de la productividad.

Asignar precios para ganar El costo del software se estima independientemente de lo que el cliente está dispuesto a pagar por el proyecto. Estimación por analogía Esta técnica es aplicable cuando otros proyectos en el mismo dominio de la aplicación se han completado.Planificación y Modelado del algoritmo de costos costos que relaciona alguna métrica de software con el costo del proyecto. Figura 2. Se debe buscar más información y repetir el proceso hasta que la estimación converja. el esfuerzo requerido se estima en 60 personasmes.6 técnicas de esfuerzos de software y estimaciones de costos. Se hace una estimación de esa métrica y el modelo predice el esfuerzo requerido. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software. El costo se determina por los recursos disponibles más que por los objetivos logrados. esto indica que no se tiene suficiente información para generar los costos. Myers (1989) da una descripción muy clara de este enfoque. Cada uno de ellos estima el costo del proyecto. se deben utilizar varias técnicas de estimación de costos y comparar sus resultados. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados. Cada técnica de estimación tiene sus propias fortalezas y debilidades. Ley de Parkinson La ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. Para proyectos grandes. Estas estimaciones se comparan y discuten. El proceso de estimación se itera hasta que se acuerda una estimación. 2 . 2008 Opinión de expertos Se consultan varios expertos en las técnicas de desarrollo de software propuestas y en el dominio de la aplicación. Si estos predicen costos radicalmente diferentes. Si el software se tiene que entregar en 12 meses y se dispone de 5 personas.

A es un factor constante que depende de las practicas organizacionales locales y del tipo de software que se desarrolla. se puede generar una estimación razonable de la amplitud de la funcionalidad del sistema a desarrollar. El enfoque más sistemático. M es un multiplicador generado al combinar diferentes procesos. Kitchenham (1990) describe 13 modelos algorítmicos de costos desarrollados a partir de observaciones empíricas. 2 2008 .2. Puesto que el tamaño del software crece. Se utiliza una fórmula matemática para predecir los costos basados en estimaciones del tamaño del proyecto. En su forma más general. El valor del exponente B por lo general se encuentra entre 1 y 1. aunque no necesariamente el más preciso. los proyectos grandes de ingeniería de sistemas normalmente tendrán tal documento de requerimientos. Por lo tanto. Todos los modelos algorítmicos padecen las mismas dificultades básicas: A menudo es difícil estimar el Tamaño en una primera etapa de un proyecto donde solamente está disponible la especificación. Esto refleja el hecho de que los costos normalmente no se incrementen linealmente con el tamaño del proyecto. Tamaño es una valoración del tamaño del código del software o una estimación de la funcionalidad expresada en puntos de funciones o de objetos. Un modelo algorítmico de costos se construye analizando los costos y atributos de los proyectos realizados. la plataforma de desarrollo. etc. En general. numero de programadores y otros factores de los procesos y productos. También se incluye multiplicadores que reflejan los atributos de los productos a desarrollar. Refleja el esfuerzo requerido para proyectos grandes.3 Modelo algorítmico de costos. atributos del producto y del desarrollo. Las estimaciones de los puntos de función y los puntos de objeto son más fáciles de producir que las del tamaño del código pero pueden ser imprecisas. se incurre en costos extra como sobrecarga de comunicaciones de equipos grandes. para la estimación del software es la estimación algorítmica de costos. integración más difícil del sistema. administración más compleja de la configuración. una estimación algorítmica de costos para el software se expresa como: Esfuerzo= A x TamañoB x M En la formula. Muchos de los modelos de estimación algorítmica tienen un componente exponencial. el proceso y los desarrolladores del software.Planificación y Modelado Estas técnicas de estimación son aplicables cuando existe un documento de requerimientos para el sistema. Este define a todos los usuarios y los requerimientos del sistema.5. 2.

Este estudio está orientado a resolver varias cuestiones: • • ¿Contribuye el sistema a los objetivos generales de la organización? ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de coste y tiempo? 2 2008 .3 Estudio de viabilidad. la de los valores del tamaño de los componentes del sistema y la utilización de un componente de referencia conocido para estimar el tamaño de los componentes. dependiendo de su conocimiento y experiencia. Las estimaciones varían de una persona a otra. la entrada de este es un conjunto de requerimientos de negocio preliminares.Planificación y Modelado Las estimaciones de los factores B y M son subjetivas. La estimación del tamaño puede comprender la estimación por analogía con otros proyectos. una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. 2. Este estudio es con el que debe empezar el proceso de ingeniería de requerimientos. El número de líneas de código fuente en un sistema terminado es la métrica básica utilizada en muchos de los modelos algorítmicos de costos. la de convertir los puntos de función al tamaño del código. o simplemente puede ser una cuestión de juicio de ingeniería. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pea seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.

la motivación para conocerlo. En el informe. Para hacerlo. sería lo mismo que le pidieran aprender. Dada la complejidad potencial involucrada. un 2 2008 Llevar a cabo un estudio de viabilidad comprende la evaluación y recopilación de la información y la redacción de informes.Planificación y Modelado • ¿Puede integrarse el sistema con otros sistemas existentes en la organización? En este tipo de estudio. La fase de evaluación de la información identifica la información requerida para contestar las preguntas anteriores. Debería hacerse una recomendación sobre si debe continuar o no con el desarrollo del sistema. Normalmente. La documentación es la sangre que alimenta la ingeniería de software. un aspecto de la patología sanguínea. se debería intentar completar un estudio de viabilidad en2 o 3 semanas. se debería hablar con las fuentes de información para descubrir las respuestas a estas preguntas. por ejemplo.4 Planificación de la documentación. al igual que la documentación asociada con él. querría un panorama global del tema. imagine que le piden participar en un proyecto de software que ya está en marcha. Una vez que se tiene la información. Esto incluye la documentación separada del código. los expertos en tecnología y los usuarios finales del sistema. . se pueden proponer cambios en el alcance. 2. el presupuesto y la confección de agendas del sistema y sugerir requerimientos adicionales de alto nivel para éste. como los jefes de los departamentos donde se utilizara el sistema. Para entender la importancia de la documentación integral. los ingenieros de software que están familiarizados con el tipo de sistema propuesto. se puede consultar las fuentes de información. Una vez que dicha información se ha identificado. se redacta el informe del estudio de viabilidad.

En algunos casos. La figura 2.4.1 El documento de requerimientos del software. La diversidad de posibles usuarios significa que el documento de requerimientos tiene que presentar un equilibrio entre la comunicación de los requerimientos a los clientes. Las omisiones o contradicciones harían difícil o imposible entender que sucede. hasta los ingenieros responsables de desarrollar el software. diagramas con las interrelaciones. los dos tipos de requerimientos se pueden integrar en una única descripción. los requerimientos del usuario se definen en una introducción a la especificación de los requerimientos del sistema. la definición de los requerimientos en el detalle exacto para los desarrolladores y probadores. 2. los detalles de los requerimientos del sistema se pueden presentar en un documento separado.7 tomada del libro sobre ingeniería de requerimientos de Gerald Kotonya e Ian Sommerville. Debe incluir tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. entre otros.Planificación y Modelado flujo ordenado desde el panorama general hasta los detalles. Cuando del sistema se desarrolle por un contratista externo. y la inclusión de la información sobre la posible evolución del sistema. 2008 2 . el documento de requerimientos puede ser mucho menos detallado y cualquier ambigüedad resuelta durante el desarrollo del sistema. El documento de requerimientos del software (algunas veces denominado especificación de requerimientos del software o SRS) es la declaración oficial de qué deben implementar los desarrolladores del sistema. Si existe un gran número de requerimientos. Cuando haya más flexibilidad en los requerimientos y cuando se utilice un proceso de desarrollo iterativo dentro de la empresa. El nivel de detalle se debe incluir en un documento de requerimientos depende del tipo de sistema que se desarrolle y del proceso de desarrollo utilizado. En otros. numerosas notas acerca de implementaciones específicas. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organización que pagan por el sistema. ilustra los posibles usuarios del documento y como lo utilizan. quienes tienen que adaptar el sistema a los nuevos requerimientos. La información sobre cambios previstos puede ayudar a los diseñadores del sistema a evitar decisiones de diseño restrictivas y a los ingenieros encargados del mantenimiento del sistema. las especificaciones de los sistemas críticos necesitan ser claras y muy detalladas.

El estándar más ampliamente conocido es el IEEE/ANSI 830-1998. Este estándar IEEE sugiere la siguiente estructura para los documentos de requerimientos: 2 2008 . ha definido estándares para los documentos requeridos. como el Departamentos de Defensa de los Estados Unidos y el IEEE. Varias organizaciones grandes.7 usuarios del documento de requerimientos.Planificación y Modelado Figura 2. Davis analiza algunos de estos estándares y compara sus contenidos.

las actividades de CGS sirven para: • Identificar el cambio de nuestro software. facilitando el resto de procesos de producción. Durante el proceso de construcción de un software. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.Planificación y Modelado 2. organizar y controlar las modificaciones que sufre el software la meta es maximizar la productividad minimizando errores. Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados. sobre todo cuando no se han analizado o pronosticado correctamente. El arte de coordinar el desarrollo de software para minimizarla confusión. Los cambios provocan confusión e incertidumbre. los cambios son inevitables.5 Gestión de la configuración del software. ya que posibilita una mejor organización del desarrollo y mantenimiento. La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software. se denomina gestión de la configuración. 2 2008 . producto. La gestión es el arte de identificar.

Líneas base. el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida. Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. 2. La gestión de configuración del software no es un mantenimiento del software.5. la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el software queda fuera de circulación. La primera Ley de la ingeniería de sistemas establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos. en el proceso de ingeniería del software existe una variable importantísima que entra en juego. La IEEE define una línea base como: 2 . La gestión de configuración del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora. • Restricciones presupuestarias o de planificaciones que provocan una redefinición del sistema o del producto. • Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software. La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del proceso de ingeniería del software. el mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo.1. • Garantizar que el cambio quede bien implantado. Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software: Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales.Planificación y Modelado • Controlar ese cambio. 2008 • Informar el cambio. Desgraciadamente. el cambio. • Nuevas necesidades del los clientes que demandan la modificación de los datos producidos por un sistema basado en computadora.

Sin embargo. 2) Disculparse insistentemente. Considere las puertas de la cocina de un gran restaurante. Si un camarero recoge un pedido en la cocina lo coloca en una bandeja y luego se da cuenta de que ha cogido un plato equivocado. Una forma de describir la línea base es mediante una analogía. 3) Volver a la cocina por la puerta de entrada. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado. 4) Explicar el problema etc. pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. si abandona la cocina le da el plato al cliente y luego se le informa de su error. En el contexto de la ingeniería del software definimos una línea base como un punto de referencia en el desarrollo del software y que queda marcado por el envío de uno o más elementos de configuración del software (ECS) y la aprobación de ECS obtenido mediante una revisión técnica formal. debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algún error. el cambio se puede llevar a cabo rápida e informalmente. por una puerta de un solo sentido. Para evitar colisiones una puerta está marcada como SALIDA y la otra como ENTRADA las puertas tienen topes que hacen que solo se puedan abrir en la dirección apropiada. de forma figurada.8 2008 2 . los elementos de una especificación de diseño se documentan y se revisan. puede cambiar el plato correcto rápidamente informalmente antes de salir de la cocina. la especificación de diseño se convierte en línea base. Aunque se puedan definir las líneas base con cualquier nivel de detalle las líneas base más comunes son las que se muestran en la figura 2. pasamos. y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios. Una línea base es análoga a un plato mientras pasa por las puertas de la cocina de un restaurante antes de que un elemento de configuración del software se convierta en línea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificación del diseño) tras haber sido evaluados y aprobados. Por ejemplo. una vez que se establece una línea base. Sé pueden llevar a cabo los cambios.Planificación y Modelado Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo. Sin embargo.

Especificación de requisitos b. un ECS (elemento de configuración de software) es un documento. Plan y procedimiento de pruebas 2 2008 .8 líneas base.Planificación y Modelado Figura 2. Prototipo ejecutable o en papel 4) Manual de usuario preliminar 5) Especificación de diseños a.O) 6) Listados del código fuente 7) a.5. Descripciones de los objetos (si se utilizan técnicas de P.2 Elemento de configuración del software. Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman un conjunto de líneas base: 1) Especificación del sistema 2) Plan de proyecto 3) a. Descripción del diseño de datos b.O. Descripciones del diseño de interfaces e. Descripción del diseño arquitectónico c. un conjunto completo de casos de prueba o un componente de un programa 40 dado. Un elemento de la configuración del software es la información creada como parte del proceso de ingeniería. Descripciones del diseño de los módulos d. 2.

Planificación y Modelado b. 2008 2 . y está conectado a otros objetos mediante relaciones. Casos de prueba y resultados registrados 8) Manuales de operación de y de instalación 9) Programas ejecutables a. Peticiones de mantenimiento c. Esquema y estructura de archivos b. Informes de problemas del software b. código ejecutable b. compiladores y otras herramientas CASE utilizadas durante el desarrollo. Un ECS tiene un nombre y atributos. Módulos. Es decir congelar la versiones de editores. contenido inicial 11) Manual del usuario final 12) Documentos de mantenimiento a. Módulos enlazados 10) Descripción de la base de datos a. un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versión original Los ECS se organizan como objetos de configuración que deben ser catalogados por la base de datos del proyecto con un nombre único. Ordenes de cambios e ingeniería 13) Estándares y procedimientos de ingeniería del software Es importante considerar poner las herramientas de desarrollo de software bajo control de configuración.

4 Identificación de objetos en GCS.5.2. Cada objeto tiene un conjunto de características que los identifican como únicos.9 Objetos configuración La figura 2. diseño. 2.5. codificación o prueba. Sin embargo también se debe identificar los ECS individuales. Un objeto compuesto es una colección de objetos básicos u objetos compuestos.3 El proceso de la configuración del software.Planificación y Modelado Fig.9 se muestra el modelo de datos de los elementos de la configuración. La GCS es un elemento importante de garantía de calidad es responsable de controlar los cambios. cada objeto está relacionado con otro. El nombre del objeto es una 2 2008 . Se pueden identificar dos tipos de objetos los objetos básicos y los objetos compuestos. Un objeto básico es una unidad de texto creada durante el análisis. El proceso se puede definir en cinco tareas de CGS: • Identificación • Control de versiones • Control de cambios • Auditorias de configuración • Generación de informes 2. si se lleva a cabo un cambio sobre un objeto la interrelaciones señalan a que otros objetos afectará.

por lo que cambia el número de versión principal. datos) que está representado por el objeto. 2. "La gestión de configuración permite a un usuario especificar configuraciones alternativas del sistema de software mediante la selección de las versiones adecuadas.10 de evolución se describe la historia del objeto y sus cambios. El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.5. • Un identificador del proyecto. las grandes modificaciones hacen que un objeto cambie. Esto se puede gestionar asociando atributos a cada versión del 2 2008 . y la información de la versión y/o el cambio.Planificación y Modelado cadena de caracteres que identifica al objeto sin ambigüedad. La descripción del objeto es una lista de elementos de datos que identifican: • El tipo de ECS (documento. Figura 2.10 Grafo de evolución. En el grafo de la figura 2. programa.5 Control de versiones.

Otra forma de establecer los conceptos de la relación entre componentes.Planificación y Modelado software y permitiendo luego especificar y construir una configuración describiendo el conjunto de atributos deseado." Los atributos pueden ser tan sencillos como un número específico de versión asociado a cada objeto o tan complejos como una cadena de variables lógicas que especifiquen tipos de cambios funcionales aplicados al sistema. Figura 2. a cada componente se le asigna una tupla de atributos. variantes y versiones es representarlas como un fondo de objetos.11 Versiones y variantes Para construir la variante adecuada de una determinada versión de un programa. A cada variante se le asigna uno o más atributos. 2 2008 .

2 2008 . El control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control de cambio.12 Representación de objetos. el cambio incontrolado lleva rápidamente al caos. componentes. En un gran proyecto de desarrollo de software.Planificación y Modelado Figura 2. 2. variantes y versiones La principal diferencia entre los distintos está en la sofisticación de los atributos que se usan para construir versiones y variantes específicas de un sistema y en la mecánica del proceso de construcción.5.6 Control de cambios.

el objeto es "dado de alta" en la base de datos y se usan los mecanismos de de control de versiones apropiadas (sección 4) para crear la siguiente versión del software. Los resultados de la evaluación se presentan como un informe de cambios a la autoridad de control de cambios (ACC). La OCI describe el cambio a realizar. Para cada cambio aprobado se genera una orden de cambio de ingeniería (OCI). 2 2008 . El objeto a cambiar es "dado de baja" de la base de datos del proyecto. Luego.Planificación y Modelado Figura 2.13 Proceso de control de cambios. las restricciones que se deben respetar y los criterios de revisión y de auditoría. se realiza el cambio y se aplican las adecuadas actividades de SQA.

se crea la línea base. realizados por personas diferentes. los informes de cambio y las 2 2008 . sólo es necesario aplicar un control de cambios informal. Una vez que el ECS se convierte en una línea base. El que haya desarrollado el ECS en cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos. Para hacer un cambio. Figura 2. no se sobrescriben mutuamente. El control de sincronización asegura que los cambios en paralelo. El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuración concretos. o de la ACC si el cambio impacta en otros ECS. Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobada.Planificación y Modelado Los procedimientos de "alta" y "baja" implementan dos elementos importantes del control de cambios: control de acceso y control de sincronización.14 Control de acceso y de sincronización. el encargado del desarrollo debe recibir la aprobación del gestor del proyecto (si el cambio es local). Antes de que un ECS se convierta en una línea base. se dispensa de generar formalmente las peticiones de cambio. aparece el control de cambios a nivel de proyecto. En algunos casos.

Planificación y Modelado OCI. hay que hacer una evaluación de cada cambio así como un seguimiento y revisión de los mismos. registrarlo y divulgarlo? 2 2008 . La auditoria se plantea y responde con las siguientes preguntas: ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado modificaciones adicionales? ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección técnica? ¿Se han seguido adecuadamente los estándares de ingeniería de software? ¿Se han "recalcado" los cambios en el ECS? ¿Se han especificado la fecha del cambio y el autor? ¿Reflejan los cambios los atributos del objeto de configuración? ¿Se han seguido procedimientos del GCS para señalar el cambio. ¿Cómo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) revisiones técnicas formales 2) auditorias de configuración del software. o sea. ¿Cómo impactará el cambio en el hardware? ¿Cómo impactará en el rendimiento? ¿Cómo alterará el cambio la percepción del cliente sobre el producto? 2. se instituye el control de cambios formal. Los revisores evalúan el ECS para determinar la consistencia con otros ECS.7 Auditoria de la configuración. evaluar el impacto del cambio fuera del ECS en cuestión. las omisiones o los posibles efectos secundarios. La autoridad de control de cambios (ACC) desempeña un papel activo en el segundo y tercer nivel de control. Las revisiones técnicas formales se centran en la corrección técnica del elemento de configuración que ha sido modificado. El papel de la ACC es el de tener una visión general. Sin embargo.5. Una auditoria de configuración del software complementa la revisión técnica formal al comprobar características que generalmente no tiene en cuenta la revisión. Cuando se distribuye el producto de software a los clientes.

2 2008 .5. El IEC ayuda a eliminar esos problemas.Planificación y Modelado ¿Se han actualizado adecuadamente todos los ECS relacionados? 2. La generación de informes de estado de la configuración es una tarea de GCS que responde a las siguientes preguntas: 1) ¿Qué pasó? 2) ¿Quién lo hizo? 3) ¿Cuándo pasó? 4) ¿Que más se vio afectado? La generación de informes de estado de la configuración desempeña un papel vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fácil que no exista una buena comunicación. mejorando la comunicación entre todas las personas involucradas. Pueden darse errores entre las personas desarrolladoras del software.8 Informes de estado.

como la inestabilidad política en un país o una región sensible a terremotos. originados por situaciones concretas que afectan o pueden afectar a parte de una organización o a toda la misma. de infraestructura…) que están expuestos a diferentes tipos de riesgos: los `normales’.1 Análisis de riesgos. En un entorno informático existen una serie de recursos (humanos. y los excepcionales. se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo.Planificación y Modelado Unidad 3 Análisis del proyecto. No existe una forma fácil de hacer esto. tolerables o insignificantes. alto (50-75%) o muy alto (>75%). término que hace referencia al proceso necesario para responder a tres cuestiones básicas sobre nuestra seguridad: • ¿Qué queremos proteger? • ¿Contra quién o qué lo queremos proteger? • ¿Cómo lo queremos proteger? 2 2008 . 3. técnicos. Para tratar de minimizar los efectos de un problema de seguridad se realiza lo que denominamos un análisis de riesgos. moderado (25-50%). serios. No se hace una valoración con números precisos sino en intervalos: La probabilidad del riesgo se puede valorar como muy bajo (<10%). aquellos comunes a cualquier entorno. bajo (10-25%). Durante este proceso. Los efectos del riesgo pueden ser valorados como catastróficos.

una amenaza sería un pirata que queramos o no (no depende de nosotros) va a tratar de modificar nuestra página web principal. Con estos cuatro elementos podemos obtener un indicador cualitativo del nivel de riesgo asociado a un activo determinado dentro de la organización. por definición siempre presentes en cualquier sistema. Se basa en dos parámetros fundamentales: la probabilidad de que un suceso ocurra y una estimación del coste o las pérdidas en caso de que así sea. visto como la probabilidad de que una amenaza se materialice sobre un activo y produzca un determinado impacto. una vulnerabilidad sería una configuración incorrecta del servidor que ofrece las páginas. el impacto sería una medida del daño que causaría si lo lograra. vulnerabilidad grave. El concepto de asumible es diferente al de riesgo asumido. y cualquier riesgo calculado superior al umbral ha de implicar una decisión de reducción de riesgo. ya que ahora no entran en juego probabilidades exactas sino simplemente una estimación de pérdidas potenciales. Si por el contrario el calculado es menor que el umbral.Planificación y Modelado En la práctica existen dos aproximaciones para responder a estas cuestiones. Es mucho más sencillo e intuitivo que el anterior. el impacto asociado a una amenaza. y este riesgo calculado se ha de comparar con un cierto umbral (umbral de riesgo) determinado por la política de seguridad de nuestra organización. que indica los daños sobre un activo por la materialización de dicha amenaza. se habla de riesgo residual. Para ello se interrelacionan cuatro elementos principales: las amenazas. de uso muy difundido en la actualidad especialmente entre las nuevas `consultoras’ de seguridad (aquellas más especializadas en seguridad lógica. que denota aquellos riesgos calculados superiores al umbral 2 2008 . y los controles o salvaguardas. el producto de ambos términos es lo que se denomina coste anual estimado (EAC. Estimated Annual Cost). contramedidas para minimizar las vulnerabilidades (controles preventivos) o el impacto (controles curativos). las vulnerabilidades. tests de penetración y similares). nivel de amenaza alto. cortafuegos.). y aunque teóricamente es posible conocer el riesgo de cualquier evento (el EAC) y tomar decisiones en función de estos datos. el umbral de riesgo puede ser o bien un número o bien una etiqueta de riesgo (por ejemplo. y un control la reconfiguración de dicho servidor o el incremento de su nivel de parcheado. Tenemos por una parte el riesgo calculado. etc. Por ejemplo. resultante de nuestro análisis. La primera de ellas es con diferencia la menos usada. Tras obtener mediante cualquier mecanismo los indicadores de riesgo en nuestra organización llega la hora de evaluarlos para tomar decisiones organizativas acerca de la gestión de nuestra seguridad y sus prioridades. que potencian el efecto de las amenazas. una cuantitativa y otra cualitativa. y el mismo se considera asumible (no hay porqué tomar medidas para reducirlo). ya que en muchos casos implica cálculos complejos o datos difíciles de estimar. impacto alto. en la práctica la inexactitud en la estimación o en el cálculo de parámetros hace difícil y poco realista esta aproximación. El segundo método de análisis de riesgos es el cualitativo.

La combinación de medición y retroalimentación permite 2 . económica…) se decide no tomar medidas de reducción. La calidad de concordancia es el grado en el quelas especificaciones de diseño se aplican durante la fabricación. 3. se refiere a las características que los diseñadores especifican para un elemento. La calidad “es una característica o atributo de algo”. el software. Los riesgos son una amenaza para el proyecto. color. revisiones y pruebas empleadas a lo largo del proceso del software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado. La calidad de concordancia es un tema enfocado principalmente en la implementación. el control de calidad involucra una serie de inspecciones. En el contexto de software se lucha para controlar la variación en el proceso genérico que se aplica y el énfasis de calidad que permea el trabajo de ingeniería del software. El control de la variación es el corazón del control de calidad. la calidad de diseño incluye requisitos. Riesgos del producto: estos afectan a la calidad o al rendimiento del software que se está desarrollando. es más difícil de caracterizar que los objetos físicos. etc. cosas que se pueden comparar para conocer estándares. la calidad se refiere a características mensurables. se puede concebir un riesgo como una probabilidad de que una circunstancia adversa ocurra. 2008 De forma simple. Sin embargo. En el desarrollo de software. siempre hemos de huir de esta situación. como longitud. evidentemente.Planificación y Modelado pero sobre los que por cualquier razón (política. maleabilidad. El control de la variación es la clave para un producto de alta calidad. para el software que se está desarrollando y para la organización. El control de calidad incluye un bucle de retroalimentación con el proceso que creó el producto de trabajo. Como un atributo de un elemento. Riesgos del negocio: estos afectan a la organización que desarrolla o suministra el software. La calidad de diseño. El control de la variación puede equipararse con el control de calidad. especificaciones y el diseño del sistema.2 Control de calidad. principalmente una entidad intelectual. Estas categorías de riesgos se definen como se muestra: • • • Riesgos del proyecto: estos afectan la calendarización o los recursos del proyecto. es decir.

Existen dos enfoques complementarios para el control de la calidad: Revisiones de la calidad en las que el software. Esta valoración automática comprende una medida cuantitativa de algunos atributos del software.Planificación y Modelado afinar el proceso cuando los productos de trabajo creados fracasan en cuanto a satisfacer sus especificaciones. El bucle de retroalimentación es esencial para minimizar los defectos producidos. El cometido del equipo de revisión es detectar los errores e inconsistencias y señalarlas al diseñador o autor del documento. Toman las desviaciones de los estándares y las ponen a consideración de la administración del proyecto. Involucran a un grupo de personas que examinan parte o todo el proceso del software. Las revisiones se basan en documentos pero no se limitan a las especificaciones. Se revisan todos los documentos tales como los modelos de proceso. El control de la calidad implica el proceso de desarrollo de software para asegurar que se sigan los procedimientos de aseguramientos y estándares de calidad. Las revisiones son el método más utilizado para validar la calidad de un proceso o producto. los sistemas o su documentación asociada para descubrir problemas potenciales. Un concepto clave del control de calidad es que todos los productos de trabajo tienen especificaciones definidas mesurables con las cuales se puede comparar la salida de cada proceso. los productos resultantes de un proceso de software se comprueban contra los estándares definidos del proyecto en el proceso de control de calidad. Valoración automática del software en la que el software y los documentos producidos se procesan por algún programa y se comparan con los estándares que aplica a ese proyecto de desarrollo en particular. Son responsables de comprobar que se han seguido los estándares del proyecto y que el software y los documentos están acordes a estos estándares. 2 2008 . diseños o código. su documentación y los procesos utilizados para producir ese software son revisados por un grupo de personas. El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a utilizar durante el desarrollo de software. Estos procedimientos son directos y fácilmente comprensibles por los ingenieros que desarrollan el software. Las conclusiones de la revisión se registran formalmente y se pasan al autor o a quien sea responsable de corregir los problemas descubiertos.

La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Unidad 4 Análisis de los requerimientos.Planificación y Modelado los planes de prueba. los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. En la ingeniería de sistemas. En la ingeniería clásica. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software. un requerimiento es una necesidad documentada sobre el contenido. análisis de consistencia e 2 2008 . pero NO CÓMO hacerlo. Establecen QUÉ debe hacer el sistema. Esta fase puede dividirse en recolección de requerimientos de los inversores. los procedimientos de administración de la configuración. los estándares del proceso y los manuales de usuario. forma o funcionalidad de un producto o servicio.

Los requerimientos deben considerar las restricciones de carácter económico. ya que esto debe ser decidido en la etapa de diseño por los diseñadores. dónde. no sólo las funciones sino también la auditabilidad del sistema. definición en términos descriptivos para los desarrolladores y un esbozo de especificación. la facilidad de uso. cómo y cuándo. el mantenimiento. previo al diseño completo Los requerimientos de información de un nuevo sistema implican la identificación de quién necesita que información. Otros tipos de limitaciones externas. el testeo. En la ingeniería de software se aplica el mismo significado. El análisis de sistemas a menudo hace una contribución no intencional a la institución al aclarar los procedimientos y llegar a un consenso sobre cómo deben hacerse las cosas. Una vez culminada la etapa de requerimientos los revisores independientes revisarán lo efectuado. de calidad. etc. Se omite el cómo debe lograrse su implementación. etc. Algunos ejemplos de aspectos solicitables son la disponibilidad. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto Una colección de requerimientos describe las características o atributos del sistema deseado. Un requerimiento no funcional: de rendimiento. 2 2008 . especifica algo sobre el propio sistema. procedimientos y los procesos de decisiones en la institución. y cómo debe realizar sus funciones. que afectan en una forma indirecta al producto. Para obtener los requerimientos de los sistemas de información. El análisis de requerimientos define los objetivos del sistema nuevo o modificado y desarrolla una descripción detallada de las funciones que debe llevar a cabo el nuevo sistema. Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar. los analistas deben trabajar una y otra vez en enunciados de requerimientos en colaboración con los usuarios.Planificación y Modelado integridad. sólo que el énfasis está puesto en el propio software. En ingeniería de sistemas existen tres tipos de requerimientos. Un mal análisis de requerimientos es una de las causas principales de la falla de los sistemas y de los costos elevados del desarrollo. técnico y de tiempo así como las metas.

los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe de hacer.Planificación y Modelado 4. “la aplicación debe calcular el valor del 2 2008 .1 Requerimientos funcionales y no funcionales. En algunos casos.1 Requerimientos funcionales. de la manera en que éste reaccionara a entradas particulares y de cómo se comportara en situaciones particulares. Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema. Los requerimientos funcionales especifican los servicios que debe proporcionar la aplicación (por ejemplo. 4.1.

Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste proveerá. excepciones. Los requerimientos funcionales para un sistema de software se expresan de diferentes formas.Planificación y Modelado portafolio de inversión del usuario”). Sin embargo. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. un requerimiento como “la aplicación debe terminar el cálculo del valor de cada portafolio en menos de 1 segundo” no es un requerimiento funcional. Algunos de estos requerimientos para un sistema de biblioteca universitario para estudiantes y académicos que solicitan libros y documentos de otras bibliotecas son: El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. Por supuesto. porque no especifica un servicio dado. Dichos requerimientos se toman del documento de requerimientos del usuario para el sistema e ilustran los diferentes niveles de detalle en que se pueden relacionar los requerimientos funcionales (contrastar los requerimientos 1 y 3). La compleción significa que todos los servicios solicitados por el usuario están definidos. En principio. Cuando se expresan como requerimientos del usuario. En su lugar. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema. es posible cumplir los 2008 2 . etc. eso retrasa la entrega de éste e incrementa los costos. Por otro lado. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. La consistencia significa que los requerimientos no tienen definiciones contradictorias. El sistema deberá proveer visores adecuados para que el usuario lea documentos en el almacén de documentos. a menudo no es lo que el cliente desea. Estos son requerimientos funcionales del usuario que definen los recursos específicos que el sistema debe proveer. para sistemas grandes y complejos. A cada pedido se le deberá asignar un identificador único que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. En la práctica. sus entradas y salidas. habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste. califica un servicio o servicios (especifica algo sobre ellos). esto depende del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software.

Incluyen restricciones de tiempo.2 Requerimientos no funcionales. El incumplimiento en un funcional degrada el sistema. Una vez que estos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de la vida. a las políticas de la organización. 2 2008 . etc. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Los requerimientos no funcionales surgen de la necesidad del usuario. una especificación que el diseño debe producir una herramienta CASE particular y una descripción del proceso a seguir. El diagrama muestra una clasificación de los diferentes tipos de requerimientos no funcionales que puede haber.1. los requerimientos no funcionales no siempre se refieren al sistema de software a desarrollar. Algunos de estos requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso. se deben corregir en el documento de requerimientos. debido a las restricciones del presupuesto. Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. estándares. mientras que el fallo en un no funcional. inutilizara el sistema.Planificación y Modelado requerimientos de consistencia y compleción. lo que significa que a menudo son más críticos que los requerimientos funcionales. sobre el proceso de desarrollo. Sin embargo. Los problemas emergen después de un análisis profundo. 4. a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos. Algunos de estos requerimientos restringen el proceso a utilizar en el desarrollo del sistema. Los requerimientos no funcionales son restricciones de los servicios o funciones ofrecidos por el sistema. Estas inconsistencias no son obvias cuando los requerimientos se especifican por primera vez.

la capacidad del sistema para 2 2008 . Algunos ejemplos son los requerimientos de desempeño en la rapidez de ejecución del sistema y cuanta memoria se requiere. Se redactan para reflejar las metas generales del usuario.1 anterior se clasifican de acuerdo con sus implicaciones: Requerimientos del producto: estos especifican el comportamiento del producto. los requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar. Requerimientos organizacionales: se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos ejemplos son los estándares en los procesos que deben utilizarse.Planificación y Modelado Figura 4. los de portabilidad y los de usabilidad. los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable. Un problema común con los requerimientos no funcionales es que algunas veces no se pueden verificar.1 requerimientos funcionales. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general. como la facilidad de uso. los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley. Estos diferentes tipos de requerimientos que se muestran en la figura 4. y los requerimientos de entrega que especifican cuando se entregara el producto y su documentación. Requerimientos externos: este gran apartado cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. y los requerimientos éticos. Estos incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización.

o porque en realidad no era una verdadera necesidad sino simplemente un capricho.Planificación y Modelado recuperarse de las fallas o la respuesta rápida del usuario. 4. la realidad es que hicimos un gasto inútil e innecesario. algunas veces llamados “escenarios” (en UML.2. 4. el requerimiento individual de que una aplicación para una tienda de videos permita introducir el titulo de un nuevo video suele ser parte de una secuencia de transacciones.1 La Administración de requerimientos. y de hecho. Estas son los casos de uso. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a interpretación. Casi siempre.1. una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el éxito que deberían. no obtuvieron el valor que esperaban recibir para su negocio con el software adquirido. Organizarlos de esta manera es útil para producir casos de uso más grandes a partir de los pequeños.2. 2 2008 . Nos pudo haber pasado porque no alcanzó nuestras expectativas. En otras palabras. El proceso unificado de desarrollo de software (USDP) explota la observación de que muchos requerimientos ocurren de manera natural en secuencias operativas. o porque resultó demasiado complicado de utilizar. Sea cual fuera la razón. no es raro encontrarse con empresas que contratan un desarrollo de software sólo para darse cuenta de que desperdiciaron su dinero y su tiempo. 4. lo que provoca discusiones subsecuentes una vez que el sistema se entregue. el caso de uso se escribe de manera informal (un solo párrafo) en primera persona. Una de las razones principales por las cuales se da esta situación. El USDP favorece la organización de los requerimientos por casos de uso.2 Casos de uso.1 Los Casos de uso y el valor del sistema. un “escenario” es en realidad una instancia de un caso de uso). Por ejemplo. y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo similar. A quién no le ha pasado que siente la necesidad de comprar algo sólo para terminar con ese producto en un rincón sin jamás ser utilizado. Cuando se usa como parte del análisis de tareas. se debe a una mala administración de requerimientos. el caso de uso se desarrolla para que muestre la manera en que el usuario final realiza alguna tarea relacionada con el trabajo. Con el software. Pues. pues no obtuvieron lo que ellos esperaban o necesitaban. Esto generalmente se da por falta ya sea de habilidades en el personal responsable o de técnicas apropiadas utilizadas para llevar a cabo esta labor.

de manera que “valga la pena usar el sistema” en dichas situaciones. tal como se haría en una planta manufacturera donde se reciben las especificaciones del producto a construir. “Administrar prospectos”. Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”. cuestionando nada o muy poco. en primer lugar. “Consultar comisiones”.2.2. deberíamos llamarle manufactura de software. Todas ellas son ejemplos de situaciones u objetivos importante que podría necesitar un vendedor para llevar a cabo su trabajo. Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar. Una vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles en qué situaciones valdrá la pena para ellos utilizarlo. documentación. como estándar integrador de las buenas prácticas de desarrollo nos ofrece en este sentido los casos de uso como una técnica excelente para administrar los requerimientos de nuestros proyectos.4 Buscando los beneficios del sistema. Una buena parte de estas personas probablemente vayan a ser usuarios del sistema.1.3 El sistema y su misión. “Registrar pedido”.2. 4. 4. La lista identificada de dichas situaciones no debería de tener pequeñas funciones.2 ¿Consultoría o manufactura? Si queremos realizar una verdadera consultoría de software entonces nos corresponde algo más que escuchar la lista de funciones que el cliente cree que debería de tener su sistema (a menos que nuestro cliente tenga un área con la capacidad de realizar una buena recopilación y análisis de requerimientos). sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio. 2 2008 . 4. en UML los conocemos como Actores (más adelante veremos otros tipos de Actores que también tendremos que identificar). abarca actividades como la recopilación. tal como se muestra en el diagrama de la figura 4. Para lo cual habrá que preguntárselo a las personas que obtendrán alguna clase de beneficio cuando se ponga en operación.Planificación y Modelado La administración de requerimientos. cuál es el valor que el sistema debe proporcionar al negocio.2. validación y control de los requerimientos y sus cambios. de acuerdo a CMM.1. Si nos limitáramos a lo primero entonces en lugar de llamarle consultoría a nuestro trabajo. “Generar factura” y “Administrar clientes”. donde uno implementa las funciones exactamente cómo se las solicita el cliente. conocidas y modeladas como casos de uso en UML.1. UML.

hasta que el objetivo del caso de uso se cumple (el objetivo principal del caso de uso es lo que le da el nombre al mismo).5 Los requerimientos funcionales. primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misión del sistema. y continúa como una serie de eventos o interacciones entre actores y sistema. Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos importantes. ej: Realizar una venta) y después buscamos cuáles son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al utilizar sistema. Normalmente los casos de uso son iniciados por algún actor. Identificar quiénes utilizarán el sistema (actores primarios) 2 2008 . Especificar la misión del sistema 2. Lo que estamos obteniendo así es una especificación de requerimientos funcionales mediante un análisis top-down (de lo general a lo particular). que podría ser tan simple como elegir una opción en el sistema. Lo inicia con algún evento. es decir.2 caso de uso 4.Planificación y Modelado Figura 4. conocido como actor primario.1.2. Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso: 1.

y esto implica que en ocasiones. A diferencia de los actores secundarios. Por experiencia sabemos que.5 Las interfaces del sistema.Planificación y Modelado 3. éstos no son los que inician o requieren del caso de uso. Hay otro tipo de actores que también hay que modelar. es mejor limitarnos a los elementos más básicos. componentes externos o dispositivos con los cuales interactúa nuestro sistema. Identificar los pasos o eventos de cada caso de uso (especificación del caso de uso) 4. De esta forma estamos mostrando las interfaces requeridas con otro sistema en cada momento. Averiguar cuáles objetivos desean cumplir los actores al usar el sistema (casos de uso) 4.1. al llevar a cabo un caso de uso requiere tener algún tipo de interacción con él.2. en cuyo caso aparecerán asociados a los casos de uso durante los cuales tienen que intervenir con algún tipo de interacción con el sistema a modelar. En otras oportunidades veremos elementos adicionales para modelar los casos de uso. el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. ya que facilita el análisis. Suelen ser otros sistemas. pero podemos asegurar que la sencillez es parte importante del modelado. entendimiento y comunicación entre quienes solicitan el sistema y los que participan en su desarrollo. La esencia de los modelos radica en la simplicidad. En el diagrama de casos de uso también suele ser apropiado mostrar a este tipo de actores. en los modelos de UML. sino que nuestro sistema. y sobre todo cuando el analista no tiene tanta experiencia en UML. 2 2008 . Ejemplo de Actor Secundario. Nuestro sistema de ventas podría requerir enviarle información al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. los actores secundarios. En dicha situación el sistema de contabilidad aparecerá como un actor secundario asociado a dicho caso de uso.

Un ingeniero de software diseña la interfaz de usuario al aplicar un proceso iterativo basado en principios de diseño ampliamente aceptados. Si el uso del software es difícil. El diseño de la interfaz de usuario crea un medio de comunicación efectiva entre un ser humano y una computadora. Aunque las interfaces basadas en texto aun se utilizan. El diseño de la interfaz se concentra en tres áreas: • • El diseño de interfaces entre componentes de software El diseño de interfaces entre el software y otros productores y consumidores de la información que no son humanos (entidades externas) El diseño de la interfaz entre un ser humano y la computadora. si lleva al usuario a cometer errores o si frustra sus esfuerzos por alcanzar sus objetivos. 2 2008 . actualmente los usuarios de las computadoras esperan que los sistemas de aplicaciones tengan algún tipo de interfaz grafica de usuario.Planificación y Modelado 4. La interfaz tiene que ser correcta porque moldea la percepción del usuario acerca del software. Son muy pocos los especialistas que trabajan en el diseño de la interfaz de usuario. no le gustara. el diseñador identifica los objetos y las acciones de la interfaz y luego crea un formato en la pantalla que forma la base de un prototipo de interfaz de usuario. especialmente en los sistemas heredados. sin importar su capacidad ni las funciones que ofrezca. la interfaz de usuario.3 Diseño de interfaz de usuario. El diseño de sistemas de computo comprende varias actividades que van desde el diseño de hardware hasta el de la interfaz de usuario. • Solo hablaremos del número 3. así como de diseñar el software que implemente esta interfaz. es por eso que muchas veces los ingenieros del software tienen que encargarse de diseñar este aspecto. Siguiendo un conjunto de principios de diseño de interfaces.

Planificación y Modelado Las computadoras contienen GUIs (interfaz grafica de usuario) lo que le permite el despliegue en color de alta resolución e interacción utilizando tanto el teclado como el mouse. 2008 Las ventajas de las GUIs son: • • • Son relativamente fáciles de aprender y utilizar. como el ratón Los elementos gráficos se pueden mezclar con texto en el mismo despliegue Iconos Menús Apuntador Gráficos 2 . Características de las interfaces graficas de usuario: Característica s Ventanas Descripción Las ventanas múltiples permiten que se desplieguen simultáneamente información diversa en la pantalla del usuario Los iconos representan diferentes tipos de información. Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la pantalla. los iconos representan archivos. procesos Los comandos se seleccionan de un menú en lugar de teclearse en un lenguaje de ordenes Para seleccionar opciones de un menú o para indicar elementos de interés en una ventana. En algunos sistemas. Para interactuar con el sistema. se utiliza un dispositivo apuntador. los usuarios cuentan con pantallas múltiples. en otros.

Analizar y comprender las actividades del usuario Producir un prototipo de diseño en papel Evaluar el diseño con los usuarios finales Diseñar el prototipo Producir el prototipo del diseño dinamice Evaluar el diseño con los usuarios finales Prototipo ejecutable 2 Implementar la interfaz del usuario final 2008 .Planificación y Modelado El proceso de diseño de la interfaz de usuario.

la interfaz debe llevar al usuario al mundo virtual de la aplicación.1 Reglas en el diseño de interfaz de usuario. El diseño de la interfaz de usuario requiere el estudio de las personas y el conocimiento tecnológico adecuado En su libro sobre diseño de interfaces. que el usuario controle la computadora. esto quiere decir que el usuario es libre de dejar de hacer lo que estaba haciendo para iniciar un proceso nuevo pero sin perder lo que ya había hecho o poder deshacer acciones que ya haya hecho. o sea. Depurar la interacción a medida de que aumentan los grados de destreza y permitir que se personalice la interacción.3. que el usuario pueda decidir si entrar o salir de diferentes tipos de interacción Proporcionar una interacción flexible.Planificación y Modelado 4. esto es. no que la computadora controle al usuario. esto es. que le permita al usuario interactuar con la interfaz mediante movimientos del ratón. Theo Mantel [MAN97] acuño tres reglas de oro para el diseño de la interfaz: • • • • Dar el control al usuario Reducir la carga en la memoria del usuario Lograr que la interfaz sea consistente Dar el control al usuario Se necesitan sistemas que reaccionen a las necesidades de los usuarios y que le ayuden a hacer las cosas. del lápiz digitalizador o comandos seleccionados con el teclado o mediante reconocimiento de voz Incluir las opciones de interrumpir y deshacer la interacción del usuario. no es necesario que conozca 2 2008 . que se pueda personalizar la interfaz con el fin de los usuarios que repitan secuencias de interacciones. Oculte al usuario ocasional los elementos técnicos internos. Se debe definir los modos de interacción de forma que el usuario no realice acciones innecesarias o indeseables.

un objeto o algún comportamiento debe presentarse primero en un alto grado de abstracción. El formato visual de la interfaz debe basarse en una metáfora tomada de la realidad. la interfaz debe organizarse jerárquicamente. esto es. cuando se emplea la mnemotécnica para aplicar una función del sistema. el usuario siente que tiene el control cuando manipula los objetos necesarios para realizar una tarea de manera parecida a como lo haría con un objeto material. se debe encontrar acciones de la vida real y conectarlas mediante la interfaz a algo semejante para poder llevar a cabo la acción deseada. Se deben definir valores por defecto que tengan significado. 2 2008 Diseñar interacción directa con los objetos que aparecen en pantalla. . Esto se logra al proporcionar pistas visuales que permitan al usuario reconocer acciones anteriores sin tener que recordarlas.Planificación y Modelado el sistema operativo. es por eso que una interfaz debe “recordar” la información pertinente y ayudar al usuario con un escenario de interacción que le facilite el uso de la memoria. Desglosar la información de manera progresiva. pero también contar con la posibilidad de especificar sus preferencias. Después de que el usuario se interese en seleccionar algo con el ratón. Esto implica que: • • Toda la información visual esté organizada de acuerdo con un estándar de diseño que se mantenga en todas las presentaciones de pantalla. También se debe definir accesos directos intuitivos. osea. deben presentarse más detalles. la información sobre una tarea. Los mecanismos de entrada se restrinjan a un conjunto limitado que se utilice de manera consistente en toda la aplicación. el conjunto inicial de valores por defecto debe tener un sentido para el usuario promedio. entre más cosas tenga que recordar el usuario. de archivos u otros Reducir la carga en la memoria del usuario. las funciones de administración secretos de la tecnología de computo. debe estar unida a una acción de manera tal que resulte fácil de recordar. esto es. Lograr que la interfaz sea consistente La interfaz debe adquirir y presentar la información de manera consistente. que la interfaz se debe diseñar para que se reduzca la necesidad de recordar acciones y resultados anteriores. Se debe reducir la demanda de memoria a corto plazo. mas fácil será que cometa errores.

Mantener la consistencia en toda una familia de aplicaciones. Bibliografia: 1. Jacobson. muchas interfaces implementan capas complejas de interacciones con docenas de imágenes en pantalla. (2000). (1999). Ingeniería de Software. el usuario espera esto en todas las aplicaciones que encuentre. Ed. Ian (2001). Es importante proporcionar indicadores que permitan al usuario conocer el contexto del trabajo que realiza. 2. UML Gota a Gota. Prentice Hall. 4. Ed.Planificación y Modelado • Los mecanismos para ir de una tarea a otra se hayan definido e implementado de manera consistente. Sommerville. Sommerville. Ian (2003). Gerald. no hacer cambios a menos que haya razones inexcusables. Mc Graw Hill. Pressman Roger S (2001). Ingeniería del Software. Kotonya. Ed. Wiley. . El Proceso unificado de desarrollo de Software. Addison Wesley. se debe de implementar las mismas reglas de diseño para mantener la consistencia en todas las interacciones Si modelos interactivos anteriores han generado expectativas en el usuario. 5/E. Martin. Ed. Una vez que una secuencia interactiva se ha convertido en un estándar de facto. 5. Requirements Engineering : Processes and Techniques. 2 2008 Se debe permitir que el usuario incluya la tarea actual en un contexto que tenga algún significado. Fowler.Ivar. 3.

Prentice Hall. 9. Bruegge Bernd (2001). Ed. 12. 7.. Ingeniería de Software Orientada a Objetos. Alfaomega. 10. I Construcción de Software Orientada a Objetos.Planificación y Modelado Ed. 8. Shari Lawrence (2002). 11. Watts S. Pearson. Ingeniería de Software Una perspective Orientada a Objetos. Ed. Prentice Hall. Eric (2003). 6. Introducción al Proceso Software Personal. Craig (1999). Prentice Hall. Ed. Management Information Systems. Addison Wesley. Meyer. Ed. Ed. Prentice Hall. Larman. Ed. UML y patrones. Laudon & Laudon 8/E (2003). Braude. (2000). Bertrand (1999). Pfleeger. Addison Wesley. Humphrey. Ed. Ingeniería de Software Teoría y práctica. 2008 2 .

Sign up to vote on this title
UsefulNot useful