sábado, 8 de abril de 2017

Modelo Espiral

 El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.



-Comunicación con el cliente: Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

-Planificación: Las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.

-Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de gestión.

-Ingeniería: Las tareas requeridas para construir una o más representaciones de la aplicación.

-Construcción y acción: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica).

-Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

Cada una de las regiones está compuesta por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección (por ejemplo: gestión de configuración del software y garantía de calidad del software).

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajustes en el plan del proyecto.

El coste y la planificación se ajustan con la realimentación ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software.

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos. Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable.

Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. Finalmente, el modelo no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.


jueves, 6 de abril de 2017









Unidad 4:
En esta unidad implementamos un sistema en el desarrollo en el modelo de espiral en la culminación de nuestro proyecto .
Este Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación que en este caso nosotros lo implementaremos en nuestro sistema,
Proveera un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de nuestra organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
nuestros casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.
Cada producto tiene función y forma. Uno sólo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura.
Los desarrolladores basan su selección de qué van a implementar en una iteración en dos factores. Primero, la iteración trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteración trata con los riesgos más importantes.

al desarrollar identificamos y especificamos los casos de uso relevantes, creando el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso. Cuando la iteración cumple sus metas – y usualmente lo hace – el desarrollo continúa con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.







Unidad 2:
 En esta unidad llevamos a cabo la planeación de nuestra aplicación tomando en cuenta los principales puntos a tomar de esta.
Planeación: nos sirve para diseñar un plan a futuro de lo que deseamos hacer, y hasta donde nos proponemos llegar con ello en el largo plazo, para aprovechar al máximo el potencial existente,
Objetivo: El objetivo para este proyecto es realizar una aplicación para el estrés lo cual va a realizar y verificar cual es el nivel de estrés de cada persona.
Meta: La meta de este proyecto sería verificar que cada persona que utilicé la aplicación pueda ver a qué nivel de estrés esta y para ver la manera que pueda controlarlo y no le afecte en su salud.

Recurso:
Para la realización de este proyecto no se va a necesitar de tantos recursos ya que solo es cuestión de que funcione bien el software y realizar algunas encuestas o tés para saber cómo están las personas de hoy en día con el estrés.
Actividades: Las actividades que se van a realizar para esta aplicación son las siguientes se le dará un rol de trabajo a cada integrante para poder realizar la aplicación mas fácil así mismo actividades extras para poder llegar a la meta por cumplir.
Tiempos: Para cada uno de los integrantes del equipo se le va a destinar cierto tiempo para poder realizar su trabajo o actividad y poder entregar todo a tiempo sin complicaciones.
 Roles: implementación, analista, diseñador, tester, programador, mantenimiento.
Y nuestra políticas: Las políticas que se van a tener presente en este proyecto son las siguientes:
o   Dedicación
o   Tiempo
o   Estabilidad

o   Trabajo en equipo




 Unidad 3

En esta unidad lleva a cabo todo el proceso de nuestro proyecto reset-mine”luetenier”
Como primer paso llevamos un proceso de entrevistas y prueba de esto llevamos varios
Modelos a seguir para que fuera eficaz y eficiente ante nuestra población.
Cuestionarios :
Que nos permitirán calcular el nivel de estrés de una manera mas gráfica.
Al igual también implementamos un modelo sobre nuestra escala
De satisfacción refleja la experiencia de los trabajadores que nos permite realizar el primer análisis.
Nuestro siguiente punto fue sobre nuestra corrección de test para obtener puntuaciones diferentes.
Lanzando así el informe de nuestros resultados con una tabla de probabilidad en porcentaje.
Para nuestro proyecto uno de las tantas partes importantes es sobre los requerimientos de nuestro software.

REQUERIMIENTOS FUNCIONALES

u  Es una aplicación portátil para móvil que englobara a toda clase de público.
u  La podrás descargar en tu sistema Android. Esto ayudara que la aplicación este alcance de todos apoyando y teniendo en cuenta la economía.
u  Nuestra aplicación la cual solamente la podrás descargar si cuentas con un sistema operativo .5 sistema Android.

NO FUNCIONALES

u  Único sistema operativo funcional para la aplicación Android .5
u  Deberás contar con Internet

u  Ocupa parte considerable de memoria en el dispositivo
u  Solo es una actividad interactiva para disminuir el estrés
u  No te auto médica.
Nuestros diagramas de casos de usos nos presentara que realizara nuestro administrador y sus funciones a elaborar en cada proyecto ,
El  programador sus utilidades y funciones a llevar a cabo.
Usuario el que requerirá de nuestros servicios y pedidos a sus necesidades de su empresa.