Metodología de James Martin y UML.

Metodología de James Martin

Robinson Gutiérrez

Jesús Salas

Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones,   y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.

Fases o Etapas de Metodología RAD de James Martin.

Esta metodología consta de 4 etapas a saber:

  1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución.

  2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.

  3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.

  4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.

Ventajas y Desventajas de la Metodología RAD

Ventajas             |             Desventajas

Ahorro dramático de tiempo durante el desarrollo del sistema.            Mayor velocidad y menores costos pueden repercutir en la calidad del sistema (p.e., debido a falta de atención en controles internos).

Puede ahorrarse tiempo, dinero y esfuerzo humano. Peligrosa incoherencia entre el sistema desarrollado y el negocio, debido a la falta de información o a procesos del negocio sobreentendidos.

Estrecha correspondencia entre los requerimientos del usuario y las especificaciones del sistema.

Pueden producirse inconsistencias entre diseños internos y entre sistemas.

Trabaja muy bien cuando la velocidad de desarrollo es importante (cambios rápidos de las condiciones del negocio), o cuando lo sistemas pueden capitalizarse en oportunidades estratégicas. Posibles violaciones de estándares de programación relacionadas con nomenclaturas inconsistentes e insuficiente documentación.

Permite cambiar rápidamente el diseño de los sistemas cuando los usuarios lo demandan Dificultades con el reuso de módulos para futuros sistemas.

Los sistemas son optimizados por los usuarios involucrados en el proceso del RAD. Carencia de un diseño escalable dentro del sistema.

Se concentra en los elementos esenciales del sistema, desde el punto de vista del usuario. Falta de atención de la futura administración del sistema dentro de los sistemas existentes (p.e., falta de integración con el modelo de datos organizacional y facilidades de recuperación del sistema)        . El usuario se compromete y se hace propietario del sistema. Altos costos de compromiso por parte del personal clave.

UML

Concepto:

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

Fases en el desarrollo basado en UML

En la versión definitiva de la metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta las siguientes fases o etapas:

· Análisis de Requerimientos

· Diseño del sistema

· Diseño detallado

· Implementación y pruebas

Cada etapa consta de actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.

Cuadro Estructural UMl

El lenguaje UML se expresa con símbolos y/o agrupaciones de estos llamadas diagramas. Nos sirve fundamentalmente para crear diferentes tipos de ellos permitiéndonos ver desde diferentes perspectivas un sistema software.

Existe un tipo primordial que es “Diagrama UML” del cual heredan “Diagrama Estructural” y “Diagrama Comportamiento”, de estos a su vez heredan los trece diferentes tipos de diagramas más comunes, existiendo un tipo intermedio que serían los “Diagrama de Interacción”.

Diagramas Utilizados en UML:

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

  * Diagrama de clases

  * Diagrama de componentes

  * Diagrama de objetos

  * Diagrama de estructura compuesta (UML 2.0)

  * Diagrama de despliegue

  * Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

  * Diagrama de actividades

  * Diagrama de casos de uso

  * Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

  * Diagrama de secuencia

  * Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x)

  * Diagrama de tiempos (UML 2.0)

  * Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)

Clases y Objetos.

Un objeto es una representación de una entidad, ya sea real o conceptual, con límites bien definidos y con significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su estado, su comportamiento y su identidad.

El estado de un objeto es una de las posibles condiciones bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y está definido por un conjunto de propiedades (atributos), por los valores de esas propiedades y por las relaciones que dicho objeto puede tener con otros objetos.

El comportamiento de un objeto determina la forma en que responde ante peticiones de otros objetos, y tipifica todo lo que el objeto puede hacer. El comportamiento de un objeto se materializa en el conjunto de operaciones definidas para dicho objeto.

La identidad implica que cada objeto es único, incluso si su estado es idéntico al de otro objeto.

En UML una clase es una descripción de un grupo de objetos con propiedades comunes (atributos), comportamiento común (operaciones), relaciones comunes y semántica común. Por tanto, una clase es una plantilla (template) para la creación de objetos, donde cada objeto de dicha clase será una instancia de ella (no pudiendo ser instancia de más de una clase).

Antes de describir los distintos elementos que forman parte de un diagrama de clases, es importante aclarar la forma en que dichos diagramas pueden ser utilizados durante el proceso software. A la hora de confeccionar o interpretar un diagrama de clases pueden considerarse tres perspectivas:

Conceptual: Permite representar los conceptos del dominio. Aunque dichos conceptos suelen llevar, de una forma natural, a las clases que los implementan, puede que no exista una correspondencia directa.

Especificación: Cuando se trata de representar las interfaces del software y no el software en sí.

Implementación: Es en esta perspectiva donde realmente tenemos clases, siendo ésta la perspectiva más utilizada.

Un diagrama de clases UML puede ser utilizado desde cualquiera de estas perspectivas, resulta en este caso conveniente el indicar la perspectiva de la que se trata por medio de estereotipos.

Diagrama de clases.

Los diagramas de clases son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido. El diagrama de clases de más alto nivel (main class diagram), será lógicamente un dibujo de los paquetes que componen el sistema. A su vez cada paquete tendrá un main class diagram que muestra las clases del paquete Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, su cardinalidad (cuantos objetos intervienen en la relación) y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación). La descripción de clases complejas se puede documentar con diagramas de estados.

Metodologia para desarrollo de sofware:

 Metodología XP programación extrema:

La programación extrema XP es posiblemente el método  más conocido y ampliamente utilizado. El nombre de XP fue acuñado por Beck (2000), debido a que el enfoque fue desarrollado utilizando las mejores prácticas del desarrollo iterativo y con la participación extrema del cliente. La programación extrema (XP), que algunos consideran una innovación extraordinaria y otros creen cínica (Rakitin, 2001). En la metodología extrema, todos los requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se implementan directamente como una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integra al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema.

El desarrollo incremental se lleva a través de entregas pequeñas y frecuentes del sistema y por medio de un enfoque que sirve para la descripción de requerimientos basado en las historias del clientes o escenarios que pueden ser la base para el proceso de planificación.

La participación del cliente se lleva a cabo a través del compromiso y del tiempo completo del cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan en el desarrollo y son los responsables de definir las pruebas necesarias que servirán para la aceptación del sistema. El interés de las personas, en vez de los procesos, se lleva a través de la programación en parejas, la propiedad colectiva del código y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua. El mantenimiento se lleva a cabo a través de una recta actualización constante para mejorar la calidad del código y la utilización de diseños sencillos que no prevén cambios futuros en el sistema.

En XP, los clientes están implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema. Dichos requerimientos no se especifica como una lista de funciones requeridas en el sistema. Más bien, los clientes del sistema son parte fundamental del equipo de desarrollo esto permite que discutan escenarios con todos los miembros del equipo. Desarrollar conjuntamente tarjetas de historia (story card) que recogen las necesidades del cliente. Por ende el equipo de desarrollo intentará implementar esos escenarios en una entrega futura del software. Un punto fundamental en la ingeniería del soporte tradicional es que se debe de diseñar para futuros. Esto es que se deben de prever los cambios futuros y diseñar éste de forma que tales cambios se puedan implementar fácilmente. La metodología XP ha descartado este principio partiendo del hecho de que diseñar para el cambio es a menudo un esfuerzo inútil. Con frecuencia los cambios previstos nunca se materializa y realmente se efectúan peticiones de cambios completamente diferentes. La metodología extrema aborda este problema sugiriendo que se debe revisar constantemente el software. Esto es, que el equipo de programación busca posibles mejoras y las implementa de forma inmediata así lo que se busca es que siempre sea fácil de entender y cambiar cuando simplemente nuevas historias.

                                   Desarrollo adaptativo de software (DAS):

El desarrollo adaptativo software (DAS) lo propuso Jim Highsmith en 1998 como una técnica para construir software y sistemas complejos. Los apoyos filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo. Un enfoque de desarrollo ágil y adaptativo basado en la colaboración es " una fuente de orden en las complejas interacciones entre disciplina e ingeniería". El define el ciclo de vida del DAS, como se muestra en la figura 2.29 el cual incorpora tres fases principales:

1) Especulación; en esta fase se inicia el proyecto y se conduce el ciclo adaptativo de planeación. Este último utiliza información de inicio del proyecto, es decir, el enunciado de la misión del cliente, restricciones del proyecto y los requisitos básicos. Esto permite definir el conjunto de ciclos de lanzamiento que se requerirán para el proyecto.

2) Colaboración; la gente motivada trabaja de una forma que multiplica su talento y sus salidas creativas más allá de sus números absolutos. Este enfoque de colaboración es un tema recurrente en todos los métodos ágiles, pero la cooperación no es fácil. No solamente es la comunicación, o que la comunicación es parte de ella. No sólo es un asunto de trabajo en equipo, aunque un equipo cuajado es esencial para la presencia de la colaboración real. No es un rechazo al individualismo ya que la creatividad individual representa un papel importante en el pensamiento de colaboración. Esto es, por encima de todo, una cuestión de confianza. Las personas que trabajan juntas deben confiar entre sí para:

a) Criticar de forma constructiva

b) Ayudar sin resentimientos

c) Trabajar más duro de lo que ya lo hace

d) Tener el conjunto de actitudes para contribuir al trabajo curso

e) Comunicar los problemas o preocupaciones en una forma que conduzca a la acción efectiva

3) Aprendizaje; como miembros de un equipo de DAS se comienzan a desarrollar los componentes integrantes de un ciclo adaptativo, la importancia radica en el aprendizaje y en el progreso a través de un ciclo completo. De hecho Highsmith (2002), argumenta que los desarrolladores de software a menudo sobreestima su comprensión (de la tecnología, el proceso y el proyecto), y que el aprendizaje les podré ayudar a mejorar su grado de entendimiento real. Los equipos del DAS aprenden de tres maneras:

a) Grupos enfocados. El cliente o los usuarios finales proporcionan retroalimentación sobre los incrementos de software que se entregan. Esto indica en forma directa la satisfacción o la insatisfacción de las necesidades del negocio.

b) Revisiones técnicas formales. Los miembros del equipo del DAS revisan los componentes del software desarrollado mientras mejoran su calidad y su aprendizaje.

c) Post mortem. El equipo de DAS se vuelve introspectivo al vigilar su propio desempeño y proceso con el propósito de aprender acerca de su enfoque y después mejorarlo.

Es importante destacar que la filosofía del DAS es meritoria sin importar el modelo del proceso empleado. La dinámica de la organización propia los equipos, la colaboración interpersonal y el aprendizaje individual conducen a los grupos de proyectos de software con una mayor posibilidad de éxito.                                                                  darling arias y wolfang arroyo 

Metodología Scrum

Dulce Mendoza

Bryan Rivero

En el año de 1986 Takeuchi y Nonaka publicaron el artículo “ The New Product Developroent Game” el cual dará a conocer una nueva forma de gestionar proyectos en la que la agilidad, flexibilidad, y la incertidumbre son los elementos principales.

Nonaka y Takeuchi se fijaron en empresas tecnológicas que, estando en el mismo entorno en el que se encontrabas otras empresas, realizaban productos en menos tiempo, de buena calidad y menos costes.

Observando a empresas como Honda, HP, Canon…etc, Se dieron cuenta de que el producto o seguía unas pases en las que había un equipo especializado en cada una de ellas, si no que se partía de unos requisitos muy generales y el producto lo realizaba un equipo multisciplinar que trabajaba desde el comienzo del proyecto hasta el final.

Se comparó esta forma de trabajo en equipo, con la colaboración que se hacen los jugadores de rugby y la utilización de una formación denominada SCRUM.

Scrum aparece como una práctica destinada a los productos tecnológicos y será en 1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de Software en Ease/Corporation.

En 1996, Jeff Surtherland y Ken Schwaber presentaron las prácticas que se usaban como proceso formal para el desarrollo de software y que pasarían a incluirse en la lista de Agile Alliance.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los productos se realiza entornos que se caracterizan por tener:

1.      Incertidumbre: Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar un plan detallado del producto.

Esto genera un reto y da la autonomía que sirve para generar un “tensión” adecuada para la motivación de los equipos.

2.      Auto-organización: Los equipos son capaces de organizarse por si solos, no necesitan roles para la gestión pero tienen que reunir las siguientes características:

·         Autonomía: Son los encargados de encontrar la solución usando la estrategia que encuentren adecuada.

·         Autosuperación: Las soluciones iniciales sufrirán mejoras.

·         Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos de forma mutua, aportando soluciones que pueden complementarse.

3.      Control moderado: Se establecera un control suficiente para evitar descontroles. Se basa en crear un escenario de “autocontrol entre iguales” para no impedir la creatividad y espontaneidad de los miembros del equipo.

4.      Transmisión del conocimiento: Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos a otros así comparten sus conocimientos a lo largo de la organización.

Scrum al ser una metodología de desarrollo ágil tiene como base la idea de creación de ciclos breves para el desarrollo, que comúnmente se llama iteraciones y que en Scrum se llamaran “Sprints”, Su ciclo tiene 5 fases que definen el ciclo:

1.      Concepto: Se define de forma general las características del producto y se asigna el equipo que se encargara de su desarrollo.

2.      Especulación: En esta fase se hacen disposiciones con la información obtenida y se establecen los límites que marcaran el desarrollo del producto, yales como costes y agendas.

3.      Exploración: Se incrementa el producto en el que se añaden las funcionalidades de la pase de especulación.

4.      Revisión: El equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado.

5.   
Cierre: Se entregara en la fecha acordada un versión del producto deseado. Al tratarse de una versión, el cierro no indica que se ha finalizado el proyecto sino que seguirá habiendo cambios, denominados “mantenimientos”, que hará que el producto final se acerque al producto final deseado.

Scrum gestiona estas iteraciones a través de reuniones diarias, uno de los elementos fundamentales de esta metodología

Componentes de Scrum.

Para entender todo lo que el proceso de desarrollo del Scrum, se describirá de forma general las fases y roles. Estas fases y roles se detallaran de forma más concisa mas adelante.

Scrum se puede dividir de forma general en 3 fases, que podemos entender como reuniones. Las reuniones forman parte de los artefactos de esta metodología junto con los roles y elementos que lo forman.

Las Reuniones.

1.      Planificación del Backlog: Se definirá un documento en el que se reflejaran los requisitos del sistema por prioridades.

En esta fase se definirá también la planificación del Sprint 0, en la que se decidirá cuáles van a ser los objetivos y el trabajo que hay que realizar para esa iteración.

Se obtendrá además en esta reunión un Sprint Backlog, que es la lista de tareas y que es el objetivo más importante del Sprint.

2.      Seguimiento del Sprint: En esta fase se hacen las reuniones diarias en las que las 3 preguntas principales para evaluar el avance de las tareas serán:

·         ¿Qué trabajo se realizó desde la reunión anterior?

·         ¿Qué trabajo se hará hasta la nueva reunión?

·    Inconvenientes que han surgido y que hay que solucionar para poder continuar.

3.      Revisión del Sprint: Cuando se finaliza el Sprint se realizara una revisión del incremento que se ha generado. Se presentara los resultados finales y una demo i versión, esto ayudara a mejorar el feedback con el cliente.

Los Roles.

Los roles se dividen en 2 grupos: Cerdos y Gallinas, esto surge en el chiste sobre un cerdo y una gallina y su intención de poner un restaurante.

1.     Los Cerdos:

Son las personas que están comprometidas con el proyecto y el proceso de Scrum.

·         Producto Owner: Es la persona que toma las decisiones, y es la que realmente conoce el negocio del cliente y su visión del producto. Se encarga de escribir las ideas del cliente, las ordena por prioridad y las coloca en el Product Blaclog.

·         ScrumMaster: Es el encargado de comprobar que el modelo y la metodología funciona. Eliminará todos los inconvenientes que hagan que el producto no fluya e interactuara con el cliente y con los gestores

·         Equipo De Desarrollo: Suele ser un equipo pequeño de unas 5-9 personas y tienen autoridad para organizar y tomar decisiones para conseguir su objetivo. Está involucrado en la estimación del esfuerzo de las tareas del blacklog.

2.     Las Gallinas:

Aunque no son partes del proceso Scrum, es necesario que parte de la retroalimentación de la salida del proceso y así poner revisar y planear cada Sprint.

·         Usuarios: Es el destinatario final del producto.

·         Stakeholders: Las personas al as que el proyecto les producirá un beneficio. Participan durante las revisiones del Sprint.

·         Managers: Toma decisiones finales participando en la selección de los objetivos y de los requisitos.

Elementos de Scrum.

Los elementos que forman Scrum son:

·         Product Blacklog: Lista de necesidades del cliente.

·         Sprint Backlog: Lista de tareas que se realizan en un Sprint.

·         Incremento: Parte añadida o desarrollada en un Sprint, es una parte terminada y totalmente operativa.

Product Blacklog.

Es el inventario en el que se almacenan todas las funcionalidades o requisitos en forma de lista priorizada. Estos requisitos serán los que tendrán el producto o los que ira adquiriendo en sucesivas iteraciones.

La lista será gestionada y creada por el cliente con ayuda del Scrum Master, quien indicara el coste estimado para completar un requisito, y además contendrá todo lo que aporte un valor final al producto.

Es necesario que antes de empezar el Sprint se definan cuales van a ser los objetivos del producto y tener una lista de requisitos ya definida. No es necesario que sea muy detallada, simplemente deberá contener los requisitos principales para que el equipo pueda trabajar.

 Una vez definidos los requisitos se tendrá que acordar cuando se tiene que entender un objetivo como terminado o completado.

Como complemento a la definición  de completado, se deberá asociar una condición de aceptación o no aceptación a cada objetivo en el mismo momento en el que se crea la lista.

Finalmente el Product Blacklog ira evolucionando mientras el producto exista en el mercado. Esta es la forma para evolucionar y tener un valor del producto para el cliente suficiente para ser competitivo.

Las Historias de Usuario.

Son las descripciones de las funcionalidades que va a tener el software.

Estas Historias de usuarios, serán el resultado de la colaboración entre el cliente y el equipo, e iran evolucionando durante toda la vida del proyecto.

Las historias de usuario se componen de tres fases denominadas “Las 3 C”:

·         Card: Sera una breve descripción escrita que servirá como recordatorio.

·         Conversation: Es una conversación que servirá para asegurar de que se ha entendido bien todo, y concretar el objetivo.

·         Confirmation: Tests funcionales para finar detalles que sean relevantes e indicar cuál va a ser el límite.

Formato de la Pila Del Producto (Product Blacklog).

En Scrum, la preferencia por tener documentación en todo momento es menos estricta. Se encuentra mas necesario el matener una comunicación directa con el equipo, por eso se usa como herramienta el Backlog.

Aunque no hay ningún producto especial al a hora de confeccionar la lista, es conveniente que incluya información relativa a:

·         Identificador para la funcionalidad.

·         Descripción de la funcionalidad.

·         Sistema de priorización u orden.

·         Estimación.

Sprint Backlog.

En esta lista de tareas que elabora el equipo durante la planificación de un Sprint. Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.

De esta manera el proyecto se descompone en unidades más pequeñas y se puede determinar o ver en que tarea no se está avanzando e intentar eliminar el problema.

Cómo funciona la lista:

·         Es una lista ordenada por prioridades para el cliente.

·         Puede haber dependencias entre tareas y ora, por lo tanto se tendrán que diferenciar de alguna manera.

·         Todas las tareas tienen que tener un coste semejante que será entre 4-16 horas.

Formato de la lista:

Hay 3 opciones:

·         Hojas de cálculo.

·         Pizarras.

·         Herramientas colaborativas.

Incremento.

Representa los requisitos que se han completado en una iteración y que son perfectamente operativos.

Según los resultados que se obtengan, el cliente puede ir haciendo los cambios necesarios y replanteando el proyecto.

METODOLOGÍA DE HALL

Nieves Lucena

Yelsy Rodriguez 

   I. INTRODUCCIÓN

Uno de los campos en donde con más intensidad se ha sentido la necesidad de utilizar conceptos y metodologías de ingeniería de sistemas en el desarrollo de tecnología. Esto se debe a que los sistemas técnicos, que sirven para satisfacer ciertas necesidades de los hombres, están compuestos de elementos interconectados entre sí de tal forma que se hace necesario pensar en términos de sistemas, tanto para el desarrollo de nueva tecnología como para el análisis de la ya existente.

II. METODOLOGÍA

Los pasos principales de la metodología de hall son:

·         Definición del Problema

·         Selección de Objetivos

·         Síntesis de Sistemas

·         Análisis de Sistemas

·         Selección del Sistema

·         Desarrollo del Sistemas

·         Ingeniería

1.    DEFINICIÓN DEL PROBLEMA.

Se busca transformar una situación confusa e indeterminada, reconocida como problemática y por lo tanto indeseable, en un estatuto en donde se trate de definirla claramente. Esto sirve para:

a)    Establecer objetivos preliminares.

b)     El análisis de distintos sistemas.

De la definición del problema los demás pasos de la metodología dependen de como haya sido concebido y definido el problema. Si la definición del problema es distinta lo que realmente es, lo más probable es que todo lo que se derive del estudio vaya a tener un impacto muy pobre en solucionar la verdadera situación  problemática.

La definición  del problema demanda tanta creatividad como el proponer soluciones. El número de posibles soluciones aumenta conforme el problema es definido en términos más amplios y que disminuyen al aumentar el número de palabras que denotan restricciones dentro de la restricción.

Existen dos formas en como nacen los problemas que son resueltos con sistemas técnicos.

a)    La búsqueda en el medio ambiente de nuevas ideas, teorías, métodos, y materiales, para luego buscar formas de utilizarlos en la organización.

b)    Estudiar la organización actual y sus operaciones para detectar y definir necesidades.

Estas dos actividades están estrechamente relacionadas y se complementan una a otra.

            INVESTIGACION DE NECESIDADES

Las necesidades caen dentro de tres categorías.

a)    Incrementar la función de un sistema. Hacer que un sistema realice más funciones de las actuales.

b)    Incrementar el nivel de desempeño. Hacer que un sistema sea más confiable. Más fácil de operar y mantener, capaz de adaptarse a niveles estándares más altos.

c)    Disminuir costos, hacer que un sistema sea más eficiente.

INVESTIGACION DEL MEDIO AMBIENTE

Se trata de entender y describir el medio ambiente en donde se encuentra la organización, “entre otras cosas, se realiza un peinado del medio ambiente en búsqueda de nuevas ideas, métodos, materiales y tecnologías que puedan ser utilizadas en la satisfacción de necesidades”. De este último se desprende  que el criterio para decidir si algo que existe en el medio ambiente es útil para la organización está en función de las necesidades de esta última.

2.    SELECCIÓN DE OBJETIVOS.

Se establece tanto lo que esperamos del sistema como los criterios bajo los cuales mediremos su comportamiento y comparemos la efectividad de diferentes sistemas.

Primero se establece que es lo que esperamos obtener del sistema, así como insumos y productos y las necesidades que este pretenda satisfacer.

Ya que un sistema técnico se encuentra dentro de un supra-sistema que tiene propósitos, aquel debe ser evaluado en función de este. No es suficiente que el sistema ayude a satisfacer ciertas necesidades. Se debe escoger un sistema de valores relacionados con los propósitos de la organización, mediante el cual se pueda seleccionar un sistema entre varios y optimizarlo. Los valores más comunes son: utilidad (dinero), mercado, costo, calidad, desempeño, compatibilidad, flexibilidad o adaptabilidad, simplicidad, seguridad y tiempo.

Los objetivos deben ser operados hasta que sea claro como distintos resultados pueden ser ocasionados a ellos para seleccionar y optimizar un sistema técnico.

Cuando un sistema tiene varios objetivos que deben satisfacerse simultáneamente, es necesario definir la importancia relativa de cada uno de ellos. Si cada objetivo debe cumplirse bajo una serie de valores a estos también se debe asignarse un peso relativo que nos permita cambiarlos en el objetivo englobador.

3.    SINTESIS DEL SISTEMA.

Lo primero que se debe hacer es buscar todas las alternativas conocidas a través de las fuentes de información de nuestro alcance. Si el problema ha sido definido ampliamente, el número de alternativas va hacer bastante grande. De aquí se debe obtener ideas para desarrollar distintos sistemas que pueden ayudarnos a satisfacer nuestras necesidades. Una vez hecho esto, se procede a diseñar(ingeniar)distintos sistemas.

            En esta parte no se pretende que el diseño sea muy detallado. Sin embargo, debe de estar lo suficientemente detallado de tal forma que los distintos sistemas puedan ser evaluados.

3.1 DISEÑO FUNCIONAL

El primer paso es listar los insumos y productos del sistema. Una vez hecho esto, se listan las funciones que se tiene que realizar para que dados ciertos insumos se obtengan ciertos productos. Estas funciones se realizan o sintetizan mostrando en un modelo esquemático de las actividades y como estas se relacionan. Todo lo que desea en este punto es ingeniar un sistema que trabaje, la optimización del mismo no importa tanto en este punto.
4.    ANÁLISIS DE SISTEMA

La función de análisis es deducir  todas las consecuencias relevantes de los distintos sistemas para seleccionar el mejor. La información que se obtiene en esta etapa se retroalimenta a las funciones de selección de objetivos y síntesis de sistema. Los sistemas se analizaran en función de los objetivos que se tengan.

4.1 COMPARACIÓN DE SISTEMAS

Una vez que todos los sistemas han sido analizados y sintetizados, el paso siguiente es obtener las discrepancias y similitudes que existen entre cada uno de ellos. Existen dos tipos de comparación:

a)    Comparar el comportamiento de dos sistemas con respecto a un mismo objetivo.

b)    Comparar dos objetivos de un mismo sistema.

Antes que se lleve a cabo la comparación entre distintos sistemas, estos deben ser optimizados, deben estar diseñados de tal forma que se operen lo más eficientemente  posible. No se pueden comparar dos sistemas si aún no han sido optimizados.

5. SELECCIÓN DEL SISTEMA

 Cuando el comportamiento de un sistema de puede predecir con certidumbre y solamente tenemos un solo valor dentro de nuestra función objetivo, el procedimiento de selección del sistema es bastante simple. Todo lo que se tiene que hacer es seleccionar el criterio de selección. Cuando el comportamiento del sistema no se puede predecir con certidumbre y se tienen distintos valores en función de los cuales se va a evaluar el sistema, no existe un procedimiento general mediante el cual se puede hacer la selección del sistema

6. DESARROLLO DEL SISTEMA

El desarrollo del sistema es un sistema sigue básicamente el ciclo que se muestra en la siguiente figura:

En base al diseño que se había hecho el sistema durante la fase de síntesis del sistema, se hace un diseño detallado del mismo, para esto, se puede utilizar la técnica del síntesis funcional, mencionado anteriormente. Una vez que el sistema está en papel, hay que darle vida, desarrollarlo. El número de personas que toman parte en esta operación depende de la magnitud del sistema. Por ejemplo, el production control sistem (PSC) desarrollado por la borroughs tiene invertido alrededor de 50 años-hombres.

Lógicamente, no se puede poner en operación un sistema una vez que haya sido construido. Se tienen que hacer pruebas para deslumbrar problemas no previstos en su funcionamiento. En caso que no funcione como debiese, se debe investigar las razones y tomar acciones correctivas. Estas caen dentro de dos categorías:

a)    Falla de diseño.

b)    Fallas de la construcción.

En el primer caso, debe reportarse que fallas tienen el diseño del sistema para proceder a hacer los cambios. En el segundo caso, debe reportarse que es lo que se construyó mal para proceder a corregirlo.

Una vez que el sistema funcione como se pretendía, y antes que se ponga en operación, deben de desarrollarse documentos de que contengan información sobre su operación, instalación y mantenimientos, entre otros.

7.  INGENIERIA

En esta etapa no consiste en un conjunto de pasos más o menos secuenciales como en otras partes del proceso. Consiste en varios trabajos los cuales pueden ser calificados de la siguiente forma:

a)    Vigilar la operación del nuevo sistema para mejoras en diseños futuros.

b)    Corregir fallas en el diseño,

c)    Adaptar el sistema a cambios del medio ambiente.
d)    Asistencia al cliente.

Esta etapa dura mientas el sistema está en operación.

Metodología Espiral

Yeferson Cardenas

Elieth Picon

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

PROCESO DE DESARROLLO DE SOFTWARE 

El desarrollo de un software en sí es complejo, es usualmente no viable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una gran combinación de factores que imposibilitan realizar una verificación minuciosa de todas las posibles situaciones de ejecución que se puedan presentar. Poniendo como ejemplo la creación de un sistema operativo, esto es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. 

Un desarrollo de software es imperceptible y por lo general muy abstracto, esto pone trabas en la definición del producto y sus requisitos, más que nada cuando no se tiene precedentes definidos de un desarrollo de software similar. Esta situación va hacer que los requisitos sean difíciles de consolidar con anterioridad. Es por esto que ahora los cambios en los requisitos son inevitables, no sólo después de entregado el producto sino también durante el proceso de desarrollo. Sea cual fuere el proceso utilizado y aplicado al desarrollo del software, casi siempre libremente de este proceso, se debe aplicar un modelo de ciclo de vida. Según varias fuentes consultadas se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un proyecto de desarrollo de software “fracasa” (28% estadísticamente), muy rara vez es causado por fallas técnicas, principalmente el origen de los fallos y fracasos es la falta de aplicación de una buena metodología o procesos de desarrollo. Una fuerte tendencia, desde hace pocos años, es mejorar las metodologías y procesos, o crear nuevas e incentivar a los profesionales de la informática en su aplicación adecuada, normalmente utilizan sus conocimientos especializados con modelos, paradigmas y procesos obsoletos que ya fueron diseñados.

MODELO ESPIRAL 

El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales:

 1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos. 

2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas. 

3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.

 4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional. 

La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de software. Por ejemplo, si queremos utilizar un lenguaje de programación para desarrollar un sistema operativo, un riesgo posible es que los compiladores utilizables no produzcan un código objeto eficiente. Los riesgos originan problemas en el proyecto, como el exceso de los costos. Es así que, la disminución de los riesgos es una actividad muy importante. 

Un modelo espiral comienza con la determinación de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. Luego continuamos con el siguiente paso que es resolver estos riesgos y llevar a cabo las actividades de desarrollo, para finalizar con la planificación del siguiente ciclo de la espiral.

Ventajas

• Reduce riesgos del proyecto

• Incorpora objetivos de calidad

• Integra el desarrollo con el mantenimiento.

Desventajas

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

ACOPLAMIENTOS DEL MODELO ESPIRAL

 Los nuevos requerimientos del sistema se definen en todo los detalles posibles, esto implica generalmente el entrevistarse con un número determinado de usuarios que representarán a todos los usuarios tanto externos como internos y otros aspectos del sistema existente. 

Un prototipo preliminar se crea para el desarrollo del nuevo software partiendo de un diseño hecho del sistema que se construyó del prototipo inicial. Esto es generalmente un sistema scaled-down, y representa una aproximación de las características del producto final. 

Un segundo diseño de software es desarrollado por un procedimiento cuádruple:

Evaluación del primer prototipo en términos de sus fuerzas, debilidades, y riesgos; 

·         Definir los requisitos del segundo prototipo; 

·         Planeando y desarrollando el segundo prototipo;

·         Construyendo y probando el segundo prototipo. 

En la opción del cliente, el proyecto completado puede ser abortado si el riesgo se juzga demasiado grande. Los factores de riesgo pudieron implicar los excesos de coste del desarrollo, cálculo erróneo del fusionar los costes, o cualquier otro factor que podría, en el juicio del cliente, dar lugar a un producto final menos que satisfactorio. 

El diseño existente se evalúa de manera semejante al igual que el diseño anterior, y, en caso de necesidad, otro prototipo se desarrolla de él según el procedimiento cuádruple expuesto anteriormente. Se iteran los pasos precedentes hasta que el cliente está satisfecho sabiendo que el diseño mejorado representa el producto final deseado. Además, se construye el sistema final, basado en el diseño mejorado. El sistema final se evalúa y se prueba con todas las de ley. El mantenimiento general se realiza sobre una base continua para prevenir fallas en grande y para reducir al mínimo el tiempo perdido.