<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="Tiki CMS/Groupware via FeedCreator 1.7.2.1" -->
<?xml-stylesheet href="http://www.valuecertification.com/lib/rss/rss-style.css" type="text/css"?>
<?xml-stylesheet href="http://www.valuecertification.com/lib/rss/rss20.xsl" type="text/xsl"?>
<rss version="2.0">
    <channel>
        <title>Tiki RSS feed for forums</title>
        <description><![CDATA[Project Management, Requirement Specification, Architecture, Inspection, Quality Control, Defect Prevention, Principles of Software Engineering Management, Agile Evolutionary methods.]]></description>
        <link>http://www.valuecertification.com/tiki-forums_rss.php?ver=2</link>
        <lastBuildDate>Sun, 05 Sep 2010 08:49:18 +0100</lastBuildDate>
        <generator>Tiki CMS/Groupware via FeedCreator 1.7.2.1</generator>
        <image>
            <url>http://www.valuecertification.com/img/tiki.jpg</url>
            <title>Tom Gilb &amp; Kai Gilb</title>
            <link>http://www.valuecertification.com/Site+Content+Overview</link>
            <description><![CDATA[Feed provided by Tom Gilb & Kai Gilb. Click to visit.]]></description>
        </image>
        <language>en-us</language>
        <managingEditor>Kai@Gilb.com</managingEditor>
        <webMaster>Kai@Gilb.com</webMaster>
        <item>
            <title>Are U convinced what Drives culture change?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=221</link>
            <description><![CDATA[Listening to all since Monday...it seems the  majority view is that Systems eg SCRUM, Waterfall etc drive culture change rather than PEOPLE?

Well what all of us may need to understand more is how he synthesis of both.

The breakthrough for us will come when we combine the people process with the system process.

Am open to explore with U? is the INNOVATIONS Marlyn was talking off?

regards
Yazdi]]></description>
            <author>yazdi</author>
            <pubDate>Thu, 25 Jun 2009 11:27:07 +0100</pubDate>
        </item>
        <item>
            <title>Lorne's Presentation</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=220</link>
            <description><![CDATA[To endorse what Lorne said.

Some years back was invited to a seminar at Budapest University on Spirituality in Management.

Subsequently a book published "Spirituality in Management"

My own experiences with patterns similar to Lorne's are are shared in the book.

How are we to prepare for this new age of CONSCIOSNESS? ( ref: Spirit in Business, EBEN)

This morn David shared about the young...google INDIGO children.

Now Allan is speaking of Stories...see book DISCOVERY by JM SAMPATH, published some 15 years ago.

All this indicates the changes ahead.

So how are we going to prepare for the NEW Times ahead?

Some ideas I will explore Friday 2.30pm 

Warm regards
Yazdi]]></description>
            <author>yazdi</author>
            <pubDate>Thu, 25 Jun 2009 09:41:56 +0100</pubDate>
        </item>
        <item>
            <title>John Seddon video on Culture Change</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=219</link>
            <description><![CDATA[Hi all,

Have  look at this video http://www.vimeo.com/4670102. It lasts one hour, but is very informative and entertaining.

Regards,
Giovanni]]></description>
            <author>gasproni</author>
            <pubDate>Wed, 24 Jun 2009 11:51:22 +0100</pubDate>
        </item>
        <item>
            <title>Jl of Human Values</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=218</link>
            <description><![CDATA[http://jhv.sagepub.com/cgi/reprint/8/2/119
Integrating Corporate Values: The Malaysian Airlines Experience]]></description>
            <author>chaskins25</author>
            <pubDate>Tue, 23 Jun 2009 15:35:02 +0100</pubDate>
        </item>
        <item>
            <title>What do you bring to a Change Environment?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=215</link>
            <description><![CDATA[I set up this post (should have done that in the first place) to give you opportunity to share you results of this "test":

http://www.ppmng.com/profiles/blogs/so-what-do-you-bring-to-a

Cecilia is an INSPIRER
Rolf is a COORDINATING SUPPORTER]]></description>
            <author>rolf</author>
            <pubDate>Tue, 23 Jun 2009 10:28:49 +0100</pubDate>
        </item>
        <item>
            <title>Clifford Shelley Changing Culture: Should you? Could you? How? Why?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=210</link>
            <description><![CDATA[just a starter for your comments]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Mon, 22 Jun 2009 11:10:35 +0100</pubDate>
        </item>
        <item>
            <title>Jerry Durant - UNCulture - post your comments, thoughts, questions etc.</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=209</link>
            <description><![CDATA[wow

I like - Food is central!]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Mon, 22 Jun 2009 10:23:52 +0100</pubDate>
        </item>
        <item>
            <title>Gio Wiederhold - Valuing the result of software engineering efforts - thoughts and comments</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=207</link>
            <description><![CDATA[I'm getting lots of nice insights, thanks Gio

slide 20 "Software cannot grow exponentially" he is talking about size. Value or Performance can grow 10x, I'm not sure how sustainable that is over time though.

slide 22 Gio mentioned something like- that people pay for functionality not size or fancy looking.
I dont think they pay for functionality, but to the value it gives them combined with market alternatives etc..]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Mon, 22 Jun 2009 09:43:41 +0100</pubDate>
        </item>
        <item>
            <title>Post subject suggestions for upcoming Value Management Meetups in Oslo</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=20&amp;comments_parentId=206</link>
            <description><![CDATA[from the first meetup suggestions where:

1. Risk
2. Cases
3. ?? How to deliver Value when one is far from the Stakeholders.]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Thu, 11 Jun 2009 22:16:38 +0100</pubDate>
        </item>
        <item>
            <title>Recommend Great Books!</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=20&amp;comments_parentId=205</link>
            <description><![CDATA[see http://gilb.com/Books

Beyond Budgeting  
http://www.amazon.co.uk/Implementing-Beyond-Budgeting-Unlocking-Performance/dp/0470405163

Scaling Lean & Agile Development by Craig Larman and Bas Vodde]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Thu, 11 Jun 2009 22:08:30 +0100</pubDate>
        </item>
        <item>
            <title>Thinking about leadership thinking</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=204</link>
            <description><![CDATA["Thinking about leadership thinking - 3 modes of reasoning", by Christine Leonardi

see http://www.leader.co.za/article.aspx?s=6&f=1&a=1316

I found it valuable to invest the time to read this article (about 10 - 15 minutes for me as a non-native speaker, to understand it .)

The article to me has no real structure, and does not provide really new insights. __However__, I enjoyed reading it to the end, because it nicely expresses and summarizes values and opinions of mine. Considering the values of the people I had the chance to meet at Gilb seminars (or what I think of being their values), I believe that YOU will find it a good read , too.]]></description>
            <author>rolf</author>
            <pubDate>Thu, 04 Jun 2009 10:54:00 +0100</pubDate>
        </item>
        <item>
            <title>TED talk on change: Seth Godin</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=196</link>
            <description><![CDATA[slightly less that 20 minutes

http://www.ted.com/talks/view/id/538]]></description>
            <author>rolf</author>
            <pubDate>Mon, 25 May 2009 14:30:27 +0100</pubDate>
        </item>
        <item>
            <title>Company in Norway that practices Evo seeks Senior Software Developer</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=193</link>
            <description><![CDATA[Link: [http://www.confirmit.com/company/careers/oslo_reportingdeveloper.aspx]

For english version:
Senior Software Developer

Ready to join a Norwegian software company succeeding in the US marketplace?  Confirmit is the technology leader in its space, and takes great pride in providing innovative and superior technological solutions to an international client base.

The people in Confirmit’s R&D are superior engineers, with a commitment to deliver world-class software in a highly competitive market. 

Our success among the Fortune 500 companies drives the need for sophisticated solutions, which need to be delivered at a high pace and with high quality. In order to meet this demand, we are looking to increase the R&D staff with a senior developer within our reporting team.

Your role will require expert knowledge within several of the following areas:

•	Microsoft .NET Technology
•	Microsoft SQL Server development and performance tuning
•	Designing and developing high-performance web systems
•	Code speed and memory tuning
•	Application level security 
•	W3C standards
•	Designing and developing complex Web Services
•	Business Intelligence software
•	OLAP
•	Algorithms and analytics
•	Integration with ERP systems
•	Other areas of responsibility will be considered based on performance and ambitions

Experience and skills 
•	BS or MS in Computer Science or equivalent
•	Minimum 3 -5 years of professional experience


Confirmit R&D can offer a great working environment with social colleagues. Once on board, you’ll never want to leave! (At least, nobody else has.) As a superior engineer with constant desire to break the mold and exceed expectations, Confirmit has the challenge for you! 

Confirmit is a change oriented organization where we continually aim at creating new opportunities for our employees. What YOU create will determine our continued growth and expansion.

Confirmit can offer exiting challenges in an international environment. The position is located in Oslo (Norway). Good English skills are required. Visit www.confirmit.com for more information about the company. Send application to Trond.Johansen@confirmit.com.  If you have questions regarding the position, call +47 21502500 and ask for Trond Johansen/Ingvar Steffensen]]></description>
            <author>Trond</author>
            <pubDate>Wed, 13 May 2009 08:23:21 +0100</pubDate>
        </item>
        <item>
            <title>Job opening in Confirmit</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=20&amp;comments_parentId=192</link>
            <description><![CDATA[Confirmit is a pioneer in the use of Agile Evo (Value Management). As a Certified Value Management professional I m sure you will be highly welcome to apply. Even though they wrote this in English they do also need English speaking people. Location Oslo. Call 21502500 and ask for Trond Johansen.

- Kai

!!Confirmit søker senior systemutvikler til ledende programvarehus
Vi er stolte av det vi har fått til så langt og vi ønsker DEG med på laget når vi skal vokse til nye høyder. 

Confirmit har blitt en stor internasjonal suksess og selskapet er i dag verdens ledende leverandør av programvare for 
Market Research (MR) og Enterprise Feedback Management (EFM). Selskaper verden over bruker vår programvare til å samle inn og rapportere virksomhetskritisk data, deriblant markedstrender, kundelojalitet og ansattilfredshet. 

Confirmit er et norsk selskap med 250 ansatte og har kontorer i Oslo, Guildford, London, Moskva, New York, San Francisco og Yaroslavl. Noen av våre globale kunder er Accenture, Chase, Hewlett Packard, Microsoft, Nielsen, Symantec, og Toyota. 

Senior systemutvikler 
Som systemutvikler vil man være en del av en gruppe av dyktige systemutviklere som jobber med utviklingen av Confirmit, en applikasjon med svært høye krav til ytelse og stabilitet. Teknologiplattformen vår er Microsoft .NET og SQL Server. Vi kan tilby et eksepsjonelt godt arbeidsmiljø med gode muligheter for faglig utvikling. Vi ligger i forkant i å ta i bruk ny teknologi, blant annet .NET 3.5, C# 3.0, og SQL Server 2008. Du vil bli en del av et team som jobber med rapporteringsløsninger i Confirmit. __Vi bruker en smidig utviklingsmetodikk som heter Evo, og er en av pionerene innenfor denne retningen. __

Noen stikkord for stillingen er: 

•	Design og utvikling av high-performance web systemer 
•	Design og utvikling av komplekse Web Services 
•	Microsoft .NET teknologi 
•	Microsoft SQL Server utvikling og ytelsesoptimalisering 
•	Kodeytelse og minneoptimalisering 
•	Application level security 
•	Algoritmer og statistikk 
•	Design og utvikling av system for å lage innholdsportaler 

Vi søker deg som: 

-	Har minimum 4 års erfaring innen .NET eller Java med fokus på businesslogikk 
-	Interesserer seg for og setter seg raskt inn i ny teknologi og kode 
-	Tar ansvar og viser initiativ 
-	Jobber selvstendig men ikke redd for å stille spørsmål 
-	Snakker flytende norsk eller engelsk 
-	Legger personlig prestisje i arbeidet sitt 

Confirmit kan tilby spennende utfordringer i et internasjonalt arbeidsmiljø, positiv karriereutvikling og konkurransedyktige betingelser. Vi holder til i flotte, nye lokaler på Sjølyst. 


Send inn din søknad i dag! 
Confirmit kan tilby spennende utfordringer i et internasjonalt arbeidsmiljø, positiv karriereutvikling og konkurransedyktige betingelser. Stillingene er lokalisert i Oslo og krever gode fortløpende engelskkunnskaper (skriftlig/muntlig). Besøk www.confirmit.com for mer informasjon om selskapet. Send søknad til Trond.Johansen@confirmit.com. Alle søknader vil bli behandlet konfidensielt og. Ring oss på telefon 21502500 (spør etter Trond Johansen/Ingvar Steffensen) om du har spørsmål.]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Wed, 13 May 2009 07:42:52 +0100</pubDate>
        </item>
        <item>
            <title>Psychological Exercise Challenge</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=186</link>
            <description><![CDATA[I wanted to share with my colleagues a bit of a self-assessment exercise as you read some of the presentations, the formats and styles used, and how they shaped your 'self kept' impressions about the person.  How much of what you are feeling and responding with is shaped by your culture (country, experience, education...) and what portion is influenced by biases.  It's really interesting if you compare your thoughts, and your comments (as the sender) against how they are being received by both the stakeholder and non-stakeholder observers.

I'm sure as you read this you are saying to yourself all sorts of things about me (both good & bad).  I can assure you that I really enjoy strong intellectual and free range thinking, the challenge is appreciated.]]></description>
            <author>Jerry E. Durant &lt;&amp;#106;&amp;#100;&amp;#117;&amp;#114;&amp;#97;&amp;#110;&amp;#116;&amp;#64;&amp;#105;&amp;#110;&amp;#116;&amp;#45;&amp;#105;&amp;#111;&amp;#109;&amp;#46;&amp;#111;&amp;#114;&amp;#103;&gt;</author>
            <pubDate>Wed, 08 Apr 2009 17:36:47 +0100</pubDate>
        </item>
        <item>
            <title>HORTICULTURE AND TESTING PROFESSIONS</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=184</link>
            <description><![CDATA[As requested I am transferring this from email to a topic on the forum:

On 8 Apr 2009, at 14:49, David Stoughton wrote:

On an, admittedly brief, inspection these documents are very thorough, soundly based and commendable. I too like the horticulture analogy. I suppose I'm just a little confused about why everybody wants their practice to be a profession. I don't mean that it shouldn't have standards and qualifications but is a profession the right term.  

Although there are those who wish to call Value Management a profession - I am happier thinking of it as a discipline, an attitude and approach to problem solving that has broad applicability, but needs rethinking and adapting to each context of application. Project Managers too are bucking for professional status while I, for similar reasons think of project management as a discipline.

Professional status carries penalties as well as benefits. Chief among them is the need for absolute agreement on an unchallengeable (at least without a weight of public and academic opinion) core body of knowledge, implying that the subject matter and learning has stopped evolving except at the edges and in the hands of those whose status authorises them. It is no accident that all the established professions are very old ones.  Project management, as most of us know, has a woeful record of success and is being challenged all the time - definitely not time then to pour concrete over the methodologies and declare them sacrosanct. Value management I feel is the same (though I hope our success rate is considerably higher).

This is very roundabout because I don't really know enough about testing to properly evaluate its status. I'm just sounding a warning note.

Best wishes

David]]></description>
            <author>david</author>
            <pubDate>Wed, 08 Apr 2009 13:33:19 +0100</pubDate>
        </item>
        <item>
            <title>Hello Fellow Participants - Culture Change 2009</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=181</link>
            <description><![CDATA[Hi everybody, this is just to get the discussions started.

Notice that you can get an email of messages posted here sent to you automatically by clicking on the little icon of an eye.

Kai


Tom et al,

My 55 minutes will be spent on some musings of beekeeping and a study on the culture of a colony of honey bees - with a few sub-routines diving into stories on functional and dysfunctional organisations that I have belonged to in the past......and a few other sub-routines where we play a game or two!  For those who have been to the past two years, there might even be the odd reference to Sir Patrick Geddes – or even Darwin!  After all we are celebrating the anniversary of the founder of the evo idea!

So let the world of bees pollinate your minds and give you a break from some of the more technical aspects of analysing and changing human-based organisational cultures.

In terms of scope, let’s stretch our minds and create new ways of thinking and looking at the world!

No IT, no comment!

Kind regards,

Lorne

On 30/03/2009 10:13, "Rolf.Goetz@DeutschePost.de"  wrote:

Hmm, not sure what this leads to, concerning the long cc list. I finally decided to use it anyway, to give a public answer to Brans question. Please skip this email now if not interested.

Bran,
I don't think you're interpreting the topic too narrowly. I'd like to see the same focus on 'change and the IT profession'. I, too, want to walk away with something for my fight against windwills within the organization I belong to. On the other hand, one of the many things of value of the Gilb seminars I attended was fertilization of my thoughts with very different ones.

Mit freundlichen Grüßen
--
Rolf Götz, 1F1-6
Abt 1F1, IT Systeme Betrieb und Transport
Telefon +49 228 182 193 22
Mobil +49 175 434 87 37
E-Mail rolf.goetz@deutschepost.de

“There's nothing as practical as a good theory.“ – Kurt Lewin

-----Original Message-----
From: Bran Selic [mailto:bran.selic@gmail.com] 
Sent: Monday, March 30, 2009 5:31 AM
To: Florence, Alfred W.
Cc: Tom Gilb; Kai Thomas Gilb,; Niels Malotaux; Randel Wells; Renze Zijlstra; Richard Jeans; Götz, Z 1F1, BN; Ryan Shriver; Elayne Coakes; Gerold Keefer; Gio Wiederhold; Lars Ljungberg; Giovanni Asproni; Bob Marshall; Richard House; Dr. Kalpana Sampath; Peter Leeson; Chris Dale; CHRIS Matts; Lorne Mitchell; Lech Krzanik, Ph D; Marilyn Bush; Isabel Evans; Jenny Stuart; David Stoughton
Subject: Re: Hello Fellow Participants

Personally, I would like to focus on the culture of professions and, specifically, the IT profession. (including its relationships to management culture, client culture, etc.) -- because this is [1] where I have most experience (and can therefore speak with some knowledge) and [2] where I have a modicum of hope of having some ability to initiate change. Depending on how you define an "organization" this could either fall within the scope of organizational culture (i.e., profession as an organization) or cut across it.

Again, perhaps I am interpreting the topic too narrowly? However, I am motivated by the desire to come out of the workshop with some new practical ideas that I can apply directly to my work (and, also, provide a few of my own that others can utilize).

Once again, please note that this is not meant as a critique of Jerry Durant's presentation (which I liked and which actually fits my objectives to a point). I just want to make sure I understood what we are after here.

Regards...Bran

On Sun, Mar 29, 2009 at 9:54 PM, Florence, Alfred W.  wrote:

 
 

Seems to me that the  focus should be on organizational culture as related to corporate and  government cultures that prevent or enhance the way these organizations  conduct business, develop products and provide services.  
 

 
 
 

From: Bran  Selic [mailto:bran.selic@gmail.com] 
Sent: Sunday, March 29,  2009 7:44 PM
To: Tom Gilb
Cc: Kai Thomas Gilb,; Niels  Malotaux; Randel Wells; Renze Zijlstra; Richard Jeans; Rolf Götz; Ryan  Shriver; Elayne Coakes; Gerold Keefer; Gio Wiederhold; Lars Ljungberg;  Giovanni Asproni; Bob Marshall; Richard House; Dr. Kalpana Sampath; Peter  Leeson; Chris Dale; CHRIS Matts; Lorne Mitchell; Lech Krzanik, Ph D; Marilyn  Bush; Isabel Evans; Jenny Stuart; Florence, Alfred W.; David  Stoughton
Subject: Re: Hello Fellow Participants

 
 
 

 
 

Thanks,  Tom. Two thoughts on this, one of which might spark some controversy (which I  assume may be at least partly desirable):

(1) As one of the slides  points out, "culture" is a multi-layered thing. This presentation tries to go  as deep as it can. While useful as an excellent source of the essential  factors that hide within the term "culture", I wonder how deep we want to go  in our workshop? Personally, I think that we should definitely spend time  examining this level, but not make it our focus -- because it delves  too deep into philosophical issues that most of us may have strong opinions on  but, I suspect, few of us are experts in. We could have a lot of fun doing it,  but I am not sure we will benefit as much. 

(2) The thing that struck  me about the implicit purpose of these slides is that it tells us how we need  to approach other cultures in order to gain something from them, not in  terms of culturual enrichment but, rather, something more material (e.g.,  "Seek opportunities where you are in control". Why?). This, BTW, strikes me as  introducing a very culture-specific bias into the whole thing (e.g., before  they realized that money could be made in India and China but that this  required cultural awareness, corporate culture was generally uninterested in  the cultures of these places). [I have my flame-proof jacket on, so feel free  to fire at will...]

My understanding of our objective is to understand  the impact of culture in our domain (i.e., the development of software and  related systems and their use) and how to effect change within that context  for the better, if possible. Am I missing the  mark?

Cheers...Bran]]></description>
            <author>Kai Thomas Gilb &lt;kai(AT)gilb(DOT)com&gt;</author>
            <pubDate>Mon, 30 Mar 2009 11:01:08 +0100</pubDate>
        </item>
        <item>
            <title>Rocks Into Gold</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=180</link>
            <description><![CDATA[Hi everyone,

Tom invited me to post a link about my business parable "Rocks Into Gold".  It's free (although, if you really want you can buy a paper or pdf copy) and it might just save your job, or a friends job.  It's had over 5000 views to date, it's a very easy and quick read, and the feedback so far has been fantastic.

[http://www.tinyurl.com/rocksintogold]

I hope you enjoy it and find it useful.

Clarke]]></description>
            <author>cching</author>
            <pubDate>Mon, 23 Feb 2009 19:13:53 +0100</pubDate>
        </item>
        <item>
            <title>Virtual Conference on Agile Development</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=178</link>
            <description><![CDATA[Hi friends... this is techiefreak, who is very eager to know more about project management, and to inform you all, there is a virtual conference going on, of which the details that are shown below. so don't worry i am not here to spam, but i found it out very interesting, so if possible checkout guys.
 
Virtual Conference on Agile Development

The first-ever Virtual Conference on Agile Development now gives you the opportunity to showcase your expertise in front of a virtual audience of Project Management experts & PMP Professionals of IT industry.

This event, scheduled from Jan 17-24, 2009, will feature online learning, knowledge sharing, live chat, active movement in and out of this topic, expert presentations, contests, and more!. Beyond the well-prepared topical sessions & interactions, there will be a range of other exciting opportunities for visiting participants to get out and enjoy. Be a part of the inaugural group of experts from IT industry.

Topic of the Conference:
Perspectives on Agile Development

Click here for Participation: http://toostep.com/topic/perspectives-on-agile-development]]></description>
            <author>techiefreak</author>
            <pubDate>Mon, 19 Jan 2009 12:22:47 +0100</pubDate>
        </item>
        <item>
            <title>Is Gilb's Evo A Step away from Agile in the direction of Waterfall?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=176</link>
            <description><![CDATA[Your (Jose Diaz, editor, Berlin, www.diazhilterscheid.de) correspondent asks about our Evo Agile methods

Subject: 2 DAY GILB COURSES IN BERLIN 2009 
Advanced Agile Methods
1. Agile Software Inspections and Reviews
2. The 'Evo' method, a powerful improvement to Scrum and other conventional Agile Methods
	a. Critical Requirements for better control than Stories
	b. Impact Estimation to control and plan iterative cycles to deliver results
	c. Evolutionary Project Management: quantify value delivery to real stakeholders

THE QUESTION: “Is this taking Agile a step back in terms of emphasizing documentation over conversation and collaboration. It sounds a lot more characteristic of waterfall methodologies. “

OUR ANSWER:

1. Agile, especially Scrum, is above all an open learning-process, finding out what works in practice.

2. Agile is NOT about talking-but-not writing.

3. Agile IS about avoiding unnecessary bureaucracy, but also about doing what is necessary for DELIVERING VALUE TO STAKEHOLDERS. Let us call this the 'necessary minimum bureaucracy' for delivering value

4. Our methods are an improvement over conventional Agile methods (like XP and Crystal, see Larman's book on Iterative and Incremental Methods for comparison)) and our methods are a welcome-and-necessary supplement to Scrum, in terms of being very explicit about the several dimensions of value to be delivered to the customer. They improve Scrum!

5. Our value quantification is very minimal (fits on one page for a whole project, quantification of the top 10-25 major value objectives) but is very much more 'super-ordinate' (affects all aspects of whole system - not just one story, or use-case level.) than current agile culture, 'story and use case',  ideas of defining value.

6. There is no question of going back to Waterfall in the sense of avoiding the Evolutionary Iterations. We are the acknowledged historical driver of these iterations (see documentation below) since 1970's and in our 1988 book (PoSEM). 

7. What we do advocate, and most agile gurus have missed thus far, is the quantification of quality and value requirements, and the use of evolutionary feedback to learn how well our design and our development processes are delivering that value in practice. 

8. This 'learning what works' is the primary and central concept of Scrum. 

Do study the material below including the case studies, downloads at gilb.com, and our own agile principles and values.

Best wishes
Tom

 
========== HERE IS SOME GILB AGILE BACKGROUND ===references and Principles and Values====

"Tom Gilb is a freelance consultant, teacher and author serving clients mainly in Europe and the US.
He has 3 books in print: “Competitive Engineering”,  “Principles of Software Engineering Management” and  “Software Inspection”.

He specializes in software engineering, systems engineering, and technical management. He resides in Oslo and London. His most recent papers, book manuscripts, and slides are available on www.gilb.com,

He is cited by many of the Agile community leaders (Beck, Martin, Cunningham, Highsmith, Ambler, Larman, Ladas ) as foundational for their past ideas, and/or stimulating for their current thinking.

Tom, as a real grandfather of 5, likes to think of himself as one grandfather (among many!) of the Agile ideas, and a potential parent of the next generation of Agile ideas.

Ryan Shriver (Dominion Digital) and Per Egil Evensen (Avenir) - both active Scrum Masters, have concluded (and practice) that Gilb's 'Evo' method is needed together with Scrum to deliver value to stakeholders.
 
 ==== Detailed References ======================
November 2008
"In 1976, Tom Gilb argued that evolutionary development resulted in superior software delivery in 
his book Software Metrics and launched a movement toward agile, light, and adaptive develop- 
ment iterations that provided rapid results and more frequently visible business benefits. "
From: CMMI® or Agile:  Why Not Embrace Both! 
TECHNICAL NOTE  CMU/SEI-2008-TN-003 
http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

 
( Oct 10 2008)
Agile History…	http://eprints.ecs.soton.ac.uk/16606/1/xp2008camera_ready.pdf


His book ‘Principles of Software Engineering Management” (1988, now in 20th printing) is explicitly credited by Kent beck and other Agile method leaders as the source of short development cycles and  many other ideas in development of the Agile methods. 

	Comment of Kent Beck on Tom Gilb, Principles of Software Engineering Management: “ A strong case for evolutionary delivery – small releases, constant refactoring,  intense dialog with the customer”. (Beck, page 173). 

In a mail to Tom, Kent wrote: “I'm glad you and I have some alignment of ideas. I stole enough of yours that I'd be disappointed if we didn't :-), Kent” (2003)

 
New Jan 13 2008:
http://leansoftwareengineering.com/2007/12/20/tom-gilbs-evolutionary-delivery-a-great-improvement-over-its-successors/

"But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice."   Corey Ladas


 

Tom is cited by Craig Larman in an IEEE Computer (June 2003) paper on Iterative methods history as a pioneer with his Evo papers and books. Many early papers cited were during his 120 paper bi-weekly ‘Gilb’s Mythology’ stint in the late 1970’s in Computer Weekly (UK). Larman also included a chapter  (10, Evo) in his book,  “Agile and Iterative Development: A Manager’s Guide” (2003) describing Gilb’s contribution to the Agile Iterative class of methods; comparatively with XP, Scrum, Crystal etc.
 
His paper
‘Adding Stakeholder Metrics to Agile Projects’ was published in Cutter It Journal: The Journal of Information Technology Management, July 2004, Vol. 17, No.7, as ‘Adding Stakeholder Metrics to Agile Projects’, pp31-35. www.cutter.com.

Available at www.gilb.com, in Free papers (ID=63), as
The Agile Evo Method: Adding Stakeholder Metrics to Agile Projects (Adding Stakeholder Metrics to IT Projects citj0704TG.pdf)


Jim Highsmith (Editor of  that issue, an Agile Manifesto signatory) commented: “Two individuals in particular pioneered the evolution of iterative development approached in the 1980’s – Barry Boehm with his Spiral Model and Tom Gilb with his Evo model. I drew on Boehm’s and Gilb’s ideas for early inspiration in developing Adaptive Software Development. …. Gilb has long advocated this more explicit (quantitative) valuation in order to capture the early value and increase ROI” (page 4, July 2004).

 

Ward Cunningham wrote April 2005: Tom -- Thanks for sharing your work. I hope you find value in ours. I'm also glad that the agile community is paying attention to your work. We know (now) that you were out there ahead of most of us. Best regards. – Ward, http://c2.com
 
Robert C. Martin (Agile Manifesto initial signatory, aka Uncle Bob): "Tom and I talked of many things, and I found myself learning a great deal from him. The item that sticks most prominently in my mind is the definition of progress.", "Tom has invented a planning formalism that he calls Planguage that captures this idea of customer need. I think I'm going to spend some serious time investigating this. "  from http://www.butunclebob.com/ArticleS.UncleBob.TomGilbVisit



COMPETITIVE ENGINEERING BOOK REVIEW BY AGILE PEOPLE

 
 A "Must Read" Book, February 24, 2006
By	Scott W. Ambler "Author, Agile Database Techn... (Toronto, Canada) - See all my reviews
Tom Gilb, the father of the Evo methodology, shares his practical, real-world experience for enabling effective collaboration between developers, managers, and stakeholders in this book. Although the book describes in detail Planguage, a specification language for systems engineering, the methodological advice alone is worth the price of the book. Evo is one of the truly underappreciated agile methodologies and as a result Gilb's thought-provoking work isn't as well known as it should be, although I suspect that this will change with this book. The book describes effective practices for requirements and design specification that are highly compatible with the principles and practices of Agile Modeling, yet it goes on to address planning activities, quality, and impact estimation. I suspect that this book will prove to be one of the "must read" software development books of 2006.
 SCOTT AMBLER: 	http://www.ambysoft.com
  ------------------------------------------------------
 Hard work, but worth it, January 24, 2006
By	Mr. C. J. Ching (a kiwi in Scotland) - See all my reviews
 
Tom has already written one classic - "Principles of Software Engineering Management". It's a nice easy reading book full of great ideas; I dip into it at random every so often and always find it inspiring. 

This new book will one day be regarded as a classic too, but it is much harder to read. Tom says that he's been working on this book for the last decade and a half and it shows: it's packed full of fantastic ideas, observations and tips, but you do have to work to get them. 

I work in "Agile" software development and, just like Agile, this book is hard work but it's worth it.
 	
5 of 5 people found the following review helpful:
------------------------------------------------------------------------------
 
 A brilliant guide to complex systems development, August 13, 2005
By	Romilly Cocking "Agile development coach" (London, England) - See all my reviews
 
A brilliant guide to complex systems development 
Reviewer: Romilly Cocking from London, UK 
This wonderful book explains how to deliver complex systems within time and budget, with a level of quality that will earn you a "wow!" 

The book defines the five core processes of Competitive Engineering: Requirement Specification, Design Engineering, Specification Quality Control, Impact Estimation, and Evolutionary Project Management. It includes plenty of practical advice and lots of real-world examples. At the back you'll find a detailed glossary that contains precise definitions and detailed explanations of hundreds of the key concepts used in the book. 

I loved the style, which is clear, practical and precise. I found it a demanding but very worthwhile read, not least because of the high density of ideas per chapter. There are things to think hard about on almost every page. Gilb's decades of practical experience in complex systems development are evident throughout the book. 

Strongly recommended.
--------------------------------------------------------------------------------------- 
 At XP Days 2003 Tom participated in a panel. He tries to attend the XP Tuesday club when he is in London. The XP Days 2004 in London he keynoted with “WHAT IS MISSING FROM THE CONVENTIONAL AGILE AND eXtreme METHODS? …” available at http://www.xpday.org/slides.php. (and from www.gilb.com) And in addition held an afternoon double theme tutorial on PRACTICAL EXTREME PROJECT MANAGEMENT (XE) AND EXTREME INSPECTIONS (XI). The conference was sold out. 

Tom was awarded the Best Tutorial Prize for Extreme Inspection at Eurostar Amsterdam Dec 2003 by participant evaluations.

See paper Agile Specification Quality Control: Shifting emphasis from cleanup to sampling defects (Agile Spec QC INCOSE Final.pdf) at www.gilb.com downloads (ID= 57).
 
Tom has been busy piloting he new XE and XI methods in industrial clients with encouraging measurable results. FIRM A/S in Norway reports (using Gilb’s Evo, XE) (http://confirmit.com/news/release_20041129_confirmit_9.0_mr.asp)

    •         Up to 175 percent more intuitive user interface*

    •          Up to 80 percent increased user productivity in questionnaire design and testing*

•  Up to 1500 percent increased performance in Reportal and Panel Management*.
See FIRM Paper at www.gilb.com (ID=32)  FIRM: From Waterfall to Evolutionary Development (Evo). Paper. (Firm-FromWaterfallToEvo-Paper.pdf)
 
A Multinational Finance Giant reports that using the pilot of XI and Gilb’s Planguage for specifying requirements, the major defect level was reduced from 88 majors/page to 11 majors/page after 6 months.
 
These methods and their underpinnings are presented in depth in Gilb’s new book: Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. This is a very well developed handbook on his methods ideas: and hopefully it will be a source of agile ideas in the years to come.

 
See his website for papers and more: www.gilb.com
---------------------------------------------------]]></description>
            <author>Tom Gilb &lt;tom(AT)gilb(DOT)com&gt;</author>
            <pubDate>Thu, 08 Jan 2009 13:35:35 +0100</pubDate>
        </item>
        <item>
            <title>Process Change</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=170</link>
            <description><![CDATA[HERE IS SOME EMAIL DISCUSSION THAT I AM INSERTING INTO THE FORUM DISCUSSION
SEE ALSO RELATED BLOGS TODAY WITH THE BEGINNING OF THE DIALOGUE, Tom G

On 26 Nov 2008, at 17:33,   Lars wrote:
 
I have a lot of both positive and negative experineces from my consulting days.

One example is when I was a mentor to a new quality manager in an organisation,
we defined some issues that needed to be addressed lika a new development process.
When they asked the developers how they felt about this, 2 people were strongly
against it, the rest (round 50 people) said things like: "if we really need it, 
ok, sigh" so they accepted it. When the new process was introduced, one of the 2
initially against it had left, in hindsight this was considered good, the other one
was on the front fighting to get everyone to use the new process!

The results when
it came to code were staggering; systems prior to the new process had pages after 
pages with customer complaints, new systems only had less than a page!

GILB COMMENT: my view is that the only valid reason for a process change, is the MEASURABLY improve some organizational or product attribute in the direction of a planed and agreed target level.

The process change either really moves the indicators towards the planned level, or it needs to be re-evaluated, dumped, improved.

We have the normal situation where there is NO defined, quantified, agreed numeric objective
see
http://www.gilb.com/tiki-download_file.php?fileId=180
for extensive real examples and cases from my experience.

Management is not trained and policy-guided to set numeric targets (except for time and €€).

So far too much 'process improvement (CMMI thing in practice) is done either because someone wants to 'Get CMMI Level 3 by Next Year', or because someone falsely believes that 'Inspection will improve quality in safety critical systems' (ie do inspection [no matter how badly], problem [undefined, 'better quality, or no bugs'] solved).

If the engineers were confronted with the specific targets for improvement in productivity (with more pay to them if they achieved it!!)
and more product reliability early ( with more pay to them if the achieved it)

and were told, we want these results and we believe you do too.

The process changes are supposed to help you get the results. If you have better ideas, more cost effective ideas, and if these ideas are badly designed - LET US KNOW CONSTRUCTIVELY. Give us evidence here or elsewhere that your ideas are more effectives. The process is NOT holy. The result is HOLY, assuming we all agree we need and want the improvement.

Notice you said:
"The results when
it came to code were staggering"
Did anyone explicitly define as an Objective the staggering level of results? Did anyone tell the people whose process was changing? Did anyone motive  them by sharing the value of the benefits with them? if not, we can expect resistence, people do not know whay and do not own any interest in the change.



Another example was with an organisation that also wanted a new method handbook,
since the old one wasn't used. We asked the VP "how are we/you going to get people
to follow it?". The response was; "I will tell them at a meeting". Why the h-ll 
didn't he do this with the current one if it is this easy


GILB COMMENT: I suppose you are with me in total lack of faith that such a declaration would have any major impact on the result? :)]]></description>
            <author>Tom Gilb &lt;tom(AT)gilb(DOT)com&gt;</author>
            <pubDate>Wed, 26 Nov 2008 20:08:26 +0100</pubDate>
        </item>
        <item>
            <title>Major defect</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=157</link>
            <description><![CDATA[Hi, Tom-san,
 
 
This is Nagata,
 
I’d like to confirm one thing.
A design defect should be counted as a major defect.
If a inspector find 25 major defects and two design defects,
The major defects of the agile inspection should be 27, it’s correct, isn’t it ?
 
Best Regards,
 
Atsushi Nagata,  
Japan(:biggrin:)]]></description>
            <author>Atsushi Nagata</author>
            <pubDate>Tue, 14 Oct 2008 08:48:06 +0100</pubDate>
        </item>
        <item>
            <title>Triangle of communication, trust and risk</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=143</link>
            <description><![CDATA[I really love to coach people and teams to build efficient and fearless, communicating communities - also in software projects. 
So if you think this triangle could be interesting for your organisation please feel encouraged to speak to me.
Eckhard
]]></description>
            <author>ejokisch</author>
            <pubDate>Thu, 26 Jun 2008 15:43:12 +0100</pubDate>
        </item>
        <item>
            <title>Risk definition</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=141</link>
            <description><![CDATA[If we change from one existing system to a new system the root risk is that we change the existing system. What else? So every requirement that shall be implemented is in fact a risk.
That's apoint of view I really like.]]></description>
            <author>ejokisch</author>
            <pubDate>Thu, 26 Jun 2008 12:28:36 +0100</pubDate>
        </item>
        <item>
            <title>Doing the right thing / Doing it right</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=140</link>
            <description><![CDATA["Avoiding the Alignment Trap in IT" by David Shpilberg, Steve Berez, Rudy Puryear and Sachin Shah in MIT Sloan Review, Fall 2007

http://sloanreview.mit.edu/smr/issue/2007/fall/02/

Describes 2x2 matrix: Doing things well and Doing the right thing

]]></description>
            <author>allankellynet</author>
            <pubDate>Wed, 25 Jun 2008 15:04:17 +0100</pubDate>
        </item>
        <item>
            <title>Maintainability including ...</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=136</link>
            <description><![CDATA[Any ideas on this? Sorry I'm too confused to make it more clear.

At my company there is no formal definition of maintainability. There is a strong connection to budgeting, because the IT division pays for maintainability, while the (internal) client's division pays for (new) development.

I cannot really identify exactly and completely what is included in maintainability. Therefore I'm not really able to make sense of the great engineering ideas of Tom's talk on Maintenance. 

Here's what I am sure of. Any ideas?

Maintainability costs include (number of occurences in 11 respective proposals in {square-brackets}):
- SW-infrastructure-only changes (new OS, new DBMS(-Version), new Java-Version, ...) {4}
- HW-infrastructre-only changes (new servers, new processors, switch to virtual servers, ...) {2}
- new versions of middleware (SOA, etc) {1}
- adjustments to some reports of Management Information Systems because of 'new strategies' {2}
- changes to interfaces because the interfaced system changed something {6}
- Refactoring (new buzzword within my company) {3}
- better algorithms for some tasks {1}

Note, that maintenance explicitly DOES NOT contain anything that has to to with fixing bugs/problems from the user perspective. Yet bugfixing-costs are not factored into the developments cost either. 

In addition to development costs and maintenace costs we also have a category called "costs of maintenance-near development" ?!?

Any ideas on this? Sorry I'm too confused to make it more clear.]]></description>
            <author>rolf</author>
            <pubDate>Wed, 25 Jun 2008 09:47:10 +0100</pubDate>
        </item>
        <item>
            <title>Positive and negative risk: Contingency management?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=19&amp;comments_parentId=135</link>
            <description><![CDATA[In the FILES section, Tom has posted some information with the explanation, "Some risk related concepts ... Gilb's Planguage Concept Glossary. This relates to the discussion Don Mills and Matthew Leitch had in class about whether Risk should encompass both negative and positive deviation."

Our conclusion was that it shoiuldn't, despite the decision of both national and international standardisation bodies (A/NZ and ISO).  The decision is sort-of defensible at a mathematical level (like "negative inflation" or "negative termperatures"), but in ordinary English a risk is "the possibility of an event with negative outcome".  Risk - "bad", not "good".

"Contingency" is a term that covers both "positive risk" and "negative risk", its central definition is, "A thing that may happen at a later time; a condition that may or may not be present in the future" (Oxford); "Event that may or may not occur in a given time period" (Insurance Dictionary); "An unforeseen factor related to construction which is not specifically addressed in the budget" (Architecture Dictionary); "the status of facts that are not logically necessarily true or false" (Wikipedia).  These definitions only *imply* the occurrence of a (contingent) impact, but this implication is inherent in the term, "contingency planning".

"Contingency planning" seems normally to mean "Negative contingency planning", i.e., "risk planning" in its normal use, but "contingency management" seems not to have that meaning.  In fact, except for a Microsoft White Paper, its use on the Internet seems to relate to a technique for human behaviour modification, where "contingency" has a somewhat specialised definition.

The suggestion is, then, that the proper subject of AS/NZS 4360:2004 (and ISO/IEC 27005) is not "Risk Management" but CONTINGENCY MANAGEMENT: both avoiding/minimising risks, and grasping/exploiting opportunities; and that this wider focus is in-line with the theme for this Seminar, which concerns "Smart, Realistic and Innovative tactics for managing risk and uncertainty in projects."

Any takers for a discussion on "Unexpected Opportunity Management"?

(I feel the need for a "CMMM" coming on: Level 1: "Screw it! Let's Do It"; Level 2: "Grasp opportunity!"; Level 3: "Manage risk"; Level: 4 ... well, any takers for developing a CMMM?)

-- Don]]></description>
            <author>donmillion</author>
            <pubDate>Tue, 24 Jun 2008 16:19:10 +0100</pubDate>
        </item>
        <item>
            <title>Planguage Writing Support Tools</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=126</link>
            <description><![CDATA[What are people using to write Planguage?

Is there is a Planguage editor available that: is aware of the components of the various kinds of tags and prompts the author if requested, supports breadth first writing style and then depth refinement (with click on links to move around the document),  supports version control, shows a graphical overview of the relationships between the tags, and can export the current document format to a report in xhtml (and possibly Word).
]]></description>
            <author>drpratten</author>
            <pubDate>Sun, 30 Mar 2008 02:02:43 +0100</pubDate>
        </item>
        <item>
            <title>Evo approach to learning Planguage</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=125</link>
            <description><![CDATA[I have just been given a copy of "Competitive Engineering" and found it refreshing and informative, but it has left me with a question. I would value an Evo approach to learning Planguage.  E.g. The book’s key stakeholder is the reader and the reader’s interest is to do better at using Planguage for competitive engineering.  Could the reader be offered a useful portion of Planguage competency to apply in their work for a 2% investment in reading the book? If a reader got positive feedback after a 2% investment then they would be motivated to come back and read the remaining 98%!]]></description>
            <author>drpratten</author>
            <pubDate>Sun, 30 Mar 2008 01:58:55 +0100</pubDate>
        </item>
        <item>
            <title>IS SOFTWARE QUALITY MEASUREMENT A MATTER OF SUBJECTIVE JUDGEMENT?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=117</link>
            <description><![CDATA[I WOULD LIKE AN OPINION BECAUSE I THINK IT IS MUCH OF AN OBJECTIVE JUDGMENT RATHER THEN A SUBJECTIVE JUDGEMENT]]></description>
            <author>zykleo</author>
            <pubDate>Fri, 19 Oct 2007 13:29:23 +0100</pubDate>
        </item>
        <item>
            <title>Disambiguation</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=111</link>
            <description><![CDATA[Hi,

Function (*069) v. Function Requirement (*074)

Could you (Tom, Kai, anyone...) disambiguate these two terms from your glossary.  There is so much overlap between them, but they are not compared and contrasted to make it obvious where one should be used and not the other.  You must have had a good reason to keep them as distinct entries in the glossary.  Could you perhaps give an example which uses them both, so that there different intended application becomes obvious.

Many thanks,
Torsten Louland]]></description>
            <author>tlouland</author>
            <pubDate>Thu, 02 Aug 2007 13:05:07 +0100</pubDate>
        </item>
        <item>
            <title>Some experience</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=107</link>
            <description><![CDATA[
Some experience of quality quantification and planguage using.

Project: 
My project is a part of big one. So I have a lot of design constraints. Also our project is a new generation of existing one. So a lot of work is concerned about functions reimplementation.
Of course, as Tom & Kai say all functions already exist and any project make sense only as a quality improvement. But in case of complex systems a project may improve quality of only some functions, but at the same time it has to reimplement all other functions. Thus, biggest part of my specifications is functional requirements.

Planguage using:
I changed tag “Tag” to “Mnemonic”. It’s probably not important at all. But for me it was easy to use “Mnemonic”, more over name “Tag” is often used in programming. For instance in .Net Framework it’s very common class property, so to avoid ambiguous meaning . . . 

Also, I found what I need one else property/field for my specifications. Due to the fact that I build a requirements tree I need “node” type of requirements. 
So I have added special field – “Kind” to my requirements specification format.
“Kind” – can be “simple”, “synthetic”, “average”.
Simple – regular requirement specification which has its own scale, meter and values. At the same time it cannot have any sub requirements
“Synthetic” – requirement, which does not have its own scale. But it has sub specifications so it has normalized values as an average among sub specifications.
“Average” – I’m not sure yet, should I have it or no. The idea is used “Average” kind of nodes specifications when all sub specifications have same scale.

I don’t remember have I seen or not a weight ratio in planguage, but anyway I used it as well.


Tools:
I started write specifications on MS Excel. It was enough while I have only one level of specifications. But on the second level of specification I’ve found Excel is not good enough.
So I spend a few days and know I have my own application which fits my requirements to a requirements specifications tool.
It’s pretty simple. Tree view control is used for navigation on a projects requirements tree. Plus, specification view to and browse/edit selected specification. 



/Mark.B./
]]></description>
            <author>mbalonkin</author>
            <pubDate>Mon, 07 May 2007 07:10:27 +0100</pubDate>
        </item>
        <item>
            <title>Performance Indicator</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=103</link>
            <description><![CDATA[Hi all,

I'm a IS student, currently doing research on requirements engineering. 

I'm confronted with the following issue: How can you jugde the requirement process of a given company? are there performance indicators related to the process?

Thanks for any answer,

Regards,

Thierno Diallo]]></description>
            <author>Thierno</author>
            <pubDate>Mon, 02 Apr 2007 07:31:26 +0100</pubDate>
        </item>
        <item>
            <title>Theory on why it is hard to distinguish Requirements from Design</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=101</link>
            <description><![CDATA[IsLinkedTo: Kai Gilb's Evo book, section "Why people communicate ‘How’ and not ‘How well’"

I refer to the matching pairs questions-answers, problems-solutions, requirements-designs. It seems that requirements writers tend to blend stakeholder's real requirements with preliminary design. Even up front, some stakeholders come up with a design idea (or even design constraints), camouflaged as a requirement. (:evil:)

My theory for explaining this phenomenon is the following. 

By inventing the computer, man has introduced a need into the world, that has not been there before: the need to define problems. Writing requirements for computer-based systems basically is defining problems. The need is new, because the computer is an universal machine. Before the computer, all machines and other man-made tools where single-purpose devices. 
And this is the reason for the struggle of our discipline requirement engineering. Man is has not been properly equipped with the ability to define problems; in contrary, man (and all life) has always been very well designed to solve problems. In effect, evolution hinders people to write good requirements! (:wink:)

This is probably the shortest way to express the idea, I hope you can understand what I mean.
What do you think?]]></description>
            <author>rolf</author>
            <pubDate>Fri, 30 Mar 2007 11:13:09 +0100</pubDate>
        </item>
        <item>
            <title>Trend</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=99</link>
            <description><![CDATA[In Competitive Engineering (Gilb, 2005), the Elementary Scalar Requirement Template seems to call for the Trend value as a mandatory field.  My understanding of Trend is that it is a projection of how the process would change over time, independent of the changes being specified in the requirement (i.e. the competition's actions, scheduled upgrades on the existing platform, etc.).  However, what should be documented in the case where no improvement over the existing baseline - Past - is anticipated?  Should the author of the requirements repeat values captured in Past in the Trend field?

]]></description>
            <author>dmelnyk</author>
            <pubDate>Wed, 14 Mar 2007 13:11:39 +0100</pubDate>
        </item>
        <item>
            <title>Gilb 88</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=85</link>
            <description><![CDATA[Hello
I am IS student
I given a homework about the difference between the spiral model & incremental development gilb 88

I found an enagh information about spiral model 
but I did not find info about gilb 88
can any one help me?]]></description>
            <author>amn</author>
            <pubDate>Fri, 10 Nov 2006 17:16:57 +0100</pubDate>
        </item>
        <item>
            <title>Requirement Management Tools supporting planguage</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=84</link>
            <description><![CDATA[Are there some requirements managemant tools that support planguage?  What tools do people use for requirements specification when using planguage?]]></description>
            <author>sye</author>
            <pubDate>Fri, 03 Nov 2006 15:46:14 +0100</pubDate>
        </item>
        <item>
            <title>Setting the requirements</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=81</link>
            <description><![CDATA[How do you know, what is the correct level of requirements to be set?
For example, when you are shopping for a house to live in, nobody is questioning "Do you want there to be doors?" or "Would you mind if the temperature is always sub-zero?"
As a potential buyer, you don't state these explicitly either.

In software world, if you need a new operating system, everybody knows you'll need a task scheduler. Or in case of a word-processor, copy&paste is a necessity, you don't state it explicitly. These are known as commodities.
If your primary business is developing commodity software, you may have hard-time deciding, which of the requirements are worth stating explicitly / measurably. If you try to set them all.. well, you will spend five years specifying requirements for software what may take one to build. And at that point you'll see, the old requirements are not valid anymore.

Any comments on that?]]></description>
            <author>spoimala</author>
            <pubDate>Wed, 25 Oct 2006 18:38:13 +0100</pubDate>
        </item>
        <item>
            <title>Estimating impact of backroom activity?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=80</link>
            <description><![CDATA[During your presentation in Helsinki, you showed some examples of using IE table as a way to decide, what to do next (what is the next Evo step) and inspect the actualised benefit and cost. So it's all about Evo steps. How and where do you estimate the backroom activity?
Let's imagine at some point you have 4 alternative designs, each of which will take a month to implement. How do you estimate, which one to take and put into backroom? And how to you monitor the progress of BR-activities, as they will surely have an impact on which are the next Evo steps.]]></description>
            <author>spoimala</author>
            <pubDate>Wed, 25 Oct 2006 18:19:03 +0100</pubDate>
        </item>
        <item>
            <title>Definition</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=72</link>
            <description><![CDATA[Hi, all!

I'm interested in the definition of defect prevention. 
I myself think of testing as just fixing defects in code that have already been made. Some could say that you are preventing the customer from seeing the defects.
On the other hand, I used to consider defects found inspections (and subsequently removed) as prevented. Now I'm no longer sure.

How do you define defect prevention?

Miska]]></description>
            <author>Miska Hiltunen &lt;miska(DOT)hiltunen(AT)qualiteers(DOT)com&gt;</author>
            <pubDate>Wed, 26 Jul 2006 21:54:51 +0100</pubDate>
        </item>
        <item>
            <title>LET'S TALK ABOUT CE !</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=7&amp;comments_parentId=69</link>
            <description><![CDATA[LET'S TALK ABOUT CE!
Hello web people interested in Competitive Engineering , the book! I must apologize for some of the old website comments pre May 3 2006, that were simply moved from our old website. We should get rid of them. But we did it to get the ball rolling. The book is now published so I am offering to answer questions or reply to comments about about it, here. Thanks Tom Gilb (:rolleyes:)]]></description>
            <author>Tom Gilb &lt;tom(AT)gilb(DOT)com&gt;</author>
            <pubDate>Fri, 26 May 2006 16:16:08 +0100</pubDate>
        </item>
        <item>
            <title>Looking for opportunities</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=18&amp;comments_parentId=68</link>
            <description><![CDATA[Dick Holland, practitioner in Gilb and other methods, is looking for opportunities preferably in or near London, UK. Anything considered: permanent or temporary, full- or part-time.  See my paper on Inspection [http://www.gilb.com/community/tiki-download_file.php?fileId=34|here] and slides [http://www.gilb.com/community/tiki-download_file.php?fileId=73|here].

View my resume at [http://www.linkedin.com/in/dickholland|LinkedIn]. Contact me at [mailto://dick@xegetix.com|dick@xegetix.com]

FROM TOM GILB:
Dick is one of our best clients. He knows how to patiently make change happen. How to create a really positive climate for change. He is a great communicator. Any business that wants to make our methods happen will be lucky to get Dick Holland to help them do that. Tom

]]></description>
            <author>dickholland</author>
            <pubDate>Thu, 25 May 2006 17:30:08 +0100</pubDate>
        </item>
        <item>
            <title>I just moved all the messages over. 9. april 2006</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=49</link>
            <description><![CDATA[I just moved all the messages over from the old message board.

It is done a little quickly (it was boring), but it should all be readable.

Kai]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:28:39 +0100</pubDate>
        </item>
        <item>
            <title>Updated July 18th 2003. Hope all is OK</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=2&amp;comments_parentId=48</link>
            <description><![CDATA[

Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Thursday, July 17, 2003 - 08:56 pm:   	
Updated July 18th 2003. Hope all is OK]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:25:45 +0100</pubDate>
        </item>
        <item>
            <title>SW Development Survey</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=45</link>
            <description><![CDATA[

Stephen Bear
Posted on Thursday, July 17, 2003 - 07:38 pm:   	
By Stephen Bear on Tuesday, July 02, 2002 - 04:50 am: 

If our knowledge about SW Engineering is to be anything more 
than "meagre and unsatisfactory" then we must gather 
comparable data and extract quantified insights and 
understanding. 

Below you can find details of how you can contribute to 
building this emerging scientific understanding. In return 
you will receive details of the early results. 
------ 

To leaders of software projects-- 

(1) Fill out a survey on your completed software development 
project and we'll send you a collection of insightful 
information on fast and flexible software development. 
Visit http://web.mit.edu/surveys/pearl to start the survey. 

(2) Please forward this message to leaders of other 
completed software projects so they can fill out the survey 
too. 

(3) Here's the background on the survey: 
For the past three years, three leading professors have been 
leading research on flexible software development: 

* MIT's Mike Cusumano, author of "Microsoft Secrets," 
"Competing on Internet Time: Lessons from Netscape and Its 
Battle with Microsoft," and "Japan's Software Factories" 
* Harvard's Alan MacCormack, author of "How Internet 
Companies Build Software" and "Developing Products on 
Internet Time" 
* University of Pittsburgh's Chris Kemerer, an expert in 
software metrics and process 

The research has two main objectives: 
1 To identify and document best-known methods for increasing 
performance in software development, such as speed, 
flexibility, and quality 
2 To identify and understand what types of approaches to 
software development work best in different types of 
projects 

To achieve these objectives, a survey was developed. The 
survey was beta tested in HP. Leaders of 29 projects 
responded. The results gave powerful insights into how to 
make the promise of flexible software development a reality. 
Steve McConnell (author of "Rapid Development" and "Code 
Complete"), editor of "IEEE Software," asked us to write an 
article based on the research for his journal. IEEE Software 
is one of the leading periodicals for software research. We 
have submitted the paper for peer review and publication. 

We are now conducting the survey worldwide, asking companies 
globally in many different industries to submit surveys. 

All project-specific data will be kept confidential by 
researchers; only summary results and project data that 
cannot be matched to a specific project will be included in 
published results. 

Thank you in advance for filling out the survey. We 
appreciate your 
contribution.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:22:40 +0100</pubDate>
        </item>
        <item>
            <title>Thesis on software inspections</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=44</link>
            <description><![CDATA[

Gemma Hale 
Posted on Saturday, February 07, 2004 - 05:00 pm:   	
I doing my university thesis on software inspections, especially concentrating on collaborative software inspection systems and was wondering of anyone could give me some advice (such as journals or any personal experience you have had with them)? 

Thanks 
 
---
Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Friday, September 17, 2004 - 04:00 am:   	
Your question is very broad. 
Broad advice: Read the Software Inspection Book. 
Specific ideas: collaborative systems or not, might not matter much. Is the fundamental inspection prossess effective and efficient. Measures. What does it cost, and what does it save? 

Specific questions would be good. 

Kai]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:22:11 +0100</pubDate>
        </item>
        <item>
            <title>Relationship EVO and Architecture</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=43</link>
            <description><![CDATA[william adams
Posted on Thursday, July 17, 2003 - 07:40 pm:   	
By william adams on Monday, June 30, 2003 - 10:18 pm: 

IMHO 
SYSTEMS architecture is absolutely vital to success. It is 
the high level front end of systems engineering. Using 
common sense and logic with standard SE techniques is 
necessary but not sufficient. Architecture requires art not 
just science. As much as management would like to deskill 
architecting, it will always require a senior person with 
wide experience, soft skills, and an innovative out of the 
box approach. Maier's book gives heuristics to use as a 
guide, but knowing when they do not apply is part of the 
architect's skill. Do not confuse systems architecture with 
c4isr views nor the lower level domain architectures eg 
software, hardware, information, database, security, etc.. 
Starting with the vision and conops and the systems 
architecture, continued refinements are made. There may 
well be technical architectures eg software under the 
systems architecture. Conceivably in a very large and 
complex system there may even be lower level architectures 
before design specifications start their refinements working 
their way down to something that is implementable eg a 
software module. 

One key aspect of SYSTEMS architecture is that it 
determines the REAL REQUIREMENTS eg Kennedy said put a man 
on the moon (arguably that was a political solution and not 
a real requirement but it serves for our example) {direct 
rocket versus hopping from a space station were solutions to 
be analysed -- the one picked was not a requirement but 
merely the constraint the architect put on the next level of 
engineering}, in CONTEXT including the environment and 
existing systems, identifies and allows for REAL CONSTRAINTS 
including physical laws and current technology, while 
avoiding as many arbitrary non-constraints as possible 
whether political, legal, corporate policy, or other PHB in 
the box thinking, and then derives "requirements" that are 
more detailed and can start the whole process going. These 
so called "requirements" are really the architects solution 
which constrains the next level of work. They also, at this 
level, include both FUNCTIONAL AND NON FUNCTIONAL 
"requirements". 
Non functional requirements are constraints on the domain 
engineers and will be allocated downward as the 
specifications are refined. 


Part of our problem is the inprecise use of the English 
language. Requirements are exactly that which MUST be done. 
All other so called "requirements" are really solutions that 
are subject to change and should be changed to the 
optimisation of the system based on suggestions from lower 
IPTs and an analysis of their recommended improvements. 
This process should follow my helical model until a correct 
buildable solution has been defined. 

Additionally, the super and metasystems need to be 
considered. IE The enterprise creating a new system is also 
a system and how it works will affect the development 
effort. Enterprise architecture is a lot more than LANs and 
intranets although many tekkies have tunnel vision and 
misuse the word (systems) architecture for these subsystems.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:21:13 +0100</pubDate>
        </item>
        <item>
            <title>Any Comment on Glib's following statement</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=42</link>
            <description><![CDATA[

James 
Posted on Thursday, July 17, 2003 - 07:30 pm:   	
Any Comment on Glib's following statement : 

' The project manager, either through ineptitude, or experience and cunning, 
usually has a situation where the exact nature of the project deliveries are 
entirely unclear. This has the effect of allowing him to deliver something, 
really anything, that is ready by the deadline, and claim on-time delivery.' 
(Glib 1988) 

The argument of this statement would be based on many factors and 
situations. I hope to get some comments in order to start the discussion for 
the above statement. 

Thanks 
James 
jchangkm2@yahoo.com
 

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:32 pm:   	
By Tom Gilb (Tom_Gilb) on Tuesday, October 02, 2001 - 08:53 
am: 

James it is difficult to comment without referring to all I 
have written and 
on the website! But, let me assert that you must do projects 
Evolutionarily. 
See the Evo slides on the website. Tom Gilb
 

Anonymous
Posted on Thursday, July 17, 2003 - 07:33 pm:   	
By Anonymous on Wednesday, January 23, 2002 - 01:02 pm: 

Since 1988, we have moved from failing to deliver projects 
to failing to deliver Programmes. We have therefore the 
excuse to avoid implementing the sort of precision you 
advocate Tom until much later in the delivery process! What 
it does mean is that we can claim evolutionary delivery in 9 
month steps and fool ourselves that by doing so we are 
manging the risks. What are your thoughts on the differences 
of managing major Programmes versus projects?
 

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:34 pm:   	
By Tom Gilb (Tom_Gilb) on Thursday, January 24, 2002 - 12:38 
pm: 

Well there is the obvious - size. 

But the principles of control of risks is in my view the 
same almost irrespective of size. 

And I speak having done very small and very large (over 
1,000 engineers) projects and succeeded using Evo for 
example in all cases. I do not think you can really do Evo 
properly and fool yourself! 

Remember Evo means delivering useful stakeholder value in 
practice on all those steps. So how can you fool yourself? 
You could fool yourself if you do not do Evo properly and do 
not really deliver 
real value on each step! 

Best Wishes Tom
 

Niels Malotaux
Posted on Thursday, July 17, 2003 - 07:38 pm:   	
By Niels Malotaux on Saturday, July 06, 2002 - 02:45 pm: 

If you cannot even control the successful delivery of 
projects, who made you responsible for delivering programs? 
With Evo, projects and programs are delivered successfully 
on time. Period. If you couldn't do that, it reminds me of 
Deming's saying: "Teaching of beginners should be done by a 
master, not by a hack". If you did not succeed, either you 
didn't know how to apply the Evo methods, or you (or your 
management) were not serious in getting results. If you 
weren't anonymous, we could start helping you how to achieve 
results on time!]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:20:34 +0100</pubDate>
        </item>
        <item>
            <title>Agile software development</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=41</link>
            <description><![CDATA[

Anonymous
Posted on Thursday, July 17, 2003 - 07:35 pm:   	
By Anonymous on Friday, February 01, 2002 - 07:50 pm: 

What are your thoughts on agile software development? I'm a 
student, and in my class there are people claiming that 
agile software development processes, like XP and Crystal 
Family will solve much of the problems we see in software 
development today. 
I personaly don't know what to think?? 
Any advice, comments??
 

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:35 pm:   	
People have been claiming for decades ( I have been watching since 1960) 
that some methods were going to solve the software problem. But they did not 
and the problem is worse than ever. 

XP won't do it, and I don't know what Crystal Family is so, now I'm the 
student and you can teach me! 

There is a very simple test: there is either research that clearly shows a 
method solves some problems (Inspection method and data about it for 1500 
companies or so in Capers Jones books are examples of that) - or it probably 
has not and will not. 

Be scientific - believe what hard statistical data tells you. Everybody 
else is dangerous to listen to. The software business is resplendent with 
fools who believe in the latest thing. They wasted billions of equally 
foolish investor money in the dot coms. Their projects fail ( statistically) 
50% of the time. See Karl Wiegers Peer reviews in Software and Ralph Youngs 
book on requirements for people who gather good facts. 



Best wishes Tom
 

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:36 pm:   	
By Tom Gilb (Tom_Gilb) on Saturday, February 02, 2002 - 
04:41 am: 

People have been claiming for decades (I have been watching 
since 1960) that some methods were going to solve the 
software problem. But they did not and the problem is worse 
than ever. 

XP won't do it, and I don't know what Crystal Family is so, 
now I'm the student and you can teach me! 

There is a very simple test: there is either research that 
clearly shows a method solves some problems (Inspection 
method and data about it for 1500 companies or so in Capers 
Jones books are examples of that) - or it probably has not 
and will not. 

Be scientific - believe what hard statistical data tells 
you. Everybody else is dangerous to listen to. The software 
business is resplendent with fools who believe in the latest 
thing. They wasted billions of equally foolish investor 
money in the dot coms. Their projects fail (statistically) 
50% of the time. See Karl Wiegers Peer reviews in Software 
and Ralph Youngs book on requirements for people who gather 
good facts. 


Best wishes Tom
 

Iain Brown
Posted on Monday, February 02, 2004 - 06:13 am:   	
Tom and anonymous, 

I have very strong views on so-called extreme programming and agile software. It's rubbish. It's the latest excuse not to do the job properly. I have just finished part of a project (as the QA input) where most of the software had already been written, based on inadequate requirements and specifications, before the QA team joined. Development got a pat on the back for completing the build in a ludicrously short time, but there were precious few accolades for the quality team who found literally hundreds of defects in both the documentation and the software before it went out to the customer. Spare me quick fix solutions to complex problems - there aren't any! 

Regards, 

Iain
 

Tom Laine 
Posted on Tuesday, October 12, 2004 - 04:31 pm:   	
I recently finished a book on "Computer Software Development & Patenting Computer-Implemented Inventions", for which I studied lots of different academic approaches as well as interviewed companies like Microsoft, Nokia, First Hop, TeliaSonera, Jon "MadDog" Hall (Linux International), etc., other software specialist and several academics. No matter what kind of approach these people used in programming, testing, etc., the conclusions are as follows. 
Most important phases of software development project(sw programming in any language) were 1.Spesifications; the better specs' the higher possibility to succeed. 
2.Production; programming and testing iteratively & in modules or "objects". 
3.Integration, testing and publishing; final testing, analysis & maintenance. 
A waterfall-like implementation was seen by far the most common and iteration was seen as a real virtue. Something most companies felt as a factor most commonly put too little effort on in a sw project was... Marketing! 
XP was mentioned by few as their main approach to a SW project and was seen as a future possibility for many, but the old 'Waterfall' was seen as the best solution for today's sw projects. 
Now I don't know what I would use myself, but I have learned one thing through this last project: watch before you do, don't go with the flow even how attractive and 'hip' new style. Sometimes it's better to do things like we've used to...But maybe I'm just weird that way ;-) 
 

Editor
Posted on Thursday, January 13, 2005 - 04:30 pm:   	
In the last issue of Methods & Tools, I published two articles presenting Scrum and Feature Driven Development, two agile approaches of software development, written by practicionners of these approaches. 

I agree that there is no silver bullet, but I think that Agility can work in some cases. I think also that this movement bring back the emphasis on some important aspects that are often neglected in many software development organisations: the importance of people and communication, the importance of inspecting and testing code, the fact that you have to deal with requirements that can be changing. Like many other ideas, results of agile projects are in my mind more influenced by the people who run the project than the approach adopted... 

To read this issue, go to 
http://www.methodsandtools.com
 

Anonymous
Posted on Monday, May 02, 2005 - 03:05 am:   	
Good Agile Management tool: 
TargetProcess http://www.targetprocess.com 

Features: 
* Planning Module 
- Extreme Programming style project planning (iterative development) 
- User stories management 
- Releases and Iterations planning 
- Project dashboard 
- Personalized ToDo lists 
- Burn Down chart 
- Multiple projects support 

* Bug Tracking module 
- ToDo list for bugs 
- Bug dashboard 
- Stats and charts 
- Comments and changes history 
- Attachments 

* Time Tracking module 
- Time Tracking for projects and user stories 
- Time sheets 
- Tasks for user story 

* WYSIWYG for user stories & bugs editing 
* Automatic installer 
* Basic projects permissions 
* Automatic notifications 

FREE Version of Planning module is here http://www.targetprocess.com 

Full Demo version: http://fulldemo.targetprocess.Ðcom/default.aspx 
login: admin 
pwd: admin ]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:19:57 +0100</pubDate>
        </item>
        <item>
            <title>SW Quality Magazines</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=4&amp;comments_parentId=40</link>
            <description><![CDATA[

Anonymous
Posted on Thursday, July 17, 2003 - 07:39 pm:   	
By Anonymous on Thursday, April 03, 2003 - 10:49 am: 

Do you happen to know if there are any good SW Quality 
magazines available for subscription?
 

tom gilb 
Posted on Saturday, January 31, 2004 - 11:56 am:   	
Yes IEEE Software and IEEE Computer are good starts. OtherwiseGoogle search for papers on the subject. I will send my publications list by email on request, including web publications
 

Editor
Posted on Monday, May 10, 2004 - 03:07 pm:   	
Methods & Tools is a free e-newsletter providing practical knowledge for software development professionals with many articles on software quality. 
To download or read current and past issues go to http://www.methodsandtools.com]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:19:22 +0100</pubDate>
        </item>
        <item>
            <title>Evo Task Administration tool</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=39</link>
            <description><![CDATA[

Niels Malotaux 
Posted on Tuesday, March 23, 2004 - 05:15 am:   	
In all of the projects I coach on Evo, prople are using the ETA (Evo Task Administration) tool to administer Evo Tasks. Have a look at http://www.malotaux.nl/nrm/Evo and especially at http://www.malotaux.nl/nrm/Evo/ETAF.htm to get the tool. The tool also provides useful insight for management to know whether a project is in control or not. Note: you need to have MSAccess2000 or newer. I'm working on a Internet Browser version of the tool, but this may take some more time.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:15:06 +0100</pubDate>
        </item>
        <item>
            <title>Requests</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=7&amp;comments_parentId=38</link>
            <description><![CDATA[

Anonymous
Posted on Thursday, July 17, 2003 - 07:13 pm:   	
By Anonymous on Thursday, January 11, 2001 - 06:35 pm: 

Wouldn't it be nice to get the CE manuscript into just 
plain HTML? Is there some way I could help make things 
easier for readers like that?
 

tom gilb 
Posted on Saturday, January 31, 2004 - 11:59 am:   	
If you want to do the editing we will give you the manuscript. Tom 

We are particularly interested in getting the full 640 term Glossary done in html or wiki or some such as it looks like it will be a free download on the web, and will not go into the final book (too costly, doubles price of the book from 40 euros to 80) Tom
 

Nathan Ward 
Posted on Tuesday, February 10, 2004 - 07:20 am:   	
Hello Tom, 

No guarantees, but I've been working with J2EE web application development for several years now and we've made some tools that may or may not help with this. 

What format is the manuscript in besides PDF? Is the source in MS Word and then you convert it to PDF? Is it stored as one document or multiple documents? 

Nathan]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:13:13 +0100</pubDate>
        </item>
        <item>
            <title> Requirements</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=7&amp;comments_parentId=37</link>
            <description><![CDATA[

Anonymous
Posted on Thursday, July 17, 2003 - 07:15 pm:   	
By Anonymous on Thursday, January 11, 2001 - 06:55 pm: 

Greetings from Aachen, Germany. 

We downloaded your Requirements Driven Management script and 
want to analyze Planguage in respect to general requirement 
engineering principles. 
Therefore we asked ourselves, if Planguage supports 
different views on the resulting requirement specification 
written in Planguage. From the customers or users views as 
well as from requirement analysts or designers views.Thanks 
in advance for helping us in this topic.
 

WMJ
Posted on Thursday, July 17, 2003 - 07:16 pm:   	
By W.M. Jaworski on Wednesday, January 17, 2001 - 06:34 am: 

I just finished my first (process- and plug-able) model of 
"top process" ( page 9 out of 230). The model allows to 
create 'different views' by hiding irrelevant (for viewer) 
components of the complete model. I am new to the Forum 
style and technique, therefore if you give me e-mail address 
I will send 2 views (14 and 40 KB unzipped) of the "top 
process". BTW Which processes (subprocesses) from the 
Competitive Engineering manuscript you consider the most 
important or in the 'best shape'in the manuscript. Processes 
in 'good shape' are easier for me to capture. 
Regards 
WMJ
 

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:16 pm:   	
By Tom Gilb (Tom_Gilb) on Friday, January 19, 2001 - 03:43 
pm: 

W. M. Jaworski 

Please send after jan 22nd to gilb@acm.org. Consider 
modelling processes in 
the CE book which are now even better defined by 

lindsey@brodie.source.co.uk 
the editor 
pleaase send zipped files 

tom]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:12:34 +0100</pubDate>
        </item>
        <item>
            <title>Checking Rate</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=36</link>
            <description><![CDATA[

niels 
Posted on Thursday, July 17, 2003 - 06:44 pm:   	
PS This message was forwarded from the old forum by the 
Admin. 

Looking at the &amp;quot;Defect density against Inspection 
rate&amp;quot; graph in the book Software Inspections on 
page 334, figure 16.5, I get the feeling that this figure 
seems to indicate that 

Inspection rate * Defect density = constant 

(note the units calculation: pages/hour * defects/page = 
defects/hour) 

Example: 
~1.5 defects per page in 40 pages (total 1.5 * 40 = 60) 
~3 defects per page in 20 pages (total 3 * 20 = 60) 
~6 defects per page in 10 pages (total 6 * 10 = 60) 
~12 defects per page in 5 pages (total 12 * 5 = 60) 

The implication is that the total number of defects found 
per hour is constant and does not depend on the number of 
pages inspected in that hour. It would indicate that there 
is some fixed time to find any defect. 
This would imply that taking a sample of a few pages from a 
long document and inspecting these for a certain time would 
yield the same result as skimming through the whole document 
(probably less deep thinking about every page) during the 
same amount of time. Probably the type of defects found is 
not the same. And by skimming the whole document one could 
not come to some statistic conclusions. Still, I have a 
feeling that these results should not be the same (think 
about the optimum rate for our brain for correlation), 
however, according to the figure (the statistics recorded, I 
assume) they seem to be the same. 
What do you think of this?
 

Tom Gilb 
Posted on Thursday, July 17, 2003 - 06:45 pm:   	
By Tom Gilb (Tom_Gilb) on Thursday, January 11, 2001 - 06:11 
pm: 

Niels 
You are the first person who has pointed this out to me. 
It is not as unexpected or strange as you might think. The 
number of defects found are a function of the time you have 
used to find them, no matter how fast you check product 
pages. 
The essential point of checking single pages more slowly is 
that we find more, up to the border of all those that are 
there, on that page. So at optimum checking rates we get a 
more accurate picture of Major defects in the page. This can 
give a better decision about Exit regarding remaining Majors 
per page in the document. 

Thanks for the question 

Tom
 

Patrick Bermingham
Posted on Thursday, July 17, 2003 - 06:46 pm:   	
By P_Bermingham on Thursday, January 11, 2001 - 06:23 pm: 

Greetings from Dublin, Ireland. 

It is suggested that the document to be inspected should be 
divided into sections of suitable length to allow for the 
inspection process to be completed within its allotted time. 
In reality, do practitioners of inspection not find that 
this is very difficult to achieve since many documents need 
to be read as a whole. 

Any suggestions? 

Patrick Bermingham 
Dublin 
Ireland
 

Tom Gilb 
Posted on Thursday, July 17, 2003 - 06:47 pm:   	
By Tom Gilb (Tom_Gilb) on Thursday, January 11, 2001 - 06:27 
pm: 

On of the goals of Inspection is to assess the quality 
level of the ducument in terms of exit criteria. Unless a 
rule prescibes it, this does not mean that the inspectors 
have to understand the document. Software inspections have 
been done with inspectors who did not know anything about 
software: they find many major errors (if well instructed)! 
If you read the whole document in the time available to you, 
you usually cannot approach the optimum rate of 1 page per 
hour. The total number of errors found will be roughly the 
same (see my question posted &quot;defect density against 
inspection rate&quot;). However, if in one hour you found 
20 majors in the whole document, you cannot tell how many 
there are left unfound. If you found in one hour 20 majors 
on one page, you have much better statistical relevant 
information to judge the quality of the whole document.
 

Denis
Posted on Thursday, July 17, 2003 - 06:48 pm:   	
By Denis on Thursday, January 11, 2001 - 06:29 pm: 

Folks, 
Inspection metrics are geared to the concept of Logical 
Pages. We make extensive use of diagrams, such as Entity 
Relationship Diagrams, which can be much more 'dense' than 
text pages, in terms of the information they contain. Of 
course, they can also be large or small scale when printed! 
I am thinking of anotating each such diagram with a 'logical 
page equivalent', perhaps based on the number of entities in 
the diagram, to be able to set sensible checking rates and 
to produce consistent metrics. 
Do you have any views on this, or a better solution to 
propose? 
regards, 
Denis
 

Monika Ihle
Posted on Thursday, July 17, 2003 - 06:48 pm:   	
By Monika_Ihle on Thursday, January 11, 2001 - 06:31 pm: 

I found out, that dividing documents is necessary, 
especially when you have a team, who is not familiar with 
inspection methods or documentation. 

I would like to divide also into a formal and a content / 
index review. Mostly, I prepare the formal inspection by 
myself, when all the others do an index inspection. But, I 
get a problem, when the document itself is not 
comprehensible. 

But, as far as I understand, it is necessary, when dividing 
a document, to take the brakes, when chapter or contents of 
the text allow it. 

Maybe, somebody understand my objection and would like 
adjust my comprehension? 

Best regards, 
Monika Ihle
 

Monika Ihle
Posted on Thursday, July 17, 2003 - 06:49 pm:   	
By Monika_Ihle on Thursday, January 11, 2001 - 06:33 pm: 

Maybe McCabe can help? 

http://www.mccabe.com/?file=./prod/metrics.html&lt 
Try. 

Best regards, 
Monika Ihle
 

WMJ
Posted on Thursday, July 17, 2003 - 06:50 pm:   	
By W.M. Jaworski on Wednesday, January 17, 2001 - 07:13 am: 

Denis wrote on Thursday, January 11, 2001 - 06:29 pm: "We 
make extensive use of diagrams, such as Entity Relationship 
Diagrams ......Do you have any views on this". 

Are the ER diagrams in a non-processable (paper) format? I 
think that format (and process-ability!) of diagram 'pages' 
will have impact on the checkers 'productivity'. Diagram 
processability = generation of different views of the 
diagram. 
Regards 
WMJ
 

Tom
Posted on Thursday, July 17, 2003 - 06:51 pm:   	
By Tom Gilb on Monday, January 29, 2001 - 12:52 pm: 

Who is doing serious defect prevention process and are 
there any interesting reports or papers about your 
experiences? 
Tom in Munich Monday
 

francis delhasse 
Posted on Tuesday, July 22, 2003 - 08:33 am:   	
I'm working in the field of development and manufacturing of electrical machinery . 
I'm interested in improving our design process. 
Do you think your review method is usefull in this field? 
Do you know manufacturing industries applying your method? 
Best Regards
 

Niels Malotaux 
Posted on Tuesday, March 23, 2004 - 05:01 am:   	
Surely the Inspection method is useful in development and manufacturing of electrical machinery as well. Still, before plunging into document Inspection, you might consider organizing awareness of defect injection and prevention first. Otherwise Inspection may prove somewhat frustrating. At the other hand, an Inspection on any of your documents may be an eye opener for people to find out the state of quality of current documents, to become aware that something has to be done about it and that you can actually measure the quality of documents, even machine and electrical drawings!
 

srinivas
Posted on Friday, October 07, 2005 - 04:57 pm:   	
Can anyone tell me the formula for DEfect injection rate -]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:10:51 +0100</pubDate>
        </item>
        <item>
            <title>Building and protection against airplanes</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=12&amp;comments_parentId=35</link>
            <description><![CDATA[

Gerrit Muller
Posted on Thursday, July 17, 2003 - 07:44 pm:   	
By Gerrit Muller on Wednesday, July 09, 2003 - 02:12 am: 

I copied below two comments about ways to prevent airplanes 
to crash into buildings. This must be taken into account 
with our requirements exercise :-) 

Date: Thu, 3 Jul 2003 10:17:29 -0500 
> From: Robotech_Master 
> Subject: "Soft walls" will keep hijacked planes at bay 
> 
> Article in *NewScientist* about an interesting new 
technique for 
> keeping airliners from crashing into skyscrapers: 
> http://www.newscientist.com/news/news.jsp?id=ns999 93893 
> 
> The proposal suggests 
> 
> modifying the avionics in aircraft so that the plane 
would fight any 
> efforts by the pilot to fly into restricted airspace. So 
if a plane 
> was flying with a no-fly-zone to the left, and the pilot 
started 
> banking left to enter the zone, the avionics would 
counter by banking 
> right. Lee's system, called "soft walls", would first 
gently resist 
> the pilot, and then become increasingly forceful until 
it prevailed. 
> The risks of this technique I leave as an exercise to 
the reader. 
> 
> Chris Meadows aka Robotech_Master robotech@eyrie.org 
> http://www.eyrie.org/~robotech 
> 
> ------------------------------ 
> 
> Date: Mon, 7 Jul 2003 13:03:45 -0600 
> From: zowie@euterpe.boulder.swri.edu (Craig DeForest) 
> Subject: "Soft walls" = dangerous avionics? 
> 
> Edward Lee, at U.C. Berkeley, is proposing to implement 
no-fly zones 
> around skyscrapers (and avoid a repeat of the 9/11 
massacre) by using 
> GPS to override the controls of civilian aircraft. Based 
on a 
> database (in the aircraft) of building locations, the 
on-board 
> avionics would force the controls of large airplanes to 
prevent them 
> from flying into large buildings (with presumably known 
locations). 
> 
> There's an interesting article in this week's New 
Scientist 
> (http://www.newscientist.com/news/news.jsp?id=ns999 93893) 
that talks 
> about Lee's system and relates it to other ideas for 
counter- 
> terrorism. Interestingly, one advantage that Lee uses is 
that other 
> systems require radio links with the ground and therefore 
"can be 
> jammed, or hacked into" (while, presumably, GPS cannot?). 
> 
> Not surprisingly, Lee says that pilots are "openly 
hostile" to the 
> idea. 
> 
> It seems to me that the system falls prey to a weakness 
that so many 
> pseudo-security systems do: it's in essence a cooperative 
system, 
> rather than a pre-emptive one (by analogy to multitasking 
in the 
> computing world). Even assuming the avionics work 
flawlessly, it 
> would be impossible to install the "soft wall" system on 
every 
> airplane in the country, let alone the world -- and it 
only takes one 
> airplane with the soft-wall avionics missing or disabled, 
to defeat 
> the purpose of the whole system.
 ---

Laurence Holt
Posted on Thursday, July 17, 2003 - 07:45 pm:   	
By Laurence Holt on Thursday, July 10, 2003 - 06:25 am: 

It would be easier to let the computer fly the plane. This 
is already possible--in fact, many landings are 
computer-flown (they are easy to spot - they are the smooth 
ones). But airlines think passengers wouldn't want to fly in 
them (they are probably correct on this). And, of course, 
pilots are "openly hostile".]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:09:01 +0100</pubDate>
        </item>
        <item>
            <title>What is system architecture</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=12&amp;comments_parentId=34</link>
            <description><![CDATA[

chris 
Posted on Wednesday, January 26, 2005 - 08:08 pm:   	
What is system architecture, exactly? 

I have seen varying definitions, ranging from underlying models to hardware foundations.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:06:42 +0100</pubDate>
        </item>
        <item>
            <title>Goal-oriented methods - request for participation</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=12&amp;comments_parentId=33</link>
            <description><![CDATA[

Laurence Holt
Posted on Thursday, July 17, 2003 - 07:46 pm:   	
By Laurence Holt on Thursday, July 10, 2003 - 06:34 am: 

I'd like to repeat the request I made at the conference: if 
you are interested in participating in research into 
Goal-orientation (and sharing in the findings and other 
research papers on GO), pls contact me at 
laurence.holt@quidnunc.com. 

Specifically, I am looking for people to keep a log of their 
goals for two days. *We don't want to see the log*, so you 
should have no fears about privacy. We only need summary 
data. 

Full instructions on request.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:06:01 +0100</pubDate>
        </item>
        <item>
            <title>Outsourcing focus</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=32</link>
            <description><![CDATA[
Airton Lastori 
Posted on Wednesday, April 05, 2006 - 02:13 pm:   	
Are there references or resources focusing on verifying code produced by third party? 
At my work we have the situation where we produce the A&D artifacts and the code is produced by an external Software Factory. How to deal with that? I realized that the most references does not focus on it and would be glad if you could indicate references about this topic. Thanks!]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:04:54 +0100</pubDate>
        </item>
        <item>
            <title>Inspection Leaders/Moderators</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=31</link>
            <description><![CDATA[

Valda Redfern
Posted on Thursday, July 17, 2003 - 07:22 pm:   	
By Valda Redfern on Monday, January 29, 2001 - 12:14 pm: 

Must the leader/moderator of a software inspection have 
software expertise? Or could software inspections be run 
by, say, quality personnel with no software knowledge?
 

chris 
Posted on Wednesday, January 26, 2005 - 08:13 pm:   	
Personally, if it was my project and my money, I'd want a software inspection lead by someone with broad-based and long experienced sotware skills but also quality skills (contextualised again withing software development).]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:04:21 +0100</pubDate>
        </item>
        <item>
            <title>Tools to aid inspection</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=30</link>
            <description><![CDATA[

Eddy Parkinson
Posted on Wednesday, June 01, 2005 - 06:48 am:   	
I am a researcher at Osaka University, Japan. 

I have been looking at the idea of creating a tool to aid the "quality control process". I don't think a tool is a perfect solution, but when I look at Java Doc, I see a tool that had a big impact on the quality of my code documentation. The tool helped me to see how to create "good" code documentation. All the commercial Java code that I have created has code documentation and yet non of it has had a code inspection of any type. I knew very little about inspections and did not have any good examples to guide me, hence no inspections. 

I want to try applying the same idea to "quality control", I suspect a similar tool to automate the quality control process would improve things. I know about PSP and the Process Dashboard tool and I have read quite a few software engineering books, your ãSoftware Inspectionä book is on order. My question is about priorities. Which inspection methods take the least effort to learn and use and yet have the biggest impact on quality and development time. 

Home page: http://sel.ics.es.osaka-u.ac.jp/~eddy/ ]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:03:30 +0100</pubDate>
        </item>
        <item>
            <title>Feedback on edit actions</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=29</link>
            <description><![CDATA[

Valda Redfern
Posted on Thursday, July 17, 2003 - 07:23 pm:   	
By Valda Redfern on Friday, February 09, 2001 - 09:13 am: 

A colleague has asked me, "Is there any kind of feedback 
for the checkers once the document has exited the 
inspection? Surely they must be interested to know how 
their comments have been received." Of course, they can 
just look at at the new version of the document; but would 
it be appropriate to show them the editor's final 
classifications?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:02:44 +0100</pubDate>
        </item>
        <item>
            <title>Classifying defects as Major/minor</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=28</link>
            <description><![CDATA[
Mark Leaman
Posted on Tuesday, March 01, 2005 - 10:38 am:   	
My company has been doing formal inspections on source code and documents for about four years using a process very similar to the one described in Tom's book. One persistent problem we are having is that many projects incorrectly classify major defects as minor. We have tried revising/simplifying the definition of Major and minor, but it has not helped. Time permitting, we provide feedback to projects that are doing it incorrectly, and some of them catch on. But in an rapidly growing organization of 4,000 people, we can't provide personalized feedback on all peer reviews. We need a more systemic solution to this systemic problem. 

The primary reason seems to be that people are not willing to admit that they made a major defect. We are careful not to use inspection results to evaluate people in any way, and we try to encourage finding majors through the use of checklists that list only majors and metrics that estimate the project hours saved by finding x major defects. 

We are well aware of the intended benefits of classifying defects as major/minor, specifically, to get people focused on finding and fixing more majors. But it seems to have the opposite effect in our environment, e.g., people are finding mostly minors, not majors. 

We are seriously considering dropping defect classification from our inspection process. This would reduce the inspection effort a bit, and eliminate the stigma of drawing attention to major defects. It would also improve the consistency of our peer review process metrics. We currently evaluate peer review efficiency and effectiveness based primarily on major defects, and those metrics are compromised when people miscategorize the defects. 

Tom, Kai, what are your thoughts on this? What other problems might we encounter if we stop classifying defects? We don't want to make things worse, so any input from you would be invaluable.
 

Anonymous
Posted on Thursday, March 31, 2005 - 12:40 pm:   	
Could you simply omit the word "major" and call the major defects "defects" and the minor defects "minor defects"?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:02:07 +0100</pubDate>
        </item>
        <item>
            <title>Inspections on electronic information</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=27</link>
            <description><![CDATA[

Erwin
Posted on Thursday, July 17, 2003 - 07:25 pm:   	
By Erwin van den Berg on Thursday, August 30, 2001 - 05:01 
am: 

Dear Tom and Kai, 

As a driving force in introducing Inspections in a big 
banking company in England, I am making some good progress. 
But I am now confronted with information in an electronic 
format. This might be an architectural model of a system, 
but also an electronic user manual in HTML/SGML format. 
Inspections are very good for ideas on paper, but there are 
some practical problems when the ideas are not on paper. Do 
you have any experience or tips on this topic? 

Thanks, 

Erwin.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:01:25 +0100</pubDate>
        </item>
        <item>
            <title>Completeness of candidate documents</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=26</link>
            <description><![CDATA[

valda_redfern
Posted on Thursday, July 17, 2003 - 07:19 pm:   	
By valda_redfern on Thursday, January 25, 2001 - 09:19 am: 

I have always understood that candidate documents for 
inspections should be complete and apparently error-free. 
However, I have recently been given advice along the lines 
of the following (taken from Karl E Wiegers's article 
"Improving Quality Through Software Inspections", Software 
Development, April 1995): "There is a tendency to not to 
want to share incomplete products with your peers for 
review. This is a mistake. If a product has a systematic 
weakness, such as a C program that is using literal 
constants where #defined macros should be used, you want to 
point this out when a small amount of code has been written, 
not in a completed 5,000 line program. So long as reviewers 
know what state the product is in, most people can examine 
it from an appropriate perspective." 

What are your views on this?
 ---

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:20 pm:   	
By Tom Gilb (Tom_Gilb) on Thursday, January 25, 2001 - 02:47 
pm: 

TOM GILB REPLIES 

1. Candidate documents should be submitted by their authors 
in the belief that they can meet the exit conditions. 
Of course people can be shy, but the industrial needs and 
economics of the company should decide whether and when work 
is checked, not personal 
preferences of the individual. That doesn't mean we can or 
should ignore the motivation and psychology of the 
individual. But we cannot let them subvert the entire 
project, because they will if given a chance, to make their 
life 
comfortable! All paid professionals need independent quality 
control of their work! 

2. a dominant exit criteria is for example 'no more than 1 
Major defect per page' remaining on average. 

3. The author might be wrong in their belief of the quality 
level 

4. This might be discovered when the Inspection Team Leader 
performs the Entry process cursory check and finds that the 
major defects easily exceed that number ( for example by 
finding a single Major in 5 to 15 minutes). The author needs 
to be reminded about following the appropriate rules and 
taking it seriously. 

5. If not discovered during the Entry process cursory check 
then a sample of the document, checked by the team, should 
give a reasonable estimate of remaining defects before and 
after removal of identified defects. For example if the team 
find 20 Majors in a single page ( which they often do) then 
there are 40 to 60 Majors in the page ( Inspection is 30 to 
50% effective) and 
there is no hope, with or without correction of exit at any 
reasonable defect level ( major rewrite is necessary). 

6. Keep in mind that we are not only talking code and bugs 
here. The major use of inspection is on the requirements and 
design which accounts for 50% of all bugs if it has major 
defects. Keep in mind the definitions of defect 9 rule 
violation) and Major 9 interesting downstream cost 
possibility, ie bug or worse). 

7. Documents should not necessarily be 'complete'. If a 
document is very long, there is much benefit in sampling 
early work to make sure that the author is following the 
rules. I once experiences 40,000 pages of air traffic 
control pseudocode with average 20 logic errors per page 
before even a 3 page sample was taken at my instigation 
(Sweden 1986). All that work was wasted. 
They should have taken samples after say the first 100 pages 
to make sure there process was sane ( it was not and the 
40,000 pages had been approved by 7 managers for coding, 
which would insert 800,000 bugs directly into the code. 
Major point: inspection is primarily a Quality Control 
measurement process. The economics of inspection dictate 
that it should primarily be used in a sampling mode to 
measure the defect density and make decisions about the 
process in practice at early stages. This is not the 
traditional use of inspection, but the traditional use of 
inspection is obsolete, by the Defect prevention process ( 
Mays, chapter 17 of our Inspection book). 

A thorough reading of our book Software Inspection, or the 
Team leader slides or papers on our website will help you go 
into more depth in this subject. 

I agree with Wieger!
 ---

Valda Redfern
Posted on Thursday, July 17, 2003 - 07:21 pm:   	
By Valda Redfern on Friday, January 26, 2001 - 12:30 pm: 

Thanks, this has helped (and I've bought your book!). I 
think I was getting confused between the idea of an 
"incomplete" document (i.e. one to which sections have still 
to be added) and a "work in progress" (i.e. a document whose 
existing sections the author is still changing). Or am I 
still confused?
 ---

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:21 pm:   	
By Tom Gilb (Tom_Gilb) on Sunday, January 28, 2001 - 12:21 
am: 

Sampling can be used to measure the defect state of both 
types of document. 
Tom
 ---

Anonymous
Posted on Friday, July 16, 2004 - 02:50 am:   	
WHAT ARE THE METHODS AVAILABLE FOR CALCULATING THE DEFECT DENSITY APART FROM LOC MEHTOD. 
PLEASE EXPLAIN THOSE METHODS 
 ---

Anonymous
Posted on Friday, July 16, 2004 - 02:52 am:   	
WHAT ARE THE METHODS AVAILABLE FOR CALCULATING THE DEFECT DENSITY APART FROM LOC MEHTOD. 
PLEASE EXPLAIN THOSE METHODS 

PLEASE GIVE SOME REFERENCE BOOK REGARDING THIS
 ---

Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Friday, September 17, 2004 - 02:37 am:   	
The Software Inspection book explains how to calculate defect density. 
page 385-7 Defect density - Post-inspection Measurement is a good place to start. 

Here is the rough idea. 

1. We do an inspection process with a fairly stable known defect finding effectiveness. 

a. known effectiveness: any defect finding method will find somewhere between 0% and 100% of the defects that actually are there. We have found Inspection to operate in the area of about 3% (the normal for inspections not optimized with optimal checking rates etc.) to about 88%. 

b. stable: the defect finding effectiveness must be relatively stable from inspection to inspection. Key to stability is checking rate, logical pages, rules, sources. 

2. Then we just multiply the defects we find per logical page. 

a. logical page: is any way we find to identify a fairly even amount of work. In documents like Requirements, we usually use 300 logical (non commentary) words. 

b. example: 
Known Inspection Effectiveness 50% ± 15% 
Sample: 1 logical page 
Total Pages: 10 
Finding: 20 Major Defects 

Calculations: 
20 * 1 * 2 = 40 Maj/logical page 
40 * 10 = (± 15%) Major remaining in the whole document 

Hope that helped.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 02:00:45 +0100</pubDate>
        </item>
        <item>
            <title>Test Plans</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=10&amp;comments_parentId=25</link>
            <description><![CDATA[

David Overton 
Posted on Friday, September 16, 2005 - 12:05 pm:   	
What is the view of using the Agile Inspection technique on Test Plans? Does anyone currently do this, if so, what lessons have been learnt so far?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:59:26 +0100</pubDate>
        </item>
        <item>
            <title>Minimum project size</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=13&amp;comments_parentId=24</link>
            <description><![CDATA[

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:08 pm:   	
By Tom Gilb (Tom_Gilb) on Tuesday, May 22, 2001 - 08:53 am: 

REPLY FROM TOM GILB 

1. Correct, the key issue for all projects, with or without 
Evo, is knowing and aiming for what your stakeholders really 
want. 

2. With Evo, early and frequent stakeholder feedback, you 
have a method for 
getting direct measurable feedback regarding both the 
objectives you are delivering to, and perhaps some you have 
forgotten. 

3. All my Competitive Engineering techniques work well on 
small projects, 
according to my experience. Remember that Evo is all about 
taking a large project and making it be a series of much 
smaller projects. Smallness is 
necessary for understanding and for avoiding too big a risk 
of loss if we are wrong. 

Best wishes from the Oslofjord, Tom]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:57:48 +0100</pubDate>
        </item>
        <item>
            <title>EVO in Fixed Price Projects</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=13&amp;comments_parentId=22</link>
            <description><![CDATA[

mdheur 
Posted on Wednesday, July 27, 2005 - 10:43 am:   	
Would like to understand how EVO has successfully used in Fixed Price project environments. The concept asks for flexibility, but the fixed price framework mandates to plan everything out in advance to come up with a proper proposal. How can both worlds be combined?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:56:13 +0100</pubDate>
        </item>
        <item>
            <title>Related Methods</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=13&amp;comments_parentId=21</link>
            <description><![CDATA[

David_D
Posted on Thursday, July 17, 2003 - 06:56 pm:   	
By David_D on Thursday, January 11, 2001 - 06:20 pm: 

What do you think about the practice of Extreme Programming 
(Kent Beck, et al). Many of the core elements are aligned 
with Evolutionary Delivery. Curious about your thoughts on 
this.
 
---
Tom Gilb 
Posted on Thursday, July 17, 2003 - 06:57 pm:   	
By Tom Gilb (Tom_Gilb) on Thursday, January 11, 2001 - 06:21 
pm: 

I have not read this book but a good friend Stephan Becker, 
Nokia has highly recommended it to me this week. He says it 
is all about Evo! Maybe if someone could give me an 
electronic summary of the ideas I could comment better! But 
knowing a little about extreme programming i would say that 
the spirit is Evo but the execution has some major 
differences ( see my books etc on the website to answer your 
own question). For example I assume that we are driven by a 
set of top ten defined quantified benefit./quality/values 
objectives and that every evo delivery step trys to 
measaurably move us towards those targets. I also assume evo 
can abe used for any type of project not just software. is 
this a start? 

best wishes from 
Tom Gilb
 ---

D. Lasley
Posted on Thursday, July 17, 2003 - 07:02 pm:   	
By D. Lasley on Friday, June 22, 2001 - 11:23 am: 

Tom, 
Attended your lecture on EVO last evening (21 Jun) at the 
DC ASQ meeting. Just wanted to say thanks for all the 
references and information. I plan to study EVO in detail 
because I believe from what I have just learned that it will 
assist my company in evolving our software development 
processes with a greater sense of direction and vision. 

I have some experience with implementing and accessing 
organizations using the Baldrige criteria. Do you see this 
as a fit with EVO? The strategic planning, continuous 
improvement and results oriented aspects of Baldrige seem to 
provide a framework that seems to support an EVO approach. 
What do you think?
 ---

vananda
Posted on Thursday, July 17, 2003 - 07:03 pm:   	
By vandana on Friday, June 21, 2002 - 08:43 am: 

We are pracising a methodology close to EVO. How do you 
test the application so many times? We develop and deliver 
for customer feed back & then change the application as 
suggested by the customer. First delivery is for feedback 
not production grade application, so do we not test it ? 
What is the best way of testing an application in EVO?
 ---

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:04 pm:   	
By Tom Gilb (Tom_Gilb) on Saturday, July 06, 2002 - 12:37 
pm: 

Answer from Tom: 

1. an Evo cycle test does not have to be as complete as 
final tests. It just has to be good enough to confirm that 
the function and performance you have planned to deliver are 
delivered. 

2. So the essence of the answer is to distinguish between 
Evo cycle testing and other testing which can be done on a 
continuous basis, after the Evo 
testing, and at the end of a series of cycles. 

3. There is of course no universal best way of testing with 
Evo or any other method. The degree and type of testing 
depends on a number of factors: 
? the quality objectives you have set which must be 
validated 
? the risk and consequences of faults in the system 
? the availability of test resource by deadlines 
And other factors. 

4. One interesting type of testing in the Evo environment is 
that practiced by Michael Dyer (several books and papers) 
then of IBM Federal Systems Division. This is for the Clean 
room method (using Evo). The test method was based on a 
frequency of use profile for the application. More frequent 
things were tested more. Sampling of the test profile was 
used. Not 
exhaustive test. They were working on high quality systems 
(99.98% availability plane systems for example). They 
focused on proving 
statistically that the system had the required availability 
level after every increment before releasing the increment. 

The XP methods have some interesting perspectives on testing 
in an Evo environment, so for example try these papers 
recommended to my by Kent Beck 
- which I found useful : 
Here's another paper with some data: 
http://www.objectmentor.com/processImprovement/wor kshareCaseStudy/xpAtWorkshare. 
Here's another from a client: 
www.xpuniverse.com/2001/pdfs/Method02.pdf 

The most data-intense XP projects are run by XP Labs. 
Francesco Cirillo is a great guy, very bright. Here's the 
data from one of his projects: 
http://www.communications.xplabs.com/contents/pape r2001-2.html. 

Please come back with more questions and tell us of your 
experiences and problems as this is an interesting area. 

Best wishes Tom
 ---

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:05 pm:   	
By Tom Gilb (Tom_Gilb) on Monday, July 08, 2002 - 11:31 am: 

To D. Lasley 

I agree. No one has pointed this out, so I would appreciate 
any further documentation, analysis and thought you have on 
this connection. 

Tom]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:55:27 +0100</pubDate>
        </item>
        <item>
            <title>How does a Mana. know how well Evo is implemented?</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=13&amp;comments_parentId=20</link>
            <description><![CDATA[

Anonymous
Posted on Thursday, July 17, 2003 - 07:10 pm:   	
By Anonymous on Wednesday, November 21, 2001 - 06:26 pm: 

We now have discussions about moving to "incremental 
development" for some SW projects. 

Assuming that a high level manager is visiting a project 
claiming to do incremental development/delivery (EVO style) 
of their SW. 

What would be the 5-10 tough questions he should ask to 
check how well EVO ideas have been implemented?
 ---

Tom Gilb (Tom_gilb) 
Username: Tom_gilb

Registered: 7-2003
Posted on Thursday, July 17, 2003 - 07:11 pm:   	
By Tom Gilb (Tom_Gilb) on Wednesday, November 21, 2001 - 
06:40 pm: 

VERSION 21 NOVEMBER 2001. © 2001 Gilb@acm.org 
TWELVE TOUGH QUESTIONS ABOUT PROJECT MANAGEMENT: FROM AN 
EVOLUTIONARY POINT OF VIEW 

BY TOM GILB 
TomGilb@Result-Planning.com 

These are the diagnostic questions I would recommend asking 
by a manager who is trying to understand the degree to which 
a software development environment is really doing 
Evolutionary Project Management, and doing it well. 

The uninitiated and untrained reader might not understand 
the point of these questions. They could look at the 
Evolutionary Project Management course slides at 
www.result-planning.com for suitable detail. 

At some stage I could write more supporting detail for each 
question but this will do as a first draft. 

1. What is your result delivery cycle (planned, actual, 
average, maximum)? 

2. Do you estimate the quantified impact expected on your 
critical performance, quality and cost requirements (time, 
effort, money, and space) before you implement an Evo step? 

3. Do you actually measure at the end of every cycle the 
impact you have achieved in relation to your planned impact? 

4. Do you analyze the difference between expected and 
achieved quantified impacts? ³Why this difference and what 
can we do?Å 

5. Do you try to determine the cause of significant 
deviations and to improve or change something in your 
requirements, design, planning or processes so as to get 
nearer to your specified target on the next steps? 

6. Are your step sizes nearer 2% of critical resources? 

7. Have you organized your project into backroom (concurrent 
engineering) for those tasks which take longer than an Evo 
cycle to build or get ready for integration Ã and Ã a 
Ôfrontroom  which focuses on Evolutionary result delivery to 
stakeholders? 

8. Are your delivery steps selected on a clear policy of 
delivering the most critical results to the most critical 
stakeholders first? 

9. Have you really quantified the critical few product 
requirements and defined suitable tests or short term 
measuring processes? 

10. Have you systematically identified the many (10-30) 
internal and external critical stakeholders to whom you are 
going to deliver results evolutionarily? 

11. Is your platform architecture really open ended enough 
to tolerate constant evolutionary extension? 

12. Are your stakeholders Ôdancing with joy  because they 
are really getting handover of useful results compared to 
your old way of doing projects?
 ---

Coen 
Posted on Saturday, October 11, 2003 - 02:27 pm:   	
Hi Tom, 

In step 7 you talk about tasks that take longer than one cycle. This is exactly the difficulty I have with Evo sofar. How do you handle tasks like e.g. a system architecture, you cannot draft one in two weeks I would say. I thought about splitting the task into sub-task but then you have the problem that you cant't guarantee that the subtask is 100% finished at the end of the cycle, becaus new insights after finishing another sub-task may have impact on the finished one. 
What is your opinion on such tasks?
 ---

Niels Malotaux 
Posted on Tuesday, March 23, 2004 - 04:35 am:   	
Yes Coen, this is just my problem with the "backroom" concept, where people may keep working the way they did before, forgetting about setting quantified targets and analysing the intermediate Results of their work. That's why I added the "Task"-cycle to the Evo process, by which we organize all of the work. Not just the frontroom. Have a look at http://www.malotaux.nl/nrm/Evo and the booklet http://www.malotaux.nl/nrm/pdf/MxEvo.pdf for some more information.
 ---

Niels Malotaux 
Posted on Tuesday, March 23, 2004 - 04:46 am:   	
About finishing a Task: 
If the Requirements of a Task are met, the Task is finished. If the Requirements have changed in the meantime, while you couldn't anticipate that change while working on the Task, the old Requirements of the Tasks define a successful conclusion. However, if during the Task execution (never more than one week) you become aware of the changing Requirements, of course you shouldn't continue against the old, now incorrect Requirements. Analyse the situation, take the consequences, re-estimate, replan and you're back to work on the redefined Tasks. That's taking the PDCA-cycle seriously. It actually is that simple.
 ---

srihari.boregowda 
Posted on Monday, January 17, 2005 - 05:34 am:   	
Tom/Kai 
I need one clarification. Normally we need to define Lifecycle as part of ISO-9000/CMMI. This requires capturing the EVO as a Lifecycle in a process format e.g. it should have Phase, Input, Tasks, Outputs..Entry condition, Exit conditions, Metrics...Pls. let me know if such a format exists for EVO 
Warm Regards 
-Srihari
 ---

Tom Gilb 
Username: tom_gilb

Registered: 07-2003
Posted on Monday, January 31, 2005 - 06:24 pm:   	
The Evo life cycle is described in formal terms in my book, Competitive Engineering, Chapter 10, ( manuscript at www.gilb.com), expected publication June 2005. I would be happy to email this directly to you when I get an email address. 

Tom
 ---

Anonymous
Posted on Sunday, June 12, 2005 - 05:08 pm:   	
I'm student of Computer science in UDO(Universidad de Oriente - Venezuela). I have a doubt: which the evo devices are?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:54:12 +0100</pubDate>
        </item>
        <item>
            <title>Quantified Objectives: A Fundamental Advance in Managing Software Development Projects</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=13&amp;comments_parentId=19</link>
            <description><![CDATA[

Editor
Posted on Monday, May 10, 2004 - 03:06 pm:   	
Methods & Tools has published an article "Quantified Objectives: A Fundamental Advance in Managing Software Development Projects". This article describes the Evolutionary Project Management. 

http://www.methodsandtools.com/archive/archive.php?id=6
 ---

Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Friday, September 17, 2004 - 01:51 am:   	
Nice article. 
I encourage everyone to share their experience using the methods here. No need for a full blown article, even a few words is nice.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:52:45 +0100</pubDate>
        </item>
        <item>
            <title>System Assessment</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=14&amp;comments_parentId=18</link>
            <description><![CDATA[

chris haysham 
Posted on Wednesday, January 26, 2005 - 08:04 pm:   	
I'm interested in learning where it is normal in the software life-cycle to evaluate designs. 

In particular, I'd like to know where one would evaluate whether a design is making use of the best technological functionality to satisfy users' requirements -- and also, how one would go about determining this. 

Presumably you don't have to build an alternative design to make a case that it is stronger than that currently proposed?
 ---

Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Wednesday, September 21, 2005 - 05:14 am:   	
Norm: It is normal to be very confused when it comes to the difference between requirements, design, functions etc. Consequently I find that most people start inadvertently adding design in their requirement specifications. (I do recommend against this norm). 

Waterfall: Most methods thought are based on a waterfall method, they do requirements, then based on those they do design. 

Evo: We teach and our clients practice Evo, a method where we cycle through Requirements - Design - Build - Delivery - Feedback -Learn, and back to Requirements again, so Design does not happen at one point, but continuously throughout the development process. 
In the Download Center, see the Firm case study and the Evo book. 

IET: We teach and use an Impact Estimation Table IET to evaluate the goodness of design ideas compared to users' requirements. 
See Evo book-manuscript in the download center section of this site. 
]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:51:28 +0100</pubDate>
        </item>
        <item>
            <title>System Assessment</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=14&amp;comments_parentId=17</link>
            <description><![CDATA[

chris haysham 
Posted on Wednesday, January 26, 2005 - 08:04 pm:   	
I'm interested in learning where it is normal in the software life-cycle to evaluate designs. 

In particular, I'd like to know where one would evaluate whether a design is making use of the best technological functionality to satisfy users' requirements -- and also, how one would go about determining this. 

Presumably you don't have to build an alternative design to make a case that it is stronger than that currently proposed?
 

Kai Gilb 
Username: kai_gilb

Registered: 07-2003
Posted on Wednesday, September 21, 2005 - 05:14 am:   	
Norm: It is normal to be very confused when it comes to the difference between requirements, design, functions etc. Consequently I find that most people start inadvertently adding design in their requirement specifications. (I do recommend against this norm). 

Waterfall: Most methods thought are based on a waterfall method, they do requirements, then based on those they do design. 

Evo: We teach and our clients practice Evo, a method where we cycle through Requirements - Design - Build - Delivery - Feedback -Learn, and back to Requirements again, so Design does not happen at one point, but continuously throughout the development process. 
In the Download Center, see the Firm case study and the Evo book. 

IET: We teach and use an Impact Estimation Table IET to evaluate the goodness of design ideas compared to users' requirements. 
See Evo book-manuscript in the download center section of this site. 
]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:51:18 +0100</pubDate>
        </item>
        <item>
            <title>Design Methods</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=15&amp;comments_parentId=16</link>
            <description><![CDATA[

David Overton 
Posted on Friday, September 16, 2005 - 12:03 pm:   	
Hi, 

Does anyone have any comparison tables of all the recognised deign methods available today, shown with their strengths and weaknesses?
 ---

Tom Gilb 
Username: tom_gilb

Registered: 07-2003
Posted on Wednesday, September 21, 2005 - 04:52 am:   	
Q2. Design Methods: Does anyone have any comparison tables of all the recognised design methods available today, shown with their strengths and weaknesses? 

A2. No 

There is even a problem for software people to agree on a notion of 'design' that any other engineering discipline would recognize! 

Here is mine: 
Design Idea Concept *047 May 9 2005 

A design idea is a concept that is intended to satisfy some requirements. 

A set of design ideas is usually needed to solve a design problem. 

Notes: 
1. A design specification is a written definition of a specific design idea. A template for design specification is given in Figure 7.6. 
2. A design idea is not usually a requirement. A design idea can, in principle, be changed at any time for a better design idea (without having to ask the permission of any stakeholders because the system designers are responsible for the proposed design ideas). A better design meets the requirements by giving more performance and/or less cost. 
Requirements are inputs into a design process; design ideas are the outputs. 
Note: A design can be a requirement if it is a design constraint. That is, a specific design is stated as mandatory or prohibited in the requirements. 
3. A satisfactory design idea can have some negative performance scalar impacts, and still be acceptable overall. As long as the negative impacts (negative side effects) of a design idea do not prevent us from reaching all the required Goals levels, the design idea can be used. 
4. <A design may be described in terms of its attributes. Design attributes can be function (and sub-functions). Performance attributes, costs, technical specification. 
Synonyms [Design Idea *047]: 
Design *047 
Strategy *047 
Proposed Solution *047 
Means *047 
Related Concepts [Design Idea *047]: 
Architecture *192 
Policy *111 
Design Constraint *181 
Design Specification *586 
Design Target *338 
Design Problem *048 
Entity *645 
Function Design *521 
Keyed Icon [Design Idea *047]: ->@ or ->.@ 
This icon symbolizes Impact (->) on a target (@) which is what design ideas do. 
Graphic Icon [Design Idea *047]: A lying-down rectangle. (The standing rectangle is a document icon.) 

Type [Design Idea *047]: Parameter, Design. 
--------- Quote from Planguage Glossary (online version), also simpler version inCompetitive Engineering (Gilb, 2005). 

See my chapter on Design in CE book.
 ---

Alan Ashton-Jeanes
Posted on Tuesday, October 18, 2005 - 08:38 pm:   	
I think Jerry Weinberg's pithy definition of design was: "the progressive elimination of ambiguity" (Exploring Requirements). My understanding of his argument is that computers do exactly what their specification (program code etc) tells them to do. By this time, then, there is no ambiguity: the software may be defective, but if so, it is unambiguously so. 

It is a common error, it seems to me, to believe that requirements somehow actually exist prior to the design process. Rather, as note 4 to concept *026 suggests, "Requirements, at different levels of abstraction, can be viewed as inputs to a defined level of design process. In a series of systems engineering processes, one engineerâs output (Îdesignâ, Îarchitectureâ) may become another engineerâs inputs, or Îrequirementsâ." And this is also true of the initial inputs, an output from a business design "process". 

All too often, as we know, the business design is deficient (hardly surprisingly). In fact, I would argue that it must be deficient at outset, since some necessary business inputs only become necessary as the systems design process firms up on a particular range of solution ideas (I call these inputs "second order requirements"). In practice, then, the business design process needs to proceed in parallel with the systems design process. Indeed, sidestepping the traditional boundaries, the two processes can be viewed as a single design process. So what are the inputs to this process? Not "requirements", but the business context, including stakeholders, business objectives and constraints etc. 

It is often said that projects fail due to poor communication of stakeholder requirements. It is nearer the truth to say that they fail due to poor understanding of these requirements, either by the stakeholders or by the engineers. Any takers for the proposition that Requirement (*026) is a special case of Design Idea (*047)? (Unfortunately, this would seem to invalidate the definition of *047 by making it recursive; however, design ideas and requirements seem to exist in an almost fractal hierarchy that suggests a recursive definition is appropriate. A requirement/design-idea that has no "parent" requirement/design idea is simply a special case that we must accept as a given, "axiom" or Fundamental Objective (*229) of the System (*145), which can be taken to include organisation, business or enterprise.)
 ---

Alan Ashton-Jeanes
Posted on Saturday, November 05, 2005 - 12:07 pm:   	
After further reflection, pondering on Competitive Engineering, I would refine my previous comments. A Requirement (*026) is neither more nor less than a "stakeholder-desired, or needed" (<- Planguage Glossary [Requirement]) System (*145) Attribute (*003). 

This point is almost explicit in Figure 2.2, where "System Requirements (Future Attributes)" are mapped from "System Attributes (Present or Past), but appears to be omitted from the glossary. Requirement (*026) itself does not link to Attribute. Function Requirement (*074) points to Function (*069) which points to Attribute. Performance Requirement (*100) seems to avoid pointing to Attribute even indirectly. Resource Requirement (*431) is defined as "...a scalar attribute...", although Attribute is not a "Related Concept". 

Returning to the process of Requirement specification, we see that there are two components to the process: selection of the future Attributes and assignment of values to Parameters (*105) such as Goal, Fail and Survival. Formal approaches similar to Impact Estimation can be used to challenge both the selection of particular Attributes (and Scales) over others and the values assigned to the Parameters. This is putting the Engineering into Requirements Engineering.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:49:35 +0100</pubDate>
        </item>
        <item>
            <title>Design Activities</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=15&amp;comments_parentId=15</link>
            <description><![CDATA[

Mordechai
Posted on Thursday, July 17, 2003 - 07:42 pm:   	
By Mordechai on Saturday, July 05, 2003 - 02:27 pm: 

Following the conclusion of the seminar last week, here are 
my sugestions for activites in the realm of Industrial 
Design. 
1.Activity worldwide - an attachment will be sent by email 
to all. 
2.Practical cooperation to implemnet design strategy in 
companies & organizations. 
3.Design Methodology. 
4.Request other suggestions
 ---

Mordechai
Posted on Saturday, July 19, 2003 - 10:30 am:   	
Mordechai Rotenberg's Design Management Activities 

1.	Design Management of projects for various types of companies (from consumer items to strategic products). 
2.	Multi-disciplinary analysis of condition of company's products and proposals to improve performance significantly (cost benefit; improved marketability; etc.). 
3.	Partner in several enterprise initiatives that entail futuristic concepts in the field of air purification, acclimatization & energy saving, sophisticated building construction & hospital equipment . 
4.	Teach university course in introduction to Design at faculty of Industrial Management Engineering, at 2 institutions, as well as lecturing at professional forums. 
5.	Production of instructions kits for the practical application of Design in various companies and organizations. 
---
 

Mordechai 
Posted on Saturday, August 02, 2003 - 02:04 pm:   	
Continuation of getting acquainted with Industrial Design and Industrial Designers 

© ICSID 1999 2001 
Professional Ethics 
ICSID Code of 
Professional Ethics 
www.icsid.org 

The following code provides an outline of ethical guidelines designed 
to advance the quality of the industrial design profession. The articles 
specified within this code should not be considered exclusive of one 
another, but should rather be applied in a consistent, holistic approach 
in the everyday practice of industrial design. 

Benefit the Client 
Benefit the User 
Protect the Ecosystem 
Enrich Cultural Identity 
Benefit the Profession 


ARTICLE I 
Benefit the Client 

Industrial designersâ ultimate responsibility to their clients shall be realized 
by providing appropriate and original designs which represent both value and 
benefit to their clients, clientsâ customers and the general public, while meeting 
the clientsâ ethical, business objectives. 
a) Recognition of clientâs objectives. Designers shall work within 
the limits of their profession to further the short and long-term 
interests of their clients through provision of the following: 
ð regard for strategic, economic and technical objectives, 
ð appropriate, high-quality and competitive designs, 
ð best professional practice 
ð efficient, economic and environmentally-sound 
production means, and 
ð honest business practices. 
b) Clarity of contractual agreements. Designers will clearly define 
the basis on which their total remuneration is calculated, before 
accepting an assignment. 
c) Respect for client confidentiality. Designers will maintain 
absolute confidentiality in all matters concerning a clientâs 
technology, strategy, organization and business practices and/or 
any other matter which is defined as confidential by the client, 
unless expressly permitted to disclose such information by the 
client, or if and when such information becomes part of the public domain. 

d) Acknowledgment of personal/professional conflicts. 
Designers will not consciously assume or accept a position in 
which their personal interests conflict with their professional duty. 
Should a designer find her/himself in such a position, the designer 
will inform the client of these conflicts. 

ARTICLE II 
Benefit the User 
Designers recognize their contributions to the social, individual and material 
well-being of the general public, particularly as regards health and safety, and 
will not consciously act in a manner harmful or contradictory to this well-being. 
Industrial designers shall advocate and thoughtfully consider the needs of all 
potential users, including those with different abilities such as the elderly and 
the physically challenged. 
Code of Professional Ethics © ICSID 2001 3/5 
<<>> Index 
In this respect, designers will think of the whole value chain, from production 
to sales and use of the product. Designers realize that the humanization of 
technology, the idea, usability and even the enjoyment of the product are part 
of their responsability. 

ARTICLE III 
Protect the Earthâs Ecosystem 
Ultimately, the best interests of current and future generations can only 
be protected if the worldâs ecosystem can be safeguarded. Consequently, 
designers shall adopt the following principles of environmental stewardship: 
a) Advocacy for safe products and services. Designers will 
advocate with their clients the development of environments, 
landscapes, products, communications and packaging that 
minimize environmental harm and are safe for use by all people. 
b) Protection of the biosphere. Designers will seek to minimize the 
release of any pollutant that may endanger life, air, water, or earth. 
c) Sustainable use of natural resources. Designers will strive to 
specify processes and materials which are the result of sustain- 
able and/or renewable natural resources, including the protection 
of vegetation, wildlife habitat, open spaces and wilderness. 
Designers will share information that will help their peers make 
the best choices in specifying materials and processes. 
d) Reduction of waste and increasing recycling. Designers will 
try to minimize waste. To this end, they will design for durability, 
adaptability, repair and recycling of the product. 
e) Wise use of energy. Designers will choose environmentally safe 
energy sources and adopt energy conserving means of production 
and operation whenever possible. 
f) Use of new technology. Designers will remain continuously 
aware of the possibilities offered by new technologies, and use 
them to create new resources-saving materials. 



ARTICLE IV 
Enrich Cultural Identity 
Industrial designers acknowledge that the environments, objects and services 
created as a result of the design process both reflect and help to define the 
cultural identity of their nations and distinct societies within nations. Designers 
shall strive to embody and further the cultural traditions of their national 
societies while incorporating the best characteristics of international design 
principles and standards. 

ARTICLE V 
Benefit the Profession 
Designers shall abide by the following guidelines in order to further ongoing 
development of ö and respect for ö the industrial design profession itself: 
a) Advocacy for professional business practices. Professional 
business practices will be strengthened by applying the 
following principles: 
ð professional advancement will be based primarily on 
the quality of design work and not at the expense of 
other designers, 
ð no work will be undertaken at the invitation of a client 
without appropriate payment, unless for a charitable or 
non-profit organization, 
ð the client will be notified in advance, when a designer 
may benefit financially (through association with any 
company, firm or business) from any recommendations 
made by him/her during the realization of a project, and 
ð when asked to advise on the recommendation of other 
designers, a designer will accept no payment in any 
form from the selected designers. 
b) Support for ongoing development of the profession. 
Professional development will be supported through 
the provision of: 
ð opportunities to apply acquired design skills to 
challenging projects, 
ð fair recognition for work undertaken, 
ð opportunities for further education, 
ð respectable working practices and remuneration to 
colleagues, sub-contractors, suppliers, etc. with which 
the work has been undertaken, and 
ð endorsement of, and (where possible) participation in, 
activities and programs which aim to enhance the design 
profession, whether by professional organizations, 
educational institutions or legislative bodies. 
c) Congruity of professional image. Promotional endeavors 
will consistently reflect professional aims and will include 
only factual, truthful statements and, where appropriate, 
objective, constructive criticism. 
---
 

Xenia Riemann 
Posted on Sunday, May 29, 2005 - 01:12 pm:   	
Dear ladies and gentlemen, 
The name of the designer Mordechai Rotenberg i found at your website. I am writing a doctoral thesis on the designer Wilhelm Braun-Feldweg (1908-1998) at the Free University in Berlin. I also archived the property of Braun-Feldweg. Mordechai Rotenberg was one of his students in the late 1960s/early 1970s at the academy of arts in Berlin. I am still interviewing Braun-Feldwegs students and therefore would be interested to know, if Mr. Rotenberg has interest in telling me about his time in (West)Berlin. 
My e-mail is x.riemann@yahoo.de 
my address is Xenia Riemann, Rochusstr. 23, 40479 Duesseldorf, Germany 
I would be happy if you could help me further in contacting Mr. Rotenberg for me? 
My best regards, 
Xenia Riemann
 ---

Mordechai Rotenberg 
Posted on Saturday, June 18, 2005 - 03:51 pm:   	
The bi-annual international industrial design conference will be held in Scandanvia in September (simutaneous conferences in Oslo,Helsinki, Copenhagen & Gottenburg). Please see website for further details http://www.era05.com/]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:48:23 +0100</pubDate>
        </item>
        <item>
            <title>Requirements vs. Design</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=14</link>
            <description><![CDATA[Richard Dalton
Posted on Thursday, July 17, 2003 - 08:47 pm:   	
By Richard Dalton on Wednesday, May 22, 2002 - 11:12 am: 

Joseph, 

I ususally hate non software examples, in 
response to software questions, but if you 
are looking for a means of backing up the 
argument, this may help: 

Requirement: I need a way to transport 
cargo accross a river. 

This leaves the door open to all sorts of 
solutions like, a Bridge, a Ferry, a fleet 
of small boats. Exploring the requirement 
more would help you decide what's appropriate. 
(i.e what sort of cargo, and how much of it.) 

Now if the requirement was stated as follows: 

Requirement: I need a bridge for transporting 
cargo accross a river. 

You can see that the possible solutions are more 
limited. As you increase the amount of "design" in the 
requirement, you reduce the 
amount of designing that can be done by your 
designers. And since you pay them to design, 
reducing their capacity to work is rarely a good 
idea. 

Incidently this also raises it's head in another 
way. Requirements are often written in terms of 
things that the system "shall" do. You end up 
with dozens or even hundreds of "shalls" Many 
of these include design by stealth. 

It's better to get people thinking about things they need to 
do, and let the "shalls" fall out 
of that, perhaps using Use Cases. From what I can see, the 
"shalls" are the first step for 
many people, which I don't think is a good idea. 

Hope this helps. 

-Richard Dalton
 ---

Tom Gilb 
Username: tom_gilb

Registered: 07-2003
Posted on Thursday, July 17, 2003 - 08:47 pm:   	
By Tom Gilb (Tom_Gilb) on Saturday, July 06, 2002 - 12:50 
pm: 

From Tom Gilb 
Comment on Richard Dalton message 22 May 2002 

In Planguage we believe that the requirements should limit 
themselves to stating the real requirements of defined 
stakeholders. Requirements should never directly state a 
design unless this is an intentional constraint. Such 
an intentional design specification in the requirements is 
called a 'Design Constraint'. This means that the design is 
required. An Authority and/or Rationale for demanding such 
constraints on the designers should also be 
specified. 

Design should be left to professional designers ( those who 
know available designs and their performance and cost 
characteristics). At the very least design decisions should 
be left to a design stage, which should not begin until most 
constraints, performance requirements are known. This is so 
that they can consider the fairly complete set of 
requirements, and the total set 
of other designs, when selecting a specific design - so as 
to avoid sub-optimization which otherwise results. 

See more about these ideas in the Competitive Engineering 
manuscript at www.gilb.com 

Best wishes 
Tom
 ---

Matthew
Posted on Thursday, July 17, 2003 - 08:51 pm:   	
By Matthew Leitch on Thursday, September 19, 2002 - 12:40 
pm: 

The question was whether requirements and design should be 
kept separate. I would answer yes and no. Yes, a 
distinction is useful for the reasons given by other 
postings in this discussion. But No, if separate means one 
set of people writes requirements then another set of people 
subsequently designs to them I think that is inefficient. 

The interaction of people with designs and solutions with 
people who have requirements is what is needed. 

Matthew
 ---

Joe D
Posted on Thursday, July 17, 2003 - 08:52 pm:   	
By Joseph Dubowski on Wednesday, October 09, 2002 - 10:16 
am: 

Thanks for all the great feedback on this question. 
Reading "Principles of Software Engineering Management" made 
this more clear for me as well. 

Regarding Mr. Dalton's illustration, a non-software 
illustration: I like it. Even though it is not a SW 
illustration, it still models the idea well. 

Mr. Leitch: Point well taken. I do find from my own 
experience that the stakeholders write best what they know 
best, their business problems; and technologists write best 
what they know best, solutions. There are people of broad 
knowledge and experience, and education, who can do both 
well, but those people are still relatively rare. Most 
people, especially on the IT side, are very specialized. If 
you are fortunate to work with people with the wider 
skill-set, more power to you. 

Kind regards, 
Joe Dubowski
 ---

Kym P
Posted on Thursday, July 17, 2003 - 08:53 pm:   	
Requirements vs. Design: Mapping Functional Specifications to Technical Specifications 

By Kym Phillpotts on Wednesday, April 02, 2003 - 12:17 am: 

Hi, 
I've been tasked with a job of providing a "third party" 
review of the mapping of Functional Specifications to 
Technical Specifications. Basically to ensure that all 
functional requirements have been addressed in the technical 
specification. 

Can you provide any input on methodologies that I may follow 
or other useful information about how this should be done. 

Thanks 
Kym
 ---

chris haysham 
Posted on Wednesday, January 26, 2005 - 07:32 pm:   	
http://www.gilb.com/cgi-bin/discus/show.cgi?tpc=1&post=53#POST53 

This is an issue that's always intrigued me. I think that it is difficult to separate requirements from design. I find that many requirements implicitly embody design, even if it's in basis of the question. 

"I need to transport cargo across the river" already suggests that someone is able to recognise that cargo needs transporting. The problem is, I find users don't have such insight, and the insight they do have is rarely appropriate for the organisation. 

Any comments? 
---
 

Kate 
Posted on Thursday, January 27, 2005 - 03:38 pm:   	
Yes, although the textbooks appear to tell otherwise, my intuition is that you're right. I can't help thinking that it can be awfully inefficient to go back and forth to the users asking them what they "need" when in fact much of the work they do (which can be bestowed with technological advantage) can be learnt more time-efficiently through observation and chatting etc. We once hired a sociologist to interact with users and their work so that this information could be fed back into design. Nightmare! The guy came back with all sorts of weird and wonderful sociological insights, but little of it was relevant to any eventual design -- and that was despite us trying to focus the chap.
 ---

Kate 
Posted on Thursday, January 27, 2005 - 04:21 pm:   	
Thinking about this a little more: 

I think requirements engineers will *always* need to have an appreciation of the development process. Otherwise, what's to stop asking the user irrelevant questions like what they have for dinner on a Sunday? The needs of the users must surely be placed in the context of a prospective technology design, and this guides the needs elicited. Otherwise things become awfully inefficient, which is probably what Chris is talking about and likely why we had trouble with our little "sociologist professor". 

Hmmm... 

But the text-book versions I've seen of Requirements Engineers really do just champion elicitation of "needs".]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:46:02 +0100</pubDate>
        </item>
        <item>
            <title>Entry Criteria for Impact Estimates</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=13</link>
            <description><![CDATA[

Nathan Ward 
Posted on Thursday, February 19, 2004 - 05:22 am:   	
True or False: A critical entry criteria for even starting an impact estimation table is to define, review and approve the scales for the performance requirements (as defined in the CE manuscript). 

It seems to me that we are very likely to waste time trying to even guess at impact estimates if we aren't sure that those of us working on the impact estimates do not have a common understanding of the performance requirements. And, we can't expect to have a common understanding of the performance requirments until we've done something to verify that we understand the scales. I'm thinking that we can get by without agreeing too much up front on the levels that we want to achieve on the scales, but we at least need to have well defined scales before it is worthwhile to work on impact estimates.
 

Niels Malotaux 
Posted on Tuesday, March 23, 2004 - 04:27 am:   	
I agree that you need the common understanding of performances and scales. However, just starting an IE table exercise can make people find out that this is the case. Once they find out themselves that they don't know what they are talking about, while trying to fill in the IE table, they are more "vulnerable" to the performance and scale issues. Sometimes, you have to start at the egg, sometimes at the chicken, as long as the Result is OK.]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:41:40 +0100</pubDate>
        </item>
        <item>
            <title>Usecases and qualities</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=12</link>
            <description><![CDATA[
niels malotaux
Posted on Thursday, July 17, 2003 - 08:49 pm:   	
By Niels Malotaux on Saturday, July 06, 2002 - 02:28 pm: 

Use cases are scenarios which help you to find out what the 
real requirements are that lead to the behaviour as 
derscribed in the use-case. 
Unfortunately, Rational tells people that use-cases are 
requirements, while all requirements that cannot be 
described by use-cases are to be kept in the "Supplementary 
Requirements". 
Who in your company decided that use cases are requirements 
and why? Can they explain why use-cases are adopted as 
company standard when defineing requirements? Can they 
explain how use-cases can be used as requirements? 
Note that uses cases are usually design, where you omit the 
actual reason why this use case is the right design. 
What organisation is this? What are we going to do about 
this? Who should we educate?
 

Anonymous
Posted on Thursday, July 17, 2003 - 08:50 pm:   	
By Anonymous on Wednesday, September 04, 2002 - 05:00 am: 

Tank you for the information. 6 months ago we reorganized 
the development process and we are not using use-cases as 
requirements anymore and we are moving in the direction you 
have stated. But we still use use-cases to express ideas and 
design solutions. And I found the same problems with 
use-cases that you are mentioning.
 

Marko Komssi
Posted on Tuesday, November 11, 2003 - 02:27 am:   	
Thanks for your comments! 

Use Cases and Planguage are excellent methods for accomplishing specification. However, the level of content and stakeholders' goals determine whether document is requirement or not. 

I have used both Use Cases and Planguage for writing many type of specifications. For instance, I have used Use Cases even for writing quantifiable performance requirements, bug reports, and test cases. 

On the other hand, Use Cases may cause people to write design, not goal, oriented requirements. Unfortunatly, I have seen that happen a lot. 

Anyway, it is important not to mix methods and document types. The goal of stakeholder is what counts (IMHO). 
 

ANZAR 
Posted on Tuesday, September 20, 2005 - 05:45 am:   	
Just wondering that , software industry has been flooded with quality models and still new model yet to come in.....are we really lookin at the Return to customer ( RTC) when we get into implementing of choosing one for our compnay. 
Can any one throw few thoughts on...any standard methodologies or any unique implementation methods to get on to ROI}]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:40:49 +0100</pubDate>
        </item>
        <item>
            <title>Agile, Multidisciplinary Teamwork by Gautam Gosh</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=11</link>
            <description><![CDATA[Posted on Thursday, January 13, 2005 - 04:18 pm:   	
The Methods & Tools newsletter has just released in its html archive section "Agile, Multidisciplinary Teamwork" by Gautam Gosh 

This article presents techniques and tools used to create requirements with a team composed of the different participants of agile projects. 

http://www.methodsandtools.com/archive/archive.php?id=17]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:39:47 +0100</pubDate>
        </item>
        <item>
            <title>Reading Techniques</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=10</link>
            <description><![CDATA[Hayley S 
Posted on Thursday, November 13, 2003 - 09:21 am:   	
I am a Software Engineering degree student and I am researching 'reading techniques' for software Inspections. I am particularly interested in comparing the traditional 'Checklist-Based reading (CBR)' with the newer 'Usage-Based reading (UBR)' technique.

I have read some articles written by Thelin (et al) comparing the 2 techniques but I wondered if anyone knows of any other sources of information on UBR in particular, or if anyone could give me their opinions on this subject? ]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:37:50 +0100</pubDate>
        </item>
        <item>
            <title>Requirements Testing</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=9</link>
            <description><![CDATA[A Collins
Posted on Friday, October 10, 2003 - 09:05 am:   	
I found this web page very interesting. Interesting reading! 
Please redirect me if i posted this in the wrong forum. 

I«m wondering if you have written any papers/articles on Requirements Testing? 

Regards 
A Collins]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:36:16 +0100</pubDate>
        </item>
        <item>
            <title>Requirement Methods</title>
            <link>http://www.valuecertification.com/tiki-view_forum_thread.php?forumId=16&amp;comments_parentId=6</link>
            <description><![CDATA[David Overton 
Posted on Wednesday, September 14, 2005 - 07:37 am:   	
Could someone please list all the methods and/or techniques used to document software requirements, and list the strengths and weaknesses for each, e.g., ÎPlanguageâ, ÎUse Caseâ, etc?]]></description>
            <author>System Administrator</author>
            <pubDate>Sun, 09 Apr 2006 01:26:34 +0100</pubDate>
        </item>
    </channel>
</rss>
