ALM Day 1–Exitósa jornada de ALM sobre Team Foundation Server

por Daniel Laco  3. marzo 2011

 

Ayer 2 de Marzo realizamos exitósamente el evento de ALM (Application Lifecycle Management) sobre TFS.

La jornada se desarrolló en las instalaciones del MUG.

La sala estaba completa, y la inscripción se completo varios días antes de las charlas.

Se pueden bajar las presentaciones aquí

Reportes Agiles en Team Foundation Server – Remaining Work Report

por Viviana Chelini  29. octubre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

 

Seguimos en este post con:

Remaining Work Report

El reporte de trabajo restante permite realizar un seguimiento del progreso del equipo e identificar cualquier problema en el flujo de trabajo.

Información que proporciona el reporte

El reporte puede visualizarse según las horas trabajadas o el número de elementos de trabajo para cada tarea, caso de uso o error.

La primera vista (horas trabajadas) muestra el número total de horas de trabajo para el período de tiempo especificado y el progreso del equipo para completar ese trabajo. La segunda vista (elementos de trabajo) muestra el número de elementos de trabajo para el período de tiempo especificado y el número de elementos de trabajo en cada estado.

Horas de trabajo

Aquí se muestra un ejemplo del reporte en la vista Horas de Trabajo. Este ejemplo es positivo en cuanto que se ha completado una tasa constante de trabajo.

 

  • Horas restantes: valor acumulado de todas las horas restantes para todas las tareas.
  • Horas completadas: valor acumulado de todas las horas completadas para todas las tareas.

Número de elementos de trabajo

La ilustración siguiente muestra el mismo reporte pero en la vista Elementos de Trabajo, con los elementos de trabajo agrupados por estado. Un análisis del graficó permite determinar que el equipo realizó un progreso adecuado pero la estimación de elementos de trabajo aumentó desde el inicio de la iteración a casi tres veces más hacia el final de la iteración.

 

  • Activo: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Activo (azul).
  • Resuelto: valor acumulado de todos los casos de uso o errores que se encuentran en estado Resuelto (oro).
  • Cerrado: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Cerrado (verde).

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

 

  • Definir los casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada elemento de trabajo.
  • Especificar y actualizar los campos Horas Completadas y Horas Restantes para cada tarea o subtarea a medida que el equipo realiza progresos en cada elemento de trabajo.
  • Actualizar el Estado de cada tarea, caso de uso y error cuando progrese de activo a cerrado.


Análisis del reporte

El reporte muestra información que permite visualizar si el equipo progresa correctamente y si finalizará las tareas dentro del tiempo asignado, como así también permite responder a las siguientes preguntas:

 

  • ¿Con qué rapidez avanza el equipo hacia el trabajo restante?
  • ¿Se agrega trabajo durante la iteración?
  • ¿Cuánto progreso puede realizar el equipo en el tiempo disponible?
  • ¿Hay demasiado trabajo en curso?
  • ¿El flujo de trabajo se impide o está bloqueado?
  • ¿Cuándo finalizará el equipo la iteración actual?


Versión positiva del reporte

Un reporte positivo muestra un progreso constante para resolver y cerrar las tareas. La forma rectangular del diagrama indica que el trabajo estimado coincide con el trabajo final y no fue necesario agregar nuevas tareas.

Versión negativa del reporte

Un reporte negativo muestra poco progreso y las líneas planas del gráfico identifican que las tareas permanecen en el mismo estado durante un tiempo prolongado. También se puede determinar que le número elementos de trabajo aumenta después del punto medio de la iteración, lo que indica que se han introducido nuevas tareas las cuales no habían sido planificadas.

 

Los posibles indicadores que se pueden visualizar en un reporte negativo son:

  • El número de horas completadas o el número de elementos de trabajo resueltos o cerrados sigue siendo plano, se podría deben a un bloqueo en el progreso del equipo.
  • El número de horas restantes o elementos de trabajo activos aumenta.

    Esta situación indica que el equipo no estimó con precisión el trabajo en el inicio de la iteración o que el equipo agregó las características después de que se inició la iteración.

Reportes Agiles en Team Foundation Server – Build Quality Indicators Report

por Viviana Chelini  28. septiembre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Seguimos en este post con:

 

Build Quality Indicators Report

El siguiente reporte muestra la cobertura de pruebas, la renovación de código y el número de errores para una compilación especificada.

 

Información que proporciona el reporte

En el reporte se puede visualizar sobre el eje X las compilaciones que incluye el reporte, sobre la base de los filtros establecidos para la plataforma, la configuración y la definición de la compilación.

Cada barra vertical representa un conjunto de datos derivados de una o más compilaciones. En la variante de tamaño de código del reporte, la longitud de cada barra vertical representa el tamaño de la base de código protegida. Las pruebas manuales se pueden ejecutar en cualquier momento después de la compilación y están asociadas a esa compilación. Las pruebas que no se han ejecutado todavía se cuentan como "no concluyentes".

En la siguiente tabla se describe la información que aparece en el reporte:

Indicador

Descripción

Errores activos (número)

Gráfico de líneas que representa el número de errores que estaban activos al momento de la compilación.

Renovación de código (líneas)

Gráfico de líneas que describe el número de líneas de código que el equipo agregó, quitó y modificó antes de la compilación. La renovación de código se calcula determinando el número de líneas de código que se han agregado, eliminado o modificado en la compilación dividido por el número total de líneas de la compilación.

Cobertura de código (porcentaje)

Gráfico de líneas que representa el porcentaje de código que cubren las pruebas.

Pruebas no concluyentes

Gráfico de barras apiladas de color gris que indica el número de pruebas que no tuvieron un resultado correcto o se pusieron en pausa. Si la compilación no tuvo un resultado correcto, las pruebas no se cuentan o se cuentan como no concluyentes.

Ejemplo de informe Indicadores de calidad de la compilación

Pruebas no superadas

Gráfico de barras apiladas de color rojo que indica el número de pruebas no superadas para la compilación.

Pruebas superadas

Gráfico de barras apiladas de color verde que indica el número de pruebas superadas para la compilación.

Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades para administrar pruebas y compilaciones:

  • Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.
  • Crear definiciones de compilación. Puede crear varias definiciones de compilación, de modo que cada una de ellas pueda ejecutarse para generar código para una plataforma diferente.
  • Definir las pruebas que se ejecutarán automáticamente como parte de la compilación.
  • Configurar las pruebas para recopilar datos de cobertura de código. Para que los datos de cobertura de código aparezcan en el reporte, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.
  • Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos establecidos o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.

 

Análisis del reporte

El reporte permite responder las siguientes preguntas:

  • ¿Cuál es la calidad del software?
  • ¿Está el equipo probando suficiente código?
  • ¿Se están superando las pruebas?
  • ¿Es probable que el equipo termine en función del código y las métricas de pruebas?
  • ¿Con qué frecuencia se superan las pruebas y con qué frecuencia se prueba el código?

 

Versión positiva del reporte

Un reporte positivo muestra los siguientes indicadores:

  • La mayoría de las pruebas se superan (áreas grandes de color verde) y pocas pruebas no se superan (cantidades pequeñas de color rojo).
  • El porcentaje de color rojo es inferior al 20-30 por ciento.

Versión positiva del indicador de calidades de compilación

 

Versiones negativas del reporte

Una versión negativa mostrará uno o más de los siguientes indicadores:

  • Menos cobertura de código y más renovación de código. Podría indicar que el nuevo código se protege sin las correspondientes pruebas unitarias que lo cubran.

    Renovación de código del informe Indicadores de calidad de la compilación

  • Baja tasa de pruebas en ejecución. Estos datos podrían indicar que el equipo no está realizando suficientes pruebas. Este bloqueo podría indicar falta de recursos o que los evaluadores estén haciendo otras tareas, como escribir la automatización de pruebas en lugar de probar la funcionalidad actual.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Alta renovación de código, baja tasa de cobertura de código. Una alta renovación de código sugiere que los errores se introducirán como efectos secundarios de los cambios. De lo contrario, una alta renovación de código podría indicar una cobertura reducida y la necesidad de reescribir pruebas.

    Alta renovación de código en el informe Indicadores de calidad de la compilación

  • Tasa alta de pruebas no superadas. La siguiente ilustración muestra que muchas pruebas se realizan con una cobertura de código razonable, pero que no se están superando las pruebas. Estos datos podrían indicar prácticas de desarrollo poco rigurosas o, en iteraciones tempranas, que las pruebas son demasiado duras para esta etapa del producto.

    Prueba no superada en el informe Indicadores de calidad de la compilación

  • Alta tasa de pruebas que se superan y alta tasa de errores activos. La siguiente ilustración muestra una alta tasa de pruebas superadas pero, no obstante, un alta tasa de errores de entrada. Esta situación se puede producir por varias razones. Es posible que las pruebas no sean suficientemente rigurosas para esta etapa del producto.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Tasa creciente de superación de pruebas sin aumento en la cobertura de código. Habitualmente, cuantas más pruebas se realizan, se debe cubrir más código. Por otro lado, si la ejecución de pruebas y las tasas de superación de pruebas aumentan sin un aumento correspondiente en la cobertura de código, es posible que las pruebas incrementales sean redundantes.
  • El número de errores activos aumenta, pero las pruebas no superadas no aumentan. Es probable que las pruebas no estén probando la misma funcionalidad que indican los errores.
  • El número de errores activos está disminuyendo, pero las pruebas superadas no aumentan. Puede que exista un aumento en la tasa de reactivación.

 

 

Tags: , ,

ALM | Gestión de Proyectos | TFS

Reportes Agiles en Team Foundation Server – Reactivation Report

por Viviana Chelini  24. septiembre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Seguimos en este post con:

 

Reactivation Report

A medida que el equipo resuelve y cierra los errores, se puede utilizar el reporte de Reactivaciones para determinar la eficacia con que el equipo corrige los errores.

Las reactivaciones se refirieren a errores que se han resuelto o cerrado tempranamente y, a continuación, se han vuelto a abrir. La tasa de la reactivación también se la denomina tasa de retorno de errores.

Este reporte se puede utilizar para mostrar los errores y casos de uso que se han reactivado. Una tasa de reactivaciones baja (por ejemplo, menor que el 5%) podría ser aceptable dependiendo de los objetivos del equipo. Sin embargo, una tasa alto o creciente de reactivaciones indica que el equipo podría necesitar diagnosticar y corregir otros problemas.

Información que proporciona el reporte

El reporte de Reactivaciones informa en un gráfico de superficie el número de errores o casos que se han resuelto o reactivado después de cerrarlos.

 

Reactivation Report

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

  • Definir casos de uso y errores, y especificar sus rutas de iteración y de área.
  • Actualizar el Estado de los casos y errores a medida que avanzan desde que se activan hasta que se cierran.

 

Análisis del reporte

Es normal que el reporte varíe según el punto del ciclo de desarrollo del producto en que nos encontremos. Las iteraciones tempranas deberían presentar muy pocas reactivaciones.

El reporte de Reactivaciones muestra información que se puede utilizar para detectar si el equipo está reactivando un número alto de errores o casos, esta tasa se obtiene de contar el número de errores supuestamente corregidos cuyas correcciones no funcionan. Estas reactivaciones pueden crear un ciclo de repetición del trabajo que interfiere con las tareas planeadas.

El reporte permite responder las siguientes preguntas:

  • ¿Cuántos errores se han reactivado en la iteración actual?
  • ¿Cuántos casos de uso se han reactivado en la iteración actual?
  • ¿El equipo está resolviendo y cerrando los errores y casos reactivados a una velocidad aceptable?

 

Versión positiva del reporte

Una versión positiva del reporte muestra un progreso sostenido de resolución y cierre de errores. La tasa total de reactivación de elementos de trabajo es del 5% o inferior, y no aumenta durante la iteración. Cuanto menor sea la tasa de reactivación, más podrá progresar el equipo en su conjunto.

Versión Positiva - Reactivaction Report

 

Versión negativa del reporte

 

Versión Negativa - Reactivaction Report

Una versión negativa del reporte podría indicar:

El equipo está reactivando una cantidad elevada de errores. Una tasa de reactivación de errores alta podría indicar que el equipo está cerrando los errores rápidamente. Este indicador se podría tomar como una mala señal para el proyecto, ya que las reactivaciones introducen trabajo adicional que duplica el esfuerzo total que se necesita para completar el trabajo correspondiente.

El equipo está reactivando un número alto de casos de uso La tasa de reactivación de casos de uso debe considerarse como un porcentaje del número total de casos de uso que el equipo está cerrando.

 

Tags: , , ,

ALM | Gestión de Proyectos | TFS

Manage IT 2010 - Gestión de Proyectos y Arquitectura de Software

por Daniel Laco  26. abril 2010

Se viene el evento nuevamente !!!

 

Este año estaremos repitiendo el evento sobre Gestión de Proyectos y Arquitectura de Software.

VEMN SA conjuntamente con el MUG, Lagash SA y el apoyo de la Universidad Argentina de la Empresa (UADE) realizaremos el evento el día 8 de Junio a las 9.00 hs. en la sala Magna de la UADE.

Temario

8:30 - 9:30 Acreditación
9:30 – 10:00 Presentación del Evento y KeyNote
10:00 – 11:15 Value Express. Optimizando los resultados de sus inversiones realizadas.
(Susana Silberberg)
11:15 - 11:45 Break
11:45 – 13:00 Desarrollo de aplicaciones de misión crítica.
(Diego Gonzalez y Rodolfo Finochietti)
13:00 – 14:15 Almuerzo Libre
14:15 – 15:30 Estimación de Proyectos de Software. La cara oculta de las diferencias.
(Daniel Laco y Patricia Scalzone)
15:30 – 16:00 Break
16:00 – 17:15 ¿Sueñan los Gerentes de IT con programadores eléctricos?
(Luis Ávalo)
17:15 – 17:30 Cierre y Sorteos
Es un evento de interés para profesionales de TI, Gerentes de Sistemas, Líderes de Proyectos, Arquitectos, Analistas y todo aquel interesado en el mundo TI.


El evento es gratuito. Vacantes limitadas, con inscripción previa.

Para mas información en www.manageit.com.ar.


Que es ALM ?

por Daniel Laco - Leticia Medela  15. enero 2009

El significado de ALM

ALM (Application Life Cycle Management)

según la visión de Gartner

ALM comprende prácticas, procesos y herramientas que auxilian a la gestión del ciclo de vida de la aplicación, específicamente en el workflow de su producción y mantenimiento. La gestión de cambios, el workflow y gestión de ítems de trabajo, y la integración de todos los elementos son capacidades indispensables que permiten a una organización establecer trazabilidad , seguimiento y control a través de sus múltiples procesos, ubicaciones y variedad de herramientas, a lo largo de las etapas de desarrollo y despliegue de la aplicación.

Les dejamos un link interesante

mediaproducts.gartner.com/reprints/microsoft/vol4/article7/article7.html

 

la definición según Forrester

ALM comprende la coordinación de actividades del Ciclo de Vida del Desarrollo de Software , incluyendo requerimientos, modelado, desarrollo y pruebas, a través de:

1. Implementación de procesos que abarcan estas actividades.
2. Gestión de interrelaciones entre los artefactos utilizados o producidos por estas actividades.
3. Información de avance del esfuerzo de desarrollo , en su totalidad.

ALM y SDLC

ALM y SDLC no son la misma cosa, y a la vez tienen similitudes.

SDLC (Software Development Life Cycle)

Abarca todo lo concerniente al DESARROLLO de una aplicación software, incluyendo requerimientos, arquitectura, codificación, testing, gestión de configuración y administración del proyecto.

ALM (Application Life Cycle Management)

Incluye todo lo que es parte del ciclo de vida de una aplicación. La vida de una aplicación se inicia antes del desarrollo. Nace en algún lugar en el NEGOCIO, ya sea como una idea, una necesidad, una meta, o bien un riesgo. Finaliza más allá del desarrollo. Muere cuando el negocio ya no requiere de la aplicación, probablemente años después de finalizado su desarrollo.

 

SDLC es iterativo por naturaleza, ALM también lo es. En tanto el negocio responde a los cambios que se producen en su ambiente, comienza un nuevo ciclo ALM, enriquece la aplicación y realiza un nuevo despliegue para acrecentar sus beneficios.

Fuente : http://blogs.msdn.com/chrisbirmele/archive/2007/04/23/alm-versus-sdlc-two-different-things.aspx

 



ALM-Gestion de Proyectos

Tags: , ,

ALM | Gestión de Proyectos | Metodologías y Procesos

Publicación del libro donde participó Patricia Scalzone

por Patricia Scalzone  17. abril 2008

 

Como parte de un proyecto de colaboración de varias universidades de HispanoAmerica, y bajo la coordinación de Hanna Oktaba y Mario Piattini

se ha publicado un libro relacionado con el manejo de Procesos y las mejoras relacionadas en las Pequenas y Medianas Empresas.

El título es Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies y pueden obtener mas información aqui

Aqui va en resumen del libro (en Inglés) que sirve como guia de los temas tratados.

 PREFACE

From the very beginning of the 1990s onward, the software engineering community (industry and researchers) has expressed special interest in software process improvement (SPI). This is evidenced by the growing number of books, articles, and conferences that deal with the topic of SPI and the great number of international initiatives related to SPI such as CMM®, CMMI®, ISO/IEC 12207, 15504, and ISO 90003, among others.

Nevertheless, these standards and models are conceived for big organizations like USA DoD, NASA, multinational software factories, and so forth. In fact, there is a widespread tendency to emphasize that the success of SPI is only possible for large companies that have enough resources to tackle these types of practices. This perception is based on the fact that SPI programs are just not viable for small and medium enterprises (SMEs) because of their organizational structure and the high costs that are involved. However, the software industry in most countries is made up mainly of SMEs which favor the growth of national economies. Most software development organizations (nearly 90%) are SMEs which contribute to very valuable and widespread products.

Almost all the experts agree that the special characteristics of SMEs mean that process improvement programs must be applied in a way that is particular to them and visibly different from how this is done in the large organizations. This is not as simple as just regarding these programs as scaled down versions of those applied in big companies. In fact, the assessments conformant to the international standards are expensive and time consuming, difficult to perform in small companies, their process model structure is too complex, and the return of investment undertaken has to be seen from a long-term perspective.

The first International Research Workshop for Process Improvement in Small Settings organized by the Software Engineering Institute (October 2005), the new ISO/IEC JTC1 SC7 Working Group 24, which was created (2006) to develop the “Software Life Cycle Profiles and Guidelines for use in Very Small Enterprises (VSE),” and several other initiatives have demonstrated the increasing interest for new proposals and experiences in software improvement for SMEs. SMEs have become concerned about how to improve the capability of their software processes, as a fundamental element to increase product quality, addressing two main concerns: the first one has to do with their image, which is a key factor in order to be able to export software and hence enter the global marketplace; and the other concern is related to the efficiency and effectiveness of software process management.

Also, different countries like Mexico, Spain, Australia, Brazil, Colombia, and so on have developed local programs to promote the improvement of their software industry, especially focused on SMEs. As a result, several maturity and improvement models have been developed and successful experiences have been carried out. Therefore, in this context, we present this book, the main objective of which is to provide practical and useful guidelines, models, and techniques for improving software processes in SMEs and collecting real case studies and lessons learned, as successful examples of experiences in improving software process capability.

The book consists of 18 chapters. The chapters seek to provide a critical survey of the fundamental themes, problems, arguments, theories, and methodologies in the field of software process improvement in SMEs. Each chapter has been planned as a self-standing introduction to its subject.

Therefore, in Chapter I, “Organizational Analysis of Small Software Organizations: Framework and Case Study,” Jesús Zavala Ruiz realizes an overview on the complexity of a software organization focusing on software engineering and project management as disciplines in crisis and their underlying management paradigm. He considers opening it to those related disciplines and presents a framework to support this change of paradigm.

Claude Y. Laporte, Alain Renault, and Simon Alexandre, in Chapter II, “The Application of International Software Engineering Standards in Very Small Enterprises,” present the new ISO project proposed to facilitate access to, and utilization of, its standards in SMEs by means of developing profiles and providing guidance for compliance with ISO software engineering standards.

In Chapter III, “Practical Experience in Customization for a Software Development Process for Small Companies Based on RUP Process and MSF,” Valerio Fernandes del Maschi, Mauro de Mesquita Spinola, Ivanir Costa Alexandre de Lima Esteves, Luciano S. Souza, Wilson Vendramel, and Jorge Pirola, show the methodology, strategy, main phases, and procedures to the implantation of a customized software engineering process in a SME.

Chapter IV, “The Impact of Software Testing in Small and Medium Settings,” by Luis Vinicio León-Carrillo, shows some foundations of the discipline of software testing and fragments of some successful test process defined using a proprietary process definition language. He presents two case studies realized in Mexican SMEs that show the economic impact of the testing process.

Sarah Kohan, Marcelo Schneck de Paula Pessôa, and Mauro de Mesquita Spinola present “QuickLocus: A Software Development Process Evaluation Method for Small-Sized Organizations” (Chapter V). This is a low-cost process evaluation method especially designed for SMEs that has been successfully apply in several organizations which provide ways to be more competitive.

In Chapter VI, Deepti Mishra and Alok Mishra present “A Study of Software Process Improvement in Small and Medium Organizations,” in which some process assessment and software process improvement methods for SMEs are compared. This will lead towards development of a standardized software process improvement model for small and medium sized software development organizations in the future.

“CMM Fast-Track: Experience and Lessons Learned,” Chapter VII, by Hareton Leung and Yvette Lui, presents the CMM Fast-track Toolkit (CMMFT). This program aims to provide a faster and cheaper method of obtaining CMMI capability for SMEs, increasing the quality of their software products and gaining competitive advantage.

Chapter VIII, written by Hanna Oktaba and Ana Vázquez, presents “MoProSoft: A Software Process Model for Small Enterprises.” This chapter resumes the process model and its assessment method (EvalProSoft) and shows their most important features. It also includes the results of their application in four small Mexican enterprises.

Julio A. Hurtado, Francisco J. Pino, Juan C. Vidal, César Pardo, and Luis Eduardo Fernández present “Agile SPI: Software Process Agile Improvement: A Colombian Approach to Software Process Improvement in Small Software Organizations” in Chapter IX. This framework (Agile SPI), designed to motivate SMEs towards improving and certifying their software development processes, is based on the integration of software processes in small and medium organization contexts and cultures. Knowledge regarding the organization and its main features let processes generate profits and increase the intellectual capital of the organization.

In Chapter X, John Gómez and Alejandro Núñez present “Agile Practices in Project Management.” In this chapter, both authors present common agile practices as the way to address the daily problems that may appear in a process improvement initiative. They explain how these practices can reduce the efforts and cost, and contribute to realize benefits sooner, in a motivational way.

A framework for improving software process in Latin-American SMEs is being developed by the COMPETISOFT project. This framework is composed by a reference process model, an assessment model, and an improvement model, and it is based on other previously solutions, especially in the MoProSoft project. COMPETISOFT is shown in Chapter XI, “COMPETISOFT: An Improvement Strategy for Small Latin-American Software Organizations,” written by Hanna Oktaba, Mario Piattini, Félix García, Francisco J. Pino, Claudia Alquicira, Francisco Ruiz, and Tomás Martínez.

Chapter XII, “SPI Long-Term Benefits: Case Studies of Five Small Firms,” written by Aileen Cater-Steel and Terry Rout, presents a study of assessment-based improvement in more than 20 SMEs during five years. The results show how improving frameworks can affect the organization and its business.

Oswaldo Terán, Johanna Alvarez, Blanca Abraham, and Jose Aguilar show in Chapter XIII, titled “An Incremental Functionality-Oriented Free Software Development Methodology,” the validated methodology used in a factory oriented at free software development. This incremental methodology is based on a prioritization of functionalities development according to needs and has features of both cathedral and bazaar developing styles.

“How to Align Software Projects with Business Strategy” (Chapter XIV) by Gustavo Ricardo Parés Arce, proposes a methodological framework to promote strategic alignment, improve execution through better communication, and understand IT projects. It will help to make better IT decisions for offering a competitive edge to companies based on a better management of the strategic IT portfolio.

Chapter XV, “A Model to Classify Knowledge Assets of a Process-Oriented Development,” written by Raquel Anaya, Alejandra Cechich, and Mónica Henao, identifies a model to characterize knowledgeable assets and their relationships in a software organization, and it sets the basis for defining a transversal process of knowledge management at the organization.

Alicia Mon, Marcelo Estayno, and Patricia Scalzone describe a framework implementation experience in an accounting office in Chapter XVI, titled “Practical Application of a Software Development Framework in an Accountant Office” They show how their process definition allows progressively putting a work model into practice for implementing a process model with continuous improvement.

Chapter XVII, “Estimate of Effort in Software Implementation Projects” by María Julia Orozco Mendoza, Evaristo Fernández Perea, and Claudia Alquicira Esquivel, contains a proposal for project estimation of software used in a Mexican SME. This is based on Karner’s use case point estimation method. Two methods are compared to provide conclusions.

In “Improving Resource Management: Lessons from a Case Study in a Middle-Range Governmental Organization,” Chapter XVIII, Juan M. Luzuriaga, Rodolfo Martínez, and Alejandra Cechich present how resources have been managed according to recommendations of the MoProSoft reference model in a governmental organization. They present some lessons learned from this case study.

In summary, these chapters constitute evidence of the importance of software process improvement in SMEs. These are intended to be useful to a wide audience, including CEOs, CIOs, software engineers, software process engineers, quality specialists, consultants, and software students.

We hope that the practical vision and experience presented in this book will provide the reader with useful guidelines, models, and techniques for improving software processes in SMEs. In this sense, we wish to contribute to increase the quality of the processes and products of SMEs.

 

 

 

Tags: , ,

ALM | Gestión de Proyectos | Metodologías y Procesos

La Calidad y las PyMes de la Industria del Software

por Patricia Scalzone  12. marzo 2008
En la economía mundial se observan claras tendencias hacia la internacionalización de los negocios y los mercados de capitales, la liberación del comercio, el intercambio entre grandes bloques regionales y cierto desplazamiento del centro del comercio mundial desde el Océano Atlántico hacia el Pacífico (Bozzo, 2001).
 
El papel de las Pequeñas y Medianas Empresas (PyMEs) en la estructura industrial deja paulatinamente de ser cualitativa y cuantitativamente marginal, para conformar una parte integrada y no simplemente alternativa de organizaciones productivas. El mercado Argentino no está exento a estas consideraciones.
 
En particular la industria del software, y especialmente luego de los cambios económicos sufridos a partir del año 2001, se ha convertido en una actividad económica de suma importancia para la economía del país, como para el resto de los países latinoamericanos.
 
Por otra parte, las pequeñas y medianas empresas desarrolladoras de software sufren un cambio de paradigma importante, producto de la maduración de este mercado emergente, y es que ya no basta con aplicar bien la tecnología, o aplicar la tecnología de última generación para obtener un buen producto software. Uno de los desafíos para no sucumbir, es buscar e implementar nuevas estrategias sobre la base del trabajo con mayor eficiencia (Bozzo, 2001).
 
En este mercado esto se traduce con procesos de calidad. La única forma que tiene una Pyme de desarrollo de Software de mejorar su eficiencia y ser más productiva, alcanzando los niveles de calidad exigidos por el comercio exterior, es introducir un modelo de calidad, que se ajuste a las necesidades de la organización.
No obstante, las PyMEs de este sector productivo poseen una serie de ventajas y algunas desventajas, debido a sus características estructurales.
 
Entre las ventajas de las PyMEs más significativas, se puede señalar:
 
  1. Posibilidad de flexibilidad y reaccionar con rapidez frente a los cambios.
  2. Mayor poder de innovación.
  3. Menores costos de infraestructura.
  4. Concentración en la toma de decisiones.
  5. Puntos de ventas cercanos al consumidor.
  6. Atención más personalizada.
 
Entre las desventajas de las PyMEs más destacadas, se puede señalar:
 
  1. Pocas facilidades de financiación.
  2. Problemas para planear su crecimiento.
  3. Falta de gerenciamiento profesional.
  4. Dificultades para exportar.
  5. Fuerte individualismo que le impide efectuar distintos tipos de asociaciones.
  6. Fuertes lazos afectivos con su pasado.
  7. Sistemas de información, administración y contabilidad deficientes.
 
Dentro de este contexto, es necesario aplicar un modelo de procesos que asegure obtener los niveles de calidad requeridos por el mercado para ser eficiente, pero que por otro lado no resulte excesivamente burocrático, que se convierta en gigantesco e inflexible, o que termine resultando muy costoso y desmotivador para el equipo de desarrollo.
 
En la actualidad existen varios modelos de proceso apropiados para aplicar en el desarrollo de software. Entre los más utilizados y reconocidos por el mercado, se encuentra el conjunto de Normas ISO, para certificación de Calidad tales como ISO/IEC 15504-2, ISO 90003, ISO 9001:2000, y el Modelo CMMI (Capability Maturity Model Integration)  (Software Engineering Institute, 2002), que mide la madurez de las organizaciones y ha sido creado especialmente para el desarrollo de software.
 
Estos modelos han sido pensados para la mejora de la calidad en organizaciones grandes, por lo tanto, la implementación en pequeñas y medianas empresas resulta dificultosa, compleja y de un costo económico significativo. Es por ello que han surgido diversas experiencias de crear modelos de proceso adecuados a las PyMEs, como son los casos de Brasil, con el Modelo "MR mps" de Brasil  (Weber, y otros, 2004), México con el Modelo MoProSoft, Modelo de Procesos y Evaluación para Desarrollo y Mantenimiento de Software  (Oktaba, y otros, Agosto 2005), y el modelo SPICE: Software Process Improvement and Capability dEtermination, ISO 15504  (ISO/IEC, 2003).
 
El modelo MoProSoft, ha sido elaborado por la Universidad Autónoma de México y aprobado en el marco del Programa para el Desarrollo de la Industria de Software (ProSoft) de la Secretaría de Economía, como Norma de Certificación de Calidad de software para la industria mexicana de software (NMX-I-059/01-NYCE-2005 TECNOLOGÍA DE LA INFORMACIÓN - SOFTWARE - MODELOS DE PROCESOS Y EVALUACIÓN PARA DESARROLLO Y MANTENIMIENTO DE SOFTWARE), creado especialmente para el desarrollo de software por Pequeñas y Medianas Empresas.
 
MoProSoft, que en estas latitudes se conoce como CompetiSoft, se propone como un modelo sencillo de entender y de aplicar en las empresas pequeñas, que les permita mejorar su forma de trabajar y obtener niveles de competitividad internacionales en relativamente corto tiempo y a bajo costo.
 
En su estructura define diferentes niveles de capacidad, de forma similar a lo que hace CMMI, con un orden específico para la implementación de las prácticas de los procesos partiendo de prácticas básicas, e incorporando prácticas más complejas que se corresponden con los niveles más avanzados.
 
Por otra parte, una dificultad con la que se encuentran a menudo las empresas de desarrollo de software es la selección y utilización de herramientas apropiadas para el gerenciamiento de proyectos que a su vez permita la visibilidad de todo el desarrollo, incluyendo la definición de tareas y responsabilidades por rol en el equipo de trabajo, hasta la generación de código correspondiente al producto requerido.
 
Generalmente, las empresas cuentan e incorporan a la organización, una diversidad de herramientas que se encuentran disponibles en el mercado, para cumplir con las diferentes actividades. Este conjunto de herramientas, habitualmente permanecen desvinculadas entre sí, generando dificultades para gestionarlas, mantenerlas y controlar el versionamiento de los productos que se desarrollan, no teniendo la información disponible exacta acerca de los elementos del desarrollo, se encuentren o no documentados. Como resultado, se cuenta con distintas fuentes o repositorios no integrados, que hace costosa y menos confiable la obtención de información para el control gerencial de los proyectos.
 
En Marzo del 2006 Microsoft Corporation lanzó al mercado Visual Studio Team System (VSTS), un conjunto integral de herramientas diseñadas para permitir la comunicación desde dos perspectivas: por una parte, entre los miembros de un equipo de desarrollo, y por otra parte, entre los miembros del equipo de desarrollo y los interesados o clientes, en tiempo real (Levinson & Nelson, 2006), facilitando una administración legítima del proyecto integrada con el desarrollo, sin tener que recurrir a herramientas extras.
 
El Visual Studio Team System viene provisto de dos metodologías de desarrollo, basadas en el metamodelo denominado Microsoft Solution Framework (MSF), que es un marco de trabajo descriptivo con modelos y disciplinas a seguir. Las metodologías propuestas por el fabricante no son más que guías de procesos de desarrollo prescriptivas, una pensada más liviana que es MSF para Desarrollo de aplicaciones Ágiles, y otra más formal y rigurosa que es MSF para Proceso de Mejora Continua con CMMI.
 
No obstante los modelos provistos por la herramienta, la misma cuenta con la capacidad de personalizar la totalidad del Modelo de Proceso a las características propias del modelo de cualquier organización. De esta manera, permite conformar una plantilla de proceso genérica que cuenta con todos los elementos necesarios, cada vez que la misma es seleccionada al iniciar un proyecto.
 
Como resultado, podría haber tantas plantillas de procesos diferentes como proyectos tuviera una organización, ya sea de Modelos Agiles como de Modelos tradicionales.
 
Cada uno de estas metodologías, dentro de este conjunto de herramientas, cuenta con una Guía de Procesos, que sirve de consulta permanente para todos los miembros del equipo de proyecto, y puede personalizarse acorde al proceso seleccionado.
 

 

 

Tags: , ,

ALM | Gestión de Proyectos | Metodologías y Procesos

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML