Planificacion y Modelado 09 04 2012

Planificacion y ModeladoBy lizolm | Studymode.com

INSTITUTO TECNOLÓGICO DE ACAPULCO INGENIERIA EN SISTEMAS COMPUTACIONALES

Acapulco Gro. 05 de Enero del 2012PLANIFICACIÓN Y MODELADO“RECOPILACIÓN DE APUNTES”

INDICE

INDICE 2INTRODUCCIÓN 4Objetivos 4UNIDAD I 5PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS 5INTRODUCCION 51.1 REQUERIMIENTOS DE PROCESO 81.2 REQUERIMIENTOS DE LOS USUARIOS 141.3 REQUERIMIENTOS PARA EL ANALISIS Y NEGOCIACION 161.4 REQUERIMIENTOS PARA LA GESTION 19UNIDAD II 26PLANIFICACIÓN DEL SISTEMA 26INTRODUCCIÓN 262.1 PLANIFICACIÓN DEL TIEMPO 262.2. EVALUACIÓN DE COSTO BENEFICIO. 322.3 ESTUDIO DE LA VIABILIDAD 352.4 PLANIFICACIÓN DE LA DOCUMENTACIÓN 602.5 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE 78UNIDAD III 89ANÁLISIS DEL PROYECTO 893.1 ANÁLISIS DE RIESGOS 893.2. CONTROL DE CALIDAD DEL SOFTWARE 93

UNIDAD IV 112ANALISIS DE LOS REQUERIMIENTOS 112INTRODUCCION 1124.1 REQUERIMIENTOS FUNCIONALE Y NO FUNCIONALES 1134.2 CASOS DE USO 1204.3 DISEÑO DE INTERFAZ DE USUARIO 1274.3.1 REGLAS EN EL DISEÑO DE INTERFAZ DE USUARIO 1354.3.2 INTEGRACIÓN DE LA INTERFAZ AL CASO DE USO 139CONCLUSIONES 143

INTRODUCCIÓN

La ingeniería del software es una disciplina de la ingeniería cuya metaes el desarrollo costeable de sistemas de software. Este es abstracto eintangible. No está restringido por materiales, o gobernado por leyes físicas o procesos de manufactura. De alguna manera, esto simplifica laingeniería del software ya que no existen limitaciones físicas del potencial del software, sin embargo, esta falta de restricciones naturales significa que el softwarepuede llegar a ser extremadamente complejo y por lo tanto, muy difícil de entender.En estos capítulos se expone sobre el producto que va a ser tratado conla ingeniería y el proceso que proporciona un marco de trabajo para la Tecnología de la Ingeniería del Software.

ObjetivosLos objetivos de este trabajo son introducir la ingeniería del softwarey proporcionar un marco para poder desarrollar una buena Planificación de un Sistema.* Comprenderá que es la Ingeniería del Software y el por qué de su importancia.* Conocerá las respuestas a las preguntas claves que proporciona al querer desarrollar un Sistema.* Comprenderá algunos aspectos profesionales y de ética que son importantes para los ingenieros del Software.

UNIDAD I PROCESOS DE LA INGENIERIA DE REQUERIMIENTOSINTRODUCCION

De las muchas definiciones que existen para requerimiento, a

continuación se presenta la definición que aparece en el glosario de laIEEE.

1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

2. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

3. Una representación documentada de una condición o capacidad como en 1 o 2

La ingeniería de requerimientos es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.

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.

REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, elrendimiento, mantenimiento, seguridad, portabilidad, estándares, etc.

¿QUÉ SON LOS REQUERIMIENTOS?

El termino requerimiento no siempre es constante en la industria del software. En algunos casos, un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema. Ian Somerville, en su libro “Ingeniería de Software”, 7a. Edición, Capitulo 6, dice que “los requerimientos para un sistema son las

descripciones de los servicios que debe proporcionar el sistema y sus restricciones operativas. La ingeniería de requerimientos es el procesode descubrir, analizar, documentar y verificar los servicios proporcionados por el sistema y sus restricciones operativas.”

La especificación del software o ingeniería de requerimientos es el proceso de compresión y definición de qué servicios se requieren del sistema y de identificación de las restricciones de funcionamiento y desarrollo del mismo. La ingeniería de requerimientos es una etapa particularmente crítica en el proceso del software ya que los errores en esta etapa originan inevitablemente problemas posteriores en el diseño e implementación del sistema.

¿POR QUE SON IMPORTANTES LOS REQUERIMIENTOS?

En uno de los párrafos máscitados en la bibliografía de la Ingeniería del Software, Frederick P. Brooks, en su libro “Essence and Accidents of Software Engineering”,1987. (Reimpreso en 1995 edition of The Mythical Man-Month), dice:"La parte más difícil de construir un sistema es precisamente saber quéconstruir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otraparte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante... Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto."

Por lo tanto antes de ponerse a programar, se debe tener bien claro quees lo que se quiere tener como producto final y para ello necesitamos requerimientos ya sea por parte del cliente que requiere esa necesidad en el sistema o bien porque el sistema necesita de ese requerimiento para funcionar ya que si no se consiguen los requerimientos correctos el producto resultante no permitirá a los usuarios finales llevar a cabo su trabajo.

CARACTERÍSTICAS DE UN REQUERIMIENTO.

Es importante no perder de vista que un requerimiento debe ser:

* Especificado por escrito: Cómo todo contrato o acuerdo entre dos partes.* Posible de probar o verificar: Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe que se cumplió con él o no?* Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos quevayan a consultarlo en un futuro.* Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.* Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.* No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición no debe causar confusiones al lector.

DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS* Los requerimientos no son obvios y vienen de muchas fuentes.* Son difíciles de expresar en palabras (el lenguaje es ambiguo).* Existen muchos tipos de requerimientos y diferentes niveles de detalle.* La cantidad de requerimientos en un proyecto puede ser difícil de manejar.* Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.* Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.* Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.* Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.* Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.INGENIERÍA DE REQUERIMIENTOS El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.A continuación se darán algunas definiciones paraingeniería de requerimientos.

"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá comobase para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979."Ingeniería 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 combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987."Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software.

1.1 REQUERIMIENTOS DE PROCESO

Estos requerimientos existen porque los procesos lo usan durante el desarrollo del software

La meta del proceso de ingeniería de requerimientos es crear y mantenerun documento de requerimientos del sistema. El proceso general corresponde cuatro subprocesos de alto nivel de la ingeniería de requerimientos. Estos tratan de la evaluación de si el sistema es útil para el negocio(estudio de viabilidad); el descubrimiento de requerimientos (obtención y análisis); la transformación de estos requerimientos en formularios estándar (especificación), y la verificación de que los requerimientos realmente definen el sistema quequiere el cliente (validación). La Figura 7.1 ilustra la relación entreestas actividades. También muestra el documento que se elabora en cada etapa del proceso de ingeniería de requerimientosLas actividades que se muestran en la Figura 7.1 se refieren al descubrimiento, documentación y verificación de requerimientos. Sin embargo, en casi todos los sistemas los requerimientos cambian. Las

personas involucradas desarrollan una mejor comprensión de lo que quieren que haga el software; la organización que compra el sistema cambia; se hacen modificaciones a los sistemas hardware, software y al enlomo organizacional. El proceso de gestionar estos cambios en los requerimientos se denomina gestión de requerimientos, tema que se aborda en la sección final de este capítulo.Se presenta una perspectiva alternativa sobre el proceso de ingeniería de requerimientos en la Figura 7.2. Esta muestra el proceso como una actividad de tres etapas donde las actividades se organizan como un proceso iterativo alrededor de una espiral. La cantidad de dinero y esfuerzo dedicados a cada actividad en una iteración depende de la etapa del proceso general y del tipo de sistema desarrollado. Al principio del proceso, se dedicará la mayor parte del esfuerzo a la comprensión del negocio de alto nivel y los requerimientos no funcionales y del usuario. Al final del proceso, en el anillo exterior de la espiral, sededicará un mayor esfuerzo a la ingeniería de requerimientos del sistema y al modelado de éste.Este modelo en espiral satisface enfoques de desarrollo en los cuales los requerimientos se desarrollan a diferentes niveles de detalle. El número de iteraciones alrededor de la espiral puede variar, por lo que se puede salir de la espiral después de que se hayan obtenido algunos otodos los requerimientos del usuario. Figura 7.1 El proceso de ingeniería de requerimientos.

Figura 7.2 Modelo en espiral de los procesos de la i n g e n i e r í a de requerimientos.

Algunas personas consideran a la ingeniería de requerimientos como el proceso de aplicar un método de análisis estructurado, como el análisisorientado a objetos (Larman, 2002). Éste comprende analizar el sistema y desarrollar un conjunto de modelos gráficos del mismo, como los modelos de casos de uso, que sirven como una especificación del sistema. El conjunto de modelos describe el comportamiento del sistema al cual se le agregan notas con información adicional que detallan, porejemplo, el rendimiento o fiabilidad requeridos.

Aunque los métodos estructurados juegan un cierto papel en el proceso de ingeniería de requerimientos, existe mucho más en dicha ingeniería de lo que se abarca en estos métodos. La obtención de requerimientos, en particular, es una actividad centrada en las personas, y a éstas no

les gustan las restricciones impuestas por modelos de sistemas rígidos.Aquí se tratan los enfoques generales de la ingeniería de requerimientos, y en el Capítulo 8 se examinan los métodos estructurados y los modelos del sistema.

Un proceso es unconjunto ordenado de tareas; una serie de pasos que involucran actividades, restricciones y recursos que producen una determinada salida esperada.

Un proceso involucra por lo general un conjunto de herramientas y técnicas.Un proceso es entonces, un conjunto de procedimientos de tal modo que los productos que se construyen satisfacen un conjunto de metas o estándares.Un procedimiento es una serie de pasos; una manera de combinar herramientas y técnicas para generar un producto.

Características de los procesos:

* Un proceso utiliza recursos* Está sujeto a una serie de restricciones* Genera productos intermedios y finales* Cada actividad del proceso tiene criterios de entrada y salida, es decir se conoce cuando inicia y termina el proceso* Todo proceso tiene un conjunto de principios que permiten explicar las metas de cada actividad* Las actividades se realizan secuencialmente.

ESTUDIO DE LA VIABILIDAD El proceso de ingeniería de requerimientos debería de empezar con un estudio de viabilidad.

La entrada de este es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de cómo este pretende contribuir a los procesos del negocio.

Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.Un estudio de viabilidad es un estudio corto y orientado a resolver

varias cuestiones:1. ¿Contribuye el sistema a los objetivos generales de la organización?2. ¿Se puede implementar el sistema utilizando la tecnologíaactual y dentro de las restricciones de coste y tiempo?3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización?En un estudio de viabilidad, se pueden consultar las fuentes de información. OBTENCIÓN Y ANÁLISIS La siguiente etapa del proceso de ingeniería de requerimientos es la obtención y análisis de requerimientos. En esta actividad, los ingenieros de software trabajan con los clientesy los usuarios finales del sistema para determinar el dominio de la aplicación, que servicios debe proporcionar el sistema, las restricciones hardware, etc.

En la figura anterior se muestra un modelo muy general del proceso de obtención y análisis. Las actividades del proceso son:* Descubrimiento de requerimientos:Es el proceso de interactuar con los stakeholders del sistema para recopilar sus requerimientos.* Clasificación y organización de requerimientos: Esta actividad toma la recopilación no estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en grupos coherentes.* Ordenación por Prioridades y Negociación de Requerimientos: Inevitablemente, cuando existen muchos stakeholders involucrados, los requerimientos entraran en conflicto. Esta actividad se refiere a ordenar las prioridades los requerimientos, y a encontrar y resolver los requerimientos en conflicto a través de la negación.

* Documentación de Requerimiento: Se documentan los requerimientos y se entra en la siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos formales o informales.

VALIDACION DE REQUERIMIENTOS La validación derequerimientos trata de mostrar que estos realmente definen el sistema que el cliente desea. Coincide parcialmente con el análisis ya que implica encontrar problemas con los requerimientos.

Durante el proceso de validación de requerimientos, se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos.

Estas variables son:* Verificación de valides: un usuario puede pensar que necesita un sistema para llevar a cabo ciertas funciones.* Verificaciones de consistencias: Los requerimientos en el documento no deben contradecirse.* Verificación por completitud: El documento no debe incluir requerimientos que definan todas las definiciones y restricciones propuestas por el usuario.* Verificación por realismo: usando el conocimiento de la tecnología existente, los requerimientos deben verificarse para asegurar que se puedan implementar.* Verificabilidad: para reducir la posibilidad de discusiones entre cliente y con el tratita, los requerimientos del sistema deben redactarsede tal forma que sean verificables.

1.2 REQUERIMIENTOS DE LOS USUARIOS (Actores Involucrados) Algunos de los problemas que surgen durante el proceso de ingeniería derequerimientos son resultado de no hacer una clara separación entre losdiferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos dealto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detalladapara establecer un puente entre la ingeniería de requerimientos y las actividades de diseño. Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento técnico detallado. Únicamente deben especificar el comportamiento externo del sistema y deben evitar, tanto como sea posible, las características de diseño delsistema. Por consiguiente, si se están redactando requerimientos del usuario, nose debe utilizar jerga del software, notaciones estructuradas o

formales, o describir los requerimientos por la descripción de la implementación del sistema. Deben redactarse en un lenguaje sencillo con tablas y formularios sencillos y diagramas intuitivos. Sin embargo, pueden surgir diversos problemas cuando se redactan con frases del lenguaje natural en un documento de texto: 1. Falta de claridad. Algunas veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer. 2. Confusión de requerimientos. No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y lainformación para el diseño. 3. Conjunción de requerimientos. Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento. Los requerimientos del usuario que incluyen demasiada información restringen la libertad del desarrollador del sistema para proporcionar soluciones innovadoras a los problemas del usuario y son difíciles de comprender. Los requerimientos del usuario deben simplementeenfocarse alos recursos principales que se deben proporcionar. En si los requerimientos de los usuarios son todas sus necesidades, lascuales se traducen a los requerimientos, de lo que esperan que un nuevosistema realice y de las restricciones que lleva consigo. Un ejemplo detales necesidades pueden ser los siguientes: * Obtener soluciones a problemas en su trabajo bajo el sistema actual * Una interfaz más amigable, rápida de aprende, fácil de usar * un tiempo de respuesta más corto, etc. Para minimizar los malentendidos al redactar los requerimientos del usuario, se recomienda seguir algunas pautas sencillas: 1. Inventar un formato estándar y asegurar que todos los requerimientosse adhieren al formato. Estandarizar el formato hace que las omisiones sean menos probables y los requerimientos más fáciles de verificar. El formato utilizado muestra el requerimiento inicial en negrita, incluyendo una declaración del fundamento más detallada de los requerimientos del sistema. 2. Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los requerimientos deseables y los obligatorios. Los requerimientos obligatorios son los requerimientos a los que el sistemadebe dará soporte y normalmente se redactan en futuro simple. Los requerimientos deseables no son fundamentales y se redactan en futuro condicional.

3. Resaltar el texto (con negrita, cursiva o color) para distinguir laspartes clave del requerimiento. 4. Evitar, hasta donde sea posible, el uso de jerga informática. El analista puede obtener los requerimientos generales del usuario respondiendo a las siguientes preguntas paraluego profundizar y obtenerla mayoría de los requerimientos y más adelante resolver cómo satisfacer dichos requerimientos. * ¿Qué es lo que él necesita hacer el usuario? * ¿Qué es lo que tiene que hacer para realizar su trabajo? * ¿Qué información tiene que capturar, almacenar o desplegar? * ¿Qué recursos necesita? * Por lo general cuando se está investigando estos requerimientos, el analista se encuentras con el problema de la comunicación con el usuario pues el lenguaje cotidiano de ambos no es igual. Ejemplos de estos problemas se listan a continuación:

* Falta de claridad * Conocen de manera muy general lo que desean obtener * No saben expresar o explicar lo que quieren del sistema * Usan terminologías distintas * Confunde los requerimientos funcionales y los no funcionales * Confusión de requerimientos, pues expresan de varias formas un mismo requerimiento Ya que durante la obtención de requerimientos se tiene trato con diferentes tipos de personas de la organización, es de utilidad conocersu nivel de habilidad y de comprensión del sistema, esto para una mejorcompresión de los requerimientos por parte del analista. También es importante para el analista conocer a los participantes claves, es decir, aquellos que: * Interactúan regularmente con sistema * Cambia su forma de trabajar por el sistema * Producen información para el sistema * Emplea dicha información 1.3 REQUERIMIENTOS PARA EL ANALISIS Y NEGOCIACION

ANALISISLos requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y ademáscontienen múltiples relaciones entre sí. Lo que nos da a concluir, de acuerdo a lo expuesto

anteriormente, que el conjunto de requerimientos de un sistema computacional es complejo.

Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto selogra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos.El análisis de requerimientos consiste brevemente en los siguientes pasos:

* Obtener información acerca de lo que los usuarios desean* Clasificar esos deseos para comenzar a estructurar requerimientos* Identificar los niveles de jerarquía del sistema y empezar a alojar los ya clasificados requerimientos en cada nivel.* Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentación que describa la manera que el clientedesea que funcione el sistema de software.Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada revisióno cambio que se haga a esta documentaciónComo cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuáles de ellas seránsatisfechas por el software y cuales por algún otro producto del sistema.

NEGOCIACION

La diversa gama de fuentes de las cuales provienen los requerimientos,

hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultadoscompletos, correctos y sin ambigüedades.En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado.Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura que todas las características de los requerimientos estén presentes en cada uno de los ellos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc.

Clasificar los requerimientos:En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio.En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Unrequerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo oque puede esperar para fases posteriores, el requerimiento es catalogado como innecesario.Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios.Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Porejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el

sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

En la actividad de negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

* Documentar todos los requerimientos a un nivel de detalle apropiado.* Mostrar todos los requerimientos a los involucrados en el sistema.* Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.* Establecerlas relaciones entre requerimientos que indiquen dependencias.* Negociar con flexibilidad para que exista un beneficio mutuo.* Enfocarse en intereses y no en posiciones.

Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema.Se espera que una especificación de requerimientos que fue aprobada porclientes y/o usuarios tenga al menos las siguientes características:

* Que contenga todos los requerimientos deseados.* Que cada requerimiento solo tenga una interpretación posible (esto apunta a eliminar ambigüedades).* Que el cumplimiento de cualquier requerimiento no provoque conflictoscon el cumplimiento de otro requerimiento, es decir, que sea consistente.* Que se definan prioridades.

1.4 REQUERIMIENTOS PARA LA GESTION

Los requerimientos para sistemas software grandes son siempre cambiantes. Debido a que el problema no puede definirse completamente, es muy probable que los requerimientos del software sean incompletos. Durante el proceso del software, la comprensión del problema por parte de los stakeholders está cambiando constantemente.Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante del problema.

Además, una vez que un sistema se ha instalado, inevitablemente surgen nuevos requerimientos.Es difícil para los usuarios y clientes del sistema anticipar qué efectos tendrá el sistema nuevo en la organización. Cuando los usuariosfinales tienen experiencia con un sistema, descubren nuevas necesidadesy prioridades:

1. Normalmente, los sistemas grandes tienen una comunidad deusuarios diversa donde los usuarios tienen diferentes requerimientos y prioridades. Éstos pueden contradecirse o estar en conflicto. Los requerimientos finales del sistema son inevitablemente un compromiso entre ellos y, con la experiencia, a menudo se descubre que la ayuda suministrada a los diferentes usuarios tiene que cambiarse.

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. Estos pueden estar en conflicto con los requerimientos de los usuarios finales y, después de la entrega, pueden tener que añadirse nuevas características de apoyo al usuario si el sistema tieneque cumplir sus objetivos.

3. El entorno de negocios y técnico del sistema cambia después de la instalación, y estos cambios se deben reflejar en el sistema. Se puede introducir nuevo hardware, puede ser necesario que el sistema interactúe con otros sistemas, las prioridades de negocio pueden cambiar con modificaciones consecuentes en la ayuda al sistema, y puedehaber una nueva legislación y regulaciones que deben ser implementadas por el sistema. La gestión 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 vínculos entre los requerimientos dependientes de forma que sepueda evaluar el impacto de los cambios en los requerimientos. Hay que establecer un proceso formal para implementar las propuestas de cambiosy vincular éstos a los requerimientos del sistema. Elproceso de gestión de requerimientos debería empezar en cuanto esté disponible una versión preliminar del documento de requerimientos, perose debería empezar a planificar cómo gestionar los requerimientos que cambian durante el proceso de obtención de requerimientos.REQUERIMIENTOS DURADEROS Y VOLÁTILES

La evolución de los requerimientos durante el proceso de ingeniería de requerimientos y después de que un sistema esté en uso es inevitable. El desarrollo de requerimientos software centra su atención en las capacidades de éste, los objetivos del negocio y otros sistemas de la organización.Conforme se va desarrollando la definición de los requerimientos, normalmente tiene una mejor comprensión de las necesidades de los usuarios. Esto retroalimenta la información del usuario, quien puede entonces proponer un cambio en los requerimientos (Figura 7.10). Además, especificar y desarrollar un sistema grande puede llevar variosaños. Durante ese tiempo, el entorno del sistema y los objetivos del negocio cambian, y los requerimientos evolucionan para reflejar esto.

Figura 7.10 Evolución 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 organización y que estánrelacionados directamente con el dominio del sistema. Por ejemplo, en un hospital siempre habrá requerimientos que se refieren a los pacientes, médicos, enfermeras y tratamientos. Estos requerimientos se pueden derivar de los modelos del dominio que muestran las entidades y relaciones quecaracterizan un dominio de aplicación (Easterbrook, 1993;Prieto-Díaz y Arango,1991).

2. Requerimientos volátiles. Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o después de que éste se haya puesto en funcionamiento. Un ejemplo serían los requerimientos resultantes de las políticas gubernamentales sobre sanidad. Harker y otros (Harker et al., 1993) han indicado que los requerimientos volátiles se dividen en cinco clases. Utilizando éstas como base, se ha desarrollado la clasificación mostrada en la Figura 7.11.

Figura 7.11 Clasificación de los requerimientos volátiles.

PLANIFICACIÓN DE LA GESTIÓN DE REQUERIMIENTOS

La planificación es una primera etapa esencial del proceso de gestión de requerimientos. La gestión de requerimientos tiene un coste elevado.Para cada proyecto, la etapa de planificación establece el nivel de detalle necesario en la gestión de requerimientos. Durante la etapa de gestión de requerimientos, habrá que decidir sobre:

1. La identificación 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 evaluacionesde rastreo.

2. Un proceso de gestión del cambio. Éste es el conjunto de actividadesque evalúan el impacto y coste de los cambios. Se trata con mayor detalle este proceso en la sección siguiente.

3. Políticas de rastreo. Estas políticas definen las relaciones entre los requerimientos, y entre éstos y el diseño del sistema que se debe registrar y la manera en que estos registros se deben mantener.

4. Ayuda deherramientas CASE. La gestión de requerimientos comprende elprocesamiento de grandes cantidades de información sobre los requerimientos. Las herramientas que se pueden utilizar van desde sistemas de gestión de requerimientos especializados hasta hojas de cálculo y sistemas sencillos de bases de datos.

Existen muchas relaciones entre los requerimientos y entre éstos y el diseño del sistema. También existen vínculos entre los requerimientos ylas razones fundamentales por las que éstos se propusieron. Cuando se proponen cambios, se debe rastrear el impacto de estos cambios en los otros requerimientos y en el diseño del sistema. El rastreo es una propiedad de la especificación de requerimientos que refleja la facilidad de encontrar requerimientos relacionados.Existen tres tipos de información de rastreo que pueden ser mantenidos:

* La información de rastreo de la fuente vincula los requerimientos conlos stakeholders que propusieron los requerimientos y la razón de éstos. Cuando se propone un cambio, esta información se utiliza para encontrar y consultar a los stakeholders sobre el cambio.

* La información de rastreo de los requerimientos vincula los requerimientos dependientes en el documento de requerimientos. Esta información se utiliza para evaluar cómo es probable que muchos requerimientos se vean afectados por un cambio propuesto y la magnitud de los cambios consecuentes en los requerimientos.

* La información de rastreo del diseño vincula los requerimientos a losmódulos del diseño en los cuales son implementados. Esta información seutiliza para evaluar el impacto de los cambios de losrequerimientos propuestos en el diseño e implementación del sistema.

A menudo, la información de rastreo se representa utilizando matrices de rastreo, las cuales relacionan los requerimientos con los stakeholders, con los módulos del diseño o los requerimientos entre ellos. En una matriz de rastreo de requerimientos, cada requerimiento se representa en una fila y en una columna de la matriz. Cuando existendependencias entre diferentes requerimientos, éstas se registran en la celda en la intersección fila/columna.La Figura 7.12 muestra una matriz de rastreo sencilla que registra las dependencias entre los requerimientos. Una «D» en la intersección fila/columna ilustra que el requerimiento en la fila depende del requerimiento señalado en la columna; una «R» significa que existe alguna otra relación más débil entre los requerimientos. Por ejemplo, ambos pueden definir los requerimientos para partes del mismo subsistema.

Las matrices de rastreo pueden utilizarse cuando se tiene que gestionarun número pequeño de requerimientos, pero son difíciles de manejar y caras de mantener para sistemas grandes con muchos requerimientos. Paraestos sistemas, se debería captar la información de rastreo en una basede datos de requerimientos en la que cada requerimiento esté explícitamente vinculado a los requerimientos relacionados. De esta forma, se puede evaluar el impacto de los cambios utilizando las facilidades de exploración de la base de datos. Se pueden generar automáticamente matrices de rastreo de la base de datos.

La gestión de requerimientos necesita ayuda automatizada; las herramientas CASE para esto deben elegirsedurante la fase de planificación. Se precisan herramientas de ayuda para:1. Almacenar requerimientos. Los requerimientos deben mantenerse en un

almacén de datos seguro y administrado que sea accesible a todos los que estén implicados en el proceso de ingeniería de requerimientos.2. Gestionar el cambio. Este proceso (Figura 7.13) se simplifica si está disponible una herramienta de ayuda.

3. Gestionar el rastreo. Como se indicó anteriormente, las herramientasde ayuda para el rastreo permiten que se descubran requerimientos relacionados. Algunas herramientas utilizan técnicas de procesamiento del lenguaje natural para ayudarle a descubrir posibles relaciones entre los requerimientos.

Para sistemas pequeños, es posible que no sea necesario utilizar herramientas de gestión de requerimientos especializadas. El proceso degestión de requerimientos puede llevarse a cabo utilizando los recursosdisponibles en los procesadores de texto, hojas de cálculo y bases de datos en PC. Sin embargo, para sistemas grandes, se requieren herramientas de ayuda más especializadas. En el sitio web del libro he incluido enlaces a herramientas de gestión de requerimientos como DOORSy RequisitePro.

GESTIÓN DEL CAMBIO DE LOS REQUERIMIENTOS

La gestión del cambio de los requerimientos (Figura 7.13) 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 tres etapas principales en un proceso de gestión decambio:

1. Análisis del problema y especificación del cambio. El proceso empieza con la identificación de un problema en los requerimientos o, algunas veces, con una propuesta de cambio específica. Durante esta etapa, el problema o la propuesta de cambio se analizan para verificar que ésta es válida. Los resultados del análisis se pasan al solicitantedel cambio, y algunas veces se hace una propuesta de cambio de requerimientos más específica.

2. Análisis del cambio y cálculo de costes. El efecto de un cambio propuesto se valora utilizando la información de rastreo y el

conocimiento general de los requerimientos del sistema. El coste de hacer un cambio se estima en términos de modificaciones al documento derequerimientos y, si es apropiado, al diseño e implementación del sistema. Una vez que este análisis se completa, se toma una decisión sobre si se continúa con el cambio de requerimientos.

3. Implementación del cambio. Se modifica el documento de requerimientos y, en su caso, el diseño e implementación del sistema. Debe organizar el documento de requerimientos de modo que pueda hacer cambios en él sin tener que hacer grandes reorganizaciones o redactar nuevamente gran cantidad del mismo. Como sucede con los programas, los cambios en los documentos se llevan a cabo minimizando las referencias externas y haciendo las secciones del documento tan modulares como sea posible. De esta manera, se pueden cambiar y reemplazar secciones individuales sin afectar a otras partes del documento.

Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe siempre la tentación de hacer ese cambioal sistema y entonces modificar de forma retrospectiva el documento de requerimientos. Esto conduce casi inevitablemente a que la especificación de requerimientos y la implementación del sistema se desfasen. Una vez que se han hecho los cambios en el sistema, los del documento de requerimientos se pueden olvidar o se hacen de forma que no concuerdan con los cambios del sistema.

Los procesos de desarrollo iterativo, como la programación extrema, se han diseñado para hacer frente a los requerimientos que cambian duranteel proceso de desarrollo. En estos procesos, cuando un usuario propone un cambio en los requerimientos, no se hace a través de un proceso formal de gestión del cambio. Más bien, el usuario tiene que establecerla prioridad del cambio y, si es de alta prioridad, decidir qué característica del sistema que fue planificada para la siguiente iteración debería abandonarse.

UNIDAD IIPLANIFICACIÓN DEL SISTEMAINTRODUCCIÓN

GESTIÓN DE PROYECTOSLa gestión de proyectos de software se hace necesaria ya que todo

proyecto está sujeto a restricciones de presupuesto y tiempos. La gestión permite asegurar que el software se lleve a cabo a tiempo y de acuerdo con los requerimientos especificados.

La gestión del software es particularmente difícil, algunas de las razones son: * El producto de software es intangible. * No hay un proceso estándar. * A menudo los proyectos de software grandes son únicos.

Las de las actividades comunes de la gestión de proyectos software son:* Redacción de la propuesta.* Planificación del proyecto* Estimaciones de costo, tiempo yesfuerzo.* Supervisión y revisión del proyecto.* Selección y evaluación del personal.* Redacción y presentación de informes.

2.1 PLANIFICACIÓN DEL TIEMPO

¿QUE ES LA PLANIFICACIÓN?Es una guía de desarrollo para cumplir las metas del proyecto. Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado. Esto quiere decir que su revisión es continua, ya que tanto requerimientos como restricciones pueden cambiar a lo largo del desarrollo.

El éxito o fracaso de un proyecto de software depende en gran parte de la planificación, ya que con ayuda de ésta se pueden evitar problemas alos que un proyecto está sujeto, tales como:

* Retraso de tiempo de entrega* Sobrepasar el presupuesto * Baja calidad del producto* Alto costo de mantenimiento, etc.

Actividades de la Gestión y la Planificación

Planificación del tiempo* El factor tiempo es muy importante en el desarrollo de software ya

que ganaremos o perderemos a un cliente si este no es entregado en los tiempos establecido o ya negociados.* La planificación de tiempo se puede definir como una actividad en la cual se debe estimar el tiempo que requerirá para llevar a cabo una tarea y los recursos necesarios para su realización.Actividades e Hitos* Durante la recolección de requerimientos, se listan todos los elementos que se deben entregar del proyecto (actividades e hitos), queson los ítems que los clientes esperan ver durante el desarrollo del proyecto.* La descomposición en hitos y actividades beneficia: Tanto a clientes como desarrolladores para entender el desarrollo ymantenimiento del sistema.Calendarizar el proyectoUna vez definidas las actividades y hitos lo siguiente es calendarizar el proyecto, esto es, dividir el trabajo en actividades o tareas complementarias y considerar el tiempo que requiere cada una para completarse. Generalmente se representa con gráficos de barras y grafoso redes de actividades que muestran las actividades, los responsables, la dependencia entere actividades y la asignación de recursos, entre otras cosas.El gestor debe coordinar las tareas del trabajo, asignarles a éstas el personal y otros recursos de tal manera que se aprovechen de manera óptima. Las actividades por lo general duran al menos una semana, la cantidad de tiempo máxima sugerida es de 8 a 10 semanas. Al gestor para juzgar el progreso del software y puede entonces actualizar costos y el calendario

MÉTODOS DE PLANIFICACIÓN TEMPORAL

Existen varios métodos para la planificación: * La técnica de revisión y evaluación del programa(PERT) * CPM la ruta críticaTambién existen varias representaciones gráficas como los son:* Redes de actividades * Gráficos de barras

DIAGRAMA DE ACTIVIDADESPor, medio de una red de actividades se muestra la dependencia entre las diferentes actividades y se estima el tiempo en que tardará cada

tarea, se debe considerar que algunas de éstas se podrán realizar en paralelo.

DIAGRAMAS DE GANTTEn un diagrama de Gantt las actividades son seguidas por una barra sombreada (azul) y cuya longitud es calculada por una herramienta de calendarización. La barra azul indica que hay flexibilidad en la fecha de terminación para dichasactividades. Entonces la ruta crítica se ve afectada solamente si:* Las actividades que no tienen barra azul no se completan a tiempo.* Las actividades con barra azul pasa del límite de tiempo marcado por ésta.

1. Introducción.Cada programa refleja el conjunto, único, de prioridades y responsabilidades de la persona que lo ha realizado. No hay dos personas que tengan exactamente la misma idea de lo que constituye la gestión perfecta del tiempo. La idea final es simplemente ver si tu relación con el tiempo es buena, si te permite responder a tus obligaciones profesionales, disfrutar de la compañía de tus seres queridos y cuidar bien de tu activo más importante, la salud. No hay unúnico modelo a gusto de todos sobre cómo gestionar el tiempo, pero hay una serie de principios básicos que se pueden aplicar a una gran variedad de circunstancias.

2. Planificar por adelantadoPlanificar es la piedra sobre la que se basa la gestión del tiempo, todo el tiempo que le dediques a esa tarea merece la pena. Pero no consiste sólo en crear una buena planificación o programa, debes ser capaz de llevarlo a cabo. Esto supone ser preciso sobre la realidad diaria de tu trabajo y el resto de responsabilidades, contar con las interrupciones, conflictos y retrasos habituales. Como si fuera una prenda de vestir, debes sentirte cómodo y que te quede un poco amplia por si acaso encoge.

3. Programa actividades de ocioLos mejores planes de gestión de tiempo te acompañan durante toda la vida, no sólo durante tus horas de trabajo. Intenta programar periodos de tiempo dedicados a la familia, amigos, hacer ejercicio, interesesespeciales o proyectos especiales, en vez de dedicarles “el

tiempo que quede” después de la rutina diaria habitual. Esto te dará laoportunidad de observar tu relación actual del trabajo que te llevas a casa y del tiempo libre, para ayudar a restablecer el equilibrio si se ha perdido.

4. Promete menos y cumple másUna de las reglas más inteligentes que se pueden aplicar es establecer fechas de entrega que sean viables. En otras palabras, es una buena idea sobrestimar el tiempo que piensas que te va a llevar un trabajo para, primero, asegurarse el cumplimiento del plazo incluso si hay que enfrentarse a retrasos imprevistos y segundo, sorprender positivamente a tu jefe, clientes, compañeros de comité y familia, terminando antes de lo previsto.

5. Divide los trabajos grandes en tareas manejablesEs muy fácil aceptar trabajos de grandes proporciones. Por ejemplo, “pintar la casa” será un proyecto menos desalentador si se siguen bien los pasos hasta conseguir ese objetivo: seleccionar el color, comprar la pintura y empezar a trabajar en la fachada de atrás.

6. Haz un seguimiento de tus progresosCada proyecto de envergadura requiere su propia programación, agenda y calendario para identificar los pasos principales o hitos en el camino hacia su consecución. Si has establecido fechas, objetivo realista, y tienes previsto tiempo para “resbalones” posibles, tus progresos deberían responder a tu plan. Si hay imprevistos que te sitúan por detrás de la fecha prevista, puedes avisar a tu jefe o cliente y establecer una fecha de consecución revisada o dar los pasos necesariospara acelerar su progreso y recuperar el tiempoperdido. Nota: Si puedes, deja espacio en tu programa para anotar trabajos en proceso de realización.

7. Delega lo que puedasCuando se trata de delegar, parece que hay dos tipos de personas: aquellos que pueden y los que no pueden. Si eres uno de los últimos y encuentras todo tipo de razones para hacer las cosas por ti mismo (“…setarda demasiado en explicárselo a otra persona” o “…al final acabo por tener que repetirlo”) entonces es inútil intentarlo. Sin embargo, si piensas que no eres tan indispensable como crees, es hora de empezar a delegar. Comienza con la rutina, trabajos que requieren mucho tiempo y

que sabes que alguien más puede llevar a cabo. Acepta que enseñar a otra persona puede llevar un poco de tiempo, y permite una curva de aprendizaje razonable. Te beneficiarás en tener más tiempo y menos estrés.

8. Establece parámetros para decir “No”Todos conocemos a gente que establecen sus límites de tiempo: “No es mitrabajo”, dicen. “Son las cinco y me voy”. Puede parecer excesivo pero también sabemos que muchas personas terminan trabajando hasta tarde o se llevan trabajo a casa de vez en cuando, por ello puede que haya llegado el momento de empezar a decir “no” y no sólo a los otros, sino también a ti mismo. Trabajar durante horas y horas, tanto si recibe paga extra o no, daña el equilibrio entre trabajo y ocio que es básico para la salud y el bienestar.

9. Haz y sigue una lista de prioridadesNo hace falta que seas un experto para elaborar listas de prioridades. Algunas personas llevan varias listas a la vez: una de mayor prioridad para las tareas urgentes y muy importantes, una de prioridad mediapara las tareas menos urgentes o medianamente importantes, y otra de baja prioridad para tareas que le gustaría hacer cuando tenga tiempo.

10. Agrupa tareas según las capacidades requeridasPara sacar el mayor partido a tu tiempo, trata de realizar los trabajosmás difíciles, aquellos que requieren la máxima concentración y mayor eficiencia en aquellos momentos del día en los que tus niveles de energía y atención son mayores. Si puedes coordinar esos momentos con periodos en los que tienes menos interrupciones de lo normal, mucho mejor. De la misma forma, trata de programar tu rutina, tareas de bajo nivel para las horas del día en las que te resulta más difícil concentrarse. El truco está en identificar tus horas de mayor rendimiento y programar tu trabajo en consecuencia.

11. Mantén los ojos abiertos para encontrar atajosEs siempre tentador seguir haciendo las cosas de la forma en que se hanhecho siempre, porque es con lo que se está familiarizado. Encontrar, adaptar y aplicar nuevas técnicas más eficientes a tus responsabilidades, no sólo te ahorrará tiempo, sino que rebajará tu carga de trabajo total.

2.2. EVALUACIÓN DE COSTO BENEFICIO.

El costo-beneficio es el análisis basado en obtener mayores y mejores resultados con el menor esfuerzo posible.* Beneficios mayores al costo, éxito.* Costo mayor a beneficios, fracaso.

¿CÓMO IDENTIFICAR Y PRONOSTICAR LOS COSTOS Y BENEFICIOS?Aunque se propongan sistemas o mejoras en un sistema, la decisión de continuar o no con el proyecto se basará en el análisis de costo-beneficio y no en los requerimientos de información.En gran medida los beneficiosse miden por los costos.

¿CÓMO PRONOSTICAR LOS COSTOS Y BENEFICIOS?La condición principal para escoger un modelo es la disponibilidad de los antecedentes.Si no están disponibles, el analista debe volver a uno de los métodos de discernimiento: las estimaciones de la fuerza de ventas, estudios para estimar la demanda del cliente si ya hay antecedentes se involucrael tipo de pronóstico:El pronóstico condicional implica que hay una asociación entre las variables en el modelo que dicha relación causal existe.ESTIMACIÓN DE LAS TENDENCIAS

Las tendencias se pueden estimar de diferentes formas:* JUICIO GRÁFICO:Se realiza simplemente al observar un gráfico y al estimar una prolongación de una línea o curva a pulso. Una vez encontrada la línea más apropiada, se puede granear y la línea se puede prolongar para pronosticar lo que pasará.

* IDENTIFICACIÓN DE BENEFICIOS Y COSTOSLos beneficios y costos se pueden representar como tangibles o intangibles.Beneficios tangibles:Los beneficios tangibles son ventajas que se pueden medir en dólares que se acreditan a la organización mediante el uso del sistema de información (ahorros).* BENEFICIOS INTANGIBLES:Algunos beneficios que se acreditan a la organización mediante el uso

del sistema de información son difíciles de medir pero aun así son importantes, incluyen mejorar el proceso de toma de decisiones, incrementar la exactitud, ser más competitivo en el servicio al cliente, mantener una buena imagen del negocio e incrementar la satisfacción del trabajo para los empleados eliminando las tareas tediosas.* COSTOS TANGIBLES:Los costos tangiblesson aquellos que el analista de sistemas y el personal de contabilidad del negocio pueden proyectar con precisión. Costo de equipo tal como las computadoras y terminales, el costo de recursos, el costo del tiempo de analistas de sistemas, el costo del tiempo de programadores y sueldos de otros empleados.* COSTOS INTANGIBLES:Los costos intangibles son difíciles de estimar y podrían ser desconocidos.Éstos incluyen perder una ventaja competitiva, perder la reputación por no ser el primero con una innovación o un líder en un campo, deterioro de la imagen de la compañía debido al incremento en la insatisfacción del cliente y toma de decisiones ineficaz debido a la información inoportuna o inaccesible.* Comparación de los costos y beneficios.* Algunas técnicas empleadas son:* Análisis del punto de equilibrio.* Análisis del tiempo de recuperación de la inversión.* Análisis de flujo de efectivo.* Análisis de valor presente

ANÁLISIS DEL PUNTO DE EQUILIBRIO.Es el punto en donde los ingresos totales recibidos se igualan a los costos asociados con la venta de un producto. Un punto de equilibrio esusado comúnmente en las empresas u organizaciones para determinar la posible rentabilidad de vender determinado producto. Para calcular el punto de equilibrio es necesario tener bien identificado el comportamiento de los costos; de otra manera es sumamente difícil determinar la ubicación de este punto.

ANÁLISIS DEL TIEMPO DE RECUPERACIÓN DE LA INVERSIÓN.

* PERIODO DE RECUPERACION DE LA INVERSION

EL tiempo exacto que requiere una empresa para recuperar su inversión inicial en unproyecto; se calcula a partir de las entradas de efectivo

* ANÁLISIS DE FLUJO DE EFECTIVO.Por medio de este trabajo se conocerá la importancia que merece el Estado de Flujo de Efectivo en la toma de decisiones en una empresa, cualquiera que sea su actividad.La generación de efectivo es uno de los principales objetivos de los negocios. La mayoría de sus actividades van encaminadas a provocar de una manera directa o indirecta, un flujo adecuado de dinero que permita, entre otras cosas, financiar la operación, invertir para sostener el crecimiento de la empresa, pagar, en su caso, los pasivos asu vencimiento, y en general, a retribuir a los dueños un rendimiento satisfactorio.

* ANÁLISIS DE VALOR PRESENTELas alternativas que se pueden dar, son el resultado de considerar diferentes sumas de dinero en relación a distintos tiempos, dentro de la vida útil de las mismas. Para posibilitar la selección más apropiada, dichas alternativas deben ser reducidas a una base temporal común, entendiéndose como tal, la comparación realizada en el mismo punto del eje temporal. Las bases más comunes de comparación son:- Valor presente: la comparación es realizada entre cantidades equivalentes computadas en el tiempo presente.- Costo anual uniforme: la comparación es realizada al final del año entre cantidades anuales uniformes equivalentes (base temporal: un año).- Costo capitalizado: la comparación es realizada con la premisa de disponer de los fondos necesarios para reponer el equipo una vez cumplida su vida útil.

2.3 ESTUDIO DE LA VIABILIDAD

DESCRIPCIÓN Y OBJETIVOS

Mientras que el Plan de Sistemas deInformación tiene como objetivo proporcionar un marco estratégico que sirva de referencia para los Sistemas de Información de un ámbito concreto de una organización, el objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto

plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio puede serla definición de uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual. A partir del estado inicial, la situaciónactual y los requisitos planteados, se estudian las alternativas de solución.Dichas alternativas pueden incluir soluciones que impliquen desarrollosa medida, soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas, indicando los requisitos que cubre.Una vez descritas cada una de las alternativas planteadas, se valora suimpacto en la organización, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación.Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán informacióna tener en cuenta en todo el proceso. Las actividades que englobaeste proceso se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realización resultados originados en actividades anteriores.

El objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio puede ser la definiciónde uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual.El proceso de ingeniería de requerimientos comienza con un estudio de viabilidad. Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por la organización. Llevar a cabo un estudio de factibilidad comprende la evaluación y

recolección de información y la redacción de informes.

ViablidadTécnicaViabilidadEconómicaViabilidadOperativa

VIABILIDAD ECONÓMICA

VIABILIDAD TÉCNICA

VIABILIDAD OPERATIVA

ESTUDIO DE LA VIABILIDADEl estudio de viabilidad constará de las siguientes partes: 1.- INTRODUCCION 2.- ESTUDIO DE MERCADO 3.- TAMAÑO DEL PROYECTO. 4.-LOCALIZACIÓN 5.- INVERSION Y FINANCIACIÓN 6.- PRESUPUESTO 7.- PROGRAMA 8.- EVALUACION

1.- INTRODUCCIÓN:El informe debe reflejar la situación de partida que ha dado origen a la preparación del Estudio deViabilidad.

2.- ESTUDIO DE MERCADO: Constará de los siguientes sub-apartados: * El mercado del proyecto: detalle de la situación actual y futura de los posibles consumidores, competidores, demanda, hábitos de consumo, etc. * Estudios de proyección de mercado: modelos de series temporales, regresión, etc. * 3.- TAMAÑO DEL PROYECTO. PROCESOS APLICABLES Y TECNOLOGÍA A EMPLEAR:En lo referente al tamaño del proyecto de deberá indicar:

* Factores que determinan el tamaño del proyecto * Posibles economías de escala * Optimización del tamaño: en mercados crecientes o de demanda constante. En lo referente a los procesos y tecnología aplicables: * Proceso elegido en el caso de un producto industrial * Tecnología(s) a utilizar y su justificación: costes, calidad, etc. 4.- LOCALIZACIÓN. EMPLAZAMIENTO. IMPACTO AMBIENTAL Deberán incluirse los siguientes sub-apartados: * Factores de localización * Métodos de evaluación para la optimización de la localización: cualitativos, Brown y Gibson, etc. Estudio del emplazamiento: factores que influyen Optimización del emplazamiento

5.-INVERSIÓN Y FINANCIACIÓN Debe incluir los siguientes sub-apartados: * Estimación de costes: materias primas, mano de obra, adquisición de equipos, etc. * Análisis coste-volumen-utilidad y posibles economías de escala * Inversiones previas y en capital inicial de trabajo * Fuentes de financiación y beneficios de la inversión * 6.- PRESUPUESTO Debe incluir: * Flujo de caja proyectado * Cuentas de ingresos y gastos proyectados * Costes de producción porpartidas: materias primas, mano de obra, seguros, etc. * Fondos contables de amortización

7.- PROGRAMA Hay que distinguir entre programa y herramienta de programación. El programa debe ser una expresión clara de la sucesión en el tiempo de las actividades principales que hay que realizar para satisfacer la necesidad origen del E. de V. Es decir, expresión gráfica sencilla de todo lo que hay que hacer. Naturalmente, el programa habrá de ser absolutamente coherente con el presupuesto y reflejar, junto con aquél,la claridad de ideas que se tiene sobre cómo llevar adelante el intento

que se está promoviendo.

8.- EVALUACIÓN Si la idea es un negocio deberá acompañarse de la justificación de su rentabilidad. Caso de no justificarse, se deberán expresar las razones en que se apoya la propuesta. Es recomendable incluir un análisis de sensibilidad y riesgo a la evaluación. Los criterios de rentabilidad a incluir serán: * Tasa de rentabilidad * Periodo de recuperación del capital * Velocidad de rotación del capital * VAN * TIR

ACTIVIDADES Las actividades que engloba este proceso se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realización resultados originados en actividades anteriores.

ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA

En esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario, o como consecuencia de la realización de un PSI, realizando una descripción general de la misma. Se determinan los objetivos, se inicia el estudio de losrequisitos y se identifican las unidades organizativas afectadas estableciendo su estructura. Se analizan las posibles restricciones, tanto generales como específicas, que puedan condicionar el estudio y la planificación de las alternativas de solución que se propongan. Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación. Se detalla la composición del equipo de trabajo necesario para este proceso y su planificación. Finalmente, con el fin de facilitar la implicación activa de los usuarios en la definición del sistema, se identifican susperfiles, dejando claras sus tareas y responsabilidades.

TAREA EVS 1.1: ESTUDIO DE LA SOLICITUD

Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de iniciar el estudio de los requisitos del sistema se establecenlos objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente.Si el sistema objeto de estudio se encuentra en el ámbito de un Plan deSistemas de Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, como información adicional para ladescripción general del sistema y determinación de los requisitos iniciales.

Productos * De entrada

* Catálogo de Requisitos del PSI (PSI 9.2)* Arquitectura de Información (PSI 9.2)* Solicitud (externo) * De salida

* Descripción General del Sistema* Catálogo de Objetivos del EVS* Catálogo de Requisitos Prácticas * Catalogación* Sesiones de trabajo Participantes * Comité de Dirección* Jefe de Proyecto* Análisis

TAREA EVS 1.2: IDENTIFICACIÓN DEL ALCANCE DEL SISTEMA

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. Esta información se recoge en el catálogo

de requisitos.Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la arquitectura de información propuesta para analizar el alcance del sistema e identificar los sistemas de información que quedan fuera del ámbito del estudio. Además, se estudia el plan de proyectos, para determinar las posibles dependencias con otros proyectos.Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo.


* Plan de Proyectos (PSI 9.2)* Arquitectura de Información (PSI 9.2)* Descripción General delSistema (EVS 1.1)* Catálogo de Objetivos del EVS (EVS 1.1)* Catálogo de Requisitos (EVS 1.1) * De salida• Descripción General del Sistema: * Contexto del Sistema * Estructura Organizativa • Catálogo de Requisitos: * Requisitos Relativos a Restricciones * Dependencias con Otros Proyectos* Catálogo de Usuarios * Técnicas * Diagrama de Flujo de Datos* Diagrama de Descomposición Funcional * Prácticas * Catalogación* Sesiones de trabajo

* Participantes * Comité de Dirección* Jefe de Proyecto* Analistas

TAREA EVS 1.3: ESPECIFICACIÓN DEL ALCANCE DEL EVS

En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación actual y, en el caso de considerarlo necesario, con quéobjetivo. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de información propuesta, en cuanto a la identificación delos sistemas de información actuales, implicados en el ámbito de este estudio, que se haya decidido conservar. Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realización delEstudio de Viabilidad del Sistema, determinando previamente sus perfiles y responsabilidades.Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en elEstudio de Viabilidad, solicitando su aceptación y esperado su confirmación.


• Arquitectura de Información (PSI 9.2)• Catálogo de Objetivos del EVS (EVS 1.1)• Descripción General del Sistema (EVS 1.2)• Catálogo de Usuarios (EVS 1.2) * De salida

• Catálogo de Objetivos del EVS:

ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIÓN ACTUAL

La situación actual es el estado en el que se encuentran los sistemas de información existentes en el momento en el que se inicia su estudio.Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la información existente acerca de los sistemas de información afectados. En función de dicha valoración, se especifica el nivel de detalle con que se debe llevar a cabo el

estudio. Si es necesario, se constituye un equipo de trabajo específicopara su realización y se identifican los usuarios participantes en el mismo.Si se decide documentar la situación actual, normalmente es convenientedividir el sistema actual en subsistemas. Si es posible se describirá cada uno de los subsistemas, valorando qué información puede ser relevante para la descripción.Como resultado de esta actividad se genera un diagnóstico, estimando laeficiencia de los sistemas de información existentes e identificando los posibles problemas y las mejoras.

TAREA EVS 2.1: VALORACIÓN DEL ESTUDIO DE LA SITUACIÓN ACTUAL

En función de los objetivos establecidos para el estudio de la situación actual, y considerando el contexto del sistema especificado en la descripción general del mismo, se identifican los sistemas de informaciónexistentes que es necesario analizar con el fin de determinar el alcance del sistema actual. Asimismo, se decide el nivel de detalle con el que se va a llevar a cabo el estudio de cada uno de los sistemas de información implicados. En el caso de haber realizado un Plan de Sistemas de Información que afecte a dicho sistema, se toma como punto de partida para este análisis la arquitectura de informaciónpropuesta.Para poder abordar el estudio, se realiza previamente una valoración dela información existente acerca de los sistemas de información afectados por el EVS. Se debe decidir si se realizan o no los modelos lógicos del sistema actual o si se describe el modelo físico, en función de los siguientes criterios: - Si existen los modelos lógicos, y son fiables, se utilizan en la tarea Descripción de los Sistemas de Información Existentes (EVS 2.3) - Si no existen dichos modelos, o no son fiables, se considera el tiempo de vida estimado para el sistema de información en función de laantigüedad, la obsolescencia de la tecnología o la falta de adecuación funcional para determinar sí se obtienen los modelos lógicos y físicos del sistema actual o por el contrario no se elabora ningún modelo. La información relativa a los sistemas de información que se decida analizar, se obtiene mediante sesiones de trabajo con los Directores deUsuarios y el apoyo de los profesionales de Sistemas y Tecnologías de la Información y Comunicaciones (STIC) que se considere necesario.


* Información Existente del Sistema Actual (externo)* Arquitectura de Información (PSI 9.2)* Catálogo deObjetivos del EVS (EVS1.3) * Descripción General del Sistema (EVS 1.2) * De salida* Descripción de la Situación Actual: * Contexto del Sistema Actual * Descripción de los Sistemas de Información Actuales Técnicas * Diagrama de Flujo de Datos Prácticas * Diagrama de Representación* Sesiones de Trabajo Participantes * Jefe de Proyecto* Analistas* Directores de Usuarios

TAREA EVS 2.2: IDENTIFICACIÓN DE LOS USUARIOS PARTICIPANTES EN EL ESTUDIO DE LA SITUACIÓN ACTUAL

En función del nivel de detalle establecido para el estudio de la situación actual, se identifican los usuarios participantes de cada unade las unidades organizativas afectadas por dicho estudio. Se informa alos usuarios identificados como implicados en el Estudio de la Situación Actual, se solicita su aceptación y se espera su confirmación.

Productos * De entrada* Descripción General del Sistema (EVS 1.2)* Catálogo de Usuarios (EVS 1.3)* Descripción de la Situación Actual (EVS 2.1) * De salida* Catálogo de Usuarios Prácticas * Catalogación

* Sesiones de Trabajo Participantes * Jefe de Proyecto* Directores de Usuarios

TAREA EVS 2.3: DESCRIPCIÓN DE LOS SISTEMAS DE INFORMACIÓN EXISTENTES En esta tarea se describen los sistemas de información existentes afectados, según el alcance y nivel de detalle establecido en la tarea Valoración del Estudio de la Situación Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este estudio.Si se ha decidido describir los sistemas a nivel lógico, y siexiste un conocimiento suficiente de los sistemas de información a especificar, puede hacerse directamente, aplicando las técnicas de modelización y siguiendo un método descendente. Si no se dispone del conocimiento suficiente, se construyen los modelos a partir de la descripción del modelo físico, es decir, de forma ascendente.Si se tiene que describir el modelo físico, se puede hacer mediante un Diagrama de Representación en el que se recojan todos los componentes físicos y sus referencias cruzadas. Otra opción es describir el modelo físico de forma más detallada, para lo que es necesaria la utilización de herramientas de tipo scanner.Es conveniente indicar la localización geográfica y física actual de los módulos y datos de los sistemas de información afectados, evaluandoal mismo tiempo la redundancia en las distintas unidades organizativas.

Productos

* De entrada

* Descripción de la Situación Actual (EVS 2.1)* Catálogo de Usuarios (EVS 2.2) * De salida* Descripción de la Situación Actual: * Descripción Lógica del Sistema Actual * Modelo Físico del Sistema Actual (opcional) * Matriz de Localización Geográfica y Física de Módulos y Datos, incluidas las redundancias Técnicas * Diagrama de Flujo de Datos * Modelo Entidad/ Relación extendido

* Diagrama de Clases* Diagrama de Interacción de Objetos* Matricial Prácticas * Diagrama de Representación* Sesiones de Trabajo Participantes * Analistas* Usuarios Expertos * Equipo de Soporte Técnico

TAREA EVS 2.4: REALIZACIÓN DEL DIAGNÓSTICO DE LA SITUACIÓN ACTUALCon elfin de elaborar el diagnóstico de la situación actual se analiza la información de los sistemas de información existentes, obtenida en la tarea anterior y se identifican problemas, deficiencias y mejoras. Estas últimas deben tenerse en cuenta en la definición de los requisitos.

ACTIVIDAD EVS 3: DEFINICIÓN DE REQUISITOS DEL SISTEMA

Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de solución que se propongan.

TAREA EVS 3.1: IDENTIFICACIÓN DE LAS DIRECTRICES TÉCNICAS Y DE GESTIÓN

La realización de esta tarea permite considerar los términos de referencia para el sistema en estudio desde el punto de vista de directrices tanto técnicas como de gestión. Si el sistema en estudio pertenece al ámbito de un Plan de Sistemas de Información vigente, ésteproporciona un marco de referencia a considerar en esta tarea.Con este fin, se recoge información sobre los estándares y procedimientos que deben considerarse al proponer una solución, relativos ha: - Políticas técnicas:

- Gestión de Proyectos (seguimiento, revisión y aprobación final). - Desarrollo de Sistemas (existencia de normativas, metodologías y técnicas de programación). - Arquitectura de Sistemas (centralizada, distribuida).- Política de Seguridad (control de accesos, integridad de datos,disponibilidad de aplicaciones).- Directrices de Planificación.- Directrices de Gestión de Cambios.- Directrices de Gestión de Calidad. Productos * De entrada

• Catálogo de Normas del PSI (PSI 3.2)

• Recopilación de Directrices Técnicas y de Gestión (externo)* De salida • Catálogo de Normas Prácticas • Catalogación Participantes • Jefe de Proyecto• Analistas• Usuarios Expertos

TAREA EVS 3.2: IDENTIFICACIÓN DE REQUISITOS

Para la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qué tipo de sesiones de trabajo se realizarán y con qué frecuencia tendrán lugar, en función de la disponibilidad de los usuarios participantes. Si se ha realizado el Estudio de la Situación Actual (EVS 2), puede serconveniente seleccionar la información de los sistemas de información existentes que resulte de interés para el desarrollo de dichas sesionesde trabajo. Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los usuarios participantes identificados alestudiar el alcance del Estudio de Viabilidad del Sistema (EVS1.3), y se realizan de acuerdo al plan previsto. La información obtenida depende del tipo de sesión de trabajo seleccionado.

Productos

* De entrada

• Descripción General del Sistema (EVS 1.2)• Catálogo de Requisitos (EVS 1.2)• Equipo de Trabajo del EVS (EVS 1.3)• Catálogo de Usuarios (EVS 2.2/1.3)• Descripción de la Situación Actual (EVS 2.4) De salida• Identificación de Requisitos Prácticas • Sesiones de Trabajo Participantes • Jefe de Proyecto• Analistas• Usuarios Expertos

TAREA EVS3.3: CATALOGACIÓN DE REQUISITOS

Se analiza la información obtenida en las sesiones de trabajo para la Identificación de Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades.Se incluirán también requisitos relativos a distribución geográfica y entorno tecnológico.


• Identificación de Requisitos (EVS 3.2)• Catálogo de Requisitos (EVS 1.2) * De salida

• Catálogo de Requisitos Prácticas • Catalogación Participantes • Jefe de Proyecto• Analistas• Usuarios Expertos

ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIÓN

Este estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos planteados, considerando también los resultados obtenidos en el Estudio de la Situación Actual (EVS 2), en el caso de que se haya realizado. Teniendo en cuenta el ámbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar, previamente a la definición de cada alternativa, una descomposición del sistema en subsistemas.En la descripción de las distintas alternativas de solución propuestas,se debe especificar si alguna de ellas está basada, total o parcialmente, en un producto existente en el mercado. Si la alternativaincluye un desarrollo a medida, se debe incorporar en la descripción dela misma un modelo abstracto de datos y un modelo de procesos, y en orientación a objetos, un modelo de negocio y un modelo de dominio

TAREA EVS 4.1: PRESELECCIÓN DE ALTERNATIVAS DE SOLUCIÓN

Una vez definidos los requisitos a cubrirpor el sistema, se estudian las diferentes opciones que hay para configurar la solución. Entre ellas, hay que considerar la adquisición de productos software estándardel mercado, desarrollos a medida o soluciones mixtas.Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente una descomposición del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar el estudio de la solución, combinando las opciones que se consideren más adecuadas.

Productos * De entrada• Información de Productos Software del Mercado (externo)• Descripción General del Sistema (EVS 1.2)• Descripción de la Situación Actual (EVS 2.4)• Catálogo de Requisitos (EVS 3.3) * De salida• Descomposición Inicial del Sistema en Subsistemas (opcional)• Alternativas de Solución a Estudiar

Prácticas • Diagrama de Representación

Participantes • Jefe de Proyecto• Analistas• Técnicos de Sistemas

TAREA EVS 4.2: DESCRIPCIÓN DE LAS ALTERNATIVAS DE SOLUCIÓN

Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta.Se deben considerar también aspectos relativos a la cobertura geográfica (ámbito y limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestión de comunicaciones y control de red.En la definición de cada alternativa, se propone una estrategia de implantación teniendo en cuenta tanto la cobertura global del sistema como la cobertura geográfica.Si la alternativa incluye desarrollo se describe el modelo abstracto dedatos y el modelo de procesos, y en elcaso de Orientación a Objetos, elmodelo de negocio y, opcionalmente, el modelo de dominio. Se propone elentorno tecnológico que se considera más apropiado para la parte del sistema basada en desarrollo y se describen los procesos manuales.Si la alternativa incluye una solución basada en producto se analiza suevolución prevista, adaptabilidad y portabilidad, así como los costes ocasionados por licencias, y los estándares del producto. Igualmente sevalora y determina su entorno tecnológico.


• Descripción General del Sistema (EVS 1.2)• Descripción de la Situación Actual (EVS 2.4)• Catálogo de Requisitos (EVS 3.3)• Descomposición Inicial del Sistema en Subsistemas (EVS 4.1) (opcional)• Alternativas de Solución a Estudiar (EVS 4.1) * De salida

• Catálogo de Requisitos (actualizado)• Alternativas de Solución a Estudiar: * Catálogo de Requisitos (cobertura) * Modelo de Descomposición en Subsistemas

* Matriz Procesos / Localización Geográfica * Matriz Datos / Localización Geográfica * Entorno Tecnológico y Comunicaciones * Estrategia de Implantación Global del Sistema * Descripción de Procesos Manuales* Si la alternativa incluye desarrollo: * Modelo Abstracto de Datos / Modelo de Procesos * Modelo de Negocio / Modelo de Dominio (en caso de Orientación a Objetos)* Si la alternativa incluye un producto software estándar de mercado: * Descripción del Producto * Evolución del Producto * Costes Ocasionados por Producto * Estándares del Producto * Descripción de Adaptación (si es necesaria)Técnicas • Matricial• Diagrama de Flujo de Datos • Modelo Entidad/ Relación extendido• Diagrama de Clases• Casos de Uso Prácticas • Catalogación• Diagrama de Representación Participantes • Jefe de Proyecto• Analistas• Usuarios Expertos • Técnicos de Sistemas• Responsable de Seguridad• Especialistas en Comunicaciones

ACTIVIDAD EVS 5: VALORACIÓN DE LAS ALTERNATIVAS

Una vez descritas las alternativas se realiza una valoración de las mismas, considerando el impacto en la organización, tanto desde el punto de vista tecnológico y organizativo como de operación, y los posibles beneficios que se esperan contrastados con los costes asociados. Se realiza también un análisis de los riesgos, decidiendo cómo enfocar el plan de acción para minimizar los mismos y cuantificando los recursos y plazos precisos para planificar cada

alternativa.

TAREA EVS 5.1: ESTUDIO DE LA INVERSIÓN

Para cada alternativa de solución propuesta, se valora el impacto en laorganización y se establece su viabilidad económica. Para ello, se realiza un análisis coste/beneficio que determina los costes del sistema y los pondera con los beneficios tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo de cuantificarlos. Productos * De entrada

• Alternativas de Solución a Estudiar (EVS 4.2) * De salidaValoración de Alternativas:* Impacto en la Organización de Alternativas * Coste / beneficio de Alternativas Técnicas • Análisis Coste / Beneficio Participantes • Jefe de Proyecto• Analistas

TAREA EVS 5.2: ESTUDIO DE LOS RIESGOS

Para cadaalternativa se seleccionan los factores de situación que habráque considerar, relativos tanto a la incertidumbre como a la complejidad del sistema. Se identifican y valoran los riesgos asociadosy se determinan las medidas a tomar para minimizarlos.


• Alternativas de Solución a Estudiar (EVS 4.2)• Valoración de Alternativas (EVS 5.1) * De salida • Valoración de Alternativas: Valoración de Riesgos Prácticas

• Impacto en la Organización Participantes • Jefe de Proyecto• Analistas

TAREA EVS 5.3: PLANIFICACIÓN DE ALTERNATIVAS

En función del análisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes:- Se determina el enfoque más adecuado para llevar a buen fin la solución propuesta en cada alternativa.- Se realiza una planificación, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrollo o que esté previsto desarrollar, según se ha recogido en el catálogo de requisitos.De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida. Productos * De entrada• Catálogo de Requisitos (EVS 4.2) • Alternativas de Solución a Estudiar (EVS 4.2)• Valoración de Alternativas (EVS 5.2) * De salida • Plan de Trabajo de Cada Alternativa: Enfoque del Plan de Trabajo de Cada Alternativa Planificación de Cada Alternativa Técnicas • Planificación Participantes • Jefe de Proyecto• Analistas

ACTIVIDAD EVS 6: SELECCIÓN DE LA SOLUCIÓN

Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comité de Dirección para lapresentación de las distintas alternativas de solución, resultantes de la actividad anterior. En dicha presentación, se debaten las ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el finde seleccionar la más adecuada. Finalmente, se aprueba la solución o sedetermina su inviabilidad.

TAREA EVS 6.1: CONVOCATORIA DE LA PRESENTACIÓN

Se efectúa la convocatoria de la presentación de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comité de Dirección pueda estudiar previamente su contenido. Se espera confirmación por parte del Comité de Dirección de las alternativas a presentar.

Productos * De entrada• Catálogo de Usuarios (EVS 2.2/1.3)• Alternativas de Solución a Estudiar (EVS 4.2)• Valoración de Alternativas (EVS 5.2)• Plan de Trabajo de Cada Alternativa (EVS 5.3) * De salida• Plan de Presentación de Alternativas Prácticas • Presentación Participantes • Jefe de Proyecto

TAREA EVS 6.2: EVALUACIÓN DE LAS ALTERNATIVAS Y SELECCIÓN Una vez recibida la confirmación de qué alternativas van a ser presentadas para su valoración, se efectúa su presentación al Comité deDirección, debatiendo sobre las ventajas e inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comité, hasta la selección de la solución final.


• Descripción General del Sistema (Contexto del Sistema) (EVS 1.2)• Catálogo de Requisitos (EVS 4.2)• Alternativas de Solución a Estudiar (EVS 4.2)• Valoración de Alternativas (EVS 5.2)• Plan deTrabajo de Cada Alternativa (EVS 5.3)• Plan de Presentación de Alternativas (EVS 6.1)

* De salida

• Plan de Presentación de Alternativas• Catálogo de Requisitos (Actualizado en Función de la Cobertura de la Solución)• Solución Propuesta: Descripción de la Solución • Modelo de Descomposición en Subsistemas• Matriz Procesos / Localización Geográfica• Matriz Datos / Localización Geográfica • Entorno Tecnológico y Comunicaciones• Estrategia de Implantación Global del Sistema• Descripción de Procesos Manuales Si la alternativa incluye desarrollo:• Modelo Abstracto de Datos / Modelo de Procesos • Modelo de Negocio / Modelo de Dominio Si la alternativa incluye un producto software estándar de mercado:• Descripción del Producto• Evolución del Producto• Costes Ocasionados por Producto• Estándares del Producto• Descripción de Adaptación (si es necesaria) * Contexto del Sistema (con la Definición de las Interfaces en Función de la Solución) * Impacto en la Organización de la Solución * Coste / Beneficio de la Solución * Valoración de Riesgos de la Solución * Enfoque del Plan de Trabajo de la Solución * Planificación de la Solución Prácticas • Presentación• Sesiones de Trabajo Participantes • Comité de Dirección• Jefe de Proyecto• Analistas

TAREA EVS 6.3: APROBACIÓN DE LA SOLUCIÓN

El Comité de Dirección da su aprobación formal o determina la inviabilidad del sistema, por motivos económicos, de funcionalidad comoresultado del incumplimiento de los requisitos identificados en plazos

razonables o de cobertura de los mismos, etc.Productos De entrada

• Catálogo de Requisitos (EVS 6.2) • Solución Propuesta (EVS 6.2) De salida

• Aprobación de la Solución Participantes • Comité de Dirección• Jefe de Proyecto

Actividades EVS 1 Establecimiento del alcance del sistemaEVS 2 Estudio de la situación actualEVS 3 Definición de requisitos del sistemaEVS 4 Estudio de alternativas de soluciónEVS 5 Valoración de las alternativasEVS 6 Selección de la solución

ACTIVIDADESEVS 1 Establecimiento del alcance del sistemaEVS 2 Estudio de la situación actualEVS 3 Definición de requisitos del sistemaEVS 4 Estudio de alternativas de soluciónEVS 5 Valoración de las alternativasEVS 6 Selección de la solución

2.4 PLANIFICACIÓN DE LA DOCUMENTACIÓN

Administrar la documentación de un proyecto de software requiere un grado significativo de habilidad organizacional, debido a que el documento se establece como una gran entidad con vida, que sufre modificaciones continuas y relacionadas, hechas por varias personas. Escribir una buena documentación flexible es similar en muchas formas aescribir un buen código flexible.La administración de la documentación requiere que un documento esté completo, sea consistente y tenga configuración. La integridad es el conjunto de documentos que cubre el proceso de desarrollo y mantenimiento del software. La consistencia significa que el conjunto

de documentos no se contradice. En los conjuntos grandes de documentos es difícil evitar afirmaciones ocasionales casi contradictorias. La configuración es la coordinación de las diferentes versiones y partes del documento y el código.Los documentos queapoyan un proyecto corresponden, en términos generales, al proceso en cascada. El plan de aseguramiento de la calidad del software identifica la documentación del proyecto, estándares, revisiones, auditorías y manejo del riesgo. El plan de administración de la configuración del software explica cómo deben guardarse los documentos y el código. El plan de administración del proyecto de software expresa la forma en el que el proyecto debe llevarse a cabo. La especificación de requerimientos de software describe los requerimientos para la aplicación. El documento de diseño de software puntualiza la arquitectura y los detalles de diseño para a aplicación. El documento de pruebas de software describe la manera en que se verifica la aplicación. ESTÁNDARES DE DOCUMENTACIÓNEn el pasado, el establecimiento de estándaresha magnificado los beneficios de los nuevos campos de la ingeniería. Los estándares hacen posible la interoperabilidad; en otras palabras, una idea o artefacto producido para una aplicación se puede llevar a otra. Los estándares mejoran la comunicación entre los ingenieros. Como señala un caso, el establecimiento de estándares eléctricos llevó a grandes avances en lasposibilidades de producir productos y servicios útiles. La mayor parte de las compañías grandes ha establecido estándares para el desarrollo del software. Algunos clientes, como el Ministerio de Defensa de los EUA, insisten en que sus contratistas usen sus estándares específicos. La mayoría de las compañías han descubierto que sólo publicar y difundir sus estándares no lleva a su aceptación. Es común encontrar gruesos volúmenes de manuales de estándares de las compañías llenos de polvo en las repisas de los ingenieros. El autor ha observado incluso tarjetas de referencias breves para los estándares de la compañía que de hecho no se usan, los que prueba que el tamaño no es un factor determinante. Forzar a los ingenieros a asistir a sesiones de capacitación de estándares tampoco hará que los cumplan. Para que sean efectivos los ingenieros deben percibir los estándares como ayuda y no como un conjunto de obstáculos. Además, las metas cuantificables que requieren enfoques disciplinados y documentados tienden a motivar a losequipos de trabajo. Se sugiere que los equipos de desarrollo decidan en forma colectiva qué

estándares de documentación se aplicarán. En la opinión del autor, estamanera de decidir es preferible porque el equipo estará motivado aseguir su propia decisión. Otra ventaja es que la compañía, de hecho, intenta varios enfoques, proceso que quizá produzca mejores decisiones a largo plazo. La desventaja de permitir a los equipos elegir sus propios estándares es que los grupos dentro de la misma compañía a menudo seleccionan diferentes estándares. Esto disminuye la posibilidadde comparar los proyectos y requiere que los ingenieros que cambien de proyecto aprendan un nuevo marco de trabajo para el documento.Como mínimo, las organizaciones deben desarrollar estándares mínimos y claros. Deben permitir cierta flexibilidad y autonomía, pero también debe esperara retroalimentación para el mejoramiento del proceso de unamanera estandarizada. Por ejemplo, una organización debe esperar datos concernientes al tiempo dedicado a una aplicación y a las líneas de código medidas de cierta manera. Estas mediciones hacen posible usar los datos en toda la organización. El proceso de mejoramiento involucrauna meta proceso evolutivo (un proceso que se refiere a los procesos) dentro de la organización. Un ejemplo es el modelo de madurez de capacidades (CMM, Capability Maturity Model), que clasifica las organizaciones de desarrollo de software en cinco categorías de capacidad creciente. Las siguientes organizaciones publican datos normas importantes. En todos los casos, los estándares se han modificado un poco para actualizarlos, ya que las deliberaciones requeridas para crearlos son mucho más lentas que la generación de nuevas técnicas y tecnologías en el mercado. * El Internacional Institute of Electronic and Electrical Engineers (IEEE, www.ieee.org) ha estadomuy active en el establecimiento de estándares de documentación durante muchos años. La mayor parte de los estándares fueron desarrollados por comités distinguidos de ingenieros experimentados en la industria. Varios estándares de IEEE son ahora estándares ANSI (American National Standards Institute).* La International Standars Organization (ISO) ha tenido un impacto mundial significativo, en especial en la manufactura y en particular entre las organizaciones que hacen negocios con el Mercado Común Europeo (MCE). El MCE exige el cumplimiento de los estándares ISO a lascompañías que hacen negocios con los países miembros; esto ha sido un incentivo poderoso para su adopción mundial. * El Software Engineering Institute (SEI) fue establecido por el Ministerio de Defensa de los Estados Unidos en Carnegie Mellon

University para ayudar a actualizar el nivel de ingeniería de software de los contratistas miliares. El trabajo del SEI también se ha adoptadoen numerosas compañías comerciales, que han identificado el mejoramiento del proceso de software como una meta corporativa estratégica. El CMM es un estándar de capacidad del SEI.* El Object Management Group (OMG, www.omg.org) es una organización no lucrativa con alrededor de 700 compañías afiliadas. El OMG establece estándares para computación orientada a objetos. En particular, la OMG ha respaldado el lenguaje de modelado unificado (UML, Unified Modeling Languaje) como un estándar para describir diseños. Los documentos que apoyan un proyecto varían de una organización a otra, pero en general corresponden al proceso en cascada; ISO 12207 es un ejemplo deeste tipo de documentos.Aunque los estándares del IEEE requieren cierta modernización, ayudan al ingeniero a recordar la mayoría de los aspectos que deben incluirse y le permiten concentrarse en la aplicación. Cuando los estándares de documentación no se usan, los ingenieros tienen que dedicar una cantidad considerable de tiempo a organizar los documentos, y esto equivale a reinventar la rueda. La figura muestra un conjunto de documentación típico que usa la terminología del IEEE. El hecho de que este tipo de documentación vaya en paralelo con el proceso de cascada no implica que deba usarse el modelo en cascada, pero si no se usa, losdocumentos deben revisarse y revisarse cada vez que se apliquen las etapas individuales. Esto significa que los documentos deben estar muy bien organizados. Se parece mucho a la organización de una biblioteca en el sentido que es sencillo agregar o eliminar libros cuando está bien organizada. A continuación se da una descripción de cada documentoen el conjunto del IEEE. Otros cuerpos de estándares organizan sus documentos de modo similar.* PVVS. Plan de validación y verificación del software. Este plan explica la forma en que deben verificarse los pasos de un proyecto y unproducto con sus requerimientos. Verificación es el proceso de comprobar que una aplicación este construida de la manera correcta; la validación examina que se haya construido el producto correcto. A menudo una organización externa realiza algunas o todas estas funciones(en cuyo caso se llama V&V independiente o V&VI).

* PAQS. Plan de aseguramiento de la calidad del software. Este plan especifica lamanera en que el proyecto logra sus metas de calidad. * PACS. Plan de la administración de la configuración del software. El

PACS explica dónde se almacenan los documentos y el código en sus diferentes versiones, además como se acomodan juntos. No se recomienda empezar sin este plan porque el primer documento que se genera está destinado a cambiar y debemos entender cómo manejar este cambio antes de comenzar a escribir el documento. Las compañías de medianas a grandes casi siempre intentan resolver los detalles de la administración de la configuración para todos sus proyectos, y los ingenieros sólo deben aprender a seguir los procedimientos señalados enel PACS oficial y usar las herramientas proporcionadas. * PAPS. Plan de administración del proyecto de software. Este plan explica cómo debe llevarse a cabo el proyecto. Por lo común cita un proceso desarrollo conocido, como el proceso estándar de la compañía. * ERS. Especificación de requerimientos del software. Este documento establece los requerimientos para la aplicación y es una especie de contrato y guía para el cliente y los desarrolladores. * DDS. Documentación del diseño de software. El DDS describe los detalles de la arquitectura y el diseño de la aplicación. En general seusan diagramas como modelos de objetos y diagramas de flujos de datos. * DPS. Documentación de las pruebas de software. Describe la manera en que deben probarse la aplicación y sus partes. En ocasiones, los proyectos empleas documentos adicionales a los descritos. La documentación para el desarrollo iterativo puede organizarse al menos de dosmaneras. Algunos documentos (como el DDS) pueden contener una versión para cada iteración. Otra manera es agregarapéndices que expliquen el avance de la aplicación. Una manera de… identificar las necesidades de la documentación * Especificar la manera en que debe tenerse acceso a los documentos y al código.* De otra manera el resultado es el caos* “Plan de administración de la configuración”* Especificar quién hará y cuando lo hará.* “Plan de administración del proyecto de software” * Documentar que debe implementarse.* Para el uso propio, para el cliente y para el equipo* “Especificación de requerimientos de software”* Documentar el diseño de de la aplicación.* Por ejemplo, antes de programar* “Documentación de diseño del software”* Escribir y documentar el código.* “código base”

* Documentar las pruebas que se realicen.* De manera que puedan repetirse, extenderse, etcétera* “Documentación de pruebas de software”El lenguaje de modelado unificado (UML) fue desarrollado como una manera de estandarizar la descripción de los diseños de software, en particular los diseños orientados a objetos. El Object Management Groupha aceptado el UML como un estándar. La figura resume las necesidades de la documentación clave que tiene cada proyecto, sin importar si usa los estándares de la documentación reconocidos, como los del IEEE.

CONSISTENCIA DE LA DOCUMENTACIÓNUna clave para la consistencia es especificar cada entidad en un solo lugar. Esto se llamará documentación con una sola fuente. Por ejemplo, unrequerimiento de una aplicación científica puede ser: “cuenta de bacterias, un entero entre 1 y 100000000, debe estar accesible en todo momento”. Este requerimiento se documentaría en la especificación de requerimientos de software (ERS). Es tentador repetir este requerimiento en otros lugares –por ejemplo, en el código fuente, ya sea en el encabezado de la función o como línea de comentario-. Otro lugar donde puede colocarse un requerimiento es en el manual del usuario. El valor de las repeticiones debe evaluarse con cuidado contralas dificultades inherentes que puede causar. La razón para evitar las repeticiones es el cambio inevitable que tiene lugar en la vida de un proyecto. Cuando el mismo hecho se establece en varios lugares, cada una de las repeticiones debe cambiar de manera simultánea, siempre que cambien los hechos. Esto es prácticamente imposible durante la época detensión de la realización de un proyecto. Las repeticiones llevan a inconsistencias y éstas conducen al fracaso. Si existe la necesidad de hacer referencia a las mismas ideas en varias partes de un documento, una manera de hacerlo sin violar “documentación con una sola fuente” eshacer hipervínculos (hyperlink) a una sola fuente.La figura propone una versión con hipervínculos del conjunto de documentos, donde algunas partes del documento se refieren a otras. Porejemplo, como cada requerimiento lleva a un código fuente específico, el código fuente puede tener un hipervínculo a l requerimiento correspondiente del ERS. La tecnología de los hipervínculos permite rastrear cada requerimiento hasta su prueba e implementación sin que serepita. Desde el año2000, varios vendedores de herramientas de softwarehan comenzado a explotar las ventajas de los hipervínculos. Las componentes dinámicas que brinda la figura son las partes de los

documentos que deben actualizarse y/o proporcionarse mientras el documento avanza. Dicho de otra manera, la mayoría de los documentos son entidades con vida que requieren “cuidado y alimentación” continuos. Un ejemplo es el PACS, que especifica las versiones actualesdel documento. El ERS se revisa con frecuencias para hacer adiciones o modificaciones durante el desarrollo iterativo.

Algunas veces simplemente debe repetirse el requerimiento de manera diferente. Los manuales del usuario, por ejemplo, suelen tener que escribirse de forma distinta de la usada en la documentación del desarrollador, por lo tanto, es necesario repetir los requerimientos deuna nueva manera. Además, en ocasiones la documentación debe expresarsecon un nivel de detalle mayor; por ejemplo, en una etapa quizá sea necesario proporcionar una visión general y en otra los detalles. Es fácil que estos detalles sean inconsistentes. Los hipervínculos son unapromesa para mitigar los problemas de consistencia resultantes al conservar las referencias cruzadas. Por ejemplo, una sección de resumenpodría contener los hipervínculos a las secciones de detalle correspondientes; o un requerimiento en el ERS podría tener un hipervínculo a la sección correspondiente en el manual del usuario. Esto no evita cubrir el material dos veces, pero si puede facilitar la consistencia al tener las dos versiones “virtualmente” una al lado de la otra. Las organizaciones, en especial laspequeñas, suelen encontrar dificultad para mantener una documentación sincronizada. Por ejemplo, después de completar el bosquejo inicial de requerimientos, a menudo los ingenieros agregan capacidades al diseño y a la implementación, pordesgracia sin actualizar los requerimientos correspondientes. Los documentos no consistentes pierden credibilidad: es menos probable que los ingenieros los actualicen y la inversión en su creación pueda vaporarse con facilidad.

DOCUMENTACIÓN DE REQUERIMIENTOSEl documento de requerimientos del software (algunas veces denominado especificación de requerimientos del software o SRS) es la declaración oficial de que deben implementar los desarrolladores del sistema. Debe incluir tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se pueden integrar en una única descripción. En otro, los requerimientos del usuario se definen en una

introducción a la especificación de los requerimientos del sistema. Si existe un gran número de requerimientos, los detalles de los requerimientos del sistema se pueden presentar en un documento por separado.El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organización que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software. La figura 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 comunicación de los requerimientosa los clientes, la definición de los requerimientos en detalle exacto para los desarrolladores y probadores,y la inclusión de información sobre la posible evolución del sistema. La información sobre cambios previstos puede ayudar a los diseñadores del sistema evitar decisiones de diseño restrictivo y a los ingenieros encargados del mantenimiento del sistema, quienes tienen que adaptar elsistema a los nuevos requerimientos.El nivel de detalle que se debe incluir en un documento de requerimientos depende del tipo de sistema que se desarrolle y del proceso de desarrollo utilizado. Cuando el sistema se desarrolle por uncontratista externo, las especificaciones de los sistemas críticos necesitan ser claras y muy detalladas. Cuando haya más 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 ambigüedad resuelta durante el desarrollo del sistema.Varias organizaciones grandes, como el Departamento de Defensa de los Estados Unidos y el IEEE, han definido estándares para los documentos de requerimientos. El estándar más ampliamente conocido es el IEEE/ANSI830-1998. Este estándar IEEE sugiere la siguiente estructura para los documentos de requerimientos:

Aunque el estándar IEEE no es el ideal, contiene muchos consejos sobre cómo redactar los requerimientos y cómo evitar problemas. Es muy general para que pueda ser un estándar de una organización. Es un marcogeneral que se puede transformar y adaptar para definir un estándar ajustado a las necesidades de una organización en particular.La figura ilustra una posible organización para un documento de requerimientos se

basa en el estándar IEEE. Sin embargo, se ha ampliado para incluir la información sobre la evolución predicha del sistema. Esto, como se ha indicado, ayuda a las personas encargadas del mantenimiento del sistemay puede permitir a los diseñadores incluir soporte para futuras características del sistema. Por supuesto, la información que se incluya en un documento de requerimientos debe depender del tipo de software a desarrollar y del enfoque de desarrollo que se utilice. Si se adopta un enfoque evolutivopara un producto de software (por ejemplo), el documento de requerimientos dejará fuera muchos de los capítulos detallados sugeridos anteriormente. El interés estará en definir los requerimientos del usuario y los requerimientos del sistema no funcionales de alto nivel. En este caso, los diseñadores y programadores utilizan su juicio para decidir cómo satisfacer el esquema de los requerimientos del usuario para el sistema. Por el contrario, cuando el software es parte de un proyecto de ingeniería de sistemas grande que incluye la interacción de los sistemas hardware y software, a menudo es fundamental definir con muchodetalle los requerimientos. Esto significa que el documento de requerimientos probablemente sea muy extenso y deba incluir la mayoría si no la totalidad de los capítulos que se muestra en la figura. Para documentos extensos, es de particular importancia incluir una tabla de contenido comprensible y un índice del documento para que así los lectores puedan encontrar la información que necesiten.El documento derequerimientos es fundamental cuando un contratista exterior está desarrollando el sistema de software. Sin embargo, los métodos de desarrollo ágiles sostienen que los requerimientos cambian tan rápidamente que un documento de requerimientos se queda desfasado en cuanto se redacta, por lo que el esfuerzo en gran parte se malgasta.Más que un documento formal, enfoques como la programación extrema proponen que los requerimientos del usuario deberían ser recogidos incrementalmente y escritos en tarjetas. El usuario entonces da prioridad a los requerimientos que se han de implementar en el siguiente incremento del sistema.Para sistemas de negocio donde los requerimientos son inestables, este enfoque es bueno. Sin embargo, argumentaría que todavía es útil redactar un breve documento de soporte que defina el negocio y los requerimientos de confiabilidad del sistema. Es fácil olvidarse de los requerimientos que se aplican al sistema en sus totalidad al centrase en los requerimientos funcionales para la siguiente entrega del

sistema.DOCUMENTACIÓN DEL DISEÑOLa Especificación del diseño aborda diferentes aspectos del modelo de diseño y se completa a medida que el diseñador refina su propia representación del software. En primer lugar, se describe el ámbito global del esfuerzo realizado en el diseño. La mayor parte de la información que se presenta aquí se deriva de la Especificación del sistema y del modelo de análisis (Especificación de los requisitos del software). A continuación, se especifica el diseño de datos. Se definen también las estructuras de las bases de datos, cualquier estructura externa de archivos,estructuras internas de datos y una referencia cruzada que conecta objetos de datos con archivos específicos. El diseño arquitectónico indica cómo se ha derivado la arquitectura delprograma del modelo de análisis. Además, para representar la jerarquía del módulo se utilizan gráficos de estructuras. Se representa el diseño de interfaces internas y externas de programas y se describe un diseño detallado de la interfaz hombre-máquina. En algunos casos, se podrá representar un prototipo detallado del IGU. Los componentes -elementos de software que se pueden tratar por separado tales como subrutinas, funciones o procedimientos- se describen inicialmente con una narrativa de procesamiento en cualquier idioma (castellano, inglés). La narrativa de procesamiento explica la función procedimental de un componente (módulo). Posteriormente, se utiliza una herramienta de diseño procedimental para convertir esa estructura en una descripción estructural. La Especificación del diseño contiene una referencia cruzada de requisitos. El propósito de esta referencia cruzada (normalmente representada como una matriz simple) es: * Establecer que todos los requisitos se satisfagan mediante el diseño del software, y * Indicar cuáles son los componentes críticos para la implementación derequisitos específicos. El primer paso en el desarrollo de la documentación de pruebas también se encuentra dentro del documento del diseño. Una vez que se han establecido las interfaces y la estructura de programa podremos desarrollar las líneas generales para comprobar los módulos individuales y la integración de todo el paquete. Enalgunos casos, estasección se podrá borrar de la Especificación del diseño. Las restricciones de diseño, tales como limitaciones físicas de memoria

o la necesidad de una interfaz externa especializada, podrán dictar requisitos especiales para ensamblar o empaquetar el software. Consideraciones especiales originadas por la necesidad de superposiciónde programas, gestión de memoria virtual, procesamiento de alta velocidad u otros factores podrán originar modificaciones en diseño derivadas del flujo o estructura de la información. Además, esta sección describe el enfoque que se utilizará para transferir software al cliente. La última sección de la Especificación del diseño contiene datos complementarios. También se presentan descripciones de algoritmos, procedimientos alternativos, datos tabulares, extractos de otros documentos y otro tipo de información relevante, todos mediante notas especiales o apéndices separados. Será aconsejable desarrollar un Manual preliminar de Operaciones/instalación e incluirlo como apéndice para la documentación del diseño.DOCUMENTACIÓN DE LA IMPLEMENTACIÓNMuchos estándares y procedimientos corporativos u organizacionales se concentran en las descripciones que acompañan un conjunto de programas.Se considera como documentación del programa al conjunto de descripciones escritas que explican al lector qué hace el programa y cómo lo hace. La documentación interna es el material descriptivo, escrito directamente dentro de código, y cualquier otra documentación es documentación externa.DOCUMENTACIÓN INTERNALa documentación interna contiene información dirigida a quienes leeránelcódigo fuente del programa. Se incluye información sumaria para identificar al programa y describir algoritmos, estructuras de datos y flujos de control. Usualmente esta información se ubica al comienzo de cada componente en un conjunto de comentarios que se denomina bloque deencabezamiento.Encabezamiento. Así como un buen periodista incluye el por qué, el cuándo, el dónde, y los quienes de la historia, es necesario incluir alcomienzo de los programas un encabezamiento que contenga la siguiente información acerca de cada componente:1. Qué denominación tiene el componente2. Quién ha escrito el componente3. Dónde va ubicado el componente en el diseño general del sistema4. Cuándo fue escrito, revisado o modificado5. Por qué existe el componente6. Cómo utiliza sus estructuras de datos, algoritmos y control

Se puede examinar en mayor profundidad cada una de estas piezas de información.En primer lugar, el nombre del componente debe aparecer en un sitio destacado de la documentación. Luego se identificará al autor incluyendo su número de teléfono o dirección de correo electrónico, de modo que los equipos de prueba y mantenimiento pueden contactarlo y formular preguntas o comentarios.Durante el ciclo de vida del sistema, los componentes se actualizan y revisan, ya sea para subsanar alguna falla o debido a cambios o ampliaciones de los requerimientos. Es muy importante hacer el seguimiento de cada revisión, de modo que la documentación del programamantenga un registro de los cambios realizados y de quienes los han efectuado.Debido a que un componente es una parte de un sistema mayor,este bloquedebe indicar cómo encaja en la jerarquía de componentes. Esta información se suele comunicar mediante algún diagrama; otras veces, sedará una descripción simple al respecto. En el encabezamiento también puede explicarse la forma en que es invocado el componente.Para explicar la forma en que el componente alcanza su meta, se requiere información más detallada. El bloque deberá* indicar el nombre, tipo y propósito de cada una de las principales estructura de datos y variables * contener breves descripciones del flujo lógico, algoritmos y tratamiento del error* listar la entrada esperada y la posible salida* presentar las ayudas para la prueba y cómo usarlas* enunciar las extensiones o revisiones esperadasUsual mente, los estándares organizacionales especifican el orden y contenido de estos bloques de comentarios. Otros comentarios del programa. El encabezamiento actúa como una introducción al programa, tanto como la introducción de un libro explica el contenido. Os comentarios adicionales iluminan a los lectores a medida que se desplazan a lo largo del programa, ayudándolesa comprender cómo las intenciones enunciadas en el encabezamiento estánimplementadas en el código. Si la organización del código refleja un diseño bien estructurado, si las sentencias tienen un formato claro y si las etiquetas, nombres de variables y nombres de datos son descriptivos y fáciles de distinguir, entonces el número de comentariosadicionales será reducido. Es decir, al seguir directivas simples para la estructura y formato del código, se logra que el código sea una

fuente de información acercade sí mismo.Hay lugar para comentarios aun cuando el código está bien escrito y claramente estructurado. A pesar que la claridad y la estructura minimizan la necesidad de otros comentarios, éstos resultan particularmente útiles toda vez que debe agregarse información de ayudaa un componente. En lugar de escribir una explicación línea por línea sobre lo que hace el programa, los comentarios permiten fragmentar el código en fases que representan las actividades principales. Lugo, cadaactividad podrá ser dividida en pasos todavía más pequeños, de modo quecada uno esté formado por unas pocas líneas de código. El pseudocódigo obtenido al diseñar el programa puede servir para este propósito y embeberse en el código mismo. Además, cuando se revisa el código, los programadores deben actualizar los comentarios para reflejar los cambios introducidos. De esta forma, los comentarios constituyen un registro de las revisiones a lo largo del tiempo.Resulta esencial que los comentarios reflejen el comportamiento real del código. Además es conveniente comprobar que los comentarios agregannueva información, en lugar de enunciar lo que ya resulto obvio al usarlas etiquetas y nombres de variables apropiados. Usualmente se comienza a codificar pasando del diseño al pseudocódigo, lo que proporciona a su vez una estructura de soporte para el código final, y una base para los correspondientes comentarios. Los comentarios deben escribirse simultáneamente con el código, porque así se capturan tanto el diseño como la intención presente en el momento dela codificación. Se debe estar atento ante un código difícil de documentar; ladificultad a menudo indica que el diseño debe simplificarse antes de seguir adelante con la codificación. Nombres de variables y etiquetas con significado. Seleccionar nombres de variables y enunciados que reflejen su utilización o significado. Por ejemplo, si se escribe: Weekage = (hrrate * hours) + (.5) *(hrrate) * (hours – 40.);Tendrá mayor significado para el lector queZ = (a * b) + (.5) * (a) + (b – 40.);De hecho, el caso del ejemplo probablemente no precise mayores comentarios, con lo cual la posibilidad de introducir defectos es reducida. De forma similar, las etiquetas alfabéticas deben transmitir al lector alguna idea acerca de lo que realiza la sección etiquetada del programa. Si se utilizan etiquetas numéricas, es necesario comprobar que respetan un orden ascendente y que forman grupos de afinidad

conforma a su propósito.Dar formato para mejorar la comprensión. El formato de los comentarios puede ayudar al lector a comprender la meta del código y cómo se alcanza dicha meta. Mediante espaciado se puede reflejar la estructura básica de control. Nótese como un código no indentado, como el siguiente:If (xcoord < ycoord)Result = -1;Else if (xcoord == ycord)If (slope1 > slope2)Result = 0;Else result = 1;Else if (slope1 > slope2)Result = 2;Else if (slope1 < slope2)Result = 3;Result = 4;

Además del uso de formato para representar la estructura de control, serecomienda un formato para las sentencias donde los comentarios aparezcan en uno de los lados de la página y las sentencias en el otro.De esta forma se tiene una cobertura a medida que se chequea el código yno hay posibilidad de confusión a causa del uso de la documentación incorrecta. Documentación de los datos. Uno de los aspectos que presentan más dificultades para los lectores de programas es la comprensión de la forma en que se estructuran y utilizan los datos. Un mapa de datos es muy útil para la interpretación de las acciones del código, especialmente cuando el sistema maneja varios archivos de distinto tipoy propósito, acoplados por medio de señales de control (flags) y pasajede parámetros. Este mapa debe corresponderse con el diccionario de datos de la documentación externa, de modo que el lector pueda seguir la pista de la manipulación de los datos a través de los requerimientosy el diseño hasta llegar al código.

Con el diseño orientado a objetos, se minimizan o eliminan algunos de estos problemas, pero muchas veces a causa de este ocultamiento de información es más difícil que le lector comprenda exactamente cómo ocurren los cambios de los valores de los datos. En consecuencia la documentación interna debe incluir las descripciones de las estructuras

de datos y su utilización.DOCUMENTACIÓN EXTERNAMientras que la documentación interna es concisa y está escrita en un nivel apropiado para un programador, la documentación externa se prepara para ser leída por quienes quizás nunca verán el código real. Por ejemplo, los diseñadores pueden revisar la documentación cuando consideren modificaciones o mejoras. Además, la documentación externa brinda una oportunidad de explicar cosas en forma más amplia que lo quees razonable hacer en los comentarios. Si se considera que el bloque delos comentarios delencabezamiento es una vista global o resumen del programa, entonces, la documentación externa constituye un informe totalmente desarrollado. Responde a las mismas cuestiones –quién, qué, por qué, cuándo, dónde, y cómo- desde la perspectiva del sistema, en lugar de la perspectiva de un componente.

Dado que un sistema de software se construye a partir de componentes interrelacionados, la documentación externa a menudo incluye una vista general de los componentes del sistema o de varias agrupaciones de componentes (tales como los componentes de la interfaz de usuario, los de la administración de la base de datos o los que realizan los cálculos de velocidad). Los diagramas acompañados por una narrativa quedescribe cada componente muestran cómo se comparten los datos y se utilizan por uno o más componentes; en general, la vista global describe como la información pasa de un componente a otro. Las clases objeto y su jerarquía de herencia se detallan aquí, dado que constituyen una razón para definir entre tipos o categorías especiales de datos.La documentación externa de un componente es parte de la documentación total del sistema. Al momento de escribir el código de un componente, gran parte de la justificación de la estructura y flujo del mismo ya seencuentra detallada en los documentos de diseño. Es este sentido, el diseño es el esqueleto de la documentación externa, y el relleno lo proporciona la narrativa donde se discuten los aspectos particulares delos componentes del código.

Descripción del problema. En la primera sección de la documentación delcódigo se debe explicar el problema tratado por el componente. Estasección es el mejor escenario para la descripción de las opciones que se consideran como vías de solución y de por qué se seleccionó una en particular. La descripción del problema no es una repetición de la

documentación de requerimientos, sino que es una discusión general de la situación, explicando cuando se invoca el componente y por qué se lonecesita.

Descripción de los algoritmos. Una vez que se ha esclarecido el porqué de la existencia del componente, se debe respaldar la elección del algoritmo. Deben explicarse todos los algoritmos utilizados en el componente, incluyendo fórmula, condiciones especiales o de límite, e inclusive su derivación, o bien la referencia al libro o artículo del cual se ha extraído.

Si un algoritmo trata casos especiales, debe asegurarse que se discute cada uno de ellos y explicar cómo se maneja. Si determinado caso no se considera o trata debido a que no es probable que ocurra, hay que justificar apropiadamente eta decisión y describir el tratamiento del error relacionado por parte del código. Por ejemplo, un algoritmo puedeincluir una fórmula donde una variable divide a otra. La documentación debe considerar los casos en que el denominador pueda ser cero, puntualizando cuándo puede producirse esta situación y cómo debe ser manejada por el código.

Descripción de los datos. En la documentación externa, los usuarios y los programadores deben ser capaces de ver el flujo de datos a nivel decomponente. Los diagramas de flujo de datos deben ir acompañados por las referencias relevantes del diccionario de datos. Para componentes de procedencia orientada a objetos, la vista general deobjetos y clasesdebe explicar la interacción general entre los objetos.

DOCUMENTACIÓN DE LA ENTREGALos manuales del sistema proveen información más detallada de la ayuda en línea y se diseñan de tal forma que puedan ser utilizados por diferentes clases de usuarios del sistema.

Para satisfacer a estas clases de usuarios diferentes y a los diferentes niveles de experiencia de los usuarios, existen al menos cinco documentos (o tal vez capítulos de un mismo documento) que se entregan con un sistema de software.

Estos documentos son:

1. Una descripción funcional que describe, muy brevemente, los servicios que provee el sistema. A los usuarios les debe ser posible leer este documento junto con un manual introductorio y decidir si es el sistema que necesitan.2. Un documento de instalación que provee los detalles de cómo instalarel sistema. Describe los discos que se entregan con el sistema, los archivos de estos discos y la configuración mínima de hardware requerida. Incluye las instrucciones de instalación y los detalles de cómo instalar los archivos dependientes de la configuración.3. Un manual introductorio que presenta una introducción informal del sistema, describiendo su utilización “normal”. Describe cómo iniciar y cómo los usuarios finales podrían utilizar los recursos comunes del sistema. Se ilustra con muchos ejemplos. Incluye información de cómo recuperarse de los errores y restablecer el funcionamiento. Se sugiere que centrarse en la recuperación de errores y minimizar la información que tienen que leer los usuarios eliminando redundancias es una forma efectiva de organizar los manualesintroductorios. 4. Un manual de referencia describe los recursos del sistema y su utilización, provee una lista de mensajes de error, las posibles causasy describe cómo recuperarse de los errores detectados.5. Un manual de administrador se provee en algunos tipos de sistemas. Éste describe los mensajes generados cuando el sistema interactúa con otros sistemas y cómo reaccionar a éstos mensajes. Si el sistema de hardware participa, explica cómo reconocer y reparar los problemas relacionados con el hardware, cómo conectar los nuevos periféricos, etcétera.

2.5 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

Cuando se construye software de computadora, los cambios son inevitables. Además, los cambios aumentan el grado de confusión entre los ingenieros del software que están trabajando en el proyecto. La confusión surge cuando no se han analizado los cambios antes de realizarlos, no se han registrado antes de implementarlos, no se les han comunicado a aquellas personas que necesitan saberlo o no se han controlado de manera que mejoren la calidad y reduzcan los errores. El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de

programación. La meta es maximizar la productividad minimizando los errores. La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCSsirven para:1. Identificar el cambio,2. controlar el cambio, 3. garantizar que el cambio se implementa adecuadamente y 4. informar del cambio a todos aquellos que puedan estar interesados. Es importante distinguir claramente entre el mantenimiento del softwarey la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjuntode actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías:

1. programas de computadora (tanto en forma de código fuente como ejecutable),2. documentos que describen los programas de computadora (tanto técnicos como de usuario) y 3. datos (contenidos en el programa o externos a él).

Los elementos que componen toda la información producida como parte delproceso de ingeniería del software se denominan colectivamente configuración del software.

A medida que progresa el proceso del software, el número de elementos de configuración del software (ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía deinformación. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por

cualquier razón. De hecho, la Primera Ley de la Ingeniería 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.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:

* nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales; * nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora; * reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software; * restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.

La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.

LÍNEAS BASEUna línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE (EstándarIEEE 610.12-1990) define una línea base como una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí enadelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios. Antes de que un elemento de configuración de software se convierta en una línea base, el cambio se puede llevar a cabo rápida e informalmente. Sin embargo, una vez que se establece una línea base, pasamos, de forma figurada, por una puerta de un solo sentido. Se pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.

En el contexto de la ingeniería del software, definimos una línea base como un punto de referencia en el desarrollo del software que queda marcado por el envío de uno o más elementos de configuración del software y la aprobación del ECS obtenido mediante una revisión técnicaformal. Por ejemplo, los elementos de una Especificación de Diseño se documentan y se revisan. Se encuentran errores y se corrigen. Cuando todas las partes de la especificación se han revisado, corregido y aprobado, la Especificación de Diseño se convierte en una línea base. Sólo se pueden realizar cambios futuros en la arquitectura del software(documentado en la Especificación de Diseño) tras haber sido evaluados y aprobados. Las líneas base se pueden definir con cualquier nivel de detalle.

Las tareas de la ingeniería del software producen uno o más ECSs. Una vez que un ECS se ha revisado y aprobado, se coloca en una base de datos del proyecto(también denominada biblioteca del proyecto o depósito de software). Cuando un miembro del equipo de ingeniería del software quiere hacer modificaciones en un ECS de línea base, se copia de la base de datos del proyecto a un área de trabajo privada del ingeniero. Sin embargo, este ECS extraído puede modificarse sólo si se siguen los controles GCS.

ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARELlevado al extremo, se puede considerar un ECS como una sección individual de una gran especificación o cada caso de prueba de un gran conjunto de pruebas. De forma más realista, un ECS es un documento, un conjunto completo de casos de prueba o un componente de un programa dado (por ejemplo, una función de C++ o un paquete de ADA).En realidad, los ECSs se organizan como objetos de configuración que han de ser catalogados en la base de datos del proyecto con un nombre único. Un objeto de configuración tiene un nombre y unos atributos y está «conectado» a otros objetos mediante relaciones. De acuerdo con lafigura, los objetos de configuración, Especificación de Diseño, modelo de datos, componente, código fuente y Especificación de Prueba, están definidos por separado. Sin embargo, cada objeto está relacionado con otros como muestran las flechas. Una flecha curvada representa una relación de composición. Es decir, modelo de datos y componente N son parte del objeto Especificación de Diseño. Una flecha recta con dos puntas representa una interrelación. Si se lleva a cabo un cambio sobre

el objeto código fuente, las interrelaciones permiten al ingeniero de software determinar qué otros objetos (y ECSs) puedenverse afectados.EL PROCESO DE LA GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARELa gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorías de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.Cualquier estudio de la GCS plantea una serie de preguntas complejas:* ¿Cómo identifica y gestiona una organización las diferentes versionesexistentes de un programa (y su documentación) de forma que se puedan introducir cambios eficientemente? * ¿Cómo controla la organización los cambios antes y después de que el software sea distribuido al cliente? * ¿Quién tiene la responsabilidad de aprobar y de asignar prioridades alos cambios? * ¿Cómo podemos garantizar que los cambios se han llevado a cabo adecuadamente? * ¿Qué mecanismo se usa para avisar a otros de los cambios realizados? Estas cuestiones nos llevan a la definición de cinco tareas de GCS: Identificación, control de versiones, control de cambios, auditorías deconfiguración y generación de informes.CONTROL DE VERSIONESEl control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creados duranteel proceso del software. Se describe el control de versiones en el contexto de la GCS:La gestión de configuración permite a unusuario especificar configuraciones alternativas del sistema de software mediante la selección de las versiones adecuadas. Esto se puede gestionar asociandoatributos a cada versión del software y permitiendo luego especificar -y construir- una configuración describiendo el conjunto de atributos deseado.Los «atributos» que se mencionan pueden ser tan sencillos como un número específico de versión asociado a cada objeto o tan complejos como una cadena de variables lógicas (indicadores) que especifiquen tipos de cambios funcionales aplicados al sistema.

Una representación de las diferentes versiones de un sistema es el grafo de evolución mostrado en la figura. Cada nodo del grafo es un objeto compuesto, es decir, una versión completa del software. Cada versión del software es una colección de ECSs (código fuente, documentos, datos) y cada versión puede estar compuesta de diferentes variantes. Ejemplo: Para ilustrar este concepto, consideremos una versión de un sencillo programa que está formado por los componentes 1,2, 3, 4 y 5. El componente 4 sólo se usa cuando el software se implementa para monitores de color. El componente 5 se implementa cuando se dispone de monitor monocromo. Por tanto, se pueden definir dos variantes de la versión: * componentes 1, 2, 3 y 4;* componentes 1, 2, 3 y 5.Para construir la variante adecuada de una determinada versión de un programa, a cada componente se le asigna una «tupla de atributos» -una lista de características que definen si se ha de utilizar el componentecuando se va a construir una determinada versión del software-. A cada variante se leasigna uno o más atributos. Por ejemplo, se podría usar un atributo color para definir qué componentes se deben incluir para soporte de monitores en color.Otra forma de establecer los conceptos de la relación entre componentes, variantes y versiones (revisiones) es representarlas como un fondo de objetos. De acuerdo con la figura siguiente, la relación entre los objetos de configuración y los componentes, las variantes y las versiones se pueden representar como un espacio tridimensional. Un componente consta de una colección de objetos del mismo nivel de revisión. Una variante es una colección diferente de objetos del mismo nivel de revisión y, por tanto, coexiste en paralelo con otras variantes. Una nueva versión se define cuando se realizan cambios significativos en uno o más objetos. En la pasada década se propusieron diferentes enfoques automatizados para el control de versiones. La principal diferencia entre los distintos enfoques está en la sofisticación de los atributos que se usan para construir versiones y variantes específicas de un sistema y en la mecánica del proceso de construcción.

CONTROL DE CAMBIOSLa realidad del control de cambio en un contexto moderno de ingeniería de software ha sido bien resumida por James Bach: El control de cambio es vital. Pero las fuerzas que lo hacen necesario también lo hacen

molesto. Nos preocupamos por el cambio porque una diminuta perturbaciónen el código puede crear un gran fallo en el producto. Pero también puede reparar un gran fallo o habilitar excelentes capacidades nuevas. Nos preocupamos por el cambio porque un desarrollador pícaro puede hacer fracasarel proyecto; sin embargo las brillantes ideas nacidas en la mente de estos pícaros, y un pesado proceso de control de cambio pueden disuadirle de hacer un trabajo creativo. Bach reconoce que nos enfrentamos a una situación a equilibrar. Mucho control de cambio y crearemos problemas. Poco, y crearemos otros problemas. En un gran proyecto de ingeniería de software, el cambio incontrolado lleva rápidamente al caos. Para estos proyectos, el control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control del cambio. El proceso de control de cambios está ilustrado esquemáticamente en la figura. Se hace una petición de cambio y se evalúa para calcular el esfuerzo técnico, los posibles efectos secundarios, el impacto global sobre otras funciones del sistema y sobre otros objetos de la configuración. Los resultados de la evaluación se presentan como un informe de cambiosa la autoridad de control de cambios (ACC) -una persona o grupo que toma la decisión final del estado y la prioridad del cambio-. Para cadacambio aprobado se genera una orden de cambio de ingeniería (OCI). La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoría. 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 (Garantía de laCalidad del Software). Luego, el objeto es «dado de alta» en la base dedatos y se usan los mecanismos de control de versiones apropiados para crear la siguiente versión del software.Losprocesos de «alta» y «baja» implementan dos elementos importantes del control de cambios -control de acceso y control de sincronización-.El control de acceso gobierna los derechos de los ingenieros de software a acceder y modificar objetos de configuración concretos. El control de sincronización asegura que los cambios en paralelo, realizados por personas diferentes, no se sobrescriben mutuamente.El flujo de control de acceso y de sincronización está esquemáticamenteilustrado en la figura siguiente. Ejemplo: De acuerdo con una petición de cambio aprobada y una OCI, un ingeniero de software da de baja a un objeto de configuración. Una función de control de acceso comprueba queel ingeniero tiene autoridad para dar de baja el objeto, y el control

de sincronización bloquea el objeto en la base de datos del proyecto, de forma que no se puedan hacer más actualizaciones hasta que se haya reemplazado con la nueva versión. Fíjese que se pueden dar de baja otras copias, pero no se podrán hacer otras actualizaciones. El ingeniero de software modifica una copia del objeto de línea base, denominada versión extraída. Tras la SQA y la prueba apropiada, se da de alta la versión modificada del objeto y se desbloquea el nuevo objeto de línea base.

Puede que algunos lectores empiecen a sentirse incómodos con el nivel de burocracia que implica el proceso anterior. Esta sensación es normal. Sin la protección adecuada, el control de cambios puede ralentizar el progreso y crear un papeleo innecesario. La mayoría de los desarrolladores de software que disponen de mecanismos de control de cambios (desgraciadamente la mayoría notienen ninguno) han creado varios niveles de control para evitar los problemas mencionados anteriormente.Antes de que un ECS se convierta en una línea base, sólo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECSen cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos (siempre que los cambios no impacten en otros requisitos del sistema más amplios que queden fuera del ámbito detrabajo del encargado del desarrollo). Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobado, se crea la línea base. Una vez que el ECS se convierte en una línea base, aparece el control de cambios a nivel de proyecto. Ahora, para hacer un cambio, el encargado del desarrollo debe recibir la aprobación del gestor del proyecto (si el cambio es «local») o de la ACC si el cambio impacta en otros ECSs. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las OCI. Sin embargo, hay que hacer una evaluación de cada cambio así como un seguimiento y revisión 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) desempeña un papel activo en el segundo y tercer nivel de control. Dependiendo del tamaño y de las características del proyecto de software, la ACC puede estar compuesta por una persona -el gestor del proyecto- o por varias personas (por ejemplo, representantes del software, del hardware, de la ingeniería delas bases de datos, del soporte o del departamento comercial,etc.). El

papel de la ACC es el de tener una visión general, o sea, evaluar el impacto del cambio fuera del ECS en cuestión. ¿Cómo impactará el cambioen el hardware? ¿Cómo impactará en el rendimiento? ¿Cómo alterará el cambio la percepción del cliente sobre el producto? ¿Cómo afectará el cambio a la calidad y a la fiabilidad? La ACC se plantea estas y otras muchas cuestiones.AUDITORÍA DE LA CONFIGURACIÓNLa identificación, el control de versiones y el control de cambios ayudan al equipo de desarrollo de software a mantener un orden que, de otro modo, llevaría a una situación caótica y sin salida. Sin embargo, incluso los mecanismos más correctos de control de cambios hacen un seguimiento al cambio sólo hasta que se ha generado la OCI. ¿Cómo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1. revisiones técnicas formales y 2. auditorías de con- figuración del software. Las revisiones técnicas formales se centran en la corrección técnica del elemento de configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la consistencia con otros ECSs, las omisiones o los posibles efectos secundarios. Se debe llevar a cabo unarevisión técnica formal para cualquier cambio que no sea trivial. Una auditoría de configuración del software complementa la revisión técnicaformal al comprobar características que generalmente no tiene en cuentala revisión. La auditoría se plantea y responde las siguientes preguntas:1. ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado modificaciones adicionales? 2. ¿Se ha llevado a cabo unarevisión técnica formal para evaluar la corrección técnica?3. ¿Se ha seguido el proceso del software y se han aplicado adecuadamente los estándares de ingeniería del software? 4. ¿Se han «resaltado» los cambios en el ECS? ¿Se han especificado la fecha del cambio y el autor? ¿Reflejan los cambios los atributos del objeto de Configuración?5. ¿Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo? 6. ¿Se han actualizado adecuadamente todos los ECSs relacionados?En algunos casos, las preguntas de auditoría se incluyen en la revisióntécnica formal. Sin embargo, cuando la GCS es una actividad formal, la auditoría de la GCS se lleva a cabo independientemente por el grupo de

garantía de calidad.INFORMES DE ESTADOLa generación de informes de estado de la configuración (a veces denominada contabilidad de estado) es una tarea de GCS que responde a las siguientes preguntas:1. ¿Qué pasó? 2. ¿Quién lo hizo? 3. ¿Cuándo pasó? 4. ¿Qué más se vio afectado?Cada vez que se asigna una nueva identificación a un ECS o una identificación actualizada se genera una entrada en el IEC (Informe de Estado de la Configuración). Cada vez que la ACC aprueba un cambio (o sea, se expide una OCI), se genera una entrada en el IEC. Cada vez que se lleva a cabo una auditoría de configuración, los resultados aparecencomo parte de una tarea de generación de un IEC. La salida del IEC se puede situar en una base de datos interactiva de forma que los encargados del desarrollo o del mantenimiento del software puedan acceder a la información de cambios por categorías clave. Además, segenera un IEC regularmente con intención de mantener a los gestores ya los profesionales al tanto de los cambios importantes.La generación de informes de estado de la configuración desempeña un papel vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fácil que se dé el síndrome de que «la mano izquierda ignora lo que hace la mano derecha». Puede que dos programadores intenten modificar el mismo ECS con intenciones diferentes y conflictivas. Un equipo de ingeniería del software puede emplear meses de esfuerzo en construir un software a partir de unas especificaciones de hardware obsoletas. Puede que la persona que descubra los efectos secundarios senos de un cambio propuesto no esté enterada de que el cambio se está realizando. El IEC ayuda a eliminar esos problemas, mejorando la comunicación entre todas las personas involucradas.

Bibliografía:Ingeniería de Software Un enfoque práctico Pressman, Roger S. Ed. McGraw-Hill. 5º edición. España, 2002.Ingeniería de Software. Somerville, Ian. Ed. Pearson Educación. 7º edición. Madrid, 2005.

UNIDAD III

ANÁLISIS DEL PROYECTO

4.1 ANÁLISIS DE RIESGOS

GESTIÓN DE RIESGOSUna tarea importante del gestor de proyectos es anticipar los riesgos que podrían afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar éstos y crear planes para minimizar susefectos en el proyecto se llama gestión de riesgos.

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 organización. Estas categorías de riesgos se definen como se muestra a continuación:

1. Riesgos del proyecto. Éstos afectan la calendarización o los recursos del proyecto. Un ejemplo podría ser la pérdida de un diseñadorexperimentado.

2. Riesgos del producto. Éstos afectan a la calidad o al rendimiento del software que se está desarrollando. Un ejemplo podría ser que el rendimiento en un componente que hemos comprado sea menor que el esperado.

3. Riesgos del negocio. Estos afectan a la organización que desarrolla o suministra el software.Por ejemplo, que un competidor introduzca un nuevo producto es un riesgo de negocio.

Por supuesto, estos tipos no son exclusivos entre sí. Si un programadorexperto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un sustituto puede no ser tan experto y cometer muchos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios futuros).

Los riesgos que pueden afectar a un proyecto dependen del propio proyecto y del entorno organización al donde se desarrolla. Sin embargo, muchos riesgos son universales. La gestión de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes con las que se enfrentan muchos proyectos. Estasincertidumbres son el resultado de losrequerimientos ambiguamente definidos, las dificultades en la estimación de tiempos y los recursos para el desarrollo del software, la dependencia en las habilidades individuales, y los cambios en los requerimientos debidos a los cambios en las necesidades del cliente. Espreciso anticiparse a los riesgos: comprender el impacto de éstos en elproyecto, en el producto y en el negocio, y considerar los pasos para evitarlos. En el caso de que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación.

La Figura 5.10 muestra el proceso de gestión de riesgos. Éste comprendevarias etapas:1. identificación de riesgos. Identificar los posibles riesgos para el proyecto, el producto y los negocios.2. Análisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.3. Planificación de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto. 4. Supervisión de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible.

El proceso de gestión de riesgos, como otros de planificación de proyectos, es un proceso iterativo que se aplica a lo largo de todo el proyecto. Una vez que se genera un conjunto de planes iníciales, se supervisa la situación. En cuanto surja más información acerca de los riesgos, éstos deben analizarse nuevamente y se deben establecer nuevasprioridades. La prevención de riesgos y los planes de contingencia se deben modificar tan pronto como surja nuevainformación de los riesgos.Los resultados del proceso de gestión de riesgos se deben documentar enun plan de gestión de riesgos. Éste debe incluir un estudio de los riesgos a los que se enfrenta el proyecto, un análisis de éstos y los planes requeridos para su gestión. Si es necesario, puede incluir algunos resultados de la gestión de riesgos; por ejemplo, planes específicos de contingencia que se activan si aparecen dichos riesgos.

IDENTIFICACIÓN DE RIESGOSÉsta es la primera etapa de la gestión de riesgos. Comprende el descubrimiento de los posibles riesgos del proyecto. En principio, no hay que valorarlos o darles prioridad en esta etapa aunque, en la práctica, por lo general no se consideran los riesgos conconsecuencias menores o con baja probabilidad.Esta identificación se puede llevar a cabo a través de un proceso de grupo utilizando un enfoque de tormenta de ideas o simplemente puede basarse en la experiencia. Esta identificación se puede llevar a cabo através de un proceso de grupo utilizando un enfoque de tormenta de ideas o simplemente puede basarse en la experiencia. Para ayudar al proceso se utiliza una lista de posibles tipos de riesgos. Hay al menosseis tipos de riesgos que pueden aparecer:1. Riesgos de tecnología. Se derivan de las tecnologías de software o de hardware utilizadas en el sistema que se está desarrollando.2. Riesgos de personal. Riesgos asociados con las personas del equipo de desarrollo.3. Riesgos organizacionales. Se derivan del entorno organizacional donde el software se está desarrollando.4. Riesgos de herramientas. Se derivan de herramientas CASE y de otro software de apoyoutilizado para desarrollar el sistema.5. Riesgos de requerimientos. Se derivan de los cambios de los requerimientos del cliente y el proceso de gestionar dicho cambio.6. Riesgos de estimación. Se derivan de los estimados administrativos de las características del sistema y los recursos requeridos para construir dicho sistema.

ANÁLISIS DE RIESGOSEs un paso importante para implementar la seguridad de la información. Como su propio nombre lo indica, es realizado para detectar los riesgosa los cuales están sometidos los activos de una organización, es decir,para saber cuál es la probabilidad de que las amenazas se concretenDurante 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 fácil de hacer esto —recae en la opinión y experiencia del gestor del proyecto—. No se hace una valoración con números 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 catastrófico, serio,tolerable o insignificante.El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada según la seriedad del riesgo. La Figura 5.12 ilustra esto para los riesgos identificados en la Figura 5.11. Obviamente, aquí es arbitraria la valoración de la probabilidad y seriedad.En la práctica, para hacer esta valoración se necesita información detallada del proyecto, el proceso, el equipo de desarrollo y la organización.

Por supuesto, tanto laprobabilidad como la valoración de los efectos deun riesgo cambian conforme se disponga de mayor información acerca del riesgo y los planes de gestión del mismo se implementen. Por lo tanto, esta tabla se debe actualizar durante cada iteración del proceso de riesgos.Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto. Este discernimiento debe depender de una combinación de la probabilidad de aparición del riesgo y de los efectosdel mismo.En general, siempre se deben tener en cuenta todos los riesgos catastróficos, así como todos los riesgos serios que tienen más que unamoderada probabilidad de ocurrir. Boehm (Boehm, 1988) recomienda identificar y supervisar los «10 riesgos más altos», pero este número parece demasiado arbitrario. El número exacto de riesgos a supervisar debe depender del proyecto. Pueden ser cinco o 15. No obstante, el número apropiado debe ser manejable.Un número muy grande de riesgos requiere obtener mucha información. De los riesgos identificados en la Figura siguiente, conviene considerar los ocho que tienen consecuencias serias o catastróficas.

PLANIFICACIÓN DE RIESGOSEl proceso de planificación de riesgos considera cada uno de los riesgos clave que han sido identificados, así como las estrategias paragestionarlos. Otra vez, no existe un proceso sencillo que nos permita establecer los planes de gestión de riesgos. Depende del juicio y de laexperiencia del gestor del proyecto.La Figura 5.13 muestra posibles estrategias para los riesgos que han sido identificados en la Figura 5.12.Estas estrategias seguidas pueden

dividirse en tres categorías.1. Estrategias de prevención. Siguiendo estas estrategias, la probabilidad de que el riesgo aparezca se reduce. 2. Estrategias de minimización. Siguiendo estas estrategias se reduciráel impacto del riesgo.3. Planes de contingencia. Seguir estas estrategias es estar preparado para lo peor y tener una estrategia para cada caso.

SUPERVISIÓN DE RIESGOSLa supervisión de riesgos normalmente valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y si han cambiado sus efectos.

4.2. CONTROL DE CALIDAD DEL SOFTWARE

¿QUÉ ES CALIDAD?El American Heritage Dictionary, define la calidad como «una característica o atributo de algo». Como un atributo de un elemento, lacalidad se refiere a las características mensurables -cosas que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos.El producto o servicio que nosotros adquiramos satisfaga nuestras expectativas sobradamente. Es decir, que aquel servicio o producto funcione tal y como nosotros queramos y para realizar aquella tarea o servicio que nos tiene que realizar. CALIDAD DE DISEÑOLa calidad de diseño se refiere a las características que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto grado y se especificantolerancias más estrictas y niveles más altos de rendimiento, la calidad de diseño de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones.CALIDAD DE CONCORDANCIALa calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño durante su realización. Una vez más, cuanto mayor sea el grado de cumplimento, más alto será el nivel de calidad deconcordancia. En el desarrollo del software, la calidad de diseño

comprende los requisitos, especificaciones y el diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación. Si la implementación sigue el diseño, y el sistema resultante cumple los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. CONTROL DE CALIDADEl control de calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del proceso del software para asegurar que cada producto cumple con los requisitos que le han sido asignados. El control de calidad incluye un bucle de realimentación (feedback) delproceso que creó el producto. La combinación de medición y realimentación permite afinar el proceso cuando los productos de trabajo creados fallan al cumplir sus especificaciones. Este enfoque veel control de calidad como parte del proceso de fabricación.

Las actividades de control de calidad pueden ser manuales, completamente automáticas o una combinación de herramientas automáticase interacción humana. Un concepto clave del control de calidad es que se hayan definido todos los productos y las especificaciones mensurables en las que se puedan comparar losresultados de cada proceso. El bucle de realimentación es esencial para reducir los defectos producidos.GARANTÍA DE CALIDADLa garantía de calidad consiste en la auditoría y las funciones de información de la gestión. El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Por supuesto, si los datos proporcionados mediante la garantía de calidad identifican problemas, es responsabilidad de la gestión afrontar los problemas y aplicar los recursos necesarios para resolver aspectos de calidad. COSTE DE CALIDADEl coste de calidad incluye todos los costes acarreados en la búsqueda de la calidad o en las actividades relacionadas en la obtención de la calidad. Se realizan estudios sobre el coste de calidad para proporcionar una línea base del coste actual de calidad, para identificar oportunidades de reducir este coste, y para proporcionar una base normalizada de comparación. La base de normalización siempre tiene un precio.

Una vez que se han normalizado los costes de calidad sobre un precio base, tenemos los datos necesarios para evaluar el lugar en donde hay oportunidades de mejorar nuestros procesos. Es más, podemos evaluar cómo afectan los cambios en términos de dinero.Los costes de calidad se pueden dividir en costes asociados con la prevención, la evaluación y los fallos.Entre los costes de prevención se incluyen:* Planificación de la calidad,* Revisiones técnicas formales,* Equipo depruebas,* Formación. Entre los costes de evaluación se incluyen actividades para tener una visión más profunda de-la condición del producto «la primera vez a través de» cada proceso. A continuación se incluyen algunos ejemplos de costes de evaluación:* Inspección en el proceso y entre procesos* Calibrado y mantenimiento del equipo* Pruebas.Los costes de fallos son los costes que desaparecerían si no surgieran defectos antes del envío de un producto a los clientes. Estos costes sepueden subdividir en costes de fallos internos y costes de fallos externos. Los internos se producen cuando se detecta un error en el producto antes de su envío. Entre estos se incluyen: trabajo (revisión), reparación, análisis de las modalidades de fallos.

Los costes de fallos externos son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. A continuación se incluyen algunos ejemplos de costes de fallos externos:* Resolución de quejas* Devolución y sustitución de productos* Soporte de línea de ayuda* Trabajo de garantía.Como es de esperar, los costes relativos para encontrar y reparar un defecto aumentan dramáticamente a medida que se cambia de prevención a detección y desde el fallo interno al externo. BIBLIOGRAFÍA;Libro: Ingeniería del SoftwareAutor: Pressman Roger S. Editorial: Mc Graw HillEdición: 5°, 2001

Paginas: 132-135

LA TENDENCIA DE LA CALIDADPara que un proyecto software tenga éxito, es necesario que el resultado cuente con la calidad esperada por el cliente o los usuariosDeberá ser posible realizar un plan de pruebas o deaseguramiento de la calidad que clasifique las actividades relacionadas con la calidad del producto según su importanciaEl uso de herramientas de análisis para medir la respuesta del proyectoa determinadas situaciones, o para simular un uso normal del mismo. El proceso de aseguramiento de la calidad no trata únicamente de que elproducto pase todos los test establecidos, sino que implicará en muchoscasos aspectos como los del siguiente diagrama.

PROCESO DE ASEGURAMIENTO DE LA CALIDAD

1El uso de hojas de estilo aprobadas por los usuarios

2La confección y repaso de checklists sobre funcionalidades.

3La revisión periódica del producto con los usuarios

GARANTIA DE CALIDAD DEL SOFTWARELa garantía de la calidad es el proceso que define cómo lograr la calidad del software y cómo la organización de desarrollo conoce el nivel de calidad requerido en el software Los equipos de garantía de calidad que desarrollan los estándares se apoyan en sus estándares organizacionales basados en estándares nacionales e internacionales El equipo de garantía de calidad debe ser independiente del equipo de desarrollo para que puedan tener una visión objetiva del software.

La calidad del software se estructura en tres actividades principales

Planificación de la calidadControl de la calidad

El establecimiento de un marco de trabajo de procedimientosy estándares organizacionales que conduce a software de alta calidadLa selección de procedimientos y estándares adecuados apartir de este marco de trabajo y la adaptación de éstos para un proyecto software específico.La definición y fomento de los procesosque garanticen que losprocedimientos y estándares para la calidad del proyecto son seguidos por el equipo de desarrollo de software.

ASPECTOS DE SEGUNDO PLANOLa garantía de calidad es una actividad esencial en cualquier empresa que elabora productos que van a ser usados por otros.El grupo de SQA intenta responderse preguntas y otras para asegurar quese tiene la calidad de software.¿Satisface de forma adecuada el software los factores de calidad?¿Se ha realizado el desarrollo del software del software de acuerdo conestándares preestablecidos? ¿Han desempeñado apropiadamente sus papeles las disciplinas técnicas como parte de la actividad de SQA? ACTIVIDADES DE SQAUna de las principales fases dentro de la elaboración de un proyecto esel Aseguramiento de la Calidad del Software (SQA) Para poder lograr una buena adherencia con los estándares se debe medircuantitativamente, donde sea posible, los aspectos de calidad (por ejemplo complejidad, confiabilidad, mantenimiento, seguridad, defectos,número de problemas) utilizando métricas bien establecidas. Actividades de SQAPara cumplir con esto, se deben realizar chequeos de:- Administración. - Documentación. - Estándares, prácticas, convenciones y métricas. - Revisiones e intervenciones. Actividades de testeo. Reporte de errores y accionescorrectivas. - Herramientas, técnicas y métodos.

- Control del código - Control de medios.

Colección de registros,mantenimiento y retención. - Control de los proveedores - Entrenamiento. - Administración del riesgo.

BIBLIOGRAFÍA:Libro: Ingeniería delSoftwareAutor: Pressman Roger S. Editorial: Mc Graw HillEdición: 5°, 2001Paginas: 173-175,182

IMPACTOS DE LOS DEFECTOS DE SOFTWARE SOBRE EL COSTEDentro del contexto de desarrollo de software, los términos "defecto" y"fallo" son sinónimos. Ambos implican un problema de calidad descubierto después de entregar el software a los usuarios finales.El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del Software.Una serie de estudios indican que las actividades del diseño introducenentre el 50% y 65% de todos los errores (y en último lugar, todos los defectos) durante el proceso de software. Sin embargo se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores.A partir de estos seis pasos surge la necesidad de la conformación de: objetivos participantes de la inspección y con qué roles, productos de trabajo a inspeccionar y cual deberá ser el resultado de las reuniones de inspección.Objetivos: El principal objetivo es encontrar defectos en el "producto de trabajo", de esta manera debemos definir cuáles serán las metas a alcanzar para el cumplimiento de éste objetivo. En nuestra opinión el establecimiento de éstas metas están en relación directa con el tipo deproyecto, metodologías y herramientas utilizados.Grupos de inspección: Se recomienda formar grupos entre 3 y 6personas [IEEE STD 1028-1988]. Dentro de éste grupo debe incluirse al autor de los productos de trabajo.

Roles: Además del autor se deberá tener en cuenta al moderador quien dirige la inspección y deberá contar con mayor experiencia que el resto, el lector quien presenta los productos de trabajo en las reuniones y el escriba quien documenta la descripción y ubicación de los defectos encontrados. Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes tipos de productos de trabajo que pueden encontrarse en un desarrollo de software incluyendo requerimientos, diseño, código, test,guías de usuario y otro tipo de documentación. El estándar de la IEEE no especifica un tamaño, pero los productos de trabajo tienen un tamañode 10 a 20 hojas para especificación de requerimientos, 200 o 250 líneas de código. En nuestra opinión también se debe tener en cuenta ladivisión natural que pueda tener cada uno de estos documentos ya que toda especificación podremos dividirla en partes así como el diseño o el código. Resultado de las reuniones de inspección: Los dos resultados principales debe ser: Una lista de defectos a corregir, y un reporte deinspección que describa que es lo que se inspeccionó, quien inspeccionóqué y el número de defectos encontrados. AMPLIFICACIÓN Y ELIMINACIÓN DE DEFECTOSSe puede usar un modelo de ampliación de defectos para ilustrar la generación y detección de errores durante los pasos de diseño preliminar, diseño detallado y codificación del proceso de ingeniería del software. En la figura A se ilustra esquemáticamente el modelo. Cada cuadro representa un paso en eldesarrollo del software. Durante cada paso se pueden generar errores que pasan inadvertidos. La inspección puede fallar en descubrir nuevos errores y errores de pasos anteriores, produciendo un mayor número de errores que pasan inadvertidos. En algunos casos, los errores que pasan inadvertidos desde pasos anteriores se amplifican (factor de ampliación x) con el trabajo actual. Las subdivisiones de los cuadros representan cada una de éstas características y el porcentaje de eficiencia para la detección de errores, una función de la profundidad de la inspección.

OBJETIVOS DE LA RTF Describir errores en la función, la lógica o la implementación de cualquier representación de los sistemas de información. Verificar que los sistemas bajo revisión alcancen sus requisitos. Garantizar que los sistemas han sido representados de acuerdo con ciertos estándares predefinidos.

Conseguir un sistema desarrollado en forma uniforme. Hacer que los proyectos sean más manejables. REVISIONES TÉCNICAS FORMALES* Es la actividad central del proceso de calidad.* Es una reunión entre el personal técnico con el propósito de descubrir problemas de calidad.Incluye los siguientes pasos:1. Reunión de revisión: * Idealmente deben ser entre 3 y 5 personas.* Deben ir preparados.* No se deben invertir más de dos horas.2. Registro e informes de la revisión: * ¿Qué fue revisado?* ¿Quién lo revisará?* ¿Qué se descubrió y cuáles fueron las conclusiones?

3. Puntos de conclusión y acciones a tomar: Son los pasos y acciones que se harán después de tener elregistro, es importante tomar en cuentalo siguiente:* Se debe revisar el producto, no los desarrolladores.* Se debe fijar la fecha de la siguiente reunión y mantenerla

LA REUNIÓN DE REVISIÓNEntre 3 y 5 personas (grupo pequeño) Preparación previa (2 horas por persona) Especificación precisa (formal o informal).La persona o el equipo ha desarrollado este módulo específico o producto íntimos del producto es completa y un examen puede tener lugar. Entonces el jefe de proyecto hacia adelante la solicitud a la líder de revisión que también informa a los revisores que llevan a cabo la tarea. Los miembros de la reunión de examen son los encuestados que realizan la tarea.

Los miembros de la reunión de examen son los encuestados, los desarrolladores líderes de revisión, producto (o el líder módulo solo) y no uno de los encuestados toma el trabajo de la grabadora y anota todas las cuestiones importantes planteadas en la reunión.

Al final de cada reunión de revisión, la decisión debe ser tomada por los asistentes a la FTR (formal de Revisión Técnica) sobre si aceptar el producto sin ninguna otra modificación o rechazar el producto debidoa errores graves o aceptar el producto con carácter provisional. Todos los FTR (formal de Revisión Técnica) asistentes firmar cualquier decisión adoptada. Al final de la revisión de una lista de examinar lascuestiones y un resumen de revisión es el informe se genera. Preguntas que se deben generar para realizar un informe de la revisión:¿Qué fue revisado?¿Quién lo revisará?¿Qué se descubrió y cuáles fueron las conclusiones?

REGISTRO E INFORMEDE LA REVISIÓN

DIRECTRICES PARA LA REVISIÓN1.- Revisar al producto, no al productor.2.- Fijar una agenda y mantenerla.3.- Limitar el debate y las impugnaciones.4.- Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.5.- Tomar notas escritas.6.- Limitar el número de participantes e insistir en la preparación anticipada.7.- Desarrollar una lista de comprobación para cada producto que haya de ser revisado.8.- Disponer de recursos y una agenda para las Revisiones.9.- Llevar a cabo un buen entrenamiento de todos los revisadores.10.- Repasar las revisiones anteriores.ENFOQUES FORMALES DE LA SQAUna corriente de pensamiento que argumenta que se requiere un enfoque más formal a SQA.Un programa de computadora es un objeto matemáticoSe puede definir una sintaxis y una semántica rigurosa para todos los lenguajes de programación y a la especificación de requerimientos.Se puede aplicar pruebas matemáticas de corrección a la especificación para demostrar que un programa cumple con su especificación. GARANTÍA DE CALIDAD ESTADÍSTICAPara garantizar la calidad del software se requieren los siguientes pasos:1. Clasificación de la programación sobre los efectos del software.

2. Se intenta encontrar la causa subyacente del defecto. 3. Utilizando la herramienta de Pareo se puede utilizar muchos defectos(eliminando los pocos vitales). 4. Se identifica los defectos vitales para corregir los problemas.

Podemos definir dos tipos de estándares como parte del proceso de garantía de calidad:1. Estándares de producto. Estos estándares se aplicansobre el productosoftware que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentario estándar para definición de clases, y estándares de codificación, que definen cómo debe utilizarse el lenguaje de programación.2. Estándares de proceso. Estos estándares definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el cursode estos procesos. Existe una relación muy cercana entre los estándares de producto y los estándares de proceso. Los estándares de producto se aplican a las salidas del proceso software y, en muchos casos, los estándares de proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares de producto.Los entandares de software son importantes por varias razones: Están basadas en el conocimiento de la mejor o más apropiada práctica de la empresa. A menudo, este conocimiento sólo se adquiere después de seguir un proceso de prueba y error. Tenerlo constituido en un estándarevita la repetición de errores anteriores. Los estándares captan el conocimiento que es de valor para la organización.Proveen un marco de trabajo alrededor del cual se implementa el procesode garantía de la calidad. Puesto que los estándares captan las mejoresprácticas, el control de la calidad sencillamente asegura que los estándares se siguen adecuadamente. Ayudan a la continuidad cuando una persona continúa el trabajo que llevaba a cabo otra. Los estándares aseguran que todos los ingenierosdeuna organización adopten las mismas prácticas. En consecuencia, se reduce el esfuerzo de aprendizaje cuando se comienza un nuevo trabajo.El desarrollo de los estándares de los proyectos de ingeniería del software es un proceso difícil y largo. Organizaciones nacionales e internacionales como el Departamento de Defensa de Estados Unidos, ANSI, BSI, OTAN y el IEEE han estado activas en la producción de los

estándares. Estos estándares generales se aplican a una variedad de proyectos. Organizaciones como la OTAN y otras organizaciones de defensa exigen que se sigan sus propios estándares en los contratos de software. Fiabilidad del softwareSi un programa falla frecuentemente en su funcionamiento, no importa siel resto de los factores de calidad son aceptables. La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa de computadoraes un entorno determinado y durante un tiempo específico.

Add Your TitleAdd Your TitleAdd Your Title¿Qué se entiende por el término fallo ?En el contexto de cualquier discusión sobre calidad y fiabilidad del software El fallo es cualquier falla de concordancia con los requisitos del software.

En esta definición existen grados. BIBLIOGRAFIA:Directrices para la revisión => internet dirección: http://chacharaselnido.com/calidad_sw/unidad3/Garantia%20de%20calidad.pdfEnfoques formales a la SQA => internet dirección: http://clases3gingsof.wetpaint.com/page/PLAN+DE+SQAFiabilidad del software => internet dirección: http://temasselectossw.galeon.com/productos1835379.htmlLibro:Ingeniería del softwareAutor: Ian SomervilleEditorial: Pearson Educación SA. de CV.Edición: 7°, 2005 Paginas: 591-593MEDIDAS DE FIABILIDAD Y DE DISPONIBILIDADLos primeros trabajos sobre fiabilidad intentaron explotar las matemáticas de la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software. La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al desajuste que a los fallos debidos a

defectos del diseño. En el hardware, son más probables los fallos debidos al desgaste físicoque los fallos relativos al diseño. Desgraciadamente para el software lo que ocurre es lo contrario. De hecho todos los fallos del software, se producen por problemas de diseño o de implementación; el desajuste no entra en este panorama.Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es el tiempo medio entre fallos (TMEF), donde:TMEF = TMDF + TMDR

TMEF: Tiempo Medio Entre Fallos.TMDF: Tiempo Medio De Fallo.TMDR: Tiempo Medio De Reparación.Además de una medida de fiabilidad debemos obtener una medida de la disponibilidad. La disponibilidad del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado, y se define como: La medida de fiabilidad TMEF es igualmente sensible al TMDR que al TMDF. La medida de disponibilidad es algo más sensible al TMDR, una medida indirecta de la facilidad de mantenimiento del software. PUNTO CLAVE Los problemas de la fiabilidad del software se deben casi siempre a errores en el diseño o en la implementación.

ANALISIS DE RIESGO¿Qué es el análisis de riesgos?El análisis de riesgos es un paso importante para implementar la seguridad de la información. Como su propio nombre lo indica, es realizado para detectar los riesgos a los cuales están sometidos los activos de una organización, es decir, para saber cuál es la probabilidad de que las amenazas se concreten.Las amenazas se pueden convertir en realidad a través de fallas de seguridad, que conocemos como vulnerabilidades y que deben ser eliminadas al máximo para que el ambiente que se desea proteger esté libre de riesgos de incidentes de seguridad.Por lo tanto, la relación entre amenaza-incidente-impacto, es la condición principal a tomar en cuenta en el momento de priorizar acciones de seguridad para la corrección de los activos que se desean proteger y deben ser siempre considerados cuando se realiza un análisisde riesgos.

DEFINICION ANALISIS DE RIESGO

ESTANDARES DE CALIDAD ISO 9001¿Qué es la norma ISO 9001?La ISO 9001 es una norma internacional que se aplica a los sistemas de gestión de calidad (SGC) y que se centra en todos los elementos de administración de calidad con los que una empresa debe contar para tener un sistema efectivo que le permita administrar y mejorar la calidad de sus productos o servicios.Los clientes se inclinan por los proveedores que cuentan con esta acreditación porque de este modo se aseguran de que la empresa seleccionada disponga de un buen sistema de gestión de calidad (SGC).Esta acreditación demuestra que la organización está reconocida por másde 640.000 empresas en todo el mundo.Temporalmente, en principio cada año, lasempresas se ven sometidas a una auditoria por parte de la empresa de certificación. A la que se le exigen los más altos niveles de honradez, seriedad, fiabilidad y experiencia.Dicha auditoria, va a exigir una mejora de los resultados respecto a laauditoria anterior. Por lo que es requisito indispensable para renovar la certificación haber mejorado la calidad del producto.Si no se supera la auditoria en determinados plazos e intento, se pierde la certificación.La certificación, es garantía de calidad. Es demandada por los consumidores, y por las empresas certificadas. Estas empresas, suelen exigir la misma certificación a sus proveedores que permita a ambos mejorar y prosperar mediante productos de elevada cualidad.Esta estrategia de gestión de la calidad, es la que se considera óptimapara lograr estos objetivos. Y aunque no se esté certificado, es a lo que todas las empresas deben de aspirar y lograr.La norma ISO 9001, es una buena forma de mejorar el resultado final de la organización, sin incurrir en elevados costes. Mediante la auto acción interna sobre la organización y componentes de la empresa.El objetivo de la ISO es llegar a un consenso con respecto a las soluciones que cumplan con las exigencias comerciales y sociales (tantopara los clientes como para los usuarios). Estas normas se cumplen de forma voluntaria ya que la ISO, siendo una entidad no gubernamental, nocuenta con la autoridad para exigir su cumplimiento.Sin embargo, tal como ha ocurrido con los sistemas de administración decalidad adaptados a la norma ISO 9000, estas normas pueden convertirse

en un requisito para que una empresa semantenga en una posición competitiva dentro del mercado.La Norma ISO 9001 tiene como objetivo satisfacer al consumidor PASOS PARA OBTENER EL CERTIFICADO ISO – 9001

Obtener la certificación ISO 9001, es tarea de todos los integrantes dela empresa, y produce satisfacción entre sus miembros.La certificación, es sinónimo de buenos productos y garantía de calidad.

Plan de Garantía de Calidad de Software (SQA Plan) Software Quality AssuranceSoftware Quality Assurance Plan o SQAP (es decir, Plan de Garantía de Calidad de Software) es un documento que organiza el desarrollo del software con el fin de que el proceso de creación de este siga unas pautas que aseguren la calidad del resultado.Este plan de garantía forma parte de la Ingeniería de software.En este documento se organiza el equipo de personas, se elige el ciclo de vida a seguir, se especifican los documentos que harán falta, las revisiones que se harán, las pruebas e incluso cómo realizar el mantenimiento.SOFTWARE DE GARANTÍA DE CALIDAD Software Quality Assurance (SQA) se define como un proyecto y enfoque sistemático para la evaluación de la calidad y de la adhesión a las normas sobre los productos de software, procesos y procedimientos. SQA incluye el proceso de garantizar que normas y procedimientos están establecidos y son seguidos todo el software de adquisición del ciclo de vida. Libro: Ingeniería del softwareAutor: Ian SommervilleEditorial: Pearson Educación SA. de CV.Edición: 7°, 2005 Paginas: 789-792, Cap. 7Libro: Ingeniería del SoftwareAutor: Pressman Roger S. Editorial: Mc Graw HillEdición: 5°, 2001Paginas: 749-755UNIDAD IVANALISIS DE LOS REQUERIMIENTOSINTRODUCCION

Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos (RE).

El término requerimiento no se utiliza de una forma constante en la industria de software. En algunos casos, un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. En el otro extremo, es una definición detallada y formal de una función del sistema

Algunos de los problemas que surgen durante el proceso de ingeniería derequerimientos son resultado de no hacer una clara separación entre estos diferentes niveles de descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la descripción detallada de lo que el sistema debe hacer.Los requerimientos del usuario y del sistema se pueden definir como se muestra a continuación:1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.2. Los requerimientos del sistema establecen con detalle las funciones,servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificación funcional) debe ser preciso. Debe definir exactamente qué es lo que se va a implementar.

Diferentes niveles de especificación del sistema son de utilidad debidoa que comunican la información del sistema a diferentes tipos de lectores. Es necesario redactar los requerimientos en diversos niveles de detalle debido a que diferentes. Tipos de lectores los utilizan de distinta manera.

Los lectores de los requerimientos del sistema necesitan saber con más precisión qué hará el sistema debido a que están interesados en cómo

ayudará esto a los procesos de negocio o debido a que están implicados en la implementación del sistema.

5.1 REQUERIMIENTOS FUNCIONALE Y NO FUNCIONALESRequerimiento: Una condición o necesidad de un usuario para resolver unproblema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

Los requerimientos puedes dividirse en requerimientos 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 características que de una u otra forma puedan limitar el sistema, como por ejemplo, elrendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad deequipo), mantenimiento, seguridad, portabilidad, estándares, etc.Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos (RE).

El término requerimiento no se utiliza de una forma constante en la industria de software. En algunos casos, un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. En el otro extremo, es una definición detallada y formal de una función del sistema

Algunos de los problemas que surgen durante el proceso de ingeniería derequerimientos son resultado de no hacer una clara separación entre estos diferentes niveles de descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la descripción detallada de lo que el sistema debe hacer.

Los requerimientos del usuario y del sistema

Características de los requerimientos: ------------------------------------------------------------------Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo.A continuación se presentan las más importantes.

* Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

* Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

* Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

* Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

* No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

* Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

* Los requerimientos no son obvios y vienen de muchas fuentes.* Son difíciles de expresar en palabras (el lenguaje es ambiguo).* Existen muchos tipos de requerimientos y diferentes niveles de detalle.* La cantidad de requerimientos en un proyecto puede ser difícil de

manejar.* Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.* Los requerimientos están relacionados unos con otros, y a su vez serelacionan con otras partes del proceso.* Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.* Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.* Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.EJEMPLO:

Definición de requerimiento de usuario.

1. LIBSYS controlará todos los datos requeridos por las agencias que licencian los derechos de autor en el Reino Unido y en otro parte.

Especificación de los requerimientos del sistema.

1.1. Al hacer una petición de un documento del LIBSYS, el solicitante se presentará con un formulario que registre los detalles del usuario yde la petición hecha.1.2. El formulario de petición del LIBSYS será almacenado en el sistemadurante cinco años desde la fecha de la petición.1.3. Todos los formularios de peticiones del LIBSYS se deben indexar por usuario, por el nombre del material solicitado por el proveedor de la petición.1.4. El LIBSYS mantendrá un fichero en el que se registrarán todas las peticiones que se han hecho al sistema.1.5. Para el material donde se aplican los derechos de préstamo del autor, los detalles del préstamo serán enviados mensualmente a las agencias que licencian los derechos de autor que se han registrado con LIBYSYS.

Es necesario redactar los requerimientos en diversos niveles de detalledebido a que diferentes tipos de lectores los utilizan de distinta manera. La siguiente figura muestra los tipos de lectores de requerimientos de usuario y del sistema. Los lectores de los requerimientos normalmente no tratande cómo se implementará el sistema y pueden ser administradores que no están interesados en los recursos

detallados del sistema. Los lectores de los requerimientos del sistema necesitan saber con más precisión qué hará el sistema debido a que están interesados en cómo ayudará esto a los procesos de negocio o debido a que están implicados en la implementación del sistema.

Lectores de los diferentes tipos de especificaciones.

A menudo, los requerimientos del sistema software se clasifican en funcionales y no funcionales, o como requerimientos del dominio:

1. REQUERIMIENTOS FUNCIONALES: Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

2. REQUERIMIENTOS NO FUNCIONALES: Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre los procesos de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmenteapenas se aplican a características o servicios individuales del sistema.

3. REQUERIMIENTOS DEL DOMINIO: Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales y no funcionales.

En realidad, la distinción entre diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones. Porejemplo, un requerimiento del usuario sobre seguridad podría parecer un requerimiento no funcional. Sin embargo, cuando se desarrollan en detalle, pueden generar otros requerimientos que son claramente funcionales, como la necesidad de incluir en el sistema recursos para la autentificación del usuario.

REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales de un sistema describen lo que el

sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describende una forma bastante abstracta. Sin embargo, los requerimientos funcionales del sistema describen con detalle las funciones de éste, sus entradas y salidas, excepciones, etcétera.

Los requerimientos funcionales de un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales de un sistema de biblioteca universitaria, denominada LIBSYS, utilizada por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.

1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.2. El sistema deberá proporcionar visores adecuados para que el usuariolea documentos en el almacén de documentos.3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta.

Estosrequerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimiento del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales.

El sistema LIMSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículospublicado en revistas, periódicos y publicaciones científicas. La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería de software. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto, esto

retrasa la entrega de éste e incrementa los costes.

EJEMPLO:

Un sistema de biblioteca puede mostrar documentos en diferentes formatos; la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. Sin embargo, los requerimientosestán ambiguamente redactados, no clarifica que se deben proporcionar los visores de cada formato. Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y afirmar que se ha cumplido el requerimiento.En principio, las especificaciones de requerimientos funcionales de un sistema deben estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. Laconsistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemasgrandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud.

Una razón de esto es que es fácil cometer errores y omisiones cuando seredactan especificaciones para sistemas grandes y complejos. Otras razones es que los stakeholders del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas contradicciones pueden noser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es posible que los problemas surjan solamente después de un análisis más profundo o, a veces, después de que se termine el desarrollo y el sistema se entregue al cliente.

SommervilleIan. Ingeniería de Software. 7ma edición. Pág. 100-101

REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales, como su nombre sugiere, son aquellosrequerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las

interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, puedenespecificar el rendimiento del sistema, laprotección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares.

Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo, el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable.EJEMPLO:

Si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, lasfunciones de control no funcionarán correctamente.

Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema.

Ejemplos de requerimientos de procesos son la especificación que el diseño debe producir con una herramienta CASE particular y una descripción del procesos a seguir.

Los requerimientos no funcionales surgen de las necesidades del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas software o hardware, o a factores externos como regulaciones de seguridad o legislaciones sobre la privacidad.

Tipos de requerimientos no funcionales

Los tipos de requerimientos no funcionales son:1. Requerimientos del producto. Estos requerimientos especifican el comportamiento delproducto.

2. Requerimientos organizacionales. Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador.

3. Requerimientos externos: Este gran partido incluye todos los requerimientos que se derivan de los factores externos del sistema al sistema y de su proceso de desarrollo. Roger S.Pressman. 5 edición. Pág. 186 188

4.2 CASOS DE USO

Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos que se introdujeron por primera vez en el método Objetory. Actualmente se han convertido en una característica fundamental de la notación UML, que se utiliza para describir modelos de sistemas orientados a objetos. En su forma más simple, un caso de uso identifica el tipo de interacción y los actores involucrados. Por ejemplo en la figura siguiente se muestra un caso de uso de alto nivel de la función e impresión de artículos en el LIBSYS descrita.

La figura ilustra la esencia de la notación para los casos de uso. Los actores en el proceso se representan como figuras delineadas, y cada clase de interacción se representa como una elipse con su nombre. El conjunto de casos de uso representa todas las posibilidades interacciones a representar en los requerimientos del sistema.

Un caso de uso sencillo para la impresión de artículos.

Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son quéhace el sistema desde el punto de vista del usuario. Es decir,describenun uso del sistema y cómo este interactúa con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean también una

forma visual de representar la información. Sin embargo estás muy equivocado, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para que quede claro, "Los diagramas no son lo importante".Sé que alguno estará impaciente con los diagramas, así que luego los trataré. Pero primero vayamos con lo realmente interesante.

Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿qué es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario.Pero lo más claro es que te presente uno. Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.

Algunas veces existe confusión sobre si un caso de uso es un escenario o, como sugiere Fowler, un caso de uso encierra un conjunto de escenarios, y cada uno de éstos es un hilo único a través del caso de uso. Si un escenario incluye múltiples hilos, habrá un escenario para la interacción normal y escenarios adicionales para las posibles excepciones.

Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en más detalle. Los diagramas en secuenciase utilizan a menudo para añadir información a un caso de uso. Éstos muestran los actoresinvolucrados en la interacción, los objetos con losque interactúan y las operaciones asociadas con estos objetos.

EJEMPLO: Biblioteca.

Las interacciones involucradas en la utilización del LIBSYS para la descarga e impresión de un artículo. En la siguiente figura existen cuatro objetos de clases: artículos, Formularios, Espacio de trabajo e Impresora, involucradas en esta interacción. La secuencia de acciones es de arriba abajo, y las etiquetas de las flechas entre los actores y los objetos indican los nombres de las operaciones. Fundamentalmente, una petición de un artículo por parte de un usuario provoca una petición de un formulario de derechos de autor. Una vez que el usuario ha completado el formulario, se descarga el artículo y se envía a la

impresora. Cuando termina la impresión, se elimina el artículo del espacio de trabajo del LIBSYS.

UML es un estándar de facto para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utilizan cada vez más para la obtención de requerimientos.

Nombre: | Crear mensaje foro |Autor: | Joaquín Gracia |Fecha: | 24/08/2003 |Descripción: Permite crear un mensaje en el foro de discusión. |Actores: Usuario de Internet logueado. |Precondiciones: El usuario debe haberse logueado en el sistema. |Flujo Normal: 1. El actor pulsa sobre el botón para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpodel mensaje. 3. El actor introduce el título del mensaje y el cuerpo delmismo. 4. El sistema comprueba la validez de los datos y los almacena. |Flujo Alternativo: 4. El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole quelos corrija |Post condiciones: El mensaje ha sido almacenado en el sistema. |

Saltándome los campos evidentes como nombre, autor, fecha y descripción; los actores son aquellos que interactúan con el sistema. Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo. Luego tenemos el flujo de eventos, que corresponde a la ejecución normal y exitosa del caso de uso (use case). Los flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados. Por último, las post condiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente.

De forma que un caso de uso (use case) es un documento como el

anteriormente presentado. Los casos de uso se pueden detallar más o menos dependiendo de la necesidad del problema. El que te he presentadono es completo, si te interesa puedes echar un vistazo a una plantilla completa de un caso de uso (use case), se les suele llamar casos de uso"full-dressed".

Se cita un ejemplo de diagrama de caso de uso expresado de otra manera para la interacción del uso de un cajero automático.

Se analizan otros tipos de modelos UML, el cual trata en modelado de sistemas, que aborda el diseño orientado a objetos. Los escenarios y los casos de uso son técnicas eficaces para obtener requerimientos para los puntos devista de los interactuadores, donde cada tipo de interacción se puede representar como un caso de uso. También se puede utilizan conjuntamente con algunos puntos de vista indirectos cuando éstos reciben resultado (como un informe de gestión) del sistema. Sin embargo, debido a que se centran en las interacciones,no son tan eficaces para obtener restricciones y requerimientos de negocios y no funcionales de alto nivel de puntos de vista indirectos opara descubrir requerimientos del dominio.Una vez recopilados los requisitos, bien por reuniones informales, TFEAy DFC el ingeniero de software (analista) puede crear un conjunto de escenarios que no identifiquen una línea de utilización para el sistemaque va a ser construido. Los escenarios, alguna vez llamados casos de uso (JAC 92), facilitan una descripción de como el sistema se usara, para crear un caso de uso, facilitan una descripción de como el sistemausara.Para crear un caso de uso, el analista debe primero identificar los diferentes tipos de personas (o dispositivos) que utiliza el sistema o producto. Estos actores actualmente representan papeles que la gente (odispositivos) juegan como impulsores del sistema. Definido más formalmente, un actor es algo que comunica con el sistema o producto que es externo al sistema en sí mismoEs importante indicar que un actor y en un usuario no son la misma cosa.Un usuario normal puede jugar un número de papeles diferentes cuando utiliza un sistema, por lo tanto un actor representa una clase de entidades extremas (a veces, pero no siempre personas) que lleva a caboun papel.Ejemplo:

Considerar un operador de unamaquina (un usuario) que interactúa con elordenador central para un elemento de fabricación que contiene un numero de robots y maquinas bajo control numérico. Después de una revisión cuidadosa de los requisitos, el SW del computador central requiere cuatro modelos diferentes (papeles) de interacción: modo programación, modo prueba, modo monitorización y modo investigación, además se pueden definir cuatro actores: programador, probador, supervisor e investigador. En algunos casos, el operador de la maquina puede realizar todos los papeles. En otras ocasiones, diferentes personas pueden jugar el papel de cada actor.Porque la obtención de requisitos es una actividad de evolución, no todos los actores se identifican durante la primera iteración. Es posible identificar actores secundarios cuando más se aprende del sistema. Los actores iniciales interactúan para conseguir funciones delsistema y derivar el beneficio deseado del sistema.Ellos trabajan directa y frecuentemente con el software. Los actores secundarios existen para dar soporte al sistema que los actores iniciales han dado forma con su trabajo.Una vez que se han identificado los actores, se pueden desarrollar los casos de uso. El caso de uso describe la manera en que los actores interactúan con el sistema. Jacobson sugiere un número de preguntas quedeberían responderse por el caso de uso:¿Cuáles son las principales tareas o funciones que serán realizadas porel actor?¿Cuál es el sistema de información que el actor adquiere, produce o cambia?¿Qué actor informara al sistema de los cambios en el entorno externo?¿Qué información necesito el actor sobre elsistema?Cada caso de uso facilita un escenario sin ambigüedad en la interacciónentre el actor y el software. Esto puede usarse para especificar requisitos de tiempo u otras restricciones del escenario. Los casos de uso describen escenarios que serán percibidos de distinta forma por distintos actores. Wyder (WYD96) indica que la calidad de la función desplegada puede ser usada para desarrollar un amplio valor de prioridades para cada caso de uso. Para acabar los casos, de uso son evaluados desde el punto de vista de todos los actores definidos para el sistema. Se asigna un valor de prioridad a cada caso de uso (ejemplodel 1 al 10) para cada acto. Se calcula una prioridad indicando la importancia percibida de cada caso de uso.Cuando un modelo de proceso iterativo es usado por la ingeniería del

software orientado a objetos, las prioridades pueden influir en que funcionalidad del sistema será entregada primero.Ejemplo:Un caso de uso para el sistema de activación persigue:El propietario observa un prototipo del panel de control de hogar seguro para determinar si el sistema está preparado para la entrada. Siel sistema no está preparado, el propietario debe físicamente cerrar ventana de puertas para que se encienda el indicador de preparado.El propietario utiliza el teclado para introducir una contraseña de cuatro dígitos. La contraseña es comparada con la contraseña valida almacenada en el sistema. Si la contraseña es errónea, el panel de control emitirá un sonido y se restaurara para incorporar una nueva entrada.El propietario selecciona y pulsa STAY o AWAY para activar el sistema. Stay activa solamentesensores perimetrales cuando se detectan movimiento interno se desactivan. Away activa todos los sensores.

BIBLIOGRAFIA:Roger S. Pressman.Ingeniería de software. Un enfoque práctico 5ª Edición. Pág. 186- 188.

4.3 DISEÑO DE INTERFAZ DE USUARIOEl diseño de sistemas informáticos abarca varias actividades que van desde el diseño de hardware hasta el de la interfaz de usuario. Aunque muchos especialistas a menudo trabajan en el diseño de hardware y en eldiseño gráfico de páginas web, normalmente sólo las organizaciones grandes emplean diseñadores especialistas de interfaces para sus aplicaciones software. Por lo tanto, los ingenieros de software a menudo deben tomar la responsabilidad de diseñar la interfaz de usuario, así como de software a menudo deben tomar la responsabilidad de diseñar la interfaz de usuario, así como del diseño del software queimplementa esa interfaz.El diseño de interfaz de usuario o ingeniería de la interfaz es el diseño de computadoras, aplicaciones, máquinas, dispositivos de comunicación móvil, aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la interacción.Normalmente es una actividad multidisciplinar que involucra a varias ramas del diseño y el conocimiento como el diseño gráfico, industrial, web, de software y la ergonomía; y está implicado en un amplio rango deproyectos, desde sistemas para computadoras, vehículos hasta aviones

comerciales.Su objetivo es que las aplicaciones o los objetos sean más atractivos yademás, hacer que la interacción con el usuario sea lo más intuitiva posible, conocido como el diseño centrado en el usuario. En este sentidolas disciplinas del diseño industrial y gráfico se encargan de que la actividad a desarrollar se comunique y aprenda lo más rápidamente, a través de recursos como la gráfica, los pictogramas, losestereotipos y la simbología, todo sin afectar el funcionamiento técnico eficiente.

DISEÑO DE LA INTERFAZ DE USUARIOUn diseño cuidadoso de la interfaz de usuario es parte fundamental de proceso de diseño general del software. Si un sistema software debe alcanzar su potencial máximo, es fundamental que su interfaz de usuariosea diseñada para ajustarse a las habilidades, experiencia y expectativas de sus usuarios previos. Un buen diseño de la interfaz de usuario es crítico para la confiabilidad del sistema. Muchos de los llamados <<errores de usuario>> son causados por el hecho de que las interfaces de usuario no consideran las habilidades de los usuarios reales y su entorno de trabajo. Una interfaz de usuario mal diseñada significa que los usuarios probablemente no podrá acceder a algunas características del sistema, cometerán errores y sentirán que el sistema les dificulta en vez de ayudarlos a conseguir cualquier objetivo para el que utilizan el sistema. El diseño de la interfaz de usuario requiere el estudio de las personasy el conocimiento tecnológico adecuado.-----

Preguntas que deben plantearse y responderse para el diseño de la interfaz de usuario* ¿Quién es el usuario?* ¿Cómo aprende a interactuar con el nuevo sistema de cómputo?* ¿Cómo interpreta la información que produce el sistema?* ¿Qué espera del sistema?

REGLAS DE ORO

Existen tres reglas de oro para el diseño dela interfaz:* Dar el control al usuarioEs decir un sistema que reaccione a las necesidades del usuario y que le ayude a hacer las cosas.

* Reducir la carga en la menoría del usuario Una interfaz de usuario bien diseñada no dependerá de la memoria del usuario. Siempre que sea posible, el sistema debe “recordar” la información pertinente y ayudar al usuario con un escenario de interacción que le facilite el uso de la memoria.* Lograr que la interfaz sea consistenteImplica:Toda la información visual este organizada de acuerdo con un estándar de diseño que se mantenga en todas la presentaciones de pantalla. * Los mecanismos de entrada se restrinjan a un conjunto limitado que seutilicé de manera consistente en toda la aplicación.* Los mecanismos para ir de una tarea a otra se hayan definido e implementado de manera consistente.

ANALISIS Y DISEÑO DE LA INTERFAZ DE USUARIOEl proceso general para analizar y diseñar una interfaz de usuario empieza con la creación de diferentes modelos de función del sistema. Asuntos de diseñoAntes de abordar el proceso de diseño de la interfaz de usuario, se tratan algunos asuntos generales de diseño que tienen que son considerados por los diseñadores de interfaces de usuario. Fundamentalmente, el diseñador de la interfaz de usuario se plantea doscuestiones clave:1. ¿Cómo debe interactuar el usuario con el sistema informático?2. ¿Cómo se debe presentar la información del sistema informático al usuario?Una interfaz de usuario coherente debe integrar la interacción del usuario y la presentación de la información. Esto debe serdifícil debido a que los diseñadores tienen que encontrar un término medio entre los estilos más adecuados de interacción y presentación para la aplicación, la información y la experiencia de los usuarios del sistema, y el equipo disponible.

ANALISIS Y DISEÑO DE LA INTERFAZ DE USUARIO (Cont.)Luego se delinean las tareas orientadas al ser humano y al equipo que se requieren para lograr el funcionamiento del sistema.

Existen dos operaciones fundamentales que se necesitan soportar:1. Búsqueda de documentos, en la que los usuarios utilizan las

funciones de búsqueda para encontrar los documentos que necesitan2. Petición de documentos, en la que los usuarios solicitan que el documento se descargue en su máquina o servidor local para imprimirlo.

Múltiples interfaces de usuarios.

Una interfaz basada en formularios para el sistema LIBSYS

La interfaz de usuario del LIBSYS se implementa utilizando un navegadorweb, por lo que dado que los usuarios deben proporcionar información alsistema como el identificador del documento, sus nombres y detalles de autorización tiene sentido utilizar una interfaz basada en formularios.

Modelos del análisis y diseño de la interfazUn ingeniero humano establece un modelo del usuario; el ingeniero del software crea un modelo del diseño; el usuario final desarrolla una imagen mental que suele denominarse modelo mental del usuario o percepción del sistema, y quienes implementan el sistema crean un modelo de la implementación.

El modelo del usuarioEstablece el perfil de los usuarios finales del sistema.

Los usuarios están distribuidos en las siguientescategorías:* Principiantes. No tienen conocimientos de la sintaxis del sistema y cuentan con escasos conocimientos de la semántica de la aplicación o del uso de la computadora en general. * Usuarios esporádicos y con conocimientos. Tienen conocimientos razonables de la semántica, pero muestran una retención relativamente baja de la información sobre sintaxis necesaria para utilizar la interfaz. * Usuarios frecuentes y con conocimientos. Cuentan con conocimientos desintaxis y semántica suficientes para llegar al “síndrome del usuario avanzado”.

El modelo del diseñoIncorpora datos, arquitectura interfaz y representaciones procedimentales del software.

La especificación de requisitos establece ciertas restricciones que ayudan a definir el usuario del sistema.El modelo mental moldea la manera en que el usuario percibe la interfazy esta satisface sus necesidades.

El modelo de la implementación Combina la manifestación externa del sistema de cómputo y toda la información de ayuda que describe la sintaxis y semántica del sistema. Cuando coinciden el modelo de la implementación y el modelo mental del usuario, los usuarios suelen sentirse a gusto con el software y lo usancon efectividad.El Proceso El proceso de análisis y diseño de la interfaz de usuario abarca cuatroactividades distintas de marco de trabajo1. Análisis y modelado de usuarios, tarea y entornos.2. Diseño de la interfaz 3. Construcción (implementación) de la interfaz 4. Validación de la interfaz

El análisis de la interfaz se concentra en el perfil de los usuarios que interactuaran con el sistemaProceso de diseño de la interfaz de usuario

PASOS DEL DISEÑO DE LA INTERFAZSe han propuesto muchos modelos diferentes para el diseño de la interfaz de usuario, todos sugieren una combinación de los siguientes pasos:1. Con base en la información desarrollada durante el análisis de la información, definir los objetos y las acciones de la interfaz (operaciones).2. Definir eventos (acciones del usuario) que cambiarán el estado de lainterfaz. Modelar este comportamiento.3. Representar cada estado de la interfaz tal como lo verá el usuario final. 4. Indicar como interpreta el usuario el estado del sistema a partir dela interfaz proporcionada mediante la interfaz.

TIEMPO DE RESPUESTAEl tiempo de respuesta del sistema es la primera queja sobre muchas aplicaciones interactivas. En general, se mide desde el punto en que el

usuario realiza alguna acción de control.El tiempo de respuesta del sistema tiene dos características importantes:

Duración y variabilidad.

* Duración. Si la respuesta del sistema se demora mucho, la frustracióny el estrés del usuario son inevitables.

* Variabilidad. Es la desviación del tiempo de respuesta promedio. Una baja variabilidad permite que el usuario establezca un ritmo de interacción, aunque el tiempo de respuesta sea relativamente largo.

Métodos de presentar la información numérica que varía dinámicamente.

EVALUACIÓN DEL DISEÑO Una vez que se ha creado un prototipo de interfaz de usuario operacional, debe evaluarse y determinar si satisface las necesidades del usuario.

Ciclo de evaluación del diseño de la interfaz deusuarioRoger S. Pressman.Ingeniería de software. Un enfoque práctico 5ª Edición. Pág. 140- 141

4.3.1 REGLAS EN EL DISEÑO DE INTERFAZ DE USUARIOEl diseño de interfaces debería ser la columna vertebral de cualquier aplicación, porque un buen diseño de interfaz puede ser la diferencia para ofrecerle al usuario final una excelente experiencia de usabilidad, efectividad y hacer de tu sistema una joya.Del libro Designing the User Interface por Ben Shneiderman, nos listan 8 puntos para lograr una buena interacción con el diseño.1 Luchar por la coherencia.-------------------------------------------------------------------Secuencias de acciones consistentes deberían ser necesarias en situaciones similares; idéntica terminología debe utilizarse en anuncios, menús y pantallas de ayuda, y los comandos consistentes debenser empleados en todo.

2 Permite a los usuarios frecuentes utilizar accesos

directos.-------------------A medida que la frecuencia de uso aumenta, también lo hacen los deseos del usuario para reducir el número de acciones y aumentar el ritmo de interacción. Acrónimos y abreviaturas, las teclas de función, los comandos ocultos, y macro instalaciones son muy útiles para un usuario experto.3 Ofrece comentarios informativos.--------------------------------------------------------Por cada operador de acción, debe haber algún sistema de retroalimentación. Para acciones frecuentes y de menor uso, la respuesta puede ser modesta, mientras que para los poco frecuentes y las principales acciones, la respuesta debería ser más sustancial.4 Diseño de diálogo para producir laclausura.----------------------------------------Acciones secuenciales debe organizarse en grupos con un comienzo, intermedio y final. La retroalimentación informativa a la conclusión deun grupo de acciones da a los operadores la satisfacción de logro, una sensación de alivio, la señal para dejar caer los planes de contingencia y las opciones de sus mentes, y una indicación de que la vía está libre para prepararse para el siguiente grupo de acciones.Análisis de tareas jerárquico

5 Ofrece una manipulación de errores simples.---------------------------------------En la medida de lo posible, diseñar el sistema para que el usuario no ocasione un grave error. Si aparece un error, el sistema debería ser capaz de detectar el error y ofrecer de manera sencilla y comprensible una manera para identificar el error.

Mensajes de error orientados al sistema y al usuario.6 Permitir un fácil retroceso de las acciones.------------------------------------------Esta característica alivia la ansiedad, ya que el usuario sabe que los errores se pueden deshacer, sino que por lo tanto, alienta la exploración de opciones desconocidas. Las unidades de reversibilidad pueden ser una sola acción, una entrada de datos, o un grupo de acciones.

7 Apoyo interno a un enfoque de control total.----------------------------------------

Los usuarios experimentados desean el sentido de que están a cargo del sistema y que el sistema responde a sus acciones. Diseña el sistema para que los usuarios inicien las acciones en lugar de las respuestas.

8 Reducir la carga de la memoria a corto plazo.---------------------------------------La limitación de recursos humanos deprocesamiento de la información en la memoria a corto plazo exige que se muestren de manera sencilla, varias páginas se muestra consolidado, ventana-motion frecuencia se reducirá, y suficiente tiempo de formación se adjudicará a los códigos,mnemotécnicos, y secuencias de acciones.

El proceso de diseño de la UI.

EJEMPLO:Un informe de observaciones del control de tráfico aéreoEl control del tráfico aéreo implica varios juegos de controles donde los juegos que controlan sectores adyacentes del espacio aéreo están físicamente situados unos al lado de otros. Los vuelos en un sector se representan mediante tiras de papel que se ajustan en rejillas de madera en un orden que refleja su posición en el sector. Si no hay suficientes ranuras en la rejilla (por ejemplo, cuando hay mucho tráfico en el espacio aéreo), los controladores extienden las tiras en la mesa delante de la rejilla. Cuando observamos a los controladores, nos dimos cuenta de que con regularidad la miraban las rejillas de tiras del sector adyacente. Se lo comentamos y les preguntamos por qué lo hacían. Respondieron que cuando el controlador adyacente tiene tirasen su mesa, significa que están entrando muchos vuelos a los sectores. Por lo tanto, intentaban incrementar la velocidad de los aviones en el sector para despejar el espacio para los aviones entrantes.BIBLIOGRAFIA:Roger S. Pressman.Ingeniería de software. Un enfoque práctico 5ª Edición. Pág. 259- 265 4.3.2 INTEGRACIÓN DE LA INTERFAZ AL CASO DE USO

Aunque se han propuesto modelos diferentes para el diseño de la interfaz de usuario (Por ejemplo, NOR86, NIE00), todos sugieren algunacombinación de los siguientes pasos:

1. Con base en la información desarrollada durante el análisis de la

información, definir los objetos y las acciones de la interfaz (operaciones).

2. Definir eventos (acciones del usuario) que cambiarán el estado de lainterfaz Modelar este comportamiento.

3. Representar cada estado de la interfaz tal como lo verá el usuario final.

4. Indicar como interpreta el usuario el estado del sistema a partir dela interfaz proporcionada mediante la interfaz.

En algunos casos, el diseñador de la interfaz puede empezar con borradores de cada estado de la interfaz (es decir, el aspecto de la interfaz en distintas circunstancias) y luego trabajar hacia atrás paradefinir objetos, acciones y otra información importante para el diseño.Independientemente de la secuencia de las tareas del diseño, éste debe:

A) Seguir siempre las reglas de oro analizadas.

B) Modelar la manera en que se implementará la interfaz

C) Tomar en cuenta el entorno (por ejemplo, la tecnología de despliegue, el sistema operativo, las herramientas de desarrollo) en que habrá de usarse.

APLICACIÓN DE LOS PASOS DEL DISEÑO DE LA INTERFAZ

Un paso importante en el diseño de la interfaz es la definición de los objetos que esta tendrá y las acciones que se les aplicarán. Para realizarlo se analizan los casos de uso.

Es decir, se escribe una descripción de un caso de uso. Luego se aíslanlos nombres (objetos) y los verbos (acciones) para crear una lista de objetos y acciones.

Una vez definidos los objetos y las acciones, que se han elaborado de manera iterativa, se organizan portipo. Se identifican objetos de destino, origen y aplicación.

Para construir una interfaz de usuario efectiva, “todo diseño debe empezar por la comprensión de quienes son los usuarios de destino, incluidos sus perfiles de edad, sexo, habilidades físicas, educación, antecedentes culturales o étnicos, motivaciones, objetivos y personalidad”.

El modelo MVC de interacción con el usuario

Un objeto origen (como el icono de un informe) se arrastra y coloca en un objeto de destino (por ejemplo, un icono de impresora). La implicación de esta acción es crear un informe impreso. Un objeto de aplicación representa datos específicos de la aplicación que no se manipulan directamente como parte de la interacción con la pantalla. Por ejemplo, en una lista de correo se almacenan nombres para un envío de correspondencia.

La propia lista podría ordenarse, combinarse o purgarse (acciones de menú), pero no arrastrarse ni colocarse mediante interacción del usuario. Una vez que el diseñador queda satisfecho con un objeto importante y que se han definido las acciones (para una iteración de diseño) se realiza el formato de la pantalla. Como otras actividades dediseño de la interfaz, el formato de la pantalla es un proceso interactivo; en él se elabora el diseño gráfico y se colocan los iconos, la definición de texto descriptivo en pantalla, la especificación y la asignación de nombres a las ventanas, además de la definición de los elementos primarios y secundarios de los menús. Si una metáfora de la realidad es apropiada para la aplicación, se especifica en este momento, y el diseño se organiza de manera tal que satisfaga lametáfora. A continuación se presenta un caso de estudio preliminar (escrito por el propietario) para la interfaz.Caso de uso preliminar: Quiero tener acceso a mi sistema Hogar Seguro desde cualquier lugar remoto vía internet. Empleando software de navegador que opera en mi notebook (mientras estoy trabajando o viajando) puedo determinar el estado del sistema de alarmas, armar o desarmar el sistema, reconfigurar zonas de seguridad y ver diferentes habitaciones de la casa con las cámaras de video preinstaladas.

Para tener acceso a Hogar Seguro desde un lugar remoto proporciono una identificación y una contraseña. Estos elementos definen los niveles deacceso (por ejemplo, no todos los usuarios pueden reconfigurar el

sistema ni proporcionar seguridad). Una vez validado, puedo revisar el estatus del sistema y cambiarlo al armar o desarmar Hogar Seguro. Puedoreconfigurar el sistema al desplegar un plano de la casa, ver cada uno de los sensores de seguridad, desplegar cada zona configurada actualmente y modificar zonas de acuerdo con las necesidades. Puedo verel interior de la casa con las cámaras de video colocadas de manera estratégica. Puedo hacer acercamientos y desplazamientos con las cámaras para proporcionar diferentes vistas del interior.

Con base en este caso de uso se identifican las tareas del propietario,los objetos y los elementos siguientes:

* Tiene acceso al sistema Hogar Seguro* Ingresa un ID y una contraseña para acceso remoto* Revisa el estatus del sistema* Arma o desarma el sistema Hogar Seguro* Despliega el plano de la casa y las ubicaciones de los sensores* Despliega zonasen el plano de la casa* Cambia zonas en el plano de la casa* Despliega ubicaciones de las cámaras de video o el plano de la casa* Selecciona visualmente una cámara de video* Ve imágenes de video* Desplaza o acerca las cámaras de video

Los objetos (en negritas) y las acciones (en cursivas) se extraen de lalista de tareas del propietario. La mayor parte de los objetos indicados son objetos de la aplicación. Sin embargo, ubicación de las cámaras de video (un objeto de origen) se arrastra y coloca en cámara de video (un objeto de destino) para crear una imagen de video (una ventana que contiene el desplegué de video).Se crea un boceto preliminar del formato de la pantalla para el monitoreo de video. La imagen de video se solicita seleccionando un icono de ubicación de las cámaras de video, C, localizado en el plano de la casa desplegado en la ventana de monitoreo. En este caso, se arrastra la ubicación de una cámara de video en la sala, SA, y se coloca sobre el icono de cámara de video ubicado en la parte superior izquierda de la pantalla. Aparecerá la ventana de imagen de video, desplegando video de flujo continuo proveniente de la cámara ubicada enla sala (SA). Los controles deslizables de acercamiento y desplazamiento se emplean para controlar la ampliación y la dirección

de la imagen del video. Para seleccionar una vista de otra cámara, el usuario simplemente arrastra y coloca un icono de ubicación de cámara diferente en el icono de la cámara emplazado en la esquina superior izquierda de la pantalla.

El boceto del formato que se muestra tendría que complementarse con unaexpansión decada elemento de menú dentro de la barra de menús, indicando cuales acciones están disponibles para el modo de monitoreo de video (estado). Durante la etapa de diseño de la interfaz se crearíaun conjunto completo de bocetos para cada tarea de propietario anotada en el escenario del usuario.

EJEMPLO:

Un escenario de interacción en una biblioteca.

Jane es una estudiante de estudios religiosos que está preparando una redacción sobre la arquitectura india y cómo ésta ha estado influida por las costumbres religiosas. Para ayudarle a entender esto, le gustaría acceder a imágenes de detalles de edificios notables, pero no pueden encontrar nada en su biblioteca loca. Se acerca al bibliotecario para exponerle sus necesidades y éste le sugiere términos de búsqueda que podría utilizar. También le siguiere bibliotecas en Nueva Delhi y Londres que podrían tener este material, por lo que entran en catálogos y de la biblioteca y buscan utilizando estos términos. Encuentran algunas fuentes de material y hacen una petición de fotocopias de las imágenes con los detalles arquitectónicos, para que se las envíen directamente a Jane.

BIBLIOGRAFIA:http://itsaisc60.files.wordpress.com/2009/09/unidad-4-de-planificacion-y-modelado.pdf

CONCLUSIONES

En este trabajo se analiza el concepto de requerimiento, se enfatiza enla cuestión de análisis de requerimientos y todos los aspectos que se necesitan para su creación.Hablamos sobre requerimientos de sistema y de usuario, de sus diferentes niveles de de especificación del sistema. Aprendimos sobre

los requerimientos funcionales y los no funcionales; los funcionales definenlas funciones que el sistema será capaz de hacer y los no funcionales son las características que limitarían al sistema.Se analiza que los requerimientos deben ser Necesarios, Concisos, Completos, Consistentes, ambiguos y No Verificables. También existen los requerimientos de dominio estos provienen del dominio de la aplicación del sistema y reflejan características y restricciones de esas habilidad de dominarlo. Los casos de uso es una técnica que se base en escenarios para obtener los requerimientos, un caso de uso identifica el tipo de interacción y los actores involucrados.Los casos de uso no son parte del diseño, si no parte del análisis, conesto nos ayuda a describir que es lo que el sistema debe hacer. Los casos de uso son qué hace el sistema desde un punto de vista del usuario, describen un uso del sistema y como interactuará el usuario con este.Vimos que en el diseño de la interfaz de usuario es una actividad que involucra a varias ramas del diseño y el conocimiento como el diseño gráfico, su objetivo es que las aplicaciones y los objetos sean más atractivos y además hace que la interacción con el usuario sea lo más intuitiva posible. Las reglas para diseñar adecuadamente una interfaz de usuario son dar el control al usuario, reducir la carga en la menoría del usuario y lograr que la interfaz sea consistente.Dado que los usuarios están divididos en principiantes, usuarios esporádicos y con conocimientos, usuarios frecuentes y con conocimientos. Se debe pensar en realizar una interfaz que cubra estos perfiles o bien una interfaz para cada tipo de usuario con estos distintos perfiles.

Planificacion y Modelado 09 04 2012

Documents