Bjorn:
Thanks for the discussion. You made some good points. I am interested in your comments on
my following comments which are my humble opinion and not meant to negate
yours or anyone else's opinion. I hope it raises some questions and facilitates more good discussion.
I wish you a Happy Holiday Season!
Quality is all those things you listed and not just defect free code. A product which costs far
too much and/or was completed long after it was needed is of poor quality, too. A product
which is hard to learn, will not scale up, etc, is of low quality if those factors were
requirements.
You may want to read http://www.embedded.com/97/feat9609.htm how Robert
Oshana used formal methods to reduce cycle time on the very first project using a new
formal method (new to them) which included training and ramp up. It is a fallacy to state
that formal processes take longer, though I will agree that human intellect and sweat can
win on small problems of short duration as per the legendary American folk hero: John
Henry http://www.nsc.ru/folk/usa/johnhenry.htm .
All formal methods do not require clear requirements at least for other than the initial
level. Clearly "do something" may even be a requirement since there will be some limits on
time and cost and expected outcomes. Some such as RAD develop the functional
requirements as part of an experimentation and exploration process - or at least the second
level and deeper level requirements but isn't RAD a formal process? The initial requirement had to be in place such as I
wonder what a so-and-so system would look like and cost. When all is not known ahead of
time, one still must use formal processes to manage thru that such as an exploration process
which clearly must have an objective, a schedule, a budget, or it falls into basic research
which does have its place but should not be the normal modus operandi.
The formal part is the managing the expectations and outcomes and means to get there.
Why would anyone not want to keep the product under intellectual control at all times, all
components under configuration management control, the project under managerial control
(cost, resources, schedule), and the processes under statistical process control? Anything less
is skunk works which does have its place outside mainstream software engineering but
hopefully we are speaking to mainstream.
Your coffee example shows that there is a defect in the specification process for your problem.
Had you used a sequence enumeration specification, the sequence of actions in combination
with state would have been specified in detail, which is why you may have needed to use
this proven formal process in the first place. So now a formal process needs improvement via
another formal process, namely statistical process control. See
http://www.computer.org/proceedings/sesd/0010/00100014abs.htm?SMSESSION=NO .
"Formal requirements have a high up-front investment..." Have you read the
documentation by Fagan and Gilb et all about the ROI of formal inspections? Short
learning curve, quick and high payback. Same thing with the use of small teams and
developing in small demonstratable increments. I can list others.
Thanks for your comments!
C. Wayne Hardeman
Bjorn Reese wrote:
carl hardeman wrote:
> So if the goal is better quality software, then the better psychological question
> to study is why programmers reject proven formal techniques and continue their
> brute force and awkwardness ways believing they can intellectually overcome
> problems of complexity. That and sweat. Formal processes are well understood in
> academia but not so widely practiced in industry. Why? What are the psychological
> factors? It's not the fear of lack of time since it is usually the case that doing
> things right the first time is faster/better/cheaper than a less formal approach.
Maybe quality is not as important than other goals in reality? Developing
software is usually an attempt at balancing cost, time, features, and
quality, and normally quality is the first factor to be lowered when
facing a potential delivery slippage.
Formal methods have a high up-front investment, so the benefits are
long-term. However, since the environment that software has to operate
in is constantly changing (due to competition, innovation, and customer-
expectation), long-term investments are difficult to rely on. You may
have to abandon the software because it does not address todays needs.
Formal methods require clear requirements to work on. In practice,
however, requirements often change during the development cycle,
especially when the customer is presented with the first prototypes.
Furthermore, it is often difficult to exhaustively specify the
requirements (my favorite example is a coffee machine, whose specification
says that it must pour hot water, coffee powder, and milk into a cup --
one day it pours hot water, coffee powder, milk, and oil into the cup,
which is perfectly legal according to its specification.)
Formal methods do not handle integration with other systems well. This
is important because more and more of todays software development is
really systems engineering, i.e. gluing existing components and systems
together.
Formal methods do not address non-functional requirements well; in
particular the important usability and efficiency requirements.
----------------------------------------------------------------------
PPIG Discuss List ([EMAIL PROTECTED])
Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss
Announce admin: http://limitlessmail.net/mailman/listinfo/announce
PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
