FACULTAD DE INGENIERIA DE SISTEMAS

CURSO
CONTROL Y CALIDAD DE SOFTWARE
CATEDRTICO
ALONSO MORALES
TRABAJO
Anlisis y Diseo de Software
INTEGRANTES
Crdenas Gutirrez, Jos Luis
Flores Flores, Noheli
Pacheco Loyola, Luis Miguel
FECHA
20 / 06 / 2011
NOTA


1



Contenido Pgina
I. Introduccin 02
II. Consideraciones Tericas 03
III. Estructura Interna del Software 05
3.1 Estructura Y Arquitectura Del Software 05
3.1.1 Riesgos 06
3.1.2 Ventajas de un Diseo Ascendente 06
3.1.3 Patrones Micro Arquitectnicos 07
3.2 Anlisis de Dominio 08
3.3 Modelado de Datos 09
3.3.1 Objetos de Datos 09
3.3.2 Atributos 09
3.3.3 Relaciones 09
3.3.4 Cardinalidad y modalidad 09
3.4 Anlisis orientado a objetos 10

IV. Consideraciones de Diseo de Software 11
4.1 Transformacin de un M.A a un Modelo de Diseo 11
4.2 Conceptos Fundamentales 13
4.3 Metodologas de Diseo 16
4.3.1 Diseo de Datos 16
4.3.2 Diseo Arquitectnico 17
4.3.3 Diseo de Componentes 22
4.3.4 Diseo de Interfaz 24
V. Buenas Prcticas de Diseo 29
5.1 Definicin 29
5.2 Objetivos 30
5.3 Motivos de fracaso 30
5.4 Diseo se centra en el valor cliente/usuario 31
5.5 La calidad en el diseo 33
5.6 Impacto Econmico 34
5.7 Test de Usuarios 37
5.8 Metodologa, Procesos y Casos de Uso 41
5.9 CMMI 43
5.10 Ms detalles 44
VI. Conclusiones y Recomendaciones 49
VII. Bibliografa 50

INDICE

2


Objetivo:
El objetivo general de la Ingeniera del Software es producir un software de calidad,
por calidad se entiende la adecuacin del software a los requisitos exigidos.
El proceso de desarrollo de software es aquel en el que las necesidades del usuario
son traducidas en requisitos de software, estos transformados en diseo y el diseo
implementado en cdigo.
El diseo es la nica forma exacta de que un requisito del cliente se pueda convertir
en un sistema o producto de software terminado.
El anlisis y diseo del software juegan un papel importante en el desarrollo del
software lo cual permite al ingeniero del software producir varios modelos del
sistema o producto del cual se va a construir; ya que el software es un elemento
lgico, en lugar de fsico.

Justificacin:
El anlisis y diseo del sistema es la etapa en donde se fomentara la calidad, ya que
el diseo proporciona las representaciones del software susceptibles de evaluar
respecto a la calidad.
El diseo tambin es importante porque permite que se evaluara la calidad del
software antes de implementarlo; aqu es el mejor momento para corregir los
errores, omisiones o inconsistencias; y a la vez no nos resultaran caras.
En la actualidad la mayora de las metodologas del diseo de software carecen de
profundidad, flexibilidad y naturaleza cuantitativa.




I. INTRODUCCION

3



ANALISIS
Distincin y separacin de las partes de algo para conocer su composicin, y as
poder examinar sus caractersticas y funciones.
[G001]


SOFTWARE
El software es un conjunto de programas elaborados por el hombre, que controlan
la actuacin del computador, haciendo que ste siga en sus acciones una serie de
esquemas lgicos predeterminados.
Los programas estn divididos en rutinas. Una rutina es un subconjunto del
conjunto de instrucciones que conforman el programa. Cada una de las rutinas de
un programa realiza una determinada funcin dentro del mismo.
[G002]


DISEO
El proceso de aplicar distintas tcnicas y principios con el propsito de definir un
producto con los suficientes detalles como para permitir su realizacin fsica.
El diseo de software es un proceso iterativo a travs del cual se traducen los
requisitos en una representacin del software; y se representa a un alto nivel de
abstraccin, un nivel que se puede seguir hasta requisitos especficos de datos,
funcionales y de comportamiento.

PATRON
Descripcin de un problema que ocurre una y otra vez en nuestro entorno, as
como la solucin a un problema, de tal modo que esa solucin se pueda aplicar
esta solucin un milln de veces.

MODULARIDAD
Es un atributo particular del software que permite que un programa sea manejable
de manera intelectual.

II. CONSIDERACIONES TEORICAS

4
ASPECTO DE DISEO
Son propiedades que afectan el desempeo o la semntica de los componentes en
el sistema en diferentes maneras
CONCURRENCIA
Forma de descomponer el software en los procesos, tareas e hilos y tratar de
relacionarlos con la eficiencia, la atomicidad, la sincronizacin, y dems
cuestiones de programacin.
CONTROL Y MANEJO DE EVENTOS
Organizacin de los datos y el control de los flujos, manejo de reactivo y temporal
de los acontecimientos a travs de diversos mecanismos, tales como la invocacin
implcita de llamadas y sus intentos.
DISTRIBUCION DE COMPONENTES
Es la distribucin del software en el hardware, como los componentes se
comunican, como se puede usar una plataforma al utilizarse para hacer frente a
software heterogneos.

















El milagro ms comn de la ingeniera del software
es la transicin del anlisis al diseo y del diseo al
cdigo
Richard Due


5


3.1. ESTRUCTURA Y ARQUITECTURA DE SOFTWARE
Para todo el proceso en el anlisis y diseo el ingeniero debe usar un enfoque sobre
el aseguramiento de la calidad, mediante la ingeniera de software que son 3:
1 Garantizar el aseguramiento de la calidad total diseando sistemas y
software con un enfoque modular descendente de arriba abajo.
2 Documentar el software con las herramientas necesarias.
3 Probar mantener y auditar el software, tiene como gua 2 propsitos
1 El usuario de sistemas de informacin es factor ms importante para la
evaluacin en su calidad.
2 Es menos costoso en la correccin de problemas en sus fases inciales
y no en las avanzadas porque les causa mayor problema problemas al
usuario.

Para un enfoque 6 sigmas se deben llevar 7 pasos:
1 Definir el problema
2 Observar el problema
3 Analizar las causas
4 Actuar en las causas
5 Estudiar los resultados
6 Estandarizar los resultados
7 Sacar las conclusiones.
La evaluacin se desarrolla debido a la expectacin del usuario que es de gran
importancia en la administracin total de calidad de QM y as establecer sus
distintas dimensiones.







III. ESTRUCTURA INTERNA DEL SOFTWARE

6
La calidad de los sistemas de informacin de administracin y de los sistemas de
apoyo a la toma de decisiones a travs del establecimiento de fuerzas de tareas o
crculos de calidad se puede involucrar en la entera evolucin de los sistemas.
Si se toma un enfoque descendente es que es donde se determina primero los
objetivos generales de la organizacin y luego la divisin de los distintos niveles el
desarrollo modular se complementa bien con el mismo, hace la programacin,
depuracin y mantenimiento ms fcil de lograr. La TQM puede ser de gran
satisfaccin para el diseo.
El enfoque descendente proporciona grupos de sistemas con una divisin mas
natural de usuarios en grupos de trabajo para subsistemas.

3.1.1 Riesgos
Quela divisin de los sistemas sea subsistemas errneos, ya hecha las
divisiones se pueden descuidar las interfaces y es necesario detallar de quien
es la responsabilidad de ella.
En el diseo ascendente es difcil de interconectar los sistemas de manera que
se desempean fcilmente como sistemas en la programacin interna.

3.1.2 Ventajas del Enfoque Descendente
- Evitan el caos de intentar disear un sistema de repente.
- Permite separar a los equipos de anlisis de sistemas para trabajar en
paralelo en diferentes subsistemas en los cuales se puede ahorrara mucho
tiempo.
- Evita un problema mayor asociado a un problema con un enfoque
ascendente.










7
3.1.3 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.
Objetivos de los Patrones
Los patrones de diseo pretenden:
Proporcionar catlogos de elementos reusables en el diseo de sistemas
software.
Evitar la reiteracin en la bsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
Formalizar un vocabulario comn entre diseadores.
Estandarizar el modo en que se realiza el diseo.
Facilitar el aprendizaje de las nuevas generaciones de diseadores
condensando conocimiento ya existente.
Asimismo, no pretenden:
Imponer ciertas alternativas de diseo frente a otras.
Eliminar la creatividad inherente al proceso de diseo.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener
el mismo problema o similar que soluciona el patrn, siempre teniendo en
cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el
uso de los patrones puede ser un error"




8
3.2. ANALISIS DE DOMINIO
Como se estableci anteriormente los patrones de anlisis a menudo ocurren de
nuevo en muchas aplicaciones dentro de un dominio de negocio especfico.
El dominio de aplicacin especfico puede variar desde aeronutica hasta servicios
bancarios. La meta del anlisis o de dominio es directa: encontrar o crear aquellas
clases de anlisis o funciones y caractersticas comunes que se aplican ampliamente
para que puedan reutilizares.
Un factor importante es que la probabilidad de aplicar patrones de diseo
reutilizables y componentes ejecutables de software aumenta en forma sustancial.
El papel del analista de dominio es descubrir y definir patrones de anlisis
reutilizables, clases de anlisis e informacin relacionada que pueda usar mucha
gente en aplicaciones parecidas.







9
3.3. MODELADO DE DATOS
3.3.1 Objetos de Datos
Es una representacin de cualquier informacin compuesta que se procesa con
software, se refiere a lago que tiene muchas propiedades o atributos diferentes.
Un objeto de datos puede ser una entidad externa, encapsulando solo datos: no existe
alguna referencia dentro de un objeto de datos a las operaciones acten sobre los
datos.

3.3.2 Atributos
Los atributos definen las propiedades de un objeto de datos y toman una de las tres
caractersticas diferentes:
Nombran una ocurrencia del objeto de datos.
Describir la ocurrencia
Hacer referencia a otra ocurrencia en otra tabla.
Adems se debe definir uno o ms atributos como un identificador.

3.3.3 Relaciones
Los objetos de datos estn conectados entre s de muchas maneras diferentes, por
ejemplo se establece una conexin entre persona y auto porque los objetos se
relacionan entre s; se puede definir un conjunto de parejas objeto/relacin que
definan las relaciones relevantes, como por ejemplo:
Una persona posee un auto
Una persona est asegurada para conducir un auto


3.3.4 Cardinalidad y Modalidad
Cardinalidad es la especificacin del nmero de ocurrencias de un objeto que puede
relacionarse con el nmero de ocurrencias de otro objeto.
La Cardinalidad tambin define el nmero mximo de objetos que puede participar
en una relacin.
Sin embargo no indica si un objeto particular de datos debe participar o no en la
relacin.
El modelo de datos agrega modalidad al par objeto/relacin para especificar esta
informacin; la modalidad de una relacin es de 0 si no hay una necesidad explicita
para que ocurra la relacin o la relacin es opcional; la modalidad es 1 si una
ocurrencia de la relacin es obligatoria.

10
3.4. ANALISIS ORIENTADO A OBJETOS
El objetivo del anlisis orientado a objetos (AOO) es definir todas las clases,
adems de las relaciones y el comportamiento asociado con ellas relevantes para el
problema y que deben resolverse.
Esto se logra llevando a cabo algunas tareas:
i. Deben comunicarse los requisitos bsicos del usuario entre el cliente y el
ingeniero de software.
ii. Deben identificarse las clases (definir atributos y mtodos)
iii. Se define una jerarqua de clases.
iv. Deben representarse las relaciones de objeto a objeto.
v. Debe modelarse el comportamiento del objeto.
vi. Las tareas del 1 al 5, se vuelven a aplicar de manera iterativa hasta que el
modelo este completo.
En lugar de examinar un problema mediante un modelo ms convencional del tipo
entrada-procesamiento-salida o un modelo derivado en forma exclusiva de las
estructuras jerrquicas de informacin, el AOO construye un modelo orientado a las
clases que se basa en la comprensin de los conceptos OO.

El objetivo del modelado de anlisis es crear una variedad de representaciones que
muestran los requisitos del software para la informacin, la funcin y el
comportamiento. Esto se logra aplicando dos diferentes filosofas de modelado: el
anlisis estructurado y el anlisis orientado a objetos.
El anlisis estructurado considera al software como un transformador de
informacin, mientras que el anlisis orientado a objetos examina un dominio de
problema definido como un conjunto de casos de uso en un esfuerzo por extraer
clases que definen el problema.
El modelo de anlisis lo componen cuatro elementos: modelo basado en escenarios,
modelos de flujo, modelos basados en clases y modelos de
comportamiento; donde los primeros tres elementos
proporcionan una visin esttica del software, mientras que los
de comportamiento muestran un desempeo dinmico.



11



4.1. TRANSFORMACION DE UN MODELO DE ANALISIS A UN
MODELO DE DISEO
Cada uno de los elementos del modelo de anlisis proporciona la informacin
necesaria para crear los modelos de diseo que se requieren para una especificacin
completa de diseo.
Una vez que se analizan y especifican los requisitos del software, el diseo del
software es la primera de las tres actividades tcnicas:
Diseo
Generacin de cdigo
Pruebas
Estas etapas son importantes porque se requieren para construir y verificar el
software.
Durante el diseo se toman decisiones que al final incidirn en el xito de la
construccin del software; as tambin con el mismo grado de importancia y la
facilidad con que el software puede mantenerse.



IV. CONSIDERACIONES DE DISEO

12
CONSIDERACIONES PARA EL DISEO
Cuando usted comienza un proyecto de software, hgase estas tres preguntas:
Cmo quiero que mi software sea para ofrecer a los usuarios?
Cmo puedo disear una aplicacin que sea accesible a todos los usuarios
potenciales?
Cmo puedo disear una aplicacin que se adapte a una audiencia global y
requiere un esfuerzo mnimo para localizar?

GUIA PARA EVALUAR UN BUEN DISEO
A travs del proceso de diseo, la calidad se evala con una serie de revisiones tcnicas
formales o con revisiones de diseo.
Segn McGlaughlin sugiere las siguientes caractersticas de un buen diseo:
El diseo deber implementar todos los requisitos explcitos del modelo de
anlisis, y debern ajustarse a todos los requisitos implcitos que desea el cliente.
El diseo deber ser una gua legible y comprensible para aquellos que generan
cdigo y para aquellos que comprueban y consecuentemente, dan soporte al
software.
El diseo deber proporcionar una imagen completa del software, enfrentndose
a los dominios de comportamiento, funcionales y de datos desde una perspectiva
de implementacin.







13
4.2 CONCEPTOS FUNDAMENTALES
4.2.1 Abstraccin
Es una de las formas fundamentales con la que podemos enfrentar la
complejidad.
En la medida en que cambian los diferentes grados de abstraccin
tenemos:
a. Abstraccin Procedimental: se refiere a una secuencia de
instrucciones que tiene una funcin especfica y limitada; pero se
omiten detalles especficos.
b. Abstraccin de Datos: es una coleccin nombrada de datos que
describe un objeto de datos.

4.2.2 Arquitectura
La arquitectura de software se refiere a la estructura global del software y
la manera en que esta estructura proporciona integridad conceptual al
sistema.
Representa los componentes que tiene el software, cmo interactan y la
estructura de los datos que usan estos componentes.
El uso de patrones arquitectnicos permitir a los diseadores reutilizar
componentes
La arquitectura del diseo se puede representar utilizando diferentes
modelos: Estructurales, Plantillas, Dinmicos, de procesos, y funcionales

4.2.3 Patrones
Un patrn de diseo describe una estructura de diseo que resuelve un
problema de diseo particular, dentro de un contexto especfico.
Un patrn de diseo provee informacin que permite al diseador
determinar si el patrn es aplicable, si puede re-usarse y si se puede usar
como gua para desarrollar algn patrn similar con estructura diferente.






14
4.2.4 Modularidad
Es un atributo del software que permite que un programa sea manejable
de manera intelectual, 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.
Tericamente el aumento en el nmero de mdulos disminuye la
complejidad, y por lo tanto el esfuerzo de resolver un problema; entonces
con un nmero infinito de mdulos tendramos un problema de
complejidad cero.
Sin embargo el aumento en el nmero de mdulos genera un aumento en
el costo por comunicacin entre mdulos.




4.2.5 Ocultamiento de la Informacin
Los mdulos deben especificarse y disearse de manera que la
informacin (procedimientos y datos) que est dentro del modulo sea
inaccesible para otros mdulos que no necesiten esa informacin.
La ocultacin implica que se puede conseguir una modularidad efectiva
al definir un conjunto de mdulos independientes que se comuniquen
entre si y que intercambien solo la informacin necesaria para lograr la
funcin del software.
El uso de la ocultacin de informacin proporciona los mayores
beneficios cuando se requieren modificaciones durante la realizacin de
las pruebas y despus en el mantenimiento del software.



15
4.2.6 Independencia Funcional
Es la suma directa de la modularidad, de la abstraccin y ocultamiento de
informacin
La independencia funcional se logra al desarrollar mdulos con una
funcin determinante y una aversin a la interaccin excesiva con otros
mdulos.

4.2.7 Refinamiento
La arquitectura de un programa se desarrolla a travs del detallado
sucesivo de niveles.
El refinamiento es un proceso de elaboracin, que se inicia con el
enunciado de una funcin que se define con un alto grado de abstraccin,
haciendo que el diseador trabaje sobre el enunciado original y que
proporcione ms y ms detalles conforme se realiza cada refinamiento
sucesivo.

4.2.8 Refabricacin
Es el proceso de cambiar un sistema de tal forma que no se altere el
comportamiento externo de su cdigo y aun as se mejore su estructura
interna.

4.2.9 Clases de Diseo
Las clases generadas en el anlisis definen el dominio del problema.
En el diseo, las clases se definen de manera que se refinan las clases
obtenidas en el anlisis a fin de que se puedan implementar,
El diseo crea un nuevo conjunto de clases que permiten implementar la
infraestructura de software que va a sostener la solucin







Existen dos formas de construir un diseo de software; una
forma es hacerlo tan simple que obviamente no hay deficiencias,
y la otra es hacerlo tan complicado que no existen diferencias
obvias. El primer mtodo es mucho ms difcil
C.A.R.Hoare


16
4.3 METOLOGIAS DE DISEO

4.3.1 DISEO DE DATOS
Es un modelo de informacin a estructuras de datos, es decir crea un modelo
de datos o informacin que se representa con un alto grado de abstraccin,
que a la vez lleva al diseo de datos a la definicin de una arquitectura para
una base o almacn de datos.
La estructura del diseo de datos y los algoritmos con que se manipulan son
esenciales para la creacin de aplicaciones de alta calidad.
Al nivel de aplicacin la traduccin de un modelo de datos a una base de
datos es esencial para alcanzar los objetivos de negocio de un sistema.
Por lo general, el diseo de datos empieza durante la creacin del diseo de
anlisis.

Niveles de Diseo de Datos
a. A Nivel Arquitectnico: aqu se ha desarrollado la tcnica de minera y
almacenamiento de datos, que es un conjunto de herramientas que apoya
la integracin, consulta, informes y funciones estadsticas que nos ayudan
en la identificacin de relaciones entre atributos.
b. A Nivel de Componentes: es la representacin de estructuras de datos a
las que se tiene acceso en forma directa mediante uno o ms
componentes de software

Principios Para la Especificacin de Datos
Deben identificarse todas las estructuras de datos y las operaciones que
se realizaran.
Debe establecerse un mecanismo para la definicin del contenido de cada
objeto de datos y usarlo para definir los datos y las operaciones que se les
aplican.
Las decisiones del diseo a nivel de datos deben posponerse hasta una de
las ltimas etapas del proceso de diseo.
Un diseo de software y un lenguaje de programacin deben dar soporte
a la especificacin y la realizacin de los tipos de datos abstractos.



17
4.3.2 DISEO ARQUITECTONICO
Los elementos del diseo arquitectnico dan una visin general del software, nos
representa la estructura de datos y los componentes del programa.
El diseo arquitectnico se realiza aplicando varios pasos:
i. Definir las entidades externas que interactan con el software y la naturaleza
de la interaccin.
ii. Identificar un conjunto de abstracciones de nivel superior llamados
Arquetipos
iii. Crear instancias especficas de la arquitectura para probar el diseo en un
contexto real.
Y una vez que se ha elaborado se compara contra los criterios de calidad.

QUE ES ARQUITECTURA DE SOFTWARE?
Es la estructura(s) del sistema, que incluyen los componentes del software, las
propiedades visibles externamente de esos componentes y las relaciones entre
ellos.
La arquitectura es una representacin que permite al ingeniero de software a:
Analice la efectividad del diseo para cumplir con los requisitos
establecidos.
Considere opciones arquitectnicas en una etapa en que aun es fcil hacer
cambios al diseo.
Reduzca los riesgos asociados con la construccin del software.



18
ESTRUCTURA ARQUITECTONICA
a. Representacin del Sistema en el Contexto
En esta etapa deben identificarse todos los datos que fluyen al interior o exterior
del sistema de destino, la informacin del usuario y el procesamiento relevante
de soporte.
Un arquitecto del diseo de software aplica un diseo de contexto arquitectnico
(DCA) para modelar la manera en que el software interactuara con las entidades
ms all de sus lmites.

b. Definicin de Arquetipos
Es un conjunto de abstracciones de nivel superior, que representan elementos
centrales del comportamiento o la funcin del sistema.
Los arquetipos se derivan al examinar las clases de anlisis definidas como parte
del modelo de anlisis.
Los arquetipos forman base de la arquitectura pero son abstracciones que deben
refinarse aun ms a medida que avanza el diseo arquitectnico.

c. Refinamiento de la Arquitectura en Componentes
Las clases de anlisis representan entidades dentro del dominio de la aplicacin,
que es una fuente para la derivacin y el refinamiento de la arquitectura en
componentes.
Se identifican los componentes y se representan dentro del contexto de una
arquitectura que los soporta.

d. Descripcin de la Creacin de Instancias del Sistemas
Hasta ahora hemos visto la estructura general del sistema y se han identificado
los principales componentes del software. Sin embargo, aun se necesita mayor
refinamiento ya que todo diseo es iterativo.
Aqu se crean instancias especificas de la arquitectura para probar el diseo en
un contexto real; esto se logra desarrollando una instancia de la arquitectura, es
decir que se aplique a un problema especfico con el propsito de demostrar que
la estructura y los componentes son apropiados.




19
ESTILOS ARQUITECTONICOS
Un estilo arquitectnico es una transformacin impuesta al diseo de todo un sistema,
con el objetivo de establecer una estructura para todos los componentes del sistema.

TAXONOMIA DE ESTILOS ARQUITECTONICOS

a.- Arquitectura Centrada en Datos:
promueve la capacidad de integracin, es
decir, que es posible cambiar
componentes existentes y agregar nuevos
componentes a la arquitectura sin
preocuparse por otros.




b.- Arquitectura de Flujo de Datos: se aplica cuando los datos de entrada se habrn de
transformar en datos de salida mediante una serie de componentes para el clculo o
la manipulacin.
Si el flujo de datos degenera en una sola lnea de transformaciones se denomina
procesamiento por lotes secuencial.




20
c.- Arquitectura de Llamada y Retorno: permite obtener una estructura de programa
que resulta relativamente fcil modificar y cambiar de tamao.
En esta categora hay dos subestilos: Arquitectura de Programa Principal /
Subprograma y Arquitectura de Llamada de Procedimiento Remoto.

d.- Arquitectura Orientada a Objetos: los componentes del sistema encapsulan los
datos y las operaciones que deben aplicarse para manipular los datos; la
comunicacin y la coordinacin entre componentes se consigue mediante el paso de
mensajes.

e.- Arquitectura Estratificada: hay varias capas y cada una de ellas realiza
operaciones que se acercan progresivamente al conjunto de instrucciones de la
mquina.














21
PATRONES ARQUITECTONICOS
Los patrones arquitectnicos para el software definen un enfoque especfico para el
manejo de alguna caracterstica de comportamiento del sistema.
Aqu algunos ejemplos representativos:
Concurrencia
Manejar varias tareas de manera tal que simulen paralelismo, es decir que ocurra
cada vez que un solo procesador maneja varias tareas o componentes paralelas.
Una aplicacin tiene varias maneras de manejar la concurrencia y cada una se
presenta mediante un patrn arquitectnico diferente.

Persistencia
Los datos persisten si sobreviven despus de la ejecucin del proceso que los creo
Los datos persistentes se almacenan en una base de datos o un archivo, donde en
un momento posterior otros procesos tiene la opcin de leerlos o modificarlos.
En general se emplean dos patrones arquitectnicos para lograr la persistencia:
1. Sistema de administracin de base de datos: que aplica las capacidades
de almacenamiento y recuperacin de bases de datos.
2. Al nivel de aplicacin: construye caractersticas de persistencia en la
arquitectura de esta; por ejemplo, el software de procesamiento de
palabras que maneja su propia estructura de documento.

Distribucin
El problema de la distribucin es la manera en que se comunican entre si los
sistemas o componentes en un entorno distribuido.
Este problema incluye dos elementos:
La manera en que las entidades se conectan entre si
La naturaleza de la comunicacin
Una solucin a este problema es el de Corredor, que acta como intermediario entre el
componente cliente y servidor.



22
4.3.3 DISEO DE COMPONENTES
La accin de diseo al nivel de componentes abraca una secuencia de tareas que
reducen lentamente el grado de abstraccin con que se representa el software.
El diseo a nivel de componentes describe al software en un grado de abstraccin
cercano al cdigo.
El objetivo es traducir el modelo de diseo en un software operacional para ver
los errores sutiles que resultan difciles de encontrar y corregir en etapas
posteriores del proceso de software.
El diseo de componentes define las estructuras de datos, los algoritmos, las
caractersticas de la interfaz y los mecanismos de comunicacin asignado a cada
componente.

Segn la naturaleza del software hay dos enfoques:
a.- Diseo de Componentes Basados en Clases
Principios bsicos de diseo: el motivo elemental para usarlos es para
crear diseos que sean ms sensibles al cambio y reducir la propagacin
de efectos secundarios cuando ocurran cambios.
Lneas Generales: se trata se un conjunto pragmtico de lneas
generales de diseo a medida que avanza el diseo, las interfaces y las
caractersticas de dependencia y herencias que impactan al diseo
resultante.
Cohesin: implica que un componente o una clase solo encapsula
atributos y operaciones relacionadas estrechamente entre s y con la
clase del propio componente.
Acoplamiento: es una medida cualitativa del grado al que las clases se
conectan entre s, y a medida que las clases se vuelven ms
interdependientes, el acoplamiento aumenta.








23
b.- Diseo de Componentes Convencionales
Un componente de software convencional implementa un elemento de
procesamiento que atiende una funcin o subfuncin en el dominio del
problema, los componentes convencionales no encapsulan datos de la
misma manera que los componentes orientados a objetos.
El diseo a nivel de componentes convencional requiere la representacin
de estructuras de datos, interfaces y algoritmos, que sirven como gua en la
generacin de cdigo fuente en lenguaje de programacin.
Para lograr esto, el diseador usa varias notaciones de diseo que se
representan en formatos de:
Notacin Grafica del Diseo
Notacin Tabular del Diseo
Lenguaje de Diseo de Programas

La programacin estructurada es una tcnica de diseo que restringe el
flujo de la lgica a tres construcciones:
De secuencia
De condicin
De repeticin
El objetivo de la programacin estructurada es ayudar al diseador a
definir algoritmos que sean menos complejos, y por tanto mas fciles de
leer, probar y mantener.



24
4.3.4 DISEO DE INTERFAZ DE USUARIO
El diseo de la interfaz de usuario crea un medio de comunicacin efectiva entre
el ser humano y una computadora
El propsito de la interfaz es muy simple: recoger de los usuarios la informacin
del sistema y ponerla a disposicin de otros usuarios.

REGLAS DE ORO

1. Dar el Control al Usuario
Definir los modos de interaccin de manera que el usuario no realice
acciones innecesarias o indeseables
Proporcionar una interaccin flexible
Incluir las opciones de interrumpir y deshacer la interaccin del usuario
Depurar la interaccin a medida que aumentan los grados de destreza y
permitir que se personalice la interaccin
Oculte al usuario ocasional los elementos tcnicos internos
Disear interaccin directa con los objetos que aparecen en la pantalla

2. Reducir la Carga de Memoria del Usuario
Reducir la demanda de memoria a corto plazo
Definir valores por defecto que tengan significado
Definir accesos directos intuitivos
El formato visual de la interfaz se deber basar en una metfora del
mundo real
Desglosar la informacin de manera progresiva

3. Construccin de una Interfaz Consistente
Permitir que el usuario incluya la tarea actual en un contexto que tenga
algn significado
Mantener la consistencia en toda una familia de aplicaciones
Si modelos interactivos anteriores han generado expectativas en el
usuario, no hacer cambios a menos que haya razones inexcusables











Siempre he deseado que mi computadora sea tan fcil de
manejar como mi telfono.
Mi deseo se ha vuelto realidad, ya no s cmo usar mi
telfono
Bjarne Stronstrup


25
PROCESO DE DISEO DE LA INTERFAZ DE USUARIO
El proceso de diseo de las interfaces de usuario es iterativo y se representa mediante un
modelo espiral.
El proceso de anlisis y diseo de la interfaz abarca cuatro actividades distintas de
marco de trabajo:
1. Anlisis y modelado de usuarios, tareas y entornos.
2. Diseo de la interfaz
3. Implementacin de la interfaz
4. Validacin de la interfaz de usuario
Estas tareas ocurrirn ms de una vez, es decir de manera iterativa, y en casi todos los
casos la actividad de construccin incluye la creacin de prototipos que permiten
evaluar los escenarios de uso.
El objetivo del diseo de la interfaz es definir un conjunto de objetos y acciones que
permitan que el usuario realice todas las tareas definidas, de tal manera que cumplan
todos los objetivos de facilidad de uso que define el sistema.





26
ANALISIS DE LA INTERFAZ DE USUARIO
Para comprender el problema tenemos que:
Comprender a las personas que interactuaran con el sistema
Comprender las tareas de los usuarios finales
Comprender el contenido que se presenta como parte de la interfaz
Comprender el entorno en que se realizaran estas tareas

ELEMENTOS DEL ANALISIS DE INTERFAZ
a. Anlisis del usuario: cada usuario tiene una imagen mental del software que
podra ser diferente a la del diseador; pero para hacer que estas coincidan en el
mayor rango posible, se cuenta con una amplia variedad de fuentes: entrevistas
con el usuario, informacin de ventas, informacin de mercadotecnia e
informacin proveniente de soporte.

b. Anlisis y Modelado de Tareas: aqu tambin se basan en las tcnicas ya
estudiadas pero que se aplican a la interfaz del usuario.
Entre las tcnicas tenemos los casos de uso, elaboracin de tareas, elaboracin
del objeto, anlisis del flujo de trabajo y una representacin jerrquica.
c. Anlisis del contenido de la pantalla: va de informes basados en caracteres,
pantallas graficas o informacin especializada.
Aqu se debe de considerar el formato y la esttica del contenido, es decir tal
como se despliega en la interfaz.

d. Anlisis del entorno de trabajo: tiene que ver con el entorno fsico y la cultura
del lugar de trabajo incidirn en las relaciones de trabajo con los dems.










27
PASOS DEL DISEO DE LA INTERFAZ
Aunque se han propuesto muchos modelos diferentes, todos sugieren alguna combinacin
de los siguientes pasos:
1. Con base en la informacin desarrollada durante el anlisis, definir los objetos y
las acciones de la interfaz (operaciones)
2. Definir eventos (acciones del usuario) que cambian el estado de la interfaz
(modelar este comportamiento)
3. Representar cada estado de la interfaz tal como lo ver el usuario final
4. Indicar como interpreta el usuario el estado del sistema a partir de la interfaz

En algunos casos, el diseador de la interfaz puede empezar con borradores de cada
estado de la interfaz, tomando en cuenta el entorno como la tecnologa de despliegue, el
sistema operativo y las herramientas de desarrollo que habr de usarse.




















El diseo interactivo es una mezcla integrada de artes
graficas, tecnologa y psicologa
Brad Wieners


28
EVALUACIN DEL DISEO
Una vez que se ha creado un prototipo de interfaz de usuario operacional, debe
evaluarse y determinar si satisface las necesidades del usuario.
La evaluacin podr abarcar un espectro de grados de formalidad: que va desde
pruebas de manejo informal, en donde el usuario proporciona respuestas espontneas
hasta un estudio formalmente diseado, el cual utilizar mtodos estadsticos para la
evaluacin de cuestionarios que llena una poblacin de usuarios finales.
El ciclo de la evaluacin contina hasta que ya sean innecesarias mas modificaciones al
diseo de la interfaz.
El enfoque de generacin de prototipo resulta eficaz, ahora bien es posible evaluar la
calidad de la interfaz de usuario antes de construir un prototipo? Si los problemas se
pueden descubrir y solucionar rpidamente, el nmero de bucles en el ciclo de
evaluacin se reducir y el tiempo de desarrollo se acortar.




29


Las organizaciones reconocen cada vez ms la necesidad de una implantacin
especfica, para adoptar nuevas herramientas de ingeniera de software, procesos y
mtodos. Los esfuerzos de mejora, incluyendo el proceso de mejora del software,
gestin continua de riesgos o la introduccin de un nuevo entorno de desarrollo, son tan
complejos, y sus efectos de tanto alcance, que requieren una especializacin y un
mtodo sistematizado para gestionar el ciclo vital de adopcin de tecnologa.
Segn las estadsticas, menos de 20% de los proyectos se completan en costes, plazos,
alcance y nivel de calidad.
Cuando hablamos de procesos de desarrollo de software, no estamos hablando de temas
puramente tcnicos porque est demostrado que la mayora de los problemas son
organizativos.
El objetivo consiste en mejorar los procesos de desarrollo de software de tal modo que
los proyectos sean ms predecibles (tiempo y costes), se reduzcan los riesgos en los
desarrollo (con el consiguiente ahorro de costes), etc.
Es un hecho que las empresas que ms crecen, son las que ms invierten en diseo y
mejor lo gestionan. En muchas organizaciones los responsables tcnicos han ido
prosperando y ocupando labores de responsabilidad sin haber sido correctamente
preparados: Tcnicamente pueden estar cualificados pero tienen graves deficiencias en
labores de gestin.
El problema fundamental es que se han consolidados en las empresas procesos
informales y poco estructurados que propician un desarrollo poco predecible y repetible.

5.1. DEFINICIN
Se refiere al conjunto de orientaciones puestas al servicio de las instituciones que se
dedican a planificar, disear y ejecutar actividades cuyo propsito es examinar y
potenciar sus procesos de trabajo de manera de hacerlos ms eficientes y obtener
resultados de calidad.
Acciones que se generan para la prestacin del servicio en las prcticas habituales y que
tienden a optimizar los resultados. Son experiencias exitosas que pueden ser replicadas
en su conjunto o en alguna de sus partes. Se consideran como buenas, por ser prcticas
sistematizadas de trabajo, que han resultado eficientes en determinados contextos.
V. BUENAS PRACTICAS DE DISEO

30
5.2. OBJETIVOS
Las buenas prcticas de diseo de software permiten:
Explicar un proceso de trabajo para satisfacer necesidades de los clientes.
Definir el concepto de calidad en el desarrollo de software y la relacin costes
/ beneficios.
Identificar las prioridades de valor.
Medir el impacto del diseo en los objetivos de la empresa.
Identificar y crear requisitos de usuario.
Distinguir entre diseo eficiente y diseo efectivo.
Establecer conceptos bsicos de Customer Relationship
Management.(Gestin de Relacin con el Cliente)
Relacionar la Gestin de la Calidad Total (TQM) y el diseo de software.

5.3. MOTIVOS DE FRACASO POR FALTA DE BUENAS PRCTICAS DE
DISEO:
La mayor parte de los proyectos son un caos, apenas se evalan econmicamente y la
racionalidad es una excepcin.
Con una mala gestin en prcticas de diseo slo del 15 30% del proyecto se
completan a tiempo, en el presupuesto y con las funcionalidades especificadas
originalmente.
5.3.1 GESTIN DBIL
Anlisis de negocio
Implicar usuarios
Compromiso / competencias
Gestin / riesgos
5.3.2 COMPLEJIDAD
El proceso de diseo de un producto de software es complejo porque:
Hay un elevado nmero de factores (internos y externos) que deben ser
manipulados e incorporados.
Los objetivos a cumplir pueden ser amplios.
Hay personas, organizaciones y procesos involucrados.

31
5.4. EL DISEO SE CENTRA EN EL VALOR PARA EL CLIENTE / USUARIO:
Todas las empresas existen para generar VALOR. Pero el valor es un concepto relativo,
donde cada interesado lo entiende de forma distinta. Por ejemplo:
Valor para un(a):
Negocio es el beneficio
Empleado la seguridad laboral o un buen sueldo
Gobierno que la empresa pague impuestos y cumpla las leyes
Sociedad nuevos empleos

La empresa privada no puede sobrevivir si no proporciona valor a sus clientes. Se debe
tener en cuenta lo siguiente:
ENTENDER LA PERCEPCIN de valor de los CLIENTES es un REQUISITO inicial
en cualquier estrategia de negocio.
Es decir, Valor percibido = calidad percibida en relacin al precio.

Los clientes evalan la CALIDAD segn las necesidades de USO y de ESTIMA.
El diseo de software se ocupa de las necesidades TANGIBLES o de USO.
El diseo es por tanto un trabajo fundamentalmente TIL (que trae o produce
provecho), lo que algunos hoy llaman usable.
Muchas empresas hoy en da han llegado a considerar que no solo se puede competir
por el precio de sus productos sino tambin por el valor en calidad que generan las
mismas al llegar a manos del cliente. Vale decir:
Si no hablas el lenguaje del valor, slo podrs competir por precio.





32
Caso: diseo grfico es arte
Podemos decir, pues, que diseo grfico y arte se diferencian principalmente en que
el primero busca llegar a un producto que sea aceptado por el consumidor final,
mientras que el segundo se basa en la libertad total de expresin, sin importar si es
aceptado o no.
El diseador grfico, adems, las ms de las veces trabaja en equipo y valindose de
otras disciplinas para lograr que su trabajo final cumpla con las condiciones
necesarias.
Esto no significa que si uno es diseador grfico excluyentemente no sea artista, todo
lo contrario, las ms de las veces el artista utiliza su libertad para lograr un mejor
trabajo relacionado con el diseo. Adems, muchos artistas trabajan como
diseadores para solventarse econmicamente, aunque su amor este en direccin al
arte. El diseo grfico es una actividad que no desagrada y tiene muchos puntos de
contacto con el arte.
Por tanto culminemos diciendo que existe una diferencia entre diseo grfico y arte;
el fin de su realizacin, lo cual justifica los medios.

Identificar las prioridades de VALOR de los clientes es necesario para invertir o medir
el rendimiento de un producto.
Sin una respuesta clara con DATOS y HECHOS a estas respuestas, cualquier diseo
estar basado nicamente en SUPOSICIONES / INTUICIN, pero no en proceso
metodolgico .Ejemplo:
Qu valoran tus clientes ahora?
Con qu prioridad?
Cmo de bien / mal tu empresa cumple?
Por qu tu empresa lo hace bien / mal?
Qu van a valorar en el futuro?



33
5.5. LA CALIDAD EN EL DISEO:
La Calidad implica:
5.5.1 Consistencia: Cumplir la especificacin no es un hecho aislado, sino un
proceso diseado y controlado que asegura el cumplimiento.
Un proceso intuitivo NUNCA podr serlo.
Medir el impacto del proyecto.
5.5.2 Conformidad: Necesidad de cumplir las especificaciones.
Si apenas existen las especificaciones de usuario en los proyectos los
tales son de baja calidad
5.5.3 Expectativas: ni necesidades (requisitos bsicos) ni deseos (todo, cualquier
cosa).
Para la gestin total de la calidad (Total Quality Management), cumplir las expectativas
de los clientes, significa ms:
Implica VER LAS COSAS DESDE LA PERSPECTIVA DEL CLIENTE.
Esto implica ver a la empresa como un proceso, que afecta a toda la
organizacin, contra la visin tradicional de
funciones/competencias/departamentos.



34
5.6. IMPACTO ECONMICO
Las empresas que ms crecen son las que ms invierten en diseo.
5.6.1.- El diseo es capaz de aportar beneficios cuantitativos y cualitativos en
empresas de cualquier sector.
5.6.1.1.- Beneficios Cuantitativos:
El diseo incide sobre la facturacin: de las empresas que ms crecen, el
60% asegura que existe una correlacin entre la inversin en diseo y el
aumento de la facturacin.
La inversin en diseo facilita la apertura a nuevos mercados: un 15,5%
de las empresas asegura que su inversin en diseo facilita mucho la apertura
a nuevos mercados, mientras que un 40,9% opinan que facilita bastante dicha
apertura, y un 20% asegura que la facilita algo.
El diseo tambin mejora la productividad: Ms de la mitad de las
empresas considera que invertir en diseo afecta positivamente a la
productividad, reduciendo costes y tiempo.
El diseo ayuda a competir y posicionarse en el mercado: Cuando
competir por precio no es una opcin, el diseo parece ser la opcin ms
utilizada.
El diseo es una solucin a las demandas de los usuarios, y ayuda a
integrar los avances tecnolgicos y los condicionantes del mercado.
Las empresas que ms crecen son las que mejor utilizan el diseo: Si
hasta ahora tena el concepto de que el diseo se trata de un ejercicio de estilo
o esttica, o en definitiva, de un bien superfluo, de una herramienta ftil que
supona un lujo para su empresa, sepa que es algo que le ocurre a muchas
empresas. Sin embargo esta tendencia est cambiando y el diseo ya se
considera como una herramienta de diferenciacin y mejora empresarial.





35
5.6.1.2.- Beneficios Cualitativos:
El diseo mejora la percepcin que los clientes tienen de una empresa, y
ayuda a atraer a clientes potenciales. A travs del diseo se refuerza y se da
visibilidad a la identidad de un producto o empresa, haciendo que los
destinatarios perciban con claridad los valores de la misma, tales como
seriedad, organizacin, etc. El 74% de las empresas consideran que el diseo
ayuda a mejorar su imagen y su relacin con los clientes. Entre las empresas
de mayor crecimiento, este porcentaje supera el 96%.
Provoca que la percepcin de la calidad del servicio o producto sea an
ms evidente, e incluso se puede conseguir vender productos de baja
calidad consiguiendo que los usuarios los perciban como superiores. En
este sentido habra que entrar a valorar la tica del procedimiento, pero
conviene recordar casos como el de la conocida bodega gallega que venda el
mismo vino en dos gamas: una normal y una gran reserva, y siendo el mismo
producto lograba engaar incluso a los someliers. Y todo gracias a una simple
etiqueta.
Ello provoca al mismo tiempo una mejora en la experiencia del cliente,
haciendo que ste quede ms satisfecho, y ayudando a fidelizarle. Ms del
95% de las empresas que ms crecen consideran que el diseo ayuda a
mejorar la satisfaccin de sus clientes.
Con el diseo se consigue mejorar la motivacin, la satisfaccin y la
integracin de los trabajadores, reforzando el sentimiento de pertenencia a
su empresa, y hacindoles lgicamente ms productivos y comprometidos
con los objetivos de la misma. Ms del 60% de las empresas afirman que el
diseo mejora la satisfaccin y motivacin de sus empleados.
Tambin se consigue mejorar la comunicacin interna en una empresa,
segn afirman ms del 60% de las empresas.
La rentabilidad del diseo no slo hay que medirla en nmeros, sino
tambin en calidad, satisfaccin y esa expresin que tanto buscan mejorar
las empresas hoy en da que es la experiencia de marca


36
5.6.2. EL DISEO APORTA VALOR AADIDO, ES CALIDAD DE PRODUCTO,
AHORRA COSTES Y TIEMPOS PERMITIENDO APROVECHAR MEJOR LAS
CAPACIDADES DE LAS PERSONAS
Las empresas que ms crecen son las que ms invierten en diseo. Ejercido por
profesionales y adecuadamente gestionado, el diseo es capaz de aportar beneficios
cuantitativos y cualitativos antes ya mencionados en empresas de cualquier sector.
Segn, La DDI, sociedad estatal para el desarrollo del diseo y la innovacin en el
ao 2005.
Las conclusiones del primer estudio de La Sociedad Estatal para el Desarrollo del
Diseo y la Innovacin S.A. (DDI), realizado a 1000 empresas espaolas de ms de 20
empleados, sobre el impacto econmico del diseo en sus negocios.
De la intromisin y psima gestin de no profesionales en cuestiones de diseo, el
estudio tambin concluye que las empresas de mayor crecimiento son las que mejor
organizan la funcin diseo. Se clasifican as:
1) No Diseo: el diseo juega un papel insignificante en el negocio de una empresa
2) El diseo como estilo: La mayora de las empresas entienden el diseo como un
ejercicio de estilo (modelo agencia). Diseo se refiere principalmente al diseo
exterior o la forma de un producto.
3) El diseo es un proceso: Se usa para mejorar la EFICIENCIA, (y que son las
tcnicas que hoy voy a comentar).
4) Diseo como innovacin: Dirigiendo todas las actividades para satisfacer las
necesidades de los usuarios.







37
5.6.3.- El Diseo De Procesos en las Operaciones De Negocio
El diseo de un producto y su proceso de creacin no pueden separarse, especialmente
en los servicios, donde el proceso es el servicio.
Los costes de rectificar errores se incrementan cuanto ms tiempo permanezcan en el
proceso.
El diseo de un producto y su proceso de creacin no pueden separarse, especialmente
en los servicios, donde el proceso es el servicio.
Este aspecto est relacionado con el proceso de desarrollo (incremental y no en cascada)
y las competencias de los componentes de un equipo.


5.7. TEST DE USUARIOS
El Testing es un anlisis EMPRICO que verifica las especificaciones de requisitos en
condiciones concretas. Incluye los defectos de forma y los bugs (defectos de
software/errores de programacin).
La Test de Usuarios en la Prctica de diseo de Software se basa a travs de mtodos de
verificacin, los cuales son:
Testing: es el mtodo de verificacin ms riguroso.
Inspeccin: usando los sentidos o con medidas mecnicas.
Demostracin: probar que algo se puede hacer.
Anlisis: modelos matemticos, simuladores, clculos
Certificacin: Basado en un certificado que alguien otorga.

38
5.7.1.-Test En el Cdigo estndar:
Cada Desarrollador es responsable de que su cdigo sea funcional, Pero
adems en la fase de Testing deber testear cdigo que no ha sido
desarrollado por l.
TI P: nunca puedes testear tu propio cdigo. Tambin cuando escribas
cdigo, documentar que es lo que hace la clase/mtodo es de suma
importancia para el tester y para el luego mantenimiento del cdigo
El 80% del coste del cdigo de un programa va a su mantenimiento.
Casi ningn software lo mantiene toda su vida el autor original.
Las convenciones de cdigo mejoran la lectura del software,
permitiendo entender cdigo nuevo mucho ms rpidamente y ms a
fondo.
Si distribuyes tu cdigo fuente como un producto, necesitas asegurarte
de que est bien hecho y presentado como cualquier otro producto.
Cada tipo de modificacin debe ser debidamente documentado, de
acuerdo a estndares.

Conclusin: es una buena prctica utilizar y respetar las
convenciones en la escritura del cdigo.
5.7.1.1.-Como reportar un bug:
Si existe algn error, anomala o defecto en la funcionalidad de una cierta
caracterstica es catalogado como un bug.
Depende de lo que MIDAS obtienes un producto con una determinada
calidad.




39
5.7.2.- Resultado del Test:
Recordando que es EMPRICO, es decir: hechos experimentales y no en
OPINIONES.
Intuitivo, no es fcil de usar, fresco, altamente funcional, diseo
limpio, diseo arriesgado, aprueba en criterios de usabilidad, de fcil
uso, claramente orientado a sus clientes.
5.7.3.- Diferencia entre un test de usabilidad/usuarios y los tradicionales:
beta Testing
5.7.3.1.-Los test de usabilidad , se pueden hacer durante todo el proceso de
desarrollo, utilizando prototipos o versiones parciales del producto.
Observas a tus usuarios.
Realizas entrevistas.
Grabas a personas seleccionadas.
El objetivo se especifica de forma concreta.
Los participantes son usuarios reales.
Los participantes realizan tareas reales.
Se observa y graba lo que hacen y dicen.
Se analizan los datos, diagnostican problemas y recomiendan cambios
para solucionarlos.
Un test de usabilidad es una medida emprica de la usabilidad de una
herramienta, sitio o aplicacin, tomada a partir de la observacin sistemtica
de usuarios llevando a cabo tareas reales.
El test de usabilidad, nos permitir:
Verificar la existencia de posibles problemas de usabilidad en el sitio.
Encontrar posibles soluciones para los problemas encontrados.
Establecer una medida concreta inicial contra la cual comparar a los
competidores, futuros desarrollos de este mismo sitio o modificaciones al
actual.

40
5.7.3.2.-Los beta Testing, son pruebas de software al proceso que permite
verificar y revelar la calidad de un producto software cuando ste est parcial
o totalmente terminado. En esa fase los errores crticos se pueden arreglar,
pero los errores de usabilidad no. La usabilidad NO ES dar a tus clientes una
versin del producto y esperar su reaccin.
Los betas Testing rara vez producen informacin relevante sobre problemas
de usabilidad porque:
La respuesta no es sistemtica. Los usuarios pueden o no dar su
opinin, y si lo hacen, cuentan lo que recuerdan o lo que quieren.
No se observa ni se graba al usuario. Al contrario que un test de
usabilidad, donde ves lo que hacen y se graba.
No controlas las tareas. En un beta Testing, las tareas que se realizan
son las que el usuario quiera hacer al usar tu producto. En un test de
usabilidad, un profesional elije las tareas, asegurando as que se
comprueban los objetivos del producto.
Debes considerar que aunque tus clientes sepan que usan una versin beta de
tu producto, una mala experiencia les har estar menos dispuestos a probar
se u otros productos de tu empresa.
5.7.4.-TEST DE USABILIDAD y La Realidad
La mayor parte de los test (si se hacen), se producen al final del proceso cuando
est parcial o totalmente terminado el producto. En esa fase slo los errores
crticos se pueden arreglar, pero no el VALOR / CALIDAD del producto.
Debemos de tener en cuenta lo siguiente:
5.7.4.1.- Valor + Metodologa y no slo la herramienta: se puede tener la
mejor herramienta para el proceso de desarrollo, pero si no se tiene en cuenta
el valor (calidad) y la utilizacin de una metodologa para el mismo,
obtendremos errores que nos llevaran a la no satisfaccin del cliente.
5.7.4.2.- Aclarar los diseos visuales y la efectividad de contenidos: se
deben de aclarar los diseos dependiendo la necesidad del usuario de tal
forma que los contenidos de los mismos garanticen su satisfaccin.
No olvidando que todo se debe realizar bajo estndares de calidad.

41
5.8.-METODOLOGA, PROCESOS Y CASOS DE USO
El software no es ARTE, sino un producto de consumo, es por tanto un PRODUCTO
industrial ms. Lo que los clientes quieren y compran, no es un software, sino los
beneficios que ese producto produce.
Cuanto ms maduro es el mercado, hay cada vez menos diferencia, y la tecnologa no
la genera por s misma.
Para lo cual se distinguen dos tipos de diseo:
Diseo Eficiente: minimizar los costes de produccin. Ejemplo:
Cdigo fuente de 350KB a 100KB.
Diseo Efectivo: proporcionar los atributos demandados por los
clientes en mercado.
5.8.1.-Anlisis de NEGOCIO: Cuando se desea desarrollar un producto software se
deben considerar Los costos y beneficios, de acuerdo a las siguientes interrogantes:
La inversin va a ser RENTABLE?: cmo? Cundo?
Hay otras alternativas?
Qu opcin es la ms rentable?: tiempo, dinero, recursos.
5.8.2.-REQUISITOS: Los requisitos de usuario son fundamentales y deben incluir
CASOS DE USO que describan las interacciones y PERFILES de usuario.
Identificar a todos los usuarios permite tomar decisiones con criterio sobre su grado
de implicacin en un proyecto para que tenga xito.
5.8.2.1.- Quin es realmente tu usuario?: para medir riesgos
//caso del cliente del cliente del cliente: todo para el pueblo pero sin el
pueblo//
5.8.2.2.- Importancia De La Definicin De Los Requisitos
Ver es comprender: no escribas pginas y pginas de requisitos,
potencia los requisitos VISUALES.
// Caso: tiene pocas pginas para lo que vale, escribe ms //
Con planos, mapas de procesos.
Diagramas (ejemplo: caso de uso).
Recopila la mayor cantidad de informacin posible sobre los clientes que sean de
UTILIDAD para poder dar valor. Administrar la relacin con los clientes, Customer
Relationship Management CRM, es parte de una estrategia de negocio centrada en el
cliente.

42
5.8.3.-REUTILIZACIN (componentes / marcos / patrones de diseo): No
construyas/analices de nuevo algo que ya existe dentro o fuera de tu empresa.
5.8.4.-Reconocer Escenarios: Un escenario es una descripcin narrativa informal
(Carroll 2000) en forma de historia de actividades humanas o tareas.
Entender qu hace la gente, es un buen punto de partida para saber cmo funciona un
producto.

5.8.5.-Prototipos: Utiliza metodologa para priorizar los requisitos.
Quality Function Deployment (QFD): Mtodo para transformar las demandas de los
usuarios en calidad de diseo, priorizando las caractersticas del producto. De uso
extensivo en Toyota.
La forma de valorar el cmo, DEBE emplear un criterio de evaluacin.
5.8.6.-MEJORA CONTINUA / LECCIONES APRENDIDAS: usando auditoras
al final de cada proyecto. Con consecuencias en la cultura / estructura / procesos /
responsabilidades de todos los implicados.
// Comentar caso call-center //
5.8.6.1.-Lecciones Aprendidas:
Generacin de Ideas
Valorar Ideas
Prototipo
Evaluacin
Diseo Final








43
5.9 CMMI :
BUENAS PRCTICAS PARA EL DESARROLLO DE SOFTWARE
CMMI (Capability Maturity Model Integration) es un modelo concebido para mejorar
los procesos de desarrollo y mantenimiento de productos de software.
CMMI tambin se inspira en buenas prcticas de la industria y de la experiencia
adquirida en la evaluacin e implantacin de mejora de procesos en entornos reales.
Es un modelo de calidad del software que clasifica a las empresas de acuerdo al nivel de
madurez en los procesos de produccin de sus aplicaciones.
El modelo permite a las empresas de desarrollo de software evaluar su capacidad para
producir productos de calidad con la mejor eficiencia y eficacia, y propone un sistema
de mejora continua de los procesos para lograr unos mximos resultados. CMMI consta
de 5 niveles de madurez:



5.9.1.- NIVELES DE MADUREZ DE CMMI
Desarrollo - Estado inicial donde el desarrollo se basa en la heroicidad y
responsabilidad de los individuos.
Los procedimientos son inexistentes o localizados a reas concretas.
No existen plantillas definidas a nivel corporativo.
Gestionado - Se normalizan las buenas prcticas en el desarrollo de
proyectos (en base a la experiencia y al mtodo).
En este nivel consolidado, las buenas prcticas se mantienen en los
momentos de estrs.
Estn definidos los productos a realizar.
Se definen hitos para la revisin de los productos.

44
Definido - La organizacin entera participa en el proceso eficiente de
proyecto software.
Se conoce de antemano los procesos de construccin de software.
Existen mtodos y plantillas bien definidas y documentados.
Los procesos no solo afectan a los equipos de desarrollo sino a toda la
organizacin relacionada.
Los proyectos se pueden definir cualitativamente.
Cuantitativamente Gestionado
Se puede seguir con indicadores numricos (estadsticos) la evolucin de
los proyectos.
Las estadsticas son almacenadas para aprovechar su aportacin en
siguientes proyectos.
Los proyectos se pueden pedir cuantitativamente.
Optimizado
En base a criterios cuantitativos se pueden determinar las desviaciones
ms comunes y optimizar procesos.
En los siguientes proyectos se produce una reduccin de costes gracias a
la anticipacin de problemas y la continua revisin de procesos
conflictivos.
3.10 MS DETALLES DE BUENA PRCTICAS DE DISEO DE SOFTWARE
BUENAS PRCTICAS DE GENERACIN DE SOFTWARE
La razn principal de implementar las buenas prcticas es que finalmente todo el
tiempo perdido, se convierte en costos que afecta los resultados de un proyecto,
pues generalmente se usa ms del tiempo planeado para las pruebas. Para los
administradores de proyectos, la correcta administracin es la que lleva a obtener
buenos resultados.




45
Se pueden considerar las siguientes:
Hacer una evaluacin del trabajo de cada integrante del equipo. Concienciar al
equipo de la importancia que tienen las pruebas y el valor que tienen para cada
miembro del equipo y as generar cooperacin y coordinacin entre los
miembros del mismo.
Establecer un plan maestro integrado. Establecer claramente las funciones y
responsabilidades de los equipos de desarrollo y pruebas
Considerar las pruebas preventivas como parte de las especificaciones de
trabajo. Disear previamente los escenarios de prueba, dentro del desarrollo de
software, y realizar revisiones para asegurarse de que lo que se est
construyendo cumple con los requerimientos solicitados.
Usar las pruebas como puntos de control y progreso. Realizar pruebas y
revisiones formales para verificar y demostrar que todos los productos claves
del proyecto han sido realmente terminados.
Inventario de los objetivos de pruebas y diseo para factibilidad. Revisar la
factibilidad en la realizacin de las pruebas.
Probar pronto y frecuentemente. Hay que probar lo antes y ms frecuentemente
posible; esto permitir detectar los problemas tan pronto surjan, de esta manera
el desarrollador ser ms eficiente en las correcciones.
Disear y desarrollar el testware como el software. Esto implica planear,
analizar, disear, supervisar, controlar los cambios, administracin; en suma,
desarrollar el testware con la misma disciplina con que se desarrolla el
software.
Proporcionar una herramienta integrada de pruebas, evaluacin y de soporte de
infraestructura. Proporcionar herramientas que incluyan: Base de datos o
repositorio, Administracin de pruebas, que permita documentar, ejecutar y
clasificar pruebas, Soporte automtico, Simuladores, Analizadores de software,
Manejadores de pruebas, Herramientas de captura y repeticin (playback) y
utileras.
Medir el costo, el alcance, los resultados y la efectividad de las pruebas y
evaluacin. Coleccionar informacin que permita conocer el costo, los
resultados y los beneficios as como el alcance.
Entrenar y administrar al equipo. Proporcionar el liderazgo y administracin al
equipo con el fin de que sepa lo que se espera de l para que se tomen las
pruebas seriamente. Definir los criterios de "mejores prcticas".

46
3.11. CONSTRUCCIN DE SOFTWARE - MTODO
Construccin de buenas reglas
Ciertamente no es fcil legislar sobre construccin de software y es grande el
peligro de producir reglas intiles, poco meditadas o incluso dainas.
Los principios que se enumeran a continuacin, basadas en el anlisis del papel
de la metodologa en el software, pueden ayudarnos a evitar tales peligros.
Bases tericas: las reglas de metodologa del software deben basarse en una
teora sobre el tema subyacente.
Bases prcticas: las reglas de metodologa del software deben estar
respaldadas por una amplia experiencia prctica.
Experiencia en reutilizacin
Tipologa de reglas: una regla pude ser de recomendacin ( invita a seguir
un cierto estilo) o absoluta ( plantea que hay que trabajar de una cierta
manera ); y puede anunciarse de forma positiva ( indicando lo que se debe
hacer ) o negativa ( indicando lo que no se debe hacer ).
Excepciones: si una regla metodolgica presenta una gua que es aplicable
en general pero que tiene excepciones, las excepciones deben anunciarse
como parte de la regla.
Conclusin: es una buena prctica basar el mtodo sobre reglas claras.

3.12. PROCESO DE DESARROLLO ACTIVIDADES
Un proceso de desarrollo es un mtodo de organizar las actividades relacionadas
con la creacin, presentacin y mantenimiento de los sistemas de software.
Una de las caractersticas principales de un proceso de desarrollo es el ciclo de
vida iterativo. Un ciclo de vida iterativo se basa en el agrandamiento y
perfeccionamiento secuencial de un sistema a travs de mltiples ciclos de
desarrollo de anlisis, diseo, implementacin y pruebas. El ciclo de vida
iterativo se basa en una idea muy simple, cuando un sistema es demasiado
complejo para ser comprendido, diseado o realizado de golpe, o incluso las tres
cosas a la vez, es mejor realizarlo en varias etapas por evoluciones. En la
naturaleza, los sistemas complejos que funcionan son siempre evoluciones de
sistemas ms simples. Las iteraciones debern estar controladas por casos de

47
uso, es decir que los ciclos de vida iterativos de desarrollo se organizan a partir
de los requerimientos del caso de uso.
El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables,
medibles y, por lo tanto, en la evaluacin de elementos concretos. Se opone al
ciclo de vida en cascada que se basa en la elaboracin de documentos. Las
entregas fuerzan al equipo a dar resultados concretos regularmente, lo que
permite evitar el sndrome del 90% terminado, con an el 90% por hacer. El
desarrollo regular de las iteraciones facilita el tener en cuenta los problemas; los
cambios se incorporan en las iteraciones futuras en lugar de distraer e
interrumpir los esfuerzos.
A lo largo del desarrollo, se muestran ciertos prototipos a los usuarios y a los
clientes. La demostracin de los prototipos presenta numerosas ventajas:
El usuario se coloca delante de situaciones de uso concretas que le
permiten estructurar mejor sus deseos y comunicarlos al equipo de
desarrollo;
El usuario se hace colaborador del proyecto; toma su parte de
responsabilidad en el nuevo sistema, y de hecho, lo acepta ms fcilmente;
El equipo de desarrollo est ms motivado debido a la proximidad del
objetivo;
La integracin de los diferentes componentes del programa se realiza de
manera progresiva, durante la construccin, sin el efecto bin bang al
aproximarse al fecha de entrega;
Los progresos se miden por programas demostrables en lugar de
documentos o estimaciones como en el ciclo de vida en cascada. Se
dispone as de elementos objetivos y pueden evaluar los progresos y el
estado de avance con mayor fiabilidad.
En contrapartida, el ciclo de vida iterativo exige ms atencin e implicacin de todos los
actores del proyecto. Debe ser presentado y comprendido por todos: los clientes, los
usuarios, los desarrolladores, el control de calidad, los probadores, los documentalistas.
Todos deben organizar su trabajo en consecuencia.

Conclusin: es una buena prctica realizar iteraciones en el ciclo de vida de
un desarrollo.

48
3.13. DISEO A LA IMPLEMENTACIN
La escritura de cdigo es una extensin del proceso de diseo. Hay que tomar
decisiones mientras se escribe el cdigo, pero cada una de ellas debera de afectar
solamente a una pequea parte del programa, de tal manera que fuera fcil
cambiarlas. El cdigo del programa es la personificacin ltima de la solucin del
problema, as que la forma en que se escriba ser importante para la
mantenibilidad y la extensibilidad.
La manera ms fcil de implementar un diseo orientado a objetos conlleva el uso
de un lenguaje orientado a objetos, pero incluso los lenguajes orientados a objetos
ofrecen distinto grados de apoyo para los conceptos orientado a objetos. Cada
lenguaje supone un compromiso entre potencia conceptual, eficiencia y
compatibilidad.

Conclusin: es una buena prctica realizar un exhaustivo examen del
lenguaje de programacin que se utilizar, para que se ajuste a los
requerimientos del desarrollo.















49


La ingeniera de diseo debe siempre comenzar considerando los datos, que son el
fundamento para todos los otros elementos del diseo.
Una construccin bien diseada muestra: firmeza, comodidad y placer
Sin diseo se corre el riesgo de construir un sistema inestable, que ser difcil de
probar y cuya calidad no podr evaluarse sino hasta etapas tardas del proceso del
software.
En una organizacin o empresa, el anlisis y Diseo de Sistemas, es el proceso de
estudiar su Situacin con la finalidad de observar cmo trabaja y decidir si es
necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el
analista de sistemas.
Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio
de Sistemas para detectar todos los detalles de la situacin actual de la empresa.
La informacin reunida con este estudio sirve como base para crear varias
estrategias de Diseo. Los administradores deciden que estrategias seguir. Los
Gerentes, empleados y otros usuarios finales que se familiarizan cada vez ms con
el uso de computadoras estn teniendo un papel muy importante en el desarrollo
de sistemas.
Todas las organizaciones son Sistemas que actan de manera recproca con su
medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que
pueden estar formados por otros Sistemas de denominan Sub-sistemas y
funcionan para alcanzar los fines de su Implantacin








VI. CONCLUSIONES

50


[Libro de Consulta]
Ingeniera del software Un enfoque prctico (Sexta edicin)
Roger S. Pressman
McGrawHill

[Anexos Web]
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=cultura
[G001]
http://todoinformatica.lacoctelera.net/
[G002]

http://www.slideshare.net/nicbet/studying-the-impact-of-social-structures-on-
software-quality
http://www.slideshare.net/javiergs/sdp-parte-3
http://www.slideshare.net/javiergs/200812-patrones-de-diseo-de-software
http://www.kctech.com.mx/Soluciones/software.html
http://www.wikilearning.com/articulo/mds360degmetodologias-de-desarrollo-
de-software
http://www.monogrfias.com/trabajos73/diseno-software/diseno-software.shtml

VII. BIBLIOGRAFIA