UNIDAD 2: ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
UNIDAD 2:
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
2.1 Relación de la Ingeniería del software con SQA.
La concordancia con los requerimientos funcionales y de
rendimiento explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se espera de todo software se
define como:
Los requerimientos del software son los fundamentos desde
los que se mide la calidad.
La falta de concordancia con los requerimientos es una falta
de calidad.
Los estándares especificados definen un conjunto de
criterios de desarrollo que guía la forma en se aplica la ingeniería del software; si no se
siguen ciertos criterios, casi siempre se dará una falta de calidad.
Existe un conjunto de requerimiento implícitos (el deseo de
buen mantenimiento). Si el software se ajusta a sus requerimientos pero falla en
alcanzar los requerimientos implícitos del software queda en entre dicho.
La calidad del software es una compleja mezcla de ciertos
factores que varían para las diferentes aplicaciones y los clientes que las solicitan.
La garantía de calidad es una actividad esencial en
cualquier empresa que produce productos que van a ser usados por otros. Antes del siglo veinte, la
garantía de calidad era responsabilidad única de la persona que construía el
producto. La primera función de control y de garantía de calidad formal fue introducida por los
laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en
día, cada compañía tiene un mecanismo que asegura la calidad de sus productos de hecho,
durante la pasada década, se han usado ampliamente como tácticas de mercado la
declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las compañías.
La historia de la garantía de calidad en el desarrollo de
software ha sido paralela a la historia en la fabricación de hardware. Durante los primeros años de
información (los 50 y los 60), la calidad era responsabilidad únicamente del programador.
La SQA forma parte de una función más amplia de garantía de
calidad y engloba actividades que desbordan muchas disciplinas técnicas.
El grupo de SQA sirve como representación del cliente dentro
de la casa. O sea, la gente que lleva a cabo la SQA deba mirar el software desde el punto de
vista del cliente ¿satisfacer de forma adecuada el software los factores de calidad?.
La garantía de calidad del software es la guía de preceptos
de gestión y de las disciplinas de diseño de la garantía de calidad para el espacio tecnológico
y la aplicación de la ingenieria de software. La capacidad de garantizar la calidad es la medida
de la madurez de la disciplina de ingenieria . Al finalizar de seguir esa guía antes
mencionada, lo que se obtiene es la madurez de la ingenieria de software. (documents, 2015)
2.2 DEFINICION Y PROPOSITO DEL SQA
La garantía de calidad del software (SQA, Software Quality
Assurance) es una actividad de protección que se aplica a lo largo de todo el
proceso del software.
El aseguramiento de la calidad del software (SQA) por Presman, R.S. (s.f.) “es el conjunto de actividades planificadas y sistemáticas necesarias para aportar
la confianza en que el producto (software) satisfará los
requisitos dados de calidad”.
• Aumenta las posibilidades de éxito del proyecto.
• Ayuda a definir los parámetros de medición de la calidad
del software.
• Verifica que los estándares sean aplicados correctamente.
• Define un plan de monitoreo del proceso de desarrollo del
software (ciclo de vida).
• Reducción de los tiempos de desarrollo, principalmente en
el tiempo de trabajo
2.3 La SQA abarca Problemas que resuelve
Para controlar la calidad del software es necesario, ante
todo, definir los parámetros, indicadores o criterios de medición. Otros autores identifican la calidad con el nivel de
complejidad del software y definen dos categorías de métricas:
•Complejidad de programa o código
•Complejidad de sistema o estructura.
• Disminución del costo de mantenimiento, ya que se generan
aplicaciones más seguras
• Aumento de la permeabilidad al cambio y facilidad para
medir el impacto del mismo
• Asegurar el cumplimiento de los requerimientos
• Promueve el seguimiento de los estándares
• Provee información sobre la calidad del proyecto, los
desarrollos se vuelven más predecibles.
la gestión de calidad, las tecnologías de la ingeniería del software que se pueden aplicar, revisiones
técnicas formales, estrategias de prueba, el control de la documentación del
software y de los cambios realizados, un procedimiento que asegure un
ajuste a los estándares de desarrollo del software y mecanismos de
medición.
2.4 Calidad del software en el ciclo de vida del mismo.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
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.
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.
Ciclo de vida del software
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.
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:
Prueba de unidad: prueba individual de cada subconjunto de
la aplicación para garantizar que se implementaron de acuerdo con las
especificaciones.
Diseño en detalle: definición precisa de cada subconjunto de
la aplicación.
Marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de
un producto de software, abarcando la vida del sistema desde la definición de
los requisitos hasta la finalización de su uso (norma ISO 12207-1) [ISO/IEC, 1995].
Modelo de ciclo de vida
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.
Calidad del software en el ciclo de vida del mismo.
El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final.
Prueba beta (o validación), para garantizar que el software
cumple con las especificaciones originales.
Definición de objetivos: definir el resultado del proyecto y
su papel en la estrategia global.
(2012)
https://prezi.com/w7utaeaanzhy/calidad-del-software-en-el-ciclo-de-vida-del-mismo/
2.5 Roles y responsabilidades de los equipos de desarrollo
Un equipo de desarrollo puede ser una sola persona, o 50,
pero en cualquier equipo existen una serie de roles(funciones), que pueden ser
identificados. En un equipo pequeño, puede que una persona cubra múltiples
roles, mientras que en equipos más grandes, es más común tener funciones
dedicadas.
El Cliente
Se puede pensar que tratar al cliente como parte del equipo
de desarrollo es extraño, pero en realidad, no lo es: El cliente es un factor
importante en el éxito de un proyecto, tanto como cualquier otro miembro del
equipo, por eso es importante contar con la participación activa del cliente
dentro del proyecto.
También es importante entender quién es en realidad “El
Cliente”. Tanto si se desarrolla software para clientes actuales, como si se
desarrolla para uno mismo, o para la propia empresa u organización, siempre hay
un rol de cliente. El cliente, es en esencia, quien pone en marcha el proyecto,
paga las cuentas, o define el resultado final. Aun si no se tiene literalmente
un “cliente”, es bueno entender que aun así existe un rol “cliente” en su
proyecto.
El Analista
El analista es alguien que es responsable de entender las
necesidades del cliente, y asegurarse de que la solución que está siendo
desarrollada se ajusta a esas necesidades.
Las actividades típicas de un analista incluyen la
elicitación de requisitos, reuniones con clientes y la redacción de
especificaciones funcionales.
El Arquitecto de Software
El papel del arquitecto de software es traducir los
requisitos, tal como se define por el analista, en una solución técnica. Él
puede crear un diseño técnico, o simplemente algunos bocetos a mano alzada, de
cómo el sistema va a estar estructurado. En cualquier caso, es la
responsabilidad del arquitecto a pensar en el sistema antes de que se
desarrolle. Si se hace bien, durante la fase de diseño que se abordarán
correctamente todos los problemas que se enfrenten en el desarrollo de la
solución.
El Arquitecto del Sistema
Al igual que el arquitecto de software, el Arquitecto del
Sistema es responsable de pensar el sistema antes de construirlo. Asi como
el arquitecto de software es responsable
para el software, un arquitecto del sistema es responsable del hardware. Muchas
aplicaciones ejecutan completamente en un único servidor. Muchos otros sin
embargo se ejecutan en grupos de servidores, con servidores dedicados de bases
de datos, servidores web y balanceadores de carga. Un arquitecto del sistema
tiene en cuenta los requisitos de rendimiento y disponibilidad, el número de
usuarios / visitantes, etc. y en base a esto, diseña una infraestructura de servidores
y una red.
El Desarrollador de Software
El desarrollo efectivo de una aplicación es hecha por los
desarrolladores del equipo. Pero un desarrollador tiene más responsabilidades
que solo escribir código. Él es a menudo responsable de hacer el seguimiento de
su propio progreso, e informar al jefe de proyecto de los problemas a los que
se enfrenta. Él es también quien implementa las ideas del arquitecto, y como
tal, puede tener que discutir las (in)posibilidades de la implementación con el
arquitecto.
La Documentación de Código tiene como objetivo el explicar a
otros desarrolladores aquellas cosas que no resulten evidentes o claras a
partir de la lectura del propio código en sí. Se debe dar una idea de por qué
un fragmento de código es de la manera que es. El desarrollador es el único que
conoce los pensamientos e ideas detrás del código que escribe, lo cual lo
convierte en el candidato perfecto para documentarlo.
El Jefe de Desarrolladores
Un desarrollador líder, que tiene las mismas
responsabilidades que los otros desarrolladores, pero también tiene añadidas
algunas más. Un desarrollador líder debe entrenar a los otros desarrolladores,
y ayudarles a resolver los problemas que puedan enfrentar. Este desarrollador,
que suele ser el miembro del equipo más experimentado, también será capaz de
asegurarse de que la ejecución sigue de cerca al diseño planteado, y no se dé
lugar a lo que se denomina “invasión de características” durante el desarrollo.
El desarrollador líder tiene una gran influencia en la calidad del código.
El Diseñador Gráfico
“Lo de dentro es lo que cuenta.”, es tan cierto, como que
también la percepción de los usuarios depende mucho de la mirada y la sensación
que le produce una aplicación o sitio web. No importa lo buena que la aplicación
sea, si la interfaz es inconsistente, se sentirá menos robusto. Incluso si el
diseño está determinado por los desarrolladores, es una responsabilidad
importante crear un diseño consistente en toda la aplicación.
El Tester
Las pruebas son una parte importante para asegurar que el
software funciona de la manera que debería. El papel de ‘tester’ se realiza a
menudo por los desarrolladores para los aspectos técnicos y los usuarios para
los aspectos funcionales. Un problema que surge de hacer a los desarrolladores
probar su propio código es que, no importa lo bueno que sean, se ven influidos
por la forma de su código fue creado. Si se prueba código de otra persona, se
puede pensar en escenarios que la otra persona no los pensó. Así que incluso si
no se tiene un equipo de Testers dedicado, es una buena idea que cada
desarrollador pruebe código de otro desarrollador, en lugar del suyo propio.
El Gerente del Proyecto
Un gerente de proyecto tiene muchas responsabilidades. Es
responsable de la planificación del proyecto, de mantener el proyecto dentro
del presupuesto, y de la solución de problemas. Muchas de las tareas del
gerente del proyecto tienen que ver con la comunicación, la comunicación al
cliente sobre el progreso del proyecto y la comunicación con todos los miembros
del equipo. Incluso en los proyectos de desarrollo que no cuentan con un
gerente de proyecto, es conveniente asignar el rol de gerente de proyecto a
alguien, para que quede claro quién es responsable de la ejecución del mismo.
El Administrador de Cuentas
Si usted desarrolla proyectos para clientes, sus proyectos
pueden beneficiarse de las funciones de un Administrador de Cuentas. Un
administrador de cuentas cultiva la relación con el cliente. Aunque la gestión
de proyectos y administración de cuentas se hace a menudo por la mismo persona
dentro de un proyecto, hay situaciones en las que ayuda a dividir estos roles.
Un administrador de cuentas puede mantener una relación más independiente con
el cliente, y avisar si el cliente no está contento con la forma en que se
ejecuta el proyecto por parte del gerente del proyecto.
El Administrador de sistemas
El sistema en que la aplicación será instalada es creado por
un administrador del sistemas.
Se arman los servidores, se instala el sistema operativo, un
servidor web, PHP, una base de datos y cualquier software adicional que se
requiera.
El Administrador de Código
El Código es importante y debe ser tratado como tal, el
código necesita ser gestionado. Si varios de los desarrolladores están
trabajando en conjunto, el código que escriben deben integrarse en algún
momento, independientemente del sistema de control de versiones utilizado.
El Capacitador
Cuando un proyecto se haya completado, los usuarios pueden
necesitar ser capacitados, en particular si en el proyecto se desarrollado una
aplicación. El Capacitador relaciona las soluciones que se han creado con el
usuario final. Una importante responsabilidad del Capacitador es explicar cómo
la aplicación resuelve el problema del cliente y, como tal, juega un papel
importante en asegurar que las expectativas del cliente sobre el software están
en línea con lo que ha sido creado.
2.6 Habilidades y capacidades del personal SQA
Es responsable de asegurar la calidad de los productos
generados en el proyecto y del proceso utilizado. Para asegurar la calidad debe
revisar la calidad de los entregables de planificación del proyecto y los
entregables de valoración del proyecto. Además revisa el nivel de apego al
modelo de proceso de desarrollo de software y a los planes de Verificación,
Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones
encontradas.
Debe conocer los conceptos y técnicas de Gestión de Calidad
del Software. Debe identificar las propiedades de calidad que deben cumplir los
productos del proyecto.
Centralizar y revisar las entregas que se realizan durante
el ciclo de vida del proyecto. Realiza las Revisiones Técnicas Formales con los
responsables de los productos a revisar.
El Responsable de SQA debe:
- Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo.
- Asegurarse de que se realicen estudios de factibilidad
- Realizar mediciones para comprobar la calidad del proyecto
- Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos
- Evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto
- Registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el Cliente.
https://itpnli.es.tl/Calidad-Unidad-2.html
2.7 Actividades del SQA
Para poder lograr una buena adherencia con los estándares se
debe medir cuantitativamente, donde sea posible, los aspectos de calidad (por
ejemplo complejidad, confiabilidad, mantenimiento, seguridad, defectos, número
de problemas) utilizando métricas bien establecidas. Para cumplir con esto, se
deben realizar chequeos de:
- Administración.
- Documentación.
- Estándares, prácticas, convenciones y métricas.
- Revisiones e intervenciones.
- Actividades de testeo.
- Reporte de errores y acciones correctivas.
- Herramientas, técnicas y métodos.
- Control del código
- Control de medios.
- Colección de registros, mantenimiento y retención.
- Control de los proveedores
- Entrenamiento.
- Administración del riesgo.
2.8 Métodos y herramientas
Entrevistas y Cuestionarios.
Las entrevistas y cuestionarios se emplean para reunir
información proveniente de personas o de grupos. Durante la entrevista, el
analista conversa con el encuestado; el cuestionario consiste en una serie de
preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas
existentes o usuarios en potencia del sistema propuesto. En algunos casos, son
gerentes o empleados que proporcionan datos para el sistema propuesto o que
serán afectados por él.
Las preguntas que deben realizarse en esta técnica, deben
ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del
proyecto para obtener información sobre aspectos globales del problema del
usuario y soluciones potenciales.
Con frecuencia, se utilizan preguntas abiertas para
descubrir sentimientos, opiniones y experiencias generales, o para explorar un
proceso o problema. Este tipo de preguntas son siempre apropiadas, además que
ayudan a entender la perspectiva del afectado y no están influenciadas por el
conocimiento de la solución.
Las preguntas pueden ser enfocadas a un elemento del
sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra
algunos tipos de preguntas abiertas.
Del Usuario
· ¿Quién es el
cliente?
· ¿Quién es el
usuario?
· ¿Son sus
necesidades diferentes?
· ¿Cuáles son sus
habilidades, capacidades, ambiente?
Del Proceso
· ¿Cuál es la
razón por la que se quiere resolver este problema?
· ¿Cuál es el
valor de una solución exitosa?
· ¿Cómo usted
resuelve el problema actualmente?
· ¿Qué retrasos
ocurren o pueden ocurrir?
Del Producto
· ¿Qué problemas
podría causar este producto en el negocio?
· ¿En qué
ambiente se usará el producto?
· ¿Cuáles son sus
expectativas para los conceptos fácil de usar, confiable, rendimiento?
· ¿Qué obstáculos
afectan la eficiencia del sistema?
El éxito de esta técnica combinada, depende de la habilidad
del entrevistador y de su preparación para la misma. Los analistas necesitan
ser sensibles las dificultades que algunos entrevistados crean durante la
entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan
considerar no sólo la información que adquieren a través del cuestionario y la
entrevista, sino también, su significancia.
Lluvia de Ideas (Brainstorm)
Este método comenzó en el ámbito de las empresas,
aplicándose a temas tan variados como la productividad, la necesidad de
encontrar nuevas ideas y soluciones para los productos del mercado, encontrar
nuevos métodos que desarrollen el pensamientocreativo a todos los niveles, etc.
Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de
sistemas; básicamente se busca que los involucrados en un proyecto desarrollen
su creatividad, promoviendo la introducción de los principios creáticos.
Prototipos
Los prototipos permiten al desarrollador crear un modelo del
software que debe ser construido.
Al igual que todos los enfoques al proceso de desarrollo del
software, el prototipado comienza con la captura de requerimientos.
Desarrolladores y clientes se reúnen y definen los objetivos globales del
software, identifican todos los requerimientos que son conocidos, y señalan
áreas en las que será necesaria la profundización en las definiciones. Luego de
esto, tiene lugar un "diseñorápido". El diseño rápido se centra en
una representación de aquellos aspectos del software que serán visibles al
usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido
lleva a la construcción de un prototipo. El prototipo es evaluado por el
cliente y el usuario y utilizado para refinar los requerimientos del software a
ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo
es "puesto a punto" para satisfacer las necesidades del cliente y
permitiendo al mismo tiempo una mejor comprensión del problema por parte del
desarrollador.
Existen principalmente dos tipos de prototipos:
Prototipo rápido (o concept prototipe): El prototipado
rápido es un mecanismo para lograr la validación pre-compromiso. Se utiliza
para validar requerimientos en una etapa previa al diseño específico. En este
sentido, el prototipo puede ser visto como una aceptación tácita de que los
requerimientos no son totalmente conocidos o entendidos antes del diseño y la
implementación. El prototipo rápido puede ser usado como un medio para explorar
nuevos requerimientos y así ayudar a "controlar" su constante
evolución.
Prototipo evolutivo: Desde una perspectiva diferente, todo
el ciclo de vida de un producto puede ser visto como una serie incremental de
detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida está
dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha
demostrado que esta distinción es arbitraria y va en contra de la realidad ya
que la mayor parte del costodel software ocurre después de que el producto se
ha entregado. El punto de vista evolutivo del ciclo de vida del software
considera a la primera entrega como un prototipo inicial en el campo.
Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos
más maduros.
Entrevista
Es tal vez la forma más productiva de obtener información,
si el analista cuenta con la confianza del entrevistado. Debe entrevistarse a
todo el personal que se considere conveniente, independientemente del nivel
jerárquico del puesto que desempeñen.
Elementos que forman la calidad del Software:
· Metodologías
· Medidas
· Personas
· Herramientas y
técnicas
Metodologías
*RUP: Diseñada para entornos dinámicos y equipo pequeño.
*XP
-Comunicación verbal
-Diseño
-Entregas pequeñas
-Uso de estándares
-Cliente implicado
· Se centran en
el equipo de desarrollo y sus interacciones
· Buscan un
Software funcional
· Una estrecha
colaboración con el cliente
· Responder a
cambios aunque implique cambiar el plan
(2 de octubre de 2012). Obtenido de
https://prezi.com/w7utaeaanzhy/calidad-del-software-en-el-ciclo-de-vida-del-mismo/
documents. (26 de junio de 2015). Obtenido de documents:
https://vdocuments.mx/21-relacion-de-la-ingenieria-del-software-con-sqa.html
https://prezi.com/u-hjtqgmps7f/definicion-y-proposito-sqa-problemas-que-resuleve-sqa/.
(3 de octubre de 2012). prezi. Obtenido de prezi.
prezi. (s.f.). Obtenido de prezi:
https://itpnli.es.tl/Calidad-Unidad-2.htm
Comentarios
Publicar un comentario