DIAGRAMA PERT
DIAGRAMA CPM
jueves, 24 de junio de 2010
CARACTERISTICAS PERT-CPM
MENCIONA LAS CARACTERISTICAS Y DIFERENCIAS DE PERT/CPM
DIAGRAMA PERT
DIAGRAMA CPM
DIAGRAMA PERT
DIAGRAMA CPM
MODELO DE PROTOTIPOS
El método de prototipo incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso.
-Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.
-Resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Pasos:
1.- Recolección de análisis de requerimientos: 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.
2.- Desarrollo de un modelo de trabajo
Componentes:
a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.
b). Pantallas y formatos para la entrada de datos.
c). Módulos esenciales de procesamiento.
d). Salida del sistema.
3.- Utilización del prototipo: Debe ser bajo condiciones del usuarios responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas
4.- Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.
5.- Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
-Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.
-Resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Pasos:
1.- Recolección de análisis de requerimientos: 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.
2.- Desarrollo de un modelo de trabajo
Componentes:
a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.
b). Pantallas y formatos para la entrada de datos.
c). Módulos esenciales de procesamiento.
d). Salida del sistema.
3.- Utilización del prototipo: Debe ser bajo condiciones del usuarios responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas
4.- Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.
5.- Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
Modelos Ciclo de Vida de los Sistemas.
1.1 Segmentación y modalidad
1.2 Criterios y elementos de conexión entre las partes
Ciclo de vida del software
“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”.
IEEE 1074
“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”.
ISO 12207-1
De acuerdo a la definición anterior el ciclo de vida de un sistema es un enfoque por fases del análisis y diseño que sostiene que los sistemas sean desarrollados de mejor manera mediante el uso de un ciclo en especifico; determina el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Jaime APV.
Lista de modelos
1.-Modelo en cascada
2.-Modelo incremental
3.-Modelo en espiral
4.-Prototipado
5.- Concurrente
6.- Modelo de Prototipado de Requerimientos
7.- Modelo De Desarrollo Evolutivo
8.- La reutilización en el Ciclo de Vida
9.- Síntesis automática de Software
10. Comparación de Ciclos de Vida
11. Modelos para desarrollo de sistemas Orientados a
Objetos.
Modelo en cascada
-Flujo secuencial entre las fases.
-Cada etapa tiene un input y un output.
-Se supone que para comenzar con una
etapa deben haber finalizado las
anteriores.
Contribuciones:
-El proceso debe ser disciplinado, planeado
y gerenciado
-La implementación debe posponerse hasta
que los objetivos se hayan comprendido
Ingeniería de requerimientos
-Identificar y documentar los requerimientos
exactos del sistema según las necesidades de
los usuarios finales.
-Cualidades del sistema.
-Funcionales, no−funcionales, del proceso y del
mantenimiento
Diseño- Especificación
-Dividir el sistema en partes y establecer las
relaciones entre ellas.
-Arquitectura y diseño detallado.
-Establecer qué hará exactamente cada parte.
-En esta fase se crea un modelo funcional−
estructural de los requerimientos.
-El diseño debe permitir implementaciones que
verifiquen los requerimientos.
Críticas:
-No refleja realmente el proceso de desarrollo del software
-Se tarda mucho tiempo en pasar por todo el ciclo
-Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
-El mantenimiento se realiza en el código fuente
-Las revisiones de proyectos de gran complejidad son muy
difíciles
-Impone una estructura de gestión de proyectos
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
-Determinar qué quieres lograr.
-Determinar las rutas alternativas que puedes tomar para lograr estas metas.
-Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.
La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
Decidir qué problema se quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
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.
1.2 Criterios y elementos de conexión entre las partes
Ciclo de vida del software
“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”.
IEEE 1074
“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”.
ISO 12207-1
De acuerdo a la definición anterior el ciclo de vida de un sistema es un enfoque por fases del análisis y diseño que sostiene que los sistemas sean desarrollados de mejor manera mediante el uso de un ciclo en especifico; determina el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Jaime APV.
Lista de modelos
1.-Modelo en cascada
2.-Modelo incremental
3.-Modelo en espiral
4.-Prototipado
5.- Concurrente
6.- Modelo de Prototipado de Requerimientos
7.- Modelo De Desarrollo Evolutivo
8.- La reutilización en el Ciclo de Vida
9.- Síntesis automática de Software
10. Comparación de Ciclos de Vida
11. Modelos para desarrollo de sistemas Orientados a
Objetos.
Modelo en cascada
-Flujo secuencial entre las fases.
-Cada etapa tiene un input y un output.
-Se supone que para comenzar con una
etapa deben haber finalizado las
anteriores.
Contribuciones:
-El proceso debe ser disciplinado, planeado
y gerenciado
-La implementación debe posponerse hasta
que los objetivos se hayan comprendido
Ingeniería de requerimientos
-Identificar y documentar los requerimientos
exactos del sistema según las necesidades de
los usuarios finales.
-Cualidades del sistema.
-Funcionales, no−funcionales, del proceso y del
mantenimiento
Diseño- Especificación
-Dividir el sistema en partes y establecer las
relaciones entre ellas.
-Arquitectura y diseño detallado.
-Establecer qué hará exactamente cada parte.
-En esta fase se crea un modelo funcional−
estructural de los requerimientos.
-El diseño debe permitir implementaciones que
verifiquen los requerimientos.
Críticas:
-No refleja realmente el proceso de desarrollo del software
-Se tarda mucho tiempo en pasar por todo el ciclo
-Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
-El mantenimiento se realiza en el código fuente
-Las revisiones de proyectos de gran complejidad son muy
difíciles
-Impone una estructura de gestión de proyectos
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
-Determinar qué quieres lograr.
-Determinar las rutas alternativas que puedes tomar para lograr estas metas.
-Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.
La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
Decidir qué problema se quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
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.
jueves, 3 de junio de 2010
Introducción y conceptos básicos
Ingeniería inversa (Reverse engineering):
La ingeniería inversa es el proceso de descubrir los principios tecnológicos de un dispositivo, objeto o sistema, a través de razonamiento abductivo de su estructura, función y operación.
La ingeniería inversa se trata de tomar algo (un dispositivo mecánico o electrónico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original.
Identifica los componentes de un sistema de información y la interrelación que existe entre ellos.
Reestructuración:
Es la transformación de una forma de representación de un sistema en otra distinta pero del mismo nivel de abstracción sin modificar el comportamiento externo del sistema.
Reingeniería:
Reingeniería en un concepto simple es el rediseño de un proceso en un negocio o un cambio drástico de un proceso. A pesar que este concepto resume la idea principal de la reingeniería esta frase no envuelve todo lo que implica la reingeniería.
Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa alrededor de los procesos. La reingeniería requiere que los procesos fundamentales de los negocios sean observados desde una perspectiva transfuncional y en base a la satisfacción del cliente.
Ingeniería hacia delante (Forward Engineering):
Reingeniería de empresas: (Bussiness Procese Reengineering):
¿Para qué se utiliza?
Acciones:
La ingeniería inversa es el proceso de descubrir los principios tecnológicos de un dispositivo, objeto o sistema, a través de razonamiento abductivo de su estructura, función y operación.
La ingeniería inversa se trata de tomar algo (un dispositivo mecánico o electrónico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original.
Identifica los componentes de un sistema de información y la interrelación que existe entre ellos.
Reestructuración:
Es la transformación de una forma de representación de un sistema en otra distinta pero del mismo nivel de abstracción sin modificar el comportamiento externo del sistema.
Reingeniería:
Reingeniería en un concepto simple es el rediseño de un proceso en un negocio o un cambio drástico de un proceso. A pesar que este concepto resume la idea principal de la reingeniería esta frase no envuelve todo lo que implica la reingeniería.
Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa alrededor de los procesos. La reingeniería requiere que los procesos fundamentales de los negocios sean observados desde una perspectiva transfuncional y en base a la satisfacción del cliente.
Ingeniería hacia delante (Forward Engineering):
Reingeniería de empresas: (Bussiness Procese Reengineering):
¿Para qué se utiliza?
Acciones:
Suscribirse a:
Entradas (Atom)
