Nicolas Bortolotti

Para este artículo me propuse analizar un segmento muy pequeño de las métricas que podemos obtener en el escenario de la ingeniería de software. Para este objetivo tenemos que tener claro que la medición es un elemento clave en cualquier proceso de ingeniería, las medidas se emplean para comprender mejor los atributos de los modelos que se elaboran y con esto se puede evaluar la calidad de los productos. Hay una discusión de varios autores sobre las medidas directas de varias ramas de la ingeniería en contraste con las medidas indirectas de la ingeniería de Software, para este punto voy a citar a Fenton: "La medición es el proceso mediante el cual se asignan números o símbolos a los atributos de entidades reales para definirlas de acuerdo con reglas claramente establecidas… En las ciencias físicas, la medicina y, más recientemente, las ciencias sociales, ahora podemos medir atributos que se consideraban imposibles de medir…Por supuesto, estas mediciones no tienen el mismo refinam

En este artículo voy a analizar un material que me gustó y me hizo reflexionar sobre el concepto de arquitecto, cualidades y habilidades necesarias sobre el rol. Para comenzar voy a citar el material sobre el cual quiero reflexionar y de paso les recomiendo la lectura en su totalidad: http://msdn.microsoft.com/en-us/arcjournal/cc505974.aspx Autor: Joseph Hofstader "En proyectos de software, el título Arquitecto es a menudo definido de forma ambigua y el valor que brindan los arquitectos no se mide con facilidad" Este frase resume la actualidad sufrida en los actuales proyectos de ingenieria de software, incluso se torna muy complejo para las organizaciones encontrar el valor agregado por el concepto de arquitecto. La idea es encontrar como objetivo general el valor que los buenos arquitectos aportan a los procesos de desarrollo de software. ¿Les parece un buen objetivo? Algo de lo que debemos partir para esta discusión es una definición de un buen arquitecto, para este objeti

En este articulo me pareció interesante repasar algunos principios de diseño desde la óptica de componentes, particularmente que son para mi punto de vista son "no negociables" en la ingenieria de software. Hay cuatro principios básicos de diseño aplicables al diseño al nivel de componentes y se han adoptado ampliamente cuando se aplica ingenieria de software orientada a objetos. La idea es lograr diseños que sean más sensibles al cambio y reducir la propagación de efectos secundarios cuando ocurren cambios. El objetivo del artículo es cubrir uno de los principios nombrados, "el principio abierto-cerrado (PAC)". ¿Qué dice este principio? "El componente de un módulo debe estar abierto para la extensión, pero cerrado para modificación" Para expresarlo de manera simple, el diseñador debe especificar el componente de manera que permita extenderlo (dentro del dominio funcional que atiende) sin necesidad de modificaciones internas al propio componente (al nivel