cse3308 - software engineering: analysis and design, 2003lecture 3a.1 software engineering: analysis...

CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 3A.1

Software Engineering: Analysis and Design - CSE3308

Project Management

CSE3308/DMS/2003/7

Monash University - School of Computer Science and Software Engineering


Lecture Outline

The Problem Definitions Overview The People The Team Leader Coordination and Communication The Project Meetings Formal Technical Reviews


Project Management – The Problem

“I’ve visited dozens of commercial shops, both good and bad, and I’ve observed scores of data processing managers, again, both good and bad. Too often, I’ve watched in horror as these managers futilely struggled through nightmarish projects, squirmed under impossible deadlines, or delivered systems that outraged their users and went on to devour huge chunks of maintenance time.” - Page-Jones, 1985

A KPMG survey of 256 companies indicated that only 14% of failures could be attributed to a company’s inability to cope with technology. The other 86% were due to management problems:

improperly defined objectives (17 percent) unfamiliar scope (17 percent) lack of effective communication (20 percent) poor project management skills (32 percent)


Project Management - Definitions

“Project management consists of managing the production of a product within given time and funding limits. Since this requires human resources, project management involves not only technical and organizational skills, but also the art of managing people. Project management is no mundane activity: It can be as gripping as landing a jumbo jet on a short airstrip.” – Braude, 2001

“Project management involves the planning, monitoring, and control of the people, process and events that occur as software evolves from preliminary concept to operational implementation.” – Pressman, 2000


Project Management – Overview (1) What is it?

Planning, monitoring and control of» People» Process» Events

as software evolves from preliminary concept to operational implementation

Who does it? Everyone, to some extent, e.g.:

» A software engineer manages his/her daily activities: planning, monitoring and controlling technical tasks

» A project manager plans, monitors and controls the activities of a team of software engineers

» A senior manager coordinates the interactions between business and software professionals


Project Management – Overview (2)

Why is it important? As we saw earlier, many projects fail Software development is a complex task

» particularly if it involves many people and lasts a long time“ there are no technical failures; only management failures” –

Braude, 2001 What are the steps?

Understand the four P’s:» People – must be organised to work effectively» Product – must have effective communication with the

customer to specify scope and requirements» Process – must be appropriate for people and product » Project – must estimate effort and time needed, define work

products, establish quality checkpoints, establish methods to monitor and control work defined by plan

We will focus on people and project


The People (1)

A 1988 IEEE study asked the engineering VPs of major technology companies what was most important to the success of a project. Some quotes:

“I guess if you had to pick one thing out that is most important in our environment, I’d say it’s not the tools we use, it’s the people.”

“The only rule I have in management is to ensure that I have good people – real good people – and that I grow good people – and that I provide an environment in which good people can produce.”

Managers say that people are primary, but unfortunately they often do not act in accordance with this principle


The People (2) People working on software projects play various

roles, which can be organized into five basic types: Senior managers

» Define business issues that often have great impact on project

Project managers» Plan, motivate, organize and control the people who do

technical aspects of work – the practitioners Practitioners

» Deliver necessary technical skills to engineer the product Customers & Stakeholders

» Specify requirements and scope for software End-Users

» Interact with software product once it is released To be effective, the Team Leader must organize the

project team so as to maximise each person’s skills and abilities


The Team Leader Project management is a people-oriented activity

People with great technical skills don’t necessarily make good team leaders – people skills are needed too

Weinberg suggests an MOI model of leadership Motivation

» Ability to encourage technical people to work to the best of their abilities (push or pull)

Organization

» Ability to adapt existing processes, or devise new ones, to enable the concept to be turned into a product

Ideas/Innovation

» Ability to encourage people to create, and to feel creative, within the bounds of the particular product

Team leader must let everyone know, by words and deeds, that quality is important – lead by example!


The Team Leader Another view of what makes a good team leader:

Problem solving» Decide which technical and organizational issues are most

important» Create a systematic solution to the problem – or motivate

others to do so» Apply lessons from past projects to new ones» Remain flexible enough to change direction if initial

proposed solution doesn’t work Managerial Identity

» Confidence to take charge of project when necessary, but also to let good technical people use their initiative

Achievement» Reward initiative and accomplishment» Demonstrate that controlled risk-taking will not be punished

Influence and Team building» Be able to “read” people – understand both verbal and non-

verbal signals from team members, and react to their needs


Software projects fail for many reasons. For modern software, issues of scale, uncertainty and interoperability are usually unavoidable

Scale: many projects are large, leading to complexity, confusion and major difficulties in coordinating people

Uncertainty: scope and requirements change is common, often resulting in continuous addition to the team load

Interoperability: new software must communicate with existing systems, and conform to predefined standards and constraints

Coordination and Communication (1)


Coordination and Communication (2) To deal with these issues, methods must be

established to foster both formal and informal communication between team members, and to coordinate their work

Project Coordination Techniques Formal, impersonal approaches

» Software engineering documents and deliverables (including source), technical memos, project milestones, schedules and PM tools, change requests & documentation, error tracking reports, etc.

Formal, interpersonal procedures

» Focus on quality assurance activities applied to the work products: status review meetings, design and code inspections (walkthroughs)


Coordination and Communication (3)

Project Coordination Techniques cont. Informal, interpersonal procedures

» Group meetings for communication of information, problem solving, and getting requirements and development staff together

Electronic communication

» Email, bulletin boards, video conferencing Interpersonal network

» Informal discussions with team members and outside experts

You should consider applying some or all of these techniques in your group project


The Project (1)

Ten signs that indicate that a project is in trouble:

Technical people don’t understand customer’s needs Product scope is poorly defined Change management is poor Change in technology chosen for solution Business needs change or are not well defined Deadlines are not realistic Users are resistant to the proposed solution Sponsorship is lost, or was never actually obtained Project team lacks people with the right skills Managers and team members resist best-practice, and

lessons learned on previous projects


The Project (2)

How does a project manager avoid these problems?

Start on the right foot

» Work very hard to understand the problem

» Set realistic objectives and expectations for team

» Give team members autonomy, authority and appropriate technology

Maintain momentum

» Provide incentives to minimize turnover of personnel

» Ensure that team emphasizes quality in every task

» Avoid getting in team’s way!


The Project (3)

How does a project management avoid these problems? cont.

Track progress» Work products are produced and approved by formal

technical review» Project and process metrics can be gathered and compared

with historical data Make smart decisions

» KISS: Keep It Simple, Stupid Use off-the-shelf software and/or components where possible Avoid custom interfaces if a standard is available Identify and avoid obvious risks Allocate more time than you think is needed to risky or complex tasks

Conduct a post-mortem analysis» Establish a mechanism for extracting lessons-learned from

completed projects: planned vs. actual schedule, metrics, feedback from team members and customers

» Record findings in written form


Meetings (1)

Project Managers are required to run meetings. Some good practices:1. Distribute start time, end time and estimated time for

agenda items (before meeting)2. Prepare “strawman” items (before meeting)3. Start on time4. Have someone record action items5. Have someone track time and prompt participants6. Get agreement on agenda and timing7. Watch timing throughout – end on time

Allow exceptions for important discussion – but take excessive discussion off-line

8. Keep discussions on topic9. Circulate minutes including action items and discussion

summary (after meeting)


Meetings (2)

Strawman items Groups are not very good at creating artifacts (e.g. analysis &

design documents) from scratch Much better to have someone create a tentative – “strawman” –

version of the item before the meeting Strawman item is used as the basis for discussion

» Should not be too specific

» Must be plenty of room for input from meeting participants

Taking discussion off-line Team leader or meeting chairperson must decide when to

terminate discussion that is running over allotted time, or getting off-topic

Consensus is not always possible in a meeting Solution? Identify the problem to be solved, and specify who will

continue the discussion off-line and report to the next meeting


Formal Technical Reviews (FTR)

An FTR is a quality assurance activity performed by software engineers (and others)

Objectives Uncover errors in function, logic or implementation for

any representation of software Verify that software being reviewed meets its

requirements Ensure that software is represented according to relevant

standards (e.g. Structured A&D, UML) Achieve uniform software development Make projects more manageable Train junior software engineers

FTRs include walkthroughs, inspections and other small group software assessments


FTRs: Constraints

FTRs are conducted as meetings, and will only be successful if properly planned, controlled and attended

Basic constraints for FTRS: Typically involve three to five people Participants should do advance preparation (no more

than two hours work) Review meeting should take no more than two hours

To meet these constraints, the FTR must focus on a specific (and small) part of the software

By reducing scope of the FTR, the chance of uncovering errors is increased


FTRs: Preparation

Preparation for an FTR Person who developed the work product – the producer –

informs the team leader that it is ready for review Team leader designates a review leader, who evaluates

the product’s readiness and distributes copies of product material to two or three other reviewers

Each reviewer spends one or two hours reviewing the product and making notes on it

At the same time, the review leader also reviews the product, establishes an agenda for the review meeting and schedules a meeting time


FTRs: The Meeting

The FTR meeting Meeting is attended by producer, review leader and all reviewers One reviewer acts as a recorder, who notes in writing all the

important issues raised during the review Start by going over the agenda, and a brief introduction to the

product from the producer Producer then proceeds to “walk-though” the product,

explaining it as he/she goes» Reviewers raise issues based on their advance preparation» When valid problems or errors are discovered, they are

noted by the recorder At end of meeting, all participants must decided whether to

» Accept the product as is» Reject the product due to severe problems (redevelopment

and another review required)» Accept the product provisionally (minor errors, as noted,

must be corrected, but no further review required)


FTRs: Reporting

Review Reporting and Recording After the review meeting, the recorder produces a review

summary report, answering the questions:» What was reviewed?» Who reviewed it?» What were the findings and conclusions?

Review summary report is typically a single page, possibly with attachments

A review issues list should also be created and attached to the summary report. It notes:» Problem areas within the product» An action item checklist which guides the producer

as corrections are made The review leader should have follow-up contact with the

producer to ensure that the issues have been addressed


FTRs: Guidelines

Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Identify problem areas but don’t attempt to solve every

problem Take written notes Limit the number of participants Insist on advance preparation Develop a checklist for each work product Allocate resources and time Conduct meaningful training Review earlier reviews


FTRs: Effectiveness

Catch up to 75% of design errors Can be up to three times more effective than

testing at finding errors Involve time, effort and money, but provide a

demonstrable cost benefit in the overall development


References

Braude, Eric J., Software Engineering: an object-oriented perspective, John Wiley & Sons, New York, 2001 (Chapter 2).

McNeice Filler, Susan, Project Failures Spur Management Back to Basics, Billing World and OSS Today, Nov. 2001.http://www.billingworld.com/archive-detail.cfm?archiveId=4963&hl=PMI

Page-Jones, Meilir, Practical Project Management, Dorset House, 1985.

Pressman, Roger S., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000 (Chapters 3, 8).

Van Vliet, Hans, Software Engineering: Principles and Practice (2nd Ed.), John Wiley & Sons, New York, 2000 (Chapter 2).

cse3308 - software engineering: analysis and design, 2003lecture 3a.1 software engineering: analysis...

Documents

people u

cse3308 software engineering

software engineering

project management overview

communication u

team of software

lecture outline u

software professionals