Conceptos importantes
Ciclo de
vida: Describe los procesos y las
actividades involucradas en el desarrollo y uso del software, abarcando la vida
del sistema desde la definición de los requisitos hasta la finalización de su
uso.
Proceso: Un
conjunto de tareas ordenadas que tienen como objetivo alcanzar o cumplir
algunas metas.
Método: Proceso o camino
sistemático establecido para realizar una tarea o trabajo con el fin de
alcanzar un objetivo predeterminado. Método es
una palabra que proviene del término griego y que se refiere al medio utilizado para llegar a un
fin. Su significado original
señala el camino que conduce a un lugar.
Metodología: El
concepto hace referencia al plan de investigación
que permite cumplir ciertos objetivos en el marco de una ciencia, es el conjunto
de métodos por los cuales se regirá una investigación,
lo que pre eminentemente hace la metodología es estudiar los métodos para luego
determinar cuál es el más adecuado a aplicar o sistematizar en una investigación
o trabajo. Por lo tanto, puede entenderse a la
metodología como el conjunto de procedimientos que determinan una investigación de tipo
científico o marcan el rumbo de una exposición doctrinal.
Herramienta: software o metodologías
auxiliares utilizados por el programador o desarrollador para la construcción o
diseño de algún sistema o proyecto. Esta puede ser útil para que el desarrollo
sean más rápido así como más claros los pasos a seguir para quienes trabajaran
en el sistema.
Paradigma: Es un estilo o bien una forma
particular de realizar algo. En este caso cada modelo de proceso puede ser un
paradigma, puesto que cada uno tiene sus propias características y reglas, las
cuales se tienen que respetar para lograr el resultado indicado.
Modelo incremental
El modelo
incremental combina elementos del modelo lineal secuencial (aplicados
repetidamente) con la filosofía interactiva de construcción de prototipos. El modelo incremental aplica secuencias
lineales de forma escalonada mientras progresa el tiempo en el calendario.
Cada secuencia lineal produce un
«incremento» del software.
Cada etapa
consiste de requerimientos, diseño, codificación, pruebas, y entrega.
Permite entregar al cliente un producto más
rápido en comparación del modelo de cascada.
La propuesta del modelo es diseñar sistemas que
puedan entregarse por piezas.
Construir un sistema pequeño es siempre menos
riesgoso que construir un sistema grande.
Los primeros incrementos son versiones «incompletas»
del producto final, pero proporcionan al usuario la funcionalidad que precisa y
también una plataforma para la evaluación.
PUNTO CLAVE
El modelo incremental entrega el software en
partes pequeños, pero utilizables, llamadas (incrementos). En general, cada incremento se construye sobre aquél que ya ha sido entregado.
Reduce los
riesgos ya que:
- Permite
atacar los mayores riesgos desde el inicio.
- El progreso
se puede medir en periodos cortos de tiempo.
- Resulta más
sencillo acomodar cambios al acotar el tamaño de los incrementos.
- Se puede
planear en base a la funcionalidad que se quiere entregar primero.
Ventajas
- La solución
se va mejorando en forma progresiva a través de las múltiples iteraciones.
- Incrementa
el entendimiento del problema y de la solución por medio de los refinamientos
sucesivos.
Desventajas
- Requiere de
mucha planeación, tanto administrativa como técnica.
- Requiere de
metas claras para conocer el estado del proyecto.
Modelo De
Desarrollo Incremental
Los
requerimientos del usuario se priorizan y los requerimientos de prioridad más
altos son incluidos en los incrementos tempranos.
Difícil de
aplicar a sistemas transaccionales que tienden a ser integrados y a operar como
un todo.
Beneficios:
El desarrollo
incremental es particularmente útil cuando la dotación de personal no está
disponible para una implementación completa en la fecha límite que se haya
establecido para el proyecto. Los primeros incrementos se pueden implementar
con menos personas.
Ejemplo:
Un
procesador de texto que sea desarrollado bajo el paradigma Incremental podría
aportar, en principio, funciones básicas de edición de archivos y producción de
documentos (algo como un editor simple). En un segundo incremento se le podría
agregar edición más sofisticada, y de generación y mezcla de documentos. En un
tercer incremento podría considerarse el agregado de funciones de corrección
ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de
dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al
procesador final requerido. Así, el producto va creciendo, acercándose a su
meta final, pero desde la entrega del primer incremento ya es útil y funcional
para el cliente, el cual observa una respuesta rápida en cuanto a entrega
temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni
tan definida, lo que da margen de operación y alivia presiones al equipo de
desarrollo.
Con cada
incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien
se mejora la versión previamente implementada del producto software. Este
modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan
cambios en los requisitos por parte del usuario, un cambio de requisitos
propuesto y aprobado puede analizarse e implementarse como un nuevo incremento
o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado.
Modelo de
Espiral
Modelo propuesto
por Barry Boehm, se basa en las experiencias que se van obteniendo conforme
avanza en el proyecto. Un aspecto importante es que hace énfasis en la
reducción de los riesgos durante el desarrollo del software.
Provee un enfoque
cíclico de tal manera que el proyecto se
vaya desarrollando de forma incremental
y al mismo tiempo se minimicen los riesgos conforme el proyecto va
avanzando.
Obsérvese que el
modelo se ilustra en cuatro cuadrantes y conforme se va desarrollando el
proyecto se atraviesan los cuatro cuadrantes.
Cada cuadrante
sigue los siguientes propósitos:
- El cuadrante 1 identifica los
objetivos, alternativas y restricciones en cada ciclo del espiral.
- El dos evalúa las alternativas
y restricciones. Muchos riesgos son identificados y evaluados.
- En el tres se hace una mejor
evaluación de riesgos y se desarrolla un prototipo que promueva una reducción
significativa de riesgos con el fin de que la siguiente tarea sea el diseño o
la implementación de código.
- El cuarto valida el objetivo
logrado y el plan para el siguiente paso en el ciclo.
El modelo en
espiral implica un control continuo de los requerimientos hasta obtener el
resultado deseado o bien hasta que sea demuestre que ya no se puede mejorar el
proceso. Sin embargo el modelo no puede evitar rehacer una tarea porque
posiblemente se identifique un nuevo riesgo.
Scrum

¿Quién
utiliza Scrum y por qué?
Cualquiera que
tenga un proyecto complejo puede beneficiarse del uso de Scrum. Dar
prioridad a las grandes listas de tareas pendientes en tareas manejables con un
mejor trabajo en equipo, mejorar la comunicación y resultados más rápidos.
Utilizar Scrum para entregar
proyectos por valor a los clientes. Los militares se
han basado en Scrum para preparar barcos para la implementación. En el mundo del automóvil, Equipo Wikispeed está utilizando Scrum para construir un
coche rápido asequible, ultra-eficiente seguro del viajero que debe vender por
menos de $ 20.000. Así que si
usted está trabajando en la próxima aplicación para teléfonos inteligentes, la
gestión de la logística de un almacén, o la planificación de un evento de
caridad, usted debe echar un vistazo más de cerca el uso de Scrum.
Beneficios SCRUM
- clientes satisfechos
- mejor retorno de
la inversión
- costo reducido
- resultados rápidos
- confianza para
tener éxito en un mundo complejo
Sus principales actividades
En el modelo de
Scrum, la primera actividad de cada sprint es una reunión de planificación
de Sprint . Durante esta reunión, el propietario del producto y el
equipo hablan sobre los temas de mayor prioridad en el trabajo pendiente
del producto scrum . Los miembros del equipo deben averiguar el
número de elementos que pueden comprometerse, y luego crear un trabajo
pendiente del sprint, que es una lista de las tareas a realizar durante el
sprint.
Durante cada sprint, periodo definido por cada
equipo que normalmente es de entre una y cuatro semanas, el equipo crea una
nueva versión de software potencialmente
entregable, utilizable o usable.
Esta metodología
de procesos ágiles establece que en cada día de la Scrum sprint estén presentes
todos los miembros del equipo, incluido el ScrumMaster y el propietario del
producto. Una reunión de duración fija para no más de 15
minutos. Durante ese tiempo, los miembros del equipo comparten lo que han
trabajado el día anterior, trabajará en la actualidad, e identificar los
obstáculos para el progreso. Scrums diario sirven para sincronizar el trabajo
de los miembros del equipo que hablarán de la obra del sprint.
Al final de un
Scrum Sprint, los equipos llevan a cabo una revisión de sprint. Durante
el sprint opinión el equipo demuestra la funcionalidad durante el
sprint. El objetivo de esta reunión es obtener información del propietario
del producto o los usuarios u otras partes interesadas que han sido invitados a
la revisión. Esta información puede dar lugar a cambios en la
funcionalidad recién entregada. Pero puede ser un resultado en la revisión
o añadir elementos a la acumulación de productos Scrum.
Otra actividad que
se realiza al final de cada sprint es la retrospectiva sprint. Todo el
equipo participa en esta reunión, incluyendo el ScrumMaster y el propietario
del producto. La reunión es una oportunidad para reflexionar sobre el sprint
que termina e identificar oportunidades para mejorar en el nuevo sprint.
Actividades del desarrollo de software
Cuando se nos plantea un problema
tenemos diferentes ideas de abordarlo para llegar a su solución, para poder
lograrlo es necesario realizar ciertas actividades. Dichas actividades deben de
tener un principio y un fin, para esto existen diferentes modelos de procesos
de software que nos ayudan en la elaboración, algunos de éstos tienen definidos
pasos que deben de realizarse estrictamente, lo que ocasiona que no todas las
veces nos garantice su solución. En la vida real solo se toman en cuenta qué es
lo que podemos hacer, como una guía; pero si optamos por algún modelo es
necesario regresar a algún paso y de ahí desplazarte hacia otro y no cumplir
firmemente con lo qué él especifica, no todos los problemas son iguales.

La imagen muestra el orden que
se debería seguir en cualquier desarrollo de software, ya que el orden en que
se encuentran las actividades es el indicado para organizar mejor la asignación
de recursos y la planificación de tiempos de inicio y terminación tanto de
ellas mismas como del proyecto en general.
La imagen muestra la situación que ocurre normalmente en el desarrollo de un software, ya que existen riesgos
que muchas veces se desconocen y al presentarse situaciones que no se tenían
planeadas se debe tomar otro camino, estos riesgos pueden presentarse en
cualquiera de las cuatro actividades, es por eso que las cuatro están
conectadas entre ellas mismas.
Se debe adaptar
una metodología pues se seguirían los pasos establecidos por ella, existen
distintas metodologías, cada una de ellas está planteada específicamente para
proyectos de software que cumplan con ciertas características, el orden en el
que se encuentran las actividades, es el
mejor para ese tipo de proyecto, se disminuirían las situaciones de riesgo como
las que ya antes mencionábamos y en caso de se presentaran estas, la misma
metodología nos guiaría acerca de que hacer para resolver las situaciones,
trabajando así de maneras más eficiente en el desarrollo de nuestro software.
http://www.mountaingoatsoftware.com/topics/scrum
http://www.scrumalliance.org/why-scrum/who-uses-scrum
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php