Está en la página 1de 95

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

METODOLOGIA DE DESARROLLO DE SISTEMAS

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

NDICE I. QUE ES EL CAPABILITY MATURITY MODEL FOR SOFTWARE (CMM) II. ADMINISTRACIN DE PROYECTOS
1. CONCEPTOS 2. DOCUMENTACIN 3. FLUJO DEL PROCESO

III. MODELO DE DESARROLLO


1. CONCEPTOS 2. ETAPAS
A. B. C. D. E. F. G. PRE ANLISIS PLANEACIN ANLISIS DISEO DESARROLLO O CONSTRUCCIN PRUEBAS IMPLANTACIN

IV. MODELOS DE PROCESAMIENTO V. DOCUMENTACIN DE UN SISTEMA


1. EXPEDIENTE GENERAL 2. MANUALES
A. PROCEDIMIENTOS B. EXPEDIENTE TCNICO

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

I. QUE ES EL CAPABILITY MATURITY MODEL FOR SOFTWARE (CMM)


Conceptos fundamentales Es un modelo de madurez de procesos (Capability Maturity Model) desarrollado por el Instituto de Ingeniera de Software (S. E. I.), en conjunto con la Universidad de Carnegie Mellon de Pittsburg Pennsylvania, como gua para implementar metodologas, siendo la base para una certificacin de calidad (ISO 9000). El CMM mide la madurez de las prcticas de desarrollo de sistemas de las organizaciones. Se evala a travs de auditorias especializadas que dan la certificacin. El modelo est organizado en cinco niveles de madurez, cada nivel se mide por procesos clave que deben satisfacerse para poder pasar al siguiente. Los cinco niveles del proceso de madurez de software son:

5 4 3 2 1
INICIAL Impredecible y poco controlado REPETIBLE Es posible repetir tareas previamente realizadas exitosamente DEFINIDO Proceso caracterizado y bien comprendido MANEJADO Proceso medido y controlado

OPTIMIZADO Enfoque en mejora de procesos

Los procesos clave que tienen que ser dominados dentro de cada nivel y deben satisfacerse para pasar al siguiente son:
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

OPTIMIZADO Manejo del cambio de proceso Manejo del cambio de tecnologa Prevencin de defectos

MEJORA CONTINUA DE PROCESOS

MANEJADO Manejo de la calidad del software Manejo cuantitativo del proceso

CALIDAD DE PRODUCTO Y PROCESO

DEFINIDO Revisiones Coordinacin entre grupos Ingeniera de productos de software Administracin integrada Capacitacin Definicin organizacional de los procesos Enfoque organizacional a procesos

PROCESO INTEGRADO

REPETIBLE Existe la planeacin de proyectos Manejo de requerimientos Manejo y supervisn de proyectos Manejo de la configuracin de software Control de calidad Manejo de contratos

MANEJO DE PROYECTOS

INICIAL Algunas prcticas son informales La Calidad cambia de proyecto en proyecto Los procesos no estn documentados El xito depende de los individuos

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

II. ADMINISTRACIN DE PROYECTOS


1. CONCEPTOS

El Objetivo de contar con un proceso definido de administracin de proyectos asociados a la Tecnologa de la Informacin, es incrementar las posibilidades de cumplir o exceder las necesidades y expectativas del usuario, dentro del tiempo y costos programados, y la calidad especificada, el tener este proceso documentado y llevarlo a cabo cumple con las caractersticas del nivel 2 del CMM, lo que indica que las tareas y actividades realizadas exitosamente dentro del proceso pueden ser repetibles. Este proceso debe incluir: Autorizacin: Para asegurar la justificacin y aprobacin del patrocinador del proyecto. Propsito: Documentar el convenio entre el equipo desarrollador del proyecto y el patrocinador del mismo. Esta especificacin escrita se actualiza cuando se requiera e identifica los principales objetivos del proyecto, supuestos, restricciones, entregables, fases, calendario de compromisos y criterios de aceptacin. Planeacin: Asegurar que el plan del proyecto incluya: Plan: Actividades con dependencias e hitos contra los cuales se medir el avance de los mismos. Administracin de recursos y costos: Para asegurar que se definan todos los recursos fsicos requeridos para completar el proyecto y realizar una estimacin del costo total de los recursos. Roles y responsabilidades: Para asegurar estos y las relaciones de reporte del proyecto Comunicacin: Asegurar la realizacin de los reportes de avance peridicos versus hitos y entregables. Disposicin operacional: Asegurar que todas las actividades de implementacin hayan sido identificadas, documentadas y revisadas por todas las reas impactadas. Administracin del riesgo: Asegurar que el riesgo sea identificado, evaluado, documentado, monitoreado y administrado a travs de estrategias de mitigacin. Seguimiento:

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Asegurar el control del proyecto y administrar desviaciones mediante el establecimiento de mtricas de seguimiento y mediciones de avance, revisin peridica de resultados reales y desempeo versus planes y ejecucin de acciones correctivas cuando los resultados reales y el desempeo difieran de los planes. Administracin del cambio. Es asegurar que los cambios a requerimientos de los usuarios y compromisos relacionados son administrados, comunicados y acordados por todas las partes afectadas y que los componentes clave del plan del proyecto se actualizan por cambios relevantes de enfoque, costo, plan, uso de recursos o riesgo. Revisiones administradas: Para monitorear el avance del proyecto Revisiones post- implantacin: Para asegurar que las revisiones post proyecto sean completadas para evaluar la efectividad de la implantacin del proyecto y donde se pueden hacer mejoras al proceso, para futuros proyectos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

2. DOCUMENTACIN Especificacin de trabajo solicitado (ETS) Producto de la planeacin (PDP) Especificacin de trabajo solicitado cambio (ETS cambio) Matriz de roles y responsabilidades Bitcora de control de cambios Bitcora de control de riesgos Bitcora de control de desviaciones Reporte de avance Acta de trmino Encuesta final

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

ESPECIFICACIN DEL TRABAJO SOLICITADO


ETS

1. Identificacin

Nombre de la Solicitud Nm. de solicitud Fecha de Solicitud: dd/mm/aaaa

Nombre del Departamento Usuario: Nombre y puesto del solicitante: Nombre del Lder:

Direccin General

Fecha estimada de trmino: dd/mm/aaaa

2. Antecedentes. Situacin actual y acontecimientos previos que originan la necesidad o determinan la oportunidad. Breve descripcin de como opera el proceso actualmente. 3. Objetivo. Es la finalidad que se persigue con el proyecto. Descripcin del problema o necesidad que origina la iniciacin del proyecto. Objetivo funcional. Objetivo del proyecto. 4. Alcance. Descripcin de lo que se har (y lo que no) en trminos macro. 5. reas Participante. Nombre del participante Departamento Telfono o extensin

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

6. Suposiciones. Supuestos y prerrequisitos para que se cumpla con el objetivo del proyecto. 7. Restricciones. Factores que limitan la ejecucin de las actividades del proyecto, en cuanto a tiempo, costo y calidad. 8. Costo-beneficio. (Estimacin Preliminar)** Indicar la estimacin preliminar (nivel 0) con una precisin aproximadamente de +-40% de la aplicacin de recursos y del costo en la ejecucin del proyecto. Tambin se debe indicarse el beneficio que traer el proyecto una vez terminado. 9. Categora Con base a la estimacin preliminar, asignar la categora que le corresponda al proyecto.
CATEGORA PARMETROS ESTIMADO RESULTADO CATEGORA

ESFUERZO 1 2 3 Hasta 80 hrs.

COSTO $0 Pesos

ESFUERZO

COSTO

Hasta 200 Hasta $200,000 Pesos das/persona Mayor a 200 Mayor a $200,000 Pesos das / persona

NOTA. Para proyectos Categora 1 incluir el calendario de actividades con fechas de inicio y terminacin, as como el uso de recursos a ejercer en cada una de ellas. Este calendario puede obtenerse del reporte del seguimiento del Plan detallado con Recursos, y se anexa a este documento, como se indica en la etapa de planeacin.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

1) Seccin de Firmas FIRMAS DE ENTENDIMIENTO DE LA SOLICITUD Este Documento se firma en comn acuerdo entre el rea Usuaria y la Direccin General de Tecnologa de la Informacin, que la Solicitud esta correctamente especificada. USUARIO DIRECCIN GENERAL DE LDER TECNOLOGA DE LA INFORMACIN REA: REA: REA:

Nombre y firma del Director del rea Usuaria

Nombre y firma

Nombre y firma del Lder de proyecto

Fecha dd/mm/aaaa

Fecha dd/mm/aaaa

Fecha dd/mm/aaaa

2) Comentarios. Comentarios para ser considerados en la elaboracin del PDP. 3) Apndices. Documentos anexos que sustenten la especificacin.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

PRODUCTOS DE LA PLANEACIN
PDP
1. IDENTIFICACIN Num. de Proyecto: Nombre Oficial del Proyecto: Direccin General Puesto del solicitante:

Departamento Usuario: Nombre del solicitante Nombre del Lder: Fecha Acordada Termino: dd/mm/aaaa Inversin y Gasto (Estimacin nivel 1): Valor Presente Neto (VPN):

Esfuerzo (Estimacin Nivel 1):

Tasa Interna de Retorno (TIR):

2. OBJETIVO Es la finalidad que se persigue con el proyecto. (Generalmente ser el mismo del ETS). Descripcin del problema o necesidad que origina la iniciacin del proyecto. Objetivo funcional. Objetivo del proyecto. 3. JUSTIFICACIN La necesidad por la cual se lleva a cabo el proyecto (Esta planteada en los Antecedentes del ETS). Situacin actual y acontecimientos previos que originan la necesidad o determinan la oportunidad. Breve descripcin de como opera el proceso actualmente. 4. ALCANCE Relacin y descripcin de alto nivel de los productos y el trabajo que se realizar y cuya entrega completa y satisfactoria marcan que el proyecto se ha concluido. Especifica que incluye el proyecto y que no. Que debe de entregar el proyecto. Limites del proyecto Procesos, caractersticas, y funciones del negocio incluidas y excluidas Impacto en la estructura de organizacin Interdependencia con otros proyectos 5. RESTRICCIONES
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 1 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Factores que limitan la ejecucin de las actividades del proyecto, en cuanto a tiempo, costo y calidad. 6. DIAGRAMA CONCEPTUAL Diagrama que muestre en forma general el esquema funcional que se tendr una vez concluido el proyecto. 7. CRITERIOS DE XITO Criterios cuantificables que deben ser alcanzados por el proyecto para que se considere exitoso. Deben incluir al menos medidas de costos, calendarios, y calidad. 8. TIPO DE PROYECTO POR REAS DE APLICACIN Identifica el tipo de proyecto de acuerdo a las siguientes reas de aplicacin. REA DE APLICACIN DESARROLLO DE SOFTWARE MANTENIMIENTO DE SOFTWARE ADECUACIN DE SOFTWARE COMERCIAL COMUNICACIONES COMPRA DE EQUIPO APLICA

9. PRODUCTOS A ENTREGAR Relacin de los productos crticos y no crticos que sern entregados al usuario y descripcin de las especificaciones de cada uno de ellos. 10.ESTRUCTURA DE DESCOMPOSICIN DEL TRABAJO (WBS) Esquema Orientado a describir en forma jerrquica las tareas definidas y que muestra el trabajo que ser desarrollado para alcanzar los objetivos del proyecto. El nivel mnimo de tarea/actividad debe de ser de1 a 10 das (8 a 80 hrs.) 11.SUPOSICIONES Supuestos que se han tomado como ciertos para la realizacin de la planeacin. 12.RECURSOS REQUERIDOS Resumen de los recursos necesarios para la atencin del proyecto. Normalmente se presenta el presupuesto de inversin y de gasto tanto del proyecto en si como necesario para la operacin del da con da. Donde se mostrarn tanto las necesidades de personal (esfuerzo), capacitacin, equipo de cmputo, comunicaciones, instalaciones fsicas, etc. 13.ESTRATEGIA DE COMUNICACIN
Procedimientos que sern utilizados a lo largo del proyecto para normar el proceso de comunicacin, describiendo actividades tales como el manejo de problemas y las revisiones de avance.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 1 2

M ET ODOLOG A 14.ROLES Y RESPONSABILIDADES

DE DESARROLLO DE SISTEMAS

Matriz que determina y muestra las responsabilidades de los participantes clave en el Proyecto.

15.CALENDARIO DE ACTIVIDADES Y USO DE RECURSOS


Calendario de principales actividades, con fechas de inicio y terminacin, as como el uso de recursos a ejercer en cada una de ellas.

Actividad

Fecha de Inicio

Fecha Termino

de

Recursos requeridos (cantidad y tipo)

Anexar el plan detallado

16.ESTRUCTURA DE LA ORGANIZACIN DEL PROYECTO (OBS) Esquema orientado a mostrar en forma Jerrquica a las relaciones de reporte de los participantes en el Proyecto. 17.BENEFICIOS DEL PROYECTO Indicar los beneficios cuantitativos que aportara el proyecto a la organizacin y al usuario, una vez concluido. Se incluir el comparativo contra el costo y su amortizacin en el tiempo. Adicionalmente se presentan los beneficios cualitativos o intangibles. 18.POSIBLES RIESGOS Y PLAN DE CONTINGENCIA Se presentan los posibles riesgos que pueda tener el proyecto, junto con las acciones para minimizar el riesgo, indicando en cada elemento la probabilidad que ocurra. 19.NOMBRE DEL USUARIO A ENCUESTAR Nombre de los usuarios que sern beneficiados por los productos y/o servicios del proyecto, para dirigir la encuesta de evaluacin del proyecto a su trmino. 20.FIRMAS DE COMPROMISO DE LOS PARTICIPANTES Los Directores de Tecnologa de la Informacin firman este documento, al igual que los Directores del rea Usuaria, constituyendo as la formalizacin del compromiso.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

FORMALIZACIN Hemos revisado los Productos de la Planeacin del proyecto Num.:________________, NOMBRE: ____________________________________________________________, y estamos de acuerdo con su contenido, por lo que confirmamos nuestra participacin en el desarrollo de este Proyecto y el cumplimiento de los compromisos sealados. DEPARTAMENTO RESPONSABLE FIRMA FECHA

Visto Bueno

DIRECCIN REA USUARIA Firma

DIRECCIN GENERAL DE LDER DEL PROYECTO TECNOLOGA DE LA INFORMACIN Firma Firma

Nombre Fecha

Nombre Fecha

Nombre Fecha

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

ESPECIFICACIN DEL TRABAJO SOLICITADO ETS-CAMBIO


Este formato deber llenarse exclusivamente cuando existan cambios a la situacin del proyecto

1) Identificacin Nombre de Proyecto: Numero de Proyecto: Fecha de solicitud del cambio dd/mm/aaaa Nombre del Lder

2) Situacin Los antecedentes que originaron el establecimiento del cambio al proyecto. 3) Estado Indicar el estado actual del proyecto, que puede ser: en Ejecucin o Suspendido. 4) Replaneacin Especificar en el cuadro los cambios que se sufre el proyecto en cuanto a fechas, esfuerzo y costo, adems del nuevo calendario de actividades. Anexar calendario de principales actividades, con fechas de inicio y trmino, as como el uso de recursos a ejercer en cada una de ellas. Replaneacin Anterior Nuevo

Fecha de Termino Esfuerzo (Das/Persona) Presupuesto

5) Motivo y Descripcin del Cambio

Descripcin breve de las razones que generan el cambio de situacin del proyecto, as como la descripcin del cambio mismo.
6) Impacto del cambio Cuantificacin por la afectacin en esfuerzo, fechas compromisos y presupuestos acordados y/o afectacin a la operacin. 7) Acuerdo Escribir con quines y cundo se estableci el acuerdo, para determinar la nueva situacin del proyecto.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 1 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

8) Seccin de Firmas FIRMAS DEL ACUERDO AL CAMBIO DE LA SOLICITUD Este Documento se firma en comn acuerdo entre la Direccin Usuaria y la Direccin de Tecnologa de la Informacin, que los cambios solicitados estn correctamente especificados. DIRECCIN USUARIA DIRECCIN GENERAL DE LDER DEL PROYECTO TECNOLOGA DE LA INFORMACIN firma firma firma

Nombre Fecha dd/mm/aaaa

Nombre Fecha dd/mm/aaaa

Nombre Fecha dd/mm/aaaa

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Matriz de roles y Responsabilidades Nmero y nombre de proyecto: Elabor: OBS (rea o nombre del participante WBS (nombre actividad) de la Fecha:

R = Responsable, A = Autoriza, P = Participa, I = Informado

Bitcora de Control de Cambios en proyectos Nmero y nombre de proyecto: Elabor:


No. Fecha de recepcin Descripcin cambio del Solicitante Fecha acordada Recursos requeridos (horas/persona, $)

Fecha:
Estado Observacione s

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Bitcora de Control de Riesgos en proyectos Nmero y nombre de proyecto: Elabor:


No Fecha de Identificacin Descripcin del riesgo Impacto (severidad) Probabilidad ocurrencia de Acciones preventivas correctivas o

Fecha:
Fecha planeada de solucin Estado

Impacto: Bajo = 1, Medio = 2, Alto = 3 Probabilidad de ocurrencia: Baja = .25, Media = .50, Alta = .75, Seguro = 1

Bitcora de Control de Desviaciones en proyectos Nmero y nombre de proyecto: Elabor:


No Fecha de Deteccin Descripcin desviacin de la Impacto (severidad) Acciones correctivas Fecha planeada de solucin Estado

Fecha:
Observacin

Impacto: Bajo = 1, Medio = 2, Alto = 3

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 8

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Reporte de avance de proyectos Nmero y nombre de proyecto: Elabor: Fecha de inicio del proyecto: Reporte del periodo del Porcentaje estimado de avance: T A B C D E Total de actividades del proyecto Numero de actividades terminadas Numero de actividades en proceso vencidas Numero de actividades en proceso normales Numero de actividades no iniciadas vencidas Numero de actividades no iniciadas normales Avance A/T Retrazo (B + D) / T Pendiente (B + C + D + E) / T OBSERVACIONES: Fecha: Fecha planeada de trmino: al

Acta de trmino de proyectos


Nmero y nombre de proyecto: Elabor: Fecha de inicio del proyecto: Lder del proyecto: Fecha:

Estoy de acuerdo en que todas las actividades de este proyecto han terminado y estoy completamente satisfecho con la operacin actual de los procesos y sistemas implementados, por lo cual no tengo inconveniente en cerrar este proyecto, en el entendido que cualquier adicin o cambio ser tratado como otro requerimiento. FIRMAS DE ACUERDO: PARTICIPANTE REA O DEPARTAMENTO FIRMA FECHA OBSERVACIONES

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

1 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Encuesta final de proyectos


Nmero y nombre de proyecto: Elabor: Fecha de inicio del proyecto: Lder del proyecto Datos de la persona encuestada Nombre Puesto Domicilio Telfono Departamento rea Direccin Direccin general MAL
FUNCIONALIDAD

Fecha: Fecha planeada de trmino:

REGULAR

BIEN

EXCELENTE

OBSERVAC.

ASPECTOS TCNICOS CUMPLIMIENTO DE COMPROMISOS ACTITUD DEL PERSONAL TCNICO CUMPLIMIENTO DEL PRESUPUESTO DOCUMENTACIN OPERATIVA CAPACITACIN

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

3. FLUJO DEL PROCESO Conceptos


FLUJO DEL PROCESO DE ADMINISTRACIN DE PROYECTOS
INICIO PLANEACION EJECUCION POST-IMPLANTACION Y CIERRE DAR SEGUIMIENTO A PUESTA EN PRODUCCIN PREPARAR DOCUMENTOS PARA LA REVISION MEDIR SATISFACCION DEL USUARIO REVISAR Y EVALUAR EL DESARROLLO Y RESULTADO DEL PROYECTO ELABORAR Y APROBAR REPORTE FINAL APROBAR EL PRESUPUESTO ADMINISTRAR CAMBIOS DE ESTADO DEL PROYECTO DE LA CALIDAD DEL PROYECTO CERRAR PROYECTO

RECIBIR REQUERIMIENTO, Y ASIGNAR LIDER

PRIORIZAR PROYECTO PLANEAR EL PROYECTO, ELABORAR PDP CON ESTIMACION NIVEL 1 REQUISITAR AUTORIZACION DEL PRESUPUESTO APROBAR EL PLAN DEL PROYECTO (PDP)

EJECUTAR EL PLAN DEL PROYECTO

CONTROL MEDIR EL DESEMPEO Y DIFUNDIR MEDICIONES

GENERAR ETS CON ESTIMACIN NIVEL 0

CATEGORIZAR Y AUTORIZAR ETS

CONTROL VARIACIONES DE: ESFUERZO, COSTO, PRODUCTOS, PRIORIDADES, ALCANCE Y RIESGOS

ASEGURAMIENTO

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

INICIO

RECIBIR REQUERIMIENTO Y ASIGNAR LIDER

GENERAR ETS CON ESTIMACION NIVEL 0

CATEGORIZAR, REVIZAR Y AUTORIZAR ETS

Las estimaciones de recursos, tiempo y costo generada en esta fase tienen una posibilidad de desviacin mxima aceptada de +/- 40%. En esta parte del proceso se genera la Especificacin de Trabajo Solicitado (E T S) Este documento es formulado por el lder del proyecto en funcin del requerimiento generado por el solicitante. ASPECTO RELEVANTE: En esta fase se evala la categora del proyecto. Evaluacin de categoras Se asigna la categora del proyecto con base en el esfuerzo global preliminar de acuerdo con los siguientes parmetros:

el costo

Categora 1.- Si el esfuerzo es menor o igual a 30 das/persona y no requiere gasto adicional al gasto corriente. Categora 2.- Si el esfuerzo es menor o igual a 200 das/persona y el costo es menor o igual a $2,000.000 pesos. Categora 3.- Si el esfuerzo es mayor a 200 das/persona o el costo es mayor de $2,000.000 pesos. La categora a asignar ser la mayor que aplique al proyecto. PLANEACIN

PRIORIZAR PROYECTOS

PLANEAR EL PROYECTO / PDP CON ESTIMACIN NIVEL 1

REQUISITAR AUTORIZACION DEL PRESUPUESTO

APROBAR EL PLAN DEL PROYECTO (PDP)

APROBAR EL PRESUPUESTO

En esta fase se elabora el documento Producto de la Planeacin o Plan del Proyecto y es formulado por el lder del proyecto en funcin del ETS. ASPECTO RELEVANTE: Se genera el PDP, con estimacin de nivel 1
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

+/-

25 %.
2 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

EJECUCIN Y CONTROL
CONTROLAR VARIACIONES DE: ESFUERZO, COSTO, PRODUCTOS, PRIORIDADES, ALCANCE Y RIESGOS

MEDIR EL DESEMPEO Y DIFUNDIR MEDICIONES

ADMINISTRAR CAMBIOS DE ESTADO DEL PROYECTO

ASPECTOS RELEVANTES: Se deben comprender como se generan las mediciones de seguimiento a proyectos. Es necesario registrar y administrar el seguimiento a Proyectos, Lderes y Participantes. Se deben registrar y administrar los riesgos que presente el proyecto. Se deben registrar los cambios en la bitcora de Control de cambios, esto se generara con base al ETS CAMBIO.

POST-IMPLANTACIN Y CIERRE
DAR SEGUIMIENTO A LA PUESTA EN PRODUCCIN REVISAR Y EVALUAR EL DESARROLLO Y RESULTADOS DEL PROYECTO

PREPARAR DOCUMENTOS PARA LA REVISION

MEDIR SATISFACCION

ELABORAR Y APROBAR REPORTE

CERRAR PROYECTO

ASPECTOS RELEVANTES: Es muy til conocer el nivel de satisfaccin de usuario mediante una encuesta La retroalimentacin del resultado de la encuesta, as como los aprendizajes del proceso son bsicos para mejorarlo. Formalizar el cierre de proyecto Elaborar carta de liberacin a produccin y al usuario

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

VALOR DEVENGADO
Para los proyectos de categora 2 y 3 es muy til llevar el control mensual del valor devengado, para contar con un control mas objetivo. Ejemplo de clculo de valor devengado de un proyecto

Fecha de inicio Enero

mayo

Fecha fin diciembre

BAC Presupuesto al trmino (Budget at completion) BCWS Costo presupuestado del trabajo programado (Budgeted cost of work scheduled) ACWP Costo actual del trabajo realizado (Actual cost of work performed) BCWP Costo presupuestado del trabajo realizado (Bubgeted cost of work performed) 58% SV Varianza programada (Schedule variante) = BCWP BCWS = SPI Indice del rendimiento programado (Schedule performance index) = BCWP/BCWS = CV Costo de la varianza (Cost variante) = BCWP ACWP = CPI Indice del costo de rendimiento (Cost perfomance index) = BCWP/ACWP = ETC Estimado para terminar (Estimate to complete) = BAC BCWP = EAC Estimado al termino (Estimate at complete) = ETC + ACWP =

120,000 50,000 60,000 70,000 20,000 1.4 10,000 1.16 50.000 110,000

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

ASEGURAMIENTO DE CALIDAD

EJECUTAR LA AUTO-EVALUACION DE CALIDAD Y ESTABLECER ACCIONES CORRECTIVAS

EJECUTAR LA AUDITORIA DE ASEGURAMIENTO DE CALIDAD

SI SE GENERARON NO CONFORMIDADES?

CONTINUAR CON LA SIGUIENTE FASE DEL PROYECTO

NO

ESTABLECER ACCIONES CORRECTIVAS O INICIAR PROCESO DE ESCALAMIENTO

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

III. MODELO DE DESARROLLO 1) CONCEPTOS

MODELO DE DESARROLLO DE UN PROYECTO DE SOFTWARE

SOLICITUD IDEA

M
ENTENDIMIENTO ESPECIFICACION DE TRABAJO

PREANALISIS

PLAN DEL PROYECTO

ANALISIS DISEO

DOCUMENTO DE ANALISIS

ESPECIFICACIONES DE CONSTRUCCION CONSTRUCCION PRUEBAS SISTEMA CONSTRUIDO IMPLANTACION ACEPTACION DEL FIN DEL PROYECTO ENCUESTA FINAL CODIGO GUIONES DE PRUEBAS

CONTROL Y ADMINISTRACION DEL PROYECTO

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

2. ETAPAS A. PREANLISIS B. PLANEACIN C. ANLISIS o Generalidades del Paradigma orientado a objetos o Anlisis orientado a objetos o Anlisis estructurado o Modelado de sistemas con UML D. DISEO o Diseo estructurado o Diseo de la interfaz de usuario E. DESARROLLO O CONSTRUCCIN F. PRUEBAS G. IMPLANTACIN

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

A.

PREANALISIS El disparador de cualquier desarrollo, ya sea de cambio o nuevo, se debe documentar a travs de una solicitud por escrito y debe de ser enviada a la Direccin General de Tecnologa de la informacin. Con base a esta solicitud, Tecnologa de la Informacin asigna un lder de proyecto, donde su primera actividad es elaborar un pre-anlisis de esta solicitud y lo documenta en una Especificacin de Trabajo, donde se presenta una serie de datos bsicos, as como una estimacin preliminar de los impactos con una precisin aproximada de un + - 40 % y se obtiene el Visto Bueno del rea Usuaria y de la Direccin General de Tecnologa de la Informacin. Documento final: Especificacin de Trabajo Solicitado (ETS).

B.

PLANEACIN Con base a la Especificacin de Trabajo autorizada, el lder del proyecto inicia las actividades de planeacin detallada del proyecto, elaborando el documento Plan del proyecto o Producto de la Planeacin (PDP), cuya finalidad es tanto la involucracin de todos los participantes del proyecto donde cada uno de ellos estima su participacin y se establece la organizacin del proyecto para su desarrollo. Uno de los principales productos de esta etapa es el plan detallado a nivel de actividad de cada participante y el estimado a detalle de los recursos humanos, financieros y materiales para la realizacin del proyecto. En el caso de requerir inversin de gastos adicionales a los corrientes, es necesario obtener la autorizacin de la disponibilidad de estos recursos. Documento final: Producto de la planeacin o Plan de Proyecto (PDP).

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 8

M ET ODOLOG A C. ANLISIS

DE DESARROLLO DE SISTEMAS

Una vez obtenida la autorizacin del plan y de los recursos a utilizar, se procede a la ejecucin misma del plan de trabajo, donde la siguiente etapa es el anlisis detallado de los requerimientos planteados. El producto de esta etapa es un documento avalado por el usuario de acuerdo a la metodologa de anlisis estructurado, o anlisis orientado a objetos. Se cuenta con varias tcnicas para el anlisis, las que se recomiendan son: Generalidades del paradigma orientado a objetos Anlisis orientado a objetos Anlisis estructurado Modelado se sistemas con UML Generalidades Del Paradigma Orientado A Objetos Objeto Un objeto representa un elemento identificable con ciertas caractersticas (atributos) y que puede realizar un conjunto de acciones (operaciones). Los objetos son la pieza fundamental que combina tanto estructura como comportamiento. Un objeto es el elemento donde la estructura de datos y el comportamiento estn estrechamente relacionados. Un elemento con estado, comportamiento e identidad. Una instancia de una clase. Un objeto es algo que tiene: Estado. Comportamiento. Identidad. Estado: El estado de un objeto es una de las condiciones posibles en las que un objeto puede existir. El estado de un objeto normalmente cambia con el paso del tiempo. El estado de un objeto usualmente se implementa por una serie de propiedades (llamadas atributos), con valores determinados, ms las relaciones que el objeto pueda tener con otros objetos. Comportamiento: El comportamiento determina como acta y responde un objeto a peticiones de otros objetos. El comportamiento visible de un objeto se modela por un conjunto de mensajes a los que puede responder (las operaciones que el objeto puede desempear). Identidad: Cada objeto tiene una identidad nica, an si el estado es idntico al de otro objeto.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

2 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Clase Una clase es una descripcin de un grupo de objetos con propiedades comunes (atributos), comportamiento comn (operaciones), relaciones comunes con otros objetos (asociaciones y agregaciones) y semnticas comunes. Un objeto es una instancia de una clase. Una clase es una abstraccin en la que enfatiza caractersticas relevantes y suprime otras caractersticas. La abstraccin nos ayuda a manejar la complejidad. Reglas para nombrar una Clase: El nombre de una clase debe ser un nombre singular que caracterice de la mejor forma a la abstraccin. La dificultad en el nombramiento de una clase puede indicar que una abstraccin est pobremente definida. Los nombres deben venir directamente del vocabulario del dominio. Una gua de estilo debe dictar convenciones de nombres para clases. Las clases se nombran usando sustantivos singulares. Los nombres de clases empiezan con una letra minscula. No se usan palabras subrayadas. Los nombres compuestos de palabras mltiples se ponen juntas y la primera letra de cada palabra adicional se escribe en maysculas. Caractersticas de los objetos: Abstraccin.- Omitir las propiedades y acciones de un objeto y dejar slo aquellas que nos interesan. Clasificacin.- Los objetos con la misma estructura y comportamiento son agrupados en clases. Polimorfismo.- El comportamiento de una clase puede variar de acuerdo a ciertas circunstancias. En ocasiones una operacin tiene el mismo nombre en diferentes clases. Herencia.-Las clases son organizadas jerrquicamente. Las clases hijas conservan la estructura y comportamiento de las clases padres. Encapsulamiento.- Permite ocultar los detalles de la implementacin de un objetos. Los objetos ocultan la funcionalidad interna de sus operaciones, de otros objetos y del mundo exterior. Mensajes.- Para que los objetos de un sistema trabajen en conjunto, un objeto enva a otro un mensaje para realizar una operacin y el objeto receptor ejecutar la operacin Ventajas de la tecnologa orientada a objetos Facilita la re-utilizacin de la arquitectura y el cdigo. Los modelos reflejan de manera ms cercana el mundo real. Describe con mayor exactitud los procesos y datos incorporados. Descomposicin basada en particin natural.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 3 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Ms fcil de entender y mantener. Estable. Un cambio pequeo en requerimientos no significa cambios masivos en el sistema en desarrollo.

Aplicaciones de la tecnologa orientada a objetos Facilita el diseo e implementacin de sistemas con Interfaces Grficas de Usuario (GUI). Permiten desarrollar sistemas inmersos y de tiempo real con mayor calidad y flexibilidad. Los sistemas de comercio electrnico requieren robustez y estabilidad que la tecnologa de objetos proporciona.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Anlisis Orientado A Objetos DIAGRAMA ENTIDAD RELACIN

Conexin Objetos de Datos De 1 a muchos (requerido) De 1 a muchos (opcional) De 1 a 1 (requerido) Relaciones De 1 a 1 (opcional)

Los diagramas entidad relacin identifican un conjunto de componentes primarios, objetos de datos, atributos, relaciones y varios indicadores de tipo, el principal propsito de este diagrama es representar los objetos de datos y sus relaciones: Los Objetos de datos se representan como rectngulos etiquetados Las Relaciones se indican mediante rombos Las Conexiones son lneas que muestran las relaciones entre los objetos de datos, establecidas mediante variadas lneas especiales de conexin.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

RELACIONES ENTRE CLASES Y ENTRE OBJETOS

Clase Herencia Plantilla de Clase Conexiones de doble trazo + Una o ms instancias { } Mensaje

Este diagrama de clases y/o objetos indica la arquitectura de clases de un sistema, las clases se definen como parte del diseo de un sistema y existen independientemente del comportamiento en ejecucin del sistema, sin embargo los objetos se crean y se eliminan dinmicamente a medida que se ejecuta el sistema, para el diseador es de un valor incalculable el disponer de una notacin que capture la semntica dinmica o imagen temporal de un programa, refleja cada instancia de una clase, las operaciones que se le aplican y los mensajes que se le pasan. La herencia se representa con un smbolo de flecha Las conexiones de doble trazo, indican que una clase utiliza informacin contenida en otra clase. Las Plantillas de Clase (doble trazo) indican la cardinalidad, adems del propio diagrama de clases, se puede definir cada clase con estas plantillas que incluya su nombre, sus atributos y sus operaciones, as como la informacin sobre la herencia, los parmetros y el comportamiento tomando en cuenta que esta plantilla de la clase no es realmente una parte del diagrama, sino que se crea para complementarlo. Instancias podr haber una o ms instancias representadas por el signo +. Mensajes un objeto puede mandar mensajes a otro objeto colocando un recuadro etiquetado que indica el tipo de datos que contiene el mensaje o mensajes.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Anlisis Estructurado Esta metodologa requiere del levantamiento de informacin ordenada y plasmada en los siguientes 5 captulos: Propsito del sistema Descripcin del aspecto ambiental Diagrama de contexto (Notacin: Yourdon o Gane &Sarson) Descripcin del aspecto de comportamiento Descripcin del aspecto de informacin Propsito Del Sistema Es una declaracin textual breve y concisa del objetivo del sistema. La declaracin del propsito debe de contar de una o ms frases iniciando con un verbo. Sin embargo jams debe de llegar a ms de un prrafo, ya que la intencin no es proporcionar una descripcin completa y detallada del sistema. Debe resumir los beneficios tangibles y cuantificables que se logran con el nuevo sistema. (Costo/Beneficio). Descripcin Del Aspecto Ambiental Es la identificacin de las relaciones del sistema con su medio ambiente. Esto se lleva a cabo al Identificar el origen de la informacin usada por el sistema y el destino de la informacin producida por el sistema. Alcance del Sistema Es la determinacin de las fronteras del sistema; esto se logra conocer al delimitar el sistema y su ambiente que le rodea. Por lo cual es importante definir las interfaces entre el sistema y el ambiente, adems, se necesita saber que informacin entra al sistema desde el ambiente exterior, y qu informacin produce como salida al ambiente externo.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagrama De Contexto El diagrama de contexto es un esquema que consiste en: flujos de datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el sistema.

Sistema SOFTWARE

Caractersticas del diagrama de contexto: El sistema es considerado como un solo proceso. Debe de tener mnimo una entrada de informacin. Debe de tener mnimo una salida de informacin. Las entidades externas se presentan en rectngulos y van fuera del sistema. Las entidades externas deben de tener un nombre descriptivo concreto y deben de hacer referencia al rol que desempean en el sistema. Todos los flujos de informacin deben de tener un nombre asociado que represente la informacin que esta fluyendo. No es valido relacionar entidades externas. Reglas que deben seguirse en la construccin del diagrama de contexto: El nombre dentro de este proceso suele ser el nombre del sistema completo o un acrnimo convenido. Los terminadores se representan con rectngulos y se comunican directamente con el sistema a travs de flujos de datos o de control, o bien a travs de almacenes externos. Los terminadores o destinos de los datos no se comunican directamente entre si dado que son externos al sistema. Los flujos que aparecen en el diagrama de contexto deben modelar datos que entran y salen del sistema.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Descripcin Del Aspecto De Comportamiento Es la descripcin de los procesos que son parte del sistema, incluyendo la informacin usada y producida por este. Es necesario describir el comportamiento que del sistema se requiere para que interacte de manera exitosa con el ambiente. En esta etapa del anlisis estructurado se utiliza el Diagrama de Flujo de Datos (DFD). El Diagrama de Flujo de Datos es una representacin grafica que permite al analista definir entradas, procedimientos y salidas de la informacin en la organizacin, permitiendo de esta manera comprender los procedimientos existentes con la finalidad de optimizarlos, reflejndolos en el sistema propuesto. El propsito del diagrama de Flujo de Datos tiene es representar grficamente el sistema a nivel lgico y conceptual, ilustrando los componentes esenciales de un proceso y la forma en que interactan. El flujo de datos es la representacin simblica utilizada para describir el movimiento de bloques o paquetes de informacin de una parte del sistema a otra, representando los datos en movimiento, estableciendo la comunicacin entre los procesos; almacenes y entidades externas. Reglas de construccin El diagrama de flujo de datos de nivel 0 (nivel mas alto) debe reflejar el software / sistema como una sola burbuja. Deben anotarse cuidadosamente la entrada y la salida principales. Esta burbuja se debe de ir descomponiendo separando los procesos por importancia. El refinamiento debe comenzar aislando estos procesos, los elementos de datos y los almacenes de datos que sean candidatos a ser representados en el siguiente nivel. Todas las flechas y las burbujas deben ser rotuladas con nombres significativos. Entre sucesivos niveles se debe mantener la continuidad del flujo de informacin. Los datos no pueden ser creados ni destruidos por un flujo de datos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Notacin:
El flujo se representa mediante flechas indicando el sentido del flujo de la informacin:

PROCESO: Representa procedimientos utilizados para transformar datos de entradas en salidas. Reglas de construccin Un proceso no es origen ni final de los datos, slo lugar de transformacin de los mismos. Un proceso puede transformar un dato en varios. Debe contener el nombre del proceso correspondiente. En la parte superior izquierda se coloca un nmero identificador del proceso que indica el nivel del DFD en que se encuentra. Debe contener la unidad o rea dentro de la organizacin donde se realiza el proceso. Notacin: Yourdon Gane & Sarson

Almacenamiento: Representa un depsito de informacin dentro del sistema. Reglas de construccin Representa informacin en reposo. No puede crear, destruir y transformar datos. No puede estar comunicado un almacn con otro almacn ni una entidad externa. No debe de estar referido al entorno fsico sino al lgico.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Notacin Yourdon Gane & Sarson

ENTIDADES: Son usadas para determinar una actividad externa (otro departamento, un negocio, una persona, o una mquina) que puede enviar datos o recibirlos del sistema. Reglas de construccin Son externas al sistema que se esta modelando. Es evidente que ni los analistas ni el diseador del sistema estn en posibilidades de cambiar los contenidos de una entidad. Las relaciones que existen entre las entidades no se muestran en el modelo DFD. Notacin Yourdon Gane & Sarson

Nivelacin: Existe la nivelacin descendente y ascendente, y significa que se desea agrupar procesos relacionados en agregados con significado, cada uno de los cuales representar una burbuja en un nivel superior.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 8

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Reglas de la nivelacin ascendente Cada agrupacin de procesos debe involucrar respuestas relacionadas cercanamente (cada burbuja se nombra de manera significativa con relacin a los procesos que maneja). Se debe tratar de esconder o "enterrar" datos almacenados que aparecen en el nivel inferior (si observa que un grupo de procesos en los DFD preliminares que se refieren a un almacn comn y no hay otros procesos en el DFD preliminar que se refieren a ese almacn, entonces puede crear una burbuja en el nivel superior para esconderlo). Reglas de la nivelacin descendente Si encuentra una burbuja de proceso que realiza una funcin compleja, trate de identificar sub-funciones, cada una de las cuales pueda ser hecha por una burbuja de nivel inferior. Los flujos de datos de entrada y salida proporcionarn la mejor gua para la nivelacin descendente. Al realizar la actividad de nivelacin ascendente y descendente, el balanceo es de gran importancia, es decir deben asegurarse que las entradas y las salidas netas que se muestran en la burbuja de alto nivel correspondan a las entradas y salidas netas que muestran para el diagrama de nivel inferior. Descripcin Del Aspecto De Informacin Se refiere a la informacin usada por el sistema y como cambia a travs del tiempo. En esta etapa del anlisis estructurado se incluye el Diagrama Entidad - Relacin (E-R), as como el Diccionario de Datos (DD). Diagrama Entidad - Relacin Es conocido como E-R o DER y es un modelo de red que describe con un alto nivel de abstraccin la distribucin, movimiento y procesamiento de datos almacenados en un sistema. Es muy diferente del DFD, que modela las funciones que lleva a cabo un sistema; y es diferente del diagrama Transicin de Estados que modela el comportamiento dependiente del tiempo de un sistema. Componentes: Entidades. Relaciones. Flujos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

3 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

ENTIDADES: Representa una coleccin o conjunto de objetos del mundo real cuyos miembros juegan un papel muy importante en el desarrollo del sistema pueden ser identificados de manera nica y ser descritos a travs de atributos. Se representan por medio de un rectngulo:

RELACIONES: Son una serie de conexiones o asociaciones entre las entidades y estas ltimas estn conectadas con la relacin por medio de flechas. Se representan por medio de rombos:

FLUJOS: Se encargan de conectar las relaciones con las entidades y viceversa. Se representan por medio de lneas:

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

ATRIBUTOS

VALORES

Atributos.- Son aquellos datos que permiten describir a una entidad tales como nombre, domicilio, nmero telefnico, y estos deben de aplicarse a cada instancia de un tipo de entidad. Valores.- Son las caractersticas propias de una entidad. Diccionario De Datos El diccionario de Datos es una lista organizada de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento comn en todas las entradas, salidas, componentes de almacenes y clculos intermedios. Propsito: Describir el significado de los almacenes que se muestran en los DFD. Describir la composicin de agregados de paquetes de datos que se mueven a lo largo de los flujos es decir, paquetes complejos que pueden descomponerse en unidades ms elementales como el domicilio de un cliente se puede descomponer en ciudad, estado y cdigo postal. Describir la composicin de los paquetes de datos en los almacenes.

Especificar los valores y unidades relevantes de piezas elementales de informacin en los almacenes de datos. Notacin
= + () {} [] ** @ | Est compuesto de Y Optativo Iteracin Seleccionar una de varias alternativas Comentario Identificador (campo clave) para un almacn Separa opciones, alternativas en la construccin

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Definiciones: Est compuesto de La definicin de un dato se introduce con el smbolo "=". En este contexto, el "=" se lee: "se define como", o "se compone de", o simplemente "significa". El diccionario de datos debe de proporcionar una breve narrativa, encerrada entre caracteres "*", que describa el significado del trmino en el contexto del usuario. Ejemplo: Fecha de nacimiento = *Unidades: das a partir del 1 de enero de 1900*

Optativo Un dato opcional, como la frase implica, es aquel que pueda estar o no presente en un dato compuesto. El nombre de un cliente pudiera no incluir un segundo nombre. El domicilio de un cliente pudiera no incluir informacin secundaria como el no. de departamento. Las situaciones de este tipo deben verificarse con cuidado con el usuario y deben documentarse precisamente en el diccionario de datos. Ejemplo: Domicilio de cliente = domicilio de envo + (domicilio para cuentas) Iteracin: La notacin de iteracin se usa para indicar la ocurrencia repetida de un componente de un dato. Se lee como "cero o ms ocurrencias de"... Ejemplo: Solicitud = nombre del cliente + domicilio de envi + {artculo} Lo anterior significa que la solicitud siempre debe de contener un nombre de cliente, un domicilio de envo, y tambin cero o ms ocurrencias de un artculo. Tambin habr ocasiones en las que el usuario querr especificar los lmites inferior y superior de la iteracin. Tal vez, en el ejemplo anterior, el cliente seale que no tiene sentido que un cliente haga un pedido de cero artculos, debe haber por lo menos uno como se muestra a continuacin... Ejemplo: Solicitud = nombre del cliente + domicilio de envo + 1{artculo} 10 Nota: es posible especificar slo el lmite inferior o el superior, ambos o ninguno.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Seleccin: La notacin de seleccin indica que un dato consiste en exactamente un elemento dentro de un conjunto de opciones alternativas. Las opciones se encierran entre corchetes "[" y "]", y se separan por una barra vertical "|". Ejemplos: Sexo = Tipo de cliente = [Femenino | Masculino] [Gobierno | Industria |Universidad |Otro]

Alias: Un alias como el trmino implica, es una alternativa de nombre para un dato. Esto es una ocurrencia comn cuando se trata con diversos grupos de usuarios en diferentes departamentos o ubicaciones geogrficas. Ejemplo: Comprador = *alias de cliente* Nota: es importante hacer saber que la definicin de Comprador no muestra en el diccionario de datos su composicin, ya que todos estos detalles deben darse slo para el nombre primario que es cliente, y de esta manera minimizamos la redundancia en el modelo. Es importante reducir el uso de alias hasta donde sea posible ya que el usuario suele ver primero los DFDs y pudiera no ser tan obvio que comprador y cliente sean alias.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Modelado De Sistemas Con Uml UML es el lenguaje de modelado estndar para crear planos de software, que permite: Visualizar la solucin y facilitar la comunicacin. Especificar modelos precisos, completos y sin ambigedad. Construir cdigo base mediante herramientas en varios lenguajes de programacin. Documentar arquitectura, requerimientos, pruebas, procesos de negocio, pginas web.

Diagramas del UML Un modelo es una descripcin completa de un sistema desde una perspectiva particular. Un modelado de sistemas con UML, deber incluir los siguientes diagramas:

Diagramas de Clase Diagramas de Secuencia Diagramas de Casos de Uso Diagramas de Obje tos

Diagramas de Colaboracin Modelos

Diagramas de Componentes

Diagramas de Estado

Diagramas de Actividad

Diagramas de Distribucin

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Tipos de Diagrama Funcionalidad: Diagrama de Casos de Uso. Estructura esttica: Diagrama de Clases. Comportamiento dinmico: Diagramas de actividad. Diagramas de interaccin (secuencia y colaboracin). Diagramas de estado. Implementacin: Diagramas de componentes. Diagramas de distribucin. Casos de Uso Un Caso de Uso representa una secuencia de acciones que un sistema lleva a cabo para ofrecer algn resultado de valor para un Actor. El modelo de Casos de Uso es una especificacin completa de todas las formas posibles de utilizar un sistema. Notacin:

Relacin Caso de Uso Actor Un Actor representa cualquier cosa que interacte con el sistema. Un Caso de Uso (Use Case) es una interaccin tpica entre un usuario (Actor) y un sistema.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Especificaciones: 1.- El diagrama de Casos de Uso deber mostrar la funcionalidad y el comportamiento del sistema hacia el cliente o el usuario final. 2.- Deber representar las funciones del sistema (Casos de Uso) y en su entorno (Actores). 3.- Deber emplearse en el anlisis de requerimientos, diseo y pruebas. 4.- Deber exponerse a los usuarios finales y expertos en el dominio del problema en las etapas previas del desarrollo y en la definicin de los requerimientos. 5.- El modelo de Casos de Uso deber emplearse para los siguientes objetivos: Identificar los actores que interactan con el sistema. Lo que debe hacer el sistema. En el diseo de las interfaces del sistema. Para verificar que estn contemplados todos los requerimientos. Reglas: 1.- El caso de uso debe ser una unidad coherente de funcionalidad. 2.- El caso de uso debe especificar la secuencia de acciones, incluyendo las variantes y los resultados posibles. 3.- El caso de uso debe representar un escenario tpico. 4.- El caso de uso debe ayudar a comprender los requerimientos esenciales. Para la elaboracin del diagrama de Casos de Uso se pueden recurrir a las siguientes fuentes de informacin: Conversacin con el cliente / usuario. Dominio del problema. Especificacin del sistema. Literatura relevante del dominio. Entrevistas con expertos. Conocimiento personal del dominio. Sistemas legados. Documentacin: Para la documentacin de los Casos de Uso se debern seguir las siguientes consideraciones: 1. Se debern considerar los siguientes elementos en la documentacin: Breve descripcin.- El propsito es explicar en pocas lneas el Caso. Pre-condiciones.- Requisitos necesarios para que el Caso de Uso se lleve a cabo. Flujo Principal.- Secuencia de acciones que se dan normalmente. Flujos Alternos.- Secuencias de acciones que detallan las alternativas del Caso. Flujos de excepcin.- Eventos extraordinarios del Caso. Post-condiciones.- Requisitos que deben cumplirse posteriormente. 2. Describir slo los eventos que pertenecen al caso de uso, y no lo que pasa en otros casos de uso. 3. Utilizar un lenguaje comprensible para el cliente. 4. Evitar terminologa vaga como por ejemplo, etc. e informacin. 5. Deber describir: Cmo y cundo inicia y termina el Caso de Uso.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 4 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Cuando interacta el Caso de Uso con los actores. Qu informacin se intercambia entre un Actor y el Caso de Uso. No describir los detalles de la interfaz de usuario, describir solo acciones.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagramas de Actividad Son tiles para la descripcin del comportamiento que tiene una gran cantidad de procesos paralelos. Permite modelar los procesos reales de una organizacin humana y modelar actividades de software. Permiten describir Casos de Uso. Notacin:

Actividad

Barra de sincronizacin

[Condicin de guarda] Decisin

Una actividad es una accin a realizar. La barra de sincronizacin permite iniciar acciones una vez que se han realizado actividades concurrentes. La decisin es un punto en el que se pueden seguir alternativas distintas de acuerdo al resultado de la actividad anterior. Las condiciones de guarda son los posibles resultados de una accin que servirn como condicin para la realizacin de otra. Existe una variante de este diagrama denominado swimlanes, el cual muestra adems de qu pasa, quin lo hace: Se indican con una lnea vertical que separa el diagrama en zonas. Cada zona representa una clase, persona o departamento en particular. Consideraciones: El diagrama deber ser empleado para representar los comportamientos en paralelo. Se deber utilizar en el anlisis de un Caso de Uso. El diagrama deber ayudar a la comprensin del flujo de trabajo a travs de numerosos Casos de Uso. El diagrama deber ser elaborado cuando se traten de aplicaciones multihilos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 8

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagramas de Clases y Objetos El diagrama de clases muestra las clases que hay en el sistema y las relaciones estticas (asociacin y agregacin) entre ellas. Se consideran la columna vertebral de los mtodos OO. Notacin:

Nombre

Estructura

Comportamiento

El diagrama de clase se comprende de tres secciones: 1. La primera seccin contiene el nombre de la clase. 2. La segunda seccin muestra la estructura (atributos). 3. La tercera seccin muestra el comportamiento (operaciones). La segunda y tercer seccin pueden suprimirse si no es necesario que sean visibles en el diagrama. Consideraciones: En el caso de utilizar estereotipos, estos deben estar basados en tipos o clases existentes. Cada clase puede tener como mximo un estereotipo. Los estereotipos se muestran en la parte donde se escribe el nombre de la clase entre << >>. Deben emplearse los estereotipos ms comunes.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

4 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Existen tres tipos de Clase: Clase Interfaz Se representa la interaccin entre el sistema y sus actores. Aqu se denota claramente la informacin que se recibe y/o presenta y las peticiones de (y hacia) los usuarios y los sistemas externos. Se emplea para modelar las partes del sistema que dependen de sus actores. Se representan abstracciones de ventanas, formularios, paneles, interfaces de comunicaciones, impresoras, sensores, terminales. Clase Entity Se emplea para modelar informacin y comportamiento asociado de larga vida (persistente). Se pueden utilizar para reflejar un fenmeno de la vida real. Los valores de sus atributos se proporcionan por un actor. Clase Control Se emplea para representar la coordinacin, secuencia, transacciones y control de otros objetos. Debe utilizarse para encapsular el control de un Caso de Uso. Tambin se puede emplear para representar las derivaciones, clculos completos y reglas del negocio. Paquetes Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Los elementos estructurales y los elementos de comportamiento pueden agruparse en paquetes. Se visualizan como carpetas.

Nombre del paquete

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagrama de Clases Relaciones Asociacin: Nombre, rol, multiplicidad. Agregacin (pertenencia): Relacin de tipo tiene-un. Generalizacin (herencia): Relacin de tipo es-un. Dependencia Todos los sistemas abarcan varias clases y objetos. Los objetos contribuyen al comportamiento del sistema colaborando con unos y otros. La colaboracin se realiza a travs de las relaciones. Hay dos importantes tipos de relaciones durante el anlisis: Asociacin Agregacin Asociacin: Una asociacin es una conexin semntica bi-direccional entre clases. Esto implica que hay una liga entre objetos en las clases asociadas. Las asociaciones se representan en diagramas de clase por una lnea que conecta las clases asociadas. La informacin puede fluir en cualquier direccin o en ambas direcciones a travs de la liga.

<<controller> maestro

Nombramiento

<<entity>> detalle

Concepto: Una asociacin es una relacin bi-direccional. Dada una instancia de maestro hay un objeto asociado detalle. Dada una instancia de detalle hay un objeto asociado maestro.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Navegacin: Para clarificar su significado, se debe nombrar una asociacin. El nombre se representa como una etiqueta que se pone a lo largo de la lnea de asociacin, a mitad de camino entre los iconos de clases. Un nombre de asociacin es usualmente un verbo o una frase con verbo. Definicin de Roles: Un rol denota el propsito o capacidad en la que una clase se asocia con otra. Los nombres de roles son tpicamente sustantivos o frases con sustantivo. Un nombre de rol se pone a lo largo de la lnea de asociacin cerca de la clase que modifica. Uno o ambos finales de una asociacin pueden tener nombres de roles. Multiciplidad para Asociaciones: Multiplicidad es el nmero de instancias de una clase relacionada a UNA instancia de la otra clase. Para cada asociacin, hay dos decisiones de multiplicidad que tomar: una por cada final de la asociacin. Cada final de una asociacin contiene una multiplicidad de indicadores. Indica el nmero de objetos que participan en la relacin.

Muchos Exactamente uno Cero o ms Uno o ms Cero o uno Rango especfico

* 1 0..* 1..* 0..1 2..4

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Significado de la Multiciplidad: La multiplicidad responde a dos preguntas: La asociacin es obligatoria u opcional? Cul es el nmero mnimo y mximo de instancias que pueden ligarse a una instancia? Agregacin: Agregacin es una forma especializada de asociacin en la que un todo se relaciona con su parte o sus partes. Agregacin es conocida como parte de o relacin que contiene. Una agregacin se representa como una asociacin con un diamante al lado de la clase denotando el agregado (todo). La multiplicidad se representa de la misma manera que otras asociaciones.

<<controller> maestro 1 1

<<entity>> detalle

Asociacin o Agregacin: Si dos objetos estn estrictamente limitados por una relacin completa: La relacin es una agregacin. Si dos objetos se consideran usualmente como independientes, y an as estn ligados: La relacin es una asociacin.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Calificadores Un calificador es un atributo o grupo de atributos cuyos valores particionan el conjunto de objetos relacionado a un objeto a travs de una asociacin.

departamento Id. empleado

profesor

Dado un objeto departamento y un valor para un id. empleado hay exactamente un objeto profesor

departamento ttulo

profesor

1.. *

.
Dado un objeto departamento y un valor para titulo hay un conjunto de objetos profesor

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Restricciones Una restriccin es la expresin de alguna condicin que se debe preservar: Una restriccin se muestra como una lnea punteada.

profesor

{Ordenado por id. empleado} 1..*

Es miembro de 1

departamento

1 {Subconjunto}

Es cabeza de

Generalizacin (Herencia):

Generalizacin

Consideraciones: La generalizacin permite conectar clases generales con otras ms especializadas. Se conocen como subclase/superclase o hijo/padre. Es una relacin de es-un-tipo-de. Una clase hija hereda las propiedades de sus clases padres, especialmente sus atributos y operaciones.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 5 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Dependencia

A
Consideraciones:

Las dependencias son relaciones de uso. Indican que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza. Se representa con una lnea discontinua dirigida hacia el elemento del cual se depende. Se utilizan generalmente en el contexto de las clases o entre paquetes. Relaciones de Paquetes

Interface Reglas del negocio

Elementos

Consideraciones: Los paquetes se relacionan unos a otros usando una relacin de dependencia. Si una clase en un paquete habla con una clase en otro paquete entonces se agrega una relacin de dependencia en el nivel de paquete.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 5 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Los diagramas de escenario y de clase se evalan para determinar relaciones de paquete.

Relaciones durante el Anlisis y el Diseo Durante el anlisis, se establecen conexiones (asociaciones y agregaciones) entre clases. Estas conexiones existen debido a la naturaleza de las clases, y no debido a una implementacin especfica. Hacer una estimacin inicial de multiplicidad para exponer hiptesis ocultas. Los diagramas de clase se actualizan para mostrar las relaciones agregadas. Durante el diseo: Se refinan y actualizan las estimaciones de multiplicidad. Se evalan y refinan las asociaciones y agregaciones. Se evalan y refinan las relaciones de paquetes. Se maduran los diagramas de clase. Diagramas de Interaccin (Secuencia y Colaboracin) Un diagrama de interaccin es una representacin grfica de interacciones entre objetos Hay dos tipos de diagramas de interaccin: Diagramas de secuencia. Diagramas de colaboracin. Cada uno provee un punto de vista diferente de la misma interaccin. Los diagramas de secuencia estn ordenados de acuerdo al tiempo. Los diagramas de colaboracin pueden incluir flujo de datos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 7

M ET ODOLOG A Diagramas de Secuencia

DE DESARROLLO DE SISTEMAS

Un diagrama de secuencia muestra interacciones de objetos ordenados en secuencia de tiempo. El diagrama muestra: Los objetos que participan en la interaccin. La secuencia de mensajes intercambiados. Un diagrama de secuencia contiene: Objetos con sus lneas de vida. Mensajes intercambiados entre objetos en orden secuencial. Enfoque de control (opcional).

Alumno:

forma de inscripcin
2: validar id

forma de horario

Cursos disponibles

1: introducir id

3: introducir semestre actual 4: crear horario nuevo desplegar 6: obtener cursos

Consideraciones: Los objetos se dibujan como rectngulos con nombres subrayados. Las lneas de vida se representan con lneas de guiones descendentes. La interaccin de objeto se indica con flechas horizontales que se dirigen desde la lnea vertical que representa al objeto cliente hasta la lnea que representa al objeto proveedor. Las flechas horizontales se etiquetan con mensaje. El tiempo de orden de mensajes se indica por posicin vertical, con el ms cercano en la parte superior. La numeracin es opcional ya que la orden se basa en posicin vertical. Para escenarios complejos, los diagramas de secuencia pueden mejorar mediante el uso de guiones. Un guin se escribe a la izquierda de un diagrama de secuencia con los pasos del guin alineados con las interacciones del objeto. Los guiones se pueden escribir en lenguaje natural o en pseudo-cdigo.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 8

M ET ODOLOG A Diagramas de Colaboracin

DE DESARROLLO DE SISTEMAS

Un diagrama de colaboracin es una forma alternativa de representar los mensajes intercambiados por un conjunto de objetos. El diagrama muestra interacciones de objeto organizadas alrededor de los objetos y sus ligas a cada uno. Un diagrama de colaboracin contiene: Objetos. Ligas entre objetos. Mensajes intercambiados entre objetos. Flujo de datos entre objetos, si hay alguno.

1: introducir id

2: validar id

3: introducir semestre actual forma de registro

4: crear nuevo horario Miguel : Alumno 5: desplegar

Clases disponibles 6: obtener cursos

forma horario

Consideraciones: Los objetos se dibujan como rectngulos con nombres subrayados. Una liga de interaccin en un diagrama de colaboracin se representa como una lnea que conecta iconos de objetos. Una liga indica que hay una ruta para comunicacin entre objetos conectados. Una liga de interaccin en un diagrama de colaboracin se puede anotar con: Una flecha apuntando del objeto cliente al objeto proveedor. El nombre del mensaje con una lista opcional de parmetros y/o un valor de dato de regreso. Un nmero de secuencia opcional que muestre el orden relativo en el cual se envan los mensajes.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

5 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagramas de Estado Un diagrama de transicin de estado se usa para mostrar la historia de vida de una clase dada, los eventos que causan una transicin de un estado a otro, y las acciones que resultan de un cambio de estado. El espacio de estado de una clase dada es la numeracin de todos los estados posibles de un objeto. El estado de un objeto es una de las condiciones posibles en las que puede existir un objeto Contiene todas las propiedades del objeto. Usualmente esttico. Ms los valores actuales de cada una de estas propiedades Usualmente dinmico. Notacin:

adicEstud

Inicializar Hacer: inicializar

Sin Asignacin Hacer: Asignar professor a

adicEstud/ numEstuds = 0

Abierto entrada: Registrar estudiante

cancelar cancelar registro cerrado [numestud < 3]


Cancelado Hacer: enviar aviso de cancelacin

[fecha = fin]

[numEstuds = 10 ]

Cancelar

Cerrado Hacer: Reporte curso lleno Registro Hacer: Generar lista de grupos

Consideraciones: Un estado se representa como un rectngulo redondeado. Los estados pueden distinguirse por los valores de ciertos atributos.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 6 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Los estados tambin pueden distinguirse por la existencia de ciertas ligas. Inicio y Fin: El estado inicial es el estado introducido cuando se crea un objeto: Un estado inicial es obligatorio. Solo un estado inicial es permitido. El estado inicial se representa como un crculo slido. Un estado final indica el final de vida de un objeto: Un estado final es opcional. Puede existir ms de un estado final. Un estado final se indica con un ojo. Eventos: Un evento es la ocurrencia de alguna situacin que sucede en un punto del tiempo: El estado del objeto determina la respuesta a diferentes eventos. Transiciones: Una transicin es un cambio de un estado original a un estado sucesor como resultado de algunos estmulos. Condiciones de Guarda: Una condicin de guarda es una expresin booleana de valores de atributos que permiten una transicin solo si la condicin es verdadera. Acciones: Una accin es una operacin que se asocia a una transicin: Toma una cantidad insignificante de tiempo para completarse. Se considera no-interruptible. Actividades: Una actividad es una operacin que toma tiempo para completarse. Las actividades se asocian con un estado. Una actividad: Inicia cuando se introduce el estado. Puede ejecutarse hasta el fin o puede ser interrumpida por una transicin que sale.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagramas de Componentes Un componente es una unidad de cdigo fuente que sirve como bloque constructor para la estructura fsica de un sistema. Un componente pertenece al mundo material de los bits. Los estereotipos (con iconos alternos) pueden usarse para definir tipos de componentes especficos. Ejemplos: Ejecutables EXE, bibliotecas DLL, programas principales, encabezados, mdulos, formas, tablas, archivos y documentos. Agrupar clases en un componente que ya sea que tenga una funcin cooperativa o que necesite estar en proximidad para la eficiencia en la implementacin. Notacin: Nombre Del Componente

Inscripciones

Catlogos

Reportes

Consideraciones: Un diagrama de componente muestra la distribucin de clases y objetos en los componentes de implementacin as como sus dependencias de compilacin. Se requiere un nombre para cada componente, este nombre denota tpicamente el nombre simple del archivo fsico correspondiente en el espacio de trabajo actual. La nica relacin es la dependencia de compilacin, representada por una lnea punteada dirigida que apunte al modelo donde existe la dependencia. Por ejemplo: en C++, se indica una dependencia de compilacin por directivas #include. Puede que no haya ciclos en un conjunto de dependencias de compilacin. Los ejecutables y las libreras son representadas como componentes en UML: Especificacin de Paquete (DLL). Especificacin de tareas (EXE).

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagramas de Componentes - Paquetes


Nombre del paquete

Consideraciones: Un paquete en la vista de componente es una coleccin de componentes, algunos de los cuales son visibles a otros paquetes y otros estn ocultos. Un paquete agrupa componentes que estn lgicamente relacionados. Un paquete en la vista de componente agrupa componentes de manera similar a la que un paquete en la vista lgica agrupa clases. Cada componente en el sistema debe vivir en un solo paquete en el nivel mas alto del sistema. Diagramas de Distribucin Etiqueta

Nodo

Conexin

Consideraciones: Los nodos, al igual que los componentes, pertenecen al mundo material y modelan el aspecto fsico de un sistema. Los nodos modelan la topologa del hardware sobre el que se ejecuta el sistema. Los requerimientos como son rendimiento y desempeo son tomados en cuenta. Los diagramas de despliegue son creados para mostrar los diferentes nodos (procesadores y dispositivos) en el sistema. Elementos: Los elementos esenciales de un diagrama de despliegue son los nodos y sus conexiones. Un nodo es un objeto fsico en tiempo de ejecucin que representa recursos de cmputo. Una conexin indica comunicacin, usualmente la relacin directa entre hardware.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

D. DISEO El diseo es la evaluacin de las distintas soluciones alternativas y la especificacin de una solucin detallada de tipo informtico. Esta etapa trata principalmente las especificaciones tcnicas.

Etapas que debe considerar el diseo Preliminar.- se centra en la transformacin de los requisitos en los datos y arquitectura del software. Detallado.- se ocupa del refinamiento de la representacin arquitectnica que lleva a una estructura de datos detallada y a las representaciones algortmicas del software. Dentro del contexto de los diseos preliminar y detallado, se llevan a cabo varias actividades de diseo diferentes. Adems del diseo de datos, del diseo arquitectnico y del diseo de procedimientos, muchas aplicaciones requieren de un diseo de la interfaz del sistema hacia con el usuario. El diseo de la interfaz establece la disposicin y los mecanismos para la interaccin hombre mquina (no cubierto por las herramientas del diseo estructurado). Diseo estructurado Diseo de la interfaz de usuario

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 4

M ET ODOLOG A Diseo Estructurado Diseo Estructurado Con El Anlisis Orientado A Objetos

DE DESARROLLO DE SISTEMAS

Modularizacin del diseo

Objetos de datos Componente de Programa

Operaciones

Flechas de conexin

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

La modularizacin del diseo asigna clases y objetos a los componentes fsicos de programa (mdulos) y por lo tanto representa una visin de implementacin de la arquitectura del programa. Componente de programa (objeto) como una caja dividida en una parte de especificacin (visible en el exterior) y una parte privada (tambin denominada parte del cuerpo) que est oculta al exterior, en esta etapa todava no se especifican los detalles de implementacin de la parte privada o cuerpo del paquete. Los objetos de datos se representan con un valo alargado, Las operaciones que actan sobre ellos se representan mediante rectngulos. Las flechas de conexin que implican dependencia, es decir, el paquete o componente en el origen de la flecha depende del paquete o componente de programa en la punta de la flecha.

Paso de parmetros

Clase

Operacin

Excepciones

Datos de la Clase

El diagrama engloba elementos del diagrama de estructura, as como los principios de definicin de clases y herencia. Una clase definida es representada por el rectngulo grande. Las operaciones se representan por los cuadros que se solapan con el rectngulo. Paso de parmetros, se utiliza para mostrar los datos que entran y salen de las operaciones, son representados por pequeos crculos con flejas que emanan de ellos. Las flechas indican el acoplamiento entre los mdulos de la estructura del programa. Los rombos indican condiciones de excepcin que requieren un procesamiento de casos especiales.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Especificacin de la lgica de procesos Nos ayudan a describir lo que sucede en cada burbuja primitiva de nivel ms bajo en un DFD. Una especificacin de proceso define lo que debe hacerse para transformar entradas en salidas. Es una descripcin detallada de la poltica de negocios del usuario que cada burbuja lleva a cabo. (i) Caractersticas: Las especificaciones representan las burbujas de bajo nivel del diagrama de flujo de datos (DFD). Deben ser tan claras que el usuario pueda entender fcilmente lo que describen. (ii) Herramientas para hacer especificaciones de proceso:

Existen varias herramientas para realizar especificaciones de proceso algunas de estas herramientas son: Diagramas de flujo. Tablas de decisin. Lenguaje estructurado (pseudocdigo, espaol, ingls, etc.). Diagramas Nassi/Shneiderman. Diagrama de estructura. Diagrama de transicin de estados (DTE). (iii) Consideraciones al realizar las especificaciones de procesos: La especificacin del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista. Evitar el lenguaje narrativo, pues es ambiguo para expresar acciones alternativas (decisiones), acciones repetitivas (ciclos) y condiciones booleanas compuestas (YAND, O-OR, NO-NOT). El proceso debe especificarse en una forma que pueda ser comunicada efectivamente a todos los usuarios que estn involucrados.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(1) DIAGRAMA

DE FLUJO

Un diagrama de flujo permite representar grficamente la lgica de procedimiento de un programa de computadora y describe de manera precisa la poltica del usuario (reglas del negocio). (a) Consideraciones para elaborar un diagrama de flujo: Un diagrama de flujo debe usarse slo para describir lgica detallada. En la elaboracin de un diagrama, deben solo utilizarse los smbolos para diagramas de flujo equivalentes a las construcciones en espaol estructurado (pseudocdigo). Para crear un diagrama de flujo estructurado, la lgica debe estar organizada de tal manera que este acorde con las combinaciones anidadas de los smbolos de diagrama de flujo que se muestran. (b) Notacin para el diagrama de flujo:

Proceso

Decisin

Datos

Documento

Conector de pgina

Entrada por teclado

Imprimir en pantalla

Iteracin

Terminador

Conector

Flujo

(c) Los componentes elementales de un diagrama de flujo son: Proceso: Cuadro que representa una instruccin ejecutable o una secuencia contigua de instrucciones de la computadora. Este smbolo representa la inicializacin de variables, actividades de entrad y salida y las llamadas para ejecutar otros procedimientos. Decisin: Rombo que representa una decisin; en el caso sencillo, representa una decisin binaria. Representa condiciones alternativas que pueden ocurrir y que el programa debe manejar. Son equivalentes a las estructuras IF-THEN-ELSE (SIENTONCES-OTRO) utilizadas en el espaol estructurado.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 6 8

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Flujo: Son las flechas que conectan los cuadros y representan el flujo de control. Slo puede haber una flecha que fluya hacia fuera de un rectngulo; es decir cuando la ejecucin de una instruccin de computadora concluye, se puede proceder a alguna instruccin o decisin siguiente nica. De manera similar, puede haber slo dos flechas que emanen de una decisin. Iteracin: El smbolo de iteracin representa los ciclos y repeticin de operaciones mientas exista una condicin dada o hasta que haya una condicin. Terminador: valo que muestra el inicio o fin del flujo.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

6 9

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(2) TABLAS

DE DECISIN

Constituyen una notacin que traduce las acciones y las condiciones a una forma tabular, siendo difcil que la tabla se interprete mal e incluso puede usarse como entrada interpretable por la mquina para un algoritmo manejado por tabla. (a) Notacin para la tabla de decisin:

Nmero de reglas Filas de condiciones

Filas de accin

Reglas (b) Consideraciones para elaborar una tabla de decisin: Listar todas las acciones que pueden asociarse con un mdulo. Listar todas las condiciones (o decisiones hechas) durante la ejecucin del procedimiento. Asociar conjuntos especficos de condiciones con acciones especficas, eliminando las combinaciones de condiciones imposibles; alternativamente, desarrollar cada posible permutacin de condiciones. Definir reglas indicando qu acciones ocurren para un conjunto de condiciones.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(3) LENGUAJE

ESTRUCTURADO

(PSEUDOCDIGO)

El lenguaje estructurado es lenguaje en espaol con estructura, tambin conocido como pseudocdigo. Es un subconjunto de todo el idioma con importantes restricciones sobre el tipo de frase que pueden utilizarse y la manera en que pueden juntarse dichas frases. Su propsito es hacer un balance razonable entre la precisin del lenguaje formal de programacin y la informalidad y legibilidad del lenguaje cotidiano. (a) Caractersticas: Una sintaxis fija de palabras clave que permitan construir todas las construcciones estructuradas. Una frase en lenguaje estructurado puede consistir en una ecuacin algebraica. Esta frase no contiene el punto y coma que termina una instruccin en muchos lenguajes de programacin. Una sintaxis libre en lenguaje natural para describir las caractersticas del procesamiento. Facilidades para la declaracin de datos, incluyendo estructuras de datos sencillas y complejas. Un mecanismo de definicin de subprogramas y de invocacin, soportando los distintos modos de descripcin de interfaces. Puede o no terminar con un punto (.) dependiendo de la preferencia del diseador. Las frases que describen los clculos pueden usarse con prefijos de los verbos en infinitivo. Los verbos deben escogerse de entre un pequeo grupo de verbos orientados a la accin tales como: CONSEGUIR(o ACEPTAR o LEER) ENCONTRAR(o BUSCAR o LOCALIZAR) RESTAR DIVIDIR BORRAR VALIDAR REEMPLAZAR ORDENAR PONER(o MOSTRAR o ESCRIBIR) AGREGAR(o AADIR o SUMAR) MULTIPLICAR CALCULAR ENCONTRAR MOVER FIJAR

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(b) Estructuras utilizadas en un Pseudocdigo: La construccin SI-ENTONCES-OTRO se utiliza para describir frases alternativas que se deben realizar segn el resultado de la decisin binaria. La construccin SI-ENTONCESOTRO puede tomar cualquiera de las formas siguientes: Forma 1: SI condicin-1 frase-1 FIN SI Forma 2: SI condicin-1 frase-1 OTRO frase-2 FIN SI La construccin CASO se utiliza para describir frases alternativas que se efectuarn basndose en el resultado de una decisin multivaluada (en contraste con la decisin binaria que tiene lugar con la construccin SI-ENTONCES). La construccin CASO toma la forma general: Ejemplo: HACER CASO CASO variable = valor-1 frase-1 Ejemplo: SI el cliente vive en Hidalgo aadir cliente a PROSPECTOS-DEMERCADO FIN SI Ejemplo: Si edad-del-cliente es mayor que 65 fijar cuota a cuota-ancianos OTRO fijar cuota a cuota-normal FIN SI

. . .

CASO variable = valor-n frase-n

OTRO
frase-n+1 FIN CASO

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

La construccin HACER-MIENTRAS se usa para describir una frase que deber llevarse a cabo repetitivamente hasta que alguna condicin booleana se haga verdadera. Tiene la siguiente estructura: Ejemplo: HACER-MIENTRAS condicin-1 frase-1 FIN HACER

La construccin REPITE-HASTA es usada para ejecutar una frase especfica por lo menos una vez antes de hacer una prueba para ver si debe repetirse. Es una variante de la construccin HACER-MIENTRAS y tiene la siguiente estructura: Ejemplo: REPITE frase-1 HASTA condicin-1

Combinacin de estructuras.- Se pueden construir frases compuestas a partir de combinaciones de frases sencillas y las estructuras sencillas que se presentaron anteriormente. (c) Reglas para evitar complejidad en el lenguaje estructurado: Restringir la especificacin de proceso en lenguaje estructurado a una sola pgina de texto. Si la especificacin ocupa ms de una pgina, entonces el analista (con la ayuda del usuario) debe pensar en una forma totalmente distinta de formular la poltica. Si no se puede, entonces es posible que el proceso mismo sea demasiado complejo, y debe partirse en una red de procesos ms simples de nivel inferior. No se deben utilizar ms de tres niveles de anidamiento (es decir, tres niveles de estructuras anidadas SI-ENTONCES-OTRO o tres niveles de estructuras CASO, etc.). Para evitar confusiones acerca de los niveles de anidamiento, debe utilizar sangras. Esto se puede lograr y controlar si est utilizando algn procesador de texto o alguna herramienta para el desarrollo de especificaciones de proceso.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(4) DIAGRAMA NASSI/SHNEIDERMAN


Es una representacin para el diseo de procedimientos que no permite la violacin de las construcciones estructuradas, siendo la caja el elemento fundamental de este diagrama. (a) Caractersticas: El mbito funcional (mbito de una repeticin o de un if-then-else). La transferencia arbitraria de control es imposible. Se puede determinar fcilmente el mbito de los datos locales y/o globales. La recursividad es fcil de representar. (b) Notacin:

Primera tarea

Condicin

Siguiente tarea

Parte else

Parte then

Tarea siguiente + 1

Secuencia
Condicin del bucle Parte repeat-until

If- then - else


Caso de condicin Valor Valor Parte del caso ...

Parte do-while

Parte del caso

...

Condicin del bucle

Repeticin

Seleccin

(c) Consideraciones para elaborar un diagrama de Nassi/Shneiderman:


Una salida del bucle slo se puede implementar mediante un estricto seguimiento de las construcciones estructuradas, de hecho no existe ningn mecanismo que permita violar las construcciones.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 4

M ET ODOLOG A (5) DIAGRAMA


DE ESTRUCTURA

DE DESARROLLO DE SISTEMAS

(a) Caractersticas: A travs de los diagramas de estructura se puede modelar el control del sistema, as como la descomposicin de las funciones en forma jerrquica. Un diagrama de estructura muestra la jerarqua funcional y las interfaces de datos entre los componentes. Es el modelo ms comn de organizacin de la actividad en una sola unidad sincronizada, pues muestra la organizacin jerrquica de mdulos dentro de una tarea. (b) Elementos del diagrama de estructura:

Llamada a un mdulo Mdulo

Parmetros de salida Parmetros de entrada

Mdulo.- En un diagrama de estructura, los mdulos son representados por rectngulos. Los mdulos del diagrama de estructura son los mismos que los que aparecen en los distintos niveles del DFD, vistos en otra dimensin. Aunque el mdulo padre de un diagrama de estructura o mdulo raz puede tener dos nodos hijos en su segundo nivel de descomposicin, se recomienda descomponer este mdulo en 3 hijos, cada uno de ellos dar origen a una rama en el diagrama de estructura, es decir, cada uno de ellos a su vez podr tener otros mdulos hijos. Estas ramas son:

a) Rama aferente: Su objetivo es capturar u obtener la informacin proveniente


generalmente del usuario.

b) Rama de proceso: Transforma la informacin capturada, es decir las entradas, en las c)


salidas del sistema. Rama eferente: Su objetivo es entregar las salidas del sistema al usuario o al terminador que corresponda.

Llamada a un mdulo.- Se representa mediante una flecha descendente, la cual indica la dependencia (jerrquica) entre mdulos, las instancias de repeticin y decisin as como el flujo de los datos de control. Parmetros de entrada.- Se representan mediante una flecha descendente (ms pequea que la flecha de llamada al mdulo) e indican los datos de entrada que recibe un nodo hijo de su nodo padre. Parmetros de salida.- Se representan mediante una flecha ascendente (ms pequea que la flecha de llamada al mdulo) e indican los datos de salida que enva un nodo hijo a su nodo padre.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 7 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(c) Ejemplo:

Parmetros de entrada que se pasan al mdulo que se llama

Mdulo que llama Nodo padre A

Datos de entrada: X, Y

Datos de salida: P,Q

Llamada a un mdulo

Nodo hijo B Parmetros de entrada que se pasan al mdulo que se llama

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(6) DIAGRAMA

DE TRANSICIN DE ESTADOS

(DTE)

Son una herramienta poderosa de modelado para describir el comportamiento requerido de los sistemas. Su objetivo es mostrar las modificaciones que sufre una entrada a travs del tiempo debido a la ocurrencia de eventos. Un DTE puede ser usado de manera ms general para mostrar de manera detallada el comportamiento de un sistema indicando cules son los estados por los que pasa cada uno de sus procesos. (a) Componentes:

Condicin Accin Estado Transicin o cambio de estado

Estado.- Cada rectngulo representa un estado o un modo de comportamiento en el que se puede encontrar el sistema. Un estado es un conjunto de circunstancias o atributos que caracterizan a una persona o cosa en un tiempo determinado. Es una forma de ser o una condicin. Un estado representa algn comportamiento del sistema que es observable y que perdura durante algn periodo finito. Los estados tpicos de un sistema pueden ser: Esperar a que el usuario de su contrasea. Calentar una mezcla de sustancias qumicas. Esperar la siguiente orden. Acelerar el motor. Mezclar los ingredientes. Esperar los datos del instrumento. Llenar el tanque. Aguardar en reposo.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

(b) Ejemplo:

En reposo

Esperando llamada

una

Grabando mensaje

Dando el mensaje

Respondiendo a la llamada Transicin.- Es el cambio de estado que sufre un sistema. Existen reglas que gobiernan el comportamiento del sistema y los cambios se realizan mediante ciertos eventos o cambios de estado significativos y vlidos. Existen dos tipos de transicin:

Transicin inicial: Es el cambio que genera el primer estado de una entidad. Transicin final: Es el ultimo estado que puede tener un sistema antes de que se termine.

Condicin o evento.- Causan un cambio de estado. Es una accin que da lugar a una transicin. Una condicin es un acontecimiento en el ambiente externo que el sistema es capaz de detectar. Una condicin hace que un sistema cambie de un estado de espera X a un estado de espera Y, o bien de llevar a cabo la actividad X a llevar a cabo la actividad Y. Puede ser:

Una seal. Una interrupcin. La llegada de un paquete de datos.

Accin: Es la accin que el sistema toma cuando cambia de estado. Como parte del cambio de estado. Las acciones que se muestran en un DTE son respuestas regresadas al ambiente externo o bien clculos cuyos resultados el sistema recuerda (en un almacn de datos que se muestra en el DFD) para poder responder a algn acontecimiento futuro, normalmente el sistema har una o ms acciones, como: Producir una salida. Desplegar una seal en la computadora del usuario. Realizar un clculo. Crear informacin. Modificar informacin.
7 8

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A Borrar informacin.

DE DESARROLLO DE SISTEMAS

(c) Pasos para la construccin de un DTE: Para la construccin de los DTE se puede seguir cualquiera de los siguientes enfoques: Primer enfoque: 1. Identificar todos los posibles estados del sistema. 2. Representar cada uno de los estados encontrados como una caja separada en una hoja de papel. 3. Explorar todas las conexiones con significado (es decir, los cambios de estado) entre las cajas. Segundo enfoque: 1. Buscar el estado inicial. 2. Seguir un camino metdico hasta el o los estados restantes. 3. Luego de los estados secundarios, proseguir a los terciarios, etc.

(d) Reglas de consistencia para la construccin de DTEs:


Deben contestarse las siguientes preguntas para verificar la consistencia de los DTEs: Se han definido todos los estados? Observar cuidadosamente el sistema para detectar si existe algn otro comportamiento observable, o alguna otra condicin en la que el sistema pudiera estar, aparte de las que se han identificado. Se pueden alcanzar todos los estados? Se han definido estados que no tengan caminos que lleven a estos? Se puede salir de todos los estados? El sistema puede tener uno o ms estados finales con mltiples entradas a ellos; pero todos los dems estados deben tener un sucesor. El sistema responde adecuadamente a todas las condiciones posibles en cada estado? Cuando el analista identifica los cambios de estado ocurren condiciones normales, pero no especfica el comportamiento del sistema ante condiciones inesperadas. Si no se especifica el comportamiento del sistema, existen muchas posibilidades de que los diseadores y programadores no lo programen tampoco, y el sistema tendr un comportamiento impredecible bajo una variedad de circunstancias.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

7 9

M ET ODOLOG A Diseo de la Interfaz de Usuario Modelos de diseo de interfaces

DE DESARROLLO DE SISTEMAS

Cuando se va a disear una interfaz deben tomarse en cuenta cuatro modelos diferentes:

Modelo de diseo: incorpora datos, representaciones de los datos, procedimientos y

estructuras del software. La especificacin de requisitos puede establecer ciertas restricciones que ayudan a definir al usuario del sistema, pero el diseo de la interfaz suele tener escasa importancia en comparacin con el modelo de diseo, sin embargo al tratarse de sistemas interactivos, el diseo de la interfaz es tan importante como el diseo de datos, de los procedimientos o de la arquitectura.

Modelo de usuario.- Representa el perfil de los usuarios finales del sistema, para la

construccin de una interfaz efectiva, cualquier diseo debera comenzar con conocimiento de los posibles usuarios, incluyendo perfiles sobre su edad, sexo, estado fsico, educacin, procedencia cultural o tnica, motivacin, objetivos y personalidad, los usuarios pueden ser clasificados como:

Novatos: sin conocimiento de los mecanismos de interaccin requeridos para utilizar la interfaz eficientemente (sintctico), poca comprensin de las funciones que se realizan, el significado de las entradas, salidas, metas y objetivos del sistema (semntico). Intermitentes (con capacidad de aprender): conocimiento semntico razonable sobre la aplicacin pero poca memorizacin de la informacin sintctica necesaria para utilizar la interfaz. Frecuentes (con capacidad de aprender): buen conocimiento sintctico y semntico que a menudo conduce al sndrome de usuario-poder, esto es, individuos que buscan trucos y formas abreviadas de interaccin.

Percepcin del Sistema (el modelo del usuario): es la imagen mental del sistema que
se forma el usuario final, un usuario que conozca en profundidad los procesadores de texto, pero que solo haya trabajado con un procesador concreto una vez, podra proporcionar una descripcin ms completa de su funcionamiento que el novato que est aprendiendo a aprender su manejo.

Imagen del Sistema: combina la manifestacin externa del sistema basado en

computadora (el aspecto y el sentir de la interfaz), con toda la informacin de soporte (libros, manuales, cintas de video) que describen la sintaxis y la semntica del sistema. Cuando coinciden la imagen y la percepcin del sistema los usuarios se sienten, generalmente, ms cmodos con el software y lo utilizan ms efectivamente, esta fusin de los modelos se lleva acabo mientras el modelo de diseo se haya desarrollado teniendo en cuenta la informacin contenida en el modelo de usuario, la imagen del sistema debe reflejar con precisin la informacin sintctica y semntica de la interfaz.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Anlisis y modelado de tareas Un enfoque alternativo para el anlisis de tareas es el orientado a los objetos, se observan los objetos fsicos utilizados por el diseador y las acciones que se aplican a cada objeto. El modelo de diseo de la interfaz definir tareas de usuario para realizar el resultado final. Una vez que cada tarea o accin se ha definido, comienza el diseo de la interfaz. Los primeros pasos en el proceso de diseo de la interfaz pueden realizarse siguiendo el siguiente enfoque: 1. Establecer los objetivos e intenciones de cada tarea. 2. Asignar a cada objetivo / intencin una secuencia de acciones especficas. 3. Especificar la secuencia de acciones tal y como se ejecutarn en el nivel de interfaz. 4. Indicar el estado del sistema, es decir, qu aspecto tiene la interfaz en el momento en que se ejecuta una accin de la secuencia? 5. Definir los mecanismos de control, es decir, los dispositivos y acciones accesibles al usuario para modificar el estado del sistema. 6. Indicar cmo afectan los mecanismos de control al estado del sistema. 7. Indicar cmo interpreta el usuario al estado del sistema a partir de la informacin suministrada a travs de la interfaz. Aspectos de diseo Segn evoluciona el diseo de una interfaz de usuario aparecen cuatro aspectos de diseo comunes: Tiempo de respuesta del sistema: es el punto ms crtico de muchos sistemas interactivos (particularmente en aplicaciones de tiempo-compartido que hacen uso de una computadora central). En general, el tiempo de respuesta del sistema se mide desde que el usuario realiza una accin de control hasta que el programa responde con la accin o salida deseada. El tiempo de respuesta tiene dos caractersticas importantes, el retardo de la respuesta el cual si es demasiado grande, los resultados son, inevitablemente, la frustracin y el estrs del usuario, un retardo pequeo puede ser perjudicial cuando el usuario es conducido por la interfaz, una respuesta rpida puede forzar al usuario a ir muy deprisa y cometer errores; la variabilidad que se refiere a la desviacin del tiempo de respuesta medio y supone la caractersticas ms importante de todas las relacionadas con el tiempo de respuesta, una baja variabilidad permite establecer un ritmo propio de interaccin, an cuando el retardo sea alto. Facilidades de ayuda al usuario: casi todos los usuarios de un sistema interactivo requieren ayuda de vez en cuando, normalmente se encuentran dos tipos de facilidades de ayuda: Integrada: diseada en el software desde el principio, a menudo es sensible al contexto, permitiendo al usuario seleccionar aquellos temas relacionado con las acciones que est ejecutando en ese momento incrementando la amigabilidad de la interfaz.

Aadida: es aquella que se incorpora al sistema despus de haber sido construido, en muchos casos es un manual de usuario interactivo con un conjunto limitado de tipos de preguntas, en general, la ayuda integrada es preferible a la aadida. Manejo de la informacin de error: los mensajes de error y avisos constituyen malas noticias para los usuarios de sistemas interactivos que indican que algo ha ido mal, en el peor de los casos, los mensajes de error y avisos suministran informacin confusa o sin ninguna utilidad, el mensaje de error no suministra una indicacin real de qu es lo
8 1

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

que ha ido mal o dnde mirar para encontrar informacin adicional, en general todos los mensajes de error deben tener las siguientes caractersticas:
El mensaje debe describir el problema en un lenguaje que comprenda el usuario. Debe proporcionar una informacin constructiva para poder solventar el problema. Debe indicar las consecuencias negativas del error, de tal forma que el usuario pueda comprobar que no han ocurrido o corregirlas si lo han hecho. Debe ir acompaado de una clave visual o audible, puede generarse un pitido acompaando la visualizacin de un mensaje, o bien ste puede parpadear momentneamente y ser visualizado en un color fcilmente reconocible como color de error. El mensaje no debe aportar un juicio sobre o ocurrido, es decir no debe culpar al usuario.

Una filosofa efectiva de mensajes de error puede hacer mucho para mejorar la calidad de un sistema interactivo.

Asignacin de nombres a las rdenes: es uno de los modos ms usados de interaccin

entre el usuario y el sistema, hoy en da la utilizacin de interfaces orientadas a ventanas con utilizacin de dispositivos de sealizacin y eleccin ha reducido la dependencia del teclado, sin embargo an muchos usuarios prefieren un modo de interaccin orientado a rdenes as el usuario puede disponer de opciones que pueden ser seleccionadas de un men desplegable o esttico, o invocadas a travs de una secuencia de rdenes por teclado.

Es importante tomar en cuenta estos aspectos para evitar problemas antes de construir el prototipo operativo, de lo contrario dar lugar a revisiones innecesarias, retrasos del proyecto y frustracin del cliente, es mucho mejor definir estos puntos como aspectos del diseo y considerarlos desde el comienzo del mismo, cuando todava no es difcil hacer cambios y los costos son bajos.

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Evaluacin del diseo Una vez creada la versin operativa de la interfaz, sta debe ser evaluada para determinar si satisface las necesidades del usuario. Ciclo de evaluacin de la interfaz Despus de completar un diseo preliminar, se crea un prototipo de primer nivel, el cual es evaluado por el usuario el cual proporciona al diseador comentarios directos acerca de la eficiencia de la interfaz, adems si se utilizan tcnicas de evaluacin formales (cuestionarios, hojas de evaluacin), el diseador puede extraer informacin de esos cuestionarios. Las modificaciones del diseo son realizadas en base a la informacin del usuario, tras lo que se desarrolla el siguiente prototipo, el ciclo de evaluacin contina hasta que no sea necesario hacer ms modificaciones sobre el diseo de la interfaz. Si pueden descubrirse y corregirse problemas potenciales a tiempo, se conseguir el nmero de veces que habr que recorrer el ciclo de evaluacin y el tiempo de desarrollo del prototipo.

Diseo preliminar

Construccin del prototipo I de interfaz

Evaluacin de la interfaz por parte del usuario

Construccin del prototipo n de interfaz

Modificaciones del diseo

Estudio por el diseador de la evaluacin

Diseo de la interfaz completo

Pueden aplicarse en las primeras revisiones los siguientes criterios: 1. La longitud y complejidad de la especificacin escrita del sistema y de su interfaz proporciona una indicacin de la cantidad de aprendizaje requerido por los usuarios. 2. El nmero de rdenes especificado y el nmero medio de argumentos por orden, proporcionan una indicacin del tiempo de interaccin y de la eficiencia global del sistema. 3. El nmero de acciones, rdenes y estados del sistema, indican la carga de memorizacin de los usuarios del sistema. 4. El estilo de la interfaz, las facilidades de ayuda y el protocolo de manejo de errores proporcionan una indicacin general de la complejidad de la interfaz y del grado de aceptacin por parte de los usuarios.
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 8 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Una vez construido el primer prototipo, el diseador puede recoger una gran variedad de datos cuantitativos y cualitativos que le ayudan en la evaluacin de la interfaz. Para obtener datos cuantitativos, se puede utilizar un tipo de anlisis basado en la observacin del usuario durante un cierto tempo, y si se desean obtener datos cualitativos se pueden distribuir cuestionarios entre los usuarios del prototipo. Directrices para el diseo de interfaces Se sugieren tres directrices para el diseo de interfaces: Interaccin General: sobrepasan a menudo las fronteras que la separan de la visualizacin de informacin, la entrada de datos y el control global del sistema, son complementarias. Las siguientes directrices se centran en la interaccin general: Ser consistente: formato consistente para la seleccin de mens, entrada de rdenes, visualizacin de datos y otras funciones que incorpora una interfaz. Ofrecer retroalimentacin significativa: debe proporcionarse al usuario una realimentacin visual y auditiva para asegurar que se establece una comunicacin bidireccional entre el usuario y la interfaz. Preguntar por la verificacin de cualquier accin destructiva no trivial: si el usuario pide eliminar cierta informacin o desea concluir la ejecucin de un programa debe aparecer un mensaje del tipo Est seguro...? Permitir una vuelta atrs fcil en la ejecucin de la mayora de las acciones: las funciones deshacer o invertir deben estar disponibles en todas las aplicaciones interactivas. Reducir la cantidad de informacin que debe ser memorizada entre acciones: la carga de memorizacin debe ser minimizada. Buscar la eficiencia en el dilogo, el movimiento y el pensamiento: las pulsaciones del ratn deben ser minimizadas. Perdonar los errores: el sistema deber protegerse de los errores del usuario que pudiesen afectarle causndole un fallo. Categorizar las actividades en base a su funcin y organizar la geografa de la pantalla convenientemente: se debe hacer hincapi en la ubicacin coherente de rdenes y acciones. Proporcionar facilidades de ayuda sensibles al contexto. Utilizar verbos de accin simples o frases verbales para nombrar las rdenes.

Visualizacin de la informacin: puede ser presentada como texto, dibujos y sonidos, por posicin, movimiento y tamao, utilizando colores, resolucin e incluso por omisin. Las siguientes directrices se centran en la visualizacin de la informacin: Mostrar solo aquella informacin que sea relevante en el contexto actual. No abrumar al usuario con datos. Utilizar etiquetas consistentes, abreviaciones estndar y colores predecibles. Permitir al usuario mantener el contexto visual. Producir mensajes de error significativos.
8 4

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Utilizar maysculas y minsculas, tabulaciones y agrupaciones de texto para ayudar a la comprensin. Utilizar ventanas (si estn disponibles) para modularizar los diferentes tipos de informacin. Utilizar representaciones analgicas para mostrar la informacin que es ms fcil de asimilar bajo este tipo de representacin. Considerar la geografa disponible en la pantalla y utilizarla eficientemente.

Entrada de datos: el teclado sigue siendo el manejo de entrada de datos ms importante, sin embargo el ratn, los digitalizadores e incluso los sistemas de reconocimiento de voz ya son alternativas eficientes. Las siguientes directrices se centran en la entrada de datos: Minimizar el nmero de acciones de entrada de datos que debe realizar el usuario. Mantener la consistencia entre la informacin visualizada y los datos de entrada. Permitir al usuario personalizar la entrada de datos. La interaccin tambin debe ser flexible y estar ajustada al modelo de entrada preferido por el usuario. Desactivar rdenes que sean inapropiadas en el contexto actual. Permitir al usuario controlar el flujo interactivo. Proporcionar ayuda en todas las acciones de entrada de datos. Eliminar las entradas innecesarias.

En la etapa del diseo se elaboran las especificaciones para la construccin de la solucin y esta debe de documentarse en: Documento final del diseo: Funcionalidad por capas Flujo de procesos Especificaciones de las tablas de las bases de datos Proceso de migracin del procedimiento actual al nuevo Presentaciones (reportes pginas, pantallas, etc.)

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 5

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

E. DESARROLLO O CONSTRUCCIN En esta etapa con base a los documentos del diseo se construye de acuerdo a las especificaciones dadas y a los estndares de construccin. El producto final es: El conjunto de instrucciones en cdigo fuente probadas. El conjunto de manuales solicitados en la normatividad Manual de Capacitacin del usuario final F. PRUEBAS En esta etapa se elaboran: Los Las Las Las guiones de prueba pruebas del cdigo individual por programa pruebas en conjunto pruebas de funcionalidad,

Documento final: Expediente tcnico Manual de usuario Manual de instalacin Memoria tcnica Guiones de prueba Visto bueno del usuario Visto bueno del personal o funcin que va a operar el sistema Evidencias de las pruebas G. IMPLANTACIN Capacitacin Instalacin de la infraestructura necesaria Instalacin del cdigo Instalacin de los procedimientos Prueba piloto Conversin y / o carga de datos iniciales Carga de catlogos y parmetros del sistema Documento final: Aceptacin del fin de proyecto Encuesta final

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 6

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

IV.

MODELOS DE PROCESAMIENTO

Los modelos de procesamiento son un conjunto de tcnicas y reglas de organizacin lgica y fsica que permiten moverse de un concepto a un diseo y a una implantacin. El propsito de identificar y documentar estos patrones es construir las habilidades necesarias para traducir un requerimiento de la funcin o de productividad a modelos que permitan la reusabilidad y homogeneizacin de los diversos componentes, as mismo facilitan la planeacin de soluciones y la obtencin de mtricas de costo y duracin de los proyectos Por cada modelo, pueden existir varios escenarios que describan ligeras variantes fsicas del modelo genrico. ARQUITECTURA MULTICAPAS Conceptos Modelos identificados Modelo de procesamiento entre la Secretaria de Salud y el exterior. Modelo de procesamiento de Informacin Gerencial y Estadsticas Modelo de procesamiento de apoyo a los procesos administrativos internos Modelo de procesamiento de apoyo a la productividad. Modelo de procesamiento de solicitudes

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 7

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Conceptos

MODELO LGICO MULTICAPAS Integracin De Funcionalidad Aplicativa

Presentacin Al Usuario

Apoyo A La Presentacin

Administracin De Datos

Datos

Presentacin al usuario Funcionalidad incluida Interfase con el usuario (entrada/salida) Funcionalidad excluida No provee acceso a datos No contiene datos No tiene lgica de aplicacin No tiene acceso directo al middleware No maneja contexto transaccional Invoca la capa Apoyo a la presentacin Apoyo a la presentacin Funcionalidad incluida Abstraccin de la capa de integracin de funcionalidad Aplicativa hacia la capa de presentacin de usuario Contiene validaciones sintcticas Contiene validaciones semnticas de la secuencia aplicativa Maneja la secuencia aplicativa Administra perifricos propios del dispositivo Funcionalidad excluida No contiene interfase con el usuario No maneja control transaccional Invoca la capa: Integracin de funcionalidad aplicativa Integracin de funcionalidad aplicativa Funcionalidad incluida Lgica de integracin de la aplicacin
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 8 8

M ET ODOLOG A Funcionalidad operativa del servicio Manejo del contexto y control transaccional Contiene validacin semntica de la integracin aplicativa Maneja la secuencia de integracin aplicativa Funcionalidad excluida No tiene acceso directo a datos Invoca la capa: Integracin de funcionalidad aplicativa Administracin de datos Administracin de datos

DE DESARROLLO DE SISTEMAS

Funcionalidad incluida Contiene el acceso a los datos, encapsulando el acceso a los mtodos del manejador de datos Contiene las reglas de validacin asociadas a datos Contiene validacin semntica asociada a datos Contiene ejecucin de acceso a datos Invoca la capa: Datos Datos Funcionalidad incluida Acceso a los datos de la aplicacin

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

8 9

M ET ODOLOG A Modelos identificados

DE DESARROLLO DE SISTEMAS

Modelo de procesamiento entre la Secretaria de Salud y el exterior. Define la forma en que se realiza el intercambio de informacin con el exterior. Es toda aquella funcionalidad aplicativa que implique interactuar con entidades que no sean la Secretaria de Salud. Otras secretarias Otros organismos del sector Ciudadanos Terceros (bancos) Modelo Lgico Presentacin de usuario No existe Apoyo a la presentacin Generacin del formato requerido transaccional o de archivo Integracin de funcionalidad aplicativa Lgica de armado de la informacin requerida Administracin de datos Secuencia de acceso a las bases de datos Datos

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

9 0

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Modelo de procesamiento de Informacin Gerencial y Estadsticas Define la forma en que se puede poblar un almacn general o local de datos, as como la forma en que se puede consultar y manipular su contenido. Es toda aquella funcionalidad aplicativa que genere informacin para la toma de decisiones. Acopio Validacin Integracin Almacenamiento Armado de modelos de presentacin Seguridad Consulta Modelo Lgico Presentacin de usuario Apoyo a la presentacin Aplicacin de las reglas de seguridad Integracin de funcionalidad aplicativa Integracin de la informacin solicitada de acuerdo al modelo de informacin Administracin de datos Datos

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

9 1

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Modelo de procesamiento de apoyo a los procesos administrativos internos Define la manera en que se tiene que procesar las aplicaciones que apoyen a los procesos de administracin interna y de apoyo a la funcin de la Secretara. Es toda aquella funcionalidad aplicativa que est vinculada directamente con los procesos de apoyo a la administracin interna y al apoyo a la funcin de la Secretara. Modelo Lgico Presentacin de usuario Apoyo a la presentacin Manejo de perifricos Control de navegacin Servicios de apoyo a la presentacin Validacin sintctica Validacin semntica Consulta a catlogos para presentacin Integracin de funcionalidad aplicativa Validaciones de seguridad Ordenador de operaciones Funcionalidad x Funcionalidad y Funcionalidad z Funcionalidad Administracin de datos Reglas asociadas a los datos Datos

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

9 2

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Modelo de procesamiento de apoyo a la productividad. Define la manera en que se tienen que procesar las aplicaciones departamentales de apoyo a la productividad. Modelo Lgico Presentacin de usuario Apoyo a la presentacin Integracin de funcionalidad aplicativa Administracin de datos Datos

Modelo de procesamiento de solicitudes Define la forma en que se procesan las solicitudes hechas por los ciudadanos, desde su recepcin hasta que se entregue la solucin a la solicitud, incluyendo el seguimiento a los diversos cambios de estado de la solicitud. Es toda aquella funcionalidad aplicativa que implique la atencin a una solicitud de un ciudadano, no requiere de atencin inmediata, implica una serie de pasos para atender una orden, involucra flujo de trabajo Modelo Lgico Presentacin de usuario Apoyo a la presentacin Integracin de funcionalidad aplicativa Administracin de datos Datos

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

9 3

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

V. DOCUMENTACIN DE UN SISTEMA
1. EXPEDIENTE GENERAL Cartula Objetivo Alcance Usuario responsable Responsable tcnico Mdulos que lo componen Diagrama de entidad-relacin Diagrama general con interrelaciones Descripcin general de los procesos en lote y en lnea. Infraestructura necesaria para operar 2. MANUALES A. PROCEDIMIENTOS Operacin de usuario final Implementacin del sistema Operacin y administracin del sistema Administracin de seguridad y control de acceso Registro y administracin de usuarios Control de bases de datos, archivos, procesos, respaldos y salidas impresas Continuidad de la funcin en casos de excepcin (Planes de Contingencia) Capacitacin de usuario final B. EXPEDIENTE TCNICO General del Sistema Cartula del Sistema Objetivo Alcance Mdulos que lo componen Diagrama entidad relacin (E-R) Diagrama general con interrelaciones (entradas-salidas-bases de datos) Descripcin de los procesos en lnea Descripcin de los procesos en lote Especificaciones de las bases de datos y archivos. Parmetros de control del sistema. Parmetros de control de procesos del sistema. Subsistema o Mdulo Cartula del subsistema o mdulo Objetivo del subsistema o modulo Alcance Funciones Diagrama de entidad-relacin (E-R)
DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN 9 4

M ET ODOLOG A

DE DESARROLLO DE SISTEMAS

Diagrama de flujo conteniendo programas indicando uso de archivos y / o tablas (por frecuencia de uso, diario, mensual, anual, eventual, etc.). Manejo de excepciones. Procedimientos y cifras de control. Guiones de pruebas. Evidencia de las pruebas efectuadas. Programa Cartula del programa Objetivo del programa Autor (nombre) Fecha de creacin y de ltima modificacin Frecuencia de uso Lenguaje de programacin Manejador de bases de datos Diagrama general con interrelaciones (entradas-salidas-bases de datos) Funciones que realiza el programa Diagrama de flujo Descripcin de los archivos y tablas utilizados Descripcin de las funciones que modifican los campos (donde aplique) Reportes que emite (con la descripcin de cada campo y su origen) Pantallas o presentaciones (ejemplos con la descripcin de cada campo y su origen) Manejo de excepciones Ayudas al usuario final en lnea Cifras de control Guiones de pruebas Evidencia de las pruebas efectuadas Componentes utilizados Cdigo fuente Componente Cartula del componente Objetivo del componente Autor (nombre) Fecha de creacin y de ltima modificacin Lenguaje de programacin Manejador de bases de datos Funciones que realiza el componente Diagrama de flujo Descripcin de los archivos utilizados Descripcin de las funciones que modifican los campos (donde aplique) Cdigo fuente Manejo de excepciones Guiones de pruebas Evidencia de las pruebas efectuadas

DIRECCIN GENERAL DE TECNOLOGA DE LA INFORMACIN

9 5