INGENIERÍA DE SOFTWARE Y FUNDAMENTOS DE DISEÑO ÁGIL

INTRODUCCIÓN

En esta entrada hablaremos de la complejidad de los softwares y de su ingeniería. De igual manera, se discutirán las principales razones por las cuales llegan a fallar, junto con las mejores prácticas para mejorar la calidad de este pedazo de tecnología de la computación. 

Se hablará sobre su ciclo de vida y de sus típicas metodologías, y se terminará con la discusión de los métodos ágiles. 

DESARROLLO

• El tema de ingeniería de software es cómo evitar que falle el software

• La ingeniería del software es la rama de las ciencias de la computación que busca principios que sirvan como guía al desarrollo de sistemas de software complejos y de gran tamaño

• Complejo es distinto de complicado

• Complejo es algo que tiene muchas ramificaciones al interior pero que todo está perfectamente diseñado

• Complicado es algo que no salió como lo esperado

• El desarrollo de estos sistemas requiere el esfuerzo de más de una persona a lo largo de un periodo extendido de tiempo durante el cual los requisitos del sistema propuesto pueden verse alterados y el personal asignado al proyecto puede variar

• La ingeniería del software es muy parecido a la ingeniería

• Se comienza con hacer un plano

Disciplina de la ingeniería del software

• ¿Cómo podemos estimar el coste en tiempo y dinero y otros recursos necesarios para completar el proyecto?

• ¿Cómo podemos dividir el proyecto en piezas más manejables?

• ¿Cómo podemos garantizar que las piezas producidas sean compatibles?

• ¿Cómo pueden comunicarse las personas que estén trabajando en las distintas piezas?

Diferencias de la ingeniería del software

• Capacidad de construir sistemas a partir de componentes genéricos prefabricados

• Los componentes de software son diseñados para un dominio específico y para una aplicación específica

• Falta de técnicas cuantitativas, denominadas métricas, para medir las propiedades del software

• La complejidad del software es difícil de medir

• La calidad de un producto software es difícil de medir (tiempo entre fallos no es una buena métrica)

Dependencia y Errores en el Software

• Nuestra sociedad es dependiente a los sistemas de computadoras y software

• Nuestra economía, la salud pública, el gobierno, las fuerzas de seguridad, el transporte y la defensa dependen de sistemas software de gran envergadura

• Los errores en el software han provocado desastres o casi desastres

• There are 3 reasons why systems go down:

• No redundancy: company might have chosen not to protect itself with a backup system

• Hacking: caused by a malicious attacker. 

• Human Error: layers and layers of systems that pile up over time create some kind of glitch and suddenly the whole thing comes crashing down

Why software fails?

• Why do projects fail so often?

• Los factores o razones más comunes por las cuales los software fallan, es decir, las razones por las cuales la IEEE (Asociación de Software) establece las razones por las cuales fallan los proyectos son:

• Un realistic or unarticulated project goals

• Inaccurate estimates of needed resources

• Badly defines system requirements

• Poor reporting of the project’s status

• Unmanaged risks

• Poor communication among customers, developers and users

• Use of immature technology

• Inability to handle the project’s complexity

• Sloppy development practices

• Poor project management 

• Stakeholder politics

Mejorando la Calidad en el Software

• Ingeniería del software asistida por computadora (CASE)

• Sistemas de planificación de proyectos: como ayuda para la estimación de costes para la fijación de hitos en los proyectos y para la asignación de personal

• Sistemas de gestión de proyectos: como ayuda para el monitoreo del progreso del proyecto desarrollo

• Herramientas de documentación: como ayuda para la escritura y organización de la documentación

• Sistemas de prototipado y simulación: como ayuda al desarrollo de prototipos

• Sistemas de programación: como ayuda a la escritura y depuración de programas

Asociaciones Profesionales

• ACM: Association for Computing Machine

• IEEE: Institute of Electrical and Electronics Engineers

Otras cuestiones 

• ¿Por qué el número de líneas de un programa no sería una actividad de esta?

• R=Porque el que sea más largo no implica que sea mejor o más eficiente para la realización de una tarea, inclusive puede ser todo lo contrario, además un código de mayor longitud es más propenso a equivocación y corre más lento

• Sugiera una métrica para medir la calidad del software. ¿Qué debilidades tiene su métrica?

• R=Rapidez de ejecución de una tarea. Las debilidades podrían ser que aunque uno rápido haría ver que es eficiente no implica que sea libre de errores por completo, sino nos podría dar un resultado distinto de lo deseado

• ¿Qué técnica puede utilizarse para determinar cuántos errores hay en una unidad del software?

• R= Realizar dos códigos distintos pero que tengan el mismo objetivo y ver si se llega al mismo resultado

El ciclo de vida del software

•  Siempre todo software se desarrolla, se usa y se mantiene

• Una vez que el software ha sido desarrollado, entra en un ciclo de utilización y mantenimiento, un ciclo que continúa durante el resto de la vida útil de ese software

• En otros productos, la fase de mantenimiento tiende a ser un proceso de reparación, en el caso de software suele consistir en correcciones y actualizaciones

• El proceso de mantenimiento normalmente requiere que una persona estudie el programa subyacente y su documentación para entender el programa, o cuando menos la parte pertinente del mismo

• En ocasiones resulta más fácil desarrollar un nuevo sistema partiendo de cero que modificar adecuadamente el paquete existente

Ingeniería de Software

Fase de desarrollo tradicional del ciclo de vida del software

• Las fases son:

• Análisis de requisitos: especificar qué servicios proporcionará el sistema propuesto, identificar las condiciones impuestas a esos servicios y definir cómo interactuará el mundo exterior con el sistema

• Diseño: crear un plan para la construcción de este sistema propuesto

• El diseño consiste en tratar de desarrollar una solución para un problema

• El resultado de la fase de diseño es una descripción detallada de la estructura del sistema software que puede convertirse en programa

• Implementación: implica la escritura de programas la creación de archivos de datos, y el desarrollo de bases de datos

• Analista de software vs. programadador

• El analista tiene una visión tipo cliente, entiende mejor la problemática del cliente mientras que el programador solamente programa el código y no tiene porqué entender la problemética del cliente, sólo realiza

• Pruebas: proceso de depurar los programas y confirmar que el producto software final es compatible con la especificación de requisitos

• Eliminación de errores

Ciclo de vida del software

• El ciclo de vida de un software es:

1. Crear el software
2. Usar el software
3. Reemplazar el software

Metodologías de ingeniería de software

• Modelo en cascada: proceso estrictamente secuencial

• Modelo incremental: en este modelo el primer sistema es una versión simplificada del producto final con una funcionalidad limitada (por ejemplo, Whatsapp empezó sólo con mensajes de texto y luego ya hay fotos, llamadas, etc.)

• Modelo iterativo: en este modelo el primer sistema es una versión incompleta del sistema al cual se van añadiendo características (por ejemplo, una página web con un catálogo)

• Proceso unificado racional: un paradigma de desarrollo de software que redefinir los pasos de la fase de desarrollo del ciclo de vida del software y proporcionar directrices para llevar a cabo esos pasos

• Tiene ramas y cada rama evoluciona de manera diferente

• Prototipado rápido: se construye rápidamente un ejemplo simple del sistema propuesto.

• Esto se hace durante las etapas iniciales del desarrollo

• El objetivo no es una versión funcional del producto sino conseguir una herramienta de demostración que puede utilizarse para aclarar requerimientos

• Desarrollo de código fuente abierto (Open Source): un único autor escribe una versión inicial del software y publica código fuente y su documentación en internet

• Desde allí puede ser descargado y modificado por otros usuarios sin ningún costo

• Métodos ágiles: implementación rápida y temprana basada en el concepto incremental, una adecuada capacidad de respuesta a las variaciones en requisitos y menor énfasis en la rigurosidad del análisis de requisitos y el diseño

Métodos Ágiles

• Son un grupo de métodos de desarrollo de software que son iterativos y de desarrollo incremental donde los requerimientos y las soluciones evolucionan a través de la colaboración entre equipos multifuncionales y auto organizados

• Promueven la planeación adaptativa, el desarrollo evolucionario y la entrega flexible y con alta respuesta al cambio

• Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

• It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change

 

• Manifiesto por el Desarrollo Ágil de Software

• Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros

• A través de este trabajo hemos aprendido a valorar:

• Individuos o interacciones sobre procesos y herramientas

• Software funcionando sobre documentación extensiva

• Colaboración con el cliente sobre negociación contractual

• Respuesta ante el cambio sobre seguir un plan

• Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda

• Los principios ágiles son:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirement, even late in development
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
7. Working software is the primary measure of progress

• Scrum:

• Se tiene un software, éste se parte en pedacitos 

• El equipo desarrolla parte de esos pedacitos

• Durante 30 días no hay cambios, solamente se dedican a programas 

• Se hace una reunión diaria de lo que se va a hacer

• Se convierte en un producto entregable

• Los métodos ágiles están siendo utilizados más que solamente una metodología de desarrollo de software

• Mitos:

• No hay planeación

• No hay gobernanza

• No hay documentación

• Respuestas rápidas y efectivas a un ambiente dinámico de negocios

• Puede salir mal

• Cambio de mentalidad

• Transformación organizacional

SCRUM

• Scrum is an agile approach for developing products and services

• Scrum es uno de los métodos ágiles más comunes

• Todo el equipo empuja para lograr un objetivo

                    

• La lista de cosas que debe hacer un negocio se llama product backlog (es el wish list de todas las cosas que harían el producto genial)

• Su ventaja es que el cliente puede pedir nuevas cosas en el momento que quiera, es dinámico (no estático)

• Cada una de sus funcionalidades se divide en etapas (que están dentro de la iteración de planeación)

• En la iteración de planeación está el ciclo completo de producto

• Todo el equipo de scrum son de 6 a 8 personas

• La diferencia entre hacer las cosas con tecnología en cascada y con tecnología en scrum es que en cascada es como una carrera de relevos donde no puede entrar uno sino entra el otro, mientras que en scrum todos trabajan al mismo tiempo en equipo

• La tecnología en casada puede tener conflicto con los objetivos de alta velocidad y flexibilidad

• Lo que se debe de hacer para poner en internet un negocio es:

• Dominio

• Diseño de la página

• Contratos con empresas de envía

• Catálogo de productos: debe de tener precio, clave, nombre, característica, foto, descripción del producto

• La línea de tiempo de scrum es:

• 1995: Ken Schwaber published the first paper on scrum at OOPSLA

• 2001: Agile Software Development with Scrum   <-- book by Schwaber and Beedle

• 2004: Agile Project Management with Sum  <-- book by Schwaber

• 2011: The Scrum Guide <-- by Schwaber and Sutherland

¿Por qué deberíamos usar Scrum?

• Scrum permite tanto una exploración rápida de productos, como también permite la retroalimentación

• Scrum da un enfoque balanceado al diseño, el caul incluye algo del diseño up front combinado con el diseño de just-in-time

• Scrum requiere de un enfoque de tamaño multifuncional

• Scrum alienta a hacer sincronización diaria

Beneficios de Scrum

• Clientes felices

• Mejor retorno de la inversión

• Reducción de costos

• Resultados más rápidos

• Confianza en el hecho de ser exitoso en un mundo tan complejo

• Mayor felicidad y alegría

• Scrum se enfoca en la entrega de características funcionales, integradas, probadas y valiosas para el negocio en cada iteración

Scrum Framework (estructura)

• Scrum es un framework/estructura para organizar y administrar el trabajo (no es un proceso estandarizado)

• El framework/estructura de Scrum está basado en un conjunto de valores, principios y prácticas que proporcionan la base sobre la que una organización va a añadir su propia implementación de prácticas de ingeniería relevantes y sus propios métodos para realizar las prácticas de scrum

• Scrum es sencillo

• Es un framework/estructura centrado en las personas y basado en los valores de la honestidad, apertura, valentía, respeto, confianza, focus, empoderamiento y colaboración

 

• Los componentes que necesitamos para llevar a cabo un proyecto de Scrum son:

• Los roles (normalmente ninguno es jefe de los demás, sino que todos están al mismo nivel) son: 

• El dueño del producto: 

• Platica con el cliente

• Es el que da la prioridad de qué historia se va a desarrollar primero

• Es el responsable de lo que se va a desarrollar y en qué orden

• Mantiene y comunica a los otros participantes una visión clara de lo que el equipo de desarrollo está tratando de lograr

• Tiene la obligación de asegurarse que el trabajo más valioso siempre se esté desarrollando

• Activamente colabora con el ScrumMaster y con el equipo de desarrollo, y debe estar dispuesto a responder preguntas

• No es el jefe de nadie

• El ScrumMaster (o el ninja): 

• Actúa como un coach al proveer de liderazgo de procesos

• No desarrolla

• Es un resolutor de problemas, siempre hace la pregunta de ¿Qué dificultad tienes? o ¿qué te impide avanzar?, es decir, es un facilitar pues ayuda al equipo a resolver problemas y hacer mejoras en el uso de scrum

• Es el responsable de guiar al equipo en la creación y seguimiento de su propio proceso basado en el framework (estructura) de scrum

• Ayuda a todos los involucrados a entender y a adoptar los valores, principios y prácticas de scrum

• Protege a su equipo de la interferencia externa y quita impedimentos

• Funciona como un líder pero no como un administrador o gerente; no es jefe de nadie

• El equipo de desarrollo: 

• Es el responsable de determinar cómo se va a entregar lo que pidió el dueño del producto

• Es diverso, es una colección multifuncional de lo que las personas son responsables de diseñar, crear y probar el producto deseado

• Es auto organizado

• Es de 5 a 9 personas y sus miembros deben tener en conjunto todas las habilidades necesarias para producir un software de buena calidad y funcional

• Las actividades son las cosas que hacemos en la práctica de scrum:

• Sprint: 

• Pueden ser 7 días, 10 días, 15 días, o lo que sea hasta un mes calendario y todos deben ser de la misma duración (hay fecha de inicio y de término)

• El trabajo completado en cada sprint debería crear algo tangible

• No hay cambios de objetivos, metas o de personal (programadores) durante el sprint

• La selección de funcionalidades que se hace para el sprint no debe de cambiar)

• Planeación del sprint

• El dueño del producto y el equipo de desarrollo se ponen de acuerdo en un objetivo de sprint que define lo que se supone que va a alcanzar el siguiente sprint

• Se escogen las funciones que trabajan a una marcha sostenible, lo que deriva en las tareas que se van a implementar en cada función

• Toma de 4 a 8 horas durante 2 semanas a 1 mes de sprints

• Reunión diaria

• Son juntas de 15 minutos (stand-up diario)

• Es esencial para ayudar al equipo de desarrollo a administrar el flujo de trabajo flexible y rápido

• No es una actividad para resolver problemas

• No es una junta de estatus tradicional

• Es principalmente una actividad de inspección, sincronización y de planeación adaptativa diaria

• El dueño del producto no tiene que estar en la reunión diaria

• El ScrumMaster facilita y cada miembro del equipo respondiendo 3 preguntas:

1. ¿Qué es lo que logré desde la última reunión diario?
2. ¿Qué es en lo que planeo trabajar para la próxima reunión diaria?
3. ¿Cuáles son los obstáculos o impedimentos que me están impidiendo progresar?

• Ejecución del sprint

• El equipo de desarrollo, guiado por el coacheo del ScrumMaster realiza todo el trabajo a nivel de tarea necesario para que las funcionalidades se hagan

• “Hecho o Done” significa que hay un gran nivel de confianza para que se termine todo el trabajo necesario para producIr funcionalidades de buena calidad

• Es una porción de una funcionalidad del producto que es funciona lo suficiente y que se puede usar para generar retroalimentación que permita al equipo decidir el trabajo que se debe hacer después o cómo hacerlo

• Nadie le dice al equipo de desarrollo en qué orden o cómo hacer el trabajo a nivel de tarea

• Revisión del sprint:

• El objetivo de esta actividad es inspeccionar y adaptar el producto que está siendo creado

• Evaluar y conversar con el equipo de scrum, grupos de interés, patrocinadores, clientes y miembros interesados de otros equipos   <-- Genera visibilidad y concentración

• Inspecciona y adapta el producto

• Retrospectiva del sprint:

• Es antes de la planeación del sprint

• Es una oportunidad de inspeccionar y adaptar el proceso

• El equipo de desarrollo, el ScrumMaster y el diseño del producto vienen juntos a checar qué es lo que está funcionando y que es lo que no está funcionado con el scrum y sus prácticas

• Compromisos para cambiar el proceso

• Acondicionamiento del product backlog; priorizar, ordenar o arreglar el product backlog

• Un artefacto tiene que ver con las cosas que hay en la práctica de scrum. En este sentido, los artefactos son los siguientes:

• Product backlog: lista de características que son requeridas para cumplir con la visión del dueño del producto

• Evoluciona constantemente

• Se hace el trabajo más valioso primero

• El desarrollo continuo de productos pueden contener nuevas funcionalidades, cambios en las mismas, defectos que necesitan reparación, mejoras técnicas, etc

• El tamaño de los ítems deben ser medidas de tamaño relativo, puntos históricos, días ideales

• El backlog del sprint: qué desarrollamos durante los 7 días, o 10 días, o 15 días, etc.

• Incremento de producto potencialmente enviable

• Las reglas

• Están descritas a través de todo el libro

• El Scrum no es una cura mágica

• Es bueno para los esfuerzos de desarrollo de productos complejos

• El scrum framework (estructura) es sencillo, pero sería un error asumir que es fácil y libre problemas de aplicar

• No es de prescripción

• Genera visibilidad a los procesos de negocio

• Permite ver que tan lento o rápido se está avanzando

    

SCRUM para trabajo interrumpido: Kanban

• El scrum no está bien diseñado para el trabajo con alta interrupción

• Cuando se tiene un proyecto al que siempre se le tiene que estar dando revisión se usa Kanban para ver quien está haciendo qué cosas y tener la visibilidad suficiente de cada una de las actividades de cada persona

• Kanban es un método que se interlapa en un proceso existente (en lugar de una solución de proceso independiente y que defiende:

• Visualización de cómo el trabajo fluye a través de todo el sistema (por ejemplo, los pasos que una organización (por ejemplo, los pasos que una organización de soporte toman para resolver una pregunta relacionada con el soporte)

• Limita el trabajo en proceso en cada paso para asegurar que no se está haciendo más trabajo del que tienen la capacidad de hacer

• Mide y optimiza el flujo de trabajo a través de un sistema para hacer una mejora continua

CONCLUSIÓN

Una gran metodología para implementar en los procesos de negocio son los métodos ágiles, porque requieren de un gran trabajo en equipo, de búsqueda y logro en tiempo y forma de los objetivos de un proyecto y alcance de resultados. para esta metodología, resulta muy fácil que un error acarree otros pero gracias a que se requiere de chequeos constantes para ver lo que estamos haciendo mal, bien o podemos hacer mejor, se pueden detectar con facilidad y no algo que solamente se podría ver hasta terminar el proyecto, además es un modelo flexible que permite ir adaptando a las necesidades y requerimientos de los clientes.