PROCESOS DE INGENIERA DEL SOFTWARE

Armando Cabrera
Loja, Ecuador

Raquel Solano
Loja, Ecuador

Mayra Montalvn
Loja, Ecuador

aacabrera@utpl.edu.ec

rfsolano@utpl.edu.ec

mamontalvan@utpl.edu.ec

RESUMEN
El proceso de Ingeniera del Software se basa en modelos, mtodos y herramientas que sirven como una gua para los ingenieros del software durante el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos, procesos y productos mediante la evaluacin y medicin de los mismos. El objetivo de las organizaciones desarrolladoras de estos modelos, procesos y metodologas es que en las empresas desarrolladoras de software se los ponga en prctica para ver las mejoras en los procesos de cada una de las fases de desarrollo. Otro tema importante son los modelos del ciclo de vida del software, los cuales se basan en diferentes tcnicas y fases pero todos tienen un mismo fin. El fin de este trabajo es establecer un entorno general alrededor de las aplicaciones y definiciones actuales del Proceso de Ingeniera del Software, el mismo que puede reconocerse en dos niveles: el primero involucra actividades tcnicas y de gestin durante la adquisicin, desarrollo, mantenimiento y retirada del software en el procesos del ciclo de vida del software y el segundo se refiere a la definicin, implementacin, valoracin, medicin, gestin, cambios y mejoras de los procesos mismo del ciclo de vida del software. Algunos modelos estandarizados para la medicin de la calidad como lo son: CMMI e ISO 9000, son mencionados.

Cuando puedas medir lo que ests diciendo y expresarlo en nmeros, sabrs algo acerca de eso; pero cuando no puedes medirlo, cuando no puedes expresarlo en nmeros, tus conocimientos sern escasos y no satisfactorios Lord Kelvin La medicin en general tiene tres principales objetivos: entender qu ocurre durante el desarrollo y el mantenimiento, mejorar nuestros procesos y nuestros productos y controlar lo que ocurre en nuestros proyectos. Dentro de la gestin de proyectos de desarrollo de software las mtricas juegan un papel importante para entender, monitorizar, controlar, predecir y probar el desarrollo de software. Las mtricas son medio para asegurar la calidad en los PRODUCTOS / PROCESOS / PROYECTOS SOFTWARE.

Objetivos
Los principales objetivos del desarrollo de este trabajo son: Comprender los conceptos principales relacionados con el proceso de ingeniera de software y ciclo de vida del software. Conocer los mtodos y modelos que se aplican actualmente en la ingeniera del software. Conocer los principales ciclos de vida del software.

Trminos Generales
Software, Procesos, Mtodos, Modelos, Desarrollo de Software, Ingeniera del Software, Procesos del Software

2.ESTADO DEL ARTE 2.1 Conceptos de procesos de ingeniera del software

Palabras claves
CMMI QIP Modelo gil RUP Modelo Cascada

1.INTRODUCCIN
El proceso de ingeniera del software puede ser visto desde dos enfoques: El primero: ciclo de vida del software, procesos durante la adquisicin, desarrollo, mantenimiento y cierre y el segundo con definicin, implementacin, evaluacin, manejo, cambio y mejora del ciclo de vida del software El principal objetivo del manejo del proceso de vida de software es implementar nuevos o mejores procesos en prcticas actuales y que sean aplicados en el desarrollo de software, tales modelos como CMMI, IDEAL, QIP, entre otros.

Figura 1. Elementos del proceso de software [6]

cuatro grandes fases: concepcin, elaboracin, construccin y transicin.

Concepcin: Define el alcance del proyecto y desarrolla un caso de negocio. Elaboracin: Define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. Construccin: Crea el producto. Transicin: Transfiere el producto a los usuarios.

En la Figura 1, se muestra los elementos principales del proceso de Software que son: Personal. Mtodos y Procedimientos y Herramientas y Tecnologas. En la Figura 2, se muestra los tipos de elementos para modelar o representar un Proceso de Software Figura 2. Tipos de elementos para modelar/representar un Proceso Software [6]

2.1.4Ciclo de vida del Software

Un concepto dado por IEEE 1074 [6] es, el ciclo de vida del software es una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software Y otro concepto dado por ISO 12207 Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso

2.1.1Proceso de Software
Segn Piatini [2] El proceso de software es un conjunto coherente de: polticas, estructuras organizacionales, tecnologas, procedimientos y artefactos; que son necesarios para: concebir, desarrollar, instalar y mantener un producto software.

2.1.2Ingeniera del Software

Se puede decir que Ingeniera de software [1], es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad. Existen algunos conceptos de Ingenierita del Software, a continuacin se lista conceptos de autores ms reconocidos:

2.2Procesos de implementacin y cambios

2.2.1Modelos para Procesos de Implementacin y Cambios
A continuacin se trata dos modelos principales para mejoramiento de procesos: Modelo IDEAL y modelo QIP (Quality Improvement Paradigm)

Ingeniera de Software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978) Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o Produccin de Software (Bohem, 1976). Ingeniera de Software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972). Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera al software (IEEE, 1993).

2.2.1.1Modelo IDEAL

2.1.3Proceso de Ingeniera del Software

El proceso de ingeniera de software [3], se define como "un conjunto de etapas parcialmente ordenadas con la intencin de lograr un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998]. A este proceso tambin se le llama el ciclo de vida del software que comprende Figura 3. Modelo IDEAL [23] El modelo IDEAL [4], es un ciclo de mejoramiento de procesos, proporciona un conjunto de actividades coherentes para sustentar

la adopcin de las prcticas recomendadas por el CMM, teniendo variaciones de una entidad a otra dependiendo del tipo de industria de software, tamao de organizacin y modalidades de operacin. Las 5 fases principales que componen el modelo son: 1. Iniciar.- Establece los fundamentos bsicos para garantizar la iniciativa de mejoramiento de procesos. Cuyas actividades son: a. b. c. d. e. f. 2. Estimulo para iniciar el mejoramiento Establecimiento del contexto Establecer patrocinio de la gerencia Establecer infraestructura mejoramiento para el

Evaluar y caracterizar el estado actual de las practicas Desarrollar recomendaciones y documentar los resultados de la fase

Figura 4. Modelo QIP [24] Otro de los modelos reconocidos es el modelo QIP [5] El propsito de este modelo es apoyar el proceso de mejora continua y la ingeniera de los procesos de desarrollo, para ayudar en la tecnologa de perfusin. Una forma de ver el modelo es tambin verlo como un modelo para la organizacin de aprendizaje, donde la organizacin establece una forma de desarrollar las prcticas a travs de la experimentacin con ellos y, a continuacin, la captura y el paquete en una forma que pueden ser reutilizados en otras partes, dentro de ciertos lmites. QIP esta basado en las principales disciplinas del software, por eso es natural, revolucionario y experimental. El trabajo para desarrollo de software se basa en los humanos y su diseo de trabajo.

Diagnosticar.- Evala mediante un mtodo formal las fortalezas y debilidades del proceso seguido por los proyectos. Las principales actividades son: a. b. Evaluar y caracterizar el estado actual de las practicas Desarrollar recomendaciones y documentar los resultados de la fase

3.

Establecer.- realiza la planificacin especifica de los mejoramientos que desea alcanzar. Principales actividades: a. b. Establecer los equipos de accin de procesos Elaboracin del Plan de Accin

2.3Definicin de procesos
2.3.1Modelos del ciclo de Vida del Software
Existen varios modelos del ciclo de vida del software, sin embargo los mas utilizados son: Cascada, Prototipado, Incremental y en Espiral

4.

Actuar.- Implementa el mejoramiento de procesos llevando a cabo el plan de accin. Sus caractersticas son: a. b. c. d. Planificar, ejecutar y seguir la instalacin Planificar y ejecutar proyectos piloto Refinar la solucin Implementar la solucin

2.3.1.1Cascada

5.

Difundir.- Aprende de la experiencia del ciclo recin realizado y aumenta la habilidad de la empresa u organizacin para mejorar los procesos en forma continua. Sus caractersticas son: a. b. Documentar y analizar las lecciones. Revisar el enfoque seguido y proponer acciones futuras.

2.2.1.2Modelo QIP

Figura 5. Modelo en Cascada [6] Este modelo es conocido tambin como ciclo de vida lineal o bsica. Este modelo admite la posibilidad de hacer iteraciones. Se

define como una secuencia de fases como se muestra en la Figura 5, en la que al final de cada una de ellas se rene la documentacin para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente. [25] Sus principales caractersticas son [6]:

Cada fase empieza cuando se ha terminado la fase anterior Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto

El modelo prototipado [26], modela el producto final y permite efectuar un test sobre determinados atributos del mismo sin necesidad de que este disponible. Se trata, simplemente, de testear haciendo uso del modelo. Esta tcnica puede ser utilizada en cualquier etapa de desarrollo. A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez ms las caractersticas del producto final. En la Figura 6 se listan las fases del modelo Prototipado. Existen varios tipos como: Prototipado Rpido Prototipado Evolutivo Prototipado Operacional Prototipado Reutilizable

Las ventajas y desventajas [21], de este modelo se describen a continuacin:

2.3.1.1.1Ventajas

Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida. Este modelo es sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

Los prototipos [6], tienen una doble funcin: El cliente ve el producto y refina sus requisitos El desarrollador comprende mejor lo que necesita hacer Sus principales caractersticas son: Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuario o Reduce costos y aumenta la probabilidad de xito o Exige disponer de las herramientas adecuadas o No presenta calidad ni robustez Suele utilizarse principalmente en dos reas: o Prototipado de la interfaz de usuario o Prototipado del rendimiento Las ventajas y desventajas [27], [28], se listan a continuacin:

2.3.1.1.2Desventajas

Su inflexibilidad en la divisin del proyecto en distintas etapas Esto hace difcil poder responder a los cambios en los requerimientos del cliente. Se tarda mucho tiempo en pasar por todo el ciclo El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son muy difciles Para obtener resultados se debe llegar a la etapa final del proyecto. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

2.3.1.2.1Ventajas

Es mucho mejor y conveniente usar este modelo porque es el nico apto para desarrollos en los que se utiliza nueva tecnologa. El prototipado es un medio excelente para recoger la realimentacin del usuario final, as como tambin es mucho ms rpido de desarrollarse. El cliente se va familiarizando con el nuevo producto. Permite proporcionar una funcionalidad til en manos del cliente sin tener la aplicacin finalizada.

2.3.1.2Prototipado

2.3.1.2.2Desventajas

No hay que usar en casos experimentales ya que no puede funcionar. La gestin de desarrollo que es lenta porque da vueltas hasta que el usuario este de acuerdo, o se pongan limites. Imposibilidad de conocer a priori el tiempo de desarrollo Es muy difcil y complejo realizarlo

2.3.1.3Iterativo e Incremental
Estos modelos disminuyen riesgos y nos ayudan a tener un mejor desarrollo de software ya que se basan en la retroalimentacin por lo que nos ayudan a tener una mejor arquitectura del software y son muy tiles cuando el usuario tiene ms requerimientos.

Figura 6. Modelo Prototipado [6]

El modelo iterativo: Este modelo mejora cada versin es decir mejora la funcin que tiene la versin. El modelo incremental: Este modelo mantiene la funcin anterior y aumenta otra, ya que puede ser que el primer incremento no hubiera tenido todos los requerimientos que necesitaba el proyecto.

Difcil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo. Los errores en los requisitos se detectan tarde y su correccin resulta costosa Necesitan una gran planeacin. Debido a la interaccin con los usuarios finales, cuando sea necesaria la retroalimentacin hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances extremadamente lentos. No es una aplicacin ideal para desarrollos en los que de antemano se sabe que sern grandes en el consumo de recursos y largos en el tiempo. Al requerir constantemente la ayuda de los usuarios finales, se agrega un costo extra a la compaa, pues mientras estos usuarios evalan el software dejan de ser directamente productivos para la compaa.

2.3.1.4En espiral

Figura 7. Modelo Iterativo e Incremental [6] En la Figura 7, se muestra el modelo Incremental, en este modelo se aplican secuencias lineales de forma escalonada mientras progresa el calendario. Sus principales caractersticas son: Corrige la necesidad de una secuencia no lineal de pasos de desarrollo El sistema se crea aadiendo componentes funcionales al sistema incrementos El sistema no se ve como una entidad monoltica con una fecha fija de entrega, sino que es una integracin de resultados sucesivos obtenidos despus de cada iteracin Se ajusta a entornos de alta incertidumbre Las ventajas y desventajas de este modelo son [30] [32]:

Figura 8. Modelo en Espiral [6] El modelo en Espiral que se muestra en la Figura 8, es un modelo de proceso de software evolutivo que combina la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Segn Wikipedia [31], las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. El software se desarrolla en una serie de versiones incrementales.

2.3.1.3.1Ventajas

Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucra ms. Mayor retorno de la inversin. Disminuyen riesgos Se puede cambiar los requerimientos pues como nos basamos en una versin a esta la aumentamos o la modificamos. Reduce costos, si algo sale mal solo volvemos a la antigua versin y comenzamos de nuevo. Al usuario se le entrega parte del producto, es decir una versin con la cual el puede trabajar.

Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.

2.3.1.3.2Desventajas

Difcil de evaluar el coste total. Requiere gestores experimentados.

Sus principales caractersticas son:

Cada ciclo empieza identificando: o Los objetivos de la porcin correspondiente

o o

Las alternativas Restricciones

Se evalan las alternativas respecto a los objetivos y las restricciones. Se formula una estrategia efectiva para resolver las fuentes de riesgos (simulacin, prototipado, etc.). Se plantea el prximo prototipo. Una vez resueltos los riesgos se sigue el ciclo en cascada Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el siguiente.

Demostrar valor iterativamente. Elevar el valor de abstraccin. Enfocarse en la calidad.

2.3.2.1.1Ciclo de vida de RUP

El proceso del RUP est dividido en 4 fases, en estas fases se realiza varias iteraciones de acuerdo al proyecto, en la Figura 9 se muestra grficamente las 4 fases del RUP, cuyas iteraciones estn representadas con lneas verticales y marcadas con la letra correspondiente a la inicial de la fase, la fase Inicial tiene una sola iteracin.

Las ventajas y desventajas de este modelo son [31]:

2.3.1.4.1Ventajas

No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es mas fcil validar los requisitos El riesgo en general es menor, porque si todo se hace mal , solo se ha perdido el tiempo y recursos invertidos en una iteracin El riesgo de sufrir retrasos es menor ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos, El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.

Figura 9. Fases del RUP [35]

2.3.2.1.2Fase de Inicio 2.3.1.4.2Desventajas

Es difcil evaluar los riesgos Necesita de la participacin continua por parte del cliente Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita y esto lleva tiempo. Genera mucho tiempo en el desarrollo del sistema Modelo costoso requiere experiencia en la identificacin de riesgos En esta fase se define el modelo del negocio y el alcance del proyecto, se identifican los autores y casos de usos y se disean los casos de uso esenciales. Los objetivos son:

2.3.2Metodologas de desarrollo de software 2.3.2.1RUP

RUP [35] es un proceso para el desarrollo de un proyecto de software que define quien, como, cuando y que debe hacerse en el proyecto, con 3 caractersticas esenciales como: Casos de uso, centrado n la arquitectura y es iterativo e incremental. El RUP maneja 6 principios clave:

Establecer el mbito del proyecto y sus limites Encontrar los casos de uso crticos del sistema, los escenarios bsicos. Mostrar una arquitectura para los escenarios principales. Estimar el coste en recursos y tiempo en todo el proyecto. Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase son:

Adaptacin del proceso. Balancear prioridades. Colaboracin entre equipos.

Documento de visin Modelo inicial de casos de uso Glosario inicial Caso de negocio Lista de riesgos y plan de contingencia Plan del proyecto Modelo de negocio

2.3.2.1.3Fase de Elaboracin
En esta fase se analiza el dominio del problema, establece los cimientos de la arquitectura, desarrolla el plan del proyecto y elimina los riesgos mayores. Se construye un prototipo de la arquitectura que evoluciona en iteraciones sucesivas hasta convertirse en el sistema final. Los objetivos de esta fase son:

configuracin, instalacin y facilidad de uso del producto. En esta fase tambin se realiza:

Definir, validar y cimentar la arquitectura. Completar la visin Crear un plan para la fase de construccin Demostrar que la arquitectura propuesta soportara la visin

La prueba de la versin beta para validar al nuevo sistema frente a las expectativas del usuario. Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos por el nuevo proyecto. Conversin de las bases de datos operacionales. Entrenamiento de los usuarios y tcnicos de mantenimiento. Traspaso del producto a los equipos de marketing, distribucin y venta.

Los objetivos de esta fase son: Conseguir que el usuario se valga por si mismo. Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.

Los resultados son los siguientes:

Un modelo de casos de uso al menos el 80% Requisitos adicionales que capturan los requisitos no funcionales. Descripcin de la arquitectura software Prototipo ejecutable de la arquitectura. Lista de riesgos y caso de negocio revisados Plan de desarrollo para el proyecto Manual de usuario preliminar.

Los resultados son:

2.3.2.1.4Fase de Construccin
En esta fase la finalidad es alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones, en esta fase todas las componentes, caractersticas y requisitos deben ser implementados, integrados y cambiados en su totalidad. Los objetivos son:

Prototipo operacional Documentos legales Caso del negocio completo Lnea base del producto completa y corregida que incluye todos los modelos del sistema Descripcin de la Arquitectura completa y corregida. Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva versin.

Los criterios de evaluacin de esta fase son:

Minimizar los costes de desarrollo mediante la optimizacin de recursos. Conseguir calidad adecuada. Conseguir versiones funcionales tan rpido como sea prctico.

El usuario se encuentra satisfecho. Son aceptables los gastos actuales versus los gastos planificados.

2.3.2.2MSF
La metodologa MSF (Microsoft Solucion Framework) [40], es flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, y guas para disear y desarrollar soluciones empresariales de una manera que asegura que todos los elementos del proyecto tal como gente, procesos y herramientas, puedan ser exitosamente conducidos. MSF no slo es aplicable al desarrollo de proyectos de desarrollo, tambin es aplicable a otros proyectos de TI, como el despliegue o proyectos de infraestructura o redes. MSF no fuerza al desarrollador a utilizar una metodologa especfica (Cascada, gil), pero les permite decidir qu mtodo utilizar.

Los resultados de la fase de construccin deben ser:

Modelos completos(casos de uso, anlisis, diseo, despliegue e implementacin) Arquitectura integra. Riesgos presentados mitigados Plan del proyecto para la fase de transicin. Manual inicial de usuario. Prototipo operacional. Caso del negocio actualizado.

2.3.2.1.5Fase de Transicin
En esta fase se pone el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentacin, entrenar al usuario en el manejo del producto y tareas relacionadas con el ajuste,

Escalable: Puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: Es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: Porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa.

Principios fundamentales en los que se basa MSF MSF propone una secuencia generalizada de actividades para la construccin de soluciones empresariales, este proceso es flexible y se puede adaptar al diseo y desarrollo de una amplia gama de proyectos de una empresa, adems est basado en fases, puntos de transicin y de carga de forma iterativa que se puede aplicar en el desarrollo de aplicaciones tradicionales, soluciones empresariales para comercio electrnico as como aplicaciones Web distribuidas.

Los principios en los que se fundamenta MSF son: Figura 10. Fases del modelo MSF [41]
El MSF est compuesto 6 por fases, como se muestra en la Figura 10, las fases se listan a continuacin: 1. Visin: donde se rene un equipo del proyecto, define la visin y el mbito de una solucin que cumplir los objetivos del cliente. El equipo organiza entonces el proyecto y proporciona un documento de visin/mbito aprobado. Las personas encargadas de funciones de administracin de productos y administracin de programas toman el mando en esta fase. Planeacin: donde se desarrollan los procesos de diseo conceptual, lgico y fsico, as como la especificacin funcional. La persona encargada de funciones de administracin de programas toma el mando durante esta fase y crea planes de proyecto que tratan el desarrollo, la comunicacin y otras tareas; y cada funcin proporciona los datos para crear la programacin del proyecto. Desarrollo: El equipo crea y prueba la solucin. La persona encargada de funciones de desarrollo toma el mando durante esta fase. Estabilizacin: El equipo crea la solucin piloto en preparacin para el lanzamiento de produccin. La persona encargada de las funciones de prueba toma el mando durante esta fase. Instalacin. Soporte

Fomentar la comunicacin abierta. Trabajar en pro de una visin compartida. La autonoma de los miembros del equipo. Establecer una clara rendicin de cuentas y la responsabilidad compartida. Centrarse en entregar valor de negocio. Mantenerse gil a espera del cambio. Invertir en calidad. Aprender de todas las experiencias.

2.

MSF para Metodologas de Desarrollo gil (MSF4ASD) MSF para Metodologas de Desarrollo gil es un proceso de desarrollo manejado por escenarios, basado en contexto, que utiliza muchas de las ideas incorporadas en Team System (herramientas de Microsoft). Este proceso incorpora las prcticas probadas desarrolladas en Microsoft con respecto a los requerimientos, diseo, seguridades, rendimiento y pruebas (testing) [42]. MSF para metodologas de desarrollo gil presenta una gua muy recomendable a los Desarrolladores y Gestores de proyectos de software que pueden adaptarla a la metodologa de su empresa, en la que incluye documentos de ejemplo, plantillas, archivos en blanco de Project, Excel y Word para la administracin de proyectos, requerimientos, seguridad y pruebas. MSF para CMMI (MSF4CMMI) EL MSF4CMMI para CMMI es una metodologa formal para la ingeniera de software es un proceso de mejora que proporciona a las organizaciones los elementos esenciales del proceso continuo de mejora que den lugar a una reduccin de Ciclo de vida del Desarrollo de Software, la mejora de la capacidad para satisfacer las metas de costos y el calendario, la construccin de productos de alta calidad. El MSF4CMMI se ha ampliado una orientacin MSF4ASD con una formalidad adicional, evaluacin, verificacin y auditora [43].

3.

4.

5. 6.

Las caractersticas ms relevantes del MSF son: Adaptable: Es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar.

Una de las ventajas de utilizar el proceso CMMI es el estndar de evaluacin por la que uno puede comparar la capacidad de desarrollar software en otras organizaciones.

Essential Unified Process Feature Driven Development Lean Development

EssUP FDD LD De Luca & Coad 1998 Palmer & Felsing 2002, Charette 2001, Mary y Tom Poppendieck Beck 1999 Sutherland 1994 Schwaber 1995 Microsoft 1994

2.3.2.3Modelo gil
El Modelo de Desarrollo gil se origin a mediados de los aos 1990 y se podra decir que fue extrado del modelo de desarrollo en cascada, pues ste ltimo era visto como burocrtico, lento, degradante e inconsistente por lo exigente y muy estructurado en sus formas de desarrollo de software que sin embargo realizaban un trabajo eficiente. En el ao 2001, miembros prominentes de la comunidad de la industria del software se reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologas giles"[36]. El modelo de desarrollo gil es un paradigma de Desarrollo de Software que utiliza procesos giles (pequeas y frecuentes entregas con ciclos rpidos) enfocados en la gente y resultados, se podra decir que es: Cooperativo, clientes y desarrolladores trabajan constantemente con una comunicacin muy fina y constante, Sencillo, mtodo fcil de aprender y modificar para el equipo pues la reduccin de documentacin se reemplaza por la constante comunicacin, y Adaptativo, capaz de permitir cambios de ltimo momento.

Programacin Extrema Scrum Microsoft Solutions Framework Rapid Development Open Process Unified

XP Scrum MSF

RAD OpenUP RUP

McConnell 1996

Rational Unified Process

Krutchen 1996

Algunas empresas que usan metodologas de desarrollo gil en algunos de sus proyectos, son:

El objetivo de este modelo es desarrollar software rpidamente, respondiendo a los cambios que puedan surgir a lo largo del proyecto. Esta metodologa propone que un pequeo grupo de personas (10 como mximo) conformado de los ms experimentados y capaces ingenieros de software, trabajen en el desarrollo de iteraciones (software desarrollado en una unidad de tiempo) con una duracin mxima de hasta 4 semanas y desarrollando una serie de user stories (Casos de Uso) que al final cumplan con los requerimientos establecidos en lnea directa por los usuarios finales del sistema [37].

Google, Oracle, Yahoo, Canon, Xerox, Sun, HP, Nokia, Honda, Toyota, etc.

2.3.2.3.2Ventajas: 2.3.2.3.1Metodologas Agiles

Hacemos mencin de algunas metodologas giles de desarrollo de software en la Tabla 1, estas metodologas son: Tabla 1. Lista de Metodologas giles Metodologa Adaptive Software Development Agile Modeling Agile RUP Crystal Methods Acrnimo ASD Creacin Highsmith 2000 Mtodos de comunicacin ms eficaces en este tipo de metodologas. Es posible identificar y atacar los problemas ms crticos y controversiales del proyecto en las primeras etapas. El cliente comenzar a ver su sistema lo ms pronto posible y verificar que se estn cubriendo sus requerimientos de forma adecuada. Entrega de resultados tangibles en etapas tempranas del proyecto.

AM dx CM

Ambler 2002 Booch, Martin, Newkirk 1998 Cockbum 1998

2.3.2.3.3Desventajas:

Proceso menos controlado y con pocos principios. No existe contrato tradicional o al menos es bastante flexible.

Grupos pequeos, trabajando en el mismo sitio y no distribuidos adecuadamente. Menos nfasis en la arquitectura del software, siendo sta primordial para el xito del proyecto de software.

documentacin de actividades de mantenimiento de software.

2.3.3.2.2 ISO 14764:1998

ste estndar internacional como es ISO 14764 [34] aclara los requerimientos para el Proceso de Mantenimiento del Software. El Mantenimiento del Software es un proceso primario en el ciclo de vida de un producto software. En muchos proyectos, especialmente aquellos que tienen una vida larga, el mantenimiento del software es con seguridad una de las consideraciones ms importantes del proyecto. Por esta razn es necesario ser capaces de corregir los fallos que se encuentran durante su manejo. Mantenimiento de Software se puede hacer combinando herramientas software, mtodos y tcnicas, se aplica a programas de ordenador, cdigo, datos, y documentacin. Se intenta que se aplique a productos software creados durante el desarrollo del producto software. ste estndar internacional est pensado para su uso en todos los esfuerzos de mantenimiento, independientemente del ciclo de vida o del enfoque usado en el desarrollo.

2.3.2.3.4Uso de Metodologas
El surgimiento de estas revolucionarias metodologas que no solo nacen para el desarrollo de sistemas software sino para el manejo o desarrollo de productos los incrementos en adeptos se presentan gradualmente con el tiempo y las tecnologas. En la Figura 11, se muestra [38]

2.3.3.3ISO 9001-2000
Figura 11. Uso de Mtodos giles [38] El estndar o norma ISO 9001:2000 (Quality management systems Requirements) que significa Calidad del manejo de requerimientos del sistema, especifica los requerimientos para el manejo de la calidad de un sistema organizacional proveyendo requerimientos de los productos y satisfaccin del cliente. Primario se basa en la calidad del software, y segundo en los procesos de ingeniera del software.

2.3.3Procesos del ciclo de vida del Software 2.3.3.1Estndar IEEE 1074

El estndar IEEE 1074 [7] y [8], es un estndar para la generacin de los que rigen el proceso de desarrollo de software y mantenimiento de un proyecto. Este estndar requiere la seleccin de proyectos de software y modelos de ciclo de vida, basado en la misin, visin, metas y recursos de las organizaciones. Tambin describe las diferentes actividades que van a ser asignada en el modelo seleccionado. Sin embargo, este estndar no es una gua de instruccin. Tambin puede ser utilizado para desarrollar los procesos de organizacin para apoyar el desarrollo de software y procesos que tiene una nica funcin dentro de un proyecto.

2.4Evaluacin de Procesos
2.4.1Modelos de Evaluacin del proceso 2.4.1.1CMMI
CMMi intenta proveer una gua para los procesos. Las reas especficas relacionadas son:

2.3.3.2Procesos de Mantenimiento: 2.3.3.2.1 IEEE 1219-1998

El estndar IEEE 1219-1998 [9], se basa en procesos iterativos para ejecutar y manejar el mantenimiento de software. Los procesos estn aplicados a:

Calidad de proceso y producto Verificacin del proceso Validacin del proceso

Planeacin de mantenimiento mientras el producto est desarrollndose. Planeacin y ejecucin de mantenimiento para productos de software existente. Aplica cualquiera de los modelos del ciclo de vida disponibles. Estndares prescriben los requerimientos para procesos, control y manejo de la planeacin, ejecucin y

Hubo inicialmente algn debate sobre si la ISO 9001 o CMMi podran ser usadas por los ingenieros del software para asegurar la calidad. Este debate fue publicado y como resultado la decisin ha sido tomada que los dos son complementarios y que teniendo certificacin ISO 9001 puede ayudar grandiosamente en altos niveles de madurez del CMMi. [6] El modelo CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

2.4.2Mtodos de evaluacin del proceso

Estos medos fueron desarrollados por el SW-CMM

2.4.2.1CBA-IPI
El CBA-IPI [39], es un mtodo de evaluacin basado en CMM sirve para mejorar internamente los procesos, fue desarrollado por el Softare Engneer Institute de la Universidad Carnegie Mellon. Es una herramienta de diagnostico que permite a las organizaciones y proyectos el poder determinar las fortalezas y de sus procesos de desarrollo de software, utiliza el mtodo de madurez de capacidades para software desarrollado por el SEI

2.4.2.2SCAMPI
Los mtodos SCAMPI son grandes torres de evaluacin CMMi. Las actividades ejecutadas durante una evaluacin, la distribucin de esfuerzo en estas actividades como la atmosfera durante una evaluacin son diferentes cuando son de mejora para la adjudicacin de un contrato.

Planificar el Proceso de Medicin que implica tareas como: o Obtener caractersticas de la Organizacin. o Identificar las necesidades de la Informacin. o Seleccionar las medidas. o Definir los procedimientos de recoleccin de datos, anlisis e informes. o Definir los criterios de evaluacin de los productos de informacin y el proceso de medicin. o Revisar, aprobar y proporcionar recursos para las tareas de medicin. o Adquirir y utilizar tecnologas de apoyo. Realizar el Proceso de Medicin que implica tareas como: o Integrar los procedimientos, o Recoger los datos, o Analizar los datos y desarrollar productos de informacin. o Comunicar los resultados. Evaluar la Medicin que implica tareas como: o Evaluar productos de informacin y el proceso de medicin, o Identificar las mejoras potenciales.

2.5Medidas de Productos y Procesos

La medicin de software es una disciplina relativamente joven, consenso general sobre la definicin exacta de los conceptos y terminologa que maneja, aunque trminos clave de medicin del software y mtodos de medicin han sido definidos en la ISO/IEC 15939 basados en el vocabulario ISO internacional de metrologa. A pesar de todo, los lectores encontrarn diferencias terminolgicas en la literatura; por ejemplo, el trmino mtrica se utiliza a veces en vez de medida. En la Figura1 se muestra el mbito de ISO/IEC 15939: [10]

2.5.1Medicin del Proceso: ISO 15539-02

La medicin del Proceso significa recoger, analizar e interpretar informacin cuantitativa sobre nuestros procesos, para identificar las fuerzas y las debilidades de los mismos y para evaluarlos despus de que hayan sido implementados y/o cambiados. Muchos son los propsitos que abarca la medicin del Proceso en el presente caso de estudio nos centraremos en la medicin del proceso para gestionar un proyecto de software enfocado en la implementacin y cambio del proceso. El medir un proceso de software implica medir las actividades relacionadas con el software como por ejemplo el esfuerzo, el coste y los defectos encontrados, mientras que se pueden hacer algunos esfuerzos para valorar la utilizacin de herramientas y de hardware, un recurso principal que necesita ser gestionado en la ingeniera del software es el personal. Existen tres tipos de mtricas de proceso: Tiempo requerido para completar un proceso en particular: total del proyecto, por ingeniero, por actividad, etc. Recursos requeridos para un proceso en particular: esfuerzo en personas/da, costes de viajes, recursos de hardware, etc. Nmero de Ocurrencias de un Evento nmero de defectos descubiertos durante la revisin del cdigo, nmero de peticiones de cambio en requerimientos, nmero promedio de lneas de cdigo (LDC) modificadas en respuesta a un cambio de requerimientos, errores detectados por el usuario, etc.

Figura 12. mbito de la ISO/IEC 15939 [10] Las actividades de la ISO/IEC 15939 son: Establecer y Mantener el Compromiso de Medicin que implica tareas como: o Aceptar los requisitos de medicin. o Asignar recursos.

Justificacin La recoleccin de mtricas del proceso es esencial para la mejora del mismo y se utilizan para evaluar la eficiencia de un proceso y si ste ha mejorado con los cambios realizados. Las dos primeras mtricas ayudan a descubrir si los cambios en el proceso mejoran la eficiencia de un proceso. Por ejemplo, se puede medir el tiempo y esfuerzo necesarios para moverse de un hitos fijo a otro, como la aceptacin de requerimientos, terminacin de un diseo arquitectnico, etc. Esos valores ayudan a identificar reas de mejora en el proceso. Una vez introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos. El nmero de ocurrencias de un Evento Tienen influencia directa en la calidad del software. Por ejemplo, incrementar el nmero de defectos descubiertos al cambiar el proceso de revisin del cdigo probablemente se reflejar en una mejora de la calidad del producto, aunque tiene que confirmarse por mediciones posteriores del producto.

que el software satisfaga las necesidades del usuario), que son manifestadas externamente cuando el software es utilizado, y son un resultado de atributos internos del software. El modelo de calidad de ISO 9126-1 establece 3 niveles: (1) Caracterstica, (2) Subcaracterstica y (3) Mtricas. [12] Caractersticas de calidad del ISO 9126-1:2001: Funcionalidad: conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades. Las subcaractersticas son: Idoneidad, Exactitud Interoperabilidad, Seguridad, Cumplimiento de normas. Fiabilidad: conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestacin bajo condiciones establecidas durante un perodo de tiempo establecido. Las subcaractersticas son: Madurez, Tolerancia a fallas, Facilidad de Recuperacin, Conformidad de Fiabilidad. Usabilidad: conjunto de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios. Las subcaractersticas son: Aprendizaje, Comprensin, Operatividad, Atractividad, Conformidad de Usabilidad Eficiencia: conjunto de atributos que se refieren a las relaciones entre el nivel de rendimiento del software y la cantidad de recursos utilizados bajo unas condiciones predefinidas. Las subcaractersticas son: Compartimiento en el tiempo, Compartimiento de recursos, Conformidad de eficiencia. Mantenibilidad: conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software. Las subcaractersticas de la Facilidad de Mantenimiento son: Facilidad de anlisis, Facilidad de cambio, Estabilidad y Facilidad de prueba. Portabilidad: conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra. Las subcaractersticas de la Portabilidad son: Capacidad de instalacin, capacidad de reemplazamiento, Adaptabilidad y Co-Existencia.

Se describira a las salidas de los procesos como: calidad del producto (errores por KLOC (Kilo Lneas de Cdigo) o por Punto Funcin (FP)), mantenibilidad (el esfuerzo para hacer un cierto tipo de cambio), productividad (LDC (Lneas de Cdigo)) o Puntos Funcin por persona-mes), tiempo-de-mercado, o satisfaccin del cliente (como medidos por medio de una encuesta a clientes). Esta relacin depende del contexto particular (por ejemplo, el tamao de la organizacin o el tamao del proyecto). De all que el obtener las salidas del proceso que deseamos significa que se debi haber implementado los procesos adecuados.

2.5.2Medicin del Producto: ISO 9126-01

Qu es un producto de software? Un producto de software se lo puede describir en un sentido extenso como: los ejecutables, cdigo fuente, descripciones de arquitectura, y as. De all que las mtricas del producto se refieren a las caractersticas del propio software que incluye: la medicin del tamao del producto, la estructura del producto y la calidad del producto. Un estndar internacional para la evaluacin del Software es el ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005. [11] Permite evaluar la calidad del software desde distintas perspectivas relacionadas con el desarrollo, adquisicin, requerimientos, uso, evaluacin, mantenimiento, aseguramiento de la calidad. El estndar est dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente:

2.5.2.2Mtricas Externas ISO 9126-2:2003

Las cuales miden el software en s mismo o software en ejecucin (Calidad Externa Ambiente de Prueba).

2.5.2.3Mtricas Internas ISO 9126-3: 2003

Las cuales miden el comportamiento del sistema, dichas mtricas se aplican cuando el software no est en ejecucin por ejemplo durante el diseo y codificacin. (Calidad Interna Ambiente de Desarrollo)

2.5.2.4Calidad 2.5.2.1Modelo de la Calidad

Describe el modelo de calidad del producto de software especificando 6 caractersticas de calidad interna (evala el total de atributos que un software debe satisfacer) y externa (evala

en

UsoISO

9126-4:

2004

El cual mide el efecto de usar el software en un contexto especfico (Ambiente de Produccin). ISO 9126-2, ISO 9126-3 e ISO 9126-4 estn encaminados en ambientes de Prueba, Desarrollo y Produccin respectivamente.

Quin puede utilizar esta norma? Esta Norma puede ser usada por desarrolladores, evaluadores independientes y grupos de aseguramiento de la calidad responsable de especificar y evaluar la calidad del software.

3.MODELOS ESTANDARIZADOS DISPONIBLES 3.1CMMI

CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones

3.1.1Niveles CMM CMMI

Los niveles CMM - CMMI son 5: Inicial o Nivel 1 CMM CMMI: En este nivel pertenecen aquellas empresas que no tienen sus procesos bien definidos. Caractersticas comunes de este tipo de empresas son: los presupuestos se disparan, no se entrega el proyecto en fechas establecidas, no hay control sobre el estado y desarrollo del proyecto. El simple hecho de existir como empresa de software se est en el nivel1. Repetible o Nivel 2 CMM CMMI: El objetivo que pretende alcanzar el nivel 2 es que los proyectos que lleve a cabo las empresas se los ejecute con una adecuada gestin de los procesos lo que implica planeacin, ejecucin, control, medicin de los mismos. Es un nivel difcil de alcanzar pues al establecer procesos se est pretendiendo cambiar la forma de trabajar de la empresa que muchas de las veces implica un cambio cultural de la misma y por ende lo ms importante aqu es saber si se cuenta con el apoyo de la direccin para afrontar este cambio. Sin este apoyo no se podra alcanzar el CMM-CMMI nivel 2. Los procesos que hay que implantar para alcanzar este nivel son: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin Definido o Nivel 3 CMM CMMI: Pertenecer a este nivel significa que los proyectos que se llevan a cabo a ms de contar con procesos gestionados, la organizacin o empresa debe contar con una forma definida para desarrollar dichos proyectos es decir sus procesos deben estar establecidos, documentados y contar con mtricas para la consecucin de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin

Cuantitativamente Gestionado o Nivel 4 CMM CMMI: Nivel 4 a ms de contar con procesos definidos para el desarrollo de los proyectos se utilizan tcnicas cuantitativas para el control de los procesos, como pueden por ejemplo se usan las mtricas para gestionar la organizacin. Los procesos que hay que implantar para alcanzar este nivel son: Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin Optimizado o Nivel 5 CMM CMMI Los procesos de los proyectos y de la organizacin en este nivel a ms de ser cuantitativamente gestionados estn orientados a la mejora de las actividades mediante el uso de mtricas. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional. Anlisis y resolucin de las causas.

3.2ISO 9000
ISO 9000 se refiere a una serie de normas internacionales que define un sistema de Garanta de Calidad en las organizaciones: ISO 9001, ISO 9002, ISO 9003 e ISO 9004 (y sus subnormas) desarrollado por la Organizacin Internacional de Normalizacin (ISO). Esta norma ha sido adoptada por 90 pases en todo el mundo y est compuesta por representantes de normas nacionales de ms de 100 pases. La familia de normas apareci por primera vez en 1987 teniendo como base una norma estndar britnica (BS), y se extendi principalmente a partir de su versin de 1994, estando actualmente en su versin 2008, publicada el 13 de noviembre de 2008. La principal norma de la familia es actualmente la: ISO 9001:2008 - Sistemas de Gestin de la Calidad - Requisitos. [15]

3.2.1Proceso de Certificacin
Para brindar una certificacin bajo la norma ISO 9000 a determinada empresa u organizacin, existen las entidades certificadoras vigiladas por organismos nacionales que les dan su acreditacin y son las encargadas de verificar que dichas organizaciones o empresas cumplen con los requisitos de la norma, una vez que stas hayan elegido el alcance de la actividad profesional que se va a registrar, seleccionado un registro, someterse a la auditora y haber concretado con xito dicho proceso; se les otorga un certificado y sello. Qu hacer ante el incumplimiento? Si un auditor/registrador encuentra reas de incumplimiento la organizacin o empresa tiene un plazo para adoptar medidas correctivas, sin perder la vigencia de la certificacin o la continuidad en el proceso de certificacin.

3.2.2 Marco Conceptual

La ISO 9001 y la ISO 9002 son normas de sistema. ISO 9001 se aplica a las empresas que se dedican al diseo de productos o servicios y tambin a su produccin o implementacin. ISO 9002 simplemente excluye el elemento de diseo de un modelo similar para garanta de calidad. Los certificados que pueden concederse mediante ellas sealan que una organizacin es perfectamente capaz de cumplir las necesidades y requisitos de sus clientes de manera planificada y controlada [16]. Si quiere ir ms all y lograr la excelencia, debera cumplir requisitos adicionales. La ISO 9004:2000 establece estos requisitos adicionales.

La Computer Society declara "dedicada al avance de la teora, la prctica y la aplicacin de la informtica y la tecnologa de procesamiento de la informacin." Procura "ser el proveedor lder de informacin tcnica y servicios a los profesionales del mundo de la informtica". [19]

4.4 RUSSOFT Association

Con sede en San Petersburgo, es un multi-nacional de la asociacin de software de empresas de Rusia, Ucrania y Bielorrusia. Fue fundada el 9 de septiembre de 1999 y se ha fusionado con la de Fort-Ross Consorcio en mayo de 2004. Al igual que en la India NASSCOM, RUSSOFT fue creado para representar a empresas rusas de desarrollo de software en el mercado mundial, a fin de mejorar la comercializacin y actividades de relaciones pblicas de sus miembros, y para presionar a sus intereses en sus pases los gobiernos. [20]

4.ORGANIZACIONES 4.1Software Engineering Institute (SEI)

Es un instituto federal estadounidense de investigacin y desarrollo, fundado por el Congreso de los Estados Unidos en 1984 para desarrollar modelos de evaluacin y mejora en el desarrollo de software, que dieran respuesta a los problemas que generaba al ejrcito estadounidense la programacin e integracin de los sub-sistemas de software en la construccin de complejos sistemas militares. Financiado por el Departamento de Defensa de los Estados Unidos y administrado por la Universidad Carnegie Mellon. Es un referente en Ingeniera de Software por realizar el desarrollo del modelo SW-CMM (1991) que ha sido el punto de arranque de todos los que han ido formando parte del modelo que ha desarrollado sobre el concepto de capacidad y madurez, hasta el actual CMMI. [17]

5.MEJORA DE LOS PROCESOS DE SOFTWARE

La mejora de procesos de Software (MPS) es un trmino que se usa cuando se referencian mejoras al proceso de software. Histricamente CMMI (y otros estndares y mtodos envueltos) y otras organizaciones aadieron un S para ampliar el alcance a sistemas y procesos de software (MPSS), mientras que otras organizaciones reemplazaron Software por Sistemas para guardar el mismo acrnimo: Mejora de Procesos de Sistemas (MPS) e incluir HW, SW, FW y WW. [21]

5.1Enfoque para MPS 4.2 British Computer Society (BCS):

Es una organizacin profesional y una sociedad cientfica que representa a las personas que trabajan en la tecnologa de la informacin. Establecida en 1957, es el ms grande de Reino Unido basados en un organismo profesional de la informtica. Cubre los ms de 68.000 miembros en ms de 100 pases, BCS es una sin fines de lucro y se incorpor por Carta Real en 1984. Sus objetivos son promover el estudio y la aplicacin de la tecnologa de las comunicaciones y la informtica y la tecnologa para avanzar en el conocimiento de la educacin en las TIC en beneficio de los profesionales y el pblico en general. [18] En la mejora de procesos de software podemos encontrar tres enfoques principales (o paradigmas) para la mejora de procesos de sistemas/software que se usan independientes o combinadas: Mejora apoyada en Modelos: este enfoque se basa en el uso de prcticas aceptadas por la industria como un modelo para mejorar una organizacin, que no est consolidada a estas prcticas. Frecuentemente se usan dos modelos: o Modelo de Madurez de capacidad integrada (CMMI) del Instituto de Ingeniera de Software (SEI). Conjunto de estndares de la ISO-9000 de la Organizacin Internacional para la estandarizacin.

4.3 IEEE Computer Society

En una unidad de organizacin del Instituto de Ingenieros Elctricos y Electrnicos (IEEE). Se estableci en 1963 cuando el Instituto Americano de Ingenieros Elctricos (AIEE) y el Instituto de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE. En el momento de la fusin, la AIEE del Subcomit de gran escala de Computacin (creado en 1946) se fusion con el IRE del Comit Tcnico de Electrnica Informtica (establecida 1948) para crear el Grupo de IEEE Computer. El grupo se convirti en el IEEE Computer Society en 1971.

Mejora de Procesos Bottom-Up: este enfoque se centra en hacer mediciones como tamao, esfuerzo, productividad, defectos, reuso y otros indicadores de procesos consiguiendo as datos de lneas-base y cuando se determina que habido mejoras potenciales el cambio se implementa. El efecto del cambio determina la ocurrencia de una mejora significativa y el resultado es usado para manejar el cambio organizacional.

Reingeniera de Negocios: establece mejor un cambio radical que un cambio incremental, un poco similar al enfoque Mejora de Procesos Bottom-Up.

7.REFERENCIAS
[1] Mario Piattini, Francisco J. Pino y Flix Garca,
Contribucin de los estndares internacionales a la gestin de procesos software, Facultad de Ingeniera Electrnica y Telecomunicaciones, Universidad del Cauca, Colombia http://www.aemes.org/rpm/descargar.php?volumen=4&nume ro=2&articulo=1

5.2 Grupos de Procesos de Ingeniera de Sistemas e Ingeniera de Software (SEPG)

Software Engineering Process Group, nombre original dado al servicio registrado del Instituto de Igeniera del Software (SEI) a los grupos responsables por las actividades de proceso de las organizaciones del software. Algunos de estos grupos son: SEPG: Grupo de Procesos de Ingeniera de Sistemas. SSEPG: Grupo de Procesos de Ingeniera de Software y Sistemas. SSPG: Grupo de Procesos de Software y Sistemas. PEG: Grupo de Ingeniera de Procesos. PIG: Grupo de Mejora de Procesos. QIG: Grupo de Mejora de Calidad. PTIG: Grupo de Mejora de Procesos y Tecnologa.

[2] Wikipedia,

Ingeniera de software, http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwar e Geogrfica sobre internet. Tesis de Maestra en Ciencias de la Computacin. Universidad Autnoma MetropolitanaAzcapotzalco. Mxico, D.F. En prensa, http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware. html#IngSoft

[3] Zavala R. 2000. Diseo de un Sistema de Informacin

[4] Luciano Guerrero, Monerreal: Canad, 1999, Ciclo de

Mejoramiento de Procesos, El modelo IDEAL,www.geocities.com/SiliconValley/Lab/3629/IDEA L_ciclo.pdf

6.CONCLUSIONES
Finalmente se puede concluir acerca del tema: Dentro del proceso de Ingeniera del Software los tres factores ms importantes son: Personal, Mtodos y Procedimientos y Herramientas y Tcnicas. El proceso de ingeniera del software est basado en procesos y modelos a la definicin, evaluacin y medicin del software. Existen modelos y procesos aplicados en las diferentes etapas del proceso de software. La facilidad de entendimiento humano y comunicacin, ayuda a llevar una buena definicin de los procesos. La medicin del Proceso de un Proyecto de Desarrollo de Software es primordial pues gracias a ste nos permite identificar las fuerzas y las debilidades del mismo y a su vez del proyecto. La recoleccin de mtricas del proceso es esencial para la mejora del mismo y se utilizan para evaluar la eficiencia de un proceso y si ste ha mejorado con los cambios realizados. Un producto de software constituye: los ejecutables, cdigo fuente, descripciones de arquitectura, y as. Medir un producto de software implica: la medicin del tamao del producto, la estructura del producto y la calidad del producto. Las mtricas en un proyecto de desarrollo de software e se pueden aplicar a procesos y productos. Las mtricas del proceso permiten a una organizacin de ingeniera del software tener una visin profunda de la eficacia de un proceso ya existente Dos modelos estandarizados que se los puede utilizar para la medicin de la calidad del Software son: CMMI y ISO 9000.

[5] Software process engineering systems: models and industry

cases, http://herkules.oulu.fi/isbn9514265084/html/x287.html

[6] Francisco Ruiz,

Procesos de Ingeniera del Software, http://personales.unican.es/ruizfr/is1/doc/teo/02/is1-t02trans.pdf bin/detail?product_id=1277365

[7] IEEE, IEEE 1074-2006, http://www.techstreet.com/cgi[8] IEEE Standard Association, IEEE Std 1074-1997 IEEE
Standard for Developing Software Life Cycle Processes Description, http://standards.ieee.org/reading/ieee/std_public/description/s e/1074-1997_desc.html

[9] Jin Lyu, Kyle Hancock y Linus Luotsinen, IEEE Standard

1219-1998 Software Maintenance, http://classes.cecs.ucf.edu/eel6883/berrios/slides/ch%209%2 0-%20art%202%20-%20IEEE%20Standard%2012191998.ppt

[10] Mtricas, [11] ISO/IEC [12] Fernanda

disponible en: r.uclm.es/doc/Calidad/capitulo09.ppt

http://alarcos.infen:

9126 disponible http://es.wikipedia.org/wiki/ISO/IEC_9126

Scalone, Software Quality Management, disponible en: http://softqm.blogspot.com/2007/01/visingeneral-acerca-de-iso-9126.html gestin financiera empresarial, http://ciruelo.uninorte.edu.co/pdf/pensamiento_gestion/23/6_ Inteligencia%20artificial.pdf

[13] Mara Del Carmen Sosa Sierra, Inteligencia artificial en la

[14] Carlos J. Alonso Gonzlez, Departamento de Informtica,

Induccin de Reglas Proposicionales, http://www.infor.uva.es/~calonso/IAII/Aprendizaje/Induccio nReglasProposicionales.pdf

[15] Wikipedia,

Normas ISO 9000 disponible http://es.wikipedia.org/wiki/Normas_ISO_9000

en:

[16] CINTERFOR, Gestin de calidad en la formacin

disponible en: http://www.ilo.org/public/spanish/region/ampro/cinterfor/te mas/calidad/doc/cedefop1.htm

[36] Wikipedia, disponible en:http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gi l_de_software [37] Gucoba disponible en: http://gucoba.com/index.php?option=com_content&vi ew=article&id=56&Itemid=57 [38] Monografias, disponibe en: http://www.monografias.com/trabajos67/metodologiadesarrollo-softwares/metodologia-desarrollosoftwares2.shtml [39] Mtodo CBA IPI para la evaluacin de proyectos,
Disponible en:

[17] Wikipedia, Software Engineering Institute disponible en:

http://es.wikipedia.org/wiki/Software_Engineering_Institute

[18] Wikipedia, British Computer Society disponible en:

http://en.wikipedia.org/wiki/British_Computer_Society

[19] Wikipedia, IEEE Computer Society disponible en:

http://en.wikipedia.org/wiki/IEEE_Computer_Society

[20] Wikipedia,

RUSSOFT disponible http://en.wikipedia.org/wiki/RUSSOFT, disponible http://www.slideshare.net/aacevedolipes/spin-colombia http://www.tamps.cinvestav.mx/~ertello/swe/sesion03.pdf

en: en:

http://www.geocities.com/SiliconValley/Lab/3629/cbai pi.htm [40] Metodologas De Desarrollo De Software,

Mendoza Sanchez , Mara A. 2004,

[21] Rduardo A. Rodrguez Tello, Procesos de software, 2008, [22] Chirstian Tzec, Fundamentos de Desarrollo de Sistemas,
http://www.scribd.com/doc/16416960/Modelo-cascadaespiralincremental

http://www.willydev.net/InsiteCreation/v1.0/descargas /cualmetodologia.pdf [41] Microsoft Solution Framework, figura tomada http://caraujo334.blogspot.es/img/msf1.jpeg

de:

[23] https://www.mytconsulting.com/principal/images/12207_5.p
ng

[42] http://www.mentores.net/default.aspx?tabid=104&type =art&site=183&parentid=32 [43] http://en.wikipedia.org/wiki/Microsoft_Solutions_Fra mework

[24] http://www.cs.umd.edu/users/basili/qip/img007.gif [25] http://es.kioskea.net/contents/genie-logiciel/cycle-devie.php3

[26] Sid@r,

Prototipado, http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/ Prototyping.htm a la Ingeniera de http://oacosta334.blogspot.es/tags/prototipo/ Software, 2009,

[27] Introduccin [28] Wikipedia,

Modelo de prototipos, http://es.wikipedia.org/wiki/Modelo_de_prototipos

[29] http://cmunoz334.blogspot.es/tags/Modelo/ [30] MODELOS

DE PROCESO ITERATIVOS INCREMENTALES, http://scruz334.blogspot.es/1193793960/ E

[31] Wikipedia, Desarrollo en espiral, Modificado: 16 abril del

2009, http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Ventajas

[32] Wikipedia, Desarrollo iterativo y creciente, Modificado 18

de Junio 2009, http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente #Debilidades_de_este_modelo_de_desarrollo

[33] Samira

Lamayzi, La norma ISO 14764, http://alarcos.infcr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf ro=2&articulo=1

1999,

[34] http://www.aemes.org/rpm/descargar.php?volumen=4&nume [35] Juan Pablo Gomez Gallego, Fundamentos de la

Metodologa RUP Rational Unified Process, 2007