CREANDO EL ESTADO BASE

Primero se debe tener abierta la Aplicación que se desea testear (ya sea de escritorio o web). Si es web en el explorador de InternetExplorer.

Segundo se debe crear un proyecto :

• web para aplicaciones web
• windows based para aplicaciones de escritorio

Para el ejemplo se testeara http://demo.borland.com/gmopost

Asignen un nombre y ubicación a su proyecto, es importante que recuerde la dirección, para el ejemplo C:\Proyectos

Por cuestión de comodidad en ubicación de datos, creen las carpetas de: bin, result, script, data, include - frame; en la raiz de su proyecto es decir en C:\Proyectos (como se observa en la figura)

Configure el proyecto para que sus archivos estén en las carpetas creadas

direccionen la carpeta bin en el campo object filepath 

direccionen la carpeta result en el campo directory file, asi los archivos results se crearan dentro de ella cuando realize las compilaciones 

Tercero: Detectando la aplicación

seleccione la aplicacion y click en select

seleccione DOM, y ok, los checks son opcionales

Cierre y Abra nuevamente la pagina que desea testear para que el botón test se habilite, click en test

click en ok

CUARTO: Rescatando el estado BASE

• seleccione la aplicacion a testear nuevamente, notece que el campo frame filename contiene el path de donde se creara el archivo .inc que contendra el estado base,  es recomendable que lo direccione a la carpeta  include - frame q se creo, si lo desea puede cambiar tambien el nombre del frame por alguno q usted considere mas descriptivo.
• y click en ok

click en ok

este es nuestro estado base nótese que las 5 lineas escritas al inicio son las que establecen el estado base, el cual puede tener mas configuraciones descomentando las subsiguientes

Y listo!
si corre, es decir cuando lo ejecuta, el InternetExplorer(o la aplicación de escritorio si es el caso) se levanta y accede a la pagina que desea testear, entonces su estado base fue creado exitosamente.

My IQ

QuickIQTest.net - IQ Test

Análisis comparativo entre la Norma ISO 29119 y el libro de Pressman (cap. 17 y 18)

Pressman Capítulos 17 y 18

En el capitulo 17 "Técnicas de prueba del software" se describen las distintas técnicas para realizar las pruebas.

Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación.

La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.

Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

Existen distintas técnicas como ser las pruebas de caja blanca (camino básico, estructuras de control), caja negra (basados en grafos, de comparación, de tabla ortogonal), de entornos especializados, arquitecturas y aplicaciones (de interfaz gráfica, de arquitectura).

En el capitulo 18 "Estrategias de pruebas del software" se habla de cual es la mejor manera de realizar las pruebas, siguiendo una estrategias para su ejecucion. 

El proceso de ingeniería del software se puede ver como una espiral. 

También se puede ver la estrategia para la prueba del software en el contexto de la espiral.que se desarrolla de la siguiente manera: 

• La prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. 
• La prueba de integración, donde el foco de atención es el diseño y la construcción de la arquitectura del software. 
• La prueba de validación, donde se validan los requisitos establecidos como parte del análisis de requisitos del software.
• La prueba del sistema, en la que se prueban como un todo el software y otros elementos del sistema. 

Se habla también del perfil psicológico que implican el desarrollo del software y las pruebas, es decir, los desarrolladores deben ser personas constructivas, mientras por el contrario quienes realizan las pruebas deben ser destructivos. sin embargo esto no quiere decir que los desarrolladores no deban de participar en las pruebas sino todo lo contrario, ellos son los primeros en probar el software y seguidamente un grupo imparcial(GIP) también realiza pruebas.

ISO/IEC 29119

Este estándar, cuya elaboración comenzó en 2007 tiene como objetivo cubrir todo el ciclo de vida de las pruebas de sistemas software incluyendo los aspectos relativos a la organización, gestión, diseño y ejecución de las pruebas.

La norma reemplazará a un número de los actuales estándares IEEE BSI para las pruebas de software:

• IEEE 829 Documentación de prueba
• IEEE 1008 Unidad de Pruebas
• BS 7925-1 Vocabulario de términos en pruebas de software
• BS 7925-2 de componentes estándar de pruebas de software

Define el vocabulario, los procesos, la documentación, las técnicas y un modelo de evaluación del proceso de pruebas de software que se puede utilizar dentro de cualquier ciclo de desarrollo de software.

La estructura de ISO/IEC 29119 consta de cuatro partes:

• Conceptos y Vocabulario
• Proceso de Pruebas
• Documentación de Pruebas
• Técnicas de Prueba
• Modelo de Proceso de evaluación

Análisis

La nueva norma iso es la prueba viviente del avance que han tenido las pruebas en el software al pasar del tiempo.

Los conceptos, definiciones, etc que ofrece Pressman siguen siendo validos solo que ahora se tiene mas herramientas y técnicas para tener una mayor efectividad en las pruebas


REFERENCIAS

• Ingeniería del Software: Un Enfoque Práctico                                                                            Rogger S. Presuman - Quinta Edición

• ISO / IEC 29119 de pruebas de software http://softwaretestingstandard.org/

Ciclo de Vida Orientado a Objetos VS Tradicionales

El tiempo de desarrollo y uso del software, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado se denominan ciclo de vida del software.

Un ciclo de vida usualmente consta de las siguientes etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento.

Cada etapa consta de diversas tareas; la documentación es una tarea que se realiza en todas las etapas.

Los ciclos de vida tradicionales más conocidos son:

• Ciclo de vida en cascada
• Ciclo de vida en cascada incremental
• Ciclo de vida en espiral
• Ciclo de vida en espiral Win Win
• Ciclo de vida Prototipo
• Ciclo de vida Recursivo Paralelo
• Ciclo de vida DRA
• Ciclo de vida Evolutivo
• etc.

A continuacion se describe brebemente alguno de estos ciclos de vida.

Ciclo de vida en cascada

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:

• Especificación de requisitos
• Diseño del software
• Codificación
• Pruebas (o validación)
• Despliegue (o instalación)
• Mantenimiento

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

Ventajas

• La planificación es sencilla. 
• La calidad del producto resultante es alta. 
• Permite trabajar con personal poco calificado. 
• Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.
• Es mejor que no seguir ningún ciclo de vida.

Inconvenientes

• Es difícil obtener todos los requisitos al comienzo. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas. 
• Si se han cometido errores en una fase es difícil volver atrás. Al cambiar alguna de las etapas se debe revisar todas las etapas subsiguientes.
• Es comparativamente más lento que los demás y el coste es mayor también.
• Se tarda mucho en disponer del software.
• No se tiene el producto hasta el final, esto quiere decir que: 
• Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos. 
• El cliente no verá resultados hasta el final, con lo que puede impacientarse. 
• No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).
• El mantenimiento se realiza en el código fuente
• Impone una estructura de gestión de proyectos

Tipos de proyectos para los que es adecuado

• Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería. 
• Se está desarrollando un tipo de producto que no es novedoso. 
• Proyectos complejos que se entienden bien desde el principio. 
• Como el modelo en cascada ha sido muy popular ha generado algunas variantes.

Ciclo de vida en espiral

La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

• Crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
• Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
• La implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;

Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto.

Ventajas

• 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 más 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 (las anteriores iteraciones están bien). 
• El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos. 

Inconvenientes

• Es difícil evaluar los riesgos. 
• Necesita de la participación continua por parte del cliente. 
• Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo. 

Dónde es adecuado

• Sistemas de gran tamaño. 
• Proyectos donde sea importante el factor riesgo. 
• Cuando no sea posible definir al principio todos los requisitos.

Ciclo de vida Prototipo

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombremáquina.

En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.

• Escuchar al Cliente: El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. 
• Construir/Revisar la maqueta: Entonces aparece un «diseño rápido». El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. 
• El Cliente Prueba la maqueta: El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

Ventajas

• Ayuda a identificar los requisitos del software. 
• Hace el software amigable al usuario.
• El cliente estará seguro de que el producto final reflejara lo que él desea.

Inconvenientes

• Primera versión de un producto es construido con poca funcionalidad y poca fiabilidad.
• El cliente ve lo que parece ser una versión de trabajo del software, y piensa que el trabajo esta hecho.
• Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. 
• No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es más inteligente, y construir una versión rediseñada en la que se resuelvan estos problemas

Diferencia entre Prototipo y Producto Final

La diferencia entre prototipo y producto final es que el prototipo es eficiente y el producto final debe serlo y, que en el prototipo no están todos los detalles y, el producto final debe contenerlos.

Clases de prototipos:

• Vertical: no recoge todas las funciones del sistema final.
• Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

Ciclo de Vida Orientado a Objetos

Esta técnica fue presentada en la década de los 90, tal vez como una de las mejores metodologías a seguir para la creación de productos software.

Puede considerarse como un modelo pleno a seguir, como así también una alternativa dentro de los modelos anteriores.

Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto.

 Los ciclos de vida clásicos se centran en el proyecto, el desarrollo orientado a objetos se basa en el producto, no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro y se relacionan entre ellos a través de interfaces, son más modulares y se dividen en miniproyectos lo cual permiten que el código sea reutilizable. 

Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho mas fácil agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene.

Debido a todo esto se considera que el ciclo de vida orientado a objetos es iterativo e incremental.

Los ciclos de vida orientados a objetos son:

• Modelo Fuente.
• Modelo de Agrupamiento.
• Modelo Remolino.
• Modelo PinBall.

A continuacion veremos un tipo de ciclo de vida orientado a objetos mas conocidos, que es además el más representativo, el modelo fuente.

Modelo fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido.

Un proyecto se divide en las fases:

1. Planificación del negocio
2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades
• Planificación
• Investigación
• Especificación
• Implementación
• Revisión
3. Entrega

La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos periodos:

• Crecimiento: Es el tiempo durante el cual se construye el sistema
• Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.

Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la figura se muestra un esquema de este tipo de ciclo de vida.

Modelo de Agrupamiento (Clúster)

Propuesto por Bertrand Meyer (Meyer, 1990). 

Concepto Clave: Agrupamiento, que es un conjunto de clases relacionadas con un objetivo común.

Clúster: Unidad organizativa básica. Es un grupo de clases relacionadas o, recursivamente, clústeres relacionados. El clúster es la unidad natural para el desarrollo por parte de un único desarrollador.

• Evita el efecto todo-nada propio del modelo en cascada.

Tiene un componente secuencial y un componente concurrente.

• Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo.
• Se aplica al clúster no al sistema completo.
• El miniciclo de vida que gobierna el desarrollo de un clúster está formado por Especificación, Diseño, Implementación, Verificación/Validación y Generalización.

Enfoque Ascendente.

La ocultación de la información posibilita la forma del modelo de clústeres de ingeniería concurrente.

Modelo Remolino

Definido por James Rumbaugh (Rumbaugh, 1992). Las metodologías de desarrollo no ofrecen una visión real del ciclo de vida en el desarrollo orientado al objeto. El ciclo de vida de un desarrollo orientado al objeto es desordenado, involucrando múltiples iteraciones interrelacionadas.

El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso.

Pueden Identificarse otras dimensiones:

• Amplitud: tamaño del desarrollo, por ejemplo en número de elementos.
• Profundidad: referida al nivel de abstracción o detalle.
• Madurez: grado de complexión, corrección y elegancia.
• Alternativas: Diferentes soluciones a un problema.
• Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo largo del tiempo.

Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad - madurez – amplitud

Este proceso fractal (mas que lineal), consiste en un desarrollo multiciclo en forma de remolino en lugar de una cascada, de ahí su nombre.

Modelo PinBall

Propuesto por Ambler (Ambler, 1994). Modelo muy didáctico señala que el pinball refleja la forma que se desarrolla el software.

• Pelota ====> Proyecto o subproyecto 
• Jugador ====> Equipo de desarrollo

Se procede de forma iterativa a encontrar clases, atributos, métodos y relaciones (actividades que pueden englobarse en la fase de análisis) y definir colaboraciones, herencia, agregación y subsistemas (actividades de diseño), y por último se pasa a la programación, prueba e implementación.

Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea.

Existen dos estilos a la hora de jugar

• A lo seguro ===> Con tecnologías y métodos probados 
• Al límite ===> Con más riesgo (se pueden conseguir beneficios espectaculares) 

El autor destaca que al igual que en el juego del pinball, la habilidad es el factor mas importante.

Consideraciones sobre los Ciclos de Vida Orientado a Objetos

• Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto.
• Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.
• Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.

Conclusiones

Los ciclos de vida tradicionales son estructurados lo que hace difícil dividirlos en subsistemas para ser implementados independientemente, en cambio los ciclos de vida orientado a objetos son modulares, es decir, se dividen en módulos formados por componentes, donde cada componente es independiente del otro y se relacionan a través de las interfaces; esta división eventualmente facilita la construcción del software, puesto que se puede avanzar en distintas partes del proyecto a la vez.

Los Ciclos de vida Orientados a Objetos tienen permiten la reutilización del código, algo con lo que no cuentan los tradicionales.

Los Ciclos de vida Orientados a Objetos son mas fáciles de mantener porque los cambios están localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho mas fácil agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene. En cambio los tradicionales tienen más complicaciones para detectar y corregir los errores a tiempo, mas aun la modificación o incremento de requerimientos ocasiona crisis en el proyecto pues no suelen ser muy flexibles al cambio.

Por todo esto es a mi parecer mucho mas conveniente realizar proyectos siguiendo un ciclo de vida orientado a objetos en lugar de utilizar uno tradicional, o bien también es factible utilizar alguna variante de los tradicionales con los orientados a objetos obteniendo como resultado un ciclo de vida hibrido

Referencias

Libros

Ingeniería del Software: Un Enfoque Práctico

Rogger S. Presuman - Quinta Edición

Páginas Web

http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html

http://es.scribd.com/doc/54962509/33/Los-modelos-orientados-al-objeto

http://www.ctr.unican.es/asignaturas/is1/is1-t02-trans.pdf

http://www.buenastareas.com/ensayos/Modelos-De-Desarrollo-De-Sistemas-Orientados/1193373.html

Procesos de desarrollo Ligeros vs Pesados, ciclos de vida, MSF, MOF, ITIL

PROCESOS DE DESARROLLO LIGEROS VS PESADOS

Actualmente con el creciente desarrollo tecnológico y la aparición de nuevos modelos de producción, han ido apareciendo nuevas metodologías de proceso de desarrollo, estos procesos han ido tomado características marcadas, lo que ha conllevado en agruparlos en dos grandes grupos, los llamados "métodos pesados" y los "métodos ligeros", la diferencia más saltante entre estos dos grandes grupos es que mientras los métodos pesados intentan obtener los resultados ayudándose principalmente de la documentación ordenada, los métodos ligeros tienen como base de sus resultados a la comunicación e interacción directa con todos los usuarios involucrados en el proceso.

Metodología Ágil	Metodología No Ágil (Tradicional)
Pocos artefactos	Más artefactos
Pocos roles	Más roles
No existe un contrato tradicional o al menos es bastante flexible	Existe un contrato prefijado
El cliente es parte del equipo de desarrollo (además in-situ)	El cliente interactúa con el equipo de desarrollo mediante reuniones
Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio	Grupos grandes
Menos énfasis en la arquitectura	La arquitectura es esencial

RUP (Rational Unified Process)

Este es uno de los procesos más generales que existe, esta enfocado a cualquier tipo de proyecto así no sea de software, se basa en la documentación generada en cada uno de sus cuatro fases:

1. Intercepción (puesta en marchar)

2. Elaboración (definición, análisis y diseño)

3. Construcción (implementación)

4. Transición (fin del proyecto y puesta en producción) 

En cada fase se ejecutarán una o varias iteraciones (según el tamaño del proyecto) y dentro de cada una de ellas seguirá un modelo de cascada o waterfal para los flujos de trabajo que requieren las nuevas actividades anteriormente citadas.

RUP se basa en UseCase(casos de uso) para describir lo que se tiene y lo que se espera del software, está muy orientado a la arquitectura del sistema a implementarse, documentandose de la mejor manera, basándose en UML (Unified Modeling Language - Lenguage de Modelado Unificado).

Para poder usar RUP antes hay que adaptarlo a las características de la empresa, y medir de manera exacta el tiempo, costos y todos los demás recursos involucrados en el proceso.

XP (eXtreme Programming - Programación Extrema)

XP, se basa en el trabajo orientado directamente al objetivo, basándose para esto en las relaciones interpersonales y en la velocidad de reacción para la implementación y para los cambios que puedan surgir durante el desarrollo del proceso.

Esto se logra, minimizando el riesgo de fallo del proceso manteniendo dentro del equipo a un representante "competente" del cliente, este representante es quién responderá a todas las preguntas y dudas que surjan por parte del equipo de desarrollo durante el proceso, de forma que no se retrase la toma de decisiones.

XP se basa en UseStories (historias de uso), estas historias las escribe el cliente o su representante dentro del equipo y describen los escenarios claves del funcionamiento del software, a partir de estas se generan los releases (entregas) entre el equipo y el cliente. Estos releases son los que permiten definir las iteraciones necesarias para cumplir con los objetivos, de manera que cada resultado de la iteración sea un programa aprobado por el cliente de quien depende la definición de las siguientes iteraciones.

Una característica saltante de XP, es que el código siempre se produce en parejas, parejas que van cambiando constantemente para lograr así que todo el equipo sepa y pueda modificar según necesidades el código generado, esto logra en el equipo que los integrantes aprendan entre sí y compartan todo el código.

MSF (Microsoft Solution Framework)

La metodología MSF es del tipo de metodologías agiles, esta enfocada a dirigir proyectos o soluciones de innovación, en ella no se detalla ni se hace énfasis de la organización ni el tamaño del equipo de desarrollo, esta mas bien centrada en la gestión y administración del proyecto para lograr el impacto deseado.AInvolucra indudablemente la calidad ya que prevee liberar una solución si esta aun tiene fallos o desperfectos para ello propone seleccionar un grupo de prueba piloto el cual es una VERSIÓN BETA y cumplido un tiempo de prueba ya es liberada la versión formal o VERSIÓN ALFA en la cual esta garantizada la calidad.

El modelo de proceso de MSF se compone de 5 fases:

• Previsión
• Planificación
• Desarrollo
• Estabilización
• Implementación

MOF (Microsoft Operation Framework)

MOF ofrece directrices sobre el modo de planear, implementar y mantener procesos operativos de TI que respalden las soluciones de servicio críticas. MOF es un modelo genérico y, por este motivo, debe adaptar muchas de las recomendaciones para usarlas en su empresa. Cuando encuentre referencias a "funciones" en el modelo MOF, tenga en cuenta que se puede asignar a una misma persona a varias funciones, sobre todo en las empresas pequeñas. No obstante, aunque represente a todo el departamento de TI, los procedimientos y recomendaciones de este modelo se pueden aplicar de forma general.

MOF es un modelo estructurado y flexible que está basado en lo siguiente:

• Los equipos de consultoría y soporte técnico de Microsoft y su experiencia de trabajo con clientes empresariales y socios, además de grupos internos de operaciones de TI en Microsoft. 
• La Biblioteca de infraestructuras de TI (ITIL), que describe los procesos y las prácticas recomendadas necesarios para el suministro de soluciones de servicio críticas. 
• ISO/IEC 15504, de la Organización Internacional de Normalización (ISO), que proporciona un enfoque normalizado para evaluar la madurez del proceso de software.

MOF ofrece recomendaciones para la implementación de varios productos de Microsoft, como Microsoft Windows Server 2003 y Microsoft Exchange Server 2007.

El modelo de proceso MOF está formado por cuadrantes, revisiones de la administración de las operaciones y revisiones de la administración de los servicios. El modelo de proceso MOF se desplaza en sentido de las agujas del reloj y se divide en los cuatro cuadrantes integrados siguientes:

• Cambios 
• Operaciones 
• Soporte técnico 
• Optimización

ITIL (Information Technologies Infrastructure Library )

La Biblioteca de infraestructuras de informática (ITIL) es un conjunto de códigos completos y coherentes de recomendaciones para la administración de servicios informáticos. La Agencia central de equipos y telecomunicaciones (CCTA) desarrolló una biblioteca de más de 40 libros en el Reino Unido.

El objetivo de CCTA era aumentar la eficacia empresarial en el uso de los sistemas de información. La demanda de que las organizaciones pudieran reducir los costos al mismo tiempo que mantenían los servicios informáticos demostró la necesidad de un conjunto de estándares.

Así, se desarrollaron los conceptos de ITIL de recomendaciones para servicios informáticos en colaboración con expertos, consultores y profesionales líderes del sector.

Muchas organizaciones han adoptado el concepto de ITIL porque ofrece un enfoque sistemático y profesional de la administración de los servicios informáticos. Mediante la adopción de las guías proporcionadas por ITIL, las organizaciones obtienen muchas ventajas, entre las que se incluyen:

• Aumento de la satisfacción de los clientes. 
• Reducción del costo de desarrollo de prácticas y procedimientos. 
• Mejora en los flujos de comunicación entre el personal de informática y los clientes. 
• Aumento de la productividad y del uso de capacidades y experiencia. 

CONCLUSIONES

Los procesos de software ligeros actualmente están ganando terreno ante los pesados, es probable con el tiempo solo queden en uso los ligeros. Así mismo Microsoft ha notado esto y desarrollo su propia metodología: MSF.

En su tiempo se pensó tal vez que los procesos crecerían tomando lo mejor de los anteriores, pero ha sido todo lo contrario, se les ha quitado lo que tenían de mas y se los ha vuelto mas ligeros. Sin lugar a dudas el mercado mismo los esta empezando a demandar.

REFERENCIAS

http://synergyca.net/index.php?p=1_9_Metodologias

http://universotela.blogspot.com/2011/05/scrum-y-programacion-extrema.html

http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP

http://www.microsoft.com/technet/prodtechnol/exchange/guides/ExMgmtGuide/62fab0e2-a570-4921-a0f1-7fdc6ffff2a9.mspx?mfr=true

http://audiemangt.blogspot.com/2010/05/metodologia-agil-msf-microsoft-solution.html

http://arevalomaria.wordpress.com/2010/01/07/msf-microsoft-solution-framework/

http://download.microsoft.com/download/4/4/E/44E1B331-E509-4D10-A9E3-B60640A3A403/20051206-ARC-BA.ppt

http://technet.microsoft.com/es-es/library/bb232042(v=exchg.80).aspx

http://download.microsoft.com/download/9/5/e/95e24fbf-5a65-4bd4-af44-44049ad9bed0/MOF%20-%20Presentaci%F3n.ppt

http://synergyca.net/index.php?p=1_9_Metodologias

http://universotela.blogspot.com/2011/05/scrum-y-programacion-extrema.html

http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP

http://www.microsoft.com/technet/prodtechnol/exchange/guides/ExMgmtGuide/62fab0e2-a570-4921-a0f1-7fdc6ffff2a9.mspx?mfr=true

http://audiemangt.blogspot.com/2010/05/metodologia-agil-msf-microsoft-solution.html

http://arevalomaria.wordpress.com/2010/01/07/msf-microsoft-solution-framework/

http://download.microsoft.com/download/4/4/E/44E1B331-E509-4D10-A9E3-B60640A3A403/20051206-ARC-BA.ppt

http://technet.microsoft.com/es-es/library/bb232042(v=exchg.80).aspx

http://download.microsoft.com/download/9/5/e/95e24fbf-5a65-4bd4-af44-44049ad9bed0/MOF%20-%20Presentaci%F3n.ppt

MODELOS DE CALIDAD EN EL SOFTWARE MCCALL, NORMA ISO/IEC 9126 Y NORMA 25000

MODELOS DE CALIDAD EN EL SOFTWARE MCCALL, NORMA ISO/IEC 9126 Y NORMA 25000

1. Introducción

En la industria del software, al igual que en cualquier otra industria, necesitamos medir el  producto que realizamos para conocer el esfuerzo y costes de producir dicho producto. De esta manera será posible ofrecer productos de calidad, es necesario por ello seguir alguna metodología que nos garantize esto. Hoy en dia hay diversos modelos de calidad y normas, en el presente trabajo se verán: el modelo de McCall, las normas ISO/IEC 9126 e ISO 25000

2. El Modelo de McCall

El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los EE.UU en 1977. , es uno de los más renombrados actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores enfocándose en un número de factores de calidad que reflejen las prioridades de ambos.

El modelo establece una jerarquía de Perspectivas (3), Factores (11), Criterios de Calidad (23) y Métricas (41). Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios y métricas de calidad.

Este enfoque es sistemático, y permite cuantificar la calidad a través de las siguientes fases:

·        Determinación de los factores que influyen sobre la calidad del software

·        Identificación de los criterios para juzgar cada factor

·       Definición de las métricas de los criterios y establecimiento de una función de normalización que define la relación entre las métricas de cada criterio y los factores correspondientes

·        Evaluación de las métricas

·        Correlación de las métricas a un conjunto de guías que cualquier equipo de desarrollo podría seguir

·        Desarrollo de las recomendaciones para la colección de métricas

En el modelo de McCall, los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.

Puntos De Vista O Ejes	Factor	Criterios
OPERACIÓN DEL PRODUCTO	Facilidad de uso	Facilidad de operación: Atributos del software que determinan la facilidad de operación del software. Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas fácilmente asimilables. Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición del modo actual de operación. Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema.
	Integridad	Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja. Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software. Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos.
	Corrección	Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas. Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación. Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.
	Fiabilidad	Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados. Consistencia. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independientes. Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible. Exactitud: La precisión de los cálculos y del control.
	Eficiencia	Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento. Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.
REVISIÓN DEL PRODUCTO	Facilidad de mantenimiento	Modularidad. Simplicidad. Consistencia. Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de códigos posible. Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.
	Facilidad de prueba	Modularidad. Simplicidad. Auto descripción. Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las mediciones del uso o la identificación de errores.
	Flexibilidad	Auto descripción. Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos. Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas. Modularidad.
TRANSICIÓN  DEL PRODUCTO	Reusabilidad	Auto descripción. Generalidad. Modularidad. Independencia entre sistema y software: Atributos del software que determinan su dependencia del entorno operativo. Independencia del hardware: Atributos del software que determinan su dependencia del hardware.
	Interoperabilidad	Modularidad. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar. Estandarización en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa.
	Portabilidad	Auto descripción. Modularidad. Independencia entre sistema y software. Independencia del hardware.

3. La Norma ISO/IEC 9126

El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software. Este estándar es una simplificación del Modelo de McCall,  e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software.

El estándar está dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, métricas externas, métricas internas y calidad en las métricas de uso.

El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un conjunto estructurado de características y subcaracterísticas de la siguiente manera:

• Funcionalidad - Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas.

§  Idoneidad

§  Exactitud

§  Interoperabilidad

§  Seguridad

§  Cumplimiento de normas.

• Fiabilidad - Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido.

§  Madurez

§  Recuperabilidad

§  Tolerancia a fallos

• Usabilidad - Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios.

§  Aprendizaje

§  Comprensión

§  Operatividad

§  Atractividad

• Eficiencia - Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas.

§  Comportamiento en el tiempo

§  Comportamiento de recursos

• Mantenibilidad - Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.

§  Estabilidad

§  Facilidad de análisis

§  Facilidad de cambio

§  Facilidad de pruebas

• Portabilidad - Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.

§  Capacidad de instalación

§  Capacidad de reemplazamiento

§  Adaptabilidad

§  Co-Existencia

La subcaracterística Conformidad no está listada arriba ya que se aplica a todas las características. Ejemplos son conformidad a la legislación referente a usabilidad y fiabilidad.

Cada subcaracterística (como adaptabilidad) está dividida en atributos. Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no están definidos en el estándar, ya que varían entre diferentes productos software.

Un producto software está definido en un sentido amplio como: los ejecutables, código fuente, descripciones de arquitectura, y así. Como resultado, la noción de usuario se amplía tanto a operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas software.

El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. Haciendo esto así, sin embargo, se lleva a cada organización la tarea de especificar precisamente su propio modelo. Esto podría ser hecho, por ejemplo, especificando los objetivos para las métricas de calidad las cuales evalúan el grado de presencia de los atributos de calidad.

Métricas internas son aquellas que no dependen de la ejecución del software (medidas estáticas).

Métricas externas son aquellas aplicables al software en ejecución.

La calidad en las métricas de uso están sólo disponibles cuando el producto final es usado en condiciones reales.

Idealmente, la calidad interna no necesariamente implica calidad externa y esta a su vez la calidad en el uso.

La calidad de uso es definida como “la capacidad del software que posibilita la obtención de objetivos específicos con efectividad, productividad, satisfacción y seguridad”.

Es interesante destacar que los factores de calidad que contempla el estándar ISO/IEC 9126 no son necesariamente usados para mediciones directas, pero proveen una valiosa base para medidas indirectas, y una excelente lista para determinar la calidad de un sistema.

4. La Norma ISO 25000

El estándar ISO/IEC 25000 SQuaRE (Evaluación de Calidad de Productos de Software) constituye una serie de normas basadas en la ISO 9126 y en la ISO 14598 (Evaluación del Software), y su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad. Establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su evaluación.

SQuaRE está formada por las divisiones siguientes.

• ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE. 

• ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.

• ISO/IEC 2502n. División de mediciones de calidad. Los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.

• ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado ó como entrada para un proceso de evaluación. El proceso de definición de requisitos se guía por el establecido en la norma ISO/IEC 15288 (ISO, 2003).

• ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.

• ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para la calidad de productos de software “Off-The-Self” y para el formato común de la industria (CIF) para informes de usabilidad.

La norma ISO 25000 ha sido desarrollada por el subcomité SC 7 (Ingeniería de software y sistemas) del Comité Técnico Conjunto ISO/IEC JTC 1.

Al igual que la norma ISO/IEC 9126, este estándar define tres vistas diferenciadas en el estudio de la calidad de un producto:

• Vista interna: esta vista se ocupa de las propiedades del software como: el tamaño, la complejidad o la conformidad con las normas de orientación a objetos.

• Vista externa: vista que analiza el comportamiento del software en producción y estudia sus atributos, por ejemplo: el rendimiento de un software en una máquina determinada, el uso de memoria de un programa o el tiempo de funcionamiento entre fallos.

• Vista en uso: mide la productividad y efectividad del usuario final al utilizar el software.

La primera puede utilizarse desde las primeras fases del desarrollo, permitiendo detectar deficiencias en el software en edades muy tempranas del ciclo de vida del software.

La segunda, sin embargo, necesita que el producto software este completo y se utilizará por tanto en el pase a producción del producto, siendo muy dependiente de la máquina donde se ejecute.
 .
Por último la tercera vista que también estudia el producto software finalizado será dependiente del usuario y estará condicionada a los factores personales del mismo.
 .
Puede observarse que las distintas vistas se interrelacionan, afectando los valores de la vista interna a los de la vista externa y los de la vista externa a los de la vista en uso. Así por ejemplo: un software con una alta complejidad probado sobre una máquina con bajas prestaciones tendrá un rendimiento bajo que provocará que el usuario final tenga un rendimiento inferior al esperado independientemente de sus factores humanos.

La serie ISO 25000 no establece los niveles de calidad deseables para cada proyecto, si bien se recomienda que los requisitos de calidad deberán ser proporcionales a las necesidades de la aplicación y lo crítico que sea el correcto funcionamiento del sistema implementado.
.
 El modelo de referencia para la medición de la calidad del producto software de la norma ISO/IEC 25000 establece que la calidad del producto software está compuesta de características de calidad, las cuales a su vez se componen de subcaracterísticas. Así mismo, establece que las medidas de calidad software (Software Quality Measures) indican las características y subcaracterísticas de calidad del producto software.
 .
El valor de estas medidas de calidad software se obtiene por la aplicación de una función de medida (Measurement Function) a los elementos de medida de calidad (Quality Measure Elements). Los elementos de medida de calidad son medidas base o medidas derivadas obtenidas según describe el método de medición correspondiente (measurement method), de acuerdo a la ISO/IEC 15939.
 .
Aunque las normas ISO/IEC 9126 y 25000 establecen cuáles son las características de la calidad de un producto software y sus subcaracterísticas, no indica qué medidas de calidad indican una subcaracterística.

Modelo de Referencia de Medición de la Calidad del Producto Software, según la ISO/IEC 25000.

Conclusión  

Si bien no todos los modelos los llaman de la misma forma, todos ellos evalúan el software considerando los mismos factores (como los llama McCall). Se interesan en medir estos factores desde la planificación del proyecto, siguiendo a lo largo de su ciclo de vida hasta su conclusión; es así que cada modelo a su manera ve la forma de garantizar la calidad del producto final.

Referencias

http://www.monografias.com/trabajos5/call/call.shtml

http://es.scribd.com/doc/52926121/9/El-modelo-de-McCall

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

http://iso25000.com/index.php/iso-iec-9126.html

http://iso25000.com/

http://iso25000.com/index.php/25000.html

http://es.wikipedia.org/wiki/ISO/IEC_25000