FACULTAD DE INGENIERIA DE SISTEMAS

CURSO
CONTROL Y CALIDAD DE SOFTWARE

CATEDRTICO
ALONSO MORALES

INTEGRANTES

Crdenas Gutirrez, Jos Luis Flores Flores, Noheli Pacheco Loyola, Luis Miguel

FECHA
20 / 06 / 2011

NOTA

TRABAJO
Anlisis y Diseo de Software

INDICE
Contenido
I. II. III.
Introduccin Consideraciones Tericas Estructura Interna del Software 3.1 Estructura Y Arquitectura Del Software 3.1.1 Riesgos 3.1.2 Ventajas de un Diseo Ascendente 3.1.3 Patrones Micro Arquitectnicos 3.2 Anlisis de Dominio 3.3 Modelado de Datos 3.3.1 Objetos de Datos 3.3.2 Atributos 3.3.3 Relaciones 3.3.4 Cardinalidad y modalidad 3.4 Anlisis orientado a objetos Consideraciones de Diseo de Software 4.1 Transformacin de un M.A a un Modelo de Diseo 4.2 Conceptos Fundamentales 4.3 Metodologas de Diseo
4.3.1 Diseo de Datos 4.3.2 Diseo Arquitectnico 4.3.3 Diseo de Componentes 4.3.4 Diseo de Interfaz

Pgina
02 03 05 05 06 06 07 08 09 09 09 09 09 10 11 11 13 16 16 17 22 24

IV.

V.

Buenas Prcticas de Diseo 5.1 Definicin 5.2 Objetivos 5.3 Motivos de fracaso 5.4 Diseo se centra en el valor cliente/usuario 5.5 La calidad en el diseo 5.6 Impacto Econmico 5.7 Test de Usuarios 5.8 Metodologa, Procesos y Casos de Uso 5.9 CMMI 5.10 Ms detalles Conclusiones y Recomendaciones Bibliografa

29
29 30 30 31 33 34 37 41 43 44

VI. VII.

49 50

I.
Objetivo:

INTRODUCCION

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.

II.

CONSIDERACIONES TEORICAS

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.

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

III.

ESTRUCTURA INTERNA DEL SOFTWARE

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.

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 tiempo. - Evita un problema mayor asociado a un problema con un enfoque ascendente. cuales se puede ahorrara mucho

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"

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.

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.

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.

10

IV. CONSIDERACIONES DE DISEO

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.

11

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 potenciales? Cmo puedo disear una aplicacin que se adapte a una audiencia global y requiere un esfuerzo mnimo para localizar? los usuarios

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.

12

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.

13

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.

14

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

15

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.

16

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.

17

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.

18

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.

19

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.

20

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.

21

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.

22

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.

23

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

24

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.

25

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.

26

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

27

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.

28

V. BUENAS PRACTICAS DE DISEO

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.
29

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.
30

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 Empleado Gobierno Sociedad es el beneficio la seguridad laboral o un buen sueldo que la empresa pague impuestos y cumpla las leyes 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.

31

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?

32

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.

33

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.

34

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

35

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.

36

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.
37

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. TIP: 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.

38

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.

39

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.
40

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.
41

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

42

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.
43

 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.

44

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".
45

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

46

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.

47

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.

48

VI.

CONCLUSIONES

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

49

VII.
[Libro de Consulta]

BIBLIOGRAFIA

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 http://todoinformatica.lacoctelera.net/
[G002] [G001]

http://www.slideshare.net/nicbet/studying-the-impact-of-social-structures-onsoftware-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-desarrollode-software http://www.monogrfias.com/trabajos73/diseno-software/diseno-software.shtml

50