Universidad Nacional Experimental

De los Llanos Occidentales

“Ezequiel Zamora”
Barinas. Estado. Barinas

DESARROLLO ADAPTABLE DE
SOFTWARE (ASD)

Bachilleres:
Rivero Jenny C.I. 24747554
Torres Guerrero Kennymar C.I. 23023059
Profesora: Dajerling Silva
Carrera: Ingeniería en Informática
Subproyecto: Metodologías de desarrollo de software
Sección: 01G1D

Barinas, Marzo de 2014

 INDICE

Pág.

PORTADA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1
Contenido:
INTRODUCCIÓN A ASD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3
FASES DEL CICLO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5
ESPECULAR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -6
COLABORAR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -7
APRENDER - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -8
NORMATIVAS DE CALIDAD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11/12
REFERENCIAS BIBLIOGRAFICAS- - - - - - - - - - - - - - - - - - - - - - - - - - - 13

INDICE DE FIGURAS

Figura Nº1 Fases del ciclo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5

Figura Nº2 Subdivisión de cada ciclo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 9

2
 DESARROLLO ADAPTABLE DE SOFTWARE ASD

Highsmith (2000), Es una metodología ágil que se implementa en el desarrollo de

sistemas de software, formulada por Highsmith en el año 2000, la cual al igual que otras
metodologías de desarrollo de software se basa en un funcionamiento cíclico y reconoce
que en cada iteración se producirán cambios e incluso errores, el desarrollo adaptable de
software se basa en la adaptación continua a los cambios, en ella no hay un ciclo de
planificación, diseño, construcción del software, sino un ciclo de especular, colaborar y
aprender.

Highsmith (2000) desarrolló esta metodología con la intención de ofrecer una alternativa al
desarrollo de software basándose en la idea de que la optimización es la única solución para
problemas de complejidad creciente, ya que para Highsmith los proyectos de software son
sistemas adaptativos complejos y la optimización no hace más que sofocar la emergencia
necesaria para afrontar el cambio.

Según Highsmith los tres siguientes puntos caracterizan a esta metodología:

1. Iterativo: ya que la base de esta metodología se enfoca en un ciclo de vida.

2. Orientado en los componentes del software: definiendo este como un grupo de
funcionalidades a ser desarrolladas durante un ciclo de vida.
3. Tolerante a cambios: fácil adaptación a cambios repentinos de requerimientos, ya
sean estos implantados por el usuario o el análisis del grupo de trabajo.

La estrategia de esta metodología se basa en el concepto de emergencia, una propiedad de

los sistemas adaptativos complejos que describe la forma en que la interacción de las partes
genera una propiedad que no puede ser explicada en función de los componentes
individuales. Highsmith tomo estas ideas de John Holland, el creador del algoritmo
genético, Holland se pregunta, entre otras cosas, cómo hace un macro-sistema
extremadamente complejo, no controlado de arriba hacia abajo en todas las variables
intervinientes (como por ejemplo la ciudad de Nueva York o la Web) para mantenerse

3
funcionando en un aparente equilibrio sin colapsar. La respuesta, que tiene que ver con la
auto-organización, la adaptación al cambio y el orden que emerge de la interacción entre las
partes.

El ciclo de vida que se desarrolla para esta metodología propone tres fases esenciales:
especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se
planifican las características del software; en la segunda desarrollan las características y
finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los
componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

El desarrollo adaptable de software reconoce que las necesidades del cliente son siempre
cambiantes. La iniciación de un proyecto involucra definir una misión para él, determinar
las características y las fechas y descomponer el proyecto en una serie de pasos
individuales, Los pasos iniciales deben verificar el alcance del proyecto; los tardíos tienen
que ver con el diseño de una arquitectura, la construcción del código, la ejecución de las
pruebas finales y el despliegue.

Este ciclo se basa en componentes y no en tareas, es limitado en el tiempo, orientado por

riesgos y tolerante al cambio. Que se base en componentes implica concentrarse en el
desarrollo de software que trabaje, construyendo el sistema pieza por pieza.

En este paradigma, el cambio es bienvenido y necesario, pues se concibe como la

oportunidad de aprender y ganar así una ventaja competitiva; de ningún modo es algo que
pueda ir en deterioro del proceso y sus resultados.

4
 FASES DEL CICLO DE VIDA DEL DESARROLLO ADAPTABLE DE
SOFTWARE

Las fases en las que se trabaja la metodología de desarrollo adaptable de software

son tres: especular, colaborar y aprender, estas fases o etapas corresponden al ciclo de vida
que en esta metodología se realizan para la construcción de un sistema de software.
Cabe destacar que el carácter adaptativo de esta metodología, nos permite tomar pequeñas
desviaciones en cada fase, en que cada ciclo debe componerse de una mezcla entre
funcionalidades críticas, útiles y opcionales, en donde deben priorizarse las críticas ya que
son las que ponen en riesgo el proyecto, luego las útiles, que facilitaran el desarrollo del
sistema y por último las opcionales las cuales no son necesarias en el proyecto. Todo esto
con tal de evitar futuros retrasos en el proyecto. También se pueden tomar grandes
desviaciones las cuales son beneficiosas para el sistema, ya que se utilizan para la
exploración del dominio y la aplicación.

Figura 1

Autores: Torres y Rivero

5
 1. Especular:
Esta fase consiste en realizar una planificación tentativa del proyecto tomando en cuenta las
futuras entregas que se le darán al usuario prototipos. En esta fase se fija un rumbo
determinado el cuál será seguido en la parte de desarrollo y toma mayor énfasis en cada
iteración ya que ASD posee la características de usar cada iteración para APRENDER por
lo que en el momento de especular en las futuras iteraciones esto será de gran importancia
ya que trabajaremos en función de esto para así abordar de una manera más efectiva y
planificada nuestra especulación.

En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y

cambiarán los requerimientos. Gracias a centrarse en la especulación, ASD permite
administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el
borde del caos. Respecto a la especulación, se recomienda realizar una estructura de
desglose del componente, en el cual mediante una hoja de cálculo se pueda conocer la
funcionalidad a ser liberada en cada ciclo.

La etapa de la especulación se subdivide en:

Iniciación del proyecto: en este paso se determina la función y finalidad con la que
va dirigida el proyecto y de igual forma sus requerimientos tanto del software como
del hardware, además se incluye una visión del proyecto en la cual se hace entrega
de un documento que consta de una hoja de datos, un perfil de la misión del
producto y un esquema de su requerimiento, este se entrega cuando el equipo tiene
una idea general de lo que tratará el sistema para poder realizar la iniciación del
proyecto.
Planeación de los ciclos: para este paso se realiza la determinación del numero de
iteraciones que tendrá el proyecto, es decir, la cantidad de veces que se va a repetir
cada etapa (dependiendo del control de calidad), así como la duración que tendrá
cada iteración, al igual se definirá el objetivo de cada una y se le asignara la
funcionalidad de dichas iteraciones.

6
 2. Colaborar:
La siguiente fase del ciclo de vida, colaborar, es aquella en la que se construye la
funcionalidad definida durante la especulación. Durante cada iteración el equipo colabora
intensamente para liberar la funcionalidad planificada. También, existe la posibilidad de
explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar
el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al
momento de llevar a cabo la construcción simplemente mencionando que todas las
prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma
la línea de las metodologías ágiles respecto a la orientación a componentes. El énfasis se
ubica en la relaciones entre las personas que deben estar lo suficientemente enlazadas para
generar una propiedad imprescindible de los organismos complejos: la emergencia, la cual
es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad más
grande del todo el comportamiento del sistema, a partir de la interacción entre las partes el
comportamiento auto-organizativo de los agentes. Gracias a esta propiedad los grupos de
desarrollo logran sacar lo mejor de sí en el borde del caos.

La etapa de la colaboración se subdivide en:

Ingeniería de componentes concurrente: es la unión de varios procedimientos que

sirven para reducir los tiempos que se utilizan en el desarrollo del software, en este
paso se realiza la construcción del sistema software; es decir los elementos que
integran el sistema, como la codificación de la funcionalidad del proyecto así como
el diseño del mismo. Dentro de este paso también se realiza la gestión del producto
lo cual corresponde a dirigir, ordenar y organizar el producto.

7
 3. Aprender:

La fase final de ASD, aprender, consiste en la revisión de calidad que se realiza al final de
cada ciclo. En la misma se analizan cuatro categorías de cosas para aprender:

Calidad del resultado de la desde la perspectiva del cliente: En esta parte se

sugiere, para lograr evaluar la calidad desde el punto de vista del cliente, utilizar
grupos de enfoque hacia el cliente con tal de recoger nuevos requerimientos o
cambios que el cliente pueda requerir.
Calidad del resultado de la desde la perspectiva técnica: Esto consiste en
analizar la calidad del producto revisando el diseño, el código y las pruebas en
función de lograr aprender de los errores y desvíos usados para poder resolverlos, y
esto implica no poner énfasis en encontrar culpables ya que esto afectaría las
relaciones entre el grupo de trabajo. Seguido a esto viene la parte práctica de esta
etapa en la cual se profundiza en las exploraciones que se hayan realizado con lo
cual podremos modificar ya sea el diseño del sistema, o los posibles cambios de
requerimientos que nos dé el cliente.
Funcionamiento del equipo de desarrollo y las prácticas que este utiliza: En
esta etapa del aprendizaje se enfatiza la interacción entre las partes, la dinámica del
grupo y las técnicas que se acordaron emplear. Es importante que al final de cada
ciclo de vida (autopsia), se realicen pequeñas reuniones con el fin de analizar lo
aprendido. Antes de realizar una iteración, se discuten los procesos que favorecen el
desarrollo del proyecto y así mismo descartar los de influencia negativa siendo estos
últimos, los procesos que puedan haber afectado el trabajo del grupo y los que no
son compatibles con los requerimientos.
Estatus del proyecto: En esta última etapa, se revisa todo lo efectuado respecto al
proyecto en función de lo que inicialmente se había planificado, tanto en la parte
técnica como en la humana. En este momento es en donde se detectaran las posibles
diferencias que podrían cambiar el rumbo del proyecto. Una vez que exploramos las
tres fases se realiza el bucle de aprendizaje, en el cual se realizan revisiones de
calidad con presencia del cliente como experto. La presencia del cliente se

8
 suplementa con sesiones de talleres en el que programadores y representantes del
cliente se encuentran para discutir rasgos del producto en términos no técnicos, sino
de negocios.

La etapa de aprender se subdivide en:

Control de calidad: en este paso se verifica la calidad del producto mediante una
serie de pruebas referentes a los criterios del cliente, técnicos, de funcionamiento y
por último el estatus del proyecto, especificadas anteriormente, una vez realizadas
dichas pruebas se conoce si el sistema software cumple con lo establecido por el
cliente y si su funcionabilidad es correcta, será entregado al cliente; de no ser así el
producto empieza a realizarse nuevamente partiendo de la fase de planeación de los
ciclos. Conjuntamente en este paso se entrega un documento el cual se estructura la
descripción del sistema, se hace al finalizar el proyecto para analizar el software
conjuntamente con el cliente.
Entrega final: una vez que el producto ha sido verificado se realiza la entrega del
sistema software al cliente.

Figura 2

Autor: Cristina Roncal

9
 TÉCNICAS Y HERRAMIENTAS

Esta metodología no propone técnicas ni tareas al momento de llevar la construcción,

simplemente ocuparemos las prácticas que sirvan para reforzar el desarrollo del sistema,
siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a
componentes. El énfasis se ubica en las relaciones entre las personas, las cuales deben estar
lo suficientemente buenas para lograr sacar lo mejor, si estamos en momentos críticos del
desarrollo.

En la fase de la especulación, se recomienda utilizar una estructura de desglose del

componente en el cual mediante una hoja de cálculo se pueda conocer la funcionalidad que
será entregada en cada ciclo desarrollado. Otra técnica que se recomienda son las sesiones
JAD son reuniones que se realizan entre el desarrollador y el cliente para capturar los
requerimientos del software y la realización de prototipos para descifrar ambigüedades que
se presenten en el desarrollo.

Algunas de las técnicas de planificación y de control de actividades más empleadas en las

metodologías de desarrollo son la carta Gantt y el diagrama Pert, los cuales se utilizan para
representar de forma grafica las tareas, actividades y tiempos del proyecto. Las
herramientas para emplear las técnicas mencionadas tienen que ser las que mejor se adapten
o en las que mejor dominio se tenga.

Como forma de concluir podemos considerar que:

Usado de manera adecuada esta metodología (Adaptive Software Development) se puede

alcanzar excelentes resultados pero debido a las características que maneja es más factible
usarla para proyectos pequeños y medianos. Sirve para aprender de los errores y volver a
iniciar el ciclo de desarrollo, además de esto se basa en la utilización de información
disponible en tiempo real para la mejora del software; agregando que permite la interacción
entre usuario-cliente y desarrolladores junto con programadores-diseñadores.

10
 SOFTWARE NORMATIVAS DE CALIDAD

CALIDAD EN EL PRODUCTO

ISO (Organización internacional de normalización): Es el organismo encargado de

promover el desarrollo de normas internacionales de fabricación, comercio y comunicación
para todas las ramas industriales a excepción de la eléctrica y la electrónica. Su función
principal es la de buscar la estandarización de normas de productos y seguridad para las
empresas u organizaciones públicas o privadas a nivel internacional.

NORMATIVAS

ISO 9126: Es un estándar internacional para la evaluación de la calidad del software, está
dividido en cuatro partes las cuales dirigen realidad, métricas externas, métricas internas y
calidad en las métricas de uso y expendido. El modelo de calidad establecido clasifica la
calidad del software en un conjunto estructurado de caracterí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.
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.
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.
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.
Mantenibilidad: conjunto de atributos relacionados con la facilidad de extender,
modificar o corregir errores en un sistema software.
Portabilidad: conjunto de atributos relacionados con la capacidad de un sistema
software para ser transferido desde una plataforma a otra.

11
ISO 14598: Proporciona un marco de trabajo para evaluar la calidad de todos los tipos de
software, indicando los requisitos que serán medidos y analizados en este proceso. Se basa
en implementar estándares que garanticen una correcta evaluación del software y aminorar
los errores que pueda presentar cuando se esté ejecutando.

Según esta norma, los componentes fundamentales en la evaluación de la calidad del

software son:

Modelo de calidad.
Método de evaluación.
Medidas de software.
Herramientas de soporte.

ISO 25000: Conocida como requerimientos de calidad de productos de software y

evaluación. El objetivo general de la creación de esta norma es organizar, enriquecer y
agrupar las series que cubren dos procesos principales: especificación de requisitos de
calidad del software y evaluación de la calidad del software, soportada por el proceso de
medición de calidad del software. Las características de calidad y sus mediciones asociadas
pueden ser útiles no solamente para evaluar el producto software sino también para definir
los requerimientos de calidad.

12
 REFERENCIAS BIBLIOGRAFICAS

Schenone (2004), diseño de una metodología ágil de desarrollo de software.

Highsmith (2000), adaptative software development.
Arancibia (2007), Ingeniería de software.
Calderón (2007), Metodologías agiles.

DOCUMENTOS EN LINEA

http://grupocrystal.files.wordpress.com/2007/10/informe-de-metodologia.pdf
http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf
http://www.slideshare.net/urumisama/metodologia-agil-asd
http://www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/Evaluacion%20de%20P
roductos%20-%20G2/Evaluacion%20de%20Productos.pdf
http://www.slideshare.net/albert317/calidad-del-producto-software
http://www.iso25000.com/
http://www.iso.org/iso/catalogue_detail?csnumber=35683

13