lunes, agosto 29, 2005

Le interesan a todos los estándares y la compatibilidad?

Developer publica un artículo sobre el test de conformidad Acid2, del Web Standards Project:

While it would seem that getting your browser to display the grinning face is simple, getting it to pass the Acid2 test is anything but. Currently there are 90 recommendations within the W3C, ranging from Cascading Style Sheets 2 (CSS 2) and HTML 4.01 to XML-binary Optimized Packaging.

WaSP's test doesn't try to incorporate all 90 recommendations, just the ones the group believes should be in all browsers based on Web developer input. It looks for basic support of HTML 4, CSS 1, data URLs and Portable Network Graphics (PNG), as well as particular implementations from these and other specifications.

The goal of the test is to get browsers to implement the Web standards tested in a consistent fashion, so what the Web surfers see using IE is the same as what another views in Safari, for example.

Lo probé con Mozilla Firefox 1.06 y con IE 6.02. El resultado es frustrante. IE 7.0 no lo soportará, según señala el artículo, y, en fin, solo tres browsers lo consiguen: Safari, iCab, y Konqueror.

UML no es OOD: cómo se relacionan

Un artículo de Craig Larman explica con algún detalle por qué UML no es igual a OOD, y por qué su uso no garantiza un diseño orientado a objetos.

viernes, agosto 26, 2005

MDA en la empresa: Visto desde múltiples perspectivas

Mikko Kontio, finlandés, presenta un breve documento en IBM Developer Works sobre las conveniencias de una arquitectura dirigida por modelo (MDA). Tanto desde el punto de vista de la conducción de los negocios, como desde el punto de vista de los diversos actores del area de TI. En pocas palabras, da un buen conjunto de argumentos en favor del estándar.

Para directivos:
MDA allows you to get more work done with the same people, or to do the same amount of work with less people. The time to completion on new projects will diminish radically, as will the time to make changes on existing systems.
La principal objeción:
In terms of cost, management will need to consider more than the price of tools. The biggest cost will be education, because not everyone in the organization will be familiar with MDA. Others may need time to become comfortable with the new approach. Therefore, the cost of the transition must be measured in time as well as money, but the end benefits should add up favorably.
Para analistas y diseñadores:

Analysts capture business requirements into a formal model. Because the work of capturing requirements is people-driven, most of it is the same regardless of approach. In MDA the formal model is Unified Modeling Language (UML), so your analysts will need to have a working knowledge of UML to implement MDA.

For the most part, the designer's job isn't affected by the transition to MDA. Designers turn analyst's models into more evolved ones, encompassing classes, state diagrams, detailed method actions, and so on. Because the designer's models are used to generate code, they must be detailed and precise. If your organization's UML tool uses executable UML, the designer will be able to more easily demonstrate the behavior of the model to customers.

Para arquitectos:
Company architects will likely be excited by your proposal to transition to MDA. MDA makes it much easier for architects to ensure that a system is implemented the way they designed it, from start to finish. As the system evolves, it will be easy to add new technologies, re-use existing code, or plug-in third-party modules. Performance tuning will be a snap using existing mappings, and documentation will always be up to date. As a result of these factors the overall quality of the system will improve, and fine-tuning it will be easier than ever. Most architects like to design and specify things before they are implemented, so for them MDA is a welcome change.
En todo caso, no suscribiría ciento por ciento la posibilidad de que la documentación esté siempre actualizada. No conozco (quienquiera puede desmentirme) herramientas del tipo MDA que puedan mantener como una colección integrada toda la documentación asociada. Por eso es interesante el concepto de Software Factory de Jack Greenfield, si el caso fuera que SF puede lograr esta integración.

Para programadores:
Every programmer knows how stupid it is to write the Customer class and its functions over and over. MDA cuts out much of that redundant work so that programmers can focus on more productive tasks like writing mappings to different platforms and fine-tuning existing mappings for specific reasons. Programmers put their platform expertise to better use this way, and they also get to concentrate on tough coding jobs that even the best MDA tools can't handle. With all the busy work cut out, programming can become more fun and also more challenging: programmers need to know their tools and languages well in order to work efficiently in an MDA environment.
Para testeadores:
Testing and maintaining are the grunt work of the development cycle, and MDA cuts out much of the worst of both. With the right tools, testers can generate test scripts directly from a system's UML model. This obviates the necessity of writing endless nearly identical test scripts and code fragments, allowing testers to focus on more crucial tasks.
Para mantenedores:
When not hunting down missing documentation, maintainers can usually be found frowning over out-of-date, poorly written documents that fail to yield the exact information they require. Not so with MDA, where the model is always current and applicable to solving real problems. MDA documentation is built in, which cuts down significantly on both frustration and high maintenance costs.
Agregaría que no sólo la documentación está integrada -aquí entendida en el sentido estricto del diseño del modelo-, sino que la inserción de cambios es simple, mucho más que la que se pueda pensar basado en un sistema no dirigido por modelo, dado que las partes están intrínsecamente integradas y articuladas, y un cambio se propaga en forma automática, reduciendo el alcance del problema a seguir la ruta del impacto, verificando conflictos que se pueden localizar en todos los casos, y a planificar las transformaciones que se deban implementar al ejecutar los cambios. (Hablando en términos generales; siempre puede haber excepciones).

Finalmente, adhiero a las recomendaciones de Mikko sobre la transición a la adopción de la arquitectura:

Convincing your organization to make the transition to MDA is only half the game: implementing the new approach is the second half. After you've adopted the MDA approach and settled on the tools you need to implement it, you'll want to embark on your first-ever MDA project together. Before you even launch the project, you should clearly spell out your goals. Admit that there is hype around MDA and explain its benefits, using the proposed project as an example. Make sure that everyone on the development team understands what you're aiming for. For example, if you want to generate a complete application, provide one or two examples so that people see it can be done. If you have a different intention, then clearly state it and provide examples to back up your goal.

Start with a good project that is small enough to process quickly. It's always best to introduce a new technology or approach with a project that is quick and relatively simple. After you've done a few smaller projects, everyone will have learned the basics and executing larger ones will be easier.

Make sure that everyone who needs support gets it. Project managers might be concerned about the amount of work involved in the new approach, the duration of certain tasks, and so on. Developers may be challenged by the unfamiliar techniques and tools. Having a knowledgeable expert or consultant on the job could be helpful in this phase of the transition.

Follow up is important. After the project is finished, make a final report detailing the successes and failures of the project. Be sure to record both -- plenty of praise for what worked as well as a clear discussion of problems and how they may be resolved in the future.

lunes, agosto 22, 2005

"la apabullante Corea"

Nora Bär, el 17 de agosto pasado, publicó un breve artículo en La Nación sobre los números de Corea: Exportaciones: 2000 millones de dólares en 1960, 557.000 millones en 1996. Producto Bruto: 8000 millones en 1960, 253.000 millones en 1996. Patentes: en 2003, 22.943.

Dice Bär :
Semejante pujanza, que a ojos de un argentino parece sencillamente "milagrosa", se debe -para Deok- a las bondades de su sólido Sistema Nacional de Innovación. Para hacerse una idea de las dimensiones de esta organización basta con mencionar que en 2003 había en Corea 297.060 personas dedicadas a actividades de investigación y desarrollo -198.171 eran científicos, alrededor de siete por cada mil personas económicamente activas-. Para mantenerla activa, Corea invierte unos 19.400 millones de dólares anuales en ciencia, el 2,64% de su PBI, una cifra en aumento año tras año.
Nuestros números, por el contrario, son innombrables. No lo podemos explicar por riqueza natural, porque Corea tiene escasas, no lo podemos explicar por la diferencia de tradición histórica, porque otros países "jóvenes" tienen buenos números. Tampoco porque hubieran permitido el ingreso del capital externo a su país, porque también nosotros lo hacemos. Ni siquiera por las historias políticas recientes, porque Corea tiene antecedentes con algunos parecidos a los nuestros. ¿No sería mejor poner el ojo en cada asunto de importancia que esté estancado, y crudamente terminar con las falacias con que los encubrimos?

jueves, agosto 18, 2005

IBM: Clasificación ortogonal de defectos

Gracias a Pablo Sánchez, que en algún momento refirió el blog de Prasanna Kumar, dí con la clasificación de IBM, actualizada por última vez en febrero de 2002 (link en el título de esta nota).
Así se introduce el problema en el Center for Software Engineering, de IBM:

Traditionally, defects represent the undesirable aspects of a software's quality. Root Cause Analysis (RCA)and Statistical Growth Modeling (e.g. S-curves) have played useful roles in the analysis of software defects. Effective RCA, while yielding exhaustive details on each defect, takes substantial investment of resources for completion and points to too many actions as a result. Growth modeling, on the other hand, provides an easy way to monitor trends, but is not capable of suggesting corrective actions due to the inadequate capture of the semantics behind the defects.

ODC is a scheme to capture the semantics of each software defect quickly. It is the definition and capture of defect attributes that make mathematical analysis and modeling possible. Analysis of ODC data provides a valuable diagnostics method for evaluating the various phases of the software life cycle (design, development, test and service) and the maturity of the product. This is much like the diagnostics done in medicine using the blood sample from a patient to understand the existing health conditions and arrive at corrective actions. ODC makes it possible to push the understanding and use of defects well beyond quality.

ODC puede representar una buena guía de referencia en el seguimiento de defectos. Probablemente pase a formar parte de mis guías rápidas de trabajo.

sábado, agosto 06, 2005

Simplemente Buenos Aires

Esto no tiene nada que ver con la informática, excepto en el medio de transporte. Simplemente, para no olvidar Buenos Aires. El mercado de San Telmo, Diagonal, Belgrano, los bares, el aire de la ciudad caminando las fotografías...una imágen habla; cien son el espíritu de la ciudad.