Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.1 Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.2

Se pueden citar otras definiciones enunciadas por prestigiosos autores:

Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

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

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.3 El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente títulos de ingeniería de universidades reconocidas.

Algunos autores consideran que "desarrollo de software" es un término más apropiado que "ingeniería de software" para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos "ingeniería de software" o "ingeniería del software". En Hispanoamérica el término usado normalmente es el primero de ellos.

La creación del software es un proceso intrínsecamente creativo y la ingeniería del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa.

La IS se puede considerar como la ingeniería aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicación de ellos de la forma más eficiente para la obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No es sólo de la resolución de problemas, sino más bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.

La ingeniería de software afecta a la economía y las sociedades de variadas formas.

Económicamente

En los Estados Unidos, el software contribuyó a una octava parte de todo el incremento del PIB durante la década de 1990 (alrededor de 90,000 millones de dólares por año), y un noveno de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33.000 millones de dólares estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico en formas similares, aunque es difícil de encontrar estadísticas fiables. [cita requerida]

Además, con la industria del lenguaje está hallando cada vez más campos de aplicación a escala global.

Socialmente[editar · editar código]

La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (E-mail), la WWW y la mensajería instantánea permiten a la gente interactuar en nuevas formas. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a GNU/Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

Metodología[editar · editar código]

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso[editar · editar código]

La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas comunes a casi todos los modelos de ciclo de vida son las siguientes:

Análisis de requisitos[editar · editar código]

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad y experiencia para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requisitos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos

procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de requisitos.

La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requisitos de software (Software Requirements Specification).

No siempre en la etapa de "análisis de requisitos" las distintas metodologías de desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El más conocido de los modelos de estimación de coste del software es el modelo COCOMO

Especificación[editar · editar código]

La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Caso de uso,

Historias de usuario,

Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

Arquitectura[editar · editar código]

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.

El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.

La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software.

La arquitectura de software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases

Diagramas de base de datos

Diagrama de despliegue

Diagrama de secuencia

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar.

Las herramientas para el diseño y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto4 está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.

Modelos y filosofías de desarrollo de software

Artículo principal: Anexo:Filosofías del desarrollo de software

La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede citar:

Modelo en cascada o Clásico (modelo tradicional)

Modelo de prototipos

Modelo en espiral

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

RAD (Rapid Application Development)

Desarrollo concurrente

Proceso Unificado

RUP (Proceso Unificado de Rational)

Naturaleza de la IS[editar · editar código]

La ingeniería de software es una disciplina que está orientada a aplicar conceptos y métodos de ingeniería a la fabricación de software de calidad.

Matemáticas[editar · editar código]

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.

Creación[editar · editar código]

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los

desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la IS.

Gestión de Proyecto[editar · editar código]

El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en Gestión de Proyectos.

Arte[editar · editar código]

Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase.

Responsabilidad[editar · editar código]

La responsabilidad en la ingeniería del software es un concepto complejo, sobre todo porque al estar los sistemas informáticos fuertemente caracterizados por su complejidad, es difícil apreciar sus consecuencias.

En la ingeniería del software la responsabilidad será compartida por un grupo grande de personas, que comprende desde el ingeniero de requisitos, hasta el arquitecto software, y contando con el diseñador, o el encargado de realizar las pruebas. Por encima de todos ellos destaca el director del proyecto. El software demanda una clara distribución de la responsabilidad entre los diferentes roles que se dan en el proceso de producción.

El ingeniero del software tiene una responsabilidad moral y legal limitada a las consecuencias directas.

Desarrollo en cascada

(Redirigido desde «Modelo en cascada»)

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.1

Un ejemplo de una metodología de desarrollo en cascada es:

Análisis de requisitos.

Diseño del Sistema.

Diseño del Programa.

Codificación.

Pruebas.

Implantación.

Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria[cita requerida], sigue siendo el paradigma más seguido al día de hoy.

El "modelo cascada" sin modificar. El progreso fluye de arriba hacía abajo, como una cascada.

Análisis de requisitos[editar · editar código]

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema[editar · editar código]

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito

el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación...

Diseño del Programa[editar · editar código]

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación[editar · editar código]

Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas[editar · editar código]

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificación[editar · editar código]

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.

Mantenimiento[editar · editar código]

Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Variantes[editar · editar código]

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.

Desventajas[editar · editar código]

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.

Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.

Véase también[editar · editar código]

Modelo de prototiposEl Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El

prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos

recursos.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el

cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el

cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La

interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al

mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Etapas[editar · editar código]

Plan rápido

Modelado, diseño rápido

Construcción del Prototipo

Desarrollo, entrega y retroalimentación

Comunicación

Entrega del desarrollo final

Ventajas[editar · editar código]

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no

identifica los requisitos detallados de entrada, procesamiento o salida.

También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de

la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la

interacción humano-máquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más

comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los

modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de

prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de

la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular,

involucra al cliente más profundamente para adquirir el producto.

Inconvenientes[editar · editar código]

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa

de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales

como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a

reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre

reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en

un prototipo evolutivo, pero partiendo de un estado poco recomendado.

En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de

implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque

proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la

razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen

a formar parte del sistema final...

Conclusiones[editar · editar código]

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para

la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el

desarrollador se deben poner de acuerdo en:

Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.

Que el prototipo se descarte, al menos en parte.

Que después se desarrolle el software real con un enfoque hacia la calidad.

Desarrollo en espiralEl desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm

en 1986,1 utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman

en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no

están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo,

comenzando por el bucle interior.

Introducción

La Ingeniería de software, se vale y establece a partir de una serie de modelos que establecen y

muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción

inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del

producto. A estos modelos se les denomina «modelos de ciclo de vida del software». El primer modelo

concebido fue el de Royce, más comúnmente conocido como desarrollo en cascada o desarrollo lineal

secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un

producto software se suceden de forma lineal.

Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzo y tiempo

que se consume en hacer productos software; y Modelos de Ciclo de Vida; ideó y promulgó un modelo desde

un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en

Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se

comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un

ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas

nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que

el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.

Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en una serie de ciclos que se repiten en

forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la

espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El Espiral puede verse como un

modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y

sistemáticos del Modelo Cascada, con el agregado de gestión de riegos.

Ciclos o Iteraciones[editar · editar código]

En cada vuelta o iteración hay que tener en cuenta:

Los Objetivos: qué necesidad debe cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes

puntos de vista como pueden ser:

1. Características: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestión del sistema.

3. Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una

forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más

tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de

un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos

fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad

para detectar y catalogar correctamente los riesgos.

Tareas[editar · editar código]

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.

2. Análisis del riesgo.

3. Planificación.

4. Desarrollar y probar.

Determinar o fijar objetivos[editar · editar código]

Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.

Fijar las restricciones.

Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.

Hay una cosa que solo se hace una vez: planificación inicial.

Desarrollar, verificar y validar(probar)[editar · editar código]

Tareas de la actividad propia y de prueba.

Análisis de alternativas e identificación resolución de riesgos.

Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el

que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo

si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la

construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un

desarrollo basado en transformaciones formales podría ser el más apropiado.

Análisis del riesgo[editar · editar código]

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados

y los daños y consecuencias que éstas puedan producir.

Mecanismos de control[editar · editar código]

La dimensión radial mide el coste.

La dimensión angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral[editar · editar código]

Modelo en Espiral Típico de seis regiones.

Modelo en espiral WIN WIN.

Ventajas[editar · editar código]

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

Integra el desarrollo con el mantenimiento, etc.

Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que

este ciclo de vida no es rígido ni estático.

Desventajas[editar · editar código]

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos

Inconvenientes

Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número

de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y,

para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.

El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV.2

Desarrollo por etapasEl modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente

el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son

conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes

versiones del código.

Pueden distinguirse las siguientes fases:

Especificación conceptual

Análisis de requisitos

Diseño inicial

Diseño detallado, codificación, depuración y liberación

Estas diferentes fases se van repitiendo en cada etapa del diseño.

Este modelo estipula que el software será desarrollado en sucesivas etapas:

1. Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad

y se identifica cualquier restricción aplicable al proyecto.

2. Especificación de requisitos Permite entregar una visión de alto nivel sobre el proyecto, poniendo énfasis

en la descripción del problema desde el punto de vista de los clientes y desarrolladores. También se considera

la posibilidad de una planificación de los recursos sobre una escala de tiempos.

3. Especificación funcional Especifica la información sobre la cual el software a desarrollar trabajará.

4. Diseño Permite describir como el sistema va a satisfacer los requisitos. Esta etapa a menudo tiene

diferentes niveles de detalle. Los niveles más altos de detalle generalmente describen los componentes o

módulos que formarán el software a ser producido. Los niveles más bajos, describen, con mucho detalle, cada

módulo que contendrá el sistema.

5. Implementación Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño del

proyecto, la programación puede ser distribuida entre distintos programadores o grupos de programadores.

Cada uno se concentrará en la construcción y prueba de una parte del software, a menudo un subsistema. Las

pruebas, en general, tiene por objetivo asegurar que todas las funciones están correctamente implementadas

dentro del sistema.

6. Integración Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada

sección es enlazada con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos

los módulos y el sistema se prueba como un todo.

7. Validación y verificación Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es

probado para verificar que el sistema es consistente con la definición de requisitos y la especificación

funcional. Por otro lado, la verificación consiste en una serie de actividades que aseguran que el software

implementa correctamente una función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en

ambiente de explotación.

8. Mantenimiento El mantenimiento ocurre cuando existe algún problema dentro de un sistema existente, e

involucraría la corrección de errores que no fueron descubiertos en las fases de prueba, mejoras en la

implementación de las unidades del sistema y cambios para que responda a los nuevos requisitos. Las

mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.

Desarrollo iterativo y crecienteDesarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en

respuesta a las debilidades del modelo tradicional de cascada.

Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de

trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems

Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de

programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de

software.

Ciclo de vida

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera

incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo

anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el

desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una

implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de

versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el

diseño y se agregan nuevas funcionalidades y capacidades al sistema.

El proceso en sí mismo consiste de:

Etapa de inicialización

Etapa de iteración

Lista de control de proyecto

Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda

interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del

problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente.

Para guiar el proceso de iteración se crea una lista de control de proyecto, que contiene un historial de todas

las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas,

y areas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y constantemente

como resultado de la fase de análisis.

Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis

de la versión más reciente del sistema. La meta del diseño e implementación de cualquier iteración es ser

simple, directa y modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de

control de proyecto. El código puede, en ciertos casos, representar la mayor fuente de documentación del

sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las

funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad,

confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz

de los resultados del análisis.

Las guías primarias que guían la implementación y el análisis incluyen:

Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la

necesidad de rediseñar o recodificar.

Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si

no es así, entonces se requiere algún grado de rediseño.

Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no

ocurre rápidamente, se debe aplicar algo de rediseño.

Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así,

hay un problema primordial usualmente encontrado en un diseño débil o en la proliferación excesiva

de parches al sistema.

Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios

para evitar el rediseño durante una fase de implementación.

La implementación existente debe ser analizada frecuentemente para determinar qué tal se ajusta a

las metas del proyecto.

Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de

implementaciones parciales.

La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación

referida por él.

Caso práctico

La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una

familia de lenguajes de programación en una gama de arquitecturas de hardware. Un conjunto de 17 versiones

del sistema se desarrollaron en un lugar, generando 17 mil líneas de código fuente de lenguaje de alto nivel

(6500 de código ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a

dos versiones diferentes del lenguaje base: una versión esencialmente se enfocaba en aplicaciones

matemáticas, añadiendo números reales y varias funciones matemáticas, y la otra se centró en añadir

capacidades para escribir del compilador. Cada iteración fue analizada del punto de vista de los usuarios (las

capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de vista

del desarrollador (el diseño del compilador evolucionó para ser más fácilmente modificable, por ejemplo, para

añadir nuevos tipos de datos). Mediciones tales como acoplamiento y modularización fueron seguidas sobre

múltiples versiones.

Características

Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor entre las

mejoras iterativas y el desarrollo rápido de aplicaciones, principalmente por dos razones:

Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto.

Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.

Estas mediciones y actividades de análisis pueden ser añadidas a los métodos de desarrollo rápido existentes.

De hecho, el contexto de iteraciones múltiples conlleva ventajas en el uso de mediciones. Las medidas a

veces son difíciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a través de

la evolución del sistema puede ser muy informativo porque proveen una base de comparación. Por ejemplo,

un vector de medidas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en

cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lógico, físico

y dinámico, consideraciones del entorno, etcétera. Así el observador puede decir como las características del

producto como el tamaño, la complejidad, el acoplamiento y la cohesión incrementan o disminuyen en el

tiempo. También puede monitorearse el cambio relativo de varios aspectos de un producto o pueden proveer

los límites de las medidas para apuntar a problemas potenciales y anomalías.

Debilidades de este modelo de desarrollo

Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente

no estarán dispuestos a invertir el tiempo necesario.

Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo

de profesionales sobre el promedio.

Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos están previamente

definidos, o para proyectos "todo/nada" en los cuales se requiere que se completen en un 100% el

producto para ser implementado (por ejemplo, licitaciones)otro punto muy importante es asegurarnos de

que el trabajo se pueda cumplir tomando en cuenta los costos que podamos usar en nuestros propios

recursos

Desarrollo rápido de aplicacionesEl desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un

proceso de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El método

comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer

Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también

la usabilidad, utilidad y la rapidez de ejecución.1 2

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales

como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas

son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el área de la

autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas

de desarrollo rápido de aplicaciones, dentro de ciertos límites.

Antecedentes

Comenzando con las ideas de Barry Boehm y Scott Shultz, Martin desarrolló el Rapid Application Development

durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1990.

Proceso UnificadoEl Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo

de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por

ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso

Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser

adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational,

también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento

particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres

suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que

son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya

que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational

Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso

Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson,Grady

Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de

Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational

utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre

de Proceso Unificado de Rational.

Características

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases

denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en

una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones

ofrecen como resultado un incrementodel producto desarrollado que añade o mejora las funcionalidades del

sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en

el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas

las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de

ellas varía a lo largo del proyecto.

Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los

contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y

desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso

dirigido por casos de uso es el rup. Nota: en UP se estáDirigido por requisitos y riesgos de acuerdo con el

Libro UML 2 de ARLOW, Jim que menciona el tema.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por

dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La

analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los

distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una

etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración

deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

Lenguaje unificado de modelado]

El Lenguaje unificado de modelado no es el sucesor de la oleada de metodos de analisis y diseno orientados a

objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El UML unifica, sobre todo,

los metodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance ha llegado a formar parte

fundamental de la Ingeniería de Software tras su estandarización en 1997 con el OMG (Object Management

Group o Grupo de administracion de objetos).

¿Por qué analizar y diseñar?

En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del código. Después

de todo, los diagramas son solo imagenes bonitas. Ningún usuario va a agradecer la belleza de los dibujos; lo

que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, pág. 7). Por lo tanto,

cuando considere usar el UML es importante preguntarse por qué lo hará y cómo le ayudará a usted cuando

llegue el momento de escribir el código. No existe una evidencia empírica adecuada que demuestre si estas

técnicas son buenas o malas; pero lo que sí es cierto es que es de considerable ayuda para las etapas de

mantenimiento en proyectos de mediana/avanzada envergadura.

Proceso Unificado de RationalEl Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP)

es un proceso de desarrollo de software desarrollado por la empresaRational Software, actualmente propiedad

de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada

para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al

contexto y necesidades de cada organización.

También se conoce por este nombre al software, también desarrollado por Rational, que incluye información

entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational

Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación

más detallada, el Rational Unified Process, que se vendiera como producto independiente...

Principios de desarrollo

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso

El proceso de la adaptacion del software.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos

limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se

podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza

la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como

también los riesgos involucrados.

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación

fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software,

lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de

software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber

con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio

pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre

diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales

de la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción.

El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos

en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable

según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura

muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto

RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y

la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento

de unabaseline (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de

requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan

más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de

implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su

implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que

se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la

comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el

esfuerzo dedicado a una disciplina varía.

Principales características

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo

Administración de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la

arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso

como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una

persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

Fases

Establece oportunidad y alcance

Identifica las entidades externas o actores con las que se trata

Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

'Proceso': Las etapas de esta sección son: (Revise nuevamente la gráfica)

Modelado de negocio

Requisitos

Análisis y Diseño

Implementación

Pruebas

Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

Gestión del cambio y configuraciones

Gestión del proyecto

Entorno

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente

iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio (también llamado Incepción o Concepción).

Elaboración.

Desarrollo (también llamado Implementación, Construcción).

Cierre (también llamado Transición).

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores,

identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y

producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la

arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso

seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben

clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los

usuarios y se realizan las mejoras para el proyecto.

Fase de Transición: El propósito de esta fase es asegurar que el software esté disponible para los usuarios

finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y

proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones

entregadas por las personas involucradas en el proyecto.

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que

sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre

otros) son los siguientes:

Inicio:

Documento Visión

Diagramas de caso de uso

Especificación de Requisitos

Diagrama de Requisitos

Elaboración:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

Diagrama de clases

Modelo E-R (Si el sistema así lo requiere)

Vista de Implementación

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboración

Vista Conceptual

Modelo de dominio

Vista física

Mapa de comportamiento a nivel de hardware.

Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos

Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada

responde adecuadamente a requerimientos funcionales y no funcionales.

Construcción:

Especificación de requisitos faltantes

Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa

Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso

Transición:

Pruebas finales de aceptación

Puesta en producción

Estabilización

Un poco de historia

Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los

contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software compró una

compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos

de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una

convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado

de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en

1998, siendo el arquitecto en jefe Philippe Kruchten.

El primer libro para describir el proceso fue titulado "The Unified Software Development Process (ISBN 0-201-

57169-2)" El Proceso Unificado de Desarrollo de Software (ISBN 0-201-57169-2), y publicado en 1999 por Ivar

Jacobson, Grady Booch y James Rumbaugh.

Comentarios sobre Metodología

Por otro lado, en lo que se refiere a la metodología esta comprende tres principios claves: Dirigido por los

casos de uso, centrado en la arquitectura, iterativo e incremental.

En lo referente a dirigido por los casos de uso, significa que los requerimientos están enfocado a dar valor al

cliente y que el proceso debe garantizar que todo el desarrollo, pruebas, planeación, documentación etc, está

orientado a cubrir estas expectativas del cliente y asegurar que los requerimientos de valor se ponen en

producción.

En lo referente a centrado en arquitectura, significa que hay un énfasis a diseñar una arquitectura de calidad, y

es la arquitectura también la que guía la forma cómo se debe planear y hacer el desarrollo.

En lo referente a iterativo e incremental, significa que el proyecto se divide en varios ciclos de vida (llamadas

iteraciones) que deben dar como resultado un ejecutable. Por cada una de las iteraciones se va agregando

requerimientos y sobre todo valor al cliente; por este motivo es incremental.

UsabilidadEl neologismo usabilidad 1 2 (del inglés usability -facilidad de uso-) se refiere a la facilidad con que las

personas pueden utilizar una herramienta particular o cualquier otro objeto fabricado por humanos con el fin de

alcanzar un objetivo concreto. La usabilidad también puede referirse al estudio de los principios que hay tras la

eficacia percibida de un objeto. La usabilidad es un término que no forma parte del diccionario de la Real

Academia Española (RAE), aunque es bastante habitual en el ámbito de la informática y la tecnología.

En interacción persona-ordenador, la usabilidad se refiere a la claridad y la elegancia con que se diseña la

interacción con un programa de ordenador o un sitio web. El término también se usa a menudo en el contexto

de productos como la electrónica de consumo o en áreas de comunicación, y en objetos que transmiten

conocimiento (por ejemplo, un libro de recetas o un documento de ayuda en línea). También puede referirse al

diseño eficiente de objetos mecánicos como, por ejemplo, un manubrio o un martillo.

El grado de usabilidad de un sistema es, por su parte, una medida empírica y relativa de la usabilidad del

mismo. Se mide a partir de pruebas empíricas y relativas.

Empírica porque no se basa en opiniones o sensaciones, sino en pruebas de usabilidad realizadas

en laboratorio u observadas mediante trabajo de campo.

Relativa porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas (por

lo menos el 80% de los usuarios de un determinado grupo o tipo definido deben poder instalar con éxito el

producto X en N minutos sin más ayuda que la guía rápida) o de una comparación con otros sistemas

similares.

El concepto de usabilidad se refiere a una aplicación (informática) de (software) o un aparato (hardware),

aunque también puede aplicarse a cualquier sistema hecho con algún objetivo particular.

El modelo conceptual de la usabilidad, proveniente del diseño centrado en el usuario, no está completo sin la

idea utilidad. En inglés, utilidad + usabilidad es lo que se conoce como usefulness.

Jakob Nielsen definió la usabilidad como el atributo de calidad que mide lo fáciles que son de usar las

interfaces Web.3

o

Orígenes controvertidos del término

El término usabilidad, aunque de origen latino, en el contexto que se utiliza deriva directamente del

inglés usability. En castellano significa capacidad de uso, es decir, la característica que distingue a los objetos

diseñados para su utilización de los que no. Sin embargo la acepción inglesa es más amplia y se refiere a la

facilidad o nivel de uso, es decir, al grado en el que el diseño de un objeto facilita o dificulta su manejo.

Una objeción a esta pretensión de otorgarle amplitud de interpretación al término en inglés y negársela o

restringírsela a su acepción en español, describe y manifiesta claramente el complejo lingüístico y cultural que

afecta a aciertos usuarios y profesionales, en particular y especialmente del sector informático en nuestras

comunidades de habla hispana, especialmente latinoamericanas. Usability así como usefulness tienen sus

correlatos españoles en "uso", "funcional", "funcionalidad", "utilidad", "utilizable" respectivamente. El uso,

funcionalidad o utilidad de un diseño, programa u objeto no está sólo en la aplicación inmediata que hacemos

de ellos, sino también y sobre todo en el beneficio o solución que obtenemos. A partir de ahora definiremos el

término usabilidad basándonos en la segunda acepción.4

Según David Branderbest, la usabilidad define el objetivo del sistema creado. Sin ella, cualquier mensaje o

contenido no tiene sentido, lo que es tan obvio que no debería ser objeto de discusión siquiera. Si bien el

concepto mismo de usabilidad es de reciente aplicación, desde hace mucho tiempo se maneja por criterios

como facilidad de uso, amistoso con el usuario, etc. Muchos casos y empresas acumulan muestras de cómo el

interés por lo que hoy denominamos usabilidad moderna se remonta a varias décadas atrás. Algunas

conclusiones y casos recogidos en estudios e investigaciones por Sun Microsystems:5

La usabilidad demuestra reducciones del ciclo de desarrollo de los productos de 33-50% (Bosert

1991).

63% de todos los proyectos de desarrollo de software sobrepasan su presupuesto, siendo las cuatro

causas más importantes relacionadas con usabilidad. (Lederer y Prassad 1992).

El porcentaje de código que se dedica al desarrollo de la interfaz con los usuarios ha ido aumentando

a lo largo de los años hasta un promedio 47-60% del conjunto de la aplicación. (MacIntyre et al. 1990).

La empresa Ricoh descubrió que el 95% de los usuarios encuestados nunca utilizaban las tres

características claves diseñadas para hacer más atractivo el producto, bien por desconocer su existencia,

no saber cómo utilizarlas o no entenderlas. (Nussbaum y Neff 1991).

80% de las tareas de mantenimiento se deben a requerimientos de usuarios no previstos, quedando

el resto debido a fallos y errores. (Martin y McClure 1993; Pressman 1992)

Por otro lado, la introducción de criterios tendentes a hacer amigable y fácil de usar un producto, no puede

negarse desde tiempos inmemoriables, desde la cinta para sujetar una prenda de vestir hasta las asas en

viejas ánforas prehistóricas, tuvieron como idea original facilitar el uso de un objeto, por ende éste se hacía

más atractivo y por consiguiente cobraba otro valor en el mercado.

Definiciones formales

La Organización Internacional para la Estandarización (ISO) ofrece dos definiciones de usabilidad:4 6

ISO/IEC 9126:

"La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo

para el usuario, en condiciones específicas de uso"

Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su

funcionalidad y eficiencia. La usabilidad depende no sólo del producto si no también del usuario. Por ello un

producto no es en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto

particular y por usuarios particulares. La usabilidad no puede ser valorada estudiando un producto de manera

aislada (Bevan, 1994).

ISO/IEC 9241:

"Usabilidad es la eficacia, eficiencia y satisfacción con la que un producto permite alcanzar objetivos

específicos a usuarios específicos en un contexto de uso específico"

Es una definición centrada en el concepto de calidad en el uso, es decir, se refiere a cómo el usuario realiza

tareas específicas en escenarios específicos con efectividad.

Otros aspectos de la usabilidad

A partir de la conceptualización llevada a cabo por la ISO, se infieren los principios básicos en los que se basa

la usabilidad:4

Facilidad de Aprendizaje: facilidad con la que nuevos usuarios desarrollan una interacción efectiva

con el sistema o producto. Está relacionada con la predicibilidad, sintetización, familiaridad, la

generalización de los conocimientos previos y la consistencia.

Facilidad de Uso: facilidad con la que el usuario hace uso de la herramienta, con menos pasos o más

naturales a su formación específica. Tiene que ver con la eficacia y eficiencia de la herramienta.

Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el sistema pueden

intercambiar información. También abarca la posibilidad de diálogo, la multiplicidad de vías para realizar la

tarea, similitud con tareas anteriores y la optimización entre el usuario y el sistema.

Robustez: es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Está

relacionada con la capacidad de observación del usuario, de recuperación de información y de ajuste de

la tarea al usuario.

En informática, la usabilidad está muy relacionada con la accesibilidad, hasta el punto de que algunos

expertos consideran que una forma parte de la otra o viceversa. Uno de estos expertos y gurú de la usabilidad

en los entornos web es Jakob Nielsen, quien definió la usabilidad en el 2003 como "un atributo de calidad que

mide lo fáciles de usar que son las interfaces web".

Otra definición clarificadora es la de Redish (2000), para quien es preciso diseñar sitios web para que los

usuarios sean capaces de "encontrar lo que necesitan, entender lo que encuentran y actuar apropiadamente…

dentro del tiempo y esfuerzo que ellos consideran adecuado para esa tarea".

La usabilidad por lo tanto se dirige a conseguir el objetivo de satisfacer más a los usuarios, con un sitio web

más eficaz y eficiente.

Fuera del ámbito informático, la usabilidad está más relacionada con la ergonomía y los factores humanos.

La ergonomía parte de los principios del diseño universal o diseño para todos. La buena ergonomía puede

lograrse mediante el diseño centrado en el usuario (que no necesariamente dirigido por él), aunque se

emplean diversas técnicas. El diseñador de ergonomía proporciona un punto de vista independiente de las

metas de la programación porque el papel del diseñador es actuar como defensor del usuario. Por ejemplo,

tras interactuar con los usuarios, el diseñador de ergonomía puede identificar necesidades funcionales o

errores de diseño que no hayan sido anticipados.

La ergonomía incluye consideraciones como:

¿Quiénes son los usuarios, cuáles sus conocimientos, y qué pueden aprender?

¿Qué quieren o necesitan hacer los usuarios?

¿Cuál es la formación general de los usuarios?

¿Cuál es el contexto en el que el usuario está trabajando?

¿Qué debe dejarse a la máquina? ¿Qué al usuario?

Las respuestas a estas preguntas pueden conseguirse realizando análisis de usuarios y tareas al principio del

proyecto.

Otras consideraciones incluyen:

¿Pueden los usuarios realizar fácilmente sus tareas previstas? Por ejemplo, ¿pueden los usuarios

realizar las tareas previstas a la velocidad esperada?

¿Cuánta preparación necesitan los usuarios?

¿Qué documentación u otro material de apoyo están disponible para ayudar al usuario? ¿Puede éste

hallar las respuestas que buscan en estos medios?

¿Cuáles y cuántos errores cometen los usuarios cuando interactúan con el producto?

¿Puede el usuario recuperarse de los errores? ¿Qué han de hacer los usuarios para recuperarse de

los errores? ¿Ayuda el producto a los usuarios a recuperarse de los errores? Por ejemplo, ¿muestra el

software mensajes de error informativos y no amenazantes?

¿Se han tomado medidas para cubrir las necesidades especiales de los usuarios con

discapacidades? (Es decir, ¿se ha tenido en cuenta la accesibilidad?)

Ejemplos de técnicas para hallar respuesta a estas y otras cuestiones son: análisis de requisitos enfocado al

usuario, construcción de perfiles de usuarios y pruebas de usabilidad.

Reglas de usabilidad web

Existen 5 principales reglas que adaptadas a una web, se les puede considerar como un web "usable".

Rápido - Las páginas deben cargarse en una media de 4 segundos. Los usuarios lo más que esperarán en

ver el contenido de una página web es de una media de 10 segundos. - La mayoría de los usuarios disponen

de módem para su acceso a Internet, por lo que nuestras páginas deben de ser lo menos pesadas posibles

con el fin de que los usuarios no esperen mucho tiempo, porque de lo contrario cancelarán la visita.

Simple - Mantenga una navegación constante. No fuerce a los visitantes a aprender diversos caminos o

esquemas para la navegación en diversas partes de su site. - No abuse de la utilización de la animación, esto

puede abrumar y cansar la vista.

Investigable - Los motores de búsqueda buscan el texto real. No prestan ninguna atención a los gráficos y al

código de programación (como el Javascript). Evite estas situaciones si desea que su web esté bien

posicionada en los buscadores.

Para la mayoría - Los Sitios Web necesitan ser compatibles con todos los navegadores y ordenadores para

su fácil usabilidad. - Utilice HTML simple y llano siempre que sea posible, es el código más compatible con

todos los navegadores.

Manténgalo actualizado - La manera más rápida para que una web pierda credibilidad es contener la

información anticuada.

Beneficios de la usabilidad

Entre los principales beneficios se encuentran:4

Reducción de los costes de aprendizaje y esfuerzos.

Disminución de los costes de asistencia y ayuda al usuario.

Disminución en la tasa de errores cometidos por el usuario y del retrabajo.

Optimización de los costes de diseño, rediseño y mantenimiento.

Aumento de la tasa de conversión de visitantes a clientes de un sitio web.

Aumento de la satisfacción y comodidad del usuario.

Mejora la imagen y el prestigio.

Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la

productividad.

Todos estos beneficios implican una reducción y optimización general de los costes de producción, así como

un aumento en la productividad. La usabilidad permite mayor rapidez en la realización de tareas y reduce las

pérdidas de tiempo.

Un caso real, después de ser rediseñado prestándose especial atención a la usabilidad, el sitio web

de IBM incrementó sus ventas en un 400% (InfoWorld, 1999).

¿Cómo se puede conseguir un alto nivel de usabilidad? según la Fundación SIDAR

Adaptando el proceso de desarrollo a los principios del Diseño Centrado en el Usuario: [1]

¿Por qué es importante la usabilidad? según la Fundación SIDAR

El establecimiento de unos principios de diseño en ingeniería de usabilidad han tenido como consecuencia

probada:

Una reducción de los costes de producción: los costes y tiempos de desarrollo totales pueden ser

reducidos evitando el sobrediseño y reduciendo el número de cambios posteriores requeridos en el

producto.

Reducción de los costes de mantenimiento y apoyo: los sistemas que son fáciles de usar requieren

menos entrenamiento, menos soporte para el usuario y menos mantenimiento.

Reducción de los costes de uso: los sistemas que mejor se ajustan a las necesidades del usuario

mejoran la productividad y la calidad de las acciones y las decisiones. Los sistemas más fáciles de utilizar

reducen el esfuerzo (stress) y permiten a los trabajadores manejar una variedad más amplia de tareas.

Los sistemas difíciles de usar disminuyen la salud, bienestar y motivación y pueden incrementar el

absentismo. Tales sistemas suponen pérdidas en los tiempos de uso y no son explotados en su totalidad

en la medida en que el usuario pierde interés en el uso de las características avanzadas del sistema, que

en algunos casos podrían no utilizarse nunca.

Mejora en la calidad del producto: el diseño centrado en el usuario resulta en productos de mayor

calidad de uso, más competitivos en un mercado que demanda productos de fácil uso.

Opiniones de Jakob Nielsen[

Jakob Nielsen, considerado el padre de la Usabilidad, la definió como el atributo de calidad que mide lo fáciles

de usar que son las interfaces web. Es decir un sitio web usable es aquél en el que los usuarios pueden

interactuar de la forma más fácil, cómoda, segura e inteligentemente posible.

No sólo la tecnología y el aspecto gráfico son factores determinantes para hacer un sitio web llamativo. Es

importante que cumpla con las siguientes características:

Entendible

Novedoso

Comprensible

Inteligente

Atractivo

Es decir la finalidad, en este caso de un sitio web, es lograr que el usuario encuentre lo que busca en el menor

tiempo posible.

La Usabilidad de un sitio web está determinada por sus contenidos, entre más cercanos estén al usuario,

mejor es la navegación por el mismo y más acertada será la experiencia al enfrentarse a la pantalla.

Lógicamente es imposible crear un sitio web ciento por ciento perfecto y en óptimas condiciones, pues no se

puede agradar al mismo tiempo a millones de usuarios, sin embargo, los diseñadores y creadores deben tratar

de mostrar todos los elementos de una manera clara y concisa, minimizando el número de clics y de scroll.

En ocasiones los cibernautas se enfrentan a sitios Web de altísima calidad y contenido, pero que presentan

dificultades en su contenido. Por ejemplo, que los menúes son de difícil ubicación, o que la herramienta de

búsqueda no aparece en un lugar visible.

Aunque no hay estándares definidos para la Usabilidad, depende en cierta forma del espacio donde se

desenvuelve el navegante. Pero lo importante en este caso es que el usuario no se deje consumir ni dominar

por el sitio, es decir que sea él mismo que tome el control de la navegación por medio de un aprendizaje

sencillo y el dominio de los elementos necesarios, para encontrar finalmente y en el menor tiempo posible, lo

que busca.

Un buen sitio Web debe responder a las necesidades del usuario. En una comunidad virtual donde confluyen

diferentes culturas e intereses, el contexto en el que se desenvuelven los miembros de un grupo virtual, o

comunidad, no puede generar molestias en el momento de la navegación.

Un error recurrente de los creadores y diseñadores de sitios Web, es querer imponer sus decisiones y criterios

sin pensar en el usuario. Por eso en el momento de diseñar el sitio e introducir contenidos, siendo está última

labor de los editores, y no de los diseñadores, es importante pensar en el otro.

Reconocimiento en la industria del software

Actualmente la usabilidad está reconocida como un importante atributo de calidad del software, habiéndose

ganado un puesto entre atributos más tradicionales como el rendimiento y la fiabilidad. Incluso diversos

programas de estudios se centran en ella. También han surgido diversas empresas de consultoría de

usabilidad, y las firmas tradicionales de consultoría y diseño están ofreciendo servicios similares para este

término tan asociado al marketing. Desde un enfoque del diseño y evaluación de aplicaciones software,

hablamos de usabilidad software como un área incluida en el campo de la Interacción Persona

Ordenador (IPO) que se define como un conjunto de fundamentos teóricos y metodológicos que aseguran el

cumplimiento de los niveles de usabilidad requeridos. Se trata, fundamentalmente, de decidir qué atributos del

concepto de usabilidad deben de ser priorizados, para lograr metas verificables y medibles de niveles de

usabilidad cuyo objetivo último es atraer la atención del usuario lo máximo posible ya sea por motivos

económicos, publicitarios u otros.

Prueba de usabilidadLas pruebas de usabilidad es una técnica usada en el diseño de interacciones centrado en el usuario para

evaluar un producto mediante pruebas con los usuarios mismos. Esto puede ser visto como una práctica

de usabilidad irreemplazable, dado que entrega información directa de como los usuarios reales utilizan el

sistema.1 Este es en contraste con los métodos de inspección de usabilidad donde expertos usan diferentes

métodos para evaluar una interfaz de usuario sin involucrar a usuarios reales.

Las pruebas de usabilidad se enfocan en medir la capacidad de un producto de fabricación humana en cumplir

el propósito para el cual fue diseñado. Ejemplos de productos que normalmente se benefician de pruebas de

usabilidad son comidas, productos de consumo, sitios web o aplicaciones web, interfaces de usuario,

documentos y dispositivos. Las pruebas de usabilidad miden la usabilidad, o facilidad de uso, de un objeto

específico o un conjunto de objetos, mientras que los estudios de interacción persona-computadorintentan

formular los principios generales.

Las pruebas de usabilidad consisten en seleccionar a un grupo de usuarios de una aplicación y solicitarles que

lleven a cabo las tareas para las cuales fue diseñada, en tanto el equipo de diseño, desarrollo y otros

involucrados toman nota de la interacción, particularmente de los errores y dificultades con las que se

encuentren los usuarios.

No es necesario que se trate de una aplicación completamente terminada, pudiendo tratarse de un prototipo.

Métricas de usabilidad

Exactitud : Número de errores cometidos por los sujetos de prueba y si estos fueron recuperables o no

al usar los datos o procedimientos adecuados.

Tiempo  requerido para concluir la actividad.

Recuerdo : Qué tanto recuerda el usuario después de un periodo sin usar la aplicación.

Respuesta emocional: Cómo se siente el usuario al terminar la tarea (bajo tensión, satisfecho, mole

Arquitectura de la información

La arquitectura de la Información (AI) es la disciplina y arte encargada del estudio, análisis, organización,

disposición y estructuración de la información en espacios de información, y de la selección y presentación de

los datos en los sistemas de información interactivos y no interactivos.

En relación con la World Wide Web, el Information Architecture Institute define la Arquitectura de la

Información como:

1. El diseño estructural en entornos de información compartida.

2. El arte y la ciencia de organizar y rotular sitios web, intranets, comunidades en línea y software para

promover la usabilidad y la ubicabilidad (la característica de ser encontrado a través de las búsquedas en

Internet).

3. Una comunidad emergente orientada a aplicar al entorno digital los principios del diseño y la

arquitectura.

La Arquitectura de la Información trata indistintamente del diseño de: sitios web, interfaces de dispositivos

móviles o gadgets (como los lectores de mp3), CD interactivos, videoclips digitales, relojes, tableros de

instrumentos de aviones de combate o civiles, interfaces de máquinas dispensadoras, interfaces de juegos

electrónicos, etc. (Laverde, A. 2005)

Su principal objetivo es facilitar al máximo los procesos de comprensión y asimilación de la información, así

como las tareas que ejecutan los usuarios en un espacio de información definido.

Origen del término Arquitectura

El término Arquitectura empieza a utilizarse por primera vez en el ámbito de la informática en el año 19591 en

el trabajo de Lyle R. Jonson y Frederick P. Brook de IBM. No obstante hay que esperar hasta 1970 cuando

Xerox reunió a un grupo de científicos del ámbito de las Ciencias de la Información

(bibliotecología exactamente) y las Ciencias naturales a los que encargó la creación de una "Arquitectura de la

Información".2

Richard Saul Wurman fue el segundo que utilizó la acepción como nombre del tema central de la conferencia

del Instituto Americano de Arquitectos (AIA) que se celebró en 1976. Como menciona R. E. Wyllys no deja de

ser una curiosa coincidencia histórica que este evento se organizase justo cien años después del primer

encuentro de la American Library Association.

Wurman, arquitecto de profesión, estaba interesado en la clase de interacción que se producía entre las

personas y su ámbito urbano, y en el tipo de medios que podían ayudar a transmitir la información de estos

entornos a los profesionales de la arquitectura, ingenieros, turistas y a los ciudadanos en general. Era una

concepción más próxima al mundo del diseño gráfico, a la visualización de información, a la planificación

urbana y a la capacidad de orientarse en entornos urbanos que al medio digital.

En 1996, Wurman publicó su libro "Information Architects" en el que aportaba tres someras definiciones de su

concepto de Arquitectura de la Información. Sin embargo, no fue hasta 1998 cuando Louis Rosenfeld y Peter

Morville (Masters en bibliotecología) fundadores de Argus-Inc, publicaron su famoso libro "Information

Architecture for the World Wide Web" (también conocido como el "Libro del Oso Polar") en el que adoptaron el

término extrapolándolo al ámbito del diseño de sitios web y sistematizaron por primera vez los principios de la

emergente disciplina.

Arquitectura de la Información como proceso

La "arquitectura de la información" es un proceso iterativo, transversal, que se da a lo largo de todo el diseño

del sitio y en cada una de sus fases, para asegurarse de que los objetivos de su producción y del desarrollo de

la interfaz se cumplen de manera efectiva.

La Arquitectura de la Información como disciplina no busca definir una metodología de diseño universal sino

articular un conjunto de técnicas para ayudar al desarrollo y producción de espacios de información como los

sitios web.

Con el fin de que la asimilación de contenidos por parte del usuario sea eficiente y efectiva, y para que el sitio

sea accesible y usable, la Arquitectura de la Información como proceso en general se encarga, durante el

desarrollo, de definir:

El objeto, propósito y fines del sistema de información o sitio

La definición del público objetivo y los estudios de la audiencia

La realización de análisis competitivos

El diseño de la interacción

El diseño de la navegación, esquemas de organización y facetación de los contenidos

El etiquetado o rotulado de los contenidos para acceder a la información

La planificación, gestión y desarrollo de contenidos

La facilidad de búsqueda y el diseño de la interfaz de búsqueda

La usabilidad

La accesibilidad

El feedback del resultado y los procesos de reingeniería del sitio

Entregables del Arquitecto de Información

Normalmente, el trabajo de los Arquitectos de Información se concreta en la generación de un conjunto de

materiales entregables (del inglés Deliverables) en los que se plasma de forma efectiva la estructura del

espacio de información, el diseño de la interacción del usuario con el sistema y el funcionamiento de la

interfaz. Estos materiales tienen la doble finalidad de servir como material que se suministrará:

A los clientes como resultado del proceso de diseño o reingeniería del sitio llevado a cabo durante la

fase de análisis, definición y desarrollo del proyecto.

A los diseñadores gráficos como material de base para la producción de maquetas gráficas que

utilizarán los maquetadores para la elaboración de las plantillas en las que se basarán todas las páginas

del sitio web.

A los ingenieros informáticos para ayudar a desarrollar la parte de procesamiento y lógica del sitio.

Arquitectura de la Información como abstracción

La Arquitectura de la Información no trata del establecimiento de un conjunto de pasos o guías predefinidas,

sino del diseño inteligente que subyace detrás de una interfaz o espacio de información. Trata de maximizar

las sinergias que se producen entre interactividad, navegación y contenido con el objetivo de alcanzar una

integración sistémica con el cerebro del usuario logrando un fenómeno de persuasión, conocimiento o

información simbiótica que se traspasa de un sistema de información a otro.

De esta forma, las acciones de buscabilidad, encontrabilidad y recuperabilidad de los contenidos se realizan

en un contexto óptimo en ambos aspectos del sistema de información (interfaz y usuario), interactúan

iniciándose un proceso de comunicación que los enriquece mutuamente. Por un lado, la interfaz cumple con

su objetivo y puede ser mejorada y, por otro, el usuario encuentra lo que busca, lo asimila con facilidad y lo

utiliza.

El Arquitecto de Información

Es la persona encargada de llevar a cabo y verificar el proceso de diseño del sitio; además, trabaja

estrechamente con los diseñadores gráficos y los responsables del la parte de procesamiento y lógica (back-

end) para definirla. Está integrado en un equipo y sus tareas abarcan desde la fundamentación del proyecto

hasta el rediseño, verificación y testado del producto durante todas las fases de desarrollo hasta la obtención

del resultado final.

La A.I. es una nueva profesión que surge en 1996 a raíz de la evolución y transformación de la World Wide

Web en un canal y medio de comunicación. Su aparición en un contexto social, cultural, económico y político

está fuertemente condicionada por las Nuevas Tecnologías de la Información, tecnologías que han modificado

bruscamente y a todos los niveles las formas de comunicación entre los seres humanos, así como la manera

en que perciben y asimilan información.

Estos avances en telecomunicaciones, ciencia, y tecnología en general han producido una cantidad ingente de

conocimiento, de nuevos conceptos, ideas, métodos, procesos, visiones, problemas y soluciones sobre los

que interviene la Arquitectura de la Información que, en concreto, busca:

Procesar y dosificar la enorme cantidad de información que se ha producido a causa de los

descubrimientos y nuevas investigaciones en todos los nuevos campos surgidos a causa de la revolución

de Internet, así como ponerla a disposición de una manera clara, relevante y significativa a disposición del

usuario común. Se trata, entre otras cosas, de hacer comprensible lo abstracto de alguna forma.

Desarrollar y verificar procesos de producción o diseño de información con el fin de que el usuario

pueda recuperar la información de un determinado espacio de manera clara, precisa y sin ambigüedades,

en cualquier plataforma o soporte; en concreto, se refiere a soportes multimedia e interactivos, aunque,

retomando a Shedroff, en la práctica no debemos omitir ningún soporte por plano que este sea y hablar

de experiencias de usuario.

Organizar, estructurar, sistematizar (Tufte), rotular, distribuir, diseñar estructuralmente sistemas

de información (Baeza, Rivera, Velasco, 2003) con el fin de que el usuario pueda hacer de su experiencia

de recuperación algo simple, agradable, eficaz y productivo.

La experiencia de usuario

Se entiende por experiencia de usuario el conjunto de factores y elementos que determinan la interacción

satisfactoria del usuario con un entorno o dispositivo concretos, siendo capaces de generar en él un conjunto

de emociones positivas sobre el medio y su uso.

En la experiencia de usuario intervienen la arquitectura de la información, el diseño de interacción, la

usabilidad, la accesibilidad, el diseño gráfico, la estética, la psicología cognitiva, y la extrapolación de

principios del mundo del marketing, entre otras disciplinas. Nathan Shedroff extiende el concepto de

experiencia del usuario más allá de la Web planteando su Teoría unificada del diseño que articula en torno a

los conceptos clave de diseño de información, percepción e interactividad.

La arquitectura de la información es una parte específica del marco global más amplio que es la experiencia

de usuario.

Kanban (desarrollo)Este artículo se refiere a la gestión de procesos y método de mejora. Para el proceso de manufactura esbelta,

consulte Kanban.

Kanban es un método para gestionar el trabajo intelectual, con énfasis en la entrega justo a tiempo, mientras

no se sobrecargan a los miembros del equipo. En este enfoque, el proceso, desde la definición de una tarea

hasta su entrega al cliente, se muestra para que los participantes lo vean y los miembros del equipo tomen el

trabajo de una cola.

Kanban se puede dividir en dos partes:

Kanban  - Un sistema de gestión de proceso visual que le indica qué producir, cuándo producirlo, y

cuánto producir.

El método Kanban - Una aproximación a la mejora del proceso evolutivo e incremental para las

organizaciones.

Índice

El método Kanban

En el desarrollo de software, utilizamos un sistema Kanban virtual para limitar el trabajo en curso. A pesar de

que el nombre se origina del idioma japonés "Kanban", y se traduce aproximadamente como "tarjeta de señal",

y hay tarjetas utilizadas en la mayoría de las implementaciones de Kanban en desarrollo de software, estas

tarjetas no funcionan en realidad como señales para realizar más trabajo. Representan los elementos de

trabajo. De ahí el término "virtual" porque no existe una tarjeta física.

El método Kanban formulado por David J. Anderson1 2 es una aproximación al proceso gradual, evolutivo y al

cambio de sistemas para las organizaciones. Utiliza un sistema de extracción limitada del trabajo en curso

como mecanismo básico para exponer los problemas de funcionamiento del sistema (o proceso) y estimular la

colaboración para la mejora continua del sistema. Un ejemplo del sistema de extracción es el sistema Kanban,

y es después de esta popular forma de trabajo en curso, que se ha denominado el método.

Los principios del método Kanban El método Kanban tiene sus raíces en cuatro principios básicos:

1. Comience con lo que hace ahora

El método Kanbn se inicia con las funciones y procesos que ya se tienen y estimula cambios

continuos, incrementales y evolutivos a su sistema.

2. Se acuerda perseguir el cambio incremental y evolutivo

La organización (o equipo) deben estar de acuerdo que el cambio continuo, gradual y evolutivo es la

manera de hacer mejoras en el sistema y debe apegarse a ello. Los cambios radicales pueden

parecer más eficaces, pero tienen una mayor tasa de fracaso debido a la resistencia y el miedo en la

organización. El método Kanban anima a los pequeños y continuos cambios incrementales y

evolutivos a su sistema actual.

3. Respetar el proceso actual, los roles, las responsabilidades y los cargos

Tenemos que facilitar el cambio futuro; acordando respetar los roles actuales, responsabilidades y

cargos, eliminamos los temores iniciales. Esto nos debería permitir obtener un mayor apoyo a nuestra

iniciativa Kanban.

4. Liderazgo en todos los niveles

Se debe alentar hechos de liderazgo en todos los niveles de la organización de los contribuyentes

individuales a la alta dirección.

Seis prácticas centrales del método Kanban

Anderson identificó cinco características básicas que se habían sido observadas en cada implementación

correcta del método Kanban. Posteriormente fueron etiquetadas como prácticas y se ampliaron con la adición

de una sexta característica.3

1. Visualizar

Visualizando el flujo de trabajo y hacerlo visible es el base para comprender cómo avanza el trabajo.

Sin comprender el flujo de trabajo, realizar los cambios adecuados es más difícil. Una forma común de

visualizar el flujo de trabajo es el uso de columnas. Las columnas representan los diferentes estados

o pasos en el flujo de trabajo.

2. Limitar el trabajo en curso

Limitar el trabajo en curso implica que un sistema de extracción se aplica en la totalidad o parte del

flujo de trabajo. El sistema de extracción actúa como uno de los principales estímulos para los

cambios continuos, incrementales y evolutivos en el sistema.

3. Dirigir y gestionar el flujo

Se debe supervisar, medir y reportar el flujo de trabajo a través de cada estado. Al gestionar

activamente el flujo, los cambios continuos, graduales y evolutivos del sistema pueden ser evaluados

para tener efectos positivos o negativos.

4. Hacer las Políticas de Proceso Explícitas

Configure las reglas y directrices de su trabajo. Entienda las necesidades y asegúrese de seguir las

reglas. Las políticas definirán cuándo y por qué una tarjeta debe pasar de una columna a otra.

Escríbalas. Cambie las reglas cuando la realidad cambie.

5. Utilizar modelos para reconocer oportunidades de mejora

Cuando los equipos tienen un entendimiento común de las teorías sobre el trabajo, el flujo de trabajo,

el proceso y el riesgo, es más probable que sea capaz de construir una comprensión compartida de

un problema y proponer acciones de mejora que puedan ser aprobadas por consenso. El método

Kanban sugiere que un enfoque científico sea utilizado para implementar los cambios continuos,

graduales y evolutivos. El método no prescribe un método científico específico para utilizarlo.

Comportamiento emergente con Kanban

Hay una creciente lista de comportamientos emergentes que hemos llegado a esperar de la implementación

de Kanban, tales como4

Proceso único a la medida de cada cadena de valor

Cadencias desacopladas

Trabajo programado por el costo de la demora

Valor optimizado con clases de servicio

Gestión de riesgo con asignación de capacidad

Tolerancia en la experimentación de procesos

Gestión cuantitativa

Propagación viral de Kanban en toda la organización

Pequeños equipos fusionados para crear bolsas de trabajo más fluidas.

La implementación del método Kanban

Algunos profesionales han implementado Kanban en físico utilizando notas adhesivas, o tableros con ranuras.

Más a menudo la señal es generada por un software de seguimiento de trabajos especiales, tales como:5

Kanban Tool

JIRA Greenhopper

Cardmapping

Tablero Kanban online

Programación extrema(Redirigido desde «Programación Extrema»)

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de

software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained:

Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que

éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone

más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la 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.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de

acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de

vida del software.

Valores

Los valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación

(feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming

Explained. Los cinco valores se detallan a continuación:

Simplicidad

La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y

facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de

diferentes desarrolladores hacen que la complejidad aumente exponencialmente.

Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el

código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa

medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los

nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el

tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.

Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que

cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.

Comunicación

La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto

más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código

autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el

código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo

de una clase o la funcionalidad de un método.

Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos

al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican

constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el

cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre

debe estar disponible para solucionar dudas.

Retroalimentación (feedback

Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes

que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante.

Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la

borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El

código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las

pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente

permite descubrir fallos debidos a cambios recientes en el código.

Coraje o valentía

Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para

mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo

para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos

con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con

ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar

un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en

crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en

un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es

persistente.

Respeto

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los

programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el

trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta

calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la

refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros,

una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

Características fundamentales

Las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias  continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de

regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las

herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET

o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el

primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.

Programación en parejas : se recomienda que las tareas de desarrollo se lleven a cabo por dos

personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado

y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un

representante del cliente trabaje junto al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorización  del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad

y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la

refactorización no se ha introducido ningún fallo.

Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada

módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y

extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles

errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se

podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer

algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y

quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta

más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que

comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el

equipo de programadores.

Roles

Programador

Escribe las pruebas unitarias y produce el código del sistema.

Cliente

Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a

las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor

valor de negocio.

Tester

Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el

equipo y es responsable de las herramientas de soporte para pruebas.

Tracker

Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre

las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras

estimaciones.

Entrenador (coach)

Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.

Consultor

Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto.

Ayuda al equipo a resolver un problema específico.

Gestor (Big boss

Es el dueño del equipo y el vinculo entre clientes y programadores. Su labor esencial es la coordinación.

ScrumVéase también: medio scrum

Ciclos de desarrollo.

Metodología SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e

incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en

equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

Historia

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la

rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.1

Características de Scrum

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como

punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles

principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de

proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que

incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo

crea un incremento de software potencialmente entregable(utilizable). El conjunto de características que forma

parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que

definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan

durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos

del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo

determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente

sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están

congelados durante el sprint.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros

del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de

idea sobre lo que quieren y necesitan (a menudo llamadorequirements churn), y que los desafíos

impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum

adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o

definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a

requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas

amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es

muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Roles en Scrum

Roles Principales

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma

adecuada desde la perspectiva del negocio. El Product Owner escribehistorias de usuario, las

prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que

impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque

ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia

que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El

ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con

las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas,

documentación, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se

involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta.

Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los

usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente

participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y

planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio

acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Administradores (Managers)

Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum

Daily Scrum o Stand-up meeting[editar · editar código]

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se

llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:

La reunión comienza puntualmente a su hora.

Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del

tamaño del equipo.

La reunión debe ocurrir en la misma ubicación y a la misma hora todos los

días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:3

¿Qué has hecho desde ayer?

¿Qué es lo que harás hasta la reunión de mañana?

¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el

papel del ScrumMaster recordar estos impedimentos).

Scrum de Scrum[

Cada día normalmente después del “Daily Scrum”:

Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose

especialmente en áreas de solapamiento e integración.

Asiste una persona asignada por cada equipo.

La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes

cuatro preguntas:

¿Qué ha hecho tu equipo desde nuestra última reunión?

¿Qué hará tu equipo antes que nos volvamos a reunir?

¿Hay algo que demora o estorba a tu equipo?

¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint (Sprint Planning Meeting)[

Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se

lleva a cabo.

Seleccionar qué trabajo se hará

Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que

tomará hacer el trabajo.

Identificar y comunicar cuánto del trabajo es probable que se realice durante el

actual Sprint

Ocho horas como límite

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del

Sprint” y la “Retrospectiva del Sprint”

Reunión de Revisión del Sprint (Sprint Review Meeting

Revisar el trabajo que fue completado y no completado

Presentar el trabajo completado a los interesados (alias “demo”)

El trabajo incompleto no puede ser demostrado

Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retrospective

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los

miembros del equipo dejan sus impresiones sobre el sprint recién superado. El

propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión

tiene un tiempo fijo de cuatro horas.

Sprint[

El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que

la duración de los sprints sea constante y definida por el equipo con base en su propia

experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3

semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo

demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y

el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se

recomienda no agregar objetivos al sprint o sprint backlog a menos que la falta de estos

objetivos amenace al éxito del proyecto. La constancia permite la concentración y

mejora la productividad del equipo de trabajo.

Documentos

Product backlog

El product backlog es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requisitos, funcionalidades deseables, etc.

priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es

abierto y solo puede ser modificado por el product owner. Contiene estimaciones

realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de

desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea

temporal(KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo,

si dos características tienen el mismo valor de negocio la que requiera menor tiempo de

desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

Sprint backlog

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a

implementar los requisitos durante el siguiente sprint. Las tareas se dividen

en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de

16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca

son asignadas, son tomadas por los miembros del equipo del modo que les parezca

oportuno.

Burn down chart[

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de

requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando

una línea que conecte los puntos de todos los Sprints completados, podremos ver el

progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que

todo va bien en el sentido de que los requisitos están bien definidos desde el principio y

no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha

terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si

durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente

en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o

incluso valdrá cero en algunos tramos.

Scrum aplicado al desarrollo de software

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se

emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y

flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de

software.

Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel

Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en

VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1995 lo

presentó junto con Ken Schwaber como proceso formal, también para gestión del

desarrollo de software en OOPSLA 95. Más tarde, en 2001 serían dos de los

promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado

como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:

Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e

Interesados.

Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint

(Sprint Backlog), Incremento.

Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint.

Sprint