ESCUELA POLITÉCNICA DEL EJÉRCITO GERMAN ÑACATO MAO ASTUDILLO MAURICIO CAMPAÑA Lectura 1: STAKEHOLDERS IN REQUERIMENTS ENGINEERING: Lectura 2 BUILDING WHAT STAKEHOLDERS DESIRE: MARIO ALMACHE XAVIER MERA SANTIAGO JÁCOME MAESTRÍA EN INGENIERÍA DE SOFTWARE

QUE ES ? Es una persona o organización quien influye en la requerimentación del sistema o quien es impactado por ese sistema. STAKEHOLDERS QUIÉNES SON? Clientes: Que pagan por el sistema Usuarios: Usan el sistema Consejeros: Expertos legales y reguladores que poseen información relevante sobre los requerimientos Grupos de proyecto: Están involucrados en el desarrollo del proyecto CÓMO IDENTIFICARLOS ? Los primeros Stakeholders son los clientes o Stakeholders del Negocio, ellos proveen los requerimientos del Negocio.

STAKEHOLDERS EN LA INGENIERÍA DE REQUERIMIENTOS CONSTRUIR UN SISTEMA ÚTIL SABER SUS REQUERIMIEN TOS SABER LOS DESEOS Y NECESIDADES DE STAKEHOLDER Importancia Stakeholders en RE quienes son cuan importantes son 1.Tienen un interés activo en el sistema (usan, envueltos en el proceso). 2.Debería administrar, introducir, operar o mantener el sistema después de su desarrollo. 3.Están envueltos en el desarrollo del sistema como un arquitecto, desarrollador, tester, Ing. De Calidad o administrador de proyecto. 4.Son responsables del negocio o proceso que el sistema, soporta o automatiza. 5.Tiene un interés financiero (pagan o son responsables de vender) 6.Forzar el sistema como regulador, o 7.Son negativamente afectados por el sistema (asi llamados stakeholder negativo)

STAKEHOLDERS EN LA INGENIERÍA DE REQUERIMIENTOS

No todos los stakeholder son importantes Se debe priorizar el rol del stakeholder. Si lo descuida podría matar el proyecto, el rol del stakeholder es critico. Si se descuida debería tener un impacto negativo significante en el sistema, el stakeholder tiene un rol mayor. Si descuida debería tener un impacto marginal en el sistema, el rol del stakeholder es menor. Se debe seleccionar individuos o a grupos representativos de los papeles identificados y prioritarios. Con los cuales se pueda sacar y validar los requisitos de sistema.

Construcción de lo que los Stakeholders (partes interesadas) desean de un sistema. Ian Alexander Consultor independiente especializado en ingeniería de requerimientos para sistemas de automatización, transporte terrestre y aeroespacial, telecomunicaciones y servicios del sector público.

Stakeholders La clave del éxito en la construcción de sistemas es tomar en cuenta los deseos de los Stakeholders. La clave del éxito en la construcción de sistemas es tomar en cuenta los deseos de los Stakeholders. Nadie puede construir lo que ellos no desean. Nadie puede construir lo que ellos no desean. Pero el problema está en ubicar a los Stakeholders apropiados y saber los detalles de lo que verdaderamente quieren. Pero el problema está en ubicar a los Stakeholders apropiados y saber los detalles de lo que verdaderamente quieren.

Ejemplos de proyectos ■ Proyecto A es un juego de un dispositivo portátil para el mercado adolescente. ■El proyecto B es un sistema de software integrado para el control de las operaciones de una línea ferroviaria.

Proyecto A: juego para adolescentes  El Gerente de Producto considera que la clave del éxito es la construcción de lo que quieren sus consumidores adolescentes: excitación, velocidad, sensación de dominio, sensación de misterio y así sucesivamente.  Otros Stakeholders son los Reguladores que deciden en nombre del público, si el juego es excesivamente violento o tiene demasiado contenido sexual, incluso en la portada del juego.  El regulador, a su vez, está influido por los políticos, que responden a la satisfacción del público.

Proyecto A: juego para adolescentes  Evidentemente, el balance de los deseos de los reguladores con los jugadores es esencial, pero también lo es la neutralización de la competencia –Stakeholders negativos.  Por último, un proyecto es un éxito comercial si se gana dinero, es decir, si se ajustan a las expectativas financieras de los beneficiarios, tales como los Directores de la empresa y los Accionistas.

El (onion model) modelo de la cebolla muestra las presiones que el Gerente del Producto debe mediar con todos los Stakeholders.

Proyecto B: control de operaciones de un línea ferroviaria El Gerente de Proyecto y el Ingeniero Jefe saben que la clave para el éxito es la construcción de un sistema que trabaje con seguridad, seguridad y seguridad. El Gerente de Proyecto y el Ingeniero Jefe saben que la clave para el éxito es la construcción de un sistema que trabaje con seguridad, seguridad y seguridad. El aprobación del sistema por parte del Regulador de seguridad es obligatoria, pero primero el proyecto debe integrar a todos los subcontratistas de los diferentes componentes para hacer que el sistema trabaje decuadamente. El aprobación del sistema por parte del Regulador de seguridad es obligatoria, pero primero el proyecto debe integrar a todos los subcontratistas de los diferentes componentes para hacer que el sistema trabaje decuadamente.

Proyecto B: control de operaciones de un línea ferroviaria  Por tanto las especificaciones de las interfaces de todos los componentes es crucial.  En la teoría, el equipo de sistemas puede establecer las interfaces con antelación e imponer requisitos a los subcontratistas para que el proceso de integración no sea difícil  En este caso los criterios de los Stakeholders menos poderosos “no son pisoteados”.  El modelo de la cebolla para este caso se vería muy diferente al señalado anteriormente.

No haga solamente lo que le dicen Los desarrolladores pueden (y deben) desempeñar un rol positivo en el descubrimiento y exploración de los requerimientos " " Kent Beck: " hay más que ofrecer en un buen Sw que hacer sólo lo que el cliente dice"

Errores frecuentes con los clientes  Hacer promesas y no entregar nada.  Entregar lo que usted quiso desarrollar sin la observación de lo que los clientes desean.  Sistema entregado es diferente a lo que se pidió.

DWTTY (Do What They Tell You)   Conduce a una gran cantidad de pedidos de cambio.   Es una fortaleza el escuchar y responder a lo que los clientes piden.   Los pedidos de cambio son una señal de que los clientes están comprometidos con el sistema.   Cualquier desarrollador que vaya más allá de DWTTY, no deberían perder este sentido, pues, los clientes desean continuar mejorando las características del sistema.

Qué sucede cuando desarrolladores DWTTY?  Primero, los aspectos solicitados son frecuentemente más caros de lo que deberían ser. (los desarrolladores pueden ofrecer las opciones con sus costos asociados)  Segundo, los aspectos pedidos pueden carecer coherencia. (Los desarrolladores tienen la única ventaja de ser capaces de ver un dominio amplio con ojos frescos)  Tercero, los clientes frecuentemente tienen una comprensión monolítica del sistema que ellos requieren, conduciendo a desarrollos riesgosos. (Ello, a menudo lleva a los desarrolladores para ver cómo particionar el sistema en entregas incrementales)

DWTTY y la responsabilidad  Aparte de los problemas técnicos anteriores, DWTTY sufre del defecto fatal de carencia de responsabilidad. "Hey, no me llore. Yo simplemente hice lo que me fue dicho“, no es una posición responsable del desarrollador.  El desarrollo de software funciona mejor cuando todos involucrados aceptan su responsabilidad en el sistema.

Entonces…  Hay muchas alternativas para DWTTY. Un desarrollador podría pensar, "Bien, si ellos no están a cargo, entonces Yo estoy a cargo." Esta estrategia niega el derecho de los clientes de ser responsables con el sistema.  ¿La pregunta no es, " ¿ Quién está a cargo? ", sino, " ¿ Cómo podemos trabajar juntos?"

¿Cómo se logra lo anterior en Programación Extrema?  El principio de los pasos pequeños, sugiere trabajar en pasos concretos pequeños.  Si nosotros aplicamos este principio a los requerimientos, el diálogo de requerimientos fomentará en todos el lograr algo concreto rápidamente y con más frecuencia.  Los pasos pequeños crean retroalimentación, reducen el esfuerzo, y fomentan la confianza entre los miembros de equipo.

EN DEFINITIVA  Las prácticas precisas no son tan importantes como el intento detrás las prácticas. Todos los involucrados deben asumir su responsabilidad en el desarrollo del sistema.  Los desarrolladores deben comprometerse para escuchar las necesidades reales de los clientes; los clientes deben digerir la retroalimentación acerca de sus deseos. Entonces todo el equipo logrará mucho más si los desarrolladores "hacen más de lo que ellos me cuentan."