Posible retraso de la primera entrega.

A fecha de hoy, veo que casi la mitad de los alumnos matriculados en la asignatura no han contactado conmigo. Quizá tenga que retrasar una semana la entrega del primer trabajo (concepto Hazard, previsto para el 11 de marzo), con objeto de dar tiempo a todos los alumnos a contactar conmigo, y así poder todos continuar al unísono (sería un poco problemático si unos alumnos avanzan y otros van rezagados, tal y como ha sido concebido el curso).

Primer concepto: Hazard

Comenzamos a trabajar. El primer concepto será el de “Hazard”, que podríamos traducir por “peligro”, pero esa traducción no es exacta (y si hacéis bien vuestro trabajo, pronto veréis el porqué). Al tratarse del primer trabajo, vamos a dar un margen de entrega de dos semanas. En relación al formato y otros detalles, me remito a la normativa de la asignatura. Os recuerdo, eso sí, que el trabajo se entrega por mail, en formato pdf. Dicho pdf, si es posible, debería estar anonimizado, es decir, no debería identificar al autor (o autores). Esto es para facilitar la tarea posterior de “peer-review” que, como expliqué el otro día, debería garantizar el anonimato.

Siempre que yo anuncie un nuevo concepto para trabajar, proporcionaré una serie de referencias básicas. Dichas referencias no sirven más que como punto de partida para comenzar vuestra búsqueda.

Recordad que el objetivo es escribir un documento que explique el concepto a vuestros compañeros. Posteriormente dichos documentos serán sometidos a puntuación por el resto de compañeros, y se discutirán en una clase presencial. Todo ello se anunciará en su día en este mismo blog.

En resumen:
Concepto: Hazard
Fecha de entrega: 18 de marzo de 2009.
Referencias de partida: transparencias de safeware, libro de N. Leveson, otras referencias.

Asignatura de software crítico. Primer post.

Empezamos, por tanto, con la asignatura de Master de Prevención de Accidentes y Software Crítico. Para aquellos que no hayáis asistido a la presentación del miércoles 25, os recuerdo que la nueva normativa de la asignatura se encuentra en esta página. Como véis, habrá que trabajar una serie de conceptos, en grupos de dos alumnos (o individualmente, si alguien lo prefiere así). Nuestro centro de comunicación será este blog y, posiblemente en unos minutos, publicaré aquí lo que habrá que hacer con el primer concepto, fechas de entrega y otra información relevante. Hasta pronto.

Este blog a partir de ahora y hasta el verano

A partir de ahora, este blog se reservará para la asignatura de Máster sobre Software Crítico y Prevención de Accidentes. Por tanto, aquellos alumnos que no cursen dicha asignatura, podrán, si quieren, dejar de consultarlo, pues ya no les conciernen los temas aquí tratados.

Sobre la integración de SyS a nivel nacional

He notado un problema de interpretación acerca de lo que hay que hacer en el ejercicio de integración de los sistemas autonómicos. Se trata de unificar la gestión, pero manteniendo cada una de las sociedades de cada comunidad autónoma. Es decir, se mantiene en cada momento qué sociedad (de qué comunidad autónoma) ha hecho qué actividad, qué encuesta, etc. Para ello habrá que tratar con códigos de comunidad autónoma, y eso tendrá cierto impacto en el sistema.
O sea, no es una fusión de todas las sociedades en una. Lo que hay que permitir es una gestión integrada de las distintas sociedades que, en cuanto a su funcionamiento interno, seguirán existiendo y siendo autónomas.

Curiosidad: Fotos de Ed Yourdon

Tras días y días de darle vueltas al tema de los DFDs según Yourdon, me ha resultado muy curioso el encontrar fotos del propio Ed Yourdon en Flickr. Resulta que es un gran y prolífico fotógrafo y, a juzgar por muchas de sus fotos, es un enamorado de Manhattan. Podéis ver sus fotos en su página de Flickr.

Req(18): Análisis estadístico

Os recuerdo que, según vimos en clase, las estadísticas, para eliminar la vaguedad con la que están tratadas en la ERS, vamos a reducirlas a una sola acción: La obtención de datos correspondientes al total de altas y bajas de SySs a lo largo de un período de tiempo. Ya está, no habrá más estadística que esa.

Sobre quien “hace” las cosas en nuestro sistema

Veo que todavía persiste cierta confusión respecto a quienes son las entidades externas. Básicamente, de lo que se trata es de recordar que el concepto de “usuario” y el de “entidad externa” son DISTINTOS. En los DFDs (al contrario que hacíamos en los Casos de Uso) no nos importa el usuario (no nos importa quien “mete” las cosas en el sistema): nos importan los orígenes y destinos de la información. Por ejemplo, a la hora de recibir el papelito con la nómina de la UPM, yo (Andrés Silva) soy una Entidad Externa para el sistema informático de la UPM, pero yo no soy el usuario. Yo no uso ese sistema ni sé en que S.O. corre ni nada. Igualmente, cuando tú renuevas el DNI tú no eres un usuario del sistema de DNI (tú eres la entidad externa y los usuarios serán personal del Ministerio del Interior).
Por tanto, no hay que preocuparse de quien “Introduce los datos” sino de a quien van o de donde vienen…
Y por cierto, sí, puede haber más de una entidad externa en un acontecimiento.

Nuevas dudas que han llegado por mail

> Somos los del grupo XXX y queriamos preguntarte un par de dudas que tenemos.
>
> La primera era sobre los socios y simpatizantes. No sabemos si
> tratarlos como dos entidades separadas o solo como una y definir en el
> almacen un campo a elegir tal que:
> [socio + cuota | no_socio]
> ya que todos los eventos que tienen son iguales y la única diferencia
> entre ellas es que uno paga cuota de socio y el otro no.

Las dos opciones son válidas, mientras lo hagáis de manera coherente. Yo creo que bastaría una sola entidad-almacén, pero no sería incorrecto utilizar dos.

> Otra duda que tenemos es sobre los SyS que envian respuestas a las
> encuestas (Req(14)) , estas se almacenan en una Base de Datos
> Complementaria al sistema. Nuestra pregunta es: ¿Hay que tratar esta
> base de datos complementaria como una entidad externa o como un
> almacen?

Los requisitos hablan de una BD “complementaria al sistema, pero relacionada con él”. Traducción: es parte de nuestra BD. Por tanto, figura en el E/R y tendrá su reflejo en los almacenes.

> Esta última duda tambien nos serviría para aclarar sobre los Back-ups
> automáticos del sistema (Req(27)), pues creemos lógico que el back up
> del sistema vaya a una entidad externa, pero no estamos del todo
> seguros.

No es necesario un acontecimiento para backups. Ni tampoco para los logins. Suponemos que existe una infraestructura informática básica (SO, SGBD, etc.) y por tanto, son cosas que nosotros no desarrollaremos. Si no las desarrollamos, no son acontecimientos.

Algunas dudas que han llegado por mail

> Referente al Req(12) -> ¿Debe recibir el gestor AMM una notificación de
> dirección de correo errónea?

No, no es necesario. Nuestro sistema (AMM) podrá proporcionar listas de direcciones mail para enviar información, y ahí se acaba su función. Otro sistema, no desarrollado por nosotros (mailman, por ejemplo), es el que se encargará de gestionar el envío y los mensajes de error en el mail.

> Referente al Req(16) -> ¿Es necesario que el sistema de pago externo (tipo
> PayPal) envíe una confirmación de pago de donaciones, o se suponen anónimas?
> ¿Hay que almacenarlas?

Las donaciones pueden ser anónimas o no. Supondremos que PayPal nos envia informes de quien ha donado dinero, y para qué causa (si la hay). Las donaciones, en principio, son un tipo de aportación y habrá que tratarlas como tales.

> Req(29) -> ¿Debemos contemplar como acontecimiento el acceso (tanto por
> parte del gestor AMM como del administrador) con login y password?

Partimos de una infraestructura software habitual: un sistema operativo más o menos seguro, y una base de datos relacional. Por tanto, no vamos a considerar lo acontecimentos relacionados con el login/password ni con los bloqueos de registro, pues NO vamos a desarrollarlos ni a programarlos ni nada. Simplemente, es algo con lo que ya contamos…

> Al dar de baja un SyS, ¿qué ocurre con las aportaciones? ¿Debemos indicar
> que se borran o suponer que lo hace la BD?

Es habitual, en los Sistemas de Información, que las bajas no impliquen borrado. Yo he sido empleado de la Universidad Carlos III hace unos 10 años pero sigo en su BD (como “inactivo”, eso sí). Es decir, un SyS puede darse de baja, y lo marcaremos como inactivo (o algo así), pero no implica que lo borremos de la BD. Sus datos siguen ahí, y pueden ser útiles para el futuro, o para ciertas consultas. Eso evitará, además, los borrados en cascada.

> Req(28 ) -> ¿Hay que contemplar también este requisito? (el hecho de que el
> administrador realiza mantenimiento)

No. Al igual que otros requisitos no funcionales (de calidad, usabilidad, seguridad, etc.), no es posible que generen acontecimientos.