metodologia spem epec

12
PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE IBARRA ESCUELA DE INGENIERÍA EVALUACION DE SISTEMAS (Modalidad Proyecto) “Metodología Spem-Epec” Línea de Investigación: Consultar Índice. Trabajo de Investigación Autores: Alexis Vilañez Grace Laguna Carlos Rivadeneira Proaño “Ibarra – Mayo 2014”

Upload: grace-laguna

Post on 15-Jul-2015

221 views

Category:

Education


1 download

TRANSCRIPT

Page 1: Metodologia spem epec

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR

SEDE IBARRA

ESCUELA DE INGENIERÍA

EVALUACION DE SISTEMAS (Modalidad Proyecto)

“Metodología Spem-Epec”

Línea de Investigación: Consultar Índice.

Trabajo de Investigación

Autores: Alexis Vilañez

Grace Laguna

Carlos Rivadeneira Proaño

“Ibarra – Mayo 2014”

Page 2: Metodologia spem epec

ÍNDICE DE CONTENIDO

RESUMEN ......................................................................................................................................... III

ABSTRACT ....................................................................................................................................... VI

INTRODUCCIÓN ............................................................................................................................. IX

MARCO TEÓRICO ............................................................................................................................ X

Page 3: Metodologia spem epec

III

RESUMEN

El Software y Sistemas de Proceso Meta-modelo de Ingeniería (SPEM) es un proceso de

ingeniería de meta-modelo, así como el marco conceptual, que puede proporcionar los

conceptos necesarios para modelar, documentar, presentar, gestionar, intercambiar, y la

promulgación de los métodos y procesos de desarrollo. Una implementación de este meta-

modelo se dirige a ingenieros de procesos, jefes de proyecto, proyecto y directores de

programas que son responsables del mantenimiento y la implementación de procesos para

sus organizaciones de desarrollo o proyectos individuales.

EPF Composer es una herramienta que permite generar marcos de procesos de software

para una organización. Se basa en la primicia de modelos reutilizables que permiten tomar

las mejores prácticas del mercado e integrarlas en el framework de procesos

organizacionales. Basada por completo en el ambiente de desarrollo de Eclipse

Permite autorizar, parametrizar y publicar métodos.

Añadir, eliminar y cambiar elementos de acuerdo con las necesidades de su proceso.

Publicar y comunicar el contenido para servir de guía a su equipo de trabajo.

Características de EFP Composer

Patrones genéricos de procesos (Capability Pattern)

Este tipo de construcción es un tipo especial de procesos que describen un conjunto de

actividades reutilizables y aplicables a un área común de un proceso de desarrollo, también

se utilizan como bloques de construcción para ensamblar los procesos de entrega o mayor

capacidad de los patrones que garanticen la reutilización óptima y la aplicación de las

prácticas clave que expresan.

Page 4: Metodologia spem epec

IV

Proceso de desarrollo (Delivery Process)

Un proceso de desarrollo es un proceso que cubre el ciclo de vida completo de un proyecto,

con fases, actividades e iteraciones predefinidas, puede ser utilizado como una plantilla

para la planificación y ejecución de un proyecto. Proporciona un modelo de ciclo de vida

completo con fases predefinidas, iteraciones, y actividades.

Roles (EPF Role)

Se trata de una serie de habilidades, competencias y responsabilidades que forman una

entidad, que puede adoptar un usuario o varios y que especifica quién debe trabajar en el

desarrollo de tareas y productos de trabajo.

Producto de Trabajo (Workproduct)

Es el término general adoptado para los artefactos que se generan, modifican o utilizan en

una tarea.

Guía (Template)

Es cualquier tipo de ayuda que sirve para conocer cómo debe llevarse a cabo una tarea o

producto de trabajo, como ejemplos, plantillas o listas de cuestiones a comprobar durante el

desarrollo de una acción.

Actividad (Activity)

Constituyen los bloques de los procesos de desarrollo y agrupan a los demás elementos

(incluso a nuevas actividades), pueden ser presentados en las estructuras de desglose del

trabajo y diagramas de actividad que describen gráficamente el flujo de trabajo.

Page 5: Metodologia spem epec

V

Iteración (Iteration)

Un grupo de actividades que pueden repetirse en más de una ocasión. Las iteraciones se

utilizan para organizar el trabajo en ciclos repetitivos.

Fase (Phase)

Es un tipo de actividad que representa un periodo significativo en el proyecto, suelen

concluir con un puesto de control de gestión, un hito o un conjunto de artefactos de entrega.

Tarea (task)

Se trata de una unidad de trabajo, generalmente con una duración de algunas horas o pocos

días, y es el elemento principal de un proyecto. Cada tarea se asigna a una función

específica. Las tareas suelen generar uno o más productos de trabajo.

Page 6: Metodologia spem epec

VI

Abstract

The Software and Systems Process Engineering Meta-model (SPEM) is a process

engineering meta-model as well as conceptual framework, which can provide the necessary

concepts for modeling, documenting, presenting, managing, interchanging, and enacting

development methods and processes. An implementation of this meta-model would be

targeted at process engineers, project leads, project and program managers who are

responsible for maintaining and implementing processes for their development

organizations or individual projects.

EPF Composer is a tool that allows generating software process frames for an organization.

It is based on the novelty of reusable models that allow taking the best practices of the

market,introducing them in the process framework. Based completely on the ambience of

development of Eclipse.

It allows authorizing and publishing methods.

To add, to eliminate and to change elements in accordance with the needs for its

process.

To publish and to communicate the content to serve as guide to its team of work.

Typical of EFP Composer

Generic process bosses

This type of construction is a special type of processes that describe a set of activities

reusable and applicable to a common area of a process of development, also they are used

like construction blocks to assemble the processes of delivery or major capacity of the

bosses that guarantee the ideal recycling and the application of the key practices that they

express.

Page 7: Metodologia spem epec

VII

Development process

A development process is a process that covers the finished life cycle of a project, with

phases, activities and predefined iterations; it can be used like a staff for the planning and

execution of a project. It provides a model of finished life cycle with predefined phases,

iterations, and activities.

Rolls

It is a question of a series of skills, competitions and responsibilities that form an entity,

which there can adopt a user or several and which specifies who must be employed at the

development of tasks and products of work.

Product of Work

It is the general term adopted for the gadgetry that are generated, modify or use in a task.

Guide

It is any type of help that serves to know how there must be carried out a task or product of

work, like examples, staff or lists of questions to be verified during the development of an

action.

Activity

They constitute the blocks of the processes of development and group to other elements

(even to new activities), can be presented in the structures of breakdown of the work and

diagrams of activity that describe graphically the work flow.

Page 8: Metodologia spem epec

VIII

Iteration

A group of activities that can recur in more than one occasion. The iterations are used to

organize the work in repetitive cycles.

Phase

It is a type of activity that represents a significant period in the project, they usually

conclude with a position of managerial control, a milestone or a set of gadgetry of delivery.

Task

It is a question of a work unit, generally with a duration of some hours or a few days, and it

is the main element of a project. Every task is assigned to a specific function. The tasks

usually generate one or more work products.

Page 9: Metodologia spem epec

IX

Introducción

METRICA 3 (M3), el proceso unificado de Rational (RUP) y demás metodologías están

basadas en un conjunto de ideas y conceptos subyacentes, que no están definidos de manera

explícita, es decir, no es evidente el metamodelo subyacente utilizado. Además, el formato

en que se maneja la información de dichas metodologías son documentos de texto en

lenguaje natural. Esto tiene la gran desventaja de que toda la manipulación (creación,

revisión, reutilización, adaptación, etc.) y generación de documentación (publicación) para

dichas metodologías es un proceso puramente manual. Para evitar dicha situación, OMG (la

organización industrial promotora de UML) ha desarrollado y aprobado recientemente el

estándar SPEM (Software & Systems Process Engineering Metamodel) versión 2.0 1, que

pretende ser el estándar industrial para la representación de modelos de procesos de

ingeniería del software e ingeniería de sistemas. Por otro lado, dentro de la plataforma

abierta ECLIPSE, se ha puesto en marcha el proyecto EPF (Eclipse Process Framework) 2,

que ha desarrollado un editor de SPEM 2, llamado “EPF Composer”, en adelante EPFC.

EPFC se basa en el estándar SPEM 2 y permite definir, gestionar y reutilizar un repositorio

de fragmentos de métodos y procesos. Con EPFC se pueden crear implementaciones en

formato SPEM 2 de cualquier método, proceso o metodología de ingeniería del software.

En este documento se presentan las principales características y conceptos de SPEM 2, así

como la manera en que sus conceptos y elementos se manejan con la herramienta EPFC.

Como ejemplo de uso, se utiliza la metodología M3, estableciendo las reglas para

implementar dicha metodología con SPEM 2, e incluyendo una implementación detallada

en EPFC de una tarea completa de M3.

(Francisco Ruiz, 2008)

Page 10: Metodologia spem epec

X

Marco Teórico

¿Alguna vez ha intentado documentar un proceso de desarrollo de software? ¿Por dónde se

comienza? ¿Hay algún estándar o recomendación en la industria? Para cualquiera que haya

realizado estas tareas, se dará cuenta que no es fácil y en general uno termina usando los

recursos disponibles sin mucha guía: procesadores de texto, herramientas de ayuda en línea,

wikis, diagramadores de procesos, etc. La documentación de los procesos de desarrollo de

software no es sencilla: ¿cómo documentar adecuadamente un proceso de desarrollo de

software con el objetivo que sea entendido claramente por un equipo y la documentación

sirva como un apoyo en la implementación y seguimiento del proceso descrito?

A lo largo de los años diversos autores y organizaciones han tratado de definir y comunicar

procesos de desarrollo: desde Royce con el Modelo en Cascada de 1970 hasta los métodos

ágiles más recientes. Probablemente la propuesta más estructurada, y que con su

publicación en 1998, mostró el nivel de detalle que se puede lograr con la descripción de un

proceso de desarrollo fue el “Proceso Unificado” (Unified Process).

Este trabajo inició años antes, en 1987 cuando Ivar Jacobson en Suecia creó Objectory y

fue adoptado por Ericsson, después Objectory AB fue adquirida por Rational Software

Corporation en 1995 (Ambler, 2005). En 1996, se integra el “Rational Approach” con

“Objectory Process v.3.8” para crear el “Rational Objectory Process 4.0” y que

posteriormente se convertiría en 1998 en RUP 5.0 (Kruchten, 2000). De su documentación

destacan el nivel de detalle que tiene y la integración de sus elementos: artefactos, roles,

tareas, fases, etc. Esto permitió que se entendiera fácilmente como un producto y tuvo gran

aceptación junto con UML. Sin embargo, muchas veces se omite un aspecto valioso del

Proceso Unificado: cuenta con un modelo general y con un framework que permite su

extensibilidad y soporte por medio de herramientas. Este modelo se basa en conceptos

básicos que permiten la definición de procesos más complejos y detallados:

Page 11: Metodologia spem epec

XI

Roles: Es un conjunto de habilidades, competencias y responsabilidades (el “quién”).

Tareas y Actividades: Describe una unidad de trabajo que se asigna a un rol para

lograr un resultado significativo (el “cómo”).

Productos de Trabajo (artefactos): Es un resultado significativo de un proceso (el

“qué”).

Procesos: Definen las estructuras de trabajo secuenciales que deben realizarse para

desarrollar un sistema, normalmente compuestos por diversos flujos de trabajo y fases

(el “cuándo”).

Los conceptos clave que organizan el marco de trabajo son:

Contenido Metodológico. Es la información en el proceso, la propiedad intelectual de

“cómo” realizar ciertas tareas y productos. La explicación detallada de cómo lograr

metas específicas, independientemente de su colocación en un proceso.

Guías. Es un concepto que engloba todas las formas de contenido cuyo propósito

principal es proveer explicaciones adicionales e ilustraciones de apoyo: plantillas,

herramientas, listas de verificación (checklists), etc.

Método o Metodología. Es la combinación de un proceso y contenido metodológico (la

forma en que los combinamos nos define el enfoque particular para desarrollar un

proyecto).

El framework original del Proceso Unificado evolucionó al “Method Framework” que

forma la base del “Software & Systems Process Engineering Meta-Model Specification”

(SPEM) v.2.0 [3]. SPEM es un “meta-modelo” y un perfil de UML 2.0, que se usa para

definir procesos de desarrollo de software y sistemas junto con sus componentes. Es decir,

es un esquema estandarizado de describir procesos de desarrollo administrado por el OMG.

Page 12: Metodologia spem epec

XII

Al enfrentar este tipo de proyectos de ingeniería de software, vale la pena revisar SPEM

como un marco teórico y las herramientas que lo soportan. Ver Figura 1.

Fuente: (Garcia, 2013)

(Garcia, 2013)

Gráfico1: Method Framework