lunes, 17 de noviembre de 2008

Video: Deposito de Autos Robotizado de Volkswagen

Prototipos

PROTOTIPOS

Un prototipo es una representación limitada del diseño de un producto que permite a las partes responsables de su creación experimentar, probarlo en situaciones reales y explorar su uso.

Un prototipo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo software.

Un prototipo es también un modelo a escala o facsímil de lo real, pero no tan funcional como para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final, proporcionando una retroalimentación temprana por parte de los usuarios acerca del sistema.

Los prototipos son una visión preliminar del sistema futuro que se implantara.

La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información especifica a cerca de los requerimientos de información de los usuarios.

Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos.

En esta forma el analista esta buscando las reacciones iniciales de los usuarios y de la administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisión que detallan que parte del sistema necesita realizarse primero.

Tipos de Información que busca el Analista durante la Elaboración de Prototipos.

• Reacciones del usuario.
• Innovaciones.
• Sugerencias del usuario.
• Plan de revisión.

Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactua con él.

Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema.

Sugerencias: El analista también esta interesado en las sugerencia de los usuarios y la administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo especifico.

El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e interés en el proyecto de sistemas. Las sugerencias son el producto de la interacción de los usuarios con el prototipo. Estas sugerencias deben apuntar ala analista hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios.

Innovaciones: Son parte de las informaciones buscada por el equipo de análisis de sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo.

Van más allá de las características prototipicas actuales añadiendo algo nuevo e innovador.

Plan de Revisión: Ayuda a identificar prioridades para lo que se debe construir un prototipo a continuación. En situaciones donde están involucradas muchas ramas de la organización, los planes de revisión ayuda a determinar para cuáles hay que construir un prototipo a continuación.

La información recolectada en la fase de hechedura del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de ruptura. La elaboración de prototipo y la planeación van mano a mano.




TIPOS DE PROTOTIPO

a) Prototipo Parchado: Es un sistema que tiene todas las características propuesta pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante.

b) Prototipo no Operacional: La segunda concepción de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño. Este puede ser hecha cuando la codificación requeridas por las aplicaciones es muy amplia para hacerce el prototipo y, sin embargo se puede obtener una idea útil del sistema por medio de la elaboración de prototipos de la entrada y salida solamente.

Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podría no ser realizado, sin embargo se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo.

c) Prototipo Primero de una Serie: Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto.

Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente.

d) Prototipo de Características Seleccionadas: Un prototipo de características seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior.

Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final.

Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta.

DESARROLLO DE UN PROTOTIPO

Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de problema esta siendo resuelto y en qué forma el sistema presenta la solución.

Lineamientos para el Desarrollo de un Prototipo.

1. Trabajar en módulos manejables.
2. Construir el prototipo rápidamente.
3. Modificar el prototipo en interacción sucesiva.
4. Enfatizar la interfaz del usuario.

Trabajar en Módulos Manejables: Es bueno que el analista en modelos manejables cuando se realiza el prototipo de algunas de las características de un sistema para obtener un modelo funcional.

Un modelo manejable es aquel que permite la interacción con sus características principales, pero todavía puede ser construido por separado de otros módulos del sistema. Las características del módulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial.

Construcción Rápido del Prototipo: La velocidad es esencial para la elaboración satisfactoria de un prototipo en un sistema. El prototipo ayuda a acortar el tiempo de la interacción del sistema con el usuario para que pueda empezar a experimentar con él.

Se usan técnicas de recolección de información tradicional tales como: entrevistas, las observaciones e investigaciones de datos de archivo.

La elaboración de un prototipo debe llevarse a cabo en una semana, para construir un prototipo tan rápidamente se deben de usar herramientas especiales tales como: Los sistemas de administración de las base de datos y software, existente que permitan la entrada y salida generalizada.

En esta etapa del ciclo de vida el analista sigue recopilando información acerca de lo que se necesita y quieren los usuarios del sistema.

El poner un prototipo operacional rápidamente junto a las primeras etapas del ciclo de vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera en que se debe realizar el resto del proyecto. De este modo se le va mostrando al usuario como actúan las partes del sistema.

Modificaciones del Prototipo: Un tercer lineamiento para el desarrollo del prototipo es que debe ser flexible para futura modificaciones. Esto significa crearlo en módulos que no sean muy interdependientes.

Por lo general el prototipo es modificados varias veces pasando a través de varias interacciones. Los cambios al prototipo deben mover al sistema más cerca a lo que los usuarios dicen que es importante.

Cada modificaciones necesitan otras evaluaciones de los usuarios, estas modificaciones se deben realizar velozmente en uno o dos días, esto depende también del usuario y que tan rápido sea su evaluación.

Enfatizar la Interfaz de Usuarios: La interfaz del usuario con el prototipo (y eventualmente con el sistema) es muy importante debido que lo que se esta tratando realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez más sus requerimientos de información, debe ser capas de interactuar fácilmente con el prototipo del sistema.

El objetivo del analista es diseñar una interfaz que permita al usuario interactuar con el sistema con un mínimo de entrenamiento y que permita el máximo de control del usuario sobre las funciones representadas.

DESVENTAGAS DE LOS PROTOTIPOS

1. Puede ser bastante difícil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema más grande.

2. Es que si un sistema es muy necesario y es bienvenido rápidamente , puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios. En este caso el prototipo no tendrá las funciones necesarias y eventualmente cuando se de cuenta de la deficiencias se puede desarrollar un rechazo del usuario.


VENTAJAS DE LOS PROTOTIPOS

1. Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboración de prototipos satisfactoria depende de la retroalimentacion temprana y frecuente de los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta más ágil a las necesidades actuales. Los cambios tempranos son menos caros que los cambios hechos posteriormente en le desarrollo del proyecto.

2. Desechado de Sistemas Indeseables: Una segunda ventaja del uso de prototipos como una técnica para la recopilación de información es la posibilidad de desechar un sistema que no es lo que los usuarios y analistas esperaban.

3. Diseño de un Sistema para las Necesidades y Expectativas de los Usuarios: Una tercera ventaja de la elaboración de prototipos es que el sistema que está siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los usuarios . Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas más de cerca.


Desventajas de la elaboración de Prototipos
• Es difícil manejar la elaboración de prototipos como un proyecto dentro de un esfuerzo de sistemas más grande.
• Los usuarios y analista pueden adoptar a un prototipo como un sistema terminado cuando es inadecuado.

Ventajas de la elaboración de prototipos
• Existe el potencial para hacer cambios en le sistema en las primeras etapas de su desarrollo.
• Existen oportunidades para detener el desarrollo de un sistema que no es funcional.
• Puede atacar necesidades de usuario y expectativas más cercanas.



PAPEL DEL USUARIO EN LOS PROTOTIPOS

Hay tres formas principales en que un usuario puede ser de ayuda en la elaboración del Prototipo.

1. Experimentando con el Prototipo.
2. Reaccionar abiertamente ante el Prototipo.
3. Sugiriendo adiciones y/o eliminaciones del prototipo.


Experimentando con el Prototipo: Los usuarios deben tener libertad para experimentar con el prototipo, y no una simple lista de características del sistema, el prototipo permite a los usuarios la realidad de la interacción real.

Los analista deben estar presente la mayor parte del tiempo en que se este experimentando con el prototipo.

Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organización, es poco probable que se de reacciones abiertas ante el prototipo. Una forma para aislarlos de influencias organizacionales no deseada es proporcionar un periodo privado, para que los usuarios interactúen con y respondan al prototipo.

El hacer que los usuarios se sienta lo suficientemente seguros para dar una reacción abierta es parte de la realización entre los analista y usuarios que el equipo tiene que construir.

Sugerencias de Cambios al Prototipo: Un tercer aspecto del papel de los usuarios en la elaboración de los prototipos es sugerir adiciones y/o eliminaciones a las características que se están probando. El papel del analista es deducir tales sugerencias, asegurando a los usuarios que tal retroalimentación que proporciona es tomada en serio, observando a los usuarios mientras interactúan y realizando entrevistas cortas y específicas en relación con su experiencia con el prototipo.

miércoles, 5 de noviembre de 2008

Descagar Guias!

Para descargar los archivos:
- Cliquear el link correpondiente.
- Cliquear Boton "Free User".
- Esperar el contador para que comienze a descargar.

Descagar Guia - Procesos, Diagrama de Flujo y Diccionario de Datos - Formato PDF (nueva)

Descargar Guía Modelos DRA y Evolutivos - Formato Microsoft Word

Desagar Presentacion - Formato Powerpoint

Procesos, Diagramas de Flujo de Datos y Diccionario de Datos

¿Qué es un proceso?

Un proceso es un conjunto de tareas relacionadas lógicamente llevadas a cabo
para lograr un resultado, cada proceso tiene sus entradas, funciones y salidas.
Componentes básicos de un proceso

  • Entrada (Datos Relevantes).
  • Proceso (Tareas Realizadas).
  • Salida (Resultados).


No se concibe un proceso sin un objetivo, ya sea un bien o servicio producto, ni
ese resultado no asociado a un cliente que tiene una necesidad por satisfacer.
¿Qué es análisis de Procesos?
Se refiere a la aplicación de métodos científicos al reconocimiento y definición de
problemas, así como al desarrollo de procedimientos para su solución. En una forma
más concreta esto quiere decir:

  • Especificación matemática del problema para la situación física dada.
  • Análisis detallado para obtener modelos matemáticos
  • Síntesis y presentación de resultados para asegurar la total comprensión

Determinación de procesos:
  • ¿Cuáles son las principales actividades que se realizan en la organización?
  • Descripción de cada proceso identificado
  • ¿Qué es lo que da inicio a la actividad?
  • ¿Cuál es el objetivo de la misma?
  • ¿Cuánto tiempo se tarda en realizarla?
  • ¿Qué retrasos ocurren o pueden ocurrir?
  • ¿Qué métodos se emplean para medir y evaluar el desempeño de esta actividad?
  • ¿Se toman precauciones específicas de seguridad para la protección contra alguna actividad impropia que se pudiera presentar?
  • ¿Qué tan frecuente es el ciclo con el que se desarrolla dicha actividad?
  • De acuerdo al ciclo con el que se presenta la actividad, ¿Cuál es el volumen de información que aquí se procesa?
  • ¿Qué pasos, sub−procesos, o funciones constituyen la actividad? (describir la actividad paso a paso)
  • ¿Existe algún tipo de control desarrollado en el proceso en cuestión?
Determinación de datos (flujos y contenido de los flujos)
  • ¿De dónde proviene la información que se utiliza en esta actividad? (fuentes)
  • ¿Cuáles son específicamente los datos que recibe esta actividad?
  • ¿De qué manera ingresan a este proceso? (flujos)
  • ¿Qué tablas de referencia y diagramas u otros datos intervienen en la actividad?(documentación involucrada)
  • ¿Qué información se genera en esta actividad? (producto de la actividad)
  • ¿Con qué finalidad la utilizan?
  • ¿Cuáles datos se conservan o almacenan en este proceso?
  • ¿En qué forma quedan almacenados?
  • ¿Existe información que se genera pero que no es utilizada nunca por nadie? (partes extrañas)
Para cada dato identificado:
  • ¿Qué formato posee cada dato que interviene en esta actividad?
  • ¿Para qué es usado?
  • ¿Se interpone algún tipo de seguridad para la verificación de la veracidad del dato en mención?
  • ¿Qué tan importante es dicho dato?
  • ¿Por cuánto tiempo es importante mantener el dato en el sistema?

¿Por qué es importante el análisis de proceso?

Si no analizas, es muy probable que construyas una solución muy elegante que
resuelva incorrectamente el problema. El resultado es tiempo y dinero perdido,
frustración personal y clientes descontentos.

¿Cómo podemos asegurarnos que hemos realizado un buen análisis que reconoce
las necesidades del cliente y satisface sus expectativas?

No hay una respuesta segura para esa difícil pregunta, pero un sólido proceso de
ingeniería de requerimientos es la mejor solución que disponemos actualmente.
Norma ISO 9001
Es un método de trabajo, que se considera tan bueno, Que es el mejor para
mejorar la calidad y satisfacción de cara al consumidor. La versión actual, es del año
2000 ISO 9001:2000, que ha sido adoptada como modelo a seguir para obtener la
certificación de calidad. Y es a lo que tiende, y debe de aspirar toda empresa
competitiva, que quiera permanecer y sobrevivir en el exigente mercado actual.
Estos principios básicos de la gestión de la calidad, son reglas de carácter social
encaminadas a mejorar la marcha y funcionamiento de una organización mediante la
mejora de sus relaciones internas. Estas normas, han de combinarse con los principios
técnicos para conseguir una mejora de la satisfacción del consumidor.

Cuáles son los Requisitos generales

1. Identificar todos los procesos necesarios para el Sistema de Gestión de la
Calidad.
2. Determinar la secuencia e interacción de estos procesos.
3. Determinar los criterios y métodos para asegurar que la operación y el control de
estos procesos sea eficaz.
4. Asegurarse de la existencia de recursos e información necesarios para apoyar la
operación y el seguimiento de estos procesos.
5. Realizar el seguimiento, la medición y el análisis de esos procesos.
6. Diseñar las acciones necesarias para alcanzar los resultados planificados y la
mejora continua de estos procesos.

Qué documentación debe crearse

1. Los Procedimientos e instrucciones.
2. Declaraciones de la Política de la Calidad y Objetivos de la Calidad.
3. Manual de la Calidad de la empresa.
4. Los Procedimientos requeridos en esta Norma.
5. Los Documentos necesarios para asegurar la planificación, la operación y el
control de los procesos.
6. Los Registros requeridos por esta Norma.

Política de la Calidad
La dirección debe asegurar que la política cumpla con los requisitos solicitados
por la entidad certificadora.
Planificación

  • Objetivos de la Calidad
La dirección debe establecer sus objetivos de Calidad que sean medibles,
cuantificables y consistentes con la política de Calidad

  • Planificación del Sistema de Gestión de la Calidad
La dirección debe asegurar que:
1. Se planea la implantación del Sistema de Gestión de Calidad
2. Se planean los cambios al sistema de Gestión de Calidad
3. Debemos asegurar que el proceso de planeación y transición del
Sistema se lleve de Acuerdo a lo planeado

Las normas se revisan periódicamente. Se dice que actualmente la ISO 9001: 2008 está
muy avanzada. Y que incluye muy pocos cambios con respecto a la versión del 2000; el
primer borrador oficial se publicará a principios de octubre de 2008, y se dice también
que no saldrá la versión definitiva hasta mediados de 2009.

¿Qué es Seis Sigma?

Sigma (σ) es una letra del alfabeto griego que corresponde a la letra “s”, la cual
también es utilizada en estadística para representar la desviación estándar 6
corresponde al ancho de banda de una distribución normal. Seis Sigma es la medición
de defectos por cada millón de operaciones, se aplica a todas las transacciones. Mientras
más bajo sea el número de errores, mayor será la calidad.
Beneficios.

1. Alineamiento entre los resultados y la eficacia: la mejora de la calidad de un
proceso implica aumento de la rentabilidad para la empresa.
2. Aplicación de la metodología en diversas áreas de la empresa: finanzas,
logística, ventas, sistemas, administración, etc., no restringiendo los trabajos a
las áreas productivas de la empresa.
3. Posibilidad de toma de decisiones basadas en datos estadísticos.
4. Desarrollo de una sistemática que promueva el vínculo entre planeamiento
estratégico y herramientas estadísticas y de calidad
Fases de Implementación

El Enfoque de Seis Sigma esta basado en 6 fases que son:
  • Definición
  • Medición
  • Análisis
  • Mejora (en ingles improvement)
  • Control

En esencia estos pasos suponen definir, medir, analizar con la finalidad de
descubrir las causas raíz del problema y después mejorar y controlarlo para impedir queel problema se presente de nuevo.

Diagrama de Flujo de Datos

Definición:

El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías,
los procesos que cambian o transforman los datos en un sistema, las entidades externas
que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los
almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo
así describir el movimiento de los datos a través del sistema.

En síntesis, el Diagrama de Flujo de Datos describe:
  • Los lugares de origen y destino de los datos (los límites del sistema),
  • Las transformaciones a las que son sometidos los datos (los procesos internos),
  • Los lugares en los que se almacenan los datos dentro del sistema, y
  • Los canales por donde circulan los datos.
Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales
son:

  • Nivel 0: Diagrama de contexto.
  • Nivel 1: Diagrama de nivel superior.
  • Nivel 2: Diagrama de detalle o expansión.
Características de los niveles:

Diagrama de Contexto: Nivel 0
En el diagrama de contexto solo se dibuja el proceso principal y los flujos entre
este y sus entidades externas.

Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al
proceso principal. En este nivel los procesos no pueden interrelacionarse directamente,
sino que entre ellos siempre debe existir algún almacenamiento o entidad externa que
los una.

Diagrama de Detalle o Expansión: Nivel 2
A partir del nivel 2 de detalle, los procesos pueden interrelacionarse
directamente, sin necesidad de almacenamiento que los una. Cabe destacar que en el
nivel 1 y 2 siempre los procesos deben tener las entradas y las salidas dadas en el
diagrama de contexto.

Características:
  • Relevante: Ya que posibilita comunicar diferentes modelos para así facilitar el
  • entendimiento entre el usuario y el analista de sistemas.
  • Lógico: Ya que no identifica soporte físico.
  • Descendente: Se construye en forma descendente, de lo general a lo particular.
Simbología:

Entidad externa:
Son generalmente clases lógicas de cosas o de personas, las cuales representan
una fuente o destino de transacciones, como por ejemplo clientes, empleados,
proveedores, etc., con las que el sistema se comunica.
También pueden ser una fuente o
destino específico, como por ejemplo Departamento Contable.
Como el sistema que está bajo análisis acepta datos de otro sistema o bien se los
provee, este otro sistema es una Entidad Externa.
Mediante la designación de alguna cosa o de algún sistema como Entidad
Externa estamos estableciendo implícitamente que se encuentra fuera de los límites del
sistema que estamos considerando por lo cual no nos interesa la transformación o
proceso que se realiza dentro de ellos, es decir que están fuera del control del sistema
que se está modelando. Son sólo proveedores o requeridores de datos del sistema bajo
consideración.
Por todo ello, ni el analista ni el diseñador pueden cambiar ni los contenidos ni
la forma de trabajo de un terminador.

Proceso:

Indican aquellos lugares dentro del sistema en donde la información (flujos de
datos) que ingresan se procesan o transforman. Es decir, son las funciones o procesos
que transforman entradas de datos en salidas de información.
Su nombre deberá ponerse mediante una frase imperativa, que consistirá
idealmente de un verbo activo seguido por una cláusula objeto, cuanto más simple
mejor. Al analista le servirá pensar que la descripción de la función es "una orden a un
empleado sin conocimiento del tema". Estas frases imperativas no tienen sujeto; tan
pronto como se introduce un sujeto se habrá indicado como deberá realizarse
físicamente la función ("El operador ingresará los datos del alumno").
Un proceso puede ser físicamente una oficina repleta de empleados, un
procedimiento, o una combinación de actividades manuales y automatizadas.

Flujo de datos:

Representa un transporte de paquetes de datos desde su origen hasta su destino,
es decir que representa una estructura de datos en movimiento de una parte del sistema a
otro.
Un flujo muestra las interfaces entre los elementos del DFD.
Puede imaginarse como una tubería por donde se envían paquetes de datos, pero
deberá tener una descripción de su contenido la cual deberá elegirse de forma que sea lo
más útil posible a los usuarios que revisen el DFD.
La flecha indica la dirección del flujo.
Puede estar contenido físicamente en una nota, una factura, una llamada
telefónica, de programa a programa, etc. Es decir, en cualquier medio por el cual los
datos pasan de una entidad o proceso a otra.

Almacén o archivo:

Representa un archivo lógico en donde se agregan o de donde se extraen datos.
Es una estructura de datos, pero estática.
Puede ser físicamente un archivo de tarjetas, una microficha, un archivo, o un
archivo en cinta o diskette.
Deberá elegirse el nombre que sea más descriptivo para el usuario, que
identifique los paquetes de datos que contiene.
Implica escritura, actualización o borrado de datos.
Implica lectura o recuperación de información almacenada.


Guías para construir un DFD:

1. Primero se deberán identificar las entidades externas ya que ello implica definir
los límites del sistema.
2. Se deberán elegir nombres con significado tanto para procesos como también
para flujos de datos, almacenes y entidades externas. Si es posible a partir del
vocabulario del usuario evitando terminologías técnicas.
3. Identificar el papel del proceso del sistema, no quien lo realiza.
4. Numerar los procesos, mediante un esquema de numeración consistente que
implique, para los lectores del DFD, una cierta secuencia de ejecución.
5. Se deberán, en la medida de lo posible, evitar los DFD excesivamente complejos.
Deberán ser comprensibles, digeribles y agradables a la vista sin demasiados elementos.
6. Todos los elementos se relacionan entre sí a través de flujos de datos.
7. Procesos: Se relacionarán con:
• Almacenes
• Entidades externas
• Otros procesos
• Deberán tener al menos una Entrada y una Salida, no son manantiales de
datos.

8. Almacenes: Se relacionarán solamente con Procesos.
9. Entidades Externas: Se relacionarán solamente con Procesos.
10. En todos los niveles del Diagrama de Flujo de Datos deberá haber igual cantidad
de Entradas y de Salidas.

11. Niveles del DFD:

Nivel de Partida: Diagrama de Contexto:
• No existirán almacenes o archivos.
• Se representarán las entidades externas que son fuente y destino de los
datos.
• El sistema será representado como un proceso simple.
• Se dibujarán sólo los flujos de datos de comunicación exterior-sistema.
Nivel 1 y subsiguientes:
• Deberá haber igual cantidad de archivos. Aunque podrá existir mayor
cantidad de almacenamientos en el nivel 2 debido a la explosión de algún
proceso.
• En el último nivel, cada proceso realizará una función específica y
concreta.
12. Cada proceso en el DFD de alto nivel de un sistema puede ser "explotado"
para convertirse en un DFD en sí mismo.
13. Cada proceso en el nivel inferior deberá estar relacionado, inversamente, con
el proceso del nivel superior. Es decir que, cada proceso “padre” que se detalla en el
DFD, ha de estar balanceado. La regla del balanceo consiste en que cada proceso debe
tener exactamente los mismos datos de entrada/salida netos que el DFD hijo.
14. Los flujos de datos pueden descomponerse en la “explosión” del proceso en
un DFD hijo.
15. No se deberá prestar atención a las condiciones de tiempo, excepto a las
naturales precedencias lógicas y a los almacenamientos de datos necesarios desde el
punto de vista lógico. Se deberá dibujar un sistema que nunca comience ni pare.
16. Para evitar el cruzamiento de las líneas de flujo de datos, la misma entidad (o
el mismo almacén) se podrá dibujar más de una vez en el mismo diagrama; las dos (o
más) casillas por entidad pueden identificarse con dos líneas inclinadas en el ángulo
superior izquierdo de las mismas.

Tipos de diagramas de flujo de datos.

1. Diagramas físicos de flujo de datos: Proporcionan un panorama del sistema en uso,
muestra las tareas que se llevan a cabo y como se hacen.
2. Diagramas lógicos de flujo de datos: Proporcionan un panorama del sistema
independiente de la implantación, que se centra en el flujo de datos entre los procesos
sin considerar los dispositivos específicos y la localización de almacenes de datos o
personas en el sistema.

Diccionario de datos
Definición
Un Diccionario de datos (DD) es un catalogo en el cual se describe todos los
elementos de un sistema (flujo de datos, procesos y almacenes de datos). Dicho
diccionario debe ser actualizado cada vez que se realiza un cambio. En un DD se
encuentran las características lógicas de los sitios donde se almacenan los datos del
sistema, incluyendo nombre, descripción, alias, contenidos y organización. También
identifica los procesos donde se emplean los datos
Importancia
El objetivo de un diccionario de datos es dar precisión sobre los datos que se
manejan en un sistema, evitando así malas interpretaciones o ambigüedades.
Los analistas de datos utilizan los diccionarios de datos principalmente por las
siguientes razones:
  • Permite manejar detalles
  • Comunicar un significado común para todos los elementos del sistema
  • Facilitar el análisis de los detalles
  • Localizar Errores
Contenido de un D.D.

El diccionario de datos contiene dos tipos de descripciones para el flujo de datos
dentro del sistema: elementos de datos y estructuras de datos.
Elemento dato: Describe el significado de los datos, definiendo valores como: nombre,
tipo de elemento, descripción, sinónimos, observaciones.
Estructuras de datos: Describe el agrupamiento de los datos, definiendo relaciones
entre componentes.

Notación empleada

Símbolo Significado Explicación Uso
= es equivalente a Alias Denota
sinónimos
+ y Concatenación
Denota una
relación de
secuencia
[ ] , | uno u otro
Define opciones entre los
componentes de una
estructura de datos
Denota una
relación de
selección
{ } iteraciones de
Define repetición de un
componente en una
estructura de datos
Denota una
relación de
iteración
( ) opcional Define iteraciones que
ocurren 0/1 vez
Denota una
relación
opcional
*…* Comentario Descripción
complementaria
Denota
información
adicional
< > Al menos uno
Define opciones entre los
componentes de una
estructura de datos
Al menos una de
las opciones

Ejemplo
– Nombre = TituloCortesia+NombrePila+Apellido
– TituloCortesia = [“Sr” | “Sra”]
– NombrePila =
– Apellido =
– Carácter = [ “A”-”Z”|”a”-”z” ]

viernes, 31 de octubre de 2008


DETERMINACION DE LOS REQUERIMIENTOS
Es el estudio del sistema para conocer como trabaja y donde es necesario
efectuar mejoras. El primer paso del Analista es comprender la situación y conocer
como funcionan los métodos actuales o si son necesarios o posibles algunos
ajustes en relación con los sistemas manuales y los computarizados.


Requerimientos

Es una característica que debe incluirse en un nuevo sistema. Esta puede incluir
una determinada forma para capturar o procesar datos. Producir información
controlar una actividad de la empresa o brindar soporte a la gerencia.

Requerimientos Básicos:

Los Analistas estructuran su investigación al buscar respuestas a las siguientes
cuatro importantes preguntas:


1.- ¿Cuál es el proceso básico de la empresa?
2.- ¿Qué datos utiliza o produce este proceso?
3.- ¿Cuáles son los límites impuestos de tiempo y de carga de trabajo?
4.- ¿Qué controles de desempeño utiliza?

EJEMPLO DE REQUERIMIENTOS

El punto clave de análisis de sistemas se consigue al adquirir un conocimiento
detallado de todas las facetas importantes dentro del area de negocios que se
investiga. (Por esta razón, a menudo esta actividad se conoce como investigación
detallada). Los analistas, al trabajar con los empleados y gerentes, deben estudiar
el proceso que actualmente se efectua para contestar estas preguntas clave:


1. ¿Que se esta haciendo?
2. ¿Cómo se esta haciendo?
3. ¿Qué tan frecuentemente ocurre?
4. ¿ue tan grande es la cantidad de transacciones o decisiones?
5. ¿Qué tan bien se lleva acabo la tarea?
6. ¿Existe algún problema?
7. ¿Si el problema existe, que tan serio es?


TECNICAS PARA EL LEVANTAMIENTO DE DATOS

1.- Entrevista
2.- Cuestionario
3.- Revisión de Registro
4.- Observación

Entrevista:

La entrevista se utiliza para recabar información en forma verbal, a través
de preguntas que propone el analista, quien responde puede ser gerentes o
empleados, los cuales son usuarios actuales del sistema existente.
La entrevista se inicia con una cita.
La entrevista se puede clasificar en estructurada o no estructurada:

- Entrevista Estructurada:

los analistas necesitan adquirir datos más específicos sobre las operaciones y asegurar una alta confiabilidad en lasrespuestas a las preguntas que han propuesto a su entrevistado.
Utilizan preguntas estándares en formato de respuesta.

- Entrevista No Estructurada:

utilizan formato pregunta respuesta y sonapropiados cuando el analista desea adquirir información general de un sistema. Este formato anima a los entrevistados a compartir ideas,
sentimientos y creencias.

Ventajas y desventajas de las entrevistas Estructuradas y no Estructuradas:

Entrevista Estructurada:


Ventajas:
- Asegura la elaboración
uniforme de la preguntas

para todos los que van a
responder.
- Fácil de administrar y de
evaluar.
- Evaluación más objetiva
tanto de quienes responden
como de las respuestas a
las preguntas.
- Se necesita un limitado
entrenamiento del
entrevistador.
- Resulta en entrevistas más
pequeñas.


Desventajas:
-Alto costo de preparación.
- Los que responden pueden
no aceptar un alto nivel en
la estructura y carácter
mecánico de las preguntas.
- Un alto nivel de la
estructura puede no ser
adecuado para todas las
situaciones.
- El alto nivel en la estructura
reduce responder en forma
espontánea, así como la
habilidad del entrevistador
para continuar con
comentarios hacia el
entrevistado.

Entrevista no Estructurada:

Ventajas:
- El entrevistador tiene
mayor flexibilidad
realizar las preguntas
adecuadas a quienes
responden.
- El entrevistador puede
explorar áreas que
surgen espontáneamente
durante la entrevista.
- Puede producir
información sobre
áreas que se
minimizaron o en las
que no se pensó que
fueran importantes.
entrevistado.

Desventajas:
- Puede utilizarse
negativamente el
tiempo tanto de quien
responde como del
entrevistador.
- Los entrevistados
pueden introducir sus
dudas en las preguntas
o al informar de los
resultados.
- El análisis e
interpretación de los
resultados pueden ser
largos.
- Toma tiempo entre
recabar los hechos
esenciales.

Cuestionarios:
Los cuestionarios proporcionan una alternativa muy útil de relacionar la
información proveniente de varios aspectos de sistema en un grupo grande de
personas. El empleo de formatos estándares para las preguntas puede
proporcionar datos mas confiables. Este método no permite al analista observar
las expresiones reacciones de los encuestados.
Existen dos formas de cuestionario para recabar datos:

1.- Cuestionarios Abiertos:
se aplica cuando se requieren conocer los
sentimientos, opiniones y expresiones generales, son útiles cuando se quiere
explorar el problema básico, proporcionan una amplia posibilidad para quienes
responden.

2.- Cuestionarios Cerrados:
Limita las respuestas posibles del interrogado por
medio de cuidadoso estilo de preguntas el analista puede controlar el marco de
referencia. es el mejor método para obtener información sobre hechos.

Revisión de Registros:
Varios tipos de registros y de reportes pueden proporcionar al analista
información valiosa con aspecto a las organizaciones y sus operaciones. Al revisar
los registros, el analista examina la información asentado en ellos relacionada con
el sistema y los usuarios. La revisión puede efectuarse al comienzo del estudio o
también después, y sirve de base para comparar las operaciones actuales por lo
tanto los registros pueden indicar que esta sucediendo. Los registros incluyen
manuales de políticas, reglamentos y procedimientos estándares de operación
utilizando por la mayor parte de las organizaciones como guía para los gerentes y
empleados.

Observación:
Permite al analista ganar información que no se puede obtener con las
técnicas. Por medio de la observación el analista obtiene información de primera
mano sobre la forma en que se efectúan las operaciones o las actividades. El
método es útil cuando el analista necesita observar por un lado la forma en que se
maneja los documentos y se llevan a cabo los procesos y por el otro, si se siguen
todos los pasos específicos.

jueves, 30 de octubre de 2008

CICLO DE VIDA CLASICO DEL DESARROLLO DE SISTEMAS

El ciclo de vida del desarrollo de sistemas es el conjunto de actividades de los analistas, diseñadores y usuarios, que necesitan llevarse a cabo para desarrollar y poner en marcha un sistema de información.
El ciclo de vida del desarrollo de sistemas consiste en las siguientes actividades:

INVESTIGACIÓN PRELIMINAR
Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigación preliminar. Esta actividad tiene tres partes: aclaración de la solicitud, estudio de factibilidad y aprobación de la solicitud.

• Aclaración de la solicitud.
Muchas solicitudes que provienen de empleados y usuarios, no están formuladas de manera clara. Por consiguiente, antes de considerar cualquier aclaración de sistemas, la solicitud de proyecto, debe examinarse para determinar con precisión lo que el solicitante desea. Si éste tiene una buena idea de lo que necesita, pero no esta seguro, como expresarlo, entonces bastará con hacer una llamada telefónica.
Por otro lado, si el solicitante pide ayuda sin saber, que es lo que esta mal o donde se encuentra el problema, la aclaración del mismo se vuelve más difícil. En cualquier caso, antes de seguir adelante, la solicitud del proyecto debe estar claramente planteada.

• Estudio de Factibilidad
Un resultado importante de la investigación preliminar es la determinación de que el sistema requerido es factible. Existen tres aspectos en el estudio de factibilidad de la investigación preliminar:
Factibilidad técnica: El trabajo para el proyecto, ¿puede realizarse en el equipo actual, la tecnología existente del software y el personal disponible? Si se necesita nueva tecnología ¿cuál es la posibilidad de desarrollarla?
Factibilidad económica: Al crear el sistema, ¿los beneficios que se obtienen serán suficientes para aceptar los costos?, ¿los costos asociados con la decisión de no crear el sistema son tan grandes que se debe aceptar el proyecto?
Factibilidad operacional: Si se desarrolla e implanta, ¿será utilizado el sistema?, ¿existirá cierta resistencia al cambio por parte de los usuarios que de cómo resultado una disminución de los posibles beneficios de la aplicación?

• Aprobación de la solicitud
No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender unas cuantas.
Sin embargo, aquellos proyectos que son deseables o factibles deben incorporarse en los planes, en algunos casos, el desarrollo puede comenzar inmediatamente, aunque lo común es que los miembros de equipos de sistemas se encuentran ocupados en otros proyectos. Cuando esto ocurre, la administración decide que proyectos son los más importantes y decide el orden en que se llevara a cabo, muchas organizaciones desarrollan sus planes para sistemas de información con el mismo cuidado con los que clarifican nuevos productos y programas de la fabricación o la expansión de sus instalaciones.
Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades del personal: con esta información se determina donde ubicarlo dentro una lista de proyectos que existen de proyectos.

DETERMINACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA.

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la empresa que se encuentra bajo estudio. Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que tendrá el nuevo sistema, incluyendo la información que el sistema debe producir y las características operativas, como son controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.
Aquí determinaremos que es lo que requiere el sistema.

Investigación de datos de mayor importancia.
Entrevistas y cuestionarios.
Creación de prototipos.
Formularios.

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (Es por esta razón que el proceso de adquirir información se denomina, con frecuencia, Investigación detallada). Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas:

• ¿Qué es lo que hace?
• ¿Cómo se hace?
• ¿Con qué frecuencia se presenta?
• ¿Qué tan grande es el volumen de transacciones o de decisiones?
• ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
• ¿Existe algún problema?
• Si existe un problema. ¿Qué tan serio es?
• Si existe un problema. ¿Cuál es la causa de lo que origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre porque ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se emplea cuestionarios para obtener esta información cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organización.
Así mismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observación en condiciones reales de las actividades de trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad.
La determinación de los requerimientos de una aplicación es tan importante para el método de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.
Aplicar el método de resolución de problemas. Método clásico: Identificación del problema, comprender el contexto del problema, causas y efectos del mismo, solución deseada, soluciones alternativas, elegir la mejor solución, implantar la solución, evaluar el impacto de la solución.

Se debe realizar un levantamiento completo de requerimientos teniendo en cuenta el Flujo de la Información con que se trabaja en la organización o las áreas que se desea sistematizar mediante un SIG. Se debe documentar el proceso mediante Diagrama de Flujo de Datos.
Cuál es la información y los datos que usan y generan en la organización para desarrollar sus funciones?
Qué sistemas se encuentran en funcionamiento en la organización?
Cuáles son los productos esperados del sistema?
Se debe conocer cuales son los productos esperados del sistema dependiendo del tipo de usuario. Se deben establecer prioridades respecto a los productos.

Cuáles es el alcance del sistema?
Se debe identificar si el alcance es local, regional, nacional o global. El nivel define la escala o resolución de los datos necesarios para alimentar el sistema.


DISEÑO DEL SISTEMA.
El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo de software, a la que denominan diseño físico.
Aquí es donde el analista debe entender que información necesitan los usuarios finales para realizar correctamente sus trabajos

Por ejemplo: un sistema de creación de boletas... el analista tendrá que comprender que cada boleta tiene:

Hora de emisión, fecha de emisión, número de boleta, descripción del negocio, teléfono, etc.

Finalmente para poder comprender las funciones actuales del sistema debemos realizarnos una serie de preguntas:

¿Qué personas están involucradas?
¿Qué actividad desarrolla el negocio?
¿En que ambiente se realiza el trabajo?
¿Cuando, en que momento?
¿De que forma se desarrollan los procedimientos actualmente implementados?
¿Por qué el negocio usa el sistema actual?

Ya dando por finalizado esta 2º parte investigativa tendremos que comprender las funciones del negocio, tener información acerca de los operadores y trabajadores, tener claro el objetivo que se quiere lograr y mediante que procedimientos llegaremos a este objetivo tan anelado.

Diseño Detallado. Se divide en:
Diseño Externo. (Conjunto de especificaciones de la interfaz del sistema con sus usuarios incluyen entradas, consultas, salidas, diseño de ventanas y transición entre ventanas.
Diseño Interno. Especificaciones de aplicación del sistema, los archivos, diseño de la base de datos.
“En esta etapa es necesario elaborar un modelo de datos que estructure el SIG, definir la verificación y control de calidad de los datos, seleccionar las capas de información por áreas de trabajo, estructurar la base de datos espacial y temática y concretar todos los procesos que soportará el SIG. Igualmente en ésta etapa se definen los programas y equipos para el SIG, de tal manera que satisfagan los requerimientos para producción de mapas, datos tabulares y procesamiento digital de imágenes”.
El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los procedimientos de cálculo y los datos individuales. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnéticas o incluso archivos en papel.
Los documentos que contienen las especificaciones de diseño representan a éste de muchas maneras (diagramas, tablas y símbolos especiales). La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software.
Los diseñadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseño.


DISEÑO POR PLANIFICACIÓN
Es similar al modelo de entrega por etapas y es útil cuando el proyecto tiene un plazo concreto. Este modelo se utiliza cuando no se conoce si el producto se tendrá para la última entrega.
A diferencia del modelo de entrega por etapas, estas están ordenadas por orden de prioridad, así que la fecha tope aunque no hayamos terminado el proyecto estamos seguros de haber cubierto las funcionalidades más importantes.

DESARROLLO DE SOFTWARE.
Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseñados a la medida del solicitante.
La elección depende del Costo de cada alternativa.
El tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por esta regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. En empresas pequeñas, donde no hay programadores, se pueden contratar servicios externos de programación.

Los programadores también son responsables de la documentación de los programas y de proporcionar una explicación de cómo y por qué ciertos procedimientos se codifican en determinada forma. La documentación es esencial para probar el programa y llevar acabo el mantenimiento una vez que la aplicación se encuentra instalada.

PRUEBA DE LOS SISTEMAS.
Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funcione de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organización implante el sistema y dependa de él.
En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea más confiable.

Tres medios instrumentales de minimizar los riesgos de la tecnología son la verificación, prueba y mantenimiento de los sistemas. Cada componente de un sistema de cómputo -equipo, comunicaciones y programas- debe ser verificado y probado rigurosamente:

La prueba de los sistemas es usualmente más detallada y rigurosa que la verificación. Se requiere para asegurar que cada componente del sistema esté en operación como debe y que el sistema en su conjunto se desempeñe exactamente de acuerdo con los requerimientos locales específicos.
Para un sistema importante, como el de votación electrónica, un programa estructurado de prueba constituye un medio para asegurar que todos sus componentes sean evaluados. Las medidas de prueba que se pueden seguir incluyen:

• Desarrollar un conjunto de criterios para la prueba.
• Examinar todos los códigos no estandarizados para garantizar su lógica y que se hayan seguido los estándares debidos de diseño y construcción.
• Aplicar pruebas "no operativas" para asegurar que el equipo puede tolerar los niveles de manejo físico esperado.
• Aplicar pruebas funcionales para determinar si se han satisfecho los criterios de prueba.
• Aplicar evaluaciones de calidad para determinar si se han satisfecho los criterios de prueba.
• Conducir pruebas durante un periodo prolongado, para cerciorarse que los sistemas pueden funcionar de manera consistente.



IMPLANTACIÓN Y EVALUACIÓN.

En este proceso lo que se realiza es llevar acabo estudios de los pro y contras de establecer un sistema nuevo, generalmente se manejan los dos sistemas a la par (el viejo y el a implementar), nunca se desligan, la idea de trabajar simultáneamente es que se pueda ver los problemas que puedan surgir, se crea una especie de ambiente para que el sistema nuevo sea probado por los usuarios, en este momento se vera si es amigable, interfaz, y eficacia.

Los desarrolladores dejan siempre abierta la posibilidad de mejorar lo ya planteado, todo varia de acuerdo a las necesidades de la empresa y el diseño del sw, permanecen en constante evolución por el incremento de nuevas plataformas y tecnologías.

la evolución de un sistema se lleva a cabo para identificar puntos débiles y fuertes, la evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones.

• Evaluación operacional
• Impacto organizacional
• Opinión de los administradores
• Desempeño del desarrollo
Mientras existan mejoras de sw los sistemas debe evolucionar, de esta manera se actualizan las herramientas y no se hacen obsoletas las aplicaciones.

martes, 28 de octubre de 2008

Video - Modelo Desarrollo de Software utilizado por Google: SCRUM

Video - Ciclos de vida y la rigidez de algunas metodologias

Modelo Concurrente


Como el modelo espiral, el modelo concurrente provee una meta-descripción del Proceso software. Mientras que la contribución primaria del modelo espiral es en Realidad que esas actividades del software ocurran repetidamente, la contribución Del modelo concurrente es su capacidad de describir las múltiples actividades del Software ocurriendo simultáneamente.

Esto no sorprende a nadie que ha estado involucrado con las diversas actividades Que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos Un poco tales casos:


Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también).


Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.

Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.

En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo manutención de la etapa 1 de un producto, y al mismo tiempo estar haciendo manutención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.


En todos estos casos, diversas actividades están ocurriendo simultáneamente.

Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.


En vez de confinar las actividades de ingeniería de software a una secuencia de pasos, define una red de actividades.


Todas las actividades de la red existen simultáneamente con otras.


Los sucesos generados dentro de una actividad, o en algún otro lado de la red de actividad, inician las transiciones entre los estados de otra actividad.


Ventajas: excelente para proyectos en los que se conforman grupos de trabajo independientes.


Desventajas: Si no se dan las condiciones señaladas no es aplicable

martes, 21 de octubre de 2008

Descargar Guia y Presentacion - Modelos DRA y Evolutivos

Para descargar los archivos:
- Cliquear el link correpondiente.
- Cliquear Boton "Free User".
- Esperar el contador para que comienze a descargar.

Descargar Guía - Formato Microsoft Word

Desagar Presentacion - Formato Powerpoint

Modelo de Desarrollo Concurrente


La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo.

Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis.

Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/ servidor".

Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones:

Una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso.

En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

La concurrencia se logra de dos formas: (1) las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos; (2) una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

El modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.

Modelo espiral WinWin (Victoria- Victoria)


El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:
- Identificación del sistema o subsistemas clave de los directivos.
- Determinación de las condiciones de victoria de los directivos.
- Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.

Desarrollo en Espiral



El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle anterior.

Para cada actividad habrá cuatro tareas:
I- Planficación: Determinar o fijar objetivos
* Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
* Fijar las restricciones.
* Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
* Hay una cosa que solo se hace una vez: planificación inicial o previa.
II- Análisis del riesgo
* Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
III- Ingenería: Desarrollar, verificar y validar (probar)
* Tareas de la actividad propia y de prueba.
* Análisis de alternativas e identificación resolución de riesgos.
* Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.
IV- Evaluación del Cliente
* Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes. Planificamos la próxima actividad en case de ser necesaria una nueva iteración.

- Mecanismos de control
* La dimensión radial mide el coste.
* La dimensión angular mide el grado de avance del proyecto.

Ventajas
- El análisis del riesgo se hace de forma explícita y clara.
- Une los mejores elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento etc.
- Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.


Desventajas
- Genera mucho tiempo en el desarrollo del sistema
- Modelo costoso
- Requiere experiencia en la identificación de riesgos

Inconvenientes
Genera mucho trabajo adicional, y eso causa muchos problemas sobre todo si la compañía que está produciendo el software es floja y holgazán. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil). El IEEE lo pone como modelo no operativo en sus clasificaciones de MCV

Modelo Incremental


Se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales.

El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente.

Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario.

Ventajas

- Se puede financiar el proyecto por partes.
- Apropiado para proyectos grandes de larga duración.
- No se necesita tanto personal al principio como para una implementación completa.

Inconvenientes
- Se necesitan pruebas de regresión.
- Pueden aumentar el coste debido a las pruebas por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Modelos Evolutivos


El software, como todo sistema complejo, evoluciona con el tiempo, los requisitos y los productos cambian a medida que el desarrollo avanza.

Para dar respuesta a esto, existen modelos de desarrollo que evolucionan con el tiempo.

Los modelos evolutivos son iterativos, se caracterizan por permitir el desarrollo de versiones cada vez más complesas del software

Entre los modelos de desarrollo evolutivo destacan:

Desarrollo Rápido de Aplicaciones (D.R.A.)

Rapid application development (RAD), es un proceso de desarrollo de software, en inglés: software development process, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.
Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto y además se adapta en alta velocidad al tradicional modelo de cascada, enfocado en la construcción basada en componentes.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de GUIs tal como Glade, o IDEs de desarrollo completas como Delphi, Foxpro o Anjuta. Uno de los programas más usados para hacer aplicaciones rápidamente es el Visual Basic

Historia
Comenzando con las ideas de Barry Boehm y Scott Shultz, James Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1991.

Razones para utilizar RAD
· Convergir tempranamente en un diseño aceptable para el cliente y posible para los desarrolladores.
· Limitar la exposición del proyecto a las fuerzas de cambio.
· Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.

Ventajas
- Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE.
- Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.


Desventajas
- Características reducidas.
- Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.
Problemas
- Para proyectos grandes necesitamos de recursos suficientes para formar los equipos necesarios.
- Compromiso de colaboración entre desarrolladores y clientes.
- No todas las aplicaciones son susceptibles de aplicar este modelo.
- Cuando los riesgos técnicos son altos DRA no es apropiado.
- Cuando el grado de interoperatividad con programas ya existentes es alto, no es apropiado.

Herramientas RAD Multiplataforma
* NetBeans
* Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
* Lazarus Es un IDE cross-platform similar a Borland Delphi.
* Real Basic Es un IDE cross-platform similar a Visual Basic.
* Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
* Microsoft Visual Studio 2003 / 2005
* ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

Herramientas RAD para Escritorio
* AppBuilder 1 2 3
* Automated Architecure's Blue Ink
* Borland C++Builder
* Visual Basic
* Ultimate++

Herramientas RAD para Bases de Datos
* FileMaker Pro Advanced
* Omnis Studio
* Oracle Forms
* Oracle Application Express o APEX
* Sybase PowerBuilder
* WinDev
* Velneo
* Servoy

Herramientas RAD Orientadas a la WEB
* 37 Signals Ruby on Rails
* Adobe ColdFusion
* Symfony (PHP)
* iRise 1
* WebDev
* Velneo
* Leonardi
* Microsoft Visual Studio