Conclusiones extraídas de las mesas de debate sectoriales celebradas en la jornada 'El Turismo en la Especialización Inteligente de Canarias'.
miércoles, 20 de marzo de 2013
lunes, 18 de marzo de 2013
DSL textual para pseudocódigo.
En una entrada del blog de Jordi Cabot http://modeling-languages.com/structured-flowcharts-outperform-pseudocode/ se comenta que los algoritmos se entienden mejor por los alumnos con lenguajes visuales (flowcharts).
Yo pienso que un buen pseudocódigo escrito como un DSL textual tal vez es mejor, pues tiene mayor expresividad.
Aquí hay un ejemplo de un DSL textual para escribir pseudocódigo. http://wikis.uca.es/wikiPLII/index.php/Pseudoc%C3%B3digo_DSL
Yo pienso que un buen pseudocódigo escrito como un DSL textual tal vez es mejor, pues tiene mayor expresividad.
Aquí hay un ejemplo de un DSL textual para escribir pseudocódigo. http://wikis.uca.es/wikiPLII/index.php/Pseudoc%C3%B3digo_DSL
jueves, 14 de marzo de 2013
Open Goverment
¿Qué pueden aprender los gobiernos de la revolución de la información? En esta motivadora charla, Beth Noveck, quien fuera la Administradora de Tecnologías de la Casa Blanca presenta una visión práctica y abierta sobre la conexión de la burocracia con los ciudadanos para compartir información y crear una democracia realmente participativa. Imagina una «sociedad editable»...
viernes, 1 de marzo de 2013
Slides on Domain-Specific Languages
Slides on Domain-Specific Languages de Javier Canovas,muy bien explicado.
lunes, 28 de enero de 2013
DSL y requisitos. An agile vision
Markus Voelter nos explica en su libro "DSL Engineering" cómo usar DSL para capturar requisitos. Según mi opinión una visión para bastante agile
dslbook.org
...
There is a much better approach, though. Since today’s language workbenches support extremely rapid prototyping, you can actually build the DSLs interactively with the requirements owner. Since you are not capturing the specific requirements, but rather try to define how specific requirements are described, you essentially perform a domain analysis: you try to understand the degrees of freedom in the domain to be able
to represent the domain with the DSL19. Here is the process I have use successfully many times:
1. Have the requirements owner explain some particular aspect of the domain.
2. Try to understand that aspect and change your DSL so it can express that aspect.
3. Make the requirements owner try to express a couple of specific, but representative, requirements with the DSL
.
4. Most likely you will run into problems, some things cannot be expressed with the DSL. If so, go back to 1 and reiterate. A complete iteration should take no more than 60 minutes.
5. After half a day, stop working with the requirements owner and clean up/refactor the DSL.
6. Start another of the language design sessions with the requirements owner and iterate – over time, you should get closer to the DSL for the domain.
dslbook.org
...
There is a much better approach, though. Since today’s language workbenches support extremely rapid prototyping, you can actually build the DSLs interactively with the requirements owner. Since you are not capturing the specific requirements, but rather try to define how specific requirements are described, you essentially perform a domain analysis: you try to understand the degrees of freedom in the domain to be able
to represent the domain with the DSL19. Here is the process I have use successfully many times:
This is similar to what has been done with "analysis models" (back in the day . . . ). However, instead of drawing UML analysis diagrams, you capture the domain into a language definition, which makes it executable, in the sense that you can always turn around and have the requirements owner try to express specific requirements with the DSL you’re building, verifying the suitability of the DSL.
1. Have the requirements owner explain some particular aspect of the domain.
2. Try to understand that aspect and change your DSL so it can express that aspect.
3. Make the requirements owner try to express a couple of specific, but representative, requirements with the DSL
.
4. Most likely you will run into problems, some things cannot be expressed with the DSL. If so, go back to 1 and reiterate. A complete iteration should take no more than 60 minutes.
5. After half a day, stop working with the requirements owner and clean up/refactor the DSL.
6. Start another of the language design sessions with the requirements owner and iterate – over time, you should get closer to the DSL for the domain.
jueves, 17 de enero de 2013
TOP 10 Mistakes Companies Make When Conducting Business Rules Projects
Un artículo muy interesante sobre reglas de negocio.
http://www.brsolutions.com/BRS_10Mistakes.pdf
Mistake 1: Treating Business Rules Initiatives Simply as IT Projects
Mistake 2: Not Focusing on Terminology
Mistake 3: Assume Everyone Knows What a Business Rule Is
Mistake 4: Not Managing Business Rules from the Start
Mistake 5: Not Having the Right Business Infrastructure
Mistake 6: Not Having Strong Sponsorship
Mistake 7: Not Having a Well-Defi ned Scope
Mistake 8: Not Having the Right Skill Set
Mistake 9: Not Having a Business Rule Methodology
Mistake 10: Not Communicating
http://www.brsolutions.com/BRS_10Mistakes.pdf
Mistake 1: Treating Business Rules Initiatives Simply as IT Projects
Mistake 2: Not Focusing on Terminology
Mistake 3: Assume Everyone Knows What a Business Rule Is
Mistake 4: Not Managing Business Rules from the Start
Mistake 5: Not Having the Right Business Infrastructure
Mistake 6: Not Having Strong Sponsorship
Mistake 7: Not Having a Well-Defi ned Scope
Mistake 8: Not Having the Right Skill Set
Mistake 9: Not Having a Business Rule Methodology
Mistake 10: Not Communicating
martes, 4 de diciembre de 2012
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
Suscribirse a:
Entradas (Atom)