Q1 B) Compare and contrast White box testing and Black box testing.

Black-Box Testing :
1. Black box testing, also called behavioral testing, focuses on the functional requirements of the software. 2. Black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. 3. Black-box testing attempts to find errors in the following categories: i. Incorrect or missing functions. ii. Interface errors iii. rrors in data structures or external database access. iv. Behavior or performance errors, and v. Initiali!ation and termination errors.

4. "nlike white-box testing, which is performed early in the testing process, black-box testing tends to be applied during later stages of testing. Because black-box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. 5. #ests are designed to answer the following questions: 1. $ow is functional validity tested% 2. $ow is system behavior & performance tested% 3. 'hat classes of input will make good test cases% 4. Is the system particularly sensitive to certain input values% 5. $ow are the boundaries of a data class isolated% 6. 'hat data rates and data volume can the system tolerate% 7. 'hat effect will specific combinations of data have on system operation% Advantages Of Black-Box Testing : By applying black-box techniques, a set of test cases can be derived that satisfy the following criteria: 1. #est cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing. 2. #est cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

 WHIT -B!" T #TI$% : 1. 'hite-box testing, sometimes called glass-box testing is a test case design method that uses the control structure of the procedural design to derive test cases. 2. "sing white-box testing methods the software engineer can derive test cases that i. (uarantee that all independent paths within a module have been exercised at least once. ii. xercise all logical decisions on their true and false sides. iii. xecute all loops at their boundaries and within their operational bounds and iv. xercise internal data structures to ensure their validity.

Reasons/Advantages of conducting white-box tests: 1. )ogic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. rrors tend to creep into ones work when one design and implement function, conditions, or control those are out of the mainstream. veryday processing tends to be well understood *and well scrutini!ed+, while ,special case- processing tends to fall into the cracks. 2. 'e often believe that a logical path is not likely to be executed when in fact. it may be executed on a regular basis. #he logical flow of a program is sometimes counter intuitive, meaning that ones unconscious assumptions about flow of control and data may lead us to make design errors that are uncovered only once path testing commences. 3. #ypographical errors are random. 'hen a program is translated into programming language source code, it is likely that some typing errors will occur. /any will be uncovered by syntax and type checking mechanisms, but others may go undetected until testing begins.

Q& ') What is the p(rpose o) $ormali*ation. Ill(strate the method o) normali*ation o) database
$ormali*ation : 0ormali!ation is the process of taking data from a problem and reducing it to a set of relations while ensuring data integrity and eliminating data redundancy 1ata integrity - all of the data in the database are consistent, and satisfy all integrity constraints. 1ata redundancy 2 if data in the database can be found in two different locations *direct redundancy+ f data can be calculated from other data items *indirect redundancy+ then the data is said to contain redundancy. Example Of o!mali"ation :

1ata taken is used to illustrate the process of normali!ation. 3 company obtains parts from a number of suppliers. ach supplier is located in one city. 3 city can have more than one supplier located there and each city has a status code associated with it. ach supplier may provide many parts. #he company creates a simple relational table to store this information that can be expressed in relational notation as : 4I56# *s7, status, city, p7, qty+ where supplier identifcation number *this is the primary s7 key+ statu status code assigned to city s city name of city where supplier is located p7 part number of part supplied qty8 quantity of parts supplied to date In order to uniquely associate quantity supplied *qty+ with part *p7+ and supplier *s7+, a composite primary key composed of s7 and p7 is used. #i!st o!mal #o!m : 3 relational table, by definition, is in first normal form. 3ll values of the columns are atomic. #hat is, they contain no repeating values. 4igure9 shows the table 4I56# in 904.

#igu!e $: Table in $ #

3lthough the table 4I56# is in 904 it contains redundant data. 4or example, information about the supplier:s location and the location:s status have to be repeated for every part supplied. 5edundancy causes what are called update anomalies. "pdate anomalies are problems that arise when information is inserted, deleted, or updated. 4or example, the following anomalies could occur in 4I56#:

I06 5#. #he fact that a certain supplier *s;+ is located in a particular city *3thens+ cannot be added until they supplied a part. 1 ) # . If a row is deleted, then not only is the information about quantity and part lost but also information about the supplier. "<13# . If supplier s9 moved from )ondon to 0ew =ork, then six rows would have to be updated with this new information.

%econd o!mal #o!m #he definition of second normal form states that only tables with composite primary keys can be in 904 but not in >04. 3 relational table is in second normal form >04 if it is in 904 and every non-key column is fully dependent upon the primary key. #hat is, every non-key column must be dependent upon the entire primary key. 4I56# is in 904 but not in >04 because status and city are functionally dependent upon only on the column s7 of the composite key *s7, p7+. #his can be illustrated by listing the functional dependencies in the table: s7 ?8 city, status city ?8 status *s7,p7+ ?8qty #he process for transforming a 904 table to >04 is:

1. Identify any determinants other than the composite key, and the columns they determine. 2. @reate and name a new table for each determinant and the unique columns it determines. 3. /ove the determined columns from the original table to the new table. #he determinate becomes the primary key of the new table. 4. 1elete the columns you Aust moved from the original table except for the determinate which will serve as a foreign key. 5. #he original table may be renamed to maintain semantic meaning. #o transform 4I56# into >04 we move the columns s7, status, and city to a new table called 6 @B01. #he column s7 becomes the primary key of this new table. #he results are shown below in 4igure >. #igu!e &: Tables in & #

#ables in >04 but not in C04 still contain modification anomalies. In the example of 6 @B01, they are I06 5#. #he fact that a particular city has a certain status *5ome has a status of ;D+ cannot be inserted until there is a supplier in the city. 1 ) # . 1eleting any row in 6"<<)I 5 destroys the status information about the city as well as the association between supplier and city. Thi!d o!mal #o!m #he third normal form requires that all columns in a relational table are dependent only upon the primary key. 3 more formal definition is: 3 relational table is in third normal form *C04+ if it is already in >04 and every non-key column is non transitively dependent upon its primary key. In other words, all nonkey attributes are functionally dependent only upon the primary key. #able <35#6 is already in C04. #he non-key column, qty, is fully dependent upon the primary key *s7, p7+. 6"<<)I 5 is in >04 but not in C04 because

it contains a transitive dependency. 3 transitive dependency is occurs when a non-key column that is a determinant of the primary key is the determinate of other columns. #he concept of a transitive dependency can be illustrated by showing the functional dependencies in 6"<<)I 5: 6"<<)I 5.s7 ?8 6"<<)I 5.status 6"<<)I 5.s7 ?8 6"<<)I 5.city 6"<<)I 5.city ?8 6"<<)I 5.status 0ote that 6"<<)I 5.status is determined both by the primary key s7 and the non-key column city. #he process of transforming a table into C04 is: 1. Identify any determinants, other the primary key, and the columns they determine. 2. @reate and name a new table for each determinant and the unique columns it determines. 3. /ove the determined columns from the original table to the new table. #he determinate becomes the primary key of the new table. 4. 1elete the columns you Aust moved from the original table except for the determinate which will serve as a foreign key. 5. #he original table may be renamed to maintain semantic meaning. #o transform 6"<<)I 5 into C04, we create a new table called @I#=E6#3#"6 and move the columns city and status into it. 6tatus is deleted from the original table, city is left behind to serve as a foreign key to @I#=E6#3#"6, and the original table is renamed to 6"<<)I 5E@I#= to reflect its semantic meaning. #he results are shown in 4igure C below. #igu!e ': Tables in ' #

#he results of putting the original table into C04 has created three tables. #hese can be represented in Fpseudo-6G)F as: <35#6 *7s, p7, qty+ <rimary Hey *s7,7p+ 4oreign Hey *s7+ references 6"<<)I 5E@I#= .s7 6"<<)I 5E@I#=*s7, city+ <rimary Hey *s7+ 4oreign Hey *city+ references @I#=E6#3#"6.city

@I#=E6#3#"6 *city, status+ <rimary Hey *city+ Advantages of Thi!d o!mal #o!m : #he advantage of having relational tables in C04 is that it eliminates redundant data which in turn saves space and reduces manipulation anomalies. 4or example, the improvements to our sample database are : I06 5#. 3 fact about the status of a city, 5ome has a status of ;D, can be added even though there is not supplier in that city. )ikewise, facts about new suppliers can be added even though they have not yet supplied parts. 1 ) # . Information about parts supplied can be deleted without destroying information about a supplier or a city. "<13# . @hanging the location of a supplier or the status of a city requires modifying only one row.

Q& B ) +isc(ss the six special s,stem test

#,stem testing 6ystem testing is actually a series of tests whose purpose is to fully exercise the computer-based system. 3lthough each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions. 6ome types of common system tests are : i( Recove!) testing : /any computer-based systems must recover from faults and resume processing within a pre-specified time. In some cases, a system must be fault-tolerant, i.e. processing faults must not cause overall system function to cease. In other cases, a system failure must be corrected within a specified period of time or severe economic damage will occur. 5ecovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic, re-initiali!ation, check-pointing mechanisms, data recovery and restart are evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair */##5+ is evaluated to determine whether it is within acceptable limits. ii( %ecu!it) testing : 3ny computer-based system that manages sensitive information or causes actions that can harm individuals is a target for improper or illegal penetration. 6ecurity testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. 1uring security testing, the tester plays the role of the hacker who desires to penetrate the system. (iven enough time and resources, good security testing will ultimately penetrate a system. #he role of the system designer is to make

penetration cost more than the value of the information that will be obtained. iii( %t!ess testing : 1uring earlier testing steps, white box and black box techniques result in a thorough evaluation of normal program functions and performance. 6tress tests are designed to confront programs with abnormal situations. 6tress testing executes a system in a manner that demands resources in abnormal quantity, frequency or volume. ssentially, the tester attempts to break the program. 3 variation of stress testing is a technique called sensitivity testing. In some situations, a very small range of data contained within the bounds of valid data for a program may cause extreme and even erroneous processing or performance degradation. 6ensitivity testing attempts to uncover data combinations within valid input classes that may cause instability or improper processing. iv( *e!fo!mance testing : 6oftware that performs the required functions but does not conform to performance requirements is unacceptable. <erformance testing is designed to test run-time performance of software within the context of an integrated system. <erformance testing occurs through all the steps in the testing process.

Q- ') What cost elements are considered in the cost.bene)it anal,sis/ What do ,o( think is the most di))ic(lt to estimate / Wh,/
Cost.Bene)it 'nal,sis It is the analysis used to compare costs and benefits to see whether the investment in the development of a new system will be more beneficial than costly. +ost And Benefits +atego!ies : In developing cost estimates for a system, we need to consider several cost elements. 4ollowing are the types of costs that are analy!ed : ,a!dwa!e +osts : @osts related to actual purchases or leasing of computers and peripheral devices. *e!sonnel +osts : @osts including staff salaries and benefits *staff includes system analysts, programmers, end-users, etc.+. #acilit) +osts: @osts involved in the preparation of the physical site where the computer system will be operating *wiring, flooring, air conditioning, etc.+. -evelopmental +osts: @osts involved in the development of the system *hardware costs, personnel costs, facility costs+. Ope!ating +osts : @osts incurred after the system is put into production i.e. the day-to-day operations of the system *salaries of people using the application, etc.+.

3 system is also expected to provide benefits.#he first task is to identify each benefits and then assign a monetary value to it for costIbenfit analysis. Benefits may be tangible and intangible or direct and indirect.#he two maAor benefits are as follows : Improving performance : #he performance category emphasis improvement in the accuracy of or access to information and easier access to the system by the authorised users. /inimi!ing the cost of processing : /inimi!ing costs through an efficient system- error control or reduction of staff 2 is a benefit that should be measured and included in costIbenefit analysis.

.ost difficult to estimate / 0h) / *<art two of the question is not complete+

Q- B) xplain )act )inding techni0(es

1act-1inding 2ethods: 4act-finding techniques are used to identify system requirements, through comprehensive interaction with the users using various ways of gathering information. #here are six methods of Information (athering which are as follows : $1 -ist!ibute 2 +ollect 3uestionnai!es : Guestionnaires enable the proAect team to collect information from a large number of stakeholders conveniently, and to obtain preliminary insight on their information needs. #his information is then used to identify areas that need further research using document reviews, interviews, and observation. Guestionnaires can be used to answer quantitative questions, such as ,$ow many orders do you enter in a day%6uch questions are called closed-ended questions i.e. questions that have simple, definitive answers and do not invite discussion or elaboration. #hey can be used to determine the userJs opinion about various aspects of a system *say, asking the user to rate a particular activity on a scale of 9-;+. Guestionnaires, however, do not provide processes, work-flow, or techniques used. information about

Guestions that illicit a descriptive response are best answered using interviews, or observation. 6uch questions that encourage discussion and elaboration are called open-ended questions.

&1 Review Existing Repo!ts4 #o!ms4 and *!ocedu!e -esc!iptions : #wo advantages of reviewing existing documents documentation: #o get a better understanding of processes and

#o gain knowledge about the industry or the application that needs to be studied.

3n analyst requests for and reviews procedural manuals, and work descriptions, in order to understand business functions.

1ocuments and reports can also be used in interviews, where forms and reports are used as visual aid, and working documents are used for discussion. 1iscussion can center on use of each form, its obAective, distribution, and information content. 4orms already filled-out with real information ensure a correct understanding of the fields and data content. 5eviewing existing documentation of existing procedures helps identify business rules, while written procedures also help in discovering discrepancies and redundancies in the business processes. It is essential to ensure that the assumptions and business rules derived from existing documentation are accurate.

'1 +onduct 5nte!views 2 -iscussions with 6se!s : Interviewing stakeholders is considered the most effective way to understand business functions and rules, though it is also the most time-consuming and resource-expensive. In this method, members of the proAect team *system analysts+ meet with individual groups of users, in one or multiple sessions in order to understand all processing requirements through discussion. 3n effective interview consists of three parts: *a+ <reparing for the interview *b+ @onducting the interview and *c+ 4ollowing up the interview. Befo!e an 5nte!view: stablish obAective of interview *what do you want to accomplish through this interview%+ 1etermine correct user*s+ to be involved *no. of users depends on the obAective+ 1etermine proAect team members to participate *at least >+ Build a list of questions and issues to be discussed 5eview related documents and materials *list of specific questions, open and closed ended+ 6et the time and location *quiet location, uninterrupted+ Inform all participants of obAective, time, and locations *each participant should be aware of obAective of the interview+

-u!ing an 5nte!view: 1ress appropriately *show good manners+ 3rrive on time *arriving early is a good practice, if long interview, prepare for breaks+ )ook for exceptions and error conditions *ask ,what ifquestions, ask about exceptional situations+ <robe for details *ensure complete understanding of all procedures and rules+ #ake thorough notes *handwritten note-taking makes user feel that what he has to say is important to you+ Identify and document unanswered items or open questions *useful for next interview session+ Afte! an 5nte!view: 5eview notes for accuracy, completeness, and understanding *absorb, understand, document obtained information+ #ransfer information to appropriate models and documents *create models for better understanding after complete review+ Identify areas that need further clarification *keep a log of unanswered questions, such as those based on policy questions raised by new system, include them in next interview+ 6end thank-you notes if appropriate

71 Obse!ve Business *!ocesses 2 0o!k-flow : Bbserving business procedures that the new system will support are an excellent way to understand exactly how the users use a system, and what information they need. 3 quick walkthrough of the work area gives a general understanding of the layout of the office, the need and use of computer equipment, and the general workflow. 3ctually observing a user at his Aob provides details about the actual usage of the computer system, and how the business processes are carried out in reality. Being trained by a user and actually performing the Aob allows one to discover the difficulties of learning new procedures, the importance of an easy-to-use system, and drawbacks of the current system that the new system needs to address. It must be remembered that the level of commitment required by different processes varies from one process to another. 3lso, the analyst must not be a hindrance to the user.

81 Build *!otot)pes :

Building a prototype implies creating an initial working model of a larger, more complex entity. #ypes of prototypes: prototypes. throwaway, discovery, design, evolving

1ifferent phases of the 61)@ require different prototypes. #he 1iscovery <rototype is used in the <lanning & 3nalysis phases to test feasibility and help identify processing requirements. #he 1evelopment <rototype is used in the design, coding and implementation phases, to test designs, effectiveness of code and workability of software. 1iscovery prototypes are usually discarded after the concept has been tested, while an volving prototype is one that grows and evolves and may eventually be used as the final, live system. +ha!acte!istics of *!otot)pes: 3 prototype should be operative i.e. a working model, that may provide lock-and-feel but may lack some functionality. It should be focused on a single obAective, even if simple prototypes are being merged into a single large prototype. It should be built and modified easily and quickly, so as to enable immediate modification if approach is wrong.

91 +onduct :oint Application -esign ;:A-( %essions : K31 is a technique used to expedite the investigation of system requirements. "sually, the analysts first meet with the users and document the discussion through notes & models *which are later reviewed+. "nresolved issues are placed on an open-items list, and are eventually discussed in additional meetings. #he obAective of this technique is to compress all these activities into a shorter series of K31 sessions with users and proAect team members.

1uring a session, all of the fact-finding, model-building, policy decisions, and verification activities are completed for a particular aspect of the system. #he success of a K31 session depends on the presence of all key stakeholders and their contribution and decisions.

Q3 ') xplain 4'+ and 5ater)all model

4apid 'pplication +e6elopment74'+) 2odel : 5apid 3ction 1evelopment is an incremental software development process model that emphasi!es an extremely short development cycle. #he 531 model is a high-speed adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and proAect scope is constrained, the 531 model enables a development team to create a fully functional system within LD-MD days. "sed primarily for information system applications, the 531 approach encompasses the following phases : Business modeling : #he information flow among business functions is modeled so as to understand the following: i+ #he information that drives the business process . ii+ #he information generated. iii+ #he source and destination of the information generated. iv+ #he processes that affect this information.

-ata modeling : #he information flow defined, as a part of the business-modeling phase is refined into a set of data obAects that are needed to support the business. #he attributes of each obAect are identified and the relationships between these obAects are defined. *!ocess modeling: #he data obAects defined in the previous phase are transformed to achieve the information flow necessary to implement a business function. <rocessing descriptions are created for data manipulation. Application gene!ation : 531 assumes the use of fourth generation techniques 5ather than using third generation languages, the 531 process works to reuse existing programming components whenever possible or create reusable components. In all cases, automated tools are used to facilitate construction.

Testing and tu!nove!: 6ince 531 emphasi!es reuse, most of the components have already been tested. #his reduces overall testing time. $owever, new components must be tested and all interfaces must be fully exercised. In general, if a business function can be modulari!ed in a way that enables each function to be completed in less than three months, it is a

candidate for 531. ach maAor function can be addressed by a separate 531 team and then integrated to form a whole. Advantages : /odulari!ed approach to development @reation and use of reusable components 1rastic reduction in development time -isadvantages : 4or large proAects, sufficient human resources are needed to create the right number of 531 teams. 0ot all types of applications are appropriate for 531. If a system cannot be modulari!ed, building the necessary components for 531 will be difficult. 0ot appropriate when the technical risks are high. 4or example, when an application makes heavy use of new technology or when the software requires a high degree of interoperability with existing programs.

Classic 8i)ec,cle 2odel : #his model is also known as the waterfall or linear sequential model. #his model demands a systematic and sequential approach to software development that begins at the system level and progresses through analysis, design, coding testing and maintenance. 4igure 9.9 shows a diagrammatic representation of this model.

#he life-cycle paradigm incorporates the following activities:

%)stem enginee!ing and anal)sis : 'ork on software development begins by establishing the requirements for all elements of the system. 6ystem engineering and analysis involves gathering of requirements at the system level, as well as basic top-level design and analysis. #he requirement gathering focuses especially on the software. #he analyst must understand the information domain of the software as well as the required function, performance and interfacing. 5equirements are documented and reviewed with the client. -esign: 6oftware design is a multi-step process that focuses on data structures, software architecture, procedural detail, and interface characteri!ation. #he design process translates requirements into a representation of the software that can be assessed for quality before coding begins. #he design phase is also documented and becomes a part of the software configuration. +oding: #he design must be translated into a machine-readable form. @oding performs this task. If the design phase is dealt with in detail, the coding can be done mechanically. #esting : Bnce code is generated, it has to be tested. #esting focuses on the logic as well as the function of the program to ensure that the code is error free and that oIp matches the requirement specifications. .aintenance : 6oftware undergoes change with time. @hanges may occur on account of errors encountered, to adapt to changes in the external environment or to enhance the functionality and I or performance. 6oftware maintenance reapplies each of the preceding life cycles to the existing program. #he classic life cycle is one of the oldest models in use. $owever, there are a few associated problems. %ome of the disadvantages a!e given below1 9. 5eal proAects rarely follow the sequential flow that the model proposes. Iteration always occurs and creates problems in the application of the model. >. It is difficult for the client to state all requirements explicitly. #he classic life cycle requires this and it is thus difficult to accommodate the natural uncertainty that occurs at the beginning of any new proAect.

C. 3 working version of the program is not available until late in the proAect time span. 3 maAor blunder may remain undetected until the working program is reviewed which is potentially disastrous. In spite of these problems the life-cycle method has an important place in software engineering work. 6ome of the reasons are given below. 9. #he model provides a template into which methods for analysis, design, coding, testing and maintenance can be placed.

>. #he steps of this model are very similar to the generic steps that are applicable to all software engineering models.

3. It is significantly preferable to a hapha!ard approach to software development.

Q9 ') +escribe components o) C'# Tools: indicating the )(nction per)ormed b, each.
+ompute! Aided %oftwa!e Enginee!ing ;+A%E( tools #oday software engineers use tools that are analogous to the computer-aided design and engineering tools used by hardware engineers. @36 tools support contemporary systems development. It automates step-by-step development methods. It reduces the amount of repetitive work. It allows developers to free their ,mind cycles- for more creative problem-solving tasks. +atego!ies Of +A%E tools Integrated @36 tools*contains functionality of both+. "pper @36 )ower @36 1. 6ppe! +A%E tools :

3llows the analysts to create and modify the system design. "pper @36 tools primarily help the analysts and designers. 3ll info about the proAect is stored in the @36 repository 2 encyclopedia *collection of recordsI elements+ that contains diagrams, screens, and other info. 3nalysis reports are produced using the repository information, for validation. 3lso helps in modeling functional requirements of organi!ations. $elps in drawing the boundaries for a given proAectIsystem. $elps analysts to visuali!e how the present proAect *subsystem+ meshes with the other *sub+systems of the organi!ation.

2. <owe! +A%E tools : )ower @36 tools are used more by the programmers and others who implement the systems designed via upper @36 tools. "sed to generate source code 2 reduces the programming effortsIcost greatly @ode generation may be slow initially 2 familiarity with the methodology used by a tool. #esting, and maintenance costs are reduced 2 test, debug, modify efforts are greatly reduced. 'ith change in design the code is simply regenerated. #here are several different tools with different functionalities.#hey are: i( Business s)stems planning tools By modeling the strategic information requirements of an organi!ation, these tools provide a meta-model from which specific information systems are derived. Business systems planning tools help software developers to create information systems that route data to those that need the information. #he transfer of data is improved and the decision-making is expedited. ii( *!o=ect management tools "sing these management tools, a proAect manager can generate useful estimates of cost, effort and duration of a software proAect, plan a work schedule and track proAects on a continuous basis. In addition, the manager can use these tools to collect metrics that will establish a baseline for software development quality and productivity. iii( %uppo!t tools #his category encompasses document production tools, network system software, databases, electronic mail, bulletin boards and configuration management tools that are used to control and manage the information that is created as the software is developed. iv( Anal)sis and design tools #hese enable the software engineer to model the system that is being built. #hese tools assist in the creation of the model and an assessment of the models quality. By performing consistency and validity tests on each model, these tools provide the engineer with the insight and help to eliminate errors before they propagate into the program.

v+ <rogramming tools 6ystem software utilities, editors, compilers, debuggers are a legitimate part of @36 tools. In addition to these, new and powerful tools can be added. BbAect-oriented programming tools, N( languages, advanced database query systems all fall into this tool category. vi+ Integration and testing tools #esting tools provide a variety of different levels of support for the software testing steps that are applied as part of the software engineering process. 6ome tools provide direct support for the design of test cases and are used in the early stages of testing. Bther tools, such as automatic regression testing and test data generation tools are used during integration and validation testing and can help reduce the amount of effort required for testing. vii+ <rototyping and simulation tools #hese tools span a wide range of tools that include simple screen painters to simulation products for timing and si!ing analysis of real-time embedded systems. 3t their most fundamental, prototyping tools focus on the creation of screens and reports that will enable a user to understand the input and output domain of an information system. viii+ /aintenance tools #hese tools can help to decompose an existing program and provide the engineer with some insight. $owever, the engineer must use intuition, design sense and intelligence to complete the reverse engineering process and I or to re-engineer the application. ix+ 4ramework tools #hese tools provide a framework from which an integrated proAect support environment *I<6 + can be created. In most cases, framework tools actually provide database management and configuration management capabilities along with utilities that enable tools from different vendors to be integrated into the I<6 . Advantages Of +A%E tools 3utomate many manual tasks (enerate system documentation <romote standardi!ation <romote greater consistency & coordination -isadvantage Of +A%E tools @36 tools cannot automatically provide a functional, relevant system It cannot automatically force analysts to use a prescribed methodology or create a methodology when one does not exist @annot radically transform the system analysis and design process

Q9. B) What are str(ct(red 5alkthro(ghs and ho5 are the, carried o(t/
#tr(ct(red Walkthro(ghs : 1. 3 structured walkthrough is a planned review of a system or its software by persons involved in the development effort.

2. #he participants are generally at the same level in the organi!ation: that is , they are analysts or programmer-analysts. #ypically department managers for marketing or manufacturing are not involved in the review even though they may be the eventual recipients of the system. 3. 6ometimes structured walkthroughs are called O<eer 5eviewsJ because the participants are colleagues at the same level in the organi!ation. +ha!acte!istics : 1. #he purpose of walkthroughs is to find areas where improvement can be made in the system or the development process. 2. 3 walkthrough should be viewed by the programmers and analysts as an opportunity to receive assistance, not as an obstacle to be avoided or tolerated. 3. #he review session does not result in the correction of errors or changes in specifications. #hose activities remain the responsibility of the developers. $ence the emphasis is constantly on review, not repair. 4. #he individuals who formulated the design specifications or created the program code are as might be expected, part of the review team. 5. 3 moderator is sometimes chosen to lead the review, although many organi!ations prefer to have the analyst or designer who formulated the specifications or program lead the session, since they have greater familiarity with the item being reviewed. In either case, someone must be responsible for keeping the review focused on the subAect of the meeting. 6. 3 scribe or recorder is also needed to capture the details of the discussion and the ideas that are raised. 6ince the walkthrough leader or the sponsoring programmers or analysts may not be able to Aot down all the points aired by the participants, appointing another individual to take down all the relevant details usually ensures a more complete and obAective record. 7. #he benefits of establishing standards for data names, module determination, and data item si!e and type are recogni!ed by systems managers. #he time to start enforcing these standards is at the design stage. #herefore, they should be emphasi!ed during walkthrough sessions. 8. /aintenance should also be addressed during walkthroughs. nforcing coding standards, modularity, and documentation will ease later maintenance needs. 9. It is becoming increasingly common to find organi!ations that will not accept new software for installation until it has been approved by software maintenance teams. In such an organi!ation, a participant from the quality control or maintenance team should be an active participant in each structured walkthrough.

9D. (i) #he walkthrough team must be large enough to deal with the subAect of the review in a meaning way, but not so large that it cannot accomplish anything. (ii) (enerally no more than P to M persons should be involved , including the individuals who actually developed the product under review, the recorder, and the review leader. 99. a. 3s a general rule, management is not directly involved in structured walkthrough sessions. Its participation could actually Aeopardi!e the intent of the review team from speaking out about problems they see in proAect. b. Because management is often interpreted to mean evaluation. c. /anagers may feel that raising many questions, identifying mistakes or suggesting changes indicates that the individual whose work is under review is incompetentI d. It is best to provide managers with reports summari!ing the review session rather than to have them participate. e. #he most appropriate type of report will communicate that a review of the specific proAect or product was conducted, who attended, and what action the team took. It need not summari!e errors that were found, modifications suggested, or revisions needed. 12. 6tructured reviews rarely exceed MD minutes in length. 13. #he structured walkthrough can be used throughout the systems development process as a constructive and cost-effective management tool, after the detailed investigation *requirements review+, following design *design review+, and during program development *code review and testing review+. 14. #he purpose of walkthroughs is to find areas where improvement can be made in the system or the development process. 15. 3 walkthrough should be viewed by the programmers and analysts as an opportunity to receive assistance, not as an obstacle to be avoided or tolerated. 16. #he review session does not result in the correction of errors or changes in specifications. #hose activities remain the responsibility of the developers. $ence the emphasis is constantly on review, not repair. 17. #he individuals who formulated the design specifications or created the program code are as might be expected, part of the review team. 18. 3 moderator is sometimes chosen to lead the review, although many organi!ations prefer to have the analyst or designer who formulated the specifications or program lead the session, since they have greater familiarity with the item being reviewed. In either case, someone must be responsible for keeping the review focused on the subAect of the meeting.

19. 3 scribe or recorder is also needed to capture the details of the discussion and the ideas that are raised. 6ince the walkthrough leader or the sponsoring programmers or analysts may not be able to Aot down all the points aired by the participants, appointing another individual to take down all the relevant details usually ensures a more complete and obAective record. 20. #he benefits of establishing standards for data names, module determination, and data item si!e and type are recogni!ed by systems managers. #he time to start enforcing these standards is at the design stage. #herefore, they should be emphasi!ed during walkthrough sessions. 21. /aintenance should also be addressed during walkthroughs. nforcing coding standards, modularity, and documentation will ease later maintenance needs. 22. It is becoming increasingly common to find organi!ations that will not accept new software for installation until it has been approved by software maintenance teams. In such an organi!ation, a participant from the quality control or maintenance team should be an active participant in each structured walkthrough. >C. (i) #he walkthrough team must be large enough to deal with the subAect of the review in a meaning way, but not so large that it cannot accomplish anything. (ii) (enerally no more than P to M persons should be involved , including the individuals who actually developed the product under review, the recorder, and the review leader. >N. a. 3s a general rule, management is not directly involved in structured walkthrough sessions. Its participation could actually Aeopardi!e the intent of the review team from speaking out about problems they see in proAect. b. Because management is often interpreted to mean evaluation. c. /anagers may feel that raising many questions, identifying mistakes or suggesting changes indicates that the individual whose work is under review is incompetentI d. It is best to provide managers with reports summari!ing the review session rather than to have them participate. e. #he most appropriate type of report will communicate that a review of the specific proAect or product was conducted, who attended, and what action the team took. It need not summari!e errors that were found, modifications suggested, or revisions needed. 25. 6tructured reviews rarely exceed MD minutes in length. 26. #he structured walkthrough can be used throughout the systems development process as a constructive and cost-effective management tool, after the detailed investigation *requirements review+, following design *design review+, and during program development *code review and testing review+.

Q; ') xplain +ecision Table and +ecision Tree.

+ecision Table :
1ecision tables are a precise yet compact way to model complicated logic. 1ecision tables, like if-then-else and switch-case statements, associate conditions with actions to perform. But, unlike the control structures found in traditional programming languages, decision tables can associate many independent conditions with several actions in an elegant way. 1ecision #ables are useful when complex combinations of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions.

%t!uctu!es Of -ecision Table : 1ecision tables are typically divided into four quadrants, as shown below The #ou! 3uad!ants @onditions 3ctions @ondition alternatives 3ction entries

ach decision corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives. ach action is a procedure or operation to perform, and the entries specify whether *or in what order+ the action is to be performed for the set of condition alternatives the entry corresponds to. /any decision tables include in their condition alternatives the don:t care symbol, a hyphen. "sing don:t cares can simplify decision tables, especially when a given condition has little influence on the actions to be performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed. 3side from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives and action entries are represented. 6ome decision tables use simple trueIfalse values to represent the alternatives to a condition *akin to if-then-else+, other tables may use numbered alternatives *akin to switch-case+, and some tables even use fu!!y logic or probabilistic representations for condition alternatives. In a similar way, action entries can simply represent whether an action is to be performed *check the actions to perform+, or in more advanced decision tables, the sequencing of actions to perform *number the actions to perform+.

Example Of -ecision Table :

#he limited-entry decision table is the simplest to describe. #he condition alternatives are simple boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed. 3 technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. *!inte! T!oubleshoote! Rules <rinter does not print @onditions 3 red light is flashing <rinter is unrecogni!ed @heck the power cable @heck the printer-computer cable 3ctions nsure printer software is installed @heckIreplace ink @heck for paper Aam Q Q Q Q Q Q = = = = = 0 = 0 = Q Q Q Q Q Q Q = 0 0 0 = = 0 = 0 0 0 = 0 0 0

Bf course, this is Aust a simple example *and it does not necessarily correspond to the reality of printer troubleshooting+, but even so, it demonstrates how decision tables can scale to several conditions with many possibilities. Benefits Of -ecision Table : 1ecision tables make it easy to observe that all possible conditions are accounted for. In the example above, every possible combination of the three conditions is given. In decision tables, when conditions are omitted, it is obvious even at a glance that logic is missing. @ompare this to traditional control structures, where it is not easy to notice gaps in program logic with a mere glance --- sometimes it is difficult to follow which conditions correspond to which actionsR Kust as decision tables make it easy to audit control logic, decision tables demand that a programmer think of all possible conditions. 'ith traditional control structures, it is easy to forget about corner cases, especially when the else statement is optional. 6ince logic is so important to programming, decision tables are an excellent tool for designing control logic. In one incredible anecdote, after a failed L man-year attempt to describe program logic for a file maintenance system using flow charts, four people solved the problem using decision tables in Aust four weeks.

+ecision Tree :
In operations research, specifically in decision analysis, a decision tree is a decision support tool that uses a graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. 3 1ecision tree is a predictive model . that is, a mapping from observations about an item to conclusions about its target value. 3 decision tree is used to identify the strategy most likely to reach a goal. 3nother use of trees is as a descriptive means for calculating conditional probabilities. 1ecision #rees are useful when the sequence of conditions and actions is critical or not every condition is relevant to every action. /ore descriptive names for such tree models are classification tree *discrete outcome+ or regression tree *continuous outcome+. In these tree structures, leaves represent classifications and branches represent conAunctions of features that lead to those classifications.

Example Of -ecision T!ee : @onsider the Book 6eller example where the condition are as follows : If order is from book store 3nd if order is for L copies #hen discount is >;S lse *if order is for less then L copies+ 0o discount is allowed lse *if order is from libraries+ If order is for ;D copies or more #hen discount is 9;S lse if order is for >D to NM copies #hen discount is 9DS lse if order is for L to 9M copies #hen discount is ;S lse *order is for less then L copies+ 0o discount is allowed.

#he 1ecision #ree for the above example would be as follows : Brder 8 L copies >;S 1iscount Book 6tore Brder T L copies 0o 1iscount Book Brder Brder 8 ;D copies 9;S 1iscount Brder 8>D && Brder T NM 9DS 1iscount )ibraries Brder 89M && Brder T L ;S 1iscount Brder T L @opies 0o 1iscount

Q; B) What are the re0(irement o) a %ood #,stem 'nal,st/

4 Q<I4 2 $T# !1 ' %!!+ #=#T 2# '$'8=#T:

#,stem 'nal,st :
3 person who conducts a methodical study and evaluation of an activity such as a business to identify its desired obAectives in order to determine procedures by which these obAectives can be gained. #he various skills that a system analyst must posses can be divided into two categories 1) Interpersonal skills 2) #echnical skills Interpersonal skills deal with relationships and the interface of the analyst with people in business. #echnical skills focus on procedures and techniques for operations analysis, systems analysis, and computer science. Interpersonal skills incl(de: 1. Communication : $eIshe must have the ability to articulate and speak the language of the user, a ,flare- for mediation, and a knack for working with virtually all managerial levels in the organi!ation.

2. Understanding: Identifying problems and assessing their ramifications. $aving a group of company goals and obAectives and showing sensitivity to the impact of the system on people at work. 3. Teaching: ducating people in use of computer systems, selling the system to the user and giving support when needed. 4. Selling: 6elling ideas and promoting innovations in problem solving using computers. Technical skills incl(de: 1. Creativity: $elping userJs model ideas into concrete plans and developing candidate systems to match user requirements. &. Problem solving: 5educing problems to their elemental levels for analysis, developing alternative solutions to a given problem, and delineating the pros and cons of candidate systems. '1 Project management: 6cheduling, performing well under time constraints, coordinating team efforts, and managing costs and expenditures. 71 Dynamic interface: Blending technical and non-technical considerations in functional specifications and general design. 5. 6. Questioning attitude and in uiring mind: Hnowing the what, when, why, where, who and how a system works. !no"ledge of the basics of the com#uter and the business function : #he above skills are acquired by a system analyst through hisIher education, experience and personality.

d(cational Backgro(nd !) #,stem 'nal,st :

1. $eIshe must have knowledge of systems theory and organi!ation behavior. 2. 6hould be familiar with the makeup and inner workings of maAor application areas such as financial accounting, personnel administration marketing and sales, operations management, and model building and production control. 3. @ompetence in system tools and methodologies and a practical knowledge of one or more programming and data base languages.

4.

xperience in hardware and software specification which is important for selection.

>ersonal 'ttrib(tes !) #,stem 'nal,st : 1. 3uthority: #he confidence to tell people what to do. <roAect management and to get the team to meet deadlines is the result of this quality. 2. @ommunication 6kills: 3bility to articulate and focus on a problem area for logical solution. 3. @reativity : #rying ones own ideas. 1eveloping candidate systems using unique tools or methods. 4. 5esponsibility: /aking decisions on ones own and accepting the consequences of these decisions. 5. Uaried skills: 1oing different proAects and handling change.