Apunte ingeniería de software

Apuntes I1 Software

1. Proceso de desarrollo de software

• Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.
• ¿Por qué?

• Encontrar y repetir buenas prácticas.
• Administrar recursos, estimar y planear.

• ¿Cómo elegir un modelo?

• Factores organizacionales y humanos.
• Factores tecnológicos.
• Factores del negocio.
• Factores regulatorios.

Modelo de cascada

[pic 1]

Procesos iterativos

• Secuencia de iteraciones.
• No es necesario que se produzca código en cada iteración.
• Modelo espiral, de prototipos y unificado.

Modelo espiral

• Considera el riesgo de forma explícita.
• Cada iteración consta de 4 fases:

1. Análisis de requisitos.
2. Construcción.
3. Evaluación y análisis de riesgo.
4. Planeación de la siguiente iteración.

[pic 2]

Modelo de prototipos

• Proceso basado en prototipos.
• El prototipo se usa para que el usuario pueda evaluar la propuesta en forma temprana y resolver el dilema de “el usuario sólo sabrá lo que quería cuando le muestres el resultado”.
• Prototipo desechable: sólo se usa para asegurar que el usuario valide lo que se está construyendo, después se desecha.
• Prototipo evolutivo: evoluciona hasta convertirse en producto final.

Modelo unificado

• Considera un desarrollo en 4 fases, en las cuales se llevan a cabo distintas actividades.

1. Inicio: definir el alcance del sistema para validar los costos y presupuestos iniciales.
2. Elaboración: Establecer cómo se construirá el sistema dadas las restricciones existentes.
3. Construcción: Construir un sistema que opere exitosamente (beta).
4. Transición: Entregar el sistema totalmente funcional a los clientes.

Procesos iterativos incrementales

• Permite desarrollar un sistema a través de iteraciones, en las cuales se produce un incremento de valor para el cliente con funcionalidades listas para ser usadas.

Procesos ágiles

• Los procesos ágiles están basados en el manifiesto ágil y son de naturaleza adaptativa.
• Xtreme programming, scrum.
• Valores del manifiesto ágil:

1. Individuos e interacciones por sobre procesos y herramientas.
2. Software funcionando sobre documentación extensiva.
3. Colaboración con el cliente sobre negociación contractual.
4. Responder a los cambios en lugar de apegarse a un plan.

• Principios del manifiesto ágil:

Extreme Programming

• Buenas prácticas alineadas con valores y principios del manifiesto ágil.
• On-site customer, small releases, simple design, testing, pair programming, continuous integration.
• Ventajas:

Scrum

• Responde a los principios ágiles al abrazar la variabilidad, desarrollar en forma iterativa e incremental, inspeccionar y adaptar constantemente, fomentar la transparencia y reducir incertezas.
• Roles

1. Product Owner:

• Prioriza los ítems del product backlog.
• Define las features del producto.
• Define el alcance y el cronograma.
• Responsable de alcanzar los objetivos financieros.
• Ajusta las características y prioriza cada sprint como sea necesario.
• Acepta o rechaza los resultados del trabajo.

1. Scrum Master:

• Responsable de velar los valores y prácticas de Scrum.
• Entrena al equipo para conseguir la mejor performance posible.
• Elimina obstáculos.
• Ayuda a mejorar la productividad.
• Habilita la relación cercana entre todos los roles y funciones.
• Asegura que todos entienden las metas de los sprints.
• Encontrar técnicas efectivas para el manejo del product backlog.

1. Developers

• Típicamente 5 a 9 personas.
• Programadores, testers, ui designers, etc.
• El equipo se auto-organiza.
• Inculcar calidad al producto.
• Responsabilizarse como profesionales.
• Sigan los valores Scrum: compromiso, foco, franqueza, respeto y coraje.

• Artefactos

1. Product backlog:

• Ítems o tareas que deben ser ejecutados o desarrollados.
• Priorizado por el product owner.
• Re-prioriza en cada sprint.

1. Sprint backlog:

• Muestra el trabajo que los desarrolladores realizan durante el sprint.

1. Potentially shippable product/incremento:

• En cada sprint se genera un resultado que podría ser entregado.
• Cada incremento se suma a todos los incrementos anteriores y se verifica minuciosamente que funcionen juntos.

• Actividades

1. Sprint: iteración, típicamente de dos a cuatro semanas de duración
2. Sprint planning: el equipo selecciona ítems del “product backlog” que ellos se comprometen a completar. Las tareas son identificadas y estimadas.
3. Daily Scrum: los miembros del equipo indican que hicieron desde ayer, qué pretendo hacer hoy y posibles obstáculos visibles. Mejora autogestión y comunicación.
4. Sprint execution: ejecución de las tareas en el orden que el equipo decida.
5. Sprint review: todo el equipo participa, permite inspeccionar y adaptar el producto a medida que transcurren las iteraciones.
6. Sprint retrospective: segunda reunión al final del sprint. Está orientada a reflexionar y ver formas de mejorar el proceso.

1. Requerimientos

• Descripciones de lo que el sistema debe hacer.
• Reflejan las necesidades de los clientes.
• Funcionales: qué es lo que el sistema debe ser capaz de hacer. Servicios, comportamiento del sistema.
• No funcionales: restricciones y exigencias, como desempeño y usabilidad.

Relatos de usuario

• Es un enfoque que describe la funcionalidad que será valiosa para un usuario o cliente de un sistema o software.
• Tienen 3 aspectos:

1. Card: Una descripción escrita de la historia a ser usada para la planificación y como recordatorio. Usualmente se usaban tarjetas de 3X5 pulgadas.
2. Conversation: Los detalles de una historia de usuario, son capturados durante la conversación con el usuario o product owner.
3. Confirmation: Las pruebas de aceptación confirman que una historia de usuario fue completada correctamente.

• Estructura

• El nivel de abstracción de una historia de usuario debe ser el ideal para implementarse en un sprint.
• Epics: Grandes historias de usuario que pueden abarcar meses de desarrollo. Estas normalmente se refinan progresivamente en historias de usuario más pequeñas.
• Theme: Contenedor de historias relacionadas.
• Elaboración de historias de usuario

1. User Story Writing Workshop: enfoque para la elaboración de historias e involucra a usuarios y stakeholders.

• Identificación de roles de usuario y un conjunto de historias de usuarios candidatos para la entrega del primer producto.
• Se puede empezar por EPICS y luego ir refinando en historias de usuario.

1. Story mapping: es una técnica de refinamiento y ordenación temporal de historias de usuario. Proporciona una lista priorizada del backlog.

• Calidad en historias de usuario: INVEST

1. Independent: independientes entre sí o débilmente relacionadas.
2. Negotiable: no es un contrato ni una especificación sino una referencia a una característica que el equipo debe discutir.
3. Valuable: deben proporcionar valor al usuario, describir características del sistema, no tareas.
4. Estimatable: Deben tener suficiente detalle para poder estimar el costo/tiempo de desarrollo.
5. Small: Debe caber en un sprint.
6. Testeable: Deben ser comprobables mediante pruebas.

• Problemas comunes en las descripciones:

1. Uso de tecnicismos.
2. Beneficio no claro.
3. Negación.
4. Épica.

...