miércoles, 30 de noviembre de 2011

Ciclos de Vida basados en Prototipos.

En esta entrada les voy a hablar del ciclo de vida basado en prototipos, como ya sabéis el ciclo de vida es un proceso por el cual, los analistas, programadores, ingenieros e inclusive los usuarios (clientes), elaboran sistemas de información y aplicaciones informáticas.

El ciclo de vida basado en prototipos lo encuadraríamos dentro de los ciclos de vida evolutivos, estos ciclos corrigen las carencias más obvias de los ciclos de vida en cascada, ya  que no existe el problema de volver atrás en el ciclo de vida de un programa suponiendo esto  tanto grandes pérdidas tanto de tiempo como económicas incluso llegando al fracaso del proyecto.

Los ciclos de vida evolutivos se basan en ir aproximándose a la consecución del producto software deseado, a tandas, desde las partes más simples e ir iterando fase a fase hasta llegar a un producto software final que deje al cliente satisfecho.

La idea en que se basa el ciclo de vida basado en prototipos es realizar varias iteraciones durante las fases de análisis y diseño global.

En el esquema siguiente queda claramente expresado como seria el proceso:















El ciclo de vida en si sería como el ciclo de vida en cascada pero con la característica de que tiene una especie de “bucle” el cual es el que se reitera dejando una buena base desde un principio.

El ciclo de vida basado en prototipos seria así:

Se haría un buen análisis de los requisitos junto con el cliente.
Se procedería a la ejecución del diseño y construcción del prototipo.
Una vez validado el prototipo por el cliente, si este decide que el producto ya cumple la función deseada, se pasaría a la elaboración detallada del software, en caso contrario se volvería al análisis de requisitos en el cual definiríamos los nuevos requisitos a añadir o los viejos a modificar.

Los prototipos pueden ser prototipo horizontal o vertical:

Los prototipos horizontales son los que exhiben un amplio espectro de las características del sistema pero sin un respaldo de amplia funcionalidad.
Por ejemplo: un prototipo horizontal de un programa de contabilidad, sería implementar un programa que implementara todas las interfaces de ventana, pero sin ninguna funcionalidad.

Los prototipos verticales son los que muestran la funcionalidad exacta de una pequeña parte del conjunto completo de funcionalidades que tendría sistema final.
Por Ejemplo:  Un prototipo vertical de un procesador de textos podría mostrar todas las funciones de comprobación de ortografía y gramática, pero ninguna función relacionada con la entrada de texto o su formato.

Las herramientas para desarrollar este tipo de programas serian como las de cualquier otro, si el programa se hace con un lenguaje interpretado seria más que suficiente un editor de texto y un navegador como por ejemplo firefox. Para programas  escritos en lenguajes compilados se requeriría de un editor de texto y un programa compilador como por ejemplo: dev++, NetBeans, Borland C++ Builder.

Los ciclos de vidas basados en prototipos como todas las cosas tiene tanto sus ventajas como sus inconvenientes:

Ventajas:
-          Los cilos de vida basados en prototipos permiten identificar los requisitos de forma incremental.
-          Permite probar herramientas a los desarrolladores.
-          Mejora la comunicación entre desarrolladores y clientes.
-          Mejora la administración de los proyectos.

Inconvenientes:
-          Los desarrolladores confunden el prototipo con el sistema real. Esto puede derivar en la producción de SW final de baja calidad.
-          El cliente pude confundir el prototipo con el sistema real. Por eso no entienden que las fases de codificación e integración son tan largas.
-          No es posible aplicar la metodología a todos los proyectos software y, finalmente, la mala interpretación puede confundir con el sistema terminado.

-------------------------------------------------------------------------------------------
Fuentes:
- Apuntes Profesor.

viernes, 25 de noviembre de 2011

CICLO DE VIDA EN ESPIRAL


UN POCO DE HISTORIA

Fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final.
Cada ciclo tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior, 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.

DEFINICION

El Modelo en Espiral es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Más que representar al software como una secuencia en cadena de actividades o fases con retrospectiva de una actividad a otra, se representa como una espiral.

Más que representar al software como una secuencia en cadena de actividades o fases con retrospectiva de una actividad a otra, se representa como una espiral.

Vamos a ver mejor como funciona este tipo de ciclo de vida en la siguiente imagen:






CARACTERISTICAS
• Es un ciclo de vida bastante sofisticado: consiste en una serie de ciclos que se
repiten.
• Cada vuelta o iteración tiene las mismas fases y cuando termina, materializa un
objetivo o producto* ampliado con respecto al ciclo anterior.
Nota: un producto puede ser: una especificación formal, un diseño validado, una
prototipo validado, una beta validada, una documentación del sistema, una primera
versión del sistema validada, una segunda versión mejorada, etc. En cada iteración
el producto va madurando y va creciendo en complejidad.
ANALISIS DE RIESGO

Desarrollar, verificar y validar(probar)

  • Tareas de la actividad propia y de prueba.
  • Análisis de alternativas e identificación resolución de riesgos.
  • Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.



Planificar

* Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Tipos de proyectos para el que es adecuado

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


Links Interesantes:

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

http://www.slideshare.net/guest37183b/modelo-de-ciclo-de-vida-en-espiral

http://www.youtube.com/watch?v=-vPONxVik-I










Ciclo de Vida Incremental

CICLO DE VIDA DEL SOFTWARE
[MODELO INCREMENTAL]



El incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofía iterativa.

Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.

Bajo este modelo se entrega software «por partes funcionales más pequeñas», pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.



Hay dos partes en el ciclo de vida, similares al método de uso de prototipos. 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, implementación y mantenimiento.Sin embargo difiere de este en que aquí no se habla de “prototipos” sino de versiones operativas.

Ventajas
  • Es interactivo: con cada incremento se entrega al cliente un producto operacional al cliente, que puede evaluarlo.
  • El primer incremento es a menudo el núcleo.
  • No es necesario tener todos los requisitos en un principio.
  • Los primeros incrementos se pueden implementar con menos recursos.
  • Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
  • Cada versión emitida incorpora a los anteriores incrementos, las funcionalidades y requisitos que fueron analizados como necesarios.
Desventajas
  • Si el sistema a desarrollar es de gran magnitud y se cuenta con un único grupo para construirlo se corre el riesgo que el desarrollo se prolongue demasiado en tiempo.
  • Se requiere de una experiencia importante para definir los incrementos de forma de distribuir en ellos las tareas en forma proporcional.
  • En la primera iteración (primera versión) se puede invertir bastante esfuerzo (ya que es totalmente operativa), y en este sentido la detección tardía de detecciones de errores de requisitos, son bastante traumáticas, e incluso pueden hacer fracasar el proyecto.
Fuentes

http://es.wikipedia.org/wiki/Software#Modelo_iterativo_incremental
http://ciclodevidasoftware.wikispaces.com/CICLO+DE+VIDA+INCREMENTAL
http://cestal.blogspot.com/2010/10/modelos-de-ciclo-de-vida-del-sw.html
http://85517bmdsi.blogspot.com/

Videos

Ciclo de Vida en Cascada tradicional

El Ciclo de Vida en Cascada tradicional es un modelo de enfocar la ingeniería de software basado en un desarollo donde para iniciar cada etapa es necesario finalizar la etapa anterior.


Introducción:
Se le suele llamar modelo convencional, y nace desde el comienzo del desarrollo del software.




Ejemplo de modelo en cascada:




Lo más característicos de esta forma es que cualquier error en una fase hace volver al inicio obligando al rediseño.

Esto produce un esfuerzo adicional y además un coste mas elevado.




Las fases mas importantes y que siempre aparecen en este modelo son:


Análisis de requisitos:
Se analizan las necesidades del usuario para determinar los objetivos y requisitos.
Diseño del Sistema y del Programa:
Se realizan los algoritmos necesarios para obtener los objetivos del "análisis de requisitos"
Codificación:
Se empieza el trabajo para conseguir un código fuente, dónde se pueden usar prototipos y ensallos.
Pruebas:
Comprobación de que todo funcione correctamente.
Verificación:
El usuario ejecuta y verifica el correcto funcionamiento.
Mantenimiento:
Mantenimiento del sistema (requiere muchos recursos)


Problemas comunes:

· La continuidad del proyecto es costoso e implica rehacer trabajo anterior para actualizar los documentos y partos del proyecto.

· Es normal congelar parte del desarrollo y continuar con las siguientes fases.

· Los problemas se dejan para el final, lo que lleva a que estos sean ignorados o corregidos de una forma poco eficaz.

· Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.

· Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.


Es actualmente el modelo más común y cerca del 90% de los proyectos se hacen en este modelo.
Es más beneficioso para proyectos grandes ya que es más fácil realizar cada parte del proceso.

Mantenimiento SW - Tecnicas y herramientas de soporte y atencion al cliente.

El mantenimiento del Software consiste en la corrección de errores de este, después de su entrega. También se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.

Aparte de las actividades realizadas después de la entrega hay otra fase que se dedica a la preparación del mantenimiento. Esta fase inicia antes de que el software este acabado y consiste en la revisión de la documentación para tener una idea de como debe de hacerse el mantenimiento y también influye en la creación del software.


Como se ve, el mantenimiento no es simplemente una actividad post-entrega, sino pre- y post- entrega del software. Para clasificar las actividades tenemos los siguientes, dos puntos.

  1. actividades de mantenimiento posteriores a la entrega.

  2. actividades de preparación para el mantenimiento.

La guía SWEBOK considera que el mantenimiento ocurre durante todo el ciclo de vida.


Herramientas para mantenimiento del Software


Herramientas CASE

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida porComputadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).


Las herramientas case se clasifican en tres grupos: Upper CASE (U-CASE), Middle CASE (M-CASE) yLower CASE (L-CASE). El grupo de herramientas que se dedica al mantenimiento es Lower CASE:


Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones. Una aplicación del tipo CASE es UML Umbrello, que sirve para crear diagramas de desarrollo del software y su documentación.


Pantallazo de Umbrello UML sobre Windows Vista



Herramientas de control remoto


En muchos casos los clientes se encuentran a distancia y el equipo de mantenimiento no puede desplazarse, por lo tanto se implementan aplicaciones de control remoto. Algunas de estas son TeamViewer, VNCviewer y la sesión remota de Windows.


TeamViewer es una de las aplicaciones más utilizadas para control remoto. Tiene versión gratuita y versión de pago. Con TeamViewer se puede conectar a la maquina remota como FTP para pasar ficheros o para control total.



Pagina web official: http://teamviewer.com/en/index.aspx


Centro de llamadas automatizado

¿Que es un asistente automatizado?

Los asistentes automatizados pueden ser conocidos como un asistente o AA auto. Estos sistemas permiten que transfieran a los llamadores entrantes automáticamente a la extensión del dueño sin tener que utilizar a una persona viva, generalmente recepcionista. Si una persona necesita hablar con una persona verdadera, la mayoría de los sistemas permitirán que presionen un número o un símbolo para un operador. La mayoría de los sistemas modernos, tales como PBX y sistemas de teléfono dominante vienen con los asistentes automatizados como una característica de estándar, pero éstos se pueden también instalar en líneas telefónicas estándares, también.

Cuando uno llama y recibe a asistentes automatizados de una compañía, hay generalmente algunos tipos de directorios puestos en ejecución en el sistema para encontrar la persona o el área que están buscando. Algunos tienen un sistema del "dial-por-nombre" instalado, donde el sistema enumera nombres por el nombre pasado. Un llamador puede entonces prensa # o un símbolo similar en su teléfono cuando se anuncia ese nombre, y llamará automáticamente ese a personas extensión. Un sistema más popular pide que el llamador marque la extensión de una persona automáticamente si se sabe. Si no es, el llamador puede entonces escuchar una lista de opciones para conseguir su llamada dirigida a la persona adecuada.



FAQ Del Asistente Automatizado

Hay muchas diversas aplicaciones que los varios lugares tendrán para los asistentes automatizados. Principalmente, está liberar para arriba líneas de los llamadores que tienen las mismas preguntas generales que se pueden contestar fácilmente, por ejemplo horas de la compañía, las direcciones, y más. Después de que se jueguen estos mensajes, el llamador tendrá una opción de oír más mensajes, o fue transferido a una recepcionista si tienen una pregunta que no pueden encontrar la respuesta a. Utilizan a estos asistentes automatizados también con frecuencia para los programas del gobierno, los números de la información, y las universidades y los sistemas escolares uniformes.

Hay otras características que se pueden utilizar de un sistema acompañante automatizado, tal como transferencia de una llamada a una línea telefónica exterior o conectar a dos diversas compañías usando establecimiento de una red del ancho-área. Los asistentes automatizados deben ser programados muy cuidadosamente, de modo que un llamador pueda conseguir la información que necesitan rápidamente y fácilmente. Muchas compañías grandes hacen también que un llamador pasa con una serie sin fin de menús antes de que puedan conseguir realmente la respuesta que la necesiten, o hagan cerca de imposible conseguir a una persona viva.


Tele-a-Greeter-uno-Greeter

Un tipo de asistentes automatizados se llama greeters del teléfono, o un tele'fono-uno-greeter. Cuando un llamador telefona en una compañía, las respuestas un tele'fono-uno-greeter la llamada y entonces los defienden con un tipo informativo de saludo. Los llamadores pueden elegir de mensajes previos de antemano o el OPT para un vivo toma de una persona verdadera para ayudarle. La mayoría del tele'fono-uno-greeters se hace para manejar un número de llamadas a la vez, con diversas líneas que tomen el mismo número de teléfono.

Hay muchas razones que una compañía o un negocio utiliza greeters del teléfono. Muchas llamadas que vienen adentro son gente que pide los mismos tipos de preguntas, tales como las horas de oficinas de la operación, de direcciones, y así sucesivamente. Los greeters del teléfono pueden manejar estos tipos de llamadas ofreciendo el mensaje derecho para la pregunta derecha, así liberando encima del tiempo de un personal. Los mensajes registrados en estos greeters del teléfono se pueden hacer típicamente en la localización, o aún remotamente usar un código especial. Son generalmente contraseña protegida, no apenas cualquier persona puede tener acceso y cambiar tan a un saludo. La mayoría de los sistemas también ofrecen mensajes separados del día y de la noche, y los mensajes del asimiento se pueden programar a tener gusto de los dueños.

Hay diversos tipos de greeters del teléfono que puedan manejar una diversa cantidad de negocio y de llamadas. Los sistemas automatizados de los asistentes se modifican para requisitos particulares para una variedad de negocios.

Symposium Call center es un centro PBX o asistente virtual de telefonia.

Para más información visita la pagina web oficial de Symposium: http://www.itcom.itd.umich.edu/telephone/symposium.html

FUENTES:


http://cnx.org/content/m17404/latest/


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


Ciclo de Vida tipo Sashimi


¿Os preguntais el porque de esta palabra "Sashimi"...?
...porque tiene fases solapadas, como el pescado japonés "sashimi"...
El modelo Sashimi fue creado originalmente por Peter DeGrace...
A veces se hace referencia a él como el modelo en cascada con fases superpuestas o el modelo en cascada con retroalimentación. Ya que las fases en el modelo sashimi se superponen, lo que implica que se puede actuar durante las etapas anteriores.



Por ejemplo...


Ya que las fases de diseño e implementación se superpondrán en el modelo sashimi, los problemas de implementación se pueden descubrir durante las fases de diseño e implementación del proceso de desarrollo. Esto ayuda a aliviar muchos de los problemas asociadas con la filosofía del modelo en cascada.



Al utilizar este ciclo de vida se obtiene una ganancia de calidad en elproducto final, además de que no hace necesario unadocumentación detallada para cada etapa, ya que por el mismohecho de que estas se solapan, comparten partes de la documentación.

PERO COMO EN TODOS LOS SITIOS...
EXISTEN PROBLEMAS QUE SE PRESENTAN
AL UTILIZAR ESTE MODELO...




Existe la dificultad de identificar el inicio y el fin decada etapa, además de que en caso de presentarse problemas decomunicación estos van a generar 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.



ESTRUCTURA DEL TIPO DE VIDA SASHIMI:














Espero que os guste...Un saludo

miércoles, 23 de noviembre de 2011

Nou Look

Vos agrada? espere comentaris...