Developer Forum

How does XP handle non-functional requirements like performance, reliability,
safety, security, maintainability and so on? For example if there is a
performance requirement for at least 1000 transactions/second how is it ensured
in the XP process?

I can only think of creating a user story for this non-functional requirement
and than refactoring the code as long as the non-functional requirement is met.


Kind regards,


Sebastian

You have answered your own question.

Customer: I want is to handle 1000 transactions per second.

Developers: Lets create a story card for it "System to to handle 1000
transactions per second".

Story planned as per XP planning game.

Then, Customer with developers help write an acceptance test that
executes 1000 transactions, which fails if it takes more than a second
(or something thing like this).

The developers implement what ever is needed to get the acceptance test
to pass.

The best part, is that now the system has this automated acceptance test
, it will always be run even as the system continues to develop. This
gives the developers immediate feedback, should future story
implementations adversely effect this performance story.

reliability,
ensured
requirement
is met.

How about "security". The test for that is you fill a room with the most
mindless of the underworld hackers, and give them a continuous supply of
Mountain Dew.

--
Phlip
http://www.yqcomputer.com/

Yes, performance is easy. But what about maintainability, portability,
reliability? Do you think you can always come up with good user stories for
that?

Sebastian

for

- maintainability

An XP project is always in maintenance. We deliver to end-users, early and
often, so we expect that most of development (the RUP "inflation phase" and
"implementation phase";) is changing code that users must expect to be
stable. All the tests, together, support maintainability. The onsite
customer remains aware of real customer's workflow, and helps not derail it.

- security

To get this, you research known security issues and their fixes, your team
votes on which ones your project needs, and you implement them using TDD.
You don't expect a secure system to emerge via TDD for all the other
features. There are always ways to crack systems, even bug-free ones.

- portability

The C++ literature, for example, talks too much about portability, because
some C++ developers have the goal of matching their application to any
platform that supports C++. This leads to too much newbie traffic on

nobody needs. This has lead to the admonition:

==> portability is for canoes <==

However, XP supports portability better than C++. XP programmers generally
agree that if you port between platforms, or migrate between languages or
systems, that you throw the code away and keep all the tests.

However, if your code must simultaneously support several back-ends (such as
GameCube, XBox, PS2, etc.), then you need portability in space, not in time.
In this situation, you must run all tests on all platforms at integration
time. This requires a Test Server From Hell, to manage all the permutations
of ramifications of all platforms, and synchronize their testage in
lockstep. This aspect of test servers needs further investigation.

- reliability

The effect of refactoring code, under test, simply cannot be understated
here. Some traditional testing techniques rotate test criteria thru many
permutations, and run them all against the same code. (If you need that kind
of testing, you should add it on top of the XP testage.)

XP's refactoring practice rotates the same tests thru steadily contracting
permutations of code. As duplication squeezes out of code, and as its
continuously reviewed and cleaned, there are simply no places for bugs to
hide.

If you say, "Ah, but what about 100% availability". That's a feature, and
the onsite customer must request it. The reason it's a feature, not an
emergent property of clean code, is very simple. No matter how tested your
code, life, and karma is, somewhere out in space there is a cosmic ray with
your CPU's serial number written on it. If you need availability, you buy
it, typically using common techniques like redundant servers.

So, in conclusion, the answer to everything is "tests", and the answer to
"tests" are all the other XP practices that support tests.

--
Phlip
http://www.yqcomputer.com/

If you can't come up with user stories for the requirement, how do you
implement it???

Curious, Ilja

Maintainability is not something that a customer would ask for, so don't
try and write any stories for it. Its something the development team
needs to ensure happens. TDD's unit tests aid this tremendously!

The acceptance tests and the Unit tests from the TDD sessions also help
maintainability to continue for the entire duration of
the system.

Reliability is the same as maintainability.

'Availability' is different to 'Reliability. 'Availability' can and
should be treated like any other feature.

Example Availability stories could be:

"The system should restart itself is it crashes".
"System start-up time should be less than n seconds".

Portability should only ever be thought about when its need.

Its akin to premature optimisation, to prematurally create code or use
specific technology to aid portability when there is no current need,
just adds unneeded complexity.

Andrew

Maintainability.

There are times when the customer wants to insure that
the system can be turned over to another team, so
maintainability is definitely a story. What you do is
monitor velocity. As long as it's stable, your system
is maintainable. If it starts to go down, you're losing
maintainability.

Portability.

Portability is the same as internationalization. Adding
I18N to a project at the beginning requires developing
for four languages (selected from languages with
specific characteristics) from the beginning, and also
with providing tools for the translators.

To insure portability, develop for each of the
systems you need to port to. Do it up front,
and develop whatever tools you need.

Reliability.

High reliability systems require several things:
1) a good threat analysis
2) minimal defects
3) good recovery

Threat analysis is a parallel task best done offline.

Assured Quality is the usual name for the set
of techniques required to guarantee that there
are fewer remaining defects than some target.
Defect seeding is an Assured Quality technique
that can be automated so it doesn't impact the
XP workflow. Defect seeding is also a reasonably
method of testing your recovery mechanisms.

In other words, yes, you can write stories
for each of them.

HTH

John Roth

Reliability is the probability that the software will execute without
failure for a given time period in a given environment. Maintainablity is
...? (certainly not the same)


Malcolm S Jenner
Senior Lecturer
School of Computing & IT
University of Wolverhampton

is

The ability to return to a module changed a long time ago, perform a minor
change (or seven), and know the result is reliable

Poor maintainability requires minor changes to lead to bad code changes,
without simplifying the result. So the code fills up with cruft. Code that
holds its value over time is above average.

--
Phlip
http://www.yqcomputer.com/

Granted, they are differing qualities.

I was referring to Reliability in terms of how to achieve it, in that
one would do so using the same techniques to achieve maintainability.

Actually not. They are similar in that maintainable code tends
to have a lower defect density than otherwise, which in turn would
tend toward being more reliable.

However, if you want to qualify a piece of code as reliable,
you need to be able to quantify things like the residual
defect density, and you need to look into obscure
corners that will only come up when the code has been
executing for months. The Patriot missile batteries in
Gulf War I are a good case in point: they had a clock
drift that affected their targeting accuracy. They had to
be rebooted after some ridiculously small number of hours
(I remember 11, but could easily be wrong.)

John Roth

They are similar in that maintainable code tends

Which is what I was trying to convey.


Admittedly, to Quantify the Reliability, then other approaches are
needed. However, I've not personally seen nor heard of a customer
wanting Reliability quantified. I have and currently do see customers
wanting Availability quantified.