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 = fn(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
- 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 - Determine who owns the customer facing requirements and who owns the technical and derived requirements.
- Determine who owns:
a. Cost
b. Schedule
c. Quality
d. Functionality - 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:
- Response Time
- System Availability
- Throughput Capacity
- Security Requirements
- Integrity
- Auditability
- Disaster Recovery
- 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
- the single most important piece of documentation for the project is the Context Diagram
- Its purpose is to show the scope of the project
- The Context Diagram is made up of one bubble with the name of the System inside
- It shows all the inputs and all the outputs.
- 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
- The most important document in the entire development process.
- It serves as a contract between Engineering and Product Management.
- It is the key transition in the entire development process.
- The software project manager must ensure that this document is developed, reviewed and approved in a timely manner.
Who should create this document?
- Primary Responsibility: Product Mgr
- Secondary Responsibility: Software Engr,Test Engr
Why do you need a detailed PRD?
- preliminary acceptance/rejection
- vehicle for communication
- feasibility
- 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:
- Preliminary high level schedules and costs based on the MRD 2. Detailed schedules and costs based on the detailed analysis and product specifications
- Revised schedules and costs based on the work being accomplished
Scheduling Steps
- Assign Engineers to the tasks
- Assign duration to tasks
- Determine which function needs to be done in what order
- Layout the end to end schedule
- 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:
- High level product functionality
- Decomposed tasks list (based on process)
- Delivery date and some rough milestone dates
- High resource allocation to tasks
- Defined roles, responsibilities and expectations
- Physical resources
How would the following scenarios affect the development process?
- Time-to-Market
- Developing a Market
- Research and Development
- Establishing Market Leadership 5. Establishing a Product Family
How would the software engineering team’s background and environment affect the project:
- Complex, new technology
- Straightforward and known technology
- 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
- A detailed plan cannot be created until AFTER the detailed requirements have been refined, reviewed and approved.
- A high level plan (using the template) based on organizational practices, prior project histories and the MRD CAN be created.
- 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
System Overview. Briefly state the purpose of the system and its major
componentsProduct and Project Deliverables
MajorActivityScheduleAndMilestones
a. Whendoesitstart
b. When does it end
c. What does it produce
d. Sequential relationship to other activitiesResources
a. Hardware b. Software c. FacilitiesRisks
a. Whatarethey
b. How will you monitor them
c. What will you do if they occurStatusing Method
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. ReviewsSoftwareTesting
a. OrganizationalStructure
b. Personnel and their RR&E
c. TestApproach
d. TestPlanningAndConstraintsSoftware Configuration Management and Release
a. Organizational Structure
b. Personnel
c. Configuration Control- Flow Of Configuration Control
- Reporting Documentation
- Review Procedures
- 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
- Not planning at all.
- Not planning for all project activities.
- Failure to plan for risk
- Using the same plan for every project
- Using a prepackaged plan
- Allowing a plan to diverge from reality
- Planning too much too soon
- Planning to catch up later
- Not learning from past planning sins.
Lecture 5
Interview Preparation
Risk Reduction and Management
Questions Ask Youself Before A Project
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?
Is The Team trained In:
a. Application
b. Tools
c. Language
d. Methodologies:
Development
Test
ProcessHave You Prototyped In Order To Help:
a. Cost
b. Schedule
c. Proof of concept, process, documentation
d. Buy/Build DecisionHave you reviewed any previous projects’ post-mortems to insure the recommended improvements have been put in place?
Have you identified the risks and plans to address the risks?
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
- dose this system make sense(feasiblility)
- Throughput(benchmarking)
- Cost and schedule
- What are the risks areas
- Customer buy in
- Prototyping can answer critical questions up front without having to build a complete product.
Steps In Performing Prototyping
- Select a candidate: CPU, Dbase, Communication, Low- Level Interface, User Interface, External Interface
- 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 - Design/Code/Test
- Show the customer (or internal engineering team)
- Iterate the previous steps
Key Points in Prototyping
- Prototyping needs to be carried out in a controlled manner with a definite goal in mind.
- A prototype leads to a functional product that remains far from a deliverable working product.
- Prototyping allows for customer feedback (as a specification for a final product) in addition to answering one or more critical technical questions.
Tradeoffs
- Quick delivery vs. lack of robustness
- Sidetrack effort vs. keeping on main line of development
- 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
- 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. - 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
- Personnel Shortfalls: Staffing with top talent, team building, job matching, key personnel agreements, cross training.
- Unrealistic Schedules and Unrealistic Budgets: Detailed multi-source cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing, descoping.
- Developing the Wrong Functions: Organization analysis, mission analysis, operations-concept formulation, user participation prototyping, early user’s manuals, testing, traceability
matrices. - Developing the Wrong User Interface: Prototyping, scenarios, task analysis, user participation and surveys
- Gold-Plating: Requirements scrubbing, cost analysis, designing to costs
- Requirement Changes: High change threshold, incremental development, configuration management, cost and budget impact.
- Shortfalls In Externally Performed Tasks: Reference checking, award fee, contracts, team building, strong quality assurance, paper trail, configuration management
- Real-Time Performance: Simulation, benchmarking, tuning
Risk Form
Management After Identifing The Risk
- Have a plan to address the most probable/costly risk.
- Manage to the plan.
What should be in the plan?
- Objectives of the plan
- Deliverables and milestones
- Responsibilities
- Approach
- Resources