Abstract
This chapter introduces a list of analysis axes and characterizing dimensions for educational software engineering work. This list is meant to suggest questions whose answers may help to clarify raison d’être, matters of concern or objectives of work, in particular when addressing the zone within which occurs the education/CS interplay.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
In order to keep the text fluid we will stick to the educational software notion and term. Most of the issues addressed in this chapter do, however, also apply, mutatis mutandis, to pedagogical-setting support software as defined in Chap. 2.
- 2.
Part of this chapter takes its origins from research work conducted with Baker, M., Balacheff, N., Baron, M., Derycke, A., Guin, D., Nicaud, J.-F. & Rabardel, P. and disseminated as: Tchounikine, P. et al. (2004). Platon-1: quelques dimensions pour l’analyse des travaux de recherche en conception d’EIAH (in French). Public report (département STIC du CNRS).
- 3.
Verification consists of evaluating whether software functioning is correct; validation consists of evaluating whether software meets requirements.
- 4.
Wang, F. & Hannafin, M. J. (2005). Design-based research and technology-enhanced learning environments. Educational Technology Research and Development, 53(4), 5–23.
- 5.
The theoretical background related to the design process is addressed in Sect. 2.6.
- 6.
Elaborating an understanding is a very broad category that subsumes all others, but may be useful for denoting some projects at some level of granularity (elsewhere this is broken down into more precise categories) and/or at some period of a project’s history.
- 7.
IMS Learning Design (http://www.imsglobal.org/learningdesign/index.html; retrieved November 11, 2010).
- 8.
ADL Sharable Content Object Reference Model (http://www.adlnet.gov; retrieved November 11, 2010).
- 9.
IEEE Standard for Learning Object Metadata (http://ieeeltsc.org; retrieved November 11, 2010).
- 10.
IEEE Standard for Learning Technology Systems Architecture (http://ieeeltsc.org; retrieved November 11, 2010).
- 11.
Model Driven Architecture (http://www.omg.org/mda; retrieved November 11, 2010).
- 12.
As an example, within a research project focusing on (for example) how to implement a particular feedback mechanism, the choice of the application domain may be contingent, and governed by the available experimental setting. This is a frequent cause of misunderstandings between actors who are focusing on general mechanisms (e.g., feedback or diagnosis) and actors who are interested in the domain per se.
- 13.
Data analysis and interpretation are here dissociated from data elaboration, although they may be considered as particular cases.
- 14.
Data visualization is here dissociated from task achievement, although it may be considered as a particular case.
- 15.
The issue here is to solve the problem consisting of deciding what features will be made available at the software interface and how they may be presented or articulated, which is a different problem from that of designing the corresponding pieces of software.
- 16.
What is meant here is a task of a different nature from those (elaboration of data or managing access) dissociated above.
- 17.
If an effective system were to be considered, analysis of the theoretical background should be conducted in more detail, making explicit the involved theories and notions, how these theories are hybridized, the justification of the use of these theories for the considered setting, etc.
- 18.
The way such an external list of characteristics leads to another analysis of work is only illustrated to a very limited extent by the examples developed in Sect. 4 as we had already used these systems to illustrate different ideas. Moreover, such analyses only make sense when considering effective systems: conducted at an abstract level (which considering imaginary systems may lead to) the analysis may easily fall into a kind of categorization process, which is indeed not the objective.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2011 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Tchounikine, P. (2011). Characterizing the Design Context and the Software Artifact. In: Computer Science and Educational Software Design. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-20003-8_7
Download citation
DOI: https://doi.org/10.1007/978-3-642-20003-8_7
Published:
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-642-20002-1
Online ISBN: 978-3-642-20003-8
eBook Packages: Computer ScienceComputer Science (R0)