1. (Required reading SWEBOK Chapters 1 and 2 Text Ch 1-4)
Becoming a Certified Software Development Professional (CSPD) and Overview of The Software Engineering Body of Knowledge (SWEBOK)
(Required reading SWEBOK Chapters 1 and 2
Text Ch 1-4)

2. Background Licensing Professional Engineer Certification
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?? Characteristics 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
Why:
Better to proactively establish it now, rather than have governmental imposed constraints later
Legitimacy – to become recognized, as other engineering disciplines are, and to set standards as a basis for certification

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

6. Background - Efforts IEEE & ACM efforts (1993 - 2000) Results
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

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 Other Presentations Self Study Employment RTP Spin: 1 PDUs
3 years ACM, CS, journals: PDUs
Employment
3 5/yr: PDUs
Other
Referee, reviewer ?? PDUs

21. CSDP - Evaluation Pros Cons Backed by IEEE Multiple choice exam
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
3 task forces:
define body of knowledge and recommended practices
ethics and professional standards (completed 1998 and approved by ACM)
educational curricula for education (1998) (undergrad, grad)

23. The SWEBOK Guide Cont’d
A guide to describe the core of the SE Body of Knowledge
Broken into Knowledge Areas
Objectives: basically, the goal is to define the core body of knowledge of SE
core = everything that should be mastered to become certified. Material from related disciplines (like project management) is also needed by SE, but is not included in the core
NOT goals:
define everything in SE
define a level of detail allowing testing and defining curriculum

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 Cont’d
Captures a subset of “generally accepted” knowledge or the core of SE

27. Knowledge Areas Cont’d
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 Cont’d 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 Cont’d
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 V&V
Activities and Techniques for SQA and V&V
Measurement Applied to SQA and V&V

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
Association for Computing Machinery was an initial supporter of the SWEBOK effort along with IEEE
Core BOK vs. specific BOK
software development involves many tasks and roles, of which only a subset carries the burden of professional engineering
for example, an analysis by an engineer for the purpose of attesting to software safety versus the development or testing of a single function in a software system
Not all roles that are currently called “SE” involve responsibilities that are commonly regarded as “engineering”
ACM interests and priorities
Collection of materials like the BOK serves the first 2
Public interest and Software quality – 3 ways to ensure it
Attending to the product
Attending to the producing organization
Attending to the individuals the build the product
A BOK would address the individuals
Need a balance between the above questions – more research needed
ACM concerned with apparent haste between using the SWEBOK to start credentialing (Texas)
Question: might it be best to influence this process if possible?

45. Challenges Cont’d 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
Licensing issues:
Licensing as PEs not practical
Inappropriate exams:
Fundamentals of Engineering exam:
covers Chemistry, computers, electrodynamics, engineering economics, fluid mechanics, mechanics of material, thermodynamics
Taken by all PEs in any discipline
Need 100 ABET accredited schools with SE degree programs before the afternoon exam can be SE specific
Normal updates to exams happen every 3 years, and in some areas certification is for life
Who should be required to take such exams? Managers, req’ts writers, testers…?
PE process establishes everyone as a PE – it is up to the indivodual to decide if they are qualified to practice a particular subdiscipline

46. Challenges Cont’d 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? Capability Maturity Model Integration 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 Level 0 - Incomplete Level 2 - Managed Level 1 - Performed
The five levels
of CMMI process
maturity!
Level 5
Optimizing
Level 4
Quantitatively
Managed
Level 3 - Defined
Level 2 - Managed
Level 1 - Performed
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
Process not
performed
Performing at CMMI
Level 0

52. How do we achieve Level 1? Identify your customers
Identify customers needs
Identify management
process goals
Develop steps to produce
the desired work products
Identify 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
YES
Are there
policies
governing the
process?
Is there a
process plan?
adequate
resources
to execute the
Plan?
Is training
provided for
individuals
executing the
Process? NO
Is the process
documented?
CMMI Level 1
Process Performed
Performing at CMMI
Level 1 NO

56. EIA 859 EIA Standard 859 Industry Standard for Data Management DRAFT
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 Principles EIA Standard 859 Industry Standard for
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.
EIA Standard 859
Industry Standard
for
Data Management
DRAFT

58. Advocates Repeatable Processes
CMMI & EIA 859
CMMI
EIA 859
Principles
Level 5
Optimizing
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
Level 3 - Defined
Level 2 - Managed
Level 1 - Performed .
Advocates Repeatable Processes
Project Level
&
Enterprise Level

59. Relating CMMI & EIA 859 Principles EIA Standard 859 Industry Standard
for
Data Management
DRAFT
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.
3. Develop DM processes to fit the
context and business environment in
which they will be performed
1. Define the organizationally-
relevant scope of Data Management
8. Continuously improve data
management.

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 EIA 859 CMMI YES Are there established Is there a
policies
governing the
process?
Is there a
process plan?
Are there adequate
resources
to execute the
Plan?
Is training
provided for
individuals
executing the
Process?
Is the process
Documented?
EIA 859
Develop DM processes to fit the
context and business environment
in which they will be performed.
Determine related organizational
policies.
Identify external forces.
Determine related business
objectives.
Determine requirements for access
and delivery.
Determine who will create, access,
update, and dispose of the data.
Principle 3
Develop policies for process
execution based on organizational
requirements and customer needs.
Develop standards for work
products and services.
Identify stakeholders.
Define process dependencies and
work products and services.
Define resource requirements
(funding, people etc.)
Define work products requiring
configuration control.
Define process measurement
requirements to determine
process performance.
CMMI
Level 2

62. Comparing CMMI Level 2 & EIA 859
YES
Is the process
monitored?
Are work products
under configuration
control?
Are all relevant
stakeholders being
considered?
controlled and
measured?
Is the process
being objectively
evaluated?
EIA 859
Principle 3
Make needed adjustments in
processes, practices, policy,
organizational alignment and
infrastructure.
Control the integrity of data, data
elements, data structures and data
views.
Establish a change control process
that imposes the appropriate level
of review and approval.
Establish mechanisms for tracking
and determining status of data.
CMMI
Level 2
Evaluate the effect of deviations
from the process plans and
descriptions.
Review accomplishments against
process plans and descriptions.
Place the process work products
under configuration management.
Coordinate the process plan and
description with relevant stake-
holders.
Monitor and control the process.
Assign responsibility and authority
for performing the process.
Obtain the necessary resources.

63. CMMI Level 3 Level 3 - Defined Process institutionalized
Process consistent across the organization
Process measurable

64. CMMI YES Is the process unique to the organization? considered
standard?
being objectively
evaluated?
defined?
institutionalized?
CMMI
Level 3
Define process steps for
institutionalization.
Define policy/guidelines for
tailoring process steps.
Define process tailoring.
Document process tailoring.
Collect and document work
process/product measurement
results.
Develop and maintain a data base
for process/product measurement
information.
Document and store lessons learned
in the data base.

65. CMMI Level 3 CMMI EIA 859 YES Is the Is Are there tailored process
documented? Is
there a
data base to
record process
improvements?
Are there
guidelines
for tailoring the
institutionalized
process?
Is the process
quantitatively
managed?
CMMI
Level 3
Define process steps for
institutionalization.
Define policy/guidelines for
tailoring process steps.
Define process tailoring.
Document process tailoring.
Collect and document work
process/product measurement
results.
Develop and maintain a data base
for process/product measurement
information.
Document and store lessons learned
in the data base.
EIA 859
Principle 8
Establish and maintain a metric
process and reporting strategy.
Establish the necessary tools and
infrastructure to support the
process and assess the results.

66. Quantitatively Managed
CMMI Level 4
Level 4
Quantitatively Managed
Controlled using statistical and other techniques
Process variation identified

67. qualitative objectives
CMMI Level 4 Is
the process
stable and
predictable? Is
quantitative/
qualitative process/
product data
being
collected?
Are
the
quantitative/
qualitative objectives
based on
customer
needs?
YES
YES
YES
YES
YES
Are significant
processes/products
statistically
managed?
Is the
collected data
being analyzed?
EIA 859
Principle 8
Recognize the need to continuously
improve the quality of data resources.
Establish and maintain a metric
process and reporting strategy.
Establish the necessary tools and
infrastructure to support the process
and assess the results.
Monitor the quality of data to
improve data and processes.
CMMI
Level 4
Determine an understanding of the
ability of the process to achieve
the quantitative objectives.
Determine objectives for statistical
control.
Identify and measure the sub-
process determined to be under
statistical control.
Identify and measure process and
product attributes important to
quality and process performance.
Identify causes for process variation.
Manage processes to attain statistical
stability and predictability. .
Predict the ability of the process to
achieve performance objectives
using managed statistical data.
Institutionalize process
performance baselines.
Take appropriate action when
desired quantitative and process/
product performance objectives
are not being met.

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
objectives?
YES
YES
Does
the process
allow for tech
improvements?
YES
Does
the process
include a plan
for attaining
improvement
objectives?
YES
Does
the process
identify problems
and
defects?
Is the process
optimized?
CMMI
Level5
Develop and maintain process/
product improvement objectives.
Identify and implement tech-
nelogical innovations for process/
product improvements.
Manage process/product improve-
ment deployment.
Measure results against objectives.
Identify and correct process/
product defects.
EIA 859
Principle 8
Recognize the need to continuously
improve the quality of data
resources.
Implement a strategy for on-going
improvement.
Improve Data Management
through a systematic and self-
diagnostic process..
Identify objective evidence of
improvements.

70. Summary Data Management CMMI Level 2 Level 1 Level 3 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,
Trip, Leonard L., Professionalization of Software Engineering: Next Steps, 1999,
“A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession”,
“An Assessment of Software Engineering Body of Knowledge Efforts: A Report to the ACM Council“,
IEEE Computer Society Web Site:
Code of ethics
Comm. of the ACM, Nov (45, 11)
Licensing Software Engineers - 6 articles