Conceptualización I 2006

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
I Semestre 2006
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 ___________________________________________________ 7
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 _____________________________________________ 10
1.4. Estudio de Factibilidad___________________________________________________ 12

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 ________________________________________ 23
3.1 Estimar el Tamao del Producto ___________________________________________ 23
3.1.1 Componentes del Anlisis de Puntos de Funcin______________________________________ 23
3.1.2 Obtencin de los Puntos de Funcin Sin Ajustar ______________________________________ 26
3.1.3 Ajustar los Puntos de Funcin ____________________________________________________ 27
3.2 Estimar el Esfuerzo_______________________________________________________ 30

3.2.1. Enfoques de Estimacin del Esfuerzo ______________________________________________ 30
3.2.2 Estimacin Consolidada del Esfuerzo ______________________________________________ 31
3.2.3 Estimacin Indicativa del Esfuerzo ________________________________________________ 32
3.3 Estimar la Duracin ______________________________________________________ 33
Referencias Bibliogrficas ________________________________________________ 35
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
Contratacin
mayor
Avance
Decisin de
arranque
+/- 40%
Etapa 1
Etapa 2
Factibilidad
Planeacin
Inicio Formulacin
Costo y cronograma
Estudio Factibilidad Trminos contrato
Aprobacin
Descripcin Conceptual
Plan
Project Charter (PMI)
Operacin completa/
Entrega definitiva
se
a ba
e
n
Etapa 3
Etapa 4
Desarrollo Implantacin
Produccin
Entrega
Instalacin
Prueba
Prueba final
Mantenimiento
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: 28/08/2006.
Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.
Requerimientos
Del Negocio
Descripcin
Conceptual
Requerimientos
Del Usuario
Casos de Uso
Atributos de Calidad
Requerimientos
No Funcionales
Requerimientos
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. Se debe considerar el problema y
por qu es necesario resolverlo. Esta tarea incluye la identificacin de una idea o
necesidad generada desde una o ms de las siguientes fuentes:
Cambios en los requerimientos del software (pueden ser por

legislacin, regulaciones, estndares nacionales e internacionales,
mantenimiento, etc.)
Solicitudes de clientes.
Ideas que provienen de la misma organizacin de desarrollo.
Solicitudes de usuarios.
Demanda de mercado.
Informacin reportada por problemas de mejoramiento.
Recomendaciones de mantenimiento.
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.
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 una herramienta que permite identificar Actores y Casos de Uso potenciales,
porque ayuda a enfocar las cosas que interactan con el sistema ignorando los
servicios que aquellas cosas requieren. Solo se necesita conocer las cosas fsicas con
las que el sistema habla, no se necesita saber los servicios que este requerir o
entregar. El Diagrama de Contexto 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
Sistema de
Instalacin de
Servidores
(SIS)
Auditora
Interna
Funcionarios
Empresa
Departamento
de Sistemas
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 relacionados con el cronograma que para fines
del desarrollo del cronograma se consideran verdaderos, reales o ciertos, 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, en lugar
de dejar que la fecha sea determinada por el proceso de planeacin.
c. Restricciones contractuales si se est trabajando bajo contrato.
d. Recursos disponibles: humanos, de equipo, de espacio, herramientas
automatizadas y no automatizadas, etc.
e. Entrega de materiales provenientes e fuentes externas.
f. Presentacin de documentos, actividades peridicas de revisin.
g. Ciclo de vida.
10
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
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.
En el captulo 2 de este documento se encuentra una plantilla para
documentar los escenarios de los Casos de Uso.
3. Identificar y listar los requerimientos no funcionales.
4. 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:
11
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
condicional est ausente, puede esperar una siguiente versin, si se necesita. Debe
tomarse en cuenta en el diseo del sistema y en el diseo de objetos.
Baja
u Se refiere a una mejora en la funcionalidad o en la calidad. Ilustra la
opcional
manera 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.
D escrip cin : M an ten im ien to S oftw are
P riorid ad
R 1-1
In cluir nuev o softw are y nuevas versiones d el

m ism o
A lta
R 1-2
M odificar caractersticas d e softw are ya incluid o.
A lta
R 1-3
B orrar softw are que ya no se utilice en la em presa
A lta
R 1-4
L istar el softw are utilizad o, con la posibilid ad de

filtrar inform acin
A lta
R 1-5
E nviar por correo lista d e softw are a XX X
B aja
Tabla 3. Ejemplo del requerimiento funcional nmero 2 priorizado.

No.
Descripcin : Mantenimiento Detalles Orden
Prioridad
R2-1
Incluir datos iniciales sobre el detalle de la orden

de trabajo a realizar
Alta
R2-2
Modificar caractersticas de un detalle particular
Alta
..
R2-n-1
Listar el detalle de una orden de trabajo en

particular.
Alta
R2- n
Posibilidad de definir formatos de impresin
Baja
12
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.
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.
13
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.
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.
Mejor
percepcin
por
parte
potenciales de la organizacin.
por
parte
del
cliente
de
del
los
producto
empleados
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.
Administra las expectativas del usuario y las actitudes al cambio.
necesidades
resuelve
problemas
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.
Se recomienda utilizar la siguiente plantilla para elaborar el documento
Especificacin del Caso de Uso.
18
19
Plantilla de Casos de Uso (tomada de [14, pg. 30]))

1.0 Nombre del Caso de Uso
1.1 Descripcin breve.
1.2 Actores.
2.0 Flujo de eventos
2.1 Flujo bsico o principal
2.1.1 Escenario principal: Se describe la secuencia normal de
eventos en la que el sistema debe funcionar. Si el caso de Uso
contiene diferentes alternativas, en esta seccin solamente se
indican (no se describen los eventos).
2.1.2 Escenarios secundarios: Son secuencias alternas de eventos.
Cuando el Caso de Uso contiene varias alternativas, cada opcin
se incluye como un escenario secundario, en el cual se describe la
secuencia de pasos correspondiente a cada alternativa.
2.2 Flujos alternos
Manejan situaciones errneas o excepciones.
3.0 Requerimientos especiales: tpicamente son requerimientos no
funcionales.
4.0 Precondiciones: es una condicin inicial, debe indicar qu hacer antes de
comenzar el Caso de Uso.
5.0 Poscondiciones: es una condicin final, debe indicar qu sucede al
finalizar el Caso de Uso.
6.0 Puntos de extensin.
20
Ejemplo del Uso de la Plantilla

A continuacin se muestra la descripcin del escenario de uno de los Casos
de Uso de un Sistema de Matrcula (tomado textualmente de [14, pg. 30]) que le
permite a los profesores de una Universidad seleccionar los cursos a ensear. La
idea es ejemplificar el uso de la plantilla mostrada anteriormente.
1.0 Nombre del CU: Seleccionar cursos a ensear.
1.1 Breve Descripcin
Este Caso de Uso le permite al estudiante crear, eliminar, modificar y/o
revisar el horario de cursos para un semestre dado.
1.2 Actores
Profesor.
2.0 Flujo de eventos
2.1 Flujo Bsico o Principal
2.1.1 Escenario principal:
El Caso de Uso inicia cuando el profesor ingresa su nmero de identificacin
en el Sistema de Registro. El sistema verifica que el nmero sea vlido (Si la
identificacin es invlida, se ejecuta el Flujo Alterno 2.2.1), y le pide al Profesor
que seleccione el semestre actual o un semestre futuro (si el semestre ingresado
es invlido, se ejecuta el Flujo Alterno 2.2.2). El profesor ingresa el semestre
deseado. El sistema pide al profesor seleccionar la transaccin deseada:
CREAR, ELIMINAR CONSULTAR, IMPRIMIR o SALIR.
2.1.2 Escenarios secundarios
CREAR
El sistema muestra una pantalla de cursos que contiene un campo para el
nombre del curso y otro para el nmero de curso. El profesor ingresa el nombre
y nmero de curso (si se ingresa una combinacin nombre/nmero invlida, se
ejecuta el Flujo alterno 2.2.3). El sistema despliega las ofertas de cursos para el
curso ingresado (si el nombre del curso no se puede desplegar, se ejecuta el
Flujo Alterno 2.2.4). El profesor selecciona una oferta de cursos. El sistema hace
la liga entre el profesor y la oferta de cursos seleccionada (si la liga no se puede
crear, se ejecuta el Flujo Alterno 2.2.5). El Caso de Uso comienza de nuevo.
ELIMINAR
El sistema muestra una pantalla de ofertas de cursos que contiene un campo
para el nombre de la oferta de curso y otro para el nmero. El profesor ingresa
el nombre y nmero de la oferta de curso (si se ingresa una combinacin
nombre/nmero invlida, se ejecuta el Flujo Alterno 2.2.3). El sistema remueve
21
la liga al profesor (si la liga no se puede eliminar se ejecuta el Flujo alterno

2.2.6). El Caso de Uso comienza de nuevo.
CONSULTAR
El sistema recupera (si la informacin del curso o se puede recuperar, se ejecuta
el Flujo Alterno 2.2.7) y muestra la siguiente informacin para todas las ofertas
de cursos asignadas al profesor: nombre del curso, nmero del curso, nmero
de oferta de curso, das de la semana, hora y lugar. Cuando el profesor indica
que termin la consulta el Caso de Uso comienza de nuevo.
IMPRIMIR
El sistema imprime el horario del profesor (si el horario no puede imprimirse,
se ejecuta el Flujo Alterno 2.2.8). El Caso de Uso comienza de nuevo.
SALIR
El Caso de Uso termina.
2.2. Flujos alternos:
2.2.1 Identificacin invlida
Se ingresa una identificacin invlida. El usuario puede volver a ingresar su
identificacin o terminar el Caso de Uso.
2.2.2 Semestre invlido
El sistema le informa al usuario que el semestre es invlido. El usuario
puede volver a ingresar el semestre o terminar el Caso de Uso.
2.2.3 Nombre/nmero del curso invlido
El sistema le informa al usuario que el nombre/nmero del curso es
invlido. El usuario puede volver a ingresar una combinacin de
nombre/nmero vlida o terminar el Caso de Uso.
2.2.4 Oferta del curso no puede ser desplegada
El usuario es informado que la opcin no est disponible en ese momento.
El Caso de Uso comienza de nuevo.
2.2.5 No se puede crear la liga entre el profesor y la oferta del curso.
La informacin es guardada y el sistema crear la liga un tiempo despus. El
Caso de Uso comienza de nuevo.
2.2.6 No se puede eliminar la liga entre el profesor y la oferta del curso.
22
La informacin es guardada y el sistema eliminar la liga un tiempo

despus. El Caso de Uso comienza de nuevo.
2.2.7 No se puede recuperar la informacin del horario.
2.2.8 No se puede imprimir el horario.
3.0 Requerimientos especiales:

No hay ningn requerimiento especial para este Caso de Uso.
4.0 Precondiciones:
4.1 El subflujo Crear una Oferta de Curso del mdulo de Mantenimiento
de Cursos debe ejecutarse antes de que comience este Caso de Uso.
5.0 Poscondiciones:
Ninguna.
6.0 Puntos de extensin:
No hay puntos de extensin.
23
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
24
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
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).
25
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.
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:
26
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
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.
27
Tabla 2. Tabla de Pesos.

Complejidad
Componentes
Media
Total
Archivos Lgicos Internos (ILF)
X10
Archivos de Interfaz Externos (EIF)
X7
Entradas Externas (EI)
X4
Salidas Externas (EO)
X5
Consultas Externas (EQ)
X4
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
Factor no presente o sin influencia
Influencia incidental
Influencia moderada
Influencia media
Influencia significativa
Influencia fuerte
A continuacin se describen las 14 caractersticas generales

cuenta:
a tener en
Tabla 3. Tabla de las 14 caractersticas Generales

Caractersticas
Descripcin
Peso
28
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.
2. Procesamiento
Es el grado en que una aplicacin transfiere datos
de Distribuido entre los componentes de la aplicacin.
de Datos
3. Rendimiento
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.
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.
5. Frecuencia
de Describe el grado en el que la frecuencia de
Transacciones
transacciones comerciales influyen en el diseo,
desarrollo, instalacin y soporte de la aplicacin
6. Entrada
de Describe el grado en el que los datos se ingresan a
Datos en Lnea
travs de transacciones interactivas. La entrada
de datos en lnea y las funciones de control son
provistas por la aplicacin.
7. Eficiencia
del Describe el grado en que se consideran factores
Usuario Final
humanos y facilidades de uso, para el usuario de
la aplicacin que se est midiendo.
8. Actualizacin en Describe el grado en que los archivos lgicos
Lnea
internos (ILF) se actualizan en lnea.
9. Procesamiento
complejo
Describe el grado en el que la lgica de

procesamiento influye en el desarrollo de la
aplicacin.
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.
11. Facilidad
instalacin
de Describe el grado en el que la conversin del

sistema desde un ambiente previo influye en el
29
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
(Soporte
respaldo)
de Describe el grado en el que la aplicacin atiende

los
aspectos
operacionales
tales
como;
de inicializacin, respaldo y recuperacin. La
aplicacin minimiza las necesidades de
actividades manuales, tales como: cargar una
cinta, manejo del papel, intervencin manual
directa.
13. Instalacin
en Describe el grado en que la aplicacin se ha
distintos lugares diseado, desarrollado y soportado para ser
instalado en mltiples lugares y organizaciones
del usuario.
14. Facilidad
cambio
de Describe el grado en el que la aplicacin se ha

desarrollado para facilitar la modificacin de la
lgica de procesamiento o la estructura de datos.
Debe proveer capacidad para reportar/consultar
de manera flexible.
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.
30
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
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
Estimacin macro
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).
31
El Anlisis de Puntos de Funcin tiene un papel importante en ambos

enfoques:
Mtodo
Estimacin Micro
Estimacin macro
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.
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
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
Desarrollo, mantenimiento, re-desarrollo

(nueva plataforma)
Tamao
Tamao en Puntos de Funcin
Metas del proyecto
En trminos de calidad, costos y

cronograma
Plataforma de desarrollo
Mainframe, Midrange, PC
Lenguaje
Lenguaje o nivel de lenguaje
32
Seleccin de tareas
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.
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.
1
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.
33
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

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 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
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.
34
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 proyectos 3GL
Para proyectos 4GL
Esfuerzo = 0,80 * Tamao en PF 0,404


Para proyectos 3GL
Para proyectos 4GL
13,03 meses
15,67 meses
11,78 meses
35
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.

Conceptualización I 2006

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Conceptualización I 2006

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad de Costa Rica

Escuela de Ciencias de la Computacin e Informtica

GUA PARA ELABORAR LA

Autora: Prof. Gabriela Salazar Bermdez

1.2. Introduccin _____________________________________________________________ 5

1.3. Descripcin Conceptual del Sistema ________________________________________ 6

1.4. Estudio de Factibilidad___________________________________________________ 12

Captulo 2: Tcnicas para Extraccin de Requerimientos_____________________ 14

3.2 Estimar el Esfuerzo_______________________________________________________ 30

3.3 Estimar la Duracin ______________________________________________________ 33

Referencias Bibliogrficas ________________________________________________ 35

Figura 1. Fases de un proyecto y su ciclo de vida [1]

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Figura 2: Tres niveles de Requerimientos de software [9]

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

Descripcin Conceptual del Sistema

Sistema de Registro de Instalacin de Servidores

1.1.2 Hoja de Aprobacin

Aprobado el 13 de mayo del 2005

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

1.1.3 Tabla de Contenidos

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

1.2.2 Definiciones, Acrnimos, y Abreviaciones

Figura 5. Tareas para la

Elaborar la Descripcin Conceptual del Sistema

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

1.3.1 Diagnosticar la Situacin Actual

Cambios en los requerimientos del software (pueden ser por

Ideas que provienen de la misma organizacin de desarrollo.

Informacin reportada por problemas de mejoramiento.

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Realizar estimaciones ms realistas de los procesos de instalacin de

Cumplir con la recomendacin de Auditora Interna.

1.3.3 Delimitar el Alcance del Sistema

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

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

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

1.3.5 Definir los Requerimientos del Usuario

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

Tabla 1. Significado de las prioridades de los requerimientos.

En las tablas 2 y 3 se muestran ejemplos de dos requerimientos agrupados

D escrip cin : M an ten im ien to S oftw are

In cluir nuev o softw are y nuevas versiones d el

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

E nviar por correo lista d e softw are a XX X

Tabla 3. Ejemplo del requerimiento funcional nmero 2 priorizado.

Descripcin : Mantenimiento Detalles Orden

Incluir datos iniciales sobre el detalle de la orden

Modificar caractersticas de un detalle particular

Listar el detalle de una orden de trabajo en

Posibilidad de definir formatos de impresin

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

1.4. Estudio de Factibilidad

Presupuesto y tiempo estimado para desarrollar el sistema. Para

Uso de recursos humanos y tecnolgicos.

Inversin de capital requerido como: equipo de hardware,

Recursos invertidos para evitar la resistencia al cambio por parte

Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

2. Tangibles y no medibles: son los beneficios que afectan la rentabilidad

Habilidad para mantener mejor informacin.