Migración a Team Foundation Server 2010 – Donde están los Reportes? por Daniel Laco

20. agosto 2010

 

Dónde quedan los reportes de TFS2008 cuando se realiza la migración a TFS 2010?

A no preocuparse si acceden a los viejos reportes y ven que la fecha de actualización del cubo quedó congelada a la fecha de la migración, porque los reportes están ahora en una nueva locación

Por los cambios producidos en los modelos en la nueva version 2010, el proceso de actualización que realiza TFS hace que se instalen las nuevas bases de datos y cubos siguiendo el concepto de Project Collections (ver http://www.vemn.com.ar/Blog/post/Nuevos-conceptos-en-TFS-2010.aspx)

Las bases anteriores TFSWarehouse y al cubo también llamado de la misma manera siguen existiendo y los reportes en Reporting Services (SSRS) siguen apuntando a esta base .

Pero los reportes para los templates basados en MSF for Agile y MSF for CMMI en la versión 4.2 son migrados a un nuevo directorio en Reporting Services. Este directorio se llama TFSReports y dentro de él está el directorio DefaultCollections (esto dependiendo del nombre de la collection que fué creada en la migración). Dentro de este último directorio vamos a encontrar todos los reportes de los proyectos anteriores migrados a la nueva versión 2010 de TFS.

Por supuesto, que todos los proyectos abiertos desde Visual Studio, apuntan ahora a la nueva ubicación. Esta ubicación es sacada desde la consola de configuración de TFS.

En el gráfico siguiente, está un esquema de como quedan ahora las bases de datos y los Data Sources de Reporting Services

 

ServerUpgrade

 

Tambien tenemos nuevos Data Sources

2008

2010

TfsReportsDS

Tfs2010ReportsDS

TfsOlapReportsDS

Tfs2010OlapReportsDS

 

Aquí les dejo una serie de link sobre información puntual sobre el tema de reportes (algunos extraidos del blog de Buck Hodges:

Sunder Raman, Program Manager para TFS, ha escrito una serie de post (en inglés) sobre los cambios en el almacenamiento y en los cubos para 2010.

Reporting

 

Customizing Reports for Team Foundation Server 2010 (en MSDN)

Cube

 

 

John Socha-Leialoha, escribió una serie de post sobre la actualización de reportes en TFS

ALM, Gestión de Proyectos, TFS , ,

Migración de TFS 2010 - Como detener o iniciar todos los servicios? por Daniel Laco

19. agosto 2010

 

Si es necesario hacer backup o restore de las bases de datos, o mover una instalación o hacer cambios importantes, es útil contar un algo que nos permita con un solo comando parar o arrancar todos los servicios que usa Team Foundation Server.

Hay una herramienta de linea de comandos  que se llama TFSServiceControl que permite realizar esas operaciones con todos los servicios,  y los Application Pools que usa el Team Foundation Server.

El comando se usa:

TFSServiceControl [quiesce|unquiesce]

TFSServiceControl quiesce Detiene los servicios

TFSServiceControl unquiesce Inicia los servicios

 

Fuente (en inglés) : http://msdn.microsoft.com/en-us/library/ff470382.aspx

 

ALM, Gestión de Proyectos, TFS ,

Nuevos conceptos en TFS 2010 – Categorizando Work Items por Victor Passador

10. agosto 2010

Siguiendo con nuestra idea de mostrar novedades que exceden la calificación de “nueva característica”, y que nos ponen en situación de repensar algunas situaciones, quisiera comentar sobre las Categorías de Work Items.

Ahora, con TFS 2010, podemos categorizar Work Items, pero … ¿por qué querríamos o necesitaríamos hacer esto?.

Porque tendríamos la posibilidad de tratar de la misma manera a aquellos work items que son diferentes pero parecidos, teniendo en cuenta que cuando hablo de “tratar” estoy apuntando al seguimiento de esos work items. Con este nuevo agrupamiento podríamos por ejemplo:

  • Construir queries, con una sintaxis mucho más simple e intuitiva, que devuelvan work items de más de un tipo. ¿O acaso una “User Story” y un “Quality of Service Requirement” no son en definitiva requerimientos del usuario?
  • Construir reportes de manera más simple apuntando a obtener resultados más “macro” sin resignarnos a perder el detalle de lo que hay debajo (… o ver el bosque y también ver los árboles). Cada work item tendrá su propia estructura de datos, con el nivel de detalle que requiera cada uno, pero aquella información que tengan en común podría ser explotada en reportes utilizando estas nuevas categorías.
  • Construir Test Suites utilizando Microsoft Test Manager (el nuevo integrante de la familia TFS, del que estaremos posteando/presentando novedades muy pronto)

 

Para crear queries que respondan a este nuevo agrupamiento, tenemos disponible el comando “In Group”. Aquí tienen un ejemplo de una query utilizada por el Microsoft Test Manager que se vale de este nuevo operador.

image

Estas categorías están definidas en el template con el cual fue creado el proyecto. Es por este motivo que no encontraremos (al menos por ahora) ningún botón que diga “Add New Category”.

Pero no todo está perdido, si nos damos un poco de maña, nos prometen que podemos categorizar work items en proyectos que no tenían esa facilidad.

Hasta la próxima !

Gestión de Proyectos, TFS, ALM , , , ,

Guía de Migración a Team Foundation Server 2010 por Daniel Laco

21. julio 2010

 

El proceso de migración a TFS 2010 siempre es complejo. TFS hace uso de varias tecnologías demas del propio servidor, por ej: usa SQLServer para almacenamiento, Sharepoint para repositorio de documentos y trabajo colaborativo y IIS para alojar los servicios.

En resumen siempre es bueno leer las guías y estar preparados para esta tarea.

En http://vs2010upgradeguide.codeplex.com/ hay una guía que preparan los ALM Rangers que es un grupo de gente que adiciona información a las guias que publica MS.

Aqui les dejo un listado de los temas que están resueltos en esta guía (en Inglés):

 

  • Introduction
    • A Few Words about Team Project Collections
  • Part I – Upgrade Planning
    • Choosing between Upgrade and Migration
      • Upgrade
      • Migration
      • Server Move
    • Upgrade Process
      • In-Place Upgrade
      • Migration Upgrade
      • Upgrading Projects from Multiple TFS 2008 servers into one TFS 2010 server
      • Splitting a Team Project Collection into Multiple Collections
      • Moving reports after a Team Project Collection move
      • Updating Team Project Portal for an existing Team project
  • Part II – Questions and Answers (Q&A)*
    • Joining a Workgroup Machine to a Domain
    • Upgrading severs when SQL Mirroring is enabled
    • Recovering system if upgrade fails midway
    • Can I use a TFS2008 Process Template to create team projects in TFS 2010?
    • How can I enable Agile Workbooks in upgraded Projects?
      • Enabling the Product Backlog Workbook
      • Enabling the Iteration Backlog Workbook
    • How can I enable Test Case Management in upgraded project?
    • How can I enable Branch Visualization in upgraded projects?
    • How can I enable Lab Management in upgraded projects?
    • What is the WITAdmin command line utility used for?
    • Where is the custom reports placed post upgrade?
    • Will my TFS2008 reports work post upgrade?
    • Can I add a new Database to my existing TFS 2010 farm?
    • How to resolve the error encountered when bringing cloned TPC online?
    • Can I move TPC Database from one Database server to another Database Server?
    • How to enable the TFS reports if the WSS server is upgraded to MOSS server?
    • How to Move Team Projects from one Team Project Collection to another?

     

     

    Siempre es importante la guia de MS previo paso por este sitio. Esta guía se puede bajar de aquí.

     

     

  • ALM, Javascript, TFS

    Desmitificando Branches por Victor Passador

    8. junio 2010

    En el tiempo que llevamos trabajando en consultoría relacionada con TFS, y en particular con lo concerniente al Source Control, nos hemos encontrado con dos tipos de casos:

    • Empresas que no aprovechan los beneficios aportados por el branching.
    • Empresas que hacen abuso del branching, que también pierden esos mismos beneficios y terminan siendo devorados por el monstruo.

     

    Los primeros no quieren ni hacer mención al branching por simple temor a lo desconocido, pero en cuanto vencen ese primer miedo y obtienen los primeros buenos resultados, se convierten automáticamente en los de la segunda clase, casi sin término medio.

    Los segundos vuelven a convertirse en los primeros por abandono.

    Con este post me propongo  hacer una introducción a las políticas de branches, para que ambos grupos puedan lograr el equilibrio.

    Branching Guidance

    En gran parte de los casos con los que me he cruzado, el caos viene de la mano de la falta de políticas de branches. Casi como la planificación previa de la arquitectura de cualquier aplicación, los branches necesitan ser diagramados y consensuados de antemano.

    Desde hace varios años ya, está publicada en Codeplex lo que se conoce como “Branching Guidance” sobre la cual estoy basando este post. Hoy la guía se encuentra en su versión 2.0 a raíz del feedback recibido desde la comunidad y recientemente fue publicado el Release 2010, obviamente apuntando al lanzamiento de la nueva versión de la plataforma.

    En esa guía hay una frase a modo de advertencia que me gustaría transcribir:

    Cada branch que se crea tiene un costo, por lo tanto asegúrese de obtener algún valor de él.

    Creo que esta frase resume perfectamente el concepto de equilibrio al que hacía referencia  anteriormente, y al punto al que deberían llegar las empresas que decidan apostar por una política de branches.

    Apostando a una política de branches

    El uso de branching requiere ordenamiento, y por tal motivo voy a enumerar algunos principios que se deberán tener en cuenta antes de meter mano:

    • El encargado de ejecutar y mantener la política de branches que se defina, deberá tener un nivel medio-avanzado en el manejo de TFS. (“Cada branch tiene un costo …”).
    • La política que se defina dependerá fuertemente de los tipos de Release (release de nueva versión, de service pack, de hot fix, etc.) requeridos por el proyecto en cuestión, de lo que se desprende:
      • Se pueden definir diferentes tipos de políticas para diferentes tipos de proyecto.
      • A menor cantidad de tipos de release, un plan de branching más simple.

     

    Los planes de branching sugeridos en la guía tienen una característica “aditiva” lo que permite elegir en primera instancia un plan simple, y en caso de que aparezcan nuevos tipos de release (conocidos como release vehicles, ver Glosario) ir “complicando” el plan agregando nuevos branches.

    Un plan equilibrado – El “Standard Branch Plan”

    Imaginemos un escenario con las siguientes características:

    • Se desarrolla un producto del cual el cliente siempre tiene la última versión.
    • Se desarrollan permanentemente nuevas versiones con nuevos features (un release vehicle por aquí).
    • Se entregan además actualizaciones (services packs, bug fixes, otro release vehicle por aca).
    • Cada actualización liberada sobre una determinada versión contiene todas las actualizaciones anteriores.
    • Los services packs se desarrollan paralelamente a los features de la nueva versión.

     

    Dado este escenario, un plan de branches como el que muestro a continuación permitiría soportar las necesidades del proyecto a la vez que mantendría una cantidad de branches controlada, fuera de una situación de caos.

    image

    Qué propone este plan:

    • Branch Development:
      • Sobre él se desarrollan los features de la próxima versión.
      • Existe un flujo continuo desde y hacia el branch Main (merges).
      • Merge hacia Main (RI) ante cada objetivo cumplido, por ejemplo el fin de una iteración.
      • Merge desde Main (FI) cada vez que Main genera un build exitoso.
    • Branch Service Pack:
      • Se crea en el mismo instante que Release, determinando en ese momento la jerarquía Main –> Service Pack –> Release.
      • Los cambios “de servicio” se hacen sobre esta rama y luego se hace merge (RI) sólo hacia Main.
    • Branch Release:
      • Es hijo de Service Pack.
      • La entrega al cliente se hace desde este branch, y una vez que se libera, el branch se marca como read-only.
      • Bug fixes graves, que se hagan sobre el branch Release, deben hacer merge hacia Main pero pasando por el branch Service Pack (Release –> Service Pack –> Main)
      • Una vez que se creó este branch, los cambios que no fueron aprobados para el Release en curso sólo deberían hacerse en Main.

     

    Herramientas de TFS

    Con el lanzamiento de TFS 2010, se agregaron nuevas ventajas que facilitarán la vida del desarrollador que se encuentre con la difícil tarea de hacer los merges al momento de incorporar cambios a los diferentes branches, entre los que tenemos:

    Visualización gráfica de la jerarquía de branches …

    image

    y visualización gráfica de los merges a los diferentes branches (incluye línea de tiempo …)

    image

    Con esta última mejora, podremos saber si un determinado cambio fue incorporado a un branch que lo requiera (si no se hubiera hecho el merge, el branch se vería en color rojo), y además, podemos saber en qué fecha y con qué changeset fue realizado.

    Conclusión

    Lograr equilibrios no es sencillo, pero los beneficios pueden ser muchos.

    Invertir tiempo en la planificación y el mantenimiento de una política de branches que cubra nuestras necesidades pero que a la vez no se descontrole puede no ser fácil, pero seguramente permitirá reducir llamados de nuestros clientes enviando saludos a nuestras hermanas, madres y abuelas porque la entrega de la última versión, con aquellos fantásticos nuevos features, revivió bugs que habían sido ya solucionados.

    Glosario

    Development Branch con los cambios de la próxima versión
    Main Es la conjunción de los branches Development y Release. Representa un “foto” estabilizada del producto que podría ser compartida, por ejemplo, con el equipo de QA
    Service Pack Una colección de bug fixes que apuntan a la última versión liberada
    Release Un branch sobre el que se hacen cambios de último momento o bug fixes de alta prioridad
    Forward Integrate (FI) Merge desde branches padres a hijos
    Reverse Integrate (RI) Merge desde branches hijos a padres
    Release Vehicle Es la forma en que el producto llega al cliente

    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.


    ALM, Eventos, Gestión de Proyectos, Metodologías y Procesos, Tecnología , , , , ,

    Cómo forzar la actualización de Datawarehouse de TFS por Victor Passador

    3. febrero 2010

    Al trabajar en la creación de reportes para TFS, con uno de los problemas con los que nos cruzaremos es con el hecho de que los cambios que realicemos en la base de datos de TFS (por ejemplo al crear/modificar Work Items) no se reflejarán inmediatamente en el reporte.

    Esto se debe a que, por defecto, la actualización del Datawarehouse se realiza a intervalos de una hora, ya que es un proceso que consume una cantidad importante de recursos del servidor. Además, al tratarse generalmente de reportes basados en datos estadísticos, contar con información que se actualiza a cada hora es suficiente para la mayoría de los casos.

    Como mencionábamos, esto es válido en un entorno de producción, pero cuando estamos haciendo el ajuste fino de un reporte en un ambiente de pruebas, este lapso no nos sirve y nos encontramos en la necesidad de actualizar el Datawarehouse “on demand”.

    Para esto podemos utilizar un Web Service que, además de ésta, cuenta con otras funcionalidades:

    http://teamserver:8080/Warehouse/v1.0/WarehouseController.asmx

     

    Una vez allí, debemos hacer click en la operación “Run” y luego el botón “Invoke”

    La yapa

    Si  son lo suficientemente impacientes como para pretender algo más cómodo, los voy a invitar a que lean el post de Eric Lee donde publica una pequeña aplicación que realiza esto mismo pero con sólo presionar un botón.

     

    ALM, TFS ,

    Nueva area de recursos sobre ALM y SharePoint por Daniel Laco

    4. febrero 2009

    Una nueva area en el sitio de MS sobre Sharepoint y ALM.

    Se acaba de publicar el Application Lifecycle Management Resource Center for SharePoint Server

    Aqui se pueden encontrar guias, articulos, links, herramientas sobre todo lo relacionado con ALM y Sharepoint.

    Hay temas como:

    • Templates para Visual Studio
    • Control de código fuente.
    • Testing
    • Builds
    • TFS
    • Etc. etc. etc.

     

    Sharepoint-ALM

     

    ALM, Gestión de Proyectos, Metodologías y Procesos, Sharepoint ,

    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

    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.

     

     

     

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