Prox Ter

PLAN DE CALIDAD PARA PRODUCTO DE
SOFTWARE
“CONTROL DE SELLOS DE SEGURIDAD DE LA

EMPRESA XYZ”
STALIN INUCA
Profesor Guía:
ING. JUAN CARLOS ARMAS
OTAVALO,
FEBRERO, 2019
1. INTRODUCCIÓN
La rapidez con que el mercado mundial avanza hacia la globalización, hace imprescindible el uso
de la tecnología como primer recurso para concretarla. Dentro de ella, lo que ha tenido éxito en el
último tiempo es la aparición de nuevos sistemas operativos, los cuáles tienen como finalidad,
actuar como intermediario entre el usuario y el computador, de manera que el usuario pueda
ejecutar programas y usar el equipo de manera adecuada. Para que todo esto sea posible, el
sistema debe responder de manera eficiente. Dentro de tales características, el sistema operativo a
utilizarse es Windows 7.
Llevado al ámbito nacional, se puede apreciar que dicho recurso ha experimentado un desarrollo
cada vez más creciente en los últimos años, con lo cual se hace patente la necesidad de las
empresas y las personas en general, de encontrar una manera apropiada de adquirir los
conocimientos que les permitan desenvolverse dentro de esta tecnología emergente.
Usando las herramientas y tecnología que la informática provee, la empresa, y todo su equipo ha
decidido contribuir proporcionando los elementos adecuados para satisfacer las necesidades de
todos aquellos con mayor desconocimiento en el área de utilización de Microsoft visual studio y sql-
server, mediante una aplicación de software que facilite el manejo de inventarios y seguridad del
producto en finca, es decir, una herramienta que guíe y ayude al usuario. Para ello, la herramienta
que permitirá conseguir estos objetivos es app de control de sellos y seguridad.
1.1 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.
Por lo tanto, el plan de SQA está dirigido al jefe de proyecto, los desarrolladores y al grupo de
SQA, responsable de la elaboración, actualización y monitoreo del plan.
1.2 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 software 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.
2
1.3 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
Documentación para controlar y monitorear.

Plan de Proyecto
Documentación sobre las posibles situaciones

Plan de Riesgos
en las que el Proyecto puede verse afectado
Repositorio central que contiene la información
Especificación de Requerimientos
actualizada de cada uno de los requerimientos
detectados.
Descripción de los requerimientos del cliente
que deben ser satisfechos por el equipo de
desarrollo.
Documentación sobre la situación actual, sus
Especificación del sistema (Solución Propuesta)
problemas y las mejoras que introduce el
desarrollo de la solución que se propone.
Documentación que especifica en términos no
Especificación Funcional
técnicos, que es lo que la solución hace que se
propone.
Documentación que describe las pruebas que
Plan de pruebas
serán llevadas a cabo para demostrar al cliente
que la solución satisface los requerimientos
definidos.
Documentación que define la Arquitectura de la
Especificación de Diseño de Sistema
Solución e identifica todos los componentes del
sistema..
Documentación detallada de los requerimientos
Especificación de Diseño de Soporte
de soporte desde la fase de Implementación a la
de Operación.
Documentación que define todas las actividades
Plan de aseguramiento de calidad SQA
de aseguramiento de calidad que se harán
durante el Proyecto.
Documentación que describe la metodología que
Plan de gestión de la configuración SCM
se seguirá para realizar la gestión de la
configuración en el proceso de desarrollo de
software, formularios y checklist
Documentación que describe los resultados de
Informe de pruebas (testing)
las pruebas, los cuales ayudarán a comprobar el
“buen” funcionamiento del software.
Documentación que describe el comportamiento
Manual de usuario
del sistema desde el punto de vista funcional de
la aplicación.
Documentación de la especificación de los
Manual de instalación del sistema
componentes de instalación y la forma en que se
debe realizar esta tarea.
Subproductos que evaluará el cliente.
Avances de la Aplicación
Elementos gráficos que forman parte de la

Diseño de imágenes y escenarios
aplicación
Tabla 1: Identificación Productos de Trabajo
3
1.4 Descripción del Sistema
1.4.1 Descripción de la situación actual
Al momento la empresa no cuenta con un registro sistematizado ya que la toma de registro de

sellos y control de seguridad es manual por tal razón hay filtración de información y perdida de la
misma.
La tendencia desde hace un par de años es que en los colegios y en las familias existan
computadores, debido a ello los jóvenes se están habituando a usarlos tempranamente.
La mayoría de estos computadores, funcionan principalmente con el sistema operativo Windows,
debido en gran parte al posicionamiento de éste en el mercado y la facilidad de manejo se
implementara un aplicativo relacionado con comercio exterior y seguridad física de la empresa.
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 [WEB-01]:
 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.
1.6 Acrónimos
Acrónimo Significado
SQA Software Quality Assurance, Aseguramiento de la Calidad del Software
SCM Software Configuration Management, Gestión de Configuración del

Software
WBS Work Breakdown Structure
4
2. REQUERIMIENTOS
Un requerimiento es un aspecto del producto requerido o deseado por el cliente. Los

Requerimientos Funcionales cubren las funciones y operaciones a realizar para proporcionar un
sistema que operará de acuerdo a las necesidades del usuario. Al elaborar una lista completa de
las percepciones de los usuarios respecto a sus requerimientos, se definen las funciones que
tendrán que ser realizadas por el sistema a desarrollar. En cambio, un Requerimiento No Funcional
indica cómo se deben hacer todas las actividades de desarrollo para obtener un producto con la
mayor calidad posible ya que ésta puede hacer la diferencia entre el éxito o fracaso de una
aplicación.
Las métricas usadas para medir la calidad de los Requerimientos No Funcionales del APP. Control
de sellos y seguridad son los siguientes:
 Interfaz: Se basa en lo referente a la calidad de la Interfaz usuaria

 Portabilidad: Capacidad de la aplicación para funcionar correctamente en diferentes
configuraciones, ya sean de software o hardware.
 Performance: Requerimientos reales de la performance, velocidad, precisión, disponibilidad,
nivel de servicio, volúmenes de datos, entre otros.
 Operacional: Ambiente en que el usuario operará el producto.
 Mantenibilidad: Es el tiempo esperado y el permitido para el mantenimiento o la realización
de cambios.
 Seguridad: Requerimientos para permitir el acceso, restringir mal uso, hechos anormales,
entre otros.
2.1 Aplicación de las Métricas definidas para el app
 Interfaz
La interfaz para esta aplicación debe ser simple en la entrega de datos, topología de letra
adecuada a la vista, colores adecuados, rápidos y eficientes para la selección e ingreso de datos al
sistema.
Objetivos
 Simplicidad en la entrega de datos, sin tener necesidad de instrucciones para su uso.

 Tipología de la letra adecuada a la vista y que no produzca rechazo por el usuario.
 Forma rápida y eficiente para seleccionar e ingresar datos al sistema.
 La interfaz debe mostrar la estructura de los contenidos, de manera rápida de entender para el
usuario, además de figuras didácticas, colores y enlaces, para una mejor comprensión y
profundización de los temas.
Criterios de Aceptación
 La interfaz debe mostrar en todo momento la estructura de árbol que presenta para la
organización de los contenidos.
 La rapidez de respuesta de la aplicación, ante los datos que se seleccionan e ingresan no
debe superar los 2 seg.
5
 Portabilidad
Para la utilización de la aplicación, debe considerarse el correcto funcionamiento desde el sistema

operativo Linux y el hardware apropiado para su uso.
Objetivos
 Los equipos deben contar con ciertas características mínimas para el correcto funcionamiento
del sistema.
 La aplicación debe funcionar bajo el sistema operativo Microsoft.
 La aplicación debe acoplarse a la totalidad de módulos construidos y los que puedan ser
incorporados de forma posterior.
 La aplicación debe ejecutarse sin ningún problema en los distintos computadores donde sea
instalado. Para ello, las características mínimas son:
 Procesador Intel core i3

 Disco Duro de 500 GB
 2 Gb Ram
 La aplicación debe funcionar bajo el sistema operativo Windows 7 o similares Base de Datos
SQL server.
 Performance
Rapidez de respuesta a las consultas realizadas a la base de datos y manejo de grandes

volúmenes de datos.
Objetivos
 La aplicación debe entregar una respuesta rápida a la consulta realizada.

 La aplicación debe permitir el manejo rápido de grandes volúmenes de datos.
 La rapidez de respuesta no debe ser mayor a 5 [seg] desde que se realizó la actualización.
 La aplicación debe permitir el manejo de 10000 registros.
 Operacional
Por otra parte, la información desplegada por pantalla debe ser clara y sencilla, sin mayor
sobrecarga de imágenes e información, de manera que no sea dificultoso el entendimiento de los
datos desplegados.
Objetivos
 La aplicación debe mostrar un número adecuado de figuras dinámicas y estáticas, evitando la

sobrecarga de ellas.
 La aplicación debe mostrar un número de preguntas que no sobrecargue la interfaz.
 No se deben desplegar más de 3 figuras dinámicas y 5 figuras dinámicas en forma simultánea.

 No se deben desplegar más de 10 preguntas por cada módulo a evaluar.
6
 Mantenibilidad
El mantenimiento debe ser realizado a medida que se reporten fallas o inconsistencias que no sean
descubiertas durante el desarrollo, éstas fallas serán descubiertas por los mismos usuarios de la
aplicación dándolas a conocer a través de e-mail o personalmente al Administrador.
Objetivos
 La aplicación debe funcionar correctamente sin la necesidad de modificaciones posteriores al

equipo.
 La mantención debe ser realizada en horarios en que no se ocupe la Aplicación.
 Se debe considerar el tiempo de mantención y los módulos afectados por los cambios, ya sean
correctivos o perfectivos.
 El tiempo de mantención estará restringido según las líneas de código del módulo afectado,
debido a que existen componentes que son de gran complejidad, por lo cual tendrán un tiempo
mayor de mantención.
 La aplicación debe ser actualizada una vez cada seis meses, debido a los continuos cambios
que puedan sufrir las versiones de la aplicación.
 La documentación necesaria debe tener descrito los cambios realizados, además de los pasos
seguidos en el proceso de desarrollo y mantenciones posteriores.
 El código fuente de la aplicación debe ser comentado al menos en un 50% del total, y claros en
su estructura.
 Seguridad
La aplicación debe tener la capacidad de detectar consultas, equivocadas o mal intencionadas por
parte del usuario.
Por otra parte, el hecho de que los datos se modificarán constantemente, se debe tener un
respaldo periódico de la aplicación.
Objetivos
 Los datos no deben ser modificados por terceros.

 Se debe asegurar la recuperación de los datos, en caso de fallar la aplicación.
 La aplicación debe poseer un control de acceso al sistema, con el fin de evitar el
procesamiento de datos erróneos.
 Se debe establecer un perfil para el administrador, quien tendrá acceso a la información clave
de la aplicación.
3. MODELO DE DESARROLLO
Se optó por la estrategia de desarrollo “Modelo Incremental”, el cual aplica secuencias lineales de
forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
“incremento” del software. La elección de la estrategia seleccionada se debe a que la intención es
entregar el software en partes pequeñas, pero utilizables, llamadas “incrementos”, es decir, cada
“incremento” se construye sobre aquél que ya ha sido entregado .
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial,
es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas
conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión
detallada). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el
7
incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las
necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se
repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Los
primeros incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario
la funcionalidad que precisa y también una plataforma para la evaluación. El desarrollo incremental
es particularmente útil cuando la dotación de personal no está disponible para una implementación
completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se
pueden implementar con menos personas .
Otro punto a considerar, es que pese a que el cliente está abierto a recibir nuevas soluciones a sus
problemas, no tiene claro cuáles son sus requisitos ideales. Debido a esto, la construcción
temprana del sistema nos puede llevar a desarrollar una solución inútil. Como solución a esto, se
entregará una versión del programa App control de sellos y seguridad con la implementación de
algunas funciones, dejando el proyecto abierto a que en una futura etapa de desarrollo, entregue
una nueva versión del proyecto que agregue nuevas funcionalidades (un incremento).
Ingeniería Sistemas Incremento 1

de Información
Entrega de 1°
Análisis Diseño Código Prueba
Incremento
Incremento 2
Entrega de 2°
Incremento
Incremento 3
Entrega de 3°
Incremento
Incremento 4
Entrega de 4°
Incremento
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.
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. MA-02]:
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 de liberables 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.
11
3.2 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.
 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 (Ver página 36).
 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.
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.
12
 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 en
la Especificación de Diseño de Soporte.
 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.
 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.
 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.
 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
13
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.

3.2.1 Definición de los atributos de calidad
 Con una perspectiva orientada hacia la Revisión del Producto se tienen los siguientes factores:
1º. Mantenimiento ¿Se pueden corregir los errores?

2º. Flexibilidad ¿Pueden cambiarlo?
3º. Prueba ¿Puede ser probado?
 Tomando una perspectiva desde la Operación del Producto se tienen los siguientes factores:
4º. Corrección ¿Hace lo que se le pidió?

5º. Confiabilidad ¿Es confiable todo el tiempo?
6º. Facilidad de uso ¿Está diseñado para ser usado?
7º. Integridad ¿Es seguro (inviolable)?
8º. Eficiencia ¿Podrá ejecutarse lo mejor que pueda?
 Con una perspectiva de la Transición del Producto se tienen los siguientes factores:
9º. Portabilidad ¿Podrá usarse en otra máquina?

10º. Rehusabilidad ¿Podrá rehusar algo del software?
11º. Interoperatividad ¿Podrá interactuar con otro sistema?
 Otros atributos definidos son los siguientes:
12º. Completitud ¿Se encuentran todas las funciones y restricciones en

el sistema?
13º. Claridad Son suficientemente claros los conceptos e ideas que
se intentan expresar?
15
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo
Producto Planificación
Objetivo Cuantificable La Planificación del proyecto debe respetar los
plazos establecidos.
Se requiere la participación del cliente.
Atributos de Calidad Claridad, Mantenimiento, Flexibilidad,
Confiabilidad, Corrección, Facilidad de uso,
Eficiencia, Integridad.
Encargado (s) revisión final Gerente de Proyecto, Jefe de Proyecto, Cliente
Tabla 4: Planificación
Producto Especificación de Requerimientos

(Definición)
Objetivo Cuantificable Se requiere la participación del cliente.
No se debe consumir más de un 20% del tiempo
total del proyecto.
Deben estar identificados los problemas o
necesidades de Negocios en un 90%.
Las metas de la organización, sus objetivos y
factores críticos de éxito deben ser analizados
en un 100%.
Los Procesos de Negocios y flujos de
información actuales deben ser analizados en un
100%.
Los Requerimientos de la Solución, en términos
de Procesos y principios de negocios, estructura
organizacional y arquitectura tecnológica, deben
ser analizados en un 100%
Los beneficios de la Solución e impacto en la
organización, recursos humanos y ambiente
tecnológico deben ser analizados en un 100%.
Nota: En esta etapa no se debe pensar en
posibles soluciones, sino solamente en el
problema, es decir, se debe describir el
problema en forma de Requerimientos
Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos
Tabla 5: Especificación de Requerimientos
Producto Análisis
Se requiere la participación del Analista de
Negocios
No se debe consumir más de un 30% del tiempo
total del proyecto.
Se deben identificar las soluciones que
satisfagan la Especificación de Requerimientos,
en un 100%, y seleccionar solo una.
Se debe documentar la Solución Propuesta en
un 100%.
Se debe preparar el Plan inicial del Proyecto en
un 70% del total y de QA en un 80%, basado en
la Solución Propuesta.
Atributos de Calidad Completitud, Claridad, Mantenimiento,

Flexibilidad, Corrección, Confiabilidad, Facilidad
de uso, Integridad, Eficiencia
Tabla 6: Análisis
16
Producto Diseño
Objetivo Cuantificable No se debe consumir más de un 60% del tiempo
total del Proyecto.
Se requiere de la participación del Arquitecto de
Sistema.
Se requiere la participación del Diseñador.
Se requiere de la participación del Jefe de
Proyectos.
Se requiere participación del Analista de
Negocios
Se debe definir la Funcionalidad y Solución
Física que va a satisfacer los Requerimientos en
un 90%.
Se debe planificar cómo se va a implementar y
aceptar la Solución Propuesta en un 90%.
Se debe planificar el soporte de la Solución
Propuesta en un 90%.
Atributos de Calidad Claridad, Completitud, Mantenimiento,
Encargado (s) revisión final Arquitecto de Sistema, Jefe de Proyectos,
Cliente
Tabla 7: Diseño
Producto Implementación
Objetivo Cuantificable No se debe consumir más de un 60% del total
del Proyecto.
Las Pruebas no deben superar más del 30% del
total del Proyecto.
Los componentes de la Solución deben ser
construidos en un 100%.
Las Pruebas deben cubrir el 100% de los
Componentes construidos.
Atributos de Calidad Corrección, Claridad, Mantenimiento, Integridad,
Completitud, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final Jefe de Proyecto, Cliente, Arquitecto de Sistema
Tabla 8: Implementación
Producto Instalación (Aceptación y Entrega)

La Solución se prueba 100% en un ambiente
operacional hasta que esté lista para la prueba
de aceptación formal por parte del cliente.
El cliente debe estar de acuerdo en que la
Solución cumple la Especificación Funcional,
que la Solución ha sido distribuida y que la
Organización acepta la propiedad de la
Solución, en un 100%.
Se debe registrar, revisar y corregir la Solución
para los defectos identificados en un 100%.
Se debe involucrar al personal de Soporte para
facilitar el traspaso exitoso, en un 80%.
Atributos de Calidad Mantenimiento, Corrección, Claridad,
Confiabilidad, Integridad, Completitud, Facilidad
de uso, Eficiencia
Encargado (s) revisión final Cliente
Tabla 9: Instalación (Aceptación y Entrega)
Producto Operación (Mantención)

Se debe hacer una revisión para registrar datos
estadísticos y discutir sobre áreas de
experiencia que puedan ser útiles para otros
proyectos en el futuro, en un 80%.
17
Se debe archivar el contenido del Proyecto y
considerar el proyecto como terminado, en un
100%.
Se debe proveer soporte para la Mantención de
la Solución en un 100%.
Atributos de Calidad Corrección, Flexibilidad, Facilidad de uso,
Corrección, Confiabilidad, Claridad
Encargado (s) revisión final Cliente
Tabla 10: Operación (Mantención)

3.2.3 Atributos de calidad (evaluados por QA) por productos de trabajo
Producto Plan de Proyecto

Objetivo Cuantificable El documento no debe superar las 200 hojas
Debe ser comprendido en un 98% por la
totalidad del Equipo de trabajo.
La Planificación del Proyecto debe ser capaz de
soportar Eventos No Planificados que se puedan
producir en el transcurso del Proyecto. Los
EVNP no deben cubrir más de un 10% del
tiempo total del Proyecto.
Se requiere participación del cliente.
El Plan del Proyecto debe contemplar la
estrategia, organización, riesgos, contingencias,
recursos y tareas, en un 100% para la fase de
diseño.
Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final Gerente de Proyecto, Jefe de Proyecto, Cliente
Tabla 11: Plan de Proyecto
Producto Plan de Riesgos

Objetivo Cuantificable El documento no debe superar las 50 hojas.
El documento como mínimo debe contener 20
riesgos.
Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia.
Encargado (s) revisión final Jefe de Proyectos
Tabla 12: Plan de Riesgos
Producto Especificación de Requerimientos

Objetivo Cuantificable Se requiere participación del Jefe de Proyectos.
Negocios.
Debe existir un 100% de conformidad en los
acuerdos entre Cliente y Jefe de Proyectos.
Se debe permitir una administración eficiente
ante los estados y cambios que sufran los
requerimientos, en un 100%.
Debe ser suficientemente claro, es decir,
explicado de manera No técnica para el
entendimiento del cliente.
Deben estar contemplados el 100% de los
Requerimientos planteados por el cliente.
Deben estar contemplados un 100% de los
Requerimientos Derivados.
Atributos de Calidad Completitud, Mantenimiento, Claridad,
Encargado (s) revisión final Jefe de Proyectos, Cliente
Tabla 13: Especificación de Requerimientos
Producto Especificación de Sistema (Solución

Propuesta)
Objetivo Cuantificable Se requiere participación del Jefe de Proyectos.
Negocios.
acuerdos entre cliente y desarrolladores.
Debe ser claro, es decir, explicado de manera
No técnica para el entendimiento del cliente en
19
un 100%.
La Solución que se presenta al cliente debe ser
rigurosa en sus restricciones, en un 100%.
Tabla 14: Especificación de Sistema (Solución Propuesta)

Producto Especificación Funcional
Objetivo Cuantificable Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Negocios.
Debe ser suficientemente claro, es decir,
explicado de manera No técnica para el
entendimiento del cliente en un 100%.
Encargado (s) revisión final Jefe de Proyecto, Cliente
Tabla 15: Especificación Funcional
Producto Plan de Pruebas

Se requiere participación del Arquitecto de
Sistemas.
Negocios.
El plan de pruebas debe abarcar todos los
módulos de la aplicación.
Las Pruebas deben cubrir el 100% de la
Aplicación.
Las Pruebas deben abordar en un 100% los
tipos de prueba: unitaria, integración, y sistema.
Las Pruebas deben abordar en un 100% los
enfoques: Funcional, Seguridad, Calidad,
Rendimiento, Aceptación, e Instalación.
Atributos de Calidad Claridad, Completitud, Mantenimiento,
Encargado (s) revisión final Cliente, Jefe de Proyectos, Analista de Negocios
Tabla 16: Plan de Pruebas
Producto Especificación de Diseño de Sistema

Se requiere participación del Arquitecto de
Sistemas.
El desarrollador debe comprender en un 98% el
documento.
La Solución (desde el punto de vista del Diseño)
debe contemplar el 100% de los Requerimientos
acordados con el cliente.
debe contemplar el 100% de los Requerimientos
derivados.
debe ser lo suficientemente flexible para
soportar en el futuro nuevas funcionalidades en
un 90%
Tabla 17: Especificación de Diseño de Sistema
Producto Especificación de Diseño de Soporte

21
El Documento no debe superar las 100 hojas.
Tabla 18: Especificación de Diseño de Soporte

Tabla 19: Plan de Aseguramiento de Calidad
Producto Informe de Pruebas (Testing) de la Integridad

del Sistema, Unidad, y Aceptación
Objetivo Cuantificable El cliente debe comprender en un 98% el
documento.
Se deben detectar a lo menos un 40% de
errores en los Casos de Prueba aplicados.
Encargado (s) revisión final Cliente, Persona de QA, Jefe de Proyectos
Tabla 20: Informe de Pruebas (Testing)
Producto Manual de Usuario

Objetivo Cuantificable El manual no debe manejar un lenguaje técnico,
debe ser entendido en un 95% por los usuarios
finales
No debe superar las 50 hojas
Encargado (s) revisión final Desarrollador, Jefe de Proyectos
Tabla 21: Manual de Usuario
Producto Manual de Instalación del Sistema

Objetivo Cuantificable El manual no debe superar las 50 hojas
Encargado (s) revisión final Desarrollador, Jefe de Proyectos
Tabla 22: Manual de Instalación del Sistema
23
Anexos
3.2.4 Puntos de revisión (hitos)
Se identifican como puntos de revisión aquellos que permiten validar y controlar las tareas
realizadas dentro de cada etapa del ciclo de desarrollo y por cada cambio producido en
mantención. Debe ser utilizado por la unidad de SQA durante la planificación para verificar el
correcto establecimiento de los hitos de calidad.
 Planificación
 Revisión y aprobación del plan de SQA.

 Revisión y aprobación del plan de proyecto.
 Revisión y aprobación del plan de riesgos.
 Reporte del estado y los resultados de las actividades de SQA.
 Especificación de requerimientos (Definición)
 Revisión y aprobación de la especificación de requerimientos.

 Análisis
 Revisión y Aprobación de la Especificación del Sistema (Solución Propuesta).

 Diseño
 Revisión y aprobación de la Especificación de Diseño de Sistema.

 Revisión y aprobación de la Especificación Funcional del Sistema.
 Revisión y aprobación de la Especificación de Diseño de Soporte del Sistema.
 Revisión y aprobación del Plan de Pruebas del sistema
 Implementación
 Revisión y aprobación de los casos de prueba.

 Revisión y aprobación de la especificación de los procedimientos de prueba.
 Revisión y aprobación del código y su documentación.
 Revisión y aprobación de los resultados de la prueba de unidad, integración, y sistema
 Revisión y aprobación del Manual de Usuario.
 Revisión y Aprobación del Manual de Instalación del Sistema
 Instalación (Aceptación y entrega)
 Revisión y aprobación el software y su documentación.

 Operación (Mantención)
 Revisión y aprobación de cada cambio producido durante la mantención en su

especificación, diseño, implementación y prueba.
 Revisión y aprobación de la documentación asociada a los cambios.
 Revisión y aprobación de la nueva versión del software y de su documentación.
24
Id Nombre de tarea Duración Comienzo Fin Predecesoras
Unidad Requiriente
'18 dic 31
L M X
1 CRONOGRAMA PROYECTO SELLOS 269,5 días mar 19-01-01 lun 20-01-13
2 FASE INICIO 4 días mar 19-01-01 vie 19-01-04
3 Levantamiento de Requerimientos solicitados 4 días mar 19-01-01 vie 19-01-04
4 Capacitación 3 días mar 19-01-01 jue 19-01-03
5 Reporte: Inscritos 0,5 días mar 19-01-01 mar 19-01-01 DIRECCION GENERAL DE SEGURIDAD CIUDA
6 Reporte: Aprobados 0,5 días mar 19-01-01 mar 19-01-01 5 DIRECCION GENERAL DE SEGURIDAD CIUDA
7 Reporte: LISTADOS 0,5 días mié 19-01-02 mié 19-01-02 6 DIRECCION GENERAL DE SEGURIDAD CIUDA
8 Incluir una opción para importar de manera automatica 0,5 días mié 19-01-02 mié 19-01-02 7 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
9 Programar para poder editar sistema de sellos 0,5 días jue 19-01-03 jue 19-01-03 8 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
10 En la opción de Guardias por Compañía, se muestre una 0,5 días jue 19-01-03 jue 19-01-03 9 DIRECCION GENERAL DE
columna "% Capacitados" que despliegue el Porcentaje SEGURIDAD CIUDADANA
de guardias Capacitados actualizado.
11 Administración 1 día vie 19-01-04 vie 19-01-04

12 Ampliar la información de creación y desactivación de 0,5 días vie 19-01-04 vie 19-01-04 10 DIRECCION GENERAL DE
usuarios internos SEGURIDAD CIUDADANA
13 Gestión en la entrega de claves desechables a usuarios 0,5 días vie 19-01-04 vie 19-01-04 12 DIRECCION GENERAL DE
de compañías de seguridad privada. SEGURIDAD CIUDADANA
14 FASE ANÁLISIS Y DISEÑO 16,5 días lun 19-01-07 mar 19-01-29
15 Análisis y Diseño de los requerimientos solicitados 16,5 días lun 19-01-07 mar 19-01-29
16 Emisión de Permisos de Operación 1ra vez para las 10 días lun 19-01-07 vie 19-01-18
compañías de seguridad privada
Tarea Resumen inactivo Tareas externas
División Tarea manual Hito externo
Hito solo duración Fecha límite

Proyecto: SICOSEP - Cronogram
Resumen Informe de resumen manual Progreso
Fecha: vie 19-02-08
Resumen del proyecto Resumen manual Progreso manual
Tarea inactiva solo el comienzo
Hito inactivo solo fin
Página 1
Unidad Requiriente
'18 dic 31
L M X
17 Diseño del proceso de Permisos de Operación 1ra vez 1 día lun 19-01-07 lun 19-01-07 13 DTICS
18 Registrar Compañía en SICOSEP 2 días mar 19-01-08 mié 19-01-09 17 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
19 Subir los documentos habilitantes (pdf) de la Compañía 1 día jue 19-01-10 jue 19-01-10 18 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
20 Subir el Informe de Inspección de la Compañía al 1 día vie 19-01-11 vie 19-01-11 19 DIRECCION GENERAL DE
Sistema SICOSEP SEGURIDAD CIUDADANA
21 Revisar el Informe de Inspección de la Compañía 1 día lun 19-01-14 lun 19-01-14 20 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
22 Elaborar Acuerdo Ministerial 2 días mar 19-01-15 mié 19-01-16 21 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
23 Subir el Acuerdo Ministerial al sistema SICOSEP 1 día jue 19-01-17 jue 19-01-17 22 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
24 Reporte de Listado de Compañías de Seguridad de 0,5 días vie 19-01-18 vie 19-01-18 23 DIRECCION GENERAL DE
Primera Vez SEGURIDAD CIUDADANA
25 En el módulo Consultas a la Ciudadana, opción 0,5 días vie 19-01-18 vie 19-01-18 24 DIRECCION GENERAL DE
Compañías, incluir las Compañías que están solicitando SEGURIDAD CIUDADANA
el permiso de operación por primera vez
26 Capacitación 4,5 días lun 19-01-21 vie 19-01-25

27 Diseño del proceso de Capacitación 1 día lun 19-01-21 lun 19-01-21 25
28 Reporte: Inscritos por compañía de seguridad 0,5 días mar 19-01-22 mar 19-01-22 27 DTICS
29 Reporte: Aprobados 0,5 días mar 19-01-22 mar 19-01-22 28 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA

Fecha: vie 19-02-08
Página 2
Unidad Requiriente
'18 dic 31
L M X
30 Reporte: Aprobados por compañía de seguridad 0,5 días mié 19-01-23 mié 19-01-23 29 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
31 Incluir una opción para importar de manera automática 0,5 días mié 19-01-23 mié 19-01-23 30 DIRECCION GENERAL DE
el listado de guardias aprobados y capacitados al SEGURIDAD CIUDADANA
SICOSEP
32 Programar para poder editar sistema Sicosep en cuanto 1 día jue 19-01-24 jue 19-01-24 31 DIRECCION GENERAL DE
a convocatorias por centro SEGURIDAD CIUDADANA
33 En la opción de Guardias por Compañía, se muestre una 0,5 días vie 19-01-25 vie 19-01-25 32 DIRECCION GENERAL DE
34 Administración 2 días vie 19-01-25 mar 19-01-29

35 Ampliar la información de creación y desactivación de 1 día vie 19-01-25 lun 19-01-28 33 DIRECCION GENERAL DE
36 Gestión en la entrega de claves desechables a usuarios 1 día lun 19-01-28 mar 19-01-29 35 DIRECCION GENERAL DE
37 FASE DE DESARROLLO 58 días mar 19-01-29 vie 19-04-19
38 Emisión de Permisos de Operación 1ra vez para las 33 días mar 19-01-29 vie 19-03-15
39 Registrar Compañía en SICOSEP 10 días mar 19-01-29 mar 19-02-12 36 DTICS
40 Subir los documentos habilitantes (pdf) de la Compañía 4 días mar 19-02-12 lun 19-02-18 39 DTICS
41 Subir el Informe de Inspección de la Compañía al Sistema 4 días lun 19-02-18 vie 19-02-22 40 DTICS
SICOSEP
42 Revisar el Informe de Inspección de la Compañía 2 días vie 19-02-22 mar 19-02-26 41 DTICS

Fecha: vie 19-02-08
Página 3
Unidad Requiriente
'18 dic 31
L M X
43 Elaborar Acuerdo Ministerial 4 días mar 19-02-26 lun 19-03-04 42 DTICS
44 Subir el Acuerdo Ministerial al sistema SICOSEP 3 días lun 19-03-04 jue 19-03-07 43 DTICS
45 Reporte de Listado de Compañías de Seguridad de Primera 3 días jue 19-03-07 mar 19-03-12 44 DTICS
Vez
46 En el módulo Consultas a la Ciudadana, opción Compañías, 3 días mar 19-03-12 vie 19-03-15 45 DTICS
incluir las Compañías que están solicitando el permiso de
operación por primera vez
47 Capacitación 16 días vie 19-03-15 lun 19-04-08
48 Reporte: Inscritos por compañía de seguridad 2 días vie 19-03-15 mar 19-03-19 46 DTICS
49 Reporte: Aprobados 2 días mar 19-03-19 jue 19-03-21 48 DTICS
50 Reporte: Aprobados por compañía de seguridad 2 días jue 19-03-21 lun 19-03-25 49 DTICS
51 Incluir una opción para importar de manera automática el 4 días lun 19-03-25 vie 19-03-29 50 DTICS
listado de guardias aprobados y capacitados al SICOSEP
52 Programar para poder editar sistema Sicosep en cuanto a 4 días vie 19-03-29 jue 19-04-04 51 DTICS
convocatorias por centro
53 En la opción de Guardias por Compañía, se muestre una 2 días jue 19-04-04 lun 19-04-08 52 DTICS
columna "% Capacitados" que despliegue el Porcentaje de
guardias Capacitados actualizado.
54 Administración 4 días lun 19-04-08 vie 19-04-12
55 Ampliar la información de creación y desactivación de 2 días lun 19-04-08 mié 19-04-10 53 DIRECCION GENERAL DE
56 Gestión en la entrega de claves desechables a usuarios de 2 días mié 19-04-10 vie 19-04-12 55 DIRECCION GENERAL DE
compañías de seguridad privada. SEGURIDAD CIUDADANA

Fecha: vie 19-02-08
Página 4
Unidad Requiriente
'18 dic 31
L M X
57 Versionamiento de cambios a ambiente de pruebas 5 días vie 19-04-12 vie 19-04-19 56 DTICS
58 FASE DE PRUEBAS 501 días mié 17-07-19 jue 19-06-20
59 Etapa de Pruebas para revisión de funcionalidades en 62 días vie 19-03-15 mar 19-06-11
SICOSEP:
60 Emisión de Permisos de Operación 1ra vez para las 59,5 días vie 19-03-15 jue 19-06-06
61 Registrar Compañía en SICOSEP 1 día vie 19-03-15 lun 19-03-18 46 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
62 Subir los documentos habilitantes (pdf) de la Compañía 0,5 días lun 19-03-18 lun 19-03-18 61 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
63 Subir el Informe de Inspección de la Compañía al 0,5 días mar 19-03-19 mar 19-03-19 62 DIRECCION GENERAL DE
Sistema SICOSEP SEGURIDAD CIUDADANA
64 Revisar el Informe de Inspección de la Compañía 0,5 días jue 19-06-06 jue 19-06-06 63 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
65 Elaborar Acuerdo Ministerial 0,5 días jue 19-06-06 jue 19-06-06 64 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
66 Subir el Acuerdo Ministerial al sistema SICOSEP 0,5 días jue 19-06-06 jue 19-06-06 65 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
67 Reporte de Listado de Compañías de Seguridad de 0,5 días jue 19-06-06 jue 19-06-06 66 DIRECCION GENERAL DE
Primera Vez SEGURIDAD CIUDADANA
68 En el módulo Consultas a la Ciudadana, opción 0,5 días jue 19-06-06 jue 19-06-06 67 DIRECCION GENERAL DE
Compañías, incluir las Compañías que están solicitando SEGURIDAD CIUDADANA
el permiso de operación por primera vez
69 Capacitación 3 días jue 19-06-06 mar 19-06-11

Fecha: vie 19-02-08
Página 5
Unidad Requiriente
'18 dic 31
L M X
70 Reporte: Inscritos por compañía de seguridad 0,5 días jue 19-06-06 jue 19-06-06 48 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
71 Reporte: Aprobados 0,5 días jue 19-06-06 jue 19-06-06 70 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
72 Reporte: Aprobados por compañía de seguridad 0,5 días jue 19-06-06 jue 19-06-06 71 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
73 Incluir una opción para importar de manera automática 0,5 días vie 19-06-07 vie 19-06-07 72 DIRECCION GENERAL DE
el listado de guardias aprobados y capacitados al SEGURIDAD CIUDADANA
SICOSEP
74 Programar para poder editar sistema Sicosep en cuanto 0,5 días jue 19-06-06 jue 19-06-06 73 DIRECCION GENERAL DE
a convocatorias por centro SEGURIDAD CIUDADANA
75 En la opción de Guardias por Compañía, se muestre una 0,5 días jue 19-06-06 jue 19-06-06 74 DIRECCION GENERAL DE
76 Administración 1 día jue 19-06-06 vie 19-06-07

77 Ampliar la información de creación y desactivación de 0,5 días jue 19-06-06 jue 19-06-06 56 DIRECCION GENERAL DE
78 Gestión en la entrega de claves desechables a usuarios 0,5 días jue 19-06-06 jue 19-06-06 77 DIRECCION GENERAL DE
79 Ajustes por Etapa de Pruebas de manera interactiva hasta 5 días jue 19-06-06 jue 19-06-13 57 DIRECCION GENERAL DE
aceptación del usuario SEGURIDAD CIUDADANA
80 Elaboración de Instructivo o Manual de Usuario 3 días jue 19-06-13 mar 19-06-18 79 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
81 Capacitación a usuarios de DGSC 2 días mar 19-06-18 jue 19-06-20 80 DTICS

Fecha: vie 19-02-08
Página 6
Unidad Requiriente
'18 dic 31
L M X
82 Capacitación a usuarios de COSP 2 días mié 17-07-19 vie 17-07-21 81 DTICS
83 FASE DE IMPLANTACIÓN 8 días mar 19-01-01 jue 19-01-10
84 Versionamiento de cambios a ambiente de producción 5 días mar 19-01-01 lun 19-01-07 82 DTICS D
85 Prueba final de aceptación en producción y control de calidad 2 días mar 19-01-08 mié 19-01-09 84 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA
86 Lanzamiento a Producción 1 día jue 19-01-10 jue 19-01-10 85 DIRECCION GENERAL DE
SEGURIDAD CIUDADANA

Fecha: vie 19-02-08
Página 7
18 dic 31 '19 ene 07 '19 ene 14 '19 ene 21 '19 ene 28 '19 feb 04 '19 feb 11 '19 feb 18
X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M

Fecha: vie 19-02-08
Página 8

Fecha: vie 19-02-08
Página 9

Fecha: vie 19-02-08
Página 10

Fecha: vie 19-02-08
Página 11

Fecha: vie 19-02-08
Página 12

Fecha: vie 19-02-08
Página 13
DINACOM
COSP
COSP

Fecha: vie 19-02-08
Página 14
'19 feb 18 '19 feb 25 '19 mar 04 '19 mar 11 '19 mar 18 '19 mar 25 '19 abr 01 '19 abr
M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L

Fecha: vie 19-02-08
Página 15

Fecha: vie 19-02-08
Página 16

Fecha: vie 19-02-08
Página 17

Fecha: vie 19-02-08
Página 18

Fecha: vie 19-02-08
Página 19

Fecha: vie 19-02-08
Página 20

Fecha: vie 19-02-08
Página 21
'19 abr 08 '19 abr 15 '19 abr 22 '19 abr 29 '19 may 06 '19 may 13 '19 may 20
L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D

Fecha: vie 19-02-08
Página 22

Fecha: vie 19-02-08
Página 23

Fecha: vie 19-02-08
Página 24

Fecha: vie 19-02-08
Página 25

Fecha: vie 19-02-08
Página 26

Fecha: vie 19-02-08
Página 27

Fecha: vie 19-02-08
Página 28
'19 may 27 '19 jun 03 '19 jun 10 '19 jun 17 '19 jun 24 '19 jul 01 '19 jul 08
D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S

Fecha: vie 19-02-08
Página 29

Fecha: vie 19-02-08
Página 30

Fecha: vie 19-02-08
Página 31

Fecha: vie 19-02-08
Página 32
COSP

Fecha: vie 19-02-08
Página 33
DINACOM;MDI;COSP
DINACOM;COSP
DINACOM;COSP

Fecha: vie 19-02-08
Página 34

Fecha: vie 19-02-08
Página 35
'19 jul 15 '19 jul 22 '19 jul 29 '19 ago 05 '19 ago 12 '19 ago 19 '19 ago 26
S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V

Fecha: vie 19-02-08
Página 36

Fecha: vie 19-02-08
Página 37

Fecha: vie 19-02-08
Página 38

Fecha: vie 19-02-08
Página 39

Fecha: vie 19-02-08
Página 40

Fecha: vie 19-02-08
Página 41

Fecha: vie 19-02-08
Página 42
6 '19 sep 02 '19 sep 09 '19 sep 16 '19 sep 23 '19 sep 30 '19 oct 07 '19 oct 14
V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J

Fecha: vie 19-02-08
Página 43

Fecha: vie 19-02-08
Página 44

Fecha: vie 19-02-08
Página 45

Fecha: vie 19-02-08
Página 46

Fecha: vie 19-02-08
Página 47

Fecha: vie 19-02-08
Página 48

Fecha: vie 19-02-08
Página 49
ct 14 '19 oct 21 '19 oct 28 '19 nov 04 '19 nov 11 '19 nov 18 '19 nov 25 '19 dic 02
J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X

Fecha: vie 19-02-08
Página 50

Fecha: vie 19-02-08
Página 51

Fecha: vie 19-02-08
Página 52

Fecha: vie 19-02-08
Página 53

Fecha: vie 19-02-08
Página 54

Fecha: vie 19-02-08
Página 55

Fecha: vie 19-02-08
Página 56
19 dic 02 '19 dic 09 '19 dic 16 '19 dic 23 '19 dic 30 '20 ene 06 '20 ene 13 '20 ene 20

Fecha: vie 19-02-08
Página 57

Fecha: vie 19-02-08
Página 58

Fecha: vie 19-02-08
Página 59

Fecha: vie 19-02-08
Página 60

Fecha: vie 19-02-08
Página 61

Fecha: vie 19-02-08
Página 62

Fecha: vie 19-02-08
Página 63

Prox Ter

Hochgeladen von

Dokumentinformationen

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Prox Ter

Hochgeladen von

Copyright:

PLAN DE CALIDAD PARA PRODUCTO DE

“CONTROL DE SELLOS DE SEGURIDAD DE LA

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

El presente documento establece, de acuerdo a la política organizacional, las actividades de SQA

Producto de Trabajo Descripción

Documentación para controlar y monitorear.

Documentación sobre las posibles situaciones

Elementos gráficos que forman parte de la

Tabla 1: Identificación Productos de Trabajo

Al momento la empresa no cuenta con un registro sistematizado ya que la toma de registro de

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

SQA Software Quality Assurance, Aseguramiento de la Calidad del Software

SCM Software Configuration Management, Gestión de Configuración del

WBS Work Breakdown Structure

Un requerimiento es un aspecto del producto requerido o deseado por el cliente. Los

 Interfaz: Se basa en lo referente a la calidad de la Interfaz usuaria

2.1 Aplicación de las Métricas definidas para el app

 Simplicidad en la entrega de datos, sin tener necesidad de instrucciones para su uso.

Para la utilización de la aplicación, debe considerarse el correcto funcionamiento desde el sistema

 Procesador Intel core i3

Rapidez de respuesta a las consultas realizadas a la base de datos y manejo de grandes

 La aplicación debe entregar una respuesta rápida a la consulta realizada.

 La aplicación debe mostrar un número adecuado de figuras dinámicas y estáticas, evitando la

 No se deben desplegar más de 3 figuras dinámicas y 5 figuras dinámicas en forma simultánea.

 La aplicación debe funcionar correctamente sin la necesidad de modificaciones posteriores al

 Los datos no deben ser modificados por terceros.

Ingeniería Sistemas Incremento 1

Actividades del proceso de desarrollo

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

 Especificación de requerimientos (Definición)

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

 La adherencia del diseño y su documentación a los estándares definidos en el Plan del

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

Los posibles componentes son:

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

A SQA le corresponde auditar:

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

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

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

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

 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

 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

 Informe de pruebas (testing)

 Manual de instalación del sistema

Subproductos que evaluará el cliente

 Diseño de imágenes y escenarios

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

1º. Mantenimiento ¿Se pueden corregir los errores?

4º. Corrección ¿Hace lo que se le pidió?

9º. Portabilidad ¿Podrá usarse en otra máquina?

 Otros atributos definidos son los siguientes:

12º. Completitud ¿Se encuentran todas las funciones y restricciones en

Producto Especificación de Requerimientos

Tabla 5: Especificación de Requerimientos

Atributos de Calidad Completitud, Claridad, Mantenimiento,

Producto Instalación (Aceptación y Entrega)

Tabla 9: Instalación (Aceptación y Entrega)

Producto Operación (Mantención)

Tabla 10: Operación (Mantención)

Producto Plan de Proyecto

Tabla 11: Plan de Proyecto

Producto Plan de Riesgos

Tabla 12: Plan de Riesgos

Producto Especificación de Requerimientos