Planificacin y Modelado

Instituto Tecnolgico de Pachuca Autopista Mxico Pachuca: Km 87.5, Cdigo Postal 42080, Apartado Postal 276 Telfonos: (771) 71-1 31 40, 71130 73, 711 35 96 Fax: 711 33 9910/04/2008

Jos Fructuoso Gutirrez Daz

Planificacin y modelado, trata de la planificacin, anlisis y diseo de proyectos de software o sistemas de informacin, conforme a los requerimientos establecidos al inicio del mismo y aplicando tcnicas modernas y de acorde a las caractersticas intrnsecas del mismo.

Planificacin y Modelado

Contenido
Procesos de la ingeniera de requerimientos......................................................4 1.1 Requerimientos de proceso.......................................................................7 1.1.1 Inicio.................................................................................................... 8 1.1.2 Obtencin............................................................................................8 1.1.3 Elaboracin..........................................................................................9 1.1.4 Negociacin.........................................................................................9 1.1.5 Especificacin....................................................................................10 1.1.6 Validacin..........................................................................................11 1.1.7 Gestin 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 anlisis y la negociacin.....................................26 1.3.1 Requerimientos para el anlisis.........................................................26 1.3.2 Requerimientos para la negociacin..................................................31 1.4 Requerimientos para la gestin...............................................................32 1.4.1 Requerimientos duraderos y voltiles................................................34 1.4.2Planificacin de la gestin de requerimientos.....................................35 1.4.3 Gestin de cambio de los requerimientos..........................................36 Planificacin del sistema...................................................................................37 2.1 Planificacin del tiempo...........................................................................39 2.1.1 Grficos de barras y redes de actividades.........................................41 2.2 Evaluacin del costo beneficio.................................................................44 2.2.1 Productividad.....................................................................................45 2.2.2 Tcnicas de estimacin......................................................................46 2.2.3 Modelo algortmico de costos...........................................................48 2.3 Estudio de viabilidad................................................................................49 2.4 Planificacin de la documentacin...........................................................50 2.4.1 El documento de requerimientos del software...................................51
2008

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

Planificacin y Modelado 2.5 Gestin de la configuracin del software.................................................53 2.5.1. Lneas base.......................................................................................54 2.5.2 Elemento de configuracin del software............................................56 2.5.4 Identificacin 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 configuracin.............................................................64 2.5.8 Informes de estado............................................................................65 Anlisis del proyecto.........................................................................................66 3.1 Anlisis de riesgos...................................................................................66 3.2 Control de calidad....................................................................................68 Anlisis 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 Diseo de interfaz de usuario..................................................................80 4.3.1 Reglas en el diseo de interfaz de usuario........................................83
2008

2.5.3 El proceso de la configuracin del software.......................................58

Planificacin y Modelado

Procesos de la ingeniera de requerimientos.

Qu son requerimientos? normalmente, un tema de ingeniera de software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuacin se presenta la definicin que aparece en el glosario de la IEEE: 1. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. 3. Una representacin documentada de una condicin 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 caractersticas 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, estndares, etctera. Caractersticas de los requerimientos. Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad,

2008

Unidad 1

Planificacin y Modelado caractersticas fsicas o factor de calidad no pueden reemplazados por otras capacidades del producto o del proceso. ser

Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones en el lector. Verificable: un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Dificultades para definir los requerimientos.

Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar con palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tienen funcionales especficas. propiedades nicas y abarcan reas

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

2008

Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en el futuro.

Planificacin y Modelado Son difciles de cuantificar, ya que el conjunto de requerimientos es particular para cada proyecto. Ingeniera de requerimientos vs. Administracin de requerimientos.
2008

Nota: el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado ingeniera de requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para ingeniera de requerimientos. Ingeniera de requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema Boehm 1979. Ingeniera de requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones STARTS Guide 1987. Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos Leite 1987. Ingeniera de requerimientos es un enfoque sistemtico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto Rational Software.

Importancia de la ingeniera de requerimientos.

Los principales beneficios que se obtienen de la ingeniera 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. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: la IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios.

Planificacin y Modelado Disminuye los costos y retrasos del proyecto: muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante el anlisis. Mejora la calidad del software: la calidad del software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etctera.). Mejora la comunicacin entre equipos: la especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso. Evita rechazos de usuarios finales: la ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.
2008

1.1 Requerimientos de proceso.

La ingeniera de requerimientos, proporciona un mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin, y administrar los requisitos conforme stos se transformen en un sistema operacional. Los requerimientos de proceso se llevan a cabo a travs de siente distintas funciones: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin.

Planificacin y Modelado Resulta importante destacar que algunas de estas funciones de la ingeniera de requerimientos ocurren en paralelo y que todas deben adaptarse a las necesidades del proyecto. Todas estn dirigidas a definir lo que el cliente quiere, y todas sirven para establecer una base slida respecto al diseo y la construccin de lo que obtendr el cliente. Nota: Se debe esperar la realizacin de una parte del diseo durante el trabajo de los requisitos y una parte del trabajo de los requisitos durante el diseo. 1.1.1 Inicio. Cmo 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. Nota: Por lo general, las semillas de los desastres ms importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto Capers Jones. En algunos casos, una conversacin informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniera de software. Pero en general, la mayora de los proyectos se inician cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Los participantes de la comunidad de negocios (es decir, los gerentes, gente de mercadotecnia, gerentes de producto) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un anlisis preliminar de factibilidad, e identifican una descripcin funcional del mbito del proyecto. Toda esa informacin est sujeta a cambios (una situacin probable), pero suficiente para suscitar conversaciones con la organizacin de ingeniera de software. Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto. El objetivo es establecer una comprensin bsica del problema, las personas que quieren una solucin, la naturaleza de la solucin que se desea, y la efectividad de la comunicacin preliminar entre el cliente y el desarrollador. 1.1.2 Obtencin. En verdad parece muy simple preguntarle al cliente, a los usuarios, y otros interesados cules son los objetivos para el sistema o el producto, qu es lo que se debe lograr, de qu forma el producto satisface las necesidades del negocio y por ltimo cmo se utilizar el sistema o producto da a da. Pero no es simple, es muy difcil. Christel y Kang identifican una serie de problemas que ayudan a entender por qu es difcil la obtencin de requisitos:

2008

Planificacin y Modelado Problemas de mbito. El lmite del sistema est mal definido o los clientes/usuarios especifican detalles tcnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema.
2008

Problemas de comprensin. Los clientes/usuarios no estn seguros por completo de qu es lo que se necesita, comprenden poco acerca de las capacidades y limitaciones de su ambiente de cmputo, no comprenden del todo el dominio del problema, tienen dificultades al comunicar necesidades al ingeniero de sistemas, omiten informacin que consideran obvia, especifican requisitos que chocan con las necesidades de otros clientes/usuarios, especifican requisitos ambiguos o inestables. Problemas de volatilidad. transcurre el tiempo. Los problemas cambian conforme

Para ayudar a superar estos problemas, los ingenieros de requerimientos deben realizar en forma organizada la actividad de recopilacin de requisitos. 1.1.3 Elaboracin. La informacin conseguida con el cliente durante el inicio y obtencin se expande y se refina durante la elaboracin. Esta actividad de la ingeniera de requerimientos se enfoca en el desarrollo de un modelo tcnico refinado de las funciones, caractersticas y restricciones del software. La elaboracin es una accin del modelado del anlisis y se componen de una serie de tareas del modelado y refinamiento. La elaboracin se conduce mediante la creacin y el refinamiento de escenarios del usuario que describen la forma en que el usuario final (y otros actores interactan con el sistema) interactuarn con el sistema. Cada escenario del usuario se analiza para obtener clases de anlisis: entidades del dominio del negocio visibles para el usuario final. Se definen los atributos de cada clase de anlisis y se identifican los servicios que requiere cada clase. Se identifican las relaciones y la colaboracin entre las clases y se produce una variedad de diagramas de UML complementarios. Nota: la elaboracin es buena, pero se debe saber cundo detenerla. La clave es describir el problema de una forma que establezca una base firme para el diseo. Si se trabaja ms all de ese punto, se estar haciendo diseo. El resultado final de la elaboracin es un modelo de anlisis que define el dominio de la informacin, las funciones y el comportamiento del problema. 1.1.4 Negociacin. Dados los recursos limitados del negocio, no resulta inusual que los clientes y usuarios pidan ms de lo que se puede lograr. Tambin es relativamente

Planificacin y Modelado comn que diferentes cliente o usuarios propongan requisitos que entran en conflicto entre s al argumentar que su versin es esencial para nuestras necesidades especiales.
2008

El ingeniero de requerimientos debe conciliar estos conflictos por medio de un proceso de negociacin. Se pide a los clientes, usuarios y a otros interesados que ordenen sus requisitos y despus discutan los conflictos relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares del esfuerzo requerido para su desarrollo y despus se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfaccin. Nota: en una negociacin eficaz no debe haber ni ganador ni perdedor. Ambas partes ganan porque se solidifica un trato con el que las dos pueden vivir. 1.1.5 Especificacin. En el contexto de los sistemas basados en computadora (y en software), el trmino especificacin tiene significados diferentes para personas distintas. Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos. Algunos sugieren que para una especificacin se debe desarrollar y utilizar una plantilla estndar, argumentan que esto conduce a que los requisitos sean presentados de manera ms consistente y por ende ms entendible. Sin embargo, algunas veces es necesario ser flexible mientras se desarrolla una especificacin. Respecto de sistemas grandes el mejor enfoque podra ser un documento escrito que combinara descripciones en lenguaje natural y modelos grficos. Por otro lado, en cuanto a productos o sistemas ms pequeos, podra ser que no se necesite ms que escenarios de uso, cuando dichos sistemas residan en ambientes tcnicos que se comprendan bien. Nota: la formalidad y el formato de una especificacin varan con el tamao y la complejidad del software que se va a construir. La especificacin es el producto de trabajo final que genera la ingeniera de requerimientos. Sirve como base para las actividades de ingeniera de software subsecuentes. Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regir su desarrollo.

Planificacin y Modelado 1.1.6 Validacin. La calidad de los productos de trabajo procedentes de la Ingeniera de requerimientos se evala durante un paso de validacin. La validacin de requerimientos examina la especificacin para asegurar que todos los requerimientos de software se han establecido de manera precisa; que se han detectado inconsistencias, omisiones y errores y que stos han sido corregidos, y que los productos de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto. Nota: un inters clave durante la validacin de requisitos es la consistencia. Se recomienda utilizar el modelo de anlisis para asegurar que los requisitos se han establecido de madera consistente. El mecanismo primario para la validacin de requerimientos es la revisin tcnica formal. El equipo de revisin que valida los requisitos incluye ingenieros de software, clientes, usuarios y otros interesados que examinan la especificacin y buscan errores en el contenido o en la interpretacin, reas que tal vez requieren una clasificacin, informacin faltante, inconsistencias (que es un problema importante cuando se desarrollan productos o sistemas grandes), conflictos entre los requisitos, o requisitos irreales (inalcanzables). A continuacin se muestra una lista de verificacin para la validacin de requisitos.
Con frecuencia resulta til examinar cada requisito frente a una serie de preguntas en forma de lista de verificacin. Enseguida se presenta un pequeo subconjunto de las preguntas que deben realizarse: El requisito se puede probar? S es as, Se pueden especificar las pruebas (algunas veces llamadas criterios de validacin) para ejecutar el requisito? El requisito es rastreable para cualquier modelo de sistema que haya sido creado?

Los requisitos estn establecidos de manera clara? stos pueden malinterpretarse? La fuente del requisito (por ejemplo, una persona, una regulacin o un reglamento) est identificada? El enunciado final del requisito ha sido examinado por la fuente original o comparndolo con ella? El requisito est restringido en trminos cuantitativos?

El requisito es rastreable para los objetivos generales del sistema o producto?

La especificacin est estructurada de una forma que conduzca a su comprensin,

2008

Planificacin y Modelado
referencia y traduccin fcil en productos de trabajo ms tcnicos? Cules otros requisitos estn relacionados con este? Estn registrados de manera clara por medio de una matriz de referencias cruzadas u otro mecanismo? El requisito viola alguna restriccin del dominio del sistema? Se ha creado un ndice para la especificacin?

Los requerimientos asociados con el rendimiento, el desempeo y las caractersticas operacionales se han establecido de manera clara? Cules requerimientos parecen ser implcitos?

1.1.7 Gestin de requerimientos. Se sabe que los requerimientos para los sistemas basados en computadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema. La gestin de requerimientos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los equipos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto. Muchas de estas actividades son idnticas a las actividades de la gestin de la configuracin del software (CGS). Nota: cuando un sistema es grande y complejo, la determinacin de las conexiones entre los requisitos puede ser una tarea redituable. Se recomienda el uso de las tablas de rastreabilidad para facilitar un poco el trabajo.
Aspecto especifico del sistema o su ambiente

A01
Requisito

A02

A03

A04

A05

Aii

R01 R02 R03

2008

Planificacin y Modelado

R04 R05

2008

Rnn

Figura 1.1 tabla de rastreabilidad

La gestin de requisitos comienza con la identificacin. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad. En la figura 1.1 se muestra de manera esquemtica una tabla de rastreabilidad, cada una de ellas relaciona los requisitos con uno o ms aspectos del sistema o de su ambiente. Entre las muchas tablas de rastreabilidad tenemos las siguientes: Tabla de rastreabilidad de las caractersticas. Muestra la manera en que los requerimientos se relacionan con las caractersticas del sistema/producto observables para el cliente. Tabla de rastreabilidad de la fuente. Identifica la fuente de cada requerimiento. Tabla de rastreabilidad de dependencia. Indica la forma en que los requisitos estn relacionados entre s. Tabla de rastreabilidad del subsistema. Establece categoras entre los requerimientos de acuerdo con los subsistemas que gobiernan. Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requerimientos se relacionan con las interfaces internas y externas del sistema.

En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requerimientos de forma que puede buscrseles con rapidez para entender cmo el cambio en un requisito afectar diferentes aspectos del sistema que se construir.

Herramientas de software para la ingeniera de requerimientos.

Planificacin y Modelado Las herramientas de la ingeniera de requerimientos ayudan en la recopilacin, modelado, gestin y validacin de los requerimientos. Mecnica. La mecnica de las herramientas varia. Por lo general, las herramientas de la ingeniera de requerimientos construyen una variedad de modelos grficos (por ejemplo, UML) que muestran los aspectos de informacin, funcionamiento y comportamiento de un sistema. Estos modelos forman la base para todas las otras actividades en el proceso del software.

1.2 Requerimientos de los usuarios (actores involucrados).

Ian Sommerville, establece en su Libro (Ingeniera de Software 6 edicin, Pearson Educacin), que algunos de los problemas que surgen durante el proceso de ingeniera de requerimientos son resultado de no hacer una clara separacin entre los diferentes niveles de descripcin. Esto se hace utilizando el trmino requerimientos del usuario, para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema, para designar la descripcin detallada de lo que es sistema debe de hacer. De igual forma que

2008

Planificacin y Modelado en estos dos niveles de detalle, se puede producir una descripcin ms detallada (una especificacin del diseo del software) para establecer un puente entre la ingeniera de requerimientos y las actividades de diseo. Los requerimientos del usuario, los del sistema y la especificacin del diseo del software se definen como se muestra a continuacin: 1. Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el diagrama provea y de las restricciones bajo las cuales debe operar. 2. Los requerimientos del sistema establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificacin funcional, debe ser preciso. ste sirve como un contrato entre el comprador del sistema y el desarrollador del software. 3. Una especificacin del diseo del software es una descripcin abstracta del diseo del software que es una base para un diseo e implementacin detallados. Esta especificacin agrega detalle a la especificacin de requerimientos del sistema. Definicin de requerimientos del usuario.
1. El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas. Especificacin de los requerimientos del sistema. 1.1 Al usuario se le proveer con los recursos para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo tendr una herramienta asociada que ser aplicada al archivo. 1.3 Cada tipo de archivo externo se representara como un icono especifico sobre la pantalla del usuario. 1.4 Se proveern recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el efecto de esta seleccin es aplicar la herramienta asociada con este tipo de Figura 1.2 Requerimientos del usuario y del sistema. archivo al archivo representado por el icono seleccionado.

Diferentes niveles de especificacin del sistema son de utilidad debido a que comunican la informacin del sistema a los diferentes tipos de lectores. La figura 1.2 ilustra la diferencia entre los requerimientos del usuario y del sistema. Muestra la manera en que un requerimiento del usuario se expande en varios requerimientos del sistema.
Administradores clientes. Usuarios finales del sistema. Ingenieros clientes. Administradores contratistas.

Requerimientos del usuario.

2008

Planificacin y Modelado

Ingenieros clientes (quizs). Arquitectos del sistema. Desarrolladores del software Figura 1.3 Lectores de los diferentes tipos de especificaciones. Especificacin del diseo del

Los requerimientos del usuario se redactan para el cliente y los contratistas administradores quienes no tienen un conocimiento tcnico detallado del sistema (vea la figura 1.3). La especificacin de requerimientos del sistema se orienta al personal tcnico y a los administradores del proyecto. Tambin lo utilizaran tanto el equipo de cliente como el del contratista. Los usuarios finales del sistema pueden leer ambos documentos. Finalmente, la especificacin del diseo del software es un documento orientado a la implementacin. Debe redactarse por los ingenieros de software que desarrollaran el sistema. 1.2.1 Requerimientos de los usuarios. 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 tcnico detallado. nicamente especifican el comportamiento externo del sistema y evitan, en tanto sea posible, las caractersticas del diseo del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementacin. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: 1. Falta de claridad. Algunas veces es difcil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y hacerlos fcil de leer. 2. Confusin de requerimientos. No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la informacin para el diseo. 3. Conjuncin de requerimientos. Diversos requerimientos diferentes se expresan de forma conjunta como un nico requerimiento.

2008

Requerimientos del sistema.

Usuarios finales del sistema. Ingenieros clientes. Arquitectos del sistema. Desarrolladores del software.

Planificacin y Modelado

La base de datos deber ayudar a la generacin y control de la configuracin de objetos; es decir, objetos que a su vez son agrupaciones de otros de la base de datos. Los recursos para este control permitirn el acceso a los objetos en una versin de grupo utilizando un nombre incompleto. Figura 1.4 un requerimiento de una base de datos para un entorno de programacin.

Para ilustrar algunos de estos problemas, considere uno de los requerimientos para un entorno de programacin Ada que se muestra en la figura 1.4. Este requerimiento incluye tanto informacin conceptual como detallada. Expresa la existencia de recursos de control de la configuracin como una parte inherente del APSE. Sin embargo, sta tambin incluye el detalle de que los recursos de control de la configuracin que permiten el acceso a los objetos en una versin de grupo sin especificar su nombre completo. Este detalle podra ubicarse mejor en la especificacin de requerimientos del sistema. Nota: APSE significa, Entorno de Ayuda a la programacin en Ada. En el documento de requerimientos es una buena prctica separar los requerimientos del usuario de los detallados del sistema. Por otra parte, los lectores no tcnicos de los requerimientos del usuario se confundirn con los detalles que slo son relevantes a los lectores tcnicos. La figura 1.5 ilustra esta confusin.
Recursos de la cuadrcula. Para ayudar a la ubicacin de entidades en un diagrama, el usuario activar una cuadricula en centmetros o en pulgadas, mediante una opcin en el panel de control. De forma inicial, dicha cuadrcula estar desactivada. sta cuadrcula se podr activar o desactivar en cualquier momento durante una sesin de edicin y puesta en pulgadas y en centmetros. La opcin de cuadrcula se proveer en la vista de reduccin de ajuste, pero el nmero de lneas de la cuadrcula a mostrar se reducir para evitar saturar el diagrama ms pequeo con lneas de cuadrcula.
Figura1.5 Un requerimiento de usuario para un editor de cuadrcula.

Este ejemplo se tom del documento de requerimientos para una herramienta CASE para editar modelos de diseo de software. El usuario especifica que se desplegar una cuadrcula para que las entidades se coloquen de forma precisa en un diagrama. La primera oracin mezcla tres diferentes clases de requerimientos. 1. Un requerimiento funcional conceptual que establece que el sistema de edicin proveer una cuadrcula. Se presenta la justificacin de esto. 2. Un requerimiento no funcional que provee informacin detallada de las unidades de la cuadrcula (centmetros o pulgadas). 3. Un requerimiento de interfaz de usuario no funcional que define la manera en que esa cuadrcula es activada o desactivada por el usuario.

2008

Planificacin y Modelado El requerimiento de la figura 1.5 tambin muestra un parte de la informacin de inicializacin. Define que la cuadrcula est inicialmente desactivada. Sin embargo, no define sus unidades cuando se activa. Provee alguna informacin detallada, como la de intercambiar unidades, pero no el espacio entre las lneas de la cuadrcula. Cuando los requerimientos del usuario incluyen demasiada informacin, restringen la libertad del desarrollador del sistema para proveer soluciones innovadoras a los problemas del usuario y hace que los requerimientos sean difciles de comprender. Los requerimientos del usuario simplemente deben enfocarse a los recursos principales a proveer. Esto se ilustra en la figura 1.6, donde se redactan nuevamente los requerimientos para el editor de la cuadrcula, con nfasis en las caractersticas esenciales del sistema.
Recursos de la cuadrcula. El editor deber proporcionar un recurso para la cuadrcula donde una matriz de lneas horizontales y verticales proporciona un fondo para la ventana del editor. Esta cuadrcula deber ser pasiva, donde la alineacin de entidades es responsabilidad del usuario. Fundamento: Una cuadrcula ayuda al usuario a crear un diagrama ordenado con entidades bien espaciadas. Aunque en una cuadrcula activa pueda ser de utilidad que las entidades se ajusten a las lneas de la cuadrcula, la ubicacin es imprecisa. El usuario es la mejor persona para decidir donde se deberan ubicar las entidades.
Figura 1.6 Una definicin de un recurso para el editor de cuadrcula.

La base asociada a los requerimientos es importante. Ayuda a los desarrolladores y mantenedores del sistema a entender por qu el requerimiento se incluye y a valorar el impacto de los cambios en stos. Por ejemplo, en la figura 1.6 la base declara que es de utilidad que una cuadrcula activa situ automticamente objetos a una lnea de la cuadrcula. Sin embargo, de forma deliberada se rechaza esta opcin cuando se hace una ubicacin manual. S en alguna etapa posterior se propone un cambio a esto, entonces es claro que la utilizacin de una cuadrcula pasiva es mucho mejor que una decisin de implementacin.
Adicin de nodos a un diseo. El editor deber proporcionar un recurso a los usuarios para agregar a su diseo nodos de un tipo especifico. La secuencia de acciones para agregar un nodo debera ser como se muestra a continuacin: 1. El usuario selecciona el tipo de nodo a agregar. 2. El usuario mueve el cursor a la proximidad de la posicin del nodo en el diagrama e indica que el smbolo de dicho nodo debe agregarse en este punto. 3. Despus el usuario arrastra el smbolo del nodo a su posicin final. Fundamento: El usuario es la mejor persona para decidir dnde ubicar un nodo en un diagrama. Este enfoque da al usuario control directo sobre la seleccin del tipo de nodo y sobre la ubicacin.

2008

Planificacin y Modelado

Figura 1.7 Requerimientos del usuario para la creacin de nodos.

Para minimizar las malas interpretaciones al redactar los requerimientos del usuario, se recomienda seguir unas pautas sencillas para redactar requerimientos: 1. Inventar un formato estndar y asegurar que todos los requerimientos se adhieren al formato. Estandarizar el formato significa reducir la probabilidad de las omisiones y hacer que los requerimientos sean fciles de verificar. El formato incluye poner en negritas el requerimiento inicial, que incluye una declaracin base para cada requerimiento del usuario, y una referencia a la especificacin detallada de los requerimientos para el sistema. 2. Utilizar el lenguaje de forma consistente. en particular, distinguir entre los requerimientos deseables y los obligatorios. Es comn definir estos ltimos en futuro simple y los deseables en futuro condicional como se muestra en la figura 1.7. por lo tanto es obligatorio que el sistema incluya un recurso para agregar nodos a un diseo. Es necesario que la sucesin de acciones se especifique. Pero no es absolutamente esencial si existe buenas razones para hacerlo. 3. Resalta el texto (con negritas o itlicas) para ver las partes claves del requerimiento. 4. Evitar, hasta donde sea posible, utilizar el lenguaje tcnico de computacin. Sin embargo, en los requerimientos de usuario ser inevitable utilizar trminos tcnicos detallados provenientes del dominio de aplicacin del sistema. 1.2.2 Actores involucrados. Los actores en los sistemas de informacin se dividen en cinco grupos: 1. Dueos del sistema. 2. Usuarios del sistema.

2008

En la figura 1.7 se muestra un ejemplo adicional de un requerimiento del usuario ms especfico, que tambin define parte del sistema de edicin. Esta es una especificacin ms detallada de la funcin. En este caso, la definicin incluye una lista de las acciones del usuario. Algunas veces, esto es necesario para que todas las funciones se proporcionen de forma consistente. Los detalles de la implementacin no deben incluirse en esta informacin adicional. Por lo tanto, la definicin no establece como se mueven el cursor y el smbolo, o cmo se selecciona el tipo.

Planificacin y Modelado 3. Diseadores de sistemas. 4. Constructores de sistemas. 5. Analistas de sistemas. A continuacin se exponen cada uno de estos grupos. 1.2.2.1 Dueos del sistema. Para cualquier sistema de informacin grande o pequeo habr uno o ms dueos del sistema, los dueos del sistema tienden a estar interesados en: Cunto costara el sistema? Cul ser el costo/beneficio? Cundo recuperaran la inversin y como la recuperaran?
2008

Y otras, las cuales son de inters econmico primordialmente. Este grupo es que paga por el sistema. 1.2.2.2 Usuario del sistema. Los usuarios del sistema son los que definen los requerimientos del negocio y las expectativas del sistema. Ellos ven a un sistema de informacin en trminos de la funcionalidad que provee a sus trabajos, en que sea fcil de aprender y de utilizar. Hay muchas clases de usuarios, pero para estudiarlos los separaremos en dos grandes clases: usuarios internos y usuarios externos dentro de los cuales se cuenta con ms subdivisiones las cuales se explican a continuacin:

Usuarios internos.
Son aquellos empleados del negocio para el cual se est construyendo el sistema y son el mayor porcentaje de usuarios de un sistema. Dentro de este grupo tenemos. Empleados administrativos y de servicios: realizan los procesos del da a da, procesan rdenes, facturas, pagos etctera. Ellos capturan los datos en el sistema. Staff tcnico y profesional: son empleados que realizan tareas especializadas ejemplo. Abogados, ingenieros, cientficos etctera. Supervisores mandos medios y ejecutivos: son los empleados que toman decisiones, ya sea decisiones del da a da (supervisores), de corto plazo (mandos medios) o largo plazo (ejecutivos).

Planificacin y Modelado

Usuarios Externos.
El uso de Internet ha permitido extender los lmites de las organizaciones, de forma que se ha generado un aumento de usuarios externos, dentro de los cuales podemos mencionar: Clientes: son cualquier organizacin o persona(s) que compren nuestros productos o servicios. Hoy da nuestros clientes se pueden convertir en usuarios directos, ya que pueden ejecutar rdenes y compras directamente al sistema, como por ejemplo las compras online. Surtidor o Proveedor: son cualquier organizacin en la cual nuestra compaa compre insumos. Hoy da nuestros proveedores pueden interactuar directamente con nuestros sistemas y determinar nuestra necesidad de insumos y crear de forma automtica ordenes con dichas necesidades. Socios: son cualquier organizacin a la cual nuestra compaa compre servicios o de la que sea socio. Ejemplo: mantenimiento, manejo de la red, outsourcing, etc. Empleados: son empleados que trabajan en el camino o en casa. Ejemplo: representantes de venta, empleados que puedan trabajar remotamente en el sistema.

La cantidad de usuarios externos ha ido en aumento en los ltimos tiempos, ellos se conectan a la informacin de la compaa a travs de laptos, handhelds y smartphones (ya se con conexin en bases o va inalmbrica) por lo que debemos tener presente el uso de estos dispositivos al momento de realizar el diseo del sistema. 1.2.2.3 Diseadores del sistema. Son tcnicos especializados que traducen los requerimientos de los usuarios del negocio en soluciones tcnicas. Ellos disean: bases de datos, entradas y salidas del sistema, pantallas, redes y software que se puede adaptar a los requerimientos del usuario. Un diseador del sistema puede pertenecer a algunas de las siguientes especialidades: Administrador de la base de datos. Son especialistas en bases de datos, se encargan de realizar el diseo de la base de datos, y la coordinacin de cambios en bases de datos corporativas. Arquitectos de redes. Se especializan en redes y telecomunicaciones.

2008

Planificacin y Modelado Arquitectos web. se encargan de disear sitios web para las organizaciones, generalmente de un alto grado de complejidad. Artistas grficos. Son especialistas en la tecnologa grafica y en mtodos de diseo de interfaces fciles de utilizar. (en pc, web, handheld, smartphones, etc). Expertos en seguridad. Son en especialistas en tecnologa y metodologas utilizadas para asegurar la integridad y la privacidad de los datos y la red. Especialistas en tecnologa. Son expertos en la aplicacin de tecnologas especficas que podran ser utilizadas en un sistema. Tanto en paquetes de software como en hardware con caractersticas especificas.

1.2.2.4 Constructores del sistema. Su rol es la construccin del sistema de acuerdo a las especificaciones dadas por el diseador de sistemas. Un constructor del sistema puede pertenecer a algunas de las siguientes especialidades: Programador de aplicaciones. son especialistas que convierten los requerimientos de la compaa en lenguajes de programacin. Ellos desarrollan y prueban programas de computacin que capturan y almacenan datos. Programadores de sistemas. son especialistas que desarrollan, prueban e implementan software a nivel de sistema operativo. Programadores de bases de datos. Son especialistas en tecnologas y lenguajes de bases de datos, que construyen, modifican y prueban las estructuras de las bases de datos as como los programas que se utilizan para darles mantenimiento a las mismas. Administradores de redes. Son especialistas que disean, instalan y optimizan las redes de computadoras. Administradores de seguridad. Son especialistas que disean, implementan y manejan la seguridad y controles de privacidad de una red. Webmaster. Son especialistas que codifican y dan mantenimiento a los servidores Web.

2008

Planificacin y Modelado Integradores de software. Son especialistas que integran paquetes de software con hardware, redes y otros paquetes de software.

Roles del analista de sistemas.

El analista de sistemas evala de manera sistemtica el funcionamiento de un negocio mediante el examen de la entrada, el procesamiento de datos y su consiguiente produccin de informacin, con el propsito de mejorara los procesos de una organizacin. Muchas mejoras incluyen un mayor apoyo a las funciones de negocio a travs del uso de sistemas de informacin computarizados. Un analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempea diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres principales roles del analista de sistemas son el de consultor, experto en soporte tcnico y agente de cambio. El rol de consultor del analista de sistemas. Con frecuencia, el Analista de Sistemas desempea el rol de consultor para un negocio y, por tanto podra ser contratado de manera especfica para enfrentar los problemas de sistemas de informacin de una empresa. Esta contratacin se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los dems miembros de una organizacin. Tambin se puede traducir en una desventaja porque alguien externo nunca conocer la verdadera cultura organizacional. En su funcin de consultor externo, usted depender en gran medida de los mtodos sistemticos que se deber aprender de los libros sobre el anlisis y diseo de sistemas de informacin. Adems tendr que apoyarse en los usuarios de los sistemas de informacin para entender la cultura organizacional desde el punto de vista que ellos tienen. El rol de experto en soporte tcnico del analista de sistemas. Otro rol que tendr que desempear es el de experto en soporte tcnico dentro de la empresa en la cual labora de manera regular. En este rol el analista recurre a su experiencia profesional con el hardware y software de cmputo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino ms bien la realizacin de pequeas modificaciones o la toma de decisiones que se circunscriben a un solo departamento.

2008

1.2.2.5 Analista de sistemas. Es un especialista que estudia los problemas y necesidades de una organizacin para determinar cmo las personas, datos, procesos y la tecnologa de la informacin pueden en conjunto mejorar un negocio.

Planificacin y Modelado Como experto en soporte tcnico, usted no est a cargo del proyecto, tan solo acta como recurso para aquellos que si lo estn. Si usted es un analista de sistemas contratado por una empresa manufacturera o servicios, gran parte de sus actividades podran ajustarse a este rol. El rol de agente de cambio del analista de sistemas. El rol ms completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un agente de cambio si desempea 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 ms de un ao). Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para el cambio y coopera con los dems para facilitar el cambio. Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar consciente de este hecho y utilizarlo como punto de partida para su anlisis. De ah que tenga que interactuar con los usuarios la administracin desde el principio del proyecto. Sin su colaboracin usted no podra entender lo que ocurre en una organizacin y el cambio real nunca se dara. Si el cambio (es decir, las mejoras al negocio que se pueden concretar mediante los sistemas de informacin) parece factible despus de efectuar el anlisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de autorizarlo. Una vez que se haya alcanzado el consenso acerca de los cambios por realizar, usted tendr que interactuar constantemente con quienes vaya a cambiar. En su calidad de analista de sistemas desempeando la funcin de agente de cambio debe promover un cambio que involucre el uso de los sistemas de informacin. Tambin es parte de su tarea ensear a los usuarios el proceso del cambio, ya que las modificaciones a un sistema de informacin no solo afecta a este sino que provocan cambios en el resto de la organizacin.
2008

Cualidades del analista de sistemas.

De las descripciones anteriores sobre los roles que desempea el analista de sistemas, se deduce fcilmente que el analista exitoso debe contar con una amplia gama de cualidades. Hay una gran diversidad de personas trabajando como analistas de sistemas, por lo que cualquier descripcin que intente ser general est destinada a quedarse corta en algn sentido. No obstante, la mayora de los analistas de sistemas tienen algunas cualidades comunes. En primer lugar, el analista es un solucionador de problemas. Es una persona que aborda como un reto el anlisis de problemas y que disfruta al

Planificacin y Modelado disear soluciones factibles. Cuando es necesario, el analista debe contar con la capacidad de afrontar sistemticamente cualquier situacin mediante la correcta aplicacin de herramientas, tcnicas y su experiencia.
2008

El analista tambin debe ser un comunicador con capacidad para relacionarse con los dems durante extensos periodos. Necesita suficiente experiencia en computacin para programar, entender las capacidades de las computadoras, recabar los requisitos de informacin 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 profesin de analista de sistemas es muy exigente; pero es una profesin en constante evolucin que siempre trae nuevos retos.

Planificacin y Modelado

1.3 Requerimientos para el anlisis y la negociacin.

2008

Una vez recopilados los requerimientos, el producto obtenido configura la base de los requerimientos para el anlisis. Los requerimientos se agrupan por categoras y se organizan en sub conjuntos, se estudia cada requerimiento en relacin con el resto, se examinan los requerimientos en su consistencia, completitud y ambigedad, y se clasifican en base a las necesidades de los clientes/usuarios. Es corriente en clientes y usuarios solicitar ms de lo que puede realizarse, consumiendo recursos de negocios limitados. Tambin es relativamente comn en clientes y usuarios el proponer requisitos contradictorios, argumentando que esa versin es esencial por necesidades especiales. Nota: el ingeniero de requerimientos debe resolver estos conflictos a travs de un proceso de negociacin. Los clientes, usuarios y el resto de intervinientes debern clasificar sus requerimientos y discutir los posibles conflictos segn su prioridad. Los riesgos asociados con cada requerimiento sern identificados y analizados. Se efectan 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 anlisis. En esta seccin se presenta el anlisis global de los requerimientos de una aplicacin, que es un proceso de conceptualizacin y expresin de los conceptos en forma concreta. La mayor parte de los defectos encontrados en el software entregado se originan durante la obtencin de los requerimientos para el anlisis. En general, estos defectos tambin son los ms caros de reparar. 1.3.1.1 Significado de requerimientos para el anlisis. Para construir algo primero debe entenderse lo que debe ser algo. El proceso de entender y documentar este algo se llama requerimientos para el anlisis. En general, los requerimientos expresan qu se supone debe hacer una aplicacin: por lo comn, no intentan expresar cmo lograr estas funciones. Por ejemplo, la siguiente afirmacin es un requerimiento para una aplicacin de contabilidad. El sistema debe permitir a los usuarios acceso a sus saldos. En trminos generales, la siguiente afirmacin no es un requerimiento para una aplicacin.

Planificacin y Modelado Los estados de cuenta del cliente se almacenarn en una tabla llamada saldos en una base de datos de Access. Esta ltima afirmacin se refiera a cmo debe de construirse la aplicacin, y no a qu debe hacer la aplicacin. Un requerimiento en un nivel con frecuencia se traduce en ms de un requerimiento especfico en el siguiente nivel ms detallado. Adems existen excepciones a la regla de que en los requerimientos se evite especificar cmo debe hacerse algo. Por ejemplo, el cliente del ejemplo del anterior podra, por alguna razn, querer que los estados de cuentas se almacenen en la base de datos de Access con el nombre indicado. En este caso, la segunda afirmacin sera un requerimiento. La salida de los requerimientos para el anlisis es un documento que se conoce como especificacin de requerimientos o especificacin de requerimientos de software (ERS). 1.3.1.2 Requerimientos C y requerimientos D. Durante algn tiempo se ha discutido quien es el dueo de los requerimientos: el cliente o el desarrollador. Para manejar este aspecto, el anlisis 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 especfica 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 estndar de IEEE para documentar los requerimientos. La distincin entre los tipos de requerimientos C y D en los ttulos principales de la plantilla del documento estndar del IEEE se ilustra en la figura 1.8.

ERS (IEEE) 1. Introduccin. 2. Descripcin global. 3. Requerimient os especficos. 4. Informacin de apoyo.

Requerimientos D

Requerimientos C

2008

Planificacin 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 comunicacin es hacer que representantes de los clientes trabajen junto con los desarrolladores. Algunas organizaciones de desarrollo se rehsan 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 cdigo fuente expresa todos los requerimientos: como el cdigo fuente es imprescindible, por qu no reducir el proceso completo a este documento esencial? La respuesta es que esto no funciona. La disciplina de ingeniera 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 cules 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 prcticas, no puede predecir el tamao y esfuerzo de su siguiente trabajo y no puede satisfacer a sus clientes. En resumen, no existe la ingeniera profesional sin los requerimientos escritos. Para ilustrar estos puntos, considere el siguiente requerimiento para una aplicacin cientfica. La aplicacin 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. Adems, 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 resultara si el requerimiento 7824 no estuviera escrito. Muy pocos de los pasos Ser de acceso sencillo. de los figura 1.9 se podran llevar a cabo de modo apropiado. No sera de sorprender que la aplicacin en cuestin no fuera confiable. Numerarse.
Acompaarse con pruebas que lo verifiquen. Tomarse en cuenta en el diseo. Tomarse en cuenta en el cdigo. Probarse aislado.

Validarse con las pruebas despus de construir la aplicacin.

Probarse junto con otros requerimientos.

2008

Planificacin y Modelado

Figura 1.9 lo que debe hacerse con cada requerimiento.

Cuando se contemplan los pasos de la figura 1.9 para todos y cada uno de los requerimientos, se obtiene una idea de por qu los ingenieros de software manejan de forma extensa los requerimientos individuales: son el acervo bsico ms importante de la profesin. 1.3.1.4 mapa conceptual tpico del proceso de requerimientos para el anlisis. La figura 1.10 es un mapa conceptual tpico del proceso de requerimientos para el anlisis descrito en este captulo. Este mapa conceptual se consultar durante cada iteracin. El ltimo paso de mapa rene los requerimientos D detallados. El equipo recolecta las mediciones de las etapas de este proceso para facilitar la estimacin de iteraciones y aplicaciones futuras.
1. Identificar el cliente.

2. Entrevistar representantes del cliente. Revisin con el cliente Identificar deseos y necesidades. Aprovechar herramientas de expresin. Bosquejar las GUI. Identificar el hardware. 3. Escribir requerimientos C en forma de documento estndar.
Para todas las etapas, supervisar mtricas por ejemplo: Tiempo indicado. Cantidad lograda. Pginas de requerimientos C. Minutos de interaccin con el cliente por pgina. Calidad autoevaluada (escala 1 a 10). Tasas de defectos en inspecciones.

4. inspeccionar los requerimientos C.

Con la aprobacin del cliente

5. Construir los requerimientos D.

Figura 1.10 Mapa conceptual tpico para los requerimientos C.

Existen varias formas para organizar la especificacin de requerimientos de software. Se usar y modificar el estndar IEEE830-1993 que muestra la figura 1.11. Tambin este es un estndar ANSI.

2008

Planificacin y Modelado Los ingenieros de software discuten los mritos de las distintas formas de documentacin de los requerimientos. La desventaja del estndar IEEE es que es bastante antiguo y necesita modificarse y ampliarse (para reflejar los avances en el anlisis y diseo orientados a objetos y el surgimiento de los aspectos de Internet). La ventaja del estndar IEEE es que abarca la mayor parte de los aspectos que deben 1. Introduccin. expresarse de una u otra forma. 1.1 Propsito.
1.2 Alcance 1.3 Definiciones, acrnimos y abreviaturas. 1.4 Referencias. 1.5 Panorama. Descripcin general. 2.1 Perspectiva del producto. 2.1.1Interfaces del sistema. 2.1.2Interfaces de usuario. 2.1.3Interfaces de hardware. 2.1.4Interfaces de software. 2.1.5Interfaces de comunicacin. 2.1.6Restricciones de memoria. 2.1.7Operaciones. 2.1.8Requerimientos de adaptacin del sitio. 2.2 Funciones de producto. 2.3 Caractersticas del usuario. 2.4 Restricciones. 2.5 Suposiciones y dependencias. 2.6 Distribucin de requerimientos. Requerimientos especficos. Informacin de apoyo.

2.

Figura 1.11 Contenido del estndar IEEE 830-1993: especificacin de requerimientos de software. Copyright 1994 IEEE.

1.3.1.5 Retos y beneficios del anlisis de requerimientos. Un requerimiento defectuoso (es decir, el que no se repara antes de terminar el documento de requerimientos) es muy costoso. Se estima que repararlo es entre 20 y 50 veces ms costo si se permite que pase durante todo el proceso de desarrollo. En trminos financieros, si el costo de encontrar y reparar un defecto en la etapa de requerimientos es $100, entonces el costo de encontrar y reparar ese mismo defecto al final del proceso de desarrollo es entre $2000 y $5000. Quin rechazara una inversin de $100 que garantiza un pago de $2000 a $5000 en un ao o en dos? Piense que cada bsqueda de los defectos en los requerimientos desde el inicio es una inversin de este tipo.
3. 4.

El dao que resulta de una mala experiencia del cliente con la aplicacin es un factor por completo adicional al gasto involucrado. Dado el gran beneficio de detectar y reparar defectos en la etapa de requerimientos, Por qu tantos proyectos sufren daos por un anlisis de requerimientos malo o falta del mismo? Una razn es que, por lo general, al principio de un proyecto los clientes no saben qu quieren o necesitan con exactitud. Los ingenieros que usan un proceso iterativo bien organizado renen requerimientos, disean segn stos y los implementan mediante iteraciones coordinadas. El anlisis de requerimientos es una necesidad, no un lujo. Considere sus defectos sobre las pruebas. La mayor parte de las organizaciones de desarrollo considera las pruebas una necesidad absoluta. Pero si alguien le proporcionara

2008

Planificacin y Modelado una caja negra con un cable morado, uno rosa y uno naranja que salen de ella, y le pidiera que lo probara, lo ms seguro es que se negara. Probarla ser imposible sin saber qu se supone que debe lograr! En otras palabras, sin requerimientos no es posible realizar pruebas adecuadas. Muchas organizaciones no describen los requerimientos. Esto no significa que no los usen slo quiere decir que los requerimientos existen en la mente de ciertos ingenieros de software. Cuando se considera la falta de efectividad general de los requerimientos no escritos, y el gran nmero de requerimientos en cada aplicacin real, junto con la realidad de la rotacin de personal, realmente sorprende el porcentaje tan grande de proyectos de software que nunca terminan? Un problema ms sutil se crea en las organizaciones que escriben los requerimientos para la iteracin inicial, construyen con ellos en mente, pero no actualizan el documento de requerimientos en las interacciones que siguen. La razn es que con frecuencia es ms difcil actualizar un documento de requerimientos que escribir la primera versin. (Esto subraya la importancia de la buena organizacin del documento.) Sin embargo, la situacin de que sea ms difcil actualizar no altera el hecho de que no escribir los requerimientos ocasionar un alto grado de dificultad. Un beneficio importante del anlisis de requerimientos es la comprensin y acuerdo de la aplicacin que se construir. Esta es la base de todo tipo de contratos. 1.3.2 Requerimientos para la negociacin. En un contexto ideal de la ingeniera de requerimientos, las tareas de inicio, obtencin y elaboracin determinan los requisitos con el suficiente detalle como para emprender los pasos subsecuentes de la ingeniera de software. Desgraciadamente, esto sucede muy rara vez. En realidad, el cliente y el desarrollador entran en un proceso de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caractersticas del sistema o producto frente al costo y el tiempo de colocacin en el mercado. El objetivo de esta negociacin 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, gente, presupuesto) a las que est sometido el equipo de software. un acuerdo es el arte de dividir el pastel de tal forma que cada uno piense que se qued con la rebanada ms grande. Las mejores negociaciones son aquellas que buscan un resultado del tipo ganar-ganar esto es, el cliente gana al obtener el sistema o producto que satisface la mayora de sus necesidades, y el equipo de software gana al trabajar con presupuestos y lmites de tiempo realistas y alcanzables.
2008

Planificacin y Modelado Bohem define un conjunto de actividades de negociacin en el inicio de cada iteracin del proceso del software. En lugar de la actividad sencilla de comunicacin con el cliente, se definen las siguientes actividades:
2008

1. Identificacin de los interesados calve en el sistema o subsistema. 2. Determinacin de las Condiciones ganadoras de los interesados. 3. Negociacin 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). La conclusin exitosa de estos pasos inciales asegura un resultado del tipo ganar-ganar, el cual se convierte en el criterio clave para continuar con las actividades subsecuentes de la ingeniera de software.

El arte de la negociacin. El aprendizaje del arte de la negociacin efectiva es una actividad que sirve a travs de la vida tcnica y personal. La consideracin de las siguientes directrices puede resultar muy valiosa: 1. Reconocer que no es una competencia. Para ser exitoso, ambos lados deben de tener el sentimiento de haber ganado o logrado algo. Las dos partes tendrn que haber llegado a un acuerdo. 2. Disear una estrategia. Decidir qu es lo que se deseara lograr; que es lo que la otra parte quiere alcanzar, y qu es lo que se va a hacer para que ambas cosas sucedan. 3. Requerimientos para la se debe pensar en formular una respuesta Escuchar de manera activa. no gestin. 1.4 mientras la otra parte est hablando. Es necesario escuchar es posible que se obtenga un conocimiento que ayudar a negociar de mejor manera la posicin propia. En 4. temas anterioreslos intereses de que parte. Si se quieren evitar los conflictos no Enfocarse en se estableci otra los requerimientos para los sistemas de computadora cambian yposicin inflexible. cambiarlos persiste durante la vida se debe de tomar una que el deseo de 5. No dejar requerimientos para la gestin es problema que debe ser del sistema. Losque se vuelva personal. Enfocarse en el un conjunto de actividades resuelto. al equipo de proyecto a identificar, controlar y rastrear los que ayudan 6. Ser creativo. Cuando existen situaciones de estancamiento no se debe tener requerimientos y los cambioscnones. en cualquier momento mientras se a stos miedo de pensar fuera de los desarrolla el proyecto.pactar. Una vez que se ha llegado a un acuerdo, no es 7. Estar listo para necesario esperar: se debe pactar dicho convenio y seguir adelante.

Nota: formalmente la recopilacin de los requerimientos para la gestin se inicia slo para proyectos grandes, los cuales tienen cientos de requerimientos identificables. En los proyectos pequeos esta funcin de la ingeniera de requerimientos es bastante menos formal.

Muchas de estas actividades son idnticas a las actividades de la gestin de la configuracin del software (GCS).

Planificacin y Modelado Durante el proceso del software, la comprensin del problema por parte de los stakeholders est cambiando constantemente. Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante del problema. Adems, una vez que un sistema se ha instalado, inevitablemente surgen nuevos requerimientos. Es difcil para los usuarios y clientes del sistema anticipar qu efecto tendr el sistema nuevo en la organizacin. Cuando los usuarios finales tienen experiencia con un sistema, descubren nuevas necesidades y prioridades: 1. Normalmente, los sistemas grandes tienen una comunidad de usuarios diversa donde los usuarios tienen diversos requerimientos y prioridades. Los requerimientos finales del sistema son inevitablemente un compromiso entre ellos. 2. Las personas que pagan por el sistema y los usuarios de ste raramente son la misma persona. Los clientes del sistema imponen requerimientos debido a las restricciones organizacionales y de presupuesto. Esto puede estar en conflicto con los requerimientos de los usuarios finales y, despus de la entrega, pueden tener que aadirse nuevas caractersticas de apoyo al usuario si el sistema tiene que cumplir su objetivo. 3. El entorno de negocios y tcnico del sistema cambia despus de la instalacin, y estos cambios se deben reflejar en el sistema. Se puede introducir nuevo hardware, puede ser necesario que el sistema interacte con otros sistemas, las prioridades de negocio pueden cambiar con modificaciones consecuentes en la ayuda del sistema, y puede haber una nueva legislacin y regulaciones que deben ser implementadas en el sistema. La gestin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema. Es necesario mantenerse al tanto de los requerimientos particulares y mantener vnculos entre los requerimientos dependientes de forma que pueda evaluar el impacto de los cambios en los requerimientos. Hay que establecer un proceso formal para implementar las propuestas de cambios y vincular stos a los requerimientos del sistema. El proceso de gestin de requerimientos debera empezar en cuanto est disponible una versin preliminar del documento de requerimientos, pero se debera empezar a planificar cmo gestionar los requerimientos que cambian durante el proceso de obtencin de requerimientos.
2008

Planificacin y Modelado 1.4.1 Requerimientos duraderos y voltiles La evolucin durante el proceso de ingeniera de requerimientos y despus de que un sistema est en uso es inevitable. El desarrollo de requerimientos software centra su atencin en las capacidades de este, los objetivos del negocio y otros sistemas de la organizacin. Conforme se van desarrollando la definicin de los requerimientos, normalmente tiene una mejor comprensin de las necesidades de los usuarios. Esto retroalimenta la informacin del usuario, quien puede entonces posponer un cambio en los requerimientos (figura 1.12). Adems, especificar y desarrollar un sistema grande puede llevar varios aos. Durante ese tiempo, el entorno del sistema y los objetivos del negocio cambian, y los requerimientos evolucionan para reflejar esto.

Figura 1.12 evolucin de los requerimientos

Desde una perspectiva evolutiva, los requerimientos se dividen en dos clases: 1. Requerimientos duraderos, Son requerimientos relativamente estables que se derivan de la actividad principal de la organizacin y que estn relacionados directamente con el dominio del sistema. Por ejemplo, en el hospital siempre habr requerimientos que se refieren a los pacientes, mdicos, enfermeras y tratamientos. Estos requerimientos se pueden derivar de los modelos del dominio que muestran las entidades y relaciones que caracterizan un dominio de aplicacin.

2. Requerimientos voltiles, Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o despus de que este se haya puesto en funcionamiento. Un ejemplo seran los requerimientos resultantes de las polticas gubernamentales sobre la sanidad. Harker y otros han indicado que los requerimientos voltiles se dividen en 5 clases. Utilizando estas como base, se ha desarrollado la clasificacin mostrada en la figura 1.13.

2008

Planificacin y Modelado Requerimientos cambiarios Requerimientos que cambian debido a los cambios en el entorno en el que opera la organizacin. Por ejemplo, en los sistemas hospitalarios, el pago del cuidado del paciente puede cambiar y as requerir un tratamiento diferente la informacin a recopilar. Requerimientos que emergen al incrementarse la comprensin del cliente en el desarrollo del sistema. El proceso de diseo puede revelar requerimientos emergentes nuevos. Requerimientos que son resultado de la introduccin del sistema informtico. Esta introduccin puede cambiar los procesos de la organizacin y desarrollar nuevas formas de trabajar que generan nuevos requerimientos del sistema. Requerimientos que dependen de sistemas particulares o procesos de negocios dentro de la organizacin. Cuando estos ltimos cambian, los requerimientos de compatibilidad del sistema encargado o entregado tambin pueden cambiar.

Requerimientos emergentes

Requerimientos consecuentes

Requerimientos de compatibilidad

Figura 1.13 clasificacin de los requerimientos voltiles.

1.4.2Planificacin de la gestin de requerimientos. La planificacin es una primera etapa esencial del proceso de gestin de requerimientos. La cual tiene un coste elevado. Para cada proyecto la etapa de planificacin establece el nivel de detalle necesario en la gestin de requerimientos. Durante la etapa de gestin de requerimientos, habr que decidir sobre: 1. La identificacin de requerimientos. 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.

2008

Planificacin y Modelado 2. Un proceso de gestin del cambio. Este es conjunto de actividades que evalan el impacto y coste de los cambios. 3. Polticas de rastreo. Esta poltica define las relaciones entre los requerimientos, y entre stos y el diseo del sistema que se debe registrar y la manera en que estos registros se deben mantener. 4. Ayuda de herramientas CASE. La gestin de requerimientos comprende el procesamiento de grandes cantidades de informacin sobre los requerimientos. Las herramientas que se pueden utilizar van desde sistemas de gestin de requerimientos especializados hasta hojas de clculo y sistemas sencillos de bases de datos. 1.4.3 Gestin de cambio de los requerimientos Se debe aplicar a todos los cambios propuestos en los requerimientos. 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. Existen 3 etapas principales en un proceso de gestin de cambio: 1. Anlisis del problema y especificacin del cambio. El proceso empieza con la identificacin de un problema en los requerimientos o, algunas veces, con una propuesta de cambio especfica. Durante esta etapa, el problema o la propuesta de cambio se analizan para verificar que esta es vlida.

2. Anlisis del cambio y clculo de costes. El efecto de un cambio propuesto se valora utilizando la informacin de rastreo y el conocimiento general de los requerimientos del sistema. Coste de hacer un cambio se estima en trminos de modificaciones al documento de requerimientos y, si es apropiado, al diseo e implementacin del sistema.

3. Implementacin del cambio. Se modifica el documento de requerimientos y, en su caso el diseo e implementacin del sistema. 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. Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe siempre la tentacin de hacer ese cambio al sistema y entonces modificar de forma retrospectiva el documento de requerimientos.

2008

Planificacin y Modelado Esto conduce casi inevitablemente a que la especificacin de requerimientos y la implementacin del sistema se desfasen.

Unidad 2
Planificacin del sistema
La planeacin de proyectos de software es una parte esencial de la ingeniera del software. La buena gestin no puede garantizar el xito del proyecto, pero la mala llevara al fracaso del proyecto. La administracin efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El administrador del proyecto debe anticiparse a los problemas que podran surgir, as como preparar soluciones tentativas a esos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto. Este plan inicial debe ser el mejor posible de acuerdo con la informacin disponible. Este evolucionara conforme el proyecto progrese y la informacin disponible ser mejor. Los administradores tienen que preparar planes de trabajo, para llevar a cabo mejor el sistema y tener un control sobre el trabajo algunos de estos planes se muestran en la figura 2.1: Plan Plan de calidad Descripcin Describe los procedimientos y estndares de calidad

2008

Planificacin y Modelado que se utilizaran en un proyecto. Plan de validacin Describe el enfoque, los recursos y la programacin utilizados para la validacin del sistema.
2008

Plan de la Describe los procedimientos de administracin de la administracin de configuracin y las estructuras a utilizarse. la configuracin Plan mantenimiento de Predice los requerimientos de mantenimiento del sistema, los costos de mantenimiento y el esfuerzo requerido.

Plan de desarrollo Describe cmo se desarrollan las habilidades y personal experiencia de los miembros del equipo del proyecto.
Figura 2.1 planes de trabajo.

Los gestores de software son responsables de la planificacin y temporalizacin del desarrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estndares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto. La administracin de proyectos de software es necesaria debido a que la ingeniera de software profesional siempre est sujeta a restricciones organizacionales de tiempo y presupuesto. 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 compaa de desarrollo de software. Los gestores de software hacen el mismo trabajo que otros gestores. Sin embargo, la ingeniera del software es diferente en varios aspectos a otros tipos, lo que hace la gestin de software particularmente difcil. La gestin de proyectos de software es un tema amplio y no puede tratarse en un solo tema; es necesario abordar temas como la planificacin del tiempo, la evaluacin de costos, la planificacin de la documentacin, el estudio de la viabilidad, entre otros temas.

Plan de proyecto
Este plan fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo. En algunas organizaciones, el plan del proyecto es un nico documento que incluye todos los diferentes tipos de planes mencionados anteriormente en la tabla; en otros casos solo se refiere al proceso de desarrollo y en otros puede estar referenciado, pero son proporcionados por separado.

Planificacin y Modelado La estructura general de cualquier plan lleva los siguientes puntos, aunque pueden variar un poco segn el tipo de proyecto o el lugar en que se quiera aplicar:
2008

Introduccin: describe brevemente los objetivos del proyecto y expone las restricciones que afectan la administracin del proyecto. Organizacin del proyecto: describe la forma en que el equipo de desarrollo de desarrollo est organizado, la gente involucrada y sus tareas en el equipo. Anlisis de riesgo: describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reduccin de riesgos propuestas. Requerimientos de recursos de hardware y software: describe el hardware y la ayuda de software requerida para llevar a cabo el desarrollo. Si es necesario comprar hardware, se deben incluir los estimados de los precios y las fechas de entrega. Divisin del trabajo: describe la divisin del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad Programa del proyecto: describe las dependencias entre actividades, el tiempo estimado requerido para alcanzar cada hito y la asignacin de la gente a las actividades. Mecanismos de supervisin e informe: describe la administracin de informes y cuando deben producirse, as como los mecanismos de supervisin del proyecto a utilizar.

El plan de proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como el calendario del proyecto, cambiaran frecuentemente; otras sern ms estables. Debe utilizarse una organizacin documental que permita reemplazar fcilmente las secciones.

2.1 Planificacin del tiempo.

La planificacin es una parte muy demandante para los administradores de software, ya que deben estimar el tiempo y los recursos para completar y programar las actividades en forma coherente; en caso de existir un proyecto previo parecido, se puede tomar como base su planificacin adaptndola al

Planificacin y Modelado nuevo proyecto, aunque esto se complica cuando el nuevo proyecto utiliza mtodos de diseo y lenguajes de implementacin diferentes. Si el proyecto es tcnicamente complejo, las estimaciones inciales de tiempo pueden variar con las estimaciones finales, ya que durante el proceso pueden salir imprevistos que pueden ir retrasando el proyecto, por lo que es recomendable ir actualizando la calendarizacin mediante se vaya progresando en dicho proyecto. Para calendarizar el proyecto, se debe separar en actividades complementarias y considerar el tiempo para llevar acabo dichas actividades (figura 2.2); 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 simultneamente o paralelamente.

Identificar actividades

Identificar dependencias de actividades

Estimar recursos para las actividades

Asignar personas a las actividades

Crear grficos de proyecto

Requerimient os de software
Figura 2.2 actividades complementarias de un proyecto.

Redes de actividades y grficos de

Normalmente, cada actividad debe durar por lo menos una semana, y como mximo de 8 a 10 semanas, si se estima ms tiempo, se deben hacer mas subdivisiones. En la elaboracin de la calendarizacin, los administradores deben contemplar que cada etapa puede tener problemas, ya que pueden pasar distintas fallas o pudieran ser ms complicadas, por lo que se llevara ms tiempo del estimado inicialmente. Un mtodo es estimar como si no saliera nada mal, entonces se debe incrementar esta estimacin para problemas no previstos; este aumento ser a partir del tipo de proyecto, de los parmetros y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. Por lo general, el calendario del proyecto se representa como un conjunto de grficos que muestran la divisin del trabajo, las dependencias de las actividades y la asignacin del personal; las herramientas de administracin

2008

Planificacin y Modelado de software, como Microsoft Project, se utilizan para automatizar la produccin de diagramas. 2.1.1 Grficos de barras y redes de actividades. Los grficos de barra y las redes de actividades son notaciones graficas que se utilizan para ilustrar la calendarizacin del proyecto. Los grficos de barras muestran quien es responsable de cada actividad y cuando se debe comenzar y finalizar sta; las redes de actividades muestran las dependencias entre las diferentes actividades que conforman un proyecto; ambos se generan automticamente a partir de una base de datos de la informacin del proyecto utilizando una herramienta de administracin de proyectos. Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11
14/7/ 99 das Figura 2.3 tabla de actividades.

Duracin (das) 8 15 15 10 10 5 20 25 15 15 7
15 das

Dependencias

T1 (M1)

T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T9 T11 (M8)
25/8/9 9

T12

10

T3 4/8/99 M1 un conjunto de actividades, las cualesM6 representadas son M4 por la tabla de la figura 2.3 anterior; esta tabla nos ensea que actividades son 5 das das dependientes de otras, as como las que no tienen dependencia:7 por ejemplo, T1 4/7/9 para llevar a cabo la actividad T3, es necesario llevar a cabo la actividad T1, as 9 T1 T6 25/7/99 como T2 se puede realizar de manera paralela a T1. Dadas las dependencias y 1 INICI la duracin estimada de las actividades, se puede realizar una red de O M3 actividades, la cual muestra la sucesin de actividades que deben generarse, 5/9/99 20 das 15 ya sea dependientes o paralelas unas de otras; la figura 2.4 ilustra esto: das M8 T7 11/8/9 15 das T2 25/7/9 10 9 10 das 9 M7 10 das das 15 T1 T4 das M2 T5 2 T1
8 Se das considera

M5

T8

FINA L

18/7/9 9

25 das

2008

Planificacin y Modelado

19/9/9
Figura 2.4 red de actividades.

Las actividades se representan con rectngulos, los hitos y los productos a entregar por el proyecto se muestran con esquinas redondeadas; la red se debe lee de izquierda a derecha y de arriba hacia abajo. Todas las actividades deben terminar en hitos; una actividad comienza cuando su hito precedente ha sido alcanzado; tambin otra caracterstica, es que antes de que pueda pasar de un hito a otro, todas las trayectorias deben completarse. El tiempo total se calcula en base a la trayectoria ms larga de la red, en este caso esta remarcada la trayectoria ms larga, que es de 11 semanas o 55 das laborales. Cualquier aplazamiento en la trayectoria crtica provoca el retraso en el proyecto. Los grficos de proyecto (figura 2.5) es otra manera de representar la informacin del calendario; es un grafico de barras que muestra el calendario y las fechas inciales y finales de las actividades. Algunas de las actividades que se muestran son seguidas por una barra sombreada cuya longitud es calculada por una herramienta de calendarizacin. Esto muestra que existe alguna flexibilidad en las fechas de terminacin de estas actividades.

2008

Planificacin y Modelado

Figura 2.5 ejemplo grfica de proyecto.

2008

Planificacin y Modelado

2.2 Evaluacin del costo beneficio.

La estimacin y la calendarizacin del proyecto se llevan a cabo de forma conjunta. Sin embargo, en las primeras etapas del proyecto se requieren algunas estimaciones de costos, antes de que se tenga la calendarizacin detallada. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente. Una vez que el proyecto se encamina, las estimaciones se actualizan de forma regular; esto ayuda al proceso de planeacin y permite la utilizacin efectiva de los recursos. Si el gasto real es significativamente ms grande que las estimaciones, entonces el administrador del proyecto debe tomar algunas acciones. Estas pueden ser solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar. Existen tres parmetros involucrados en el clculo del costo total de un proyecto de desarrollo de software: los costos de hardware y software, incluyendo el mantenimiento los costos de viajes y capacitacin los costos de esfuerzo (los costos de pago a los ingenieros de software
2008

En muchos proyectos, el costo dominante es el costo de esfuerzo. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos, son relativamente bajos para muchos proyectos; el uso de fax, correos electrnicos y teleconferencias reduce los viajes requeridos. Los costos de esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. Las organizaciones calculan los costos de esfuerzos en trminos de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organizacin y dividen este entre el nmero de personas productivas. Por lo tanto, los siguientes costos son parte de los costos de esfuerzo totales: los costos de proveer, calentar e iluminar las oficinas los costos de personal de apoyo como los contadores, secretarias, limpiadores y tcnicos

Planificacin y Modelado los costos de las redes y las comunicaciones los costos de los recursos centralizados como las bibliotecas, los recursos recreativos, etc.
2008

Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud. El costo de un proyecto es de inters continuo y vital para los coparticipes. Con el precio de produccin equivocado, incluso el sistema ms fantstico puede ser un desastre. La estimacin de costo ms sencilla es la que proporciona un costo fijo desde el principio, sin permitir desviaciones en ninguna circunstancia. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes para cumplir con un costo predeterminado, la rigidez absoluta en el costo no siempre se adopta. El proceso de estimar costos con frecuencia comienza desde la concepcin del proyecto y contina aun despus de iniciada la codificacin. Cuando se inicia un proyecto, tal vez el equipo tenga solo una idea vaga de su costo. Si la estimacin del costo se puede posponer hasta que el proyecto tome forma, sin duda deben esperar, 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 diseo se realice, ms preciso ser el costo. Una buena manera de enfocar la estimacin de costos del proyecto durante las primeras etapas es desarrollar estimaciones de varias maneras independientes y despus combinar los resultados. Incluso se pueden ponderar las estimaciones obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas. 2.2.1 Productividad. La productividad en un sistema de manufactura se mide contando el nmero de unidades que se producen y dividiendo ste entre el nmero de personashora requeridas para producirlas. Sin embargo, para cualquier problema de software, existen muchas soluciones diferentes con distintos atributos. Una solucin poda ejecutarse de forma ms eficiente mientras que otra podra ser ms legible y fcil de mantener. Cuando se producen soluciones con diferentes atributos, no tiene sentido comparar estas tasas de produccin. Sin embargo, los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software. Estas estimaciones son necesarias para la estimacin del proyecto y para valorar si los procesos o las mejoras tecnolgicas son efectivos. Por lo general, estas estimaciones de productividad se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de medidas utilizadas:

Planificacin y Modelado Medidas relacionadas con el tamao: estas se relacionan con el tamao de alguna salida de una actividad. La mediad ms comn relacionada con el tamao son las lneas de cdigo fuente entregadas. Otras medidas que se utilizan son el numero de instrucciones de cdigo objeto entregado o el nmero de pginas de la documentacin del sistema. Medidas relacionadas con la funcin: estas se relacionan con la funcionalidad total del software entregado. La productividad se expresa en trminos de la cantidad de funcionalidad til producida en un tiempo dado. Los puntos de funcin y los puntos de objeto son las medidas ms conocidas de este tipo. Las lneas de cdigo fuente por programador-mes son una mtrica ampliamente utilizada en la medida de la productividad. Esta se calcula contando el nmero total de lneas del cdigo fuente que se entrega. La cuenta se divide entre el tiempo total de programadores-mes requeridos para completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requerido para el anlisis y diseo, codificacin, pruebas y documentacin. 2.2.2 Tcnicas de estimacin. No existe una forma simple de hacer una estimacin precisa del esfuerzo requerido para desarrollar un sistema de software. Las estimaciones inciales se hacen bajo la base de la definicin de requerimientos de usuario de alto nivel. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologas de desarrollo. Probablemente no se conozcan las personas involucradas en el proyecto y sus habilidades. Todos estos factores significan que en una primera etapa del proyecto es difcil producir una estimacin precisa de los costos de desarrollo del sistema. Existe una dificultad para valorar la precisin de los diferentes enfoques de las tcnicas de estimacin de costos. Por lo general, las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. La estimacin se utiliza para definir el presupuesto del proyecto y el producto se ajusta para que las cifras del presupuesto se cumplan. No se conocen informes de experimentos controlados sobre los costos de los proyectos donde los costos estimados no se utilicen para ajustar el experimento. Un experimento controlado no revelara la estimacin del costo al administrador del proyecto. Los costos reales tendran que compararse con los estimados del proyecto. A pesar de esto, las organizaciones necesitan hacer esfuerzos de software y estimaciones de los costos. Para hacerlo, se utilizan una o ms de las tcnicas descritas en el cuadro de la figura 2.6: Tcnica Modelado Descripcin Se desarrolla un modelo utilizando informacin histrica de

2008

Planificacin y Modelado del algoritmo de costos costos que relaciona alguna mtrica de software con el costo del proyecto. Se hace una estimacin de esa mtrica y el modelo predice el esfuerzo requerido.
2008

Opinin de expertos

Se consultan varios expertos en las tcnicas de desarrollo de software propuestas y en el dominio de la aplicacin. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discuten. El proceso de estimacin se itera hasta que se acuerda una estimacin.

Estimacin por analoga

Esta tcnica es aplicable cuando otros proyectos en el mismo dominio de la aplicacin se han completado. Se estima el costo de un nuevo proyecto por analoga con estos proyectos completados. Myers (1989) da una descripcin muy clara de este enfoque.

Ley de Parkinson

La ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles ms que por los objetivos logrados. Si el software se tiene que entregar en 12 meses y se dispone de 5 personas, el esfuerzo requerido se estima en 60 personasmes.

Asignar precios para ganar

El costo del software se estima independientemente de lo que el cliente est dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software.

Figura 2.6 tcnicas de esfuerzos de software y estimaciones de costos.

Cada tcnica de estimacin tiene sus propias fortalezas y debilidades. Para proyectos grandes, se deben utilizar varias tcnicas de estimacin de costos y comparar sus resultados. Si estos predicen costos radicalmente diferentes, esto indica que no se tiene suficiente informacin para generar los costos. Se debe buscar ms informacin y repetir el proceso hasta que la estimacin converja.

Planificacin y Modelado Estas tcnicas de estimacin son aplicables cuando existe un documento de requerimientos para el sistema. Este define a todos los usuarios y los requerimientos del sistema. Por lo tanto, se puede generar una estimacin razonable de la amplitud de la funcionalidad del sistema a desarrollar. En general, los proyectos grandes de ingeniera de sistemas normalmente tendrn tal documento de requerimientos. 2.2.3 Modelo algortmico de costos. El enfoque ms sistemtico, aunque no necesariamente el ms preciso, para la estimacin del software es la estimacin algortmica de costos. Un modelo algortmico de costos se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una frmula matemtica para predecir los costos basados en estimaciones del tamao del proyecto, numero de programadores y otros factores de los procesos y productos. Kitchenham (1990) describe 13 modelos algortmicos de costos desarrollados a partir de observaciones empricas. Muchos de los modelos de estimacin algortmica tienen un componente exponencial. Esto refleja el hecho de que los costos normalmente no se incrementen linealmente con el tamao del proyecto. Puesto que el tamao del software crece, se incurre en costos extra como sobrecarga de comunicaciones de equipos grandes, administracin ms compleja de la configuracin, integracin ms difcil del sistema, etc. Tambin se incluye multiplicadores que reflejan los atributos de los productos a desarrollar, la plataforma de desarrollo, el proceso y los desarrolladores del software. En su forma ms general, una estimacin algortmica de costos para el software se expresa como: Esfuerzo= A x TamaoB x M En la formula, A es un factor constante que depende de las practicas organizacionales locales y del tipo de software que se desarrolla. Tamao es una valoracin del tamao del cdigo del software o una estimacin de la funcionalidad expresada en puntos de funciones o de objetos. El valor del exponente B por lo general se encuentra entre 1 y 1.5. Refleja el esfuerzo requerido para proyectos grandes. M es un multiplicador generado al combinar diferentes procesos, atributos del producto y del desarrollo. Todos los modelos algortmicos padecen las mismas dificultades bsicas: A menudo es difcil estimar el Tamao en una primera etapa de un proyecto donde solamente est disponible la especificacin. Las estimaciones de los puntos de funcin y los puntos de objeto son ms fciles de producir que las del tamao del cdigo pero pueden ser imprecisas.

2008

Planificacin y Modelado Las estimaciones de los factores B y M son subjetivas. Las estimaciones varan de una persona a otra, dependiendo de su conocimiento y experiencia. El nmero de lneas de cdigo fuente en un sistema terminado es la mtrica bsica utilizada en muchos de los modelos algortmicos de costos. La estimacin del tamao puede comprender la estimacin por analoga con otros proyectos, la de convertir los puntos de funcin al tamao del cdigo, la de los valores del tamao de los componentes del sistema y la utilizacin de un componente de referencia conocido para estimar el tamao de los componentes, o simplemente puede ser una cuestin de juicio de ingeniera.

2.3 Estudio de viabilidad.

Este estudio es con el que debe empezar el proceso de ingeniera de requerimientos; la entrada de este es un conjunto de requerimientos de negocio preliminares, una descripcin resumida del sistema y de cmo ste pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberan ser un informe que recomiende si merece o no la pea seguir con la ingeniera 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 organizacin? Se puede implementar el sistema utilizando la tecnologa actual y dentro de las restricciones de coste y tiempo?

2008

Planificacin y Modelado Puede integrarse el sistema con otros sistemas existentes en la organizacin?

En este tipo de estudio, se puede consultar las fuentes de informacin, como los jefes de los departamentos donde se utilizara el sistema, los ingenieros de software que estn familiarizados con el tipo de sistema propuesto, los expertos en tecnologa y los usuarios finales del sistema. Normalmente, se debera intentar completar un estudio de viabilidad en2 o 3 semanas. Una vez que se tiene la informacin, se redacta el informe del estudio de viabilidad. Debera hacerse una recomendacin sobre si debe continuar o no con el desarrollo del sistema. En el informe, se pueden proponer cambios en el alcance, el presupuesto y la confeccin de agendas del sistema y sugerir requerimientos adicionales de alto nivel para ste.

2.4 Planificacin de la documentacin.

La documentacin es la sangre que alimenta la ingeniera de software. Esto incluye la documentacin separada del cdigo, al igual que la documentacin asociada con l. Para entender la importancia de la documentacin integral, imagine que le piden participar en un proyecto de software que ya est en marcha. Dada la complejidad potencial involucrada, sera lo mismo que le pidieran aprender, por ejemplo, un aspecto de la patologa sangunea. Para hacerlo, querra un panorama global del tema, la motivacin para conocerlo, un

2008

Llevar a cabo un estudio de viabilidad comprende la evaluacin y recopilacin de la informacin y la redaccin de informes. La fase de evaluacin de la informacin identifica la informacin requerida para contestar las preguntas anteriores. Una vez que dicha informacin se ha identificado, se debera hablar con las fuentes de informacin para descubrir las respuestas a estas preguntas.

Planificacin y Modelado flujo ordenado desde el panorama general hasta los detalles, diagramas con las interrelaciones, numerosas notas acerca de implementaciones especficas, entre otros. Las omisiones o contradicciones haran difcil o imposible entender que sucede. 2.4.1 El documento de requerimientos del software. El documento de requerimientos del software (algunas veces denominado especificacin de requerimientos del software o SRS) es la declaracin oficial de qu deben implementar los desarrolladores del sistema. Debe incluir tanto los requerimientos del usuario para el sistema como una especificacin detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se pueden integrar en una nica descripcin. En otros, los requerimientos del usuario se definen en una introduccin a la especificacin de los requerimientos del sistema. Si existe un gran nmero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar en un documento separado. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organizacin que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software. La figura 2.7 tomada del libro sobre ingeniera de requerimientos de Gerald Kotonya e Ian Sommerville, ilustra los posibles usuarios del documento y como lo utilizan. La diversidad de posibles usuarios significa que el documento de requerimientos tiene que presentar un equilibrio entre la comunicacin de los requerimientos a los clientes, la definicin de los requerimientos en el detalle exacto para los desarrolladores y probadores, y la inclusin de la informacin sobre la posible evolucin del sistema. La informacin sobre cambios previstos puede ayudar a los diseadores del sistema a evitar decisiones de diseo restrictivas y a los ingenieros encargados del mantenimiento del sistema, quienes tienen que adaptar el sistema a los nuevos requerimientos. 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. Cuando del sistema se desarrolle por un contratista externo, las especificaciones de los sistemas crticos necesitan ser claras y muy detalladas. Cuando haya ms flexibilidad en los requerimientos y cuando se utilice un proceso de desarrollo iterativo dentro de la empresa, el documento de requerimientos puede ser mucho menos detallado y cualquier ambigedad resuelta durante el desarrollo del sistema.
2008

Planificacin y Modelado

Figura 2.7 usuarios del documento de requerimientos. Varias organizaciones grandes, como el Departamentos de Defensa de los Estados Unidos y el IEEE, ha definido estndares para los documentos requeridos. Davis analiza algunos de estos estndares y compara sus contenidos. El estndar ms ampliamente conocido es el IEEE/ANSI 830-1998. Este estndar IEEE sugiere la siguiente estructura para los documentos de requerimientos:

2008

Planificacin y Modelado

2.5 Gestin de la configuracin del software.

La gestin de la configuracin del software es uno de los procesos clave para toda organizacin dedicada a la Ingeniera del Software, ya que posibilita una mejor organizacin del desarrollo y mantenimiento, producto, facilitando el resto de procesos de produccin. Durante el proceso de construccin de un software, los cambios son inevitables. Los cambios provocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniera. El arte de coordinar el desarrollo de software para minimizarla confusin, se denomina gestin de la configuracin. La gestin es el arte de identificar, organizar y controlar las modificaciones que sufre el software la meta es maximizar la productividad minimizando errores. Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para: Identificar el cambio de nuestro software.

2008

Planificacin y Modelado Controlar ese cambio. Garantizar que el cambio quede bien implantado.
2008

Informar el cambio. La gestin de configuracin del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniera hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina slo una vez que el software queda fuera de circulacin. Desgraciadamente, en el proceso de ingeniera del software existe una variable importantsima que entra en juego, el cambio. La primera Ley de la ingeniera de sistemas establece: Sin importar en qu momento del ciclo de vida del sistema nos encontremos, el sistema cambiar y el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida. 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. Nuevas necesidades del los clientes que demandan la modificacin de los datos producidos por un sistema basado en computadora. Reorganizacin y/o reduccin del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniera del software. Restricciones presupuestarias o de planificaciones que provocan una redefinicin del sistema o del producto. La gestin de configuracin 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. La GCS es una actividad de garanta de calidad del software que se aplica en todas las fases del proceso de ingeniera del software. 2.5.1. Lneas base. Una lnea base es un concepto de gestin de configuracin del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una lnea base como:

Planificacin y Modelado Una especificacin o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ah en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a travs de procedimientos formales de control de cambios. Una forma de describir la lnea base es mediante una analoga. Considere las puertas de la cocina de un gran restaurante. 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 direccin apropiada. 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, puede cambiar el plato correcto rpidamente informalmente antes de salir de la cocina. Sin embargo, si abandona la cocina le da el plato al cliente y luego se le informa de su error, debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algn error. 2) Disculparse insistentemente. 3) Volver a la cocina por la puerta de entrada. 4) Explicar el problema etc. Una lnea base es anloga a un plato mientras pasa por las puertas de la cocina de un restaurante antes de que un elemento de configuracin del software se convierta en lnea base, el cambio se puede llevar a cabo rpida e informalmente. Sin embargo, una vez que se establece una lnea base, pasamos, de forma figurada, por una puerta de un solo sentido. S pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. En el contexto de la ingeniera del software definimos una lnea base como un punto de referencia en el desarrollo del software y que queda marcado por el envo de uno o ms elementos de configuracin del software (ECS) y la aprobacin de ECS obtenido mediante una revisin tcnica formal. Por ejemplo, los elementos de una especificacin de diseo se documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificacin de diseo se convierte en lnea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificacin del diseo) tras haber sido evaluados y aprobados. Aunque se puedan definir las lneas base con cualquier nivel de detalle las lneas base ms comunes son las que se muestran en la figura 2.8
2008

Planificacin y Modelado

Figura 2.8 lneas base.

2.5.2 Elemento de configuracin del software. Un elemento de la configuracin del software es la informacin creada como parte del proceso de ingeniera, un ECS (elemento de configuracin de software) es un documento, un conjunto completo de casos de prueba o un componente de un programa 40 dado. Los siguientes ECS son el objetivo de las tcnicas de gestin de configuracin y forman un conjunto de lneas base: 1) Especificacin del sistema 2) Plan de proyecto 3) a. Especificacin de requisitos b. Prototipo ejecutable o en papel 4) Manual de usuario preliminar 5) Especificacin de diseos a. Descripcin del diseo de datos b. Descripcin del diseo arquitectnico c. Descripciones del diseo de los mdulos d. Descripciones del diseo de interfaces e. Descripciones de los objetos (si se utilizan tcnicas de P.O.O) 6) Listados del cdigo fuente 7) a. Plan y procedimiento de pruebas

2008

Planificacin y Modelado b. Casos de prueba y resultados registrados 8) Manuales de operacin de y de instalacin 9) Programas ejecutables a. Mdulos, cdigo ejecutable b. Mdulos enlazados 10) Descripcin de la base de datos a. Esquema y estructura de archivos b. contenido inicial 11) Manual del usuario final 12) Documentos de mantenimiento a. Informes de problemas del software b. Peticiones de mantenimiento c. Ordenes de cambios e ingeniera 13) Estndares y procedimientos de ingeniera del software Es importante considerar poner las herramientas de desarrollo de software bajo control de configuracin. Es decir congelar la versiones de editores, compiladores y otras herramientas CASE utilizadas durante el desarrollo, un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versin original Los ECS se organizan como objetos de configuracin que deben ser catalogados por la base de datos del proyecto con un nombre nico. Un ECS tiene un nombre y atributos, y est conectado a otros objetos mediante relaciones.
2008

Planificacin y Modelado

Fig.2.9 Objetos configuracin

La figura 2.9 se muestra el modelo de datos de los elementos de la configuracin, cada objeto est relacionado con otro, si se lleva a cabo un cambio sobre un objeto la interrelaciones sealan a que otros objetos afectar. 2.5.3 El proceso de la configuracin del software. La GCS es un elemento importante de garanta de calidad es responsable de controlar los cambios. Sin embargo tambin se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de CGS: Identificacin Control de versiones Control de cambios Auditorias de configuracin Generacin de informes 2.5.4 Identificacin de objetos en GCS. Se pueden identificar dos tipos de objetos los objetos bsicos y los objetos compuestos. Un objeto bsico es una unidad de texto creada durante el anlisis, diseo, codificacin o prueba. Un objeto compuesto es una coleccin de objetos bsicos u objetos compuestos. Cada objeto tiene un conjunto de caractersticas que los identifican como nicos. El nombre del objeto es una

2008

Planificacin y Modelado cadena de caracteres que identifica al objeto sin ambigedad. La descripcin del objeto es una lista de elementos de datos que identifican: El tipo de ECS (documento, programa, datos) que est representado por el objeto. Un identificador del proyecto; y la informacin de la versin y/o el cambio.

Figura 2.10 Grafo de evolucin.

En el grafo de la figura 2.10 de evolucin se describe la historia del objeto y sus cambios, las grandes modificaciones hacen que un objeto cambie, por lo que cambia el nmero de versin principal. 2.5.5 Control de versiones. El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creadas durante el proceso de ingeniera del software. "La gestin de configuracin permite a un usuario especificar configuraciones alternativas del sistema de software mediante la seleccin de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versin del

2008

Planificacin y Modelado software y permitiendo luego especificar y construir una configuracin describiendo el conjunto de atributos deseado." Los atributos pueden ser tan sencillos como un nmero especfico de versin asociado a cada objeto o tan complejos como una cadena de variables lgicas que especifiquen tipos de cambios funcionales aplicados al sistema.

Figura 2.11 Versiones y variantes

Para construir la variante adecuada de una determinada versin de un programa, a cada componente se le asigna una tupla de atributos. A cada variante se le asigna uno o ms atributos. Otra forma de establecer los conceptos de la relacin entre componentes, variantes y versiones es representarlas como un fondo de objetos.

2008

Planificacin y Modelado

Figura 2.12 Representacin de objetos, componentes, variantes y versiones

La principal diferencia entre los distintos est en la sofisticacin de los atributos que se usan para construir versiones y variantes especficas de un sistema y en la mecnica del proceso de construccin. 2.5.6 Control de cambios. En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rpidamente al caos. El control de cambios combina los procedimientos humanos y las herramientas automticas para proporcionar un mecanismo para el control de cambio.

2008

Planificacin y Modelado

Figura 2.13 Proceso de control de cambios.

Los resultados de la evaluacin se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Para cada cambio aprobado se genera una orden de cambio de ingeniera (OCI). La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisin y de auditora. El objeto a cambiar es "dado de baja" de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA. Luego, el objeto es "dado de alta" en la base de datos y se usan los mecanismos de de control de versiones apropiadas (seccin 4) para crear la siguiente versin del software.

2008

Planificacin y Modelado Los procedimientos de "alta" y "baja" implementan dos elementos importantes del control de cambios: control de acceso y control de sincronizacin. El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuracin concretos. El control de sincronizacin asegura que los cambios en paralelo, realizados por personas diferentes, no se sobrescriben mutuamente.

Figura 2.14 Control de acceso y de sincronizacin.

Antes de que un ECS se convierta en una lnea base, slo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECS en cuestin podr hacer cualquier cambio justificado por el proyecto y por los requisitos tcnicos. Una vez que el objeto ha pasado la revisin tcnica formal y ha sido aprobada, se crea la lnea base. Una vez que el ECS se convierte en una lnea base, aparece el control de cambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es local), o de la ACC si el cambio impacta en otros ECS. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las

2008

Planificacin y Modelado OCI. Sin embargo, hay que hacer una evaluacin de cada cambio as como un seguimiento y revisin de los mismos. Cuando se distribuye el producto de software a los clientes, se instituye el control de cambios formal. La autoridad de control de cambios (ACC) desempea un papel activo en el segundo y tercer nivel de control. El papel de la ACC es el de tener una visin general, o sea, evaluar el impacto del cambio fuera del ECS en cuestin. Cmo impactar el cambio en el hardware? Cmo impactar en el rendimiento? Cmo alterar el cambio la percepcin del cliente sobre el producto? 2.5.7 Auditoria de la configuracin. Cmo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) revisiones tcnicas formales 2) auditorias de configuracin del software. Las revisiones tcnicas formales se centran en la correccin tcnica del elemento de configuracin que ha sido modificado. Los revisores evalan el ECS para determinar la consistencia con otros ECS, las omisiones o los posibles efectos secundarios. Una auditoria de configuracin del software complementa la revisin tcnica formal al comprobar caractersticas que generalmente no tiene en cuenta la revisin. 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 revisin tcnica formal para evaluar la correccin tcnica? Se han seguido adecuadamente los estndares de ingeniera 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 configuracin? Se han seguido procedimientos del GCS para sealar el cambio, registrarlo y divulgarlo?

2008

Planificacin y Modelado Se han actualizado adecuadamente todos los ECS relacionados? 2.5.8 Informes de estado. La generacin de informes de estado de la configuracin es una tarea de GCS que responde a las siguientes preguntas: 1) Qu pas? 2) Quin lo hizo? 3) Cundo pas? 4) Que ms se vio afectado? La generacin de informes de estado de la configuracin desempea un papel vital en el xito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fcil que no exista una buena comunicacin. Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la comunicacin entre todas las personas involucradas.

2008

Planificacin y Modelado

Unidad 3
Anlisis del proyecto.

3.1 Anlisis de riesgos.

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. No existe una forma fcil de hacer esto. No se hace una valoracin con nmeros precisos sino en intervalos: La probabilidad del riesgo se puede valorar como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%). Los efectos del riesgo pueden ser valorados como catastrficos, serios, tolerables o insignificantes. En un entorno informtico existen una serie de recursos (humanos, tcnicos, de infraestructura) que estn expuestos a diferentes tipos de riesgos: los `normales, aquellos comunes a cualquier entorno, y los excepcionales, originados por situaciones concretas que afectan o pueden afectar a parte de una organizacin o a toda la misma, como la inestabilidad poltica en un pas o una regin sensible a terremotos. Para tratar de minimizar los efectos de un problema de seguridad se realiza lo que denominamos un anlisis de riesgos, trmino que hace referencia al proceso necesario para responder a tres cuestiones bsicas sobre nuestra seguridad: Qu queremos proteger? Contra quin o qu lo queremos proteger? Cmo lo queremos proteger?

2008

Planificacin y Modelado En la prctica existen dos aproximaciones para responder a estas cuestiones, una cuantitativa y otra cualitativa. La primera de ellas es con diferencia la menos usada, ya que en muchos casos implica clculos complejos o datos difciles de estimar. Se basa en dos parmetros fundamentales: la probabilidad de que un suceso ocurra y una estimacin del coste o las prdidas en caso de que as sea; el producto de ambos trminos es lo que se denomina coste anual estimado (EAC, Estimated Annual Cost), y aunque tericamente es posible conocer el riesgo de cualquier evento (el EAC) y tomar decisiones en funcin de estos datos, en la prctica la inexactitud en la estimacin o en el clculo de parmetros hace difcil y poco realista esta aproximacin. El segundo mtodo de anlisis de riesgos es el cualitativo, de uso muy difundido en la actualidad especialmente entre las nuevas `consultoras de seguridad (aquellas ms especializadas en seguridad lgica, cortafuegos, tests de penetracin y similares). Es mucho ms sencillo e intuitivo que el anterior, ya que ahora no entran en juego probabilidades exactas sino simplemente una estimacin de prdidas potenciales. Para ello se interrelacionan cuatro elementos principales: las amenazas, por definicin siempre presentes en cualquier sistema, las vulnerabilidades, que potencian el efecto de las amenazas, el impacto asociado a una amenaza, que indica los daos sobre un activo por la materializacin de dicha amenaza, y los controles o salvaguardas, contramedidas para minimizar las vulnerabilidades (controles preventivos) o el impacto (controles curativos). Por ejemplo, una amenaza sera un pirata que queramos o no (no depende de nosotros) va a tratar de modificar nuestra pgina web principal, el impacto sera una medida del dao que causara si lo lograra, una vulnerabilidad sera una configuracin incorrecta del servidor que ofrece las pginas, y un control la reconfiguracin de dicho servidor o el incremento de su nivel de parcheado. Con estos cuatro elementos podemos obtener un indicador cualitativo del nivel de riesgo asociado a un activo determinado dentro de la organizacin, visto como la probabilidad de que una amenaza se materialice sobre un activo y produzca un determinado impacto. Tras obtener mediante cualquier mecanismo los indicadores de riesgo en nuestra organizacin llega la hora de evaluarlos para tomar decisiones organizativas acerca de la gestin de nuestra seguridad y sus prioridades. Tenemos por una parte el riesgo calculado, resultante de nuestro anlisis, y este riesgo calculado se ha de comparar con un cierto umbral (umbral de riesgo) determinado por la poltica de seguridad de nuestra organizacin; el umbral de riesgo puede ser o bien un nmero o bien una etiqueta de riesgo (por ejemplo, nivel de amenaza alto, impacto alto, vulnerabilidad grave, etc.), y cualquier riesgo calculado superior al umbral ha de implicar una decisin de reduccin de riesgo. Si por el contrario el calculado es menor que el umbral, se habla de riesgo residual, y el mismo se considera asumible (no hay porqu tomar medidas para reducirlo). El concepto de asumible es diferente al de riesgo asumido, que denota aquellos riesgos calculados superiores al umbral

2008

Planificacin y Modelado pero sobre los que por cualquier razn (poltica, econmica) se decide no tomar medidas de reduccin; evidentemente, siempre hemos de huir de esta situacin.
2008

De forma simple, se puede concebir un riesgo como una probabilidad de que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se est desarrollando y para la organizacin. Estas categoras de riesgos se definen como se muestra: Riesgos del proyecto: estos afectan la calendarizacin o los recursos del proyecto. Riesgos del producto: estos afectan a la calidad o al rendimiento del software que se est desarrollando. Riesgos del negocio: estos afectan a la organizacin que desarrolla o suministra el software.

3.2 Control de calidad.

El control de la variacin es el corazn del control de calidad. El control de la variacin es la clave para un producto de alta calidad. En el contexto de software se lucha para controlar la variacin en el proceso genrico que se aplica y el nfasis de calidad que permea el trabajo de ingeniera del software. La calidad es una caracterstica o atributo de algo. Como un atributo de un elemento, la calidad se refiere a caractersticas mensurables, es decir, cosas que se pueden comparar para conocer estndares, como longitud, color, maleabilidad, etc. Sin embargo, el software, principalmente una entidad intelectual, es ms difcil de caracterizar que los objetos fsicos. La calidad de diseo, se refiere a las caractersticas que los diseadores especifican para un elemento. La calidad de concordancia es el grado en el quelas especificaciones de diseo se aplican durante la fabricacin. En el desarrollo de software, la calidad de diseo incluye requisitos, especificaciones y el diseo del sistema. La calidad de concordancia es un tema enfocado principalmente en la implementacin. El control de la variacin puede equipararse con el control de calidad; el control de calidad involucra una serie de inspecciones, 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. El control de calidad incluye un bucle de retroalimentacin con el proceso que cre el producto de trabajo. La combinacin de medicin y retroalimentacin permite

Planificacin y Modelado afinar el proceso cuando los productos de trabajo creados fracasan en cuanto a satisfacer sus especificaciones. 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. El bucle de retroalimentacin es esencial para minimizar los defectos producidos. El control de la calidad implica el proceso de desarrollo de software para asegurar que se sigan los procedimientos de aseguramientos y estndares de calidad; los productos resultantes de un proceso de software se comprueban contra los estndares definidos del proyecto en el proceso de control de calidad. 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 fcilmente comprensibles por los ingenieros que desarrollan el software. Existen dos enfoques complementarios para el control de la calidad: Revisiones de la calidad en las que el software, su documentacin y los procesos utilizados para producir ese software son revisados por un grupo de personas. Son responsables de comprobar que se han seguido los estndares del proyecto y que el software y los documentos estn acordes a estos estndares. Toman las desviaciones de los estndares y las ponen a consideracin de la administracin del proyecto. Valoracin automtica del software en la que el software y los documentos producidos se procesan por algn programa y se comparan con los estndares que aplica a ese proyecto de desarrollo en particular. Esta valoracin automtica comprende una medida cuantitativa de algunos atributos del software. Las revisiones son el mtodo ms utilizado para validar la calidad de un proceso o producto. Involucran a un grupo de personas que examinan parte o todo el proceso del software, los sistemas o su documentacin asociada para descubrir problemas potenciales. Las conclusiones de la revisin se registran formalmente y se pasan al autor o a quien sea responsable de corregir los problemas descubiertos. El cometido del equipo de revisin es detectar los errores e inconsistencias y sealarlas al diseador o autor del documento. Las revisiones se basan en documentos pero no se limitan a las especificaciones, diseos o cdigo. Se revisan todos los documentos tales como los modelos de proceso,

2008

Planificacin y Modelado los planes de prueba, los procedimientos de administracin de la configuracin, los estndares del proceso y los manuales de usuario.

Unidad 4
Anlisis de los requerimientos.
En la ingeniera de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniera de sistemas o la ingeniera de software. En la ingeniera clsica, los requerimientos se utilizan como datos de entrada en la etapa de diseo del producto. Establecen QU debe hacer el sistema, pero NO CMO hacerlo. La fase del desarrollo de requerimientos puede estar precedida por una fase de anlisis conceptual del proyecto. Esta fase puede dividirse en recoleccin de requerimientos de los inversores, anlisis de consistencia e

2008

Planificacin y Modelado integridad, definicin en trminos descriptivos para los desarrolladores y un esbozo de especificacin, previo al diseo completo Los requerimientos de informacin de un nuevo sistema implican la identificacin de quin necesita que informacin, dnde, cmo y cundo. El anlisis de requerimientos define los objetivos del sistema nuevo o modificado y desarrolla una descripcin detallada de las funciones que debe llevar a cabo el nuevo sistema. Los requerimientos deben considerar las restricciones de carcter econmico, tcnico y de tiempo as como las metas, procedimientos y los procesos de decisiones en la institucin. Un mal anlisis de requerimientos es una de las causas principales de la falla de los sistemas y de los costos elevados del desarrollo. Para obtener los requerimientos de los sistemas de informacin, los analistas deben trabajar una y otra vez en enunciados de requerimientos en colaboracin con los usuarios. El anlisis de sistemas a menudo hace una contribucin no intencional a la institucin al aclarar los procedimientos y llegar a un consenso sobre cmo deben hacerse las cosas. Una vez culminada la etapa de requerimientos los revisores independientes revisarn lo efectuado, no slo las funciones sino tambin la auditabilidad del sistema. En ingeniera de sistemas existen tres tipos de requerimientos. Un requerimiento funcional puede ser una descripcin de lo que un sistema debe hacer. Este tipo de requerimiento especfica algo que el sistema entregado debe ser capaz de realizar. Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cmo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuacin a leyes o regulaciones aplicables al producto Una coleccin de requerimientos describe las caractersticas o atributos del sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto debe ser decidido en la etapa de diseo por los diseadores. En la ingeniera de software se aplica el mismo significado, slo que el nfasis est puesto en el propio software.

2008

Planificacin y Modelado

4.1 Requerimientos funcionales y no funcionales.

4.1.1 Requerimientos funcionales. Los requerimientos funcionales son declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionara a entradas particulares y de cmo se comportara en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe de hacer. Los requerimientos funcionales especifican los servicios que debe proporcionar la aplicacin (por ejemplo, la aplicacin debe calcular el valor del

2008

Planificacin y Modelado portafolio de inversin del usuario). Por otro lado, un requerimiento como la aplicacin debe terminar el clculo del valor de cada portafolio en menos de 1 segundo no es un requerimiento funcional, porque no especifica un servicio dado. En su lugar, califica un servicio o servicios (especifica algo sobre ellos). Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que ste proveer, esto depende del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc. Los requerimientos funcionales para un sistema de software se expresan de diferentes formas. Algunos de estos requerimientos para un sistema de biblioteca universitario para estudiantes y acadmicos 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. El sistema deber proveer visores adecuados para que el usuario lea documentos en el almacn de documentos. A cada pedido se le deber asignar un identificador nico que el usuario podr copiar al rea de almacenamiento permanente de la cuenta. Estos son requerimientos funcionales del usuario que definen los recursos especficos que el sistema debe proveer. 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). Muchos de los problemas de la ingeniera de software provienen de la imprecisin en la especificacin de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema. Por supuesto, eso retrasa la entrega de ste e incrementa los costos. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La complecin significa que todos los servicios solicitados por el usuario estn definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la prctica, para sistemas grandes y complejos, es posible cumplir los
2008

Planificacin y Modelado requerimientos de consistencia y complecin. La razn de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias no son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen despus de un anlisis profundo. Una vez que estos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de la vida, se deben corregir en el documento de requerimientos. 4.1.2 Requerimientos no funcionales. Los requerimientos no funcionales son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, etc. Muchos requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos particulares del mismo, lo que significa que a menudo son ms crticos que los requerimientos funcionales. El incumplimiento en un funcional degrada el sistema, mientras que el fallo en un no funcional, inutilizara el sistema. Sin embargo, 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. Algunos de estos requerimientos de procesos son la especificacin de los estndares de calidad que se deben utilizar en el proceso, una especificacin que el diseo debe producir una herramienta CASE particular y una descripcin del proceso a seguir. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones del presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos. El diagrama muestra una clasificacin de los diferentes tipos de requerimientos no funcionales que puede haber.

2008

Planificacin y Modelado

Figura 4.1 requerimientos funcionales.

Estos diferentes tipos de requerimientos que se muestran en la figura 4.1 anterior se clasifican de acuerdo con sus implicaciones: Requerimientos del producto: estos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de desempeo en la rapidez de ejecucin del sistema y cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. Requerimientos organizacionales: se derivan de las polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador. Algunos ejemplos son los estndares en los procesos que deben utilizarse; los requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cuando se entregara el producto y su documentacin. Requerimientos externos: este gran apartado cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Estos incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con los otros sistemas de la organizacin; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos ticos. Estos ltimos son impuestos al sistema para asegurar que ser aceptado por el usuario y por el pblico en general. Un problema comn con los requerimientos no funcionales es que algunas veces no se pueden verificar. Se redactan para reflejar las metas generales del usuario, como la facilidad de uso, la capacidad del sistema para

2008

Planificacin y Modelado recuperarse de las fallas o la respuesta rpida del usuario. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a interpretacin, lo que provoca discusiones subsecuentes una vez que el sistema se entregue.

4.2 Casos de uso.

El proceso unificado de desarrollo de software (USDP) explota la observacin de que muchos requerimientos ocurren de manera natural en secuencias operativas. Por ejemplo, el requerimiento individual de que una aplicacin para una tienda de videos permita introducir el titulo de un nuevo video suele ser parte de una secuencia de transacciones. Estas son los casos de uso, algunas veces llamados escenarios (en UML, un escenario es en realidad una instancia de un caso de uso). El USDP favorece la organizacin de los requerimientos por casos de uso. Organizarlos de esta manera es til para producir casos de uso ms grandes a partir de los pequeos. Cuando se usa como parte del anlisis de tareas, el caso de uso se desarrolla para que muestre la manera en que el usuario final realiza alguna tarea relacionada con el trabajo; Casi siempre, el caso de uso se escribe de manera informal (un solo prrafo) en primera persona. 4.2.1 Los Casos de uso y el valor del sistema. A quin no le ha pasado que siente la necesidad de comprar algo slo para terminar con ese producto en un rincn sin jams ser utilizado. Nos pudo haber pasado porque no alcanz nuestras expectativas, o porque result demasiado complicado de utilizar, o porque en realidad no era una verdadera necesidad sino simplemente un capricho. Sea cual fuera la razn, la realidad es que hicimos un gasto intil e innecesario. Con el software, y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo similar. Pues, no es raro encontrarse con empresas que contratan un desarrollo de software slo para darse cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o necesitaban. En otras palabras, no obtuvieron el valor que esperaban recibir para su negocio con el software adquirido. 4.2.1.1 La Administracin de requerimientos. Una de las razones principales por las cuales se da esta situacin, y de hecho, una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el xito que deberan, se debe a una mala administracin de requerimientos. Esto generalmente se da por falta ya sea de habilidades en el personal responsable o de tcnicas apropiadas utilizadas para llevar a cabo esta labor.

2008

Planificacin y Modelado La administracin de requerimientos, de acuerdo a CMM, abarca actividades como la recopilacin, documentacin, validacin y control de los requerimientos y sus cambios. UML, como estndar integrador de las buenas prcticas de desarrollo nos ofrece en este sentido los casos de uso como una tcnica excelente para administrar los requerimientos de nuestros proyectos.

4.2.1.2 Consultora o manufactura? Si queremos realizar una verdadera consultora de software entonces nos corresponde algo ms que escuchar la lista de funciones que el cliente cree que debera de tener su sistema (a menos que nuestro cliente tenga un rea con la capacidad de realizar una buena recopilacin y anlisis de requerimientos). Si nos limitramos a lo primero entonces en lugar de llamarle consultora a nuestro trabajo, deberamos llamarle manufactura de software, donde uno implementa las funciones exactamente cmo se las solicita el cliente, cuestionando nada o muy poco, tal como se hara en una planta manufacturera donde se reciben las especificaciones del producto a construir. 4.2.1.3 El sistema y su misin. Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar, en primer lugar, cul es el valor que el sistema debe proporcionar al negocio. Para lo cual habr que preguntrselo a las personas que obtendrn alguna clase de beneficio cuando se ponga en operacin. Una buena parte de estas personas probablemente vayan a ser usuarios del sistema; en UML los conocemos como Actores (ms adelante veremos otros tipos de Actores que tambin tendremos que identificar). 4.2.1.4 Buscando los beneficios del sistema. Una vez identificados los usuarios del sistema (actores primarios) habr que preguntarles en qu situaciones valdr la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debera de tener pequeas funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio, de manera que valga la pena usar el sistema en dichas situaciones. Ejemplo: un vendedor en cierto sistema de ventas querr Registrar venta, Registrar pedido, Consultar comisiones, Administrar prospectos, Generar factura y Administrar clientes. Todas ellas son ejemplos de situaciones u objetivos importante que podra necesitar un vendedor para llevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML, tal como se muestra en el diagrama de la figura 4.2.

2008

Planificacin y Modelado

Figura 4.2 caso de uso

4.2.1.5 Los requerimientos funcionales. Normalmente los casos de uso son iniciados por algn actor, conocido como actor primario. Lo inicia con algn evento, que podra ser tan simple como elegir una opcin en el sistema, y contina como una serie de eventos o interacciones entre actores y sistema, 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). Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos importantes. Lo que estamos obteniendo as es una especificacin de requerimientos funcionales mediante un anlisis top-down (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y despus buscamos cules son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misin del sistema. Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso: 1. Especificar la misin del sistema 2. Identificar quines utilizarn el sistema (actores primarios)

2008

Planificacin y Modelado 3. Averiguar cules objetivos desean cumplir los actores al usar el sistema (casos de uso) 4. Identificar los pasos o eventos de cada caso de uso (especificacin del caso de uso) 4.2.1.5 Las interfaces del sistema. Hay otro tipo de actores que tambin hay que modelar; los actores secundarios. Suelen ser otros sistemas, componentes externos o dispositivos con los cuales interacta nuestro sistema. A diferencia de los actores secundarios, stos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso requiere tener algn tipo de interaccin con l. En el diagrama de casos de uso tambin suele ser apropiado mostrar a este tipo de actores, en cuyo caso aparecern asociados a los casos de uso durante los cuales tienen que intervenir con algn tipo de interaccin con el sistema a modelar.
Ejemplo de Actor Secundario. Nuestro sistema de ventas podra requerir enviarle informacin al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso Generar factura. En dicha situacin el sistema de contabilidad aparecer como un actor secundario asociado a dicho caso de uso. De esta forma estamos mostrando las interfaces requeridas con otro sistema en cada momento.

Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en la simplicidad, ya que facilita el anlisis, entendimiento y comunicacin entre quienes solicitan el sistema y los que participan en su desarrollo. En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos ms bsicos.

2008

Planificacin y Modelado

4.3 Diseo de interfaz de usuario.

El diseo de sistemas de computo comprende varias actividades que van desde el diseo de hardware hasta el de la interfaz de usuario. Son muy pocos los especialistas que trabajan en el diseo de la interfaz de usuario, es por eso que muchas veces los ingenieros del software tienen que encargarse de disear este aspecto, as como de disear el software que implemente esta interfaz. El diseo de la interfaz se concentra en tres reas: El diseo de interfaces entre componentes de software El diseo de interfaces entre el software y otros productores y consumidores de la informacin que no son humanos (entidades externas) El diseo de la interfaz entre un ser humano y la computadora.

Solo hablaremos del nmero 3, la interfaz de usuario. El diseo de la interfaz de usuario crea un medio de comunicacin efectiva entre un ser humano y una computadora. Siguiendo un conjunto de principios de diseo de interfaces, el diseador 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. Un ingeniero de software disea la interfaz de usuario al aplicar un proceso iterativo basado en principios de diseo ampliamente aceptados. Si el uso del software es difcil, si lleva al usuario a cometer errores o si frustra sus esfuerzos por alcanzar sus objetivos, no le gustara, sin importar su capacidad ni las funciones que ofrezca. La interfaz tiene que ser correcta porque moldea la percepcin del usuario acerca del software. Aunque las interfaces basadas en texto aun se utilizan, especialmente en los sistemas heredados, actualmente los usuarios de las computadoras esperan que los sistemas de aplicaciones tengan algn tipo de interfaz grafica de usuario.

2008

Planificacin y Modelado Las computadoras contienen GUIs (interfaz grafica de usuario) lo que le permite el despliegue en color de alta resolucin e interaccin utilizando tanto el teclado como el mouse.
2008

Las ventajas de las GUIs son: Son relativamente fciles de aprender y utilizar. Para interactuar con el sistema, los usuarios cuentan con pantallas mltiples. Es posible interactuar rpidamente y tener acceso inmediato a cualquier punto de la pantalla.

Caractersticas de las interfaces graficas de usuario:

Caracterstica s Ventanas Descripcin Las ventanas mltiples permiten que se desplieguen simultneamente informacin diversa en la pantalla del usuario Los iconos representan diferentes tipos de informacin. En algunos sistemas, los iconos representan archivos; 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 inters en una ventana, se utiliza un dispositivo apuntador, como el ratn Los elementos grficos se pueden mezclar con texto en el mismo despliegue

Iconos

Mens Apuntador

Grficos

Planificacin y Modelado

El proceso de diseo de la interfaz de usuario.

Analizar y comprender las actividades del usuario

Producir un prototipo de diseo en papel

Evaluar el diseo con los usuarios finales

Disear el prototipo

Producir el prototipo del diseo dinamice

Evaluar el diseo con los usuarios finales

Prototipo ejecutable

Implementar la interfaz del usuario final

2008

Planificacin y Modelado

4.3.1 Reglas en el diseo de interfaz de usuario. El diseo de la interfaz de usuario requiere el estudio de las personas y el conocimiento tecnolgico adecuado En su libro sobre diseo de interfaces, Theo Mantel [MAN97] acuo tres reglas de oro para el diseo 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; que el usuario controle la computadora, no que la computadora controle al usuario. Se debe definir los modos de interaccin de forma que el usuario no realice acciones innecesarias o indeseables, esto es, que el usuario pueda decidir si entrar o salir de diferentes tipos de interaccin Proporcionar una interaccin flexible, esto es, que le permita al usuario interactuar con la interfaz mediante movimientos del ratn, del lpiz digitalizador o comandos seleccionados con el teclado o mediante reconocimiento de voz Incluir las opciones de interrumpir y deshacer la interaccin del usuario, 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 haba hecho o poder deshacer acciones que ya haya hecho. Depurar la interaccin a medida de que aumentan los grados de destreza y permitir que se personalice la interaccin, o sea, que se pueda personalizar la interfaz con el fin de los usuarios que repitan secuencias de interacciones. Oculte al usuario ocasional los elementos tcnicos internos; la interfaz debe llevar al usuario al mundo virtual de la aplicacin; no es necesario que conozca

2008

Planificacin y Modelado el sistema operativo, las funciones de administracin secretos de la tecnologa de computo. de archivos u otros

Reducir la carga en la memoria del usuario; entre ms cosas tenga que recordar el usuario, mas fcil ser que cometa errores; es por eso que una interfaz debe recordar la informacin pertinente y ayudar al usuario con un escenario de interaccin que le facilite el uso de la memoria. Se debe reducir la demanda de memoria a corto plazo, esto es, que la interfaz se debe disear para que se reduzca la necesidad de recordar acciones y resultados anteriores. Esto se logra al proporcionar pistas visuales que permitan al usuario reconocer acciones anteriores sin tener que recordarlas. Se deben definir valores por defecto que tengan significado; el conjunto inicial de valores por defecto debe tener un sentido para el usuario promedio, pero tambin contar con la posibilidad de especificar sus preferencias. Tambin se debe definir accesos directos intuitivos, esto es, cuando se emplea la mnemotcnica para aplicar una funcin del sistema, debe estar unida a una accin de manera tal que resulte fcil de recordar. El formato visual de la interfaz debe basarse en una metfora tomada de la realidad, osea, se debe encontrar acciones de la vida real y conectarlas mediante la interfaz a algo semejante para poder llevar a cabo la accin deseada. Desglosar la informacin de manera progresiva; la interfaz debe organizarse jerrquicamente, la informacin sobre una tarea, un objeto o algn comportamiento debe presentarse primero en un alto grado de abstraccin. Despus de que el usuario se interese en seleccionar algo con el ratn, deben presentarse ms detalles. Lograr que la interfaz sea consistente La interfaz debe adquirir y presentar la informacin de manera consistente. Esto implica que: Toda la informacin visual est organizada de acuerdo con un estndar de diseo que se mantenga en todas las presentaciones de pantalla. Los mecanismos de entrada se restrinjan a un conjunto limitado que se utilice de manera consistente en toda la aplicacin.

2008

Disear interaccin directa con los objetos que aparecen en pantalla; el usuario siente que tiene el control cuando manipula los objetos necesarios para realizar una tarea de manera parecida a como lo hara con un objeto material.

Planificacin y Modelado Los mecanismos para ir de una tarea a otra se hayan definido e implementado de manera consistente.

Mantener la consistencia en toda una familia de aplicaciones, se debe de implementar las mismas reglas de diseo para mantener la consistencia en todas las interacciones Si modelos interactivos anteriores han generado expectativas en el usuario, no hacer cambios a menos que haya razones inexcusables. Una vez que una secuencia interactiva se ha convertido en un estndar de facto, el usuario espera esto en todas las aplicaciones que encuentre.

Bibliografia: 1. Pressman Roger S (2001). Ingeniera del Software, 5/E. Ed. Mc Graw Hill. 2. Sommerville, Ian (2001). Ingeniera de Software. Ed. Prentice Hall. 3. Kotonya, Gerald, Sommerville, Ian (2003). Requirements Engineering : Processes and Techniques. Ed. Wiley. 4. Jacobson,Ivar. (2000). El Proceso unificado de desarrollo de Software. Ed. Addison Wesley. 5. Fowler, Martin, (1999). UML Gota a Gota.

2008

Se debe permitir que el usuario incluya la tarea actual en un contexto que tenga algn significado; muchas interfaces implementan capas complejas de interacciones con docenas de imgenes en pantalla. Es importante proporcionar indicadores que permitan al usuario conocer el contexto del trabajo que realiza.

Planificacin y Modelado Ed. Addison Wesley. 6. Larman, Craig (1999). UML y patrones. Ed. Pearson. 7. Humphrey, Watts S. (2000).. Introduccin al Proceso Software Personal. Ed. Addison Wesley. 8. Pfleeger, Shari Lawrence (2002). Ingeniera de Software Teora y prctica. Ed. Prentice Hall. 9. Bruegge Bernd (2001). Ingeniera de Software Orientada a Objetos. Ed. Prentice Hall. 10. Braude, Eric (2003). Ingeniera de Software Una perspective Orientada a Objetos. Ed. Alfaomega. 11. Meyer, Bertrand (1999). I Construccin de Software Orientada a Objetos. Ed. Prentice Hall. 12. Laudon & Laudon 8/E (2003). Management Information Systems. Ed. Prentice Hall.
2008