Software Engineering

Software Engineering Unit 5Project Management Concepts Prepared By: PoojaMishra

The Management Spectrum The People The Product The Process The Project

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 • Different tasks set-tasks,milestones,work products and quality assurance • Finally Umbrella activities such as SQA and SCM are conducted. • The project The scope of the software development must be established and bounded

People Product Process Project

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

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 (More on next slide)

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

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 (More on next slide)

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 (More on next slide)

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

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 (More on next slide)

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

What are Metrics? Software process and project metrics are quantitative measures They are a management tool They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework Basic quality and productivity data are collected These data are analyzed, compared against past averages, and assessed The goal is to determine whether quality and productivity improvements have occurred The data can also be used to pinpoint problem areas Remedies can then be developed and the software process can be improved

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 (More on next slide)

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

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

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

Software Measurement

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

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 - Errors per person-month • Defects per KLOC - KLOC per person-month • Dollars per KLOC - Dollars per page of documentation • Pages of documentation per KLOC (More on next slide)

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

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)] • Material in Chapter 15 covered this in more detail • Function point values on past projects can be used to compute, for example, the average number of lines of code per function point (e.g., 60)

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

Object-oriented Metrics • Number of scenario scripts (i.e., use cases) • This number is directly related to the size of an application and to the number of test cases required to test the system • Number of key classes (the highly independent components) • Key classes are defined early in object-oriented analysis and are central to the problem domain • This number indicates the amount of effort required to develop the software • It also indicates the potential amount of reuse to be applied during development • Number of support classes • Support classes are required to implement the system but are not immediately related to the problem domain (e.g., user interface, database, computation) • This number indicates the amount of effort and potential reuse (More on next slide)

Object-oriented Metrics(continued) • Average number of support classes per key class • Key classes are identified early in a project (e.g., at requirements analysis) • Estimation of the number of support classes can be made from the number of key classes • GUI applications have between two and three times more support classes as key classes • Non-GUI applications have between one and two times more support classes as key classes • Number of subsystems • A subsystem is an aggregation of classes that support a function that is visible to the end user of a system

Metrics for Software Quality • Correctness • This is the number of defects per KLOC, where a defect is a verified lack of conformance to requirements • Defects are those problems reported by a program user after the program is released for general use • Maintainability • This describes the ease with which a program can be corrected if an error is found, adapted if the environment changes, or enhanced if the customer has changed requirements • Mean time to change (MTTC) : the time to analyze, design, implement, test, and distribute a change to all users • Maintainable programs on average have a lower MTTC

Defect Removal Efficiency • Defect removal efficiency provides benefits at both the project and process level • It is a measure of the filtering ability of QA activities as they are applied throughout all process framework activities • It indicates the percentage of software errors found before software release • It is defined as DRE = E / (E + D) • E is the number of errors found before delivery of the software to the end user • D is the number of defects found after delivery • As D increases, DRE decreases (i.e., becomes a smaller and smaller fraction) • The ideal value of DRE is 1, which means no defects are found after delivery • DRE encourages a software team to institute techniques for finding as many errors as possible before delivery

Integrating Metrics within the Software Process

Arguments for Software Metrics Most software developers do not measure, and most have little desire to begin Establishing a successful company-wide software metrics program can be a multi-year effort But if we do not measure, there is no real way of determining whether we are improving Measurement is used to establish a process baseline from which improvements can be assessed Software metrics help people to develop better project estimates, produce higher-quality systems, and get products out the door on time

Establishing a Metrics Baseline • By establishing a metrics baseline, benefits can be obtained at the software process, product, and project levels • The same metrics can serve many masters • The baseline consists of data collected from past projects • Baseline data must have the following attributes • Data must be reasonably accurate (guesses should be avoided) • Data should be collected for as many projects as possible • Measures must be consistent (e.g., a line of code must be interpreted consistently across all projects) • Past applications should be similar to the work that is to be estimated • After data is collected and metrics are computed, the metrics should be evaluated and applied during estimation, technical work, project control, and process improvement

Scope and Feasibility

Software Scope • Software scope describes • The functions and features that are to be delivered to end users • The data that are input to and output from the system • The "content" that is presented to users as a consequence of using the software • The performance, constraints, interfaces, and reliability that bound the system • Scope can be define using two techniques • A narrative description of software scope is developed after communication with all stakeholders • A set of use cases is developed by end users (More on next slide)

Software Scope (continued) • After the scope has been identified, two questions are asked • Can we build software to meet this scope? • Is the project feasible? • Software engineers too often rush (or are pushed) past these questions • Later they become mired in a project that is doomed from the onset

Feasibility • After the scope is resolved, feasibility is addressed • Software feasibility has four dimensions • Technology – Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs? • Finance – Is is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford? • Time – Will the project's time-to-market beat the competition? • Resources – Does the software organization have the resources needed to succeed in doing the project? Another view recommends the following feasibility dimensions: technological, economical, legal, operational, and schedule issues (TELOS)

Project Resources

Resource Estimation • Three major categories of software engineering resources • People • Development environment • Reusable software components • Often neglected during planning but become a paramount concern during the construction phase of the software process • Each resource is specified with • A description of the resource • A statement of availability • The time when the resource will be required • The duration of time that the resource will be applied Time window

Categories of Resources • People • Number required • Skills required • Geographical location • Development Environment • Software tools • Computer hardware • Network resources The Project • Reusable Software Components • Off-the-shelf components • Full-experience components • Partial-experience components • New components

Human Resources • Planners need to select the number and the kind of people skills needed to complete the project • They need to specify the organizational position and job specialty for each person • Small projects of a few person-months may only need one individual • Large projects spanning many person-months or years require the location of the person to be specified also • The number of people required can be determined only after an estimate of the development effort

Decomposition Techniques

Introduction • Before an estimate can be made and decomposition techniques applied, the planner must • Understand the scope of the software to be built • Generate an estimate of the software’s size • Then one of two approaches are used • Problem-based estimation • Based on either source lines of code or function point estimates • Process-based estimation • Based on the effort required to accomplish each task

Approaches to Software Sizing • Function point sizing • Develop estimates of the information domain characteristics (Ch. 15 – Product Metrics for Software) • Standard component sizing • Estimate the number of occurrences of each standard component • Use historical project data to determine the delivered LOC size per standard component • Change sizing • Used when changes are being made to existing software • Estimate the number and type of modifications that must be accomplished • Types of modifications include reuse, adding code, changing code, and deleting code • An effort ratio is then used to estimate each type of change and the size of the change The results of these estimates are used to compute an optimistic (low), a most likely, and a pessimistic (high) value for software size

Problem-Based Estimation • Start with a bounded statement of scope • Decompose the software into problem functions that can each be estimated individually • Compute an LOC or FP value for each function • Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person-month or FP/person-month) • Combine function estimates to produce an overall estimate for the entire project (More on next slide)

Problem-Based Estimation (continued) • In general, the LOC/pm and FP/pm metrics should be computed by project domain • Important factors are team size, application area, and complexity • LOC and FP estimation differ in the level of detail required for decomposition with each value • For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) • For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors • External inputs, external outputs, external inquiries, internal logical files, external interface files pm = person month

Problem-Based Estimation (continued) For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) Then the expected size value S is computed as follows:S = (Sopt + 4Sm + Spess)/6 Historical LOC or FP data is then compared to S in order to cross-check it

Process-Based Estimation • Identify the set of functions that the software needs to perform as obtained from the project scope • Identify the series of framework activities that need to be performed for each function • Estimate the effort (in person months) that will be required to accomplish each software process activity for each function (More on next slide)

Process-Based Estimation (continued) • Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity • Compute the total cost and effort for each function and each framework activity (See table in Pressman, p. 655) • Compare the resulting values to those obtained by way of the LOC and FP estimates • If both sets of estimates agree, then your numbers are highly reliable • Otherwise, conduct further investigation and analysis concerning the function and activity breakdown This is the most commonly used of the two estimation techniques (problem and process)

Empirical Estimation Models

Software Engineering