UNIDAD II. METODOLOGIAS DE DESARROLLO
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.
2.1 METODOLOGIAS CLASICAS
Bass
(2001) establece que los modelos de desarrollo de software son una
representación gráfica del proceso del software, y se cuenta con los siguientes
tipos de modelos Genéricos:
•
Modelo de Cascada
•
De Desarrollo Evolutivo
•
Prototipado
•
Transformación Formal
•
Desarrollo basado en la Reutilización
“El
modelado es un conjunto de componentes y relaciones entre esos componentes.
Esto se puede ilustrar gráficamente en un modelo arquitectónico del sistema, el
cual proporciona al lector un panorama de la organización del sistema” (Bass,
2001).
2.1.1 CASCADA
“Modelo
de Cascada.
Su
proceso es Separar en distintas fases de especificación y desarrollo y las
fases en
que
se subdivide son:
•
Análisis de requerimientos y definición.
•
Diseño del sistema y del software.
•
Implementación y prueba de unidades
•
Integración y prueba del sistema.
•
Operación y mantenimiento.
La
dificultad en esta modelo reside, en realizar cambios entre las etapas.
2.1.2 INCREMENTAL
El Modelo
Incremental combina elementos del MLS con la filosofía interactiva de construcción
de prototipos.
En una
visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y
Prueba. Sin embargo, para la producción del Software, se usa el principio de
trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de
programación. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento.
Es el
mismo cliente el que incluye o desecha elementos al final de cada incremento a
fin de que el software se adapte mejor a sus necesidades reales. El proceso se
repite hasta que se elabore el producto completo.
De esta
forma el tiempo de entrega se reduce considerablemente.
Al igual
que los otros métodos de modelado, el Modelo Incremental es de naturaleza
interactiva pero se diferencia de aquellos en que al final de cada incremento
se entrega un producto completamente operacional.
El Modelo
Incremental es particularmente útil cuando no se cuenta con una dotación de
personal suficiente. Los primeros pasos los pueden realizar un grupo reducido
de personas y en cada incremento se añadir personal, de ser necesario. Por otro
lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma
grafica:
- Se
evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El
usuario se involucra más.
- Difícil
de evaluar el coste total.
- Difícil
de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
-
Requiere gestores experimentados.
- Los
errores en los requisitos se detectan tarde.
- El
resultado puede ser muy positivo.
Ventajas:
- Con un
paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se
implementa la funcionalidad parcial.
- También
provee un impacto ventajoso frente al cliente, que es la entrega temprana de
partes operativas del Software.
- El
modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite
entregar al cliente un producto más rápido en comparación del modelo de
cascada.
- Resulta
más sencillo acomodar cambios al acotar el tamaño de los incrementos.
- Por su
versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo
como técnico.
Desventajas:
- El
modelo Incremental no es recomendable para casos de sistemas de tiempo real, de
alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de
riesgos.
-
Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere
de metas claras para conocer el estado del proyecto.
2.1.3 EVOLUTIVO
El modelo
Evolutivo consiste en hacer la documentación de las fases, realizando un
prototipo del sistema, se evalúa el qué tan lejos el prototipo está de la
solución final esperada por el cliente; se toman en cuenta las observaciones de
esta evaluación, y se crea un nuevo prototipo que las incluya.
VENTAJA
La
ventaja es que es ideal para sistemas que no tienen bien definidos los
requerimientos, es decir, para la mayoría de los sistemas que se desarrollan.
DESVENTAJA
Es
difícil distinguirlo del proceso "codifica y corrige", pues en cierta
medida son parecidos, la diferencia está que en la práctica se requiere que al
construir el prototipo se aplique el análisis y el diseño pero sólo a una parte
de los requerimientos ya entendidos, que se documente y se codifique.
2.1.4 ESPIRAL
El modelo espiral, propuesto originalmente por B. Boehm, es
un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa
de construcción de prototipos con los aspectos controlados y sistemáticos del
modelo en cascada, añadiendo un Nuevo elemento: el análisis de riesgo . El
modelo, representado mediante la espiral, define cuatro actividades
principales:
• Planificación. Determinación de objetivos, alternativas y
restricciones.
• Análisis de riesgo. Análisis de alternativas e
identificación/resolución de riesgos.
• Ingeniería. Desarrollo del producto del “siguiente nivel”.
• Evaluación del cliente. Valorización de los resultados de
la ingeniería.
Durante la primera vuelta alrededor de la espiral se definen
los objetivos, las alternati-vas y las restricciones, y se analizan e
identifican los riesgos. Si el análisis de riesgo indica que hay una
incertidumbre en los requisitos, se puede usar la creación de prototipos en el
cuadrante de ingeniería para dar asistencia, tanto al encargado de desarrollo
como al cliente. Éste evalúa el trabajo de ingeniería (cuadrante de evaluación
de cliente) y sugiere modificaciones.
Sobre la base de los comentarios del cliente se produce la
siguiente fase de planificación y de análisis de riesgo; en cada bucle
alrededor de la espiral, la culminación del análisis de riesgo resulta en una
decisión de “seguir o no seguir”. Con cada iteración alrededor de la espiral
(comenzando en el centro y siguiendo hacia el exterior), se construyen
sucesivas versiones del software, cada vez más completa y, al final, al propio
sistema operacional.
Actualmente, el paradigma del modelo en espiral para la ingeniería de software es el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un
enfoque evolutivo para la ingeniería de software, puesto que
le permite al desarrollador y al cliente entender y reaccionar conforme a los
riesgos en cada nivel evolutivo. De igual forma, utiliza la creación de
prototipos como un mecanismo de reducción de riesgo, pero, lo que es más
importante permite a quien lo desarrolla aplicar el enfoque de creación de
prototipos en cualquier etapa de la evolución de prototipos .
2.1.5 PROTOTIPOS
El
prototipado de software es la animación y demostración de los requerimientos
del sistema. Los usos de los prototipos del sistema son:
•
El uso principal, es que le ayuda a los clientes y los desarrolladores para
entender los requerimientos del sistema
•
El prototipo puede ser usado para entrenamiento antes de que el sistema final
sea entregado.
•
El prototipo puede ser utilizado para pruebas
2.1.6 DESARROLLO BASADO EN COMPONENTES
La ingeniería de software basada en componentes (CBSE) (también conocida como desarrollo basado en componentes (CBD)) es una rama de
la ingeniería de software que enfatiza la separación de
asuntos (separation of concerns (SoC)) por lo que se refiere a la
funcionalidad de ámplio rango disponible a través de un sistema de software
dado. Es un acercamiento basado en la reutilización para definir, implementar,
y componer, componentes débilmente acoplados en sistemas. Esta
práctica apunta traer igualmente un ámplio grado de beneficios tanto en el
corto como el largo plazo, para el software en sí mismo, y para las
organizaciones que patrocinan tal software.
Los ingenieros
de software consideran los componentes como parte de la plataforma inicial
para la orientación a servicios. Los componentes juegan este rol, por
ejemplo, en servicios de web, y más recientemente, en
las arquitecturas orientadas a servicios (SOA), por el que un
componente es convertido por el servicio web en un servicio y subsecuentemente
hereda otras características más allá de las de un componente ordinario.
Los
componentes pueden producir o consumir eventos y pueden ser usados para
las arquitecturas dirigida por eventos(EDA).
Un componente de software individual
es un paquete de software, un servicio web, o
un módulo que encapsula un conjunto de funciones relacionadas
(o de datos).
Todos los
procesos del sistema son colocados en componentes separados de tal manera que
todos los datos y funciones dentro de cada componente
están semánticamenterelacionados (justo como con el contenimiento
de clases). Debido a este principio, con frecuencia se dice que los
componentes son modulares y cohesivos.
Con
respecto a la coordinación a lo largo del sistema, los componentes se comunican
uno con el otro por medio de interfaces. Cuando un componente ofrece servicios
al resto del sistema, éste adopta una interface proporcionada que especifica
los servicios que otros componentes pueden utilizar.
2.2 OTRAS METODOLOGIAS
2.2.1 GANAR- GANAR
El modelo en espiral tratado anteriormente sugiere una
actividad del marco de trabajo que aborda la comunicación con el cliente.El
objetivo de esta actividad es mostrar los requisitos del cliente. En un
contexto ideal,el desarrollador simplemente le pregunta al cliente lo que
necesita y el cliente proporciona detalles
suficientes para continuar. Desgraciadamente, esto
raramente ocurre. En realidad, el cliente y el desarrollador entranen un
proceso de negociación, en el cual el cliente puede ser preguntado para sopesar
la funcionalidad, el rendimiento y otros productos o características del sistema
frente al coste y al tiempo de comercialización.Las mejores negociaciones se
esfuerzan en obtener “gana-gana”. Esto es, el cliente gana obteniendo el
producto o sistema que satisface la mayor parte de sus necesidades y el
desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de
entrega realista.
El modelo en espiral win-win define un conjunto de actividades de
negociación al principio de cada paso alrededor de la espiral. Además del
énfasis realizado en la negociación inicial, el modelo en espiral win-win
introduce tres hitos en el proceso, llamados puntos de fijación, que ayudan a
establecer la completitud de un ciclo alrededor de la espiral y proporcionan
hitos de decisión antes de continuar el proyecto de software.
En esencia, los puntos de fijación representan tres visiones
diferentes del progreso mientras
que el proyecto recorre la espiral.
El primer punto de
fijación, llamado objetivos del ciclo de vida, define un conjunto de objetivos
para cada actividad principal de ingeniería de software. El segundo punto de
fijación, llamado arquitectura del ciclo de vida, establece los objetivos que
se deben conocer, mientras que se define la arquitectura del software y el
sistema. La capacidad operativa inicial es el tercer punto de fijación y
representa un conjunto de objetivos asociados a la preparación del software
para la instalación y distribución.
2.2.2 PROCESO UNIFICADO
RUP (Rational Unified Process)
RUP (Rational Unified Process) es una metodología que permite
construir software en tiempo y
precio justos. RUP utiliza UML
(Unified Modeling Language), para
especificar, visualizar, construir y documentar sistemas de software. También representa un conjunto de las mejores prácticas de ingeniería que han
probado ser exitosas en el modelo
de sistemas, reduciendo la complejidad y el diseño de los procesos.
Un proceso de Ingeniería de Software requiere actividades del
ciclo de vida de los sistemas. Como respuesta a ello Rational Software Corp.
pone a disposición herramientas que están diseñadas para hacer más eficiente la
aplicación de metodologías como el RUP, de esa forma se permite la creación de
un ambiente de desarrollo óptimo. El conjunto de herramientas de Rational está
basado en seis principios fundamentales para el desarrollo de software,
denominadas las seis mejores prácticas que son: administración de los
requerimientos, desarrollar en forma iterativa, modelar visualmente, pruebas
continuas, arquitecturas basadas en en componentes y control de cambios.
2.2.3 INGENIERIA WEB
Es la
aplicación de metodologías sistemáticas, disciplinadas y cuantificables al
desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en
la World Wide Web.1
La
ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web
está ocasionando un impacto en la sociedad y el nuevo manejo que se le está
dando a lainformación en las diferentes áreas en que se presenta ha hecho
que las personas tiendan a realizar todas sus actividades por esta vía.
Desde que
esto empezó a suceder el Internet se volvió más que una diversión y
empezó a ser tomado más en serio, ya que el aumento de publicaciones y de
informaciones hizo que la Web se volviera como un desafío para los (Ingeniería
del software) ingenieros del software, a raíz de esto se crearon enfoques
disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos
específicos de este nuevo medio.
Uno de
los aspectos más tenidos en cuenta, en el desarrollo de sitios web es
sin duda alguna el diseño gráfico y la organización estructural del
contenido. En la actualidad la web está sufriendo grandes cambios, que han
obligado a expertos en el tema a utilizar herramientas y técnicas basadas en
la ingeniería del software, para poder garantizar el buen
funcionamiento y administración de los sitios web. ´
Para
garantizar el buen funcionamiento y mantenimiento de los sitios web, este debe
contar con ciertos atributos y características que en conjunto forman un
concepto muy importante, para alcanzar el éxito en cualquier organización,
herramienta, y todo aquello que se pueda considerar como servicio. Dicho
concepto es la calidad, que con atributos como, usabilidad, navegabilidad,
seguridad, mantenibilidad, entre otros, hace posible por un lado la eficiencia
del artefacto web y por ende la satisfacción del usuario final.
Entonces
la ingeniería de la Web es la aplicación de metodologías sistemáticas,
disciplinadas y cuantificables al desarrollo eficiente, operación y evolución
de aplicaciones de alta calidad en la World Wide Web. En este
sentido, la ingeniería de la Web hace referencia a las metodologías, técnicas y
herramientas que se utilizan en el desarrollo deaplicaciones Web complejas
y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo,
implementación y evolución de dichas aplicaciones.
2.2.4 METODOLOGIAS AGILES
El desarrollo
ágil de software son métodos de ingeniería del software basado en el desarrollo
iterativo e incremental, donde los requerimientos y soluciones evolucionan
mediante la colaboración de grupos auto organizado y multidisciplinario.
Algunos
métodos ágiles de desarrollo de software:
1.-Adaptive Software Development (ASD).
2.-Agile Unified Process (AUP).
3.-Essential Unified Process (EssUP).
4.-Feature Driven Development (FDD).
5.-Lean Software Development (LSD).
6.-Kanban.
7.-Open Unified Process (OpenUP).
8.-Programación Extrema (XP).
9.-Scrum.
