Assignment 4: You have just been hired as the head of a company's software development group. Your predecessor was fired because too many of the group's projects were behind schedule, over budget, or both. On your first day at this job, you realize that the group was not using any kind of formal development process. Write a 3-4 page paper comparing and contrasting these development methodologies: Synchronize and Stabilize, Extreme Programming, and the Rational Unified Process. Select the methodology that you would use, and explain why.
Prof S: it's highly likely that you'll get 24 papers that do pretty much the same thing: carefully summarize the features, advantages, and disadvantages of each methodology, then solemnly select one as 'the best.' I'm going to take a different tack. Without further ado - and with profuse apologies to Paramount Pictures Corporation and the estate of Gene Roddenbury - here is Star Trek: The Next Iteration.
Excerpt from The Lost Process (unaired episode)
"You wanted to see me, Captain?"
"Yes, Number One. Please, sit down. I have the results of the Captain's Investigation of the transporter accident that killed Lieutenant Babbage, the Lead Officer in the Software department."
"You mean the one where his head was found up his - "
"Fatally, yes. The transporter malfunctioned due to a software error; specifically," Picard read from his desktop display, "A data conversion error resulting in the replenerating frobnobdicator emitting radiation in excess of fatal levels."
"The software chief killed by a software error. How ironic. Sir."
"Quite. But that is only the beginning. The report goes on to say that examination of the department's records, where any could be found, revealed that none - not one - of their software projects in the past five years ever came in on time, on budget, or without significant faults. Commander Riker, we don't just need to replace a department head; we need that department to significantly change how it does its job. Figure out how, and report back to me."
[A few days later]
"Captain, I have three software development processes that can do what we ask. I'll describe each of them and you can decide."
"I'm glad to see that the concept of Completed Staff Work didn't die out with Napoleon. Proceed."
"Yes, sir. First, a little background. Traditional software development used what is called the 'waterfall' process. First, you figure out what the customer wants, then you design how you're going to do it, then you code it up, then you test it."
"What happens if the customer changes his mind while you're testing?"
"That's the primary flaw in the waterfall process. It's very difficult to go 'back' in the process and change anything without having a huge impact on other work you've already done. All three processes are designed to deal with this issue, although they do it in different ways. First, there is the 'synchronize and stabilize' process. The Microsoft Collective uses this method, and they just released Windows 2300. The company traces its roots to the 20th Century 'hacker' mentality, and they needed a process that can work without a whole lot of formal structure."
"That's hardly an appropriate concept for a Starfleet crew, is it?"
"It strikes a good balance between keeping control over the project and allowing the developers the most flexibility and creativity in completing their tasks. In the Planning Phase, the team works closely with the customer to establish exactly what features are desired. Then, again together with the customer, they prioritize those features. Based on this, the team forms subteams whose task is to implement each feature; each team comprises six to sixteen members, evenly split between developers and testers."
"One tester per developer? That ratio seems a bit high."
"What this does is allow continuous testing during the Development Phase. As parts of each feature are implemented, each day's code changes are combined into an interim version of the software called a build. Tests are run with each build, designed to catch any errors introduced since the last build."
"So that's the 'synchronize' part. What about 'stabilize'?"
"Every so often, the project goes through a Stabilization Phase, where a 'milestone' build is made, features are completed, and the developers fix most of the known errors. They then revisit the development phase and implement the next set of features."
"Most of the errors?"
"As each milestone progresses, fewer and fewer errors are allowed to remain unfixed. The goal is zero defects by the time of the final milestone. Another advantage of this method is that once the first milestone is passed, there is always a version 'good enough' to ship if necessary."
"It sounds like a lot depends on the features being independent and easy to define. What happens if that isn't the case?"
"Frankly, sir, that's where the process has problems, particularly if the project runs behind schedule and some features have to be dropped. If the features are tightly coupled, it's hard to know which features can be dropped. The process tries to mitigate this risk by being very careful about how features are defined."
"Hmmph. Tell me about the second process."
"It has the fairly odd name of Extreme Programming, and it concentrates on implementing small pieces of the problem quickly. Once again, the developers and the customer get together to decide what the product should do, breaking the product down into parts called 'stories.' The programmers estimate how long it will take them to implement each story, and the customer decides which stories need to be implemented in each release. Project resource allocation and scheduling can then be determined."
"Assuming that the programmers can accurately estimate how long it will take to implement each story. Based on their schedule performance to date, I think that's unlikely."
"Yes, sir. Programmers work in pairs, with one doing the code and the other simultaneously writing and executing the tests that the code must pass."
"Now that sounds wasteful."
"Proponents of XP claim that two programmers working together in such a way are more productive than one programmer working alone."
"I should hope that they would be more productive than two programmers working alone."
"The literature I read doesn't have much to say in that area, but it can be a good way to help new developers get up to speed quickly. The process also depends heavily on customer availability, both to help define functional tests and to help resolve important questions that come up during development."
"That shouldn't be a problem for us; we're the only ones using their products."
"Yes, sir. The process also looks to integrate new code changes quickly - at least daily - but if the software doesn't pass all its tests, any offending changes are discarded."
"That could lead to a lot of wasted effort."
"It's another reason why the process uses pair programming - the changes can be incrementally tested before they're thrown in with everybody else's. This is supposed to keep rework to a minimum. Proponents consider continuous testing the 'heart' of XP."
"So every iteration has its own set of tests? What happens to the old ones?"
"The old tests are run on every release."
"By hand? Wouldn't that eventually mean the developers would spend more time testing than coding?"
"The literature mentions running the tests automatically, but it doesn't detail how."
"That might be a good first project for the department - an automated test suite. Very well. You said there was a third process?"
"Yes, sir, the Rational Unified Process. It is also designed to develop software iteratively, but it puts more emphasis on visually modeling the software and keeping track of changes. The process is broken down into four phases. In the Inception phase, the scope of the product and the external entities that the product works with are defined. The use cases, descriptions of how the product behaves, are identified, and a few of the important ones are fully fleshed out. Any known risks in the project are identified. A project plan is produced, including what use cases will be implemented in which iteration. Some prototypes may also be written, depending on the product.
In the Elaboration phase, the basic architectural structure is created, the rest of the use cases are defined and the more important ones are prototyped, the project plan is refined, and the high-risk items are addressed. The end of this phase is where the 'go / no-go' decision is made."
"Why there?"
"Because it should be known by then whether the product can be completed with the resources available. It also represents the transition from a large effort by a few people to a large effort by a lot of people. In the Construction phase, the rest of the use cases are coded and integrated, and all features are tested. If the work in the first two phases was done properly, there aren't any serious 'gotchas' lurking around the corner."
"That sounds suspiciously like the waterfall model."
"It sounds like it, but remember that each phase is performed inside one iteration of the project. You finish the last phase - the Transition phase, where final testing and error correction is performed, as well as building versions of the product for each environment it will operate in - and you start over on the next iteration with the Inception phase."
"I think that one sounds best, particularly since it emphasizes being able to model the software so you can see what it's supposed to do without having to know each line of code in detail. How would we go about implementing it?"
"Actually, it's a whole suite of development tools that you purchase from Rational Software Corporation."
Picard frowned. "That may pose a problem. I got a call this morning from Commodore Ballmer at Starfleet Accounting. It would seem that he received a copy of my report on the department, and I don't think he would be well disposed to paying someone a large sum of money just so we can get our software development process under control. 'Throwing good money after bad,' I think his exact words were."
"Might I suggest, sir, that given the current state of the department, where the developers aren't accustomed to any process at all, that the process closest to the hacker mentality would be the place to start? 'Synchronize and stabilize' would allow control of the process while minimizing the impact on the developers' freedom and creativity. Maybe later, after we show some progress, we might re-evaluate the Rational Unified Process."
"Perhaps, but if 'synchronize and stabilize' works, I don't think we would want to switch. What is the experience level of our developers?"
"We have a mix of all experience levels, from ensigns fresh out of the Academy to a couple of graybeards that I think learned under Grace Hopper."
Picard regarded Riker quizzically.
"Never mind, sir. I was going to suggest that because of this, we use part of XP's pair programming technique, at least with the new graduates, until they get up to speed."
"Agreed. Anything else?"
"It's not explicitly mentioned in any of this literature, but I learned of the idea of having each change examined by other members of the development team, both to catch errors before release and to provide a kind of 'cross-training' where developers can become familiar with each others' code. The idea is called peer review."
"Then include that as well. Now who do we put in charge of the department?"
"I think Lieutenant Worf would be ideal for the job, sir."
"A Klingon in charge of software development? Good Lord, Number One, we want to improve our software development, not scare our programmers to death!"
"I think his presence would serve as a deterrent to anyone complaining about the process, sir."
"Very well. Make it so."
This is a work of parody. Characters and settings mentioned herein are from Star Trek: The Next Generation, which is property of Paramount Pictures Corporation.
Epilogue: Unbeknownst to Commander Riker and Captain Picard, Lieutenant Worf tailored the software development process somewhat. http://ftp.logica.com/~stepneys/joke/klingon.htm revealed this list:
Back to the Reserved Space.