Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 1 4/19/2003 2) Analyzing the Job to be Done

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 2 4/19/2003 Outline Fundamentals of Planning Understanding the Need Understanding the System Identifying the Software Products Summary

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 3 4/19/2003 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 4 4/19/2003 Fundamentals of Planning

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 5 4/19/2003 What Should be Planned Organization of the software project Cost and Schedule Staffing Strategy High level process to be followed Tools to be used Risk Management procedures Others, as determined by company policy, standards or customer requirements

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 6 4/19/2003 Why Plan at all? Forces you to answer a lot of questions that would otherwise be left unanswered Communicates your plans to concerned parties - your staff, other organizations, subcontractors Provides a common framework from which all participants can make their individual plans How will we do this?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 7 4/19/2003 Why Plan at all? (continued) Helps to convince management and/or the customer that you have the ability to manage the project It documents assumptions, contractual understandings, mutual agreements, etc. It helps you to not forget what you planned It helps you manage risks by recording your rationale, backup plans, expectations, etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 8 4/19/2003 Risks of a Documented Plan The tendency to assume that if it is not in the Plan it is not important –Other plans may also be important You may treat the Plan as a Law, NEVER to be violated –Common sense must always prevail You might treat the Plan as a deliverable to meet a requirement rather than as an aid to management and communication

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 9 4/19/2003 Risks of a Documented Plan (continued) You may change the Plan and fail to communicate the changes to people who need to know Customer or internal approval requirements might inhibit needed changes –Every plan should be reviewed and (usually) updated from time to time

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 10 4/19/2003 A Good Plan is a Living Document Initial Planning etc. initial plan Periodic Review and Update Periodic Review and Update revised plan The Plan is a communication and management tool

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 11 4/19/2003 A Plan is Static - Planning is Dynamic A plan is rarely followed exactly as written As you progress, you learn more Keeping the plan up to date keeps everyone synchronized and reduces the chances of miscommunication, etc. Plans need to reflect what you know today, not what you didn’t know when you wrote the plan.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 12 4/19/2003 Dealing with the Realities of Formal Change Approvals Avoid excessive detail in the Plan –Put it in a supplement to the formal plan Incorporate plans for changing the Plan –So that certain changes require little or no formal approval Establish trust with customers by keeping commitments

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 13 4/19/2003 The Plan within a plan Software Development Plan (formal document) software development plan Software Standards and Procedures WBS Policies Facilities Estimates Staffing plan Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 14 4/19/2003 Understanding the Need

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 15 4/19/2003 What Do You Need to Begin Planning? You must start by making sure you know what you are supposed to do I.e., the first step of planning is to make sure you have the information needed to plan And the first thing to learn about is the customer need

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 16 4/19/2003 Two Key Items - Find Them or Create Them Software Statement of Work (SOW) –What to do and what to deliver –Often the basis for a contract Software Requirements –What the software is required to do and how you will test to see if it is correct What happens if these are missing?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 17 4/19/2003 Twp Useful Items on a Large Project System Design Description –How the overall system works what the parts of the system are how they interface which parts of the system are to be implemented in software what requirements are allocated to what parts of the system  especially the software parts Requirements Trace –From software to system to customer and back

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 18 4/19/2003 Requirements Trace Tie it all Together How These Items Relate INPUT PRODUCT What to Do What to Deliver Statement of Work System Specs Requirements Allocation, Identify the Products Produce the Product (Using the Software Process) Characterize the Product Software Requirements

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 19 4/19/2003 Some Important Considerations Make sure you know the views of all “customers” relative to these items End User Sponsor Intermediary You

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 20 4/19/2003 Other Important Considerations Make sure you know who controls changes to each requirement, specification, statement of work, etc. –And make sure they are motivated to inform you of changes Understand key dependencies on other parts of the system

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 21 4/19/2003 A Plan Should Communicate Who the customers are –Sponsor, end user, intermediaries Their needs, expectations, perspectives & degree of influence Commitments made to them Risks involved in successful completion of the project

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 22 4/19/2003 A Plan Should Document the Customer’s Need So that everyone operates from the same set of assumptions and understandings To make sure that the needs are well understood and do not conflict with each other

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 23 4/19/2003 Identify Stake Holders Legal Dept End User Software Manager System Engineer Program Manager Champion

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 24 4/19/2003 Align the goals of all Stake Holders Goal

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 25 4/19/2003 Use Iterative Approaches when Needs are Not Firm Changes are received and processed here (  )      

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 26 4/19/2003 Statement of Work What work is to be performed? What products are to be delivered? Requirements for the project and the process Often used as the basis for a contract because it indicates specific things to be done

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 27 4/19/2003 SOW may optionally include... When (schedule, delivery dates) Costs (budgets, spending profile) Customer imposed standards, methods, tools or even processes to be used Recommendation: document what is NOT needed in a SOW supplement or memorandum of understanding.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 28 4/19/2003 Example SOW Develop a spreadsheet program in the C++ language to run under under Windows 2000 Deliver the following: –Source code –User’s guide –Load module of the spreadsheet program –Operator’s guide –Installation guide Develop using workmanlike processes and methods [i.e., contractor’s choice but must be competent] Spreadsheet should meet the requirements contained in a separate specification

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 29 4/19/2003 Software Requirements May be Defined at Various Levels of Detail Statement Develop a spreadsheet tool that is better than Excel but looks and functions like it Specification In response to the “sort” command, the spreadsheet shall do the following: ……..

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 30 4/19/2003 Alternative Ways to Document the Requirements Use Cases User pays bill … User inquires about account balance User requests cash withdrawal … Prototype Develop a model of key system behaviors User Documents Develop user documents first, use as basis for tests

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 31 4/19/2003 Typical Requirements Flow-Down from System to Subsystem to SW 3000 pounds 0-60mph in 9 sec Transmission System Analysis & Design Allocated Requirements Automobile Drive TrainChassisEngine 100 lbs 50 ft# torque 50 lbs2000 lbs500 lbs 250 hp... Original Requirements Engine Control SW Requirements

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 32 4/19/2003 Test Requirements An indication of how the product will be tested and what constitutes acceptable performance Definition If you don’t know how you will test it, you don’t have a good requirement.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 33 4/19/2003 An Example Test Requirement The spreadsheet must pass the standard spreadsheet test suite defined by TESTSRUS corporation The spreadsheet shall be run through each command and the screens will be inspected for proper color, speed, and readability The spreadsheet help command will be applied for each command listed in appendix 2 of the requirements statement and the resulting help information must be understandable by at least 80% of a panel of novice spreadsheet users...

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 34 4/19/2003 Rqmt 2 Rqmt 3 Rqmt 1 Electrical Rqmt a Rqmt b Rqmt c Rqmt d Mechanical Rqmt a Rqmt b Rqmt c Rqmt d Software Rqmt a Rqmt b Rqmt c Rqmt d Allocation Process Requirements Trace Mechanism Needed so you can connect the requirements the software is designed to address to the original requirements as specified by a system designer or customer

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 35 4/19/2003 Typical Risks Identified Cannot decide what to do / deliver Requirements are too vague Technology may not be adequate Schedules may not be feasible Costs may be prohibitive or uncertain Domain knowledge may be lacking –I.E., We don’t know how to do it –Need to go outside for information Tests not stated or not understood

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 36 4/19/2003 Understand the System

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 37 4/19/2003 Software Does Not Happen in a Vacuum Software System Larger System or Program

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 38 4/19/2003 Software in a Larger Context Software runs on hardware –Which is usually part of a system –That solves the overall customer problem To understand the big picture, you need to understand the system, its lifecycle, and where software fits

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 39 4/19/2003 Lifecycle The period of time during which a process occurs. Generally, this begins with an initial concept and ends with a final termination. Any kind of process has a lifecycle We are concerned with lifecycles for product development

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 40 4/19/2003 Example of a Project Lifecycle containing SW Phase 2Phase 3Phase 4Phase nPhase 1.. c: Software Lifecycle b: Software Lifecycle d: Software Lifecycle a: Software Lifecycle a: Software to simulate the system and select the right design b: Software to test hardware c: Software to test software d: Maintenance software

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 41 4/19/2003 Concerns Associated with Systems Containing Software Warranties Maintenance Documentation Support Hardware Procedures Standards Contracts etc. These things are often ignored when discussing software development lifecycles, but they are important for the systems of which software is a part.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 42 4/19/2003 Software Manager’s Initial Responsibilities in a System Lifecycle Know what it is (what model) Know where you are (what phase) Know what was supposed to be done in the previous phase Know what was actually done in the previous phase

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 43 4/19/2003 Typical Software Problems for a Product Development Phase Prototype software is planned for use in a production system, but it lacks the appropriate specifications, documentation, testing, etc. Software specifications were not produced, even though the upcoming phase assumes they have been Continued...

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 44 4/19/2003 Typical Software Problems for a Product Development Phase (continued) System requirements are still highly unstable, even though they are supposed to be firm Program is staffed by people who lack experience in a product development phase -- don’t appreciate need for discipline, etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 45 4/19/2003 Software Manager’s Later Responsibilities in a System Lifecycle Understand the overall structure of the system Understand what software needs to be written Identify the software products or configuration items

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 46 4/19/2003 Identify the Software Items (aka Software Products or Software Configuration Items)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 47 4/19/2003 What Software Needs to be Written? This question is not always as simple as it sounds Sometimes there are choices –Hardware or software solution –Purchased or developed software –Reused or new software And sometimes software is hidden from view

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 48 4/19/2003 Project Lifecycle containing Software Phase 2Phase 3Phase 4Phase nPhase 1.. c: Software Test Facility b: Hardware Test Software d: Maintenance Software a: Simulator

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 49 4/19/2003 How Does the Software Fit Within the System Architecture? What to put in software and where it is found are very important system design issues It is common to under-scope the amount of software, especially if no software people are involved with the system design

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 50 4/19/2003 Typical System Architecture Subsystem (segment) Subsystem (segment) Subsystem (segment) Product or Item (configuration item) Product or Item (configuration item) Product or Item (configuration item) System Subsystem (segment)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 51 4/19/2003 Example 1 Display Radio Functions Keyboard Processor and Memory System Software Application Software Cellular Telephone Processing Unit

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 52 4/19/2003 Example 2 DisplayPrinterKeyboard Processor and Memory System Software Power Supply Personal Computer System Unit

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 53 4/19/2003 Software Notes A typical large system may have MANY software components Some designers may combine hardware and software elements into a single component After identification of the software, the next key decision is to organize it into components, which are often called software products or software items or software configuration items This is an important decision that software managers and technical staff must participate in deciding

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 54 4/19/2003 What Is a Software Product or Configuration Item? A part of the software that will typically have one or more of these attributes: –Developed independently –Tested independently (test cases, test procedures, etc.) –Sold separately (part number, upgrades, price, etc.) –Maintained as a separate unit –Supported with its own set of documentation

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 55 4/19/2003 The Litmus Test The answer to this question may depend on specific details of your project Do you want to manage and track this part of the software separately?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 56 4/19/2003 Considerations when Selecting Software Products What makes logical sense, given the system design? How many contractors will build / manage it? –Ideally, one contractor per product How many target processors? How many programming languages? What is the most sensible maintenance approach?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 57 4/19/2003 Considerations when Selecting Software Products (continued) Schedules / delivery dates –Several releases of a product vs multiple products Size –Is it manageable? Interfaces to other products –Interfaces should be simple between different software products

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 58 4/19/2003 Selection of Programming Languages and Tools Pick something the developers are familiar with Pick something that fits the problem –Don’t use Cobol for real-time systems Beware of new tools and languages –Your project will pay the cost of training the developers to use the new tools and languages –This can add significant risk

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 59 4/19/2003 Summary Analyzing the Job to be Done Software must be developed in a planned manner A plan should reflect the current knowledge of the project team to serve as a valid reference for all The planning activity begins with identification of all stake holders in the project & by understanding their requirements, expectations & degree of influence

Copyright © , Dennis J. Frailey, All Rights Reserved Day 1, Part 2, Page 60 4/19/2003 Summary Analyzing the Job to be Done Understand the need –What do they want? Understand the system –What is its lifecycle? –What is the architecture of the system? –Where does software fit? Identify the software products Identify the programming language(s)