Tom Gilb & Kai Gilb

Planguage Definition of Architecture Concepts

Description: Set of Planguage concepts related to the architecture notion. I have long been uncomfortable with traditional 'architecture' definitions. And I've been downright disgusted with the books, papers and practices in the 'software architecture' area. My main gripe is that they never even hint that multiple qualities and costs might be interesting! Slight oversight. These are extracted from my private Planguage Glossary a copy of which is at http://www.gilb.com/tiki-download_file.php?fileId=25 (version April 25 2009) and a strongly edited version of it is in the Competitive Engineering book glossary (not all concepts are there). Should a reader wish to suggest improvements, I 'd be happy to listen.

Created / Uploaded: Wed 27 of May, 2009

Last Modified: Mon 06 of Sep., 2010

Creator: Kai Thomas Gilb

Gilb's Planguage Principles in CE Book - with some friends too

mini paper in Norwegian on Value Pro Management with course info

Gilb’s Laws: Uncommon Sense for Planners and Decision-Makers

Description: This unchanged draft from 2006 is put on my website (Gilb.com) August 2010, so as to see interest and receive feedback (tomsgilb@gmail.com). In some parts there is no detail, only a sketch of the content. After 4 years I decided it was better to put it on the website than to keep it hidden. I often write draft manuscripts that are not published, and I also can spend 13 years between published books – trying to get the right quality. My last book (Competitive Engineering 2005) was intentionally a voluminous handbook. Now I am struggling to find a way to convey my ideas in a brief and accessible form, for many purposes. I have about 6 prototypes like this one! As Churchill noted, it is more difficult to be brief.

Created / Uploaded: Thu 12 of Aug., 2010

Last Modified: Thu 12 of Aug., 2010

Creator: Tom Gilb

What's Wrong with Requirements Methods?

Gilb’s Ten Key Agile Principles

Estimation or Control? • A Paradigm Shift in Agile and Lean Directions.

Description: “Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets, and deadlines is possible, using feedback and change.” So, rather than trying to improve project estimates initially, we suggest that budgets and deadlines are set based on value of delivery, and then iterative re-engineering of product and process are used to stay within acceptable bounds, or at least to get most of the expected value delivered by the acceptable deadlines and budgets. New draft paper July 25 2010, SQP has asked for a copy.

Created / Uploaded: Sun 25 of July, 2010

Last Modified: Sun 25 of July, 2010

Creator: Tom Gilb

Real QA Manifesto, Prawdziwe QA: Zapewnienie “Jakości i wartości”

Verdifokus i Prosjektstyring

A Quality Manifesto (as Published)

Description: Published in Testing Experience 01/08 March 15, 2008 This is a glossy version of the Word doc at this site [http://www.gilb.com/tiki-download_file.php?fileId=142] I'd be happy to have some people arrange to have this as a signed document on a website. We have put The Real QA Manifesto - serving the aim of moving test to real QA on this site 27 May 2009. This paper takes aim at the more general Software Engineering and Systems Engineering problem of Quality. It is Not focussed on QC or QA

Created / Uploaded: Thu 28 of May, 2009

Last Modified: Thu 28 of May, 2009

Creator: Tom Gilb

Real QA: Assuring the ‘Quality and Value’ Up Front, and minimizing testing effort.

Agile Specification Quality Control

Description: "Agile Specification Quality Control" by Tom Gilb This includes 3 case studies and detailed data collection forms and process descriptions. initially presented at INCOSE Conference, and now edited and published in Testing Experience March 2009. With the last issue we did have till this morning (March 13) 207,556 downloads. It is amazing. Here is the link for you: http://www.testingexperience.com/testingexperience01_09.pdf

Created / Uploaded: Fri 13 of Mar., 2009

Last Modified: Fri 13 of Mar., 2009

Creator: Tom Gilb

Vision Engineering

Rule-Based Reviews

Undergraduate Basics for Systems Engineering (SE)

Description: PAPER (Published 2007 INCOSE Conference Paper and Cutter). Updated May 5 2008 Strachey Quote. Abstract. There are some very basic things that systems engineers should be taught. These things are both fundamental and classic. They are fundamental because we can reuse them in a very wide variety of SE situations. They are classic in the sense that they have a very long usefulness half-life. They are probably useful for at least a career lifetime. When I was in my Twenties, I decided to collect, to learn and to develop these SE Basics. Now, in my Sixties, I am more than ever convinced that these fundamentals should be share with students. The fundamentals are: Principles (heuristics, laws), Measures (ways to quantify critical factors), Concepts (really useful definitions of fundamental SE ideas), and Processes (really useful SE processes). I have published these in several books and papers already. I would like to argue here why they need teaching in undergraduate systems engineering. I believe that their usefulness and longevity are demonstrated in my own work, are acknowledged by many professional colleagues and some academics, and are self-evident upon examination. Hopefully this paper can stimulate others to adopt at least the general idea, if not my exact artefacts. Principles Some Principles of Useful Knowledge • UNIVERSALITY: 1. Knowledge is more useful when it applies to more circumstances • ETERNALITY: 2. Knowledge is more worth learning if it can be applied for a long time after learning it • VALUE: 3. Knowledge is more useful if there is a high value from applying it • SHARING: 4. Knowledge is more useful if it can easily be shared with others • PROOF: 5. Knowledge is useful when early feedback can prove its usefulness in practice • SYNCHRONOUS: 6. Knowledge is more useful when it can be used together with a larger body of knowledge • MEASURABIILITY: 7. Knowledge is more useful when the results of its application can be measured • ACCEPTANCE: 8. Knowledge is more useful when it is widely accepted in your culture. • COST: 9. Knowledge is more useful when the cost of applying it is low. • GENERATION: 10. Knowledge is more useful when is can be used to generate even more useful knowledge. 2.9 MB Word A set of Powerpoint slides is available on request.

Created / Uploaded: Tue 10 of Oct., 2006

Last Modified: Mon 05 of May, 2008

Creator: Tom Gilb

Decomposition of Projects - How to design small incremental result steps

Description: PAPER. Abstract MAJOR EDIT UPGRADE 5 APRIL 2008 • The basic premise of iterative, incremental and evolutionary project management [Larman 03 MG] is that a project is divided into early, frequent and short duration delivery steps. • One basic premise of these methods is that each step will attempt to deliver some real value to stakeholders. • It is not difficult to envisage steps of construction for a system; the difficulty is when a step has to deliver something of value to stakeholders, in particular to end users. • This paper will give some teachable guidelines, policies and principles for decomposition. It will also give short examples from practical experience.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sat 05 of Apr., 2008

Creator: Tom Gilb

QFD What's Wrong

Description: PAPER2nd MAJOR UPDATE November 22 2007: How problems with Quality Function Deployment's (QFD's) House of Quality (HoQ) can be addressed by applying some concepts of Impact Estimation (IE) By Gilb and Brodie This version goes much deeper than previous versions. Introduction Quality Function Deployment (QFD) is widely taught as a method for analyzing the relationship between designs and related qualities. I admit that the structure of analysis – multiple design correlated to multiple quality and performance requirements – is a very healthy and necessary analysis process. My problem with QFD is that there are too many permitted specification notations, that are badly defined, subjective, and coarse. The result is that the potential value of such a many-design to many-requirements analysis is in severe danger of failing to perform its primary function – giving us a useful understanding of the power of design to satisfy a set of requirements.

Created / Uploaded: Sat 09 of Dec., 2006

Last Modified: Thu 22 of Nov., 2007

Creator: Tom Gilb

How to Quantify Quality

Description: PAPER: How to Quantify Quality: Finding Scales of Measure by Tom Gilb Tom@Gilb.com Abstract. ‘Scales of measure’ are fundamental to a specification method we have developed called Planguage. They are central to the definition of all scalar attributes; that is, to all the performance (especially quality attributes) and resource attributes. You can learn the art of developing your own tailored scales of measure for the performance and resource attributes, which are important to your organization or system. You cannot rely on being 'given the answer' about how to quantify. You will lose control over your current vital system performance concerns if you cannot or do not quantify the critical attributes. This was published as a paper at INCOSE.org conference Washington DC 2003. June 14 2007 INCOSE says they will make all previous incose conference papers available on the web, so that includes this one. There is of course a set of slides for this and other papers, on request from the author.

Created / Uploaded: Thu 14 of June, 2007

Last Modified: Mon 05 of Nov., 2007

Creator: Tom Gilb

Why? (Manager Book)

Quality Manifesto

Description: PAPER: Quality Manifesto: Software Quality is a Systems Engineering Job PAPER: 16 Pages. Major rewrite of core paper I had on this site since Summer 2007. Abstract. The main idea with this paper is to wake up software engineers, and maybe some systems engineers, about quality. The software engineers (sorry, ‘softcrafters’) seem to think there is only one type of quality (lack of bugs), and only one place where bugs are found (in programs). My main point here is that the quality question is much broader in scope. The only way to get total necessary quality in software, is to treat the problem like a mature systems engineer. That means to recognize all critically interesting types of quality for your system. It means to take an architecture and engineering approach to delivering necessary quality. It means to stop being so computer program-centric, and to realize that even in the software world, there a lot more design domains than programs. And the software world is intimately entwined with the people and hardware world, and cannot simply try to solve their quality problems in splendid isolation. I offer some principles to bring out these points.

Created / Uploaded: Tue 30 of Oct., 2007

Last Modified: Mon 05 of Nov., 2007

Creator: Tom Gilb

Engineer Your Review Process

Description: PAPER: Engineer Your Review Process: Some guidelines for engineering your engineering review processes for maximum efficiency 15 Page paper. Completed Nov 2 2007 Abstract. You can tailor your various review processes so as to maximize effectiveness for purpose, at minimum costs. I call this review efficiency. This presumes you are willing and able to state a set of clear objectives for your various reviews. Then we can design review strategies to try to meet those objectives. In addition to corporate level review design, you need to design-in the freedom locally, at the project level, and the individual review level, to dynamically adjust or optimize the review process for local conditions and local requirements.

Created / Uploaded: Fri 02 of Nov., 2007

Last Modified: Mon 05 of Nov., 2007

Creator: Tom Gilb

Engineering Productivity:

Description: PAPER: Engineering Productivity: Some ways to measure it and manage it. 1 MB, pdf, 15 page paper. Nov 4 2007 Version Abstract. There are often too few qualified engineers. I am mostly referring to product design engineers – software engineers and systems engineers. One reason we have too few is that we misuse their time so badly – we waste at least 50% of it. But when we can longer desire or afford to solve the problem by hiring or off-shoring to get more warm-bodies, we need to consider getting more productivity from the engineers we already have. There is one great advantage from that tactic – they already have plenty of experience in our company! There are several tactics to improve productivity. They can take many years to come to full effect, but a steady long term improvement, and dramatic short term improvement, should be possible. The key idea in this paper is that we can define our own productivity quantitatively – and manage the improvement of it quite systematically. Your own definition of productivity demands several simultaneous dimensions of productivity. The definition of productivity also requires substantial tailoring to your organization, and to its current environment. I am going to assert that the best short term measure of engineering productivity is agreed value (requirements) delivered; and the best long term measure of engineering productivity is stakeholder benefits actually delivered.

Created / Uploaded: Sun 04 of Nov., 2007

Last Modified: Mon 05 of Nov., 2007

Creator: Tom Gilb

Making Metrics Practical

Description: PAPER: Completed 28 Oct 2007, about 17 pages, pdf Making Metrics More Practical in Systems Engineering: Fundamental Principles for Failure and for Success. Abstract. Quantification is the essence of real engineering. Engineering is good at quantifying many traditional aspects of systems. But there are weak points. For example in quantification of emerging ‘soft’ aspects of systems like usability and security, and within the emerging sub-disciplines of software and data. We need to use the quantification tool in all critical aspects of of our systems, not just in traditional sectors. This paper will explore the extension and strengthening for the metrics discipline in the weakest areas of systems engineering.

Created / Uploaded: Sun 28 of Oct., 2007

Last Modified: Mon 05 of Nov., 2007

Creator: Tom Gilb

Designing Maintainability in Software Engineering

Description: PAPER: Designing Maintainability in Software Engineering: a Quantified Approach. Tom Gilb 15 PAGES, 1MB Abstract. Software system maintenance costs are a substantial part of the life cycle costs. They can easily steal all available effort away from new development. I believe that this is because maintainability is as good as never systematically engineered into the software. Our so-called software architects bear a primary responsibility for this, but they do not engineer to targets. They just throw in customs and habits that seem appropriate. We need to define our maintainability requirements quantitatively, set investment targets that will pay off, pursue long-term engineered improvement of the systems, and then ‘architect’ and ‘engineer’ the resulting system. Other disciplines within systems engineering may already in principle understand this discipline, some may not understand it, some may simply not apply the engineering understanding that is out there

Created / Uploaded: Fri 26 of Oct., 2007

Last Modified: Fri 26 of Oct., 2007

Creator: Tom Gilb

Value Delivery in Systems Engineering

Description: PAPER (new 25 Oct 07) 16 Pages. 1.5 MB "Value Delivery in Systems Engineering" By Tom Gilb Abstract. Sponsors who order and pay for systems engineering projects, must justify their money spent based on the expected consequential effects (hereafter called ‘value’) of the systems. At one extreme if a system met all technical requirements, but was never deployed in practice – it might have no possibility of delivering the value expected. This paper will argue that the definition of the expected value should form an integral part of the high level requirements of the system. It will argue that we need specific design and implementation planning to improve the probability that the value will be delivered and will be maintained.

Created / Uploaded: Thu 25 of Oct., 2007

Last Modified: Thu 25 of Oct., 2007

Creator: Tom Gilb

Requirement Relationships

Description: PAPER: Requirement Relationships: A Theory, some Principles, and a Practical Approach. Drafted initially Sunday, 1 October 2006. © Tom@Gilb.com, 2006 Introduction: This paper will argue that the ‘conventional ideas’ [NASA 97, INCOSE01, Raytheon06] of how requirements relate to other entities is unnecessarily weak in relation to the complex demands placed on a systems engineering task. We will argue that it would improve systems engineering requirements practice if we were to invest substantially more in effort to determine, and to specify, at least a dozen or two useful relationships for each requirement. We will argue that the nature or variety of these relationships should but relatively unlimited (by a standard or tool), and should be whatever is useful to the engineering work. In addition, we need to keep the requirement relationship specifications, together with the core requirement itself, in a reusable requirement ‘object’ (a mini database about each discrete requirement, which is tool independent). Systematic rules and conventions, like those illustrated, will enable more-automated use (analysis, presentation, consistency checking, reuse) of requirements, even with simple text string searching.

Created / Uploaded: Sun 01 of Oct., 2006

Last Modified: Fri 24 of Aug., 2007

Creator: Tom Gilb

The 10 Most Powerful Principles for Quality in

Description: PAPER: The 10 Most Powerful Principles for Quality in Software and Software Organizations. The software industry knows it has a problem: The industry's maturity level with respect to "numbers" is known to be poor. While solutions abound, knowing which solutions work is the big question. What are the most fundamental underlying principles in successful projects? What can be done right now? The first step is to recognize that all your quality requirements can and should be specified numerically. This does not mean "counting bugs." It means quantifying qualities such as security, portability, adaptability, maintainability, robustness, usability, reliability, and performance. This article presents 10 powerful principles to improve quality that are not widely taught or appreciated. They are based on ideas of measurement, quantification, and feedback. Published in http://www.stsc.hill.af.mil/crosstalk/2002/11/gilb.html See corresponding set of slides at this website.

Created / Uploaded: Tue 08 of May, 2007

Last Modified: Tue 08 of May, 2007

Creator: Tom Gilb

Virtual Team Communication:

Description: PAPER, UNPUBLISHED. Principles of Virtual Team Communication: Manage By Results, Not Effort and Tasks Quantify Key Results Evolve Delivery of Key Results, Early and Frequently Measure Real Progress towards Key Results Architecture Constraints but Design Freedom Measurable Specification Quality Control Reward Team for Results Avoid Unrealistic Models and Tools Write Everything, Forget Oral Communication Learn Rapidly, Change Rapidly, Delivery Value Rapidly Version 1.1 2 small typos corrected 12 Dec 2006

Created / Uploaded: Mon 06 of Nov., 2006

Last Modified: Tue 12 of Dec., 2006

Creator: Tom Gilb

Requirements for Outsourcing

Description: PAPER (Unpublished) Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening. I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project. Outsourcing Requirements Principles. Here is a set of principles for Requirements for Outsourcing: 1. If anything can be misunderstood, it probably will be. 2. Writers Are Responsible for Readers Wrong Renditions 3. Assume Nothing, Specify Everything 4. Too Much is Safer than Too Little 5. If They ask a question, document and integrate the answer 6. Quality Control before sending 7. Evolve Requirement Delivery 8. Quantify Quality 9. Constrain explicitly 10. Connect relationships

Created / Uploaded: Wed 11 of Oct., 2006

Last Modified: Thu 12 of Oct., 2006

Creator: Tom Gilb

10 Powerful Systems Engineering Heuristics

Description: PAPER (Unpublished) I would like to suggest some fundamental heuristics that characterize the essential spirit of systems engineering. Heuristics that can be used to teach essential engineering tactics. The heuristics: 1. All designs are valid if they deliver the performance within the constraints. 2. System Level Architecture optimizes the specialist disciplines, and constrains them. 3. We don’t really know what works until we try it. 4. System Models cannot be relied on, and their only justification is when there is no more realistic way to economically represent the future system. 5. Systems need to be built to tolerate change and expansion beyond current stakeholder needs. 6. System Stakeholders are one more than you know about; and known stakeholders have at least one more need than you know about now. 7. You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term, over current systems. 8. The most critical requirements and critical designs are probably soft, not hard. And most ‘engineers’ are not social engineers. 9. Don’t ever try to build it all at once – evolve the system based on highest value early, and rapid learning about realities. 10. Manage the details through focus on high-level measurable objectives, not through bureaucracy. 11. Contractors will deliver better value for money, if paid only for value delivered, not for work completed. 12. Risks are impossible to detail completely and correctly, but can be controlled by frequent and early numeric feedback and change – as well as creating openness for necessary change in architecture, contracts, and relationships. Drafted 8 Oct 2006

Created / Uploaded: Sun 08 of Oct., 2006

Last Modified: Sun 08 of Oct., 2006

Creator: Tom Gilb

Ten Design Principles: Some implications for multidimensional quantification of design impacts on requirements

Description: PAPER. By Tom Gilb See corresponding ppt slides from INCOSE July 2006 here. Abstract. Designs have multiple impacts on requirements, and can only be fully understood in terms of their impact on requirements. In other words, the contributions of designs towards the set of performance and resource requirements must be considered, when evaluating designs, in addition to their contributions to the function requirements. This paper sets out ten principles, and outlines their various implications for design. These are basic ideas about designs, which we should explicitly acknowledge, teach and use in practice. I would be surprised to find any serious disagreement about these principles, but I would be surprised to find serious conscious practice and teaching of them today!

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Tue 11 of July, 2006

Creator: Tom Gilb

How Good Is A Process? Evaluating Engineering Processes’ Efficiency

Description: PAPER. By Tom Gilb (see corresponding PPT Slides here) Abstract. What is ‘best practice’ for an engineering process? How good is your current set of development, maintenance and service processes? How can we decide exactly which processes we are going to adopt in our organization, for example in a CMMI implementation? It is the assertion of this paper that such questions are often dealt with without explicit and quantified regard to the full set of real, and well-defined business needs, as well as often not taking into consideration the current processes and the issues of changing them. We too often carry out and change processes because we are told to, not because there is a clearly defined need to do so. Introduction A rational evaluation process would continuously match our continuously evolving set of business, technical and engineering objectives to a set of engineering processes. It would do so on a multi-dimensional and numeric basis: • We would quantify our engineering process objectives. • We would estimate the impacts we can expect from new and changed engineering processes. • We would measure in practice the impact of new processes. • We would decide which processes are good and which are bad, based entirely on how they worked in our particular environment. I am sure the reader agrees with the desirability of numeric principles, even if they are in doubt about how to practice them. However, how many people can show that their organization operates on this rational principle? What is often missing is the ability to articulate engineering organizational objectives as quantified goals. My observation of a large number of multinational engineering organizations convinces me that even the best and most senior managers are not trained in how to do this. The good news is that given a little help and some examples, they are willing to define their needs quantitatively. The aim of this paper is to outline how to quantify such objectives and to outline how to use such quantification to achieve better processes.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Tue 11 of July, 2006

Creator: Tom Gilb

Competitive Product Engineering: 10 Powerful Principles for winning product leadership, through advanced systems engineering

Software Outsourcing Contracting: What should be in the contract and what should not.

Description: PAPER: New 26 May 2006. Prepared initially for Norwegian Computer Society lecture 12 June 2006 Oslo. • This paper takes the point of view of the customer. But I hope the suppliers will be interested in some more competitive and satisfactory ways to offer services to their customers and prospects. • • The major problem for both parties to the contract is how to define things clearly, in spite of the fact that there are many future unknowns. • • The major problem is that far too many outsource relationships are outright failures, or are partial failures. • So, the major premise of this paper is how to avoid total failure, how to reduce failure, or at least detect failures early, and stop the bleeding. • • The major premise is that we need to define the results we are expecting in quantified and testable ways. • • The second major premise is that we cannot actually do this in the contract. The contract must however serve as a framework for such decisions and agreements, as the work progresses. • • I assume that any contract format, or contract standard, can be used for these ideas. They are a supplement, rather than a change to the contract templates. But, that some of the ideas could be more explicitly treated in public contracting templates. Note: this paper can be viewed in the light of my earlier No Cure No Pay paper and slides. It preaches the same quantified results and Evo message, but is focussed on the contractual relationship possibilities themselves.

Created / Uploaded: Fri 26 of May, 2006

Last Modified: Fri 26 of May, 2006

Creator: Tom Gilb

Competitive Engineering:12 Powerful Practices for winning more profitable business for Indian Corporations

No Cure No Pay:How to Contract for Software Services

Description: PAPER. Abstract. 50% of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid! My suggestion is simple. Pay only when defined results are provably delivered. This requires several things: • Contracts that release payment only for meaningful results; • The ability to define those results, particularly qualitative ones, and particularly the organizational ones; • The ability to deliver those results incrementally, thus proving capability at early stages and continuously. Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well. http://roots.dnd.no/repository/05_Gilb_Tom_No_Cure_No_Pay.pdf contains the slides and (about 12 MB ppt download) www.nasscom.org/download/Tom_Gilb-.ppt advice for Indian Organizations.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Wed 24 of May, 2006

Creator: Tom Gilb

12 Tough Questions

Description: PAPER. Managers don't ask tough enough questions about written material. I know because I have spent decades watching them fail to ask the questions which would have exposed the proposals as dangerous or not well thought out. I have to conclude that managers need training to ask these questions. But I forgive any reader who thinks that asking such questions is just good common sense. It is. The questions all refer to a larger method I teach; "Requirements Driven Management" and documentation in my past ("Principles of Software Engineering Management") and future books (RDM, Evo, Requirements Engineering (all working titles). But these books exceed 400 pages, the courses take several days. The patience of top managers for such detail is necessarily limited in a high pressure world. So this paper is offered as a simplification and an appetizer. If you want more substance and detail, it exists. If this alone is useful, be happy!

Created / Uploaded: Mon 10 of Apr., 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Software Inspections are not for quality,

Description: PAPER. Software Inspections were developed at IBM and published in 1974-76 [1] more than a quarter century has passed and it is time to reassess them. Most literature on the subject is rooted in the initial IBM practices. Most professionals have an incomplete understanding of the traditional inspection and why it succeeded at IBM and elsewhere. But time and experience have led to many new practices which make Inspection more economic and useful than originally envisaged. The bottom line is that I believe that it is more relevant to view Inspection as a way to control the economic aspects of software engineering, rather than a way to get 'quality' by early defect removal. Quality needs to be multidimensional, specified in quantified requirements and architected, engineered and designed into software products. Inspection needs to be used to monitor the entire software engineering process.

Created / Uploaded: Mon 10 of Apr., 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

The Ten Most Powerful Principles for Quality

Risk Management: A practical toolkit for identifying, analyzing and coping with project risks.

Practical Purposeful Creativity

Description: PAPER. This paper was invited, written, and published by a special issue of a Psychological Journal . It is attempting to break with conventional academic thinking about the subject . This paper is written as an invited contribution to a book “Creativity, Innovation and Cooperation” (Springer) and a special issue of “AI & Society: the Journal of Human-Centred Systems and machine Intelligence”. The editor is Robert C. Muller (Fax +44-491-579750). Published around 1992.

Created / Uploaded: Mon 10 of Apr., 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Impact Estimation Tables:Understanding Complex Technology Quantitatively

Description: PAPER. How good is your design suggestion? Does anybody else really understand why you think the technology you suggest is such a great idea? Would you like to know how to shoot down those dumb ideas that your colleagues and those consultants manage to entice your managers with? Would you like a killer approach to prove your technical expertise to the world? We may have it right here! Impact Estimation (IE) Tables will allow you to analyze any technical or organizational idea in relation to requirements and costs. It's a method, I've developed over the last twenty years and it works! To give one example, shortly after we taught the idea to a manufacturing group, they declared it was worth a million dollars! Using IE for the first time, they presented a bid for project money to management and got the full budget they requested; $1 million more than they had expected! Crosstalk Dec 1998 Version

Created / Uploaded: Mon 10 of Apr., 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Real Requirements: How to find out what the requirements really are.

FIRM: From Waterfall to Evolutionary Development (Evo). Paper.

Description: PAPER. How we rapidly created faster, more user-friendly, and more productive software products for a competitive multi-national market. Evolutionary development (Evo) focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper describes from a project manager’s viewpoint, the positive experiences that one organization rapidly achieved on switching from using the Waterfall method to Evo. Major benefit came from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality. Authors: Trond Johansen - FIRM, Tom Gilb, Kai Gilb

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Kai Thomas Gilb

Quantifying Stakeholder Values

Description: PAPER. This paper focusses on how to determine project stakeholder needs/requirements/values. It shows how to use Planguage to specify them quantitatively. This is the basis for deriving corresponding and supporting product qualities. Abstract: Here are some questions we need to ask about stakeholder value. How can we determine the overall value of a system? How is this value related to the performance characteristics of the system? How can we engineer the value to meet stakeholder expectations? How can we test and measure the real value? Can we contract for system payment by value, or do we have to restrict ourselves to payment for performance levels? Is there any way to quantify the overall value of a system as a function of a set of system attributes?

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Plicons: A Graphic Planning Language for Systems Engineering

Description: PAPER. Abstract: • A Pictorial language (Planguage Icons = Plicons) for representing systems engineering problems (requirements) and solutions (designs) has been developed, and continues development, by the author. It differs from most all other published software engineering and systems engineering languages in several key respects. • The main, but not only, differentiating characteristic is that it allows us to model quantified system performance properties and resources graphically; whereas most all other graphic languages are limited to things like functions, logic flow, use cases; and invariably avoid any representation at all for quantifiable qualities and costs.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

AGILE ASPECTS OF PLANGUAGE: For Cost-Effective Engineering

Description: PAPER. • Planguage is a comprehensive, but not exhaustive, set of tools for systems engineering. Planguage encompasses language constructs to model engineering products, and to model processes. Planguage also includes well-defined processes for some of the engineering processes, principally requirements, design, quality control, and project management. • I designed Planguage to be agile. I specified a set of agile Planguage requirements, and evolved the design to meet these requirements. Much of the agility has evolved, as a result of the practical use of the language, and by us making immediate experiments, during client work, in adapting Planguage to needs and opportunities.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Quantifying Security: How to specify security requirements in a quantified way

Description: PAPER. Introduction. • Security is a system quality. It can be dealt with in the same way that all other critical system qualities need to be dealt with – quantitatively, and systematically. We suggest that the planning language, Planguage, as defined in Competitive Engineering [Gilb05] is a strong and innovative framework for dealing with security in a systematic way. In fact even those who are not just interested in security, but in the larger set of system qualities, may be interested in this paper as an example of what one can do with other qualities. • The theme of this paper is summarized by the following: o Security is a complex quality: that means it needs to be defined by a set of measures, not a single measure. o A single elementary measure of quality will need to be applied to a wide variety of conditions regarding when, where and for which events, in order to be made intelligible for various levels of analytical benchmarks, for constraint levels and target levels of security. o The security designs, to meet security requirement levels, must all be evaluated by both quantitative estimate and direct measure, to see if they help meet the security target levels. In addition they must not harm other performance or quality target levels, other constraints, and they must fit within the resource budgets.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Choice and Priority Using Planguage: A wide variety of specification devices and analytical tools.

Description: PAPER. Abstract: • Planguage (the Planning language defined in Competitive Engineering [CE]) has a variety of methods and tools to help us identify and choose candidates for solving a defined problem. • There is no single method or tactic for making a ‘best’ choice. • There is no concept of finding a ‘perfect choice’ either. • By rational application of a suitable set of methods, within the time and resources available, a candidate solution can be found, which is probably one of the most satisfactory available. It is probably satisfactory enough. And, we will be able to say something about the solution’s risks, uncertainties, issues, dependencies, and side effects. • We can substantially improve the probability of successful choices. Only in some unreal world, if we had infinite time, infinite knowledge, and static circumstances, could we hope to make a ‘perfect’ choice. • In the competitive world, the necessity is making very good choices rapidly, under conditions of uncertainty, and risk of change.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Decision Rationale: A Quantified Decision-Making Basis Using Planguage

Description: PAPER. Abstract: • Decision rationale are widely discussed in the literature for design decisions [example Burge]. To a far lesser degree for requirements decisions [example Ramesh95]. And practically not at all for justification of Evolutionary project steps or iterative cycle selection [exceptions see Evo in Larman03]. • It is my contention that all software engineering, systems engineering, and management planning specifications can benefit from a variety of forms of rationale. Even specification types not mentioned above, such as source code and test plans can benefit. • At one extreme all plan specifications, and even source code and test cases, can all be viewed as types of ‘design’. So what applies to any type of design applies to them; even though they be, from another viewpoint, classified as something else.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Rich Requirement Specs:The use of Planguage to clarify requirements.

Description: PAPER. Abstract: I believe that most requirements specifications in practice are very poor in clarity, and in content. I believe that in addition to tackling the clarity problem by a variety of rich specification devices, we need to make a requirement specification ‘work harder’ to satisfy a large number of needs by adding ‘background’ to the requirement. The needs I am referring to include: prioritization, risk management, change management, presentation, justification, testability, integration, quality control, and other purposes. To do this I have, over the years developed a requirement specification language, as a subset of my Planning Language (Planguage). This is has been developed by practical need in international industry over decades, and supplemented with some recent ideas. The more detailed version of the Requirements Language is documented in my book Competitive Engineering, which is a handbook defining concepts rigorously. This paper will give an overview of the conceptual basis and some detail as a sample. By ‘rich’ I mean substantially more detail for each requirement than is usual. By ‘background’ I mean information related to the requirement that is not the requirement itself.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Rule-Based Design Reviews:Objective Design Reviews and Using Evolutionary Project Methods

Description: PAPER. Abstract. Design reviews would benefit from the support of formal rules. By the use of relevant rules, it should be possible to ensure prior to a review that all the relevant information for a review is present in the design specifications, and that all the minimum review criteria are met. This will ensure management time is not wasted and aid better decision-making. This paper recommends that the Specification Quality Control (SQC) method be used to do this additional quality control. In addition, this paper outlines the impact of Evolutionary Project Management (Evo) on the design review process.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

A Conceptual Glossary for Systems Engineering: Define the Concept, don’t quibble about the terms.

Description: PAPER. Abstract. We seem to spend a lot of our time defining terms, arguing over terms, standardizing terms, and misunderstanding terms. In connection with my development of a planning language, and its basic textbook I had to make a decision regarding my glossary. One of the formal design requirements I had set for myself was that the planning language, and its textbooks were easy to translate into other international languages. It was primarily in order to satisfy that requirement that I came up with the concept of a concept-centered glossary, rather than the conventional term-focused glossary (like a conventional dictionary). The basic idea is that we focus on defining a concept, no matter how many synonyms it might have, or how many different opinions there are about what the concept should be called. Introduction

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Systems Architecture:A View Based on Multiple

Description: PAPER. Abstract. In order to properly support the systems engineering process, the systems engineering profession needs to consciously adopt a more productive view of systems architecture. Many existing definitions of systems architecture are too narrow: they focus too much on ‘structure.’ The focus needs to be shifted to the impact on requirements. Introduction What is ‘Architecture?’ OK, we know what conventional ‘Architecture’ is in the context of the structure of buildings. So, the question is, ‘What is ‘Systems Architecture’ in the systems engineering context?’ There are many different opinions, and many standard definitions. But I want to argue that most of these are missing some essential truths about systems architecture. They seem to universally miss the point that architecture is addressing system requirements: especially the aim to achieve the required performance and resource levels (a set of defined targets and constraints). Instead, they get hung up on the nature of the solutions (and narrow ideas of those solutions, such as ‘structures’).

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

WHAT’S WRONG WITH AGILE METHODS? SOME PRINCIPLES AND VALUES TO ENCOURAGE QUANTIFICATION

Description: PAPER. Abstract: Current agile methods could benefit from using a more quantified approach across the entire implementation process (that is, throughout development, production and delivery). The main benefits of adopting such an approach include improved communication of the requirements and, better support for feedback and progress tracking. This chapter first discusses the benefits of quantification, then outlines a proposed approach (Planguage) and, finally describes an example of its successful use (a case study of the ‘Confirmit’ product within a Norwegian organization, ‘FIRM’).

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

GREAT CHANGE WITH EVOLUTION

Why Aren’t Software Systems Trustworthy?

Description: PAPER. IT Cutter Journal Paper 2006 Shortened Version of full paper System Trustworthiness: defined: A defined system is ‘trustworthy’ from the point of view of a defined stakeholder or user. The same system states may be evaluated as ‘untrustworthy’ from some points of view, and ‘trustworthy’ by others. Trustworthiness is a relative point of view, not a system state independent of such points of view. The ‘Trustworthiness View’ is subjective. That is, any given observer is at liberty to define a set of system states they consider trustworthy or untrustworthy. We cannot prevent them from having those perceptions. We can identify their perceptions, make formal agreements about their perceptions, and attempt to engineer and operate a system to be trustworthy in accordance with those stakeholders we care to serve. We can also choose to ignore, or give lower priority to, the perceptions of stakeholders that we do not care to serve, to prioritize, or who are uneconomic; or who have requirements outside of the state of the art.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

What are Evolutionary (EVO) Development Methods?

Agile Specification Quality Control: Shifting emphasis from cleanup to sampling defects

Description: PAPER Abstract. Traditional Inspection is often uneconomic and ties up valuable staff resources. Shifting the emphasis from cleanup (that is, from identifying defects and then removing them), to merely sampling the defect level of specifications, produces significant benefits. It enables the quality level of specifications to be determined more rapidly. Consequently, the QC can be carried out more frequently. Systems and software engineers rapidly learn, through SQC feedback, to take standards seriously, which in turn reduces defect injection. Further, by analyzing where/how the defects occur continuous process improvement can be supported. Copyright © 2005 by Tom Gilb. Published and used by INCOSE with permission. Presented at INCOSE 2005 Rochester NY

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Design Evaluation: Estimating Multiple Critical Performance and Cost Impacts of Designs

Description: PAPER. Abstract: How should we evaluate someone’s design suggestion? Is gut feel and experience enough for most cases? Is anything more substantial and systematic possible? This paper outlines a process for design evaluation, which assesses the impacts of designs towards meeting quantified requirements. The design evaluation process is viewed as consisting of a series of design filters. Copyright © 2005 by Tom Gilb. Published and used by INCOSE with permission. Presented at INCOSE 2005 Rochester NY

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Fundamental Principles of Evolutionary Project Management

Description: PAPER. Abstract: The Evolutionary Project Management method – abbreviated Evo – is arguably the best systems engineering project management method (Larman and Basili 2003). However, it is also probably the least known and the least discussed, so the aim of this paper is to shed some light on it. Evo is particularly good at dealing with large, complex, and innovative systems – it does so by breaking down the project into a series of numerous small incremental steps. Each Evo step is both an opportunity to deliver some useful results to the stakeholders, and an opportunity to learn more about the system. INTRODUCTION Let’s discuss Evo by outlining its ten basic principles. They are as follows: E1: Decompose by performance results and stakeholders; E2: Do high-risk steps early, learn how ‘unknowns’ really perform; E3: Focus on improving your most valuable performance objectives first; E4: Base your early evolution on existing frameworks and stakeholders; E5: Design to cost dynamically; E6: Design to performance dynamically; E7: Invest in an open-ended architecture early on; E8: Motivate your team by rewarding results; E9: Prioritize changes by value, not place in queue; E10: Learn fast, change fast, adapt to reality fast. Presented at INCOSE 2005 Rochester NY

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Managing Priorities: A Key to Systematic Decision-Making

Description: PAPER. By Tom Gilb and Mark Maier Abstract. A central concern of systems engineering is selecting the most preferred alternatives for implementation from among competing options. The selection process is sometimes called tradeoff analysis, and is often built on the methods of decision analysis and utility theory. The process can be loosely divided into two parts, a first part in which one determines the relative priority of various requirements, and a second part, a design selection phase, in which alternatives are compared, and the preferred alternatives chosen. This paper discusses the means of determining the priority order for implementing system changes. It also outlines the implications on the selection process of evolutionary systems development. Tom Gilb Tom@Gilb.com Mark W. Maier Mark.w.maier@aero.org Copyright © 2005 Tom Gilb and Mark Maier. Used by Permission of the authors by INCOSE.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Project Failure Prevention: 10 Principles for Project Control

Description: PAPER. Abstract: It is now well-known and well-documented that far too many projects fail totally or partially, both in engineering generally (Morris 1998) and software engineering (Neill and Laplante 2003). I think everybody has some opinions about this. I do too, and in this paper I offer some of my opinions, and I hope to lend some originality to the discussion. As an international consultant for decades, involved in a wide range of projects, and involved in saving many ‘almost failed’ projects, my basic premises in this paper are as follows:

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Rule-Based Design Reviews

Description: PAPER. VERSION PUBLISHED IN SOFTWARE QUALITY PROFESSIONAL 2004 Key words: evolutionary project management, peer review, quality control of specifications, review, review standards INTRODUCTION It is known that most projects are a partial or total failure, and few are totally successful (Morris 1994; Taylor 2001; Johnson 2001). A key reason for this lack of success is the failure of design reviews. In other words, designs must have been approved that were in some way inappropriate. Based on reading the literature and participating in numer- ous requirement and design inspections in many different industries internationally, I fear that most design reviews are carried out: • On poorly written design specifications (in the sense that the design specifications lack sufficient detail for them to be safely evaluated) • Using highly polluted requirement specifications (requirements being the basis for evaluating any design). I find it unacceptable that design reviewers are given no quantified knowledgeof the quality of the design specification, or of the estimated ability of the design(s) to impact on the requirements (that is, the system performance and costs). A common underlying problem is that specification of design is carried out on the basis of inadequate design standards. I sug- gest the following remedies: • A high, defined standard of requirements should be met before entry to the design process itself is permitted. • Design specification should initially pass quality control against design specification rules to ensure the designs are clearly and fully described. • Designs should be specified in enough detail to accu- rately estimate their dominant performance and cost characteristics. • A set of designs should be seen to credibly and numeri- cally contribute to meeting the requirements (the set of performance targets within the resource budgets). • The design review process should work in the context of evolutionary cycles of design (for example, in 50 steps), and not operate on a large monolithic total initial design set.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

The Agile Evo Method: Adding Stakeholder Metrics to Agile Projects

Agile Specification Quality Control

Description: PAPER (5 Page version, Cutter IT Journal , January 2005) INTRODUCTION If we do specification inspections properly able for some: about one hour of effort, per page checked, per engi- neer. The harvest, if we are skilled, is between defects identified. The rest are not found yet, but they will be found inthe final product, in testing, or released products. defects earlier than the test stage is beneficial and may even pay off. But there is a better way, which will appeal to many organizations that have not been able to stomach the high costs, and low effectiveness, of conventional inspection. The main concept is to shift emphasis from finding and fi defects early (in engineering specs before using them for construction) to estimating the specification defect density and using this infor- mation to motivate engineers to learn to avoid defect injection in thefirst place. This shift permits a dramatic cost savings. We can sam- ple rather than check 100 specs when our purpose is meas- urement rather than The main purpose of Agile Specification is to motivate individuals to reduce major specification defect inser- tion. Secondary S To prevent uneconomic major- defect density specs from escaping downstream thus to avoid consequent delays and quality problems. The major tactic here is an S specification process e rier, such as majors per page. To teach and reinforce current specification standards.

Created / Uploaded: Wed 03 of May, 2006

Last Modified: Sun 07 of May, 2006

Creator: Tom Gilb

Gallery: Gilb Papers