Curso = Metodos Tecnicas y Modelos de Enseñanza.pdf
Metodologia spem epec
1. 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”
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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)
10. 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:
11. 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.
12. 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