SlideShare una empresa de Scribd logo
1 de 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
Ciclo V
Turno Noche
Especialidad Computacion e Informatica
Docente Marco Aurelio Porro Chulli
2015
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

Más contenido relacionado

La actualidad más candente

Analisis y Diseño de Sistemas 2-Metodologia OMT
Analisis y Diseño de Sistemas 2-Metodologia OMTAnalisis y Diseño de Sistemas 2-Metodologia OMT
Analisis y Diseño de Sistemas 2-Metodologia OMT
Mari Cruz
 
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
Leo 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 Objetos
maria8003
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
yoiner santiago
 
Metodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaugh
viisistemas
 

La actualidad más candente (20)

Analisis y Diseño de Sistemas 2-Metodologia OMT
Analisis y Diseño de Sistemas 2-Metodologia OMTAnalisis y Diseño de Sistemas 2-Metodologia OMT
Analisis y Diseño de Sistemas 2-Metodologia OMT
 
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
 
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
 
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
 
Programacion o.o.
Programacion o.o.Programacion o.o.
Programacion o.o.
 
Clasificacion metodologias
Clasificacion metodologiasClasificacion metodologias
Clasificacion metodologias
 
Diseño Oriendado a Objetos
Diseño Oriendado a ObjetosDiseño Oriendado a Objetos
Diseño Oriendado a Objetos
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
 
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ã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaugh
 
Deber analisis
Deber analisisDeber analisis
Deber analisis
 
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
 
Metodología orientada a objetos
Metodología orientada a objetosMetodología orientada a objetos
Metodología orientada a objetos
 
Dominio
DominioDominio
Dominio
 
Ender metodologia estructura
Ender metodologia estructuraEnder metodologia estructura
Ender metodologia estructura
 
Uml
UmlUml
Uml
 
Metodologia omt
Metodologia omtMetodologia omt
Metodologia omt
 
Modelo Orientado A Objetos
Modelo Orientado A ObjetosModelo Orientado A Objetos
Modelo Orientado A Objetos
 
Metodologia para el proyecto
Metodologia para el proyectoMetodologia para el proyecto
Metodologia para el proyecto
 

Similar a Presentación2

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
Alexander Pino
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
waralivt
 
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
 
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdfclasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
clasificacindelasmetodologasdedesarrollodesoftware-151201230639-lva1-app6892.pdf
CESARAS4
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santeliz
wilensanz
 

Similar a 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
 
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
 
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
 
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
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
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
 
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
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santeliz
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
 
República bolivariana de venezuela
República bolivariana de venezuelaRepública bolivariana de venezuela
República bolivariana de venezuela
 
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.
 
Analisis de requerimientos
Analisis de requerimientosAnalisis de requerimientos
Analisis de requerimientos
 
20% del segundo corte
20% del segundo corte20% del segundo corte
20% del segundo corte
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistema
 
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
 
Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos
 
Jessika parica. Fundamentos y métodos de análisis de los requerimientos.
Jessika parica. Fundamentos y métodos de análisis de los requerimientos.Jessika parica. Fundamentos y métodos de análisis de los requerimientos.
Jessika parica. Fundamentos y métodos de análisis de los requerimientos.
 

Más 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
 

Último

Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D Ccesa007.pdf
Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D  Ccesa007.pdfEdiciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D  Ccesa007.pdf
Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D Ccesa007.pdf
Demetrio Ccesa Rayme
 
Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14
KevinBuenrostro4
 
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
helmer del pozo cruz
 
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdfANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
lvela1316
 
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docxSISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
gesicavillanuevaqf
 

Último (20)

Luz desde el santuario. Escuela Sabática
Luz desde el santuario. Escuela SabáticaLuz desde el santuario. Escuela Sabática
Luz desde el santuario. Escuela Sabática
 
Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D Ccesa007.pdf
Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D  Ccesa007.pdfEdiciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D  Ccesa007.pdf
Ediciones Previas Proyecto de Innovacion Pedagogica ORIGAMI 3D Ccesa007.pdf
 
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptxHidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
Hidrocarburos cíclicos, EJERCICIOS, TEORIA Y MÁS.pptx
 
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxComunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
 
Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024Seguridad y virus informáticos 12°B 2024
Seguridad y virus informáticos 12°B 2024
 
flujo de materia y energía ecosistemas.
flujo de materia y  energía ecosistemas.flujo de materia y  energía ecosistemas.
flujo de materia y energía ecosistemas.
 
Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14
 
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocxCONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
 
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
 
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
RESOLUCION_VICE_MINISTERIAL-00048-2024-M-EVALUACIÓN EVALAUCION FORMATIVA MINE...
 
Estudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado BásicoEstudios Sociales libro 8vo grado Básico
Estudios Sociales libro 8vo grado Básico
 
Power Point : Motivados por la esperanza
Power Point : Motivados por la esperanzaPower Point : Motivados por la esperanza
Power Point : Motivados por la esperanza
 
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdfANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
ANTOLOGIA COMPLETA ANITA LA ABEJITA PARA LA LECTOESCRITURA EN PRIMER GRADO.pdf
 
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docxSISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
 
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO SOPA DE LETRAS OLÍMPICA. Por JAVIER SOLIS NOYOLA
 
Análisis de los factores internos en una Organización
Análisis de los factores internos en una OrganizaciónAnálisis de los factores internos en una Organización
Análisis de los factores internos en una Organización
 
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLAACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
ACERTIJO CÁLCULOS MATEMÁGICOS EN LA CARRERA OLÍMPICA. Por JAVIER SOLIS NOYOLA
 
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIALA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
 
Sesión de clase Motivados por la esperanza.pdf
Sesión de clase Motivados por la esperanza.pdfSesión de clase Motivados por la esperanza.pdf
Sesión de clase Motivados por la esperanza.pdf
 
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docxcuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
cuadernillo_cuentos_de_los_valores_elprofe20 (1).docx
 

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 Ciclo V Turno Noche Especialidad Computacion e Informatica Docente Marco Aurelio Porro Chulli 2015
  • 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.