Homework Title / No.

: _________4___________________________________Course Code :
____cap314_____

Course Instructor : ram sirCourse Tutor (if applicable) : _______rohit ohri sir_____

Date of Allotment : ________08/25/2010_____________ Date of submission :

___01/08/2010________________

Student’s Roll No.______rtb902b43_________________ Section No. :

_________tb902________________
Declaration:
I declare that this assignment is my individual work. I have not copied from any other
student’s work or from any other source except where due acknowledgment is made
explicitly in the text, nor has any part been written for me by another person.
Student’s Signature :
_pradeep
kumar____________
Evaluator’s comments:
_____________________________________________________________________
Marks obtained : ___________ out of ______________________
Content of Homework should start from this page only:

Q1. Elaborate Alpha testing and beta testing?

Ans.1. Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test.[1] Software testing also
provides an objective, independent view of the software to allow the business to
appreciate and understand the risks of software implementation. Test techniques include,
but are not limited to, the process of executing a program or application with the intent of
finding software bugs (errors or other defects).
Software testing can also be stated as the process of validating and verifying that a
software program/application/product:
meets the business and technical requirements that guided its design and development;
works as expected; and
can be implemented with the same characteristics.

Alpha testing
Alpha testing is simulated or actual operational testing by potential users/customers or an
independent test team at the developers' site. Alpha testing is often employed for off-the-
shelf software as a form of internal acceptance testing, before the software goes to beta
testing.
Beta testing
Beta testing comes after alpha testing and can be considered a form of external user
acceptance testing. Versions of the software, known as beta versions, are released to a
limited audience outside of the programming team. The software is released to groups of
people so that further testing can ensure the product has few faults or bugs. Sometimes,
beta versions are made available to the open public to increase the feedback field to a
maximal number of future users
Q2. Explain Basis Path?
Ans.2. Basis path testing is a hybrid between path testing and branch testing:
Path Testing: Testing designed to execute all or selected paths
through a computer program

Branch Testing: Testing designed to execute each outcome of

each decision point in a computer program

Basis Path Testing: Testing that fulfills the requirements of

branch testing & also tests all of the independent paths that
could be used to construct any arbitrary path through the
computer program

A path through the software is a sequence of instructions or statements that starts at an entry
junction or decision and ends at another or possibly the same junction decision or exit. A path
may go through several junctions processes or decisions one or more times.

Q3. Elaborate Unit testing and System Testing using example?

Ans.3 unit testing is a method by which individual units of source code are tested to
determine if they are fit for use. A unit is the smallest testable part of an application. In
procedural programming a unit may be an individual function or procedure. In object-
oriented programming a unit is usually a method.[citation needed] Unit tests are created
by programmers or occasionally by white box testers during the development process.
Ideally, each test case is independent from the others: substitutes like method stubs, mock
objects,fakes and test harnesses can be used to assist testing a module in isolation. Unit
tests are typically written and run by software developers to ensure that code meets its
design and behaves as intended. Its implementation can vary from being very manual
(pencil and paper) to being formalized as part of build automation.

Part- B

Q4. Discuss Integration Testing and Validation Testing. Give Examples?

Ans.4. Integration testing: -
This test begins after two or more programs or application components have been successfully
unit tested. The development team to validate the technical quality or design of the
application conducts it. It is the first level of testing which formally integrates a set of
programs that communicate among themselves via messages or files (a client and its server(s) a
string of batch programs or a set of on-line modules within a dialog or conversation.)

Validation - validation:Means are we doing things right.i.e

we have to
check whether we have developed a software as per the
client requirement. Are we building a right Product?'it
is a
Dynamic testing method. chekcing whether product designed
meeting
client inputs and working as per the requirement It may be
validated by client or by practical validation on
simulation.

Q5. Elaborate use of Identifying Elements of Object Model?

Ans.5. A object model in software engineering is an abstract model, that documents and
organizes the business data for communication between team members and is used as a
plan for developing applications, specifically how data is stored and accessed.

According to Hoberman (2009), "A object model is a wayfinding tool for both business
and IT professionals, which uses a set of symbols and text to precisely explain a subset of
real information to improve communication within the organization and thereby lead to a
more flexible and stable application environment."

A object model explicitly determines the structure of data or structured data. Typical
applications of data models includedatabase models, design of information systems, and
enabling exchange of data. Usually data models are specified in a data modeling
language.

Communication and precision are the two key benefits that make a data model important
to applications that use and exchange data. A object model is the medium which project
team members from different backgrounds and with different levels of experience can
communicate with one another. Precision means that the terms and rules on a data model
can be interpreted only one way and are not ambiguous

Q6. Explain how will you Manage Object Oriented Software Projects?

Ans.6. The popularity and sophistication of object-oriented (OO) technology has grown
dramatically over the last few years. Several organizations sponsored early attempts to use OO
technology that demonstrated its potential for delivering high-quality software. Then, full-scale
projects were developed that proved the promise. Now, as an established technology, companies
are using object-oriented methods to implement a variety of projects, and many more companies
have decided they will also adopt object orientation. While information abounds on software
development methods and object-oriented programming, there is still little guidance for
organizations that already develop software to make the transition to object orientation. This book
is designed to fill that gap. We present a guide that takes object orientation out of the textbooks
and makes it available for software teams to its power in the real world, on real projects having
real people, budgets, and budget deadlines.
The central claim of this book is that OO technology has become not just practical, it has become
the only effective way to deal with the complexity and reliability demanded of current software.
But formidable obstacles stand in the way of moving to object technology. Transitioning to object
technology is considerably more complex than just moving to a new design technique or to a new
programming language. The move requires a radically different model for software development
from the ones organizations currently use, and it further requires a simultaneous adoption of
software engineering techniques. This transition requires, in turn, a change of culture throughout
the organization and the allocation of significant resources. Because the change is so
widespread, the risks associated with the transition are equally large. By providing a transition
framework for existing organizations, we intend to help organizations minimize the risks, costs,
and schedule impacts.

We maintain a relentlessly practical viewpoint about software development. We avoid the

common ploy of presenting ideal situations in which project goals are clearly understood at the
project's outset and remain constant throughout the development, where time, money, and tools
are unstintingly available, and where staffing is never a problem. Moreover, common
presentations usually ignore some of the other challenges of transition, such as supporting the
existing system, integrating with legacy systems, and encountering resistance to change. In our
experience, the real-world project lacks almost all the attributes the ideal project assumes. Our
approach, then, is to identify challenges in product development, especially those encountered in
a transition to object technology, and to recommend ways to minimize the impacts of these
challenges. In some cases, minimizing long-term costs implies significant up-front costs. In these
cases, we describe how to assure that the costs aren't wasted. One of the results of our approach
is that we make some radical claims.

First, software is difficult to develop. Reading and following the advice in this or any other book
will not make software development easy or entirely predictable. As Fred Brooks puts it, there is
"no silver bullet" to kill the monster of software development. But looking at software today, it is
more capable and reliable than the software of even five years ago. It shows that making
increasingly good software is possible even if it isn't easy. What we describe is how to make
software development tractable and the output of development, as well as the development team,
more adaptable.

Second, making the transition to object-oriented software engineering will take time, money,
tools, and training. There is no shortcut to transform an organization overnight, and there is no
way to make it inexpensive. There are, however, quite a few ways to make the transition slower,
more expensive, and less successful. Our intent is to identify those ways and to avoid them.

Third, there is no ultimate development method. Every project has different needs, and
development methodologies must be tailored to those needs. A corollary to this assertion is that
there is no ultimate object-oriented technique. Every object-oriented technique has shortcomings
and hidden costs that make it a poor match for some projects. By identifying the basic parameters
of your project and by using our recommendations, you should be able to choose an object-
oriented development method that will suit your needs without wasting time and money on an
inappropriate technique.

The transition framework this book describes is based on real-world experience and discusses
the areas of culture change, object-oriented method selection, development environments,
staffing, training, tracking and controlling object technology projects, and process documentation.
We also cover planning, cost estimation, object-oriented software metrics, and documentation.
Within this framework, we explain why moving to object technology is vital and why it is a
challenging transition. For each section, we detail how to recognize the challenges and how to
deal with them in the most effective way. Each chapter also gives a set of tips and practical
advice for making the change.
This is not a how-to book about object-oriented programming. It is a book about the technical,
social, and management issues involved in running large software projects, and it is specifically
designed to help organizations effectively apply object-oriented technology in the real world. We
present guidelines for such management issues as project and personnel selection, cost
estimation, and project tracking. Although much of the information we provide is applicable to any
software organization, we pay special attention to the way object technology affects these areas
and the special needs of an organization in transition. We analyze technical issues such as
process documentation, reuse criteria, inspection methods, and the integration of legacy systems.
We give tips on avoiding hidden costs, technical blind alleys, and time sinks. We augment these
warnings with positive advice on best practices and effective approaches.