PRACTICAL :1

AIM: Study the complete software development life cycle & analyze various activity
conducted at various phases.

OBJECTIVE: To study various phases of SDLC and different models in detail.

DESCRIPTION:

SDLC
SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The
life cycle defines a methodology for improving the quality of software and the overall development
process.

Various phases of SDLC:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the
senior members of the team with inputs from the customer, the sales department, market surveys and
domain experts in the industry. This information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational, and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to define the
various technical approaches that can be followed to implement the project successfully with minimum
risks.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done through
SRS. Software Requirement Specification document which consists of all the product requirements to
be designed and developed during the project life cycle.

Stage 3: Designing the product architecture

SRS is the reference for product architects to come out with the best architecture for the product to be
developed. Based on the requirements specified in SRS, usually more than one design approach for the
product architecture is proposed and documented in a DDS - Design Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity , budget and time constraints , the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any). The
internal design of all the modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is
generated as per DDS during this stage. If the design is performed in a detailed and organized manner,
code generation can be accomplished without much hassle.
Developers have to follow the coding guidelines defined by their organization and programming tools
like compilers, interpreters, debuggers etc are used to generate the code. Different high level
programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming
language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are
mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the
product where products defects are reported, tracked, fixed and retested, until the product reaches the
quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market.
Sometime product deployment happens in stages as per the organizations,business strategy.

SDLC Models

There are various software development life cycle models defined and designed which are followed
during software development process. These models are also referred as "Software Development
Process Models". Each process model follows a Series of steps unique to its type, in order to ensure
success in process of software development.
Following are the most important and popular SDLC models followed in the industry:
  Waterfall Model
 Iterative Model
 Spiral Model
1] Waterfall Model
1.1 Define:
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.

1.2 Diagram:

The sequential phases in Waterfall model are:

 Requirement Gathering and analysis: All possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification doc.
 System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
 Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested
for its functionality which is referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any faults
and failures.
 Deployment of system: Once the functional and non functional testing is done, the product is
deployed in the customer environment or released into the market.
 Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
Applications of waterfall model
 Requirements are very well documented, clear and fixed.
  Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 The project is short.

2] Iterative Model design

2.1 Define:
Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration,
design modifications are made and new functional capabilities are added. The basic idea behind this
method is to develop a system through repeated cycles (iterative) and in smaller portions at a time
(incremental).

2.2 Diagram:

Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of
the software development cycle may be in progress at the same time." and "This process may be
described as an "evolutionary acquisition" or "incremental build" approach."
In incremental model the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release. The process continues till the
complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests have to be
repeated and extended to verify each version of the software.

Applications of Iterative Model

 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested enhancements
may evolve with time.
 There is a time to the market constraint.
 Practical: 2

AIM: Consider any project to be developed in any technology. Construct software requirement
specification document.

1. Introduction:
The development of portal for web based newspaper generally means creating a website in which the
management of all news item sent by crowd about any type of news & activities are done by the
administrator where all people (viewers) can view and know all the relevant information about the
knowledge which they seek. This project is about the designing of a newspaper which displays the news
which a normal person wants to show. This portal is designed by using HTML, PHP, & CSS
technologies and SQL Server. The portal has basically three user parts where one is registered user
(authentication required) who can view, add comment can have general discussion with another user and
another is administrator (has an authentication) who will manage or control the website and other user
(no authentication required) can only view and search.
The following subsections of the Software Requirements Specifications (SRS) document provide an
overview of the entire SRS.

 Purpose
The main purpose of the project is intended to develop a portal for management of Web based news.
The portal provides a suitable and easy display for which large population around the world can learn or
will have the knowledge about the world. Basically this is a crowd sourcing newspaper. Online news
portal aims in digitalizing our daily life as it is used to keep us updated with all the daily news updates.
It provides us the detailed news alerts digitally so we can get rid of newspapers. This project has many
different features which are not available in normal online news websites. This provides Facility to users
to have discussions with others.

 Overview
The SRS is organized into two main sections. The first is The Overall Description and the second
is the Specific Requirements. The Overall Description will describe the requirements of the
WBNP from a general high level perspective. The Specific Requirements section will describe in
detail the requirements of the system.

 Definitions
SRS – Software Requirements Specification
WBNP – Web Based News Portal
End users – The people who will be actually using the system

2. Goal of Implementation
Online news portal is a digitalized system which helps users to get daily news alerts & updates online.
 Free of cost
 Get rid of newspapers
  Smart
 Area of interest
 Gives detailed view with photos & videos
 Provides facility to discuss

3. Functional Requirements

For documenting the functional requirements, the set of functionalities supported by the system
are to be specified. A function can be specified by identifying the state at which the data is to be
input to the system, its input data domain, the output data domain, and the type of processing to
be carried on the input data to obtain the output data. Basically the management parts are the
functional requirements which are uploading details, search topic, edit option and user
registration.

R1: Uploading Item

Description: Uploading function can be done by the user who has registered on the website.
When the user uploads an item and if it is a news item or forum is determined and edited by the
administrators or editors and then it is displayed on the home page. A registered user can also
add comment on other news as well.

R1.1: Select upload option.

Input: Upload item option.
Output: User will be prompted to enter the upload type.

R1.2: Select the type of item.

Input: Users option from one of the following
R1.2.1 News item
R1.2.2 Forum item
R1.2.3 Comment item
Output: User will be prompted to enter item details according to the above item.

R1.3: Check to display

Input: Check whether the item is visible for the masses.
Output: We will be prompted to display item.

R1.4: Display the item

Input: Edit the news item.
Output: The item is displayed on the screen.

Processing: It is controlled by the editor and which checks whether the uploaded item is fit for
the mass or not if it is then it display on screen if not then it is edited to make it visible for the
mass then display on the screen of the website.
R2: Search topic
Description: Search function does not require any authentication from its user so any user can
perform this function. If an user searches for a news item then the news will be displayed on the
screen if it related to the search topic.
R2.1: Select search option
Input: Search option.
Output: User will be prompted to enter the search topic.

R2.2: Check for the search topic

Input: Checks for the search topic related item.
Output: We will be prompted to display the items.

R2.3 Display the item

Input: Enter topic related to item.
Output: Display the item.

Processing: It checks for any item related to the search topic and displays it on the screen and if
there is no item related to the topic is present then it will pop as no related item.

R3: Edit topic

Description: Edit function can be done by only administrator or editor. Any uploaded item is
examined and edited by administrator so it can be allowed to display to mass.

R3.1: Select edit option

Input: Edit option.
Output: User will prompt to edit the uploaded item.

R4: User registration

Description: Registration is allowed to the users who are not registered yet (unregistered users)
and completion of this function they can also upload items.

R4.1: Select register option

Input: Register option.
Output: User will prompt to write a user name, email id, and password.

R4.2: Check for validity

Input: Checks whether any other registered users have same information.
Output: We will be prompted to register successfully if it has different information or else it’s
rejected.

Processing: It checks if the information submitted about the new user is similar to any other
registered user if yes it rejects the user information if no then new user will be registered
successfully.
4. Non-functional Requirements
These are the requirements that are not functional in nature. Especially these are the constraints
the system must work within.

 Performance Requirements: The system response time must be less than 30 seconds for
the user interface. Or else the system will show TIMED OUT.
 Reliability Requirements: The system shall have a minimum uptime of 99 % excluding
time pre-scheduled for maintenance and/or upgrades.
 Safety Requirements: All the system data must be backed up every day and the backup
copies stored in another server at different location for disaster recovery.

Quality Attributes: The source code for the system is well documented for ease of maintenance
and upgrading the system in future.

External Interfaces

The Web Based News Portal will use the standard input/output devices for a personal computer. This
includes the following:
 Keyboard
 Mouse
 Monitor
 Printer

Software Interfaces
The system shall interface with any Web Browser easily and on any Operating System like mac, android
and Microsoft etc.

Hardware Interfaces
The system shall run on any smart devices like laptop, pc, mobile, tablet etc.

5. Behavioral description

Design Constraints
The WBNP System shall be a stand-alone system running in a any of environment like Microsoft,
android, mac etc. The system shall be developed using HTML,PHP,CSS and SQL database.

Availability
The system shall be available 24 hours 7 days of week.
Security
Admin and User both will be able to log in to the Web Based News Portal System. User will have access
to the systems for reading and gathering information from it and Admin will have access to the system
for upload things as well as changing phase in systems. Access to the various subsystems will be
protected by a user log in screen that requires a user name and password.

Maintainability
The Web Based News Portal System is being developed in Html, PHP, CSS and SQL database. SQL is
best database and html is also easy layout so it shall be easy to maintain system.

Portability
The Web Based News Portal System shall run in any Microsoft Windows, Apple Mac or any Android
system like Desktop, Laptop, Tablet or Mobile Device etc.
 Practical: 3

AIM: Decide which process model to be used for development. Process model description
& why this model suitable for your project.

DESCRIPTION:
Incremental Model

In incremental model the whole requirement is divided into various builds. Multiple development cycles
take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller,
more easily managed modules. Incremental model is a type of software development model like V-
model, Agile model etc.

In this model, each module passes through the requirements, design, implementation and testing phases.
A working version of software is produced during the first module, so you have working software early
on during the software life cycle. Each subsequent release of the module adds function to the previous
release. The process continues till the complete system is achieved.

Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
  Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it’d iteration.

Disadvantages of Incremental model:

 Needs good planning and design.

 Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
 Total cost is higher than waterfall.

When to use Incremental model

 This model can be used when the requirements of the complete system are clearly defined and
understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

Why is this model suitable for my project?

 In our project the basic requirements are clear so we can develop a basic software.
 First only a basic online web portal for news will be delivered
 Then with time new modules will be added according to the feedback.
 With time there will not be much changes in the requirements for the system so there is no
problem in using this model.
 PRACTICAL: 4

AIM: Construct SPMP document for your project. Decide effort estimation for project.
OBJECTIVE: To specify the project plan and cost estimation to develop the Online News Portal
System.
DESCRIPTION: This SPMP document outlines a brief plan about how project is to be shaped.

Software Project Management Plan for Online News portal

Preface

The purpose of this document is to specify the project plan to develop the Online News Portal System.
This document outlines a brief plan about how project is to be shaped and also includes the milestones
and deliverables. This document will serve as guide for developers, developing the project. Updates of
this document will serve to record the progress of the project.

1. Introduction:

A) Objectives
The main purpose of the project is intended to develop a portal for management of Web based news.
The portal provides a suitable and easy display for which large population around the world can learn or
will have the knowledge about the world. Basically this is a crowd sourcing newspaper. The idea is
anyone can send a news item using their web based
Gadget which is managed by administrator to whom the editor’s panel kept in charge for this to make it
visible for the masses. This portal is developed using HTML, PHP & CSS technologies and SQL Server.

B) Major Functions
The development of portal for web based newspaper generally means creating a website in which the
management of all news item sent by crowd about any type of news & activities are done by the
administrator where all people (viewers) can view and know all the relevant information about the
knowledge which they seek. This project is about the designing of a newspaper which displays the news
which a normal person wants to show. This portal is designed by using HTML,
PHP, & CSS technologies and SQL Server. The portal has basically three user parts where one is registered
user (authentication required) who can view, add comment can have general discussion with another user
and another is administrator (has an authentication) who will manage or control the website and other user
(no authentication required) can only view and search.
The website consists of basic pages from which the user can view and know the relevant
Information like history, upcoming. In other case, the administrator manages all the relevant
Actions for which the users can view properly and also make reports.

C) Performance Issue
The major issue is to deliver a complete whole portal which is not possible within little time and with RAD
model so deliverables are broken down in the project plan into smaller deliverables and activities.
Factors critical in deciding the performances of the software are:
Internet Connection
Being predominantly a web based application, fast internet connection is necessity. Slow
connections may hamper performance.

Server performance
Performance may also be hampered by excessive net traffic.

D) Management and technical constrains

 The project should be completed within specified time period including Planning,
Designing, Development, Testing and Deployment.
 The project should be completed within specified budget.
 The Requirement Traceability Matrix (RTM) should be correlated and completed.
 All the Entry and Exit criteria of all the stages should met.
 The product should be user-friendly, reliable and should maintain the industry standards
without compromising the quality.
 The system architecture and design should be open and in a standard way such that
additional functionalities can be added later without much effort.
 Database designed should me normalized.
 Transfer of rupees for booking tickets should be done through secured connection.
2. Project Estimates:

Estimation technique for project

COCOMO (Constructive Cost Estimation Model) was proposed by Boehm 1981. Boehm postulated that
any software development project can be classified into a one of the following categories based on
development complexity: organic, semidetached and embedded. In order to classify a product into the
identified categories, Boehm requires us to consider not only the characteristics of the product but also
of the development team and the development environment. Roughly speaking, the three product classes
correspond to application, utility and system programs, respectively. Normally data processing programs
are considered to be application programs. Compilers, linkers etc. are utility programs. Operating
systems and real time system programs etc. are system programs. System programs interact directly with
the hardware and typically involve meeting timing constraints and concurrent processing.

Also the utility programs are three times as difficult to write as application programs and, system
programs are roughly three times as difficult as utility programs. Thus, the relative levels of product
development complexity for the three categories (application, utility and system programs) of products
are 1:3:9.

Boehm’s [1981] definitions of organic, semidetached and embedded systems are elaborated as follows:

1. Organic: We can consider a development project to be of organic type, if the project deals with
developing a well understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar types of projects.
2. Semidetached: The project can be considered of this type is the development team consists of a
mixture of experienced and inexperienced staff. Team members may have limited experience on
related systems but may be unfamiliar with some aspects of the system being developed.
3. Embedded: The project can be considered of this type, is the software being developed is
strongly coupled to complex hardware, or if stringent regulations on the operational procedures
exist. Here we have chosen the embedded model since all the team members are new in the field
of the software development and also the software product size is relatively small.
Estimation of Development Efforts
1. Organic model:
Efforts=2.4(KLOC) 1.05 Person-Months
2. Semi-Detached Model:
Efforts=3.0(KLOC) 1.12 Person-Months
3. Embedded Model:
Efforts=3.6(KLOC) 1.20 Person-Months

Estimation of Development Time

1. Organic model:
Efforts=2.4(KLOC) 1.05 Person-Months
2. Semi-Detached Model:
Efforts=3.0(KLOC) 1.12 Person-Months
3. Embedded Model:
Efforts=3.6(KLOC) 1.20 Person-Months

Cost and Effort Calculation:

Efforts:
=3.6(KLOC) 1.20
=3.6(1)1.20
=3.6
=4 Person-months (approx.)

Time Duration:
=2.5(Efforts) 0.32
=2.5(4)0.32
=2.5(1.5583)
=3.895
= 4 months
3. Schedule:
(A) Work breakdown structure
In order to execute the task successfully we need to follow the work break down structure.

Work Breakdown Structure

A work breakdown structure can be defined as dividing the whole project into individual
components in a hierarchical structure. The breakdown structure defines tasks that can be
completed independent of other tasks, resource allocation and assigning the responsibilities of
resources in the project.

Online News Portal System:

a. Description
i) Brief of project
ii) Define stakeholders
b. Achieve goal
i) Scope
ii) Requirements
iii) Research
iv) Explore
v) Consult
vi) Concept development
vii) Plan
c. Design
i) Develop OHS regulation
ii) Human resource
iii) Budgeting
iv) Finalize
v) Approval of budget
vi) Approval of plan
vii) Re-approval in requirement
d. Implementation
i) Coding
ii) Unit testing
e. Testing
i) Final commotion
ii) Testing phase 1
iii) Testing phase 2
f. Installation and deployment
i) installation
g. Evaluation
i) Review
ii) Feedback
iii) Report
 Online News Portal System

Description Goal Implementation Installation Evaluation

Design Testing

-Install -Review
-Brief of S -Scope -Developing -Coding -Final
Project. Commotion
- -Human
Requirem -Deployment -Feedback
ents resource -Unit Testing
-Define -Testing 1
Stakeholders -Research -Budgeting
- Testing-2 -Report
E -Explore -Finalize

-Consult Approvalof

A) Gantt Chart
4. Project resources:
A) People
The Stakeholders
Team leaders
The Software Team
Agile Team (Implementer)
Co-ordination and Communication Issues.

B) Hardware and Software Requirements

Software Interfaces
The system shall interface with any Web Browser easily and on any Operating System like mac,
android and Microsoft etc.

Hardware Interfaces
The system shall run on any smart devices like laptop, pc, mobile, tablet etc.
*The minimum hardware requirements are
Server side:
Processor: Intel i5 and above
Memory: 4GB RAM
Client side:
Processor: Above of Pentium 4
Memory: 2 GB RAM

*The minimum software requirements are

Server side:
As web application is designed in Php, Wamp server must be installed on server side. For
database purpose MySql will be used.
Client side:
This is being a web application a browser must be installed on the users system. The browser
should be anyone of the following:
Internet Explorer,
Mozilla Firefox,
Chrome,
Adobe flash.

C) Special Resources
 For developing this application the resources being used are:
 Php
 Wamp server
 MySql
 Dreamweaver (Designing Webpages)

5. Staff Organization:

Team Structure

Democratic team structure is used, as the name implies there is no project manager. All are
treated as team leaders and all of them can give any suggestions for the project development.
Everyone is given equal rights for making and giving changes which are beneficiary for the
project.
Democratic organization leads to higher morale and job satisfaction. Consequently, it suffers
from less man-power turnover.
As team is of less than 5 engineers, democratic team structure is suitable for project and for
research-oriented projects.

6. Risk Management:

A) Risk Analysis:

1) Product Size Risks

 Estimated size of product in number of programs, files, transactions
 Size of database created or used by the product.
 Number of projected changes to the requirements for the product before delivery and after
delivery.

2) Business Risks
 Amount and Quality of product documentation that must be produced and delivered to the
customer.
 Delivery deadlines
 Costs associated with late delivery and defective product.

3) Client Risks
 Communicating with developers
  Will customer agree to spend time in formal requirements gathering meetings to identify project
scope.
 When working for the first time

4) Resource Risks
 Number of Resources and skillsets

5) Technology Risks
 Requirements put excessive performance constraints on the product
 Customer demanding new technology.

B) Risk identification:
 Risks with respect to the work to be done
 Miscommunication
 Time out
 Design errors
 Illness or absence of team members
 Server crash

 Risks with respect to the management

 Illness or sudden absence of the project manager
 Risks with respect to the resources
 Unavailability of the technical advisor when needed
 Risks with respect to the customer.
 The customer changes his mind about the requirements
 The customer is not available when needed
The Risk Manager is responsible for identifying risks and monitor risk. After identifying Risk Manager
Need to solve problem by replace old system with new one. If need arise Risk Manager should modify,
delete and add information to the database.

C) Risk Estimation:
-Risk estimation also called risk projection, attempts to rate each risk in two ways:
 The likelihood or probability that the risk is real.
  The consequences (i.e. effect or result) of the problems associated with the risk, should it
occur.
-The project planner, along with other managers and technical staff, performs four risk projection
activities:
 Establish a scale that reflects the supposed likelihood of a risk
 Describe the consequences of the risk,
 Estimate the impact of the risk on the project and the product,
 Note the overall accuracy of the risk projection so that there will be no misunderstanding
-The intent of these steps is to consider risks in a manner that leads to prioritization. By prioritizing
risks, the team can allocate resources where they will have the most impact.

7) Project Tracking & Control Plan:

The monitoring of progress is done by the Project Manager using the following means:
 Weekly Project Group Meetings
 Progress Meetings
 Project metrics
 Team leader meetings
Project cost will be tracked by counting manpower, number of resources needed, wages given to staff,
etc. As per the schedule all the activities will be performed on time and frequency of report structure
should be as per the standards of the organization and meeting structure would be frequently so that
team members get to know where they are standing right now and can plan further meetings. After each
task audit will be there so that team members get to know errors and fault of the system, after that they
will recover it as soon as possible.

8.Miscellaneous plan:
A) Quality assurance plan
Quality Assurance Quality assurance plan includes the techniques to test the quality of the current
product. Again acceptance tests are used to see if the components are working properly when they are
brought together. Additionally, performance tests will be used to see the overall quality in terms of
efficiency. Results of these tests are considered frequently and these tests are run daily. If any
improvement is needed already implemented parts will be improved before going on to other parts.

B) Configuration Management plan

This part of the SPMP contains the configuration management plan for the software project, to include
the methods that will be used to provide configuration identification, evaluation, and release
management. Configuration identifications are done according to the needs of the customer. Similarly,
evaluation is also done with customer but in-team evaluations are also done as frequently as possible.
Releases are done as big milestones are achieved. They are scheduled above. Change requests are
analyzed during development phases and schedule is updated accordingly. Possible changes might result
in missed deadlines. Therefore these observations are done during development frequently.

C) Validation & verification

Verifications are done first via various tests like unit tests and acceptance tests. These will ensure us that
we do the right thing. Similarly, verification is done between team members in weekly meetings.
Validation is done with the help of customer. There will be weekly meetings with the customer to
validate the parts that is developed. Demos are done for this purpose. At each meeting the milestones
that are met is showed to the customer and current status of the development is said to him.

D) System Testing plan

• Recovery testing (fault tolerant)

• Security testing
• Stress testing (volume, resources)
• Performance testing (real-time, embedded system)

Acceptance Testing
• Alpha test: at the developer’s site, controlled environment
• Beta test: at one or more customer site.
 E) Delivery, introduction, maintenance plan

After processing through all phases of the system development life cycle, the portal is developed. In future it
will be hosted on the internet server which will be accessed by all people in the world and can view the site
and learn as much as news and information about the world. The Administrator or editor who will be
assigned for editing or managing or controlling will be given the secure login information and will change or
modify the website as per the requirements.
Also in future we can add more features to support iPods, iphone and other electronic devices.
 Practical: 5

AIM: Perform modelling for your project. Draw DFD using function oriented approach.

DESCRIPTION:

DESIGN
Design phase deals with transforming the requirements, as described in the SRS document, into a
form that is implemented using a programming language. The various designs of this system are
shown as following:

Data Flow Diagram:

Data Flow diagram is a graphical representation of flow of data throughout the information
system. Data flow diagrams illustrate how data is processed by a system in terms of inputs and
outputs.

Name Notation Role

Process Transforms incoming data flow to output

data flow.

Data Store Repositories of data in the system.

Dataflow Dataflow are pipelines through which

packets of information flow.

External Entity External entities are objects outside the

system, with which the system
communicates.
CONTEXT DIAGRAM
LEVEL-0 DFD
LEVEL-1 DFD
 Practical: 6

AIM: Prepare uml modeling using object oriented approach. (Class, object, sequence,
collaboration, activity, state chart diagram)

DESCRIPTION:

1) E-R Diagram:
2) Use Case Diagram:
3) Class Diagram:
4) Sequence Diagram:
5) State Diagram:
6) Activity Diagram:
 PRACTICAL: 7

AIM: Understand cocomo model with suitable example. Also decide cost estimation of your project.

OBJECTIVE: Cost estimation of the project

DESCRIPTION:
• The Constructive Cost Model (COCOMO) is the most widely used software estimation model
in the world. It

• The COCOMO model predicts the effort and duration of a project based on inputs relating to
the size of the resulting systems and a number of "cost drives" that affect productivity.

• Effort Equation

• PM = C * (KDSI)n (person-months)

• Where PM = number of person-month (=152 working hours),

• C = a constant,

• KDSI = thousands of "delivered source instructions" (DSI) and

• N = a constant.

• Productivity equation

• (DSI) / (PM)

• Where PM = number of person-month (=152 working hours),

• DSI = "delivered source instructions"

• Schedule equation

• TDEV = C * (PM)n (months)

• Where TDEV = number of months estimated for software development.

• Average Staffing Equation

• (PM) / (TDEV) (FSP)

• Where FSP means Full-time-equivalent Software Personnel.

 • COCOMO is defined in terms of three different models:

• The Basic model,

• The Intermediate model, and

• The Detailed model.

• The more complex models account for more factors that influence software projects, and make
more accurate estimates.

• The most important factors contributing to a project's duration and cost is the Development
Mode

• Organic Mode: The project is developed in a familiar, stable environment, and

the product is similar to previously developed products. The product is relatively
small, and requires little innovation.

• Semidetached Mode: The project's characteristics are intermediate between

Organic and Embedded.

• The most important factors contributing to a project's duration and cost is the Development
Mode:

• Embedded Mode: The project is characterized by tight, inflexible constraints

and interface requirements. An embedded mode project will require a great deal
of innovation.

Calculation for the project:

Method used: Basic Cocomo model:
The Basic COCOMO model computes effort as a function of program size. The Basic COCOMO
equation is:
 E = aKLOC^b

Effort for three modes of Basic COCOMO

Estimation of Development Efforts

1. Organic model:
Efforts=2.4(KLOC) 1.05 Person-Months
2. Semi-Detached Model:
Efforts=3.0(KLOC) 1.12 Person-Months
3. Embedded Model:
Efforts=3.6(KLOC) 1.20 Person-Months
Estimation of Development Time
1. Organic model:
Efforts=2.4(KLOC) 1.05 Person-Months
2. Semi-Detached Model:
Efforts=3.0(KLOC) 1.12 Person-Months
3. Embedded Model:
Efforts=3.6(KLOC) 1.20 Person-Months

Cost and Effort Calculation:

Efforts:
=3.6(KLOC) 1.20
=3.6(1)1.20
=3.6
=4 Person-months (approx.)

Time Duration:
=2.5(Efforts) 0.32
=2.5(4)0.32
=2.5(1.5583)
=3.895
= 4 months
 PRACTICAL: 8

AIM: Understand function point. Analyze the case study. Identify error & solve it.

OBJECTIVE: To study function point & try to solve the error if any.

DESCRIPTION:
A function point is a "unit of measurement" to express the amount of business functionality
an information system (as a product) provides to a user. Function points are used to compute
a functional size measurement (FSM) of software. The cost (in dollars or hours) of a single
unit is calculated from past projects.

Measure size in terms of the amount of functionality in a system. Function points are
computed by first calculating an unadjusted function point count (UFC).

Counts are made for the following categories

 External inputs – those items provided by the user that describe distinct application-
oriented data (such as file names and menu selections)
 External outputs – those items provided to the user that generate distinct application-
oriented data (such as reports and messages, rather than the individual components of
these)
 External inquiries – interactive inputs requiring a response
 External files – machine-readable interfaces to other systems
 Internal files – logical master files in the system

Multiply each number by a weight factor, according to complexity (simple, average or

complex) of the parameter, associated with that number. The value is given by a table:

 Calculate the total UFP (Unadjusted Function Points)

 Calculate the total TCF (Technical Complexity Factor)
 Sum the resulting numbers to obtain DI (degree of influence)
 TCF given by the formula: TCF=0.65+0.01*DI
Function Points are by given by the formula: FP=UFP*TCF
Case Study:
The spell checker accepts as input a document file & an optional personal dictionary file.
The checker lists all words not contained in either of these files. The user can query the
number of words processed & the number of spelling errors found at any stage during
processing.

User inputs: Document file name, personal dictionary name

User outputs: Fault report, word count, report on inappropriate content
User requests: #treated words, #found errors
Internal file: Dictionary
External file: Document file, personal dictionary

UFP = (4 * 2) + (5 * 3) + (4 * 2) + (10 * 1) + (7 * 2) = 55

Technical complexity factor = 3 + 0 + 4 + 0 + 3 + 3 + 3 + 3 + 0 + 3 + 3 + 5 + 3 + 3

= 30 (Degree of influence)

FP = UFP * (0.65+0.01 * DI)

= 55 * (0.65 + 0.01 * 30)
= 52.25

Therefore, FP is 52.25.
 PRACTICAL: 9

AIM: Understand Cyclometric complexity for coding. Analyze the case study.

OBJECTIVE: To study complexity & analyse the case study.

DESCRIPTION:

Cyclomatric complexity is a software metric (measurement), used to indicate the

complexity of a program. It is a quantitative measure of the number of linearly independent
paths through a program's source code. It was developed by Thomas J. McCabe, Sr. in 1976.
Cyclomatric complexity is computed using the control flow graph of the program.
One testing strategy, called basis path testing by McCabe who first proposed it, is to test
each linearly independent path through the program.

Definition:

The cyclomatric complexity of a section of source code is the number of linearly

independent paths within it. For instance, if the source code contained no control flow
statements (conditionals or decision points), the complexity would be 1, since there would be
only a single path through the code. If the code had one single-condition IF statement, there
would be two paths through the code: one where the IF statement evaluates to TRUE and
another one where it evaluates to FALSE, so the complexity would be 2. Two nested single-
condition IFs, or one IF with two conditions, would produce a complexity of 4.
Mathematically, the cyclomatric complexity of a structured program is defined with
reference to the control flow graph of the program, a directed graph containing the basic
blocks of the program, with an edge between two basic blocks if control may pass from the
first to the second. The complexity M is then defined as
M = E – N + 2P

Where,
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components
For a single program (or subroutine or method), P is always equal to 1. So a simpler formula
for a single subroutine is:
M=E–N+2

Applications:
Determining the number of test cases that are necessary to achieve thorough test coverage of
a particular module.

It is useful because of two properties of the cyclomatic complexity, M, for a specific module:

 M is an upper bound for the number of test cases that are necessary to achieve a
complete branch coverage.
 M is a lower bound for the number of paths through the control flow graph (CFG).
Assuming each test case takes one path, the number of cases needed to achieve path
coverage is equal to the number of paths that can actually be taken.

All three of the above numbers may be equal:

branch coverage cyclomatic complexity number of paths.

CASE STUDY:
consider a program that consists of two sequential if-then-else statements:

if( c1() )
f1();
else
f2();

if( c2() )
f3();
else
f4();

In general, in order to fully test a module all execution paths through the module should be
exercised. This implies a module with a high complexity number requires more testing effort
than a module with a lower value since the higher complexity number indicates more
pathways through the code. This also implies that a module with higher complexity is more
difficult for a programmer to understand since the programmer must understand the different
pathways and the results of those pathways.
In this example, two test cases are sufficient to achieve a complete branch coverage, while
four are necessary for complete path coverage. The CC of the program is 3 (as the strongly
connected graph for the program contains 9 edges, 7 nodes and 1 connected component) (9-
7+1).

Unfortunately, it is not always practical to test all possible paths through a program.
Considering the example above, each time an additional if-then-else statement is added, the
number of possible paths doubles. As the program grew in this fashion, it would quickly
reach the point where testing all of the paths was impractical.
 PRACTICAL: 10

AIM: Study of Open Source Software/learning for implementation of project.

OBJECTIVE: To study Open Source Software.

DESCRIPTION:

Open-source software (OSS) is computer software with its source code made available with
a license in which the copyright holder provides the rights to study, change, and distribute
the software to anyone and for any purpose. Open-source software is the most prominent
example of open-source development.
A report by the Standish Group (from 2008) states that adoption of open-source software
models has resulted in savings of about $60 billion per year to consumers.
The Open Source Initiative's (OSI) definition is recognized as the standard or de
facto definition. With about 20 years of evidence from case histories of closed and open
development already provided by the Internet, OSI continued to present the "open source"
case to commercial businesses. They sought to bring a higher profile to the practical benefits
of freely available source code, and wanted to bring major software businesses and other
high-tech industries into open source.
OSI uses The Open Source Definition to determine whether it considers a software license
open source. The definition was based on the Debian Free Software Guidelines, written and
adapted primarily by Perens.

Advantages & Disadvantages:

 The main advantage for business is that open source is a good way for business to
achieve greater penetration of the market. Companies that offer open source software
are able to establish an industry standard and, thus, gain competitive advantage.
 It has also helped to build developer loyalty as developers feel empowered and have a
sense of ownership of the end product.
 Lower costs of marketing and logistical services are needed for OSS. OSS also helps
companies keep abreast of technology developments.
 The OSS development approach has helped produce reliable, high quality software
quickly and inexpensively.
  Besides, it offers the potential for a more flexible technology and quicker innovation.
It is said to be more reliable since it typically has thousands of independent
programmers testing and fixing bugs of the software.
 Moreover, free software can be developed in accord with purely technical
requirements. It does not require thinking about commercial pressure that often
degrades the quality of the software.
 It is sometimes said that the open source development process may not be well
defined and the stages in the development process, such as system testing and
documentation may be ignored. However, this is only true for small (mostly single
programmer) projects. Larger, successful projects do define and enforce at least some
rules as they need them to make the teamwork possible.
 Software experts and researchers who are not convinced by open source's ability to
produce quality systems identify the unclear process, the late defect discovery and the
lack of any empirical evidence as the most important problems (collected data
concerning productivity and quality).
 It is also difficult to design a commercially sound business model around the open
source paradigm. Consequently, only technical requirements may be satisfied and not
the ones of the market.
 In terms of security, open source may allow hackers to know about the weaknesses or
loopholes of the software more easily than closed-source software.

Comparison:
Proprietary Software:

The debate over open source vs. closed source (alternatively called proprietary software) is
sometimes heated.
The top four reasons (as provided by Open Source Business Conference survey) individuals
or organizations choose open source software are:

1. lower cost,
2. security,
3. no vendor 'lock in', and
4. better quality
Since innovative companies no longer rely heavily on software sales, proprietary software
has become less of a necessity. As such, things like open source content management
system—or CMS—deployments are becoming more commonplace.
Free Software:

The main difference is that by choosing one term over the other (i.e. either "open source" or
"free software") one lets others know about what one's goals are. As Richard Stallman puts
it, "Open source is a development methodology; free software is a social movement."
Critics have said that the term "open source" fosters an ambiguity of a different kind such
that it confuses the mere availability of the source with the freedom to use, modify, and
redistribute it. Developers have used the alternative terms Free/open source
Software (FOSS), or Free/Libre/open source Software (FLOSS), consequently, to describe
open source software which is also free software.
Open-source software and free software are different terms for software which comes with
certain rights, or freedoms, for the user. They describe two approaches
and philosophies towards free software. Open source and free software (or software libre)
both describe software which is free from onerous licensing restrictions. It may be used,
copied, studied, modified and redistributed without restriction. Free software is not the same
as freeware, software available at zero price.

Applications & Adoption:

 Widely used on every platform
 Widely used in business applications
 Extension of the term for non-software usage
 PRACTICAL: 11

AIM: Develop test case scenarios for your project.

OBJECTIVE: To study & develop test case scenario.

DESCRIPTION:

Testing phase is a very important for a successful system. In this phase before
implementing the new system into operation, for eliminating bugs a test run of the system
is done. After completing codes for the whole programs of the system, a test plan should
be developed and run one given set of test data.

Test Case: 1 Test Case Name: Register

System: Online News Portal Subsystem: Registration

Designed By: Keval Shah Design Date: March 02, 2017

Executed By: Priya Koladiya Execution Date: March 02, 2017

Short Description: Test case for user registration when all details are valid.

Pre-conditions: User must navigate to registration page.

Step Action Expected System Pass/Fail Comment

Response

User enters User clicks on User should be Pass

correct details Register button registered

Test Case: 2 Test Case Name: View News Page

System: Online News Portal Subsystem: News

Designed By: Keval Shah Design Date: March 03, 2017

Executed By: Priya Koladiya Execution Date: March 03, 2017

Short Description: Test case for displaying some news when the user goes to the page of a
specific topic

Pre-conditions: User must navigate to specific news topic.

Step Action Expected System Pass/Fail Comment

Response

User goes to News are shown News details like Fail

page writer’s list, their contact
number, etc. should be
shown.

Test Case: 3 Test Case Name: Login

System: Online News Portal Subsystem: Login

Designed By: Priya Koladiya Design Date: March 02, 2017

Executed By: Keval Shah Execution Date: March 02, 2017

Short Description: Test case for logging user in when credentials are valid.

Pre-conditions: User must navigate to login page.

Step Action Expected System Pass/Fail Comment

Response

User enters User clicks on User should be logged Pass

correct Login button in and session must be
credentials created

Test Case: 4 Test Case Name: Find Specific News

System: Online News Portal Subsystem: News Search

Designed By: Priya Koladiya Design Date: March 04, 2017

Executed By: Keval Shah Execution Date: March 04, 2017

Short Description: Test case for finding a specific news according to topic.
Pre-conditions: User must navigate to the website.

Step Action Expected System Pass/Fail Comment

Response

User must select User clicks on If any news article exists Pass
the topic from Find button for that topic, they
list of topics should be shown in a list
based on the search
criteria.

Test Case: 5 Test Case Name: Edit Profile

System: Online News Portal Subsystem: Profile

Designed By: Keval Shah Design Date: March 05, 2017

Executed By: Priya Koladiya Execution Date: March 05, 2017

Short Description: Test case for editing user profile with proper details.

Pre-conditions: User must be logged in, and navigated to Edit Profile page.

Step Action Expected System Pass/Fail Comment

Response

User edits User clicks on The new details must be Fail

profile and Edit Profile saved in the database
enters proper button and user should be
details shown the edit profile
page again with the new
details.
Test Case: 6 Test Case Name: Log Out

System: Online News Portal Subsystem: Log Out

Designed By: Priya Koladiya Design Date: March 07, 2017

Executed By: Keval Shah Execution Date: March 07, 2017

Short Description: Test case for logging a user out of the system.

Pre-conditions: User must be logged in.

Step Action Expected System Pass/Fail Comment

Response

User clicks on User must be logged out True

Log Out button of the system, session
should be destroyed,
and the homepage must
be shown
 PRACTICAL: 12
AIM: Identify number of independent path required for testing for your project.

OBJECTIVE: To study & develop independent testing path.

DESCRIPTION:
Path testing, a structured testing or white box testing technique used for designing test cases
intended to examine all possible paths of execution at least once. Creating and executing
tests for all possible paths results in 100% statement coverage and 100% branch coverage.

Step 1:

Draw the Flow Graph of the Function/Program under consideration as shown below:

1
Start

2
Search
News

10 Not
3 Connected
connected to
to Database
Database

9
Success
4 Result 5 Result
Not Found
Found 7
Bookmarked

8
Failure
6 Don’t
Bookmarked
Step 2:
Determine the independent paths:

Path 1: 1 – 2 – 3 – 4
Path 2: 1 – 2 – 3 – 5 – 6
Path 3: 1 – 2 – 3 – 5 – 7 – 8
Path 4: 1 – 2 – 3 – 5 – 7 – 9
Path 5: 1 – 2 – 10
 PRACTICAL: 13

AIM: Study various tools for testing. (Win runner & Load runner)

OBJECTIVE: To study win runner & load runner tools for testing.

DESCRIPTION:
Automated testing is becoming more & more important for many software projects in order
to automatically verify key functionality. Various areas in which automated testing tools are
used:
 Reviews, walkthroughs & inspection
 Regression testing, defect management, test management, etc
 Configuration control & version management

WinRunner:
As a functional test suite, it worked with HP QuickTest Professional & supported
enterprise quality assurance. It captured, verified and replayed user interactions
automatically, in order to identify defects & determine whether business processes worked
as designed. The software implemented a proprietary Test Script Language (TSL) that
allowed customization and parameterization of user input.
HP WinRunner was originally written by Mercury Interactive. Mercury Interactive was
subsequently acquired by Hewlett Packard (HP) in 2006. It is the most commonly used
automated testing tool.

Features:

1. Automatic Recovery: It is possible for the user to set up various operations that will
become activated if an exception event appears. The recovery manager will give you a
wizard that will allow you to set up a scenario for recovery.

2. Silent Installation: The unattended installation mode can be set.

3. Support For Various Environments: WinRunner includes support for Internet Explorer
6.x & Netscape 6.x, Windows XP & Sybase’s Power Builder 8, in addition to 30+
environments.
 4. Cost Effective: WinRunner provides the most powerful productive & cost-effective
solution for verifying enterprise application functionality.

5. Support For Multiple Data Combination: WinRunner has an ability to use numerous
data combinations for one test. The DataDriver Wizard has been designed for
automatic processing of large amount of data.

6. Multiple Verification: It can offer checkpoints for test, URL, GUI & databases this
provides ability to compare expected outcomes with real ones.

Load Runner:
HP Load Runner is a software testing tool from Hewlett-Packard. It is used to test
applications, measuring system behaviour & performance under load. HP Load Runner can
simulate thousands of users concurrently using application software, recording & later
analysing the performance of key components of the application.

Features:

1. It has excellent monitoring & analysis interface where tester can see reports easy to
understand coloured charts & graphics.

2. It uses C as a default programming language. However, it also supports other

languages like Java, & Visual Basic.

3. No need to install it on the server under test. It uses native monitors.

4. It has a support for most of the commonly used protocols.

5. It has GUI generated scripts which can be modified as per the requirements.

6. This tool can quickly point out the effect of the wide area network (WAN) on
application reliability, performance & response time.
 PRACTICAL: 14

AIM: Study open ended problems. (Design based)

DESCRIPTION:

Open Ended Questions

Open ended questions offer a suite of scenarios where you explore various skills that define a
good developer. These scenarios are really up to you and can include everything from data
modelling to application architecture to user interface design. Essentially, you simply tee up a
situation and see how the developer deals with the situation. There’s no right or wrong answer,
just good or bad discussions. More importantly, it requires solid communication- the ability to
understand and explain ideas- which is the cornerstone of a good developer.

Makeup of a Performance Problem

A performance problem could be caused by any number of things: a poorly designed

architecture, an underpowered CPU, limited network bandwidth, or a combination of several
factors. For example, a higher than expected load can easily overwhelm a system's resources.
However, a higher volume is not always required to uncover performance problems. Poorly
designed software that does not handle resource allocation and contention properly can easily
cause deadlocks that eventually lead to nefarious performance problems even at a normal load.

Regardless of what causes a performance problem in a web-based application, the first step in
resolving such a problem is to create a performance plan document—even if it is a short one.
When you put such a document together, you should identify and involve all the domain experts
relevant to the web-based application at hand.

Performance Strategy: Total Systems Approach

Performance troubleshooting of a web-based system, much like a mind-body healing, requires

a holistic approach. A web-based system is much more than just an application server, a few
thousand lines of code, a database, and a firewall. It is more than the sum of its parts. It is an
interconnected whole. Therefore, the most effective approach to solving a performance problem
is to take a total systems approach, a process where all parts of the application domain are
examined from the perspective of performance.

Why is it important, as a manager, or a lead engineer, to consider all the aspects of an

application? The foundation of any web system includes software, hardware and the network. A
short leg on any one of these three foundations can cause performance problems. A system's
performance is dependent as much on a well-tuned, well-configured network as it is on fast
computing hardware or well designed software architecture. Making your SQL statements more
efficient will not solve a performance problem caused by a lack of network bandwidth. Faster
computers will not solve a performance problem caused by a poorly configured routing table.
Replacing your current network with faster fiber optics will not solve a performance problem
caused by a lack of memory or an underpowered CPU.

How to Execute a Total Systems Approach

In an ideal world, you would catch and resolve all performance problems by load testing prior to
deployment. In the real world, however, the test and production environments are not always
identical. Even when the test and production environments are identical, a load test itself is only
an approximation of the real load the application will face in production. Therefore,
performance bottlenecks and slowdown issues often show up right after a new project is
deployed. The key is being able to resolve such performance problems efficiently without too
much guesswork and therefore avoiding losses in the deployment time and potential business
revenues. So it is important to plan ahead for performance problems.

If you are dealing with a new project, schedule time throughout the project development for
design reviews that focus on potential deadlock scenarios. While coding the application, think
about inserting key timing and trace information that may come in handy later when debugging
for performance issues. In addition, put together and involve a team of domain experts that will
be key in helping you resolve a future performance problem.

Should a performance problem surface, make sure you have a plan. As mentioned previously, it
is important that the plan be an overall performance resolution strategy where the effects of
software design changes are evaluated in conjunction with the systems network and the
underlying computing hardware. Although fancy tools and monitoring agents can be a great help
when faced with a performance problem, the central part of resolving a web-based performance
problem is a sharp-minded project manager or an experienced lead systems engineer with a good
knowledge of the systems domain and armed with the plan.
A Sample Strategy Guide: A Step-by-Step Approach

In the rest of this article we will outline a series of steps that you may use to help you solve a
crash or lockup problem.

1. Identify the problem:

o Classify the performance issue: crash, lockup, or slow-down. Why? Because each
scenario has specific symptoms that will give you specific hints as to the cause of
the problem.
o Repeat the problem If the problem only happens in the production environment
make a full effort to make it happen again on a controlled environment, like the
Quality Assurance (QA) or the development system. Why? Because being able to
repeat the problem will enable you to understand and test the problem. You can try
different cause and effect scenarios that will lead eventually to the actual cause of
the problem—not to mention avoiding using the production machine for
troubleshooting.
o Log key systems information Tracking vital signs of a system, such as its memory
usage, CPU utilization, and disk I/O performance, are always helpful in finding
out how efficient your system operates. Collect this information before and after
the problem occurs as this may give you some clues. You may need to turn
logging in for a while before the problem occurs. Therefore, watch out for the
system log getting too big. Don't forget to time stamp any information that you
log.
o Chart or graph all your data Use a spreadsheet package to display the data you
collect in order to understand the behavior of your system. Finding a visual pattern
in the occurrence of your performance problem is a key starting point.
o Look back at the latest system changes If the problem occurred suddenly,
backtrack your steps to see if that gives you any clues. Sometimes unforeseen or
undocumented simple changes could cause problems. For example, an unplanned
backup starting at midnight on a server machine dedicated to a specific application
process may well cause a poor response time as the server's CPU would be hogged
by the backup program.
o Start with the software changes first Begin your troubleshooting, if possible, with
software changes that could make the most impact, as the software in general is
for most part easier to change relative to hardware changes. ( Especially if you
have to order and install hardware.)
2. Include all parties involved: In an all-out systems approach you will need to include the
network team, the systems operation (systems administrators/database administrators
(DBAs)), the QA and the development teams. This has to happen at early stages of the
performance problem troubleshooting even if those parties may not have an active role at
the start.
3. Write down the strategic plan.
 o Look at the entire system first and then point to the component that is most likely
to buy you the largest bang for the buck when you optimize it.
o Avoid guesswork and make sure you look at the impact any changes you make on
other parts of the system.
o Write down a list of solution options and mark them as short-term or long-term
and see which one fits your case better.
o If you come across a situation that you cannot troubleshoot in the context of the
entire application, extract the key components and make a simple application. This
way you have easier time understanding the problem and easier time resolving it.
o Write down a backup plan in case your first set of solutions doesn't solve the
performance problem. (For example a complete system rebuild in case some parts
of your system was corrupted.)
4. Keep an accurate and detailed log of all the changes and all the steps taken. This
document becomes invaluable when you try multiple changes, as you want to minimize
your test scenarios and avoid the repeat of any previous step.

Conclusion

Performance is a system-wide issue that spans consideration over application software, network
system, and the underlying computing hardware. A solid performance strategy and a planned
effort coordinated with the operations staff, QA, development, and network systems domain
experts are key elements in resolving systems performance issues and creating an optimized and
well tuned web application. Since software changes are often the easiest to make, a good
approach would be to start with software code or software architectural changes first and then
later proceed to bigger and costlier changes to the network or the computing hardware systems.
 PRACTICAL: 15

AIM: Study various web based SE tools. (Software rational ROSE, SCM tools, SQA
tools)

OBJECTIVE: To study various web based SE tools.

DESCRIPTION:

Rational Rose:
Rational Rose XDE, an "eXtended Development Environment" for software developers,
integrates with Microsoft Visual Studio .NET & Rational Application Developer. The
Rational Software division of IBM, which previously produced Rational Rose, wrote this
software.
With the Rational June 2006 Product Release, IBM withdrew the “XDE” family of
products and introduced the Rational Rose family of products as replacements. The
Rational Rose family of products is a set of UML modelling tools for software design.
Rational Rose could also do source-based reverse engineering; the combination of this
capability with source generation from diagrams was dubbed roundtrip engineering.
The Rational Rose family allows integration with legacy integrated development
environments or languages. A 2003 UML 2 For Dummies book wrote that Rational Rose
suite was the "market (and marketing) leader".
The UML part was superseded by Rational Software Architect around 2006, with
Rational Rose becoming a legacy product. As of 2011, the ER modelling part
(Rational Rose Data Modeller) has been superseded by another IBM product— Rational
Data Architect. As of 2014 IBM still sells Rational Rose, listing Visual Studio &
Windows as compatible environment.
SCM Tools:
Software Configuration Management (SCM) is the task of tracking and controlling
changes in the software, part of the larger cross-disciplinary field of configuration
management. SCM practices include revision control & the establishment of baselines. If
something goes wrong, SCM can determine what was changed & who changed it. If a
configuration is working well, SCM can determine how to replicate it across many hosts.
The acronym "SCM" is also expanded as source configuration management process and
software change & configuration management. However, "configuration" is generally
understood to cover changes typically made by a system administrator.
The goals of SCM are generally:

• Configuration identification - Identifying configurations, configuration items &

baselines.
• Configuration control - Implementing a controlled change process.
• Configuration status accounting - Recording and reporting all the necessary
information on the status of the development process.
• Configuration auditing - Ensuring that configurations contain all their intended parts
and are sound with respect to their specifying documents, including requirements,
architectural specifications and user manuals.
• Build management - Managing the process and tools used for builds.
• Process management - Ensuring adherence to organization's developing process.
Environment management - Managing software & hardware that host the system.
• Teamwork - Facilitate team interactions related to the process.
• Defect tracking - Making sure every defect has traceability back to the source.
SQA Tools:
(1) qTest:
Developed by QASymphony, qTest is the only test management solution that allows you
to manage your manual, exploratory, and automated testing in a single location, providing
the most complete view of your testing coverage and progress on the market. With the
help of qTest Connector, it has seamless integrations with JIRA for an entire end-to-end
QA solution – but that is not all, it also integrates with other tools like Bugzilla, FogBugz,
Rally, VersionOne etc.

(2) PractiTest:
An entirely SaaS end-to-end QA and Agile friendly Test management tool. Using their
unique and customizable filters you can efficiently organize your requirements, create
and run tests, track bugs and generate reports using this tool. It integrates seamlessly with
leading bug tracking tools like JIRA, Pivotal tracker, Bugzilla, and Redmine as well as
various automation tools such as Selenium, Jenkins etc.
However, their API can ensure further customizing for your process’ needs. It is not
open sourced but is quite affordable. You can benefit from their human methodological
support throughout your usage.

(3) HP ALM/Quality Center:

HP QC has been one of the most used test management software for many years. It has
all the features necessary and in many ways, it is the standard against which the other
tools are measured. Even though it is one of the high-end tools, economically, it still
remains to be very popular.

(1) Gemini:
One of the key components of this tool is supporting ‘Testing & QA’ along with the other
aspects like Project Planning, issue tracking etc. Using this tool, you could create test
plans, test cases, test runs, traceability, test run reports etc. There are also various
integrations and extensions available.

There are many more web based software testing & QA tools like QMetry, Testuff,
TestLogde, etc.