1. Instituto De Educación Superior Tecnológico Privado
Curso ingenieria de software
Tema Clasificacion De Metodologia
integrantes Densy de la Cruz Lucero
Yuliana Arrieta Flores
Samantha Palomino zamora
Maria Aracely Chavesta Lluen
Ciclo V
2. Metodología 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.
3. .
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: ¿Cuáles 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.
4. Esta metodología surge en Francia en 1977 a propuesta del Ministerio de
Industria, como un intento de unificar criterios en torno a la metodología de
desarrollo para los sistemas informáticos de la Administración Pública Francesa.
Sus principios generales son:
Desglose en etapas: estudio preliminar, estudio detallado, realización y
puesta en marcha.
División en el estudio de los tratamientos por un lado y el estudio de los
datos por otro.
Uso del modelo Entidad/Relación y sus formalismos para representar los
datos.
Uso de los Diagramas de Encadenamiento de Procedimientos para
representar los tratamientos.
Completo reparto de tareas y responsabilidades entre los desarrolladores
durante la fase inicial, y entre los ususarios y ordenador en la explotación.
(Esquema director)
NIVEL TRATAMIENT
OS
DATOS OPCIÓN
CONCEPTUAL Modelo
Conceptual
Modelo
Concept
ual
De
gestión
ORGANIZACIO
NAL
Modelo
Organizacional
Modelo
Lógico
De
organizaci
ón
OPERACIONAL Modelo
Operacional
Modelo
Físico
Técnica
5. Aparece en Gran Bretaña por los mismos motivos que MERISE y se establece como
obligatoria para la Administración Pública a partir de 1983.
Los aspectos claves de esta metodología son:
Énfasis en los usuarios: sus requisitos y participación.
Definición del proceso de producción.
Tres puntos de vista: datos, eventos y procesos.
Máxima flexibilidad en herramientas y técnicas de implementación.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y
diseño, pero no cubre aspectos como la planificación estratégica ni entra en la
construcción del código.
Es la metodología adoptada como estándar por la Administración Pública
Española. Consiste en un conjunto de fases donde se utilizan multitud de técnicas
conducentes a la obtención de aplicaciones de calidad, fáciles de mantener y muy
bien documentadas.
4.3.1.- Objetivos de Métrica versión 3.
La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un
instrumento útil para la sistematización de las actividades que dan soporte
al ciclo de vida del software dentro de un marco que permite alcanzar los
siguientes objetivos:
Proporcionar o definir Sistemas de Información que sirvan a la consecución
de los fines de la Organización mediante la definición de un marco
estratégico para el desarrollo de los mismos.
6. MÉTRICA Versión 3 contempla el desarrollo de Sistemas de Información
para las distintas tecnologías que actualmente están conviviendo y los
aspectos de gestión que asegurarán que un Proyecto cumple sus objetivos en
términos de calidad y coste.
Su punto de partida es la versión anterior de MÉTRICA de la cual se ha
conservado la adpatabilidad, flexibilidad y sencillez. Se ha tenido en cuenta
la experiencia de los usuarios de las versiones anteriores para solventar los
problemas o deficiencias detectados.
En la elaboración de MÉTRICA Versión 3 se han tenido en cuenta los
métodos de desarrollo más extendidos, así como los últimos estándares de
ingeniería del software y calidad, así como referencias específicas en cuanto
a seguridad y gestión de proyectos.
4.3.3.- Estructura de Métrica V3.
En una única estructura la metodología MÉTRICA Versión 3 cubre distintos
tipos de desarrollo: estructurado y orientado a objetos, y facilita a través de
interfaces la realización de los procesos de apoyo u organizativos.
Procesos principales.
Interfaces.
• Procesos principales:
Cada Proceso detalla las Actividades y Tareas a realizar.
Para cada tarea se indican:
Las técnicas y prácticas a utilizar.
Los responsables de realizarla.
Sus productos de entrada y salida.
7. La metodología orientada a objetos ha derivado de las metodologías anteriores a
éste. Así como los métodos de diseño estructurado realizados guían a los
desarrolladores que tratan de construir sistemas complejos utilizando algoritmos
como sus bloques fundamentales de construcción, similarmente los métodos de
diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a
explotar el poder de los lenguajes de programación basados en objetos y orientados
a objetos, utilizando las clases y objetos como bloques de construcción básicos.
Actualmente el modelo de objetos ha sido influenciado por un número de factores
no sólo de la Programación Orientada a Objetos, POO (Object Oriented
Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha
probado ser un concepto uniforme en las ciencias de la computación, aplicable no
sólo a los lenguajes de programación sino también al diseño de interfaces de
usuario, bases de datos y arquitectura de computadoras por completo. La razón de
ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la
inherente complejidad de muchos tipos de sistemas.
Se define a un objeto como "una entidad tangible que muestra alguna conducta
bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual
almacenamos datos y los métodos que controlan dichos datos".
Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En
particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o
estar en relación con otros objetos de manera apropiada a este objeto.
Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como método
de análisis de requisitos por derecho propio y como complemento de otros métodos
de análisis. En lugar de examinar un problema mediante el modelo clásico de
entrada-proceso-salida (flujo de información) o mediante un modelo derivado
exclusivamente de estructuras jerárquicas de información, el AOO introduce varios
conceptos nuevos. Estos conceptos nuevos le parecen inusuales a mucha gente,
pero son bastante naturales.
8. Una metodología puede definirse como "Una
versión ampliada del ciclo de vida completo del
desarrollo de sistemas, que incluyen tareas o
pasos para cada fase, funciones desempeñadas
en cada tarea, productos resultantes, normas de
calidad y técnicas de desarrollo que se utilizan
en cada tarea" [3]. En los últimos años se han
desarrollado diversas metodologías de
aplicación específica del diseño de STR, entre
ellas se pueden encontrar ROOM/UML-RT,
HRT-HOOD, OOHARTS, SiMOO-RT,
ACCORD/UML COMET, Octopus/UML, ROPES
[4]. Para esta investigación, se seleccionaron las
tres últimas de las metodologías mencionadas,
tomando en cuenta características comunes
tales como, basadas en notaciones estándares
como UML y enfocadas bajo el paradigma
orientado a objetos, utilizan la definición
arquitectura de software. A continuación, se
presenta una descripción breve de cada una de ellas.
9. . Desarrollo, aquellas metodologías con
mayor énfasis en la planificación y control
del proyecto, en especificación precisa de
requisitos y modelado, reciben el apelativo
de Metodologías Tradicionales (o también
denominadas Metodologías Pesadas, o Peso
Pesado). Otras metodologías,
denominadas Metodologías Ágiles, están
más orientadas a la generacas por una fuerte
planificación durante todo el proceso de
desarrollo; llamadas también metodologías
tradicionales o clásicas, donde se realiza una
intensa etapa de análisis y diseño antes de la
construcción del sistema.
Una metodología es un conjunto de
procedimientos, técnicas, herramientas y un
soporte documental que ayuda a los desarrolladores a realizar un nuevo software.
Puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica
qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo
hacerlo. La metodología indica cómo hay que obtener los distintos productos
parciales y finales.
Finalmente dependerá de la metodología utilizada los productos del proyecto, por
esta razón es necesario, conoces a fondo cada una de ellas y poder diferenciar entre
una y otra, para de este modo saber elegir la correcta en el momento de desarrollar
un nuevo software, de otra manera el producto no será el mejor e incluso puede ser
inútil
10. Developing those methodologies with greater emphasis on planning and control of
the project, precise specification of requirements and modeling, receive the
nickname traditional methodologies (also called Heavy methodologies, or
Heavyweight). Other methodologies, called Agile, are more oriented to generacas
by strong planning throughout the development process; also called traditional or
classical methodologies, where an intense period of analysis and design is done
before the construction of the system.
A methodology is a set of procedures, techniques, tools and supporting
documentation to help developers to make new software. You can do one or several
life cycle models, ie, the life cycle tells you what you need to get over the
development of the project but not how. The methodology indicates how you have
to get the various intermediate and final products.
Finally it depends on the methodology of project outputs, for this reason it is
necessary, you know thoroughly each and to differentiate between them, to thereby
know how to choose the right one at the time to develop a new software, otherwise
the product will not be the best and may even be useless.
Después de revisar los resultados de la presente investigación se obtuvieron las
Siguientes conclusiones:
.1 Las metodologías de desarrollo de Software se basan en diversas pruebas, y cada
Una tiene proceso divididos en fases.
.2 Cada metodología está diseñada para cumplir una necesidad especifica es decir,
no
Todas tienen la misma funcionalidad, por ejemplo si el objetivo es la fácil y rápida
Creación de un programa sencillo se pude utilizar el modelo en espiral o el de
Cascada; pero si por el contrario se requiere el diseño de un programa tecnificado
Arquitectónico más complicado, lo ideal sería utilizar alguna metodología mas
Explicita como la RUP.