UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL

Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

QUE ES EL ANÁLISIS DE DISEÑO DE SISTEMAS

El Propósito del análisis y Diseño

El análisis es el proceso de determinar que se necesita hacer, antes de decir como debe
hacerse. El diseño es el proceso de determinar cual de muchas posibles soluciones es la
mejor para lograr lo que se necesita hacer, respetando las restricciones tecnológicas y de
presupuesto del proyecto. El diseño escoger un como especifico para aplicarlo al que. El
análisis es el acto de descubrimiento. El diseño es el arte del compromiso.
Tradicionalmente, los esfuerzos de análisis han tenido una dudosa reputación en el
desarrollo de software. Casi todos saben de algún proyecto al que se dedicaron
incontables meses (o a veces años) dibujando miles de burbujas, fichas, cuadros y líneas,
solo para ser abandonado en un librero y comenzar a codificar apresuradamente. Talvez
también halla sabido de algún proyecto que se salto cualquier pretensión de análisis y
comenzó la codificación desde el primer día.
La construcción de software es igual a la construcción de una casa. Muy pocas gentes en
sus cabales comprarían un terreno, contrataría a quince carpinteros y les diría:
“constrúyanme una casa”, dejándoles en el campo con un montón de madera y una caja
de clavo para que lo hagan a su real saber y entender. (Los carpinteros no estarían muy
preocupados, debido a que ya han construido casas, por lo tanto, si se presentan dudas
sobre su detalle, tales como la cantidad de cuartos o pisos que se quieren, con seguridad
serían capaces de resolver entre ellos)
El costo de tal tontería podría estar entre los cien o doscientos mil dólares y produciría
una estructura bastante extraña. Es muy probable que el propietario no estará
completamente satisfecho con el resultado, y es posible que la casa sea completamente
inhabitable.
Aunque parezca tan loca la historia de este propietario de casa con sus retos

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

arquitectónicos, no es nada en comparación a los millones de dólares perdido cada año

en proyectos de software, los cuales fallan para entregar los que los usuarios necesitan o
se derrumban completamente sin entregar nada. Así como seria tonto culpar a los
carpinteros por su falla para producir una casa decente bajo esas circunstancias, es raro
el caso en que un proyecto de desarrollo de software falle debido a la falta de
habilidades técnica por parte del personal de programación. La mayoría de los proyectos
que fracasan lo hacen por falta de una buena administración del proyecto y por fallas en
el análisis de la necesidad del negocio y para diseñar una solución antes de realizar la
construcción del producto.
Se podría decir que el propósito del analista y diseño es, al menos evitar que se caiga el
proyecto, y lo óptimo, que articule completamente las necesidades del negocio con base
en una comprensión de sus problemas actuales y que encuentre la solución que mejor
satisfaga las necesidades y se ajuste a las restricciones presupuestales de recursos y
tiempo impuesta por el propio negocio. Un arquitecto residencial determina los deseos,
gustos, problemas particulares, necesidades y presupuesto del propietario de la casa y
luego explora la solución de diseño para verificar y validar los requerimientos antes de
construir. El analista de software define la naturaleza del problema del negocio y el
diseñador de software explora las diversas soluciones, tomando decisiones bien
informadas para llegar a un producto que dejara a los usuarios satisfechos.
Esto se reduce a un concepto muy simple “Encuentre lo que el negocio requiere que se
haga antes de comenzar a imaginarse como hacerlo”.
El factor que complica todo es que los negocios no son simples y sus problemas
intrínsecos crecen por la presencia de personas con diferentes opiniones sobre la manera
de resolverlos (o incluso si siquiera deben resolverse), y todo el lio este coronado con un
laberinto inexpugnable de sistemas heredados muy enfermos.

Las habilidades de un analista

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

El papel del analista es ir y encontrar que problema existe en el negocio y determinar lo

que desean que suceda quienes están a cargo del mismo. Este es un papel y un conjunto
de responsabilidades radicalmente diferente a las de, por ejemplo, un programador, cuyo
trabajo es escribir código confiable. Es razonable entonces que las habilidades que se
requieren en el analista sean diferentes de las que se requieren en el programador.
No me termina de gustar los términos “analista de negocio” y “analista de software”,
debido a que los analistas exitosos son una mezcla de ambos. Como analista necesita
estar consciente en forma muy precisa de la manera en que un negocio hace dinero.
Como veremos en el capitulo 2 los sistemas de información de negocio existen para
contribuir a ellos. Por otro lado, el objetivo del juego es construir software. Por esta
razón, el analista no puede desentenderse completamente de los principios básicos de la
automatización. Necesita estar profundamente consiente de lo que es posible, factible y
practico en lo que se refiere a la computación en el negocio.
En términos generales el analista es un investigador, ya que el análisis es un proceso de
descubrimiento. El analista debe estar a gusto en el papel de arqueólogo, desenterrando
gemas de datos desconocido de entre el naufragio de los archivos planos de un sistema
heredado, o descifrando lo geroglifico de un antiguo algoritmo de algún programador
que ya ha muerto. Muchas veces el analista se convierte en un sociólogo que es forzado
a aventurarse y vivir entre la tribu para aprender sus costumbres y dialectos y para
separar su mitología de la realidad.
También son de gran importancia las buenas habilidades para la comunicación. El
análisis no es una actividad “sosegada y sin sobresalto”. En la fase de análisis de un
proyecto se pasará gran parte del tiempo sacando información de los posibles usuarios
del sistema, recarganizando lo que aprende y volviéndolo a presentar para su validación.
Tal vez sea llamado para hacer diplomacia resolviendo conflicto y dando soluciones
entre facciones del negocio que esta en guerra, o pasara tiempo en el papel de consejero

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

de campamento alidiando el miedo que los usuarios tienen al cambio.

Algunas empresas de IT (Tecnologia de información) tiene la creencia de que si una
persona se pasa dos años encerrada en su cubículo dando mantenimiento a código
COBOI., obtiene mágicamente el conjunto de habilidades mencionada anteriormente y
asciende a un orden de existencia superior: “Analista - Programador”. Desgraciadamente
esto no es cierto. Al igual que muchas otras habilidades en la vida, un buen analista se
crea por medio de practica dedicada y aptitud para el trabajo. El analista necesita el
entrenamiento adecuado y un ambiente en donde pueda pulir su talento por medio de la
repetición de las técnicas analíticas.
Muchos programadores talentosos se convierten en analistas excelentes, sin embargo, la
programación no es un requisito previo para el trabajo del analista. El conjunto de
habilidades y aptitudes que se requieren para hacer ambas cosas es muy dispar y tal vez
no siempre se ve en la misma persona. En muchos establecimientos de IT, el ascenso a
“programador-analista” involucra muy poco o ningún cambio en la cantidad de
programación requerida para el trabajo, y, de hecho, se pasa muy poco tiempo
realizando análisis. En esta situación, “analista” es un título indicativo únicamente del
nivel de salario.
La realidad es que ningún esfuerzo de desarrollo de software de tamaño apreciable
puede hacerse sin las habilidades de buenos administradores, analista y tecnólogos. Una
empresa de TI con buen personal tratara de atraer y cultivar estos tres conjuntos de
habilidades dentro de la organización y recompensara a cada uno de estos de acuerdo a
sus experiencias.
Algunos establecimientos han mostrado éxitos convirtiendo a usuarios de sistemas en
analistas, aunque esto, por lo general, requiere algún grado de entrenamiento sobre los
detalles de la automatización. Muchos colegios de educación superior y universidades
ahora están ofreciendo cursos sobre negocios con una concentración de la tecnología de
la información, o aumentando su curriculum en ciencia de la computación con cursos

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

sobre contabilidad, mercadotecnia, producción y administración en general. Este es

precisamente el tipo de fundamento educativos que forman una base solida para una
carrera como analista.

Las habilidades de un diseñador

El diseñador es un bicho ligeramente diferente al analista. Mientras el enfoque del

analista esta orientado principalmente hacia los negocios, con una fuerte base en la
tecnología; el enfoque del diseñador es principalmente sobre la tecnología con una fuerte
base en los negocios.
El diseño se refiere casi completamente a los compromisos. El diseñador se enfrenta con
la enorme tarea de mapear los requerimientos del negocio, con la tecnología disponible.
El analista se puede dar el lujo de suponer una tecnología perfecta. El documenta los
requerimientos del usuario como si todos los procesadores fueran infinitamente rápidos
y todos los datos estuvieran disponible instantáneamente. Sin embargo, el diseñador
debe hacer que los deseos y fantasías de los usuarios se ejecuten en el lastimero conjunto
de maquinas que pone a su disposición el departamento de IT.
El diseñador traza los planos a partir de los cuales se construirán el sistema, lo que lo
convierte en parte ingeniero y en parte artesano, un buen diseñador es creativo, lleno de
recursos e inteligente al evaluar opciones entre soluciones que no son perfectas. Las
habilidades de un diseñador están mucho mas cercanos a la de un programador. De
hecho, la mayoría de los diseñadores provienen del grupo de programadores. Aunque la
programación no siempre es un requisito previo para llegar a ser un buen diseñador, se
debe tener un buen entendimiento de las capacidades del ambiente de destino, para
diseñar sistemas que aprovechen sus fortalezas y eviten sus fallas más notorias.

Que se necesita para que un proyecto cliente/servidor sea exitoso

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

El secreto del desarrollo éxitos en los ambientes cliente/servidor multiplataforma

actuales en realidad no es ningún secreto. Toma a la gente adecuada a la administración
sensata y a una buena metodología. Por supuesto, no hace daño tener una gran bolsa de
dinero a la mano, pero debido a que este libro no trata de la obtención de fondos para los
proyectos cliente/servidor, regresemos al tema “la gente adecuada”.

La gente adecuada
La era del técnico con conocimientos generales

En algunas ocasiones, cuando estoy ante un público de programadores y gerente de

proyectos me gusta plantearles la pregunta: “¿cuándo fue la última vez que sintieron que
sabían todo en esta industria?”. Los programadores más jóvenes me han visto como si
estuviera loco, pero algunos de los participantes más antiguos han caído en una
ensoñación haciendo un breve recuerdo y después de eso se oyen fechas que se
mencionan con añorancia y reverencia, “19967”, “1974”, “junio de 1979”.
A mediado y finales de los 70, el establecimiento con mainframe típico tenia todo bajo
control desde un punto de vista tecnológico. Los lenguajes empleados para mover datos
hacia y desde archivos el poner pequeños caracteres verdes en pantalla de terminal o
procesar grandes cantidades de datos estaban bien establecido. Si un proyecto necesitaba
mas ayuda, un gerente podía tomar un teléfono y tener un pelotón de guerreros de bits
calificados que le enviaban del semillero local de programadores. Era típico a principio
de los 80 ver un curriculum que se basaba en mas de 20 años de experiencia en
programación en un leguaje determinado. Si se tenían problema de hardware se podía
llamar a un vendedor especificado por la empresa y enviaba un equipo de técnicos
vestido de azul en el siguiente vuelo.
Los mecanismos de la mainframe estaban bien comprendidos y un buen técnico en

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

general podría montar cintas, estructurar archivos, escribir lógica de programación y

manejar pantallas. Aunque había algunas áreas de especialidad que estaban emergiendo
en aquella industria, la mayoría de los trabajadores de procesamiento de datos hacia un
poco de todo. Con un conjunto de recursos muy homogéneo, un gerente de proyecto
podía casi siempre salir de problemas lanzando suficiente gente ante cualquier problema,
seguro en la creencia de que ellos sabrían como resolverlos y lo harían.
Todo podrían ir a casa a la noche sabiendo que el almacén empresarial de todo el
conocimiento estaba seguro en la mainframe. Era especialmente reconfortante para los
gerentes de procesamiento de datos de esa era, el saber que esta era la única alternativa.
Su personal era competente, altamente intercambiable y los usuarios no tenían ni otro
lugar a donde ir.
Todo el sentimiento de control termino con la llegada de la pc (computadora personal).
Las primeras computadoras personales comenzaron a aparecer en las oficinas
administrativas de muchos negocios al principio de los 80. Muchos establecimientos de
mainframes tallaron al reconocer la importancia de estas anémicas maquinitas, y las
clasificaron juntos con la calculadora de bolsillo, las maquinas de escribir y las
sumadoras. Los usuarios vieron a la pc como su salvador, liberándolos de las garras
malignas de las mainframes terroríficas e inflexibles y sus sirvientes vestidos de blanco
en el cuarto de vidrio con aire acondicionado.

La tendencia hacia la especialización.

Los gerentes de las IT que se ocultaron en el refugio anti bomba en el boom de la
tecnología de los 80 emergieron en un paisaje completamente extraño en los 90. Un
departamento IT robusto ya no esta compuesto de repeticiones del mismo conjunto de
habilidades. En forma muy similar a la profesión médica, el cuerpo de conocimiento
requerido para mantenerse al tanto con la explosión tecnológica ha llegado a ser tan
grande que la especialización es obligatoria. Un equipo de desarrollo necesita

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

habilidades en análisis de negocios, modelado de eventos, modelado de información,

diseño de interfaces, diseño de bases de datos, representación de usuario, resolución de
asuntos de negocios, administración de base de datos, administración de bibliotecas y de
clases de objetos, comunicaciones en red hardware y operación de sistema host,
hardware y operación de computadoras personales programación de interfaces graficas
de usuario, programación orientada a objeto experiencias en SQL, programación
tradicional, intercambio electrónico de datos, administración de proyectos, planeación y
ejecución de pruebas, entrenamiento de usuarios, administración de ayuda,
administración de liberaciones de software, control de versiones, etc. (discúlpenme si no
mencione su especialidad favorita).
Esto no quiere decir que al técnico con conocimiento generales le halla pasado lo mismo
que al vendedor de helado. Un equipo de desarrollo estelar casi siempre se mantiene
junto por uno cuantos profesionales con conocimientos generales que saben lo suficiente
a cerca de cada especialidad para ayudad a orquestar el esfuerzo técnico. Tampoco
quiero implicar que se tiene que contratar a un grupo diferente para cada necesidad. La
mayoría de las personas llegan con suficientes experiencias en varias áreas, sin embargo,
es muy poco probable esperar que una persona logra ser competente en todas o la
mayoría de las habilidades que se listaron. La complejidad de las herramientas de
desarrollos actuales, junto con la avalancha de automatización en cada uno de las facetas
de la empresa de negocios, demanda un nivel de experiencia en cada área que esta mas
allá de lo que es razonable esperar de un solo individuo.
La clave para reunir un equipo exitoso no solamente es contar con la cantidad necesaria
de personas inteligentes y lanzarlas ante el problema. En vez de ello, lo que hay que
hacer, es construir una matriz de habilidades necesaria a lo largo de la duración del
proyecto y determinar cuales se necesitan y en que momento. Luego el gerente del
proyecto puede buscar un equipo modular que proporcione la continuidad del proyecto y
que mejore el equipo con especialistas que pueden rotarse por poco tiempo en los

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

distintos grupos, proporcionando así las habilidades criticas solamente cuando sean
necesario.

La gran complejidad del ambiente cliente/servidor actual nos esfuerza a reconocer que
no podemos apoyaros completamente en técnicos con conocimientos generales.
Necesitamos gentes que tengan grandes habilidades en áreas que tengan curvas de
aprendizajes amplias y con gran pendiente. Las especialidades se cultivan con
experiencias repetidas. El permitir que un individuo se involucre en el mismo tipo de
tareas una y otra vez es la mejor forma para construir habilidades. Esta aseveración es un
reto para muchas estructuras organizacionales de IT tradicionales, en donde grupo de
programadores construyen un sistema para una parte particular de negocio y luego se
mantienen ahí y le dan mantenimiento hasta que el sistema o los programadores se
retiren o mueran de vejez. En vez de ellos, los establecimientos de IT necesitan
concentrarse en la construcción de habilidades especificas permitiendo que la gente se
mueva de proyecto en proyecto para que pueda sobrepasar la capacidad apenas
suficiente y elevarse al nivel de experto que demandan los sistemas de negocios
actuales.

Administración solida de un proyecto

La labor del gerente del proyecto es planear y asignar el trabajo, medir el avance
continuamente y ajustar el plan con base en sus mediciones, esta es una tarea imposible
a menos de que se tenga algún plan contra el cual medir el avance.
Este libro detalla una seria de técnicas para la realización de análisis y diseño de
sistemas cliente/servidor y aplicaciones de la GUI (interfaz gráfica de usuario). Una
técnica es un método estructurado y repetible para lograr una tarea específica. Ejemplo
de técnicas en este libro incluyen modelado de eventos, modelado de información y

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

diagramado de navegación por ventanas. Una metodología de ingeniería de software es

el acomodo ordenado de las técnicas en un enfoque sistemático para la construcción o
adquisición de sistema de información.
Mientras que los analistas, diseñadores y desarrolladores individuales son responsables
del dominio y la ejecución de las técnicas, el gerente de proyecto sirve como la fuerza
conductora para ordenar la tarea en una tecnología coherente a fin de satisfacer los
objetivos del proyecto. El gerente de un proyecto de desarrollo de software es muy
similar al contratista general en un proyecto de construcción. El gerente de construcción
se asegura que las cuadrillas de concreto, los enmarcadores, los que hacen el lecho, los
plomeros, los electricistas y las cuadrillas de paredes lleguen al proyecto en la fecha
adecuada y coordina sus esfuerzos. De la misma forma, el gerente de desarrollo de
software tiene que hacer malabarismos con las agendas y calendarios de las cuadrillas de
red y de hardware, los analistas de negocios, los diseñadores de interfaces, los
especialistas en comunicaciones, los programadores, los probadores y los entrenadores.
Entre mas grande sea el proyecto es mas probable que esto sean equipos individuales de
personas y no simplemente papeles representado por las mismas personas.

Metodología Solida
Sobre espirales y cascadas

La metodología viene en muchas formas y tamaños. Mucho se ha dicho a cerca de las

ventajas de la “metodología de espiral” contra la “metodología de cascada”. Otros
conceptos en el campo de la metáfora incluyen pirámides, remolinos, vértices y algo que
parece jorobas de caballos traslapantes. Sus filosofías van desde el enfoque de recetario
draconiano, hasta “la programación evolucionaria”, que es el último eufemismo para
dominar a lo que hace el hacker.
Enfoque de cascada

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

La cascada tradicional tiene una cierta lógica. Se hace un plan para el proyecto y luego
se realiza el análisis del dominio del problema. Cuando se declara la victoria en el
análisis comienza el diseño, y una vez que esta terminado el diseño comienza la
construcción. Las salidas de una etapa son las entradas para la siguiente, y a esto se debe
la metáfora de la cascada

Planeación

Análisis

Diseño

Construcción

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

La cascada tiene un atractivo ordenado que hace sea un modelo especialmente conveniente
para la enseñanza de las técnicas de ingeniería de software. De hecho, observara que este
libro está dispuesto en una forma similar, con el capitulo sobre el plan general del proyecto
precediendo a los capítulos sobre análisis y a continuación los capítulos sobre diseño. Sin
embargo, la organización para el aprendizaje de una serie de técnicas no siempre es igual a
la organización para el empleo de una seria de técnicas en nuestro caótico y ambiguo
mundo real. Aunque pocos puedan argumentar en contra de que la planificación debe
preceder al análisis detallado, y que el análisis es un precursor lógico del diseño y la
construcción, seria tonto insistir que un proyecto de desarrollo a gran escala termine todo su
análisis antes de realizar nada del diseño, o que debería diseñar todo el sistema antes de
construir cualquier parte de él.
Los instructores de ingeniería de software han advertido desde hace mucho que, aunque sus
cursos se presentan con un enfoque de cascada, los proyectos reales se ejecutan en faces,
sucediendo muchas tareas en forma concurrente y con un grado moderado de iteración de
ajustes mientras se aprende cosas sobre la marcha, las cuales causan que se revise tareas
anteriores. Mi teoría es que muchos gerentes de proyectos estaban fuera del salón o
hablando por teléfono durante esta platica en particular. Por tanto, la historia de la
ingeniería de software esta salpicada con fallas monumentales que fueron el resultado de
una mala administración de las técnicas, mas que de la falta de adecuación de las técnicas
mismas.
El desarrollo en faces incrementales y algún grado de interacción de ajustes, siempre ha
sido una practica clave en la implementación exitosa de cualquiera de los llamado métodos
de cascada. Los buenos gerentes de proyectos lo han estado haciendo durante años. Las
metodologías de cascada en realidad sufren de una mala analogía, el agua, siendo victima
de la gravedad, no tiende a regresar hacia arriba de la colina para dar otro paso por su
propia caída. De manera similar, la gente tiende a tratar los regresos hacia el análisis o el

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

diseño como una falla en vez de ser un paso hacia adelante.

Planeación

Análisis

Diseño

Construcción

Implementación de fases

Es una practica sensata de hacer los proyectos grandes en fases. Unas de las principales
razones es que el aprendizaje que se obtiene mientras se toma una parte del proyecto a
través de su ciclo de vida completo proporciona experiencia valiosa que agiliza el
desarrollo de faces subsecuentes. Otro beneficio es la entrega temprana de alguna parte del
sistema que puede usar el negocio.
Muchas fallas de proyectos que han sido achacadas a la cascada, en realidad fueron
resultado de una falla de empleo de buenas técnicas de modelado en un plan de
implementación correctamente dividido en fase. El término “parálisis de análisis” fue

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

acuñado para escribir proceso que se encuentran entrapados en un gran dominio del
problema, para su desgracia, sin una conclusión previsible para el inmenso esfuerzo de
modelo. Tales proyectos fueron cancelados, por lo general, por patrocinadores frustrados
convencidos de que el departamento de IT se había convertido en estudiante profesionales
analizando el problema en vez de hacer algo por él, o lo que es peor las necesidades de
negocio habían cambiado tan drásticamente en los siglos transcurridos desde que el
proyecto se inició. Que el sistema resulte seria obsoleto antes de que fuera instalado.

Enfoque Espiral

Por lo contrario, el modelo desarrollo espiral, integran la fase y la iteración de ajustes en la

metáfora. El modelo espiral fue desarrollado originalmente en el pentágono como un
método para controlar los costos desbocados de armas masivas y proyecto de desarrollos de
sistemas de defensa. La idea fue dividir el proyecto en faces más cortas de análisis, diseño,
desarrollo y evaluación. Después de cada fase se evalúa la viabilidad del trabajo terminando
junto con una estimación refinada para las siguientes fases. Esta técnica de presupuestación
proporciono revisiones de factibilidad cruciales para proyectos en donde frecuentemente
estaban haciendo investigaciones sobre tecnologías completamente nuevas. Se toma una
decisión en la fase de evaluación sobre si se debe continuar con otra iteración de ajuste.
La idea de la espiral ha cambiado ligeramente para adaptarse a las sensibilidades peculiares
de las industrias de softwares. En vez de enfocarse en el rol de presupuesto, la espiral se ha
empleado como un método para la entrega temprana de código en una metodología que ha
llegado a ser popular bajo el termino RAD (Desarrollo rápido de aplicaciones).
El RAD combina el enfoque espiral con una estrategia de división de un proyecto grande en
“cuadros de tiempo”. Un cuadro de tiempo es un conjunto de características definido que se
promete entregar a los usuarios dentro de un marco de tiempo fino, digamos 90 días.
Dentro del cuadro de tiempo se realiza algo de análisis, un diseño leve y luego, usando

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

herramienta de desarrollo de alto poder, se construye un prototipo funcional. El prototipo es

revisado por los usuarios y se solicitan modificaciones. El ciclo de codificación y de
refinación del prototipo se repite 3 veces, yendo de espiral, volviendo a analizar, diseñar y
evaluar. Al final del cuadro de tiempo se instala la aplicación resultante.

Que es lo que hace que una metodología sea solida

Una buena metodología arma sus practicantes con un juego de herramientas de técnicas
confiables y repetibles que se adecuan prácticamente bien a los problemas que están
tratando de resolver. Las técnicas de modelador deben permitir permitir combinar el
balance y mezclas adecuados de técnicas para el problema. No todos los problemas de
negocios se crean igual. Algunos son ricos de datos, pero tienen muy poco requerimiento de
procesamientos. Otros ricos en eventos, casi sin procesamientos, pero comprenden grandes
cantidades de datos, y así sucesivamente. Una metodología balanceada incluye técnicas que
le dan a los analistas y diseñadores una amplia cobertura de todos los aspectos que deban
modelar, pero les permite desviar sus énfasis de modelados para adaptarse a la técnica del
problema de negocio.
Una buena metodología de análisis y diseño debe tener 5 características principales
 Motivar la actividad pretendida
 Ser completa
 Ser modificable en su corrección
 Producir productos contra los que se pueda medir el avance
 Ser fácilmente aprovechable en la fase subsecuente

Características de las buenas metodologías de diseño

 Un buen diseño debe motivar la toma de decisiones ayudando a evaluar alternativas.

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

todo el diseño es acerca de compromisos. Como veremos posteriormente en el libro,

no hay solución perfecta en el ámbito cliente/servidor.
 El diseño necesita ser completo, de tal forma que cubra cada uno de los aspectos
principales del software que necesitan constituirse. Esto causara que tenga varios
tipos diferentes de modelos en la documentación del diseño.
 El diseño debe ser verificable antes su construcción. Unos de los propósitos
principales del diseño es revisar y discutir la solución antes de lanzarse a la carga y
codificarla.
 Una buena metodología de diseño crea productos diferenciados que son mensuales.
Unas de las tareas más difíciles de cualquier proyecto es estimar cuando se
terminara. Para hacer una estimación el gerente del proyecto debe tomar medidas, la
cual involucra el conteo de cosas que necesiten hacerse y la aplicación de algún tipo
de medida sobre de ella para estimar que tanto tiempo llevara hacerla.
 Por último, pero no menos importante, el diseño debe ser fácilmente aprovechado
en el producto final. Debe expresar el uno y la estructura del sistema en forma muy
cercana al resultado pretendido.

Características de las buenas metodologías de análisis

 Una técnica de análisis debe motivar al acto de descubrimiento proporcionando un

marco de trabajo en el que el analista puede escribir lo que ellos saben y evaluar lo
que debe aprender.
 La metodología de análisis debe ser completa respecto a que cubra adecuadamente
cada uno de los aspectos del problema del negocio. Como vemos posteriormente
ene este libro, los sistemas de negocios tienen datos que deben recordarse, reglas de
procesamiento y comportamiento definible.
 Los resultados del análisis necesitan ser verificables. Esa fase del análisis también

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página

 UNIVERSIDAD TECNOLOGICA INTERCONTINENTAL
Creada por Ley N° 822 del 12-01-96 La Universidad sin fronteras

tiene un publico dual. Los usuarios son el publico principal para aprobar los
documentos como una representación precisa de sus necesidades.
 La metodología del análisis también debe crear unidades medibles para el gerente
del proyecto. Al inicio de la etapa de análisis, el tamaño y el alcance del proyecto
pueden ser un poco difusos.
 Esto nos lleva al punto final de la posibilidad de su aprovechamiento. Nadie en esta
industria puede negar que una metodología de análisis debe motivar al propio
análisis, ser completa, verificable y mensurable.

Sede Central Fernando de la Mora – Decanato – F.T.I. &.C.E Página