SlideShare una empresa de Scribd logo
METODOLOGIAS DE DESARROLLO DE SOFTWARE LIC. ESPINOZA ROBLES ARMANDO DAVID
Conceptos Generales No existe un consenso entre los autores sobre el concepto de metodología. Una primera definición:“ una metodología es un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de softw.” según esto una metodología especifica:
Como se debe dividir un proyecto en etapas que tareas se llevan a cabo en cada etapa que salida se produce y cuanto deben producir que restricciones se aplican que herramientas se van a usar como se gestiona y controla un proyecto atendiendo a una definición mas genérica; “ una metodología es un conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores ha realizar softw.”
De forma general podemos identificar tres necesidades principales que se intenta cubrir con una metodología: mejores aplicaciones un mejor proceso de desarrollo un proceso estándar en la organización  los objetivos de las metodologias son: registrar los requisitos de un SI proporcionar un método sistemático de desarrollo  construir un SI dentro de un tiempo apropiado y costos aceptables
Construir un sistema bien documentado y fácil de mantener identificar lo mas rápido posible cualquier cambio necesario proporcionar un  sistema que satisfaga a todas las personas (clientes, directivos, auditores etc) la descomposición de proceso se realiza a nivel de tareas elementales.  Para cada tarea se identifica un procedimiento. Como resultado se obtiene uno o mas productos. El Sistema esta compuesto de un conjunto de productos finales
Para aplicar un procedimientos se usa una o mas TECNICAS:  suelen ser gráficas con apoyo de texto. Para la realización de una técnica nos apoyamos en Herramientas de Softw. Por ejemplo:  una metodología donde hay una tarea que define un procedimiento para construir un modelo conceptual de datos. Para ello se usa la Técnica de Chen, con la herramienta Power Designer, resultado modelo conceptual de datos
Es necesario aclarar la confusión entre los términos: metodología, método y ciclo de vida. Una metodología puede seguir una o varios modelos de ciclo de vida.  El ciclo de vida indica que es lo que hay que obtener a lo largo del desarrollo pero no como. La metodología si debe indicar como una metodología es un conjunto de métodos.
Al inicio los métodos se centraban en una fase del ciclo de vida: métodos de programación estructurada. Siguiendo los de diseño estructurado, luego análisis estructurado. Luego se establecen métodos conjunto de análisis y diseño estructurado enlazando las dos fases.
Visión del desarrollo de metodologias de desarrollo de SI . Han ido evolucionando a lo largo del tiempo.  Inicialmente periodo de  desarrollo convencional :  practicas artesanales surge el  Desarrollo estructurada : parte de la programación estructurada seguido de los métodos de análisis y diseño. Cubre todo el ciclo de vida completo. Actualmente aparece el paradigma de la  Orientación a objetos. Nuevo enfoque en la Ing.Sft.
Desarrollo Convencional En los años 50 no existía metodologías de desarrollo. El desarrollo estaba a cargo de programadores. Se vio la importancia del análisis y diseño en el desarrollo del sistemas. Aparecen los analistas programadores y analistas de sistemas. Los analistas se dividen en dos: analistas funcionales y analistas técnicos
El enfoque convencional tiene serios problemas, como los siguientes: los resultados finales son impredecibles : no se sabe cuando debe acabar un proyecto. No hay forma d controlar lo que esta sucediendo en el proyecto:  al no existir fases establecidas y productos intermedios sobre los que realizar verificaciones. Los cambios organizativos afectan negativamente al proceso de desarrollo : no suele existir documentación estandarizada o no se actualizan oportunamente.
Desarrollo estructurado El nacimiento de técnicas estructuradas define el punto de partida donde se pasa de la construcción de programas de una forma artesanal a una que sigue unos métodos de ingeniería. El termino programación estructurada se introdujo a finales de los 60 pasando las técnicas al entorno industrial a mediados de los 70
Programación Estructurada el enfoque de desarrollo estructurado comenzó con la programación.  Diseño estructurado: mediados de los 60 el enfoque estructurado se extiende a la fase de diseño, en los que se define una abstracción mas amplia usando los módulos de programa como componentes básicos de construcción.
Diseño Estructurado : se refina concepto de modularidad normalizando la estructura de un modulo de programa, restringiendo las relaciones entre módulos.( Yourdon y Constantine) Análisis Estructurado :  antes de la aparición del análisis estructurado, las especificaciones de requisitos se hacen de manera narrativa.
Análisis estructurado : las especificaciones estaban afectadas por: eran monolíticas : había que leer todas la especificaciones para entender el prob. Eran redundantes : se repetía la misma información en partes diferentes del doc. Eran ambiguas : el enfoque de requisitos se interpretaba diferente por cada usuario. Imposible de mantener : cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.
Por estos inconvenientes había un movimiento gradual hacia las especificaciones funcionales: Gráficas : compuestas por diagramas, apoyados en técnicas textuales. Particionadas : leer de porciones independientes las especificaciones. Mínimamente redundantes : de forma que los cambios afectan a una parte de las especificaciones.
Este enfoque se conoce como análisis estructurado análisis descendente o top - down. Desde su aparición se han hecho mejoras: dar menor importancia a la construcción de  los modelos físicos actuales y a los modelos lógicos actuales diferenciar mas los modelos físicos y lógicos. Ampliar las tec. De análisis estructurado, para modelar sistemas en tiempo real enfocarse en el modelo de datos. Estudio de eventos.a través de lista de eventos.
Cronología de las metodología mas representativas en la historia de la Ing. De Softw. Año Metodología 1968 concepto sobre prog.estructurada  1974 Tec. De prog. Estructurada  1975 primeros conceptos sobre diseño estructurado  1977 primeros conceptos sobre análisis estructurado
Año   Metodología 1978 análisis estructurado 1981 SSADM versión inicial 1985 análisis y diseño estructurado para  sistemas tiempo real  1986 SSADM siguiente versión 1987 análisis diseño estructurado para sistemas tiempo real. 1989 Métrica versión inicial 1990 SSADM siguiente versión
Ano  Metodología 1993 Métrica siguiente versión 1995 Métrica versión actual Desarrollo OO el paradigma de OO trata los procesos y datos de forma conjunta lo OO comienza con los lenguajes de programación LOO en los que se daba énfasis a la abstracción de datos para los que se adjuntaba un conjunto de operaciones.
A partir de mediados de los 80 OO alcanzo gran resonancia. Por otra parte los conceptos de técnicas estructuradas han servido de base para muchas de las metodológicas OO. Así como el diseño de bloques usado en telecomunicaciones y otras de inteligencia artificial e inteligencia del conocimiento.
Características principales de las Metodológias Impacto de la metodología en el entorno de desarrollo de Softw. Todo entorno de desarrollo incluye un conjunto de componentes que condicionan la construcción de softw. La productividad no basta y debe estar asociado a la calidad de los productos finales.
La metodología de desarrollo es el corazón de este entorno e influye muy directamente en estos dos factores ( productividad y calidad)
Entorno de desarrollo de software Organización de desarrollo de software Equipo de desarrollo de software Procedimientos de gestión Metodología de desarrollo Soporte  automatizado Técnicas Da informes a dirección Coordinan y guían Determinan las herramientas necesarias Selección de herramientas Da una estructura visible Soportan métodos
Dentro del entorno la org.mantiene un equipo de desarrollo softw. Los procedimientos de gestión determinan el tipo de soporte automatizado de softw. Y hardw. Los procedimientos de gestión coordinan y guían a los desarrolladores en el empleo de técnicas  el soporte automatizado mejora la productividad.
La organización de desarrollo tiene dos opciones: selección entre un gran numero de métodos de gestión, técnicas de desarrollo y soporte automatizado, para crear y desarrollar la metodología mas apropiada analizar y evaluar las metodologias existentes a adoptar en la organización la que mas se ajuste a sus necesidades. Esta es la mas común.
Características deseables de una metodología 1. Existencia de regalas predefinidas 2. Cobertura total del ciclo de desarrollo 3. Verificaciones intermedias 4. Planificación y control 5. Comunicación efectiva 6. Utilización sobre un abanico de proyectos 7. Fácil formación
8. Herramienta CASE 9. La metodología debe contener actividades que mejoren el proceso de desarrollo 10. Soporte de mantenimiento 11. Soporte de la reutilizacion de softw.
Clasificación de las Metodológias Debe tener en cuenta tres punto de vista o dimensiones. Enfoque   tipo de Siste   formalidad estructurado  gestión  no formal orientado  proc. Orientado datos jerarquico no jerarquico mixtos orientado a obj.  Tiempo real  formal
Metodologias Estructuradas Propone la creación de modelos de sistemas que representan los procesos, los flujos y la estructura de los datos de manera descendente top down se pasa de una visión general del problema (nivel alto de abstracción) hasta llegar a niveles mas sencillos de abstracción
Da lugar a los siguientes tipos de metodológias: orientado a procesos  orientado a datos orientado a estruc. Datos jerárquico orientado a estruc. Dato no jerárquico mixtos
Metodología orientado a procesos La Ing. De Softw., se funda en el modelo básico  entrada / proceso/salida  de un sistema. Este modelo básico lo usan todas las metodologías estructuradas, las que se enfocan en los proceso se llaman orientadas el proceso.
Se basan en métodos descendentes de descomposición funcional para definir los requisitos del sistema. Se apoya en técnicas gráficas dando lugar al concepto de  especificación estructurada  que es un modelo gráfico participando descendente y jerárquico de los procesos del sistema y de los datos usados por el sistema
La especificación estructurada esta compuesta de: Diagrama de flujo de datos : representa los procesos en distintos niveles de descomposición los complejos se descomponen en mas sencillos es la técnica mas importante del análisis estructurado diccionario de datos : definición de todos los datos que aparen en DFD especificaciones de proceso : describe con detalle lo que sucede en un proceso
Actividades de las principales metodologias Metodología de DeMarco: los pasos son: 1. Estudio del entorno físico actual :  modelo del sistema actual con sus procedimientos. A través de un conjunto de DFD 2. Derivación del correspondiente modelo   lógico actual : modelo derivado del anterior sin connotación física. 3. Derivación del nuevo modelo lógico : tomar en cuenta las nuevas necesidades. Formado por un DFD, diccionario de datos y especificaciones de proceso del sistema.
4. Crear un conjunto de modelos físicos  alternativos: del modelo lógico se establecen alternativas se enoje el mas conveniente. 5. Valorar cada opción : costos y beneficios de los modelos físicos. 6. Seleccionar una opción:  selecciona modelo físico 7. Empaquetar la especificación:  se recopila toda la documentación.
Metodología de Gane y Sarson Es el resultado de varios  años de practica en consultoría de análisis y diseño estructurado. Creado por la empresa MCAUTO/IST bajo el nombre de STRADIS SDM. Es parecido al de DEMARCO, la principal diferencia es que hay una etapa en la que se define los contenidos de los almacenes de datos que aparecen en DFD en 3FN.
Diferencias entre metodologias de DeMarco y Gane Sarson Fase del análisis Estructurado Método DeMarco Construir el mod.físico actual DFD físico actual construir mod. Lógico actual DFD lógico actual crear un conjunto de modelos físicos alternativos Método Gane y Sarson construir el Mod. Lógico actual DFD lógico actual construir el mod. Lógico del nuevo sistema: datos en 3FN seleccionar un Mod. logico
Método DeMarco estimar costos y tiempo de cada opción seleccionar un modelo empaquetar la especificación Metod Gane y Sarsan crear nuevo mod. Físico del sistema empaquetar la especificación
Metodología de Yourdon / Constantine Consta de las siguientes fases 1. realizar los DFD del sistema 2. Realizar el diagrama de estructuras a partir del DFD, mediante análisis de transformación, y análisis de transacción. 3. Evaluación del diseño midiendo la calidad de la estructura mediante el acoplamiento y cohesión preparación del diseño para la implementacion dividiendola en Und. Físicas o  cuadernos de carga.
Metodologias Orientados a datos Jerárquicos En el mod. Basico Entrada / Proceso/Salida, esta Metodologia se orienta a las entradas y salidas. Primero se define la estructura del dato, a partir de estos se dividen los componentes procedimentales. Se destaca que:
La estructura de control del programa debe ser jerárquica el proceso de diseño define primero la estructura  de los datos de E/S. Mezclar todos en una estructura jerárquica de programa y luego ordenar la lógica procedimental para que se ajuste a la estructura. El diseño lógico precede y esta separado del físico
Metodologias orientados a datos no Jerarquicos Se divide en cuatro etapas con los siguientes objetivos: Planificación:  construir arquitectura de información y una estrategia que soporte los objetivos de la org. Análisis:  comprender las áreas del negocio y determinar los requisitos del sistema. Diseño : establecer sistema deseado por el usuario y alcanzable por la tec. Construcción : construir un sistema que cumpla lo anterior.
Metodología Orientado a Objetos. En la metodología de análisis y diseño estructurado se examina los sistemas desde las funciones o tareas que deben realizar, que se descomponen sucesivamente en tareas mas pequeñas, para formar los módulos de la aplicación. En OO cobra importancia el aspecto del modelado del sistema examinando el dominio del problema como un conjunto de objetos que interactuan entre si.
En las metodologias tradicionales (estructuradas) se produce una dicotomía entre : función y datos. En OO se propugna un enfoque unificar de ambos espectos que se encapsulan en los objetos. Se puede identificar dos enfoques en metod. OO: revolucionarios o puros: Sintetista o evolutivo:
Sistemas en Tiempo Real Son los sistemas independientes del tiempo que procesan la información, mas orientados al control, se controlan y son controlados por eventos externos. “Sist. Tiempo  Real es aquel que controla un ambiente recibiendo datos procesandolos y devolviendolos con suficiente rapidez como para influir en dicho ambiente en ese momento”
Los sistemas en tiempo real se caracterizan por: Concurrencia Prioridades a determinados procesos existe comunicación entre tareas accesos simultaneo a datos comunes no se debe confundir sistemas en tiempo real y sistemas en línea. Sistemas en línea interactuan con personas sist. Tiempo real interactuan con personas y depósitos físicos del exterior
Para especificar los requisitos de este sistema hay que incluir nuevos conceptos para: manejo de interrupciones comunicación y sincronización de tareas gestionar procesos concurrentes dar respuesta oportuna y a tiempo entre eventos externos datos continuos o discretos
Principales Metodologias de Desarrollo Metodología MERISE : se planteo en 1972. Su primera versión 1976 fue iniciativa del ministerio de industria francés.  Se realizo con apoyo de diversas empresas, el proyecto finalizo 1978 dando lugar al MERISE
La mayor aportación de la metodología es: ciclo de vida mas largo : se incluye la etapa de planificación previa al desarrollo denominada esquema director introducción de 2 ciclos complementarios : ciclo de  abstracción   y ciclo de  decisión . El ciclo de abstracción tiene tres niveles: nivel conceptual : finalidad la empresa nivel organizativo : organización adecuada nivel físico : interrogación medios técnicos
Resultados en los Niveles de MERESI
Fases de la Metodología:  1.  Estudio preliminar : estudia situación existente propone solución global 2.  Estudio detallado 3 . Implementacion : realiza los programas que correspondan, se divide en : estudio técnico: Producción de Programas 4.  Realización y puesta en Marcha
Metodología SSADM A iniciativa del Gob. Británico a principios de los 80 se plantea  estandarizar proyectos de tecnología de información Surge el SSADM: structured Systems Analysis and desing method.
Los aspectos del SSADM  son: énfasis en los usuarios: requisitos y participación definición del proceso de producción: que hacer, como , cuando tres punto de vista : dato, evento, proceso. Máxima flexibilidad en herramientas y técnicas de implementacion. El  SSADM no cubre aspectos como la planificación estratégica ni la construcción del código
Plan. Estra. Estud. De  viabil Anali de Requis Espec logic del sistem Especi de  Requi Diseñ fisico Constr y  prueb Produ Administracion y control Estudio Completo desarrollo SSADM
Metodología Métrica El consejo superior de informática de España en 1989 acuerda realizar el proyecto Métrica en 1993 aparece la versión 2 de Métrica.esta estructurada mediante una sucesión de fases, módulos, actividades y tareas. Indica los productos que se obtienen en cada una de las tareas
Se divide en las siguientes fases: Fase 0 : Plan de sistemas de información Fase 1: Análisis de Sistemas Fase 2: Diseño del sistema Fase 3: Construcción de Sistemas Fase 4 Implementacion de sistemas se enfoca directamente en el desarrollo.
EL PROCESO UNIFICADO VISION GENERAL Es importante primero analizar el proceso para poder ver como funciona un desarrollo OO. Se mostrara una primera visión general del Proceso para tener una idea de cómo llevar a cabo un proyecto
Panorámica del Proceso En la figura se muestra la secuencia al nivel mas alto del proceso de desarrollo unificado. concepción elaboración construcción transicion
Este es un procesó de desarrollo iterativo y gradual, el softw. No se elabora de un solo golpe, sino se libera por partes. La Etapa de construcción : consta de muchas iteraciones en cada una se construye softw.., de calidad, probada e integrado que cumple un subconjunto de requisitos. Cada etapa contiene todas la etapas del ciclo de vida:  Análisis, Diseño, Implementacion, experimentación.
Las dos primeras etapas son de: Concepción Elaboración en este proceso iterativo algunas cosas se dejan para al final la etapa de  transición  como las pruebas Beta , la afinación del desempeño y el entrenamiento al usuario. Los proyectos varían: muy formales en entregas y reuniones o de poca formalidad. Las iteraciones se dan en cada fase, pero centralmente en la fase de construcción.
CONCEPCION : puede adoptar muchas forma, en algunos proyectos una conversación en la cafetería. Para proyectos mayores un amplio estudio de factibilidad de meses. Durante esta etapa se define: la situación económica del proyecto. Costos alcance del proyecto magnitud del proyecto.
En la  concepción , de define si vale la pena dedicar algunos mese de investigación. En este momento el patrocinador del proyecto no se compromete mas que ha una mirada seria del proyecto.
ELABORACION: Se tiene la luz verde para iniciar el proyecto. En esta etapa se pose una vaga idea de los requerimientos. Se plantea la necesidad de comprender mas el problema : ¿Que es lo que va ha construir en realidad ? ¿Como lo va ha construir? ¿Que tecnología empleara?
Al decidir sobre estas interrogantes deberá considerar los riesgos de su proyecto que pueden ser: 1.  Riesgo de requerimientos : entender bien el problema. 2.  Riesgos Tecnológicos : plantea las sig. Preguntas: a) va ha usar objetos:¿tiene suficiente experiencia en OO? B) usara Java, Web: ¿ que también funciona esta tecnología?
3.  Riesgos de Habilidades : ¿puede conseguir la asesoría de expertos necesaria? 4.  Riesgos Políticos : ¿ existen fuerzas Políticas que se interpongan en su camino?
MANEJO DE LOS RIESGOS DE REQUERIMIENTOS: los requerimientos son importantes y en esta metodología los casos de uso son el punto de partida. Los caso de uso son el motor del proceso de desarrollo. Un caso de uso es una iteración entre usuario y sistema. Con el fin de lograr un objetivo
El tamaño del caso de uso puede variar según el problema. La importancia radica en que un caso de uso indica una función que el usuario puede entender y tiene un valor para el. Los caso de uso son la base para la comunicación entre los patrocinadores y los desarrolladores, durante la planificación del proyecto. En la etapa de  elaboración  deben descubrirse los casos de uso principales del SI.
Es poco probable descubrir todos los casos de uso. Se debe contar en los mas importantes. Para lo cual deberá programar entrevistas con los usuarios , para recopilar los caso de uso. Los casos de uso no deben ser muy detallados, la descripción será breve y precisa, para entender la idea básica, para usuarios y desarrolladores.
La otra tarea es elaborar el esqueleto del  Modelo Conceptual del Dominio . El modelo conceptual responde a las preguntas ¿ como se relacionan los objetos entre ellos? Y establece los fundamentos para el modelo de objetos. El concepto  Modelo de Dominio , es el mundo al que da apoyo el Sistema de computo. El Modelo del Dominio y los Casos de Uso capturan los requerimientos
Los modelos de Análisis abarcan las implicancias de estos requerimientos para una aplicación  los modelos de Diseño agregan la  infraestructura interna que hace que funcione la aplicación. El propósito del modelo de Dominio es explorar el vocabulario del dominio en términos comprensibles para los expertos.
Contando con un modelo de  Dominio y un modelo de casos de uso, se desarrolla un  Modelo de Diseño  que reconoce tanto la información en los objetos del dominio como el comportamiento de los casos de uso. El Modelo de Diseño agrega clases que realizan el trabajo y proporcionan una estructura reutilizable.
Se deja correcto las clases de Dominio y los casos de uso importantes, para luego agregar de manera progresiva casos de uso, al modelo de diseño, de forma iterativa. No se debe construir el sistema de golpe. Para construir modelos de Diseño se debe considerar técnicas que proporciona el UML, como: los diagramas de clase : que captura el lenguaje del negocio.
Los diagramas de Actividades : describen el flujo de trabajo del negocio. Elimina secuencias innecesarias en el proceso. Puede también apoyarse en : Diagramas de Interacción. Apoyados en Diagramas  Conceptuales de clase y de actividad se consulta la opinión de los expertos del Dominio, para identificar áreas de riesgo y casos de uso. Consolidar los diversos diagramas en un solo modelo de dominio, que sirve como punto de partida para un diseño de clases en la etapa de construcción.
Si el modelo en muy grande mediante paquetes se divide en partes, consolidando los diag. De clase y actividad. El primer modelo de dominio debe concentrar los detalles mas importantes. El resto se cubrirá durante el desarrollo iterativo. El modelo de Dominio es dirigido por Casos de Uso .
El equipo que construye el dominio debe ser pequeño ( de dos a cuatro personas) durante el periodo de elaboración el líder del proyecto deberá asegurase que el equipo no se empantane en detalles, ni que pierda contacto con la realidad. Para comprender los requerimientos se debe construir prototipos de las partes intrincadas de los casos de uso.
MANEJO DE RIESGOS TECNOLOGICOS: para abarcar los riesgos tecnológicos se debe construir prototipos, que pruebe la tecnología que uno quiere usar. Si trabaja en VB y SQL. Conseguir una versión adecuada del VB con sus herramientas construir partes sencillas del modulo y ver como funciona construir la BD y conectar al VB probar las diversas herramientas .
Los riesgos tecnológicos mayores son los inherentes a la manera como se integran los componentes de un diseño. Concentrese en la áreas que parezca que mas adelante será difícil de cambiar. Preguntese: ¿qué sucederá si no trabaja una pieza de la tecnología ¿qué ocurrirá si no podemos conectar dos piezas del rompecabezas? ¿cuál es la probabilidad de que algo vaya mal? ¿qué haremos si eso sucede?
Se deberá analizar los caso de uso a medida que aparezcan, a fin de ver si tiene algo que pueda echar por tierra su diseño. Los diagramas de clase y de iteración son útiles para mostrar como se comunican los componentes. Los diagramas de paquetes pueden mostrar un cuadro de alto nivel de los componentes  los diagramas de desplazamiento (deployment) proveen una visión panorámica de la distribución de piezas.
MANEJO DE RIESGOS DE HABILIDAD : el principal riesgo es iniciar un proyecto OO sin la suficiente experiencia.  Los directivos se preocupan por los costos del entrenamiento pero se paga hasta el ultimo centavo cuando se alargan los proyectos. El entrenamiento es una manera de evitar errores, cometerlos consume tiempo y cuesta
Lo adecuado son cursos de entrenamiento breve, brindados por instructores capaces, por partes en el momento que se necesite, y poner en practica lo aprendido. La mejor manera de adquirir las habilidades en OO es a través del método de tutoría, contratarlos para áreas especificas o todo el proyecto. También podrá completar sus habilidades mediante la lecturas. Constituir grupos técnico  de estudio
BASE ARQUTECTONICA se compone de: la lista de casos de uso , que le dice cuales son los requerimientos. El modelo del dominio  : compuesto de lo que se entiende del negocio. Sirve para armar las clases. La plataforma tecnológica. Esta arquitectura es el cimiento del desarrollo y funciona como ante proyecto.
CUANDO TERMINA LA ELABORACION : la elaboración consume una quinta parte de la duración  del proyecto Dos circunstancias son indicadores claves que señalan que se ha completado la elaboración: los desarrolladores pueden tener la confianza necesaria para dar estimaciones. Se han identificado todos los riesgos significativos, se sabe como tratarlos

Más contenido relacionado

La actualidad más candente

Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4
Enrique Barreiro
 
Fcaps
FcapsFcaps
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
Camila Arbelaez
 
Desarrollo iterativo e incremental
Desarrollo iterativo e incrementalDesarrollo iterativo e incremental
Desarrollo iterativo e incremental
noriver
 
Herramientas case alto y bajo nivel
Herramientas case alto y bajo nivelHerramientas case alto y bajo nivel
Herramientas case alto y bajo nivel
sistemaaabbbb
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdencies
MICProductivity
 
Bootstrap
Bootstrap Bootstrap
Bootstrap
lizethmunoz
 
GestióN De Proyectos Software
GestióN De Proyectos SoftwareGestióN De Proyectos Software
GestióN De Proyectos Software
UCPR
 
Modelo furps
Modelo furpsModelo furps
Modelo furps
Leo Ruelas Rojas
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
Sandrea Rodriguez
 
Presentacion MSF
Presentacion MSFPresentacion MSF
Presentacion MSF
Felipe Lozano Leon
 
ITIL
ITILITIL
Metodologia de desarrollo de software
Metodologia de desarrollo de softwareMetodologia de desarrollo de software
Metodologia de desarrollo de software
Victor Varela
 
modelos de calidad de software
modelos de calidad de softwaremodelos de calidad de software
modelos de calidad de software
Hernan Espinoza
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
Wilfredo Mogollón
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de software
Lorena Quiñónez
 
Historia delas bases de datos orientada a objetos.
Historia delas bases de datos orientada a objetos.Historia delas bases de datos orientada a objetos.
Historia delas bases de datos orientada a objetos.
Noel Ruiz Gimenez
 
Ieee 1074
Ieee 1074Ieee 1074
Ieee 1074
Juan Restrepo
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
Reivaj Sagarv
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
MARCO POLO SILVA SEGOVIA
 

La actualidad más candente (20)

Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4Ingeniería del Software de Gestión. Tema 4
Ingeniería del Software de Gestión. Tema 4
 
Fcaps
FcapsFcaps
Fcaps
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Desarrollo iterativo e incremental
Desarrollo iterativo e incrementalDesarrollo iterativo e incremental
Desarrollo iterativo e incremental
 
Herramientas case alto y bajo nivel
Herramientas case alto y bajo nivelHerramientas case alto y bajo nivel
Herramientas case alto y bajo nivel
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdencies
 
Bootstrap
Bootstrap Bootstrap
Bootstrap
 
GestióN De Proyectos Software
GestióN De Proyectos SoftwareGestióN De Proyectos Software
GestióN De Proyectos Software
 
Modelo furps
Modelo furpsModelo furps
Modelo furps
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
 
Presentacion MSF
Presentacion MSFPresentacion MSF
Presentacion MSF
 
ITIL
ITILITIL
ITIL
 
Metodologia de desarrollo de software
Metodologia de desarrollo de softwareMetodologia de desarrollo de software
Metodologia de desarrollo de software
 
modelos de calidad de software
modelos de calidad de softwaremodelos de calidad de software
modelos de calidad de software
 
Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
 
Métricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de softwareMétricas de Proceso y proyecto de software
Métricas de Proceso y proyecto de software
 
Historia delas bases de datos orientada a objetos.
Historia delas bases de datos orientada a objetos.Historia delas bases de datos orientada a objetos.
Historia delas bases de datos orientada a objetos.
 
Ieee 1074
Ieee 1074Ieee 1074
Ieee 1074
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
 

Destacado

Metodologias De Desarrollo De Software
Metodologias De Desarrollo De SoftwareMetodologias De Desarrollo De Software
Metodologias De Desarrollo De Software
guesta1695670
 
Metología Agiles Desarrollo Software (XP)
Metología Agiles Desarrollo Software (XP)Metología Agiles Desarrollo Software (XP)
Metología Agiles Desarrollo Software (XP)
Tuyo Mio
 
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARECLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
BiingeSof
 
Metodologias agiles Programacion Xtrema
Metodologias agiles Programacion Xtrema Metodologias agiles Programacion Xtrema
Metodologias agiles Programacion Xtrema
Lis Pater
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
ElvisAR
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrollo
Hermes Romero
 
Definicion de usuarios
Definicion de usuariosDefinicion de usuarios
Definicion de usuarios
samazu2012
 

Destacado (7)

Metodologias De Desarrollo De Software
Metodologias De Desarrollo De SoftwareMetodologias De Desarrollo De Software
Metodologias De Desarrollo De Software
 
Metología Agiles Desarrollo Software (XP)
Metología Agiles Desarrollo Software (XP)Metología Agiles Desarrollo Software (XP)
Metología Agiles Desarrollo Software (XP)
 
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARECLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
CLASIFICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE
 
Metodologias agiles Programacion Xtrema
Metodologias agiles Programacion Xtrema Metodologias agiles Programacion Xtrema
Metodologias agiles Programacion Xtrema
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrollo
 
Definicion de usuarios
Definicion de usuariosDefinicion de usuarios
Definicion de usuarios
 

Similar a 4 Clase Metodologia De Desarrolo De Software

Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
waralivt
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
waralivt
 
28731.ppt
28731.ppt28731.ppt
¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software
JorgeArmijosC
 
Metodologías para desarrollo de software
Metodologías para desarrollo de softwareMetodologías para desarrollo de software
Metodologías para desarrollo de software
Abner Garcia
 
Metodologia y prototipo
Metodologia y prototipoMetodologia y prototipo
Metodologia y prototipo
Arturo Jimenez
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
Luis R Inciarte
 
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfclasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
CESARAS4
 
Metodologia
MetodologiaMetodologia
Analisis y diseños de sistemas
Analisis y diseños de sistemasAnalisis y diseños de sistemas
Analisis y diseños de sistemas
victor rodriguez
 
METODOLOGIAS.pptx
METODOLOGIAS.pptxMETODOLOGIAS.pptx
METODOLOGIAS.pptx
juan gonzalez
 
Metodologia estructurada
Metodologia estructuradaMetodologia estructurada
Metodologia estructurada
M'elver Melende'z
 
Monografia
MonografiaMonografia
Monografia
Hulder Armuto
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemas
Eliset Gonzales Uceda
 
Administracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantesAdministracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantes
Cyber Brel'R
 
las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas
Adriana Devera
 
Instituto tecnologio spencer w
Instituto tecnologio spencer wInstituto tecnologio spencer w
Instituto tecnologio spencer w
Abner Garcia
 
Informe de Christian Oblitas
Informe de Christian OblitasInforme de Christian Oblitas
Informe de Christian Oblitas
Christian1705
 
Informe de christian oblitas
Informe de christian oblitasInforme de christian oblitas
Informe de christian oblitas
Christian1705
 
Sia i cap7
Sia i cap7Sia i cap7
Sia i cap7
Carlos Gonzalez
 

Similar a 4 Clase Metodologia De Desarrolo De Software (20)

Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
28731.ppt
28731.ppt28731.ppt
28731.ppt
 
¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software
 
Metodologías para desarrollo de software
Metodologías para desarrollo de softwareMetodologías para desarrollo de software
Metodologías para desarrollo de software
 
Metodologia y prototipo
Metodologia y prototipoMetodologia y prototipo
Metodologia y prototipo
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
 
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfclasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
 
Metodologia
MetodologiaMetodologia
Metodologia
 
Analisis y diseños de sistemas
Analisis y diseños de sistemasAnalisis y diseños de sistemas
Analisis y diseños de sistemas
 
METODOLOGIAS.pptx
METODOLOGIAS.pptxMETODOLOGIAS.pptx
METODOLOGIAS.pptx
 
Metodologia estructurada
Metodologia estructuradaMetodologia estructurada
Metodologia estructurada
 
Monografia
MonografiaMonografia
Monografia
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemas
 
Administracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantesAdministracion de proyectos software i estudiantes
Administracion de proyectos software i estudiantes
 
las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas
 
Instituto tecnologio spencer w
Instituto tecnologio spencer wInstituto tecnologio spencer w
Instituto tecnologio spencer w
 
Informe de Christian Oblitas
Informe de Christian OblitasInforme de Christian Oblitas
Informe de Christian Oblitas
 
Informe de christian oblitas
Informe de christian oblitasInforme de christian oblitas
Informe de christian oblitas
 
Sia i cap7
Sia i cap7Sia i cap7
Sia i cap7
 

Más de Julio Pari

Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Julio Pari
 
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesLinks kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Julio Pari
 
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesComandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Julio Pari
 
Indice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCIndice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPC
Julio Pari
 
Arquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMArquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSM
Julio Pari
 
Jelastic Enterprise
Jelastic EnterpriseJelastic Enterprise
Jelastic Enterprise
Julio Pari
 
Marketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor OsorioMarketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor Osorio
Julio Pari
 
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor CorderoIngenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
Julio Pari
 
Documento de Arquitectura
Documento de ArquitecturaDocumento de Arquitectura
Documento de Arquitectura
Julio Pari
 
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISISolucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
Julio Pari
 
Práctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa IIPráctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa II
Julio Pari
 
Armas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilasArmas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilas
Julio Pari
 
UML Java
UML JavaUML Java
UML Java
Julio Pari
 
Formato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISIFormato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISI
Julio Pari
 
Cuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hijaCuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hija
Julio Pari
 
Ingeniería de Software Examen Parcial
Ingeniería de Software Examen ParcialIngeniería de Software Examen Parcial
Ingeniería de Software Examen Parcial
Julio Pari
 
Sistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen ParcialSistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen Parcial
Julio Pari
 
Php07 consultas bd
Php07 consultas bdPhp07 consultas bd
Php07 consultas bd
Julio Pari
 
Php06 instalacion my_sql
Php06 instalacion my_sqlPhp06 instalacion my_sql
Php06 instalacion my_sql
Julio Pari
 
Php05 funciones usuario
Php05 funciones usuarioPhp05 funciones usuario
Php05 funciones usuario
Julio Pari
 

Más de Julio Pari (20)

Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...
 
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesLinks kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
 
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesComandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes
 
Indice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPCIndice General Tesis Sistemas UPC
Indice General Tesis Sistemas UPC
 
Arquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSMArquitectura Web FISI UNMSM
Arquitectura Web FISI UNMSM
 
Jelastic Enterprise
Jelastic EnterpriseJelastic Enterprise
Jelastic Enterprise
 
Marketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor OsorioMarketing Examen Parcial Profesor Osorio
Marketing Examen Parcial Profesor Osorio
 
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor CorderoIngenieria Software Examen Parcial 2013 2 Profesor Cordero
Ingenieria Software Examen Parcial 2013 2 Profesor Cordero
 
Documento de Arquitectura
Documento de ArquitecturaDocumento de Arquitectura
Documento de Arquitectura
 
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISISolucion Examen Parcial Sistemas Digitales UNMSM FISI
Solucion Examen Parcial Sistemas Digitales UNMSM FISI
 
Práctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa IIPráctica de Inventarios - Investigación Operativa II
Práctica de Inventarios - Investigación Operativa II
 
Armas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilasArmas silenciosas para guerras tranquilas
Armas silenciosas para guerras tranquilas
 
UML Java
UML JavaUML Java
UML Java
 
Formato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISIFormato de presentación de Proyecto UNMSM FISI
Formato de presentación de Proyecto UNMSM FISI
 
Cuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hijaCuento para nuestro hijo y nuestra hija
Cuento para nuestro hijo y nuestra hija
 
Ingeniería de Software Examen Parcial
Ingeniería de Software Examen ParcialIngeniería de Software Examen Parcial
Ingeniería de Software Examen Parcial
 
Sistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen ParcialSistemas Distribuidos Examen Parcial
Sistemas Distribuidos Examen Parcial
 
Php07 consultas bd
Php07 consultas bdPhp07 consultas bd
Php07 consultas bd
 
Php06 instalacion my_sql
Php06 instalacion my_sqlPhp06 instalacion my_sql
Php06 instalacion my_sql
 
Php05 funciones usuario
Php05 funciones usuarioPhp05 funciones usuario
Php05 funciones usuario
 

Último

11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf
PanchoChangue
 
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
241578066
 
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptxDiapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
GnesisOrtegaDeLen
 
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdfBIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
sunwndniel
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
gregory760891
 
bomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexionesbomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexiones
JessAdrinGonzlezCade
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
Katia Reyes
 
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docxSEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
Eddy Nathaly Jaimes Villamizar
 
Informe_mc_bombas_Warman_001-WEIR vulco.pdf
Informe_mc_bombas_Warman_001-WEIR vulco.pdfInforme_mc_bombas_Warman_001-WEIR vulco.pdf
Informe_mc_bombas_Warman_001-WEIR vulco.pdf
Rubén Cortes Zavala
 
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
sunwndniel
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
correodetareas
 
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdfInforme de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
KEVINYOICIAQUINOSORI
 
Conceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagaciónConceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagación
edgarcalle8
 
aplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geograficoaplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geografico
cyberquiximies
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
bellomiguelangel68
 
Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
Henry W. Zavala
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
walter729637
 
Transporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdfTransporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdf
milagrosAlbanPacherr
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
MenaOlortinYherlyEli
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
estudios22
 

Último (20)

11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf11. Legislación Aplicada a la Informática.pdf
11. Legislación Aplicada a la Informática.pdf
 
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
"El uso de las TIC en la vida cotidiana". SantanaMartinez_Alejandra
 
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptxDiapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
Diapositiva sobre Tecnologia de la Información y Telecomunicaciones.pptx
 
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdfBIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
BIOSENSORES BASADOS EN NANOTECNOLOGÍA.pdf
 
Generaciones de Computadoras .
Generaciones de Computadoras                 .Generaciones de Computadoras                 .
Generaciones de Computadoras .
 
bomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexionesbomba-koomey -Todo sobre sus istema y conexiones
bomba-koomey -Todo sobre sus istema y conexiones
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
 
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docxSEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
SEGUNDA GENERACIÓN xxxxxxxxxxxxxxxx.docx
 
Informe_mc_bombas_Warman_001-WEIR vulco.pdf
Informe_mc_bombas_Warman_001-WEIR vulco.pdfInforme_mc_bombas_Warman_001-WEIR vulco.pdf
Informe_mc_bombas_Warman_001-WEIR vulco.pdf
 
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
Reconocimiento del Secuenciador de nanoporos (Nanopore sequencing) MinIon Mk1...
 
_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf_Manejo de Riesgos en el Laboratorio.pdf
_Manejo de Riesgos en el Laboratorio.pdf
 
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdfInforme de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
Informe de electroforesis del ADN MEDIANTE EL MinION Mk1C.pdf
 
Conceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagaciónConceptos y definiciones de Antenas y propagación
Conceptos y definiciones de Antenas y propagación
 
aplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geograficoaplicaciones de sistema de informacion geografico
aplicaciones de sistema de informacion geografico
 
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
2 FIBRA OPTICA COMO MEDIO DE RED DE ACCESO.pptx
 
Evolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TICEvolución, características, aplicación, ventajas y desventajas de las TIC
Evolución, características, aplicación, ventajas y desventajas de las TIC
 
Catalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdfCatalogo-Voxtech- accesorios radios RF.pdf
Catalogo-Voxtech- accesorios radios RF.pdf
 
Transporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdfTransporte a través del tiempo en el perú.pdf
Transporte a través del tiempo en el perú.pdf
 
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
TESisssssssss de yhnnjuuhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj...
 
DN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en PerúDN Consultores | Una mirada al mercado de fibra en Perú
DN Consultores | Una mirada al mercado de fibra en Perú
 

4 Clase Metodologia De Desarrolo De Software

  • 1. METODOLOGIAS DE DESARROLLO DE SOFTWARE LIC. ESPINOZA ROBLES ARMANDO DAVID
  • 2. Conceptos Generales No existe un consenso entre los autores sobre el concepto de metodología. Una primera definición:“ una metodología es un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de softw.” según esto una metodología especifica:
  • 3. Como se debe dividir un proyecto en etapas que tareas se llevan a cabo en cada etapa que salida se produce y cuanto deben producir que restricciones se aplican que herramientas se van a usar como se gestiona y controla un proyecto atendiendo a una definición mas genérica; “ una metodología es un conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores ha realizar softw.”
  • 4. De forma general podemos identificar tres necesidades principales que se intenta cubrir con una metodología: mejores aplicaciones un mejor proceso de desarrollo un proceso estándar en la organización los objetivos de las metodologias son: registrar los requisitos de un SI proporcionar un método sistemático de desarrollo construir un SI dentro de un tiempo apropiado y costos aceptables
  • 5. Construir un sistema bien documentado y fácil de mantener identificar lo mas rápido posible cualquier cambio necesario proporcionar un sistema que satisfaga a todas las personas (clientes, directivos, auditores etc) la descomposición de proceso se realiza a nivel de tareas elementales. Para cada tarea se identifica un procedimiento. Como resultado se obtiene uno o mas productos. El Sistema esta compuesto de un conjunto de productos finales
  • 6. Para aplicar un procedimientos se usa una o mas TECNICAS: suelen ser gráficas con apoyo de texto. Para la realización de una técnica nos apoyamos en Herramientas de Softw. Por ejemplo: una metodología donde hay una tarea que define un procedimiento para construir un modelo conceptual de datos. Para ello se usa la Técnica de Chen, con la herramienta Power Designer, resultado modelo conceptual de datos
  • 7. Es necesario aclarar la confusión entre los términos: metodología, método y ciclo de vida. Una metodología puede seguir una o varios modelos de ciclo de vida. El ciclo de vida indica que es lo que hay que obtener a lo largo del desarrollo pero no como. La metodología si debe indicar como una metodología es un conjunto de métodos.
  • 8. Al inicio los métodos se centraban en una fase del ciclo de vida: métodos de programación estructurada. Siguiendo los de diseño estructurado, luego análisis estructurado. Luego se establecen métodos conjunto de análisis y diseño estructurado enlazando las dos fases.
  • 9. Visión del desarrollo de metodologias de desarrollo de SI . Han ido evolucionando a lo largo del tiempo. Inicialmente periodo de desarrollo convencional : practicas artesanales surge el Desarrollo estructurada : parte de la programación estructurada seguido de los métodos de análisis y diseño. Cubre todo el ciclo de vida completo. Actualmente aparece el paradigma de la Orientación a objetos. Nuevo enfoque en la Ing.Sft.
  • 10. Desarrollo Convencional En los años 50 no existía metodologías de desarrollo. El desarrollo estaba a cargo de programadores. Se vio la importancia del análisis y diseño en el desarrollo del sistemas. Aparecen los analistas programadores y analistas de sistemas. Los analistas se dividen en dos: analistas funcionales y analistas técnicos
  • 11. El enfoque convencional tiene serios problemas, como los siguientes: los resultados finales son impredecibles : no se sabe cuando debe acabar un proyecto. No hay forma d controlar lo que esta sucediendo en el proyecto: al no existir fases establecidas y productos intermedios sobre los que realizar verificaciones. Los cambios organizativos afectan negativamente al proceso de desarrollo : no suele existir documentación estandarizada o no se actualizan oportunamente.
  • 12. Desarrollo estructurado El nacimiento de técnicas estructuradas define el punto de partida donde se pasa de la construcción de programas de una forma artesanal a una que sigue unos métodos de ingeniería. El termino programación estructurada se introdujo a finales de los 60 pasando las técnicas al entorno industrial a mediados de los 70
  • 13. Programación Estructurada el enfoque de desarrollo estructurado comenzó con la programación. Diseño estructurado: mediados de los 60 el enfoque estructurado se extiende a la fase de diseño, en los que se define una abstracción mas amplia usando los módulos de programa como componentes básicos de construcción.
  • 14. Diseño Estructurado : se refina concepto de modularidad normalizando la estructura de un modulo de programa, restringiendo las relaciones entre módulos.( Yourdon y Constantine) Análisis Estructurado : antes de la aparición del análisis estructurado, las especificaciones de requisitos se hacen de manera narrativa.
  • 15. Análisis estructurado : las especificaciones estaban afectadas por: eran monolíticas : había que leer todas la especificaciones para entender el prob. Eran redundantes : se repetía la misma información en partes diferentes del doc. Eran ambiguas : el enfoque de requisitos se interpretaba diferente por cada usuario. Imposible de mantener : cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.
  • 16. Por estos inconvenientes había un movimiento gradual hacia las especificaciones funcionales: Gráficas : compuestas por diagramas, apoyados en técnicas textuales. Particionadas : leer de porciones independientes las especificaciones. Mínimamente redundantes : de forma que los cambios afectan a una parte de las especificaciones.
  • 17. Este enfoque se conoce como análisis estructurado análisis descendente o top - down. Desde su aparición se han hecho mejoras: dar menor importancia a la construcción de los modelos físicos actuales y a los modelos lógicos actuales diferenciar mas los modelos físicos y lógicos. Ampliar las tec. De análisis estructurado, para modelar sistemas en tiempo real enfocarse en el modelo de datos. Estudio de eventos.a través de lista de eventos.
  • 18. Cronología de las metodología mas representativas en la historia de la Ing. De Softw. Año Metodología 1968 concepto sobre prog.estructurada 1974 Tec. De prog. Estructurada 1975 primeros conceptos sobre diseño estructurado 1977 primeros conceptos sobre análisis estructurado
  • 19. Año Metodología 1978 análisis estructurado 1981 SSADM versión inicial 1985 análisis y diseño estructurado para sistemas tiempo real 1986 SSADM siguiente versión 1987 análisis diseño estructurado para sistemas tiempo real. 1989 Métrica versión inicial 1990 SSADM siguiente versión
  • 20. Ano Metodología 1993 Métrica siguiente versión 1995 Métrica versión actual Desarrollo OO el paradigma de OO trata los procesos y datos de forma conjunta lo OO comienza con los lenguajes de programación LOO en los que se daba énfasis a la abstracción de datos para los que se adjuntaba un conjunto de operaciones.
  • 21. A partir de mediados de los 80 OO alcanzo gran resonancia. Por otra parte los conceptos de técnicas estructuradas han servido de base para muchas de las metodológicas OO. Así como el diseño de bloques usado en telecomunicaciones y otras de inteligencia artificial e inteligencia del conocimiento.
  • 22. Características principales de las Metodológias Impacto de la metodología en el entorno de desarrollo de Softw. Todo entorno de desarrollo incluye un conjunto de componentes que condicionan la construcción de softw. La productividad no basta y debe estar asociado a la calidad de los productos finales.
  • 23. La metodología de desarrollo es el corazón de este entorno e influye muy directamente en estos dos factores ( productividad y calidad)
  • 24. Entorno de desarrollo de software Organización de desarrollo de software Equipo de desarrollo de software Procedimientos de gestión Metodología de desarrollo Soporte automatizado Técnicas Da informes a dirección Coordinan y guían Determinan las herramientas necesarias Selección de herramientas Da una estructura visible Soportan métodos
  • 25. Dentro del entorno la org.mantiene un equipo de desarrollo softw. Los procedimientos de gestión determinan el tipo de soporte automatizado de softw. Y hardw. Los procedimientos de gestión coordinan y guían a los desarrolladores en el empleo de técnicas el soporte automatizado mejora la productividad.
  • 26. La organización de desarrollo tiene dos opciones: selección entre un gran numero de métodos de gestión, técnicas de desarrollo y soporte automatizado, para crear y desarrollar la metodología mas apropiada analizar y evaluar las metodologias existentes a adoptar en la organización la que mas se ajuste a sus necesidades. Esta es la mas común.
  • 27. Características deseables de una metodología 1. Existencia de regalas predefinidas 2. Cobertura total del ciclo de desarrollo 3. Verificaciones intermedias 4. Planificación y control 5. Comunicación efectiva 6. Utilización sobre un abanico de proyectos 7. Fácil formación
  • 28. 8. Herramienta CASE 9. La metodología debe contener actividades que mejoren el proceso de desarrollo 10. Soporte de mantenimiento 11. Soporte de la reutilizacion de softw.
  • 29. Clasificación de las Metodológias Debe tener en cuenta tres punto de vista o dimensiones. Enfoque tipo de Siste formalidad estructurado gestión no formal orientado proc. Orientado datos jerarquico no jerarquico mixtos orientado a obj. Tiempo real formal
  • 30. Metodologias Estructuradas Propone la creación de modelos de sistemas que representan los procesos, los flujos y la estructura de los datos de manera descendente top down se pasa de una visión general del problema (nivel alto de abstracción) hasta llegar a niveles mas sencillos de abstracción
  • 31. Da lugar a los siguientes tipos de metodológias: orientado a procesos orientado a datos orientado a estruc. Datos jerárquico orientado a estruc. Dato no jerárquico mixtos
  • 32. Metodología orientado a procesos La Ing. De Softw., se funda en el modelo básico entrada / proceso/salida de un sistema. Este modelo básico lo usan todas las metodologías estructuradas, las que se enfocan en los proceso se llaman orientadas el proceso.
  • 33. Se basan en métodos descendentes de descomposición funcional para definir los requisitos del sistema. Se apoya en técnicas gráficas dando lugar al concepto de especificación estructurada que es un modelo gráfico participando descendente y jerárquico de los procesos del sistema y de los datos usados por el sistema
  • 34. La especificación estructurada esta compuesta de: Diagrama de flujo de datos : representa los procesos en distintos niveles de descomposición los complejos se descomponen en mas sencillos es la técnica mas importante del análisis estructurado diccionario de datos : definición de todos los datos que aparen en DFD especificaciones de proceso : describe con detalle lo que sucede en un proceso
  • 35. Actividades de las principales metodologias Metodología de DeMarco: los pasos son: 1. Estudio del entorno físico actual : modelo del sistema actual con sus procedimientos. A través de un conjunto de DFD 2. Derivación del correspondiente modelo lógico actual : modelo derivado del anterior sin connotación física. 3. Derivación del nuevo modelo lógico : tomar en cuenta las nuevas necesidades. Formado por un DFD, diccionario de datos y especificaciones de proceso del sistema.
  • 36. 4. Crear un conjunto de modelos físicos alternativos: del modelo lógico se establecen alternativas se enoje el mas conveniente. 5. Valorar cada opción : costos y beneficios de los modelos físicos. 6. Seleccionar una opción: selecciona modelo físico 7. Empaquetar la especificación: se recopila toda la documentación.
  • 37. Metodología de Gane y Sarson Es el resultado de varios años de practica en consultoría de análisis y diseño estructurado. Creado por la empresa MCAUTO/IST bajo el nombre de STRADIS SDM. Es parecido al de DEMARCO, la principal diferencia es que hay una etapa en la que se define los contenidos de los almacenes de datos que aparecen en DFD en 3FN.
  • 38. Diferencias entre metodologias de DeMarco y Gane Sarson Fase del análisis Estructurado Método DeMarco Construir el mod.físico actual DFD físico actual construir mod. Lógico actual DFD lógico actual crear un conjunto de modelos físicos alternativos Método Gane y Sarson construir el Mod. Lógico actual DFD lógico actual construir el mod. Lógico del nuevo sistema: datos en 3FN seleccionar un Mod. logico
  • 39. Método DeMarco estimar costos y tiempo de cada opción seleccionar un modelo empaquetar la especificación Metod Gane y Sarsan crear nuevo mod. Físico del sistema empaquetar la especificación
  • 40. Metodología de Yourdon / Constantine Consta de las siguientes fases 1. realizar los DFD del sistema 2. Realizar el diagrama de estructuras a partir del DFD, mediante análisis de transformación, y análisis de transacción. 3. Evaluación del diseño midiendo la calidad de la estructura mediante el acoplamiento y cohesión preparación del diseño para la implementacion dividiendola en Und. Físicas o cuadernos de carga.
  • 41. Metodologias Orientados a datos Jerárquicos En el mod. Basico Entrada / Proceso/Salida, esta Metodologia se orienta a las entradas y salidas. Primero se define la estructura del dato, a partir de estos se dividen los componentes procedimentales. Se destaca que:
  • 42. La estructura de control del programa debe ser jerárquica el proceso de diseño define primero la estructura de los datos de E/S. Mezclar todos en una estructura jerárquica de programa y luego ordenar la lógica procedimental para que se ajuste a la estructura. El diseño lógico precede y esta separado del físico
  • 43. Metodologias orientados a datos no Jerarquicos Se divide en cuatro etapas con los siguientes objetivos: Planificación: construir arquitectura de información y una estrategia que soporte los objetivos de la org. Análisis: comprender las áreas del negocio y determinar los requisitos del sistema. Diseño : establecer sistema deseado por el usuario y alcanzable por la tec. Construcción : construir un sistema que cumpla lo anterior.
  • 44. Metodología Orientado a Objetos. En la metodología de análisis y diseño estructurado se examina los sistemas desde las funciones o tareas que deben realizar, que se descomponen sucesivamente en tareas mas pequeñas, para formar los módulos de la aplicación. En OO cobra importancia el aspecto del modelado del sistema examinando el dominio del problema como un conjunto de objetos que interactuan entre si.
  • 45. En las metodologias tradicionales (estructuradas) se produce una dicotomía entre : función y datos. En OO se propugna un enfoque unificar de ambos espectos que se encapsulan en los objetos. Se puede identificar dos enfoques en metod. OO: revolucionarios o puros: Sintetista o evolutivo:
  • 46. Sistemas en Tiempo Real Son los sistemas independientes del tiempo que procesan la información, mas orientados al control, se controlan y son controlados por eventos externos. “Sist. Tiempo Real es aquel que controla un ambiente recibiendo datos procesandolos y devolviendolos con suficiente rapidez como para influir en dicho ambiente en ese momento”
  • 47. Los sistemas en tiempo real se caracterizan por: Concurrencia Prioridades a determinados procesos existe comunicación entre tareas accesos simultaneo a datos comunes no se debe confundir sistemas en tiempo real y sistemas en línea. Sistemas en línea interactuan con personas sist. Tiempo real interactuan con personas y depósitos físicos del exterior
  • 48. Para especificar los requisitos de este sistema hay que incluir nuevos conceptos para: manejo de interrupciones comunicación y sincronización de tareas gestionar procesos concurrentes dar respuesta oportuna y a tiempo entre eventos externos datos continuos o discretos
  • 49. Principales Metodologias de Desarrollo Metodología MERISE : se planteo en 1972. Su primera versión 1976 fue iniciativa del ministerio de industria francés. Se realizo con apoyo de diversas empresas, el proyecto finalizo 1978 dando lugar al MERISE
  • 50. La mayor aportación de la metodología es: ciclo de vida mas largo : se incluye la etapa de planificación previa al desarrollo denominada esquema director introducción de 2 ciclos complementarios : ciclo de abstracción y ciclo de decisión . El ciclo de abstracción tiene tres niveles: nivel conceptual : finalidad la empresa nivel organizativo : organización adecuada nivel físico : interrogación medios técnicos
  • 51. Resultados en los Niveles de MERESI
  • 52. Fases de la Metodología: 1. Estudio preliminar : estudia situación existente propone solución global 2. Estudio detallado 3 . Implementacion : realiza los programas que correspondan, se divide en : estudio técnico: Producción de Programas 4. Realización y puesta en Marcha
  • 53. Metodología SSADM A iniciativa del Gob. Británico a principios de los 80 se plantea estandarizar proyectos de tecnología de información Surge el SSADM: structured Systems Analysis and desing method.
  • 54. Los aspectos del SSADM son: énfasis en los usuarios: requisitos y participación definición del proceso de producción: que hacer, como , cuando tres punto de vista : dato, evento, proceso. Máxima flexibilidad en herramientas y técnicas de implementacion. El SSADM no cubre aspectos como la planificación estratégica ni la construcción del código
  • 55. Plan. Estra. Estud. De viabil Anali de Requis Espec logic del sistem Especi de Requi Diseñ fisico Constr y prueb Produ Administracion y control Estudio Completo desarrollo SSADM
  • 56. Metodología Métrica El consejo superior de informática de España en 1989 acuerda realizar el proyecto Métrica en 1993 aparece la versión 2 de Métrica.esta estructurada mediante una sucesión de fases, módulos, actividades y tareas. Indica los productos que se obtienen en cada una de las tareas
  • 57. Se divide en las siguientes fases: Fase 0 : Plan de sistemas de información Fase 1: Análisis de Sistemas Fase 2: Diseño del sistema Fase 3: Construcción de Sistemas Fase 4 Implementacion de sistemas se enfoca directamente en el desarrollo.
  • 58. EL PROCESO UNIFICADO VISION GENERAL Es importante primero analizar el proceso para poder ver como funciona un desarrollo OO. Se mostrara una primera visión general del Proceso para tener una idea de cómo llevar a cabo un proyecto
  • 59. Panorámica del Proceso En la figura se muestra la secuencia al nivel mas alto del proceso de desarrollo unificado. concepción elaboración construcción transicion
  • 60. Este es un procesó de desarrollo iterativo y gradual, el softw. No se elabora de un solo golpe, sino se libera por partes. La Etapa de construcción : consta de muchas iteraciones en cada una se construye softw.., de calidad, probada e integrado que cumple un subconjunto de requisitos. Cada etapa contiene todas la etapas del ciclo de vida: Análisis, Diseño, Implementacion, experimentación.
  • 61. Las dos primeras etapas son de: Concepción Elaboración en este proceso iterativo algunas cosas se dejan para al final la etapa de transición como las pruebas Beta , la afinación del desempeño y el entrenamiento al usuario. Los proyectos varían: muy formales en entregas y reuniones o de poca formalidad. Las iteraciones se dan en cada fase, pero centralmente en la fase de construcción.
  • 62. CONCEPCION : puede adoptar muchas forma, en algunos proyectos una conversación en la cafetería. Para proyectos mayores un amplio estudio de factibilidad de meses. Durante esta etapa se define: la situación económica del proyecto. Costos alcance del proyecto magnitud del proyecto.
  • 63. En la concepción , de define si vale la pena dedicar algunos mese de investigación. En este momento el patrocinador del proyecto no se compromete mas que ha una mirada seria del proyecto.
  • 64. ELABORACION: Se tiene la luz verde para iniciar el proyecto. En esta etapa se pose una vaga idea de los requerimientos. Se plantea la necesidad de comprender mas el problema : ¿Que es lo que va ha construir en realidad ? ¿Como lo va ha construir? ¿Que tecnología empleara?
  • 65. Al decidir sobre estas interrogantes deberá considerar los riesgos de su proyecto que pueden ser: 1. Riesgo de requerimientos : entender bien el problema. 2. Riesgos Tecnológicos : plantea las sig. Preguntas: a) va ha usar objetos:¿tiene suficiente experiencia en OO? B) usara Java, Web: ¿ que también funciona esta tecnología?
  • 66. 3. Riesgos de Habilidades : ¿puede conseguir la asesoría de expertos necesaria? 4. Riesgos Políticos : ¿ existen fuerzas Políticas que se interpongan en su camino?
  • 67. MANEJO DE LOS RIESGOS DE REQUERIMIENTOS: los requerimientos son importantes y en esta metodología los casos de uso son el punto de partida. Los caso de uso son el motor del proceso de desarrollo. Un caso de uso es una iteración entre usuario y sistema. Con el fin de lograr un objetivo
  • 68. El tamaño del caso de uso puede variar según el problema. La importancia radica en que un caso de uso indica una función que el usuario puede entender y tiene un valor para el. Los caso de uso son la base para la comunicación entre los patrocinadores y los desarrolladores, durante la planificación del proyecto. En la etapa de elaboración deben descubrirse los casos de uso principales del SI.
  • 69. Es poco probable descubrir todos los casos de uso. Se debe contar en los mas importantes. Para lo cual deberá programar entrevistas con los usuarios , para recopilar los caso de uso. Los casos de uso no deben ser muy detallados, la descripción será breve y precisa, para entender la idea básica, para usuarios y desarrolladores.
  • 70. La otra tarea es elaborar el esqueleto del Modelo Conceptual del Dominio . El modelo conceptual responde a las preguntas ¿ como se relacionan los objetos entre ellos? Y establece los fundamentos para el modelo de objetos. El concepto Modelo de Dominio , es el mundo al que da apoyo el Sistema de computo. El Modelo del Dominio y los Casos de Uso capturan los requerimientos
  • 71. Los modelos de Análisis abarcan las implicancias de estos requerimientos para una aplicación los modelos de Diseño agregan la infraestructura interna que hace que funcione la aplicación. El propósito del modelo de Dominio es explorar el vocabulario del dominio en términos comprensibles para los expertos.
  • 72. Contando con un modelo de Dominio y un modelo de casos de uso, se desarrolla un Modelo de Diseño que reconoce tanto la información en los objetos del dominio como el comportamiento de los casos de uso. El Modelo de Diseño agrega clases que realizan el trabajo y proporcionan una estructura reutilizable.
  • 73. Se deja correcto las clases de Dominio y los casos de uso importantes, para luego agregar de manera progresiva casos de uso, al modelo de diseño, de forma iterativa. No se debe construir el sistema de golpe. Para construir modelos de Diseño se debe considerar técnicas que proporciona el UML, como: los diagramas de clase : que captura el lenguaje del negocio.
  • 74. Los diagramas de Actividades : describen el flujo de trabajo del negocio. Elimina secuencias innecesarias en el proceso. Puede también apoyarse en : Diagramas de Interacción. Apoyados en Diagramas Conceptuales de clase y de actividad se consulta la opinión de los expertos del Dominio, para identificar áreas de riesgo y casos de uso. Consolidar los diversos diagramas en un solo modelo de dominio, que sirve como punto de partida para un diseño de clases en la etapa de construcción.
  • 75. Si el modelo en muy grande mediante paquetes se divide en partes, consolidando los diag. De clase y actividad. El primer modelo de dominio debe concentrar los detalles mas importantes. El resto se cubrirá durante el desarrollo iterativo. El modelo de Dominio es dirigido por Casos de Uso .
  • 76. El equipo que construye el dominio debe ser pequeño ( de dos a cuatro personas) durante el periodo de elaboración el líder del proyecto deberá asegurase que el equipo no se empantane en detalles, ni que pierda contacto con la realidad. Para comprender los requerimientos se debe construir prototipos de las partes intrincadas de los casos de uso.
  • 77. MANEJO DE RIESGOS TECNOLOGICOS: para abarcar los riesgos tecnológicos se debe construir prototipos, que pruebe la tecnología que uno quiere usar. Si trabaja en VB y SQL. Conseguir una versión adecuada del VB con sus herramientas construir partes sencillas del modulo y ver como funciona construir la BD y conectar al VB probar las diversas herramientas .
  • 78. Los riesgos tecnológicos mayores son los inherentes a la manera como se integran los componentes de un diseño. Concentrese en la áreas que parezca que mas adelante será difícil de cambiar. Preguntese: ¿qué sucederá si no trabaja una pieza de la tecnología ¿qué ocurrirá si no podemos conectar dos piezas del rompecabezas? ¿cuál es la probabilidad de que algo vaya mal? ¿qué haremos si eso sucede?
  • 79. Se deberá analizar los caso de uso a medida que aparezcan, a fin de ver si tiene algo que pueda echar por tierra su diseño. Los diagramas de clase y de iteración son útiles para mostrar como se comunican los componentes. Los diagramas de paquetes pueden mostrar un cuadro de alto nivel de los componentes los diagramas de desplazamiento (deployment) proveen una visión panorámica de la distribución de piezas.
  • 80. MANEJO DE RIESGOS DE HABILIDAD : el principal riesgo es iniciar un proyecto OO sin la suficiente experiencia. Los directivos se preocupan por los costos del entrenamiento pero se paga hasta el ultimo centavo cuando se alargan los proyectos. El entrenamiento es una manera de evitar errores, cometerlos consume tiempo y cuesta
  • 81. Lo adecuado son cursos de entrenamiento breve, brindados por instructores capaces, por partes en el momento que se necesite, y poner en practica lo aprendido. La mejor manera de adquirir las habilidades en OO es a través del método de tutoría, contratarlos para áreas especificas o todo el proyecto. También podrá completar sus habilidades mediante la lecturas. Constituir grupos técnico de estudio
  • 82. BASE ARQUTECTONICA se compone de: la lista de casos de uso , que le dice cuales son los requerimientos. El modelo del dominio : compuesto de lo que se entiende del negocio. Sirve para armar las clases. La plataforma tecnológica. Esta arquitectura es el cimiento del desarrollo y funciona como ante proyecto.
  • 83. CUANDO TERMINA LA ELABORACION : la elaboración consume una quinta parte de la duración del proyecto Dos circunstancias son indicadores claves que señalan que se ha completado la elaboración: los desarrolladores pueden tener la confianza necesaria para dar estimaciones. Se han identificado todos los riesgos significativos, se sabe como tratarlos