Calidad de Software Trabajo Práctico Integrador. CACIC 2012 XVI Escuela Internacional de Informática

Transcripción

1 Calidad de Software Trabajo Práctico Integrador CACIC 2012 XVI Escuela Internacional de Informática

2 INDICE 1. Consignas del Trabajo Práctico Pautas generales Consignas Presentación de la empresa requirente Escenario de la empresa NewIdea SRL Comercialización Workflow de las líneas de Desarrollo... 7 Página 2 de 9

3 1. Consignas del Trabajo Práctico 1.2 Pautas generales 1. El trabajo deberá ser grupal de hasta 3 personas. 2. Características del informe: a. Con portada donde se indique el título del TP y los integrantes (nombre, apellido, universidad). b. Incluir como anexo las referencias bibliográficas y material de investigación utilizado. 3. Fecha de Entrega: 23/11/ Por correo electrónico a: vvcuomo@hotmail.com / Virginia.cuomo@huddle.com.ar 2.2 Consignas El equipo asume el rol de Gerente de Calidad de la empresa QASoft. La Gerencia de Calidad de QASoft tiene bajo su responsabilidad las funciones de mantenimiento de la calidad de su propia organización y los servicios de consultoría en mejora de procesos para clientes externos. El trabajo a realizar consiste en el desarrollo de una propuesta de consultoría para la mejora de procesos de una organización llamada NewIdea dedicada a la prestación de servicios informáticos. La propuesta deberá abarcar los aspectos propios del servicio de consultoría y los aspectos comerciales que cotizan el servicio. La propuesta será presentada al Directorio y Gerente de NewIdea, quien justifica la adquisición de este servicio, y debe incluir los siguientes temas: A. Propósito Explicación de qué se espera satisfacer con esta propuesta, qué objetivos de mejora abarca. B. Alcance del Servicio 1) La descripción del servicio en sí mismo, incluyendo el modelo o metodología SPI aplicada y la forma de trabajo del consultor para con el personal de la empresa (modo de interacción). 2) Los recursos requeridos (tanto de la consultora QASOFT como de la empresa NewIdea) 3) Los riesgos identificados al momento de realizar la propuesta. 4) Condiciones asumidas al momento de realizar la propuesta (supuestos). 5) La recomendación de utilizar o no un estándar de calidad como parámetro para la mejora: a) En caso afirmativo, se deberán presentar los estándares sugeridos, con las respectivas justificaciones de uso y cómo se sugiere incluirlo. (Evaluar todas las alternativas posibles y justificar la recomendación) b) En caso negativo, deberán indicarse los motivos por los que no se sugiere utilizar estándares de calidad como parámetro para la mejora. (Evaluar todas las alternativas posibles y justificar la sugerencia) 6) La recomendación de utilizar o no un metodología, paradigma y técnicas para desarrollo de las aplicaciones: Página 3 de 9

4 a) En caso afirmativo, se deberán indicar las metodologías, paradigmas y técnicas sugeridas con las respectivas justificaciones. b) En caso negativo, deberán indicarse los motivos por los que no se sugiere utilizar metodologías, paradigmas y técnicas. 7) El análisis de las herramientas de soporte: a) Identificar las herramientas utilizadas actualmente b) De considerarse necesario, proponer nuevas herramientas. Cada propuesta de herramienta deberá incluir ventajas y desventajas de la misma respecto de la situación actual y el escenario esperado luego de su implementación C. Plan de trabajo. D. Cotización. Detallar los ciclos de mejora que se proponen, en orden de prioridades y acorde al modelo o metodología SPI propuesto. Incluir las actividades requeridas por los consultores para el entendimiento de los objetivos de la organización en relación a este proyecto. Proponer un plan de trabajo, con hitos, entregables y responsables. Definir los productos entregables en cada ciclo. Especificar los equipos de trabajo de QASOFT y NewIdea, y su dedicación al proyecto. Proponer una estrategia de contratación (alcance Cerrado, Time and Materials, otras) Estimar el esfuerzo de la consultoría para cada actividad (presentar como ternas: Actividad - Hs. Estimadas - $) Deberán estar cotizadas dentro de la propuesta las actividades requeridas por los consultores para el entendimiento de los objetivos de la organización en relación a este proyecto. E. Condiciones generales (según corresponda) Validez de la propuesta, Condiciones de contratación, Aspectos de confidencialidad. Soporte y garantía F. Muestra de Definición procesos Seleccionar uno de los ciclos de mejora propuestos en el desarrollo del punto C y elaborar los artefactos definidos como entregables de dicho ciclo. Entiéndase por artefacto entregable: procesos, procedimientos, templates, guías, y demás elementos (excepto herramientas de software) que permitan la implementación de las mejoras definidas. Realizar dichas definiciones de acuerdo a la metodología de trabajo propuesta, acorde a los métodos formales de definición utilizados o por utilizar durante la consultoría. Página 4 de 9

5 2. Presentación de la empresa requirente 2.1 Escenario de la empresa NewIdea SRL CACIC 2012 XVI Escuela Internacional de Informática La empresa NewIdea SRL solicita servicio de asesoramiento para la mejora de sus procesos productivos. NewIdea es una empresa argentina dedicada a la prestación de servicios de desarrollo de aplicaciones y consultoría de software. La empresa se organiza en tres líneas de negocio que se caracterizan de la siguiente forma: - Desarrollo de software Custom: proyectos medianos y grandes. - Desarrollo de software Custom: proyectos chicos. - Servicios de Consultoría en: o Diseño de arquitectura o Experiencia de Usuario La empresa se dimensiona de la siguiente forma: 60 personas en la primera línea de negocio, 20 personas en la segunda y 10 personas en la línea de consultoría. En base a un análisis comercial interno, se ha podido deducir que la empresa posee una distribución de sus proyectos de la siguiente forma: un 50% de proyectos custom medianos a grandes, un 30% de proyectos custom chicos, y finalmente un 20% de proyectos correspondientes a servicios de consultoría. Los proyectos de desarrollo de ambas líneas se realizan tanto en tecnología.net como Java y todos implementan desarrollos web, cliente servidor. Ambas líneas se diferencian únicamente en que los proyectos chicos aplican SCRUM y XP, mientras que en los proyectos medianos a grandes aplican ciclos de vida en cascada con UML y casos de uso para el análisis funcional. NewIdea está en un proceso de crecimiento y expansión, buscando liderar mercados en toda América como principal objetivo y algunos mercados específicos asiáticos como objetivo de mediano plazo. La empresa ha decidido invertir en la mejora de sus procesos de desarrollo de software. Actualmente exporta a Venezuela, Ecuador y Colombia. El Directorio ha establecido los primeros contactos para ganar mercado en Canadá y Estados Unidos. Para ello ha definido un conjunto de estrategias prioritarias: Mejorar la calidad de servicio para sus clientes para mantener altos niveles de fidelización y de referencias de sus clientes. Mejor control de los costos, para poder competir. Ordenamiento de los procesos productivos que requieren de mayor grado de estandarización para facilitar la expansión de la empresa. Evaluar la conveniencia de alcanzar algún tipo de certificación de calidad para lograr una mayor inserción en los mercados canadiense y estadounidense. Página 5 de 9

6 NewIdea está dirigida por un Directorio conformado por 3 socios, uno de los cuales cumple a su vez el rol de Director General. Cada socio es referente de una línea de negocio. De la Dirección General dependen 4 Gerencias: 1) Administración y Finanzas; 2) Comercial; 3) Operaciones; 4) RRHH; cada una con su respectivo gerente, roles asumidos por personal de la empresa. De la Gerencia de Operaciones dependen las áreas: 1) Producción de Software; 2) Testing; 3) Infraestructura Tecnológica y 4) Soporte y Mantenimiento; cada una de las cuales cuenta son su respectivo Jefe de Área. Los proyectos medianos a grandes están conformados por un líder de proyecto, dos a tres analistas funcionales, y entre 7 y 10 desarrolladores. Mientras que los proyectos chicos cuentan con un líder de proyecto, un analista funcional, y entre 1 a 3 desarrolladores. Cada Líder de Proyecto reporta a un Gerente de Proyecto, quien a su vez puede gestionar hasta 5 proyectos simultáneamente. Del Jefe de Producción de Software dependen los Gerentes de Proyectos y sus respectivos equipos. El área de Testing cuenta con una dotación de 12 Analistas Testers que son asignados en función del esfuerzo de desarrollo estimado en cada proyecto. Testing es responsable de la calidad del producto que se libera al Cliente. Los Analistas Tester realizan el testing funcional validando que se cumplan los requerimientos expresados por los clientes. Esta área no realiza el testing unitario. Este testing es realizado por los mismos desarrolladores en forma automática cuando es posible, junto con prácticas de integración continua. Para automatizar testing unitario utilizan N-Unit/J-Unit de acuerdo a la tecnología aplicada en el proyecto. Para favorecer la integración continua se utiliza la herramienta CruiseControl, que es open source. La empresa no tiene un sistema de gestión orientado a procesos, cada líder de proyecto realiza la planificación, estimación y seguimiento de sus proyectos en forma personalizada, lo que complica al Gerente de Proyecto la consolidación de la información, por lo que tiene dificultades en su relación con el Gerente de Producción por no brindar alertas tempranas del estado de situación de los proyectos a su cargo. En general utilizan MS Project para dar seguimiento a las tareas y planillas Excel para la registración de las horas que se insumen en cada tarea. No hay una forma estandarizada de registrar las horas por lo que se dificulta realizar un análisis posterior de los tiempos insumidos por cada recurso, y la obtención de indicadores de productividad. Esta dificultad es más notoria aun cuando se requiere obtener métricas consolidadas de ambas líneas, dadas las diferencias de prácticas de gestión aplicadas, considerando incluso prácticas ágiles en la línea de proyectos chicos. El Jefe de Producción de Software ha insistido en la necesidad de trabajar con pautas más ordenadas y ha dado indicaciones para que todos los equipos documenten los proyectos con UML. Por este motivo, los proyectos medianos a grandes han incorporado el Modelo de Casos de Uso para documentar los requerimientos y el Modelo de Clases de Análisis, aunque aún no se utilizan herramientas que den soporte automatizado a esta forma de trabajo. Siendo el primer punto de partida para un trabajo más ordenado, el Jefe de Producción de Software no ha insistido en estas prácticas de modo estandarizado para todos los proyectos, sino que ha puesto su mayor énfasis en que la gente las comience a aplicar, aun sabiendo que no resuelve sus necesidades de indicadores generales. Página 6 de 9

7 2.2 Comercialización NewIdea tiene dos modalidades de venta: a) Proyecto cerrado: los vendedores, tomando en consideración información obtenida durante la preventa, definen el alcance de alto nivel de la aplicación a desarrollar. Un desarrollador senior asignado por el Jefe del área de Producción de Software, realiza una estimación técnica y colabora en la confección de la propuesta funcional y comercial. b) Time & Materials: se asigna un equipo de trabajo (que puede trabajar en NewIdea o in house en la empresa del cliente). Se cotiza el rate de las personas que conforman el equipo y se factura al cliente por las horas/hombre mensuales insumidas en las tareas asignadas. Estas dos modalidades comenzaron a aplicarse en función de las necesidades de adecuar la estrategia de ventas para mantener el flujo de nuevos proyectos. El alcance de los servicios de NewIdea incluye el servicio de soporte y mantenimiento de las aplicaciones que produce, en los casos que el cliente desee contratarlo. Caso contrario se entrega el código desarrollado para que el cliente lo implemente y mantenga internamente. La falta de estandarización en el registro de horas afecta la facturación de los proyectos que se comercializan en modalidad Time & Materials, generando diferencias con lo esperado por el cliente. Así mismo, para los proyectos cerrados, se dificulta el análisis de desvíos generales y la proyección de insumo de horas esperada hasta el fin del proyecto. 2.2 Workflow de las líneas de Desarrollo a) Preventa: los vendedores, el desarrollador senior y el líder de proyecto completan la propuesta comercial que incluye la cotización y un plan de proyecto. En líneas generales para los proyectos de alcance cerrado, se establecen módulos por funcionalidad y se especifican los alcances de cada uno. Estos alcances pueden sufrir adecuaciones acorde al conocimiento que se va ganando del proyecto y las re-estimaciones que realiza el equipo al inicio de cada módulo. Para los proyectos Time & Materials, se estipulan módulos fijos de horas/hombre de acuerdo con el cliente al inicio del proyecto. b) Desarrollo: una vez que los proyectos han pasado la etapa de preventa y se firma el contrato con el cliente, el Analista Funcional completa el relevamiento definiendo los requerimientos del negocio. En el caso de proyectos cerrado, parte de la base de alcance definido en la propuesta comercial. A medida que se va desarrollando la aplicación, pueden surgir cambios identificados por el Cliente que pueden impactar en el alcance acordado, en el plazo del proyecto y en los costos. En todos los casos, los cambios son considerados nuevos requerimientos. Para realizar el impacto de cada cambio, el equipo se apoya en el conocimiento funcional que como equipo ha adquirido sobre el proyecto y producto, y entre todos definen los componentes a que se necesitan modificar. En proyectos de alcance cerrado, se negocia con el cliente el esfuerzo adicional, ya sea por facturación de las horas excedentes o bien por eliminación de otros requerimientos que implican mismo esfuerzo. En proyectos Time & Materials, se negocia con el cliente si el cambio es prioritario, pudiéndose dejar de lado otros requerimientos ya previstos para el producto, si el cliente así lo determinase. Página 7 de 9

8 c) Testing: se realiza el testing funcional o de integración una vez finalizados los desarrollos correspondientes al alcance del módulo. Muchas veces, los desarrollos se demoran, generando retrasos en la realización del testing, por lo que el trabajo de esta área se ve afectado en la calidad y profundidad de las pruebas cuando no es posible demorar la fecha de entrega. Cuando se terminan los desarrollos, el equipo de proyecto del área de Producción de Software, elabora un paquete de instalación con la versión ejecutable, lo resguarda en el file system, e informa a Testing por mail para que los Analistas Testers asignados al proyecto lo instalen en su entorno de prueba y completen el testeo. Si durante las pruebas se identifican defectos, se registran en un Excel y se informan vía mail al equipo del área de Producción de Software, quienes deben corregirlos y generar un nuevo paquete de instalación con el fix. Junto al paquete generan un documento Word que indica los defectos que se han corregido en dicho fix. Una vez generado el fix, los Analistas Testers inician un nuevo ciclo de test (instalación, ejecución, registración y reporte de defectos) para corroborar que los defectos que identificaron en ciclos anteriores estén resueltos. Los ciclos de testing se repiten hasta cerrar todos los defectos, hasta obtener un nivel de defectos aceptable por el cliente, o hasta acordar internamente la calidad del producto a liberar entre las áreas de Testing y Producción de Software cuando los plazos de entrega están retrasados o en alto riesgo. d) Infraestructura Tecnológica: el área cuenta con personal técnico que se ocupa de proveer y mantener un soporte adecuado para las aplicaciones de la empresa NewIdea. Cuenta con 2 Ingenieros de Software que participan en la Preventa y desarrollo del proyecto asesorando y definiendo sobre el soporte tecnológico necesario para soportar las aplicaciones construidas. e) Implementación: una vez aprobada la liberación del entregable del entregable (alcanzado un hito del proyecto o al cierre de una iteración), el equipo genera un paquete de instalación con el código y los ejecutables, en una dirección FTP que es informada al Cliente y al área de Soporte por el líder del proyecto para su implementación. f) Soporte: para las actividades de soporte, se cuenta con SVN para el control de cambios de código. Es utilizada por todos los proyectos por igual, aunque están evaluando la implementación de TFS de Microsoft para gestión de código. Hoy en día, existe un repositorio de código y un repositorio de documentación separado para cada proyecto. El repositorio de documentación no utiliza la herramienta SVN, sino que es una estructura de directorios en un servidor dedicado para file system. g) Gestión de Proyectos: los Gerentes de Proyecto de NewIdea son PMP (Project Management Professional) certificados del PMI (Project Management Institute) y la mayoría de ellos (6 de 8) consideran que las metodologías ágiles son caóticas y no garantizan una adecuada gestión de los proyectos. Así mismo, los líderes de proyecto, algunos conocen las prácticas del PMI, pero no están certificados y las aplican parcialmente utilziando únicamente los aspectos básicas de las áreas de conocimiento del PMBOK. El Jefe del área de Producción de Software Página 8 de 9

9 entiende que existen aspectos positivos y negativos en ambas formas de trabajo pero desconoce cuál puede ser la mejor para las líneas de desarrollo con las que NewIdea cuenta. El Gerente General, que ha estado realizando contactos en los EEUU, considera que la adaptación de las metodologías ágiles es lo que facilitaría a la empresa alcanzar sus objetivos estratégicos. Por otra parte, suelen presentarse diferencias y roces entre las los líderes de proyecto y los gerentes de proyecto por diferencias e incluso solapamientos entre las actividades por no estar claras las responsabilidades entre ambos. h) Gestion organizativa interna No hay un mecanismo interno que asegure una adecuada gestión interna, visibilidad de riesgos generales, situaciones de equipo, y líneas de trabajo organizadas para todas las áreas. Cada Jefe de Área de las áreas que conforman la gerencia de Operaciones no generar ningún tipo de reporte formal. El único mecanismo que existe es una reunión semanal con el Gerente de Operaciones, donde comparten visión, objetivos a corto plazo y situaciones generales de los proyectos. Así mismo, el Gerente de Operaciones, comparte una reunión semanal con el Gerente de RRHH, el Gerente Comercial y el Gerente de Administración y Finanzas, donde tratan estrategias de permanencia y rotación del personal, indicadores de utilización de horas (horas facturables a los clientes) y proyecciones de ventas para los próximos tres meses. El Directorio se reúne una vez por mes, convocando a los Gerentes correspondientes de acuerdo a los temas que ellos consideren tratar de acuerdo a los objetivos estratégicos de la empresa. No cuentan con herramientas que den soporte a esta gestión facilitando el seguimiento de accionables y análisis de cumplimiento de objetivos. El Directorio considera que deben instrumentar un panel de indicadores que le permita tomar decisiones sobre el rumbo de compañía pero no está seguro de las variables que deberían incluir en dicho panel. Página 9 de 9