Download - Ingeniería de Software
![Page 1: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/1.jpg)
Ingeniería de Software
Métricas / Ciclos de vida
![Page 2: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/2.jpg)
¿Porqué?“Cuando puedas medir lo que está diciendo y
expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas
expresar lo que dices con números, tu conocimiento es precario y deficiente.”
(Lord Kelvin)
Métricas
![Page 3: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/3.jpg)
¿Para qué sirve?◦ Medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado (IEEE Standard Glossary of Software Engineering, 1993)
Se aplican a:◦ Procesos (métricas de control): por ejemplo, tiempo y
esfuerzo medios necesarios para corregir un error.◦ Productos (métricas de predicción): complejidad ciclomática
de un módulo, número de métodos y atributos asociados con los objetos de un diseño,...
Permiten tomar decisiones◦ No se deben utilizar para sancionar empleados, sino para
definir procesos de mejora (training, beneficios nuevos, motivación, etc.)
Métricas
![Page 4: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/4.jpg)
Seleccionar métricas Realizar la medición Generar reportes de resultados Analizar los valores y proponer acciones
correctivas si son necesarias Proveer feedback a los stake holders
Métricas – Proceso general
![Page 5: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/5.jpg)
Métricas del producto (Atributos de calidad)◦ Estáticas
Reusabilidad Cantidad de clases Complejidad ciclomática
◦ Dinámicas Performance Cantidad de bugs encontrados
Métricas del proceso◦ Sobre tiempo◦ Sobre recursos◦ Sobre impacto de cambios
Métricas - Tipos
![Page 6: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/6.jpg)
Goal Question Metric es una metodología de definición de métricas, que especifica pasos basados en el hecho que para poder hacer mediciones útiles, primero debe definir qué objetivos tienen las mismas.Define un conjunto de pasos y buenas prácticas para definir dichas métricas
Selección de Métricas – GQM
![Page 7: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/7.jpg)
Conceptual level (GOAL): Un Goal se puede definir de acuerdo a su objeto, a los stakeholders involucrados y al contexto particular. Tipos de objetos a medir son:◦ Productos: Software, código fuente, documentación, entregables en general.◦ Procesos: Los procesos involucrados en el análisis, desarrollo, testing, etc.◦ Recursos: HW, SW, espacio de trabajo, personal involucrado
Operational level (QUESTION): Un conjunto de preguntas para cada goal, las cuales se utilizan para conocer el estado actual con respecto a una medida de calidad desde la perspectiva necesaria.
Quantitative level (METRIC): Se definen métricas, las cuales permiten medir de manera cuantitativa ciertas medidas de calidad para responder las preguntas dadas. Las métricas pueden ser:◦ Objetivas: no dependen del punto de vista: Cantidad de clases, Complejidad
ciclomática◦ Subjetivas: atractividad del software, entendibilidad del código
GQM - Pasos
![Page 8: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/8.jpg)
Conceptual level (GOAL): Un Goal se puede definir de acuerdo a su objeto, a los stakeholders involucrados y al contexto particular. Tipos de objetos a medir son:◦ Productos: Software, código fuente, documentación, entregables en general.◦ Procesos: Los procesos involucrados en el análisis, desarrollo, testing, etc.◦ Recursos: HW, SW, espacio de trabajo, personal involucrado
Operational level (QUESTION): Un conjunto de preguntas para cada goal, las cuales se utilizan para conocer el estado actual con respecto a una medida de calidad desde la perspectiva necesaria.
Quantitative level (METRIC): Se definen métricas, las cuales permiten medir de manera cuantitativa ciertas medidas de calidad para responder las preguntas dadas. Las métricas pueden ser:◦ Objetivas: no dependen del punto de vista: Cantidad de clases, Complejidad
ciclomática◦ Subjetivas: atractividad del software, entendibilidad del código
GQM - Pasos
![Page 9: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/9.jpg)
GQM - Goals Se debe definir a nivel organizacional los
goals que se quieren alcanzar. Tipos de goals
◦ Estratégicos: A largo plazo. Por ejemplo?◦ Tácticos: A nivel de proyecto
![Page 10: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/10.jpg)
GQM - Goals Se definen a partir de atributos que se desean mejorar. GQM
propone un conjunto de atributos para definir mejor un Goal. Atributos de un goal
◦ Propósito: Se definen especificando qué se desea hacer, con respecto a qué
◦ Punto de vista: desde la perspectiva de quién se busca◦ Contexto: El contexto que lleva a tal necesidad o información pertinente al
goalEjemplos: Goal 1:
◦ Propósito: Mejorar velocidad de resolución de incidentes◦ Punto de vista: Del punto de vista del PM◦ Contexto: Proyecto nuevo con muchos incidentes
Goal 2:◦ Propósito: Analizar la complejidad de las interfaces con otros sistemas◦ Punto de vista: Equipo de desarrollo◦ Context: Proyecto nuevo con hecho orientado a objectos
![Page 11: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/11.jpg)
GQM - Questions A cada Goal se le asigna un conjuntos preguntas que
permiten conocer cómo estamos con respecto a ese goal y qué falta hacer para conseguirlo.
Por ejemplo:◦ Goal 1:
¿Cuánto se tarda actualmente en arreglar un incidente? ¿Qué tipos de incidentes tardan más? ¿Se mejoró con respecto a versiones anteriores?
◦ Goal 2: ¿Qué cantidad de interfaces existen? ¿Cada cuánto cambian? ¿Qué porcentaje son interfaces de objetos java, de mensajería,
etc.?
![Page 12: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/12.jpg)
GQM - Métricas Para cada Goal se define una o más métricas
que permiten responder a esa pregunta de manera cuantitativa◦ Goal 1:
Cuánto se tarda actualmente en arreglar un incidente? Incidentes arreglados por día Vida promedio de los incidentes Comparación con iteraciones anteriores
◦ Goal 2: Cada cuánto cambian? Cambios requeridos en las itnerfaces por iteración Evolución de la cantidad de cambios
![Page 13: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/13.jpg)
Recolección de datos Recolección de datos
◦ Se debe definir el proceso de recolección de datos.◦ Teniendo en cuenta el objetivo de los goals que requieren
dichas métricas se define: Quién va a recolectar los valores?
si se va a hacer automáticamente o manualmente Cuándo se va a recolectar?
De acuerdo a los recursos con los que se cuenta, se define cuando se va a recolectar la información
Cómo se va a recolectar los datos? Se define si se hace de manera automática, qué herramientas se
cuentan, se debe “molestar” lo menos posible a las personas relacionadas con dichas métricas.
Quiénes son los principales stakeholders? Teniendo en cuenta la perspectiva y los stake holders se pueden obtener
mejor subjetividad al mostrar los resultados.
![Page 14: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/14.jpg)
Elaboración de reporte de resultados Se elaboran reportes con los resultados
utilizando gráficos:◦ de torta◦ de línea◦ histogramas◦ cuadros comparativos◦ diagramas de tendencia.
![Page 15: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/15.jpg)
Reporte - Ejemplo
![Page 16: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/16.jpg)
Análisis de resultados Se deben verificar los reportes y analizar las
posibles causas ◦ Se puede utilizar el diagrama espina de pescado
para analizar las causas Se deben especificar acciones para mejorar
![Page 17: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/17.jpg)
Comunicación de resultados Se debe dar feedback a los diversos
stakeholders sobre los resultados, describiendo:◦ Métricas utilizadas y resultados obtenidos◦ Reportes◦ Evaluación de causas y planes de acción
![Page 18: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/18.jpg)
Ejemplos
![Page 19: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/19.jpg)
Ejemplos
![Page 20: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/20.jpg)
Ejemplos
![Page 21: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/21.jpg)
Goal: Analyze the delivered product for the purpose of understanding, with respect to the effectiveness of reuse, and from the viewpoint of the software development team in the context of Project A.◦ What is the percentage of modules that were not developed
from scratch (i.e., some portion is reused [overall and per subsystem])? Metric 1. For each software module: Developed from scratch (yes,
no)? Metric 2. For each software module: Name of subsystem it belongs to
◦ What is the percentage of completely reused code (overall and persubsystem)? Metric 1. For each software module: Code reused (yes, no)? Metric 2. For each software module: Name of subsystem it belongs to
Ejemplos
![Page 22: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/22.jpg)
Goal: Analyze the delivered product for the purpose of understanding, with respect to the effectiveness of reuse, and from the viewpoint of the software development team in the context of Project A.◦ For software modules where code is reused: What is the distribution of
modules among reuse modification classes (overall and per subsystem)? Metric 1. Degree of code modification (unchanged, mainly deletions, less than 20
percent of lines changed, more than 20 percent of lines changed) Metric 2. Name and version of the original reused module Metric 3. Name and version of the released reusing module Metric 4. Name of subsystem it belongs to
◦ What is the relationship between module reuse and reliability? Metric 1. For all modules: What is the level of reuse? Metric 2. For top faulty modules: What is the level of reuse? Metric 3. For top non-faulty modules: What is the level of reuse? Metric 4. For all modules: What is the fault density? Metric 5. For reused modules: What is the fault density? Metric 6. For non-reused modules: What is the fault density?
Ejemplos (Cont.)
![Page 23: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/23.jpg)
Some conclusions were:◦ Reusing large parts of a module that is already
fixed results in significantly lower faults than if developed from scratch
◦ Faults in reused modules are detected more before delivery because reused modules are reviewed and tested more intensively than newly developed modules
Ejemplos (Cont.)
![Page 24: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/24.jpg)
Ciclos de vidaDescansemos un rato
![Page 25: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/25.jpg)
Es el conjunto de actividades requeridas, en un orden determinado, para desarrollar un Software.
Los tipos de actividades, entre otros, son:◦ Especificación de requerimientos◦ Diseño◦ Desarrollo◦ Validación◦ Evolución
Procesos de software / ciclos de vida
![Page 26: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/26.jpg)
Cada actividad además tiene un conjunto de:◦ Roles necesarios◦ Condiciones necesarias (para iniciar y para
terminar) Dependiendo del proceso, existen diversas
herramientas y metodologías aplicadas.
Procesos de software / ciclos de vida
![Page 27: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/27.jpg)
Un modelo de proceso es una representación abstracta del proceso.
Representa una descripción del proceso que permite conocer qué actividades y metodologías se utilizaron, en qué orden y a qué nivel.
Se conocen varios modelos de proceso, que se pueden adaptar de acuerdo a las necesidades y que fueron adaptándose en los últimos años.
Modelos de Ciclos de vida
![Page 28: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/28.jpg)
Esos modelos se pueden dividir en:◦ Orientados a planeamiento:
RUP Cascada Entrega en etapas
◦ Orientados a adaptación al cambio: Agile Prototipado evolutivo
◦ Orientados a disminuir riesgos: Spiral
◦ Orientados al tiempo: Entrega evolutiva Timebox
De acuerdo a las necesidades, un proceso puede tomar cosas de más de un modelo o incluso tomar distintos modelos para distintas etapas.
Modelos de Ciclos de vida
![Page 29: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/29.jpg)
Algunas preguntas:◦ Se requiere mucha documentación detallada o contrato muy rígido?◦ Se tiene seguridad con respecto a los requerimientos?◦ Se puede vender el proyecto, en lugar de como producto, como
servicio?◦ Es muy grande el proyecto? Tiene equipos en distintos lugares del
mundo?◦ Qué tipo de sistema se requiere?◦ Qué tipo de cliente se tiene?◦ Cuál es la expectación de vida del sistema a realziar?◦ Qué tecnologías se tienen al alcance y cuántos recursos se tienen para
acceder a tecnologías pagas?◦ Se puede mover la fecha de finalización?◦ Qué tan experto es el equipo?◦ Qué tan riesgoso es el proyecto? ◦ Cuánta visibilidad se necesita dar?
Cómo elegir un modelo?
![Page 30: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/30.jpg)
Qué pasa si no hay modelo?
![Page 31: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/31.jpg)
Se trata de un modelo en el que, una vez que se tiene una idea de lo que hay que hacer se empieza a desarrollar, cada cambio pedido se realiza directo en el código, etc.
En conclusión no se agrega ningún nivel de proceso. Simplemente, el o los programadores se sientan a programar.
Code And Fix
![Page 32: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/32.jpg)
Ventajas◦ No se requiere mucha experiencia◦ Para proyectos muy chicos presenta resultados
rápidamente: prototipos que se planea descartar pruebas de concepto demos
◦ Es fácil de aprender no hay que hacer nada◦ Es fácil de implementar en equipos de una persona:
no hay equipo
Code And Fix
![Page 33: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/33.jpg)
Desventajas◦ Si es un equipo, ya siquiera con 2 personas puede
llegar a un caos: ninguno sabe lo que hizo el otro se pisan los cambios se pierde conocimiento de los cambios que se fueron
haciendo y por qué no se conocen los tiempos totales, ni los costos no se conocen los riesgos el testing no existe o es exploratorio
Code And Fix
![Page 34: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/34.jpg)
Son modelos con etapas que deben estar definidas de antemano
Cada etapa tiene una salida definida de manera precisa y completa
La salida se utilizará como entrada para la etapa siguiente.
Son los modelos más clásicos, están basados en otras disciplinas
Modelos basados en planeamiento
![Page 35: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/35.jpg)
Waterfall
![Page 36: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/36.jpg)
Se definen ciertas etapas Las mismas deben estar terminadas antes de
avanzar a la siguiente La salida de dicha etapa no se puede cambiar y
va a ser utilizada como input para la etapa siguiente
En caso que el resultado de la etapa sea inválido se debe elegir cómo seguir◦ volver a realizar la etapa◦ extenderla◦ cancelar el proyecto.
Waterfall
![Page 37: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/37.jpg)
Ventajas:◦ En proyectos largos ayuda a conocer el largo total
del proyecto y ayuda a calcular el costo total del proyecto en etapas tempranas.
◦ Cuando hay pocos cambios, la eficiencia es óptima.◦ Al final de cada etapa se tiene, en teoría,
información precisa como para poder trabajar en la etapa siguiente.
◦ El personal encargado de una etapa puede pasar a otro proyecto al terminar la misma
Waterfall
![Page 38: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/38.jpg)
Desventajas:◦ Si bien ayuda a calcular el costo total, esto no toma
en cuenta los cambios en los requerimientos.◦ Al tener una documentación excesiva, la eficiencia
decrece dado que el personal trabaja en: diseñar partes muy pequeñas del sistema documentar requerimientos que luego no se harán
◦ Incapacidad de reaccionar a los cambios.
Waterfall
![Page 39: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/39.jpg)
Overlapped Waterfall
Waterfall - variantes
![Page 40: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/40.jpg)
Sub-project Waterfall
Waterfall - variantes
![Page 41: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/41.jpg)
Es un proceso desarrollado bajo una patente de Rational Está relacionado integramente con UML (Unified
Modeling Language) Busca integrar modelos existentes de manera de ser
orientado a:◦ Riesgos◦ Planificación ◦ Incrementalidad
Se definen 4 fases:◦ Inception◦ Elaboration◦ Construction◦ Transition
RUP (Rational Unified Process)
![Page 42: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/42.jpg)
En cada fase se desarrollan, en paralelo, distintos tipos de actividad que en Cascada, por ejemplo, se desarrollaban en secuencia.
RUP define actividades (Workflows):◦ Modelado de negocio◦ Ingeniería de requerimientos◦ Análisis y diseño◦ Implementación◦ Testing◦ Distribución◦ Configuración y evolución◦ Manejo de proyecto◦ Contexto y herramientas
Rational Unified Process
![Page 43: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/43.jpg)
De acuerdo a la fase, cada actividad se realiza en distinto nivel:
Rational Unified Process
![Page 44: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/44.jpg)
Rup define un conjunto de buenas practicas:◦ Desarrollo Iterativo e incremental
Se planifican Iteraciones en las que cada una propone un incremento con respecto a la anterior, el cual es visible y medible
De ésta manera se reducen riesgos al dar más visibilidad del avance◦ Orientado a casos de uso
Los requerimientos se escriben en forma de casos de uso, y estos deben ser mantenidos en el tiempo (cambios) y su avance es visible
Se utilizan herramientas de control de cambio y configuración. De esta manera se aumenta la visibilidad y se mejora la adaptación al
cambio◦ Orientados a la arquitectura
Lo primero que se debe definir es la arquitectura De esta manera se reducen riesgos de nivel técnico
◦ Basado en UML “Todos” conocen UML por lo que mejora la transmisión de conocimiento
Buenas Prácticas
![Page 45: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/45.jpg)
Es un modelo claro que permite establecer un balance entre el nivel de planificación, el manejo de riesgos y la adaptación al cambio
Utiliza herramientas de modelado (UML) que son conocidas mundialmente
Está ampliamente ligado a herramientas Case (Rational Rose) por lo que, al menos en teoría permite disminuir el nivel de codificación necesario
Define herramientas que deben ser utilizadas como control de versiones y configuración.
Rational Unified Process
![Page 46: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/46.jpg)
Desventajas◦ Caro de implementar: se requiere personal
capacitado en RUP, si se hace bien se debe acreditar dicha capacidad
◦ Se debe implementar completo, se implementa RUP completo, sus prácticas por separado no son RUP
◦ Las herramientas utilizadas en general son provistas por Rational y son caras
◦ Agrega mucho overhead al proyecto
Rational Unified Process
![Page 47: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/47.jpg)
También conocidos como Rapid Application Development (RAD) Son modelos de proceso que están de moda actualmente. Se basan en que los clientes puedan tener de manera rápida el
acceso del software, y que la reacción al cambio sea la prioridad. Las actividades de desarrollo, análisis, diseño y testing se suelen
hacer en paralelo Se realizan iteraciones cortas que permiten una visibilidad rápida
a los stakeholders Se suele tener representantes de los clientes trabajando en
conjunto con el equipo de desarrollo Aparecieron luego de sucesivas fallas en procesos clásicos de
desarrollo y por el “disgusto” que ocasionaba el alto overhead de los procesos.
Modelos Ágiles
![Page 48: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/48.jpg)
Buenas prácticas◦ Enfocarse en el código, perdiendo énfasis la
documentación◦ Desarrollo iterativo e incremental, con iteraciones
cortas de alta visibilidad◦ Se tiene software funcional de manera temprana, lo
que permite direccionar las expectativas de los clientes
◦ El software evoluciona a partir del feedback de los clientes
Modelos Ágiles
![Page 49: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/49.jpg)
Énfasis en las personas y sus interacciones vs procesos y herramientas:◦ Énfasis en las habilidades y conocimientos de las personas ◦ Se busca mejorar el potencial de las mismas, en lugar de estar atado a un proceso
Énfasis en software andando vs documentación◦ Se tiene software andando, desarrollando en incrementos y desarrollando primero los
requerimientos más importantes, en lugar de entregar documentación. Énfasis en colaboración con usuarios vs contratos rígidos
◦ Los usuarios/clientes colaboran durante todo el desarrollo, pueden ver el avance, darse cuenta a tiempo si se está perdiendo el rumbo, responder preguntas rápidamente y priorizar requerimientos
Énfasis en adaptación al cambio vs planeamiento◦ Se espera el cambio, no se reacciona ante él. El diseño, la especificación, el control de
cambios y el código se hacen pensando en el cambio.◦ Se utiliza el refactoring para ir adaptando el código a medida que se hacen los cambios
Énfasis en simplicidad vs complejidad◦ Se busca simplicidad. Algo simple es más fácil de entender y, sobretodo, de modificar.◦ Parte del proceso incluye activamente modificar o remover código complejo y
reemplazarlo por código más simple
Diferencias entre proceso clásicos y ágiles
![Page 50: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/50.jpg)
VentajasDe acuerdo al método ágil a utilizar hay distintas ventajas o desventajas, pero pueden ser resumidas en:◦ Adaptación al cambio asumida◦ Se aprovecha el potencial de todo el equipo◦ Mayor visibilidad a los clientes
Modelos Ágiles
![Page 51: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/51.jpg)
Desventajas◦ Pueden generarse problemas culturales◦ Se requiere tener un equipo con alto expertise para
compensar la falta de documentación◦ Es difícil de implementar cuando se requieren
contratos rígidos de facto◦ Es difícil de implementar en proyectos grandes◦ Al poner énfasis en personas, la importancia de las
mismas crece, por lo que se hace importante mantener el equipo
Modelos Ágiles
![Page 52: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/52.jpg)
Dado que Agile se potencia en la comunicación e integración de equipos se plantea que en proyectos grandes su implementación es de difícil e ineficiente, dado que:◦ tienen equipos funcionando en distintas zonas◦ tienen interfaces con otros sistemas◦ tienen sus sistemas distribuidos y el enfoque se da en la
comunicación entre esos sistemas◦ hay regulaciones y contratos que limitan la forma de
desarrollo◦ duran muchos años◦ tienen una gran variedad de stakeholders
Agile en proyectos grandes
![Page 53: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/53.jpg)
Para poder implementar agile se necesita:◦ Mayor nivel de documentación y diseño, haciendo foco en las interfaces
entre distintos componentes◦ Al tener equipos en distintas zonas se debe buscar formas de mejorar la
comunicación: comunicación individual por web cam conferencias con cámara herramientas que mejoren la visibilidad (SCM)
SCM es muy importante para poder conocer qué versiones de cada componentes son compatibles y para tener visibilidad de los cambios pedidos y realizados.
Se deben planear releases teniendo en cuenta las interfaces con otros sistemas
Dividir los proyectos grandes en proyectos chicos que puedan implementar las herramientas propuestas
Scaling up Agile en proyectos grandes
![Page 54: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/54.jpg)
Es más difícil dado que:◦ Empresas que por su forma de ser tienen altos requerimientos
burocráticos, standards y procesos rígidos◦ Se suelen utilizar modelos más clásicos dado que se tienen PM
que no aceptan los riesgos del cambio◦ Problemas culturales
Para poder evitar esto se puede◦ Utilizar Agile de a poco, en proyectos chicos e ir agregando de a
poco◦ Contratar expertos en metodologías Agile que ya tengan
experiencia en grandes empresas Aún así se debe tener en cuenta que puede ser imposible
implementar metodologías Agile si la cultura empresarial se resiste.
Scaling out Agile en empresas grandes
![Page 55: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/55.jpg)
Prototipado Evolutivo
![Page 56: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/56.jpg)
Se pone énfasis en el desarrollo de prototipos. Al inicio se realizan prototipos visuales y se
va avanzando luego en la arquitectura. En la práctica se pueden realizar prototipos
para cualquier tipo de entregable Se continúa desarrollando hasta que el cliente
decida terminar.
Prototipado Evolutivo
![Page 57: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/57.jpg)
Ventajas:◦ Cuando se tiene poco conocimiento de qué se
espera se van haciendo prototipos y se va corrigiendo el camino mientras se avanza
◦ A nivel de desarrollo sirve cuando no se sabe qué arquitectura utilizar se pueden crear distintos prototipos y elegir el más conveniente según los resultados.
◦ Los clientes tienen gran visibilidad del progreso
Prototipado Evolutivo
![Page 58: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/58.jpg)
Desventajas:◦ Se tiene poca visibilidad de la duración total del
proyecto◦ Su productividad es difícil de medir ya que no se
sabe a ciencia cierta qué hay que desarrollar◦ Puede terminar en proyectos infinitos
Prototipado Evolutivo
![Page 59: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/59.jpg)
Staged delivery
![Page 60: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/60.jpg)
Se definen a priori etapas en las que los entregables van a ser incrementos de software funcional.
Ya desde la primera entrega se tiene software funcional.
Desde el principio se debe saber qué versiones van a tener que funcionalidad
Las etapas de análisis y diseño de alto nivel deben ser rigurosas y en secuencia
Staged delivery
![Page 61: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/61.jpg)
Ventajas◦ Alta visibilidad◦ Alta certeza sobre las fechas◦ Se tiene la funcionalidad más importante al principio
Desventajas◦ No es adaptable al cambio◦ Se debe tener mucho cuidado con el planeamiento
de las entregas◦ Se debe tener cuidado con las dependencias entre
las funcionalidades
Staged delivery
![Page 62: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/62.jpg)
Timebox Development
![Page 63: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/63.jpg)
Es similar a staged delivery, pero el foco está en la fecha final en vez del alcance.
Su objetivo no es dar visibilidad sino certeza de que a cierta fecha se va a tener algo andando.
Se pone un límite de tiempo, y lo que se alcance a hacer para esa fecha es lo realizado.
Es utilizado en proyectos que por diversas razones dependen de la fecha final, por ejemplo festividades
Timebox Development
![Page 64: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/64.jpg)
Se deben establecer condiciones mínimas para la aceptación del proyecto.
Se planean etapas, una vez llegado la fecha límite, se utiliza el entregable de la última etapa completa.
Nunca se debe utilizar el código de una etapa no completa
Timebox Development
![Page 65: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/65.jpg)
Ventajas◦ Se tiene certeza de que se va a tener algo para la
fecha y que se tiene la funcionalidad más importante◦ Se sabe que dicho entregable ya paso por QA
Desventajas◦ Se pierde tiempo en análisis y diseño de
funcionalidad que no se va a desarrollar◦ Por sus características sólo sirve para ciertos tipos
de proyectos
Timebox Development
![Page 66: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/66.jpg)
Spiral
![Page 67: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/67.jpg)
El proceso se representa en forma de una espiral, en la que cada vuelta tiene mayor duración.
Cada vuelta es una fase del proceso.◦ El inicio de cada fase se centra en analizar los
riesgos y definir estrategias para mitigarlos.◦ Luego se realizan las actividades principales de la
fase (Ing. de req, desarrollo etc.) ◦ Al final se hace una evaluación del avance.
Spiral
![Page 68: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/68.jpg)
Ventajas◦ Propone etapas de análisis de riesgos de manera
explícita, reduciendo la probabilidad de fallo del proyecto
◦ Tiene un impacto directo costo-riesgo, a más costo menos riesgo.
Desventajas◦ Difícil de aprender e implementar.◦ Se requiere un equipo experto.
Spiral
![Page 69: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/69.jpg)
Func. requerida
Func. provista por frameworks
La idea es utilizar frameworks ya desarrollados y probados. Si cierta funcionalidad requerida no puede ser desarrollada
basándose en frameworks existentes que la solucionen, la funcionalidad NO DEBE SER INCLUIDA.
Hay riesgo al perder el control del código, con lo cuál se complica el soporte futuro.
Pero por otro lado se agilizan los tiempos de desarrollo y si los frameworks son maduros se minimizan los bugs.
Sirve en general para aplicaciones no muy grandes y/o desechables
Design to tools
Funcionalidad a desarrollar en el
sistema
![Page 70: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/70.jpg)
Tiene como ventaja lo rápido que se obtiene el software y se supone que es un software maduro o probado.
Pero es casi imposible extender la funcionalidad, y se está atado a los bugs y el soporte del fabricante (uno no puede resolverlos).
Se debe pensar seriamente: llegar a desarrollar el 70 % de la funcionalidad con mucho costo y mucho tiempo de desarrollo, contra cumplir con el 50%, pero a MUCHO menor costo y casi sin atrasos, tal vez el cliente prefiera eso, no?
COTS (commercial on the shelf)
![Page 71: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/71.jpg)
Preguntas
![Page 72: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/72.jpg)
Sugerencias
![Page 73: Ingeniería de Software](https://reader035.vdocumento.com/reader035/viewer/2022062410/56815ebc550346895dcd3f10/html5/thumbnails/73.jpg)
Aplausos