Software Engineering Body of Knowledge

Transcription

1 Software Engineering Body of Knowledge Tutorial prepared for Conference: Ada Technology Update November 2000 Presented by James W. Moore, The MITRE Corporation Terry B. Bollinger,, The MITRE Corporation SWEBOK

2 Project managed by: Corporate Support by: 2

3 Presentation Objectives SWEBOK Project Status: Moore SWEBOK Overview: Moore Software Construction Knowledge Area: Bollinger 3

4 SWEBOK Project Status SWEBOK

5 Guide to the Software Engineering Body of Knowledge Initiated as a collaboration between IEEE CS, ACM and UQAM. International participation from industry, professional societies, standards bodies, academia, authors By the time the project is finished literally thousands of individuals will have touched it About to complete the middle of three phases Web site

6 Recognized Profession? P. Starr, The Social Transformation of American Medicine, BasicBooks, 1982: v Knowledge and competence validated by the community of peers v Consensually validated knowledge rests on rational, scientific grounds v Judgment and advice oriented toward a set of substantive values 6

7 Model of the Maturity of a Profession Ford and Gibbs: v Education v Accreditation v Skills development v Licensing/certification v Professional development G. Ford and N. E. Gibbs, A Mature Profession of Software Engineering, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical CMU/SEI-96- TR-004, January v Code of ethics v Professional society or societies 7

8 Professional Development Initial Professional Development Initial professional education Infrastructure Support for the Profession Accreditation Professional Society Influence Skills Development Certification One or both Full Professional Status Licensing Professional development Code of ethics Professional societies Adapted from Steve McConnell, After the Gold Rush, Microsoft Press, 1999, p

9 Professional Development Initial Professional Development Initial professional education Infrastructure Support for the Profession Accreditation Professional Society Influences Skills Development Certification One or both Full Professional Status Licensing Professional development Code of ethics Professional societies Adapted from Steve McConnell, After the Gold Rush, Microsoft Press, 1999, p

10 Key Interrelationships for a Core Body of Knowledge Development of Software Engineering Curricula Influences Consensus on a Core Body of Knowledge Influences Development of Certification / Licensing Criteria and Exams Influences Development of University Program Accreditation Criteria 10

11 Window of Opportunity? ACM / IEEE-CS Code of Ethics Texas Board of Professional Engineers Computer Science Curriculum 2001 Rochester Institute of Technology (and others) are offering undergraduate degrees in Software Engineering CSAB & ABET are cooperating on accreditation Possible software liability issues: Y2K, etc. Increased interest in the establishment of a profession (After the Gold Rush was #752 on Amazon.com) Continuing focus on organizational engineering capability (ISO 9000, CMM) 11

12 Project Objectives Promote a consistent view of software engineering worldwide Clarify the place of, and set the boundary of, software engineering with respect to other disciplines Characterize the contents of the Software Engineering Body of Knowledge Provide a topical access to the Software Engineering Body of Knowledge Provide a foundation for curriculum development and individual certification and licensing material 12

13 Intended Audience Public and private organizations Practicing software engineers Makers of public policy Professional societies Software engineering students Educators and trainers 13

14 What is Software Engineering? IEEE : (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). 14

15 Categories of Knowledge in the SWEBOK Specialized Generally Accepted Advanced and Research Focus of the SWEBOK Guide 15

16 Software Engineer s Knowledge Application domain knowledge Advanced SE Knowledge C.S. Specialized SE Knowledge SWEBOK Knowledge of a Software Engineer Maths

17 Two Underlying Principles of the Project Transparency: the development process is itself published and fully documented Consensus-building: the development process is designed to build, over time, consensus in industry, among professional societies and standards-setting bodies and in academia 17

18 Project Team Editorial team Industrial Advisory Board Knowledge Area Specialists Reviewers 18

19 Editorial Team Alain Abran Université du Québec à Montréal Computer Science Dept. C.P. 8888, Succ. Centre-Ville Montréal, Québec H3C 3P8 Canada Tel.: (514) ext Fax: (514) Pierre Bourque Université du Québec à Montréal Computer Science Dept. C.P. 8888, Succ. Centre-Ville Montréal, Québec H3C 3P8 Canada Tel.: (514) ext Fax: (514) Executive Editors Guide Editors James W. Moore The MITRE Corporation 1820 Dolley Madison Blvd. McLean, Virginia USA Tel: Fax: Robert Dupuis Université du Québec à Montréal Computer Science Dept. C.P. 8888, Succ. Centre-Ville Montréal, Québec H3C 3P8 Canada Tel.: (514) ext Fax: (514)

20 Industrial Advisory Board Mario R. Barbacci, SEI, representing the IEEE Computer Society Carl Chang, University of Illinois at Chicago, Editor Emeritus, IEEE Software, representing Computing Curricula 2001 François Coallier, speaking as ISO/IEC JTC 1 / SC7 Chairman Morven Gentleman, National Research Council of Canada Paula Hawthorn, representing the ACM Philippe Kruchten, Rational Software Corp. Laure Le Bars, SAP Labs (Canada) Dan Nash, Raytheon Systems Company Bryan Pflug, The Boeing Company Larry Reeker, National Institute of and Technology Dolores Wallace, National Institute of and Technology 20

21 A Three-Phase Approach for Developing the Guide Straw Man Version Stone Man Version Experimentation and Trial Usage Iron Man Version (Sub-phase 1) Iron Man Version (Sub-phase 2) Rewriting

22 Stone Man Review Process Transparency and consensus-building v All intermediate versions of documents are published and archived on v All comments are made public as well as the identity of the reviewers v Detailed comment disposition reports are produced v Roughly 5000 comments from 200 reviewers in 25 countries 22

23 Stone Man Deliverables Consensus on a list of Knowledge Areas Consensus on a list of topics and relevant reference materials for each Knowledge Area Consensus on a list of Related Disciplines Available free on the web 23

24 Baseline List of Knowledge Areas Requirements Design Construction Testing Maintenance Configuration Management Quality Engineering Tools & Methods Engineering Process Engineering Management Related Disciplines Computer Science (CC2001) Mathematics (CC2001) Project Management (PMBOK) Computer Engineering Cognitive Sciences and and Human Factors Systems Engineering Management and and Management Science 24

25 Knowledge Area Description Classification of Topics Matrix of Topics & References References Topic Descriptions Classification by Vincenti s Taxonomy Classification by Bloom s Taxonomy Not implemented in Stoneman References to Related Disciplines 25

26 Knowledge Area Specialists Requirements: Pete Sawyer and Gerald Kotonya, UK Design: Guy Tremblay, Canada Construction: Terry Bollinger, USA; Philippe Gabrini, Louis Martin, Canada Testing: Antonia Bertolino, Italy Maintenance: Tom Pigoski, USA Configuration Management: John Scott and David Nisse, USA Quality: Dolores Wallace and Larry Reeker, USA Tools and Methods: Dave Carrington, Australia Process: Khaled El Emam, Canada Management: Stephen MacDonald and Andrew Gray, New-Zealand 26

27 Overview of the SWEBOK SWEBOK

28 Guide to the Software Engineering Body of Knowledge Software Requirements v 0.7 Software Design v 0.7 Software Construction v 0.7 Software Testing v 0.7 Software Maintenance v 0.7 Requirements Engineering Process Software Design Basic Concepts Linguistic Construction Methods Basic Concepts and Definitions Maintenance Activities Requirements Elicitation Requirements Analysis Software Requirements specifications Software Architecture Software Design Quality Analysis and Evaluation Software Design Notations Reduction in Complexity Anticipation of Diversity Structuring for Validation Use of External Formal Construction Methods Reduction in Complexity Anticipation of Diversity Test Levels Test Techniques Test Related Measures Maintenance Process Organization Aspect of Maintenance Problems of Software Maintenance Maintenance Cost and Maintenance Cost Estimation Requirements Validation Requirements Management Software Design Strategies and Methods Structuring for Validation Use of External Visual Construction Methods Management the Test Process Maintenance Measurements Techniques for Maintenance Reduction in Complexity Anticipation of Diversity Structuring for Validation Use of External 28

29 Guide to the Software Engineering Body of Knowledge Software Engineering Management v 0.7 Software Engineering Process v 0.6 Software Quality v 0.6 Software Configuration Management v 0.7* Software Engineering Tools and Methods v 0.7 Measurement Organizational Management and Coordination Initiation and Scope Definition Planning Enactment Review and Evaluation Project Close Out Post-Closure Activities Basic Concepts and Definitions Themes Terminology Process infrastructure Process Measurement Methodology in Process Measurement Process Measurement Paradigms Process Definition Types of Process Definitions Life Cycle Models Life Cycle Process Models Notations for Process Definitions Process Definition Methods Automation Qualitative Process Analysis Process Implementation and Change Paradigms for Process Implementation and Change Guidelines for Process Implementation and Change Evaluating Process Implementation and Change Software Quality Concepts Defining SQA and V&V Planning for SQA and V&V Activities and Techniques for SQA and V&V Measurement Applied to SQA and V&V Management of the SCM Process Software Configuration Identification Software Configuration Control Software Configuration Status Accounting Software Configuration Auditing Software Release Management and Delivery Software Tools Software Requirements Tools Software Design Tools Software Construction Tools Software Testing Tools Software Maintenance Tools Software Engineering Process Tools Software Quality Analysis Tools Software Configuration Management Tools Software Engineering Management Tools Infrastructure Support Tools Miscellaneous Software Development Methods Heuristic Methods Formal Methods Prototyping Methods Miscellaneous 29

30 Requirements Requirements engineering process v v Connection to life cycle Contractual issues and project organization Requirements elicitation v v Stakeholder identification Relationships established between the development team and the customer Requirements analysis v v v Detect and to resolve conflicts Discover the boundaries of the system and how it must interact with its environment Elaborate user and system requirements to software requirements Requirements validation v v Check for omissions, conflicts and ambiguities Ensure that requirements follow prescribed quality standards Requirements management: change management and maintaining requirements in a state that accurately mirrors the software to be, or that has been, built. 30

31 Design Design transforms requirements, stated in the problem domain, to produce a description of a solution--system components and interfaces--refined to a level of detail suitable for construction. Design quality and metrics: quality attributes, quality assurance, metrics. Software architecture v v Structures and viewpoints, architectural descriptions, patterns and object-oriented frameworks Architectural styles Design notations Design strategies and methods: general strategies, data-structurecentered design, function-oriented design and object-oriented design. 31

32 Construction More to Come! 32

33 Testing Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite domain of executions, against the specified expected behavior. Test levels: Test phases for large systems Testing for specific properties Test techniques and corresponding measures v Specification-based v Code-based v Fault-based v Usage-based v Specialized Organizing and controlling the test process Automating the test process 33

34 Maintenance Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. Maintenance activities and roles v Formal types of maintenance and common activities v Process is critical to the success. Standard maintenance processes Organizing for maintenance (may be different than for development) Software evolution Cost: life cycle costs as well as costs for individual evolution and maintenance tasks Maintenance measurements Tools and techniques 34

35 Configuration Management System: Collection of components organized to accomplish specified functions. CM is the discipline of identifying the configuration of systems at discrete times to control changes and maintain integrity and traceability. Concepts are universal, but implemented differently for HW and SW. Primary activities v v v v v v Management of the CM process Configuration identification Configuration control Configuration status accounting Configuration auditing Software release management and delivery 35

36 Quality Includes software product quality and processes for software quality assurance and software verification and validation activities Although different terminology is currently used, there is some consensus about the attributes that define software quality and dependability over a range of products. These definitions provide the base knowledge from which individual quality products are planned, built, analyzed, measured, and improved. The definitions are discussed in the defining quality products sub-area. Software quality assurance is a process designed to assure a quality product; it is a planned and systematic pattern of all actions necessary to provide adequate confidence that the product conforms to specified technical requirements. Software verification and validation is an process to provide an objective assessment of software products and processes throughout the software life cycle, that is, the verification an validation process provides management with visibility into the quality of the product. These two processes form the backbone of the software quality analysis: definition of quality analysis, process plans, activities and techniques for quality analysis, and measurement in software quality analysis. 36

37 Engineering Tools & Methods Development methods v Impose structure to make activity systematic v Provide notation, vocabulary, procedures, and guidelines for checking v Approaches: informal, mathematically-based, prototype-based Software tools v Intended to assist the software engineering process v Often designed to support particular methods, v Development and maintenance, supporting activities and management tools v Integrated tool sets v Tool assessment 37

38 Engineering Process Process definition: types of process definitions, life cycle models, life cycle process models, notations for process definitions, process definition methods, and automation Process evaluation: approaches for the qualitative and quantitative analysis of software processes, including measurement v Analytic: qualitative evaluation, root-cause analysis, process simulation, orthogonal defect classification, experimental and observational studies, and personal software process v Benchmarking: identifying an excellent organization in a field and documenting its practices and tools, including process assessment models and methods Process implementation and change: paradigms, infrastructure, and critical success factors for successful process implementation and change v Process implementation and change v Infrastructure v Guidelines for process implementation and evaluation 38

39 Engineering Management Process and measurement are inseparable. v Management without measurement suggests a lack of rigor v Measurement without management suggests a lack of purpose or context. Measurement v Measurement program goals v Measurement selection v Data collection and model development v Implementation. Management process v In the large v Development and implementation of standards v Project staffing v Team development v Life cycle activities 39

40 Software Construction in the SWEBOK SWEBOK

41 Software Construction (SWC) at a Glance 16 pages in Stoneman version (0.7) 17 references, 5 standards Three authors: v Terry Bollinger (MITRE) v Philippe Gabrini (UQÀM) v Louis Martin (UQÀM) 41

42 Terry Bollinger Works at The MITRE Corporation, a non-profit company that does U.S. government research and development work in advanced technologies Assistant Editor for IEEE Software Co-author of IEEE Software issue on Linux Author of influential articles on reuse and process IEEE Millennium Medal winner Extensive experience in the trenches in industry Likes to annoy Capability Maturity Model advocates 42

43 Philippe Gabrini Université du Quebec à Montréal (University of Quebec at Montreal) Directeur, Département d'informatique (Director, Information Processing Dept.) Long-time member of the Canadian Computer Science Accreditation Council Broad, long-term experience in software engineering accreditation issues 43

44 Louis Martin Université du Quebec à Montréal (University of Quebec at Montreal) Professor of Business Information Processing (colleague of Philippe) Extensive background in applied software construction topics Helped in particular with selection and development of reference materials 44

45 Definition Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Construction: The creation of usable software via a suite of skills that include: v coding v self-validation v self-testing Not just a mechanistic translation of good design into working software! Construction burrows deeply into some of the most difficult issues of SWE 45

46 Versus Design Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Design: Emphasis on dividing complex problems into smaller chunks Construction: Emphasis on finding final, executable solutions Design produces a framework, while Construction produces an working result v Both are exercises in problem solving v Both use similar methods 46

47 Use of Tools Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Software construction tools are: v Software-based v Construction-oriented v Examples: ½ compilers ½ version control systems ½ design tools ½ documentation tools Good tools bridge the gap between v Fast & efficient (but dumb!) computers and v Creative (but sloppy & forgetful!) humans 47

48 Self-Evaluation Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Integrated self-evaluation: Open loop coding is not software construction Construction uses explicit self-checks : v Continuous checks v Periodic checks v Checks of interim results v Checks of the process itself Examples: design reviews, module compilations, unit tests, self-reviews 48

49 Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References create shared languages of powerful & low-cost baseline capabilities v De facto standards (e.g., Windows) v Explicit standards (e.g., XML) affect construction powerfully: v Bad choices fritter away time & resources v Good standards choices: ½ simplify construction ½ increase marketability ½ reduce maintenance costs The best standards enable innovation 49

50 SWC Spectrum Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Manual construction: People control the overall process. Requires skills of: v insightful problem break-down v disciplined self-review and validation v anticipation of future changes Automated construction: A tool or environment controls key aspects of the overall construction process v overall process complexity is reduced v allows broader participation in process v less flexible ( domain specific ) 50

51 Manual Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Usually procedural (order-dependent) Very large number of descriptive options Emphasis on finding new problem solutions Process is defined by user (versus by tools) Expensive, risky, and often doable only by highly skilled people More likely to be defined by a standard 51

52 Automated Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Often non-procedural (e.g., descriptive) Limited number of construction options Emphasis on reusing existing problem solutions Process is defined mostly by tools used Low-cost, safe, usable by many people Often custom to application area 52

53 Styles Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Styles are ways of communicating that track closely to innate human capabilities Not all styles of communication are equally accessible to all people Styles also vary greatly in how easily they can be explained to computers Construction relies on three main styles: v Linguistic v Formal v Visual 53

54 Linguistic Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Linguistic construction uses computer languages whose form resembles natural languages such as French or English v Usually conveyed as text (characters) v Can also be conveyed via audio or tactile Pros: v Nearly universal as a way to communicate to people v Efficient representations Cons v Imprecise syntax (from computer s view) 54

55 Formal Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Formal construction uses the precision and rigor of a formal (mathematical or logical) style Pros v Great for conveying exact intent accurately v Encourages completeness of thoughts v Can provide powerful generalizations Cons v Not readily accessible to all people! v Can encourage overly narrow viewpoints 55

56 Visual Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Visual construction relies on powerful spatial abilities found in nearly all people v Primarily visual (eyes) v Tactile can be a stand-in Pros v Highly parallel, remarkable bandwidth v Powerful for structuring complex data v Easy for people to understand and use Cons v Harder for computers to understand 56

57 Principles Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Principles of organization are broad strategies that people use to apply their (finite) time and abilities to the resolution of complex problems. The four main strategies are: v Reduction of complexity v Anticipation of diversity v Structuring for Validation v Use of External 57

58 Reduction Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Reduction of complexity deals with constraining the scale of a problem to limits that can be handled safely Three main strategies exist for reducing complexity: v Removal of Complexity v Automation of Complexity v Localization of Complexity 58

59 Reduction by Removal Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Reduction by removal lowers total complexity by eliminating needless noise in the features or structure of software. Examples: v Axing unnecessary feature requirements v Simplifying complex call structures v Factoring out repeated operations or data 59

60 Reduction by Automation Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Reduction by Automation eliminates complexity by solving it once and automating the solution Examples: v Compilers v Operating systems v Visual programming languages 60

61 Reduction by Localization Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Localization of complexity factors out complexity and keeps it within well-defined, easy-to-maintain boundaries Localization is a powerful technique and one of the indicators of good design: v Modularity (all forms) v Object-oriented design v Coupling and cohesion criteria 61

62 Anticipation Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Anticipation of diversity deals with the problem of changes over time. Change always happens. Failure to anticipate change is a hallmark of bad design Anticipating future diversity: v Requires an ability to estimate the future v Is an implicit goal of many quality standards 62

63 Anticipation by Generalization Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Anticipation by generalization uses isolated cases to help find a broader, more powerful solutions that bridge across them Generalization is a distinctly mathematical concept, and is often expressed in mathematical terms Good design in general also requires generalization (e.g., for portability) 63

64 Anticipation by Experiment Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Anticipation by experiment recognizes that even the best developers cannot anticipate all the implications of a complex system Various forms of experimentation are used to identify unexpected behaviors Testing (all forms) is experimentation Prototyping is also experimentation 64

65 Anticipation by Localization Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Anticipation by localization is a special case of localization of complexity (since changeability is a type of complexity) Locality of change indicates how well software was constructed: v Poor change locality: Common changes result in the code being touched in many different locations v Good change locality: Common changes result in the code being touched only once 65

66 Validation Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Structuring for validation means building code in a way that specifically recognizes the need to assure its overall correctness. Structuring for validation amounts to instrumenting designs in anticipation of the need for testing and simulation 66

67 Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Use of external standards simplifies construction by relying on the proven concepts and capabilities implied by external standards Use of standards must balance between: v Advantages of accessing capabilities and technologies implied by those standards v Risk of failure of any specific standard Best strategy: Build in some hedging 67

68 Taxonomy Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References (3 Styles) X (4 Principles) = 12 Impact Areas Taxonomy classifies effects, since any one technique (e.g., modularity) can have multiple impacts Overall power of a technique can be judged by how many areas it affects Power of a language can be estimated by how many techniques it includes 68

69 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References 1. [BEN00] Bentley, Jon, Programming Pearls (Second Edition). Addison- Wesley, (Chapters 2,3,4,11,13,14) 2. [BOO94] Booch, Grady, and Bryan, Doug, Software Engineering with Ada (Third edition). Benjamin/Cummings, (Parts II, IV, V) 3. [HOR99] Horrocks, Ian, Constructing the User Interface with Statecharts. Addison- Wesley, (Parts II, IV) 69

70 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References 4. [KER99] Kernighan, Brian W., and Pike, Rob, The Practice of Programming. Addison-Wesley, (Ch. 1,2,3,5,6,9) 5. [MAG93] Maguire, Steve, Writing Solid Code. Microsoft Press, [McCO93] McConnell, Steve, Code Complete. Microsoft Press, [MEY97] Meyer, Bertrand, Object- Oriented Software Construction (Second Edition). Prentice-Hall,1997.(Ch. 6,10,11) 70

71 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References 8. [SET96] Sethi, Ravi, Programming Languages Concepts & Constructs (Second Edition). Addison-Wesley, (Parts II, III, IV, V) 9. [WAR99] Warren, Nigel, and Bishop, Philip, Java in Practice Design Styles and Idioms for Effective Java. Addison- Wesley, (Chapters 1, 2, 3, 4, 5, 10) 71

72 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Further Readings 10. [BAR98] Barker, Thomas T., Writing Software Documentation A Task- Oriented Approach. Allyn & Bacon, [FOW99] Fowler, Martin, Refactoring Improving the Design of Existing Code. Addison-Wesley, [GLA95] Glass, Robert L., Software Creativity. Prentice-Hall,

73 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References 13. [HEN97] Henricson, Mats, and Nyquist, Erik, Industrial Strength C++. Prentice- Hall, [HOR99] Horrocks, Ian, Constructing the User Interface with Statecharts. Addison- Wesley, [HUM97] Humphrey, Watts S., Introduction to the Personal Software Process. Addison-Wesley,

74 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References 16. [HUN00] Hunt, Andrew, and Thomas, David, The Pragmatic Programmer. Addison-Wesley, [MAZ96] Mazza, C., et al., Software Engineering Guides. Prentice-Hall, (Part IV) 74

75 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References Relevant to SWC a. IEEE Std (Reaff 1991), IEEE Standard for Software Test Documentation (ANSI) b. IEEE Std (Reaff 1993), IEEE Standard for Software Unit Testing (ANSI) c. IEEE Std (Reaff 1993), IEEE Standard for Software Reviews and Audits (ANSI) 75

76 References Definition Versus Design Use of Tools Self-Evaluation SWC Spectrum Manual Automated Styles Linguistic Formal Visual Principles Reduction Anticipation Validation Taxonomy References d. IEEE Std (Reaff 1993), IEEE Standard for Software User Documentation (ANSI) e. IEEE Std , IEEE Standard for Software Maintenance (ANSI) 76

77 swebok.org SWEBOK