ANALISIS Y MODELADO DEL PROYECTO DE

SOFTWARE
Unidad IV
Profesor: N avarrete Prieto Jos Antonio
Alum no: O nofre Cortez Jonathan M ichel
G rupo: T44
4.1 TEC N IC A S D E R EC O P ILA C IO N D E
IN FO R M A C IO N
El proceso de obtencin de requisitos, cuya finalidad es llevar a la
luz los requisitos, no solo es un proceso tcnico, sino tambin un
proceso social que envuelve a diferentes personas, lo que conlleva
dificultades aadidas a su realizacin. Existe un gran nmero de
tcnicas para obtener requerimientos. A continuacin se describen
las ms utilizadas. Hay que aclarar que ninguna de estas tcnicas
es suficiente por s sola y que es recomendable combinarlas para
obtener requerimientos completos.
Entrevistas

La entrevista es de gran utilidad

para obtener informacin
cualitativa como opiniones, o
descripciones subjetivas de
actividades. Es una tcnica muy
utilizada, y requiere una mayor
preparacin y experiencia por parte
del analista. La entrevista se puede
definir como un intento
sistemtico de recoger informacin
de otra persona a travs de una
comunicacin interpersonal que se
lleva a cabo por medio de una
conversacin estructurada. Debe
quedar claro que no basta con
hacer preguntas para obtener toda
la informacin necesaria. Es muy
Aspectos ms importantes a tener en cuenta al realizar entrevistas:

Preparacin. Es necesario documentarse e investigar la situacin

de la organizacin analizando los documentos disponibles, de tal
forma que la entrevista se enfoque en aquellos aspectos que estn
solamente en la mente del entrevistado y que no son accesibles por
otros medios como la observacin o el anlisis de documentos.

Entrevistar al personal adecuado. La mayora de los analistas

adoptan un enfoque top-down, comenzando a entrevistar a
directivos para que brinden un panorama general de hacia donde
deberan ir las cosas, y terminando por hablar con los empleados
que aportan detalles importantes de la operacin.

Duracin. Una entrevista debera durar a lo sumo un par de horas.

Formato. Se recomienda utilizar preguntas abiertas, donde los

entrevistados puedan elaborar y dar detalles, ms all de
simplemente responder si o no.
D esarrollo C on ju n to d e A p licacion es ( JA D )

Es una tcnica que se utiliza

para promover la cooperacin y
el trabajo en equipo entre
usuarios y analistas. Consiste en
realizar sesiones en las que
participan usuarios expertos del
dominio junto a analistas de
software. La idea es aprovechar
la dinmica de grupos aplicando
un proceso de trabajo
sistemtico y organizado,
apoyado por elementos visuales
de comunicacin y comprensin
de soluciones.
 Las razones que sirven de base a JAD son las siguientes:

Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino tambin en
redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos
entrevistados.

Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya que slo el

analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar
defectos.

El JAD propugna una participacin ms profunda de los usuarios en el proyecto, hasta tal
punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema
que se construye.

El JAD no se utiliza demasiado, debido a que requiere una mayor organizacin que las
entrevistas y porque el ambiente o los mtodos de trabajo convencionales en las empresas no
facilitan este tipo de actividades (falta de tiempo, dificultad de coordinacin de tanta gente,
dificultad para convencer a la direccin, etc.). No obstante las empresas que han implantado
este mtodo han informado de importantes ahorros de tiempo en el desarrollo de software, as
como de una mayor satisfaccin de los usuarios con los sistemas construidos.
D esarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no
son totalmente operativos) de la aplicacin pedida. Esta tcnica es particularmente til cuando:

El rea de la aplicacin no est bien definida (posiblemente por ser algo muy novedoso).

El costo del rechazo de la aplicacin por los usuarios es muy alto.

Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organizacin.

Los prototipos de sistema permiten a los usuarios experimentar para ver cmo ste ayuda a su
trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos. Adems de
permitir a los usuarios mejorar las especificaciones de requerimientos, el desarrollo de un
prototipo tiene otras ventajas:

Se identifican las discrepancias entre los desarrolladores y los usuarios.

Darse cuenta de requerimientos inconsistentes y/o estn incompletos.

Aunque limitado, se dispone rpidamente de un sistema que funciona y demuestra la

factibilidad y usabilidad de la aplicacin a administrar.

El prototipo se utiliza como base para escribir la especificacin para la produccin.

 O bservacin

Por medio de esta tcnica el

analista obtiene informacin de
primera mano sobre la forma en
que se efectan las actividades.
Este mtodo permite observar la
forma en que se llevan a cabo los
procesos y, por otro, verificar que
realmente se sigan todos los
pasos especificados. Como
sabemos, en muchos casos los
procesos son una cosa en papel y
otra muy diferente en la prctica.
Los observadores experimentados
saben qu buscar y cmo evaluar
la relevancia de lo que observan.
Estudio de docum entacin

Varios tipos de documentacin, como

manuales y reportes, pueden
proporcionar al analista informacin
valiosa con respecto a las
organizaciones y a sus operaciones.
La documentacin difcilmente refleja
la forma en que realmente se
desarrollan las actividades, o donde
se encuentra el poder de la toma de
decisiones. Sin embargo, puede ser de
gran importancia para introducir al
analista al dominio de operacin y el
vocabulario que utiliza.
 Cuestionarios

El uso de cuestionarios permite

a los analistas reunir
informacin proveniente de un
grupo grande de personas. El
empleo de formatos
estandarizados para las
preguntas puede proporcionar
datos ms confiables que otras
tcnicas; por otra parte, su
amplia distribucin asegura el
anonimato de los encuestados,
situacin que puede conducir a
respuestas ms honestas.
Torm en ta d e id eas ( B rain storm in g )

Consiste en reuniones con cuatro a

diez personas donde como primer
paso sugieren toda clase de ideas
sin juzgar su validez por muy
disparatadas que parezcan, y
despus de recopilar todas las
ideas se realiza un anlisis
detallado de cada propuesta. Esta
tcnica se puede utilizar para
identificar un primer conjunto de
requisitos en aquellos casos donde
no estn muy claras las
necesidades que hay que cubrir, o
cuando se est creando un sistema
que habilitar un servicio nuevo
para la organizacin.
ETH ICS ( Im plem entacin Efectiva de Sistem as Inform ticos desde los puntos
de vista H um ano y Tcnico )

Constituye un mtodo bastante

evolucionado para fomentar la
participacin de los usuarios en los
proyectos. Creado por E. Mumford
en 1979, coordina la perspectiva
social de los sistemas con su
implementacin tcnica. Un sistema
no tiene xito si no se ajusta a los
factores sociales y organizacionales
que rigen a la empresa. Se busca la
satisfaccin de los empleados en el
trabajo a travs de estudios
integrales. Los requisitos tcnicos
del sistema sern los necesarios
para mejorar la situacin de los
empleados (y, por lo tanto, su
Puntos de Vista
Cualquier sistema de software no trivial debe satisfacer las
necesidades de un grupo diverso de interesados (stakeholders).
Cada uno de estos puede tener intereses diferentes en el sistema
de software, y por lo tanto sus necesidades pueden generar
requerimientos que tengan conflicto entre s, o incluso se
contradigan.

Los mtodos orientados a puntos de vista (viewpoints) toman en

consideracin estas perspectivas diferentes y las utilizan para
estructurar y organizar tanto el proceso de obtencin, como los
requerimientos mismos. Uno de estos mtodos es el mtodo
VORD (Definicin de Requerimientos Orientado a Puntos de Vista),
el cual provee un marco de trabajo orientado para la obtencin y
documentacin de requerimientos

Las etapas principales de este mtodo son:

Identificacin de puntos de vista,
Estructuracin de puntos de vista
Documentacin de puntos de vista,

 Escenarios
Estos se utilizan para documentar el comportamiento
del sistema cuando se le presentan eventos
especficos. Cada evento de interaccin distinto, o la
seleccin de un servicio del sistema, se documentan
como un escenario de eventos distinto. Los escenarios
de eventos incluyen una descripcin del flujo de datos
y las acciones del sistema, y documenta las
excepciones que puedan surgir.
Las entradas y salidas de la informacin de control se
ubican en la parte superior de cada recuadro.
Las salidas de datos se ubican a la derecha de cada
recuadro. Si no estn encerradas, significa que
pertenecen al sistema.
Las excepciones se muestran en la parte inferior del
recuadro. Si existen varias excepciones posibles, stas
se encierran en un recuadro.
El nombre del siguiente evento esperado despus de
completar el escenario se muestra en un recuadro
sombreado.
 4.2 ES TU D IO D E V IA B ILID A D
Un estudio de viabilidad consiste en la recopilacin,
anlisis y evaluacin de diferentes tipos de
informacin con el propsito de determinar si se
debe establecer o no una empresa que conlleve
riesgos econmicos.

Tambin el estudio de viabilidad resulta til para

evaluar la posible ampliacin o expansin de un
negocio ya existente. En trminos generales, los
estudios de viabilidad buscan contestar la pregunta
sobre si resulta deseable el establecer o ampliar
una empresa a base del rendimiento econmico
que se obtendra de la misma. Casi siempre la
realizacin del estudio es un esfuerzo de equipo con
la participacin de especialistas en mercadeo,
finanzas, entre otros, pero que necesariamente
debe incluir al empresario o proponente de la
empresa.
P R O P S ITO S D EL
ES TU D IO

Los propsitos bsicos de un estudio

de viabilidad son: demostrar la
viabilidad del negocio a
inversionistas, dueos e instituciones
financieras y estimar el posible
rendimiento o ganancia econmica
de una iniciativa empresarial. El
estudio formaliza, documenta y
revalida la idea del negocio
propuesto, reduciendo el riesgo
asociado a tomar una decisin de
inversin. Debemos aclarar, sin
embargo, que no es una garanta de
xito.
V IA B ILID A D C O N C EP TU A L

Es necesario realizar un anlisis crtico y

exhaustivo de las fortalezas y debilidades de la
idea. En general, para ser exitoso un nuevo
negocio debe:

Poder obtener en un tiempo razonable los

permisos para operar.

Ofrecer un producto o servicio que presente

una ventaja diferencial en relacin a sus
competidores.

Requerir una inversin de capital inicial al

alcance del proponente.
 V IA B ILID A D
O P ER A C IO N A L
De igual manera, se deber evaluar objetivamente los
siguientes aspectos relacionados a la operacin y
administracin del negocio propuesto:
Recursos humanos- Posee el proponente la
capacidad tcnica y gerencial en el rea de negocio?
Infraestructura disponible- Existe la disponibilidad
de los servicios y otros suministros?
Capacidad tecnolgica- La tecnologa a utilizarse
ha sido comprobada comercialmente?
Requisitos legales- Puede razonablemente
cumplirse con los requisitos legales que impone el
gobierno? Cul ser el efecto en los costos del
proyecto?
Salud y tiempo disponible- Tiene usted buena
salud, dispone de tiempo para atender el negocio y
cuenta con el apoyo incondicional y compromiso de
su familia?
V IA B ILID A D D E M ER C A D O
La verdad es que el anlisis de mercado es
probablemente el componente ms
importante en el proceso de determinar la
viabilidad del proyecto. El anlisis de
mercado para propsitos de determinar la
viabilidad deber incluir como mnimo:

Un estimado del mercado potencial

La participacin proyectada en el
mercado

Las proyecciones de ventas-

 V IA B ILID A D
EC O N M IC A
El anlisis financiero para determinar viabilidad
econmica conllevar usualmente los siguientes
pasos: a. Anlisis de las fuentes y usos de los
fondos
b. Proyecciones de ingresos y gastos y flujo de
efectivo
c. Anlisis del punto de empate ("Break-even
point)
d. Estimacin del perodo de repago- se define
como el tiempo requerido para recobrar la
inversin inicial
e. Estimacin del rendimiento sobre la
inversin o "Return on Investment" (ROI por sus
siglas en ingls)
 4.3 A N A LIS IS D E R EQ U ER IM IEN O S
FU N C IO N A LES Y N O FU N C IO N A LES
Requerimientos funcionales. Son declaraciones de los
servicios que debe proporcionar el sistema, de la manera en
que ste debe reaccionar a entradas particulares y de cmo se
debe comportar en situaciones particulares. en algunos casos,
los requerimientos funcionales de los sistemas tambin pueden
declarar explcitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen lo que

el sistema debe hacer, estos requerimientos dependen del tipo
de software que se desarrolle, de los posibles usuarios del
software y del enfoque general tomado por la organizacin al
redactar requerimientos.
1. El usuario deber tener la posibilidad de buscar en el
conjunto inicial de la base de datos o seleccionar un
subconjunto de ella.
2. El sistema deber proporcionar visores adecuados para que
el usuario lea documentos en el almacn de documentos.
3. A cada pedido se le deber asignar un identificador nico
(id_pedido), que el usuario podr copiar al rea de
almacenamiento permanente de la cuenta
 Requerimientos no funcionales. Son restricciones de los
servicios o funciones ofrecidos por el sistema, incluyen restricciones
de tiempo, sobre el proceso de desarrollo y estndares.

Los requerimientos no funcionales a menudo se aplican al sistema

en su totalidad, normalmente apenas se aplican a caractersticas o
servicios individuales del sistema.

Los requerimientos no funcionales, como su nombre sugiere, son

aquellos requerimientos que no se refieren directamente a las
funciones especficas que proporciona el sistema, sino a las
propiedades emergentes de ste como la fiabilidad, el tiempo de
respuesta y la capacidad de almacenamiento,

Los requerimientos no funcionales no slo se refieren al sistema

software a desarrollar, algunos de estos requerimientos pueden
restringir el proceso que se debe utilizar para desarrollar el sistema.
 4.4 A R Q U ITEC TU R A D EL S IS TEM A B A S A D A EN U M L:
D IA G R A M A S D E C O M P O R TA M IEN TO Y D E
FU N C IO N A LID A D

El UML prescribe un conjunto de

notaciones y diagramas estndar
para modelar sistemas orientados a
objetos y describe la semntica
esencial de estos diagramas y los
smbolos en ellos utilizados. En la
programacin orientada a objetos,
algunos conceptos claves son:
objetos, atributos, mtodos, clase,
etc.

Se puede definir un objeto como un

conjunto de datos y funciones
relacionadas. Las funciones de los
objetos son los mtodos y los datos
son los atributos.
 Una clase es algo abstracto que define la "forma" del objeto, algo as como el molde de los
objetos. Por ejemplo, un libro determinado es slo uno de todos los libros de una biblioteca,
por lo tanto, un libro es una instancia de la clase "Libro". Todos los libros tienen los atributos:
ttulo, autor, edicin, etc. y mtodos: abrir, cerrar, ir a la pgina siguiente, ir a la pgina
anterior, etc.

La programacin orientada a objetos permite producir objetos en serie por medio de clases o
moldes, y as utilizaremos la clase libro (molde) para producir sus instancias (objetos). Los
objetos son instancias de clases.

La clase es, una especie de plantilla que define las variables y mtodos comunes para todos
los objetos de cierto tipo. Un diagrama de clases sirve para visualizar las relaciones entre las
clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenido. Un diagrama de clases est compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Clase es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una
instancia de una clase). A travs de ella podemos modelar el entorno en estudio (un Libro,
una Casa, una Cuenta Corriente, etc.).