Sistemas de Calidad

Hola chicos les saludo para comunicarles que por este medio aparecerá alguna tarea pendiente =)

Requisitos del software

Requisitos funcionales. Describen todas las entradas y salidas y la relación entre ambas.

- De datos
- De proceso

Requisitos no funcionales. Definen las cualidades generales que ha de tener el sistema al realizar su función.

- Eficiencia
- Tipos de interface
- Económicos
- Estructurales
- Políticos
- Calidad


Fuente:
Especificación de sistemas software en UML - Ernest Teniente López, Dolors Costal Costa, M. Ribera Sancho Samsó - CPET

Artefacto

Es un termino general que se utiliza para describir cualquier pieza de información usada o producida al desarrollar sistemas. Podría ser un diagrama, texto descriptivo, instrucciones de usuario, métodos del código, programas o cualquier otro componente del sistema.

Fuente:
Análisis y diseño de sistemas - Julie E. Kendall - Prentice Hall

Alta cohesión y bajo acoplamiento

Los podemos separar, aunque están íntimamente ligados, de hecho si nos esforzamos en aumentar mucho la cohesión de nuestro software, es muy posible que perjudiquemos el acoplamiento aumentándolo, y por el contrario si reducimos mucho el acoplamiento, se verá disminuida la cohesión:

Alta cohesión.
Nos dice que la información que almacena una clase debe de ser coherente y está en la mayor medida de lo posible relacionada con la clase.

- Cohesión Coincidente. El módulo realiza múltiples tareas, sin ninguna relación entre ellas.

- Cohesión Lógica. El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.

- Cohesión Temporal. Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.

- Cohesión de Procedimiento. La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.

- Cohesión de Comunicación. Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.

- Cohesión de Información. Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS

- Cohesión Funcional. Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.

Bajo acoplamiento.
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases.

- Acoplamiento de Contenido. Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)

- Acoplamiento Común. Cuando dos módulos acceden (y afectan) a un mismo valor global.

- Acoplamiento de Control. Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.

Fuente:
Ingenieria del Software, un enfoque práctico - Roger Pressman - Mc-Graw Hill

Beneficios de la tecnología orientada a objetos

Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de modo que se puedan adaptar. Un depósito debe estar poblado de una creciente colección de clases reutilizables. Es probable que las bibliotecas de clases crezcan rápidamente. Un objetivo fundamental de las técnicas Orientadas a Objetos es lograr la reutilización masiva al construir un software.

Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. Las aplicaciones se construyen a partir de chips de software cuando sea posible.

El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulado oculta los detalles y hace que las clases complejas sean fáciles de utilizar. Las clases son como cajas negras; el investigador utiliza la caja negra y no ve hacia el interior de ésta. Sólo debe entender el comportamiento de la caja negra y cómo comunicarse con ella.

Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Así como los bienes manufacturados se fabrican a partir de una serie de materiales de partes y subpartes ya existentes, también el software se crea mediante una serie de materiales de clases ya existentes y probadas. Esto permite construir componentes complejos de software, que a su vez se convierten en bloques de construcción de software más complejo.

Confiabilidad. Es probable que el software construido a partir de clases estables ya probadas tenga menos fallas que el software elaborado a partir de cero.

Nuevos mercados para el software. Las compañías de software deben proporcionar bibliotecas de software para áreas específicas, que se adapten con facilidad a las necesidades de la organización que las utiliza. La era de los paquetes monolíticos viene siendo reemplazada por software que incorpora clases y paquetes encapsulados por muchos proveedores distintos.

Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se puedan adaptar para un diseño particular. Los componentes se pueden ver, adaptar y ligar entre sí en la pantalla de herramientas del CASE.

Diseño de mayor calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces.

Integridad. Las estructuras de datos sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-despachador y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.

Programación más sencilla. Los programas se conjuntan a partir de piezas pequeñas, cada una de las cuales, en general, se puede crear fácilmente. El programador crea un método para una clases a la vez. El método cambia el estado de los objetos en formas que suelen ser sencillas cuando se les considera en sí mismas.

Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás.

Fuente:
Análisis y Diseño Orientado a Objetos - James Martin & James J. Odell - Prentice Hall