[Las cosas que no interesan]

pageicon miércoles oct 03, 2007

Las Cosas por Leer

Durante mi entrada a este mundo de la ingeniería de software me he encontrado con cosas increíbles: la forma como se puede concebir un proyecto a un alto nivel, las técnicas para estimar su duración, el cálculo de puntos de función, las metodologías iterativas y la convivencia con el cambio, la asignación de recursos, el modelado del negocio, el análisis, el diseño, las pruebas todas las disciplinas de RUP, etc. Hace 6 meses ni me imaginaba todas las herramientas que existen para administrar un proyecto de desarrollo de software, no es que esté administrando un proyecto ahora, pero si que he tenido que preocuparme por estos aspectos.

Pero son tantos, tan diversos, hay tantas formas de ver un proyecto que resulta abrumadora la cantidad de materias en las que me encuentro ignorante; puedo mirar el proyecto desde el punto de vista de su desarrollo, es decir, las etapas que comprenden el modelado del negocio, la definición de requerimientos, el análisis y diseño, la implementación, las pruebas y el despliegue. Esta es la primera “vista” a la que me acerqué, es la que más conozco o al menos la que se me antoja menos ajena, de todas formas en la universidad se aborda cada uno de estos temas, no con gran profundidad, pero se hace y ya tenía idea de que se trata cada uno. Aún así me he llevado muchas sorpresas: la relevancia que tienen los casos de uso, como a través de ellos se puede conocer el tamaño de un sistema y como a través de ellos se puede hacer un seguimiento a todo el proceso de desarrollo; también he descubierto muchas cosas sobre el diseño, que se trata como todo de un proceso iterativo, que de un diagrama de clases se hace un esbozo inicial y a través de otros diagramas (especialmente el de secuencia) se pude probar ese diseño inicial para entrar en una etapa cíclica de refinamiento. Me he enterado de otras disciplinas sobre las que no tenía mucho conocimiento: las técnicas para modelar el negocio y la preparación de casos de prueba, no solo las he conocido, sino que he aprendido a reconocer su valor en el proceso.

La otra vista desde la que se puede mirar el proyecto es desde la administrativa, es decir, las disciplinas que soportan el proceso y que brindan las técnicas y herramientas para medirlo y controlarlo adecuadamente. Hay técnicas muy interesantes para crear un cronograma iterativo, basado en el proceso y no en el producto, es decir, hay que pensar el proyecto en términos de etapas y disciplinas, no de módulos y submódulos como estamos acostumbrados a hacerlo. El diseñar un cronograma de esta forma es lo que ha permitido estandarizar la forma de administrar proyectos de desarrollo de software, por que podemos comparar los procesos llevados para proyectos similares y empezar a obtener patrones y métricas. Una vez realizada la planificación del proyecto se pueden empezar a definir requerimientos, requerimientos que muy seguramente irán cambiando con el tiempo, a los cuales se les puede hacer seguimiento con casos de uso bien definidos y con las herramientas adecuadas que proporciona la disciplina del entorno (environment); todo esto ya está bien documentando, depurado con el paso del tiempo, con aplicación en miles de proyectos y adaptado a la tecnología de nuestra época.

Todo el interés que me ha generado mi nuevo quehacer me ha traído también una cantidad infinita de recursos: libros, páginas Web completas, artículos en línea, revistas, etc. Es obvio que nunca en mi vida voy a leer todo lo que quiero leer, que por más que me guste hacerlo, debo ser efectivo con las cosas que estudio, es decir, escoger lo mejor, lo más clásico o “lo más” en algún aspecto. No puedo leer cuanto libro consigo o me prestan, no puedo leer todos los artículos de la Web. Por eso hice una selección del material que más me recomendaron o el que más interesante me pareció por el autor o el contenido; es una gran cantidad de material, pero al menos es finita y creo yo, la puedo procesar en unos tres o cuatro meses, ojala tres para finalizar el año con la frente en alto. El material corresponde a las dos vistas de las que he hablado: el proceso de desarrollo y la parte administrativa, todo muy orientado RUP y sus mil formas de hacer lo mismo, pero es que creo que RUP es maravilloso por la claridad y la madurez de las cosas que propone. Claro, también puede llegar a ser un ladrillo.

El hecho de que el material seleccionado haya salido en su gran parte de lo recomendado por RUP, no quiere decir que no se pueda abortar de forma independiente a metodología. Aquí va pues, la tarea que tengo para los próximos tres meses:

Artículos
Entre ellos están todos los recomendados en el curso de “Gerencia de Proyectos” de Mario Zuluaga (http://www.geocities. com/marioztobon/gerenciap.htm), los otros los he encontrado uno a uno.

1. A Software Development Process for Small Projects (http://www.geocities. com/marioztobon/articles/s5096.pdf).
2. When Telepathy Won't Do: Requirements Engineering Key Practices.
3. Listening to the Customer’s Voice.
4. Estimación ISO 9000 (http://www.geocities. com/marioztobon/formatos/Estimacion_ISO_9000.doc).
5. Stop Promising Miracles.
6. Know Your Enemy: Software Risk Management.
7. Running Projects.
8. Configuration Management (http://www.geocities. com/marioztobon/articles/Configuration_Management_Notes.pdf).
9. Improving Quality through Software Inspections.
9. What Is Software Testing? And Why Is It so Hard? (http://www.geocities. com/marioztobon/articles/s1070.pdf).
10. Vee Chart (http://www.geocities. com/marioztobon/articles/Extracto_V_V.pdf).
11. Core Measures (http://www.geocities. com/marioztobon/articles/metricas.pdf).
12. Implementing Software Engineering in a Small Software Group.
13. Looking Back, Looking Ahead.
14. The New Methodology.
15. Continuous Integration.
16. Building a Fort: Lessons in Software Estimation.
17. Function Point Training Manual.
18. Structuring Use Cases with Goals.

Libros
1. Software Project Management in Practice.
2. Getting Things Done.
3. Desarrollo y Gestión de Proyectos Informáticos.
4. Peopleware: Productive Projects and Teams.
5. The Unified Modeling Language User Guide.
6. The Mythical Man-Month.
7. Object-Oriented Analysis and Design with Applications.
8. Head First Design Patterns.
9. The Rational Unified Process: An Introduction.
10. The Rational Unified Process Made Easy.
11. Patterns for Effective Use Cases.
12. Writing Effective Use Cases.
13. Software Requirements.
14. Head First Object-Oriented Analysis and Design.

Otros
1. Memorias de la Informática en Colombia.
2. Ingeniería de Software.
3. La Inteligencia Emocional.
4. The Art of Software Testing.
5. La esperanza no es un método.

Vaya, después de hacer esta lista veo tres cosas:
- Tendré que replantearme lo de 3-4 meses, por que no solo se trata de leer, hay que estudiar y poner en práctica lo aprendido.
- Me hace falta un buen libro sobre diseño de interfaz de usuario.
- ¿Por qué no puedo publicar URLs de geocities?.

Ya veremos como va resultando el camino.

Comentarios:

Muy buen artículo, no soy muy partidario de diagramas, casos de uso, etc, ya que los proyectos en los que trabajo son más bien pequeños. Pero si estoy de acuerdo en que hacer proyectos no es hacer obras de "arte", debe existir una metodología detras de ellos, sea esta cual sea.

PS: lo de geocities será el filtro anti-spam. Lo miro.

Un saludo.

Enviado por lasterra en octubre 03, 2007 a las 09:29 AM COT #

Hola Enrique.
Sí, esto no es solo arte, hay mucha técnica, metodología y lecciones aprendidas de hace ya varios años y es imperdonable seguir cometiendo los mismos errores solo por que no estudiamos.
Pues a mí últimamente me gustan mucho los diagramas UML, por que me han permitido experimentar fácilmente en papel cosas que de haberlas hecho durante la implementación terminarían en fracasos rotundos. Claro, no es nada fácil aprender a pensar de esta forma. También creo que hay demasiados diagramas y es otra habilidad necesaria saber cuando usar cuales.

Para proyectos pequeños es claro que no ha que exagerar en los artefactos que se generen o en las disciplinas a implementar, pero al menos el diagrama de clases es fundamental para realizar una buena implementación, a menos claro, que no sea algo realizado en un lenguaje orientado a objetos ;-). Enrique, ¿Usas algún diagrama especialmente? ¿El de clases?, o ¿Todo lo vas diseñando sobre la marcha?, solo curiosidad.

Un saludo y gracias por revisar lo de las URLs.

Enviado por azuluaga en octubre 03, 2007 a las 10:24 AM COT #

Bueno yo ademas de programador soy pintor y les puedo asegurar que detras de cualquier verdadera obra de arte hay tanto trabajo, estudio y talento como el que se requiere para hacer un proyecto de software grande, quiza la unica diferencia es que el arte es una creacion individual y el software en su mayoria es producto de un equipo de trabajo multidisiplinario.

No obstante a mi tambien me parece muy bueno el articulo.

Saludos

Enviado por Miguel en octubre 04, 2007 a las 11:24 AM COT #

Excelente comentario Miguel!
Un trabajo que se podría hacer bien interesante es una comparación entre la realización de una obra de arte y el diseño e implementación de un programa.
Como dices creo que ambos implican bastante conocimiento y trabajo, pero la creación de un programa tiene eso del arte que son los detalles infinitos, el que su creador nunca a dar por finalizada su "obra".
Seguro que debe suceder con cualquier disciplina que tenga que ver con la creación.

Saludos.

Enviado por azuluaga en octubre 04, 2007 a las 12:06 PM COT #

5444

Enviado por 190.81.63.254 en octubre 29, 2007 a las 07:05 PM COT #

Enviar un comentario:
  • Sintaxis HTML: Deshabilitado