Universidad

Autnoma de Nuevo Len

Facultad de Ingeniera
Mecnica y Elctrica
Taller de POO
Nombre: Ricardo Osorio Casillas
Matricula: 1630894
Hora: N1-N2

Da: jueves

Ing. Antonio Jurez Covarrubias

Tema: Investigacin sobre un
proyecto

 Ciclo de vida de un proyecto.

Ciclo de Vida.
Su definicin facilita el control sobre los tiempos en que es necesario aplicar
recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el
proyecto incluye subcontratacin de partes a otras organizaciones, el control del
trabajo subcontratado se facilita en la medida en que esas partes encajen bien en
la estructura de las fases. El control de calidad tambin se ve facilitado si la
separacin entre fases se hace corresponder con puntos en los que sta deba
verificarse.
Antecedentes.
Un aspecto de atencin en la gestin de proyecto es su ciclo de vida ya que tiene
objetivos o metas ligadas a la obtencin de un producto, proceso o servicio nuevo
o mejorado, que es necesario generar a travs de diversas actividades. Algunas
de estas actividades pueden agruparse en fases porque de forma global
contribuyen a obtener un producto intermedio, necesario para continuar hacia el
producto final y facilitar la gestin del proyecto.

Definicin de Fases.
Una fase es un conjunto de actividades relacionadas con un objetivo en el
desarrollo del proyecto. Se construye agrupando tareas (actividades elementales)
que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La
agrupacin temporal de tareas impone requisitos temporales correspondientes a la
asignacin de recursos (humanos, financieros o materiales).
Cuanto ms grande y complejo sea un proyecto, mayor detalle se necesitar en la
definicin de las fases para que el contenido de cada una siga siendo manejable.
De esta forma, cada fase de un proyecto puede considerarse un micro-proyecto
en s mismo, compuesto por un conjunto de micro-fases.
Fases del proyecto.
Un proyecto no puede concebirse al margen del resto de las actividades que lleva
a cabo la organizacin. Todas las actividades contribuyen a conseguir unos fines
generales expresados en las estrategias de la organizacin. Por ello, el tipo de
organizacin influye no slo en los proyectos que se van a realizar sino tambin en
la forma en la que se realizan. Todo ello forma parte del contexto del proyecto.

El conocimiento del contexto del proyecto es un elemento fundamental para

asegurar el cumplimiento de sus objetivos.
En la gestin de un proyecto es clave conocer bien las etapas del mismo
Desde un punto de vista muy general puede considerarse que todo proyecto tiene
cinco grandes etapas:
Fase de planificacin.
Se trata de establecer cmo el equipo de trabajo deber satisfacer las
restricciones de prestaciones, planificacin temporal y costos. Una planificacin
detallada da consistencia al proyecto y evita sorpresas que nunca son bien
recibidas.
Fase de ejecucin.
Representa el conjunto de tareas y actividades que suponen la realizacin
propiamente dicha del proyecto, la ejecucin de la actividad de que se trate.
Responde, ante todo, a las caractersticas especficas de cada tipo de proyecto y
supone poner en juego y gestionar los recursos en la forma adecuada para
desarrollar la actividad o tarea en cuestin. Cada tipo de proyecto responde en
este punto a su tecnologa propia, que generalmente es bien conocida por los
miembros del equipo que desarrolla el mismo.
Fase de iniciacin.
Definicin de los objetivos del proyecto y de los recursos necesarios para su
ejecucin. Las caractersticas del proyecto implican la necesidad de una fase o
etapa previa destinada a la preparacin del mismo, fase que tienen una gran
trascendencia para la buena marcha del proyecto y que deber ser especialmente
cuidada. Una gran parte del xito o el fracaso del mismo se fraguan principalmente
en estas fases preparatorias que, junto con una buena etapa de planificacin,
algunas personas tienden a menospreciar, deseosas por querer ver resultados
excesivamente pronto.
Fase de control.
Monitorizacin del trabajo realizado analizando cmo el progreso difiere de lo
planificado e iniciando las acciones correctivas que sean necesarias. Incluye
tambin el liderazgo, proporcionando directrices a los recursos humanos,
subordinados (incluso subcontratados) para que hagan su trabajo de forma
efectiva y a tiempo.
Fase de entrega o puesta en marcha.
Es la que se culmina el proyecto con la entrega de los resultados al cliente o la
aplicacin en la prctica social en el sector correspondiente, verificando que
funciona adecuadamente y responde a las especificaciones en su momento

aprobadas. Esta fase es tambin muy importante no slo por representar la

culminacin de la operacin sino por las dificultades que suele presentar en la
prctica, alargndose excesivamente y provocando retrasos y costes imprevistos.
Descomposicin de las fases en sub-faces.
Otro motivo para descomponer una fase en subfases menores puede ser el inters
de separar partes temporales del proyecto que se subcontraten a otras
organizaciones, requiriendo distintos procesos de gestin.
Cada fase viene definida por un conjunto de elementos observables externamente,
como son las actividades con las que se relaciona, los datos de entrada
(resultados de la fase anterior, documentos o productos requeridos para la fase,
experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por
la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la
estructura interna de la fase.
Definicin de los objetivos de cada fase.
En cada fase general de un modelo de ciclo de vida, se pueden establecer una
serie de objetivos y tareas que lo caracterizan, tal y como se muestra a
continuacin:
Fase de definicin: Estudio de viabilidad.
Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de
contexto).

Asegurar que los requisitos son alcanzables.

Formalizar el acuerdo con los usuarios.
Realizar una planificacin detallada.
Fase de diseo :Soluciones en costos, tiempo y calidad
Identificar soluciones tecnolgicas para cada una de las funciones del
sistema.
Asignar recursos materiales para cada una de las funciones.
Proponer (identificar y seleccionar) subcontratos.
Establecer mtodos de validacin del diseo.
Ajustar las especificaciones del producto.
Fase de construccin, elaboracin o realizacin: Generar el producto o
servicio pretendido con el proyecto.
Integrar los elementos subcontratados o adquiridos externamente.
Validar que el producto obtenido satisface los requisitos de diseo
previamente definidos y realizar, si es necesario, los ajustes necesarios en
dicho diseo para corregir posibles lagunas, errores o inconsistencias.

Fase de mantenimiento y operacin.

Operacin: Asegurar que el uso del proyecto es el pretendido.

Mantenimiento: Esto se refiere a un mantenimiento no habitual, es decir, aquel que
no se limita a reparar averas o desgastes habituales como es el caso del
mantenimiento en productos software, ya que en un programa no se puede o cabe
hablar de averas o de desgaste
Tipos de modelo de ciclo de vida.
En dependencia de los objetivos que se deseen alcanzar en un proyecto, el mismo
estar relacionado con un modelo de ciclo de vida por lo que es conveniente
exponer las diferencias que existen entre distintos modelos.
El alcance del ciclo dependiendo de hasta dnde llegue el proyecto
correspondiente. Un proyecto puede comprender un simple estudio de viabilidad
del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al
extremo, toda la historia del producto, proceso o servicio con su desarrollo,
obtencin y modificaciones posteriores hasta su retirada del mercado.
Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas
que deben realizarse para proyectar un nuevo tipo de avin
que disear un software), o de la organizacin (inters de reflejar en la divisin en
fases aspectos de la divisin interna o externa del trabajo).
La estructura de la sucesin de las fases que puede ser lineal, con prototipo, o en
espiral.
Ciclo de vida lineal
Consiste en descomponer la actividad global del proyecto en fases que se
suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se
realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fcil dividir
las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada
fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una
fase no necesite resultados de las siguientes (realimentacin), aunque pueden
admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista
de la gestin (para decisiones de planificacin), requiere tambin que se sepa bien
de antemano lo que va a ocurrir en cada fase antes de empezarla.
Ciclo de vida con prototipo.
A menudo ocurre en desarrollo de productos, procesos o servicios con
innovaciones importantes, o cuando se prev la utilizacin de tecnologas nuevas
o poco probadas, que las incertidumbres sobre los resultados realmente

alcanzables, o las ignorancias sobre el comportamiento de las tecnologas,

impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cmo desarrollar un determinado producto o cules
son las especificaciones de forma precisa, suele recurrirse a definir
especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no
hace falta que contenga funciones que se consideren triviales o suficientemente
probadas) y provisional (no se va a fabricar realmente para clientes, por lo que
tiene menos restricciones de costos y/o prestaciones). Este tipo de procedimiento
es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su evaluacin deben permitir la
definicin de las especificaciones ms completas y seguras para el producto
definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con
prototipo repite las fases de definicin, diseo y construccin dos veces: para el
prototipo y para el producto real.
Ciclo de vida en espiral
El ciclo de vida en espiral puede considerarse como una generalizacin del
anterior para los casos en que no basta con una sola evaluacin de un prototipo
para asegurar la desaparicin de incertidumbres y/o ignorancias. El propio
producto a lo largo de su desarrollo puede as considerarse como una sucesin de
prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo
(espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en
trminos generales lo que quiere, no es capaz de definirlo en todos sus aspectos
sin ver como unos influyen en otros. En estos casos la evaluacin de los
resultados por el cliente no puede esperar a la entrega final y puede ser necesaria
repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle
en espiral, donde los cuadrantes son, habitualmente, fases de especificacin,
diseo, realizacin y evaluacin (o conceptos y trminos anlogos).
En cada vuelta el producto gana en madurez (aproximacin al final deseado)
hasta que en una vuelta la evaluacin lo apruebe y el bucle pueda abandonarse
Anlisis del proyecto.
El anlisis de sistemas es impulsado por los asuntos de negocios de los
propietarios del sistema y los usuarios de sistema. Por tanto, aborda los bloques
de construccin de conocimiento.
Proceso y comunicacin desde las perspectivas de los propietarios del sistema y
los usuarios. Los anlisis del sistema sirven como facilitadores del anlisis de

sistemas. Este contexto se ilustra en la pgina de inicio del captulo que precedi a
los objetivos del mismo.
La documentacin y los productos obtenidos por las tareas de anlisis de sistemas
por lo general se almacenan en un repositorio. ste puede ser creado para un solo
proyecto o ser compartido por todos los proyectos y sistemas. Por lo general un
repositorio se implementa como una combinacin de lo siguiente:
Un directorio de red de procesadores de palabras, hojas de clculo y otros
archivos generados en computadoras que contienen correspondencia de
proyectos, informes y datos.
Uno o ms diccionarios o enciclopedias de herramientas CASE
Documentacin impresa (como la almacenada en carpetas y bibliotecas de
sistemas).
Una interfaz de sitio Web de intranet para los componentes anteriores (til para
la comunicacin).
De manera fundamental, el anlisis de sistemas trata acerca de la solucin de
problemas.
Hay muchos mtodos para ello; por lo tanto, no le debe sorprender que haya
muchos enfoques para el anlisis de sistemas. Estos enfoques con frecuencia son
vistos como alternativas en competencia. En realidad, ciertas combinaciones
pueden y deben complementarse entre ellas.
Enfoques de anlisis basados en modelos
El anlisis estructurado, la ingeniera de informacin y el anlisis orientado a
objetos son ejemplos de un anlisis basado en modelos. Este anlisis utiliza
imgenes para comunicar problemas de negocios, requerimientos y soluciones.
Ejemplos de modelos con los que puede ya estar familiarizado incluyen diagramas
de flujo, cuadros de estructura o jerarquas y organigramas.
En la actualidad, los enfoques basados en modelos casi siempre se resaltan por el
uso de herramientas automatizadas. Algunos analistas dibujan modelos de
sistemas con software grfico de propsitos generales como Visio de Microsoft.
Otros analistas y organizaciones requieren el uso de herramientas basadas en
repositorios CASE o de elaboracin de modelos como System Architect, Visible
Architect, Visible Analyst o Rational ROSE. Las herramientas CASE ofrecen la
ventaja del anlisis consistente y completo as como una revisin de errores
basada en reglas.
Analicemos de manera breve los tres enfoques ms populares de anlisis basados
en modelos.

Mtodos tradicionales
Al inicio de la dcada de los setenta se desarrollaron diversos mtodos
tradicionales para el anlisis y el diseo de sistemas. Uno de los primeros
mtodos formales, que an es ampliamente utilizado en la actualidad es el anlisis
estructurado.
El anlisis estructurado se enfoca en el flujo de datos a travs de los procesos de
negocios y de software. Se dice que est centrado en el proceso. Por centrado en
el proceso queremos decir que el nfasis est en los componentes (bloques de
construccin) del procedo en su marco de referencia del sistema de informacin.
Una de las herramientas clave utilizadas para elaborar modelos de procesos es el
diagrama de flujo de datos que describe los procesos existentes o propuestos en
un sistema junto con sus entradas, salidas y datos. Los modelos muestran el flujo
de datos entre y a travs de los procesos y los lugares donde se almacenan los
datos. Por ltimo, estos modelos de procesos sirven como planos para que los
procesos de negocios sean implementados y que el software se adquiera o se
construya.
La prctica de anlisis estructurado para el diseo de software ha disminuido
mucho en favor de los mtodos orientados a objetos. Sin embargo, la elaboracin
de modelos de proceso disfruta un cierto reavivamiento gracias el nfasis
renovado en el rediseo de procesos de negocios, que se analizar
posteriormente en este captulo.
Otro mtodo tradicional, llamado ingeniera de informacin (IE), se enfoca en la
estructura de datos almacenados en un sistema ms que en los procesos. Por
ello, se dijo que era centrado en los datos, al enfatizar el anlisis de los
requerimientos de conocimiento (o datos). La herramienta fundamental para
modelar requerimientos de datos es el diagrama de relacin de entidad (Los
diagramas de relacin de entidades an son muy utilizados en el diseo de bases
de datos de relaciones.
En un principio, la ingeniera de informacin era vista como un mtodo en
competencia con el anlisis estructurado. Con el paso del tiempo muchas
personas los hicieron complementarios; utilizan diagramas de flujo de datos para
modelar los procesos de sistemas y los diagramas de relaciones de entidades
para modelar un sistema de datos.
Estrategia orientada a objetos
Los mtodos tradicionales separaban las preocupaciones en forma deliberada del
conocimiento (datos) de los de procesos. Aunque la mayora de los mtodos de
anlisis de sistemas intentaron sincronizar modelos de datos y procesos, ese
intento no siempre funcionaba bien en la prctica. Las tecnologas de objeto han

surgido desde entonces para eliminar esta separacin artificial de datos y

procesos. La estrategia orientada a objetos ve los sistemas de informacin no
como datos y procesos, sino como una coleccin de objetos que encapsulan datos
y procesos. Los objetos pueden contener atributos de datos. Sin embargo, la nica
forma de crear, leer, actualizar o eliminar los datos de un objeto es a travs de uno
de sus procesos incrustados (llamado mtodos).
Los lenguajes de programacin orientados a objetos como Java, C++ y los
lenguajes .NET, se vuelven cada vez ms populares.
La estrategia orientada a objetos tiene un conjunto completo de herramientas de
elaboracin de modelos conocido como Unified Modeling Language (UML). Uno
de los diagramas UML de clase de objetos, se muestra en la figura 4.4. Algunas de
las herramientas
UML han ganado aceptacin por los proyectos de sistemas incluso cuando el
sistema de informacin no sea implementado con tecnologas orientadas a
objetos.

Enfoques de anlisis de sistemas acelerados

El desarrollo de la elaboracin de prototipos de identificacin y de arquitectura
rpida son ejemplos de enfoques de sistemas acelerados que enfatizan la
construccin de prototipos para identificar con ms rapidez los requerimientos de
negocios y de usuarios para un sistema nuevo. La mayora de dichos mtodos se
derivan de alguna variacin en la construccin de prototipos, muestras funcionales
pero incompletas de un sistema deseado.
Los prototipos sirven a la forma de pensar de sabr lo que quiero cuando lo vea,
que es caracterstico de muchos usuarios y administradores. Por incompleto
queremos decir que un prototipo no incluir la revisin de errores, validacin de
entrada de datos, seguridad y totalidad de proceso de una aplicacin terminada. Ni
tampoco estar tan pulida ni ofrecer ayuda al usuario como en el sistema final.
Pero como puede ser desarrollado con rapidez, de igual forma puede identificar
los requerimientos ms cruciales de nivel de negocios. A veces, los prototipos
pueden evolucionar para convertirse en los sistemas finales, es decir, las
aplicaciones completas.
En un sentido, los mtodos de anlisis acelerado ponen mucho nfasis en los
componentes de comunicaciones en su marco de referencia de sistema de
informacin al construir formas e informes de muestras. Al mismo tiempo, las
herramientas de software utilizadas para construir prototipos tambin incluyen los
componentes de datos y procesos.

Estos mtodos acelerados son comunes en las metodologas de desarrollo rpido

de aplicaciones (rapid application development, RAD) y las rutas que fueron
presentadas en el captulo 3. Los mtodos RAD requieren herramientas
automatizadas mientras que algunas herramientas CASE basadas en repositorios
incluyen instalaciones RAD muy simples, la mayora de los analistas utilizan
verdaderos ambientes de programacin RAD, como Powerbuilder de Sybase,
Access de Microsoft, Visual Basic .NET de Microsoft o Websphere Studio for
Application Development de IBM (basado en Java).

Diseo del proyecto.

Se define el diseo de sistemas de informacin como las tareas que se enfocan en
la especificacin de una solucin computarizada detallada. Tambin se le llama
diseo fsico.
As pues, mientras que en el anlisis de sistemas se pone nfasis el problema del
negocio, el diseo de sistemas se enfoca en los aspectos tcnicos o de
implantacin del sistema.
Como se ilustra en la pgina de inicio de este captulo, el diseo de sistemas se
basa en las preocupaciones tcnicas de los diseadores de sistemas. Por tanto,
se centra en los componentes de IS desde la perspectiva de los diseadores de
sistemas. Los analistas de sistemas sirven como facilitadores del diseo de
sistemas.
Muchos de nosotros definimos muy estrictamente el proceso de diseo. Nos
imaginamos trazando esquemas de los sistemas basados en computadora para su
programacin y desarrollo en manos de nosotros mismos o de los programadores.
As pues, se disean entradas, salidas, archivos, bases de datos y otros
componentes de computadora. Los reclutadores de especialistas en cmputo
recin egresados de las universidades se refieren a esta definicin restrictiva
como el sndrome de no se invent aqu. En realidad, muchas compaas
adquieren ms paquetes de software del que crean a la medida para la propia
organizacin. Es algo que no debe sorprenderle. Por qu reinventar la rueda?
Muchos sistemas son suficientemente genricos, as mismo, los proveedores de
computadoras han creado paquetes de software adecuados aunque raras veces,
si acaso, perfectos que se pueden adquirir y posiblemente modificar para
adaptarlos a los requerimientos del usuario final.
Hay muchas estrategias o tcnicas para llevar a cabo el diseo de sistemas. Esto
abarca el diseo estructurado moderno, ingeniera de la informacin, elaboracin
de prototipos, JAD, RAD y diseo orientado a objetos. Es frecuente que se
considere a estas estrategias como alternativas que compiten entre s en el diseo
de sistemas, aunque en realidad ciertas combinaciones se complementan

mutuamente. Analicemos brevemente tales estrategias y el alcance u objetivos de

los proyectos a los que se adecuan. La intencin es desarrollar nicamente un alto
nivel de entendimiento.

Estrategias basadas en modelos

El diseo estructurado, la ingeniera de la informacin y el diseo orientado a
objetos son ejemplos de estrategias basadas en modelos. El diseo basado en
modelos pone nfasis en el trazado de modelos de sistema pictricos para
documentar los aspectos tcnicos o de implantacin de un nuevo sistema.
Los modelos de diseo suelen derivarse de modelos lgicos que se desarrollan en
una parte previa de la obra, en el anlisis basado en modelos. En ltima instancia,
los modelos de diseo de sistemas se convierten en planos para la construccin e
implantacin del nuevo sistema.
Hoy, las estrategias basadas en modelos casi siempre se mejoran con el uso de
herramientas automatizadas. Algunos diseadores trazan modelos del sistema con
software de grficos de propsito general, como Visio Professional o Corel Flow.
Otros diseadores y organizaciones requieren el uso de herramientas CASE
basado en repositorios o herramientas de modelado, como System Architect,
Microsoft Visio, Visible Analyst o Rational de IBM. Las herramientas de CASE
brindan consistencia e integridad, adems de verificacin de errores basada en
reglas.
En seguida examinaremos las estrategias de diseo basado en modelos ms
usadas.

Diseo estructurado moderno.

Las tcnicas de diseo estructurado ayudan a los desarrolladores a manejar el
tamao y complejidad de los programas. El diseo estructurado moderno es una
tcnica orientada a procesos para dividir un programa grande en una jerarqua de
mdulos, lo que da por resultado un programa de computadoras ms fcil de
implantar y mantener (cambiar). Sus sinnimos (si bien tcnicamente imprecisos)
son diseo descendente de programas y programacin estructurada.
El concepto es sencillo. Se disea un programa como una jerarqua descendente
de mdulos. Un mdulo es un conjunto de instrucciones: un prrafo, bloque,
subprograma o subrutina. La estructura descendente de estos mdulos se
desarrolla de conformidad con diversas reglas y normas de diseo. (Por tanto,
trazar simplemente una jerarqua o grfico estructural de un programa no es
diseo estructurado.)

El diseo estructurado se considera como tcnica orientada a procesos porque

hace nfasis en los componentes de PROCESO del sistema de informacin, de
manera especfica, en los procesos de software. El diseo estructurado busca
dividir un programa en una jerarqua descendente de mdulos que tengan las
propiedades siguientes:
Los mdulos deben tener mucha cohesin, es decir, cada mdulo debe
encargarse de una y slo una funcin. Esto hace que los mdulos sean
reutilizables en programas futuros.
Los mdulos deben acoplarse, lo cual significa que su dependencia mutua debe
ser mnima. Ello minimiza el efecto que los cambios futuros en un mdulo tendrn
en otros mdulos.
La cohesin y el acoplamiento tambin son conceptos importantes en el mundo
orientado a objetos. El modelo de software que se deriva del diseo estructurado
se llama grfico de estructura. Este grfico se obtiene mediante el estudio del flujo
de datos por el programa. El diseo estructurado se realiza durante el diseo de
sistemas. No comprende todos los aspectos del diseo; por ejemplo, el diseo
estructurado no ayuda a disear las entradas, salidas o bases de datos.
El diseo estructurado ha perdido una parte de su popularidad a raz de que
muchas aplicaciones actuales requieren tcnicas ms novedosas, enfocadas en
tcnicas de programacin orientadas a eventos u orientadas a objetos. Sin
embargo, todava es una tcnica muy utilizada en el diseo de software de
aplicaciones para mainframe y se utiliza para hacer frente a las cuestiones de
acoplamiento y cohesin en el nivel de sistema.

Ingeniera de la informacin
(IE, por sus siglas en ingls) es una tcnica de planeacin, anlisis y diseo de
sistemas de informacin basada en modelos y centrada en datos, si bien es
sensible a procesos.
La herramienta principal de la IE es un diagrama de modelo de datos.
La IE implica realizar un anlisis de requerimientos del rea de negocios, a partir
del cual se definen y jerarquizan las aplicaciones del sistema de informacin.
Estas aplicaciones identificadas en la IE se vuelven proyectos, a los que se
pretende aplicar otros mtodos de anlisis y diseo de sistemas para desarrollar
los sistemas de produccin. Tales mtodos podran incluir alguna combinacin de
anlisis y diseo estructurado moderno, elaboracin de prototipos, anlisis y
diseo orientados a objetos.
Diseo orientado a objetos

El diseo orientado a objetos (OOD, por sus siglas en ingls) es la estrategia de

diseo de advenimiento ms reciente. La figura muestra algunos de los
numerosos diagramas usados en el diseo orientado a objetos.
Las tecnologas y tcnicas de objetos son un intento por eliminar la separacin
entre Datos y procesos. Las tcnicas de OOD se usan para refinar las definiciones
de requerimientos de objetos identificadas con anterioridad, durante el anlisis, y
para definir objetos de diseo especfico.

A manera de ejemplo, durante el OOD podra ser necesario que el diseador

revise las caractersticas de datos
o procesos de un objeto definido
durante el anlisis del sistema,
esto con base en una decisin de
implantacin de diseo. De
manera similar, una decisin de
este tipo puede hacer que el
diseador defina un nuevo
conjunto de objetos, con una
pantalla de interfaz que permita a
los usuarios interactuar con el
nuevo sistema.

Determinacin de requerimientos.
Muchos analistas inexpertos cometen un error crtico luego de completar la fase
de anlisis del problema. La tentacin en ese punto es comenzar a considerar
alternativas de solucin, particularmente tcnicas. Uno de los errores citados con
mayor frecuencia en los nuevos sistemas de informacin se ilustra en la frase
seguro, el sistema funciona y tcnicamente es impresionante, pero no hace lo que
nosotros necesitamos. La fase de anlisis de requerimientos define los
requerimientos de negocios para un sistema nuevo.
Not la palabra clave en la oracin citada? es que y no cmo! Los analistas
con frecuencia estn tan preocupados por la solucin tcnica que
inadecuadamente definen los requerimientos de negocios para esa solucin. La
fase de anlisis de requerimientos responde la pregunta, Qu necesitan y
desean los usuarios de un sistema nuevo? La fase de anlisis de requerimientos
es crtica para el xito de cualquier sistema nuevo de informacin. En distintas
metodologas la fase de anlisis de requerimientos podra ser llamada fase de
definicin o fase de diseo lgico.

Se puede alguna vez pasar por alto la fase de anlisis de requerimientos?

Definitivamente no! Los nuevos sistemas siempre sern evaluados, primero y
sobre todo, acerca de si cumplen o no con los objetivos y requerimientos del
negocio, sin importar qu tan impresionante o compleja pueda ser la solucin
tcnica!
Debe reconocerse que algunas metodologas integran las fases de anlisis del
problema y anlisis de requerimientos en una sola fase.
Una vez ms, sus componentes de sistemas de informacin pueden servir como
un marco de referencia til para documentar los requerimientos de sistemas de
informacin.
Ntese que seguimos ocupados con las perspectivas de los usuarios del sistema.
Los requerimientos pueden ser definidos en trminos del marco laboral PIECES o
en trminos de los tipos de datos, procesos e interfaces que deben ser incluidos
en el mismo.

La fase de anlisis de requerimientos generalmente incluye las siguientes tareas:

1.
2.
3.
4.

Identificar y expresar los requerimientos del sistema.

Priorizar los requerimientos de sistema.
Actualizar o refinar el plan de proyecto.
Comunicar la definicin de requerimientos.

Ahora analicemos cada una de estas tareas con mayor detalle.

Tarea 1: Identificar y expresar los requerimientos del sistema
La tarea inicial de la fase de anlisis de requerimientos es identificar y expresar
requerimientos.
Mientras que esto puede parecer como una tarea fcil o trivial, a menudo es la
fuente de muchos errores, omisiones y conflictos. La base para esta tarea se
estableci en la fase de anlisis del problema cuando identificamos objetivos de
mejora de sistemas. En forma mnima, esta tarea traduce estos objetivos en un
esquema de requerimientos funcionales y no funcionales que se necesitarn para
cumplir con los objetivos. Los requerimientos funcionales son frecuentemente
identificados en trminos de entradas, salidas, procesos y datos almacenados que
son necesarios para satisfacer los objetivos de mejora del sistema.
Ejemplos de requerimientos no funcionales incluyen desempeo (tiempo de
desempeo y de respuesta); facilidad de aprendizaje y uso; presupuestos, costos
y ahorros de costos; cronogramas y vencimientos; documentacin y necesidades

de capacitacin; administracin de la calidad y controles de auditoria interna y

seguridad.
Rara vez esta tarea de definicin identifica todos los requerimientos de negocios
funcionales y no funcionales. Pero este esquema enmarcar su pensamiento
mientras procede con tareas posteriores que agregarn nuevos requerimientos y
detalles al mismo. Por tanto, ni la totalidad ni la perfeccin son una meta en esta
tarea.
Los analistas de sistemas facilitan la tarea. Tambin documentan los resultados.
Evidentemente, los usuarios del sistema son la fuente principal de los
requerimientos de negocios. Algunos propietarios del sistema pueden elegir
participar en esta tarea ya que tuvieron un papel en la estructuracin de los
objetivos de mejora del sistema que guiarn la tarea. Los diseadores y
constructores del sistema no deben participar porque tienden a redirigir
prematuramente el enfoque a la tecnologa y a las soluciones tcnicas.

El nico producto a obtener en esta tarea son los requerimientos funcionales y no

funcionales. Diversos formatos pueden funcionar. En su formato ms simple, el
esquema puede ser dividido en cuatro secciones lgicas: la lista original de los
objetivos de mejora de sistemas, una sublista de a) entradas, b) procesos, c)
salidas y d) datos almacenados necesarios para satisfacer el objetivo. Sin
embargo, cada vez ms, los analistas de sistemas expresan requerimientos
funcionales mediante una herramienta de elaboracin de modelos llamada casos
de uso. Los casos de uso elaboran modelos de escenarios de negocios y sucesos
que deben ser manejados por un sistema nuevo. Se presentan en el captulo 6 y
se utilizan a lo largo de este texto.
El marco de referencia PIECES que fue utilizado anteriormente para identificar
problemas, oportunidades y restricciones tambin puede utilizarse como marco
laboral para definir los requerimientos del borrador.
Diversas tcnicas son aplicables a esta tarea. La planeacin de requerimientos
conjuntos (joint requirements planning, JRP) es la tcnica preferida para delinear
con rapidez los requerimientos del negocio. De manera alternativa, los analistas
podran utilizar otros mtodos de identificacin de hechos como encuestas y
entrevistas.

Tarea 2: Priorizar los requerimientos del sistema

Anteriormente comentamos que el xito de un proyecto de desarrollo de sistemas
puede ser medido en trminos del grado en el que se satisfacen los
requerimientos del negocio.

Pero no todos los requerimientos se crean igual. Si un proyecto se retrasa en

horario o sobre el presupuesto, puede ser til para reconocer qu requerimientos
son ms importantes que otros. Por tanto, dados los requerimientos validados, los
propietarios del sistema y los usuarios del sistema deben priorizar los
requerimientos del sistema.
Otorgar prioridades a los requerimientos puede facilitarse por medio de una
tcnica popular llamada timeboxing. El timeboxing intenta dividir requerimientos en
partes que puedan ser implementadas dentro de un periodo que no acabe con la
paciencia del usuario y de la comunidad administrativa. El timeboxing obliga a que
las prioridades sean definidas claramente.
Los analistas de sistemas facilitan la tarea de clasificacin de prioridades. Los
propietarios y usuarios de los sistemas establecen las prioridades actuales. Los
diseadores y los constructores de sistemas no participan en la tarea. La tarea es
realizada cuando los requerimientos son vlidos. Debe resultar evidente que usted
no pueda otorgar prioridades adecuadamente a un conjunto de requerimientos
incompleto. El producto de esta tarea es obtener requerimientos son propiedades.
Las prioridades pueden ser clasificadas de acuerdo con su importancia relativa:
Un requerimiento obligatorio es aqul que debe ser satisfecho por la mnima
versin del sistema (versin 1.0.) El sistema es intil sin l. Tenga cuidado!, existe
la tentacin de etiquetar demasiados requerimientos como obligatorios. Un
requerimiento obligatorio no puede ser clasificado porque es esencial para
cualquier solucin. De hecho, si un requerimiento obligatorio puede ser clasificado
en orden de importancia, en realidad es un requerimiento deseable.
Un requerimiento deseable es aqul que no es absolutamente esencial a la
versin mnima del sistema (versin 1.0). Puede an ser esencial para la visin de
alguna versin futura. Los requerimientos deseables pueden y deben ser
clasificados. El uso de nmeros de versin como esquema de clasificacin es una
forma eficaz de comunicar y categorizar los requerimientos deseables.

Tarea 3: Actualizar o refinar el plan del proyecto

Nuevamente, recordemos que el alcance del proyecto es un objetivo mvil. Ahora
que hemos identificado los requerimientos del sistema, debemos regresar y
redefinir nuestra comprensin del alcance del proyecto y actualizar en
consecuencia nuestro plan de proyecto. El equipo debe considerar la posibilidad
de que el nuevo sistema pueda ser ms grande de lo originalmente esperado. Si
es as, en consecuencia, el equipo debe ajustar el programa, presupuesto o
alcance. Debemos tambin asegurar la aprobacin para que el proyecto contine
hacia la siguiente fase. (Puede que el trabajo ya se haya iniciado en las fases de
diseo; sin embargo, las decisiones todava requieren una revisin.)

El administrador del proyecto, en conjunto con los propietarios del sistema y el

equipo de proyecto completo, facilitan esta tarea. Como siempre, el administrador
del proyecto y los propietarios del sistema son los individuos clave en esta tarea.
Deben considerar la posibilidad de que los requerimientos ahora excedan la visin
original que se estableci para el proyecto y el nuevo sistema. Pueden tener que
reducir el alcance para cumplir con un vencimiento o incrementar el presupuesto
para que el trabajo se realice.

Tarea 4: Comunicar la definicin de requerimientos

La comunicacin es una tarea continua de la fase de anlisis de requerimientos. A
lo largo de la fase, debemos comunicar requerimientos y prioridades para la
comunidad de negocios.
Los usuarios y administradores con frecuencia abogarn por una consideracin de
requerimientos y prioridades. La comunicacin es el proceso a travs del cual se
deben mediar las diferencias de opinin. El administrador del proyecto y el
patrocinador ejecutivo conjuntamente deben facilitar esta tarea. Actualmente, una
intranet o un portal de proyecto se utilizan con frecuencia para comunicar los
requerimientos. Algunos sistemas permiten a los usuarios y administradores
acceder a los documentos de requerimientos para asegurarse de ser notificados
conforme ocurran los cambios. Las habilidades interpersonales, de comunicacin
y negociacin son esenciales para esta tarea.

Manejo de requerimientos permanentes

La fase de anlisis de requerimientos est ahora completa. O no? Alguna vez fue
popular congelar los requerimientos del negocio antes de empezar las fases de
diseo de sistemas y las de construccin. Pero la economa actual se ha vuelto
cada vez ms acelerada. Los negocios se miden de acuerdo con su capacidad
para adaptarse con rapidez a requerimientos y oportunidades constantemente
cambiantes. Los sistemas de informacin no pueden ser menos cambiantes que el
negocio mismo. Por tanto, el anlisis de requerimientos realmente nunca termina.
Mientras que hacemos una transicin silenciosa hacia las fases restantes de
nuestro proyecto, contina una necesidad constante de manejar requerimientos a
travs del curso del proyecto y la vida del sistema.
El manejo de los requerimientos define un proceso para los propietarios, usuarios,
analistas, diseadores y constructores del sistema para enviar los cambios
propuestos a los requerimientos de un sistema. El proceso especific cmo se
deben solicitar y documentar los cambios, cmo se registrarn y rastrearn y
cundo y cmo se evaluarn para saber su prioridad y la forma en que
eventualmente sern satisfechos (si alguna vez sucede).

 Tcnicas para obtener requerimientos.

Existe un gran nmero de tcnicas para obtener requerimientos. A continuacin
describo 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 importante la
forma en que se plantea la conversacin y la relacin que se establece en la
entrevista.
Estos son algunos de los 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.
Desarrollo Conjunto de Aplicaciones (JAD).
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.
Desarrollo 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:
Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
Durante el desarrollo del prototipo, el personal del desarrollo de software puede
darse cuenta de que los requerimientos son 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.

En general, el uso de esta tcnica es un medio que permite solventar objeciones

del usuario del tipo: No s exactamente lo que quiero, pero lo sabr cuando lo
vea. Por lo general, la construccin de prototipos incrementa los costos en las
etapas iniciales de un proyecto, pero esto se recupera en etapas posteriores
gracias al mejor entendimiento de los requerimientos por parte de los
desarrolladores. En algunos casos tambin se utiliza como un medio para
formalizar la aceptacin previa del cliente de los requisitos del proyecto.
Observacin.
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 documentacin.
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.
El inconveniente es que la respuesta puede ser limitada, ya que es posible que no
tenga mucha importancia para los encuestados llenar el cuestionario. Es
recomendable conseguir apoyo de la alta direccin para solicitar a las personas de
la organizacin que contesten el cuestionario.
Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista
debe asegurar que el conocimiento y experiencia de stos califiquen para dar
respuestas a las preguntas.
Tormenta de ideas (Brainstorming),
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.
ETHICS (Implementacin Efectiva de Sistemas Informticos desde los puntos de
vista Humano 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 productividad) en funcin de dichos anlisis.
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, que implica descubrir los que reciben los
servicios del sistema e identificar los servicios especficos que se suministran a
cada punto de vista.
Estructuracin de puntos de vista, que comprende agrupar los relacionados en
una jerarqua. Los servicios comunes se ubican en los niveles altos de la jerarqua
y se heredan los puntos de vista de bajo nivel.
Documentacin de puntos de vista, que comprende refinar la descripcin de stos
y los servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en
un diseo orientado a objetos utilizando la informacin del servicio encapsulado en
los 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 convenciones para los diagramas utilizados en los escenarios de eventos son:
Los datos proporcionados desde un punto de vista o proporcionados a ste se
representan como elipses.
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.
Los Casos de Uso son una tcnica que se basa en escenarios para la obtencin
de requerimientos. Actualmente se han convertido en una tcnica fundamental que
se utiliza para analizar y describir modelos de sistemas orientados a objetos. En
su forma ms simple, un caso de uso identifica a los actores involucrados en una
interaccin y nombra al tipo de sta.
Etnografa.
Los sistemas de software no existen de forma aislada; se utilizan en un contexto
social y organizacional, y los requerimientos de sistemas de software se derivan y
se restringen acorde a ese contexto. Satisfacer esos requerimientos sociales y
organizacionales es crtico para el xito del sistema. Una razn de por qu
muchos sistemas de software se entregan pero nunca se utilizan es porque no se
toma en cuenta la importancia de este tipo de requerimientos.
La etnografa es una tcnica de observacin que se puede utilizar para entender
los requerimientos sociales y organizacionales. Un analista se sumerge por s solo
en el entorno laboral donde el sistema se utilizar. El trabajo diario se observa y se
hacen notas de las tareas reales en las que los participantes estn involucrados.
La etnografa es especialmente efectiva para descubrir dos tipos de
requerimientos:
Los requerimientos que se derivan de la forma en la que la gente trabaja
realmente ms que de la forma en la que las definiciones de los procesos
establecen que debera trabajar.

Los requerimientos que se derivan de la cooperacin y conocimiento de las

actividades de la gente.
Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que
otras tcnicas de obtencin de requerimientos a menudo olvidan. Sin embargo,
puesto que se centran en el usuario final, este enfoque no es apropiado para
descubrir los requerimientos organizacionales o del dominio. La etnografa
tampoco est diseada para identificar nuevas propiedades a agregar al sistema.
Por lo tanto, la etnografa no es un enfoque completo para la obtencin de
requerimientos y debe utilizarse en conjunto con otras tcnicas, como el anlisis
de casos de uso.

Bibliografa.

http://sg.com.mx/revista/17/obtencion-requerimientos-tecnicas-y

estrategia#.V76WwZjhDIU
http://www.ecured.cu/Ciclo_de_Vida_de_un_Proyecto
Libro: Anlisis de Sistemas. Diseo y Mtodos.