INSTITUTO TECNOLGICO SUPERIOR

DE COMALCALCO
ALUMNO
SMIRNA DEL CARMEN ALCUDIA GALLEGOS
PROFESOR
WILBERT COLORADO CANTO
MATERIA
GEST. PROY. SOFT
TRABAJO
INVESTIGACION
CARRERA
INGENIERIA EN SISTEMAS COMPUTACIONALES
GRADO Y GRUPO
SEPTIMO SEMESTRE GRUPO C
FECHA
COMALCALCO TAB. JUEVES 09 DE OCTUBRE DE 2014

COMPARACION DE LA METODOLOGIA SCRUM Y LA

METODOLOGIA GROW
Comparacin entre RUP y SCRUM:

Enfoque
Ciclo

Planificacin

Alcance

Los artefactos

RUP
Iterativo
Ciclo formal se define a
travs de 4 fases, pero
algunos flujos de trabajo
pueden ser concurrentes.
Plan de proyecto formal,
asociada
a
mltiples
iteraciones, se utiliza. El
plan es impulsado fecha
final y tambin cuenta con
hitos intermedios.

SCRUM
Iterativo
Cada sprint (iteracin) es un
ciclo completo.

No de extremo a extremo
del plan del proyecto. Cada
plan de la siguiente
iteracin se determina al
final de la iteracin actual
(no la fecha final de
traccin). Dueo
del
Producto
(usuario
de
negocios clave) determina
el momento en que el
proyecto se lleva a cabo.
En vez de alcance, SCRUM
utiliza una Cartera de
Proyectos, que se reevaluado al final de cada
iteracin (sprint).

mbito de aplicacin est

predefinido antes del inicio
del
proyecto
y
se
documenta
en
el
documento de Alcance.
mbito
de
aplicacin
pueden ser revisados
durante el proyecto, los
requisitos
se
estn
aclarando,
pero
estas
modificaciones
estn
sujetas a un procedimiento
estrictamente controlado.
Visin / mbito de
El nico artefacto formal es
aplicacin del documento,
el software operativo.
el paquete formal de
requisitos funcionales,
documento de arquitectura
del sistema, plan de

desarrollo, plan de pruebas,

scripts de prueba, etc
Tipo de proyecto / producto Recomendado para
grandes, a largo plazo, a
nivel de empresa con
proyectos a medio y alta
complejidad.

Recomendado para las

mejoras
rpidas
y
organizaciones que no
dependen de una fecha
lmite.

Metodologa rup
VentajasE
valuacin en cada fase que permite cambios de objetivos
Funciona bien en proyectos de innovacin.
Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar
el software.
Seguimiento detallado en cada una de las fases.
Desventajas
La evaluacin de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda
para l.
Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle
para poder acordar un alcance del proyecto con l.
Caractersticas de la metodologa RUP:
Casos de Uso:
Describe un servicio que el usuario requiere del sistema, incluye la secuencia completa de
interacciones entre el usuario y el sistema.
Centrado en la arquitectura:
Comprende las diferentes vistas del sistema en desarrollo, que corresponden a los
modelos del sistema: Modelos de casos de uso, de anlisis, de diseo, de despliegue e
implementacin. La arquitectura del software es importante para comprender el sistema
como un todo y a la vez en sus distintas partes (Abrahamsson, Salo, Ronkainen y Warsta,
2002), sirve para organizar el desarrollo, fomentar la reutilizacin de componentes y hacer
evolucionar el sistema, es decir, agregarle ms funcionalidad (Pressman y Murrieta, 2006)

En la figura 1 se aprecia la forma en que los modelos de la arquitectura se completan en

cada ciclo, ejemplo: se ve en la lnea base de la arquitectura que la barra que denota el
modelo de despliegue est clara e incompleta, evidencindose una implementacin
parcial del sistema, lo cual mostrara solo algunas funciones y propiedades del software en
construccin. A esta parcialidad en la implementacin se le conoce como arquitectura
ejecutable. En la misma grfica que se encuentra arriba se ve la misma barra pero un poco
ms oscura, lo cual muestra que el modelo se ha estado mejorando progresivamente,
mostrando que durante la construccin
los diferentes modelos se van desarrollando hasta completarse. De igual forma se aprecia
la misma barra en la lnea base al final de la construccin en la cual se ve la barra del
modelo de despliegue completa y con un color ms oscuro, esto obedece a los
refinamientos sucesivos que hace la metodologa RUP a la arquitectura ejecutable,
proporcionando de esta manera un prototipo evolutivo y funcional. De la misma manera
la arquitectura como tal no cambia drsticamente pues gran parte de la arquitectura se
defini durante la fase de elaboracin, pero puede agregar modelos as como lo muestra
la grfica con la adicin del modelo de pruebas a la misma arquitectura:

Figura 1. Arquitectura RUP. Fuente: Adaptado de RUP (Booch,

Rumbaugh y Jacobson, 2000)
Iterativo e Incremental:
Significa que la aplicacin se divide en pequeos proyectos, los cuales incorporan una
parte de las especificaciones, y el desarrollo de la misma es una iteracin que va
incrementando la funcionalidad del sistema de manera progresiva
(Silva, Barrera, Arroyave y Pineda, 2007) Tal como lo muestra la figura 2, una iteracin
est compuesta por los requisitos, anlisis, diseo, implementacin y pruebas; pero dicha
iteracin slo entrega una parte pequea pero funcional del sistema, de tal forma que los
requisitos y dems modelos no se desarrollan en una sola iteracin sino progresivamente,
ello con la finalidad de poder garantizar entregas funcionales e iterativas y de tal forma ir
completando el sistema software paso a paso. Cabe aclarar que una iteracin tambin
incluye otros artefactos que no estn explcitamente en la grfica, tales como la

planificacin y el anlisis de la iteracin, entre otras actividades especficas concebidas

dentro de esa iteracin.

METODOLOGIA SCRUM
Scrum es una metodologa gil, que puede ser usada para manejar el desarrollo de
productos complejos de software.
Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los
principios de de inspeccin continua, adaptacin, auto-gestin e innovacin.
Ventajas:
Cumplimiento de expectativas
Flexibilidad a cambios
El cliente puede empezar a utilizar las funcionalidades ms importantes del
proyecto antes de que est finalizado por completo
Mayor calidad del software mayor productividad (motivacin del equipo)
Reduccin de riesgos
Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con
las prestaciones que aportan mayor valor de negocio gracias a la priorizacin por
retorno de inversin
Predicciones de tiempos: se conoce la velocidad media del equipo por sprint, y es
fcilmente estimar para cuando se dispondr de una determinada funcionalidad
Desventajas:
Dificultad de aplicacin en grandes proyectos
Se requiere de experto en la metodologa que motorice su cumplimiento
Plantea un problema si el desarrollo est restringido por una fecha de entrega y un
precio de entrega cerrados por contrato
Presupone que los requerimientos cambian, pero no de forma que el cliente
acepte un diseo funcional/tcnico
Supone que el equipo est muy formado y motivado

Presupone que el cliente est muy involucrado en el desarrollo, y revisa

frecuentemente el avance de la funcionalidad, pero en realidad el cliente participa,
pero no hasta el punto de dedicar tiempo y recursos para revisar pequeos
avances en el desarrollo.
Caractersticas:
El desarrollo del software se realiza mediante iteraciones, denominadas sprint,
con una duracin de 30 das. El resultado de cada sprint es un incremento
ejecutable que se muestra al cliente.
Las reuniones a lo largo del proyecto, entre ellas destaca la reunin diaria de
15 minutos del equipo de desarrollo para coordinacin e integracin.

CRISIS DEL SOFTWARE Y COMO SOBREVIVIR ANTE ESTA CRISIS

LA CRISIS DEL SOFTWARE
La crisis del software se refiere a un conjunto de problemas encontrados en el desarrollo
del software de computadoras. Los problemas no estn limitados al software que no
funciona adecuadamente. Sino que la crisis del software abarca los problemas asociados
con cmo desarrollar el software, cmo mantener un volumen creciente de software
existente y cmo podemos esperar satisfacer la demanda creciente de software. Aunque
la referencia a una crisis del software puede ser criticada por ser algo melodramtico, la
frase sirve como un propsito til para alumbrar los problemas reales encontrados en
todas las reas de desarrollo del software.
Problemas
La crisis del software se caracteriza por muchos problemas, pero los responsables del
desarrollo del software se concentran sobre los aspectos de fondo: (1) la planificacin y
estimacin de coste es frecuentemente muy imprecisa; (2) la productividad de la gente
del software no se corresponde con la demanda de sus servicios, y (3) la calidad del
software no llega a ser a veces ni adecuada. Se ha sufrido el sobrepasar los costes en un
orden de magnitud. Se ha errado en la planificacin en meses o aos. Se ha hecho muy
poco para mejorar la productividad de los trabajadores en software. Los errores en los
nuevos programas producen en los clientes insatisfaccin y falta de confianza. Tales
problemas son slo las manifestaciones ms visibles de otras dificultades del software:
No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software. Sin
datos histricos como gua, la estimacin no ha sido buena y los resultados predichos muy
pobres. Sin una indicacin slida de productividad, no podemos evaluar con precisin la
eficacia de las nuevas herramientas, tcnicas o estndares.

 La insatisfaccin del cliente con el sistema terminado se produce demasiado

frecuentemente. Los proyectos de desarrollo del software se acometen frecuentemente
con slo una vaga indicacin de los requerimientos del cliente. Normalmente la
comunicacin entre el cliente y el que desarrolla el software es muy escasa.
La calidad del software es normalmente cuestionable. Hemos empezado a comprender
recientemente la importancia de la prueba sistemtica y tcnicamente completa del
software. Estn comenzando a emerger conceptos cuantitativos slidos sobre la fiabilidad
del software y garantas de calidad [IAN84].
El software existente puede ser muy difcil de mantener. La tarea de mantenimiento del
software se lleva la mayor parte de todos los dlares invertidos en software. El
mantenimiento no se ha considerado un criterio importante en la aceptacin del
software.
Hemos presentado primero las malas noticias. Ahora las buenas: todos los problemas
descritos anteriormente pueden corregirse. La clave est en dar un enfoque de ingeniera
al desarrollo del software, junto con la mejora continua de tcnicas y herramientas.
Permanecer un problema (podramos llamarlo un hecho de la vida). El software
absorber mayores y mayores porcentajes del coste de desarrollo global de los sistemas
basados en computadoras. En los Estados Unidos gastamos cerca de 50 billones de dlares
cada ao en el desarrollo, compra y mantenimiento de software de computadora. Nos
hemos tomado ms en serio los problemas asociados con el desarrollo del software.
Causas
Los problemas asociados con la crisis del software se han producido por el carcter del
propio software y por los errores de las personas encargadas del desarrollo del mismo. Sin
embargo, es posible que esperemos demasiado en demasiado poco tiempo. Despus de
todo, nuestra experiencia no va ms all de 35 aos.

El carcter del software de computadora se ha tratado brevemente en la seccin anterior.

Revismoslo, el software es un elemento lgico en vez de fsico; por tanto, el xito se
mide por la calidad de una nica entidad en vez de por muchas entidades fabricadas. El
software no se rompe. Si se encuentran fallos, existe una alta probabilidad de que se
introdujeran inadvertidamente durante el desarrollo y no se detectaran durante la
prueba. Reemplazamos las partes defectuosas durante el mantenimiento del software,
pero tenemos muy pocas, o incluso ninguna, piezas de repuesto; es decir, el
mantenimiento incluye normalmente la correccin o modificacin del diseo.

La naturaleza lgica del software presenta un desafi a la gente que lo desarrolla. Por
primera vez hemos aceptado la tarea de comunicarnos con un aliengena inteligente
una mquina. El desafi intelectual del desarrollo del software es seguramente una de las
causas de la crisis del software, pero los problemas tratados anteriormente han sido
causados por defectos humanos ms mundanos.
Los ejecutivos de nivel medio y alto sin conocimientos en software, han sido
frecuentemente responsables del desarrollo de software. Hay un viejo axioma de gestin
que dice: Un buen gestor puede gestionar cualquier proyecto. Nosotros debemos
aadir: ...Si desea aprender las tcnicas novedosas que pueden utilizarse para medir el
desarrollo del proyecto, aplicar mtodos efectivos de control, ignorar la mitologa y llegar
a conocer una tecnologa rpidamente cambiante. El gestor debe comunicarse con todos
los componentes implicados en el desarrollo del software clientes, realizadores del
software, equipo de soporte y otros. La comunicacin puede romperse debido a que las
caractersticas especiales del software y los problemas particulares asociados con su
desarrollo son mal comprendidos. Cuando esto ocurre, los problemas asociados con la
crisis del software se multiplican.
Los trabajadores del software (la pasada generacin se llam programadores; esta
generacin se ganar el ttulo de ingenieros en software) han tenido muy poco
entrenamiento formal en las nuevas tcnicas de desarrollo de software. En muchas
organizaciones reina una suave forma de anarqua. Cada individuo enfoca su tarea de
escribir programas con la experiencia obtenida en trabajos anteriores. Algunas personas
desarrollan un mtodo ordenado y eficiente de desarrollo del software mediante prueba y
error, pero muchos otros desarrollan malos hbitos que dan como resultado una pobre
calidad y mantenibilidad del software.
Todos nos resistimos al cambio. Sin embargo, es verdaderamente irnico, que mientras el
potencial de clculo (hardware) experimenta enormes cambios, la gente del software,
responsables de aprovechar dicho potencial, se oponga normalmente a los cambios
cuando se discuten, y se resistan al cambio cuando se introduce. Puede que sta sea la
causa real de la crisis del software.
COMO SOBREVIVIR ANTE ESTA CRISIS
Jams escatimes en calidad de hosting, conexin ADSL o servicio al cliente. De qu
sirve ahorrar para una compaa o actividad a la que le puedes estar destrozando
los cimientos?
Nunca entregues chapuzas o trabajos de baja calidad. Optimiza procesos, reutiliza
diseos o cdigo y haz lo que sea para optimizar el tiempo y poder ofrecer un
precio ajustado; pero nunca jams entregues chapuzas o algo que pueda afectar
a la imagen o ganancias de tu cliente y recuerda que un nico trabajo mal hecho
puede destruir la buena reputacin que puedes haber ganado tras cientos de
trabajos perfectamente realizados.

Reduce costes. No necesitas lo ltimo en software y probablemente puedes evitar

gastos innecesarios. Sobre todo recuerda que el tiempo tambin es dinero,
aprovchalo!
Aprovchate tambin de las oportunidades que la crisis ofrece, agudiza el ingenio

Recuerda que muchos grandes proyectos y un gran nmero de fortunas surgieron

en tiempos de crisis. Nunca olvides que los periodos de recesin econmica
pueden estar llenos de oportunidades Aprende a descubrirlas y aprovecha la
rapidez de actuacin que te da el ser pequeo!
No desaproveches ninguna oportunidad de conseguir un buen cliente, por
pequea que pueda parecer, y no dejes nunca de hacer aquello que aconsejas.

Cuestionario del libro:

5.1.- intntese resumir en un prrafo breve los siete principios para el desarrollo de
software de David Hooker. Trtese de extraer la esencia de su gua en un solo unas
cuantas oraciones y sin usar las palabras de Hooker.
Para desarrollar un software se debe tener muy en claro el porqu tiene que existir, estar
presente para los usuarios por muchos aos, siendo de manera sencilla para todos y muy
clara para facilitar su uso y as muchas personas ms la ocupen y que se tenga informacin
de que es reutilizable para mayor comodidad de todos.
5.2.- existen otros puntos tcnicos esenciales que se puedan recomendar a los
ingenieros de software? Enunciar cada uno de ellos y explicar porque se han incluido.
1. Escuchar: estar atento a lo que se dice para entender bien y sin interrumpir y con
mucho respeto sin estar haciendo seales o gestos, si algo no quedo claro hacer la
pregunta bien formulada y ante todo con respeto.
2. Prepararse antes de comunicar: debe hacer previa investigacin para asi dominar y
tener muy claro el tema, especificado los puntos a tratar y en riguroso orden
3. Alguien debe facilitar la actividad: debe haber una persona que dirija o moderador
para facilitar las distintas opiniones o conflictos sin salirse del tema.
4. La comunicacin cara a cara es la mejor: con esquemas o documentos ser mejor
para la discusin del tema
5. Tomar notas y documentar las decisiones algunas de las personas que este
participando en la comunicacin debe hacer anotaciones de los puntos y ms
relevantes
6. Buscar la colaboracin: que los miembros del equipo sean tomados en cuenta con
su opinin y as entre todos poder describir mejor el producto o sistema

7. Conservar el enfoque, examinar un modulo a la ves: cuando hay muchas personas

en una misma discusin muchos se van a otros puntos del tema ah debe actuar el
moderador para dejar un punto hasta que est claro
8. Si algo no est claro, se hace un dibujo un esquema puede dejar ms claro el tema
9. Se debe continuar cuando ya quedo todo claro, o pasar al siguiente punto si ya
lleva mucho tiempo
10. La negociacin se debe llevar a cabo de forma tranquila para que ambas partes
queden conformes
5.3.- Existen otros punto esenciales de gestin que se puedan recomendar a los
ingenieros de software? Enunciar cada uno y explicar lo que se ha incluido.
1. Entender los alcances del proyecto: deben saber exactamente el alcance del
software
2. Involucrar al cliente en la actividad de planificacin este debe dar su opinin en
cuanto sus prioridades de cmo quiere su software
3. Reconocer que la planeacin es iterativa: el plan de un programa no es exacto,
siempre requiere de alguna modificacin de ltima hora
4. Estimar con base en el conocimiento disponible, esto proporciona un indicio del
costo, duracin, esfuerzo y tiempo que lleva realizar el trabajo
5. Considerar el riesgo cuando se define el plan: se debe tomar en cuenta si algo no
sale como se tena planeado, pues arruinara el calendario de duracin del trabajo
6. Ser realista mientras se establece el plan en cuenta que no todos los das ni todas
las personas trabajan al 100%
7. Ajustar la gradualidad mientras se define el plan; se refiere al grado de detalles del
plan en cuanto a su desarrollo.
8. Definir como se intentara asegurar la calidad: deben decidir cmo confirmar la
calidad y cunto tiempo tardara una revisin a otra.
9. Describir como se pretende incluir el cambio: el cliente puede pedir cambio en
cualquier momento y como se evala el costo, el impacto.
10. Adaptar el plan a menudo y hacer los ajustes estos requerirn: los proyectos de
software van por detrs del calendario establecido este debe ajustarse
constantemente.

5.4.- un principio importante de la comunicacin establece prepare antes de comunicar.

Cmo podra esta preparacin manifestarse por s misma en los primeros trabajos que se
realizan? Cules productos de trabajo podran resultar como consecuencia de la
preparacin oportuna?

Detallar los principios de procesar los negocios con la intencin de que el ingeniero del
software se considere parte del negocio, por ello, es necesario que se identifique con la
misma para sea realizado con xito el proyecto.
5.5.- hgase una investigacin de la facilitacin para la actividad de comunicacin
(utilcense las referencias que se proporcionan u otras) y preparase un conjunto de
directrices que se enfoquen solo en la facilitacin.
Es de vital importancia que se evite el liderazgo para llevar a buen trmino, el proyecto
para que de igual manera no se creen conflictos internos dentro de la empresa, para que
se lleve por buen camino el software.