Fernando Francisco Villagrn Jurez 2339307

Ingeniera de Software I. URL

Ing. Ivan de Len

PREGUNTAS

1. Es lo mismo un defecto que un error?

NO es lo mismo segn la bibliografa. Sin embargo muchos ingenieros no hacen

distincin entre ellos ya que el detectarse dichas fallas antes de su entrega final o en algn

momento del proceso de desarrollo ya hay implcitas algunas consecuencias. Sin embargo,

segn el libro, un defecto no es lo mismo que un error. Si bien ambos parecieran

sinnimos ya que se refieren a problemas en la calidad del software, difieren en lo

siguiente:

El error es un problema de calidad que se detecta antes de que el Software se

entregue a usuarios finales. Podra ser en las etapas de diseo, generacin de

cdigo del software, antes y durante las pruebas.

El defecto por su parte se refiere a todo problema de calidad en el Software que

se detecta luego de que el mismo se haya entregado al usuario final.

Segn la bibliografa donde se extrajo esta informacin, mientras estos errores se

pasen por alto tienden a ser ms costosos. Obviamente un error va a ser menos costoso

que un defecto, sin embargo el defecto tiene consecuencias an ms negativas (adems

del costo) ya que tienden a tener un efecto sobre la percepcin que el cliente tiene sobre

el desarrollador de Software, es decir, los defectos podran afectar incluso su reputacin

como buen o mal profesional del Software.

2. Segn su experiencia Qu costos tienen los defectos?

Mi experiencia an no ha cubierto el desarrollar Software formal para personas y

recibir un beneficio econmico a cambio de ello. Sin embargo, lo ms cerca que pude estar

de una experiencia de este tipo fue el realizar un Software para un curso llamado

Ingeniera Primero, el cual fue propuesto por unos 5 grupos de trabajo a la facultad de

Ciencias Jurdicas y Sociales de la Universidad Rafael Landivar. Quien lograra convencer

ms a las autoridades de dicha facultad iba a tener la oportunidad de dejar su Software

instalado en dicho ente. Fue todo un proceso, el revisar algunos requerimientos (a travs

de entrevistas con autoridades) y el presentar algunos avances.

Sin embargo, como fue de los cursos donde empezaba la carrera, an no tena la

menor idea de lo que era el administrar adecuadamente el manejo de errores y de

tcnicas de revisin. Fue as que durante todo el semestre se realiz el software y tuve el

honor de que mi grupo fuera el que ganara y por lo tanto instalara dicho programa.

Sin embargo, el manejar mal lo que son errores trajo muchos defectos al momento

de tener instalado dicho programa, a tal punto que incluso en vacaciones tuve que

sacrificar algunos viajes y actividades recreativas por ir a reparar dichos problemas. En

pleno diciembre tuve que emplear horas y noches de trabajo para reparar dicho programa

y con mucha presin debido a que ya haba informacin real en juego y las autoridades de

dicha facultad estaban presionando para que se arreglaran esos defectos.

Obviamente de haber sido una empresa hubiramos gastado muchos recursos

econmicos y nuestra reputacin hubiera quedado en tela de juicio. Por lo tanto esa

experiencia la puedo ejemplificar como una manera en la cual no se debe realizar software

ya que no se tuvo en cuenta ninguna tcnica de revisin (formal o informal) y por lo tanto

se tuvieron muchos ms errores de los que se vean venir.

3. Cmo se administran los defectos?

Los defectos como se ha escuchado, tienen duras implicaciones no solamente

econmicas sino tambin en el aspecto psicolgico, humano y empresarial. Sin embargo,

en un ambiente ms formal de desarrollo, es importante hacer uso de las tcnicas de

revisin las cuales son una manera de asegurarse del buen funcionamiento del Software.

Se empieza teniendo mtricas para revisiones tcnicas (tales como el esfuerzo de

preparacin, el esfuerzo de evaluacin y el de repeticin, sin contar el tamao del

producto, errores menores/mayores detectados entre otras tantas mtricas). Se hace un

anlisis de dichas mtricas para hallar la densidad del error en el software (es decir que

tanto error hay por lneas de cdigo). Obviamente de acuerdo a la naturaleza del

proyecto, de la formalidad de los programadores y del contexto (cliente, etc.) se realizan

revisiones formales e informales, siendo las primeras estructuradas y casi guiadas por un

protocolo mientras que las informales son algunas verificaciones simples de escritorio sin

embargo con un poco ms de sentido que un simple Debugg.

Obviamente estas tcnicas no garantizan que un Software funcione al 100%, esto

es una utopa, sin embargo podran ahorrar grandes cantidades de dinero y consecuencias

negativas que podran darse debido al mal control o administracin de los errores.