Software Planning www.educlash.com

Problem Projects: Needs quantitative estimates and organized plan. Requirement changes as the project proceeds Important to define 1. Definition of problem 2. Scope of problem 3. Decomposition of problem www.educlash.com

Software Scope First activity in Project Management It can be the answers of 1. Context: How to make the system fit for all levels? What are the constraints for the same? 2. Information Objectives: What visible objects are projected as output. What input is required for the same. 3. Function and Performance: Regular functions (Input to Output) Special functions www.educlash.com

Problem Decomposition Defined as Partitioning Sits at the core of Requirement analysis. Two major areas: 1. Functionality – needs to be delivered. 2. The process – to deliver the same. Software functions – evaluated in the beginning Cost, Schedule estimation – based on decomposition Some degree of decomposition – always good. www.educlash.com

Software Metrics Measurement can be applied • to the software process with the intent of improving • to assist in estimation, quality control, productivity assessment, and project control • to help assess the quality of technical work products and to assist in tactical decision making as a project proceeds www.educlash.com

MEASURES , METRICS , AND INDICATORS a measure provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some attribute of a product or process. a metric as " a quantitative measure of the degree to which a system, component, or process possesses a given attribute”. an indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself . A software engineer collects measures and develops metrics so that indicators will be obtained . www.educlash.com

Project indicators enable a software project manager to assess the status of an ongoing project track potential risks uncover problem areas before they "go critical“ adjust work flow or tasks evaluate the project team's ability to control quality of software engineering work products. www.educlash.com

Cont… www.educlash.com

Project Metrics Used for strategic purposes by a project manager and a software team to adapt project work flow and technical activities . Project metrics on estimation effort and time duration estimates Production rates –pages of documentation, –review hours, –function points, –delivered source lines www.educlash.com

Con.. The intent of project metrics is twofold : –to minimize the development schedule, –to assess product quality on an ongoing basis and when necessary, modify the technical approach to improve quality. 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 www.educlash.com

SOFTWARE MEASUREMENT Direct measures (e.g., the length of a bolt) Indirect measures (e.g., the "quality" ) Direct measures –lines of code (LOC) –execution speed –memory size –defects reported over some set period of time Indirect measures ·functionality, quality, complexity, efficiency, reliability, ·maintainability and many other "abilities" www.educlash.com

Size-Oriented Metrics Derived by normalizing quality and or productivity measures by considering the "size" of the software www.educlash.com

Con.. A set of simple size -oriented metrics can be developed for each project: errors per KLOC (thousand lines of code) defects per KLOC $ per LOC pages of documentation per LOC other interesting metrics: errors/person-month LOC per person-month $/page of documentation www.educlash.com

Function-Oriented Metrics Use a measure of the functionality delivered by the application as a normalization value. Function-oriented metrics were first proposed by Albrecht. www.educlash.com

Con.. Number of user inputs. Each user input that provides distinct application oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately. Number of user outputs. Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, and so on. Individual data items within a report are not counted separately. Number of user inquiries. An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file), is counted. Number of external interfaces. All machine readable interfaces (e.g., data files on tape or disk) that are used to transmit information to another system are counted. www.educlash.com

COMPUTING FUNCTION POINTS Once the above data have been collected, a complexity value is associated with each count. For determining whether a particular entry, –simple, –average, –complex. To compute function points (FP), FP = count-total x [0.65 + 0.01 x SFi] The Fi ( i = 1 to 14) are "complexity adjustment values" www.educlash.com

Con… www.educlash.com

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

Feature point metrics FP doesn’t solve algorithmic complexity of a software. It implies that developing efforts of two functionally same programs are same. To resolve the same, feature point is proposed. It includes additional parameter – algorithmic complexity. More complexity of the function – greater efforts to develop it. These are language independent and easily computed from SRS document. www.educlash.com

Software Estimation Determine size of the product. From the size estimate, determine the effort needed. From the effort estimate, determine project duration, and cost. www.educlash.com

Software Cost Estimation www.educlash.com

Three approaches Empirical Heuristic Analytical www.educlash.com

Cost Estimation Techniques Empirical techniques: An educated guess based on past experience. Heuristic techniques: Assume that the characteristics to be estimated can be expressed in terms of some Mathematical expression. Analytical techniques: Derive the required results starting from certain simple assumptions. www.educlash.com

Empirical Estimation Techniques Expert Judgement: A guess made by an expert. Suffers from individual bias. Delphi Estimation: Overcomes some of the problems of expert judgement. www.educlash.com

Expert Judgment Technique Experts divide a software product into component units: e.g. GUI, database module, data communication module, billing module, etc. Add up the guesses for each of the components. Subject to human errors and individual bias. Experts may overlook some factors. Understanding all the aspects would be difficult. www.educlash.com

Delphi Estimation Team of Experts and a coordinator. Experts carry out estimation independently. Mention the rationale behind their estimation. Coordinator notes down any extraordinary rationale. Circulates among experts. Experts re-estimate. Experts never meet each other To discuss their viewpoints. www.educlash.com

Heuristic – COCOMO Model COCOMO (COnstructive COst MOdel) proposed by Boehm. Divides software product developments into 3 categories: Organic Semidetached Embedded www.educlash.com

Con.. Elaboration of Product classes Organic: Development of well understood appl. Program. Size is very small. Team members develop similar applications. Semidetached: If it contains the mix of experienced and inexperienced staff. Embedded: The software is strongly coupled to complex hardware, or real-time systems. www.educlash.com

Con.. Software cost estimation is done through three stages: Basic COCOMO, Intermediate COCOMO, Complete COCOMO. www.educlash.com

Basic COCOMO Model Gives only an approximate estimation: Effort = a1*(KLOC)a2 Tdev = b1*(Effort)b2 KLOC is the estimated kilo lines of source code, a1,a2,b1,b2 are constants for different categories of software products, Tdev is the estimated time to develop the software in months, Effort estimation is obtained in terms of person months (PMs). www.educlash.com

Development Effort Estimation Organic : Effort = 2.4*(KLOC)1.05 PM Semi-detached: Effort = 3.0*(KLOC)1.12 PM Embedded: Effort = 3.6*(KLOC)1.20 PM www.educlash.com

Development Time Estimation Organic: Tdev = 2.5*(Effort)0.38 Months Semi-detached: Tdev = 2.5*(Effort)0.35 Months Embedded: Tdev = 2.5*(Effort)0.32 Months www.educlash.com

Con. Development time sub linear function of product size. When product size increases two times, development time does not double. Time taken: almost same for all the three product categories. www.educlash.com

Con.. Development time is roughly the same for all the three categories of products: For example, a 60 KLOC program can be developed in approximately 18 months regardless of whether it is of organic, semidetached, or embedded type. There is more scope for parallel activities for system and application programs, than utility programs. www.educlash.com

Intermediate COCOMO Basic COCOMO model assumes effort and development time depend on product size alone. However, several parameters affect effort and development time: Reliability requirements Availability of CASE tools and modern facilities to the developers Size of data to be handled www.educlash.com

Con.. For accurate estimation, the effect of all relevant parameters must be considered: Intermediate COCOMO model recognizes this fact: refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost drivers (multipliers). www.educlash.com

Con.. If modern programming practices are used, initial estimates are scaled downwards. If there are stringent reliability requirements on the product : initial estimate is scaled upwards. Rate different parameters on a scale of one to three: Depending on these ratings, multiply cost driver values with the estimate obtained using the basic COCOMO www.educlash.com

Computer: Execution time, storage requirements, etc. Cost driver classes: Product: Inherent complexity of the product, reliability requirements of the product, etc. Computer: Execution time, storage requirements, etc. Personnel: Experience of personnel, etc. Development Environment: Sophistication of the tools used for software development. www.educlash.com

Shortcomings of two models Both models: consider a software product as a single homogeneous entity: However, most large systems are made up of several smaller sub-systems. Some sub-systems may be considered as organic type, some may be considered embedded, etc. for some the reliability requirements may be high, and so on. www.educlash.com

Complete COCOMO A Management Information System (MIS) for an organization having offices at several places across the country: Database part (semi-detached) Graphical User Interface (GUI) part (organic) Communication part (embedded) Costs of the components are estimated separately: Summed up to give the overall cost of the system. www.educlash.com

Con.. A Management Information System (MIS) for an organization having offices at several places across the country: Database part (semi-detached) Graphical User Interface (GUI) part (organic) Communication part (embedded) Costs of the components are estimated separately: summed up to give the overall cost of the system. www.educlash.com