lunes, 19 de enero de 2015

Tema 3. Gestión de Proyectos de Software: Gestión de Calidad

ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

SEMESTRE SEPTIMO                 PERIODO OCT./2014-MAR./2015

INGENIERIA DE SOFTWARE
TEMA 3:
GESTIÓN DE PROYECTOS DE SOFTWARE

AUTORA:
JENNIFER V. LÓPEZ ÁLAVA

FACILITADOR:
ING. HIRAIDA SANTANA

CALCETA, 19 ENERO 2014


INTRODUCCIÓN

En este capítulo se dará a conocer sobre la gestión de calidad en la elaboración de un proyecto de software, las dimensiones dadas por Garvin, la responsabilidad de la administración de la calidad y los factores de calidad definidos por McCall.

GESTIÓN DE CALIDAD

La administración de la calidad total (TQM) es esencial en todos los pasos de desarrollo de sistemas. Los principales elementos de la TQM tienen sentido sólo cuando ocurren en un contexto organizacional que apoye un esfuerzo de calidad integral. Es en este contexto en el que se unen los elementos de enfoque hacia el cliente, la planeación y el liderazgo estratégico, la mejora continua, el otorgamiento de poderes y el trabajo en equipo para cambiar el comportamiento de los empleados y, en última instancia, el curso de la organización. En vez de concebir la calidad como el control del número de productos defectuosos producidos, ahora se considera como un proceso evolutivo hacia la perfección, al cual se le conoce como administración de la calidad total.

Los analistas de sistemas deben estar conscientes de los factores que impulsan el interés en la calidad. Es importante tener en cuenta que el compromiso cada vez mayor de las empresas con la TQM se adapta extraordinariamente bien a los objetivos generales para el análisis y diseño de sistemas.

La calidad del diseño se refiere a las características que los diseñadores especifican para un producto. El tipo de materiales, tolerancias y especificaciones del desempeño, todo contribuye a la calidad del diseño. Si se utilizan mejores materiales, tolerancias más estrictas y se especifican mayores niveles de desempeño, la calidad del diseño de un producto se incrementa si se fabrica de acuerdo con las especificaciones.

En el desarrollo del software, la calidad del diseño incluye el grado en el que el diseño cumple las funciones y características especificadas en el modelo de requerimientos. La calidad de la conformidad se centra en el grado en el que la implementación se apega al diseño y en el que el sistema resultante cumple sus metas de requerimientos y desempeño.

Dimensiones De La Calidad De Gravin
David Garvin sugiere que la calidad debe tomarse en cuenta, adoptando un punto de vista multidimensional que comience con la evaluación de la conformidad y termine con una visión trascendental.

Calidad del desempeño. ¿El software entrega todo el contenido, las funciones y las características especificadas como parte del modelo de requerimientos, de manera que da valor al usuario final?

Calidad de las características. ¿El software tiene características que sorprenden y agradan la primera vez que lo emplean los usuarios finales?

Confiabilidad. ¿El software proporciona todas las características y capacidades sin fallar? ¿Está disponible cuando se necesita? ¿Entrega funcionalidad libre de errores?

Conformidad. ¿El software concuerda con los estándares locales y externos que son relevantes para la aplicación? ¿Concuerda con el diseño de facto y las convenciones de código?

Durabilidad. ¿El software puede recibir mantenimiento (cambiar) o corregirse (depurarse) sin la generación inadvertida de eventos colaterales? ¿Los cambios ocasionarán que la tasa de errores o la confiabilidad disminuyan con el tiempo?

Servicio. ¿Existe la posibilidad de que el software reciba mantenimiento (cambios) o correcciones (depuración) en un periodo de tiempo aceptablemente breve? ¿El equipo de apoyo puede adquirir toda la información necesaria para hacer cambios o corregir defectos?

Estética. No hay duda de que todos tenemos una visión diferente y muy subjetiva de lo que es estético. Aun así, la mayoría de nosotros estaría de acuerdo en que una entidad estética posee cierta elegancia, un flujo único y una “presencia” obvia que es difícil de cuantificar y que, no obstante, resulta evidente. El software estético tiene estas características.

Percepción. En ciertas situaciones, existen prejuicios que influirán en la percepción de la calidad por parte del usuario.

Responsabilidad De La Administración De La Calidad Total
Gran parte de la responsabilidad por la calidad de los sistemas de información recae en los usuarios del sistema y la gerencia. Deben ocurrir dos cosas para que la TQM se convierta en una realidad con los proyectos de sistemas. En primer lugar debe existir el soporte organizacional completo de la gerencia, algo considerablemente distinto al simple hecho de promocionar el ardid administrativo más reciente. Dicho soporte implica establecer un contexto para que el personal administrativo considere con seriedad cómo afecta la calidad tanto de la información como de los sistemas de información en su trabajo.

Es necesario que el analista y los usuarios de la empresa se comprometan con la calidad lo antes posible para lograr el objetivo de ésta. Este compromiso se ejerce como resultado de un esfuerzo de ritmo uniforme hacia la calidad en todo el ciclo de vida de desarrollo de sistemas; además supone un fuerte contraste con el hecho de tener que invertir mucho esfuerzo para resolver los problemas al final del proyecto.

Factores De La Calidad De McCall
McCall, Richards y Walters proponen una clasificación útil de los factores que afectan la calidad del software.

Corrección. Grado en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente.

Confiabilidad. Grado en el que se espera que un programa cumpla con su función y con la precisión requerida.

Eficiencia. Cantidad de recursos de cómputo y de código requeridos por un programa para llevar a cabo su función.

Integridad. Grado en el que es posible controlar el acceso de personas no autorizadas al software o a los datos.

Usabilidad. Esfuerzo que se requiere para aprender, operar, preparar las entradas e interpretar las salidas de un programa.

Facilidad de recibir mantenimiento. Esfuerzo requerido para detectar y corregir un error en un programa.

Flexibilidad. Esfuerzo necesario para modificar un programa que ya opera.

Susceptibilidad de someterse a pruebas. Esfuerzo que se requiere para probar un programa a fin de garantizar que realiza la función que se pretende.

Portabilidad. Esfuerzo que se necesita para transferir el programa de un ambiente de sistema de hardware o software a otro.

Reusabilidad. Grado en el que un programa (o partes de uno) pueden volverse a utilizar en otras aplicaciones.

Interoperabilidad. Esfuerzo requerido para acoplar un sistema con otro.

CIERRE

En el desarrollo de un software la calidad juega un papel muy importante, porque incluye el grado en el que el diseño cumple las funciones y características especificadas en el modelo de requerimientos. Los analistas deben estar comprometidos con la calidad del sistema, así mismo la administración de la empresa, las dimensiones propuestas son la calidad de desempeño, de características, además debe tener confiabilidad, conformidad, durabilidad, servicio, estética y percepción. Los factores de calidad que se debe cumplir son la confiabilidad, eficacia, integridad, usabilidad, flexibilidad, facilidad de recibir mantenimiento, susceptibilidad de someterse a pruebas, portabilidad, reusabilidad e interoperabilidad.

BIBLIOGRÁFIA

Kendall, K. Kendall, J. Análisis y Diseño de Sistemas. 8va ed. Pearson Education. Prentice Hall, INC., Copyright © 2011.

Pressman, R. 2010. Ingeniería del Software Un Enfoque Práctico. 7ma ed. University of Connecticut. McGraw-Hill Interamericana Editores, S.A.

lunes, 5 de enero de 2015

Tema 2. Lenguaje Unificado de Modelado: Diagramas de Estructura: Componentes, Despliegue, Objeto y Paquetes


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

SEMESTRE SEPTIMO                 PERIODO OCT./2014-MAR./2015

INGENIERIA DE SOFTWARE
TEMA 2:
LENGUAJE UNIFICADO DE MODELADO UML

AUTORA:
JENNIFER V. LÓPEZ ÁLAVA

FACILITADOR:
ING. HIRAIDA SANTANA

CALCETA, 05 ENERO 2015



INTRODUCCIÓN

En este capítulo se dará a conocer de los demás diagramas de estructura que existen como los diagramas de componentes, los diagramas de despliegue, diagrama de objeto y diagrama de paquetes, que son, el funcionamientos de cada uno y como se utilizan.

DIAGRAMAS DE ESTRUCTURA

COMPONENTES

El diagrama de componentes es similar a un diagrama de clases, sólo que es más como una vista superficial de la arquitectura del sistema. El diagrama de componentes muestra los componentes del sistema, como un archivo de clase, un paquete, las bibliotecas compartidas, una base de datos, etcétera, y la forma en que se relacionan entre sí. Los componentes individuales en un diagrama de componentes se consideran con más detalle dentro de otros diagramas de UML, como los diagramas de clases y los diagramas de casos de uso.

DESPLIEGUE

El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el hardware, las relaciones entre el hardware y el sistema en el que se va a desplegar. El diagrama de despliegue puede mostrar los servidores, estaciones de trabajo, impresoras, etcétera

OBJETO

Utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase.

Por ejemplo, Miguel: Persona..

PAQUETES

Los paquetes son contenedores para otras cosas de UML, como los casos de uso o las clases. Los paquetes pueden mostrar el particionamiento del sistema, para indicar qué clases o casos de uso se agrupan en un subsistema, a lo cual se le denomina paquetes lógicos. También pueden ser paquetes componentes, que contienen componentes físicos del sistema, o paquetes de casos de uso que contienen un grupo de casos de uso. Los paquetes usan un símbolo de carpeta con el nombre del paquete en la ficha de la carpeta o centrado en la misma. El empaquetamiento puede ocurrir durante el análisis del sistema o en una etapa posterior de diseño del sistema. Los paquetes también pueden tener relaciones de manera similar a los diagramas de clases, que pueden incluir asociaciones y herencia.

CIERRE

El diagrama de componentes muestra los componentes del sistema, y la forma en que se relacionan entre sí. El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el hardware, las relaciones entre el hardware y el sistema en el que se va a desplegar. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clases, no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase. Los paquetes pueden mostrar el particionamiento del sistema, para indicar qué clases o casos de uso se agrupan en un subsistema, a lo cual se le denomina paquetes lógicos, usan un símbolo de carpeta con el nombre del paquete.

BIBLIOGRÁFIA

Kendall, K. Kendall, J. Análisis y Diseño de Sistemas. 8va ed. Pearson Education. Prentice Hall, INC., Copyright © 2011.

Martínez, H. Lenguaje Unificado de Modelado UML. Consultado, 05 feb. 15. Formato HTML. Disponible en: http://umlhugomartinez.blogspot.com/p/diagramas-de-estructura.html

Pressman, R. 2010. Ingeniería del Software Un Enfoque Práctico. 7ma ed. University of Connecticut. McGraw-Hill Interamericana Editores, S.A.