conceptos y fundamentos acerca de procesos de desarrollo · conceptos y fundamentos acerca de...

Conceptos y Fundamentos

acerca de Procesos de Desarrollo

Prof. Gustavo J. Sabio

Calidad de Software – 4to año

Licenciatura en Sistemas de Información

Universidad de Congreso

(c) 2006, Mendoza, Argentina

Introducción a Procesos de Desarrollo de Software 2© 2006, Prof. Gustavo J. Sabio

ContenidoContenido

Características de una organización inmadura

Aspectos esenciales para desarrollar software

Características de una organización madura


Mapa de contenidos

Proceso OptimizadoProceso Optimizado

Aspectos esenciales Aspectos esenciales para desarrollar para desarrollar softwaresoftware

Proceso informal Proceso informal o indefinidoo indefinido


Algunos conceptos fundamentales

Conjunto de actividades que interactúan o se relacionan para

transformar las entradas de clientes en salidas con un valor

agregado.

� actividades aisladas

� aplicación aleatoria

� áreas independientes

� fusionadas sistemáticamente para un fin

� relacionadas y organizadas

� se complementan para objetivo común

¿Qué es un proceso?


Otras Definiciones de Proceso

� Una secuencia de pasos llevados a cabo para un

propósito dado (IEEE)

� la organización lógica de personas, materiales, energía,

equipamientos, y procedimientos dentro las actividades

diseñadas para producir un resultado final específico

(Pall, Gabriel A. Quality Process Management.

Englewood Cliffs, N.J.: Prentice-Hall, 1987.)

� Actividades que pueden ser reconocidas como la

implementación de prácticas en un modelo (Glosario

CMMI)


Algunos conceptos fundamentales

Proceso de desarrollo de software

Cliente

� Las necesidades del cliente son transformadas en un

producto software

entradas Proceso de desarrollo salida

necesidades actividades varias Producto softwareCliente

equiposistemas

AnAnáálisis y Dise

lisis y Diseññoo

Construcci

Construccióónn

Prueba e integraci

Prueba e integracióónn

Despliegue y entrega

Despliegue y entrega

Ciclo de vida del desarrollo de software

Modelado de Negocio

Modelado de Negocio

y Requerimientos

y Requerimientos


Construcción de SW – Panorama mundial

� El mundo tecnológico invade todos los ámbitos.

� Los sistemas software son cada vez más:

� Grandes – Complejos - Distribuidos.

� La demanda del mercado es:

software de mejor calidad en menor tiempo!

• Se torna sumamente difícil construir

y mantener software de buena calidad

de manera predecible.


Organización inmadura

� Algunas causas:

�Manejo de requerimientos ad hoc.

� Arquitecturas frágiles.

� Inconsistencias entre los requerimientos, el diseño y la

implementación.

� Prueba insuficiente.

� Valoración subjetiva del estado del proyecto.

� No se atacan oportunamente los riesgos.

� Propagación de cambios no controlada.


Procesos Inmaduros

� Los procesos son ad hoc e improvisados por los recursos y sus jefes

� Los procesos descriptos no son rigurosamente seguidos o

implementados

� La performance es altamente dependiente de los recursos humanos

actuales

� El conocimiento del estado actual de un proyecto es limitado

� El resultado de los procesos inmaduros es apagar el incendio:

� No hay tiempo para mejorar – son constantemente reactivos

� Los bomberos terminan quemados

� El incendio puede volver


Organización inmadura - Características

Dificultades para

cumplir con los

compromisos



Mucho tiempo atendiendo lo

urgente y no lo importante



Las prioridades son

establecidas por la crisis



Algunas veces se cumple con los tiempos!

Muchas veces por

esfuerzos individuales

más que por mérito de la

organización



El cliente suele tolerar

mientras no hay otra

alternativa



El estímulo por

incorporar mejoras al

proceso, proviene de

personas que no realizan

las tareas operativas del

día a día



La idea de dedicar tiempo

para la mejora, se

traduce en menos

tiempo para “sacar” el

trabajo del día a día


El caos produce más caos

� Ante la presión política es difícil decir que no se sabe.

� Bajo presión se asumen compromisos no planeados

� Se carece de pasos claros para cumplir con los compromisos

� El tamaño del proyecto, a lo largo de su vida, sigue creciendo

� Nos sorprendemos cuando las cosas fallan (“magia”)


Dimensiones de un desarrollo efectivo

Personas

Proceso Producto

Tecnología

Trabajan rápida o lentamenteSe destacan en lo que hacen o no

Supone una mejora en las actividades de las personas o burocratiza la situación

Está definido de tal manera que se construye casi solo o pone trabas a los mejores esfuerzos de quienes lo construyen

Ayuda al esfuerzo del desarrollo u obstaculiza los mejores intentos de los desarrolladores

Se deberían potenciar entre cada una de ellas


PROYECTOPROYECTO

PROCESOPROCESO

PERSONASPERSONAS

TECNOLOGTECNOLOGÍÍAA

PRODUCTOPRODUCTO

....participantes...

....plantilla...

....resultado...

....automatización...

¿Qué comprende el desarrollo de software?

Relación entre las dimensiones


Errores clásicos

� ¿Qué es un error clásico?

� Hay que salvar un proyecto retrasado…

� Hay que acortar el plan…

� Algunos de los miembros claves incomoda al equipo…

� Debemos acelerar para terminar…

� Etc…

Analogía con “La Isla de Gilligan”


La importancia de las personas

• Motivación débil

• Personal no capacitado

• Personal problemático incontrolado

• Creer en hazañas

• Agregar personal a un proyecto retrasado

• Fricciones entre clientes y desarrolladores

• Expectativas poco realistas

• Falta de participación del usuario

Errores Errores clcláásicossicos


La importancia del proceso

• Planificación excesivamente optimista

• Gestión de riesgos insuficiente

• Pobre comunicación con mis proveedores

• Planificación insuficiente

• Abandono de los planes bajo presión

• Diseño inadecuado

• Escatimar en el control de calidad

• Falta de supervisión de quién dirige

• Omitir tareas necesarias para la estimación

• Programación a destajo



La importancia del producto

• Exceso de requerimientos

• Cambio de funcionalidad

• Desarrolladores meticulosos

• Desarrollo orientado a la investigación



La importancia de la Tecnología

• Síndrome de la panacea

• Sobre estimación de las ventajas de usar nuevas

herramientas o métodos

• Cambiar de herramienta a mitad de proyecto

• Falta de control de versiones del código fuente



¿En dónde estamos?





Comenzar a neutralizar el caos

� Analogía de la orquesta sin director

Reconocer que necesitamos mejorar!

Evitar cometer errores clásicos

Contar con “bases” para el desarrollo

Controlar los riesgos

Dirigir mediante un PLAN de desarrollo


Ciclo PECA – Mejora Contínua

PlanificarPlanificarActuarActuar

EjecutarEjecutarControlarControlar

•¿qué hacer?•¿cómo hacerlo?

•Hacer lo planificado

•¿cómo mejorar la Próxima vez?

•Verificar si sucediósegún lo planificado

ciclo de Demingciclo de Deming


Contrarestar la fuerza del Caos

• Aplicar una gestigestióón de proyectos bn de proyectos báásicasica, mediante el concepto PECA

El trabajo debe ser estimado y planeado

Se debe dirigir su ejecución

Medir y controlar según el plan

Aprendiendo de los errores cometidos


Desarrollar Software

¿Cómo lograr el equilibrio delicado entre entregar

el software de calidad y entregarlo rápidamente?

(la paradoja del software!)


Respuesta !

� Entender que existen aspectos esenciales del proceso

que no se pueden soslayar.

� Buscar adherir a la cultura organizacional las

mejores prácticas que han sido probadas por la

industria y ayudan ha alcanzar el éxito a los proyectos

de desarrollo de software.

� Lograr la Adaptación del proceso para que encaje

mejor con las necesidades específicas de “su” proyecto

y organización

esenciales del proceso

mejores prácticas

Adaptación del proceso


Aspectos esenciales del proceso

Visión —Desarrollar una Vision

Plan —Administrar un Plan de desarrollo

Riesgos— Identificar riesgos y saber como mitigarlos

Modelo de Negocio— Examinar el negocio

Arquitectura—Diseñar Arquitetura de componentes

Incremental—Construir y Probar, incrementalemente, el producto

Medicíón—Valorizar regularmente los resultados

Administrar el Cambio—Administrar y Controlar los cambios

Soporte al Usuario—Brindar soporte al usuario

Responsable—Asignar y controlar los pendientes


Proceso: Visión

Desarrollar una Visión

� ¿Cuáles son los términos claves?

� ¿Cuál es el problema que se intenta resolver?

� ¿Quiénes son los involucrados? ¿quiénes son usuarios? ¿cuáles son sus necesidades?

� ¿Cuáles son las características del producto?

� ¿Cuáles son los requerimientos funcionales?

� ¿Cuáles son los requerimientos no-funcionales?

� ¿Cuáles son las restricciones de diseño?


Proceso: Plan

Administrar un Plan de Desarrollo

“El producto es tan bueno como lo sea el plan para elaborarlo”

� Carta gantt (actividad, recursos, responsable, entregable,

plazos).

� Organización del proyecto

� Plan de administración de requerimientos

� Plan de administración de configuraciones

� Plan de resolución de problemas

� Plan de QA

� Plan de Test

� Plan de aceptación de producto.

� Su formato no interesa: “ el plan no es nada, la planificación es

todo”


10 tips esenciales del proceso

Identificar y mitigar los Riesgos

� Identificación temprana dentro del

proyecto

� Riesgo identificado -> Mitigación

definida

� La lista de riesgos se convierte en una

herramienta que ayuda a planificar las

actividades del proyecto

� Es un elemento esencial para

especificar las iteraciones en un

desarrollo iterativo e incremental



Asignación y seguimiento de pendientes

� Valorizar regularmente el estado del

proyecto como mecanismo para la

identificación, comunicación y

resolución de problemas.

� Problemas en el gerenciamiento del

proyecto, problemas técnicos, otros.

� Registrarlos y hacer su seguimiento.

� Quitarlos cuanto antes del camino !



Conocer el modelo de Negocio

� Nos permite conocer mejor el funcionamiento del negocio

� Se logra profundidad en la definición del problema

� Es entendido por todos los involucrados

� Brinda información para la toma de

desiciones



Definir una arquitectura de componentes

� Contar qué componentes

conforman el sistema y cómo

éstos interactúan entre ellos

a través de interfaces

� ¿Cuáles son las principales

“piezas” del sistema?

� Se representa por múltiples

vistas destinadas a: usuarios

finales, diseñadores,

administradores, y otros.



Construir y probar incrementalmente el producto

� En la fases tempranas sirve como prototipo de

funcionalidades e interfaz

� Durante las otras etapas del desarrollo se van

integrando en versiones ejecutables

� Tanto la contrucción como la prueba van creciendo

en complejidad.

� Se incrementa hasta obtener la versión final



Valorizar regularmente los resultados

� Lo que no medimos no lo podemos controlar

� Se identifican y contemplan lecciones aprendidas

� Simple o compleja… Lo importantes es realizarla!

� Encontrar problemas en el proceso y en el

producto.

� Aplicar acciones correctivas y preventivas



Administrar y controlar los cambios

� Se debe tener control sobre el alcance del proyecto

� Apuntar a que no queden requerimientos en el tintero

� Asumir que se solicitarán cambios durante la vida del proyecto.

� Contar con un procedimiento que los contenga

� Poder medir el impacto de un cambio



Brindar Soporte al Usuario

� El producto software es más que el código

� El producto se acompaña de documentación de

utilidad para el usuario

� Como mínimo: Manual de usuario, manual de

sistemas, manual de instalación y configuración.

� Además: manual de capacitación, ayuda en línea,

instructivos específicos, instructivos paso a paso

preguntas frecuentes, otros.



¿Es aplicable a todo tipo de proyecto?

� Proyecto pequeños

� Alcanza con implementar los 10 puntos esenciales.

� No es necesario utilizar herramientas automatizadas.

� Proyectos mayores

� Considerar los 10 tips más las “mejores prácticas”

� Ir agregando las herramientas que sean necesarias

� Equipos maduros

� Guía para evaluar los aspectos esenciales

� Priorizar el foco de la mejora


¿Se puede ignorar algún tip?

� ¿Ninguna visión?

� ¿Ningún plan?

� ¿Ninguna lista de riesgo?

� ¿ninguna lista de pendientes?

� ¿Ningún modelo de Negocio?

� ¿Ninguna arquitectura?

� ¿Ningún producto hasta el final?

� ¿Ninguna medición?

� ¿Ningún Requerimiento de Cambio?

� ¿Ningún soporte para el usuario?

¿Por qué considerarlos a todos?


¿Otros Esenciales?

� IEEE Software Magazine, Abril 1997, incluyendo un

artículo de Steve McConnell, "Software's Ten

Essentials." The Software Project

� Manager's Network define un listado de "16 Critical

Software Practices," disponible en www.spmn.comwww.spmn.com

� El Capability Maturity Model (CMM) del SEI, define las

Key Process Areas (KPAs) consideradas como

“esenciales" www.sei.cmu.eduwww.sei.cmu.edu


SPMN: 16 prácticas esenciales

www.spmn.com/16CSP.htmlwww.spmn.com/16CSP.html


¿ y la NASA ?

Existen las 100 reglas para los administradores de proyectos

de software

One Hundred Rules for NASA

Project Managers


Respuesta !

Esenciales del proceso

Mejores prácticas

Adaptación del proceso


Mejores Prácticas

Desarrollo IterativoDesarrollo Iterativo

AdministraciAdministracióón de Requisitosn de Requisitos

Arquitectura basada en componentesArquitectura basada en componentes

Modelado Visual Modelado Visual -- UMLUML

Aseguramiento de la CalidadAseguramiento de la Calidad

AdministraciAdministracióón del Cambion del Cambio


Cada vuelta es una iteración

de cada Iteración resulta una versión ejecutable


Mejores prácticas


Riesgos en el modelo iterativo vs el modelo cascada

Mejores prácticas



Requerimientos de SoftwareRequerimientos de Software

Mejores prácticas

caractercaracteríísticassticas

NecesidadesNecesidades

Procedimientos de Procedimientos de TestTest

DiseDiseññoo

Documentos para usuarioDocumentos para usuario

problema

El El sistema a sistema a construirconstruir



¿En qué consiste la AR?

• Analizar el problema

• Entender las necesidades

• Definir el sistema

• Administrar el Cambio

• Redefinir el sistema

• Administrar el cambio en los requerimientos


Mejores prácticas



¿Qué es un componente arquitectónico?

Porciones de código (fuente o ejecutable) con interfaces y comportamiento bien definidos que proveen una fuerte encapsulación de sus contenidos, siendo, por lo tanto,

reutilizables

¿Para qué sirve?

La arquitectura basada en componentes tiende a reducir considerablemente el tamaño y complejidad de la solución,

haciéndola mas robusta.

Mejores prácticas


Propósito:

Base para la reutilizaciónComponentes reutilizablesArquitectura reutilizable

Base para la Administración de ProyectosPlanificaciónRRHHEntregas

Control IntelectualAdministrar complejidadAdministrar integridad

11


Mejores prácticas


Modelado Visual Modelado Visual

Un modelo es:

Una simplificación de la realidad…

que provee una descripción acabada de un sistema…

desde una perspectiva particular…

¿Para qué construimos modelos?

Para entender mejor el sistema que estamos modelando

(ocultando los detalles innecesarios)

Mejores prácticas


DiagramaDiagrama

actividadactividad

Diagrama Diagrama

EstadosEstados

DiagramaDiagrama

ColaboraciColaboracióónn

DiagramaDiagrama

DespliegueDespliegue

DiagramaDiagrama

ObjetosObjetos

Diagrama Diagrama

ComponentesComponentes

DiagramaDiagrama

de Clasesde Clases

DiagramaDiagrama

Casos de UsoCasos de UsoDiagramaDiagrama

secuenciasecuencia

Modelos

Modelado Visual Modelado Visual

Mejores prácticas



“cuanto antes se descubran los errores, mas barato será su corrección”

Los problemas en el software son de 1 a 100 veces mas costosos para Encontrarlos y repararlos después del deployment

Mejores prácticas


Testeo para distintas dimensiones de la Calidad

Funcionalidad

Verificando el correcto funcionamiento de los escenariosUsabilidad

Desde la perspectiva del usuario finalConfiabilidad

Verifica un comportamiento consistente y predeciblesRendimiento

Se verifica la respuesta ante la cargaMantenimiento

La habilidad de mantenimiento al ponerlo en producción


Mejores prácticas



“Hay un dicho que oigo en cada proyecto problemático con que me he encontrado. Los desarrolladores vienen y me dicen:

"el problema con este proyecto es que los requisitos cambian todo el tiempo".

Lo que yo encuentro sorprendente sobre esta situación es que sorprenda a cualquiera. En el negocio de construcción de

software los cambios en los requisitos son la norma, la preguntaes:

¿qué hacemos al respecto?. ”Martin Fowler

Mejores prácticas


Los requerimientos deben estar perfectamente documentados, en unúnico repositorio y con aprobación centralizada

Nuevas prestaciones

Nuevos requerimientos

Cambio en los requerimientos

Errores de código

Resultados de pruebas

Propuestas de los programadores


Mejores prácticas


Algunas características de Procesos maduros

� Todos los procesos se encuentran acordados, definidos,

documentados y bajo mejora continua .

� El trabajo que se realiza a diario, dirige la descripción de los

procesos y no en sentido contrario.

� Existen controles sobre los procesos y responsables bien definidos

� Existe institucionalización de los procesos:

� La Dirección de la organización está comprometida con los procesos,

avalándolos y apoyando su institucionalización.

� Se escucha la frase: “Es nuestra manera de hacerlo”

� La alta Dirección y la gerencia impulsan y promueven esta cultura

� La organización brinda un marco de infraestructura que permite

soportar procesos efectivos.

� La filosofía de trabajo es reconocida y respetada por todos, existen

roles y responsabilidades claramente definidos.


¿ Por qué insistir con ser una empresa madura ?

• Evitar retrabajo

• Lograr cronogramas efectivos

• Capacidad para predecir costos

• Asegurarle la Calidad a nuestros clientes

• Promover la reutilización

• Transitar un proceso bajo control

• Evitar pérdidas de dinero






……ContinuarContinuar con la con la

presentacipresentacióón de n de

IntroducciIntroduccióón a n a CMMiCMMi

conceptos y fundamentos acerca de procesos de desarrollo · conceptos y fundamentos acerca de...

Documents