Modulo ii metodologías de sistemas

Elaborado por Prof. Virginia Juárez - II semestre 2010

1

Análisis y Diseño de Sistemas

II Semestre de 2010

Metodologías de Desarrollo de Sistemas de Información


2

2.1. Ingeniería de Software

Concepto.

Disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. (Ian Sommerville, Ingeniería de Software, 6ta edición, 2002)

Existen dos frases claves:


3

Ingeniería de SoftwareConcepto.

“disciplina de ingeniería” Los ingenieros hacen que las cosas funciones. Aplican teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y métodos aplicables para resolverlos.“todos los aspectos de producción de software” La

ingeniería de software no sólo comprende los procesos técnicos del desarrollo de software sino también las actividades, como la administración de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software.


4

• Enfoque sistemático del desarrollo, operación,mantenimiento y retiro del software.

• Rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo efectivas ( cost-effective - eficaces en costo, o económicas) a los problemas de desarrollo de software.

Ingeniería de Software


5

Una actividad de modelado – para manejar lacomplejidad se utilizan modelos que se enfocan en losdetalles relevantes.

Una actividad de solucionar problemas - se usanmodelos para buscar soluciones aceptables (búsquedapor experimentación).



6

Una actividad de adquisición de conocimientos – en elmodelado se recopila datos, se organizan eninformaciones y se formalizan en conocimiento.Una actividad dirigida por una fundamentación – esnecesario captar el contexto en el que se tomarondecisiones y las razones que hay tras las mismas.



7

La computación concierne a la teoría y fundamentos de cualquier sistema de cómputo, sea de hardware o de software.

La Ingeniería de software concierne solo al desarrollo de sistemas o productos de software.

La Ingeniería de Software todavía esta lejos de ser una ciencia como los son la Química, la Ingeniería Civil o la Electrónica.

Ingeniería de Software vs Ciencia de la Computación


8

La Ingeniería de Sistemas concierne a todos los aspectos del desarrollo de sistemas basados en cómputo, que incluyen hardware, software y el proceso de Ingeniería. La Ingeniería de Software es solo parte de este proceso.

Ingeniería de Sistemas e Ingeniería de Software


9

2.2. Proceso de Software

Concepto.

Es un conjunto de actividades y resultados asociados que producen un producto de software.producto de software.Es uno de los componentes de un mméétodo de desarrollo todo de desarrollo de software. de software.


10

Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

Especificación- qué debe hacer el software y cuáles son sus especificaciones de desarrollo.Desarrollo – producción del sistema de software.Validación – verificar que el software hace lo que el cliente pide.Evolución – cambiar/adaptar el software a las demandas.

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse.Debe estar explícitamente modelado si va a ser bien administrado.

Proceso de Software


11

Proceso de Software


12

Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle.

El tiempo de cada actividad varía, así como los resultados.Organizaciones diferentes usan procesos diferentes para producir el mismo producto.

Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros.

Proceso de Software (Sommerville, 2005)


13

Modelo de Proceso de Software

Es una descripción que se presenta desde una perspectiva particular.Es una abstracción de un proceso real.Incluye actividades (que son parte de los procesos de software), los productos (artefactos) software, y el papel de las personas involucradas en el desarrollo (stakeholders).Ejemplos:

Modelos de flujos de trabajo.Modelo de flujo de datos o actividad.Un modelo de rol/acción.


14

Modelo de Procesos

Existe una gran variedad de modelos diferentes “genéricos” o paradigmas de desarrollo de software.

Enfoque en cascada.Desarrollo evolutivo.Transformación formal.Sistema de ensamblaje de componentes reutilizables.

No confundir con el modelo de procesos de un sistema.


15

2.3. Ciclo de Vida

Alternativamente, a veces se usan los términos “Ciclo de vida”, y “Modelo de ciclo de vida”

Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotación)


16

Ciclo de vida ≠

Ciclo de desarrolloDesde el análisis hasta la entrega al usuario

Toda la vida del sistema:

desde la concepción hasta el fin de uso

¿Qué es un proceso software?. Ciclo de vida


17

Objetivos del Ciclo de Vida

Definir las actividades a ser ejecutadas en un proyecto de Procesamiento Electrónico de Datos (PED)Introducir coherencia en muchos proyectos de PED de la misma organizaciónEstablecer punto de control para control de gerencia y puntos de control para tomar la decisión de “continuar o no”.


18

Tipos de Ciclos de Vida

El Ciclo de Vida del Desarrollo de Sistemas es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de información y aplicaciones informáticas.


19

A.A.R.R.

PrototProtot.. 11

Protot2 Protot2 PrototProtot.3.3PrototipoPrototipoOperacionalOperacional

AnAnáálisis delisis deRiesgo.Riesgo.

AnAnáálisis de lisis de RiesgoRiesgo

AnAnáálisis de lisis de RiesgosRiesgos

EvalEvalúúa a alternativas,alternativas,identifica y identifica y resuelveresuelve

RiesgosRiesgos

Determina objetivos, Determina objetivos, alternativas y lalternativas y líímitesmites

Mayor Mayor costocosto

DiseDiseññoodetalladodetallado

CodifCodif..TestTestUnid.Unid.

IntegracIntegrac..Y testeoY testeo

Test deTest deAceptacAceptac..

ImplementaciImplementacióónn

DiseDiseñño validacio validacióón yn yverificaciverificacióónn

DiseDiseñño deo deproductosproductosde de SoftSoft..IntegraciIntegracióónn

y testeoy testeo

ValidaciValidacióón den deRequerimientosRequerimientos

Desarrollo deDesarrollo dePlanPlan

RequerimientRequerimient ososDe Software.De Software.

Concepto deConcepto deOperaciOperacióónn

Desarrollo y Desarrollo y verifverif. producto de . producto de proxprox. nivel. nivel

Plan delPlan delciclo de vidaciclo de vidaRequerimRequerim..


20

Ingeniería es una ciencia aplicada, o sea un área de conocimiento humano que utiliza principios matemáticos y físicos para resolver problemas ligados a la construcción de INGENIOS. Un Ingenio es todo aquello que produce la capacidad creativa del hombre para atender a un fin determinado.

INGENIERIA DE INFORMACION


21

La Ingeniería de la Información se puede definir como una disciplina, o sea un “conjunto de conocimientos” ligados al tratamiento de la Información y la construcción de mecanismos formales para la construcción de los “Sistemas de Información”.

INGENIERIA DE INFORMACION


22

CARACTERISTICAS DE LA INGENIERIA DE LA INFORMACIÓN

Centrada en los negociosParticipación intensa de los usuariosImplementación de Técnicas de Modelaje eficaces.Se orienta a la AUTOMATIZACION en los desarrollos de los sistemas.Propone a la Tecnología como “soporte” de los negocios.


23

PEIPEI

ANNANN

PSIPSI

CSICSI

1. Planeamiento Estratégico de Informaciones (PEI)

2. Análisis del Área de Negocios (AAN)

3. Proyecto de Sistemas de Información (PSI)

4. Construcción del Sistema de Información (CSI


24

2.4. Metodologías de Desarrollo de Software

Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo softwareTarea: Actividades elementales en que se dividen los procesos.Procedimiento: Definición de la forma de ejecutar la tarea.


25

2.4. Metodologías de Desarrollo de Software

Técnica: Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias.Herramienta: Para realizar una técnica, podemos apoyarnos en las herramientas software que automatizan su aplicación.Producto: Resultado de cada etapa.


26

METODOLOGÍA vs CICLO DE VIDA

Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo.

La metodología indica cómo hay que obtener los distintos productos parciales y finales.


27

GENERACIONES DE METODOLOGÍA

Desarrollo Convencional (Sin metodología) .Desarrollo Estructurado.Desarrollo Orientado a Objetos.


28

Desarrollo Convencional

Los resultados finales son impredecibles.No hay forma de controlar lo que está sucediendo en el Proyecto.Los cambios organizativos afectan negativamente al proceso de desarrollo.


29

Desarrollo Estructurado

Programación estructuradaDiseño estructuradoAnálisis estructuradoEspecificaciones funcionales:

GráficasParticionadasMínimamente redundantes


30

AÑO METODOLOGÍA1968 Conceptos sobre la programación estructurada de DIJKSTRA1974 Técnicas de programación estructurada de WARNIER y JACKSON1975 Primeros conceptos sobre diseño estructurado de MYERS y YOURDON1977 Primeros conceptos sobre análisis estructurado GANE y SARSON1978 Análisis estructurado: DEMARCO y WEINBERGNace MERISE1981 SSADM (versión inicial)Information Engineering (versión inicial)1985 Análisis y Diseño estructurado para sistemas de tiempo real deWARD y MELLOR1986 SSADM Versión 31987 Análisis y Diseño estructurado para sistemas de tiempo real deHATLEY y PIRHBAY1989 METRICA (versión inicial)1990 SSADM Versión 41993 METRICA Versión 21995 METRICA Versión 2.1

RELACION HISTORICA DE LAS PRINCIPALES METODOLOGIAS


31

Desarrollo Orientado a Objetos

La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje de programación.


32

Consideraciones sobre Metodologías OO

Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto.

Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.

Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica


33

Aspectos Positivos de las Metodologías OO

Son interactivas e incrementales.

Fácil de dividir el sistema en varios subsistemas independientes.

Se fomenta la reutilización de componentes.


34

Características Deseables de una Metodología

Existencia de reglas predefinidas.Cobertura total del ciclo de desarrollo.Verificaciones intermedias.Planificación y control.Comunicación efectiva.Utilización sobre un abanico amplio de proyectos.Fácil formación.Herramientas CASE.Actividades que mejoren el proceso de desarrollo.Soporte al mantenimiento.Soporte de la reutilización de software.


35

Clasificación de las Metodologías

EstructuradasOrientadas a ProcesosOrientadas a datos

JerárquicasNo Jerárquicas

MixtasOrientadas a ObjetosPara Sistemas de Tiempo Real


36

Metodologías Orientadas a Procesos

METODOLOGIAS ESTRUCTURADASEspecificación estructurada:

Diagramas de Flujo de DatosDiccionario de DatosEspecificaciones de procesos


37


1. Construir el modelo físicoactual (DFD físico actual)

2. Construir el modelo lógicoactual (DFD lógico actual)

3. Crear un conjunto de modelosfísicos alternativos

4. Estimar los costes y tiemposde cada opción

5. Seleccionar un modelo6. Empaquetar la especificación

1. Construir el modelo lógico actual (DFD lógico actual)2. Construir el modelo del nuevo

sistema: elaborar una especificaciónestructurada y construir un modelológico de datos en tercera formanormal que exprese el contenido delos almacenes de datos.

3. Seleccionar un modelo lógico4. Crear el nuevo modelo físico del sistema5. Empaquetar la especificación

FASES DEL ANALISIS ESTRUCTURADO

Método Demarco Método de Gane y Sarson


38


Metodología de Yourdon/Constantine

Realizar los DFD del sistemaRealizar el diagrama de estructurasEvaluar el diseñoPreparar el diseño para la implantación


39

Metodologías Orientadas a Datos Jerárquicos

La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa.

El proceso de diseño consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura

El diseño lógico debe preceder y estar separado del diseño físico.


40

Metodologías Orientadas a Datos No Jerárquicos

Metodología Ingeniería de la Información.

Planificación: construir una arquitectura de la Informacióny una estrategia que soporte los objetivos de la organización

Análisis: comprender las áreas del negocio y determinar losrequisitos del sistema

Diseño: establecer el comportamiento del sistema deseadopor el usuario y que sea alcanzable por la tecnología

Construcción: construir sistemas que cumplan los tres nivelesanteriores.


41

Metodologías Orientadas a Objetos

Se examinan los sistemas desde las funciones o tareas que deben realizar, que se descomponen sucesivamente en tareas más pequeñas para formar los módulos de la aplicación.

En OO cobra importancia del modelado del sistema examinando el dominio del problema como un conjunto de objetos que interactúan entre si.

En xxx se produce una dicotomía entre función y datos.

En OO se propugna un enfoque: unificar de ambos aspectos que se encapsulan en los objetos.


42

Metodologías Orientadas a Objetos

Se identifican dos enfoque en metodologías OO:

“Revolucionarios” o “puros”“Sintetistas” o “evolutivos”


43

Metodologías para Sistemas de Tiempo Real

Manejo de interrupciones.Comunicación y sincronización entre tareas.Gestión de procesos concurrentes.Respuesta oportuna ante eventos externos.Datos continuos o discretos.Se está produciendo una evolución de las metodologías orientadas a objetos para desarrollos de sistemas de tiempo real.


44

2.5. Motivos para el Uso de una Metodología

Nivel de Madurez del Proceso de Desarrollo de Software.

SEI Carnegie Mello University de Pittsburg.Son cinco los nivelesInicial: la empresa no dispone de procesos y controles definidos.

Se trabaja con procedimientos que no están formalizados, es decir, procedimientos tanto del propio desarrollo de software como de su planificación y control, y no están establecidos explícitamente antes de su uso.


45

Técnicas y herramientas carecen de integración, son empleadas en algunas fases del ciclo de vida del desarrollo de software.Lo que caracteriza a las empresas que están en este nivel es que no hay un control de la Gestión de Proyectos Software efectivo; procedimientos, técnicas formales no se utilizan de una manera estándar en todos los proyectos.

Inicial: la empresa no dispone de procesos y controles definidos.


46

Disponen de un control básico de la gestión: proyectos, calidad y configuración.G. de Proyectos: se determina la programación de proyectos más adecuada en cuanto a productos a entregar y plazos de tiempo previstos y se prevén los recursos necesarios.G. de Calidad: que asegure a la dirección que el proceso software se realiza ajustándose a los procedimientos formales de la empresa.

Repetible: la empresa tiene métodos estandarizados facilitando procesos repetibles.


47

G. de la Configuración: que se encarga de que un cambio producido en cualquier producto software se refleje en todos los demás productos software.Introducir cualquier cambio tiene un alto grado de riesgo de fracaso:

Por no servirles los datos estadísticos de otros proyectos, si se cambió el tipo de sistema a desarrollar.Si se introducen nuevas herramientas o métodos, ya que afectarán al proceso.

Repetible: la empresa tiene métodos estandarizados facilitando procesos repetibles.


48

Un grupo de proceso: cuyo objetivo es el de mejorar el proceso software. Esto se logra:

Definiendo el proceso de desarrollo.Identificando necesidades tecnológicas.Asesorando los proyectos.Revisando periódicamente el estado y rendimiento del proceso.

Proceso Definido: la empresa monitoriza y mejora sus procesos. Disponen de:


49

Proceso Definido: la empresa monitoriza y mejora sus procesos. Disponen de:

Una metodología de desarrollo de software: que describa las actividades técnicas y de gestión requeridas para la adecuada ejecución del proceso de desarrollo.


50

Proceso Gestionado: la empresa posee controles avanzados. Métricas y retroalimentación:

Disponen de control de costos y calidad de las principales etapas del proceso. Por tanto, es prerrequisito que exista una metodología de desarrollo software para realizar una medición efectiva.El objetivo de disponer de datos del proceso, mediante el empleo de métricas y controles es el de mejorar el proceso y no el de evaluar individuos o equipos.


51

Proceso en Optimización: la empresa emplea métricas con propósitos de optimización.

Tiene los medios para identificar los elementos más débiles del proceso y mejorarlos. Es vital disponer de datos para justificar la aplicación de una nueva tecnología a tareas críticas. Para ello se ha de soportar la recolección de datos del proceso de una manera automática, bien porque algunos datos no se pueden recoger manualmente o bien porque se introduce con mayor seguridad que manualmente.


52

Importancia de la Metodología

Factores que repercuten en la persona que trabaja en un entorno de desarrollo de software:

Cambios en el so, lenguaje de programación, organización del proyecto, formato de las especificaciones, los estándares establecidos.

Trabajador y cantidad de trabajo.

Productividad: alterada de distintas maneras (escribir a máquina).


53

Importancia de la Metodología

Calidad del producto: establecer un entorno que no sólo mejore la productividad del que desarrolla, sino que genere la creación de mejores productos.

Esto se logra con un entorno metodológico para el desarrollo de software que consta de una secuencia de pasos, combinando procedimientos de gestión, métodos técnicos, y soporte automatizado para producir software.


54

Impacto de la Metodología en el Entorno de Desarrollo.


55

Programadores vs Metodologías

Personal con alta cualificación no asegura el éxito en la consecución de los objetivos propuestos debido a: falta de conjunción, perfecto engranaje, auténtico trabajo en equipo.

CMM, indica que los mejores informáticos requieren un entorno disciplinado y estructurado en la cual puedan realizar un trabajo en equipo, para lograr obtener unos productos con alta calidad.


56

Programadores vs Metodologías.

La disciplina no va a coartar la creatividad de los buenos profesionales, sino todo lo contrario, al liberarles de los errores que otros producen.

PARNAS: IS, “multi person construction of multiversion software”.


57


PARNAS: IS, “multi personconstructionof multiversionsoftware”.


58


Programador: individualista, escribe un programa completo por sí solo sin tener en cuenta la posible interacción con otros programas, ni que “su” programa vaya a ser “tocado” por otro en su vida.

Ingeniero de Software: persona que trabaja en equipo, que conoce que lo que él realiza es un componente software que se combinará con otros componentes realizados por otros ingenieros de software para forma un sistema.


59

2.6. Criterios para Evaluar una Metodología

Debe ajustarse a los objetivos: Cada aproximación al desarrollo está basada en unos objetivos a lograr. Por ello, la metodología que elija debe recoger el aspecto filosófico de la aproximación deseada, es decir, que los objetivos generales del desarrollo deben estar implementados en la metodología de desarrollo.

Debe cubrir el ciclo entero de desarrollo de software: investigación, análisis de requisitos, diseño.


60

Criterios para Evaluar una Metodología

Debe integrar las distintas fases del ciclo de desarrollo:

Rastreabilidad: en fases distintas a la de requerimientos, el ing. De software debe poder referirse a la fase previa y fusionar el trabajo. Identificar los módulos. Correspondencia entre módulos y unidades de programas.

Fácil interacción entre etapas del ciclo de desarrollo: Se refiere a la importancia de la validación formal antes de pasar a la siguiente. Ejm. Dejar de documentar un requisito.


61


Debe incluir la realización de validaciones. Destacar y corregir errores cuanto antes:

los errores han sido hechos antes de la codificación.Cuanto más tarde sea detectado el error, más caro es corregirlo.


62


Debe soportar la determinación de la exactitud del sistema a través del ciclo de desarrollo.

Implica la correspondencia entre el sistema y sus especificaciones, así como que el sistema cumple con las necesidades del usuario.

No sólo técnicas para validar, sino también prestar atención para obtener la descripción más completa y exacta de los requisitos de usuarios, a la vez que consigue una productividad de desarrollo.


63


Debe ser la base de una comunicación efectiva.

Emplear el número óptimo de personas.

Reducir la pérdida de productividad debido a las comunicaciones en un proyecto, consiguiendo que el trabajo se haga con menos ejecutores y más productivos.


64


Debe funcionar en un entorno dinámico orientado al usuario.

Transformación de conocimiento: transferencia de conocimiento al usuario, promover la flexibilidad, creatividad y cooperación.

Técnicas de diagramación sencillas: el usuario debe pensar en los sistemas ayudado de diagramas claros, y pudiendo describir los procedimientos que necesita.


65


Debe especificar claramente los responsables de resultados.

Identificar claramente quiénes son los participantes de cada tarea a desarrollar, detallar los resultados de los que serán responsables.

Pasos claramente definidos apoyan esta definición.


66


Debe poder emplearse en un entorno amplio de proyectos de software.

Variedad: útil para un número grande de sistemas que se vaya a construir.

Tamaño, vida: de distintos tamaños y rangos de vida.

Complejidad: es decir, que abarquen a un departamento o varios, o varias empresas.

Entorno: servir con independencia de la tecnología que disponga la empresa.


67


Se debe poder enseñar.

Cada persona debe poder entender las técnicas específicas de la metodología, los procedimientos organizativos y de gestión que la hacen efectiva, las herramientas automatizadas que soportan la metodología.


68


Debe estar soportada por herramientas CASE.

Que mejoren la productividad tanto del ingeniero software como la del equipo del desarrollo en general.Reduce el número de personas requeridas y la sobrecarga de comunicación.

Ayuda a producir especificaciones y diseños con menos errores, más fáciles de probar, modificar y usar siempre que se utilicen técnicas modernas de diseño.


69


Debe soportar la evolución eventual del sistema.

Cambios de tecnología, necesidades de usuarios, provocan cambios al desarrollo del sistemas.

La metodología asiste en esta actividad evolutiva indicando qué productos software deben estar incluidos en el baseline logrando suministrar una documentación del sistema interno y externo en concordancia.


70


Debe contener actividades conducentes a mejorar el proceso de desarrollo de software.

Mejorar el proceso significa disponer de datos numéricos que evidencian la efectividad de la aplicación del proceso con respecto a cualquier producto software resultante del proceso.

Conjunto de mediciones de proceso identificar calidad y costo asociado a cada etapa del proceso.

Ideal: mediciones soportadas por case.


71

Descripción de Metodologías para Desarrollo de Software

METODOLOGIA SSADM Structured Systems Analysis and Design Method(1981, 1986, 1990)

• ESTUDIO DE FACTIBILIDAD• ANALISIS DE REQUISITOS• ESPECIFICACION DE REQUISITOS• ESPECIFICACION DEL SISTEMA LOGICO• DISEÑO FISICO


72

METODOLOGIA SSADM Structured Systems Analysis and Design Method(1981, 1986, 1990)


73

MODULO ETAPA PASOS Preparación del EF Definición del Problema Selección de las Opciones de Factibilidad

ESTUDIO DE FACTIBILIDAD (EF)

Factibilidad

Construcción del Informe de Factibilidad



74

MODULO ETAPA PASOS Organización del Análisis Investigación y Definición de los Requisitos Investigación de los Datos Actuales Obtención de una Visión Lógica de los Servicios Actuales

Investigación del Entorno Actual

Reunión de los Resultados de la Investigación Definición de las Opciones de Gestión del Sistema

ANÁLISIS DE REQUISITOS

Opciones de Gestión del Sistema

Selección de una Opción de Gestión del Sistema



75

MODULO ETAPA PASOS Definición del Funcionamiento del Sistema Requerido Desarrollo del Modelo Lógico de Datos RequeridoObtención delas Funciones del Sistema Refinar el Modelo Lógico de Datos Requeridos

Desarrollo de los Prototipos de Especificación

Desarrollo de la Especificación de Funcionamiento Confirmación de los Objetivos del Sistema

ESPECIFICACIÓN DE REQUISITOS (ER)

Definición de Requisitos

Reunión de la ER



76

MODULO ETAPA PASOS Definición de las Opciones Técnicas del Sistema

Opciones Técnicas del Sistema Selección de una Opción de

Gestión del Sistema Diseño de los Diálogos de Usuario

Definición de los Procesos de Actualización

Definición de los Procesos de Consulta de la Base de Datos

ESPECIFICACIÓN DEL SISTEMA LÓGICO

Diseño Lógico

Reunión de la para la Construcción del Diseño Lógico



77

MODULO ETAPA PASOS Preparación para el Diseño Físico Creación del Diseño Físico de Datos Creación del Mapa de Implantación de Componentes de FuncionesOptimización del Diseño Físico de Datos

Completar la Especificación de Funciones

Consolidación del Interfaz Procesos/Datos

DISEÑO FISICO

Diseño Físico

Reunión del Diseño Físico



78

Planificación del Sistema

de Información

PSI

Desarrollo

EVS

ASI

DSI

CSI

IAS

Mantenimiento del Sistema de

Información MSI

Interfaz Interfaz

Interfaz

Interfaz

GESTION DE PROYECTOS

SEGURIDAD

ASEGURAMIENTO DE CALIDAD

GESTION DE CONFIGURACIÓN

Descripción de Metodologías para Desarrollo de SoftwareDiagrama de los Procesos Principales de la Metodologia Metrica Version III


79


80


81


82


83


84

Bibliografía

Ian Sommerville. “Ingeniería de Software” . Editorial Prentice Hall.Rogger S. Pressman. “Ingeniería de Software: Un Enfoque Práctico”. Editorial McGraw – Hill, quinta edición.Jesús Barranco Areba. “Metodologías del Análisis Estructurado de Sistemas”Universidad Pontificia ICAI ICADE; Madrid.


85

BIBLIOGRAFIA

Ian Sommerville, Ingeniería de Software. Sexta Edición, Editorial Adisson Wesley.Whitten y Bentley, Análisis de Sistemas Teoría y Métodos. Séptima Edición Editorial MxGraw – Hill.Kendal & Kendal, Análisis y Diseño de Sistemas. Sexta Edición, Editorial Pearson.Antonio de Amescua Seco, Luis García Sánchez, Paloma Martínez Fernández y Paloma Díaz Pérez. Ingeniería de Software de Gestión Análisis y Diseño de Aplicaciones. Editorial Paraninfo.

Education

Modulo ii metodologías de sistemas