View
220
Download
0
Category
Preview:
DESCRIPTION
Â
Citation preview
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
Recommended