Acontecimientos: concentrarse únicamente en la sección 3

Para extraer los acontecimientos del documento sólo se tendrán en cuenta los requisitos numerados, los que estan contenidos en la sección 3. Esos son los verdaderos requisitos, los que debemos diseñar (y, si hubiera tiempo, implementar). El resto es introducción, descripción general, perspectivas de futuro, pero nada más…

Primeras dudas: Req(06), usuarios y operaciones de mantenimiento

Algunas dudas que han ido llegando hoy:

• Hay una redundancia clara en el Req(06): “El usuario podrá consultar qué tipos de aportaciones existen y su descripción. Adicionalmente, el usuario podrá consultar qué tipos de aportaciones existen y en qué consiste cada una.” Estas dos frases dicen, en realidad, lo mismo.
• A los usuarios del sistema no conviene denominarles “usuarios” sino “gestores de AMM” o simplemente “gestores” o algo parecido. Recordad que son tan sólo 7-8 personas. En algunos acontecimientos funcionarán como usuarios (no son Entidad Externa) y en otros casos funcionarán como orígen/destino de información (sí son Entidad Externa).
• Como se ve, a partir de los requisitos surgen operaciones de mantenimiento (altas, bajas y modificaciones) de almacenes. La duda, por tanto, es ¿las operaciones de alta, baja y modificación constituyen un sólo acontecimiento o son tres acontecimientos separados? Cada grupo podrá hacerlo como considere conveniente. Por un lado, está bien considerarlos tres acontecimientos separados, pues suceden en tiempos distintos. Por otro lado, las tres operaciones son tan similares entre sí que resulta muy cómodo agruparlas en un acontecimiento único, llamado “mantenimiento de X” o algo así. Ésta solución tiene la ventaja adicional de minimizar el número de acontecimientos, pero tiene la desventaja de hacer que los contenidos de los flujos sean un pelín más complejos. Caben, además soluciones intermedias, como fusionar en un acontecimiento las altas y modificaciones (operaciones muy similares entre sí) y poner las bajas en otro acontecimiento separado (pues una baja requiere información distinta de un alta o modificación). Queda a la elección de cada grupo el hacerlo de una determinada forma o de otra.

Publicados los enunciados de las entregas individuales

Ahora mismo he publicado un documento con los enunciados de los ejercicios individuales, tanto los correspondientes al grupo de evaluación continua como al grupo tradicional. El documento, como siempre, podréis encontrarlo aquí.

Normalización y 3FN

Para aquell@s que necesiten refrescar un poco el tema de la normalización de datos, que será imprescindible para las tareas de los próximos días, he encontrado esta página web donde, en sencillos pasos, nos explica todo lo referente a la normalización: Rules of data normalization.

IS2: Comienza el Bloque III

Hola a tod@s. Mañana día 9 comenzamos con el bloque 3 de la asignatura, dedicado a la técnica de estructurado según Yourdon. Ya he colgado la documentación necesaria en el sitio habitual: se trata de un pdf con la teoría y otro con ejercicios. El resto de documentos necesarios (enunciado de la práctica, etc.) ya se os entregó en su día, cuando vimos Ingeniería de Requisitos (bloque 1 de la asignatura).

Twitter andres_silva

He creado una cuenta en twitter, que a lo mejor resulta más útil de seguir que las rss, ahora que comienzan de nuevo las clases. He configurado esto para que todos los posts de este blog sean twitteados a mi cuenta de twitter. Ya veremos. No es más que un experimento, a ver que tal sale…

Comienzo del curso de IS2 08/09

Hola. Este blog, igual que otros años, proporcionará un canal de comunicación más entre nosotros, y servirá tanto para el grupo tradicional como para el grupo de evaluación contínua. De momento, quizá no resulte muy útil, pero en Enero será fundamental, para aclarar cosas de la práctica de DFDs (estructurado). De momento, podéis ir echando un vistazo a los posts que hay por aquí (aunque ya he borrado muchos, pues eran irrelevantes para el curso actual) y a los links que he recopilado en la sección de “Requisitos”, en la columna izquierda. Por lo demás, ya sabéis que la documentación importante es la que está en la web de la UDIS.

Grandes fracasos informáticos. Software Hall of Shame

La revista “IEEE Spectrum”, en septiembre de 2005, dedicó un artículo a reflexionar sobre los fracasos en los proyectos software. El artículo, como se ve, fue publicado hace tres años, pero conviene seguir teniéndolo presente, pues las cosas no han cambiado tanto desde entonces. La referencia completa es la siguiente:

R. N. Charette, “Why software fails [software failure],” Spectrum, IEEE, vol. 42, no. 9, pp. 42-49, 2005.
Disponible en: http://dx.doi.org/10.1109/MSPEC.2005.1502528

El artículo incluía la siguiente lista de grandes fracasos (el Hall of Shame de la industria del software). No están todos los que son, pero son todos los que están. Todas las cifras en dólares:

• 2005. Hudson Bay Co. (Canada): Problemas en el sistema de inventario conducen a un pérdida de 33.3 millones.
• 2004-2005. UK Inland Revenue (UK): Errores de software condujeron a pagos excesivos (tax-credit overpayments), por valor de 3.45 mil millones.
• 2004. Avis Europe PLC (UK): Sistema ERP cancelado tras invertir en él unos 54.5 millones.
• 2004. Ford Motor Co. El sistema de compras es abandonado tras gastarse en él unos 400 millones.
• 2004. J. Sainsbury PLC (UK): Sistema de SCM (Supply-change management) abandonado tras su instalación, y tras un gasto de 527 millones.
• 2004. Hewlett-Packard Co.: Problemas en el sistema de ERP contribuyen a una pérdida de 160 millones.
• 2003-2004. AT&T Wireless: Una “mejora” al sistema de CRM (Customer relations management) lleva a una pérdida de 100 millones.
• 2002. McDonald’s Corp.: Sistema de gestión de compras cancelado tras gastarse 170 millones.
• 2002. Sydney Water Corp (Australia): Sistema de facturación cancelado tras gasto de 33.2 millones.
• 2002. CIGNA Corp.: Problemas con sistema CRM contribuyen a una pérdida de 445 millones.
• 2001. Nike Inc.: Problemas con el sistema de SCM llevan a una pérdida de 100 millones.
• 2001. Kmart Corp.: Sistema SCM cancelado tras gastar en él unos 130 millones.
• 2000. Ayuntamiento de Washington DC: Sistema de nómina es abandonado. Coste: 25 millones.
• 1999. United Way: Sistema administrativo cancelado tras un gasto de 12 millones.
• 1999. Estado de Mississippi: Sistema de impuestos cancelado tras gasto de 11.2 millones.
• 1999. Hershey Foods Corp.: Problemas con el sistema de ERP llevan a una pérdida de 151 millones.
• 1998. Snap-on Inc.: Problemas con el sistema de recepción de pedidos provocan pérdida de 50 millones.
• 1997. US Internal Revenue Service: Un caso muy conocido y estudiado, debido a su magnitud y a que sucedió en el sector público. La modernización del sistema de impuestos fue cancelada tras un gasto de 4 mil millones.
• 1997. Estado de Washington: El sistema para el Departamento de Vehículos a Motor es cancelado tras un gasto de 40 millones.
• 1997. Oxford Health Plans Inc.: Sistema de facturación provoca grandes pérdidas. La subsecuente caída en bolsa de la empresa se contabiliza en 3.4 mil millones
• 1996. Ariane Space (Francia): Errores en la especificación y el diseño del software para el Ariane 5 conducen a la explosión del mismo, valorado en 350 millones
• 1996. FoxMeyer Drug Co.: Sistema de ERP de 40 millones es abandonado tras su instalación. Como consecuencia, la empresa se declara en bancarrota.
• 1995. Bolsa de Toronto (Canada): Sistema de trading cancelado tras un gasto de 25.5 millones
• 1994. US Federal Aviation Administration (FAA): El Advanced Automation System fue cancelado tras un gasto de 2.6 mil millones. Uno de los “supervivientes” de dicho proyecto, Robert N. Britcher, contó sus deprimentes experiencias en un libro titulado “The limits of software” (Addison-Wesley, 1999).
• 1994. Estado de California: Sistema DMV cancelado tras gastar 44 millones.
• 1994. Chemical Bank: Error en el software provoca la deducción de unos 15 millones de las cuentas de unos 100.000 clientes.
• 1993. Bolsa de Londres (UK): Systema Taurus es cancelado tras gasto de 600 millones.
• 1993. Allstate Insurance Co.: Sistema de automatización de tareas es abandonado tras su instalación. Coste: 130 millones.
• 1993. London Ambulance System (UK): Otro caso muy bien estudiado. El sistema de gestión de urgencias, debido a su ineficiencia, fue cancelado tras un gasto de 11.25 millones. Se produjo un segundo intento, para remediar dicho fracaso. Dicho intento no sirvió de nada, y provocó una nueva pérdida, esta vez de 15 millones.
• 1993. Greyhound Lines Inc.: Sistema de reserva de autobuses cancelado por sus continuas caídas. La empresa deja de ganar unos 61 millones.
• 1992. Budget Rent-A-Car, Hoteles Hilton, Marriott International y American Airlines: Sistema integrado de reservas cancelado tras un gasto de 165 millones.

Si a alguien le apetece, puede hacer la suma de todos los millones de dólares que se han perdido, y pensar en la cantidad de cosas útiles que se podrían haber hecho con ese dinero. Yo prefiero no hacerlo, que me pongo malo.

Metro de Washington DC: Incendio causado por el software

Según este artículo del Washington Post, el Domingo de Pascua comenzó un incendio después del fallo de un sensor situado bajo un vagón, provocando subidas de voltaje en dicho vagón. Al mismo tiempo, “el software que monitorizaba el flujo de electricidad tambien falló, causando sobrecalentamieto”. El software se diseñó sin tener en cuenta la posibilidad de fallo en el sensor que monitorizaba dicho flujo de electricidad (o sea que, pese a lo que dice el Post, en realidad el software no “falló”; mucho peor: había sido mal concebido). Washington DC Metro está ahora mismo reemplazando dicho software por otro que evita dicho problema.

FBI Virtual Case File: 170 millones a la basura

Os recomiendo que escuchéis este episodio podcast, via IT Conversations, dónde varios expertos comentan la reciente debacle en el desarrollo del llamado FBI Virtual Case File, sistema orientado a modernizar la infraestructura informática del FBI. Un (fra)caso “de libro”: no había requisitos, no había plan, no había personal apropiado (pese a que muchos de ellos poseían un doctorado), no había nada, no hay ni palabras para describir lo que allí sucedió…