Sistema de gestin de calidad ISO 9126

Es estndar internacional para evaluacin de calidad del software. El estndar se

divide en cuatro porciones, que tratan, respectivamente, los temas siguientes:
modelo de la calidad; mtrica externa; mtrica interna; y mtrica funcionando de la
calidad.
El modelo de la calidad establecido en la primera parte del estndar, ISO 9126-1,
clasifica calidad del software en un sistema estructurado de caractersticas y de
secundario-caractersticas como sigue:
Funcionalidad - Un sistema de las cualidades que refieren la existencia de un
sistema de funciones y de sus caractersticas especificadas. Las funciones son las
que satisfacen necesidades indicadas o implicadas.
o Conveniencia
o Exactitud
o Interoperabilidad
o Conformidad
o Seguridad
Confiabilidad - Un sistema de las cualidades que refieren la capacidad del
software para mantener su nivel del funcionamiento bajo condiciones indicadas
por un perodo del tiempo indicado.
o Madurez
o Recuperabilidad
o Tolerancia de avera
Utilidad - Un sistema de las cualidades que refieren el esfuerzo necesit para el
uso, y en el gravamen individual de tal uso, por un sistema indicado o implicado de
usuarios.
o Learnability
o Understandability
o Operability
Eficacia - Un sistema de las cualidades que refieren la relacin entre el nivel del
funcionamiento del software y la cantidad de recursos usados, bajo condiciones
indicadas.
o Comportamiento de Tiempo
o Comportamiento del recurso
Capacidad de mantenimiento - Un sistema de las cualidades que refieren el
esfuerzo necesit hacer modificaciones especificadas.
o Estabilidad
o Analyzability
o Changeability
o Testability
Portabilidad - Un sistema de las cualidades que refieren la capacidad del
software de ser transferido a partir de un ambiente a otro.
o Installability
o Reemplazabilidad
o Adaptabilidad
La conformidad secundario-caracterstica no se enumera arriba y no se aplica a
todas las caractersticas. Los ejemplos son conformidad a la legislacin referente a
utilidad o confiabilidad.
Cada calidad secundario-caracterstica (como adaptabilidad) se divide ms a
fondo en cualidades. Una cualidad es una entidad que se puede verificar o medir
en el producto de software. Las cualidades no se definen en el estndar, pues
varan entre diversos productos de software.
El producto de software se define en un ancho: abarca los executables, cdigo de
fuente, descripciones de la arquitectura, y as sucesivamente. Consecuentemente,
la nocin del usuario extiende a los operadores as como a los programadores,
que son usuarios de componentes como bibliotecas del software.

El estndar proporciona un marco para las organizaciones para definir un modelo
de la calidad para un producto de software. En hacer as pues, sin embargo, deja
hasta cada organizacin la tarea de especificar exacto su propio modelo. Esto se
puede hacer, por ejemplo, especificando los valores de blanco para la mtrica de
la calidad que evala el grado de presencia de las cualidades de la calidad.
Las mtricas internas son las que no confan en la ejecucin del software
(medidas estticas).
Las mtricas externas son aplicables al software corriente. Las mtricas
funcionando de la calidad estn solamente disponibles cuando el producto final se
utiliza en condiciones verdaderas. Idealmente, la calidad interna determina la
calidad externa y la calidad externa determina la calidad funcionando.
Este estndar proviene modelo establecido en 1977 de McCall y de sus colegas,
que propusieron un modelo para especificar calidad del software. El modelo de la
calidad de McCall se organiza alrededor de tres tipos de caractersticas de la
calidad:
Factores (especificar): Describen la vista externa del software, segn lo visto por
los usuarios.
Criterios (construir): Describen la vista interna del software, segn lo visto por el
revelador.
Mtrica (al control): Se definen y se utilizan para proporcionar una escala y un
mtodo para la medida.
La ISO 9126 distingue entre un defecto y una inconformidad, a defecto siendo El
incumplimiento de los requisitos previstos del uso, mientras que a inconformidad
es El incumplimiento de requisitos especificados. Una distincin similar se hace
entre la validacin y la verificacin, sabidas como V&V en el comercio de prueba.

Formas de normalizacin para el desarrollo de software
as herramientas de desarrollo de software (HDS) han desempeado un importante
papel en el desarrollo de aplicaciones. Como consecuencia del avance tecnolgico
stas han experimentado tambin continuos cambios. As como se cuenta en la
actualidad con documentacin sobre las numerosas HDS disponibles, y con
trabajos de investigacin que revelan avances en herramientas particulares.

El Proceso / Tcnicas. Permite un desarrollo racional de la IS y comprende
actividades tcnicas y de gestin propias asociadas al ciclo de vida del software.
Est determinado por un modelo, una representacin formal de un sistema. En la
IS, un modelo se comporta tambin como una estrategia de desarrollo.
El Mtodo. Un mtodo es una gua general para ayudar al desempeo de una
actividad . En la IS, los mtodos indican cmo construir el software. Los mtodos
tienen dimensiones de eficiencia y de efectividad, sentido del proceso y del
producto, cualidades que se atribuyen directamente a la calidad del software.
Las Herramientas. Todo mtodo tiene uno o varios instrumentos y tcnicas
asociados a l, con un grado de adecuacin que depende generalmente del
contexto de aplicacin.
Instrumento o herramienta, sera aquello que nos permite transportarnos por el
mtodo. As, las HDS proporcionan un enfoque automtico o semi automtico para
el proceso y para los mtodos.
Herramientas de Desarrollo de Software
Actualmente se considera a las HDS como herramientas basadas en
computadoras que asisten el proceso de ciclo de vida de software , consolidadas
en la literatura en la forma de Ingeniera de software asistida por computadora
(CASE, por sus siglas en ingls). Esto es, software que se utiliza para ayudar a
las actividades del proceso de software o software que es utilizado para disear y
para implementar otro software .
Permiten automatizar acciones bien definidas, reduciendo tambin la carga
cognitiva del ingeniero de software, quien requiere libertad para concentrarse en
los aspectos creativos del proceso. Este soporte se traduce en mejoras a la
calidad y la productividad en el diseo y desarrollo. Las HDS automatizan
metodologas de software y desarrollo de sistemas y se vinculan con los
diferentes conceptos involucrados en el desarrollo.
Las Herramientas como rea de Conocimiento de la IS
Las disciplinas conforman una visin de contexto de la IS. Hacia lo interno, existen
un conjunto de reas de conocimiento que facilitan la comprensin del alcance y
las limitaciones de diferentes temas en la IS. Estas reas son: Requerimientos,
Diseo, Construccin, Pruebas y Mantenimiento de software, Gestin de la
configuracin, Gestin de la ingeniera y del proceso de la ingeniera de software,
Herramientas y mtodos de software, y Calidad de software. De este modo, las
herramientas de software y los mtodos, integran un rea especfica de la IS, y
contribuyen a la produccin de software de alta calidad, con bajo costo y en el
menor tiempo posible.
Anlisis de requisitos del sistema de software
La ingeniera de requisitos del software es un proceso de descubrimiento,
refinamiento, modelado y especificacin. Se refinan en detalle los requisitos del
sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de
requisitos un conjunto de actividades que son denominadas anlisis El cliente
intenta replantear un sistema confuso, a nivel de descripcin de datos, funciones y
comportamiento, en detalles concretos. El desarrollador acta como interrogador,
como consultor, como persona que resuelve problemas y como negociador.
El anlisis y la especificacin de requisitos pueden parecer una tarea
relativamente sencilla, pero las apariencias engaan. El contenido de
comunicacin es muy denso. Abundan las ocasiones para malas interpretaciones
o falta de informacin. Es muy probable que haya ambigedad. El dilema al que se
enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa
frase de un cliente annimo: S que cree que entendi lo que piensa que dije,
pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo
quise decir.
El anlisis de requisitos es una tarea de ingeniera del software que cubre el
hueco entre la definicin del software a nivel sistema y el diseo de software. El
anlisis de requerimientos permite al ingeniero de sistemas especificar las
caractersticas operacionales del software (funcin, datos y rendimientos), indica la
interfaz del software con otros elementos del sistema y establece las restricciones
que debe cumplir el software.
Tareas de anlisis
El anlisis de requisitos del software se puede subdividir en cinco reas de
esfuerzo:
1. Reconocimiento del problema
2. Evaluacin y sntesis
3. Modelado
4. Especificacin
5. Revisin

Todos los mtodos de anlisis se relacionan por un conjunto de principios
operativos:
1. Debe representarse y entenderse el dominio de la 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 de la implementacin.
Adems de los principios operativos mencionados anteriormente, se sugiere un
conjunto de principios directrices para la ingeniera de requerimientos:
1. Entender el problema antes de empezar a crear el modelo de anlisis.
2. Desarrollar prototipos que permitan al usuario entender como ser la
interaccin hombre-mquina.
3. Registrar el orden y la razn de cada requerimiento,
4. Usar mltiples planteamientos de requerimientos.
5. Priorizar los requerimientos.
6. Trabajar para eliminar la ambigedad.
Un ingeniero de software que se apegue a estos principios es muy probable que
desarrolle una especificacin de software que represente un excelente
fundamento para el diseo.
Funciones y habilidades del analista
La funcin principal de un analista del software (o ingeniero de requisitos es llevar
a cabo las actividades necesarias para cumplir con las cinco reas de esfuerzo
descritas en la seccin anterior. Para lo cual hace uso de las siguientes tcnicas :
1. Entrevistas
2. Talleres
3. Observacin
4. Encuestas
5. Revisin documental
6. Uso de especificaciones formales para requerimientos (formatos estndar de
documentos, UML, etc.)
El ingeniero de requisitos debe poseer habilidades particulares para facilitar la
comunicacin con el cliente y ganar su confianza. (Consultar el artculo: So You
Want to be a Requirements Analyst?, Software Development, Julio 2003)
Ingeniera de Requisitos
Conceptos [SOMMERVILLE, 2002]
Requisitos del Software
Es la descripcin de los servicios y restricciones de un sistema de software, es
decir, lo que el software debe hacer y bajo qu circunstancias debe hacerlo.
Ingeniera de Requisitos del Software
Es el proceso de descubrir, analizar, documentar y verificar los requisitos del
software.
Stakeholders
Este trmino se utiliza para referirse a cualquier persona que tiene influencia
directa o indirecta sobre los requisitos del sistema. Entre los stakeholders se
encuentran los usuarios finales que interactan con el sistema y todos aquellos en
la organizacin se que vern afectados por dicho sistema. Los stakeholders
tambin son los ingenieros que desarrollan o dan mantenimiento a otros sistemas
relacionados, los administradores del negocio, los expertos en el dominio del
sistema, los representantes de los trabajadores, etc.
El proceso de la ingeniera de requisitos
Las actividades del proceso son:
1. Comprensin del dominio
2. Recoleccin de requisitos
3. Clasificacin
4. Resolucin de conflictos
5. Priorizacin
6. Verificacin de requisitos
7. Anlisis
Actividades de la Ingeniera de Requisitos. [SOMMERVILLE, 2002]
La ingeniera de requisitos incluye dos actividades principales: la obtencin de
requisitos, que da como resultado una especificacin del sistema que el cliente
comprende, y el anlisis, que da como resultado un modelo de anlisis que los
desarrolladores pueden interpretar sin ambigedad. [BRUEGGE, 2002]
La obtencin de requisitos se enfoca en la descripcin del propsito del sistema y
es la que implica el reto mayor. El cliente, los desarrolladores y los usuarios
identifican un rea problema y definen un sistema que resuelve el problema. A tal
definicin se le llama especificacin de los requisitos del software (SRS) y sirve
como contrato entre el cliente y los desarrolladores. La SRS se estructura y
formaliza durante el anlisis para producir un modelo de anlisis. Tanto la SRS
como el modelo de anlisis representan la misma informacin. Difieren slo en el
lenguaje y notacin que usan. La SRS est escrita en lenguaje natural, mientras
que el modelo de anlisis se expresa, por lo general, en una notacin formal o
semiformal. La especificacin del sistema es la base de la comunicacin con los
stakeholders. El modelo de anlisis es la base de la comunicacin entre los
desarrolladores.
La obtencin de requisitos y el anlisis se enfocan slo en la visin del sistema
que tiene el usuario.
Tipos de requisitos
Requisitos funcionales: Describen las interacciones entre el sistema y su
ambiente, en forma independiente a su implementacin. El ambiente incluye al
usuario y cualquier otro sistema externo con el cual interacte el sistema.
Requisitos no funcionales: Describen atributos slo del sistema o del ambiente del
sistema que no estn relacionados directamente con los requisitos funcionales.
Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo
de respuesta o precisin, tipo de plataforma (lenguajes de programacin y/o
sistemas operativos, etc.)

Caractersticas de una buena SRS
[IEEE Std 830-1998]
1. Correcta
2. No ambigua
3. Completa
4. Consistente
5. Calificada de acuerdo a la importancia y/o estabilidad
6. Verificable
7. Modificable
8. Rastreable
1. Correcta
Una SRS es correcta, s y solo s, cada requisito especificado es un requisito que
el software debe cumplir.
No ambigua
Una SRS no es ambigua s y solo s cada requisito especificado tiene slo una
interpretacin.
Completa
Una SRS es completa, s y solo s, incluye los siguientes elementos:
a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad,
desempeo, restricciones de diseo, atributos o interfaces externas. En particular
cualquier requisito externo impuesto por una especificacin del sistema debe ser
reconocido y tratado.
b) Definicin de las respuestas del software a todos los tipos posibles de clases
de datos de entrada en todos los tipos posibles de clases de situaciones. Notar
que es importante especificar las respuestas tanto para valores de entrada vlidos
como invlidos.
c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la
SRS as como la definicin de todos los trminos y unidades de medida.
Consistente
Una SRS es consistente, s y solo s, no se contradice a s misma, es decir, si
ningn subconjunto de requisitos ah descritos se contradicen o entran en
conflicto.
Jerarquizada de acuerdo a la importancia y/o estabilidad
Una SRS est calificada de acuerdo a la importancia y/o estabilidad si cada
requisito tienen un identificador que indique la importancia o estabilidad del
requisito.
Verificable
Una SRS es verificable, s y solo s, cada requisito especificado es verificable. Un
requisito es verificable s y solo s existe un proceso finito de costo-efectivo con el
cual una persona o una mquina puede verificar que el producto de software
cumple el requisito. En general cualquier requisito ambiguo no es verificable.
Modificable
Una SRS es modificable, s y solo s, su estructura y estilo son tales que, cualquier
cambio a los requisitos pueden ser hechos fcil, completa y consistentemente sin
perder la estructura y el estilo. La modificabilidad generalmente requiere que una
SRS:
a) Tenga una organizacin coherente y fcil de usar con una tabla
de contenido, un ndice y referencias cruzadas explcitas.
b) No sea redundante (esto es, el mismo requisito no debe
aparecer en ms de una parte en la SRS).
c) Expresa cada requisito de manera separada, en vez de hacerlo
mezclado con otros requisitos.
Rastreable
Una SRS es rastreable si el origen de cada uno de sus requisitos es clara y si
facilita la referencia de cada requisito en el desarrollo futuro o mejora de la
documentacin.
Se recomiendan los siguientes dos tipos de rastreabilidad:
a) Rastreabilidad hacia atrs (esto es, a estados previos del
desarrollo). El requisito tiene referencias explcitas a sus fuentes en documentos
anteriores.
b) Rastreabilidad hacia enfrente (esto es, a todos los documentos
derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre
nico o nmero de referencia. Es particularmente importante cuando el software
entra en operacin y mantenimiento. Cuando el cdigo y los documentos de
diseo son modificados, es escencial contar con la capacidad para conocer el
conjunto completo de requisitos que pueden ser afectados por esas
modificaciones.

Tipos de encuestas, entrevistas, como recavan necesidades para el
desarrollo de software y herramientas en general.
Encuestas:
En la actualidad, existen cuatro tipos de encuesta que se dividen segn el medio
que se utiliza para realizar la encuesta:
1. Encuestas basadas en entrevistas cara a cara o de profundidad [1]: Consisten
en entrevistas directas o personales con cada encuestado. Tienen la ventaja de
ser controladas y guiadas por el encuestador, adems, se suele obtener ms
informacin que con otros medios (el telfono y el correo). Sus principales
desventajas son el tiempo que se tarda para la recoleccin de datos, su costo que
es mas elevado que las encuestas telfnicas, por correo o internet (porque
incluye viticos, transporte, bonos y otros que se pagan a los encuestadores) y la
posible limitacin del sesgo del entrevistador (por ejemplo, su apariencia, estilo de
hacer preguntas y el lenguaje corporal que utiliza, todo lo cual, puede influir en las
respuestas del encuestado).
2. Encuestas telefnicas [1]: Este tipo de encuesta consiste en una entrevista va
telefnica con cada encuestado. Sus principales ventajas son: 1) se puede abarcar
un gran nmero de personas en menos tiempo que la entrevista personal, 2) sus
costos suelen ser bajos y 3) es de fcil administracin (hoy en da, existen
softwares especializados para la gestin de encuestas telefnicas). Sin embargo,
su principal desventaja es que el encuestador tiene un mnimo control sobre la
entrevista, la cual, debe ser corta (para no molestar al encuestado).
3. Encuestas postales: Consiste en el envo de un "cuestionario" a los potenciales
encuestados, pedirles que lo llenen y hacer que lo remitan [1] a la empresa o a
una casilla de correo. Para el envo del cuestionario existen dos medios: 1) El
correo tradicional y 2) el correo electrnico (que ha cobrado mayor vigencia en los
ltimos aos). Las principales ventajas de este tipo de encuesta estn
relacionadas con la sinceridad con que suelen responder los encuestados (al no
tener la presin directa que supone la presencia del encuestador), el bajo costo
(en relacin a la encuesta cara a cara y por telfono) y la amplia cobertura a la que
se puede llegar (siempre y cuando se disponga de una buena base de datos). Sus
desventajas son: La baja tasa de respuesta y la falta de listas con informacin
actualizada.

4. Encuestas por internet: Este tipo de encuesta consiste en "colocar" un
cuestionario en una pgina web o en enviarlo a los correos electrnicos de un
panel predefinido. Sus principales ventajas son: 1) la amplia cobertura a la que se
puede llegar (incluso a miles de encuestados en varios pases y al mismo tiempo),
2) el ahorro de tiempo (se puede obtener miles de encuestas respondidas en
cuestin de horas), los bajos costos (que son menores a las encuestas cara a
cara, por telfono y postales) y la utilizacin de medios audiovisuales durante la
encuesta. Sus desventajas son: No siempre se puede verificar la identidad del
encuestado y la interrogante que deja la muestra en cuanto a su representatividad
del universo.
Otros Tipos de Encuesta:
* Encuesta en el punto de venta: Es aquella que es realizada en los pasillos de un
establecimiento comercial y que consiste en interceptar a los compradores de ese
momento para solicitarles que rellenen el cuestioario.
* Encuesta mnibus: Consiste en un cuestionario cerrado multitemtico,
compuesto por varios mdulos que recogen informacin de una misma muestra
sobre diferentes temas, para distintos clientes, que se abonan al servicio y se
benefician de un ahorro de costes, dado qu stos son compartidos por todos los
suscriptores. El hecho de que se lleven a cabo con periodicidad semanal, mensual
o trimestral las hace muy indicadas para estudios de seguimiento.
* Encuesta por suscripcin: Es una encuesta de carcter nico que es vendida a
varios clientes interesados en ella y con necesidades parecidas. No debe ser
confundida con la encuesta mnibus
Entrevistas
Tipos de entrevista [editar]La entrevista tiene un nmero de variantes casi
indeterminadas, a continuacin se citan varios tipos de entrevista que aparecen en
los medios de comunicacin:
Laboral
Para informarse el entrevistador, valorar al candidato a un puesto de trabajo y
saber si puede ser apto o no para realizar su funcin.
Entrevista de personalidad
Se realizan con la finalidad de analizar psicolgicamente a un individuo y en
funcion de esta y otras tcnicas determinar el tratamiento adecuado.
Informativa o de actualidad
Es la vinculada con los hechos del da, es noticiosa, por tanto, se redacta como
una noticia. Jams se titula con frases textuales.
De divulgacin
Sobre temas especializados en avances o descubrimientos cientficos, mdicos,
tecnolgicos, etc o temas de actualidad o de inters permanente.
Testimoniales
Las que aportan datos, descripciones y opiniones sobre un acontecimiento o
suceso presenciado
Declaraciones
Datos, juicios u opiniones recogidos textualmente
Como recabar informacin
Muchas veces nos ha pasado que cuando estamos en la fase de inicio de un
software tenemos la necesidad de recolectar la informacin que el usuario nos
brinda, y qu mejor forma para hacerlo que con una entrevista con el mismo. A lo
largo de este curso aprenderemos la fase por la que pasa una entrevista, as como
prepararla y ejecutarla. Primero que todo imaginemos a Jorge que es un analista
encargado de realizar la parte de anlisis de un software en desarrollo.
Este analista debe saber que en el anlisis de sistemas hay que distinguir las
formas cualitativas y cuantitativas de informacin. La cualitativa est relacionada
con opiniones, polticas y descripciones narrativas de actividades o problemas y
las cuantitativas con nmeros, frecuencias o cantidades.
A menudo las entrevistas son la mejor fuente de informacin cualitativa, adems la
entrevista es la tcnica primaria para la informacin que recolecta durante las
fases de anlisis de los sistemas de un proyecto del desarrollo. Dentro de las
tcnicas utilizadas para recopilar informacin, las entrevistas ocupan un lugar
preponderante en consideracin con el tiempo que ocupan y el objetivo que
tienen. Por lo general, son la mayor fuente de informacin del analista.
Durante la entrevista el analista no se limita solo a informarse de los puntos que le
interesan, sino que adems aprovecha la oportunidad para explicar su trabajo a
los usuarios y crear un clima sociolgico favorable. Las entrevistas se pueden
realizar sobre la base de un cuestionario rgido o de una gua ms o menos
detallada que las orienta hacia puntos bien definidos.
El mtodo de entrevistas para obtener informacin tiene las siguientes ventajas. .
Permite a los analistas presentar sus necesidades de forma directa y verificar en
las respuestas recibidas, si las preguntas realizadas fueron interpretadas
correctamente. . Es una oportunidad que tiene el analista para conocer el grado de
aceptacin o resistencia que existe entre los usuarios hacia el sistema que se
desea disear. Despus de que nuestro analista tiene la nocin de que es una
entrevista entonces damos paso a realizarla, pero antes que nada Jorge debe
saber que la entrevista es un arte que todo analista debe dominar.
1. preparacion.
2. Ejecucin.
3. Problemas.
4. Conclusiones.

Tipos de procesadores y sus aplicaciones
Procesadores dedicados.
Para desarrollar una tarea muy especifica. Ejecutando un nico algoritmo de forma
ptima.
Procesadores de propsito general.
Est capacitado para ejecutar una serie de instrucciones sean E/S
(entrada/salida), lgicas, aritmticas, etc. Almacenando y listando una coleccin
de instrucciones en una memoria secundaria (programa) de tal forma que el
procesador de modo secuencial lleve a cabo cada una de ellas.
CISC.
Complex Instruction Set Computing. Posee un nmero grande y longitud variable
de instrucciones, alto porcentaje de ciclos por instruccin, operaciones de
microcdigo, baja optimizacin en el uso de registros.
RISC.
Reduced Instruction Set Computing. Posee un nmero bajo y longitud fija de
instrucciones, bajo porcentaje de ciclos por instruccin, no tiene operaciones de
microcdigo, muchos registros de propsito general, compilador optimizado. Su
arquitectura permite un cierto grado de paralelismo en su ejecucin.
Power PC.
Diseados para rendir al igual que los mejores CISC y RISC, pero mejorando sus
errores. Tiene un conjunto de instrucciones distinto a estos procesadores, pero
puede emular sus caractersticas para ejecutar los programas escritos para ellos.
Usados en computadores tipo Estaciones de Trabajo y en equipos de medio
rango.
SIMD.
Single instruction, multiple data. Tiene una organizacin nica de instruccin y
datos mltiples. Manipula instrucciones de vector mediante mltiples unidades
funcionales que responden a una instruccin comn.
Microprocesadores.
Son de uso general, requieren dispositivos externos de memoria y de
comunicacin con el exterior (E/S).
Microcontroladores.
Integran memorias y elementos de entrada/salida junto al microprocesador.
ASIC.
Application-Specific Integrates Circuits. Integra en un solo chip los elementos
analgicos y digitales necesarios para efectuar una determinada funcin.
DSP.
Digital Signal Processors. Procesadores de alta velocidad y poca memoria, muy
eficientes para efectuar algoritmos de procesado de la seal.
Procesadores Neuronales, transputers.
Estn equipados con elementos que facilitan su comunicacin de forma que puede
distribuirse fcilmente una funcin entre varios de ellos.
Procesador convencional.
Ejecuta las instrucciones en forma de serie es decir, una detrs de otra.
Procesador con paralelismo interno.
Externamente ejecuta las instrucciones como si fuera un procesador convencional
en serie, pero internamente puede efectuar operaciones en paralelo.
Procesador con paralelismo externo.
Se presenta en los sistemas que incluyen varios procesadores como los
servidores, los mainframes y los supercomputadores.
Multiprocesador.
Se acostumbra a usar la arquitectura de multiprocesador con memoria comn en
los servidores. Cada uno de estos procesadores incluyen una memoria cach de
grandes dimensiones para reducir el trafico con la memoria comn.

Conceptos fundamentales de diseo de software
A travs de la historia de la ingeniera del software ha evolucionado un conjunto de
conceptos fundamentales de diseo de software, aunque el grado de inters en
cada concepto ha variado con los aos, han pasado la prueba del tiempo
ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden
aplicarse mtodos de diseo ms elaborados.
El diseo de Software juega un papel importante en el desarrollo de software lo
cual permite al ingeniero de software producir varios modelos del sistema o
producto de que se va a construir el mismo que forman una especie de plan de la
solucin de la aplicacin. Estos modelos puede evaluarse en relacin con su
calidad y mejorarse antes de generar cdigo, de realizar pruebas y de que los
usuarios finales se vean involucrados a gran escala. El diseo es el sitio en el que
se establece la calidad del software.
Diseo es definido como: "El proceso de definicin de la arquitectura,
componentes, interfaces y otras caractersticas de un sistema o componente que
resulta de este proceso" [IEEE610.12-90].
Palabras Claves
Definicin de Documentos de Software (IEEE)
SQAP: Software Quality Assurance Plan IEEE 730
SCMP: Software Configuration Management Plan IEEE 828
STD: Software Test Documentation IEEE 829
SRS: Software Requirements Specification IEEE 830
SVVP: Software Validation & Verification Plan IEEE 1012
SDD: Software Design Description IEEE 1016
SPMP: Software Project Management Plan IEEE 1058
Fundamentos del Diseo de Software
Conceptos generales de diseo.
El software no es el nico campo donde el diseo se encuentra inmiscuido. En
general podemos ver el diseo como una forma para resolucin de problemas. El
problema sin solucin definitiva es interesante en trminos de comprensin del
diseo. Un numero de otras nociones y conceptos son tambin de inters en la
comprensin del diseo en su sentido general, objetivos, limitaciones, alternativas,
representaciones y soluciones
Contexto del diseo de software.
El diseo del software se encuentra en el ncleo tcnico de la respectiva
ingeniera y se aplica de manera independiente al modelo de software que se
utilice. Una vez que se analizan y especifican los requisitos, el diseo del software
es la ltima accin de la ingeniera correspondiente dentro de la actividad del
modelado, la cual establece una plataforma para la construccin (generacin de
cdigo y prueba).
"El milagro ms comn de la ingeniera de software es la transicin del anlisis al
diseo y del diseo al cdigo" Richard Due
Proceso del Diseo de Software.
Diseo Arquitectnico.
El diseo arquitectnico puede representarse al usar uno o ms de muchos
modelos diferentes. Los modelos estructurales representan la arquitectura como
una coleccin organizada de componentes del programa. Los modelos del marco
de trabajo repetible incrementan el grado de abstraccin del diseo al intentar
identificar marcos de trabajo repetibles del diseo arquitectnico que se
encuentran en tipos de aplicaciones similares.
El diseo de la arquitectura de software se describe cmo se descompone y como
estn organizados los componentes en el software. [IEEEP1471-00]
Diseo Detallado.
El diseo detallado se describe el comportamiento especfico de estos
componentes.
Tcnicas Permitidas.
Abstraccin
Abstraccin es el proceso o el resultado de la generalizacin de la reduccin del
contenido de la informacin de un concepto o un fenmeno observable, por lo
general, con el fin de conservar nicamente la informacin que es relevante para
un propsito en particular. Cuando se considera una solucin modular a cualquier
problema se pueden exponer muchos grados de abstraccin.
En un alto grado de abstraccin una solucin se establece en trminos generales
con el lenguaje del entorno del problema.
En los grados de menor abstraccin se proporciona una descripcin ms detallada
de la solucin.
En la medida en que se cambian los diferentes grados de abstraccin se trabaja
para crear abstracciones procedimentales y de datos.
Abstraccin Procedimental: Se refiere a una secuencia de instrucciones que tiene
una funcin especfica y limitada.
Abstraccin de Datos: Es una coleccin nombrada de datos que describe un
objeto de datos.
Acoplamiento y Cohesin.
Dentro del modelo de diseo es necesario que las clases de diseo colaboren con
alguna otra.
Es una medida de la interconexin entre los mdulos de la estructura de un
programa. Depende de la complejidad de la interfaz entre los mdulos, el punto en
el que se entra o se hace referencia al mdulo y qu datos pasan a travs de la
interfaz. Intentamos conseguir el menor nivel posible de acoplamiento. Las
conexiones sencillas entre los mdulos hacen que el software sea ms fcil de
entender y menos dado al efecto ola.
Acoplamiento: La fuerza de las relaciones entre los mdulos.
Acoplamiento de datos: est subordinado al mdulo y se accede a l por medio de
una lista convencional de argumentos a travs de la cual se pasan los datos.
Acoplamiento de marca: cuando en vez de argumentos simples se pasa una
porcin de la estructura de datos se pasa por la interfaz del mdulo.
Acoplamiento de control: se pasa un indicador de control (una variable que
controla las decisiones en el mdulo subordinado).
Acoplamiento externo: cuando los mdulos estn atados a un entorno externo al
software. Por ejemplo, las I/O y los dispositivos.
Acoplamiento comn: varios mdulos hacen referencia a un rea global de datos.
Acoplamiento de contenido: un mdulo hace uso de datos o de informacin de
control mantenidos dentro de los lmites de otro mdulo. Cuando se realiza una
bifurcacin hacia la mitad de otro mdulo.
Una clase de diseo cohesiva tiene un conjunto de responsabilidades pequeo y
enfocado, y aplica atributos y mtodos de manera sencilla de implementar dichas
responsabilidades.
Cohesin: Como estn relacionados los elementos que conforman un modulo.
Es una extensin natural del concepto de ocultamiento de la informacin. Un
mdulo con cohesin realiza una sola tarea dentro de un procedimiento de
software, requiriendo poca interaccin con los procedimientos que se realizan en
otras partes del programa. Un mdulo con cohesin debera hacer una sola cosa.
Siempre debemos buscar la cohesin ms alta, aunque la parte media del
espectro es a menudo aceptable.
Coincidencialmente cohesivo: un mdulo que realiza un conjunto de tareas poco
relacionadas las unas con las otras.
Cohesin lgica: realiza tareas relacionadas lgicamente (produce todas las
salidas).
Cohesin temporal: contienen tareas relacionadas por el hecho de que todas
deben hacerse en el mismo intervalo de tiempo.
Cohesin procedimental: cuando los elementos de procesamiento estn
relacionados y deben ejecutarse en un orden especfico.
Cohesin de comunicacin: todos los elementos de procesamiento se concentran
en un rea de la estructura de datos.
La descomposicin y la modularizacin.
Los patrones de arquitectura y diseo de software materializan la modularidad; es
decir, el software se divide en componentes con nombres independientes y que es
posible abordar en forma individual. Estos componentes llamados mdulos se
integran para satisfacer los requisitos del problema.
Modularidad: Es el atributo particular del software que permite que un programa
sea manejable de manera intelectual.
Se divide el software en componentes identificables y tratables por separado,
denominados mdulos, que estn integrados para satisfacer los requisitos del
programa.
Hay un nmero m de mdulos que resultaran en un costo de desarrollo mnimo,
pero no tenemos la sofisticacin necesaria para predecir m con seguridad
Encapsulacin/Ocultar Informacin
Mediante la agrupacin y empaquetado de los elementos y los detalles internos de
una abstraccin, haciendo que estos detalles sean inaccesibles.
Separacin de la interfaz y la aplicacin
La separacin de la interfaz y la aplicacin implica la definicin de un elemento
especificando una interfaz pblica, conoce a los clientes, aparte de los detalles de
cmo se realiza el componente.
Suficiencia, integridad y primitivismo.
Los mtodos asociados con una clase de diseo deben enfocarse en el
cumplimiento de un servicio para la clase.
Temas Claves en el Diseo de Software
A la hora de disear software hay una serie de cuestiones fundamentales que se
deben tomar en cuenta. Algunos relacionados con la calidad as como los
concernientes a la direccin como por ejemplo el rendimiento. Adems de cmo
se descomponen, organizan los paquetes de los componentes de software.
Esto es tan fundamental que en todo el proceso de diseo que se debe abordar de
una manera u otra.
"[Aspectos] no suelen ser unidades de descomposicin funcional del software, sino
ms bien a las propiedades que afectan el desempeo o la semntica de los
componentes en el sistema en diferentes maneras " (Kic97).
Concurrencia:
La forma de descomponer el software en los procesos, tareas e hilos tratar
relacionarlos con la eficiencia, la atomicidad, la sincronizacin, y dems
cuestiones de programacin.
Control y manejo de Eventos
Cmo organizar los datos y el controlar el flujo, manejo de reactivo y temporal de
los acontecimientos a travs de diversos mecanismos, tales como la invocacin
implcita de llamadas y sus intentos.
Distribucin de Componentes
Cmo distribuir el software en el hardware, cmo los componentes se comunican,
cmo se puede usar una plataforma al utilizarse para hacer frente a software
heterogneos.
Error y Gestin de Excepciones Tolerancia a Fallos.
El anlisis y la gestin del riesgo son una serie de pasos que ayudan al equipo del
software a comprender y a gestionar la incertidumbre.
Un riesgo es un problema potencial que puede ocurrir o no. Pero sin tener en
cuenta el resultado, realmente es una
buena idea es identificarlo, evaluar su
probabilidad de aparicin, estimar
su impacto, y establecer un plan de contingencia por si ocurre el problema.
Una estrategia considerablemente ms inteligente para el control del riesgo es ser
proactivo. La estrategia proactiva empieza mucho antes de que comiencen los
trabajos tcnicos. Se identifican los riesgos potenciales, se evala su probabilidad
y su impacto y se establece una prioridad segn su importancia. Despus, el
equipo de Software establece un plan para controlar el riesgo. El primer objetivo
es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo
trabaja para desarrollar un plan de contingencia que le permita responder de una
manera eficaz y controlada.
Estructura y Arquitectura de Software
En el sentido estricto, una arquitectura de software es "Una descripcin de los
subsistemas y componentes de un sistema de software y las relaciones que
existen entre ellos" (Bus96: c6).
A mediados de 1990, la arquitectura empez a emerger como una disciplina ms
amplia que implica el estudio de las estructuras y las arquitecturas de software en
una forma ms genrica, dando ideas interesantes sobre diseo del software en
diferentes niveles de abstraccin.
Algunos de estos conceptos son muy tiles durante el diseo arquitectnico (estilo
de arquitectura), de software especfico, as como en su diseo de detalle (nivel
inferior, patrones de diseo). As tambin para el diseo de sistemas genricos lo
que lleva a la concepcin de las familias de los programas (conocidas como lneas
de productos). La mayora de estos conceptos pueden verse como intentos de
describir, por tanto la reutilizacin del diseo genrico del conocimiento.
El desarrollo de un sistema con gran cantidad de software requiere que este sea
visto desde diferentes perspectivas. Diferentes usuarios (usuario final, analistas,
desarrolladores, integradores, jefes de proyecto...) siguen diferentes actividades
en diferentes momentos del ciclo de vida del proyecto, lo que da lugar a las
diferentes vistas del proyecto, dependiendo de qu interese ms en cada instante
de tiempo.
La arquitectura es el conjunto de decisiones significativas sobre:
La organizacin del sistema
Seleccin de elementos estructurales y sus interfaces a travs de los cuales se
constituye el sistema.
El Comportamiento, como se especifica las colaboraciones entre esos
componentes.
Composicin de los elementos estructurales y de comportamiento en subsistemas
progresivamente ms grandes.
El estilo arquitectnico que gua esta organizacin: elementos estticos y
dinmicos y sus interfaces, sus colaboraciones y su composicin.
Estructuras Arquitectnicas y Puntos de Vista.
Durante las diferentes facetas o etapas del software deben ser descritos y
documentados.
"Una vista representa un aspecto parcial de la arquitectura de un software
mostrando las propiedades del sistema de software".
La arquitectura que no debe centrarse nicamente en la estructura y en el
comportamiento, sino que abarque temas como el uso, funcionalidad, rendimiento,
capacidad de adaptacin, reutilizacin, capacidad para ser comprendida,
restricciones, compromisos entre alternativas, as como aspectos estticos. Para
ello se sugiere una arquitectura que permita describir mejor los sistemas desde
diferentes vistas, donde cada una de ellas es una proyeccin de la organizacin y
la estructura centrada en un aspecto particular del sistema.
La vista de casos de uso comprende la descripcin del comportamiento del
sistema tal y como es percibido por los usuarios finales, analistas y encargados de
las pruebas y se utilizan los diagramas de casos de uso para capturar los aspectos
estticos mientras que los dinmicos son representados por diagramas de
interaccin, estados y actividades.
La vista de diseo comprende las clases, interfaces y colaboraciones que forman
el vocabulario del problema y de la solucin. Esta vista soporta principalmente los
requisitos funcionales del sistema, o sea, los servicios que el sistema debe
proporcionar. Los aspectos estticos se representan mediante diagramas de
clases y objetos y los aspectos dinmicos con diagramas de interaccin, estados y
actividades.
La vista de procesos comprende los hilos y procesos que forman mecanismos de
sincronizacin y concurrencia del sistema cubriendo el funcionamiento, capacidad
de crecimiento y el rendimiento del sistema. Con UML, los aspectos estticos y
dinmicos se representan igual que en la vista de diseo, pero con el nfasis que
aportan las clases activas, las cuales representan los procesos y los hilos.
La Vista de implementacin comprende los componentes y los archivos que un
sistema utiliza para ensamblar y hacer disponible el sistema fsico. Se ocupa
principalmente de la gestin de configuraciones de las distintas versiones del
sistema. Los aspectos estticos se capturan con los diagramas de componentes y
los aspectos dinmicos con los diagramas de interaccin, estados y actividades.
La vista de despliegue de un sistema contiene los nodos que forman la topologa
hardware sobre la que se ejecuta el sistema. Se preocupa principalmente de la
distribucin, entrega e instalacin de las partes que constituyen el sistema. Los
aspectos estticos de esta vista se representan mediante los diagramas de
despliegue y los aspectos dinmicos con diagramas de interaccin, estados y
actividades.
Patrones de Diseo (Patrones Micro arquitectnicos).
"Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno,
as como la solucin a este problema, de tal ,modo que esta solucin se pueda
aplicar esta solucin un milln de veces, sin hacer lo mismo dos veces"
Christopher Alexander.
Los patrones de diseo hacen que sea ms fcil reutilizar buenos diseos y
arquitecturas. Al expresar como patrones de diseo tcnicas que ya han sido
probadas, las estamos haciendo ms accesibles para los desarrolladores de
nuevos sistemas. Los patrones de diseo nos ayudan a elegir las alternativas del
diseo que hacen que un sistema sea reutilizable, y evitar aquellas que dificultan
dicha reutilizacin.
Los patrones de creacin tienen que ver con el proceso de creacin, estructural o
de comportamiento.
Calidad en el anlisis, diseo y evaluacin del software
Calidad de atributos
Varios atributos son generalmente considerados importantes que permiten obtener
un diseo de software con alta calidad, existen algunas caractersticas que son (
mantenible, portabilidad, probable) y (correctos, robusto). Cabe destacar que
existen diferencias entre calidad de atributos que son (rendimiento, seguridad,
funcionalidad y usabilidad), y los que son (portabilidad, reutilizacin, integralidad y
pruebas), y las caractersticas relacionadas con la arquitectura (integridad
conceptual, correcto, completo).
Calidad en anlisis y evaluacin de tcnicas
Varias tcnicas y herramientas pueden ayudar a mejorar la calidad de diseo de
software:
Diseo de software.- Para este tipo se puede aplicar al diseo de software informal
y semi informal tomando un grupo base, tcnicas que permiten verificar la calidad
de diseo de los artefactos que pueden ser (vista de la arquitectura, diseo -
inspeccin, tcnicas y requerimientos).
Anlisis esttico.- Para este tipo se puede aplicar al diseo de software informal y
semi informal que permite evaluar algo simple utilizando anlisis automticos de
casos de pruebas.
Simulacin y prototipos.- Son tcnicas dinmicas que permiten evaluar un diseo
la caracterstica de simulacin, o la flexibilidad del prototipo.
Diseo de software
Muchas notaciones y lenguajes existen para representar el diseo de artefactos de
software. Algunos describen un diseo estructural organizado, otros representan el
inicio del software. Estas notaciones son generalmente usadas durante un diseo
natural y se pueden usar durante ambos casos. Una representan notaciones que
son usadas en el contexto de especficos mtodos en las estrategias de diseo y
mtodos de sub reas, pero estas categoras son categorizadas en notaciones
para describir la estructura esttica y la dinmicas vistas.
Software diseo estrategias y mtodos
Existen varias estrategias en el desarrollo del software que permiten mejorar el
diseo de procesos, a diferencia con las estrategias generales, mtodos que son
especficos en generar estrategias y proveen notacin para ser usados en
Mtodos y descripcin del proceso. Los mtodos utilizados son medias que
permiten transferir conocimiento y como un framework que permiten testear la
ingeniera del software.
Estrategias generales
Las estrategias generales son usadas en el diseno de procesos son dividios y
refinados permitiendo lograr una alta estracion de datos y informacin para esto
utilizando heursticas usando para esto patentes y patentes de lenguajes
Herramienta (gsBase(ie))
Es una herramienta de desarrollo y explotacin de propsito general que se puede
utilizar para crear soluciones para ingeniera, clculo, gestin, diseo grfico,
educacin, etc. Incluye novedosas ideas originales que le harn su trabajo mucho
ms fcil.
Permite construir soluciones integrales para empresas (ERP's, CRM's, B2B, B2C,
...) minimizando el tiempo invertido, recursos hardware y costes de desarrollo.
La comunicacin entre cliente y servidor se puede establecer por redes locales
internas, Internet o redes privadas. Los recursos mnimos de comunicaciones
necesarios hacen posible usar distintas tecnologas de comunicacin: ADSL,
GPRS, UMTS, RTB, Frame Relay, 3G, RDSI, etc.
Para disear, incluye un IDE (Integrated Development Environment) que permite
crear y modificar aplicaciones de una forma rpida y gil a la par que dar soporte a
instalaciones
El sistema de programacin gsBase incorpora una idea novedosa y original
(ventanas dinmicas) que permite, sin tener conocimientos de programacin
orientada a objetos, realizar o disear programas con dichas atribuciones de una
forma elegante y resolver problemas de gran complejidad de una forma muy fcil.
Todos los desarrollos realizados son reutilizables y el sistema permite que en el
desarrollo de aplicaciones, participen grupos de personas (trabajo en grupo
cooperativo). La claridad del lenguaje de programacin utilizado permite, sin
problemas, que un tcnico pueda interpretar rpidamente lo que otro ha
desarrollado (garantizado).
Para la definicin de ventanas dinmicas se usa el nuevo concepto de grupos o
agrupaciones de controles. Los campos de entrada, botones, textos,. de una
determinada ventana de gestin de archivo se definen por grupos, no de forma
individual como hacen la mayora de lenguajes de programacin, en los problemas
del mundo real los controles casi siempre van agrupados (por ejemplo para una
ficha de clientes: datos de identificacin, datos econmicos, condiciones de venta,
etc).
Gran parte del trabajo de diseo de aplicaciones consiste en la creacin de
ventanas para la gestin de archivos (creacin de registros, modificacin,
seleccin, borrado, consulta, etc.). gsBase estandariza y generaliza este tipo de
ventanas haciendo su diseo inmediato, el sistema incluye un potente control de
grid, controles de entrada, listas, rboles, chek-boxes, cuadros de radio, mensajes,
imgenes, botones, textos, sliders, etc.
La potente arquitectura cliente/servidor gsBase permite el trabajo concurrente de
miles de usuarios, hablamos de usuarios conectados de forma permanente al
servidor y realizando procesos simultneos (no se trata de conexiones
espordicas como ocurre en servidores web). gsBase es por tanto, la mejor
solucin para Medianas y Grandes Empresas, por su escalabilidad, potencia,
robustez, seguridad y necesidades mnimas de hardware y comunicaciones.
Los resultados e informes grficos en gsBase tienen una calidad y potencia
excepcional. Diagramas de barras, de tarta, de lneas o de reas son construidos
parametrizando una simple funcin en gsBase. La integracin de dichos
elementos en ventanas, informes o documentos es muy sencilla y funcional.
Caractersticas.
gsBase es un sistema de desarrollo de software para crear aplicaciones cliente-
servidor
Crear todo tipo de aplicaciones para empresas y administracin pblica
Disear sistemas centralizados para trabajo en local y/o remoto o por Internet
Las instalaciones de sus clientes finales podrn ser de 1 a miles de usuarios
concurrentes (Pymes o grandes empresas).
gsBase es la mejor herramienta para crear soluciones ASP (Alquiler de Software).
Ventajas.
Facilidad en diseo: cientos de ideas nuevas para el desarrollo.
Tiempo mnimo de aprendizaje para el desarrollo.
Amplios recursos para el aprendizaje en el diseo.
Posibilidad de partir de aplicaciones ya diseadas. Una vez adquirido el diseo, no
pagar royalties.
Evaluacin de las aplicaciones on-line trabajando con nuestros servidores de
demostracin el tiempo que necesite.
Posibilidad de direccin de proyectos por parte de nuestros ingenieros
Accesibilidad a sus datos y aplicaciones a nivel mundial para ejecucin o
mantenimiento
Sistema seguro y automatizado de distribucin de sus aplicaciones.
Mnimos recursos de hardware y comunicaciones.
Facilidad de instalacin y mantenimiento.
Sistema tolerante a fallos.
Trabajo en multi-idioma del sistema y sus aplicaciones.
Posibilidad de vender sus aplicaciones y mdulos de aplicaciones diseados.
Publicacin en gsBase Resource Center.
Gestin de licencias automtica, es posible deslicenciar en un ordenador y volver
a licenciar en otro.
Los tcnicos de desarrollo no son imprescindibles: lo que uno ha diseado, puede
mantenerlo otro sin problemas.