Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
2020SEG

2020SEG

Ratings: (0)|Views: 13|Likes:
Published by saurabmi2

More info:

Categories:Types, School Work
Published by: saurabmi2 on Apr 09, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

06/16/2009

pdf

text

original

 
SAMPLE TEST PAPER 2 SEG 2020Q11. RISK COMPONENTS AND THEIR MEANING: The risk components are defined in the following manner:
Performance risk 
—the degree of uncertainty that the product will meet itsrequirements and be fit for its intended use.
Cost risk 
—the degree of uncertainty that the project budget will be maintained.
Support risk 
—the degree of uncertainty that the resultant software will be easy tocorrect, adapt, and enhance.
Schedule risk 
—the degree of uncertainty that the project schedule will bemaintained and that the product will be delivered on time.2. PERT:1.Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort.2.Therefore, generalized project scheduling tools and techniques can beapplied with little modification to software projects.
Program evaluation and review technique
(PERT) and
critical path method 
(CPM) are two projectscheduling methods that can be applied to software development.3.Both techniques are driven by information already developed in earlierproject planning activities:• Estimates of effort.• A decomposition of the product function.• The selection of the appropriate process model and task set.• Decomposition of tasks.4.Both PERT and CPM provide quantitative tools that allow the software plannerto(1) determine the
critical path
—the chain of tasks that determines theduration of the project; (2) establish “most likely” time estimates forindividual tasks by applying statistical models; and (3) calculate “boundarytimes” that define a time "window" for a particular task.3. BLACK BOX TEST:1.
Black-box testing,
also called
behavioral testing,
focuses on the functionalrequirements of the software.2.That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for aprogram.3.Black-box testing is not an alternative to white-box techniques. Rather, it is acomplementary approach that is likely to uncover a different class of errorsthan white-box methods.4. Black-box testing attempts to find errors in the following categories:(1) incorrect or missing functions,(2) interface errors,(3) errors in data structures or external data base access,(4) behavior or performance errors, and
 
(5) initialization and termination errors. Unlike white-box testing, which isperformed early in the testing process.By applying black-box techniques, we derive a set of test cases that satisfy thefollowing criteria :(1) test 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 and(2) test 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.*[Diagram in Nirali text book]Q2.1.PHASES OF SOFTWARE PROJECT PLANNING:?2.FACTORS RESPONSIBLE FOR SOFTWARE PROJECT FAILURE:In order to manage a successful software project, we must understand whatcan go wrong (so that problems can be avoided) and how to do it right.
1.
Software people don’t understand their customer’s needs.
2.
 The product scope is poorly defined.
3.
Changes are managed poorly.
4.
 The chosen technology changes.
5.
Business needs change [or are ill-defined].
6.
Deadlines are unrealistic.
7.
Users are resistant.
8.
Sponsorship is lost [or was never properly obtained].
9.
 The project team lacks people with appropriate skills.
10.
Managers [and practitioners] avoid best practices and lessons learned.3. ALPHA AND BETA TESTING:-1.It is virtually impossible for a software developer to foresee how thecustomer will really use a program. Instructions for use may bemisinterpreted; strange combinations of data may be regularly used;output that seemed clear to the tester may be unintelligible to a user inthe field.2.When custom software is built for one customer, a series of 
acceptancetests
are conducted to enable the customer to validate all requirements.3. If software is developed as a product to be used by many customers, it isimpractical to perform formal acceptance tests with each one. Mostsoftware product builders use a process called alpha and beta testing touncover errors that only the end-user seems able to find.4. The
alpha test 
is conducted at the developer's site by a customer. Thesoftware is used in a natural setting with the developer "looking over theshoulder" of the user and recording errors and usage problems. Alphatests are conducted in a controlled environment.5. The
beta test 
is conducted at one or more customer sites by the end-userof the software. Unlike alpha testing, the developer is generally notpresent. Therefore, the beta test is a live" application of the software in anenvironment that cannot be controlled by the developer.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->