James W' Moore 1

1
Making Software Development a Professional
DisciplineThe IEEE Computer Societys Program

• James W. MooreThe MITRE CorporationMay 2003

The opinions contained in this presentation are
those of the author and do not necessarily
represent those of The MITRE Corporation or its
sponsors.
2
From Grady Booch,The Future of Software
3
From Grady Booch,The Future of Software
4
What is Software Engineering?

• (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).
• -- IEEE Std 610.12

5
Model of the Maturity of a Profession

• Education
• Accreditation
• Skills development
• Licensing/certification
• Professional development
• Code of ethics
• Professional 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.
6
Software Engineering as a Profession A Model
Individual Engineers Development
Infrastructure Support for the Profession
Professional Societies
Initial professional education
Accreditation
Skills Development
One or both
Certification
Licensing
Professional development programs
Adapted from Steve McConnell, After the Gold
Rush, Microsoft Press, 1999, p. 93
Full Professional Status
Code of ethics
Adapted from Steve McConnell, After the Gold
Rush, Microsoft Press
7
Software Engineering is Becoming Recognized as an
Engineering Profession

• IEEE-CS/ACM Computing Curriculum 2001 completed.
  Basic curriculum is completed. Four specialty
  volumes are planned Computer Science, Computer
  Engineering, Software Engineering, Information
  Systems.
• Merger of CSAB and ABET completed. A single
  organization now accredits all university
  programs in computer science, information
  systems, software engineering and computer
  engineering.
• RIT granted the first-in-US Software Engineering
  bachelor degrees in 2001. (Degree requires five
  years, including coop work.) Accreditation
  process is now underway.
• IEEE-CS Software Engineering Body of Knowledge
  published in book form. Trial usage is underway
  leading to revision circa 2004. Several
  universities are using it to rationalize
  curriculum, e.g. SMU, NTU, NJIT.
• Licensing of software engineers underway in
  Texas, BC, Ontario, Quebec, other countries.

8
IEEE CS Support of the Professional
Professional Development
Necessary Infrastructure Support
Example Products and Services of Professional
Societies
Curricula CC2001, CCSE Accreditation ABET/CSAB Bod
y of knowledge SWEBOK Prof. literature IT Pro,
Software Prof. interaction Chapters, Elec.
Communities Prof. training DVP,
Tutorials, Distance Learning Design
solutions Standards, Workshops Practice
norms Standards, Best Practices Ethical
norms Code of Ethics Prof. certification CSDP
Initial professional education
Skills Development
Possibly
Certification
Licensing
Adapted from Steve McConnell, After the Gold
Rush, Microsoft Press
Full Professional Status
9
Software Engineering Body of Knowledge Project
10
Software Engineering Body of Knowledge 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 - SWEBOK
• Provide a topical access to the Software
  Engineering Body of Knowledge
• Provide a foundation for curriculum development
  and individual certification and licensing
  material

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

• Editorial team
• Project Champion
• Leonard Tripp, 1999 President, IEEE Computer
  Society
• Executive Editors
• Alain Abran, École de Technologie Supérieure
• James W. Moore, The MITRE Corp.
• Editors
• Pierre Bourque, École de Technologie Supérieure
• Robert Dupuis, UQAM

• Knowledge Area Specialists
• Pete Sawyer Gerald Kotonya, UK
• Guy Tremblay, Canada
• Terry Bollinger, USA, Louis Martin Philippe
  Gabrini, Canada
• Antonia Bertolino, Italy
• Tom Pigoski, USA
• John Scott David Nisse, USA
• Stephen MacDonell Andrew Gray, New Zealand
• Khaled El Emam, Canada
• David Carrington, Australia
• Dolores Wallace Larry Reeker, USA

• Industrial Advisory Board
• Provided funding so that the SWEBOK Guide will
  always be free.
• Provided practical advice
• Provided early feedback

• Reviewers
• Three review cycles
• Approximately 500 reviewers, 42 countries
• Approximately 10,000 comments

13
Industrial Advisory Board
Corporate Support by
Project managed by
14
Reviewer Demographics
Version 0.1 33 reviewers Version 0.5 195
reviewers Version 0.7 378 5 ISO nations
15
What Software Engineers Should Know
Application
Domain
Advanced
Knowledge
SWE
Knowledge
C.S.
Specialized
SWE
Guide to the
Knowledge
SWEBOK
Math
etc.
16
Types of Knowledge
Focus of the SWEBOK Guide
Generally
Accepted
Advanced
Specialized
Generally accepted Applies to most projects
most of the time and widespread consensus
validates its value and effectiveness. -- PMI
and
Research
In operational terms, we target the SWEBOK at
bachelors degree plus four years of experience.
17
Knowledge Areas

• Software Requirements
• Software Design
• Software Construction
• Software Testing
• Software Maintenance
• Software Configuration Management
• Software Eng. Management
• Software Eng. Tools Methods
• Software Engineering Process
• Software Quality

Related Disciplines

• Computer Science
• Mathematics
• Project Management
• Computer Engineering
• Cognitive Sciences
• Human Factors
• Systems Engineering
• Management
• Management Science

18
Knowledge Area Description
Classification of Topics
Matrix of Topics References
References
Topic Descriptions
Classification by Vincentis Taxonomy
Classification by Blooms Taxonomy
References to Related Disciplines
Not implemented in Stoneman
19
Overall SWEBOK Guide
20
Uptake of SWEBOK

• 1999-2002 32 conferences and workshops
• North America
• Europe
• Australia, New Zealand, Argentina,
• Editorial team presentations
• USA, Canada, Spain, Brazil, Japan, China,

• 2370 references to SWEBOK on Web in March 2003
• University
• Software Engineering curriculum
• University lectures
• Research Papers
• Professional development
• Conferences Workshops
• Certification Licensing
• Government Policy organizations
• Individuals

http//www.swebok.org
21
Examples of SWEBOK Uptake

• CSDP, CC2001/SE, and planned CS SW Portal are
  traceable to SWEBOK.
• A large defense contractor has experimented with
  the Guide to calibrate skills descriptions in
  proposals.
• An FFRDC has rewritten its Software Systems
  Engineer job description in terms of the SWEBOK
  knowledge areas.
• Construx, Inc. has rewritten its position
  descriptions in terms of the Guide, structures
  its professional development around the Guide.
• NTU and SMU have rationalized their software
  engineering offerings using the SWEBOK.
• SWEBOK provides the taxonomical basis for VISEK,
  a SWE Portal funded by the German government.
• SWEBOK contributed to SW Development portion of
  a BOK developed by the Canadian Council of
  Professional Engineers for use in provincial
  licensing programs.
• SWEBOK influenced (how much?) IFIP committee on
  IT professionalism.
• International Organization for Standardization
  (ISO) is adopting SWEBOK as a Technical Report.

22
Software Engineering Standards
23
Roles of Software Engineering Standards
More exciting

• Specify techniques to develop software faster,
  cheaper, better, IEEE 982.1 (Measures for
  Reliable SW)
• Provide consensus validity for best practices
  that cannot be scientifically validated, IEEE
  1008 (Unit Testing)
• Provide a systematic treatment of ilities, IEEE
  730 (SW Quality Assurance)
• Provide uniformity in cases where agreement is
  more important than small improvements, IEEE
  P1320.1 (IDEF0)
• Provide a framework for communication between
  buyer and seller, IEEE/EIA 12207 (SW Life Cycle
  Processes)
• Give precise names to concepts that are fuzzy,
  complex, detailed and multidimensional, IEEE 1028
  (SW Reviews)

More effective
24
A standard is a name for an otherwise fuzzy
concept
In a complex, multidimensional trade space of
solutions ...
a standard gives a name to a bounded region.
It defines some characteristics that a buyer can
count on.
25
Software EngineeringStandards in Context
Education
SWE Body of Knowledge
Certification
Dependability
Practice
Quality Management
Fundamental Principles
Process Definition
Project Management
Motivate
Process Assessment
System Engineering
Process Measurement
Body of Standards
Best Practices
Competency Certification
Organizational Adoption
Buyer/Seller Agreement
Critical System Assurance
26
Standards should Balance Principles and Practice
Standards should exist in a tension balancing
the integrating and organizing forces of a priori
principles with the messy real-world demands of
observed effective practices.
Observed Best Practices
A priori Principles
Standards
In many cases, a priori considerations are
provided by science and mathematics. Sometimes
they are provided by custom or by marketing
forces. In the case of software engineering, we
have to invent them.
27
Principes fondamentaux du génie logiciel

• A collaboration between the IEEE Computer Society
  and the Université du Québec à Montréal and the
  École de Technologie Supérieure.

SWE Principles organize, explain and validate the
practice standards.
SWE Principles are specific cases of general
engineering principles.
Practices are deployed based on the practice
standards.
Principles of Engineering and other Disciplines
Principles of Software Engineering
Practice Standards
Implemented Best Practices
Some SWE Principles may be generalized to
principles for the engineering of complex systems.
SWE Principles should be abstractions of
practice standards.
Practice standards should be recordings of
observed best practices.
Source Jabir97
28
Examples of Fundamental Principles

• Currently, 16 candidates. Examples are
• Since change is inherent in software, plan for it
  and manage it.
• Comme le logiciel est, de par sa nature même,
  sujet au changement, il faut planifier et gérer
  ce changement.
• Since tradeoffs are inherent to SWE, make them
  explicit and document them.
• Les compromis étant inhérents au GL, il faut les
  rendre explicites et les documenter.

Source Dupuis97
29
Certified Software Development Professional
30
Certification

• Certification is a voluntarily gained recognition
  by peers. There are 3 types professional,
  product-related, training-related.
• Certification ? Licensing ? Accreditation
• IT certifications have exploded from about 200 to
  more than 400 in three years.

• There are now 185,000 Certified Novell Engineers
  and 267,000 Microsoft Certified Software
  Engineers.
• Market projected at 4B by 2004. (IT training
  market 34B.) There are certification trainers,
  vendors, consultants and magazines.

31
IT Certifications

• Information Week reports bonus pay growing for
  certifications (and falling for non-certified
  skills). Median bonus for certified IT skill in
  4Q01 was 8.3 of base pay.

• IDC reports nine-month payback on company
  investment.

Who was the big winner? Answer to come.
32
Impact of Certification The PMI Example

• Project Management Institute (100K members
  growing at 20-30 per year) offers a Project
  Management Professional (PMP) certification.
• PMP is based on education, experience,
  examination, plus adherence to code of conduct.
• PMI provides PMBOK, self-assessment material,
  books, training courses, seminars, and
  examination. Process is ISO 9001 certified.
• Success
• 30,000 PMPs in 26 countries.
• Many employers (e.g. State of California)require
  it of project managers.
• Salary bonus for PMP is top one surveyed median
  bonus is 14 of base pay.

33
IEEE CS Certified Software Development
Professional

• IEEE Computer Society has rolled out the
  Certified Software Development Professional
  (CSDP) program.

Possesses fundamental knowledge and understanding
of computing principles and concepts and their
application to the definition, design,
construction, testing, and maintenance of
software. Is able to provide appropriate design
with technical and economic tradeoffs of modules,
subsystems, and systems in accordance with
standards of practice, specifications, and
principles of behavior of software as required to
perform the functions as stated in the software
requirements.

• Computer Society web site for CSDPhttp//www.com
  puter.org/certification

34
IEEE Computer Society CSDP

• Certification based
• education,
• experience (9000 hours),
• examination,
• code of ethics, and
• continuing education.
• Exam based on a Body of Knowledge and
  professional standards 3.5 hours, 180
  questions.
• Developed with Chauncey Group (a subsidiary of
  Educational Testing Service) to be fair, reliable
  and valid.
• First test in April 2002. About 250
  certifications to date.

35
Examination Development
Exam Specification Determine content weights
Job Analysis Describe the job domain Identify
needed skills
Exam questions Write questions Review at workshop
Validate exam Beta test Analyze questions Set cut
score
Assemble exam Select questions according to
content weights Review results
Approval by IEEE
36
Requirements for CSDP Certification

• Education
• Bachelor or equivalent university degree
• Experience
• 9000 hours of experience in 6 of the 11 Software
  Engineering Knowledge Areas
• Proof of Professionalism
• Review and acknowledge the Software Engineering
  Code of Ethics and Professional Practice
• Examination
• Pass the CSDP written examination

37
11 Knowledge Areas for CSDP

• Software Requirements
• Software Design
• Software Construction
• Software Testing
• Software Maintenance
• Software Configuration Management
• Software Engineering Management
• Software Engineering Process
• Software Tools and Methods
• Software Quality
• Business Practices Engineering Economics

Same as SWEBOKplus
38
Approximate Distribution of Questions
39
Examination Topics (1 of 4)

• Business Practices and Engineering Economics
  (3-4)
• Economics
• Ethics
• Professional Practice
• Standards

• Software Design (22-24)
• SW design concepts
• SW architecture
• SW design quality analysis and evaluation
• SW design notations and documentation
• SW design strategies and methods
• Human factors in SW design
• SW and system safety

• Software Requirements (13-15)
• Requirements engineering process
• Requirements elicitation
• Requirements analysis
• SW requirements specification
• Requirements validation
• Requirements management

40
Examination Topics (2 of 4)

• Software Construction (10-12)
• Construction planning
• Code design
• Data design and management
• Error processing
• Source code organization
• Code documentation
• Construction QA
• System integration and deployment
• Code tuning
• Construction tools

• Software Testing (15-17)
• Types of tests
• Test levels
• Testing strategies
• Test design
• Test coverage of code
• Test coverage of specifications
• Test execution
• Test documentation
• Test management

41
Examination Topics (3 of 4)

• Software Maintenance (3-5)
• SW maintainability
• SW maintenance process
• SW maintenance measurement
• SW maintenance planning
• SW maintenance management
• SW maintenance documentation

• Software Engineering Management(10-12)
• Measurement
• Organization management and coordination
• Initiation and scope definition
• Planning
• Software acquisition
• Enactment
• Risk management
• Review and evaluation
• Project closeout
• Post-closure activities

• Software Configuration Mgmt (3-4)
• Management of SCM process
• SW configuration identification
• SW configuration control
• SW configuration status accounting
• SW configuration auditing
• SW release management and delivery

42
Examination Topics (4 of 4)

• Software Engineering Process (2-4)
• Process infrastructure
• Process measurement
• Process definition
• Qualitative process analysis
• Process implementation and change

• Software Quality (6-8)
• SW quality concepts
• Planning for SQA and VV
• Methods for SQA and VV
• Measurement applied to SQA and VV

• Software Engineering Tools and Methods (2-4)
• Management tools and methods
• Development tools and methods
• Maintenance tools and methods
• Support tools and methods

43
Process of Becoming Certified

• Complete application including
• resumé
• transcript or diploma
• report of education
• verification of reading Code of Ethics
• report of experience in at least 6 of the 11
  knowledge areas

• Prepare for examination
• Self-study using a recommended two-volume
  resource guide, or
• Take exam preparation tutorial
• Schedule the exam at a Prometric test center
• Take the exam
• 4-hour, computer-based, 180-question,
  multiple-choice
• Pass/Fail is determined immediately
• Diagnostic scores for self-assessment in content
  areas are provided to candidates who do not pass

44
Taking the Test

• The 2003 Testing Window is from April 1, 2003 to
  June 30, 2003.
• The computerized exam can be taken at over 230
  Prometric Testing Centers.
• Special exam opportunity here at STC this week
• Discount on pre-exam tutorial.
• Discount on exam itself.
• Free retest within one year (so you can use the
  exam for your own personal gap analysis).

45
Certification Renewal

• Certificate is valid for 3 years
• Renewal is based upon earning continuing
  education credits

46
Importance to Individuals

• Self-assessment of professional knowledge
• Differentiation from less qualified individuals
• Credibility of qualifications for employment or
  contracts
• Professional recognition

But certification is not a guarantee of
competency.
47
Importance to Organizations

• Hiring A method to credibly assess
  qualifications.
• Salary Management A rational way to provide
  salary bonuses for vital IT skills.
• Training A structure for a development program
  leading to a recognizable result.
• Competency A method to assess strengths in
  important areas.
• Consulting A means to assert qualifications to
  consult in important areas.
• Suppliers A way to evaluate the ability of
  suppliers to perform.

48
Code of Ethics
49
Software Engineering Code of Ethics and
Professional Practices

• Developed by a Joint IEEE-CS/ACM Task Force on
  Software Engineering Ethics and Professional
  Practices. Approved in 1998.

The short version of the code summarizes
aspirations at a high level of the abstraction
the clauses that are included in the full version
give examples and details of how these
aspirations change the way we act as software
engineering professionals. Without the
aspirations, the details can become legalistic
and tedious without the details, the aspirations
can become high sounding but empty together, the
aspirations and the details form a cohesive code.
50
Short Version States Eight Principles

• Public Software engineers shall act consistently
  with the public interest.
• Client and employer Software engineers shall act
  in a manner that is in the best interests of
  their client and employer consistent with the
  public interest.
• Product Software engineers shall ensure that
  their products and related modifications meet the
  highest professional standards possible.
• Judgment Software engineers shall maintain
  integrity and independence in their professional
  judgment.

• Management Software engineering managers and
  leaders shall subscribe to and promote an ethical
  approach to the management of software
  development and maintenance.
• Profession Software engineers shall advance the
  integrity and reputation of the profession
  consistent with the public interest.
• Colleagues Software engineers shall be fair and
  supportive of their colleagues.
• Self Software engineers shall participate in
  lifelong learning regarding the practice of their
  profession and shall promote an ethical approach
  to the practice of the profession.

51
Example from Long Version

• Principle 4 JUDGMENT Software engineers shall
  maintain integrity and independence in their
  professional judgment. In particular, software
  engineers shall, as appropriate
• 4.01. Temper all technical judgments by the need
  to support and maintain human values.
• 4.02 Only endorse documents either prepared under
  their supervision or within their areas of
  competence and with which they are in agreement.
• 4.03. Maintain professional objectivity with
  respect to any software or related documents they
  are asked to evaluate.
• 4.04. Not engage in deceptive financial practices
  such as bribery, double billing, or other
  improper financial practices.
• 4.05. Disclose to all concerned parties those
  conflicts of interest that cannot reasonably be
  avoided or escaped.
• 4.06. Refuse to participate, as members or
  advisors, in a private, governmental or
  professional body concerned with software related
  issues, in which they, their employers or their
  clients have undisclosed potential conflicts of
  interest.

52
IEEE CS Support of the Professional
Professional Development
Necessary Infrastructure Support
Example Products and Services of Professional
Societies
Curricula CC2001, CCSE Accreditation ABET/CSAB Bod
y of knowledge SWEBOK Prof. literature IT Pro,
Software Prof. interaction Chapters, Elec.
Communities Prof. training DVP,
Tutorials, Distance Learning Design
solutions Standards, Workshops Practice
norms Standards, Best Practices Ethical
norms Code of Ethics Prof. certification CSDP
Initial professional education
Skills Development
Possibly
Certification
Licensing
Adapted from Steve McConnell, After the Gold
Rush, Microsoft Press
Full Professional Status