Project Management

  • 518 views
Uploaded on

 

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
518
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
21
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • GOOD ( Morning/Afternoon ) Welcome to the System Modification Scenario Project Management Training Class Housekeeping (restrooms, breaks, lunch, vending machines) Introductions Agenda Expectations. Write students’ expectations on a flip chart at the front of the classroom. Refer to it periodically when appropriate to point out we have covered an objective.
  • The overview is listed on the slide.
  • As you perform each of these objectives, you will grow to get a feel for what PM is and how it “fits” into our plans to reach CMM Level 2.
  • WHAT IS SPI? Software Process Improvement - The process we must follow as we endeavor to improve our software. WHAT IS MEANT BY “SOFTWARE PROCESS ’ ? The set of tools, methods, and practices involved in the production and evolution of a software product throughout the software life cycle. WHY DO WE NEED TO IMPROVE OUR SOFTWARE PROCESSES? 1. We want to be responsive to the rapid and constant technology changes. 2. We want to define and document our processes, which evolve over time and need to be recorded. 3. We need to improve reliability and quality. 4. We want to reduce costs. 5. We want to provide for measurements. 6. We want mature versus immature processes. FOCUS: on fixing the process, not the people. Improving the process can reduce stress, simplify jobs and reduce stress on the people.
  • Software Engineering Institute (SEI), a DoD-funded research and development center at Carnegie Mellon University, in Pittsburgh, PA.: 1. Surveyed hundreds of companies regarding software improvement. 2. Developed the CMM which: a. Identifies five levels of maturity that an organization may experience in work flow during software improvement process. b. Identifies particular clusters of related activities (key process areas, KPAs) that must be present to say that an organization is working at a particular level. This is WHAT we must do to be at a particular level. c. Identifies common features within each KPA. 3. Assigned organization to the level that best reflected the way they do business. This means that an organization might be at one level, but have a few AISs at a higher level. Also, an organization may have succeeded at some KPAs in higher level, but cannot be considered higher level until have succeeded in all KPAs at higher level.
  • Outlines the things an organization must do to be at the various levels. Describe characteristics of each level: Level 1 - chaotic, accomplishments come from heroic efforts, Level 2 - Processes are documented and are repeatable, analyzable, and changeable. Mainly geared toward project issues in an organization. Level 3 - At the corporate level, processes are defined and documented. Establish infrastructure for effective s/w engineering and management across all projects. Level 4 - Establish a quantitative understanding of the software process and the products being built. Level 5 - Create atmosphere to implement continuous and measurable software process improvement. Talk about each of the KPA’s and include a high-level overview of them (CMM Text pp. 32 - 39)
  • One scenario in the Software Process Architecture. Others are the Software Development Scenario (rel 2 due Jul/Aug ‘97), and maybe an Emergency SMS. SMS developed by FSO HQ SMS focuses on routine, controlled, periodic releases of changes to AISs Sets up the standard format for HOW we do business. It was developed by all FSAs/Best of Breed - collaboration effort. CMM tells us what key practices we must perform; the SMS tells us the procedures we’ll use to do it. A somewhat linear snapshot of the life cycle of a change in an AIS
  • This is another way to look at the high level of the SMS--like a floor plan. We will identify phases and subphases that specifically relate to PM. Not all phases of the SMS apply to every KPA. You have a chart of this. (Green card.) The phases and subphases, a high-level focus: Provide direction for mgmt of business practices. 7 phases = 7 heavy line boxes. Look into SMS extract to relate to SMS outline. Within the phases are subphases. For example, Change Initiation has 3 subphases. The tasks, subtasks, and procedures (Low-level focus): Deal with the procedures/steps to support our business practices. We will cover the phases and subphases that involve PM. Later, we’ll cover tasks, subtasks and procedures that help in execution of PM.
  • This course has emphasis on PM broken into: Estimation and Planning Tracking and Oversight
  • These are the student objectives for this section of the course. Let’s look at PM in general from the perspective of the CMM.
  • What does this mean to you? Emphasis on establishing REASONABLE plan. What is Project Management? Establishing reasonable plans for: Performing software engineering Managing the software project Providing adequate visibility into project’s actual progress Taking action to change the project’s schedule, resources, scope, or quality
  • THE PURPOSE OF PM IS TO: Provide Management Control Provide oversight of Estimation Planning Tracking Address commitments to project’s customer according to: Resources Constraints Capabilities Adjust plans when necessary DEVELOPING ESTIMATES for the work to be performed ESTABLISHING the necessary COMMITMENTS DEFINING THE PLAN to perform the work TRACKING, REVIEWING, AND REPORTING the software ACCOMPLISHMENTS and results against documented estimates, commitments, and plans ADJUSTING these PLANS based on the actual accomplishments and results
  • The above features are common to all KPAs of the CMM. as you learn about each KPA, you will learn where to look for the authoritative definition of CMMs common features for each KPA. The CMM common features institutionalize the process, provide an infrastructure, and make the process effective, repeatable, and lasting. PM as taught in this course includes both CMM KPAs: Software Project Planning Software Project Tracking and Oversight
  • Goals are: From the CMM A summary of key practices for the KPA Incorporated verbatim into the FSO policy Discussed in the CMM or the SMS Direct students to the CMM reprint for Software Project Planning.
  • Commitments to perform: Are key practices from the CMM Describe actions the organization must take to ensure the process is: Established Will endure Take the form of organizational policies and leadership Direct students to the CMM reprint for Software Project Planning.
  • Abilities to Perform: Are key practices from the CMM Describe project and organizational preconditions necessary to implement s/w process competently Typically involve: Resources Organizational structure Training Direct students to the CMM reprint for Software Project Planning. SOW is documented and approved Responsiblities for developing the software work products and performing SQA activities are assigned. Adequated resourced and funding are provided Training is received in the s/w estimating and planing procedures
  • Measurement and Analysis: Are key practices from the CMM Describe basic measurement practices necessary to determine status At higher maturity levels, describe practices that go beyond status and into the realms of: Quality Effectiveness Functionality Direct students to the CMM reprint for Software Project Planning.
  • Verifying Implementation common feature: Contains key practices from the CMM Describes steps to ensure that activities are performed in compliance with the established process Direct students to the CMM reprint for Software Project Planning.
  • Purpose of Policy: Establish an infrastructure to support software development improvement Establish high-level guidance to perform the improvement (standard processes)
  • Applies to all systems developed and requiring maintenance.
  • FSO Director: Establish Policy and Procedures for Project Management FSA/DSE Directors: Implement Policy and Procedures Ensure adequate resources Ensure their implementation Project Managers: Exercise overall responsibility for execution of procedures and standards and adherence to standards Prepare the SDP Track actual progress to documented estimates Conduct internal and external coordination IAW SMS Report progress to Sr. Mgmt. IAW SMS
  • These tasks, subtasks, and procedures are the FSO’s direction for tailoring the activities listed in the CMM KPA for SPP and SPTO.
  • PURPOSE of Rqts Spec and Impact Analysis subphase in Change Analysis phase : To analyze the detailed func’l and tech’l requirements definitions
  • PM-specific activities are bolded; first four tasks are mainly RM activities and the last SQA. Tasks to perform Rqts Spec and Impact analysis: Analysts Review (RM) Appl Execution Env. (AEE) and S/W Eng. Env. (SEE) Reviews (RM) Techn’l Arch. Guidance (TAG) Review by TARB (RM) Detailed Impact Analysis (Some PM subtasks) Perform the SRR (SQA) The emphasis of this part of the course is on the detailed impact analysis because it relates to PM.
  • Phases of SCRs (Bold relate to task on this slide) : Functionally Defined SCR - converted PTR from the technical proponent FSA-Accepted SCR - From Analysis Preparation Subphase - Req’s Rev and Acceptance Task (RM) FSA-Analyzed SCR - Req’s Spec and Impact Analysis Subphase - SCS Preparation Task (RM) FSA-Impacted SCR - Req’s Spec and Impact Analysis Subphase - Detailed Impact Analysis Task ( RM & PM) To understand this IDEF chart, must understand the three states of SCRs.
  • There are two subtasks related to PM: Detailed Impact Analysis Configuration Items(RM) Ancillary Requirements (PM) Risk Analysis (PM)
  • Purpose: to identify costs not normally associated with development. Examples: Special/additional hardware Training in a new language Extraordinary system testing requirements Implementation requirements
  • Purpose: to allow PM to recognize the risks and prepare some plans to mitigate the risks. Need to expose risk early and include decision points upon which the plan rests Represents the unknown or the never-been done-before. e.g., you can estimate fairly close for modifications that you are comfortable with. If you’ve never done this type of work before, or in this manner, you may have some risks that need to be identified and tracked.. Examples: Additional changes in req’s Specific deadline req’s Competing for resources Changes or upgrades to operating environment Special skills req’d by personnel to effect change
  • A non-level 2 activity (Design Preparation) and an optional (at this point) activity (System/Subsystem Design) precedes this subphase. CMM Activity 9, 10, & 11 Purpose of Resource Estimation Subphase To prepare detailed estimates for each SCR Size Effort Critical Computer Resource Firm Fixed Price To perform Resource Estimation Review
  • All four tasks relate to PM. Emphasize that we create separate size and effort estimates.
  • CMM - SW Project Planning - Activity 9 Input System/Subsystem Metrics are used as historical basis to more accurately estimate the size of a task. Purpose: estimate size or change to size of SW work products. Applies to all work products and activities: Operational software and support software Deliverable and nondeliverable work products Software and nonsoftware (documentation) Activities for developing, verifying, and validating work products IFPUG - International Fcn Point User Group -- international standards that apply to function point counting.
  • Approved methods - in the SMS: Lines of Code Function Point Analysis - official size estimation method for FSO Change Complexity Each AIS selects one Each AIS documents the selected method in the SDP Open the SMS to the section on Size Estimation and walk through the procedures with the student’s input.
  • CMM - SW Project Planning - Activity 10 Purpose: estimate effort and costs, related to the size estimates for the software work products. Applies to following types of costs: direct labor expenses Indirect labor expenses Overhead expenses Travel expenses Computer use costs Productivity data are used for estimates when available: Best when historical Use similar types of projects to gather history Best when using the same project
  • Approved methods - in the SMS: Lines of Code Function Point Analysis Change Complexity Function Point Analysis and Change Complexity must include both direct and indirect costs. Refer to the SMS, SCR Effort Estimation, to discuss the related effort estimation procedures.
  • CMM - SW Project Planning - Activity 11 Purpose: produce, record and coordinate CCR estimates for the requested change Estimates will be used by CCB for determining the SCRs that ultimately go into a release package.
  • Actually, at some AISs, PM has no involvement except to identify to FSA (functional organization) the needed CCR. The FSA has responsibility to acquire and budget for the CCRs. CCRs are those used by FSA development Examples from the SMS: Computer memory capacity DASD Computer processor use: Compiles Test runs Support tools Print support Telecommunication requirements Communication channel capacity LAN/WAN availability Identified risks If mid-tier, coordinate with DTI, otherwise, coordinate with DISA.
  • For each SCR: Identify costs for each CCR Record the estimates Record the commitments from the organizations responsible to provide the CCR
  • Purpose: produce, record and coordinate Firm Fixed Price for each SCR. CCB uses FFP to: Determine contents of scheduled release Set priorities Plan initial schedule Determine implementation date
  • We will talk about these subtasks on the next 5 slides
  • Record on an FFP estimate summary sheet if appropriate
  • If appropriate, multiply CCR cost by size factor % from SCR size estimate prep task. Record the result in FFP est worksheet
  • If appropriate, multiply Ancillary Requirements cost by size factor % from SCR size estimate prep task. Record the result in FFP est worksheet
  • Procedures TBD by FSO
  • This calculation is important. Will be the decision upon which your customer bsae decision to use your services to produce their product. Remember, record in a form or repository. Coordinate FFP with all affected groups and individuals Maintain a record of the coordination Remember you require approval of your business mgr to use CCR, Ancillary Rqts, and Subcontractor cost ests. as part of your FFP.
  • Purpose of Proposed Release Package Development: develop a package of SCRs for a release. Included are: SCRs projected for accomplishment in a scheduled release Work level required for implementation Staff availability required for implementation Responsibility “may or may not” lie with the FSA This is a non-level 2 subphase. Minimal work occurs in this subphase because work is not yet funded.
  • Two tasks--we’ll talk about them in the next two slides.
  • Purpose: create the list of scrs that will be proposed for this scheduled release. Take into consideration: Prioritized list of scrs for the most recent CCB Additional scrs that may be required due to new regulations, high priority or production support requirements Some limiting factors can prohibit accomplishing all scrs in current release: Labor resources Time constraint/quick deadline
  • In SMS Rel 3, there were seven subtasks. Current release only includes the most important, SCR List Determination. Others may return in future release of the SMS, mainly CCB activities: Effort Estimate Analysis Effort Availability Analysis Firm Fixed Price Determination Implementation Date Determination Identification Determination Recording
  • The practice seems to be that CCB develops the proposed list of SCRs in contrast to what the SMS says.
  • Purpose: reproduce, distribute for review, and coordinate to ensure timely response and closure.
  • A key difference in the SMS Release 4 is that emphasis is placed on electronic reproduction and distribution. Mainly through use of approved office productivity tools and e-mail.
  • Now, we are going to begin work on the SDP Also include SQA, CM, Test, etc. “ Planning the plan” Pensacola is the organization that opts to perform their release planning at the first optional opportunity.
  • Read 4.3 in SMS: Paragraph describes the different places where release planning could occur. First occurrence in SMS: Optional Performed at this point by Pensacola and some AIS’s at Indy. Requires MIPR (Military Interdepartmental Purchase Request) specifically for release planning activity (overall level-of-effort) Second place occurs in section 5.1 of SMS and is REQUIRED if not already performed.
  • Purpose: identify work required to satisfy release req’ts. Portions of SDP could be completed when this task is finished Requirements from individual SCR’s are consolidated for the release: Ancillary Requirements Critical Computer Resources Risk Staff Hours (effort and availability)
  • We’ll talk about these points on the next five slides.
  • Release estimates recorded in Section 5 of SDP Identify effort estimates (listed in SMS) for: Training Planning/administration Development supervision Requirements analysis/determination Data administration Design Programming Testing Integration Database administration Documentation Implementation Product assurance Configuration management Software engineering
  • This is also recorded in SDP, Section 5. Identify Critical Computer Resources (listed in SMS) for: Design Programming Testing Documentation Implementation
  • Risks and Concerns are recorded in SDP Section 11. Identify Risks (listed in SMS) for: Design Programming Testing Documentation Implementation With respect to: Cost Resources Schedule Technical aspects
  • Ancillary Requirements are recorded in SDP Section 9. Identify ancillary req’s for: Design Programming Testing Documentation implementation
  • Plan of action and milestones to develop the SDP: Review and modify SQAP and SCMP and test plans or others Establish the completion Date and Resources necessary to complete: Resource availability SCMP modification SQAP modification Test and evaluation master plan modification SIT plan development milestones SQT plan development milestones SAT plan development milestones SDP preparation milestones
  • Can create a rough capacity planning chart. Create an example in class.
  • Resource Availability Determination is Task 2 under Release Planning Subphase.
  • Analyze staffing patterns and availability during time frame for release. Ensure that all Effort Evaluation categories are covered. Training Planning/administration Development supervision Requirements analysis/determination Data administration Design Programming Testing Integration Database administration Documentation Implementation Product assurance Configuration management Software engineering
  • Analyze CCR availability during time frame for release. Ensure that all CCR categories are covered: Design Programming Testing Documentation Implementation
  • CMM - SW Project Planning - Activity 6 SDP used to schedule work to meet release date. There are a host of inputs to this task. The list starts on this page and continues onto the next.
  • These are the additional inputs, in addition to those on the previous slide.
  • The 19 subtasks are introduced on this and the next two slides. We’ll discuss each in detail
  • Purpose: a high level statement defining major area of impact for release. Scope: release number and description systems and/or subsystems affected list of SCRs Goals: define when and how the major goal defined in the purpose will be delivered. e.g., - “Locality pay will be implemented on the payroll system prior to end of the calendar year.”
  • This subtasks requires PM to define: principal groups and individuals responsible for parts of the release roles and responsibilities
  • Select an FSO-defined and approved system scenario. Make appropriate to the type of work. Can include: JAD - Joint Application Design RAD - Rapid Application Development System Modification Scenario.
  • Management and Technical Controls: Mandates, req’s, policies, etc. Imposed on the release. Methodologies, models, tools: Estimation Design Coding Testing Verification/Validation Walkthroughs Peer reviews Separate from SQA reviews. Tracking and oversight Periodic review intervals Actuals vs. Est. Deviation for cost, effort, size, CCR.S Deliverable completion reporting.
  • Record consolidated estimates for all the SCRs in the release.
  • Software products: Computer programs Procedures Associated documentation Data Describe: SCP - System Change Package, general release ICP - Interim Change Package - interim release Emergency Release?
  • Note the item and one of the following: Specific dates when the requirement must be met by the customer or, Date relative to a milestone, e.g. - implementation minus 10 days.
  • Note the item and one of the following: Specific dates when the requirement must be met by the customer or, Date relative to a milestone, e.g. - implementation minus 10 days.
  • Include Ancillary Requirements that FSA needs to complete the release. Do not include Ancillary Req’s for organizations external to FSA. Specify a date here also.
  • Some assumptions can include resources availability Work Breakdown Structure Components of WBS (tasks or summary tasks in the project plan) reflect the phases, subphases, etc. of the SMS structure.
  • Will address risks during periodic reviews.
  • Software Engineering Facilities: DISA Other federal activities. Support Tools: Hardware Software Firmware Examples: IBM, LAN, VISUAL BASIC
  • Each AIS can choose to either attach documentation and plans to the SDP or refer to documentation and plans as separate entities.
  • ditto previous slide
  • ditto previous slide
  • Includes: Statement of work Subcontractor’s development plans Any other release-level documents pertaining to subcontractor’s work
  • Distribute to all Intergroup communication is very important and has been one of the root causes of development problems. Communication tools have been provided to enhance the communications: e-mail, for example.
  • Retain for future reference and auditing purposes. Evaluators will use this documentation during an SCE Part of the CMM and the SMS point out the need to perform audits as part of achieving CMM Level 2.
  • The most important aspect of documenting and routing is to ensure that all affected groups offer their approval of the plan. Demonstrates a formal “sign up” for commitments contained in the plan.
  • Use CMM Reprint to discuss
  • Use CMM Reprint to discuss
  • Use CMM Reprint to discuss
  • Use CMM Reprint to discuss
  • Verifying Implementation: Are key practices from the CMM Describe steps to ensure that activities are performed in compliance with the established process Direct students to the CMM reprint for Software Project Tracking and Oversight.
  • Purpose of System/Subsystem design and CSU specifications development: determine design and specs for CSU to satisfy func’l req’s. Also, analyze changes to plan, modify the plan
  • Because the 2 tasks occur independently and we have seen the second one before, we will discuss the second task first. We performed a detailed impact analysis as part of the Change Analysis Phase, Req’s Specs and Impact Analysis Subphase.
  • Opportunity to review in light of any new information found out in investigation.
  • These are the only two subtasks that are the responsibility of PM. Other tasks are CI identification, performed by RM, and CDR, facilitated by SQA. The purpose of this task and its subtasks is to provide a periodical opportunity to review impacts and risks in light of any new information learned during the development process.
  • Similar to what we performed in Change Analysis Phase.
  • Similar to what we performed in Change Analysis Phase.
  • Before we define the steps, we’ll discuss high level concept of Tracking and Oversight It is similar to the project planning. Use the planned data Determine where you are relative to where you expect to be Adjust Report
  • AT PERIODIC INTERVALS, DEFINED IN THE SDP: collect data compare to estimates record report to management Repetitive and cyclic
  • Eight subtasks, seven of which are the responsibility of PM, The other is the responsibility of RM. Tracking and oversight: Repeat the same subtasks throughout the change development phase for: Design Development Test definition Test execution Test certification
  • For each CI, collect and record release metrics: Size Cost Effort CCR Schedule Technical activities Risk Ancillary req’s Compare actuals to estimates and record any deviation.
  • PM: Reviews progress with staff Devises corrective actions Discusses corrective actions with proj. Mgr and other mgmt. Implements course of action selected by appropriate management personnel
  • Provide to higher mgmt as appropriate.
  • Discuss and update status of tasks from previous periodic reviews.
  • Coordinate with all affected staff member, SQA, external orgs, and mgmt. Want to provide a chance for everyone to “sign up” for all changes to the plan that come out of the Tracking and Oversight process.
  • Gather and record completion data: Size Effort CCRs Cost Ancillary requirements
  • A review with the customer’s representatives to address current status of release, including review of due and pending deliverables. Record the meeting results Project officer ensures open items are completed.
  • T & O is done PM is involved in certification prior to entry of each test phase.
  • For all three test levels
  • Purpose for each phase is to record certification that all affected parties are comfortable that we have satisfied
  • Certifies prior to each test phase and before implementation. 3 parties are involved: SQA QATO PM

Transcript

  • 1. Welcome to the System Modification Scenario Project Management Training Class
  • 2. Course Overview
      • Review SPI, CMM, and SMS
      • Introduction to Project Management (PM)
      • PM and the CMM
      • PM and FSO Policy
      • Identification of PM tasks, subtasks, and procedures as outlined in the SMS
  • 3. SECTION 1 SPI Review
  • 4. SPI, CMM, SMS Review
    • The student will answer questions about:
      • Software Process Improvement (SPI)
      • Capability Maturity Model (CMM)
      • System Modification Scenario (SMS)
    • The student will identify:
      • The Key Process Areas of CMM Level 2
      • The outline levels of the SMS
  • 5. Software Process Improvement (SPI)
      • Effort to Improve Software Process
      • System of:
        • Tasks
        • Tools
        • Standards, Methods, Practices
      • Applicable Throughout Software Life Cycle
    SPI REVIEW
  • 6. Capability Maturity Model (CMM)
    • A FRAMEWORK FOR EFFECTIVE SOFTWARE PROCESSES
      • Identifies:
        • Maturity Levels
        • Key Process Areas
        • Common Features
    CMM REVIEW
  • 7. KEY PROCESS AREAS (KPAs) As Defined by SOFTWARE ENGINEERING INSTITUTE (SEI) “ SOFTWARE ENGINEERING AND MANAGEMENT PRACTICES” ORGANIZATION PROCESS DEFINITION SOFTWARE PRODUCT ENGINEERING ORGANIZATION PROCESS FOCUS INTEGRATED SOFTWARE MANAGEMENT INTERGROUP COORDINATION PEER REVIEWS TRAINING PROGRAM PROCESS MEASUREMENT & ANALYSIS QUALITY MANAGEMENT DEFECT PREVENTION TECHNOLOGY INNOVATION PROCESS CHANGE MANAGEMENT REQUIREMENTS MANAGEMENT PROJECT PLANNING PROJECT TRACKING & OVERSIGHT SUBCONTRACT MANAGEMENT SOFTWARE QUALITY ASSURANCE SOFTWARE CONFIGURATION MANAGEMENT LEVEL 3 - DEFINED LEVEL 4 - MANAGED LEVEL 5 - OPTIMIZING LEVEL 2 -REPEATABLE LEVEL 1 - INITIAL
  • 8. System Modification Scenario (SMS)
      • One part of the Software Process Architecture
      • Focuses on routine system modification
      • Provides:
        • Process definition
        • Description
        • Documentation
    SMS REVIEW
  • 9. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 10. Performance Check Open the Performance Check Package to SPI, CMM, SMS Review and answer the questions.
  • 11.
    • PROJECT
    • MANAGEMENT
    • INTRODUCTION
    SECTION 2
  • 12. PM Introduction
    • Objectives:
      • Define Project Management (PM) and its goals
      • Review CMM’s PM Common Features
      • Identify PM roles and responsibilities
      • Review the FSO’s PM Policy
  • 13. PM Introduction
    • What is PM?
      • Establishing plans for:
        • Performing software engineering
        • Managing the project
      • Providing adequate visibility into project’s actual progress
      • Taking action to change the project’s schedule, resources, scope, or quality
  • 14. PM Introduction
    • What are some of the functions performed?
      • Developing estimates
      • Establishing commitments
      • Defining the plan
      • Tracking, reviewing, and reporting accomplishments
      • Adjusting the plans
  • 15. PM Introduction
    • CMM’s PM Common Features:
      • Goals
      • Commitment to Perform
      • Ability to Perform
      • Activities to Perform
      • Measurement and Analysis
      • Verifying Implementation
  • 16. PM Introduction
    • Goals for S/W Project Planning (SPP):
      • Software estimates are documented for use in planning and tracking the software project
      • Software project activities and commitments are planned and documented
      • Affected groups and individuals agree to their commitments related to the software project
  • 17. PM Introduction
    • COMMITMENT TO PERFORM:
    • The project software manager:
      • Is responsible for:
        • Negotiating commitments
        • Developing the project’s SDP
        • Defining the project’s software activities
      • Follows a written organizational policy for planning and managing a software project
  • 18. PM Introduction
    • ABILITY TO PERFORM (SPP):
      • Statement of work exists for the project
      • Responsibilities and activities are assigned
      • Resources and funding are provided
      • Training is received in estimating and planning
  • 19. PM Introduction
    • MEASUREMENT AND ANALYSIS (SPP):
      • Determines the status of:
        • software planning
        • tracking
        • oversight activities
  • 20. PM Introduction
    • VERIFYING IMPLEMENTATION (SPP):
      • PM reviews the activities for SPP with:
        • Senior management (periodic basis)
        • All affected groups (periodic and event-driven basis)
      • SQA reviews and/or audits (per SQAP):
        • Activities
        • Work products
  • 21. PM Introduction - Policy
    • PURPOSE:
      • Establishes Software Project Management responsibilities and processes for the modernization or modification of AISs
      • Addresses a standard set of processes for:
        • Estimation
        • Planning
        • Tracking
        • Oversight activities
  • 22. PM Introduction - Policy
    • SCOPE:
      • Applicable to all Defense Finance and Accounting Service (DFAS) Financial Systems Activities (FSA)
  • 23. PM Introduction - Policy
    • RESPONSIBILITIES IDENTIFIED FOR:
      • FSO Director
      • FSA/DSE Directors
      • Project Managers
  • 24. Performance Check Open the Performance Check Package to Project Management Introduction and answer the questions.
  • 25.
    • SMS
    • &
    • PM
    • Relationship
    SECTION 3
  • 26. SMS and PM Relationship
    • Objective:
      • Use the SMS to perform:
        • PM tasks
        • Subtasks
        • Procedures
  • 27. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 28. CHANGE ANALYSIS PHASE 1 TASK Detailed Impact Analysis Requirements Specifications and Impact Analysis Subphase
  • 29. References/Standards Skill(s): ANSI/IEEE Std 1042-1987 DFAS 8000.1-R Mil Std 973 Computer Expertise Input (s): Output (s): FSA-Impacted SCR FSA-Analyzed SCR System Documentation System Specification Detailed Impact Analysis Task (1 of 1) PURPOSE: To identify the impact on the system components due to the change in requirements .
  • 30. 2 Subtasks Detailed Impact Analysis Task Ancillary Requirements Identification Potential Risk Identification
  • 31. Detailed Impact Analysis Task
    • Ancillary Requirements Identification Subtask 1 of 2
      • Are associated with a change request
      • Are special requirements
      • Require the FSA to incur costs beyond those normally associated with completing a change request
  • 32. Detailed Impact Analysis Task
    • Potential Risk Identification
    • Subtask (2 of 2)
      • Associated with the changed requirements
      • Relate directly to the projected costs or staff hours
      • Are identified and documented for use in the Configuration Control Board and for Release Planning
  • 33. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 34. CHANGE ANALYSIS PHASE 4 TASKS SCR Size Estimate Preparation SCR Effort Estimate Preparation SCR Critical Computer-Resource Estimates Preparation SCR Firm Fixed Price (FFP) Preparation Resource Estimation Subphase
  • 35. FSA-Impacted SCR SCR Size Estimates References/Standards Skill(s): IFPUG Counting Practices Manual Computer Expertise Input (s): Output (s): System Documentation System/Subsystem Metrics Project Management SCR Size Estimate Preparation Task (1 of 4) PURPOSE: Produce an estimate for the size of the change to the system’s components due to the change in requirements.
  • 36. 3 Subtasks SCR Size Estimate Preparation Task Lines of Code Size Estimation Function Point Analysis Size Estimation Change Complexity Size Estimate Calculation
  • 37. Performance Check Open the Performance Check Package to SCR Size Estimate Preparation and answer the questions.
  • 38. Job Time Worksheet Skill(s) Computer Expertise SCR Effort Estimate Preparation Task (2 of 4) PURPOSE: Produce an effort estimation, which will be utilized by the Configuration Control Board to determine the initial cost, schedule and release date of the project. Input (s): Output (s): FSA-Impacted SCR SCR Size Estimates System Documentation System/Subsystem Metrics Project Management SCR Effort Estimates
  • 39. 3 Subtasks SCR Effort Estimate Preparation Task Lines of Code Effort Estimation Function Point Effort Estimation Change Complexity Effort Estimate Calculation
  • 40. Performance Check Open the Performance Check Package to SCR Effort Estimate Preparation and answer the questions.
  • 41. SCR Critical Computer
            • Computer Expertise
    SCR Critical Computer Resource Estimates Preparation Task (3 of 4) Input (s): Output (s): FSA-Impacted SCR System/Subsystem System Documentation Metrics Resources Estimates Purpose: To produce, record and coordinate critical computer resource estimates required to complete the requested change. Skill(s): Project Management Telecommunications Specialist Expertise
  • 42. 1 Subtask Critical Computer Resources Estimates Calculation
    • SCR Critical
    • Computer-
    • Resource
    • Estimation
    • Preparation
    • Task
  • 43. SCR CCR Estimates Prep. Task
    • CCR Estimates Calculation
    • Subtask (1 of 1)
      • Calculate CCR estimates
      • Document CCR estimates
      • Coordinate CCR estimates
  • 44. Performance Check Open the Performance Check Package to SCR Critical Computer-Resource Estimates Preparation Task and follow the directions.
  • 45. Ancillary Requirements Cost * References/Standards Skill(s):
            • Computer Expertise
    SCR Firm Fixed Price Preparation Task (4 of 4) Purpose: To produce, record and coordinate a Firm Fixed Price required to satisfy all requirements of the SCR Input (s): Output (s): FSA-Impacted SCR SCR Effort Estimates Project Management Subcontract Management, if appropriate Software Subcontract Management Scenario, if appropriate Estimated SCRs Firm Fixed Price Estimate Summary Sheet FSO Hourly Rate Critical Computer Resources Estimates * * These are used only with approval by the business manager
  • 46. 5 Subtasks Effort Estimates Calculation Firm Fixed Price Calculation SCR Firm Fixed Price (FFP) Preparation Task Critical-Computer-Resources Estimates Calculation * Ancillary Requirements Cost Calculation * Subcontract Cost Estimation Determination * * Perform these subtasks only with the approval of the business manager.
  • 47. SCR FFP Preparation Task
    • Effort Estimates Calculation
    • Subtask (1 of 5)
      • Calculate the costs associated with the effort estimates
      • Multiply the effort estimate by the established FSO hourly rate for “direct” labor
  • 48. SCR FFP Preparation Task
    • CCR Estimates Calculation
    • Subtask * (2 of 5)
      • Determine the cost associated with each CCR needs estimate.
    • * Perform this subtask only with the approval of the business manager.
  • 49. SCR FFP Preparation Task
    • Ancillary Requirements Cost Calculation
    • Subtask * (3 of 5)
    • Determine the cost of each ancillary requirement and calculate the cumulative cost.
    • * Perform this subtask only with the approval of the business manager.
  • 50. SCR FFP Preparation Task
    • Subcontract Cost Estimation Determination Subtask * (4 of 5)
      • Determine estimated costs of subcontracted work associated with the SCR
    • * Perform this subtask only with the approval of the business manager.
  • 51. SCR FFP Preparation Task
    • Firm Fixed Price Calculation
    • Subtask (5 of 5)
      • Produce the FFP for the SCR based on sum of:
        • Size and effort
        • CCRs
        • Ancillary Requirements
        • Subcontractor Cost Estimates
  • 52. Performance Check Open the Performance Check Package to SCR Firm Fixed Price Preparation Task and follow the directions.
  • 53. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 54. 2 TASKS Proposed Release Package Creation Proposed Release Package Distribution Planning CHANGE APPROVAL AND PLANNING PHASE
    • Proposed
    • Release
    • Package
    • Development
    • Subphase
  • 55. Proposed Release Package Creation Task (1 of 2) Purpose: To identify work level available and effort to support customer requirements and to include SCRs projected for completion in a scheduled release Input (s): Output (s): Estimated SCRs Proposed Release Package
  • 56. 1 Subtask Proposed Release Package Creation Task Release Package SCR List Determination
  • 57.
    • Release Package SCR List Determination Subtask (1 of 1)
      • Develop a Proposed list of SCR’s to be included in a release
      • Reflect customer and FSA priorities
    Proposed Release Package Creation Task
  • 58. Performance Check Open the Performance Check Package to Proposed Release Package Creation Task and follow the directions.
  • 59. Proposed Release Package Distribution Task (2 of 2) Purpose: To reproduce the release package and distribute it to all appropriate groups and individuals for review Input (s): Output (s): Proposed/Approved Release Package Proposed/Approved Release Package References/Standards: Systems Management Policy - SM-05
  • 60. 3 Subtasks Proposed Release Package Distribution Task Release Package Reproduction Release Package Distribution Release Package Coordination Proposed Release Package Distribution Task
  • 61. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 62. CHANGE DEVELOPMENT PHASE Release Planning Subphase 3 TASKS Release Package Analysis Resource Availability Determination Software Development Plan (SDP) Preparation
  • 63. References/Standards: Skill(s) : Output (s): Software Subcontract Management Scenario DFAS Regulation 8000.1-R Release Ancillary Requirements Consolidation Release Package Analysis Task (1 of 3) Purpose: To analyze release package to identify work required to satisfy release requirements and to begin preparation of the Software Development Plan Release Critical Computer Resource Consolidation Release Planning Milestones Release Risk Consolidation Release Staff Hours Consolidation Computer Expertise Project Management Input (s): Funding Documents, if available Proposed/Approved Release Package FSA-Estimated SCR
  • 64. 5 Subtasks Release Package Analysis Task Release Package Effort Evaluation Release Package Critical Computer-Resources Evaluation Release Package Risk Evaluation Release Package Ancillary Requirements Evaluation Release Plan Milestones Preparation
  • 65. Release Package Analysis Task
    • Release Package Effort Evaluation Subtask (1 of 5)
      • Total the effort estimates for each SCR
      • Use list of direct labor categories in SMS
      • Create schedule and billing
  • 66. Release Package Analysis Task
    • Release Package CCR Evaluation Subtask (2 of 5)
    • Total the critical computer resources for each SCR
    • This total may only be utilized with the approval of the business manager
  • 67. Release Package Analysis Task
    • Release Package Risk Evaluation Subtask (3 of 5)
      • Identify cost, resource, schedule, and technical risks associated with:
        • Design
        • Programming
        • Testing
        • Documentation
        • Implementation
  • 68. Release Package Analysis Task
    • Release Package Ancillary Requirements Evaluation
    • Subtask (4 of 5)
      • Identify ancillary requirements the release package
  • 69. Release Package Analysis Task
    • Release Plan Milestones Preparation Subtask (5 of 5)
      • Consists of:
        • Preparing a plan of action and milestones used to develop SDP
        • Reviewing and modifying the SQAP
        • Reviewing and modifying the SCMP
        • Reviewing and modifying plans associated with the release, e.g., - test plans.
  • 70. Performance Check Open the Performance Check Package to Release Package Analysis Task and follow the directions and answer the questions.
  • 71. Resource Availability Determination Task (2 of 3) Purpose: To determine the availability of resources to satisfy the direct labor requirements of the release Input (s): Output (s): Critical Computer-Resources Staff Hours Availability Calendar FSA Staffing Level Implementation Date Master Labor Agreement Resource Non-Availability Schedules Availability Determination Determination Skill(s) : Computer Expertise Project Management
  • 72. 2 Subtasks Resource Availability Determination Task Staff-Hours Availability Determination Critical Computer Resources Availability Determination
  • 73. Resource Availability Determination Task
    • Staff-Hours Availability Determination Subtask (1 of 2)
      • Analyze staffing patterns and availability during the time frame for the scheduled release
      • Determine staff-hours availability for carrying out the requirements of the release package
      • Categories are same as those covered in the Release Package Analysis Task
  • 74. Resource Availability Determination Task
    • CCR Availability Determination Subtask (2 of 2)
      • Analyze CCR availability during the time frame for the scheduled release
      • Determine CCR availability for carrying out the requirements of the release package
      • Categories are same as those covered in the Release Package Analysis Task
  • 75. Performance Check Open the Performance Check Package to Resource Availability Determination Task and follow the directions.
  • 76. Skill(s) : Computer Expertise Software Development Plan (SDP) Preparation Task (3 of 3) Purpose: To develop a Software Development Plan which identifies the tasks and establishes milestones for the release Input (s): Output (s): Software Development Plan Proposed/Approved Release Package Modified Software Configuration Management Plan Modified Software Quality Assurance Plan Release Staff Hours Evaluation Release Ancillary Requirements Review Release Critical Computer- Resources Evaluation Release Risk Review Project Management
  • 77. Skill(s) : Computer Expertise Software Development Plan (SDP) Preparation Task Con’t Input (s) Output (s): Software Development Plan Release Planning Milestones Modified Test and Evaluation Master Plan Software Integration Test Plan Software Acceptance Test Plan Software Qualification Test Plan Statement of Work Package Project Management
  • 78. 19 Subtasks Software Development Plan (SDP) Preparation Task SDP Project Overview Completion SDP Organization and Responsibility Objectives Identification SDP Software Life Cycle Selection SDP Procedures, Methods, and Standards Identification SDP Release Estimates Recording SDP Software Products to be Delivered Identification
  • 79. Subtasks con’t Software Development Plan (SDP) Preparation Task SDP Items Required from the Customer Identification SDP Items Required from External Organizations Identification SDP Ancillary Requirements Identification SDP Release Scheduling SDP Risks and Concerns Identification and Assessment SDP Plans for Software Engineering Facilities and Support Tools
  • 80. Subtasks con’t Software Development Plan (SDP) Preparation Task SDP Software Quality Assurance Plan SDP Software Configuration Management Plan SDP Test Plans SDP Statement of Work Documentation SDP Coordination SDP Release Planning Audit Trail Documentation SDP Approval
  • 81. SDP Preparation Task
    • SDP Project Overview Completion Subtask (1 of 19)
      • Identify and record:
        • The purpose of the release
        • The scope of the release
        • The goals and objectives of the release
  • 82. SDP Preparation Task
    • SDP Organization and Responsibility Objectives Identification
    • Subtask (2 of 19)
      • Identify:
        • Approval authority for SDP
        • Project manager
        • Any external org. with interest in release
        • Project personnel
        • Interfacing groups
  • 83. SDP Preparation Task
    • SDP Software Life Cycle Selection Subtask (3 of 19)
      • Select the system scenario appropriate for the type of work being accomplished
  • 84. SDP Preparation Task
    • SDP Procedures, Methods and Standards Identification
    • Subtask (4 of 19)
      • Identify:
        • Management and technical controls
        • Methodologies, models and tools
        • Verification and validation procedures
        • Tracking and oversight
  • 85. SDP Preparation Task
    • SDP Release Estimates Recording Subtask (5 of 19)
      • Consolidate and record:
        • Size estimates
        • Effort estimates
        • Critical computer resources estimates
        • Firm Fixed Prices
  • 86. SDP Preparation Task
    • SDP Software Products to be Delivered Identification
    • Subtask (6 of 19)
      • Consolidate and record
        • The lists of affected Configuration Items
        • Other software products for all SCRs in the release
  • 87. SDP Preparation Task
    • SDP Items Required from the Customer Identification
    • Subtask (7 of 19)
      • Consolidate and record:
        • All the items that the customer is still required to provide to complete the release
  • 88. SDP Preparation Task
    • SDP Items Required from External Organizations Identification
    • Subtask (8 of 19)
      • Consolidate and record:
        • All the items that are required from groups outside the FSA (except the customer) to complete the release
  • 89. SDP Preparation Task
    • SDP Ancillary Requirements Identification Subtask (9 of 19)
      • Consolidate and record:
        • Ancillary requirements from each SCR in the release
  • 90. SDP Preparation Task
    • SDP Release Scheduling
    • Subtask (10 of 19)
      • Identify, consolidate, and record WBS
      • Assign or compute duration for each task
      • Document assumptions in scheduling process
      • Identify date dependencies between tasks
      • Assign all tasks to specific personnel
      • Document the consolidated schedule
  • 91. SDP Preparation Task
    • SDP Risks and Concerns Identification and Assessment
    • Subtask (11 of 19)
      • Consolidate and record:
        • The risk assessments from the proposed release review
  • 92. SDP Preparation Task
    • SDP Plans for Software Engineering Facilities and Support Tools
    • Subtask (12 of 19)
      • Identify software engineering facilities and support tools required for the release
      • Refer to CCR Evaluation and CCR Availability Tasks
      • Arrange with external activities to fulfill needs
      • Document the plans
  • 93. SDP Preparation Task
    • SDP Software Quality Assurance Plan Subtask (13 of 19)
    • Attach or refer to the Software Quality Assurance Plan for this release
  • 94. SDP Preparation Task
    • SDP Software Configuration Management Plan
    • Subtask (14 of 19)
      • Attach or refer to the Software Configuration Management Plan for this release
  • 95. SDP Preparation Task
    • SDP Test Plans
    • Subtask (15 of 19)
      • Attach or refer to the test plans for this release
  • 96. SDP Preparation Task
    • SDP Statement of Work Documentation Subtask (16 of 19)
      • Attach statement of work documents relating to any subcontracted work
  • 97. SDP Preparation Task
    • SDP Coordination
    • Subtask (17 of 19)
      • Coordinate completed SDP with all affected groups and individuals
  • 98. SDP Preparation Task
    • SDP Release Planning Audit Trail Documentation
    • Subtask (18 of 19)
      • Archive all documents used in the preparation of the SDP
  • 99. SDP Preparation Task
    • SDP Approval
    • Subtask (19 of 19)
      • Submit the finalized SDP for approval
  • 100. Performance Check Open the Performance Check Package to SDP Modification Task and follow the directions.
  • 101.
    • Project
    • Tracking and
    • Oversight
    SECTION 4
  • 102. Project Management Introduction
    • Goals for Software Project Tracking and Oversight (SPTO)
      • PM:
        • Tracks actuals vs. estimates recorded in SDP
        • Takes corrective action
        • Manages to closure
        • Gets agreement and commitment on changes to plans from all affected groups and individuals
  • 103. Project Management Introduction
    • COMMITMENT TO PERFORM (SPTO):
      • Project software manager is designated to be responsible for:
        • Negotiating commitments
        • Developing the project’s SDP
        • Defining the project’s software activities
      • PM follows a written organizational policy for planning and managing a software project
  • 104. Project Management Introduction
    • ABILITY TO PERFORM (SPTO):
      • SDP is documented and approved
      • Responsibilities for developing work products and performing SQA activities are assigned
      • Adequate resources and funding are provided
      • Managers are trained in managing the technical and personnel aspects of the s/w project.
      • Software managers receive orientation in the technical aspects of the software project
  • 105. Project Management Introduction
    • MEASUREMENT AND ANALYSIS (SPTO):
      • Determine the status of:
        • Software planning
        • Tracking
        • Oversight activities
  • 106. Project Management Introduction
    • VERIFYING IMPLEMENTATION (SPTO):
      • PM reviews the activities for SPTO with:
        • Senior management (periodic basis)
        • All affected groups (periodic and event-driven basis)
      • SQA reviews and/or audits (per SQAP):
        • Activities
        • Work products
  • 107. References/Standards: Skill(s): Computer Expertise Tracking and Oversight Task PURPOSE: To perform ongoing tracking and oversight functions in order to keep management informed as to progress of the release Input (s): Output (s): Deliverable Review Proceedings Periodic Review Proceedings Software Development Plan Project Management Amended Software Development Plan Periodic Review Proceedings Release Metrics Data Deliverable Review Proceedings
  • 108. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 109. CHANGE DEVELOPMENT PHASE 2 TASKS Detailed Design & CSU Specs Tracking and Oversight Impact Analysis Review
    • System/Subsystem
    • Design & CSU
    • Specifications
    • Development
    • Subphase
  • 110. Skill(s) : Input (s): Output (s): FSA-Impacted SCR Impact Analysis Review Task (1 of 2) Purpose: To review the impact analysis to determine its completeness, correctness and currency FSA-Impacted SCR Development Subject Matter Manager (SMM) Expertise Subject Matter Expertise Systems Design Testing
  • 111. 2 Subtasks Impact Analysis Review Task Ancillary Requirements Review Potential Risk Review
  • 112. Impact Analysis Review Task
    • Ancillary Requirements Review
    • Subtask (1 of 2)
      • Review the ancillary requirements associated with a change request
  • 113. Impact Analysis Review Task
    • Potential Risk Review
    • Subtask ( 2 of 2)
      • Review the potential risks associated with the system change request
  • 114. Tracking and Oversight Task
    • WHAT IS TRACKING AND OVERSIGHT?
      • Review project plan
      • Adjust plans as necessary
      • Report status
  • 115. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 116. Deliverable Review Proceedings References/Standards: Skill(s): Computer Expertise Tracking and Oversight Task PURPOSE: To perform ongoing tracking and oversight functions in order to keep management informed as to progress of and changes to the release Input (s): Output (s): Periodic Review Proceedings Software Development Plan Project Management Amended Software Development Plan Periodic Review Proceedings Release Metrics Data Deliverable Review Proceedings
  • 117. 7 Subtasks Project Tracking and Oversight Task Periodic Review Preparation and Planning Periodic Review Execution Periodic Review Reporting Periodic Review Follow-Up SDP Update and Coordination SDP Deliverable(s) Completion Recording SDP Deliverables Review
  • 118. Tracking and Oversight Task
    • Periodic Review Preparation and Planning
    • Subtask (1 of 7)
      • Collect, compare and roll up Configuration Item Status data
      • Analyze deviations between actual and estimated data
      • Notify management
  • 119. Tracking and Oversight Task
    • Periodic Review Execution
    • Subtask (2 of 7)
      • Develop corrective actions for deviations including:
        • Changing the schedule
        • Changing resources
        • Changing scope
        • Lowering the quality (not recommended)
      • Develop course of action for completing
      • proposed corrective actions
  • 120. Tracking and Oversight Task
    • Periodic Review Reporting
    • Subtask (3 of 7)
      • Record the results of the Periodic Review including:
        • Minutes of the meeting
        • Action items identified during the meeting
  • 121. Tracking and Oversight Task
    • Periodic Review Follow-Up
    • Subtask (4 of 7)
      • Determine status of each tasking or action item that was previously identified and recorded during the review session
  • 122. Tracking and Oversight Task
    • SDP Update and Coordination
    • Subtask (5 of 7)
      • Identify and coordinate changes to the SDP
      • Obtain approval of proposed SDP amendments
      • Implement approved amendments in the SDP
      • Publish amended SDP
  • 123. Tracking and Oversight Task
    • SDP Deliverables Completion Recording Subtask (6 of 7)
      • Identify completed deliverables
      • Collect and record completion data
      • Report completion of deliverables to management
  • 124. Tracking and Oversight Task
    • SDP Deliverables Review
    • Subtask (7 of 7)
      • Prepare and plan customer meeting
      • Meet with the customer
      • Record results of the customer meeting
      • Follow up on tasking from customer meeting
  • 125. Performance Check Open the Performance Check Package to Tracking and Oversight Task and answer the questions.
  • 126. SOFTWARE PROCESS ARCHITECTURE SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES CHANGE INITIATION UNIT CODING & UNIT TESTING (UT) System/Subsystem Design & CSU SPECIFICATIONS DEVELOPMENT DETAILED UT DEFINITION DETAILED SAT DEFINITION CHANGE DEFINITION DETAILED SQT DEFINITION DETAILED SIT DEFINITION SYSTEM DOCUMENT MODIFICATION CHANGE DEVELOPMENT CHANGE IMPLEMENTATION SIT EXECUTION & CERTIFICATION SQT EXECUTION & CERTIFICATION SAT EXECUTION & CERTIFICATION CHANGE DEVELOPMENT (CONT’D) REQUIREMENTS SPECIFICATION & IMPACT ANALYSIS DESIGN PREPARATION SYSTEM/ SUBSYSTEM DESIGN RESOURCE ESTIMATION ANALYSIS PREPARATION CHANGE (SCR) INITIATION, REVIEW, APROVAL, & RANKING PROBLEM (PTR) DOCUMENT- ATION & DISPOSITION CHANGE/ PROBLEM DEFINITION FUNCTIONAL REQ’MENTS DEFINITION CHANGE ANALYSIS Release Planning CHANGE APPROVAL & PLANNING PROPOSED RELEASE PACKAGE DEVELOPMENT RELEASE PLANNING ITSA PREP & ACCEPTANCE RELEASE PLANNING DEVELOPMENT ITSA PREP. & ACCEPTANCE CCB REVIEW & APPROVAL PERIODIC PROCESSES SOFTWARE BASELINE AUDITS RELEASE IMPLEMEN- TATION POST RELEASE IMPLEMEN- TATION REVIEW SQA PROCESS REVIEWS POST RELEASE PHYSICAL CONFIG. AUDIT
  • 127. Certification Task CHANGE DEVELOPMENT PHASE 1 TASK SIT/SQT/SAT Certification SIT, SQT and SAT Execution and Certification Subphases
  • 128. Skill(s) : Output (s):
    • SIT/SQT/SAT Certification
    • Task
    • Purposes:
    • SIT - To ensure that all various requirements up
    • to this point have been met
    • SQT - To validate that the system has met the
    • requirements of the SQT, completed quality
      • assurance reviews and audits and that release management is ready to pass to the acceptance phase
    • SAT - The final check before release to the field for implementation
    CMIS Certification Entry Project Management Input (s): Test Analysis Report Test Discrepancy Report (TDR) Test Results
  • 129. 1 Subtask Certification Task Test Project Officer Certification
  • 130. Certification Task
    • Test Project Officer Certification
    • Subtask ( 1 of 1)
      • Test project officer must certify test results prior to subsequent testing phases beginning or proceeding to implementation
      • Test project officer receives the test certification and quality assurance certification and then makes the final determination for this subphase
  • 131. CONGRATULATIONS YOU HAVE SUCCESSFULLY COMPLETED THE PROJECT MANAGEMENT COURSE