Scribd Logo
Upload

Welcome to Scribd!

  • Se Importance

    Uploaded by

    Shivam Narkhede
    15 views50 pages

    Original Title

    se importance

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    Download as pdf
    15 views50 pages

    Se Importance

    Uploaded by

    Shivam Narkhede

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    Download as pdf
    of 50
    Software Engineering Importance (Mumbai University) No. Module 1____[ Sotware Requirement Seecficaten 2 2 | Rk ligation, Montorng and Management fe (Ru) 3 [whi Box Testing Black box Testing ® 4 | ydomate Compexy 5 5 | Conwson and cauping * | Formal Tetra! Review (FTR) ls 7 Grange ane Version Conia! le Priority 2 No. | Question Moaute 8 | Function PointAnatysis (FPA) 3 8 [Object Overt Testing (Une tegration Tesina) [8 10 | Roverse Enghowring 5 ‘ale Daveloprent (Scrum / xP in dea) 7 “Tost Orvon Davelapment 1 Question Module 1 2 Pronty 3 No. 3 \Verilcaion & Vatdation(Diference) + 14 _ | Sohece Sippage & Cost Sippage 7 15 | Capability Maturity Mode! 1 16 |cocowo 3 Extra Topics No. | Question Module 17 | Alpha & Beta Testing 5 18 | SDLC Models, 1 Module 1 1. Explain agile methodology. Ans: In terms of Software Development, basically agile’ means the ability to respond to changes, .e., changes from Requirements, Technology and people. > Its an fterative and incremental process. > Itoffers direct collaboration with the customers. > Delivers multiple Software Increments, > Here each iteration lasts from oneto three weeks. > Engineering actions are carried out by cross functional teams(a team expert in their respective work assigned) > ateam of software developers published the Agile Manifesto ia +2001, highlighting the importance of the development team, ‘accommodating changing requirements and customer involvement. > The principles of agile methodology were defined by Manifesto (a public dedaration of policy and aims). ‘The principles of agile process models are: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software, 2, Welcome changing requirements, even late in development. 3. Deliver working software frequently, from a couple of weeks to @ couple of months, with a preference to the shorter timescale, 4. Provide the individuals the environment and support which they need, and trust them to get the jobdone, 45. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant eee, 6, Business men and developers must work together daily throughout the project. +7. Tomeasure the progress done we run the software thus Working ‘Software is the primary measure of progress. 8, The most efficent and effective method of conveying information toand within a development team is face to face, 9. Attention should be given to technical excellence and good design ‘Which enhances agilties. 40, Teams should inow about the amount of work not completed. 4s, The teams should be self-organized and independent, 12, Atregular interval, the team should refiect on haw to become ‘more effective and adjust its behavior accordin Agile Process Models 1. Extreme Programming Planning:- > Start with creation ofset of stories > Describes required features and functional > Customer will give priority to each user story > Sp team willaccess each story and cost > Stories with highost priority will be developed firstand ‘then with risk stories Design:- > It should be as simple as possible > CRO(class-responsibility-collaboretion)- they identify and organize the object oriented classes relevant to current software increment > If difficult design problems encountered then immedietely an operational prototype is designed called spike solution Coding: Pair Programming- > Itis a process of two people working together on one workstation to create code > Many pair programmers integrate their code to get complete code of that anit Testing: Unittesting- Here acceptance testing also called as customer testing is used. It ‘means comparing software with the expectations of users, then seeing fit satisties the user. 2. Scrum + It iterative and incremental agile methodology principles + Small teams to meximize communication and minimize overhead + Process mustbe adaptable to technical and business changes to ensure best possible product is produced + Process yields frequent software increments Constant testing and documentation is performed as produc is built + Backlog(list of prioritized requirements) ‘The product manager accesses the backlog and updates the priorities + Sprints Work units required to achieve requirement are defined + Scrum meetings -Short meetings held dally by scrum team_ -It includes the discussions about what did you o in the last meeting, ‘what obstacles are you encountering, what éo you plen to accomplish bynext team meeting 2. Test Driven Development ‘Test-driven development (TDD), also called test-sriven design, is amethod of {implementing softvare programming that interaces un testing, programming and refactoring on source code. ‘Test-ariven development was introduced as part ofa larger software design paradigm known as Extreme Programming (XP), which is part of he Agile sofware development methodology. ‘Test-ariven development starts with developing test for each one of the features. ‘The test might fail as the tests are developed even before the develooment, Dovolopment ioam then dovolops and rofactors the code to pace the tost. ‘Test-ariven development is related to the test-irst programming evolved as part of extreme programming concepts. ‘Steps of ihe testdriven development approach - Before any new code is writien, the programmer must frst create a felling unittest. ‘Then, the programmer ~ or oair, or mob ~ creates just enough code to setisty that requirement. Once the test is passing, the programmer may re-factor the design, ‘making improvements without changing the behavior. Test-priven Developaent Test-Driven Development Process: *Adda Test + Run all tests and see ifthe new one fils + Write some code + Run tests and Refactor code + Repeat Example e Pass Deveboment toos Context of Testing: + Valid inputs + Invalid inputs + Errors, exceptions, and events + Boundary conditions + Everything that might break Benefits of TDD: “Much less debug time + Coce proven to meet requrements «Tess become Safely Net “Near zero defects + Shorter development cycles 3. Difference between verification and validation. Ans: Vesifietion ‘ahiaioe 1 Tinliee tat we youbulding 1 Tigges at we you buiing gh ing 2 tis done by Seveloper 2 Tes doneby tester 5 Tune metiods ike nope 3 Tee mathods like ack bon eng and reviews, wallboueh ard desk checka bite box esting 4 Tian cbpctve process 4 Teas eee precane 5 Ie tales pace befor validation Seas place aftr validation 6 doesnot inva exciting the exe 6 Trimaleesexnaring the code 7 Nesicaion is tocheck whether the 7. aliatioe nt check whether wate seftate confirms to spcifieziex meets the cusemer exsectatons ad segues 4, Explain Schedule and Cost Slippage. ‘Ans: Slippage isthe act of missing deadline, > Tho goal of software project managements to deliver the software product {n the given time and within the budzet, > The software project should be developed with the requirements of the organization, > Managing projectsis difficult because of other engineering products which are visible, > The large projects are different in nature, so even the managers find difficulties in the project. > Schedule slippage- if the project we have, is being delayed from the date being estimated before then this type of delay is knownas schedule slippage. To overcome this delay we create time line charts or Gantt charts > Costslippage-it depens on the schedule. If there is slippage in schedule then ultimately there will be slippage in the cost ofthe projector the budget of ‘the project. > Here the project manager deals with the problems of the project and finds ‘the main causes ofthe slippage > Necessary actions are taken to correct the problems. > Nowadays we have three dates associated with the project plans > NRA Non risk adjusted date, Ra-Risk adjusted dete, upper limit, ‘oNRA- here wo consider the ideal conditions that no risk will ocour and the software will be developed without any tisk ‘oRA-here we consider that the delays or errors may occur so we consider some extra time ‘Upper limit- this is considered as the last deadline ofthe project. > Ifthe projectis between NRA to RA then the project is expected to be completed. > Ifthe projectis between RA to upper limit then itis knownas delayed completion, Thus this completion is neither good nor expected to be a well planned project ‘Causes of slippage > Poor estimation- we estimate the date of project completion but could not ‘complete the project at thet fixed date then itis said to be poor estimation > Poor requirement analysis- we estimated that the project will require 10 people but it required more than 10 people thenit is mown as poor requirement analysis, > Management issues- the issues in the organization due the management of the projectare said to bemanagementissues. 5. Write a short note on Capability Maturity Model (CMM). ‘Aas: « The Capability Maturity Model (CMM) isa methodology used to develop and reiine an organization's software development process. + The model describes a five-level evolutionary path of increasingly organized ‘and systematically more mature processes. + Itwas developed and is promoted by the SOFTWARE ENGINEERING INSTITUTE (SED, aresearch and development center sponsored by US. Department of Defense (DoD). + Capability Maturity Model is used as a benchmark o measure the maturity of ‘an organizstion’s software process. + This model has five different levels which describe a strategy that should be followed. + Each level here shows a process capability evel. allthe levels except level are further described by Key Process Areas (KP4’s). + Key Process Area's (KP4’s)- Key process areas form the basis for management control ofthe project. + KPa's defines the basic requirements that should be met by a software process. + The five levels of CMD areas follows:- Level: Initial- + No KPa’ defined + Unpredictable processes occur here + Taese processes are poorly contrelled and are not well defined + Tis the reactive process, hence Its said tobe less matured level +No basis for predicting product quality, time or completion, te. Level-2: Repeatable- + Here the processes performed can be repeatable hence itis said repeatable level + tfocuses on developing basi project management policies + Ttincludes Software quality assurance, Software subcontract, management, Software project tracking and oversight, Software project planning and requirement management + KPA > Project planning- it includes defining resources required, gals, constrains, etc. forthe project. > Configuration management: it msintains the performance of the software product for entie life cvele. > Requirements management- it consists ofthe management of customer reviews and feedback resulting in some changes in the requirement set. > Software quality assurance- It renders good quality software product by maintaining certain rules and standards. Level-3: Defined- + Special documentation of the standard guidelines and procedures occur + Its well defined integrated set of management processes KPA’ > Peer reviews- here defects are removed by usinga number of review methods like walithroughs, etc. > Organization process focas- it includes activities and practices that should be followed to improve the process capabilities of an organization > Training programs-it increases work efficiency Level-g: Managed- ++ Here quantitative quality goals are set for software products + Itinvolves predictable processes +KPAS > Software Quality Management- establishes plans and strategies to develop quantitative analysis and understanding of, the quality ofproduct > Quantitative Management. it controls the performance of the + Itis the highest level of process maturity in CMMI ‘+ Here new tools, techniques are used to prevent recurrence of ‘known defects EPA'S > Process Change Management: it identifies and uses new technologies to improve productivity, quality for software product > Technology Change Management- consists of identification and use of new technologies to improve product quality > Defect Prevention- focuses on identification of defects 6. Explain iterative model in SDLC. Ans: + Tterative model combines elements of waterfall model in an iterative fashion. + When incremental model is used, the first increment delivered to the client is core product, ie, very basic requirements are addressed. + This is deivered and evaluated by the customer/client (increment is aiven to the customers where it undergoes detailed evaluation). + With the help ofthe result of use and evaluation nest plan is made for next increment, + So this processis repeated for deivery of each increment, until ‘complete product is produced. + The basic idea behind this method is to develop a system through, repeated cycles and in smaller portions ata time (incremental), allowing software developers to take advantage of what was leamed ‘during the development of earlier parts or verstons of the system, + The core product is deployed and the customers evaluate it and give feedback. + Based on this feedback the further increments are planned. + Ithas a linear and parallel workflow. + It consists of the following phases:- ‘+ Communication- helps to understand the business problem, ie., what software has to be devsloped. + Planning- is essential berause multiple software teams work in parallel on different system function, ‘+ Modeling-it establishes design representation which serves as basis for nest activity. ++ Construction- emphasis in raising components and automatic code generation and testing + Deployment- integrating, delivering the product and feedback Advantages- + Produces business value early inthe deployment lifecycle. + Lowers initial delivery cost. + More flexible. + Can acccmmodate some change requests between increments, + Better risk analysis Disadvantages- Requires heary documentation. + Requires more customer involvement than the linear approaches. + integration between iteration can beissue. ITERATIVE MODEL Sater Fate ter Module 2 1. Software requirement specification (SRS) ‘Ans: A software requirements specification (SRS)is a comprehensive description ofthe intended purpose and environment for software under development. The ‘SRS fully describes what the software will do and how t will be expected to perform. A Software Requirements Specification (SRS) is a document thet describes the nature of a project, software or application. In simple words, SES document isa ‘manuel of a project provided itis prepared before youkick-start a project/application, This document is also known by the names SRS repert, software document. A software document is primarily prepared fore project, software orany kind of application, ‘There are a set of guidelines to be followed while preparing the software requirement specification document. This includes the purpose, scope, functional ‘and nonfunctional requirements, software and hardware requirements of the project. In addition to this, it also contains the information about environmental conditions required, safety and security requirements, software quality atributes of the project ete. Following are the characteristics ofa good SRS document: ‘Software requirements specification should be accurate, complete efficient, and of high quality, so that it does not affect the entire project plan. An SRSiis seid tobe of high quality when the developer and user easily understand the prepared document, Other characteristics of SRS are discussed below. (Correct: SRS is correct when all user requirements are stated in the requirements document. The stated requirements should be according to the desired system. ‘This implies that each requirement s examined to ensure that it (SRS) represents ‘user requirements, Note that thereis no specified tool or procedure to assure the correctness of SRS, Correctness ensures that all specified requirements are performed correctly. Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation. This implies that each requirement is uniquely interpreted. In case there is a term used with multiple meanings, the requirements document should specify the meanings in the SRS so that its clear and easy tounderstand. Complete: SRS is complete when the requirements clearly define what the software is required to do. This includes all the requirements related to performance, design and functionality. Ranked for importance/stabiity: All requirements are not equally important, hhonce each requirement is identified to make differences among cther requirements. For this, itis essential to clearly identify each requirement, Stability implies the probability of changes in the requirement in future, Modifiable: The requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS. Traceable: SRS is tracezble when the source of each requirement is lear and facilitates the reference of each requirement in future. For this, forward tracing and backward tracing are used. Forward tracing implies that each requirement should, be traceable to design and code elements, Backward tracing implies defining each requirement explicitly referencing its source, Verifiable: SRS is verifizble when the specified requirements can be verified with ‘a cost- effective processto check whether the final software meets those requirements. The requirements are verified with the help ofreviews. Notethat unambiguity is essential for verfiability Consistent: SRS is consistent when the subsets of individual requirements defined do not conflict with each other. For example, there can bea case when different requirements can use difforent terms to refer to the same object. There can be logical or temporal conflicts between the specified requirements and some requirements whose logical or temporal characteristics are not satisfied. For instance, a requirement states that an event 'a'is to occur before another event ‘0. But then another set of requirements states (directly or indirectly by transitivity) that event should occur before event "2" Example: Online Student Feedback System Online Student Feedback System Prepared by XYZ danuary 5, 20:6 Release 1.0 Version 10 ‘Table of Contents 3. Introduction 1.1 Purpose 1.2 Scope 1.3 Overview 2, General Description 2. User Manual 3. Functional Requirements 3.1Description 4. Interface Requirements 4aGUL 4.2 Harware terface 4.3 Software Interface 5. Performance Requirements 6. Design Constraints Other non-functional attributes 7a Security 7.2 Reliability Availability 7.4 Maintainability Reusability 8. Operational Scenarios 9. Preliminary Schedule 1L.Intreduction 14 Purpose ‘This document gives detailed functional and non-functional require online student feedback system, The purpose ofthis document is that the requirements mentioned init should be utilized by software developer to ‘implement the system. s.2 Scope ‘This system allows the students to provide quick feedback which is provided by collage staff. The feedback report is generated ané whith is checked by HOD’. ‘He can view grade and graie obtained to the lecturers. 1.3 Overview ‘This system provides an easy solution to collage staff and students for ‘maintaining feedbackrelated to collage staff and infrastructure, facility ts for Feedback Report 2. General Description ‘This online student feedback system replaces the traditionél, manual feedback system by which lots of paper work will be reduced. The teecher should able to provide feedback regarding faciity and students are able to provide feedback easily. This is primary feature of this system. ‘Another feature is that feedback form can be provided to student and staff by ‘emailing for filing up form. 24 User Manual ‘The system should provide Help option in which how to operate system should be explained. also hard copy of this document should be given to user in booklet form. 3. Functional Requirement ga Description For idontity of staff, system should display staff photograph slong with their names for that corresponding subject and skills, Statistical report accordingly subject or skill should display’ whenever required \dividual’s report 4. Interface Requirement 43GUr Stadent ‘Student can give the feedback about the lecturers on the scale of ten. Student can give feedback bout the lecturers based on interaction of lecturer in the classrooms with students and facility provided by collage like infrastructure ete. Saft ‘The feodback given by students can be viewed by the staff and improve their performance in teaching and other aspect Head of Department ‘The feedback report can be checked by HOD’s. He can view overall gradesand view the grades obtained to the lecturers and give report to principal and he can give counselling tothe collage staff. Principal Finally, report was referred by principal and give suggestions to the lecturers, ‘to improve ther teaching. 4.2 Hardware Interface ‘The system should be embedded in all desktop. 4.3 Software Interface 4. Online Student Feedback System ii, The feedback database transmitted to database server. Report generator. §, Performance Requirements ‘The system should work concurrently on multiple processors between the collage hours. ‘The report should be generated immediately within one hours 6. Design Constraints ‘The system should be designed within 6 months. 7. Other non-funetional attributes 174 Security ‘The student and staff should provide password to log on to the system. 72 Reliability Reliability can be guaranteed due to wired connectivity. 79 Availail ‘The system should be available during collage hours. 7-4 Maintainability ‘There should be facility to add and delete feedback form for differeat purpose. 5 Reusability 7.6 The same system will be used in each semester. 8, Operational Scenarios ‘There should be student database, teacher database. The student database contain name and feedback information, ‘The teacher database contain name, subject, skils, and other details. 9, Preliminary Schedule ‘The system should be designed within 6 months. Module 3 1. Function Point Analysis (FPA) ‘Ams: The function point (FP) metric is used effectively for measuring the sizeof a software system. Function based metrics canbe used as a predictor for the overall testing effort. Various project-level characteristics (e.g, and testing effort and time, ‘rrors uncovered, and number of test cases produced) of past projects can be collected and correlated with the number of FP produced by a project teem. The ‘eam can then project the expected values ofthese characteristics for the current project. Listed below area few FP measures: 1. Number of hours required for testing per FP 2, Number of FP s tested per person-month {3 Total cost of testing per FP 4. Defect density measures the number of defects identified across one or more phases ofthe development project lifecycle and compares thet value with the total size of the system. It can be used to compare the density levels, across different lifecycle phases or across different development efforts. Itis calculated as ‘Number of defects (by phase or in total) / Total number of FPs ‘5. Test case coverage measures the number oftest cases that are necessary to ‘adequately support thorough testing of a development project. This measure does not indicate the effectiveness of test cases, nor doesit guarantee that all conditions have bem tested. However, it can be an effective comparative ‘measure to forecast anticipated requirements for testing that may be required on a development system of a particular size, This measure is, calculated as ‘Test case coverage = Number of test cases / Total number of FPs Capers Jones estimates that the number of test cases in a system can be determined by the function points estimate for the comresponding effort. The formula is ‘Number of test cases = (Function points) Function points can also be used to measure the acceptance test cases. The formula is Number of test cases = (Function points) »1. ‘The afore-mentioned relationships show that testcase grow at a faster rate than function points 2. Explain COCOMO model ‘Ans:> COCOMO stands for Constructive Cost Model > This model gives the estimation of cost ofthe construction ofthe projectso {1s also known as cost estimation model. > Itis applied on three lasses of software projects: + Organic Frojects- here the teams are small with good, experience and less rigid requirements + Semi Detach- the team size is medium with mixed experience and mized rigid requirements + Embedded Projects- these projects are combination of organic projects and semi detach projects > The stages of constructive cost model areas follows: (@) Basie COCOMO model: + Tt gives the approximate estimate ofp ct parameters. + The project parameters are- efforts needed development time and other requirements needed to build the project + Software development efforts are given using LOC (lines of code) + Effortsapplied ©) = a(KLOC)» + Development time (D) = cb (efforts applied)-b Gere abcd, ae constats and b indicates Basic COCOMO model) + People Required (P)= ED (@) Intermediate COCOMO model: - + Itis extension of the Basic Cocomo model. Itimproves the results obtained by basic COCOMO model + Itrefines estimate obtained by Basic COCOMO modelby using asetof 15 cost drivers, each having 6-point scale ranging from Very Low to Extra High + Effort Applied (E) = a(K LOC) + Development Time and People required are dependent on Efforts applied. (G) Detailed COCOMO model: - > Itrefines the results obtained by Intermediate COCOMO model. > Here the estimation is done during all the phases of software development, as a result it is known as detailed COCOMO model, > Ithas Six phases init where the estimation is performed, that are Plan and Requirement - System Design - Detail Design - Module Code & Test Integration & Test - Cost Constructive Module 4 1. Explain cohesion and coupling. Ans: Coupling- is ¢ qualitative measure of the degree towhich classes are connected to one another. As classes become more interdependent, coupling increases. An important objectivein component level design is to Keep coupling as low as possible. Couplings categorized as follows: 1. Content coupling: occars when one component modifies data that is {internal to another component. 2. Common coupling- occurs when a number of components all make use of a global variable. Common coupling can ead to uncontrolled error and unseen side effects when changes are made. 3. Control coupling: occurs when operation A invokes operation B and passes control flag to B. The control flag then directs logical flow within B. 4 Stamp coupling- occurs when Class B is declared as a type for an argument of an operation of Class A +5 Data coupling- occurs whea operations pass long strips of data arguments. ‘The bandwidth of communication between classes and components grows and the complesity ofthe interface increases. 6. Routine coupling- ocours when one operation invokes another. This level of coupling is common and is often quite necessary 7. Type use coupling- occurs when component A uses a data type defined in component B. Ifthe type definition changes, every component thet uses the definition must also change. 8. Inclusion or import coupling- occurs wi ‘component A imports or includes a package or the content of component B. 9. External coupling- occurs when a component communicates with the ‘nfrascructure components. ‘Cohesion- is the single mindedness of a component. It implies that a component or class encapsulates only attributes and operations that are closely related to ‘one another and to the class or component itself. (Cohesion is categorized as follows: 1. Functional- exhibited primarily by operations, this evel of cohesion occurs, ‘when a module performs one and only compatation and then returns a result 2, Layer- exhibited by packages, components, and classes, this type of ‘cohesion occurs whena higher layer accesses the services ofa lower layer. ‘3. Communicational- all operations that access the same data are defined ‘within one class. In general such classes focus solely on the data in question, accessing and storing it. 4. Sequential- components or operations are grouped ‘in a manner that allows the frst to provide input to the next and so on. ‘5. Procedural- components or operations are grouped in @ manner that allows ‘oneto be invoked immediately after the preceding one was invoked, even when there is no data passed between them. 6. Temporal- operations that are performed to reflect a specific behavior o stata, eg., an operation performed at start-up or all operations performed when an error is detected. - components, classes, or operations thet exist within the same category but are cthenvise unrélated are grouped together. Module 5 1. Explain White Box testing and Black Box Testing Ans: (Yaar naam se pata chal jata hat Bi SIV ko test tarna hai, SV banta medule wice hai alag-clag chote chote modiles mai, toh white box texting mein ‘yeh save modules ko chang se test karte hai) INTRODUCTION: > tis also known as Glass box testing.(Sab detail mai check hota hal isle) > Ittests the internal structure of the modtles. > [evaluates alllogical decisions and find whether they are true or false Module kandar ke saare conditions lite ifeketfec) > Guarantees the traversal of all independent paths at east once, (Example: Ek boar {condition rue lke et baar fae lee; yeh 2 independent path ue) > Itevaluates all the Inops-to check their boundaries. > Itevaluates all intemal data structures to confirm their validi ol array stack queue tree kuch use kiya hal progran mai tohwo ‘memory mai exist karta hai ya nahi.) Differeat whitebox testing Basis path testing > Flow graph notation, > Independent program paths. > Deriving tast cases. > Graph matrices + Control structure testing ~ Condition testing, > Data flow testing. > Loop testing. Basis path testing > Flow graphnotetion ‘Tho seach erst ew ero ead inonkranchong POL or tource cede sameentt ‘Now converting a flow chart to flow graph, > In considered example, Node number 2 &3 donot have any branch, node 3 will be processed immediately after node 2, thus we have combined it. > Similarly, for node 4 & 5. > The closed areas within the flow graph are callad as Regions. > Region Ra in the flow graphis termed as open region.(for pai I-11.) > Nodes which have decision in it are called as predicate nodes in our ‘example node(s}, (2,3), {6} are predicatenodes, > after flow graph conversion next step is finding the independent program paths and cyclomatic Complexity. Independent program paths. + These paths are independent of exch cther, Patht :>11 Patho :to2sg-sg-s5->10->0 518 Path3 : r>2>3-26->8->9->10>1>11 Path : 2223-62729 >see (0 Cyclomatic Complexity. {denoted by ViG)] + It isa measure of complexity of code. Three methods of finding cyclomatic complexity areas follows. + No. oftegions. n this example (4). + V(G) = (x)no. of edges - (9) no. of nodes + 2 =4 = VG) = (9) no. of predicate node +1= 4. ‘Deriving test cass: + Prepare test cases that will force execution of ecch path in the basis set «+ We have to prepare test cases in such a way that it forces the traversal of each independent program path. > Graph Matrices: + The flow graph is stored in computer memory in the form of matrix, + 4 2D array (Matri) stores the flow graph. Control Structure Testing > Condition Testing: - ot checks all the conditions within the program, types of conditions are as follows. A. Relational Expression: ~ Ex E2. B. Simple Condition: ~ Unary operators Eg. (~) NOT. (0C. Compound Condition: ~ (E1 & E2) | E28E3).{combination of two or more conditions) oD. Boolean Expression: - True / False. > Data Flow Testing: - ot checks the flow of data within the program: that is the flow control between the place where variable is declared and the plece where variableis used. lt ensures thet all the variable and their decleration within the rogram are working fine. > Loop Testing: - ‘Simple loops: - simple loop structures with a condition, ‘Nested loops:-loops within loop are called nested loop, here the outer loop controls the iterations of inner loop. ‘Concatenated Loops: - itconsists of loop, followed by another loop. ‘Unstructured Loops: -here the control is transferred from ody ofone loop to another Black Bex + The main focus in black box testing is on the functionality of the system as a whele, + Tt checks the behavior; hence it also known as “behavioral testing”. + Tt focuses on the functional requirements. + Black box testing is used after the completion ofthe software. + Itcannot be termed as the alternative for white box testing + It helps in deriving the set of input conditions (jo i imput dena h program io). + It checks the performance errors or behavioral errors. + It's applied in the final stage of testing. + Here testing fs not performed module wise. ‘The diferent methods of Black Box Testing are as follows:~ 1. Graph Based Testing- + In this technique we need to draw graph of objects and their relationships. + Serle of test cases are destgned, that cover the graph in such a way that cach object and its relationship is covered and the errorsare detected. + The representation of the graph is as follows: + Circle- Node connected by links + Directed link-fs denoted by an arrow in which relationship moves in one direction, + Bi-directional link- also called as symmetric link shows that the relationship is applied to both the objects + Parallel link- used where varions relationship existamong the graph nodes. + Itis a black bos testing method that divides the input domain of a program into classes of data from which test cases can be derived. «The partitioning is performed while testing in the following + Ifan input condition specifies a range, then one valid and two ‘invalid classes are defined. For example Range-> 211025, <1 ho Teal vad aval + Ifan input condition specifies a member ofa set then one valid and one invalid equivalence class is defined. For example Value=4 Set=(4,2,3,4,5) Value of set-valid Nota valueof set- invalid - If an input condition is Boolean, then one valid and one invalid equivalence classis defined. For example ‘Tme- valid False-invalid + If an input condition requires a specific value, then one valid and ‘two invalid classes are defined. For example Value=18 invalid 3.Boundary Value Analysis- « Here lange number of errors occurs at bounéaries. + The BVA actually selects the tast cases at the edge of the class. Guidelines for BVA: > Range: betveen a and b then test case should be designed beyond a and b, Forexample srange= (5-5) > Ifinput selects min and max then values just above and just below are also tested. For example- (20,18, 24,24) Mis 18— just above (17) ‘Max 24-+justbelow (25) > The above two guidelines are applied to output conditions. > Ifintemal program or its Data Structure prescribed some boundary values like an array of 100 numbers then it should use test cases thatare up to 100 entries only. 4. Orthogonal Array Testing- + It isa type of software testing which is systematic and statistical + Itisused when the number of inputs for the system is relatively small but itis large enough to accommodate the exhaustive testing + Orthogonal arrays can be applied in user interface testing, system testing, configuration testing and performance testing + Here testing cycle is reduced making the process of analysis simpler. 2. Cyclomatic complexity Ans: Cyclomatic complexity is a source code complexity measurement that is being correlated to a number of coding errors. itis calculated by developing a ‘Control Flow Graph of the code that measures the number of inearly-independent paths through a program module, Cyclomatic complexity s used to gauge the overall intricacy of an application or specific functionality within, The software metric quantitatively measures a program’ logical strength based on existing decision paths in thesourve code. Itis ‘computed by using the control low graph, where each node on the graph represents indivisible groups or commands within the program, Forexample, an application consisting of zero decision points (IF, FOR, etc.) has an intricacy score of 1 becanse it containsa single path in the source code. Ifthe program containsan IF statement consisting of on2 condition, the code would contain a total of two paths: TRUE or FALSE. The cyclomatic complexity elgorithm is used to derive a measurable value based on the number of edges and nodes ‘within the graph 2s well as the total count of connected components or exit nodes. Itisrepresented as shown below: ‘Complesity (M1) = Edges (E) - Nodes (N) + Exit Nodes ®) ‘Individual programs, subroutines, or methods always have one exit node, thus resulting in the value of P equaling one. This value remains consistent unless ‘multiple applications with several exit points are to be assessed at the same time, Lower the Program's cyclomatic complesity, lower the risk to modify and easier to understand. It can be represented using the below formula: E = number of edges in the flow graph. 1N =number of nodes in the flow graph. P = number of nodes that have exit points Example: IPA=10 THEN IFB>CTHEN FlowGraph: Cyclomatic complesity in Test Life Cycle = =< ‘The Cyclomatic complexity is calculated using the above control flow diagram thet shows seven nodes(shapes) and eight edges (lines), hence the cyclomatic complexity is 8-7 +2= 3, Explain Object Oriented Testing Methods. Ans: + Here the test cases made are changed due to class hierarchy. + This contains classes in which the date is encapsulated and integrated. + Types of object oriented testing methods are as follows: 1. Fault based testing- - Hore we design the test cases that have the probability of detecting high number of errors. + Usually we give test cases where more errors wil be detected. + Itdepands on the tester completely. + So to get good or best results the tester should be more experienced. + So here we can get good results with less efforts, + Ttmay happen that in simple test cases we get to know if {interaction of subsystemsis proper or not, + The main drawback of this testing is that itdoes notfocus on ‘the user's requirements and the interactions among the various subsystems, + Hore the user creates a scenario (ase cases). + Itdepends on the user completely. + Ituncovers theinteraction errors, + Iteovers incorrect specifications. + Here the main focus is lad upon what the users doing, not on ‘what the product does, + Itinvolvesa condition under which the scenario runs. + Itinvolvesa set of steps of actions. + Ttcombines all the classes that support a use-case and executes atest case totest them. + To ensure that.all methods in all the classes are executed at least once during testing then execution ofall the test cases should be completed. + Ths testing all the objects together comes up to bea difficult task, + So rather than testing all objects together, testing is done ‘through either top-down or bottom-up integration approach. Challenges in Testing Object-oriented Frograms + While testing, encapsulation of attributes and methods in class may create obstacles. Here the state of the objectat the time of ‘invocation of method affects the behavior of testing. + Inheritance and polymorphism are also one of the major problems in cbject oriented testing. Here thetest cases designed for the base classes are not applicable tothe derived classes. 4, Write short note on Reverse Engineering. Ans: + Tt the process of analyzing a program in an effort to create representation of the program at the level of abstraction than the source code. + Tt cen be termed as the process of design recovery, + Here systemis analyzed at higher level of abstraction, (design hte te source code ta pta trea) + From this source code knowledge and design information is extracted. (souce code se naya design) + The purpose of reverse engineering 4 Ttean beused as learning tools. 2. tis used for security auditing, 3. It enables the new features to be added. 4.It is used in developing compatible products cheaper than that are currently available in the market. ‘There are three levels of Reverse Engineering:- 1. abstraction level: + Itis the highest level + Here information is extracted from the source code, + Ithelps the software engineer to understand the program. 2, Completeness: + Here we observe that the information given by the abstraction level is complete or not. « Completeness means detailing of the abstraction level. + As abstraction level increases completeness decreases. + Tt develops interactivity in reverse engineering. «The interactivity to bring the completeness increases with the increase in the abstraction level 3. Directionality: + Ttmakes available the information from the source code and provides it to the software engineer + Tecan be one way or two way process. + One way directionality source code and given to the software engineer. + Two way directionality means the information which is extracted from the source code is fed toa re-engineering tool that attempts to restructure old programs. ‘means the information is extracted from the + Firstly the raw source code is refined here, + The outcome of refining this raw code is that we get a clear source code which ‘quality based better es compared to the raw source code, + Then this code is abstracted using extract abstraction. + This extract abstraction consists of three parts: processing, interface, databases. + Processing means how the software or srstem is working, interface means ‘which component is linked or interfaced with which component, databases gives the information of about what type of databases are used in the system or software. + After all this we get the intial spectiications of the system (tld jo system tha + In these initial specifications we add some new features which improve the quality of the system, all these new features are added through refinement and simplification, + Tihs at last we get the final specification which helpsin easy understanding of the source code, 5. Alpha & Beta Testing ‘Ans: Alpha Testing isa type of software testing performed to identify bugs before releasing the product to real users or to the public. Alpha Testing is one of the user acceptance testing, ‘This is referred toas an alpha testing only because it s done early on, near theend of the development of the software, Alpha testing is commonly performed by homestead software engineers or quality assurance staifs It is the ast testing stage before the software is released into the real world. Objective of Alpha Testing: 1. The objective of alphe testing is to refine the software product by finding the bugs that were not discovered during the previous tests. ‘2. The objective of alphe testing isto refine the software product by fixing the bugs that were not discovered during the previous tests. +3. The objective of alphe testing isto involve customer deep into the process of development. 4. The objective of alpha testing is to give better insight into the software's reliability atthe early stages of development. alpha Testing Process: 1. Review the design specification and functional requirements. +2, Develop comprehensive test cases and tast plan, 3. Execute test plan 4. Log defects 5. Retest once the issues have been fixed Review design specification and functional requirements Develop comprehensive test cases and test plan Execute test plan Log defects Phases of Alpha Testing: ‘There are two phases in alpha testing: ast Phase: ‘The firs: phase of testing is done by in-house developers or software engineers. ‘They either use hardware-aided debuggers or debugger softwere. The aim isto catch bugs quickiy. Usually while alpha testing, 2 tester comes across to lots of ‘bugs, crashes, missing features, and docs. ‘and Phese: ‘The second phase of alphe testing is done by software quality assurance staff for additional testing in an enviroament. Itincludesa black box as well as white box testing. Advantages of Alpha Testing: 1. Better insight about the software's reliability atts early stages. 2, Free up your team for other projects, 3, Itreduces delivery timeto market. 4. Early feedback helps to improve software quality ‘Bata Testing is performed by real users ofthe software application in a real environment, Beta testing is one ofthe types of User Acceptance Testing. A Beta version ofthe software, whose feedback is needed, is released to a limited number of end-users ofthe product to obtain feedback on the product quality. Beta testing ‘helps in minimization of product failure risks and it provides increesed quality of ‘the product through customer validation, Ibis the last test before shipping a product to the customers. One of the major advantages of beta testing is direct feedback from customers. (Characteristics of Beta Testing: 1. Beta Testing is performed by clients or users who are notemployees of the security, ané robustness are checked during beta testing. 9. Beta Testing commonly uses black-box testing. 4, Beta testing is carried out inthe user's location. 5. Beta testing doesn’t require lab or testing environment. ‘Types of Beta Testing: ‘Thereare different types of beta testing: 2. Traditional Beta testing: Product is distributed io the target market and related data is gathered in all aspects. This data can be used for Product improvement, +, Public Beta Testing: Productis released publicly to the world through online channels and data can be collected from anyone. Based on feedback, product improvements can be done, For example, Microsoft conducted the largest of all Beta Tests for its operating system Windows 8 before offically releasing it, 23, Technical Beta Testing: Product is released to a group of emplovees of an organization and collects feedback data from the employees ofthe organization, 4, Focused Beta Testing: Software productis released to the market for collecting feedback oa specific features ofthe program, For , important functionality of the software, +5. Post-release Beta Testing: Software product is released to the market and data is collected to make improvements for the future release of the product. Criteria for Beta Testing: 1. Sign offa document on Alpha testing, +2. The Beta version of the software should be ready 3. Environment ready to release the software application to the public 4. Tool to capture real-time faults Advantages of Beta Testing: 1. It reduces product failure risk via customer validation, 2. Beta Testing allows a company to test post-launch infrastructure, 23. It elpsin improving product quality via customer feedback. 4, Cost-effective compared to similar data gathering methods ‘5 Tt creates goodwill with customers and increases customer satisfaction. Disadvantages of Beta Testing: 1. Sometimes, its complex to follow the errors or bugs because the testing environment varies from user to user. ‘2. There isa chance of having duplication of errors or bugs. 3. The development team and the testing team are not having comtrol over this real-time test environment. 4 This testing is atime consuming process sinc» it involves real time wsers or clients and hence delay in the overall feedback about the entire product. 5 The users who are testing the product should have encugh knowledge about the working ofthe entire application or product. Otherwise, the testing will not be implemented in an efficient manner. Difference between alpha and Beta Testing: ‘The difference betwoon Alpha and Beta Testing is as follows: ‘Alpha Testing Beta Testing ‘Alpha tesiing invches both the white box and black box testing Bets testing commonly uses black-box ‘esting ‘Alpha tesiing is performed by testers who are usually intemal employees of the Srganization Bets testing is performed by cients who are ‘ot pat of the organization ‘Alpha testing i performed at the developer's sit Bets testing is performed at the end-user of the product Relibilty and securly testing are not checked in alpha testing, Relablty, security and checked during beta testing, robustness are ‘Alpha testing ensures the gualty of the Product before forwarding to beta testing, Beta testing also concentrates on the quality of the product but collects users input on the product and ensures thet the product is Alpha testing requies a testing | Beta testing dosent requre a testing environment ora lab ‘environment or lab, ‘Alpha testing may require a long | Beta testing requkes only a few weeks of ecution eye Swecution Developers can immediately adress the ceal esues of tues in alpha tasting Most of the issues or feedback collected ‘rom the teta testing wil be implemented in future versions of the product Multiple test eles ara organized in alpha testing Onl one ar two test eycloe ara thera in eta resting, Module 6 1. Explain risk mitigation, monitoring and management. Ans: + The risks analysis activities presented havea single goal-to assist the project team {in developing a strategy for dealing with risk. + RIMM is an effective strategy to deal with risk, + The three issues are as follows: s.Riskavoidance 2.Risk monitoring 3. Risk management and contingency planning + Ifa software team adopts a proactive approach to risk, avoidance is always teh best strategy, This is achieved by developinga plan for risk mitigation, + For example- assume that high staff turnover is noted as a project risk, r.based ‘on past history and management intuition, the likelihood, ls, of high turnover is estimated tobe 0.70 and the impact x1, projected as critical. That is, high turnover wwillhave a critical impact on project cost and schedule, + Tomitigate this risk, project management must develop a strategy for reducing ‘tumover. Among the possible stepsto be taken are: + Meet with current staffto determine causes for tumover + mitigate those causes that are under our control before the project starts + Organize project teams so that information about each development activity is widely dispersed + Define documentation standards and establish mechanisms to ensure that ‘documents are developed in a timely manner + Assign a backup staff member for every critical technologist. + As the project proceeds, risk monitoring activities commence. The project ‘manager monitors factors that may provide an indication of whether theriskis, becoming more or less likely «The following factors can be monitored: + General attitude of team members based on project pressure, + Interpersonal relationships among team members. + Potential problems with compensation and benefits. «The availability of jobs within the company and outside it + In addition to monitoring these factors, a project manager should monitor the effectiveness of risk mitigation steps. + The project manger should monitor documents carefully to ensure that each can stand om its own and that each imparts information that would be necessary ifa ‘eweomer were forced to join the software team somewhere in the middle of the project. + Risk management and contingency planning assumes that mitigation efforts have and that the risk has become a reality. + Its important to note that risk mitigation, monitoring and management (RAM steps incur additional project cost. + The project planner performs a classic cost benefit analysis. + Iftisk aversion steps for high tumover will Increase both project cost and duration by an estimated 15%, but the cost factor is*baciup”, management may decide nct to implement this step. RMMM Plan: + Arisk management strategy can be included in the software project plan or risk ‘management steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan. + The RMMM plan docaments all work performed as part of risk analysis end is ‘used by the project manager as part of the overall project plan, + Some software teams do not develop a formal RMMM document, rather each risk is documented individually using a risk information sheet (RIS). + The RIS {s maintained using a database system, so that creation and information entry, priority ordering, searches may be accomplished asi + The format ofthe RISis shown below: Risk information Shoot Doayie! Refinement cates Miaganonmononng ‘Maagencnconangesey Fan gB=t 2. Explain Formal Technical Review (FTR). Ans: Formal Technical Review (FTR) is a SQA Activity. SQA stands for Software Quality Assurance. | FTRis a type of review conducted by technical stafi-software engineers. + It focuses on making system error free. ‘The main objectives of FTRare as follows.- 1 Itis used to uncover the errors. 2. Its used to verify that software under review meets the requirements, 3. It maintains the standards which were pre-defined. 4 Itmakes the project manageable and effective, 5 Itensures that the software is developed in uniform manner. 6. Groom new resources. 7 Provide backup and continuity. Itincludes- ‘Walk-through, inspections, other small group technical measurements of software, Itis conducted in a meeting that is successful only if is properly planned, controlled, and attended, Guidelines for walkthroughs The review meeting is + Between 3-5 people. + advanced preparation “Should not require more then 2 hours of work er person. + Less than twohours. + Focuses on specific part of the overall software. + Focus is on work product. + Producer- asks the project leader for review. + Project leader informs the review leader. + The review leeder- evaluates the work process + The review meetings attended by the review leader, all reviewers, and the producer. + One of the reviewers takes the roles of recorder. + Producer walks through the product, explaining the material ‘Review Reporting and Record Keeping + During the FTR the recorder notesall the issues + These issues are summarized at the end and a review issue list s prepared + Asummary report is produced that inclades: whet is reviewed, who reviewed it, what were the conclusions + This report makes ervor identification easy + Servesas checklist for developers ‘The Reviewer raises issue based on their advanced preparation at the ené, all attendees of the FTR must decide + accept the product without further modification «+ Reject the product due to severe errors + accept the product provisionally, Le. with some modification 3. Change Control & Version Control in SCM Ans: Software configuration management (SCM) is ¢ software engineering

    You might also like