TEMA 1 - ETAPAS DEL CICLO DE DESARROLLO DEL SOFTWARE

Saludos estimados estudiantes, me alegra saber que van avanzando en sus tareas y deberes, y que van logrando también ingresar al foro, ... como vamos aprendiendo en clase, sabemos que los algortimos nos ayudan
a comprender que debemos realizar pasos uno a continuación de otro para lograr una meta, un objetivo, una tarea o un resultado.
Ahora vamos imaginar que debemos elaborar un software para una compañía o empresa, el desafío para este tema será,
investigar cuáles son las etapas del desarrollo de un software.

Este tema tiene tres momentos:
PRIMERO: Colocar en este foro con sus palabras lo que entiende por Etapas del ciclo de desarrollo del software o fases del desarrollo del software u otros términos que se utilicen.
SEGUNDO: para ello, busque un sitio en el Internet o referencia de un libro, indicando de dónde obtuvo la información.
TERCERO: buscar o crear, y colocar una imagen representativa del tema a investigar en su participación.

Les deseo buen inicio de participación, mucho empeño y ánimo,
sé que lo van a lograr.

En la ingeniería del software el término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una etapa en la que se agregan las nuevas características, después una etapa donde se eliminan errores activamente, y finalmente una etapa en donde se han quitado todos los estados importantes . Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los términos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compañías usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las características reales son raramente secretas.

El término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir el mismo.

Existen varias etapas del desarrollo del software....



Se publica a veces antes del lanzamiento de una versión alfa o beta; esta etapa no tiene sus características completas. Los diseñadores todavía están determinando qué funcionalidades debe tener el producto.



Es la primera versión del programa que se envía a los verificadores para probarla. Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.



Representa generalmente la primera versión completa del programa informático o de otro producto, que es probable que sea inestable pero útil para que las demostraciones internas y las inspecciones previas esten de acuerdo con los clientes. Esta etapa se la conoce como inspección previa (preview) o como una inspección previa técnica (technical preview [TP]).



Se refiere a un producto final, preparado para lanzarse como versión definitiva a menos que aparezcan errores que lo impidan.



La versión de disponibilidad general (también llamada "dorada") de un producto es su versión final. Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de último momento. Esta versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una distribución amplia y usada por usuarios finales.



Normalmente distinguen las fases del desarrollo.


===============================================
* EMMANUEL NARVAEZ VELASTEGUI P.21 *
===============================================


http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software

Ciclo de Vida del Software.

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.

Definición de un Modelo de Ciclo de Vida.

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
**Describe las fases principales de desarrollo de software.
**Define las fases primarias esperadas de ser ejecutadas durante esas
fases.
**Ayuda a administrar el progreso del desarrollo, y
**Provee un espacio de trabajo para la definición de un detallado proceso
de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

Hay varios modelos de ciclo de vida del software.
**modelo cascada
**modelo espiral

Espero compañeros de que les sea de gran utilidad este breve resumen, adjunto les dejo algunas paginas sobre este tema.

http://www.lsi.us.es/docencia/get.php?id=856
http://www.ceroble.edu.gt/pcb/sa/bi/v_curso/mapoyo/informatica/ciclo.pdf


Encontre algo muy importante para nuestro conocimiento , La Seguridad con todas las etapas del ciclo de desarrollo del software
adjunto les dejo este otro enlace...

http://www.germinus.com/sala_prensa/articulos/ppos%20basicos%20desarrollo%20seguro.pdf

Primeramente el software es una produccion inmaterial del cerebro humano y tal vez una de las estructura mas complicadas que la humanidad conoce....

Ciclo de desarrollo del software

Planificacion del proyecto.-esta etapa conlleva la planificacion de como se pueden llevar a cabo las etapas del ciclo de vida de la manera mas eficiente.

Definicion del sistema.-en esta etapa se especifica el ambito y los limites de la aplicacion de bases de datos.

Recoleccion y analisis de los requisitos.-en esta etapa se recogen y analizan los requerimientos de los usuarios y de las areas de aplicacion.

Diseño de la base de datos.-en esta etapa consta de tres fases:
*diseño logico
*diseño conceptual
*diseño fisico


Seleccion del SGDB.-Si no se dispone de un SGDB, o el que hay se encuentra obsoleto, se debe escoger un SGDB que sea adecuado para el sistema de infofmacion.

Diseño de la aplicacion.- en esta etapa se diseñan los programas de aplicacion que usaran y procesaran la base de datos. Esta etapa y el diseño y el diseño de la base de datos, son paralelas.

Prototipado.-esta etapa, que es opciona, es para construir prototipos de la aplicacion que permitan a los diseñadores y a los usuarios probar el sistema.

Implementacion.-en esta etapa se crean las definiciones de la base de datos a nivel conceptual, extremo e interno, asi como los programas de aplicacion.

Conversion y carga de datos.-esta etapa es necesaria cuando se esta reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGDB y luego se cargan.

Prueba.-en esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios.

Mantrnimiento.-una vez que el sistema esta completamente implementando y probado, se pone en marcha. En la fase de mantenimiento se llevan a cabo las siguientes tareas:
*Monitorizacion de las prestaciones del sistema
*Mantenimiento y actualizacion del sistema.









refencia

http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/img7.png

http://www.c5.cl/tise97/trabajos/trabajo2/index.htm

Ciclo de vida del software.
Es el proceso que se sigue para construir, entregar y hacer evolucionar al software, desde la concepción de una idea hasta la entrega y el retiro del sitema.
El ciclo de vida cláico del software iendo uno de los más utilizados, está conformado por siete etapas y se lo pueden representar como un modelo cascada:
Ingeniería de Sistemas:
En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema.
-Análisis:
En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema.
-Diseño:
Una vez que se tiene suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar a resolver el problema.
-Implementación:
Partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programaque solucione el problema mediante el uso de una herramienta computacional determinada.
-Pruebas:
Los errores humanos dentro de la programación de las computadoras son muchos y aumentan considerablemente con la complejidad del problema.
-Documentación:
Es la guía o comunicación escrita en sus diferentes formas, ya sea enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa.
-Mantenimiento:
Una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o sastifacer una determinada necesidad.

Ciclo de vida del Software

El desarrollo de un software va en conjunto con un ciclo de vida, compuesto por una serie de etapas.

Etapas

Necesidades
Primero creamos un documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar.

Especificaciones
Ahora se trata de formalizar los requerimientos, el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente.

Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
* Funcional.
* Estático.
* Dinámico.

Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo. Aquí se definirán en detalle entidades y relaciones de las bases de datos, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc...

Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo como de integración del sistema.

Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).


Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa sólamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).





Fuente de la Información
http://www.manycomics.com/ingenieria-del-software/ciclo-vida-software/
http://www.getec.etsit.upm.es/docencia/gproyectos/planificacion/cvida.htm

ETAPAS DEL CICLO DE DESARROLO DEL SOFTWARE

Existen Tres Etapas de este ciclo : Alfa ,Pre Alfa, Beta


ALfa : La fase alfa es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versión para que los programas puedan eviar verificadores para comprobar su verificacion.

El nombre se deriva de alfa, la primera letra en el alfabeto griego.

Pre Alfa : Esta fase es la mas conicida pre-alfa se publica a veces antes del lanzamiento de una versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa no tiene sus características completas. Los diseñadores todavía están determinando en esta etapa exactamente qué funcionalidades debe tener el producto.

BETA : Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.

Cuando una versión beta llega a estar disponible para el público en general que a menudo es utilizada extensamente por los tecnológicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado.

Pre Alfa
La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa no tiene sus características completas. Los diseñadores todavía están determinando en esta etapa exactamente qué funcionalidades debe tener el producto. Tales etapas se pueden llamar también development releases o nightly builds

Alfa
La versión alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versión del programa que se envía a los verificadores para probarla.

Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.

El nombre se deriva de alfa, la primera letra en el alfabeto griego.

Beta
Una versión beta o lanzamiento beta representa generalmente la primera versión completa del programa informático o de otro producto, que es probable que sea inestable pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Algunos desarrolladores se refieren a esta etapa como inspección previa (preview) o como una inspección previa técnica (technical preview [TP]). Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.

El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios.
Expresión de necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener.
Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos
Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de da

Ciclo de vida del software
Definición
'El proceso que se sigue para construir, entregar y
hacer evolucionar el software, desde la concepción
de una idea hasta la entrega y el retiro del sistema.
'Confiable, predecible y eficiente.
Objetivos
' Bohem: determinar el orden de las etapas
involucradas en el desarrollo del software,
establecer el criterio de transición para progresar de
una etapa a la siguiente:
'criterio para determinar la finalización
'criterio para comenzar y elegir la siguiente.
'Así un modelo de proceso apunta a:
'¿Qué debemos hacer a continuación?
'¿Por cuánto tiempo debemos hacerlo?
Modelo de cascada
Estudio de
factibilidad
Ingeniería de
requerimientos
Diseño
Especificación
Codificación
Entrega y

Ciclo de vida del Desarrollo de Software

Estimados profesor y compañeros, para el desarrollo de esta tarea he querido basarme en mi propia experiencia y así compartirla para que de algún modo les sea útil.

He desarrollado software desde algo más de 8 años para diferentes tipos de industria; de estos, los 4 últimos he estado liderando proyectos muy complejos tanto en la empresa donde laboro como en proyectos personales. Puedo afirmales que los mejores resultados se obtienen cuando se invierte, en lo posible, tiempo y recursos en todas las etapas del ciclo de vida del desarrollo de software, ya que ninguna de ellas tiene menos importancia que la otra.

En nuestro medio es bastante complicado seguir esta filosofía al pie de la letra ya sea por los siempre limitados tiempos de desarrollo, el ahorro de recursos, la poca estrategia por parte de los líderes o simplemente porq no existen aun procesos operativos maduros dentro de la organización; sin embargo tratar de aplicarlos en lo posible minimiza los factores de fracazo e incluso reduce los costos finales del proyecto.

Adicionalmente quisiera indicarles que estas fases no solo se pueden aplicar a poryectos de desarrollo, sino a TODO PROYECTO TECNOLOGICO EN QUE NOS EMBARQUEMOS DENTRO DE UNA ORGANIZACION.

Ayudándome de textos teoricos puedo citar como etapas del desarrollo de software las siguientes:

Analisis de los procesos (o si prefieren ¿Qué es lo q vamos a hacer?)
Toda organización de cualquier índole siempre está en busca de mayor competitividad y para ello recurre a proyectos de software ya sea para mejorar sus tiempos de respuesta, reducir costos u optimizar procesos existentes. Basándonos en lo anterior en esta etapa es donde se recoge con detalles cada uno de los requisitos, procesos y flujos de operacion que va a crear o mejorar nuestro software, siendo obligación nuestra la de tener el criterio suficiente para interpretar este levantamiento de información ya que cada usuario, funcionario y mando de la organización tiene su propia visión y representación de las necesidades del área. Para nuestra interpretación debemos tener en cuenta q hay un hilo muy delgado que separa la buena automatización de un proceso de otra que dificulte o entorpezca la operación, con esto quiero decir que debemos ser siempre objetivos en cuanto a los alcances de cada tarea. Una práctica común en esta etapa a más de emitir la documentación del levantamiento es la de generar el MODELO DE ENTIDAD-RELACION del nuevo software que es una guía de todas las entidades participantes y su relación entre si y un prototipo de la Base de Datos (si la hubiere). He descubierto con el paso del tiempo que existe una palabra importantisima que se debe definir en esta etapa y esta es ALCANCE del proyecto, si todos la tienen en claro se evitará caer en el futuro en demoras en la impementación, o en proyectos infinitos que nunca terminan de estar listos.

Arquitectura o especificación (o ¿Con que y Como lo vamos a hacer?)
Aquí es donde decidimos en primera instancia cosas que delinearan y encasillaran el futuro del proyecto, sus mantenimiento y los próximos proyectos dentro de la organización. Se debe elegir la plataforma tecnológica más adecuada para el desarrollo, cosas como: hardware, ambiente de operación del software (desktop, web, movil), plataforma de desarrollo, etc. Luego dependiendo del anterior análisis y paradigma a utilizarse se deben modelar los objetos del sistema, su Base de Datos, informes, procesos corelativos etc. Si se opta por un esquema cliente/servidor y orientado a objetos en esta parte se debe poner principal enfasis a la aruitectura de clases ya que esta será de gran beneficio para el desarollo en si de la aplicación. Actualmente se están usando más herramientas CASE para el desarrollo de aplicaciones y de ser este el caso en esta parte se debe dar enfasis a las entidades y sus reglas. Por último es recomendable definir un estandar para las interfaces de usuario dandole así al nuevo sistema mayor coherencia y lograr que el usuario tenga mejor afinidad con el producto final. Generalmente es bueno separar en etapas de entrega e implementación al proyecto, por tanto en esta parte se pueden definir y negociar que los cronogramas de entrega

Desarrollo (Manos a la obra!!!)
Esta es la etapa en que todo lo analizado y orquestado anteriormente se lleva a código en la plataforma de desarrollo elegida.

Durante esta fase cada parte desarrollada debe someterse a las pruebas de control de calidad, las cuales nos llevará a reducir los errores de operación de nuestro nuevo sistema a la hora de implementarlo.

Antes de la siguiente fase se debe contar con la documentación de todo el proyecto, tanto tecnica, de flujos de operación y procesos, y el famoso manual de usuario que tanto odiaran hacer en el futuro

Implementación
Si tenemos suerte y contamos con gente especialista en Organización y Métodos (O&M, un mal necesario )podremos escapar del trabajo de hacer que nuestro sistema inicie su operación dentro de la organición, de lo contrario no nos quedará otra que asignar tiempo para principalmente: PRESENTAR (muy importante para resaltar los beneficios de nuestro trabajo, y obtener una predisposición al uso de nuestro nuevo sistema), INSTALAR, CAPACITAR AL USUARIO EN EL USO DEL SISTEMA, BRINDARLE SOPORTE (Escuchar sus quejas sobre nuestros muy pequeños y comprensibles errores y corregirlos cuando podamos ).

Mantenimiento
En el mundo actual ocurren cambios tan rápido que afectan a todas las organizaciones y siempre debemos estar atentos a los mismos para brindar nuevos servicios y mejoras sobre el software ya entregado. Esta es una buena practica que nos lleva a la excelencia, ya que no debemos vivir de los cambios que nos pida el propio usuario.

Profesor y compañeros este es mi aporte al foro, espero Ing. que disculpe el atrazo en mi posteo.

Saludos,

OV.

Etapas del ciclo de desarrollo del software


Expresión de necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).



Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.

Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).



Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
* Funcional.
* Estático.
* Dinámico.



Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).



* Observación:
Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirán justificadas en simple política de empresa y por mantener "compatibilidad" en lo que respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte de los casos no serán rumores con fundamento o estudios previos realizados al efecto, sino más bien debidos a la propia publicidad como consejera).



Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

* Observación:
Lamentablemente en la actualidad, año 2.000, quedan bastantes empresas en las que, tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.



Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).



Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).



Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).














Tomado de: http://www.manycomics.com/ingenieria-del-software/ciclo-vida-software
http://lsi.ugr.es/~arroyo/inndoc/inicio.php

En la ingeniería del software el término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una etapa en la que se agregan las nuevas características (etapa alfa), después una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los estados importantes (etapa estable). Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los términos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compañías usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las características reales son raramente secretas.

Pre-alfa

La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa no tiene sus características completas

Alfa

La versión alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versión del programa que se envía a los verificadores para probarla.



Una versión beta o lanzamiento beta representa generalmente la primera versión completa del programa informático o de otro producto, que es probable que sea inestable pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.

Versión candidata a definitiva

El término candidata a definitiva o candidata para el lanzamiento se refiere a un producto final, preparado para lanzarse como versión definitiva a menos que aparezcan errores que lo impidan. En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo.

Versión de disponibilidad general

La versión de disponibilidad general (también llamada "dorada") de un producto es su versión final. Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de último momento. Esta versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una distribución amplia y usada por usuarios finales.

REFERENCIA
http://lsi.ugr.es/~arroyo/inndoc/doc/fases_desarrollo_d.php
http://www.monografias.com/trabajos5/inso/inso.shtml
http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software

GRAFICO

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son:


Análisis: Construye un modelo de los requisitos
Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.
Codificación: Construye el sistema. La salida de esta fase es código ejecutable.
Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.
Las etapas constan de tareas. La documentación es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida según se muestra en la figura 1.1.

Figure: Etapa genérica



Algunos autores dividen la fase del diseño en dos partes: Diseño global o arquitectónico y diseño detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentación y se planifica la integración. En el detallado para cada módulo se refina el diseño, se definen los requisitos del módulo y su documentación.

Las formas de organizar y estructurar la secuencia de ejecución de las tareas en las diferentes fases de cada uno de los métodos puede dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuación realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.



1.2.1 Ciclos de vida en cascada
El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así). La estructura se muestra en la figura 1.2.


Figure 1.2: Ciclo de vida en cascada




1.2.1.1 Descripción
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.

Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:


Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

1.2.1.2 Ventajas

La planificación es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado.

1.2.1.3 Inconvenientes

Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difícil volver atrás.
No se tiene el producto hasta el final, esto quiere decir que:

Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.
El cliente no verá resultados hasta el final, con lo que puede impacientarse .
No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).1.1
Es comparativamente más lento que los demás y el coste es mayor también.

1.2.1.4 Tipos de proyectos para los que es adecuado

Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería.
Se está desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio.
Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.


1.2.1.5 Ciclo de vida en V
Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstracción de cada una. Una fase además de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su estructura está representada en la figura 1.3.


Figure 1.3: Ciclo de vida en V





1.2.1.6 Ciclo de vida tipo sashimi
Según el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón. Una ventaja de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son:


Es aún más difícil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.
Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. En la figura 1.4 se ha representado la estructura del ciclo de vida sashimi.

Figure 1.4: Ciclo de vida sashimi





1.2.1.7 Ciclo de vida en cascada con subproyectos
Si una vez que se ha llegado al diseño arquitectónico, se comprueba que el sistema se divide en varios subsistemas independientes entre sí, sería razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los demás. Cada uno tendrá seguramente fechas de terminación distintas. Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos.



1.2.1.8 Ciclo de vida en cascada incremental
En este caso se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.

Hay dos partes en el ciclo de vida, similares al anterior. Por un lado está el análisis y el diseño global. Por otra parte están los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento. En la figura 1.5 se puede ver su estructura.


Figure 1.5: Cascada incremental





1.2.1.9 Ciclo de vida en cascada con reducción de riesgos
Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo durante las fases de análisis y diseño global. Esto consistiría en:

Preguntar al usuario.
Hacer el diseño global que se desprende del punto 1.
Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y volver con ello al punto 1 para identificar más requisitos o corregir malentendidos.
El resto es igual al ciclo de vida en cascada.


1.2.2 Modelo de ciclo de vida en espiral
Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, etc. Un representación típica de esta estructura se muestra en la figura 1.6.


Figure 1.6: Ciclo de vida en espiral



En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:


Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista

Características del producto.
Formas de gestionar el proyecto.
Restricciones:

Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
Riesgos: Lista de riesgos identificados.
Resolución de riesgos: La técnica más usada es la construcción de prototipos.
Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
Planes: Lo que se va a hacer en la siguiente fase.
Compromiso: Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

1.2.2.1 Ventajas

No necesita una definición completa de los requisitos para empezar a funcionar.
Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

1.2.2.2 Inconvenientes

Es difícil evaluar los riesgos.
Necesita de la participación continua por parte del cliente.
Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

1.2.2.3 Dónde es adecuado

Sistemas de gran tamaño.
Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir al principio todos los requisitos.

1.2.3 Ciclos de vida orientados a objetos
Los tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y diseño estructurados, pero los objetos tienen una particularidad, y es que están basados en componentes que se relacionan entre ellos a través de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Además, hoy en día la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental.

En este texto sólo veremos un tipo de ciclo de vida orientado a objetos, que es además el más representativo, el modelo fuente.



Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto se divide en las fases:


Planificación del negocio
Construcción: Es la más importante y se divide a su vez en otras cinco actividades

Planificación
Investigación
Especificación
Implementación
Revisión
Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos periodos:

Crecimiento: Es el tiempo durante el cual se construye el sistema
Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la figura 1.7 se muestra un esquema de este tipo de ciclo de vida.

Figure 1.7: Ciclo de vida fuente

Diseño del software.-

El proceso de diseño

Diseño de datos
Diseño arquitectónico
Estilos arquitectónicos
Descomposición modular
Conversión de una especificación en una arquitectura software
Análisis de transformaciones
Análisis de transacciones
Diseño de la interfaz de usuario

Un software debe ser estudiado detalladamente antes de ser
implementado como un nuevo sistema de una empresa o compañia.

Att. Paul Salvatierra

Nombre: Diego Hidalgo Palacios Paralelo : #21

Etapas del ciclo de desarrollo de un software


Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.


Especificación

Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.


Diseño y arquitectura

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Según Yourdon consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.


Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga.


Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral.


Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs.


Metodología Tradicional para desarrollar un software.

La tradicional o Teichrow, busca seguir una secuencia, en etapas válidas con tecnologías informáticas o manuales.



Ciclo de desarrollo

- Diagnóstico: Descubrir el problema.

- Factibilidad: Económico, técnico y operacional.

- Diseño Lógico: Informe sobre qué hacer, qué cambiar, eliminar o resolver.

- Diseño Físico: Informe sobre cómo hacerlo, primer contacto con el HW.

- Construcción y Pruebas: Se hacen los programas y estructura de datos, y se prueban.

- Implementación: Significa implementar el nuevo software desarrollado.



El software: es un elemento lógico, por lo que tiene unas características muy diferentes a las del hardware:

El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación. A mediados de la década de 1980, se introdujo el concepto de "fábrica de software", que recomienda el uso de herramientas para el desarrollo automático del software.

Si se representa gráficamente la proporción de fallos en función del tiempo, para el hardware se tiene la figura conocida como "curva de bañera". Al principio de su vida hay bastantes fallos (normalmente por defectos de diseño y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto de suciedad, malos tratos, temperaturas extremas y otras causas. El hardware empieza a estropearse.

El software no se estropea. La gráfica de fallos en función del tiempo, tendría forma de caída desde el principio, hasta mantenerse estable por tiempo casi indefinido. El software no es susceptible a los males del entorno que provocan el deterioro del hardware. Los efectos no detectados harán que falle el programa durante las primeras etapas de su vida, sin embargo una vez corregidas, no se producen nuevos errores. Aunque no se estropea, si puede deteriorarse. Esto sucede debido a los cambios que se efectúan durante su vida.

Att. Diego_Cobain

________________________________________
En la ingeniería del software el término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una etapa en la que se agregan las nuevas características (etapa alfa), después una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los estados importantes (etapa estable). Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los términos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compañías usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las características reales son raramente secretas.


La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa no tiene sus características completas. Los diseñadores todavía están determinando en esta etapa exactamente qué funcionalidades debe tener el producto. Tales etapas se pueden llamar también development releases o nightly builds.


La versión alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versión del programa que se envía a los verificadores para probarla.


Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.
El nombre se deriva de alfa, la primera letra en el alfabeto griego.


Una versión beta o lanzamiento beta representa generalmente la primera versión completa del programa informático o de otro producto, que es probable que sea inestable pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Algunos desarrolladores se refieren a esta etapa como inspección previa (preview) o como una inspección previa técnica (technical preview [TP]). Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final.




Cuando una versión beta llega a estar disponible para el público en general que a menudo es utilizada extensamente por los tecnológicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado.
Generalmente los desarrolladores de las versiones betas del software gratuito o de código abierto los lanzan al público en general, mientras que las versiones beta propietarias van a un grupo relativamente pequeño de probadores. En febrero de 2005, ZDNet publicó un artículo acerca del fenómeno reciente de las versiones beta que permanecían a menudo por años y que eran utilizada como si estuvieran en nivel de producción [1]. Observa que Gmail, igual que las noticias de Google, por ejemplo, han estado en beta por un período de tiempo muy largo y no saldrán del estado beta a pesar del hecho de que se han utilizado extensamente. Esta técnica puede también permitir a un desarrollador retrasar el ofrecimiento de apoyo total o la responsabilidad de ediciones restantes. Los receptores de betas altamente propietarias pueden tener que firmar un acuerdo de no revelación.


Como esta es la segunda etapa en el ciclo de desarrollo que sigue la etapa de alfa, esta se nombra como la siguiente letra griega beta.


La versión de disponibilidad general (también llamada "dorada") de un producto es su versión final. Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de último momento. Esta versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una distribución amplia y usada por usuarios finales. En versiones comerciales, puede estar también firmada (usado para que los usuarios finales verifiquen que el código no ha sido cambiado desde su salida. La expresión de que un producto "se ha dorado" significa que que el código ha sido completado y que "está siendo producido masivamente y estará en venta próximamente".


El término "dorado" se refiere anecdóticamente al uso del "disco maestro de oro" que fue frecuentemente usado para enviar la versión final a los fabricantes que lo usan para producir las copias de venta al detalle. Esto puede ser una herencia de la producción musical. En algunos casos, sin embargo, el disco maestro está realmente hecho de oro, tanto por apariencia estética como por resistencia a la corrosión.
Microsoft y otros usan el término "release to manufacturing" (RTM) para referirse a esta versión (para productos comerciales como Windows XP, tal como "Build 2600 is the Windows XP RTM release"), y "release to Web" (RTW) para productos libremente descargables.


En la programación de código abierto los números de las versiones, o los términos estable e inestable, normalmente distinguen las fases del desarrollo. En el núcleo Linux la versión está formada por cuatro números, separados por un punto. Una cifra impar en el segundo número de la versión indica una versión inestable. En la práctica el uso de números pares e impares para indicar la estabilidad de un producto ha sido usado por otros muchos proyectos de software libre.
Este concepto también se aplica al software empaquetado en algunas distribuciones Linux como Debian, de modo que existie una rama o conjunto de paquetes considerados estables y otra rama considerada inestable. Esta última rama aporta versiones de programas más recientes que la estable pero que no están tan probados.


Fuente: Wikipedia
http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software

Buenas tardes profesor...primero saludandolo espero que este bien...aqui le envio de nuevo mi resumen de etapas de ciclo de desarrollo del software
Evolucionabilidad
'Un software es evolucionable si permite cambios
que lo hacen capaz de satisfacer nuevos
requerimientos.
'Se logra mediante modularización; los sucesivos
cambios tienden a destruir un buen diseño (ver
entropía)
'El diseño original y cada cambio deben hacerse con
esta cualidad en mente.
Otras
'Verificabilidad: es verificable si sus propiedades
pueden verificarse fácilmente.
'Reparabilidad: es reparable si permite la corrección
de sus defectos con una cantidad limitada de trabajo.
'Portabilidad (interoperabilidad): uso (interacción) en
(con) diferentes entornos.
'Productividad, puntualidad, visibilidad.
'Reusabilidad
'Amigabilidad[img][/img]

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).
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).

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.
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.
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.
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.
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)

Nombre: Diego Hidalgo Palacios Paralelo : #21

Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.


Especificación

Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.


Diseño y arquitectura

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Según Yourdon consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.


Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga.


Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral.


Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs.


Metodología Tradicional para desarrollar un software.

La tradicional o Teichrow, busca seguir una secuencia, en etapas válidas con tecnologías informáticas o manuales.



Ciclo de vida


Ciclo de desarrollo

- Diagnóstico: Descubrir el problema.

- Factibilidad: Económico, técnico y operacional.

- Diseño Lógico: Informe sobre qué hacer, qué cambiar, eliminar o resolver.

- Diseño Físico: Informe sobre cómo hacerlo, primer contacto con el HW.

- Construcción y Pruebas: Se hacen los programas y estructura de datos, y se prueban.

- Implementación: Significa implementar el nuevo software desarrollado.



El software: es un elemento lógico, por lo que tiene unas características muy diferentes a las del hardware:

El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación. A mediados de la década de 1980, se introdujo el concepto de "fábrica de software", que recomienda el uso de herramientas para el desarrollo automático del software.

Si se representa gráficamente la proporción de fallos en función del tiempo, para el hardware se tiene la figura conocida como "curva de bañera". Al principio de su vida hay bastantes fallos (normalmente por defectos de diseño y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto de suciedad, malos tratos, temperaturas extremas y otras causas. El hardware empieza a estropearse.

El software no se estropea. La gráfica de fallos en función del tiempo, tendría forma de caída desde el principio, hasta mantenerse estable por tiempo casi indefinido. El software no es susceptible a los males del entorno que provocan el deterioro del hardware. Los efectos no detectados harán que falle el programa durante las primeras etapas de su vida, sin embargo una vez corregidas, no se producen nuevos errores. Aunque no se estropea, si puede deteriorarse. Esto sucede debido a los cambios que se efectúan durante su vida.

Att. Diego_Cobain



Enlace:
www.wikipedia.com/tecnisismos_y_resoluciones_del_software_0023

http://www.chilehardware.com/Articulos/Intel/Centro-de-desarrollo-de-software-en-Cordoba-200611191676.html




http://www.chilehardware.com/foro/imagehosting/64455fdeb316a0f.jpg

Ciclo de vida del Software

Autor: Freddy Mora


El desarrollo de un software va en conjunto con un ciclo de vida, compuesto por una serie de etapas.

Etapas de desarrollo:
Necesidades
Primero creamos un documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar.

Especificaciones
Ahora se trata de formalizar los requerimientos, el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente.

Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
* Funcional.
* Estático.
* Dinámico.

Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo. Aquí se definirán en detalle entidades y relaciones de las bases de datos, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc...

Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo como de integración del sistema.

Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).


Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa sólamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).

http://www.manycomics.com/ingenieria-del-software/ciclo-vida-software
http://www.getec.etsit.upm.es/docencia/gproyectos/planificacion/cvida.htm

Enlaces:

http://www.manycomics.com/ingenieria-del-software/ciclo-vida-software/
http://www.getec.etsit.upm.es/docencia/gproyectos/planificacion/cvida.htm

Diseño del software.-

El proceso de diseño

Diseño de datos

Diseño arquitectónico

Estilos arquitectónicos

Descomposición modular

Conversión de una especificación en una arquitectura software

Análisis de transformaciones

Análisis de transacciones

Diseño de la interfaz de usuario


Un software debe ser estudiado detalladamente antes de ser
implementado como un nuevo sistema de una empresa o compañia.


Enlaces:

http://www.lcc.uma.es/LCC?-f=LCCDocencia/Asignatura.lcc&v_asignatura.idasignatura=76

http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software

http://www.mitecnologico.com/Main/CicloVidaProyectoSoftware

Att. Paul Salvatierra