Chapter 4 Software Project Planning.pptx

Chapter 4 Software Project Plannin

1. Chapter 4 Software Project Planning Fundamentals of SE by Eshetu and Lami 1

2. Software Project Planning Effective project management is crucial to the success of any software development project. The main goal of software project management is to enable a group of developers to work effectively towards the successful completion of a project. project management involves use of a set of techniques and skills to steer a project to success. Fundamentals of SE by Eshetu and Lami 2

3. Software Project Management Complexities Management of software projects is much more complex than management of many other types of projects. Invisibility: Software remains invisible, until its development is complete and it is operational. Anything that is invisible, is difficult to manage and control. Invisibility of software makes it difficult to assess the progress of a project and is a major cause for the complexity of managing a software project. Fundamentals of SE by Eshetu and Lami 3

4. Software Project Management Complexities Changeability: Because the software part of any system is easier to change as compared to the hardware part, the software part is the one that gets most frequently changed. Frequent changes to the requirements and the invisibility of software are possibly the two major factors making software project management a complex task. Fundamentals of SE by Eshetu and Lami 4

5. Software Project Management Complexities Complexity: Even a moderate sized software has millions of parts (functions) that interact with each other in many ways—data coupling, serial and concurrent runs, state transitions, control dependency, file sharing, etc. Uniqueness: Every software project is usually associated with many unique features or situations. This makes every project much different from the others. Fundamentals of SE by Eshetu and Lami 5

6. Software Project Management Complexities Exactness of the solution: Mechanical components such as nuts and bolts typically work satisfactorily as long as they are within a tolerance of 1 percent or so of their specified sizes. However, the parameters of a function call in a program are required to be in complete conformity with the function definition. Fundamentals of SE by Eshetu and Lami 6

7. Software Project Management Complexities Team-oriented and intellect-intensive work: Software development projects are akin to research projects in the sense that they both involve team-oriented, intellect-intensive work. In contrast, projects in many domains are labor-intensive and each member works in a high degree of autonomy . Fundamentals of SE by Eshetu and Lami 7

8. Responsibilities of a Software Project Manager A software project manager takes the overall responsibility of steering a project to success. The job responsibilities of a project manager ranges from invisible activities like building up of team morale to highly visible customer presentations. We can broadly classify a project manager’s varied responsibilities into the following two major categories: Project planning, and Project monitoring and control. Fundamentals of SE by Eshetu and Lami 8

9. Responsibilities of a Software Project Manager Project planning: Project planning is undertaken immediately after the feasibility study phase and before the starting of the requirements analysis and specification phase . Project planning involves estimating several characteristics of a project and then planning the project activities based on these estimates made. The initial project plans are revised from time to time as the project progresses and more project data become available. Fundamentals of SE by Eshetu and Lami 9

10. Responsibilities of a Software Project Manager Project monitoring and control: Project monitoring and control activities are undertaken once the development activities start . The focus of project monitoring and control activities is to ensure that the software development proceeds as per plan . While carrying out project monitoring and control activities, a project manager may sometimes find it necessary to change the plan to cope up with specific situations at hand. Fundamentals of SE by Eshetu and Lami 10

11. Skills necessary for Managing Software Projects A theoretical knowledge of various project management techniques is certainly important to become a successful project manager. Three skills that are most critical to successful project management are the following: Knowledge of project management techniques. Decision taking capabilities. Previous experience in managing similar projects. Fundamentals of SE by Eshetu and Lami 11

12. Project Planning Once a project has been found to be feasible, software project managers undertake project planning. Project planning is undertaken and completed before any development activity starts. However, for effective project planning, in addition to a thorough knowledge of the various estimation techniques, past experience is crucial. Fundamentals of SE by Eshetu and Lami 12

13. Project Planning During project planning, the project manager performs the following activities. Estimation: The following project attributes are estimated. Cost : How much is it going to cost to develop the software product? Duration : How long is it going to take to develop the product? Effort : How much effort would be necessary to develop the product? Fundamentals of SE by Eshetu and Lami 13

14. Project Planning The effectiveness of all later planning activities such as scheduling and staffing are dependent on the accuracy with which these three estimations have been made. Scheduling: After all the necessary project parameters have been estimated, the schedules for manpower and other resources are developed. Staffing: Staff organization and staffing plans are made. Fundamentals of SE by Eshetu and Lami 14

15. Project Planning Risk management : This includes risk identification, analysis, and reduction planning. Miscellaneous plans: This includes making several other plans such as quality assurance plan, and configuration management plan, etc. Size is the most fundamental parameter based on which all other estimations and project plans are made. Fundamentals of SE by Eshetu and Lami 15

16. Project Planning Fundamentals of SE by Eshetu and Lami 16

17. The SPMP Document of Project Planning Once project planning is complete, project managers document their plans in a software project management plan (SPMP) document. Listed below are the different items that the SPMP document should discuss. This list can be used as a possible organization of the SPMP document. Fundamentals of SE by Eshetu and Lami 17

18. The SPMP Document of Project Planning Introduction Objectives Major Functions Performance Issues Management and Technical Constraints 2. Project estimates Historical Data Used Estimation Techniques Used Effort, Resource, Cost, and Project Duration Estimates 3. Schedule Work Breakdown Structure Task Network Representation Gantt Chart Representation PERT Chart Representation 4. Project resources People Hardware and Software Special Resources Fundamentals of SE by Eshetu and Lami 18

19. The SPMP Document of Project Planning 5. Staff organization Team Structure Management Reporting 6. Risk management plan Risk Analysis Risk Identification Risk Estimation Risk Abatement Procedures 7. Project tracking and control plan Metrics to be tracked Tracking plan Control plan 8. Miscellaneous plans Process Tailoring Quality Assurance Plan Configuration Management Plan Validation and Verification System Testing Plan Delivery, Installation, and Maintenance Plan Fundamentals of SE by Eshetu and Lami 19

20. Project Size Estimation Metrics Accurate estimation of project size is central to satisfactory estimation of all other project parameters such as effort, completion time, and total project cost. The size of a project is obviously not the number of bytes that the source code occupies, neither is it the size of the executable code. The project size is a measure of the problem complexity in terms of the effort and time required to develop the product. Fundamentals of SE by Eshetu and Lami 20

21. Project Size Estimation Metrics Currently, two metrics are popularly being used to measure size lines of code (LOC) and function point (FP). Each of these metrics has its own advantages and disadvantages. Based on their relative advantages, one metric may be more appropriate than the other in a particular situation. Fundamentals of SE by Eshetu and Lami 21

22. Line of Code (LOC) LOC is possibly the simplest among all metrics available to measure project size . This metric measures the size of a project by counting the number of source instructions in the developed program. One can possibly estimate the LOC count at the starting of a project, only by using some form of systematic guess work . Fundamentals of SE by Eshetu and Lami 22

23. Line of Code (LOC) Systematic guessing typically involves the following. The project manager divides the problem into modules, and each module into sub-modules and so on, until the LOC of the leaf-level modules are small enough to be predicted. To be able to predict the LOC count for the various leaf-level modules sufficiently accurately, past experience in developing similar modules is very helpful. Fundamentals of SE by Eshetu and Lami 23

24. Shortcomings of the LOC metric LOC is a measure of coding activity alone. A good problem size measure should consider the total effort needed to carry out various life cycle activities (i.e. specification, design, code, test, etc.) and not just the coding effort. LOC count depends on the choice of specific instructions: LOC gives a numerical value of problem size that can vary widely with coding styles of individual programmers. Fundamentals of SE by Eshetu and Lami 24

25. Shortcomings of the LOC metric LOC measure correlates poorly with the quality and efficiency of the code: Calculating productivity as LOC generated per man-month may encourage programmers to write lots of poor quality code rather than fewer lines of high quality code achieve the same functionality. LOC metric penalizes use of higher-level programming languages and code reuse: A paradox is that if a programmer consciously uses several library routines, then the LOC count will be lower. Fundamentals of SE by Eshetu and Lami 25

26. Shortcomings of the LOC metric LOC metric measures the lexical complexity of a program and does not address the more important issues of logical and structural complexities: a program incorporating complex logic would require much more effort to develop than a program with very simple logic. It is very difficult to accurately estimate LOC of the final program from problem specification: The LOC count can accurately be computed only after the code has fully been developed. Fundamentals of SE by Eshetu and Lami 26

27. Function Point Metric Function point metric was proposed by Albrecht in 1983. This metric overcomes many of the shortcomings of the LOC metric. it can easily be computed from the problem specification itself. The size of a software product is directly dependent on the number of different high-level functions or features it supports. Fundamentals of SE by Eshetu and Lami 27

28. Function point (FP) metric computation The size of a software product is computed using different characteristics of the product identified in its requirements specification. It is computed using the following three steps: Step 1: Compute the unadjusted function point (UFP) using a heuristic expression. Step 2: Refine UFP to reflect the actual complexities of the different parameters used in UFP computation. Step 3: Compute FP by further refining UFP to account for the specific characteristics of the project that can influence the entire development effort. Fundamentals of SE by Eshetu and Lami 28

29. Step 1: UFP Computation The unadjusted function points (UFP) is computed as the weighted sum of five characteristics of a product as shown in the following expression. UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10 Fundamentals of SE by Eshetu and Lami 29

30. FP example Fundamentals of SE by Eshetu and Lami 30

31. T h e prin c ip le of A lbr ec ht ’ s fu nc tio n p oi n t a n a ly s i s (FP A ) is th a t a s yst em is d ec o m po s e d in t o fun c t i on a l u n i t s . Categorized as transaction type and Data files Inputs O utputs E nquiri e s : : : info r m a tio n ent e rin g the s y s t e m info r m a tio n l ea vin g the s y s t e m r e qu es ts for in s t a nt acces s to info r m a tio n info r m a tio n h e ld w ithin the s y s t e m info r m a tio n h e ld b y oth e r s y s t e m th a t is u sed b y the s y s t e m b e in g a n a l y ze d. Int e rn a l logi ca l fil e s : E xt e rn a l int e r f ac e f il e s : Step 1: UFP Computation Fundamentals of SE by Eshetu and Lami 31

32. Th e FP A f u n ct io na l u ni ts a re s ho w n i n f igu re gi v e n b elo w : U s e r I nq u i r i e s ILF EIF U s e r O t h e r a p pli ca t i o n s S y s t e m Ou t p ut s I np u t s I L F: I n t e r n a l l o gi ca l f il e s E IF: E x t e r n a l i n t e r f ace s Step 1: UFP Computation F ig: FPA s f unctio n a l u n i ts S ystem Fundamentals of SE by Eshetu and Lami 32

33. Step 2: Refine parameters UFP computed at the end of step 1 is a gross indicator of the problem size. This UFP needs to be refined. This is possible, since each parameter (input, output, etc.) has been implicitly assumed to be of average complexity. The complexity of each parameter is graded into three broad categories- simple , average, or complex. Based on these weights of the parameters, the parameter values in the UFP are refined. Fundamentals of SE by Eshetu and Lami 33

34. Step 2: Refine parameters Counting Function Point Fundamentals of SE by Eshetu and Lami 34

35. T h e p r o c e du r e f o r t h e calc u lati o n o f UFP i n m at h e m atica l f o r m i s g i v e n b el o w : i  1 J  1 W h e re i in d ic a t e t h e r o w a nd j in di c ates t h e c o l u m n W ij : It is t h e e n try of t h e i th row and j th c o lu m n Z i j : It is t h e cou n t of t he nu m ber of f unctio n a l u n i ts of T ype i th a t have been c l assi fi ed a s having t h e co m plex it y correspo n ding to colu m n j . U F P  ∑ ∑ Z ij w ij 5 3 Step 3: Refine UFP based on complexity of the overall project Fundamentals of SE by Eshetu and Lami 35

36. O rgani za ti o ns th a t use f unc t ion p o i n t m ethods d e velop a c ri t e rion f o r de t er m ining w heth e r a pa r t i c u lar e ntry is L o w , A verage o r H igh. N oneth e les s , t h e d ete r m ina t ion of co m plex i ty is s o m e w hat subj e c t i v e. F P = U F P * C A F W here CA F is co m plex i ty a d just m e nt f a c tor a n d is equ a l to [ 0.65 + 0.01 x ΣF i ] . T he F i ( i =1 to 1 4 ) a re t he de g ree o f in f luen c e and a r e based on r esponses to q u es t ions n o t e d in ta b le 3. Step 3: Refine UFP based on complexity of the overall project Fundamentals of SE by Eshetu and Lami 36

37. Ta b l e 3 : C o m p utin g f u n c t i o n p o i n t s. Ra te e ac h f a c t o r o n a s c a le o f to 5. 0 1 2 3 5 4 I n c id e n tal M od e r a te Signifi c ant E ss e nti a l No I nflu e n c e Ave r ag e N u m b e r o f f a c to r s c on si d ere d ( F i ) D o e s th e s y s te m r e qu i r e r e l i a b le b ac ku p a n d rec ov e r y ? I s d a t a c o m m un i c a tio n re qu i re d ? A r e t h e r e di st r i but e d p r o ce s s in g fun c tion s ? I s p e r fo r m a n c e c ri t i c a l ? W i ll th e s y s t e m r u n in a n e xi s tin g h ea vi l y u t i l i ze d o p e r a t ion a l e nv i r o n m e nt ? D o e s th e s y s te m r e qu i r e o n l in e d a ta e n t r y ? D o e s th e o n li n e d a t a e n t r y re qu i r e th e input t r a n s a ct io n to b e bui l t ov e r m u l t ip le s c r e e n s o r op e ra t ion s ? A r e t h e m a s t e r fil e s upd a t e d o n l i n e ? I s th e inputs, o u tputs, f i l e s , o r inquiri e s c o m p l e x ? I s th e int e r n a l p r o ce s s in g c o m p l e x ? I s th e c od e d e si gn e d to b e re u s a b le ? A r e c onv er s io n a n d in st a l l a t io n i n c lud e d in th e d e s i g n ? I s th e s y s t e m d e si gn e d fo r m u l t i p le in s t a l l a tion s in diff ere nt o r g a n i z at ion s ? I s th e a ppli c a ti o n d e si gn e d to f a ci li t a t e c h a ng e a n d e a se o f u se b y th e u s e r ? Step 3: Refine UFP based on complexity of the overall project Fundamentals of SE by Eshetu and Lami 37

38. Organizational and Team structures Organization structure Usually every software development organization handles several projects at any time. Software organizations assign different teams of engineers to handle different software projects. Each type of organization structure has its own advantages and disadvantages so the issue “how is the organization as a whole structured?” must be taken into consideration so that each software project can be finished before its deadline. Fundamentals of SE by Eshetu and Lami 38

39. Organization structure Functional format vs. Project format In the project format , the project development staff are divided based on the project for which they work. In the functional format, the development staff are divided based on the functional group to which they belong . In the functional format, different teams of programmers perform different phases of a project. For example, one team might do the requirements specification, another do the design, and so on. In the project format, a set of engineers is assigned to the project at the start of the project and they remain with the project till the completion of the project. Fundamentals of SE by Eshetu and Lami 39

40. Organization structure Fundamentals of SE by Eshetu and Lami 40 Project format Functional format

41. Team structures Fundamentals of SE by Eshetu and Lami 41 Centralized – Control Team Organization Workers report to supervisor – who directly controls and is responsible for their performance Specialists Standard management technique

42. Team structures Fundamentals of SE by Eshetu and Lami 42 Decentralized – Control Team Organization Ring like management – lack of hierarchy Team members – same level, review each other‘s work and responsible as a group Software Engineer Communication

43. Team structures Fundamentals of SE by Eshetu and Lami 43 Mixed – Control Team Organization Combine the benefits of centralized and decentralized organization Minimizing / avoiding their disadvantages Distinguishes the engineers into senior and junior ; senior leads a group of juniors; senior report to a project manager

44. Project Estimation Techniques The different parameters of a project that need to be estimated include- project size, effort required to complete the project, project duration, and cost. A large number of estimation techniques have been proposed by researchers. These can broadly be classified into three main categories: Empirical estimation techniques Heuristic techniques Analytical estimation techniques Fundamentals of SE by Eshetu and Lami 44

45. 1. Empirical Estimation Techniques Empirical estimation techniques are essentially based on making an educated guess of the project parameters . prior experience with development of similar products is helpful. Although empirical estimation techniques are based on common sense and subjective decisions, over the years, the different activities involved in estimation have been formalized to a large extent. Fundamentals of SE by Eshetu and Lami 45

46. 2. Heuristic Techniques Heuristic techniques assume that the relationships that exist among the different project parameters can be satisfactorily modelled using suitable mathematical expressions. Once the basic (independent) parameters are known, the other (dependent) parameters can be easily determined by substituting the values of the independent parameters in the corresponding mathematical expression. Different heuristic estimation models can be divided into the following two broad categories: single variable and multivariable models. Fundamentals of SE by Eshetu and Lami 46

47. 2. Heuristic Techniques Single variable estimation models assume that various project characteristic can be predicted based on a single previously estimated basic (independent) characteristic of the software such as its size. Estimated Parameter = c1 * e d1 e represents a characteristic of the software that has already been estimated (independent variable). The dependent parameter to be estimated could be effort, project duration, staff size, etc., c1 and d1 are constants. Fundamentals of SE by Eshetu and Lami 47

48. 2. Heuristic Techniques A multivariable cost estimation model assumes that a parameter can be predicted based on the values of more than one independent parameter. It takes the following form: Estimated Resource = c 1 * p 1 d1 + c 2 * p 2 d2 + c 3 * p 3 d3 + … where, p1, p2, ... are the basic (independent) characteristics of the software already estimated, and c1, c2, d1, d2, .... are constants. Multivariable estimation models are expected to give more accurate estimates compared to the single variable models Fundamentals of SE by Eshetu and Lami 48

49. 3. Analytical Estimation Techniques Analytical estimation techniques derive the required results starting with certain basic assumptions regarding a project. Unlike empirical and heuristic techniques, analytical techniques do have certain scientific basis. In fact, it outperforms both empirical and heuristic techniques as far as estimating software maintenance efforts is concerned . Fundamentals of SE by Eshetu and Lami 49

50. Scheduling The scheduling problem, in essence, consists of deciding which tasks would be taken up when and by whom. Fundamentals of SE by Eshetu and Lami 50

51. Scheduling ……. General Practices: On large projects, hundreds of small tasks must occur to accomplish a larger goal Project manager’s objectives Define all project tasks Build an activity network that depict their interdependencies Identify the tasks that are critical within the activity network Build a timeline depicting the planned & actual progress of each task Track task progress to ensure that delay is recognized “one day at a time” To do this, the schedule should allow progress to be monitored and the project to be controlled. Fundamentals of SE by Eshetu and Lami 51

52. General Practices…..Cont’d SW project scheduling distributes estimated effort across the planned project duration by allocating the effort to specific tasks Scheduling for project can be viewed from two different perspectives First, an end-date for release for a computer-based system has already been established & fixed The sw organization is constrained to distribute effort within the prescribed time frame Second, assume that rough chronological bounds have been discussed but that the end-date is set by the SE organization Effort is distributed to make best use of resources and an end-date is defined after careful analysis of the software. Fundamentals of SE by Eshetu and Lami 52

53. Basic Principles for Project Scheduling Compartmentalization The project must be compartmentalized into a number of manageable activities, actions, & tasks; both the product & process are decomposed Interdependency The interdependency of each compartmentalized activity, action, or task must be determined Some task must occur in sequence while others can occur in parallel Some actions or activities cannot commence until the work product produced by another is available Fundamentals of SE by Eshetu and Lami 53

54. Basic Principles for Project Scheduling Time allocation Each task to be scheduled must be allocated some number of work units In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies Start and stop dates are also established based on whether work will be conducted on a full-time or part-time basis Effort validation Every project has a defined number of people on the team As time allocation occurs, the project manager must be ensure that no more than the allocated number of people have been scheduled at any given time Fundamentals of SE by Eshetu and Lami 54

55. Basic Principles for Project Scheduling Defined responsibilities Every task that is scheduled should be assigned to a specific team member Defined outcomes Every task that is scheduled should have a defined outcome for SW projects such as a work product or part of a work product Work products are often combined in deliverables Defined milestones Every task or group of tasks should be associated with a project milestone A milestone is accomplished when one or more work products has been reviewed for quality and has been approved Fundamentals of SE by Eshetu and Lami 55

56. Task Network A task set is the work breakdown structure for the project. No single task set is appropriate for all projects and process models. It varies depending on the project type and the degree of rigor (based on influential factors) with which the team plans to work The task set should provide enough discipline to achieve high software quality But it must not burden the project team with un neccesary work Fundamentals of SE by Eshetu and Lami 56

57. Factors that influence a project’s schedule Size of the project Number of potential users Application longevity Stability of requirements Ease of customer or developer communications Maturity of applicable technology Performance constraints Embedded and non-embedded characteristics Project staff Reengineering factors Fundamentals of SE by Eshetu and Lami 57

58. Purpose of a Task Network Also called an activity network It is a graphical representation of the task flow for a project It depicts task length, sequence, concurrency and dependency Points out inter-task dependencies to help the manager ensure continuous progress toward project completion The critical path A single path leading from start to finish in a task network It contain the sequence of tasks that must be completed on schedule if the project as a whole is to be completed on schedule It also determines the minimum duration of the project Fundamentals of SE by Eshetu and Lami 58

59. Purpose of a Task Network Fundamentals of SE by Eshetu and Lami 59

60. Purpose of a Task Network Fundamentals of SE by Eshetu and Lami 60

61. Timeline Chart Mechanics of a Timeline chart Also called a Gantt chart ; All project tasks are listed in the far left column The next few columns may list the following for each task: the project start-date, project stop-date, project duration, actual start-date, actual stop-date, actual duration, task-interdependencies (i.e. predecessors) To the far right are columns representing dates on the calendar The length of a horizontal bar on the calendar indicates the duration of the task When multiple bars occur at the same time interval on the calendar, this implies task concurrency A diamond in the calendar area of a specific task indicates that the task is a milestone; a milestone has a time duration of zero Fundamentals of SE by Eshetu and Lami 61

62. Timeline Chart Fundamentals of SE by Eshetu and Lami 62

63. Methods for Tracking the Schedule Qualitative approach Conduct periodic project status meetings in which each team member reports progress and problem Evaluate the result of all reviews conducted throughout the software engineering process Determine whether formal project milestones (i.e. diamond) have been accomplished by the scheduled date Compare actual start date to planned start date for each project task listed in the timeline chart Meet informally with the software engineering team to obtain their subjective assessment of progress to date and problem on the horizon Quantitative approach Use earned value analysis to assess progress quantitatively Fundamentals of SE by Eshetu and Lami 63

64. Sof t w a r e R i s k M a n ag e m e n t W e Soft w a re d e v e lop e rs a re e xtr e m e ly opti m ists. W e a ssu m e , e v e ryth i ng w ill go e x ac tly a s pl a nn e d . O th e r vi ew not p o s s ib l e to pr e di c t w h a t is going to h a pp e n ? Soft w a re s urpris e s N e v e r good n e w s Risk Management Fundamentals of SE by Eshetu and Lami 64

65. R isk f ac tor m a n a g e m e nt i s r e quir e d to r e du c e this su r prise D ea ling w ith c on cer n b e fore it b ec o m e s a c risis. Q u a ntify p rob a b i li t y of f a ilure & c ons e q ue n ce s of f a ilur e . Risk Management Fundamentals of SE by Eshetu and Lami 65

66. What i s ri sk ? T o m orro w ’s probl e m s a re tod ay ’s risks. “ Ri sk i s a p r ob l e m t h a t m a y c au se s o me l o ss o r t h r e a t e n t h e s uc ce ss o f t h e p r o j e c t , bu t w h i c h ha s no t ha p p en e d y e t ” . Risk Management Fundamentals of SE by Eshetu and Lami 66

67. R isk m a n a g e m e nt is the pro ces s of id e nt i fying a dd re ssi n g a nd e li m in a ting th e s e probl e m s b e fore th e y ca n d a m a ge the proj ect . C urr e nt probl e m s & Pot e n t i a l Probl e m s Risk Management Fundamentals of SE by Eshetu and Lami 67

68. T ypi c al Sof t w ar e R isk Ca p e rs J o n e s h a s ide ntifi e d t h e to p five ris k f act or s th a t thr ea t e n p r oj ec ts i n d i ff e r e nt a ppli ca t i ons. D e p e nd e n c i e s on o u t side a g e n c i e s or f ac tors. A v a il a bi l i t y of tr a in e d, e xp e ri e n ce d p e rs o ns Int e r gro u p d e p e nd e n c i e s C usto m e r-Furnish e d it e m s or infor m a tion Int e rn a l & e xt e rn a l s u b c ontr ac t o r r e l a tion s hips Risk Management Fundamentals of SE by Eshetu and Lami 68

69. 2. Re quir e m e nt i s su e s U n ce rt a in r e quir e m e nts W rong pr o du c t or R ight p r o d u c t b a d l y E ith e r si t u a ti o n r e su l ts unh ap py c usto m e rs. i n unpl e a s a nt surpr i s e s an d Risk Management Fundamentals of SE by Eshetu and Lami 69

70. L ac k of c l ea r produ c t vi s ion L ac k of a g r e e m e nt on produ c t r e quir e m e nts U npriori ti ze d r e quir e m e nts N e w m a r k e t w ith u nce rt a in n ee ds R a pid l y c h a ngi n g r e quir e m e nts In a d e qu a te I m p ac t a n a lys i s of r e quir e m e nts c h a ng e s Risk Management Fundamentals of SE by Eshetu and Lami 70

71. 3. M a n a g e m e nt Issu e s Proj ec t m a n a g e rs pl a ns, an d m ost u su a l l y p e ople w rite the r is k m a n a g e m e nt to a ir th e ir d o not w i sh w ea kn e ss e s in pu b li c . In a d e qu a te pl a nn i ng In a d e qu a te vis i bi l i t y i nto ac tu a l proj ec t s t a tus U n c l ea r p r oj ec t o w n e rship an d d ec is i on m a king St a ff p e rson a li t y c on f li c t s U nr ea listic e xp ec t a ti o n Poor c o m m uni ca ti o n Risk Management Fundamentals of SE by Eshetu and Lami 71

72. 4. Lac k of kno w l e dge In a d e qu a te tr a ini n g Poor un de rst a n d ing of m e thods, to o ls, a nd t ec hn i qu e s In a d e qu a te a ppli ca t i o n do m a in e xp e ri e n c e N e w T ec h nol o gi e s • In e ff ec tiv e , poorly do c u m e nt e d or n e gl ec t e d pro ce ss e s Risk Management Fundamentals of SE by Eshetu and Lami 72

73. 5. O th e r risk ca t e gori e s U n a v a il a b i li t y of a d e qu a te t es t i ng f ac il i ti e s T urnov e r of e ss e n t i a l p e rso n n e l U n ac hi e v a ble p e rfor m a n c e r e q uir e m e nts T ec hni ca l a ppro ac h e s th a t m a y not w ork Risk Management Fundamentals of SE by Eshetu and Lami 73

74. R isk M a n a g e m e nt R i s k M a n ag e m e n t A c t ivi t i e s R isk A ss e ss m e nt R isk C ont r ol R isk Id e n t ifi ca t i on R isk A n a lys i s R isk Prior i ti za t i on R isk M a n a g e m e nt Pl a nn i ng R isk M on i tori n g R isk Re so l ut i on F i g . 9 : R isk Ma n a g e m e n t A cti v it ies Risk Management Fundamentals of SE by Eshetu and Lami 74

75. R i s k A ss e ss m e n t I d e n tifi ca t i on of ri s ks R i s k a n a l ys i s i nvo l ve s e x a m i n i ng h o w p r o j ec t o u t c o m e s m i ght c h an ge w it h m o d ifi ca ti on o f ri s k i nput v a ri a b l es . R i s k p ri o riti za ti on f o c us f or seve r e ri s k s . R i s k e x p o s u r e : I t i s t he p r od u c t o f t he p r ob a b ilit y of i n c u rri n g a l o s s due t o t he ri s k a nd t h e p o t e n ti a l m a gn it ude of t h a t l o ss . Risk Management Fundamentals of SE by Eshetu and Lami 75

76. A n o t he r w a y of h a n d li ng ri s k i s t he ri s k a v o i d a n ce . Do not d o t he ri s ky t h i n g s ! W e m a y a vo i d ri s ks by not u n d e r t a k i n g ce rt a i n p r o j ec t s , or by r e l y i ng o n p r o v e n r a t h e r t h a n c u tti ng ed ge t echn o l o g i es . Risk Management Fundamentals of SE by Eshetu and Lami 76

77. R i s k C on t r ol R i s k M a n a g e m e nt P l a nn i ng p r o d u ce s a p l a n f or d ea li n g w i t h eac h s i g n ifi ca nt ri s k s . Y R ec o r d d e c i s i on i n t he p l a n. R i s k r es o l u ti on i s t he e x e c u ti on o f t he p l a ns of d ea li n g w i t h eac h ri s k. Risk Management Fundamentals of SE by Eshetu and Lami 77

78. Thank You! End of the Chapter Fundamentals of SE by Eshetu and Lami 78