1.1 Objetivos e importancia del diseño de sistemas

El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos

de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde

el punto de vista funcional como del no funcional.

Existen diferentes definiciones de lo que es el diseño de sistemas, entre las cuales se pueden destacar:

Por tal razón, el diseño de sistema persigue los siguientes objetivos:

Generales Específicos

Satisfacer los requerimientos de los usuarios

Efectuar en forma correcta los procedimientos apropiados

Presentar en forma apropiada y adecuada la información

Proporcionar resultados exactos

Utilizar métodos de interacción apropiados

Proporcionar confiabilidad

Especificar los elementos de diseño lógico

Describir las características de un sistema de información: entrada, salida, procedimientos, archivos, bases de datos.

Proporcionar las especificaciones de software

Especificar los componentes y funciones con suficiente detalle para construir el software.

Ajustarse a estándares de diseño

El diseño y su especificación debe estar en concordancia con estándares de desarrollo así como con las reglas establecidas por la organización.

Fácil de usar Las buenas prácticas de diseño ergonómico deben contribuir a

la efectividad y eficiencia del usuario.

El objetivo más importante es: Entregar las funciones requeridas por el usuario (Satisfaga una especificación

funcional dada).

Pero además para lograr esto deben de considerarse los aspectos de: (Rendimiento, Control y

Confiabilidad).

1.2 Perfil del diseñador de sistemas

Perfil Ocupacional

Desarrollo de soluciones de software

Gestionar bases de datos, gestionar sistemas de redes informáticas.

Explorar problemas y generar diseños y soluciones inteligentes de sistemas informáticos mediante

análisis de tecnología y costos de software y hardware para una empresa

Conformar equipos, procesos y sistemas de desarrollo de tecnologías informática con destreza y

habilidad

Perfil De Estudiante

Estudiantes interesados en el lenguaje de la tecnología

Estudiantes con unas bases en conocimientos de software, hardware y redes tecnológicas.

Estudiantes creativos, innovadores y éticos con una gran capacidad de servicio

1.3 Elementos de hardware y software a considerar en el diseño

El diseño del sistema se representa a través de dos fases:

a) El diseño Lógico

Unidad aritmético- lógica

Unidad de control

La memoria

La entrada y la salida

b) El diseño Físico

Lenguaje de programación

Sistema Operativo

Podemos decir que el diseño lógico de sistemas se refiere lo que ara el nuevo sistema, mientras que el diseño

físico de sistemas es la forma es la manera en la que se lograran las tareas , lo que incluye la manera de

combinar sus componentes y las funciones que realizara cada uno de estos; en otras palabras, es la expresión

conceptual de lo que ara el sistema para resolver los problemas identificados en el análisis previo.

1.4 Metodologías para el diseño de sistemas

Fase de diseño de políticas o pre-planeación.

Fase de evaluación.

Fase de acción-implantación.

Fase 1. Preplaneación o diseño de políticas es la fase durante la cual:

1. Se llega a un acuerdo de lo que es el problema.

2. Se llega a una determinación por los autores de decisiones de puntos de vista mundiales (premisas, suposiciones, sistemas de valor, y estilos cognoscitivos).

3. Se llega a un acuerdo sobre los métodos básicos por los cuales se interpretará la evidencia.

4. Se llega a un acuerdo sobre qué resultados (metas y objetivos) se esperan de los clientes (expectativas) y por los planeadores (promesas).

5. Se inicia la búsqueda y generación de alternativas.

Fase 2. La evaluación consiste en evaluar las diferentes alternativas propuestas para determinar el grado

al cual satisfacen las metas y objetivos implantados durante la fase anterior. La evaluación incluye:

1. Una identificación de los resultados y consecuencias derivados de cada alternativa.

2. Un acuerdo de que los atributos y criterios elegidos con los cuales se evaluarán los resultados, representa verdaderamente las metas y objetivos pre-establecidos a satisfacer.

3. Una elección de la medición y modelos de decisión, con los que se usarán para evaluar y comparar

alternativas. 4. Un acuerdo en relación al método por el cual se hará la elección de una alternativa en particular.

Fase 3. La implantación de la acción, es la fase durante la cual el diseño elegido se pone a efecto. La

implantación incluye todos los problemas “malos” de

1. Optimización, que describe donde está la “mejor” solución. 2. Sub-optimización, que explica por qué no puede lograrse la “mejor” solución. 3. Complejidad, que trata con el hecho de que, de tener solución, debe simplificarse la realidad, pero para

ser real, las soluciones deben ser “complejas”. 4. Conflictos, legitimación y control, que son problemas que afectan, pero no son exclusivos de la fase de

implantación del diseño de sistemas. 5. Una auditoría o evaluación de resultados obtenidos del implemento del diseño de sistemas, que significa

optimismo o pesimismo de que los objetivos pueden realmente satisfacerse y proporcionarse los

resultados prometidos. 6. Reciclamiento desde el comienzo, que ocurre a pesar de sí los resultados significan éxito o fracaso.

1.5 Evidencias resultado del diseño de sistemas

2.1 Arquitectura de software

Usando alguna de las metodologías de diseño del software se producirá un determina do tipo de estructura del software.

2.1.1 Capa de presentación

Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario,

le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para

comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de

ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.

2.1.2 Capa de negocio

Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las

respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se

establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las

solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o

recuperar datos de él. También se consideran aquí los programas de aplicación.

2.1.3 Capa de acceso a datos o de base de datos

3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de negocio, y otra serie de ordenadores sobre los cuales corre la base de datos. En una arquitectura de tres niveles, los términos "capas" y "niveles" no significan lo mismo ni son similares.

El término "capa" hace referencia a la forma como una solución es segmentada desde el punto de vista lógico:

Presentación. (Conocida como capa Web en aplicaciones Web o como capa de usuario en Aplicaciones Nativas) Lógica de Negocio. (Conocida como capa Aplicativa) Datos. (Conocida como capa de Base de Datos)

En cambio, el término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo:

Una solución de tres capas (presentación, lógica del negocio, datos) que residen en un solo ordenador (Presentación+lógica+datos). Se dice que la arquitectura de la solución es de tres capas y un nivel.

Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos ordenadores (presentación+lógica por un lado; lógica+datos por el otro lado). Se dice que la arquitectura de la solución es de tres capas y dos niveles.

2.2 Arquitectura de hardware

Es el conjunto de dispositivos físicos que hacen posible el funcionamiento de un computador; Éste abarca todos

los componentes eléctricos y mecánicos que permiten llevar a cabo en una computadora el almacenamiento y

procesamiento de información.

COMPONENTES DE UN HARDWARE Un sistema computacional consiste en un conjunto de componentes electrónicos y electromecánicos

interconectados que almacenan y transforman símbolos en base a las instrucciones especificadas en los componentes software del mismo sistema.

Conceptualmente, es posible distinguir 5 tipos de componentes hardware:

Memoria principal

Procesadores Dispositivos de entrada Dispositivos de almacenamiento secundario

Dispositivo de salida

Una computadora debe ser capaz de recibir, a través de sus dispositivos de entrada, ciertos datos e instrucciones para manipular éstos. Una vez que los datos e instrucciones son ingresados, el computador debe

ser capaz de almacenarlos internamente en su memoria primaria y luego, procesar los datos en base a las instrucciones suministradas utilizando su(s) procesador(es).

Dado que la memoria principal posee una capacidad limitada y es típicamente volátil (su contenido se pierde cuando el componente no recibe energía), es necesario disponer de alternativas para el almacenamiento de

datos e instrucciones; ese es el rol de los dispositivos de almacenamiento secundario.

2.2.1 Consideraciones de selección

2.2.2 Consideraciones de implantación

2.2.3 Consideraciones de software Para realizar cualquier adquisición de Software o Hardware, se deberán considerar los siguientes puntos: • Solicitud de propuesta. Todo sistema se origina en base a una solicitud que hace el usuario al centro de cómputo, intentando satisfacer una necesidad específica. Los parámetros sobre los cuales debe medirse dicha solicitud son los objetivos y las políticas, los cuales debe fijar el usuario, aunque puede ser que el departamento de análisis le brinde ayuda en su clarificación. Ambos parámetros deben quedar establecidos por escrito.

• Evaluación de propuesta. Previamente debe llevarse a cabo una investigación con el propósito de establecer con seguridad el tipo de Software y Hardware requerido para su implementación, posteriormente se integra toda la información obtenida de dicha investigación y así poder establecer la operatividad de los sistemas a adquirirse. • Financiamiento. Las fuentes de financiamiento, pueden ser principalmente instituciones bancarias a través de criterios. Para el caso de centros de cómputo destinados a la educación pública no existen fuentes de financiamiento, a menos que la institución educativa cuente con un área destinada a la producción de software para empresas privadas, entonces la misma empresa puede ser el origen del financiamiento. • Negociación de contrato. La negociación de contrato debe incluir todos los aspectos de operación del Software y del Hardware a implementarse. Aspectos tales como: Actualizaciones, innovaciones, capacitación, asesoría técnica, etc.

2.3 Herramientas de arquitectura de sistemas

2.3.1 Descripción de la arquitectura

3.1 Herramientas de diseño de procesos

Herramientas determinísticas

Herramientas cuantitativas

Etiquetamiento

3.1.1 Diagrama de actividad

Los diagramas de actividades sirven para:

Representar el comportamiento dinámico de un sistema

Haciendo hincapié: En la secuencia de actividades que se llevan a cabo y las condiciones que

guardan o disparan esas actividades.

Un estado inicial no puede ser destino de una transición

Toda actividad tiene al menos un flujo de entrada y otro de salida

Puede haber cero o más estados finales (por ejemplo, un proceso continuo no tendrá

estado final)

3.1.2 Diagrama de secuencia

Diagramas de Secuencia: Los Diagramas de Secuencias muestran la forma en que un grupo de objetos se comunican (interactúan) entre sí a lo largo del tiempo.

Un Diagrama de Secuencia consta de objetos, mensajes entre estos objetos y una línea de vida del objeto representada por una línea vertical.

3.2 Herramientas de diseño de datos

Open System Architect 4.0.0

SQL Power Architect 1.0.6

SQuirreL SQL 3.2.1

Druid III (3.11)

3.2.1 Diagrama entidad-relación

El Modelo Entidad-Relación(o Modelo E-R o Modelo Entidad-Interrelación) fue propuesto por Peter

Chen en 1976 para la representación conceptual de los problemas del mundo real. Este modelo de datos representa los datos utilizando grafos y símbolos gráficos, además de tablas para la

representación de los datos y sus relaciones.

Conceptos básicos usados en el Modelo E-R: 1. Entidad: Es un objeto del mundo real que tiene interés para la empresa. Por ejemplo, la entidad

ALUMNO de un centro escolar o la entidad CLIENTE de una empresa. Se representan con

rectángulos con el nombre en el interior. 2. Conjunto de Entidades: Es un grupo de entidades del mismo tipo, y no tienen que ser conjuntos

disjuntos, es decir, puede haber una entidad que pertenezca a varios conjuntos de entidades a la

vez. Por ejemplo, el conjunto de entidades ALUMNOS de un centro escolar. 3. Entidad Fuerte: Es una entidad que no depende de otra entidad para su existencia. Por ejemplo,

la entidad ALUMNO es fuerte pues no depende de otra para existir como entidad, mientras que la entidad NOTA es una

Entidad débil pues necesita a la entidad ALUMNO para existir. 4. Atributos o Campos: Son las unidades de información que describen propiedades de las

entidades. Por ejemplo, la entidad ALUMNO posee los atributos: número de matrícula, nombre, dirección, población, código postal, provincia, y teléfono. Los atributos toman valores, por ejemplo, el

atributo provincia podría ser SEVILLA, CÁDIZ, etc. Se representan mediante una elip se con el nombre en el interior.

5. Dominio: Es el conjunto de valores permitidos para cada atributo. Por ejemplo, el dominio del

atributo nombre puede ser el conjunto de cadenas de texto de una longitud determinada.

3.2.2 Diagrama de clases

el diagrama de clases puede tener como ejemplo: una clase que sería un objeto o persona misma en la cual se especifica cada acción y especificación.

Propiedades de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de

quién diseñe el sistema se pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas

para una interfaz gráfica.

Presenta las clases del sistema con sus relaciones estructurales y de herencia.

El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.

3.2.3 Diagrama de paquetes

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema. Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

4.1 Técnicas asociadas al aseguramiento de la calidad de software

Calidad y tipos de calidad

La calidad es uno de los aspectos más difíciles de precisar en la ingeniería en general. Se habla de calidad de

procesos, de servicios y de productos, de calidad visible e invisible, de calidad a largo o corto plazo, etc.

En este artículo me voy a centrar en la definición más castiza de calidad: la que se refiere a un producto de buena calidad, que cumple con lo que se espera de él de manera satisfactoria. Así, de un auto de buena calidad

se espera que sus puertas cierren sin rebotar, que sea estable a alta velocidad, etc.

Prometo otro artículo para tratar sobre calidad de código. Aquí me centro en las prácticas de mejora de la calidad.

A continuación presento una lista de factores:

- Confiabilidad. Éste es el factor de calidad por excelencia. Se basa a su vez en tres necesidades: corrección (que el

sistema cumpla con las especificaciones, es decir, que sea consistente con éstas), robustez (capacidad de reaccionar bien

ante situaciones excepcionales) y disponibilidad (capacidad de estar operativo el mayor tiempo posible).

- Facilidad de uso o usabilidad: es el grado de efectividad de la interacción entre el sistema y sus usuarios.

- Seguridad: una medida de la habilidad del sistema para evitar usos no autorizados, al mismo tiempo que permite el uso

a quienes legítimamente tienen permiso para usarlo.

- Funcionalidad: el sistema no debe pecar ni por exceso ni por defecto respecto de los requisitos.

- Oportunidad: que el sistema esté en el mercado en el momento en que los usuarios lo precisan, o apenas un poco

antes (Llegar mucho antes ha sido la causa del escaso éxito comercial de gran cantidad de productos excelentes. No

olvidemos lo ocurrido con el computador Xerox Star, el lenguaje Ada, la tecnología Jini, la planilla de cálculo Visicalc,

etc.).

- Costo.

- Eficiencia o desempeño. Consiste en resolver el problema usando la menor cantidad posible de recursos de hardware,

tiempo de procesador y ancho de banda. Este requisito de calidad no se debe exagerar, ya que, como dice un refrán

conocido, “no importa cuán eficiente es hasta que no sea correcto”.

- Interoperabilidad, o capacidad de comunicación con otras aplicaciones, brindando o consumiendo servicios. Se logra a

través del uso de estándares, como las normas de comunicación, formatos de datos, etc.

- Adaptabilidad, o facilidad de adaptarse a cambios de especificación.

- Reutilización, o capacidad de las partes de un sistema para servir en la construcción de aplicaciones distintas.

- Portabilidad, o posibilidad de correr el sistema en otras plataformas (hardware, software de base, motor de base de

datos) distintas de aquellas para las cuales fue diseñado.

- Escalabilidad. es una medida de cómo el agregado de recursos afecta el desempeño del sistema. Un sistema es

escalable, cuando la adición de recursos (servidores en paralelo, memoria, capacidad de disco) produce una mejora

proporcional en el desempeño del sistema.

En este artículo me centraré más en los atributos internos de calidad. Por lo tanto, nos interesan:

- Confiabilidad, en el sentido de corrección y de robustez

- Extensibilidad

- Reutilización

- Eficiencia o desempeño

Prácticas colaborativas para mejorar la calidad

Las prácticas colaborativas son aquellas actividades que, realizadas por equipos de desarrollo y sin poner en juego

jerarquías, se utilizan para mejorar la calidad del desarrollo de software.

Normalmente, este carácter colaborativo hace que sean esenciales para el entrenamiento y transferencia de

experiencia, en directo y sobre casos bien concretos. Además, es sabido que la gente trabaja mejor y más apegada a

estándares si sabe que su trabajo es observado por otros, aun cuando el espíritu de la revista no s ea hostil ni evaluativo.

Revisiones de código

Las revisiones de código son de las técnicas de mejoramiento de la calidad que mejor resultado brindan. Como además

son de menos uso que otras técnicas, las analizaré un poco.

Hay tres formas básicas de revisiones de código:

- Pruebas de escritorio

Revisiones informales por pares

Revisiones formales por pares

La prueba de escritorio – además de no ser una práctica colaborativa, sino que la hace el propio programador solo –

rinde muy poco, tal vez menos de lo que cuesta, pero es una costumbre difícil de desterrar. Consiste en simular un

recorrido por el código con algunos datos y ver si el programa se comporta como se espera, pero sin correr el programa,

sino con lápiz y papel.

Para que agreguen valor, es bueno concentrarse en buscar anomalías típicas, como variables u objetos no inicializados o

que no se usan, ciclos infinitos y demás. No obstante, muchas de estas anomalías las detectan también algunas

herramientas automatizadas.

Las revisiones por pares informales rinden mucho más. Son exposiciones del código escrito frente a pares, en reuniones

informales. El programador, exponiendo su código, encuentra muchos errores. Además da ideas avanzadas a

programadores novatos que asisten a las mismas.

Aunque a priori no deberían tener resultados diferentes de las revisiones formales, las estadísticas demuestran que su

efectividad es menor. Ya volveremos sobre esto.

Las llamadas revisiones formales consisten en reuniones programadas entre los responsables de la programación y los

responsables de la revisión. Tienen como objetivo revisar el código escrito por los programadores para chequear que

cumpla con las normas que se hayan fijado y para verificar la corrección y eficiencia del mismo. Se realizan siguiendo

listas de verificación preestablecidas, que ayudan a mantener el foco en lo importante. Si hay un moderador, mejor. En

las reuniones se revisa el código de un cierto porcentaje de módulos seleccionados al azar o según su grado de

complejidad o criticidad.

Revisiones por pares en general

Así como son muy productivas las revisiones por pares del código, las revisiones formales de diseño, de requerimientos,

o de cualquier artefacto, han demostrado también una efectividad mayor a la esperada.

Conceptualmente son lo mismo que las revisiones de código, pero centradas en el artefacto respectivo. De nuevo, la

mayor formalidad permite comparaciones históricas, mientras que cierta flexibilidad deja la mente abierta para

descubrir problemas nuevos.

Programación en parejas

La programación de a pares de programadores fue introducida formalmente por XP (Extreme Programming o

Programación extrema).

En XP, un programador escribe, mientras el otro piensa en mayor escala, buscando simplicidad, errores y formas

alternativas de solución del problema. Las parejas pueden intercambiarse a lo largo del desarrollo, y dentro de cada

pareja los roles van cambiando a lo largo de cada tarea a desarrollar. De todas maneras, cada pareja es responsable de

una tarea, y no se supone que haya intercambios hasta no terminarla.

El objetivo de esta práctica es, no sólo ir a una forma más social de desarrollo, sino aprovechar las mismas ventajas de

las revisiones por pares. De hecho, se trata de una revisión por un par que, aunque con menos formalis mo, se realiza a la

vez que se genera el código.

4.1.1 Modelo de boehm

El modelo de boehm o desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la ingeniería de software. Las actividades de este modelo

se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades.

Ciclos o Iteraciones En cada vuelta o iteración hay que tener en cuenta:

Los Objetivos: qué necesidad debe cubrir el producto. Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista

como pueden ser:

1. Características: experiencia del personal, requisitos a cumplir, etc. 2. Formas de gestión del sistema. 3. Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo. 2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo

desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo. Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Tareas

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos. 2. Análisis del riesgo. 3. Desarrollar y probar. 4. 'Planificación.'

Determinar o fijar objetivos

Fijar también los productos definidos a obtener: requisitos, especificación, manual de usuario. Fijar las restricciones. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificación inicial.

Desarrollar, verificar y validar(probar)

Tareas de la actividad propia y de prueba. Análisis de alternativas e identificación resolución de riesgos. Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede

ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por eje mplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

Análisis del riesgo

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.

Modelo en espiral WIN WIN

El modelo Win-Win es una adaptación del modelo espiral que se enfatiza en la participación del cliente en el proceso de desarrollo de un producto de software. En un caso ideal, el desarrollador simplemente pregunta al cliente lo que se requiere y el cliente proporciona suficiente información y detalles para proceder. Sin embargo esto no suele ocurrir en la mayoría de los casos y es necesario que se establezcan negociaciones significativas entre ambas partes para equilibrar la funcionalidad y rendimiento con los costos y tiempo de salida al mercado del producto. El modelo Win -Win deriva su nombre del objetivo de estas negociaciones, es decir, "ganar-ganar". El cliente recibe el producto que satisface la mayoría de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, se realizan varias actividades de negociación al principio de cada paso alrededor de la espiral.

4.1.2 Modelo de McCall

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes

y a su vez cada factor se desglosa en otros criterios:

Puntos De Vista O Ejes

Factor Criterios

OPERACIÓN DEL

PRODUCTO

Facilidad de uso - Facilidad de operación: Atributos del software que determinan la facilidad de operación del software.

- Facilidad de comunicación: Atributos del software que proporcionan

entradas y salidas fácilmente asimilables.

- Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición del modo

actual de operación.

- Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema.

Integridad - Control de accesos. Atributos del software que proporcionan control de

acceso al software y los datos que maneja.

- Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software.

- Seguridad: La disponibilidad de mecanismos que controlen o protejan los

programas o los datos.

Corrección - Completitud: Atributos del software que proporcionan la implementación

completa de todas las funciones requeridas.

- Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación.

- Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno

operativo concreto.

OPERACIÓN

DEL PRODUCTO

Fiabilidad - Precisión: Atributos del software que proporcionan el grado de precisión

requerido en los cálculos y los resultados.

- Consistencia.

- Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.

- Modularidad: Atributos del software que proporcionan una estructura de

módulos altamente independientes.

- Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.

- Exactitud: La precisión de los cálculos y del control.

Eficiencia - Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento.

- Eficiencia en almacenamiento: Atributos del software que minimizan el

espacio de almacenamiento necesario.

REVISION

DEL PRODUCTO

Facilidad de

mantenimiento

- Modularidad.

- Simplicidad.

- Consistencia.

- Concisión: Atributos del software que posibilitan la implementación de una

función con la menor cantidad de códigos posible.

- Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.

Facilidad de prueba

- Modularidad.

- Simplicidad.

- Auto descripción.

- Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las

mediciones del uso o la identificación de errores.

Flexibilidad - Auto descripción.

- Capacidad de expansión: Atributos del software que posibilitan la expansión

del software en cuanto a capacidades funcionales y datos.

- Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas.

- Modularidad.

Reusabilidad - Auto descripción.

- Generalidad.

- Modularidad.

-Independencia entre sistema y software: Atributos del software que determinan su dependencia del entorno operativo.

- Independencia del hardware: Atributos del software que determinan su

dependencia del hardware.

Interoperabilidad - Modularidad.

- Compatibilidad de comunicaciones: Atributos del software que posibilitan el

uso de protocolos de comunicación e interfaces estándar.

- Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar.

- Estandarizacion en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa.

Portabilidad - Auto descripción.

- Modularidad.

-Independencia entre sistema y software.

- Independencia del hardware.

Cómo emplear el modelo de mccall.

Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas:

1. Se aceptan los factores, criterios y métricas que propone el modelo. 2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas. 3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de calidad establecidos

para el proyecto.

Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se

seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello:

Las características particulares del propio producto que se está diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente implicará como requisito su portabilidad, ...

La relación calidad-precio, que puede evaluarse a través del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad-precio para cada factor considerado:

Factor Beneficio / coste

Corrección alto

Fiabilidad alto

Eficiencia bajo

Integridad bajo

Facilidad de uso medio

Facilidad de mantenimiento alto

Facilidad de prueba alto

Flexibilidad medio

Portabilidad medio

Reusabilidad medio

Interoperabilidad bajo

La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer

en cuales se dejan sentir más los efectos de una calidad pobre con respecto a cada uno de los factores. Las propias interrelaciones entre los factores debido a que algunos factore s pueden entrar en conflicto entre sí:

por ejemplo, la eficiencia plantea conflictos prácticamente con todos los demás factores de calidad. La interacción entre los diversos factores a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de McCall.

También habrá que establecer valores deseables para los criterios, para lo cual se emplearán datos históricos, el promedio en la industria, .... y con ellos se concretarán los valores finales y otros intermedios o predictivos en

cada período de medición durante el desarrollo, así como unos valores mínimos aceptables. La explicación para cualquier selección o decisión deberá ser adecuadamente documentada.

En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus resultados y tomar

medidas correctivas cuando los valores obtenidos estén por debajo de los mínimos aceptables.

Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.

4.2 Métricas de calidad

MÉTRICA

Históricamente se habló de métrica en referencia a los sistemas que existían para escribir versos diferenciados en base al número de sílabas que contenía cada verso, así como en referencia al estudio y “medición” de la cantidad de sílabas y estrofas que contenían los versos.

En informática, el término métrica hace referencia a la medición del software en base a parámetros predeterminados, como puede ser el número de líneas de código de que consta o el volumen de documentación

asociada. A veces en vez de hablar de métrica se usa el término “Indicadores” del software. Algunos ingenieros lo usan como sinónimos mientras que otros les atribuyen significados distintos.

Algunas métricas o indicadores pueden ser:

a) Índice de productividad = tamaño / esfuerzo = líneas de código generado / horas trabajadas.

b) Tasa de defectos = defectos / tamaño = número de errores / líneas de código generadas.

4.2.1 Métricas de producto

4.2.2 Métricas de proceso

4.2.3 Métricas basadas en atributos internos del producto

4.2.4 Métricas basadas en atributos externos del productos