CHAPTER-1

INTRODUCTION

1

INTRODUCTION

1. Overview of proposed system

The main purpose of this project is to develop software to computerize all the work that has been done manually by concern customers. Previously all the work likes allotment of the products, keeping the records of all customer and records of all customer transaction. So it is too difficult to maintain all records, generate reports, and fetch information while using manual system.

Problem description

Manual system suffers from great limitations, like wastage, errors due to work, complications in maintaining and analyzing the records. To sort these we have designed a computerized system for, maintaining the record of the customers and also to fetch the information easily and in a convenient way

That will provide different kind of facilities like-

1. The main aim is automation of customer’s record2. To records the various things like name of customer, customer e-mail id,

address, records of his transaction.3. To make the system independent to make the system flexible.4. Records are easy to analyze, sereach , view etc.

Existing system with limitation

The existing system is manual. All the records are kept in the papers & prepared manually. The records kept in registers & files written manually &different types of records are stored in different files.

Limitation existing system:-

1. The existing system is manual so it is very difficult to analyze the records.2. In the manual system it is very difficult to analyze the records.3. Records are not to be maintained for a long time.

2

4. Problem of record losing, inaccuracy are there.5. Reports generation and computerized printouts is also a big problem.6. Searching a particular record take very long time

2. Need of the proposed system:

We can make this software:-

i. For help in keeping the record of customer.ii. For help in make awareness in online purchasing.

iii. For help in reduce the time and money.iv. For easily day-to-day new products updating.

(c)Scope of work

The scope needs to detail the basic background of your company or organization, the aim of the design project, budget goals, completion time frame, audience, design requirements… essentially you need to be able to tell the company what you want and what your website needs to achieve, thus creating the framework in which they can design your site. These principles are common to any project. Would you ever consider building a house, a car or an airplane without detailed plans?

The scope will often require consulting with an experienced designer or project manager to create the document for you. This will greatly ease the overall design and tendering process and allow choosing the right design team to actually build and construct your website.

3

CHAPTER-2

Objectives of Proposed System

4

Objectives of proposed system

Manual system suffers from great limitation like time wastage, errors due to work, complications in maintaining & analyzing the records. To sort these problems we have designed a computerized system for maintaining the record for the records for keeper of the concern organisations.

i. Provide fully computerized purchasing system.ii. Dynamic search engine.

iii. Complete day-to-day stock status.iv. Complete day-to-day registered customer’s report.

5

CHAPTER-   3

Project Categories Tools and

Environment

6

Project categories Tools and environment

Front-end and back-end are terms used to characterize program interfaces and services relative to the initial user of these interfaces and services. (The "user" may be a human being or a program.) A "front-end" application is one that application users interact with directly. A "back-end" application or program serves indirectly in support of the front-end services, usually by being closer to the required resource or having the capability to communicate with the required resource. The back-end application may interact directly with the front-end or, perhaps more typically, is a program called from an intermediate program that mediates front-end and back-end activities.

(a)Front end In front end we have use HTML, CSS, JAVA script, PHP. For creating a website use HTML tag, make webpage more effective and better-looking we have used CSS. For some restriction we have use validation.

Front-end designers basically come up with the user interface for the website. They deal with colors, fonts, images, layout, informational structure and organization, navigation, etc. They use HTML, Flash, CSS, etc.

(b)Back end The backend to a website is pretty much everything the user can't see. Generally, this means the programming that generates pages that the user views, creating the "server-side" content of the site. This could be scripts, directives, databases, and other automated functions the server performs.Back end designers are usually database people, and they design the databases or whatever that is presented through the front end. They might need to know SQL, GNU, or some other corporate-level database like DB2 or Lotus Domino. They deal with order-fulfillment, inventorying, etc. 

7

(c) Hardware and software requirements

Hardware Requirementsi. PROCESSOR CPU

ii. MEMORY (RAM)iii. FLOPPY DRIVEiv. HARD DISKv. MONITER

vi. KEYBOARDvii. MOUSE

viii. WI-FIix. POWERx. PENDRIVE

xi. CDxii. PRINTER

Software requirementsi. OPERATING SYSTEM

ii. NOTEPADiii. INTERNET EXPLORERiv. GOOGLE CHROMEv. WAMP SERVER

vi. PHP READERvii. MYSQL

viii. MS-ACCESSix. HTML

8

CHAPTER-4    

Software Development Life Cycle

9

Software Development Life Cycle

In order to understand what is Software Development Lifecycle (SDLC) let us break these words into two parts: Software Development , and LifeCycle.

Software Development.

Software Development is A PROCESS to create software.At first glance to a developer - this is the coding process. This is when you sit down with the computer and start to write codes that later processed (compiled,linked etc.) become the actual software that is used by the end user. This is might be the case for beginners or novice developer who are working on "garage" project.

In a small one person project its common for developers to go directly into coding and then testing their code. They are using common divide and conquer, then trial and error testing.But for a significant size software development trial and error method will be expensive.This is because large size project normally involved few developers. Any change in any part of the codes might requires other developers to change their code also.

Larger software development also requires better way to communicate, between the developers.The communication is to make sure developers understand what to be developed, when to start the development, when the other part of the software that they dependence to will be developed, when to test these parts together, what is considered pass..etc.etc. Lot of issues to synchronized the developers.

The larger the group, the harder it is to communicate to all the team members.

This can be worst if the team members are not located in the same place - which are common these day. The team that I am part of have people working in 4 different continents in different time zone.

10

To make it easier, a concept of "Lifecycle" is introduced.

Lifecycle

Common concept of lifecycle is communicated to a development team to synchronized all the team members - so that every one knows when are the important milestones.

Milestones are dates when certain important criteria or requirement has to be met.Concept of lifecycle is not exclusive to software development.

For example a human being also has lifecycle. Start from the day a human being is born.

Then s/he grows become baby,teenager,adult, old and died. This lifecycle also can be traced differently based on different view -example if look from education lifecycle (of the same human being) it can start from pre-school,junior high, high school,college undergrad, and graduate.

These phases actually applicable to the final product, or even into the individual component that make up the product. For example if you are creating a chair, then you have components such as the arm rest, legs, cushions, and back rest. Once the "high level" requirements (description, specification - lot of different names of the same thing) is defined the developer of each component should be able to continue on their own to produce the components. Each of the components will go through the same 5 phases lifecycle also.

This concept of "component" developement is that not far off from what is happening in software development. If you have been in the industry long enough I bet you have heard of "component based" development. The idea is to introduce generic requirement on how components can be handled, then as long as a component is developed in conformant to this standard it can be "plugged in" into another software that understand this standard with very little effort.

Even a lot of people say that software development should be the same as other product development -- such as car and building constructions, but experience has proven that this is not true. The normal discipline that is used in building construction does not really work in software development.

From what the expert observation this is because in normal product construction such as a freeway, ideas and creativity are injected to the project only in very

11

specific part of the phase -- early phase. In building construction creativity can come from the architect and also the civil engineers who has to figure out how to build what is envisioned by the architect. This is done in early stage (design) of the development phase. Once it is fixed the implementation, testing and delivery just need to follow the instructions.

In software development on the other hand, the injection of ideas is hard to controlled since its actually needed in every phase. From the high level architecture, down to low level programming, ingenuity and creativity is needed. Most software developmentactually depending on in development discoveries to come up with innovative products. New way of coding, new algorithm, new component can make the difference between on software to the other in term of feature offered,resource usage and performance.

Because of this software development process is normally "less rigid" compare to car or buiding construction. The side effect is that this can also caused two major problems:

SDLC consists of following activities:

1. Planning: The most important parts of software development, requirement gathering or requirement analysis are usually done by the most skilled and experienced software engineers in the organization. After the requirements are gathered from the client, a scope document is created in which the scope of the project is determined and documented.

2. Implementation: The software engineers start writing the code according to the client's requirements.

3. Testing: This is the process of finding defects or bugs in the created software.

4. Documentation: Every step in the project is documented for future reference and for the improvement of the software in the development process. The design documentation may include writing the application programming interface (API).

5. Deployment and Maintenance: The software is deployed after it has been approved for release.

12

6. Maintaining: Software maintenance is done for future reference. Software improvement and new requirements (change requests) can take longer than the time needed to create the initial development of the software.

The actual amount of steps varies according to the person describing them, but they always cover the same steps.

1. Specify the Requirement2. Data Analysis3. Problem Analysis4. Algorithm5. Coding6. Testing7. Maintenance

The first four steps are very important as it represents the logic of the problem, and can be used to test the execution of the algorithm. This checking of the logic eliminates semantic problems, and allows for the utilization of the pseudocode in many languages. You should have test data ready, and develop a trace table; This can be used to check the output of the program when testing.

1. Specify the requirement: This area is where you describe exactly what you are doing as clear as possible. In this statement you will include the data to be used, and what can be assumed. Also, the desired output and its layout.2. Data Analysis: List all the variables needed to solve the problem. Utilizing self-documenting (Descriptive of what they represent) variable names is always preferred. This also includes the data type, scope, and documentation for each variable.3. Problem Analysis: Here you will list each operation necessary to solve the problem at hand. You can also divide the problem into multiple subtasks as needed, and continue until they are specifically stated and easily solved.4. Algorithm: this clarifies how the problem is to be solved. An algorithm is an effective method for solving a problem expressed as a finite sequence of steps. Thealgorithm must be written very clearly, as not to cause misinterpretation, and is normally done in pseudocode.

13

The algorithm should, when applied to the problem, solve it in a finite amount of time.These last three steps allow for the solution to the problem to be entered into a form the computer can work with.5. Coding: The translation of the algorithm from pseudocode into a programming language. Proper mapping of the code to the algorithm, combined with refining of the pseudocode, should lead to an easy translation to any programming language.6. Testing: This step requires the use of the data table built with the algorithm. You will run the program, and verify the output for correctness and proper layout. Also, you will validate the code ensuring you requirements have been met and the problem was solved.7. Maintenance: Updating and testing of the software. Every time the code is updated, it must be tested for correctness.

14

The different phases of software life cycle development are:

Types of Software developing life cycles (SDLC)

1.Waterfall Model :The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

Waterfall model is the earliest SDLC approach that was used for software development .

The waterfall Model illustrates the software development process in a linear sequential flow; hence it is also referred to as a linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete. In waterfall model phases do not overlap.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

15

Following is a diagrammatic representation of different phases of waterfall model.

16

rrgg

sfgreggs

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model phases do not overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are:

Requirements are very well documented, clear and fixed.

Product definition is stable.

Technology is understood and is not dynamic.

There are no ambiguous requirements.

ADVANTAGE

The advantage of waterfall development is that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

DISADVANTAGE

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

17

2.Spiral Model The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model.

Spiral model is a combination of iterative development process model and sequential linear development model i.e. waterfall model with very high emphasis on risk analysis.

It allows for incremental releases of the product, or incremental refinement through each iteration around the spiral.

Spiral Model design

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals.

Identification:This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral the product is deployed in the identified market.

Design:Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals.

Construct or Build:Construct phase refers to production of the actual software product at every spiral. In the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to customer for feedback.

Evaluation and Risk Analysis:Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

18

Following is a diagrammatic representation of spiral model listing the activities in each phase:

Based on the customer evaluation, software development process enters into the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iterations along the spiral continues throughout the life of the software.

Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the natural development process of any product i.e. learning with maturity and also involves minimum risk for the customer as well as the development firms. Following are the typical uses of Spiral model:

When costs there are a budget constraint and risk evaluation is important.

For medium to high-risk projects.

Long-term project commitment because of potential changes to economic priorities as the requirements change with time.

19

Customer is not sure of their requirements which are usually the case.

Requirements are complex and need evaluation to get clarity.

New product line which should be released in phases to get enough customer feedback.

Significant changes are expected in the product during the development cycle.

Spiral Model Pros and Cons

The advantage of spiral lifecycle model is that it allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design.

This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort.

On the other side, it takes very strict management to complete such products and there is a risk of running the spiral in indefinite loop. So the discipline of change and the extent of taking change requests is very important to develop and deploy the product successfully.

20

(a). Recognition of Need:

One must know what the problem is before it can be solved. The basis of candidate system is recognition of need for improving the system. The key question is:

What is the problem?

This recognition of need leads to a preliminary survey or an initial investigation of current system to determine whether an alternative system can solve the problem. If the problem is serious enough, management may have an analyst look at it.

The idea for change may originate in the environment or within the firm. Environment-based ideas originate from customers, vendors, government sources etc. When investigated each of these ideas may lead to a problem definition. Idea for change may also come from within the organization – top management, the user, the analyst. User-originated ideas also prompt initial investigation.

(b). Feasibility study: Depending upon the results of the initial investigation, the survey is expanded to a more detailed feasibility study. A feasibility study is a test of a system proposal according to its workability, impact on the organization, ability to meet user needs and effective use of resources. The key questions are:-

 1.    What are the user’s demonstrable needs and how does a candidate system meet them?

2.      What resources are available for given candidate systems? Is the problem worth solving?

3.      What is the impact of the candidate system on the organization? How well does it is fit within the organization’s master Master Information System plan?

Each of these questions must be answered carefully. All of these questions help to investigate and to evaluate the problem, the cost of each system and final selection of the best system.

21

The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. Consequently, Cost and benefits are estimated with greater accuracy at this stage.The result of the feasibility study is a formal proposal. This is simply a formal document detailing the nature and scope of the proposed solution.

(i)Operational Feasibility:Often, a feasibility study is needed to determine if a project or end result of a project is feasible and beneficial. The world of feasibility studies is not just considering the project as a whole; often you also need an example of an operational feasibility study as part your research.

The Need for Operational Feasibility StudiesOperational feasibility studies are generally utilized to answer the following questions:

Process – How do the end-users feel about a new process that may be implemented?

Evaluation – Whether or not the process within the organization will work but also if it can work.

Implementation – Stakeholder, manager, and end-user tasks. Resistance – Evaluate management, team, and individual resistance and how

that resistance will be handled. In-House Strategies – How will the work environment be affected? How much

will it change? Adapt & Review – Once change resistance is overcome, explain how the new

process will be implemented along with a review process to monitor the process change.

22

Example of an Operational Feasibility StudyIf an operational feasibility study must answer the six items above, how is it used in the real world? A good example might be if a company has determined that it needs to totally redesign the workspace environment.

After analyzing the technical, economic, and scheduling feasibility studies, next would come the operational analysis. In order to determine if the redesign of the workspace environment would work, an example of an operational feasibility study would follow this path based on six elements:

Process – Input and analysis from everyone the new redesign will affect along with a data matrix on ideas and suggestions from the original plans.

Evaluation – Determinations from the process suggestions; will the redesign benefit everyone? Who is left behind? Who feels threatened?

Implementation – Identify resources both inside and out that will work on the redesign. How will the redesign construction interfere with current work?

Resistance – What areas and individuals will be most resistant? Develop a change resistance plan.

Strategies – How will the organization deal with the changed workspace environment? Do new processes or structures need to be reviewed or implemented in order for the redesign to be effective?

Adapt & Review – How much time does the organization need to adapt to the new redesign? How will it be reviewed and monitored? What will happen if through a monitoring process, additional changes must be made?

23

(ii) Economical feasibility: This is one of the most important parts of the report. The economic overview of the area can be organized under following heads:

• General Overview

• Gross Domestic Product

• Investment Indicators

• Inflation

• Population and labor

• Tourism

The “area” in the “economic overview of the area” can be either the city,

or the state or even the country where the project is located. When you are

working on a project located in India (Area = 11,437 SqKm, population =

1.85 million) you should cover the whole country. But when you are doing a

project in Delhi(Area = 603 SqKm, population = 12.5 million), you can

either cover the city or can go for the state Delhi( (Area = 307,713

SqKm, population = 112.4

iii.Technical Feasibility: Technical Feasibility centers on the system such as hardware, software etc, and to what extent it can support the proposed package. It also needs to be ensuring that the requesting hardware for operating the system is available.

iv.Legal Feasibility: Legal feasibility involve in verifying the legal viability of the proposed system.

24

Our website follows the restriction, rule & regulation define by the govt. and this is not involved in any unfair, illegal, and fraud type activity.

c. System Requirement Specifications (SRS)

Introduction

The introduction of the Software Requirements Specification (SRS) provides an overview of the entire SRS with purpose, scope, definitions, acronyms, abbreviations, references and overview of the SRS. The aim of this document is to gather and analyze and give an in-depth insight of the complete Marvel Electronics and Home Entertainment software system by defining the problem statement in detail. Nevertheless, it also concentrates on the capabilities required by stakeholders and their needs while defining high-level product features. The detailed requirements of the Marvel Electronics and Home Entertainment are provided in this document.

Purpose

The purpose of the document is to collect and analyze all assorted ideas that have come up to define the system, its requirements with respect to consumers. Also, we shall predict and sort out how we hope this product will be used in order to gain a better understanding of the project, outline concepts that may be developed later, and document ideas that are being considered, but may be discarded as the product develops.

In short, the purpose of this SRS document is to provide a detailed overview of our software product, its parameters and goals. This document describes the project's target audience and its user interface, hardware and software requirements. It defines how our client, team and audience see the product and its functionality. Nonetheless, it helps any designer and developer to assist in software delivery lifecycle (SDLC) processes.

25

Scope

Primarily, the scope pertains to the Newly launched car product features for making JIKUS AUTOMOBILE project live. It focuses on the company, the stakeholders and applications, which allow for online sales, distribution and marketing of electronics.

This SRS is also aimed at specifying requirements of software to be developed but it can also be applied to assist in the selection of in-house and commercial software products. The standard can be used to create software requirements specifications directly or can be used as a model for defining a organization or project specific standard. It does not identify any specific method, nomenclature or tool for preparing an SRS.

Definitions, Acronyms, and Abbreviations

Configuration

It means a product which is available / Selected from a catalogue can be customized.

FAQ Frequently Asked QuestionsCRM Customer Relationship ManagementRAID 5 Redundant Array of Inexpensive Disk/Drives

26

Overview

The remaining sections of this document provide a general description, including characteristics of the users of this project, the product's hardware, and the functional and data requirements of the product.  General description of the project is discussed in section 2 of this document.  Section 3 gives the functional requirements, data requirements and constraints and assumptions made while designing the E-Store.  It also gives the user viewpoint of product.  Section 3 also gives the specific requirements of the product.  Section 3 also discusses the external interface requirements and gives detailed description of functional requirements. Section 4 is for supporting information.

Overall Description

This document contains the problem statement that the current system is facing which is hampering the growth opportunities of the company. It further contains a list of the stakeholders and users of the proposed solution. It also illustrates the needs and wants of the stakeholders that were identified in the brainstorming exercise as part of the requirements workshop. It further lists and briefly describes the major features and a brief description of each of the proposed system.

The following SRS contains the detail product perspective from different stakeholders. It provides the detail product functions of E-Store with user characteristics permitted constraints, assumptions and dependencies and requirements subsets.

27

Specific Requirements

The specific requirements are –

Functionality

Introduction –

This subsection contains the requirements for the e-store. These requirements are organized by the features discussed in the vision document. Features from vision documents are then refined into use case diagrams and to sequence diagram to best capture the functional requirements of the system. All these functional requirements can be traced using tractability matrix.

Sell Configured to Ordered Products.

The system shall display all the products that can be configured. The system shall allow user to select the product to configure. The system shall display all the available components of the product to

configure The system shall enable user to add one or more component to the

configuration. The system shall notify the user about any conflict in the current

configuration. The system shall allow user to update the configuration to resolve conflict in

the current configuration. The system shall allow user to confirm the completion of current

configuration

Provide comprehensive product details.

The system shall display detailed information of the selected products. The system shall provide browsing options to see product details.

28

Detailed product Categorizations

The system shall display detailed product categorization to the user.

Provide Search facility.

The system shall enable user to enter the search text on the screen.

The system shall enable user to select multiple options on the screen to search.

The system shall display all the matching products based on the search

The system shall display only 10 matching result on the current screen.

The system shall enable user to navigate between the search results.

The system shall notify the user when no matching product is found on the search.

Maintain customer profile.

The system shall allow user to create profile and set his credential.

The system shall authenticate user credentials to view the profile.

The system shall allow user to update the profile information.

Provide personalized profile

. The system shall display both the active and completed order history in the

customer profile.

The system shall allow user to select the order from the order history.

The system shall display the detailed information about the selected order.

29

The system shall display the most frequently searched items by the user in the profile.

The system shall allow user to register for newsletters and surveys in the profile.

Provide Customer Support.

The system shall provide online help, FAQ’s customer support, and sitemap options for customer support.

The system shall allow user to select the support type he wants.

The system shall allow user to enter the customer and product information for the support.

The system shall display the customer support contact numbers on the screen.

The system shall allow user to enter the contact number for support personnel to call.

The system shall display the online help upon request.

The system shall display the FAQ’s upon request.

Email confirmation.

The system shall maintain customer email information as a required part of customer profile.

The system shall send an order confirmation to the user through email.

30

Detailed invoice for customer.

The system shall display detailed invoice for current order once it is confirmed.

The system shall optionally allow user to print the invoice.

Provide shopping cart facility.

The system shall provide shopping cart during online purchase.

The system shall allow user to add/remove products in the shopping cart.

Provide multiple shipping methods.

The system shall display different shipping options provided by shipping department.

The system shall enable user to select the shipping method during payment process.

The system shall display the shipping charges.

The system shall display tentative duration for shipping.

Online tracking of shipments

The system shall allow user to enter the order information for tracking.

The system shall display the current tracking information about the order.

31

Provide online Tax Calculations

The system shall calculate tax for the order.

The system shall display tax information for the order.

Allow multiple payment methods.

. The system shall display available payment methods for payment.

The system shall allow user to select the payment method for order.

Allow online change or cancellation of order.

The system shall display the orders that are eligible to change.

The system shall allow user to select the order to be changed.

The system shall allow user to cancel the order

The system shall allow user to change shipping, payment method.

The system shall notify the user about any changes made to the order.

Allow Online Product reviews and ratings

The system shall display the reviews and ratings of each product, when it is selected.

The system shall enable the user to enter their reviews and ratings.

32

Offer financing options.

The system shall display all the available financing options.

The system shall allow user to select the financing option.

The system shall notify the use about the financing request.

Provide detailed sitemap.

The system shall allow user to view detailed sitemap.

Offer online promotions and rewards.

The system shall display all the available promotions to the user.

The system shall allow user to select available promotion.

Online Purchase of products.

The system shall allow user to confirm the purchase.

The system shall enable user to enter the payment information.

Usability

Graphical User Interface

The system shall provide a uniform look and feel between all the web pages.

The system shall provide a digital image for each product in the product catalog.

The system shall provide use of icons and toolbars.

33

Accessibility

The system shall provide handicap access.

The system shall provide multi language support.

Performance

The product shall be based on web and has to be run from a web server.

The product shall take initial load time depending on internet connection strength which also depends on the media from which the product is run.

The performance shall depend upon hardware components of the client/customer.

Security

Data Transfer

The system shall use secure sockets in all transactions that include any confidential customer information.

The system shall automatically log out all customers after a period of inactivity.

The system shall confirm all transactions with the customer’s web browser.

The system shall not leave any cookies on the customer’s computer containing the user’s password.

The system shall not leave any cookies on the customer’s computer containing any of the user’s confidential information.

Data Storage

34

The customer’s web browser shall never display a customer’s password. It shall always be echoed with special characters representing typed characters.

The customer’s web browser shall never display a customer’s credit card number after retrieving from the database. It shall always be shown with just the last 4 digits of the credit card number.

The system’s back-end servers shall never display a customer’s password. The customer’s password may be reset but never shown.

The system’s back-end servers shall only be accessible to authenticated administrators.

The system’s back-end databases shall be encrypted.

Supportability

Configuration Management Tool

The source code developed for this system shall be maintained in configuration management tool.

Design Constraints

Standard Development Tools

The system shall be built using a standard web page development tool that conforms to either IBM’s CUA standards or Microsoft’s GUI standards.

Web Based Product

There are no memory requirements

35

The computers must be equipped with web browsers such as Internet

explorer.

The product must be stored in such a way that allows the client easy access

to it.

Response time for loading the product should take no longer than five

minutes.

A general knowledge of basic computer skills is required to use the product

On-line User Documentation and Help System Requirements

As the product is E-store, On-line help system becomes a critical component of the system which shall provide –

o It shall provide specific guidelines to a user for using the E-Store system and within the system.

o To implement online user help, link and search fields shall be provided.

Interfaces

There are many types of interfaces as such supported by the E-Store software system namely; User Interface, Software Interface and Hardware Interface.

The protocol used shall be HTTP.

The Port number used will be 80.

There shall be logical address of the system in IPv4 format.

36

User Interfaces

The user interface for the software shall be compatible to any browser such as Internet Explorer, Mozilla or Netscape Navigator by which user can access to the system.

The user interface shall be implemented using any tool or software package like Java Applet, MS Front Page, EJB etc.

Hardware Interfaces

Since the application must run over the internet, all the hardware shall require to connect internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN, Ethernet Cross-Cable.

Software Interfaces

1. The e-store system shall communicate with the Configurator to identify all the available components to configure the product.

2. The e-store shall communicate with the content manager to get the product specifications, offerings and promotions.

3. The e-store system shall communicate with billPay system to identify available payment methods , validate the payments and process payment.

4. The e-store system shall communicate to credit management system for handling financing options.

5. The e-store system shall communicate with CRM system to provide support.

6. The e-store system shall communicate with Sales system for order management.

7. The e-store system shall communicate with shipping system for tracking orders and updating of shipping methods.

8. The e-store system shall communicate with external Tax system to calculate tax.

9. The e-store system shall communicate with export regulation system to validate export regulations.

10. The system shall be VeriSign like software which shall allow the users to

37

complete secured transaction. This usually shall be the third party software system which is widely used for internet transaction.

Communications Interfaces

The e-store system shall use the HTTP protocol for communication over the internet and for the intranet communication will be through TCP/IP protocol suite.

Licensing Requirements

Not Applicable

Legal, Copyright, and Other Notices

E-store should display the disclaimers, copyright, word mark, trademark and product warranties of the JIKUS AUTOMOBILE.

Applicable Standards

It shall be as per the industry standard.

Supporting Information

Please refer the following document:

1. Vision document for E-store.

2. Use case analysis.

3. Structural models.

4. Behavioral models.

5. Nonfunctional requirements model.

6. Traceability Matrix.

38

7. Project Plan

d.   System   Analysis and   Design: A system analyst is a person responsible for the development of software and hardware solution to the efficient working of the organization. Analysts study the environment and problems of an organization to determine whether a new information method can provide solution to the problem.The main job of system analyst is to provide right type of information, in right quantity at the right time in post-effective manner to the management or then user.

i. Entity Relationship Diagram: An entity–relationship model (ER model) is a data model for describing a database in an abstract way. This article refers to the techniques proposed in Peter Chen's 1976 paper. However, variants of the idea existed previously, and have been devised subsequently such as super type and subtype data entities and commonality relationships.

1. The building blocks: entities, relationships, and attributes

Two related entities

An entity with an attribute

A relationship with an attribute

39

Primary key

An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of a domain. When we speak of an entity, we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.[4]

An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem.

A relationship captures how entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem.

The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs. ERROL's semantics and implementation are based on reshaped relational algebra (RRA), a relational algebra which is adapted to the entity–relationship model and captures its linguistic aspect.

Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity–relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in mathematics, while a relationship corresponds to a member of the relation.

Certain cardinality constraints on relationship sets may be indicated as well.

40

41

LOGIN

USER NAME

(ii)ENTITY RELATIONSHIP DIAGRAM

ii.     Data Flow Diagram and Use Case Diagram

1 st LEVEL DATAFLOW DIAGRAM

REGISTER

42

UESR

FIG: REGISTRION FORM

CUSTOMER NAME &PASSWORD

EAIL ID

iii. Design Strategies: Software design is about a sequence of steps taken to achieve a goal. Designers must plan their approach to carrying out these steps. In studying designers at work, the authors observed breadth- versus depth-first approaches to design-space exploration and problem- versus solution-driven approaches during the actual design. Which approaches and when to use them are important to effective design. The authors suggest four archetypical strategies that designers can choose under different circumstances, thus making design strategy one of the early design decisions.

e.   Physical Design (Coding):

43

44

45

46

47

(f). System Integration and Testing

SIT is part of the software testing life cycle for collaborative projects. Usually, a round of SIT precedes the user acceptance test (UAT) round. Software providers usually run a pre-SIT round of tests before consumers run their SIT test cases.

For example, if an integrator (company) is providing an enhancement to a customer's existing solution, then they integrate the new application layer and the new database layer with the customer's existing application and database layers. After the integration is complete, users use both the new part (extended part) and old part (pre-existing part) of the integrated application to update data. A process should exist to exchange data imports and exports between the two data layers. This data exchange process should keep both systems up-to-date. The purpose of system integration testing is to ensure all parts of these systems successfully co-exist and exchange data where necessary.

(i).Functional Testing

Functional testing is a quality assurance (QA) process and a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like in white-box testing). Functional Testing usually describes what the system does.

Functional testing differs from system testing in that functional testing "verifies a program by checking it against ... design document(s) or specification(s)", while system testing "validate[s] a program by checking it against the published user or system requirements" (Kaner, Falk, Nguyen 1999, p. 52).

Functional testing typically involves five steps [citation needed]

1. The identification of functions that the software is expected to perform2. The creation of input data based on the function's specifications3. The determination of output based on the function's specifications4. The execution of the test case5. The comparison of actual and expecte

48

(ii).Structural Testing

The structural testing is the testing of the structure of the system or component. Structural testing is often referred to as ‘white box’ or ‘glass box’ or ‘clear-box

testing’ because in structural testing we are interested in what is happening ‘inside the system/application’.

In structural testing the testers are required to have the knowledge of the internal implementations of the code. Here the testers require knowledge of how the software is implemented, how it works.

During structural testing the tester is concentrating on how the software does it. For example, a structural technique wants to know how loops in the software are working. Different test cases may be derived to exercise the loop once, twice, and many times. This may be done regardless of the functionality of the software.

Structural testing can be used at all levels of testing. Developers use structural testing in component testing and component integration testing, especially where there is good tool support for code coverage. Structural testing is also used in system and acceptance testing, but the structures are different. For example, the coverage of menu options or major business transactions could be the structural element in system or acceptance testing.

49

(iii)Test case .

The example above contains the main headings that a test case needs for most cases. However, there are many more headings which could be useful and you can find these below.

You probably won’t need all these fields in every situation, so start with a few fields and add others to the test case template later as the need arises. You can get started initially using just the fields in the example above.

 

ID (identification)

The ID field makes it easier to cross-reference test cases, both with one another and from defect reports. The ID obviously has to be unique, i.e.: there can never be more than one test case with the same ID number.

The most common approach is to use a continuous sequence, so that test cases are identified as 1, 2, 3, and so on. You don’t have to prefix the ID with a code (like

50

UM01 for the first test case in the user module), but some people do use prefixes to make it easier to see which part of the system a test case belongs to.

If you have access to a good test management tool, you won’t need to use prefixes, since the tool will automatically assign an ID number to each test case.

Some people put the test case number in the test case title, to make it easier to sort the test cases for example, however, it’s better to keep ID as a custom field and use the tool’s sorting functions, because it can get pretty difficult to keep the numbering consistent and sequential as the number of test cases grows.

 

Title

The title should provide a concise, revealing description of the test case, such as “Add customer”.

The title is important because it’s often the first or only thing you see when you are scanning a list of test cases for example.

You should gather the test cases in a test management tool, or in a document (often referred to as the test specification). Clear titles are key to helping testers quickly find the right test cases.

 

Pre-conditions

In the pre-conditions heading, you should explain any activities that the tester needs to carry out before he/she can execute the test steps. They may need to add test data, perform other functions, execute other test cases, or navigate to a particular part of the system.

The pre-conditions field isn’t relevant to every test case, so you may want to include it in the template but not make it mandatory. If you don’t describe pre-conditions accurately, the testers may not be able to conduct the test. If you have several cases that all have the same pre-conditions, you should move the pre-conditions to a test run or test specification instead, to avoid writing the same instructions repeatedly.

51

 

Test Steps

The Test Steps section gives the tester a numbered list of the steps to perform in the system, which makes it easier to understand the test case.

It is recommended to have 3-8 test steps per test case, although sometimes you might need a smaller number of test cases with a larger number of test steps. Too many steps make it difficult for developers and testers to reproduce the steps in the event that a bug report is filed against the test case.

 

Expected Results

The tester needs to know the expected result in order to assess whether the test case is successful. The optimal level of detail in this field varies from situation to situation.

One of the most common problems is the wording of the expected outcome, especially if the description is so vague that it’s not possible to tell whether the test case has succeeded. Ensure that the wording is clear and concise.

 

Post-conditions

The person executing the test case needs the Post-conditions field to know how to restore the system to its original state and not interfere with subsequent testing. For example, if the test case adds a customer, the tester might need to remove that customer. In many systems it is not possible to add two customers containing the same data. If you do not remove the customer, it is not possible to execute the test case again. Removing the newly-added customer after  executing the test steps is a typical post-condition.

If the test case involves deleting a login account, you may need to recreate it. If the same post-conditions is used in several test cases it’s more efficient to move it to a test run or test specification instead of adding it to each test case.

52

 

 

Test Data

You can enter test data directly in the test data field, or refer to a separate file that contains test data for one or more test cases. For example, you can store test data in a text file or in an Excel spreadsheet.

By using a test data file, you avoid hard coding test data in the test case, so a single test case can be used to test several sets of test data.

 

Priority

Priority indicates how urgent and/or important a test case is. All test cases can’t be of equally high priority, and priority can help determine the order in which you run them.

Priority is also useful when you run up against time constraints during test execution – you can just run the highest priority test cases, for example.

You can use a simple scale like high/medium/low, or the MoSCoW scale (Must, Should, Could, or Won’t be executed).

Priority should naturally be based on requirements, but if the requirements aren’t already prioritized, the test group should propose a prioritization that the client reviews and approves.

 

Requirements Reference

This section refers to the requirement that the test case is testing (for example “14″ if the test case tests requirement ID 14).

By using specific references to particular requirements, you can create a traceability matrix that, among other things, can show you whether you have test cases that cover all requirements.

53

With a test management tool it’s easy to create and maintain references to requirements, test cases, and defect reports.

 

Version

The field for Version contains the test case version number (not the system version number!). It’s used because the conditions for the test case may change when the test case changes.

A defect might not be caused by a problem in the system, but by the tester using an outdated version of the test case.

 

Author 

The (first and last) name of the person who wrote the test case. People reading the test case may want to contact the author to ask questions or get clarification.

 

Subsystem/functional area 

The part(s) of the system related to the test case. Sometimes also called program or component.

 

 

2. Fields which are not included in the test case

The following fields aren’t normally included in the test case since they are typically handled by a test management tool or manually documented in a test log if a tool is not used.

The reason this information doesn’t belong in a test case is that test cases contain static information which doesn’t change. The result of the test run is dynamic information that changes every time the test case is run.

54

Mixing static and dynamic information is a huge challenge, especially if you use Word and Excel for test and requirements management. However, if you’re using a test management tool such as Retest, it will probably be able to integrate static and dynamic information effectively.

 

Actual results (outcome)

Either “Approved” or the ID number of the defect report.

 

Name or signature

Details about which tester conducted the test case.

 

Date

Date the test case was performed.

55

g. Operation and Maintenance

e-business operations - website maintenance

Once a business has set up its website, it requires maintenance, just like any other part of the firm’s operations. Unless the website only offers the very minimum in information, it will need to be refreshed, updated and corrected on a regular basis. How this is done will partly depend on whether the business built its own website, or used an external agency to do it.

External agency

If the firm used an external web agency to build its website, then it should consider having a maintenance agreement with that agency to carry out such amendments and modifications as are needed.

Internally-built website

If the business built its own website, then it will be necessary for someone internally to allow time to keep the information up to date.

Whether managed internally or externally, the key areas that must be refreshed include:

o Changes in address or telephone numbers.

o New branding, logos and so on.

o The catalogue (if any) must be kept up to date, including new products and removing any that are no longer offered - this can be helped by having a catalogue that shows whether the product is in stock or not. Some potential customers will not bother to place an order for something listed as out of stock, so some businesses choose not to disclose this as long as they can get hold of stock quickly.

o Businesses that use their website extensively will tend to keep it refreshed with news of new products, promotions, events and so on.

56

o A key feature of many website packages is to have a message that states when the website was last updated, so that loyal customers can look out for what’s new.

o Another useful feature is the number of visitors counter, so that everyone can see how popular the website is (or is not!).

o External links - it is worthwhile checking all links regularly to ensure that they are still all current.

Website statistics & diagnostics

The ISP or the website package itself will provide a certain level of information about usage levels of the various sections of the site. Typically, reports can also be provided about ‘broken links’ where links within the website or to external sits are no longer working properly.

Monitoring service levels

The ISP will provide reports on any downtime that has affected the website, and it is also possible to sign up for external services that regularly test the website across the Internet to draw attention to any downtime.

Search Engines

See the note on promoting a business online. It will be necessary to re-advise search engines of the website so that it keeps coming up on searches. It is possible to purchase software that does this on the firm’s behalf.

Review of Promotion

See the note on promoting a business online. Again, the promotional strategy should be reviewed regularly in the light of performance – there are plenty of other possibilities if the current strategy is not cost-effective.

57

CHAPTER-5

Conclusion

and

Future Work

58

5.Conclusion and Future Work

Conclusions The primary objective of this project, Recommending Dynamic Web Design for the my customer via Web 2.0 and dynamic web design. The way we did this was to evaluate our website subjectively and objectively. With the results gathered from the evaluation of the site, a template was created incorporating features we deemed helpful to reaching our goal. A survey was posted on the City’s website, its Facebook fan page, allowing us to gain user input on the website. Finally, online validation tools were used to verify if jikus automobile was abiding by the W3C guidelines. This set of evaluations allowed us to assess the City’s website through a user’s perspective, compare it to other government websites, as well as making sure the website complies with W3C accessibility regulations. We then created a functional template with the combination of our research and findings, incorporating the possible changes that we believe could be added to the City’s website. The creation of this template was to visually incorporate Web 2.0 features not yet implemented on the current website, along with the addition of accessibility considerations. It was not made specifically as a direct replacement for CityOfBoston.gov, but instead as a visual representation of our findings and what could theoretically be done. We recommend a gradual addition of our possible improvements (as described in our findings section) along with polls to gauge feedback on each change. If the features are implemented in this manner, the users will have a voice in the new features being added and any unpopular changes can easily be modified or removed. This allows a more democratic feel to the alterations of the website, leaving users to measure the successes and failures of our recommendations. The template that we created was then the focus of evaluations. Though the scope of our project only allowed us to evaluate the template objectively, it was a critical part of our project. The evaluations of the template allowed us to give Boston’s MIS department a template with credible evaluations. 71

59

Future workIn the future there are several things that could be done in order to build off of the work that we completed for this project. By gaining more feedback from users and learning from the successes and failures of the template that we created, jikus automobile could become a more dynamic site that encourages civic engagement. To gain more feedback from users, another survey, with questions similar to the ones that we asked, could be conducted. However, we recommend that this survey be completed over a longer period of time as well as the promotion of its existence, thus allowing for more participation than we had in our survey. By obtaining more feedback, it would be possible to obtain a broader opinion of the user perspective of the current site. This would allow the MIS Department to make decisions about changes in the site that would reflect a larger portion of the population.

60

CHAPTER-5

Bibliography

61

6.Bibilography

Book

1. Management Information Systems , Mahadeo Jaiswal & Monika Mittal, Jul 2004 

2. Software Engineering ,K.K. Aggarwal, Yogesh Singh ,New Age International, 01-Jan-2005 - Software engineering - 494 pages

3. Management Information System, W.S.Jawadekar, 3rd edition, TMH 3. ... Management Information Systems - By W.S.Jawdekar, Second Edition. TMG Publications

Websites

1. www.wikipedia.org2. www.tutorialspoint.com3. www.slideshare.net4. www.webopedia.com5. www.computerworld.com6. www.wampserver.com7. www.w3schools.com8. www.htmltemplates.net

62