Becoming a Certified Software Development Professional (CSPD) and Overview of The Software Engineering Body of Knowledge (SWEBOK)

1
Becoming a Certified Software Development
Professional (CSPD) andOverview of The
Software Engineering Body of Knowledge (SWEBOK)

• (Required reading SWEBOK Chapters 1 and 2
• Text Ch 1-4)

2
Background

• Licensing
• Regulation by government (state in US)
• Professional Engineer
• Individual granted title authority to offer
  engineering services
• Certification
• Statement of competence by an authority

3
Professions

• What is a profession??
• Law
• Medicine
• Accounting
• Characteristics
• Well defined body of knowledge / practices
• Code of ethics
• Continuing education
• Public service / commitment

4
SE and Engineering

• Why?
• Software has evolved from individual activity to
  highly organized team effort
• To help solve the software crisis
• Certification
• Legitimacy

5
Background - Status

• 1998 - Texas
• Board of Prof. Eng. Makes Soft. Eng. a recognized
  specialty
• 44 PEs with this specialty in May, 02.
• 2001 - Canada
• June Canadian Eng. Acr. Board accredits 3
  university soft eng programs
• Huge controversy rages..

6
Background - Efforts

• IEEE ACM efforts (1993 - 2000)
• Joint Committee on Establishing Soft. Eng. as a
  profession
• SWECC (1998) Soft. Eng Co-ord. Comm.
• Results
• Curriculum recommendations
• Code of ethics
• Soft Eng Body of Knowledge (SWEBOK)

7
Background - Recent

• ACM withdrew support/cooperation from SWEEC in
  2000
• Drops support for licensing software engineers
• IEEE CS Continues
• Certified Software Engineering Professional
  Beta Test Exam offered (April - June) 2001
• Becomes current CSDP program

8
CSDP - Current Status
9
Components of Certification

• 1. Mastery of a Body of Knowledge (BOK)
• 2. Adherence to a Code of Ethics
• 3. Experience in the Profession
• 4. Continuing Professional Education

10
CSDP Applicant Requirements

• 1. Education
• 2. Experience
• 3. Professionalism
• 4. Certification Exam

11
Education Requirements

• Applicant must
• Have baccalaureate or equivalent university
  degree
• Proof
• Copy of diploma
• OR
• Copy of transcript

12
Professional Requirements

• Adherence to code of professional behavior (code
  of ethics)
• Technical competency
• Proof (1 of 4 ways)
• Membership in IEEE, IEEE CS, or ASQ
• Membership in any of 17 equivalent orgs.
• Recommendation of 2 IEEE CS members
• Registration as Professional Engineer

13
Experience Requirements

• 9,000 hours software engineering experience (4.5
  years.)
• At least 2 years experience in last 4 years
• Experience in 6 or more of 11 areas
• Proof
• Resume / Curriculum Vitea detailing work
• AND
• Report of Experience Forms

14
Report of Experience Form
15
Exam Requirement

• Must take pass a certification exam
• Covers the Software Engineering Body of Knowledge
  (SWEBOK)
• 180 multiple choice questions
• 3.5 hours to complete

16
(No Transcript)
17
Application Process

• Submit
• Application (Form 1)
• Report of education professionalism form (Form
  2)
• Report of experience form(s) (Form 3)
• Current resume / CV detailing work education
  experience
• Copy of diploma / transcript

18
Re-Certification

• Required
• Every 3 years
• 150 fee
• Continued full-time software engineering practice
• Continuing education
• 30 Professional Development Units (PDUs)

19
Qualifying PDU Categories

• 1. Educational activities
• 2. Publishing
• 3. Presentations
• 4. Technical/Professional service
• 5. Self Study
• 6. Employment
• 7. Other

20
Sample PDUs

• Presentations
• RTP Spin 1 PDUs
• Self Study
• 3 years ACM, CS, journals 5 PDUs
• Employment
• 3 years _at_ 5/yr 15 PDUs
• Other
• Referee, reviewer ?? PDUs

21
CSDP - Evaluation

• Pros
• Backed by IEEE
• Developed by open, consensus process
• Includes the accepted components

• Cons
• Multiple choice exam
• No analysis of real work
• No measurement of engineering, judgment
• No enforcement of code
• No real recognition
• No consensus

22
The SWEBOK Guide

• Task Force
• Objectives
• Promote a consistent view of SE worldwide
• Clarify the place and boundaries of SE relative
  to other related disciplines
• Define/characterize the contents of the SE
  discipline
• Provide access to the various components of the
  SWEBOK
• Provide a foundation for curriculum development
  and individual certification and licensing

23
The SWEBOK Guide Contd

• A guide to describe the core of the SE Body of
  Knowledge
• Broken into Knowledge Areas

24
How we will use SWEBOK

• Has many definitions of most key terms, you
  will be required to know the terms defined in the
  chapters assigned.
• Has references to primary material (and
  occasional textbooks), you can use later when/if
  you need more details.
• Only doing an overview, you are expected to know
  what is there, not necessarily how to do it.
• Really covering the SWEBOK takes 5-8 courses!

25
Knowledge Areas

• Establishes boundaries that identify engineering
  disciplines
• May share common boundaries with other
  disciplines
• Does not attempt to describe all of the knowledge
  within SE

26
Knowledge Areas Contd

• Captures a subset of generally accepted
  knowledge or the core of SE

27
Knowledge Areas Contd

• There are 10 KAs in the SWEBOK
• Each KA contains a reasonable topic list
  presenting sound information about SE
• Excludes specific knowledge regarding application
  domains, business, technology, SLCs and
  development methods
• Compatible with what is generally found in
  industry

28
Knowledge Area Contd

• Each KA follows the KA Description Specification
• Includes description, topics, related areas and
  reference materials.

29
The Repeatable Process

• The first 5 KAs cover the repeatable process
• Requirements
• Design
• Construction
• Testing
• Maintenance
• Define KA used in the development of software
  management processes
• Together the are comparable to the definition of
  CMM level 2 excluding business specific knowledge

30
Software Requirements

• Requirements engineering process
• Requirements elicitation
• Requirements analysis
• Software requirements specification
• Requirements validation
• Requirements management

31
Software Design

• Basic concepts
• Key issues of software
• Structure and architecture
• Software design quality analysis and evaluation
• Design notation
• Software design strategies and methods

32
Software Construction

• Considered one of the fundamental act of SE
• The construction of working, useful software
  through programming, validation and testing.
• Three styles of construction
• Linguistic
• Formal
• Visual

33
Software Construction Contd

• Principles of construction
• Reduction of complexity
• Anticipation of diversity
• Structuring for validation
• Use of external standards
• Where does the Software Engineer learn to
  construct software?
• Is Computer Science a required related discipline?

34
Software Testing

• Basic concepts
• Test levels
• Test techniques
• Test-related measures and management

35
Software Maintenance

• Basic concepts
• Maintenance process
• Key issues
• Techniques for maintenance
• Is there a SENG course that covers software
  maintenance?

36
Related Disciplines

• Computer Science
• Mathematics
• Projects Management
• Computer Engineering
• Cognitive Science and Human Factors
• Systems Engineering
• Management and Management Science

37
The Defined and Managed Process

• The last 5 KAs cover the defined and managed
  process
• Software Configuration Management
• Software Engineering Management
• Software Engineering Process
• Software Engineering Tools and Methods
• Software Quality Analysis
• Together they are are comparable to the
  definition of CMM level 3 and 4

38
Software Configuration Management (SCM)

• Management of the SCM Process
• Software Configuration Identification
• Software Configuration Control
• Software Configuration Status Accounting
• Software Configuration Auditing
• Software Release Management and Delivery

39
Software Engineering Management

• Organizational Management
• Process/ Project Management
• Software Engineering Measurement

40
Software Engineering Process

• Software Engineering Process Concepts
• Process Infrastructure
• Process Measurement
• Process Definition
• Qualitative Process Analysis
• Process Implementation and change

41
Software Engineering Tools and Methods

• Software Tools requirements tools, design tools,
  Construction tools, testing tools, maintenance
  tools , engineering process tools, quality tools,
  configuration management tools, engineering
  management tools, infrastructure support tools,
  Miscellaneous tools issues
• Software Methods
• Heuristic
• Formal
• Prototyping
• Miscellaneous

42
Software Quality

• Software Quality Concepts
• Purpose and Planning of SQA and VV
• Activities and Techniques for SQA and VV
• Measurement Applied to SQA and VV

43
A complete SWEBOK based Education Program
Software Engineering Tools and Methods
Software Engineering Process
Software Engineering Management
Software Quality
Software Configuration Management
SWEBOK
Software Maintenance
Software Requirement
Software Testing
Software Construction
Software Design
44
Challenges

• Withdrawal of the ACM
• Core BOK vs. specific
• ACM interests and priorities
• Professional development
• Development and maturation of computing
  disciplines
• Public interest and critical systems
• Software quality

45
Challenges Contd

• Professional Engineer (PE) exams
• Areas are covered that are outside the CPSC or SE
  domain
• Rate of change in SE is high
• Who should take the exam?
• SE is not included in any depth

46
Challenges Contd

• Challenges
• Creativity and individuality
• Can a consensus be reached?
• Guarantee a product or a level of quality?

47
An Organizational alternative

• What is CMMI, and how related to PSP and CMM.
• What is required to achieve CMMI?
• Relating CMMI and EIA 859!

48
What is CMMI?

• Defines 5 levels of process maturity
• Describes model framework to be used for
• Assessing process maturity
• Determining priorities
• Instituting process improvement

Capability Maturity Model Integration CMMI
49
Relation to PSP and CMM

• PSP is the Personal Software process, and is
  basically a process (supported by course
  material to teach it) for an individual to follow
  a capabilities-based maturity model.
• CMM is the older SEI Capability Maturity Model,
  strictly for Software Development. CMMI is a
  generalization that covers more systems and
  project issues as well as business processes.

50
CMMI Levels
The five levels of CMMI process maturity!
Level 0 - Incomplete
51
At what CMMI Level are we performing?
Are all process goals being accomplished?

• Are Data Management requirements
• being met?
• Are all customers identified?
• Are all customer requirements identified?
• Are customer requirements being
• met?

NO

Review data management procedures to determine
CMMI Level
Are one or more of the process goals not
accomplished?
YES
CMMI Level 0 Incomplete
Performing at CMMI Level 0
Process not performed
52
How do we achieve Level 1?
Identify your customers
Identify customers needs
Identify management process goals
Identify work products
Develop steps to produce the desired work products
53
What is CMMI Level 1?

Level 1 - Performed

• Specific goals are being accomplished
• No defined processes
• Individuals may follow differing procedures
• Using general purpose tools

54
CMMI Level 1

• Dependent on individuals
• Results vary
• Resources vary
• Results unpredictable
• Practices are informal
• Quality inconsistent

Characteristics
55
Determining the CMMI Level
56
EIA 859
Includes 9 high level Data Management
Principles Principles address functions of Data
Management Describes fundamental concepts to
be considered when structuring a Data
Management process
EIA Standard 859 Industry Standard for Data
Management
DRAFT
57
EIA 859 Principles
EIA Standard 859 Industry Standard for Data
Management
DRAFT
58
EIA 859
CMMI EIA 859
CMMI
Principles
1. Define the organizationally- relevant scope
of Data Management 2. Plan for, acquire, and
provide data responsive to customer
requirements 3. Develop DM processes to fit the
context and business environment in which they
will be performed. 4. Identify data products and
views so their requirements and attributes can
be controlled. 5. Control data repositories,
data products, data views, and meta data using
approved change control process. 6. Establish
and maintain an identifi- cation process for
intellectual property, proprietary, and
competition-sensitive data. 7. Retain data
commensurate with value. 8. Continuously improve
data management. 9. Effectively integrate data
management and knowledge management.
Level 4 Quantitatively Managed
Advocates Repeatable Processes Project
Level Enterprise Level
59
Relating CMMI EIA 859
60
CMMI Level 2
Level 2 - Managed
Level 2 - Managed

• Planned and executed IAW policy/procedures
• Established objectives
• Adequate resources
• Applicable to a particular group/project

61
CMMI Level 2
62
Is the process being objectively evaluated?
63
CMMI Level 3
Level 3 - Defined

• Process institutionalized
• Process consistent across the organization
• Process measurable

64

65
CMMI Level 3

66
CMMI Level 4
Level 4 Quantitatively Managed

• Controlled using statistical and other techniques
• Process variation identified

67
CMMI Level 4
Is the process stable and predictable?
Are the quantitative/ qualitative
objectives based on customer needs?
Is quantitative/ qualitative process/ product
data being collected?
YES
YES
YES
YES
YES
Are significant processes/products statistically
managed?
Is the collected data being analyzed?
68
CMMI Level 5
Level 5 Optimizing

• Continuously improving performance
• Incremental improvement
• Technological improvement

69
Comparing CMMI Level 5 EIA 859


Does the process include continuous improvement o
bjectives?
YES
YES
YES
YES
Does the process allow for tech improvements?
Does the process include a plan for
attaining improvement objectives?
Does the process identify problems and defects?
Is the process optimized?
70
Summary
EIA Standard 859 Industry Standard for Data
Management
DRAFT
Data Management
CMMI
71
References

• Guide to the Software Engineering Body of
  Knowledge Trial Version, 2001,
  http//www.swebok.org/stoneman/version09.html
• Trip, Leonard L., Professionalization of Software
  Engineering Next Steps, 1999, http//www.swebok.o
  rg/documents/x3009.pdf
• A Summary of the ACM Position on Software
  Engineering as a Licensed Engineering
  Profession, http//www.acm.org/serving/se_policy/
  selep_main.html
• An Assessment of Software Engineering Body of
  Knowledge Efforts A Report to the ACM Council,
  http//www.acm.org/serving/se_policy/bok_assessmen
  t.pdf
• IEEE Computer Society Web Site
  http//computer.org/certification
• Code of ethics http//computer.org/certification/e
  thics.htm
• Comm. of the ACM, Nov. 2002 (45, 11)
• Licensing Software Engineers - 6 articles