Project Management

1. Project Management PART - II

2. Software Project Management • Organising, planning and scheduling software projects. • Concerned with activities involved in ensuring that software is delivered • on time • within the budget • in accordance with the requirements. • While project management was traditionally applied to the management of projects only, it is now being deployed to help organizations manage all types of change. • It begins before any technical activity is initiated and continues throughout the rest of the phases of software development.

3. Management Activities • Proposal writing • Project planning and scheduling • Project costing • Project monitoring and reviews • Personnel selection and evaluation • Report writing and presentations

4. The Management Spectrum • Effective Software Project Management focuses on four P’s: People Product Process Project

5. The Management Spectrum • People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development) • Product (product objectives, scope, alternative solutions, constraint tradeoffs) • Process (framework activities populated with tasks, milestones, work products, and QA points) • Project (planning, monitoring, controlling)

6. People • The most important contribution in a software project is made not by the system or the tools but by the people. • The human element is very vital in software project management. • The success of a project depends on selecting the right kind of people with the right kind of talent. • Depending on their roles and responsibilities, people involved in a software project can be categorized into the following main categories: • Senior manager • Project manager • Software Engineer • Customer • End user

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

8. Software Teams How to lead? How to collaborate? How to organize? How to motivate? How to create good ideas?

9. Team Leader • The MOI Model • Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. • Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. • Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

10. Software Teams The following factors must be considered when selecting a software project team structure …. • the difficulty of the problem to be solved • the size of the resultant program(s) in lines of code or function points • the time that the team will stay together (team lifetime) • the degree to which the problem can be modularized • the required quality and reliability of the system to be built • the rigidity of the delivery date the degree of sociability (communication) required for the project.

11. Avoid Team Toxicity • A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed. • High frustration caused by personal, business, or technological factors that cause friction among team members. • “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. • Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. • “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

12. Agile Teams • Team members must have trust in one another. • The distribution of skills must be appropriate to the problem. • A team member may have to be excluded from the team, if team cohesiveness is to be maintained. • Team is “self-organizing” • an adaptive team structure • uses elements of Constantine’s random, open, and synchronous paradigms • significant autonomy.

13. Broad Categories of Team Organization • There can be three broad categories of team organizations: • Democratic Decentralized (DD) • Controlled Decentralized (CD) • Controlled Centralized (CC)

14. Democratic Decentralized (DD) • This kind of team has a horizontal level of communication where there will be no permanent leader as such. • A person to coordinate and monitor tasks will be appointed for short durations and then replaced by others who may coordinate different tasks. • Decisions are generally made by group consent. • This kind of team structure is best for difficult problems. • Job satisfaction and high morale can be achieved by implementing this kind of team structure.

15. Controlled Decentralized (CD) • This kind of team has a proper leader who coordinates specific tasks and secondary leaders who are responsible for subtasks. • Problem solving is still a group activity but the team leader divides implementation of solutions among subgroups. • Communication within subgroups and individuals is horizontal. However, along the control hierarchy, vertical communication also exists. • This kind of team structure is suitable for simple problems and is found to produce fewer defects.

16. Controlled Centralized (CC) • A team leader manages top-level problem solving and internal team coordination. • Communication between the leader and team members is vertical. • This kind of team structure is also suitable for simple problems and is found to produce fewer defects.

17. What Structure can be used and When? • For solving simple problems • A centralized structure is more suitable since it completes faster than a decentralized one. • For solving difficult problems • A decentralized structure is suitable since decentralized teams generate more and better solutions than individuals. • For large projects • Since the performance of a team is inversely proportional to the amount of communication that must be conducted, very large projects can be addressed by teams with a CC or CD structure where sub-grouping can be easily accommodated. • For high morale and job satisfaction • The DD team structure results in high morale and job satisfaction and are therefore good for teams that will be together for a long time.

18. What Structure can be used and When? • For solving problems with low modularity • The DD team structure is best applied to problems with relatively low modularity because of the higher volume of communication needed. When high modularity is possible (and people can do their own thing), the CC or CD structure will work well. • CC and CD teams have been found to produce fewer defects than DD teams, but these data have much to do with the specific quality assurance activities that are applied by the team. • Decentralized teams generally require more time to complete a project than a centralized structure and at the same time are best when high sociability is required.

19. Second P - Product Customers and software developers must meet • To define objectives and scope of the project. • To consider alternative solutions and to select the best possible approach. • To identify technical and management constraints. • Objectives identify the overall goals for the product (from the customers’ point of view) without considering how these goals will be achieved. • Scope identifies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner.

20. The Product Scope • Scope • Context.How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? • Information objectives.What customer-visible data objects are produced as output from the software? What data objects are required for input? • Function and performance.What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? • Software product scope must be unambiguous and understandable at the management and technical levels.

21. Second P - Product • If scope and objectives are not defined, then it will be impossible: • To define a reasonable and accurate estimate of cost. • To assess possible risks • To define a manageable project schedule.

22. Problem Decomposition • Sometimes called partitioning or problem elaboration. • Once scope is defined … • It is decomposed into constituent functions • It is decomposed into user-visible data objects or • It is decomposed into a set of problem classes • Decomposition process continues until all functions or problem classes have been defined

23. Third P – The Process • The project manager must decide which process model is appropriate for: • The customers who have requested the product and the people who will do the work • The characteristics of the product itself • The project environment in which the software team works. • When a process model has been selected, define a preliminary project plan on the set of common process framework activities.

24. The Process Once a process framework has been established • Consider project characteristics • Determine the degree of rigor required • Define a task set for each software engineering activity • Task set : • Software engineering tasks • Work products • Quality assurance points • Milestones

25. The 4th P - The Project • For a successful project, we must understand what can go wrong • Projects get into trouble when … • Software people don’t understand their customer’s needs. • The product scope is poorly defined. • Changes are managed poorly. • The chosen technology changes. • Business needs change [or are ill-defined]. • Deadlines are unrealistic. • Users are resistant. • Sponsorship is lost [or was never properly obtained]. • The project team lacks people with appropriate skills. • Managers [and practitioners] avoid best practices and lessons learned.

26. Common Sense Approaches to Projects • Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. • Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way. • Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. • Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.” • Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.

27. Critical Practices • The Airlie Council (a team of software engineering experts chartered by the US Department of Defense to help develop guidelines for the best practices in software project management and software engineering) have developed a list of critical software practicesthat are used by and considered critical by, highly successful projects and organizations whose performance is much better than industry averages. • In an effort to enable a software organization to determine whether a specific project has implemented critical practices, the Airlie Council has developed a set of questions for a project.

28. Critical Software Practices • Formal risk management – What are the main risks for this project? What is the probability of the risks turning into a problem and what is the impact if it does? • Metric-based project management - Do we have a metrics program to give early indications of evolving problems? • People-aware program management – What is the average staff turnover for the past three months for each of the suppliers/developers involved in the development of software for this system? • Empirical cost and schedule estimation – What is the estimated size of the application software (excluding system software) that will be delivered into operation and how was it derived? • Defect tracking against quality targets – Is there a mechanism to periodicallytrack and report the number of defects found by each inspection?

29. Project Planning • Planning is deciding in advance: • what to do • how to do it • when to do it • who is to do it • The project plan sets out: • the resources available to the project; • the work breakdown; • a schedule for the work.

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

31. Types of Project Plan

32. Steps to Project Planning • Determination of the Software Scope • Estimation of the Resources Required. • Project Estimation • Decisions

33. Each resource is specified with four characteristics: • Description of the resource • a statement of availability • chronological order of time, and • duration of time that the resource will be applied. • Software Scope: • Already discussed • Resources:

34. Objectives of Project Planning Human Resources: • Human resource estimation is done by evaluating scope and selecting skills required to complete the process of development. • While larger projects and organizations can afford a large number of people, in smaller organizations with relatively smaller projects, the same people will perform all the roles. Re-useable Software Resources: • Software resources are primarily reusable building blocks. • These can be divided into four categories as described below: • Fully experienced components • Partial experience components • Off-the-shelf components • New components

35. Fully Experienced Components • These are the specifications, designs, code or test data that were developed for previous projects and are similar to the software that is to be built. • The team members are fully experienced in the application area represented by these components. • Not only will the time required to develop the project be lesser but also modifications required for such fully-experienced components will carry less risk.

36. Partial Experience Components • These are the specifications, designs, code or test data that were developed for previous projects and are somewhat similar to the software that is to be built but require substantial modifications. • The team-members are not very well experienced in the application area represented by these components. • Hence, these kinds of components will carry more risk. However, since the team has at least some experience on a similar project, the time taken for this will not be substantial.

37. Off-the Shelf and New Components • Off-the-shelf components • These are the components that can be acquired from a third party or may have been developed internally for a past project. • These components are ready to use and do not require any modification. • New components • Since these components do not exist in any form, new components have to be built by the team. • This is very time-consuming.

38. Other Resources • Other resources could be • The infrastructure in terms of hardware and software required to implement the project. • The platform or the operating system, • The necessary hardware components, • And additional software utilities that may be required – all come under this category.

39. Measure, Metrics, and Indicator • Measure -- Provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some product or process attribute. • Measurement occurs as the result of the collection of one or more data points (e.g., a number of module reviews are investigated to collect measures of the number of errors for each). • Metric -- A quantitative measure of the degree to which a system, component, or process possesses a given attribute. • Software Metrics -- refers to a broad range of measurements for computer software. • A software metric relates the individual measures in some way (e.g., the average number of errors found per review or the average number of errors found per person-hour expended on reviews). • Indicator -- a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.

40. Process Indicator • enable insight into the efficacy of an existing process. • to assess the current work status. • Goal -- to lead to long-term software process improvement. Project Indicator • assess the status of an ongoing project • track potential risks • uncover problem areas before they “go critical”. • adjust workflows or tasks. • evaluate the project team’s ability to control the product quality.

41. Process Metrics and Software Process Improvement Project Customer characteristics Business conditions Process People Technology Development environment

42. Measurement • What to measure? • errors uncovered before release. • defects delivered to and reported to end users. • work products delivered. • human effort expended. • calendar time expended. • schedule conformance. • At what level of aggregation? • By team? • Individual? • Project?

43. Person Month • Person month is the amount of time one person spends working on the software development project for one month. • This number is exclusive of holidays and vacations but accounts for weekend time off. • The number of person months is different from the time it will take the project to complete; this is called the development schedule. • "A project may be estimated to require 50 PM of effort but have a schedule of 11 months." • To translate percent effort into person months, use this formula: % Effort x # Months Pay x % Appointment = Person Months

44. Example Professor XYZ has an appointment for nine months. He will expend 10 percent of his effort on a postgraduate project for the academic year, and 66 percent effort in teaching undergraduate students for three months. Person months are calculated as follows:

45. Lines of Codes (LOC) • Length of a software system is measured in terms of lines of code (LOC). • This model assumes that there is a linear relationship between system size and volume of documentation. • LOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or effort once the software is produced. • Broadly speaking, there are two types of LOC: • Physical LOC: A count of lines in the text of the program's source code including comment lines. • Logical LOC: Logical LOC attempts to measure the number of "statements", but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like programming languages is the number of statement-terminating semicolons). • Some organizations do not count Blank and comments lines. However, some organizations also include blank lines unless the lines of code in a section consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.

46. LOC Based Estimation • Let us take one simple instance where different categories of programming tasks involved in the project are mapped with the estimated lines of code and approximate person-days to complete each task. • Effort is calculated based on the assumption that a person will write one KLOC of code per day. • The total effort as we can conclude from the table would be approximately 45 person days

47. Example for (i=0; i<100; ++i) { printf("hello"); } /* Now how many lines of code is this? */ In this example, we have: 4 physical LOC 2 logical LOC 1 comment line

48. A Model of Project Metrics • Every project should measure • Inputs—measures of the resources (e.g., people, environment) required to do the work. • • Outputs—measures of the deliverables or work products created during the software engineering process. • •Results—measures that indicate the effectiveness of the deliverables.

49. Software Metrics • Direct Measures: • Cost and effort applied. • Lines of Code (LOC) produced. • Execution speed • CPU utilization • Memory size • Defects reported over certain period of time. • Indirect Measures: • Functionality, quality, complexity, efficiency, reliability, maintainability.

50. Size-Oriented Metrics • are derived by normalizing quality and/or productivity measures by considering the “size” of the software that has been produced. • Lines of Codes often as normalization value. project LOC effort $(000) pp.doc errors defects people alpha 12,100 24 168 365 134 29 3 beta 27,200 62 440 1224 321 86 5 gamma 20,200 43 314 1050 256 64 6 . . . . . . . . . . . . . . . .