software engineering body of knowledge - · pdf fileguide to the software engineering body of...
TRANSCRIPT
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:
www.swebok.org 3SIGAda 2000
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
www.swebok.org 5SIGAda 2000
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
www.swebok.org 6SIGAda 2000
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
www.swebok.org 7SIGAda 2000
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.
www.swebok.org 8SIGAda 2000
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
www.swebok.org 9SIGAda 2000
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
www.swebok.org 10SIGAda 2000
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
www.swebok.org 11SIGAda 2000
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)
www.swebok.org 12SIGAda 2000
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
www.swebok.org 13SIGAda 2000
Intended AudienceIntended Audience
� Public and private organizations
� Practicing software engineers
� Makers of public policy
� Professional societies
� Software engineering students
� Educators and trainers
www.swebok.org 14SIGAda 2000
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).
www.swebok.org 15SIGAda 2000
GenerallyAccepted
Advanced
Sp
ecia
lized
andResearch
Focus of the SWEBOK Guide
Categories of Knowledge Categories of Knowledge in the SWEBOKin the SWEBOK
www.swebok.org 16SIGAda 2000
Maths
Applicationdomain
knowledge
AdvancedSE
Knowledge
SWEBOK
C.S.
...
Knowledge of aSoftware Engineer
SpecializedSE
Knowledge
Software Software Engineer’s Engineer’s KnowledgeKnowledge
www.swebok.org 17SIGAda 2000
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
www.swebok.org 18SIGAda 2000
Project TeamProject Team
� Editorial team
� Industrial Advisory Board
� Knowledge Area Specialists
� Reviewers
www.swebok.org 19SIGAda 2000
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
Executive Editors
Guide Editors
www.swebok.org 20SIGAda 2000
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
www.swebok.org 22SIGAda 2000
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
www.swebok.org 23SIGAda 2000
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
www.swebok.org 24SIGAda 2000
• 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
www.swebok.org 25SIGAda 2000
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
www.swebok.org 26SIGAda 2000
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
www.swebok.org 28SIGAda 2000
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
Reduction in Complexity
Anticipation of Diversity
Structuring for Validation
Use of ExternalStandards
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
www.swebok.org 29SIGAda 2000
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
SoftwareConfiguration
Control
SoftwareConfiguration
Status Accounting
SoftwareConfiguration
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
www.swebok.org 30SIGAda 2000
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.
www.swebok.org 31SIGAda 2000
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.
www.swebok.org 32SIGAda 2000
ConstructionConstruction
� More to Come!
www.swebok.org 33SIGAda 2000
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
www.swebok.org 34SIGAda 2000
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
www.swebok.org 35SIGAda 2000
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
www.swebok.org 36SIGAda 2000
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.
www.swebok.org 37SIGAda 2000
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
www.swebok.org 38SIGAda 2000
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
www.swebok.org 39SIGAda 2000
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
www.swebok.org 41SIGAda 2000
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)
www.swebok.org 42SIGAda 2000
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
www.swebok.org 43SIGAda 2000
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
www.swebok.org 44SIGAda 2000
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
www.swebok.org 45SIGAda 2000
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
www.swebok.org 46SIGAda 2000
Versus DesignVersus Design
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 47SIGAda 2000
Use of ToolsUse of Tools
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 48SIGAda 2000
SelfSelf--EvaluationEvaluation
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 49SIGAda 2000
StandardsStandards
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 50SIGAda 2000
SWC SpectrumSWC Spectrum
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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”)
www.swebok.org 51SIGAda 2000
ManualManual
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 52SIGAda 2000
AutomatedAutomated
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 53SIGAda 2000
StylesStyles
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 54SIGAda 2000
LinguisticLinguistic
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 55SIGAda 2000
FormalFormal
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 56SIGAda 2000
VisualVisual
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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”
www.swebok.org 57SIGAda 2000
PrinciplesPrinciples
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 58SIGAda 2000
ReductionReduction
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 59SIGAda 2000
Reduction by RemovalReduction by Removal
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 60SIGAda 2000
Reduction by AutomationReduction by Automation
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
TaxonomyReferences
� Reduction by Automation “eliminates” complexity by solving it once and automating the solution
� Examples:
v Compilers
v Operating systems
v Visual programming languages
www.swebok.org 61SIGAda 2000
Reduction by LocalizationReduction by Localization
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 62SIGAda 2000
AnticipationAnticipation
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 63SIGAda 2000
Anticipation by GeneralizationAnticipation by Generalization
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 64SIGAda 2000
Anticipation by ExperimentAnticipation by Experiment
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 65SIGAda 2000
Anticipation by LocalizationAnticipation by Localization
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 66SIGAda 2000
ValidationValidation
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 67SIGAda 2000
StandardsStandards
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 68SIGAda 2000
TaxonomyTaxonomy
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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
www.swebok.org 69SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 70SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 71SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 72SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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.
www.swebok.org 73SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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.
www.swebok.org 74SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 75SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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)
www.swebok.org 76SIGAda 2000
ReferencesReferences
DefinitionVersus DesignUse of ToolsSelf-EvaluationStandardsSWC Spectrum
ManualAutomated
StylesLinguisticFormalVisual
PrinciplesReductionAnticipationValidationStandards
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