TGS: COMPONENTES EN COMÚN CON SISTEMAS AUTOMATIZADOS Y SISTEMAS EN LÍNEA, SISTEMAS DE TIEMPO

REAL, SISTEMAS DE APOYO A DECISIONES O SISTEMAS BASADOS EN EL CONOCIMIENTO

TEORÍA GENERAL DE SISTEMAS: Las definiciones que se dan sobre sistemas son

numerosas. La mayoría de ellas vienen a coincidir, o se pueden resumir, en la dada por el

iniciador de la Teoría General de Sistemas (T.G.S.) en su vertiente actual, Bertalanfy: “un

conjunto de elementos que deben estar fundamentalmente en interacción”.

Se puede decir que la T.G.S. tiene como misión fundamental formular de la forma más

precisa posible el diseño de los sistemas, y mantenerlos en estado óptimo de actividad.

Todo sistema admite un diseño hacia la consecución de un objetivo, en este sentido

Churchman define el sistema como: “un conjunto de partes coordinadas con vistas a

alcanzar un conjunto de objetivos”. El análisis del sistema es el estudio de los sistemas. Su

propósito puede ser diseñar uno nuevo, o mejorar el existente.

Dentro de la T.G.S. existen algunos principios “generales” que son de interés particular

para quienes crean sistemas automatizados de información e incluyen los siguientes:

1. Cuanto más especializado sea el sistema, menos capaz es de adaptarse a

circunstancias diferentes: Entre más general sea un sistema, menos óptimo será para una

situación determinada; pero entre más óptimo sea, para tal situación menos adaptable será

a nuevas circunstancias.

2. Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse

en sistemas menores: Este punto es importante porque sugiere organizar el sistema

computacional por el procedimiento de dividirlo en sistemas menores.

En el ordenador lo consideramos:

3. Los sistemas crecen: Un sistema de información típico, por ejemplo, crecerá hasta

el punto de incluir más SW, más datos, más funciones y más usuarios que los que

inicialmente habíamos planificado.

Subsistema de E/S

Subsistema central

Subsistema de comunicaciones

Para que un sistema tenga éxito, debe conocer a los demás sistemas con los que va a

interactuar.

Tipos de sistemas:

NATURALES

HECHOS POR

EL HOMBRE

En la actualidad casi todos los Sistemas hechos por el hombre incluyen entre sus

elementos al ordenador y de hecho la gran mayoría de estos sistemas no podrían existir sin

ellos.

SISTEMAS AUTOMATIZADOS: Los sistemas automatizados, son sistemas hechos por

el hombre que interactúan con o son controlados por uno o más ordenadores.

Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener

componentes en común:

1. El HW del ordenador: los procesadores, los discos, terminales, impresoras,

unidades de cinta magnética, etc.

2. El SW del ordenador: los programas de sistemas tales como sistemas operativos,

sistemas de bases de datos, programas de control de telecomunicaciones, además de los

programas de aplicación que llevan a cabo las funciones deseadas por el usuario.

3. Las personas: los que operan el sistema, los que proveen su material de entrada y

utilizan su material de salida, y los que proveen actividades de procesamiento manual en un

sistema.

4. Los datos: la información que el sistema maneja durante un período de tiempo.

5. Los procedimientos: las políticas formales e instrucciones de operación del sistema.

Una manera de ordenar por categorías los sistemas automatizados es por su aplicación:

sistemas de manufactura, sistemas de contabilidad, sistemas de defensa, etc.

Una división por categorías más útil de los sistemas automatizados es la siguiente:

• Sistemas en línea: Acepta material de entrada directamente del área donde se creó

y el material de salida se devuelve directamente a donde es requerido. Los usuarios del

sistema computacional normalmente interactúan con el ordenador desde terminales.

Físicos (galaxias, ríos, cordilleras) Vivientes (raza humana, animales, plantas)

(Sistema financiero, de comunicaciones, sistema de información, etc.)

Sistemas

• Sistemas de tiempo real: En los sistemas de tiempo real, el ordenador debe de

reaccionar en milisegundos y a veces en microsegundos a los estímulos que recibe.

• Sistemas de apoyo a decisiones: Ayudan a los administradores de una organización a

tomar decisiones inteligentes y documentadas.

• Sistemas basados en el conocimiento: Contienen grandes cantidades de diversos

conocimientos que emplean en el desempeño de una determinada tarea.

SISTEMAS EN LÍNEA: Un sistema en línea es aquel que acepta material de entrada

directamente del área donde se creó. También es el sistema en el que el material de salida,

o resultado de la computación, se devuelve directamente a donde es requerido.

Una característica común de los sistemas en línea es que entran datos al ordenador o se

les recibe de forma remota. Es decir, los usuarios del sistema computacional normalmente

interactúan con el ordenador desde terminales.

La información se teclea

desde el lugar de origen

La salida se transmite

a donde es requerida

UN SISTEMA EN LÍNEA

SISTEMAS DE TIEMPO REAL: Un sistema computacional de tiempo real puede

definirse como aquel que controla un ambiente recibiendo datos, procesándolos y

devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese

Procesador

Los datos se organizan de modo que se puedan recobrar fácilmente

Estímulo

Respuesta

momento. En la mayoría de los sistemas de tiempo real, el ordenador debe de reaccionar en

milisegundos y a veces en microsegundos a los estímulos que recibe.

Paso del tiempo

UN SISTEMA DE TIEMPO REAL

Dada la preocupación por la respuesta instantánea a las entradas del sistema, un analista

que trabaja en sistemas de tiempo real generalmente estará muy atento con el

comportamiento dependiente del tiempo que el sistema tenga.

SISTEMAS DE APOYO A DECISIONES: Estos sistemas no toman decisiones por sí

mismos, sino que ayudan a los administradores y a otros profesionales de una organización a

tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de cualquier

operación. Una característica común es que no sólo recuperan y muestran los datos, sino

que también realizan varios tipos de análisis matemáticos y estadísticos de los mismos.

También tienen la capacidad, en la mayoría de los casos, de presentar la información en una

variedad de formas gráficas (tablas, gráficos, etc.) al igual que en forma de “reportes”

(informes) convencionales.

SISTEMAS BASADOS EN EL CONOCIMIENTO: Los sistemas basados en el

conocimiento, contienen grandes cantidades de diversos conocimientos que emplean en el

desempeño de una determinada tarea. Los sistemas expertos son una especie de sistema

basado en el conocimiento, aunque ambos términos a menudo se utilizan indistintamente.

Un sistema experto es un programa de ordenador que contiene el conocimiento y la

capacidad necesarios para desenvolverse a nivel de experto.

Se prevé un momento en el futuro cercano en el cual los sistemas de IA y los SS.EE.

formarán parte de la actividad “normal” del análisis de sistemas.

SISTEMA DE TIEMPO REAL

Ambiente

RELACIÓN ERAS – GENERACIONES

HW – GENERACIONES SW – ERAS

1ª GENERACIÓN:

Válvulas de vacío

2ª GENERACIÓN:

Transistor

1ª ERA: Década

Distribución limitada 50 - 60

SW a medida

3ª GENERACIÓN:

Circuito integrado

2ª ERA: Década

Sistema Multiusuario 60 – 70

Sistema de tiempo real

Bases de datos

SW como producto

4ª GENERACIÓN:

Circuito integrado + Microprocesador

3ª ERA: Década

Sistema distribuido 70 – actual

SW de bajo coste

Impacto en el consumo

5ª GENERACIÓN:

Circuitos Ultragrande

Escala de Integración (ULSI)

4ª ERA: Década

Sistemas expertos Comenzando

Sistemas potentes de sobremesa

Tecnología orientada a objetos

Redes neuronales

Computación paralela

FASES Y ACTIVIDADES DEL CICLO GENÉRICO

La creación de cualquier sistema SW implica la realización de tres pasos genéricos:

definición, desarrollo y mantenimiento. Estos pasos (fases) los encontramos siempre

independientemente del tamaño, complejidad y área de aplicación del proyecto elegido.

La fase de definición se centra sobre el qué: Se intenta caracterizar el sistema que

se ha de construir. Por tanto, han de identificarse los requisitos clave del sistema y del

SW. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del

paradigma, o combinación de paradigmas, de ingeniería del SW aplicado (Ciclo de vida

clásico, Ciclo de vida de prototipos, Modelo en espiral y Técnicas de cuarta y quinta

generación), de alguna forma se producirán tres pasos específicos:

• Análisis del sistema: El análisis del sistema define el papel de cada elemento de un

sistema informático, asignando finalmente al SW el papel que va a desempeñar.

• Planificación del proyecto de software: Una vez establecido el ámbito del SW se

definen las tareas y se planifica el trabajo.

• Análisis de requisitos: El ámbito establecido para el SW proporciona la dirección a

seguir, pero antes de comenzar a trabajar es necesario disponer de una información más

detallada del ámbito de información y de función del SW.

La fase de desarrollo se centra en el cómo: Se diseña la arquitectura del SW y las

estructuras de los datos y de los programas. Se producirán tres pasos concretos:

• Diseño del SW: Traduce los requisitos del SW a un conjunto de representaciones

(algunas gráficas y otras tabulares o basadas en lenguajes) que describen la estructura de

los datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz.

• Codificación: Las representaciones del diseño deben ser traducidas a un lenguaje

artificial, dando como resultado unas instrucciones ejecutables por ordenador. El paso de la

codificación es el que lleva a cabo esa traducción.

• Prueba del SW: Una vez que el SW ha sido implementado en una forma ejecutable por

máquina debe ser probado para descubrir los defectos que puedan existir en la función, en

la lógica y en la implementación.

La fase de mantenimiento se centra en el cambio: Comienza una vez construido el

sistema, coincidiendo con su vida útil. Durante ella, el SW es sometido a una serie de

modificaciones y reparaciones. Va asociada a la corrección de errores, a las adaptaciones

requeridas por la evolución del entorno del SW y a las modificaciones debidas a los cambios

Modificación y adaptación

Fallos de definición

Errores

de los requisitos del cliente dirigidos a reforzar o a ampliar el sistema. Esta fase vuelve a

aplicar los pasos de las fases de definición y de desarrollo, pero en el contexto del SW ya

existente. Se encuentran cuatro tipos de cambios:

• Corrección: El mantenimiento correctivo cambia el SW para corregir los defectos.

• Adaptación: El mantenimiento adaptativo consiste en modificar el SW para

acomodarlo a los cambios de su entorno externo.

• Mejora: El mantenimiento perfectivo amplia el SW más allá de sus requisitos

funcionales originales.

• Prevención: Ya que el SW se deteriora debido al cambio, de ahí este mantenimiento

preventivo o reingeniería del SW, que hace que los programas se puedan corregir, adaptar y

mejorar más fácilmente.

Las fases y sus pasos relacionados descritos anteriormente, se complementan con varias

actividades “protectoras”: las revisiones que se realizan durante cada paso para asegurar

que se mantiene la calidad.

Resumiendo, el SW se ha convertido en el elemento clave de la evolución de los sistemas

y productos informáticos, ha pasado a ser una industria por sí misma; un factor que limita

la evolución de los sistemas informáticos.

ESQUEMA DEL CICLO DE VIDA DEL SW

DEFINICIÓN

- Análisis del sistema - Planificación del proyecto - Análisis de requisitos

MANTENIMIENTO

- Corrección - Adaptación - Mejora - Prevención

DESARROLLO

- Diseño del SW - Codificación - Prueba

PERSPECTIVAS FUTURAS

Los cambios en la tecnología de la ingeniería del SW son “rápidos y estrictos”, pero, al

mismo tiempo, el progreso avanza de forma lenta.

Es el SW el que “marca la diferencia”, pero además, los programas y datos que lo

constituyen, ayudan a generar el producto más importante que puede adquirir cualquier

persona, empresa o gobierno: la información. En informática los cambios suelen seguir una

progresión (regla 5-5-5 en años) es el tiempo que pasa generalmente a convertirse una idea

en producto de masas.

Los cambios que afectan a la ingeniería del SW estarán determinados simultáneamente

por estos cuatro aspectos:

1. (La gente que trabaja) Las personas y la forma en que construyen sistemas.

Al aumentar el tamaño de los programas, aumentan las personas que trabajan, se crean

equipos individuales de trabajo, la comunicación se hace así más difícil pero se solucionará

cambiando la forma de comunicación (correo electrónico).

2. (El proceso que aplican) El nuevo proceso de ingeniería del SW.

En situaciones difíciles es probable que el SW se desplace a un modelo evolutivo de

desarrollo. Es probable que en el futuro se apunte a sistemas orientados a objetos

combinando con herramientas CASE.

3. (La naturaleza de la información) Nuevas formas de representación de la

información.

Los datos son información en bruto, la información se obtiene procesándolos, el

conocimiento se obtiene asociando informaciones, la sabiduría consiste en obtener

principios generales de fragmentos del conocimiento. La ingeniería que viene, además de

información procesará conocimientos. La clave residirá en nuestra habilidad para asociar la

información de fuentes distintas sin una conexión evidente y combinarlos de forma

adecuada.

Proceso

Proceso

Proceso

De otras informaciones

De otras informaciones

E/ P /S

LA NATURALEZA DE LA INFORMACIÓN

UN CAMBIO QUE AFECTA AL FUTURO DEL SW: LA NATURALEZA DE LA

INFORMACIÓN

Todo tratamiento implica: E/, P y /S

SABIDURÍA

CONOCIMIENTO

INFORMACIÓN

DATOS EN BRUTO

El SW futuro procesará conocimientos que es la entrada de los SS.EE.

INFORMACIÓN INFORMACIÓN

CONOCIMIENTO CONOCIMIENTO CONOCIMIENTO

SABIDURÍA

Clave del futuro del SW: Posibilidad y habilidad de asociar la información y el conocimiento de distintas fuentes

4. (La tecnología subyacente) La tecnología como impulsor.

El HW seguirá probablemente dos caminos paralelos, uno de tecnologías ya maduras

(procesadores CISC y RISC) y otra dirección podría ser el desarrollo de arquitecturas

menos tradicionales que pueden ocasionar cambios radicales en el SW que se construya. A

pesar de esto, se puede asegurar que la calidad de SW nunca perderá importancia y que un

buen diseño, un análisis efectivo y una correcta validación siempre estarán presentes en su

desarrollo.

Comenzando el nuevo milenio, el SW ha pasado a ser el producto y la industria más

importante en el mundo, su impacto y su importancia han aumentado. Sin embargo, las

nuevas generaciones de desarrolladores de SW deberán enfrentarse a la mayoría de

problemas y desafíos a los que se enfrentaron las generaciones anteriores.

De otras informaciones

De otras informaciones

E/ P /S

Proceso

Proceso

Proceso

NATURALEZA DE LA INFORMACIÓN

LA NATURALEZA DE LA INFORMACIÓN

UN CAMBIO QUE AFECTA AL FUTURO DEL SW: LA NATURALEZA DE LA

INFORMACIÓN

INFORMACIÓN INFORMACIÓN

CONOCIMIENTO CONOCIMIENTO CONOCIMIENTO

SABIDURÍA

Clave del futuro del SW: Posibilidad y habilidad de asociar la información y el conocimiento de distintas fuentes

Todo tratamiento implica: E/, P y /S

El SW futuro procesará conocimientos que es la entrada de los SS.EE.

SABIDURÍA

CONOCIMIENTO

INFORMACIÓN

DATOS EN BRUTO

Nuevas formas de representación de la información.

Los datos son información en bruto, la información se obtiene procesándolos, el

conocimiento se obtiene asociando informaciones, la sabiduría consiste en obtener

principios generales de fragmentos del conocimiento. La ingeniería que viene, además de

información procesará conocimientos. La clave residirá en nuestra habilidad para asociar la

información de fuentes distintas sin una conexión evidente y combinarlos de forma

adecuada.

CICLOS DE VIDA EN GENERAL

CICLO DE VIDA CLÁSICO (EN CASCADA, LINEAL O SECUENCIAL)

Lo que realmente caracteriza el ciclo de vida de un proyecto como clásico son dos

aspectos: una fuerte tendencia a la implantación ascendente del sistema y la insistencia en

la progresión lineal y secuencial de una fase a la siguiente.

El ciclo de vida clásico es un ciclo de fases, que sigue un esquema en cascada, análogo al

esquema general. Este paradigma contempla las siguientes fases:

• Análisis del sistema: El SW suele ser parte de un sistema mayor, formado por HW,

SW, bases de datos y personas. Por ese motivo, se debe comenzar estableciendo los

requisitos del sistema, asignando funciones a los distintos componentes y definiendo las

interfases entre componentes.

• Análisis de los requerimientos del SW: Como fruto de este análisis se genera un

documento conocido como especificación de requisitos del SW (SRS).

• Diseño: Consiste en construir una estructura para el SW que permita cumplir los

requisitos con la calidad necesaria.

• Codificación: Consiste en plasmar el diseño en programas escritos e un lenguaje de

programación adecuado.

• Prueba: En las pruebas se debe comprobar que los programas se corresponden con el

diseño, realizan correctamente sus funciones y que el sistema satisface los requisitos

planteados.

• Mantenimiento: Dependiendo de la naturaleza y motivación de cada operación de

mantenimiento concreta, será necesario revisar desde la codificación, desde el diseño o

desde una fase de análisis.

- Inicio del proyecto - Recopilación o análisis de requisitos

COMUNICACIÓN

PLANEACIÓN

- Estimación - Itinerario - Seguimiento - Análisis

- Diseño

MODELADO

- Código - Prueba

CONSTRUCCIÓN

DESPLIEGUE

- Soporte - Entrega - Retroalimentación

El ciclo de vida clásico es el paradigma más antiguo y más ampliamente usado en la

ingeniería del SW. Sin embargo, con el paso de los años se han producido críticas al

paradigma. Entre los problemas que se presentan algunas veces se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.

Siempre hay iteraciones y se crean problemas en la aplicación del paradigma.

2. Normalmente, es difícil para el cliente establecer explícitamente al principio todos los

requisitos.

3. El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del

proyecto, no estará disponible una versión operativa del programa.

Cada uno de estos problemas es real. Sin embargo, el paradigma clásico del ciclo de vida

tiene un lugar definido e importante dentro del trabajo realizado en ingeniería de SW. El

ciclo de vida clásico sigue siendo el modelo procedimental más ampliamente usado por los

ingenieros del SW, a pesar de sus inconvenientes.

CICLO DE VIDA DE PROTOTIPOS

Hay situaciones en que no es posible usar el ciclo de vida clásico. En estas situaciones es

posible seguir el modelo de ciclo de vida de prototipos. Se basa en la construcción de un

prototipo durante las primeras etapas del ciclo de vida.

Un prototipo es un modelo “a escala reducida” del sistema que se va a construir.

El ciclo de vida comienza con la realización de un breve análisis de los requisitos, tras el

cual se diseña y codifica el prototipo. Sobre el prototipo se discuten y detallan las

especificaciones, modificando el prototipo de acuerdo con éstas, siguiendo un proceso

COMUNICACIÓN PLAN RÁPIDO

DESARROLLO ENTREGA RETROALIMENTACIÓN

CONSTRUCCIÓN DEL PROTOTIPO

MODELADO DISEÑO RÁPIDO

cíclico. El resultado de este proceso es el documento de especificación de requisitos del

SW.

A partir de este punto se puede desechar el prototipo, diseñándose el sistema

definitivo, o pueden realizarse refinamientos sucesivos del prototipo hasta alcanzar un

producto utilizable.

Normalmente un cliente define un conjunto de objetivos generales para el SW, pero no

identifica los requisitos detallados de entrada, proceso o salida.

La construcción de prototipos comienza con la recolección de los requisitos. Luego se

produce un “diseño rápido” que conduce a la construcción de un prototipo. El prototipo es

evaluado por el cliente/usuario y se utiliza para refinar los requisitos del SW a desarrollar.

La clave está en definir al comienzo las reglas del juego; debe construirse el SW real

siempre con los ojos puestos en la calidad y en el mantenimiento del producto.

CICLO DE VIDA EN ESPIRAL

COMUNICACIÓN

CONSTRUCCIÓN Código Prueba

MODELADO Análisis Diseño

PLANEACIÓN Estimación Análisis de riesgos

DESPLIEGUE Entrega Retroalimentación

Ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida

clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el

análisis del riesgo. El modelo, define cuatro actividades principales:

• Planificación: Determinación de objetivos, alternativas y restricciones.

• Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos.

• Ingeniería: Desarrollo del producto de “siguiente nivel”.

• Evaluación del cliente: Valoración de los resultados de la ingeniería.

Con cada iteración alrededor de una espiral el cliente evalúa el trabajo de ingeniería y

sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase

de planificación y análisis de riesgo. En cada bucle alrededor de la espiral, la culminación

del análisis de riesgo resulta en una decisión de “seguir o no seguir”. Si los riesgos son

demasiado grandes, se puede dar por terminado el proyecto.

El modelo en espiral demanda una consideración directa de riesgos técnicos en todas las

etapas del proyecto y, si se aplica adecuadamente, debe reducir los riesgos antes de que se

conviertan en problemáticos. Pero, al igual que otros paradigmas no es la panacea. Requiere

una considerable habilidad para la valoración del riesgo, y cuenta con esta habilidad para el

éxito. El modelo en sí mismo es relativamente nuevo y no se ha usado tanto como el ciclo de

vida o la creación de prototipos.

TÉCNICAS DE T4G Y T5G

El término “técnicas de cuarta generación” (T4G) abarca un amplio espectro de

herramientas de SW que facilitan, al que desarrolla el SW, la especificación de algunas

características del SW a alto nivel. Luego, la genera automáticamente el código fuente

basándose en la especificación del técnico.

Actualmente, no existe un entorno T4G que pueda aplicarse con igual facilidad a todas

las categorías de aplicaciones del SW.

Ha habido mucha controversia en un considerable debate sobre el uso del paradigma

T4G. Los defensores aducen reducciones drásticas en el tiempo de desarrollo del SW y una

mejora significativa en la productividad de la gente que construye el SW. Los detractores

aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los

lenguajes de programación, que el código fuente producido por tales herramientas es

“ineficiente” y que el mantenimiento de grandes sistemas de SW desarrollados mediante

T4G, es cuestionable.

El estado actual de los métodos de T4G es este, aproximadamente:

1. Con muy pocas excepciones, el ámbito de aplicación actual de las T4G está limitado a

las aplicaciones de sistemas de información de gestión.

2. Los datos preliminares recogidos en compañías que utilizan T4G parecen indicar que el

tiempo requerido para producir SW se reduce mucho para aplicaciones pequeñas y de

tamaño medio.

3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de SW exige el

mismo o más tiempo de análisis, diseño y prueba, perdiéndose así un tiempo sustancial que

se ahorra mediante la eliminación de la codificación.

Las T4G ya se han convertido en una parte importante del desarrollo del SW en el área

de aplicaciones de sistemas de información y probablemente llegarán a usarse bastante en

aplicaciones de ingeniería y de tiempo real. La demanda de SW continuará creciendo, pero

los métodos y los paradigmas convencionales contribuirán probablemente cada vez menos al

desarrollo del mismo. Las T4G llenarán el hueco existente.

TÉCNICAS DE DESARROLLO INCREMENTAL: Son los métodos de desarrollo que

permiten crear y entregar un programa por etapas. Las técnicas incrementales reducen el

riesgo dividiendo los proyectos en una serie de subproyectos más pequeños.

El desarrollo incremental ofrece una facilidad mayor para realizar modificaciones a

mitad de camino.

A parte del modelo en espiral, tenemos los siguientes modelos:

MODELO DE CASCADA PURA

Concepto del software

Análisis de requerimientos

Diseño global

Diseño detallado

Codificación y depuración

Prueba del sistema

El modelo en cascada pura es el modelo de ciclo de vida más conocido y ofrece una

velocidad de desarrollo aceptable en algunas circunstancias. Otros modelos, sin embargo,

proporcionan una velocidad de desarrollo superior. La mayoría de inconvenientes de este

modelo están en el tratamiento como etapas secuenciales disjuntas.

MODELO SASHIMI (CASCADA CON FASES SOLAPADAS)

Puede evitar algunos inconvenientes del modelo en cascada solapando sus etapas, pero

este enfoque genera nuevos problemas. No debemos esperar necesariamente a que termine

una etapa para comenzar otra. Se pueden realizar actividades en paralelo, lo cual puede

suponer una mala comunicación.

MODELO DE PROTOTIPADO EVOLUTIVO

Con el prototipado evolutivo, se comienza por diseñar e implementar las partes más

importantes del programa en un prototipo, y a continuación se amplía y refina el prototipo

hasta que se termine. El prototipo se convierte en el software que se entrega finalmente.

Se desarrolla el concepto del sistema a medida que avanza el proyecto, se comienzan

diseñando e implementando las partes más importantes y visibles del sistema en un

Concepto del software

Análisis de requerimientos

Diseño global

Diseño detallado

Codificar y depurar

Prueba del sistema

Concepto inicial

Diseño e implementación del prototipo

inicial

Refinar el prototipo hasta

que sea aceptable

Completar y entregar el prototipo

prototipo y se va ampliando y refinando el prototipo hasta que se termine. El prototipo se

convierte en el software que finalmente se entregará al cliente.

Se utiliza con ventaja cuando los requerimientos cambian con rapidez, cuando el cliente

es reacio a especificar el conjunto de requisitos y también cuando los desarrolladores no

están seguros de la arquitectura o los algoritmos adecuados que podemos utilizar.

Tiene el inconveniente de la imposibilidad de conocer desde el principio del proyecto lo

que tardaremos en obtener un producto aceptable, e incluso desconocemos el número de

iteraciones que tendremos que realizar.

MODELO DE ENTREGA POR ETAPAS

La entrega por etapas evita el problema del modelo en cascada de no terminar ninguna

parte del sistema que se está realizando hasta que esté finalizado completamente. Una vez

finalizado el diseño, se puede implementar y entregar el sistema en etapas.

El software se le muestra al cliente en etapas refinadas sucesivamente. Se atraviesa los

pasos del modelo en cascada pasando por la definición, análisis y diseño global de una

arquitectura para el programa completo que se intenta construir y luego se procederá a

realizar el diseño detallado, la codificación, depuración y prueba independientemente en

cada una de las etapas.

Concepto del software

Análisis de requerimientos

Diseño global

Etapa 1: Diseño detallado, codificación, depuración, prueba y entrega

Etapa 2: Diseño detallado, codificación, depuración, prueba y entrega

Prioridad media: Diseño detallado, codificación, depuración y prueba

MODELO DE ENTREGA EVOLUTIVA

Este modelo ofrece el control que se obtiene con la entrega por etapas y la flexibilidad

que se obtiene con el prototipado evolutivo. Puede ajustarlo para proporcionar el control y

la flexibilidad que necesite.

Se desarrolla una versión del producto, se le muestra al cliente y se refina en función de

la realimentación del cliente.

MODELO DE DISEÑO POR HERRAMIENTAS: Pueden ofrecer una velocidad de

desarrollo excepcional, pero por el contrario, el control que tenemos sobre la funcionalidad

del producto es mucho menor que en otros ciclos.

Este modelo, y el siguiente, sólo lo añaden algunos autores.

SOFTWARE COMERCIAL EXISTENTE: Que encontraremos disponible de forma

inmediata y que siempre podemos revisarlo y adaptarlo a nuestras necesidades.

Concepto del software

Análisis preliminar de requerimientos

Diseño global y del núcleo del sistema

Desarrollar una versión

Incorporar la realimentación

del cliente

Entregar la versión

Pedir la realimentación

del cliente

Entregar la versión final

DIAGRAMAS CON LOS QUE UN PROYECTO QUEDA DEFINIDO

DIAGRAMA DE CONTEXTO: El diagrama de contexto es un DFD. Este diagrama es el

primer diagrama de la jerarquía. También se le conoce como diagrama de nivel 0. El objetivo

de este diagrama es delimitar la frontera entre nuestro sistema y el mundo exterior, y

definir sus interfaces, es decir, los flujos de datos de entrada y salida, o sea, el contexto.

Este diagrama está formado exclusivamente por un proceso que representa una especie

de caja negra del sistema completo, un conjunto de entidades externas que representan la

procedencia y el destino de la información del sistema, y un conjunto de flujos de datos que

representan los caminos por los que fluye dicha información. En este diagrama es necesario

que estén representadas todas las entidades externas.

Ejemplo:

DIAGRAMA DE FLUJO DEL SISTEMA: Es una herramienta adicional muy útil para los

diseñadores que deben desarrollar una arquitectura global del HW y SW del sistema para

implantar los requerimientos del usuario. Sin embargo, no parece ser una herramienta de

modelado apropiado para el análisis de sistemas, porque enfatiza los detalles de la

implantación física.

Pudiera ser útil para modelar al final de la actividad de análisis, cuando se está

desarrollando el modelo de implantación del usuario.

El ingeniero de sistemas refina el diagrama de contexto de arquitectura al estudiarlo

con más detalle. Se identifican los subsistemas principales que permiten funcionar al

sistema dentro del contexto definido por el diagrama. Los subsistemas principales se

definen en un diagrama de flujo del sistema (DFS) que se obtiene del diagrama de

contexto. El flujo de información a través de las regiones del diagrama de contexto se

utiliza para guiar al ingeniero de sistemas en el desarrollo del DFS, un esquema más

detallado del sistema. El DFS muestra los subsistemas principales y el flujo de las líneas de

0 Gestionar biblioteca

USUARIO USUARIO

BIBLIOTECARIO

Sanción

Pedido libros

Devolución libros

Altas/Bajas

información importantes (datos y control). Además, la plantilla del sistema divide el

proceso del subsistema en cada una de las regiones de proceso. En este punto, cada uno de

los subsistemas puede contener uno o más elementos del sistema (por ejemplo, HW, SW,

personas) tal y como los ha asignado el ingeniero del sistema.

El DFS inicial se convierte en el nodo superior de una jerarquía de DFS. Cada rectángulo

del DFS original puede expandirse en otra plantilla de arquitectura dedicada a ella en

forma exclusiva. Cada uno de los DFS del sistema puede utilizarse como punto de partida

de subsiguientes fases de ingeniería para el subsistema que se describe.

Ejemplo:

Archivo de transacciones

# 1

Archivo de transacciones

# 2

Programa de edición de

transacciones

Archivo temporal (disco)

Actualizar programa

Informe diario Archivo principal

PASO DE ANÁLISIS A DISEÑO

DISEÑO DE DATOS: Transforma el modelo de la información que se creo durante el

análisis en las estructuras de datos necesarias para el SW. Los objetos y las relaciones en

el DER junto con el DD son la base de este diseño.

DISEÑO ARQUITECTÓNICO: Definen la relación entre las principales estructuras del

programa. El proceso consiste en dividir el programa en módulos que se identifican por

separado y luego se integran para satisfacer los requisitos del sistema. La base de este

diseño está en la interacción de subsistemas definidos en el DFD.

DISEÑO DE LA INTERFAZ: Se describe la comunicación del SW consigo mismo,

también con los sistemas que operan con él y con los usuarios que lo emplean. La base del

diseño de la interfaz es el DFD que se complementa algunas veces con algunas

especificaciones (o informaciones) de control.

DISEÑO PROCEDIMENTAL: Transforma los módulos del diseño arquitectónico (que son

las estructuras del programa) en una descripción procedimental de los componentes del

SW. La base de este diseño está en el DTE, en las especificaciones de proceso y en las

especificaciones de control.

Diseño Procedimental

Diseño de Interfaz

Diseño Arquitectónico

Diseño de Datos

MEJOR PLAN POSIBLE

RESUMIR LOS CUATRO PILARES

1 2 3 4

EVITAR ERRORES CLÁSICOS: Se deben evitar a toda costa. Estos errores pueden

estar relacionados con las personas, con el proceso, con el producto o con la tecnología.

APLICAR LAS BASES DE DESARROLLO:

• Bases de gestión:

Estimación: Del tamaño, del esfuerzo y planificar en base a ellos.

Planificación: Siguiendo actividades para evitar problemas.

Seguimiento: Comprobación paso a paso de planes previos.

Medidas: Recogiendo datos medibles para analizar calidad y productividad.

• Bases técnicas:

Gestión de requisitos: Llevados a documentación.

Construcción: Trabajo dirigido a calidad del código.

Gestión de la configuración (SCM): Con métodos para evaluar los cambios.

• Bases de control de calidad:

Módulos propensos a errores.

Prueba.

Revisiones técnicas: Reuniones, lectura de código, inspecciones.

GESTIONAR LOS RIESGOS: Su función es identificar, estudiar y eliminar las fuentes

de riesgo antes de que empiecen a amenazar la terminación satisfactoria de un proyecto de

SW. La gestión de riesgo se divide en:

1 EVITAR ERRORES CLÁSICOS

2 APLICAR LAS BASES DE DESARROLLO

3 GESTIONAR LOS RIESGOS

4 APLICAR LOS MÉTODOS ORIENTADOS A LA PLANIFICACIÓN • Que permita desarrollar más rápido • Que reduce el riesgo de planificación • Que hacen visible el progreso

• Estimación de riesgos: Identificación, análisis y priorización.

• Control de riesgos: Planificación de la gestión, resolución y monitorización.

APLICAR LOS MÉTODOS ORIENTADOS A LA PLANIFICACIÓN: Hay tres tipos:

• Que mejoran la velocidad.

• Que reducen el riesgo.

• Que hacen visible el progreso.

Métodos

orientados a la velocidad

Métodos orientados a

los riesgos de planificación

Métodos orientados a la visibilidad

Métodos orientados a

la planificación

RAD: ESTRATEGIA GENERAL Y ESQUEMA. EXPLICAR “PERSONAS”

El RAD (Rapid Application Development) o DRA (Desarrollo Rápido de Aplicaciones), que

tal y como su propio nombre indica hace especial énfasis en un ciclo de desarrollo

extremadamente corto, y que para algunos autores no es más que una adaptación a alta

velocidad del Modelo Lineal Secuencial.

El tiempo de desarrollo se ha convertido en una prioridad tan importante que en la

mayoría de las ocasiones nos impide valorar otros parámetros, que al final terminan

afectando al propio tiempo de desarrollo.

Un proyecto de desarrollo rápido puede ser cualquier proyecto que necesite hacer

especial hincapié en la velocidad de desarrollo, utilizaremos el término de igual forma a

desarrollo veloz o planificación más corta, en definitiva significa desarrollar SW a una

velocidad superior a la que conseguimos en estos momentos.

Las soluciones simples suelen funcionar sólo con problemas sencillos, y el desarrollo de

SW no lo es, el desarrollo “rápido” es aún menos simple. Para tener éxito desarrollando SW

de forma rápida se requieren dos condiciones:

• Seleccionar métodos eficaces en lugar de métodos ineficaces.

• Seleccionar métodos orientados de forma específica para alcanzar objetivos de

planificación.

Se pueden seleccionar tres tipos de métodos orientados a la planificación:

• Métodos que mejoran la velocidad de desarrollo, permitiéndose entregar antes el SW.

• Métodos que reducen el riesgo en la planificación, evitando grandes retrasos.

• Métodos que hacen visible el progreso, e impiden tener la impresión de estar

efectuando un desarrollo muy lento.

Métodos

orientados a la velocidad

Métodos orientados a

los riesgos de planificación

Métodos orientados a la visibilidad

Métodos orientados a

la planificación

Recordar por último que seleccionar métodos eficaces y evitar los que no lo son es mucho

más fácil de decir que de hacer.

ESTRATEGIA GENERAL PARA EL DESARROLLO RÁPIDO: Uno de los errores más

frecuentes en los que incurren las personas que quieren desarrollar de forma rápida, es

centrarse en métodos orientados solamente a la “planificación”, sin tener en cuenta que son

sólo una parte de lo que necesitamos para obtener el plan más corto posible.

Se puede obtener un desarrollo rápido siguiendo una estrategia dividida en cuatro

partes:

1. Evitar los errores clásicos.

2. Aplicar las bases de desarrollo.

3. Gestionar los riesgos.

4. Aplicar métodos orientados a la planificación (de la figura anterior).

DIMENSIONES (FACTORES) DE LA VELOCIDAD DE DESARROLLO: Nuestro

proyecto SW se desarrolla a través de cuatro dimensiones principales: PERSONAS,

PROCESO, PRODUCTO Y TECNOLOGÍA.

PERSONAS: Las personas forman una de las cuatro dimensiones principales a través de

las cuales se desarrolla nuestro producto SW. Los temas relacionados con el personal

tienen un impacto mayor en la productividad del SW y por lo tanto en su calidad. Los

métodos más efectivos son aquellos que sacan el máximo partido al potencial humano de sus

desarrolladores.

En definitiva si nos interesa el desarrollo rápido, ocupémonos de las personas.

• SELECCIÓN DEL PERSONAL PARA EQUIPOS DE PROYECTOS: Barry Boehm

presenta cinco principios de selección:

Máximo talento: Utiliza poco y mejor personal.

Trabajo adecuado: Asignar tareas según las habilidades y motivación de las

personas.

Progresión Profesional: Ayudando a la gente a actualizarse por sí misma en lugar

de obligarles a trabajar donde son más necesarios.

Equilibrar los equipos: Seleccionando personal que se complemente y armonice con

los demás.

Eliminar la inadaptación: Reemplazando a los miembros problemáticos del equipo lo

antes posible.

• ORGANIZACIÓN DEL EQUIPO: La forma con que se organiza al personal tiene una

gran influencia sobre la eficiencia en el trabajo.

• MOTIVACIÓN: La motivación es potencialmente el mejor aliado para el desarrollo

rápido de los proyectos.

BASES DE GESTIÓN

Los fundamentos de Gestión tienen, al menos, tanta influencia como los técnicos en la

planificación de desarrollos, las organizaciones que intentan implantar la disciplina de IS

antes que la Gestión de Proyectos, están abocadas al fracaso ya que la Gestión controla las

tres magnitudes del triángulo clásico de equilibrio: Planificación, Coste y Producto.

Los fundamentos de Gestión consisten en determinar el tamaño del producto, asignando

los recursos apropiados a un producto de ese tamaño.

ESTIMACIÓN Y PLANIFICACIÓN: Para crear una buena Planificación SW los

proyectos pasan por tres etapas básicas. Primero se estima el tamaño del producto, luego

se estima el esfuerzo y por último se realiza la Planificación basándose en el esfuerzo

estimado.

Una estimación correcta es una condición necesaria para una Planificación efectiva, que

además es esencial para un desarrollo eficiente.

PLANIFICACIÓN: Una mala Planificación se manifiesta como fuente de problemas más a

menudo que cualquier otra causa. Incluye las siguientes actividades:

• Estimación y Planificación.

• Determinar el número de personas que deben participar en el equipo de proyecto, las

habilidades técnicas que son necesarias, cuándo aumentar el número de personas y quién

participará.

• Decidir cómo organizar el equipo.

• Elegir el modelo de Ciclo de Vida que se va a realizar.

• Gestión de Riesgos.

• Tomar Decisiones estratégicas, tales como: controlar el conjunto de prestaciones del

producto y decidir si hay que crear o bien comprar algunas partes del producto.

SEGUIMIENTO: Una vez planificado el proyecto, hay que seguir el proceso de

desarrollo para comprobar que se está cumpliendo con el plan previsto.

El seguimiento es una actividad fundamental en el proceso de Planificación del SW, está

claro que si no se puede seguir un proyecto, no hay forma de saber si el plan se está

llevando a cabo ni lo que se debe hacer después. Si hacemos un seguimiento efectivo

podremos detectar inmediatamente los problemas de Planificación cuando aún estamos a

tiempo de resolverlos, el desarrollo rápido no puede llevarse a efecto si no seguimos el

proyecto.

MEDIDAS: Recoger datos métricos para analizar la calidad y productividad del SW a lo

largo del tiempo, es una de las buenas normas a seguir para obtener una buena organización.

Si además de los datos sobre el Coste y la Planificación obtenemos datos históricos,

como, el tamaño de los programas en número de líneas de código, o cualquier otra medida,

tendremos una buena base para poder planificar proyectos futuros.

Una organización que desee implantar el desarrollo rápido debe utilizar métricas

específicas recogiendo las medidas y datos básicos para saber cuál es la velocidad de

desarrollo y si va mejorando o no a medida que transcurre el tiempo.

BASES TÉCNICAS

Un estudio realizado en 1984 comprobó que no se puede alcanzar una gran productividad

sin utilizar estas Bases Técnicas. Hay algunos proyectos que utilizan modernos métodos de

Programación con los mismos resultados que otros que no los utilizan, esto nos indican que

las Bases Técnicas son necesarias pero no suficientes para conseguir un rápido desarrollo.

GESTIÓN DE REQUERIMIENTOS (REQUISITOS): Es éste un proceso que consiste

en reunir requisitos y plasmarlos en un documento. El éxito en la gestión de los

requerimientos está en conocer los suficientes métodos diferentes como para poder

escoger los que sean más apropiados para un proyecto específico.

Las Bases de Gestión de Requerimientos son:

• Metodologías de Análisis de Requerimientos.

• Métodos para crear el modelo del Sistema.

• Métodos de Comunicación como el Desarrollo Conjunto de Aplicaciones (JAD).

• Las relaciones entre la Gestión de Requerimientos y los diferentes modelos del Ciclo

de Vida.

La Gestión de Requerimientos proporciona de dos formas diferentes una gran influencia

en la velocidad de desarrollo. En primer lugar es un paso que tiende a hacerse sin prisas,

comparado con otras actividades, si aceleramos este paso sin afectar a la calidad se puede

disminuir el tiempo de desarrollo. En segundo lugar, obtener los requerimientos que se

necesitan en el primer momento normalmente cuesta de 50 a 200 veces menos que si se

espera a obtenerlos en fases posteriores.

Un proyecto normal tienen un 25 por 100 de cambios en los Requerimientos, algunos

métodos de Gestión de Requerimientos permiten reducir el número de estos cambios, otros

métodos permiten reducir el coste de cada cambio. Podemos imaginar el efecto combinado

que puede producir por un lado reducir el número de cambios y por otro el coste de los

mismos. Consiguiendo esto, el desarrollo rápido está más cerca.

DISEÑO: Antes de construir un sistema SW debemos pensar y hacer una arquitectura y

un diseño. Un error de diseño que no es detectado hasta la fase de comprobación cuesta 10

veces más tiempo para solucionarlo que si se aprecia en la etapa de diseño.

Los conceptos de Modularidad (que permite a un programa ser intelectualmente

manejable) y Ocultamiento (que hace que los objetos sean inaccesibles a otros módulos

para que no haya colisiones) son las bases del diseño Orientado a Objetos.

El Diseño bien hecho, es la base de la construcción, planificación, seguimiento y control

de un proyecto y es imprescindible para conseguir una velocidad máxima de desarrollo.

CONSTRUCCIÓN: Cuando llegamos aquí es que ya se ha llevado a cabo la mayor parte

del trabajo para el éxito o el fracaso del proyecto. El trabajo de Construcción es

importante hacerlo bien. Las bases de la Construcción incluyen algunos temas como:

• Métodos de Codificación.

• Métodos de Comprobación y de Depuración.

• Ventajas e inconvenientes del Lenguaje de Programación utilizado.

• Estrategias y Métodos para refinar el Código.

• Uso de Herramientas de Construcción, etc.

GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE: La SCM (Software

Configuration Management) es un método de Gestión de los “artefactos” del proyecto de

forma que éste permanezca en estado controlable durante todo el tiempo.

El artefacto más controlado del proyecto suele ser el Código Fuente pero podemos

aplicar SCM (Gestión de Configuración del SW) a los requerimientos, planes, diseños, casos

de prueba y a cualquier otro elemento que se utilice para construir el producto.

BASES DE CONTROL DE CALIDAD

Proporcionan un gran apoyo para obtener la máxima velocidad de desarrollo. La clave

principal para no cometer errores, sobre todo en los primeros momentos, es prestar una

especial atención desde el primer día a estas Bases de Control.

Pocas son las organizaciones que tienen una tasa de defectos muy baja, en cuyo punto, la

reducción adicional del número de defectos aumentará la cantidad de tiempo de desarrollo.

El tiempo extra es necesario cuando se aplica a Sistemas críticos para la vida, pero no para

cuando no se producen estas circunstancias extremas.

MÓDULOS PROPENSOS A ERRORES: Son responsables de un número

desproporcionado de defectos, son mucho más costosos y consumen más tiempo de

ejecución. Es prioritario identificar y rediseñar este tipo de módulos

PRUEBA: La Prueba de Ejecución: Encontrar los errores al ejecutar el programa y ver lo

que hace, es indudablemente el método más común del Control de Calidad. Existen dos

clases de Prueba, la individual, en la que el desarrollador comprueba su propio código y la

prueba del Sistema, en la que un probador independiente observa si el Sistema funciona

como se esperaba de él.

En lo que respecta a la velocidad de desarrollo y a los métodos de control de calidad, la

Prueba es la oveja negra, con ella se descubre si el producto tiene una calidad muy baja y

se convierte así en el mensajero de las malas noticias que afectan a la planificación.

La mejor forma de afrontar la Prueba es preparar un plan antes de las posibles malas

noticias, estableciendo la Prueba de tal forma que se pueda relanzar inmediatamente el

producto.

REVISIONES TÉCNICAS: Incluyen toda clase de Revisiones que se utilizan para

detectar defectos. Los tipos de Revisiones más frecuentes son:

• Reuniones: Son útiles porque se pueden utilizar para detectar errores antes de la

prueba. Con las Reuniones se pueden encontrar entre un 30 y un 70 por 100 de errores en

los programas.

• Lectura de código: El programador, autor de la codificación, distribuye el listado del

programa fuente entre dos o más revisores que le informan de cualquier error que

detecten.

• Inspecciones: Son un tipo de Revisión técnica formal que también ha demostrado ser

efectiva en la corrección de errores, sobre todo en requerimientos, prototipos de interfaz

de usuario, diseño y otros artefactos del proyecto. Detectan al mismo tiempo tanto el

Síntoma como la Causa del defecto. Se recomienda siempre seguir las instrucciones ya que

la mayoría de las veces los proyectos SW fallan simplemente porque tanto los

Programadores como los directivos no siguen las Bases de Desarrollo que se han descrito,

es también cierto que se puede desarrollar SW, a veces rápidamente, sin dominar estos

fundamentos, pero a juzgar por los resultados que se obtienen si no utilizamos los

fundamentos de las Bases de Desarrollo no tendremos el control necesario sobre los

proyectos no solo para desarrollarlos de forma rápida si no que incluso desconoceremos si

podemos terminar los trabajos hasta que no finalizan.

ESTIMACIÓN Y SUS HERRAMIENTAS

El argumento básico de la estimación del SW es que: El desarrollo del SW es un proceso

de refinamiento gradual.

El proceso para crear una planificación de desarrollo exacta consta de tres pasos:

1. Estimar el tamaño del producto (Número de Líneas de Código).

2. Estimar el esfuerzo (personas – mes).

3. Estimar la planificación (meses).

Estos tres pasos se pueden englobar dentro de un paso general:

4. Dar un intervalo de estimación e ir refinando periódicamente ese intervalo, para ir

aumentando la precisión a medida que avanza el proyecto.

ESTIMACIÓN DEL TAMAÑO: Se hace sobretodo utilizando un enfoque algorítmico

como los puntos de función, que son una medida sintética del tamaño de los programas y se

pueden determinar fácilmente a través de las líneas de codificación (LDC) que requieren.

Algunos consejos para la estimación del tamaño son:

• Evitar las estimaciones improvisadas.

• Reservar tiempo suficiente para la estimación y planificarla.

• Utilizar datos de proyectos anteriores.

• Utilizar estimaciones basadas en el desarrollador.

• Estimar por consenso entre los miembros del equipo.

• Estimar a un bajo nivel de detalle.

• Utilizar herramientas de estimación de SW.

• Usar técnicas distintas para estimar y luego comparar los resultados.

• Cambiar los métodos de estimación conforme avanzamos en el proyecto.

ESTIMACIÓN DEL ESFUERZO: Es bueno conocer este dato para saber el número de

personas que hay que incorporar al proyecto. Para estimar el esfuerzo se pueden utilizar

los datos sobre proyectos anteriores o bien utilizar, utilizar un método algorítmico de

planificación como es el modelo COCOMO o el modelo de ciclo de vida de Putnam y Myers

para convertir la estimación del número de líneas de código en estimación del esfuerzo.

Recurso ( ) 2C1 estimada ticaCaracterisC ⋅= (C1 y C2 estimados en otros proyectos)

ESTIMACIÓN DE LA PLANIFICACIÓN: Existe una regla que permite calcularla a

partir del esfuerzo, es la ecuación:

−×= 31

mespersonas3.0meses en iónPlanificac

La calidad de la estimación del SW depende del nivel de refinamiento de la definición del

propio SW. Cuanto más refinada sea la definición, de mayor calidad será la estimación.

Es conveniente refinar la estimación de los proyectos a medida que vamos avanzando en

la ejecución de los mismos.

DESARROLLO ORIENTADO AL CLIENTE

Algunos expertos en desarrollo rápido aseguran que la buena comunicación con el usuario

final es uno de los tres factores críticos de este tipo de proyectos. Las dos razones

principales son:

• Estas buenas relaciones aumentan la velocidad de desarrollo actual.

• Las buenas relaciones con el cliente mejoran la percepción de la velocidad de

desarrollo.

MÉTODOS ORIENTADOS AL CLIENTE: Se pueden dividir en varias categorías:

• Planificación.

• Análisis de requerimientos.

• Diseño.

• Construcción.

No podemos olvidar que al utilizar métodos orientados al utilizar métodos orientados al

cliente aumenta la proporción de requerimientos reales que podemos recopilar desde un

primer momento (metodologías tipo JAD).

GESTIÓN DE LAS ESPECTATIVAS DEL CLIENTE: El esforzarnos en comprender las

expectativas del cliente puede ahorrarnos muchas fricciones y trabajo extra, ya que, parte

de nuestro trabajo como desarrolladores de SW es educar a nuestros clientes para que

comprendan el desarrollo del mismo.

Crear expectativas poco realistas en los clientes resulta a la larga un riesgo insuperable

en cualquier tipo de proyecto. Si hacemos promesas en función de un trabajo sencillo

generando expectativas realistas, ésa será una buena labor, y parte del trabajo como

desarrolladores.

MOTIVACIÓN

De las cuatro áreas de desarrollo rápido (personas, proceso, producto y tecnología), las

personas son las que ofrecen mayor posibilidad de acortar las planificaciones de SW. La

motivación es la que ejerce mayor influencia individual en cómo trabajan las personas y su

peso específico en la productividad es mayor que cualquier otro factor.

MOTIVACIONES TÍPICAS DEL DESARROLLADOR: Diferentes personas se motivan

con diferentes factores y los desarrolladores no se motivan siempre con las mismas cosas

que sus directivos.

Los principales factores que motivan a los desarrolladores de SW son (entre otros):

• Realización: Proporcionarles un entorno que les permita centrarse en lo que más les

gusta hacer, desarrollar SW.

• Posibilidad de superación: Centrarse en la superación del personal puede tener

consecuencias a corto y largo plazo sobre la productividad y sobre la organización. Apoyar

el desarrollo profesional es vital para la estabilidad de cualquier empresa especialmente en

el campo del SW.

• El trabajo en sí: La motivación interna de las personas parte de tres fuentes: el

trabajo debe tener sentido, debe tener responsabilidades por el resultado del mismo y

debe conocer los resultados reales de su actividad en el trabajo.

• Vida personal: El factor personal está mas considerado entre los desarrolladores de

SW.

• Oportunidad de supervisión técnica: Para el desarrollador esto representa una

realización, pues implica que ha alcanzado un nivel de experiencia suficiente para dirigir a

otros.

DESTRUCTORES DE LA MORAL: Tan importantes como los factores de motivación son

los que desmotivan, son los factores no satisfactorios (de higiene).

Los factores de higiene son las condiciones básicas que un trabajador necesita para

poder rendir de forma efectiva, en el mejor de los casos, estos factores no crean

descontento, pero su ausencia puede ser fuente de problemas. Factores de higiene para los

desarrolladores son:

• Espacio adecuado para la mesa de despacho y estantería.

• Tranquilidad suficiente para poder concentrarse.

• Intimidad para evitar interrupciones no deseadas.

• Acceso no restringido al ordenador y suministros de oficina.

• Equipo informático actualizado.

• Herramientas de SW y HW apropiadas.

• Libertad para establecer el horario de trabajo, tanto general (entre mañanas y

tardes, por ejemplo), como específico (tomarse una determinada tarde libre).

OTROS DESTRUCTORES DE LA MORAL:

• La manipulación de la directiva.

• La presión excesiva en la planificación.

• La falta de apreciación en los esfuerzos de desarrollo.

• La participación de directivos sin preparación técnica.

• El no involucrar a los desarrolladores en decisiones que les atañen.

• La baja calidad de los productos que desarrollan, lo que mina su amor propio.

FACTORES DE HIGIENE

Los factores de higiene son las condiciones básicas que un trabajador necesita para

poder rendir de forma efectiva, en el mejor de los casos, estos factores no crean

descontento, pero su ausencia puede ser fuente de problemas. Factores de higiene para los

desarrolladores son:

• Espacio adecuado para la mesa de despacho y estantería.

• Tranquilidad suficiente para poder concentrarse.

• Intimidad para evitar interrupciones no deseadas.

• Acceso no restringido al ordenador y suministros de oficina.

• Equipo informático actualizado.

• Herramientas de SW y HW apropiadas.

Libertad para establecer el horario de trabajo, tanto general (entre mañanas y tardes, por

ejemplo), como específico (tomarse una determinada tarde libre).

OTROS DESTRUCTORES DE LA MORAL:

• La manipulación de la directiva.

• La presión excesiva en la planificación.

• La falta de apreciación en los esfuerzos de desarrollo.

• La participación de directivos sin preparación técnica.

• El no involucrar a los desarrolladores en decisiones que les atañen.

• La baja calidad de los productos que desarrollan, lo que mina su amor propio.

EQUIPO DE TRABAJO

Es un pequeño número de personas, con aptitudes complementarias, que están

comprometidas en un propósito, en unos objetivos de rendimiento y con unos enfoques

comunes, en el que todos sean responsables ante todos.

Los proyectos pequeños pueden prescindir de equipos. Los grandes proyectos son

esfuerzo de grupos y juegan un papel importante en el éxito de este tipo de proyectos.

CREACIÓN DE UN EQUIPO DE ALTO RENDIMIENTO: Los equipos productivos se

caracterizan por una gran unión y que se han ido formando a lo largo de un tiempo. Las

características son:

• Una gran visión u objetivos compartidos.

• Un sentido de identidad de equipo.

• Una estructura dirigida por los resultados.

• Sus miembros son competentes.

• Un compromiso de equipo.

• Confianza mutua.

• Interdependencia entre sus miembros.

• Comunicación eficaz.

• Un sentido de autonomía.

• Un sentido de enriquecimiento.

• Un tamaño de equipo pequeño.

• Un alto nivel de disfrute.

CONFIGURACIONES DE EQUIPOS A LARGO PLAZO: Conseguir una gran

productividad es solo una consecuencia de los equipos estables, las razones para mantener

unidos y estables a los equipos son:

• Mayor productividad.

• Costes iniciales menores.

• Menor riesgo de problemas con el personal.

• Menos cambio de personal.

• El tema de la inactividad: Las organizaciones se muestran recelosas de mantener a los

equipos juntos, ya que tendrían que estar pagando a gente que no está haciendo nada hasta

que le llega un proyecto apropiado. Parece demostrado que las mejores organizaciones, no lo

consideran un gran inconveniente. Debemos permitirles perder tiempo, durante un tercio o

incluso la mitad de su vida laboral, para evitar el riesgo que implica el que se divida un buen

equipo.

CONTROL CONJUNTO DE PRESTACIONES

El problema más serio del conjunto de prestaciones es el cambio que se produce en los

requerimientos que se hicieron al inicio del proyecto. Los estudios realizados demuestran

que el cambio o añadido a posteriori de requerimientos tardíos incrementa el coste y la

planificación.

El control del conjunto de las prestaciones conforma la parte del producto de las cuatro

dimensiones de la velocidad de desarrollo, es el campo en el que entran en juego las

posibilidades relacionadas con el producto.

Podemos distinguir tres tipos generales de control:

• Control al principio del proyecto, para definir un conjunto de prestaciones consistente

con los objetivos de planificación y los presupuestos del proyecto.

• Control a mitad del proyecto, para controlar los cambios de requerimientos.

• Control al final del proyecto, recortando las prestaciones para alcanzar un objetivo de

planificación o de coste.

PROYECTO INICIADO: REDUCCIÓN DEL CONJUNTO DE PRESTACIONES: Esta

reducción consiste en no introducir prestaciones innecesarias en el producto. Hay tres

métodos para conseguirlo:

• Especificación mínima.

• Filtrado de requerimientos.

• Desarrollo por versiones.

Respecto a ésta última (Desarrollo por versiones), puede ser una alternativa y que

consiste en eliminar requerimientos de la versión actual. Aparece en el mercado la versión 1

y con el paso del tiempo la 2 con los requerimientos que desechamos inicialmente y los

nuevos.

PROYECTO AVANZADO: CONTROL DE CAMBIOS DE LAS PRESTACIONES: Los

cambios cuando el proyecto está avanzado suelen surgir por diversos motivos:

• Usuarios finales: Que los deseen porque necesitan una funcionalidad adicional o

diferente.

• Vendedores: Si durante nuestro desarrollo aparecen nuevos productos con nuevas

prestaciones, los especialistas en marketing desearán evidentemente añadirlas en nuestro

producto.

• Desarrolladores: Desearán hacer modificaciones sobre todo se está construyendo una

segunda versión.

Todos estos grupos (Usuarios finales, Vendedores y Desarrolladores) intentarán poner

sus prestaciones favoritas en la especificación de los requerimientos.

PROYECTO A PUNTO DE TERMINAR: RECORTE DE PRESTACIONES: Al llegar al

final del proyecto, una de las mejores opciones para reducir la planificación es eliminar las

prestaciones de baja prioridad. Es un método muy utilizado en Microsoft para controlar

proyectos de SW atrasados.

El inconveniente es que puede ser que ya hayamos realizado el diseño y gran parte de la

implementación y comprobación de las prestaciones de lo que vamos a suprimir. Si tenemos

en mente sacar una nueva versión del mismo producto, esto no representa mucho problema

ya que lo más probable es que podamos utilizar el trabajo suprimido en la versión posterior.

DISCIPLINAS DE APOYO: GESTIÓN DE SEGURIDAD

Para comprender las dificultades que se derivan de la naturaleza de nuestro Producto, y

las diferencias que aparecen al compararlo con productos ordinarios (tangibles), están lo

que se conoce como Disciplinas de Apoyo.

Se suelen contemplar seis actividades o disciplinas de apoyo para poder alcanzar el éxito

en el desarrollo y utilización de los sistemas de información.

GESTIÓN DE LA SEGURIDAD: La seguridad y privacidad son otras de las áreas

complejas a tener en cuenta, los conceptos de la propiedad y el acceso a los datos forman

la columna vertebral para mantener el control en esta área difícil.

La Seguridad de los Datos y la Funcionalidad de los Sistemas

Una manera de empezar es dejando claro a quién pertenece cada dato y quién es

responsable de él.

La accesibilidad puede verse de dos formas: como el acceso a la operación de un sistema,

y como acceso a la información. En ambos casos tenemos que establecer los privilegios que

puede tener cada uno de los usuarios.

Un primer paso es que cada usuario tenga su Identificación y Contraseña (ID), una vez

que se identifica el sistema busca los derechos de acceso en una tabla. Separar el acceso a

la función del sistema por un lado y a la información que contiene por otro, es un paso

importante que en ocasiones no se tiene en cuenta y que debemos cuidar.

La Seguridad del Sistema Físico

Los riesgos físicos que entorpecen el funcionamiento seguro de una instalación son:

• Acceso físico irregular al edificio y todas la instalaciones con él relacionadas

(cableado, salas de comunicaciones, etc.).

• Acceso remoto no autorizado al SI, empleando el Sistema de Comunicaciones.

• Recursos informáticos como: documentación, soportes magnéticos etc. Almacenados

en lugares poco seguros.

• Incendios, inundaciones y caídas de tensión.

• Delitos cometidos por el personal.

• Falta de los planes adecuados para recuperar el Servicio.

Precauciones Básicas

Una forma simple de tratar lo que concierne a la seguridad es: mantener unos registros

complementarios y detallados de los accesos al sistema y de los acontecimientos singulares,

de esta forma los intentos de accesos no autorizados se pueden detectar de forma rápida.

La delincuencia entre el personal es más difícil de abordar, el primer paso debe ser

asegurarse de que todo el mundo conoce lo que está autorizado a hacer.

Otra amenaza que tenemos son los “virus” informáticos, que hay que detectar y eliminar.

La Recuperación del Servicio

Es preciso planificar la forma en que vamos a afrontar los problemas antes de que se

presenten, lo que suele hacerse mediante un Análisis formal de Riesgos.

Algunas medidas que facilitan la recuperación más rápida pueden ser:

• Adquirir locales alternativos e instalar equipos compatibles.

• Compartir esos locales con otras empresas que utilicen el mismo SW y tipo de

ordenador.

• Documentar los procedimientos de copia de Seguridad y de recuperación de Servicio y

ensayarlos de forma periódica, para garantizar su funcionamiento.

• Asegurar que todos los archivos, el SW de las Aplicaciones y el SO se copian de forma

periódica y se guardan en lugares seguros.

• Asignar a un único Supervisor o encargado la responsabilidad de la copias de

Seguridad y de la recuperación del Servicio.

Será preciso también evaluar cualquiera de las iniciativas en términos de Coste.

JAD: DESARROLLO CONJUNTO DE APLICACIONES

JAD (Joint Application Development, Desarrollo Conjunto de Aplicaciones) es un proceso

estructurado para la recopilación y negociación de los requisitos, consiste en una serie de

seminarios a los que asisten ejecutivos, usuarios finales y desarrolladores. JAD es uno de

los métodos más potentes y sofisticados para la especificación de requerimientos y nos

permite ahorrar esfuerzos y tiempo de las siguientes formas:

• Comprometiendo a los altos ejecutivos en el proceso de Planificación del SW.

• Reduciendo la fase de especificación de requisitos.

• Ayudando a obtener desde el principio de forma correcta los requisitos.

• Ayudando a obtener la Interfaz de Usuario a la primera.

• Reduciendo las disputas dentro del a Organización.

USO DE JAD: Consta de dos fases principales, una de Planificación y otra de Diseño.

Ambas fases trabajan con lo que se denomina tradicionalmente Requerimientos del

Sistema, pero a niveles diferentes.

Durante la primera fase (de Planificación), con JAD hacemos hincapié en la organización

de la posibilidades generales del sistema SW. El resultado principal de esta fase son los

objetivos del Sistema, las estimaciones preliminares del esfuerzo y la Planificación y la

Decisión sobre si continuamos desarrollando el producto.

Una vez tomada la decisión de seguir adelante, continuaremos con la fase de Diseño,

donde obtendremos requerimientos más detallados hasta llegar a un Diseño de SW a nivel

de Usuario, ya que el principal objetivo de esta fase es: El Diseño detallado de la Interfaz

de Usuario, un esquema de la Base de Datos (si se cree conveniente), y unas estimaciones

refinadas tanto de la Planificación como del Presupuesto.

Estas dos fases de que consta JAD están divididas en tres partes:

1. Personalización: El responsable de JAD lo adapta al proyecto específico. Tiempo

estimado de esta parte entre 1 – 10 días.

2. Sesión: Es el momento en que se reúnen todas las partes, y es el núcleo principal de

JAD. Dependiendo del tamaño del Sistema también se invierte entre 1 – 10 días.

3. Generación de la Documentación: Consiste en recoger o generar la información que se

ha obtenido en la sesión. Tiempo requerido entre 3 – 15 días.

Una vez que finalizamos la fase de Diseño JAD, pasamos tan rápido como sea posible a la

parte instrumental del Diseño del Programa y de la Construcción. En JAD no se imponen

ningún método de construcción, pero es especialmente compatible con los modelos de Ciclo

de Vida Incrementales y con el uso de Herramientas CASE.

Es igualmente aplicable a productos comerciales, SW de aplicaciones, SW de “pret – à –

porter” y SW de Sistemas.

CARACTERÍSTICAS:

1. Eficacia

• Reducción potencial de la planificación: Buena (10 – 20 %)

• Mejora en la visibilidad del progreso: Media (0 – 25 %)

• Efecto sobre el riesgo de planificación: Disminuye el riesgo.

• Posibilidad de éxito inicial: Buena (40 – 60 %)

• Posibilidad de éxito a largo plazo: Excelente (80 – 100 %)

2. Riesgos principales

• Previsiones de productividad poco realista después de las sesiones.

• Estimaciones incorrectas y prematuras del trabajo pendiente tras las sesiones.

3. Interacciones y equilibrios principales

• Funciona mejor cuando se combina con modelos de Desarrollo Incremental (ciclo de

vida en espiral, entrega evolutiva, prototipado evolutivo, entrega por etapas).

• Se puede combinar con Lenguajes de Desarrollo Rápido y Herramientas de

Prototipado.

Personalización Sesión Generación de

la documentación

PLANIFICACIÓN

Personalización Sesión Generación de

la documentación

DISEÑO

Promotor ejecutivo

Promotor ejecutivo

IMPLEMENTACIÓN

Revisar material

Revisar material

Revisar material

Aprobación

Aprobación