República bolivariana de Venezuela

Ministerio del poder popular para la educación superior

I.U.P Santiago Mariño

ingeniería de Sistemas

Realizado por:

Keivell Nuñez Villalobos

1. Metodología de desarrollo de software

2. Importancia

3. Evolución

4. El desarrollo rápido de aplicaciones o RAD

5. Programación orientada a objetos

6. Rational Unified Process (RUP)

7. Ciclo de vida

8. Programación extrema

9. características de la metodología xp

10. Nivel de madurez, software del proceso

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. También

se puede definir como el conjunto de herramientas, técnicas, procedimientos y

soporte documental para el diseño de Sistemas de información.

Cuando se habla de desarrollo de software se habla de desarrollo de programas y

por lo tanto se considera como una tarea de ingeniería, en el cuál se debe ejecutar

una serie de fases, etapas para obtener un programa que funcione de acuerdo con

métodos ya establecidos en otras disciplinas de ingeniería. Las actividades que los

ingenieros de software realizan se encuentran asociadas a un proceso de software

donde intervienen diferentes elementos (fases, actividades, producto, roles,

agentes) que permiten la definición del software a producir (producto), el desarrollo

o el diseño del software, la validación del software tanto lo interno(requerimientos

específicos)como lo externo(expectativas del cliente), y la evolución del software

donde se modifica para adaptarlo a los cambios.

Importancia de la metodología

Hay un gran número de factores que repercuten en la persona que trabaja dentro

de un entorno de desarrollo software. Los cambios en el sistema operativo, el

lenguaje de programación, la organización del proyecto, o los estándares

establecidos para los diferentes aspectos del ciclo de vida de un proyecto pueden

influir tanto en el trabajador como en la cantidad de trabajo que puede realizar.

La productividad, cómo una medida cuantitativa de la cantidad de trabajo que

puede ser realizada por una persona, se puede alterar de distintas maneras,

alguna de ellas tan simple como, por ejemplo, enseñar a todos los implicados en el

trabajo a escribir a máquina. Este hecho, sin ir más lejos, podría tener un mayor

impacto en la productividad que el de introducir unas nuevas herramientas

software o técnicas de diseño.

Sin embargo la productividad no tiene en consideración la calidad del producto.

Por ejemplo los trabajadores en una planta de ensamblaje de ordenadores pueden

producir 100 ordenadores por hora, pero esta medida no es útil, en cuanto que los

ordenadores pueden requerir trabajo adicional para corregir problemas surgidos

en la etapa del ensamblaje. Lo mismo ocurre en el desarrollo de software, el

objetivo es establecer un entorno que no sólo mejore la productividad del que lo

desarrolla, sino que también genere la creación de mejores productos.

EVOLUCION

Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron

ciertos métodos que permitían llevar a producir un buen proyecto, estas

metodologías aplicadas eran simples, solo se preocupaban por los procesos mas

no por los datos, por lo tanto los métodos eran desarrollados hacia los procesos.

El modelo de procesos predominaba para los años 60 y consistía encodificar y

corregir (Code-and-Fix), si al terminar se descubría que el diseño era incorrecto, la

solución era desecharlo y volver a empezar, este modelo implementaba el código

y luego se pensaba en los requisitos, diseño, validación y mantenimiento. los

principales problemas del modelo de procesos son:

Los arreglos se hacen costosos, después de tantas correcciones el código

tenía una mala estructura.

El software no se ajusta a las necesidades del usuario, por lo que es

rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y

modificar.

En la década de los setenta empezó a tomar la importancia de los datos, y para

solucionar sistemas complejos empezó el análisis por partes o etapas, se

introducen la planeación y administración. El modelo en cascada surge como

respuesta al modelo de procesos, este modelo tiene más disciplina y se basa en el

análisis, diseño, pruebas y mantenimientos.

La década de los ochenta es la época marcada por las metodologías dirigida a

datos cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a

estudiar los objetos en sí como unidades de información. Para los años 90 se

quiere dar respuesta al entorno siempre cambiante y en rápida evolución en que

se han de desarrollar los programas informáticos, lo cual da lugar a trabajar en

ciclos cortos (como mini-proyectos) que implementan una parte de las

funcionalidades, pero sin perder el rumbo general del proyecto global.

Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en

lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos

durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos

van buscando minimizar riesgos y, puesto que los errores más perjudiciales se

producen en los primeros pasos, se comienza ya desde la fase más general del

estudio por analizar los riesgos que significa seguir con las siguientes fases del

desarrollo.

Las metodologías más utilizadas a nivel mundial en orden cronológico:

Década de los 70s

Programación Estructurada Jackson desde 1975

Década de los 80s

Structured Systems Analysis and Design Methodology (SSADM) desde

1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la Información (IE/IEM) desde 1981

Década de los 90s

Rapid Application Development (RAD) desde 1991.

Programación Orientada a Objetos (OOP) a lo largo de la década de los

90's

Virtual Finite State Machine (VFSM) desde 1990s

Dynamic Systems Development Method desarrollado en UK desde 1995.

Rational Unified Process (RUP) desde 1999

Año 2000 en adelante

Extreme Programming (XP) desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Constructionist Design Methodology (CDM) desde 2004 por Kristinn R.

Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler

RAD

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid

application development) es un proceso de desarrollo de software, desarrollado

inicialmente por James Maslow en 1980. El método comprende el desarrollo

interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer

Aided Software Engineering).

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la

usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces

gráficas de usuario tales como Glade, o entornos de desarrollo

integrado completos. Algunas de las plataformas más conocidas son Visual Studio,

Lazarus, Gambas, Delphi,Foxpro ,Anjuta, Game Maker, Velneo o Clarión.

En el área de la autoría multimedia, software como Neosoft Neobook y

MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de

aplicaciones, dentro de ciertos límites.

Programación Orientada a Objetos (OOP)

En el paradigma de programación orientada a objetos (POO, o bien OOP en

inglés), un objeto se define como la unidad que en tiempo de ejecución realiza las

tareas de un programa. También a un nivel más básico se define como la instancia

de una clase.Estos objetos interactúan unos con otros, en contraposición a la

visión tradicional en la cual un programa es una colección de subrutinas (funciones

o procedimientos), o simplemente una lista de instrucciones para el computador.

Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a

otros objetos de manera similar a un servicio.

En el mundo de la programación orientada a objetos (POO), un objeto es el

resultado de la instanciación de una clase.

Una clase es el anteproyecto que ofrece la funcionalidad en ella definida, pero

ésta queda implementada sólo al crear una instancia de la clase, en la forma de un

objeto.

Rational Unified Process (RUP)

El Proceso Unificado de Rational (Rational Unified Process en inglés,

habitualmente resumido como RUP) es un proceso de desarrollo de software

desarrollado por la empresa Rational Software, actualmente propiedad de IBM.

Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología

estándar más utilizada para el análisis, diseño, implementación y documentación

de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de

metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software, también desarrollado por

Rational, que incluye información entrelazada de diversos artefactos y

descripciones de las diversas actividades. Está incluido en el Rational Method

Composer (RMC), que permite la personalización de acuerdo con las

necesidades.

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso

El proceso deberá adaptarse a las necesidades del cliente ya que es muy

importante interactuar con él. Las características propias del proyecto u

organización, el tamaño del mismo, así como su tipo o las regulaciones que lo

condicionen, influirán en su diseño específico. También se deberá tener en cuenta

el alcance del proyecto en un área subformal para hacer un proceso de

satisfacción del software.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios

o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los

deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que

surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.

En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad

del producto, y se refina la dirección del proyecto así como también los riesgos

involucrados.

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos.

Debe haber una comunicación fluida para coordinar requisitos, desarrollo,

evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como

patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por

nombrar algunos. Esto evita que los ingenieros de software vayan directamente de

los requisitos a la codificación de software a la medida del cliente, sin saber con

certeza qué codificar para satisfacer de la mejor manera los requisitos y sin

comenzar desde un principio pensando en la reutilización del código. Un alto nivel

de abstracción también permite discusiones sobre diversos niveles y soluciones

arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de

la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad El control de calidad no debe realizarse al final de cada

iteración, sino en todos los aspectos de la producción. El aseguramiento de la

calidad forma parte del proceso de desarrollo y no de un grupo independiente.

CICLO DE VIDA

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado

ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida

organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias

iteraciones en número variable según el proyecto y en las que se hace un mayor o

menor hincapié en las distintas actividades. En la Figura muestra cómo varía el

esfuerzo asociado a las disciplinas según la fase en la que se encuentre el

proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la

comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,

la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea

Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de

modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline

de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de

negocios (refinamiento), análisis, diseño y una parte de implementación

orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por

medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su

análisis y diseño y se procede a su implementación y pruebas. Se realiza una

pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se

termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero

dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

"The Unified Software Development Process (" El Proceso Unificado de Desarrollo

de Software (publicado en 1999 por Ivar Jacobson, Grady Booch y James

Rumbaugh.

PROGRAMACION EXTREMA

Según Kent Beck 1999

ORIGEN DE LA METODOLOGÍA XP

La programación extrema o extreme Programming (XP) es una metodología de

desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer

libro sobre la materia, Extreme Programming Explained: Embrace Change (1999).

Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que

éstos, la programación extrema se diferencia de las metodologías tradicionales

principalmente en que pone más énfasis en la adaptabilidad que en la

previsibilidad. Los defensores de la XP consideran que los cambios de requisitos

sobre la marcha son un aspecto natural, inevitable e incluso deseable del

desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de

requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y

más realista que intentar definir todos los requisitos al comienzo del proyecto e

invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores

metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el

proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

CARACTERÍSTICAS DE LA METODOLOGÍA XP

Se diferencia de las metodologías tradicionales principalmente en que pone Más

Énfasis en la adaptabilidad que en la previsibilidad.

Se aplica de manera dinámica durante el ciclo de vida del software.

Es capaz de adaptarse a los cambios de requisitos.

Los individuos e interacciones son más importantes que los procesos y

Herramientas. Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito de un proyecto

software. Es más importante construir un buen equipo que construir el entorno.

Muchas veces se comete el error de construir primero el entorno y esperar que el

equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure

su propio entorno de desarrollo en base a sus necesidades. Software que funcione

es más importante que documentación exhaustiva. Desarrollar software que

funciona más que conseguir una buena Documentación La regla a seguir es no

producir documentos a menos que sean necesarios de Forma inmediata para

tomar una decisión importante. Estos documentos deben ser cortos y centrarse

en lo fundamental

Nivel de madurez, software del proceso

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los

Estados Unidos de América (en particular del Departamento de Defensa, DoD),

desarrolló una primera definición de un modelo de madurez de procesos en el

desarrollo de software, que se publicó en septiembre de 1987. Este trabajo

evolucionó al modelo CMM o SW-CMM(CMM for Software), cuya última versión

(v1.1) se publicó en febrero de 1993.

Este modelo establece un conjunto de prácticas o procesos clave agrupados en

Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso

define un conjunto de buenas prácticas que habrán de ser:

Definidas en un procedimiento documentado

Provistas (la organización) de los medios y formación necesarios

Ejecutadas de un modo sistemático, universal y uniforme

(institucionalizadas)

Medidas

Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez",

de modo que una organización que tenga institucionalizadas todas las

prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado

ese nivel de madurez.

La creciente necesidad, sumada a décadas de promesas incumplidas en cuanto a

calidad, costos y cumplimiento en el desarrollo de software, condujo al Instituto de

Ingeniería del Software (SEI) de la Universidad Carnegie Mellon de Pittsburgha

desarrollar un método para evaluar el nivel de madurez del proceso de desarrollo

del software de una empresa u organismo. El proceso se evalúa mediante un

cuestionario y las respuestas sirven para determinar una magnitud denominada

"Nivel de Madurez del Proceso". El modelo se llama CMM (Capability Maturity

Model - Modelo de Madurez de Capacidad).

En principio fue creado para evaluar y mejorar la capacidad de los contratistas de

software del Departamento de Defensa de los Estados Unidos, el modelo CMM se

convirtió a través de los años en el más alto estándar de ingeniería en el mundo

para todo tipo de compañías. Está fundamentado en prácticas reales de las

compañías más avanzadas, y refleja lo mejor en procesos de desarrollo de

software.

El CMM está compuesto de 316 prácticas claves agrupadas en 18 áreas y

distribuidas en una jerarquía de cinco niveles, a través de los cuales una

organización progresivamente alcanza mayor calidad, productividad y menores

costos en el desarrollo de software. Los niveles progresan desde el 1, que

representa el estado caótico, hasta el nivel 5, que representa el estado de

optimización continua. Un modelo posterior es el CMMI, siglas de Modelo de

Madurez de Capacidad Integrado.

El valor obtenido es un indicador de toda la empresa, aunque puede darse el caso

de que en algún departamento tenga un nivel de madurez mayor o inferior al

resultante. Los niveles de madurez del proceso son cinco:

Inicial. La empresa no dispone de procesos y controles definidos

Se trabaja con procedimientos que no están normalizados, es decir,

procedimientos tanto del propio desarrollo de software como de su planificación y

control, que no están establecidos explícitamente antes de su uso.

Por otro lado las técnicas y/o herramientas que se emplean para el desarrollo del

software carecen de una integración entre las mismas y únicamente son

empleadas en algunas fases del ciclo de vida del software.

La característica de las empresas que se encuentran en este nivel es que no hay

un control de la gestión de proyectos software efectivo, porque puede suceder que

la empresa disponga de procedimientos y técnicas formales, tanto de gestión

como del proceso, y de herramientas, pero no se utilizan de manera estándar en

todos los proyectos

Repetible. La empresa tiene métodos estandarizados facilitando procesos

repetibles

Las empresas que se encuentran en este nivel son las que disponen de un control

básico de la gestión de proyectos, gestión de calidad y gestión de la configuración.

El problema en este tipo de organización es que introducir cualquier cambio tiene

un alto grado de riesgo de fracaso.

Definido. La empresa monitoriza y mejora sus procesos.

Las empresas que se encuentran en este nivel se caracterizan por disponer de:

- Un grupo de proceso, cuyo objetivo es el de mejorar el proceso software.

- Una metodología de desarrollo software que describa las actividades técnicas y

de gestión requeridas para la adecuada ejecución del proceso.

Gestionado. La empresa posee controles avanzados, métricas y retroalimentación

Las empresas que han alcanzado este nivel disponen de un control de los costes y

calidad de las principales etapas del proceso. Es prerequisito que exista una

metodología de desarrollo software para realizar una medición efectiva.

Optimización.

La empresa emplea métricas con propósitos de optimización.

En este nivel, las organizaciones se encuentran en un proceso de mejora

continua. Se usan todos los procesos y técnicas modernas, lo mismo que la

administración cuantitativa. Las organizaciones se enfocan en la mejora a través

de técnicas y procesos de prevención de defectos, cambios en tecnología y

cambios en procesos. Menos del 0.1% de las organizaciones en el mundo se

encuentran en este nivel de madurez.

-SEI - Software Engeniering Institute