Ciudad Madero, Tamaulipas a 31 de Octubre de 2014

Instituto Tecnológico de Ciudad Madero

Ingeniería en Sistemas Computacionales

Gestión de proyectos de Software

Punto de Venta para tienda de ropa

Docente: Laura Silvia Vargas Pérez

Integrantes del equipo:

-Daniel Efraín Cruz Rivera
-Luis Eduardo García Albarrán
-Jesús Enrique Ramírez Camacho
-Alberto Isaías Barrón Loredo
Índice:
Capítulo 1 Marco Conceptual

1.1 Introducción………………………………………………………………………………………….
1.2 Definición del problema…………………………………………………………………………….
1.3 Justificación………………………………………………………………………………………….
1.4 Objetivos…………………………………………………………………………………………….
1.4.1 Objetivo General……………………………………………………………………………….
1.4.2 Objetivos Específicos…………………………………………………………………………
1.5 Hipótesis……………………………………………………………………………………………
1.6 Alcances del Proyecto…………………………………………………………………………….
1.7 Limitaciones del Proyecto………………………………………………………………………..
1.8 Factibilidad Técnica y Financiera……………………………………………………………….
1.8.1 Viabilidad económica: estudio de costo-beneficio……………………………………….
1.8.2 Viabilidad técnica y operativa: Análisis del entorno……………………………………..

Capítulo 2 Marco Teórico

2.1. Antecedentes de la arquitectura de 4+1 vistas……………………………………………..
2.2. Estado del Arte………………………………………………………………………………..
2.2.1 Descripción de Requerimientos …………………………………………………………...
2.2.1.1 De proceso //enrique………………………………………………………………………
2.2.1.2 De los usuarios (actores involucrados)………………………………………………..
2.2.1.3 Para la gestión, negociación y análisis ………………………………………………
2.2.1.4 Estándar IEEE 830………………………………………………………………………
2.2.2 Herramientas en el mercado para el manejo de Requerimientos ……………………
2.2.3 Análisis de Riesgo………………………………………………………………………….
2.2.3.1 Diferentes Metodologías de análisis de riesgo………………………………………..
2.2.4 Aseguramiento de la Calidad (Calidad en los procesos)………………………………
2.2.4.1 Normas para la calidad en procesos: SQA, ISO/IEC 15939, 15504, 12207, IEEE 1074..
2.2.5 Control de Calidad (Calidad en el producto)………………………………………………
2.2.5.1 Normas para la calidad en productos: ISO/IEC 9126, 14598, 25000, IEEE 1061 …

Capítulo 3 Marco Metodológíco

3.1 Ciclo de Vida de Desarrollo de Software CVDS elegido………………………………….
3.1.1 Descripción y características ……………………………………………………………..
3.2 Análisis………………………………………………………………………………………….
3.2.1 De la Problemática…………………………………………………………………………
3.2.2 De requisitos del sistema a crear………………………………………………………...
3.2.3 De riesgos………………………………………………………………………………….
3.2.4 De metodología para el aseguramiento de la calidad………………………………….
3.3 Técnicas de desarrollo de las arquitectura de referencia ……………………………
3.3.1 De acuerdo a la arquitectura de referencia del dominio del proyecto:……………….
Diseño en UML (diagrama dinámicos y estáticos)……………………………………
3.3.1 Diagramas de Casos de uso……………………………………………………………
3.3.2 Diagramas de actividades……………………………………………………………….
3.3.3 Diagramas de secuencia e interacción…………………………………………………
3.3.4 Diagramas de colaboración……………………………………………………………..
3.3.5 Diagramas de estados y transiciones…………………………………………………
3.3.5 Diagramas de clases y objetos………………………………………………………..
3.3.6 Diagrama de componentes……………………………………………………………
3.4 Diagramas Entidad-Relación (E-R)………………………………………………………
3.5 Diccionario de Datos……………………………………………………………………….
1.1 INTRODUCCIÓN

El monitoreo de las acciones de una empresa o negocio es fundamental para su

correcto funcionamiento, los sistemas de ventas vienen a automatizar el proceso de
salida y cobro de la mercancía en los negocios, la correcta implementación de estos
sistemas da buenos resultados, en la actualidad estos sistemas no son un lujo, sino
una necesidad primordial para agilizar los procesos en los que están relacionadas las
salidas de mercancía en los establecimientos.

El presente proyecto se desarrolló porque existía un problema de sistematización en el

manejo de la información de las ventas generadas por el negocio de “Ropa y
Novedades Gris”. Ya que existían la necesidad de llevar un control sobre el inventario,
así como los estados del capital generado por las ventas, de igual manera en el
sistema de apartados, con estas acciones se pretende realizar las tareas para volver a
resurtir de una manera apropiada los productos que se van agotando esto de manera
efectiva. Se desarrollara una interfaz basada en un punto de venta.

Hoy en día se realizan las ventas sin la utilización de un sistema, solo se toman las
ventas en notas dentro de una libreta, tampoco se cuenta con un sistema de inventario.
De igual manera no se cuenta con un equipo de cómputo que pueda reproducir o
ejecutar el sistema que se pretende desarrollar, este es un punto a considerar más
adelante.

De esta manera se impulsó al dueño a que hiciera uso de las tecnologías de la

información. Generando así un nuevo nivel de gestión de su negocio y así mismo
optimizando el manejo de información con un nuevo enfoque más tecnológico.

1.2 DEFINICIÓN DEL PROBLEMA

Ropa y Novedades Gris hasta la fecha ha realizado sus operaciones de ventas por
medio de notas, así como los registros de apartados, para todas sus ventas o
apartados, esto genera un problema de tiempo, así como un descontrol en las finanzas
del negocio, confusión de los productos apartados, como el estado de esas cuentas, de
igual manera al no llevar un control de inventario los productos se agotan, lo cual
dificulta su reposición inmediata o anticipada, todo esto en general representa pérdidas
económicas en ventas y productos del negocio.
El sistema de apartado no están eficiente ya que al no llevar los registros de manera
segura pueden perderse o traspapelarse, o el producto apartado puede ser vendido en
algún momento, y no contar con el cuándo el cliente liquide el apartado.

Con la creación del sistema se pretende erradicar estos problemas, para así facilitar el
manejo de las cuentas e inventarios del negocio, permitiendo llevar la administración de
una manera correcta.

1.3 JUSTIFICACIÓN

Se pretende con el desarrollo de esta aplicación solucione los problemas derivados de

una malo manejo de las ventas, de manera que contemple las normas de calidad, que
al tipo de sistema se le puedan aplicar. Además de ayudar en el control de inventarios,
que ayudara de una manera importante al stok que cuenta el negocio, ya que el
sistema avisara con tiempo que las unidades o productos determinados se están
agotando y así poder sustituir de manera anticipada tal producto.

Esto ayuda de manera importante al incremento de las ventas del negocio ya que el
producto siempre estará disponible para ser vendido. Con esto no se perderán ventas
por falta de producto.

En la parte del registro de ventas permitirá que los registros derivados de las ventas
cuenten con un folio único, fecha de venta, etc. Que ayudaran a conocer las ventas
realizadas en determinada fecha, además estos registros solo podrán ser visualizados
por el administrador, lo cual le da más seguridad al sistema, la información generada
será guardado en una base de datos.

En la parte del sistema de apartados, se mejorara el control de los pagos y las fechas
en las cuales el producto fue apartado, esto ayudara en gran medida que los estados
de cuentas estén siempre disponibles para su liquidación. Y el producto esté disponible
para su entrega.

1.4 OBJETIVOS

1.4.1 OBJETIVO GENERAL

Realizar un sistema que dé solución a los problemas en las operaciones de ventas y
control de inventarios del negocio. Para aumentar las ventas del negocio.

1.4.2 OBJETIVOS ESPECÍFICOS

 Control de las ventas de productos, por medio de registros de ventas.

 Control de inventario de los productos, de manera de detectar la falta de
productos y poder resurtir en tiempo y forma.
 Implementación de una interfaz amigable con el usuario, y de fácil manipulación.
 Contar con una parte para la administración de los productos y registros
realizados por concepto de ventas.
 Contar con usuarios Administrador, que tenga acceso a los registros de las
ventas y al inventario, usuario Vendedor, el cual solo pueden vender y no tiene
acceso a la parte administrativa.
 Almacenar los datos en una base de datos.

1.5 Hipótesis

Con este sistema se pretenderá minimizar el tiempo de recolección de datos, los cuales
son necesarios para llevar una administración del manejo de las ventas en el local
donde se encuentra.

1.6 Alcances del proyecto

El proyecto desarrollado administrara y gestionara la información, de los clientes, las

ventas que se realicen y así también un mayor control del inventario que estará alojado
en una base de datos, dando como consecuencia una gran reducción del tiempo al
realizar dichas tareas.

1.7 Limitaciones del proyecto

La limitación más importante del sistema desarrollado es no contar con el sistema de
cómputo con los requerimientos necesarios en donde se implementaría el servidor de
la base de datos la cual se enlazaría con el sistema instalado en la misma
computadora.
1.8.1 Viabilidad económica: estudio de costo-beneficio

Las características necesarias para el correcto funcionamiento del sistema, en cuanto a

hardware y software, además de las características que son necesarias en cuanto
servicio de energía eléctrica, como medidas de seguridad necesarias para el equipo.
El negocio no cuenta con equipo propio, de tal modo que se invertirá por vez primera y
no es necesario actualización ni reposición de piezas. Lo cual debe de tener en cuenta
estos aspectos, ante el costo que se presentara a continuación en forma de análisis
costo-beneficio.

Cantidad Producto Costo Beneficio

1 Computadora Computadora necesaria

Procesador Dual-Core 3.0 Ghz. para la correcto
Memoria Ram funcionamiento del
DRR3 1333 Ghz. 4gb
sistema de venta, además
Unidad de DVD-CD $ 5320.00
300 Gb. Disco duro de ser utilizada para el
Teclado y raton estándar sistema tendrá un
Monitor LCD 17” Salida Estandar beneficio para el negocio
por la actualización.

2 Lector de Código de Barras Realizara las acciones de

entrada del código de
manera directa, lo cual no
$ 1450.00
ocasionara problemas por
equivocación de los
códigos.

Servicios

Energía eléctrica: Comisión Federal de Electricidad. $700 mensuales.

Servicio de Internet: Telmex o Telecable. $399 mensuales.

*El anterior análisis muestra los costos aproximados, ya que no se garantiza las cantidades
presenten el mismo valor al realizar el proyecto.

Las características del hardware son las recomendadas o estimadas para un óptimo
funcionamiento del sistema y que este no cause problemas, de tal manera que si se pueden
estimar más recursos en cuanto a un equipo con características superiores, representara un
mayor costo, pero de igual manera será un mayor beneficio, por la calidad del producto será
más alta y de mayor tecnología.
1.8.2 Viabilidad técnica y operativa: Análisis del entorno

Gastos de Operación

Se presenta el siguiente análisis del entorno:

PRESUPUESTO 2014
PARTIDA MONTO JUSTIFICACIÓN
SOLICITADO

2101 Materiales y útiles de oficina $ 368.00 Pape, lápices, carpetas, grapadora,

plumas, marcadores, clips, post it, cagas
de archivos. Gasto por mes.

2102 Material de limpieza $ 545.00 Detergentes, Aromatizante, Pinol,

Cloro, trapeadores, escobas,
aspiradora, limpia vidrios. Gasto por
mes.

2105 Materiales y útiles de impresión $ 1300.00 Copiadora, impresora laser, escáner. O

y reproducción multifuncional.

2106 Materiales y útiles para el $ 5000.00 Computadoras, Reguladores, pilas de

procesamiento en equipos y emergencia, teclados, ratones,
bienes informáticos monitores,

2107 Material para información $ 490.00 Cd´s, discos duros portables. Gasto por
mes.

2203 Productos alimenticios para el $ 600.00 Café, galletas, agua, comidas rápidas.
personal que realiza labores en
campo o de supervisión

2302 Refacciones y accesorios para $ 550.00 Cargadores para laptops, fuentes de

equipo de cómputo poder, discos duros, monitores,
reguladores.

2505 Materiales, accesorios y $ 100.00 Botiquín de primeros auxilios.

suministros médicos

TOTAL CAPÍTULO 2000 $ 8353.00

3103 Servicio telefónico $ 399.00 Renta de servicio telefónico. Gasto

convencional mensual.
3304 Otras asesorías para la $ 1000.00 Cursos de actualización o capacitación
operación de programas sobre nuevas herramientas.

3502 Mantenimiento y conservación $ 560.00 Material de limpieza de equipo, renta

de bienes informáticos de servicio de redes. Gasto mensual.

TOTAL CAPÍTULO 3000 $ 1959.00

 2.1 Antecedentes de la arquitectura

Introducción

La arquitectura de software es muy importante como disciplina ya que debido a que los
sistemas de software crecen a un ritmo muy acelerado que resulta muy complicado que
sean diseñados, especificados e intuitivos para un individuo. Unos de los aspectos que
motivan al estudio en este campo es el factor humano, la comunicación a alto nivel
entre los miembros del equipo de desarrollo es la reutilización de componentes y
comparación a alto nivel de diseños alternativos.

En el proceso de desarrollo se pueden aplicar diversos enfoques para garantizar el

cumplimiento de los requerimientos arquitectónicos, así como la evaluación de las
alternativas presentadas. La evaluación provee indicadores que permiten, en las fases
tempranas, la oportunidad de resolver problemas que pueden presentarse a nivel
arquitectónico.
La Arquitectura de Software es la organización fundamental de un sistema encarnada
en sus componentes, las relaciones entre ellos y el ambiente y los principios que
orientan su diseño y evolución.
El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes.
Tal como se muestra en la Figura 1.1, cada vista se refiere a un conjunto de intereses
de diferentes stakeholders del sistema.
• La vista lógica describe el modelo de objetos del diseño cuando se usa un método de
diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se
puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal
como diagramas de entidad-relación.
• La vista de procesos describe los aspectos de concurrencia y sincronización del
diseño.
• La vista física describe el mapeo del software en el hardware y refleja los aspectos de
distribución.
• La vista de desarrollo describe la organización estática del software en su ambiente
de desarrollo.
 Arquitectura del software (Elementos, Formas, Motivación/Restricciones)
Las vistas están definidas en un conjunto de elementos s (componentes, contenedores
y conectores), captamos la forma y los patrones con los que se trabaja, enseguida
captamos la justificación y sus restricciones, relacionando la arquitectura con algunos
de sus requisitos.
Cada vista se describe en lo que llamamos “diagrama” estos usan su notación
particular. Los arquitectos también pueden usar estilos de arquitectura para cada vista,
y por lo tanto hacer que coexistan distintos estilos en un mismo sistema
La arquitectura del software se trata de abstracciones, de descomposición y
composición, de estilos y estética. También tiene relación con el diseño y la
implementación de la estructura de alto nivel del software.
Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos
elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos
de funcionalidad y performance (desempeño) del sistema, así como también otros
requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y
disponibilidad del sistema.

La Arquitectura Lógica
La arquitectura lógica apoya principalmente los requisitos funcionales, lo que el sistema
debe brindar en términos de servicios a sus usuarios. Este sistema se descompone en
una serie de abstracciones clave, tomadas (principalmente) del dominio del problema
en la forma de objetos o clases de objetos.
Aquí se aplicanlos principios de abstracción, encapsulamiento y herencia. Esta
descomposición no sólo se hace para potenciar el análisis funcional, sino también sirve
para identificar mecanismos y elementos de diseño comunes a diversas partes del
sistema.

La Vista de Procesos
La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales
como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y
distribución, integridad del sistema, de tolerancia a fallas. La vista de procesos también
específica en cuál hilo de control se ejecuta efectivamente una operación de una clase
identificada en la vista lógica. Un proceso es una agrupación de tareas que forman una
unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos
puede ser controlada tácticamente (comenzar, recuperar, reconfigurar, y detener. El
software se particiona en un conjunto de tareas independientes: hilo de control
separado que puede planificarse para su ejecución independiente en un nodo de
procesamiento. Podemos entonces distinguir:
• Tareas mayores son elementos arquitectónicos que pueden ser manejados en forma
univoca. Se comunican a través de un conjunto bien definido de mecanismos de
comunicación inter-tarea: servicios de comunicación síncrona y asincrónica basados en
mensajes, llamados a procedimientos remotos, difusión de eventos, etc.
• Tareas menores son tareas adicionales introducidas localmente por motivos de
implementación tales como actividades cíclicas, almacenamiento en un buffer, time-out,
etc.). Pueden implementarse en Ada por ejemplo, o como hilos de control liviano
(threads). Pueden comunicarse mediante rendezvous o memoria compartida.

Vista de Desarrollo
La vista de desarrollo se centra en la organización real de los módulos de software en
el ambiente de desarrollo del software. El software se empaqueta en partes pequeñas –
bibliotecas de programas o subsistemas– que pueden ser desarrollados por uno o un
grupo pequeño de desarrolladores. Los subsistemas se organizan en una jerarquía de
capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las
capas superiores.
La vista de desarrollo apoya la asignación de requisitos y trabajo al equipo de
desarrollo, y apoya la evaluación de costos, la planificación, el monitoreo de progreso
del proyecto, y también como base para analizar reusó, portabilidad y seguridad. Es la
base para establecer una línea de productos. La vista de desarrollo de un sistema se
representa en diagramas de módulos o subsistemas que muestran las relaciones
exporta e importa.
 Escenarios
Todas las partes juntas Los elementos de las cuatro vistas trabajan conjuntamente en
forma natural mediante el uso de un conjunto pequeño de escenarios relevantes –
instancias de casos de uso más generales– para los cuales describimos sus scripts
correspondientes (secuencias de interacciones entre objetos y entre procesos. Los
escenarios son de alguna manera una abstracción de los requisitos más importantes.
Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de
interacción de objetos.

En conclusión no toda arquitectura de software requiere las “4+1” vistas completas. Las
vistas que no son útiles pueden omitirse de la descripción de arquitectura, tales como la
vista física si hay un único procesador, y la vista de procesos si existe un solo proceso
o programa. Para sistemas muy pequeños, es posible que las vistas lógica y de
desarrollo sean tan similares que no requieran descripciones independientes. Los
escenarios son útiles en todas las circunstancias.

2.2 Estado del arte

La estimación del software y otras carreras paralelas al desarrollo de software, es una

de las actividades menos deseadas por el equipo de desarrollo del proyecto, así como
la más “pesada” de llevar a cabo. De una forma muy parecida a lo que ocurre en la
práctica de una actividad deportiva, en la que para mejorar es necesario actividades
muy agotadoras y poco gratificantes como el trabajo con pesas etc., el desarrollo de
proyectos de software es necesario tareas similares, pero que son necesarias para
conseguir que el comportamiento de una organización evolucione y mejorar con el
tiempo de forma que su capacidad de desarrollo, así como la calidad en el trabajo
realizado, etc. Sean cada vez más eficientes.
Actualmente, las empresas tienen conocimiento amplio en este aspecto, mientras los
estándares proclaman la existencia de sus métodos de estimación, planificación y
gestión de proyectos, estos son reducidos en una planificación de los recursos en
función del negocio, es decir, de lo que se supone que el cliente puede llegar a pagar
por un servicio prestado. Después entran otros aspectos menos importantes, pero no
por ello perjudícales, que redundan en la mala planificación y gestión de los proyectos
de desarrollo de aplicaciones.
 2.2.1 Descripción de requerimientos
Los requerimientos son declaraciones que identifican atributos, capacidades,
características y/o cualidades que necesita cumplir un sistema (o un sistema de
software) para que tenga valor y utilidad para el usuario. En otras palabras, los
requerimientos muestran qué elementos y funciones son necesarias para un proyecto.
En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los
requerimientos viene antecedida de la etapa de factibilidad del sistema/software y
precedida por la etapa de diseño del sistema/software.

Etapas de la fase de requerimientos

* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los
grupos de interés.
* Análisis: comprobación de la consistencia y completitud de los requerimientos.
* Verificación: constatación de que los requerimientos especificados son correctos.

Clasificación de los requerimientos

* Requerimientos funcionales: qué debe hacer el sistema o software.
* Requerimientos no funcionales: cómo debe funcionar el sistema o software (no su
implementación), por ej. Calidad, rendimiento, facilidad de uso, etc.
* Requerimientos externos: a qué se debe atener el sistema o software con respecto a
su entorno: compatibilidad con otros sistemas, adecuación a determinadas leyes, etc.

Características que deberían cumplir los requerimientos

* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.
* Cohesión: el requerimiento debe dirigirse a solo una única cosa.
* Completo: el requerimiento debe estar completamente declarado en un único lugar,
sin información faltante.
* Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe
ser completamente consistente con toda la documentación.
* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los
interesados en el sistema/software.
* Factible/viable: el requerimiento debe poder ser implementado.
* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar
hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única
manera.
* Obligatorio: el requerimiento debe representar una característica definida por el grupo
interesado en el desarrollo del sistema/software, su ausencia no puede ser
reemplazada.
* Observable externamente: el requerimiento debe especificar una característica
observable externa o experimentable por el usuario del producto.
* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta
en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.

2.2.1.1 Descripción de procesos

Un Proceso de negocio es un conjunto de tareas relacionadas lógicamente, llevadas a

cabo para generar productos y servicios. Los procesos reciben insumos para
transformarlos utilizando recursos de la empresa. Los procesos de negocio
normalmente atraviesan varias áreas funcionales.
En la serie de normas internacionales ISO 9000 ("Sistemas de Gestión de la Calidad")
se define un proceso como “conjunto de actividades mutuamente relacionadas o que
interactúan, las cuales transforman elementos de entrada en resultados” (ISO
9000:2005; pp. 7). Oscar Barros hace una importante distinción, al introducir el
concepto de valor agregado en la definición de proceso, señalando que “un proceso es
un conjunto de tareas lógicamente relacionadas que existen para conseguir un
resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le
agregan valor para producir una salida.
Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales
reciben a la salida, lo que puede ser un producto físico o un servicio. Éstos establecen
las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no”
(Barros, 1994; pp. 56). Thomas Davenport, uno de los pioneros de la reingeniería,
señala que un proceso, simplemente, es “un conjunto estructurado, medible de
actividades diseñadas para producir un producto especificado, para un cliente o
mercado específico. Implica un fuerte énfasis en CÓMO se ejecuta el trabajo dentro de
la organización, en contraste con el énfasis en el QUÉ, característico de la focalización
en el producto” (Davenport, 1993; pp. 5).
 Tipos

Procesos estratégicos - Estos procesos dan orientación al negocio. Por ejemplo,

"Planeación estratégica"
Procesos sustantivos, clave o de generación de valor - Estos procesos dan el valor al
cliente, son la parte principal del negocio. Por ejemplo, "Entregar el paquete" (empresa
de paquetería y mensajería); "Preparar la comida y servirla" (restaurante); "Transportar
al viajero" (aerolínea)
Procesos de apoyo vertical u horizontal - Estos procesos dan soporte a los procesos
centrales. Por ejemplo, "Contratar personal", "Dar soporte/servicio técnico".
Acorde a la filosofía planteada en el libro "Sistema Empresa Inteligente" los procesos
se dividen en: Procesos sustantivos, procesos de apoyo vertical y procesos de apoyo
horizontal.
Componentes
Un proceso se puede dividir en subprocesos, éstos en actividades y éstas a su vez en
tareas, siendo las tareas las acciones más simples como firmar un cheque o talón.
Algunos autores invierten el sentido y establecen que las tareas son las que se dividen
en actividades.
2.2 Estado del arte

La estimación del software y otras carreras paralelas al desarrollo de software, es una

de las actividades menos deseadas por el equipo de desarrollo del proyecto, así como
la más “pesada” de llevar a cabo. De una forma muy parecida a lo que ocurre en la
práctica de una actividad deportiva, en la que para mejorar es necesario actividades
muy agotadoras y poco gratificantes como el trabajo con pesas etc., el desarrollo de
proyectos de software es necesario tareas similares, pero que son necesarias para
conseguir que el comportamiento de una organización evolucione y mejorar con el
tiempo de forma que su capacidad de desarrollo, así como la calidad en el trabajo
realizado, etc. Sean cada vez más eficientes.
Actualmente, las empresas tienen conocimiento amplio en este aspecto, mientras los
estándares proclaman la existencia de sus métodos de estimación, planificación y
gestión de proyectos, estos son reducidos en una planificación de los recursos en
función del negocio, es decir, de lo que se supone que el cliente puede llegar a pagar
por un servicio prestado. Después entran otros aspectos menos importantes, pero no
por ello perjudícales, que redundan en la mala planificación y gestión de los proyectos
de desarrollo de aplicaciones.
 2.2.1 Descripción de requerimientos
Los requerimientos son declaraciones que identifican atributos, capacidades,
características y/o cualidades que necesita cumplir un sistema (o un sistema de
software) para que tenga valor y utilidad para el usuario. En otras palabras, los
requerimientos muestran qué elementos y funciones son necesarias para un proyecto.
En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los
requerimientos viene antecedida de la etapa de factibilidad del sistema/software y
precedida por la etapa de diseño del sistema/software.

Etapas de la fase de requerimientos

* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los
grupos de interés.
* Análisis: comprobación de la consistencia y completitud de los requerimientos.
* Verificación: constatación de que los requerimientos especificados son correctos.

Clasificación de los requerimientos

* Requerimientos funcionales: qué debe hacer el sistema o software.
* Requerimientos no funcionales: cómo debe funcionar el sistema o software (no su
implementación), por ej. Calidad, rendimiento, facilidad de uso, etc.
* Requerimientos externos: a qué se debe atener el sistema o software con respecto a
su entorno: compatibilidad con otros sistemas, adecuación a determinadas leyes, etc.

Características que deberían cumplir los requerimientos

* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.
* Cohesión: el requerimiento debe dirigirse a solo una única cosa.
* Completo: el requerimiento debe estar completamente declarado en un único lugar,
sin información faltante.
 * Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe
ser completamente consistente con toda la documentación.
* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los
interesados en el sistema/software.
* Factible/viable: el requerimiento debe poder ser implementado.
* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar
hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única
manera.
* Obligatorio: el requerimiento debe representar una característica definida por el grupo
interesado en el desarrollo del sistema/software, su ausencia no puede ser
reemplazada.
* Observable externamente: el requerimiento debe especificar una característica
observable externa o experimentable por el usuario del producto.
* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta
en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.

2.2.1.1 Descripción de procesos

Un Proceso de negocio es un conjunto de tareas relacionadas lógicamente, llevadas a

cabo para generar productos y servicios. Los procesos reciben insumos para
transformarlos utilizando recursos de la empresa. Los procesos de negocio
normalmente atraviesan varias áreas funcionales.
En la serie de normas internacionales ISO 9000 ("Sistemas de Gestión de la Calidad")
se define un proceso como “conjunto de actividades mutuamente relacionadas o que
interactúan, las cuales transforman elementos de entrada en resultados” (ISO
9000:2005; pp. 7). Oscar Barros hace una importante distinción, al introducir el
concepto de valor agregado en la definición de proceso, señalando que “un proceso es
un conjunto de tareas lógicamente relacionadas que existen para conseguir un
resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le
agregan valor para producir una salida.
Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales
reciben a la salida, lo que puede ser un producto físico o un servicio. Éstos establecen
las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no”
(Barros, 1994; pp. 56). Thomas Davenport, uno de los pioneros de la reingeniería,
señala que un proceso, simplemente, es “un conjunto estructurado, medible de
actividades diseñadas para producir un producto especificado, para un cliente o
mercado específico. Implica un fuerte énfasis en CÓMO se ejecuta el trabajo dentro de
la organización, en contraste con el énfasis en el QUÉ, característico de la focalización
en el producto” (Davenport, 1993; pp. 5).

Tipos

Procesos estratégicos - Estos procesos dan orientación al negocio. Por ejemplo,

"Planeación estratégica"
Procesos sustantivos, clave o de generación de valor - Estos procesos dan el valor al
cliente, son la parte principal del negocio. Por ejemplo, "Entregar el paquete" (empresa
de paquetería y mensajería); "Preparar la comida y servirla" (restaurante); "Transportar
al viajero" (aerolínea)
Procesos de apoyo vertical u horizontal - Estos procesos dan soporte a los procesos
centrales. Por ejemplo, "Contratar personal", "Dar soporte/servicio técnico".
Acorde a la filosofía planteada en el libro "Sistema Empresa Inteligente" los procesos
se dividen en: Procesos sustantivos, procesos de apoyo vertical y procesos de apoyo
horizontal.

Componentes
Un proceso se puede dividir en subprocesos, éstos en actividades y éstas a su vez en
tareas, siendo las tareas las acciones más simples como firmar un cheque o talón.
Algunos autores invierten el sentido y establecen que las tareas son las que se dividen
en actividades.
2.2.1.2 De los usuarios (actores involucrados)

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más
de un tipo de usuario, los analistas de requisitos han de tomar en consideración a
todos los implicados para que se obtengan y depuren sus requerimientos de la
forma más fidedigna posible.

Realmente, son muchas las personas involucradas en el desarrollo de los

requerimientos de un sistema. Es importante saber que cada una de esas
personas tienen diversos intereses y juegan roles específicos dentro de la
planificación del proyecto; el conocimiento de cada papel desempeñado, asegura
que se involucren a las personas correctas en las diferentes fases del ciclo de
vida, y en las diferentes actividades de la IR.
No conocer estos intereses puede ocasionar una comunicación poco efectiva
entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en
tiempo como en presupuesto.

Los roles más importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están
familiarizados con los procesos específicos que debe realizar el software, dentro
de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y
los manuales de usuario.

Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el
dominio del problema en donde será empleado el software desarrollado. Ellos
proporcionan al equipo técnico los detalles y requerimientos de las interfaces del
sistema.

Personal de Mantenimiento: Para proyectos que requieran un mantenimiento

eventual, estas personas son las responsables de la administración de cambios,
de la implementación y resolución de anomalías. Su trabajo consiste en revisar y
mejorar los procesos del producto ya finalizado.Analistas y programadores: Son los
responsables del desarrollo del producto en
sí; ellos interactúan directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas

para asegurar que las condiciones presentadas por el sistema son las adecuadas.
Son quienes van a validar si los requerimientos satisfacen las necesidades del
cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del
proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores
de base de datos, entre otros.

Problemas relacionados con los actores involucrados

Las vías que pueden dificultar la determinación de los requisitos se presentan a
continuación:
Relacionados con los usuarios.

 Los usuarios no tiene claro lo que desean

 Los usuarios no se involucran en la elaboración de requisitos escritos
 Los usuarios insisten en nuevos requisitos después de que el coste y la
 programación se hayan fijado.
 La comunicación con los usuarios es lenta
 Los usuarios no participan en revisiones o son incapaces de hacerlo.
  Los usuarios no comprenden los problemas técnicos
 Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor cambian,
incluso cuando el desarrollo del producto ya está en marcha.

Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante análisis de
requisitos son:

-El personal técnico y los usuarios finales pueden tener diversos

vocabularios y pueden llegar a creer incorrectamente que están de acuerdo,
no dándose cuenta del desacuerdo hasta que se provee el producto final.

-Los desarrolladores pueden intentar encajar el sistema en un modelo

existente, en vez de desarrollar un sistema adaptado a las necesidades del
cliente.

-El análisis de requisitos se puede realizar a menudo por los ingenieros o

programadores, en vez de personal con las dominio habilidades de relación
con la gente y el conocimiento del para entender las necesidades de un
cliente correctamente.

2.2.1.3 Para la gestión, negociación y análisis

Durante las dos pasadas décadas, se han desarrollado un gran número de métodosde
modelado. Los investigadores han identificado los problemas del análisis y sus causas
y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de
heurísticas para solucionarlos. Cada método de análisis tiene su punto de vista. Sin
embargo, todos los métodos de análisis se relacionan por un conjunto de principios
operativos:

1. Debe representarse y entenderse el dominio de información de un problema.

2. Deben definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software (como consecuencia de

acontecimientos externos).

4. Deben dividirse los modelos que representan información, función y comportamiento

de manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle dela
implementación.

Aplicando estos principios, el analista se aproxima al problema sistemáticamente. Se

examina el dominio de información de manera que pueda entenderse completamente la
función. Se emplean modelos para poder comunicar de forma compacta las
características de la función y su comportamiento. Se aplica la partición para reducir la
complejidad.
Son necesarias las visiones esenciales y de implementación del software para
acomodar las restricciones lógicas impuestas por los requisitos del procesamiento y las
restricciones físicas impuestas por otros elementos del sistema. Además de los
principios operativos de análisis mencionados anteriormente, Davis sugiere un conjunto
de 6 principios directrices para la «ingeniería de requisitos»:

•Entender el problema antes de empezar a crear el modelo de análisis. Hay tendencia a

precipitarse en busca de una solución, incluso antes de entender el problema. ¡Esto
lleva a menudo a un elegante software para el problema equivocado!
•Desarrollar prototipos que permitan al usuario entender cómo será la interacción
hombre-máquina. Como el concepto de calidad del software se basa a menudo en la
opinión sobre la «amigabilidad» de la interfaz, el desarrollo de prototipos (y la iteración
que se produce) es altamente recomendable.

•Registrar el origen y la razón de cada requisito. Este es el primer paso para establecer
un seguimiento hasta el cliente.

•Usar múltiples planteamientos de requisitos. La construcción de modelos de datos,

funcionales y de comportamiento, le proporcionan al ingeniero del software tres puntos
de vista diferentes. Esto reduce la probabilidad de que se olvide algo y aumenta la
probabilidad de reconocer la falta de consistencia.

•Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la
implementación de todos los requisitos del software. Si se aplica un modelo de proceso
incremental, se deben identificar los requisitos que se van a entregar en la primera
entrega.

•Trabajar- para eliminar la ambigüedad. Como la mayoría de los requisitos están

descritos en un lenguaje natural, abunda la oportunidad de ambigüedades. El empleo
de revisiones técnicas formales es una manera de descubrir y eliminar la ambigüedad

Estándar IEEE 830:

Las características de una buena especificación de requisitos de software (ERS) son

definidas por el estándar IEEE 830-1998. Una buena ERS debe ser:
 Completa. Todos los requerimientos deben estar reflejados en ella y todas las
referencias deben estar definidas.

 Consistente. Debe ser coherente con los propios requerimientos y también con
otros documentos de especificación.

 Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.

 Correcta. El software debe cumplir con los requisitos de la especificación.

 Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de

un ítem a través de su identificación almacenada y documentada.

 Priorizable. Los requisitos deben poder organizarse jerárquicamente según su

relevancia para el negocio y clasificándolos en esenciales, condicionales y
opcionales.

 Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser

fácilmente modificable.

 Verificable. Debe existir un método finito sin costo para poder probarlo.

2.2.2 Herramientas en el mercado para el manejo de Requerimientos.

Existen diferentes herramientas que se utilizan para llevar a cabo las fases de la
ingeniería de requerimientos. Sin embargo, estas herramientas no son restrictivas para
una única actividad dentro de este gran proceso

Herramientas que se utilizan para las diferentes fases de la ingeniería de

requerimientos:
También existen herramientas de software que facilitan la realización de cada una de
esas actividades:

Características de las herramientas de Administración de requerimientos más

utilizadas:
Lista de herramientas seleccionadas como las más utilizadas por las empresas de
E.E.U.U

2.2.3 Análisis de Riesgo.

El análisis de riesgo, también conocido como evaluación de riesgo o PHA por sus
siglas en inglés Process Hazards Analysis, es el estudio de las causas de las
posibles amenazas y probables eventos no deseados y los daños y consecuencias que
éstas puedan producir.
Este tipo de análisis es ampliamente utilizado como herramienta de gestión en estudios
financieros y de seguridad para identificar riesgos (métodos cualitativos) y otras para
evaluar riesgos (generalmente de naturaleza cuantitativa).

El análisis del riesgo es un método sistemático de recopilación, evaluación, registro y

difusión de información necesaria para formular recomendaciones orientadas a la
adopción de una posición o medidas en respuesta a un peligro determinado. Hay
pequeñas variaciones en la terminología utilizada por las tres organizaciones. Sin
embargo, las tres organizaciones hermanas consideran el análisis del riesgo como un
proceso que consta de cuatro etapas:

 identificación del peligro;

 evaluación del riesgo;
 gestión del riesgo; y
 comunicación del riesgo.

La identificación del peligro consiste en especificar el acontecimiento adverso que es

motivo de preocupación.

En la evaluación del riesgo se tiene en cuenta la probabilidad (la probabilidad real y no

sólo la posibilidad) de que se produzca el peligro, las consecuencias si ocurre y el
grado de incertidumbre que supone. (Obsérvese que esta descripción de la evaluación
del riesgo es diferente de la definición que figura en el Acuerdo MSF.)

La gestión del riesgo consiste en la identificación y aplicación de la mejor opción para

reducir o eliminar la probabilidad de que se produzca el peligro.

La comunicación del riesgo consiste en el intercambio abierto de información y

opiniones aclaratorias que llevan a una mejor comprensión y adopción de decisiones.

El procedimiento general para la elaboración del análisis de riesgo se enmarca en:

2.2.3.1 Diferentes Metodologías de análisis de riesgo.
Existen diversas metodologías para desarrollar los análisis de riesgos, la selección de
la metodología más apropiada en cada caso depende de la disponibilidad de
información y el nivel de detalle que se desee alcanzar.

1. Metodología de análisis preliminar de riesgos (Método APELL):

Señala los principales aspectos que deben considerarse para establecer el análisis
preliminar de riesgos, integrando de manera articulada elementos de salud, ambiente y
riesgo industrial, para lo cual se divide en cuatro partes cada una con peso dentro de la
evaluación total:

1. Matriz de riesgos: 40 %.

2. Elementos de gestión en seguridad, salud y ambiente: 20 %.

3. Aspectos ambientales: 20 %.

4. Otras características: 20 %.

La metodología adoptada se basa en el Programa de Concientización y Preparación

para Emergencias a Nivel Local (APELL) el cual fue dado a conocer en 1988 por el
Centro de Actividades del Programa de Industria y Medio Ambiente (UNEP IE/PAC) del
Programa de las Naciones Unidas. Con ésta metodología se pretende obtener un
análisis primario que permita conocer de manera general y anticipada los principales
riesgos, siendo indicado para Organizaciones de carácter eminentemente industrial,
Industrias químicas, Empresas petroleras, Industrias, Instalaciones u Organizaciones
en general cuya actividad pueda producir daños medioambientales o para la seguridad
de las personas.

2. Metodología de análisis y estrategias para el Control del Riesgo

La metodología presentada a continuación permite parametrizar el análisis de un riesgo

de modo muy completo, considerando las Amenazas que representan los riesgos, la
Probabilidad y Consecuencias del Riesgo, la Vulnerabilidad de las personas, bienes,
medio ambiente, infraestructuras y operaciones, así como las Estrategias para el
Control del Riesgo.

Esta metodología permite aplicarse a edificios y actividades de cualquier naturaleza,

aunque estaría más indicado para edificios o actividades que no tengan una gran
ocupación o personal en sus instalaciones, como por ejemplo Comercios,
Restaurantes, Hoteles de pocas habitaciones, Residenciales, etc.

3. Metodología de matriz DOFA.

La matriz DOFA (conocido por algunos como DAFO y SWOT en inglés) es una
herramienta de gran utilidad para entender y tomar decisiones en toda clase de
situaciones. DOFA es el acrónimo de Debilidades, Oportunidades, Fortalezas y
Amenazas, encabezados de una matriz que proveen un buen marco de referencia para
analizar por ejemplo los riesgos de una empresa.

Completar la matriz es sencillo, y resulta apropiada para reportes de investigación de

los riesgos y amenazas en una Organización. El análisis DOFA es una evaluación
subjetiva que ayuda a comprender, presentar, discutir y tomar decisiones. Puede ser
utilizado en cualquier tipo de toma de decisiones, ya que la plantilla estimula a pensar
pro-activamente.

La metodología adoptada permite analizar en con meticulosidad y en profundidad los

riesgos y amenazas de una Organización, siendo por tanto muy indicada para edificios
críticos como Hospitales, Laboratorios, Centros de Salud, etc.

4. Metodología de matriz de riesgos.

Señala los principales aspectos que deben considerarse para establecer el análisis
preliminar de riesgos, pero no contempla elementos de salud, ambiente y riesgo
industrial. La metodología adoptada se basa en una parte concreta del Programa de
Concientización y Preparación para Emergencias a Nivel Local (APELL), siendo
indicada la aplicación de este método en Organizaciones, Empresas, Industrias e
Instalaciones cuya actividad no origina riesgos medioambientales, como
Organizaciones administrativas, Centros Comerciales, Galerías Comerciales, Edificios
Comerciales, Comercios de cualquier naturaleza, Centros de Enseñanza,
Universidades, Oficinas, Hoteles, Hospitales, etc.

5. Metodología de análisis de riesgos por colores.

La metodología de análisis de riesgos por colores, de una forma general y cualitativa
permite desarrollar el análisis de amenaza y vulnerabilidad a personas, recursos,
sistemas y procesos, con el fin de determinar el nivel de riesgo a través de la
combinación de variables con códigos de colores.

Asimismo, aporta elementos de prevención y mitigación de los riesgos y atención

efectiva de los eventos que la organización, establecimiento o actividad pueda generar,
los cuales constituirán la base para formular los planes de acción. Se trata de una
metodología muy visual, siendo indicada en Organizaciones, Empresas, Industrias e
Instalaciones de todo tipo, como Organizaciones administrativas, Centros Comerciales,
Galerías Comerciales, Edificios Comerciales, Comercios de cualquier naturaleza,
Centros de Enseñanza, Universidades, Oficinas, etc.

2.2.4 Aseguramiento de la Calidad (Calidad en los procesos).

Según la norma ISO 9000:2000, el aseguramiento de la calidad es la parte de la

gestión de la calidad orientada a proporcionar confianza en que se cumplirán los
requisitos de calidad.

El Aseguramiento de la Calidad del Software es el conjunto de actividades, planificadas

y sistemáticas necesarias para aportar la confianza que el software satisfará los
requisitos dados de calidad. Este aseguramiento se diseña para cada aplicación antes
de comenzar a desarrollarla y no después. El Aseguramiento de la Calidad del
Software engloba:

 Un enfoque de gestión de calidad.

 Métodos y herramientas de Ingeniería del Software.
 Revisiones técnicas formales en el proceso del software.
 Una estrategia de prueba multiescala.
 El control de la documentación del software y de los cambios realizados.
 Procedimientos para ajustarse a los estándares de desarrollo del software.
 Mecanismos de medición y de generación de informes.

Las revisiones del software son un "filtro" para el proceso de Ingeniería del Software.
Esto es, las revisiones se aplican a varios momentos del desarrollo del software y
sirven para detectar errores y defectos que pueden ser eliminados. La revisión técnica
formal (RTF), a veces llamada inspección, es el filtro más efectivo desde el punto de
viste del aseguramiento de la calidad y es un medio efectivo para mejorar la calidad del
software.

El defecto se define como una anomalía del producto. Dentro del contexto del proceso
del software, los términos defecto y fallo son sinónimos.

Las actividades de diseño introducen entre el 50 y 65% de todos los errores durante el
proceso de software. Sin embargo, se ha demostrado que las RTF son efectivas en un
75% a la hora de detectar errores. Con la detección y la eliminación de un gran
porcentaje de errores, el proceso de revisión reduce substancialmente el coste de los
pasos siguientes en las fases de desarrollo y mantenimiento.

La RTF promueve la seguridad y la continuidad, ya que varias personas se

familiarizarán con partes del software que, de una forma u otra, no hubieran visto
nunca. Es una clase de revisión que incluye recorridos, inspecciones, revisiones
cíclicas y otro pequeño grupo de evaluaciones técnicas del software. Cada RTF se
lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada
y atendida.

El aseguramiento de calidad se refiere a validar los procesos usados para crear los
productos. Es una herramienta especialmente útil para administradores y
patrocinadores, ya que permite discutir los procesos usados para determinar si los
productos creados son razonables. Este aseguramiento tiene asociado 2 constitutivos
diferentes:

1. Los ingenieros del Software que realizan el trabajo técnico.

2. Un grupo de SQA (Software Quality Assurance) que se responsabiliza en la
planificación de aseguramiento de la calidad, supervisión, mantenimiento de
registros, análisis e informes.

Las Actividades del grupo de SQA son:

 Establecimiento de un plan de SQA para un proyecto.

 Participación en el desarrollo de la descripción del proceso de software
del proyecto.
 Revisión de las actividades de Ingeniería del Software para verificar su ajuste al
proceso de software definido
 Auditoria de los productos de software designados para verificar el ajuste con los
definidos como parte del proceso del software.
  Asegurar que las desviaciones del trabajo y los productos del software se
documentan y se manejan de acuerdo con un procedimiento establecido.

2.2.4.1 Normas para la calidad en procesos: SQA, ISO/IEC 15939, 15504, 12207,
IEEE 1074

SQA:

Aseguramiento de la calidad del software (SQA) consiste en un medio de seguimiento

de los programas de ingeniería de procesos y métodos utilizados para asegurar la
calidad. [Los métodos por los cuales esto se logra son muchos y variados, y pueden
incluir la garantía de la conformidad con una o más normas, tales como ISO 9000 o un
modelo como CMMI .
SQA abarca todo el desarrollo de software de proceso, que incluye procesos tales
como la definición de requisitos, diseño de software , codificación , control de código
fuente ,revisiones de código , gestión de configuración de software , pruebas , gestión
de versiones , y la integración de productos. SQA está organizado en los objetivos,
compromisos, habilidades, actividades, medidas y verificaciones.

ISO/IEC 15939
ISO/IEC 15939:2007: Define un proceso de medición través de un modelo que define
las actividades y es adaptable, flexible a las necesidades de diferentes usuarios.

ISO / IEC 15939: 2007 define un proceso de medición aplicable al sistema y la

ingeniería de software y disciplinas de gestión. El proceso se describe a través de un
modelo que define las actividades del proceso de medición que se requieren para
especificar adecuadamente lo que la información de medición se requiere, cómo las
medidas y los resultados de los análisis se han de aplicar, y cómo determinar si los
resultados del análisis son válidas. El proceso de medición es flexible, tolerable, y
adaptable a las necesidades de diferentes usuarios.

ISO / IEC 15939: 2007 identifica un proceso que apoya la definición de un conjunto
adecuado de medidas que aborden las necesidades de información específica.
Identifica las actividades y tareas que son necesarias para identificar con éxito, definir,
seleccionar, aplicar y mejorar la medición dentro de un proyecto global o estructura
organizacional de medición. También proporciona definiciones de los términos de
medida de uso común dentro de las industrias de sistemas y software.
ISO/IEC 15504

ISO/IEC 15504:2004: Proporciona un marco para la evaluación y mejorar la capacidad

y madurez de los procesos. Se aplica junto ISO/OEC 12207, para evaluar y mejora de
la calidad del proceso de desarrollo y mantenimiento de software.

ISO / IEC 15504 proporciona un marco para la evaluación de los procesos. Este marco
puede ser utilizado por las organizaciones que participan en la planificación, la gestión,
el seguimiento, el control y la mejora de la adquisición, suministro, desarrollo,
operación, evolución y soporte de producto y servicios.
Los ISO / IEC 15504 modelos de evaluación de procesos publicados para sistemas y
software no ofrecen en la actualidad una base suficiente para la realización de una
evaluación de la capacidad de proceso de los procesos con respecto al desarrollo de
sistemas de seguridad complejos.

El desarrollo de los sistemas relacionados con la seguridad requiere de procesos

especializados, técnicas, habilidades y experiencia. Se necesitan amplificaciones de
proceso (de extensión de seguridad) en el área de gestión de la seguridad, ingeniería
de seguridad y requisitos de seguridad. ISO / IEC TS 15504-10: 2011 presenta estas
amplificaciones (una extensión de seguridad) como tres descripciones de procesos:
gestión de la seguridad, los procesos de ingeniería de seguridad y certificación de la
seguridad.

El objetivo de la norma ISO / IEC TS 15504-10: 2011 no es proporcionar una forma de

verificar el cumplimiento de una o más normas de seguridad específicas del dominio, ni
de ampliar la norma ISO / IEC 15504 con el fin de utilizarlo como una norma de
seguridad contra la que para verificar el cumplimiento. El objetivo es proporcionar a los
asesores con los medios y la información para la medición de la capacidad de los
procesos y también la definición de posibles acciones de mejora de procesos cuando el
software / sistema en desarrollo está relacionado con la seguridad necesarias.

ISO / IEC TS 15504-10: 2011, como un documento independiente, se puede utilizar en

conjunción con la norma ISO / IEC 15504-5 y / o ISO / IEC TR 15504-6 modelos de
evaluación de proceso por asesores experimentados, con un mínimo apoyo de
expertos en el dominio de seguridad.

ISO / IEC TS 15504-10: 2011 se desarrolló independiente de cualquier estándar de

seguridad específicas que definen los principios de seguridad, métodos, técnicas y
productos de trabajo. Sin embargo, los elementos de las normas de seguridad
pertinentes puedan ser asignada a la extensión de seguridad y la extensión de
seguridad se pretende que sea extensible para incluir requisitos específicos sobre
normas de seguridad.

La influencia de la extensión de la seguridad relativa a la evaluación de los procesos en

la norma ISO / IEC 15504-5 e ISO / IEC TR 15504-6 se describe en la norma ISO / IEC
TS 15504-10: 2011. Para cada proceso contenida en la norma ISO / IEC 15504-5 e ISO
/ IEC TR 15504-6, no es una indicación de problemas adicionales que deben tenerse
en cuenta en el momento de la evaluación. Los temas se proporcionan por medio de
frases que indican las relaciones específicas entre la norma ISO / IEC 15504-5 e ISO /
IEC TR 15504-6 procesos y la norma ISO / IEC TS 15504-10: 2011 los procesos, así
como destacando aspectos relevantes a tener en cuenta para mejorar la integridad de
la fase de recogida de datos de la evaluación. De esta manera, un evaluador puede
utilizar la norma ISO / IEC TS 15504-10: 2011 para comprobar si, en la evaluación de
una norma ISO / IEC 15504-5 o ISO / IEC TR 15504-6 proceso, algunos aspectos
relevantes relacionados con el entorno de desarrollo de la seguridad tiene que pasarlos
por alto

ISO/IEC 12207

ISO/IEC 12207:1995: Define los procesos del ciclo de vida del software.

Esta norma establece un marco común para los procesos del ciclo de vida del software,
con una terminología bien definida, que puede ser referenciada por la industria del
software. Se aplica a la adquisición de sistemas y productos de software y servicios,
para el suministro, desarrollo, operación, mantenimiento y eliminación de los productos
de software y la parte de software de un sistema, ya sea realizado internamente o
externamente a una organización. Se incluyen aquellos aspectos de la definición del
sistema necesario para proporcionar el contexto para los productos y servicios de
software. El software incluye la parte de software de firmware. Esta revisión se integra
la norma ISO / IEC 12207: 1995, con sus dos enmiendas y se coordinó con la revisión
paralela de 15288 ISO / IEC: (procesos del ciclo de vida del sistema) 2002 para alinear
la estructura, términos, y los correspondientes procesos de la organización y del
proyecto. Esta norma se puede usar independiente o conjuntamente con la norma ISO /
IEC 15288, y suministra un modelo de referencia de proceso que soporta la evaluación
de la capacidad del proceso de conformidad con la norma ISO / IEC 15504-2
(evaluación del proceso). En un anexo se ofrece soporte para los usuarios de IEEE y
describe las relaciones de esta norma a los estándares IEEE.
2.2.5 CONTROL DE CALIDAD EN EL PRODUCTO

La calidad es la estructura que organiza evaluaciones, inspecciones, auditorias y

revisiones que aseguren que se cumplan las responsabilidades asignadas, se utilicen
eficientemente los recursos y se logre el cumplimiento de los objetivos del producto.
Tiene la intención de mantener bajo control un proceso y eliminar las causas de los
defectos en las diferentes fases del ciclo de vida de un producto.

La calidad en el producto persigue los siguientes puntos que se detallan a continuación:

 Incrementar la productividad y satisfacción al trabajo de los profesionales

afines al campo de la computación.
 Mejorar la calidad del producto del software.
 Proveer técnicas aplicadas para automatizar el manejo de datos.
 Realizar una planeación eficaz de los sistemas.
 Documentar.
 Validar y controlar formalmente la calidad del trabajo realizado.
  Cumplir con los objetivos de la organización en cuanto a productividad de sus
sistemas de cómputo.

Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores
o criterios de medición. El software posee determinados índices medibles que son las
bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez
seleccionados los índices de calidad, debe establecerse el proceso de control, que
requiere los siguientes pasos:

1. Definir el software que va a ser controlado:

Clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los
estándares establecidos para el desarrollo del software.

2. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada
clase de software es necesario definir los indicadores y sus magnitudes.
3. Crear o determinar los métodos de valoración de los indicadores: métodos
manuales como cuestionarios o encuestas estándares para la medición de
criterios periciales y herramientas automatizadas para medir los criterios de
cálculo.
4. Definir las regulaciones organizativas para realizar el control: quiénes participan
en el control de la calidad, cuándo se realiza, qué documentos deben ser
revisados y elaborados, etc.

Existen Indicadores que permiten diferenciar los productos de calidad de los que
carecen de ella:

 El acercamiento a cero defectos.

 El cumplimiento de los requisitos intrínsecos y expresos.
 La satisfacción del cliente Sobre todo la satisfacción del cliente.

2.2.5.1 NORMAS PARA LA CALIDAD EN PRODUCTOS: ISO/IEC 9126, 14598,

25000, IEEE 1061

El estándar ISO/IEC 9126 tiene como objetivo la definición de un modelo de calidad y

su uso como marco para la evaluación de software. Como ya se ha mencionado, los
modelos de calidad concordantes con este estándar pertenecen a la categoría de
modelos mixtos, ya que el estándar propone una jerarquía de factores de calidad
clasificados como características, subcaracterísticas y atributos según su grado de
abstracción, entre los que se propone un conjunto de factores de partida compuestos
de 6 características y 27 subcaracterísticas.
El estándar ISO/IEC 9126 distingue entre calidad interna y calidad externa, e introduce
también el concepto de calidad en uso. La calidad interna tiene como objetivo medir la
calidad del software mediante factores medibles durante su desarrollo. La calidad
externa pretende medir la calidad del software teniendo en cuenta el comportamiento
de este software en un sistema del cual forme parte. Finalmente, la calidad en uso
corresponde a la calidad del software desde el punto de vista de un usuario.

El ISO/IEC 9126 original fue substituido en 2001 por dos estándares relacionados, el
ISO/IEC 9126 de calidad del software y el ISO/IEC 14598 de evaluación de productos
software. La versión de 2001 del ISO/IEC 9126 consiste de cuatro partes: 9126-1
(2001), presenta un modelo de calidad, que es común para medir la calidad interna y
externa, y uno distinto para medir la calidad en uso; 9126-2 (2003), presenta posibles
métricas externas para atributos de calidad externos; 9126-3 (2003), presenta posibles
métricas para atributos de calidad internos; y 9126-4 (2004), presenta posibles métricas
para evaluar atributos de calidad en uso. Cabe destacar que en este cambio, las
subcaracterísticas mencionadas anteriormente pasaron de ser recomendadas en un
anexo, a formar parte del estándar.

Norma ISO/IEC 14598

Esta norma define una serie de etapas que se deben realizar en el proceso de
evaluación de software. Para cada una de las etapas se indican las actividades que se
debe realizar, todo con el fin de que el proceso de evaluación se realice de forma
adecuada. Esta norma constituye una guía que brinda los fundamentos para llevar a
cabo la evaluación, la cual va a depender del objetivo de que se establezca.
Por ejemplo medir la calidad del producto durante su desarrollo, antes de su
adquisición, o en una comparación con otros productos similares o simplemente su
funcionamiento.

En ISO/IEC 14598-1 (1999), se define que el proceso de evaluación debe tener como
características fundamentales: la repetición, es decir que al repetir la evaluación de un
producto con la mismas especificaciones y el mismo evaluador se deben ocasionar
resultados idénticos; la reproducción, igual a la anterior pero esta vez la evaluación la
realiza un evaluador diferente y se producen resultados similares; la imparcialidad, que
indica que no se debe dirigir la evaluación hacia un resultado particular; y la objetividad,
que implica que los resultados de la evaluación sean reales y no se vean afectados por
los sentimientos u opiniones del evaluador.

NORMA ISO/IEC 25000

Conocida como SQuaRE (System and Software Quality Requirements and Evaluation),
es una familia de normas que tiene por objetivo la creación de un marco de trabajo
común para evaluar la calidad del producto software.
La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores,
especialmente de las normas ISO/IEC 9126, que describe las particularidades de un
modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso
de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se
encuentra compuesta por cinco divisiones.

 ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman esta
división definen todos los modelos comunes, términos y referencias a los que se
alude en las demás divisiones de SQuaRE.
 ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta
división presenta un modelo de calidad detallado, incluyendo características para la
calidad interna, externa y en uso.
 ISO/IEC 2502n. División de mediciones de calidad. Los estándares pertenecientes
a esta división incluyen un modelo de referencia de calidad del producto software,
definiciones matemáticas de las métricas de calidad y una guía práctica para su
aplicación. Presenta aplicaciones de métricas para la calidad de software interna,
externa y en uso.
 ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman parte
de esta división ayudan a especificar los requisitos de calidad. Estos requisitos
pueden ser usados en el proceso de especificación de requisitos de calidad para un
producto software que va a ser desarrollado ó como entrada para un proceso de
evaluación. El proceso de definición de requisitos se guía por el establecido en la
norma ISO/IEC 15288 (ISO, 2003).
 ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares
proporcionan requisitos, recomendaciones y guías para la evaluación de un
producto software, tanto si la llevan a cabo evaluadores, como clientes o
desarrolladores.

IEEE 1061

El estándar IEEE 1061 (1998) tiene como objetivo la definición de métricas de software
y su uso en la evaluación de componentes software. Fue aprobado en 1992 y revisado
y modificado en 1998. Propone la construcción de modelos de calidad a medida
adaptados a cada proyecto. No fija ningún factor de calidad, pero sí una clasificación de
los factores de los que debe constar un modelo en un nivel más alto y abstracto de
factores, que deben descomponerse en subfactores, que a su vez se descomponen en
métricas.