SlideShare une entreprise Scribd logo
1  sur  11
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
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.
.
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.
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
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.
 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.
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.
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.
. 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
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.
https://sites.google.com/site/cursofpeanalistafuncional/necesidad-de-una-
metodologia
http://www.academia.edu/9953322/Metodologias_para_el_desarrollo_de
_software
https://sites.google.com/site/adai6jfm/principales-metodologas-de-
desarrollo-europeas

Contenu connexe

Tendances

Esquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasEsquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasLeo Jm
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetosmaria8003
 
Clasificacion metodologias
Clasificacion metodologiasClasificacion metodologias
Clasificacion metodologiashaljho2015
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
 
Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Andoni Vasquez
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a ObjetosRafael Miranda
 
Estilos y patrones arquitectónicos
Estilos y patrones arquitectónicosEstilos y patrones arquitectónicos
Estilos y patrones arquitectónicosIsrael Rey
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasFrancisco Gómez
 
Aplicaciones del modelo y especificaciones
Aplicaciones del modelo y especificacionesAplicaciones del modelo y especificaciones
Aplicaciones del modelo y especificacionesedsacun
 
Trabajo de Análisis y Diseños de Sistemas
Trabajo de Análisis y Diseños de SistemasTrabajo de Análisis y Diseños de Sistemas
Trabajo de Análisis y Diseños de SistemasFreddy Ramos
 
Alumno david gimenez ci 26846136 metodología
Alumno david gimenez ci 26846136 metodologíaAlumno david gimenez ci 26846136 metodología
Alumno david gimenez ci 26846136 metodologíaDavid Alexander
 

Tendances (20)

Esquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasEsquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologías
 
Metodologías de desarrollo orientado a objetos
Metodologías de desarrollo orientado a objetosMetodologías de desarrollo orientado a objetos
Metodologías de desarrollo orientado a objetos
 
Metodologías para el desarrollo de sioo
Metodologías para el desarrollo de siooMetodologías para el desarrollo de sioo
Metodologías para el desarrollo de sioo
 
OOSE
OOSEOOSE
OOSE
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
 
Clasificacion metodologias
Clasificacion metodologiasClasificacion metodologias
Clasificacion metodologias
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
 
Ender metodologia estructura
Ender metodologia estructuraEnder metodologia estructura
Ender metodologia estructura
 
Dominio
DominioDominio
Dominio
 
Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Análisis y diseño de sistemas1
Análisis y diseño de sistemas1
 
Metodologia omt
Metodologia omtMetodologia omt
Metodologia omt
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
Arquitectura pizarra
Arquitectura pizarraArquitectura pizarra
Arquitectura pizarra
 
Tecnicas de modelado y metodologias para aplicaciones Web
Tecnicas de modelado y metodologias para aplicaciones WebTecnicas de modelado y metodologias para aplicaciones Web
Tecnicas de modelado y metodologias para aplicaciones Web
 
Estilos y patrones arquitectónicos
Estilos y patrones arquitectónicosEstilos y patrones arquitectónicos
Estilos y patrones arquitectónicos
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemas
 
Aplicaciones del modelo y especificaciones
Aplicaciones del modelo y especificacionesAplicaciones del modelo y especificaciones
Aplicaciones del modelo y especificaciones
 
Trabajo de Análisis y Diseños de Sistemas
Trabajo de Análisis y Diseños de SistemasTrabajo de Análisis y Diseños de Sistemas
Trabajo de Análisis y Diseños de Sistemas
 
Alumno david gimenez ci 26846136 metodología
Alumno david gimenez ci 26846136 metodologíaAlumno david gimenez ci 26846136 metodología
Alumno david gimenez ci 26846136 metodología
 

Similaire à Presentación2

Metodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de SistemasMetodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de SistemasElvis Mendoza Sequera
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasAlexander Pino
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructuradowaralivt
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructuradowaralivt
 
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 sistemasEliset Gonzales Uceda
 
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 softwareElvisAR
 
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfclasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfCESARAS4
 
República bolivariana de venezuela
República bolivariana de venezuelaRepública bolivariana de venezuela
República bolivariana de venezuelaaularjesus
 
Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.German Rodriguez
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemasalberto_marin11
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemasalberto_marin11
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizwilensanz
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandross1
 
Analisis de requerimientos
Analisis de requerimientosAnalisis de requerimientos
Analisis de requerimientosssalzar
 
Metodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaMetodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaFreddy Ramos
 
20% del segundo corte
20% del segundo corte20% del segundo corte
20% del segundo cortejoelfinol
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareAndhy H Palma
 

Similaire à Presentación2 (20)

Metodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de SistemasMetodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de Sistemas
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemas
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
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
 
Analisis orientados a objetos
Analisis orientados a objetosAnalisis orientados a objetos
Analisis orientados a objetos
 
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
 
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfclasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
 
República bolivariana de venezuela
República bolivariana de venezuelaRepública bolivariana de venezuela
República bolivariana de venezuela
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
 
Uml
UmlUml
Uml
 
Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemas
 
Metodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de SistemasMetodologías para el Análisisy Diseño de Sistemas
Metodologías para el Análisisy Diseño de Sistemas
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santeliz
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistema
 
Analisis de requerimientos
Analisis de requerimientosAnalisis de requerimientos
Analisis de requerimientos
 
Metodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaMetodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistema
 
20% del segundo corte
20% del segundo corte20% del segundo corte
20% del segundo corte
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 

Plus de densy de la cruz lucero (15)

Trabajo
TrabajoTrabajo
Trabajo
 
Densy vI
Densy vIDensy vI
Densy vI
 
Densy
DensyDensy
Densy
 
Diagrama de despligue
Diagrama de despligueDiagrama de despligue
Diagrama de despligue
 
Densy
DensyDensy
Densy
 
Presentacion
PresentacionPresentacion
Presentacion
 
Porro 10
Porro 10Porro 10
Porro 10
 
Densy yuli
Densy yuliDensy yuli
Densy yuli
 
Densy yuli
Densy yuliDensy yuli
Densy yuli
 
Densy yuli
Densy yuliDensy yuli
Densy yuli
 
Diagramas de caso de uso1
Diagramas de caso de uso1Diagramas de caso de uso1
Diagramas de caso de uso1
 
Yuliana y dency
Yuliana y dencyYuliana y dency
Yuliana y dency
 
Metodologias rup
Metodologias rupMetodologias rup
Metodologias rup
 
Public3
Public3Public3
Public3
 
Metodologia
MetodologiaMetodologia
Metodologia
 

Dernier

IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...YobanaZevallosSantil1
 
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docx
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docxIII SEGUNDO CICLO PLAN DE TUTORÍA 2024.docx
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docxMaritza438836
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOEveliaHernandez8
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxLudy Ventocilla Napanga
 
Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Rosabel UA
 
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxEJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxFabianValenciaJabo
 
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfMapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfvictorbeltuce
 
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxPROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxEribertoPerezRamirez
 
Concurso José María Arguedas nacional.pptx
Concurso José María Arguedas nacional.pptxConcurso José María Arguedas nacional.pptx
Concurso José María Arguedas nacional.pptxkeithgiancarloroquef
 
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfFisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfcoloncopias5
 
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsxJuanpm27
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesRaquel Martín Contreras
 
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfssuser50d1252
 
describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...DavidBautistaFlores1
 
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdf
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdfTarea 5_ Foro _Selección de herramientas digitales_Manuel.pdf
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdfManuel Molina
 
sesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfsesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfpatriciavsquezbecerr
 

Dernier (20)

IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO  YESSENIA 933623393 NUEV...
IV SES LUN 15 TUTO CUIDO MI MENTE CUIDANDO MI CUERPO YESSENIA 933623393 NUEV...
 
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docx
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docxIII SEGUNDO CICLO PLAN DE TUTORÍA 2024.docx
III SEGUNDO CICLO PLAN DE TUTORÍA 2024.docx
 
PPTX: La luz brilla en la oscuridad.pptx
PPTX: La luz brilla en la oscuridad.pptxPPTX: La luz brilla en la oscuridad.pptx
PPTX: La luz brilla en la oscuridad.pptx
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
 
Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024Actividad transversal 2-bloque 2. Actualización 2024
Actividad transversal 2-bloque 2. Actualización 2024
 
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxEJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
 
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfMapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
 
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxPROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
 
Concurso José María Arguedas nacional.pptx
Concurso José María Arguedas nacional.pptxConcurso José María Arguedas nacional.pptx
Concurso José María Arguedas nacional.pptx
 
TL/CNL – 2.ª FASE .
TL/CNL – 2.ª FASE                       .TL/CNL – 2.ª FASE                       .
TL/CNL – 2.ª FASE .
 
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdfFisiologia.Articular. 3 Kapandji.6a.Ed.pdf
Fisiologia.Articular. 3 Kapandji.6a.Ed.pdf
 
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
3. Pedagogía de la Educación: Como objeto de la didáctica.ppsx
 
Aedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptxAedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptx
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materiales
 
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
 
describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...
 
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdf
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdfTarea 5_ Foro _Selección de herramientas digitales_Manuel.pdf
Tarea 5_ Foro _Selección de herramientas digitales_Manuel.pdf
 
sesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfsesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdf
 
Aedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptxAedes aegypti + Intro to Coquies EE.pptx
Aedes aegypti + Intro to Coquies EE.pptx
 

Presentación2

  • 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.