TGS: COMPONENTES EN COMÚN CON SISTEMAS … · • Sistemas basados en el conocimiento: Contienen...
Transcript of TGS: COMPONENTES EN COMÚN CON SISTEMAS … · • Sistemas basados en el conocimiento: Contienen...
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