Re: [spc-l] Diferencia entre Metodología de desarrollo de software y Proceso de desarrollo de software

[Erick Fernando Rubio Mendoza]

Hola,

Parte una definición básica que Metodología es Proceso + Lenguaje.

En este caso por ejemplo RUP: Es un Proceso de Desarrollo, que se usa con el lenguaje UML.

En el caso por ejemplo de waterfall, proceso ya en desuso, también es un proceso de desarrollo, que fue usado con diversos lenguajes:IDEF, UML, etc

El caso de CMMI, es distinto, es un modelo de capacidad de madurez, mide mas o menos que nivel de madurez tiene tu empresa dividido en varios niveles del 1 al 5, y para llegar a cada uno de esos niveles podrías usar cualquier proceso y lenguaje, entiéndase metodología.

Por ejemplo hay ejemplos y artículos sino mal recuerdo en rational edge, que comentaban que podía adquirirse CMMI nivel 2 y 3 utilizando RUP.

Saludos,

El 6 de diciembre de 2013 07:22, Luis CC <luisce...@gmail.com> escribió:

Estimados amigos, el que escribe es un estudiante y tengo una duda respecto a estos 2 conceptos y donde quedarían enmarcados: Agile, Scrum, RUP, Waterfall, CMMI, XP

Esto después de haber encontrado muchos conceptos vagos, contradictorios o ambiguos. 

- Metodología de desarrollo de software

- Proceso de desarrollo de software

Luis CC

--
--
Para enviar mensajes al grupo: sp...@googlegroups.com
Para retirarse del grupo: spc-l-un...@googlegroups.com
Para mas opciones: http://groups.google.com/group/spc-l?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Sociedad Peruana de Computación (SPC)" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spc-l+un...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Abraham Eliseo Dávila Ramón]

Holas

La ISO ha realizado un esfuerzo en este tema de las definiciones que siempre es bueno tomar en cuenta. Claro está que existe y siempre existirán personas y organizaciones que les den otra acepción o lo usen de una manera diferente y que con el tiempo pueden que lleguen a ser incorporada a nivel de la ISO o simplemente no se acepten y queden dispersos por ahí.

Ahí va las definiciones tomadas de la ISO/IEC 24765:2010:

3.1765  methodology

1. a system of practices, techniques, procedures, and rules used by those who work in a discipline. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition. 

2. specification of the process to follow together with the work products to be used and generated, plus the consideration of the people and tools involved, during an IBD development effort. ISO/IEC 24744:2007, Software Engineering — Metamodel for Development Methodologies.3.2 

NOTE A methodology specifies the process to be executed, usually as a set of related activities, tasks and/or techniques, together with the work products that must be manipulated (created, used or changed) at each moment and by whom, possibly including models, documents and other inputs and outputs. In turn, specifying the models that must be dealt with implies defining the basic building blocks that should be used to construct.

3.2217 process

1. set of interrelated or interacting activities which transforms inputs into outputs. ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle processes.4.16; ISO/IEC 15939:2007, Systems and software engineering — Measurement process.3.32. 

2. a predetermined course of events defined by its purpose or by its effect, achieved under given conditions. ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.01.01.24. 

3. to perform operations on data. 

4. a collection of steps taking place in a prescribed manner and leading to an objective. ISO/IEC 15414:2006, Information technology — Open  distributed processing — Reference model — Enterprise language.6.3.5. 

5. in data processing, the predetermined course of events that occur during the execution of

all or part of a program. ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.01.01.25. 

6. an executable unit managed by an operating system scheduler. 

7. system of activities, which use resources to transform inputs into outputs. ISO/IEC 25000:2005, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE.4.41 

NOTE [ISO 9000:2005] The term ""activities"" covers use of resources. A process may have multiple starting points and multiple end points. The prescribed manner may be a partially ordered sequence. A process specification can be a workflow specification. An enterprise specification may define types of processes and may define process templates.

De lo anterior, se puede entender que una metodología es una especificación de proceso o una instancia de proceso o una concreción del mismo. Sin embargo no se puede asegurar que toda especificación de proceso sea necesariamente una metodología; pues dependerá en realidad mucho del nivel de abstracción (o nivel de detalle) de la especificación.  Te paso otras definiciones que pueden resultar útiles o necesarias.

3.1587 life cycle

1. evolution of a system, product, service, project or other human-made entity from conception through retirement. ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering — Software life cycle processes.4.16, ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle processes.4.11. 2. the system or product evolution initiated by a perceived stakeholder need through the disposal of the products. IEEE Std 1220-2005 IEEE Standard for the Application and Management of the Systems Engineering Process.3.1.20

3.1589 life cycle model

1. framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding. ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering — Software life cycle processes.4.16, ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle processes.4.12. Syn: life-cycle model

3.1590 life cycle processes

1. a set of interrelated activities that result in the development or assessment of software products. IEEE Std 1012-2004 IEEE Standard for Software Verification and Validation.3.1.18; IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation.3.1.18. Syn: life-cycle processes NOTE Each activity consists of tasks. The life cycle processes may overlap one another. For V&V purposes, no process is concluded until its development products are verified and validated according to the defined tasks in the Software Validation and Verification Plan.

Sugiero que descargues y revises la NTP-ISO/IEC 12207 Tecnología de la información. Procesos del ciclo de vida del software que puedes hacerlo desde (http://ctn-issi.pucp.pe/normas-tecnicas-peruanas) buscando la norma vigente de 12207 o buscarlo en el portal de INDECOPI; que es una de las pocas que puedes descargar libremente.

Sí bien RUP y CMMI son principalmente marcos de trabajo ambos cubren gran parte de la ISO/IEC 12207 y se acercan más al nivel de procesos. En particular RUP que es Rational Unified Process es una propuesta de procesos; pero que si tiene algunos elementos de proceso establecidos de modo que pueden terminar decantando una metodología (de ahí es que viene mucha confusión). CMMI en realidad es un modelo de capacidad y evaluación, siendo muy popular el enfoque escalonado (por ser más comercial) de niveles de madurez organizacional del 1 al 5; pero tiene otro que se denomina de manera continua y que es por capacidad de proceso. CMMI cumple 12207.

En caso de Scrum, XP y Waterfall encajan más por el lado de metodologías y por cierto muchos de ellos cumplen con 12207. El caso de Agile es más una corriente o filosofía o llamada de atención sobre el que se existen varias propuestas metodológicas algunas muy formales y otras menos formales, teniendo como referente lo que conocen como el manifiesto ágil. 

Un comentario final. A veces, y me parece que es una de las fallas fundamentales de las personas que dirigen proyectos, la gente olvida que las metodologías o procesos son propuestas y que NO son necesariamente letras en piedra dejando el CRITERIO y RESPONSABILIDAD de las decisiones como algo de segundo o incluso tercer nivel de importancia. Un buen gestor de proyecto debe tener muy claro que una metodología (o forma de trabajo) debe incrementar la productividad y calidad del trabajo; pero cuando ello no se cumple DEBE usar su buen CRITERIO profesional para hacer ligeros ajustes de modo que el proyecto sea mejor encaminado. Claro que existen escenarios más complejos y menos recomendables para pensar en hacer cambios (como desarrollar software de misión crítico por ejemplo para aeronaves); pero en la gran mayoría de casos si puede ser una opción. En función a este contexto (claro a veces no saben de esto, pero igual lo hacen por x razones) es que algunas organizaciones definen sus propias metodologías basadas en otras más conocidas, pero omitiendo algunas cosas o simplificando algunas  o "dejando" para que el jefe de proyecto decida algunos aspectos; esto no es malo per-se y quizás en muchos casos bien pensados es una buena alternativa; pero existen otros casos donde realmente esas definiciones incompletas sean la base para las futuros proyectos fracasados.

Espero te sirva lo comentado. En realidad se tiene que leer bastante para poder cubrir la amplia variedad de propuestas que se tienen hoy en día.....y si piensas en pequeñas organizaciones, en la ISO venimos trabajando la ISO/IEC 29110 un modelo para pequeñas organizaciones que desarrollan software

Saludos

Abraham

El 6 de diciembre de 2013 07:22, Luis CC <luisce...@gmail.com> escribió:

Estimados amigos, el que escribe es un estudiante y tengo una duda respecto a estos 2 conceptos y donde quedarían enmarcados: Agile, Scrum, RUP, Waterfall, CMMI, XP

Esto después de haber encontrado muchos conceptos vagos, contradictorios o ambiguos. 

- Metodología de desarrollo de software

- Proceso de desarrollo de software

Luis CC

--

Abraham Dávila

abraham...@pucp.edu.pe
Cel: (51) 999 340 843
RPM: # 999 340 843