El desarrollo de software, ha ido evolucionando constantemente en las
metodologías o maneras en las cuales se realiza la planeación para el diseño
del software, con el objetivo de estructurar, controlar, mejorar y optimizar
los procesos y ofrecer una mejor calidad.
Esta demanda de desarrollo de software se debe principalmente a
la necesidad empresarial de gestionar sus procesos y facilitar, organizar y
administrar las tareas en una empresa.
¿QUÉ ES UN MÉTODO?
Un Método se compone por un
conjunto de herramientas y estrategias que una vez ordenados y sistematizados nos
permitirán conseguir una meta o lograr un objetivo definido. Permiten la ejecución de procesos que nos llevarán a
cumplir los objetivos que buscamos.
¿QUÉ ES METODOLOGÍA?
Se
encarga del estudio de los métodos .Una Metodología de desarrollo de software,
consiste específicamente en hacer uso de diversas herramientas, técnicas,
métodos y modelos para el desarrollo de un
software.
METODOLOGÍA
ÁGIL.
Existen numerosas metodologías
para desarrollar software. Tradicionalmente estas metodologías se centran en el
control del proceso, estableciendo rigurosamente las actividades, herramientas
y notaciones en el desarrollo de un software, dado estas reglas estas metodologías
se caracterizan por ser rígidos y dirigidos por la documentación que se genera
en cada una de las actividades desarrolladas. Debido a esto es necesario el
desarrollo de desarrollar metodologías más simples y sin tanta documentación durante
el proceso.
Una metodología ágil es un método que permite incorporar
cambios con rapidez en el desarrollo de un software. En muchas ocasiones, los
modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día
resulta fundamental: incorporar cambios con rapidez y en cualquier fase del
proyecto sin la necesidad de cambiar todo el desarrollo del proyecto.
Principales
características de las metodologías agiles:
- · Una metodología ágil se caracteriza por ser rápida, dinámica, con contenido específico y por responder de manera apropiada a los cambios y orientada al crecimiento.
- · Estimula las estructuras y actitudes de los equipos para que la comunicación sea fácil.
- · Resalta la entrega rápida de software operativo y le resta importancia a los productos de trabajo intermedio.
- · Adopta al cliente como una parte del equipo de desarrollo.
- · Satisface al cliente mediante la entrega temprana y continua de software valioso.
- · La estructura delos procesos ágiles cambia para le ventaja competitiva del cliente.
- · Entrega software en funcionamiento frecuentemente demorando desde un par de semanas aun par de meses.
- · Los desarrolladores y la gente de negocios deben trabajar juntos a diario durante el proyecto.
- · Utilizan la conversación cara a cara para transmitir la información hacia y dentro de un equipo de desarrollo.
- · Promueven el desarrollo sustentable.
- · Utilizan la simplicidad que es el arte que maximiza la cantidad de trabajo no realizado.
- · Su comportamiento se ajusta y se adecua en concordancia para volverse más efectivo.
METODOLOGÍA DE DESARROLLO PESADA
una metodología de desarrollo de software pesada Surge ante la necesidad de utilizar una serie de procedimientos, técnicas, herramientas y soporte documentada a la hora de desarrollar un producto (software). Se centra en la definición detallada de los procesos y tareas a realizar Y requiere una extensa documentación el cual debe ser seguido al pie de la letra para poder conseguir el producto final.
CARACTERÍSTICAS DE UNA METODOLOGÍA PESADA:
- § Son más complicadas .
- § Tienen mayor documentación y procesos que seguir al pie de la letra
- § Esta metodología solo es aplicable debido a que ya fue documentada.
- § Tiene modelos predeterminados para el desarrollo de un software
- § No son flexibles para el cambio durante el
desarrollo de un so
ftware.
Diferencias:
|
Metodologías pesadas
|
Metodologías Agiles
|
|
Basadas en normas provenientes de
estándares seguidos por el entorno de desarrollo
|
Basadas en heurísticas provenientes
de prácticas de producción de código
|
|
Cierta resistencia a los cambios
|
Especialmente preparados para
cambios durante el proyecto
|
|
Impuestas externamente
|
Impuestas internamente (por el
equipo)
|
|
Proceso mucho más controlado, con
numerosas políticas/normas
|
Proceso menos controlado, con pocos
principios.
|
|
El cliente interactúa con el equipo
de desarrollo mediante reuniones
|
El cliente es parte del equipo de
desarrollo
|
|
Más artefactos
|
Pocos artefactos
|
|
Más roles
|
Pocos roles
|
|
Grupos grandes y posiblemente
distribuidos
|
Grupos pequeños (<10
integrantes) y trabajando en el mismo sitio
|
|
La arquitectura del software es
esencial y se
expresa mediante modelos
|
Menos énfasis en la arquitectura
del software
|
|
Existe un contrato prefijado
|
No existe contrato tradicional o al
menos es bastante flexibles.
|
Metodologías Agiles
|
Metodologías Tradicionales
|
Están orientadas hacia las necesidades del cliente.
|
Están orientados hacia el proceso del software.
|
Basadas en heurísticas o estadísticas provenientes de prácticas de producción de código.
|
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo.
|
Especialmente preparadas para cambios durante el proyecto.
|
Cierta resistencia a los cambios.
|
Proceso menos controlado, con pocas políticas para el desarrollo.
|
Procesos mucha más controlados, con numerosas políticas o normas.
|
El cliente es parte del equipo de desarrollo
|
El cliente interactúa con el equipo de desarrollo mediante reuniones.
|
Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio.
|
Grupos grandes y posiblemente distribuidos.
|
Pocos artefactos
|
Más artefactos
|
Pocos roles
|
Más roles.
|
Menos énfasis en la arquitectura del software.
|
La arquitectura del software es esencial y se expresa mediante modelos.
|
Que es PMI
El Project Management Institute (PMI) es una de las asociaciones
profesionales estadounidense más grandes del mundo. Asocia a profesionales
relacionados con la gestión de proyectos y cuenta con medio millón de miembros
e individuos titulares de sus certificaciones en 180 países. Es una
organización sin fines de lucro que avanza la profesión de la dirección de
proyectos a través de estándares y certificaciones reconocidas mundialmente, a
través de comunidades de colaboración, de un extenso programa de investigación
y brinda oportunidades de desarrollo profesional.
La guía PMBOK
Project Management Body of Knowledge (PMBOK), es un instrumento de desarrollo del Project
Management Institute (PMI). El guía más conocido internacionalmente en
los estándares de gestión, administración y dirección de proyectos, conocido
como manual de buenas prácticas.
Tiene dos
aspectos fundamentales: macroprocesos, que agrupan todos los procesos y las
actividades implicadas en los proyectos estandarizados.
Los macroprocesos de la guía PMBOK
La guía PMBOK identifica 5 macroprocesos en los que
se incluyen los 47 procesos estándares que intervienen en cualquier proyecto:
- Inicio: conformado por 2
procesos menores, cuyo fin es definir
un nuevo proyecto o una nueva fase de ejecución del mismo, y
obtener la autorización necesaria para llevarlo a cabo.
- Planificación: este macroproceso incluye 24 procesos destinados a la concreción y el establecimiento de
objetivos, y al diseño de las estrategias más adecuadas para lograr
su consecución.
- Ejecución: incluye 8 procesos implicados en el correcto
desempeño, acorde a la estrategia adoptada, de las
actividades definidas en el proyecto para la consecución de los fines
establecidos.
- Control y monitorización:
consta de once procesos que se inscriben en este macroproceso, todos ellos
relacionados con la supervisión
y la evaluación del desempeño del proyecto.
LOS 47 PROCESOS DEL PMBOK
1.(Inicio) Desarrollar el acta de constitución del proyecto.
- 2.Identificar a los interesados.
- 4.Planificar el involucramiento de los interesados.
- 5.Planificar la gestión del alcance.
- 6.Recopilar los requisitos.
- 7.Definir el alcance.
- 8.Crear la EDT/WBS.
- 9.Planificar la gestión del cronograma.
- 10.Definir las actividades.
- 11.Secuenciar las actividades.
- 12.Planificar la gestión de los riesgos.
- 13.Identificar los riesgos.
- 14.Realizar el análisis cualitativo de riesgos.
- 15.Realizar el análisis cuantitativo de riesgos.
- 16.Planificar la respuesta a los riesgos.
- 17.Planificar la gestión de recursos.
- 18.Planificar la gestión de los costos.
- 19.Estimar los costos.
- 20.Estimar los recursos de las actividades.
- 21.Estimar la duración de las actividades.
- 22.Desarrollar el cronograma.
- 23.Determinar el presupuesto.
- 24.Planificar la gestión de la calidad.
- 25.Planificar la gestión de las comunicaciones.
- 26.Planificar la gestión de las adquisiciones.
- 27.(Ejecución) Dirigir y gestionar el trabajo del 28
- .proyecto.
- 28.Gestionar el conocimiento del proyecto (Nuevo)
- 29.Gestionar la participación de los interesados.
- 30.Adquirir recursos.
- 31.Desarrollar el equipo.
- 32.Dirigir al equipo.
- 33.Gestionar las comunicaciones.
- 34.Efectuar las adquisiciones.
- 35.Gestionar la calidad.
- 36.Implementar la respuesta a los riesgos (Nuevo)
- 37.(Monitoreo) Monitorear y controlar el trabajo del proyecto.
- 38.Realizar el control integrado de cambios.
- 39.Monitorear el involucramiento de los interesados.
- 40.Controlar el cronograma.
- 41.Controlar los costos.
- 42.Monitorear las comunicaciones.
- 43.Monitorear los riesgos.
- 44.Controlar la calidad.
- 45.Controlar los recursos (Nuevo)
- 46.Validar el alcance.
- 47.Controlar el alcance.
- 48.Controlar las adquisiciones.
- 49.Cerrar el proyecto o fase


