14
2012
Arquitectura y métodos de medición
Léelo aprox. en 2:15 minutos.
Hoy día, en cualquier reunión de amigos, poner en juego la palabra “arquitectura” lleva asociados muchos conceptos negativos, como pueden ser: burbuja inmobiliaria, paro, crisis… Podríamos terminar el día hablando y mezclando todos estos conceptos.
La primera definición de arquitectura está relacionada con la proyección y construcción de edificios, pero si ponemos en juego las palabras “arquitectura Software”, quizás nos quedemos solos en la conversación y sin amigos. Así que mejor lancemos todas las preguntas relacionadas con “arquitectura e ingeniería del Software” dentro de nuestro ambiente laboral.
Pero incluso ahí tendemos a simplificar el concepto de arquitectura y, si alguien se presenta como “arquitecto de Software”, nuestra mente pondrá el foco de la conversación sobre los servidores y sus versiones, sobre las redes y su tipología, centros y las comunicaciones, etc.
Esta simplificación del concepto arquitectura nos lleva a lanzar muchas preguntas y numerosos debates. ¿Es necesario un diseño funcional? ¿La ingeniería del Software es un arte o una ciencia?
A partir de la definición de arquitectura de Auguste Perret podemos ofrecer respuestas desde otro punto de vista:
La arquitectura es el arte de organizar el espacio
APRENDE A MEDIR Y ESTIMAR PROYECTOS DE SOFTWARE
Ver Más Información
- ¿Por qué? Aprende a justificar porque se deben medir los proyectos de software
- ¿Para qué? Aprende para que sirve una medición y los beneficios que obtienes con ellas.
- ¿Cómo? Aprende métodos de estimación y medición como: COCOMO 81 y COCOMO 2000, Putnam, Estimación de 3 puntos, Puntos Función IFPUG, NESMA, MKII, COSMIC, SiFP, Puntos de Casos de Uso, SNAP, T-Shirt y un largo etc.
¡Sólo vale 7,52€ (en papel 12,35€)!
Esta definición es mucho más general y no se centra únicamente en el esqueleto del Software; nos ofrece la posibilidad de aplicar la definición de arquitectura a la visión del negocio (cómo las empresas organizan sus aplicaciones y procesos), y a la visión técnica (cómo las empresas organizan sus servicios y componentes).
Al construir edificios somos capaces de medir el tiempo que tardamos en levantar una planta y conocer el momento en el que podemos construir la siguiente. El arquitecto identifica los planes y materiales que deben ser utilizados y los trabajadores deben seguir la planificación y no inventar una nueva proporción en la mezcla de cemento, agua y arena.
Al construir Software, en muchas ocasiones no somos capaces de medir el tiempo de desarrollo. En muchas ocasiones sólo existe una arquitectura de la tecnología (soporte, herramientas), pero no existe una arquitectura lógica (negocio), ni una arquitectura técnica (desarrollo), lo que deja sin sentido un diseño funcional y nos lleva a que el desarrollo de Software sea un arte en manos de los programadores.
La aparición de las arquitecturas lógica y técnica nos ayuda a dar respuestas al negocio en cuanto a esfuerzos, planificación, coste y calidad de los productos entregados. Con la definición de estas arquitecturas somos capaces de establecer métodos de medición más precisos porque sabremos identificar los elementos y su complejidad antes de ser desarrollados. El diseño adquiere su máximo valor y no hay margen para el arte ni la improvisación.
Sin unos requisitos definidos no seremos capaces de medir y sin una arquitectura definida (en su máxima expresión) no seremos capaces de repetir casos de éxito.
Consigue Más de 100 Libros gratis
Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo
Últimos artículos de Pablo Soneira (ver todos)
- El Haiku: Nunca subestimes el corazón … (Rudy Tomjanovich) - hace 6 años
- Video del Viernes: Retrospectiva y la mejora continua - hace 6 años
- El Haiku: No nos atrevemos a muchas cosas porque… (Séneca) - hace 6 años
Otros artículos que te pueden interesar
8 Comentarios+ Escribir Comentario
¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
Hola,
Me gusta el enfoque que le habeis dado a vuestro blog!
Saludos,
./JuanJo
Muchas gracias JuanJo. Estamos trabajando en los próximos artículos, esperemos que te gusten
Saludos
Pablo
Buenas.
Me gusta mucho el enfoque de vuestro blog, felicidades.
Leyendo este articulo, y el que habeis publicado hoy (29 nov), os propondria uno referente a como conseguir unos requisitos definidos por parte del cliente sin que cambien en el tiempo. Vamos, si existe alguna :).
Un Saludo.
Gracias Francisco. Ten cuidado con lo que pides, porque a veces se cumplen los deseos… Si no tuvieramos pedidos, no tendríamos trabajo 🙂
En la cocina tenemos uno sobre la labor de un jefe de proyectos, y en que punto debe empezar su actividad.
Abrazos
Nono, tampoco eso por dios! :).
Pero no deja ser frustrante que tengas una proyecto perfectamente definido y medido para que luego te apliquen el “Donde dije digo, digo Diego”, ahi se va al traste cualquier buena intencion 🙂
Un saludo.
Las solicitudes de cambio son una entrada para nuestro proceso de Gestión de Cambios. El problema no lo encontramos en el “Donde dije digo, digo Diego”. El problema lo encontramos en como gestionamos esos cambios.
Como ya te he anunciado en primicia :), habrá unos cuantos post especiales sobre la labor del jefe de proyecto
Salu2
Muy buenos días.
Trabajo como Business arquitecto un par de aňitos, antes como process, functional, enterprise arquitecto, no tanto system/IT architect. Tengo una pequeňa duda:
Porqué pregunto? porque dándole al arquitecto más y más responsabilidades, hace que en el tiempo necesario no hace la suya.
Existen especialistas en medición, estimación, diseňo, planeación … (cuidado, tomo diseňo como algo un poco diferente a arquitectura, diseňo es todos los niveles más “bajos”…) un jefe de team sabe perfectamente planear, monitorear, un analítico debería saber bastante bien estimar, un jefe de proyecto sabe perfectamente delegar la tarea a la persona específica … Cuando el arquitecto empieza a trabajar con mediciones (o sea, términos, FTEs, effort, defects, size …) empieza a hacer el trabajo de otros y a pensar como ellos y a “jorobar y jorobar”
Es de verdad la medición responsabilidad del arquitecto? quisiera que no hagamos fuerza en la comparación de desarrollo / diseňo de arquitectura en sistemas organizacionales y en la construcción, he visto muchas comparaciones que han inducido a resultados erróneos e irreales (no siempre pero algunas veces). Sin embargo: mis amigos arquitectos de construcción (algunos de ellos hacen casos un poco más “grandes”), tienen en su team a especialistas en medición y calculación, que saben ayudar en el momento preciso y decir de que “para ésta propuesta de edificio supermoderno de 37 plantas es ésta ambiciosa torreta o balcones acceptables en materia de estática y dinámica, y en materia económica y de plan de tiempo de construcción” o “que hay que esperar al próximo verano porque ésta tecnología que Ud. arquitecto propone, no se puede “hechar” en invierno …” ah! viene el jefe de proyecto, dice: hay que hacerlo de todas maneras, viene el cliente y dice: “sí, quiero esos balcones) y para ello hay otras roles (o team) para buscar soluciones como isolar y calentar, hacer el bloque en otro lado y dejarlo montar completo … etc… el jefe de proyecto planea, busca y maneja riesgos, comunica de antemano, monitorea …
Que conste, muchas veces hago como arquitecto, y como business analático, y tengo la role de medidor IFPUG, pero ello con 3 roles distintas y estrictamente declaradas en el proyecto, para poder decir honestamente: desde mi punto de vista de arquitecto de negocios” o “desde … de arqui de solución”, o d analítico, o de …”
Por ello estoy un poco confundido si su Best practice es de que el arquitecto de solución de proyecto de business … es el encargado o responsable (o acconutable) de las mediciones – sobre todo funcionales.
Muchas gracias por eventual respuesta y discúlpe la extensión …
Respetuosamente:
Iglesias.
En el post comentamos la necesidad de definir tres niveles de arquitectura. La experiencia nos dice que en la mayoría de los clientes en los que trabajamos, cuando hablan de arquitectos se refieren a las herramientas que utilizan o al sistema operativo y las versiones que utilizan.
Extender el concepto de arquitectura nos ayuda a definir nuestro mapa de aplicaciones, nuestras tecnologías utilizadas y la forma que debemos seguir para construir el Software.
El arquitecto diría lo siguiente: “Para construir esta casa, utilizaremos ladrillos de color verde, 10 cm alto / 20 cm de ancho / 50 cm de largo, los ladrillos los traslademos a mano, haremos un edificio de 20 m de alto…”
El responsable de la medición no es el arquitecto.
El analista recoge los requisitos y utilizando los datos históricos es capaz de estimar el esfuerzo y coste que supone realizar ese edificio con esas condiciones.
El analista no debería decidir que va a utilizar ladrillos más grandes o de otro color. Debería proponer mejoras en el proceso de construcción.
El analista es el responsable de las mediciones y el seguimiento de las normas definidas en la arquitectura.
Un saludo y muchas gracias por tu comentario