Managing Software Project — | Syllabus Software metrics (Process, Product and Project metrics, ; s ), Soft ject planning (MS project tool), Project scheduling and meet (ree estimations, Software | projec ys f 1 | (Risk idemiication, Rsk projection, Risk refinement, Rsk mitigang Mo and management | Contents es 3.1 Software Process and Project Metrics | 3.2. Software Measurement Peeters Winter-2017, Summer-2019 Marks 4 Summer-2013, 2014, Winter-2013, 2017, - - » Marks 7 3.3 Product Metrics 3.4 Software Project Estimations .............. Winter-2019, --- +--+ > ++. Marks 7 3.5 Software Project Planning 3.6 Project Scheduling and Tracking ........... Summer-2016, see eee eee eeeeene Winter-2018, 2019, : - » Marks 7 3.7 Risk Analysis and Management............ Winter-2011, Summer-2013, 2016, REE Eee eee rn 2018, 2019,------- +--+» + Marks 7 3.8 Risk Identification =... seve reese eens Summer-2011, ::----~ Marks 7 3.9 Risk Projection 3.10 Risk Refinement 3.11 Risk Mitigation wees vee eee eee ees Summer-2015, eee ar Winter-2018, -»-~ °° «°° Marks 7 Winter-2017, 2019, °°» Marks 7 B.12RiskPlan seer ernest3-2 Software Engineering ee A emcee Software Process and Project Metrics Software Process and Project Metrics are Quant tative measures that engineers to gain insight into the efficacy of the Software Process and ee Sah, The software measures are collected by software engineers and sof - analyzed by software managers. The work product of software metrics is a set of productivity metrics a4 i Fa, et, s metrics. Metrics in Process and Project Improvement Process metrics are the set of process indicators that are used to improve the ; processes. Process metrics is collected over the complete software life cyc See process can be improved with the help of process metrics. It can be illustrated as bey Measure specific attributes of the process NE” Fig. 3.1.1 Process improvement In making improvements to any software system, there are three basic quality faiss to consider : product, people, and technology. These three are the major determinans ¢ software cost, schedule, productivity, and quality. «The factor people includes hiring the best people you can find, motivating then = do the best job, and training them on the skills needed to perform their jobs effectively. « The technology factor includes acquiring and installing tools that help automate. The technology also includes use of new software languages to develop the desired quality product (eg., Java, Visual C++, Oracle). ¢ The complexity of the factor product has great impact on Fig. 3.1.2 Quality factors for im quality and team performance. TECHNICAL PUBLICATIONS® - An up thrust for knowledge provementconware Engineering ing Software Project Out of these three components if one component is altered then it will impact other two factors, For example ; If an organization makes use of new testing tool (technology) then the staff (people) must be trained to work with this tool. The organization must consider if this new tool helps in generating the desired software product. + This process triangle resides within the circle. This circle specifies the environmental conditions such as : Customer characteristics(communication and collaboration between user and developer). © Business conditions( Organizational policies, Business rules) © Development environment (use of new technologies, use of automated tools). Grady suggested some guideline for collecting software metrics. These are known as Software Metrics Etiquette. These are as given below - 1. Never use metrics to please the individuals or to threaten the individuals or team. 2. Use common sense and organizational sensitivity while understanding the metrics data. 3. Collectively together with project manager and software team set the goals and use of metrics for the software. 4. The metrics data directs the area of process improvement. 5. Do not focus on single metrics so that other important metrics may get omitted. WS5HH Principle * Bary Bohem suggested an approach for addressing - project objectives, deciding milestones and schedules, roles and responsibilities, project management, technical approaches and required resources by WWWWWHH principle. The WSHH principle is nothing but the series of questions in the form of why, what, when, who, how and so on. * Answers to these questions lead to definition of key project characteristics. The answers of these questions are also useful in building the resultant project plan. * Following are those WSHH questions - 1) Why is the system being developed ? Answer to this question assesses the validit work. It also justifies the expenditure of people, time and money. 2) What will be done ? . Answer to this question will helj tasks and milestones. ity of business reasons for the software p the software team member to identify the project TECHNICAL PUBLICATIONS® - An up thrust for knowledge3-4 Mana, z 1g So a Software Engineering = 3) When will be done ? The answer to this question will help to prepare the project sched; ule With and milestones. ‘deny project tasks 4) Who is responsible for a function ? By answering this question, the roles and responsibilities is Te system can be defined. quited to devel 5) Where are they organisationally located ? ‘All the roles can not be defined within the software team itself. There users and other stakeholders holding some responsibilities. ONT a8 Co 6) How to do the job technically with proper management? Answer to this question will help to establish the technical strategy about th 7) How much of each resource required ? ee This answer will be useful for deriving the project estimate or cost of the project 1. Explain 4 P's of effective project management in det 2. Explain software project management and WSHH principle. Software Measurement and software Software measurement is an ability to measure attributes of software development process so that the software engineerin; ivities can be improve’ [—> Direct measure q (measures cost and effort applied, lines of code produced ,execution speed and defects) Software —4 measurement L_» indirect measure (measures functionality, quality, reliability. efficiency, maintainability, complexity) Fig. 3.2.1 Software meas urement ment of software can be classified into two categories - 5 the metrics based on these approaches ~ ont urable attributes: For exam"P The measure! Let us discus 1. Direct Metrics : of code, execution speed. _ CHNICAL PUBLICATIONS® - An up thrust for It refers to immediately meas' TEeS Engineering 3. sowere _ 5 Managing Software Project 2, Indirect Metrics ; It refers to the aspects that are not immediately quantifiable or measurable. For example-functionality of the program. pa Size Oriented Metrics + Size oriented measure is derived by considering the size of software that has been produced. The organization builds a simple record of size measure for the software projects It is built on past experiences of organizations. «+ It isa direct measure of software Project LOC Effort Cost($)_Doctpgs) Errors Defects People ABC 10,000 2a 400 100 2 4 por 20,000 60 300 1000 129 2 6 a7 7 XYZ 35,000 65 522 1290 "Table 3.2.1 Size measure + A-simple set of size measure that can be developed is as given below : s Size = Kilo Lines of Code (KLOC) Effort = Person/month «Productivity = KLOC/person-month Quality = Number of faults/KLOC = Cost = $/KLOC = Documentation = Pages of documentation/KLOC + The size measure is based on the lines of code comput defined as one line of text in a source file. code the Simplest Standard is : ation. The lines of code is © While counting the lines of = Don’t count blank lines, «Don’t count comments. = Count everything else. © The size oriented measure is not universally accepted method. Advantages 1. Artifact of software development whicl 2. Many existing methods use LOC as a key input. 3. A large body of literature and data based on LOC already exists. th is easily counted. TECHNICAL puBLICATIONS® = An up thrust for knowledgePO ae Managy ‘Software Engineering ing nn, Disadvantages 1 This measure is dependent upon the programming language . This measure is on Bet suffered 2. This method is well designed but shorter program may get fe non procedural languages. 3. It does not accommodat jovelopment it is difficult to estimate LOC 4. In early stage of di Function Oriented Metrics «The oriented model is based on functionality of the delivered application, © These are generally independent of the programming language used, © This method is developed by Albrecht in 1979 for IBM. It uses function fe * Function points are derived using: 1. Countable measures of the software requirements domain 2. Assessments of the software complexity. How to calculate function point 7 The data for following information domain characteristics are collected : 1. Number of user inputs - Each user input which provides distinct application, dat to the software is counted. 2. Number of user outputs - Each user output that provides application data to the user is counted, e.g. screens, reports, error messages. Number of user inquiries - An on-line input that results in the generation of some immediate software response in the form of an output. Number of files - Each logical master file, ie. a logical grouping of data that may be part of a database or a separate file. Number of external interfaces - All machine-readable interfaces that are used t» transmit information to another system are counted. The organization needs to develop criteria which determine whether a _ particular entry is simple, average or complex. w » a The weighting factors should be determined by observations or by experiments. Domain Characteristics Count Weighting factor mr Simple Average Complex Number of user input x 3 4 6 Number of user output x 4 5 7 __Number of user inguisies x 3 ~nnenenee’, 4 6 —— TECHNICAI PUBLICATIONS® - An un threes 4, s,,...,.,..Engineering . sonwen ORs Managing Sofware Project | rumber of files x 7 0 6 | J yumber of external x 5 7 a | Faterfaces | i Count Total The count table can be computed with the help of above given table. Now the software complexity can be computed by answering following, questions ‘These are complexity adjustment values, 1, Does the system need reliable backup and recovery ? 2, Are data communications required ? 4, Are there distributed processing functions ? 4, Is performance of the system 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 ? g, Are the master files updated on-line ? o, Are the inputs, outputs, files or inquiries complex ? 10. Is the internal processing complex ? 11. Is the code which is designed being reusable ? 12. Are conversion and installation included in the design ? 13. Is the system designed for multiple installations in different organizations ? 1U. Is the application designed to facilitate change and ease of use by the user ? + Rate each of the above factors according to the following scale : « Function Points (FP) = Count total x (0.65 + (0.01 x Sum(F))) 0 1 2 3 4 5 T T T T T T No. Incidental Moderate Average Significant Essential influence * Once the functional point is calculated then we can compute various measures as follows = Productivity = FP/person-month "Quality = Number of faults /FP = Cost = $/FP = Documentation = Pages of documentation/FP. TECHNICAL PUBLICATIONS® - An up thrust for knowiedgey Managir ee EID Sota Software Engineering _ - “Setter — » _ °F Advantages es. 1. This method is independent of programming languag, " sed on the data which can be obtained in early stage of projet 2. It is based on the Disadvantages i i te id can be 1) This method is more suitable for business systems an e Aevelopeg foe domain. tha 2) Many aspects of this method are not validated. 7 3) The functional point has no significant meaning. It is just a numerical value, Comparison between size oriented and function oriented metrics “tr, . Sr. No. Size oriented metrics Function oriented Metrics Size oriented software metrics is by Function oriented — metri Hdmi, nn, Ue thividering the size of the software measure of functionality delivereg y that has been produced. the software. For a size oriented metric the software Most Widely used function, Oriented GrBanization maintains simple records metric is the function Point (Fp) in tabular form. The ‘ypical table computation of the function point ig Panes are : Project name, LOC, Effort, based on characteristics of software's Pages of documents, errors, defects, information domain and complesty fotal number of people working on Project. CREIEED sists of reqirenent scsi for results : Need for 7 inputs, 10 outputs, Input and external interface functi ABC Project has produced following 6 inquiries, 17 files and 4 external interfaces 7 inputs 10 Outputs 6 inquiries 17 files 4 external interfaces lexity for inputs ang extemal interfaces, Low complexity for remains Parameters, Adjusted function Point value a) TECHNICAL Py) jns-,..®software Engineering 3-9 OO ———____ Managing Software Project Let us calculate count total value. Measurement parameters Count Weighting £ ting factor X Simple Average complex Number of user inputs 7 x 4 B Number of user outputs. 10 x 4 . 0 Number of user inquiries. 6 x 3 4 { 18 Number of files 7 x 7 19 Number of external interfaces. 4 x 7 _ B Count total (UFP) niin 2% Function point = UFP x [0.65 + 0.01 x E(F,)] = 233 x [0.65 + 0.01 x 32] = 233 x [0.65 + 0.32] 233 x 0.97 FP = 226.01 Hence adjusted function point is 226.01. Explain function point analysis method. Compute the function points for the = 12, Inquiries = 4, Logical files = 41, following data set : Inputs = 8, Outputs = Interfaces = 1 and 3 Fi = 41. Solution : The given functional units are 1. Inputs = 8 2. Outputs = 12 3. Inquiries = 4 4. Logical files = 41 5. Interfaces = 1 Jexity adjustment factors and weighting factors as average- Assume comp! UFP = 8x4412x5+4x4+41x10+1%7 = 32+60+16+410+7 UFP = 525 CAF = (0.65 + 0.01 SF) = 0.65 + 0.01 (41) = 1.06 FP = UP x CAF = 525 x 1.06 FP 556.5 ee ist for knowledge TECHNICAL PUBLICATIONS” - An up thrSofware Engineering BU Managing cy Object-Oriented Metrics hy, Lorenz and Kidd have proposed set of metrics for object oriented Project, Metrics Description Number of scenario scripts The number scenarios can be typically obta; m the use cases for the system. It basically tained by dey interaction with the applications. The total neces eh is dependant upon size of application and numbe Of ¥ == ~ - OF fag i, Number of key classes In any object oriented design classes are the gt the system. Hence total number of key eit eng ___Roresent the amount of effort rete to develo tna . i "ate, Number of support classes The support clases are logical entities requi 7 key classes. Thus total number of support a poe 5 amount of software reusability and total amoun fy, Average number of support There are more number of support class class per key class applications with GUT than applications veiw for by _ 2 this average number makes the design more simplified, "*¢ Number of subsystems Subsystem means aggregation of classes. To sched Project systematically it is necessary to ident tee subsystem of the system being developed. all ty EEZ] Attributes of Effective Software Metrics The effective software metrics should have following attributes, 1. Simple and computable - The derivation of metric should be easy to compute ag should not be a time consuming activity. 2. Empirically and intuitively persuasive - It should be immediate and can ty derived based on observations. 3. Consistent and objective - The metric should produce unambiguous reuls Anybody should get the same result by using these metrics when same sete information is used. 4. Consistent in its use of units and dimensions - The mathematical units ad dimensions used for the metric should be consistent. And there should not ® intermixing of units. 5. Programming language independent - The metric should be based on a ' model, design model and program structure. It should be independent programing languages, syntax or semantic of any programing language. tt 6. Metric should be effective mechanism for high quality feedback - The ™ should provide a way to produce high quality software product. TECHNICAL PUBLICATIONS® - An up thrust for knowledge asSoftware Engineerin sotwam ergroving 3-11 ___ Managing Sofware Pree 1. Explain di s pctrcs «Stee, fnctonal and complet = : fen ets Se, tna ad cmpety 2. Explain softoare metre Cictila sed for sofa cot estimation. EBD Product Metrics Product metrics are com puted from d ode and test ces. m data collected Metrics and Indicators from analysis and design models, Measures, or size 4, Measure : It is @ quantitative of some attribute of a product or process. : ' is the degree to which 2 system, component, or process possesses 4 en attribute. The software metrics relate several For example - ge number of errors found per review combination of metrics that provides insight into the indication of the extent, amount, dimension, giv |, measures. averat ators ; Indicators mean 3, Indic roject or product. software process, P! tes of Effective Software Metrics metrics should have follo jon of met wing attributes. tric should be €a8 Attribut ‘The effective software 4, Simple and computable - The derivati should not be a time cons’ i uD Empirically and intuitively persuasiv' derived based on ‘observations. 7 ive - The metric should produce unambiguous results. Anybody should get the same result by using these metrics when same set of its and dimensions - The mathematical units and metric should be consistent. And there should not be dimensions used intermixing of units. 5. Programming language independent ~ The metric should be based eel wre) Cea tructure- It should be indepen ming language metric st syntax OF semantic of any progra igh quality feedback * The vuality software product sy to compute and fe - It should be immediate and can be on analysis dent of __ _ © an up tmust for Knowle”Software Engineering _ Metrics For Analysis Model Metrics for the analysis model are useful in estimating the Project in. Sed a5 a me,” determine the metrics in analysis model “size” of the software is u: size of software is measured in LOC or FP. Metrics For Design Model We need metrics for design model for determining the meas; quality. This metric guides the software design activity as design evol urement of . ves, : Architectural Design Complexity ested three design complexity Measures ;. Two scientists Card and Glass has sugges © Structural complexity Structural complexi lepends upon the fan-out for modules. It can be defined 2 Fowl) Where fou epresents fan-out for module k[fan out means number of modules & are subordinating module k] © Data complexity Data complexity is the complexity within the interface of internal module. For ser: module k it can be defined as_ tot_ var(k) D(k) = — =A) : [out (K) +1] Where tot_var is total number of input and output variables going to and coming 0: of the module. © System complexity System complexity is the combination of structural and data complexity. It can b denoted as , Sylk) = S(k)+D(k) When structural, data and system complexity get increased the overall architectural complexity also gets increased. EREY Metrics for Object Oriented Design i . rable characteristi / re has suggested nine meas MSUCS Of object oriented design and Whitmi: those are - ing following factors. (See ed using fovowm Fig. 3. 1) Size - It can be meas asure representing the characteristics tne Next page.) 2) Complexity - It is 4 ch other. how the classes . ith ea are interrelated wi __—_—_— tons? - An Silt for gpssonware Engineering 3-13 Managing Software Project 3) Coupling - It is a measure ———~ Population : means total number of classes and stating the collaborations operations between classes or number of messages that can be passed [|——~ Volume: means total number of classes or between the objects. operations that ere collected dynamically 4) Completeness - It is the measure representing all the |——— Length: means otal number of interconnected ‘ of ‘ design elements requirements the design component. ion - It is the degree ~~ Functionality : is a measure of output delivered to 5) Cohesion er the customer by which the set of Fig. 3.3.1 Factors that determine the size Metrics properties that are working For Object Oriented Design together to solve particular property. 6) Sufficiency - It is the measure representing the necessary requirements of the design component. 7) Primitiveness - The degree by which the operations are simple. In other words, the measure by which number of operations are independent upon other. 8) Similarity - The degree to which two or more classes are similar with respect to their functionalities and behaviour. 9) Volatility - Due to changes in requirements or some other reasons modifications in the design of application may occur. Volatility is a measure that represents the probability of changes that will occur. These product metrics for object oriented design is applicable to design as well as analysis model. EER] User interface Design There are numerous methods for evaluating user interface. In this section we will discuss two such metrics proposed by different software practitioners. 1, Layout appropriateness Andrew Sears has suggested Layout appropriateness metric for the Ul design. The layout appropriateness requires description of sequence of the actions performed on layout entities such as icons, menus, windows and so on. In order to accomplish certain task using GUI the user makes transition from one layout entity to another. The Layout ae is a metric used for computing the “cost” of all the transitions made by Cost = yr [frequency of the transition * cost of the transition] All transitions in a layoutManaging », Sofwore Engineering iy Nar 2. Cohesion metrics \ The cohesion metrics can be defined as the Felative connection Of on. scregp ther sree ts. Ul cohesion for screen is high. Kokol hag Pe other on-screen contents a 7 empirical model for cohesion metrics for Ul design: It is suggested that the effective design of GUI can be done if it ig base, demands and needs. That means designed interface should satisfy the user, Metrics for Source Code Halstead’s complexity measurement was developed to measure @ program me complexity directly from source code, with emphasis on computational Complexity The Halstead's measures are based on four scalar numbers derived directly fro ¥ From Program's source code : ‘ nj, is number of distinct operators Nn is number of distinct operands N), is total number of operators N) is total number of operands From these numbers, five measures are derived : Measure Symbol Formula Program length N N=N, +N, Program vocabulary n n=nj +n) Volume v V=N* (log, n) Difficulty D D = (ny/2) * (N2/2) Effort _. E E=D*v Halstead's uses certain Measures such as volume, difficulty and effort for the that the program length can be cal The above given table shows how a The Halstead's measures are applicable to operational systems and to development efforts once the code has been written. Thus using Halstead's measurement experiments! verification can be performed in software science, Program length, program vocabulary siven algorithm. By this Halstead's is trying to show culated, volume of the algorithm can be estimated tually these measures can be obtained. Program length The length of a program is total usage of operators and operands in the program. Length = Ni+N> TECHNICAL PUB) Imarinn ©3.96 ring 7 a Managing Som, a M18 Project rogram vocabulary " cabulary is the number o The program vocabulary is the number of unique operator, And operands ited in 1 Vocabulary n= ny +n, program volume The program volume can be defined as minimum Number of bits needed led to ene the program. V = Nlogyn Length estimation N=n, log» nN +n log, np Guideline for calculating operands and operators 1. All the variables and constants are considered as operands, 2, Local variables with same name, if occu ring in different functions are counted as unique operand. » Function calls are considered as operators, > The looping statements, do ... while, while, for are operators. The else are operators. The switch case statements are considered The reserve words, return, default, continue, statements if, if as operators, break, sizeof are all operators, ne The brackets, commas, semicolons are operators, N The unary and binary operators are considered as Operators. The & is considered as operator. = In arrays, array name and index are considered as Operands and [ ] is considered as operator. 9. All hash directives can be ignored. 10. Comments are not considered. 11. In Goto statement, goto is considered as operator and label as operand. TECHNICAL PUBLICATIONS® - An up thrust for knowledge™ Seca ee Manag Sng, Pn, Sofware Engineering Obtain Hastend’s length and volume measure for following C funy, ey void swap (int a [ J, int i) { int temp ; temp = aj afi] = afi+1] afit+1] = temp ; Solution : We will first find out the operands and operators from above function slong y their occurrences. oo _ Operands Occurrences Operators Occurrences swap 7 1 po Osee 3 pesen! | we 5 0 ce i 5 void 1 | temp 3 int 3 i 1 2 iB 5 ny=5 N=Ni+No = 164+21=37 n=nj+n)=14 Estimated length = nj logn, + np log ny = 5log5+9 log 9 = 5*23249*219 11.60 + 19.77 = 31.37 " Volume = Nx log n = 37* log (14) Volume = 37+ 2.63 = 97.64 TECHNICAL PUBLICATIONS® - AN tan, the.»software Engineering a7 Managing Softwarn Project po Metrics for Testing jralstead’s metrics for estimating the testing efforts are as given below ‘The Halstead effort can be defined as e = V/PL where V is the program volume and PL is the program level. The program level can puted as PL = 1/l(ry/2) X (No/m,)} ‘The percentage of overall testing effort = testing effort of specific module/testing efforts of all the modules be com FEB Metrics for Maintenance of software product is given by an IEEE standard which suggests a The stability dex(SM1) for that matter. It is given as follows - metrics software maturity in gMI = (M- (A +C +D))/M Where, M = Number of modules in current version ‘A= Number of added modules in current version C = Number of changed modules in current version D = Number of deleted modules in current version compared to the previous version When SMI reaches to the value 1.0 the product becomes more and more stabilized. This SMI metrics is used for planning the software maintenance activities EZ] Software Project Estimations PGTU : Winter-2019, Marks 7] Software project estimation is just similar to problem solving. Many times the Hence for solving such problem to be solved is too complex in software engineering, problems, we decompose the given problem into a set of smaller problems. tion of problem or ; The decomposition can be done using two approached decomposi lecomposition of process. Estimation uses one ‘or both forms of decomposition (partitioning). Software Sizing °K ollowing are certain issues based on which accuracy of software project estimate is predicated - TECHNICAL PUBLICATIONS® - An up thrust for knowledge3-18 Mr, The degree to which planner has properly estimated the yi, ; ; of my Pn to be built i" i r . The ability to translate the size estimate into human. effort, Caen, ‘Software Engineering ting money The degree to which the project plan reflects the abilities of soft 78 tear, ¢ stability of product requirements and the environment that g 4. The software engineering effort. © Sizing represents the project planner's first major challenge, Ih the . project planning, size refers to a quantifiable outcome of the Software i et , * The sizing can be estimated using two approaches - a direct approach lines of code is considered and an indirect proach in which cone ti function point is done. « Putnam and Myers suggested four different approaches for sizing the Probe 1. Fuzzy logic sizing In this approach planner must identify - © The type of application © Establish its magnitude on a qualitative within the original range. © Planner should also have access to historical database of the projct sp : estimates can be composed to actual experience. ty i hi, my scale and then refine the magni 2. Function point sizing Planner develops estimates of the information domain. 3. Standard component sizing There are various standard components used in software. These components a subsystems, modules, screens, reports, interactive, programs, batch program, files, LOC and Object-level instruction. The project planner estimates the number of time these standard components a used. He then uses historical project data to determine the delivered size per stand! component. 4. Change sizing This approach is used when existing software has to be modified as pe ™ avail Of the project. The size of the software is then estimated by the number type of reuse, addition of code, change made in the code, deletion of code. TECHNICAL PUBLICATIONS® . An up thrust for knowledgeSoftware Engineering Problem based Estimation . The problem based estimation is conducted ; du estimation, process based estimation and 1 ise Managing Setar Preyact using, LOC based estimation, °P based ; cased based - ream 0 estimation can FP based data are used in two ways during soft a Z software estimation are useful to estimate the size each elernent of ot _ nent of software 2. The baseline metrics are col collected from past , Project and LOC and FP dat used " ae with estimation variable to der lop 7 pe ae y " elop cost and effort vanes for the project. (LOC) and (FP) estimation are different ame to iques. Yet, both have number of characteristics in common a With a bounded statement of software sc begin: ‘ope a project planning proe by using the statement of scope the software problem is eg < Fe functions that can be estimated individually. : Ou (LOC) or (FP)is then estimated for each function. Baseline productively metrics are then applied to the appropriate estimation variable and cost or effort for the function is derived. » Function estimates are combined to obtain an overall estimate for the entire “project. © Using historical data the project planner expected value by considering following Pe variables - 1. Optimistic 2. Most likely 3.Pessimistic For example, following formula $= [Sop + 4° Sm +S pesel/6 e estimation size variable, Sope ’ estimate where S is the te and Spess considers for "most likely’ Sm represents the most likely estuna! _ represents the optimistic estimate, _ represents the pessimistic estimate values. Example of LOC based Estimation Consider an ABC project with some important modules such as 1. User interface and control facilities 2. 2D graphics analysis q 3. 3D graphics analysis 4, Database se 5, Computer graphics display facility 6. Peripheral contro 7. Design analysis models . Estimate the project in based on LOC oa For estimating the given application we consider een ‘ae “ ind corresponding lines of code can be estimated in the fo'0W 5 aa CATIONS”. rust for nowlodo® as separate function. An up (nt= ™“ “ eee ey Engineering " Sofware Function Estimated Log uni ICF Ben ies(UICF User Interface and Control Facilit “ 2D graphics analysis(2DGA) im 3D Geometric Analysis function(3DGA) 3 = Database Management(DBM) DF) 74H) Computer Graphics Display Facility(CGDF) : Peripheral Control Function(PCF) 7380, Design Analysis Modules (DAM) i 32629 Total Estimation in LOC * Expected LOC for 3D Geometric analysis function based on three poins tig oe © Optimistic estimation 4700 © Most likely estimation 6000 ° Pessimistic estimation 10000 S= [Sopt + (4* Sy) + Spess ]/6 Expected value = [4700 + (4 * 6000) + 10000] /6 — 6450 * A review of historical data indicates - 1. Average Productivity is 500 LOC per month 2. Average labor cost is $6000 Per month Then cost for lines of code can be estimated as cost/LOC = (6000/500) = $12 By considering total estimated LOC as 32620 * Total estimated Project cost = (32620*12) = $391440 * Total estimated Project effort = (32620/500) = 65 Person-months EZ Example of FP based Estimation n rather than software functions. Ths " Create a function point cal BC project, discussed in section 3.43. INFO DOMAIN Opt. ee ' A rP Most pessimistic esti. weight VALUE likely value factor NO.OF INPUTS 25 28 2 281 4 2eee sofware Engineering aa Managing Son No. OF OUTPUTS u ” 7 ohare Project v7 NO. OF INQURIES "7 B w 5 : 2A NO. OF FILES 5 5 > . 5 i By NoOF EXTERNAL 2 2 ; 0 8 INTERFACES 2 a e COUNT TOTAL wi «For this example we assume average com plexity weightin 8 factor. « Each of the complexity weighting factor adjustment factor is computed using the com the 14 questions) '8 estimated and the complex lexity factor table below. (Based on FACTOR aa VALUE (Fi, 1. Backup and recovery ? ; 2 Data communication ? 2 3, Distributed processing ? : 4 Performance critical ? 4 5, Existing operational environment ? ‘ & On-line data entry ? o 7, Input transactions over multiple screens? 5 8 Online updates ? 3 4, Information domain values complex ? 5 10. Intemal processing complex? 5 11, Code designed for reuse? 4 12 Conversion / installation in design? 3 13, Multiple installations? 5 14. _ Application designed for change ? oe 5 YF) > 2 The estimated number of adjusted FP is derived using the following formula : - FP ESTIMATED = (FP COUNT TOTAL * [COMPLEXITY ADJUSTMENT FACTOR] FP ESTIMATED = COUNT TOTAL* [0.65 + (0.01" ry (Fi) Complexity adjustment factor = [0.65 + (0.01 * 52)] = 1.17 / * FP ESTIMATED = (381 * 1.17) = 446 (Function point count adjusted with complexity adjustment factor) TECHNICAL PUBLIGATIONS® - An up thrust for knowied®Sofware Engineering Mh, ria, «A review of historical data indicates - Pg 1. Average productivity is 6.5 FP/Person month 2. Average labor cost is $6000 per month Caleulations for cost per function point, total estimated project cost =a 1. The cost per function point = (6000 / 6.5) = $923 tota) 2. Total estimated project cost = (446 * 923) = $411658 3. Total estimated effort = (446 / 65) = 69 Person-month, Cy Process based Estimation ¢ This is the most commonly used estimation technique for estimating the based on the processes used. Freq In this technique, the process is decomposed into telatively size set OF tasks the effort required to accomplish each task is estimated. a * The estimation begins with identification of software functions obtained from Project scope. Then a series of software process activities must be Performed fy each function. The function and software Process activities are presenteq ing tabular form. Then planner estimates the efforts for each software function. z Example of Process based Estimation Consider the same project described in section 3.4.3 We can estimate it using proces based estimation technique by creating a table as shown below. In this technique for each of the business function software engineering tasks such as analysis, design, coding and testing is carried out. The estimated efforts for each of these functions are identified and their sum is obtained. In the following table, the sum of all the rows and columns 8 taken and the effort for each business function is estimated in percentage. ACTIVITY CC Plannin Risk Engineering Construction CE TOTAL release analysis co ad Analysis Code Test Design BUSINESS FUNCTION J User interface nN 83 and control 0.50 275 0.50 4.50 re facilities(UICF)3-23 Managing Software Project 0.75 450° 075 200 = oN 800 A CC means customer communication CE means customer evaluation lated based on the total 48. The percentage effort is calcul the task Design as 22.25 For instance we get the total for 22.25#100/48 = 46 % approximately Thus the percentage efforts for all the software engineering t Based on average labor cost of $6000 per month 1. Total estimated project Effort = 48 persons-month 2. Total estimated project cost=(6000*48)=$288000 asks are computed. Estimation with Use-Cases * Use-cases also provide a softwat requirements. But there are some cases due to the following reasons «There are varieties of ways by WI unique format for them. ‘An up thrust for knowledge TECHNICAL PUBLICATIONS re team with insight difficulties in develop! described. There is n° — nich use cases can be eee3-24 Manag son, sotwere Engneery 7 1 external view (User's view) of the Software Jeecases represent al a Uses action. That means som, These ,, t levels of al ‘also written at differen . 4 y primary functions Be, may be written to expose only primary where a8 some on i cases may describe each function in more detail. «The complexity of the functions and features cannot be descripgy ' Y ae cases «The complex behaviour involved in many functions and features i, us, described in use cases. In spite of these difficulties the use cases can be used for estimation, but they are considered within the context of structured hierarchy that ae “ Che, describe. Smith argues that any level of structured hierarchy - 1 Can be described by at the most 10 Use-cases. 2 Each use-case would not contain more than 30 distinct scenarios. « Therefore before using the use cases for the estimation - © The level within the structured hierarchy must be established. © The average length of each use case must be determined. 2 The type of software application for which estimation is calculated must te defined. © The rough system architecture is defined. After establishing these characteristics, empirical data can be used to estimate LOC or FP for each use case. Then the structured hierarchical data can be used to compute the efforts required to develop the system. © Following formula is useful to compute this estimation - LOC estimates = N * LOC,,g + [(Sa/Sh - 1) + (Pa/Ph - 1] * LOCyijust where N = Actual number of Use-cases LOCayg = Historical average LOC / Use-case for this type subsystem LOC, sjust = Adjustment based on 'n %' of LOC, avg "= Defined locally and represents the difference between this proiect &™ ‘Average’ project Sa = Actual scenarios Per use-case Sh = Average scenarios per use-case for this type subsystem Pa = Actual pages per use-case Ph = ; Average pages Per use-case for this type of subsystem xin thug prs As clin Gant chart det CECE, | EEA Risk Analysis and Management | | | CURE Ee Definition of risk : The risk denotes the uncertainty that may occur in the digg ‘due to past actions and risk is something which causes heavy losses. = Definition of risk management : Risk management refers to the proce K 85 of deceon bse! on a evalunon of he factors ut teas fo the business Various activities that are carried out for risk management are - 1 Risk denifation 2. Rsk projection 5. Risk refinement 4 Risk mitigation, monitoring and management. } Software Risks ‘There are two characteristics of the risks 1 The risk may or ma 1 Tek Mot happen. It shows the uncertainty of the risks risks occu, unwanted consequences or loses will occur. Diterant type of isk 1 Pj sk Projet ths are in the te sf budget, schedule, staffing, rae sever then he ol at 2. Technical i These ik al auay and a then potential desi eae maeane pes harder toscive 3. Business risk When feasibility of of software Business risks can be further eee an be further categorized ag” MSPECt 'orized as then business risks occur 1) Market sk When customer for te, BMY 3 for this produ than 9g UE PPO an rss then they basicaly aft jet gels nce he” Projet risks become ig ioe Mio peas, ea etl ne Tene al ara, Yeti a y, ainations built but i called ut markt sk fue gee 2 following crag the company’s business policies then suc ii) Strategic risk - When a Pode but andi ct brings sna product gets developed, Tines, poor requirement specification and software scope. here are two types of known risks -poficabe and unpredictable sks project experience. For example Improper Reactive risk strategy Jk - When a product is built but how to sell is not clear then such 2 i) Sales 0 situation brings sales risk. jw) Management risk - When senor management othe responsible staff leaves the organization then management risk occurs 4) Budget risk - Losing the overall budget of the pret is called budget risk oC vein rea are ase [= sa sansone Lega = Precictabe nsks Fig. 37.4 Categorization of risk ‘Another categorization of risk proposed by Charette is - Known risks are those risk that are Known aks —~ identified after evaluating the project plan ‘These risks can also be identified from other | prose ts sources such as environment in which the “ Fig. 3.72 unrealistic dead Predictable risks are those risks tat can be tdeniied in advance based on PSS! Experienced and skilled staff leaving in between or vermanication with customer resuling in poor requirement speciicabon Unpredictable risks are those risks that can not be guessed eae. For example certain changes in Goverment policies may ae the business project. Reactive Vs. Proactive Risk Strategies Reactive and proactive risk strategies are the approaches use for mandeing the risks. nt Resctve risk management is a risk management strategy in WNGH when project ____gets into trouble then only corrective a Taken. But when such risks can not TECHNICAL PUBLICATIONS® nis ‘an wp thrust or knoe ——ota Engineering 3-34 C be managed and new risks come up one after the other, the softy ine ere wo dheogt In cael prbane. 2apsd NM “firefighting” activities, a ‘sctvitis ay + Resouces are utlized to mana to manage such risks. And i managed then projet sin danger. AE SR the ike do + In this strategy no preventive on als orcas nn” ome i taken bout the Zia. They ae bang ‘+ This is an older approach of risk management. Proactive risk strategy + Proactive risk sk management. strate considering the probable risk begins before the technical actly; + In this strategy poten lish ae identified identified first then their 4s analyzed. Such risks Tks are then specif according to their priorities (ie hy riorities (ie 1 What rte 2 aera pn Oe F892 Egg 90% mean by rk? Wt spr, rib 3 Wie . Write str nolo ik mengeney Srl pe of ater rik 4 Esplin rik monegnent 5 Balt and discuss the Us the pes of isk 6 ipl it manegenenn EET Risk identification Rk deni plan Risks idenahorscen oe define’ as the ication can be done by ide then idenifyin Ae to on =e, $0 aPproschgy “ ee 1. Generic risk i omy "isk identification - It includes = a ~SPredictable risks. | a da TECrmICAL PuBLICATIONS® . ay, ~ p ma —_- to software "hn gg Managing Sofware P)0Ct luct specific threat identification tin which the 3-38 ication - It includes prod specific risk identifi technology and working environmen' 2, Product by understanding people, product gets built: Normally the risk hho. follows. following StePS ~ identification is done by the project manager step 1 : Preparation of risk item check list “The risk items ean be identified using following j) Product size - The risk items based on ove identified, 1i) Business impact - Risk items related t predicted. ii) Customer characteristics - Risks ass communication can be identified. iw) Process definition - Risks that get process. This category exposes importan process definition made, is then followed by the whole team. Development environment - The risks associated with the technology and tool being used for developing the product. 1) Staff size and experience ~ Once the technology and too} related risks items are srentifed it is essential to identify the risk associated with sufficient highly experienced and skilled staff who will do the development vii) Technology to be built - complexity of the system should Pe understood and related risk items needs to be identified ‘After preparing a tisk item checklist a questionnaire i PX questions should be answered and based on these answers the i= particular risk item can be judged. Stop 2 : Creating risk components and drivers list. The set of risk components and drivers list is prepar occurrence. Then their impact on the project can be analysed. stand which are the risk components and drivers. known and predictable componen’s all size of the software product 's 10 the marketplace or management can be ciated with customer-developer ised with the definition of software t risks items because whichever is the pared. These set of pact or seriousness of fed along with their probability of Let us under Risk Components and Drivers US. Air force has written a guideline for risk identification which is based on identification of risk component and risks drivers. It has suggested following types of risk components - TECHNIGAL PUBLICATIONS® - An up thus fr knowledgeSofware Engnesng ee Mere Sovey, 1, Performance risk - It isthe degree of uncertainty that the product will satisfy the requirements 2 Cast risk = It is the degree of ‘uncertainty that the project will maintain the budget 3. Support risk - It is the degree of Uncertainty that the software Project being developed will be easy to correct, modify or adapt. 4 Scale ik 1s the degree of uncertainty thatthe software project will main, the schedule and the project will be delivered in time. Associated with these components are the risk dri |mpact of risk. These four risk drivers are listed below. Fig. 3.8.4 Components of risk vers that are used to’ analyse be ‘ach software component can be specified. -——— ' ' Neale Margnat Catastrophic ference between risk ‘components and risk drivers, 7 EEX Risk Projection : The rk Projection is also called rs estimation THe ae to ways by whe ik canbe rate | —_ robabily thatthe risks eal ' sea Cansequences of problems aesociaied iy thei “" ——___ og TECAMCAL PUBLCATIONS® Anse ram ge coors a7 Managing Sofware Pret sonar Ergneemg ar Sete Pet the overall accuracy of the risk projection in order to have clear estan ofthe software that i to be bul ‘These steps help to prioritize the risks. Once the sks are prioritized then it casy to allocate the resources for handling them. Pron becomes EME Buitaing Risk Table Building the risk table isthe simplest and most commonly used technique adopted a fect managers in order to project the risks. The sample risk table is as given below - cL’ Category Probability impact MMM | Peas caching aut 5 Camogie itt he team size sient Sat ax — Haye the salt ecved Sa ~~ en ann aa ‘ | Wat technology meet the Tecnology Seniors —- |b the sofware suragenent Envicunet Ot (Nepghle le building the risk table exten ote rae tare sto ll ent all prbbl sks with te lp of : risk can be . Eich rik is then categorized. As we know vron can 4) Project size b) Technology «) Customer d) Business ) Developing ‘environment. + Probability of occurrence of each ne the impact of each risk, * Then impact of each sik i assed. While ens aa aH each using the cost drives each component of real impact of parteuar Schedule) is assessed and it then averaged 10 4 risk risk is then estimated by each teem member ee ap tt TECHNICAL PUBLICATIONS «401?98 Mane909 Sete, 0 aragig Sctrs as = santos ra Stn Aer baling is table iis then sorted by probability and imp nk Bepoure = Probably of occurrence of sk Cost 2 Expos rbbity and high impact risks wil be at the top of the table any probably and bw input tsk wil be at the bottom of He iy oe ‘ofthe table is called first-order prioritization. 5. Then he projet manager goes trough this fistorder prioritized risk ay diosa horzonal ie at sone pot in the able Ths ie i called et of The rks table above the ct of ini ow considered fo further tik analy The nak ble below the ct offline is agtin sorted and second Prittizaton is applied on this table re ents were developed fom the scratch. Each component 3 coor and each LOC have an average cot of $10, Tae the 00 cited 0 Fist of all we will compute cast = Number of components‘LOC*cost of each LOC have on an average "sk exposure can be '5*500"10=$75000 fs en = Probabil x 5 The risk table above the cut-off line is having the risks with high probabiliy ‘Then Risk Exposure : Fomblty of xcurence of rk Cost high impact and such risks should occupy the significant amount of manageney 75000 ‘time. = $5750 6 All the sks that lie above the cut off line should be managed. Using i sitgaon, moitoring and management pl Thus ik exposure foreach rk fom rk ble saute. Theft tk eposre lan the lat column of the risk fale filled up of ll sks helps in determining the final cost ofthe project. EEE Assessing Risk impact Le : 1. How rk proton i cared out rik able? INK SS te ks input te fc ate consid + Nota of risk Risk Refinement Rak refinement isa process of specifying the rik in more detail The Fisk refinement «an be represented using CTC format suggested by D.P.Gluch, The CTC stands for condition -trnstionconsquence. The conion is first stated and then based on this condition sub Scope ofthe risk * Timing at which risk occurs, Nature of risk denotes 10 deere the ipa 1 he pay Sere} ERED Risk mitigation == 2 be ong "luli and average "Sof sk (reormance, St, support and schedule) MMM stands fo 2. Using risk ‘driver iia wd There are three yg oar L Risk avoidance 2 Risk monitoring 3. Risk management. Rsk mitgation Risk, hl, man "PM MH) te impact of sk o te Baton means preventing the rsks to occuisk avoidance). Flowing are the be taken for ‘mitigating the risks. 1 “inicate with the concemed staff to find of probable risk Fd out and el ‘isk before the project starts, liminate al those causes that can create ease eel eaeemsaeneeennnan ee TECHICAL PUBLICATIONS® An up at or knowiagest sonwere Engineering 3, Develop a policy in an organization which though some staff leaves the organization. ‘4, Everybody in the project feam should be acquainted with the current d activity. will help to continue the py ding documents in timely manner, This the standards set by the organization. der to speed up the work. 6. Conduct timely reviews in 0) ty during software development, provi 7. For conducting every critical activi additional staff if required. Risk monitoring In risk monitoring process followin 4g things must be monitored by the manager, 1. The ay roach or the behaviour ofthe fam members as Pressure of roject vars PP ris | 2. The degree in which the team performs with the spirit of “team-work”. oagin ‘Assigned to “caoho is responsible for maiigaes, the risk 3 The type of co-operation among the team members ihe ersan oh hastened * 2 eo ee an 5 Availabilty of jobs within and outside the organization. Refinement/Context “The project manager should monitor certain mitigation steps. For example. | etme inormaton for Pk MEMEN If the current development activity is monitored continuously then everybody int Mitigation Monitor tater team will get acquainted with current development activity. aarer the mitigationhnonitorng Pe ee ore gextContingency PIE ‘The objective of risk monitoring is ees mitigation fils the plan for honing I —— eae eee ee | status - vee a ane pr rc cee = fo ensure def to ai e 2 Tew so aa oom the risk are applied properly oF not taming ae he a entry os mH ae fo gather mation wh can be ae useful for analyzing the risk: — Risk management ‘name and signature Project manager performs this tak when risk becomes a reality. If Project mars The "sok formation a risk info much documenting the risks successful in applying the spleen ” in aly igation effectively then it becomes very ae peop ae leaving the ore eee et ee ro available, if current ivity ‘everybody in the team, if latest and systemz ie = creboay th een wstematic documentation is available the? 2"Y ferstand current development activity. This will ultimately continuing the work without any interval TECHNICAL PUBLICATIONS® - An up thrust for knowledge fagation, monstorin3-8 Meany Requirements Analysis and Specification modeling, Requirement specification (SRS). ‘Syllabus Understanding the requirement, Requirenent “Requirement analysis and requirement requirement elicitation, Requirement engineer? | Contents 44 Intrduetion ‘Summer-2016, Marks 7 42 resoamert xoretig Tk Winter-2017, css se Summer-2012, 2018, 2018,“ Marks 7 143. Iniiating Requirements Engineering Process 44. Elicting Requirements Winter-2013, Summer-2018, Marks 3 45. Developing Use Cases 46 Negotiating Requirements 47 Validating Requirements oo --- Summer-201, Marks 7 48 Priortizing Requirements | 49° Building Requirements Analysis Mode! 4.10 Elements of Requirements Analysis. «<=» --~ ‘Summer-2015, = Marks 7 oss $ummer-2016, Winter-2017, Marks 7 4.14 Scenario Based Modeling: - 4.12 Glass Based Modeling --- 4.19 Data Modeling 4.14 Flow Oriented Modeling -- 4.15 Behavioral Modeling Seman SntcetS)