Dan's next transparency showed a circle similar to the one in the MSF Development Process Model, except it had three sections instead of four. "This is the MSF Design Process. It has three parts: Conceptual Design, Logical Design, and Physical Design. The three parts are staggered, parallel processes. In other words, before we finish Conceptual Design, we can begin Logical Design and work on them in parallel. The three are also interrelated, which means that if we decide to change something in Logical Design, for example, we need to go through Conceptual Design again to make sure the change is reflected there."
"What are the differences between the three parts?" asked Marilou.
"There are a number of differences, but basically, they are three different ways of looking at the same application. Conceptual Design is from the viewpoint of the user, Logical Design is from the viewpoint of the project team, and Physical Design is from the viewpoint of the developers.
"Another difference is the level of abstraction. The MSF Design Process is sort of like morphing software. We take something concrete—the users' needs, wants, and ways of doing things—and put that in at one end of the process. As this input goes through the process, it becomes transformed into an intermediate step, Logical Design, which is fairly abstract. Then we take that abstract model and transform it back into something concrete and physical—the final application. As we move through this concrete-abstract-concrete process, we have to ensure that the two ends of the process correlate; in other words, every feature of the application that comes out of Physical Design should be traceable through Logical Design back to something in Conceptual Design, and vice versa."
Jane was shaking her head. "This is beginning to sound like some of the philosophy courses I had in college. I'm getting lost already, and we haven't even gotten to the hard stuff. How about an example?"
"OK. This will be greatly simplified, but perhaps it will give us all a better grasp of the concepts involved. Let's take a small task that we should all do every day: backing up our data files. Jane, you do this manually. Tell us what you do."
Jane looked at Tim, somewhat embarrassed. "It's not because I don't trust your backups, Tim. When it comes to money and accounting, I'm just a belt-and-suspenders kind of gal."
Tim tried to look hurt. "I'm devastated. Hmm…think I'll drown my sorrows in another doughnut."
Jane laughed and then turned to Dan. "Well, it's pretty simple, really. I open up the data folder for our accounting package, sort by date, and copy all the files changed today to my Zip drive. Then I take the disk home with me."
"OK," said Dan as he made some notes. "Remember that in the conceptual part of the Design Process, we see the application from the viewpoint of the user. We do this by creating use cases and scenarios to describe everything the user does and how they do it. Later on, we'll see how use cases and scenarios interact. For now, let's describe Jane's backup process so that we can write an application to do it for her."
"Are we going to do a batch file, or a Visual Basic app, or what?" said Tim.
"At this point, we don't know and don't care," said Dan. "The choice of technology comes much later." He went to the whiteboard. "OK, someone take a shot at describing what Jane does."
Marta raised her hand. "It sounds like a two-step process: First she selects the files, and then she copies them to the Zip disk."
"You're leaving out a step," Bill said. "How does she select the files?"
"By date, of course," said Marta. "Oh, I see. She already knows the date, but the application would have to get it. So, we need to add an earlier step to get the date."
"Good." Dan added the step on the board. "Now, would everyone agree that this is a fairly accurate description of the application from the user's viewpoint?" Everyone nodded. "Since we agree, we can move on to Logical Design. If this application were larger, we might continue doing conceptual work on other bits of it. However, even though we were still working on Conceptual Design, as soon as we finished a description, we would send it on to Logical."
He erased the whiteboard. "Our job in Logical Design is to turn the descriptions we get from Conceptual Design into abstract entities called objects. We also need to discover what services are needed, what attributes are needed, and what the relationships are among the various services. You'll find definitions of these in your materials." While the rest of the team studied the definitions, Dan drew some boxes on the board and turned back to the group. "Now that you know what entities we're looking for, tell me some of the objects you see in our example."
"There are the files themselves," said Marta, drawing on her notepad as she spoke. "And the files have a Date Modified attribute that we're going to need."
Marilou added, "There's the User object, although I can't think of any services or attributes to go with it. There's the Get Date service. And, somewhere we're going to have to have a Copy Files service, but I can't figure out what object it belongs with."
Dan continued drawing on the board. "That's OK, Marilou. As you'll see in a moment, sometimes we create objects simply to hold the services we need." He finished what he was doing, then turned to the group. "Any other candidate objects or services?"
Bill had been sketching continuously since the discussion had begun. "It seems to me there are some other objects and services that are implied by the use cases we wrote," he said. "For example, the files themselves are part of a larger data store called the file system, which has its own services and attributes. Also, we need a Select Files service before we can use the Copy Files service. And what about error checking in case there's no disk in the drive, or something to make sure the files copied completely?"
Dan added Bill's descriptions to the board. "All excellent points, Bill. One of the steps in Logical Design is to discover any implied objects or services, which you've helped us to do. Now, let's take a moment to trace the use cases to the objects we've described and make sure we've covered everything."
The team spent a few minutes cleaning up the diagram, including drawing object boxes to hold some of the "orphan" services. They then drew arrows to show the flow of the application and to make sure their diagram worked properly. Finally, Dan said, "Does everyone understand, roughly, how the Logical model comes from the Conceptual model?" The team members nodded, so he continued.
"OK, at this point we're ready to move into Physical Design. Now we identify possible technologies for the application and consider their tradeoffs. The tradeoffs come from the differences between the physical requirements of the application and the physical constraints posed by the enterprise architecture and the current technologies. Who's got a candidate technology for our BJF application?"
"BJF?" asked Tim.
"Backup Jane's Files. We seem to run to acronyms for project names around here, so I wanted to be consistent. How about it, folks? What should we use to write this massive, enterprise app?"
Marilou spoke up immediately. "I vote for Visual Basic."
"Too much overhead," said Bill. "I'd do it with a batch file, preferably using 4DOS, which is a command.com substitute. It allows you to choose files by date within a batch file using a single command."
"Close, but no cigar, Old Man of the Sea," said Tim, grinning. "Batch file is the right track, but it needs more error-checking than 4DOS can give you, at least without going far out of your way. Besides, 4DOS isn't approved technology here. WinBatch is. It gives you a true Windows application, it's simple to write, it's easy to debug, and it can even be compiled!"
"Sounds like a winner," said Dan. "Tim's considered the tradeoffs, and he's locked into the enterprise architecture. What do you think, Bill?"
"I've never heard of this WinBatch, but if it does what he says, I agree it's probably the best candidate." Bill turned to Tim. "What I want to know, though, is how you know so much about it!"
"I use it all the time for automating little tasks around the office; been using it for years." Tim grinned. "Just because your folks have "Programmer" in their title, doesn't mean you're the only ones who know how to program! Some of us used to dabble in it, 'til we saw the light." He ducked as Bill's paper napkin whizzed over his head.
Dan laughed. "OK, Bill, don't wipe out our Network Manager. We might need him some day." Turning to Jane and Marta, who had been observing the technology discussion with bemused expressions, he said, "I know this may have been hard to follow, but don't let that worry you. Remember, Physical Design is from the viewpoint of the Development team, so they have to take the lead in working through the candidate technologies. When we come to Physical Design in RMS, I'll have some high-level material for you both so that you can follow the discussions and prepare your own deliverables."
Dan erased the whiteboard. "At this point, if we were really building the BJF app, we'd finalize the Physical model and then use it to complete the Functional Specification. Finally, we'd ask Development to do a project plan and a project schedule, then each of us would do our own project plan and schedule based on the one from Development. We'd put them all together, work out any conflicts or issues, meet with the customer to finalize and approve them, and we'd be done with the Planning Phase and ready to begin the developing Phase. Any questions or comments?"
Marta held up her hand and ticked off the steps. "Conceptual, Logical, Physical, Functional Spec, Project Plan, Project Schedule, done. Is that it?"
"Don't forget the revision of the Risk Assessment Document," added Jane.
"Got it," said Marta.