[Las cosas que no interesan]
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.
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.
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.
Posted at 01:13AM oct 03, 2007 by Carlos Alexander Zuluaga in General | Comentarios[5]


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 #