You are on page 1of 13

UNIVERSIDAD DE OTAVALO

TEMA: DISEÑO DE UN PLAN DE ASEGURAMIENTO DE LA CALIDAD PARA LA


EMPRESA DE SOPORTE INFORMATICO INTERNET.COM

ALUMNO: JIMMY MAURICIO IMBA PUJOTA

DOCENTE: ING. JUAN CARLOS ARMAS

OTAVALO, FEBRERO DE 2019


Introducción

Los recursos informáticos se han convertido en un requisito indispensable en la industria


de los negocios. Facilitan completar tareas que son tediosas y para los seres humanos.
Las empresas que utilizan computadoras en la actualidad son prácticamente todas.
Aunque muchas de las funciones no son insustituibles, las empresas se han convertido
en dependientes de su precisión y la puntualidad, para el manejo de la información,
manejo de sus procesos, administración de recursos, en general para todas las tareas
que la empresa desarrolla, debido a esto se establecen los negocios que brindan soporte
en el área de informática, para que el usuario o empresa puedan estar tranquilos sobre
el hecho de que van a tener soporte oportuno en el momento del incidente

Propósito

El propósito del presente plan es definir la organización, actividades y responsabilidades


asociadas al proceso de SQA durante todo el ciclo de vida del proyecto. Además,
entregar guías para la ejecución de las actividades de SQA, definir los estándares, los
procedimientos y las convenciones que serán utilizados durante estas actividades y
establecer las herramientas, técnicas y metodologías que soportarán las prácticas de
SQA.
Alcance
El presente documento establece, de acuerdo a la política organizacional, las actividades de
SQA que deberán ser ejecutadas durante el ciclo de vida del proyecto definido para la aplicación.
El ciclo de vida comprende las etapas de Planificación, Especificación de Requerimientos,
Análisis, Diseño, Implementación, Instalación (aceptación y entrega), y Operación (Mantención).

El objetivo del Plan de Calidad es comunicar el ámbito, recursos, y herramientas a los gestores
del software y personal técnico, además de entregar a la administración una visibilidad
adecuada del proceso utilizado y los productos construidos durante el proyecto mediante
acciones planificadas y sistemáticas que aseguren la calidad de los procesos y productos.
Identificación de productos de trabajo
A continuación, se nombran los productos de trabajos que soportan la construcción del sistema.

Producto de Trabajo Descripción

Plan de Proyecto Documentación para controlar y monitorear el Proyecto (Ver anexo


Plan de Proyecto).

Plan de Riesgos Documentación sobre las posibles situaciones en las que el


Proyecto puede verse afectado (ver página 36)

Especificación de Requerimientos Repositorio central que contiene la información actualizada de cada


uno de los requerimientos detectados.

Descripción de los requerimientos del cliente que deben ser


satisfechos por el equipo de desarrollo (ver anexo Especificación de
Requerimientos)

Especificación del sistema (Solución Propuesta) Documentación sobre la situación actual, sus problemas y las
mejoras que introduce el desarrollo de la solución que se propone
(ver anexo Especificación del Sistema).

Especificación Funcional Documentación que especifica en términos no técnicos, que es lo


que la solución hace que se propone (ver anexo Especificación
Funcional).

Plan de pruebas Documentación que describe las pruebas que serán llevadas a cabo
para demostrar al cliente que la solución satisface los
requerimientos definidos. (ver anexo Plan de Pruebas).

Especificación de Diseño de Sistema Documentación que define la Arquitectura de la Solución e


identifica todos los componentes del sistema. (ver anexo
Especificación de Diseño de Sistema).

Especificación de Diseño de Soporte Documentación detallada de los requerimientos de soporte desde


la fase de Implementación a la de Operación (ver anexo
Especificación de Diseño de Soporte).

Plan de aseguramiento de calidad SQA Documentación que define todas las actividades de aseguramiento
de calidad que se harán durante el Proyecto.

Plan de gestión de la configuración SCM Documentación que describe la metodología que se seguirá para
realizar la gestión de la configuración en el proceso de desarrollo de
software, formularios y checklist (ver anexo Plan de gestión de la
configuración SCM).

Informe de pruebas (testing) Documentación que describe los resultados de las pruebas, los
cuales ayudarán a comprobar el “buen” funcionamiento del
software.

Manual de usuario Documentación que describe el comportamiento del sistema desde


el punto de vista funcional de la aplicación.

Manual de instalación del sistema Documentación de la especificación de los componentes de


instalación y la forma en que se debe realizar esta tarea.

Avances de la Aplicación Subproductos que evaluará el cliente.

Diseño de imágenes y escenarios Elementos gráficos que forman parte de la aplicación


Descripción de la situación actual
La tendencia desde hace un par de años es que en los colegios y en las familias existan
computadores, sin nombrar las empresas, que si no disponen del recurso informático están
limitando su crecimiento, estancándose en su estado actual y con mucho riesgo de ser
absorbidas por otras empresas.

La mayoría de estos computadores, funcionan principalmente con el sistema operativo


Windows, y aplicaciones de software basadas en el mismo, debido en gran parte al
posicionamiento de éste en el mercado y al desconocimiento de otras plataformas de software

El usuario no-técnico, en la mayoría de los casos no dispone de tiempo para leer, ni tampoco
tiene interés por los manuales tradicionales que le explican cómo y que se debe hacer para
realizar una determinada tarea. El usuario final necesita que todo se resuelva con la menor
complejidad posible.

Actividades del proceso de desarrollo

 Planificación

Planificación / definición de recursos, tiempo y otras informaciones relacionadas con el proyecto


según la evaluación del cliente poniendo énfasis en lo que se debe modificar y lo que se debe
mantener.

Durante la etapa de planificación, SQA debe participar de la elaboración del Plan de Proyecto.
Es su responsabilidad producir el Plan de SQA y verificar que los procesos, procedimientos y
estándares identificados en el Plan de Proyecto sean apropiados, claros, específicos y
auditables.

El contenido del Plan de SQA debe identificar: evaluaciones, auditorías y revisiones, estándares,
procedimientos de seguimiento y reporte de errores, y documentación por producir.

 Especificación de requerimientos (Definición)

Esta fase comienza cuando se han identificado los problemas o necesidades de negocios, cuya
solución requiere un análisis y especificación. En esta etapa el equipo de proyecto debe
entender al cliente en términos de sus problemas y dirección, sus capacidades técnicas y de
organización y su potencial futuro. Para esto hay que analizar:
 Las metas de la organización, sus objetivos y factores críticos de éxito.
 Los procesos de negocios y flujos de información actuales.
 Requerimientos de solución, en términos de procesos y principios de negocios, estructura
organizacional y arquitectura tecnológica.
 Beneficios de la solución e impacto en la organización, recursos humanos y ambiente
tecnológico.

En esta etapa no se debe pensar en posibles soluciones, sino solamente en el problema, es decir,
se de describir el problema en forma de requerimientos.

SQA debe corroborar que en la Especificación estén expresados todos los requerimientos, de
manera tal que puedan ser verificados en el producto final.

 Análisis

Durante esta fase se analiza la Especificación de Requerimientos con el objetivo de identificar


las soluciones que satisfagan los requerimientos, se analizan diferentes alternativas de solución
y se selecciona solo una, y se genera el informe de Solución Propuesta.

En la fase de Análisis, dentro de las actividades de SQA se incluye asegurar:

 La adherencia del Análisis y su documentación a los estándares definidos en el Plan de


Proyecto.
 La incorporación de los resultados de las inspecciones en el Análisis.

 DISEÑO

Esta etapa se centra en el "cómo", en la forma cómo debe construirse el sistema de software de
acuerdo a la información obtenida de la etapa de análisis. En esta etapa se define como deberá
implementarse el sistema de software. Los modelos creados en la fase de análisis determinan
claramente cuál debe ser el comportamiento general del sistema en un entorno ideal. Los
modelos a crear en la fase de diseño determinan, ya sobre el entorno propio de la organización,
cómo deberá implementarse el sistema. Por otra parte, en esta fase el Equipo de Proyecto define
la funcionalidad y solución física que va a satisfacer los requerimientos definidos.

En la fase de diseño, dentro de las actividades de SQA se incluye asegurar:


 La adherencia del diseño y su documentación a los estándares definidos en el Plan del
Proyecto.
 La presencia de todo módulo en el diseño.
 La incorporación de los resultados de las inspecciones en el diseño.
 El ingreso del diseño a la configuración del software, tras su aprobación.

 Implementación

La implementación se establece como la "construcción" del sistema. La actividad sólo lleva a la


práctica el sistema que se modeló en la fase de diseño. La fase incluye las actividades de
codificación e integración de los diferentes módulos constitutivos del sistema. En la fase de
implementación, cada componente de la solución, identificado en la Especificación de Diseño
de Sistema, se diseña en detalle (si corresponde), se construye, se ensambla, se prueba y se
integra con otros componentes relacionados. Los componentes se prueban como un todo.

Los posibles componentes son:

 Productos estándares disponibles y componentes construidos para el cliente.


 Componentes construidos solo para el cliente.
 Componentes derivados de prototipos, usados preliminarmente para verificar todo o parte
del diseño y, en algunos casos, para llegar a ser parte de la solución.

Los componentes individuales son distribuidos por varias disciplinas y terceras partes. Es
esencial que el Equipo aplique los principios de control de cambios, administración de la
configuración y reportes. Esta fase involucra a muchas personas trabajando simultáneamente,
pero con independencia en tareas complejas. Por lo tanto, es muy importante que los planes
para apoyar esta fase sean conocidos y los roles y responsabilidades estén claramente definidas.

El software generado en la fase de implementación no puede ser “entregado” a los clientes, para
que funcione, sin practicarle antes una serie de pruebas. Las pruebas son tendientes a encontrar
defectos en el sistema final debidos a omisión o mal interpretación de alguna parte del análisis
o el diseño.

Los defectos deberán entonces detectarse y corregirse en esta fase del proyecto. En ocasiones los
defectos pueden deberse a errores en la implementación de código (errores propios del lenguaje o
sistema de implementación), aunque en esta etapa es posible realizar una efectiva detección de los
mismos, ellos deben ser detectados y corregidos en la fase de implementación.

A SQA le corresponde auditar:

 Los resultados de las actividades de diseño y codificación.


 El estado de todos los entregables.
 Las actividades de gestión de configuración y de la biblioteca del software.
 Los informes sobre desviaciones y las acciones correctivas.
 Garantizar la concordancia de las pruebas con el Plan y los procedimientos definidos, así
como también toda desviación sea informada y corregida.
 Certificar que las actividades de prueba se han completado satisfactoriamente y que el
software y su documentación se encuentran listos para la entrega del producto final.

 Instalación (Aceptación y Entrega)

Aceptación (negativa o positiva) de las representaciones de la aplicación por parte del


cliente. Durante la fase de instalación, todas las componentes de la solución se
distribuyen al cliente y se instalan. La solución se prueba como un todo en un ambiente
operacional hasta que esté lista para la prueba de aceptación formal por parte del
cliente.
La Prueba de Aceptación quiere demostrar al cliente que la solución cumple los
requerimientos de la Especificación Funcional. El cliente confirma por escrito que todas
las pruebas han sido exitosas y que acepta la solución.
La salida de esta fase es transferir la propiedad de la solución a la organización cliente.
En la fase de aceptación, SQA es responsable de realizar la última auditoria de
configuración del software, con el objetivo de determinar que los deliberables están
listos para la entrega.

 Operación (Mantención)

Esta es la fase post-aceptación del proyecto, durante la cual se mantiene y soporta la


solución según lo acordado entre las partes.
En esta fase el software es puesto en funcionamiento con los usuarios y el entorno de la
organización. Es común que estas etapas requieran de trabajo adicional del equipo de
desarrolladores, especialmente en procesos de configuración adecuada, utilidades
menores de copias de respaldo, administración de seguridad o reportes adicionales. Esta
es la fase post-aceptación del proyecto, durante la cual se mantiene y soporta la solución
según lo acordado entre las partes.
Se hace una revisión para registrar datos estadísticos y discutir sobre áreas de
experiencia que puedan ser útiles para otros proyectos en el futuro.
El contenido del proyecto se archiva y se considera el proyecto terminado.
Después del período de garantía, se puede continuar con la mantención de la solución.
En la fase de Operación, SQA es responsable de asegurar que los requerimientos de
calidad se han cumplido y que las actividades de aseguramiento de calidad se han
realizado.
Durante la operación pueden presentarse correcciones o mejoras que originen
pequeños “ciclos de desarrollo”. En tal caso, se repetirán las actividades de SQA
descritas con anterioridad.

Productos de trabajo

A continuación, se definen los productos de trabajo que deberían entregarse dentro del
desarrollo del proyecto:

 Plan de Proyecto

Para contar con una forma de monitorear y controlar lo que se está llevando a cabo
dentro del desarrollo del proyecto. El Plan de Proyecto proporciona un repositorio
central que contiene la información de planificación e implementación requerida para
ejecutar el plan de proyecto entero. Provee un resumen y una integración de todos los
planes contenidos en el proyecto y de todos los proyectos contenidos en el programa.
Posibilita el monitoreo del progreso del proyecto de manera consistente con el plan.

El Plan de Proyecto inicial refleja la información que está disponible en la fase de análisis.
Al tener información más detallada, según avanza el proyecto, el plan de proyecto es
actualizado de acuerdo con esto. La cobertura del Plan de Proyecto es el proyecto
completo, pero en cualquier punto del tiempo, normalmente contendrá actividades
detalladas solamente para la fase actual y la fase siguiente [MA-02] (ver anexo Plan de
Proyecto).

 Plan de Riesgos

El Plan de Riesgos establece las posibles situaciones en las que el proyecto podría verse
afectado. Para ello, se realiza un Análisis de Riesgos, a través de la cual se establecerán
las acciones a tomar en caso que se concreten dichas situaciones. Básicamente, el Plan
de Riesgos debe contemplar la: definición de los riesgos, la posibilidad de que se
concrete cada uno de los riesgos detectados, definir que tan grande sería el impacto de
cada riesgo identificado en el proyecto, definir e indicar cuales son los eventos
indicadores de que el riesgo se ha concretado, y definir el plan de contingencia para cada
uno de ellos

 Especificación de Requerimientos

La Especificación de Requerimientos proporciona un repositorio central que contiene la


información actualizada de cada uno de los requerimientos detectados, como el número
secuencial que identifica en forma única al requerimiento, tipo de requerimiento,
identificación de requerimiento original (cuando es reclasificado), estado del
requerimiento, persona que lo planteó, categoría del requerimiento, nombre del
requerimiento, fecha en que se da por aprobado el requerimiento por parte del cliente,
nombre de la persona que da por aprobado el requerimiento. Todo esto, permitirá una
administración correcta de los requerimientos del proyecto [MA-02].
Por otra parte, la Especificación de Requerimientos refleja las necesidades de negocio,
los requerimientos necesarios para resolver aquellas necesidades, y objetivos del cliente
que buscan una solución. Este es el primer documento que se genera en un proyecto y
debe ser conciso, claro y completo; de modo tal que sea la base para las siguientes
etapas. Por otro lado, debe ser escrito en un lenguaje de alto nivel, en términos del
negocio. Debiera ser capaz de ser producido en un tiempo limitado, y no debería
contener detalles específicos a menos que sean considerados requisitos para el negocio.
La Especificación de Requerimientos forma la base para el desarrollo de la Solución
Propuesta, pero al mismo tiempo difieren, pues ésta refleja las necesidades y objetivos
de negocio traducidos en requerimientos para una solución. La Solución Propuesta
detalla eespecificaciones para una solución específica seleccionada a partir de un
número de alternativas posibles

 Especificación del Sistema (Solución Propuesta)

Mostrando como es la situación actual, sus problemas y las mejoras que introduce el
desarrollo de la solución que se propone. La Solución Propuesta específica en términos
no técnicos cómo la solución satisface al cliente y es la base para la Especificación
Funcional, que es producida en la fase de diseño. Incluye también el soporte operacional
propuesto que es la base para formular el la Especificación de Diseño de Soporte [MA-
02] (ver anexo Especificación del Sistema).

 Especificación Funcional

La Especificación Funcional especifica en términos no técnicos, qué es lo que la solución


hace para el usuario. Este es un documento muy importante, porque provee una única
definición formal del total de los requerimientos que satisface la solución, y por qué es
la base para planificar el diseño y para desarrollar e implementar el Proyecto.
Para el desarrollo de la Especificación Funcional, se toma como base lo escrito en los
documentos de Especificación de Requerimientos y Solución Propuesta [MA-02] (ver
anexo Especificación Funcional).

 Plan de pruebas

El Plan de Pruebas es un documento estrechamente alineado con la Especificación


Funcional, el cual describe las pruebas que serán llevadas a cabo para demostrar al
cliente que la solución satisface los requerimientos y que la solución cumple con el uso
que se pretende en el ambiente operacional del cliente (Verificación y Validación).
 Especificación de Diseño de Sistema

La Especificación de Diseño del Sistema define la Arquitectura de la Solución e identifica


todos los componentes del sistema. Establece las interfaces y la especificación a alto
nivel de cada componente. Para cada componente se establece: la descripción de la
componente, diagrama de flujo de datos de la componente, interfaces de la
componente, estructura de datos de la componente, diseño funcional de la
componente, criterios de diseño y restricciones de la componente, especificación de test
de la componente e integración, y ambiente de la componente.
Por otro lado, también especifica un nivel básico de implementación y los test de
componentes e integración que se utilizan en la fase de implementación [MA-02] (ver
anexo Especificación de Diseño de Sistema).

 Especificación de Diseño de Soporte

La Especificación de Diseño de Soporte provee documentación detallada de los


requerimientos de soporte desde la fase de implementación a la de operación. Los
requerimientos de soporte al cliente deben ser claramente establecidos para identificar
áreas críticas que pudieran requerir recursos significativos [MA-02] (ver anexo
Especificación de Diseño de Soporte).

 Plan de Aseguramiento de Calidad SQA

El Plan de QA define todas las actividades de aseguramiento de calidad que se harán


durante el proyecto. La importancia de este plan reside en contar con un documento
formal con instrucciones explícitas acerca de la forma de llevar a cabo cada una de las
actividades previamente planificadas y de esta forma poder controlar cada una de las
variables que inciden en el correcto desarrollo del producto

El Proyecto, debe tener definidas ciertas actividades para cumplir con sus estándares de
calidad, entre ellas realizar revisiones e inspecciones dentro del proyecto, llevar a cabo
testing de los módulos desarrollados, entre otras. Estas actividades, serán realizadas
durante todo el proceso de desarrollo del software para asegurar que este cumpla con
los criterios de calidad impuestos.
Algunas de las etapas a seguir son las de llevar a cabo controles sobre la documentación
del software, códigos fuentes, manuales e informes de requerimientos, mantener toda
la documentación con respecto a los cambios efectuados durante el desarrollo, llevar a
cabo procedimientos que permitan asegurar los ajustes de los estándares de desarrollo
de software, mecanismos para realizar mediciones de manejo de información e
identificación de procesos, entre otros.
Por otra parte, el Plan de QA, entrega todos los procedimientos y estándares que se
llevarán a cabo durante el desarrollo del proyecto, así como los formularios y checklist
correspondientes. Se entrega junto con el Plan de Proyecto [MA-02].

 Plan de Gestión de la Configuración SCM

Describe la metodología que se seguirá para realizar la gestión de la configuración en el


proceso de desarrollo de software, los formularios y checklist

 Informe de pruebas (testing)

Los resultados de estas pruebas ayudarán a comprobar el “buen” funcionamiento del


software una vez integrados sus componentes (ver anexo Informe de pruebas).

 Manual de usuario

Explica el comportamiento del sistema desde el punto de vista funcional de la Aplicación.


Para ello, se basa en el documento de Especificación Funcional (ver anexo Manual de
Usuario).

 Manual de instalación del sistema

Especificación de los componentes de instalación y la forma en que se debe realizar esta


tarea.

 Avances de la Aplicación

Subproductos que evaluará el cliente

 Diseño de imágenes y escenarios

Elementos gráficos que forman parte de la aplicación.


Glosario de términos

Para lograr un mejor entendimiento de los términos técnicos que se utilizan en el


presente Plan de SQA, se mencionan a continuación los significados de los siguientes
términos

 Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar


a la administración una visibilidad adecuada del proceso utilizado y los productos
construidos mediante acciones planificadas y sistemáticas que aseguren la calidad
de dichos procesos y productos.
 Auditoría  Evaluación independiente de los productos de trabajo y de un conjunto
de procesos de software para asegurar la adherencia con las especificaciones, los
estándares, procedimientos y otros acuerdos.
 Gestión de la Configuración del Software (SCM) El propósito de SCM es establecer
y mantener la integridad de los productos a través de todo el ciclo de vida del
software, para así proveer un adecuado control de los cambios en los diversos ítems
de configuración.
 Revisión  Metodología definida, estructurada y disciplinada para la detección e
identificación de defectos en los productos de trabajo durante el ciclo de vida del
software.
 Prueba (Testing)  Actividad que evalúa los atributos y la capacidad de un programa
o sistema para determinar si se cumple con los resultados definidos.

You might also like