Articulo sobre el agile BA

http://library.dzone.com/sites/all/files/whitepapers/V1%20Agile%20Biz%20Analyst%20White%20Paper%200809.pdf

de la empresa http://www.versionone.com

2 presentaciones sobre turismo

Ponencia Raúl Hernández de la Jornada Nuevas Experiencias Turísticas: Oportunidades y modelos de negocio, en Foro CajaCanarias-27 Noviembre 2012 from Fundación FYDE-CajaCanarias

Ponencia Sergio Moreno Gil de la Jornada Nuevas Experiencias Turísticas: Oportunidades y modelos de negocio, en Foro CajaCanarias-27 Noviembre 2012 from Fundación FYDE-CajaCanarias

Libro sobre programación

Todavía no lo he leído, pero se ve que van al grano.

http://cloud.github.com/downloads/emanchado/camino-mejor-programador/camino_2012-11-09_3bee1fb.pdf

Gran video sobre Gobierno Abierto

Como he abierto un gobierno: Nagore de los Rios at TEDxMadrid

Esta es la plataforma

http://www.irekia.euskadi.net/

Ssh desde un navegador web con HTML5... Increible.

Ssh desde un navegador web con HTML5... Increible.


http://liftoffsoftware.com/Products/GateOne

Infografía PI-Model Driven Development

Platform-Independent Model-Driven Development Infographic

Executive Summary Platform-Independent Model Drive Development (PI-MDD) is an integrated agile, test-driven and model-driven approach to architecting, developing, testing and deploying complex, high-performance systems software. Two decades of constant refinement by hundreds of development teams and dozens of technology and expertise vendors spanning a range of challenging industries have optimized this method and its supporting automation to deliver the highest performance and best quality systems while boosting key business results. Real-world project metrics show the PI-MDD at its current level of refinement yields repeatable results including substantial productivity gains and 10 times quality gains within 14 months of adoption.

Model driven engineering is not cool

New programming languages are cool. Agile is cool. Cloud is cool. MDE / modeling is clearly not cool. Every time I mention the word model I get the immediate question: where is the proof that MDE improves productivity / quality /… ty. Instead if I talk about the latest programming language (new Agile method, new cloud platform,…) everybody gets excited and nobody asks if somebody has done any research on whether the new language is better than existing ones. They always give it at least the benefit of the doubt.

I wonder why this is not the case with MDE. Maybe the memories of the UML fever still hurt. Maybe there is something intrinsic in MDE that repels people. Maybe we should stop doing research on new MDE technologies and instead try to understand how we could change people’s perception and make MDE cool. That would probably the biggest advancement in the field of the last 10 years!

Two last things:

• We do have some proof about the benefits of modeling (see an example) but this is not the topic of this post
• I’m not saying that cool technologies do not bring any benefit (nor that right now we don’t have proof of that). I’m highlighting they were massively adopted before that proof exsisted.

http://modeling-languages.com/mde-is-not-cool/ (via Jordi Cabot)

[...] Meinte Boerma
One of the reasons that MDE is not cool is precisely that it has an uncool history (in the form of MDA, UML, 4GL, CASE tools, etc.) 

[...] Gleen

I’m going to have to disagree with Frank. MDE is not cool with programmers precisely because they want to spend their time coding. With MDE, you spend most of your time modeling and not coding.

As a programmer, I think MDE is cool because you do spend time meta-programming which I find to be very geeky and intellectually challenging in a oddly relaxing way. Most programmers aren’t into that at all. They are quite uncomfortable with modeling because they think it is for wannabees and posers who want to pretend that they can code but really cannot.

Plantillas Lean Startup Canvas y Business Model Canvas

Google drive es una buena opción para crear y compartir tus modelos de negocio. Podemos para ello podemos usar las plantillas que ya están creadas de manera pública.

https://drive.google.com/previewtemplate?id=1X27K9Z_6mPI7Q_YTBWT7llWdPp0JGre2AB7cueft5pg&mode=public

https://drive.google.com/previewtemplate?id=16uOd158UzJM9oqGWgJOtbppzGNPmZ4fWMSV6_xBz3Z8&mode=public

https://drive.google.com/previewtemplate?id=1UaiazQ2v97VlekS8iFtLYafWSQzKB9Waq2ivDI-F4cU&mode=public

Reflexiones sobre Oficinas Técnica

Reflexiones sobre Oficinas Técnica ( vía Rafa Feliciano)
http://rafafelicianor.wordpress.com/2011/09/26/oficina-tecnica-de-proyectos-un-aliado-estrategico/

Considero que hay tres características principales que convierten a unaOficina Técnica de Proyectos en un socio tecnológico necesario para implantar las medidas derivadas de la estrategia de la organización. Como detallaré seguidamente, estas cualidades son inherentes a un equipo técnico-funcional dedicado a la gestión de proyectos de tecnologías de la información.

Transversalidad

Los sistemas de información alcanzan, de manera horizontal, a toda la organización y a todos sus niveles. La promoción e implantación de aplicaciones y herramientas es, por lo tanto, una función de la oficina técnica que implica un impacto global. Por este motivo, alinear a la OTP con la estrategia corporativa se convierte en un factor facilitador clave para llevar a cabo el despliegue de las actuaciones y políticas que se desea adoptar.

Conocimiento de negocio

Siguiendo el punto anterior y dado el carácter global de los sistemas de información, el asesoramiento y gestión de proyectos que desempeña una oficina técnica en la organización hace que concentre, en un reducido equipo de consultores, un amplio conocimiento del negocio. Esta capacidad ofrece a la organización un valor que, en muchas no tiene cubierto con perfiles correspondientes a técnicos de gestión.

Conocimiento tecnológico

El perfil de los consultores de una OTP cuenta con una sólida base en conocimiento de las infraestructuras informáticas y de telecomunicaciones. Estas capacidades convierten a una oficina técnica en referente en el ámbito tecnológico de la organización, ya que puede abarcar desde el conocimiento técnico hasta la planificación estratégica de los sistemas.

Como conclusión, la combinación de estos tres factores es un valor añadido adicional, ya que se concentra en un único equipo de trabajo tanto el conocimiento horizontal (negocio) como el especializado o vertical (tecnología)

http://rafafelicianor.wordpress.com/2011/06/08/dos-donts-de-una-oficina-de-proyectos/

[...]

Cuando me pregunto qué debe hacer una OTP me surgen múltiples respuestas, todas ellas con tres conceptos comunes: coordinación, conocimiento, asesoramiento. De estas tres ideas generales se desprende la relación de acciones identificadas: anticipar los problemas y proponer soluciones; orientar la evolución de los sistemas de información proponiendo las líneas tecnológicas a seguir; gestionar los proyectos y controlar su ejecución, tanto en lo referido al seguimiento de plazos como a garantizar la calidad de las soluciones implementadas; identificar las necesidades de la organización; participar en el diseño de las soluciones para que se ajusten a las necesidades identificadas; canalizar las peticiones provenientes de la capa de negocio concretando los requerimientos de partida para facilitar la obtención de un análisis inicial; ofrecer información de soporte al nivel directivo para la toma de decisiones estratégicas.

A pesar de que desarrolle todas estas actividades, una OTP no podrá ofrecer todo su valor potencial si la organización no tiene a este equipo como referencia en el desarrollo del negocio y, consecuentemente, de los sistemas de información.

Por otra parte, desde mi punto de vista hay un tipo de tareas que no debe hacer una OTP, y que podría resumir como ejecutar los proyectos encomendados por la organización a terceros. Dentro de esta categoría incluyo, principalmente, cuestiones como la realización de tareas de mantenimiento y evolución de los sistemas de información, implementación de las soluciones evolutivas o correctivas de las aplicaciones de soporte al negocio, etc. La realización de tareas de este tipo supondría una pérdida de eficiencia al duplicar esfuerzos que deben ser asumidos por la empresa que ejecuta los proyectos en cuestión. En este sentido, la OTP no estaría aportando el valor añadido esperado por la organización.

Como resumen me ha parecido interesante representar sobre el diagrama del Ciclo de Deming (Plan-Do-Check-Act) las responsabilidades de una Oficina Técnica de Proyectos, ya que encajan prefectamente con los pasos Plan y Check.

En este punto se podría ampliar la discusión con la siguiente pregunta: ¿quién es el responsable de planificar las tareas a realizar en el proyecto? Si atendemos a la propuesta de roles de Scrum, la planificación de cada iteración es responsabilidad del Product Owner (persona que toma las decisiones del cliente) pero, ¿puede ser la OTP el Product Owner? En el caso de mi organización la respuesta es no.

Para concluir me gustaría retomar el comentario sobre el denominador común que hacía al principio. En este caso propongo tomar como referencia la guía PMBOK, que aborda la PMO (Project Management Office) desde una perspectiva abierta indicando que tiene “responsabilidades asignadas con relación a la dirección centralizada y coordinada de proyectos”, señalando posteriormente funciones como el apoyo administrativo al establecimiento de políticas, metodologías y plantillas; la capacitación y asesoría a los directores de proyectos; la identificación de recursos necesarios en el proyecto; y la centralización de la comunicación entre directores de proyecto, patrocinadores, nivel directivo y otros interesados.

Seguramente con vuestra experiencia y aportaciones se podrá ampliar y mejorar esta primera aproximación. ¿Se animan a participar?

¿Qué es una OTP?

http://www.ambiser.es/servicios/ContenidoExtendido/ContenidoExtendido_0006.html_49272422.html

Una Oficina Técnica de Proyectos (OTP) es un centro de competencia dentro de cualquier organización, normalmente externalizado, que permite la coordinación entre las diferentes áreas de la organización y los departamentos de tecnología, sirviendo de referencia para la recogida y canalización de todas las necesidades en materia tecnológica.

Funciones de una OTP Establecer las bases tecnológicas de los diferentes proyectos a ejecutar Definir los pliegos técnicos de las contrataciones a realizar Dar soporte a la evaluación de las propuestas técnicas presentadas por los diferentes ofertantes Realizar el seguimiento de los proyectos en ejecución Dar soporte a las certificaciones de las entregas correspondientes a los proyectos ejecutados Realización de informes de seguimiento y cuadro de mando de indicadores de seguimiento del proyecto Analizar las nuevas necesidades planteadas desde los diferentes departamentos de la Organización Apoyo a las reuniones de seguimiento Apoyo a la colaboración con otras Administraciones Públicas Búsqueda activa y continua de financiación alternativa disponible Difundir los resultados del proyecto a Ciudadanos, Empresas y otras Administraciones Coordinar los diferentes canales de comunicación de la organización para difundir el proyecto

¿Qué beneficios obtiene el cliente? Recibe el asesoramiento adecuado y alineado a los objetivos del proyecto, sin tener que realizar contrataciones de personal especializado. Coordina los diferentes actores del proyecto adecuadamente Establece un equipo de referencia para cualquier consulta o acción a emprender dentro de la organización Unifica los criterios para seleccionar y atender a proveedores Obtiene un ahorro de costes en la gestión de cualquier proyecto Dispone de los medios humanos adecuados a las necesidades del proyecto en todo momento Oficina técnica de proyectos from Isidro Parga PMO (vía PMBOK) A project management office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project. The projects supported or administered by the PMO may not be related, other than by being managed together. The specifi c form, function, and structure of a PMO is dependent upon the needs of the organization that it supports. A PMO may be delegated the authority to act as an integral stakeholder and a key decision maker during the beginning of each project, to make recommendations, or to terminate projects or take other actions as required to keep business objectives consistent. In addition, the PMO may be involved in the selection, management, and deployment of shared or dedicated project resources. A primary function of a PMO is to support project managers in a variety of ways which may include, but are not limited to: Managing shared resources across all projects administered by the PMO; Identifying and developing project management methodology, best practices, and standards; Coaching, mentoring, training, and oversight; Monitoring compliance with project management standards, policies, procedures, and templates via project audits; Developing and managing project policies, procedures, templates, and other shared documentation(organizational process assets); and Coordinating communication across projects. Project managers and PMOs pursue different objectives and, as such, are driven by different requirements. All of these efforts, however, are aligned with the strategic needs of the organization. Differences between the role of project managers and a PMO may include the following: T he project manager focuses on the specifi ed project objectives, while the PMO manages majorprogram scope changes which may be seen as potential opportunities to better achieve business objectives. The project manager controls the assigned project resources to best meet project objectives while the PMO optimizes the use of shared organizational resources across all projects. The project manager manages the constraints (scope, schedule, cost, and quality, etc.) of the individual projects while the PMO manages the methodologies, standards, overall risk/opportunity, and interdependencies among projects at the enterprise level.

SPL en pequeñas empresas

Effective development of automation systems through
domain-specific modeling in a small enterprise context



High development and maintenance costs and a high error rate are the major problems in the development of
automation systems, which are mainly caused by bad communication and inefficient reuse methods. To overcome these problems, we propose a more systematic reuse approach. 

Though systematic reuse approaches such as software product lines are appealing, they tend to involve rather burdensome development and management processes. This paper focuses on small enterprises. Since such companies are often unable to perform a “big bang” adoption of the software product line, we suggest an incremental, more lightweight process to transition from single-system development to software product line development. Besides the components of the transition process, this paper discusses tool selection, DSL
technology, stakeholder communication support,  and business considerations. Although based on problems from the automation system domain, we believe the approach may be general enough to be applicable in other domains as well. The approach has proven successful in two case studies. First, we applied it to a research project for the automation of a logistics lab model, and in the second case (a real-life industry
case), we investigated the approaches suitability for fish farm automation systems



http://download.springer.com/static/pdf/469/art%253A10.1007%252Fs10270-012-0289-1.pdf?auth66=1351512547_48997887e84e0044a96808afbdda8db4&ext=.pdf (vía @jlroda)

Agile Requirements Management - When User Stories Are Not Enough

Retomando los Casos de Uso e Historias de Usuario

CEO BigLever, SPL

Video del CEO de BigLever empresa especializada en SPL.

Casos de Uso y Agile

Muy bueno las metáfora que escribe Cockburn en su blog. Totalmente de acuerdo

http://alistair.cockburn.us/Elephant+carpaccio

Product manager.

Un video muy interesante sobre product manager. Se mencionan conceptos como línea de producto, business case, ....

http://www.youtube.com/watch?v=OzBmyYTZAxI&feature=g-wl

Cómo hacer un CD que arranque una shell de grub

Si necesitamso recuperar el sistema de arranque tener una LiveCD es una opción... otra más rápida tener un cd con grub. Así se puede crear

mkdir iso

mkdir -p iso/boot/grub

cp /usr/share/grub/i386-pc/stage2_eltorito iso/boot/grub
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso

... grabar la iso en un CD
... arrancamos del CD 

find /boot/grub/stage1

...
...

root (hd0,0)

Recuerda hd0, disco primario, 0 partición 1

setup (hd0)

¡Bien! Para arrancar (sin reiniciar porque la BIOS es vieje p.ej.  y no arranca desde esa unidad o por ahorrarnos tiempo)

kernel /boot/[TAB] ro root=/dev/sda1 
initrd /boot/[TAB]
boot 



Nota 1: Desde el grub puedes ver fichero con el comando cat, P.ej cat /etc/fstab para ver si las unidades son correctas.

Nota 2: Esto es para el grub 0.9x, no para grub 2.

Convertir máquinas virtuales a máquinas físicas

VMware virtual machines exist as files on the hard drive of the host computer. VMware vCenter Converter can convert a physical computer to a virtual machine, but not the reverse. A VMware virtual machine can be cloned using a program such as Norton Ghost, dd or PartImage. The downside of cloning is that it is a multiple-step process, which can be complicated. A simpler alternative is Qemu, an open-source virtual machine platform that supports VMware virtual machine images and can convert them to physical disks.


http://www.ehow.com/how_7390760_convert-vmware-virtual-physical.html

JSON-LD

Después de un discusión en twitter sobre rdf vs. api he aprendido que es Json-ld (via @chozero). Aquí les dejo un video que lo explica genial, y la verdad es que tiene buena pinta.


A short introduction to JSON-LD for Web developers, designers, and hobbyists. It covers how to express basic Linked Data in JSON. If you have any questions

DROOLS reglas de negocio y DSL

Drools es un motor de regla de negocio para Java, usa  en parte DSL para definir reglas.
Tambien tiene tablas de decisiones escritas en Excel.
¿alguien lo ha usado?

http://docs.jboss.org/drools/release/5.4.0.CR1/drools-expert-docs/html/ch05.html#d0e6321

BA vs. PO

En el mundo del agilismo buscan insistentemente un buen "Product Owner", lo que realmente necesitan tanto los clientes como las empresas desarrolladoras son buenos "Business Analyst". Adjunto presentación sobre el valor del analista en las organizaciones.



 

Escribir buenos casos de uso

Aqui tenéis la presentación sobre escribir casos de uso. Creo que es una actividad fundamental para analistas de negocio. La mayoría del material se basa en los autores Cockburn y Josep Vilalta.


 

Presentación MDD

En esta presentación explico los conceptos básicos de MDD. Muchos frameworks de desarrollo avanzan en este sentido, lo que me resulta desconcertante que las empresas de desarrollo de software y desarrolladores no muestren interés en MDD. También doy unas pinceladas a SPL.




 

MD*/DSL Best Practices

Buenas prácticas al construir DSLs.


http://voelter.de/data/pub/DSLBestPractices-2011Update.pdf

Herramienta para test automáticos.

Herramienta para hacer test funcionales realizados automáticamente y generados también automáticamente en base a modelos.
http://www.metacase.com/blogs/jpt/blogView?showComments=true&entry=3517490549

 http://youtu.be/B82pesisQaY

 http://youtu.be/HR8mzcHnHKk

Planificación de Sistemas de Información (PSI)

Planificación de Sistemas de Información (PSI)
¿PUEDE EL PSI AYUDARNOS A DEFINIR NUESTRA CARTERA DE PROYECTOS Y SPL?


---
El Plan de Sistemas de Información tiene como objetivo la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización. Este marco de referencia consta de:

Una descripción de la situación actual, que constituirá el punto de partida del Plan de Sistemas de Información. Dicha descripción incluirá un análisis técnico de puntos fuertes y riesgos, así como el análisis de servicio a los objetivos de la organización.
Un conjunto de modelos que constituya la arquitectura de información.
Una propuesta de proyectos a desarrollar en los próximos años, así como la prioridad de realización de cada proyecto.
Una propuesta de calendario para la ejecución de dichos proyectos.
La evaluación de los recursos necesarios para los proyectos a desarrollar en el próximo año, con el objetivo de tenerlos en cuenta en los presupuestos. Para el resto de proyectos, bastará con una estimación de alto nivel.
Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos mecanismos de evaluación adecuados.
La perspectiva del plan debe ser estratégica y operativa, no tecnológica.

Es fundamental que la alta dirección de la organización tome parte activa en la decisión del Plan de Sistemas de Información con el fin de posibilitar su éxito. La dirección debe convencer a sus colaboradores más directos de la necesidad de realización del plan; de su apoyo de forma constructiva, mentalizándose de que la ejecución del mismo requerirá la utilización de unos recursos de los cuales son responsables.

La presentación del Plan de Sistemas de Información y la constitución del equipo supone el arranque del proyecto y es fundamental que las más altas instancias de la organización estén implicadas en ambos, dando el apoyo necesario y aportando todo tipo de medios. Explicar el plan a las personas de la organización y a las unidades organizativas afectadas sobre las que recaerá el Plan, el apoyo de los altos directivos y la cualificación de los recursos de las distintas unidades implicadas, serán factores críticos de éxito del Plan de Sistemas de Información.

El nivel de detalle con el que se hará el estudio de la situación actual dependerá de la existencia de documentación actual, de si hay personas que conozcan dicha documentación y de la predisposición a una sustitución total o parcial por sistemas de información nuevos. En cualquier caso, como paso previo para detectar aspectos importantes que puedan afectar a la organización, es necesario investigar sus puntos fuertes, áreas de mejora, riesgos y amenazas posibles y hacer un diagnóstico de los mismos.

Para la elaboración del Plan de Sistemas de Información se estudian las necesidades de información de los procesos de la organización afectados por el Plan, con el fin de definir los requisitos generales y obtener modelos conceptuales de información. Por otra parte se evalúan las opciones tecnológicas y se propone un entorno.

Tras analizar las prioridades relacionadas con las distintas variables que afectan a los sistemas de información, se elabora un calendario de proyectos con una planificación lo más detallada posible de los más inmediatos. Además, se propone una sistemática para mantener actualizado el Plan de Sistemas de Información para incluir en él todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo.





http://manuel.cillero.es/doc/metrica-3/procesos-principales/psi
http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/otros/metrica3-psi.pdf

Presentación sobre SPL enfoque en los requirimientos

http://www.ifi.uzh.ch/seal/teaching/courses/ase/11-PLE_stoiber.pdf

Libro gratuito sobre SPL

http://www.intechopen.com/books/software-product-line-advanced-topic

Software Product Line - Advanced Topic

Qué es COTS

El acrónimo COTS (del inglés Commercial Off‐The Shelf, o “comercial, de la estantería”),
aplicado al software, hace referencia a un producto disponible de forma comercial. Es decir, a
aquel que no es desarrollado a medida para una demanda única y específica, sino con unos
requerimientos más genéricos y con la intención de ser comercializado y vendido de forma
más o menos masiva [172] [124]. De forma simple, podemos decir por tanto que un software
COTS es un producto software comercial. Aunque algunos autores han constatado que existe
cierta ambigüedad e indefinición sobre el uso que se hace del término COTS en la bibliografía
relacionada con la ingeniería del software [29][124], este carácter comercial es un aspecto en
el que hay un claro consenso. Así, ejemplos clásicos de COTS son las aplicaciones ofimáticas,
las herramientas de CAD/CAM (del inglés Computer Aided Design/Computer Aided
Manufacturing; esto es: diseño asistido por computadora/fabricación asistida por
computadora), los gestores de bases de datos, o los paquetes de ERP (del inglés Enterprise
Resource Planning, o software    de planificación de recursos empresariales), que se pueden
adquirir como productos comerciales manufacturados y listos para su uso.



Extraido de la tesis

http://postgrado.ei.uvigo.es/ssiaBlog/wp-content/uploads/2010/12/Tesis-doctoral-Emilio-Garc%C3%ADa-Rosell%C3%B3.pdf


Hace una buena explicación de COTS y uso de componentes.

Principios CAS, Agile y SPLE

Dos links sobre test muy diferentes...

http://readyset.tigris.org/nonav/templates/test-case-format.html
http://www.makinggoodsoftware.com/2009/08/05/how-to-write-good-tests/

Agile y SPL

Agile y SPL pueden vivir juntos.

http://www.lsi.upc.edu/events/aple/TianCooper.pdf

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406496


http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CIUBEBYwAQ&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.107.61%26rep%3Drep1%26type%3Dpdf&ei=O8nRT_T4DqSn0QXUmsnyAw&usg=AFQjCNEQvJsMwra5qPO1YNPtUNsehVPSyQ&sig2=nJTzYeWCl3U9bWZKal7XIQ

PMBOK &. Agile

Muy interesante, relación de procesos del PMBOK con metodologías ágiles
¡Gracias! Toni Dorta (@ToniDorta)


http://leadinganswers.typepad.com/leading_answers/pmbok-v4-process-mappings-large-format.html

MD-SPL

¿Qué es MD-SPL?


MD-SPL une dos paradigmas para el desarrollo del software, por un lado MDD, Model Driven Development y por otro SPL, Software Product Line.


MDD
Resumiendo mucho, podemos decir que  MDD (o MDSD), define modelos sobre el dominio de negocio con el objetivo de crear aplicaciones con calidad y a bajo coste gracias a la reutilización estratégica de código mediante DSL (lenguajes específicos de dominio).


Hay que tener cuidado cuando entramos en en el mundo de los modelos ya que es muy amplio y con enfoques muy diferentes. Recalcar que MDD, es ágil y funciona. Es muy diferente a  MDA, UML o RUP.  Con MDD pasamos de modelo a código directamente,  sin más florituras :-)

Puedes ver más sobre MDD en esta presentación
https://docs.google.com/present/edit?id=0AUj2bcZ_ecAkZGRodGtzempfMTEzZDI5azViZDY


Este libro de Voelter explica perfectamente todo el paradigma MDD
http://www.voelter.de/publications/books-mdsd-en.html




SPL
Software Product Lines, está englobada dentro del paradigma  Software Factory. Desgraciadamente el mal uso del término Software Factory, o Factoría de Software se ha extendido y mucha gente los usa como sinónimo de "industria de software".
El concepto correcto de SPL y SF los podemos consultar en el SEI
http://www.sei.cmu.edu/productlines/
Una SF implica generalmente el uso de entornos de desarrollo especializados y configurados, “software factory schemas”, DSLs, patrones de análisis, vocabularios controlados, frameworks, generadores de código, librerías especializadas, y quedan más. Obviamente, todos coordinados y definidos dentro de un proceso de desarrollo y configurados para un tipo determinado de aplicaciones.




Ejemplo:


Supongamos que el ISTAC tiene en su cartera de proyectos pendiente de realizar diferentes webs para mostrar datos estadísticos a para diferentes usuarios  como periodistas, políticos, consumidores de información, etc.


Lo primero sería configurar la SPL, para ello hay muchos actividades a realizar. Una de las más relevantes es definir la "variabilidad" entre los productos.


* Número de indicadores. Cada web mostrará sólo una serie de indicadores.
* Visualización. Cada indicador se mostrará de diferente forma. p.ej. Gráfico o tablas
* Acceso. Los Indicadores podrán ser público o privado
* Descripción del datos. Existirá diferentes descripciónes del indicador

Otros aspectos  a considerar serían disponibilidad, agregación de datos, calidad de dato, pago, metadatos, etc.


La parte más variable de la SPL la gestionamos a través de DSL textuales y MDD.


Creamos un DSL textual para describir nuestro indicadores (es para uso interno, no estamos  preocupados de la interoperabilidad o web semántica) y otro para definir las diferentes web.




Un ejemplo de DSL


indicador "Paro registrado"
fuente "SCE"
descripcion sencilla "bla bla"
descripcion complicada "bla bla bla bla"
acceso-dato  "datos.istac.gobcan.org/datos/paro.px"
datos mes "enero" "datos.istac.gobcan.org/datos/paro-enero.px"



indicador "Alojamiento turistico"
fuente "SCE"
acceso-dato  "datos.istac.gobcan.org/datos/alojamiento.px"
datos mes "enero" " datos.istac.gobcan.org/datos/alojamiento.px 



web "ISTAC prensa"
pagina "Paro registrado"
mostrar indicador "Paro registrado" visualización "grafico"
mostrar indicador "Paro registrado" descripción "sencilla"




web "ISTAC consumidores informacion"
pagina "Paro registrado"
mostrar indicador "Paro registrado"  visualizacion "rdf"




Lo siguiente es crear "generadores de código"  que leen nuestro DSL y "escupen" el código que muestra las diferentes páginas. Este sería el esquema.

Gestión de roles en el código

Gracias a Carlos Ble.

Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks

http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/

I used to call this action-based security. However, the recent popularity in Model-View-Controller application architectures has overloaded the term “action”. Most people think of actions as controller actions because of this. While a controller action is certainly an action or activity that may have authorization needs, it’s not the only place that authorization may need to be checked. Using the term “activity” instead of action gives a little bit of differentiation and distinction, to hopefully indicate that authorization is not strictly limited to controller actions.

Integración Linux Windows

Plantea el uso de pam-mkhomedir y tambien de pam script.

http://es.scribd.com/doc/71750644/68/Uso-de-pam-mkhomedir-y-pam-mount

Blog sobre BA

Un gran blog de toca todo lo que me interesa: patrones de análisis, mda, cu, etc..

http://caminao.wordpress.com

Dsl features sple grammar

Gramatica de features en Emftext para Sple

http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo_Feature_Models

Play framework on the cloud made easy: Openshift module.

Play framework on the cloud made easy: Openshift module

Read more: http://www.javacodegeeks.com/2012/02/play-framework-on-cloud-made-easy.html#ixzz1v7P3rNIV

Crítica DSL

http://ruicurado.com/2009/11/25/the-hidden-costs-of-domain-specific-languages/

Ontologies, DSL and others...

Using ontology in the development of domain-specific languages http://inforum.org.pt/INForum2010/papers/compiladores-e-linguagens-de-programacao/Paper056.pdf (incluye un ejemplo de caracteristicas con dsl) Ontology Driven Development of Domain-Specific Languages http://www.doiserbia.nb.rs/img/doi/1820-0214/2011/1820-02141100019C.pdf The Hidden Costs of Domain-Specific Languages http://ayende.com/blog/2968/why-we-need-for-domain-specific-languages DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design http://www.theenterprisearchitect.eu/archive/2009/05/06/dsl-development-7-recommendations-for-domain-specific-language-design-based-on-domain-driven-design

26 reglas para construir DSL

Design Guidelines for Domain Specific Languages http://www.dsmforum.org/events/DSM09/Papers/Karsai.pdf

SPL - SEI

Presentación SPL
http://www.sei.cmu.edu/library/assets/spl-essentials.pdf
http://www.sei.cmu.edu/productlines/

AMPLE - Aspect Model Product Line Engineering

Una visión global de Orientación Aspectos, MDD y SPL. Mucha documentación a leer.

http://www.ample-project.net

http://www.amazon.com/Aspect-Oriented-Model-Driven-Software-Product-Lines/dp/0521767229/ref=sr_1_1?ie=UTF8&qid=1331053036&sr=8-1

The aim of AMPLE is to provide a Software Product Line (SPL) development methodology that offers improved modularisation of variations, their holistic treatment across the software lifecycle and maintenance of their (forward and backward) traceability during SPL evolution

Variabilidad en MD-SPL

VML* – A Family of Languages for Var iability M a  n a gem en t   in   Softwa r  e  P r  od u ct   L in es
http://www.steffen-zschaler.de/publications/sle09_vmlstar.pdf

Requirements
http://teknologimalaysia.academia.edu/ShahlizaHalim/Papers/799453/Requirements_Identification_and_Representation_in_Software_Product_Line


http://www.emn.fr/z-info/harbol07/IICCC.pdf

Herramientas Modelos de Caractarísticas.FOSD

Una buena lista la encontramos en Wikipedia:
http://en.wikipedia.org/wiki/Feature_model


http://www.eclipse.org/proposals/feature-model/

http://www.eclipse.org/modeling/emft/featuremodel/

During the last years Feature Modeling has become the "standard" for variability management in the field of Software Product Lines. Feature Models are easy to understand and provide a generic way to represent variability information, independent of a specific application domain. Several independent projects using the Eclipse platform / EMF have each defined their own meta model for feature models. Although these meta models have considerable structural differences, their core semantics are similar. A brief description of feature models can be found at Wikipedia. The EMF Feature Model project will define a standard representation of Feature Models inside the Eclipse platform. The intent is to provide a uniform representation for variability information for tools based on the Eclipse Modeling Framework. This will allow easy and consistent access to variability-related information, such as variation points and variant decisions, in DSLs, M2M transformations, and other contexts where variability information is produced or consumed.

M2T (Xpand) and TMF (Xtext) eclipse projects already have (simple) interfaces for feature model information integrated. These should be based on the proposed EMF Feature Model.

http://fosd.de/fide/

http://www.pnp-software.com/XFeature/

:
 Feature-Oriented Software Development
http://www.jot.fm/issues/issue_2009_07/column5.pdf

http://www.sei.cmu.edu/reports/05tr012.pdf

http://www.voelter.de/data/presentations/Tools-VariabilityInSoftware.zip

Virtualbox headless

Virtualbox puede ser usado como plataforma de virtualización servidora.


https://www.virtualbox.org/manual/ch01.html#intro-installing






#VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack

#VBoxManage modifyvm "VM name" --vrde on



#VBoxManage startvm "vm2" --type headless

# rdesktop -a 16 -N z:3389
# VBoxManage controlvm  "vm2" poweroff

git over Centos

Hoy toca instalar git sobre Centos y vincularlo a Atlassian FishEye.

http://akcdev.blogspot.com/2011/02/instalando-git-en-centos-5.html

Twist 2 y BDD

http://www.infoq.com/news/2010/04/twist-2.0

DSL y test

Además de definir DSL para crear nuestras aplicaciones, debemos crear DSL que permitan testearlas. Sin duda, ambos DSL compartiran conceptos del negocio.

http://www.thoughtworks.com/articles/dsls-functional-testing


“I believe that the hardest part of software projects, the most common source of project
failure, is communication with the customers and users of that software. By providing a clear
yet precise language to deal with domains, a DSL can help improve this communication.” –
Martin Fowler, Domain Specific Languages (working title).
Involving all the stakeholders in the testing process requires that subject matter experts,
customers, testers, and developers communicate consistently and effectively. In the past,
many software project teams relied on extensive requirements documentation to communicate
effectively across these groups. However, requirements in this context require a fair
amount of translation. Subject Matter Experts (SMEs) and analysts must translate customer
desires and needs into requirements. Developers must translate these requirements into code,
and testers must independently translate the same requirements into tests. Finally, each one
of these translations must match the customers’ original expectations, which may change
over time. It’s similar to the telephone game that children play in primary school, only that
the starting phrase is a moving target.
We could effect a substantial improvement to the translation problem if the customers could
express and test their own requirements, or acceptance criteria, themselves. At a minimum,
customers should be able to simply review any translations that occur in the process and
verify that translations match their needs.
One means to ensure that code across a project team is readable by everyone is a DSL.
Domain specific languages are mini-computer languages that are designed around a very
specific purpose or domain. They are not general programming languages like Java, C# or Ruby but are tailored toward a narrow task. Depending on the implementation, they can also closely resemble written human language. Applied to automated functional testing, creating a DSL to express testing intent solves several problems.
A DSL for an SUT allows a team to share a vocabulary that describes their domain. If a standard vocabulary is already in use, then using a DSL to express acceptance criteria minimizes translation errors. Furthermore, DSLs allow non-technical stakeholders to interact with the testing effort on more level terms. A properly designed DSL will at a minimum allow these stakeholders to read tests. Under the right circumstances, and with the appropriate skill level, it’s possible for domain experts and non-technical users to write tests as well."




Twist™ is a next-generation collaborative functional testing platform for software teams.
It provides a rich environment for authoring, executing, and maintaining tests. Twist is designed
to be used by subject matter experts, QA professionals and developers, making everyone on
a team jointly responsible for software quality. It allows you to express acceptance criteria as
executable tests, while using Domain Specific Languages. Twist leverages the testing expertise of ThoughtWorks, the creators of the popular web testing engine, Selenium.


Twist
http://www.thoughtworks-studios.com/agile-test-automation/features-benefits

Para los amantes de las retrospectivas

http://www.softwarestrategy.co.uk/dlgsheets/

Pasar una VM en virtualbox a VMWare ESXi

Tan sencillo como:

VBoxManage clonehd Ubuntu10.04.LTS-etsii.powered.vdi exthost.vmdk --format vmdk

Designing web interfaces

Parece que este libro está muy bien
http://designingwebinterfaces.com/explore
Patrones sencillos para hacer mejores nuestras aplicaciones web.