Software Project Management Overview v1 PDF

Preview

Summary

nil...

Description

4Ps of Project Management

340CT Software Quality and Process Management

Dr. Yih-Ling Hedley Email: [email protected]

Process: the set of framework activities and software engineering tasks 2

YL Hedley

Project Management: People

Processes in Conventional Practice 1

 Stakeholders − Senior managers: define the business issues that often have significant influence on the project. − Project (technical) managers: plan, motivate, organize, and control the practitioners who do software work. − Practitioners: deliver the technical skills that are necessary to engineer a product or application. − Customers: specify the requirements for the software to be engineered and other stakeholders with a peripheral interest in the outcome. − End-users: interact with the software once it is released for production use.

 Software Teams and Team Leaders YL Hedley

3

Problems in Conventional Practice 2  In practice, the traditional approach has suffered from: − protracted integration & late design breakage (i.e. where problems are discovered in the implementation that couldn't have been foreseen through paper-only models.)  Conduct early paper designs and thorough briefings  Lots of time spent on ‘perfecting the software design’. Commitment to code very late in cycle  Integration difficulties due to unforeseen implementation and interface issues YL Hedley

5

 Problems associated with traditional projects (with a waterfall model): − Real projects rarely follow the sequential flow of the processes proposed by the model. − Unable to accommodate the nature of uncertainty of project’s requirements. It is difficult for customers to identify detailed criteria at the beginning of the project. − System development can be a long process which does not produce a working version of the system until late in the process. YL Hedley

Source: http://www.ctg.albany.edu/publications/reports/sur vey_of_sysdev?chapter=5&PrintVersion=2

4

Problems in Conventional Practice 2.1

Early paper designs and thorough briefings • Commitment to code very late in cycle • Integration nightmares due to unforeseen implementation and interface issues • Heavy budget and schedule pressure • Late ‘shoe-horning’ of non-optimal fixes with no time for redesign • A very fragile, un-maintainable product and almost always: delivered late.

H Guo & YL Hedley

6

Problems in Conventional Practice 2.2 − late risk resolution  Requirements stage: difficult to resolve risks when many key requirements are still not fully understood – identify risks at a very high level  Design stage, when requirements better understood, still difficult to get objective assessment.  Coding stage: some risks resolved  Integration stage: many risks were quite clear and changes to many artefacts occur

7

YL Hedley

Problems in Conventional Practice 3 − requirements-driven (functional decomposition) approach  assume that all requirements can be completely specified up-front  assume that all requirements could be captured as ‘functions’ and resulting decomposition of these functions.

Activity 2: Feedback

Activity 2  Discuss the problems associated with requirements-driven and functional decomposition approach .

9

YL Hedley

Conventional to Iterative Project 1  Progress profiles for Waterfall projects − Requirements were first captured in complete details in ad hoc text. − Software development progressed without delivering any executable result until integration phase. − Getting the software to operate reliably to test its usefulness took much longer than planned.

YL Hedley

Source: The Economics of Iterative Software Development: Steering Toward Better Business Results: The Economics of Iterative Development, Walker Royce et al. 2009

8

YL Hedley

11

− Developers assumed requirement specs: complete, clear, necessary, feasible, and constant – which differ in real projects. − Often too much time spent equally on all requirements rather than on critical ones. − much time spent on documentation on that was later made obsolete as ‘subsequent design understanding evolve.’ − Functions became the basis for software contracts, while ignoring architectural-driven approaches 10

YL Hedley

Conventional to Iterative Project 2  Progress profiles for Iterative projects − Software development team produces the architecture first: understand important issues regarding architecture − Continuous integration: allows integration to occur as the verification of design to detect design flaws and resolve problems earlier in the lifecycle − The system is developed from an immature prototype to a skeletal baseline architecture, to increments of capabilities, to final complete product releases. YL Hedley

Source: The Economics of Iterative Software Development: Steering Toward Better Business Results: The Economics of Iterative Development, Walker Royce et al. 2009

12

Conventional to Iterative Project 3  Project progress profiles for Waterfall and Iterative processes

 Agile software development methodology: emphases on increasing collaboration and communication; works well on projects where a large number of changes, issues, or uncertainty is anticipated. − Scrum: small teams work independently on various tasks or subsections managed by a Scrum master, allowed multiple subprojects to be accomplished concurrently

13

YL Hedley

Project: Agile Management Methodologies

14

YL Hedley

Scrum: Sprint Planning and Tracking

Project: Scrum Method

 Burn-downs charts: approaches − using task count: using number of tasks remaining, when the team updates tasks as they complete them − using effort remaining approach − using story points

YL Hedley

Source: codeproject.com

15

YL Hedley

Source: https://www.scrumalliance.org/

16

Scrum: Burn-downs charts 1

Scrum: Burn-downs charts 1.1

 Effort remaining approach − A task breakdown during the sprint planning meeting − reflects progress assuming that all tasks will be completed within the sprint at a uniform rate

 Example 1: sprint commitments are met and progress has been smooth over the sprint

YL Hedley

Source: https://www.scrumalliance.org/

17

YL Hedley

Source: https://www.scrumalliance.org/

18

Scrum: Burn-downs charts 1.3

Scrum: Burn-downs charts 1.2  Example 2: sprint commitments were not met and the remaining work then become part of the product backlog and was carried forward to subsequent sprints

YL Hedley

Source: https://www.scrumalliance.org/

19

 Example 3: the work is carried out at a slow pace in the first few weeks of the sprint and pushed toward the end of the sprint to meet the commitment

YL Hedley

 Example 4: the work performance is not consistent but meeting weekly goals by stretching toward the end of every week

Source: https://www.scrumalliance.org/

21

Scrum: Burn-downs charts 2.1  Story Points approach: Team members commit to a finite number of user stories that must be completed during each sprint

YL Hedley

Source: https://www.scrumalliance.org/

20

Scrum: Burn-downs charts 2

Scrum: Burn-downs charts 1.4

YL Hedley

Source: https://www.scrumalliance.org/

23

 Story Points (SP) approach − Example: Team members (TM with a total of working hours 198) commit to a finite number of user stories (e.g. 16) that must be completed during each sprint − Daily SP (expected SP per day) = Daily Hours * Sprint SP Total [16] / Sprint Working Hours Total = 21 * 16 / 198 = 1.7 or = 15 * 16 / 198 = 1.21

YL Hedley

Source: https://www.scrumalliance.org/

22...