Introduction Take notes for the software management and write down the knowledge points in each chapter

Software Management

Lecture 1

Engineering Problem


Software Management Process

Lecture 2

Key to software management

How design a software managment

Solution

SPQR

Secure + Product + Quality + Resource
One change, all Change

Success Formula

Success = f_n(S,Q,F,OI)

Decomposition

Validation

Software Analysis

Lecture 3

note
unit case is necessary, it is a very very big deal.

Seven Phases Of Software Development

seven phases
release

Popular Development Mode

How to write product requirement

note
when you know requirement, you know test cases

Lecture 4

Engineers should think from the user’s point of view

Can be gained in following ways

Relationship between PM and Engineer

Conflict between PM and Engineer

Effect

A major conflict between Engineering and Product Management will in many cases exist and have the most deleterious effect on the Project.

Resolve Conflict

1. Determine the stage the company and product is as a whole
   Stage 1: Startup
   Stage 2: Operational Excellence
   Stage 3: Market Driven
   Stage 4: Finance Driven
2. Determine who owns the customer facing requirements and who owns the technical and derived requirements.
3. Determine who owns:
   a. Cost
   b. Schedule
   c. Quality
   d. Functionality
4. Validate performance requirements.

Method For Analysis

Step 1. Draw a Context Diagram
a. draw a circle, inside is the system, outside is the environment
b. outside the circle draw the inputs, outputs, source and destination

Step 2. Identify the high level functions to be performed or behavior to be exhibited.

Step 3. Identify the flow of data between these functions.

Step 4. Define the major data entities named on the context chart and the high level functions.

Step 5. Identify the quality requirements:

1. Response Time
2. System Availability
3. Throughput Capacity
4. Security Requirements
5. Integrity
6. Auditability
7. Disaster Recovery
8. Resource Load

Step 6. Arrive at a preliminary cost and schedule estimates

Step 7. How does this new system or enhancement fit into the organization’s strategic plan?

Context Diagram

1. the single most important piece of documentation for the project is the Context Diagram
2. Its purpose is to show the scope of the project
3. The Context Diagram is made up of one bubble with the name of the System inside
4. It shows all the inputs and all the outputs.
5. The Context Diagram is an important product of the requirements specification step for it presents to all interested parties a view of the system that can be understood and agreed to.

Product Requirements Document

1. The most important document in the entire development process.
2. It serves as a contract between Engineering and Product Management.
3. It is the key transition in the entire development process.
4. The software project manager must ensure that this document is developed, reviewed and approved in a timely manner.

Who should create this document?

1. Primary Responsibility: Product Mgr
2. Secondary Responsibility: Software Engr,Test Engr

Why do you need a detailed PRD?

1. preliminary acceptance/rejection
2. vehicle for communication
3. feasibility
4. management OK/constraint

PRD

Requirements Management

How to Plan a Project

Initial Estimate

Although it is most uncertain, the initial estimate is, in many ways, the most important. It occurs at such an early state (after the MRD) that the temptation is strong to ignore it; to do so is a mistake. Making the initial estimate has the welcome side effect of leading the manager to consider the various factors bearing on the size and complexity of the development task. The initial estimate seeds the estimation process, serving as a reference value with which to compare later estimates.

Scheduling and Costing

Scheduling and Costing will continue throughout the life of the project:

1. Preliminary high level schedules and costs based on the MRD 2. Detailed schedules and costs based on the detailed analysis and product specifications
2. Revised schedules and costs based on the work being accomplished

   Scheduling Steps

3. Assign Engineers to the tasks
4. Assign duration to tasks
5. Determine which function needs to be done in what order
6. Layout the end to end schedule
7. Go through several cycles of:
   a. Looking at the task that represents the critical path
   b. Move resources or tasks to reduce the critical path

Organizational Alignment

Before the project begins you should have the following in place:

1. High level product functionality
2. Decomposed tasks list (based on process)
3. Delivery date and some rough milestone dates
4. High resource allocation to tasks
5. Defined roles, responsibilities and expectations
6. Physical resources

How would the following scenarios affect the development process?

1. Time-to-Market
2. Developing a Market
3. Research and Development
4. Establishing Market Leadership 5. Establishing a Product Family

How would the software engineering team’s background and environment affect the project:

1. Complex, new technology
2. Straightforward and known technology
3. Somewhere in the middle

Software Project Plan

Purpose

Describe or reference the specific mechanisms and subordinate plans to complete the development project to include schedules, responsibilities, methodologies, tools testing, guidelines. The plan clearly states the reporting mechanisms and quality goals. It is an Organizational Level Plan not to be confused with the lower level detail project plan

Points

1. A detailed plan cannot be created until AFTER the detailed requirements have been refined, reviewed and approved.
2. A high level plan (using the template) based on organizational practices, prior project histories and the MRD CAN be created.
3. This high level plan will be REFINED (just as the MRD is refined into a Detailed Requirements Specification) and reviewed for approval purposes.

Software Project Plan Template

1. System Overview. Briefly state the purpose of the system and its major
   components

2. Product and Project Deliverables

3. MajorActivityScheduleAndMilestones
   a. Whendoesitstart
   b. When does it end
   c. What does it produce
   d. Sequential relationship to other activities

4. Resources
   a. Hardware b. Software c. Facilities

5. Risks
   a. Whatarethey
   b. How will you monitor them
   c. What will you do if they occur

6. Statusing Method

7. Software Engineering
   a. ProjectOrganizationalStructure
   b. Personnel and their RR&E
   c. Design and Coding Standards
   d. Development Techniques And Methodologies Used In
   S/WRequirementsAnalysis
   Preliminary Design
   Detailed Design
   Coding
   e. Reviews

8. SoftwareTesting
   a. OrganizationalStructure
   b. Personnel and their RR&E
   c. TestApproach
   d. TestPlanningAndConstraints

9. Software Configuration Management and Release
   a. Organizational Structure
   b. Personnel
   c. Configuration Control

   1. Flow Of Configuration Control
   2. Reporting Documentation
   3. Review Procedures
   4. Status Accounting

At this stage you should have (or performed) the following
a. A baselined Product Specification (Marketing)
Third Party Software (and costs)
Preliminary costs and schedules
A go / no-go decision
b. A baselined Software Requirements Specification
Detailed development plan
Detailed estimated costs for:
Engineering Test Documentation

The Nine Deadly Sins of Project Planning

1. Not planning at all.
2. Not planning for all project activities.
3. Failure to plan for risk
4. Using the same plan for every project
5. Using a prepackaged plan
6. Allowing a plan to diverge from reality
7. Planning too much too soon
8. Planning to catch up later
9. Not learning from past planning sins.

Lecture 5

Interview Preparation

Risk Reduction and Management

Questions Ask Youself Before A Project

1. Do You Have:
   A development process written out for your project
   that describes the steps, inputs, outputs, change control, and statusing?

   Development plan that identifies the hardware and software required, the methodologies to be used, reviews, team organization, and reporting structure?

2. Is The Team trained In:
   a. Application
   b. Tools
   c. Language
   d. Methodologies:
   Development
   Test
   Process

3. Have You Prototyped In Order To Help:
   a. Cost
   b. Schedule
   c. Proof of concept, process, documentation
   d. Buy/Build Decision

4. Have you reviewed any previous projects’ post-mortems to insure the recommended improvements have been put in place?

5. Have you identified the risks and plans to address the risks?

6. Has the Organization aligned on the project, goals, risks etc. ?

Difference Between Planning And Risk Management

Planning is essential but it is a paper exercise for the most part and there is risks involved in just doing analysis and paper exercises.

To reduce risk, we need to do three activities:
Critical Activity Number 1: Noodling
Critical Activity Number 2: Prototyping
Critical Activity Number 3: Risk Management

Risk Management

Noodling

informal improvise or play casually

Prototyping

Advantages Of Prototyping

1. dose this system make sense(feasiblility)
2. Throughput(benchmarking)
3. Cost and schedule
4. What are the risks areas
5. Customer buy in
6. Prototyping can answer critical questions up front without having to build a complete product.

Steps In Performing Prototyping

1. Select a candidate: CPU, Dbase, Communication, Low- Level Interface, User Interface, External Interface
2. Create a subset of the requirements
   A. handle one operator instead of n
   B. develop subset of screens
   C. complicated DB associations
   D. drivers for Low-Level interface
   E. read/write from External Interface
3. Design/Code/Test
4. Show the customer (or internal engineering team)
5. Iterate the previous steps

Key Points in Prototyping

1. Prototyping needs to be carried out in a controlled manner with a definite goal in mind.
2. A prototype leads to a functional product that remains far from a deliverable working product.
3. Prototyping allows for customer feedback (as a specification for a final product) in addition to answering one or more critical technical questions.

Tradeoffs

1. Quick delivery vs. lack of robustness
2. Sidetrack effort vs. keeping on main line of development
3. Quick implementation vs. structured, reusable code

Risk Management

Goal Of Risk Management

Avoid an unsatisfactory outcome.
If you are Customer or Developer, unsatisfactory outcome is budget overruns, schedule slips.
If you are User, unsatisfactory outcome is wrong functionality or performance
and reliability problems.
If you are Maintainers, unsatisfactory outcome is poor quality software.

Build Risk Management

1. Risk Assessment
   a. Risk Identification. What are project specific risks?
   b. Risk Analysis. What could cause the risk, will they occur?
   c. Risk Prioritization. Rank the risks.
2. Risk Control
   a. Risk Management Planning. Plan to deal with the risks.
   b. Risk Resolution. Eliminate or avoid the risk.
   c. Risk Monitoring. Track the risk, or the efforts to avoid the risks.

Top 8 Software Risk Items

1. Personnel Shortfalls: Staffing with top talent, team building, job matching, key personnel agreements, cross training.
2. Unrealistic Schedules and Unrealistic Budgets: Detailed multi-source cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing, descoping.
3. Developing the Wrong Functions: Organization analysis, mission analysis, operations-concept formulation, user participation prototyping, early user’s manuals, testing, traceability
   matrices.
4. Developing the Wrong User Interface: Prototyping, scenarios, task analysis, user participation and surveys
5. Gold-Plating: Requirements scrubbing, cost analysis, designing to costs
6. Requirement Changes: High change threshold, incremental development, configuration management, cost and budget impact.
7. Shortfalls In Externally Performed Tasks: Reference checking, award fee, contracts, team building, strong quality assurance, paper trail, configuration management
8. Real-Time Performance: Simulation, benchmarking, tuning

Risk Form

Management After Identifing The Risk

1. Have a plan to address the most probable/costly risk.
2. Manage to the plan.

What should be in the plan?

1. Objectives of the plan
2. Deliverables and milestones
3. Responsibilities
4. Approach
5. Resources