Unit 5 Software Estimation PDF

Software Engineering COMP  Unit 5 Software estimation  Disclaimer The PowerPoint presentations of the Module COMP 20009.1 Software Engineering are created merely to guide me during the delivery of this module in my class. The content included in the slides are only indicative to remind...

Software Engineering COMP  Unit 5 Software estimation  Disclaimer The PowerPoint presentations of the Module COMP 20009.1 Software Engineering are created merely to guide me during the delivery of this module in my class. The content included in the slides are only indicative to remind me the sequence which I will be following during the delivery. The content presented in the slides is free from any plagiarism and copyright violations and wherever needed appropriate referencing/citations have been provided. In addition to the content in this PowerPoint presentations, I will also be verbally delivering other important content in the class as well as also writing on the board, some information related to the topic being covered wherever necessary. The student is therefore advised to refer to the text books, reference books and any supplementary materials recommended in the Module Information Guide (MIG) or in the PowerPoint presentations for complete understanding of the topic.  Contents covered Observations on estimation Project planning process Software scope & feasibility Resources - Human resources, Reusable software resources and environmental resources Software project estimation Decomposition techniques-Software sizing, LOC based estimation Estimation model-Basic COCOMO model.  Observations on estimation Planning requires technical managers and the software team to make an initial commitment Process and project metrics can provide a historical perspective and valuable input for generation of quantitative estimates Past experience can aid greatly Estimation carries inherent risk, and this risk leads to uncertainty The availability of historical information has a strong influence on estimation risk  When software metrics are available from past projects Estimates can be made with greater assurance Schedules can be established to avoid past difficulties Overall risk is reduced Estimation risk is measured by the degree of uncertainty in the quantitative estimates for cost, schedule, and resources Nevertheless, a project manager should not become obsessive about estimation Plans should be iterative and allow adjustments as time passes and more is made certain  Project planning process Establish project scope Determine feasibility Analyze risks Define required resources Determine human resources required Define reusable software resources Identify environmental resources Estimate cost and effort Decompose the problem Develop two or more estimates using different approaches Reconcile the estimates Develop a project schedule Establish a meaningful task set Define a task network Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms  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 Narrative Description of Software Scope: A narrative description of software scope is developed through comprehensive communication with all stakeholders involved in the project. This technique involves gathering insights, requirements, and expectations from various project stakeholders to create a detailed narrative that outlines the boundaries, goals, and deliverables of the software project. The narrative serves as a written confirmation of the project's objectives and provides a clear understanding of what the project is intended to achieve. Use Case Development by End Users: Alternatively, a set of use cases is developed by end users to define the scope of the software project. Use cases are specific scenarios or interactions that illustrate how users will interact with the software, describing the various external objectives the system needs to accomplish. End users play a crucial role in identifying and detailing these use cases, providing a user-centric perspective on the functionalities and features  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  Software Feasibility 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? Legal Operational  Technical Feasibility This involves assessing whether the proposed solution is achievable from a technical standpoint. Variables to consider include: a.Technology Stack: Choose appropriate programming languages, frameworks, and tools based on the app's requirements and the team's expertise. b.Integration: Determine how the app will interact with external services like banks, payment gateways, or APIs. c.Scalability: Ensure the chosen architecture can handle a growing user base and increased data load. d.Security: Plan for data encryption, secure authentication methods, and protection against potential vulnerabilities.  Financial Feasibility Evaluating the project's financial viability helps ensure that the startup can sustain the app's development and operation. Variables to consider include: a. Budget: Estimate development, testing, deployment, and ongoing maintenance costs. b. Revenue Model: Decide on pricing strategies, freemium options, or in-app purchases that align with the target audience's willingness to pay. c. Monetization Timelines: Predict when the app will start generating revenue and how long it might take to achieve profitability.  Operational Feasibility This focuses on whether the app can be smoothly integrated into the startup's operations. Variables to consider include: a. Internal Processes: Assess whether the startup's existing workflows can accommodate the app's data flows and customer support requirements. b. Training and Support: Plan for user onboarding, customer support, and potential updates that may require user re-training. c. Resource Availability: Ensure the startup has the necessary human resources, infrastructure, and time to commit to the app's development and ongoing management.  Legal and Regulatory Feasibility It's important to ensure the app complies with legal and regulatory frameworks. Variables to consider include: a. Data Privacy: Ensure the app adheres to data protection regulations like GDPR or HIPAA, depending on the app's user data handling. b. Financial Regulations: Investigate any financial laws or regulations related to personal finance apps, such as those governing transactions and financial advice. c. Licensing and Intellectual Property: Determine whether any third-party components or intellectual property rights need to be acquired or licensed.  Schedule Feasibility It is a crucial aspect of project management and software development. It evaluates whether a project can be completed within the defined time frame. It examines whether the project can meet its deadlines and milestones. Timely project completion is essential for organizations. Delays can lead to increased costs and missed opportunities. Variables to consider include: a.Project Complexity: Complex software with extensive features or intricate architectural requirements often necessitates a longer schedule. b.Available Resources: Adequate resources, including skilled personnel, equipment, and software tools, are essential for meeting project timelines. If there are resource shortages or limitations, it can lead to delays. It's vital to ensure that the necessary resources are available and allocated appropriately. c.Team Skills: The proficiency and expertise of the project team members are critical. A highly skilled team can work more efficiently and effectively, potentially reducing project duration. Conversely, a lack of expertise can result in delays due to learning curves and mistakes. d) Potential Risks: Identifying and assessing potential risks is a fundamental aspect of schedule feasibility analysis. Risks such as technical challenges, external dependencies, and unexpected obstacles can lead to schedule disruptions. Developing mitigation plans for these risks is essential to stay on track. e) Scope and Requirements: A well-defined project scope and clear requirements are crucial for estimating the schedule accurately. Changes in project scope or frequent modifications to requirements can extend the timeline significantly. Effective change management processes are needed to handle scope changes without derailing the schedule. f) Dependencies: Understanding project dependencies, both internal and external, is essential. Delays in dependent tasks or external factors can have a cascading effect on the project schedule. Managing dependencies and having contingency plans is vital. g) Buffer Time: Including some buffer or contingency time in the schedule to account for unexpected delays or changes is a prudent practice. It provides flexibility in case unforeseen issues arise.  Resource Feasibility Resource feasibility in the context of project management refers to assessing whether the necessary resources are available and adequate to execute a project successfully. Several factors should be considered when evaluating resource feasibility: Human Resources: Availability of skilled personnel with the required expertise; assessing if the team has the necessary skills and experience to complete the project; evaluating the team's capacity and workload to ensure they can meet project timelines. Financial Resources: Determining the budget required for the project; assessing the availability of funds and financial stability; considering the cost of resources, materials, and equipment. Physical Resources: Availability of physical assets like office space, equipment, and infrastructure; ensuring that facilities are adequate for the project's needs. Technological Resources: Availability of technology and software tools required for the project; evaluating if the existing technology infrastructure can support the project's requirements. Time: Evaluating if the project can be completed within the allocated timeframe; considering any time constraints or deadlines. Resource Allocation: Efficiently allocating resources to different project tasks; balancing resource allocation to avoid bottlenecks or overloading certain areas.  Software Resources Three major categories of software engineering resources Human Resources Reusable software resources Environmental resources  Software Resources Human Resources: For small projects, a single individual may perform all software engineering tasks (a few person-months PM) For larger projects, the software team may be dispersed across a number of different locations. Hence, the location of each human resource is specified. The number of people required for a software project can be determined only after an estimate of development effort (person-months PM) is made.  Software Resources Reusable software: Off-the-shelf components. Existing software that can be acquired from a third party or from a past project Full-experience components: past projects components that are similar to the software to be built for the current project. Partial-experience components: past projects components that are related to the software to be built for the current project but will require substantial modification. New components. Software components must be built by the software team specifically for the needs of the current project.  Software Resources Environmental Resources Environment that supports a software project - hardware and software. Hardware provides a platform that supports the tools (software) required to produce the work products  Decomposition techniques- Software sizing Function point sizing Develop estimates of the information domain characteristics external input, external output, external inquiries, internal logical files, external interface files(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 References 1. Pressman, R.S(2004). Software engineering: a practitioner’s approach, NewYork:Mc.Grawill 2. Somerville, Ian(2001), Software engineering, Boston: Addison- Wesley. BASIC COCOMO MODEL The COCOMO (Constructive Cost Estimation Model) is proposed by DR. Berry Boehm in 1981  According to him software cost estimation should be done through three stages: Nipun Tomar (2012), COCOMO 1/ COCOMO'81: Constructive Cost Estimation Model, [online] available from https://www.c-sharpcorner.com/uploadfile/nipuntomar/cocomo-1-cocomo81-constructive-cost-estimat ion-model [ 12 March 2012]  Development Modes Basic COCOMO model compute software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code (SLOC, KLOC). Project are categorized into three types: Organic Semidetached Embedded  DEVELOPMENT MODES Organic Mode: Relatively Small, Simple Software projects. Small teams with good application experience work to a set of less than rigid requirements. Similar to previously developed projects. Relatively small and require little innovation. Semidetached Mode: Intermediate (in size and complexity) software projects teams with mixed experience levels mix of rigid and less than rigid requirements. Embedded Mode: Software projects that must be developed within set of tight hardware, software and operational Constraints.  Development Mode with Project Characteristics Development Mode Project Characteristics Size Innovation Deadline Dev. Environment ORGANIC Small Little Not Tight Stable SEMI-DITACHED Medium Medium Medium Medium EMBEDDED Large Greater Tight Complex Hardware Nipun Tomar (2012), COCOMO 1/ COCOMO'81: Constructive Cost Estimation Model, [online] available from https://www.c-sharpcorner.com/uploadfile/nipuntomar/cocomo-1-cocomo81-constructive-cost-estimatio n-model [ 12 March 2012]  BASIC COCOMO MODEL Basic COCOMO compute software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code (KLOC). Basic COCMO Model is good for quick, early, rough order of magnitude estimate of software cost. This model also estimates the total effort in terms of person-months of the technical project staff Definition is taken from Wikipedia. For more details you can refer this site: https://en.wikipedia.org/wiki/COCOMO The basic step of this models are: 1) Obtain initial estimate of the development effort Ei = a * (KLOC)b PM Where, KLOC is the estimated size of the software product expressed in Kilo Lines of Code, a, b are constants for each category of software products. 2)Determine a set of 15 multiplying factors from different attributes of the project (Effort Adjustment factor EAF) 3)Adjust the effort estimate by multiplying the initial estimate with all the multiplying factors E=EAF * Ei where E ,Effort is the total effort required to develop the software product, expressed in person months (PMs). EAF is effort adjusting factor Ei is the initial effort  4) Calculate the Nominal Development Time (estimated time to develop the software) Tdev = a1 x (E)b1 Months Where, a1, b1 are constants E is the total effort required to develop the software product. Multiplying Factors http://www.cs.unc.edu/~stotts/145/ cocomo6.gif  Estimation of development effort For the three classes of software products, the formulas for estimating the effort based on the code size are shown below: System a b Organic 3.2 1.05 Semidetached 3.0 1.12 Embedded 2.8 1.20 Nipun Tomar (2012), COCOMO 1/ COCOMO'81: Constructive Cost Estimation Model, [online] available from https://www.c-sharpcorner.com/uploadfile/nipuntomar/cocomo-1-cocomo81-constructive-cost-estimation-model[ 12 March 2012]  Estimation of development time For the three classes of software products, the formulas for estimating the development time based on the effort are given below: System a1 b1 Organic 2.5.38 Semidetached 2.5.35 Embedded 2.85.32 Nipun Tomar (2012), COCOMO 1/ COCOMO'81: Constructive Cost Estimation Model, [online] available from https://www.c-sharpcorner.com/uploadfile/nipuntomar/cocomo-1-cocomo81-constructive-cost-estimation-model[ 12 March 2012]  Problem:1 Suppose a system for office automation must be designed. From the requirements ,it was clear that there will be four major modules in the system: data entry, data update, query and report generator. It is also clear from the requirements that this project will fall in organic category. The size for the different modules and the overall system were estimated to be: Data Entry 0.6 KDLOC Data update 0.6 KDLOC Query 0.8KDLOC Reports 1.0 KDLOC From the requirements ,the ratings of the different cost driver attributes were assessed. These ratings along with their multiplying factors are Complexity High 1.15 Storage High 1.06 Experience Low 1.13 Programmer Capability Low 1.17 Estimate: i. Initial Effort for developing the project ii. Final Effort iii. Nominal development time iv. Cost required to develop the product. Assume that the average salary of software engineers be OMR. 3000/- per month Solution As per the basic COCOMO estimation formula for organic software: Initial Effort (Ei ) = a * (KLOC)b (As it is organic project a= 3.2 b=1.05) Ei=3.2*(KLOC)1.05 Total Size of the project=0.6+0.6+0.8+1.0=3.0 KLOC Ei = 3.2 * (3)1.05 = 10.14 PM =10 PM Final effort( E ) = EAF * Ei Effort adjusting Factor EAF=1.15*1.06*1.13*1.17=1.61 E=1.61 * 10.14 =16.3 PM=16 persons/month  Nominal development time Tdev = a1 x (E)b1 Months = 2.5 * (E)0.38 = 2.5*(16)0.38 = 7.16 months =7 months Cost required to develop the product = Total months *salary =7*3000 =RO 21000  Problem: 2 Suppose a system for office automation must be designed. From the requirements ,it was clear that there will be four major modules in the system: data entry, data update, query and report generator. It is also clear from the requirements that this project will fall in organic category. The size for the different modules and the overall system were estimated to be: Data Entry 0.5 KDLOC Data update 1.6 KDLOC Query 0.8KDLOC Reports 1.2 KDLOC From the requirements ,the ratings of the different cost driver attributes were assessed. These ratings along with their multiplying factors are Complexity High 1.15 Storage High 1.06 Experience Low 1.07 Programmer Capability Low 1.17 Estimate: i. Initial Effort for developing the project ii. Final Effort iii. Nominal development time iv. Cost required to develop the product. Assume that the average salary of software engineers be OMR. 4000/- per month  Problem 3 Suppose a system for office automation must be designed. From the requirements ,it was clear that there will be four major modules in the system: data entry, data update, query and report generator. It is also clear from the requirements that this project will fall in semidetached category. The size for the different modules and the overall system were estimated to be: Data Entry 0.3 KDLOC Data update 2.5 KDLOC Query 1.7 KDLOC Reports 2.2 KDLOC From the requirements ,the ratings of the different cost driver attributes were assessed. These ratings along with their multiplying factors are Complexity High 1.15 Storage High 1.06 Experience Low 1.07 Programmer Capability Low 1.17 Estimate: i.Initial Effort for developing the project ii.Final Effort iii.Nominal development time iv.Cost required to develop the product. Assume that the average salary of software engineers be OMR. 4500/- per month  References 1. Nipun Tomar (2012), COCOMO 1/ COCOMO'81: Constructive Cost Estimation Model, [online] available from https://www.c-sharpcorner.com/uploadfile/nipuntomar/ cocomo-1-cocomo81-constructive-cost-estimation- model[ 12 March 2012]  References. Pressman, R.S. Software engineering: a practitioner’s approach. McGraw‐ Hill.,2004 http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/srinivasan/01- 291999.html referenced 11/9/2006 http://www.infosys.tuwien.ac.at/se-book/slides/ referenced 16/9/2006 Below site will give you more details regarding COCOMO model http://www.cs.unc.edu/~stotts/145/cocomo.html Following sites will give you more details regarding software models http://istqbexamcertification.com/what-is-prototype-model-advantages-disadvantages- and-when-to-use-it/ https://www.technotrice.com/prototype-model/ http://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm https://watirmelon.blog/2015/02/02/iterative-vs-incremental-software-development/ http://softwareengineeringhub.blogspot.com/2010/03/evolving-role-of-software.html  Reference 1. Pressman, R.S(2004). Software engineering: a practitioner’s approach, New York,Ny:Mc.Grawill 2. Somerville, Ian(2001), Software engineering, Boston, MA: Addison-Wesley.