Descrip C I On Conceptual 2008

Universidad de Costa Rica
Escuela de Ciencias de la Computacin e Informtica
GUA PARA ELABORAR LA DESCRIPCIN CONCEPTUAL DE UN PROYECTO DE SOFTWARE
Autora: Prof. Gabriela Salazar Bermdez
II Semestre 2008
Tabla de contenido
Introduccin ____________________________________________________________ 1 Captulo 1: Gua para elaborar la Descripcin Conceptual del Sistema _________ 4
1.1. Contenido del Documento de Descripcin Conceptual (DC)___________________ 4
1.1.1 Portada _______________________________________________________________________ 4 1.1.2 Hoja de Aprobacin _____________________________________________________________ 4 1.1.3 Tabla de Contenidos_____________________________________________________________ 5
1.2. Introduccin _____________________________________________________________ 5

1.2.1 Propsito del Documento _________________________________________________________ 5 1.2.2 Definiciones, Acrnimos, y Abreviaciones ___________________________________________ 6 1.2.3 Referencias Bibliogrficas ________________________________________________________ 6
1.3. Descripcin Conceptual del Sistema ________________________________________ 6

1.3.1 Diagnosticar la Situacin Actual ___________________________________________________ 6 1.3.2 Definir los Requerimientos del Sistema ______________________________________________ 7 1.3.3 Delimitar el Alcance del Sistema __________________________________________________ 8 1.3.4 Identificar Supuestos y Restricciones del Sistema _____________________________________ 9 1.3.5 Definir los Requerimientos del Usuario ______________________________________________ 9
1.4. Estudio de Factibilidad___________________________________________________ 11

1.4.1 Costos _______________________________________________________________________ 12 1.4.2 Beneficios____________________________________________________________________ 12 1.4.3 Conclusiones _________________________________________________________________ 13
Captulo 2: Tcnicas para Extraccin de Requerimientos _____________________ 14 Captulo 3: Proceso de Estimacin ________________________________________ 18
3.1 Estimar el Tamao del Producto ___________________________________________ 18
3.1.1 Componentes del Anlisis de Puntos de Funcin______________________________________ 18 3.1.2 Obtencin de los Puntos de Funcin Sin Ajustar ______________________________________ 21 3.1.3 Ajustar los Puntos de Funcin ____________________________________________________ 22
3.2 Estimar el Esfuerzo_______________________________________________________ 29

3.2.1. Enfoques de Estimacin del Esfuerzo ______________________________________________ 30 3.2.2 Estimacin Consolidada del Esfuerzo ______________________________________________ 30 3.2.3 Estimacin Indicativa del Esfuerzo ________________________________________________ 31
3.3 Estimar la Duracin ______________________________________________________ 33
Referencias Bibliogrficas ________________________________________________ 34
Introduccin
Este estndar contiene una gua para realizar la etapa de factibilidad y describir conceptualmente un proyecto de software, que permita evaluar su viabilidad e iniciar formalmente su desarrollo. El producto de software obtenido despus de seguir esta gua es conocido como Descripcin Conceptual y precisamente sirve para formalizar la existencia del proyecto y proveer a su administrador, autoridad para aplicar recursos organizacionales. Este documento tambin es conocido como el Project Charter segn el PMBOK Guide 2000 Edition. Como se puede observar en la figura 1, con base en el documento Descripcin Conceptual (o Project Charter) se puede dar la decisin de arranque, es decir se puede decidir si continuar o no el desarrollo del sistema. [1]
Instalacin sustancialmente completa Operacin completa/ Entrega definitiva
Avance
Decisin de arranque
Contratacin mayor
se a ba e n L
+/- 40% Etapa 1 Etapa 2 Factibilidad Planeacin
Etapa 3 Etapa 4 Desarrollo Implantacin

Produccin Entrega Instalacin Prueba Prueba final Mantenimiento
Inicio Formulacin
Costo y cronograma Estudio Factibilidad Trminos contrato Aprobacin Descripcin Conceptual Plan Project Charter (PMI)
Figura 1. Fases de un proyecto y su ciclo de vida [1] El camino hacia la calidad del software comienza con una excelente extraccin de requerimientos. Realizar esta tarea superficialmente es una causa comn en el fracaso de un proyecto de software. Si no se logra una buena obtencin de los requerimientos existe una gran probabilidad de que se introduzcan errores, que por lo general se descubren tarde en el proceso, con frecuencia tan tarde como en la entrega. Karl Wiegers en [9] indica que los tres factores que ms contribuyen al fracaso de los proyectos de software son: ausencia del usuario, requerimientos y especificaciones incompletas, y requerimientos y especificaciones cambiantes. Y para evitar toda confusin en los requerimientos, l nos recomienda reconocer tres niveles de requerimientos los cuales se muestran en la siguiente figura:
Gua para Elaborar la Descripcin Conceptual del Sistema. Fecha de creacin: 30/08/2009.
Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.
Requerimientos Del Negocio
Descripcin Conceptual
Requerimientos Del Usuario Casos de Uso Atributos de Calidad
Requerimientos Funcionales
Requerimientos No Funcionales
Especificacin de Requerimientos del Software
Figura 2: Tres niveles de Requerimientos de software [9] En el nivel superior estn los requerimientos del negocio (identificados en este documento como requerimientos del sistema). A este tipo de requerimiento se hace referencia en la seccin 1.3.2 de este documento. El segundo nivel se refiere a los requerimientos del usuario y se hace referencia a ellos en la seccin 1.3.5 de este documento. Debido a que esta gua sirve especficamente para la fase de factibilidad y que en las primeras etapas del ciclo de vida de un sistema, la informacin es escasa, los requerimientos del usuario capturados en los Casos de Uso se describirn para esta fase en formato de alto nivel tal y como lo recomienda Larman en [11, pg. 56]. Sin embargo, los Casos de Uso obtenidos en esta primera etapa del ciclo de vida, servirn de base para que en la fase de anlisis se contine recabando informacin sobre los requerimientos y se describan en formato expandido. El tercer nivel en la figura 1 corresponde a los requerimientos funcionales del software, los cuales junto con los requerimientos no funcionales y los atributos de calidad conforman el documento Especificacin de Requerimientos, que est fuera del alcance de este documento. Como complemento a la recomendacin de Karl Wiegers respecto a los tres niveles de requerimientos, en el captulo 2 se describen diferentes tcnicas para realizar la tarea de extraccin de requerimientos. Segn [1] con base en los requerimientos del usuario, para evaluar la viabilidad de un proyecto, se debera realizar una estimacin aproximada del tiempo de desarrollo y del total de costos del proyecto. De acuerdo a [12], una recomendacin para realizar dicha estimacin en una etapa tan temprana, en donde todava no hay suficiente informacin, es utilizar la tcnica de estimacin
del esfuerzo basada en los Casos de Uso, junto con la tcnica de Puntos de Funcin de Albrecht,79. El captulo 3 de este documento explica dicha metodologa. En la seccin 3.1 se describe el procedimiento para estimar el tamao del software, en la seccin 3.2 cmo derivar el esfuerzo con base en el tamao y en la seccin 3.3 se explica cmo estimar la duracin del proyecto. Esta informacin permitir determinar si el proyecto es factible de realizar. No es parte del alcance de este documento estimar el costo monetario del proyecto. Este costo vara dependiendo de la organizacin donde se realice, pero si es importante indicar; que si conocemos el valor monetario de un Punto de Funcin para la organizacin que desarrolla la aplicacin, lo nico que se debe hacer para obtener una estimacin aproximada de su costo, es multiplicar los Puntos de Funcin por dicho valor.
Captulo 1: Gua para elaborar la Descripcin Conceptual del Sistema

1.1. Contenido del Documento de Descripcin Conceptual (DC)
Esta seccin describe las partes que debe contener el documento Descripcin Conceptual y los procedimientos para elaborarlo. El documento DC debe incluir los puntos descritos en las secciones 2.1 a la 2.6 de este documento. 1.1.1 Portada Debe contener como mnimo la siguiente informacin: Nombre de la institucin, Tipo de documento (Descripcin Conceptual del Sistema), Nombre del sistema o mdulo del software (Sistema de Registro de Instalacin de Servidores), Nmero de versin (Versin 1.01). La figura 3 muestra un ejemplo de una portada de una DC.
UNIVERSIDAD DE COSTA RICA
Descripcin Conceptual del Sistema
Sistema de Registro de Instalacin de Servidores

Versin 1.1 Figura 3. Ejemplo de una portada de una DC.
1.1.2 Hoja de Aprobacin Debe contener como mnimo la siguiente informacin: Nombre de la institucin., los nombres y firmas de las personas que elaboraron y aprobaron la DC y la fecha de aprobacin. La Figura 4 muestra un ejemplo de una hoja de aprobacin de una DC.
UNIVERSIDAD DE COSTA RICA
Hoja de aprobacin Elaborado por: Juan Prez, Ligia Barboza Aprobado por:
Marta Brenes
Aprobado el 13 de mayo del 2005 Figura 4. Ejemplo de una hoja de aprobacin de una DC.
1.1.3 Tabla de Contenidos Todo documento de Descripcin Conceptual debe contener el siguiente formato en su tabla de contenido. Cada punto ser explicado en detalle a travs de este documento. Portada Hoja de Aprobacin Bitcora de Cambios Tabla de Contenido 1. Introduccin 1.1 Propsito del Documento 1.2 Definiciones, acrnimos y abreviaturas 1.3 Referencias bibliogrficas 2. Descripcin Conceptual del Sistema 2.1 Diagnosticar la Situacin Actual 2.2 Definir Requerimientos del Sistema 2.3 Delimitar Alcance del Sistema 2.4 Identificar supuestos y Restricciones 2.5 Definir Requerimientos del Usuario 3. Estudio de Factibilidad 3.1 Costos 3.2 Beneficios 3.3 Conclusiones
1.2. Introduccin El objetivo es guiar al lector sobre la naturaleza y estructura general del contenido del documento. Contiene tres sub-secciones descritas a continuacin. 1.2.1 Propsito del Documento Se describen los objetivos del documento y se definen claramente sus lectores, que generalmente son los usuarios del sistema a desarrollar y cualquier otro interesado en su desarrollo.
1.2.2 Definiciones, Acrnimos, y Abreviaciones Se deben definir todos los trminos, acrnimos, y abreviaciones que se utilicen en el resto del documento. 1.2.3 Referencias Bibliogrficas Se deben enumerar las referencias completas (ttulo, autor, fecha, editorial, etc.) de todos los documentos mencionados en el DC, as como cualquier otra documentacin complementaria que est relacionada. 1.3. Descripcin Conceptual del Sistema Para describir conceptualmente un sistema es necesario realizar las tareas que se muestran en la figura 5 y se describen en detalle en las secciones 1.3.1, 1.3.2, 1.3.3, 1.3.4 y 1.3.5.
Diagnosticar la Situacin Actual Diagnstico de la Situacin Actual Definir Requerimientos del Sistema Requerimientos del Sistema Delimitar Alcance del Sistema Alcance del Sistema Identificar Supuestos y Restricciones Supuestos y Restricciones Definir Requerimientos del Usuario Requerimientos del Usuario
Figura 5. Tareas para la Elaborar la Descripcin Conceptual del Sistema 1.3.1 Diagnosticar la Situacin Actual De acuerdo a [8, pg. 37] el objetivo de diagnosticar la situacin actual es describir el contexto de trabajo y la situacin que provoca un nuevo esfuerzo o un cambio en todo o parte de la aplicacin existente. Normalmente una organizacin maneja un plan estratgico que le permite dirigir sus esfuerzos. Como resultado, tenemos una serie de estrategias que se apoyan en proyectos especficos.
Esta tarea pretende identificar las causas por las que surge el proyecto. Algunas pueden ser: una idea o necesidad generada desde una o ms de las siguientes fuentes: Demanda de mercado. Solicitudes de clientes, usuarios. Necesidad del negocio. Ideas que provienen de la misma organizacin. Avances tecnolgicos. Requerimientos legales (pueden ser por legislacin, regulaciones, estndares nacionales e internacionales, mantenimiento, etc.)
En esta seccin se debe describir la fuente que genera los cambios que se estn proponiendo y para cada cambio propuesto, se deben describir las estrategias manuales y/o automatizadas que se estn llevando a cabo para enfrentarlos. Si la organizacin cuenta con un plan estratgico se debe documentar la relacin entre el sistema que se desea desarrollar y las necesidades del negocio de acuerdo a dicho plan. Si se cuenta con un portafolio de aplicaciones debe hacerse referencia a la prioridad establecida para este proyecto. 1.3.2 Definir los Requerimientos del Sistema Una vez diagnosticada la situacin actual, es necesario definir los requerimientos del sistema, tambin conocidos como objetivos o metas tcnicas del sistema. Estos requerimientos representan los objetivos de alto nivel de la organizacin o cliente, que solicitan el sistema o producto. Son las razones por las que el sistema se desarrollar, las cuales describen cmo se puede mejorar la organizacin a nivel general si existiera el nuevo producto. [8] y [9] Estos requerimientos se identifican mediante entrevistas con el usuario/cliente y deben ser aprobados por todos los interesados. Algunos posibles requerimientos del sistema para un posible Sistema de Instalacin de Servidores (denominado SIS) son: Documentar y estandarizar el proceso de instalacin de servidores. Realizar estimaciones ms realistas de los procesos de instalacin de servidores a partir de los histricos mantenidos por el sistema. Reducir la curva de aprendizaje del nuevo personal de soporte de servidores.
Cumplir con la recomendacin de Auditora Interna.
1.3.3 Delimitar el Alcance del Sistema El Sistema puede crecer de una manera incontrolable si no se definen sus fronteras. Para establecer las fronteras entre el sistema y su ambiente se deben especificar los sistemas externos y el personal con el que el sistema debe colaborar. Se identifican las personas y organizaciones activamente involucradas en el proyecto o aquellos cuyos intereses sern afectados poitiva o negativamente por el desarrollo del mismo. Esta informacin ayuda a determinar los participantes del proyecto. En etapas tempranas del desarrollo las fronteras pueden ser difusas porque el sistema no est claro. Comience indicando las fronteras con la informacin disponible y conforme desarrolla los Casos de Uso aprende ms del sistema y refina sus fronteras. Un Diagrama de Contexto es una herramienta til para documentar las fronteras entre el sistema y su ambiente. Consiste de un crculo y cajas conectadas por lneas y flechas. El crculo representa al sistema y las cajas representan cualquier cosa externa al sistema. Las lneas con flechas representan los flujos de datos entre el sistema y su ambiente. El Diagrama de Contexto el cual puede ser dibujado en UML (Lenguaje Unificado de Modelaje) como un Diagrama de Puesta en Marcha (Deployment), es un excelente punto de inicio para desarrollar el conjunto de Casos de Uso. [10] En la figura 6 se muestra la relacin del sistema SIS con los Departamentos de Sistemas, Ingeniera y Auditora Interna y con los funcionarios de la empresa. As mismo el SIS leer datos de los Sistemas de Empleados y Servidores que son administrados en otras aplicaciones.
Sistema de Empleados Departamento de Ingeniera
Auditora Interna
Sistema de Instalacin de Servidores (SIS)
Departamento de Sistemas
Funcionarios Empresa
Sistema de Servidores
Figura 6. Diagrama de Contexto para el Sistema de Instalacin de Servidores
1.3.4 Identificar Supuestos y Restricciones del Sistema Se deben enumerar y describir los supuestos y restricciones iniciales asociados con el alcance del proyecto que puedan afectar su desarrollo. [1] y [6] Los supuestos son factores que consideramos como verdaderos, reales o ciertos para efectos de planeacin y que tendrn que confirmarse a medida que avance el proyecto. Es decir se deben cumplir para que el proyecto proceda de acuerdo a lo planificado. Por ejemplo: horas de trabajo por semana, momento en se realizar determinada capacitacin, supuestos sobre el tipos de recurso que se necesita, disponibilidad y qu cantidad se utiliza. Las restricciones son condiciones que limitan las opciones del equipo de desarrollo y se deben satisfacer. Es necesario conocer las restricciones que nos da la organizacin en cuanto a: a. Presupuesto disponible o predefinido. b. Una fecha de conclusin impuesta emitida por la organizacin y fechas parciales de entrega. c. Restricciones contractuales si se est trabajando bajo contrato. d. Recursos disponibles: humanos, de equipo, de espacio, herramientas automatizadas y no automatizadas, etc. e. Restricciones de horarios de trabajo del personal y/o equipo. f. Entrega de materiales provenientes de fuentes externas. g. Apego a estndares de calidad. h. Presentacin de documentos, actividades peridicas de revisin. i. Ciclo de vida. 1.3.5 Definir los Requerimientos del Usuario En esta seccin se establece la correspondencia entre un enunciado del problema (identificado en los puntos anteriores), y los requerimientos del usuario, los cuales describen las tareas que ellos deben ser capaces de realizar usando el nuevo producto. Estos requerimientos son representados como un conjunto de Actores y Casos de Uso modelados con UML. [9] Refirase al captulo dos para obtener ms informacin sobre esta tcnica. Para formular los Requerimientos del Usuario se deben realizar las siguientes tareas: 1. Elaborar el diagrama de Casos de Uso. Se debe presentar el Diagrama Principal de Casos de Uso de la aplicacin a desarrollar. Si se tienen ms de 15 o 20 casos de uso es mejor listarlos. Modelar cada Caso de Uso de manera
10
individual en Rational Rose y adjuntar el archivo electrnico. Cada Caso de Uso deben tener un nmero y nombre que lo identifique. 2. Documentar los escenarios de los Casos de Uso en formato de alto nivel. Larman en [11, pg. 58] recomienda este tipo de formato cuando se estn comenzando a investigar los requerimientos, con el propsito de entender mejor el alcance del problema y las funciones necesarias. Este tipo de casos permite captar la esencia del proceso y sus motivos fundamentales, debido a su brevedad y abstraccin, posponiendo los detalles de diseo (especialmente los relacionados con la interfaz del usuario), para despus. 3. Elaborar Modelo Conceptual: En esta fase no se debe profundizar mucho en este modelo porque el propsito no es llevar a cabo un estudio serio, sino decidir si merece la pena un estudio ms profundo en el proyecto. Para elaborarlo se deben identificar las clases conceptuales a nivel de toda la aplicacin, incorporar las asociaciones e ir descubriendo los primeros atributos. 4. Identificar y listar los requerimientos no funcionales. Los requerimientos funcionales son acciones que el producto debe ejecutar. Generalmente responde a objetivos del negocio. Ej: Reducir gastos, Controlar inventario. Los requerimientos no funcionales son las propiedades de comportamiento que debe tener el producto resultante. Estn relacionado con las caractersticas de calidad como modificable, seguro, portable, confiable, verificable y fcil de usar. 5. Asignar a cada Caso de Uso una prioridad relativa de implementacin. Los usuarios deben compartir la responsabilidad de asignar esa prioridad. Cuando las expectativas y los recursos son limitados, el usuario/cliente necesita estar seguro de que el producto contiene las funciones esenciales [6]. Generalmente, la secuencia en la que el usuario identifica los Casos de Uso candidatos sugiere una prioridad aproximada. La prioridad de implementacin de un Caso de Uso est en funcin del valor provisto por el cliente, del costo relativo de implementacin y de los riesgos tcnicos relativos asociados con la implementacin. Hay tres niveles de prioridad segn [4, pg. 162] y [6, pg. 2] los cuales se presentan en la siguiente tabla: Tabla 1. Significado de las prioridades de los requerimientos.
Prioridad Alta esencial Significado o Requerimiento crtico, el producto no es aceptable si no se satisface en esta versin. Debe demostrarse en forma satisfactoria durante la aprobacin del cliente.
Media o El requerimiento puede mejorar el producto, pero no es inaceptable si est condicional ausente, puede esperar una siguiente versin, si se necesita. Debe tomarse en cuenta en el diseo del sistema y en el diseo de objetos.
11
Baja u Se refiere a una mejora en la funcionalidad o en la calidad. Ilustra la manera opcional en que podra ampliarse el sistema a largo plazo. Podra ser bueno tenerlo algn da si los recursos lo permiten.
En las tablas 2 y 3 se muestran ejemplos de dos requerimientos agrupados en forma lgica, con su prioridad asignada. El primer requerimiento es el Mantenimiento Software y el segundo es el Mantenimiento DetallesOrden. Estas tablas tienen tres columnas: la primera identifica el nmero de requerimiento, la segunda lo describe brevemente y la tercera indica su prioridad. Tabla 2. Ejemplo del requerimiento funcional nmero 1 priorizado.
N o. R 1-1 R 1-2 R 1-3 R 1-4 R 1-5 D escrip cin : M an ten im ien to S oftw are In cluir nuev o softw are y nuevas versiones d el m ism o M odificar caractersticas d e softw are ya incluid o. B orrar softw are que ya no se utilice en la em presa L istar el softw are utilizad o, con la posibilid ad de filtrar inform acin E nviar por correo lista d e softw are a XX X P riorid ad A lta A lta A lta A lta B aja
Tabla 3. Ejemplo del requerimiento funcional nmero 2 priorizado.

No. R2-1 R2-2 . R2-n-1 R2- n Descripcin : Mantenimiento Detalles Orden Incluir datos iniciales sobre el detalle de la orden de trabajo a realizar Modificar caractersticas de un detalle particular .. Listar el detalle de una orden de trabajo en particular. Posibilidad de definir formatos de impresin Prioridad Alta Alta . Alta Baja
1.4. Estudio de Factibilidad Se debe efectuar un anlisis de costos y beneficios esperados para valorar y justificar el desarrollo del sistema. Para realizar dicho estudio es necesario conocer las restricciones identificadas en la seccin 2.5.4 de este documento para analizar la conveniencia de desarrollar el sistema completo, desarrollar una parte o contratar su desarrollo.
12
A continuacin se presentan los posibles rubros de costos y beneficios que se deben considerar: 1.4.1 Costos Son aquellos recursos que se deben invertir para desarrollar el sistema. Algunos ejemplos son: Presupuesto y tiempo estimado para desarrollar el sistema. Para obtener una estimacin aproximada del presupuesto y cronograma del proyecto es necesario estimar el tamao del proyecto y a partir de ste, el esfuerzo requerido para desarrollarlo. En el captulo 2 de este documento se explica la metodologa para estimar el tamao, el esfuerzo y la duracin del proyecto. Uso de recursos humanos y tecnolgicos. Inversin de capital requerido como: equipo de hardware, software de desarrollo. Recursos invertidos para evitar la resistencia al cambio por parte del usuario.
1.4.2 Beneficios Los beneficios se pueden clasificar en dos categoras genricas que se combinan: tangibles/intangibles, y medibles y no medibles. 1. Tangibles y medibles: son aquellos beneficios que afectan la rentabilidad de la organizacin y pueden ser medidos objetivamente. Algunos ejemplos son: Reduccin de costos. Reduccin en activos. Aumento en ventas.
2. Tangibles y no medibles: son los beneficios que afectan la rentabilidad de la organizacin pero no se puede determinar con exactitud en qu medida la afectan. Habilidad para mantener mejor informacin. Mejora en el perfil de riesgo de la empresa. Mejora en la seguridad de la empresa.
13
3. Intangibles y medibles: son aquellos beneficios que pueden ser medidos con exactitud pero no necesariamente impactan la rentabilidad de la empresa Obtener informacin ms rpidamente. Proveer mayor satisfaccin al cliente. Mejorar la satisfaccin del personal.
4. Intangibles y no medibles: son los beneficios que no son cuantificables ni necesariamente impactan la rentabilidad de la organizacin. Mejor reaccin del mercado hacia la firma. Mejor percepcin de la organizacin. por parte del cliente de del producto empleados
Mejor percepcin por parte potenciales de la organizacin.
los
1.4.3 Conclusiones De acuerdo a los puntos anteriores se debe valorar la conveniencia institucional de realizar o no el sistema. Despus de hacer el anlisis de costobeneficio es justificado el desarrollo de los sistemas en donde la suma de los beneficios es mayor a la de los costos. Sin embargo, dependiendo del sistema y del plan estratgico, se puede justificar el desarrollo de un sistema aunque no sea rentable. La administracin debe tomar la decisin acerca de cmo responder a esto.
14
Captulo 2: Tcnicas para Extraccin de Requerimientos

De acuerdo a [3, cap. V] algunas tcnica que se pueden utilizar durante el proceso de extraccin de los requerimientos son: entrevistas, anlisis de documentos, lluvia de ideas, workshops de requerimientos (por ejemplo el Joint Application Development, JAD), Prototipado y Casos de Uso. A continuacin se explica cada una: 2.1 Entrevistas Frecuentemente la tcnica ms utilizada para acercar al cliente con el desarrollador es comenzar la comunicacin estableciendo una reunin o entrevista preliminar [5]. Gause y Weinberg sugieren que el analista comience haciendo preguntas de contexto libre, que permitan alcanzar un entendimiento bsico del problema, la naturaleza de la solucin que se desea y finalmente evaluar la efectividad de la reunin. Este tipo de preguntas ayuda a evitar respuestas prejuiciosas, debido a que no se pretende sugerir una solucin o respuesta particular, sino que se enfocan en la perspectiva del usuario. Hay tres conjuntos de preguntas de contexto libre que se presentan a continuacin: Primer conjunto de preguntas: Se centran en el cliente, en los objetivos globales y en los beneficios. Por ejemplo: A quin le interesa esta solucin? Quin la utilizar? Cul es la razn para querer resolver este problema? Hay otro camino para la solucin (que no sea automatizar)?
Segundo conjunto de preguntas: Permiten que el analista comprenda mejor el problema y que el cliente exprese sus percepciones sobre una solucin: Cmo se caracterizara un resultado correcto para generar una solucin satisfactoria? Qu problemas se pueden presentar ante esta solucin? Puede mostrar o describir el ambiente en que probablemente se utilizar esta solucin?
15
Hay aspectos o limitaciones especiales de rendimiento que afectarn la forma en que se est abordando la solucin?
Tercer conjunto de preguntas: Se centran en efectividad de la reunin. Gause y Weinberg proponen la siguiente lista: Sus respuestas son oficiales? Son relevantes mis preguntas? Hay alguien que pueda proporcionar informacin adicional? Hay algo ms que debiera preguntarle?
2.2 Anlisis de documentos Toda extraccin de requerimientos efectiva involucra algn nivel de anlisis de documentos Se analizan documentos tales como: planes del negocio, estudios de mercado, contratos, solicitudes de propuestas, definiciones de trabajo, guas existentes, anlisis de sistemas actuales y procedimientos.
2.3 Lluvia de ideas (Brainstorming) La lluvia de ideas es una tcnica que involucra la generacin y reduccin de ideas. La meta es identificar tantas ideas como sea posible, para posteriormente ordenarlas y considerar las ms importantes para el grupo. Esta es una tcnica poderosa, porque las ideas ms creativas y efectivas a menudo son el resultado de combinar ideas no relacionadas. Adems esta tcnica promueve un pensamiento original y la propuesta de ideas poco usuales. Se utiliza cuando hay usuarios con diferentes perspectivas o cuando hay conflictos entre los requerimientos. 2.4 Workshops de requerimientos
16
Esta es una tcnica poderosa en el proceso de extraccin de requerimientos porque pueden ser diseadas para fomentar el consenso de ciertos requerimientos en particular. Normalmente son dirigidas por un consultor externo y duran no ms de tres das. A menudo se logran otras ventajas como: un compromiso de los participantes en los productos de trabajo y el xito del proyecto, trabajo en equipo, se solucionan problemas polticos y se logra consenso sobre tpicos organizacionales. Algunos beneficios de los workshops son: A menudo los costos son menores que mltiples entrevistas. Ayudan a estructurar el proceso de captura y anlisis de requerimientos. Es un proceso dinmico, interactivo y cooperativo. Involucra a usuarios y cruza fronteras organizacionales. Identifica y prioriza controversiales. necesidades y resuelve problemas
Administra las expectativas del usuario y las actitudes al cambio.
Una categora especial de workshops es el JAD (Joint Application Development). JAD es un mtodo para obtener requerimientos a travs de los clientes,los representantes de usuarios y los desarrolladores, que trabajan junto con un facilitador, para producir una especificacin que apoye ambas partes. Es una forma de definir tempranamente las necesidades del usuario. 2.5 Prototipado El prototipado es una tcnica para construir una versin rpida y aproximada del sistema deseado o parte del sistema. Hay dos tipos: el desechable en donde se conoce el problema o su solucin y se descarta despus de obtenido el conocimiento, y el evolutivo en el cual una vez que el conocimiento es obtenido, el prototipo se adapta hasta satisfacer todas las necesidades y desarrollar el sistema real. Como herramienta para extraer requerimientos se recomienda que el prototipo incluya: pantallas, filtros, reportes, navegacin e interaccin con el usuario. El prototipo no debe implementar: manipulacin de las bases de datos, validaciones de campos, ni implementacin de procesos y reportes. Los prototipos pueden ser combinados efectivamente con otros enfoques tales como JAD y otros modelos. 2.6 Casos de Uso
17
Es un instrumento para estimular a usuarios potenciales a hablar de un sistema desde su propio punto de vista. Proporcionan un medio para obtener los requerimientos de un sistema en desarrollo. Describen el sistema, su ambiente y las relaciones entre el sistema y su ambiente. De acuerdo a [11, pg. 49] los Casos de Uso no son los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen tcitamente los requerimientos en las historias que narran. Los Casos de Uso deben complementarse con caractersticas de interfaces y de calidad. El Diagrama de Casos de Uso es una descripcin grfica de las acciones que debe realizar el sistema que muestra a los actores y los casos de uso identificados para este sistema. Normalmente un diagrama de Casos de Uso contiene: los Casos de Uso, los Actores y las relaciones, tal como se muestra en la figura 7.
Caso de Uso 1
Relacin
Actor
Caso de Uso 2
Actor
Figura 7. Diagrama de un Caso de Uso
Un Actor es una entidad externa del sistema que de alguna manera participa en la historia del Caso de Uso, tpicamente representa a un usuario humano o a otro sistema que interacta con el sistema bajo anlisis. [11, pg. 52] Cada Caso de Uso debe ir acompaado de una descripcin textual que describe un escenario en el cual el usuario interacta con el sistema bajo anlisis, para lograr una meta especfica o realizar una tarea particular. Esta descripcin debe estar contenida en un documento llamado Especificacin del Caso de Uso. Este documento y los diagramas de Casos de Uso facilitan la comunicacin del equipo, ya que proveen un contexto para expresar los requerimientos como una secuencia de eventos, utilizando un lenguaje comn (no en trminos de implementacin) entre usuarios y equipo tcnico. Esta secuencia de eventos debe ser escrita en trminos de lo qu debera hacer el sistema y no cmo lo hace. [14, pg. 29] La documentacin de los escenarios tpicamente se realiza en la fase de conceptualizacin del producto de una manera iterativa. Al principio, solamente se puede escribir una breve descripcin de los pasos necesarios para realizar el Caso de Uso. Conforme se progresa en el anlisis los pasos se detallan ms. Finalmente se agregan los flujos excepcionales.
18
Captulo 3: Proceso de Estimacin

Segn McConnell en [13, cap. 8] el proceso para crear una planificacin de desarrollo consta de tres pasos: 1. Estimar el Tamao del Producto. 2. Estimar el Esfuerzo. 3. Estimar la Duracin. 3.1 Estimar el Tamao del Producto Para una estimacin efectiva de la duracin se necesita antes estimar el tamao del software. En esta seccin se explica la metodologa para estimar el tamao del software con base en los Casos de Uso y utilizando el Anlisis de Puntos de Funcin de Albrecht,79. Existe una relacin natural entre los Puntos de Funcin y los Casos de Uso. Los Puntos de Funcin permiten estimar el tamao del software a partir de sus requerimientos, mientras que los Casos de Uso permiten documentar los requerimientos del software. Aplicando el Anlisis de Puntos de Funcin a los Casos de Uso, se podr obtener una estimacin general del tamao y a partir de ella el esfuerzo. Esta estimacin es una aproximacin, debido principalmente a la escasa informacin que se tiene sobre el software al principio de un proyecto, pero permitir obtener una idea del esfuerzo necesario, con el fin de analizar la viabilidad del proyecto. El objetivo de esta tcnica es identificar a partir de los Casos de Uso los Archivos de datos que se requiere procesar y las Transacciones que procesan los datos. Para facilitar la comprensin de esta tcnica, en la seccin 3.1.1 se describen ambos componentes (Archivos y Transacciones). En la seccin 3.1.2 se explica cmo obtener los Puntos de Funcin Sin Ajustar con base en esos dos componentes, y en la seccin 3.1.3 cmo ajustarlos para obtener los Puntos de Funcin finales. 3.1.1 Componentes del Anlisis de Puntos de Funcin 1. Transacciones: Los Casos de Uso corresponden al concepto de transacciones planteado por la definicin de Puntos de funcin. Sin embargo no hay una relacin de uno a uno entre ambos, es decir un Caso de Uso podra ser contado como una o ms transacciones, dependiendo de las tareas que realice. Pero en general, el conjunto de Casos de Uso equivale al conjunto de transacciones candidatas. Para este anlisis se requiere el diagrama de Casos de Uso y sus especificaciones (mnimo en formato de alto nivel). En la especificacin de un Caso de Uso, se utiliza un
19
escenario principal para relatar la secuencia de pasos entre el Actor y el sistema, y escenarios alternativos para relatar las condiciones que se apartan del flujo normal de eventos. Una transaccin est representada por uno o ms pasos del flujo de eventos principal del Caso de Uso, pudiendo existir ms de un transaccin dentro del mismo Caso de Uso. Los flujos de eventos alternativos ayudan a clarificar las transacciones. Para identificar las transacciones se van a aplicar las siguientes reglas: 1. Los Casos de Uso son transacciones si desarrollan funcionalidad para el usuario 2. Cada caso de uso que tenga relacin directa con un Actor va a ser candidato para una o ms transacciones. 3. Un Caso de Uso puede ser extendido o puede usar otro Caso de Uso. Los Casos de Uso que extienden (tipo de relacin extiende) a un Caso de Uso candidato es tambin candidato. 4. Un Caso de Uso usado (tipo de relacin usa) no se cuenta como una transaccin. 5. Los Casos de Uso vinculados exclusivamente al entorno no se toman en cuenta (ejemplo: almacenar en una base de datos). En relacin a los Puntos de Funcin, las transacciones se clasifican de la siguiente manera: 1. Entradas Externas (EI, External Inputs en ingls): Se definen como un proceso elemental mediante el cual ciertos datos cruzan la frontera del sistema desde afuera hacia adentro. El Actor del Caso de Uso provee datos al sistema, lo cuales pueden tratarse de informacin para agregar, modificar, eliminar, asignar o evaluar alguna entidad del sistema, o bien informacin de control o del negocio. Ejemplo: Podemos tener Un Caso de Uso que documente el mantenimiento de alguna entidad del sistema, por ejemplo el mantenimiento de empleados, el cual est constituido por tres escenarios: una inclusin, una modificacin y una exclusin. Cada uno de estos escenarios representa una pantalla o entrada externa (EI). De igual forma si tenemos tres Casos de Uso, en donde cada uno describe el escenario de inclusin, modificacin y exclusin, tenemos tres pantalla o entradas externas (3 EI). 2. Salidas Externas (EO, External Outputs en ingls): Se definen como un proceso elemental con componentes de entrada y salida mediante el cual datos simples y derivados cruzan la frontera del sistema desde adentro hacia afuera.
20
Los datos derivados se calculan a partir de otros datos a travs de alguna frmula matemtica. Adicionalmente, las Salidas Externas pueden actualizar alguna entidad del sistema. Los datos crean reportes o archivos que se envan hacia el Actor del Caso de Uso (que puede ser humano u otro sistema). Estos reportes y archivos se crean desde una o ms entidades. Ejemplo: Se pueden catalogar como Salidas Externas los Casos de Uso que documentan reportes o estadsticas que genera el sistema para el uso de los Actores. La informacin que sale del sistema consiste fundamentalmente de datos calculados a partir de otros datos de una o ms entidades. Un ejemplo podra ser un Caso de Uso que genere un reporte de la cantidad de empleados que se incluyeron en un perodo de tiempo. El actor indica el rango de fechas y el sistema genera el reporte. Desde el punto de vista de Puntos de Funcin, este Caso de Uso es una Salida Externa (EO). 3. Consultas Externas (EQ, External Inquiries en ingls): Se definen como un proceso elemental con componentes de entrada y salida donde un Actor del sistema recupera datos de uno o ms entidades. Los datos de entrada para hacer la recuperacin no actualizan ni mantienen ningn archivo y los datos de salida no contienen datos derivados (es decir, los datos de salida son bsicamente los mismos que se obtienen de las entidades). Dentro de este tipo de transaccin estn los listados y las bsquedas. Ejemplo: Se puede catalogar como Consulta Externa un Caso de Uso que describa la bsqueda de empleados. Desde el punto de vista de Puntos de Funcin, este Caso de Uso es una Consulta Externa (EO). 2. Archivos: En relacin a los casos de Uso, los archivos estn representados por las descripciones de almacenamiento de datos dentro del Caso de Uso, los cuales pueden ser archivos, bases de datos u otro tipo de almacenamiento. En relacin a Puntos de Funcin los archivos se clasifican de la siguiente manera: 1. Archivos Lgicos Internos (ILF, Internal Logical Files en ingls): Son un grupo de datos relacionados lgicamente e identificables por el usuario, que se almacenan completamente dentro de los lmites del sistema y se mantienen a travs de la Entradas Externas o EI que se explican ms adelante. Ejemplo: Los Casos de Uso que estn relacionados con el mantenimiento (inclusiones, modificaciones y exclusiones) de entidades, lo cual est indicando la presencia de Archivos Lgicos Internos. Retomando el ejemplo de mantenimiento de empleados
21
en el que se documentaban tres escenarios, uno para inclusin, otro para modificacin y otro para exclusin de empleados se tiene un Archivo Lgico Interno (ILF) que es el que almacena la informacin de los empleados. 2. Archivos de Interfaz Externos (EIF, External Interface Files en ingls): Son un grupo de datos relacionados lgicamente e identificables por el usuario, que se utilizan solamente para fines de referencia. Los datos estn almacenados completamente fuera de los lmites del sistema y se mantienen por las Entradas Externas (EI) de otras aplicaciones, es decir, cada Archivo de Interfaz Externo (EIF) es un Archivo Lgico Interno (ILF) de otra aplicacin. Ejemplo: Si tenemos un Caso de Uso que como parte de alguna de sus secuencias de pasos indica que el sistema debe consultar informacin de alguna base de datos externa (administrada por otra aplicacin), esta es una seal de que existe por lo menos un Archivo de Interfaz Externo (EIF). Como complemento a esta tcnica, para muchos proyectos adems de los Casos de Uso se desarrolla el modelo de objetos del dominio, el cual generalmente, identifica los conceptos de datos relevantes para el dominio de la aplicacin. En este modelo los objetos se tipifican como objetos de entidad, de interfaces y de control. Los objetos de entidad de este modelo corresponden a los archivos de PF. Si se cuenta con este modelo cada objeto de tipo entidad es un candidato a ser archivo de datos. 3.1.2 Obtencin de los Puntos de Funcin Sin Ajustar Con la informacin obtenida en las transacciones (EI, EO y EQ) y en los archivos (ILF y EIF) identificados en los Casos de Uso se puede efectuar una estimacin inicial del tamao en Punto de Funcin, asumiendo que todas las transacciones identificadas tienen una complejidad media. El valor estimado de archivos y de transacciones se debe incluir en las filas correspondientes de la tabla 2 y se le debe aplicar el peso de la complejidad, obteniendo as los Puntos de Funcin Sin Ajustar. Conforme avanza el anlisis y se obtenga ms informacin de los requerimientos, se podrn detallar los Archivos de datos y las Transacciones y clasificar su complejidad en alta, media y baja. Se recomienda entonces utilizar las reglas de conteo explicadas en [16] para actualizar la estimacin de los Puntos de Funcin.
22
Tabla 2. Tabla de Pesos. Complejidad Componentes Archivos Lgicos Internos (ILF) Archivos de Interfaz Externos (EIF) Entradas Externas (EI) Salidas Externas (EO) Consultas Externas (EQ) Media X10 X7 X4 X5 X4 Total
Total de Puntos de Funcin Sin Ajustar (PFSA) Una vez que se han obtenido los Puntos de Funcin Sin Ajustar a partir de los Casos de Uso, se deben ajustar a travs de catorce caractersticas generales del sistema, tales como: comunicacin de datos, entrada de datos el lnea, rendimiento, facilidad de instalacin, etc.. A continuacin se explica el procedimiento para ajustarlos. 3.1.3 Ajustar los Puntos de Funcin El Anlisis de Puntos de Funcin plantea el ajuste de los Puntos de Funcin sin Ajustar a partir de las Transacciones y Archivos de datos, mediante la evaluacin de 14 caractersticas generales del sistema. A cada una de esas caractersticas se le asigna un factor de peso que indica la importancia de la caracterstica para el sistema bajo anlisis. El peso del valor asignado a cada caracterstica es el siguiente: 0 1 2 3 4 5 Factor no presente o sin influencia Influencia incidental Influencia moderada Influencia media Influencia significativa Influencia fuerte a tener en
A continuacin se describen las 14 caractersticas generales cuenta:
23
Tabla 3. Tabla de las 14 caractersticas Generales Caractersticas

1. Comunicacin de Datos Es el grado en que los datos y la informacin de control usados en la aplicacin, son enviados o recibidos a travs de las facilidades de comunicacin.
Descripcin
0 La aplicacin es procesamiento en lote puro o solo PC. No hay interactividad. 1 La aplicacin es en lote pero tiene capacidad de ingreso remoto o de impresin remota. 2 La aplicacin es en lote pero tiene capacidad de ingreso remoto y de impresin remota. 3 La aplicacin incluye un conjunto de datos en lnea o teleprocesamiento (TP) front-end hacia un proceso en hacia un proceso en lote o sistema de consulta. Son aplicaciones que tienen pantallas de entrada de datos front-end, pero actualizan archivos lgicos internos a travs de un procesamiento en lote. 4 La aplicacin es ms que un front-end, pero soporta solo un tipo de protocolo de comunicacin TP. Igual que 3 pero la actualizacin ocurre interactivamente. 5 La aplicacin es ms que un front-end, pero soporta ms de un tipo de protocolo de comunicacin TP. Por lo general las aplicaciones en lote reciben un peso de 0 a 3, en lnea de 3 a 4 y en tiempo real, telecomunicacin o sistemas de control de procesos reciben de 4 a 5.
2. Procesamiento de Distribuido de Datos Es el grado en que una aplicacin transfiere datos entre los componentes de la aplicacin.
0 La aplicacin no soporta la transferencia de datos o funciones de procesamiento entre los componentes del sistema. Totalmente monoltica. 1 La aplicacin prepara los datos para que el usuario los procese en otro componente del sistema, tal como una hoja electrnica o un BBMS en una PC. 2 La aplicacin prepara los datos para transferirlos, entonces son transferidos y procesados sobre otro componente del sistema (no para procesamiento de usuario final). 3 El procesamiento es distribuido y la transferencia de datos es en lnea y en una sola direccin. 4 El procesamiento es distribuido y la transferencia de datos es en lnea y en ambas direcciones. 5 Las funciones de procesamiento son dinmicamente ejecutadas en muchos componentes del sistema. Solo las aplicaciones distribuidas o en tiempo real tienen peso. Las distribuidas primitivas pueden ser 1 0 2. Las de cliente-servidor o Web son de 2 a 4. Un peso de 5 puede asignarse cuando son mltiples servidores o procesadores, cada uno de los cuales se ha seleccionado dinmicamente sobre la base de disponibilidad en tiempo real.
3. Rendimiento
0 No hay requerimientos de rendimiento especiales indicados por el
24
Es el grado en que el tiempo de respuesta y consideraciones de rendimiento influyen en el desarrollo de la aplicacin. Los objetivos de rendimiento son indicados o aprobados por el usuario en respuesta al diseo, desarrollo, instalacin y soporte de la aplicacin.
usuario. 1 Los requerimientos de rendimiento y diseo fueron indicados y revisados por el usuario pero no se requieren acciones especiales. El retraso en el procesamiento se deja para el siguiente da comercial. 2 El tiempo de respuesta es crtico durante las horas pico pero no se requiere un diseo especial para la utilizacin del CPU. 3 El tiempo de respuesta es crtico durante todas las horas comerciales, pero no se requiere un diseo especial para la utilizacin del CPU. Los requerimientos en el retraso de procesamiento se consideran como restricciones. 4 Adems, los requerimientos de rendimiento indicados por el usuario son lo suficientemente crticos como para realizar anlisis del rendimiento durante el diseo. 5 Adems, las herramientas de anlisis de rendimiento fueron utilizadas durante el diseo, el desarrollo y/o implementacin para alcanzar los requerimientos de rendimiento indicados por el usuario. Esta caracterstica se parece mucho a la 5, pero requiere consideraciones de rendimiento durante las fases del desarrollo de la aplicacin. Un peso de 4 requiere tareas de anlisis de rendimiento durante la fase de diseo. Un peso de 5 requiere el uso de herramientas de anlisis de rendimiento.
4. Configuracin fuertemente utilizada Una configuracin operacional pesada describe el grado en el que las restricciones de recursos computacionales influyen en el desarrollo de la aplicacin.
0 No hay restricciones operacionales implcitas o explcitas incluidas. 1 Las restricciones operacionales existen pero son menos restrictivas que una aplicacin tpica. Ningn efecto especial es necesario para alcanzarlas. 2 Existen algunas consideraciones de seguridad o de tiempo. 3 Hay requerimientos de procesador especficos para una parte de la aplicacin. 4 Las restricciones de operacin indicadas requieren restricciones especiales sobre la aplicacin en un procesador central o en un procesador dedicado. 5 Adems, hay restricciones especiales sobre la aplicacin en los componentes distribuidos del sistema.
5. Frecuencia de Transacciones Describe el grado en el que la frecuencia de transacciones comerciales influyen en el diseo, desarrollo, instalacin y soporte de la
0 No se anticipa un perodo pico transaccional. 1 Se anticipa un perodo transaccional trimestralmente, semestralmente o anualmente. 2 Un perodo transaccional pico se anticipa. 3 Un perodo transaccional pico se anticipa diariamente. 4 Los requerimientos de porcentaje transaccional indicados por el usuario son lo suficientemente crticos como para requerir anlisis del rendimiento durante el diseo. pico mensualmente,
25
aplicacin
5 Adems, se requiere el uso de herramientas de anlisis de rendimiento durante el diseo, el desarrollo y la implementacin para alcanzar los requerimientos del usuario. 0 Todas las transacciones son procesadas en lote. 1 De un 1% a un 7% de las transacciones son entrada de datos interactiva. 2 De un 8% a un 15% de las transacciones son entrada de datos interactiva. 3 De un 16% a un 23% de las transacciones son entrada de datos interactiva. 4 De un 24% a un 30% de las transacciones son entrada de datos interactiva. 5 Ms de un 30% de las transacciones son entrada de datos interactiva.
6. Entrada de Datos en Lnea Describe el grado en el que los datos se ingresan a travs de transacciones interactivas. La entrada de datos en lnea y las funciones de control son provistas por la aplicacin.
Las transacciones se refieren a los EI, EO y EQ de la aplicacin. Uno de los problemas de GSCs es que la gua no se ha actualizado en aos. Consecuentemente los pesos no son realsticos, sin embargo, los datos de la industria se han calculado utilizando estas guas. Tpicamente las aplicaciones en lote reciben de 0 a 1; y los sistemas en lnea, en tiempo real, telecomunicaciones, o control de procesos un peso de 5. 7. Eficiencia del Las funciones en lnea enfatizan un diseo especfico para lograr la eficiencia del usuario final. Esto incluye lo siguiente: Usuario Final Ayuda de navegacin (por ejemplo: teclas de funcin, menes Describe el grado en generados dinmicamente) que se consideran Menes. factores humanos y Documentacin de ayuda en lnea. facilidades de uso, para el usuario de la Movimiento del cursor automtico. aplicacin que se est Scroolling. midiendo. Impresora remota. Teclas de funcin preasignadas. Tareas en lote enviadas desde transacciones en lnea. Interfases con mouse. Ventanas pop-up. Mnimo de ventanas como sea posible para realizar las funciones comerciales. Uso pesado de video en reverso, colores, subrayados y otros indicadores. Documentacin de usuario hard-copy de transacciones en lnea. Soporte bilinge (si soporta 2 lenguajes se cuenta como 4 items). Soporte multilenguaje (si soporta ms de 2 lenguajes se cuenta como 6 items). El peso se aplica como sigue:
26
0 Ninguna de las anteriores. 1 Una de las tres anteriores. 2 De 4 a 5 de las anteriores. 3 Seis o ms de las anteriores pero no se indican requerimientos de usuario especficos relacionados con la eficiencia. 4 Seis o ms de las anteriores y los requerimientos indicados por el usuario para la eficiencia son lo suficientemente fuertes para requerir tareas de diseo de factores humanos (por ejemplo usar plantillas, maximizar casos por omisin). 5 Seis o ms de las anteriores y los requerimientos indicados por el usuario para la eficiencia son lo suficientemente fuertes para requerir herramientas especiales y procesos que demuestren que los objetivos se han logrado. 8. Actualizacin Lnea en El peso se aplica como sigue: 0 Ninguna. 1 Se requiere la actualizacin en lnea de 1 a 3 archivos de control. El volumen de actualizacin es bajo y la recuperacin es fcil. 2 Actualizacin en lnea de 4 o ms archivos de control. El volumen de actualizacin es bajo y la recuperacin es fcil. 3 Se requiere la actualizacin en lnea de archivos lgicos internos importantes. 4 Adems la proteccin contra prdida de datos es esencial y ha sido especficamente diseada y programada en el sistema. 5 Adems volmenes altos traen consideraciones de costos en el proceso de recuperacin. Procedimientos de recuperacin altamente automatizados con un mnimo de intervenciones de operacin. 9. Procesamiento complejo Describe el grado en el que la lgica de procesamiento influye en el desarrollo de la aplicacin. Esto incluye lo siguiente: Control sensitivo (por ejemplo procesamiento de auditora especial) y/o procesamiento de seguridad especfica en la aplicacin. Procesamiento lgico extenso. Procesamiento matemtico extenso. Muchos procesamientos de excepcin que resultan de transacciones incompletas que deben ser procesadas de nuevo (por ejemplo: transacciones incompletas por interrupciones, datos ausentes o validaciones sin xito). Procesamiento complejo para manejar entrada/salida, por ejemplo multimedia. posibilidades de
Describe el grado en que los archivos lgicos internos (ILF) se actualizan en lnea.
El peso se aplica como sigue:
27
0 Ninguna de las anteriores. 1 Una de las anteriores. 2 Dos de las anteriores. 3 Tres de las anteriores. 4 Cuatro de las anteriores 5 Todas las anteriores. 10. Reusabilidad Describe el grado en que la aplicacin y el cdigo de la aplicacin han sido especficamente diseados, desarrollados y soportados para que otras aplicaciones la utilicen. El peso se aplica como sigue: 0 No hay cdigo reutilizable. 1 El cdigo reutilizable es usado dentro de la aplicacin. 2 Menos del 10% de la aplicacin se considera para ms de una necesidad del usuario. 3 Diez por ciento o ms de la aplicacin se considera para ms de una necesidad del usuario. 4 La aplicacin fue especficamente empaquetada y documentada para facilitar la reutilizacin y la aplicacin es adaptada al usuario en un nivel de cdigo fuente. 5 La aplicacin fue especficamente empaquetada y documentada para facilitar la reutilizacin y la aplicacin es adaptada al usuario en un nivel de cdigo fuente por medio de parmetros de mantenimiento. 11. Facilidad instalacin de El peso se aplica como sigue: 0 No hay consideraciones especiales indicadas por el usuario ni un set-up especial es requerido para la instalacin. 1 No hay consideraciones especiales indicadas por el usuario pero se requiere un set-up especial para la instalacin. 2 Los requerimientos de conversin e instalacin fueron indicados por el usuario y las guas de conversin e instalacin sern provistas y probadas. El impacto de conversin del proyecto no se considera importante. 3 Los requerimientos de conversin e instalacin fueron indicados por el usuario y las guas de conversin e instalacin sern provistas y probadas. El impacto de conversin del proyecto se considera importante. 4 Adems del punto 2 la conversin automatizada y las herramientas de instalacin sern provistas y probadas. 5 Adems del punto 3 la conversin automatizada y las herramientas de instalacin sern provistas y probadas.
Describe el grado en el que la conversin del sistema desde un ambiente previo influye en el desarrollo de la aplicacin. Se debe considerar un plan de conversin e instalacin y/o herramientas de conversin provistas y probadas durante la fase de pruebas del sistema.
12. Facilidad operacin
de Los pesos se aplican como siguen: 0 No hay consideraciones operacionales especiales ms que el
28
(Soporte respaldo)
de
Describe el grado en el que la aplicacin atiende los aspectos operacionales tales como; inicializacin, respaldo y recuperacin. La aplicacin minimiza las necesidades de actividades manuales, tales como: cargar una cinta, manejo del papel, intervencin manual directa.
procedimiento de respaldo normal indicado por el usuario. 1-4 Seleccionar los siguientes elementos que se aplican. Cada elemento vale un punto. Procesos de inicializacin, respaldo y recuperacin fueron provistos, pero la intervencin del operador es necesaria. Procesos de inicializacin, respaldo y recuperacin fueron provistos pero ninguna intervencin del operador es necesaria (contar 2 elementos). La aplicacin minimiza la necesidad de montar cintas. La aplicacin minimiza la necesidad del manejo del papel. 5 La aplicacin es diseada para que no se requiera la intervencin del operador. La recuperacin de errores en forma automtica es una caracterstica de la aplicacin.
13. Instalacin en El peso se aplica como sigue: distintos lugares 0 No hay requerimientos del usuario que consideren ms de un lugar de instalacin. Describe el grado en que la aplicacin se ha 1 La necesidad de mltiples lugares fue considerada en el diseo, y la diseado, aplicacin es diseada para operar solamente bajo un ambiente de desarrollado y hardware y software idntico. soportado para ser 2 La necesidad de mltiples lugares fue considerada en el diseo, y la instalado en mltiples aplicacin es diseada para operar solamente bajo un ambiente de lugares y hardware y software similar. organizaciones del 3 La necesidad de mltiples lugares fue considerada en el diseo, y la usuario. aplicacin es diseada para operar solamente bajo diferentes ambientes de hardware y software. 4 El plan de documentacin y soporte es provisto y probado para apoyar la aplicacin en mltiples lugares y la aplicacin se describe como en el punto 1 o el 2. 5 El plan de documentacin y soporte es provisto y probado para apoyar la aplicacin en mltiples lugares y la aplicacin se describe como en el punto 3. Sus caractersticas son las siguientes:
14. Facilidad cambio
de
Provee capacidad para reportar/consultar de manera flexible. Describe el grado en el Los datos de control del negocio son agrupados en tablas que la aplicacin se ha mantenidas por el usuario. desarrollado para facilitar la El peso se aplica como sigue: modificacin de la 0 No hay requerimientos especiales del usuario para facilitar los lgica de cambios. procesamiento o la 1 5 Seleccione cualquiera de los siguientes elementos: estructura de datos.
29
Debe proveer capacidad para reportar/consultar de manera flexible.
La facilidad de consulta y reporte flexible permite manejar solicitudes simples- por ejemplo: lgica aplicada a un solo ILF (contar como un elemento). La facilidad de consulta y reporte flexible permite manejar solicitudes de complejidad media por ejemplo: lgica aplicada a ms de un ILF (contar como dos elementos). La facilidad de consulta y reporte flexible permite manejar solicitudes complejas por ejemplo: lgica combinada sobre uno o ms ILF (contar como tres elementos). Los datos de control comercial se mantienen en tablas que son administradas por el usuario con un proceso interactivo en lnea pero los cambios tienen efecto solamente el prximo da comercial (contar como un elemento). Los datos de control se mantienen en tablas que son administradas por el usuario con un proceso interactivo en lnea y los cambios tienen efecto inmediatamente (contar como 2 elementos).
Grado Total de Influencia (GTI) Cada una de estas caractersticas aporta un peso entre 0 y 5, de acuerdo a la importancia que tenga en el sistema a desarrollar. Luego se suman los aportes de cada una obteniendo el Grado Total de Influencia (GTI) y se calcula el Factor de Ajuste (FA): FA = (GTI * 0.01) + 0.65 FA: Factor de Ajuste GTI: Grado Total de Influencia Finalmente los Puntos de Funcin finales (ya ajustados) se obtienen como el producto de los Puntos de Funcin sin Ajustar por el Factor de Ajuste: PF = PFSA* FA PF: Puntos de Funcin finales PFSA: Puntos de Funcin sin Ajustar. 3.2 Estimar el Esfuerzo Una vez que se ha estimado el tamao del software a desarrollar se pasa al segundo paso que es derivar la estimacin del esfuerzo. La estimacin del esfuerzo para desarrollar un proyecto de software se basa en los datos e informacin del proyecto. Hay una lista de factores que influyen en la productividad del desarrollo. Entre ellos estn: la funcionalidad solicitada, las restricciones del proyecto tales
30
como la fecha de entrega, el rendimiento, el costo y la calidad, la tecnologa, los mtodos, el ambiente de desarrollo, el nivel de habilidades del personal la estabilidad percibida de los requerimientos. En la seccin 3.2.1 se explican dos enfoques para estimar el esfuerzo y la relacin de los Puntos de Funcin con cada enfoque. En la seccin 3.2.2 se explica el mtodo ideal de determinar la tasa de productividad para derivar el esfuerzo. Y en la seccin 3.2.3 se explican la manera de estimar el esfuerzo cuando la organizacin no cuenta con datos propios y requiere de los datos de la industria. 3.2.1. Enfoques de Estimacin del Esfuerzo A continuacin se describen dos enfoques de estimacin de costos importantes que se utilizan comnmente: Estimacin Micro En este mtodo el esfuerzo asociado con cada componente o actividad de las tareas es estimado individualmente y el resultado produce una estimacin general del proyecto. Este es un enfoque bottom-up Este mtodo usa un enfoque top-down. Esencialmente trata de encontrar proyectos terminados con atributos similares y extrapolar la experiencia en los nuevos proyectos. La extrapolacin puede ser simplemente por analoga, pero a menudo es soportada por uno o ms algoritmos que producen la estimacin del esfuerzo, como una funcin del nmero de variables las cuales son consideradas como importantes effort drivers (factores de costos).
Estimacin macro
El Anlisis de Puntos de Funcin tiene un papel importante en ambos enfoques: Mtodo Estimacin Micro Uso de los Puntos de Funcin El tamao funcional permite calcular la tasa de productividad esperada, comparndola con datos histricos. El tamao funcional es una entrada clave en muchos algoritmos de estimacin.
Estimacin macro
3.2.2 Estimacin Consolidada del Esfuerzo Tpicamente los proveedores de servicios de Tecnologa de Informacin usan la tcnica de estimacin micro (por tarea o por algn componente) para desarrollar la estimacin del esfuerzo. La tcnica de estimacin macro es utilizada
31
posteriormente, para validar la estimacin micro. Cuando la estimacin difiere de ms del 10-15% entonces se re-trabaja lo estimado. No es conveniente utilizar solamente tcnicas de estimacin macro, en contratos o licitaciones para propsitos comerciales serios. La tasa de productividad usada es mejor derivarla de la base de datos de experiencias propias de la organizacin. Si no est disponible puede ser ayudado por bases de datos externas de la industria. El tamao funcional es solo una de las muchas variables conocidas que influyen en el esfuerzo, pero es reconocida como un factor clave. Conforme se incrementa el tamao funcional, el esfuerzo se aumenta ms rpidamente, es decir si se incrementa el tamao se reduce la productividad lo cual se refleja en la siguiente frmula Esfuerzo = Tamao funcional * tasa de productividad Donde la tasa de productividad es expresada como Horas/Puntos de Funcin o Puntos de Funcin/Mes. La tasa de productividad se deriva de proyectos terminados con atributos similares. Un conjunto de atributos recomendado para elegir proyectos similares son: Tipo de proyecto Tamao Metas del proyecto Plataforma de desarrollo Lenguaje Seleccin de tareas Desarrollo, mantenimiento, re-desarrollo (nueva plataforma) Tamao en Puntos de Funcin En trminos de calidad, costos y cronograma Mainframe, Midrange, PC Lenguaje o nivel de lenguaje Plantillas de proyectos similares en trminos de actividades y entregables de esa actividades
Las diferentes organizaciones tienen sus propias caractersticas que influyen en sus procesos y en su productividad. Muchas de estas caractersticas son difciles de identificar y cuantificar. Ellas incluyen variables como: ambiente de trabajo, predisposicin el personal y moral del personal, mezclas de equipo (desarrollo/soporte), administracin, estructura organizacional y relaciones con clientes/usuarios. 3.2.3 Estimacin Indicativa del Esfuerzo Una estimacin indicativa o rpida usualmente se utiliza cuando hay poco tiempo e informacin para desarrollar sus propias mtricas de productividad. En esta situacin una tcnica de estimacin macro simple se puede utilizar fcilmente.
32
A continuacin se describen dos mtricas de la industria (tomadas de SPR Caperss Jones1 y de ISBSG2) para estimar rpidamente el esfuerzo [15]. 1. Capers Jones provee la siguiente regla: Esfuerzo = (Tamao en PF /150)* Tamao en PF 0,4 En los algoritmos de Capers Jones el esfuerzo incluye a los desarrolladores de software, al personal de Calidad, a los encargados de pruebas, a los que escribe material tcnico, a los administradores de bases de datos y a los administradores del proyecto Ejemplo: Para un proyecto con tamao de 1000 PF tenemos: Esfuerzo = (1000 /150)* 1000 0,4 105,5 meses persona Aproximadamente 13.660 horas persona. Se calcul con base en 130 horas laborables al mes. 2. Las ecuaciones derivadas de los datos ISBSGs, para valores benchmarked como valores medios de esfuerzo para desarrollo son: Para todos los proyectos Para proyectos 3GL Para proyectos 4GL Esfuerzo = 11,79 * tamao en PF 0,898 Esfuerzo = 5,76 * tamao en PF 1,062 Esfuerzo = 9,32 * tamao en PF 0,912
En los algoritmos del ISBCG el esfuerzo incluye a los desarrolladores de software, administradores de proyecto y a la administracin. Ejemplo: Para un proyecto de un tamao de 1000 PF: Para todos los proyectos Para proyectos 3GL Para proyectos 4GL 5828 horas persona 8839 horas persona 5075 horas persona 5.8 horas PF 8,8 horas PF 5,1 horas PF
Otro posible mtodo para obtener el esfuerzo directamente sobre los Puntos de Funcin Sin Ajustar, es el mtodo algortmico COCOMO II, el cual consiste en la aplicacin de ecuaciones matemticas sobre los Puntos de Funcin Sin Ajustar o sobre las Lneas de Cdigo estimadas para un proyecto. Estas ecuaciones se encuentran ponderadas por ciertos factores de costo (cost drivers) que influyen en el esfuerzo requerido para el desarrollo del software. Sin embargo, esta herramienta no est calibrada para proyectos muy pequeos Aunque no se ha
SPR corresponde a la Base de Datos de Software Productivity Research de Capers Jones. La tasa de productividad tiende a ser ms conservadora que en ISBSG. 2 ISBSG corresponde a la Base de Datos International Software Benchmarking Standards Group. Sus datos son tomados de organizaciones que contribuyen a propsitos de benchmarking.
1
33
especificado un tamao que constituya un proyecto pequeo, muchos especialistas en mtricas han acordado un lmite inferior entre 50-100 PF. (Por ejemplo Capers Jones usa 50 PF. Bankers Trust Australia usa 40.) 3.3 Estimar la Duracin El tercer paso en la estimacin de un proyecto de software es estimar la duracin del proyecto, la cual usa los siguientes factores: la estimacin del esfuerzo, la plantilla de fases del ciclo de vida incluyendo el traslape entre fases y actividades, y la disponibilidad del personal. Para una estimacin indicativa se dan dos tcnicas para obtener rpidamente la duracin de un proyecto [15]: 1. Capers Jones provee la siguiente regla: Duracin =Tamao en PF 0,4 Donde la duracin es en meses calendario. Ejemplo: Para un proyecto con tamao de 1000 PF tenemos: Duracin =1000 en PF 0,4 15,85 meses 2. Las ecuaciones derivadas de los datos ISBSGs, para valores benchmarked como valores medios de duracin, para nuevo desarrollo son: Para todos los proyectos Para proyectos 3GL Para proyectos 4GL Esfuerzo = 0,80 * Tamao en PF 0,404 Esfuerzo = 0,33 * Tamao en PF 0,559 Esfuerzo = 1,11 * Tamao en PF 0,342
Ejemplo: Para un proyecto con tamao de 1000 PF tenemos: Para todos los proyectos Para proyectos 3GL Para proyectos 4GL 13,03 meses 15,67 meses 11,78 meses
34
Referencias Bibliogrficas
[1] PMBOK Guide 2000 Edition. A Guide to the Project Management Body of Knowledge. Secciones 5.1 y 5.2. [2] Harold Kerzner. Project Management. Seventh Edtion, Wiley. [3] Cuerpo de conocimientos - CSQE BOK (Body of Knowledge). Cap. III y IV. [4] Bruegge Bern, Allen H Dutoit Objetos. Prentice Hall. Ingeniera de Software Orientada a
[5] Pressman, R. Ingeniera de Software: Un enfoque prctico. 5ta edicin, McGraw-Hill, 1997. Cap. 5. [6] Karl E. Wiegers. First Things First: Prioritizing Requirements. Process Impact. 716-377-5110. www.proccessimpact.com [7] Dan Remenyi, Arthur Money y Alan Twite. Effective Measurement & Management of IT Costs & Benefits. Butterworth-Heinemann, Gran Bretaa, 1998. [8] ANSI/ISO/IEEE Std. 1074-1991. IEEE Standard for Developing Software Live Cycle Processes. [9] Karl E. Wiegers. Karl Wiegers Describes 10 Requirements Traps to Avoid. [10] Steve Adolph, Paul Bramble, Alistair Cockburn. Patterns for Effective Use Cases. Adisson Wesley 2002. [11] Larman. UML Y PATRONES. Introduccin al anlisis y diseo orientado a objetos. Prentice Hall. [12] Mario Peralta. Estimacin del Esfuerzo basada en Casos de Uso. Reportes Tcnicos en Ingeniera de Software Vol. 6 N 1 (2004), pg 1-16. (http://www.itba.edu.ar/capis/rtis/index.htm). [13] Steve McConnell. Desarrollo y Gestin de Proyectos Informticos. McGraw-Hill. 1996. [14] Terry Quatrani. Visual Modeling with Rational Rose 2002 and UML Addison Wesley 2003. [15] Robyn Lawrie, Pul Radford. Using Functional Sizing in Software Project Estimating. Charismatek Software Metrics. http:// Charismatek.com. [16] Salazar Gabriela. Metodologa para Medir el Versin 2. 2005
Proceso de Software.

Descrip C I On Conceptual 2008

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Descrip C I On Conceptual 2008

Загружено:

Авторское право:

Доступные форматы

Universidad de Costa Rica

Escuela de Ciencias de la Computacin e Informtica

GUA PARA ELABORAR LA DESCRIPCIN CONCEPTUAL DE UN PROYECTO DE SOFTWARE

Autora: Prof. Gabriela Salazar Bermdez

1.2. Introduccin _____________________________________________________________ 5

1.3. Descripcin Conceptual del Sistema ________________________________________ 6

1.4. Estudio de Factibilidad___________________________________________________ 11

3.2 Estimar el Esfuerzo_______________________________________________________ 29

3.3 Estimar la Duracin ______________________________________________________ 33

Referencias Bibliogrficas ________________________________________________ 34

+/- 40% Etapa 1 Etapa 2 Factibilidad Planeacin

Etapa 3 Etapa 4 Desarrollo Implantacin

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Requerimientos Del Negocio

Requerimientos Del Usuario Casos de Uso Atributos de Calidad

Especificacin de Requerimientos del Software

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Captulo 1: Gua para elaborar la Descripcin Conceptual del Sistema

Descripcin Conceptual del Sistema

Sistema de Registro de Instalacin de Servidores

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Cumplir con la recomendacin de Auditora Interna.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Sistema de Instalacin de Servidores (SIS)

Figura 6. Diagrama de Contexto para el Sistema de Instalacin de Servidores

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Tabla 3. Ejemplo del requerimiento funcional nmero 2 priorizado.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Mejor percepcin por parte potenciales de la organizacin.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Captulo 2: Tcnicas para Extraccin de Requerimientos

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Administra las expectativas del usuario y las actitudes al cambio.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Figura 7. Diagrama de un Caso de Uso

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Captulo 3: Proceso de Estimacin

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

A continuacin se describen las 14 caractersticas generales cuenta:

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Tabla 3. Tabla de las 14 caractersticas Generales Caractersticas

0 No hay requerimientos de rendimiento especiales indicados por el

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

El peso se aplica como sigue:

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

12. Facilidad operacin

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

14. Facilidad cambio

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Debe proveer capacidad para reportar/consultar de manera flexible.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.