[CSUSB]
>> [CNS]
>> [Comp Sci Dept]
>> [R J Botting]
>> [Monograph]
>>
01_4
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:
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).
.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:
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:
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 ]
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.
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:
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].
Conclusions
The current system(S) implements certain Purposes(P) that refer to certain Realities(R) under Quality(R) and
Technological(T) constraints:
| Modular Programming | T | Stepwise Refinement(SWR) | TP |
|---|---|---|---|
| Functional programming(FP) | P;TP | Functional decomposition | P;Q;T |
| Information Hiding | PT | Systems Analysis | ST |
| Structured Design(1) | PT | Structured Design(2) | PRT |
| ADTs | PR;T | Objects | T |
| OOA | R | OOD | RQ;P;T |
| Syntax Directed Programming | R;T | Data Directed Design | R;T |
| Data Engineering | R;Q;T;P | Expert Systems | R;T;P |
| Dynamic Analysis and Design | R;P | Formal Modelling | RP |
| QFD | PQ;TPQ | Requirements Engineering | SPQ;R;P'Q' |
| SSADM | S;PR;QT |
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).
| Number | Short Description | Notes/Sources | Inputs | Outputs |
|---|---|---|---|---|
| 1. | Operate and Monitor system | f, IEEE | System | Client, Managers |
| 2. | Analyze problem domain/concepts | DE, Abbot, Booch, FM | Clients | PQRS |
| 3. | Document System that has problem | e, Checkland, SA | System | PQRST |
| 4. | Manage project | g, Boehm, Gilb | Management | QT |
| 5. | Negotiate changes | Gane&Sarson,JAD, QFD | PQRST+Client | Q'S'+Client |
| 6. | Plan system schedule | SSADM, PE | PQS'T | S'Q' |
| 7. | Build mockup | Botting 85, RAD | PQ'RS' | Mockup |
| 8. | Improve mockup | Mumford, JAD | Mockup + Client | Mockup |
| 9. | Normalize data | DE | Mockup, PS' | R' |
| 10. | Decompose processing | e, SD, SWR/FD | Mockup, S' | P'R' |
| 11. | Analyze dynamics | DAD | RS'R' | R' |
| 12. | Specify objects | OO, SSADM | P'R' | Spec.b |
| 13. | Specify purposes | e, SD, FM, SWR/FD,QFD | P'S'R' | Spec. |
| 14. | Specify physical data+algorithms | SSADM, DE, CSci | Spec+'T | Data |
| 15. | Maintain performance model | SSADM, DE | Spec+Data | Model |
| 16. | Improve physical data+algorithms | SSADM, DE, PE, CSci | Q'+Model+Data | Data |
| 17. | Document performance problems | SSADM, PE | Q'+Model+Data | Q'+Client |
| 18. | Derive dictionaries & grammars | e, JSP | Spec.+Data | Dict.c |
| 19. | Detail Dynamics | e, DAD | Spec. | Dict. |
| 20. | Refine Purposes | e, JSP, SWR/FD | Spec.+Dict. | Spec.+Dict. |
| 21. | Derive program/object structure | e, JSP, LCP | Dict.+Spec. | Blueprint |
| 22. | Extract & list operations | JSP | Spec. | Blueprint |
| 23. | Embed operations | JSP | Blueprint | Blueprint |
| 24. | Resolve nondeterminism | e, JSP | Blueprint+Spec | Blueprint |
| 25. | Create breadboard | Botting 85 | Blueprint+Mockup | Breadboard |
| 26. | Test breadboard | e,"debugging" | Breadboard+P'Q'R'S'T | Breadboard' |
| 27. | Tune breadboard | e, PE | Breadboard+Q'T | Breadboard' |
| 28. | Fit to schedule/compile, . . . | JSP | Breadboard+Data | Code |
| 29. | Fit into system | "coding" | Blueprint, Code | System |
| Note | Meaning |
|---|---|
| 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. |
| e | Some explicitly excludes these processes. |
| f. | Can include user written programs. |
| g. | Management includes planning, resourcing, setting goals, monitoring,... |
| Abbreviation | References | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CSci | Computer Science - clicheŽ+algorithm, data structures and algorithms, heuristics, ... | ||||||||||||||||||
| DE | Data Engineering - ERD, Normalization, Conceptual models ...(see [ DATA in subjects ] and [ ERD in subjects ] in Chapter 9) | ||||||||||||||||||
| FM | Formal Methods - eg Hoare, Woodford, Ince, Spivey, Zave, ...(see [ FORMAL in subjects ] in Chapter 9) | ||||||||||||||||||
| DAD | Dynamic Analysis and Design - SSADM, JSD, Harel, MERODE,Shlaer & Mellor ... ( [ DAD in subjects ] in Chapter 9) | ||||||||||||||||||
| JAD | Joint Applications Development and Participative Development - Wood & Silver ,...( [ USER in subjects ] ) | ||||||||||||||||||
| JSP/JSD | See Michael A Jackson and John Cameron (
[ JSP in subjects ]
,
[ JSD in subjects ]
| LCP | Warnier/Orr, also DSSD (
[ LCP in subjects ]
and
[ LCS in subjects ]
)
| OO | Object Oriented - Abbot, Berard, Booch, Coad, ... , OMT, SBM, Fusion(see
[ OBJECT-ORIENTED in subjects ]
)
| PE | Performance Engineering - Botting 88, (SPE) Smith CU 90, ... (see
[ OPTIMIZATION in subjects ]
)
| QFD | Quality Function Deployment Haag et al 95, Wyder 96...(See
[ QFD in subjects ]
)
| RAD | Rapid Application Development (See Martin 91,
[ PROTOTYPES in subjects ]
)
| SA | Structured Analysis - Gane and Sarson, Weinberg V,... Davis A 90(
[ SAD in subjects ]
, also parts of
[ SSADM in subjects ]
)
| SD | Structured Design - Yourdon, De Marco, Constantine, Mastro... Davis A 90 (
[ SAD in subjects ]
)
| SWR/FD | Stepwise Refinement, Functional Decomposition,... - any college programming text(
[ SEQUENTIAL in subjects ]
)
| SSADM | Structured Systems Analysis and Design Method --UK Civil Service(NCC), Hall 81, Cutts 88(
[ SSADM in subjects ]
)
| |
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.
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.
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.
. . . . . . . . . ( end of section 4) <<Contents | Index>>
Next Section
[ 01_5.html ]
and contents list
[ http://www.csci.csusb.edu/dick/monograph/ ]