Software Engineering: Analysis and Design - CSE3308

1. CSE3308/DMS/2002/11 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Project Management

2. Lecture Outline • The Problem • Definitions • Overview • The People • The Team Leader • Coordination and Communication • The Project • Meetings • Formal Technical Reviews

3. 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 • According to a KPMG survey of 256 companies, only 14 percent of all failures can be chalked up to a company’s inability to cope with technology. The other 86 percent owe to some common management woes: • improperly defined objectives (17 percent) • unfamiliar scope (17 percent) • lack of effective communication (20 percent) • poor project management skills (32 percent)

4. 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

5. 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

6. Project Management – Overview (2) • Why is it important? • As we have just seen, many projects fail • Building software is a complex task – particularly if it involves a lot of people and takes place over a long period of 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 & time needed, define work products, establish quality checkpoints, establish methods to monitor & control work defined by plan • We will focus on people and project

7. The People (1) • A 1988 IEEE study of engineering VPs of major tech. companies were asked what was most important to the success of a project “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 argue that people are primary, but unfortunately their actions often belie their words

8. 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 people who do technical aspects of work – the practioners • Practioners • Deliver necessary techical skills to engineer 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

9. 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 ability (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!

10. 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

11. Coordination and Communication (1) • 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

12. 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)

13. 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 • Which of these techniques are you currently applying in your group project?

14. 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

15. The Project (2) • How does a project management 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!

16. 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

17. Meetings (1) • Project Managers are required to run meetings. Some good practices: • Distribute start time, end time and estimated time for agenda items (before meeting) • Prepare “strawman” items (before meeting) • Start on time • Have someone record action items • Have someone track time and prompt participants • Get agreement on agenda and timing • Watch timing throughout – end on time • Allow exceptions for important discussion – but take excessive discussion off-line • Keep discussions on topic • Circulate minutes including action items and discussion summary (after meeting)

18. 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

19. 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 walkthoughs, inspections and other small group software assessments

20. 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, chance of uncovering errors is increased

21. 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

22. 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 partipants 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)

23. 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

24. 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

25. FTRs: Effectiveness • Catch up to 75% of design errors • Can be up to 3 times more effective than testing at finding errors • Involve time, effort and money, but provide a demonstrable cost benefit in the overall development

26. 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).