Presentación de PowerPoint · - Análisis de productividad en proyectos de software El libro más...

© FATTO Consultoria e Sistemas - www.fattocs.com

• Si es necesario, ajuste el idioma de la sala virtual en la barra de herramientas en la parte superior

• El evento tendrá 45 min. de presentación y 15 min. al final para preguntas

• Usted podrá mandar sus preguntas por el chat a lo largo de la presentación y serán respondidas al final de la presentación

• La presentación será grabada y la grabación y las diapositivas serán publicadas

• Para aquellos que poseen certificación PMP, el evento vale 1 PDU

• Acompáñenos en las redes sociales

Orientaciones Iniciales


FATTO Consultoría y Sistemas

2

Misión: “Ayudar nuestros clientes a planificar y controlar mejor sus proyectos de software.” Consultoría y Entrenamiento en Medición, Estimación y Requisitos de Software: - Análisis de Puntos de Función (IFPUG, NESMA , COSMIC) - Estimaciones de proyectos de software - Ingeniería de Requisitos - Medición y auditoría en medición de software - Análisis de productividad en proyectos de software

El libro más vendido de FPA en Brasil fue escrito por nosotros Formó 25% de expertos certificados (CFPS) en Brasil Representantes del Scope Proyect Sizing Software

- Aumenta su nivel de gobierno en las mediciones funcionales y en la gestión de activos de software.


Preparación para el

Examen CFPS 96 horas (EAD y presencial)

Servicios Educativos de la FATTO

FPA: Fundamentos,

Beneficios e Implantación 8 horas (EAD y presencial)

Capacitación en FPA:

Medición y Estimación de Software

16 horas (EAD y presencial)

Workshop FPA:

Metodología y Práticas de Medición

16 horas (presencial)

Ingeniería de Requisitos

de Software 24 horas

Estimación de Proyectos

de Software con COCOMOII 16 horas

Taller de Medición de

Puntos de Función Sesiones de 8 ~ 40 horas

Medición y Estimación de

Software con el Método COSMIC 16 horas

(presencial)


4

Retos y soluciones de trabajar con Requerimientos de Software

Nelson Camilo Orduz Illidge

[email protected]


Qué es la Ingeniería de Requerimientos

Importancia de la Ingeniería de Requerimientos

¿Qué es requerimiento de software?

Retos: Comunicación, Acceso a los interesados, Usuarios que no

saben lo que desean, Requerimientos implícitos, Cambios,

Conflictos, Participación del interesado, Resistencia al cambio,

Usuarios que no dominan su negocio, Clientes que no leen la

especificación de requerimientos

Conclusión

Agenda

5


La disciplina de la Ingeniería de Software que consiste en

un uso sistemático y repetitivo de técnicas que abarcan las

actividades de identificación, documentación y

mantenimiento de un conjunto de requerimientos para

el software, con el fin de que éstos cumplan con los

objetivos de negocio y sean de calidad*

Ingeniería de Requerimientos

6

*https://www.youtube.com/watch?t=682&v=2WMndeLi2kQ


• 47% de los fracasos en proyectos se deben a la

gestión deficiente de los requerimientos

• 20% de los defectos tienen su origen en

requerimientos

• Encontrar y corregir defectos en el software después de

entregado es >100 x más costoso que hacerlo durante

el trabajo de requerimientos

Importancia de la Ingeniería de Requerimientos

7

*PMI’s Pulse of the Profession: Requirements Management

A Core Competency for Project and Program Success - 2014

**Software Defects Origins and Removal Methods Capers

Jones - 2014

***Software Defect Reduction – Top 10 List Barry

Boehm y Victor Basili - 2001


(1) Condición o capacidad que un usuario

necesita para resolver un problema o lograr

un objetivo

(2) Condición o capacidad que debe cumplir

o poseer un sistema o uno de sus

componentes para satisfacer un contrato,

estándar, especificación u otra documentación

formalmente impuesta

(3) Representación documentada de una

condición o capacidad como en (1) o (2)

¿Qué es requerimiento de software?

8

deseo (proyecto)

producto

documentación

IEEE Standard Glossary of Software

Engineering Terminology (IEEE 610) especificación


9

Reto: Comunicación

Como lo describió el

consultor de negocios

Lo que el cliente realmente

necesitaba

Como lo desarrolló el

programador Como lo diseñó el analista Como lo entendió el líder de

proyecto

El soporte que se le dió Lo que se cobró al cliente Las funcionalidades que

fueran entregadas

Como se documentó el

proyecto

Como lo explicó el cliente

www.projectcartoon.com


• Proporcionar información sin subjetividad o

ambigüedad: Los requerimientos se expresan a menudo

en lenguaje natural, lo que facilita la comprensión, pero

da lugar a varias interpretaciones

• Falla en la interpretación del mensaje entre el analista

de requerimientos y interesados. La propagación

errónea de los requerimientos para los otros miembros

del equipo involucrados en el proyecto

Reto: Comunicación

10


• Desarrollar sus habilidades de comunicación: escrita,

verbal e interpersonal

Comunicación - Solución

11


12

Reto: Acceso a los interesados


• No siempre está al alcance del analista seleccionar

las personas con quien levantar requerimientos

• A veces un intermediario es seleccionado para

desempeñar el rol de un interesado. Esto es común

cuando el interesado es externo a la organización

(cliente, proveedor, aliado, etc)

• Esto significa un riesgo considerable de que la

información recolectada no sea la más adecuada

Reto: Acceso a los interesados

13


• Si la dificultad es la falta de autoridad para elegir los

interesados, involucrar al director de proyectos es

fundamental para una solución

• Otra alternativa es buscar personas adicionales que

también puedan tener la información deseada, u otras

fuentes de información, por ejemplo: documentación

existente, observación

Acceso a los interesados - Solución

14


15

Reto: Usuarios que no saben lo que desean


• Esta dificultad varia desde aquellos que no saben decir

lo que quieren, hasta aquellos que dicen la necesidad

incorrecta. Y ésto es un escenario muy frecuente

• ¿Qué hacer? ¿Cambiar los usuarios?

Reto: Usuarios que no saben lo que desean

16


• El gran valor del trabajo de requerimientos es

comprender correctamente las necesidades, aunque

el usuario no sepa decir con claridad lo que desea. El

trabajo debe ser proactivo, no pasivo

• Los métodos a aplicar deben ser bien evaluados. Lo

que funciona bien para algunos no funciona para

todos. Prototipos y observación son efectivos para

traer información de quién no sabe expresarse

Usuarios que no saben lo que desean - Solución

17


• O los requerimientos “obvios”, pero no explícitos

• El analista escucha a los interesados, documenta sus

necesidades, diseña una solución, valida la misma con

éstos y obtiene aprobación. El producto es desarrollado

y en la entrega varias necesidades no mencionadas

antes son presentadas

• ¿Quién falló?

• ¿Los interesados? ¿El analista?

Reto: Requerimientos implícitos

18

A B C

Correcto Especificado


• Creer que el trabajo de requerimientos está restricto al

explícito no es realista

• No hay método o herramienta que garantice que la

especificación sea completa. Todavía hay como

minimizar:

Profundizar conocimiento en el negocio

Observación

Prototipos

Requerimientos implícitos - Solución

19


"(...) requerimientos cambian a

un ritmo de 2% por mes (...)" -

Capers Jones en “Software

Engineering: The State of the

Art in 2008”.

Reto: Cambios

20


• Cambios generan trabajo adicional. Todavía, no todos

significan problema. Hay muchos cambios que

aumentan el valor del proyecto

• Un trabajo de requerimientos pasivo, casi siempre

resulta en muchos cambios innecesarios después

(para corregir el alcance). Posición proactiva es clave

• Elaborar una especificación modificable

Cambios - Solución

21


Conflictos aumentan en proporción

de la cantidad de interesados. Ej.:

Solicitudes de distintos interesados que

no se pueden cumplir simultáneamente

Datos no consistentes del proceso de negocio

Solicitudes fuera del alcance del proyecto

Interesados enemigos entre sí

Falta de sintonía entre las áreas de negocio

Reto: Conflictos

22


• Solucionar conflictos es una responsabilidad más

directa del director de proyectos que del analista

• Sin embargo, desarrollar habilidades de

relacionamiento interpersonal es clave para el éxito del

trabajo del analista de requerimientos

→ A veces, hay que ser un poco psicólogo,

diplomático y político

Conflictos - Solución

23


• “No tengo tiempo.”

• ¿Cuál es el rol del interesado?

- ¿Cliente directo?

- ¿Cliente indirecto?

- ¿Externo a la organización?

Reto: Participación del interesado

24


• “Los responsables de negocio y los desarrolladores deben

trabajar juntos de forma cotidiana durante todo el proyecto.” –

Cuarto Principio del Manifiesto Ágil

• Promover cultura de participación

• Ayuda de alguien con más autoridad

• Enfocar métodos de levantamiento que necesiten de menos

tiempo del interesado: observación, análisis de documentación,

cuestionarios

• Buscar otra persona con más interés y disponibilidad

Participación del interesado - Solución

25


• Las novedades casi

siempre generan miedo

• Mantener su zona de

confort es la reacción

natural de la mayoría

Reto: Resistencia al cambio

26


• ¿Cuál es la motivación para la resistencia?

- ¿Perjudica los intereses de alguien?

Obtener medios alternativos para la búsqueda de

información: otras personas, análisis de documentos,

observación

- ¿Falta de conocimiento de los objetivos del proyecto?

Comunicar los beneficios generados por el proyecto

Resistencia al cambio - Solución

27


• ¿Cómo así? ¿Esto no debería ser obligatorio?

• Hay casos que son transitorios, ej., un nuevo director asume un

cargo en una nueva área de negocio

• Hay casos que son la rutina:

personas en cargos no por competencia, pero por

política

cambios frecuentes de gestores en poco tiempo

(gobierno después de una elección)

Áreas de negocio que delegan para el área de TI

decisiones que son de su propia responsabilidad

Reto: Usuarios que no dominan su negocio

28


• La especificación de requerimientos es el contrato entre

clientes y desarrolladores. Debe presentar todo lo que

será entregado al cliente, cumpliendo con todas sus

necesidades. El cliente debe conseguir comprenderla y

dar su aprobación para que el trabajo continúe

• Contrato que nos es aprobado por las dos partes no es

valido

Reto: Cliente no lee la especificación

29


• Profundizar conocimiento en el negocio

• Obtener otras fuentes de información (otras personas,

documentación)

• Alinear los roles entre el área de TI y los demás áreas

de negocio

Usuarios que no dominan su negocio - Solución

30


• Comprender la razón para que la especificación no sea leída

Interesados no comprenden su importancia

- Comunicar el proceso de desarrollo

- Simplificar la documentación

Presentación equivocada de los requerimientos

- Definir el nivel de retroalimentación deseado

El interesado cree que ya sabe todo

- Si esto es verdad, optimo. Si no lo es, repase con él

Cliente no lee la especificación - Solución

31


• Los ítems presentados abarcan una buena parte de las

dificultades enfrentadas en el trabajo de requerimientos.

• Casos más comunes

Conclusión

32


Encuesta


¿Preguntas?

¡Gracias por la atención y participación!

Nelson Camilo Orduz Illidge

[email protected] cr.linkedin.com/in/nelsonorduz

Skype: nelson.illidge

Cierre

34

Próximo Webinar:

Prototipos: Um juguete muy valioso

mailto:[email protected]

Presentación de PowerPoint · - Análisis de productividad en proyectos de software El libro más...

Documents

Transcript of Presentación de PowerPoint · - Análisis de productividad en proyectos de software El libro más...