After establishing a goal on the effort front, we need to establish the goal for delivery schedule. With the effort estimate (in person-months), it may be tempting to pick any project duration based on convenience and then fix a suitable team size to ensure that the total effort matches the estimate. However, as is well known now, person and months are not fully interchangeable in a software project. Person and months can be interchanged arbitrarily only if all the tasks in the project can be done in parallel, and no communication is needed between people performing the tasks. This is not true for software projects—there are dependencies between tasks (e.g., testing can only be done after coding is done), and a person performing some task in a project needs to communicate with others performing other tasks.
As Brooks has pointed out 16, “. Man and months are interchangeable only for activities that require no communication among men, like sowing wheat or reaping cotton. This is not even approximately true of software.”. However, for a project with some estimated effort, multiple schedules (or project duration) are indeed possible. For example, for a project whose effort estimate is 56 person-months, a total schedule of 8 months is possible with 7 people.
A schedule of 7 months with 8 people is also possible, as is a schedule of approximately 9 months with 6 people. (But a schedule of 1 month with 56 people is not possible. Similarly, no one would execute the project in 28 months with 2 people.) In other words, once the effort is fixed, there is some flexibility in setting the schedule by appropriately staffing the project, but this flexibility is not unlimited. Empirical data also suggests that no simple equation between effort and schedule fits well 72. The objective is to fix a reasonable schedule that can be achieved (if suitable number of resources are assigned). One method to determine the overall schedule is to determine it as a function of effort.
Effort Estimation In Software Engineering
Such function can be determined from data from completed projects using statistical techniques like fitting a regression curve through the scatter plot obtained by plotting the effort and schedule of past projects. This curve is generally nonlinear because the schedule does not grow linearly with effort. Many models follow this approach 2, 12. The IBM Federal Systems Division found that the total duration, M, in calendar months can be estimated by M = 4.1E.36.
In COCOMO, the equation for schedule for an organic type of software is M = 2.5E.38. As schedule is not a function solely of effort, the schedule determined in this manner is essentially a guideline. Another method for checking a schedule for medium-sized projects is the rule of thumb called the square root check 58. This check suggests that the proposed schedule can be around the square root of the total effort in personmonths. This schedule can be met if suitable resources are assigned to the project. For example, if the effort estimate is 50 person-months, a schedule of about 7 to 8 months will be suitable. From this macro estimate of schedule, we can determine the schedule for the major milestones in the project.
To determine the milestones, we must first understand the manpower ramp-up that usually takes place in a project. The number of people that can be gainfully utilized in a software project tends to follow the Rayleigh curve 71, 72. That is, in the beginning and the end, few people are needed on the project; the peak team size (PTS) is needed somewhere near the middle of the project; and again fewer people are needed after that. This occurs because only a few people are needed and can be used in the initial phases of requirements analysis and design. The human resources requirement peaks during coding and unit testing, and during system testing and integration, again fewer people are required. Often, the staffing level is not changed continuously in a project and approximations of the Rayleigh curve are used: assigning a few people at the start, having the peak team during the coding phase, and then leaving a few people for integration and system testing. If we consider design and analysis, build, and test as three major phases, the manpower ramp-up in projects typically resembles the function shown in Figure 4.1 58.
For ease of scheduling, particularly for smaller projects, often the required people are assigned together around the start of the project. This approach can lead to some people being unoccupied at the start and toward the end. This slack time is often used for supporting project activities like training and documentation. Given the effort estimate for a phase, we can determine the duration of the phase if we know the manpower ramp-up. For these three major phases, the percentage of the schedule consumed in the build phase is smaller than the percentage of the effort consumed because this phase involves more people. Similarly, the percentage of the schedule consumed in the design and testing phases exceeds their effort percentages.
The exact schedule depends on the planned manpower ramp-up, and how many resources can be used effectively in a phase on that project. Generally speaking, design requires about a quarter of the schedule, build consumes about half, and integration and system testing consume the remaining quarter. COCOMO gives 19% for design, 62% for programming, and 18% for integration.
Software Cost Components 1. Effort costs (dominant factor in most projects) salaries Social and insurance & benefits 2. Tools costs: Hardware and software for development Depreciation on relatively small # of years 300 K US$ 3. Travel and Training costs (for particular client) 4. Overheads(OH): Costs must take overheads into account costs of building, air-conditioning, heating, lighting costs of networking and communications (tel, fax, ) costs of shared facilities (e. G library, staff restaurant, etc. ) depreciation costs of assets Activity Based Costing (ABC) Software Engineering SW Cost Estimation Slide 8.
Lines Of Code (LOC) l l Program length (LOC) can be used to predict program characteristics e. Person-month effort and ease of maintenance What's a line of code? The measure was first proposed when programs were typed on cards with one line per card How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line?
L l What programs should be counted as part of the system? Assumes linear relationship between system size and volume of documentation Software Engineering SW Cost Estimation Slide 14. Object Points (for 4 GLs) l l l Object points are an alternative function-related measure to function points when 4 Gls or similar languages are used for development Object points are NOT the same as object classes The number of object points in a program is a weighted estimate of The number of separate screens that are displayed The number of reports that are produced by the system The number of 3 GL modules that must be developed to supplement the 4 GL code C: SoftwareEngCocomoSoftware Measurement Page, COCOMO II, object points. Htm Software Engineering SW Cost Estimation Slide 36. Estimation techniques l There is no simple way to make an accurate estimate of the effort required to develop a software system: Initial estimates may be based on inadequate information in a user requirements definition The software may run on unfamiliar computers or use new technology The people in the project may be unknown l Project cost estimates may be self-fulfilling The estimate defines the budget and the product is adjusted to meet the budget Software Engineering SW Cost Estimation Slide 45.
Algorithmic Cost Modelling l l Most of the work in the cost estimation field has focused on algorithmic cost modelling. Costs are analysed using mathematical formulas linking costs or inputs with METRICS to produce an estimated output.
The formula is based on the analysis of historical data. The accuracy of the model can be improved by calibrating the model to your specific development environment, (which basically involves adjusting the weighting parameters of the metrics). Software Engineering SW Cost Estimation Slide 58.
COCOMO II l COCOMO II is a 3 -level model that allows increasingly detailed estimates to be prepared as development progresses Early prototyping level Estimates based on object points and a simple formula is used for effort estimation Early design level Estimates based on function points that are then translated to LOC Includes 7 cost drivers Post-architecture level Estimates based on lines of source code or function point Includes 17 cost drivers l Five scale factors replace COCOMO 81 ratings (organic, semi -detached, and embedded) Software Engineering SW Cost Estimation Slide 71. Early prototyping level - COCOMO II l Suitable for projects built using modern GUI-builder tools Based on Object Points l l Supports prototyping projects and projects where there is extensive reuse Based on standard estimates of developer productivity in object points/month Takes CASE tool use into account Formula is PM = ( NOP ´ (1 -%reuse/100 ) ) / PROD PM is the effort in person-months, NOP is the number of object points and PROD is the productivity Software Engineering SW Cost Estimation Slide 72. Early Design Level: 7 cost drivers - COCOMO II l l Estimates can be made after the requirements have been agreed Based on standard formula for algorithmic models Effort for Manually developed code PM = A ´ Size. B ´ M + PMm Effort for Manual adaptation of Automatically generated code M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED A = 2.
Estimation In Software Engineering
5 in initial calibration, Size: manually developed code in KLOC Exponent B. varies from 1. 24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity. B is calculated using a Scale Factor based on 5 exponent drivers PMm: represents manual adaptation for automatically generated code Software Engineering SW Cost Estimation Slide 73.
Problem Based Estimation In Software Engineering
The Exponent B Scale Factor(SF) - COCOMO II l l Exponent B for effort calculation B = 1. 01 x sum SF (i), i=1, 5 SF = Scale Factor l Each SF is rated on 6 -point scale (ranging from 0 to 5): very low (5), low ( 4), nominal (3), high (2), very high (1), extra high (0) l 5 Scale Factor (exponent drivers) Precedenteness Development flexibility Architecture/risk resolution Team cohesion Process maturity Ex: 20 KLOC ^ 1. 26 / 20 KLOC ^ 1. 11 Software Engineering SW Cost Estimation Slide 76. Post-architecture stage - COCOMO II l l Uses same formula as early design estimates Estimate of size is adjusted to take into account Requirements volatility: Rework required to support change Extent of possible reuse: Reuse is non-linear and has associated costs so this is not a simple reduction in LOC ESLOC = ASLOC ´ (AA + SU +0. 3 IM)/100 ESLOC is equivalent number of lines of new code. ASLOC is the number of lines of reusable code which must be modified, DM is the percentage of design modified, CM is the percentage of the code that is modified, IM is the percentage of the original integration effort required for integrating the reused software.
SU is a factor based on the cost of software understanding, AA is a factor which reflects the initial assessment costs of deciding if software may be reused. Software Engineering SW Cost Estimation Slide 79. COCOMO II Post Architecture Effort Multipliers (17 multipliers) l Product attributes (5 multipliers) concerned with required characteristics of the software product being developed l Computer attributes (3 multipliers) constraints imposed on the software by the hardware platform l Personnel attributes (6 multipliers) multipliers that take the experience and capabilities of the people working on the project into account. L Project attributes (3 multipliers) concerned with the particular characteristics of the software development project Software Engineering SW Cost Estimation Slide 80. Project duration and staffing - COCOMO II l l As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required Calendar time can be estimated using a COCOMO II formula TDEV = 3 ´ (PM)(0. 01)) PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model).
This computation predicts the nominal schedule for the project l The time required is independent of the number of people working on the project Software Engineering SW Cost Estimation Slide 88.
The National Programme on Technology Enhanced Learning (NPTEL) is a project funded by the Ministry of Human Resource Development (MHRD). It provides e-learning through online Web and Video courses in Engineering, Sciences, Technology, Management and Humanities.
Staffing level estimation It is necessary to determine the staffing requirement for the project. Putnam first studied the problem of what should be a proper staffing pattern for software projects. He extended the work of Norden In order to appreciate the staffing pattern of software projects, Norden’s and Putnam’s results must be understood.
Norden’s Work Norden studied the staffing patterns of several R & D projects. He found that the staffing pattern can be approximated by the Rayleigh distribution curve Norden represented the Rayleigh curve by the following equation: E = K/t²d. t.
May 31, 2018 - Drag On Opposite If H2o mediafire links free download, download Drag On Opposite of H20 (2000)www highqualitysound blogspot com, Drag. Drag on opposite of h20 rar.
e-t² / 2 t²d Staffing level estimation For more details here is the attachment.