082 Analisis Y Desarrollo Buenas Practicas Para La Convivencia
•Descargar como PPT, PDF•
0 recomendaciones•426 vistas
Recomendados
Recomendados
Más contenido relacionado
Similar a 082 Analisis Y Desarrollo Buenas Practicas Para La Convivencia
Similar a 082 Analisis Y Desarrollo Buenas Practicas Para La Convivencia (20)
Más de GeneXus
Más de GeneXus (20)
Último
Último (20)
082 Analisis Y Desarrollo Buenas Practicas Para La Convivencia
- 1. GX Consulting Development Framework: Análisis y Desarrollo, buenas prácticas para la convivencia Juan van de Kerchove Genexus Consulting Alfonso Falconi Genexus Consulting
- 2. GeneXus Consulting Development Framework
- 3. Introducción
- 4. Presentación de los Equipos Analistas Funcionales Equipo de Desarrollo
- 5. Evolución Bla Bla Bla Bla Bla Bla
- 6. Llevada a la Práctica
- 8. Setup Inicial Formatos de Caso de Uso Salida
- 9. Prueba Conceptual Entrada Formatos de Caso de Uso Salida
- 11. CU: Trabajar con
- 12. CU: Trabajar con
- 14. CU: Orientados a Servicios
- 15. Actas de Cambios
- 16. Kick Off Caso de Uso Versión 2 Opcionalmente: Caso de Uso Versión 1 Entrada Salida Mejor visión del negocio Detección de errores Aclaración de dudas
- 17. Construcción Caso de Uso Entrada Salida
- 18. Validación Funcional Caso de Uso Entrada Salida
- 19. Validación Funcional Integrada Entrada Salida
Notas del editor
- En el ciclo de charlas de Genexus Consulting Development Framework, nuestra exposición hará referencia a los procesos de Requisitos, Diseño, Construcción de un proyecto.
- Comenzaré preguntándoles quien de uds no participó en un proyecto : - donde no estaba bien definido lo que había que hacer. - donde se tuvieron que rehacer trabajos - con personas sobrecargadas, otras no tienen claro que se espera de ellas - con Trabajo fuera de hora – apuros sobre el final. - donde l a moral del equipo se deterioró - que costó y/o demoró mas de lo previsto. - donde e l cronograma no era realista - donde la calidad del resultado no fue satisfactoria Son algunas de las situaciones por las cuales todos alguna vez hemos pasado. Como resultado participar en varios proyectos, GenexusConsulting ha elaborado un conjunto de prácticas que ayudan en buena medida a mitigar estos problemas. Les contaremos nuestra experiencia usando estas prácticas y sus resultados.
- En los últimos años hemos visto la especialización de algunos roles en los proyectos de software. Uno es el caso del TEST, donde se establecen equipos independientes y especializados y el otro.. el de Analistas Funcionales. GenexusConsulting viene trabajando en proyectos con Analistas Funcionales y Equipos de Desarrollo altamente especializados e independientes. El equipo de Analistas Funcionales está compuesto por un coordinador general y analistas, los cuales básicamente están encargados de relevar, analizar y documentar los requerimientos. Por otra parte el equipo de desarrollo, está compuesto por un gerente, jefes de desarrollo y programadores. Hacer referencia al porte de los proyectos de GenexusConsulting.
- Estas prácticas son el resultado de observar problemas de comunicación entre los equipos. En una PRIMERA EXPERIENCIA - Al comienzo cada equipo contaba con RESPONSABILIDADES pero sin comunicación entre ellos en todas las fases del proyecto. -Las INSTANCIAS DE COMUNICACION entre los equipos estaban limitadas a intercambios de documentación. Los analistas entregaban: casos de uso, modelos de datos y de procesos. El equipo de desarrollo devolvía observaciones también en documentos. En definitiva, a veces, se hacía muy difícil para el equipo de desarrollo implementar, algunas funcionalidades ya sea por inconsistencias, factores de tiempo, malinterpretación de los requerimientos, poca disponibilidad de tiempo del analista funcional, etc. - Se perdían oportunidades en ETAPAS TEMPRANAS, donde el equipo de desarrollo podría haber hecho propuestas para optimizar la solución al cliente. - Pasamos por situaciones donde los requerimientos venían redactados en CASOS DE USO CON MUCHA NARRATIVA, y generó como consecuencia que lo IMPLEMENTADO NO CUMPLIA con las expectativas del analista funcional. Trayendo como consecuencia que la interpretación de los casos en etapas avanzadas del proyecto, hiciera más costosa la corrección de programas . - El RESULTADO fue que el PRODUCTO FINAL NO cumplía con las EXPECTATIVAS del analista funcional. -Todos los PROBLEMAS QUE COMENTABA ALFONSO al principio eran muy comunes. APRENDIZAJE - Luego de la experiencia anterior, nos dimos cuenta que ERA NECESARIO FOMENTAR ESPACIOS DE DIALOGO. Para lo cual definimos lineamientos de comunicación generales. Y en esa comunicación se involucraron diferentes mecanismos. Como ser, Kick off, casos de uso alineados al diseño de la solución o validaciones funcionales entre otros. -Una manera de tener una COMUNICACIÓN MAS FLUIDA fue: -- Contar con un SETUP INICIAL para hablar de los diálogos e interfases en la app. Sirve para redactar los CdU. Esto lo denominamos “Nivelación del Analista Funcional en el aspecto tecnológico” (sobre todo cuando no pertenecen a GenexusConsulting) - Establecer una instancia donde -en los casos en los que sea necesario- se implemente un prototipo con los requerimientos funcionales recién relevados, brindándole al analista funcional mejores ideas para la redacción de los casos de uso.
- A continuación pondremos en práctica lo mencionado anteriormente analizando las 7 etapas que conforman la metodología utilizada por GXC para lograr una buena comunicación entre equipos de análisis y desarrollo. Requerimientos Setup inicial Prueba conceptual Kick off Construcción Validación funcional Validación funcional integrada >>>Juan Definir como mostramos en un gráfico la etapas de la puesta en práctica. En todas las etapas debemos incluir el equipo que participa o ambos equipos.
- - El Analista Funcional comienza relevando los requerimientos con el cliente final . Salida de este proceso: Una vez que el analista cuenta con las especificaciones funcionales y tuvo una formación sobre las herramientas, está en condiciones de escribir los casos de uso de la solución. Ver un link con la ppt 10.
- Setup inicial para nivelar al analista funcional en el aspecto tecnológico y discutir sobre los diálogos e interfases del software resultante. De esta forma se disminuyen los conflictos. También ayuda al AF a redactar los casos de uso. Salida de este proceso: Una vez que el analista cuenta con las especificaciones funcionales y tuvo una formación sobre las herramientas, está en condiciones de escribir los casos de uso de la solución.
- - Este paso es opcional, es una alternativa que existe para clarificar dudas de las especificaciones. Ayuda al analista a imaginarse la solución y al desarrollador la viabilidad técnica. Cuando se cuenta con información sobre los requerimientos básicos, se coordina una reunión con el equipo de desarrollo para luego poder implementar un prototipo (prueba conceptual). Se hace una demo al analista funcional que le servirá para redactar la primera versión del caso de uso. (un ejemplo es cuando los equipos trabajan por primera vez juntos y los AF no conocen las herramientas de Artech) -Tiene 2 beneficios claros: ayuda al analista funcional a imaginarse la solución y redactar los casos de uso y para el equipo de desarrollo le asegura la viabilidad técnica. (Estos beneficios también aplican para el setup inicial en caso de que no haya prueba conceptual)
- + Como introducción a esta pantalla, incluir el problema que llevó a la evolución de los Casos de uso. -Casos de uso con mucha narrativa -> Errores en la interpretación de los mismos -El equipo de desarrollo, piensa en términos de GXFlow, Interfases con WebPanels, Filtros, etc. Los equipos funcionales en sus propios términos, pero es importante la gran difusión de casos de uso. Para resolverlo redefinimos el formato de los casos de usos contando con 3 tipos básicamente: Formato orientado a pantallas (Trabajar con, WebPanels y Transacciones). Formato orientado a servicios. Formato orientado a modificaciones menores sobre sistemas ya en producción. Además se les agregó una sección especial donde se indica la VERSIÓN, FECHA de la versión, responsable del CAMBIO y una breve descripción de los cambios. IMPORTANTE: No se redactarán Casos de Uso para especificar las paramétricas o codigueras.
- Aclarar que las Actas de Cambio están orientadas a los cambios funcionales que impactan en los Casos de Uso y/o en aplicaciones ya existentes (ajustes menores). Conclusiones: -No surgen de la teoría, son años de experiencia -AF muy avanzados da la impresión pero no es así, ellos aprenden a escribir los casos de uso de esta forma ya que les es más fácil para plasmar sus requerimientos y termina siendo más productivo para el equipo de desarrollo consumirlos en un cierto formato ya conocido. - Hubieron conflictos de áreas de responsabilidad – “esta es mi parte, no te metas con lo mío” pero con el tiempo ambos equipos cooperaron para lograr sus objetivos. -En estos formatos de casos de uso se tiene el diseño del negocio o funcional y el diseño técnico, que en alguna fase más o menos temprana, deben realizarse mediante un trabajo conjunto de ambos equipos. -La elaboración del diseño requiere aportes de los dos equipos -Hemos visto mejoras notables en la eficiencia global del proceso, cuando estos equipos se nivelan, trabajan juntos y aprovechan capacidades y herramientas de la otra parte.
- INTRODUCCIÓN: + Para el equipo de desarrollo el objetivo es tener una visión del negocio, para comprender mejor el problema, quitarse las dudas con respecto a las especificaciones. + Para el funcional asegurarse que efectivamente se haya comprendido el tema, pueden detectarse errores en forma temprana etc. Participan el líder funcional, el líder de fábrica, el desarrollador y el gerente de fábrica (permitirá tener una mejor idea al momento de armar los cronogramas de trabajo). + El líder funcional relata el módulo (si es un proceso, se van detallando las tareas que se realizan). El líder de fábrica presenta al líder funcional las dudas, las notas tomadas, los supuestos, etc. Si es necesario se invoca a un analista del negocio para evacuar dudas. Como resultado del kick off se obtienen nuevas especificaciones que posibilitan el inicio de la construcción (si el módulo es muy grande se puede dividir en varios kick off). En algunos casos se cuentan con documentos que hacen énfasis en información clave como ser diagramas de estado, registros testigo para trazabilidad de la entidad, etc. Los Kick Off están orientados a pequeñas entregas.
- Comienza el desarrollo. En esta etapa el equipo de desarrollo cuenta con la siguiente documentación: Modelo de datos, diagrama de procesos, casos de uso y máquina de estado (opcional). Se pueden agendar reuniones con el analista funcional para aclarar dudas, consultas del negocio o validar funcionalidades técnicas críticas para el futuro.
- Durante esta etapa, participa el analista funcional y el equipo de desarrollo. Al finalizar la mínima unidad que requiera validación: Se muestra el producto al analista quien deberá realizar una validación funcional. La tarea se ejecuta en el ambiente de desarrollo. La validación funcional consiste en verificar que el módulo cumple funcionalmente con las especificaciones entregadas. Se mostrará que lo plasmado en el caso de uso es lo que se construyó y detectar si se necesita una redefinición. (diferenciar o enfatizar lo que es una validación funcional de lo que son las pruebas en Testing y que TODO lo especificado en el CdU está implementado) A veces se requiere la presentación de nuevas especificaciones o cambios en las existentes. Si es necesario se vuelve a hacer otra muestra. Si hay cambios, el analista deberá documentarlos. Es importante destacar que el hecho de incorporar a los analistas funcionales en esta fase del desarrollo, logra romper barreras, crear consciencia de equipo y en cierta manera el trabajo final tendrá mayor respaldo ante el cliente final. Mencionar que es una etapa donde se acerca al Analista Funcional al desarrollo. Crea un espíritu de equipo y participación.
- Durante esta etapa, participa el analista funcional y el equipo de desarrollo. El entorno de ejecución es de Pretesting, significa que está configurado el esquema de seguridad y será el mismo ambiente donde el equipo de testing probará la aplicación. Una vez finalizada la validación funcional integrada, el analista funcional: - Habilita a la fábrica a pasar a test lo desarrollado y se promociona la aplicación a un ambiente de Testing. - Coordina con el equipo de testing las pruebas de la aplicación.
- COMUNICACION + Para la ejecución de este marco de trabajo, será importante comunicar a los equipos las fases por las cuales se deberá pasar, remarcar la importancia de las comunicaciones en todas sus formas (ya sea a través de un documento, mails, reuniones, etc) y el valor de llevarlas a cabo. + Una cosa importante es planificar todo lo que pueda planificarse. Si los analistas tienen claro con anticipación su participación, será más fácil para todos. DISPONIBILIDAD DE TIEMPO + La disponibilidad de tiempo es de ambas partes. Los desarrolladores están construyendo y a veces no disponen de tiempo para reunirse con los analistas a pedido de ellos para consultas, porque surgen nuevas cosas, etc. + Se deberá contar con disponibilidad de tiempo del Analista Funcional para el Kick off y para las validaciones funcionales. MANTENIMIENTO DE CASOS DE USO - Se deberá preveer el tiempo empleado en la actualización de los Casos de uso. El hecho de no actualizarlos éstos quedan desincronizados y afectará por un lado al equipo testing dado que se basan en estos documentos para hacer sus casos de prueba, y por otro lado al equipo de desarrollo ya que no tendría manera de justificar lo desarrollado. El caso de uso es un documento vivo durante las etapas de análisis y de construcción. (Se logra que estén alineados porque es un documento de entrada para Testing. Cada Caso de Uso debería corresponder con la funcionalidad desarrollada y validada funcionalmente. En caso que el test realice los casos de prueba a partir de los casos de uso, se deberá mantener informado de los cambios (por eso es importante mantener un versionado de los casos de uso) INTERACCION CON TESTING + El equipo de testing no tiene interacción con el equipo de desarrollo. Es el Analista Funcional quien hace de vínculo entre ellos. Remarcar que el tiempo incurrido en estas tareas puede ser visto como un problema pero a la larga es mucho menor que el tiempo de retrabajo en caso de inconsistencias futuras.
- “ Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.” PMI Necesidad de Nivelación ===================== Se reconoce la necesidad de nivelación de los conocimientos, herramientas y visiones de la otra parte de forma de disminuir los conflictos. >> Veamos que: El equipo de desarrollo, piensa en términos de GXFlow, Interfases con WebPanels, Filtros, etc. Los equipos funcionales en sus propios términos, pero es importante la gran difusión del estándar de casos de uso. Hemos visto mejoras notables en la eficiencia global del proceso, cuando estos equipos se nivelan, trabajan juntos y aprovechan capacidades y herramientas de la otra parte. En este sentido, en un proyecto reciente, se realizó una primera fase sin nivelación, que fue realizada con dificultades importantes La primera fase, culminó con la recepción de casos de uso y procesos, que no habían aprovechado las posibilidades de patterns para implementación de los diálogos, y otros recursos técnicos disponibles, GXFlow, etc. Por lo que la transición al diseño técnico tuvo idas y vueltas, retrabajo, la natural sensación del equipo funcional de que los planteos representaban una crítica a su trabajo, que los planteos se hacían por limitaciones de las herramientas, etc. Conflictos de áreas de responsabilidad – “esta es mi parte, no te metas con lo mío” - Imaginen la distorsión del clima de trabajo. >> Lecciones Aprendidas Aunque cada uno se proponía hacer lo mejor… los resultados no eran buenos. Se realizó una etapa de lecciones aprendidas que permitió rearmar las cosas para una 2da fase o 2do ciclo en el proceso (mantenemos un enfoque incremental, etc.) Se realizó una nivelación y comprensión de las herramientas: CU orientados a patterns, manejo de modelador de flujos GXFlow, etc., por ejemplo los procesos fueron especificados directamente en GX El resultado para la siguiente fase fue excelente, se lograron mejoras globales en el tiempo que significaron disminuciones de 3 a 1. Además de una mejora sustancial en el clima de trabajo. Diseño Funcional y Diseño Técnico : Modelo Operativo y Software ======================================================== Una forma de verlo es que hay un diseño del negocio o funcional y un diseño técnico, que en alguna fase más o menos temprana, deben realizarse mediante un trabajo conjunto, seguramente hablan de lo mismo (del diseño del sistema) pero los énfasis son en diferentes aspectos. La elaboración del diseño requiere aportes de los dos equipos y no puede realizarse en forma secuencial (al menos que el equipo funcional tenga un gran conocimiento de los recursos técnicos, extremo que normalmente no ocurre) Mencionar la situación cuando los analistas funcionales no tienen a cargo el diseño de la aplicación. En este caso, los Casos de Uso serán esenciales (menos técnicos).