Apunte del Segundo Parcial (Ingeniería II)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

Mejora de Procesos[editar]

Se busca alcanzar un cierto nivel de madurez de procesos. A mayor madurez, el proceso esta definido, es administrado, medido, controlado y es efectivo. En una organizacion inmadura cada equipo se maneja de manera improvisada, no hay procesos definidos, hay baja visibilidad y es muy dependiente de las personas que lo ejecutan.

Modelo IDEAL[editar]

El modelo IDEAL es un modelo de mejora de procesos que cubre:

  • Initiating: se setea un contexto de trabajo,
  • Diagnosing: se caracteriza el estado actual y el deseado,
  • Establishing: se setean prioridades y crea un plan de accion,
  • Acting: se ejecuta dicho plan creando y refinando una solucion, y
  • Learning: se analiza y miden los resultados, tras lo cual se retroalimenta hacia la parte de diagnosing.

CMMI[editar]

Capability Maturity Model Integration es un modelo que permite determinar el nivel de madurez de procesos en una empresa. Esta basado en muchos otros modelos, entre ellos CMM, respecto del cual agrega detalle y precision sobre tecnicas y best practices, ademas de ser ISO compliant.

Propone una division en 5 niveles distintos de madurez. El modelo puede ser representado o bien por niveles (indicando que practicas se corresponden a cada nivel, util para migrar de SW-CMM) o bien de manera continua (indicando las practicas por area). Cada nivel tiene generic best practices y luego specific goals por area.

Los niveles de CMMI son los siguientes:

  1. El primer nivel se considera el inicial, con procesos impredecibles, no controlados; no se encuentra especificado en el CMMI.
  2. Managed o repeatable, manejo basico de procesos, que se encuentran caracterizados para proyectos y es fundamentalmente reactivo.
  3. Defined, se estandarizan los procesos a nivel organizacion, es mas proactivo que reactivo.
  4. Quantitatively managed, los procesos se miden y controlan.
  5. Optimizing, mejora continua de los procesos.

Las siguientes son las areas cubiertas por cada nivel de CMMI:

  • Level 2 Managed
    • CM - Configuration Management
    • MA - Measurement and Analysis
    • PMC - Project Monitoring and Control
    • PP - Project Planning
    • PPQA - Process and Product Quality Assurance
    • REQM - Requirements Management
    • SAM - Supplier Agreement Management
  • Level 3 Defined
    • DAR - Decision Analysis and Resolution
    • IPM - Integrated Project Management +IPPD
    • OPD - Organizational Process Definition +IPPD
    • OPF - Organizational Process Focus
    • OT - Organizational Training
    • PI - Product Integration
    • RD - Requirements Development
    • RSKM - Risk Management
    • TS - Technical Solution
    • VAL - Validation
    • VER - Verification
  • Level 4 Quantitativley Managed
    • QPM - Quantitative Project Management
    • OPP - Organizational Process Performance
  • Level 5 Optimizing
    • CAR - Causal Analysis and Resolution
    • OID - Organizational Innovation and Deployment

Las siguientes son las goals genericas con sus practices para cada nivel:

  • GG 2 Institutionalize a Managed Process
    • GP 2.1 Establish an Organizational Policy
    • GP 2.2 Plan the Process
    • GP 2.3 Provide Resources
    • GP 2.4 Assign Responsibility
    • GP 2.5 Train People
    • GP 2.6 Manage Configurations
    • GP 2.7 Identify and Involve Relevant Stakeholders
    • GP 2.8 Monitor and Control the Process
    • GP 2.9 Objectively Evaluate Adherence
    • GP 2.10 Review Status with Higher Level Management
  • GG 3 Institutionalize a Defined Process
    • GP 3.1 Establish a Defined Process
    • GP 3.2 Collect Improvement Information
  • GG 4 Institutionalize a Quantitatively Managed Process
    • GP 4.1 Establish Quantitative Objectives for the Process
    • GP 4.2 Stabilise Subprocess Performance
  • GG 5 Institutionalize an Optimizing Process
    • GP 5.1 Ensure Continuous Process Improvement
    • GP 5.2 Correct Root Causes of Problems

El nivel de CMMI de una empresa se mide mediante un SCAMPI, Standard CMMI Appraisal Method for Process Improvement. Tambien puede hacerse un mini assessment aunque los resultados son solo orientativos y no reconocidos. El SCAMPI se basa en entrevistas, revision de documentacion, findings y mapeo contra CMMI. Comprende actividades pre y on site, y luego un reporte de resultados finales.

El SCAMPI puede ser con foco en institucionalizacion, completo a nivel organizacion (de tipo A) otorgando un nivel de madurez, con foco en deployment previo a la implementacion de los procesos en si (de tipo B) o con foco en approach (de tipo C) evaluando rapidamente areas de riesgo.

Alta Madurez[editar]

Se corresponde con los dos ultimos niveles de CMMI, organizaciones que monitorean sus procesos de manera ordenada mediante metricas. Se espera poder predecir resultados a partir de mediciones pasadas. La administracion de procesos es un loop de definir, ejecutar, medir y mejorar; a esto se agregan las metricas.

Se definen los siguientes conceptos:

  • Performance: resultados respecto de atributos medibles (calidad, cantidad, tiempo, costo)
  • Capacidad: cuan capaz es un proceso, cual es el rango en el que se encuentran los atributos de los productos generados
  • Control cuantitativo: condicion de un proceso cuyas mediciones estan dentro de ciertos limites de control
  • Control estadistico: idem anterior pero aplicando tecnicas estadisticas
  • Estabilidad: predictibilidad, se mide respecto de un atributo, implica tener el proceso bajo control

A la hora de medir, se debe tener en cuenta tambien la variacion (sigma). La variacion depende de causas comunes o especiales, en soft son dificiles de distinguir.

En el nivel 4 se comprende y se administra la variación en el proceso para poder alcanzar objetivos de calidad. En el nivel 5, se realizan mejoras tecnológicamente innovadoras, así como mejoras incrementales; se las elige y las implementa usando conocimiento obtenido de la gestión cuantitativa y habilidades de gestión del cambio organizacional; los focos son pasar de la deteccion a la prevencion de defectos y mejorar continuamente a partir de las mediciones.

Metricas[editar]

Una medicion es una cantidad o proporcion asignada a una entidad, una metrica es una medida cuantitativa sobre si un elemento posee una determinada caracteristica.

El paradigma de GQM consiste en el planteo de goals, que se traducen a preguntas, las cuales se responden o evaluan mediante el uso de distintas metricas. Los objetivos pueden ser definidos desde distintas perspectivas (organizacion, cliente, proyecto, etc).

Algunos ejemplos de metricas son:

  • Running Tested Features, funcionalidades entregadas y funcionando, vinculadas a metodologias agiles con entregas tempranas y continuas.
  • Earned bussiness value, valor de negocio acumulado de funcionalidades entregadas y aceptadas, usable con alcance conocido
  • Velocity, sea de equipo o de developer
  • Burndowns

Plan de Metricas[editar]

A usarse en empresas de alta madurez. Ejemplo:

  • Calidad (esfuerzo)
    • Costo de la calidad
    • Costo de la calidad pobre
  • Revisiones por pares
    • Cantidad de revisiones
    • Eficiencia de las Revisiones
    • Defectos críticos o moderados encontrados
  • SQA
    • Cantidad de Revisiones de SQA por Mes
    • Cantidad de Issues de SQA por mes
    • Cantidad de Issues por revisión de SQA
  • Esfuerzo y progreso
    • Retraso por proyecto según valor acumulado
    • Esfuerzo estimado vs. incurrido
  • Bugs
    • Tiempos entre estados del ciclo de vida

Software Configuration Management[editar]

Manejo de cambios en el software, durante y despues del desarrollo.

  • Artifact: A work product that is placed under configuration management and treated as a single entity
  • Baseline: A document or a set of such documents formally designated and fixed at a specific time during the lifecycle of a configuration item.
  • Variant: A version that is an alternative of another version. For example, variants allow a configuration item to meet conflicting requirements.
  • Version: An instance of a configuration item. Once a version is baselined it cannot be changed without creating a new version.
  • Release: A configuration management action whereby a particular version of software is made available for a specific purpose.
  • Revision: A version that supersedes an earlier version, typically, to correct errors as opposed to a version that is an alternative version.

Las siguientes son las actividades principales de config management, estas se replican por producto y entorno (produccion vs desarrollo).

  • Configuration Identification: Identificar y almacenar artifacts en un repositorio.
  • Configuration Change Control: Controlar y auditar cambios sobre artifacts, puede evaluar y aprobar o desaprobar cambios. Auditoria de cambios, inicialmente preponderante sobre el change control, luego deja lugar a este. CM inicialmente solo audita, despues empieza a evaluar.
  • Crear baselines para cada milestone, para permitir reproducibility, traceability y reporting.
  • Registro y seguimiento de change requests.
  • Integracion de changesets mediante actividades, las cuales se vinculan inmediatamente con los change requests, el area de PM y la forma de trabajo de desarrollo.
  • Mantener espacios de trabajo consistentes y estables.
  • Soportar cambios concurrentes. Puede usarse turn-taking, split-combine o copy-merge.
  • Integracion temprana y eficiente entre los distintos componentes.
  • Asegurar reproducibility de releases.

Change Request Management[editar]

Almacenamiento, seguimiento y reporting de pedidos de cambio de cualquier stakeholder del sistema. Requiere origen e impacto del problema, solucion propuesta y evaluacion del costo. Un cambio puede ser un enhancement o un defect.

Las etapas en CRM son:

  • Submitted: Alguien llena un change request.
  • Evaluated: Es evaluado, categorizado, priorizado, etc.
  • Revised: Llega a esta etapa tras un proceso de decision, en el que estan involucrados stakeholders, developers y users (CCB)
  • In Process
  • Verified: Se verifica el cambio contra el change request.
  • Complete


Seguimiento de Proyectos[editar]

Para definir un cronograma es importante la division, determinacion de dependencias, asignacion y estimacion de tareas. Se deben programar salidas e hitos para cada producto.

El objetivo del seguimiento es proveer de info a los responsables sobre el progreso del proyecto para poder tomar acciones correctivas de ser necesarias. Cubre avance, esfuerzo y calidad. Se hace mediante el analisis de action items. El seguimiento tambien cubre impediments, riesgos, actividades de calidad y el cumplimiento del proceso.

El avance se mide usando el valor acumulado. Cada tarea o producto se multiplica por un factor de esfuerzo o costo, su avance puede determinarse segun los hitos entregados o la etapa en la que se encuentra (analisis, disenio, programacion, test). La etapa de SQA tambien puede usarse. Para mas detalle, WBS hibrido de productos y procesos.

Deben hacerse reuniones de seguimiento, que pueden complementarse con reportes de avance. Puede ser con el cliente o interna del equipo (ej daily standups).

El seguimiento deviene en el control de proyectos, la toma de medidas correctivas ante un desvio en el plan. Deben evitarse medidas correctivas como aumento constante de esfuerzo por parte del equipo, eliminar tareas de calidad, dejar la integracion muy para el final, etc.


ATAM[editar]

Se divide en 4 fases distintas, cada una de las fases de evaluacion comprende distintas etapas.

  • Fase cero de preparación, en la que los evaluators se juntan con los key decision makers para obtener la información inicial de requerimientos, visión y documentación de la arquitectura, para llegar preparados a las evaluations.
  • Fase uno de evaluación, entre evaluators y todos los project decision makers, conlleva de las etapas 1 a 6.
  • Segunda fase de evaluación, unas dos semanas posterior a la anterior, en la que se adicionan los stakeholders (ej users, developers, maintainers) al proceso; se recapitula la evaluación anterior y realizan los pasos 7 a 9.
  • Ultima fase de follow up.

Etapas de evaluacion:

  1. Presentacion de ATAM
  2. Presentacion de bussiness drivers
  3. Presentacion de la arquitectura
  4. Identificacion de architecture approaches
  5. Quality attribute utility tree
  6. Analisis de los architectural approaches
  7. Brainstorming y priorizacion de scenarios
  8. Analisis de los architectural approaches
  9. Presentacion de resultados final en slides


Software Quality Assurance[editar]

Calidad puede definirse como el grado en que el producto se adapta a los requerimientos y necesidades del cliente. SQA es el conjunto de tareas realizadas con el objetivo de evaluar la ejecucion de procesos, identificar y proveer visibilidad de desviaciones respecto de los mismos, y asegurar que estas sean tratadas. Tiende a implementarse usando checklists (genericos y especificos). Es importante la objetividad.

En CMMI aparece en level 2: evaluate processes and work products, provide insight (objectively!).

Las funciones de SQA cubren:

  • Definir las practicas de calidad
  • Evaluar planes, requerimientos, disenio, practicas, procesos
  • Adaptacion de controles de los procesos

Se define validacion como el chequeo de que el producto sea correcto respecto de los requerimientos, y verificacion como el chequeo de la correctitud de los procesos; estan en nivel 3 de CMMI.

Las revisiones por pares pueden ayudar en la calidad. Se tienen:

  • Walkthroughs: reunion en la que un presentador exhibe un artefacto a un grupo de especialistas que dan sus opiniones sobre la resolucion.
  • Revisiones: mas informales.
  • Inspecciones de codigo: reuniones que implican revisores, autor, lector, registrador y moderador; requiere una preparacion por parte de los revisores; conviene hacerla luego de una prueba basica.

Agiles[editar]

Extreme Programming[editar]

Los valores de extreme programming son:

  • Comunicacion: entre usuarios y equipo, se fomenta lo verbal y no la documentacion extensa
  • Simplicidad: KISS (keep it simple stupid) YAGNI (you aint gonna need it), no hay forma de saber cuales pueden ser todos los cambios posteriores
  • Feedback: del sistema (mediante tests), de los usuarios, del equipo, etc; se fomenta la transparencia
  • Coraje: refactoring cuando es necesario, no code ownership
  • Respeto: entre programadores, al producto, al usuario, etc

Las 12 reglas propuestas son:

  1. Planning game
  2. Test Driven Development
  3. Pair programming
  4. Iteraciones cortas
  5. Integración continua
  6. Refactoring (mejorar los diseños)
  7. Respetar estándares
  8. Todos somos dueños
  9. Somos un gran equipo (inclusion del usuario)
  10. Diseños simples (prototipos, dejar optimizacion para el final)
  11. Metáfora del sistema (nombres simples y consistentes para clases y metodos)
  12. No trabajar más de 40hs semanales


Scrum[editar]

Scrum es un framework de desarrollo agil. La especificacion en Scrum se realiza mediante Epics (grupos de funcionalidad, casos de uso de muy alto nivel) los cuales se refinan en user stories (de la forma As a user Z, I want X so that I can Y) los cuales tambien tienen acceptance cases asociados (representan las expectativas de los clientes, conceptuales, de forma "el usuario Z puede realizar una accion X y obtener el resultado esperado Y").

Los user stories se mapean a items del backlog, los cuales pasan a ser sprint items sobre los cuales se hace el task breakdown.