En este blog podréis ir viendo el desarrollo día a día de un proyecto software bajo la Métrica v3 del grupo 3 de Ingeniería del Software III (Ingeniería Informática) de la Universidad Carlos III de Madrid.

lunes, 17 de diciembre de 2007

Seguridad en las comunicaciones

En la entrada de hoy explicaremos los procedimientos necesarios para que las comunicaciones mediante e-mail's entre los integrantes de un equipo de desarrollo se realicen de manera segura,

Un aspecto primordial para la excelencia y calidad en el software es obtener un determinado nivel o certificado de seguridad. Sin embargo, como se puede pensar desde un inicio la seguridad no se centra únicamente en securizar el producto, por ejemplo: cifrar las comunicaciones entre la parte cliente y servidora, control de datos de la entrada (verificación del código postal, letra del DNI...), comprobación de datos bancarios, etc. Sino que también hay que diseñar un escenario donde las comunicaciones y envíos de información entre los miembros del equipo de desarrollo se desarrollen garantizando la
confiabilidad, integridad y el no repudio, es decir, los principios básicos de un sistema seguro en el ámbito de las tecnologías de la información.

Lo primero de todo es identificar los problemas que surgen en un escenario no seguro en las comunicaciones. Éstos se pueden enunciar en los siguientes puntos:
  • Interceptación de mensajes. Los e-mail's se envían a través de la red sin cifrar, por lo que puede haber un sujeto que los intercepte y obtenga información confindencial, secreta o crítica: solución propuesta por la empresa al problema del cliente, cuentas bancarias, etc.
  • Modificación de información por terceros. En un problema similar al anterior, no se garantiza que la información enviada por A a B sea la original y haya sido modificada por un sujeto que "snifar" la comunicación.
  • Autenticación del emisor. Un ejemplo sencillo sería el siguiente: si un compañero X nos envía el desarrollo de un determinado componente del sistema a construir, ¿cómo sabemos que es X el que lo ha hecho realmente y no otra persona que nos intenta enviar el mismo componente pero con errores u otro con malas intenciones?
Para solucionar esto, proponemos la introducción de la criptografía de clave pública o clave asimétrica y la firma digital en el envío común de e-mail. El proceso a seguir son sencillos y además, que según la compañía que nos certifique nuestra identidad podemos securizar nuestra dirección e-mail totalmente gratis. A continuación os damos los pasos:

1. Obtener un certificado de nuestro e-mail. Como os hemos dicho antes, lo podéis conseguir de empresas a través de una pequeña cantidad de dinero como por ejemplo la lider mundial en certificación: VeriSign (20$), o gratis por medio de la empresa COMODO SSL. Os recomendamos que si queréis una certificación totalmente confiable, os decantéis por VeriSing, sin embargo, si la comunicación es informal y no os interesa la opinión de terceros, la solución es COMODO SSL.

2. Instalar el certificado en vuestro cliente de correo. Os daremos los pasos para Mozilla Thunderbird

Clic en la gestión de certificados.

Importar el certificado obtenido de VeriSign, COMODO u otros.

3. Firmar y/o cifrar los e-mail's con el certificado instalado (seguimos el ejemplo para Mozilla Thunderbird).

Seleccionar la opción que deseemos con nuestro certificado: firmar y/o cifrar.

4. De esta forma, garantizamos la confiabilidad (en el caso que cifremos el mensaje) y la integridad y no repudio (en caso que firmemos el mensaje).

Bueno, esperamos que os hayamos convencido de la necesidad de la certificación de los e-mail's para el trabajo, os haya quedado claro la explicación y si tenéis alguna duda, no dudéis en escribir en los comentarios de esta entrada.

Un saludo, y nos vemos en la siguiente entrada: "Consejos de Oferta (2)".

domingo, 16 de diciembre de 2007

Consejos Oferta (1)

Hola otra vez. Hoy queremos mirar hacia atrás en el tiempo y volver al inicio del proyecto, para recordar el documento de oferta.

Ahora que podemos observar el proyecto desde una perspectiva mayor, hemos comprendido la importancia de aquel primer documento en el que, por ser el primer documento del proyecto y de la asignatura, nos encontrábamos muy inseguros y sin saber muy bien como afrontarlo.

Probablemente sea el documento más importante de todo el proyecto, no solamente por ser con el que se vende el proyecto al cliente (como bien nos dicen en la asignatura pero esta faceta no parece demasiado importante para la asignatura en sí), sino que también porque en él se definen muchas características del proyecto que luego hay que seguir arrastrando durante todo el proyecto.

Y es que nuestro documento de oferta, al contrario de lo que realmente debería de hacerse en un proyecto bien llevado, se realiza antes que el documento de estudio de viabilidad de sistema y el de seguimiento inicial de proyecto. Esto significa que en el documento de oferta se incluye gran parte de estos dos documentos, por lo que realizarlo mal tiene graves consecuencias.

En concreto, desde nuestra experiencia, tuvimos problemas con la estimación de costes del proyecto por no haber realizado el EVS. Pero lo que más hemos notado es que hemos tenido que arrastrar la planificación inicial durante todos los informes de seguimiento.

En conclusión, recomendamos que antes de realizar una oferta se realice un estudio de viabilidad del sistema (se recojan los requisitos, se analicen los requerimientos de hardware y software y, en base a todo esto, se estime el coste como ya explicamos en un anterior post). También debe realizarse una planificación de tareas con cuidado, utilizando las herramientas de estimación ya mencionadas.

Para los estudiantes de la asignatura, evidentemente no van a realizar documentos sin que el profesor se los pida pero recomendamos que hagan un esfuerzo máximo para el primer documento, ya que, aunque cueste desde la primera semana empezar a trabajar duro, puede ser muy importante para lograr un buen resultado final.

Por hoy es suficiente, pero en próximos post esperamos poder seguir dando consejos para éste y otros documentos, ya que al ser el primer proyecto creemos que estamos aprendiendo mucho y queremos compartirlo con nuestros lectores, especialmente con alumnos de nuestra asignatura de próximos años que es a los que más podemos ayudar, pero también a todos aquellos que nos leéis interesados en general por la ingeniería del software.

PD: Un comentario al año no hace daño.

miércoles, 12 de diciembre de 2007

Nueva entrevista Jorge Becerril

¡Ya estamos aquí de nuevo! Hacía un tiempo que no publicábamos una entrevista, tranquilos... En estos días habrá una sesión doble. En la entrada de hoy recogeremos la opinión de Jorge Becerril, experto en ingeniería del software, que ya tuvimos el gusto de realizarle una entrevista en los comienzos del blog y que fue tan bien valorada por los profesores de la asignatura.

Esta nueva entrevista tratará sobre las diferencias encontradas en la metodología que usamos respecto a la que sigue Jorge Becerril en Méjico. Así pues, sin más rodeos vamos con la entrevista:

En nuestra universidad estudiamos las metodologías de desarrollo Métrica 3 y ESA. ¿Qué metodología o metodologías de desarrollo de software suele utilizar?
Recuerdo que algunas ves oí decir a alguien no importa que metodología uses lo importante es usar una,creo que difícilmente una metodología cumplirá con lo que requiere una empresa o bien un proyecto por lo cual a veces tienes que personalizar la metodología, normalmente me gusta usar metodología en espiral y RUP.


Sobre dichas metodologías, ¿en qué fases o actividades ( Análisis, Diseño, etc.) se dividen?
Prácticamente en todas las fases de desarrollo desde los requerimientos hasta la implementación.

¿Qué tipo de técnicas de modelado del sistema y su entorno utilizas generalmente?

Nosotros utilizamos bastante UML: casos de uso y sus diagramas, diagramas de secuencia, de colaboración, diagramas de despliegue, etc.

Al igual que ustedes uso mucho UML y últimamente para modelado de procesos uso BPMN (Business Process Management Notation)


Ya vemos que se guía mucho por las referencias y directrices del OMG (Object Management Group). En cuanto a las herrameintas CASE, ¿utilizan alguna para facilitar el trabajo? ¿Qué tipos de herramientas?
Definitivamente es importante usar herramientas CASE la que nunca dejo de usar es Case Studio para el diseño de base de datos.

Respecto a la obtención de requisitos:Qué tipo de técnicas de captura utiliza ¿entrevistas, reuniones, estudio de la documentación del tema a desarrollar, ...?
Creo que la principal herramienta o técnica como lo mencionas es la entrevista, en lo particular me funciona mucho el uso prototipos, la revisión de documentación, los sistemas actuales, revisión de procedimientos, reglamentaciones de instituciones a las que estén sujetos.

Muchas gracias por todo.


Pues esto ha sido todo por hoy. Como hemos dicho, en los próximos días publicaremos una nueva entrevistas sobre líderes y liderazgo en la ingeniería del software que creemos que será muy interesante.

P.D.: Si queréis ver la planificación a la que está sujeto el desarrollo de nuestro sistema de información de marcadores sociales, podéis consultar el nuevo enlace que hemos añadido a Google Calendar que hemos creado.

lunes, 10 de diciembre de 2007

Estimación de Coste del Personal

El otro día comentabamos de lo importante que es la estimación de costes para calcular el presupuesto de un proyecto.

La estimación que requiere de más experiencia es la de coste de personal, ya que si se sabe que materiales se van a dedicar para el proyecto, el cálculo de su coste es directo.

Sin embargo, del coste de personal, a priori antes de comenzar el proyecto, solamente podemos saber cuanto cobran nuestros empleados por hora, pero no sabemos cuantas horas tendrán que dedicar al proyecto.

Para intentar estimar el coste total del proyecto, existen varios métodos:

1) Técnicas Matemáticas: Utilizan modelos matemáticos que reciben como entrada datos sobre el proyecto a realizar y, tras la aplicación de fórmulas matemáticas, dan la respuesta.

2) Técnicas basadas en el aprendizaje automático: A partir de los datos de muchos proyectos, generan un modelo que, dado otro proyecto del que no se sabe nada realizar la estimación. Dan buenos resultados pero requieren de gran cantidad de datos que en una empresa pequeña no se dispondrán.

3) Técnicas basadas en expertos: Se basa en contratar a expertos para que realicen la estimación. Muy caras, por lo que para un proyecto pequeño no son recomendables.

4) Técnicas Dinámicas: Son técnicas basadas en matemáticas más complejas. Tratan de hacer una simulación matemática mediante funciones recursivas.

En conclusión, lo más apropiado para un proyecto pequeño es aplicar técnicas matemáticas. En nuestro caso, hemos estudiado en la asignatura la herramienta Cocomo 2, que es capaz de realizar estas estimaciones aplicando un modelo matemático. Únicamente es necesario introducir en el programa algunos datos sobre el proyecto, desde la experiencia y habilidad de los desarrolladores hasta la complejidad del proyecto.

Cocomo tiene varios tipos de modelos: el básico, el intermedio y el avanzado. Lo más lógico para un proyecto pequeño sería utilizar el modelo básico o el modelo intermedio.

A continuación, para aquellos que quieran profundizar más en este tema, ofrecemos una recopilación de referencias:
Tutorial de Estimación de Costes
Página Principal de Cocomo
Modelo de Cocomo
Cocomo Básico Online
Cocomo Intermedio Online
Otro calculador Online

sábado, 8 de diciembre de 2007

Correo desde El Salvador

El otro día recibimos un correo desde El Salvador, de Jorge Valencia, que nos preguntaba por lo siguiente:

"Tengo una consulta para ustedes y se los agradesería mucho su ayuda. Necesito realizar un presupuesto de implementación de un software y no se que elementos tendría que tomar en cuenta.

El software es un programa de inventario para una empresa pequeña. El software es pequeño."

Decir que no somos muy expertos en el tema de estimación y que, como ya dijimos en el post de "Opiniones sobre Oferta", nos parece una tarea que requiere experiencia. Sería recomendable consultar otras fuentes para completar los consejos que podamos dar nosotros.

Aun así, hemos estado recopilando lo que sabíamos al respecto (de ahí la tardanza de la respuesta, sentimos no haber podido contestar antes) y hemos reunido lo siguiente:

En primer lugar, para realizar un presupuesto, (en nuestro caso documento de cálculo de costes), lo más importante es estimar el coste. A partir del coste estimado, se añadirá el porcentaje de beneficios que se quiere obtener, el porcentaje de primas de riesgo y el porcentaje de IVA (o los impuestos a los que esté asociado el proyecto en el país que sea).

El porcentaje de riesgos no debe infravalorarse, hay que valorar el riesgo de impago, riesgos asociados al fracaso del proyecto, etc. En caso de que se produzcan dichos riesgos y hubiese pérdidas económicas, se agradecerá haber incluido dicho porcentaje por riesgos en el resto de proyectos de la empresa.

Pero pasamos a la estimación de coste que, bajo nuestro punto de vista, es el punto más complejo e importante (el resto de factores sacan porcentaje sobre el coste, por lo que éste resulta ser la base de todo el presupuesto). Hay que desglosar y estimar todos los costes asociados al proyecto, por ejemplo: coste de personal, de comidas con el cliente, de material (amortización de hardware y software, gasto en papel para los documentos, electricidad, etc.).

No se debe omitir ningún gasto por pequeño que parezca en un principio ya que una vez se firme el presupuesto con el cliente no habrá marcha atrás y cualquier coste no considerado tendrá que asumirlo la empresa que desarrolla el software.

La estimación que requiere de más experiencia es la de coste de personal, ya que si se sabe que materiales se van a dedicar para el proyecto, el cálculo de su coste es directo. Sin embargo, consideramos que dicha estimación es un tema suficientemente importante como para dedicarle otro post para él solo, que publicaremos en un par de días.

Hasta la próxima. Para cualquier duda, dejadla en los comentarios y la contestaremos lo antes posible.

martes, 4 de diciembre de 2007

Listado de Bibliografía

¡Hola a todos nuestros fieles blogueros! Esta entrada va a ser muy breve. Únicamente era para comentaros que hemos añadido un apartado (en la esquina inferior derecha) donde iremos poniendo un listado de la bibliografía (en estilo APA) que estamos utilizando para el desarrollo de nuestro sistema de información.

Por la cantidad de documentos que llevamos ya, es amplia y variada: existen el libro principal que estamos siguiendo (el Pressman), otros sobre UML, EJB's, diseño de sistemas operativos, arquitectura de redes, computación distribuida, etc.

En fin, nos parece bastante útil y sobre todo que puede ayudar a muchos compañeros.

lunes, 3 de diciembre de 2007

Seguimiento del Documento de Análisis del Sistema

Buenos días. Vamos a comentar los resultados del último informe de seguimiento, ya que los hemos considerado interesantes para analizar. Ya comentaremos otro día en mayor profundidad la realización de informes de seguimiento pero hoy nos centraremos en los recursos (tiempo en minutos) utilizados para las tareas de análisis.



Si se observa el gráfico anterior, teniendo en cuenta que la zona sombrada eran los recursos estimados y la línea eran los recursos dedicados, se pueden sacar dos conclusiones principales:

1) La tarea de análisis se comenzó más tarde de lo planificado.

2) Se consumieron muchísimos más recursos de los estimados.

Todo esto, derivó en un retraso en la entrega del documento que nos fue imposible remediar. Es por esto, que hemos querido analizar las causas para que no se vuelva a repetir y compartirlas con todos vosotros para que no os suceda lo mismo que a nosotros (siempre parece que es imposible que ocurra hasta que ocurre).

El principal motivo por el que se comenzó tarde la tarea de análisis fue porque para la mayoría de apartados se necesitaba disponer de los requisitos de software definidos al principio del documento y la realización de estos requisitos dependía de la definición de requisitos de usuario que no habíamos completado correctamente en el anterior documento.

Además, en el momento que se comenzó el análisis, aún no estaban 100% definidos los requisitos de usuario del Estudio de Viabilidad del Sistema. Esto provocó que, al finalizar dichos requisitos, todos los apartados del análisis se vieron afectados, por lo que se produjo el ya mencionado aumento de recursos (tiempo) para este documento.

Esto ya nos dejó al límite para poder terminar análisis. Sin embargo, la última causa del retraso, fue un error en la estimación del tamaño del diseño de clases de análisis, lo que unido a que ya íbamos totalmente apurados, hizo que venciese el plazo de entrega antes de que pudiésemos unir y revisar todas las partes.

En conclusión, ante cualquier error en un documento hay que solucionarlo de inmediato, para que no afecte a documentos posteriores y siempre intentar llegar con tiempo de sobra al final para poder solucionar los imprevistos si alguien se apura en su parte (esto es más fácil de decir que de hacer pero siempre debe intentarse).

Hasta la próxima.

sábado, 1 de diciembre de 2007

IT Crowd

Mientras realizamos la interminable fase de diseño, para relajarnos un poco hemos pensado recomendaros una serie de humor sobre informáticos. Ya era de esperar que todavía no hubiera una serie de humor por y para los "freaks".

La verdad es que parodian bastante bien nuestra profesión porque aunque parezca mentira hay personajillos con un nivel de freakismo igual o superio que Roy y Moss. Sin embargo, su punto fuerte pero a la vez débil es que las bromas o gracias que hacen es para un público muy concreto: los informáticos, así que si pensáis recomendar esta serie algún compañero ajeno al mundo de la informática, no creo que triunféis...

Pues hasta aquí la entrada de hoy, a continuación os pasamos un par de fragmentos encontrados por YouTube sobre IT Crowd. Ahm!!!! Para aquellos que no les gusten las series en inglés o subtituladas en español, n esta semana o la que viene la van a poner en Canal +.