software engineering body of knowledge - · pdf fileguide to the software engineering body of...

SWEBOK

So

ftw

are

En

gin

eeri

ng

So

ftw

are

En

gin

eeri

ng

Bo

dy

of

Kn

owle

dg

eB

od

y o

f K

now

led

ge

Tu

tori

al p

rep

ared

fo

rT

uto

rial

pre

par

ed f

or

SIG

Ad

aS

IGA

da

2000

Co

nfe

ren

ce:

2000

Co

nfe

ren

ce:

Ad

aA

da

Tec

hn

olo

gy U

pd

ate

Tec

hn

olo

gy U

pd

ate

1212-- 1

6 N

ove

mbe

r 20

0016

No

vem

ber

2000

Pre

sen

ted

by

Pre

sen

ted

by

Jam

es W

. Mo

ore

, Th

e M

ITR

E C

orp

ora

tio

nJa

mes

W. M

oo

re, T

he

MIT

RE

Co

rpo

rati

on

Ter

ry B

.T

erry

B. B

olli

nge

rB

olli

nge

r , T

he M

ITR

E C

orp

ora

tio

n, T

he M

ITR

E C

orp

ora

tio

n

www.swebok.org 2SIGAda 2000

Project managed by:

Corporate Support by:


Presentation ObjectivesPresentation Objectives

� SWEBOK Project Status: Moore

� SWEBOK Overview: Moore

� Software Construction Knowledge Area: Bollinger

SWEBOK

SW

EB

OK

Pro

ject

Sta

tus

SW

EB

OK

Pro

ject

Sta

tus


Guide to the Software Guide to the Software Engineering Body of KnowledgeEngineering 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 -- http://www.swebok.org


Recognized Profession?Recognized Profession?

� P. Starr, The Social Transformation of American Medicine, BasicBooks, 1982:

vKnowledge and competence validated by the community of peers

vConsensually validated knowledge rests on rational, scientific grounds

v Judgment and advice oriented toward a set of substantive values


Model of the Maturity Model of the Maturity of a Professionof a Profession

� Ford and Gibbs:

vEducation

vAccreditation

vSkills development

v Licensing/certification

vProfessional development

vCode of ethics

vProfessional society or societies

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 1996.


Initial Professional Development

Initial professional education

Skills Development

One or both

Full Professional

Status

Certification Licensing

Infrastructure Support for the

Profession

Accreditation

Professional development

Code of ethics

Professional societies

Professional Society Influence

Adapted from Steve McConnell, After the Gold Rush, Microsoft Press, 1999, p. 93

Professional DevelopmentProfessional Development


Initial Professional Development

Initial professional education

Skills Development

One or both

Full Professional

Status

Certification Licensing

Infrastructure Support for the

Profession

Accreditation

Professional development

Code of ethics

Professional societies

Professional Society Influences

Adapted from Steve McConnell, After the Gold Rush, Microsoft Press, 1999, p. 93

Professional DevelopmentProfessional Development


Development ofSoftware

EngineeringCurricula

Development ofCertification /

Licensing Criteria andExams

Development ofUniversity Program

Accreditation Criteria

Consensus ona Core Body of

Knowledge

Influ

ence

s Influences

Influences

Key Interrelationships for a Key Interrelationships for a Core Body of KnowledgeCore Body of Knowledge


Window of Opportunity?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)


Project ObjectivesProject 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


Intended AudienceIntended Audience

� Public and private organizations

� Practicing software engineers

� Makers of public policy

� Professional societies

� Software engineering students

� Educators and trainers


What is Software Engineering?What is Software Engineering?

� IEEE 610.12:

(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).


GenerallyAccepted

Advanced

Sp

ecia

lized

andResearch

Focus of the SWEBOK Guide

Categories of Knowledge Categories of Knowledge in the SWEBOKin the SWEBOK


Maths

Applicationdomain

knowledge

AdvancedSE

Knowledge

SWEBOK

C.S.

...

Knowledge of aSoftware Engineer

SpecializedSE

Knowledge

Software Software Engineer’s Engineer’s KnowledgeKnowledge


Two Underlying Principles of Two Underlying Principles of the Projectthe 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


Project TeamProject Team

� Editorial team

� Industrial Advisory Board

� Knowledge Area Specialists

� Reviewers


Editorial TeamEditorial Team

Alain AbranUniversité du Québec à MontréalComputer Science Dept.C.P. 8888, Succ. Centre-VilleMontréal, QuébecH3C 3P8 CanadaTel.: (514) 987-3000 ext. 8900Fax: (514) [email protected]

Pierre BourqueUniversité du Québec à MontréalComputer Science Dept.C.P. 8888, Succ. Centre-VilleMontréal, QuébecH3C 3P8 CanadaTel.: (514) 987-3000 ext. 0315Fax: (514) [email protected]

James W. MooreThe MITRE Corporation

1820 Dolley Madison Blvd.McLean, Virginia 22102-3481

USATel: 703 883-7396

Fax: 703 [email protected]

Robert DupuisUniversité du Québec à Montréal

Computer Science Dept.C.P. 8888, Succ. Centre-Ville

Montréal, QuébecH3C 3P8 Canada

Tel.: (514) 987-3000 ext. 3479Fax: (514) 987-8477

[email protected]

Executive Editors

Guide Editors


Industrial Advisory BoardIndustrial 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 Standards and Technology

� Dolores Wallace, National Institute of Standards and Technology

www.swebok.org 21SIGAda 20001998 1999 2000 2001 2002 2003

Straw ManVersion

Stone Man Version

Iron Man Version(Sub-phase 1)

Iron Man Version(Sub-phase 2)

A ThreeA Three--Phase Approach for Phase Approach for Developing the GuideDeveloping the Guide

Experimentation and Trial Usage

Rewriting


Stone Man Review ProcessStone Man Review Process

� Transparency and consensus-building

vAll intermediate versions of documents are published and archived on www.swebok.org

vAll comments are made public as well as the identity of the reviewers

vDetailed comment disposition reports are produced

vRoughly 5000 comments from 200 reviewers in 25 countries


Stone Man DeliverablesStone 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


• Computer Science (CC2001)

• Mathematics (CC2001)

• Project Management (PMBOK)

• Computer Engineering

• Cognitive Sciences andHuman Factors

• Systems Engineering

• Management and Management Science

• Computer Science (CC2001)

• Mathematics (CC2001)

• Project Management (PMBOK)

• Computer Engineering

• Cognitive Sciences andHuman Factors

• Systems Engineering

• Management and Management Science

Related Disciplines

Baseline List Baseline List ofofKnowledge AreasKnowledge Areas

� Requirements

� Design

� Construction

� Testing

� Maintenance

� Configuration Management

� Quality

� Engineering Tools & Methods

� Engineering Process

� Engineering Management


Classification of Topics

Matrix of Topics & References References

Topic Descriptions

Classification by Vincenti’s

Taxonomy

Classification by Bloom’s Taxonomy

References to Related

DisciplinesNot implemented in Stoneman

Knowledge Area DescriptionKnowledge Area Description


Knowledge Area SpecialistsKnowledge 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

SWEBOK

Ove

rvie

w o

f th

e S

WE

BO

KO

verv

iew

of

the

SW

EB

OK


SoftwareRequirements v 0.7

Software Testingv 0.7

RequirementsEngineering

Process

RequirementsElicitation

RequirementsAnalysis

RequirementsValidation

RequirementsManagement

Basic Conceptsand Definitions

Test Levels

Test Techniques

Test RelatedMeasures

Management theTest Process

SoftwareRequirementsspecifications

SoftwareConstruction v 0.7

Software Designv 0.7

LinguisticConstruction

Methods

FormalConstruction

Methods

Visual ConstructionMethods

Software DesignBasic Concepts

SoftwareArchitecture

Software DesignQuality Analysisand Evaluation

Software DesignNotations

Software DesignStrategies and

Methods

Reduction in Complexity

Anticipation of Diversity

Structuring for Validation

Use of ExternalStandards









SoftwareMaintenance v 0.7

MaintenanceActivities

MaintenanceProcess

OrganizationAspect of

Maintenance

Problems ofSoftware

Maintenance

Maintenance Costand MaintenanceCost Estimation

MaintenanceMeasurements

Techniques forMaintenance

Guide to the Software Engineering Body of Knowledge


Guide to the Software Engineering Body of Knowledge

ProcessMeasurement

Automation

SoftwareEngineering

Management v 0.7

SoftwareEngineering

Process v 0.6

MeasurementBasic Conceptsand Definitions

Process Definition

ProcessImplementation

and Change

Themes

Life Cycle Models

Process DefinitionMethods

Types of ProcessDefinitions

Life Cycle ProcessModels

Notations for ProcessDefinitions

Methodology in ProcessMeasurement

Process MeasurementParadigms

Paradigms for ProcessImplementation and

ChangeGuidelines for Process

Implementation andChange

Evaluating ProcessImplementation and

Change

OrganizationalManagement and

Coordination

Initiation andScope Definition

Planning

Enactment

Review andEvaluation

Project Close Out

Post-ClosureActivities

Processinfrastructure

Terminology

Qualitative ProcessAnalysis

Software Qualityv 0.6

Software QualityConcepts

Defining SQA andV&V

Planning for SQAand V&V

Activities andTechniques forSQA and V&V

MeasurementApplied to SQA

and V&V

SoftwareConfiguration

Management v 0.7*

Management ofthe SCM Process

SoftwareConfigurationIdentification


Control


Status Accounting


Auditing

Software ReleaseManagement and

Delivery

Software Design Tools

SoftwareEngineering Toolsand Methods v 0.7

SoftwareDevelopment

Methods

Software Tools

Heuristic Methods

Formal Methods

Prototyping Methods

Software RequirementsTools

Software Testing Tools

Software MaintenanceTools

Software EngineeringProcess Tools

Software ConstructionTools

Miscellaneous

Software Quality AnalysisTools

Software ConfigurationManagement Tools

Software EngineeringManagement Tools

Infrastructure SupportTools

Miscellaneous


RequirementsRequirements

� Requirements engineering process

v Connection to life cycle

v Contractual issues and project organization

� Requirements elicitation

v Stakeholder identification

v Relationships established between the development team and the customer

� Requirements analysis

v Detect and to resolve conflicts

v Discover the boundaries of the system and how it must interact with its environment

v Elaborate user and system requirements to software requirements

� Requirements validation

v Check for omissions, conflicts and ambiguities

v 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.


DesignDesign

� Design transforms requirements, stated in the problem domain, toproduce 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 architecturev Structures and viewpoints, architectural descriptions, patterns and

object-oriented frameworksv Architectural styles

� Design notations

� Design strategies and methods: general strategies, data-structure-centered design, function-oriented design and object-oriented design.


ConstructionConstruction

� More to Come!


TestingTesting

� 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


MaintenanceMaintenance

� 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


Configuration ManagementConfiguration 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 Management of the CM process

v Configuration identification

v Configuration control

v Configuration status accounting

v Configuration auditing

v Software release management and delivery


QualityQuality

� 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.


Engineering Tools & MethodsEngineering Tools & Methods

� Development methodsv Impose structure to make activity systematicv Provide notation, vocabulary, procedures, and guidelines for

checking v Approaches: informal, mathematically-based, prototype-based

� Software toolsv Intended to assist the software engineering processv Often designed to support particular methods, v Development and maintenance, supporting activities and

management toolsv Integrated tool setsv Tool assessment


Engineering ProcessEngineering 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


Engineering ManagementEngineering Management

� Process and measurement are inseparable. v Management without measurement suggests a lack of rigorv Measurement without management suggests a lack of purpose or context.

� Measurementv Measurement program goalsv Measurement selectionv Data collection and model developmentv Implementation.

� Management processv “In the large” v Development and implementation of standardsv Project staffingv Team developmentv Life cycle activities

SWEBOK

So

ftw

are

Co

nst

ruct

ion

So

ftw

are

Co

nst

ruct

ion

in t

he

SW

EB

OK

in t

he

SW

EB

OK


Software ConstructionSoftware Construction(SWC) at a Glance(SWC) at a Glance

� 16 pages in Stoneman version (0.7)

� 17 references, 5 standards

� Three authors:

vTerry Bollinger (MITRE)

vPhilippe Gabrini (UQÀM)

v Louis Martin (UQÀM)


TerryTerry BollingerBollinger

� 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


PhilippePhilippe GabriniGabrini

� 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


Louis MartinLouis 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


DefinitionDefinition

DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum

ManualAutomated

StylesLinguisticFormalVisual

PrinciplesReductionAnticipationValidationStandards

TaxonomyReferences

� 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


Versus DesignVersus Design


ManualAutomated



TaxonomyReferences

� 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


Use of ToolsUse of Tools


ManualAutomated



TaxonomyReferences

� Software construction tools are:v Software-basedv Construction-orientedv Examples:

½ compilers½ version control systems½ design tools½ documentation tools

� Good tools bridge the gap betweenv Fast & efficient (but dumb!) computers andv Creative (but sloppy & forgetful!) humans


SelfSelf--EvaluationEvaluation


ManualAutomated



TaxonomyReferences

� 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


StandardsStandards


ManualAutomated



TaxonomyReferences

� Standards create “shared languages” of powerful & low-cost baseline capabilitiesv De facto standards (e.g., Windows)v Explicit standards (e.g., XML)

� Standards affect construction powerfully:v Bad choices fritter away time & resourcesv Good standards choices:

½ simplify construction½ increase marketability½ reduce maintenance costs

� The best standards enable innovation


SWC SpectrumSWC Spectrum


ManualAutomated



TaxonomyReferences

� Manual construction: People control the overall process. Requires skills of:v insightful problem break-downv disciplined self-review and validationv anticipation of future changes

� Automated construction: A tool or environment controls key aspects of the overall construction processv overall process complexity is reducedv allows broader participation in processv less flexible (“domain specific”)


ManualManual


ManualAutomated



TaxonomyReferences

� 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, andoften doable only by highly skilled people

� More likely to be defined by a standard


AutomatedAutomated


ManualAutomated



TaxonomyReferences

� Often non-procedural(e.g., descriptive)

� Limited number ofconstruction options

� Emphasis on reusingexisting problem solutions

� Process is defined mostly by tools used

� Low-cost, safe, usable by many people

� Often custom to application area


StylesStyles


ManualAutomated



TaxonomyReferences

� 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 Linguisticv Formalv Visual


LinguisticLinguistic


ManualAutomated



TaxonomyReferences

� Linguistic construction uses computer languages whose form resembles natural languages such as French or Englishv Usually conveyed as text (characters)v Can also be conveyed via audio or tactile

� Pros:v Nearly universal as a way

to communicate to peoplev Efficient representations

� Consv Imprecise syntax (from computer’s view)


FormalFormal


ManualAutomated



TaxonomyReferences

� Formal construction uses theprecision and rigor of a formal (mathematical or logical) style

� Prosv Great for conveying exact intent accuratelyv Encourages completeness of thoughtsv Can provide powerful generalizations

� Consv Not readily accessible to all people!v Can encourage overly narrow viewpoints


VisualVisual


ManualAutomated



TaxonomyReferences

� Visual construction relieson powerful spatial abilitiesfound in nearly all peoplev Primarily visual (eyes)v Tactile can be a stand-in

� Prosv Highly parallel, remarkable “bandwidth”v Powerful for structuring complex datav Easy for people to understand and use

� Consv Harder for computers to “understand”


PrinciplesPrinciples


ManualAutomated



TaxonomyReferences

� Principles of organizationare broad strategies thatpeople use to apply their(finite) time and abilities tothe resolution of complexproblems. The four main strategies are:

v Reduction of complexity

v Anticipation of diversity

v Structuring for Validation

v Use of External Standards


ReductionReduction


ManualAutomated



TaxonomyReferences

� Reduction of complexitydeals with constraining thescale of a problem to limitsthat can be handled safely

� Three main strategies exist for reducing complexity:

v Removal of Complexity

v Automation of Complexity

v Localization of Complexity


Reduction by RemovalReduction by Removal


ManualAutomated



TaxonomyReferences

� Reduction by removallowers total complexityby eliminating needless“noise” in the featuresor structure of software.

� Examples:

v Axing unnecessary feature requirements

v Simplifying complex call structures

v Factoring out repeated operations or data


Reduction by AutomationReduction by Automation


ManualAutomated



TaxonomyReferences

� Reduction by Automation “eliminates” complexity by solving it once and automating the solution

� Examples:

v Compilers

v Operating systems

v Visual programming languages


Reduction by LocalizationReduction by Localization


ManualAutomated



TaxonomyReferences

� Localization of complexityfactors out complexity andkeeps 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


AnticipationAnticipation


ManualAutomated



TaxonomyReferences

� Anticipation of diversity deals with the problem of changes over time.

� Change always happens.

� Failure to anticipate changeis 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


Anticipation by GeneralizationAnticipation by Generalization


ManualAutomated



TaxonomyReferences

� Anticipation by generalization uses isolated cases to help find a broader, more powerful solutionsthat bridge across them

� Generalization is a distinctlymathematical concept, and is often expressed in mathematical terms

� Good design in general also requires generalization (e.g., for portability)


Anticipation by ExperimentAnticipation by Experiment


ManualAutomated



TaxonomyReferences

� Anticipation by experiment recognizes that even the best developers cannot anticipate all the implicationsof a complex system

� Various forms ofexperimentation are usedto identify unexpected behaviors

� Testing (all forms) is experimentation

� Prototyping is also experimentation


Anticipation by LocalizationAnticipation by Localization


ManualAutomated



TaxonomyReferences

� 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


ValidationValidation


ManualAutomated



TaxonomyReferences

� 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


StandardsStandards


ManualAutomated



TaxonomyReferences

� 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


TaxonomyTaxonomy


ManualAutomated



TaxonomyReferences

� (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


ReferencesReferences


ManualAutomated



TaxonomyReferences

1. [BEN00] Bentley, Jon, Programming Pearls (Second Edition). Addison-Wesley, 2000. (Chapters 2,3,4,11,13,14)

2. [BOO94] Booch, Grady, and Bryan, Doug, Software Engineering with Ada (Third edition). Benjamin/Cummings, 1994. (Parts II, IV, V)

3. [HOR99] Horrocks, Ian, Constructing the User Interface with Statecharts. Addison-Wesley, 1999. (Parts II, IV)




ManualAutomated



TaxonomyReferences

4. [KER99] Kernighan, Brian W., and Pike, Rob, The Practice of Programming. Addison-Wesley, 1999. (Ch. 1,2,3,5,6,9)

5. [MAG93] Maguire, Steve, Writing Solid Code. Microsoft Press, 1993.

6. [McCO93] McConnell, Steve, Code Complete. Microsoft Press, 1993.

7. [MEY97] Meyer, Bertrand, Object-Oriented Software Construction (Second Edition). Prentice-Hall,1997.(Ch. 6,10,11)




ManualAutomated



TaxonomyReferences

8. [SET96] Sethi, Ravi, Programming Languages – Concepts & Constructs (Second Edition). Addison-Wesley, 1996. (Parts II, III, IV, V)

9. [WAR99] Warren, Nigel, and Bishop, Philip, Java in Practice – Design Styles and Idioms for Effective Java. Addison-Wesley, 1999. (Chapters 1, 2, 3, 4, 5, 10)




ManualAutomated



TaxonomyReferences

Further Readings10. [BAR98] Barker, Thomas T., Writing

Software Documentation – A Task-Oriented Approach. Allyn & Bacon, 1998.

11. [FOW99] Fowler, Martin, Refactoring –Improving the Design of Existing Code. Addison-Wesley, 1999.

12. [GLA95] Glass, Robert L., Software Creativity. Prentice-Hall, 1995.




ManualAutomated



TaxonomyReferences

13. [HEN97] Henricson, Mats, and Nyquist, Erik, Industrial Strength C++. Prentice-Hall, 1997.

14. [HOR99] Horrocks, Ian, Constructing the User Interface with Statecharts. Addison-Wesley, 1999.

15. [HUM97] Humphrey, Watts S., Introduction to the Personal Software Process. Addison-Wesley, 1997.




ManualAutomated



TaxonomyReferences

16. [HUN00] Hunt, Andrew, and Thomas, David, The Pragmatic Programmer. Addison-Wesley, 2000.

17. [MAZ96] Mazza, C., et al., Software Engineering Guides. Prentice-Hall, 1996. (Part IV)




ManualAutomated



TaxonomyReferences

Standards Relevant to SWC

a. IEEE Std 829-1983 (Reaff 1991), IEEE Standard for Software Test Documentation (ANSI)

b. IEEE Std 1008-1987 (Reaff 1993), IEEE Standard for Software Unit Testing (ANSI)

c. IEEE Std 1028-1988 (Reaff 1993), IEEE Standard for Software Reviews and Audits (ANSI)




ManualAutomated



TaxonomyReferences

d. IEEE Std 1063-1987 (Reaff 1993), IEEE Standard for Software User Documentation (ANSI)

e. IEEE Std 1219-1992, IEEE Standard for Software Maintenance (ANSI)

SWEBOK

ww

w.

ww

w. s

web

ok

sweb

ok .

org

.org

software engineering body of knowledge - · pdf fileguide to the software engineering body of...

Documents