Scribd
Upload
7 views29 pages

Software Engineering - 4

Effective software project planning is crucial for project success, involving activities such as scope definition, risk management, and resource allocation. Managers must create and regularly update project plans to monitor progress and address potential issues, ensuring that projects stay on schedule and within budget. Cost estimation techniques, such as COCOMO, help in predicting development effort and time based on project complexity and size.

Uploaded by

uyyjzz
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
7 views29 pages

Software Engineering - 4

Effective software project planning is crucial for project success, involving activities such as scope definition, risk management, and resource allocation. Managers must create and regularly update project plans to monitor progress and address potential issues, ensuring that projects stay on schedule and within budget. Cost estimation techniques, such as COCOMO, help in predicting development effort and time based on project complexity and size.

Uploaded by

uyyjzz
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
SOFTWARE PROJECT PLANNING on of a project, we require good project: managemen, wntial. Lack of either one can cause a project to fail. We ment activities can be viewed as having three major ct monitoring and control and project termination, i Janning entails all acti vities that must be. performed before pee acme ork. Once the project is started, project cone begins, Inother words, during planning all the activities that management needs to perform are planned, while during project control the planis executed and updated. Planning may be the most important management activity. Without a proper plan, no real monitoring or controlling of the project is possible. Often projects are rushed toward d effort spent on planning. No amount of implementation with not enough time an technical effort later can compensate for lack of careful planning- Lack of proper planning is a sure ticket to failure for a large software project. Software managers are responsible for planning and scheduling project development. They supervise the work to ensure that it is carried out to the required standards. They monitor progress to check that the development is on time and within budget. Good managers cannot guarantee project success. However, bad managers usually result in project failure. Usually, the software is delivered late, costs more than originally estimated and fails to meets its requirements. The projet planning must incorporate the major issues like size and cost estimation scheduling, project monitoring and reviews, personnel i ion , selection and evaluatio! and risk management. In ordi and risk man der to conduct a successful software project, we must For successful completi and good engineering are esse have seen that project manage phases. Project planning, Proje ¥ Scope of work to be done Y The risk to be incurred Y The resources Tequired Y The task to be accomplished Y The cost to be expended Y Theschedule tobe followed, ‘ 114 ip coaer 6: Software Project Planning 15 The basic goal of planning is to look into the future, ced to be done to complete the project successf qurces. The inputs to the planning, ind the architecture description. A ver sential for planning, but for a good pl: raown, and it is highly desirable that identify the activities that ‘ccessfully and plan the scheduling and activity are the requirement specification ty detailed requirement document is not fan all the important requirements must be architecture decisions have been taken. 1 SOFTWARE PROJECT PLANNING Effective management of a software project depends on thoroughly planning ne progress of the project. Managers must anticipate problems that might arise nd prepare tentative solutions to these problems. A plan drawn up at the start of roject, should be used as the driver for the project. This initial plan should be he best possible plan given the available information. It evolves as the project rogress and better information becomes available. As well as a project plan, anagers may also have to draw up other types of plans, These are briefly described St @ Quality plan : It descries the quality procedures and standards that will be used in a project. (i) Validation Plan : It describes the approach, resources and schedule used for system validation. (ii) Confirmation Management Plan : It describes the configuration management procedures and structitres to be used. () Maintenance Plan : It predicts the maintenance requirements of the system, maintenance costs and effort required. (2) Staff Development Plan : It describes how the skills and experience of the project team members will be developed. At the beginning of a planning process, you should assess the constraints ffecting the project. In conjunction with this, you should estimate project arameters such as its structure, size and distribution of functions. After some ime, you should review progress and note discrepancies from the planned chedule. Because initial estimates of project parameters are tentative, you will ways have to modify the original plan. As more information becomes available, ‘ou revise your original assumptions about the project and the project schedule. If e project is delayed, you may have to renegotiate the project constraints and eliverable with the customer. If this renegotiation is unsuccessful and the schedule cannot be met, a project technical review may be held. The objective of this review is to find an alternative approach that falls with in the project constraints and eets the schedule. 6.6.1 The Project Plan ’ The project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. In some organization, the Project plan isa single document that includes the different types of plan. In other cases, the project plan is solely concerned with the development process. Referen ’ i 8 \ 6 Ives are separate, «included but the plans thems® Most p,, to other plans ar ng sections as . should include the ee briefly deseribes the ore that aia ang a Introductiomconstraints (egy budget, time, etc: the prop sets ow “ management: yes the way in which the devel ‘i : This describes : . 9) 2. Project Organisation ee volved and their roles in the team nized, the people in is describes possibl nd the risk reduction source requirements + This specifies, oftware required to carry out te be bought estimates of the Prices ang team is org? 3, Risk Analysis ¢ Th these risks arising 4! 4, Hardware and Software Fe hardware and the support S| development. If hardware has to the delivery schedule may be included. 5. Work Breakdown This sets out the breakdown of the Project int activities and identifies the milestones and deliverable associated wig, each activity. 6. Project Schedule : Thi estimated time require: to activities. 7. Monitoring and Report Mechanisms : This defines the managemet reports that should be produced, when these should be produced ai the project monitoring mechanism used. You should regularly revise the project plan during the project. Some pars such as the project schedule will change frequently; other parts will be more stable le project risk, the likelihogg strategies that are proposes 5 shows the dependencies between activities, te .d to each milestone and the allocation of people 6.1.2 Milestones and Deliverable ___ Managers need information to do their Job. Because software in intangible ae information can only be provided as reports and documents describe the stat® of the software being developed. Without this information, it is impossible ® assess how well i ; } be pated 1 the work is progressing, and cost estimates and schedules car a mieten Planing a project, you should establish a series of milestones where milestone there sh Mabe end point of a software process activity. At iommenegesent AAs : be a formal output, such as a report, that can be preset" Daaeeeeee stone reports need not be large documents. They may simply what has been completed, Milestones should represent the &™ of a distinct, complete that zal stage in the projec. Indefinite milestones such as ‘coding whether this state has been ack ingen nor Project management, You can't achi be developed is een nen achieved because the amount of code that still h#¥® A deliverable is a delivered at the end eet result that is delivered to the customer. It is usualll De some mi sliverable are usually miller eet phase such as specification or desié" a ut milestones need not be deliver 6: Soltwane NS we po be internal project result; 7 nes may s that are us, , Dla, files msject progress but which are not delivered ae sec oleet manager to chee fo establish flneboad fhe Software process ae tis ciated output. For exaemtt Be broken down into tai giavolved in Fequirements specification whan prety shows Possible Ping is used to hel e requi ; ° i activity. The project deliverables, which are deliver’, eae cane outputs a irements Specification, ease ivi ti alidal rn irements definition and the requi e Requirements Evaluation definition report design Architectural System requirements Milestones Fig, 6.1. Milestones in the requirements process, a 62 COST ESTIMATION For any new software project, it is necessary to know how much will it cost todevelop and how much development time will it take. These estimates are needed before development is initiated. But how is this done? In many cases estimates are madeusing past experience as the only guide. However, in most of the cases projects ure different and hence past experience alone may not be enough. A number of estimation technique have been developed and are having following attributes in common. ¥ Project scope must be established in advance. y Software metrics are used as a basic from which estimates are made. ¥ The project is broken into small pieces which are estimated individually. To achieve reliable cost and schedule estimates, a number of options arise: Y Delay estimation until late in project. Y Use simple decomposition techniques to generate project cost and schedule estimates. Y Develop empirical models for estimation. ¥ Acquire one or more automated estimation tools. Unfortunately, the first option, however, attractive, Ekdirmre bee ¢stimates must be provided up front. However, we should re i Wewait, more we aoe and ae we know, the less likely, are we to make serious ®tTors, in our estimates. a! 118 ‘ JODEL 6.3 COCOMO m rithmic models have been proposed as the basis 1, a ject. ese are um ef lean i els an emmy estimating the ofr tent parameter values. The cot empiticg similar but use ollecting data froma large number of software proj |CTIVE COST MODEL.” COCOMo},. ived by ¢ model that was derived 0y srthe CONSTRU Thefull form of COCOMO is" Th® which include basic, intermedia d to discover formulae that Were imatit ls, . , tware cost estimating models, hierarchy of senodels. ‘The data was analyse’ ¢ are est fit to the observations. These formulae link the size of the system ang he 7 product, project and team factors to the effort to develop tHesystem. The COCOMg model was chosen for several reasons : ; 1. Itis well documented, available in the public domain and supporteq by public domain and commercial tools. 2, Ithas been widely used and evaluated in a range of organizations, 3. It has a long pedigree from its first instantiation in 1981, through a requirement tailored to Ada software development to its most recent version, COCOMO II, published in 2000. The COCOMO models are comprehensive, witha largenumber of parameters that can each take a range of values. They are so complex and include essential characteristics to give a basic understanding of algorithmic cost models. Boehm postulated that any software development project can be classified into any one of the following three categories based on the development complexity : Organic, semidetached, and embedded. () Organic : We can consider a development project to be of organic type, if the project deals with developing a well understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects. Senidetached tA development project can be considered to be of semidetached type, if the development team consists of a mixturé of experienced and inexperienced staff. Team memb ited experience on related systems but may be unf. ilar So ag uni i of the systems being developed. 2, Se en eee (#) Embedded : A ject i type, ifthe goth neclgbment project is considered to be of embedded eing developed is strongly coupled to comple hardware, or if stri , trin; s exist. gent regulations on the operational procedures A number of sts of a sO! i s er 6: Software Project Planning . or TABLE 1: COST PARAMETER AND THIER WEIGHTS ast parameter iS Bich High | Nominat FEN, Requited Reliability 1.40 | 1.15} 100 BATA, Database Size 1.16 | 1.08 | 1.00 PpLx, Project Complexity 1.30 | 1.15 | 1.00 Fine, Executio Time Constraint 130} 111] 1.00 BOR Primary Storage Constriant] 1.21 | 1.06 1.00 Sint, Virtual MIC Volatility 130] 115] 1.00 « TURN, Tum Around Time 1.15 | 1.07 | 1.00 ‘Acar, Analyst Capacity 0.71 | 0.86 | 1.00 Aexr, Applications Experience | 0.82 | 0.91 | 1.00 AAR Programmer Capability | 6.70 | 0.86) 1.00 VEX?, Virtual M/C Experience 0.90 | 1.00 LEXP Language Experience 0.95 | 1.00 MODE, Use of Modern Practices | 0.89 | 0.91 | 1.00 TOOL, Use of Software Tools 0.83 0.91 1.00 SCHED, Rquired Devlopment 1.0 | 1.04] 1.00 Schedule ‘The above cost parameters can be categorised into four parts: 1. Product Attributes : The Ist three cost parameters are directly related to a product. 2. Computer attributes : The parameters numbered form 4 to 7 come un- der the category computer. These are corrcerned with the operational environment of a project. 3. Personal Attributes : The parameters from 8 to 12 relate to the specifica- tions of a personel. 4, Project Attributes : It defines the programming and technology. Capability and are numbered from 13 to 15. The multiplying factors for all 15 cost drivers are multipli Adjustment Factor (EAF). ied to get the Effort E=EAF*Ei E— Total Effort EAF-— Effort Adjustment factor Ei— Initial Estimate This model is used to describe the overall cost ofa projec! required for different phases, can be calulated. | cite ie The percentage of the total effort spent is phases for an organic Pe wate given in table (A) and percentage of the total effortspent in phases on mode project is given in table (B). tas wellas the effort Software Eng, | Bln 120 Table (A) Phasewise distribution of Effort based on organic Project ‘\ 4 14 25 26 31 Table (B) Phasewise distribution of Effort based on Embeddeq Atty Phas | Bort 0] Requirement analysis 8 Product design 8 Programming 44 Test Planning 6 V&V 4 Quality Assurance 7 Configuration Management 7 Manuals 6 According to Boehm, software cost estimation should be done throu; Stages : Basic COCOMO, Intermediate COCOMO, and complete COCOMO, Ths are explained as: : Plans and requirement Product design Detailed design Code and unit test Integration and test Project estimation of the proje Siven by the following expressions ; Effort = a, x (KLOC)® PM Tdey = b, * (Effortybe Months where, KLOC= Is the estimat Lines of code, ay by, a, by ai led size of the software Product expressed in Ki to devel , expressed months velop the software, exp Effort is the total effort required to develop the software prod expressed js Person months (PMs). 8 to Boehm, every line of source text should be calculated 24 ctual number of instructi ine. ee tq lines (say n lines) it i considered to ben LOC. The Biven By Bochm werent Mtegories of prodacens given by Boehm. The Accordin, ottware Project Planning 121 yer 6° th ” tion of development effort : stim of software products, gor the nae Cage fetta erie gots Organic Effort = 2.4 (KLOC)! PM ; sdetached : Effort = 3.0(KLOC)!? PM ser nbedded : Effort = 3.6 (KLOC)'2° PM , tion of development time: tian three classes of software products, the formulas for For the re based on the effort are given below : Soa Organic: Tdev = 25 (Effort)? Months gemidetached : Tdev = 2.5 (Effort) Months Embedded : Tdev = 2.5 (Effort)? Months igure 62 shows a plot of estimated effort versus product size. From Fig. 62, Figvverve that the effort is some what superliner in the size of the sofrmce we can ie, slope of the curve is > 1. This is because the exponent in the effort prowsthan 1 Thus, the effort required to develop a product increase rapidly with product size. the formulas for estimating the estimating the geveloP™ z Fig, 62, Effort yersus product size. The development time versus the product size in KLOC is plotted in Fig. 6.3. From Fig. 6.3, we can observe that the development time is a superliner ion of the size of the product. That is when the size of the product increases by ‘wo times, the time to develop the product does not double but rises ‘moderately. It may appear Surprising that duration curve does not increase superlinearly, The @Pparent anomaly can be explained by the fact that COCOMO assumes that a Project is carried out not by a single person but by a team of developers. From the effort estima rf 0 tion, the project cost can be obtained by multiplying ed Tequired effort by the manpower cost Per month. But, implicit in this project ia computation is the assumption that the entire project cost is incurred an ‘count of the manpower cost alone. Another point should be carefully embered. From the effort estimation for a project expressed in programmer Months and the nomin: Staff al development time, the novices‘ would determine the ing level by a'simple division, ' a 122 ‘Semidetached Organic g 5 Bs ‘8 g 3 E § 2 Fig. 6.3. Development time versus size. OCOMO : The basic COCOMO model assumes thy and development time are functions of the product size done. However, . na fi : i ize affect the effort requi ir project parameter besides the product size al ot required to the print as well as the development time. Therefore, in order to spe? the product as wel i ‘i accurate estimation-of the effort and project duration; the effect of al] Tel : parameters must be taken into account. The intermediate COCOMo = recognizes this fact and refines the initial estimate obtained ‘usin, gni d refit he initial estimate obtained 8 the bas COCOMO expression by using.a set of 15 cost drivers based on various ating of software development. For example, if modern programming practices aexs, the initial estimates are scaled-downward by multiplication with a Cost dri. having a value less than 1. If there are stringent reliability requirements og software product, this initial estimate is scaled upward. Boehm requires theyre manager to rate these 15 different parameters for a particular project on a sabi one to three. Then, depending on these ratings; he suggests appropriate cost die values which should-be multiplied with the initial estimate obtained using ie PoCOMOt In general, the cost drivers can be classified as being attribulsi ee 0 ate fF Pe characteristics the' product that are considered indst Siees complexity ofithe product; reliability requirements of (®) Computer: hesard ne fered i ke pul ter: Chatacteristics of the computer that are considered ind# a n speed required, storage space required etc. ) Personnel : i : ihclute thee attributes of development personnel that are conse ne erie PRET . i «analysis capability, pik si level of Personnel, programming capabilt Dever dtis te02 minors mein , capture the aaa ironment : ‘Development environment altti™™ "important paramere nt fetilities available to the develope® automation (CASE) that'is conisidered is the sophistication aii 48, Complete COCO; erp tsed for software development., y ‘ntermediate COCOMO MO 2A major shortcoming of both the basi¢ ad models is that they consider a software product a52® 2. Intermediate Ct 4g: Software Project Planning . tet vt" G 123 : entity. However, most large Systems are made UP Of sever, ws eo ese subsystems may have widely different chavacteriatign uot | eter” ne subsystems may be Considered as or, anic type, some. ae som bedded. Not only that the inherent deve! oat Ey be different, but also f an ystems Semidetached, ‘pment com, exit op ee Subsystem ee mY Of the psy jents may be high, for some the devel uy nel = quirem* m the Teliabitit, lopment team might ha y ive no of elerences heehee £0 On. The compre haveno previogs perienes Nese differences in characteristi erasers ‘Ndevelopment time as the efor eins. The cost of each subs Separately. asysete margin of error in the final estimate, rug consider thé Glowing development project as an exa ternplete ‘COCOMO model. A. distributed Management system (MIS) Product atheorganization having offices at Several places across the = an ‘ A fallowing sub components : ‘ompany can have ¥ Database part ¥ Graphical user Interface (GUI) part, ¥ Communication part, Of these, the communication part can be considere {Pp The database part could be semidetached software, ay software. The costs for these thi dd as embedded software, f ind the GUT Port organic ree components can be estis summed upto give the overall To improve the accura imated separately, and Cost of these system: model can be fine tuned ai cy of their results, the different parameter Values of the nd validated against an tganization’s historical Proj database to obtain more accurate estimations: Estimation. Modes suchas. cocomo arenotaccurated and lack a full scientific justification. Still, Software cost estimation models such as COCOMO are Tequired for an e1 Project management, Example 6.1 : Assii ngineering approach to software been estimated to bi (32)!95= 91 py t time = 2.5 x (91)038 P the product = hat a project wa £ level ‘pment time fora ea Semidetached a; . ind embedded. Solution ; = 14 months 91x 15000 = Rs, 1,465,000, s estimated to be 400 KLOC. Calculate ch of the three modes i.e. organic, The basic COCOMO equation take the form: aa } E=a,(KLOC)b, He tDe(KLOO d,s, AD Estimated Size of the Project = 400 KLOC c 126 nic small model phase Wise is KLOC it is an or8@ ceihation is given DeIOW 5 distivation system Design = 0.16 x 52.91 by Detailed Design = 0- ind Test = 0. d test = 0.16 * 52.9 time duration is 19 = 2.145 M Module code a! Integration an lopment Design = 0.19 « 11.2 Detailed Design= 0.24 x 11.29 = 2.709 M Module cost & Text = 0.39 * 11.29 = 4.403 M Integration and Test = 0.18 * 11.29 = 2,032 M ROJECT SCHEDULING jous schedules are possible, depending oy, Once the effort is estimated, vari n the project. For example, for a project whose number of resources put estimate is 56 person-months, 2 total schedule of 8, months is possible wig ple. A schedule ‘of 7 months with 8 people is also possible, as is a scheduieg approximately 9 months with 6 people. However, manpower and months are not fully interchangeable in a softizy ‘btained from the overall effort estimate A schedule cannot be simply o! on average staff size and then determining the total time requirement fort by the average staff. ‘size. For instance, in the exampleher, th with 56 people is not possible even though the effort mats 1 would execute the project in 28 months with) fort is fixed, there is some flexibility is: settingthe the project, but this flexibility is not unlimiel be broken, into two sub activities: ase wise devel Now phi system 64 PI project. deciding dividing the total e aschedule of 1 mont the requirement. Similarly no on Je, In other words, once the e! schedule by appropriately staffing Ina project, the scheduling activity can 1. Determining the overall schedule with’ .d Schedule of the various: tasks. major milestones. ( 2. Developing the detaile ( 1. Overall Scheduling : One method to’determine the normal overall scheit! is to determine it as 4 functionof effort.:) ygnsl gairnumengort | Jeted pro ¥ to be determined from data from ‘comp! using statistical techniques like fitting a regression curve through the scatter obtained by plotting the effort and schedule of past projects. This curv< is gen nonlinear because the schedule does not grow linearly with effort. Many a follow this approach. The total duration M,in calender months can be estim™ by : Any such functions has M=41E% 5, In COCOMO, the equation for schedule for an organic " sbarioz br 5 M= 25 E38 ois iwollot ot w It should be clear that schedule is not a function solely of effort. Here . itcan be schedule determined in this manner isnot really fixed. However, it can 4 guideline or check of the schedules reasonableness, which might be decide’ ‘type of software Software Engineering 128 ; a | ected inthe detailed schedule, 25 this reflects the tasks actually plang must be refl en tobe performed. : 65 STAFFING AND PERSONAL POA vt daca " and duration ©! pita stay sec nt an be ea) planned. Th taff-size is caculated with te 7 . help of the following equation. { the project e average S| ; Effort ~ PM. p (person unity Average staff size ™ Brojection duration M | in same during all the phaes of SDic, i nts are at peak during, testing and implementation, and Typically i recuirement aesigh and phases of maintenance ancl integration testing. From this, saffing comes ‘out to be a function that varies wil time. PERT and CPM are very useful for planning the staff schedule. As COCOMo model says that competent and technical staff is needed for the successful completion of project, likewise the abilities of the persons vary, which is a major | factor that effects the staffying process. Coordination and communication delay | highly affect the project completion time. 6.5.1. Rayleigh Curve : Norden of IBM observed that the rayleigh curve can be used as an approximate model for a range of hardware development projects. This‘ approach was later exptended by Putnam to apply to software projects. Putnam observed that the rayleigh curve. (Shown in Fig 6.4 below) was a close representation; not only at the project level but also for-software subsystem development. ‘m(t) (Persons) otrareale ‘The staff requirments do not remail ~+=+: Design and coding Time Fig, 64. The Rayleigh Man cf power loading ‘curve. ‘The Rayleigh equation represents man power, measured in persons per unit time as a function of time. It is usu; * all my curve model sua exeaed in person-yeatlyear(py/y»T* ion, . se m()= 4 HD ka ten? | ! i) “Where dy/dt. i time ra? 'yldt is the man power utilization rate Per unit time, “t” is elasped isa parai the Parameter that affects tl curve in the interval [0,). Imegratine ene cerve and *K” is the area unde? bh Ng equation (1) on interval [0, t], we obtait 130 7 - 1 a==a 25 i i ject at the peak ti reste eh med easy to determining by replacing with 2 Cl BY main this substitution in equation (1), we have Attime f= fy, the peak manning ™ (t, is obtained, which is denoted by mo Thus expression for the peak manning of the project is . k ur. ve where ‘¥ is the total project cost in person-year, ‘fis the delivery time in years, ‘ma’ is the number of persons empolyed at the peak. The averag rate of software team build up can also be calculated by dividing m, by ty 6.5.2 Personnel Planning The most significant factor in software quality is the quality of the person writing the software. Hiring the best developers, keeping the best developers happy once they’re on board and training new programmers up to become the best developers are the ways to achieve a high caliber development staff. Developing the development staff is an ongoing activity that proceeds at a number of levels. Obviously, during the course of a project the members of the development team will naturally acquire knowledge about the particular problem domain of project, and the tools and techniques used in building the system. This domain specific knowledge needs to be spread around the team so that no single develop® tecomes a bottleneck or overly essential to the project. This is an aspect 10 teams professionalism and the teams should be able to continue even. if one of its members were to be hit by a bus tomorrow, spreading around the knowledge of different aspects of the system also helps to inculate a wider perspective in the develope? mind, rather than just concentrating on their own little components, they a more likely to understand the system as a whole and how their component affec® the overall final system. Its important that new programmers acquire knowledge and ex technical areas outside of the things that are Tnmediately mecded for the project. There are several reason for this: v paces projects may need different skills sets, and may not have time for the development team to ramp up filling. a yf rience ° P it enous! —_— r 6: Software Project Planning 131 chapter ® e e more experience a developer has of different technical areas such as iM a ramming languages, operating systems, development tools, code Eel system, bug tracking systems the more they are able to spot the c common patterns between these different areas, and to induct the key factors involved. < The deeper knowledge a developer has to how underlying codé and systems are implemented, the better they get at debugging and understanding the foibles of those systems. j 4 ia developer is bored and not expanding their skills et and experience, they may begin to worry about being painted into a corner carrier wise and start looking for other jobs that have more Prospects. y new programmers have a thorough understanding of the underlying me that their code relies on, even among those assigning wit computer stem degrees. As such, there area number of core software lea ard technologies science Penner should get a working knowledge of during their first couple eis However, its always motivational to be able te explain why and when Gio pieces knowledge can come in handy given in parentheses below : ¥ How a compiler works, this information can be useful for determining what the problem is when it stops working, and to optimize the code for the best output from the compiler. y How the linker and loader work, Again this information can be useful to know when it stops working and to optimize things. ¥ How central features of hi useful for debuggin, igher level languages are implemented. This is debugging a crash 8 problems at the very lowest level ie,, imagine is stripped binary with a bare-bones debugger. ¥ How an operating system's scheduling algorithm works. 66 TEAM STRUCTURE Various roles in the team will depend on the nature of the PI well as the main team roles, consider the other participants and how th picture, Project roles and resources Will have been identified or roject. As ey fit into part of the hig £0 Meet the igh powered, bu: siness design team is unlikely to worl “velopment team. y k for a large application 6: Software Troe aang 6% 143 on an to highlight ect the plan to highlight the Specific risk areas, ject plannin; on quantity both probability of failure and ¢ arta ‘onsequences of failure and what will be done to reduce the risk. quences, ibe 0 jf the risk events materialize, es Aa surprisingly, then risk management is considered first among the best rf sos f0t managing large software Projects, Risk is defined as an exposure to the chance of injury or loss. This is risk jies that there is a possibility that something negative may happen. In the imp ¢ of software projects, negative implies that there is an adverse effect on rgality or schedule. Risk management is the area that tries to ensure that the af risks on cost, quality and schedule is minimized, i isk management can be, considered as, dealing with the possibilities and xtval occurrence of those events that are not regular or commonly expected, that is they are probabilistic. Risk management has to deal with identifying the undesirable events that can occur, the pr Obability of their occurring and the loss if anundesirable event does occur. Once this is known, strategies can be formulated foreither reducing the ‘probability of the risk materializing or reducing the effect of tisk materializing, So the risk management revolves ‘around risk assessment and risk control, 643.1. Typical Software Risks Possible risks can come from group brainstorming activities; or from a risk fador chart accumulated from previous projects, There are no magic solutions to any of these risk factors, so, we need to, rely on past experience and a strong ‘nowledge of contemporary software engineering and manag, ement practices to control these risks. The top five risk factors that threater Projects in different *pplications, ( Dependencies: agencies or factors. Tt i 'ypical dependency rel ‘Many risks arise due to'd is not easy to control th lated risk factors are : Y Availability of trained, experienced people): 1» ¥ Intercomponent or inter-group dependencies, Y Customer furnished items ‘or information: ¥ Internal and external subcontractor. relationships, (di) Requirement Issues: Many projects face uncerta tL the product's Tequirements. While some of this uncertainty is tolerable in early peet® but the threat to success increase if such ene and not resolved as the Teleet progresses. If we do not control requirements related risk factors, we might (att build the wrong Product, or build the right product badly. Either situation » Tesults in ‘Unpleasant surprises and unhappy customers. Some typical factors are : Y Lack of clear product vision. lependencies of project on outside ese external dependencies. Some pepanusy seen vit inty and turmoil around Rees oftware Project Planning 1S 5 copter 139 are quality is defined as the qualit nal the customer deliverables on Softw offerin’ 'y that ensures customer satisfaction Performance, standards and ease of aoe aA jg ensured through a quality man rou y ‘agement system (QMS). QMS is made ral components; it is a system integ ; 5 , rated in the bigger system of software velopment which comprises project, process and product management systems. dew software Engineering Institute (SEI) recommends a. Set of activities, which a implemented effectively, assumes the designed quality. These activities when i jnclude? . 5 y Quality assurance planning. Data gathering on key quality defining parameters. y Data analysis and reporting ¥ Quality control mechanisms. The first and foremost requirement is SQA ‘is that it is a separate group responsible for quality in the organisation. They set the goals, standards and mechanisms for SQA. The role of the SQA group is to assist the software development team in managing the quality requirements of the software. Every software has certain quality goals specified by the customer. These quality goals xe to be achieved by the development team by introducing a set of activities or ensuring the delivery of quality to the customer. ‘SQA activities operate on the normal activities of quality management. These adtvities play the role of monitoring, tracking, evaluations, auditing and review to ensure that the quality policy of the organization is implemented. The responsibility of delivering the required quality to the customer rests with the development team. The development team has an obligation to implement quality policy in terms of goals, objectives, procedures, checks and controls, documentation and feedback to management. . SQA has a variety of tools to implement the policy : Auditing : Verify compliance with norms and practices specified in QA policy; deviations are set right. 2. Inspection : Ensures that deviations are documented and reported and put in to the QA database for guidance. \ f 3. Technical review : Design and architecture is reviewed to ensure that standards are met and customer quality is assumed, . Coordinates and controls +: Implement change management. Collect and Analyse : Collect data on various observations in the process of auditing, inspection and reviews to build QA database and to improve various standards. Statistical quality control : — Data errors defects, deviation collected, categorized and analysed. — Build cause and defect relationships. — Build audit, inspection and review procedures around the causes. ge » ce Software aking, t * ing: The main goal of monitor \| ject Monitoring and Tracking : The main g Oring is for, Proje get visibility into the project execution so that they can as? | managers “action needs to be taken to ensure that the project g whether types of monitoring might be done fora project. The three Differé monitoring are : () Activity level (i) Status reports (i Milestone analysis. (i Activity Level Monitoring : It ensures that each activity in the deta | schedule has been done properly and within time. This type of monitorin, mays done daily in project team meetings or by the project manager checking the stat, | of all the tasks scheduled to be completed on that day. A completed task ig ae | marked as 100% complete in detailed schedule. This is used by tools like microsoft project to track the percentage completion of the overall Project or, | higher level task. | | (ii) Status Reports : These are often prepared weekly to take stock of: whathas | happended and what needs to be done. Status reports typically contain a su of the activities successfully completed since the last status report, any activitig that have been delayed, any issues in the project that need attention and it everything is in place for the next week. (ii) Milestone Analysis : The milestone analysis is done at each milestone or every few weeks, if milestones are too far apart. Analysis of actual versus estimated for effort and schedule is often included in the milestone analysis. If the deviation is significant, it may imply that the project may run into trouble and might not meet its objectives. This situation calls for project managers to understand the Teasons for the variation and to apply corrective and preventive actions if necessary. A graphical method of capturing the basic progress of a Project as compared to its plans is the cost schedule milestone graph. The graph shows the planned schedule and cost of different milestones,’along with shows the actual cost and Schedule of achieving the milestones achieved so for. By having both the planned Cost versus milestones and the actual cost versus milestones on the same graph, the progress of the project can be grasped easily. Overall project monitorin; in other to achieve the errors can be identifie Cals arene | main levy ‘ot | 8 Plans lays out the path the project should follow Project objectives. With proper monitoring in place, various d and plans changed accordingly. 6413 RISK MANAGEMENT Risk management is an attern unplanned events. Thi that have risks but Undertaken, software ind, an attempt to minimize the chances of failure caused >) aim of risk management ig not to avoid getting into pro} oa of minimize the impact of risks in:the projects that af Management is becoming recognized as an important area in lustry to reduce this su; with a con prise factor. ‘Risk management means deali"é development before it becomes ‘a’ crisis) Therefore, ‘most of the softwa% ivities include risk management as a key part of the plan! 6g: Software Project Planning 6 + curt 145 , Risk identification Risk assessment tL 4 Risk analysis Risk prioritization Risk management planning Risk control rH Risk monitoring Risk resolution Fig. 65, () Identifying the risk. @® Analysing them (@ Assigning priorities, (@ Identification of Risks ; Risk management activities, Possible project, product and business risks are identified, () Risk Analysis : The likelihood and consequences of these risks are assessed. {Assigning Priorities : Plans to address the risk either by avoiding it or minimizing its effect on the project are drawn up. Risk Assessment 1 isthe process of examining a project and identi Risk identification can be facil ity and impact as High, Mediu on rated as High are the ones rm Another Way of handling risk is the risk av a we ‘oldance, Do not do the tis! ace Pahor avoid risks by not undertaking certal ky things! In projects, or by relying on Proven " cutting edge technologies, Project manager | ‘Communication Fig. Mixed team structure n incorporates both hierarchical reporting ang democratic setup. In Fig, the democratic conections are shown as dashed lines ang wn using solid arrows, The mixed control team organization is suitable for large team sizes. The democratic arrangment at the senior developers level is used to decompose the problems into small parts. Each democratic setup at the programmer level attempts solution to a single part. Thus, this team organization is eminently suited to handle large and complex programs. This team structure is extremely popular and is being used in many software development companies. 6.7 SOFTWARE CONFIGURATION MANAGEMENT (SCM) The output of the software process is information that may be divided into three broad categories : () Computer programs (bo (i) Work products that describe the computer programs (to;' technical practitioners and users). (# Data (contained with in the program or external to it). The items that comprise all information produced as part of the software process are collectively called a software configuration. In each configuration item simply led to other items, little confusion would result. Unfortunately, another variable enters the process change, Change may y time, for any reason. However there are four fundamental sources of The team organizatio' the reporting structure is sho’ th source level and executable forms). ether at both occur at an) change; ; y New business or market conditions dictate change in product “ requirements or business rules, y New customer needs demand modification information systems, functionally delivered by products, delivered by a computer based system. y ‘Recognization or business growth/down sizing causes changein project priorities or software engineering team structure. alt of data produced by or services y . y 140 Softw: ' : ore E Ney : The causes for not meeting the quality commonly are : v Imprecise requirement and software specifications. Lack of understanding of customer requirements. Intentional deviations. Violation of standard design and programming. Faulty logic is rules and processes. Incomplete and defective documentation ¥ Lack of domain knowledge. SQA is also concerned with two other aspects, namely, software teliabit ily v v v y Improper interface. v v and software safety. (i) Software Reliability —is defined as the probability of failure free opera of a computer program ina specified environment of a specified time. ty SQA collects data on these failures and estimates why these failures coy, not be prevented through earlier SQA activities. Asimple measure of reliability is mean time between failure (MTBF). MTBF= MTTF+MTIR ‘ to failure and MTTR is mean time to repair. deals with the identification and assessment of potent) and its impact on the system or in the environmentir eeds are more crucial in process control systens, on. SQA activities concentrate on such areasd adversely. reliability availability ax where MTTF is mean time (ii) Software Safety—' hazards of software failure, which it operates. Software safety ni health care systems defence and so software where failure affects the customer system In short, SQA efforts assures ‘software quality, safety. OC 1827 ' . 189 ees exactly the user expectations, no claims of } 4 Product correctness can sft . pifference between Verification and Vatidati lon ification Verifi ; Validation ig a static process of verifying | 1. ttisaayna 4 weyments designs and code testing the acer ot validating/ iy does not involve executing the | 2. It involves executing fe | e | te based checki mes | is human based checking of 3. It is comput F Hocuments/files Program, | Pas64 execution of |, target is requirements specification, * pplication, architecture, high level and detailed design, database 4. Target is actual module, Product a unit, a a set of inte modules, final product, "4 design. [< [Link] methods like inspection walk | 5. Ituses methods like black box. Gray | through, Desk checking etc. box, white box, testing ete. ig It generally comes first done before |. 6. It generally follows verification, i validation. 7. It answers to the question— Are we 7. Tt answers to the question— Are we building the product right? building the right product? 8. It can catch errors that verification cannot catch. [s. It can catch errors that validation J) cannot catch iy ALPHA AND BETA TESTING __ Itis virtually impossible for a software developer to foresee how the customer jmil really use a program. Instruction for use may be misinterpreted; strange |onbinations of data may be regularly used; output that seemed clear to the tester |Bay be unintelligible to a user in the field. __ When custom software is built for one customer, a series of acceptance tests |#* conducted to enable the customer fo validate all requirements. Conducted by end-user rather than software engineers, an acceptance test can range from an ht test drive” to a planned and systematically executed series of test. In acceptance testing can be conducted over a period of weeks or months, thereby Movering cumulative errors that might degrade the system over time. If software is developed as a product to be used by many customers, it is E Practical to perform formal ssieptance tests'with each one. Most pas Moduct builders use a process called alpha and beta testing to uncover errors ae ij the end-user seems able to find. The terms alpha and beta testing ae used, picn the software is developed as a product for anonymous custom ae imal acceptance testing is not possible in such cases, However, “Stomers are identified to get their views about the product. 's si . These The alpha tests are conducted at the developer's site by = Sead S are conducted in a controlled environment. Alpha testing formal “ ag: Software Testing ont 177 the lower the additional development cost ‘he test and integration phase is the final fit t associated with removing sion. ov" és ter for all errors of omission sen * TESTING 4! im of program testing is to identi ‘qneai a . @ program. However, ii cove" after satisfactory Fmpletion of the testing phase, itis not possible to pate that a program is error free, This is because the input data domaii en rograms is very large, and itis not Practical to test the prigtars exhastin i a espect to each value that the inpu en with this obvi a wf io mn of the testing process, we shoul eamee wi imate the importance of resting: Different people understand many definitions of testing. Some of them are ven below: 1. Testing is the process of demonstrating that errors are Not present. 2, The purpose of testing is to shown thata Program performs its intended function correctly. fy all defects in it can assume. Ev id not under esti 3. Testing is the process of establishin; what it is supposed to do. These definitions are incorrect. They describe almost the opposite of what testing should be viewed as. Forgetting the definitions for the moment, consider that when we want to test a program, we want to add some value to the program. Adding value means raising the quality or reliability of the program. Raising the reliability of the program means finding and removing errors. Hence, we should not test a program to show that it works; rather we should start with the assumption that the program contains errors and then test the Program to find as many of the errors as possible. Thus, a more appropriate definition is: “Testing is the process of executing a program with the intent of finding errors.’ Thus, establishing the proper goal has an important psychological effect. If our goal is to demonstrate that a program has no errors, then we shall sub consciously steer towards this goal; that is, we will tend to select those inputs that have a low probability of causing the program to fail. Software testing becoming increasing important in the earlier part of the software life cycle, aiming to discover ‘rors before they are deeply embedded within systems. 8 confidence that a program does 81.1 Why should We Test? Although software testing is itself an expensive pate et eae of Software without testing may lead to cost, potentially peau one would think ‘sting specially in systems where human safety is involved. No} rigorous testing, °fallowing automatic pilot software into service without ' © nee onalderation Ih so called life critical system economics must not be the prime consideration while deciding whether a product should be released to a cu: force and the limiting the cost factor, which plays a major role. Itis both the driving toe ea and factor as well. In the software life cycle the earlier the errors a | apt z acceptance testing. Generally, sys' 183 gom?'| Errors located during testi Ystem testing j itl immediate attention ance °2Y fall into gay e"xPatP 11 “Burpjoyyeos ausos sarmbar yy “¢ *Surpjoyjeos xepduroo sasmba. I] ‘amponys uoye:Zaqur “yevep aur Jo Auniqista ayy sisay ay z | ur apoo jo Aypiqista ayy s3say i 2 “uoneody ads uoyeoyioads apejiaqU! ayy Woy syieys yy *T aInpow ayy wuosy syieis I ‘Buyy5ay uoyvsSoquy Sunsay nun Sunse, uonesBequy pue yun uaamyeq souasyia 19 swaysAs out ». Azansiop en doaoe ©} Jou Jo JaYVaYM auTULaIap oy raUOYsnd aU <4 5. N52} WaIshg ay) S| Zuysa, aouridaooy :Buysay Sundasoy sa “sxawO}sn9 A[puatay jo dnowd Paipajas e hq pauniojsad Buyjsay waisds auy st Sunsay Saal SunsoL epa © } URTEM wuteay ysaq ayy Aq 110 Sunsay eydyy -Bunsay eydiv © “‘YUOHeZIUeBIO ay PALES 61 324) Bursa) Waysks ayy oy a ode 7 Sunsay aavaysos * 8 Softws 184 ftware Engine, ey cases, complete testing can be postponed until the integration test ceiver and stubs are also used). A second approach is to generate the se> (here sutomatically by means of a test harness. A test harness, among N 2

You might also like