Effective Software Project Management Concepts and Strategies

Computer Engineering Department Software Engineering & UML(CE0616) Project Management Concepts & Project Metrics Presented By Prof. Bhumi Shah

The Management Spectrum Effective software project management focuses on these items (in this order) The people Deals with the cultivation of motivated, highly skilled people Consists of the stakeholders, the team leaders, and the software team The product Product objectives and scope should be established before a project can be planned The process The software process provides the framework from which a comprehensive plan for software development can be established The project Planning and controlling a software project is done for one primary reason it is the only known way to manage complexity In a 1998 survey, 26% of software projects failed outright, 46% experienced cost and schedule overruns 2

People Product Process Project 3

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

The People: Team Leaders Competent practitioners often fail to make good team leaders; they just don t have the right people skills Qualities to look for in a team leader Motivation the ability to encourage 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 Team leaders should use a problem-solving management style Concentrate on understanding the problem to be solved Manage the flow of ideas Let everyone on the team know, by words and actions, that quality counts and that it will not be compromised 5

The People: Team Leaders (continued) Another set of useful leadership traits Problem solving diagnose, structure a solution, apply lessons learned, remain flexible Managerial identity take charge of the project, have confidence to assume control, have assurance to allow good people to do their jobs Achievement reward initiative, demonstrate that controlled risk taking will not be punished Influence and team building be able to read people, understand verbal and nonverbal signals, be able to react to signals, remain under control in high-stress situations 6

The People: The Software Team Seven project factors to consider when structuring a software development team The difficulty of the problem to be solved The size of the resultant program(s) in source lines of code 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 (communication) required for the project 7

The People: The Software Team (continued) Four organizational paradigms for software development teams Closed paradigm traditional hierarchy of authority; works well when producing software similar to past efforts; members are less likely to be innovative Random paradigm depends on individual initiative of team members; works well for projects requiring innovation or technological breakthrough; members may struggle when orderly performance is required Open paradigm hybrid of the closed and random paradigm; works well for solving complex problems; requires collaboration, communication, and consensus among members Synchronous paradigm organizes team members based on the natural pieces of the problem; members have little communication outside of their subgroups 8

The People: The Software Team (continued) Five factors that cause team toxity (i.e., a toxic team environment) A frenzied work atmosphere High frustration that causes friction among team members A fragmented or poorly coordinated software process An unclear definition of roles on the software team Continuous and repeated exposure to failure How to avoid these problems Give the team access to all information required to do the job Do not modify major goals and objectives, once they are defined, unless absolutely necessary Give the team as much responsibility for decision making as possible Let the team recommend its own process model Let the team establish its own mechanisms for accountability (i.e., reviews) Establish team-based techniques for feedback and problem solving 9

The People: Coordination and Communication Issues Key characteristics of modern software make projects fail scale, uncertainty, interoperability To better ensure success Establish effective methods for coordinating the people who do the work Establish methods of formal and information communication among team members 10

Group Dynamics Based on studies published by B. Tuckman in 1965 Updated later in 1977 Group dynamics concern how groups form, their structure and process, and how they function. Group dynamics are relevant in both formal and informal groups of all types. In an organizational setting, groups are a very common organizational entity and the study of groups and group dynamics is an important area of study in organizational behavior. Describes a four-stage model Forming Storming Norming Performing 11

Group Dynamics Model Forming:concerned with forming a group. This stage is characterized by members seeking either a work assignment (in a formal group) or other benefit, like status, affiliation, power, etc. (in an informal group). Members at this stage either engage in busy type of activity or show apathy. Storming:formation of dyads and triads Members seek out familiar or similar individuals and begin a deeper sharing of self. Continued attention to the subgroup creates a differentiation in the group and tensions across the dyads / triads may appear. Pairing is a common phenomenon. 12

Group Dynamics Model Norming:more serious concern about task performance The dyads/triads begin to open up and seek out other members in the group. Efforts are made to establish various norms for task performance. Members begin to take greater responsibility for their own group and relationship while the authority figure becomes relaxed. Performing: fully functional group where members see themselves as a group and get involved in the task Each person makes a contribution and the authority figure is also seen as a part of the group. Group norms are followed and collective pressure is exerted to ensure the Process of Group effectiveness of the group. 13

People Product Process Project 14

The Product The scope of the software development must be established and bounded 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 functions does the software perform to transform input data into output? Are there any special performance characteristics to be addressed? Software project scope must be unambiguous and understandable at both the managerial and technical levels 15

The Product (continued) Problem decomposition Also referred to as partitioning or problem elaboration Sits at the core of software requirements analysis Two major areas of problem decomposition The functionality that must be delivered The process that will be used to deliver it 16

People Product Process Project 17

The Process Getting Started The project manager must decide which process model is most appropriate based on 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 Once a process model is selected, a preliminary project plan is established based on the process framework activities Process decomposition then begins The result is a complete plan reflecting the work tasks required to populate the framework activities Project planning begins as a melding of the product and the process based on the various framework activities 18

People Product Process Project 19

The Project: Signs that it is in Jeopardy 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 poorly 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 20

The Project: A Common Sense Approach Start on the right foot Understand the problem; set realistic objectives and expectations; form a good team Maintain momentum Provide incentives to reduce turnover of people; emphasize quality in every task; have senior management stay out of the team s way Track progress Track the completion of work products; collect software process and project measures; assess progress against expected averages Make smart decisions Keep it simple; use COTS or existing software before writing new code; follow standard approaches; identify and avoid risks; always allocate more time than you think you need to do complex or risky tasks Conduct a post mortem analysis Track lessons learned for each project; compare planned and actual schedules; collect and analyze software project metrics; get feedback from teams members and customers; record findings in written form 21

The Project: The W5HH Principle A series of questions that lead to a definition of key project characteristics and the resultant project plan Why is the system being developed? Assesses the validity of business reasons and justifications What will be done? Establishes the task set required for the project When will it be done? Establishes a project schedule Who is responsible for a function? Defines the role and responsibility of each team member Where are they organizationally located? Notes the organizational location of team members, customers, and other stakeholders How will the job be done technically and managerially? Establishes the management and technical strategy for the project How much of each resource is needed? Establishes estimates based on the answers to the previous questions 22

Process,Project and Product Metrics

A Quote on Measurement When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science. LORD WILLIAM KELVIN (1824 1907) 24

Uses of Measurement Can be applied to the software process with the intent of improving it on a continuous basis Can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control Can be used to help assess the quality of software work products and to assist in tactical decision making as a project proceeds 25

Reasons to Measure To characterize in order to Gain an understanding of processes, products, resources, and environments Establish baselines for comparisons with future assessments To evaluate in order to Determine status with respect to plans To predict in order to Gain understanding of relationships among processes and products Build models of these relationships To improve in order to Identify roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance 26

Metrics in the Process Domain

Metrics in the Process Domain

Metrics in the Process Domain Process metrics are collected across all projects and over long periods of time They are used for making strategic decisions The intent is to provide a set of process indicators that lead to long- term software process improvement The only way to know how/where to improve any process is to Measure specific attributes of the process Develop a set of meaningful metrics based on these attributes Use the metrics to provide indicators that will lead to a strategy for improvement 29

Metrics in the Process Domain(continued) We measure the effectiveness of a process by deriving a set of metrics based on outcomes of the process such as Errors uncovered before release of the software Defects delivered to and reported by the end users Work products delivered Human effort expended Calendar time expended Conformance to the schedule Time and effort to complete each generic activity 30

Etiquette of Process Metrics Use common sense and organizational sensitivity when interpreting metrics data Provide regular feedback to the individuals and teams who collect measures and metrics Don t use metrics to evaluate individuals Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Never use metrics to threaten individuals or teams Metrics data that indicate a problem should not be considered negative Such data are merely an indicator for process improvement Don t obsess on a single metric to the exclusion of other important metrics 31

Metrics in the Project Domain

Metrics in the Project Domain Project metrics enable a software project manager to Assess the status of an ongoing project Track potential risks Uncover problem areas before their status becomes critical Adjust work flow or tasks Evaluate the project team s ability to control quality of software work products Many of the same metrics are used in both the process and project domain Project metrics are used for making tactical decisions They are used to adapt project workflow and technical activities 33

Use of Project Metrics The first application of project metrics occurs during estimation Metrics from past projects are used as a basis for estimating time and effort As a project proceeds, the amount of time and effort expended are compared to original estimates As technical work commences, other project metrics become important Production rates are measured (represented in terms of models created, review hours, function points, and delivered source lines of code) Error uncovered during each generic framework activity (i.e, communication, planning, modeling, construction, deployment) are measured 34

Use of Project Metrics (continued) Project metrics are used to Minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks Assess product quality on an ongoing basis and, when necessary, to modify the technical approach to improve quality In summary As quality improves, defects are minimized As defects go down, the amount of rework required during the project is also reduced As rework goes down, the overall project cost is reduced 35

Software Measurement

Categories of Software Measurement Two categories of software measurement Direct measures Software process (cost, effort, etc.) Software product (lines of code produced, execution speed, defects reported over time, etc.) Indirect measures Software product (functionality, quality, complexity, efficiency, reliability, maintainability, etc.) Project metrics can be consolidated to create process metrics for an organization 37

Size-oriented Metrics Derived by normalizing quality and/or productivity measures by considering the size of the software produced Thousand lines of code (KLOC) are often chosen as the normalization value Metrics include Errors per KLOC Defects per KLOC cost per KLOC Pages of documentation per KLOC eroors per person-month KLOC per person-month cost per page of documentation 38

Size-oriented Metrics 39

Size-oriented Metrics (continued) Size-oriented metrics are not universally accepted as the best way to measure the software process Opponents argue that KLOC measurements Are dependent on the programming language Penalize well-designed but short programs Cannot easily accommodate nonprocedural languages Require a level of detail that may be difficult to achieve 40

Function-oriented Metrics Function-oriented metrics use a measure of the functionality delivered by the application as a normalization value Most widely used metric of this type is the function point: FP = count total * [0.65 + 0.01 * sum (value adj. factors)] Function point values on past projects can be used to compute, for example, the average number of lines of code per function point 41

Function Point Metrics Function points are derived using an empirical relationship based on countable (direct) measures of software s information domain and qualitative assessments of software complexity. Information domain values are defined in the following manner

Information Domain Values Number of external inputs(EIs) Each external input originates from a user or is transmitted from another application They provide distinct application-oriented data or control information They are often used to update internal logical files Number of external outputs(EOs) Each external output is derived within the application and provides information to the user This refers to reports, screens, error messages, etc.

Information Domain Values (continued) Number of external inquiries(EQs) An external inquiry is defined as an online input that results in the generation of some immediate software response The response is in the form of an on-line output Number of internal logical files(ILFs) Each internal logical file is a logical grouping of data that resides within the application s boundary and is maintained via external inputs Number of external interface files(EIFs) Each external interface file is a logical grouping of data that resides external to the application but provides data that may be of use to the application

Function Point Computation 1) 2) Identify/collect the information domain values Complete the table shown below to get the count total Associate a weighting factor (i.e., complexity value) with each count based on criteria established by the software development organization Evaluate and sum up the adjustment factors Fi refers to 14 value adjustment factors, with each ranging in value from 0 (not important) to 5 (absolutely essential) Compute the number of function points (FP) FP = count total * [0.65 + 0.01 * sum(Fi)] 3) 4) 5)

Value Adjustment Factors 1) 2) Does the system require reliable backup and recovery? Are specialized data communications required to transfer information to or from the application? Are there distributed processing functions? Is performance critical? Will the system run in an existing, heavily utilized operational environment? Does the system require on-line data entry? Does the on-line data entry require the input transaction to be built over multiple screens or operations? Are the internal logical files updated on-line? Are the inputs, outputs, files, or inquiries complex? Is the internal processing complex? Is the code designed to be reusable? Are conversion and installation included in the design? Is the system designed for multiple installations in different organizations? Is the application designed to facilitate change and for ease of use by the user? 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14)

a Flow model for SafeHome User Interaction Function SafeHome user interaction function EIs: Password, Panic Button, Activate/Deactivate(3) EOs: Messages, Sensor Status(2) EQs: Zone, sensor inquiry(2) ILFs: System Configuration file(1) EIFs: test Sensor,zone setting,activate/deactivate,alarm alert(4)

SafeHome user interaction function Here we assume that sum(Fi ) is 46 (a moderately complex product). FP = count total * [0.65 + 0.01 * sum(Fi)] FP = 50 * [0.65 + (0.01 * 46)] FP = 55.5 (rounded up to 56)

Function Point Controversy Like the KLOC measure, function point use also has proponents and opponents Proponents claim that FP is programming language independent FP is based on data that are more likely to be known in the early stages of a project, making it more attractive as an estimation approach Opponents claim that FP requires some sleight of hand because the computation is based on subjective data Counts of the information domain can be difficult to collect after the fact FP has no direct physical meaning it s just a number 49

Reconciling LOC and FP Metrics Relationship between LOC and FP depends upon The programming language that is used to implement the software The quality of the design FP and LOC have been found to be relatively accurate predictors of software development effort and cost However, a historical baseline of information must first be established LOC and FP can be used to estimate object-oriented software projects However, they do not provide enough granularity for the schedule and effort adjustments required in the iterations of an evolutionary or incremental process The table on the next slide provides a rough estimate of the average LOC to one FP in various programming languages 50