Ciudad Madero, Tamaulipas a 31 de Octubre de 2014

Instituto Tecnolgico de Ciudad Madero

Ingeniera en Sistemas Computacionales
Gestin de proyectos de Software
Punto de Venta para tienda de ropa
Docente: Laura Silvia Vargas Prez

Integrantes del equipo:

-Daniel Efran Cruz Rivera
-Luis Eduardo Garca Albarrn
-Jess Enrique Ramrez Camacho
-Alberto Isaas Barrn Loredo

ndice:
Captulo 1 Marco Conceptual
1.1 Introduccin.
1.2 Definicin del problema.
1.3 Justificacin.
1.4 Objetivos.
1.4.1 Objetivo General.
1.4.2 Objetivos Especficos
1.5 Hiptesis
1.6 Alcances del Proyecto.
1.7 Limitaciones del Proyecto..
1.8 Factibilidad Tcnica y Financiera.
1.8.1 Viabilidad econmica: estudio de costo-beneficio.
1.8.2 Viabilidad tcnica y operativa: Anlisis del entorno..
Captulo 2 Marco Terico
2.1. Antecedentes de la arquitectura de 4+1 vistas..
2.2. Estado del Arte..
2.2.1 Descripcin de Requerimientos ...
2.2.1.1 De proceso //enrique
2.2.1.2 De los usuarios (actores involucrados)..
2.2.1.3 Para la gestin, negociacin y anlisis
2.2.1.4 Estndar IEEE 830
2.2.2 Herramientas en el mercado para el manejo de Requerimientos
2.2.3 Anlisis de Riesgo.
2.2.3.1 Diferentes Metodologas de anlisis 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
Captulo 3 Marco Metodolgco
3.1 Ciclo de Vida de Desarrollo de Software CVDS elegido.
3.1.1 Descripcin y caractersticas ..
3.2 Anlisis.
3.2.1 De la Problemtica
3.2.2 De requisitos del sistema a crear...
3.2.3 De riesgos.
3.2.4 De metodologa para el aseguramiento de la calidad.
3.3 Tcnicas de desarrollo de las arquitectura de referencia
3.3.1 De acuerdo a la arquitectura de referencia del dominio del proyecto:.
Diseo en UML (diagrama dinmicos y estticos)
3.3.1 Diagramas de Casos de uso
3.3.2 Diagramas de actividades.
3.3.3 Diagramas de secuencia e interaccin
3.3.4 Diagramas de colaboracin..
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-Relacin (E-R)
3.5 Diccionario de Datos.

1.1 INTRODUCCIN

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 mercanca en los negocios, la correcta implementacin 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 estn relacionadas las
salidas de mercanca en los establecimientos.
El presente proyecto se desarroll porque exista un problema de sistematizacin en el
manejo de la informacin de las ventas generadas por el negocio de Ropa y
Novedades Gris. Ya que existan 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 da se realizan las ventas sin la utilizacin 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 cmputo que pueda reproducir o
ejecutar el sistema que se pretende desarrollar, este es un punto a considerar ms
adelante.
De esta manera se impuls al dueo a que hiciera uso de las tecnologas de la
informacin. Generando as un nuevo nivel de gestin de su negocio y as mismo
optimizando el manejo de informacin con un nuevo enfoque ms tecnolgico.

1.2 DEFINICIN 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, confusin 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 reposicin inmediata o anticipada, todo esto en general representa prdidas
econmicas en ventas y productos del negocio.

El sistema de apartado no estn eficiente ya que al no llevar los registros de manera

segura pueden perderse o traspapelarse, o el producto apartado puede ser vendido en
algn momento, y no contar con el cundo el cliente liquide el apartado.
Con la creacin del sistema se pretende erradicar estos problemas, para as facilitar el
manejo de las cuentas e inventarios del negocio, permitiendo llevar la administracin de
una manera correcta.

1.3 JUSTIFICACIN

Se pretende con el desarrollo de esta aplicacin 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. Adems 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 estn
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 perdern 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, adems estos registros solo podrn ser visualizados
por el administrador, lo cual le da ms seguridad al sistema, la informacin 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 estn siempre disponibles para su liquidacin. Y el producto est disponible
para su entrega.

1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL

Realizar un sistema que d solucin a los problemas en las operaciones de ventas y

control de inventarios del negocio. Para aumentar las ventas del negocio.

1.4.2 OBJETIVOS ESPECFICOS

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.
Implementacin de una interfaz amigable con el usuario, y de fcil manipulacin.
Contar con una parte para la administracin 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 Hiptesis
Con este sistema se pretender minimizar el tiempo de recoleccin de datos, los cuales
son necesarios para llevar una administracin del manejo de las ventas en el local
donde se encuentra.
1.6 Alcances del proyecto
El proyecto desarrollado administrara y gestionara la informacin, de los clientes, las
ventas que se realicen y as tambin un mayor control del inventario que estar alojado
en una base de datos, dando como consecuencia una gran reduccin del tiempo al
realizar dichas tareas.
1.7 Limitaciones del proyecto
La limitacin ms importante del sistema desarrollado es no contar con el sistema de
cmputo con los requerimientos necesarios en donde se implementara el servidor de
la base de datos la cual se enlazara con el sistema instalado en la misma
computadora.

1.8.1 Viabilidad econmica: estudio de costo-beneficio

Las caractersticas necesarias para el correcto funcionamiento del sistema, en cuanto a
hardware y software, adems de las caractersticas que son necesarias en cuanto
servicio de energa elctrica, 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 actualizacin ni reposicin de piezas. Lo cual debe de tener en cuenta
estos aspectos, ante el costo que se presentara a continuacin en forma de anlisis
costo-beneficio.

Cantidad

Producto

Computadora
Procesador Dual-Core 3.0 Ghz.
Memoria Ram
DRR3 1333 Ghz. 4gb
Unidad de DVD-CD
300 Gb. Disco duro
Teclado y raton estndar
Monitor LCD 17 Salida Estandar

Costo

Beneficio

$ 5320.00

Computadora necesaria
para la correcto
funcionamiento del
sistema de venta, adems
de ser utilizada para el
sistema tendr un
beneficio para el negocio
por la actualizacin.

$ 1450.00

Realizara las acciones de

entrada del cdigo de
manera directa, lo cual no
ocasionara problemas por
equivocacin de los
cdigos.

Lector de Cdigo de Barras

Servicios
Energa elctrica: Comisin Federal de Electricidad. $700 mensuales.
Servicio de Internet: Telmex o Telecable.
$399 mensuales.
*El anterior anlisis muestra los costos aproximados, ya que no se garantiza las cantidades
presenten el mismo valor al realizar el proyecto.
Las caractersticas 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 ms recursos en cuanto a un equipo con caractersticas superiores, representara un
mayor costo, pero de igual manera ser un mayor beneficio, por la calidad del producto ser
ms alta y de mayor tecnologa.

1.8.2 Viabilidad tcnica y operativa: Anlisis del entorno

Gastos de Operacin
Se presenta el siguiente anlisis del entorno:
PRESUPUESTO 2014
MONTO
SOLICITADO

PARTIDA

JUSTIFICACIN

2101

Materiales y tiles de oficina

$ 368.00

Pape, lpices, 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 impresin $ 1300.00

y reproduccin

Copiadora, impresora laser, escner. O

multifuncional.

2106

Materiales y tiles para el

procesamiento en equipos y
bienes informticos

$ 5000.00

Computadoras, Reguladores, pilas de

emergencia, teclados, ratones,
monitores,

2107

Material para informacin

$ 490.00

Cds, discos duros portables. Gasto por

mes.

2203

Productos alimenticios para el

personal que realiza labores en
campo o de supervisin

$ 600.00

Caf, galletas, agua, comidas rpidas.

2302

Refacciones y accesorios para

equipo de cmputo

$ 550.00

Cargadores para laptops, fuentes de

poder, discos duros, monitores,
reguladores.

2505

Materiales, accesorios y
suministros mdicos

$ 100.00

Botiqun de primeros auxilios.

TOTAL CAPTULO 2000

$ 8353.00

Servicio telefnico
convencional

$ 399.00

3103

Renta de servicio telefnico. Gasto

mensual.

3304

Otras asesoras para la

operacin de programas

$ 1000.00

Cursos de actualizacin o capacitacin

sobre nuevas herramientas.

3502

Mantenimiento y conservacin
de bienes informticos

$ 560.00

Material de limpieza de equipo, renta

de servicio de redes. Gasto mensual.

TOTAL CAPTULO 3000

$ 1959.00

2.1 Antecedentes de la arquitectura

Introduccin
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 diseados, especificados e intuitivos para un individuo. Unos de los aspectos que
motivan al estudio en este campo es el factor humano, la comunicacin a alto nivel
entre los miembros del equipo de desarrollo es la reutilizacin de componentes y
comparacin a alto nivel de diseos alternativos.
En el proceso de desarrollo se pueden aplicar diversos enfoques para garantizar el
cumplimiento de los requerimientos arquitectnicos, as como la evaluacin de las
alternativas presentadas. La evaluacin provee indicadores que permiten, en las fases
tempranas, la oportunidad de resolver problemas que pueden presentarse a nivel
arquitectnico.
La Arquitectura de Software es la organizacin fundamental de un sistema encarnada
en sus componentes, las relaciones entre ellos y el ambiente y los principios que
orientan su diseo y evolucin.
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 lgica describe el modelo de objetos del diseo cuando se usa un mtodo de
diseo orientado a objetos. Para disear una aplicacin muy orientada a los datos, se
puede usar un enfoque alternativo para desarrollar algn otro tipo de vista lgica, tal
como diagramas de entidad-relacin.
La vista de procesos describe los aspectos de concurrencia y sincronizacin del
diseo.
La vista fsica describe el mapeo del software en el hardware y refleja los aspectos de
distribucin.
La vista de desarrollo describe la organizacin esttica del software en su ambiente
de desarrollo.

Arquitectura del software (Elementos, Formas, Motivacin/Restricciones)

Las vistas estn 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 justificacin y sus restricciones, relacionando la arquitectura con algunos
de sus requisitos.
Cada vista se describe en lo que llamamos diagrama estos usan su notacin
particular. Los arquitectos tambin 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 descomposicin y
composicin, de estilos y esttica. Tambin tiene relacin con el diseo y la
implementacin de la estructura de alto nivel del software.
Los diseadores construyen la arquitectura usando varios elementos arquitectnicos
elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos
de funcionalidad y performance (desempeo) del sistema, as como tambin otros
requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y
disponibilidad del sistema.

La Arquitectura Lgica
La arquitectura lgica apoya principalmente los requisitos funcionales, lo que el sistema
debe brindar en trminos 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 abstraccin, encapsulamiento y herencia. Esta

descomposicin no slo se hace para potenciar el anlisis funcional, sino tambin sirve
para identificar mecanismos y elementos de diseo 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
distribucin, integridad del sistema, de tolerancia a fallas. La vista de procesos tambin
especfica en cul hilo de control se ejecuta efectivamente una operacin de una clase
identificada en la vista lgica. Un proceso es una agrupacin de tareas que forman una
unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos
puede ser controlada tcticamente (comenzar, recuperar, reconfigurar, y detener. El
software se particiona en un conjunto de tareas independientes: hilo de control
separado que puede planificarse para su ejecucin independiente en un nodo de
procesamiento. Podemos entonces distinguir:
Tareas mayores son elementos arquitectnicos que pueden ser manejados en forma
univoca. Se comunican a travs de un conjunto bien definido de mecanismos de
comunicacin inter-tarea: servicios de comunicacin sncrona y asincrnica basados en
mensajes, llamados a procedimientos remotos, difusin de eventos, etc.
Tareas menores son tareas adicionales introducidas localmente por motivos de
implementacin tales como actividades cclicas, 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 organizacin real de los mdulos de software en
el ambiente de desarrollo del software. El software se empaqueta en partes pequeas
bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o un
grupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua de
capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las
capas superiores.
La vista de desarrollo apoya la asignacin de requisitos y trabajo al equipo de
desarrollo, y apoya la evaluacin de costos, la planificacin, el monitoreo de progreso
del proyecto, y tambin como base para analizar reus, portabilidad y seguridad. Es la
base para establecer una lnea de productos. La vista de desarrollo de un sistema se
representa en diagramas de mdulos 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 pequeo de escenarios relevantes
instancias de casos de uso ms generales para los cuales describimos sus scripts
correspondientes (secuencias de interacciones entre objetos y entre procesos. Los
escenarios son de alguna manera una abstraccin de los requisitos ms importantes.
Su diseo se expresa mediante el uso de diagramas de escenarios y diagramas de
interaccin de objetos.

En conclusin no toda arquitectura de software requiere las 4+1 vistas completas. Las
vistas que no son tiles pueden omitirse de la descripcin de arquitectura, tales como la
vista fsica si hay un nico procesador, y la vista de procesos si existe un solo proceso
o programa. Para sistemas muy pequeos, es posible que las vistas lgica 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 estimacin 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 ms pesada de llevar a cabo. De una forma muy parecida a lo que ocurre en la
prctica 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 organizacin 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 ms eficientes.
Actualmente, las empresas tienen conocimiento amplio en este aspecto, mientras los
estndares proclaman la existencia de sus mtodos de estimacin, planificacin y
gestin de proyectos, estos son reducidos en una planificacin de los recursos en
funcin del negocio, es decir, de lo que se supone que el cliente puede llegar a pagar
por un servicio prestado. Despus entran otros aspectos menos importantes, pero no
por ello perjudcales, que redundan en la mala planificacin y gestin de los proyectos
de desarrollo de aplicaciones.

2.2.1 Descripcin de requerimientos

Los requerimientos son declaraciones que identifican atributos, capacidades,
caractersticas 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 clsico 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 diseo del sistema/software.

Etapas de la fase de requerimientos

* Obtencin de requerimientos: bsqueda y obtencin de los requerimientos desde los
grupos de inters.
* Anlisis: comprobacin de la consistencia y completitud de los requerimientos.
* Verificacin: constatacin de que los requerimientos especificados son correctos.

Clasificacin de los requerimientos

* Requerimientos funcionales: qu debe hacer el sistema o software.
* Requerimientos no funcionales: cmo debe funcionar el sistema o software (no su
implementacin), 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, adecuacin a determinadas leyes, etc.

Caractersticas que deberan cumplir los requerimientos

* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.
* Cohesin: el requerimiento debe dirigirse a solo una nica cosa.
* Completo: el requerimiento debe estar completamente declarado en un nico lugar,
sin informacin faltante.
* Consistente: el requerimiento no debe contradecir ningn otro requerimiento y debe
ser completamente consistente con toda la documentacin.
* 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 caracterstica definida por el grupo
interesado en el desarrollo del sistema/software, su ausencia no puede ser
reemplazada.
* Observable externamente: el requerimiento debe especificar una caracterstica
observable externa o experimentable por el usuario del producto.
* Verificable/demostrable: La implementacin del requerimiento debe poder ser resuelta
en alguno de estos cuatro mtodos: inspeccin, anlisis, demostracin o prueba.

2.2.1.1 Descripcin de procesos

Un Proceso de negocio es un conjunto de tareas relacionadas lgicamente, 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 Gestin de la Calidad")
se define un proceso como conjunto de actividades mutuamente relacionadas o que
interactan, las cuales transforman elementos de entrada en resultados (ISO
9000:2005; pp. 7). Oscar Barros hace una importante distincin, al introducir el
concepto de valor agregado en la definicin de proceso, sealando que un proceso es
un conjunto de tareas lgicamente 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 fsico o un servicio. stos establecen
las condiciones de satisfaccin o declaran que el producto o servicio es aceptable o no
(Barros, 1994; pp. 56). Thomas Davenport, uno de los pioneros de la reingeniera,
seala que un proceso, simplemente, es un conjunto estructurado, medible de
actividades diseadas para producir un producto especificado, para un cliente o
mercado especfico. Implica un fuerte nfasis en CMO se ejecuta el trabajo dentro de
la organizacin, en contraste con el nfasis en el QU, caracterstico de la focalizacin
en el producto (Davenport, 1993; pp. 5).

Tipos

Procesos estratgicos - Estos procesos dan orientacin al negocio. Por ejemplo,

"Planeacin estratgica"
Procesos sustantivos, clave o de generacin de valor - Estos procesos dan el valor al
cliente, son la parte principal del negocio. Por ejemplo, "Entregar el paquete" (empresa
de paquetera y mensajera); "Preparar la comida y servirla" (restaurante); "Transportar
al viajero" (aerolnea)
Procesos de apoyo vertical u horizontal - Estos procesos dan soporte a los procesos
centrales. Por ejemplo, "Contratar personal", "Dar soporte/servicio tcnico".
Acorde a la filosofa 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 ms simples como firmar un cheque o taln.
Algunos autores invierten el sentido y establecen que las tareas son las que se dividen
en actividades.
2.2 Estado del arte

La estimacin 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 ms pesada de llevar a cabo. De una forma muy parecida a lo que ocurre en la
prctica 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 organizacin 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 ms eficientes.
Actualmente, las empresas tienen conocimiento amplio en este aspecto, mientras los
estndares proclaman la existencia de sus mtodos de estimacin, planificacin y
gestin de proyectos, estos son reducidos en una planificacin de los recursos en
funcin del negocio, es decir, de lo que se supone que el cliente puede llegar a pagar
por un servicio prestado. Despus entran otros aspectos menos importantes, pero no
por ello perjudcales, que redundan en la mala planificacin y gestin de los proyectos
de desarrollo de aplicaciones.

2.2.1 Descripcin de requerimientos

Los requerimientos son declaraciones que identifican atributos, capacidades,
caractersticas 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 clsico 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 diseo del sistema/software.

Etapas de la fase de requerimientos

* Obtencin de requerimientos: bsqueda y obtencin de los requerimientos desde los
grupos de inters.
* Anlisis: comprobacin de la consistencia y completitud de los requerimientos.
* Verificacin: constatacin de que los requerimientos especificados son correctos.

Clasificacin de los requerimientos

* Requerimientos funcionales: qu debe hacer el sistema o software.
* Requerimientos no funcionales: cmo debe funcionar el sistema o software (no su
implementacin), 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, adecuacin a determinadas leyes, etc.

Caractersticas que deberan cumplir los requerimientos

* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.
* Cohesin: el requerimiento debe dirigirse a solo una nica cosa.
* Completo: el requerimiento debe estar completamente declarado en un nico lugar,
sin informacin faltante.

* Consistente: el requerimiento no debe contradecir ningn otro requerimiento y debe

ser completamente consistente con toda la documentacin.
* 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 caracterstica definida por el grupo
interesado en el desarrollo del sistema/software, su ausencia no puede ser
reemplazada.
* Observable externamente: el requerimiento debe especificar una caracterstica
observable externa o experimentable por el usuario del producto.
* Verificable/demostrable: La implementacin del requerimiento debe poder ser resuelta
en alguno de estos cuatro mtodos: inspeccin, anlisis, demostracin o prueba.

2.2.1.1 Descripcin de procesos

Un Proceso de negocio es un conjunto de tareas relacionadas lgicamente, 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 Gestin de la Calidad")
se define un proceso como conjunto de actividades mutuamente relacionadas o que
interactan, las cuales transforman elementos de entrada en resultados (ISO
9000:2005; pp. 7). Oscar Barros hace una importante distincin, al introducir el
concepto de valor agregado en la definicin de proceso, sealando que un proceso es
un conjunto de tareas lgicamente 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 fsico o un servicio. stos establecen
las condiciones de satisfaccin o declaran que el producto o servicio es aceptable o no

(Barros, 1994; pp. 56). Thomas Davenport, uno de los pioneros de la reingeniera,
seala que un proceso, simplemente, es un conjunto estructurado, medible de
actividades diseadas para producir un producto especificado, para un cliente o
mercado especfico. Implica un fuerte nfasis en CMO se ejecuta el trabajo dentro de
la organizacin, en contraste con el nfasis en el QU, caracterstico de la focalizacin
en el producto (Davenport, 1993; pp. 5).

Tipos

Procesos estratgicos - Estos procesos dan orientacin al negocio. Por ejemplo,

"Planeacin estratgica"
Procesos sustantivos, clave o de generacin de valor - Estos procesos dan el valor al
cliente, son la parte principal del negocio. Por ejemplo, "Entregar el paquete" (empresa
de paquetera y mensajera); "Preparar la comida y servirla" (restaurante); "Transportar
al viajero" (aerolnea)
Procesos de apoyo vertical u horizontal - Estos procesos dan soporte a los procesos
centrales. Por ejemplo, "Contratar personal", "Dar soporte/servicio tcnico".
Acorde a la filosofa 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 ms simples como firmar un cheque o taln.
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 ms
de un tipo de usuario, los analistas de requisitos han de tomar en consideracin a
todos los implicados para que se obtengan y depuren sus requerimientos de la
forma ms 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 especficos dentro de la
planificacin del proyecto; el conocimiento de cada papel desempeado, 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 comunicacin poco efectiva
entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en
tiempo como en presupuesto.
Los roles ms importantes pueden clasificarse como sigue:
Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn
familiarizados con los procesos especficos que debe realizar el software, dentro
de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y
los manuales de usuario.
Usuario Lder: 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 tcnico 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 administracin de cambios,
de la implementacin y resolucin de anomalas. 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 interactan 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, diseadores
de base de datos, entre otros.

Problemas relacionados con los actores involucrados

Las vas que pueden dificultar la determinacin de los requisitos se presentan a
continuacin:
Relacionados con los usuarios.

Los usuarios no tiene claro lo que desean

Los usuarios no se involucran en la elaboracin de requisitos escritos
Los usuarios insisten en nuevos requisitos despus de que el coste y la
programacin se hayan fijado.
La comunicacin con los usuarios es lenta
Los usuarios no participan en revisiones o son incapaces de hacerlo.

Los usuarios no comprenden los problemas tcnicos

Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situacin 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 anlisis de
requisitos son:
-El personal tcnico y los usuarios finales pueden tener diversos
vocabularios y pueden llegar a creer incorrectamente que estn de acuerdo,
no dndose 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 anlisis de requisitos se puede realizar a menudo por los ingenieros o
programadores, en vez de personal con las dominio habilidades de relacin
con la gente y el conocimiento del para entender las necesidades de un
cliente correctamente.

2.2.1.3 Para la gestin, negociacin y anlisis

Durante las dos pasadas dcadas, se han desarrollado un gran nmero de mtodosde
modelado. Los investigadores han identificado los problemas del anlisis y sus causas
y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de
heursticas para solucionarlos. Cada mtodo de anlisis tiene su punto de vista. Sin
embargo, todos los mtodos de anlisis se relacionan por un conjunto de principios
operativos:
1. Debe representarse y entenderse el dominio de informacin 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 informacin, funcin y comportamiento
de manera que se descubran los detalles por capas (o jerrquicamente).

5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle dela

implementacin.
Aplicando estos principios, el analista se aproxima al problema sistemticamente. Se
examina el dominio de informacin de manera que pueda entenderse completamente la
funcin. Se emplean modelos para poder comunicar de forma compacta las
caractersticas de la funcin y su comportamiento. Se aplica la particin para reducir la
complejidad.
Son necesarias las visiones esenciales y de implementacin del software para
acomodar las restricciones lgicas impuestas por los requisitos del procesamiento y las
restricciones fsicas impuestas por otros elementos del sistema. Adems de los
principios operativos de anlisis mencionados anteriormente, Davis sugiere un conjunto
de 6 principios directrices para la ingeniera de requisitos:
Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a
precipitarse en busca de una solucin, 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 cmo ser la interaccin
hombre-mquina. Como el concepto de calidad del software se basa a menudo en la
opinin sobre la amigabilidad de la interfaz, el desarrollo de prototipos (y la iteracin
que se produce) es altamente recomendable.
Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer
un seguimiento hasta el cliente.
Usar mltiples planteamientos de requisitos. La construccin 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
implementacin 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 ambigedad. Como la mayora de los requisitos estn
descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo
de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad

Estndar IEEE 830:

Las caractersticas de una buena especificacin de requisitos de software (ERS) son
definidas por el estndar 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 tambin con
otros documentos de especificacin.

Inequvoca. La redaccin debe ser clara de modo que no se pueda mal interpretar.

Correcta. El software debe cumplir con los requisitos de la especificacin.

Trazable. Se refiere a la posibilidad de verificar la historia, ubicacin o aplicacin de

un tem a travs de su identificacin almacenada y documentada.

Priorizable. Los requisitos deben poder organizarse jerrquicamente segn su

relevancia para el negocio y clasificndolos en esenciales, condicionales y
opcionales.

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

fcilmente modificable.

Verificable. Debe existir un mtodo 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
ingeniera 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 ingeniera de
requerimientos:

Tambin existen herramientas de software que facilitan la realizacin de cada una de

esas actividades:
Caractersticas de las herramientas de Administracin de requerimientos ms
utilizadas:

Lista de herramientas seleccionadas como las ms utilizadas por las empresas de

E.E.U.U
2.2.3 Anlisis de Riesgo.

El anlisis de riesgo, tambin conocido como evaluacin de riesgo o PHA por sus
siglas en ingls Process Hazards Analysis, es el estudio de las causas de las
posibles amenazas y probables eventos no deseados y los daos y consecuencias que
stas puedan producir.
Este tipo de anlisis es ampliamente utilizado como herramienta de gestin en estudios
financieros y de seguridad para identificar riesgos (mtodos cualitativos) y otras para
evaluar riesgos (generalmente de naturaleza cuantitativa).
El anlisis del riesgo es un mtodo sistemtico de recopilacin, evaluacin, registro y
difusin de informacin necesaria para formular recomendaciones orientadas a la
adopcin de una posicin o medidas en respuesta a un peligro determinado. Hay
pequeas variaciones en la terminologa utilizada por las tres organizaciones. Sin
embargo, las tres organizaciones hermanas consideran el anlisis del riesgo como un
proceso que consta de cuatro etapas:

identificacin del peligro;

evaluacin del riesgo;
gestin del riesgo; y
comunicacin del riesgo.

La identificacin del peligro consiste en especificar el acontecimiento adverso que es

motivo de preocupacin.
En la evaluacin del riesgo se tiene en cuenta la probabilidad (la probabilidad real y no
slo la posibilidad) de que se produzca el peligro, las consecuencias si ocurre y el
grado de incertidumbre que supone. (Obsrvese que esta descripcin de la evaluacin
del riesgo es diferente de la definicin que figura en el Acuerdo MSF.)
La gestin del riesgo consiste en la identificacin y aplicacin de la mejor opcin para
reducir o eliminar la probabilidad de que se produzca el peligro.
La comunicacin del riesgo consiste en el intercambio abierto de informacin y
opiniones aclaratorias que llevan a una mejor comprensin y adopcin de decisiones.

El procedimiento general para la elaboracin del anlisis de riesgo se enmarca en:

2.2.3.1 Diferentes Metodologas de anlisis de riesgo.

Existen diversas metodologas para desarrollar los anlisis de riesgos, la seleccin de

la metodologa ms apropiada en cada caso depende de la disponibilidad de
informacin y el nivel de detalle que se desee alcanzar.
1. Metodologa de anlisis preliminar de riesgos (Mtodo APELL):
Seala los principales aspectos que deben considerarse para establecer el anlisis
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
evaluacin total:
1. Matriz de riesgos: 40 %.
2. Elementos de gestin en seguridad, salud y ambiente: 20 %.
3. Aspectos ambientales: 20 %.
4. Otras caractersticas: 20 %.
La metodologa adoptada se basa en el Programa de Concientizacin y Preparacin
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 metodologa se pretende obtener un
anlisis primario que permita conocer de manera general y anticipada los principales
riesgos, siendo indicado para Organizaciones de carcter eminentemente industrial,
Industrias qumicas, Empresas petroleras, Industrias, Instalaciones u Organizaciones
en general cuya actividad pueda producir daos medioambientales o para la seguridad
de las personas.

2. Metodologa de anlisis y estrategias para el Control del Riesgo

La metodologa presentada a continuacin permite parametrizar el anlisis 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 metodologa permite aplicarse a edificios y actividades de cualquier naturaleza,

aunque estara ms indicado para edificios o actividades que no tengan una gran

ocupacin o personal en sus instalaciones, como por ejemplo Comercios,

Restaurantes, Hoteles de pocas habitaciones, Residenciales, etc.

3. Metodologa de matriz DOFA.

La matriz DOFA (conocido por algunos como DAFO y SWOT en ingls) es una
herramienta de gran utilidad para entender y tomar decisiones en toda clase de
situaciones. DOFA es el acrnimo 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 investigacin de
los riesgos y amenazas en una Organizacin. El anlisis DOFA es una evaluacin
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 metodologa adoptada permite analizar en con meticulosidad y en profundidad los
riesgos y amenazas de una Organizacin, siendo por tanto muy indicada para edificios
crticos como Hospitales, Laboratorios, Centros de Salud, etc.

4. Metodologa de matriz de riesgos.

Seala los principales aspectos que deben considerarse para establecer el anlisis
preliminar de riesgos, pero no contempla elementos de salud, ambiente y riesgo
industrial. La metodologa adoptada se basa en una parte concreta del Programa de
Concientizacin y Preparacin para Emergencias a Nivel Local (APELL), siendo
indicada la aplicacin de este mtodo en Organizaciones, Empresas, Industrias e
Instalaciones cuya actividad no origina riesgos medioambientales, como
Organizaciones administrativas, Centros Comerciales, Galeras Comerciales, Edificios
Comerciales, Comercios de cualquier naturaleza, Centros de Enseanza,
Universidades, Oficinas, Hoteles, Hospitales, etc.

5. Metodologa de anlisis de riesgos por colores.

La metodologa de anlisis de riesgos por colores, de una forma general y cualitativa

permite desarrollar el anlisis de amenaza y vulnerabilidad a personas, recursos,
sistemas y procesos, con el fin de determinar el nivel de riesgo a travs de la
combinacin de variables con cdigos de colores.
Asimismo, aporta elementos de prevencin y mitigacin de los riesgos y atencin
efectiva de los eventos que la organizacin, establecimiento o actividad pueda generar,
los cuales constituirn la base para formular los planes de accin. Se trata de una
metodologa muy visual, siendo indicada en Organizaciones, Empresas, Industrias e
Instalaciones de todo tipo, como Organizaciones administrativas, Centros Comerciales,
Galeras Comerciales, Edificios Comerciales, Comercios de cualquier naturaleza,
Centros de Enseanza, Universidades, Oficinas, etc.
2.2.4 Aseguramiento de la Calidad (Calidad en los procesos).

Segn la norma ISO 9000:2000, el aseguramiento de la calidad es la parte de la

gestin de la calidad orientada a proporcionar confianza en que se cumplirn los
requisitos de calidad.
El Aseguramiento de la Calidad del Software es el conjunto de actividades, planificadas
y sistemticas necesarias para aportar la confianza que el software satisfar los
requisitos dados de calidad. Este aseguramiento se disea para cada aplicacin antes
de comenzar a desarrollarla y no despus. El Aseguramiento de la Calidad del
Software engloba:

Un enfoque de gestin de calidad.

Mtodos y herramientas de Ingeniera del Software.
Revisiones tcnicas formales en el proceso del software.
Una estrategia de prueba multiescala.
El control de la documentacin del software y de los cambios realizados.
Procedimientos para ajustarse a los estndares de desarrollo del software.
Mecanismos de medicin y de generacin de informes.

Las revisiones del software son un "filtro" para el proceso de Ingeniera 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 revisin tcnica
formal (RTF), a veces llamada inspeccin, es el filtro ms 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 anomala del producto. Dentro del contexto del proceso
del software, los trminos defecto y fallo son sinnimos.
Las actividades de diseo 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 deteccin y la eliminacin de un gran
porcentaje de errores, el proceso de revisin 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
familiarizarn con partes del software que, de una forma u otra, no hubieran visto
nunca. Es una clase de revisin que incluye recorridos, inspecciones, revisiones
cclicas y otro pequeo grupo de evaluaciones tcnicas del software. Cada RTF se
lleva a cabo mediante una reunin y slo 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 tcnico.
2. Un grupo de SQA (Software Quality Assurance) que se responsabiliza en la
planificacin de aseguramiento de la calidad, supervisin, mantenimiento de
registros, anlisis e informes.
Las Actividades del grupo de SQA son:

Establecimiento de un plan de SQA para un proyecto.

Participacin en el desarrollo de la descripcin del proceso de software
del proyecto.
Revisin de las actividades de Ingeniera 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 ingeniera de procesos y mtodos utilizados para asegurar la
calidad. [Los mtodos por los cuales esto se logra son muchos y variados, y pueden
incluir la garanta de la conformidad con una o ms 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 definicin de requisitos, diseo de software , codificacin , control de cdigo
fuente ,revisiones de cdigo , gestin de configuracin de software , pruebas , gestin
de versiones , y la integracin 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 medicin travs 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 medicin aplicable al sistema y la
ingeniera de software y disciplinas de gestin. El proceso se describe a travs de un
modelo que define las actividades del proceso de medicin que se requieren para
especificar adecuadamente lo que la informacin de medicin se requiere, cmo las
medidas y los resultados de los anlisis se han de aplicar, y cmo determinar si los
resultados del anlisis son vlidas. El proceso de medicin es flexible, tolerable, y
adaptable a las necesidades de diferentes usuarios.
ISO / IEC 15939: 2007 identifica un proceso que apoya la definicin de un conjunto
adecuado de medidas que aborden las necesidades de informacin especfica.
Identifica las actividades y tareas que son necesarias para identificar con xito, definir,
seleccionar, aplicar y mejorar la medicin dentro de un proyecto global o estructura
organizacional de medicin. Tambin proporciona definiciones de los trminos de
medida de uso comn dentro de las industrias de sistemas y software.

ISO/IEC 15504
ISO/IEC 15504:2004: Proporciona un marco para la evaluacin 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 evaluacin de los procesos. Este marco
puede ser utilizado por las organizaciones que participan en la planificacin, la gestin,
el seguimiento, el control y la mejora de la adquisicin, suministro, desarrollo,
operacin, evolucin y soporte de producto y servicios.

Los ISO / IEC 15504 modelos de evaluacin de procesos publicados para sistemas y
software no ofrecen en la actualidad una base suficiente para la realizacin de una
evaluacin 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, tcnicas, habilidades y experiencia. Se necesitan amplificaciones de
proceso (de extensin de seguridad) en el rea de gestin de la seguridad, ingeniera
de seguridad y requisitos de seguridad. ISO / IEC TS 15504-10: 2011 presenta estas
amplificaciones (una extensin de seguridad) como tres descripciones de procesos:
gestin de la seguridad, los procesos de ingeniera de seguridad y certificacin 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 ms normas de seguridad especficas 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 informacin para la medicin de la capacidad de los
procesos y tambin la definicin 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
conjuncin con la norma ISO / IEC 15504-5 y / o ISO / IEC TR 15504-6 modelos de
evaluacin de proceso por asesores experimentados, con un mnimo apoyo de
expertos en el dominio de seguridad.
ISO / IEC TS 15504-10: 2011 se desarroll independiente de cualquier estndar de
seguridad especficas que definen los principios de seguridad, mtodos, tcnicas y
productos de trabajo. Sin embargo, los elementos de las normas de seguridad
pertinentes puedan ser asignada a la extensin de seguridad y la extensin de
seguridad se pretende que sea extensible para incluir requisitos especficos sobre
normas de seguridad.
La influencia de la extensin de la seguridad relativa a la evaluacin 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 indicacin de problemas adicionales que deben tenerse
en cuenta en el momento de la evaluacin. Los temas se proporcionan por medio de
frases que indican las relaciones especficas 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 evaluacin. De esta manera, un evaluador puede

utilizar la norma ISO / IEC TS 15504-10: 2011 para comprobar si, en la evaluacin 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 comn para los procesos del ciclo de vida del software,
con una terminologa bien definida, que puede ser referenciada por la industria del
software. Se aplica a la adquisicin de sistemas y productos de software y servicios,
para el suministro, desarrollo, operacin, mantenimiento y eliminacin de los productos

de software y la parte de software de un sistema, ya sea realizado internamente o

externamente a una organizacin. Se incluyen aquellos aspectos de la definicin del
sistema necesario para proporcionar el contexto para los productos y servicios de
software. El software incluye la parte de software de firmware. Esta revisin se integra
la norma ISO / IEC 12207: 1995, con sus dos enmiendas y se coordin con la revisin
paralela de 15288 ISO / IEC: (procesos del ciclo de vida del sistema) 2002 para alinear
la estructura, trminos, y los correspondientes procesos de la organizacin 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 evaluacin
de la capacidad del proceso de conformidad con la norma ISO / IEC 15504-2
(evaluacin del proceso). En un anexo se ofrece soporte para los usuarios de IEEE y
describe las relaciones de esta norma a los estndares 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 intencin 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 continuacin:

Incrementar la productividad y satisfaccin al trabajo de los profesionales

afines al campo de la computacin.
Mejorar la calidad del producto del software.
Proveer tcnicas aplicadas para automatizar el manejo de datos.
Realizar una planeacin eficaz de los sistemas.
Documentar.
Validar y controlar formalmente la calidad del trabajo realizado.

Cumplir con los objetivos de la organizacin en cuanto a productividad de sus

sistemas de cmputo.

Para controlar la Calidad del Software es necesario, definir los parmetros, indicadores
o criterios de medicin. 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:
Clasificacin por tipo, esfera de aplicacin, complejidad, etc., de acuerdo con los
estndares 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 mtodos de valoracin de los indicadores: mtodos
manuales como cuestionarios o encuestas estndares para la medicin de
criterios periciales y herramientas automatizadas para medir los criterios de
clculo.
4. Definir las regulaciones organizativas para realizar el control: quines participan
en el control de la calidad, cundo 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 intrnsecos y expresos.
La satisfaccin del cliente Sobre todo la satisfaccin del cliente.

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

25000, IEEE 1061

El estndar ISO/IEC 9126 tiene como objetivo la definicin de un modelo de calidad y

su uso como marco para la evaluacin de software. Como ya se ha mencionado, los
modelos de calidad concordantes con este estndar pertenecen a la categora de
modelos mixtos, ya que el estndar propone una jerarqua de factores de calidad
clasificados como caractersticas, subcaractersticas y atributos segn su grado de
abstraccin, entre los que se propone un conjunto de factores de partida compuestos
de 6 caractersticas y 27 subcaractersticas.

El estndar ISO/IEC 9126 distingue entre calidad interna y calidad externa, e introduce
tambin 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 estndares relacionados, el
ISO/IEC 9126 de calidad del software y el ISO/IEC 14598 de evaluacin de productos
software. La versin de 2001 del ISO/IEC 9126 consiste de cuatro partes: 9126-1
(2001), presenta un modelo de calidad, que es comn para medir la calidad interna y
externa, y uno distinto para medir la calidad en uso; 9126-2 (2003), presenta posibles
mtricas externas para atributos de calidad externos; 9126-3 (2003), presenta posibles
mtricas para atributos de calidad internos; y 9126-4 (2004), presenta posibles mtricas
para evaluar atributos de calidad en uso. Cabe destacar que en este cambio, las
subcaractersticas mencionadas anteriormente pasaron de ser recomendadas en un
anexo, a formar parte del estndar.

Norma ISO/IEC 14598

Esta norma define una serie de etapas que se deben realizar en el proceso de
evaluacin 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 evaluacin se realice de forma
adecuada. Esta norma constituye una gua que brinda los fundamentos para llevar a
cabo la evaluacin, la cual va a depender del objetivo de que se establezca.
Por ejemplo medir la calidad del producto durante su desarrollo, antes de su
adquisicin, o en una comparacin con otros productos similares o simplemente su
funcionamiento.
En ISO/IEC 14598-1 (1999), se define que el proceso de evaluacin debe tener como
caractersticas fundamentales: la repeticin, es decir que al repetir la evaluacin de un

producto con la mismas especificaciones y el mismo evaluador se deben ocasionar

resultados idnticos; la reproduccin, igual a la anterior pero esta vez la evaluacin la
realiza un evaluador diferente y se producen resultados similares; la imparcialidad, que
indica que no se debe dirigir la evaluacin hacia un resultado particular; y la objetividad,
que implica que los resultados de la evaluacin 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 creacin de un marco de trabajo
comn para evaluar la calidad del producto software.
La familia ISO/IEC 25000 es el resultado de la evolucin 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 evaluacin de productos software. Esta familia de normas ISO/IEC 25000 se
encuentra compuesta por cinco divisiones.

ISO/IEC 2500n. Divisin de gestin de calidad. Los estndares que forman esta
divisin definen todos los modelos comunes, trminos y referencias a los que se
alude en las dems divisiones de SQuaRE.

ISO/IEC 2501n. Divisin del modelo de calidad. El estndar que conforma esta
divisin presenta un modelo de calidad detallado, incluyendo caractersticas para la
calidad interna, externa y en uso.

ISO/IEC 2502n. Divisin de mediciones de calidad. Los estndares pertenecientes

a esta divisin incluyen un modelo de referencia de calidad del producto software,
definiciones matemticas de las mtricas de calidad y una gua prctica para su
aplicacin. Presenta aplicaciones de mtricas para la calidad de software interna,
externa y en uso.

ISO/IEC 2503n. Divisin de requisitos de calidad. Los estndares que forman parte
de esta divisin ayudan a especificar los requisitos de calidad. Estos requisitos
pueden ser usados en el proceso de especificacin de requisitos de calidad para un
producto software que va a ser desarrollado como entrada para un proceso de
evaluacin. El proceso de definicin de requisitos se gua por el establecido en la
norma ISO/IEC 15288 (ISO, 2003).

ISO/IEC 2504n. Divisin de evaluacin de la calidad. Estos estndares

proporcionan requisitos, recomendaciones y guas para la evaluacin de un
producto software, tanto si la llevan a cabo evaluadores, como clientes o
desarrolladores.

IEEE 1061
El estndar IEEE 1061 (1998) tiene como objetivo la definicin de mtricas de software
y su uso en la evaluacin de componentes software. Fue aprobado en 1992 y revisado
y modificado en 1998. Propone la construccin de modelos de calidad a medida
adaptados a cada proyecto. No fija ningn factor de calidad, pero s una clasificacin de
los factores de los que debe constar un modelo en un nivel ms alto y abstracto de
factores, que deben descomponerse en subfactores, que a su vez se descomponen en
mtricas.