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)".

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.

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.

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

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.

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.

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.

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 +.

Análisis de posicionamiento en la web

Muy buenas, como podéis comprobar hemos superado la primera eliminación de blogs realizada por los profesores de la asignatura. El contenido de la entrada de hoy no expondrá ningún tema relacionado con la ingeniería del software, el objetivo es mostraros el estado del posicionamiento de nuestro blog en la web y poder comprobar si el esfuerzo de publicar información y conocimientos útiles para la ingeniería del software tiene su recompensa. Respecto a la herramienta que se ha utilizado ha sido Google Analytics, una herramienta muy completa, profesional y gratuita.

A continuación se presentarán los informes generados a partir del día 29 de octubre del 2007. El primero de ellos es muestra el gráfico de visitas por país o ubicación, se puede ver observar cómo los países que más visitas realizan son España y Méjico, gracias a las buenas relaciones que mantenemos con nuestros amigos mejicanos.

En el segundo informe se refleja la visión que tienen los usuarios frente a nuestro blog. Hay que destacar varias puntos:

1. El porcentaje de abandonos es alto y el tiempo de permanencia bajo, lo que implica que debemos seguir mejorando el blog para cambiar la tendencia de estos dos valores cruciales.
2. El aumento de visitas en las fechas de valoración de blogs.
3. Una bajada actual debido a que en esta semana no hemos publicado ninguna información.
   

Por último, el tercer informe muestra las estadísticas recogidas sobre las fuentes de acceso al blog, señalando como punto más importante que casi la mitad de los usuarios de nuestro blog acceden a él a través de motores de búsqueda. Este dato nos demuestra que la estrategia de posicionamiento y publicación que tenemos está dando resultados.

Y nada más en breve incluiremos nuevas entradas: entrevista a un jefe de proyecto, opiniones sobre las fases de análisis y diseño y... ¡Una nueva sección de humor!

Web Services

Buenas a todos nuestros seguidores. En la entrada de hoy, vamos a exponer nuestra opinión sobre los Web-Services (WS) por ser una tecnología de comunicación distribuida que está en auge e implantándose cada vez en más sistemas de información, y que además, hemos decidido utilizarla para diseñar una API de acceso remoto al sistema de marcadores sociales que se está desarrollando. Nos centraremos única y exclusivamente en la opinión que tenemos: analizar las ventajas qué nos proporcionan y las limitaciones qué nos imponen, dejando en un segundo plano la colección de protocolos que conforman este mecanismo de comunicación: SOAP, WSDL, HTTP, etc. En cuanto a las fuentes y referencias de información de web-services, son muchas y variadas, destacando principalmente las siguientes:

1. Conocimientos obtenidos de la asignatura de Servidores de Información.
2. Experiencia en el ámbito laboral.
3. Artículos técnicos y blogs sobre los WS: http://sistemas3.wordpress.com/2007/06/14/web-services/, http://www.w3.org/2002/ws/,http://en.wikipedia.org/wiki/Web_service...

En cuanto a las ventajas que hemos observado, hay que destacar por encima de todo la increíble transportabilidad e interoperabilidad que existe en su comunicación: permiten compartir, obtener y generar información independientemente del lenguaje de las aplicaciones, la plataforma o entorno de ejecución y las arquitecturas de los dispositivos implicados. Pero además de esta gran ventaja, tras haber trabajado en otros paradigmas de comunicación distribuida: RMI, CORBA, RPC, etc., los WS permiten unas ayudas que no hay que olvidar como son:

• Proceso de transporte realizado por HTTP, provocando que las políticas de proxys y firewall de una empresa tras la implantación de los WS no se vea modificada.
• Permiten procesos de autenticación y seguridad, de forma que se puedan restringir el uso a máquinas que cumplan ciertas características: tengan un determinado certificado, estar en un dominio concreto, etc.
• Facilidad de uso desde la perspectiva del programador. Al final, los WS se reducen exclusivamente en una definición de funciones desde el lado del servidor, sin importar los procesos de binding, autenticación y otros de más bajo nivel; y en el lado del cliente, al uso de una "libreria de funciones" importada desde el servidor, una vez más sin importar procesos de bajo nivel.

Todo esto aplicado en una situación real, se puede ver con el siguiente ejemplo. Se tenían dos sistemas de información: un gestor de alumnos, y una plataforma de e-learning. Ambos sistemas eran desarrollados por dos empresas diferentes, en diferentes lenguajes: el primero en Java y el segundo en PHP e implantados en el mismo organismos oficial. Lo que se pretendía era que el gestor de cursos ofreciese unos servicios de matriculación al gestor de alumnos. Se procedió al estudio de las alternativas a la solución, y la que mejor se acoplaba a las necesidades solicitadas eran los Web Services. Al final, la implementación de los Web Services para PHP mediante la librería Nu-SOAP resultó todo un éxito, tanto en el tiempo que se realizó como en el funcionamiento final.

Por último, como todo en esta vida siempre hay ventajas pero también desventajas, y los WS no iban a ser una excepción. Lo primero hay que señalar que todavía se trata de una tecnología que está en plena fase de crecimiento y por tanto, la poca documentación existente y las modificaciones en el estándar no serían extrañas con el consiguiente riesgo que conllevaría. Otra desventaja que hemos observado es la sobrecarga que puede sufrir el canal por el uso de XML en el transporte de mensajes, a diferencia de RMI y CORBA que usan estrategias de marshall y unmarshall en los datos para enviar, produciendo un notable mejora en la velocidad de la comunicación. Finalmente, y aunque lo hemos citado como una ventaja, que la comunicación se realice mediante HTTP puede ser un "arma de doble filo", es decir, estará expuesto a todos los riesgos que se dan en este protocolo: captura de la información por terceros al no ir cifrada (a menos que se utilice HTTPs), WS desarrollados para producir un efecto negativo en el cliente y que esquivarían a los firewall fácilmente, etc.

Pues esto ha sido todo, esperamos vernos en la siguiente entrada ya que esta semana hay la primera eliminación de blogs. ¡Un saludo!

Opiniones sobre: Estudio de Viabilidad del Sistema (2)

Buenas de nuevo, hoy continuaremos describiendo nuestras experiencias con el Estudio de Viabilidad de Sistema.

En concreto, vamos a abordar la parte de estudio de alternativas de solución. Este apartado tiene como objetivo dar una primera aproximación al hardware y software que se utilizará para implementar e implantar el proyecto. Además, de este estudio saldrá el coste en hardware y software de implantación que tendrá que reflejarse en el presupuesto reflejado en la oferta, aunque como ya dijimos en el post anterior, en nuestro trabajo no seguimos este orden por motivos de simulación de un proyecto real en los que no siempre se sigue el orden adecuado. Para esto, deberán analizarse todas las posibilidades existentes y evaluar el rendimiento que nos ofrecen en cada uno de los factores que se consideren determinantes.

Estamos muy satisfechos con el resultado de nuestro trabajo en esta parte del nuestro trabajo, ya que varios de los miembros del grupo tienen experiencia con proyectos reales y conocían varias posibilidades de solución tanto hardware como software que nos permitieron lograr un análisis de las alternativas de gran calidad. Es decir, los factores que nos llevaron al éxito en este apartado fueron: la experiencia de nuestros empleados junto a una buena búsqueda por Internet de diferentes ofertas de empresas.

Para explicar mejor qué son las alternativas hardware y software, pondremos un ejemplo de cómo las seleccionamos nosotros:

Para las alternativas hardware del sistema, tuvimos que seleccionar entre hospedaje interno o externo, es decir si nuestro cliente tendría su propio servidor o alojaría su aplicación en el servidor de otra empresa. Recopilamos varias ofertas de diferentes empresas, dando todas las características del servicio ofrecido y su coste. La valoración fue realizada en base a las referencias, el coste, la experiencia de los desarrolladores, la estabilidad, la actuación ante fallos y los tiempos de respuesta. Finalmente, escogimos un hospedaje interno contratado con la empresa DELL.

Para las alternativas software del sistema, estudiamos varias combinaciones de sistema operativo + servidor + gestor bases de datos + lenguaje de programación. Tras valorar todas las alternativas intentando maximizar las referencias, la experiencia de los desarrolladores con la tecnología, la estabilidad, el soporte y minimizar el coste, Linux + Orión + PostgreSQL + Java fue la solución escogida.

Esperamos una vez más que este post pueda resultar de ayuda a nuestros lectores y que hayamos sido capaces de transmitir, tanto la importancia que tiene el estudio de alternativas para el desarrollo del proyecto (de aquí saldrá el presupuesto entregado al cliente) como las bases para realizarlo correctamente. Si os habéis quedado con alguna duda o queréis realizar alguna aclaración, no dudéis en dejar vuestros comentarios y os contestaremos encantados.

Un saludo.

Opiniones sobre: Estudio de Viabilidad del Sistema (1)

Buenas a todos nuestros seguidores. Como viene siendo habitual en esta entrada explicaremos nuestra experiencia que hemos adquirido después de desarrollar el documento de Estudio de Viabilidad del Sistema o EVS, que forma parte de la metodología que estamos siguiendo: Métrica 3. Este documento trata de dar un primer paso en la adquisición de requisitos y plantear qué solución se seguirá entre todas las alternativas posibles.

Puede resultar extraño el dar alternativas de solución antes de realizar la parte de análisis, pero lo cierto es que antes de entrar de lleno en la parte de análisis, normalmente habrá que dar un presupuesto al cliente y este documento busca una primera aproximación al coste del proyecto. Lo normal sería realizarlo al inicio del proyecto, antes de la oferta. Sin embargo, nuestro profesor nos indicó que lo primero que entregamos es la oferta porque así ocurre en muchos casos reales, en los que primero se presenta la oferta rápidamente y sin tiempo a nada más y luego se ve cómo justificar lo que se puso en la oferta.

Por lo tanto, diferenciaremos dos partes claras: la primera es la identificación requisitos para el software y la segunda el estudio de las alternativas a la solución. En este post, solamente expondremos nuestra experiencia en la parte de identificación de requisitos, para no realizar un post demasiado extenso. Otro día comentaremos el estudio de alternativas de solución.

En el inicio del proceso de captación de requisitos software hemos aprendido lo difícil que puede llegar a ser la identificación de los primeros requisitos. Esto se debe primero a que no estamos en una situación real y no se dispone de un cliente al cual se le puedan realizar preguntas; y después, es difícil responder a la siguiente pregunta: ¿qué problema quiere el cliente resolver? ¿que restricciones impone?

Luego la pregunta del millón es: ¿qué hemos hecho para solucionar este problema? Para enfrentarnos a él, nos hemos apoyado en dos puntos: la experiencia que disponemos en este tipo de documentos pues ya lo hemos realizado en varias asignaturas a lo largo de la carrera y la verdad es que se nota respecto a otros documentos de los cuales no disponíamos ninguna experiencia previa, como por ejemplo gestión de calidad y de configuración. Y el segundo punto, el estudio de la competencia, en nuestro caso como estamos desarrollando un sistema de marcadores sociales, qué mejor que fijarse de las capacidades y restricciones que ofrece del.icio.us para realizar un trabajo de ingeniería inversa y obtener los requisitos para nuestro proyecto.

En este punto, cometimos un error en nuestro trabajo, ya que no incluimos de forma explicita este estudio de la competencia en el documento debido a que la metodología no lo indicaba. Por ello, para que no caigáis en el mismo error, conviene que recordemos que la metodología que se sigue a lo largo del proyecto da una indicación de los pasos a seguir, pero no debe seguirse al pie de la letra. Si hay algo interesante que poner en un documento, aunque no lo indique la metodología, debe incluirse en el trabajo y, al revés, si algo de lo indicado por la metodología no tiene sentido en un proyecto en concreto, no debe realizarse.

En resumen, la conclusión principal que hemos obtenido ha sido la importancia que tiene la detección de todas las fuentes de requisitos, tanto de los usuarios participantes que puedan aportar requisitos como de otras fuentes (trabajos similares, competencia, etc.). Además, será importante poder extraer toda la información de dichas fuentes. Para esto, lograr una relación perfectamente coordinada y totalmente colaborativa por ambas partes con los usuarios participantes y formalizar en la medida de lo posible el resto de fuentes, resultará vital para obtener nuestro objetivo, es decir, un conjunto de requisitos iniciales robustos, con calidad y que reduzcan (¡no eliminen!, ya que esto es imposible) futuras modificaciones debido a las ambigüedades y vacíos que caracterizan este proceso en la ingeniería del software. Para terminar este punto, nos ha parecido curiosa la cita de Pressman sobre este tipo de problemas: "Quién hace una pregunta es un tonto por cinco minutos; quién no la hace es tonto para siempre." Proverbio chino.

Pues esto ha sido todo compañeros, en los próximos días publicaremos más entrevistas, más comentarios, más opiniones, entradas cómicas y... ¡muchas más cosas!. Como vereis, intentamos dedicar cierto tiempo al blog a pesar del trabajo que tenemos en la universidad porque nos sentimos a gusto con esta idea y pensamos que es enriquecedora tanto para vosotros como para nosotros. Un saludo y hasta las próximas entradas.

Concepto de Líneas Base

Saludos de nuevo. El otro día, en la corrección que hizo el profesor a nuestro documento del plan de gestión de configuración, resaltó que le había gustado que mencionásemos el concepto de "líneas base". Sin embargo, cuando nos pidió que explicásemos lo que eran nos quedamos un poco atascados, ya que es un concepto algo difícil de explicar.

Por eso, siguiendo en la línea de crear post didácticos, decidimos crear un post con la explicación de qué son las líneas base en ingeniería del software para que podáis incluirlo en vuestros futuros proyectos, ya que una vez comprendido correctamente, no es nada complejo.

Las líneas base o más conocidas por su termino en inglés, "baselines", son "una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios” según la traducción del estándar IEEE 610.12-1990 realizada en el libro de Pressman que ya recomendamos.

Nuestra explicación más informal pero esperamos que más comprensible también, es la siguiente:

Cuando, en un proceso de desarrollo de software se realiza un producto (un documento, código fuente u otros), este producto pasa una etapa de producción en la que se puede modificar sin impedimentos. Sin embargo, una vez terminado este producto, tendrá una revisión formal y se aprobará por el equipo de calidad y, en caso de que así se decida, por el cliente. Una vez que el producto ha sido aprobado, ya no podrá ser modificado de modo informal, sino que deberá seguirse un estricto control de cambios realizados sobre dicho producto para controlar correctamente su evolución.

Por lo tanto, una línea base se define como un producto que acaba de ser aprobado y que define la “base” de ese producto que para ser modificado deberá pasar por un protocolo de control de cambios. También puede verse como un punto de referencia en la configuración de un proyecto que marca un estado estable en algún producto del proyecto.

El uso de las líneas base en un proyecto vendrá dado por la definición de las diferentes líneas base que se realizarán a lo largo del proyecto (generalmente requisitos de usuario, requisitos software, diseño, código fuente, planes o procedimientos, pruebas, funcionamiento) para controlar cuando se aprueban los distintos productos y asegurar que se realiza el correspondiente control de cambios que ayudará a mantener la coherencia y calidad de todo el proyecto software.

Otras fuentes para consultar:
"Ingeniería del Software. Un enfoque práctico"
Baselines en Wikipedia

PD: Se agradecería cualquier tipo de comentario que ayude a completar la definición de líneas base o a corregir cualquier fallo que se pueda encontrar en este post.

Recomendación de Bibliografía

Buenas. Desde nuestro equipo creemos que ha llegado la hora de un pequeño cambio de mentalidad respecto al blog. Vamos a seguir dando nuestras impresiones sobre nuestro proyecto, pero también queremos hacer entradas que sean una verdadera ayuda a todos aquellos que estén iniciándose en la ingeniería del software.

Para ello, vamos a comenzar por una recomendación para los que no tengan experiencia a la hora de llevar un proyecto de desarrollo de software. El libro "Ingeniería del Software. Un enfoque práctico" de Roger S. Pressman.

Este libro nos está ayudando a solventar todos los problemas que vamos teniendo a la hora de realizar los documentos. En la entrada anterior, comentamos la dificultad de encontrar métricas o riesgos para un proyecto sin haber realizado ninguno aún. Para solucionarlo acudimos al libro recomendado y encontramos varias métricas de calidad para incluir en nuestro proyecto y varios ejemplos en los que basarnos para ir sacando más riesgos que los que se nos habían ocurrido.

Por lo tanto, hasta ahora, nos ha dado grandes ideas para mejorar la calidad de nuestro trabajo y pensamos seguir consultándolo durante todo el proyecto.

Esperamos que a todos aquellos que no hayáis oído hablar de este libro y decidáis echarle un vistazo, os sirva de ayuda en vuestros proyectos.

Si es así, seguid consultando el blog, ya que seguiremos haciendo recomendaciones, consejos, entrevistas a profesionales y ofreciendo toda la información y ayuda que esté en nuestra mano.

Un saludo.

PD. Si a alguien no le convence el libro o necesita más ayuda, como bien dice nuestro profesor Ricardo Colomo Palacios, "Google o F1".

Opiniones sobre: Gestión de Configuración y Calidad

Buenos días. Como ya prometimos hace unos días, ha llegado el momento de dar nuestra visión acerca de los documentos de gestión de la configuración y gestión de la calidad.

Hemos juntado esta entrada porque consideramos que el objetivo de ambos documentos es similar, ya que pretenden maximizar la calidad de todo el proyecto.

Se diferencian en que el documento de gestión de la configuración pretende dar unas normas generales para la gestión de los productos que se generarán y los cambios que se produzcan en estos, mientras que la gestión de calidad trata de todos aquellos aspectos necesarios para que el cliente quede 100% satisfecho con nuestro trabajo.

Esta ha sido nuestra primera experiencia con estos documentos. Hasta ahora, toda esta parte de un proyecto la realizábamos de un modo completamente informal, sin dejar las cosas por escrito y basándonos únicamente en nuestros presentimientos, a la hora de planificar y evaluar nuestros trabajos.

Este tipo de planificación, aunque en algunos caso salió bien, en otros tuvimos grandes pérdidas de tiempo en solucionar las inconsistencias que inevitablemente ocurrían, teniendo graves consecuencias.

Por lo tanto, consideramos que, aunque pueden resultar algo tediosos el tener que formalizar todo metódicamente, son realmente útiles a la hora de realizar un proyecto complejo.

La mejor característica que vemos en estos documentos es que son muy poco dependientes del proyecto actual. Ha medida que íbamos redactando los diferentes apartados nos dimos cuenta de que realmente, se podría realizar un documento de gestión de la configuración y de la calidad para todos los proyectos de la empresa, solamente teniendo que realizar algunas partes que dependen de los proyectos, como por ejemplo el análisis de riesgos.

En cuanto a las diferencias a la hora de realizarlos, definir la configuración es muy metódico, dando todas las normas que deben seguirse al realizar cada parte del proyecto. Definir el plan de aseguramiento de calidad es igual de metódico pero más difícil, ya que en este caso hay que listar todos los posibles riesgos que nos pueden acontecer en un proyecto, y no es sencillo conocerlos. También nos resulto difícil dar métricas.

Como conclusión, ambos documentos nos han parecido muy importantes, pero consideramos más didáctico el de calidad, ya que hasta ahora sabíamos que era uno de los objetivos que tiene que tener presente todo ingeniero del software, pero no la forma de conseguirla. Ahora hemos ampliado nuestros conocimientos para la realización de un plan de aseguramiento de calidad que nos permita realizar mejores proyectos y esperamos aprovecharlo en todos los proyectos que afrontemos en un futuro.

Entrevista a Jorge Becerrill - MSN

Ya estamos de nuevo por aquí. Sentimos que ya empieza lo bueno: el análisis y el diseño, jejeje. Pero antes de ponernos a ello es necesario definir el Plan de Gestión de Configuración y el Plan de Aseguramiento de Calidad.

Como habéis podido observar , nuestra idea es compartir y publicar ideas o conocimientos sobre la ingeniería del software, y como ocurrió en anteriores entradas, volvemos a contar con la ayuda de todo un profesional en la ingeniería del software: D. Jorge Becerril.

Al igual que ocurrió con Javier Delicado, le hemos realizado una entrevista que sin más dilación, presentamos a continuación (¡qué pareado más bonito!):

¿Qué significa la calidad en el software para usted?

Para mi calidad significa entregar un producto fuera errores y bugs y cumplir con las expectativas del cliente siendo estas reflejadas en el documento de requerimientos esto es, debe cumplir con el diseño, con las funcionalidades, con las reglas del negocio etc.

¿Qué normas de calidad usa usted en su trabajo: un sistema de calidad definido por la propia empresa o un estándar de calidad como por ejemplo IEEE 730 -2002 o ISO 9000?

Utilizamos un sistema definido por la empresa.

¿El cliente comprende que asegurando la calidad, la responsabilidad del ingeniero informático es menor o nula o limitada?

El ingeniero es responsable total de la calidad claro! en base a los requerimientos, pero si te refieres a que después de entregado el producto la responsabilidad disminuye, esta es menor, para esto debe existir un periodo de garantía, es imposible saber que el software esta perfecto sino esta implementado y probado por los usuarios y mas allá debe pasar un periodo de tiempo para determinar la estabilidad del software.

La mayoría de veces el cliente exige productos en poco tiempo, ¿suele flexibilizar los plazos de entrega a cambio de software con mayor calidad? ¿o prefiere cantidad antes que calidad?

Definitivamente la calidad no debe ser una condicionante de entrega sino que debe ser implícita, alguna vez un jefe comentaba "Le diremos al cliente que podemos entregar el software en x tiempo y con pruebas en y tiempo" se me hizo absurdo, si bien el trabajo de pruebas tiene que estar contemplado en tu costo, suena inverosímil siquiera mencionarle al cliente eso. También me viene a la mente un comentario que vi en Internet porque Microsoft si cobra las licencias por que no otorga certificados de garantía como cuando compras una estufa o un carro, y suena coherente. Definitivamente en tu planificación debes contemplar las pruebas pensando en que entregaras el software con la mayor calidad posible.

Pues ahí está la opinión de un experto. Un saludo y hasta la próxima: "Opiniones sobre gestión de configuración y calidad".

Estrategias de publicación del blog

Buenas a todos nuestros fieles seguidores de la ingeniería del software, después de una semana cargada de trabajo debido a la realización del Plan de Configuración y Plan de Aseguramiento de Calidad, es hora de dedicar un poquito de tiempo al blog. Sobre la opinión de estas dos interfaces que define métrica, pensamos que es mejor escribir una entrada conjunta al terminar la referente a la calidad, así para el sábado comentaremos estos dos documentos que hemos hecho por primera vez en la carrera.


Ahora la pregunta es trivial, ¿por qué escribimos esta entrada? Lo que queremos contar son las estrategias de publicación por la Web de nuestro blog y los resultados que hemos obtenido. Nuestro objetivo (además de ganar el premio) es compartir los conocimientos que vayamos aprendiendo y que puedan ser útiles a estudiantes o interesados en la ingeniería del software, por eso lo primero que hicimos fue dar de alta nuestra página en los principales buscadores de Internet: Google y Yahoo!. Después, tener en cuenta durante la creación del blog de qué palabras hay que resaltar (incluirla en la url, título de la ventana, descripción inicial, encabezado principal, etc.) y como se puede observar estas palabras han sido "ingeniería del software", de tal forma que nuestro blog tenga un alto posicionamiento en los buscadores por dichas palabras. También es importante señalar la gestión de los enlaces que se ha realizado, por ejemplo como referencias a nuestro blog son el wiki de "Ingeniería del software" de la Wikipedia y los foros de informática del El PAIS; como enlaces salientes, se ha puesto páginas o blogs que hablen sobre la IS y con un PageRank elevado.

En cuanto a los resultados que hemos obtenido en este corto periodo de tiempo de vida del blog han sido la indexación del blog en los buscadores anteriormente citados y lo más importante: unos compañeros de IS de la Universidad Autónoma de Sinaloa de México, representados por su jefe de proyecto, se han puesto en contacto con nosotros para poder compartir conocimientos.

Por último, también hay que señalar que nos hemos puesto en contacto con D. Jorge Luis Becerrill Ramírez, creador del mejor blog sobre la Ingeniería del Software en castellano, para intercambiar puntos de vista sobre la ingeniería del software, publicar comentarios, etc. y por su parte está totalmente de acuerdo.

Y nada más, parece que esto va saliendo adelante y es un motivo más para no dejar de escribir y publicar conocimientos con el mayor esfuerzo y entusiamos posible. Un saludo a todos.

Opiniones sobre: Oferta

Buenas. Tras un pequeño "descanso" por el puente volvemos al blog a contar nuestra experiencia con el documento de ofertación de servicios.

El objetivo de este documento es convencer al cliente de que realizar el proyecto ofertado es fundamental para sus intereses empresariales y que nuestra empresa es la opción más adecuada para llevarlo a cabo.
Esto ha marcado todo nuestro trabajo en el documento, ya que hemos intentado poner nuestro mayor esfuerzo en encontrar las palabras y expresiones más adecuadas para lograr nuestro fin. Destacamos esto porque consideramos que uno de los puntos más complejos de la realización de la oferta ha sido el intentar "vender el producto" al cliente sin dejar de parecer una empresa seria y organizada.

Otro punto que también creemos importante resaltar, es el apartado de planificación del trabajo. Consideramos este apartado muy importante, ya que le damos al cliente una serie de plazos para ir completando partes del trabajo y, en fases posteriores del proyecto, el cliente irá evaluando nuestro rendimiento comparando el progreso actual con dicha planificación.

Además, nos ha parecido una tarea compleja, puesto que decidir cómo dividir el trabajo e intentar dar una aproximación al tiempo estimado a cada fase, nos ha resultado difícil de afrontar, al ser la primera vez que nos enfrentábamos a la organización de un proyecto. El factor más importante a la hora de realizar este apartado, del cuál carecíamos, es la experiencia en proyectos anteriores.

Un problema similar a lo que acabamos de contar, es a lo que nos hemos enfrentado a la hora de realizar el documento de cálculo de costes. Al inicio del proyecto sin saber todas las necesidades exactas no sabíamos exactamente que costes poner. Al final decidimos llevar el presupuesto a la alza para asegurarnos de que no hay apuros económicos.

Para finalizar, también queremos añadir un poco de autocrítica. En este sentido, quizás deberíamos haber dedicado un poco más de tiempo a dar un formato uniforme al documento, ya que eso es tan importante como su contenido. Esto es así, especialmente en los documentos destinados al cliente. Infravaloramos el tiempo que teníamos que dedicar a dar formato a todo el documento y al final casi no nos dió tiempo de terminarlo correctamente.

Entrevista a un jefe de proyectos profesional

¡Hola a todos! A continuación os pasamos la entrevista que hicimos a Javier Delicado, experto en sistemas multimedia, consultor y jefe de proyectos en GMV-SGI. Respecto al proyecto ya estamos finalizando la oferta, con ganas de realizar la primera entrevista con el cliente y ver qué cosas le gusta y cuáles no. También hemos empezado con el documento de gestión de configuración: ver qué dice métrica al respecto, ejemplos de documentos, googlear un poco, etc. Bueno como lo prometido es deuda, os pasamos la pequeña entrevista que hicimos:

¿Cuál es la importancia de realizar una buena oferta?
De la oferta depende captar al cliente o el proyecto en sí. Con una buena oferta te llevas el trabajo, sin una buena oferta no hay trabajo que hacer. Es mejor que la oferta sea buena y el trabajo mediocre a tener una mala oferta.

¿Qué es lo que consideras más importante de una oferta?
Lo más importante para mí es que sea estructurada, comprensible por el lego. Si se hace una oferta de alto lenguaje técnico es probable que no la entienda nadie. Presentar una oferta concreta, estructurada, con índice, ilustrada y con esquemas... en definitiva "comprensible".

¿En qué momento hay que tomar una estrategia para "atacar" al cliente?
Cuando intenta hacerte trabajar más de lo acordado.

¿En qué momento hay que tomar una estrategia para "ceder" al cliente?
Típicamente cuando se comete algún error. Hay que compensar los errores propios con cesiones a lo ajeno.

¿Qué situaciones curiosas te ha pasado durante ofertas al cliente?
Para que veas lo impuntuales y lo poco formales que pueden llegar a ser lo clientes, quedamos a las 10:00, llegamos a esa hora y el cliente apareció (había bajado a desayunar) a las 11:15. Posteriormente nos dijo literalmente que "habíamos llegado con
demasiada antelación".

Blog de Javier Delicado

Explicación del.icio.us (social bookmarking)

Ya hemos comenzado a preparar el documento de oferta de servicios de nuestro proyecto. Todavía no hemos expuesto el tema de nuestro proyecto. Consiste en un sistema de marcadores sociales basándonos en del.icio.us.

Para los que no conozcan esta página, hemos encontrado un vídeo en el blog de delicious que se llama "how to explain delicious to your parents". Este vídeo, realizado por Common Craft, nos explica en qué consisten los marcadores sociales (y en concreto la solución ofrecida por delicious) de una forma sencilla, visual y entretenida. La única pega es que está en inglés, aunque se entiende bastante bien.



Esperamos que os haya gustado y ayudado a comprender de qué va nuestro proyecto.

Hasta la próxima.

Nueva interfaz

Pretendiendo tener una interfaz de usuario más usable y sobre todo acorde con el estilo Web 2.0 que se tiende en la actualidad, hemos añadido nuevos elementos en la interfaz (la mayoría de ellos con implementados mediante AJAX).

El primero y quizá el más vistoso es la inclusión de un mecanismo de previsualización de enlaces y elementos multimedia llamado SnapShot, el cual abrirá una pequeña ventana emergente donde se muestra o bien la página principal de la página a la que se enlaza o su feed.

El segundo ha sido un gestor de titulares de noticias. Las fuentes de información que hemos elegido, lógicamente relacionadas con la ingeniería del software como con la informática en general, han sido: ingenieria del software, meneame.net y barrapunto.com; y por otro lado, noticias generales en google news.

Por último otras mejoras menos importantes han sido un listado de los links que por ahora creemos más interesantes (aunque se irán actualizando conforme vayamos encontrados páginas interesantes para el desarrollo del proyecto) y añadir un par de imágenes para tener una interfaz un poco más visual: una imagen que se elegido para "datos personales", un logo de blogger y otro de SnapShot.

Bueno esperamos que os guste y para cualquier sugerencia no dudéis en comentárnoslo.

P.D. En un par de días publicaremos una entrada referente a nuestra primera toma de contacto con el "Documento de Ofertación de Servicios" y además, una opinión de un jefe de proyecto de una consultora software española con bastante prestigio en el mercado internacional.

La primera entrada...

¡Buenas a todos! Somos un grupo de alumnos de Ingeniería del Software III, nuestros nombres son: Álvaro, Pablo, Eva M., Jose Carlos, J. Ignacio, Israel y Javier M. y... ¡Queda inaugurado el blog del grupo 3 del turno de tarde!

La idea del espacio pensamos que es muy interesante pues fomenta la participación en equipo, puede ayudar a otros grupos a enfocar posibles problemas que ya se nos hayan planteado y entre todos buscar las mejores soluciones. En cuanto a los objetivos que nos planteamos son varios, el primero y quizá el más importante es trasmitir nuestros conocimientos no sólo a los compañeros de universidad sino a toda persona interesada en la Ingeniería del Software; y el segundo es hacer más ameno el trabajo entre todos, pudiendo opinar cada uno sobre sus experiencias.

Para finalizar mucha suerte a todos (pues la vamos a necesitar...), esperamos que nos escribáis tanto entradas como comentarios y para cualquier duda o sugerencia, ¡aquí estamos!