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.
Top Related