MERISE:

MERISE:
Es un método integrado de análisis, concepción y gestión de proyectos, desarrollado en Francia.Esta metodologia aporta un ciclo de vida mas largo a los existentes se materializa en un conjunto definido de etapas. El mismo provee un marco metodológico y un lenguaje común riguroso para los desarrollos informáticos.

METODOLOGIA O.AOBJETOS:

METODOLOGIA ORIENTADA A OBJETOS:

La orientación a objetos es la más reciente.

ventajas:

Está basada en componentes, lo que significa que es más fácil reutilizar código hecho por terceras personas.

Es fácil de mantener debido a que los cambios están más localizados.

Diseño estructurado : ¿Cómo se puede dividir el sistema en partes más pequeñas que puedan ser resueltas por algoritmos sencillos y qué información se intercambian?.

En el diseño orientado a objetos la idea es sin embargo: ¿Cuales son los tipos de datos que hay que utilizar, que características tienen y como se relacionan?.

La orientación a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que supone focalizar la atención en las estructuras de datos.

El concepto de objetos tuvo sus orígenes en la inteligencia artificial como un modo de representación del conocimiento.

El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaardy Ole-Johan Dahl en el centro de cálculo noruego, pero el que se considera el primer lenguaje orientado a objetos puro fue Smaltalk, donde todos los elementos del lenguaje son objetos.

El lenguaje C++ fue una ampliación de C para que soportara objetos, resultó muy eficiente y también muy complejo.

Java es otro lenguaje orientado a objetos derivado de C++ pero con la idea de ser más sencillo.

METODOLOGIA ESTRUCTURADA:

 METODOLOGIA ESTRUCTURADA:

Es la primera aproximación al problema. Está orientada a procesos, es decir, se centra en especificar y descomponer la funcionalidad del sistema.

Herramientas utilizadas:

Diagramas de flujo de datos (DFD): Representan la forma en la que los datos se mueven y se transforman. Incluye:

–Procesos
–Flujos de datos
–Almacenes de datos

Los procesos individuales se pueden a su vez descomponer en otros DFD de nivel superior.
Especificaciones de procesos: Es lo que se escribe para uno de los procesos definidos en el DFD cuando no se puede descomponer más. Puede hacerse en pseudocódigo, con tablas de decisión o en un lenguaje de programación.
Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de datos junto con sus definiciones
Diagramas de transición de estados: Modelan procesos que dependen del tiempo
Diagramas entidad-relación: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este diagrama se muestran las relaciones entre dichos elementos
Los lenguajes de programación también reflejan esta dicotomía que existe entre la metodologías, así existen lenguajes para la programación estructurada. Los más famosos son: Cobol, Fortran, C, Pascal y Modula 2.

METODOLOGIAS DE DESARROLLO DEL SOFTWARE:

MODELO ES.:

MODELO ESPIRAL:
Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.
2. Análisis del riesgo.
3. Desarrollar y probar.
4. 'Planificación.'

DETERMINAR OBJETIVOS:

• Fijar también los productos definidos a obtener: requisitos, especificación, manual de usuario.
• Fijar las restricciones.
• Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
• Hay una cosa que solo se hace una vez: planificación inicial.

DESARROLLAR, VERIFICAR y VALIDAR(PROBAR):

• Tareas de la actividad propia y de prueba.
• Análisis de alternativas e identificación resolución de riesgos.
• Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

ANÁLISIS DE RIESGO:

• Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.

MODELO E.:

MODELO EVOLUTIVO:                                                                                             

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.    Este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene una rápida re alimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

    TIPOS DE DESARROLLO EVOLUTIVO:

 DESARROLLO EXPLORATORIO:

     El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

    DESARROLLO DE PROTOTIPOS:

     El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. 

VENTAJAS:           

·       La especificación puede desarrollarse de forma creciente.

·       Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

·       Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

DESVENTAJAS:

·       Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.

·       Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

·       Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

CONCEPTO M.B.R:

• MODELO BASADO EN REUTILIZACION:
• El diseño basado en reutilización puro busca construir un producto software integrando componentes pre-existentes.
• Los beneficios principales que otorga este modelo son:
•  -Tiempos de desarrollos cortos
•  -Disminución de errores
•  -Disminución de costos y riegos ya que se reduce los componentes a desarrollar
•  -Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testados y utilizados en otro momento previo al comienzo del proyecto
• Desventaja: podemos mencionar el hecho de que al no poseer algún componente que cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los componentes almacenados en el repositorio de componentes.
• Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo para que cumpla con lo pedido por el usuario.
• Otra desventaja de este modelo es que una vez finalizada la etapa de modificación de requisitos, y ante la eventual necesidad de cambios en estos últimos, puede pasar que no haya componentes que se adapten a las nuevas modificaciones.