lunes, 14 de mayo de 2012

ANALISIS COMPARATIVO PRESSMAN E ISO/IEC 29119


Roger Humberto Uñoja Chungara

1.       Resumen.-
En los siguientes puntos veremos cómo y en qué forma aportan al proceso de realización de pruebas en el ciclo de vida de desarrollo de un determinado proyecto. Detallando algunas de sus características mas sobresalientes

2.       Ingeniería de software Cap. 17 y 18 (Roger Pressman)
Es interesante como Pressman hace una reflexión sobre el mito de los roles tanto de los que elaboran el software como constructivos, como de los que elaboran y hacen las pruebas como destructivos, desde un punto de vista mas psicológico.

Sin embargo Pressman en este capitulo de pruebas desmiente el mito de que las pruebas son usadas para desprestigiar a aquellos en los cuales es encotrado error. No somos perfectos cometemos errores, el éxito de una prueba es encontrar error que hasta el momento no se había encontrado.

Pressman define varios principios como operatividad y facilidad de pruebas para guiar las mismas. Tambien podemos ver que en ingeniería de software no se está dando la debida importancia que esta actividad debería tener que es de tener la mayor posibilidad de encontrar una falla.
Se pueden ver los diferentes tipos de realización de pruebas, unos con grafos, otros con pruebas en fin, pruebas como la de caja blanca para probar la estructura del control del programa y el de caja negra para validar los requisitos funsionales sin la necesidad de conocer su funcionamiento interno.
En el capitulo 18 podemos que esta vez Pressman pone mas énfasis en la planificación del proceso de realización de las pruebas. Aquí podemos observar claramente la preocupación por probar el funcionamiento interno del programa como lo hace las prueba de unida y de integridad.
Este escenario tendrá que contemplar todos los pasos necesarios para conseguir el fin mayor de la prueba que es de encontrar y repara los defectos de forma ordenada u efectiva.

3.       Norma ISO/IEC 29119.-
El estándar de calidad 29119 provee una guía para el testeo que cubre todos los aspectos del ciclo de vida del software.
-                     Propone una lista de  definiciones, procesos, procedimientos y técnicas de pruebas de software.
-                     Actualmente tiene la representación de más de 18 países y está siendo evaluada la unión mundial de                     profesionales de pruebas de software.
-           
      La estructura 29119 constade las siguiente partes:
-                       Conceptos y vocabularios
-                       Procesos y pruebas
-                       Documentación de pruebas
-                      Técnicas de pruebas


Los modelos de procesos como están formados por 3 procesos:
-          Procesos de la organización
-          Procesos de gestión
-          Procesos fundamentales
En un nivel superior se encuentran los procesos de la organización que son mas bien genéricos y no asi específicos a un determinado proyecto de pruebas. Pero ya tiene definidos las políticas y estrategias aplicables a toda la dirección o a una línea de  proyectos.
Para los proyectos de pruebas se definen los procesos de gestión y fundamentales así como los procesos genéricos para permitir flexibilidad y adaptación a diferentes contextos.

Conclusión.-
Podemos concluir que efectivamente ISO 29119 cubre absolutamente todos los aspectos en la realización de las pruebas desde los procesos que la compone hasta el flujo y orden en que se realizan tanto a nivel macro como específico. Potencialmente adecuado para grandes proyectos.
Pressman hace mas énfasis  a la forma y los tipos en los que se pueden realizar las pruebas tanto en la forma de su desenvolvimiento como conocer el funcionamiento del programa en detalle.
4.       Bibliografia.-
-          GIIS Software Engineering Group - http://giis.uniovi.es/
-          Javier Tuya - http://in2test.lsi.uniovi.es/gt26

-                    ISO/IEC 29119 Software Testing - http://softwaretestingstandard.org/

-          Roger Pressman – Ingenieria de software Un enfoque practico – quinta edicion

viernes, 4 de mayo de 2012

CICLOS DE VIDA ORIENTADOS A OBJETOS VS TRADICIONALES




Roger Humberto Uñoja Chungara


1.                  Resumen.-
Otra de las cuestiones a la hora de desarrollar software además de la elección de los procesos de desarrollo es la elección del ciclo de vida, muy importante ya que no es posible desarrollar software con cualquier ciclo de vida, la mala elección significaría cuantiosas pérdidas de tiempo y dinero a la vez.
A continuación vamos a realizar un análisis de los diferentes ciclos de vida existentes, aquellos que hoy por hoy son considerados obsoletos y aquellos que recientemente están siendo utilizados de acuerdo a los cambios en la forma de crear software y las necesidades del cliente.

Palabras Claves ¾ Ciclo de vida, OO, S.R.D., S.D.D.


2.                  Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así).

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:
  • Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
  • Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
  • Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
  • Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

Ventajas

  • La planificación es sencilla.
  • La calidad del producto resultante es alta.
  • Permite trabajar con personal poco cualificado.

Desventajas

  • Lo peor es la necesidad de tener todos los requisitos al principio. 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.
  • 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%).1.1
  • Es comparativamente más lento que los demás y el coste es mayor también.

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.
3.                  Ciclo de vida en V
Este ciclo fue diseñado por Alan Davis, y contiene las mimas etapas que el ciclo cascada puro, A diferencia de aquel, a este se le agregaron dos subetapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño y debubgging.



La ventajas y las desventajas de este modelo son las mismas del ciclo anterior, con el agregado de los controles cruzados entre etapas para lograr una mayor corrección.
Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples (pequeñas transacciones sobre base de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicación de facturación, en la que si bien los procedimientos vistos individualmente son de codificación e interpretación sencilla, la aplicación en su conjunto puede tener matices complicados.

4.                  Modelo de ciclo de vida en espiral

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, etc. 


En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:
  • Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
  • Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
    • Características del producto.
    • Formas de gestionar el proyecto.
  • Restricciones:
    • Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
    • Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
  • Riesgos: Lista de riesgos identificados.
  • Resolución de riesgos: La técnica más usada es la construcción de prototipos.
  • Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
  • Planes: Lo que se va a hacer en la siguiente fase.
  • Compromiso: Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

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.

Desventajas

  • 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.

5.                  Ciclos de vida orientados a objetos.

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:
Ø  Planificación del negocio
Ø  Construcción: Es la más importante y se divide a su vez en otras cinco actividades
o    Planificación
o    Investigación
o    Especificación
o    Implementación
o    Revisión
Ø  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:
  1. Crecimiento: Es el tiempo durante el cual se construye el sistema
  2. 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.


Ciclos de vida Tradicionales
Ciclos de vida orientados a objetos
Todos estos ciclos como el cascada y el modelo en V y el incremental están basados en el análisis y diseño estructurado.
Los ciclos basados en objetos tienen la particularidad de crear componentes que se relacionan entre ellos a través de interfaces.
Al ser de tipo estructurado es muy difícil dividirlos en subsistemas que puedan implementarse independientemente.
Al ser modulares se los puede dividir en mini proyectos de tal forma que no es muy restrictivo a la hora de escoger que proyecto realizar primero o incluso es posible realizarlo simultáneamente.
Los ciclos de vida tradicionales no aseguran un control de riesgos estable y con pocas facilidades de cambios
Reduce la cantidad de riesgos al ser un modelo que siempre ofrece prototipos de forma temprana debido a la facilidad de manipularlo en módulos.

Se hace mucho más difícil la detección y corrección temprana de errores debido a que para realizar una corrección se tiene que evaluar primero el impacto que el mismo tendrá sobre el sistema por su compleja estructura. .
Es mucho más fácil realizar cambios o correcciones debido a su modularidad.
Naturalmente la mayoría de los lenguajes de programación esta orientados a objetos.
Una buena forma de aprender nuevos lenguajes de programación debido a sus librerías de clases y la reutilización de componentes.


Los ciclos tradicionales difícilmente reutilizarían parte de algún proyecto anterior
La ventaja de usar componentes hace posible la reutilización de código para ahorrar tiempo y esfuerzo.



6.                  Conclusion.-
Si bien en un principio el desarrollo de software era orientado a las estructuras se debe a que los clientes estaban educados de forma que se pensaba que el producto se utilizaría por mucho tiempo y por tal motivo se invertiría más dinero y tiempo para realizar todas las tareas del ciclo de vida.
Sin embargo en estos, el mercado para el software es competitivo ya no es suficiente demostrar calidad en el producto, es importante además poder satisfacer las necesidades del cliente con la mayor calidad posible y en el menor tiempo gracias  a las nuevas tecnologías.


Referencias.-
Ø  Ciclo de vida del software – Jose Alvarez y Manuel Ariaz - http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html#tex2html394.

El Ciclo de Vidadel Software(ISG1-ITIG)- Jose Antonio Saenz - http://www.google.com.bo/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CGUQFjAA&url=http%3A%2F%2Fisg1-2009-test.googlecode.com%2Ffiles%2FDLSI-2008-9-ISG1-t2-v0.6.pdf&ei=oUykT4CmD8b1gAfonqTCAQ&usg=AFQjCNEq0L3I6SreXiPtQYAO3RNzkb4rEQ&

lunes, 23 de abril de 2012

METODOLOGIAS DE DESARROLLO DE SOFTWARE TRADICIONALES VS AGILES

 1.                  Resumen.-
Desarrollar software implica muchas cosas, desde su planificación hasta la puesta en marcha se deben de seguir un sinnúmero de pasos o actividades. Hoy en día existen diversas metodologías para hacerlo, sin embargo es necesario definir primero la naturaleza del software antes de elegir un determinado ciclo de vida.
En el presente trabajo se detallan los dos grandes enfoques, tanto metodologías tradicionales y metodologías ágiles, las primeras están pensadas para el uso exhaustivo de documentación durante todo el ciclo del proyecto mientras que las segundas ponen vital importancia en la capacidad de respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una buena relación con el cliente. Se verán diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software para interés del lector.
Palabras Claves ¾ Metodología, RUP, MSF AUP, Scrum, Metodología Tradicional, Metodología Ágil


2.                  Metodologías tradicionales.-
Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la concepción y fundamentos de metodologías  existentes en otras áreas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptación contenía el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software.

Entre las principales metodologías tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las características importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solución para proyectos donde el  entorno es volátil.

Las metodologías tradicionales (formales) se focalizan en documentación, planificación y procesos. (Plantillas, técnicas de administración, revisiones, etc.), a continuación se detalla RUP uno de los métodos más usados dentro de los métodos tradicionales
Rational Unified Process (RUP)
Proceso Unificado Rational

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo.
Fases
Las cuatro fases del ciclo de vida son:
Ø  Concepción
Ø  Elaboración
Ø  Construcción
Ø  Transición




Ventajas
Ø  Evaluación en cada fase que permite cambios de objetivos
Ø  Funciona bien en proyectos de innovación.
Ø  Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
Ø  Seguimiento detallado en cada una de las fases.

Desventajas
Ø  La evaluación de riesgos es compleja
Ø  Excesiva flexibilidad para algunos proyectos
Ø  Estamos poniendo a nuestro cliente en una situación que puede ser muy incómoda para él.
Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.


Microsoft Solution Framework (MSF)
MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.
Todo proyecto es separado en cinco principales fases:
·         Visión y Alcances.
·         Planificación.
·         Desarrollo.
·         Estabilización.
·         Implantación.
Modelo de Equipo de MSF


Microsoft Operation Framework.-
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. En la figura 1 se muestra el funcionamiento del ciclo de MOF.
Ciclo de Microsoft Operations Framework

En la figura, se observa que 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
3.                  Metodologías Agiles.-
Extreme Programming (XP)

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.


Scrum



4.      Diferencias:
Diferencias entre Metodología Tradicionales y Ágiles
Metodologías Tradicionales
Metodologías Agiles
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo
Basadas en heurísticas provenientes de prácticas de producción de código
Cierta resistencia a los cambios
Especialmente preparados para cambios durante el proyecto
Impuestas externamente
Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas políticas/normas
Proceso menos controlado, con pocos principios.
El cliente interactúa con el equipo de desarrollo mediante reuniones
El cliente es parte del equipo de desarrollo
Más artefactos
Pocos artefactos
Más roles
Pocos roles
Grupos grandes y posiblemente distribuidos
Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio
La arquitectura del software es esencial y se
expresa mediante modelos
Menos énfasis en la arquitectura del software
Existe un contrato prefijado
No existe contrato tradicional o al menos es bastante flexible

5.      Conclusión.-
Ø  El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla
Ø  Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia  trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, además debe tener la capacidad de ser equipos  auto-gestionados, altamente motivados y con gran innovación
Ø  Las metodologías tradicionales son pesadas y que suponen obligatoriamente un “todo o nada”.
Ø  Las metodologías ágiles son más modernas y mejores que cualquiera de las tradicionales.
Ø  Las actividades “de calidad” son inútiles y sólo funcionan en equipos grandes, no se adaptan a nuestros proyectos. Cualquier cosa que nos quite tiempo de tareas técnicas (programar, etc.) es una pérdida de tiempo.
Ø  El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software
Ø  Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.