El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demo strado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados.

http://www.willydev.net/descargas/prev/TodoAgil.pdf

En este artículo presentamos un curso de ingeniería de software que combina de una manera balanceada y práctica: procesos, metodología y herramientas de apoyo al desarrollo de un producto de software. Hemos llamado nuestro enfoque “proceso instrumentado” para diferenciarlo de procesos como TSP en donde se definen las fases y los entregables del desarrollo, pero no la metodología que ha de ser usada durante las actividades ni las herramientas de soporte.

http://www.willydev.net/InsiteCreation/v1.0/descargas/willydev_instrumentado.pdf

http://www.willydev.net/InsiteCreation/v1.0/descargas/WillyDEV_Especializacion_MSF.pdf

Con estas instrucciones se pretende ayudar a los diseñadores de bibliotecas de clases a comprender las ventajas y las desventajas entre las distintas soluciones. Puede que haya situaciones en las que un buen diseño de bibliotecas requiera saltarse estas instrucciones de diseño. Estos casos no son lo habitual y es importante que una decisión de este tipo esté
adecuadamente justificada. En esta sección se proporcionan instrucciones de uso y de nomenclatura para los tipos de .NET Framework, así como instrucciones de implementación de modelos de diseño comunes.

http://www.willydev.net/descargas/GuiaDiseno.pdf

En 1946 se desarrolló el primer ordenador digital. En un principio, estas máquinas ejecutaban instrucciones consistentes en códigos numéricos que señalan a los circuitos de la máquina los estados correspondientes a cada operación. Esta expresión mediante códigos numéricos se llamó Lenguaje Máquina, interpretado por un secuenciador cableado o por un microprograma. Pero los códigos numéricos de las máquinas son engorrosos. Pronto los primeros usuarios de estos ordenadores descubrieron la ventaja de escribir sus programas mediante claves más fáciles de recordar que esos códigos numéricos; al final, todas esas claves juntas se traducían manualmente a Lenguaje Máquina. Estas claves constituyen los llamados lenguajes ensambladores, que se generalizaron en cuanto se dio el paso decisivo de hacer que las propias máquinas realizaran el proceso mecánico de la traducción. A este trabajo se le llama ensamblar el programa. Sigue leyendo este paper. http://tiny.cc/Compila

La versión corta del código resume las aspiraciones a un alto nivel de abstracción; las cláusulas que se incluyen en la versión completa proporcionan ejemplos y detalles acerca de cómo estas aspiraciones modifican nuestra manera de actuar como profesionales de la ingeniería de software. Sin las aspiraciones los detalles pueden convertirse en tediosos y legalistas; sin los detalles las aspiraciones pueden convertirse en altisonantes pero vacías; juntas, las aspiraciones y los detalles forman un código cohesivo. Los ingenieros de software deberán comprometerse a convertir el análisis, especificación, diseño, implementación, pruebas y mantenimiento de software en una profesión respetada y benéfica.

Sigue leyendo más de este documento....