Modulo ii metodologías de sistemas

  • 1,398 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,398
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
62
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Metodologías de Desarrollode Sistemas de Información Análisis y Diseño de Sistemas II Semestre de 2010 Elaborado por Prof. Virginia Juárez - II semestre 1 2010
  • 2. 2.1. Ingeniería de SoftwareConcepto. 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: Elaborado por Prof. Virginia Juárez - II semestre 2 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 3 2010
  • 4. Ingeniería de Software• 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. Elaborado por Prof. Virginia Juárez - II semestre 4 2010
  • 5. Ingeniería de SoftwareUna 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). Elaborado por Prof. Virginia Juárez - II semestre 5 2010
  • 6. Ingeniería de SoftwareUna 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. Elaborado por Prof. Virginia Juárez - II semestre 6 2010
  • 7. Ingeniería de Software vs Ciencia de la Computación 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. Elaborado por Prof. Virginia Juárez - II semestre 7 2010
  • 8. Ingeniería de Sistemas e Ingeniería de Software 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. Elaborado por Prof. Virginia Juárez - II semestre 8 2010
  • 9. 2.2. Proceso de SoftwareConcepto. Es un conjunto de actividades y resultados asociados que producen un producto de software. Es uno de los componentes de un método de desarrollo de software. Elaborado por Prof. Virginia Juárez - II semestre 9 2010
  • 10. Proceso de SoftwareConjunto estructurado de actividades requeridas para desarrollar unsistema 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 desistema a desarrollarse.Debe estar explícitamente modelado si va a ser bien administrado. Elaborado por Prof. Virginia Juárez - II semestre 10 2010
  • 11. Proceso de Software Elaborado por Prof. Virginia Juárez - II semestre 11 2010
  • 12. Proceso de Software(Sommerville, 2005) 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. Elaborado por Prof. Virginia Juárez - II semestre 12 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 13 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 14 2010
  • 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) Elaborado por Prof. Virginia Juárez - II semestre 15 2010
  • 16. ¿Qué es un proceso software?. Ciclode vidaCiclo de vida ≠ Ciclo de desarrollo Desde el análisis hasta la entrega al usuario Toda la vida del sistema: desde la concepción hasta el fin de uso Elaborado por Prof. Virginia Juárez - II semestre 16 2010
  • 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ón Establecer punto de control para control de gerencia y puntos de control para tomar la decisión de “continuar o no”. Elaborado por Prof. Virginia Juárez - II semestre 17 2010
  • 18. Tipos de Ciclos de VidaEl Ciclo de Vida del Desarrollo de Sistemas esun proceso por el cual los analistas desistemas, los ingenieros de software, losprogramadores y los usuarios finales elaboransistemas de información y aplicacionesinformáticas. Elaborado por Prof. Virginia Juárez - II semestre 18 2010
  • 19. Evalúa EvalúDetermina objetivos, Mayor alternativas,alternativas y límites lí costo identifica y resuelve Riesgos Análisis de Aná Análisis de Aná Riesgos Riesgo Análisis de Aná Riesgo. Prototipo A. Protot2 Protot.3 Protot.3 Operacional R. Protot. Protot. 1 Plan del Concepto de ciclo de vida Requerim. Operación Requerim. Operació Diseño Diseñ Requerimient os detallado De Software. Desarrollo de Validación de Validació Diseño de Diseñ Plan Requerimientos Codif. Codif. productos de Soft. Test Soft. Integración Integració Unid. y testeo Diseño validación y Diseñ validació verificación verificació Integrac. Integrac. Y testeo Test de Aceptac. Aceptac. Implementación Implementació Elaborado por Prof. Virginia Juárez - II semestre 19 Desarrollo y verif. producto de prox. nivel 2010 verif. prox.
  • 20. INGENIERIA DE INFORMACIONIngeniería es una ciencia aplicada, o sea un área deconocimiento humano que utiliza principios matemáticos yfísicos para resolver problemas ligados a la construcción deINGENIOS. Un Ingenio es todo aquello que produce lacapacidad creativa del hombre para atender a un findeterminado. Elaborado por Prof. Virginia Juárez - II semestre 20 2010
  • 21. INGENIERIA DE INFORMACIONLa Ingeniería de la Información se puede definir como unadisciplina, o sea un “conjunto de conocimientos” ligados altratamiento de la Información y la construcción demecanismos formales para la construcción de los“Sistemas de Información”. Elaborado por Prof. Virginia Juárez - II semestre 21 2010
  • 22. CARACTERISTICAS DE LA INGENIERIA DE LAINFORMACIÓNCentrada en los negociosParticipación intensa de los usuariosImplementación de Técnicas de Modelajeeficaces.Se orienta a la AUTOMATIZACION en losdesarrollos de los sistemas.Propone a la Tecnología como “soporte” de losnegocios. Elaborado por Prof. Virginia Juárez - II semestre 22 2010
  • 23. PEI ANN PS I CSI1. 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 Elaborado por Prof. Virginia Juárez - II semestre 23 2010
  • 24. 2.4. Metodologías de Desarrollo de SoftwareMetodología: Conjunto de procedimientos,técnicas, herramientas y un soporte documentalque ayuda a los desarrolladores a realizarnuevo softwareTarea: Actividades elementales en que sedividen los procesos.Procedimiento: Definición de la forma deejecutar la tarea. Elaborado por Prof. Virginia Juárez - II semestre 24 2010
  • 25. 2.4. Metodologías de Desarrollo de SoftwareTécnica: Herramienta utilizada para aplicar unprocedimiento. Se pueden utilizar una o varias.Herramienta: Para realizar una técnica,podemos apoyarnos en las herramientassoftware que automatizan su aplicación.Producto: Resultado de cada etapa. Elaborado por Prof. Virginia Juárez - II semestre 25 2010
  • 26. METODOLOGÍA vs CICLO DE VIDAUna metodología puede seguir uno o varios modelos deciclo de vida, es decir, el ciclo de vida indica qué es loque hay que obtener a lo largo del desarrollo delproyecto pero no cómo hacerlo.La metodología indica cómo hay que obtener losdistintos productos parciales y finales. Elaborado por Prof. Virginia Juárez - II semestre 26 2010
  • 27. GENERACIONES DE METODOLOGÍA Desarrollo Convencional (Sin metodología) . Desarrollo Estructurado. Desarrollo Orientado a Objetos. Elaborado por Prof. Virginia Juárez - II semestre 27 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 28 2010
  • 29. Desarrollo Estructurado Programación estructurada Diseño estructurado Análisis estructurado Especificaciones funcionales: Gráficas Particionadas Mínimamente redundantes Elaborado por Prof. Virginia Juárez - II semestre 29 2010
  • 30. RELACION HISTORICA DE LAS PRINCIPALES METODOLOGIASAÑ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 Elaborado por Prof. Virginia Juárez - II semestre 30 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 31 2010
  • 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 Elaborado por Prof. Virginia Juárez - II semestre 32 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 33 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 34 2010
  • 35. Clasificación de las Metodologías Estructuradas Orientadas a Procesos Orientadas a datos Jerárquicas No Jerárquicas Mixtas Orientadas a Objetos Para Sistemas de Tiempo Real Elaborado por Prof. Virginia Juárez - II semestre 35 2010
  • 36. Metodologías Orientadas a Procesos METODOLOGIAS ESTRUCTURADAS Especificación estructurada: Diagramas de Flujo de Datos Diccionario de Datos Especificaciones de procesos Elaborado por Prof. Virginia Juárez - II semestre 36 2010
  • 37. Metodologías Orientadas a Procesos FASES DEL ANALISIS ESTRUCTURADOMétodo Demarco Método de Gane y Sarson 1. Construir el modelo físico 1. Construir el modelo lógico actualactual (DFD físico actual) (DFD lógico actual) 2. Construir el modelo lógico 2. Construir el modelo del nuevoactual (DFD lógico actual) sistema: elaborar una especificación 3. Crear un conjunto de modelos estructurada y construir un modelofísicos alternativos lógico de datos en tercera forma 4. Estimar los costes y tiempos normal que exprese el contenido dede cada opción los almacenes de datos. 5. Seleccionar un modelo 3. Seleccionar un modelo lógico 6. Empaquetar la especificación 4. Crear el nuevo modelo físico del sistema 5. Empaquetar la especificación Elaborado por Prof. Virginia Juárez - II semestre 37 2010
  • 38. Metodologías Orientadas a Procesos Metodología de Yourdon/Constantine Realizar los DFD del sistema Realizar el diagrama de estructuras Evaluar el diseño Preparar el diseño para la implantación Elaborado por Prof. Virginia Juárez - II semestre 38 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 39 2010
  • 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ón y una estrategia que soporte los objetivos de la organización Análisis: comprender las áreas del negocio y determinar los requisitos del sistema Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología Construcción: construir sistemas que cumplan los tres niveles anteriores. Elaborado por Prof. Virginia Juárez - II semestre 40 2010
  • 41. Metodologías Orientadas a ObjetosSe 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. Elaborado por Prof. Virginia Juárez - II semestre 41 2010
  • 42. Metodologías Orientadas a ObjetosSe identifican dos enfoque en metodologías OO: “Revolucionarios” o “puros” “Sintetistas” o “evolutivos” Elaborado por Prof. Virginia Juárez - II semestre 42 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 43 2010
  • 44. 2.5. Motivos para el Uso de una MetodologíaNivel de Madurez del Proceso de Desarrollo deSoftware. SEI Carnegie Mello University de Pittsburg. Son cinco los niveles Inicial: 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. Elaborado por Prof. Virginia Juárez - II semestre 44 2010
  • 45. Inicial: la empresa no dispone de procesos y controlesdefinidos. 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. Elaborado por Prof. Virginia Juárez - II semestre 45 2010
  • 46. Repetible: la empresa tiene métodosestandarizados facilitando procesos repetibles. 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. Elaborado por Prof. Virginia Juárez - II semestre 46 2010
  • 47. Repetible: la empresa tiene métodos estandarizadosfacilitando procesos repetibles. 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. Elaborado por Prof. Virginia Juárez - II semestre 47 2010
  • 48. Proceso Definido: la empresa monitoriza y mejora susprocesos. Disponen de: 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. Elaborado por Prof. Virginia Juárez - II semestre 48 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 49 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 50 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 51 2010
  • 52. Importancia de la MetodologíaFactores que repercuten en la persona que trabaja en un entorno dedesarrollo 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). Elaborado por Prof. Virginia Juárez - II semestre 52 2010
  • 53. Importancia de la MetodologíaCalidad del producto: establecer un entorno que no sólo mejore laproductividad del que desarrolla, sino que genere la creación demejores productos.Esto se logra con un entorno metodológico para el desarrollo desoftware que consta de una secuencia de pasos, combinandoprocedimientos de gestión, métodos técnicos, y soporteautomatizado para producir software. Elaborado por Prof. Virginia Juárez - II semestre 53 2010
  • 54. Impacto de la Metodología en el Entorno de Desarrollo. Elaborado por Prof. Virginia Juárez - II semestre 54 2010
  • 55. Programadores vs MetodologíasPersonal con alta cualificación no asegura eléxito en la consecución de los objetivospropuestos debido a: falta de conjunción,perfecto engranaje, auténtico trabajo en equipo.CMM, indica que los mejores informáticosrequieren un entorno disciplinado y estructuradoen la cual puedan realizar un trabajo en equipo,para lograr obtener unos productos con altacalidad. Elaborado por Prof. Virginia Juárez - II semestre 55 2010
  • 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 multi version software”. Elaborado por Prof. Virginia Juárez - II semestre 56 2010
  • 57. Programadores vs Metodologías.PARNAS: IS,“multi personconstructionof multiversionsoftware”. Elaborado por Prof. Virginia Juárez - II semestre 57 2010
  • 58. Programadores vs Metodologías.Programador: individualista, escribe un programacompleto por sí solo sin tener en cuenta la posibleinteracción con otros programas, ni que “su” programavaya 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 componentesoftware que se combinará con otros componentesrealizados por otros ingenieros de software para formaun sistema. Elaborado por Prof. Virginia Juárez - II semestre 58 2010
  • 59. 2.6. Criterios para Evaluar una MetodologíaDebe ajustarse a los objetivos: Cada aproximación aldesarrollo está basada en unos objetivos a lograr. Porello, la metodología que elija debe recoger el aspectofilosófico de la aproximación deseada, es decir, que losobjetivos generales del desarrollo deben estarimplementados en la metodología de desarrollo.Debe cubrir el ciclo entero de desarrollo de software:investigación, análisis de requisitos, diseño. Elaborado por Prof. Virginia Juárez - II semestre 59 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 60 2010
  • 61. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 61 2010
  • 62. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 62 2010
  • 63. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 63 2010
  • 64. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 64 2010
  • 65. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 65 2010
  • 66. Criterios para Evaluar una Metodología 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 Elaborado porindependencia de la tecnología 66que con Prof. Virginia Juárez - II semestre disponga la empresa. 2010
  • 67. Criterios para Evaluar una MetodologíaSe 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. Elaborado por Prof. Virginia Juárez - II semestre 67 2010
  • 68. Criterios para Evaluar una MetodologíaDebe 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. Elaborado por Prof. Virginia Juárez - II semestre 68 2010
  • 69. Criterios para Evaluar una Metodología 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. Elaborado por Prof. Virginia Juárez - II semestre 69 2010
  • 70. Criterios para Evaluar una MetodologíaDebe contener actividades conducentes a mejorar el procesode 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. Elaborado por Prof. Virginia Juárez - II semestre 70 2010
  • 71. Descripción de Metodologías para Desarrollo deSoftware 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 Elaborado por Prof. Virginia Juárez - II semestre 71 2010
  • 72. METODOLOGIA SSADMStructured Systems Analysis and Design Method(1981, 1986, 1990) Elaborado por Prof. Virginia Juárez - II semestre 72 2010
  • 73. Descripción de Metodologías para Desarrollo deSoftware MODULO ETAPA PASOS Factibilidad Preparación del EF Definición delESTUDIO DE ProblemaFACTIBILIDAD Selección de las(EF) Opciones de Factibilidad Construcción del Informe de Factibilidad Elaborado por Prof. Virginia Juárez - II semestre 73 2010
  • 74. Descripción de Metodologías para Desarrollo de Software MODULO ETAPA PASOS Investigación del Organización del Entorno Actual Análisis Investigación y Definición de los Requisitos Investigación de los Datos Actuales Obtención de una ANÁLISIS DE Visión Lógica de los REQUISITOS Servicios Actuales Reunión de los Resultados de la Investigación Opciones de Gestión Definición de las del Sistema Opciones de Gestión del Sistema Selección de una Opción de Gestión del Sistema Elaborado por Prof. Virginia Juárez - II semestre 74 2010
  • 75. Descripción de Metodologías para Desarrollo de Software MODULO ETAPA PASOS Definición de Definición del Requisitos Funcionamiento del Sistema Requerido Desarrollo del Modelo Lógico de Datos Requerido Obtención delas Funciones del Sistema ESPECIFICACIÓN DE REQUISITOS Refinar el Modelo Lógico de (ER) Datos Requeridos Desarrollo de los Prototipos de Especificación Desarrollo de la Especificación de Funcionamiento Confirmación de los Objetivos del Sistema Reunión de la ER Elaborado por Prof. Virginia Juárez - II semestre 75 2010
  • 76. Descripción de Metodologías para Desarrollo de Software MODULO ETAPA PASOS Opciones Definición de las Opciones Técnicas del Técnicas del Sistema Sistema Selección de una Opción de Gestión del Sistema Diseño Lógico Diseño de los Diálogos de Usuario ESPECIFICACIÓN DEL SISTEMA Definición de los Procesos LÓGICO de Actualización Definición de los Procesos de Consulta de la Base de Datos Reunión de la para la Construcción del Diseño Lógico Elaborado por Prof. Virginia Juárez - II semestre 76 2010
  • 77. Descripción de Metodologías para Desarrollo de Software MODULO ETAPA PASOS Diseño Físico 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 Funciones DISEÑO FISICO Optimización del Diseño Físico de Datos Completar la Especificación de Funciones Consolidación del Interfaz Procesos/Datos Reunión del Diseño Físico Elaborado por Prof. Virginia Juárez - II semestre 77 2010
  • 78. Descripción de Metodologías para Desarrollo de Software Diagrama de los Procesos Principales de la Metodologia Metrica Version III Interfaz GESTION DE CONFIGURACIÓN Desarrollo EVSPlanificación ASI Mantenimientodel Sistema del Sistema de de DSI InformaciónInformación MSI PSI CSI Interfaz ASEGURAMIENTO IAS DE CALIDAD Interfaz InterfazGESTION DE SEGURIDADPROYECTOS Elaborado por Prof. Virginia Juárez - II semestre 78 2010
  • 79. Elaborado por Prof. Virginia Juárez - II semestre 79 2010
  • 80. Elaborado por Prof. Virginia Juárez - II semestre 80 2010
  • 81. Elaborado por Prof. Virginia Juárez - II semestre 81 2010
  • 82. Elaborado por Prof. Virginia Juárez - II semestre 82 2010
  • 83. Elaborado por Prof. Virginia Juárez - II semestre 83 2010
  • 84. Bibliografía Ian Sommerville. “Ingeniería de Software” . Editorial Prentice Hall. Rogger S. Pressman. “Ingeniería de Software: Un Enfoque Práctico”. Editorial Mc Graw – Hill, quinta edición. Jesús Barranco Areba. “Metodologías del Análisis Estructurado de Sistemas” Universidad Pontificia ICAI ICADE; Madrid. Elaborado por Prof. Virginia Juárez - II semestre 84 2010
  • 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. Elaborado por Prof. Virginia Juárez - II semestre 85 2010