U2, Calidad enfocada al desarrollo de sistemas de información

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información Información - Septimo Semestre – Ingeniería Informática Informática

Unidad 2: Calidad enfocada al desarrollo de sistemas de información. Objetivo:

El alumno conocerá la importancia de la ingeniería de sistemas de información y la calidad que se aplica en ellos, así como también aplicara las técnicas para determinar los niveles de error y defectos en los sistemas de información y también adquirirá la habilidad para obtener la calidad de los sistemas de información 2.1. Calidad en los sistemas de inormación. La calidad del softare afecta a los costes de desarrollo, programación de las entregas y la satisfacción del usuario. !uesto que la calidad del softare es tan importante, necesitamos discutir primero qué significa la palabra La calidad de un producto softare debe ser definida en términos que tengan significado para los usuarios del producto. "sí, un producto que proporciona las prestaciones que son más importantes para los usuarios, es un producto de calidad. Las necesidades de los usuarios, a menudo, se e#pres e#p resan an en los doc docume umento ntoss de requis requisito itos. s. $eb $ebido ido a su import importanc ancia, ia, el desar desarrol rollo, lo, clarif clarifica icació ciónn y refinamiento de los requisitos es un ob%etivo por sí mismo. !or lo tanto, nosotros no vamos a tratar los requisitos en este libro. Es importante recordar, sin embargo, que hasta que no tengas claro los requisitos, no puedes desarrollar un programa de calidad. "unque puedes comen&ar con requisitos poco claros, debes entenderlos antes de poder acabar.

La calidad del softare es un tema tan enorme, que en este libro se tratará de forma parcial. El libro, sin embarg embargo, o, propor proporcio ciona na las habil habilida idade dess y prácti práctica cass que necesi necesitar tarás ás para para entend entender er los defec defectos tos que introduces, y esto te dotará, de un mecanismo eficiente para que encuentres y corri%as muchos de tus defect defectos. os. 'ambi 'ambién én te propor proporcio cionar naráá los datos datos para para ayu ayudar dar a preve prevenir nir estos estos defec defectos tos en el futuro futuro.. (inalmente, una ve& que puedas gestionar los defectos eficientemente, puedes dedicar más atención a aquellos aspectos de la calidad que afectan a la utilidad y valor de los programas que desarrolles. Calidad ! "eectos.

El trab traba% a%oo de un inge ingeni nier eroo del del soft softa are re es entr entreg egar ar prod produc ucto toss de cali calida dadd con con unos unos cost costes es y programaciones programaciones planificadas. )ecuerda también, que los productos softare deben satisfacer tanto las necesidades funcionales de los usuarios como hacer de una forma segura y consistente el traba%o de los mismos. La reali&ación del traba%o es un aspecto clave. "unque las funciones del softare son muy importantes para los usuarios de los programas, estas funciones no serán *tiles a menos que el softare funcione. !ara que el softare funcione, debes eliminar sus defectos. "sí, aunque hay muchos aspectos relacionados con la calidad del softare, el primer aspecto de la calidad está relacionado necesariamente con sus defectos. Esto no significa que los defectos son el *nico aspecto o que son lo más importante, pero debes tratar con muchos de los defectos antes de poder satisfacer cualquiera de los otros ob%etivos del programa. $espués de conseguir que los programas funcionen, si tienes unos pocos defectos, no funcionarán en grandes sistemas, no se utili&arán, y no se tendrá en cuenta sus otras cualidades. cualidades. La causa de que los defectos sean tan importantes, es porque las personas cometen muchos errores. En efecto, los programadores e#perimentados normalmente cometen un error por cada + a - líneas de código que desarrollan. "unque generalmente encuentran y corrigen muchos de esos defectos cuando compilan y prueban sus programas, a menudo, muchos de los defectos permanecen en el producto acabado. Entonces, tu primera prioridad es entender los defectos que introduces y prevenirlos como puedas. !ara hacer esto, necesitas necesitas dominar el lengua%e de programación que utilices, entender a fondo los sistemas que soportan el desarrollo y haber dominado los tipos de aplicaciones que desarrollarás. Estos y otros pasos más son necesarios para reducir el n*mero de defectos que introduces. L.S.C.A. Raúl Monforte Monforte Chlín M!RC" S#stems S#stems



Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información Información - Septimo Semestre – Ingeniería Informática Informática

2.2. "eectos ! errores de calidad en los sistemas de inormación. El termino defecto se refiere a algo que está equivocado en un programa, tal como un error sintáctico, una falta tipográfica, un error de puntuación, o una sentencia incorrecta del programa. Los defectos pueden estar en los programas, en los diseos o incluso en los requisitos, las especificaciones o en otra docume doc umenta ntació ción. n. Los defec defectos tos pue pueden den ser ser senten sentencia ciass e#tra e#tra o redund redundant antes, es, senten sentencia ciass incorr incorrec ectas tas o secciones del programa omitidas. /n defecto, es cualquier cosa que reduce la capacidad de los programas para cumplir completa y efectivamente las necesidades de los usuarios. /n defecto es una cosa ob%etiva. Es algo que puedes identificar, describir y contabili&ar. Erro Errore ress senc sencil illo loss de codi codifi fica caci ción ón pued pueden en prod produc ucir ir defe defect ctos os muy muy dest destru ruct ctiv ivos os o que que sea sea difí difíci cill encontrarlos. " la inversa, muchos defectos sofisticados de diseo pueden encontrarse fácilmente. La sofisticación del error de diseo y el impacto del defecto resultante, son en gran parte independientes. independientes. Los errores triviales de implementación pueden causar serios problemas en el sistema. En efecto, la fuente de muchos defectos softare son simples descuidos y errores del programador. "unque los aspectos de diseo son siempre importantes, cuando comien&as a codificar los programas, normalmente tienen pocos defectos de diseo comparados con el n*mero de simples descuidos, erratas y pifias. !ara me%orar la calidad del programa, es esencial que los ingenieros aprendan a gestionar todos los defectos que introducen en sus programas. Es importante separar la cuestión de encontrar o identificar los defectos de la determinación de sus caus causas as.. La simp simple le cont contab abil ili& i&ac ació iónn y regi regist stro ro de los los defe defect ctos os en los los prod produc ucto toss soft softar aree no es la especificación de las causas ni la asignación de culpas. Los defectos cometidos, sin embargo, tienen sus causas. !uedes haber cometido un error al escribir el nombre de un parámetro, omitido un signo de puntuación o llamado incorrectamente un procedimiento. 'odos estos errores causan defectos. 'odos los defectos, por consiguiente, provienen de errores humanos y muchos de los que los ingenieros del softare cometen, causan defectos en los programas. 2.2.1. #l cuaderno de registro de deectos.

El cuaderno de registro de defectos está diseado para ayudarte a reunir datos de defectos. El cuaderno se muestra en la siguiente figura. 0e utili&a este cuaderno para reunir datos de defectos para cada programa que codifiques. $escribe cada defecto con bastante detalle para que puedas entenderlo más adelante. $espués de haber terminado cada programa, anali&a los datos para ver dónde has introducido y eliminado los defectos y qué tipos de defectos causan los principales problemas. "ntes de utili&ar este cuaderno, lee siguientes instrucciones de la 'abla para mostrar como completar el cuaderno1 1. Cuando comiences a desarrollar desarrollar un programa: programa: Escoge

varias páginas del Cuaderno de )egistro de $efectos y rellena los datos de la cabecera de la primera página. $espués de utili&ar todos los espacios en la primera página, completa la cabecera antes de comen&ar la segunda página. 2. Cuando Cuando encuentres encuentres un deecto deecto por primer primera a vez: vez: "nota

su n*mero en el cuaderno, pero no introdu&cas el resto de datos hasta que hayas corregido el defecto. Cuando el Estudiante 2 intentó compilar el programa -, el compilador mostró más de una docena de mensa%es de error. "unque al principio no sabía qué problema tenía, al menos sabía que era un error. "notó la fecha y puso un  en la casilla 3*mero de la primera línea del cuaderno de defectos. Esto fue para el primer defecto del programa 4. Estos n*meros te ayudarán posteriormente a anali&ar los datos de los defectos. En programas más grandes, los n*meros de defecto se utili&an para controlar los problemas con correcciones incorrectas y ayudar a la prevención de defectos. $. Utiliza una l%nea separada para cada deecto: 3o

agrupes m*ltiples m*ltiples defectos idénticos idéntico s en la

misma línea. L.S.C.A. Raúl Monforte Monforte Chlín M!RC" S#stems S#stems

5

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información - Septimo Semestre – Ingeniería Informática &. #scribe la ec'a de localización del deecto: 0i encuentras varios defectos el mismo día, es aceptable de%ar las siguientes casillas de la fecha en blanco, hasta la primera anotación del día siguiente. En la 'abla, el Estudiante 2 encontró todos los defectos el día 56 de octubre, por lo que no necesitó

volver a anotar la fecha, pues supuso que se repetía hasta que no la cambiase. #l cuaderno de (egistro del "eecto:

L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

7

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información - Septimo Semestre – Ingeniería Informática

Instrucciones para el cuaderno de (egistro del "eecto

/tili&a esta tabla para mantener los datos de cada defecto que encuentres y corri%as. /tili&a estos datos para completar el )esumen del !lan del !royecto. *+todo: "nota todas las revisiones, compilaciones y pruebas de defectos en este cuaderno. "nota cada defecto de forma separada y completa. 0i necesitas espacio adicional, utili&a otra copia de la tabla. Cabecera: 8ntroduce los siguientes datos1 9 'u nombre. 9 (echa actual. 9 3ombre del profesor. 9 3*mero de programa. ,ec'a: "nota la fecha en la que se encontró el defecto. Tipo: "nota el tipo de defecto, seg*n la lista de tipos de defectos del formato anterior :también resumida en la parte superior i&quierda del cuaderno de defectos;. /tili&a tu criterio para seleccionar que tipo aplicar. Introducido "nota la fase en la que se introdu%o el defecto. : /tili&a tu criterio. #liminado: "nota la fecha en la que se eliminó el defecto.
corregido. "escripción:

Escribe una breve descripción del defecto. =a& la descripción lo suficientemente clara para que recuerdes posteriormente, el error que causó el defecto y por qué lo hiciste.

-. "espu+s de corregir el deecto anota el tipo de deecto: "unque

puedas confundirte sobre qué tipo es el adecuado, utili&a tu me%or criterio. 3o dediques mucho tiempo preocupándote sobre qué tipo de defecto es el más preciso. 0in embargo, intenta ser ra&onablemente coherente. 0obre el defecto  en la tabla siguiente, por e%emplo, el Estudiante 2 encontró que el problema era un punto y coma olvidado. /na ve& resuelto el problema, anotó el n*mero 5- para el defecto  en la casilla de 'ipo. /. 0nota la ase del proceso en la ue introdujiste el deecto: "unque

esto pueda no estar siempre claro, no debería ser un problema para programas pequeos. /tili&a tu me%or criterio y no te preocupes mucho tiempo de este tema. En el e%emplo, el Estudiante 2 estaba convencido de que había cometido el error del punto y coma cuando estaba codificando el programa, por eso puso la palabra car en la casilla de 8ntroducido. . 0nota la ase del proceso cuando 'a!as eliminado el deecto: Esta

es normalmente la fase en la que encuentras el defecto. $espués de iniciar la fase de compilación, por e%emplo, anota la palabra compilar para la fase de eliminación. "quí, para el defecto , el Estudiante 2 estaba en la fase de compilación cuando encontró y corrigió el defecto, por eso anotó la palabra compilar en la casilla de Eliminado. 3. )ara el tiempo de corrección del deecto: Estima el tiempo en que te diste cuenta y comen&aste a traba%ar

sobre el defecto hasta que lo acabaste de corregir y chequear. Cuando comen&ó a corregir el defecto , el Estudiante 2 anotó la hora de su relo%. /na ve& que había arreglado el problema y comprobado para asegurarse de que estaba correctamente corregido, de nuevo comprobó su relo% y vio que solamente le había dedicado un minuto.
>


apro#imadamente. !ara los defectos encontrados en las pruebas, sin embargo, la corrección puede llevar mucho más tiempo. !odrías utili&ar un relo% o un cronómetro para medir el tiempo de corrección, pero para correcciones pequeas, tu criterio será adecuado. #jemplo del cuaderno de registro de deectos:


?

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información - Septimo Semestre – Ingeniería Informática 4. 5a casilla de los "eectos Corregidos: Es para los defectos introducidos mientras corriges otros defectos.

"unque esto será importante más adelante, ignóralo por ahora. 16. #scribe una breve descripción del deecto en la sección de descripción: =a& esto tan breve y sencillo

como sea posible, pero describe el defecto claramente. !or e%emplo, simplemente anota un para designar un punto y coma omitido. !ara un defecto lógico más sofisticado, escribe varias líneas, escribe en las siguientes líneas del cuaderno de defectos si es necesario. !ara el defecto , el Estudiante 2 simplemente anotó @omitidoAB. !ara muchos de los defectos de la tabla anterior, tuvo que poner una descripción más detallada. !uesto que estas descripciones son *nicamente para tu uso, no es necesario escribir más de lo preciso para que puedas recordar el problema. " menudo, las personas se confunden sobre los tipos de defectos y piensan que deberían tener un tipo especial para interpretaciones erróneas y confusiones. !or e%emplo, si no entendiste los requisitos o no estabas familiari&ado con el entorno de desarrollo, probablemente cometiste muchos errores. Esta cuestión es importante, pero está relacionada con las causas del defecto. !or lo que al tipo de defecto se refiere, hay solamente dos cuestiones. =abia algo erróneo en el productoD y si es así, cuál era el tipo de defecto del productoD "sí, aunque entender la causa es necesario para prevenir los defectos, el tipo de defecto solamente describe lo que estaba incorrecto en el producto. 2.2.2. Contabilización de deectos ! errores.

"unque la definición de un defecto puede parecer obvia, no lo es. $urante la compilación, por e%emplo, cuenta solamente cambios que haces. Es decir, si el compilador presenta - mensa%es de error por una omisión del punto y coma, la omisión del punto y coma es un *nico defecto. "sí, anota un defecto en el Cuaderno de )egistro de $efectos para cada corrección del programa, sin tener en cuenta la naturale&a de la corrección y el n*mero de mensa%es de error del compilador. $e forma similar, cuando encuentres un defecto de diseo mientras estés codificando, se considerará un defecto de diseo. ientras diseas, sin embargo, con frecuencia puedes cambiar tu idea de cómo hacer algo. 0i estás corrigiendo un error en los requisitos o en las especificaciones, eso sería un defecto de requisitos de especificación. 0i, por el contrario, has pensado una forma me%or de hacer el diseo, no sería un defecto. " menudo, advertirás y corregirás errores conforme los vas cometiendo. $ichos a%ustes son las cosas más naturales de un pensamiento creativo y no son defectos. La clave está en registrar aquellos defectos que has de%ado en el producto cuando hayas acabado el diseo inicial o terminado la codificación. !or e%emplo, si escribes una línea de código e inmediatamente ves un error en el nombre del parámetro y lo corriges, este error no es un defecto. 0i, por el contrario, acabas de codificar el programa y posteriormente observas el error, entonces sí sería un defecto y lo contabili&arías. "sí, si normalmente compruebas la corrección de cada línea después de introducirla, los defectos que encuentres de esta forma no es necesario contabili Comien&a a contabili&ar los defectos cuando termines una fase de un producto o parte del mismo. $espués de la fase de diseo, por e%emplo, contarías todos los defectos de diseo. 0upongamos, sin embargo, que estás codificando dos procedimientos de un programa. $espués de codificar el primero, decides codificar el segundo, antes de comen&ar la compilación del primero. " mitad de codificar el segundo procedimiento, te das cuenta de que has dado un nombre equivocado a un parámetro en el primer procedimiento. Esto es un defecto, porque aunque estés en la fase de codificación, en ese momento habías terminado la codificación del primer procedimiento. 4bserva que en este libro no se te e#ige contabili&ar los defectos encontrados durante las fases de diseo y codificación. 8nicialmente, es importante concentrarte sobre aquellos defectos encontrados durante la L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

F


compilación y pruebas. /na ve& que estés acostumbrado a reunir datos de defectos, sabrás me%or por qué son necesarios dichos datos. Entonces puedes querer aprender más sobre los errores que cometes y corriges durante las fases de codificación y diseo. !uesto que probablemente cometerás muchos errores mientras diseas y codificas, estas son las fases donde debes tratar de entender las causas de los defectos y ver cómo prevenirlos. !or el momento, sin embargo, comien&a con aquellos defectos que encuentres en la compilación y en las pruebas. 2.2.$. ,ormas de encontrar ! corregir deectos.

0e han inventado varias herramientas y ayudas para ayudar a los ingenieros en estos pasos. La primera herramienta que los ingenieros normalmente utili&an es un compilador. !ara entender cómo y por qué un compilador ayuda a encontrar los defectos, es importante discutir su propósito. (undamentalmente, el traba%o del compilador es generar código. "sí, un compilador e#plorará todo el código fuente para ver si puede generar código. 0i puede, lo hará, tanto si el código es correcto como si no. "sí, el compilador generará código hasta que encuentre algunos caracteres que no pueda interpretar. !or e%emplo, si pones la cadena de caracteres "GC en un programa fuente y no la habías declarado, el compilador marcará esta cadena como un error. Los compiladores pueden identificar muchos defectos sintácticos, pero no te pueden decir lo que pretendes. "sí, los compiladores, a menudo, proporcionan muchos mensa%es de error para defectos aparentemente sencillos. Los compiladores, sin embargo, solamente proporcionan síntomas de defectos y debes entender dónde y cuál es el problema. "unque normalmente harás esto rápidamente, en ocasiones puedes necesitar mucha dedicación. Los compiladores no detectarán cada error tipográfico, de puntuación u otro defecto sintáctico. La ra&ón es porque los compiladores, a menudo, pueden generar código de programas fuentes defectuosas. "unque muchos de estos defectos que pasan inadvertidos provienen de diseos inadecuados, algunos podrían ser simples errores sintácticos. !uede parecer improbable que un compilador pudiese pasar por alto errores sintácticos, pero mis datos de varios miles de defectos de CHH muestran que esto sucedió en el de los errores sintácticos que cometí. "sí como un corrector ortográfico no puede detectar todos los errores ortográficos, el compilador no detectará todos los defectos sintácticos. /na segunda forma de encontrar defectos, es por medio de las pruebas. "unque hay muchas clases de pruebas, todas requieren que los e#aminadores proporcionen datos de prueba y condiciones de prueba :algunas veces llamadas casos de prueba o escenarios de prueba;. La calidad de las pruebas está gobernada por el grado en que estos escenarios cubren todas las funciones importantes del programa. El e#aminador, entonces, e%ecuta estos casos de prueba para ver si el programa proporciona los resultados adecuados. Esto implica otra responsabilidad del e#aminador1 comprender que los resultados de estas pruebas deberían parecerse si el programa traba%ase correctamente. "unque las pruebas pueden utili&arse para comprobar casi cualquier función del programa, tienen varias desventa%as. !rimero, como con los compiladores, las pruebas solo suponen el primer paso de corrección de defectos. Es decir, a*n tienes que moverte desde los síntomas a los problemas antes de comen&ar a traba%ar en la corrección. 4tro problema, es que cada prueba verifica solamente un con%unto de condiciones del programa. Es decir, si el programa multiplica dos n*meros, # e y, y lo pruebas con #Il  e sabrías solamente que funciona para esos valores. 3o sabrías, por e%emplo, cómo traba%a el programa con n*meros negativos, o con el cero, o con n*meros positivos o negativos muy grandes en el sistema numérico, o con cualquier otro par de n*meros. !ara comprobar todas estas posibilidades tendrías que hacer muchas pruebas. !uesto que cada programa sencillo implica muchas combinaciones posibles de datos y condiciones operativas, unas pruebas globales consumen tiempo. En efecto, para cualquier programa sencillo, una prueba global es prácticamente imposible.


+


La tercera forma de encontrar los defectos, es la más com*n de todas. Consiste en entregar programas defectuosos y esperar que los usuarios identifiquen e informen de los defectos. Esta es la estrategia más costosa. !or e%emplo, durante un ao, 8G gastó unos 5?- millones de dólares en reparar y reinstalar correcciones de los 7.--- defectos detectados por los clientes. Esto supone unos 5-.--- dólares por defecto. !or Jltimo, indicar que la forma más efectiva de encontrar y corregir defectos es revisar personalmente el código fuente del programa. "unque esto puede parecer una forma difícil de limpiar un programa defectuoso, se trata de la forma más rápida y eficiente. Este capítulo e#plica el porqué 2.2.&. #l costo de encontrar ! corregir deectos.

En los típicos proyectos de softare, el producto es dividido en muchos programas elementales o módulos pequeos. Cada ingeniero, desarrolla uno o más de estos módulos. $espués de disear el módulo, implementarlo y compilarlo, los ingenieros hacen una prueba inicial o prueba de unidad. $espués de estas pruebas de unidad privadas, se combinan los módulos en un gran componente y se hacen pruebas de integración. 0e reali&an varios niveles de pruebas de componentes antes de que se combinen los componentes en productos para hacer las pruebas del producto. (inalmente, se ensamblan los productos en los sistemas para hacer las pruebas del sistema. "unque el tipo, duración y comple%idad de las pruebas de integración, de componentes, de producto y del sistema variará con el tamao y comple%idad del sistema, se utili&a el mismo proceso general para casi todos los productos softare a gran escala. El coste medio de encontrar y corregir un defecto crece unas - veces en cada paso del proceso de desarrollo. "unque el tiempo de corregir los defectos varía enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos. "lgunos defectos triviales de sinta#is, como un punto y coma mal colocado o errores tipográficos en los nombres pueden pasar la fase de compilación, siendo muy difícil encontrarlos en la fase de pruebas. En la revisión de código encontrarás y corregirás los defectos en una media de l a 5 minutos. En las pruebas de unidad iniciales, sin embargo, los tiempos para corregir los defectos tendrán un valor medio de entre - y 5- minutos o más. Estos datos corresponden, en su mayor parte, a correcciones que necesitan entre l y 5 minutos, y e#isten unas pocas que necesiten varios minutos o varias horas. El tiempo de encontrar los defectos en las pruebas de integración, de componentes o del sistema, también variará con el tamao y la comple%idad del sistema. uchas veces se requiere encontrar y corregir defectos en sistemas grandes y muy comple%os. En las pruebas de integración, por e%emplo, cada defecto puede costar una hora o más, y en las pruebas del sistema cada defecto puede costar entre - a >- o más horas de ingeniero. /na ve& que los productos son entregados a los clientes, el coste de encontrar y corregir los defectos puede ser mucho mayor, dependiendo de la clase de productos y de los tipos y n*mero de clientes. is datos personales de los tiempos de encontrar y corregir los defectos en CHH se muestran en la siguiente figura. El siguiente e%emplo muestra el coste de esperar hasta que las pruebas eliminen todos los defectos del programa. #jemplo:

9 /na empresa pequea de softare comercial desarrolló un programa con varios componentes. Las pruebas de integración reali&adas por los ingenieros que estaban entrenados en el !0! duraron un par de semanas. /n componente, sin embargo, se desarrolló por un grupo que no había recibido formación en el !0! y las pruebas de integración se reali&aron en varias semanas. El tiempo de las pruebas para encontrar y corregir los defectos fue de 7-- horas. !uesto que las pruebas necesitaron mucho más tiempo que el planificado, la entrega al cliente se hi&o dos meses más tarde. 'iempos de corrección de defectos.


6


9 El desarrollo de un sistema aeroespacial, necesitó una media de >- horas de ingeniero para encontrar y corregir cada defecto en las pruebas del sistema de un sistema de navegación aérea. 9 En $igital Equiment Corporation, para un sistema, el tiempo mínimo para encontrar y corregir cada defecto informado por el cliente fue de 66 horas de ingeniero. "demás del coste, una ra&ón de igual importancia para encontrar los defectos al principio, es que la compilación, depuración y las pruebas tienen una efectividad reducida. Los compiladores son las herramientas más rápidas que tenemos para detectar defectos, pero solamente encuentran alrededor del K- de los defectos de sinta#is y muy pocos defectos lógicos. La prueba de unidad es normalmente la prueba más efectiva, pero encuentra la mitad de los defectos del programa. $espués de la prueba de unidad, la efectividad de las pruebas disminuye, con las pruebas del sistema, normalmente se encuentran entre un 7- y un >- de los defectos del producto. "sí, si quieres producir un producto de alta calidad, tendrás que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas. 2.$. 5istas de comprobación. La clave para reali&ar una revisión de código efectiva es tener un procedimiento de revisión eficiente. Este capítulo describe las listas de comprobación para la revisión de código, y e#plica cómo pueden ayudarte, para que de una forma rápida y eficiente, encuentres los defectos en tus programas y hagas una lista de comprobación para tu uso personal. Como e%ercicio, disearás una lista de comprobación para los defectos que normalmente introdu&cas y la utili&arás en la revisión de tus programas. )or u+ a!udan las 5istas de Comprobación.

/na lista de comprobación contiene una serie de pasos de procedimiento que quieres seguir de forma precisa. Cuando las personas tienen cosas importantes que quieren hacer e#actamente tal y como están especificadas, a menudo, utili&an las listas de comprobación. Los pilotos de líneas aéreas, por e%emplo, las utili&an para hacer una comprobación prevuelo antes de despegar. "unque hayan hecho una comprobación del mismo avión una hora antes, la vuelven a hacer. /n estudio de los accidentes en una base de las (uer&as "éreas de los EE.//., encontró que en cada caso, la lista de comprobación preMvuelo no se había seguido rigurosamente. 4tro e%emplo de una lista de comprobación completa y comple%a es la cuenta atrás utili&ada por la 3"0" antes de cada lan&amiento espacial. Este procedimiento se reali&a durante varios días y sigue cientos de pasos. Es tan comple%o, que se utili&an computadoras para controlar el progreso de la cuenta atrás. Cuando es esencial encontrar y corregir cada defecto en un programa, debes seguir un procedimiento preciso. /na lista de comprobación te puede ayudar a asegurarte de que se sigue el procedimiento. En este capítulo, trataremos una clase muy especial de lista de comprobación1 una diseada para ayudarte a encontrar los defectos cuando hagas una revisión de código de un programa que has escrito. Nerás cómo construyes una lista de comprobación para la revisión de código, que se adapta para encontrar los defectos que te han causado anteriormente muchos problemas. L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

K


Las listas de comprobación también pueden ser una fuente de ideas. Cuando sigues una lista de comprobación personal, sabes cómo revisar tu código. 0i utili&as la lista correctamente, también sabes cuantos defectos encuentras en cada paso de dicha lista. Comparar tu lista de comprobación con las de otros ingenieros, te puede sugerir apro#imaciones *tiles para la revisión. La lista de comprobación encapsula la e#periencia personal. /tili&ándola con regularidad y me%orándola, me%orarás en la detección de los defectos de tus programas. La lista de comprobación también te ayudará a encontrar estos defectos en menos tiempo. #jemplo de una lista de comprobación.

La lista de comprobación para la revisión de código que diseé para revisar mis programas en CHH se muestra en la siguiente tabla. /na lista de comprobación similar para el lengua%e "da se muestra en la 'abla siguiente. Estas listas de comprobación sugieren un n*mero de puntos a considerar, conforme desarrolles y utilices tu propia lista de comprobación personal. /n primer paso muy *til es asegurar que el código implementa todas las funciones incluidas en el diseo. En grandes programas, es fácil descuidar la codificación de alg*n procedimiento u operación. $ichos descuidos son errores comunes y pueden, ocasionalmente, pasar las siguientes etapas de revisión, compilación y pruebas. Los descuidos generalmente son fáciles de encontrar con una lista de comprobación. Comprobaciones completas para includes :o iths;, iniciali&ación, llamadas a procedimientos y nombres, son también efectivas. Estas, son las áreas de problemas comunes que deberías comprobar a no ser que los datos históricos te indicasen que t* 3/3C" has cometido dichos errores. #jemplo: 5ista de comprobación ! gu%a para la revisión de código en C77.


-


2.&. 8estión del tiempo para el Sistemas de Inormación. La lógica del
!robablemente harás esta semana lo mismo que hiciste la semana pasada. En general, la forma en que utili&aste tu tiempo la Jltima semana te proporcionará una apro#imación bastante buena a la forma en la que gastarás tu tiempo en futuras semanas. =ay, sin embargo, muchas e#cepciones. $urante la semana del e#amen, por e%emplo, no puedes asistir al mismo n*mero clases y probablemente dedicarás más tiempo a estudiar y menos a hacer traba%os en casa. !ara hacer un plan realista, tiene que controlar tu forma de gastar tu tiempo. "unque recuerdes cómo gastaste tu tiempo la Jltima semana, te sorprenderías de tus datos reales. Las personas recuerdan algunas cosas y olvidan otras. !or e%emplo, el tiempo que utili&aste en hacer traba%o en casa es probablemente mucho menor de lo que estimaste, mientras que el tiempo de comer o de rela%arte con los amigos, es con frecuencia, muy superior al esperado. 3uestra memoria tiende a minimi&ar el tiempo que dedicamos a cosas que parecen que transcurren rápidamente, porque nos agrada hacer dichas cosas. !or el contrario, en las actividades lentas, aburridas o difíciles parece que se dedica más tiempo del que realmente se consume. !or lo tanto, para saber cómo utili&ar tu tiempo, necesitas tener registros e#actos del mismo. !ara comprobar la e#actitud de tus estimaciones de tiempo y planes, de bes documentarlas y posteriormente compararlas con la que realmente haces. ientras esto no es un problema serio en las universidades, es de importancia crítica para el traba%o de los ingenieros. La planificación es una habilidad que pocas personas han aprendido. =ay, sin embargo, métodos de planificación conocidos que se pueden aprender y practicar. El primer paso para aprender a hacer buenos planes, es hacer planes. "sí que, escribe tu plan para que posteriormente tengas algo con lo que puedas comparar tus datos actuales. !ara hacer más precisos tus planes, determina las equivocaciones de los planes anteriores, y qué podrías haber hecho para me%orar. Cuando hagas el traba%o planificado, registra el tiempo que utili&as. Esos datos del tiempo serán *tiles si se anotan con un poco de detalle. !or e%emplo, cuando estés haciendo el traba%o del curso, registra por separado el tiempo que dedicas a asistir a clase, leer libros de te#to, escribir programas y estudiar para los e#ámenes. Cuando codifiques grandes programas, de igual forma encontrarás *til registrar los tiempos para las distintas partes del traba%o1 diseo del programa, escritura del código, compilación y pruebas. "unque dicho grado de detalle no es necesario para programas muy cortos, puede ser *til cuando traba%es en proyectos que necesiten varias horas o más. Cuando tengas la copia documentada de tu plan y hayas registrado a qué has dedicado tu tiempo, puedes comparar fácilmente los resultados reales con el plan original. Nerás donde estaba equivocado el plan y como tu proceso de planificación puede ser me%orado. La clave para planificar con e#actitud es hacer planes consistentes y compararlos con los resultados reales posteriores. Entonces verás cómo puedes hacer planes me%ores. !ara gestionar tu tiempo, planifica tu tiempo y sigue el plan. $eterminar qué podrías hacer para producir me%ores planes es la parte más fácil. Llevarlo a cabo es lo realmente difícil. El mundo está lleno de resoluciones que nunca se cumplen, como seguir una dieta o de%ar de fumar. "l principio, cumplir un plan es probablemente difícil. =ay muchas ra&ones posibles, pero la más com*n es que el plan no era muy bueno. =asta que no intentes seguirlo, probablemente no sabrás porque. 'raba%ando con el plan, consigues el primero de dos beneficios1 saber dónde estaba equivocado el plan, lo cual te ayudará a me%orarlo en el pró#imo proyecto.





El segundo beneficio de traba%ar con el plan es que harás el traba%o de la forma que lo has planificado. !uede que esto no pare&ca muy importante, pero lo es. uchos de los problemas en la ingeniería del softare son causados por ata%os irrefle#ivos, descuidos y distracciones en los detalles. En muchos casos, los propios métodos eran conocidos y especificados pero no se seguían. "prender a establecer planes *tiles es importante, pero aprender a seguir dichos planes es absolutamente crucial. 4tro beneficio más sutil de traba%ar de acuerdo a un plan es que cambias tu comportamiento actual. Con un plan, es menos probable que derroches tiempo en decidir qué harás después. El plan también te ayuda a centrarte en lo que estás haciendo. Es menos probable que te distraigas y es más fácil ser eficiente. Comprende como utilizas el tiempo.

!ara practicar la gestión del tiempo, el primer paso es entender cómo utili&as el tiempo ahora. Esto se hace en varios pasos1 Clasifica tus principales actividades. Cuando comiences a controlar el tiempo, probablemente encontrarás que gran parte del mismo lo dedicas a relativamente pocas actividades. Esto es normal. !ara hacer algo, debemos centramos en pocas cosas que sean muy importantes. 0i distribuyes tu tiempo entre muchas cosas, será difícil encontrarle sentido a los datos. $e tres a cinco categorías deberán ser suficientes para controlar el tiempo durante el curso. 0i posteriormente necesitas un mayor grado de detalle, divide las categorías más generales en subcategorías. )egistra el tiempo dedicado a cada una de las actividades principales. 0e necesita bastante disciplina personal para registrar el tiempo de forma consistente. 'oma un registro e#acto, registra el tiempo de inicio y fin de cada actividad principal. "l principio lo olvidarás con frecuencia, pero después de cierta práctica será natural en ti. El Capítulo 7 describe el registro del tiempo con más detalle. )egistra el tiempo de forma normali&ada. 3ormali&ar los registros de tiempo es necesario porque el volumen de datos aumentará rápidamente. 0i no registras y almacenas cuidadosamente estos datos, se perderán o estarán desorgani&ados. Los datos confundidos o desordenados son difíciles de encontrar o interpretar. 0i no intentas tratar los datos de forma adecuada, puede que no los re*nas bien. El Capítulo 7 describe una tabla normali&ada de registro de tiempos, utili&ada en el !0! para reunir datos.
En este curso, utili&arás un cuaderno de ingeniería para controlar el tiempo. Lo utili&arás también para otras cosas, tales como, guardar los e%ercicios, controlar compromisos, tomar notas de clase y como un cuaderno de traba%o para anotar ideas de diseo y cálculos. Como un profesional del softare, le darás m*ltiples usos al cuaderno de ingeniería tales como1 registrar los tiempos, guardar los cálculos y tomar notas de diseo. !odrás utili&arlo como una evidencia de lo que haces en la práctica de la ingeniería, evidencia importante para la defensa de tu empresa, si es que tienes que defender la responsabilidad legal de un producto. Cuando las partes per%udicadas demandan a la compaía, su principal ob%etivo es demostrar que los suministradores fueron negligentes. !ara la compaía, la me%or defensa es la evidencia de que los ingenieros siguieron las prácticas de ingeniería. !or esta ra&ón tener un cuaderno de ingeniería es un buen hábito.


5


/na utili&ación adicional del cuaderno de ingeniería es la protección de los activos intelectuales de los empleados, por e%emplo, registrando ideas que se puedan patentar. /na ve&, en una reunión de diseo, entre mis colegas y yo ideamos algo que se podía considerar como una idea a patentar. Escribimos la idea en mi cuaderno de ingeniería y todos firmamos cada página. El asesor de patentes nos di%o que esto podría ser Jtil para establecer la fecha del invento. La compaía también nos dio a cada uno de nosotros un premio en metálico. "unque probablemente estas ideas no te interesen como estudiante, este curso trata sobre cómo aprender los métodos y establecer los hábitos que necesitarás en la práctica como ingeniero. !or ello, deberías disponer a partir de ahora de tu propio cuaderno de ingeniería y crearte el hábito de utili&arlo. #l dise9o del cuaderno.

El diseo particular del cuaderno no es clave, pero la práctica general en la industria es utili&ar un cuaderno de gusanillo. 0i numeras cada página, el diseo de gusanillo te permitirá tener las páginas en orden y un registro legal Jtil de tu traba%o. La desventa%a, por supuesto, es que tendrás que registrar tus notas en orden cronológico y no podrás insertar o eliminar páginas fácilmente. /na sugerencia para la portada de tu cuaderno de ingeniería se puede observar en la siguiente tabla. En la parte superior, deberías etiquetar el cuaderno con un n*mero de cuaderno. $espués de haber guardado los cuadernos de ingeniería durante varios aos, dispondrás de bastantes. La numeración de los cuadernos es conveniente para almacenarlos en orden cronológico. 'ambién, etiqueta cada cuaderno con tu nombre y n*mero de teléfono o dirección de correo electrónico. Escribe la fecha de inicio de introducción de datos en el cuaderno, y cuando lo hayas terminado escribe la fecha del *ltimo registro. $entro del cuaderno, numera cada página, utili&a las dos primeras páginas para una breve tabla de contenidos. En los contenidos, escribe cualquier referencia especial para que puedas encontrarla posteriormente, por e%emplo1 e%ercicios del curso. Esto te evitará que tengas que buscar por todo el cuaderno. 3o es necesario registrar los contenidos por páginas si no esperas referenciarlos en el futuro. #jemplo de Ingenier%a.

un

cuaderno

de

/n e%emplo de la página de contenidos del cuaderno de ingeniería se muestra en la 'abla 5.5. !ara materias que necesitarás en el futuro, escribe a la i&quierda el n*mero de la página del cuaderno con una breve descripción del tema. !or e%emplo, el estudiante registra en la página 7 todos los e%ercicios de la L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

7


asignatura de 8! :8ntroducción a la !rogramación; para dos semanas. Los contenidos también muestran que los e%ercicios se continuarán registrando en la página . /n e%emplo de la página 7 del cuaderno se muestra en la siguiente tabla. Los contenidos también muestran que entre el KOK y el el estudiante tomó notas de clase en las páginas >, ?, F y +. $espués, continuó tomando notas en la página -. 0iempre que tengas que saltar algunas páginas debido a otras anotaciones, es una buena idea escribir en la parte inferior de la página dónde contin*a ese tema. Néase, por e%emplo, la Jltima de la tabla. $entro del cuaderno, numera cada página, utili&a las dos primeras páginas para una breve tabla de contenidos. En los contenidos, escribe cualquier referencia especial para que puedas encontrarla posteriormente, por e%emplo1 e%ercicios del curso. Esto te evitará que tengas que buscar por 2.-. Obtener calidad en los sistemas de inormación *+todos m+tricas metodolog%as est;ndares<. /no de los problemas que se afrontan actualmente en la esfera de la computación es la calidad del softare. $esde la década del +-, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comerciali&adores de softares, los cuales han reali&ado gran cantidad de investigaciones al respecto con dos ob%etivos fundamentales1 Cómo obtener un softare con calidadD Cómo evaluar la calidad del softareD "mbas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas con el concepto de la calidad del softare, que es el resultado de la primera y la fuente de la segunda.

La obtención de un softare con calidad implica la utili&ación de metodologías o procedimientos estándares para el análisis, diseo, programación y prueba del softare que permitan uniformar la filosofía de traba%o, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la ve& que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del softare. La política establecida debe estar sustentada sobre tres principios básicos1 tecnológico, administrativo y ergonómico. )rimero: El principio tecnológico define las técnicas a utili&ar en el proceso de desarrollo del softare. Segundo: El principio administrativo contempla las funciones de planificación y control del desarrollo

del softare, así como la organi&ación del ambiente o centro de ingeniería de softare. Tercero: El principio ergonómico define la interfa& entre el usuario y el ambiente automati&ado. La adopción de una buena política contribuye en gran medida a lograr la calidad del softare, pero no la asegura. !ara el aseguramiento de la calidad es necesario su control o evaluación. 'odas las metodologías y herramientas tienen un *nico fin @producir softare de gran calidadB L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

>


2./ Controlar la calidad del sistema de inormación. !ara controlar la calidad del softare es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea 'om $e arco, Pusted no puede controlar lo que no se puede medirP.

Las cualidades para medir la calidad del softare son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. !or e%emplo, Qohn Riley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La etodología para la evaluación de la calidad de los medios de programas de la C8C, de )usia, define indicadores de calidad estructurados en cuatro niveles %erárquicos1 factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. 4tros autores identifican la calidad con el nivel de comple%idad del softare y definen dos categorías de métricas1 de comple%idad de programa o código, y de comple%idad de sistema o estructura. 'odos los autores coinciden en que el softare posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. /na ve& seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos1 $efinir el softare que va a ser controlado1 clasificación por tipo, esfera de aplicación, comple%idad, etc., de acuerdo con los estándares establecidos para el desarrollo del softare. 0eleccionar una medida que pueda ser aplicada al ob%eto de control1 !ara cada clase de softare es necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores1 métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automati&adas para medir los criterios de cálculo. $efinir las regulaciones organi&ativas para reali&ar el control1 quiénes participan en el control de la calidad, cuándo se reali&a, qué documentos deben ser revisados y elaborados, etc. " partir del análisis de todo lo anterior, nuestro centro se encuentra enfrascado en un proyecto para el "seguramiento de la Calidad del 0oftare :"C0;, válido para cualquier entidad que se dedique a la investigación, producción y comerciali&ación del softare, el cual incluye la elaboración de un 0istema de 8ndicadores de la Calidad del 0oftare, la confección de una etodología para el "seguramiento de la Calidad del 0oftare y el desarrollo de herramientas manuales y automati&adas de apoyo para la aplicación de las técnicas y procedimientos del "C0, de forma tal que se conforme un 0istema de "seguramiento de la Calidad del 0oftare. 2. Costo de calidad de los sistemas de inormación. 5os costos de la calidad son auellos en ue incurre el pro!ecto para mejorar los entregables prometidos.

Como una de las variables de la 'riple Limitación, la Calidad es uno de los ob%etivo del proyecto. Los costos de la calidad son aquellos en que incurre el proyecto para me%orar los entregables prometidos. Estos costos pueden ser de dos tipos1 Costos de !revención y Costos de Evaluación. = Costos de )revención: están causados por las medidas tomadas en el proyecto para prevenir defectos o problemas en los entregables, para evitar la aparición de errores. En un proyecto de softare esto sería por e%emplo implementar una metodología de desarrollo consistente. En una obra en construcción esto sería por e%emplo cumplir con los estándares de tendido de líneas eléctricas para prevenir problemas posteriores. L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

?

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información - Septimo Semestre – Ingeniería Informática = Costos de #valuación: están

causados por las medidas tomadas para evaluar los entregables una ve& producidos, y corregirlos si es necesario. En un proyecto de softare esto sería por e%emplo dedicar recursos a las pruebas de integración del sistema una ve& desarrollado. En una obra en construcción esto sería por e%emplo reali&ar inspecciones periódicas de la estructura. Como e%emplo, e#isten varias actividades típicas en un proyecto relacionadas la Costo de la Calidad1 = Capacitación este es un Costo de )revención<: capacitación en la construcción o entrega del producto o servicio. 0irve para insertar el proceso de administración de calidad dentro del proceso de elaboración. 0irve para implementar la calidad en términos técnicos, específicos a los entregables. = *antenimiento Costo de )revención<: definición de políticas de mantenimiento posteriores a la finali&ación del proyecto. 0irve para conservar el buen desempeo de los entregables una ve& finali&ado el proyecto. = )ruebas Costo de #valuación<: especificación y e%ecución de pruebas para verificar el cumplimiento de los requerimientos por parte de los entregables. 0irve para validar el funcionamiento normal de los entregables antes de que se usen en producción. = 0uditor%as Costo de #valuación<: desarrollo de auditorías que inspeccionen el proceso de construcción de los entregables. 0irven para no cometer el mismo error dos veces. El costo de la calidad incluye todos los costos que genera la b*squeda de la calidad o que demanda el desarrollo de las actividades relacionadas con la calidad. Los estudios de costo de la calidad se llevan a cabo para ofrecer una línea base para el costo de calidad y proporcionar una base normali&ada de comparación. La base de la normali&ación casi siempre es monetaria. /na ve& que se han normali&ado los costos de la calidad sobre una base monetaria, se tienen los datos necesarios para evaluar dónde se encuentran las oportunidades para me%orar los procesos. ás todavía, se puede evaluar el efecto de los cambios en términos monetarios. Los costos de calidad se dividen en costos asociados con prevención, evaluación y fallas. Los costos de prevención incluyen planificación de la calidad, revisiones técnicas formales, equipos de prueba y entrenamiento. Los costos de evaluación incluyen actividades para comprender me%or la condición del producto la @primera ve& a través deB cada proceso. Los e%emplos de costos de evaluación incluyen inspección en el proceso y entre procesos, calibración y mantenimiento de equipo y pruebas. Los costos de fallas son aquellos que desaparecerían si no aparecieran defectos antes de enviar un producto a los clientes estos costos se subdividen en costos de fallas internas y e#ternas. 0e incurren en los costos de fallas internas cuando se detecta un defecto en el producto, antes del envío. Los costos de fallas internas incluyen reelaboración, reparación y análisis en modo de falla. Los costos de fallas e#ternas se asocian con defectos que se detectan después de que el producto ha sido enviado al cliente. Los e%emplos de costos de fallas e#ternas son la resolución de las que%as, devolución y reempla&o del producto, soporte de ayuda en línea y traba%o de garantía. Como se esperaba, los costos relativos para encontrar y repara un defecto aumentan sustancialmente conforme se pasa de la prevención a detención y de los de falla interna a falla e#terna. 2..1 C;lculo del costo de la calidad. )rocedimiento para el c;lculo de los costos de calidad.

Cada 0istema de Costos de Calidad debe ser un tra%e a la medida de la organi&ación que lo implemente. La implantación de un 0istema de Costos de la Calidad se reali&a teniendo en cuenta varios factores, entre los cuales se destacan1 las características del producto o servicio, la comple%idad del proceso, el Cliente al que está dirigido y el avance alcan&ado por la organi&ación en el proceso de me%ora de la Calidad. )esume en un reporte *nico y e#presado en unidades monetarias los costos de calidad y de no calidad de la empresa. /n 0istema de Costos de Calidad, que este encaminado a alcan&ar el má#imo de sus resultados con el menor costo posible y donde la b*squeda de la calidad sea un requisito indispensable L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

F


para un futuro desarrollo o permanencia, debe incluir el cálculo y análisis de los costos de calidad. Es por ello se propone un procedimiento que re*ne los aspectos necesarios para establecer dentro de un sistema de costos totales de calidad el cálculo y evaluación de los costos de calidad con el *nico propósito de alcan&ar dichos ob%etivos, luego de un análisis detallado de los elementos que intervienen en la calidad, seg*n las categorías reconocidas y de las metodologías propuestas por autores citados, adecuado a las características propias de la empresa en estudio, desarrollado en las siguientes etapas que se e#plican a continuación. Etapas del diseo para el cálculo y evaluación de los costos de calidad1 #tapa 1. *otivación de la alta dirección:

La implantación de un procedimiento ha de ser una acción apoyada por la alta dirección, por el departamento de calidad, contabilidad y otros departamentos involucrados pues independientemente de que la primera imparta las órdenes correspondientes, es muy conveniente que las personas del resto de los departamentos estén motivadas para que la acción planteada sea un é#ito. En estos departamentos se mane%an datos sobre costos de calidad, a*n sin conocerlo y se dispone de los medios informáticos y humanos para tratarlos. 'odos en general deben sentar las bases para tratar los temas de Costos de calidad en su con%unto. En caso contrario, el sistema puede nacer con oposiciones, lo cual puede ser muy per%udicial. #tapa 2. (ealización de un an;lisis del sistema de costos e>istente:

"ntes de disear cualquier procedimiento es necesario anali&ar las características de lo que e#iste, qué datos sobre costos de calidad puede aportar el sistema contable e#istente y qué otros se poseen en los diferentes departamentos, ya sea de forma positiva o negativa, recolectándolos con un acuerdo pleno entre los miembros de la alta gerencia sobre las definiciones de las categorías y subcategorías. Con el análisis se podrán obtener informaciones necesarias para la valoración e interpretación de los datos precisos para la detección de los problemas sobre lo que se debe actuar y valorar su efecto económico en la gestión financiera de la empresa. "demás se ha de conocer la forma de presentación y la periodicidad de la información referente a los costos, así como los responsables. !or ende, esta etapa tiene que completarse con la relación de costos de calidad que no suministra el sistema actual. #tapa $: Identiicación ! Clasiicación de Costos de Calidad:

8nicialmente se estudiaron los disímiles enfoques de costos de calidad y las categorías en que se dividen, reali&ándose un resumen de las subcategorías más importantes. Estas subcategorías identificadas, así como sus respectivas definiciones, deben ser usadas solo como una guía para iniciar la elaboración del sistema de medición de costos de calidad. La metodología más apropiada para identificar los elementos de un sistema de costos de calidad es la que el autor "le#ander :KK>; denomina @'écnica de identificación de los elementos de costos de calidad basándose en los clientesB. Cada área de la empresa debe tener sus propios elementos, los cuales tienen que haber sido identificados contemplando quiénes son sus clientes, cuál es su servicio, y cuáles son las actividades específicas que generan los elementos del sistema de costos. $e esta manera se produce un sistema de medición diseado de acuerdo a la naturale&a de cada área en la empresa. 0i no se identifican con e#actitud los clientes y los servicios, no se puede precisar lo que es conformidad e inconformidad con requerimientos. " continuación se e#plican los pasos de la técnica. = )aso 1. Identiicación de las posibles allas e>ternas

Los especialistas de calidad e#istentes en la empresa deben identificar las fallas típicas e#ternas que podrían presentarse por cada servicio que genera el proceso, en relación con cada tipo de cliente. = )aso 2. Identiicación de las posibles allas internas L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

+


Los especialistas de calidad e#istentes en la empresa deben identificar los tipos de fallas internas que se podrían encontrar en el control de las distintas actividades del proceso, hasta previa reali&ación del servicio al cliente. = )aso $. Identiicación de los esuerzos de evaluación para evitar servicios con allas

"quí deben ser identificados los distintos esfuer&os que deben reali&arse para evitar que el servicio sea reali&ado sin cumplir los requerimientos que satisfagan las necesidades de los clientes. = )aso &. Identiicación de los esuerzos de prevención para evitar servicios con allas

Los especialistas de calidad e#istentes en la empresa deben identificar cuáles deberían ser las actividades a desarrollarse en el proceso que evitarían las posibles fallas de inconformidad con los requerimientos. )aso -. Organizar los elementos del sistema de costos de calidad

/na ve& reali&ado los pasos anteriores deben ser organi&ados los distintos elementos identificados por cada tipo de categoría. $espués de culminada la aplicación de la técnica se pasaría a la pró#ima etapa. #tapa &: C;lculo de los costos de calidad

"ntes de conocer cómo debe presentarse la información de un sistema de medición de costos de calidad, cada qué tiempo debe rendirse el informe y cómo deben hacerse los análisis pertinentes, es necesario conocer cómo cuantificar los costos de calidad y en quién o quiénes debe caer esta responsabilidad. Escori&a :5--7; plantea ciertas e#presiones de cálculo muy *tiles con las cuales es posible determinar algunos elementos para cada costo, aunque es lógico que las e#presiones también sean propias del lugar y de las actividades a las cuales se asignan, para obtener un resultado real y cierto de lo que se quiere. El cálculo de los costos de calidad es más relevante en aquellas áreas de mayores gastos por este concepto y en las que tienen más posibilidades de reducción de los costos. !or tanto, es factible valorar en muchos casos la estimación de los costos y no la reali&ación de e#cesivos cálculos con los que qui&á se perdería la esencia de lo que se quiere obtener. 3o obstante, esta valoración quedaría al criterio y la e#periencia del responsable de e%ecutar la actividad. " continuación se definen las e#presiones para el cálculo de los elementos de gastos por cada categoría de costo. Costos de prevención

. . "uditorías internas al aseguramiento de la calidad1 0on los costos derivados de las inspecciones que reali&an los especialistas principales de las diferentes áreas a las actividades de su especialidad en los diferentes controles establecidos. ?. "uditorías e#ternas1 0on los costos derivados de las inspecciones reali&adas por los especialistas de 4ficina 3acional de 3ormali&ación :433; a los procesos. F. ateriales y tiempos destinados a capacitación1 0on los costos derivados del valor de los materiales invertidos en la capacitación y los salarios devengados por el personal en la capacitación. "demás se pueden los gastos por concepto de alimentación. +. antenimiento de equipos1 0on los costos del traba%o de mantenimiento a los equipos ya sea por personal interno de la empresa o e#terno. 6. odificación de la documentación del sistema de la calidad1 0on los costos derivados del valor de los materiales y el tiempo invertido en la reelaboración de la documentación ya sean, procedimientos, L.S.C.A. Raúl Monforte Chlín M!RC" S#stems

6


instrucciones o manuales del 0istema de
.
. (alta de gestión de la dirección1 Costos en que se incurre producto del tiempo de inactividad de cualquier empleado por causas concernientes a la falta de gestión, o sea lentitud en la toma de decisiones para la continuidad de los traba%os, ya sea de los Qefes de 0ervicios, administrativos o directivos. 5. (alta de gestión de marSeting1 Costos en que se incurre producto del tiempo de inactividad de cualquier empleado por causas concernientes a la falta de gestión de la actividad de marSeting. ternos:

. .

K

Instituto Tecnológico Superior de Coatzacoalcos Calidad de Sistemas de Información - Septimo Semestre – Ingeniería Informática #tapa -. #valuación de los costos de calidad

/na ve& establecido el sistema de medición de los costos de calidad es necesario definir la periodicidad de los informes contemplando el análisis de los mismos. $ependiendo a quién vayan dirigidos los informes, así será la frecuencia con que deberán presentarse. Las mediciones que se seleccionan serán una función de la empresa en particular y de sus prácticas para preparar reportes. Los reportes contables deben interpretarse por gerentes de la calidad, quienes también deben recomendar las acciones apropiadas para reducir los costos de la misma. 0e considera que si van dirigidos a la alta gerencia es recomendable presentarlos trimestralmente. Cuando se dirigen a la gerencia media su frecuencia debe ser mensual y los informes relacionados con los niveles operativos dependerán de la naturale&a del proceso, aunque se recomienda que se elaboren diariamente. Los informes se convierten en un e#celente indicador para sealar el lugar en el cuál empe&ar a investigar, identificar con precisión los problemas crónicos que están generando los costos de calidad. 'ambién constituyen un indicador importantísimo para evaluar el progreso de los proyectos de me%oramiento. En ellos debería refle%arse la disminución de las fallas, la optimi&ación de la evaluación y redimensión de la prevención, si es que el me%oramiento de la calidad ha sido e#itoso. #tapa /. )resentación de los resultados de los costos a la dirección junto con un inorme ! las oportunidades de mejoramiento

En un sistema de costos de la calidad es muy importante que la información esté organi&ada de manera tal que facilite el análisis. /na ve& recopilados los datos se debe decidir cómo se presentarán, para reali&ar los análisis e interpretaciones pertinentes. Lo más recomendable es hacerlo de forma gráfica pues así se resumen grandes cantidades de datos en un área pequea. Las técnicas gráficas más utili&adas en estos casos son1 T
Cuando el sistema ya ha sido corregido y probado, y se han demostrado los primeros beneficios, es el momento de organi&ar la implantación al resto de la empresaA adaptándolo a las características de cada área para que resulte representativo y *til, facilitándose el proceso de me%oramiento con miras a reducir los costos operativos. Es importante comprender que no es factible que el sistema de costos de calidad sea implantado con los mismos elementos para todas las áreas funcionales de la empresa. Cada una debe identificar sus propios elementos con el ob%etivo de determinar el costo real por este concepto por lo que la metodología propuesta hasta este momento, serviría de gran ayuda para su e%ecución e implantación en otras áreas de la empresa.


5-


El ob%etivo de este procedimiento es documentar y establecer las formas de reali&ar la recogida, análisis y registro de los costos de calidad, dando respuesta al 0istema de Calidad avalado en cada Empresa. Este procedimiento es de aplicación para todos los procesos que generen Costos de Calidad. Con el establecimiento de un procedimiento *nico para la recogida, análisis, registro y distribución de los Costos de Calidad en todas las actividades desarrolladas en la empresa, se logra una uniformidad en la e%ecución de este tipo de traba%o, lo cual constituye una e#celente arma para la gestión de la dirección, con el fin de monitorear los costos por proyectos y de actividades colaterales de una forma más racional, posibilitando determinar con precisión las áreas que mayormente inciden en la generación de dichos costos y que con un adecuado uso de las acciones preventivas y correctivas pueda llevar a vías de hecho el me%oramiento continuo de la calidad.

?ers%culo ,rases @ 5emas: "ios tomó al 'ombre y lo puso en el jard%n del #d+n (La naturaleza) para que lo clti$ara # lo cidara :
manera espiritual, emocional, social y laboralA b*scalo, esfuér&ate y disfr*taloA y veras que ser profesionista es e#celentemente profesional. *O(C S!stems.


5

U2, Calidad enfocada al desarrollo de sistemas de información

Recommend Documents