INTRODUCTION

Software Development Life Cycle (SDLC)

A software development methodology is a framework that is used to structure, plan,

and control the process of developing an information system - this includes the pre-
definition of specific deliverables and artifacts that are created and completed by a
project team to develop or maintain an application. A wide variety of such
frameworks have evolved over the years, each with its own recognized strengths and
weaknesses. One software development methodology framework is not necessarily
suitable for use by all projects. Each of the available methodology frameworks are
best suited to specific kinds of projects, based on various technical, organizational,
project and team considerations.

1. Software Development Methodology

Every software development methodology framework acts as a basis for applying specific
approaches to develop and maintain software. There are a number of software development
approaches that have been used since the origin of information technology. These software
development approaches are:-

1. Waterfall Approach: linear framework type.

2. Prototyping Approach : iterative framework type
3. Incremental Approach: combination of linear and iterative framework type
4. Spiral Approach : combination of linear and iterative framework type
5. Rapid Application Development (RAD) Approach: Iterative Framework Type
 Fig 1.0

1.1 Waterfall Approach

The Waterfall model is a sequential development approach, in which development is seen as
flowing steadily downwards (like a waterfall) through the phases of requirements analysis,
design, implementation, testing (validation), integration, and maintenance. The first formal
description of the waterfall approach is often cited to be an article published by Winston W.
Royce in 1970 although Royce did not use the term "waterfall" in this article.

Basic principles of the waterfall approach are:

 Project is divided into sequential phases, with some overlap and splash back acceptable
between phases.
 Emphasis is on planning, time schedules, target dates, budgets and implementation of an
entire system at one time.
 Tight control is maintained over the life of the project through the use of extensive
written documentation, as well as through formal reviews and approval/signoff by the user
and information technology management occurring at the end of most phases before
beginning the next phase.
 1.2 Prototyping Approach
Software prototyping, is the development approach of activities during software development the
creation of prototypes, i.e., incomplete versions of the software program being developed.

Basic principles of the Prototyping Approach are:

 Not a standalone, complete development methodology approach, but rather an approach

to handling selected portions of a larger, more traditional development methodology (i.e.
Incremental, Spiral, or Rapid Application Development (RAD)) approaches.
 Attempts to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
 User is involved throughout the development process, which increases the likelihood of
user acceptance of the final implementation.
 Small-scale mock-ups of the system are developed following an iterative modification
process until the prototype evolves to meet the users’ requirements.
 While most prototypes are developed with the expectation that they will be discarded, it
is possible in some cases to evolve from prototype to working system.
 A basic understanding of the fundamental business problem is necessary to avoid solving
the wrong problem.

1.3 Incremental Approach

Various methods are acceptable for combining linear and iterative systems development
methodology approaches, with the primary objective of each being to reduce inherent
project risk by breaking a project into smaller segments and providing more ease-of-
change during the development process.
Basic principles of the incremental development approach are:

 A series of mini-Waterfalls are performed, where all phases of the Waterfall development
approach are completed for a small part of the systems, before proceeding to the next
incremental, or
 Overall requirements are defined before proceeding to evolutionary, mini-Waterfall
development approaches of individual increments of the system, or
  The initial software concept, requirements analysis, and design of architecture and system
core are defined using the Waterfall approach, followed by iterative Prototyping approach,
which culminates in installation of the final prototype (i.e., working system).

Spiral Approach

The spiral model approach is a software development process combining elements of

both design and prototyping-in-stages, in an effort to combine advantages of
top concepts.
Basic principles:

 Focus is on risk assessment and on minimizing project risk by breaking a project into
smaller segments and providing more ease-of-change during the development process, as
well as providing the opportunity to evaluate risks and weigh consideration of project
continuation throughout the life cycle.
 "Each cycle involves a progression through the same sequence of steps, for each portion
of the product and for each of its levels of elaboration, from an overall concept-of-operation
document down to the coding of each individual program."
 Each trip around the spiral approach traverses four basic quadrants: (1) determine
objectives, alternatives, and constraints of the iteration; (2) Evaluate alternatives; Identify
and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next
iteration.

Fig 1.1
  Begin each cycle with an identification of stakeholders and their win conditions, and end
each cycle with review and commitment.

Rapid Application Development (RAD)

Rapid Application Development (RAD) is a software development methodology approach,

which involves iterative development and the construction of prototypes. Rapid application
development is a term originally used to describe a software development process introduced
by James Martin in 1991.

Basic principles:

 Key objective is for fast development and delivery of a high quality system at a relatively
low investment cost.
 Attempts to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
 Aims to produce high quality systems quickly, primarily through the use of iterative
Prototyping (at any stage of development), active user involvement, and computerized
development tools. These tools may include Graphical User Interface (GUI)
builders, Computer Aided Software Engineering (CASE) tools, Database Management
Systems (DBMS), fourth-generation programming languages, code generators, and object-
oriented techniques.
 Key emphasis is on fulfilling the business need, while technological or engineering
excellence is of lesser importance.
 Project control involves prioritizing development and defining delivery deadlines or
“time boxes”. If the project starts to slip, emphasis is on reducing requirements to fit the time
box, not in increasing the deadline.
 Generally includes Joint Application Development (JAD), where users are intensely
involved in system design, either through consensus building in structured workshops, or
through electronically facilitated interaction.
 Active user involvement is imperative.
 Iteratively produces production software, as opposed to a throwaway prototype.
 Produces documentation necessary to facilitate future development and maintenance.
 Standard systems analysis and design techniques can be fitted into this framework.

2. Why we are using the Waterfall Model?

Waterfall model in software engineering is basically a development approach which follows

a 'top down' mechanism. The development process goes through several phases to meet the
customer's specifications and requirements. One distinguishing feature of waterfall model
that sets it apart from other software development models is that, in this method there is no
simultaneous execution of two phases. The second phase begins only when the preceding
phase has been completely implemented. This approach is very simple to implement and
there is transparency at every stage. Review meetings are conducted at the end of every stage
to verify whether the development process is on track and meets the customer requirements.
Systematic documentation is done at every phase of waterfall model. More on waterfall
model vs. agile.
WATERFALLMODEL.

Fig 2.0
2.1 Waterfall Model Phases
Given below are the various phases of waterfall model. Although, the phase name may
differ for every software organization, the basic implementation steps remain the same.
2.2 Requirement Analysis and Software Definition
This is the first phase of waterfall model which includes a meeting with the customer to
understand his requirements. This is the most crucial phase as any misinterpretation at
this stage may give rise to validation issues later. The software definition must be
detailed and accurate with no ambiguities. It is very important to understand the customer
requirements and expectations so that the end product meets his specifications.

2.3 System Design

The customer requirements are broken down into logical modules for the ease of
implementation. Hardware and software requirements for every module are identified and
designed accordingly. Also the inter relation between the various logical modules is
established at this stage. Algorithms and diagrams defining the scope and objective of
each logical model are developed. In short, this phase lays a fundamental for actual
programming and implementation.

2.4 System Implementation

This is the software process in which actual coding takes place. A software program is written
based upon the algorithm designed in the system design phase. A piece of code is written for
every module and checked for the output.

2.5 System testing

The programmatically implemented software module is tested for the correct output. Bugs, errors
are removed at this stage. In the process of software testing, a series of tests and test cases are
performed to check the module for bugs, faults and other errors. Erroneous codes are rewritten
and tested again until desired output is achieved. More on waterfall model in testing.
 2.6 System Deployment and Maintenance
This is the final phase of the waterfall model, in which the completed software product is handed
over to the client after alpha, beta testing. After the software has been deployed on the client site,
it is the duty of the software development team to undertake routine maintenance activities by
visiting the client site. If the customer suggests changes or enhancements the software process
has to be followed all over again right from the first phase i.e requirement analysis. This is the
biggest shortcoming of the waterfall model.

3. SYSTEM DESIGN

3.1Data Flow Diagrams

Physical Context diagram for online photo shopping

3.2 Level 0 DFD

 Fig 3.0

3.3Level 1 DFD
 UserFig. 3.1

Customer
(Faculty/stude
3.4 Extended Entity Relationship Diagram
 Fig. 3.2

4. Expected output
 This Website is designed in such a way that every user is allowed to download
his/her desired image separately with more security and without any fear of losing any data.
Since the system will be internet so it enables the user to check new uploads from any
geographical position. The users are only given access to the interface not to the database. Hence
the data is secure and safe.

5. Database Design

The database was designed using MySQL.

Data source name: image1

Table descriptions:

5.1 I_user
Objective : Contains all the details of the user.

Name Type
----------------------------------------- -------- ----------------
fname Text
lname Text
id Text
DOB Text
Phone_no Text
address Text
password Text
e-mail Text
contact Text
gender Text
isadmin Text

5.2 Image
Objective : Contains all the details of the Image.
Name Type
----------------------------------------- -------- -------------
i_p_id Int
p_image Blob

5.3 Cart
Objective: Contains all the details of the image added to the user’s cart.

Name Type
----------------------------------------- -------- -------------
C_User_id Text
C_P_id Text

5.4 Payment
Objective: Contains payment details of the buyer.

Name Type
----------------------------------------- -------- -------------
C_p_idText
c_status Text
c_transaction_id Text
c_id Text
c_account Text
c_bankname Text
c_date Date
c_time Time

5.5 Status
Objective: Contains status of the image currently.

Name Type
----------------------------------------- -------- -------------
Status Text
s_transaction_id Text

6. SNAPSHOTS
Welcome to Art Gallery

About us
Help
Terms & conditions
Sign up

7. Testing
 Testing is done to ensure that an adequate level of review and testing has been applied to
different stages viz. Unit/Module/System/Integration test so that each gives the desired,
consistent output as per the functionality described in Design Document.

7.1Testing Approaches

There are two basic types of test cases:

• Black Box approaches

• White Box approaches
Black box test cases derive from the external specifications and requirements of the
system. It includes random testing at boundary values and error guessing where a list of error
situations is created.

In white box approach the test cases at the module level are derived from the internal
structure of the program. It may execute all statements of branches in the program to check on
how the system is implemented. Even efforts to test on all the branches are inadequate they do
not test many of the paths in the program. Path testing provides more thorough check, but the
number paths in the loop make exhaustive testing impossible.

7.2 System Testing

When all units are individually tested for its relevant input and output conditions, then it
is necessary to integrate all together to check for its correctness. There are number of approaches
to test the system. They are explained below:

Bottom up testing: Each module at the lowest level of the system is tested individually. The
next modules to be tested are those that include the previously tested modules. This is followed
repeatedly till all modules are included in the testing.
Top down testing: It is the reverse of bottom up approach. The top level one controlling module
is tested. Then all modules individually tested. Modules are combined and tested as a longer unit.
This approach is reapplied and tested until all the modules are incorporated.

Big bang testing: All individually tested modules are combined together and tested for its
required performance. Like in hardware, if this strategy works out then it is called big bang
testing.

Sandwich testing: This is the combination of both top down testing and bottom up testing. The
system is viewed as three layers and middle layer is considered as target layer in the system. The
top down approach is used for top layer and bottom up testing for the lowest layer. This testing
converges on the target layer (middle one) selected on the basis of the system characteristics.

White Box Tests Black Box Tests

Primarily used for unit testing. Primarily used for integrated testing.

Can be written in the design phase only if Can be written based on the requirements,
documents are quite detailed. and design documents usually for
functional tests.

Used to examine how the results were Used to examine whether a procedure
achieved at the code Path Level. produces expected results without concern
for the underlying code.

Table 4.1 White Box Vs Black Box tests

Regression Testing: Regression Testing is the most common technique for evaluating test
results. In regression testing, established Software tests are run (white box or black box) and the
results compared with the successful results from the previous test runs. If the new results don’t
conform to previously verified results, the software being tested may contain errors. If the errors
do exist, the software is said to have “regressed”. Thus, regression testing ensures that a program
runs consistently and that new features do not affect the correct execution of previously tested
features.

A typical sequence of steps used in regression testing is given below:

Step 1: Write test Scripts to test the Software.

Step 2: Organize the tests and create a mechanism that lets the team readily access the tests as
needed.

Step 3: Run the tests.

Step 4: Examine the test results.

4.1 Compare the results of each test to the expected and actual results.

4.2 For incorrect test output, revise the program code to correct the problem.

4.3 Repeat Step 3 and 4 until the test output is correct.

4.4 Save the correct output as the validated test results.

Step 5: Repeat Step 3 and 4 whenever the program is modified.

5.1 If the current and validated test results match, the program being tested is working as
expected

5.2 If unexpected changes are found in the test results, the program being tested may
contain errors. Correct the program and rerun the tests whose results did not match.
Repeat this cycle until all results are valid. For future test runs, use the validated test
results as references against which to compare the test results.

7.3Testing and Design

The development team must plan for testing when they create an application’s design.
The team should recognize that the product eventually will be tested for validity and consistency.
The verification process uses standard testing procedures (for examples regression testing) that
the team can plan for.
 The design work generally reveals potential problems such as running out of disk space
or a possible failure of the system services. If such problems cannot be “designed out” of the
system, having a record of them can be valuable when the team prepares its tests.

The team writes the set of functional validation tests during preliminary design to ensure
that the tests measure the functions the software is to perform. If the team writes the tests after
the code is written, their knowledge of the code may affect the way they write the tests. This
approach diminishes the objectivity of the test and the value of the results.

Functional tests are usually black box tests and can be written based on the requirements,
specifications, and design documents. White box tests can be written at the design phase only if
the design documents are quite detailed.

7.4Performance Testing

Performance testing helps ensure that a product performs its functions at the required
speed. Planning for performance testing starts at the beginning of the project when product goals
and requirements are defined. Performance testing is a part of the product’s initial engineering
plan.

The development team can approach performance testing is one of the three ways:

1. The team can design for performance. Techniques such as modeling and
prototyping help to assess the application’s performance. Techniques for
validating designs produce an application design that can enhance
performance.
2. The team can test performance during development. This approach
entails testing performance at the unit level. The team writes tests
and establishes performance benchmarks for each unit tested. The
drawback to this approach is the significant time and effort required.
3. The development team can test the performance of the finished product. This
approach also requires tests and benchmarks. However, the team creates the
 tests and benchmarks only for the full application. For this reasons, it is more
practical than testing during development.
Assuming that the team selects the third approach, the developers must first create the
tests and benchmarks. This step is difficult because it entails translating information from the
requirements and specification stages into tests and benchmarks that are specific to individual
products. Without meaningful benchmarks, performance testing serves little purpose.

Depending upon the project and purchaser’s requirements, appropriate testing method is
selected. All testing strategies are having advantages as well as disadvantages.

7.5 Testing with JUnit

The JUnit testing framework is now the de facto standard unit testing API for Java

development. Ant integrates with JUnit to allow executing test suites as part of the

build process, capturing their output, and generating rich color enhanced reports. In

this chapter, we cover in more detail what testing can give us beyond knowing that

our code is working well within some boundaries, then we cover the primary alternative

to JUnit testing and why it is insufficient. The bulk remainder of the chapter, the

largest part, is devoted to Ant’s JUnit integration: how to use it, its limitations, and

the techniques to make seamless integrated testing part of every build.

7.6 JAVA MAIN() TESTING

A common way that many Java developers exercise objects is to create a main method

that instantiates an instance of the class, and performs a series of checks to ensure that
the object is behaving as desired. For example, in our HtmlDocument class we define

a main method as

public static void main(String args[]) throws Exception {

HtmlDocument doc = new HtmlDocument(new File(args[0]));

System.out.println("Title = " + doc.getTitle());

System.out.println("Body = " + doc.getBodyText());

We are then able to run the program from the command-line, with the proper classpath

set:

java org.example.antbook.ant.lucene.HtmlDocument

test/org/example/antbook/ant/lucene/test.html

Using Ant as a Java program launcher, we can run it with the <java> task:

<java classname="org.example.antbook.ant.lucene.HtmlDocument">

<arg value="test/org/example/antbook/ant/lucene/test.html"/>

<classpath refid="test.classpath"/>

</java>

Writing main method checks is convenient because all Java IDEs provide the ability

to compile and run the class in the current buffer, and certainly have their place for

exercising an object’s capability. There are, however, some issues with this approach

that make it ineffective as a comprehensive test framework:

• There is no explicit concept of a test passing or failing. Typically, the program

outputs messages simply with System.out.println; the user has to look at

this and decide if it is correct.

• main has access to protected and private members and methods. While

you may want to test the inner workings of a class may be desired, many tests

are really about testing an object’s interface to the outside world.

• There is no mechanism to collect results in a structured fashion.

• There is no replicability. After each test run, a person has to examine and interpret

the results.

The JUnit framework addresses these issues, and more.

7.7 Writing a test case

One of the primary XP tenets is that writing and running tests should be easy. Writing

a JUnit test case is intentionally designed to be as easy as possible. For a simple

test case, you follow three simple steps:

1 Create a subclass of junit.framework.TestCase.

2 Provide a constructor, accepting a single String name parameter, which calls

super(name).

3 Implement one or more no-argument void methods prefixed by the word test.

An example is shown in the SimpleTest class code:

package org.example.antbook.junit;

import junit.framework.TestCase;

public class SimpleTest extends TestCase

public SimpleTest (String name) {

super(name);

public void testSomething() {

assertTrue(4 == (2 * 2));

7.8Running a test case

TestRunner classes provided by JUnit are used to execute all tests prefixed by the

word “test.” The two most popular test runners are a text-based one, junit.textui.

TestRunner, and an attractive Swing-based one, junit.swingui.TestRunner.

From the command line, the result of running the text TestRunner is

java junit.textui.TestRunner org.example.antbook.junit.SimpleTest

Time: 0.01

OK (1 tests)

The dot character (.) indicates a test case being run, and in this example only one

exists, testSomething. The Swing TestRunner displays success as green and failure

as red, has a feature to reload classes dynamically so that it can remain open while

code is recompiled, and will pick up the latest test case class each time. For this same

test case, its display appears in figure 4.2.

7.9Asserting desired results

The mechanism by which JUnit determines the success or failure of a test is via assertion

statements. An assert is simply a comparison between an expected value and an

Figure 7.0 JUnit’s Swing TestRunner

actual value. There are variants of the assert methods for each primitive datatype and for

java.lang.String and java.lang.Object, each with the following signatures:

assertEquals(expected, actual)

assertEquals(String message, expected, actual)

7.10 TestCase lifecycle

The lifecycle of a TestCase used by the JUnit framework is as follows:

1 Execute public void setUp().

2 Call a test-prefixed method.

3 Execute public void tearDown().

4 Repeat these steps for each test method.

Any number of test methods can be added to a TestCase, all beginning with the

prefix test. The goal is for each test to be small and simple, and tests will usually require

instantiating objects. In order to create some objects and preconfigure their state

prior to running each individual test method, override the empty TestCase.setUp

method, and store state as member variables to your test case class. Use the

TestCase.tearDown method to close any open connections or in some way reset

state. Our HtmlDocumentTest takes advantage of setUp and tearDown (see later

this chapter) so that all test methods will have implicit access to an HtmlDocument.

NOTE: The setUp and tearDown methods are called before and after every test

method is invoked, preventing one test from affecting the behavior of another.

Tests should never make assumptions about the order in which they

are called.

7.11 Writing a TestSuite

With JUnit’s API, tests can be grouped into a suite by using the TestSuite class.
Grouping tests may be a benefit to let you build several individual test cases for a particular

subsystem and write an all-inclusive TestSuite that runs them all.

A TestSuite also allows specific ordering of tests, which may be important—

although ideally the order of tests should not be relevant as each should be able to

stand alone. Here is an example of a test suite:

public class AllTests extends TestSuite {

static public Test suite() {

TestSuite suite = new TestSuite();

suite.addTestSuite(SimpleTest.class);

return suite;

You don’t need to bother with test suites when running JUnit tests using Ant, because

you can list a group of TestCase classes to run as a batch from the build file itself.

(See section 4.6.2 for discussion of <batchtest>.) However, running a single

TestSuite using the “running a single test case” trick in section 4.7.2 gives you

flexibility in the grouping and granularity of test cases. Remember that a TestCase

is a Test, and a TestSuite is also a Test, so the two can be used interchangeably in most instances.

8. CONCLUSION

The project is titled “Art Gallery (Online photo-shopping)” The main aim of the project is to
provide the user good graphical user interface so that the user easily use it sitting to buy and sell its
images and pay the amount through its credit card and also pay the amount at the time of image delivery.
9. References

Java Complete Reference

By Herbert Schiltdt, Tata Mcgraw-Hill publications

Java 1.4 Documentation

By Sun Microsystems

Pure JSP Java Server Pages

By James Goodwill, Techmedia

Web Programming

By Evan Bayross , BPB publication

http://www.w3schools.com