Operaciones del producto
- Corrección: El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente.
- Fiabilidad: El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida.
- Eficiencia: La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados.
- Integridad: El grado con que puede controlarse el acceso al software o a los datos a personal no autorizado
- Facilidad de uso: El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados.
Revisión del producto
- Facilidad de mantenimiento: Es el esfuerzo requerido para localizar y reparar errores.
- Flexibilidad: Esfuerzo requerido para modificar una aplicación en funcionamiento.
- Facilidad de prueba: El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos.
Transición del producto
- Portabilidad: El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo.
- Reusabilidad: Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones.
- Interoperabilidad: Esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos.
También podemos ver algunos ejemplos y tipos de factor de los anteriores:
Reusabilidad – Tipo de factor:
La reusabilidad es un factor de tipo externo, ya que es perceptible por los usuarios o clientes.
Ejemplo:
Ejemplo:
- Al momento de utilizar partes de un software en otro diferente.
- Un ejemplo de la reusabilidad son las librerías.
- Las librerías son módulos de códigos o un conjunto de subprogramas que son utilizados para el desarrollo de software.
- por ejemplo la librería java.awt permite disponer de una cantidad de códigos reutilizables a la hora de crear interfaces gráficas y todos sus componentes dentro de la creación de un proyecto de software.
Métrica:
Está dentro del contexto de las métricas de calidad. Definen de una u otra forma la calidad del software; tales como exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad, entre otras. Estas son los puntos críticos en el diseño, codificación, pruebas y mantenimiento.
Legibilidad – Tipo de factor:
- La legibilidad es un factor de tipo interno, ya que solo es perceptible por los desarrolladores o los profesionales de la computación.
- al cliente no le importa que el sistema por debajo esté legible, solo le importa que funcione óptimamente.
Métrica: Legibilidad está dentro del contexto de las métricas de Calidad.
Seguridad – Tipo de factor:
Es un factor de tipo tanto externo como interno, ya que los desarrolladores deben tener en cuenta la seguridad del software al momento de desarrollarlo, pero es a los clientes.
Ejemplo:
Son las validaciones que existen para la verificación de datos en el desarrollo de un software, tal como la validación de los nombres de usuario y contraseña en el ingreso al sistema, los captcha, tipos de datos, etc.
Métrica: La seguridad está dentro del contexto de las métricas de calidad.
Tema - 4.8 Análisis del proceso del ciclo de vida del software
Un modelo de ciclo de vida
define el estado de las fases a través de las cuales se mueve un proyecto de
desarrollo de software.
Definición
de un Modelo de Ciclo de Vida
Es una vista de las actividades que ocurren durante el desarrollo
de software, intenta determinar el orden de las etapas involucradas y los
criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida
del software:
- Describe las fases principales de desarrollo
de software.
- Define las fases primarias esperadas de ser
ejecutadas durante esas fases.
- Ayuda a administrar el progreso del
desarrollo
- Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software
Alternativas
de Modelos de Ciclo de Vida
Modelo
Cascada
Sirve como bloque de construcción para los demás modelos
de ciclo de vida. La visión del modelo cascada del desarrollo de software es
muy simple; dice que el desarrollo de software puede ser a través de una
secuencia simple de fases.
Cada fase tiene un conjunto de metas bien definidas,
y las actividades dentro de una fase contribuye a la satisfacción de metas de
esa fase o quizás a una subsecuencia de metas de la fase.
Las flechas muestran
el flujo de información entre las fases. La flecha de avance muestra el flujo
normal. Las flechas hacia atrás representan la retroalimentación.
El modelo de ciclo de vida
cascada, captura algunos principios básicos:
- Planear un proyecto antes de embarcarse en
él.
- Definir el comportamiento externo deseado del
sistema antes de diseñar su arquitectura interna.
- Documentar los resultados de cada actividad.
- Diseñar un sistema antes de codificarlo.
- Testear un sistema después de construirlo.
Modelo
De Desarrollo Incremental
Los riesgos asociados con
el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir
los riesgos es construir sólo una parte del sistema, reservando otros aspectos
para niveles posteriores.
El desarrollo incremental es el proceso de construcción
siempre incrementando subconjuntos de requerimientos del sistema.
El desarrollo incremental
no demanda una forma específica de observar el desarrollo de algún otro
incremento. Así, el modelo cascada puede ser usado para administrar cada
esfuerzo de desarrollo.
El modelo de desarrollo
incremental provee algunos beneficios significativos para los proyectos:
- Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
- Al ir desarrollando parte de las
funcionalidades, es más fácil determinar si los requerimientos planeados para
los niveles subsiguientes son correctos.
- Si un error importante es realizado, sólo la
última iteración necesita ser descartada.
- Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
- Si un error importante es realizado, el incremento previo puede ser usado.
- Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
Modelo
De Desarrollo Evolutivo
El modelo de desarrollo evolutivo (algunas veces
denominado como prototipado evolutivo) construye una serie de grandes versiones
sucesivas de un producto.
En el modelo evolutivo,
los requerimientos son cuidadosamente examinados, y sólo esos que son bien
comprendidos son seleccionados para el primer incremento. Los desarrolladores
construyen una implementación parcial del sistema que recibe sólo estos
requerimientos.
El sistema es entonces
desarrollado, los usuarios lo usan, y proveen retroalimentación a los
desarrolladores. Basada en esta retroalimentación, la especificación de
requerimientos es actualizada, y una segunda versión del producto es
desarrollada y desplegada. El proceso se repite indefinidamente.
El desarrollo evolutivo no
demanda una forma específica de observar el desarrollo de algún incremento.
El desarrollo de software
en forma evolutiva requiere un especial cuidado en la manipulación de
documentos, programas, datos de test, etc. desarrollados para distintas
versiones del software.
Modelo
Espiral
El modelo espiral de los
procesos software es un modelo del ciclo de meta-vida. En este modelo,
el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un
esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado,
puedes seguir estos cuatros pasos:
- Determinar qué quieres lograr.
- Determinar las rutas alternativas que puedes tomar para lograr estas metas.
- Seguir la alternativa seleccionada en el paso 2.
- Establecer qué tienes terminado.
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.
El modelo espiral no es
una alternativa del modelo cascada, ellos son completamente compatible.
Modelo
Concurrente
Provee una meta-descripción del proceso software. Mientras
que la contribución primaria del modelo espiral es en realidad que esas
actividades del software ocurran repetidamente, la contribución del modelo
concurrente es su capacidad de describir las múltiples actividades del software
ocurriendo simultáneamente.
Durante el diseño de
arquitectura, es posible que algunos componentes comiencen a ser bien definidos
antes que la arquitectura completa sea estabilizada. En tales casos, puede ser
posible comenzar el diseño detallado en esos componentes estables.
Similarmente, durante el diseño detallado, puede ser posible proceder con la
codificación y quizás regular testeando en forma unitaria o realizando testeo
de integración previo a llevar a cabo el diseño detallado de todos los
componentes.
En algunos proyectos,
múltiples etapas de un producto se han desarrollado concurrentemente. Por
ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto,
y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que
se está haciendo codificación sobre un componente 3, mientras se realiza diseño
sobre una etapa 4, y especificación de requisitos sobre un componente 5.
Referencia bibliográfica:
http://www.comusoft.com/factores-de-calidad-del-software-seguridad-legibilidad-y-reusabilidad
https://www.ecured.cu/Software_Educativo
https://www.itescam.edu.mx/portal/asignatura.php?clave_asig=IFB-0407&carrera=LINF-2004-303&id_d=128
No hay comentarios:
Publicar un comentario