martes, 17 de agosto de 2010
Modelos Genericos de Desarrollo de Software
Acontinuacion Encontraran ciertas clases de Modelos que le ayudaran a entender el desarrollo adecuado de un software.
Modelo de procesos en Espiral
Desarrollado por B. Boehm, basicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa; esta orientado a evitar riesgos de trabajo. No define en detalle el sistema completo a la primera. Los desarrolladores deberian solamente definir las mas altas prioridades. Definir e implementarlas y entonces obtener un feedback de los usuarios (tal y como feedback distingue desarrollo "evolutivo" de "incremental"). Con este conocimiento, deberian entonces retroceder o volver al punto de partida para definir e implementar mas y mejores partes.
El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteracion, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.
Este metodo esta basado en dos importantes principios:
la practica de diseño profesional es caracterizar en terminos de conocer, actuar en situaciones, conversacion con la situacion y reflexion en accion. Hay un distinto medio de proceso - orientacion en esta aproximacion al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que despues meramente lo transcriba. Gran parte del tiempo del diseñador esta inmiscuido en una progresiva relacion con su entorno. Una buena metafora para describirlo es "la conversacion con el material", como un escultor, quien esta ocupado en una conversacion con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser.
la necesidad para diseñadores de tomar la practica de trabajo seriamente, de supervisar las formas en las que el trabajo se esta haciendo, en el sentido de una solucion abierta y desplegada para aumentar la complejidad de una situacion que el diseñador solo entiende parcialmente. El hecho por el cual se esta tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperacion y comunicacion.
Una vision general del Modelo de Cascada puede ser la siguiente:
El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteracion, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.
Este metodo esta basado en dos importantes principios:
la practica de diseño profesional es caracterizar en terminos de conocer, actuar en situaciones, conversacion con la situacion y reflexion en accion. Hay un distinto medio de proceso - orientacion en esta aproximacion al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que despues meramente lo transcriba. Gran parte del tiempo del diseñador esta inmiscuido en una progresiva relacion con su entorno. Una buena metafora para describirlo es "la conversacion con el material", como un escultor, quien esta ocupado en una conversacion con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser.
la necesidad para diseñadores de tomar la practica de trabajo seriamente, de supervisar las formas en las que el trabajo se esta haciendo, en el sentido de una solucion abierta y desplegada para aumentar la complejidad de una situacion que el diseñador solo entiende parcialmente. El hecho por el cual se esta tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperacion y comunicacion.
Una vision general del Modelo de Cascada puede ser la siguiente:
 |
| Modelo Espiral |
Modelos de Procesos Hibridos
El concepto de Híbrido, empleado para generar nuevos procesos de diseño
Incorporación de nuevas variantes. El diseño desde lo heterogéneo.
Lo sincrético, el mestizaje, la aculturación, la transculturación, la interculturalidad y el multiculturalismo,
lo Híbrido, y su rol en la construcción de nuevos planteamientos del problema, al permitir más posibilidades en la comprensión de la mezcla, sin privilegiar ningún punto de vista limitante.
Incorporación de nuevas variantes. El diseño desde lo heterogéneo.
Lo sincrético, el mestizaje, la aculturación, la transculturación, la interculturalidad y el multiculturalismo,
lo Híbrido, y su rol en la construcción de nuevos planteamientos del problema, al permitir más posibilidades en la comprensión de la mezcla, sin privilegiar ningún punto de vista limitante.
Prototipado
¿En qué consiste?
El prototipado modela el producto final y permite efectuar un test sobre determinados atributos del mismo sin necesidad de que está disponible. Se trata, simplemente, de testear haciendo uso del modelo.
¿Cómo lo llevo a cabo?
Se comienza elaborando un prototipo del producto final: qué aspecto tendrá, cómo funcionará,...Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final. Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina. Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, si bien se pueden obtener magníficos resultados con prototipos de baja fidelidad.
¿Cuándo debería usar esta técnica?
Esta técnica puede ser utilizada en cualquier etapa del desarrollo. A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez más las características del producto final. Llegados a un punto, la construcción de prototipos adicionales resultará menos eficiente que usar las construcciones iniciales para el producto.
Hay un cierto número de términos que se oyen en conjunción con los métodos de prototipado. Los siguientes son una muestra de algunas de estas distinciones
El prototipado modela el producto final y permite efectuar un test sobre determinados atributos del mismo sin necesidad de que está disponible. Se trata, simplemente, de testear haciendo uso del modelo.
¿Cómo lo llevo a cabo?
Se comienza elaborando un prototipo del producto final: qué aspecto tendrá, cómo funcionará,...Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final. Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina. Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, si bien se pueden obtener magníficos resultados con prototipos de baja fidelidad.
¿Cuándo debería usar esta técnica?
Esta técnica puede ser utilizada en cualquier etapa del desarrollo. A medida que el proceso progresa y el producto se completa, el prototipo ha de abarcar, cada vez más las características del producto final. Llegados a un punto, la construcción de prototipos adicionales resultará menos eficiente que usar las construcciones iniciales para el producto.
Hay un cierto número de términos que se oyen en conjunción con los métodos de prototipado. Los siguientes son una muestra de algunas de estas distinciones
 |
| Modelo Prototipado |
Modelo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
 |
| Modelo Evolutivo |
Modelo Cascada
Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. la palabra cascada sugiere, mediante la metafora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.
Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA
Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algun subconjunto de estos requisitos al software.
2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN
Se lleva a cabo teniendo den cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de unproblema.
- Defina las funciones que debe realizar el Software.
- Represente el comportamiendo del Software a consecuencias de acontecimientos externos.
- Divida en forma jerárquica los modelos que represerntan la información, funciones y comportamiento.
Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir.
3.- DISEÑO
Traduce los requisitos en una representacion del Software con la calidad requerida antes de que comience la codificación.
- Diseño del sistema: Se descompone y organiza el sistema en elementos que puedad elaborarse por separado, aprovechando los ventajas del desarrollo en equipo, así como la manera en que se combinan unos con otros.
- Diseño del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.
4.- CODIFICACIÓN
El diseño debe traducirse en una forma legible para la maquina. Se implementa el código fuente. Dependiendo del lenguaje de programacion y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucha más rápido.
5.- PRUEBA
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programacion ( o “bugs” ) y defectos de forma. en un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un rpograma de ordenador. A la versión del producto de pruebas y que es anterior a la versión final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing ( Release To Market ), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.
6.- IMPLANTACIÓN
El Software obtenido se pone en producción. Se implantan los niveles Software y Hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la explotación del sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios.
7.- MANTENIMIENTO
El Software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA
Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algun subconjunto de estos requisitos al software.
2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN
Se lleva a cabo teniendo den cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de unproblema.
- Defina las funciones que debe realizar el Software.
- Represente el comportamiendo del Software a consecuencias de acontecimientos externos.
- Divida en forma jerárquica los modelos que represerntan la información, funciones y comportamiento.
Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir.
3.- DISEÑO
Traduce los requisitos en una representacion del Software con la calidad requerida antes de que comience la codificación.
- Diseño del sistema: Se descompone y organiza el sistema en elementos que puedad elaborarse por separado, aprovechando los ventajas del desarrollo en equipo, así como la manera en que se combinan unos con otros.
- Diseño del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.
4.- CODIFICACIÓN
El diseño debe traducirse en una forma legible para la maquina. Se implementa el código fuente. Dependiendo del lenguaje de programacion y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucha más rápido.
5.- PRUEBA
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programacion ( o “bugs” ) y defectos de forma. en un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un rpograma de ordenador. A la versión del producto de pruebas y que es anterior a la versión final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing ( Release To Market ), dónde se comprueba cada funcionalidad del programa completo en entornos de producción.
6.- IMPLANTACIÓN
El Software obtenido se pone en producción. Se implantan los niveles Software y Hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la explotación del sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios.
7.- MANTENIMIENTO
El Software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
 |
| Modelo Cascada |
Suscribirse a:
Entradas (Atom)