• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software Project Management and Support
 

Software Project Management and Support

on

  • 1,425 views

 

Statistics

Views

Total Views
1,425
Views on SlideShare
1,425
Embed Views
0

Actions

Likes
0
Downloads
57
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Project Management and Support Software Project Management and Support Presentation Transcript

    • Software Project Management and Support - Practical Support for CMMI®-SW Project Documentation: Using IEEE Software Engineering Standards John Walz The Sutton Group IEEE Computer Society Standards Activities Board and Awards Committee member APEGGA Professional Development seminars Edmonton, Alberta, Canada 20-Apr-06 1 © 2006 John Walz 1
    • John Walz • Sr. Consultant, The Sutton Group – Software / CMMI® • Retired Lucent / AT&T • Sr. Member IEEE, Standards Assoc. • Secretary, IEEE Computer Standards Activity Board • Vice-Chair Planning, IEEE Software & Systems Standards Committee • Secretary TL 9000 SIG • Sr. Member ASQ • Blog Author, ASQ Sarbanes-Oxley
    • Software Project Management & Support •Quality •Productivity •Risk Reduction • Objectives • People •Certifications •Sftw Prj Mgr - CSPM -QAI • Processes •Sftw Prj Mgr - SwPM -SQI •Project Mgmt Professional -PMI • Standards / Methods •Sftw Dev Prof - CSDP -IEEE •Sftw Quality Engr - CSQE -ASQ •Training 3 © 2006 John Walz 3
    • Audience M I CM • Software Project Managers • Software Engineering Professionals • Software Engineering Managers • Organizations seeking to satisfy documentation requirements for Levels 2 & 3 of Capability Maturity Model Integrated for Software (CMMI®-SW) 4 © 2006 John Walz 4
    • Overview • Problem Statement – Sftw Engr organizations face pressures and risks of missed deliveries and cost overruns • Proposed Solution – Organizations using CMMI®-SW model, report significant reductions in missed deliveries and cost overruns • Good news ☺ – CMMI®-SW is free to use and flexible • Bad news – Organizational difficulties with CMMI®-SW implementation and assessments 5 © 2006 John Walz 5
    • Software Project Management & Support • Objectives •Life Cycle Models • People •Project Management •Support • Processes • Standards / Methods 6 © 2006 John Walz 6
    • Processes • Life Cycle Models – Software Life Cycle Processes -IS 12207 – CMMI-SW Framework • Project Management – Project Planning (PP) – Project Monitoring and Control (PMC) – Risk Management (RSKM) • Support – Configuration Mgmt (CM) – Process & Product Quality Assurance (PPQA) 7 © 2006 John Walz 7
    • What is CMMI®-SW? • CMMI is a – Goal-oriented process model – Framework for reliable and consistent assessments – Mechanism for identifying & adopting best practices • Lessons learned by high maturity organizations • CMMI is NOT a – Prescription – Standard – Methodology • Reference: – CMMI®-SW, v1.1, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, 2002 8 © 2006 John Walz 8
    • CMMI® Structure Maturity Levels MLx Process Area 1 Process Area 2 Process Area n PA n Specific Goals Generic Goals GGx SGx Specific Practices Generic Practices Capability Levels CLx SPx.y GPx.y 9 © 2006 John Walz 9
    • CMMI®-SW Process Areas Maturity Level Maturity Level Process Area (PA) Name Process Area (PA) Name #Practices #Practices (ML) (ML) GP/SP GP/SP 5 Organizational Innovation and Deployment 19 Causal Analysis and Resolution 17 Optimizing 4 Organizational Process Performance 17 Quantitative Project Management 20 Quant Managed 3 Requirements Development 20 Technical Solution 21 Defined Product Integration 21 Verification/Validation 20 Organizational Process Focus 19 Organizational Process Definition 17 Organizational Training 19 Integrated Project Management 20 Documentation Risk Management 19 Scope 2 Requirements Management 15 Project Planning 24 Managed Project Monitoring and Control 20 Process and Product Quality Assurance 14 Configuration Management 17 Supplier Agreement Management 17 Measurement and Analysis 18
    • Organization Institutionalization Generic Practices 2.1 to 3.2 2.1 Adhering to organizational policies 2.2 Following established plans and process descriptions 2.3 Providing adequate resources 2.4 Assigning responsibility and authority for performing the process 2.5 Training the people performing and supporting the process 2.6 Placing work products under appropriate configuration management levels 2.7 Identifying and involving relevant stakeholders 2.8 Monitoring process performance against performance plans and taking corrective actions are when required 2.9 Evaluating the process, its work products, and its services for adherence to the process descriptions, objectives, and standards, and addressing noncompliance issues 2.10 Reviewing all process activities, status, and results with higher level management, and taking corrective action when required 3. Addressing all items that institutionalize a Managed process 3.1 Establishing the description of the defined process for the project or organizational unit 3.2 Deriving work products, measures, and improvement information from information collected from the planning and performance of defined processes Addressing all items that institutionalize a Defined process 11 © 2006 John Walz 11
    • Work Product / Artifact • CMMI®: any artifact produced by a process – Include files, documents, parts of the product, services, processes, specifications, and invoices, etc. • Scheduled by Project Managers • Stored in Configuration Management Systems • Tested for Quality • Used & shared by project staff members • Assessed for Organizational Capability or Maturity 12 © 2006 John Walz 12
    • Problem Details • Difficulties – CMMI®-SW creates many Work Products or Artifacts during the Software Life Cycle and these are inputs to the Assessment • Artifact Problem – Which Artifact? – What is the Artifact content and format? – How to convince the organization to use our “standard Artifact”? • Artifact Approaches – Mandate using existing Artifacts from best company’s project – Invent and design your own Artifacts – Benchmark & borrow Artifacts from the industry best company – Borrow Artifacts from Standards developed by the industry best 13 © 2006 John Walz 13
    • Software Project Management & Support • Objectives • People • Processes • Standards / Methods •SoftWare Engineering Body Of Knowledge (SWEBOK) •Software Engineering Standards 14 © 2006 John Walz 14
    • What are IEEE Software Engr. Standards? • Represent industry best practices – having been developed by domain experts with broad expert consensus. • Specify content – Provide detailed procedure explanations and offer section by section guidance on building the necessary documentation – with no recommendation of exact techniques or formats – Used as tools to help in the painful process of ‘self-documentation’ • Specify the minimum required contents for each CMMI® support document 15 © 2006 John Walz 15
    • Value of Standards A standard is a Name for an • What is “testing”? • Sftw Engr needs otherwise fuzzy concept standards to assign names to practices or In a complex, … a standard gives a name collections of multidimensional to a bounded region. practices. trade space of • This enables solutions ... communication between Buyer and Seller • Standards represent It defines some the “minimum level of characteristics that a responsible practice” buyer can count on. Jim Moore, 2004-03 CSEE&T Panel 7 16 © 2006 John Walz 16
    • 8 Steps to Success In CMMI® -Compliant Process Engineering Practical Support for CMMI®-SW Project Documentation: Using IEEE Software Engineering Standards Understand Look to the Look to Look to 1 your business 2 CMMISM for 3 Framework 4 Supporting processes Process Standards for Life Standards for Completeness Cycle Definition Process Detail 5 Build or Refine 6 Execute Your 7 Measure Your 8 Confirm Your Your Process Processes Results - Modify Status With Architecture Processes as Independent Necessary Appraisals 3 3 3 3 16th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004 17 Copyright 2004, Paul R. Croll, All rights reserved © 2006 John Walz 17
    • In Other Words… Using IEEE Software Engineering Standards to: • Define software engineering (SE) processes • Perform software engineering gap analyses • Improve existing SE processes • Ensure CMMI®-SW Level 2 & 3 conformance 18 © 2006 John Walz 18
    • The CMMI® and IEEE SE Standards The CMMI is a compendium of software engineering practices, which act as the motivator for the continuous evolution of improved software engineering processes IEEE Standards can be used to provide the basic beginning framework for software process improvement 19 © 2006 John Walz 19
    • CMMI®-SW Level 2 & 3 Comparison to IEEE SE Standards Level 2 CMMI-SW PA Level 2 CMMI-SW PA IEEE Standards IEEE Standards Requirements Management IEEE Std 830 – Practice for Software Requirements Specifications Project Planning IEEE Std 1058 – Software Project Management Plans; IEEE Std 1490 – PMBOK Project Monitoring and Control IEEE Std 1058 – Software Project Management Plans Process and Product Quality IEEE Std 730 – Software Quality Assurance Assurance Configuration Management IEEE Std 828 – Software Configuration Management Plans Supplier Agreement Management IEEE Std 1062 – Practice for Software Acquisition Measurement and Analysis IEEE Std 1045 – Software Productivity Metrics
    • CMMI®-SW Level 2 & 3 Comparison to IEEE SE Standards Level 3 CMMI-SW PA Level 3 CMMI-SW PA IEEE Standards IEEE Standards Technical Solution IEEE 1016 – Software Design Descriptions IEEE 1063 – Sftw. User Documentation; IEEE 1471 – Arch. Desc. of Sftw. Syst. Validation IEEE 1028 – Software Reviews Verification; IEEE 829 - Software Test Documentation Validation Project Planning; IEEE 1490 - Project Management Body of Project Monitoring & Control; Knowledge Integrated Product Management Project Planning; IEEE 1058 – Software Project Management Project Monitoring & Control Plans Risk Management IEEE 1540 - Risk Management ... ... ... ...
    • CMMI® Model Components • Specific Goals Required • Specific Practices • Generic Goals Expected • Generic Practices CMMI / IEEE SE Book – Typical work products – Sub-practices Informative – Notes – References CMMI®-SW Level 2 & 3 Support 22 © 2006 John Walz 22
    • Expert Guidance http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471738492.html
    • Book Chapters • Introduction and Overview • CMMI®-SW Summary • Organization Institutionalization – ML 2 & 3 GP • Implementation Guidance • CMMI®-SW Level 2 Support • CMMI®-SW Level 3 Support • CMMI®-SW Level 2 for Small Projects • CMMI®-SW Level 2 & 3 Comparison to IEEE SE Standards • Software Process Work Products (102) • Software Process Work Products Templates (38) 24 © 2006 John Walz 24
    • Artifact Creation Example PA: Requirements Management 25 © 2006 John Walz 25
    • PA: Requirements Management Goals and Practices CMMI®-SW Level 2 & 3 Support Specific and Generic Goals/Practices Book Plan or Artifact Specific and Generic Goals/Practices and Book Plan or Artifact and Typical Work Products Typical Work Products SG1 – Manage Requirements GG2 – Institutionalize a Managed Process SP1.1 – Obtain an understanding of GP2.1 – Establish an organizational policy requirements Organizational policy supporting requirements Organizational policy List of criteria for distinguishing Requirements Management Plan management appropriate requirements providers GP2.2 – Plan the process Criteria for evaluation and acceptance Requirements Management Plan Documentation in support of the requirements Requirements of requirements management planning process management plan Results of analyses against criteria Requirements Specification Review GP2.3 – Provide resources An agreed-to set of requirements Requirements Specification Identification of resources used in support of Project plan, SP1.2 – Obtain commitments to requirements identification and management requirements requirements management plan Requirements impact assessments Requirements Specification GP2.4 – Assign responsibility Documented commitments to Signed SRS or approved change Description of individuals responsible for Requirements requirements and requirements requests requirements management activities management plan, changes project plan, or SP1.3 – Manage requirements changes organizational policy Requirements status Requirements database, baseline GP2.5 – Train people change request Identify how individuals will be provided the Training plan or project Requirements database Requirements database appropriate training plan Requirements decision database Requirements database GP 2.6 – Manage configurations SP1.4 – Maintain bi-directional Description of how requirements and all Configuration traceability of requirements associated artifacts are placed under management plan Requirements traceability matrix Requirements Specification and configuration management database GP 2.7 – Identify relevant stakeholders Requirements tracking system Requirements database Identify who is responsible for the definition and CCB meeting minutes, SP1.5 – Identify inconsistencies management of requirements traceability reporting, between project work and requirements and requirements Documentation of inconsistencies Requirements Specification Review reviews including sources, conditions, and rationale Corrective actions Revised SRS
    • PA – Requirements Management Artifact Software Requirements Management Plan IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. Outlines the requirements for what comprises a good Software Requirements Specification (SRS): • Establishes basis for agreement between customers and suppliers on what the software product is to do • Reduces the development effort • Provides a basis for estimating costs and schedules • Provides a baseline for validation and verification • Facilitates transfer • Serves as a basis for enhancement 27 © 2006 John Walz 27
    • Software Requirements Management Plan Document Outline Table of Contents 5.1.3 Dynamic Analysis Revision Sheet 5.2 Software Requirements Management Process 1.0 Introduction 5.2.1 Requirements Elicitation 2.0 Purpose 5.2.2 Requirements Analysis 2.1 Scope 5.2.3 Requirements Specification 2.2 Definitions 5.3 Characteristics of a Good SRS 2.3 Goals 5.3.1 Correct 3.0 References 5.3.2 Nonambiguous 3.1 Key Acronyms 5.3.3 Complete 3.2 Key Terms 5.3.4 Verifiable 3.3 Key References 5.3.5 Consistent 4.0 Management 5.3.6 Modifiable 4.1 Organization 5.3.7 Traceable 4.2 Tasks 5.3.8 Usable During Operation and Maintenance 4.3 Responsibilities 6.0 Standards and Practices 4.3.1 Management 7.0 Software Measurement and Metrics 4.3.2 Program Manager 8.0 Verification and Validation 4.3.3 Project Lead 9.0 Software Configuration Management 4.3.4 Team Members 10.0 Developing a Software Requirements Specification 4.3.5 Customer 5.0 Software Requirements Management Overview Appendix A // Project Software Requirements 5.1 Software Requirements Modeling Techniques Specification Template 5.1.1 Functional Analysis Appendix B// Requirements Traceability Matrix 5.1.2 Object-Oriented Analysis 28 © 2006 John Walz 28
    • Software Requirements Management Plan Document Guidance • Purpose - ……………………….. • Scope - ……………………….. • Definitions - ……………………….. • Goals - ……………………….. • Management Organization - ……………………….. • Tasks - ……………………….. • Responsibilities - ……………………….. • Software Requirements Management - ……………………….. • Software Requirements Modeling Techniques - ……………………….. Provides section-by-section • ……………………….. guidance in support of the document creation • ……………………….. 29 © 2006 John Walz 29
    • Software Requirements Management Plan Document Template • Purpose - ……………………….. • Scope - ……………………….. • Definitions - ……………………….. • Goals - ……………………….. • Management Organization - ……………………….. • Tasks - ……………………….. • Responsibilities - ……………………….. • Software Requirements Management - ……………………….. • Software Requirements Modeling Techniques - ……………………….. Provides section-by-section • ……………………….. “fill-in the blanks” support of the document creation • ……………………….. Book has integrated set of 38 deployable document templates on CD-ROM
    • In Conclusion • Understand your business • Build or Refine Your Process processes Architecture • Look to the CMMI for Process – Fix timelines to produce goal Completeness driven process improvement – Use CMMI building blocks for – Define your processes in outline higher maturity set at each form stage – Redefine your processes • Look to Framework Standards – Use IEEE standards to develop for Life Cycle Definition your baseline process – IEEE 12207 documentation • Look to Supporting Standards • Execute Your Processes for Process Detail • Measure Your Results - Modify – Use IEEE standards to Processes as Necessary perform a gap analysis – Perform self-audit using CMMI PAs – Readjust processes/plans based upon audit results. • Confirm Your Status With Independent Appraisals Make a plan. Then follow the plan. - Watts Humphrey 31 © 2006 John Walz 31
    • IEEE Software Engineering Standards Collection • Over 40 of the most current IEEE software engineering standards on CD-ROM ISBN 0-7381-3757-X, Sep03, Catalog # ST01121, $370.00 Members / $465.00 List 32 © 2006 John Walz 32
    • Wiley and IEEE Computer Society Press Book Series • Software Engineering, Vol. 1 & 2, The Development Process, 3rd Edition by Richard H. Thayer, Mark J. Christensen • Trustworthy Systems Through Quantitative Software Engineering by Lawrence Bernstein, C. M. Yuhas • Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement by Jeff Tian • Jumpstart CMM/CMMI Software Process Improvements: Using IEEE Software Engineering Standards by Susan K. Land • Information Security : A Strategic Approach by Vincent LeVeque • The Road Map to Software Engineering: A Standards-Based Guide by James W. Moore • Practical Support for CMMI-SW Software Project Documentation: Using IEEE Software Engineering Standards by Susan K. Land, John W. Walz www.wiley.com/WileyCDA/Section/id-11028.html
    • Questions? 34 © 2006 John Walz 34
    • Mind Map
    • Backup slides
    • Software Engineering Body of Knowledge (SWEBOK) SWEBOK® Area CMMI®-SW Process Areas Requirements . . . Design . . . Construction . . . Testing . . . Maintenance . . . Configuration Management . . . Engineering Management . . . Engineering Process . . . Tools and Methods . . . Quality . . . ISO/IEC TR 19759 37 © 2006 John Walz 37
    • Why Use IEEE Standards in Support of Process Improvement ? • IEEE Standards can be used as tools to help in the painful process of ‘self-documentation’. •Many of the standards provide detailed procedure explanations, e.g., section by section guidance on building the necessary documentation. • Most importantly, they provide the best practice as defined by those from the software development industry who sit on the panels of reviewers. They can be used to: •Define software engineering (SE) processes. •Ensure CMM/CMMI-SW Level 2 compliance. •Improve existing SE processes. •Perform software engineering gap analyses. 38 © 2006 John Walz 38
    • Implementation Guidance Initiate Diagnose Establish Act Learn Serves a road map for software process implementation (e.g. CMMI) and improvement
    • Implementation Guidance IDEAL Implementation Initiate Define and Train the Process Team Leverage the expertise contained in the IEEE Software and Systems Engineering Standards. Diagnose Initial process baseline, Gap Analysis Set Realistic Goals Establish Fix Timelines for Goal driven process improvement, Develop Action Plans Act Baseline and Implement Processes changes Define your processes in outline form; Document templates, Staff training, Redefine your processes./ Use IEEE standards to change your baseline process documentation Learn Perform Gap Analysis / self-audit using CMMI PAs Re-plan Readjust processes/plans based upon audit results 40 © 2006 John Walz 40
    • Standards Support of Continuous Process Improvement Process P&P Improvement Plan PAL Training Action Training Work Process Baseline Materials Plans Materials Instructions Training Training IEEE/EIA 12207 Materials Materials ISO/IEC 15288 Management Plans Framework Standards Continuous IEEE 830 Process Deployment Process Supporting Standards IEEE 830 Improvement IEEE Standards-Based 830 Knowledge Products Training Training Materials Materials Training Tailoring Performance Materials Records IEEE Tailoring Training Findings Standards- Based Materials Training Validation Evaluation Evaluation Reports 41 © 2006 John Walz 41
    • Strategy: Use the CMMI® as a Guide to Process Completeness Determine if essential elements of your processes are missing or incomplete Process Management Engineering • Organizational Process Focus • Requirements Management • Organizational Process Definition • Requirements Development • Organizational Training • Technical Solution • Organizational Process • Product Integration Performance • Verification • Organizational Innovation and • Validation Deployment Project Management Support • Project Planning • Configuration Management • Project Monitoring and Control • Process and Product Quality Assurance • Supplier Agreement Management • Measurement and Analysis • Integrated Project Management for IPPD • Decision Analysis and Resolution • Risk Management • Organizational Environment for Integration • Integrated Teaming • Causal Analysis and Resolution • Integrated Supplier Management • Quantitative Project Management 42 © 2006 John Walz 42