Software Project Management Lecture 8 1 Organization

Software Project Management Lecture 8 1

Organization of this Lecture z. Overview of Last Lecture z. Staffing z. Scheduling z. Risk Management z. Configuration Management z. Summary 2

Overview of Last Lecture z. Last lecture we discussed the broad responsibilities of the project manager: y. Project planning y. Project Monitoring and Control z. Cost estimation is an important part of project planning. 3

Overview of Last Lecture z. To estimate software cost: y. Determine size of the product. y. Using size estimation, xdetermine effort needed. y. From the effort estimation, xdetermine project duration, and cost. 4

Overview of Last Lecture (CONT. ) z. Cost estimation techniques: y. Empirical Techniques y. Heuristic Techniques y. Analytical Techniques z. Empirical techniques are based on systematic guesses made by experts: y. Expert Judgement y. Delphi Estimation 5

Overview of Last Lecture (CONT. ) z. Heuristic techniques: yassume that different product parameters are related through a simple mathematical expression: y. COCOMO z. Analytical techniques: yderive the estimates starting with some basic assumptions y. Halstead's Software Science 6

Overview of Last Lecture (CONT. ) z. Staffing level during the life cycle of a software product: yfollows the Rayleigh curve: x. Maximum number of engineers required during testing. x. Number of engineers at any phase depends on the number of parallel activities possible. z. The relationship between schedule change and effort is highly nonlinear. 7

Overview of Last Lecture (CONT. ) z. Team organization: y. Chief programmer: Suitable for routine development work. y. Democratic: Suitable for small teams doing R&D type work. y. Mixed: Suitable for large organizations. 8

Staffing z. Project Managers usually take responsibility for choosing their team: yneed to identify and select good software engineers for the success of the project. 9

Staffing z. A common misconception: yone software engineer is as productive as another: z. Experiments reveal: ya large variation in productivity between the worst and best in a scale of 1 to 10. y. Worst engineers even help reduce the overall productivity of the team xin effect exhibit negative productivity. 10

Who is a Good Software Engineer? z Good programming abilities z Good knowledge of the project areas (Domain) z Exposure to Systematic Techniques z Fundamental Knowledge of Computer Science z Ability to work in a team z Intelligence z Good communication skills: y Oral y Written y Interpersonal z High Motivation 11

Who is a Good Software Engineer? (cont. ) z. Studies show: ythese attributes vary as much as 1: 30 for poor and bright candidates. z. Technical knowledge in the area of the project (domain knowledge) is an important factor, determines: y productivity of an individual y quality of the product he develops. 12

Who is a Good Software Engineer? (cont. ) z. A programmer having thorough knowledge of database applications (e. g MIS): ymay turn out to be a poor data communication engineer. 13

Scheduling z Scheduling is an important activity for the project managers. z To determine project schedule: y. Identify tasks needed to complete the project. y. Determine the dependency among different tasks. y. Determine the most likely estimates for the duration of the identified tasks. y. Plan the starting and ending dates for various tasks. 14

Work Breakdown Structure z Work Breakdown Structure (WBS) provides a notation for representing task structure: y Activities are represented as nodes of a tree. y The root of the tree is labelled by the problem name. y Each task is broken down into smaller tasks and represented as children nodes. z It is not useful to subdivide tasks into units which take less than a week or two to execute. y Finer subdivisions mean that a large amount of time must be spent on estimating and chart revision. 15

Work Breakdown Structure Compiler Project Requirements Design Lexer Code Test Write Manual Parser Code Generator 16

Activity Networks z WBS structure can be refined into an activity network representation: y. Network of boxes and arrows yshows different tasks making up a project, yrepresents the ordering among the tasks. z It is important to realize that developing WBS and activity network yrequires a thorough understanding of the tasks involved. 17

Activity Network Code Lexer Design Requirements Code Parser Code Generator Test Write Manual 18

Gantt Charts z. Named after its developer Henry Gantt. y a form of bar chart: xeach bar represents an activity, xbars are drawn against a time line, xlength of each bar is proportional to the length of time planned for the activity. 19

Gantt Charts z. Gantt charts are not specific to software engineering. z. Gantt charts used in software project management are: yenhanced version of standard Gantt charts. ycolored part of a bar shows the length of time a task is estimated to take. ywhite part shows the slack time, xthe latest time by which a task must be finished. 20

Gantt Chart Requirements Design Code Lexer Code Parser Code Generator Test Write Manual 21

Scheduling z. Many managers believe yan aggressive schedule motivates the engineers to do a better and faster job. y. However, careful experiments show: xunrealistic aggressive schedules cause engineers to compromise on intangible quality aspects, • also cause schedule delays. 22

Scheduling z A good way to achieve accuracy: ylet people set their own schedules. z Schedule for a large-sized task may take too long: y. Managers need to break large tasks into smaller ones to find more parallelism xcan lead to shorter development time. x. Small-sized tasks help in better tracking 23

Critical Path z Task dependencies define a partial ordering among tasks, i. e. y Completion of some tasks must precede the starting time of some other tasks. z A critical path: yalong which every milestone is critical to meeting the project deadline. z A Critical Path is a chain of tasks that determine the duration of the project. 24

Critical Paths z A critical paths is sequence of tasks such that ya delay in any of the tasks will cause a delay to the entire project. z There can be more than one critical path in a project. z It is important for the project manager to be aware of the critical paths in a project: ycan ensure that tasks on these paths are completed on time. 25

Critical Paths z Other tasks may have some room for delay without affecting the entire project. y. If necessary, the manager may switch resources from a noncritical task to a critical task. z Several software packages are available for automating the scheduling process: y. Mac. Project on Apple Macintosh computer y. MS-Project on Microsoft Windows Operating System. 26

CPM and PERT Charts z. While Gantt charts show the different tasks and their durations clearly: ythey do not show intertask dependencies explicitly. ythis shortcoming of Gantt charts is overcome by PERT charts. 27

Critical Path Management z. Critical Path Management(CPM) is a technique for: y. Identifying critical paths y. Managing project. z. The CPM technique is not specific to software engineering yhas a much wider use. 28

Critical Path Management z. CPM can assist in answering questions like: y. What are the critical paths in the project? y. What is the shortest time in which the project can be completed? y. What is the earliest (or latest) time a task can be started (or finished) without delaying the project? 29

Example z A project involves three tasks: y task a takes 4 hours, y task b takes 5 hours y task c takes 8 hours. y task c cannot commence until task a is completed. z What is the shortest time in which the project can be completed? b 5 start 4 a 8 finish c 30

Example z Clearly, the project continues until task a and then task c complete: ywhich is 12 hours. y. Task b takes only 5 hours. y. Task b can have 7 hours of leeway to start and finish. b 5 start 4 a 8 finish c 31

What data do we need to construct a CPM graph? z. To construct a CPM graph, ya list of tasks and their durations are required. y. Also, for each task a list of tasks upon which it depends is required. y. A task may depend on more than one task. z. Project task details can be given in the form of a table. 32

Task Table z Task Duration Dependents 33

CPM Graph c: 20 a: 10 start finish g: 5 b: 20 d: 10 f: 5 e: 10 34

How do we work out the various start and finish times for tasks? z Minimum time to complete project (MT) = Maximum of all paths from start to finish z Earliest start time (ES) of a task = Maximum of all paths from start to this task z Earliest finish time (EF) of a task = ES + duration of the task z Latest finish time (LF) of a task = MT Maximum of all paths from this task to finish z Slack time = LS - ES = LF - EF 35

Start and finish times for tasks. z Latest start time (LS) of a task = LF - duration of the task Task MT EF ES LF LS 36

What are the float time (or slack time) of tasks? z Float time (or slack time) is the total time that a task may be delayed ybefore it will affect the end time of the project. z The float times indicate the "flexibility" in starting and completion of tasks: z A critical activity is an activity with zero (0) slack or float time. 37

What is PERT and how does it work? z PERT (Program Evaluation and Review Technique) is a variation of CPM: y incorporates uncertainty about duration of tasks. z Gantt charts can be derived automatically from PERT charts. z Gantt chart representation of schedule is helpful in planning the utilization of resources, y while PERT chart is more useful for monitoring the timely progress of activities. 38

Risk Management z A risk is any unfavourable event or circumstance: ywhich might hamper successful or timely completion of a project. z Risk management: yconcerned with the reduction of the impact of risks. z Risk management consists of three activities: yrisk identification, yrisk assessment, and yrisk containment. 39

Risk identification z. To be able to identify various risks: ywe must categorize risks into different classes. z. Three main categories of risks can affect a software project: yproject risks ytechnical risks ybusiness risks 40

Project Risks z. Project risks associated with: ybudget, yschedule, ypersonnel, yresource, and ycustomer problems. 41

Technical Risks z Technical risks concern: yrequirements specification x(e. g ambiguous, incomplete, changing specifications) ydesign problems, yimplementation problems, yinterfacing problems, ytesting, and maintenance problems. ytechnical uncertainty, and technical obsolescence are technical risk factors too. 42

Business Risks z Business Risks include: y building an excellent product that no one wants, ylosing budgetary or personnel commitments, etc. z It is a good idea to have a “company disaster list”, ya list of all bad things that have happened in the past yproject managers can jog their mind to see which items their project is vulnerable to. 43

Risk assessment z. Objective of risk assessment is to prioritize the risks: y. Likelihood of a risk being real. y. Consequence of the problems associated with that risk. z Prioritization helps in handling the most damaging risks first. y. Priority of a risk is the product of the likelihood of the risk and the consequences of the problems associated with that risk. 44

Risk Handling z Three main strategies for risk handling: y. Avoid the risk: e. g. change the requirements for performance or functionality. y. Transfer the risk: allocate risks to third party x or buy insurance to cover any financial loss should the risk become a reality. y. Contingency planning: Prepare contingency pans to minimize the impact of the risk. 45

Risk Handling z. To decide about risk handling options, we must take into account: ycost of reducing risk yresulting cost saving from risk reduction. 46

Risk Containment z. Let us see how we can contain an important type of risk: yschedule slippage xcan be dealt with by increasing the visibility of the project. z. Milestones are placed at regular intervals yprovide a manager with regular indication of progress. 47

Containing Schedule Slippage z. A milestone is reached, ywhen documentation produced has successfully been reviewed. 48

Software Configuration Management z. The results (aka deliverables) of any large software development effort consists of a large number of objects: ysource code, ydesign document, y. SRS document, ytest document, yproject plan (SPMP) document, etc. 49

Software Configuration Management (CONT. ) z. A configuration is a collection of deliverables: ybeing developed for some customer. z. As development proceeds, ythe components comprising a configuration undergo changes: y. Even during maintenance, the components comprising a configuration keep changing. 50

What is configuration management? z. The set of activities through which the configuration items are managed and maintained yas the product undergoes its life cycle phases. 51

Versions z A configuration for a particular system is called a version: y. The initial delivery might consist of several versions, ymore versions might be added later on. y. For example, one version of a mathematical package might run on a Unix machine, xanother on Windows NT, and xanother on Solaris. 52

Versions z As a software is released and used by the customers: yerrors are discovered, yenhancements to the functionalities might be needed. z A new release of the software is an improved system intended to replace an old one. z Usually a product is described as version m and release n (or as version m. n) 53

Software Configuration Management z. Existence of variants of a software product causes several problems. z. Suppose you have several versions of the same module, and yfind a bug in one of them. yit has to be fixed in all versions. 54

Software Configuration Management z. Different objects are accessed and modified by a number of engineers. z. Unless strict discipline is enforced: yregarding updation and storage of the objects through some automated tool, yseveral problems appear. 55

Software Configuration Management z. For example, an engineer might update the module that he has designed --ywithout informing the engineers who need to interface with this module. z. Or, two engineers may simultaneously carry out changes to different portions of a module: ywhile saving overwrite each other. 56

Why Configuration Management? z To be able to identify the exact state of different deliverables at any time. z To avoid the problems associated with having replicated objects accessible by multiple engineers. z Controlling concurrent work on a module by different engineers. (Overwriting one engineer’s work by another) z Letting different engineers work on related modules at the same time. z Keeping track of variants (versions) and helping fix bugs in them. z Storing versions and revisions efficiently. z Maintaining revision history (accounting). 57

Software Configuration Management z. Configuration management helps to: yquickly determine the current state of the product ychange the various components (modifications, revisions, variations etc. ) in a controlled manner. ymaintaining the current up-to-date status of various versions of the software, ycontrol and account changes to the product. 58

Software Configuration Management Activities z. Configuration management is carried out through three principal activities: yconfiguration identification, yconfiguration control, yconfiguration accounting and reporting. 59

Software Configuration Management Activities z. Configuration identification ywhich parts of the system must be kept track of? z. Configuration control yensures that changes to a component happen smoothly. z. Configuration accounting ykeeps track of what has been changed, when, and why. 60

Configuration Identification z Deliverable objects can be classified into three main categories: ycontrolled, yprecontrolled, yuncontrolled. z Controlled objects are under configuration control: yyou must follow some formal procedures to change them. 61

Configuration Identification z. Precontrolled objects are not yet under configuration control, ybut may eventually be under configuration control. z. Uncontrolled objects are not and will not be subject to configuration control. 62

Configuration Identification z. Typical controllable objects include: y. Design documents y. Tools used to build the system, such as compilers, linkers, lexical analyzers, parsers, etc. y. Source code for each module y. Test cases y. Problem reports 63

Configuration Control z. Configuration control is the process of managing changes. y. It is the part of configuration management that most directly affects day-to-day operations of the developers. z. Once an object goes under configuration control, yany further changes requires approval from a change control board (CCB). 64

Configuration Control z. The CCB is constituted from among the development team members. z. For every change carried out, y. CCB certifies several things about the change: x. Change is well-motivated. x. Developer has considered and documented the effects of change. x. Appropriate people have validated the change. 65

Configuration Control z An important reason for configuration control: y people need a stable environment to develop a software product. z Suppose you are trying to integrate module A, with the modules B and C, y you cannot make progress if developer of module C keeps changing it; y this is especially frustrating if a change to module C forces you to recompile A. z As soon as a document under configuration control is updated, y the updated version is frozen and is called a baseline. 66

Configuration Control Baseline New Baseline A B C D C’ D Reserve Replace Cancel Reservation C Private Copy 67

Configuration Control z This establishes a baseline for others to use. z Freezing a configuration may involve archiving everything needed to rebuild it. y. Archiving means copying to a safe place such as a magnetic tape. z At any given time, a programmer may pay attention to: y. Current baseline configuration y. Programmer's private version 68

SCCS (Source Code Control System) z. SCCS is a configuration management tool: yavailable on Unix systems: yhelps control and manage text files. yalso implements an efficient way of storing versions: xminimizes the amount of occupied disk space. 69

SCCS z. Suppose a module is present in 3 versions: y. MOD 1. 1, MOD 1. 2, and MOD 1. 3. z. SCCS stores the original module MOD 1. 1 ytogether with changes needed to transform it into MOD 1. 2 and MOD 1. 3. ythe modifications are called deltas. 70

SCCS Features z Access control facilities provided by SCCS include: y facilities for checking components in and out. y. Individual developers check out components and modify them. xafter they have changed a module as required and the module has been successfully tested, xthey check in the changed module into SCCS. 71

SCCS Features z. Revisions are denoted by numbers in ascending order, ye. g, 1. 1, 1. 2, 1. 3 etc. z. It is also possible to create variants of a component yby creating a fork in the development history. 72

Summary z Project staffing requires careful understanding of the attributes of good software engineers. z Project scheduling: ybreak down large tasks into smaller logical units, ydetermine dependencies among tasks, ydetermine expected duration of tasks, yassign resources, and yassign times. 73

Summary z. Several techniques are available to help in scheduling: y. Work breakdown structure y. Activity networks y. Gantt charts y. PERT and CPM z. Commercial software tools are available to assist in developing these. 74

Summary z. It is necessary to determine the critical paths in a project: yto meet the timing for critical activities. z. An important project planning activity is risk management: y. Risk identification y. Risk assessment y. Risk containment 75

Summary z. Configuration management. ythe set of activities by which a large number of objects are managed and maintained. 76