PREGUNTAS DETONANTES "MODELOS DE DESARROLLO"

Ir abajo

PREGUNTAS DETONANTES "MODELOS DE DESARROLLO"

Mensaje  Admin el Miér Nov 21, 2012 10:32 pm

QUE TAL ALUMNOS, NUEVAMENTE LES DOY LA BIENVENIDA A ESTE FORO DE DISCUSIÓN. LAS SIGUIENTES PREGUNTAS SERVIRAN COMO PUNTO DE PARTIDA PARA ESTA NUEVA FASE, EN LA CUAL DEBERAN CONTESTAR A UNA DE ELLAS, SIGUIENDO LA MISMA DINAMICA DE LAS APORTACIONES ANTERIORES. SU RESPUESTA SERA REVISADA POR EL PROFESOR. ELIJA MUY BIEN SU PREGUNTA YA QUE SERÁ LA UNICA PARA EVALUAR SU PARTICIPACIÓN EN ESTA UNIDAD. PUEDE INCLUIR: IMAGENES, VINCULOS, VIDEOS, ETC.

Suerte!!!!!

1. Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo? Justifique.
2. Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?. Justifique
3. Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software. Explique
4. Porqué utilizar herramientas CASE en el proceso de desarrollo de software. Qué relación tienen estas herramientas con los modelos de desarrollo? Justifique
5. Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?. Justifique
6. En tu opinión, en que fases del ciclo de vida del software se justifica el uso de herramientas CASE, cuál recomendarias y porqué?.

Admin
Admin

Mensajes : 13
Fecha de inscripción : 09/03/2012

Ver perfil de usuario http://fundamentos-si-itsrl.foroactivo.mx

Volver arriba Ir abajo

Aport #1 ¿Porqué utilizar herramientas CASE en el proceso de desarrollo de software. ¿Qué relación tienen estas herramientas con los modelos de desarrollo?

Mensaje  yessica liliana el Mar Nov 27, 2012 2:18 pm

Aport #1 ¿Porqué utilizar herramientas CASE en el proceso de desarrollo de software. ¿Qué relación tienen estas herramientas con los modelos de desarrollo?

Hola maestra buenas tardes Con respecto a la pregunta que realizo ¿Porqué utilizar herramientas CASE en el proceso de desarrollo de software. ¿Qué relación tienen estas herramientas con los modelos de desarrollo?
Me e dado a la tarea de investigar lo siguiente: las herramientas Case Computer Aided Assisted Automated Software Systems Engineering (Ingeniería de Software asistida por computadoras), entonces estas herramientas son un conjunto de programas y ayudas, que dan asistencia a analistas, Ingenieros de software y desarrolladores durante el Ciclo de vida de desarrollo de Software.

Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.
Juegos de herramientas o toolkits, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Otra posible clasificación, utilizando la funcionalidad como criterio principal, es la siguiente:
• Herramientas de gestión de proyectos
• Herramientas de gestión y configuración de software (SCM)
• Herramientas de calidad y seguridad de software
• Herramientas de análisis y diseño
• Herramientas de desarrollo de interfaz de usuarios
• Herramientas para la Ingeniería de Software Orientada a Objetos
• Herramientas de integración y prueba
• Herramientas de métodos formales
• Herramientas Cliente/Servidor
• Herramientas de Ingeniería WEB
• Herramientas de Reingeniería
• Beneficios de las Herramientas CASE
Entre los beneficios más significativos de las herramientas CASE se enumeran los siguientes:
• 1. Facilidad para la revisión de aplicaciones
La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.
• 2. Soporte para el desarrollo de prototipos de sistemas
En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos.
• 3. Generación de código
La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos.
• 4. Mejora en la habilidad para satisfacer los requerimientos del usuario
Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.
• 5. Soporte interactivo para el proceso de desarrollo
La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.
2. Ejemplos de Herramientas CASE
Las herramientas CASE se han venido ampliando y desarrollando, existe una gran variedad de estas con características específicas, a continuación describiremos algunas de ellas, desde las más actuales hasta otras ya no tanto.

ejemplos:
1. Microsoft Project
Microsoft Project es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.
Permite el aprendizaje rápido con el planeamiento y la administración guiados, organización y seguimiento de las tareas y recursos, comparar versiones de planes de proyectos, evaluar los cambios, realizar un seguimiento del rendimiento, generar informes predefinidos, compartir planes de proyecto, colaboración entre grupos de trabajo, presenta diagramas como: Diagrama de Grant y Diagrama de Pert (diagrama de red).
El software Microsoft Office Project en todas sus versiones (la versión 2007 es la más reciente) es útil para la gestión de proyectos, aplicando procedimientos descritos en el PMBoK (Management Body of Knowledge) del PMI (Project Management Institute).
La primera versión de Microsoft Project fue lanzada para DOS en 1984 por una compañía que trabajaba para Microsoft. Microsoft adquirió todos los derechos del software en 1985 y liberó la versión 2. La versión 3 para DOS fue liberada en 1986. La versión 4 para DOS fue la última versión para este sistema operativo, liberada en 1987. La primera versión para Windows fue liberada en 1990, y fue llamada versión 1 para Windows. Un dato interesante es que la primera versión para DOS introdujo el concepto de Líneas de dependencia (link lines) entre tareas en la gráfica de Gantt.
Una versión para Macintosh fue liberada en julio de 1991 y su desarrollo continuó hasta Project 4.0 para Mac en 1993. En 1994, Microsoft detuvo el desarrollo para la mayoría de las aplicaciones Mac, y no ofreció nuevas versiones de Office hasta 1998, después de la creación del nuevo Microsoft Macintosh Business Unit el año anterior. El MacBU nunca lanzó una versión actualizada para Proyect, y la versión anterior de 1993 no es ejecutada nativamente en Mac OS X.
Las versiones fueron lanzadas en 1992 (v3), 1993 (v4), 1995, 1998, 2000, 2002, 2003 y 2007
La aplicación crea calendarización de rutas criticas, además de cadenas críticas y metodología de eventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resource leveled, y las gráficas visualizadas en una Gráfica de Gantt. Adicionalmente, Project puede reconocer diferentes clases de usuarios, los cuales pueden contar con distintos niveles de acceso a proyectos, vistas y otros datos. Los objetos personalizables como calendarios, vistas, tablas, filtros y campos, son almacenados en un servidor que comparte la información a todos los usuarios.
La familia de Microsoft Project incluye: Microsoft Project Standard, Microsoft Project Professional, Microsoft Project Server y Microsoft Project Web Access.
Microsoft Project y Project Server son piezas angulares del Microsoft Office Enterprise Project Management (EPM).
Microsoft reveló que las futuras versiones de Microsoft Project contarán con Interfaz de usuario fluida.

2. MagicDraw
MagicDraw es una herramienta de modelaje con completas características UML, sin duda es una de las mejores herramientas CASE del mercado, que procura mantenerse además siempre al día con continuas actualizaciones. Es desarrollada por No Magic, Inc. Implementada totalmente en JAVA. Diseñada para los analistas del negocio, los analistas del software, los programadores, los ingenieros de software, y los escritores de la documentación, esta herramienta de desarrollo dinámica y versátil facilita análisis y el diseño de los sistemas y de las bases de datos orientados objeto.
Características principales:
• Interfaz elegante e intuitiva, la mayor parte de las opciones accesibles con un solo click.
• Ayudas en el diseño con autocompletación y corrección automática en tiempo real.
• Permite visualizar el proyecto de diferentes formas.
• Posible derivación de modelos UML a través de códigos fuente escritos anteriormente.
• Facilidad y rapidez para el cambio del dominio del modelado.
• Generador automático de informes.
• Desarrollo colaborativo directamente con la herramienta a través del Team Work Server (Software que permite trabajar a más de un desarrollador sobre el mismo proyecto en el mismo instante, el modelo está almacenado en un equipo servidor y los desarrolladores pueden consultar y actualizar la información).
• Disponible para un gran número de plataformas y sistemas operativos.

3. Microsoft Visio
Microsoft Visio es un software de diagramas para Microsoft Windows. Usa gráficos de vectores para crear diversos diagramas. Facilita a los profesionales empresariales y de Tecnologías de la Información la visualización, el análisis y la comunicación de información compleja. Los diagramas de Visio comunican información de un vistazo, conectados a datos muestran información, son fáciles de actualizar y pueden aumentar espectacularmente la productividad. La amplia variedad de diagramas de Microsoft Visio permite comprender, procesar y compartir información sobre los sistemas, recursos y procesos organizativos de una empresa.
Micorsoft Visio está disponible en dos ediciones independientes: Office Visio Professional y Office Visio Standard. Office Visio Standard tiene la misma funcionalidad básica que Office Visio Professional e incluye un subconjunto de sus características y plantillas. Office Visio Professional ofrece funcionalidad avanzada, como conectividad de datos y características de visualización, que no se incluyen en Office Visio Standard. Ambas ediciones, Standard y Professional, comparten la misma interfaz.
Microsoft adquiere Visio Corporation en 2000. Visio 2007 fue liberado el 30 de noviembre del 2006.
Microsoft reveló que la siguiente versión de Microsoft Visio presentará un cordón de unión entre interfaces de usuario.

4. Enterprise Architect
Enterprise Architect (EA) Professional es una herramienta CASE de Sparx Systems. Soporta ocho de los nueve diagramas estándares del UML: diagrama de casos de uso, de clases, de secuencia, de colaboración, de actividad, de estados, de implementación (componentes), de despliegue y varios perfiles del UML. Si fuera necesario, el diagrama de objetos se puede crear usando los diagramas de colaboración.
Enterprise Architect tiene un mecanismo de perfil UML genérico para cargar y trabajar con diferentes perfiles UML. En Enterprise Architect, estos perfiles se especifican en archivos XML con un formato específico. Los perfiles disponibles son:
Modelado de Procesos de Negocio: Soporta las extensiones de modelado de procesos de negocio de Eriksson-Penker.
Modelado de Datos.
Modelado de la Interfaz de Usuario.
Modelado Web.
Esquema XSD
Permite ingeniería de código (directa e inversa) para ANSI C++, Visual Basic 6, Java, C#, VB.NET, Delphi y Bases de datos: Ingeniería directa desde el modelo de datos al script DDL. La ingeniería reversa usa la fuente de datos ODBC.
La forma en la que EA trabaja es generando los archivos de código fuente de las clases para aquellas que correspondan al mismo paquete. Adicionalmente, se pueden aplicar los patrones de diseño, el usuario tiene que crear los patrones.

5. CASE Studio
Herramienta con potente utilidad de modelado para varias bases de datos. CASE Studio es una herramienta profesional con la que pueden diseñarse bases de datos, incluye facilidades para la creación de diagramas de relación, modelado de datos y gestión de estructuras. Tiene soporte para trabajar con una amplia variedad de formatos de base de datos (Oracle, SQL, MySQL, PostgreSQL, Access) y permite además generar xcripts SQL, aplicar procesos de ingeniería inversa, usar plantillas de diseño personalizables y crear detallados informes en HTML y RTF.



Conclusiones
La herramientas CASE actualmente brindan una gran gama de componentes que incluyen todos o la mayoría de los requisitos necesarios para el desarrollo de los sistemas, han sido creadas con una gran exactitud en torno a las necesidades de los desarrolladores de software para la automatización de procesos incluyendo el análisis, diseño e implantación. Ofrecen una gran plataforma de seguridad a sistemas que las usan.
Debido a la demanda que tienen las CASE, su exigencia en cuanto a su uso ha ido aumentando, por lo que toda CASE debe entre otras cosas: proporcionar topologías de aplicación flexibles, proporcionar aplicaciones portátiles, brindar un Control de versión, crear código compilado en el servidor, dar un Soporte multiusuario y ofrecer seguridad.
Las herramientas CASE cuentan con una credibilidad y exactitud que tienen un reconocimiento universal, siendo usadas por cualquier desarrollador y/o programador que busca un resultado óptimo y eficiente.

En mi opinión utilizar herramientas case nos servirá para dar asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Además de que nos ayuda a la innovación de en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización.
El uso de herramientas case nos servirá para permiten integrar el proceso de ciclo de vida:
• Análisis de datos y procesos integrados mediante un repositorio.
• Generación de interfaces entre el análisis y el diseño.
• Generación del código a partir del diseño.
• Control de mantenimiento.
La relación que tienen las herramientas case con los modelos de desarrollo es que dependiendo de cada modelo que se escoja se cuenta con herramientas case para Mejorar la productividad en el desarrollo y mantenimiento del software, Así como para aumentar la calidad del software, mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos, mejorar la planificación de un proyecto, aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos, Automatizar, desarrollo del software, documentación, generación de código, pruebas de errores y gestión del proyecto, Ayuda a la reutilización del software, portabilidad y estandarización de la documentación, gestión global en todas las fases de desarrollo de software con una misma herramienta, Facilitar el uso de las distintas metodologías propias de la ingeniería del software, etc.
Con todo esto e llegado a cuestionarme lo siguiente: ¿Qué desventajas tendría la utilización de las herramientas case?

yessica liliana

Mensajes : 8
Fecha de inscripción : 26/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

APORT #1 ¿Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?

Mensaje  Carlos Rivera el Mar Nov 27, 2012 3:45 pm

Hola maestra, de nuevo por aquí, con respecto a la pregunta 5, ¿qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar? me di a la tarea a investigar lo siguiente:

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software.

El modelo Scrum tiene varias caracteisticas:

1.-Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
2.-Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
3.-Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
4.-Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.
5.-Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
6.-Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

En el Scrum existen varios roles que son:

a) Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario y las prioriza.
b) ScrumMaster o Facilitador
ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo, sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
c) Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc)
d) Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
e) Administradores
Es la gente que establece el ambiente para el desarrollo del producto.

El Scrum se distingue porque constantemente existen reuniones, ya sea para analizar sobe un proyecto, revisar uno ya existente, etc.
a continuacion redactare los pasos de cada reunion:

Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)
Todos son bienvenidos, pero sólo los responsables pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?

Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.
La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:
¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
Seleccionar qué trabajo se hará
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como límite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”

Reunión de Revisión del Sprint
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados
El trabajo incompleto no puede ser demostrado
Cuatro horas como límite

Retrospectiva del Sprint
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Este modelo es ampliamente recomendado para empresas de productos tecnológicos como la CONALEP, empresas que se encargan de los procesos desarrollados para dar solución a problemas técnicos y operativos específicos de las empresas, mediante acciones que impulsen el incremento de su productividad, competitividad y la calidad de sus productos o servicios, y empresas en entornos con requisitos inestables y que requieren rapidez y flexibilidad.

mi pregunta seria, ¿el ITSRLL podra pone en practica este modelo, y si no, donde lo puede poner?

Carlos Rivera

Mensajes : 8
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport 1 Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo? Justifique

Mensaje  OmarSoto el Mar Nov 27, 2012 3:56 pm

muy buenas tardes compañeros . con relacion a la pregunta Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo? Justifique que realizo la maestra me di a la tarea de responder lo siguiente

El modelo en espiral (Win-Win) se recomienda ser usado en la elaboración de sistemas complejos ya que permite al desarrollador elaborar el sistema en forma que se completa el sistema completo porque ya que es un modelo repetitivo se puede realizar el proceso un número infinito de veces
El modelo en espiral se realiza comenzando desde el bucle interior , en este se pueden llevar a cabo varias etapas como los son








OmarSoto

Mensajes : 8
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

APORT#1 ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software?. Explique

Mensaje  j_miguel_angulo_mendoza el Mar Nov 27, 2012 6:47 pm

* Hola maestra una vez más por aquí bueno pues con respuesta a la pregunta “3. ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software? “pues logre investigar lo siguiente esperando resolver tal pregunta:

DEFINICIÓN DE CALIDAD SOFTWARE
Definiciones: Calidad del Software

La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. [IEEE, Std 610-1900]
Concordancia del software producido con los requerimientos explicitamente establecidos, con los estandares de desarrollo prefijados y con los requerimientos implicitos no establecidos formalmente, que desea el usuario. [Pressman, 1998]

La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
La calidad del software es aquel proceso en donde se verifica que el software o aplicación cumpla con los requerimientos o necesidades del cliente, integrando la velocidad de respuesta de la aplicación, el sistema de seguridad y confiabilidad.
También se puede definir como la coordinación, integridad y la aplicación de los estándares que tiene que ver con la correcta funcionabilidad y desarrollo de una aplicación.

No hay que olvidar la evolución de las propuestas de calidad que son:
-Factores de revisión: flexibilidad, mantenibilidad y contestación.
-Factores de transición: portabilidad, reusabilidad y interoperabilidad
-Factores de operación: eficiencia, integridad, usabilidad, fiabilidad y corrección.

También se debe tener en cuenta que en el mantenimiento de hardware es muy diferente al de software, porque el hardware se puede reemplazar la pieza, mientras el software requiere de ingeniería, el software no se deteriora con el tiempo pues su curva de fallos es muy diferente a la de hardware.







UN MODELO DE DESARROLLO DE SOFTWARE

Es la construcción de un producto de software que involucra varias etapas y actividades y el orden en que éstas se realizan definen el ciclo de vida del software.
El proceso seguido para desarrollar, liberar y evolucionar en distintas versiones un producto de software, desde la concepción de una idea hasta la concreción de la misma se conoce como el proceso de software. En general, un proceso disciplinado es seguido en forma consistente cuando todos los participantes entienden el valor de hacerlo y existe en la Organización la infraestructura necesaria para brindar el soporte requerido. El Modelo de Desarrollo de Software es principalmente una adaptación del Unified Process (UP. Este proceso plantea un enfoque de desarrollo iterativo incremental que permite un entendimiento progresivo de los requerimientos del sistema a través de sucesivos refinamientos y el crecimiento incremental de una solución efectiva al problema planteado, permitiendo también que los riesgos del proyecto sean identificados en cada etapa del desarrollo, ayudando a reducirlos significativamente.
El desarrollo está basado en casos de uso para capturar los requerimientos y asegurar que éstos guían el diseño, implementación y verificación del software. Es centrado en la Arquitectura del Software, realizando la definición y construcción de ésta en etapas tempranas del desarrollo, lo que permite reducir los riesgos tecnológicos asociados, y sobre la cual se construirán incrementalmente el resto de las funcionalidades del sistema. Para el modelado en las disciplinas se utiliza el lenguaje UML.




* Pues respecto a la información que encontré me llevo a lo siguiente:

•La calidad de software y el modelo de desarrollo de software se llevan de la mano ya que al realizar o implementar un modelo de software es necesario contar con un control de calidad de software pues de no ser así no podría ser creado o modificado el modelo de desarrollo, pues para evolucionar un modelo de desarrollo de software necesita cumplir con ciertos sistemas de calidad del software que le brinden la seguridad de que este nuevo modelo implementado o modificado funcione correctamente y cumpla con las expectativas dadas.

* Bueno pues me despido de usted maestra esperando haber respondido su pregunta no sin antes realizar una pregunta ya que una duda surgió ¿Cual se implementa primeramente dentro de un modelo ya establecido para poderlo evolucionar o mejorar? que pase buena tarde.

Links de informacion:
MODELO DE DESARROLLO DE SOFTWARE: www.fing.edu.uy/~bperez/public/ModOOJIISIC.pdf
DEFINICION DE CALIDAD DE SOFTWARE: www.rodolfoquispe.org/blog/que-es-la-calidad-de-software.php

j_miguel_angulo_mendoza

Mensajes : 8
Fecha de inscripción : 26/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

practica num 1 Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?. Justifique

Mensaje  raul_gerardo el Mar Nov 27, 2012 7:17 pm

Hola compañeros que tal espero estén de maravilla y tenga un buen dia bueno con respecto a la pregunta de la maestra ¿qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?
Mi investigación fue la siguiente
¿Que es el modelo scrum?
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders(interesados externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
Roles Principales
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.
Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.

¿Por que utilizar el scrum y en que casos utilizarlo?
En general, las aplicaciones Web cumplen la mayor parte de las características que se mencionan en el epígrafe II.2.2, por lo que la utilización de procesos ágiles podría ser ventajoso para este tipo de desarrollos. La necesidad del cliente que contrata un desarrollo Web es que su producto esté disponible en la red lo más pronto posible. Si no se tiene en cuenta esta necesidad, la aplicación no resultará un producto provechoso para el cliente. Puesto que los procesos ágiles permiten tener versiones de producto previas a la versión final, si se aplican correctamente estos procesos el cliente podrá disponer de forma rápida de alguna versión intermedia. Además el ciclo de desarrollo de la mayoría de los sitios y aplicaciones Web es extremadamente corto [47]. Por otra parte, los desarrollos Web se perciben como desarrollos sencillos y los desarrolladores son sometidos a una gran presión de trabajo para terminar lo más pronto posible. Esta forma de trabajar implica, sin duda alguna, modificaciones. Luego sería conveniente garantizar un proceso de desarrollo adaptable a los cambios. Otra cuestión fundamental a tener en cuenta es que las aplicaciones Web se desarrollan sin conocer los perfiles de los usuarios finales de las mismas, o lo que es lo mismo sin conocer los requisitos de usuario del sistema. Sin lugar a dudas esto implicará cambios en los requisitos inicialmente detectados, lo que lleva de nuevo a la elección de un proceso adaptativo.
Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
En esta metodología se realizan entregas parciales del resultado final del proyecto, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad y la productividad son fundamentales.
Aunque Scrum surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software, y donde al aplicarlo proporciona ventajas como:
• Entrega de un producto funcional al finalizar cada iteración.
• Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente.
• Visualización del proyecto día a día.
• Alcance acotado y viable.
• Equipos integrados y comprometidos con el proyecto, toda vez que ellos definieron el proyecto.
Entre principales beneficios que reporta utilizar Scrum como metodología de desarrollo de un sistema se encuentran además: [48]
• Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:
o Gestión regular de las expectativas del cliente y basada en resultados tangibles. El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado; y comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta.
o Resultados anticipados (time to market). El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.
o Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc. De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de desarrollo, etc.
o Gestión sistemática del Retorno de Inversión (ROI). De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto.
o Mitigación sistemática de los riesgos del proyecto. Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones
• Productividad y calidad. De manera regular el equipo va mejorando y simplificando su forma de trabajar.
• Alineamiento entre el cliente y el equipo de desarrollo. Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos.
• Equipo motivado. Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.
Muchos desarrolladores en la actualidad se ven en la disyuntiva de utilizar Extreme Programming o Scrum en sus sistemas pero es válido aclarar que XP es recomendable emplearlo solo en proyectos a corto plazo y reporta altas comisiones en caso de fallar, además puede no ser más fácil que el desarrollo tradicional; los usuarios pueden no querer frecuentes pequeños releases y requiere un rígido ajuste a los principios XP. Además es difícil predecir costo y tiempo de desarrollo ya que no se precisa los elementos a acoplarse en el proyecto y mantener el producto puede ser difícil, debido a que tiene muy poca documentación.
Ala mejor es la información es algo compleja pero intento que sea lo mas completa acontinuacion dejare dos videos de este modelo de desarrollo de software scrum, mi pregunta seria que ¿tan confiable es este modelo y cuales son sus desventajas?

fuente de consulta http://www.ecured.cu/index.php/Metodolog%C3%ADa_Scrum

https://www.youtube.com/watch?v=v5Mrwk7KkE4&feature=related

espero la información les sea de utili compañeros.


Última edición por raul_gerardo el Jue Nov 29, 2012 3:47 pm, editado 1 vez
avatar
raul_gerardo

Mensajes : 8
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?

Mensaje  Viviana Sosa el Mar Nov 27, 2012 7:38 pm

Hola compañeros y maestra!! Bueno yo voy a responder la pregunta Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?


Ventajas del Modelo de Desarrollo de Software

Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por: reducción de la incertidumbre y del riesgo, reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema, mejoras en la administración de proyectos, mejoras en la comunicación entre desarrolladores y clientes, impone la necesidad de mucha disciplina planificación y administración, en el proceso de desarrollo de software, venciendo así la filosofía de los procesos de codificar y probar, impone la necesidad de que la realización del producto debe ser pospuesta hasta que los objetivos sean bien entendidos.



MODELOS MÁS RECOMENDADOS:
El modelo de codificar y fijar
El modelo básico usado en los primeros días del desarrollo de software, tiene dos pasos:
(1) Escribir algún código.
(2) Fijar los problemas en el código.
Así, el orden de los pasos era fabricar algún código primero y pensar sobre los requerimientos, diseño, prueba y mantención a continuación. Este modelo tiene las dificultades de presentar una baja estructuración del código luego de alguna cantidad de fijaciones, pese a que se puede desarrollar un software de calidad, es posible que éste tenga una correspondencia muy pobre con las reales necesidades del usuario y, finalmente, si no existe la conciencia de la necesidad real de pruebas y modificaciones el costo de las sucesivas fijaciones será muy alto.
Este método resume las características de los métodos más formales desarrollados posteriormente, primero, la desvinculación con el problema: hay, de partida dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa. Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos.
En el sentido real, el ingeniero de programación crea modelos de situaciones físicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solución computacional del problema. Un principio fundamental de la ingeniería de programación es diseñar productos que minimicen la distancia intelectual entre el problema y la solución.
La variedad de enfoques en el desarrollo de programas está limitado únicamente por la creatividad e ingenio del programador; no siempre se encuentra con claridad el enfoque que minimice esta distancia, e incluso diferentes enfoques minimizan distintas dimensiones de la distancia.
Pero, por otro lado, la primera evolución con relación a los métodos es el resultado de las deficiencias presentadas por método de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitiría incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificación, coordinación y control. Esto también coincide con el tamaño de los problemas a resolver, el que se va incrementando debido, sobre todo, al aumento de las capacidades del hardware.


El modelo de etapas
En 1956, el enfrentarse a un gran sistema de software como el Semi-Automated Ground Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificación y esto llevó al desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo estipula que el software será desarrollado en sucesivas etapas:
*Plan operativo
Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se identifica cualquier restricción aplicable al proyecto.
*Especificación de requerimientos
Permite entregar una visión de alto nivel sobre el proyecto, poniendo énfasis en la descripción del problema desde el punto de vista de los clientes y desarrolladores. También se considera la posibilidad de una planificación de los recursos sobre una escala de tiempos.
*Especificación funcional
Especifica la información sobre la cual el software a desarrollar trabajará.
*Diseño
Permite describir como el sistema va a satisfacer los requerimientos. Esta etapa a menudo tiene diferentes niveles de detalle. Los niveles más altos de detalle generalmente describen los componentes o módulos que formarán el software a ser producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que contendrá el sistema.
*Implementación
Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño del proyecto, la programación puede ser distribuida entre distintos programadores o grupos de programadores. Cada uno se concentrará en la construcción y prueba de una parte del software, a menudo un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas las funciones están correctamente implementadas dentro del sistema.
*Integración
Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada sección es enlazada con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos los módulos y el sistema se prueba como un todo.


*Validación y verificación
Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es probado para verificar que el sistema es consistente con la definición de requerimientos y la especificación funcional. Por otro lado, la verificación consiste en una serie de actividades que aseguran que el software implementa correctamente una función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotación.
*Mantención
La mantención ocurre cuando existe algún problema dentro de un sistema existente, e involucraría la corrección de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementación de las unidades del sistema y cambios para que responda a los nuevos requerimientos. Las mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.
El modelo de etapas consideraba que cada una de ellas debería ir a continuación de la anterior, poniendo énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificación y de control. Todo tendiente a conformar una cadena de producción de software, de manera similar a una cadena de montaje de automóviles.
Pero ello no logra que las causas de fondo que hicieron que se replantease el modelo de codificar y fijar desapareciesen. Todavía existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia está dada por dominios de acción distintos. La iteración de aproximación es ahora más factible, pero también resulta onerosa, es necesario instalar todo el software nuevamente en la cadena de montaje para su revisión y reconstrucción.

El modelo de cascada


El modelo de cascada es también conocido como “Modelo en cascada” o “Modelo lineal secuencial” o “Ciclo de vida básico” o “Ciclo de vida clásico”.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a través de muchas etapas.

Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relación con la idea de postular un marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software, permitiendo establecer relaciones de cooperación entre ellas. Corresponden, también, a los métodos más usados en desarrollo de software y que han sido exitosos durante décadas tanto en el desarrollo de grandes sistemas como en el de pequeños.
Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la especificación de los problemas. Ambos métodos asumen que el diseñador puede distinguir entre lo que el sistema debe hacer y como el sistema lo hará; pero algunos problemas no pueden ser divididos tan fácilmente para ser atacados desde este prisma.
Por otro lado, generalmente los requerimientos son especificados al inicio del proyecto y, paradojalmente, cuando se tiene la claridad suficiente para definir precisamente lo que se quiere es cuando se está en las últimas etapas del proyecto. Esto es consecuencia, en general, de que los clientes no están familiarizados con la tecnología, con lo cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los desarrolladores.
Otro factor importante es que estos métodos asumen que una vez que los requerimientos han sido definidos entonces ellos no cambiarán más. Pero, dependiendo de la complejidad del proyecto, la implementación final puede ocurrir meses o, eventualmente, años después de que los requerimientos han sido especificados; así, en las últimas etapas del proyecto, los requerimientos pueden haber cambiado.
Existiría un énfasis en la elaboración de documentos. El sistema completo es descrito y registrado en papel, cada etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las especificaciones de requerimientos pueden ser de cientos de páginas, explicando todos u cada uno de los detalles del sistema. Y es difícil poder visualizar a priori, desde éste volumen de papel, las características del sistema.
Por último, se ha detectado que el enfoque lineal de estos métodos no sería el adecuado para reflejar el proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clásico los lleva a seguir las etapas en orden incorrecto. Más aún, es posible que todas las etapas del proyecto, estén comprimidas dentro de cada una.
Como se ha podido observar, la especificación de métodos más acabados para el desarrollo de software no logra superar el problema de la distancia entre la visión del usuario y la del desarrollador, ya que no se ha buscado resolver ese problema, sino que las soluciones se centraron principalmente en la división de las tareas con miras al control de las mismas, lo que si bien soluciona el problema de especificar y luego programar, crea otros, como el presentado en el párrafo anterior, en que no todos los problemas podrían ser abordados desde una misma perspectiva de orden en las etapas.

El ciclo de vida clásico
El ciclo de vida proporciona un modelo conveniente que sirve para dos propósitos. En primer lugar, permite representar los procesos deconcepción y producción en una forma gráfica y lógica, y segundo, proporciona un marco de trabajo alrededor del cual las actividades de aseguramiento de calidad pueden ser construidas en una manera decidida y disciplinada.
El desarrollo de software desde el concepto inicial a través de la operación es un proceso involuntario. Es decir, se produce mediante etapas sucesivas de especificación, diseño y modificación. Cada evaluación de una parte del software - se hace por una revisión de la documentación que describe los requerimientos, especificación, diseño o, después, por pruebas al código y área usada del sistema realizado - da como resultado cambios. Idealmente, el proceso de desarrollo debe involucrar gradas sucesivas de especificación y diseño donde cada paso es verificado contra los requerimientos de la etapa precedente. Así un producto de software viable evoluciona con errores que se encuentran y corrigen conforme ocurren.
El modelo de desarrollo de software utilizado con mayor frecuencia, a menudo se denomina el "modelo V o cascada" (quizá por su similitud a un conjunto de cascadas). El modelo representa el ciclo de vida del software como un conjunto de actividades ligadas, pero separadas, con entradas descendientes a etapas sucesivas y retroalimentación ascendente para proporcionar verificación contra etapas previas así como una validación final de los requerimientos.
Aunque no es su intención ser una representación perfecta de lo que ocurre en realidad, este modelo ha tenido un uso muy difundido durante 15 años. Esto se explica aquí con detalle para dar un sentido de lo que se describe en un modelo de ciclo de vida y cómo puede ayudar a controlar el proceso de desarrollo de software.
La primera etapa en este modelo es la definición de requerimientos. Esta es, invariablemente, la primera etapa de cualquier proceso orientado al problema y es en muchos casos la más difícil de lograr. En el siguiente capítulo se analizan las razones detrás de esto. Por ahora, tan sólo estableceremos que el problema radica en La comunicación entre el cliente y el desarrollador. El primero no está siempre en posición de definir con precisión lo que se requiere; como resultado, el segundo por lo general tiene gran dificultad para producir una especificación con el detalle suficiente que permita asegurar La traducción de los requerimientos para el diseño.

El ciclo de vida cascada
Aún en casos donde el cliente y el diseñador construyen Un conjunto preciso de requerimientos, las tendencias del acto del desarrollo concreto del sistema dan como resultado La modificación de La percepción original del cliente de lo que se necesita al final. La etapa de requerimientos puede compararse con la preparación de un documento legal. Se transforma lo más preciso, lo más difícil es entenderlo. Si se omite La precisión, entonces La libertad para La ambigüedad y el mal entendido se incrementa.
Supongamos, por el momento, que puede esbozarse un grupo satisfactorio de requerimientos, que hay una base para la siguiente etapa en el modelo cascada. Este nos lleva al diseño y por lo general necesita que el desarrollador responda a los requerimientos establecidos con alguna forma de especificación de funciones que definan la apariencia externa de las funciones del sistema como el desarrollador las percibe. El material de salida de esta etapa es una definición de lo que el desarrollador desea implantar, de tal forma que proporciona la primera evidencia visible para el cliente de que el producto eventual será lo que se ordenó.
De aquí en adelante, en el modelo cascada, uno se ve envuelto en la repetición de diseño de alguna forma. En el nivel más alto, un diseño de sistema establecido es el que permitirá la separación de los componentes del software de los que no lo son y la definición de la interfaz entre ellos. Muy a menudo un diseño de arquitectura será generado para establecer un marco de trabajo. Entonces, el diseño del software se lleva a cabo mediante el uso de una metodología "hacia abajo" determinada. He aquí que el mayor efecto sobre la calidad puede verse dado que la calidad de diseño, a largo plazo, determinará la calidad final del producto. El nivel más bajo del diseño de software proporcionará la base para la codificación y definirá con amplitud la estructura de los programas. En las iteraciones a lo largo del diseño, el problema general debe ser dividido lo suficiente para dejar sólo dificultades menores para el programador. En la práctica, este rara vez es el caso y algunas decisiones de diseño tomadas en una etapa anterior no pueden implantarse. En tales casos, es necesario recurrir al rediseño y repetir hasta que el problema sea solucionado.
La siguiente etapa mayor en el modelo cascada es la concerniente a la prueba del código diseñado. Esta actividad tiene lugar a varios niveles. En el nivel más bajo, los programadores deben probar su propio código fuente por separado de otras partes del sistema. Una vez que sean consistentes consigo mismos, los módulos probados pueden presentarse para la integración del sistema del cual son parte. Conforme los progresos de integración y las funciones externas comienzan a aparecer es factible dar al cliente la oportunidad de ver el producto potencial. Esto permite hacer pruebas invaluables en la demostración del sistema que se desarrolla como se especificó originalmente y también para detectar puntos de mal entendido en la interpretación de los requerimientos originales.
La prueba de aceptación por lo general se concreta a demostrar los aspectos funcionales del producto. En realidad, es la entrega y operación La que casi siempre revela el grado en que el producto satisface los requerimientos del cliente.
Por último, una prueba de aceptación del sistema completo tendrá lugar antes de su entrega. En esta etapa el cliente puede "terminar" el sistema quizá con algunos defectos ya conocidos. Sin embargo, está lejos de la historia completa. Es esencial que la evolución del sistema posterior a la entrega se considere como parte del ciclo de vida del mismo, justo antes de ser obsoleto. De manera típica, los sistemas de software están más en servicio que en desarrollo (el software para el cambio telefónico tuvo una vida de diseño de 20 años. Inevitablemente se requieren modificaciones para entregar sistema, para corregir errores encontrados en el área y para agregar nuevas funciones al sistema.
La actividad continua de mantenimiento, por la cual se descubre y dirige la ausencia de cumplimiento a los requerimientos o requerimientos malentendidos y se agregan nuevos, necesita considerarse parte del ciclo de vida general del sistema.
El tiempo empleado en cada una de las fases anteriores del ciclo de vida varía de un proyecto a otro.

.
Bueno respecto a las ventajas del modelo de desarrollo de software pienso que es muy útil porque es muy rápido y no es tan costoso, además de que es muy eficiente y fácil de usar. Y en referencia a los modelos más recomendados me parecen muy bien ya que cada uno contiene características y funciones diferentes, que hacen que cada modelo sea interesante y a la vez práctico.



Bibliografía:
http://html.rincondelvago.com/modelos-de-desarrollo-de-software.html
avatar
Viviana Sosa

Mensajes : 7
Fecha de inscripción : 27/09/2012
Edad : 25

Ver perfil de usuario

Volver arriba Ir abajo

Aport.#1 Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo? Justifique.

Mensaje  jose luis bañuelos maciel el Miér Nov 28, 2012 1:11 am

Que tal compañeros del foro saludos a todos que la pasen de lo mejor.
En referencia al a pregunta:Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo? Justifique.
Mi investigación es la siguiente:

Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.6 10
El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.
Las regiones definidas en el modelo son:
 Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador.
 Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto.
 Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto.
 Región 4 - Tareas para construir una o más representaciones de la aplicación software.
 Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
 Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las regiones que definen esas actividades comprenden un «conjunto de tareas» del trabajo: ese conjunto sí se debe adaptar a las características del proyecto en particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si.
Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la Figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificación del producto; los pasos siguientes podrían generar un prototipo y progresivamente versiones más sofisticadas del software.
Cada paso por la región de planificación provoca ajustes en el plan del proyecto; el coste y planificación se realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para completar el desarrollo.
El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clásico, o cascada, el proceso termina a la entrega del software).
Una visión alternativa del modelo puede observarse examinando el «eje de punto de entrada de proyectos». Cada uno de los circulitos fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:
 Un proyecto de «desarrollo de conceptos» comienza al inicio de la espiral, hace múltiples iteraciones hasta que se completa, es la zona marcada con verde.
 Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: «Desarrollo de nuevo Producto». Que evolucionará con iteraciones hasta culminar; es la zona marcada en color azul.
 Eventual y análogamente se generarán proyectos de «mejoras de productos» y de «mantenimiento de productos», con las iteraciones necesarias en cada área (zonas roja y gris, respectivamente).
Cuando la espiral se caracteriza de esta forma, está operativa hasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en «mejora del producto»).
El modelo espiral da un enfoque realista, que evoluciona igual que el software11 ; se adapta muy bien para desarrollos a gran escala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad.
Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión.
Modelo espiral Win & Win
Una variante interesante del Modelo Espiral previamente es el «Modelo espiral Win-Win»7 (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan».
Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:
1. Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
2. Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
3. Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).
Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados «puntos de fijación», que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.
Porqué utilizar este modelo?
Trata de mejorar los ciclos de vida clásicos y prototipos.
Este modelo puede combinarse con otros modelos de proceso de desarrollo(cascada, evolutivo) .
En cada giro se construye un nuevo modelo del sistema completo.
El análisis de riesgo requiere la participación de personal con alta cualificación.
Incorpora objetivos de calidad y gestión de riesgos
Elimina errores y alternativas no atractivas al comienzo
Permite iteraciones, vuelta atrás y finalizaciones rápidas
Cada ciclo empieza identificando:
Los objetivos de la porción correspondiente
Las alternativas
Restricciones

Bueno compañeros en referencia a lo leído: ¿ que pasaría si este modelo se implementara con otros modelos existiría un mejor control dentro de la empresa, o existiría un desorden en el control de la empresa?


[youtube]

jose luis bañuelos maciel

Mensajes : 8
Fecha de inscripción : 26/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport. 1 Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?

Mensaje  Dañela el Miér Nov 28, 2012 1:21 am

Buenas noches compañeros y maestra nos volvemos a encontrar en este foro, me da mucho gusto y espero que tengan un exelente dia.

Mi aportacion con respecto a la pregunta es:


[img] [/img]

Scrum es una metodología
• Aplicable al desarrollo software.
• Iterativa -> se crea un incremento potencialmente entregable.
• Permite el desarrollo ágil que valora:
o A los individuos (respeto, responsabilidad, coraje) por encima de los procesos y herramientas.
o Al software que funciona, por encima de la documentación exhaustiva.
o A la colaboración con el cliente, por encima de la negociación contractual.
o A la respuesta al cambio, por encima del seguimiento de un plan.
o La transparencia y visibilidad del proyecto
¿Por qué SCRUM?
Ventajas:
• Es fácil de aprender.
• Requiere muy poco esfuerzo para comenzarse a utilizar.
• Permite que abarcar proyectos donde los requisitos de negocio están incompletos
• Permite el desarrollo, testeo y correcciones rápido
• Mediante las reuniones diarias se ven claramente los avances y problemas
• Como toda metodología ágil, obtiene mucho feedback del cliente.
• Facilita la entrega de productos de calidad a tiempo
No todo es jauja
Desventajas:
• Si no se define una fecha de fin, los stakeholders siempre pedirán nuevas funcionalidades.
• Si una tarea no está bien definida puede incrementar costes y tiempos.
• Si el equipo no se compromete hay mucha probabilidad de fracasar.
• Solo funciona bien en equipos pequeños y ágiles.
• Se requieren miembros del equipo experimentados.
• Solo funciona cuando el Scrum Manager confía en su equipo.
• Que un miembro abandone el equipo durante el desarrollo puede conllevar grandes problemas.
Roles
Cada persona que interviene en el proceso de creación de un producto tiene un rol específico. Roles comprometidos con el proyecto y el proceso SCRUM:
• Product Owner (Dueño del producto):
o Representa la voz del cliente.
o Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.
o Escribe historias de usuario, las prioriza, y las coloca en el <<product backlog>>.
• Scrum Manager (Facilitador):
o Eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint.
o No es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga.
o Se asegura de que el proceso Scrum se utiliza como es debido (osea que se cumplan las reglas).
• Team (Equipo):
o Tiene la responsabilidad de entregar el producto.
o Formado por 7±2 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc).
Roles que no forman parte del proceso Scrum pero que deben tenerse en cuenta:
• Stakeholders (Interesados: Clientes, Proveedores, Inversores):
o Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica.
o Asesoran y observan
o Sólo participan directamente durante las revisiones del sprint.
• Usuarios: son aquellas personas para las que se desarrolla el producto.
Componentes
Pila del producto (Product Backlog) :
• Responsable: Product Owner
• Relación de requisitos del producto, no detallados excesivamente
• Priorizados
• Todo el mundo puede añadir elementos pero solo el Product Owner añade prioridades.
Pila del sprint (Sprint Backlog) :
• Requisitos comprometidos por el equipo para el sprint.
• Suficientemente detallado para su ejecución
Incremento :
• Parte del producto desarrollada en 1 sprint
• En condiciones de ser usada (pruebas, codificación limpia y documentada)
Reuniones
Planificación del Sprint (Sprint Planning):
• Participantes: Producto Owner + Scrum Manager + Equipo
• Duración: 1 jornada de trabajo.
• El Product Owner explica sus prioridades y resuelve las dudas que le surjan al equipo.
• El equipo estima el esfuerzo de los requisitos prioritarios y se elabora la Pila del Sprint (lista de historias incluidas en el Sprint).
• El Scrum Manager define en una meta para el sprint en términos de negocio.
• Fijar una fecha para la Demo del Sprint.
Reunión diaria (Daily Scrum):
• Participantes: Equipo + Scrum Manager (los demás solo pueden mirar)
• Duración: 15 minutos (es dirigida por el Scrum Manager)
• Descripción: Cada miembro del equipo responde a las preguntas: ¿qué hiciste ayer?, ¿cuál es el trabajo para hoy?, ¿qué necesitas?
• Se actualiza la pila del sprint.
Revisión del Sprint (Sprint Review):
• Participantes: Todos
• Duración: 4 ahoras aproximadamente
• Descripción: reunión informativa en la que se presenta el incremento y se plantean sugerencias.
• Se anuncia el próximo sprint.
Ciclo de trabajo
1. Toma de requisitos al cliente. Para cada requisito principal se crea un bloque de trabajo, llamado historia de usuario.
2. El cliente ordena las historias de trabajo en una pila de producto (producto backlog) según su prioridad de entrega.
3. El equipo de trabajo toma un grupo de historias, con el que trabajan durante una iteración o sprint (entre 15 y 30 días).
4. Una vez finalizado un sprint entregan al cliente el resultado del trabajo. Se vuelve al punto 2º hasta terminar la pila de producto.





Creo que esta metodologia es muy buena ya que ayuda a empresas que tienen proyectos a medias, no terminados, o por terminar y es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.


A pesar que el desarrollo de esta metodologia se requiere de mucho trabajo, es posible que pueda ser utilizada aqui en la Region de los Llanos??

Dañela

Mensajes : 9
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport. 1 : ¿Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. ¿Porqué utilizar este modelo? Justifique.

Mensaje  Guille Parada el Miér Nov 28, 2012 2:10 pm

Hola compañeros. Muy buenas tardes para todos y cada uno de ustedes, nuevamente nos encontramos en este foro, para que con esta actividad finalizar este semestre que pronto va a terminar.

Por mi parte yo voy responder a la pregunta: ¿Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. ¿Porqué utilizar este modelo?

EL MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
Ø Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
Ø Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
• Decidir qué problema se quiere resolver antes de viajar a resolverlo.
• Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
• Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
• No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
Funcionamiento del modelo Espiral


En cada vuelta tomamos en cuenta:
Ø Los Objetivos: Que necesidad debe envolver el programa.
Ø Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
1. Características: experiencia del personal, exigencias a efectuar.
2. Formas de gestión del programa.
3. Riesgo tomado con cada alternativa.
Ø Desarrollar y Verificar: Programar y probar el programa.
Ø Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:
1. Angular = Avance del proyecto Software, dentro de un ciclo.
2. Radial = Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.


El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.


Modelo espiral para el ciclo de vida del software.
Las regiones definidas en el modelo de la figura son:
• Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador.
• Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto.
• Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto.
• Región 4 - Tareas para construir una o más representaciones de la aplicación software.
• Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
• Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las regiones que definen esas actividades comprenden un «conjunto de tareas» del trabajo: ese conjunto sí se debe adaptar a las características del proyecto en particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si.


Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.).

Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la Figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificación del producto; los pasos siguientes podrían generar un prototipo y progresivamente versiones más sofisticadas del software.
Cada paso por la región de planificación provoca ajustes en el plan del proyecto; el coste y planificación se realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para completar el desarrollo.

El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clásico, o cascada, el proceso termina a la entrega del software).
Una visión alternativa del modelo puede observarse examinando el «eje de punto de entrada de proyectos». Cada uno de los circulitos (๏) fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:
• Un proyecto de «desarrollo de conceptos» comienza al inicio de la espiral, hace múltiples iteraciones hasta que se completa, es la zona marcada con verde.
• Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: «Desarrollo de nuevo Producto». Que evolucionará con iteraciones hasta culminar; es la zona marcada en color azul.
• Eventual y análogamente se generarán proyectos de «mejoras de productos» y de «mantenimiento de productos», con las iteraciones necesarias en cada área (zonas roja y gris, respectivamente).
Cuando la espiral se caracteriza de esta forma, está operativa hasta que el software se retira, eventualmente puede estar inactivo (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en «mejora del producto»).
El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad.
Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión.
Este modelo tiene como objetivo la ganancia de todos los participantes, es decir que todos salgan satisfechos.
Tiene 3 puntos de fijación que son:
OVC (objetivo del ciclo de vida) Aquí se establece los objetivos a cumplirse en cada etapa.
ACV (arquitectura del ciclo de vida) Se define la arquitectura del SW.
COI (capacidad operativa inicial) Aquí el SW comienza a funcionar.

Sus ventajas son que todos los participantes ganan, y tiene un ambiente más humano.

JUSTIFICACION

Bueno de lo que yo investigue, aprendí que este modelo es muy bueno ya que ofrece muy buenas ventajas para toda aquella empresa que lo quiera implementar, nos explicaba también como es que funciona y las imágenes son muy amplias y nos permiten visualizar un poco mas como es que este modelo funciona.
Además este modelo es muy fácil de implementar y aplicarse a todo el ciclo de vida de este, ya que se desarrolla gran escala, porque nos explica como se divide y en que consiste cada una de las fases de este mismo.
Espero y que esta aportación sea de mucha utilidad, y que de igual manera el foro nos haya ayudado a fortalecer los conocimientos ya previos que teníamos con respecto al tema de la informática, y que de la misma manera nos siga fortaleciendo nuestro estudio y aprendizaje diario.




cflores334.blogspot.es/1193099760/
es.wikipedia.org/wiki/Software#Modelo_espiral

Guille Parada

Mensajes : 8
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

aport#1 1. Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo

Mensaje  daniel d glez el Miér Nov 28, 2012 2:10 pm

Hola maestra consuelo buenas tardes con respecto a la pregunta Bajo qué condiciones y/o circunstancias se recomienda emplear un Modelo de desarrollo en espiral. Porqué utilizar este modelo?.


Aporto la siguiente información:

El modelo de desarrollo en espiral es de los que se utilizan cuando se producen sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios. Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.
Se caracteriza principalmente por:
 Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
 Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
• Decidir qué problema se quiere resolver antes de viajar a resolverlo.
• Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
• Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
• No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
http://scruz334.blogspot.es/img/espiral.jpg

En cada vuelta tomamos en cuenta:
 Los Objetivos: Que necesidad debe envolver el programa.
 Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
1. Características: experiencia del personal, exigencias a efectuar.
2. Formas de gestión del programa.
3. Riesgo tomado con cada alternativa.
 Desarrollar y Verificar: Programar y probar el programa .
 Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular.
https://www.youtube.com/watch?v=AfOIH31YUYU&feature=related
Referencias de la informacion
http://scruz334.blogspot.es/1193169600/

daniel d glez

Mensajes : 8
Fecha de inscripción : 26/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aportacion 1"¿Que ofrece el modelo de desrollo Scrum, en cso se debe de utilizr? Justificar"

Mensaje  Yovana S el Miér Nov 28, 2012 2:17 pm

Que tal compañeros, me da mucho gusto saludarlos nuevamente mediante este foro, espero que se encuentren bien… mi aportación es respecto a la pregunta 5. ¿Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?, la misma que han contestado mis compañeros Carlos Rivera, Raúl Gerardo y Daniela, me di a la tarea de investigar lo siguiente:

“Scrum”
Desarrollado a principios de los 90, los primeros orígenes de Scrum provienen de los estudios realizados a finales de los 80 por empresas como Canon, HP, Honda, Xerox y otras que tenían la necesidad de desarrollar productos novedosos que debían salir al mercado en menos tiempo que sus productos anteriores para ganar cuota de mercado y adelantarse a la competencia. La primera formalización real de Scrum fue realizada por Schwaber y Sutherland, durante el OOPSLA del año 1995.
¿Qué es realmente Scrum?
Podemos definir Scrum como una metodología ágil empleada en el Desarrollo de Software y la Gestión de Proyectos TIC, especialmente indicada para proyectos en entornos complejos, donde se necesita obtener resultados pronto, los requisitos cambian constantemente o están poco definidos y donde la innovación, competitividad, flexibilidad y productividad son fundamentales para conseguir cumplir los objetivos del cliente. De hecho, Scrum es un término del Rugby que quiere decir “melé”, cuyo significado es trabajar todos agrupados en equipo. Los actores que intervienen (scrum roles) los podemos ver en el grafico.


Aunque existen muchos principios y ventajas de utilizar Scrum, los 4 principios fundamentales son estos:
• Importancia de los individuos más que los procesos y herramientas.
• Entregar software que funciona más que documentación exhaustiva.
• Colaborar con el cliente más que negociación de contratos.
• Respuesta a los cambios más que seguimiento de un plan.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
La innovación, la competitividad, la calidad y la productividad son fundamentales, utilizando Scrum.
Beneficios
Apartado muy interesante para conocer los principales beneficios de Scrum:
• Gestión de las expectativas del cliente basada en resultados tangibles
• Resultados anticipados (time to market)
• Flexibilidad y adaptación a los cambios (cliente, mercado, etc.)
• Gestión sistemática del Retorno de Inversión (ROI)
• Mitigación sistemática de los riesgos del proyecto
• Productividad y calidad
• Alineamiento entre el cliente y el equipo de desarrollo
• Equipo motivado.

Mi punto de vista sobre ésta metodología es que es muy ágil y eficiente , la cual nos brinda buenos resultados ya que fue usada a principios de empresas importantes que ahora son sobresalientes por sus productos destacados, por ejemplo, Canon, HP, Honda, Xerox y otras. Esto quiere decir que usar este método nos sirve de mucho y nos da buenos resultados.

http://santimacnet.wordpress.com/category/metodologias-agiles/




Yovana S

Mensajes : 7
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport. #1 ¿Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?

Mensaje  Cinthia el Miér Nov 28, 2012 5:44 pm

Hola buenas tardes maestra consuelo y demás compañeros esperando se encuentre muy bien su día la saludo y paso a lo siguiente.

Con respecto a la pregunta numero 2 ¿Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables? Que usted elaboro en el foro quiero aportar lo siguiente:
[url=[URL=https://redcdn.net/ihimg/photo/my-images/850/slide2728.jpg/]

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final
Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades
Es necesario destacar el ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo.
El modelo de desarrollo nos ayuda a la forma en que vamos a construir el producto (guía).
Es un complemento para generar el producto desde el punto de vista técnico y administrativo
Modelos de Desarrollo recomendados
 El Modelo de Cascada.
 El Modelo en V.
 En Flor.
 Prototipos
 El Modelo de Espiral.
 El Modelo de Procesos.
 Desarrollo Incremental
El Modelo de Cascada
 El ciclo de desarrollo de software.
 Este modelo tiene una secuencia ordenada.
 El trabajo de una etapa previa es la entrada del siguiente proceso.
 Provee de un gran control sobre las fechas de entrega y entregables.
 Establece criterios de entrada y salida en cada fase claramente definidos.
 Dado que provee pocos puntos de visibilidad da la impresión de que es lento.
Ventajas
 Excelente cuando se tiene un producto estable y se conoce la tecnología.
 Es un método muy estructurado que funciona bien con gente de poca experiencia.
 Provee estabilidad en los requerimientos.
 La planeación se puede hacer anticipadamente.
Desventajas
 Tiene poca flexibilidad.
 Los proyectos en la práctica raramente siguen un flujo secuencial.
 Siempre es difícil para el cliente mostrar todos los requerimientos explícitamente y con mucha anticipación.
 El cliente debe tener paciencia.
 Es inflexible y no motiva al cambio.
 Poco apropiado para aplicaciones para la toma de decisiones.
 Los usuarios tienen una participación limitada.
El Modelo en V
 Una reexaminación del modelo del ciclo de vida desde el punto de vista de aseguramiento de calidad.
 Cuando cada proceso termina su producto, las especificaciones de prueba para la probar los procesos están también completas.
Modelo en Flor
 El propósito del desarrollo de software es el de desarrollar un producto de software.

 Los equipos no deben de estar preocupados por el proceso de desarrollo mismo.

 Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final es alcanzado.
Prototipos
Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación.
Construcción de Prototipos
 Identificación de Requerimientos.
 Diseño Rápido.
 Utilizar el Prototipo.
 Revisar y Mejorar.
 Es un método menos formal de desarrollo.
 El prototipo es una técnica para comprender las especificaciones.
 Un prototipo puede ser eliminado.
 Un prototipo puede llegar a ser parte del producto final.
Ventajas
 Útiles cuando los requerimientos son cambiantes.
 Cuando no se conoce bien la aplicación.
 Cuando el usuario no se quiere comprometer con los requerimientos.
 Cuando se quiere probar una arquitectura o tecnología.
 Cuando se requiere rapidez en el desarrollo.
Desventajas
 No se conoce cuando se tendrá un producto aceptable.
 No se sabe cuantas iteraciones serán necesarias.
 Da una falsa ilusión al usuario sobre la velocidad del desarrollo.
 Se puede volver el producto aún y cuando no este con los estándares.
El Modelo de Espiral
 Los productos de software son creados a través de múltiples repeticiones del proceso del ciclo de vida. Se rompen un mini-proyectos.
 Estos modelos han sido aplicados al desarrollo de software.
 Aun no han madurado al punto de ser aplicados como modelos de desarrollo con tiempos y limitaciones de costos.


Ventajas
 El producto avanza a pasos firmes solucionado riesgos en cada iteración.
 El producto termina con todos los riesgos resueltos.
 Se pueden incluir otros métodos de desarrollo en las iteraciones.
 A medida que el costo aumenta, los riesgos se reducen.
 Se tienen puntos de control en cada interacción.
Desventajas
 Es complicado.
 Requiere de mucha administración.
 Difícil de definir los objetivos, metas que indiquen que podemos avanzar al siguiente ciclo.
 Se puede caer en un desarrollo de nunca acabar.
El Modelo de Procesos
 Impulsa un proceso iterativo de desarrollo.
 Cada ciclo es una versión del producto.
 Utiliza metas definidas para marcar la transición entre las distintas etapas.
 Ofrece mayor poder de decisión a los usuarios.
 Busca mejorar la calidad y creatividad.
Ventajas
 Etapas claramente definidas con metas, entregables y responsables.
 Se establecen roles asociados al modelo que promueven la participación de todos.
 Involucra muy de cerca al usuario.
Desventajas
 Dado que la mayoría de las decisiones son en consenso por el equipo en su conjunto, en ocasiones toman más tiempo de lo debido.
 Para proyectos pequeños puede resultar poco practico.
 El considerar versiones hace que se dejen de lado algunas decisiones.
Desarrollo Incremental
 Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.
 Cada etapa consiste de requerimientos, diseño, codificación, pruebas, y entrega.
 Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
Reduce los riesgos ya que:
– Provee visibilidad sobre el progreso a través de sus nuevas versiones.
– Provee retroalimentación a través de la funcionalidad mostrada.
– Permite atacar los mayores riesgos desde el inicio.
– Se pueden hacer implementaciones parciales si se cuenta con la suficiente funcionalidad.
– Las pruebas y la integración es constante.
– El progreso se puede medir en periodos cortos de tiempo.
– Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
– Se puede planear en base a la funcionalidad que se quiere entregar primero.
– Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
Ventajas
 La solución se va mejorando en forma progresiva a través de las múltiples iteraciones.
 Incrementa el entendimiento del problema y de la solución por medio de los refinamientos sucesivos.
Desventajas
 Requiere de mucha planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.

-Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a todos los proyectos de una organización.
-Una organización puede contar con uno o más modelos de desarrollo para ser utilizados dependiendo del tipo de proyecto.
-El modelo seleccionado tendrá influencia en el éxito del proyecto y en el tipo de decisiones que se deberán hacer.

Para seleccionar el modelo a adoptar habrá que hacerse una serie de cuestionamientos:
– ¿Qué tantos son los riesgos del proyecto?
– ¿Qué tan claros están los requerimientos?
– ¿Se conoce bien la tecnología ha utilizar?
– ¿Visibilidad que requiere el proyecto?
– ¿Qué tanta planeación hacia adelante es requerida?
– ¿Qué restricciones se tienen?


No hay un modelo en si que sea el mejor o peor, aunque hay modelos antiguos u obsoletos cada uno como ya lo mencione con anterioridad tiene sus propias ventajas y desventajas, así que es dependiendo de las necesidades elegir el que mejor se adecue o en dado caso adecuar algún modelo para el proyecto a construir

En base a la investigación hay una duda que me surgio y esta se refiere a que si bien existen modelos de desarrollo pero ¿como se garantiza el rendimiento de el modelo que se elija en un proyecto?. es decir, ¿En base a que podemos medir la viabilidad o confiabilidad de un modelo?
sin mas me despido esperando mi respuesta sea de utilidad. les deseo buen dia.


http://www.slideshare.net/guesta1695670/metodologias-de-desarrollo-de-software#btnNext
http://www.slideshare.net/inventa2/modelos-de-desarrollo#btnNext



Cinthia

Mensajes : 8
Fecha de inscripción : 25/09/2012
Edad : 28

Ver perfil de usuario

Volver arriba Ir abajo

Aport. 1 ¿Qué ofrece el modelo de desarrollo Scrum, en que casos se debe utilizar?

Mensaje  hassiel el Miér Nov 28, 2012 9:48 pm

Hola maestra espero y este bien y paso por este foro para darle respuesta a la pregunta:
5. Qué ofrece el modelo de desarrollo Scrum, en qué casos se debe utilizar?
Aquí le presento la información recabada y espero un comentario de su parte. Habiendo dicho todo esto me despido y que este bien

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Hay varias características sobre este modelo:

1.-Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
2.-Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
3.-Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
4.-Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.
5.-Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

En el Scrum existen varios roles que son:

a) Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario y las prioriza.
b) ScrumMaster o Facilitador
ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo, sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
c) Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc)
d) Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
e) Administradores
Es la gente que establece el ambiente para el desarrollo del producto.

El Scrum se distingue porque constantemente existen reuniones, ya sea para analizar sobe un proyecto, revisar uno ya existente, etc.
a continuacion redactare los pasos de cada reunion:

Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)
Todos son bienvenidos, pero sólo los responsables pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?

Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.
La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:
¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
Seleccionar qué trabajo se hará
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como límite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”

bibliografía:
• http://es.wikipedia.org/wiki/Scrum


hassiel

Mensajes : 9
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport.1 En tu opinión, ¿en que fases del ciclo de vida del software se justifica el uso de herramientas CASE, cuál recomendarias y porqué?.

Mensaje  Martin R. el Jue Nov 29, 2012 2:06 am

2) Hola maestra le envió un cordial saludo, espero que esté pasando un agradable día.
En referencia a la pregunta 6 en la cual hace mención en el foro: En tu opinión, ¿en qué fases del ciclo de vida del software se justifica el uso de herramientas CASE, cuál recomendarías y porqué? Investigue lo siguiente:

3) ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo plantean diferentes autores, está conformado en su versión ampliada por siete etapas:
- 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 o una necesidad que para su solución y/o satisfacción es necesario realizar un desarrollo de software.
- 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, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.
- DISEÑO: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el CÓMO se va a solucionar.
- IMPLEMENTACIÓN: partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada.
- PRUEBAS: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar.
- DOCUMENTACIÓN: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento).
La documentación se compone de tres partes:
a. Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las pos condiciones de cada función.
b. Documentación Externa: Se define en un documento escrito con los siguientes puntos:
Descripción del Problema
Datos del Autor
Algoritmo (diagrama de flujo o Pseudocódigo)
Diccionario de Datos
Código Fuente (programa)
c. Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.
- MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo.
Puntos Importantes a considerar
Cuando se selecciona una Herramienta CASE.
Seleccionar una Herramienta CASE no es una tarea simple. No existe una ‘mejor’ herramienta respecto de otra. Hay numerosas historias respecto al uso de CASE y las fallas que pueden producirse. Las fallas o las respuestas satisfactorias están en relación con las expectativas. Si el proceso de evaluación y selección de las
Herramientas CASE falla, entonces la Herramienta no cumplirá con las especificaciones o expectativas del negocio. Esto puede ocurrir durante el proceso de implementación o ejecución del producto.
Hay tres puntos comunes que fallan en el proceso de evaluación y selección:
! El proceso en sí mismo.
! Los pre-requisitos necesarios.
! Conocer la organización.

El proceso en sí mismo:
El proceso de evaluación y selección de Herramientas CASE debe aproximarse a un proyecto mayor. El proceso debe definirse cuidadosamente y debe incluir las mejores técnicas de dirección de proyecto. Ninguna selección es igual que otra, porque dos organizaciones no son iguales.
Por ejemplo, el proceso de selección para el Ministerio de Defensa puede ser completamente diferente que en una corporación comercial. Aunque hay principios básicos, por ejemplo, todos debemos entender el criterio en el que está basado el proceso de selección, todos deben tener una visión común. Es adecuado limitar el número de vendedores tanto como sea posible, para poder enfocar y entender realmente una determinada herramienta.

Los pre-requisitos necesarios:
El propósito de las herramientas CASE es apoyar y facilitar el desarrollo de software.
Debe haber una comprensión clara del propósito de las herramientas que se propongan dentro del ambiente de desarrollo que es compartido por el equipo de la selección. El equipo debe tener una visión común del ambiente de desarrollo de sistemas, resultando la selección de la herramienta adecuada.
Otro requisito previo importante sería tener una metodología de desarrollo de sistemas seleccionada. Sin una metodología, ingresará al largo camino del fracaso. Las herramientas implementan la metodología, no la determinan.
Conocer la organización:
Cuando se está evaluando y seleccionando una herramienta CASE, es importante conocer y entender a la organización. Tal como las personas son únicas, así también las organizaciones son únicas a su propio modo, cada una tiene una personalidad e infraestructura propias. Una empresa podría disciplinarse y alcanzar un nivel alto de madurez en el proceso de diseño de software, mientras otra puede estar en las fases tempranas. Sin tener en cuenta la disciplina y la madurez, es muy importante entender la organización que se verá reflejada en la selección final.

Estrategias de Implantación de una
Herramienta CASE
1. Identificar la magnitud de problemas a resolver en la Institución.
2. Identificar el nivel estratégico que deben tener los sistemas.
3. Evaluar los recursos de hardware y software disponibles en la Institución y el medio.
4. Evaluar el nivel del personal.
5. Efectuar un estudio de costo-beneficio definiendo metas a lograr.
6. Elegir las herramientas apropiadas para la Institución.
7. Establecer un programa de capacitación de personal de sistemas y usuarios.
8. Elegir una aplicación que reúna la mayor parte de los siguientes requisitos:
• Gran impacto de resultados.
• Disponibilidad de recursos.
• Mínimo nivel de riesgos.
• Máxima colaboración de usuarios.
• Tamaño reducido de solución.
9. Se establecerán interfaces de compatibilidad de los nuevos sistemas que deben convivir con los sistemas anteriores.

4) En mi opinión las etapas del ciclo de vida en donde se justificaría el uso de herramientas CASE son las siguientes:

ANÁLISIS: esta etapa es de vital importancia ya que se comprenderá cual es el problema a resolver, el entorno del problema y después de recabar información esencial de estos puntos anteriores se generara una solución eficiente para resolver el problema.
En esta fase, recomendaría la herramienta CASE: Visible Analist (VA), ya que aumenta la productividad del analista, da al analista de sistemas la posibilidad de realizar, plantación, análisis y diseño por medios gráficos, creando así aplicaciones cliente-servidor y bases de datos más complejas. Esta herramienta permite modelar datos y procesos en diferentes formatos, gracias a esto el analista es más productivo pues la reducción de tiempo es considerable y la corrección de diagramas de flujos de datos es manualmente y da una apariencia muy aceptable.

IMPLEMENTACIÓN: en esta etapa es donde se desarrolla el programa que va a solucionar el problema, lo cual es muy importante pues depende que los algoritmos y procedimientos sean confiables utilizando una herramienta computacional.
La herramienta CASE que recomendaría en esta fase es: SNAP, es un CASE para el desarrollo de aplicaciones en Sistemas, brinda la posibilidad de construir sistemas de inmejorable calidad, adheridos a los estándares S.A.A de IBM, es el CASE más poderoso con un inmejorable historial de resultados posibles, su esquema entidad-relación explota al máximo las virtudes y potenciales de aplicaciones que propone la filosofía IBM.
SNAP se compone de cuatro grandes áreas: Modelo de Datos, Método de Desarrollo Acelerado (MDA), Utilitarios y Seguridad.

MANTENIMIENTO: puesto en marcha un programa, es importante mantener una estructura que permita a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un buen mantenimiento es necesario una buena documentación.
EasyCASE Profesional es una herramienta CASE que yo recomiendo porque captura los detalles del diseño del sistema y permite comunicar las ideas gráficamente para que sean fáciles de ver y entender.

5) ¿Qué tan importante sería la creación de una herramienta CASE, donde se incluyan todas las etapas del ciclo de vida de un software?

6)virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo%20I/problemas.htm
slideshare.net/ligtningfleeting/herramientas-case-6894598#btnNext
inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf

Martin R.

Mensajes : 7
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

2. Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?. Justifique

Mensaje  jesus_antonio el Jue Nov 29, 2012 2:10 pm

Hola buenos días tengan todos ustedes les mando un cordial saludo y aquí estoy para responderles la siguiente pregunta.
2. Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los mas recomendables?. Justifique
Aquí una pequeña introducción al tema desarrollo de software.
Para el desarrollo de cualquier producto de software realizan una serie de tareas la idea inicial y el producto final.
Un modelode desarrollo establece el orden en el que se aran las cosas en el proyecto nos provee de requisitos de enytrada y salida para cada una de las actividades. Para elo es necesario destacar el ciclo de vida.
Modelo en cascada
Modelo en V
En flor
Modelo espiral
Modelo proceso
Desrrolo incremental.

MODELO EN CASCADA
En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.1
Un ejemplo de una metodología de desarrollo en cascada es:
Análisis de requisitos.
Diseño del Sistema.
Diseño del Programa.
Codificación.
Pruebas.
Implantación.
Mantenimiento.
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

VENTAJAS
Excelente cuando se tiene un producto estable y se conoce la tecnologia.
Es un metodo estructurado que funciona bien con gente de poca experiencia.
Provee estabilidad en los requerimientos.
La planeacion se puede hacer anticipadamente.
Para proyectos grandes.

MODELO EN V
El Método-V define un procedimiento uniforme para el desarrollo de productos para las TIC. Es el estándar utilizado para los proyectos de la Administración Federal Alemán y de defensa. Como está disponible públicamente muchas compañías lo usan. Es un método de gestión de proyectos comparable a PRINCE2 y describe tanto métodos para la gestión como para el desarrollo de sistemas.

Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

MODELO EN FLOR
El proposito del desarrollo de software es el de desarrollar un producto software, los equipos no deben estar preocupados por el proceso de desarrollo mismo. Deben desarrollarse todas las estapas un poco al mismo tiempo hasta que el producto final es alcanzado.
El propósito del desarrollo de software es el desarrollo de un producto de software.
Los equipos no deben estar preocupados por el proceso de desarrollo del mismo.
Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final es alcanzado.
Construcción de prototipos
* Identificación de requerimientos
* Diseño rápido
* Utilizar el prototipo
* Revisar y mejorar

VENTAJAS Y DESVENTAJAS
Útiles cuando los requerimientos son cambiables. No se conoce cuando tengamos un producto aceptable.
Cuando el usuario no se quiere comprometer con los requerimientos No se sabe cuántas iteraciones serán necesarias.
Cuando no se conoce bien la aplicación Dan una falsa ilusión al usuario sobre la velocidad del desarrollo.
Cuando se quiere probar una arquitectura o tecnología Se puede volver al producto aun y cando no esté con los estándares .
Cuando se requiera rapidez en el desarrollo


MODELO EN ESPIRAL
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,1 utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Ventajas
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.




MODELO PROCESO
El modelado de procesos debe ser entendido, a saber, por dos cuestiones importantes: el modelado y los procesos. Frecuentemente los sistemas (conjuntos de procesos y subprocesos integrados en una organización) son difíciles de comprender, amplios, complejos y confusos; con múltiples puntos de contacto entre sí y con un buen número de áreas funcionales, departamentos y puestos implicados. Un modelo puede dar la oportunidad de organizar y documentar la información sobre un sistema.


Ventajas
Las ventajas que ofrece un desarrollo iterativo e incremental son varias y variadas, pero debe quedar claro que es muy difícil obtener todas juntas ya que depende del contexto en el que se implemente el proceso. En general las ventajas son:
Resolución de problemas de alto riesgo en tiempos tempranos del proyecto.
Visión de avance en el desarrollo desde las etapas iniciales del desarrollo.
Obtención del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados.
Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, según demuestran estudios realizados sobre proyectos que han aplicado esta técnica.
Permite manejar la complejidad del proyecto, apuntando a la resolución de los problemas por partes, y no caer en la inanición del “súper análisis” del producto.
El aprendizaje y experiencia del equipo iteración tras iteración, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.
El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvíos en la duración total del proyecto.
Su adopción, con ciertos recaudos, no presenta grandes inversiones.

DESARROLLO INCREMENTAL
En términos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La descripción del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificación, desarrollo y validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.


Fig. 4 - Diagrama genérico del desarrollo evolutivo incremental.
El diagrama de la Figura 4 muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. 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.

UNO DE LOS METODOS MAS USADO ES:
1-.El de casacada
Es el ma conocido como modelo en cascada es también llamado modelo clásic, modelo tradiciona o modelo lineal secuencia.
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños sistemas a desarrollar. Esto es utópico; ya que intrínsecamente el software es de carácter evolutivo , cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.el modelo cascada en algunas de sus variantes es uno de los actualmente más utilizados, por su eficacia y simplicidad, más que nada en software de pequeño y algunos de mediano porte; pero nunca (o muy rara vez) se lo usa en su "forma pura", como se dijo anteriormente. En lugar de ello, siempre se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida; esto da oportunidad al desarrollo de productos software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo de vida.
2-. El modelo en espiral
Realiza Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la Figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificación del producto; los pasos siguientes podrían generar un prototipo y progresivamente versiones más sofisticadas del software.
Cada paso por la región de planificación provoca ajustes en el plan del proyecto; el coste y planificación se realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para completar el desarrollo.
El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clásico, o cascada, el proceso termina a la entrega del software).
http://es.wikipedia.org/wiki/Desarrollo_en_cascada
http://www.ingenieriadesoftware.mex.tl/61885_Modelo-V.html
http://es.wikipedia.org/wiki/Modelado_de_procesos
http://es.wikipedia.org/wiki/Software#Modelo_iterativo_incremental




jesus_antonio

Mensajes : 3
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport 1. Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software.

Mensaje  Maria Elena Renteria el Jue Nov 29, 2012 2:40 pm

Buenas tardes compañeros de nuevo estamos aquí en el foro y pues contestando la pregunta hecha por la maestra esto es lo que yo puedo aportar, esperando que les sirva de apoyo a todos.

Modelo de Desarrollo de Software:

La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede citar:
• Modelo en cascada o Clásico (modelo tradicional)
• Modelo de prototipos
• Modelo en espiral
• Desarrollo por etapas
• Desarrollo iterativo y creciente o Iterativo e Incremental
• RAD (Rapid Application Development)
• Desarrollo concurrente
• Proceso Unificado
• RUP (Proceso Unificado de Rational)
Naturaleza de la IS
La ingeniería de software tiene que ver con varios campos en diferentes formas:
Matemáticas
Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.
Creación
Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la IS.
Gestión de Proyectos
El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en Gestión de Proyectos.
Arte
Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald Knuth es famoso por argumentar a la programación como un arte.
Responsabilidad
La responsabilidad en la ingeniería del software es un concepto complejo, sobre todo porque al estar los sistemas informáticos fuertemente caracterizados por su complejidad, es difícil apreciar sus consecuencias.
En la ingeniería del software la responsabilidad será compartida por un grupo grande de personas, que comprende desde el ingeniero de requisitos, hasta el arquitecto software, y contando con el diseñador, o el encargado de realizar las pruebas. Por encima de todos ellos destaca el director del proyecto. El software demanda una clara distribución de la responsabilidad entre los diferentes roles que se dan en el proceso de producción.
El ingeniero del software tiene una responsabilidad moral y legal limitada a las consecuencias directas.
Educación ética
Organizaciones
• IEEE Computer Society
• Association for Computing Machinery (ACM)
• Software Engineering Institute (SEI)
• British Computer Society (BCS)
• RUSSOFT Association
• Society of Software Engineers

Calidad de Software:

Calidad
Es la aptitud de un producto o servicio para satisfacer las necesidades del usuario.
Es la cualidad de todos los productos, no solamente de equipos sino también de programas.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. Se puede seguir los siguientes aspectos para evaluar la calidad del software:
Calidad de software
Características propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.

Relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software.

• Se refiere a lograr un nivel de calidad requerido en el producto de software
• Involucra a la definición de estándares de calidad apropiados y procedimientos que permitan asegurar que estos se cumplan.
• Debe llevar a desarrollar una cultura de calidad en donde la calidad es responsabilidad de todos.

Modelos de calidad del software
• Objetivo: mejora de procesos software.
• Diversos modelos que buscan:
– Determinar las fuerzas y debilidades en una organización
– Aglutinar esfuerzos para conseguir acuerdos sobre lo que es un buen proceso.
• Principales iniciativas:
– ISO 9001 y 9000-3:
• muy útil en compañías que además de software fabrican equipos
• define los procesos de calidad tanto en compañías de hardware como de software.
• muy utilizado en Europa.
– Capability Maturity Model (CMM) del Instituto de Ingeniería del Software
• el modelo más empleado y maduro
• valora el desarrollo de software en sistemas de gran complejidad
• visión completa del proceso de madurez organizacional
• incluye mecanismos para mejora continua de los procesos
– Bootstrap:
• enfocado a pequeñas y medianas empresas
• valora la madurez global de una organización
• examina procesos individuales de software y valora la conveniencia y el impacto de nuevas tecnologías
– SPICE:
• combina elementos de ISO, CMM y Bootstrap
• enfocado a estudiar el nivel de madurez de los procesos individuales (tiene en cuenta el contexto de los procesos evaluados).
• objetivo: definir un marco común de referencia en el que convivan el resto de los modelos mencionados.
• Produce un perfil del proceso, en vez de un resultado válido/no válido.

Certificación ISO 9000
• Los Estándares de calidad y procedimientos deberán ser documentados en un manual organizacional de calidad
• Personal externo puede certificar que una organización conforma con los estándares ISO 9000
• Los clientes demandan cada vez mas que sus desarrolladores tengan la certificación ISO 9000

La relacion que hay entre la calidad y la ingenieria del software es que sin calidad no se puede hacer ningun sistema de software por esta razon la calidad es muy importante para la creacion de dicho software.
Se relacionan entre si porque se necesitan de ambos para poder crear el sistema operativo.

http://es.wikipedia.org/wiki/Calidad_de_software
Sommerville, I. Ingeniería de Software, cap. 24
Pressman, R.S. Ingeniería del Software. Un enfoque práctico, cap. 8
avatar
Maria Elena Renteria

Mensajes : 8
Fecha de inscripción : 03/10/2012

Ver perfil de usuario

Volver arriba Ir abajo

APORT 1.-Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los más recomendables?

Mensaje  Victor Antonio el Jue Nov 29, 2012 3:36 pm

La Ingeniería de Software surge como la aplicación de modelos y formas de la ingeniería tradicional a la práctica de construir productos de software; situación que ha condicionado su accionar al tener como norte las precisiones y seguridades que en otros ámbitos tiene la ingeniería
El desarrollo orientado a prototipos
Si bien algunos autores consideran que esto es parte del ciclo de vida clásico (Boehm, 1988), es también posible verlo como un método independiente.
Una definición de un prototipo en software podría ser:
"...es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas"
Las fases que comprende el método de desarrollo orientado a prototipos serían:
Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.
Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.
Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.
4
Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos.
Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial.
Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.
Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.

Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por: reducción de la incertidumbre y del riesgo, reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema, mejoras en la administración de proyectos, mejoras en la comunicación entre desarrolladores y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también presenta desventajas como: la dependencia de las herramientas de software para el éxito ya que la necesidad de disminución de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones exista mejor y esto último se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas. También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.
No se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en dos aspectos importantes: primero se ha aproximado las visiones del usuario y el desarrollador, lo cual representa el beneficio de establecer una base común de comunicación; también, el hacer explícita la posibilidad de iterar sobre estos dominios permitiría que la convergencia de los mismos sea una posibilidad cierta.
Pero lo anterior no asegura el éxito, por ejemplo, qué certeza existe en que esta iteración sea en la dirección correcta y lleve a la convergencia de los dominios; no se puede desconocer las diferencias que existen entre la prueba de un prototipo de software en la fase de definición de requerimientos y el uso del mismo ya como un producto terminado. Para explicar esto, podemos hablar de dos dominios en el usuario, uno que es el que se establece cuando se prueba el prototipo y otro, distinto por cierto, el que ocurre cuando el usuario hace uso del software en ambiente de explotación.
Por último, el proceso de iteración para que sea efectivo debería ser infinito, lo que lo hace poco efectivo. Es decir, mediante este método acercamos la problemática de los usuarios a los dominios de los desarrolladores y vice versa, pero no sería posible lograr un pareamiento uno a uno entre estos dominios, lo que sería el ideal.
El modelo de codificar y fijar
El modelo básico usado en los primeros días del desarrollo de software, tiene dos pasos:
-Escribir algún código.
- Fijar los problemas en el código.
Así, el orden de los pasos era fabricar algún código primero y pensar sobre los requerimientos, diseño, prueba y mantención a continuación. Este modelo tiene las dificultades de presentar una baja estructuración del código luego de alguna cantidad de fijaciones, pese a que se puede desarrollar un software de calidad, es posible que éste tenga una correspondencia muy pobre con las reales necesidades del usuario y, finalmente, si no existe la conciencia de la necesidad real de pruebas y modificaciones el costo de las sucesivas fijaciones será muy alto.
Este método resume las características de los métodos más formales desarrollados posteriormente, primero, la desvinculación con el problema: hay, de partida dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa. Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos.
En el sentido real, el ingeniero de programación crea modelos de situaciones físicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solución computacional del problema. Un principio fundamental de la ingeniería de programación es diseñar productos que minimicen la distancia intelectual entre el problema y la solución.
La variedad de enfoques en el desarrollo de programas está limitado únicamente por la creatividad e ingenio del programador; no siempre se encuentra con claridad el enfoque que minimice esta distancia, e incluso diferentes enfoques minimizan distintas dimensiones de la distancia.
Pero, por otro lado, la primera evolución con relación a los métodos es el resultado de las deficiencias presentadas por método de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitiría incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificación, coordinación y control.


rincondelvago.com/desarrollo-orientado-a-prototipos.html

Victor Antonio

Mensajes : 6
Fecha de inscripción : 28/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

APORT #1 ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software?

Mensaje  Juan_Manuel_V el Jue Nov 29, 2012 3:40 pm

Buenos días maestra y compañeros pues me llamo la atención la pregunta “3. ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software? Así que daré mi punto de vista esperando darle a conocer lo que necesita y me baso en la siguiente información.

-Modelo de desarrollo de software

Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a todos los proyectos de una organización. Una organización puede contar con uno o más modelos de desarrollo para ser utilizados dependiendo del tipo de proyecto.
Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y la idea final.
Un modelo de desarrollo establece el orden en el que se harán las cosas dentro de un proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.

-CARACTERÍSTICAS
Define la estructura de un proceso de desarrollo racional y controlable
• No existe un modelo universal
• Los modelos no son rígidos
• Son una guía respecto al orden en que deben adelantarse las actividades
• Se basa en el reconocimiento que el software tiene un ciclo de vida.
Actividades en el proceso de desarrollo de software
– Análisis de Requerimientos
– Especificación
– Diseño
– Programación
– Integración y Gestión de Configuraciones
– Validación y Verificación
– Prototipaje

-Modelos de Desarrollo de Software

• Relaciones entre las actividades: Modelo de Desarrollo
• Ciclo de vida del software
Las actividades en el proceso de desarrollo de software
• Se relacionan según determinados:
Modelos
• Se desarrollan aplicando un:
Método
• El método se fundamenta en:
Principios




LINK DE LA INFORMACION: www.slideshare.net/inventa2/modelos-de-desarrollo#btnNext
LINK DE LA INFORMACION: ldc.usb.ve/~mgoncalves/IS2/sd07/clase1.pdf

DEFINICION DE CALIDAD SOFTWARE


¿Qué es la calidad del software?

La calidad del software (calidad de un programa) se puede medir en base a tres aspectos principales:
• Sus características operativas.
• Su capacidad para sufrir cambios.
• Su adaptabilidad a entornos distintos.

¿Cómo se mide la calidad de un programa?

La Ingeniería del Software se utiliza sobre todo para desarrollar aplicaciones de gran envergadura (de miles o millones de instrucciones), en donde suelen participar distintos equipos de personas y, a veces, de distintas empresas de software. Suelen ser proyectos que pueden durar varios meses o incluso años. No obstante, por pequeño que sea un proyecto software, siempre es conveniente aplicar los principios de la Ingeniería del Software, ya que, esto ayudará a desarrollar un software de mayor calidad.

La calidad de un programa se puede medir en base a tres aspectos principales:

1. Sus características operativas. Se debe valorar si el software hace lo que se espera de él (corrección) y si, para ello, se utilizan, óptimamente, los recursos de la computadora (eficiencia), tales como: la memoria, el tiempo de CPU , etc. También se debe evaluar si la aplicación ofrece una interfaz adecuada al usuario (facilidad de uso) y si es seguro con respecto a los datos (integridad).

2. Su capacidad para sufrir cambios. En este sentido, es importante estimar en qué medida el programa es susceptible de ser corregido (facilidad de mantenimiento) o cambiado (flexibilidad). También hay que ver si resulta fácil hacer pruebas de su funcionamiento (facilidad de prueba).

3. Su adaptabilidad a entornos distintos. Hay que preguntarse hasta qué punto se podría volver a usar parte de dicho software en otro proyecto (reusabilidad). Asimismo, se debe valorar si el software puede interactuar con otros sistemas informáticos (facilidad de interoperación) y si se puede usar en otra máquina que utilice un procesador distinto (portabilidad), aunque sea realizando pequeños cambios en el software.

Todos los factores que influyen en la calidad de un proyecto software deben medirse a lo largo de todo su proceso de desarrollo, es decir, en el transcurso de todas las etapas del ciclo de vida, y no sólo al final. De esta forma, la calidad del producto software resultante, se puede ir mejorando sobre la marcha.
La calidad del software es aquel proceso en donde se verifica que el software o aplicación cumpla con los requerimientos o necesidades del cliente, integrando la velocidad de respuesta de la aplicación, el sistema de seguridad y confiabilidad.

También se puede definir como la coordinación, integridad y la aplicación de los estándares que tiene que ver con la correcta funcionabilidad y desarrollo de una aplicación.

No hay que olvidar la evolución de las propuestas de calidad que son:

-Factores de revisión: flexibilidad, mantenibilidad y contestación.

-Factores de transición: portabilidad, reusabilidad y interoperabilidad

-Factores de operación: eficiencia, integridad, usabilidad, fiabilidad y corrección.

También se debe tener en cuenta que en el mantenimiento de hardware es muy diferente al de software, porque el hardware se puede remplazar la pieza, mientras el software requiere de ingeniería, el software no se deteriora con el tiempo pues su curva de fallos es muy diferente a la de hardware.



LINK DE INFORMACION: www.buenastareas.com/ensayos/Definicion-De-Calidad-De-Software/1242677.html
LINK DE INFORMACION: www.carlospes.com/curso_de_ingenieria_del_software/01_04_calidad_del_software.php


Bueno pues en conclusión la relación que se tiene entre el concepto de calidad de software y un modelo de desarrollo de software es que siempre van de la mano, pues si bien es sabido para la realización o modificación de un modelo de desarrollo se necesita llevar a cabo la calidad de software ya que esta es fijada con el fin de que se implemente en un programa o modelo para evitar un mal funcionamiento que llegase a ocasionar la perdida de información o insatisfacción del usuario además de generar un mayor grado de error.
Me despido de ustedes con una pregunta que me ha surgido ¿Si la relación entre ambas no existiera que seria lo peor que podría suceder?

Juan_Manuel_V

Mensajes : 7
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

APORT.1 ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software. Explique

Mensaje  tony-cuevas el Jue Nov 29, 2012 5:55 pm

BUENAS TARDES TENGAN TODOS USTEDES COMPAÑEROS DEL FORO Y MAESTRA

Respecto a su pregunta ¿Qué relación existe entre un Modelo de Desarrollo de Software y el concepto de Calidad de Software?
me di a la tarea de investigar lo siguiente

Modelos de Desarrollo de Software
-como todos sabemos, existen diversos modelos desarrolladores de software, pero en una empresa u organizacion es dificil ver la implementacion y utilizacion de muchos o todos estos. Ningun proyecto es igual a otro, ya que los ingenieros utilizar el modelo que mas le convenga o le guste, por lo que el orden o seguimiento que se le da al programa no es igual del todo.

MODELOS DESARROLLADORESDE SOFtWARE
La Ingeniería de Software surge como la aplicación de modelos y formas de la ingeniería tradicional a la práctica de construir productos de software; situación que ha condicionado su accionar al tener como norte las precisiones y seguridades que en otros ámbitos tiene la ingeniería.
Un modelo es el conjunto de ideas que se tienen prediseñadas para llevar a cabo un proyecto o simplemente un objetivo y software es todo aquello intangible de una computadora.
Entonces se puede decir que el modelo de desarrollo de software es de mucha importancia pues de esta forma se puede asegurar la certificación de la calidad del mismo.
La especialización busca crear una cultura en el profesional estudiante, mediante la cual a partir de su propia disciplina sea capaz de aplicar y reapropiar conocimientos científicos, técnicos y vivenciales con el objetivo de mejorar los procesos de construcción de software en organizaciones, establecer estrategias para el desarrollo de productos de calidad y su adecuada planeación y comercialización.
el gran desafío con que se encuentra la gestión de proyectos software consiste precisamente
en limitar los productos que se desarrollan en esos proyectos a unos niveles de complejidad
aceptables y manejables. Dicho de otra forma, se pretende reducir los grados de libertad en la
producción de software para, al operar dentro de unos ciertos márgenes, mantener la complejidad
resultante lo más baja posible.

CALIDAD DE SOFTWARE
• La calidad está de moda, en todos los aspectos, pero
especialmente en el desarrollo de software.
• El interés por la calidad crece de forma continua, a medida
que los clientes se vuelven más selectivos y comienzan a
rechazar los productos poco fiables o que realmente no
dan respuesta a sus necesidades.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.

Calidad de software
Características propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.
La Ingeniería del Software se utiliza sobre todo para desarrollar aplicaciones de gran envergadura (de miles o millones de instrucciones), en donde suelen participar distintos equipos de personas y, a veces, de distintas empresas de software. Suelen ser proyectos que pueden durar varios meses o incluso años. No obstante, por pequeño que sea un proyecto software, siempre es conveniente aplicar los principios de la Ingeniería del Software, ya que, esto ayudará a desarrollar un software de mayor calidad.

La calidad de un programa se puede medir en base a estos aspectos principales:
Sus características operativas. Se debe valorar si el software hace lo que se espera de él (corrección) y si, para ello, se utilizan, óptimamente, los recursos de la computadora (eficiencia), tales como: la memoria, el tiempo de CPU , etc. También se debe evaluar si la aplicación ofrece una interfaz adecuada al usuario (facilidad de uso) y si es seguro con respecto a los datos (integridad).
Su capacidad para sufrir cambios. En este sentido, es importante estimar en qué medida el programa es susceptible de ser corregido (facilidad de mantenimiento) o cambiado (flexibilidad). También hay que ver si resulta fácil hacer pruebas de su funcionamiento (facilidad de prueba).
Su adaptabilidad a entornos distintos. Hay que preguntarse hasta qué punto se podría volver a usar parte de dicho software en otro proyecto (reusabilidad). Asimismo, se debe valorar si el software puede interactuar con otros sistemas informáticos (facilidad de interoperación) y si se puede usar en otra máquina que utilice un procesador distinto (portabilidad), aunque sea realizando pequeños cambios en el software.

[img] [/img]


en conclucion los modelos desarrolladores de software siempre tienen que tener en cuenta la calidad de un producto o programa, ya que los clientes son los que deciden si se quedan con un programa que esta en excelentes condiciones de trabajo.
la calidad es importante porque es como funciona el programa, como fue creado,como se ve, la facilidad de manejo, el diseño creado, etc.
por ultimo me queda decir que depende una de la otra.


http://www.buenastareas.com/ensayos/Modelos-De-Desarrollo-De-Sw/110326.html
http://es.wikipedia.org/wiki/Calidad_de_software
www.noqualityinside.com/nqi/nqifiles/CalidadDeSW_diap.pdf
www.carlospes.com/curso_de_ingenieria_del_software/01_04_calidad_del_software.php



tony-cuevas

Mensajes : 8
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport 1 Porqué utilizar herramientas CASE en el proceso de desarrollo de software. Qué relación tienen estas herramientas con los modelos de desarrollo? Justifique

Mensaje  hassiel el Jue Nov 29, 2012 6:58 pm

Hola maestra aquí nuevamente yo ya que al hacer la aportación pasada no me di cuenta de que ese tema ya no se podía desarrollar bueno aquí le presento la información de:
Porqué utilizar herramientas CASE en el proceso de desarrollo de software. Qué relación tienen estas herramientas con los modelos de desarrollo? Justifique

En mi opinión el usar las herramientas CASE para el desarrollo de software es importante ya que es mucho mas seguro y novedoso ya que estas herramientas le ayudan a corregir errores que se puedan presentar.
Juegos de herramientas o toolkits, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de estegrupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Otra posible clasificación, utilizando la funcionalidad como criterio principal, es la siguiente:
• Herramientas de gestión de proyectos
• Herramientas de gestión y configuración de software (SCM)
• Herramientas de calidad y seguridad de software
• Herramientas de análisis y diseño
• Herramientas de desarrollo de interfaz de usuarios
• Herramientas para la Ingeniería de Software Orientada a Objetos
• Herramientas de integración y prueba
• Herramientas de métodos formales
• Herramientas Cliente/Servidor
• Herramientas de Ingeniería WEB
• Herramientas de Reingeniería
• Beneficios de las Herramientas CASE
Entre los beneficios más significativos de las herramientas CASE se enumeran los siguientes:
• 1. Facilidad para la revisión de aplicaciones
La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan unbeneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.
• 2. Soporte para el desarrollo de prototipos de sistemas
En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos.
• 3. Generación de código
La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y lasestructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos.
• 4. Mejora en la habilidad para satisfacer los requerimientos del usuario
Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.
• 5. Soporte interactivo para el proceso de desarrollo
La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar eltedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.
2. Ejemplos de Herramientas CASE
Las herramientas CASE se han venido ampliando y desarrollando, existe una gran variedad de estas con características específicas, a continuación describiremos algunas de ellas, desde las más actuales hasta otras ya no tanto.
2.1 Microsoft Project
Microsoft Project es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas detrabajo.
Permite el aprendizaje rápido con el planeamiento y la administración guiados, organización y seguimiento de las tareas y recursos, comparar versiones de planes de proyectos, evaluar los cambios, realizar un seguimiento del rendimiento, generar informes predefinidos, compartir planes de proyecto, colaboración entre grupos de trabajo, presenta diagramas como: Diagrama de Grant y Diagrama de Pert (diagrama de red).
El software Microsoft Office Project en todas sus versiones (la versión 2007 es la más reciente) es útil para la gestión de proyectos, aplicando procedimientos descritos en el PMBoK (Management Body of Knowledge) del PMI (Project Management Institute).
La primera versión de Microsoft Project fue lanzada para DOS en 1984 por una compañía que trabajaba para Microsoft. Microsoft adquirió todos losderechos del software en 1985 y liberó la versión 2. La versión 3 para DOS fue liberada en 1986. La versión 4 para DOS fue la última versión para este sistema operativo, liberada en 1987. La primera versión para Windows fue liberada en 1990, y fue llamada versión 1 para Windows. Un dato interesante es que la primera versión para DOS introdujo el concepto de Líneas de dependencia (link lines) entre tareas en la gráfica de Gantt.
Una versión para Macintosh fue liberada en julio de 1991 y su desarrollo continuó hasta Project 4.0 para Mac en 1993. En 1994, Microsoft detuvo el desarrollo para la mayoría de las aplicaciones Mac, y no ofreció nuevas versiones de Office hasta 1998, después de la creación del nuevo Microsoft Macintosh Business Unit el año anterior. El MacBU nunca lanzó una versión actualizada para Proyect, y la versión anterior de 1993 no es ejecutada nativamente en Mac OS X.
Las versiones fueron lanzadas en 1992 (v3), 1993 (v4), 1995, 1998, 2000, 2002, 2003 y 2007
La aplicación crea calendarización de rutas criticas, además de cadenas críticas y metodología de eventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resource leveled, y las gráficas visualizadas en una Gráfica de Gantt. Adicionalmente, Project puede reconocer diferentes clases de usuarios, los cuales pueden contar con distintos niveles de acceso a proyectos, vistas y otros datos. Los objetos personalizables como calendarios, vistas, tablas, filtros y campos, son almacenados en un servidor que comparte la información a todos los usuarios.
La familia de Microsoft Project incluye: Microsoft Project Standard, Microsoft Project Professional, Microsoft Project Server y Microsoft Project WebAccess.
Microsoft Project y Project Server son piezas angulares del Microsoft Office Enterprise Project Management (EPM).
Microsoft reveló que las futuras versiones de Microsoft Project contarán con Interfaz de usuario fluida.


2.2 Racional Rose

Rational Rose es una herramienta de producción y comercialización establecidas por Rational Software Corporation (actualmente parte de IBM). Rose es un instrumento operativo conjunto que utiliza el Lenguaje Unificado (UML) como medio para facilitar la captura de dominio de la semántica, laarquitectura y el diseño.
Este software tiene la capacidad de:

Sus características principales:
• No es gratuito, se debe hacer un previo pago para poder adquirir el producto.
• La ingeniería de código (directa e inversa) es posible para ANSI C++, Visual C++, Visual Basic 6, Java, J2EE/EJB, CORBA, Ada 83, Ada 95, Bases de datos: DB2, Oracle, SQL 92, SQL Server, Sybase, Aplicaciones WEB.
• Solamente Ingeniería reversa para COM.
• Rational Rose habilita asistentes para crear clases y provee plantillas de código que pueden aumentar significativamente la cantidad de código fuente generado. Adicionalmente, se pueden aplicar los patrones de diseño, Racional Rose ha provisto 20 de los patrones de diseño GOF para Java.
• Admite la integración con otras herramientas de desarrollo (IDEs).
• Requerimientos :
• Windows 2000 Professional, Service Pack 4
• Windows XP Professional, Service Pack 2
• Windows 2000 and 2003 Server and Advanced Server, Service Pack 3 and 4
• Windows Vista
• Linux
La siguiente tabla muestra el soporte para Ciclo de Vida de un Proyecto en Rational Rose
Disciplina de Proyecto Rose
Modelado de Negocio Si. Usando el modelo de casos de uso de negocio
Administración de Requisitos Junto con RequisitePro.
Análisis y Diseño Si. Diagramas UML de clases y de interacción. El asistente de frameworks provee una gran cantidad de plantillas para estructurar el modelo
Implementación Soporta la mayoría de los lenguajes excepto .NET
Prueba No. Se provee Quality Architect para pruebas unitarias, pero requiere otras herramientas Rational, tales como Test Manager y Robot.
Control de Versiones Integrado con la aplicación de control de versiones compatible con SCC.
Administración del Proyecto No
Publicación Web Si
Documentación No. Requiere el uso de SoDA
Múltiples Usuarios Concurrentes Si
Ventana de trabajo:


2.3 JDeveloper

Este magnífico entorno integrado desarrollado por Oracle trabaja con la ingeniería inversa, es decir primero se crea él código y después el diagrama.
Es un software propietario pero gratuito desde 2005. Las primeras versiones de 1998 estaban basadas en el entorno JBuilder de Borland, pero desde la versión 9i de 2001 está basado en Java, no estando ya relacionado con el código anterior de JBuilder.
Sus características principales:
• Es un entorno gratis, aunque previamente se debe suscribir para poder descargarlo. Puede descargarse en :
http://www.oracle.com/technology/products/jdev/index.html.
• Netamente desarrollado para Java.
• Posee diagrama de clases (UML).
• Funciona en los siguientes sistemas operativos:
• Windows.
• Linux.
• Mac OSX

2.4 MagicDraw
MagicDraw es una herramienta de modelaje con completas características UML, sin duda es una de las mejores herramientas CASE del mercado, que procura mantenerse además siempre al día con continuas actualizaciones. Es desarrollada por No Magic, Inc. Implementada totalmente en JAVA. Diseñada para los analistas del negocio, los analistas del software, los programadores, los ingenieros de software, y los escritores de la documentación, esta herramienta de desarrollo dinámica y versátil facilita análisis y el diseño de los sistemas y de las bases de datos orientados objeto.
Características principales:
• Interfaz elegante e intuitiva, la mayor parte de las opciones accesibles con un solo click.
• Ayudas en el diseño con autocompletación y corrección automática en tiempo real.
• Permite visualizar el proyecto de diferentes formas.
• Posible derivación de modelos UML a través de códigos fuente escritos anteriormente.
• Facilidad y rapidez para el cambio del dominio del modelado.
• Generador automático de informes.
• Desarrollo colaborativo directamente con la herramienta a través del Team Work Server (Software que permite trabajar a más de un desarrollador sobre el mismo proyecto en el mismo instante, el modelo está almacenado en un equipo servidor y los desarrolladores pueden consultar y actualizar la información).
• Disponible para un gran número de plataformas y sistemas operativos.
La versiones existentes de MagicDraw son: Reader, Community, Personal, Standard, Profesional, Entrerprise.
Reader:
-Permite la visualización e impresión de proyectos.
-Gratuita.
-Destinada para poder compartir ficheros.
Community:
-Destinada para desarrolladores que creen proyectos no comerciales.
-Disponibles pocas funcionalidades y con restricciones.
-Gratuita.
Personal:
-Disponibles todas las funcionalidades.
-Destinada para el uso individual, no contiene Team Work Server.
Standard:
A todas las funcionalidades de la versión personal añade:
-Integración con IDE"s.
-Soporte para el desarrollo colaborativo.
Profesional:
-Incorpora soporte de generación de código e ingeniería inversa para lenguajes como: Java, C++, C#.
Enterprise:
-La versión más avanzada de MagicDraw
-Permite cualquier modelado.
-Recuperación de estructuras mediante JDBC.
-Producción de modelos personalizados o específicos como XML y DDL.
Soporta la integración con los siguientes IDEs:
• Sun Java Studio 8.
• Borland CaliberRM 6.0, 6.5 requirements tool.
• Oracle Workshop 8.1.2.
• E2E Bridge 4.0
• IntelliJ IDEA 4.X o mayor.
• NetBeans 6.X o mayor.
• Eclipse 3.1 o mayor.
• IBM Rational Application Developer
• Borland JBuilder 8.0, 9.0, X, 2005, 2006, 2007
• Built-in CVS interface for storing project files.
• Integración con herramientas MDA: Compuware OptimalJ, AndroMDA, Interactive Objects ArcStyler, openArchitectureWare, E2E Bridge, Mia-Software Tools and Netfective' Blu Age.
Además MagicDraw tiene plug-ins para que soporten:
• Usando SysML para Ingeniería de Sistemas.
• DoDAF para compilar modelos.
• Trabajando con IBM Rational RequisitePro and Telelogic DOORS para gestión de requerimientos.

2.5 Visual Paradigm
Visual Paradigm es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. También proporciona abundantes tutoriales de UML, demostraciones interactivas de UML y proyectos UML. Presenta licencia gratuita y comercial. Es fácil de instalar y actualizar y compatible entre ediciones.
Características principales:
• Soporte de UML versión 2.1.
• Diagramas de Procesos de Negocio - Proceso, Decisión, Actor de negocio, Documento.
• Modelado colaborativo con CVS y Subversion (control de versiones).
• Interoperabilidad con modelos UML2 (metamodelos UML 2.x para plataforma Eclipse) a través de XMI.
• Ingeniería de ida y vuelta.
• Ingeniería inversa - Código a modelo, código a diagrama.
• Ingeniería inversa Java, C++, Esquemas XML, XML, NET exe/dll, CORBA IDL.
• Generación de código - Modelo a código, diagrama a código.
• Editor de Detalles de Casos de Uso - Entorno todo-en-uno para la especificación de los detalles de los casos de uso, incluyendo la especificación del modelo general y de las descripciones de los casos de uso.
• Diagramas EJB - Visualización de sistemas EJB.
• Generación de código y despliegue de EJB - Generación de beans para el desarrollo y despliegue de aplicaciones.
• Diagramas de flujo de datos.
• Soporte ORM - Generación de objetos Java desde la base de datos.
• Generación de bases de datos - Transformación de diagramas de Entidad-Relación en tablas de base de datos.
• Ingeniería inversa de bases de datos - Desde Sistemas Gestores de Bases de Datos (DBMS) existentes a diagramas de Entidad-Relación.
• Generador de informes.
• Distribución automática de diagramas - Reorganización de las figuras y conectores de los diagramas UML.
• Importación y exportación de ficheros XMI.
• Integración con Visio - Dibujo de diagramas UML con plantillas (stencils) de Microsoft Visio.
• Editor de figuras.
Más otras herramientas y plugins de modelado UML:
• Plataforma Java (Windows/Linux/Mac OS X):
• SDE para Eclipse.
• SDE para NetBeans.
• SDE para Sun ONE.
• SDE para Oracle JDeveloper.
• SDE para JBuilder.
• SDE para IntelliJ IDEA.
• SDE para WebLogic Workshop.
• Plataforma Windows:
• SDE para Microsoft Visual Studio
2.6 Microsoft Visio
Microsoft Visio es un software de diagramas para Microsoft Windows. Usa gráficos de vectores para crear diversos diagramas. Facilita a los profesionales empresariales y de Tecnologías de la Información la visualización, el análisis y la comunicación de información compleja. Los diagramas de Visio comunican información de un vistazo, conectados a datos muestran información, son fáciles de actualizar y pueden aumentar espectacularmente la productividad. La amplia variedad de diagramas de Microsoft Visio permite comprender, procesar y compartir información sobre los sistemas, recursos y procesos organizativos de una empresa.
Micorsoft Visio está disponible en dos ediciones independientes: Office Visio Professional y Office Visio Standard. Office Visio Standard tiene la misma funcionalidad básica que Office Visio Professional e incluye un subconjunto de sus características y plantillas. Office Visio Professional ofrece funcionalidad avanzada, como conectividad de datos y características de visualización, que no se incluyen en Office Visio Standard. Ambas ediciones, Standard y Professional, comparten la misma interfaz.
Microsoft adquiere Visio Corporation en 2000. Visio 2007 fue liberado el 30 de noviembre del 2006.
Microsoft reveló que la siguiente versión de Microsoft Visio presentará un cordón de unión entre interfaces de usuario.
2.7 Enterprise Architect
Enterprise Architect (EA) Professional es una herramienta CASE de Sparx Systems. Soporta ocho de los nueve diagramas estándares del UML: diagrama de casos de uso, de clases, de secuencia, de colaboración, de actividad, de estados, de implementación (componentes), de despliegue y varios perfiles del UML. Si fuera necesario, el diagrama de objetos se puede crear usando los diagramas de colaboración.
Enterprise Architect tiene un mecanismo de perfil UML genérico para cargar y trabajar con diferentes perfiles UML. En Enterprise Architect, estos perfiles se especifican en archivos XML con un formato específico. Los perfiles disponibles son:
Modelado de Procesos de Negocio: Soporta las extensiones de modelado de procesos de negocio de Eriksson-Penker.
Modelado de Datos.
Modelado de la Interfaz de Usuario.
Modelado Web.
Esquema XSD
Permite ingeniería de código (directa e inversa) para ANSI C++, Visual Basic 6, Java, C#, VB.NET, Delphi y Bases de datos: Ingeniería directa desde el modelo de datos al script DDL. La ingeniería reversa usa la fuente de datos ODBC.
La forma en la que EA trabaja es generando los archivos de código fuente de las clases para aquellas que correspondan al mismo paquete. Adicionalmente, se pueden aplicar los patrones de diseño, el usuario tiene que crear los patrones.
La siguiente tabla muestra el Soporte del Ciclo de Vida del Proyecto en Enterprise Architect
Disciplina de Proyecto Enterprise Architect
Modelado de Negocio Si. Usando perfiles de UML para el modelado de procesos de negocio
Administración de Requisitos Si. Requisitos funcionales y no funcionales; matriz de trazabilidad de requisitos.
Análisis y Diseño Si. Diagramas UML de clases y de interacción. Requiere agregar algunos estereotipos como <> o <<use case realization>> si se necesitan. En ocasiones hay que modificar la plantilla
Implementación Es adecuada para proyectos C++, VB, C# y VB.NET
Prueba Si
Control de Versiones No lo soporta directamente. Aproximación: usar unidad controlada. Está planificada para futuras versiones.
Administración del Proyecto Administración de Riesgos - Asignación de Recursos - Estimación del Proyecto
Publicación Web Si
Documentación Si
Múltiples Usuarios Concurrentes Si
2.8 BoUML
BoUmL es una herramienta de software libre. Pude ser redistribuida o modificada bajo los términos de Licencia Pública General (GNU).
Es una herramienta que permite especificar y generar código en C++, Java, Php y IDL.
Sus Características principales:
• Es gratis.
• Es multiplataforma: Linux, Solari, Mac Os, Windows.
• Permite programar simultáneamente en C++, Java, Php y IDL.
• Es rápido, no necesita mucho espacio de memoria.
Esta herramienta puede descargarse en: http://bouml.free.fr/.

2.9 CASE Studio
Herramienta con potente utilidad de modelado para varias bases de datos. CASE Studio es una herramienta profesional con la que pueden diseñarse bases de datos, incluye facilidades para la creación de diagramas de relación, modelado de datos y gestión de estructuras. Tiene soporte para trabajar con una amplia variedad de formatos de base de datos (Oracle, SQL, MySQL, PostgreSQL, Access) y permite además generar xcripts SQL, aplicar procesos de ingeniería inversa, usar plantillas de diseño personalizables y crear detallados informes en HTML y RTF.

2.10 ArgoUML
Herramienta que contiene funciones avanzadas en las etapas de diseño y modelación de software. Presenta licencia comercial.
Como características fundamentales:
• Es modular y extensible.
• Soporta todas las especificaciones UML.
• Integrado con la WEB.
• Brinda una excelente ayuda.
2.11 Poseidon
Es una herramienta para modelar cualquier clase de sistema, relacionado o no con programación por computadoras. Se presenta en dos ediciones: Community Edition y Professional Edition.
Sus características fundamentales son:
• Soporta diagramas UML.
• Permite Generación de código para Java y exportación como HTML.
• Fácil de instalar y actualizar.
• Compatibilidad entre ediciones.
• Opciones avanzadas de impresión.
• Soporta gráficos en la mayoría de los formatos.
• Varios idiomas.
2.12 EasyCASE
EasyCASE es un producto para la generación de esquemas de base de datos e ingeniería reversa. Esta herramienta permite automatizar las fases de análisis y diseño dentro del desarrollo de una aplicación, para poder crear las aplicaciones eficazmente, desde procesamiento de transacciones a la aplicación de bases de datos de cliente/servidor, así como sistemas de tiempo real.
EasyCASE permite capturar los detalles de diseño de un sistema y comunicar las ideas gráficamente, para que sean fáciles de ver y entender. Para un diseño legítimo y modelado de datos, procesos y eventos, permite crear y mantener diagramas de flujo de datos, diagramas de entidad-relación, mapasde estructura y más.
Posee herramientas de corrección avanzadas que permiten revisiones generales. Permite re-usar diagramas o partes de diagramas para economizar el diseño de un proyecto.
EasyCASE soporta una gama amplia de metodologías estructuradas, permitiendo escoger los métodos más apropiados para realizar las tareas. Determina los tipos de esquemas según la metodología del proyecto seleccionada y notifica de errores a medida que el modelo vaya construyéndose.
El verdadero poder de EasyCASE se encuentra en el soporte comprensivo al modelado de datos, procesos y eventos. Posee desde el editor de diagramas flexible y un diccionario de los datos, así como una extensa cantidad de reportes y análisis.
Es una herramienta multi-usuario, permite compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder a proyectos localizados en el servidor de la red concurrentemente. Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al registro, al archivo y al proyecto, y niveles de control de acceso.
Especificaciones de EasyCASE Profesional:
Metodologías Estructuradas:
. Yourdon/DeMarco
. Gane & Sarson
. Ward-Mellor
. SSADM
. Yourdon/Constantine
. Chen
. Martin
. Bachman
. Shlaer-Mellor
. IDEF1X
. Merise
. Metrica
Bases de Datos que soporta:
.Oracle
. Paradox
. Progress
. SQLBase
. SQL Server
. Sybase
. Watcom SQL
. Access
. ANSI SQL
. Clipper
. dBASE III , IV, V
. DB2
. FoxPro
. Informix
. Otras más ...
Tipos de Diagramas:
. Data Flow Diagrams (DFDs)
. Transformation Schema (real-time DFDs)
. Structure Charts (STCs)
. State Transition Diagrams (STDs)
. Entity Relationship Diagrams (ERDs)
. Data Model Diagrams (DMDs)
. Data Structure Diagrams (DSDs)
. Entity Life History Diagrams (ELHs)
. Logical Data Structure Diagrams (LDSs)

2.13 ERwin
PLATINUM ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos.
Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos.
ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo Entidad-Relación de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
Más que una herramienta de dibujo, ERwin automatiza el proceso de diseño de una manera inteligente. Por ejemplo, ERwin habilita la creación de un diccionario de atributos reusables, asegurando la consistencia de nombres y definiciones para su base de datos.
Se mantienen las vistas de la base de datos como componentes integrados al modelo, permitiendo que los cambios en las tablas sean reflejados automáticamente en las vistas definidas. La migración automática garantiza la integridad referencial de la base de datos.
ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, Edwin genera automáticamente tablas, vistas, índices, reglas de integridad referencial (llaves primarias, llaves foráneas), valores por defecto y restricciones de campos y dominios.
ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, SQL Server, Sybase, DB2, e Informix.
El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
Especificaciones Técnicas:
Software de Aplicación Compatibles: NetDynamics, PowerBuilder, PROGRESS, Visual Basic.
Bases de Datos Compatibles: CA-Clipper, CA-OpenIngres, DB2 for MVS y DB2 for OS/390, DB2 UDB, dBASE, FoxPro, HiRDB, Informix, InterBase, Microsoft Access, Microsoft SQL Server, Oracle, Paradox, Rdb, Red Brick Warehouse, SAS, SQL Anywhere, SQLBase, Sybase, Teradata.

2.14 Oracle Designer
Oracle Designer es un juego de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor.
Integrado con Oracle Developer, Oracle Designer provee una solución para desarrollar sistemas empresariales cliente/servidor. Sofisticadas aplicaciones cliente/servidor pueden ser 100% generadas usando la lógica de la aplicación y el módulo de componentes reusables. Oracle Designer también habilita la captura del diseño de sistemas existentes, salvaguardando la versión actual.
Todos los datos ingresados por cualquier herramienta de Oracle Designer, en cualquier fase de desarrollo, se guardan en un repositorio central, habilitando el trabajo fácil del equipo y la dirección del proyecto.
En el lado del Servidor, Oracle Designer soporta la definición, generación y captura de diseño de los siguientes tipos de bases de datos, por conexión nativa de Oracle y por conectividad ODBC:
• Oracle7 y más
• ?Personal Oracle Lite
• Rdb
• ANSI 92
• DB and MVS
• Microsoft SQL Server
• Sybase
Oracle Designer no fuerza al uso de alguna metodología específica, pero en cambio proporciona un juego de herramientas que le permiten que use la metodología de desarrollo que elija.
Oracle Designer soporta las siguientes metodologías: Desarrollo Rápido de Aplicaciones (RAD), ?Ingeniería de la Información (IE), ?Modelado Asistido de Procesos, Captura de Diseño Asistido.
Las herramientas de Oracle Designer se agrupan en áreas que reflejan las necesidades primarias de sus tipos diferentes de usuarios:
Requisitos para el Modelado de Sistemas:
Uso de las herramientas en esta área: procesos para el modelo del negocio; re-examinar los métodos usados para conseguir las metas de la organización; crear representaciones diagramáticas de los procesos del negocio; detalles de los registros; describir los requisitos del negocio en detalle; crear modelos diagramáticos de las entidades, funciones y flujos de datos en los sistemas que constituyen la organización.
Generadores de Diseños Preliminares:
Uso de Transformadores para generar los diseños preliminares de los modelos creados anteriormente.
Diseño y Generación:
Uso de las herramientas en esta área: diseño de sistemas que reúnan los requisitos comerciales de una organización; proveer un ambiente de desarrollo para los ingenieros de sistemas y diseñadores; crear componentes del lado del servidor y aplicaciones del lado del cliente desde definiciones grabadas en el Repositorio de Datos.
Utilitarios:
Uso de las herramientas en esta área: ingresar y editar la información en el Repositorio; mostrar las relaciones entre los elementos en el Repositorio de Datos; generar etiquetas predefinidas y personalizadas en el Repositorio; administrar el Repositorio de datos; escribir sentencias interactivas en SQL.


2.15 PowerDesigner
PowerDesigner es una suite de aplicaciones de Powersoft para la construcción, diseño y modelado de datos a través de diversas aplicaciones. Es una herramienta para el análisis, diseño inteligente y construcción sólida de una base de datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual.
Esta suite cuenta con los siguientes productos:
• PowerDesigner ProcessAnalyst: Permite analizar el flujo de datos de toda la empresa, a través de los departamentos hasta el usuario final.
• PowerDesigner DataArchitect: Provee a los diseñadores de las bases de datos una manera eficiente para la creación inteligente, depuración e ingeniería de reversa del modelado, tanto conceptual como físico de los datos.
• PowerDesigner AppModeler: Permite el diseño y ajuste de los componentes de objetos y datos en aplicaciones de uso común como PowerBuilder, Power++, Visual Basic y Delphi, ajustando el modelo de base de datos. Junto con la aplicación de servidor PowerDynamo (incluido) se pueden publicar las bases de datos en Internet directamente del modelo de base de datos. Esta herramienta también puede generar páginas de servidor activas para Microsoft Internet Information Server.
• PowerDesigner WarehouseArchitect: Provee un poderoso datawarehousing para el diseño e implementación de una base de datos. Cuenta con soporte para bases de datos tradicionales DBMS y bases de datos en plataformas de sistemas analíticos usando modelados dimensionales, esquemas de "estrella" y "nieve", particionamiento y agregación. También cuenta con un alto desempeño en el indexamiento de esquemas.
• PowerDesigner MetaWorks: Permite fácilmente ver y compartir la información del modelado de datos con una definición constante de objetos. También puede comparar y mezclar dos modelos de datos paso a paso.
• PowerDesigner Viewer: Crea reportes de los modelos físicos, conceptuales y procesos del modelado de la base de datos. También permite generar reportes para Internet en HTML. Este producto cuenta con demos directos de sitio de Sybase en Internet para su evaluación.
Además de todas estas características, PowerDesigner ofrece las posibilidades de:
• Soporte para tipos de datos abstractos: PowerDesigner soporta la identificación de tipos de datos abstractos con ingeniería inversa de aplicaciones para Oracle.
• Soporte para usuarios de bases de datos: Los usuarios de bases de datos pueden ser recogidos de una base de datos existente y luego almacenados en un modelo físico de datos. Ahora, es posible añadir nuevos usuarios y también asignar usuarios como propietarios y vistas.
• Mayor selectividad en ingeniería inversa: PowerDesigner permite seleccionar no sólo las tablas que se desean cargar, sino todo tipo de objetos de la base de datos.
• Cálculo del tamaño de las bases de datos: Puede calcular y definir el tamaño definitivo de bases de datos de nuevo diseño y construcción, incluyendo tamaños detallados de índices y tablas.
2.16 System Architect
System Architect posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balanceamiento entre diagramas "Padre e Hijo", además de balanceamiento horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.
System Architect es considerado un Upper Case, que puede ser integrado a la mayoría de los generadores de código. Traduce modelos de entidades, a partir de la enciclopedia, en esquemas para Sybase, DB2, Oracle, Ingress, SQL Server, RDB, XDB, Progress, Paradox, SQL Base, AS400, Interbase, OS/2, DBMS, Dbase 111, Informix, entre otros. Genera también Windows DDL y definiciones de datos para lenguaje C/C++. Posibilita a través de ODBC, la creación de bases de datos a partir del modelo de entidades, para los diversos manejadores de bases de datos arriba mencionados.
Posee un módulo específico para Ingeniería Reversa desde las Bases de Datos SQL más populares, incluyendo Sybase, DB2, Infonmix, Oracle y SQL Server (DLL), además de diálogos y menús desde Windows.
System Architect posee múltiples metodologías para diseño y análisis, incluyendo: Análisis Estructurado en los modelos De Marco/Yourdon y Gane/Sarson, análisis de tiempo real en el modelo Ward & Mellor; análisis esencial de sistemas; análisis orientado a objetos en los modelos UML, Booch, Coad/Yourdon, Rumbaugh, Shaler/Mellor; Diagrama de entidad - relación en los modelos Peter Chen, James Martin, Bachman o Booch, Gráfico de Estructuras, Diagramas de Descomposición, Planeamiento Estratégico de informaciones, entre otras.
Es una herramienta creada específicamente para la arquitectura "Cliente/Servidor", por eso posee control total de versiones, y de acceso, así como la administración completa de múltiples equipos de desarrollo.

2.17 Otras Herramientas
• ASADAL: Herramienta CASE especializada en Sistemas de Tiempo Real
• CASE GENEXUS Tool
• Win A&D, herramientas CASE para Análisis y Diseño, incluye técnicas estructuradas y orientadas a objetos.
• CRADLE, conjunto de herramientas CASE integradas que dan soporte a la Planificación estratégica, Análisis y Diseño.
• SilverRun: Conjunto integrado de de herramientas CASE para el modelado de negocios.
• SNAP
• VISIBLE ANALYST
• UMLCAKE
• WINPROJECT
• TOGETHER
• OBJECTEERING
• MEGA SUITE
• OBJECT DOMAIN
• PROXY DESIGNER
• UML DIAGRAMMMER
• UMBRELLO UML MODELLER
Conclusiones
La herramientas CASE actualmente brindan una gran gama de componentes que incluyen todos o la mayoría de los requisitos necesarios para el desarrollo de los sistemas, han sido creadas con una gran exactitud en torno a las necesidades de los desarrolladores de software para la automatizaciónde procesos incluyendo el análisis, diseño e implantación. Ofrecen una gran plataforma de seguridad a sistemas que las usan.
Debido a la demanda que tienen las CASE, su exigencia en cuanto a su uso ha ido aumentando, por lo que toda CASE debe entre otras cosas: proporcionar topologías de aplicación flexibles, proporcionar aplicaciones portátiles, brindar un Control de versión, crear código compilado en el servidor, dar un Soporte multiusuario y ofrecer seguridad.
Las herramientas CASE cuentan con una credibilidad y exactitud que tienen un reconocimiento universal, siendo usadas por cualquier desarrollador y/o programador que busca un resultado óptimo y eficiente.

¿para ustedes seria importante utilizar estas herramientas para el desarrollo del software?

bibliografia:http://www.monografias.com/trabajos73/herramientas-case-proceso-desarrollo-software/herramientas-case-proceso-desarrollo-software2.shtml

hassiel

Mensajes : 9
Fecha de inscripción : 25/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los más recomendables?

Mensaje  dulce maria flores mata el Jue Nov 29, 2012 7:31 pm

Hola buenas tardes compañeros y maestra por mi parte decidí investigar la siguiente pregunta:
Qué ventajas ofrece un modelo de desarrollo de software?, Qué modelos son los más recomendables?
El modelo de desarrollo de software se compone de una mezcla de varios elementos, entre los que se encuentran la filosofía, el modelo de negocio, y el licenciamiento. Ni la calidad ni el desempeño dependen del modelo
Unas de las ventajas de los modelos de desarrollo de sw es que nos ayuda a realizar bien y con muy alta calidad los programas, algunos de los posee etapas que nos ayuda a mejorar los programas, muchas permiten realizar buena tareas en el sw, son modelos que nos ayudan a darle forma al programa a desarrollar, algunos modelos se pueden complementar para dar más realce y mejor calidad al programa, obedecen las demandas del cliente,Otra de las principales ventajas del modelo de desarrollo de sw son las siguientes
Su Planificación es sencilla, muy útil en los proyectos sus especificaciones deben ser claras la mayoría son fáciles y comprensibles.

Es importante recordar que Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para el (los) proceso(s) de software que adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicación, planeación, modelado, construcción y desarrollo.
Este proceso plantea un enfoque de desarrollo iterativo incremental que permite un entendimiento progresivo de los requerimientos del Sistema a través de sucesivos refinamientos y el crecimiento incremental de una solución efectiva al problema planteado, permitiendo también que los riesgos del proyecto sean identificados
En cada etapa del desarrollo, ayudando a reducirlos significativamente. El desarrollo está basado en Casos de Uso para capturar los requerimientos y asegurar que éstos guían el diseño, implementación y verificación del software. Es centrado en la Arquitectura del Software, realizando la definición y construcción de ésta en etapas tempranas del desarrollo, lo que permite reducir los riesgos tecnológicos asociados, y sobre la cual se construirán incrementalmente el resto de las funcionalidades del sistema. Para el modelado en las disciplinas se utiliza el lenguaje UML.



Estos son unos de los modelos más usados y recomendables:

MODELO EN CASCADA:
Conocido también como CICLODE VIDA CLASICO, es un paradigma que sugiere un enfoque sistemático, secuencial, hacia el desarrollo de software que se inicia con la especificación de requerimientos del cliente y continuo con la planeación, el modelado, la construcción y el despliegue para culminar con el soporte del sw ya terminado. Una de sus ventajas es que puede ser útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión de una manera lineal.

imagen



MODELO EN V
Cuando cada proceso termina su producto, las especificaciones de prueba para la probar los procesos están también completas.

MODELO EN FLOR
El propósito del desarrollo de software es el de desarrollar un producto de software. Los equipos no deben de estar preocupados por el proceso de desarrollo mismo. Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final es alcanzado
MODELO EN ESPIRAL
Los productos de software son creados a través de múltiples repeticiones del proceso del ciclo de vida. Se rompen un mini-proyectos.
Estos modelos han sido aplicados al desarrollo de software.
Aún no han madurado al punto de ser aplicados como modelos de desarrollo con tiempos y limitaciones de costos.

MODELO INCREMENTAL
El modelo es una combinación del modelo en cascada, aplicado en forma iterativa.
Aplica secuencias lineales de manera escalonada según avance el tiempo.
En cada incremento, el desarrollo del software recorre nuevamente todas las etapas del modelo.

Desventajas:

Origina un software que puede estar débilmente estructurado y difícil de comprender y mantener.
Permite que los requerimientos y las decisiones de diseño se retrasen.

Desarrollo iterativo y creciente
El desarrollo iterativo establece la construcción de un principio pequeño después cada vez más grandes porciones de un proyecto de software para ayudar a todos los participantes a descubrir cuestiones importantes de forma temprana, antes de que problemas o supuestos defectuosos puedan conducir al desastre. Los procesos iterativos se prefieren por los desarrolladores comerciales, ya que permite un potencial de alcanzar los objetivos de diseño de un cliente que no sabe cómo definir lo que quiere.
Desarrollo Ágil
El desarrollo ágil de software utiliza el desarrollo iterativo como base, pero sus defensores demandan un punto de vista más claro y más centrado en las personas que los enfoques tradicionales. El modelos ágil, utiliza procesos de retroalimentación, en lugar de planificación, ya que este es su mecanismo primario de control. La reacción es impulsada por las pruebas regulares y las liberaciones de software en constante evolución.
Hay muchas variaciones de los procesos ágiles:
En Extreme Programming (XP), las fases se realizan en muy pequeña (o "continua") medida en comparación con los antiguos, "lotes" procesos. El (intencionalmente incompleta) pasan primero a través de los pasos que puede tomar un día o una semana, en lugar de meses o años en el modelo de cascada. En primer lugar, se escriben pruebas automatizadas, para proporcionar metas concretas para el desarrollo. Lo siguiente es la codificación (por un par de programadores), que se completa cuando todas las pruebas pasan, y los programadores no pueden pensar en más pruebas que se necesitan. Diseño y arquitectura emergen de refactorización, y viene en pos de codificación. El diseño es realizado por las mismas personas que hacen la codificación. (El último rasgo - la fusión de diseño y el código - es común a todos los procesos ágiles).
El modelo incremental
Aplica elementos del modelo en cascada aplicados en forma iterativa.
Se enfoca en la entrega de un producto operacional con cada incremento.
Es útil cuando no se cuenta con todo el personal necesario para desarrollar
el proyecto o para habilitar líneas paralelas de desarrollo.











Mi conclusión sobre este tema seria la siguiente


Las condiciones en que se aplica el Modelo de Desarrollo de Software OO en el ámbito académico no son directamente trasladables a la Industria, pero presenta algunas similitudes que hacen posible reflexionar sobre la forma en que se construye software y las dificultades que se plantean en su desarrollo. Un desafío planteado es poder obtener mediciones sobre la correspondencia entre el proceso seguido para desarrollar software y la calidad del producto obtenido.
Espero y sea de su agrado y se haya podido comprender, más sobre las ventajas de los modelos de desarrollo de software y también el poder comprender cuales son los más utilizados o cuales tienen más ventajas o desventajas al momento de realizarlos
El modelo incremental
Aplica elementos del modelo en cascada aplicados en forma iterativa.
Se enfoca en la entrega de un producto operacional con cada incremento.
Es útil cuando no se cuenta con todo el personal necesario para desarrollar
el proyecto o para habilitar líneas paralelas de desarrollo.



Cada uno de estos modelos tiene ventajas y desventajas que se deben considerar a la hora de seleccionar un modelo.
El modelo en cascada








El modelo en espiral









El modelo de prototipos







Mi conclusión sobre este tema seria la siguiente


Las condiciones en que se aplica el Modelo de Desarrollo de Software OO en el ámbito académico no son directamente trasladables a la Industria, pero presenta algunas similitudes que hacen posible reflexionar sobre la forma en que se construye software y las dificultades que se plantean en su desarrollo. Un desafío planteado es poder obtener mediciones sobre la correspondencia entre el proceso seguido para desarrollar software y la calidad del producto obtenido.
Espero y sea de su agrado y se haya podido comprender, más sobre las ventajas de los modelos de desarrollo de software y también el poder comprender cuales son los más utilizados o cuales tienen más ventajas o desventajas al momento de realizarlos

Espero que con el siguiente video se comprenda de una mejor manera mi pregunta sobre los modelos del sw gracias y asta luego.

[img][/img]

dulce maria flores mata

Mensajes : 8
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

4.¿Porqué utilizar herramientas CASE en el proceso de desarrollo de software. Qué relación tienen estas herramientas con los modelos de desarrollo? Justifique

Mensaje  Estebaann el Jue Nov 29, 2012 7:39 pm

Hola maestra espero este muuuuy bien me di a la tarea de buscar información con respecto a la pregunta, ¿Porqué utilizar herramientas CASE en el proceso de desarrollo de software. Qué relación tienen estas herramientas con los modelos de desarrollo? Justifique
Herramienta CASE


Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas 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 costos, 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. Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto 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).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:
• Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
• Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.
• 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.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:
• Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.
• MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.
• CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.
• IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa.
Por funcionalidad podríamos diferenciar algunas como:
• Herramientas de generación semiautomática de código.
• Editores UML.
• Herramientas de Refactorización de código.
• Herramientas de mantenimiento como los sistemas de control de versiones•




Ejemplos de interfaces de herramientas case:



Links para mejorar lo explicado:
https://www.youtube.com/watch?v=lw9TWwqsAgc
https://www.youtube.com/watch?v=vN0tYb5hXUQ

En mi conclusión las herramientas case son muy importantes en el desarrollo de software puesto que facilitan su programación, diseño, análisis, etc. Estas herramientas son fáciles de manipular y están en cambios constantes para hacer su empleo más eficaz y así desarrollar software de calidad.
Después de esta investigación mi pregunta es ¿en realidad una herramienta case hace que nuestro software sea mas confiable?
avatar
Estebaann

Mensajes : 8
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport.1 3.- ¿qué relación existe entre un modelo de desarrollo de software y el concepto de calidad de software?

Mensaje  Fátima Itzel el Jue Nov 29, 2012 7:52 pm

muy buenas noches Maestra
Con respecto a la pregunta 3.- ¿qué relación existe entre un modelo de desarrollo de software y el concepto de calidad de software?
Modelos de desarrollo de software.
Modelos prescriptivos.
Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para el (los) proceso(s) de software que adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán, y el ambiente en el que se ejecutará el trabajo.

El modelo en cascada.
Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra aveces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un software contable debido a los cambios en las regulaciones del gobierno).Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable, El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia [HAN95]. Entre los problemas que algunas veces se encuentran al aplicar la modelo encascada están:


1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa.
2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa. En un análisis interesante de proyectos reales, Bradac [BRA94] concluyó que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal

Modelos de proceso incrementales.
En muchas situaciones los requisitos iniciales del software están bien definidos enf orma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado para producir el software en forma incremental.
El modelo incremental.
El modelo incrementa! combina elementos del modelo en cascada aplicado enforma iterativa. Como se muestra en la figura, el modelo incremental aplica secuenciaslineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial.
Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones
“incompletas del producto final,
pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitiría la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.
El modelo DRA.
El desarrollo rápido de aplicaciones
(DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido


Modelos de desarrollo de software satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer. De manera ideal, el prototipo debería servir como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta emplear los fragmentos del programa ya existentes o aplica herramientas (como generadores de informes, administradores de ventanas, etcétera) que permiten producir programas de trabajo con rapidez. Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito descrito? Brooks [BRO75] ofrece una respuesta:
En la mayoría de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o reúna las tres características a la vez. No existe otra opción que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construir una revisión rediseñada en la que se resuelvan estos problemas... Cuando se aplica un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema in-servible y que sea necesario desechar, porque incluso la mejor planeación no es omnisciente como para que el sistema esté perfecto desde la primera vez. Por lo tanto, la pregunta de la administración no es si debe construirse un sistema piloto y desecharlo. Esto tendrá que hacerse. La única pregunta es si se planea la construcción de un desechable o se promete entregárselo a los clientes.
El prototipo puede servir como "primer sistema", el que Brooks recomienda desechar. Pero ésta tal vez sea una visión idealizada. Es verdad que a los clientes y los desarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos también se torna problemática por las siguientes razones:
1. El cliente ve lo que parece una versión en funcionamiento del software, sin saber que el prototipo está unido "con chicle y cable para embalaje", que por la prisa de hacerlo funcionar no se ha considerado la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa que el producto debe construirse otra vez para mantener los altos niveles de calidad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes” para que se pueda elaborar un producto final a partir del prototipo. Es muy frecuente que la gestión del desarrollo de software sea muy lenta.
2. A menudo, el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo o lenguaje de programación inadecuado sólo porque está disponible y es conocido; se puede implementar un algoritmo ineficiente sólo para mostrar capacidad. Después de un tiempo, el desarrollador quizá se familiarice con estas selecciones y olvide las razones por las que son inapropiadas. La selección menos ideal ahora se convierte en una parte integral del sistema. A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya y sirva como un mecanismo para la definición de requisitos, en que se descarte, al menos en parte, y en que después se desarrolle el software real con un enfoque hacia la calidad.


El modelo en espiral.
El modelo en espiral, que Boehm [BOE88] propuso originalmente, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Proporciona el material para el desarrollo rápido de versiones increméntales del software. Boehm [BOE01] describe este modelo de la siguiente manera:
El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para el crecimiento incrementa! del grado de definición e implementación de un sistema, mientras disminuye su grado de riesgo. La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
Cuando se aplica el modelo en espiral, el software se desarrolla en una serie dé entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas del sistema desarrollado. Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniería del software. Para propósitos ilustrativos sea provechan las actividades genéricas del marco de trabajo expuestas páginas atrás.

Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral que se presenta en la figura. Cuando comienza este proceso evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral que tiene una dirección en el sentido del movimiento de las manecillas del reloj, y que se inicia desde el centro. El riesgo es un factor considerado en cada revolución. Los puntos de fijación Una combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral se consideran para cada paso evolutivo. El primer circuito alrededor de la espiral quizá genere el desarrollo de una especificación del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación derivada de la relación con el cliente después de la entrega. Además, el administrador del proyecto ajusta el número de iteraciones planeado que se requiere para completar el software. A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podría representar un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y continúa por múltiples iteraciones hasta que el desarrollo del concepto esté completo. Si el concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un circuito alrededor de la espiral se podría emplear para representar un "proyecto de mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso está inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto).El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos encada etapa evolutiva. El modelo en espiral emplea la construcción de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma más importante, permite al desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más verídica el mundo real. El modelo en espiral exige una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducirlos riesgos antes de que se vuelvan problemáticos. Así como otros paradigmas, el modelo en espiral no es una panacea. Es difícil convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable, ya que se requiere una habilidad considerable para evaluar el riesgo y se confía en dicha habilidad para obtener el éxito. Si un riesgo importante no se descubre y administra, sin duda surgirán problemas.
El modelo de desarrollo concurrente.
El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se representa en forma esquemática como una serie de actividades del marco de trabajo, acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la actividad de modelado, definida para el modelo en espiral, se lleva a cabo al invocar las acciones siguientes: construcción de prototipos o modelado y especificación del análisis y diseño. En la figura se proporciona un esquema de una tarea de ingeniería de software relacionada con la actividad de modelado para el modelo de proceso concurrente. La actividad Modelado puede estar en alguno de los estados destacados mencionados antes en cualquier momento dado. De forma similar, otras actividades o tareas (por ejemplo, la comunicación y la construcción) se representan de una manera análoga. Todas las actividades existen de forma concurrente, pero se encuentran en diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicación (no se muestra en la figura) ha completado su primera iteración y existe en el estado de en espera de cambios.
La actividad de modelado que existió en el estado ninguno
Mientras se realizaba la comunicación inicial, ahora realiza una transición al estado en desarrollo.
Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado se mueve del estado en desarrollo al estado de en espera de cambios.


CALIDAD DE SOFTWARE
La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
Características propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.


https://www.youtube.com/watch?feature=player_detailpage&v=hZRS6YLv3TY <iframe width="640" height="360" src="https://www.youtube.com/embed/hZRS6YLv3TY?feature=player_detailpage" frameborder="0" allowfullscreen></iframe>

La relación que existe entre modelo de desarrollo y calidad de software es que se llevan distintos procesos para llegar al objetivo deseado.

Fátima Itzel

Mensajes : 7
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Aport. #1 ¿en que fases del ciclo de vida del software se justifica el uso de herramientas CASE, cuál recomendarias y porqué?

Mensaje  Rosario el Jue Nov 29, 2012 11:14 pm

Hola!!! queridos compañeros, que tengan bonito dia.

Con referencia a la pregunta #6, ¿en que fases del ciclo de vida del software se justifica el uso de herramientas CASE, cuál recomendarias y porqué? lo que investigue fue lo siguiente:

Primero se definira que es una herramienta CASE
Nos dice que son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas 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 costos, 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.
Objetivos
Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
Mejorar la planificación de un proyecto
Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
Gestión global en todas las fases de desarrollo de software con una misma herramienta.
Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.

La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.
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.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.
MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.
CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.
IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.
Editores UML.
Herramientas de Refactorización de código.
Herramientas de mantenimiento como los sistemas de control.

CICLO DE VIDA DEL SW
describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
Implementación
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Para mi punto de vista las herramientas CASE se justifican en la fase de analisis y diseño, ya que Permiten al desarrollador crear un modelo
del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la
representación del análisis y ayudan a eliminar errores con anticipación.
• Herramientas de análisis y diseño (Modelamiento).
• Herramientas de creación de prototipos y de simulación.
• Herramientas para el diseño y desarrollo de interfaces.
• Máquinas de análisis y diseño (Modelamiento).

conclucion
Ademas estas fases son las mas adecuadas para este modelo, ya que asi se mejoramiento puede ser mucho mayor. La mayoría de las herramientas Case no han sido construidas utilizando todos los bloques componentes. Muchas de éstas son soluciones puntuales. Una herramienta se utiliza como ayuda en una actividad concreta de ingeniería de software pero no se comunica directamente con otras herramientas, porque no está unida a una base de datos de proyectos.


http://es.wikipedia.org/wiki/Herramienta_CASE[img]
http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3
http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf
avatar
Rosario

Mensajes : 5
Fecha de inscripción : 27/09/2012

Ver perfil de usuario

Volver arriba Ir abajo

Re: PREGUNTAS DETONANTES "MODELOS DE DESARROLLO"

Mensaje  Contenido patrocinado


Contenido patrocinado


Volver arriba Ir abajo

Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.