Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
PROCESOS DE INGENIERÍA DEL SOFTWARE
          Armando Cabrera                                   Raquel Solano             ...
cuatro grandes fases: concepción, elaboración, construcción y
                                                            ...
la adopción de las prácticas recomendadas por el CMM, teniendo
variaciones de una entidad a otra dependiendo del tipo de
i...
define como una secuencia de fases como se muestra en la Figura       El modelo prototipado [26], modela el producto final...
•    El modelo iterativo: Este modelo mejora cada versión             •    Difícil de aplicar a sistemas transaccionales q...
o    Las alternativas                                        •    Demostrar valor iterativamente.
              o    Restr...
2.3.2.1.3Fase de Elaboración                                         configuración, instalación y facilidad de uso del pro...
•    Escalable: Puede organizar equipos tan pequeños entre
                                                               ...
Una de las ventajas de utilizar el proceso CMMI es el estándar de     Essential Unified        EssUP
evaluación por la que...
•    Grupos pequeños, trabajando en el mismo sitio y no                    documentación de actividades de mantenimiento d...
2.4.2Métodos de evaluación del proceso
Estos medos fueron desarrollados por el SW-CMM                           •    Plani...
Justificación                                                         que el software satisfaga las necesidades del usuari...
¿Quién puede utilizar esta norma?                                            •    Desarrollo y mejora de los procesos de l...
3.2.2 Marco Conceptual                                               La Computer Society declara "dedicada al avance de la...
•     Reingeniería de Negocios: establece mejor un cambio        7.REFERENCIAS
           radical que un cambio incrementa...
[15] Wikipedia,     “Normas ISO 9000” disponible                 en:   [36] Wikipedia,                                   d...
Upcoming SlideShare
Loading in …5
×

Procesos De Ingenieria Del Software

68,665 views

Published on

Acerca de Métodos y Procesos de Ingeniería de Software

Published in: Education, Technology, Business

Procesos De Ingenieria Del Software

  1. 1. PROCESOS DE INGENIERÍA DEL SOFTWARE Armando Cabrera Raquel Solano Mayra Montalván Loja, Ecuador Loja, Ecuador Loja, Ecuador aacabrera@utpl.edu.ec rfsolano@utpl.edu.ec mamontalvan@utpl.edu.ec RESUMEN “Cuando puedas medir lo que estás diciendo y expresarlo en números, sabrás algo acerca de eso; pero cuando no puedes El proceso de Ingeniería del Software se basa en modelos, medirlo, cuando no puedes expresarlo en números, tus métodos y herramientas que sirven como una guía para los conocimientos serán escasos y no satisfactorios” ingenieros del software durante el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos, procesos y Lord Kelvin productos mediante la evaluación y medición de los mismos. El objetivo de las organizaciones desarrolladoras de estos modelos, La medición en general tiene tres principales objetivos: entender procesos y metodologías es que en las empresas desarrolladoras qué ocurre durante el desarrollo y el mantenimiento, mejorar de software se los ponga en práctica para ver las mejoras en los nuestros procesos y nuestros productos y controlar lo que ocurre procesos de cada una de las fases de desarrollo. Otro tema en nuestros proyectos. Dentro de la gestión de proyectos de importante son los modelos del ciclo de vida del software, los desarrollo de software las métricas juegan un papel importante cuales se basan en diferentes técnicas y fases pero todos tienen un para entender, monitorizar, controlar, predecir y probar el mismo fin. desarrollo de software. Las métricas son medio para asegurar la calidad en los PRODUCTOS / PROCESOS / PROYECTOS El fin de este trabajo es establecer un entorno general alrededor de SOFTWARE. las aplicaciones y definiciones actuales del Proceso de Ingeniería del Software, el mismo que puede reconocerse en dos niveles: el Objetivos primero involucra actividades técnicas y de gestión durante la Los principales objetivos del desarrollo de este trabajo son: adquisición, desarrollo, mantenimiento y retirada del software en el procesos del ciclo de vida del software y el segundo se refiere a • Comprender los conceptos principales relacionados con la definición, implementación, valoración, medición, gestión, el proceso de ingeniería de software y ciclo de vida del cambios y mejoras de los procesos mismo del ciclo de vida del software. software. Algunos modelos estandarizados para la medición de la • Conocer los métodos y modelos que se aplican calidad como lo son: CMMI e ISO 9000, son mencionados. actualmente en la ingeniería del software. • Conocer los principales ciclos de vida del software. Términos Generales Software, Procesos, Métodos, Modelos, Desarrollo de Software, 2.ESTADO DEL ARTE Ingeniería del Software, Procesos del Software Palabras claves 2.1 Conceptos de procesos de ingeniería del CMMI software QIP Modelo Ágil RUP Modelo Cascada 1.INTRODUCCIÓN El proceso de ingeniería del software puede ser visto desde dos enfoques: El primero: ciclo de vida del software, procesos durante la adquisición, desarrollo, mantenimiento y cierre y el segundo con definición, implementación, evaluación, 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 prácticas actuales y Figura 1. Elementos del proceso de software [6] que sean aplicados en el desarrollo de software, tales modelos como CMMI, IDEAL, QIP, entre otros.
  2. 2. cuatro grandes fases: concepción, elaboración, construcción y transición. • Concepción: Define el alcance del proyecto y desarrolla un caso de negocio. • Elaboración: Define un plan del proyecto, especifica las características y fundamenta la arquitectura. • Construcción: Crea el producto. • Transición: Transfiere el producto a los usuarios. En la Figura 1, se muestra los elementos principales del proceso de Software que son: Personal. Métodos y Procedimientos y Herramientas y Tecnologías. 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 2.1.1Proceso de Software Un concepto dado por IEEE 1074 [6] es, el ciclo de vida del software es una aproximación lógica a la adquisición, el Según Piatini [2] El proceso de software es un conjunto coherente suministro, el desarrollo, la explotación y el mantenimiento del de: políticas, estructuras organizacionales, tecnologías, software” procedimientos y artefactos; que son necesarios para: concebir, Y otro concepto dado por ISO 12207 “Es un marco de referencia desarrollar, instalar y mantener un producto software. que contiene los procesos, las actividades y las tareas 2.1.2Ingeniería del Software involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde Se puede decir que Ingeniería de software [1], es la disciplina o la definición de los requisitos hasta la finalización de su uso” área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad. 2.2Procesos de implementación y cambios Existen algunos conceptos de Ingenierita del Software, a 2.2.1Modelos para Procesos de Implementación y continuación se lista conceptos de autores más reconocidos: Cambios • Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de A continuación se trata dos modelos principales para sistemas software (Zelkovitz, 1978) mejoramiento de procesos: Modelo IDEAL y modelo QIP (Quality Improvement Paradigm) • Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación 2.2.1.1Modelo IDEAL asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software (Bohem, 1976). • Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972). • Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993). 2.1.3Proceso de Ingeniería del Software El proceso de ingeniería de software [3], se define como "un conjunto de etapas parcialmente ordenadas con la intención de Figura 3. Modelo IDEAL [23] lograr un objetivo, en este caso, la obtención de un producto de software de calidad" [Jacobson 1998]. A este proceso El modelo IDEAL [4], es un ciclo de mejoramiento de procesos, también se le llama el ciclo de vida del software que comprende proporciona un conjunto de actividades coherentes para sustentar
  3. 3. la adopción de las prácticas recomendadas por el CMM, teniendo variaciones de una entidad a otra dependiendo del tipo de industria de software, tamaño de organización y modalidades de operación. Las 5 fases principales que componen el modelo son: 1. Iniciar.- Establece los fundamentos básicos para garantizar la iniciativa de mejoramiento de procesos. Cuyas actividades son: a. Estimulo para iniciar el mejoramiento b. Establecimiento del contexto c. Establecer patrocinio de la gerencia d. Establecer infraestructura para el mejoramiento e. Evaluar y caracterizar el estado actual de las practicas Figura 4. Modelo QIP [24] f. Desarrollar recomendaciones y documentar los resultados de la fase Otro de los modelos reconocidos es el modelo QIP [5] El propósito de este modelo es apoyar el proceso de mejora continua 2. Diagnosticar.- Evalúa mediante un método formal las y la ingeniería de los procesos de desarrollo, para ayudar en la fortalezas y debilidades del proceso seguido por los tecnología de perfusión. Una forma de ver el modelo es también proyectos. Las principales actividades son: verlo como un modelo para la organización de aprendizaje, donde a. Evaluar y caracterizar el estado actual de las la organización establece una forma de desarrollar las prácticas a practicas través de la experimentación con ellos y, a continuación, la captura y el paquete en una forma que pueden ser reutilizados en b. Desarrollar recomendaciones y documentar otras partes, dentro de ciertos límites. los resultados de la fase QIP esta basado en las principales disciplinas del software, por 3. Establecer.- realiza la planificación especifica de los eso es natural, revolucionario y experimental. El trabajo para mejoramientos que desea alcanzar. Principales desarrollo de software se basa en los humanos y su diseño de actividades: trabajo. a. Establecer los equipos de acción de procesos 2.3Definición de procesos b. Elaboración del Plan de Acción 2.3.1Modelos del ciclo de Vida del Software 4. Actuar.- Implementa el mejoramiento de procesos Existen varios modelos del ciclo de vida del software, sin llevando a cabo el plan de acción. Sus características embargo los mas utilizados son: Cascada, Prototipado, son: Incremental y en Espiral a. Planificar, ejecutar y seguir la instalación b. Planificar y ejecutar proyectos piloto 2.3.1.1Cascada c. Refinar la solución d. Implementar la solución 5. Difundir.- Aprende de la experiencia del ciclo recién realizado y aumenta la habilidad de la empresa u organización para mejorar los procesos en forma continua. Sus características son: a. Documentar y analizar las lecciones. b. Revisar el enfoque seguido y proponer acciones futuras. 2.2.1.2Modelo QIP Figura 5. Modelo en Cascada [6] Este modelo es conocido también como ciclo de vida lineal o básica. Este modelo admite la posibilidad de hacer iteraciones. Se
  4. 4. define como una secuencia de fases como se muestra en la Figura El modelo prototipado [26], modela el producto final y permite 5, en la que al final de cada una de ellas se reúne la efectuar un test sobre determinados atributos del mismo sin documentación para garantizar que cumple las especificaciones y necesidad de que este disponible. Se trata, simplemente, de testear los requisitos antes de pasar a la fase siguiente. [25] haciendo uso del modelo. Esta técnica puede ser utilizada en Sus principales características son [6]: cualquier etapa de desarrollo. A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez más • Cada fase empieza cuando se ha terminado la fase las características del producto final. En la Figura 6 se listan las anterior fases del modelo Prototipado. • Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa Existen varios tipos como: • Al final de cada fase el personal técnico y los usuarios • Prototipado – Rápido tienen la oportunidad de revisar el progreso del • Prototipado – Evolutivo proyecto • Prototipado – Operacional • Prototipado – Reutilizable Las ventajas y desventajas [21], de este modelo se describen a continuación: Los prototipos [6], tienen una doble función: • El cliente ve el producto y refina sus requisitos 2.3.1.1.1Ventajas • El desarrollador comprende mejor lo que necesita hacer • Ayuda a prevenir que se sobrepasen las fechas de Sus principales características son: entrega y los costes esperados • Bajo riesgo para desarrollos bien comprendidos • Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuario utilizando tecnología conocida. o Reduce costos y aumenta la probabilidad de • Este modelo es sencillo ya que sigue los pasos intuitivos éxito necesarios a la hora de desarrollar el software. o Exige disponer de las herramientas adecuadas o No presenta calidad ni robustez 2.3.1.1.2Desventajas • Suele utilizarse principalmente en dos áreas: • Su inflexibilidad en la división del proyecto en distintas o Prototipado de la interfaz de usuario etapas o Prototipado del rendimiento • Esto hace difícil poder responder a los cambios en los Las ventajas y desventajas [27], [28], se listan a continuación: requerimientos del cliente. 2.3.1.2.1Ventajas • Se tarda mucho tiempo en pasar por todo el ciclo • El mantenimiento se realiza en el código fuente • Las revisiones de proyectos de gran complejidad son • Es mucho mejor y conveniente usar este modelo porque muy difíciles es el único apto para desarrollos en los que se utiliza nueva tecnología. • Para obtener resultados se debe llegar a la etapa final del proyecto. Un error importante no detectado hasta • El prototipado es un medio excelente para recoger la que el programa este funcionando puede ser desastroso. realimentación del usuario final, así como también es mucho más rápido de desarrollarse. 2.3.1.2Prototipado • El cliente se va familiarizando con el nuevo producto. • Permite proporcionar una funcionalidad útil en manos del cliente sin tener la aplicación finalizada. 2.3.1.2.2Desventajas • No hay que usar en casos experimentales ya que no puede funcionar. • La gestión 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 difícil 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 retroalimentación por lo que nos ayudan a tener una mejor arquitectura del software y Figura 6. Modelo Prototipado [6] son muy útiles cuando el usuario tiene más requerimientos.
  5. 5. • El modelo iterativo: Este modelo mejora cada versión • Difícil de aplicar a sistemas transaccionales que tienden es decir mejora la función que tiene la versión. a ser integrados y a operar como un todo. • El modelo incremental: Este modelo mantiene la • Los errores en los requisitos se detectan tarde y su función anterior y aumenta otra, ya que puede ser que el corrección resulta costosa primer incremento no hubiera tenido todos los • Necesitan una gran planeación. requerimientos que necesitaba el proyecto. • Debido a la interacción con los usuarios finales, cuando sea necesaria la retroalimentación hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances extremadamente lentos. • No es una aplicación ideal para desarrollos en los que de antemano se sabe que serán 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 compañía, pues mientras estos usuarios evalúan el software dejan de ser directamente productivos para la compañía. 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 características son: • Corrige la necesidad de una secuencia no lineal de pasos de desarrollo • El sistema se crea añadiendo componentes funcionales al sistema incrementos • El sistema no se ve como una entidad monolítica con una fecha fija de entrega, sino que es una integración de resultados sucesivos obtenidos después de cada iteración Figura 8. Modelo en Espiral [6] • Se ajusta a entornos de alta incertidumbre El modelo en Espiral que se muestra en la Figura 8, es un modelo Las ventajas y desventajas de este modelo son [30] [32]: de proceso de software evolutivo que combina la naturaleza iterativa de construcción de prototipos con los aspectos 2.3.1.3.1Ventajas controlados y sistemáticos del modelo lineal secuencial. • Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia. Según Wikipedia [31], las actividades de este modelo se • El usuario se involucra más. conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están • Mayor retorno de la inversión. fijadas a priori, sino que las siguientes se eligen en función del • Disminuyen riesgos análisis de riesgo, comenzando por el bucle interior. El software • Se puede cambiar los requerimientos pues como nos se desarrolla en una serie de versiones incrementales. basamos en una versión a esta la aumentamos o la modificamos. • Durante las primeras iteraciones, la versión incremental • Reduce costos, si algo sale mal solo volvemos a la podría ser un modelo en papel o un prototipo. antigua versión y comenzamos de nuevo. • Durante las últimas iteraciones, se producen versiones • Al usuario se le entrega parte del producto, es decir una cada vez más completas del sistema diseñado. versión con la cual el puede trabajar. Sus principales características son: 2.3.1.3.2Desventajas • Cada ciclo empieza identificando: • Difícil de evaluar el coste total. o Los objetivos de la porción correspondiente • Requiere gestores experimentados.
  6. 6. o Las alternativas • Demostrar valor iterativamente. o Restricciones • Elevar el valor de abstracción. • Se evalúan las alternativas respecto a los objetivos y las • Enfocarse en la calidad. restricciones. • Se formula una estrategia efectiva para resolver las 2.3.2.1.1Ciclo de vida de RUP fuentes de riesgos (simulación, prototipado, etc.). • Se plantea el próximo prototipo. El proceso del RUP está dividido en 4 fases, en estas fases se • Una vez resueltos los riesgos se sigue el ciclo en realiza varias iteraciones de acuerdo al proyecto, en la Figura 9 se cascada muestra gráficamente las 4 fases del RUP, cuyas iteraciones están • Cada ciclo se completa con una revisión que incluye representadas con líneas verticales y marcadas con la letra todo el ciclo anterior y el plan para el siguiente. correspondiente a la inicial de la fase, la fase Inicial tiene una sola iteración. Las ventajas y desventajas de este modelo son [31]: 2.3.1.4.1Ventajas • No necesita una definición completa de los requisitos para empezar a funcionar. • Al entregar productos desde el final de la primera iteración es mas fácil 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 iteración • El riesgo de sufrir retrasos es menor ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos, • El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. • Reduce riesgos del proyecto • Incorpora objetivos de calidad Figura 9. Fases del RUP [35] • Integra el desarrollo con el mantenimiento, etc. 2.3.2.1.2Fase de Inicio 2.3.1.4.2Desventajas • Es difícil evaluar los riesgos En esta fase se define el modelo del negocio y el alcance del • Necesita de la participación continua por parte del proyecto, se identifican los autores y casos de usos y se diseñan cliente los casos de uso esenciales. • Cuando se subcontrata hay que producir previamente Los objetivos son: una especificación completa de lo que se necesita y esto lleva tiempo. • Establecer el ámbito del proyecto y sus limites • Genera mucho tiempo en el desarrollo del sistema • Encontrar los casos de uso críticos del sistema, los • Modelo costoso requiere experiencia en la escenarios básicos. identificación de riesgos • Mostrar una arquitectura para los escenarios principales. • Estimar el coste en recursos y tiempo en todo el 2.3.2Metodologías de desarrollo de software proyecto. • Estimar los riesgos, las fuentes de incertidumbre. 2.3.2.1RUP Los resultados de la fase son: • Documento de visión RUP [35] es un proceso para el desarrollo de un proyecto de • Modelo inicial de casos de uso software que define quien, como, cuando y que debe hacerse en el • Glosario inicial proyecto, con 3 características esenciales como: Casos de uso, centrado n la arquitectura y es iterativo e incremental. • Caso de negocio • Lista de riesgos y plan de contingencia El RUP maneja 6 principios clave: • Plan del proyecto • Adaptación del proceso. • Modelo de negocio • Balancear prioridades. • Colaboración entre equipos.
  7. 7. 2.3.2.1.3Fase de Elaboración configuración, instalación y facilidad de uso del producto. En esta fase también se realiza: En esta fase se analiza el dominio del problema, establece los cimientos de la arquitectura, desarrolla el plan del proyecto y • La prueba de la versión beta para validar al nuevo elimina los riesgos mayores. Se construye un prototipo de la sistema frente a las expectativas del usuario. arquitectura que evoluciona en iteraciones sucesivas hasta • Funcionamiento paralelo con los sistemas legados que convertirse en el sistema final. están siendo sustituidos por el nuevo proyecto. Los objetivos de esta fase son: • Conversión de las bases de datos operacionales. • Definir, validar y cimentar la arquitectura. • Entrenamiento de los usuarios y técnicos de • Completar la visión mantenimiento. • Crear un plan para la fase de construcción • Traspaso del producto a los equipos de marketing, • Demostrar que la arquitectura propuesta soportara la distribución y venta. visión Los objetivos de esta fase son: • Los resultados son los siguientes: • Un modelo de casos de uso al menos el 80% • Conseguir que el usuario se valga por si mismo. • Requisitos adicionales que capturan los requisitos no • Un producto final que cumpla los requisitos esperados, funcionales. que funcione y satisfaga suficientemente al usuario. • Descripción de la arquitectura software Los resultados son: • Prototipo ejecutable de la arquitectura. • Lista de riesgos y caso de negocio revisados • Plan de desarrollo para el proyecto • Prototipo operacional • Manual de usuario preliminar. • Documentos legales • Caso del negocio completo • Línea base del producto completa y corregida que 2.3.2.1.4Fase de Construcción incluye todos los modelos del sistema • Descripción de la Arquitectura completa y corregida. En esta fase la finalidad es alcanzar la capacidad operacional del • Las iteraciones de esta fase irán dirigidas normalmente producto de forma incremental a través de las sucesivas a conseguir una nueva versión. iteraciones, en esta fase todas las componentes, características y requisitos deben ser implementados, integrados y cambiados en su Los criterios de evaluación de esta fase son: totalidad. Los objetivos son: • El usuario se encuentra satisfecho. • Minimizar los costes de desarrollo mediante la • Son aceptables los gastos actuales versus los gastos planificados. optimización de recursos. • Conseguir calidad adecuada. • Conseguir versiones funcionales tan rápido como sea práctico. 2.3.2.2MSF Los resultados de la fase de construcción deben ser: La metodología MSF (Microsoft Solucion Framework) [40], es flexible e interrelacionada con una serie de conceptos, modelos y • Modelos completos(casos de uso, análisis, diseño, prácticas de uso, y guías para diseñar y desarrollar soluciones despliegue e implementación) empresariales de una manera que asegura que todos los elementos • Arquitectura integra. del proyecto tal como gente, procesos y herramientas, puedan ser • Riesgos presentados mitigados exitosamente conducidos. • Plan del proyecto para la fase de transición. • Manual inicial de usuario. MSF no sólo es aplicable al desarrollo de proyectos de desarrollo, • Prototipo operacional. también es aplicable a otros proyectos de TI, como el despliegue • Caso del negocio actualizado. o proyectos de infraestructura o redes. MSF no fuerza al desarrollador a utilizar una metodología específica (Cascada, 2.3.2.1.5Fase de Transición ágil), pero les permite decidir qué método utilizar. 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 documentación, entrenar al usuario en el manejo del producto y tareas relacionadas con el ajuste,
  8. 8. • Escalable: Puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más. • Flexible: Es utilizada en el ambiente de desarrollo de cualquier cliente. • Tecnología Agnóstica: Porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología. Principios fundamentales en los que se basa MSF MSF propone una secuencia generalizada de actividades para la construcción de soluciones empresariales, este proceso es flexible y se puede adaptar al diseño y desarrollo de una amplia gama de proyectos de una empresa, además está basado en fases, puntos de transición y de carga de forma iterativa que se puede aplicar en el desarrollo de aplicaciones tradicionales, soluciones empresariales para comercio electrónico así como aplicaciones Web distribuidas. Los principios en los que se fundamenta MSF son: Figura 10. Fases del modelo MSF [41] • Fomentar la comunicación abierta. El MSF está compuesto 6 por fases, como se muestra en la Figura • Trabajar en pro de una visión compartida. 10, las fases se listan a continuación: • La autonomía de los miembros del equipo. 1. Visión: donde se reúne un equipo del proyecto, define • Establecer una clara rendición de cuentas y la la visión y el ámbito de una solución que cumplirá los responsabilidad compartida. objetivos del cliente. El equipo organiza entonces el • Centrarse en entregar valor de negocio. proyecto y proporciona un documento de visión/ámbito • Mantenerse ágil a espera del cambio. aprobado. Las personas encargadas de funciones de • Invertir en calidad. administración de productos y administración de • Aprender de todas las experiencias. programas toman el mando en esta fase. 2. Planeación: donde se desarrollan los procesos de MSF para Metodologías de Desarrollo Ágil (MSF4ASD) diseño conceptual, lógico y físico, así como la MSF para Metodologías de Desarrollo Ágil es un proceso de especificación funcional. La persona encargada de desarrollo manejado por escenarios, basado en contexto, que funciones de administración de programas toma el utiliza muchas de las ideas incorporadas en Team System mando durante esta fase y crea planes de proyecto que (herramientas de Microsoft). Este proceso incorpora las prácticas tratan el desarrollo, la comunicación y otras tareas; y probadas desarrolladas en Microsoft con respecto a los cada función proporciona los datos para crear la requerimientos, diseño, seguridades, rendimiento y pruebas programación del proyecto. (testing) [42]. MSF para metodologías de desarrollo ágil presenta una guía 3. Desarrollo: El equipo crea y prueba la solución. La persona encargada de funciones de desarrollo toma el muy recomendable a los Desarrolladores y Gestores de proyectos mando durante esta fase. de software que pueden adaptarla a la metodología de su empresa, en la que incluye documentos de ejemplo, plantillas, archivos en 4. Estabilización: El equipo crea la solución piloto en blanco de Project, Excel y Word para la administración de preparación para el lanzamiento de producción. La proyectos, requerimientos, seguridad y pruebas. persona encargada de las funciones de prueba toma el mando durante esta fase. MSF para CMMI (MSF4CMMI) EL MSF4CMMI para CMMI es una metodología formal para la 5. Instalación. ingeniería de software es un proceso de mejora que proporciona a las organizaciones los elementos esenciales del proceso continuo 6. Soporte de mejora que den lugar a una reducción de Ciclo de vida del Las características más relevantes del MSF son: Desarrollo de Software, la mejora de la capacidad para satisfacer • Adaptable: Es parecido a un compás, usado en las metas de costos y el calendario, la construcción de productos cualquier parte como un mapa, del cual su uso es de alta calidad. limitado a un específico lugar. El MSF4CMMI se ha ampliado una orientación MSF4ASD con una formalidad adicional, evaluación, verificación y auditoría [43].
  9. 9. Una de las ventajas de utilizar el proceso CMMI es el estándar de Essential Unified EssUP evaluación por la que uno puede comparar la capacidad de Process desarrollar software en otras organizaciones. Feature Driven FDD De Luca & Coad Development 1998 Palmer & 2.3.2.3Modelo Ágil Felsing 2002, Lean LD Charette 2001, Development El Modelo de Desarrollo Ágil se originó a mediados de los años Mary y Tom 1990 y se podría decir que fue extraído del modelo de desarrollo Poppendieck en cascada, pues éste último era visto como burocrático, lento, Programación XP Beck 1999 degradante e inconsistente por lo exigente y muy estructurado en Extrema sus formas de desarrollo de software que sin embargo realizaban un trabajo eficiente. Scrum Scrum Sutherland 1994 En el año 2001, miembros prominentes de la comunidad de la Schwaber 1995 industria del software se reunieron en Sonwbird, Utah, y Microsoft MSF Microsoft 1994 adoptaron el nombre de "Metodologías ágiles"[36]. Solutions El modelo de desarrollo ágil es un paradigma de Desarrollo de Framework Software que utiliza procesos ágiles (pequeñas y frecuentes Rapid RAD McConnell 1996 entregas con ciclos rápidos) enfocados en la gente y resultados, se Development podría decir que es: Open Unified OpenUP • Cooperativo, clientes y desarrolladores trabajan constantemente con una comunicación muy fina y Process constante, Rational Unified RUP Krutchen 1996 • Sencillo, método fácil de aprender y modificar para el Process equipo pues la reducción de documentación se reemplaza por la constante comunicación, y Algunas empresas que usan metodologías de desarrollo ágil en • Adaptativo, capaz de permitir cambios de último algunos de sus proyectos, son: momento. • Google, El objetivo de este modelo es desarrollar software rápidamente, respondiendo a los cambios que puedan surgir a lo largo del • Oracle, proyecto. • Yahoo, • Canon, Esta metodología propone que un pequeño grupo de personas (10 como máximo) conformado de los más experimentados y capaces • Xerox, ingenieros de software, trabajen en el desarrollo de iteraciones • Sun, (software desarrollado en una unidad de tiempo) con una duración • HP, máxima de hasta 4 semanas y desarrollando una serie de “user • Nokia, stories” (Casos de Uso) que al final cumplan con los • Honda, requerimientos establecidos en línea directa por los usuarios • Toyota, etc. finales del sistema [37]. 2.3.2.3.2Ventajas: 2.3.2.3.1Metodologías Agiles • Métodos de comunicación más eficaces en este tipo de Hacemos mención de algunas metodologías ágiles de desarrollo metodologías. de software en la Tabla 1, estas metodologías son: • Es posible identificar y atacar los problemas más críticos y controversiales del proyecto en las primeras Tabla 1. Lista de Metodologías Ágiles etapas. • El cliente comenzará a ver su sistema lo más pronto Metodología Acrónimo Creación posible y verificar que se están cubriendo sus Adaptive ASD Highsmith 2000 requerimientos de forma adecuada. Software • Entrega de resultados tangibles en etapas tempranas del Development proyecto. Agile Modeling AM Ambler 2002 2.3.2.3.3Desventajas: Agile RUP dx Booch, Martin, • Proceso menos controlado y con pocos principios. Newkirk 1998 • No existe contrato tradicional o al menos es bastante Crystal Methods CM Cockbum 1998 flexible.
  10. 10. • Grupos pequeños, trabajando en el mismo sitio y no documentación de actividades de mantenimiento de distribuidos adecuadamente. software. • Menos énfasis en la arquitectura del software, siendo ésta primordial para el éxito del proyecto de software. 2.3.3.2.2 ISO 14764:1998 2.3.2.3.4Uso de Metodologías Éste estándar 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 El surgimiento de estas revolucionarias metodologías que no solo de vida de un producto software. En muchos proyectos, nacen para el desarrollo de sistemas software sino para el manejo especialmente aquellos que tienen una vida larga, el o desarrollo de productos los incrementos en adeptos se presentan mantenimiento del software es con seguridad una de las gradualmente con el tiempo y las tecnologías. En la Figura 11, se consideraciones más importantes del proyecto. Por esta razón es muestra [38] necesario ser capaces de corregir los fallos que se encuentran durante su manejo. Mantenimiento de Software se puede hacer combinando herramientas software, métodos y técnicas, se aplica a programas de ordenador, código, datos, y documentación. Se intenta que se aplique a productos software creados durante el desarrollo del producto software. Éste estándar 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.3.3ISO 9001-2000 Figura 11. Uso de Métodos Ágiles [38] El estándar o norma ISO 9001:2000 (Quality management systems –Requirements) que significa Calidad del manejo de requerimientos del sistema, especifica los requerimientos para el 2.3.3Procesos del ciclo de vida del Software manejo de la calidad de un sistema organizacional proveyendo requerimientos de los productos y satisfacción del cliente. Primario se basa en la calidad del software, y segundo en los 2.3.3.1Estándar IEEE 1074 procesos de ingeniería del software. El estándar IEEE 1074 [7] y [8], es un estándar para la generación de los que rigen el proceso de desarrollo de software y mantenimiento de un proyecto. Este estándar requiere la selección 2.4Evaluación de Procesos de proyectos de software y modelos de ciclo de vida, basado en la misión, visión, metas y recursos de las organizaciones. También 2.4.1Modelos de Evaluación del proceso describe las diferentes actividades que van a ser asignada en el modelo seleccionado. Sin embargo, este estándar no es una guía 2.4.1.1CMMI de instrucción. También puede ser utilizado para desarrollar los procesos de organización para apoyar el desarrollo de software y CMMi intenta proveer una guía para los procesos. Las áreas procesos que tiene una única función dentro de un proyecto. específicas relacionadas son: 2.3.3.2Procesos de Mantenimiento: • Calidad de proceso y producto 2.3.3.2.1 IEEE 1219-1998 • Verificación del proceso • Validación del proceso El estándar IEEE 1219-1998 [9], se basa en procesos iterativos para ejecutar y manejar el mantenimiento de software. Hubo inicialmente algún debate sobre si la ISO 9001 o CMMi Los procesos están aplicados a: podrían ser usadas por los ingenieros del software para asegurar la calidad. Este debate fue publicado y como resultado la decisión • Planeación de mantenimiento mientras el producto está ha sido tomada que los dos son complementarios y que desarrollándose. teniendo certificación ISO 9001 puede ayudar grandiosamente en • Planeación y ejecución de mantenimiento para altos niveles de madurez del CMMi. [6] productos de software existente. El modelo CMMI es un modelo de calidad del software que • Aplica cualquiera de los modelos del ciclo de vida clasifica las empresas en niveles de madurez. Estos niveles sirven disponibles. para conocer la madurez de los procesos que se realizan para • Estándares prescriben los requerimientos para procesos, producir software. control y manejo de la planeación, ejecución y
  11. 11. 2.4.2Métodos de evaluación del proceso Estos medos fueron desarrollados por el SW-CMM • Planificar el Proceso de Medición que implica tareas como: 2.4.2.1CBA-IPI o Obtener características de la Organización. o Identificar las necesidades de la Información. El CBA-IPI [39], es un método de evaluación basado en CMM o Seleccionar las medidas. sirve para mejorar internamente los procesos, fue desarrollado por o Definir los procedimientos de recolección de el Softare Engneer Institute de la Universidad Carnegie Mellon. datos, análisis e informes. Es una herramienta de diagnostico que permite a las o Definir los criterios de evaluación de los organizaciones y proyectos el poder determinar las fortalezas y de productos de información y el proceso de sus procesos de desarrollo de software, utiliza el método de medición. madurez de capacidades para software desarrollado por el SEI o Revisar, aprobar y proporcionar recursos para las tareas de medición. 2.4.2.2SCAMPI o Adquirir y utilizar tecnologías de apoyo. Los métodos SCAMPI son grandes torres de evaluación CMMi. • Realizar el Proceso de Medición que implica tareas Las actividades ejecutadas durante una evaluación, la distribución como: de esfuerzo en estas actividades como la atmosfera durante una o Integrar los procedimientos, evaluación son diferentes cuando son de mejora para la o Recoger los datos, adjudicación de un contrato. o Analizar los datos y desarrollar productos de información. o Comunicar los resultados. 2.5Medidas de Productos y Procesos • Evaluar la Medición que implica tareas como: o Evaluar productos de información y el La medición de software es una disciplina relativamente joven, proceso de medición, consenso general sobre la definición exacta de los conceptos y o Identificar las mejoras potenciales. terminología que maneja, aunque términos clave de medición del software y métodos de medición han sido definidos en la ISO/IEC 15939 basados en el vocabulario ISO internacional de metrología. 2.5.1Medición del Proceso: ISO 15539-02 A pesar de todo, los lectores encontrarán diferencias terminológicas en la literatura; por ejemplo, el término “métrica” La medición del Proceso significa recoger, analizar e interpretar se utiliza a veces en vez de “medida”. En la Figura1 se muestra el información cuantitativa sobre nuestros procesos, para identificar ámbito de ISO/IEC 15939: [10] las fuerzas y las debilidades de los mismos y para evaluarlos después de que hayan sido implementados y/o cambiados. Muchos son los propósitos que abarca la medición del Proceso en el presente caso de estudio nos centraremos en la medición del proceso para gestionar un proyecto de software enfocado en la implementación 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 utilización de herramientas y de hardware, un recurso principal que necesita ser gestionado en la ingeniería del software es el personal. Existen tres tipos de métricas 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/día, costes de viajes, recursos de hardware, etc. Figura 12. Ámbito de la ISO/IEC 15939 [10] • Número de Ocurrencias de un Evento número de defectos descubiertos durante la revisión del código, Las actividades de la ISO/IEC 15939 son: número de peticiones de cambio en requerimientos, número promedio de líneas de código (LDC) • Establecer y Mantener el Compromiso de Medición que modificadas en respuesta a un cambio de implica tareas como: requerimientos, errores detectados por el usuario, etc. o Aceptar los requisitos de medición. o Asignar recursos.
  12. 12. Justificación que el software satisfaga las necesidades del usuario), que son manifestadas externamente cuando el software es utilizado, y son La recolección de métricas del proceso es esencial para la mejora un resultado de atributos internos del software. El modelo de del mismo y se utilizan para evaluar la eficiencia de un proceso y calidad de ISO 9126-1 establece 3 niveles: (1) Característica, (2) si éste ha mejorado con los cambios realizados. Subcaracterística y (3) Métricas. [12] • Las dos primeras métricas ayudan a descubrir si los Características de calidad del ISO 9126-1:2001: cambios en el proceso mejoran la eficiencia de un • Funcionalidad: conjunto de atributos que se relacionan proceso. Por ejemplo, se puede medir el tiempo y con la existencia de un conjunto de funciones y sus esfuerzo necesarios para moverse de un hitos fijo a otro, propiedades específicas. Las funciones son aquellas que como la aceptación de requerimientos, terminación de satisfacen lo indicado o implica necesidades. Las un diseño arquitectónico, etc. Esos valores ayudan a subcaracterísticas son: Idoneidad, Exactitud identificar áreas de mejora en el proceso. Una vez Interoperabilidad, Seguridad, Cumplimiento de normas. introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos. • Fiabilidad: conjunto de atributos relacionados con la capacidad del software de mantener su nivel de • El número de ocurrencias de un Evento Tienen prestación bajo condiciones establecidas durante un influencia directa en la calidad del software. Por período de tiempo establecido. Las subcaracterísticas ejemplo, incrementar el número de defectos son: Madurez, Tolerancia a fallas, Facilidad de descubiertos al cambiar el proceso de revisión del Recuperación, Conformidad de Fiabilidad. código probablemente se reflejará en una mejora de la calidad del producto, aunque tiene que confirmarse por • Usabilidad: conjunto de atributos relacionados con el mediciones posteriores del producto. esfuerzo necesitado para el uso, y en la valoración individual de tal uso, por un establecido o implicado Se describiría a las salidas de los procesos como: calidad del conjunto de usuarios. Las subcaracterísticas son: producto (errores por KLOC (Kilo Líneas de Código) o por Punto Aprendizaje, Comprensión, Operatividad, Atractividad, Función (FP)), mantenibilidad (el esfuerzo para hacer un cierto Conformidad de Usabilidad tipo de cambio), productividad (LDC (Líneas de Código)) o Puntos Función por persona-mes), tiempo-de-mercado, o • Eficiencia: conjunto de atributos que se refieren a las satisfacción del cliente (como medidos por medio de una encuesta relaciones entre el nivel de rendimiento del software y a clientes). Esta relación depende del contexto particular (por la cantidad de recursos utilizados bajo unas condiciones ejemplo, el tamaño de la organización o el tamaño del proyecto). predefinidas. Las subcaracterísticas son: Compartimiento en el tiempo, Compartimiento de De allí que el obtener las salidas del proceso que deseamos recursos, Conformidad de eficiencia. significa que se debió haber implementado los procesos • Mantenibilidad: conjunto de atributos relacionados con adecuados. la facilidad de extender, modificar o corregir errores en un sistema software. Las subcaracterísticas de la 2.5.2Medición del Producto: ISO 9126-01 Facilidad de Mantenimiento son: Facilidad de análisis, Facilidad de cambio, Estabilidad y Facilidad de prueba. ¿Qué es un producto de software? • Portabilidad: conjunto de atributos relacionados con la Un producto de software se lo puede describir en un sentido capacidad de un sistema software para ser transferido extenso como: los ejecutables, código fuente, descripciones de desde una plataforma a otra. Las subcaracterísticas de la arquitectura, y así. Portabilidad son: Capacidad de instalación, capacidad de reemplazamiento, Adaptabilidad y Co-Existencia. De allí que las métricas del producto se refieren a las características del propio software que incluye: la medición del tamaño del producto, la estructura del producto y la calidad del 2.5.2.2Métricas Externas– ISO 9126-2:2003 producto. Las cuales miden el software en sí mismo o software en ejecución Un estándar internacional para la evaluación del Software es el (Calidad Externa – Ambiente de Prueba). ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005. [11] Permite evaluar la calidad del software desde distintas 2.5.2.3Métricas Internas – ISO 9126-3: 2003 perspectivas relacionadas con el desarrollo, adquisición, Las cuales miden el comportamiento del sistema, dichas métricas requerimientos, uso, evaluación, mantenimiento, aseguramiento se aplican cuando el software no está en ejecución por ejemplo de la calidad. durante el diseño y codificación. (Calidad Interna – Ambiente de El estándar está dividido en cuatro partes las cuales dirigen, Desarrollo) respectivamente, lo siguiente: 2.5.2.4Calidad en Uso–ISO 9126-4: 2004 El cual mide el efecto de usar el software en un contexto 2.5.2.1Modelo de la Calidad específico (Ambiente de Producción). Describe el modelo de calidad del producto de software ISO 9126-2, ISO 9126-3 e ISO 9126-4 están encaminados en especificando 6 características de calidad interna (evalúa el total ambientes de Prueba, Desarrollo y Producción respectivamente. de atributos que un software debe satisfacer) y externa (evalúa
  13. 13. ¿Quién puede utilizar esta norma? • Desarrollo y mejora de los procesos de la Esta Norma puede ser usada por desarrolladores, evaluadores organización independientes y grupos de aseguramiento de la calidad • Definición de los procesos de la organización responsable de especificar y evaluar la calidad del software. • Planificación de la formación • Gestión de riesgos • Análisis y resolución de toma de decisiones 3.MODELOS ESTANDARIZADOS DISPONIBLES • Cuantitativamente Gestionado o Nivel 4 CMM – CMMI: Nivel 4 a más de contar con procesos definidos para el desarrollo de los proyectos se utilizan técnicas cuantitativas 3.1CMMI para el control de los procesos, como pueden por ejemplo se CMMI es un modelo de calidad del software que clasifica las usan las métricas para gestionar la organización. empresas en niveles de madurez. Estos niveles sirven para Los procesos que hay que implantar para alcanzar este nivel conocer la madurez de los procesos que se realizan para producir son: software. • Gestión cuantitativa de proyectos 3.1.1Niveles CMM – CMMI • Mejora de los procesos de la organización • Optimizado o Nivel 5 CMM – CMMI Los niveles CMM - CMMI son 5: Los procesos de los proyectos y de la organización en este nivel a más de ser cuantitativamente gestionados están • Inicial o Nivel 1 CMM – CMMI: En este nivel pertenecen orientados a la mejora de las actividades mediante el uso de aquellas empresas que no tienen sus procesos bien definidos. métricas. Características comunes de este tipo de empresas son: los Los procesos que hay que implantar para alcanzar este nivel presupuestos se disparan, no se entrega el proyecto en fechas son: establecidas, no hay control sobre el estado y desarrollo del • Innovación organizacional. proyecto. El simple hecho de existir como empresa de • Análisis y resolución de las causas. software se está en el nivel1. 3.2ISO 9000 • Repetible o Nivel 2 CMM – CMMI: El objetivo que pretende alcanzar el nivel 2 es que los proyectos que lleve a “ISO 9000” se refiere a una serie de normas internacionales que cabo las empresas se los ejecute con una adecuada gestión de define un sistema de “Garantía de Calidad” en las organizaciones: los procesos lo que implica planeación, ejecución, control, ISO 9001, ISO 9002, ISO 9003 e ISO 9004 (y sus subnormas) medición de los mismos. Es un nivel difícil de alcanzar pues desarrollado por la Organización Internacional de Normalización al establecer procesos se está pretendiendo cambiar la forma (ISO). Esta norma ha sido adoptada por 90 países en todo el de trabajar de la empresa que muchas de las veces implica un mundo y está compuesta por representantes de normas nacionales cambio cultural de la misma y por ende lo más importante de más de 100 países. aquí es saber si se cuenta con el apoyo de la dirección para afrontar este cambio. Sin este apoyo no se podría alcanzar el La familia de normas apareció por primera vez en 1987 teniendo CMM-CMMI nivel 2. como base una norma estándar británica (BS), y se extendió principalmente a partir de su versión de 1994, estando Los procesos que hay que implantar para alcanzar este nivel actualmente en su versión 2008, publicada el 13 de noviembre de son: 2008. La principal norma de la familia es actualmente la: ISO • Gestión de requisitos 9001:2008 - Sistemas de Gestión de la Calidad - Requisitos. [15] • Planificación de proyectos • Seguimiento y control de proyectos 3.2.1Proceso de Certificación • Gestión de proveedores • Para brindar una certificación bajo la norma ISO • Aseguramiento de la calidad 9000 a determinada empresa u organización, • Gestión de la configuración existen las entidades certificadoras vigiladas por organismos nacionales que les dan su acreditación • Definido o Nivel 3 CMM – CMMI: Pertenecer a este nivel y son las encargadas de verificar que dichas significa que los proyectos que se llevan a cabo a más de organizaciones o empresas cumplen con los contar con procesos gestionados, la organización o empresa requisitos de la norma, una vez que éstas hayan debe contar con una forma definida para desarrollar dichos elegido el alcance de la actividad profesional que proyectos es decir sus procesos deben estar establecidos, se va a registrar, seleccionado un registro, documentados y contar con métricas para la consecución de someterse a la auditoría y haber concretado con objetivos concretos. éxito dicho proceso; se les otorga un certificado y sello. Los procesos que hay que implantar para alcanzar este nivel ¿Qué hacer ante el incumplimiento? son: • Desarrollo de requisitos Si un auditor/registrador encuentra áreas de incumplimiento la • Solución Técnica organización o empresa tiene un plazo para adoptar medidas • Integración del producto correctivas, sin perder la vigencia de la certificación o la • Verificación continuidad en el proceso de certificación. • Validación
  14. 14. 3.2.2 Marco Conceptual La Computer Society declara "dedicada al avance de la teoría, la práctica y la aplicación de la informática y la tecnología de La ISO 9001 y la ISO 9002 son normas de sistema. ISO 9001 se procesamiento de la información." Procura "ser el proveedor líder aplica a las empresas que se dedican al diseño de productos o de información técnica y servicios a los profesionales del mundo servicios y también a su producción o implementación. ISO 9002 de la informática". [19] simplemente excluye el elemento de diseño de un modelo similar para garantía de calidad. Los certificados que pueden concederse mediante ellas señalan 4.4 RUSSOFT Association que una organización es perfectamente capaz de cumplir las Con sede en San Petersburgo, es un multi-nacional de la necesidades y requisitos de sus clientes de manera planificada y asociación de software de empresas de Rusia, Ucrania y controlada [16]. Si quiere ir más allá y lograr la excelencia, Bielorrusia. Fue fundada el 9 de septiembre de 1999 y se ha debería cumplir requisitos adicionales. La ISO 9004:2000 fusionado con la de Fort-Ross Consorcio en mayo de 2004. establece estos requisitos adicionales. Al igual que en la India NASSCOM, RUSSOFT fue creado para 4.ORGANIZACIONES representar a empresas rusas de desarrollo de software en el mercado mundial, a fin de mejorar la comercialización y actividades de relaciones públicas de sus miembros, y para 4.1Software Engineering Institute (SEI) presionar a sus intereses en sus países los gobiernos. [20] Es un instituto federal estadounidense de investigación y desarrollo, fundado por el Congreso de los Estados Unidos en 5.MEJORA DE LOS PROCESOS DE 1984 para desarrollar modelos de evaluación y mejora en el desarrollo de software, que dieran respuesta a los problemas que SOFTWARE generaba al ejército estadounidense la programación e integración de los sub-sistemas de software en la construcción de complejos La mejora de procesos de Software (MPS) es un término que se sistemas militares. Financiado por el Departamento de Defensa de usa cuando se referencian mejoras al proceso de software. los Estados Unidos y administrado por la Universidad Carnegie Históricamente CMMI (y otros estándares y métodos envueltos) y Mellon. otras organizaciones añadieron un “S” para ampliar el alcance a Es un referente en Ingeniería de Software por realizar el sistemas y procesos de software (MPSS), mientras que otras desarrollo del modelo SW-CMM (1991) que ha sido el punto de organizaciones reemplazaron “Software” por “Sistemas” para arranque de todos los que han ido formando parte del modelo que guardar el mismo acrónimo: Mejora de Procesos de Sistemas ha desarrollado sobre el concepto de capacidad y madurez, hasta (MPS) e incluir HW, SW, FW y WW. [21] el actual CMMI. [17] 5.1Enfoque para MPS 4.2 British Computer Society (BCS): En la mejora de procesos de software podemos encontrar tres enfoques principales (o paradigmas) para la mejora de procesos Es una organización profesional y una sociedad científica que de sistemas/software que se usan independientes o combinadas: representa a las personas que trabajan en la tecnología de la información. Establecida en 1957, es el más grande de Reino • Mejora apoyada en Modelos: este enfoque se basa en Unido basados en un organismo profesional de la informática. el uso de prácticas aceptadas por la industria como un modelo para mejorar una organización, que no está Cubre los más de 68.000 miembros en más de 100 países, BCS es consolidada a estas prácticas. Frecuentemente se usan una sin fines de lucro y se incorporó por Carta Real en 1984. Sus dos modelos: objetivos son promover el estudio y la aplicación de la tecnología de las comunicaciones y la informática y la tecnología para o Modelo de Madurez de capacidad integrada avanzar en el conocimiento de la educación en las TIC en (CMMI) del Instituto de Ingeniería de Software beneficio de los profesionales y el público en general. [18] (SEI). o Conjunto de estándares de la ISO-9000 de la 4.3 IEEE Computer Society Organización Internacional para la estandarización. • Mejora de Procesos “Bottom-Up”: este enfoque se En una unidad de organización del Instituto de Ingenieros centra en hacer mediciones como tamaño, esfuerzo, Eléctricos y Electrónicos (IEEE). Se estableció en 1963 cuando el productividad, defectos, reuso y otros indicadores de Instituto Americano de Ingenieros Eléctricos (AIEE) y el Instituto procesos consiguiendo así datos de líneas-base y cuando de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE. se determina que habido mejoras potenciales el cambio En el momento de la fusión, la AIEE del Subcomité de gran se implementa. El efecto del cambio determina la escala de Computación (creado en 1946) se fusionó con el IRE ocurrencia de una mejora significativa y el resultado es del Comité Técnico de Electrónica Informática (establecida 1948) usado para manejar el cambio organizacional. para crear el Grupo de IEEE Computer. El grupo se convirtió en el IEEE Computer Society en 1971.
  15. 15. • Reingeniería de Negocios: establece mejor un cambio 7.REFERENCIAS radical que un cambio incremental, un poco similar al enfoque “Mejora de Procesos Bottom-Up”. [1] Mario Piattini, Francisco J. Pino y Félix García, 5.2 Grupos de Procesos de Ingeniería de “Contribución de los estándares internacionales a la gestión Sistemas e Ingeniería de Software (SEPG) de procesos software”, Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Colombia http://www.aemes.org/rpm/descargar.php?volumen=4&nume Software Engineering Process Group, nombre original dado al ro=2&articulo=1 servicio registrado del Instituto de Igeniería del Software (SEI) a los “grupos responsables por las actividades de proceso de las [2] Wikipedia, “Ingeniería de software”, organizaciones del software”. Algunos de estos grupos son: http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwar e • SEPG: Grupo de Procesos de Ingeniería de Sistemas. [3] Zavala R. 2000. Diseño de un Sistema de Información • SSEPG: Grupo de Procesos de Ingeniería de Software y Geográfica sobre internet. Tesis de Maestría en Ciencias de Sistemas. la Computación. Universidad Autónoma Metropolitana- • SSPG: Grupo de Procesos de Software y Sistemas. Azcapotzalco. México, D.F. En prensa, http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware. • PEG: Grupo de Ingeniería de Procesos. html#IngSoft • PIG: Grupo de Mejora de Procesos. [4] Luciano Guerrero, Monerreal: Canadá, 1999, “Ciclo de • QIG: Grupo de Mejora de Calidad. Mejoramiento de Procesos, El modelo • PTIG: Grupo de Mejora de Procesos y Tecnología. IDEAL,”www.geocities.com/SiliconValley/Lab/3629/IDEA L_ciclo.pdf 6.CONCLUSIONES [5] “Software process engineering systems: models and industry cases”, http://herkules.oulu.fi/isbn9514265084/html/x287.html Finalmente se puede concluir acerca del tema: [6] Francisco Ruiz, Procesos de Ingeniería del Software, • Dentro del proceso de Ingeniería del Software los tres http://personales.unican.es/ruizfr/is1/doc/teo/02/is1-t02- factores más importantes son: Personal, Métodos y trans.pdf Procedimientos y Herramientas y Técnicas. • El proceso de ingeniería del software está basado en [7] IEEE, “IEEE 1074-2006”, http://www.techstreet.com/cgi- procesos y modelos a la definición, evaluación y medición bin/detail?product_id=1277365 del software. [8] IEEE Standard Association, “IEEE Std 1074-1997 IEEE • Existen modelos y procesos aplicados en las diferentes Standard for Developing Software Life Cycle Processes - etapas del proceso de software. Description”, • La facilidad de entendimiento humano y comunicación, http://standards.ieee.org/reading/ieee/std_public/description/s ayuda a llevar una buena definición de los procesos. e/1074-1997_desc.html • La medición del Proceso de un Proyecto de Desarrollo de Software es primordial pues gracias a éste nos permite [9] Jin Lyu, Kyle Hancock y Linus Luotsinen, IEEE Standard identificar las fuerzas y las debilidades del mismo y a su 1219-1998 Software Maintenance, vez del proyecto. http://classes.cecs.ucf.edu/eel6883/berrios/slides/ch%209%2 • La recolección de métricas del proceso es esencial para la 0-%20art%202%20-%20IEEE%20Standard%201219- mejora del mismo y se utilizan para evaluar la eficiencia 1998.ppt de un proceso y si éste ha mejorado con los cambios [10] “Métricas”, disponible en: http://alarcos.inf- realizados. r.uclm.es/doc/Calidad/capitulo09.ppt • Un producto de software constituye: los ejecutables, [11] “ISO/IEC 9126” disponible en: código fuente, descripciones de arquitectura, y así. http://es.wikipedia.org/wiki/ISO/IEC_9126 • Medir un producto de software implica: la medición del tamaño del producto, la estructura del producto y la [12] Fernanda Scalone, Software Quality Management, calidad del producto. disponible en: http://softqm.blogspot.com/2007/01/visin- • Las métricas en un proyecto de desarrollo de software e se general-acerca-de-iso-9126.html pueden aplicar a procesos y productos. [13] María Del Carmen Sosa Sierra, “Inteligencia artificial en la • Las métricas del proceso permiten a una organización de gestión financiera empresarial”, ingeniería del software tener una visión profunda de la http://ciruelo.uninorte.edu.co/pdf/pensamiento_gestion/23/6_ eficacia de un proceso ya existente Inteligencia%20artificial.pdf • Dos modelos estandarizados que se los puede utilizar para la medición de la calidad del Software son: CMMI y ISO [14] Carlos J. Alonso González, Departamento de Informática, 9000. “Inducción de Reglas Proposicionales”, http://www.infor.uva.es/~calonso/IAII/Aprendizaje/Induccio nReglasProposicionales.pdf
  16. 16. [15] Wikipedia, “Normas ISO 9000” disponible en: [36] Wikipedia, disponible http://es.wikipedia.org/wiki/Normas_ISO_9000 en:http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gi [16] CINTERFOR,“ Gestión de calidad en la formación” l_de_software disponible en: [37] “Gucoba” disponible en: http://www.ilo.org/public/spanish/region/ampro/cinterfor/te http://gucoba.com/index.php?option=com_content&vi mas/calidad/doc/cedefop1.htm ew=article&id=56&Itemid=57 [17] Wikipedia, “Software Engineering Institute” disponible en: [38] Monografias, disponibe en: http://es.wikipedia.org/wiki/Software_Engineering_Institute http://www.monografias.com/trabajos67/metodologia- [18] Wikipedia, “British Computer Society” disponible en: desarrollo-softwares/metodologia-desarrollo- http://en.wikipedia.org/wiki/British_Computer_Society softwares2.shtml [19] Wikipedia, “IEEE Computer Society” disponible en: [39] “Método CBA IPI para la evaluación de proyectos”, http://en.wikipedia.org/wiki/IEEE_Computer_Society Disponible en: [20] Wikipedia, “RUSSOFT” disponible en: http://www.geocities.com/SiliconValley/Lab/3629/cbai http://en.wikipedia.org/wiki/RUSSOFT, disponible en: pi.htm http://www.slideshare.net/aacevedolipes/spin-colombia [40] “Metodologías De Desarrollo De Software”, María A. [21] Rduardo A. Rodríguez Tello, “Procesos de software”, 2008, Mendoza Sanchez , 2004, http://www.tamps.cinvestav.mx/~ertello/swe/sesion03.pdf http://www.willydev.net/InsiteCreation/v1.0/descargas [22] Chirstian Tzec, “Fundamentos de Desarrollo de Sistemas”, /cualmetodologia.pdf http://www.scribd.com/doc/16416960/Modelo-cascada- [41] Microsoft Solution Framework, figura tomada de: espiralincremental http://caraujo334.blogspot.es/img/msf1.jpeg [23] https://www.mytconsulting.com/principal/images/12207_5.p [42] http://www.mentores.net/default.aspx?tabid=104&type ng =art&site=183&parentid=32 [24] http://www.cs.umd.edu/users/basili/qip/img007.gif [43] http://en.wikipedia.org/wiki/Microsoft_Solutions_Fra [25] http://es.kioskea.net/contents/genie-logiciel/cycle-de- mework vie.php3 [26] Sid@r, “Prototipado”, http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/ Prototyping.htm [27] “Introducción a la Ingeniería de Software”, http://oacosta334.blogspot.es/tags/prototipo/ [28] Wikipedia, “Modelo de prototipos”, 2009, http://es.wikipedia.org/wiki/Modelo_de_prototipos [29] http://cmunoz334.blogspot.es/tags/Modelo/ [30] “MODELOS DE PROCESO ITERATIVOS E INCREMENTALES”, http://scruz334.blogspot.es/1193793960/ [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”, 1999, http://alarcos.inf- cr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf [34] http://www.aemes.org/rpm/descargar.php?volumen=4&nume ro=2&articulo=1 [35] Juan Pablo Gomez Gallego, “Fundamentos de la Metodología RUP Rational Unified Process”, 2007

×