Proyecto de Tópicos Selectos de Programación...

Bibliografía extendida of 34

file://\\Yolanda\yolanda\my web page\bibliografia.htm 5/26/03

Centro de Investigación en Matemáticas, A. C.

Proyecto de Tópicos Selectos de Programación II

Bibliografía extendidaYolanda de Lira Domínguez

Temas de Investigación:

CMMI CMMI vs. CMM CMMI vs. SPICE Software Architecture Software Architecture in CMMI



Última fecha de actualización: 16 de Mayo del 2002



Historia de Actualizaciones del Documento

Fecha Versión Descripción Responsable Marzo 16, 2003 1.0 Creación del

documento

Yolanda de Lira Domínguez

Marzo 23, 2003 1.1 Ampliación de documento y actualización de contenido.


Mayo 5, 2003 1.2 Ampliación de documento y actualización de contenido.


Mayo 16, 2003 1.3 Ampliación de documento y actualización de contenido.




Contenido1. Título: CMM vs CMMI: From Conventional to Modern Software Management

Autor (es): Walker RoycePublicación: Provided By The Rational Edgehttp://www.therationaledge.com/content/feb_02/f_conventionalToModern_wr.jspCrítica personal del artículo: (Relevancia 1)

2. Título: The Measurement and Analysis Process Area in CMMIAutor (es): Dave ZubrowPublicación: Provided By SEI – Software Engineering Institutehttp://www.sei.cmu.edu/cmmi/publications/meas-anal-cmmi.htmlCrítica personal del artículo: (Relevancia 2)

3. Título: Evolutionary Differences Between CMM for Software and the CMMIAutor (es): Tim KassePublicación: Provided By SPI Partners –Software Process Improvementhttp://www.spipartners.nl/data/CMM-CMMI.pdfCrítica personal del artículo: (Relevancia 1)

4. Título: Comparación práctica de los modelos de madurez SW-CMM vs CMMIAutor (es): Elizabeth Almeraz y Mariana Pérez VargasPublicación: Provided By Avantarehttp://www.avantare.com/anteriores/ 20v2.pdfCrítica personal del artículo: (Relevancia 1)

5. Título: CMMI ¿Evolución o nuevo modelo?Autor (es): Ing. Alvaro Ruiz MendarozquetaPublicación: ASSE 2002 - http://www.exa.unicen.edu.ar/~asse2002/Crítica personal del artículo: (Relevancia 1)

6. Título: SeguimientoAutor (es): Software Engineering LaboratoryPublicación: Provided By SEL - Software Engineering Laboratoryhttp://www.sel.inf.uc3m.es/iswii/Curso02-03/Teoria/tema5.pptCrítica personal del artículo: (Relevancia 2)

7. Título: Concept of Operations for the Capability Maturity Model IntegrationAutor (es): Carnegie Mellon UniversityPublicación: Provided By Carnegie Mellon Universityhttp://www.grc.nasa.gov/WWW/ITRACK/cmmi.pdfCrítica personal del artículo: (Relevancia 1)



8. Título: CMMI What you need to know!Autor (es): Frank J. KochPublicación: Process Perspectives No. 7 Spring 2002http://www.process-strategies.com/pp_7.htmCrítica personal del artículo: (Relevancia 1)

9. Título: Metrics and the Immature Software ProcessAutor (es): Frank J. KochPublicación: Provided By Q/P Management Group, Inchttp://www.qpmg.com/metrics.htmCrítica personal del artículo: (Relevancia 2)

10. Título: The SEI Capability Maturity ModelAutor (es): Emmanuel R. Baker, Frank J. KochPublicación: Provided By Q/P Management Group, Inchttp://www.qpmg.com/sei.htmCrítica personal del artículo: (Relevancia 1)

11. Título: Defect PreventionAutor (es): Paula AshleyPublicación: Process Perspectives No. 5 Winter 1997http://www.process-strategies.com/pp_5.htmCrítica personal del artículo: (Relevancia 1)

12. Título: PVCS Dimensions supports the CMMIAutor (es): MerantPublicación: Provided By MERANThttp://www.merant.com/Shared/pdfs/dimensions/DimCMMIwp-WP02ECM217.pdfCrítica personal del artículo: (Relevancia 1)

13. Título: Messages from the FieldAutor (es): Mike PhilipsPublicación: Provided By SEI Software Engineering Institutehttp://interactive.sei.cmu.edu/news@sei/columns/cmmi-in-focus/cmmi-in-focus.pdfCrítica personal del artículo: (Relevancia 1)

14. Título: CMMI Myths and RealitiesAutor (es): Lauren HeinzPublicación: Provided By SEI Software Engineering Institutehttp://interactive.sei.cmu.edu/news@sei/features/2002/4q02/pdf/feature-4-4q02.pdfCrítica personal del artículo: (Relevancia 1)

15. Título: SPICE and the CMM: is the CMM compatible with ISO/IEC 15504?Autor (es): Terence P. RoutPublicación: Provided by SQI Software Quality Institutehttp://www.sqi.gu.edu.au/~terryr/aquis98.pdfCrítica personal del artículo: (Relevancia 1)

16. Título: Software architecture: theory and (mostly) practiceAutor (es): Christian GasserPublicación: Provided By UNIFR University of Fribourg



http://www-iiuf.unifr.ch/courses99-00/genie_log/exercices.htmCrítica personal del artículo: (Relevancia 1)

17. Título: The SPICE Project – Past, Present and FutureAutor (es): Terence P. RoutPublicación: Provided by SQI Software Quality Institutehttp://www.sqi.gu.edu.au/~terryr/Sp96_key.PDFCrítica personal del artículo: (Relevancia 1)

18. Título: The CMMI in 45 MinutesAutor (es): Gerold Keefer, Hanna LubeckaPublicación: AVOCA Advanced Visioning of Components Architectureshttp://www.avoca-vsm.com/Dateien-Download/CMMI45Minutes.pdfCrítica personal del artículo: (Relevancia 1)

19. Título: Foundations for the Study of Software ArchitectureAutor (es): Dewayne E. Perry and Alexander L. WolfPublicación: ACM SIGSOFT Software Engineering Notes, 17:4, October 1992http://www.idi.ntnu.no/emner/sif8056/slidesgmy/PerryFoundations92.pdfCrítica personal del artículo: (Relevancia 1)

20. Título: Introduction to the Special Issue on Software ArchitectureAutor (es): David Garlan and Dewayne PerryPublicación: IEEE Transactions on SE, 21 (4), April 1995, pp 269-274http://www.ece.utexas.edu/~perry/work/papers/tse21-4.pdfCrítica personal del artículo: (Relevancia 1)

21. Título: Software Architectures:Relevant parts of SW-CMM, SE-CMM and CMMIAutor (es): Daniel KarlstromPublicación: Provided By LUCAS - Center for Applied Software Researchhttp://www.lucas.lth.se/Internal/architecture/course/CMM.htmlCrítica personal del artículo: (Relevancia 1)



1. Título: CMM vs CMMI: From Conventional to Modern Software Management

Autor (es): Walker Royce

Publicación: Provided By The Rational Edge Internet: http://www.therationaledge.com/content/feb_02/f_conventionalToModern_wr.jsp

Carpeta Local: modernCMMI.pdf

Crítica personal del artículo: (Relevancia 1)

Subjective interpretations of the CMMI Speculation on how organizations will implement various aspects of CMMI Establishment of principles with no scientific basis.

Resumen:

This article summarize some thoughts on making the transition from conventional software management techniques to modern ones by comparing CMM and CMMI.

The CMM’s activity-based measurement approach is very much in alignment with the sequential, activity-based management paradigm of the waterfall process (i.e., do requirements activities, then design activities, then coding activities, then unit testing activities, then integration activities, then system acceptance testing). This probably explains why many organizations’ perspectives on the CMM are anchored in the waterfall mentality. Alternatively, iterative development techniques, software industry best practices, and economic motivations drive organizations to take a more results-based approach: Develop the business case, vision, and prototype solution; elaborate into a baseline architecture; elaborate into usable releases; and then finalize into fieldable releases. Although the CMMI remains an activity-based approach, it does integrate many of the industry’s modern best practices, and it discourages much of the default alignment with the waterfall mentality. It establishes some principles of Conventional (Waterfall) Software Management and other principles of Modern (Iterative) Software Management and identifies which principles in each set are directly motivated by the KPAs of the CMM and the PAs of the CMMI. The CMM has done the software industry a great service by focusing more attention on software process, but after years in the field, it is time for the CMM to



step aside to make way for the new, improved CMMI.

Comentarios Generales:

CMM has some advantages by comparing it with CMMI that’s why in some industries wouldn’t be laudable to make the change.

2. Título: The Measurement and Analysis Process Area in CMMI

Autor (es): Dave Zubrow

Publicación: Provided By SEI – Software Engineering Institute

Internet: http://www.sei.cmu.edu/cmmi/publications/meas-anal-cmmi.html

Carpeta Local: meas-anal-cmmi.pdf


Interesting aspects of including Measurement and Analysis as a Process Area in CMMI Very specific viewpoint because it refers to only one Process Area.

Resumen:

This article explains the improvement in CMMI about Measurement and Analysis.

One new feature contained in CMMI is the Measurement and Analysis process Area. “The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs”

Whereas in the software CMM measurement and analysis was only a component of institutionalizing a process, within the CMMI it is a process in its own right and therefore must be institutionalized along with the other work processes.

The challenges and benefits of this new CMMI process area to organizations that have been following the Software CMM are threefold. First, the model calls for a



consistent measurement process or approach, at least at a high level. Furthermore, the first step is to identify the purpose and use of measurement and analysis. Second, to effectively implement measurement and analysis will require integration of measurement into the other work processes of the organization. Third, organizations will need to institutionalize their measurement and analysis activities.


Measurement and Analysis is very important if we want to improve our performance because we can know how better we are according to past results, so, I think including it as a Process Area is a great advantage.

3. Título: Evolutionary Differences Between CMM for Software and the CMMI

Autor (es): Tim Kasse

Publicación: Provided By SPI Partners –Software Process Improvement

Internet: http://www.spipartners.nl/data/CMM-CMMI.pdf

Carpeta Local: CMM-CMMI.pdf


Analyzes all the Process Area in CMMI Objective comparison between both models.

Resumen:



It explains important aspects of the evolution of CMM into CMMI, for each Process Area in CMMI. Some of those aspects are:

Bi-Directional Traceability is now explicitly asked for in Requirements Management

Includes a focus on the project having the necessary Knowledge and Skills to execute the project according to the estimations and plan

Monitoring Risk and Stakeholder Involvement is more strongly emphasized in the CMMI compared to the SW-CMM

An organization that barely passes the Measurement and Analysis common Feature requirements of CMM for Software would not pass the measurement requirements of CMMI

Technical solution practices apply not only to the product and product components but also to services and product-related processes

Verification is used to assure that selected work products meet their specified requirements

Decision and Analysis presents the concepts of identifying alternatives to issues that have a significant impact on meeting objectives, analyzing the alternatives, and selecting one or more alternatives that best support prescribed objectives.

Integrated Project Management takes on the aspects of Integrated Software Management and Intergroup Coordination that were found in the SW-CMM

Quantitative Process Management combines the concepts of Quantitative Process Management and Software Quality Management from the SW-CMM point of view.


I mentioned just the Process Areas that I considered as the most important, but in the paper there is a brief explanation for each Process Area.

4. Título: Comparación práctica de los modelos de madurez SW-CMM vs CMMI

Autor (es): Elizabeth Almeraz y Mariana Pérez Vargas

Publicación: Provided By Avantare

Internet: http://www.avantare.com/anteriores/UN COMPARATIVO PRACTICO DELOS MODELOS DE MADUREZ v2.pdf



Carpeta Local: comparativo.pdf


Se enfoca en gran parte en las desventajas que tiene CMMI sobre SW-CMM al tratar de

hacer la transición en empresas pequeñas.

Resumen:

Presenta un panorama general y un comparativo sobre los dos modelos de madurez del SEI que han tenido más aceptación para las organizaciones y áreas que se dedican al desarrollo del software con el fin de que el lector se forme una idea de la razón de ser de los mismos, la audiencia hacia la cual están enfocados y los aspectos que cubren. El enfoque del SW-CMM está orientado en generar, implantar y mejorar las prácticas de Ingeniería de Software, considerando al desarrollo de software como su producto principal. El modelo del CMMI tiene el propósito de proporcionar una guía unificada para la mejora de múltiples disciplinas tales como ingeniería de sistemas, ingeniería de software, etc., lo cual no resulta útil para empresas pequeñas cuya única disciplina es Ingeniería de Software. Actualmente no hay muchas organizaciones que hayan adoptado o estén haciendo la transición hacia el nuevo modelo. La comunidad internacional pide que se mantengan los dos modelos, se libere la versión 2 del SW-CMM que esta en versión borrador y permitir que el mercado decida que modelo usar de acuerdo a sus necesidades. El éxito del proyecto no está en la selección de un modelo en particular, sino en establecer un programa de mejora que establezca nuevas prácticas y disciplinas de trabajo para el desarrollo de software utilizando un modelo como un marco de referencia que ayude a las organizaciones a lograr sus objetivos de negocio. Lo recomendable es que éste sea reconocido mundialmente con el objetivo de ser comparable con otros proveedores en mercados internacionales.

Comentarios generales:

Es un buen punto el considerar pequeñas organizaciones (ya que en México así son la mayoría de las organizaciones), pero en realidad no sé que tan factible sea lo que se pide, es decir, liberar la versión 2 del SW-CMM, ya que el propósito principal del CMMI es integrar todos los modelos CMM existentes.

5. Título: CMMI ¿Evolución o nuevo



modelo?

Autor (es): Ing. Alvaro Ruiz Mendarozqueta

Publicación: ASSE 2002

Internet: http://www.exa.unicen.edu.ar/~asse2002/

Carpeta Local: ASE2002CMMI.ppt


Presenta un panorama muy general de lo que es el modelo CMMI y sus ventajas frente al modelo CMM.

El título del artículo está en español pero el contenido está en inglés

Resumen:

Explica de manera general que CMM es un modelo de referencia con prácticas en disciplinas específicas usadas para asignar la capacidad de un grupo para desarrollar esa disciplina. Debido a la popularidad del modelo, se crearon otros modelos de CMM para diferentes usos. CMMI surgió con el fin de integrar dichos modelos que cubren las disciplinas de Ingeniería de software, Ingeniería de sistemas, Procesos y productos integrados y Desarrollo entre otras. CMMI es un modelo de procesos o una colección estructurada de elementos que describe características de procesos probados por experiencia con efectividad. Te dice que hacer, pero no como hacerlo. Comparándolo con CMM, CMMI tiene más objetivos y prácticas, es un modelo significativamente más grande que CMM, tiene más detalles y más arreas de procesos, además que es aplicable más que a sólo software, tiene mejor cubrimiento de áreas y su modelo continuo permite a organizaciones madurar de manera más relevante a los negocios. Entre las desventajas de CMMI podemos mencionar que su tamaño es mucho más grande que CMM, es más difícil ser un asesor de entrenamiento. No hay manera de estimar en que nivel de CMMI estará una empresa dado que se conoce su nivel en CMM.




La información que se presenta en este artículo es muy similar a la que se presenta como introducción en alguno de los artículos antes descritos, por lo que me pareció un poco redundante.

6. Título: Seguimiento

Autor (es): Software Engineering Laboratory

Publicación: Provided By SEL - Software Engineering Laboratory

Internet: http://www.sel.inf.uc3m.es/iswii/Curso02-03/Teoria/tema5.ppt

Carpeta Local: tema5[2].ppt


En el artículo en sí no presenta información acerca de los autores ni de la organización que lo elabora.

Resumen:

Es una presentación que trata del seguimiento de un proyecto: que es, por qué es importante y donde debe comenzarse a hacer seguimiento de un proyecto. Seguimiento de un proyecto es el proceso de obtención de análisis de información acerca del progreso, estado y trayectoria. El seguimiento de un proyecto es una de las actividades más importantes para ejercer control del mismo. Es una actividad ubicada después de la planificación de proyectos. El propósito del seguimiento es facilitar una visión adecuada del progreso real, de forma que la dirección pueda tomar unas medidas eficaces cuando el desarrollo del proyecto software se desvía notablemente de los planes software. Existen diferentes tipos de seguimiento: En función de la duración (a corto o a largo plazo) y en función de la actuación (estático, dinámico o predictivo) Las fases del seguimiento de un proyecto son: obtención de información, análisis, comparación y acción correctora (si procede). Es una acción que realiza el jefe de proyecto. Se evalúa la dificultad de producto o



proceso, la productividad del equipo, la aportación de tácticas y método. Se hace inmediatamente después de hacer la planificación detallada, y periódicamente se deberán recoger medidas de avance para ver diferencias. El modelo CMMI cuenta con un área llamada Control y seguimiento del proyecto que se encarga de hacer seguimiento del proyecto, de monitorización del mismo y de realizar acciones correctivas.


Me pareció interesante la información presentada en el artículo, aunque es demasiado específico al presentar una sola área del modelo CMMI

7. Título: Concept of Operations for the Capability Maturity Model Integration

Autor (es): Carnegie Mellon University

Publicación: Provided By Carnegie Mellon University

Internet: http://www.grc.nasa.gov/WWW/ITRACK/cmmi.pdf

Carpeta Local: cmmi.pdf


I think information presented in this article is very interesting because the most important aspects about CMMI are explained in a clear and brief way.

Resumen:

The concept of Operations (CONOPS) for the CMMI product suite includes the background and description of the CMMI, the process for using the CMMI, the scenarios for use, the process for maintenance and support and the approach for adding new disciplines. To improve the efficiency of model use and increase the return on investment, the CMMI project was created to provide a single integrated set of models. Initially, the CMMI project includes the disciplines of systems engineering, software engineering and Integrated Product and Process Development (IPPD). A Capability Maturity Model delineates the characteristics of a mature, capable process. It identifies the practices that are basic to



implementing effective processes as well as advanced practices. It also assigns to those practices associated maturity levels ranging from unrepeatable to a mature, well-managed process. In response to a perceived crisis in software development related to escalating software cost and quality problems, the Department of Defense established the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pennsylvania in the early 1980s. SEI began the development of a process improvement model for software engineering in 1988. In August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI. Additional CMMs were also developed, including the Software Acquisition CMM, the People CMM, and the integrated Product Development CMM. Some business domains have also produced their own CMMs. As the SW-CMMs Version 2.0 was completing its review process, OSD (Office of the Secretary of Defense) directed that the CMMI project be undertaken as a collaborative industry government and SEI effort and that the CMM Version 2.0 be cancelled as a stand-alone CMM and replace by the software version of the CMMI product suite. There are two representations for CMMI: the staged and continuous representations. An organization would choose the particular model and representation that meet of their particular requirements, business disciplines, and roles. Each model set can be created in either staged or continuous representations. The difference between the representations is purely structural, with regard to the way the model context is packaged.


This article presents so many details which are no mentioned in other articles, for example, what to do if you want to add a new discipline to CMMI

8. Título: CMMI What you need to know!

Autor (es): Frank J. Koch

Publicación: Process Perspectives No. 7 Spring 2002

Internet: http://www.process-strategies.com/pp_7.htm

Carpeta Local: PP_7.pdf


Excellent structure of the article Use of a restricted Natural Language vocabulary



Resumen:

The CMMI contains the essential elements of effective processes for specific disciplines. After the SW-CMM was released in 1991, the SEI developed maturity models for several other disciplines, including systems engineering, acquisition, workforce management and integrated product development. Although each model was focused on a particular discipline, there was considerable overlap in content. Further, two different structural representations were used: the systems engineering model used a “continuous” structure; the other models used a “staged” structure The major changes found in the CMMI fall into three categories: disciplines covered, maturity levels and process areas, and model structure. The most obvious change is that the CMMI covers multiple bodies of knowledge or “disciplines”. Currently the CMMI addresses four disciplines: Software Engineering (SW), Systems Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS). The CMMI’s maturity levels have the same definitions as in the earlier models, although some changes to the names of the levels were made. The representations primarily differ in how they are organized and presented: Staged Representation and Continuous Representation. In Staged Representation each process area is associated with one of five maturity levels. In the continuous Representation maturity levels do not exist. Both representations recognize that the process areas may be grouped into four general categories: project management, engineering, support, and process management.


This article mentions that the representations of CMMI differ in how they are organized and presented and it is the same idea expressed in the past article.

9. Título: Metrics and the Immature Software Process

Autor (es): Frank J. Koch

Publicación: Provided By Q/P Management Group, Inc



Internet: http://www.qpmg.com/metrics.htm

Carpeta Local: metrics.htm


Interesting viewpoint about the software metrics Use of a restricted Natural Language vocabulary

Resumen:

There has been much discussion in recent years about the role of software metrics in helping software organizations improve productivity and quality. Software measurement satisfies two sets of objectives. The first relates to project management, the second addresses organizational needs. According to the Software Engineering Institute (SEI) 75% of the organizations who have assessed their software process relative to the SEI’s Capability Maturity Model for Software (CMM) are functioning at Level 1. According to Jim Clemmer, in Firing on all Cylinders, “The key of the effective measurement of service/quality is a small number of simple measures that channel the organization’s energy and focus on the strategic areas with the highest potential return”. For a software organization with a Level 1 process, this translates to four basic measures: software size, project cost, project schedule, and defect counts. Two commonly used size measure are lines of code (LOC) and functions points (FP). LOC, a tradition of software engineering organizations, requires an accurate internal view of the system. The FP method, more popular in information systems organizations, is based on an external view of the system, as seen by the user. Measuring software quality by counting defects may be more problematic. Implementing software metrics is not the faint of the heart of those easily discouraged. However, by keeping your measurement program simple, relevant, and an integral part of your process and by measuring only stable and defined processes, your organization can start to achieve the benefits of a quantitative software quality management system.


The author is very objective in his comments, but the information presented here is very short.



10. Título: The SEI Capability Maturity Model

Autor (es): Emmanuel R. Baker, Frank J. Koch

Publicación: Provided By Q/P Management Group, Inc

Internet: http://www.qpmg.com/sei.htm

Carpeta Local: Articulos/sei.htm


Information is good when you don’t know anything about CMM.

Resumen:

In 1991 the Software Engineering Institute (SEI) at Carnegie Mellon University introduced the Capability Maturity Model for Software (CMM) This event marked a major milestone in the evolution of software process management because, for the first time, the software community had a comprehensive description of how software organizations “mature”, or improve, in their ability to develop software. The CMM defines five levels of process capability, each of which represents an evolutionary plateau towards a disciplined, measured, and continuously improving software process: initial, repeatable, defined, managed, and optimizing. Many leading software organizations are adopting the CMM as their core strategy for improving quality and productivity. Although the CMM is not perfect, it is very useful. How can the CMM help your organization? There are three key roles the CMM plays. First, the CMM helps build an understanding of software process by describing the practices that contribute to a level of process maturity. The second role of the CMM is to provide a consistent basis for conducting appraisals of software processes. The third key role is to serve as a blueprint for software process improvement.


Although most of the content in this article had been reviewed in class, it was interesting analyzing another view point.



11. Título: Defect Prevention

Autor (es): Paula Ashley

Publicación: Process Perspectives No. 5 Winter 1997

Internet: http://www.process-strategies.com/pp_5.htm

Carpeta Local: pp_5.htm


Interesting relationship between defect prevention and CMM Defect prevention could be treated in a lower level than level 5 in CMM.

Resumen:

So many persons think that Level 5 of the CMM is just too expensive and that there is not enough payback for instituting the Level 5 goals to warrant their expense. When questioning some holders of this opinion, it seems that their belief is that causal analysis must be performed on all the defects revealed by the peer review or Fagan inspection process. Typical root causes of defects listed in the CMM are:

Inadequate training Breakdown of communications Not accounting for all the details of the problem Making mistakes in manual procedures

For some reason typical root causes appear to be subjective opinions about why people make mistakes.



Causal analysis can positively engage developers in the quest for continuous improvement. This improvement benefits each individual who learns how to do his or her job better and the team which wants to deliver quality products cost effectively.


After read this article I knew how important is to have an adequate process to avoid making a mistake.

12. Título: PVCS Dimensions supports the CMMI

Autor (es): Merant

Publicación: Provided By MERANT

Internet: http://www.merant.com/Shared/pdfs/dimensions/DimCMMIwp-

WP02ECM217.pdf

Carpeta Local: DimCMMIwp-WP02ECM217.pdf


Focused in promoting the PVCS Dimensions tool. Objective comments about CMMI

Resumen:

The CMMI is the most recent evolution of the SEI’s CMM model and is expected to produce new levels of return-on-investment results. MERANT’s PVCS Dimensions is an integrated, flexible and scaleable system for change management of software intensive systems, and is well suited to supporting the efforts of organizations to achieve CMMI.



This paper provides an in-depth look at how Dimensions complements your CMMI efforts. PVCS Dimensions is a complete CM toolset designed for small and large, software intensive systems. One of its strengths is that it helps organizations manage and automate the best practices included in the CMMI’s configuration management process area. Most other CM tools are composed of separate products and separate repositories; one for configuration item and baseline management, and one for change tracking and control. The CMMI offers great value to organizations that are developing software intensive systems. CMMI compliance is likely for companies hoping to develop systems and/or software for major DoD projects. Configuration Management is an important CMMI Process Area, and it must be implemented using an automated tool. PVCS Dimensions provides integrated functions to manage systems. Dimensions provides comprehensive support for the all Configuration Management goals and practices.


It is important to know that there are some tools, as PVCS Dimensions, which can support CMMI.

13. Título: Messages from the Field

Autor (es): Mike Philips

Publicación: Provided By SEI Software Engineering Institute

Internet: http://interactive.sei.cmu.edu/news@sei/columns/cmmi-in-focus/cmmi-in-

focus.pdf

Carpeta Local: cmmi-in-focus.pdf


Some topics in this article are very interesting but the information about them is too short.



Resumen:

This article summarizes some of the messages about CMMI received for the author, who is the Director of Special Projects at the SEI and the comments the author has about this messages. Some of those messages refers to:

If we compare CMM with CMMI, we have that CMMI offers modernization, greater clarity and expanded breadth of coverage.

Some innovative uses of CMMI have come to attention. For

example CMMI has been used to examine the approach of an organization to life-cycle management.

Government participation in scheduled improvement appraisals

offers a way to address the need for ensuring a level playing field of contractors for government procurement of software intensive systems, while giving the confidence associated with government involvement.

Pending a further update to CMMI models, likely a few years

away, organizations are encouraged to use the flexibility of the Microsoft Word versions of CMMI models to insert a typical work products or subpractices that cover elements in the organization that have not seen their material included in the informative components of CMMI models.


CMMI is so new, and I think this is the reason because of there are many questions about it.

14. Título: CMMI Myths and Realities

Autor (es): Lauren Heinz

Publicación: Provided By SEI Software Engineering Institute



Internet: http://interactive.sei.cmu.edu/news@sei/features/2002/4q02/pdf/feature-4-

4q02.pdf

Carpeta Local: feature-4-4q02.pdf


It presents different viewpoints about the myths. Interesting diversity of viewpoints.

Resumen:

There are many myths about upgrading from the SW-CMM to a CMMI model. Some of these myths are: “CMMI is too big and complex”, “A CMMI appraisal takes longer and costs more than an appraisal for SW-CMM” and “CMMI is only for large organizations”. The reality for these myths is:

“CMMI is too big and complex”

The evolution of the CMM concept naturally grew into the development of the CMMI product suite, which places proven practices into a structure that helps an organization appraise its organizational maturity and process capability, establishes priorities for improvement, and guide the implementation of these improvements. But the CMMI models can seem a bit daunting.

“A CMMI appraisal takes longer and costs more than an appraisal for SW-

CMM”

The reality us that the two appraisal methods have some subtle significant differences that make such direct comparisons less than useful

“CMMI is only for large organizations”

Many smaller organizations aren’t interested in using CMMI to benchmark themselves against other organizations. They don’t need to commit to all the process areas and practices. CMMI is designed so they can pick and choose among the Pas that have the most immediate applicability to them


This article is inconsistent with the article “Comparación práctica de los modelos de madurez SW-CMM vs CMMI”, because in the last one the autor says that CMMI is just for big organizations.



15. Título: SPICE and the CMM\: is the CMM compatible with ISO/IEC 15504?

Autor (es): Terence P. Rout

Publicación: Provided by SQI Software Quality Institute

Internet: http://www.sqi.gu.edu.au/~terryr/aquis98.pdf

Carpeta Local: aquis98.pdf


Most of the information in this paper, is known for me, because I saw it in class.

Resumen:

The software Capability Maturity Model is the best known and most widely adopted of current model, has been examined to identify barriers to achievement of compatibility with ISO/IEC 15504. Terence P. Rout presents an analysis of the parameters that will have to be addressed in order to demonstrate compatibility of the CMM with ISO 15504. CMM is a model and SPICE is a reference Model. A compatible model must provide a formal and verifiable mechanism for converting data collected against the model into a set of process attribute ratings for each Reference Model process directly or indirectly assessed. The basis of assessment in ISO 15504 is different from that in CMM based assessment. After make a mapping to SPICE into CMM, the author obtained the following information: The goals of the CMM do not map clearly or unambiguously to the process and process attributes of the Reference Model.


I think SPICE and CMM are no compatibles, maybe is difficult for an organization to follow both models.



16. Título: Software architecture: theory and (mostly) practice

Autor (es): Christian Gasser

Publicación: Provided By UNIFR University of Fribourg

Internet: http://www-iiuf.unifr.ch/courses99-00/genie_log/exercices.htm

Carpeta Local: Elca_g_l_14.4.00.pdf


It presents some practical examples and makes analogies with real world situations. I like it because I can understand the main idea easier.

Resumen:

Christian Gasser explains what Software Architecture is, why it is important and presents some approach about Software Architecture. In the real world, if we have a complex problem, we solve it with designed and built by teams, proven modeling techniques, Precise measurement, Well-defined processes, Power Tools and Standards. Software Architecture makes something similar. He explains the architect’s activities in each one of the principal stages of the software production. The architect creates a vision, makes decisions, coaches, coordinates, implements, advocates and he is the key technical consultant and is also often the project leader.

Software architecture is a management tool, because it can be useful to manage functionality, performance, complexity, change, IT resources and technology. Software architecture helps to ensure the long-term coherency of the system’s evolution.




Although all the information in the paper is interesting, this is too big and complex to understand.

17. Título: The SPICE Project – Past, Present and Future

Autor (es): Terence P. Rout

Publicación: Provided by SQI Software Quality Institute

Internet: http://www.sqi.gu.edu.au/~terryr/Sp96_key.PDF

Carpeta Local: Sp96_key.pdf


SPICE structure is not presented in this paper. Very short an vague conclusion.

Resumen: The SPICE Project is an international collaborative effort to support the development of a new international standard for software process assessment. The project was stablished by the international committee on software engineering standards ISI/IEX JTC/SC7, through its Working Group 10 on software process assessment, in January 1993.



The increasing number of assessment approaches available, and the increasing use of the technique in commercially-sensitive areas, were the key motivating factors behind the development and acceptance of a proposal to develop an International Standard for software process assessment. The intent of the SPICE project is that results of conformant assessment can be equally applied to either internal process improvement, or to the demonstration of capability by a supplier to a prospective purchaser. The model as defined was highly complex, and it was one feature criticized in the reports from the SPICE Trials. A number of other factors related to the architecture were also criticized. As a result, a comprehensive restructuring of the architecture took place, resulting in a new structure based upon a different concept of the assessment model – one based on the concept of a reference model. The concept of a reference model is one which is widely used within the standards community, particularly where there is a need for harmonization of different approaches to a problem or group of problems. Any project is a temporary endeavor with clear goals and objectives, and a definite ending point. The SPICE Project is no exception to this, though its ending point has not been clearly specified.


SPICE is a reference model, and this is one difference between SPICE and CMM, because CMM is a model.

18. Título: The CMMI in 45 Minutes

Autor (es): Gerold Keefer, Hanna Lubecka

Publicación: AVOCA Advanced Visioning of Components Architectures

Internet: http://www.avoca-vsm.com/Dateien-Download/CMMI45Minutes.pdf

Carpeta Local: CMMI45Minutes.pdf


Interesting Diagram about Software Quality Standards and Models between 1985 and 2005.

Interesting comparison between both CMMI representations.



Resumen: With the release of the CMMI, the SEI puts a preliminary end to a journey started in the mid-nineties: After of the SW-CMM v1.1 in 1993 the efforts to issue version 2.0 were abandoned in favor of a general purpose CMM that would integrate several disciplines. At least two goals were clear beyond the need for integration at the beginning of the CMMI development:

The staged maturity levels prevented the CMM from delivering the flexibility need in many organizations that have to adjust their process improvement to their business goals and not vice versa.

The transition of organization that used CMM v1.1 in the past to the CMMI should be as easy as possible to protect the considerable investments made so far.

The solution to those challenges was one model and two representations: staged and continuous. The continuous representation is clearly more flexible in that it allows for a much more fine grained improvement strategy that aligns with the overall goals of the respective organization. It should also be noted that the continuous representation is likely to be more compatible to ISO 15504/SPICE type assessments. The staged model in contrast is the preferred model for organizations that want to migrate from CMM v1.1 to the CMMI with minimum overhead.


After read this paper, I understood better the difference between staged and continuous representations of the CMMI.

19. Título: Foundations for the Study of Software Architecture

Autor (es): Dewayne E. Perry and Alexander L. Wolf

Publicación: ACM SIGSOFT Software Engineering



Notes, 17:4, October 1992 Internet: http://www.idi.ntnu.no/emner/sif8056/slidesgmy/PerryFoundations92.pdf

Carpeta Local: PerryFoundations92.pdf


This article is relatively old (1992), and the information there seems new for the authors, for now, I think is well known for people in the area.

Resumen: The term “architecture” in contrast to “design” is used to evoke notions of codification, of abstraction, of standards of formal training and of style. Some of the benefits we expect to gain from the emergence of software architecture as a major discipline are:

Architecture as the framework for satisfying requirements Architecture as the technical basis for design and as the managerial basis

for cost estimation and process management Architecture as an effective basis for reuse Architecture as the basis for dependency and consistency analysis.

There are a number of interesting architectural points in building architecture that are suggestive for software architecture:

Multiple views Architectural styles Style and engineering and Style and materials.

By analogy to building architecture, authors propose the following model of Software Architecture: Software Architecture = { Elements, Form, Rationale}

That is, a software architecture is a set of architectural elements that have a particular form. Three different classes of architectural elements are distinguished: processing, data and connecting elements. Form consists of weighted properties and relationships. Rationale captures the motivation for the choice of architectural style, the choice of elements, and the form.


The model of Software Architecture proposed in this article, is one of the most common models used actually.



20. Título: Introduction to the Special Issue on Software Architecture

Autor (es): David Garlan and Dewayne Perry

Publicación: IEEE Transactions on SE, 21 (4), April 1995, pp 269-274

Internet: http://www.ece.utexas.edu/~perry/work/papers/tse21-4.pdf

Carpeta Local: tse21-4.pdf


The format of the article is not appropriate, because you can’t identify the main points there.

Resumen: Software Architecture is the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. While the application of good architectural design is becoming increasingly important to software engineering practice, the fact remains that much of common practice leads to architectural designs that are informal, ad hoc, unanalyzable, unmaintainable and handcrafted. This has the consequences that architectural designs are only vaguely understood by developers; that architectural designs cannot be analyzed for consistency or completeness; that architectures are not enforced as a system evolves; and that there are virtually no tools to help the architectural designers with their tasks. Research in software architecture is attempting to address all of these issues. Among the more active areas are: Architecture Description Languages, formal Underpinnings of Software Architecture, Architectural Analysis Techniques, Architectural Development Methods, Architectural Recovery and Re-Engineering, Architectural Codification and Guidance, Tools and Environments for Architectural Design and Case Studies.


It was very difficult for me understanding this paper, because there are many



concepts that I had never seen, that’s why I focused my attention in the interesting points for the research.

21. Título: Software Architectures\:Relevant parts of SW-CMM, SE-CMM and CMMI

Autor (es): Daniel Karlstrom

Publicación: Provided By LUCAS - Center for Applied Software Research

Internet: http://www.lucas.lth.se/Internal/architecture/course/CMM.html

Carpeta Local: CMM.html


This paper is too short, and most of the content there is about the integration of SW-CMM and SE-CMM into CMMI model.

Resumen: The CMMI v1.0 2000 project has been based on an integration of the SW-CMM and the PIID-CMM v0.98. The CMMI is available in both a staged and a continuous format to cater for companies used to the SW-CMM or the SE-CMM. Rationale is the area of the software architecture covers parts of the SW-CMM and SE-CMM models that are relevant to software architecture. As these two models have recently been integrated into the CMMI, this model is also relevant. The models contain practices related to software architecture. These practices and their effect on the architecture are interesting for the LUCAS software architecture study. The parts of the CMMI model that deal with architecture and the definitions of architecture relevant to this area are:



Level 2 Project Planning (PP) Level 3 Requirements Development (RD) Level 3 Technical Solution (TS) Level 3 Product Integration (PI) Defines “functional architecture” as: The hierarchical arrangement of functions, their internal and external functional interfaces and external physical interfaces, their respective functional and performance requirements and design constraints


I didn’t find another paper with the relationship between the Capability Maturity Models and software architecture. This is not a paper, but the information there was very useful for me.

Proyecto de Tópicos Selectos de Programación...

Documents

Transcript of Proyecto de Tópicos Selectos de Programación...