HOSTING PERU
ALOJAMIENTO WEB PERU
DISEÑO WEB PERU
PAGINAS WEB PERU
DISEÑO DE PAGINAS WEB PERU
| TICOM S.R.L | Web peru, paginas web peru, hosting peru, alojamiento web peru, registro de dominios peru, portales web peru, comercio electrónico peru, soporte tecnico de computadoras peru, diseño web peru |
PROPÓSITO DEL ANÁLISIS Y DISEÑO
El análisis es al proceso de determinar que se necesitan hacer antes de decidir cómo deben hacerse. El diseño es el proceso de determinar cuál de muchas posibles soluciones es la mejor para lograr que se necesita hacer, respetando las restricciones tecnológicas y de presupuesto del proyecto. El diseño escoge un cómo específico para aplicarlo al que. El análisis es el acto de descubrimiento. El diseño es el arte del compromiso.
Tradicionalmente, los esfuerzo del análisis han tenido una dudosa reputación en el desarrollo del software. Casi todos saben que algún proyecto al que se le dedicaron incontables meses( o a veces años) dibujando miles de burbuja, cuadros y líneas, sólo para ser abandonados en un librero y comenzar a codificar apresuradamente.
La mayoría de los proyectos que fracasaron lo hacen por falta de una buena administración del proyecto y por fallas en el análisis de las necesidades 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 análisis y diseño, es al menos, evitar que se carga el proyecto y lo optimo 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 presupuéstales 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 las soluciones 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 dejará 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 papel del analista es ir y encontrar que problemas existen 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 diferentes 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 a las que se requieren en el programador.
El
analista no puede desentenderse completamente de los principios básicos de la
automatización. Necesita estar profundamente consciente de lo que es posible,
factible y práctico en lo que se refiere a la computación en los negocios. En
términos generales el analista es un investigador ya que el analista es un
proceso de descubrimiento. El analista debe estar a gusto en el papel de arqueólogo,
desterrando gemas de datas desconocidos de entre el naufragio de los archivos
planos de un sistema heredado o
descifrando los jeroglíficos 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 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 sobre saltos”. En la fase de análisis de un proyecto se pasara gran
parte del tiempo sacando información de los posibles usuarios del sistema,
reorganizando lo que aprende y volviéndolo a presentar para su validación. Tal
vez sea llamado para hacer diplomacia, resolviendo conflictos y dando soluciones
entre facciones del negocio que están en guerra. Algunas empresas de IT
(tecnología de información tienen la creencia de que si una persona se pasa
dos años en su cubiculo dando mantenimiento a código COBOL obtiene mágicamente
el conjunto de habilidades, un buen analista se crea por medio de practica
dedicada y aptitud para el trabajo. El analista
necesita en 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
talentos se convierten en analistas excelentes, sin embargo la programación
no es un requisito previo para el trabajo del analista.
En
muchos establecimientos de IT, el ascenso “programación /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, la realidad es que ningún esfuerzo de desarrollo de software de tamaño
apreciable puede hacerse sin las habilidades de buenos administradores analistas
y tecnólogos.
LAS
HABILIDADES DE UN DISEÑADOR
El diseñador es un bicho ligeramente diferente al analista. Mientras el enfoque del analista está 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 disponibles. El analista se puede dar el lujo de suponer con la tecnología perfecta. El documenta los requerimientos del usuario como si todos los procesadores fueran íntimamente rápidos y todos los datos estuvieran disponibles 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 máquinas que pone a su disposición el departamento de IT.
El diseñador traza los planos a partir de los cuales se constituirá el sistema, lo que lo convierte 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 más cercanas a las de un programador. Aunque la programación no es siempre 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 UN PROYECTO CLIENTE / SERVIDOR EXITOSO?
El secreto de desarrollo exitoso en los ambientes clientes/ servidor multiplataforma actuales en realidad no es ningún secreto. Toma la gente adecuada, a la administración sensata y a una buena metodología. Por su puesto, 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.
Un equipó de desarrollo necesita habilidades en análisis de negocio; modelado de eventos, modelado de información, diseño de interfaces, diseño de bases de datos, comunicaciones en red, hardware y operación de sistemas host, hardware y operación de computadoras personales, programación de interfaces gráficas de usuarios, experiencia en SQL, intercambio electrónico de datos planeación y ejecución de pruebas, administración de liberaciones de software, etc.
La complejidad de las herramientas de desarrollo actuales, junto con la avalancha de automatización en cada una de las facetas de la empresa de negocios, demanda un nivel de experiencia en cada área que está más allá de lo que es razonable esperar de un solo individuo.
La clave para reunir un equipo exitoso no solamente es contratar a 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 las habilidades necesarias a lo largo de la duración del proyecto y determinar cuales se necesitan y en que momento, luego el gerente de proyecto puede buscar un equipo medular que proporcione la continuidad del proyecto y mejore al equipo con especialistas que pueden rotarse por poco tiempo en los distintos grupos, proporcionando así las habilidades críticas solamente cuando sea necesario.
La gran complejidad del ambiente cliente/servidor actual nos fuerza a reconocer que no podemos apoyarnos completamente en técnicos con conocimientos generales. Necesitamos gente que tenga habilidades en áreas que tienen curvas de aprendizaje amplias y con gran pendiente. Las especialidades se cultivan con experiencias repetidas el permitir que 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, los establecimientos de IT necesitan concentrarse en la construcción de habilidades específicas permitiendo que la gente se mueva de proyecto en proyecto.
ADMINISTRACIÓN
SÓLIDA 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.
Una técnica es un método estructurado y repetible para lograr una tarea especifica .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 sistemas 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 las tareas en una metodologí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 desarrollo de software tiene que ser malabarismos con las agendas y calendarios de las cuadrillas de red y de hardware, los analistas de negocios, 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 estos sean equipos individuales de personas y no simplemente papeles representados por las mismas personas.
METODOLOGÍA SÓLIDA
Las metodologías vienen en muchas formas y tamaños .Mucho se ha dicho de las ventajas de la metodología de espiras contra la metodología de cascada .Sus filosofías van desde el enfoque de recetano draconiano ,hasta la programación evolucionaría , que es el ultimo eufemismo para denominar a lo que hace un hacker.
La cascada tradicional tiene una cierta lógica se hace un plan para un 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, una vez que esta terminado el diseño comienza la construcción.
Una
metodología de cascada
La cascada tiene un atractivo ordenado que hace que sea un modelo especialmente conveniente para la enseñanza de las técnicas de ingeniería de software.
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 serie de técnicas en nuestro caótico y ambiguo mundo real.
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 fases.
El desarrollo en fases increméntales y algún grado de iteración de ajuste ,siempre ha sido una practica clave en la implementación exitosa de cualquiera de los llamados 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 víctima 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 diseño como una falla en vez de ser un paso hacia adelante.
Muchas fallas de proyectos que han sido achacadas a la cascada ,en realidad fueron resultado de una falla del empleo de buenas técnicas de modelado en un plan de implementación correctamente dividido en fases .El termino parálisis de análisis fue acuñado para describir proyectos que se encuentran entrampados en un gran dominio de problema.
El modelo espiral fue desarrollado originalmente en el pentágono como un método para controlar los costos desbocados de armas masivas y proyectos de desarrollo de sistemas de defensa .La idea fue dividir el proyecto en fases mas cortas de análisis, diseño, desarrollo y evaluación .Después de cada fase se evalúa la viabilidad del trabajo terminado junto con una estimación refinada para las siguientes fases. Esta técnica de presupuestación proporcionó revisiones de factibilidad cruciales para proyectos. 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 la industria del software, la espiral 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 fijo, digamos 90 días .Dentro del cuadro de tiempo se realiza algo de análisis, un diseño breve y luego ,usando herramientas 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 tres veces, yendo en espiral volviendo a analizar, diseñar y evaluar. Al final del cuadro de tiempo se instala la aplicación resultante.
En la práctica, el RAD sufre de malas aplicaciones igual que la cascada .Muchos gerentes
Y programadores ven el modelo espiral como tres iteraciones de ajuste de “codificación”.
La ventaja principal del RAD es al codificación , y en muchos establecimiento la producción de código es vista como la única medida tangible de que se a realizado una actividad significativa. Los puntos fuertes del RAD son que los usuarios se involucran intensamente la creación temprana de prototipo y la implementación en fases. Sus puntos débiles incluyen una tendencia hacia la codificación temprana, lo que hacen que pasen muchas tareas de análisis y diseños a manos del programador y, por lo tanto, depende de los técnicos con conocimientos generales el enfoque abrumador sobre el cuadro de tiempo hace difícil la construcción de componentes reutilizables a largo plazo, y cuando se acerca la fecha de entrega lo primero que se hace es la documentación . En vez de administrar contra una especificación tangible, el administrador se encuentra armado solo con un látigo y un cronometro. La medida de avance principal se convierte en la cantidad de revisiones que se han hecho al código, tanto el enfoque de cascada como el espiral tienen sus puntos buenos. Desafortunadamente ambos sufr4en de abusos brutales en el mundo real.
Una
buena metodología arma a sus practicantes con un juego de herramientas de técnicas
confiables y repetibles que se adecuan particularmente bien a los problemas que
están tratando de resolver. Las técnicas del modelador deben permitirle
combinar el balance y mezcla adecuados de técnicas para el problema. No todos
los problemas de negocios se crean igual. Algunos son ricos en datos, pero
tienen muy pocos requerimientos de procesamiento. Otros son ricos en eventos,
casi sin procesamiento, 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 su énfasis de modelado para adaptarse a la
tendencia del problema de negocios.
Una buena metodología de análisis o diseño debe tener cinco características principales :
1.- Motivar la actividad pretendida
2.-
Ser completa
3.-
Ser modificable en su corrección
4.-
Producir productos contra los que se pueda medir el avance
5.-
Ser fácilmente aprovechable en la fase subsecuente
1.
El buen diseño debe motivar la toma de decisiones ayudando a evaluar
alternativas.
Todo el
diseño es acerca de compromisos. No hay solución perfecta en el ambiente cliente/servidor. Para cada requerimiento esencial del negocio habrá
muchas formas posibles de lograrlo. Una técnica de diseño debe permitir que el
diseñador evalúe su decisión contra otras posibilidades. Por ejemplo, usando
el modelo de análisis de eventos acoplado con el esquema de diseño de datos.
2 El diseño necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causará que se tengan varios tipos diferentes de modelos en la documentación del diseño. En forma similar a los planos arquitectónicos para la cimentación. Ningún modelo puede mostrar todas las facetas del sistema funcional completo. Ese sería el sistema mismo.
3
El diseño debe ser verificable antes de su construcción. Uno de los
propósitos principales del diseño es revisar y discutir la solución antes de
lanzarse a la carga y codificarla. Con una buena especificación de diseño se
debe ser capaz de demostrar que se satisfarán los requerimientos del proyecto y
así mismo se distinguirá entre varias versiones del diseño en cualquier
momento.
4. Una buena metodología de diseño crea productos diferenciados que son mensurables.
Una
de las tareas más difíciles de cualquier proyecto es estimar cuándo se
terminara.
5.
Por último, pero no menos importante, el diseño debe ser fácilmente
aprovechado en
el
producto final. Debe expresarse el uso y la estructura del sistema en una forma
muy cercana al resultado
pretendido. El lema del diseñador es: hacer un mapa de la técnica hacia el
destino. Si el sistema va a operar con una base de datos relacional se deben
escoger técnicas que sean particularmente adecuadas para el diseño de base de
datos relacionales. Si el sistema empleará un lenguaje orientado a objetos, entonces se
deberán usar técnicas de diseño orientadas a objetos para las partes del
sistema que requieren objetos para lograr sus tareas.
Una
metodología de análisis exitosa presentará las siguientes características :
1.
Una técnica de análisis debe motivar el acto del descubrimiento
proporcionando un marco de trabajo en el que el analista pude escribir lo que
ellos saben y evaluar lo que tienen que aprender. Esto incluye el tener
inventiva para guiar el análisis.
2.
La metodología de análisis debe ser completa respecto a que cubra
adecuadamente cada uno de los aspectos del problema de negocios. Los sistemas de
negocios tienen datos que deben recordarse, reglas de procesamiento y
comportamiento definible.
3.
Los resultados de análisis necesitan ser verificables. La fase de análisis
también tiene un público dual. El usuario promedio no va a descubrir una
relación de cardinalidad que no sea exacta en un modelo de información, como
tampoco va a poner en duda el empleo de la herencia múltiple en los diagramas
de case orientados a objetos.
4.
La metodología de análisis también debe crear unidades medibles para
el gerente del proyecto. Al inicio de la etapa de análisis.
5.
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.
El
plan general establece las metas y objetivos del proyecto. Lo que es más
importante, proporciona un conjunto de medidas que permite saber cuando se han
logrado los objetivos. También indica quien hace que, tanto para el
departamento de IT como para los usuarios. El plan general es un contrato y al
igual que cualquier acuerdo, involucra a dos partes para complementar la
transacción. Hay papeles y responsabilidades significativos en ambos lados.
El
proceso de establecer el plan general es un esfuerzo cooperativo entre la IT y
el negocio. Es responsabilidad de la organización de IT el proporcionar
asistencia técnica, analítica y procedural, y dirigir al negocio a través del
proceso de la producción de un plan general. La IT actúa como una facilitadora
para llevar al negocio a través de las diversas soluciones que pueden ayudar
para que este cumpla sus metas.
Es
responsabilidad del negocio dedicar personas y tiempo para articular las metas,
objetivos y criterios de evaluación del negocio y participar materialmente en
las decisiones. Por lo general, la gente de sistemas de información no es quién
establece las políticas en una organización.
Desafortunadamente
en muchas organizaciones las metas y objetivos no están claramente
establecidos, y a veces ni siquiera escritos. En estos casos, el departamento de
IT debe extender sus responsabilidades más allá, para ayudar a que el negocio
comunique, y a veces descubra, sus necesidades. Si las personas de sistemas de
información no dan el paso para llenar el vacío en la fase de planeación, el
proyecto puede estar condenado desde el principio.
¿QUÉ
TAN PRECISO DEBE SER EL PLAN GENERAL ?
El
plan general es el plan estratégico y ordenes de avances del proyecto. El
proyecto de establecer el plan general determina que tan factible es continuar
con un proyecto y en qué dirección y a qué ritmo se debe realizar el
esfuerzo. Además de indicar los objetivos del proyecto, el plan general detalla
el costo estimado de lograr esos objetivos. La calidad del plan general es
crucial para el éxito del proyecto que le sigue.
La precisión de estimaciones de tiempo y recursos del proyecto que se hacen en el plan general es directamente proporcional a la cantidad de esfuerzo que se pone en ellas. Entre más modelado se haga por anticipado para el plan general ( tratado en los siguientes cuatro capítulos ), mejores serán las estimaciones. Esto no quiere decir que el esfuerzo de establecer el plan general típico requerirá un análisis completo. La cantidad de modelado e investigación que se ponga en un plan general estará determinada por la cantidad de detalles que se deba incluir en la estimación de tiempo y costo del proyecto.
Cualquier
ciclo de vida de desarrollo sensato incluye una etapa de planeación o
viabilidad. Me gusta el término “plan general de proyecto” debido a que se
denota “razón de ser” . El marco de trabajo para la toma de decisiones es
una técnica para reunir a la gente a fin de lograr consenso sobre las metas,
objetivos y criterios de evaluación de un proyecto. Esta visión común se
utiliza como base para seleccionar opciones a lo largo del proyecto.
En
la cima de la pirámide esta la meta del proyecto : un resumen que permite que
todos sepan lo que se trata de lograr con el proyecto. En la siguiente capa se
tiene una variedad de objetivos que soportan la meta. Estos son una especie de
pequeñas metas. Cada objetivo, en alguna forma, contribuye a lograr la meta, la
cual se alcanza cuando se satisfacen todos los objetivos.
La
capa que sigue a los objetivos, es la de los criterios de evaluación. Esta capa
contiene las mediciones que se necesitaran para determinar si se ha logrado un
objetivo.
El
inicio de un proceso analítico comienza preguntándole a la gente qué hay de
malo en el ambiente actual. Por lo general, las personas comienzan poco a poco,
sin querer ofender o llamar la atención hacia ellos mismos.
El
objetivo del ejercicio es descubrir la mayor cantidad de problemas posibles,
pero no tratar de resolverlos en ese momento.
Un
sistema de información nuevo es una solución. Para diseñar la solución
adecuada se debe comprender el problema que se está tratando de resolver. Los
problemas pueden ir desde la variedad de los obstáculos importantes (como,
“el sistema antiguo produce resultados falsos que no se deben tomar como datos
precisos” ), hasta los mundanos ( como, “los reportes de impresora son difíciles
de leer” ).
La
diferencia entre problemas y oportunidades es sutil. Un problema existe cuando
algo no está trabajando y se le quiere componer. En cuanto a una oportunidad no
hay nada necesariamente malo. La oportunidad se presenta cuando se puede
aprovechar una nueva tecnología, productos o servicios que no existían antes o
que no habían sido considerados.
Un
objetivo es una frase que cuando se lleva a cabo elimina el problema o aprovecha
una oportunidad. Los objetivos son como “ pequeñas metas”.También deben
ser claros, concisos y mensurables. Cada objetivo soporta a una parte de la
meta. Si se llegan a alcanzar todos los objetivos se ha alcanzado la meta total.
El
factor x pone un número al incremento en ganancias, a la disminución de costos
y a la mejora de servicios para cada objetivo que es posible medir. El proceso de
creación de un plan general de proyecto frecuentemente descubre la necesidad de
hacer algunas mediciones básicas en la organización. Es importante que se
hagan estas mediciones. Cuan se descubre un objetivo al que le falta cualquier
medida sobre el grado del problema, los siguientes pasos le permitirán
registrar la deficiencia y continuar con la reunión del grupo.
1.
Establecer con el grupo la manera en que podría medirse el objetivo. Se
pueden tomar mediciones tangibles en términos de tiempo o dinero.
2.
Inserte un factor x en la declaración del objetivo, mostrando donde se
necesita una medición. La existencia de la variable hace que sea claro para
cualquier lector.
3.
Asigne personal específico para establecer las mediciones básicas para
evaluar el alcance del problema.
4.
Establecer un tiempo para volver a reunir al grupo, después que se hayan
realizado las mediciones.
DECLARACIÓN
DE LA META
Después
que haya compilado una lista exhaustiva de los objetivos con el grupo y haya
determinado el método de medición de cada uno, es tiempo de regresar a la
declaración de la meta. Si ya tiene un borrador con una declaración de la meta
del proyecto, revíselo y corríjalo a la luz de los objetivos y vea si todavía
resume el proyecto.
Una
buena técnica para analizar y resumir los objetivos es agruparlos en categorías.
CRITERIOS
DE EVALUACIÓN
La
siguiente capa del marco de trabajo para la toma de decisiones del proyecto es
el criterio de evaluación que establece la manera en que se medirá cualquier
solución dada en relación con los objetivos.
LISTA
CON CRITERIOS ESTÁNDAR DE EVALUACIÓN DE COSTOS
Cualquier
evaluación de los cursos de acción propuestos, deberá involucrar alguna
determinación de costo/beneficio. La lista de objetivos nos da una medición de
esos beneficios. El criterio de evaluación también necesita sopesar el costo
de cualquier solución dada.
Los
costos se presentan de muchas maneras. La siguiente lista incluye varias categorías
de costos que deben ser parte de cualquier evaluación de un sistema de
información.
·
El
costo óptimo de adquisición (construirlo o comprarlo)
·
El
costo óptimo para implementarlo.
·
El
costo óptimo para mantenerlo a lo largo del tiempo.
·
Evita
riesgos técnicos excesivos.
·
Tiempo
de entrega aceptable.
·
Factibilidad
con la gente y experiencia disponible.
CRITERIOS DE EVALUACIÓN ADICIONALES PARA LOS SISTEMAS DE INFORMACIÓN
Además
de los criterios de evaluación que están relacionados con los beneficios de
los objetivos del proyecto y de los costos asociados con una solución, en la
lista se deben tener consideraciones que son universalmente aplicables a los
sistemas de información. A esto
Se
le llama la lista “idad”, debido a que muchos de los vectores de calidad de
la lista terminan en “idad”.
Facilidad
de uso
Contabilidad
Capacidad
de mantenimiento
Extensibilidad
Flexibilidad
Seguridad
Eficiencia
Actualidad
de información
Inmediatez
de respuesta
Habilidad
para comunicarse con otros sistemas.
Hay
muchos puntos durante un proyecto en donde se presentan alternativas. La etapa
de planeación es solamente uno de ellos. Cualquier decisión involucra
compromisos, y el marco de trabajo para la toma de decisiones ayuda a regresar
la concentración en los objetivos originales del proyecto para que las personas
puedan hacer selecciones en forma razonable.
El
tener un plan general sólido y un modelo del negocio ayudará a comprender los
compromisos de ingeniería y a tomar decisiones bien informadas.
Las
opciones de solución deben ser consideradas con el grupo de establecimiento del
plan general del proyecto.
INTRODUCCIÓN
En
este capítulo se tratará la notación para la diagramación de flujo de datos,
los conceptos de alcance expandido y reducido y se le mostrará cómo ajusta el
modelo de contexto con los otros modelos.
EL
PROPÓSITO DEL MODELO DEL CONTEXTO
El
general Dwight D. Eisenhower una vez dijo: "Lo que importa no es el plan,
sino la planeación." Estaba,
por supuesto, refiriéndose a la invasión de Europa por parte de los aliados en
el día D de la Segunda
Guerra Mundial. Lo que parecía decepcionantemente simple en papel
se había llevado mucho tiempo de planeación y de preparación.
El diagrama de contexto también se ve decepcionantemente simple en
papel. Tiene sólo una burbuja en el centro que representa al
"sistema". La notación clásica de diagramas de flujos de datos se
usa para mostrar todos los flujos de estímulos que entran al sistema y sus
flujos de respuesta que regresan al mundo exterior. Los agentes que son externos
al sistema se muestran como cuadros. Representan a los originadores de los
flujos de estímulos y/o los destinos de los flujos de respuesta.
"Lo
que importa no es el diagrama de contexto resultante sino el acto de
hacerlo."
Es de excepcional importancia que los miembros del proyecto comprendan,
definan y comuniquen el alcance del
área de estudio lo más pronto posible. El acto de creación de un modelo de
contexto los ayudará para alcanzar esa finalidad.
El diagrama de contexto es menos útil conforma avanza el proyecto,
cuando se trata de la creación de bases de datos relacionales o interfaces gráficas
de usuario. El modelo de información y el modelo de eventos tienen mucho más
valor en términos de su uso.
El
contexto representa el todo del modelo del proceso.
NOTACIÓN
DE DIAGRAMACIÓN DE FLUJO DE DATOS
El
modelo de contexto utiliza la notación de diagramación de flujo de datos clásica
(figura 3-2).
Los
diagramas de flujo de datos son modelos que muestran la ruta que toman los datos
a través de una organización, sin ninguna tendencia a causa de una
implementación específica.
Hay cuatro notaciones principales para el diagrama de contexto. El círculo
o elipse se usa para representar procesos, la flecha para los flujos de datos,
un rectángulo para representar agentes y un par de líneas paralelas para
mostrar datos almacenados.
Procesos
Para
la mayoría de los sistemas de negocios, la burbuja de proceso de un diagrama de
contexto es un popurrí de diversas actividades, y encontrar un buen nombre
puede ser difícil.
Hay unas cuantas reglas y suposiciones con relación a los procesos. La ley
de transformación establece que un proceso modifica los datos en alguna
forma. La salida debe ser diferente de la entrada. La figura 3-3 muestra un
fragmento de diagrama de flujo de datos que viola la ley de transformación. El
pedido del cliente aparece tanto en la entrada como en la salida del proceso de
validación.
La violación aparente se debe, en realidad, a una denominación
descuidada. El proceso Validación del
pedido del cliente tiene un pedido del cliente como entrada , lee algunas
estadísticas para aprobación de límites desde un almacén de datos y envía
un pedido inválido del cliente o un pedido válido del cliente. Cuando
corregimos los nombres de los flujos de datos podemos ver que éstos realmente
se han transformado.
La ley de la conservación insiste en que la salida de una burbuja de proceso debe ser derivable de su entrada, y los que es más, sol se le debe dar la información suficiente para que haga su trabajo.
Agentes
externos
Los
agentes externos están fuera del contexto del área de estudio. Por está razón
nunca se muestran flujos entre dos agentes externos. Sólo se despliegan los
datos que influyen hacia o desde el sistema en el diagrama de contexto. Los
agentes externos son mencionados con un nombre. Ellos pueden representar
departamentos específicos o grupos de
usuarios dentro del negocio, clientes, vendedores, transportistas o hasta otros
sistemas de información. Cada agente externo del modelo requiere un nombre y
una definición.
No es recomendable poner el nombre real de una persona como agente
externo. En Samson Demolition, Inc. (figura 3-5), todos en la compañía pueden
saber que Delilah teclea los pagos de
los clientes en la parte de cuentas del sistema, pero Delilah no es un nombre
adecuado apra un agente externo. Se podría llegar a tener un diagrama bastante
extraño si se descubre que Delilah
también procesa las reclamaciones médicas de los empleados y teclea los datos
de prestaciones en el módulo de recursos humanos.
Flujos
de datos
En
el diagrama de contexto los flujos de datos caen claramente en dos categorías,
estímulos y respuestas. Los flujos de estímulos son las "entradas" y
los flujos de respuestas son las "salidas".
La
definición de un flujo de datos es crítica. En la figura 3-8 un solo flujo,
llamado nuevo pedido del cliente,
entra al sistema desde el cliente. En la figura 3-9 tenemos esencialmente la
misma información entrando al sistema pero se muestra como dos flujos. Expediente
del cliente y Nuevo pedido.
Almacenes
de datos
Los
almacenes de datos son lugares del sistema en donde se recuerdan los datos
cuando no se utilizan. Se les muestra como líneas paralelas. La sabiduría
convencional es que los almacenes de datos muestran los datos inactivos dentro
de las fronteras del contexto.
TÉCNICAS
PARA LA CREACIÓN DEL MODELO DE CONTEXTO
En
el diagrama de contexto de alcance reducido
(fig. 3-21). Los agentes externos son las partes que transportan
directamente la información al sistema.
En
el diagrama de contexto de alcance
expandido (fig. 3-22). Los agentes externos son ahora los iniciadores y
consumidores finales de nuestros datos del sistema. El alcance de la burbuja de
contexto ha sido expandido para englobar a todos los procesos que están entre
los iniciadores de datos y los consumidores de datos.
ALCANCES
EXPANDIDO Y REDUCIDO
El diagrama de
alcance expandido nos permite ignorar temporalmente quién hace qué y dónde
sucede. Ahora podemos buscar dentro del contexto y ver qué procesos de
transformación de datos suceden para el evento El
cliente coloca pedido.
Nuestro diagrama de alcance expandido también nos ayuda a explorar
posibles mejoras para los flujos de respuesta. En nuestro diagrama de alcance
reducido el acuse de recibo del pedido se envía a la impresora.
CÓMO
SE RELACIONA EL MODELO DE CONTEXTO CON LOS OTROS MODELOS
El
modelo de contexto está directamente relacionado con el modelo de eventos
(figura 3-23), el cual forma la base de gran parte de las tareas de diseño de
interfaz que se van a realizar. En cualquier momento en que se mueva la frontera
del contexto también se alterará el paisaje del modelo de eventos
(capítulo 4).
Cuando el contexto del proyecto se expande para incluir ubicaciones del
negocio geográficamente distribuidas, tal como el ejemplo dado en este capítulo,
entonces la arquitectura técnica del sistema de destino llega a ser más
complicada (capítulo8).
INTRODUCCIÓN
El
modelo de eventos es una forma para definir los requerimientos del sistema desde
un punto de vista del usuario. Comenzaremos listando los eventos de negocios
para los que nuestros usuarios emplearán el sistema. A cada evento de nuestra
lista de eventos se le da una definición detallada en el diccionario de
eventos. Éste lista los datos que estimulan al sistema para entrar en acción y
los datos que comprenden la respuesta del sistema ante el evento. En este capítulo
se tratará la definición formal de un evento y se mostrará como descubrir
eventos mientras realiza el análisis. Se proporcionará un formato para el
registro de cada evento en el diccionario de eventos y se mostrará las diversas
formas en que se puede organizar una lista de eventos y las matrices de eventos
para que sean una ayuda en el análisis y el diseño. El modelado de eventos es
un concepto clave que, cuando se le dispone, ayuda a organizar las
especificaciones de análisis en una forma que es fácilmente aplicada durante
el diseño de la interfaz gráfica de usuario.
EL
PROPÓSITO DEL MODELO DE EVENTOS
- El propósito del modelo de eventos es describir cuál es el comportamiento
adecuado de un sistema.
- Para cada evento de la lista se crea una entrada en el diccionario de eventos,
la cual detalla la definición,
estímulo, actividad, respuesta y efecto en el negocio.
- Es aplicado a las tareas que suceden a su creación. Para el analista, el modelo
de eventos establece la actividad del
usuario en relación con el negocio en términos
que ellos pueden comprender fácilmente. Para el diseñador de la
interfaz, el
modelo de eventos proporciona las justificaciones de negocios para la navegación
y el contenido de
ventanas. Para el diseñador interno, las políticas del
negocio establecidas en el diccionario de eventos
proporcionan las razones para
la lógica del negocio, las cuales serán codificadas en el sistema.
El
modelado de eventos es una forma
para determinar todas las cosas que suceden en el mundo real y que deben
causar que el sistema entre en acción y haga algo.
La sintaxis para establecer un evento es sujeto-verbo-objeto.
Alguien (sujeto) hace algo [verbo] a algo (objeto).
Para lograr los eventos, se debe pasar por cada una de las siguientes
pruebas:
1.
Un evento sucede en un momento específico.
2.
Un evento sucede en el ambiente y no dentro del sistema.
3.
La ocurrencia del evento está bajo el control del ambiente y no del
sistema.
4.
El sistema debe ser capaz de detectar que el evento sucedió.
5.
Se supone que el sistema hará algo con respecto a él, significando con
esto que es relevante para el plan general del proyecto.
Si un evento no cumple cualquiera de las reglas es motivo suficiente para
descalificarlo como candidato a evento.
Eventos
Internos
Los
eventos internos son activadores entre dos procesos que están dentro del
sistema y, por lo tanto, están ocultos para el usuario.
El modelado de activadores internos es prematuro y no es relevante para
el usuario. Además, la razón por
la que cualquier proceso cobra vida dentro del sistema puede ser rastreable
hacia un evento externo.
Algunos
ejemplos de eventos
Con
un ejemplo de caja negra, nuestro conocimiento sobre la contestadora de teléfono
casera común para ver lo que es un evento y lo que no es.
1.
Quien llama hace una llamada al propietario.
2.
La máquina reproduce saludos previamente grabados.
3.
Quien llama se equivoca.
4.
Quien llama cuelga.
5.
El propietario oye un mensaje.
6.
El propietario solicita mensajes.
7.
El propietario no está en casa.
Respuestas:
1. Quien llama hace una llamada al propietario es un evento. Sucede :
