CICLO DE PRACTICO

INGENIERIA DE SOFTWARE I - SB

MELENDEZ MARTINEZ, SERGIO DRISS 215049187

INF 422 (1/2021)
 Código de ética y Conducta Profesional de ACM (Association for
Computing Machinery)
Preámbulo
El comportamiento de los profesionales de TI está cambiando el mundo. Para actuar
responsablemente, siempre debe considerar el impacto más amplio de su trabajo en el interés
público. El Código de Ética y el Código de Conducta Comercial de ACM (“Código”) reflejan nuestra
conciencia profesional. Este Código está diseñado para estimular y orientar el comportamiento
ético de todos los profesionales de TI, incluidos los profesionales actuales y futuros, instructores,
estudiantes, personas influyentes y cualquier persona que utilice la tecnología de la información
en su negocio. Esta regla también es la base para corregir infracciones. El Código contiene
principios desarrollados en forma de declaración de responsabilidad basada en la creencia de que
el bien público siempre es lo primero. Cada principio se complementa con instrucciones que
proporcionan explicaciones para ayudar a los profesionales de TI a comprenderlos y aplicarlos. El
código no es un algoritmo para resolver problemas éticos. En cambio, sirve como punto de
partida para la toma de decisiones éticas.

1. Principios Éticos Generales

1.1. Constribuir a la Sociedad y al Bienestar Humano, reconociendo que todas
las personas son partes interesadas en la informatica.
 Partiendo de este principio, estamos hablando de toda calidad de vida. Es deber de los
profesionales de TI servir a la sociedad de sus miembros y al medio ambiente. Esta es una
obligación de promover los derechos humanos y proteger la autonomía individual. Un
objetivo esencial es minimizar las consecuencias negativas de la TI, como las amenazas a la
salud, la seguridad personal y la privacidad.
 Los profesionales de TI deben evaluar el resultado de sus esfuerzos en el respeto de la
diversidad y, por lo tanto, la diversidad se utiliza de manera socialmente responsable para
satisfacer las necesidades sociales y es ampliamente accesible. Además del entorno social,
el bienestar humano requiere un entorno natural seguro que promueva la sostenibilidad
ambiental a nivel local y mundial.
1.2. Evitar el daño
El daño equivale a consecuencias negativas, especialmente cuando son significativas e
injustas.
Cuando el daño es involuntario, los responsables están obligados a deshacer o mitigar
el daño tanto como sea posible. Para evitar daños es necesario una evaluación a detalle
de los posibles impactos que fueron afectados por la toma de decisión. Y cuando es
 daño parte intencional del sistema, los responsables están obligados a garantizar que el
daño está éticamente justificado.
Para minimizar la posibilidad de dañar a los demás de manera indirecta o no
intencional, los profesionales de la computación deben seguir buenas prácticas que son
generalmente aceptadas globalmente analizando cuidadosamente cuáles serían las
consecuencias de agregación de datos y propiedades en el sistema, por lo tanto tienen
la obligación de informar cualquier tipo de riesgo que el sistema puede ocasionar, si los
responsables no actúan para reducir o mitigar dichos riesgos, puede ser necesario dar
la voz de alarma para reducir el daño potencial.

1.3. Ser honesto y confiable

La honestidad es un componente esencial de la confiabilidad. Un profesional de la
informática debe ser transparente y proporcionar una información completa de todas
las capacidades del sistema, sus limitaciones y los posibles problemas a los actores
interesados. Sostener afirmaciones deliberadamente falsas o engañosas, fabricar o
falsificar datos, ofrecer o aceptar sobornos y otras conductas deshonestas son
infracciones al código.
Los profesionales están obligados a ser honestos sobre sus capacidades
profesionales ante las limitaciones competentes para completar una tarea en
específico, deben ser capaces de manejar o conducir conflictos de interés.

1.4. Ser justo y tomar medidas para no discriminar

Este principio está gobernado por los valores de igualdad, tolerancia, respeto por los
demás y justicia.
Los profesionales deben fomentar participación justa de todas las personas, evitando la
discriminación prejuiciosa basada en la edad, color, discapacidad, etnia, identidad de
género, creencias, etcétera.
El uso de la información y la tecnología puede causar inequidades nuevas o ampliar los
existentes. Las tecnologías y prácticas deben ser lo más inclusivas y accesibles que sea
posible y que los profesionales deben tomará medidas para evitar el desarrollo de
sistemas o tecnologías que privan del derecho a decidir u oprimen a las personas
primeras personas, y si el diseño falla en la inclusión y el acceso equitativo puede
ocasionar una discriminación injusta.

1.5. Respetar el trabajo necesario para producir nuevas ideas, inventos, trabajos creativos
y artefactos informaticos
El desarrollo de nuevas ideas, inventos, obras creativas y artefactos informáticos crea
valor para la sociedad y aquellos que realizan el esfuerzo para desarrollarlos esperan
tener beneficios de su trabajos la ley reconoce la necesidad de algunas expresiones de
cara al bien público los profesionales no deben oponerse a los usos razonables de sus
obras intelectuales. Por ejemplo contribución de tiempo y energía a proyectos que
ayudan a la sociedad, los profesionales no deberían reclamar propiedad del trabajo de
aquellas personas que hayan compartido recursos públicos abiertamente.
 1.6. Respetar la privacidad
Los profesionales tienen la gran responsabilidad de respetar la privacidad forma parte
del código ético, la tecnología permite la recopilación, el control y el intercambio de
información personal de forma rápida y económica, los profesionales deberán usar
datos personales únicamente con fines legítimos sin violar los derechos de individuos y
grupos. Es por ello que es muy importante tomar precauciones para evitar la re
identificación de datos anónimos y recopilación de datos no autorizados, solamente es
necesario recopilar únicamente el mínimo de información personal necesaria que
deben ser claramente definidos cumplidos y comunicados a los interesados.

1.7. Respetar la confidencialidad

A los profesionales se les suele confiar información confidencial como secretos
comerciales , datos de clientes, estrategias comerciales que no son públicas,
información financiera, etcétera. Deben proteger la confidencialidad excepto en los
casos que encuentre evidencias de violación de una ley que por naturaleza se debe
comunicar a las autoridades correspondientes.

2. Responsabilidades Profesionales
2.1. Esforzarse por lograr una alta calidad tanto en los procesos como en los productos del
trabajo profesional
Los profesionales deberían promover el trabajo de calidad, tanto el propio como de su
colegas respetando la dignidad de los empleadores usuarios y/o cualquier otra persona
afectada directa o indirectamente por el trabajo durante el proceso.

2.2. Mantener altos estándares de competencia profesional, conducta y practica ética

La informática de calidad depende de los individuos y equipos que asumen la
responsabilidad personal y grupal de adquirir y mantener la actitud profesional, también
implica la habilidad de la comunicación y el análisis reflexivo con el reconocimiento y
gestión de desafíos éticos.
La actualización de competencia debe ser un proceso continuo para que ese mismo los
empleadores puedan alentar y facilitar estas actividades.

2.3. Conocer y respetar las reglas vigentes relacionadas con el trabajo profesional.
Los profesionales deben cumplir con estas reglas locales, regionales, nacionales e
internacionales ya que deberían ser capaces de cuestionar la regla a través de los
canales existentes antes de violar las reglas en caso de que se decida violar una regla
porque no es ética o por cualquier otro motivo se debe considerar las posibles
consecuencias y aceptar la responsabilidad de esta acción.

2.4. Aceptar y proporcionar una revisión profesional adecuada

 El trabajo de calidad en informática depende de la revisión profesional en todas sus
etapas inclusive los profesionales deben ser capaces de proporcionar revisiones
constructivas y críticas del trabajo ajeno.

2.5. Realizar evaluaciones integrales y exhaustivas de los sistemas informáticos y de sus

impactos, incluyendo un análisis de los posibles riesgos
A los profesionales se les asigna una posición de confianza que por lo tanto tienen la
responsabilidad de proporcionar evaluaciones y testimonios objetivos y creíbles a toda
la sociedad pues lo que deben ser objetivos cuando evalúan, recomiendan y presenta
descripciones de un sistema o alternativas al mismo y debe ser muy cuidadoso de
poder identificar y mitigar los riesgos potenciales en los sistemas del aprendizaje
automático.

2.6. Trabajar solo en sus ámbitos de competencia

Un profesional es responsable de evaluar el trabajo que le fue asignado y esto implica
juzgar si es factible y conveniente si el profesional considera que carece de la
experiencia necesaria debe comunicarlo.

2.7. Fomentar la conciencia ciudadana sobre la informática, las tecnologías relacionadas y

sus consecuencias
Los profesionales deberán compartir sus conocimientos técnicos con la ciudadanía para
fomentar el conocimiento sobre la informática y alentar su comprensión la
comunicación que se establece debe ser clara respetuosa y cordial inclusive deben ser
capaces de abordar la información inexacta o engañosa relacionada con la informática.

2.8. Acceder a los recursos informáticos y de comunicación solo cuando este autorizado, o
cuando sea necesario para proteger el bien publico
Las personas y las organizaciones tienen derecho a restringir el acceso a sus sistemas y
sus datos siempre que las restricciones sean consistentes con los demás principios de
este código los profesionales no tienen autorización de acceder a datos ajenos con
motivos que no sean válidos para asegurar que tal acción sea autorizada con la defensa
del bien público.

2.9. Diseñar e implementar sistemas robustos, accesibles y seguros

Las violaciones de seguridad informática causan daño, la seguridad robusta debe ser
una consideración primordial al diseñar e implementar sistemas. Los profesionales
deben implementar los mecanismos necesarios para garantizar que el sistema funcione
de la manera prevista deben integrar técnicas y políticas de mitigación de daños tales
como un monitoreo, parches de seguridad y producción de informes por lo tanto deben
garantizar que las partes afectadas por filtraciones de datos sean notificadas de manera
oportuna y clara ofreciendo orientación y corrección adecuadas.
Para garantizar que el sistema informático cumpla su propósito las funciones de
seguridad serán diseñadas de forma tan intuitiva y fácil de usar como sea posible
 evitando las precauciones de seguridad que sean confusas e inapropiadas que en la
cual impiden el uso legítimo.

3. Principios de Liderazgo Profesional

En esta sección "líder” equivale a cualquier miembro de una organización o grupo que
ejerce influencia cumpla con responsabilidades educativas o gerenciales. Si bien esto se
compite entre todos los profesionales de la informática, ya que los líderes tienen una
responsabilidad mayor para defenderlos y promoverlos.

3.1. Asegurar que el bien público sea la preocupación central en el trabajo profesional
Todas aquellas personas que incluye usuarios, clientes, u otros que puedan ser
afectados directamente o indirectamente, deben ser siempre la preocupación
principal de informática. Por lo que los profesionales de informática deben centrar su
atención en ellos más allá de las metodologías técnicas que utilicen en la práctica.

3.2. Articular, fomentar la aceptación y evaluar el cumplimiento de las

responsabilidades sociales por parte de los miembros de la organización o grupo
Las organizaciones y grupos técnicos afectan a la sociedad en general en donde los
líderes deben aceptar las responsabilidades que están asociadas a ellas ya que deben
impulsar la participación de los profesionales en el cumplimiento de la responsabilidad
social y desalentar las tendencias a hacer lo contrario.

3.3. Administrar el personal y los recursos para mejorar la calidad de la vida profesional
Los líderes deben garantizar que mejore y no se degrade la calidad de la vida profesional
deben tener en cuenta el desarrollo personal y profesional con los requisitos de
accesibilidad, seguridad física, bienestar psicológico y dignidad humana de todos los
trabajadores.

3.4. Articular, aplicar y apoyar políticas y procesos que reflejen los principios del código
Los líderes procuran el desarrollo de políticas organizacionales claramente definidas
que sean consistentes con el código y comunicarlas efectivamente a las partes
interesadas, además estos mismos deben alentar y reconocer el cumplimiento de esas
políticas tomando todas las medidas adecuadas en el diseño o implementación de los
procesos que impidan la infracción de los principios del código.

3.5. Crear oportunidades para que los miembros de la organización o el grupo crezcan
como profesionales
Las oportunidades educativas son muy esenciales para todas las organizaciones y
miembros del grupo. Es por ello que los líderes garantizan que existen las
oportunidades disponibles para que los profesionales puedan crecer o mejorar sus
conocimientos y habilidades, sus prácticas de éticas y especialidades técnicas. Todas
 estas oportunidades incluyen las experiencias para que los profesionales Informáticos
se familiaricen con las consecuencias y limitaciones en ciertos tipos determinados de
sistemas.

3.6. Tener cuidado al modificar o retirar sistemas

Los cambios de una interfaz, ya sea una eliminación o actualizaciones de software tiene
un impacto en la productividad de los usuarios y en la calidad de su trabajo. Este es un
tema muy frágil en la que los líderes deben tener cuidado al realizar algún tipo de
cambio en el sistema que las personas que dependen de ella. Es por ello que los líderes
están obligados a estudiar si las alternativas son viables para eliminar o actualizar el
software, por lo que si se llega a realizar alguna de estas actividades los usuarios deben
ser notificados de los riesgos de uso, por lo tanto los profesionales ayudan a los
usuarios del sistema a controlar la viabilidad operativa de sus sistemas ya que es
posible que sea necesario reemplazar oportunamente funciones inadecuadas u
obsoletas, incluso sistemas completos.

3.7. Reconocer y cuidar los sistemas que se integran en la infraestructura de la sociedad

Existen sistemas informáticos sencillos que tienen el potencial de afectar todos los
aspectos de la sociedad, en la que se integran a las actividades cotidianas de los
usuarios como ser comercio, viajes, educación, atención médica, etcétera. Los líderes
tienen la responsabilidad de realizar una buena administración de sistema y poder
visualizar la integración que tiene su sistema en la sociedad y conocer el nivel en la que
se adopta los cambios o las responsabilidades éticas de la organización.

4. Cumplimiento del Código

4.1. Defender, promover y respetar los principios del código
El futuro de la informática depende de la excelencia técnica y ética. Los profesionales
deben adherir a los principios del código y contribuir a mejorarlos. Aquellos que no lo
cumplan deben tomar medidas para resolver los problemas éticos identificados cuando
sea razonable expresando su preocupación a la persona o personas que cree que viola
al código.

4.2. Tratar las violaciones del código como inconsistentes con la afiliación a ACM
Cada miembro debe alentar y apoyar la decisión de todos los profesionales de la
informática que reconocen una violación del código deben evaluar reportándolo, con la
posibilidad de resultar en acciones correctivas como una especifica el código de ética y
conducta profesional.

Evolución del Software

Origen de evolución del software
El término evolución de software se ha utilizado desde la década de 1960 para designar la
dinámica del desarrollo de software. De hecho, el desarrollo del software requiere que
cualquier operación de programación tenga como objetivo crear una nueva versión del
software a partir de la versión de trabajo anterior. Al comienzo de la era de la computadora,
se consideró software complementario. La programación informática es un arte conmovedor
en el hogar, donde rara vez existen métodos sistemáticos. Todo transcurrió prácticamente
sin un plan hasta que el plan de desarrollo de software colapsó y los costos se dispararon. La
segunda era en el desarrollo de sistemas informáticos duró desde mediados de la década de
1960 hasta finales de la de 1970. Los sistemas multiprogramables y multiusuario introducen
un nuevo concepto de interacción hombre-máquina. Por tanto, se caracteriza por configurar
el software como producto. La tercera era en el desarrollo de sistemas informáticos
comenzó a mediados de la década de 1970 y duró más de una década. Los sistemas
distribuidos, muchas computadoras, cada máquina que realiza funciones en paralelo y se
comunica entre sí aumenta la complejidad de los sistemas informáticos. La creciente
demanda de 4.444 redes locales y globales, comunicaciones digitales de gran ancho de
banda y acceso a datos está ejerciendo una gran presión sobre los desarrolladores de
software. En resumen, la tercera era se caracteriza por el advenimiento y el uso generalizado
de microprocesadores.
La cuarta era de la evolución de los sistemas informáticos se aleja de las computadoras
individuales y de los programas de computadoras en la que se dirigen al impacto colectivo de
las computadoras y del software. Potentes máquinas personales en controladas por sistemas
operativos sofisticados, en redes globales y locales están acompañadas por aplicaciones
software avanzada que se han convertido en la norma.
El mundo del software ya es la cuna de la economía del mundo de la actualidad. las técnicas de
la cuarta generación para el desarrollo de software están cambiando en la forma que la
comunidad de software construye programas informáticos. Las tecnologías orientadas objetos
están desplazando rápidamente los enfoques de desarrollo software software más
convencionales en muchas áreas de aplicaciones.

Criterios para Seleccionar Estrategias de Desarrollo

Metodologias seleccionadas
Clasicas
 Cascada
 Prototipos
 Incremental
 Espiral
 RAD

Ágiles
 Scrum
 Kanban

Metodologias Clasicos (tradicionales)

Metodología Cascada
El modelo de desarrollo de software en cascada, es una metodología de la programación muy
antigua. Si bien su creador nunca lo menciona como metodología en cascada, el
funcionamiento y lineamientos de los procesos de la planeación, son exactamente iguales.
Basicamente, el estilo del modelo en cascada, es que no podrás avanzar a la siguiente fase, sí la
anterior no se encuentra totalmente terminada, pues no tiene por qué haber vuelta atrás.

Ingeniería y análisis del sistema

Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza
estableciendo los requisitos de todos los elementos del sistema y luego asignando al uso
conjunto de estos requisitos al software.

Análisis de los requisitos del software

El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software.
El ingeniero de software (Analista) debe comprender el ámbito de la información del software,
así como la función, señor rendimiento y las interfaces requeridas.

Diseño
el diseño del software se enfoca en 4 atributos distintos del programa: la estructura de los
datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz.
El proceso de diseño traduce los requisitos de una representación del software con la calidad
requerida antes de que comience la codificación.

Codificación
el diseño debe traducirse una forma legible para la máquina. La pruebas se centra en la lógica
interna del software, y en las funciones externas, realizando pruebas que aseguren que la
entrada definida produce los resultados que realmente se requieren.

Prueba
una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en
la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que
la entrada definida produce los resultados que realmente se requieren.

Mantenimiento
el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido
para que se han encontrado errores, a que el software debe adaptarse a cambios del entorno
externos (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento.

Ventajas Desventajas
estructura sencilla gracias unas fases por ahí tomas complejos de varios niveles
de proyecto claramente no permiten su división en fases de
diferenciadas proyecto
claramente diferenciados
buena documentación del proceso poco margen para realizar ajustes a lo
de desarrollo a través de unos largo del proyecto debido a un cambio de
hitos bien las
definidos exigencias
costes y las cargas de trabajo se sólo final no se integra en el proceso
puede estimar al comenzar el de producción hasta que no se
proyecto termine la
programación
 a que es proyecto que se estructura en los fallos sólo se detectan una vez
base al modelo en cascada se pueden finalizado el proceso de desarrollo
representar
cronológicamente de forma sencilla

Principios basicos del modelo cascada?

El proceso de desarrollo de software con el modelo cascada es bastante complejo. Sin embargo
uno de sus principios que cada una de las fases elaboradas, se encuentra documentada
perfectamente, de este modo, si el desarrollo queda suspendido en algunas fases, cualquier
usuario que quiera continuar con el proyecto lo podrá hacer leyendo la tramitación.
Es muy común encontrar metodología de procesadores de software en cascada con fechas de
objetivos, tiempos o presupuestos para determinadas fases. Aprovechando el hecho de que
una vez que avanzaste de fase, es muy poco recomendable el volver atrás, aunque
regularmente se tiene un cierto nivel de tolerancia, pero lo correcto en la utilización del modelo
de cascada, es que no puedas ir atrás a realizar modificaciones de ningún tipo.

Para que este modelo sea utilizado se aplique a un proyecto se debe tener un una
documentación completamente bien definida bien estructurada para recién poder ejecutar el
desarrollo del mismo.

Metodo de Prototipos
Esta metodología de la programación todavía sigue siendo la favorita de muchos. Consiste
básicamente en base a los requerimientos y necesidades que tiene el cliente, se realiza de
forma rápida un prototipo, este no vendrá completo ni mucho menos terminado, pero si
puedes venir a contar con las bases necesarias para que cualquier programador pueda seguir
trabajando en él hasta llegar al código final.

Un prototipo es una versión no terminada el producto que se le entregará al cliente o usuario

final. Esto nos genera cierta ventaja en el desarrollo de productos similares con funciones
distintas, por ejemplo. Supongamos que vas a desarrollar un proyecto para 3 clientes distintos,
ambos con una estructura idéntica pero con funcionalidades muy distintas, entonces lo que
hacemos es crear un prototipo base y entorno a él para mostrar a nuestros clientes para que de
ahí empieza empieza a desarrollar los demás funciones.
Planeación
A diferencia de otras metodologías, la planeación debe ser muy rápida, en esta fase no puedes
demorarte mucho, pues recuerda que solamente será un prototipo por el momento.
Modelado
Nuevamente, una fase que deberá ser suficientemente rápida como para que no nos quite
nada de tiempo. Hacer modelado será simple y te sigo recordando que solamente es un
prototipo, al menos por ahora.

Elaboración del prototipo

ya que contamos con la planeación de lo que vamos a realizar y el modelado rápido, entonces
es momento de elaborar el prototipo. Para esta instancia, ya no te diré que lo debes hacer
rápido, puesto que te tomará el tiempo que tenga sea necesario elaborarlo, recuerda que este
ya se muestra al cliente, así que ya es una fase importante.

Desarrollo
posterior a contar con el prototipo elaborado y mostrado al cliente, es momento de comenzar
el desarrollo. Este te tomará una gran cantidad de tiempo, dependiendo del tamaño del
proyecto y el lenguaje de programación que se vaya a utilizar.

Entrega y retroalimentación
una de las cosas con las que cuenta el modelo de prototipos, es que una vez entregado el
proyecto, debemos darle al cliente cierta retroalimentación sobre cómo utilizarlo y ciertamente
es una fase que se encuentra dentro de las etapas de desarrollo de software esta metodología.

Comunicación con el cliente

es importante que una vez entregado el proyecto, tengamos cierta comunicación con el cliente,
básicamente para que nos indique si el proyecto es correcto o si desea agregarle ciertas
funciones, nuestra metodología lo permite. Si fuera en modo cascada, entonces sería algo
realmente imposible de hacer.

Entrega del producto final

por último, solamente quedará entregar el sistema elaborado mediante esta metodología. Aquí
tendrás la ventaja de que el código reutilizable, para que así con el prototipo ya pueda
simplemente empezar de nuevo y con una buena base de código que te acelera el proceso.

Desventajas
útiles cuando los requerimientos son no se conoce cuándo se tendrá un producto
cambiantes aceptable
cuando no se conoce bien la aplicación no se conoce cuántas interacciones serán
necesarias
cuando el usuario no se quiere da falta ilusión a los usuarios sobre la
comprometer velocidad del desarrollo
con los requerimientos
cuando se quiere probar una se puede volver el producto aún y cuando
arquitectura o tecnología y se requiere no esté con los estándares
rapidez en el
desarrollo

Principios basicos del metodo de prototipos?

En el modelo de prototipos puede llegar a ser un poco más tedioso, aunque todo dependerá del
ámbito en que lo utilices. Sin embargo 1 de los principios con el método de prototipos el
proyecto se va dividiendo en partes cada vez más pequeñas, para evitar el peligro ante los
riesgos frente a los que estamos expuestos.

Ademas, otro de sus principios básicos fundamentales con la metodología de prototipos, es que
el cliente final se involucra mucho más en el proyecto que con otras metodologías, haciendo de
esta forma que el producto final llegue rápidamente aunque con un poco más de presión en el
proceso. La ventaja es que conforme se van haciendo prototipos pequeños, poco a poco se va
llegando al producto final. Incluso en algún determinado momento podrás llegar a crear un
prototipo que con solo ajustar ciertos detalles, se podría convertir en el producto que el usuario
quiere.
Modelo Incremental
Es una metodología de la programación muy utilizada hoy en día, pues su comodidad de
desarrollo permite que te obtenga un producto final mucho más completo y exitoso. Se trata
especialmente de la combinación de los modelos lineal e interactivo o bien, modelo de cascada
y prototipos. Basicamente consiste en completar varias iteraciones de lo que es el modelo de
cascada, pero sin completar ninguna, haciendo iteraciones lo que se hace es crear una
evolución en el producto, permitiendo que se agreguen nuevas especificaciones,
funcionalidades, opciones, funciones y lo que el usuario requiera después de cada iteración.

En pocas palabras, el modelo incrementar repite el modelo de cascada una y otra vez, pero con
pequeñas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De este
modo el usuario final se ve sumamente sumergido en el desarrollo y puedes proporcionarle un
resultado óptimo.

Inicialización
Como en todo modelo de desarrollo, debe haber una inicialización, aquí se puede hablar de dar
una idea, de tener algunos requisitos que se buscan en el proyecto y ciertas especificaciones
que se puedan manejar. No es necesario que se haga una lista total de requerimientos pues
recordemos que el proyecto se basa en interacciones, así que el proyecto pude ir
evolucionando poco a poco.

Período de interacción
durante el desarrollo del proyecto, es cuando damos inicio a las iteraciones. La primera
iteración se realiza con las características iniciales, básicamente al final de la primera
interacción, queda un pequeño prototipo de lo que será el proyecto, pero se puede volver a
inicializar la interacción y realizar modificaciones en los procesos, como el análisis y las
especificaciones o funciones que el usuario final requiere para su sistema. El número de
interacciones que se realicen son ilimitadas y dependerá tanto de desarrollador como del
usuario final. Si nuestro objetivo es que el cliente o la persona que necesita el trabajo quede
completamente satisfecha, entonces nos veremos en la necesidad de hacer la cantidad de
interacciones que se requieran al final del día.

Lista de control
es importante que conforme se vaya realizando cada iteración, se vaya llevando un control del
mismo en una lista. Como si fuera un programa que recibe actualizaciones constantemente.
Cada una de las actualizaciones o interacciones deberá ser documentada y de ser posible,
guardada en sus respectivas versiones, para que sea sencillo volver atrás, en caso de que una
interacción no sea exitosa o el usuario ya no la requiera.

Ventajas Desventajas
la solución se va mejorando en forma requiere de mucha planeación
progresiva a través de las múltiples tanto administrativa como técnica
iteraciones, incrementando el
entendimiento
del problema y refinamiento de los mismos
clientes no esperan hasta el fin del requiere metas claras para conocer el
desarrollo para utilizar el sistema se puede estado del proyecto
utilizar con
el primer incremento
clientes pueden aclarar los requisitos que es un proceso de desarrollo de
no tengan claro software creado en respuesta a las
debilidades del
modelo tradicional de cascada
disminuye el riesgo de fracaso de todo el
proyecto ya que se puede distribuir en
cada
incremento

Principios Basicos del modelo Incremental?

Es importante definir los siguientes principios fundamentales, pues nos permiten saber con
claridad por dónde va la idea de la metodología.

La idea de un modelo incremental, es utilizar una serie de mini modelos de desarrollo de

software en cascada, segmentando se requerimientos y permitiendo que el usuario vaya de la
mano con el proyecto durante la realización.

Basicamente las fases de cada iteración, son las mismas que se manejan en el modelo de
cascada, aunque también se pueden agregar algunas, pero su objetivo es completar cada fase
de la integración, para que ésta se vaya completando poco a poco y no se genera un desarrollo
tedioso y cansado que puede alargar la duración del proyecto.
Cada interacción de generará un prototipo cada vez más evolucionado, esto debe quería ser
guardados por si en determinado momento deseas volver atrás, pues a diferencia del modelo
de cascada, podemos retroceder cuando se requiera y los prototipos se puedan volver a utilizar
una y otra vez, pues el código fuente es reutilizable.

Modelo en Espiral
Se trata de una combinación entre el modelo lineal o de cascada y el modelo interactivo o
pasado en prototipos, sin embargo a este sistema lo que debemos añadirle la gestión de
riesgos, algo que en los modelos anteriores ni siquiera se menciona.

Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando
procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aquí estos
no son obligatorios y no llevan precisamente el orden establecido. Basicamente se trata de un
modelo evolutivo, que conforme avancen los ciclos, irá incrementando el nivel de código fuente
desarrollado, un incremento en la gestión de riesgo y por supuesto un incremento en los
tiempos de ejecución y planificación del sistema, esto es lo que tiene el modelo en espiral.

para tener una idea más clara, el modelo en espiral es principalmente utilizado para el
desarrollo de grandes proyectos como la creación de un sistema operativo. Sin embargo
necesita de ciertos requisitos, como el hecho de contar con personal completamente
capacitado para las funciones que se requieran.
Determinar objetivo
Es importante que siempre consideres una planeación inicial, estas sólo se realizará una [Link]
embargo el proceso de determinar objetivos se hará constantemente durante cada iteración
que se vaya realizando con el modelo espiral. Esto se debe a que poco a poco se irá
incrementando más el tamaño del manual del usuario, los requisitos, las especificaciones e
incluso las restricciones. Todo esto entra en lo que es la tarea de objetivos y con cada vuelta en
el espiral entraremos a esta tarea, la cual como todas las demás es fundamental.
Análisis de riesgo
Una etapa donde incluso una lluvia de ideas podría ayudar, el análisis de riesgos. Aquí deberás
tener en cuenta todo aquello que pueda dañar a tu proyecto, ya sea que se trate de ciertas
amenazas o de posibles daños que se puedan ocasionar, teniendo además un plan B por así
decirlo, para que en caso de que ocurra algo inesperado, tener a la mano la solución para
continuar con el proyecto. En esta base del modelo espiral, podemos agregar lo que son la
creación de prototipos, pues siempre es bueno tener un respaldo de nuestro código, de esta
forma en caso de que algo malo suceda, volvemos a la versión anterior. Asi que cada vez que
vayamos a ingresar a la fase de pruebas implementación, será necesario contar con un
prototipo que nos respalde.

Desarrollar validar y probar

Básicamente en esta fase, la forma en que se estará desarrollando el proyecto, dependerá del
análisis de riesgos, pues siempre se va a ir desarrollando el proyecto enfocándose en riesgos
que podemos evitar en nuestro software, es decir, si la situación de riesgo más obvia se
encuentra en interfaz de usuario, entonces hay que trabajar con prototipos para este enfoque,
creando evoluciones proporcionales, para ir evitando este tipo de riesgos. Sin embargo el
modelo en espiral acomoda un poco más las prioridades al momento, independientemente de
todo lo demás. Por lo que siempre en cada vuelta interacción que se le da al modelo de espiral,
tú avances siempre dependerá del análisis de riesgo, hasta que sea mínimo y el desarrollo
pueda continuar de forma normal.

Planificación
antes de proceder a realizar otra interacción o vuelta a la espiral, debemos prestar atención a lo
que sucedió en la vuelta anterior. Debemos analizar detalladamente si los riesgos encontrados
ya tuvieron solución, lo cual debe ser lo ideal, puesto que ahora habría que analizar más
especificaciones y más requisitos del sistema para continuar con el desarrollo. Basicamente la
fase de planificación no servirá para determinar el avance de nuestro proyecto e indicar hacia
dónde vamos a dirigirnos en la próxima interacción.

Principios basicos del modelo Espiral?

Encontramos por fuera 4 fases bien organizadas, las cuales siempre deben llevar ese orden que
se estipula desde el principio. Una determinación de objetivos, un análisis de riesgos, R
desarrollo y las pruebas, junto con la planificación, la cual dependerá de los resultados de la
iteración para saber cómo se actuará en la siguiente vuelta al espiral.
Basicamente, en este modelo espiral, toda la atención está enfocada hacia el análisis de riesgos
pues el objetivo primario será reducir los riesgos que se vayan generando, de otra forma el
sistema no llegará a ser seguro jamás.

Algo muy importante que debes ver en el modelo de espiral es que los interesados deben estar
involucrados prácticamente cada vuelta que se dé la espiral, para crear lo que son los requisitos
antes de realizar una vuelta más y al final en la fase de la planificación, se puedan determinar
los logros obtenidos, el avance y lo que se esperará en una siguiente vuelta.

RAD: Desarrollo Rapido de Aplicaciones (Rapid Application Development)

A diferencia de otras metodologías para el desarrollo de software, la metodología RAD o
desarrollo rápido de aplicaciones, no cuenta con una serie de fases ordenadas por así decirlo.
Aunque sí está basada en lo que es el modelo de cascada y la creación de prototipos, sin
embargo el proceso es muy independiente a contar con ciertas fases estipuladas como los
modelos que hemos visto anteriormente.

Modelado de gestión
El flujo de información entre las funciones de gestión se modela de forma que responda a las
siguientes preguntas: que informacion conduce el proceso de gestión? qué información
genera? quien la genera? a dónde va la informacion? quien la procesó?

modelado de datos
El flujo de información definido como parte de la fase de modelado de gestión se refina como
un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características
de cada 1 de los objetos y la relación entre estos objetos.

modelado de proceso
Los objetos de datos definidos en la base de modelado datos quedan transformados para lograr el
flujo de información necesario para implementar una función de gestión las descripciones de
procesos se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la
comunicación entre los objetos.
generación de aplicaciones
El RAD asume la utilización de técnicas de cuarta generación. En lugar de crear software como
lenguaje de programación de tercera generación, el proceso de RAD trabaja para volver a utilizar
componentes de programas ya existentes OA crear componentes reutilizables.

pruebas de entrega
Como el proceso RAD enfatiza la reutilización, ya se han comprobado muchos de los
componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben
probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Ventajas Desventajas
comprar puede ahorrar dinero en comprar puede ser más caro que construir
comparación con construir
los entregables pueden ser fácilmente costo de herramientas integradas y equipo
trasladados a otra plataforma necesario
posiblemente menos fallas y costo menos eficiente y menos precisión científica
ciclos de desarrollo más pequeños riesgo de revertirse las prácticas sin control
de antaño

Principios basicos del modelo RAD?

este modelo está basado en el uso de las instalaciones y principalmente en el manejo de
prototipos. Sin embargo a diferencia del resto, la metodología RAD hace uso de las
herramientas CASE, las cuales permitirán acelerar el proceso considerablemente.

Del mismo modo que el modelo espiral y el de prototipo, RAD se subdivide en pequeñas
secciones, las cuales Irán optimizando y de esta forma se irá avanzando mucho más rápido que
con grandes segmentos que pueden volverse difíciles dentro de un proceso acelerado como
como este modelo.
Una de las ventajas de este modelo, es que el enfoque y las prioridades van hacia la fase de
desarrollo, a diferencia de modelos como la espiral en la que se enfoquen los riesgos al
momento sean muchos menores. En RAD se hace lo contrario, si hay riesgos reducimos los
requerimientos para reducir los riesgos la idea principalmente es reducir tiempos y no riesgos
tal vez también pero la reducción de riesgos totalmente inversa al modelo espiral.

Requiere factores documentados, de preferencia todo lo que se pueda, para que en caso de
que alguien más venga a continuar con este proyecto tenga a la mano toda la información que
necesita y con unas cuantas lecturas para com pensar a desarrollar lo que se había quedado
pendiente.
Metodologias Ágiles
Metodología Scrum
Es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de
productos complejos, no es un proceso o una tecnica para construir productos; en lugar de eso,
es un marco de trabajo dentro del cual se pueden emplear varias tecnicas y procesos. Muestra
la eficacia relativa de las practicas de gestion de producto y las practicas de desarrollo, de modo
que podamos mejorar.

Scrum se basa en la teoria de control de procesos empirica. El empirismo asegura que le

conocimiento procede de la experiencia y de tomar decisiones basandose en lo que se conoce,
Scrum emplea un enfoque iterativo e incremental para optimizar la predictilidad y el control del
riesgo.

Tres pilares soportan toda la implementacion del control de procesos empirico:

 Transparencia
 Inspeccion
 Adaptacion
Transparencia
Los aspectos del proceso deben ser visibles para aquellos que son responsables del resultado.
Requiere que los aspectos sean definidos por un estandar comun, de tal modo los observadores
compartan un entendimiento de lo que se esta viendo.

Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el
progreso hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan frecuente
como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se
realizan por inspectores expertos, en el mismo lugar de trabajo.

Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites
aceptables, y que el producto resultante no será aceptable, el proceso o el material que está
siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para
minimizar desviaciones mayores. Scrum prescribe cuatro eventos formales, contenidos dentro
del Sprint, para la inspección y adaptación.

 Reunion de planificación del Sprint (Sprint Planning Meeting)

 Scrum diario (Daily Scrum)
 Revision del Sprint (Sprint Review)
 Retrospectiva del Sprint (Sprint Retrospective)

Equipo Scrum (Scrum Team)

El Equipo Scrum consiste en:

 Dueño de Producto (Product Owner)

 Equipo de Desarrollo (Development Team)
 Scrum Master

Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados

eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al
equipo. Los equipos multifuncionales tienen todas las competencias necesarias para llevar a
cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de
equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las
oportunidades de obtener retroalimentación

Dueño de Producto (Product Owner)

El Dueño de Producto es una única persona, no un comité y es el responsable de maximizar el
valor del producto y del trabajo del Equipo de Desarrollo.
El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto
(Product Backlog). La gestión de la Lista del Producto incluye:

 Expresar claramente los elementos de la Lista del Producto;

 Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de
la mejor manera posible;
 Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo;
 Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajará a continuación; y,
 Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al
nivel necesario.
El Equipo de Desarrollo (Development Team)
El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de entregar un
Incremento de producto “Terminado”, que potencialmente se pueda poner en producción, al
final de cada Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del
Incremento. Los Equipos de Desarrollo son estructurados y empoderados por la organización
para organizar y gestionar su propio trabajo.

Los Equipos de Desarrollo tienen las siguientes características:

 Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo
cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad
potencialmente desplegables;
 Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas las
habilidades necesarias para crear un Incremento de producto;
 Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son
Desarrolladores, independientemente del trabajo que realice cada persona; no hay
excepciones a esta regla;
 Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan los dominios
particulares que requieran ser tenidos en cuenta, como pruebas o análisis de negocio;
no hay excepciones a esta regla;
 Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades
especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en
el Equipo de Desarrollo como un todo.

Scrum Master
El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum
Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría,
prácticas y reglas de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum.
El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones
con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a
modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.

Por lo tanto veremos algunos puntos de lo que Scrum Master hace:

1) Servicio del Scrum Master al Dueño de Producto

a) Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;

b) Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista
de Producto claros y concisos;
c) Entender la planificación del producto en un entorno empírico;
 d) Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto
para maximizar el valor;
e) Entender y practicar la agilidad;
f) Facilitar los eventos de Scrum según se requiera o necesite

2) Servicio del Scrum Master al Equipo de Desarrollo

a) Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;

b) Ayudar al Equipo de Desarrollo a crear productos de alto valor;
c) Eliminar impedimentos para el progreso del Equipo de Desarrollo;
d) Facilitar los eventos de Scrum según se requiera o necesite;
e) Guiar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún no
ha sido adoptado y entendido por completo.

3) Servicio del Scrum Master a la Organización

a) Liderar y guiar a la organización en la adopción de Scrum;

b) Planificar las implementaciones de Scrum en la organización;
c) Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo
empírico de producto;
d) Motivar cambios que incrementen la productividad del Equipo Scrum;
e) Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación
de Scrum en la organización.

Eventos de Scrum
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad
de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de
tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración
es fija y no puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se
alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo
sin permitir desperdicio en el proceso.

Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos
de Scrum constituye una oportunidad formal para la inspección y adaptación de algún
aspecto. Estos eventos están diseñados específicamente para habilitar las vitales transparencia
e inspección.
Sprint
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos
durante el cual se crea un incremento de producto “Terminado”. Es más conveniente si la
duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint
comienza inmediatamente después de la finalización del Sprint previo.
Los Sprints contienen y consisten de la Reunión de Planificación del Sprint (Sprint
Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión
del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).

Durante el Sprint:
 No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal);
 Los objetivos de calidad no disminuyen;
 El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo
de Desarrollo a medida que se va aprendiendo más.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual que
los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de qué se va
a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto
resultante

Cancelación de un Sprint
Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Solo el Dueño
de Producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia
de los interesados, del Equipo de Desarrollo o del Scrum Master. Un Sprint se cancelaría si el
Objetivo del Sprint llega a quedar obsoleto. Esto podría ocurrir si la compañía cambia la
dirección o si las condiciones del mercado o de la tecnología cambian. En general, un Sprint
debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias. Pero debido a la
corta duración de los Sprints, rara vez la cancelación tiene sentido. Cuando se cancela un Sprint,
se revisan todos los Elementos de la Lista de Producto que se hayan completado y
“Terminado”.

Las cancelaciones de Sprint consumen recursos, ya que todos deben reagruparse en otra
Reunión de Planificación de Sprint para empezar otro Sprint. Las cancelaciones de Sprint son a
menudo traumáticas para el Equipo Scrum y son muy poco comunes.

Reunión de Planificacion de Sprint (Sprint Planning Meeting)

La Reunión de Planificación de Sprint tiene un máximo de duración de ocho horas para un
Sprint de un mes. Para Sprints más cortos, el evento es usualmente más corto. El Scrum Master
se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El
Scrum Master enseña al Equipo Scrum a mantenerse dentro del bloque de tiempo. La Reunión
de Planificación de Sprint responde a las siguientes preguntas:

 ¿Qué puede ser terminado es este Sprint?

El Dueño de Producto discute el objetivo que el Sprint debería lograr y los Elementos de
la Lista de Producto que, si se completan en el Sprint, lograrían el Objetivo del Sprint. El
Equipo Scrum completo colabora en el entendimiento del trabajo del Sprint

 ¿Cómo se conseguirá completar el trabajo seleccionado?

Una vez que se ha establecido el objetivo y seleccionado los elementos de la Lista de
Producto para el Sprint, el Equipo de Desarrollo decide cómo construirá esta
funcionalidad para formar un Incremento de producto “Terminado”. Los elementos de
la Lista de Producto seleccionados para este Sprint, más el plan para terminarlos, recibe
el nombre de Lista de Pendientes del Sprint (Sprint Backlog).

Objetivo del Sprint (Sprint Goal)

El Objetivo del Sprint es una meta establecida para el Sprint que puede ser alcanzada mediante
la implementación de la Lista de Producto. Proporciona una guía al Equipo de Desarrollo acerca
de por qué está construyendo el incremento. Es creado durante la reunión de Planificación del
Sprint. El objetivo del Sprint ofrece al equipo de desarrollo cierta flexibilidad con respecto a la
funcionalidad implementada en el Sprint. Los elementos de la Lista del Producto seleccionados
ofrecen una función coherente, que puede ser el objetivo del Sprint. El objetivo del Sprint
puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en
conjunto y no en iniciativas separadas. A medida que el equipo de desarrollo trabaja, se
mantiene el objetivo del Sprint en mente. Con el fin de satisfacer el objetivo del Sprint se
implementa la funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que el
Equipo de Desarrollo espera, ellos colaboran con el Dueño del Producto para negociar el
alcance de la Lista de pendientes del Sprint (Sprint Backlog).
Scrum Diario (Daily Scrum)
El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para que el Equipo de
Desarrollo sincronice sus actividades y cree un plan para las siguientes 24 horas. Esto se lleva a
cabo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una
proyección acerca del trabajo que podría completarse antes del siguiente.

Durante la reunión, cada miembro del Equipo de Desarrollo explica:

 ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
 ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
 ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el
Objetivo del Sprint?

Revision de Sprint (Sprint Review)

Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y
adaptar la Lista de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum
y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto, y en
cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para
determinar las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una
reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como
objetivo facilitar la retroalimentación de información y fomentar la colaboración.

La Revisión de Sprint incluye los siguientes elementos:

 Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de
Producto;
 El Dueño de Producto explica qué elementos de la Lista de Producto se han
“Terminado” y cuales no se han “Terminado”;
 El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué problemas
aparecieron y cómo fueron resueltos esos problemas;
 El Equipo de Desarrollo demuestra el trabajo que ha “Terminado” y responde preguntas
acerca del Incremento;
 El Dueño de Producto habla acerca de la Lista de Producto en el estado actual. Proyecta
fechas de finalización probables en el tiempo basándose en el progreso obtenido hasta
la fecha (si es necesario);
 El grupo completo colabora acerca de qué hacer a continuación, de modo que la
Revisión del Sprint proporcione información de entrada valiosa para Reuniones de
Planificación de Sprints subsiguientes.
Retrospectiva de Sprint (Sprint Retrospective)
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí
mismo y crear un plan de mejoras que sean abordadas durante el siguiente Sprint. La
Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes de la siguiente
Reunión de Planificación de Sprint. Se trata de una reunión restringida a un bloque de tiempo
de tres horas para Sprints de un mes. Para Sprints más cortos se reserva un tiempo
proporcionalmente menor. El Scrum Master se asegura de que el evento se lleve a cabo y que
los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento
dentro del bloque de tiempo fijado. El Scrum Master participa en la reunión como un miembro
del equipo ya que la responsabilidad del proceso Scrum recae sobre él.

El propósito de la Retrospectiva de Sprint es:

 Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y
herramientas;
 Identificar y ordenar los elementos más importantes que salieron bien y las posibles
mejoras;
 Crear un plan para implementar las mejoras a la forma en la que el Equipo
Scrum desempeña su trabajo.

Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para
proporcionar transparencia y oportunidades para la inspección y adaptación.

Lista de Producto (Product Backlog)

La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto, y
es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de
Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido,
disponibilidad y ordenación. Una Lista de Producto nunca está completa.
La Lista de Producto es dinámica; cambia constantemente para identificar lo que el producto
necesita para ser adecuado, competitivo y útil. La Lista de Producto enumera todas las
características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a
ser hechos sobre el producto para entregas futuras.

El Equipo de Desarrollo es el responsable de proporcionar todas las estimaciones. El Dueño de

Producto podría influenciar al Equipo ayudándoles a entender y seleccionar soluciones de
compromiso, pero las personas que harán el trabajo son las que hacen la estimación final.

o Seguimiento del Progreso hacia un Objetivo

El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada
Revisión de Sprint. El Dueño de Producto compara esta cantidad con el trabajo restante
en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo
proyectado en el tiempo deseado para el objetivo.

Lista de pendientes del Sprint (Sprint Backlog)

La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de Producto
seleccionados para el Sprint, más un plan para entregar el Incremento de producto y
conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción hecha por
el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y
del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”. La Lista
de Pendientes del Sprint hace visible todo el trabajo que el Equipo de Desarrollo identifica
como necesario para alcanzar el Objetivo del Sprint.

o Seguimiento del Progreso del Sprint

El Equipo de Desarrollo hace seguimiento de este trabajo restante total al menos en
cada Scrum Diario para proyectar la posibilidad de conseguir el Objetivo del Sprint.
Haciendo seguimiento del trabajo restante a lo largo del Sprint, el Equipo de Desarrollo
puede gestionar su progreso.

Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto completados durante
un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el
nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser
utilizado y que cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe
estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no.
 Ventajas Desventajas
entregas parciales a corto plazo de
resultado
este o regular de las expectativas del cliente
y basada en resultados tangibles
flexibilidad y adaptación respecto a las
necesidades del cliente
productividad y calidad

Principios basicos de Scrum?

Para poder realizar la implantación de una gestión ágil de proyectos como scrum se debe tener lo
siguiente:
 cultura de empresa basada en el trabajo en equipo, delegación, creatividad y
mejora continua.
 compromiso del cliente en la dirección de los resultados del proyecto.
 compromiso de la dirección de la organización para resolver problemas frecuentes y
realizar cambios organizativos, formando equipos auto gestionados y multidisciplinares
y fomentando una cultura de gestión basada en la colaboración y la facilitación llevada a
cabo por líderes al servicio del equipo.
 compromiso conjunto y colaboración de los miembros del equipo.
 relación entre proveedor y cliente basada en la colaboración y transparencia.
 facilidad para realizar cambios en el proyecto.
 tamaño de equipo entre 5 y 9 personas
 equipo trabajando en un mismo espacio común para maximizar la comunicación
 dedicación del equipo a tiempo completo
 estabilidad de los miembros del equipo
Metodología Kanban

Kanban se basa en la idea de que el trabajo en curso debería limitarse, y sólo deberíamos
empezar con algo nuevo cuando un bloque de trabajo anterior había sido entregado a pasado a
otra función posterior a la cadena.

la metodología kanban utilizó un mecanismo de control visual para hacer seguimiento del
trabajo conforme este viaje a través del flujo de valor. Normalmente, se emplea un panel o
pizarra con notas adhesivas o un papel electrónico de tarjetas para gestionar el flujo de trabajo
y las asignaciones. Las mejores prácticas apuntan al uso de ambos métodos. Implica que se
genere una señal visual para indicar que hay nuevos bloques de trabajo que pueden ser
compensados porque el trabajo en curso actual no alcanza el máximo acordado.

El aporte principal de kanban a las metodologías ágiles es que a través de la implementación de

tarjetas visuales, proporciona transparencia al proceso, y a que su flujo de trabajo expone los
cuellos de botella, colas, variabilidad y desperdicios a lo largo del tiempo y todas las cosas que
impactan al rendimiento de la organización en términos de la cantidad de trabajo entregado y
el ciclo de tiempo requerido para entregarlo. Proporciona a los miembros del equipo y a las
partes interesadas visibilidad sobre los efectos de sus acciones o falta de acción. De esta forma,
cambia el comportamiento y motiva a una mayor colaboración en el trabajo.

Como Resultado, kanban propicia la evolución incrementada en los procesos existentes, una
evolución generalmente está alineada con los valores de la metodología ágiles. Kanban no
genera una revolución radical de la forma en que las personas trabajan, sino que sugiere un
cambio gradual. Es un cambio que surge del entendimiento y del consenso de entre todos los
participantes del proyecto.

Las principales ventajas de esta metodología es que es muy fácil de aplicar, actualizar y asumir
por parte del equipo. Ademas, se destaca por utilizar una técnica de gestión de las tareas muy
visual y práctica, lo que permite ver a simple vista el estado de los proyectos, así como también
pautar el desarrollo de trabajo de manera efectiva.

Aplicación del metodo Kanban

La aplicación del método kanban implica la generación de un tablero de tareas que permitirá
mejorar el flujo de trabajo y alcanzar un ritmo sostenible.

1. definir el flujo de trabajo de los proyectos: para ello simplemente debemos crear
nuestro propio tablero, que deberá ser visible y accesible por parte de todos los
miembros del equipo. Cada una de las columnas corresponder a un estado concreto de
flujo de tareas, que nos servirá para saber en qué situación se encuentra cada proyecto.
El tablero debe tener tantas columnas como Estados por los que pasa una tarea, desde
que se inicia hasta que finaliza.
2. visualizar las fases del ciclo de producción: que ambas se basa en el principio de
desarrollo incremental, dividiendo el trabajo en distintas partes. Esto significa que no
 hablamos de la tarea en sí, sino que lo dividimos en distintos pasos para agilizar el
proceso de producción.
3. stop starting, start finishing: este es el lema principal de la metodología kanban. De esta
manera, se prioriza el trabajo que estaba en curso en vez de empezar nuevas tareas.
4. control de flujo: gamba no se aplica un único proyecto, sino que mezcla tareas y
proyectos. Se trata de mantener a los trabajadores con un flujo de trabajo constante, las
tareas más importantes en colas para hacer desarrolladas y un seguimiento pasivo para
no tener que interrumpir al trabajador en cada momento.

Las tres reglas de Kanban

1) Mostrar el proceso
consiste en la visualización de todo el proceso de desarrollo, mediante un tablero físico,
públicamente asequible. El objetivo demostrar el proceso, consiste en:
 entender mejor el proceso de trabajo actual.
 conocer los problemas que puedan surgir y tomar decisiones
 mejorar la comunicación entre todos los interesados/participantes del proyecto
 hacer los futuros procesos más para decirles

el tablero kanban, se divide en columnas en las cuales representan un proceso de

trabajo. La cantidad y nombre de las columnas, varía de acuerdo a las necesidades de
cada equipo y en la mayoría de los casos, estás, son sus divididas en dos columnas: cola
de espera en curso.

2) limitar el trabajo en curso

los límites de trabajo en curso consiste en acordar anticipadamente, la cantidad de
ítems que pueden abordarse por cada proceso. El principal objetivo de establecer estos
límites, es el de detectar cuellos de botellas que representa el estancamiento de un
proceso determinado.
 Es un valor a tener en cuenta, que la resolución de cuellos de botellas, la mayoría
de las veces, motiva la colaboración del equipo entre los diferentes procesos.

3) optimizar el flujo de trabajo

el objetivo es generar una producción estable, continua y previsible. Midiendo el
tiempo que el ciclo completo de ejecución del proyecto demanda, se obtiene el
CycleTime.

al dividir, el CycleTime por el WIP (trabajo en curso), se obtiene el rendimiento

de trabajo, denominado Throughput, es decir, la cantidad de ítems que un
equipo puede determinar un determinado período de tiempo.

Con estos valores, la optimización de flujos de trabajo consistirá en la búsqueda de:

 minimizar el CycleTime
 maximizar el Throughput
 lograr una variabilidad mínima entre CycleTime y Throughput

pincho todo eso, se puede decidir que implementando cambios se consigue

aumentar la eficiencia en los procesos, evitar retrasos y no desaprovechar recursos,
reduciendo de tiempos muertos entre procesos, mejor mantenimiento, información
más rápida y precisa, minimización de entregas con errores y evitar sobrecarga de
trabajo.

Principios Basicos del metodo Kanban?

 calidad garantizada: todo lo que se hace debe salir bien en la primera instancia,
no hay margen de error. Para lograr esto no se premia la rapidez, sino la calidad
final de las tareas realizadas.
 reducción del desperdicio: se basa en hacer solamente lo justo y
necesario, para garantizar que se haga bien.
 mejora continua: se acuerda perseguir el cambio incremental y evolutivo. No es
simplemente un método de gestión, sino también un sistema de mejora en el
desarrollo de proyectos, según los objetivos a alcanzar.
 Flexibilidad: es necesario poder priorizar aquellas tareas entrantes según
las necesidades del momento y tener la capacidad de dar respuestas a
estas tareas imprevistas.