Select this to skip to main content [CSUSB] >> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [Monograph] >> 01_4
[Index] || [Contents] || [Source] || [ Search monograph] || [Notation] || [Copyright] Fri Aug 20 10:40:15 PDT 2004


    Previous Section

    [ 01_3.html ] and contents list [ ]

    4 Models of Software Processes

      4.1 Software Life Cycles

        There has been much work on the "Software Life Cycle" - a sequential program for developing complex software projects from cradle to grave. Now, the flaws in SWR (section 2 [ 01_2.html ] above) should make us suspicious of attempts to look for a stepwise program for the production of software. First, the original software life cycles were a description of the life of a piece of software or a product, not a prescription of what to do: In is unarguable that a non-software product(say a new kind of automobile) goes through the following stages:
          Research & Development, Design, Production & Marketing, Support & Maintenance, and finally Obscolescence and Discontinuation.

        How ever this is hardly an algorithm guaranteeing a profitable product - the Edsel almost certainly followed this cycle - with a very short useful life.

        We should not however expect this life cycle to apply to a software project for three reasons. First: A project and a product are not the same things.

        Second, within the software world, there are many different project life cycles:

          The IEEE Glossary states that there are several Software Life Cycles. The IEEE standards group have refused to specify a standard life cycle. Instead they require that one step in a project defines a life cycle for the rest of the project. The Third International Software Process Workshop presented evidence of a variety of software life cycles [Dowson86](editor). A report on Software Quality Assurance in Japan lists 10 companies with 10 different life-cycles and 18 different methodologies and tools [Kishida87]. An article on CASE(Computer Aided Software Engineering) suggests "200 customers have 200 life cycles" [Aranow89]. DeGrace & Stahl describe nearly a dozen distinct sequence of events [DeGraceStahl90]. In Canada, the process for developing and maintaining military software is so complex that researchers have invented a special DFD notation to record it [ShepardSibbaldWortley92]. David Olsen's thought provoking "Exploiting Chaos" gives many counter-examples to the idea that there is a royal road to software [OlsenD93]. Mulhauser et al do not provide a particular method for their "design assistant" but a language for defining such a method [Mulhauseretal93]. There is bibliography in chapter 9 of many methods - there is no single standard program to produce software[cf Coad 88]. Prototyping, re-use, and objects are changing life cycles [BersoffDavis91] [Aranow92] [BerzinsLuqiYehudai93] [DBWAbyZahniser93] [HannaM95].

        Third, in real projects, (1)errors are made causing backtracking, (2) processes pause and restart later [Chroust86], and are done by several "processors"(people) at one time. Software development is in fact a concurrent non-deterministic distributed process! Even the "Waterfall Model" was not always a simple sequence of activities [Davisetal94]. A life cycle imposes a rigid program on a dynamic network [Bryant90] page 231 [FloydC91]. Stafford Beer argued that this is not a viable organization [Beer74]. Instead a living being has a continuously running feedback loop - like the spell-checker case study presented in a recent paper [BerzinsLuqiYehudai93] section IV. Taylor presented a strong case against the existence of a sequential "program" for the software process [Taylor86]. Recent models explicitly diagram concurrent processes [Henderson-SellersEdwards90] [CaldieraBasili91] [Davisetal93] [AueBreu94]. Recent books promoting methods acknowledge this:
          "Software design appears to be a collection of interleaved, iterative, loosely ordered processes under opportunistic control."p78 [White94].

        A queuing system model has been used as a basic model of some software processes [BradacPerryVotta94]. Research on intelligent assistants for software engineers also assumes that the process is dynamic with changes in requirements, technology etc. triggering a cascade of changes in a network [RichFeldman92]. A typical computer product is in dynamic equilibrium with its environment, and so, just like physical matter, it can be in several states: vapor, liquid, soft, firm, and hard [Botting93]. Software is not the only kind of product that has a non-sequential research and development process - Concurrent Engineering can be applied with any product [Reddyetal93] [PulliHeikkinen93]. Because software is part of many new products these processes will have to be used by future software engineers as well. Therefore we need a non-sequential model of software development that can be scheduled to fit different environments and changing situations.

        Some programmers and managers are skeptical about "process re-engineering" but the most obvious alternatives: hard work, tools, and technological fixes, have not put out fires caused by bad practice [Royce92] [Glass94]. The Software Engineering Institute( SEI ) at Carnegie Mellon University has developed a plan for improving a software process. The first step is to document the particular process that is in place and set up ways for it to monitored. Later levels involve the process becoming repeatable, predictable, manageable, and, finally, continuously improving. Once a process becomes repeatable then it can be re-engineered as an explicitly concurrent process [Aoyama93]. The NASA/Goddard's Software Engineering Laboratory has a similar goal to the Software Engineering Institute's processes but is more local in scope. Each project carries out experiments that are locally monitored, analyzed and packaged as experience to be used in current and future projects. This called an "Experience Factory" [Gotterbarn93] [OivoBasili93] [Basili95]. This part of this chapter gathers effective processes from 25 years of experience. These processes can be incorporated into existing processes to improve them.

        So in the absence of a life-cycle or sequential program, a non-sequential model is needed. I will simply (1) categorize the data in the process and (2) plot the data flows. Section 4.2 below describes the PQRST classification of data in the software process [Botting85], cf [BerzinsLuqi91] Figure 2.1, page 24. PQRST helped develop a DFD of loosely coupled components (section 4.3). Sections 4.2 and 4.3 summarize ideas from more than 100 sources - with the British SSADM and SDM methods as seminal contributors. These components can be formalized(chapters 2 through 7) and partly automated in an improved software process(chapter 8).

      4.2 PQRST

        Many different ideas are considered in good software project. It is not a question of just the function, the data, or the tools, but depends on combining many viewpoints [FloydC91]. PQRST is a mnemonic for a set of five factors (or viewpoints, projections, attributes,...) that interact to determine the structure of software. In this section I will take each in turn, describe it, show how it appears in different methodologies, and trace its history during a life-cycle.

      1. PQRST::=P >< Q >< R >< S >< T.

        .Figure A cube with 6 views labeled Purposes, Qualities, Reality, Systems, Technology

        P is for Purposes

        Verbs in a mission statement signal the Purposes of the software. Some methodologists call these goals, functions, or functional requirements. To ask "Why" is to ask for the purposes of something. If purposes are forgotten, the user may not have any use for the software. Functional methodologists quote that "form ever follows function" but purpose alone does not determine a unique design{12}. There is more to software than "function" [Botting87a]. To use the idea of Purpose effectively it must be admitted that (1) any piece of software has many purposes, (2) these purposes are delegated to parts of the system, (3) some purposes turn into problems that need solving, and (4) some purposes are negative: security, safety, reliability,... and are provided by making some things impossible

        [Baskerville93], and (4) some purposes are not discovered until a product is actually in use. The primary form would be:

        1. (1) "To help <user > achieve <something> by <providing a service>."
        2. (2) "To help <client> achieve security by not<providing access> to <something>"
        3. (3) "To help <client> achieve safety by not permitting <some pattern of events>"

        A key property of a useful Purpose is that it should refer to the observable behavior of the system, not the internal working that achieve the result. Purposes should be user oriented not technically focused.

        Purposes are discovered in many ways - looking at documentation, structured interviewing, observing, guesswork, analysis, and Quality Function Deployment (QFD): - It is worth sketching scenarios (specific or generic) of ways a user gets what they want done and discussing them with users [PottsTakahashiAnton94]. These should have their essential elements abstracted from any technological or technical factors [Constantine94]. There are several ways of documenting the result including: lists [Rumbaugh], grammars & STDs [Hsiaetal94], DFDs [RubinGoldberg92] [GoldsteinAlger93] , and timing diagrams[Jacobsen, Goldstein & Alger]. Tracing the flow of data in existing systems can help show how it helps users achieve their purposes, and how it fails them. In SSADM(1982) DFDs and ERDs break down a purpose (function) into a sequence of steps called a "Logical Function Description"[ [ SSADM in subjects ] ]. JSD places purposes into a dynamic simulation model of the user's world -- a simple purpose needs extra operations added to an object but a complex purpose adds new objects that access and intervene in the model[ [ JSD in subjects ] ]. Wide non-software use of TQM has lead to the discovery that Quality Function Deployment (QFD) is an effective way to develop Software Requirement Specifications(SRSs). The "Function" part of QFD is to uncover and prioritize the user's purposes [Haagetal96] [Wyder96]. Half-a-dozen of the largest vendors of software then refine them into a set of software requirements(purposes), and then correlate the user's purposes with the detailed requirements. The correlation matrix lets one relate the user's priorities to the technical requirements for the software [Haagetal96].

        In recent methodologies an object is assigned it's own set of purposes - called its responsibilities: A responsibility has the form "To help <client entities and objects> achieve <another purpose or responsibility> by <providing a service> and using <services of other entities and objects>" [LamShankar94]. Many objects are also responsible for some degree of security and safety. All responsibilities can be formally refined into a set of contracts between each object and its clients[Meyer 82],[Meyer 85],[Meyer 88],[Meyer 92]. Some OOD methods use the responsibilities to repackage a logical set of objects into a physical system that has desirable qualities like re-usability and/or speed [GoldsteinAlger92].

        Q is for Qualities

        It has proved difficult to develop a scientifically valid single measurement of software quality. There is a serious risk of using a simplistic "Bogus" metric - like Lines-Of-Code - to manage the software process. Bogus metrics actually encourage developers to produce bad software [Bollinger95]. Measurement theory leads one to look for many different measurements that help answer questions about the software and achieve project goals [Fenton94] [Fentonetal94] (sidebar). Hence Basili's Goal-Question-Metric paradigm [Basili95]. Outside the software industry there has been a renewed focus on the contribution of the quality of a product to the long term profits and survival of companies: Total Quality Management(TQM) has become an important slogan in the battle for market share. The "Quality" part of QFD applies the process described above for Purposes to uncover and prioritize the user's desired quality needs and then refine them into metrics and testable properties. These are then correlated with the user's qualities. This let us calculate the priorities in the technical qualities of the product itself [Haagetal96].

        So, it is clear that a product has potentially its own ideal set of qualities. These appear as adverbs in an informal specification and mission statements. These "ilities" suggest how the software should perform - quickly, reliably, easily, securely - these can be called the software's qualities . To ignore a need for speed is to risk building software that outputs the correct results too slowly. These are some times called non-functional requirements. Other methodologists call qualities "attributes" [Gilb] [Fenton94] or "performance and implementation constraints" [BerztissLuqi] or "non-behavioral requirements" [DavisA90]. Tom Gilb spent much of his career promoting a quality-driven design method called "Design by Objectives" [Gilb].

        Run time qualities need to be analyzed until they can be measured objectively during acceptance testing. Predicting future qualities are part of a Software Quality Assurance program (performance models, metrics, defects/KLOC, mean-time-to-fail, etc). Cost, time to produce, time-to-market, size of workgroup, expertise of the team, re- usability, etc. are important qualities that are the prime concern of the producer. They effect the user indirectly. The anomalous negative purposes: security, safety, reliability etc are best handled as qualities as well. All qualities have to be analyzed, traded-off, predicted, measured, tested, and monitored. Finally it helps to know, for each project, and each part of the project, which qualities have to be the best possible, which just have to be just "good enough"(and how much is good enough), and which are not important [Yourdon95] [Gilb]. Notice that in the real world some qualities are sacrificed to optimize others. In theory there is normally only be one quality that can be optimized at a time - the rest usually being forced to their worst "good enough" values{13}. Sometimes a collection of qualities have to be "traded off" so that all are "good enough" but none are optimal. This happens when optimizing any one quality forces other qualities out of their "good enough" range. Also note that some techniques can improve two qualities that are normally traded off: for example by reusing code Matra Cap was able in one large system improve time-to-release and the fault rate [HenryFaller95].

        Understanding the multiple nature of Qualities also help us understand how different industries need different life-cycles or processes. Thus in a mass market the "time-to-market" is a critical quality (for profit) but "correctness" is sacrificed [Bond95]p42-43 [Keufel95b] [Olsen95] [CardDN95]. On the other hand, a contract for a fly-by-wire system for a jet airliner should have "safety", "reliability", "usability", and "correctness" as critical qualities that are earned by sacrificing other attributes. As the old slogan put it: You can have it good, fast, or cheap - pick two! In these cases the critical success factors are different and lead to different plans, staffing, etc. However in all cases the project needs some form of quality control even if given a different name: A mass-marketed package may rely on user feedback and daily builds, but in the "fly-by-wire" project all documentation and code will be reviewed, inspected during development and tested at the end.

        Qualities define what "better" and "best" means [Fenton94]. As with other branches of engineering, the qualities found in a piece of software depend on the technology, tools and techniques used to design and construct it, so qualities determine the techniques and technology for a project [Cardenas-GarciaZelkowitz91]. Performance engineering, the analysis of algorithms, and data base design further show that the physical structure of software and data are determined by the desirable qualities rather than the purpose of the software.

        R is for Reality

        Reality is about "What can be" not "How to" or "What is." Section 3.6 above concluded that many design decisions can be based on reality. Winograd was an early academic advocate of the importance of the real world [Winograd79]. Adjectives and nouns in a mission statement refer to the reality with which the software is concerned. Abbot proposed using nouns and adjectives as the basis for ADTs [Abbot83]. Booch demonstrates this approach to design in detail [Booch83]. This method has been criticized and improved on, however More recent work has introduced the idea of an "Environment Model" [BerzinsLuqi91], "enterprise model" [Bachman92], formal ADTs/Objects [Wagner90b], "Content model" [GoldsteinAlger92], "Natural-Language Information-Analysis Methodology" [BrayHess95], "context" [Racko94], "Business Process Models" [Chauvet95]etc. "Domain Analysis" studies the "Reality" across a set of similar projects. EBNF, Data Dictionaries, JSP diagrams and relational schema define data that encodes the state of the environment. So, these define views of reality. The entities, relationships, and attributes (ERA ) in a data base and an Entity-Relationship-Diagram(ERD) give a static picture of reality [Bachman69] [Bachman73] [CODASYL71] [Codd70] [Wiederhold77] [Chen80] ... [ShlaerMellor88] [DedeneSnoek94]. Data base systems and object-oriented technology make it possible to implement software with a structure that mirrors reality [cf Wile 83, Henderson-Sellers & Edwards 90(p145), Korson & McGregor 90, Hawryszkiewycz 84 & 91, Slater & Carness 92, Embley et al 95]. GUIs also make a structure visible - the R view of the problem is an abstract metaphor underlying a useful GUI [Lovgren94]. Mays argues for more support for the conceptual modeling that a developer is forced to do with graphics [Mays94]. User Centered Development is a method that focusses the developer to look at the user throughout a products life cycle and promises improved usability as a result [Szmyt94].

        In one sense the word 'Reality' is misleading. It suggests that there is something "out there" that is being modeled. It is important to be aware that much of what we model is constructed by the people in the system. In other words the term 'reality' includes much that is imagined and superimposed on 'objective' things. There has recently been some interesting appeals for the application of philosophies that stress the negotiation and structuring process of a business or other organization [ POSTMODERN in subjects ] It can be argued therefore that one needs models of people's thinking as much as their actions and needs.

        It is impossible to prove that all possible cases have been allowed for without a model of the possibilities that can occur. The possible patterns of events a part of the R view of the problem. Further we need to understand what events can happen, the possible patterns of the events, and the significant patterns of events. Then we can produce systems that handle them all. Call this network of information: "dynamic reality". It is expressed as entity life histories(ELHs), Harel's Statecharts, state transition diagrams (STDs), Petri Nets, Traces [KayReed93], regular expressions [DedeneSnoek94] [ JSD in subjects ] [ SSADM in subjects ] , etc. Any of these are a basis for Dynamic Analysis and Design(DAD)[see bibliography in Chapter 9]. Jackson uses a network of dynamic objects that maintain a real-time simulation of the reality [ [ JSD in subjects ] ]. JSD and SSADM show that many of the "update functions" in traditional systems can be distributed and encapsulated in the patterns of behavior of simple "Real" entities. Similarly the various Data Directed Design methods(section 3 of chapter 1 above) show that the "real" data needed for a given Purposes can be defined by EBNF-like grammars with a program design following semi-automatically. In summary: Experience and theory indicate that Reality provides a foolproof self-documenting structure for designs. However this canonical structure does not necessarily satisfy the all the user's Ps & Qs. Hence some methodologists recommend documenting a canonical design plus a map of how this structure is implemented in a satisfactory - examples include SSADM, Data Base Design, Solution Based Modeling, and some OO Design Patterns [Gammaetal94].

        Problems have terms that need defining and facts to discover. Software engineers need to explore conjectures and theories. This implies using using logic to model "reality"[Chapter 9 under [ LOGIC in subjects ] and [ FORMAL in subjects ] ]. The facts, definitions, conjectures, questions. answers, assumptions, reasons, and consequences need to be recorded [PottsTakahashiAnton94]. Expert Systems, Declarative Programming, and Logic Programming each apply a common algorithm to a set of facts and theories. These form an R-view of the domain. Goldstein & Algers argue that each domain tends to define its own reality (categories) and that as a result classes are less re-usable than expected[ chapter 5 of Goldstein & Alger 92]. The documentation of the logic: facts, definitions, assumptions, entities, relations, metaphors, dynamics,... - is a necessary ingredient of software engineering.

        S is for Systems

        Most programmers prefer to start from scratch but the current system(data+hardware+software+people) is an important source of information that needs to be tapped prior to changing it. Henry Petrosky has documented case after case where the design of an object(Examples include: bridges, cutlery, sticky tape, etc ) has evolved by the removal of perceived faults in the current solution. The current system was and is the starting point for (1)traditional data processing(Circa1965), (2)SAD(Circa1975), (3)SSADM(Circa1980), and (4)SBM [GoldsteinAlger92]. Software reuse also depends on what exists [Schaferetal94]. Similarly process improvement (the re- engineering of software engineering) must also be based on a repeatable and measured current process[SEI Process Maturity Model]. Legacy code is common problem in current systems. The code is often the only detailed record of what the software does(should do?) and how the data is organized [Kozaczynski91] [Ningetal94] [Wongetal95] [BrayHess95]. Special cases can be executed symbolically to derive new code [Coen-Porisinietal91]. However code rarely gives enough information about why it is the way it is [Levesonetal94] [Wongetal95] [BrayHess95].

        Computer scientists ignored existing systems until "software re-engineering" became a fashionable topic to study [Saradhi94] [Arnold94]. Clearly re-engineering must start with a thorough assessment of the current system [Calchera95]. Re-engineering aims to replace old code by something that is easier to maintain. Informal and/or Formal specifications can also be reverse engineered from code [LanoBreuer90]. Techniques invented for analyzing manual systems (DFDs, ERAs, Normalization, etc) also apply to code [IEEE Software Engineering Technical Committee(TCSE) Reverse Engineering newsletters 1992]. It is possible to integrate a CASE system for a method (VIEWS) with DFDs, ERAs, Scenarios, STDs, Requirements(P&Q), etc. with a reverse engineering code analyzer [O'HareTroan94]. Grady Booch has recently been talking about "round-trip" CASE which can automatically map specifications into code and reverse engineer code into specification.

        The system is not the real world! S ­ R: A bank deposit form is part of a system(S) perhaps but it records an event. It stands for something real(R) [pp80..87 of Goldstein & Alger 92]. A button on a screen(S) is a way to trigger some useful process, it is not that process. The current system(S) implements certain Purposes(P) that refer to certain Realities(R) under Qualities(Q) and Technological(T) constraints

        Studying the current system/situation needs care and intelligence. Here are some examples:

          Documentation Manuals, comments in code, plans, blueprints, analysis and design products,... [GoldsteinAlger92]. Project documentation from previous cycles: requirements, memos, specifications, designs,.... these may all be more or less reused, rejected, or learned from.

          Observations The Reality model needs "reality checking." The R model is a theory and must be tested versus observations [Checkland81].

          Samples of current data (eg forms, screens, data structures, ...). These show what data is important [Choobinehetal92] [GoldsteinAlger92]. However, the abstract concept of the data has to be abstracted from the current implementation [AikenMuntzRichards94]. Formalization and normalizing do this .See [Codd70] [Codd82] [Choobinehetal92]. It is usually better, however, to make a simple manual prototype and test it before normalizing [Rettig94]. Data are easier for clients and users to understand than algorithms. Data dictionaries and EBNF define the form of data in the current or proposed systems.

          Statistics about the current system provide information needed for predicting performance, reliability, and other qualities of the system [Musa93] [Bernstein93] [Oman94]. Statistical data about experimental systems can make released systems more usable [Carroll82] [Malone83] [MackLewisCarroll83] [...].

          The flow of data and work in a system delimits parts that need to be (a) replaced, (b) protected, or (c) re-used. Successfully integrating software into an existing system requires that the work flow be modeled [CurtisKellnerOver92]. A DFD of the current system determines the interfaces between (1) new vs old [GaneSarson] [Cutts90] [WeinbergV79]; (2) human vs automatic [SSADM], (3) physical vs conceptual [LemosSauudAnderson92]. DFDs can help the reverse-engineering of the current system by re-discovering the why's (PQ)and what's (R)of the design.

          The people are part of the current system who need to be involved in software design [Collinsetal94]. The Ethics approach [MumfordWier79], Joint Applications Development(JAD) [WoodSilver89], operational prototyping [DavisA92], etc. apply this idea. Users, clients, and domain experts are important resources that a software engineer needs to tap via interviews, brainstorming sessions,... [GoldsteinAlger92]. The presentation of prototypes to users and clients is an important step to ensure that the project is going in the right direction [Dichter93]. The June 1993 issue of the Communications of the ACM is a survey of the state of the art in Participatory Design [MullerKuhn93]. Interviews can sort out inaccurate and ambiguous documentation [Bandinelietal95] [Wongetal95] [BrayHess95].

          Talk to your customers and clients [DavisA94a94b] [ [ USER in subjects ]

        1. and [ QFD in subjects ]
        2. in chapter 9 ] Also check out your rivals products in the same market - they are also part of the system in which your new or improved product must survive!

          Code Programs and scripts/JCL are a common place to look for clues to lost designs and requirements documentation [LocastoDarpel93]. A survey of MIS manages rated the importance of information that can be got from code: (1) data definitions (2) problem code, (3) data models, and (4) data flows and logic [HannaM93] There are also recyclable components to salvage. Components, tools, and ideas can be reused [Basili90] [Gotterbarn93] [OivoBasili93] [Ningetal94] [DavisA94a94b] [HenryFaller95]. Legacy systems can be wrapped in modern interfaces rather then being redeveloped. Reuse technology has been a hot research topic recently but wise engineers have always made use of current resources to reduce the total cost of a change. Meanwhile people report figures that indicate that reused parts costs 2/3rds less and that 60 to 80% of code can be reused [Gotterbarn93]. Reuse has a good effect on the number faults in code and the speed at which it is release [HenryFaller95] Searching for reusable pieces of legacy code is expensive even with special tools [Ningetal94]. Reusable parts may need to be specially designed [Endres93] but others claim that parts designed using information hiding and separation of concerns(eg physical vs logical, logic vs database, etc) can create parts that are worth reusing anyway [HenryFaller95]. Matching existing parts to new needs depends on having both specification and code ready for reuse [Bellinzonaetal95]. However, as Stan Kelly Bootle pointed out [Unix Review Aug 93, p101], anyone who has tried to find the right replacement part for an automobile knows why large reuse systems may not be cost effective[cf p89 Goldstein & Alger 92].

          Maintenance starts from the current situation (S) and aims to make the minimum change to fix some symptom or add a new feature. Nowadays this is may be expanded to recoding or redesigning parts of the system: re-engineering it [Arnold94]. The S factor in PQRST should remind us of the quantity of legacy code that exists and a history of academic ignorance [Matsumoto95]

          Safety, Security and Reliability concerns are also embedded in the current system. Like many qualities they are hidden in the details and need to be extracted, analyzed and if not worthless, preserved in future designs. The procedures themselves may be obsolete but they can not be ignored. Later systems normally have to show an equal or greater regard for the same qualities. Such concerns should become the Purposes and desirable Qualities flowing through the development processes into a specification of a new system.

        T is for Tools, Techniques, Technology, and Teamwork

        An engineering project depends on the tools and materials available (Languages, Libraries, Systems, Methods, Patterns, . . .). Computer people tend to over estimate the value of technology. T-factors are another set of factors that must be understood. The designer needs to know the T-factors are mandated, encouraged, permitted, forbidden, and afforded[Dasgupta's implementation constraints] because these determine the set of solutions. When T- factors are not analyzed out of a problem unnecessary constraints lead to inadequate solutions [Constantine94].

        Several recent focal topics in the literature are T-factors. Teamwork and process are an important part of determining the quality of software development. Selecting an architecture and architectural style constrains the possible designs for a piece of software and so architectural concerns are also T factors. Similarly if a project uses a particular pattern language then it constrains the possible designs. Patterns are themselves T factors.

        When T-factors are not mapped into Q-factors during design we risk producing infeasible designs. So the T-factors must be studied, analyzed, and documented; for they determine the qualities of the result. We could summarize the process as:

      2. PR=S-T; S'=PQR+T' where S' and T' are the new systems and technologies respectively.

        Some call the T-factors resources to be used [BerzinsLuqi91]. A wise implementation of a process improvement, SQA, or TQM process should expect the technical staff to review and choose technologies and techniques that make things better [Glass94].


        The current system(S) implements certain Purposes(P) that refer to certain Realities(R) under Quality(R) and Technological(T) constraints:
      3. S is a function of P, Q, R, & T. We can analyze the methods covered earlier in this chapter as follows
        Modular Programming TStepwise Refinement(SWR) TP
        Functional programming(FP)P;TPFunctional decompositionP;Q;T
        Information HidingPTSystems AnalysisST
        Structured Design(1) PTStructured Design(2)PRT
        Syntax Directed ProgrammingR;TData Directed Design R;T
        Data EngineeringR;Q;T;PExpert SystemsR;T;P
        Dynamic Analysis and DesignR;PFormal Modelling RP
        QFDPQ;TPQRequirements EngineeringSPQ;R;P'Q'
        (XY means both X and Y are consider together, X;Y means that X is considered before Y, X' indicates a changed or new X).

        Keeping PQRST in mind reminds an engineer to cover all the bases. PQRST separates the concerns between what is needed (PQR), what is (S), and what can be done(T). The engineer develops requirements(PQRT) from what exists(S) and searches the techniques(in T) to develop a system (S') to satisfy the requirements [Simon69] [Petroski85] [Dasgupta91]p 165 [Marketal93] [Chisholm94a]. Research has stressed the difference between developing the PQR components and the ST factors, and the need to keep these as connected but decoupled [BerzinsLuqiYehudai93] [RomanWilcox94]. PQRST reminds an engineer to look at the current software(ST) to see what can be reused(S--->---S') [Basili90], re-engineered (changing the T in ST (ST--->---ST' )), or reverse engineered(ST--->---S--->---PQR) [ChikofskyCross90] [AikenMuntzRichards94].

        The PQRST framework separates so-called functional requirements (PR =Purpose+Reality) from non-functional requirements (QT = Quality + Technical).Most research has concentrated on modeling the purpose (note the presumption that there is only one reason for software existing) using logic [BorgidaJarke92]. Occasional papers propose systems that track the performance aspects(Q) of multiple implementations(T) of a purpose(PR) [Gilb] [Ramamoorthyetal90] [MylopoulosChungNixon92]. Recent research has noted what is implicit in Jackson's work and in SSADM - optimal designs are harder to understand, maintain, and produce than software that results from optimizing a working prototype or proved design [BerzinsLuqiYehudai93p450]. Chapter 9 has a subject bibliography on the Q factors [ QUALITY in subjects ] and appendix 3 has some speculation on a formal model of design that includes multiple qualities. It is not always possible to optimize all qualities with one design [Simon69]. There is no algorithm because design involves (1)tradeoffs, compromise, and creativity [Petroski85] [Dasgupta91] p64 and (2) intractable or uncomputable problems eg. [Marketal93p883]. It can even be difficult to determine a set of requirements(PQR), let alone a design( pages 18 to 19 of [FeatherLamsweerde94]

        A library of modules can not be reused effectively unless it is possible to find modules that fit the problem. Current source code libraries and repositories are strong on the P and R factors but often ignore the Q factors [Nishidaetal91] [Zavidoviqueetal91] [...]. The T factors are often clearly documented but - by Parnas - should be hidden.

        Each factor has a different life cycle: Purposes develop top-down. Qualities develop from fuzzy adverbs to tests, metrics, etc. Reality starts as a list of nouns and adjectives and ends up as declarations. Systems evolve by a random walk with a cycle of small "tweaks" embedded in a larger cycle of "twiddles". Technical information develops from a concept, to prototype, to product, and then to obsolescence. It would be surprising if there was a non-trivial project life cycle that incorporated all these clashing patterns of behavior!

        Experiments with PQRST

        In 1985 I made a prototype CASE system based on PQRST and carried out some experiments. Results showed the need for a more detailed analysis of the software process [Botting85b] [Botting87a]. I used my prototype CASE system to model the software processes implicit in half-a-dozen methods [Botting89b]. This has been reworked, expanded, and corrected for 6 years now. The current result is next(section 4.3).

      4.3 Software Development System

        NumberShort Description Notes/SourcesInputsOutputs
        1.Operate and Monitor systemf, IEEESystem Client, Managers
        2.Analyze problem domain/conceptsDE, Abbot, Booch, FMClients PQRS
        3.Document System that has probleme, Checkland, SASystem PQRST
        4.Manage projectg, Boehm, GilbManagementQT
        5.Negotiate changesGane&Sarson,JAD, QFDPQRST+ClientQ'S'+Client
        6.Plan system scheduleSSADM, PEPQS'T S'Q'
        7.Build mockupBotting 85, RADPQ'RS' Mockup
        8.Improve mockupMumford, JADMockup + ClientMockup
        9.Normalize dataDEMockup, PS'R'
        10.Decompose processinge, SD, SWR/FDMockup, S'P'R'
        11.Analyze dynamicsDADRS'R' R'
        12.Specify objectsOO, SSADMP'R' Spec.b
        13.Specify purposese, SD, FM, SWR/FD,QFD P'S'R' Spec.
        14.Specify physical data+algorithmsSSADM, DE, CSciSpec+'T Data
        15.Maintain performance modelSSADM, DESpec+DataModel
        16.Improve physical data+algorithmsSSADM, DE, PE, CSciQ'+Model+DataData
        17.Document performance problemsSSADM, PEQ'+Model+DataQ'+Client
        18.Derive dictionaries & grammarse, JSPSpec.+DataDict.c
        19.Detail Dynamicse, DADSpec. Dict.
        20.Refine Purposese, JSP, SWR/FDSpec.+Dict.Spec.+Dict.
        21.Derive program/object structuree, JSP, LCPDict.+Spec.Blueprint
        22.Extract & list operationsJSPSpec. Blueprint
        23.Embed operationsJSPBlueprint Blueprint
        24.Resolve nondeterminisme, JSPBlueprint+SpecBlueprint
        25.Create breadboardBotting 85Blueprint+MockupBreadboard
        26.Test breadboarde,"debugging"Breadboard+P'Q'R'S'TBreadboard'
        27.Tune breadboarde, PEBreadboard+Q'TBreadboard'
        28.Fit to schedule/compile, . . .JSPBreadboard+Data Code
        29.Fit into system"coding"Blueprint, Code System
        a.A prime(') marks a P, Q, R or S for the new system [RossAshby] [LamSharkar].
        b.A spec. is a specification. and includes/accesses relevant parts of the new P'Q'R'S'T'.
        c.A dict. is a dictionary or repository defining ideas and describing facts.
        d.A software blueprint is commonly pseudocode or a structured flowchart, see Tripp 88.
        eSome explicitly excludes these processes.
        f. Can include user written programs.
        g.Management includes planning, resourcing, setting goals, monitoring,...
        CSciComputer Science - clicheŽ+algorithm, data structures and algorithms, heuristics, ...
        DEData Engineering - ERD, Normalization, Conceptual models ...(see [ DATA in subjects ] and [ ERD in subjects ] in Chapter 9)
        FMFormal Methods - eg Hoare, Woodford, Ince, Spivey, Zave, ...(see [ FORMAL in subjects ] in Chapter 9)
        DADDynamic Analysis and Design - SSADM, JSD, Harel, MERODE,Shlaer & Mellor ... ( [ DAD in subjects ] in Chapter 9)
        JADJoint Applications Development and Participative Development - Wood & Silver ,...( [ USER in subjects ] )
        JSP/JSDSee Michael A Jackson and John Cameron ( [ JSP in subjects ] , [ JSD in subjects ]
      1. )
      2. LCPWarnier/Orr, also DSSD ( [ LCP in subjects ] and [ LCS in subjects ] )
        OOObject Oriented - Abbot, Berard, Booch, Coad, ... , OMT, SBM, Fusion(see [ OBJECT-ORIENTED in subjects ] )
        PEPerformance Engineering - Botting 88, (SPE) Smith CU 90, ... (see [ OPTIMIZATION in subjects ] )
        QFDQuality Function Deployment Haag et al 95, Wyder 96...(See [ QFD in subjects ] )
        RADRapid Application Development (See Martin 91, [ PROTOTYPES in subjects ] )
        SAStructured Analysis - Gane and Sarson, Weinberg V,... Davis A 90( [ SAD in subjects ] , also parts of [ SSADM in subjects ] )
        SDStructured Design - Yourdon, De Marco, Constantine, Mastro... Davis A 90 ( [ SAD in subjects ] )
        SWR/FDStepwise Refinement, Functional Decomposition,... - any college programming text( [ SEQUENTIAL in subjects ] )
        SSADMStructured Systems Analysis and Design Method --UK Civil Service(NCC), Hall 81, Cutts 88( [ SSADM in subjects ] )
        .Figure N-squared chart of the above

      4.4 Software Quality Assurance(SQA)

        Each piece of uninspected code, design, specification, test case, or model is a weak link in the software system. As defects pass through the system wasted work is done so wasting money and time. So each part should only release an output when it has passed a quality gate [Hastings93]. So, it is inaccurate to model SQA as a separate process. In section 4.3 SQA is present in every part. SQA must parallel other processes. Further the DFD in 4.3 does not show a necessary meta-system which "hovers" above the system looking for ways in which the process can be improved - for example Total Quality Management(TQM), quality audits, or process improvement [See chapter 8]. A similar meta-meta-system of quality control procedures should work on the SQA system: Later SQA procedures should be used to measure the effectiveness of earlier processes [Fagan76] [BarnardPrice94]. A 1% investment of time in analyzing samples of the defects found in testing to determine their cause (DCA) can reduce defect rates by 50% [Card93]. Hastings argues that software bugs are bugs in SQA, not in the process that made them [Hastings93]. Given step by step SQA, the final review of a product and the project becomes a way to improve the process by extracting the "Best of Practice" from what was done in the project [Glass95].

        SQA implies that work is inspected. So it must exist in a readable form - documentation and code [Goldberg87].

        "[. . .]The documentation must be complete and precise, making use of mathematical notation rather than natural language.[. . .] Mathematical verification techniques must be used to make the review systematic and rigorous." [Parnasetal.] p647 Since documents will be reworked, documentation should be computerized. Computerized documentation can be submitted to new kinds of checks as well as traditional SQA procedures [KnightMyers93]. Formal documentation can be checked and compared automatically [LieteFreeman91] [LutzWong92]. Automatic checking of protocols specified in formal terms is normal [IEEE Software Vol 8 No 1, January 1991, pages 14-46]. Rigorous checking and analysis of documentation needs formal versions of all facts, assumptions, viewpoints, requirements,... , so more rigorous SQA implies more formal models.

      4.5 Maintenance

        Apparently "maintenance" is missing from the system in section 4.3 above. But each maintenance activity is in it. Now, a DFD omits the timing of the processes and maintenance is a period of time in a piece of software's life. In fact, few projects start from scratch these days [Pierce93] [Matsumoto95]. However the same processes occur in maintaining a system as in developing a new one. The difference is that in development the changes can be wide ranging. The goal of maintenance is to minimize the disturbance to a running system while eliminating undesirable behaviors and promoting desirable ones. The DFD of 4.3 describes both development and maintenance.

        Recent publications have developed the theory and practice of re-using and re-engineering existing code[ [ REUSE in subjects ] , [ RE-ENGINEERING in subjects ] ]. Engineering is about improving, modifying, and correcting things. Much computer work was and is replacing old programs by new ones or renewing a part of a program [PlaiceWadge93] p268. It should be the norm to scan what exists and reuse the best of them. All the PQRST factors change, so people are developing techniques to support the maintenance and reuse of such domain and design information [Baxter92] [Pfrenzinger92] [PlaiceWadge93] [Prieto-Diaz93]. The same activities are in operation throughout the "Software Life Cycle" however. A better software process would not have a special maintenance process.

      4.6 Conclusions (1) - Modelling Software

        Here are half a dozen kinds of preliminary models - "prototypes" or "representations" - of value to software engineers [compare Botting 85]. Collins et al [94] give a case study of a system that had to be taken down - any collection of two or more of the following models would have avoided the problems.


        Engineers have always drawn rough and ready sketches of their ideas. Until ideas are on paper, they can not be discussed, inspected, altered, improved, etc. . These engineering sketches look informal but are based on the same standards that are used for blueprints, circuit diagrams, etc. . Software engineers don't have an adequate notation for sketching ideas, plans, and concepts. Clearly some quick, easy, and precise system is needed.

        Performance model

        A performance model relates a set of Techniques/Technology to the resultant qualities: speed, size, IO volume,... . It helps select good designs - this is particularly important in data and performance engineering [Smith89] [SmithCU90] [SmithCUWilliamsLG93]. A spread sheet is one tool. Animated quantitative models and simulations are useful. Simple rules of thumb help [PechuraandShoefler83]. The "Analysis of Algorithms" is less helpful and can give misleading results [Botting88].

        Mock up

        A prototype is a Mockup if it can show the interface to the user, but is not useful to the user. Tools make it easy to generate, test, reject, and change mock ups. The better tools can generate optimized code for the final product from a mock up automatically. A mockup can be used to generate validated scenarios that lead to a project infrastructure - a set of classes that can be used throughout the product [Capperetal94]. A mockup verifies the look and feel of the system, unlike the next prototype that tests the inner workings.


        A breadboard tests implementation ideas and belongs in a laboratory. Breadboards need to be rapidly created and adapted. Breadboards are instrumented and parameterized. It should be possible to attach "signal generators" and "probes" to the interfaces between the parts to explore how the system works. They tend to have a complex and untidy interface with the engineer and not the end user - for example Cleaveland Parrow & Steffen 93. Debugging should take place on a breadboard not the final system. A recent project set up a breadboard system to test UNIX utilities on several platforms - they showed that 24%-35% of the utilities had bugs lurking in them [MillerFredriksenSo90]. Graphical breadboards already exist [CoomberChilds90] [TyszberowiczYehudai92]. The transformation from breadboard to a scale model or final system should be automated. Research on program transformation and simplification may show how [Jackson78] [Coen-Porisinietal91].

        Scale model

        A Scale Model is close to the final system, but does not have all the data available. All the purposes of the system can be tested with fewer occurrences of the entities/objects. A scale model is a better system to use for debugging than the production version. Scale models have been a part (if anonymously) of standard DP practice for decades.

        Blue print

        A blueprint is a design representation - for example the results Shlaer-Mellor analysis described by Neil Lang [Lang93]. An executable design is a prototype but a drawing(on paper or a screen) is a blueprint if it can not be executed. Blueprints must be inspected for defects(see section 4.5). They should permit the derivation of the properties of the design. In particular logic errors must be as obvious as possible. There needs to be a way of predicting the limitations on a design in terms of its speed, capacity, and range of safe usage. The translation of blue print to mock up, bread board and scale model can be partly automated[for example Engels et al 92].

        Evolutionary Prototyping

        The above are all "throw away" prototypes. A popular prototyping technique is to give the user an initial system(a muddle of bread board, mock up, or scale model typically) to play with and then modify it to make it more useful. This usually leads to happier users but the quality of the product is likely to suffer unless a strong discipline is used to control the development process. Problems arise when inexperienced people are doing design work, managers, sales people, and customers can all badly estimate the amount of work needed to produce the final system [GordonBiemen95]

        Operational Prototypes

        Operational prototyping is a recently discovered process that gives users a slowly evolving high quality "baseline system". This grows by adding desirable and well understood features. An engineer installs experimental "throw away" features into the operational system. These are always removed after experimentation - but the prototyper then submits a change request for the next base line model through a high quality but slow software engineering process [DavisA92].

        Refactoring and eXtreme Programming

        Refactoring REFACTOR is a process that allows programmers to maintian and improve the quality of object oriented code without effecting what it does. This combined wth rigorous test-first codine and fast iterations (one week!) forms a part of the XP process. This delivers a series of high quality solutions to the user or client. It encorportaes clever rituals (the planning game, pair programming, etc) that make sure the client gets the function that they need next quickly -- without quality suffering.

        XP is claimed to work on small scale projects with an on site client. There is little data on large amorphous projects being done this way.

      4.7 Conclusions (2)- Under Used Processes

        Some processes in section 4.3 are effective but not well known:
        1. Dynamic Analysis and Design(DAD) [Botting86]: 11. Analyze Dynamics, 19. Detail Dynamics

        2. Data Directed Design(DDD) [Botting87b]: 18. Derive data dictionary, 21. Derive program structure, 22. Extract & list operations, 23. Embed operations, 24. Resolve nondeterminism
        3. Performance Engineering(PE): 6. Plan system schedule, 15. Make and Maintain performance model , 16. Improve physical data [Botting88] 17. Document problems(& prepare to renegotiate), 28. Fit to schedule/compile, . . . .

    . . . . . . . . . ( end of section 4) <<Contents | Index>>

    Next Section

    [ 01_5.html ] and contents list [ ]

Formulae and Definitions in Alphabetical Order