1.

Introduction/Objective of the Project

The reason behind development of this scenario, higher authorities wants to be things more
secure. They are setting up things Intra-net based in place of Internet based.

So, we started firstly implement blogging as a Module of the project. Basically its something
like blogging sites like Google.

Project Category

Existing System:

If any Institute has more than one branch in different cities, to manage these branches record
all branches have their own management system either it is file management over register or
in computer system in excel sheets. And the main branch also has all branches data or record
in the file or in excel sheets. To manage all centers record and to view or retrieve it is very
difficult in this existing system

Proposed System:

In order to eliminate the drawbacks of the existing system, a system has been developed due
to which the person need not spend much time in-

• Maintaining data or records at centers.

• Maintaining data or records at Admin or at main branch.

• To view records center / branch vise or course vise.

• To apply filters for retrieving records.

• To retrieve records at anytime and anywhere.

While you are connected to Internet as it is online system.

Page | 1
2. Hardware or Software Requirement Specification and
Security Mechanism:

Basic Requirements
The developer should have the prerequisite knowledge of following:
1. File handling
2. Ruby and Rails
3. Data Base Management System

Technology Used
• Language : Ruby Framework rails
• Database : Postgresql
• Operating System : Windows 10 OR Linux
• Web server :Nginx or Apache
• Application server: Puma

Software Requirements
• Ruby 2.3+
• Rails 5+
• Postgresql 9.5
• Nginx

Hardware Requirements
• Processor : Pentium P4 or Above
• RAM Capacity : 500MB or Above
• Hard Disk : 40GB or Above

Security Mechanism:
Security means different authorization levels to different people depending upon their
perspective or authentication level. In the context of our application security means security
of the data from unauthorized access and modification i.e. only authorized user should be
able to view or modify presented information according to their access permissions.

Page | 2
1. Overall Description
Product Perspective:
The reason behind development of this scenario, higher authorities wants to be things more
secure. They are setting up things Intra-net based in place of Internet based.

So, we started firstly implement blogging as a Module of the project. Basically its
something like blogging sites like Google.

Our mission is to deliver Simply Easy Learning with clear, crisp, and to-the-point content
on a wide range of technical and non-technical subjects without any preconditions and
impediments.
Currently we are looking for various freelancers authors & trainers having great expertise in
below mentioned technologies:
• Android Mobile Development

• iOS Mobile Development

• Big Data and related technologies

• Hadoop, Hive, Pig, HBase. MapReduce

• Blockchain

• DevOps

• Docker

• GitLab

• Android

• Continous Integration

• AWS Certification

• Python

• PHP

• Linux

• Apache/Ngix

• Scala

• C/C++

• Selenium

Page | 3
 • Data Science

• Machine Learning

• Deep Learning

• Java/J2EE

• Spring, MVC, Boot etc.

• Cloud Computing

• Microsoft Azure

• Salesforce

• OpenStack

• Bluemix

• Linux OS

• Microprocessor

• Python and its Applications

• QlikView

• MongoDB

• Six Sigma Certification

• Cyber Security

• Power BI

• React Native

• Any other latest technology

Product functions

The visitors are free to navigate through our website without providing any personally
identifiable information if they do not want to register with us.
To gain access to some of our products and services, you need to register with us and obtain
an account, user name, and password. If you choose to register with us, and are 18 years of
age or older, we will collect your personally identifiable information such as your name,
email address, and phone number. We do not collect more information than is absolutely
necessary to allow your participation in an activity on the website.

Page | 4
 We collect and analyze information about your general usage of the website, products,
services, and courses. We might track your usage patterns to see what features of the website
you commonly use, website traffic volume, frequency of visits, type and time of transactions,
type of browser, browser language, IP address and operating system, and statistical
information about how you use our products and services. We only collect, track and analyze
such information in an aggregate manner that does not personally identify you. Read the
section on Use on Cookies to know how we collect aggregate data.

Constraints

• Limited to HTTP/HTTPS.

• No multilingual support but will be added soon.

2. Introduction to Rails Framework

Rails is a web application development framework written in the Ruby language. It is
designed to make programming web applications easier by making assumptions about what
every developer needs to get started. It allows you to write less code while accomplishing
more than many other languages and frameworks. Experienced Rails developers also report
that it makes web application development more fun.

Rails is opinionated software. It makes the assumption that there is a "best" way to do things,
and it's designed to encourage that way - and in some cases to discourage alternatives. If you
learn "The Rails Way" you'll probably discover a tremendous increase in productivity. If you
persist in bringing old habits from other languages to your Rails development, and trying to
use patterns you learned elsewhere, you may have a less happy experience.

The Rails philosophy includes two major guiding principles:

• Don't Repeat Yourself: DRY is a principle of software development which states

that "Every piece of knowledge must have a single, unambiguous, authoritative
representation within a system." By not writing the same information over and over
again, our code is more maintainable, more extensible, and less buggy.
• Convention Over Configuration: Rails has opinions about the best way to do many
things in a web application, and defaults to this set of conventions, rather than require
that you specify minutiae through endless configuration files.

Models

Active Record
Active Record is the M in MVC - the model - which is the layer of the system responsible for
representing business data and logic. Active Record facilitates the creation and use of
business objects whose data requires persistent storage to a database. It is an implementation

Page | 5
of the Active Record pattern which itself is a description of an Object Relational Mapping
system.

The Active Record Pattern

Active Record was described by Martin Fowler in his book Patterns of Enterprise
Application Architecture. In Active Record, objects carry both persistent data and behavior
which operates on that data. Active Record takes the opinion that ensuring data access logic
as part of the object will educate users of that object on how to write to and read from the
database.

Object Relational Mapping

Object Relational Mapping, commonly referred to as its abbreviation ORM, is a technique
that connects the rich objects of an application to tables in a relational database management
system. Using ORM, the properties and relationships of the objects in an application can be
easily stored and retrieved from a database without writing SQL statements directly and with
less overall database access code.

Active Record as an ORM Framework

Active Record gives us several mechanisms, the most important being the ability to:

• Represent models and their data.

• Represent associations between these models.
• Represent inheritance hierarchies through related models.
• Validate models before they get persisted to the database.
• Perform database operations in an object-oriented fashion.

Convention over Configuration in Active Record

When writing applications using other programming languages or frameworks, it may be
necessary to write a lot of configuration code. This is particularly true for ORM frameworks
in general. However, if you follow the conventions adopted by Rails, you'll need to write
very little configuration (in some cases no configuration at all) when creating Active Record
models. The idea is that if you configure your applications in the very same way most of the
time then this should be the default way. Thus, explicit configuration would be needed only
in those cases where you can't follow the standard convention.

Naming Conventions
By default, Active Record uses some naming conventions to find out how the mapping
between models and database tables should be created. Rails will pluralize your class names
to find the respective database table. So, for a class Book, you should have a database table
called books. The Rails pluralization mechanisms are very powerful, being capable of
pluralizing (and singularizing) both regular and irregular words. When using class names
composed of two or more words, the model class name should follow the Ruby conventions,
using the CamelCase form, while the table name must contain the words separated by
underscores. Examples:
• Database Table - Plural with underscores separating words (e.g., book_clubs).
Page | 6
 • Model Class - Singular with the first letter of each word capitalized
(e.g., BookClub).
Model / Class Table / Schema

Article articles

LineItem line_items

Deer deers

Mouse mice

Person people

Schema Conventions
Active Record uses naming conventions for the columns in database tables, depending on the
purpose of these columns.

•
Foreign keys - These fields should be named following the
pattern singularized_table_name_id (e.g., item_id, order_id). These are the fields
that Active Record will look for when you create associations between your
models.
• Primary keys - By default, Active Record will use an integer column named id as
the table's primary key. When using Active Record Migrations to create your
tables, this column will be automatically created.
There are also some optional column names that will add additional features to Active Record
instances:

• created_at - Automatically gets set to the current date and time when the record is
first created.
• updated_at - Automatically gets set to the current date and time whenever the
record is updated.
• lock_version - Adds optimistic locking to a model.
• type - Specifies that the model uses Single Table Inheritance.
• (association_name)_type - Stores the type for polymorphic associations.
• (table_name)_count - Used to cache the number of belonging objects on
associations.
.

Creating Active Record Models

It is very easy to create Active Record models. All you have to do is to subclass
the ApplicationRecord class and you're good to go:
class Product < ApplicationRecord
end

Page | 7
This will create a Product model, mapped to a products table at the database. By doing this
you'll also have the ability to map the columns of each row in that table with the attributes of
the instances of your model.
Overriding the Naming Conventions
What if you need to follow a different naming convention or need to use your Rails
application with a legacy database? No problem, you can easily override the default
conventions.

ApplicationRecord inherits from ActiveRecord::Base, which defines a number of helpful

methods. You can use the ActiveRecord::Base.table_name= method to specify the table name
that should be used:
class Product < ApplicationRecord
self.table_name = "my_products"
end

CRUD: Reading and Writing Data

CRUD is an acronym for the four verbs we use to operate on data: Create, Read, Update
and Delete. Active Record automatically creates methods to allow an application to read and
manipulate data stored within its tables.
Create
Active Record objects can be created from a hash, a block or have their attributes manually
set after creation. The new method will return a new object while create will return the object
and save it to the database.

Read
Active Record provides a rich API for accessing data within a database.

Update
Once an Active Record object has been retrieved, its attributes can be modified and it can be
saved to the database.

Delete
Likewise, once retrieved an Active Record object can be destroyed which removes it from the
database.

user = User.find_by(name: 'David')

user.destroy

Validations
Active Record allows you to validate the state of a model before it gets written into the
database. There are several methods that you can use to check your models and validate that
an attribute value is not empty, is unique and not already in the database, follows a specific
format and many more.

Validation is a very important issue to consider when persisting to the database, so the
methods save and update take it into account when running: they return false when validation

Page | 8
fails and they didn't actually perform any operation on the database. All of these have a bang
counterpart (that is, save! and update!), which are stricter in that they raise the
exception ActiveRecord::RecordInvalid if validation fails

Callbacks
Active Record callbacks allow you to attach code to certain events in the life-cycle of your
models. This enables you to add behavior to your models by transparently executing code
when those events occur, like when you create a new record, update it, destroy it and so on.
You can learn more about callbacks in the Active Record Callbacks guide.

Migrations
Rails provides a domain-specific language for managing a database schema called
migrations. Migrations are stored in files which are executed against any database that Active
Record supports using rake. Here's a migration that creates a table:
class CreatePublications < ActiveRecord::Migration[5.0]
def change
create_table :publications do |t|
t.string :title
t.text :description
t.references :publication_type
t.integer :publisher_id
t.string :publisher_type
t.boolean :single_issue

t.timestamps
end
add_index :publications, :publication_type_id
end
end
Rails keeps track of which files have been committed to the database and provides rollback
features. To actually create the table, you'd run rails db:migrate and to roll it back, rails
db:rollback.
Note that the above code is database-agnostic: it will run in MySQL, PostgreSQL, Oracle and
others. You can learn more about migrations in the Active Record Migrations guide.

Migration
Migrations are a convenient way to alter your database schema over time in a consistent and
easy way. They use a Ruby DSL so that you don't have to write SQL by hand, allowing your
schema and changes to be database independent.
You can think of each migration as being a new 'version' of the database. A schema starts off
with nothing in it, and each migration modifies it to add or remove tables, columns, or
entries. Active Record knows how to update your schema along this timeline, bringing it
from whatever point it is in the history to the latest version. Active Record will also update
your db/schema.rb file to match the up-to-date structure of your database.

Page | 9
Action View
In Rails, web requests are handled by Action Controller and Action View. Typically, Action
Controller is concerned with communicating with the database and performing CRUD
actions where necessary. Action View is then responsible for compiling the response.
Action View templates are written using embedded Ruby in tags mingled with HTML. To
avoid cluttering the templates with boilerplate code, a number of helper classes provide
common behavior for forms, dates, and strings. It's also easy to add new helpers to your
application as it evolves.

Some features of Action View are tied to Active Record, but that doesn't mean Action View
depends on Active Record. Action View is an independent package that can be used with any
sort of Ruby libraries.

Using Action View with Rails

For each controller there is an associated directory in the app/views directory which holds the
template files that make up the views associated with that controller. These files are used to
display the view that results from each controller action.
Let's take a look at what Rails does by default when creating a new resource using the
scaffold generator:

$ bin/rails generate scaffold article

[...]

invoke scaffold_controller

create app/controllers/articles_controller.rb

invoke erb

create app/views/articles

create app/views/articles/index.html.erb

create app/views/articles/edit.html.erb

create app/views/articles/show.html.erb

create app/views/articles/new.html.erb

create app/views/articles/_form.html.erb

[...]

There is a naming convention for views in Rails. Typically, the views share their name with
the associated controller action, as you can see above. For example, the index controller
action of the articles_controller.rb will use the index.html.erb view file in
the app/views/articlesdirectory. The complete HTML returned to the client is composed of a

Page | 10
combination of this ERB file, a layout template that wraps it, and all the partials that the view
may reference. Within this guide you will find more detailed documentation about each of
these three components.

Templates, Partials and Layouts

As mentioned, the final HTML output is a composition of three Rails
elements: Templates, Partials and Layouts. Below is a brief overview of each of them.

Templates
Action View templates can be written in several ways. If the template file has a .erb extension
then it uses a mixture of ERB (Embedded Ruby) and HTML. If the template file has
a .builderextension then the Builder::XmlMarkup library is used.
Rails supports multiple template systems and uses a file extension to distinguish amongst
them. For example, an HTML file using the ERB template system will have .html.erb as a file
extension.

ERB
Within an ERB template, Ruby code can be included using both <% %> and <%= %> tags.
The <% %>tags are used to execute Ruby code that does not return anything, such as
conditions, loops or blocks, and the <%= %> tags are used when you want output.

Builder
Builder templates are a more programmatic alternative to ERB. They are especially useful for
generating XML content. An XmlMarkup object named xml is automatically made available
to templates with a .builder extension.

Jbuilder
Jbuilder is a gem that's maintained by the Rails team and included in the default Rails
Gemfile. It's similar to Builder, but is used to generate JSON, instead of XML..

Template Caching
By default, Rails will compile each template to a method in order to render it. When you alter
a template, Rails will check the file's modification time and recompile it in development
mode.

Partials

Partial templates - usually just called "partials" - are another device for breaking the
rendering process into more manageable chunks. With partials, you can extract pieces of code
from your templates to separate files and also reuse them throughout your templates.

Layouts
Layouts can be used to render a common view template around the results of Rails controller
actions. Typically, a Rails application will have a couple of layouts that pages will be
rendered within..

Page | 11
Partial Layouts
Partials can have their own layouts applied to them. These layouts are different from those
applied to a controller action, but they work in a similar fashion.

View Paths
When rendering a response, the controller needs to resolve where the different views are
located. By default it only looks inside the app/views directory.
We can add other locations and give them a certain precedence when resolving paths using
the prepend_view_path and append_view_path methods.

Prepend view path

This can be helpful for example, when we want to put views inside a different directory for
subdomains.

We can do this by using:

prepend_view_path "app/views/#{request.subdomain}"

Then Action View will look first in this directory when resolving views.

Append view path

Similarly, we can append paths:

append_view_path "app/views/direct"

CsrfHelper
Returns meta tags "csrf-param" and "csrf-token" with the name of the cross-site request
forgery protection parameter and token, respectively.

<%= csrf_meta_tags %>

Localized Views
Action View has the ability to render different templates depending on the current locale.

Page | 12
3. Methodology

Design Methodology
Software Development Process
In the software development process we focus on the activities directly related to
production of the software, for example, design, coding, and testing. A development process
model specifies some activities that, according to the model, should be performed, and the
order in which they should be performed. As the development process specifies the major
development and quality assurance activities that need to be performed in the project, the
development process really forms the core of the software process. Due to the importance of
development process,

The Linear Sequential Model

Software Requirements Analysis
In this I have tried to understand the nature of the program(s) to be built for this
software. I have understood the information domain for this software, as well as required
function, behavior, performance, and interface. Requirements for both the system and the
software are documented and reviewed with the customer.

Design
Software design is actually a multistep process that focuses on four distinct attributes
of a program, data structure, software architecture, interface representation, and procedural
(algorithmic) detail. The design process translates requirements into a representation of the
software that can be assessed for quality before code begins. Like requirements, the design is
documented and becomes part of the software configuration.
Code Generation
Coding of this software has done in ASP.NET as a Front-End-Tool and the data are
retrieved from the using SQL (Structured Query Language) which is the back end.

Testing
Once code has been generated, I have first performed program testing. The testing
process focuses on the logical internals of the software, ensuring that all statements have been
tested, and on the functional externals; that is, conducting tests to uncover errors and ensure
that defined input will produce actual results that agree with required results

Page | 13
4. Architectural Design
Large systems are generally decomposed to smaller subsystems that account for functionality
of the complete software system. This process of identifying the sub systems and establishing
a framework for sub system control and communication is called architectural design.
Architectural design is an important phase, as a bad architectural design cannot be rescued by
good implementation. Following activities were performed during this stage:
Principle sub systems that are functionally independent were identified and distinguished.
A general model of control relationships between system parts was established.
Each subsystem was further decomposed into their sub functions

Database Design and Specification

In all there will be following tables will be there during first phase, however more
tables can be added as project progress.

Table Name Admin::Comment

Description To maintain the information about all the admins and details

Column_Name Data_Type Constraints

Author_id integer Not Null
Author_type string Not Null
Body text Not Null
Namespace string Not Null
Resource_id integer Not Null
Resource_type string Not Null

Table Name User

Description To maintain all the information about user

Column_Name Data_Type Constraints

email string Not Null
encrypted_password string Not Null
Remember_created_at datetime Not Null
reset_password_sent_at datetime Not Null
reset_password_token String Not Null

Page | 14
Table Name Blog
Description To maintain all the information about blogs

Column_Name Data_Type Constraints

body text Not Null
date string Not Null
image string Not Null
tags string Not Null
title string Not Null

Table Name User Profile

Description To maintain all the information about user details

Column_Name Data_Type Constraints

about_me text Not Null
image string Not Null
name string Not Null

Page | 15
 DATA FLOW DAIGRAM FOR ADMIN MODULE:
Level 0:

Level 1:

Level 2:

Page | 16
DFD for ADMIN Module

Page | 17
 ER DIAGRAM

Proposed System

Feasibility Study

The main objective of the preliminary analysis is to identify the problem, evaluate the
system concept of feasibility, and perform the economic and technical analyses perform the
cost benefit analysis. After the clarification analysis the solution proposed it is checked that it
is practical to implement that solution. This is done through the feasibility study. It is checked
for various aspects whether the proposed solution is technically or economically feasible or
not. On the basis if which it has been categorized into three classes- Technical, Economic and
Legal.
The outcome of the preliminary analysis should be clear so that an alternate way to do
the job can be found out?

Technical Feasibility

During the technical feasibility studies following issues are taken into consideration
Whether the required technology is available or not? Required resources are available or not?
(Manpower, programmer, software and hardware etc) Once the technical feasibility is
established, it is important to consider the monetary factors also. Since it might happen that

Page | 18
 developing a particular system may be technically possible but it may be require huge
investments and benefits may be less. For evaluating this, economic feasibility of the
proposed system is carried out. As in our proposed system our team has technically trained
manpower with knowledge of developing the system. We are going to use web technology in
our system, which is readily available. Software to be used is also available easily. So
technically the project is feasible.

Economic Feasibility
For any system if the expected benefits equal or exceed the expected costs, the system
can be judged to be economically feasible. In economic feasibility, cost benefit analysis is
done in which expected costs and benefits are evaluated. Economic analysis is used for
evaluating the effectiveness of the proposed system. In economic feasibility, the most
important is cost benefit analysis. As the name suggests, it is an analysis of the cost to be
incurred in the system and benefits derivable out of the system. As in my organization the
hardware and software required for this type of system is already available so economically
our project is feasible.

Legal Feasibility

It includes study concerning contracts, liability, violation and legal other traps frequently
unknown to the technical staff.

5. Specific Requirements

System Requirements:
a) Basic Requirements
The developer should have the prerequisite knowledge of following:
1. Ruby and Rails
2. Postgresql
3. Data Base Management System

b) Technology Used

• Language : Ruby
• Framework :rails

Page | 19
 • Database : Postgresql
• Operating System : Windows 10 OR Linux
• Web server :Nginx or Apache
• Application server: Puma

c) Software Requirements

• Ruby 2.3+
• Rails 5+
• Postgresql 9.5
• Nginx

d) Hardware Requirements

• Processor : Pentium P4 or Above

• RAM Capacity : 500MB or Above
• Hard Disk : 40GB or Above

Security Requirements:
The Software will be developed keeping in mind to provide best possible security.
Following functionalities will be utilized to make the software very secure:

• Use of unique username and password for each user account

• Utilization of certain cryptographic techniques

• Keeping specific log or history data sets

• Restriction of communications between some areas of the program

• Checking data integrity for critical variables

Security means different authorization levels to different people depending upon their
perspective or authentication level. In the context of our application security means security
of the data from unauthorized access and modification i.e. only authorized user should be
able to view or modify presented information according to their access permissions.

Page | 20
6. Software Development Life Cycle
Iterative development
Iterative development is at the heart of a cyclic software development process developed in
response to the weaknesses of the waterfall model. It starts with an initial planning and ends
with deployment with the cyclic interactions in between.

Iterative and incremental development are essential parts of the Rational Unified Process,
Extreme Programming and generally the various agile software development frameworks.
It follows a similar process to the plan-do-check-act cycle of business process improvement.
A common mistake is to consider "iterative" and "incremental" as synonyms, which they are
not. In software/systems development, however, they typically go hand in hand. The basic
idea is to develop a system through repeated cycles (iterative) and in smaller portions at a
time (incremental), allowing software developers to take advantage of what was learned
during development of earlier parts or versions of the system. Learning comes from both the
development and use of the system, where possible key steps in the process start with a
simple implementation of a subset of the software requirements and iteratively enhance the
evolving versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added.
The procedure itself consists of the initialization step, the iteration step, and the Project
Control List. The initialization step creates a base version of the system. The goal for this
initial implementation is to create a product to which the user can react. It should offer a
sampling of the key aspects of the problem and provide a solution that is simple enough to
understand and implement easily. To guide the iteration process, a project control list is
created that contains a record of all tasks that need to be performed. It includes such items as
new features to be implemented and areas of redesign of the existing solution. The control list
is constantly being revised as a result of the analysis phase.

Page | 21
The iteration involves the redesign and implementation of a task from the project control list,
and the analysis of the current version of the system. The goal for the design and
implementation of any iteration is to be simple, straightforward, and modular, supporting
redesign at that stage or as a task added to the project control list. The level of design detail is
not dictated by the interactive approach. In a light-weight iterative project the code may
represent the major source of documentation of the system; how-critical iterative project a
formal Software Design Document may be used. The analysis of an iteration is based upon
user feedback, and the program analysis facilities available. It involves analysis of the
structure, modularity, usability, reliability, efficiency, & achievement of goals. The project
control list is modified in light of the analysis results.

Phases
Incremental development slices the system functionality into increments (portions). In each
increment, a slice of functionality is delivered through cross-discipline work, from the
requirements to the deployment. The unified process groups increments/iterations into
phases: inception, elaboration, construction, and transition.

• Inception identifies project scope, risks, and requirements (functional and non-
functional) at a high level but in enough detail that work can be estimated.

• Elaboration delivers a working architecture that mitigates the top risks and fulfills the
non-functional requirements.

• Construction incrementally fills-in the architecture with production-ready code

produced from analysis, design, implementation, and testing of the functional
requirements.

Page | 22
 • Transition delivers the system into the production operating environment.
Each of the phases may be divided into 1 or more iterations, which are usually time-boxed
rather than feature-boxed. Architects and analysts work one iteration ahead of developers and
testers to keep their work-product backlog full.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a
waterfall.
Contrast with Waterfall development
Waterfall development completes the project-wide work-products of each discipline in one
step before moving on to the next discipline in the next step. Business value is delivered all at
once, and only at the very end of the project. Backtracking is possible in an iterative
approach.
Implementation guidelines
Guidelines that drive the implementation and analysis include:

• Any difficulty in design, coding and testing a modification should signal the need for
redesign or re-coding.

• Modifications should fit easily into isolated and easy-to-find modules. If they do not,
some redesign is possibly needed.

• Modifications to tables should be especially easy to make. If any table modification is

not quickly and easily done, redesign is indicated.

• Modifications should become easier to make as the iterations progress. If they are not,
there is a basic problem such as a design flaw or a proliferation of patches.

Page | 23
 • Patches should normally be allowed to exist for only one or two iterations. Patches
may be necessary to avoid redesigning during an implementation phase.

• The existing implementation should be analyzed frequently to determine how well it

measures up to project goals.

• Program analysis facilities should be used whenever available to aid in the analysis of
partial implementations.

• User reaction should be solicited and analyzed for indications of deficiencies in the
current implementation.

7. TESTING & IMPLIMENTATION

Testing Introduction
During earlier development phases an attempt is made to build software from an abstract
concept to tangible implementation. Software testing is a critical element of software quality
assurance and represents ultimate review of specification; design and coding notion of
“correctness” of the software just developed and overcome a conflict of interest that occur
sheen errors are recovered. A thorough testing of system before any implementation is
mandatory As regards its individual programs the system as a whole user acceptance of the
system etc. This is because implementing a new system is a major job, which requires a lot of
man-hours and other resources, so an error not detected before implementation may cost a lot.
Effective testing early in a process is also necessary because in some cases a small error not
detected and corrected early before installation may explore into much large problems.
After programming and testing comes the stage of installing the computerized system. It has
the enormous responsibilities of detecting any type of error that may be in the software.
Actual implementation of the system can be begin at this point using either of parallel or
direct change over plan or a blend of the two.
All these factors mean that testing cannot be done on the fly, as is often done by
programmers. It has to be carefully planned and the plan has to be properly exacted. The
testing process focuses on how testing should proceed for a particular project.

Testing the system:

Testing can be done with two types of data. Live data and test data.

• Live Data: Live data is the data actually to be used in the proposed system.

Page | 24
 • Test Data: Test data is previously designed sample input to achieve predictable
results.

Test Objective:

• Testing is a process of execution a program with the intent of finding error.

• A good test case is one that has a high portability of finding an undiscovered error.

• A successful test is one that uncovers an as-yet-discovered error.

Testing Principles:

• All tests should be traceable to customer requirements.

• Test should be planned long before testing begins.

• Testing should begin ”in small” and progress towards testing in the large.

• To be most effective an independent third party should conduct testing.

Test Plan:
The first steps in the system testing are to prepare a plan that will retest all aspects of the
system in a way that promotes its credibility among potential users. There is a psychology in
testing:

• Programmers usually do a better job in unit testing because they are expected to
document and report on the method and extent of their testing.

• Programmers are involved when they become aware of the user problems and
expectations.

Testing Methods:
White box testing:
White box testing of software is predicated on close examination of procedural details.
Providing test cases that exercise specific sets of conditions and loop tests logical is a test
case design method that uses the control structure of the procedural design to derive test
cases.

• Guarantee that all independent paths within module have been exercised at least once.

• Exercise all logical decisions on their true and false sides. Execute all loops at their
boundaries and within their operational bounds.

• Exercise internal data structures to assure their validity.

Page | 25
 • The errors that can be encountered while conducting white box testing are logic errors
incorrect assumptions or typographical errors.
Black box testing:
Black box testing is carried out check the functionality of the various modules. Although
they are designed to uncover error black box testing use to demonstrate that software function
are optional that input is corrected accepted and output is corrected produced and that the
integrity of the external information is maintained. A black box test examines some
fundamental aspects of the system with little regard for the internal logical structure of the
software.

• Incorrect or missing function

• Interface errors

• Errors in data structure or external database access.

• Performance errors

• Initialization and termination errors.

Levels of Testing:
A strategy for s/w testing integrates s/w test case designs methods in well-planned
series of steps that results in the successful construction software. An important software
testing planned in advance and conducted systematically. Verification is performed on the
output of each phase but some faults are likely to remain undetected by these methods. These
faults will be eventually reflected in the code. Testing is usually relied on to detect these
faults, in addition to the faults introduced during the coding phase itself. Due to this different
levels of testing are used in the testing process; each level of testing aims to test different
aspects of the system.

Client Acceptance Testing

Requirement System Testing

Design Integration Testing

code Unit Testing
Unit Testing.

Page | 26
 • Unit Testing: This is the first level of testing. In this different modules are tested
against the specifications produced during design for the modules. Unit testing is
essential for verification of the code produces during the coding phase, and hence the
goal is to test the internal logic of the modules. The programmers of the module
typically do it. Others consider a module for integration and use only after it has been
unit tested satisfactorily. Due to its close association with coding the coding phase is
frequently called “coding & unit testing”. As the focus of this testing level is on
testing the code structured testing is best suited for this level.

• Structural Testing: is an approach to testing where the tests are derived from
knowledge of the software’s structure and implementation this approach is can
analyze the close and use knowledge about the structure of a component to derive test
data. The analysis of the code can be used to find how many test cases are needed to
guarantee that all of the statements in the program or components are executed at least
once during the testing process

• Integration Testing: Integration Testing is the next level of testing. In this many
unit-tested modules are combined into subsystems, which are then tested. The goal
here is to see if the modules can be integrated properly. Hence the emphasis is on
testing interfaces between modules. This testing activity can be considered testing the
design.

• System and Acceptance Testing: The next levels are system testing & acceptances
testing. Here the entire software system is tested. The reference document for this
purpose is the requirements document and the goal is to see if the software meets its
requirements. This is essentially a validation exercise, and in many situations it is the
only validation activity. Acceptance testing is sometimes performed with realistic data
of the client to determine that the software is working satisfactorily. Testing here
focus on the external behavior of the system; the internal logic of the program is not
emphasized.
Activity Network for System Testing:
Test plan entails the following activities:

• Prepare Test Plan

• Specify conditions for User Acceptance Testing.

Page | 27
 • Prepare Test Data for Program Testing.

• Prepare Test Data for Transaction Path Testing.

• Plan User Training.

• Compile/Assemble Programs

• Prepare job performance aids

• Prepare operational documents.

Testing of Forms:
Forms are the interface between the user and database system. Testing of forms was
extensive task. All data entry and query formats are designed using forms. Forms were tested
to ensure that they are performing the tasks well they are designed for and correction and
modification we made found to be necessary.
System testing is designed to uncover weakness that was not found in the earlier tests. This
includes forced system failure and its users in the operational environment will implement
validation of the total system as it. The total system is tested for recovery and fallback after
various major failures to ensure that data lost during the emergency. All this is done with the
old system still in operation.
After a successful testing of the individual programs and forms the whole system was through
a series of test to ensure the proper working of the system as a whole.
The activities involved in the system testing are:

• Integration Testing

• Acceptance Testing
In integration testing the entire system is tested and acceptance testing involves planning and
execution of functional tests, implemented system satisfied its requirements.
Security Test:
The functional environment of the system posed no real security threat but the system was
developed considering the entire data to be highly critical and thus denying free access to
anyone without proper access rights. The entire system is password protected and session id
is given to each user, which is carried by him throughout his working on the site.
Debugging:
Programmers carry out some testing of the code they have developed. This often reveals
program defects that must be removed from the program. This is called Debugging.

Page | 28
 Debugging is concerned with locating and correcting these defects. The debugging process is
often integrated with other verification and validation activities. There is no simple method
for debugging. Skilled debugging look for patterns in the test output where the defect is
exhibited and use knowledge of the type of defect the output pattern the programming
language and the programming process to locate the defect.

The Debugging Process:

Test Result Specialication Test Case

Locale Design Repair Repair

Error Error Error

8. Implementation
The develops system will be implemented on the administrator’s Pc who can give
rights to other users and can modification and user’s Pc who is responsible for the recordings
the scheduling and generation of exam of the student’s site by replacing the existing system
with the new system.
The various phases of implementing new system are as following:
Conversion: This means the changing from one system to another. The objective is to put the
tested system into operation. The method adopted for conversion of this system is parallel
system. Under this method both the system old and new are operated parallel. This is the
safest method. Error can be prime concern during the conversion this will be done on site.
The data will be entered to the database from the existing registers.
Training: The quality or training received by the personnel involved with the system in
various capacities helps or hinders, and may even prevent the successful implementation of
an information system. Those who will be associated with or affected by the system need to

Page | 29
 be trained. Training the personnel will be in house. The user of the system will be trained that
what the system can be and what cannot.
Post Implementation Review: After the system is implemented and conversion is complete
a review of the system of the system will be done. It is a formal process to determine how
well the system is working how it has been accepted

9. Website architecture
Website architecture is an approach to the design and planning of websites which,
like architecture itself, involves technical, aesthetic and functional criteria. As in traditional
architecture, the focus is properly on the user and on user requirements. This requires
particular attention to web content, a business plan, usability, interaction design, information
architecture and web design. For effective search engine optimization it is necessary to have
an appreciation of how a single website relates to the World Wide Web.
Since web content planning, design and management come within the scope of design
methods, the traditional vitruvian aims of commodity, firmness and delight can guide the
architecture of websites, as they do physical architecture and other design disciplines.
Website architecture is coming within the scope of aesthetics and critical theory and this
trend may accelerate with the advent of the semantic web and web 2.0. Both ideas emphasise
the structural aspects of information. Structuralism is an approach to knowledge which has
influenced a number of academic disciplines including aesthetics, critical theory and
postmodernism. Web 2.0, because it involves user-generated content, directs the website
architect's attention to the structural aspects of information.
"Website architecture" has the potential to be a term used for the intellectual
discipline of organizing website content. "Web design", by way of contrast, describes the
practical tasks, part-graphic and part-technical, of designing and publishing a website. The
distinction compares to that between the task of editing a newspaper or magazine and its
graphic design and printing. But the link between editorial and production activities is much
closer for web publications than for print publications.

Page | 30
Website Quality Factors
• Timeliness (Proper updation)
• Structural Quality (Uncluttered and Easy to read)
• Content (Relevant and understandable)
• Recoverability (Minimum loss of data)
• Security (Encryption, Verify Users)
• Usability (Easy navigation)
• Performance (Less time to load)

Web testing checklist

• Functionality Testing

• Usability testing

• Interface testing

• Compatibility testing

• Performance testing

• Security testing

1) Functionality Testing:
Test for – all the links in web pages, database connection, forms used in the web pages for
submitting or getting information from user, Cookie testing.

Page | 31
Check all the links:

• Test the outgoing links from all the pages from specific domain under test.

• Test all internal links.

• Test links jumping on the same pages.

• Test links used to send the email to admin or other users from web pages.

• Test to check if there are any orphan pages.

• Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:

Forms are the integral part of any web site. Forms are used to get information from users
and to keep interaction with them. So what should be checked on these forms?

• First check all the validations on each field.

• Check for the default values of fields.

• Wrong inputs to the fields in the forms.

• Options to create forms if any, form delete, view or modify the forms.
Let’s take example of the search engine project currently I am working on, In this project we
have advertiser and affiliate signup steps. Each sign up step is different but dependent on
other steps. So sign up flow should get executed correctly. There are different field
validations like email Ids, User financial info validations. All these validations should get
checked in manual or automated web testing.

Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the
session mainly login sessions. Test the application by enabling or disabling the cookies in
your browser options. Test if the cookies are encrypted before writing to user machine. If you
are testing the session cookies (i.e. cookies expire after the sessions ends) check for login
sessions and user stats after session end. Check effect on application security by deleting the
cookies. (I will soon write separate article on cookie testing)

Validate your HTML/CSS:

Page | 32
If you are optimizing your site for Search engines then HTML/CSS validation is very
important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to
different search engines.
Database testing:
Data consistency is very important in web application. Check for data integrity and errors
while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also
updated correctly. More on database testing could be load on DB, we will address this in web
load or performance testing below.

2) Usability Testing:
Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or
how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided
instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.

Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark
colors annoys users and should not be used in site theme. You can follow some standards that
are used for web page and content building. These are common accepted standards like as I
mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images
should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your
task is to validate all for UI testing

Other user information for user help:

Like search option, sitemap, help files etc. Sitemap should be present with all the
links in web sites with proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily
and quickly. These are all optional items and if present should be validated.
Page | 33
3) Interface Testing:
The main interfaces are:
Web server and application server interface Application server and Database server interface.
Check if all the interactions between these servers are executed properly. Errors are
handled properly. If database or web server returns any error message for any query by
application server then application server should catch and display these error messages
appropriately to users. Check what happens if user interrupts any transaction in-between?
Check what happens if connection to web server is reset in between?

4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility
test to be executed:

• Browser compatibility

• Operating system compatibility

• Mobile browsing

• Printing options

Browser compatibility:
In my web-testing career I have experienced this as most influencing part on website testing.
Some applications are very dependent on browsers. Different browsers have different
configurations and settings that your web page should be compatible with. Your web site
coding should be cross browser platform compatible. If you are using java scripts or AJAX
calls for UI functionality, performing security checks or validations then give more stress on
browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape
navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:
Some functionality in your web application is may not be compatible with all operating
systems. All new technologies used in web development like graphics designs, interface calls
like different API’s may not be available in all Operating Systems.Test your web application

Page | 34
on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS
flavors.

Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on
mobile browsers. Compatibility issues may be there on mobile.

Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics
getting printed properly. Pages should be fit to paper size or as per the size mentioned in
printing option.

5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:

• Web Load Testing

• Web Stress Testing

Test application performance on different internet connection speed.

web load testing:

Test if many users are accessing or requesting the same page. Can system sustain in peak
load times? Site should handle many simultaneous user requests, large input data from users,
Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing:
Generally stress means stretching the system beyond its specification limits. Web stress
testing is performed to break the site by giving stress and checked how system reacts to stress
and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.
In web performance testing web site functionality on different operating systems, different
hardware platforms is checked for software, hardware memory leakage errors,

6) Security Testing:
Following are some test cases for web security testing:

Page | 35
 • Test by pasting internal url directly into browser address bar without login. Internal
pages should not open.

• If you are logged in using username and password and browsing internal pages then
try changing url options directly. I.e. If you are checking some publisher site statistics
with publisher site ID= 123. Try directly changing the URL site ID parameter to
different site ID which is not related to logged in user. Access should denied for this
user to view others stats.

• Try some invalid inputs in input fields like login username, password, input text
boxes. Check the system reaction on all invalid inputs.

• Web directories or files should not be accessible directly unless given download
option.

• Test the CAPTCHA for automates scripts logins.

• Test if SSL is used for security measures. If used proper message should get displayed
when user switch from non-secure http:// pages to secure https:// pages and vice versa.

• All transactions, error messages, security breach attempts should get logged in log
files somewhere on web server.

10. Screenshots

Page | 36
Page | 37
Page | 38
Page | 39
Page | 40
Page | 41
Page | 42
Page | 43
Page | 44
Page | 45
Page | 46
Page | 47
 11. CONCLUSION & RECOMMENDATIONS

Conclusions and Recommendations

The entire project has been developed and deployed as per the requirements stated by
the user, it is found to be bug free as per the testing standards that are implemented. Any
specification untraced errors will be concentrated in the coming versions, which are
planned to be developed in near future. The system at present does not take care of
the money payment methods, as the consolidated constructs need SSL standards and are
critically to be initiated in the first face, the application of the credit card transactions is
applied as a developmental phase in the coming days. The system needs more elaborative
technicality for its inception and evolution.

11. Future Scope

COMPUTER SCIENCE DEPARTMENT PORTAL has vast future scopes some of these are:

• Implement internal mailing system that connects all students and teachers of all
centers.

• Implement graph level reporting for students that shows his/her monthly/yearly
progress in any course or in any subject also.

• Implement online test module at c level.

• Implement a forum in which all students share their ideas with others.

Page | 48
12. BIBILIOGRAPHY

• Ruby (Oprah's Book Club 2.0) by Cynthia Bond

• The Ruby Programming Language by Yukihiro Matsumoto.

• Fundamentals of Software Engineering, Rajiv Mall.

• Intro to HTML Training By Tools.Com

• Rails Guide
Websites:

• http://www.tutorialspoint.com/ruby/

• http://www.rubypets.com

• http://www.codeproject.com

• http://www.stackoverflow.com

• http://www.ruby_n_rails.com

• http://www.RubySpider.com

• http://www.w3schools.com

• http://www.softwaretestinghelp.co

Page | 49