2 Oct 96.c
Rob Phillips
The Development Process:
The "Contribution of the Day" Award goes to Ameeta D. Jadav [2 Oct 96].
Thank you for saving me a lot of work! Many of the points you made in your post were ones that I would have made myself. So, lurkers, please read Ameeta's post again, carefully. I won't comment on most of her points, because I agree with them. However, the main design points she made are summarized below:
- Insist on a clear brief.
- Spend time on team orientation
- Build in more time for design
- Use an efficient project execution model
- Build in frequent project reviews
- Make quality assurance an ongoing process
- Take documentation seriously
A typical project goes through phases of design, production, implementation, and maintenance. There haven't been many comments about production other than it taking too long, but there have been some about the other two.
Design
One of the key points of our model for developing educational IMM is to go through a very thorough design process before starting production. Some of the points made below will bear out why we do this:
[quoting Quinn, 1 Oct 96] it was insufficiently planned, needed more specification before implementation. ... The whole thing needed better management.
[quoting Moller, 1 Oct 96] Design faults always surface afterwards because academic staff members, as subject matter experts, need to adapt to the way the instructional designer works and visa versa. The ideal situation is, however, to do a second project with the same staff member because then everyone know what is expected.
If you did not start development until the design is acceptable to all team members, you wouldn't waste the entire first project. It seems very inefficient to develop an entire project before getting the design and team model right. See comments below on prototypes and the associated post to follow on commitment.
[quoting Morrison, 1 Sep 96] The team was small, two chemists, myself as designer, a graduate assistant in chemistry, and a graduate assistant in ID. We developed a rather streamlined strategy for designing the instruction after about three months. Either the ID graduate assistant or I worked with the two chemist to design the instruction. The graduate assistant prototyped the materials in HyperCard and then made printed copies of each card for the chemist to review. (You only allow them to make changes in a stack once before learning of how difficult it is to determine what they changed!)
(ASIDE: Yes, we had content experts changing text in one project too. It seemed harmless, until strange bugs started appearing. They were resizing fields on the background to make the text fit better. What they didn't realize was that the resizing was also occurring in 20 other unrelated screens. It was all the programmer's fault, of course!)
Once we had an approved prototype which had the same screen design as the finished product, it was sent to the programmer. The programmer and his team then created the "final" product in a compiled language.
Yes. SEPARATE DESIGN FROM PRODUCTION.
The greatest amount of time was spent on the design phase, followed by the prototyping and formative evaluation. The least amount of time was spent on the programming. The programmer was literally able to copy and paste our cards into his design. Ample instructions were given about links, navigation, and animations to make this costly task very efficient.
The first project we did with our current development methodology was on Carbohydrate metabolism (one hour of student work). Essentially the same team was involved in a previous project, so we had some things going for us. The initial project meeting was in November of 1993. We went over and over the design for months until we had a very detailed storyboard. Programming started in late March 1994 and finished in late April. We didn't touch the computer for programming until March, although some graphics had been prepared. The development took approximately 300 hours, made up as follows:
| Content | 120 hours |
| Programming | 75 hours |
| Graphics | 75 hours |
| Project Management | 30 hours |
Even better, it only needed five hours of debugging, and has run faultlessly ever since.
[quoting Jadav, 2 Oct 96] Did parts of it turn out differently than you envisaged? Yes, very much so--especially when we did not spend enough effort on a clear brief and a rigorous design. While on one hand, this has time and budget implications, it also has an impact on the morale of the team. I am a proponent of Michael Allen's development model of Successive Approximation.
Can you elaborate on this model and perhaps provide a reference, please?
Prototypes
[quoting Anonymous, 1 Oct 96] Any team software development can really stretch the team's harmony. Do not hold onto what you hold dear too tightly. I can spend many hours designing a form, thinking that it is "just so," admiring the functionality built-in, proud of what I have done only to have it dashed when someone points out something like: "It looks fine at that resolution, what does it look like at a higher resolution?"
One of our programmers also has this attitude. However, it is important not to get too attached to your ideas. This is difficult, because all members of the team have a creative investment in their work. But, it IS important. Prototypes should be small and just used to test concepts. When they are finished, it is often appropriate to simply throw them away and start coding from scratch.
[quoting Jadav, 2 Oct 96] Build in more time for design: Many a time, we succumb to the client's need to "see" something quickly--and they don't like seeing paper prototypes! So, we cut short the initial design stage and jump right into production. The initial design stage needs to explore a variety of instructional approaches (has anyone out there discovered the single most right way for instruction?!!), a variety of graphics styles, user-interface philosophy and designs, media usage, etc. The eventual outcome of this stage would be the prototype (or two)--and this takes time. But, experience tells me that this is time well spent. It prevents eventual extensions of deadlines, frequent design changes, variation in content scope, and so on. Most importantly, it gives the project team confidence in what they are building. Rigor at the design stage is well worth everyone's time and effort. And maybe (just maybe), even the client will like you better at the end of it all.
There is an understandable urge on the part of the development team, especially inexperienced members, to view what the finished product will look like. However, our experience is that this approach can be wasteful of resources. It is essential that the development team have a shared vision of the outlook of the finished product, but this should be achieved with as little production effort as possible. This is the key point of our development methodology--to separate the Design Process from the Production Process.
An incremental prototyping model has the potential to be extremely wasteful of resources. There is a tendency to design and develop prototypes which include drafts of a substantial amount of content. This might include the entire navigational structure, and substantial amounts of content screens. The prototype is subsequently evaluated and design deficiencies noted. Perhaps some topics in the hierarchy need to be moved and some navigation controls need to be altered. With a prototype of fifty or so screens, it can take significant time to make these modifications.
A project I was involved in on Understanding Technical Drawings is a typical example of this approach. Early designs identified the number and types of screens, and these were created, waiting for content to be prepared for them. The first prototype highlighted significant problems with the content structure and navigation, and substantial modifications were required. This process continued as more and more content was designed and prepared.
After three major revisions and countless minor ones, the project had grown to over 400 screens, and it was decided that some of the content had to be pruned. At this stage, however, it was very difficult to identify which parts to cut, because it was difficult to form an overview of the program as a whole.
Most of the design process was being implemented in full on the computer before being finalized. In essence, it was not prototypes that were being produced, but a series of supposedly finished products. Over 400 hours were spent in this cycle, and many of these could have been saved by finalizing the design before starting production. The point of a prototype is that changing it requires little effort, unlike the full-blown program that had been produced here.
Documentation
[quoting Ramondt, 30 Sep 96] I would also be much more structured in my project management, but I believe that continuity would have taken care of a significant number of our project management problems. As it is, we pick it up and go: "Where were we again?"
Later in the week I will comment more about ways of documenting a project and how important it is.
Implementation and Maintenance
[quoting Fyte, 30 Sep 96] ...we had no idea about the follow-up, debugging, etc., we would need to do, and like with so many things, there were glitches which didn't show up until the program was being used in a large class with a part-time tutor at 6 p.m. We didn't have a fool-proof record management of debugging, and we hadn't allocated teaching release time to sorting it out.
See the post on Roles in IMM Development [Phillips, 2 Oct 96.a]. The project doesn't finish when the programmer thinks he or she has got rid of all the bugs on the version on their computer.
[quoting Anonymous, 1 Oct 96] 1. If you are designing a system to be run in a network or multi-user environment do as much of the development and testing in the target environment. Too often performance issues, file locking, access permissions, etc., do not come to light until after implementation. From then on, whatever you do is only patching up. Design these features into the project.
The way to reduce the need for ongoing maintenance is to do the feasibility study up front. You need to be aware of the sorts of problems Anonymous has identified.
In "regular" software development, the feasibility study has been finished before the design and development starts. However, it is difficult to perform a full feasibility study of an IMM project, because clear definition of the project often does not occur until late in the development cycle. Instead, the team needs to be aware of implementation and maintenance issues throughout the design and production cycles.
[quoting Jadav, 2 Oct 96] But yes, my initial projects plans took too many things for granted and were way off on time, people, and budget estimates.
Let's finish with Ameeta as well. Lots of us can sympathize with your sentiments here!