Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Becoming a Certified Software Development Professional (CSPD) and Overview of The Software Engineering Body of Knowledge (SWEBOK) (Required reading SWEBOK."— Presentation transcript:

1 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 –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  Texas –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 ( ) –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 1. Education 2. Experience 3. Professionalism 4. Certification Exam CSDP Applicant Requirements

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

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 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 1.Promote a consistent view of SE worldwide 2.Clarify the place and boundaries of SE relative to other related disciplines 3.Define/characterize the contents of the SE discipline 4.Provide access to the various components of the SWEBOK 5.Provide a foundation for curriculum development and individual certification and licensing

23 The SWEBOK Guide Cont’d  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 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 Requirement SWEBOK Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Quality Software Engineering Tools and Methods Software Engineering Process

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

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? 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 Level 1 - Performed Level 2 - Managed Level 3 - Defined Level 0 - Incomplete CMMI Levels The five levels of CMMI process maturity! Level 4 Quantitatively Managed Level 5 Optimizing

51 NO CMMI Level 0 Incomplete YES Performing at CMMI Level 0 Are Data Management requirements being met? Are all customers identified? Are all customer requirements identified? Are customer requirements being met? Are all process goals being accomplished? Are one or more of the process goals not accomplished? Process not performed At what CMMI Level are we performing? Review data management procedures to determine CMMI Level

52 How do we achieve Level 1? Identify your customersIdentify customers needsIdentify management process goals Identify work productsDevelop 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 Characteristics Dependent on individuals Results vary Resources vary Results unpredictable Practices are informal Quality inconsistent

55 Determining the CMMI Level NO Is the process documented? CMMI Level 1 Process Performed Performing at CMMI Level 1 NO YES Are there 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?

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

57 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. EIA 859 Principles

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

59 Relating CMMI & EIA 859 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 Planned and executed IAW policy/procedures Established objectives Adequate resources Applicable to a particular group/project Level 2 - Managed

61 CMMI Level 2 YES Are there e stablished 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? 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 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

62 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. 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. Is the process being objectively evaluated? Comparing CMMI Level 2 & EIA 859 YES Is the process monitored? Are work products under configuration control? Are all relevant stakeholders being considered? Is the process controlled and measured?

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

64 YES Is the process unique to the organization? Is the process considered standard? Is the process being objectively evaluated? Is the process defined? Is the process institutionalized? YES 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 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. YES Is the 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

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

67 CMMI Level 4 YES Is the process stable and predictable? YES Is the collected data being analyzed? Are the quantitative/ qualitative objectives based on customer needs? Are significant processes/products statistically managed? Is quantitative/ qualitative process/ product data being collected? 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.. CMMI Level 4 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. 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.

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

69 Comparing CMMI Level 5 & EIA 859 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. YES Does the process include continuous improvement objectives? Does the process allow for tech improvements? Is the process optimized? Does the process include a plan for attaining improvement objectives? Does the process identify problems and defects?

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

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


Download ppt "Becoming a Certified Software Development Professional (CSPD) and Overview of The Software Engineering Body of Knowledge (SWEBOK) (Required reading SWEBOK."

Similar presentations


Ads by Google