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

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

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

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

Background - Status 1998 - Texas 2001 - Canada 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…..

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)

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

CSDP - Current Status

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

CSDP Applicant Requirements 1. Education 2. Experience 3. Professionalism 4. Certification Exam

Education Requirements Applicant must: Have baccalaureate or equivalent university degree Proof: Copy of diploma OR Copy of transcript

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

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

Report of Experience Form

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

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

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

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

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

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

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)

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

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!

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

Knowledge Areas Cont’d Captures a subset of “generally accepted” knowledge or the core of SE

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

Knowledge Area Cont’d Each KA follows the KA Description Specification Includes description, topics, related areas and reference materials.

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

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

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

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

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?

Software Testing Basic concepts Test levels Test techniques Test-related measures and management

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

Related Disciplines Computer Science Mathematics Projects Management Computer Engineering Cognitive Science and Human Factors Systems Engineering Management and Management Science

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

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

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

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

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

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

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

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?

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

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

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

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

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.

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

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

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

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

CMMI Level 1 Dependent on individuals Results vary Resources vary Results unpredictable Practices are informal Quality inconsistent Characteristics

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

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

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

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

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.

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

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

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.

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

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.

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.

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

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.

CMMI Level 5 Level 5 Optimizing Continuously improving performance Incremental improvement Technological improvement

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.

Summary Data Management CMMI Level 2 Level 1 Level 3 EIA Standard 859 Industry Standard for Data Management DRAFT Data Management CMMI

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.org/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_assessment.pdf IEEE Computer Society Web Site: http://computer.org/certification Code of ethics http://computer.org/certification/ethics.htm Comm. of the ACM, Nov. 2002 (45, 11) Licensing Software Engineers - 6 articles