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.