Week 4 Assignment - Software Development PlanScenario-Your team has be.docx
1. Week 4 Assignment - Software Development Plan
Scenario:
Your team has been tasked with delivering a Section 508-validated application for U.S.
Department of Homeland Security field officers to check potential immigrants for connections to
criminal or terrorist behavior. This application must meet these requirements:
· Conform with Section-508 accessibility guidelines.
· Allow wireless real-time bidirectional data transfer and database queries with secure servers.
· Have a secure login and, after two minutes of non-use, have autolocking that reactivates a
secure login.
· Allow for officers working on any day and at any time in offices, from vehicles, and on foot
along the U.S. border and in cities across the country.
Overview
In Week 2, you defined how you will determine user applicability and needs. This week, you
will map out a plan for your project.
Instructions:
Create a 2–3-page software development plan for the application you are developing. Include
the following:
· List 8–10 steps the project will follow from proposal to post-implementation stages for
proper design of the application. Be sure to account for all application constraints in the project
planning steps.
· Explain the outcome, process, and resources involved in accomplishing each step. Incorporate
at least 3 credible and relevant resources to support your statements.
· Create a Gantt chart that includes each step in the process, the resources involved, and the
estimated duration of time it will take to complete each step. It is recommended that you use
Microsoft Excel to create your chart. You may copy and paste it into your software development
plan document or submit a separate file.
· Remember, your audience is your company’s IT executive. Your writing should be
professional and free of grammar, punctuation, and spelling errors.
Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis,
design, implementation, test) to the shorter, iterative devel- opment cycles within, for example,
3. tu re
Analysis
Design
Implementation
Test
Time
Scope
IterativeWaterfall XP
(c)(b)(a)
October 1999 71
We might get a picture like the one shown in Figure 1c. It’s called Extreme Programming.
ANATOMY OF XP XP turns the conventional software process side-
ways. Rather than planning, analyzing, and design- ing for the far-flung future, XP exploits the
reduction in the cost of changing software to do all of these activities a little at a time, throughout
software devel- opment. (The “XP Practices― sidebar will give you a quick grasp of the
practices and philosophy underly- ing XP. These practices are designed to work together, and
trying to examine any one soon leads you to the rest. The “Roots of XP― sidebar on page
73 traces the historical antecedents of these practices.)
XP development cycle Figure 2 shows XP at timescales ranging from years
to days. The customer picks the next release by choos- ing the most valuable features (called
stories in XP) from among all the possible stories, as informed by the costs of the stories and the
measured speed of the team in implementing stories.
The customer picks the next iteration’s stories by choosing the most valuable stories
remaining in the release, again informed by the costs of the stories and the team’s speed. The
programmers turn the stories into smaller-grained tasks, which they individually
XP Practices
Here is a quick summary of each of the major practices in XP.
4. Planning game. Customers decide the scope and timing of releases based on estimates provided
by program- mers. Programmers implement only the functionality demanded by the stories in
this iteration.
Small releases. The system is put into production in a few months, before solving the whole
problem. New releases are made often—anywhere from daily to monthly.
Metaphor. The shape of the system is defined by a metaphor or set of metaphors shared between
the cus- tomer and programmers.
Simple design. At every moment, the design runs all the tests, communi- cates everything the
programmers want to communicate, contains no
duplicate code, and has the fewest possible classes and methods. This rule can be summarized as,
“Say everything once and only once.―
Tests. Programmers write unit tests minute by minute. These tests are col- lected and they must
all run correctly. Customers write functional tests for the stories in an iteration. These tests
should also all run, although practi- cally speaking, sometimes a business decision must be made
comparing the cost of shipping a known defect and the cost of delay.
Refactoring. The design of the system is evolved through transformations of the existing design
that keep all the tests running.
Pair programming. All production code is written by two people at one screen/keyboard/mouse.
Continuous integration. New code is integrated with the current system after no more than a few
hours.
When integrating, the system is built from scratch and all tests must pass or the changes are
discarded.
Collective ownership. Every program- mer improves any code anywhere in the system at any
time if they see the opportunity.
On-site customer. A customer sits with the team full-time.
40-hour weeks. No one can work a second consecutive week of over- time. Even isolated
overtime used too frequently is a sign of deeper problems that must be addressed.
Open workspace. The team works in a large room with small cubicles around the periphery. Pair
programmers work on computers set up in the center.
Just rules. By being part of an Extreme team, you sign up to follow the rules. But they’re just
the rules. The team can change the rules at any time as long as they agree on how they will
assess the effects of the change.
5. accept responsibility for. Then the programmer turns a task into a set of test
cases that will demonstrate that the task is finished. Working with a partner, the programmer
makes the test cases run, evolving the design in the meantime to maintain the simplest possible
design for the system as a whole.
Stories XP considers the period before a system first goes
into production to be a dangerous anomaly in the life of the project and to be gotten over as
quickly as pos- sible. However, every project has to start somewhere.
The first decisions to make about the project are what it could do and what it should do first.
These deci- sions are typically the province of analysis, hence the thin blue analysis rectangle at
the top of Figure 1c. You can’t program until you know what you’re program- ming.
You put the overall analysis together in terms of stories, which you can think of as the amount of
a use case that will fit on an index card. Each story must be business-oriented, testable, and
estimable.
A month is a good long time to come up with the stories for a 10 person-year project. It’s
true that it isn’t enough to explore all of the possible issues thor- oughly. But forever
isn’t long enough to explore all of the issues thoroughly if you never implement.
72 Computer
Release Notice in Figure 2 that we don’t implement all of
the stories at first. Instead, the customer chooses the smallest set of the most valuable stories that
make sense together. First we implement those and put them into production. After that we’ll
implement all the rest.
Picking the scope for a release is a little like shop- ping for groceries. You go to the store with
$100 in your pocket. You think about your priorities. You look at the prices on the items. You
decide what to buy.
In the planning game (the XP planning process), the items are the stories. The prices are the
estimates on the stories. The budget is calculated by measuring the team’s output in terms of
estimated stories delivered per unit time.
The customer can either load up a cart (pick a set of stories) and have the programmers calculate
the finish date or pick a date and have the programmers calcu- late the budget, then choose
stories until they add up.
Iteration The goal of each iteration is to put into production
6. some new stories that are tested and ready to go. The process starts with a plan that sets out the
stories to be implemented and breaks out how the team will accomplish it. While the team is
implementing, the customer is specifying functional tests. At the end of the iteration, the tests
should run and the team should be ready for the next iteration.
Iteration planning starts by again asking the cus- tomer to pick the most valuable stories, this
time out
of the stories remaining to be implemented in this release. The team breaks the stories down into
tasks, units of implementation that one person could imple- ment in a few days. If there are
technical tasks, like upgrading to a new version of a database, they get put on the list too.
Next, programmers sign up for the tasks they want to be responsible for implementing. After all
the tasks are spoken for, the programmer responsible for a task estimates it, this time in ideal
programming days. Everyone’s task estimates are added up, and if some programmers are
over and some are under, the under- committed programmers take more tasks.
Over the course of the iteration, the programmers implement their tasks. As they complete each
task, they integrate its code and tests with the current system. All tests must run or the code
cannot be integrated.
As the customer delivers the functional tests dur- ing the iteration, they are added to the suite. At
the end of the iteration, all unit tests and all functional tests run.
Task To implement a task, the responsible programmer
first finds a partner because all production code is writ- ten with two people at one machine. If
there is any question about the scope or implementation approach, the partners will have a short
(15-minute) meeting with the customer and/or with the programmers most knowledgeable about
the code most likely to be touched during implementation.
Release
Years
Months
Weeks
Days
Iteration
Implementation
Stories
7. Tasks
Tests
Figure 2. XP according to various timescales. At the scale of months and years, you have the
stories in this release and then the stories in future releases. At the scale of weeks and months,
you have stories in this iteration and then the stories remain- ing in this release. At the scale of
days and weeks, you have the task you are working on now and then the rest of the tasks in the
iteration. And at the scale of minutes and days, you have the test case you are working on now
and then the rest of the test cases that you can imagine.
From this meeting, the partners condense the list of test cases that need to run before the task is
done. They pick a test case from the list that they are confident they can implement and that will
teach them some- thing about the task. They code up the test case. If the test case already runs,
they go on. Normally, though, there is work to be done.
When we have a test case and it doesn’t run, either
• we can see a clean way to make it run, in which case we make it run; or
• we can see an ugly way to make it run, but we can imagine a new design in which it could be
made to run cleanly, in which case we refactor the system to make it run cleanly; or
• we can see an ugly way to make it run, but we can’t imagine any refactoring, in which
case we make it run the ugly way.
After the test case runs, if we see how to refactor
the system to make it even cleaner, we do so. Perhaps during the implementation of this test case
we imagine another test case that should also run. We note the new test case on our list and
continue. Perhaps we spot a bigger refactoring that doesn’t fit into the scope of our current
test. We also note that and continue. The goal is to remain focused so we can do a good job and
at the same time not lose the ben- efits of the insights that come during intense interac- tion with
code.
Test If there is a technique at the heart of XP, it is unit
testing. As you saw above, unit testing is part of every programmer’s daily business. In XP,
however, two twists on conventional testing strategies make tests far more effective:
Programmers write their own tests and they write these tests before they code. If pro- gramming
is about learning, and learning is about get- ting lots of feedback as quickly as possible, then you
October 1999 73
Roots of XP
8. The individual practices in XP are not by any means new. Many people have come to similar
conclusions about the best way to deliver software in environ- ments where requirements change
vio- lently.1-3
The strict split between business and technical decision making in XP comes from the work of
the architect Christo- pher Alexander, in particular his work The Timeless Way of Building,4
where he says that the people who occupy a struc- ture should (in conjunction with a build- ing
professional) be the ones to make the high-impact decisions about it.
XP’s rapid evolution of a plan in response to business or technical changes echoes the Scrum
methodology5 and Ward Cunningham’s Episodes pattern language.6
The emphasis on specifying and sched- uling projects from the perspective of fea- tures comes
from Ivar Jacobson’s work on use cases.7
Tom Gilb is the guru of evolutionary delivery. His recent writings on EVO8
focus on getting the software into pro- duction in a matter of weeks, then grow- ing it from there.
Barry Boehm’s Spiral Model was the initial response to the waterfall.9 Dave
Thomas and his colleagues at Object Technology International have long been champions of
exploiting powerful tech- nology with their JIT method.10
XP’s use of metaphors comes from George Lakoff and Mark Johnson’s books, the latest
of which is Philosophy in the Flesh.11 It also comes from Richard Coyne, who links metaphor
with soft- ware development from the perspective of postmodern philosophy.12
Finally, XP’s attitude toward the effects of office space on programmers comes from Jim
Coplien,13 Tom DeMarco, and Tim Lister,14 who talk about the impor- tance of the physical
environment on pro- grammers.
References 1. J. Wood and D. Silver, Joint Application
Development, John Wiley & Sons, New York, 1995.
2. J. Martin, Rapid Application Development, Prentice Hall,Upper Saddle River, N.J.,1992.
3. J. Stapleton, Dynamic Systems Develop- ment Method, Addison Wesley Longman, Reading,
Mass., 1997.
4. C. Alexander, The Timeless Way of Build- ing, Oxford University Press, New York, 1979.
5. H. Takeuchi and I. Nonaka, “The New Product Development Game,― Harvard
Business Rev., Jan./Feb. 1986, pp. 137- 146.
9. 6. W. Cunningham, “Episodes: A Pattern Language of Competitive Development,― Pattern
Languages of Program Design 2, J. Vlissides, ed., Addison-Wesley, New York, 1996.
7. I. Jacobsen, Object-Oriented Software Engineering, Addison-Wesley, New York, 1994.
8. T. Gilb, Principles of Software Engineer- ing Management, Addison-Wesley, Wok- ingham,
UK, 1988.
9. B. Boehm, “A Spiral Model of Software Development and Enhancement,― Com- puter,
May 1988, pp. 61-72.
10. D. Thomas, “Web Time Software Devel- opment,― Software Development, Oct. 1998,
p. 80.
11. G. Lakoff and M. Johnson, Philosophy in the Flesh, Basic Books, New York, 1998.
12. R. Coyne, Designing Information Tech- nology in the Postmodern Age, MIT Press,
Cambridge, Mass., 1995.
13. J.O. Coplien, “A Generative Development Process Pattern Language,― The Patterns
Handbook, L. Rising, ed., Cambridge Uni- versity Press, New York, 1998, pp. 243- 300.
14. T. DeMarco and T. Lister, Peopleware, Dorset House, New York, 1999.
74 Computer
can learn much from tests written by someone else days or weeks after the code. XP primarily
addresses the accepted wisdom that programmers can’t possibly test their own code by
having you write code in pairs.
Some methodologies, like Cleanroom,1 prohibit programmers testing or in some cases even
com- piling their own programs. The usual process has a programmer write some code, compile
it, make sure it works, then pass it on to a testing organiza- tion. The bench testing takes the form
of single- stepping through the code and watching variables, or interpreting the results of print
statements, or poking a few buttons to make sure the list item turns green.
The XP testing strategy doesn’t ask any more work than the usual bench testing strategies. It
just changes the form of the tests. Instead of activities that evapo- rate into the ether as soon as
they are finished, you record the tests in a permanent form. These tests will run automatically
today, and this afternoon after we all integrate, and tomorrow, and next week, and next
year. The confidence they embody accumulates, so an XP team gains confidence in the behavior
of its sys- tem over time.
As I mentioned earlier, tests also come from the cus- tomers. At the beginning of an iteration, the
customers think about what would convince them that the sto- ries for an iteration are completed.
11. When we first started with XP, some of the developers did not want to follow it. They felt that it
would hurt their devel- opment style and that they would not be as productive. What happened
was that their pieces of the application were pro- ducing the most problem reports. Since
they were not developing in pairs, two people had not designed the subsystem and their skills
were falling behind the other developers who were learning from each other. Two well-trained
developers working together and with the rest of the team will always outperform one “intel-
ligent― developer working alone.
A misconception about XP is that it sti- fles your creativity and individual growth. It’s
actually quite the contrary. XP stimu- lates growth and creativity and encourages team members
to take chances. The key is to decide the direction of the corporation and stand behind the hard
decisions.
XP is not extreme to our team. It’s a method that uses a common-sense devel- opment
approach. Everyone works to- gether toward a common goal.
Team: managers, business ana- lysts, developers, testers, and technical writers
Application: campaign manage- ment dbase
Time: three years
October 1999 75
Underestimation From time to time you will commit to more than
you can accomplish. You must reduce the occurrence of underestimation as much as possible by
getting lots of practice estimating. If you are overcommited, you first try to solve the problem in
the family. Have you slipped away from the practices? Are you testing, pair- ing, refactoring,
and integrating as well as you can? Are you delivering more than the customer needs in places?
If you can’t find any way to go faster, you have to ask the customer for relief. Staying
committed to more work than you can confidently complete is a recipe for frustration, slipping
quality, and burnout. Don’t do that. Re-estimate based on what you’ve learned, then ask
the customer to reschedule. We can only complete two out of three stories, so which two should
we fin- ish and which one goes in the next iteration or release? Is there a story that has more
critical parts and less
critical parts so we can split it and deliver the most important parts now and the less important
parts later?
Uncooperative customers What if you get a customer who just won’t play the
game? They won’t specify tests, they won’t decide on priorities, they won’t write
stories. First, by complet- ing functionality iteration after iteration, and by giving the customer
12. clear control over development, you are trying to build a trust relationship with the customer. If
trust begins to break down, figure out if it’s your fault. Can you do a better job of
communicating?
If you can’t solve the problem on your own, you have to ask the customer for help. Extreme
programmers simply don’t go ahead based on their own guesses. Explain or demonstrate the
consequences to the cus- tomer. If they don’t change, make your concerns more visible. If no
one cares enough to solve the problem, perhaps the project isn’t a high enough priority to go
on.
DaimlerChrysler: The Best Team in the World
Chet Hendrickson, DaimlerChrysler
The C3 project began in January 1995 under a fixed-priced contract that called for a joint team of
Chrysler and contract partner employees. Most of the develop- ment work had been completed
by early 1996. Our contract partners had used a very GUI-centered development method- ology,
which had ignored automated test- ing. As a result, we had a payroll system that had a lot of very
cool GUIs, calculated most employees’ pay incorrectly, and would need about 100 days to
generate the monthly payroll. Most of us knew the program we had written would never go into
production.
We sought Kent Beck to help with per- formance tuning. He found what he had often found
when brought in to do per- formance tuning: poorly factored code, no repeatable tests, and a
management that had lost confidence in the project. He went to Chrysler Information Services
manage- ment and told them what he had found, and that he knew how to fix it. Throw all the
existing code away! The first full XP project was born.
We brought Kent in as head coach; he would spend about a week per month with us. Ron Jeffries
was brought in as
Kent’s full-time eyes and ears. The fixed- price contract was cancelled, and about one-half of
the Chrysler developers were reassigned. Martin Fowler, who had been advising the Chrysler
side of the project all along and clashing with the fixed-price contractor, came in to help the
customers develop user stories. From there, we fol- lowed Kent as he made up the rules of XP. A
commitment schedule was developed, iterations were laid out, rules for testing were established,
and paired programming was tried and accepted as the standard.
At the end of 33 weeks, we had a sys- tem that was ready to begin performance tuning and
parallel testing. Ready to begin tuning because it was well factored and backed up by a full
battery of unit tests. And, ready to begin parallel testing because a suite of functional tests had
shown the customers that the required functionality was present.
That increment of C3 launched in May 1997, not as soon as we had hoped. We were slowed by
two factors. First, we had decided to replace only the internals of the payroll system. We left all
of the external interfaces intact. Matching up the output from our new system to the old payroll
13. master ended up being a much larger task then we had originally estimated. Second, we decided
not to launch during any pay period with special processing require-
ments, such as W-2 processing, profit shar- ing, or general merit pay increases. This effectively
eliminates November through April.
Since the launch of the monthly system, we’ve added several new features, and we have
enhanced the system to pay the biweekly paid population. We have been paying a pilot group
since August 1998 and will roll out the rest before the Y2K code freeze in November 1999.
Looking back on this long development experience, I can say that when we have fallen short of
keeping our promises to our management and our customers, it has been because we have
strayed from the principles of XP. When we have dri- ven our development with tests, when we
have written code in pairs, when we have done the simplest thing that could possi- bly work, we
have been the best software development team on the face of the earth.
Team: 10 programmers, 15 total Application: large-scale payroll system
Time: four years
Turnover What if someone leaves? Won’t you be stuck with-
out documents and reviews? First, a certain amount of turnover is good for the team and for the
people on the team. However, you’d like people to leave for positive reasons. If
programmers go home at the end of every week seeing the concrete things they have accom-
plished for the customer, they are less likely to get frus- trated and leave.
When someone leaves an XP project, it isn’t like they can take away any secrets that only
they know. Two people were watching every line go into the sys- tem. And whatever
information does walk out the door, it can’t hurt the team too much because they can run the
tests to ensure that they haven’t broken any- thing out of ignorance.
New people on an XP team spend the first couple of iterations just pairing with more
experienced peo- ple, reading tests, and talking with the customer. When they feel ready, they
can accept responsibility for tasks. Over the course of the next few iterations, their per- sonal
velocity will rise as they demonstrate that they can deliver their tasks on time. After a few
months, they are indistinguishable from the old salts.
Programmers that don’t work out with the team are a problem, too. XP is an intensely social
activity, and not everyone can learn it. It also requires aban-
doning old habits, which can be difficult, especially for high-status programmers. In the end,
though, the many forms of feedback in XP make it clear who is working out and who isn’t.
Someone who consis- tently doesn’t complete tasks, whose integrations cause problems for
other people, who doesn’t refac- tor, pair, or test …. Everyone on the team knows the score.
And the team is better off without that person, no matter how skilled.
14. Changing requirements The bugaboo of most software development is just
not a problem in XP. By designing for today, an XP sys- tem is equally prepared to go any
direction tomorrow. Things that are like what you’ve already done will be easier, just by the
nature of refactoring to satisfy “once and only once,― but those are precisely the things that
are most likely to happen. However, should a radically new requirement arise, you won’t
have to unwind (or live with) a lot of mechanism built on speculation.
I didn’t initially realize the extent to which XP can adapt to changing requirements. The first
version of XP assigned stories to all the iterations in a release, as part of release planning. The
team discovered that they could get better results with less planning by only asking the customer
to pick which stories should be in the present iteration. If a new story comes up, you
76 Computer
Ford Motor: A Unique Combination of Agility and Quality
Don Wells, Ford Motor
Finance Systems at Ford Motor has been developing the Vehicle Costing and Profit System
(VCAPS), an analysis tool that produces reports on production rev- enues, expenses, net income,
and profit. The input is a bill of materials, fixed costs and expenses, and variable costs such as
labor hours. VCAPS assembles this data into detailed cost analysis reports to sup- port corporate-
level forecasting and deci- sion making.
Ford started VCAPS in 1993 and built it with VisualWorks and GemStone Smalltalk. VCAPS is
now being main- tained with a small staff and is to be replaced with a newer system.
The VCAPS project challenged us two ways. First, the analysts wanted modifica- tions and new
functionality before each run. Constantly changing requirements kept us in reaction mode. We
never caught
up. Second, the system needed to be run in a limited span of time. But the system took a long
time to process and required lengthy manual input before producing final output. A bug could
waste precious time by requiring a rerun.
XP offered us a unique combination: agility to meet the volatile requirements on time and quality
to avoid the dreaded rerun.
We began XP with the planning game. It was a failure. Customers and manage- ment were
unaccustomed to negotiating schedules. The commitment schedule pro- duced was perceived as
lacking credibility and utility. We had to swap in Microsoft Project schedules, which could be
modi- fied without large meetings and could pro- duce the kinds of artifacts management was
used to seeing and taking action on.
15. We continued by adding a few unit tests. Automated unit testing was an enormous success. After
a year, we had 40 percent test coverage and management had mea- sured a 40 percent drop in
bug reports. XP was being noticed.
We solved problems by adding XP prac- tices. Tests enabled continuous integration and small
releases. These allowed us to roll in collective ownership and refactor- ing. We were working
toward simple design. Building momentum, we tried pair programming. We had to work hard to
get pair programming going. Our developers found it awkward; it took a while to become
comfortable.
After a year and a half, the decrease in system failures had reduced the number of emergency
releases to a point where cus- tomers and managers noticed far greater system stability. Overall,
XP was very suc- cessful in our environment.
Team: 12 programmers, 17 total Application: cost analysis system Time: six years
October 1999 77
Tariff System: Tests You Can Read Rob Mee, Independent consultant
Tariff System is a subsystem of a large Smalltalk/GemStone project at a major international
container-shipping company. Using XP practices, Tariff System was taken from inception to
production in three months by a team of three. The resulting system proved to be unusually
stable and easy to maintain.
At the outset of the project, the team resolved to adhere to several core XP prac- tices: always
program in pairs, use the sim- plest design possible, refactor aggressively, and write extensive
unit tests. All of these practices were very effective. One XP idea that initially seemed far-
fetched was writ- ing tests before writing the code that sat- isfied them. We were surprised to
find that in fact this helped bring our designs into focus, enabling us to work more quickly.
Another practice we employed from the beginning was collecting requirements from users in the
form of user stories. We
had mixed results with this. As program- mers focused on coding, we found the role of
facilitating and negotiating with users difficult. More important was the fact that users needed
lots of help writing stories that were both relevant and unambiguous. In the end, we felt that
perhaps XP was missing a project role. We needed some- one from the development team whose
primary focus—and particular talent— was interacting with users.
In our efforts to refactor test cases and fix- tures, we discovered that creating little lan- guages
for our major domain objects dramatically improved the readability and brevity of our test code.
It also practically eliminated the time we spent thinking about how to create object instances
when writing tests. We defined grammars for about ten of our domain classes. Here’s a
simple exam- ple used to construct a Service Offering:
16. newFromString: ‘from Oakland to Tokyo shipping toys: 20ft containers $500; 40ft containers
$1000’.
The constructor uses a parser, automati- cally generated from a grammar, to pro- duce the
domain object. The code to instantiate this object using standard con- structors would have taken
many lines, would have been difficult to read, and would have distracted from the test case itself.
Eventually, we discovered that we could combine the individual domain lan- guages into a larger
description of the sys- tem as a whole, which proved to be a valuable tool in the expression of
func- tional tests.
don’t have to shuffle the remainder of the iterations, you just put it in the pile. One or two
weeks later, if the story still seems urgent, the customer will pick it.
Planning one iteration at a time also introduces a pleasing self-similarity. At the scale of months
and years, you have the stories in this release and then the stories in future releases. At the scale
of weeks and months, you have stories in this iteration and then the stories remaining in this
release. At the scale of days and weeks, you have the task you are working on now and then the
rest of the tasks in the iteration. And at the scale of minutes and days, you have the test case you
are working on now and then the rest of the test cases that you can imagine.
X P is by no means a finished, polished idea. The limits of its application are not clear. To try it
today would require courage, flexibility, and a
willingness to abandon the project should your use of XP be failing.
My strategy is first to try XP where it is clearly applicable: outsourced or in-house development
of small- to medium-sized systems where requirements are vague and likely to change. When we
begin to refine XP, we can begin to try to reduce the cost of change in more challenging
environments.
If you want to try XP, for goodness sake don’t try to swallow it all at once. Pick the worst
problem in your current process and try solving it the XP way. When it isn’t your worst
problem any more, rinse and repeat. As you go along, if you find that any of your old practices
aren’t helping, stop doing them.
This adoption process gives you a chance to build your own development style—which you will
have to do in any case—to mitigate the risks should XP not work for you and to continue
delivering as you change. â•–
Reference 1. S. Prowell et al., Cleanroom Software Engineering,
Addison Wesley Longman, Reading, Mass., 1999.
Kent Beck owns and operates First Class Software, your typical one-person consulting company
mas- querading behind a fancy name and an answering machine. In addition to two books and 50
19. overlook is that mass-production creates a tremendous amount of work that does not directly add
value. Shipping eyeglasses to a factory for one hour of processing adds more handling time by
far than the processing time to make the glasses. Adding retail distribution to the cutthroat
personal computer industry means that a manufacturer needs six weeks to respond to changing
technology, instead of six days. Sears’ practice of building an inventory of mail orders to fill
meant keeping track of stacks of orders, not to mention responding to innumerable order status
queries and constant order changes.
“The lean producer, by contrast, combines the advantages of craft and mass production, while
avoiding the high cost of the former and the rigidity of the later… Lean production is
‘lean’ because it uses less of everything compared with mass production – half the
human effort in the factory, half the manufacturing space, half the investment in tools, half the
engineering hours to develop a new product in half the time. Also, it requires keeping far less
than half the inventory on site, results in many fewer defects, and
2 Womack (1990) p 13.
produces a greater and ever growing variety of products.―3
While on a tour of a large customer, Michael Dell saw technicians customizing new Dell
computers with their company’s ‘standard’ hardware and software. “Do you think
you guys could do this for me?― his host asked. Without missing a beat, Dell replied,
“Absolutely, we’d love to do that.―4 Within a couple of weeks, Dell was shipping
computers with factory-installed, customer- specific hardware and software. What took the
customer an hour could be done in the factory in minutes, and furthermore, computers could be
shipped directly to end-users rather than making a stop in the corporate IT department. This
shortening of the value chain is the essence of lean thinking.
Companies that re-think the value chain and find ways to provide what their customers value
with significantly fewer resources than their competitors can develop an unassailable competitive
advantage. Sometimes competitors are simply not able to deliver the new value proposition.
(Many have tired to copy Dell; few have succeeded.) Sometimes competitors do not care to copy
a new concept. (Southwest Airlines has not changed the industry’s approach to seat
assignments.) Sometimes the industry follows the leader, but it takes time. (Almost all direct
merchandise is shipped within a day or two of receiving an order these days, but the Sears
catalog has been discontinued.)
Lean Thinking in Software Development eBay is a company which pretty much invented
‘lean’ trading by eliminating all the unnecessary steps in the trading value chain. In the
mid 1990’s, basic eBay software capabilities were developed by responding daily to
customer requests for improvements.5 Customers would send an e-mail to Pierre Omidyar with a
suggestion and he would implement the idea on the site that night. The most popular features of
eBay, those which create the highest competitive advantage, were created in this manner.
Digital River invented the software download market in the mid 1990’s by focusing on
‘lean’ software delivery. Today Digital River routinely designs and deploys
22. Finding Information Have everyone in the same room; customer included
Defects Not Caught by Tests
Test first; both developer tests and customer tests
Waiting, Including Customers Deliver in small increments
Handoffs Developers work directly with customers
‘Do It Right The First Time’ XP advocates developing software for the current need, and
as more ‘stories’ (requirements) are added, the design should be ‘refactored’7 to
accommodate the new stories. Is it waste to refactor software? Shouldn’t developers “Do
It Right the First Time?―
It is instructive to explore the origins of the slogan “Do It Right the First Time.― In the
1980’s it was very difficult to change a mass-production plant to lean production, because in
mass production, workers were not expected to take responsibility for the quality of the product.
To change this, the management structure of the plant had to change. “Workers respond only
when there exists some sense of reciprocal obligation, a sense that management actually values
skilled workers, … and is willing to delegate responsibility to [them].â€8 The slogan “Do It
Right the First Time― encouraged workers to feel responsible for the products moving down
the line, and encourage them to stop the line and troubleshoot problems when and where they
occurred.
7 Refactoring is improving the design of software without changing functionality. 8 Womack
(1990) p 99.
In the software industry, the same slogan “Do It Right the First Time,― has been misused
as an excuse to apply mass-production thinking, not lean thinking to software development.
Under this slogan, responsibility has been taken away from the developers who add value, which
is exactly the opposite of its intended effect. “Do It Right the First Time― has been used as
an excuse to insert reams of paperwork and armies of analysts and designers between the
customer and the developer. In fact, the slogan is only properly applied if it gives developers
more, not less, involvement in the results of their work.
A more appropriate translation of such slogans as “Zero Defects†and “Do It Right the
First Time†would be “Test Firstâ€. In other words, don’t code unless you
understand what the code is supposed to do and have a way to determine whether the code
works. A good knowledge of the domain coupled with short build cycles and automated testing
constitute the proper way for software developers to “Do It Right the First Time―.
Center On The People Who Add Value Almost every organization claims it’s people are
important, but if they truly center on those who add value, they would be able to say:
The people doing the work are the center of Resources Information
25. because they don’t hide unknown, lurking problems and they don’t pretend they can
forecast the future.
In Lean Software Development, the idea is to maximize the flow of information and delivered
value. As in lean production, maximizing flow does not mean automation. Instead, it means
limiting what has to be transferred, and transferring that as few times as possible over the
shortest distance with the widest communication bandwidth as late as is possible. Handing off
reams of frozen documentation from one function to the next is a mass-production mentality. In
Lean Software Development, the idea is to eliminate as many documents and handoffs as
possible. Documents which are not useful to the customer are replaced with automated tests.
These tests assure that customer value is delivered both initially and in the future when the
inevitable changes are needed.
In addition to rapid, Just-in-Time information flow, Lean Software Development means rapid,
Just-in-Time delivery of value. In manufacturing, the key to achieving rapid delivery is to
manufacture in small batches pulled by a customer order. Similarly in software development, the
key to rapid delivery is to divide the problem into small batches (increments) pulled by a
customer story and customer test. The single most effective mechanism for implementing lean
production is adopting Just-in-Time, pull-from-demand flow. Similarly, the single most effective
mechanism for implementing Lean Development is delivering increments of real business value
in short time-boxes.
In Lean Software Development, the goal is to eliminate as many documents and handoffs as
possible. The emphasis is to pair a skilled development team with a skilled customer team and
give them the responsibility and authority to develop the system in small, rapid increments,
driven by customer priority and feedback.
Optimize across Organizations Quite often, the biggest barrier to adopting lean practices is
organizational. As products move from one department to another, a big gap often develops,
especially if each department has its own set of performance measurements that are unrelated to
the performance measurements of neighboring departments.
For example, let’s say that the ultimate performance measurement of a stamping room is
machine productivity. This measurement motivates the stamping room to build up mounds of
inventory to keep the machines running at top productivity. It does not matter that the inventory
has been shown to degrade the overall performance of the organization. As long as the stamping
room is measured primarily on machine productivity, it will build inventory. This is what is
known as a sub-optimizing measurement, because it creates behavior which creates local
optimization at the expense of overall optimization.
Sub-optimizing measurements are very common, and overall optimization is virtually impossible
when they are in place. One of the biggest sub-optimizing measurements in software
development occurs when project managers are measured on earned value. Earned value is the
cost initially estimated for the tasks which have been completed. The idea is that you had better
not have spent any more than you estimated. The problem is, this requires a project manager to
build up an inventory of task descriptions and estimates. Just as excess inventory in the stamping
27. Lean manufacturing organizations develop a limited number of relationships with ‘trusted’
suppliers, and in turn, gain the ‘trust’ of these suppliers. What does ‘trust’ mean?
“Trust [is] one party’s confidence that the other party in the exchange relationship will
fulfill its promises and commitments and will not exploit its vulnerabilities.―11
“…trust…[is] not based on greater interpersonal trust, but rather greater trust in the
10 Collaborative Advantage, by Jeffrey H. Dyer, Oxford University Press; 2000, p 6. 11 Dyer
(2000) p 88.
fairness, stability, and predictability of [the company’s] routines and processes.―12
It has been the practice of legal departments writing software contracts to put into contractual
language all of the protections necessary to keep the other side ‘honest.’ However, the
transaction costs associated with creating and monitoring such contracts are enormous. Many
contracts all but demand a waterfall process, even if both companies believe this is not the best
approach. It’s time that the software development industry learned the lesson of Supply
Chain Management – “Extraordinary productivity gains in the production network or value
chain are possible when companies are willing to collaborate in unique ways, often achieving
competitive advantage by sharing resources, knowledge, and assets…. Today competition occurs
between value chains and not simply between companies.―13
Summary and Conclusion The lean production metaphor is a good one for software
development, if it is applied in keeping with the underlying spirit of lean thinking. In the past, the
application of some manufacturing concepts to software development (‘Do It Right the First
Time’ comes to mind) may have lacked a deep understanding of what makes lean principles
work. The underlying principles of eliminating waste, empowering front line workers,
responding immediately to customer requests, and optimizing across the value chain are
fundamental to lean thinking. When applied to software development, these concepts provide a
broad framework for improving software development.
12 Dyer (2000) p 100 13 Dyer (2000) p 5
Week 2 Assignment - Proposal
Executive Summary
Homeland security officers include law enforcement officers, first responders, and federal
personnel who work in the country's borders to manage the movement of people in and out and
ensure the security of the borders, seaports, and airports checking potential immigrants for
connections to terrorists or criminal behavior. The research aims to develop an app, designed for
delivering and sharing timely intelligence information with law enforcement officers and first
responders across the country. The app specifications include an interactive interface element
that allows the user to use, modify and edit navigation control tools. The study sample includes 2
senior leaders per department, from the 22 departments of the homeland security officers due to
their sufficient information on the necessary app specification necessary for investigating,
disrupting, and dismantling terrorists' transnational and other criminal investigations. The study
28. will employ both parametric and non-parametric statistical tests to evaluate the data collected
from app users.
The app users include homeland security officers which include law enforcement officers, first
responders, and federal personnel. The officers work in the country's borders to manage the
movement of people in and out of the country’s homeland security officers help to secure the
borders, seaports, and airports checking potential immigrants for connections to terrorist or
criminal behavior. The research aims to develop an app, designed for delivering and sharing
timely intelligence information with law enforcement officers and first responders across the
country. The app must allow easy and faster access to information and must be secure for any
device. It should have a feature that permits real-time collaboration between the partners and
offer key technologies for protecting the citizens from adversarial threats facilitating coordinated
responses and helping law enforcement officer to secure the country's borders.
The app specification includes an interactive interface element that allows the user to use,
modify and edit. For instance, the navigation controls such as the links and buttons and editable
content. This interactive element includes keyboard access and labels for assistive technologies.
Other elements are non-test interface elements such as images and the text tendered such as
graphs, charts, images audio and video files, and animations. (3) the app should permit the use of
colors for conveying meaningful information and provides alternative means for users who
cannot distinguish the different colors. Another important component is the flashing elements
that flicker and blink repetitively.
The study sample includes 2 senior leaders per department, from the 22 departments of
homeland security officers. The senior executives have sufficient information on the necessary
app specification necessary for investigating, disrupting, and dismantling terrorists' transnational
and other criminal investigation that seeks to or threatens to exploit the customs and immigration
laws. The research will employ the use of interviews for the data collection process. (1) an
interview helps a researcher to explain, understand and explore the research subject’s
experiences and opinions and collect in-depth information.
The interview will include questions surrounding the challenges experienced by the security
officers in checking potential immigrants for connections to terrorist or criminal behaviors. The
limitation of the present apps, and the recommendation for future apps. The users need an app
that will improve their convenience by proving a new tool for accessing information quickly and
easily and securely from any device. In most instances, field security officers are in an
operational environment and require easy and secure access to intelligence updates, reports, and
relevant breaking information. This is in line with the goal of the research w will be to provide a
user-friendly application that meets the customer's needs.
Two applicable tests for evaluating the data collected from users are the parametric and the non-
parametric statistical tests. Parametric tests make specific assumptions about the collected data
while the non-parametric do not make any assumptions. The two tests assist in making
inferences about the collected data from the sample population (2). The parametric test permits
the researcher in making generalizations from the sample and does not need interval data to be
transformed into rank data. Equally this statistical test provides real information.
29. In conclusion, the purpose of research is to outline the app specification required by the
homeland security officers to guide in the process of developing the app. the app needs to have
interactive interface elements that permit the users in delivering and sharing timely intelligence
information with the law enforcement officers checking potential immigrants for connection to
criminal behavior. Both parametric and non-parametric statistical tests are used for evaluating
the data collected during the interview.
Sources
1. Jain, N. (2021). Survey versus interviews: Comparing data collection tools for exploratory
research. The Qualitative Report , 26 (2), 541-554.
2. Kelter, R. (2021). Analysis of type I and II error rates of Bayesian and frequentist parametric
and nonparametric two-sample hypothesis tests under preliminary assessment of normality.
Computational Statistics , 36 (2), 1263-1288.
3. Swalwell, E. M., & Alagood, R. K. (2021). Homeland security twenty years after 9/11:
Addressing evolving threats. Harv. J. on Legis. , 58 , 221.