Article Summary #5: Douglas – Issues in Software Engineering of Relevance to Instructional Design

Douglas, I.  (2006).  Issues in software engineering of relevance to instructional design.  TechTrends 50(5), 28-35.

In this article, Ian Douglas describes how the principles of software development, including OS design models, are relevant to the design and development of instructional materials.  The article identifies areas of current work and leads to ideas for applications of design ideas outside of their native fields.


Douglas begins by clarifying the difference between software engineering and programming.  He says that many people assume they are the same thing, but that is like saying that instructional design is nothing more than the creation of powerpoint slides.  Software engineering was traditionally a linear process, but has evolved in many development houses to an iterative process involving rapid prototyping.  Most instructional design work, however, is stuck in the linear model.

Douglas describes the capability maturity model (CMM) that was developed at Carnegie Mellon’s Software Engineering Institute to evaluate software development approaches.  This model identifies five levels that an organization may reach.  In the Initial stage, work is done in a haphazard manner with little or no process management.  In the Repeatable stage, a process is specified so that successful development habits can be formed and used repeatedly.  In the Defined stage, the process is documented and standardized.  Someone, or some group, is given responsibility for maintaining the documentation of the process and making sure everyone understands and follows the specified development process.  In the Managed stage, the development process itself is evaluated and steadily improved.  The efficiency of the process is monitored, and areas for improvement are identified.  In the Optimized level, improvements in development process are shared rapidly throughout the organization.  Bidders on government contracts are required to have reached the Defined stage in order to secure government contracts.

The traditional model of software development is represented by the ADDIE acronym:  Analyze, Design, Develop, Implement, and Evaluate.  In closed development models, the only public stage is implementation.  OS is different in that all aspects of the development process may be open to public input, and each iteration ends with a code release, either as a development version or as a stable version.  In closed designs, most iterations are done in-house, and only a few, hopefully stable, public releases are made.

The Agile Manifesto describes models that are meant to be lighter than the ADDIE model.  These methods are said to be adaptive and people oriented rather than predictive and process oriented.  Extreme programming is mentioned as an example of an agile design methodology.  Its four core values are communication, feedback, simplicity, and courage.

Learning objects are educational parallels of object-oriented programming.  In object oriented programming, we aim to make reusable, discrete parts of programs.  This enables the re-use of code, ease of maintenance, and speed of new development.  When actual code is not reusable, we can identify reusable patterns.  Patterns are pieces of design knowledge rather than actual artifacts like code.  If we are not going to reuse actual code, we should at least identify the best design examples, and reuse these designs until they are improved upon.

Douglas describes UML, a unified modeling language that was developed to give software engineers a common way of speaking with each other around design issues.  This common language has facilitated the evaluation of software designs before the coding phase has progressed too far.

Evaluation and Educational Relevance

The capability maturity model (CMM) was developed to evaluate software engineering processes, but it can be used to examine instructional design processes as well (and many other design fields).  Every teacher is an instructional designer, and every school is a collection of designers.  Even if we use packaged curriculum, we still integrate different pieces of packaged curriculum, and design its delivery.  As designers, we can ask ourselves where we and our schools fall on the CMM scale.  In an honest evaluation, most schools would be on the initial level while some individual teachers will be on the repeatable level.  Any school without a central, accessible, and well-used repository of staff-developed curriculum is stuck in the initial level.  Many teachers repeat their best lessons and projects from year to year, but few of these teachers have identified a formal process for the revision and documentation of their curriculum.  Looking at the instructional design industry from a CMM perspective Douglas wrote, “It would be interesting to speculate how many organizations involved in producing instruction would score the equivalent of a Level 5 [Optimized]” (p. 29).

While many teachers may recognize their own informal use of the ADDIE model, few schools have implemented any formal curriculum development model.  It is worth reiterating that even a school which is only choosing a set packaged curriculum is still designing an instructional experience for its students.  Several ideas from the extreme programming model may be relevant to school-based instructional design.  One is the set of values – communication, feedback, simplicity, and courage.  Teachers who have clear communication with their students, colleagues, and administrators are in a more comfortable position to try to improve existing curriculum or develop new curriculum.  Even around complex topics, the progression of learning experiences should be simple.  A non-expert in the field should be able to recognize the development of learning that should take place in well-designed curriculum.  Finally, courage is needed to try to implement new projects.

A larger idea from extreme programming is the concept of collective ownership of that which is developed.  Douglas wrote, “This is a refinement of an earlier concept of ego-less programming, where there is collective responsibility for the system quality irrespective of individual work assignments” (p. 30).  As teachers, we often feel responsible only for the learning in our classrooms.  Schools become significantly more effective when teachers make the transition to thinking of their staff as a whole, and take collective responsibility for pedagogical excellence.

The tiered architecture model that developed out of object oriented programming has interesting suggestions for education.  In this approach, software is broken into a boundary (the interface, a GUI for example), the control (logic and processing), and the data storage.  We can aim to find a similar breakdown of functions in education.  A simple parallel might be viewing the context of instruction as the boundary, and the content, skill, idea, or knowledge as the data to be stored.  The logic is the thinking, the way we encourage students to put new knowledge together with their prior understanding.  This decoupling of pedagogical functions helps because the content changes little, the thinking changes some, and the context changes frequently.  Often times when the context changes we rethink the content and thinking aspects as well.  We may be able to minimize our rethinking of curriculum if we can adopt a similar, layered approach to instructional design, only changing the parts that need to be updated in a new curriculum implementation.  As Douglas suggests, “The currently amorphous concept of the learning object may have to evolve into a taxonomy of learning-related objects with at least a definite separation between learning content and its presentation [italics added]” (p. 32).

Douglas’ description of UML and its effect on making software design more efficient suggests the development of an Educational Markup Language (EML).  Wired magazine ran an article about a business-focused markup language, XBRL, that makes financial data more transparent and usable to everyone from industry experts to the reasonably educated public.  Financial data that took 70 days for regulators to analyze before the required implementation of XBRL took 2 days to analyze after implementation.  One could easily think of a small set of tags that are educationally relevant, from topic tags such as mathematics, exponents, and area to tags that represent sections in a lesson plan such as guiding questions, materials, and state standards.  With the use of this language, one lesson plan could be used in many different contexts, for many different audiences.  This is similar to the manner in which pathways in VUE allow one concept map to be used in many different ways.  A well-implemented scheme such as this seems to be missing from existing lesson plan repositories like Curriki.  The only place I have seen it so far in education is the closed set of descriptors in the ERIC database, the meaning of which most graduate students do not seem to grasp.

Finally, Douglas describes computer-aided software engineering (CASE).  He says that while many developers make automation tools for their customers, they use few automation tools themselves.  He describes high and low versions of CASE.  High-level CASE programs assist in analysis and design, while low-level programs assist in coding and debugging.  A similar kind of distinction could be made in education.  We could have computer-aided lesson planning (CALP).  Most teachers use nothing more sophisticated than a word processor for developing their lesson plans.  High-level CALP would assist in large-scale curriculum mapping and design; low-level CALP would assist in developing daily lesson plans, and lessons around small sets of learning objectives.  A useful piece of software might generate a daily lesson plan from a unit plan, with its only input being how far you got the previous day in the unit.


Douglas offers some concise closing thoughts:

If the barriers of jargon can be overcome, it may become apparent that many of the issues in design-related disciplines are the same, and there is great potential for sharing knowledge.

I would urge instructional designers to look beyond their own journals and conferences for reusable “objects” of knowledge that exist in other domains. (p. 35)

This article offers rich food for thought.


One Response to “Article Summary #5: Douglas – Issues in Software Engineering of Relevance to Instructional Design”

  1. Skip Says:

    You’ve touched on an issue that I think plagues most schools and school districts in terms of instructional design and delivery. We tend to confuse curriculum and instruction.

    I think curriculum and instruction are distinctly different elements of the process of teaching and learning that goes on in any classroom. I’d define curriculum as the content that needs to be taught–the Industrial Revolution, simplifying fractions, etc.–the “data to be stored,” as you mentioned in your review. Instruction is the process of how this content is delivered. Most schools do a good job of defining curriculum, but few do a great job of managing and delivering instruction. Districts will buy curriculum materials, and those materials often dictate how instruction happens. As a teacher, you get a science book, and your tendency is to have students read the chapters, do the exercises, and answer the questions at the end. Even worse, districts buy “canned” instructional packages (Everyday Math is the current example in the Fairbanks North Star Borough district) which require the teacher to follow a specific instructional process from a teacher’s guide and which most districts implement by requiring that all teachers in the district be on the same page on the same day. Douglas puts it well: “The currently amorphous concept of the learning object may have to evolve into a taxonomy of learning-related objects with at least a definite separation between learning content and its presentation.”

    We often hear the phrase “integrating technology into the curriculum,” but this makes sense to me only if you are thinking of technology as a subject to be studied and not as an instructional tool. The use of technology in the teaching and learning process should be part of the instructional design, not part of the curriculum. Technology presents teachers with so many opportunities to differentiate instruction for their students,. In my view, it’s almost irrelevant to speak of technology as a curriculum tool.

    Excellent review, Eric. Your insights are greatly appreciated.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: