Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department...

Applied Software Project Management

1


Introduction

Dr. Mengxia Zhu

Computer Science Department

Southern Illinois University Carbondale


What is software project management?The Art and science of planning and leading software project, and requires knowledge of the entire development lifecycle: Defining the visionPlanning the tasksGathering people who will do the workEstimating the effortsCreating the scheduleOverseeing the workGathering the requirementsDesigning and programming the softwareTesting end products

2


A practical bookThe specific tools, techniques, and practices that need to be put in place to run a software project.

Who should take this course?A project manager responsible for a software development

project and a teamA programmer, designer, business analyst, architect,

tester, or other method of a software team looking to improve the product he/she is working on.

and more…such as quality assurance manager and consultant

3


4

Why do software projects fail?

People begin programming before they understand the problemEveryone likes to feel that they’re making progressWhen the team starts to code as soon as the

project begins, they see immediate gainsWhen problems become more complex (as they

always do!), the work gets bogged downIn the best case, a team that begins programming

too soon will end up writing good software that solves the wrong problem


5


The team has an unrealistic idea about how much work is involved.From far away, most complex problems

seem simple to solveTeams can commit to impossible

deadlines by being overly optimistic and not thinking through the work

Few people realize the deadline is optimistic until it’s blown


6


Defects are injected early but discovered late.Projects can address the wrong needsRequirements can specify incorrect behaviorDesign, architecture and code can be technically

flawedTest plans can miss functionalityThe later these problems are found, the more

likely they are to cause the project to fail


7


Programmers have poor habits – and they don’t feel accountable for their work.Programmers don’t have good control of their

source codeCode written by one person is often difficult for

another person to understandProgrammers don’t test their code, which makes

diagnosing and fixing bugs more expensiveThe team does not have a good sense of the

overall health of the project.


8


Managers try to test quality into the software.Everyone assumes that the testers will catch all of

the defects that were injected throughout the project.

When testers look for defects, managers tell them they are wasting time.

When testers find defects, programmers are antagonized because they feel that they are being personally criticized.

When testers miss defects, everyone blames them for not being perfect.


9

How can we make sure that our projects succeed?

Make sure all decisions are based on openly shared information It’s important to create a culture of transparency, where

everyone who needs information knows where to find it and is comfortable looking at it.

All project documents, schedules, estimates, plans and other work products should be shared with the entire team, managers, stakeholders, users and anyone else in the organization who wants them.

Major decisions that are made about the project should be well-supported and explained.

Everyone agrees on what needs to be built, how long it will take and what steps will be taken, how to know it has been done properly.


10


Don’t second-guess your team members’ expertiseManagers need to trust team members and make them

productive. Just because a manager has responsibility for a project’s

success, it doesn’t mean that he’s more qualified to make decisions than the team members. Rely on the expertise of the members. No way a single person can fill all the roles. They make recommendation, you make the informed decisions.

If you don’t have a good reason to veto an idea, don’t. Support them, listen to them.

However, do not blindly trust your team. Evaluate their ideas in relation to solid engineering principles.


11


Introduce software quality from the very beginning of the projectReview everything, test everything. Review is not just force people

to sign and make commitment. Use reviews to find defects – but don’t expect the review to be

perfect. Catch enough defects to more than pay for the time to hold it. Faster to fix something on paper than build it first and fix it. A few minutes review can save hours, days or weeks in fixing code.

Use reviews to gain a real commitment from the team. Foster respect among team members for everyone’s contribution.

Testing (unit testing, functional testing, performance testing) is just as cost-effective as reviews. Testing must be planned from the beginning and then supported throughout the entire project. Look for defects at every stage, in every document, and in the software.


12


Don’t impose an artificial hierarchy on the project teamAll software engineers were created equal.A manager should not assume that programming is more

difficult or technical than design, testing or requirements engineering.

Managers should definitely not assume that the programmer is always right, or the tester is always raising false alarms.

Everyone on the team feels respected and valued and gain a true commitment from each person to make the software the best it can be.


13


Remember that the fastest way through the project is to use good engineering practicesManagers and teams often want to cut important tasks –

especially estimation, reviews, requirements gathering and testing.

Do not like adopting practices unless they believe they will see a net gain.

If it were faster to build the software without these practices, we would never use them.

Every one of these practices is about saving time and increasing quality by planning well and finding defects early. Cutting them out will cost time and reduce quality.


Part I: Tools and TechniquesSoftware Project PlanningVision and scope documentSoftware project plan

EstimationWideband Delphi estimation process

Project ScheduleProject schedulesEarned value metrics Scheduling software (such as Microsoft

Project and Open Workbench)14


Tools and Techniques

ReviewInspections, Deskchecks, Walkthroughs

code reviews and pair programming

RequirementsUse cases Functional and nonfunctional requirementsSoftware requirements specificationsChange control

15


Tools and Techniques

Design and ProgrammingConfiguration managementSubversionRefactoringUnit testsProject automation software

Software testingTest plans, Test cases and Test automationDefect tracking systemPostmortem meetingsMetrics

16


Part II: Using Project Management Effectively

It is not enough for a project manager to understand practices that are used by all of the team members. A good project manager also needs to know how to lead the team. Focused on learning how to use the five basic principles in order to work with people, teams, and organizations.

Understanding Changes

Management and Leadership

Managing an Outsourced Project

Process Improvement

17

Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department...

Documents

Transcript of Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department...