metodología de desarrollo de softwaree
TRANSCRIPT
Instituto Tecnológico Spencer W. Kimball
Bachillerato Industrial y Perito en Computación
Tecnología II
Profesor: Álvaro Martínez
Tema:
Metodología de desarrollo de software
Alumno: Selvin Fernando Xutuc Samayoa
Grado: 5to. Computación
Sección: Única
Fecha: 20/05/2015
Introducción.
El presente trabajo trata sobre el tema en general Metodologías para el desarrollo de Software,
este tema se incluye metodologías estructuradas, metodologías orientadas a objetos,
metodologías tradicionales y metodologías agiles. Tambien están: el modelo en cascada,
modelo prototipado, modelo incremental, modelo espiral, etc.
Índice.
Contenido METODOLOGÍAS ESTRUCTURADAS: ..........................................................................................................1
METODOLOGÍAS ORIENTADAS A OBJETOS: ............................................................................................1
METODOLOGÍAS TRADICIONALES: .............................................................................................................2
METODOLOGÍAS ÁGILES: ...............................................................................................................................2
Enfoques de desarrollo de software .................................................................................................................4
Modelo en cascada .............................................................................................................................................4
Modelo Prototipado .............................................................................................................................................4
Modelo Incremental .............................................................................................................................................5
Modelo Espiral ......................................................................................................................................................5
Modelo Rapid Application Development (RAD) ..............................................................................................6
Otros enfoques de desarrollo de software ...................................................................................................6
Ciclo de vida del software...................................................................................................................................7
METODOLOGIA RUP .........................................................................................................................................8
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
1
Metodología de desarrollo de software
Un proceso de software detallado y completo suele denominarse “Metodología”. Las
metodologías se basan en una combinación de los modelos de proceso genéricos (cascada,
evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con
precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas
recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de
herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a
técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del
proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad
de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada
una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para
especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las
metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos.
Por otra parte, considerando su filosofía de 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 generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos
de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en
equipo e involucran activamente al cliente en el proceso
A continuación se revisan brevemente cada una de estas categorías de metodologías:
METODOLOGÍAS ESTRUCTURADAS:
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño
(por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por
ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas
en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia),
MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos
estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e
Information Engineering.
METODOLOGÍAS ORIENTADAS A OBJETOS:
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los
más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera
versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines
de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
2
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un
objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación
Orientada a Objetos más popular en la actualidad.
Algunas metodologías orientadas a objetos que utilizan la notación UML son:
Rational Unified Process (RUP),
OPEN,
MÉTRICA (que también soporta la notación estructurada).
METODOLOGÍAS TRADICIONALES:
Las metodologías no ágiles son aquellas que están guiadas 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.
Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que
presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración
previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
METODOLOGÍAS ÁGILES:
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).
Entre las metodologías ágiles identificadas son:
Extreme Programming
Scrum
Familia de Metodologías Crystal
Feature Driven Development
Proceso Unificado Rational, una configuración ágil
Dynamic Systems Development Method
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
3
Adaptive Software Development
Open Source Software Development
SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA
DESARROLLO DE SOFTWARE:
Rational Unified Process (RUP)
Extreme Programming (XP)
SCRUM
Metodología de desarrollo de software en ingeniería de software es un marco de trabajo
usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de
información.
Una metodología de desarrollo de software se refiere a un framework que es usado para
estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose
por su fortaleza y debilidad.
El framework para metodología de desarrollo de software consiste en:
Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de
desarrollo de software
Herramientas, modelos y métodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algún tipo de organización, que además
desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo
documentada en algún tipo de documentación formal.
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
4
Enfoques de desarrollo de software
Cada metodología de desarrollo de software tiene más o menos su propio enfoque para
el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias
metodologías específicas. Estos enfoques son los siguientes:
Modelo en cascada: Framework lineal.
Prototipado: Framework iterativo.
Incremental: Combinación de framework lineal e iterativo.
Espiral: Combinación de framework lineal e iterativo.
RAD: Rapid Application Development, framework iterativo.
Modelo en cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo
(como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño,
implantación, pruebas (validación), la integración, y mantenimiento. La primera descripción
formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce
W.2 en 1970, aunque Royce no utiliza el término "cascada" de este artículo.
Los principios básicos del modelo de cascada son los siguientes:1
El proyecto está dividido en fases secuenciales, con cierta superposición y splashback
aceptable entre fases.
Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo
un sistema de una sola vez.
Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una
amplia documentación escrita, así como a través de comentarios y aprobación / signoff por
el usuario y la tecnología de la información de gestión al final de la mayoría de las fases
antes de comenzar la próxima fase.
Modelo Prototipado
El prototipado permite desarrollar modelos de aplicaciones de software que permiten ver la
funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o características del
modelo terminado. El prototipado permite al cliente evaluar en forma temprana el producto, e
interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las
expectativas y las funcionalidades acordadas. Los Prototipos no poseen la funcionalidad total
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
5
del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad,
y maneja un alto grado de participación del usuario.
Modelo Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del
producto software reservando el resto de aspectos para el futuro.
Los principios básicos son:
Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo
de desarrollo se han completado para una pequeña parte de los sistemas, antes de proceder
a la próxima incremental.
Se definen los requisitos antes de proceder con lo evolutivo, se realiza una mini cascada de
desarrollo de cada uno de los incrementos del sistema.
El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y
colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de
prototipos, que culmina en la instalación del prototipo final.
Modelo Espiral
Los principios básicos son:
La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el
proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el
proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso
de la consideración de la continuación del proyecto durante todo el ciclo de vida.
Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar
objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas; Identificar
y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteración, y (4) plan de
la próxima iteración.3
Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia,
y termina con la revisión y examinación.
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
6
Modelo Rapid Application Development (RAD)
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que
implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones
es un término originalmente utilizado para describir un proceso de desarrollo de
software introducido por James Martin en 1991.
Principios básicos:
Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de
relativamente bajo coste de inversión.
Intenta reducir el riesgo inherente del proyecto partiéndolo en segmentos más pequeños y
proporcionar más facilidad de cambio durante el proceso de desarrollo.
Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente
mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la
participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas
herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer
Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de
datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y
técnicas orientada a objetos.
Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la
ingeniería tecnológica o la excelencia es de menor importancia.
Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de
entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos
para el ajuste, no en el aumento de la fecha límite.
En general incluye Joint application development (JAD), donde los usuarios están
intensamente participando en el diseño del sistema, ya sea a través de la creación de
consenso estructurado en talleres, o por vía electrónica.
La participación activa de los usuarios es imprescindible.
Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.
Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.
Otros enfoques de desarrollo de software
Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady
Booch, también conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
7
incluye seis diagramas: de clase, objeto, estado de transición, la interacción, módulo, y el
proceso.
Top-down programming, evolucionado en la década de 1970 por el investigador
de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.
Proceso Unificado, es una metodología de desarrollo de software, basado en UML. Organiza
el desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más
iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices.
Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las
versiones más populares es la de Rational Unified Process.
Ciclo de vida del software
El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial
hasta la fase final, incluyendo su estado funcional. El propósito es definir las distintas fases
intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar
que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de
desarrollo: se asegura que los métodos utilizados son apropiados. Estos métodos se originan
en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase
de implementación (programación propiamente dicha), o peor aún, durante la fase funcional. El
modelo de ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto,
permite a los desarrolladores concentrarse en la calidad del software, en los plazos de
implementación y en los costos asociados. El ciclo de vida básico de un software consta de, al
menos, los siguientes procedimientos:
Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del
cliente y examinar cualquier restricción que se pueda aplicar.
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
Programación (programación e implementación): es la implementación en un lenguaje de
programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar
que se implementaron de acuerdo con las especificaciones.
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
8
Integración: para garantizar que los diferentes módulos y subprogramas se integren con la
aplicación. Éste es el propósito de la prueba de integración que debe estar cuidadosamente
documentada.
Prueba beta (o validación), para garantizar que el software cumple con las especificaciones
originales.
Documentación: se documenta con toda la información necesaria, sea funcional final para
los usuarios del software (manual del usuario), y de desarrollo para futuras adaptaciones,
ampliaciones y correcciones.
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las
actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una
aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo
de desarrolladores.
METODOLOGIA RUP
Siempre que empezamos discutiendo métodos en la arena OO, inevitablemente salimos con el papel del Rational Unified Process. El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la Rational como el proceso complementario al UML. El RUP es un armazón de proceso y como tal puede acomodar una gran variedad de procesos. De hecho ésta es mi crítica principal al RUP - como puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice qué hacer en lugar de dar opciones infinitas. Como resultado de esta mentalidad de armazón de procesos, el RUP puede usarse en un estilo muy tradicional de cascada o de una manera ágil. Como resultado usted puede usar el RUP como un proceso ágil, o como un proceso pesado - todo depende de cómo lo adapte a su ambiente. Craig Larman es un fuerte defensor de usar el RUP de una manera ágil. Su excelente libro introductoriosobre desarrollo OO contiene un proceso que está muy basado en su pensamiento ligero del RUP. Su visión es que mucho del reciente empujón hacia los métodos ágiles no es nada más que aceptar desarrollo OO de la corriente principal que ha sido capturada como RUP. Una de las cosas que hace Craig es pasarse los primeros dos o tres días de una iteración mensual con todo el equipo usando el UML para perfilar el diseño del trabajo a hacerse durante la iteración. Esto no es un cianotipo del que no se pueda desviarse, sino un boceto que da una perspectiva sobre cómo pueden hacerse las cosas en la iteración. Otra tachuela en el RUP ágil es el proceso dX de Robert Martin. El proceso dx es una versión totalmente dócil del RUP que simplemente es idéntico a la XP(voltear dX al revés para ver la broma). El dX está diseñado para gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la vez XP y RUP y por tanto un buen ejemplo del uso ágil del RUP.
ANALISIS DE SISTEMAS II Profesor: Álvaro Martínez
9
Para mí, una de las cosas clave que necesita el RUP es que los líderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Más de una vez he oído a la gente que usa el RUP que están usando un proceso de desarrollo estilo cascada. Gracias a mis contactos en la industria, sé que Philippe Kruchten y su equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos principios y animando las versiones ágiles del RUP tales como los trabajos de Craig y de Robert tendrá un efecto importante.
El proceso de ciclo de vida de RUP se divide en cuatro fases bien conocidas llamadas Incepción,
Elaboración, Construcción y Transición. Esas fases se dividen en iteraciones, cada una de las
cuales produce una pieza de software demostrable. La duración de cada iteración puede
extenderse desde dos semanas hasta seis meses. Las fases son: Incepción. Significa “comienzo”, pero la palabra original (de origen latino y casi en desuso como
sustantivo) es sugestiva y por ello la traducimos así. Se especifican los objetivos del ciclo de
vida del proyecto y las necesidades de cada participante. Esto entraña establecer el alcance y
las condiciones de límite y los criterios de aceptabilidad. Se identifican los casos de uso que
orientarán la funcionalidad.
Conclusiones.
1. Las metodologías se basan en una combinación de los modelos de proceso
genéricos (cascada, evolutivo, incremental, espiral entre otros).
2. Cada metodología de desarrollo de software tiene más o menos su propio
enfoque para el desarrollo de software.
3. (RAD) es una metodología de desarrollo de software, que implica el desarrollo
iterativo y la construcción de prototipos.
E-grafía.
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
http://ingenieriadesoftware.mex.tl/52788_Rup-Agil.html