Ingeniería de requerimientos

Instituto Tecnológico y de Estudios Superiores

de Monterrey

[Reporte de análisis de lecturas:

Campus Tampico

Conciencia del estado actual del

software ]
Tarea 1

Julieta Vanelly Orta Camacho 509214

Página |1
Lectura 1: Why software fails

En esta lectura nos habla de que .la mayoría de los expertos de TI dicen que los errores o
fallos se producen con gran frecuencia de la que deberían y que están universalmente libres de
prejuicios y que se producen en todos los países, en las grandes empresas, en las organizaciones
comerciales sin fines de lucro y comerciales y sin importar su estado o reputación y que los costos
por fallas están en miles de millones de dólares por año. Esto provoca que del 5 al 15 por ciento de
los proyectos será abandonado antes o poco después del haber sido terminados, algunos otros
fueron aplicados tarde o están por encima del presupuesto o simplemente requieren una
remodelación completa, por ende existen muy pocos proyectos de TI que realmente tengan éxito.

Nos mencionan que la mayoría de las fallas de software son predecibles y evitables, sin
embargo las mayorías de las organizaciones no brindan la atención necesaria a prevenir estos
fracasos, sin importarles de que los riesgos que podría sufrir la empresa e inclusive llevarle a las
destrucción.

Actualmente podemos encontrar software en todas partes, ya que es el que nos permite
obtener dinero de los cajeros automáticos, hacer llamadas telefónicas e incluso conducir nuestros
autos, el autor nos menciona que actualmente un teléfono móvil básico contiene 2 millones de
líneas de código y que para los siguientes años esta cantidad ira en aumento, también nos
menciona que actualmente uno de los mayores gastos corporativos fuera de gastos de personal
está enfocado a la actualización de software y hardware, licencias de software y así
sucesivamente.

En el escrito nos mencionan algunos de los factores más importantes y comunes por los
cuales el software falla, los cuales son:

• Objetivos poco realistas o desarticulado de proyectos

• Inexactas estimaciones de los recursos necesarios
• Mal definidos los requisitos del sistema
• Mala presentación de informes de estado del proyecto
• Administrado riesgos
• Mala comunicación entre los clientes, desarrolladores y usuarios
• Utilización de la tecnología inmadura
• Incapacidad para manejar la complejidad del proyecto
• Descuidado las prácticas de desarrollo
• Mala gestión de proyectos
• Política de las partes interesadas
• Comercial presiones

Nos menciona que todos los sistemas son intrínsecamente frágiles que por ejemplo en un
edificio de ladrillo de gran tamaño, se tendría que eliminar cientos de ladrillos colocados
estratégicamente para que este se colapse y que por el contrario en un programa de software de
100 000 líneas, sólo se necesita una o dos líneas mal para producir grandes problemas.

Nos mencionan que la mayoría de los problemas que
prevenirse, pero debido a que las TI se integran cada vez
debido a esto se depende más de ellas, esto las convierte
factor de riesgo de falla incrementa y las consecuencias
conllevar en poner incluso vidas de los usuarios en peligro.
se presentan en el software puede
más a nuestra vida cotidiana y que
en algo más complejo por lo cual el
en un futuro no muy lejano podría

Página |2
Lectura 2: No silver bullet essence and accidents of software engineering

En este artículo el autor Frederick Brooks nos muestra una visión de los proyectos
informáticos son totalmente diferentes a los bienes materiales ya que los conceptos en los que se
basan para satisfacer muestras necesidades no se pueden aplicar al software.

Brooks llega a comparar los proyectos de software con seres fantásticos del folklore, como
lo son los hombres lobo, ya que en un principio paren ser inofensivos he inocentes, pero pueden
llegar a convertirse en monturas de tareas incumplidas, presupuestos dilapidados, hasta llegas a
ser un producto defectuoso, para el cual existe una solución como lo sería la plata para un hombre
lobo, sin embargo menciona que en más de una década no ha habido desarrollo para dicha
solución, ya sea en técnicas de administración, mejoras de productividad o mejora en las técnicas
de gestión, que prometería mejora en la productividad, confiabilidad y simplicidad.

Brooks considera que la parte más compleja de la construcción de software es la parte

conceptual, la especificación de tareas, el diseño del mismo, restándole importancia a la
representación del modelo y el testeo, por lo cual considero cuatro propiedades esenciales y
permanentes del software:

 Complejidad: la mayoría de los problemas al momento desarrollar software tiene que ver
con esta propiedad, ya que debido son más complejas por su tamaño, además de que no
existen dos entidades iguales, lo cual los hace tan diferentes de los equipos tradicionales,
edificios o automóviles, donde abundan los elementos repetidos.

 Conformidad: en esta propiedad nos explican que es esencial que el software se adapte
al entorno y al revés, como lo seria los procesos de una empresa, donde después llega la
automatización de los mismos, cumpliendo a su vez con ciertas interfaces como lo serían
los usuarios y otras aplicaciones.

 Mutabilidad: en este punto nos dice que debemos estar conscientes de que el software
siempre está sujeta a cambios, en gran medida por tratarse de piezas intangibles fáciles
de alterar o destruir, son fáciles de recuperarse, sin embargo nos menciona que el principal
factor del cambio es el usuario, ya que en cuanto el usuario se encuentra cómodo con un
programa que le es útil, siempre buscara nuevas formas en que este le pueda ser útil.

 Invisibilidad: esta es la propiedad más lógica ya que sería complicado representar

software en el espacio real, ya que se necesitarían infinidad de diagramas para representar
flujos de control, datos, secuencias temporales, etc. Definido en pocas palabras, el
software se intuye pero no se ve.

Además de estas propiedades esenciales y permanentes, Brooks nos menciona que existen
otras dificultades accidentales que existen dada la forma actual de construir software, pero no son
esenciales.

 Lenguajes de alto nivel: se refiere a operaciones, tipos de datos, comunicaciones, son

sistemas que tratan de acercarse a la forma de análisis que utiliza el usuario para resolver
problemas, ocultando la verdadera complejidad del sistema.

 Tiempo compartido: la posibilidad de compartir el tiempo de ejecución entre procesos

evitaría los accidentes de los programas batch que se ejecutan en forma lenta y mejora el
tiempo de respuesta.

 Entornos de programación unificados: Brooks hace referencia a programas como

INTERLISP y Unix que por medio de bibliotecas integradas, formatos de archivos

Página |3
 unificados y filtros combaten el accidente de tener aplicaciones que resuelven en forma
individual la problemáticas comunes.

A continuación el autos comienza con lo que serían diversos intentos de la creación de la bala
de plata, como lo serían la programación orientada a objetos, la cual para muchos es la técnica que
más esperanza tiene, ya que se debe tener cuidado de distinguir dos ideas esenciales los tipos
abstractos de datos y los tipos jerárquicos, inteligencia artificial, en la cual se tienen grandes
esperanzas para facilitar el avance en las ganancias de la productividad y calidad del software, los
sistemas expertos, son la parte más avanzada de la IA y a su vez la más aplicada ya que es la
tecnología que permite la creación de un entorno de software, la programación automática, es un
eufemismo para la programación con un lenguaje de alto nivel que se dispone actualmente para el
programador, la programación visual, en cuanto a esta bala el autor se muestra escéptico en
cuanto a su avance, la verificación de programas, y los entornos y herramientas.

Lectura 3: Software’s chronic crisis

La lectura comienza con un ejemplo aeropuerto de Denver, el cual sería convertiría en uno
de los más sofisticados, o al menos ese era el plan, ya que se han presentado muchos errores de
software en el sistema que controla su sistema de automatización de equipajes, lo cual provoco
que la apertura del mismo se aplazara indefinidamente, este es un problema que para los
desarrolladores expertos se destaca por su visibilidad, demostrando que por cada seis nuevos
sistemas de software a gran escala que se ponen en funcionamiento, otros dos se cancelan.

Nos dicen que la programación ha estado durante 50 años de purificación y refinamiento, y

que se ha topado con algunas crisis y que en el otoño de 1968, el Comité Científico de la OTAN,
convoco a 50 de los mejores programadores para trazar un curso de lo fue la crisis del software,
naciendo de esta forma la ingeniería de software, la cual se define como la aplicación de un
enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de
software.

Página |4
¿Por qué falla el software?

Existen diferentes factores por los cuales el software puede fallas en la lógica de los
programados, errores en las líneas de código, incompatibilidad con los dispositivos así como
ciertos criterios que fueron mencionados en las lecturas como lo son:

• Objetivos poco realistas o desarticulado de proyectos

• Inexactas estimaciones de los recursos necesarios
• Mal definidos los requisitos del sistema
• Mala presentación de informes de estado del proyecto
• Administrado riesgos
• Mala comunicación entre los clientes, desarrolladores y usuarios
• Utilización de la tecnología inmadura
• Incapacidad para manejar la complejidad del proyecto
• Descuidado las prácticas de desarrollo
• Mala gestión de proyectos
• Política de las partes interesadas
• Comercial presiones

A esto tendríamos que sumar que la complejidad del software va ir aumentando conforme
se realizan nuevas investigaciones y se desarrollan nuevos patrones de desarrollo, así como uno
de los factores más importantes seria la capacidad de la utilización del software de los usuarios,
además que todo esta se podría prevenir si la empresas prestaran un poco de atención y brindaran
algunos recursos para prevenir este tipo de fallas.

Bibliografía:

 Why Software Fails, Charette, IEEE Spectrum, September 2006 (Lectura de la semana 1)
 No Silver Bullet Essence and Accidents of Software Engineering , Frederick P. Brooks,
Jr., University of North Carolina at Chapel Hill, Computer Magazine; April 1987.
 Software's Chronic Crisis, TRENDS IN COMPUTING, W. Wayt Gibbs, Scientific
American, 1994.

Página |5