lunes, 15 de marzo de 2010
http://ingsoft-adoo.wikispaces.com/
http://ingsoft-adoo.wikispaces.com/http://ingsoft-adoo.wikispaces.com/
CONCEPTOS Y PRINCIPIOS DEL ANALISIS
CONCEPTOS Y PRINCIPIOS DEL ANALISIS
1. INTRODUCCIÓN
2. ANÁLISIS DE REQUISITOS
• Reconocimiento del problema. Reconocer los elementos básicos del problema, tal y como los percibe el usuario o el cliente.
I. Introducción
A. Referencia del sistema
B. Descripción general
C. Restricciones del proyecto de software
II. Descripción de la información
A. Representación del contenido de la información
B. Representación del flujo de la información
1. Flujo de datos
2. Flujo de control
III. Descripción funcional
A. Partición funcional
B. Descripción funcional
1. Descripción del procesamiento
2. Restricciones / limitaciones
3. Requisitos de rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
C. Descripción del control
1. Especificación del control
2. Restricciones de diseño
IV. Descripción del comportamiento
A. Estados del sistema
B. Eventos y acciones
V. Criterios de validación
A. Limites del rendimiento
B. Clases de pruebas
C. Respuesta esperada del software
D. Consideraciones especiales
VI. Bibliografía
VII. Apéndice
PRACTICA
1. Estudie su percepción de formación y currículo ideal de un analista de sistemas.
2. Describa al "cliente" desde el punto de vista de los desarrolladores de sistemas de información, de los constructores de productos basados en computadoras y de los constructores de sistemas.
3. Construya una tabla para la selección del enfoque apropiado de creación de prototipos.
4. Investigue la técnica de componentes reutilizables como enfoque para el desarrollo de prototipos.
1. INTRODUCCIÓN
Para el éxito en el desarrollo del software es fundamental la comprensión de los requisitos necesarios para la construcción del producto software. Muchas veces es irrelevante lo bien diseñado o codificado que pueda estar un programa si es que no cuenta con una etapa de análisis previa. La tarea del análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refina en detalle el ámbito del software, inicialmente establecida por el ingeniero de sistemas y refinada durante la planificación temporal del proyecto de software. Se crean modelos de los requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan soluciones alternativas y se asignan a diferentes elementos del software.
2. ANÁLISIS DE REQUISITOS
Es una tarea de la ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite refinar la definición del software y construir los modelos de los dominios de datos, funcional y de comportamiento a ser considerados en el producto software. El análisis de requisitos proporciona al diseñador del software los siguientes modelos: de datos, arquitectónico, de interfaz y procedimental. La especificación de requisitos proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha construido el software. El análisis de requisitos del software puede dividirse en las siguientes cinco actividades de esfuerzo:
• Reconocimiento del problema. Reconocer los elementos básicos del problema, tal y como los percibe el usuario o el cliente.
• Evaluación y síntesis. Definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información y elaborar todas las funciones del software. Esta actividad continua hasta que el analista y el cliente se sienten seguros de que se puede especificar adecuadamente el software para las fases posteriores de desarrollo.
• Modelado. Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional, el comportamiento operativo y el contenido de la información.
• Especificación. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.
• Revisión. Consiste en llevar adelante la actividad de revisar las especificaciones del software para considerar las mas adecuadas.
3. TÉCNICAS DE COMUNICACIÓN
El análisis de requisitos del software siempre comienza con la comunicación entre dos o mas partes. Normalmente un cliente tiene un problema que pretende sea resuelto con un resultado producido por un programa computacional. Un desarrollador responde a la solicitud de ayuda del cliente. En este paso la comunicación comienza, pero es común comprobar que el camino de la comunicación al entendimiento está a menudo lleno de baches.
3.1 Inicio del proceso
La técnica de análisis más utilizada para empezar el proceso de comunicación es llevar a cabo una reunión o entrevista preliminar. Gause y Weinberg sugieren que el analista comience preguntando cuestiones de contexto libre, enfocados sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo se debería preguntar:
a. ¿Quién está detrás de la solicitud de este trabajo?
b. ¿Quién utilizará la solución?
c. ¿Cuál será el beneficio económico del éxito de una solución?
d. ¿Existe alguna otra alternativa necesaria para la solución?
El segundo conjunto de preguntas permite al analista obtener un entendimiento mejor del problema y al cliente comentar sus opiniones sobre la solución, estas preguntas son:
a. ¿Cómo caracterizaría un buen resultado generado por una buena solución?
b. ¿A que tipo de problema o problemas está dirigida la solución?
c. ¿Podría mostrarme el entorno en que se utilizará la solución?
d. ¿Existen aspectos o restricciones especiales de rendimiento que afecten a la manera de enfocar la solución?
El último conjunto de preguntas se concentra en la eficacia de la reunión, estas se denominan meta - preguntas y proponen la siguiente lista:
a. ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son oficiales?
b. ¿Son adecuadas mis preguntas para el problema que tiene?
c. ¿Estoy preguntando demasiado?
d. ¿Hay alguien más que pueda proporcionar información adicional?
e. ¿Hay algo mas que debería preguntarle?
3.2 Técnica para facilitar especificaciones de una aplicación (TFEA)
Este enfoque es partidario de la creación de un equipo de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución.
Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variación en las siguientes directrices básicas:
a. La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores.
b. Se establecen normas de preparación y participación.
c. Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas.
d. Se elige un coordinador que controle la reunión.
e. Se utiliza un mecanismo de definición (hojas de trabajo, gráficos, carteles, pizarra, etc.)
f. El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución.
3.3 Despliegue de la función de calidad (DFC)
Es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software. DFC se concentra en maximizar la satisfacción del cliente, haciendo énfasis en entender lo que resulta valioso para el cliente y luego desplegar estos valores a lo largo del proceso de ingeniería. DFC identifica tres tipos de requisitos:
a. Requisitos normales. Son requisitos básicos asociados a objetivos y metas para un producto software, si estos están presentes el cliente quedará satisfecho.
b. Requisitos esperados. Son implícitos al producto y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia puede ser motivo de una insatisfacción significativa.
c. Requisitos innovadores. Van más allá de las expectativas del cliente y suelen ser muy satisfactorias como valor agregado al producto.
4. PRINCIPIOS DEL ANÁLISIS
Todos los métodos de análisis se relacionan a través del siguiente conjunto de principios operativos:
a. La representación y el entendimiento del dominio de información de un problema. Requiere el examen del dominio de la información. Este dominio contiene tres visiones diferentes de los datos y del control: (1) contenido de la información y relaciones, (2) flujo de la información y (3) estructura de la información. El contenido es definido por los atributos necesarios para crearlo. El flujo representa como cambian los datos y el control a medida que se mueven dentro de un sistema. La estructura representa la organización interna de los elementos de datos o de control.
b. La definición de funciones que debe realizar el software. Los modelos se crean para entender de mejor manera la entidad que se va construir como solución aun problema. Para transformar la información el software debe realizar al menos tres funciones genéricas: entrada, procesamiento y salida.
c. La representación del comportamiento del software. La característica estimulo respuesta forma la base del modelo de comportamiento. Un programa de computadora siempre está en un estado, en un modo de comportamiento observable exteriormente (imprimiendo, calculando, etc.).
d. La división de los modelos que representan información, función y comportamiento de manera que se puedan descubrir los detalles por capas, para que las partes puedan entenderse fácilmente y establecer luego las interacciones entre las mismas de manera que se pueda conseguir la función global.
e. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación. Una visión esencial de los requisitos del software presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación. La visión de implementación de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información.
5. CREACIÓN DE PROTOTIPOS
El análisis normalmente se realiza independientemente del paradigma de ingeniería del software que se aplique. Hay circunstancias que requieren la construcción de un prototipo al principio del análisis, debido a que el modelo es el único medio a través del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona después hacia la producción del software.
El paradigma para la creación de prototipos puede ser:
a. Enfoque cerrado. Se denomina a menudo prototipo desechable. Sirve únicamente para una basta demostración de los requisitos, después se desecha y se hace la ingeniería del software con un paradigma diferente.
b. Enfoque abierto. Denominado prototipo evolutivo. Emplea el prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la construcción
6. ESPECIFICACION
El modo de especificación tiene mucho que ver con la calidad de la solución. La especificación puede verse como un proceso de representación. Los requisitos se representan de manera que como fin ultimo lleven al éxito de la implementación del software.
Los siguientes principios de especificación son adaptados del trabajo de Balzer y Goldman:
1. Separar la funcionalidad de la implementación.
2. Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno.
3. Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él.
4. Definir el entorno en que operara el sistema.
5. Crear un modelo intuitivo en lugar de un diseño o modelo de implementación.
6. Reconocer que la especificación debe ser tolerante a un posible crecimiento.
7. Establecer el contenido y la estructura de una especificación de manera que acepte cambios.
Para representar una especificación de requisitos debe seguirse el siguiente grupo de directrices.
a. El formato de representación y el contenido deben estar relacionados con el problema.
b. La información contenida dentro de la especificación debe estar escalonada.
c. La numeración de párrafos y diagramas debe indicar el nivel de detalle que se muestra.
d. Los diagramas y otras formas de notación deben restringirse en numero y ser consistentes en su empleo.
e. La representación debe permitir revisiones.
Finalmente un esquema para la especificación de los requisitos del software, señalado por Pressman es la siguiente:
I. Introducción
A. Referencia del sistema
B. Descripción general
C. Restricciones del proyecto de software
II. Descripción de la información
A. Representación del contenido de la información
B. Representación del flujo de la información
1. Flujo de datos
2. Flujo de control
III. Descripción funcional
A. Partición funcional
B. Descripción funcional
1. Descripción del procesamiento
2. Restricciones / limitaciones
3. Requisitos de rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
C. Descripción del control
1. Especificación del control
2. Restricciones de diseño
IV. Descripción del comportamiento
A. Estados del sistema
B. Eventos y acciones
V. Criterios de validación
A. Limites del rendimiento
B. Clases de pruebas
C. Respuesta esperada del software
D. Consideraciones especiales
VI. Bibliografía
VII. Apéndice
PRACTICA
1. Estudie su percepción de formación y currículo ideal de un analista de sistemas.
2. Describa al "cliente" desde el punto de vista de los desarrolladores de sistemas de información, de los constructores de productos basados en computadoras y de los constructores de sistemas.
3. Construya una tabla para la selección del enfoque apropiado de creación de prototipos.
4. Investigue la técnica de componentes reutilizables como enfoque para el desarrollo de prototipos.
jueves, 11 de marzo de 2010
Ejercicios para modelar
Dado el siguiente procedimiento, representelo mediante un diagrama de actividades.
1. Proceso de compras
_____________________________________
La requisición de compra es el documento formal para solicitar al Departamento de Compras la adquisición de cualquier producto o material.
Sólo se recibirán requisiciones de compra llenadas en forma clara, completa y detallada con la información requerida en cada campo, presentando original y copia.
Todas las requisiciones deben ser autorizadas por el Director de División, así como por el responsable de ejercer el presupuesto.
La utilización de formatos para la requisición de artículos debe ser la mínima posible y el usuario deberá agrupar los artículos según su género.
Toda requisición de compra igual o mayor a $100,000.00 se someterá revisión del Comité de Compras. Este rubro incluye las compras por proyecto.
El Departamento de Compras tendrá información sobre la requisición en un plazo mínimo de 48 hrs. a partir de su recepción.
Es indispensable que el usuario conserve el número de pedido que le fue asignado a su requisición, sirviéndole también para cualquier aclaración durante el proceso.
El tiempo de entrega del material solicitado dependerá de los tiempos pactados por el Departamento de Compras y/o de la existencia y condiciones que el proveedor indique.
En caso de presentarse algún problema para la adquisición de los bienes solicitados, Compras informará de la situación al usuario y le ofrecerá otras alternativas para realizar la compra.
2. Dado el siguiente procedimiento, representelo mediante la notacion BPMN (modele el proceso) y el diagrama de actividades.
Casas - El proceso para comprar una vivienda puede parecer complicado, pero si toma las cosas paso a paso, pronto tendrá en sus manos las llaves para su propia casa! Hay nueve pasos para comprar una vivienda.
Paso 1: Calcule cuánto puede invertir en una vivienda
La cantidad de dinero que usted puede permitirse invertir depende depende de sus ingresos, valoración crediticia, gastos mensuales actuales, la cuota inicial y la tasa de interés. Las calculadoras abajo pueden servirle de ayuda, pero es mejor visitar a un prestamista para averiguar con mayor certeza.
- ¿Cuánto puede invertir en una vivienda?
- Comprar vs. Alquilar
- Como Prepararse Para Comprar Vivienda
¿Necesita ayuda con su cuota inicial o costos de cierre?
- Programas de compra de vivienda locales
¡Un asesor de vivienda le puede ayudar a calcular cómo manejar y pagar sus deudas.
- Busque un asesor de vivienda cerca a usted
Paso 2: Conozca sus derechos
- Equidad de Vivienda: Igualdad de Oportunidades para Todos
- Ley de Procedimientos para Liquidación de Bienes Raíces (RESPA)
- Derechos del prestatario
- Prestamistas fraudalentos
Paso 3: Busque la mejor hipoteca
Ahorre dinero preparándose bien. Hable con varios prestamistas, compare costos y tasas de interés, negocie para obtener una mejor oferta. Considere conseguir aprobación previa para un préstamo.
- Cómo buscar la mejor hipoteca: averiguar, comparar, negociar
- Deje que la FHA le ayude
Paso 4: Aprenda sobre los programas de compra de vivienda
- Programas de compra de vivienda locales
Los programas de préstamo FHA le ofrecen una cuota inicial más baja y son una buena opción para los compradores de casa por primera vez.
- Deje que la FHA le ayude
- Programas de compra de vivienda especiales de HUD
- Programa del Buen Vecino – para policías, maestros, bomberos, y técnicos de emergencia médica
- Ventas a descuento para evacuados de huracanes
- Propiedad de vivienda para residentes de vivienda pública
- Programa de Garantía de Préstamos Hipotecarios para Comunidades Indígenas (Sección 184)
Paso 5: Busque una vivienda
- Escoja un agente de bienes raíces
- Lista de expectativas - ¿Qué características desea?
- Lista de verificación de búsqueda de viviendas – lista de comparaciones de viviendas
- Viviendas en venta (incluye viviendas de HUD)
- Viviendas para refaccionar (“Fixer-Upper”) – programas para compra y reparación de viviendas
- Viviendas pre-fabricadas (casas móviles)
- Construya una casa
Si escoge una vivienda en un vecindario con una Asociación de Propietarios de Vivienda (HOA, por sus siglas en inglés), asegúrese de solicitar una copia del paquete de HOA de modo que usted pueda revisarlo antes del cierre.
Paso 6: Haga una oferta
Discuta el proceso con su agente de bienes raíces. Si el vendedor le hace una contraoferta, tendrá que negociar hasta que ambos concuerden en los términos de la venta.
- Hacer una oferta
Paso 7: Haga inspeccionar la vivienda
Presente su oferta sujeto a condición de una inspección de la vivienda. Una inspección le indicará la condición en que se encuentra la casa y puede ayudarle a evitar comprar una vivienda que necesita reparaciones mayores.
- Para su protección, haga inspeccionar la vivienda
Paso 8: Busque un seguro para propietarios de vivienda
Las agencias crediticias requieren que usted tenga un seguro hipotecario. Asegúrese de buscar la mejor oferta.
- Seguro hipotecario
Paso 9: Firme los papeles
Por fín está listo para el “cierre”. ¡Asegúrese de leer todo antes de firmar!
- Costos de cierre e información importante
1. Proceso de compras
_____________________________________
La requisición de compra es el documento formal para solicitar al Departamento de Compras la adquisición de cualquier producto o material.
Sólo se recibirán requisiciones de compra llenadas en forma clara, completa y detallada con la información requerida en cada campo, presentando original y copia.
Todas las requisiciones deben ser autorizadas por el Director de División, así como por el responsable de ejercer el presupuesto.
La utilización de formatos para la requisición de artículos debe ser la mínima posible y el usuario deberá agrupar los artículos según su género.
Toda requisición de compra igual o mayor a $100,000.00 se someterá revisión del Comité de Compras. Este rubro incluye las compras por proyecto.
El Departamento de Compras tendrá información sobre la requisición en un plazo mínimo de 48 hrs. a partir de su recepción.
Es indispensable que el usuario conserve el número de pedido que le fue asignado a su requisición, sirviéndole también para cualquier aclaración durante el proceso.
El tiempo de entrega del material solicitado dependerá de los tiempos pactados por el Departamento de Compras y/o de la existencia y condiciones que el proveedor indique.
En caso de presentarse algún problema para la adquisición de los bienes solicitados, Compras informará de la situación al usuario y le ofrecerá otras alternativas para realizar la compra.
2. Dado el siguiente procedimiento, representelo mediante la notacion BPMN (modele el proceso) y el diagrama de actividades.
El Proceso para Comprar Una Vivienda
Casas - El proceso para comprar una vivienda puede parecer complicado, pero si toma las cosas paso a paso, pronto tendrá en sus manos las llaves para su propia casa! Hay nueve pasos para comprar una vivienda.
Paso 1: Calcule cuánto puede invertir en una vivienda
La cantidad de dinero que usted puede permitirse invertir depende depende de sus ingresos, valoración crediticia, gastos mensuales actuales, la cuota inicial y la tasa de interés. Las calculadoras abajo pueden servirle de ayuda, pero es mejor visitar a un prestamista para averiguar con mayor certeza.
- ¿Cuánto puede invertir en una vivienda?
- Comprar vs. Alquilar
- Como Prepararse Para Comprar Vivienda
¿Necesita ayuda con su cuota inicial o costos de cierre?
- Programas de compra de vivienda locales
¡Un asesor de vivienda le puede ayudar a calcular cómo manejar y pagar sus deudas.
- Busque un asesor de vivienda cerca a usted
Paso 2: Conozca sus derechos
- Equidad de Vivienda: Igualdad de Oportunidades para Todos
- Ley de Procedimientos para Liquidación de Bienes Raíces (RESPA)
- Derechos del prestatario
- Prestamistas fraudalentos
Paso 3: Busque la mejor hipoteca
Ahorre dinero preparándose bien. Hable con varios prestamistas, compare costos y tasas de interés, negocie para obtener una mejor oferta. Considere conseguir aprobación previa para un préstamo.
- Cómo buscar la mejor hipoteca: averiguar, comparar, negociar
- Deje que la FHA le ayude
Paso 4: Aprenda sobre los programas de compra de vivienda
- Programas de compra de vivienda locales
Los programas de préstamo FHA le ofrecen una cuota inicial más baja y son una buena opción para los compradores de casa por primera vez.
- Deje que la FHA le ayude
- Programas de compra de vivienda especiales de HUD
- Programa del Buen Vecino – para policías, maestros, bomberos, y técnicos de emergencia médica
- Ventas a descuento para evacuados de huracanes
- Propiedad de vivienda para residentes de vivienda pública
- Programa de Garantía de Préstamos Hipotecarios para Comunidades Indígenas (Sección 184)
Paso 5: Busque una vivienda
- Escoja un agente de bienes raíces
- Lista de expectativas - ¿Qué características desea?
- Lista de verificación de búsqueda de viviendas – lista de comparaciones de viviendas
- Viviendas en venta (incluye viviendas de HUD)
- Viviendas para refaccionar (“Fixer-Upper”) – programas para compra y reparación de viviendas
- Viviendas pre-fabricadas (casas móviles)
- Construya una casa
Si escoge una vivienda en un vecindario con una Asociación de Propietarios de Vivienda (HOA, por sus siglas en inglés), asegúrese de solicitar una copia del paquete de HOA de modo que usted pueda revisarlo antes del cierre.
Paso 6: Haga una oferta
Discuta el proceso con su agente de bienes raíces. Si el vendedor le hace una contraoferta, tendrá que negociar hasta que ambos concuerden en los términos de la venta.
- Hacer una oferta
Paso 7: Haga inspeccionar la vivienda
Presente su oferta sujeto a condición de una inspección de la vivienda. Una inspección le indicará la condición en que se encuentra la casa y puede ayudarle a evitar comprar una vivienda que necesita reparaciones mayores.
- Para su protección, haga inspeccionar la vivienda
Paso 8: Busque un seguro para propietarios de vivienda
Las agencias crediticias requieren que usted tenga un seguro hipotecario. Asegúrese de buscar la mejor oferta.
- Seguro hipotecario
Paso 9: Firme los papeles
Por fín está listo para el “cierre”. ¡Asegúrese de leer todo antes de firmar!
- Costos de cierre e información importante
DESARROLLO DE SOFTWARE - ESTUDIO DE FACTIBILIDAD
Objetivos:
1. Determinar la factibilidad técnica, económica, operativa y jurídica (y de ser necesarias otras) del proyecto.
2. Lograr el conocimiento general del problema y la estructura de los requerimientos de información, con el fin de estimar los recursos necesarios.
3. Planear alternativas de desarrollo.
4. Realizar planeación general de actividades.
Para qué sirve el Estudio de Factibilidad?
1. Para evitar desarrollar proyectos que no son factibles.
2. Para planear los recursos.
3. Para “aterrizar” al personal administrativo de sistemas, usuarios, auditores, etc. respecto a las expectativas reales del sistema.
Quiénes participan en la etapa?
1. Los usuarios: proporcionan los requerimientos del sistema.
2. Los analistas, programadores, jefes de proyecto, director de sistemas.
3. Personal de auditoría: asegura los controles y seguridad del sistema.
Actividades de la etapa
1. Entender el proyecto.
2. Establecer la duración y tamaño del proyecto.
3. Determinar costos y beneficios.
4. Determinar la factibilidad del sistema.
5. Elaborar un documento con recomendaciones en el cual debe quedar claro si el proyecto es o no factible.
El estudio de factibilidad contiene:
1. Definición organizada de los requerimientos de información.
2. Recursos requeridos para el desarrollo del proyecto.
3. Análisis de factibilidad.
4. Alternativas de desarrollo.
5. Cronograma de actividades.
Descripción de los principales componentes del Estudio de Factibilidad
1. Reconocimiento general del sistema
- Ubicación del sistema (Organización, departamento, sistema)
- Organización:
Objeto social, tamaño, organigrama, ubicación geográfica, visión, misión.
- Sistema:
Objetivos del sistema: debe reflejar la necesidad de satisfacer información requerida por el usuario.
Delimitación o alcance del sistema (módulos a implementar): Define los límites hasta los cuales se va a expandir el proyecto. Resuelve las siguientes preguntas: Qué hará el sistema? Qué No hará el sistema?
Beneficios que traerá el desarrollo del sistema.
Restricciones o condiciones que tendrá el sistema: a nivel tecnológico o de funcionalidad.
Definición del sistema (Narración):
Objetivos:
Definir características y necesidades de información.
Identificar cada uno de los componentes, las entradas, las salidas y las relaciones entre cada uno de ellos.
2. Recursos requeridos
Objetivo: definir las características y cantidades necesarias de talento humano, recursos técnicos y materiales, así como sus costos, necesarios para el desarrollo del proyecto.
3. Usuarios del sistema
Se identifican los usuarios que utilizarán el sistema, el cargo (dentro de la organización) y la ubicación geográfica de cada uno de ellos.
- Usuario primario: puede definir con adecuado criterio y autoridad las características fundamentales del sistema, dado que éste hace parte de su responsabilidad.
- Usuarios secundarios: son ellos quienes utilizan el sistema y por lo tanto no tienen una visión global de éste, pero brindan aportes importantes a nivel de detalle en los procesos más comúnmente utilizados por ellos, especialmente en interfaces con otras aplicaciones.
4. Beneficios esperados del proyecto
Con el fin de asegurar la viabilidad del proyecto, todos los beneficios deben ser claramente identificados.
Para identificar los beneficios en aconsejable detectar los problemas del sistema actual y los costos que representan. Si el sistema propuesto elimina el problema o reduce su costo, puede decirse que se tendrá un beneficio en la cantidad que en la actualidad representa dicho costo.
Beneficios tangibles: son de fácil cuantificación, generalmente están relacionados con la reducción de recursos o talento humano.
Beneficios intangibles: no son fácilmente cuantificables y están relacionados con elementos como el impacto sobre aspectos como Good Will o mejora en otros procesos de la organización.
Ejemplo de beneficios:
- Mejoras en la eficiencia del área bajo estudio.
- Reducción de personal.
- Reducción de futuras inversiones y costos.
- Disponibilidad del recurso humano.
- Mejoras en planeación, control y uso de recursos.
- Suministro oportuno de insumos para las operaciones.
- Cumplimiento de requerimientos gubernamentales.
- Toma acertada de decisiones.
- Disponibilidad de información apropiada.
- Aumento en la confiabilidad de la información.
- Mejor servicio al cliente externo e interno
- Logro de ventajas competitivas.
- Valor agregado a un producto de la compañía.
Cuantificación de beneficios
Es necesario cuantificar ($) los beneficios cuantificables durante los años de VIDA ÚTIL del sistema. Requerimiento para el cálculo de la relación: Costo/Beneficio.
Variable
Costo Sma. Actual (A)
Costo Sma. Propuesto (B)
Beneficio (A-B)
Vida Util
Total
5. Costos del proyecto
Los costos del proyecto pueden estar dados por la adquisición o utilización de equipos, personal, compra de software, costos en los procedimientos para la recopilación de información, preparación de documentación, mantenimiento de sistemas etc. Deben ser calculados para cada uno de los recursos en cada una de las etapas del ciclo de vida del sistema.
Requerimiento para el cálculo de la relación: Costo/Beneficio.
6. Análisis de alternativas de implementación
Es necesario evaluar cada una de las alternativas de implementación, eligiendo una de ellas y descartando una por una las demás alternativas. Deben sustentarse las razones de cada decisión.
- Mejoras al sistema actual: en esencia el sistema actual se mantiene con algunas mejoras.
- Adquisición de paquetes
- Desarrollo externo a la medida – Outsourcing
- Desarrollo interno a la medida: realizado por analistas de la organización (nosotros).
7. Análisis de factibilidad del sistema
El estudio de factibilidad se hace necesario cuando el desarrollo del sistema no tiene una justificación económica establecida, existe un alto riesgo tecnológico, operativo, jurídico o no se cuenta con una alternativa clara de implementación.
- Factibilidad económica
Se debe hacer una comparación de los costos de las posibles soluciones contra los beneficios que ofrecen, de acuerdo con lo documentado en los numerales anteriores.
Indicador: Relación Costo / Beneficio (<1>1 No factible)
Debe hacerse para cada una de las alternativas de implementación.
- Factibilidad técnica
Se debe hacer un análisis de la tecnología requerida para conseguir la funcionalidad y el rendimiento del sistema propuesto, cuál es el riesgo de desarrollo y cómo afectan éstos elementos el costo del proyecto. Además, se debe definir si el problema se puede resolver con los medios actualmente existentes y el grado de adaptación de la solución a la tecnología con la que cuenta la organización.
Existe la tecnología requerida para el desarrollo del sistema? Puede la organización acceder a dicha tecnología?
- Factibilidad operacional
Explica cómo hacer funcionar el sistema propuesto en las operaciones de la organización. Muestra como puede cambiar el sistema el entorno del usuario y las actividades que realiza.
Comprende dos aspectos:
Impacto sobre los usuarios: cuenta el proyecto con respaldo y compromiso verdadero, en términos de actitud y asignación de recursos? Consideran que el proyecto beneficia a la organización? Está la alta dirección comprometida?
Impacto sobre los demás sistemas de la organización:
Cuál será el impacto del sistema sobre otros procesos de la organización? Será positivo? Negativo?
8. Definir el impacto sobre los planes generales de la organización o sobre su planeación estratégica
Se debe determinar cómo contribuye el sistema a:
- El logro de los planes del departamento.
- El logro de los planes específicos de la compañía.
- El logro de la misión organizacional.
- El logro de la visión organizacional.
9. Cronograma
Se realiza con base en las etapas del ciclo de vida y bajo las restricciones de tiempo que siempre existen.
CONTENIDO DEL ESTUDIO DE FACTIBILIDAD
1. Reconocimiento general del sistema
1.1. Ubicación de la organización
1.1.1. Nombre y objeto social
1.1.2. Visión
1.1.3. Misión
1.1.4. Políticas
1.1.5. Tamaño de la organización
1.1.6. Organigrama
1.1.7. Ubicación geográfica
1.2. Área o departamento
1.2.1. Organigrama
1.2.2. Factores críticos de éxito
1.2.3. Planes o proyectos
1.3. El sistema
1.3.1. Definición del sistema actual (Desc. Textual + Diag. Actividades)
1.3.2. Problemas del sistema actual
1.3.3. Delimitación o alcance del sistema a desarrollar
1.3.4. Identificación de procesos de la organización
1.3.5. Requerimientos del sistema a desarrollar
1.3.5.1. Requerimientos funcionales: Casos de uso – Para qué sirve?- Qué debe hacer el sistema?
1.3.5.2. Lista de informes que debe generar
1.3.5.3. Entradas
1.3.5.4. Almacenamientos
1.3.5.5. Interfaces con otros sistemas
1.3.5.6. Requerimientos no funcionales (ilities)
1.3.6. Objetivos del sistema a desarrollar
1.3.6.1. Objetivo terminal
1.3.6.2. Objetivos específicos
2. Recursos requeridos por etapa
2.1. Talento humano
2.2. Recursos técnicos
2.3. Otros recursos
3. Usuarios del sistema
3.1. Usuario primario
3.2. Usuarios secundarios
4. Beneficios esperados del proyecto
4.1. Beneficios tangibles
4.2. Beneficios intangibles
5. Costos o inversión del proyecto – por etapa –
6. Análisis de alternativas de implementación
6.1. Mejoras al sistema actual
6.2. Adquisición de paquetes
6.3. Desarrollo externo a la medida – Outsourcing –
6.4. Desarrollo interno a la medida
7. Estudio de factibilidad
7.1. Factibilidad económica
7.2. Factibilidad técnica
7.3. Factibilidad operativa
7.4. Factibilidad jurídica
8. Impacto sobre los planes de la organización o sobre su planeación estratégica
8.1. Impacto sobre la visión
8.2. Impacto sobre la misión
8.3. Impacto sobre la planeación
9. Cronograma
10. Conclusiones
11. Recomendaciones
12. Glosario
13. Bibliografía
14. Anexos
BIBLIOGRAFÍA
- Senn. James A. Sistemas de información.
- Laudon & Laudon. Administración de los sistemas de información.
- Pressman. Roger S. Ingeniería del software: Un enfoque práctico.
- Jacobson. El proceso unificado de desarrollo de software.
- McConnel. Desarrollo y gestión de proyectos informáticos.
- Áldrin Fredy Jaramillo F. Departamento de Ingeniería de SistemasUniversidad de Antioquia
1. Determinar la factibilidad técnica, económica, operativa y jurídica (y de ser necesarias otras) del proyecto.
2. Lograr el conocimiento general del problema y la estructura de los requerimientos de información, con el fin de estimar los recursos necesarios.
3. Planear alternativas de desarrollo.
4. Realizar planeación general de actividades.
Para qué sirve el Estudio de Factibilidad?
1. Para evitar desarrollar proyectos que no son factibles.
2. Para planear los recursos.
3. Para “aterrizar” al personal administrativo de sistemas, usuarios, auditores, etc. respecto a las expectativas reales del sistema.
Quiénes participan en la etapa?
1. Los usuarios: proporcionan los requerimientos del sistema.
2. Los analistas, programadores, jefes de proyecto, director de sistemas.
3. Personal de auditoría: asegura los controles y seguridad del sistema.
Actividades de la etapa
1. Entender el proyecto.
2. Establecer la duración y tamaño del proyecto.
3. Determinar costos y beneficios.
4. Determinar la factibilidad del sistema.
5. Elaborar un documento con recomendaciones en el cual debe quedar claro si el proyecto es o no factible.
El estudio de factibilidad contiene:
1. Definición organizada de los requerimientos de información.
2. Recursos requeridos para el desarrollo del proyecto.
3. Análisis de factibilidad.
4. Alternativas de desarrollo.
5. Cronograma de actividades.
Descripción de los principales componentes del Estudio de Factibilidad
1. Reconocimiento general del sistema
- Ubicación del sistema (Organización, departamento, sistema)
- Organización:
Objeto social, tamaño, organigrama, ubicación geográfica, visión, misión.
- Sistema:
Objetivos del sistema: debe reflejar la necesidad de satisfacer información requerida por el usuario.
Delimitación o alcance del sistema (módulos a implementar): Define los límites hasta los cuales se va a expandir el proyecto. Resuelve las siguientes preguntas: Qué hará el sistema? Qué No hará el sistema?
Beneficios que traerá el desarrollo del sistema.
Restricciones o condiciones que tendrá el sistema: a nivel tecnológico o de funcionalidad.
Definición del sistema (Narración):
Objetivos:
Definir características y necesidades de información.
Identificar cada uno de los componentes, las entradas, las salidas y las relaciones entre cada uno de ellos.
2. Recursos requeridos
Objetivo: definir las características y cantidades necesarias de talento humano, recursos técnicos y materiales, así como sus costos, necesarios para el desarrollo del proyecto.
3. Usuarios del sistema
Se identifican los usuarios que utilizarán el sistema, el cargo (dentro de la organización) y la ubicación geográfica de cada uno de ellos.
- Usuario primario: puede definir con adecuado criterio y autoridad las características fundamentales del sistema, dado que éste hace parte de su responsabilidad.
- Usuarios secundarios: son ellos quienes utilizan el sistema y por lo tanto no tienen una visión global de éste, pero brindan aportes importantes a nivel de detalle en los procesos más comúnmente utilizados por ellos, especialmente en interfaces con otras aplicaciones.
4. Beneficios esperados del proyecto
Con el fin de asegurar la viabilidad del proyecto, todos los beneficios deben ser claramente identificados.
Para identificar los beneficios en aconsejable detectar los problemas del sistema actual y los costos que representan. Si el sistema propuesto elimina el problema o reduce su costo, puede decirse que se tendrá un beneficio en la cantidad que en la actualidad representa dicho costo.
Beneficios tangibles: son de fácil cuantificación, generalmente están relacionados con la reducción de recursos o talento humano.
Beneficios intangibles: no son fácilmente cuantificables y están relacionados con elementos como el impacto sobre aspectos como Good Will o mejora en otros procesos de la organización.
Ejemplo de beneficios:
- Mejoras en la eficiencia del área bajo estudio.
- Reducción de personal.
- Reducción de futuras inversiones y costos.
- Disponibilidad del recurso humano.
- Mejoras en planeación, control y uso de recursos.
- Suministro oportuno de insumos para las operaciones.
- Cumplimiento de requerimientos gubernamentales.
- Toma acertada de decisiones.
- Disponibilidad de información apropiada.
- Aumento en la confiabilidad de la información.
- Mejor servicio al cliente externo e interno
- Logro de ventajas competitivas.
- Valor agregado a un producto de la compañía.
Cuantificación de beneficios
Es necesario cuantificar ($) los beneficios cuantificables durante los años de VIDA ÚTIL del sistema. Requerimiento para el cálculo de la relación: Costo/Beneficio.
Variable
Costo Sma. Actual (A)
Costo Sma. Propuesto (B)
Beneficio (A-B)
Vida Util
Total
5. Costos del proyecto
Los costos del proyecto pueden estar dados por la adquisición o utilización de equipos, personal, compra de software, costos en los procedimientos para la recopilación de información, preparación de documentación, mantenimiento de sistemas etc. Deben ser calculados para cada uno de los recursos en cada una de las etapas del ciclo de vida del sistema.
Requerimiento para el cálculo de la relación: Costo/Beneficio.
6. Análisis de alternativas de implementación
Es necesario evaluar cada una de las alternativas de implementación, eligiendo una de ellas y descartando una por una las demás alternativas. Deben sustentarse las razones de cada decisión.
- Mejoras al sistema actual: en esencia el sistema actual se mantiene con algunas mejoras.
- Adquisición de paquetes
- Desarrollo externo a la medida – Outsourcing
- Desarrollo interno a la medida: realizado por analistas de la organización (nosotros).
7. Análisis de factibilidad del sistema
El estudio de factibilidad se hace necesario cuando el desarrollo del sistema no tiene una justificación económica establecida, existe un alto riesgo tecnológico, operativo, jurídico o no se cuenta con una alternativa clara de implementación.
- Factibilidad económica
Se debe hacer una comparación de los costos de las posibles soluciones contra los beneficios que ofrecen, de acuerdo con lo documentado en los numerales anteriores.
Indicador: Relación Costo / Beneficio (<1>1 No factible)
Debe hacerse para cada una de las alternativas de implementación.
- Factibilidad técnica
Se debe hacer un análisis de la tecnología requerida para conseguir la funcionalidad y el rendimiento del sistema propuesto, cuál es el riesgo de desarrollo y cómo afectan éstos elementos el costo del proyecto. Además, se debe definir si el problema se puede resolver con los medios actualmente existentes y el grado de adaptación de la solución a la tecnología con la que cuenta la organización.
Existe la tecnología requerida para el desarrollo del sistema? Puede la organización acceder a dicha tecnología?
- Factibilidad operacional
Explica cómo hacer funcionar el sistema propuesto en las operaciones de la organización. Muestra como puede cambiar el sistema el entorno del usuario y las actividades que realiza.
Comprende dos aspectos:
Impacto sobre los usuarios: cuenta el proyecto con respaldo y compromiso verdadero, en términos de actitud y asignación de recursos? Consideran que el proyecto beneficia a la organización? Está la alta dirección comprometida?
Impacto sobre los demás sistemas de la organización:
Cuál será el impacto del sistema sobre otros procesos de la organización? Será positivo? Negativo?
8. Definir el impacto sobre los planes generales de la organización o sobre su planeación estratégica
Se debe determinar cómo contribuye el sistema a:
- El logro de los planes del departamento.
- El logro de los planes específicos de la compañía.
- El logro de la misión organizacional.
- El logro de la visión organizacional.
9. Cronograma
Se realiza con base en las etapas del ciclo de vida y bajo las restricciones de tiempo que siempre existen.
CONTENIDO DEL ESTUDIO DE FACTIBILIDAD
1. Reconocimiento general del sistema
1.1. Ubicación de la organización
1.1.1. Nombre y objeto social
1.1.2. Visión
1.1.3. Misión
1.1.4. Políticas
1.1.5. Tamaño de la organización
1.1.6. Organigrama
1.1.7. Ubicación geográfica
1.2. Área o departamento
1.2.1. Organigrama
1.2.2. Factores críticos de éxito
1.2.3. Planes o proyectos
1.3. El sistema
1.3.1. Definición del sistema actual (Desc. Textual + Diag. Actividades)
1.3.2. Problemas del sistema actual
1.3.3. Delimitación o alcance del sistema a desarrollar
1.3.4. Identificación de procesos de la organización
1.3.5. Requerimientos del sistema a desarrollar
1.3.5.1. Requerimientos funcionales: Casos de uso – Para qué sirve?- Qué debe hacer el sistema?
1.3.5.2. Lista de informes que debe generar
1.3.5.3. Entradas
1.3.5.4. Almacenamientos
1.3.5.5. Interfaces con otros sistemas
1.3.5.6. Requerimientos no funcionales (ilities)
1.3.6. Objetivos del sistema a desarrollar
1.3.6.1. Objetivo terminal
1.3.6.2. Objetivos específicos
2. Recursos requeridos por etapa
2.1. Talento humano
2.2. Recursos técnicos
2.3. Otros recursos
3. Usuarios del sistema
3.1. Usuario primario
3.2. Usuarios secundarios
4. Beneficios esperados del proyecto
4.1. Beneficios tangibles
4.2. Beneficios intangibles
5. Costos o inversión del proyecto – por etapa –
6. Análisis de alternativas de implementación
6.1. Mejoras al sistema actual
6.2. Adquisición de paquetes
6.3. Desarrollo externo a la medida – Outsourcing –
6.4. Desarrollo interno a la medida
7. Estudio de factibilidad
7.1. Factibilidad económica
7.2. Factibilidad técnica
7.3. Factibilidad operativa
7.4. Factibilidad jurídica
8. Impacto sobre los planes de la organización o sobre su planeación estratégica
8.1. Impacto sobre la visión
8.2. Impacto sobre la misión
8.3. Impacto sobre la planeación
9. Cronograma
10. Conclusiones
11. Recomendaciones
12. Glosario
13. Bibliografía
14. Anexos
BIBLIOGRAFÍA
- Senn. James A. Sistemas de información.
- Laudon & Laudon. Administración de los sistemas de información.
- Pressman. Roger S. Ingeniería del software: Un enfoque práctico.
- Jacobson. El proceso unificado de desarrollo de software.
- McConnel. Desarrollo y gestión de proyectos informáticos.
- Áldrin Fredy Jaramillo F. Departamento de Ingeniería de SistemasUniversidad de Antioquia
Proceso
Proceso.
Cuando se construye un producto o se presta un servicio se siguen una serie de pasos para lograr cumplir las tareas necesarias en un cierto orden. Un proceso es una serie de pasos que involucran actividades, restricciones y recursos que producen una salida determinada (producto o servicio) utilizando para ello un conjunto de herramientas y técnicas.
Todos los procesos tienen estas características:
• establecen las principales actividades del proceso.
• utilizan recursos (horas hombre, equipos, dinero, …).
• están sujetos a restricciones (calendario, presupuesto, …).
• genera productos intermedios y finales.
• puede constituirse como una cadena de subprocesos, cada uno con su propio modelo. • cada actividad tiene criterios de entradas y salidas; puede saberse cuando comienza y cuando termina una actividad.
• las actividades se organizan en secuencia; resulta claro el orden relativo de una actividad respecto a las demás.
• tiene un conjunto de principios orientadores que describen las metas de cada actividad.
• las restricciones pueden aplicarse a una actividad, recurso o producto.
Un proceso es más que un procedimiento. Un procedimiento es una manera estructurada de combinar herramientas y técnicas para generar un producto. Un proceso es un conjunto de procedimientos organizados de tal modo que los productos construidos satisfagan un conjunto de metas o estándares.
Proceso de desarrollo o ciclo de vida del software.
El proceso que nos interesa es el proceso de desarrollo del software. Cuando un proceso implica construcción de algún producto suele denominarse al proceso ciclo de vida. En particular, el ciclo de vida del software describe la vida de un producto de software desde su concepción hasta su implementación, entrega, utilización y mantenimiento.
Modelos de procesos en ingeniería de software.Es posible concebir diferentes modelos de proceso para arribar a un mismo producto; las diferencias estarán en las actividades priorizadas, su importancia relativa, la secuencia de realización, los principios orientadores, las herramientas y técnicas elegidas.
Ciclo de Vida
EL CICLO DE VIDA DE UN PROYECTO DE TIC's
Enviado por Patricio Villarroel M
Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
· Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
o El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
o Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
o La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle:
Enviado por Patricio Villarroel M
Todo proyecto de ingeniería tiene fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades.
Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.
ELEMENTOS DEL CICLO DE VIDA. Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
· Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
Esquema general de operación de una fase
Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
TIPOS DE MODELO DE CICLO DE VIDA. Las principales diferencias entre distintos modelos de ciclo de vida están en:
o El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
o Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
o La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle:
Ciclo de vida lineal
Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla. Ejemplo de ciclo lineal para un proyecto de construcción
Ciclo de vida con prototipado
A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
Ciclo de vida en espiral
El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos).
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos).
En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
o Estudio de viabilidad.
o Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
o Asegurar que los requisitos son alcanzables.
o Formalizar el acuerdo con los usuarios.
o Realizar una planificación detallada.
o Estudio de viabilidad.
o Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
o Asegurar que los requisitos son alcanzables.
o Formalizar el acuerdo con los usuarios.
o Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
o Identificar soluciones tecnológicas para cada una de las funciones del sistema.
o Asignar recursos materiales para cada una de las funciones.
o Proponer (identificar y seleccionar) subcontratas.
o Establecer métodos de validación del diseño.
o Ajustar las especificaciones del producto.
o Identificar soluciones tecnológicas para cada una de las funciones del sistema.
o Asignar recursos materiales para cada una de las funciones.
o Proponer (identificar y seleccionar) subcontratas.
o Establecer métodos de validación del diseño.
o Ajustar las especificaciones del producto.
Fase de construcción
o Generar el producto o servicio pretendido con el proyecto.
o Integrar los elementos subcontratados o adquiridos externamente.
o Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
o Generar el producto o servicio pretendido con el proyecto.
o Integrar los elementos subcontratados o adquiridos externamente.
o Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
o Operación: asegurar que el uso del proyecto es el pretendido.
o Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste):
o Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste):
Suscribirse a:
Entradas (Atom)