Categoría: Ingeniería de software

Andanzas por la UNTreF

Durante este cuatrimestre estoy colaborando con DiegoF en el dictado de la materia de análisis y diseño perteneciente a la carrera de Ingeniería en Computación de la Universidad Nacional de Tres de Febrero. La materia pertenece al cuarto cuatrimestre de la carrera y en cierto modo sería equivalente a Análisis de la Información en Fiuba. Si bien el nombre formal de la materia es «Análisis y diseño estructurado», el contenido es bastante más amplio; la visión de Diego es que al finalizar la materia los alumnos cuenten con varias herramientas y tengan el criterio de para poder elegir cual utilizar en cada caso. El programa de la materia incluye temas bastante variados que van desde el análisis estructurado de Yourdon, el diseño de productos, hasta User Stories y Atributos de calidad, pasando por Casos de uso, UML,  e implementación de paquetes. La materia se dicta en clases semanales de 4 horas, donde por lo general damos 2 horas de clase de exposición y luego actividades de aplicación, como ejercicios o incluso juegos.

Sinceramente me parece que la materia está muy bien pensada y es por eso que no lo dudé cuando Diego me hizo la propuesta. Estamos intentando grabar el audio de las clases de exposición, hasta ahora solo hemos grabado 2 clases y según me cuenta Diego han quedado muy bien.

A medida que vaya avanzado el cuatrimestre iré contando por aquí las expericiencias que vayamos recogiendo.

Esto es todo por ahora, cambio y fuera.

Sobre la evolución de herramientas

Este es un post que tengo pendiente desde hace rato largo y está motivado por este link que me envió Nicolás Avellaneda http://codebetter.com/blogs/patricksmacchia/archive/2008/03/18/number-of-types-in-the-net-framework.aspx

Junto con el link, Nicolás preguntaba: "Mas tipos, métodos, interfaces, etc. ¿Nos brindan herramientas más simples?"

Esta pregunta me recuerda inevitablemente el excelente artículo de Fred Brooks, "No silver bullet", a la luz del cual podemos reformular la pregunta de Nicolás como: "¿ha logrado la plataforma .NET introducir un cambio en el orden de magnitud de la complejidad de la construcción del software?"

Definitivamente la respuesta a esto depende de contra que comparemos. Personalmente creo que si comparamos contra otras tecnologías actuales como Java, Ruby, Phyton y otras no tan recientes como VB6, Delphi, Smalltalk, no creo que que ni por asomo las cosas hayan cambiado en orden de magnitud, aunque sin duda muchas cosas se han simplificado.

Distinta puede que sea la cuestión si comparamos contra tecnologías más antiguas como COBOL y Pascal. De todas formas es preciso aclarar que mis opiniones están teñidas por el contexto en el cual trabajo: desarrollo de software de gestión.

Volviendo a la pregunta original ¿tenemos herramientas más simples? Creo que definitivamente si. Y en este sentido resulta interesante la estrategia planteada por Microsoft de querer unificar los distintos modelo de programación. Inicialmente con la aparición de la plataforma .NET y particularmente con ASP.NET Microsoft intentó unificar el modelo de programación Web y Windows, y podríamos decir que hasta cierto punto lo logró.
La reciente aparición de Silverligth también es un esfuerzo en ese sentido. No importa donde ni como vaya a correr la aplicación, no importa si es una interface web, smart cliente o RIA, no importa si es un web service o un componente remoto, no importa de si es lógica de negocio o de acceso a datos, la plataforma de desarrollo es siempre la misma: lenguaje C# e IDE Visual Studio. De esta forma se busca que un programador pueda hacer "todo" tipo de programación conociendo simplemente las herramientas mencionas C# y Visual Studio (al menos esta es la intención de Microsoft).

My 2 cent.

Nicoláz

Sobre el inicio de los proyectos

Si analizamos como surge un proyecto de desarrollo de software, nos encontraremos que la motivación principal es una necesidad de una organización. Puede que el resultado del proyecto represente una mejora directa al negocio o bien que permita soportar al negocio de una forma más «óptima».

Yendo un paso más allá nos encontraremos que previo al inicio del proyecto y antes que el mismo sea concebido como tal, debería hacerse un análisis para determinar si vale la pena o no hacer el proyecto.  Como desarrolladores muchas veces pasamos por alto este hecho ya que generalmente somos convocados cuando la decisión de hacer el proyecto ha sido tomada. El análisis de si debe o hacerse el proyecto suele conocerse como «caso de negocio» (Business case) y debería contemplar minimamente las siguientes cuestiones: descripción del proyecto, objetivos, alineamiento con la estrategia del negocio, impacto en la operaciones, costos, beneficios y riesgos.

Una vez presentado el caso de negocio y decidido que se avanzará con la ejecución del proyecto se procede a iniciar el mismo. Independientemente del tipo de proyecto y el proceso de desarrollo a utilizar, absolutamente todo proyecto debe comenzar con un documento de visión y alcance que deje en claro para todos los involucrados el porque del proyecto y a grandes rasgos cual es la funcionalidad que se espera del mismo. En algunos casos dependiendo de las características del proyecto es conveniente tener documentado en forma separada la visión y el alcance, pero independientemente de ello es necesario para poder comenzar con el proyecto que todos los involucrados tengan en claro los siguientes puntos:

  • Objetivos del proyecto
  • Beneficios para el negocio que traerá el proyecto
  • Quienes son los involucrados en el proyecto detallando al menos: sponsor, usuarios clave, experto de negocio y líder del proyecto
  • Relación del proyecto con otros proyectos
  • Alcance esperado de la solución a implementar
  • Plan de alto nivel con principales hitos y entregables

Toda esta información es lo que suele volcarse en el documento de visión y alcance. Adicionalmente dicho documento también contiene la lista de riesgos del proyecto.

continuará….

La programación como disciplina central del desarrollo del software (introducción)

Parte 1: La programación, la academia y la industria

Claramente si trazáramos un paralelismo entre el desarrollo de software y las construcción de edificios, bien podríamos decir que en cierto modo, el programador es al desarrollo de software lo que el albañil es a la construcción de edificios. Al mismo tiempo, resulta que el trabajo llevado a cabo por los programadores insume aproximadamente la mitad del esfuerzo total del desarrollo del software.

Si uno analiza la situación actual del mercado IT en Argentina rápida se encuentra con la escasez programadores, como uno de los principales problemas para el crecimiento de la industria.

Curiosamente, si uno mira la oferta académica actual de las universidad nacionales (no estoy al tanto de las universidad privadas, pero supongo que la situación debe ser similar), se encuentra con abundantes opciones de licenciaturas / ingenierías en sistemas, pero ninguna carrera enfocada en la formación de programadores. Si bien es cierto que todo licenciado / ingeniero en sistemas debería ser capaz de programar, para ser programador no basta con ser capaz de programar. Las universidades enseñan programación en la primera mitad de la carrera, tratándola más como una base necesaria para las materias del ciclo superior que como una disciplina en si misma.La falta de una carrera de programador hace que aquellos jóvenes con aspiraciones de ser programadores se vean obligados a estudiar una licenciatura/ingeniería que no los formará como programadores, provocando una deserción temprana en la carrera. Como consecuencia de todo esto, la academia no forma programadores, sino ingenieros/licenciados capaces de programar.

Por su parte la industria asume que la formación general de los programadores es responsabilidad de la academia y por ello en el mejor de los casos solo invierte en la especialización del programador en una tecnología particular.

Estas posiciones adoptadas por la industria y la academia posiblemente sean consecuencia de la subestimación de la tarea del programador y por una falta de conciencia de la importancia de la actividad.

Personalmente creo que resulta necesaria una revalorización (en la academia y la industria) de la programación como disciplina fundamental del desarrollo de software y es por ello que he decidido escribir una serie de artículos centrada en programación como actividad fundamental del desarrollo de software dejando en claro la diferencias entre ser capaz de programar y ser programador.

Tipos de excepciones

Independientemente de la tecnología de programación utilizada en toda aplicación es posible distinguir dos tipos de excepciones las de aplicación y las técnicas.
Las excepciones técnicas son producto de fallos en la infraestructura como ser falta de conectividad, caída de un servidor, etc.
Por su parte las excepciones de aplicación son producto de alguna acción incorrecta por parte del usuario y a grandes rasgos es posible clasificarlas en dos grupos: violaciones de formato (ingreso de un carácter en un campo numérico) y violaciones de reglas de reglas de negocio (alta de una entidad con un identificar repetido).
La distinción entre estos tipos de excepciones es necesaria ya que el comportamiento de la aplicación varia en base a estas.
Generalmente ante una excepción técnica la aplicación suele interrumpir la actividad del usuario mostrándole un mensaje del estilo «No es posible completar la operación requerida, por favor intente más tarde», sin hacer mayor distinción en el tipo particular de excepción.
Por su parte, ante excepciones de aplicación, el usuario suele recibir un mensaje más específico, indicándole el error que ha cometido y dándole la posibilidad de corregir el error cometido sin necesidad de volver a comenzar con la con la actividad que se encontraba desarrollando.
Otra diferencia entre estos tipos de excepciones radica en el loggueo de las misma. Las excepciones técnicas siempre se logguean, llegando incluso a generar notificaciones a los administradores del sistema, mientras que las excepciones de aplicación no suelen ser loggueadas (salvo por cuestiones de auditoría para detectar usos indebidos del sistema).
En el caso particular de .NET, las excepciones técnicas suelen ser subclases de SystemException, mientras que las excepciones de aplicación lo son de ApplicationException.