Calidad de software

Es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia, la cual plantea un adecuado balanceo de eficiencia, confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso, seguridad e integridad.

MODELO DE CALIDAD BOEHM

Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo. 

El modelo Boehm o desarrollo en espiral, propuesto originalmente por Barry Boehm en 1986, es un modelo de siglo de vida de software utilizado generalmente en la ingeniería de software. Las actividades de este modelo se conforman en un espiral en que cada bucle o interacción representa un conjunto de actividades

No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de proyecto Cada vuelta se divide en 4 sectores:

· Planeación: determinación de los objetivos, alternativas y restricciones

· Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos

 · Ingeniería: desarrollo del producto hasta "el siguiente nivel".

· Evaluación: valoración por parte del cliente de los resultados obtenidos.

 El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas. Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software.

Modelo Típico De Seis Regiones

A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto. Las regiones de tareas que componen este modelo son:

· 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 otras informaciones relacionadas con el proyecto. Son todos los requerimientos.

· Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.

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

· Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

 · 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 implementación durante la etapa de instalación.

Ventajas

· El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software.

· 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 nivele evolutivos.

· El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

· 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 problemas.

· En la utilización de grandes sistemas ha doblado la productividad.

Desventajas

· Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

· Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

· Genera mucho tiempo en el desarrollo del sistema.

· Modelo costoso.

· Requiere experiencia en la identificación de riesgos.

BIBLIOGRAFIA

https://prezi.com/wdiqmdaq4s4b/modelo-boehm/

https://es.slideshare.net/jhonsjc1/modelo-espiral-de-boehm

CARTILLA CALIDAD DESARROLLO DE SOFTWARE.