P. 1
Planificación y Modelado

Planificación y Modelado

5.0

|Views: 3.325|Likes:
Publicado porIrvyn Zarate Islas

More info:

Published by: Irvyn Zarate Islas on Sep 10, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

01/20/2014

pdf

text

original

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

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

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

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. negociación. 2008 • • • 1. Si este consenso no ocurre. es sumamente caro. especificar la solución sin ambigüedades. validación y gestión. validar la especificación. proporciona un mecanismo apropiado para entender lo que el cliente quiere. facilidad de uso. Los requerimientos de proceso se llevan a cabo a través de siente distintas funciones: inicio. Mejora la comunicación entre equipos: la especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores.1 Requerimientos de proceso. especialmente aquellas decisiones tomadas durante el análisis. La ingeniería de requerimientos. desempeño. evaluar la factibilidad. analizar las necesidades. 2 .). y administrar los requisitos conforme éstos se transformen en un sistema operacional. confiabilidad. etcétera. negociar una solución razonable. obtención. 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. el proyecto no será exitoso. por lo que se le involucra durante todo el desarrollo del proyecto. elaboración.

a los usuarios. El objetivo es establecer una comprensión básica del problema. Pero no es simple. 1. Pero en general. las personas que quieren una solución. 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. Toda esa información está sujeta a cambios (una situación probable). Christel y Kang identifican una serie de problemas que ayudan a entender por qué es difícil la obtención de requisitos: 2 2008 . e identifican una descripción funcional del ámbito del proyecto. las semillas de los desastres más importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto” Capers Jones. y otros interesados cuáles son los objetivos para el sistema o el producto. y todas sirven para establecer una base sólida respecto al diseño y la construcción de lo que obtendrá el cliente.2 Obtención.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. los gerentes. 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. 1. qué es lo que se debe lograr. En algunos casos. Todas están dirigidas a definir lo que el cliente quiere. pero suficiente para suscitar conversaciones con la organización de ingeniería de software. y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.1. la mayoría de los proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. gente de mercadotecnia. es muy difícil. hacen un análisis preliminar de factibilidad. Los participantes de la comunidad de negocios (es decir. Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto. ¿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. gerentes de producto) definen un caso de negocios para la idea. Nota: “Por lo general. tratan de identificar la amplitud y profundidad del mercado. En verdad parece muy simple preguntarle al cliente.1 Inicio. la naturaleza de la solución que se desea. una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniería de software.

especifican requisitos ambiguos o inestables. Problemas de volatilidad. Los problemas cambian conforme • Para ayudar a superar estos problemas.1. Dados los recursos limitados del negocio. tienen dificultades al comunicar necesidades al ingeniero de sistemas. Se identifican las relaciones y la colaboración entre las clases y se produce una variedad de diagramas de UML complementarios. no resulta inusual que los clientes y usuarios pidan más de lo que se puede lograr.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 ingenieros de requerimientos deben realizar en forma organizada la actividad de recopilación de requisitos. Nota: la elaboración es buena. los objetivos generales del sistema. en lugar de clarificar. características y restricciones del software. 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. no comprenden del todo el dominio del problema. las funciones y el comportamiento del problema.1. pero se debe saber cuándo detenerla. Esta actividad de la ingeniería de requerimientos se enfoca en el desarrollo de un modelo técnico refinado de las funciones. 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. Cada escenario del usuario se analiza para obtener clases de análisis: entidades del dominio del negocio visibles para el usuario final.3 Elaboración.Planificación y Modelado • Problemas de ámbito. omiten información que consideran “obvia”. Se definen los atributos de cada clase de análisis y se identifican los servicios que requiere cada clase. 1. El límite del sistema está mal definido o los clientes/usuarios especifican detalles técnicos innecesarios que pueden confundir. También es relativamente 2 . Si se trabaja más allá de ese punto. se estará haciendo diseño. 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. 2008 • Problemas de comprensión. especifican requisitos que chocan con las necesidades de otros clientes/usuarios. comprenden poco acerca de las capacidades y limitaciones de su ambiente de cómputo. transcurre el tiempo.

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. Algunos sugieren que para una especificación se debe desarrollar y utilizar una “plantilla estándar”. Sin embargo. combinan o modifican de forma que cada parte alcance cierto grado de satisfacción. los requisitos se eliminan. En el contexto de los sistemas basados en computadora (y en software). Se identifican y analizan los riesgos asociados con cada requisito. Mediante un enfoque iterativo.5 Especificación. Sirve como base para las actividades de ingeniería de software subsecuentes. usuarios y a otros interesados que ordenen sus requisitos y después discutan los conflictos relacionados con la prioridad. 1. Por otro lado. argumentan que esto conduce a que los requisitos sean presentados de manera más consistente y por ende más entendible. La especificación es el producto de trabajo final que genera la ingeniería de requerimientos. cuando dichos sistemas residan en ambientes técnicos que se comprendan bien. algunas veces es necesario ser flexible mientras se desarrolla una especificación. el término especificación tiene significados diferentes para personas distintas. Se pide a los clientes. Ambas partes ganan porque se solidifica un “trato” con el que las dos pueden vivir. Una especificación puede ser un documento escrito. en cuanto a productos o sistemas más pequeños. 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. Describe la función y el desempeño de un sistema basado en computadora y las restricciones que regirá su desarrollo. un modelo matemático formal. Respecto de sistemas grandes el mejor enfoque podría ser un documento escrito que combinara descripciones en lenguaje natural y modelos gráficos. un conjunto de modelos gráficos. un prototipo o cualquier combinación de estos.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”. una colección de escenarios de uso.1. 2 . podría ser que no se necesite más que escenarios de uso. Nota: en una negociación eficaz no debe haber ni ganador ni perdedor.

6 Validación. Enseguida se presenta un pequeño subconjunto de las preguntas que deben realizarse: • ¿El requisito se puede probar? Sí es así. Se recomienda utilizar el modelo de análisis para asegurar que los requisitos se han establecido de madera consistente. usuarios y otros interesados que examinan la especificación y buscan errores en el contenido o en la interpretación. o requisitos irreales (inalcanzables). Nota: un interés clave durante la validación de requisitos es la consistencia. clientes.Planificación y Modelado 1. conflictos entre los requisitos. ¿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. información faltante. omisiones y errores y que éstos han sido corregidos. 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. 2 2008 . La validación de requerimientos examina la especificación para asegurar que todos los requerimientos de software se han establecido de manera precisa. una persona. A continuación se muestra una lista de verificación para la validación de requisitos. y que los productos de trabajo cumplen con los estándares establecidos para el proceso. El equipo de revisión que valida los requisitos incluye ingenieros de software. inconsistencias (que es un problema importante cuando se desarrollan productos o sistemas grandes). La calidad de los productos de trabajo procedentes de la Ingeniería de requerimientos se evalúa durante un paso de validación. proyecto y producto.1. que se han detectado inconsistencias. El mecanismo primario para la validación de requerimientos es la revisión técnica formal. Con frecuencia resulta útil examinar cada requisito frente a una serie de preguntas en forma de lista de verificación. áreas que tal vez requieren una clasificación.

la determinación de las conexiones entre los requisitos puede ser una tarea redituable.7 Gestión de requerimientos. 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. el desempeño y las características operacionales se han establecido de manera clara? ¿Cuáles requerimientos parecen ser implícitos? 1.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. Aspecto especifico del sistema o su ambiente A01 Requisito A02 A03 A04 A05  Aii R01 R02 R03        2 2008 . Nota: cuando un sistema es grande y complejo. controlar y rastrear los equipos y los cambios a éstos en cualquier momento mientras se desarrolla el proyecto. La gestión de requerimientos es un conjunto de actividades que ayudan al equipo de proyecto a identificar.1.

Herramientas de software para la ingeniería de requerimientos. cada una de ellas relaciona los requisitos con uno o más aspectos del sistema o de su ambiente. Muestra la manera en que los requerimientos se relacionan con las características del sistema/producto observables para el cliente. Indica la forma en que los requisitos están relacionados entre sí. Tabla de rastreabilidad del subsistema. Entre las muchas tablas de rastreabilidad tenemos las siguientes: • Tabla de rastreabilidad de las características. Tabla de rastreabilidad de la interfaz. En la figura 1. 2 . Tabla de rastreabilidad de dependencia.1 se muestra de manera esquemática una tabla de rastreabilidad. 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.Planificación y Modelado R04 R05        2008 Rnn   Figura 1. Tabla de rastreabilidad de la fuente. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad. • • • • En muchos casos.1 tabla de rastreabilidad La gestión de requisitos comienza con la identificación. Identifica la fuente de cada requerimiento. Muestra la forma en que los requerimientos se relacionan con las interfaces internas y externas del sistema.

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

2 ilustra la diferencia entre los requerimientos del usuario y del sistema. 2. algunas veces denominado especificación funcional. Los requerimientos del usuario.2 Requerimientos del usuario y del sistema. Especificación de los requerimientos del sistema. Esta especificación agrega detalle a la especificación de requerimientos del sistema. 1. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Usuarios finales del sistema. Administradores contratistas. 2 2008 . el efecto de esta selección es aplicar la herramienta asociada con este tipo de Figura 1. La figura 1. Ingenieros clientes. debe ser preciso. 1.3 Cada tipo de archivo externo se representara como un icono especifico sobre la pantalla del usuario. 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. 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. El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos externos.5 Cuando un usuario selecciona un icono que representa un archivo externo. 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. archivo al archivo representado por el icono seleccionado. El documento de requerimientos del sistema. Los requerimientos del sistema establecen con detalle los servicios y restricciones del sistema. 1. Requerimientos del usuario. 3. Definición de requerimientos del usuario.2 Cada tipo de archivo externo tendrá una herramienta asociada que será aplicada al archivo.Planificación y Modelado en estos dos niveles de detalle. Muestra la manera en que un requerimiento del usuario se expande en varios 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 del usuario son declaraciones en lenguaje natural y en diagramas. 1. los del sistema y la especificación del diseño del software se definen como se muestra a continuación: 1. Administradores clientes.4 Se proveerán recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.

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

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

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

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

Constructores de sistemas. Dentro de este grupo tenemos. A continuación se exponen cada uno de estos grupos.2.2 Usuario del sistema. Este grupo es que paga por el sistema. 1. facturas. científicos etcétera. Ellos ven a un sistema de información en términos de la funcionalidad que provee a sus trabajos. Abogados.2.1 Dueños del sistema. Los usuarios del sistema son los que definen los requerimientos del negocio y las expectativas del sistema. procesan órdenes. 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. pagos etcétera. 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. Para cualquier sistema de información grande o pequeño habrá uno o más dueños del sistema. • • 2 . Diseñadores de sistemas. de corto plazo (mandos medios) o largo plazo (ejecutivos). 4. ya sea decisiones del día a día (supervisores). ingenieros. 5. 1. Hay muchas clases de usuarios. en que sea fácil de aprender y de utilizar.2. Son aquellos empleados del negocio para el cual se está construyendo el sistema y son el mayor porcentaje de usuarios de un sistema.Planificación y Modelado 3. Analistas de sistemas. Supervisores mandos medios y ejecutivos: son los empleados que toman decisiones. • Empleados administrativos y de servicios: realizan los procesos del día a día.2. Ellos capturan los datos en el sistema. Staff técnico y profesional: son empleados que realizan tareas especializadas ejemplo. las cuales son de interés económico primordialmente.

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

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

2. sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo departamento. por tanto podría ser contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa. el Analista de Sistemas desempeña el rol de consultor para un negocio y. El rol de consultor del analista de sistemas. con el propósito de mejorara los procesos de una organización. este trabajo no implica un proyecto completo de sistemas. 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. En su función de consultor externo. También se puede traducir en una desventaja porque alguien externo nunca conocerá la verdadera cultura organizacional. datos. 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. procesos y la tecnología de la información pueden en conjunto mejorar un negocio. Los tres principales roles del analista de sistemas son el de consultor. Con frecuencia. experto en soporte técnico y agente de cambio. El analista desempeña diversos roles. Con frecuencia. Muchas mejoras incluyen un mayor apoyo a las funciones de negocio a través del uso de sistemas de información computarizados. Roles del analista de sistemas. El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada. El rol de experto en soporte técnico del analista de sistemas.Planificación y Modelado • Integradores de software.2. en ocasiones varios de ellos al mismo tiempo. 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. el procesamiento de datos y su consiguiente producción de información. Es un especialista que estudia los problemas y necesidades de una organización para determinar cómo las personas. redes y otros paquetes de software. Son especialistas que integran paquetes de software con hardware. 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.5 Analista de sistemas. . 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. Un analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. 2 2008 1.

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

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

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

Información de apoyo.7Operaciones.2 Alcance 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.6Restricciones de memoria.2Interfaces de usuario. 2. 2.5 Panorama. Figura 1.1. En términos financieros. entonces el costo de encontrar y reparar ese mismo defecto al final del proceso de desarrollo es entre $2000 y $5000. no un lujo. 2. ¿Por qué tantos proyectos sufren daños por un análisis de requerimientos malo o falta del mismo? Una razón es que. 2.1Interfaces del sistema. La mayor parte de las organizaciones de desarrollo considera las pruebas una necesidad absoluta. 2.1. Requerimientos específicos.3.1. 1. 2.3 Definiciones. Los ingenieros que usan un proceso iterativo bien organizado reúnen requerimientos. Copyright © 1994 IEEE. 2.1. Descripción general. 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).1.1.5Interfaces de comunicación.1.4Interfaces de software. 2. expresarse de una u otra forma.1 Perspectiva del producto. Un requerimiento defectuoso (es decir. Considere sus defectos sobre las pruebas. 1.3Interfaces de hardware.3 Características del usuario. Dado el gran beneficio de detectar y reparar defectos en la etapa de requerimientos. El análisis de requerimientos es una necesidad. La ventaja del estándar IEEE es que abarca la mayor parte de los aspectos que deben 1. El daño que resulta de una mala experiencia del cliente con la aplicación es un factor por completo adicional al gasto involucrado. 2.1. por lo general. 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.4 Restricciones. 4. al principio de un proyecto los clientes no saben qué quieren o necesitan con exactitud. 1. Introducción. 2. acrónimos y abreviaturas.6 Distribución de requerimientos.4 Referencias.11 Contenido del estándar IEEE 830-1993: especificación de requerimientos de software. 2. Pero si alguien le proporcionara 2 2008 .1 Propósito. diseñan según éstos y los implementan mediante iteraciones coordinadas. 1. 1. el que no se repara antes de terminar el documento de requerimientos) es muy costoso. si el costo de encontrar y reparar un defecto en la etapa de requerimientos es $100.Planificación y Modelado Los ingenieros de software discuten los méritos de las distintas formas de documentación de los requerimientos.5 Retos y beneficios del análisis de requerimientos.8Requerimientos de adaptación del sitio.5 Suposiciones y dependencias. 2.2 Funciones de producto. 2. 2.1. 3.

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

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

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

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

Por ejemplo. Requerimientos que son resultado de la introducción del sistema informático.Planificación y Modelado Requerimientos cambiarios Requerimientos que cambian debido a los cambios en el entorno en el que opera la organización. Para cada proyecto la etapa de planificación establece el nivel de detalle necesario en la gestión de requerimientos. los requerimientos de compatibilidad del sistema encargado o entregado también pueden cambiar. Cuando estos últimos cambian. en los sistemas hospitalarios. La planificación es una primera etapa esencial del proceso de gestión de requerimientos. La identificación de requerimientos. 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 emergentes Requerimientos consecuentes Requerimientos de compatibilidad Figura 1. 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.2Planificación de la gestión de requerimientos. el pago del cuidado del paciente puede cambiar y así requerir un tratamiento diferente la información a recopilar. habrá que decidir sobre: 1. La cual tiene un coste elevado. Esta introducción puede cambiar los procesos de la organización y desarrollar nuevas formas de trabajar que generan nuevos requerimientos del sistema. 1.4. Requerimientos que dependen de sistemas particulares o procesos de negocios dentro de la organización.13 clasificación de los requerimientos volátiles. 2 2008 .

1. 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. Durante esta etapa. Se modifica el documento de requerimientos y. si es apropiado.3 Gestión de cambio de los requerimientos Se debe aplicar a todos los cambios propuestos en los requerimientos. Implementación del cambio. en su caso el diseño e implementación del sistema. Si se requiere de forma urgente un cambio en los requerimientos del sistema. con una propuesta de cambio específica. Esta política define las relaciones entre los requerimientos.Planificación y Modelado 2. algunas veces. Análisis del cambio y cálculo de costes. 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. el problema o la propuesta de cambio se analizan para verificar que esta es válida. 2 2008 . 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. El proceso empieza con la identificación de un problema en los requerimientos o.4. 4. Análisis del problema y especificación del cambio. Políticas de rastreo. 2. El efecto de un cambio propuesto se valora utilizando la información de rastreo y el conocimiento general de los requerimientos del sistema. Un proceso de gestión del cambio. Este es conjunto de actividades que evalúan el impacto y coste de los cambios. La gestión de requerimientos comprende el procesamiento de grandes cantidades de información sobre los requerimientos. existe siempre la tentación de hacer ese cambio al sistema y entonces modificar de forma retrospectiva el documento de requerimientos. 3. Ayuda de herramientas CASE. Existen 3 etapas principales en un proceso de gestión de cambio: 1. 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. Coste de hacer un cambio se estima en términos de modificaciones al documento de requerimientos y.

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

la configuración Plan mantenimiento de Predice los requerimientos de mantenimiento del sistema. entre otros temas. lo que hace la gestión de software particularmente difícil.1 planes de trabajo. los costos de mantenimiento y el esfuerzo requerido. 2 . la evaluación de costos. En algunas organizaciones. los recursos y la programación utilizados para la validación del sistema. Figura 2. el plan del proyecto es un único documento que incluye todos los diferentes tipos de planes mencionados anteriormente en la tabla. 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 proyecto Este plan fija los recursos disponibles. pero son proporcionados por separado. Sin embargo. Plan de desarrollo Describe cómo se desarrollan las habilidades y personal experiencia de los miembros del equipo del proyecto. el estudio de la viabilidad. la planificación de la documentación. en otros casos solo se refiere al proceso de desarrollo y en otros puede estar referenciado. Plan de validación Describe el enfoque. 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.Planificación y Modelado que se utilizaran en un proyecto. Los gestores de software son responsables de la planificación y temporalización del desarrollo de los proyectos. La gestión de proyectos de software es un tema amplio y no puede tratarse en un solo tema. 2008 Plan de la Describe los procedimientos de administración de la administración de configuración y las estructuras a utilizarse. la ingeniería del software es diferente en varios aspectos a otros tipos. divide el trabajo y crea un calendario de trabajo. es necesario abordar temas como la planificación del tiempo. Los gestores de software hacen el mismo trabajo que otros gestores. 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.

el tiempo estimado requerido para alcanzar cada hito y la asignación de la gente a las actividades. cambiaran frecuentemente.1 Planificación del tiempo. 2. Mecanismos de supervisión e informe: describe la administración de informes y cuando deben producirse. otras serán más estables. Si es necesario comprar hardware. así como los mecanismos de supervisión del proyecto a utilizar. 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. Debe utilizarse una organización documental que permita reemplazar fácilmente las secciones. la gente involucrada y sus tareas en el equipo. Análisis de riesgo: describe los posibles riesgos del proyecto. como el calendario del proyecto. 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. ya que deben estimar el tiempo y los recursos para completar y programar las actividades en forma coherente. La planificación es una parte muy demandante para los administradores de software. en caso de existir un proyecto previo parecido. Organización del proyecto: describe la forma en que el equipo de desarrollo de desarrollo está organizado.Planificación y Modelado La estructura general de cualquier plan lleva los siguientes puntos. Algunas partes. • • • • • El plan de proyecto debe revisarse regularmente durante el proyecto. Requerimientos de recursos de hardware y software: describe el hardware y la ayuda de software requerida para llevar a cabo el desarrollo. se deben incluir los estimados de los precios y las fechas de entrega. la probabilidad de que surjan estos riesgos y las estrategias de reducción de riesgos propuestas. se puede tomar como base su planificación adaptándola al 2 .

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

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

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

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

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. 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. limpiadores y técnicos 2 . Estas pueden ser solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar. correos electrónicos y teleconferencias reduce los viajes requeridos.Planificación y Modelado 2. Por lo tanto. antes de que se tenga la calendarización detallada. La estimación y la calendarización del proyecto se llevan a cabo de forma conjunta. entonces el administrador del proyecto debe tomar algunas acciones. los siguientes costos son parte de los costos de esfuerzo totales: • • los costos de proveer. Los costos de esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. calentar e iluminar las oficinas los costos de personal de apoyo como los contadores. el uso de fax. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas.2 Evaluación del costo beneficio. Sin embargo. esto ayuda al proceso de planeación y permite la utilización efectiva de los recursos. son relativamente bajos para muchos proyectos. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente. en las primeras etapas del proyecto se requieren algunas estimaciones de costos. secretarias. el costo dominante es el costo de esfuerzo. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos. las estimaciones se actualizan de forma regular. 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. Una vez que el proyecto se encamina. Si el gasto real es significativamente más grande que las estimaciones.

los recursos recreativos. etc. no tiene sentido comparar estas tasas de producción. 2008 Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud. 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. estas estimaciones de productividad se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Si la estimación del costo se puede posponer hasta que el proyecto tome forma. Incluso se pueden ponderar las estimaciones obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas. Existen dos tipos de medidas utilizadas: 2 . Estas estimaciones son necesarias para la estimación del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivos. 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. para cualquier problema de software. 2. 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. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes para cumplir con un costo predeterminado. existen muchas soluciones diferentes con distintos atributos. 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. Cuando se producen soluciones con diferentes atributos. tal vez el equipo tenga solo una idea vaga de su costo. más preciso será el costo. El costo de un proyecto es de interés continuo y vital para los coparticipes. Por lo general.Planificación y Modelado • • los costos de las redes y las comunicaciones los costos de los recursos centralizados como las bibliotecas. 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. incluso el sistema más fantástico puede ser un desastre. sin duda deben esperar. Cuando se inicia un proyecto. Sin embargo. los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software.2. sin permitir desviaciones en ninguna circunstancia. La estimación de costo más sencilla es la que proporciona un costo fijo desde el principio. Sin embargo.1 Productividad. Con el precio de producción equivocado.

La cuenta se divide entre el tiempo total de programadores-mes requeridos para completar el proyecto. Un experimento controlado no revelaría la estimación del costo al administrador del proyecto. pruebas y documentación. 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. 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. Esta se calcula contando el número total de líneas del código fuente que se entrega.6: Técnica Modelado Descripción Se desarrolla un modelo utilizando información histórica de 2 2008 . Por lo tanto. se utilizan una o más de las técnicas descritas en el cuadro de la figura 2. Las líneas de código fuente por programador-mes son una métrica ampliamente utilizada en la medida de la productividad. Las estimaciones iníciales se hacen bajo la base de la definición de requerimientos de usuario de alto nivel. Por lo general. La estimación se utiliza para definir el presupuesto del proyecto y el producto se ajusta para que las cifras del presupuesto se cumplan.2.Planificación y Modelado Medidas relacionadas con el tamaño: estas se relacionan con el tamaño de alguna salida de una actividad. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologías de desarrollo. este tiempo incluye el tiempo requerido para el análisis y diseño. A pesar de esto. 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. las organizaciones necesitan hacer esfuerzos de software y estimaciones de los costos. Probablemente no se conozcan las personas involucradas en el proyecto y sus habilidades. La mediad más común relacionada con el tamaño son las líneas de código fuente entregadas. Existe una dificultad para valorar la precisión de los diferentes enfoques de las técnicas de estimación de costos. las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. 2. codificación. 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. Medidas relacionadas con la función: estas se relacionan con la funcionalidad total del software entregado. 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.

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

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

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. 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. 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 . 2. Las estimaciones varían de una persona a otra. Este estudio es con el que debe empezar el proceso de ingeniería de requerimientos. la entrada de este es un conjunto de requerimientos de negocio preliminares. una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. o simplemente puede ser una cuestión de juicio de ingeniería. La estimación del tamaño puede comprender la estimación por analogía con otros proyectos. dependiendo de su conocimiento y experiencia. la de convertir los puntos de función al tamaño del código.3 Estudio de viabilidad.Planificación y Modelado Las estimaciones de los factores B y M son subjetivas. 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.

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

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.Planificación y Modelado flujo ordenado desde el panorama general hasta los detalles. numerosas notas acerca de implementaciones específicas. y la inclusión de la información sobre la posible evolución del sistema. el documento de requerimientos puede ser mucho menos detallado y cualquier ambigüedad resuelta durante el desarrollo del sistema. En algunos casos. 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. entre otros. En otros. diagramas con las interrelaciones. 2. Cuando haya más flexibilidad en los requerimientos y cuando se utilice un proceso de desarrollo iterativo dentro de la empresa. la definición de los requerimientos en el detalle exacto para los desarrolladores y probadores. Cuando del sistema se desarrolle por un contratista externo. hasta los ingenieros responsables de desarrollar el software.1 El documento de requerimientos del software. Las omisiones o contradicciones harían difícil o imposible entender que sucede. 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. los requerimientos del usuario se definen en una introducción a la especificación de los requerimientos del sistema. ilustra los posibles usuarios del documento y como lo utilizan. Debe incluir tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema.4. los detalles de los requerimientos del sistema se pueden presentar en un documento separado. los dos tipos de requerimientos se pueden integrar en una única descripción. Si existe un gran número de requerimientos. las especificaciones de los sistemas críticos necesitan ser claras y muy detalladas. 2008 2 .7 tomada del libro sobre ingeniería de requerimientos de Gerald Kotonya e Ian Sommerville. La figura 2. 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. 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.

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

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

• 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. 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. el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida. 2. La gestión de configuración del software no es un mantenimiento del software. 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. La IEEE define una línea base como: 2 . • Garantizar que el cambio quede bien implantado. 2008 • Informar el cambio. Líneas base. el mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo. 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.5. en el proceso de ingeniería del software existe una variable importantísima que entra en juego. el cambio.Planificación y Modelado • Controlar ese cambio.1. Desgraciadamente. 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 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. La primera Ley de la ingeniería de sistemas establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos. • Nuevas necesidades del los clientes que demandan la modificación de los datos producidos por un sistema basado en computadora.

Una forma de describir la línea base es mediante una analogía. una vez que se establece una línea base. pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. 4) Explicar el problema etc. 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. 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. debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algún error. 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. Considere las puertas de la cocina de un gran restaurante. 3) Volver a la cocina por la puerta de entrada. Sin embargo. Sé pueden llevar a cabo los cambios. los elementos de una especificación de diseño se documentan y se revisan. por una puerta de un solo sentido. el cambio se puede llevar a cabo rápida e informalmente. 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. si abandona la cocina le da el plato al cliente y luego se le informa de su error. pasamos. 2) Disculparse insistentemente. 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. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado. puede cambiar el plato correcto rápidamente informalmente antes de salir de la cocina.Planificación y Modelado Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo. la especificación de diseño se convierte 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. 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. de forma figurada.8 2008 2 . Sin embargo. Por ejemplo.

Plan y procedimiento de pruebas 2 2008 . 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 interfaces e. 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. Prototipo ejecutable o en papel 4) Manual de usuario preliminar 5) Especificación de diseños a. un ECS (elemento de configuración de software) es un documento. Descripción del diseño de datos b.O. un conjunto completo de casos de prueba o un componente de un programa 40 dado. Descripciones del diseño de los módulos d.2 Elemento de configuración del software.O) 6) Listados del código fuente 7) a.Planificación y Modelado Figura 2. Descripciones de los objetos (si se utilizan técnicas de P.8 líneas base. 2.5. Especificación de requisitos b. Descripción del diseño arquitectónico c.

código ejecutable b. y está conectado a otros objetos mediante relaciones.Planificación y Modelado b. Informes de problemas del software b. Módulos enlazados 10) Descripción de la base de datos a. Peticiones de mantenimiento c. Es decir congelar la versiones de editores. compiladores y otras herramientas CASE utilizadas durante el desarrollo. Un ECS tiene un nombre y atributos. contenido inicial 11) Manual del usuario final 12) Documentos de mantenimiento a. 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. 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. Casos de prueba y resultados registrados 8) Manuales de operación de y de instalación 9) Programas ejecutables a. Esquema y estructura de archivos b. 2008 2 . Módulos.

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

Planificación y Modelado cadena de caracteres que identifica al objeto sin ambigüedad.10 Grafo de evolución. 2. y la información de la versión y/o el cambio.10 de evolución se describe la historia del objeto y sus cambios. datos) que está representado por el objeto. Esto se puede gestionar asociando atributos a cada versión del 2 2008 . las grandes modificaciones hacen que un objeto cambie. por lo que cambia el número de versión principal.5. "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.5 Control de versiones. • Un identificador del proyecto. La descripción del objeto es una lista de elementos de datos que identifican: • El tipo de ECS (documento. 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. En el grafo de la figura 2. Figura 2. programa.

variantes y versiones es representarlas como un fondo de objetos. A cada variante se le asigna uno o más atributos. Figura 2. a cada componente se le asigna una tupla de atributos." 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. 2 2008 .Planificación y Modelado software y permitiendo luego especificar y construir una configuración describiendo el conjunto de atributos deseado. Otra forma de establecer los conceptos de la relación entre componentes.11 Versiones y variantes Para construir la variante adecuada de una determinada versión de un programa.

En un gran proyecto de desarrollo de software.6 Control de cambios. El control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control de cambio. 2 2008 .5.Planificación y Modelado Figura 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.12 Representación de objetos. el cambio incontrolado lleva rápidamente al caos. 2. componentes.

se realiza el cambio y se aplican las adecuadas actividades de SQA. 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.Planificación y Modelado Figura 2. Luego. 2 2008 . El objeto a cambiar es "dado de baja" de la base de datos del proyecto. las restricciones que se deben respetar y los criterios de revisión y de auditoría. Para cada cambio aprobado se genera una orden de cambio de ingeniería (OCI).13 Proceso de control de cambios.

no se sobrescriben mutuamente. En algunos casos. sólo es necesario aplicar un control de cambios informal. El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuración concretos. se crea la línea base. se dispensa de generar formalmente las peticiones de cambio. Una vez que el ECS se convierte en una línea base. Para hacer un cambio. El que haya desarrollado el ECS en cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos. o de la ACC si el cambio impacta en otros ECS. realizados por personas diferentes. los informes de cambio y las 2 2008 . Antes de que un ECS se convierta en una línea base. Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobada. Figura 2.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). El control de sincronización asegura que los cambios en paralelo. aparece el control de cambios a nivel de proyecto.

Planificación y Modelado OCI.5. Los revisores evalúan el ECS para determinar la consistencia con otros ECS. 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. ¿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. Cuando se distribuye el producto de software a los clientes. registrarlo y divulgarlo? 2 2008 . se instituye el control de cambios formal. o sea. El papel de la ACC es el de tener una visión general.7 Auditoria de la configuración. Las revisiones técnicas formales se centran en la corrección técnica del elemento de configuración que ha sido modificado. Sin embargo. hay que hacer una evaluación de cada cambio así como un seguimiento y revisión de los mismos. 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. evaluar el impacto del cambio fuera del ECS en cuestión. La autoridad de control de cambios (ACC) desempeña un papel activo en el segundo y tercer nivel de control. las omisiones o los posibles efectos secundarios. ¿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.

Pueden darse errores entre las personas desarrolladoras del software.5.8 Informes de estado. 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. 2 2008 .Planificación y Modelado ¿Se han actualizado adecuadamente todos los ECS relacionados? 2. El IEC ayuda a eliminar esos problemas. 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.

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

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

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

Involucran a un grupo de personas que examinan parte o todo el proceso del software. 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. 2 2008 . El cometido del equipo de revisión es detectar los errores e inconsistencias y señalarlas al diseñador o autor del documento. 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. Esta valoración automática comprende una medida cuantitativa de algunos atributos del software. los sistemas o su documentación asociada para descubrir problemas potenciales. Las revisiones son el método más utilizado para validar la calidad de un proceso o producto. Se revisan todos los documentos tales como los modelos de proceso. Existen dos enfoques complementarios para el control de la calidad: Revisiones de la calidad en las que el software. Las revisiones se basan en documentos pero no se limitan a las especificaciones. su documentación y los procesos utilizados para producir ese software son revisados por un grupo de personas. Toman las desviaciones de los estándares y las ponen a consideración de la administración del proyecto. diseños o código. 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. Las conclusiones de la revisión se registran formalmente y se pasan al autor o a quien sea responsable de corregir los problemas descubiertos. los productos resultantes de un proceso de software se comprueban contra los estándares definidos del proyecto en el proceso de control de calidad. 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. 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. El bucle de retroalimentación es esencial para minimizar los defectos producidos.Planificación y Modelado afinar el proceso cuando los productos de trabajo creados fracasan en cuanto a satisfacer sus especificaciones.

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

el mantenimiento. 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. la facilidad de uso. Algunos ejemplos de aspectos solicitables son la disponibilidad. En la ingeniería de software se aplica el mismo significado.Planificación y Modelado integridad. no sólo las funciones sino también la auditabilidad del sistema. ya que esto debe ser decidido en la etapa de diseño por los diseñadores. cómo y cuándo. sólo que el énfasis está puesto en el propio software. 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. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar. etc. Otros tipos de limitaciones externas. 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. 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. Se omite el cómo debe lograrse su implementación. dónde. 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. 2 2008 . el testeo. técnico y de tiempo así como las metas. de calidad. especifica algo sobre el propio sistema. que afectan en una forma indirecta al producto. y cómo debe realizar sus funciones. En ingeniería de sistemas existen tres tipos de requerimientos. Los requerimientos deben considerar las restricciones de carácter económico. Una vez culminada la etapa de requerimientos los revisores independientes revisarán lo efectuado. Para obtener los requerimientos de los sistemas de información. Un requerimiento no funcional: de rendimiento. Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. los analistas deben trabajar una y otra vez en enunciados de requerimientos en colaboración con los usuarios. procedimientos y los procesos de decisiones en la institución. etc. definición en términos descriptivos para los desarrolladores y un esbozo de especificación.

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

Sin embargo. El sistema deberá proveer visores adecuados para que el usuario lea documentos en el almacén de documentos.Planificación y Modelado portafolio de inversión del usuario”). Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Los requerimientos funcionales para un sistema de software se expresan de diferentes formas. 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. eso retrasa la entrega de éste e incrementa los costos. A cada pedido se le deberá asignar un identificador único que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. Por supuesto. esto depende del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. En su lugar. etc. Cuando se expresan como requerimientos del usuario. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. para sistemas grandes y complejos. La compleción significa que todos los servicios solicitados por el usuario están definidos. sus entradas y salidas. a menudo no es lo que el cliente desea. porque no especifica un servicio dado. La consistencia significa que los requerimientos no tienen definiciones contradictorias. habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste. excepciones. En la práctica. En principio. Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste proveerá. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema. Estos son requerimientos funcionales del usuario que definen los recursos específicos que el sistema debe proveer. la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. 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 otro lado. 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). califica un servicio o servicios (especifica algo sobre ellos). es posible cumplir los 2008 2 .

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

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

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. y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo similar. lo que provoca discusiones subsecuentes una vez que el sistema se entregue. 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. algunas veces llamados “escenarios” (en UML. Casi siempre. se debe a una mala administración de requerimientos. Por ejemplo.Planificación y Modelado recuperarse de las fallas o la respuesta rápida del usuario. Nos pudo haber pasado porque no alcanzó nuestras expectativas. o porque en realidad no era una verdadera necesidad sino simplemente un capricho. 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. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a interpretación. Sea cual fuera la razón. 2 2008 .2 Casos de uso. Una de las razones principales por las cuales se da esta situación. una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el éxito que deberían. 4. 4.1 Los Casos de uso y el valor del sistema.2. Pues. un “escenario” es en realidad una instancia de un caso de uso). Con el software. la realidad es que hicimos un gasto inútil e innecesario.1 La Administración de requerimientos. Cuando se usa como parte del análisis de tareas. y de hecho. Organizarlos de esta manera es útil para producir casos de uso más grandes a partir de los pequeños. En otras palabras. 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. no obtuvieron el valor que esperaban recibir para su negocio con el software adquirido. el caso de uso se desarrolla para que muestre la manera en que el usuario final realiza alguna tarea relacionada con el trabajo. 4.1. o porque resultó demasiado complicado de utilizar. el caso de uso se escribe de manera informal (un solo párrafo) en primera persona.2. El proceso unificado de desarrollo de software (USDP) explota la observación de que muchos requerimientos ocurren de manera natural en secuencias operativas. pues no obtuvieron lo que ellos esperaban o necesitaban. El USDP favorece la organización de los requerimientos por casos de uso. Estas son los casos de uso.

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

Planificación y Modelado Figura 4. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misión del sistema. Lo inicia con algún evento. 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. conocido como actor primario. primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p.5 Los requerimientos funcionales. es decir.1.2. Identificar quiénes utilizarán el sistema (actores primarios) 2 2008 . Normalmente los casos de uso son iniciados por algún actor. 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). y continúa como una serie de eventos o interacciones entre actores y sistema. Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso: 1.2 caso de uso 4. 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. Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos importantes.

La esencia de los modelos radica en la simplicidad. En dicha situación el sistema de contabilidad aparecerá como un actor secundario asociado a dicho caso de uso.Planificación y Modelado 3. Hay otro tipo de actores que también hay que modelar. En otras oportunidades veremos elementos adicionales para modelar los casos de uso. componentes externos o dispositivos con los cuales interactúa nuestro sistema. al llevar a cabo un caso de uso requiere tener algún tipo de interacción con él. y sobre todo cuando el analista no tiene tanta experiencia en UML.5 Las interfaces del sistema. 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”. Suelen ser otros sistemas. A diferencia de los actores secundarios. en los modelos de UML. el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. 2 2008 . sino que nuestro sistema. En el diagrama de casos de uso también suele ser apropiado mostrar a este tipo de actores. Por experiencia sabemos que.1. Identificar los pasos o eventos de cada caso de uso (especificación del caso de uso) 4. es mejor limitarnos a los elementos más básicos. y esto implica que en ocasiones. 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. pero podemos asegurar que la sencillez es parte importante del modelado. 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. ya que facilita el análisis. los actores secundarios. Ejemplo de Actor Secundario.2. éstos no son los que inician o requieren del caso de uso. entendimiento y comunicación entre quienes solicitan el sistema y los que participan en su desarrollo.

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. es por eso que muchas veces los ingenieros del software tienen que encargarse de diseñar este aspecto. la interfaz de usuario. así como de diseñar el software que implemente esta interfaz. especialmente en los sistemas heredados. Siguiendo un conjunto de principios de diseño de interfaces. sin importar su capacidad ni las funciones que ofrezca. El diseño de la interfaz de usuario crea un medio de comunicación efectiva entre un ser humano y una computadora. Son muy pocos los especialistas que trabajan en el diseño de la interfaz de usuario. La interfaz tiene que ser correcta porque moldea la percepción del usuario acerca del software. Un ingeniero de software diseña la interfaz de usuario al aplicar un proceso iterativo basado en principios de diseño ampliamente aceptados. 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. 2 2008 . actualmente los usuarios de las computadoras esperan que los sistemas de aplicaciones tengan algún tipo de interfaz grafica de usuario.3 Diseño de interfaz de usuario. • Solo hablaremos del número 3. no le gustara. 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. Si el uso del software es difícil. si lleva al usuario a cometer errores o si frustra sus esfuerzos por alcanzar sus objetivos.Planificación y Modelado 4.

En algunos sistemas. se utiliza un dispositivo apuntador. los usuarios cuentan con pantallas múltiples. 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.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. en otros. 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. 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 . Para interactuar con el sistema.

Planificación y Modelado El proceso de diseño de la interfaz de usuario. 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 .

que le permita al usuario interactuar con la interfaz mediante movimientos del ratón. que el usuario controle la computadora. que se pueda personalizar la interfaz con el fin de los usuarios que repitan secuencias de interacciones. no es necesario que conozca 2 2008 . o sea. la interfaz debe llevar al usuario al mundo virtual de la aplicación.1 Reglas en el diseño de interfaz de usuario. 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. 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. Se debe definir los modos de interacción de forma que el usuario no realice acciones innecesarias o indeseables. Depurar la interacción a medida de que aumentan los grados de destreza y permitir que se personalice la interacción.Planificación y Modelado 4.3. esto es. esto es. Oculte al usuario ocasional los elementos técnicos internos. que el usuario pueda decidir si entrar o salir de diferentes tipos de interacción Proporcionar una interacción flexible. 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. 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. no que la computadora controle al usuario.

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. pero también contar con la posibilidad de especificar sus preferencias. 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. mas fácil será que cometa errores. esto es. debe estar unida a una acción de manera tal que resulte fácil de recordar. las funciones de administración secretos de la tecnología de computo. El formato visual de la interfaz debe basarse en una metáfora tomada de la realidad. Lograr que la interfaz sea consistente La interfaz debe adquirir y presentar la información de manera consistente. osea. 2 2008 Diseñar interacción directa con los objetos que aparecen en pantalla. de archivos u otros Reducir la carga en la memoria del usuario. Esto se logra al proporcionar pistas visuales que permitan al usuario reconocer acciones anteriores sin tener que recordarlas. la información sobre una tarea. cuando se emplea la mnemotécnica para aplicar una función del sistema. que la interfaz se debe diseñar para que se reduzca la necesidad de recordar acciones y resultados anteriores. 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 reducir la demanda de memoria a corto plazo. el conjunto inicial de valores por defecto debe tener un sentido para el usuario promedio. entre más cosas tenga que recordar el usuario.Planificación y Modelado el sistema operativo. . Desglosar la información de manera progresiva. Los mecanismos de entrada se restrinjan a un conjunto limitado que se utilice de manera consistente en toda la aplicación. un objeto o algún comportamiento debe presentarse primero en un alto grado de abstracción. la interfaz debe organizarse jerárquicamente. Después de que el usuario se interese en seleccionar algo con el ratón. 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. deben presentarse más detalles. Se deben definir valores por defecto que tengan significado. También se debe definir accesos directos intuitivos. esto es.

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

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->