Chapter 5 Software Project Management Visit to more

Chapter- 5 Software Project Management Visit to more Learning Resources

Project Manager The following are the characteristics that defines an effective project manager 1. Problem solving: An effective software manager can diagnose the technical and organizational issues and systematically structure a solution or motivate other practitioners to apply the solution. 2. Managerial Identity: A good manager must take change of the project and must have confidence to assume control when necessary.

3. Achievement: To optimize the productivity of a project team, a manager must reward initiative and accomplishment of the practitioners. 4. Influence and Team Building: An effective project manager must be able to read people, he must be able to understand verbal and non verbal signals and react to the needs of the people sending these signals. The manager must remain under control in high stress situation.

Software Team The best team structure depends on the management style of your organization, the number of people who will populate the team and their skill levels, and the over all problem difficulty. The following seven project factors that should be considered when planning the structure of software engineering teams: >The difficulty of the problem to be solved. >The “size” of the resultant programs in lines of code or function points. >The time that the team will stay together. 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 required for the project.

Agile Team 1. The agile team is a very active team. 2. It encourages customers satisfaction by early incremental delivery of software. 3. It provides small and highly motivated project teams. 4. This is an highly motivated team who provides minimal software engineering work product.

Product 1. The product objectives and scope should be identified. 2. Objectives identify the overall goals for the product without considering how these goals will be achieved. 3. Scope identifies the primary data, functions and behaviors that categorize the product. 4. It identifies cost, risk and realistic break, downs of project task.

Process 1. The process model is the plan to be selected depending on following factors a) Customers and developers. b) Characteristics of product itself. c) Project environment of software team. 2) Regardless of the size and type of project these are small number of framework activities that are applicable to all of them. 3) There also umbrella activities like SQA, that occur throughout the system.

Project To manage a successful software project , we must understand what can go wrong. 10 signs that indicate that an information systems project is moving towards failure 1. Software people dont understand their customers needs. 2. The product scope is poorly defined. 3. Changes are managed poorly. 4. The chosen technology changes. 5. Business needs change. 6. Deadlines are unrealistics.

7. Users are resistant. 8. Sponsorship is lost. 9. The project team lacks people with appropriate skills. 10. Managers avoid best practices and lessons learned.

Project Scheduling 1. In project management, a schedule consist of a list of project terminal elements, with intended start date and finish date. 2. The major activity carried out in s/w project scheduling is that it distributes estimated efforts across the planned project period by allocating the effort to particular s/w engineering tasks. 3. There are many tasks in a s/w project. The project manager defines all the task and generates the schedule. 4. Initially a macroscopic schedule is developed, identifying all major process framework

Factors that delay Project Schedule Although there are many reasons why software is fail, most can be traced to one or more of the following root causes: 1. An unrealistic deadline established by someone outside the software team and forced on managers and practitioners. 2. Changing customer requirements that are not reflected in schedule changes. 3. An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job.

4. Predictable and/or unpredictable risks that were not considered when the project commenced. 5. Technical difficulties that could not have been foreseen in advance. 6. Human difficulties that could not have been foreseen in advance. 7. Miscommunication among project staff that results in delays. 8. A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.

Principles of Project Scheduling i. Compartmentalization: The project must be compartmentalized into a number of manageable activities and tasks. ii. Interdependency: The interdependency of each compartmentalized activity or task must be determined. iii. Time allocation: Each task to be scheduled must be allocated some number of work units (e. g. , person‐days of effort). iv. Effort validation: the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.

v. Defined responsibilities: Every task that is scheduled should be assigned to a specific team member vi. Defined outcomes: Every task that is scheduled should have a defined outcome. Vii. Defined milestones: Every task or group of tasks should be associated with a project milestone. viii. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

Project schedule can be tracked by using different scheduling tools and techniques. Program Evaluation Review Technique (PERT) i. PERT, is used in projects that have unpredictable tasks and activities such as in research and development projects. ii. It utilizes three estimates of the time to complete the project: the most probable, the most promising, and the most unfavorable. iii. It is a probabilistic tool using several estimates to determine the time completion of the project and to control the activities involved in the project so that it will be completed faster and at a lower cost.

Critical Path Method (CPM) i. CPM is a technique that is used in projects that have predictable activities and tasks such as in construction projects. ii. It allows project planners to decide which aspect of the project to reduce or increase when a trade-off is needed. iii. It is a deterministic tool and provides an estimate on the cost and the amount of time to spend in order to complete the project. iv. It allows planners to control both the time and cost of the project.

Disadvantage of PERT and CPM 1. The Program Evaluation and Review Technique (PERT) is a project management technique or tool which is suitable for projects that have unpredictable activities while the Critical Path Method (CPM) is a project management tool which is suitable for projects that have predictable activities. 2. CPM uses a single estimate for the time that a project can be completed while PERT uses three estimates for the time that it can be completed. 3. CPM is a deterministic project management tool while PERT is a probabilistic project

Time-Line Charts or Gantt chart: A time-line chart can be developed for the entire project or separate charts can be developed for each project function or for each individual working on the project. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamonds indicate milestones.

Concept of Task Network A task network, also called an activity network, is a graphic representation of the task flow for a project. It is sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool. In its simplest form, the task network depicts major software engineering tasks. The concurrent nature of software engineering activities leads to a number of important scheduling requirements. In addition, the project manager should be aware of those tasks that lie on the critical path. That is, tasks that must be completed on schedule if the project as a whole is to be completed on schedule.

Ways of Project Tracking: - can be accomplished in different ways: Conducting periodic project status meetings in which each team member reports progress and problems. Evaluating the results of all reviews conducted throughout the software engineering process. Determining whether formal project milestones have been accomplished by the scheduled date. Comparing actual start-date to planned start-date for each project task. Meeting informally with practitioners to obtain their subjective assessment t of progress to date and problems on the horizon.

Risk Management Software risk : A software risk is anything which can cause a delay in software or stops the progress of a system or even terminates the software project. Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is generally caused due to lack of information, control or time. A possibility of suffering from loss in software development process is called a software risk. Loss can be anything, increase in production cost, development of poor quality software, not being able to complete the project on time.

Concept of Proactive and Reactive risk strategies Reactive: 1. Majority of the software teams and managers rely on this approach i. e. , nothing is done about risks until something actually goes wrong. 2. Here when something goes wrong the team files into action and attempts to correct the problem. 3. Here disaster management or risk management is the choice of management technique.

Proactive: 1. Here the primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risk in a controlled and effective manner. 2. Here the proactive strategy start in the early of project development. 3. Possibilities and types of risks are identified, they are checked and arranged as per their priority and impact and prioritized according to their importance. 4. Then after ranking the risk the main plan of the project team is to avoid the risk.

Types of Software Risks There are two basic types of risks: (a) Generic Risk is the general purpose possible threat to every software product. (b) Product Specific Risk Product Specific risk can be find out only by those with a clear understanding of the technology going to be used for that project, the people and the environment that is particular to the software that is to be built.

Different Categories of Risks: (a) Project Risk: - Threaten the project plan. That is if project risk become real it is likely that project schedule will slip and that costs will increase. Project risks identity potential budgetary, schedule, personnel, resource, customer and requirement problem. (b) Technical Risk: - Threaten the quality and timeliness of the software to be produced. If technical risk becomes real, implementation may become difficult or impossible. (c) Business Risk: - Threaten the viability of the software to be built. Business risk often jeopardizes the product or the project.

(d) Market Risk: - Building product that no one wants (e) Strategic Risk: - Building a product that no longer fits into the business strategy (f) Management Risk: - Building a product that the sale force doesn‘t understand. (g) Budget Risk: - Losing budgetary or personnel commitment

Risk Assessment Risk assessment involves the evaluation of the risk. We take a triplet into consideration for understanding risk assessment in detail [ri, li, xi] In the triple ri stands for risk, li stands for likelihood that is probability of the risk, and xi represents impact of the risk. In initial stages of project planning a risk is stated generally. As the time passes, it is important to divide that risks into sub types and try to refine it.

Risk identification can be defined as systematic attempt to specify or find out threats to the project plan. Project plan includes estimation, resource distribution etc. With the help of finding well known and predictable risks, the project manager or leader can take first step to deal with or avoid them. These risks need to be controlled or avoided as per its form. There are two different types of risk Product specific risk and generic risk.

Risk Analysis After identification of the risk, risk analysis has to be done. The process of risk analysis is analyzing the potential risks with its types and details. The time and efforts needed for risks analysis are huge. Analysis starts with what risks are there, their probability and consequences with their impact on the project.

Risk refinement : In initial stages of project planning a risk is stated generally. As the time passes it is important to divide that risks into its sub types and try to refine it. The way to refine risk is to represent the risk in condition – transition – consequence i. e. CTC format. The risk can be stated as follows. <Condition>(Possibly)<Consequence>

Risk Prioritization For the purpose of deciding the priority of the risk, process called as risk prioritization is used. When first four columns of the risk table are filled with the risk related data, the table needs to be sorted by probability and by impact. The risk with high probability and high impact risks are located at the top of the table. The risks with low probability go to the bottom of the table after sorting. This is called as first order prioritization of the risks.

The project manager analyses the sorted risk table and defines the cutoff line. It is a horizontal line at some point in the table. The risk above this line will be given more attention. The risks below the line will be again reviewed and evaluated. After this, again second order prioritization of the risk below cut off line is done.

RMMM strategy To assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning. If a software team adopts a proactive approach to risk avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation.

Risk Mitigation To mitigate this risk, you would develop a strategy for reducing turnover. Among the possible steps to be taken are: • Meet with current staff to determine causes for turnover (e. g. , poor working conditions, low pay, competitive job market). • Mitigate those causes that are under your control before the project starts. • Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. • Organize project teams so that information about each development activity is widely dispersed.

Define work product standards and establish mechanisms to be sure that all models and documents are developed in a timely manner. • Conduct peer reviews of all work (so that more than one person is ―up to speed). • Assign a backup staff member for every critical technologist

Risk Monitoring As the project proceeds, risk-monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, the general attitude of team members based on project pressures, the degree to which the team has jelled, interpersonal relationships among team members, potential problems with compensation and benefits, and the availability of jobs within the company and outside it are all monitored.

Risk Management In addition to monitoring these factors, a project manager should monitor the effectiveness of risk mitigation steps. Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. It is important to note that risk mitigation, monitoring, and management (RMMM) steps incur additional project cost. For example, spending the time to backup every critical technologist costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them.

Software Configuration Management (SCM) is also known as change management. Changes can occur at any point of a time and that too because of any reason throughout the life cycle. Sources of change can be: Change in a product requirement and business rule because of new business or market conditions. Modification in data, functionality, services etc. Reorganization or business growth Redefinition of product because of budgetary and scheduling constraints.

Elements of software configuration management system Four important elements that should exist when a configuration management system is developed: Component elements -a set of tools coupled within a file management system (e. g. , a database) that enables access to and management of each software configuration item. Process elements -a collection of actions and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering, and use of computer software.

Construction elements -a set of tools that automate the construction of software by ensuring that the proper set of validated components (i. e. , the correct version) have been assembled. Human elements-a set of tools and process features (encompassing other CM elements) used by the software team to implement effective SCM.

Need of SCM 1. Identify change or changes. 2. Keep control on change. 3. For ensuring that change is properly implemented. 4. Make report of changes and present it to the people who have interest in that.

Benefits of SCM 1. Changes can be made with ease throughout software development process. 2. Changes are systematically recorded. 3. Changes are available whenever required for review. 4. Different version of software project can be created and process can be continued for long time. 5. Repository is available in the form of database. 6. Every object's detail can be stored with its attributes. 7. Changes can be traced in forward and backward direction. 8. Customer requirements are fulfilled by accepting changes. 9. It is one of the activities of software quality assurance that supports validation as well as verification. 10. Avoids lot of confusion because of change in software project.

Software Configuration Management Activities/Process Identification of change To control and manage configuration items, each must be named and managed using an objectoriented approach Basic objects are created by software engineers during analysis, design, coding, or testing Aggregate objects are collections of basic objects and other aggregate objects An entity-relationship (E-R) diagram can be used to show the interrelationships among the objects

Software Configuration Management Activities Identification of change To control and manage configuration items, each must be named and managed using an objectoriented approach Basic objects are created by software engineers during analysis, design, coding, or testing Aggregate objects are collections of basic objects and other aggregate objects An entity-relationship (E-R) diagram can be used to show the interrelationships among the objects

Version Control Combines procedures and tools to manage the different versions of configuration objects created during the software process An entity is composed of objects at the same revision level A variant is a different set of objects at the same revision level and coexists with other variants A new version is defined when major changes have been made to one or more objects

Change Control Change request is submitted and evaluated to assess technical merit and impact on the other configuration objects and budget Change report contains the results of the evaluation Change control authority (CCA) makes the final decision on the status and priority of the change based on the change report. Software Configuration Audit A software configuration audit complements the formal technical review by assessing a configuration object for characteristics that are generally not considered during review. The audit asks and answers the questions such as: Has the change specified in the ECO been made? Have any additional modifications been incorporated? Has a formal technical review been conducted to assess technical correctness?

Status Reporting Configuration status reporting (sometimes called status accounting) is an SCM task that answers the following questions: 1. What happened? 2. Who did it? 3. When did it happen? 4. What else will be affected?

SCM Repository Functions Data integrity: It ensure consistency among related objects. Information sharing: Sharing information among multiple developers, multiple tools, manages and controls multiuser access to data. Tool integration: Establishes data model that can accessed by many software engineering tools, controls access to data. Data integration: Provides data base functions that allow various SCM task to be performed on one or more Software Configuration Items(information as part of project). Methodology enforcement: Defines an entity relationship model stored in repository for software engineering. Document standardization: It is a standard approach for creation of software engineering documents.

SCM Tool Features Versioning - control changes to all work products before and after release to customer. Dependency tracking and change management - tracking relationships among multiple versions of work products to enable efficient changes (link management) Requirements tracing – depends on link management, provides the ability to track all work products that result from a specific requirements specification (forward tracing) and to identify which requirement generated by any given work product (backward tracing) Configuration management – works closely with link management and versioning facilities to keep track of a series of configurations representing project milestones or production releases Audit trails - establishes additional information about when, more Details contact where, why, and by whom changes were made For us