350 likes | 366 Views
Chapter 3 Project Management. Software project management. Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software
E N D
Software project management • Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software
Software management distinctions • The product is intangible • The product is uniquely flexible • Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc. • The software development process is not standardised • Many software projects are 'one-off' projects
The 4 P’s • People — the most important element of a successful project • Product — the software to be built • Process — the set of framework activities and software engineering tasks to get the job done • Project — all work required to make the product a reality
Software Project Management • Work to be done (estimate) • Resources available • Technical personnel hours • Administrative support hours • Equipment • Software • Budget
Software Project Management • Resources • People • Money • Tasks • Map people to tasks • Map money to tasks • Time • Map tasks and people to a schedule • Handle constraints among task serialization • Manage milestones (intermediate deadlines)
Project Management Tools • Resources • Spreadsheet • Tasks • Spreadsheet • Time • Calendar • Pert-type chart • Everything • Project Management Software
Project Management • Project [persistent] functions • Planning • Hiring/firing/evaluations • Accounting/budgeting • Activities • Non-persistent • Comprised of tasks • Work products • Results of tasks
The Players • Senior Managers • Project Managers • Practitioners • Customers • End users 10
The Project Managers • Hardest Problem • Having the right people • On the right part of the project • At the right time • At the right price
Software Projects Factors that influence the end result ... • size • delivery deadline • budgets and costs • application domain • technology to be implemented • system constraints • user requirements • available resources
Why Projects Fail? • an unrealistic deadline is established • changing customer requirements • an honest underestimate of effort • predictable and/or unpredictable risks • technical difficulties • miscommunication among project staff • failure in project management
Software Teams The following factors must be considered when selecting a software project team structure... • difficulty of the problem to be solved • size of resultant program(s) in LOC or FP • time the team will stay together (team lifetime) • degree to which the problem can be modularized • required quality and reliability of the system to be built • rigidity of the delivery date • degree of communication required for the project
Organizational Paradigms • closed paradigm—structures a team along traditional hierarchy of authority • random paradigm—structures a team loosely and depends on individual initiative of the team members • open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm • synchronous paradigm—relies on the natural compartment-alization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine [CON93]
Software Team • Paradigms • Controlled (the traditional approach) • Centralized (vertical only) • Decentralized (horizontal too) • Demographic • Pairs
Democratic Software Team • 10 (or so) egoless programmers • No single leader • No programmer trying to get promoted to the next level • Roles are dynamics and not well-defined • Quality Circles
Democratic Software Team • Egoless programming • Every programmer must encourage the other members of the team to find faults • The presence of faults must not be considered something bad, but rather a normal and accepted event • The reviewer is asked for advice
Democratic Software Team • Leverages the diversity of the group • Two heads really are better than one • Facilitates reviews and walkthroughs, which are proven to improve fault detection • The ultimate goal is to reduce fear in the workplace. • Primary means is by sharing responsibility
Fallacy of Egolessness • Everybody has egos • Leaders "need" to lead • Capitalism is founded on competition • Difficult to attain group decisions that truly represent the entire group • Large number of personal interconnections required • Group dynamics suggests that structure will occur
Pair Programming • Match up two people • One to define requirements, another to document requirements. • Allows interaction between two people to drive out requirements. • Can have two people programming, one thinking and one keying.
Defining the Problem • establish scope—a narrative that bounds the problem • decomposition—establishes functional partitioning
To Get to the Essence of a Project • Why is the system being developed? • What will be done? By when? • Who is responsible for a function? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm
Critical Practices • Formal risk analysis • Empirical cost and schedule estimation • Metrics-based project management • Earned value tracking • Defect tracking against quality targets • People aware project management
Management activities • Proposal writing • Project planning and scheduling • Project costing • Project monitoring and reviews • Personnel selection and evaluation • Report writing and presentations
Project staffing • May not be possible to appoint ideal team • Budget may not allow use of high-paid staff • Staff with the appropriate experience may not be available • An organisation may wish to develop employee skills on a software project • Managers work within these constraints especially with the international shortage of skilled IT staff
Project planning • Probably the most time-consuming project management activity • Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available • Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget
Activity organization • Activities in a project should be organised to produce tangible outputs for management to judge progress • Milestones are the end-point of a process activity • Deliverables are project results delivered to customers • The waterfall process allows for the straightforward definition of progress milestones
Project scheduling • Split project into tasks and estimate time and resources required to complete task • Organize tasks concurrently to make optimal use of workforce • Minimize task dependencies to avoid delays caused by one task waiting for another to complete • Dependent on project managers intuition and experience
Scheduling problems • Estimating the difficulty of problems and hence the cost of developing a solution is hard • Productivity is not proportional to the number of people working on a task • Adding people to a late project makes it later because of communication overheads • The unexpected always happens. Always allow contingency in planning
Bar charts and activity networks • Graphical notations used to illustrate the project schedule • Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two • Activity charts show task dependencies and the the critical path • Bar charts show schedule against calendar time
Pert Charts • Program Evaluation Review Techniques • US Navy, 1957 • Systematic method of estimating project length • Based on a systematic serialization algorithm based on: • Dependencies • Resource availability • Adds administrative oversight to critical paths • Critical path: Sequence of tasks such that if any task on the CP is delayed, so is the whole project 22
Activity network - PERT T 6 M 3 s t a r t T 7 T 2 M 2 M 7 T 5 T 4 T 1 0 M 5 F i n i s h 1 5 d a y s 1 4 / 7 / 9 9 1 5 d a y s M 1 T 3 8 d a y s T 9 T 1 5 d a y s 4 / 8 / 9 9 2 5 / 8 / 9 9 2 5 / 7 / 9 9 M 4 M 6 4 / 7 / 9 9 7 d a y s 2 0 d a y s 1 5 d a y s T 1 1 5 / 9 / 9 9 2 5 / 7 / 9 9 1 1 / 8 / 9 9 1 0 d a y s 1 0 d a y s M 8 1 5 d a y s 1 0 d a y s 1 8 / 7 / 9 9 T 1 2 2 5 d a y s T 8 1 9 / 9 / 9 9