FASE DE DISEÑO LÓGICO

NO TODOS LOS PROYECTOS ACEPTAN EL DESARROLLO BASADO EN MODELOS,

PERO LA MAYORÍA INCLUYE UN POCO DE ELABORACIÓN DE MODELOS DE
SISTEMAS.
UN DISEÑO LÓGICO DOCUMENTA MÁS AÚN LOS REQUERIMIENTOS DE NEGOCIOS
POR MEDIO DE LOS MODELOS DE SISTEMAS QUE ILUSTRAN LAS ESTRUCTURAS DE
DATOS, PROCESOS DE NEGOCIOS, FLUJOS DE DATOS E INTERFACES DE USUARIOS
Y VALIDAN LOS REQUERIMIENTOS ESTABLECIDOS EN LA FASE ANTERIOR
TAREA 4.1A: REQUERIMIENTOS FUNCIONALES DE
ESTRUCTURA

• Un método para el diseño lógico es definir los requerimientos funcionales de

estructura. Esto significa que, por medio de métodos acelerados, usted debe
elaborar o actualizar uno o más modelos de sistemas para ilustrar el
requerimiento funcional. Éstos pueden incluir cualquier combinación de datos,
procesos y modelos de objetos que describan con precisión el negocio y los
requerimientos de los usuarios
• Los modelos con frecuencia se complementan con especificaciones lógicas
detalladas que describen los atributos de datos, reglas y políticas de negocios.
TAREA 4.1B: REQUERIMIENTOS
FUNCIONALES DEL PROTOTIPO
(ALTERNATIVA)
• La elaboración de prototipos es una alternativa (y a veces un requerimiento previo)
para la elaboración de sistemas. Algunas veces los usuarios tienen dificultad para
expresar los hechos necesarios para elaborar los modelos de sistemas adecuados. En
tal caso, una alternativa o un enfoque complementario a la elaboración de modelos
de sistemas es construir prototipos de identificación
• Los CONSTRUCTORES DE SISTEMAS facilitan esta tarea de análisis.
• Los ANALISTAS DE SISTEMAS documentan y analizan los resultados.
• Los USUARIOS DE SISTEMAS son la fuente primaria de la entrada de hechos a la
tarea.
TAREA 4.2: VALIDAR REQUERIMIENTOS
FUNCIONALES

• los MODELOS DE SISTEMAS como los PROTOTIPOS son

representaciones de los requerimientos de los usuarios. Éstos deben ser
validados para que estén completos y correctos. Los ANALISTAS DE
SISTEMAS facilitan la tarea de asignación de prioridades al comprometer en
forma interactiva a los usuarios del sistema para la identificación de errores,
omisiones y aclaraciones.
TAREA 4.3: DEFINIR CASOS DE PRUEBA DE
ACEPTACIÓN

• la mayoría de los expertos están de acuerdo en que no es demasiado

adelantado comenzar a planear las pruebas del sistema. Los modelos y los
prototipos de sistemas definen muy eficazmente los requerimientos de
proceso, reglas de datos y reglas de negocios para el nuevo sistema
FASE DE ANÁLISIS DE DECISIÓN

• Una vez que se tienen los requerimientos del negocio para un sistema de
información mejorado, es posible abordar la implementación tecnológica del
nuevo sistema (incluidas las alternativas basadas en computadora)
• El propósito de la fase de análisis de decisión es identificar las soluciones
alternativas, analizarlas y recomendar un sistema objetivo que será diseñado,
construido e implementado
TAREA 5.1: IDENTIFICAR SOLUCIONES
ALTERNATIVAS
• Dados los requerimientos de negocios establecidos en la fase de definición del
análisis de sistemas, debemos primero identificar las soluciones alternativas. Algunas
soluciones alternativas serán planteadas por las ideas y opiniones de diseño de los
PROPIETARIOS y USUARIOS DE SISTEMAS. Otras vendrán de diversas fuentes
incluyendo a los ANALISTAS DE SISTEMAS, DISEÑADORES DE SISTEMAS,
consultores técnicos y otros profesionales de sistemas de información. Y algunas
opciones pueden estar limitadas por una arquitectura de tecnología aprobada,
predefinida. Es la intención de esta tarea no evaluar las opciones, sino simplemente
definir las posibles alternativas de solución que se van a considerar.
TAREA 5.2: ANALIZAR SOLUCIONES
ALTERNATIVAS
Debe analizarse la factibilidad de cada solución alternativa de sistemas.
• Factibilidad técnica. ¿Es la solución técnicamente práctica? ¿Nuestro personal tiene
experiencia técnica para diseñar y construir esta solución?
• Factibilidad operativa. ¿La solución cumplirá con todos los requerimientos de los
usuarios? ¿A qué grado? ¿Cómo cambiará la solución el ambiente de trabajo del usuario?
¿Cómo se sienten los usuarios acerca de dicha solución?
• Factibilidad económica. ¿La solución tiene un costo-beneficio?
• Factibilidad de programa. ¿Puede la solución ser diseñada e implementada dentro de un
periodo aceptable?
TAREA 5.3: COMPARAR SOLUCIONES
ALTERNATIVAS

• Una vez que el análisis de factibilidad ha sido completado para cada solución
alternativa, podemos compararlas y elegir una o más soluciones para
recomendarlas a los PROPIETARIOS y a los USUARIOS DE SISTEMAS. En
este punto, cualquier solución no factible normalmente se elimina de cualquier
consideración posterior. Debido a que estamos buscando la solución más
factible de las soluciones restantes, identificaremos y recomendaremos la
solución que ofrezca la más completa combinación de factibilidad técnica,
operativa, económica y de cronograma
TAREA 5.4: ACTUALIZAR EL PLAN DEL
PROYECTO

• Continuamente actualizamos nuestro plan de proyecto al tiempo que

aprendemos más acerca de un sistema, sus problemas, sus requerimientos y
sus soluciones. Ajustamos el alcance en consecuencia. Por tanto, con base en
nuestras soluciones recomendadas, debemos una vez más reevaluar el
alcance del proyecto y, en consecuencia, actualizar el plan del proyecto. El
administrador del proyecto, en conjunto con los PROPIETARIOS DE
SISTEMAS y el equipo completo del proyecto, facilitan esta tarea
TAREA 5.5: RECOMENDAR UNA SOLUCIÓN
DEL SISTEMA
• Al igual que con las fases de investigación preliminar y de análisis de
problemas, la fase de análisis de decisión concluye con una tarea de
comunicación. Debemos recomendar una solución de sistema para la
comunidad del negocio
• El administrador de proyecto y el patrocinador ejecutivo deben realizar
conjuntamente esta tarea. Otros participantes en la reunión deben incluir al
equipo completo del proyecto, así como a los PROPIETARIOS, USUARIOS,
ANALISTAS, DISEÑADORES y CONSTRUCTORES DE SISTEMAS
asignados