Home Automation System

Published on June 2016 | Categories: Types, Presentations | Downloads: 31 | Comments: 0 | Views: 463
of 48
Download PDF   Embed   Report

Home Automation System

Comments

Content

1

CONTENTS

S. No

Name of the Experiment

Page No

1

Project Planning

9

2

Software Requirement Analysis

13

3

Data Modeling and Implementation

18

4

Software Testing

26

5

Software Debugging

32

6

Database design

7

Screen Shots

2

List of Experiments

1) Project Planning
2) Software Requirement Analysis
3) Data Modeling and Implementation
4) Software Testing
5) Software Debugging

3

An Overview of Software Engineering
Definition of software engineering:


Software Engineering is the field of computer science dealing
with the building of
software systems, which are so large or so complex that they are
build by a team
or teams of engineers.
 Software Engineering can be defined as “the application of engineering to
software”.
 IEEE definition:
The application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software.
The role of software engineering in system design:




A software system is often a component of a much large system. Therefore, the
software engineering activity is a part of a much large system design activity.
o For example, a telephone-switching system. It consists of computers,
telephone lines and cables, telephones, software to control the various
components, and so on.
Software is being increasingly embedded in various systems.
o The software engineer is required to participate in developing the
requirements for the whole system.
o The software engineer is required to understand the application area before
thinking of developing software.

The relationship of software engineering to other area of computer
Science:






Programming language
o Central tools used in software development
o Having influenced how well we can achieve our software engineering
goals
Operating systems
o Software should usually run on a specific operating system.
o Need to consider if the software can work well with a specific operating
System.
Database
o Databases allow applications to be written that use data without worrying
about the underlying representation of the data.
o Allow database systems to be used as components of large software

4

Systems.





Artificial intelligence
o Some researchers have been trying to apply artificial-intelligence
Techniques.
o To improve software engineering.
Theoretical models
o A number of models developed by theoretical computer science have
become useful tool in software engineering.

The software life cycle:
 Software is said to have a life cycle composed of several phases.
 Traditional life cycle:
o waterfall model
Each phase has well-defined starting and ending points, with clearly
identifiable deliverables to the next phase
 A sample waterfall life cycle model:
o Requirements analysis and specification:
 Usually the first phase of a large-scale software development
Project.
 Purpose of this phase is to identify and document the exact
requirements for the system
o System design and specification:
 Software engineers design a software system to meet requirements.
 Sometime split into two sub-phases.
 Architectural design: entails defining the overall
organization of the system in terms of high-level
components and interactions.
 Detailed design: components are decomposed into lower
level modules with precisely defined interfaces.
o Coding and module testing:
 The engineer produces the actual code that will be delivered to the
customer as the running system
 Individual modules developed in the coding phase are tested before
being delivered to the next phase.
o Integration and system testing:
 All the modules having been developed before and tested
individually are put together-integrated-in this phase and are tested
as a whole system.
o Delivery and maintenance:

5

 Once the system passes all
the tests, it is delivered to the customer
and enters the maintenance phase. All modifications made to the
system after the initial delivery are usually attributed to this phase.

• Evolutionary models:
 Evolutionary model divides the development cycle into smaller,
incremental waterfall models in which users are able to get access to
the product at the end of each cycle.
 The users provide feedbacks on the product for the planning stage of
the next cycle and the development team responds according to these
feedbacks.
 Benefits:
o From a business perspective
 Significantly reducing the risk in software projects
by breaking the project into smaller, manageable
pieces and by increasing the visibility of the
management team in the project.

6



Spiral Model
o The goal of spiral model is to provide a framework for designing such
processes, guided by the risk levels in the project at hand
o It can accommodate any process development model. By using it as a
reference, one can choose any model that is the most appropriate, for
example,waterfall model. The principal behind such a choice is the
level of risk.
o The main characteristic is that it is cycle each cycle consists of
four stages:

o The main characteristic is that it is cycle
o Each cycle consists of four stages:

7

Stage 1:
o Identifying the objectives of the portion of the product under
consideration, in terms of qualities to achieve
o Identifying alternatives, for example: if to buy or to reuse any
software
o Identifying constraints on the application of the alternatives
Stage 2:
o Evaluating the alternatives identified in stage 1.
o Identifying and dealing with the potential risk areas.
Stage 3:
o Developing and verifying the next-level product.
Stage 4:
o Reviewing the results of the stages traversed so far and
planning for the next iteration of the spiral.

8

1

PROJECT PLANNING

Objective:
To gain understanding of plan and learn how to prepare them.

Background:
Project management is the process of planning and controlling the development
of a system within a specified timeframe at a minimum cost with the right functionality.

Study:
Project planning is part of project management, which relates to the use of schedules
such as Gantt charts to plan and subsequently report progress within the project
environment.
Project Work Plan
Prepare a list of all tasks in the work breakdown structure, plus:
 Duration of task.
 Current task status.
 Task dependencies.
 Key milestone dates.
Tracking Progress:
 Gantt Chart:
o Bar chart format.
o Useful to monitor project status at any point in time.
 PERT Chart:
o Flowchart format.
o Illustrate task dependencies and critical path.
Risk Management:
 Risk management is concerned with identifying risks and drawing up plans to
minimize their effect on a project.
 A risk is a probability that some adverse circumstance will occur.
 Project risks which affect schedule or resources.
 Product risks which affect the quality or performance of the software being
developed.
 Business risks which affect the organization developing the software.

Risk Management Process:

9






Risk identification: identify project, product and business risks.
Risk analysis: assess the likelihood and consequences of these risks.
Risk planning: draw up plans to avoid or minimize the effects of the risk.
Risk monitoring: monitor the risks throughout the project.

Project Planning A Step by Step :
Step 1: Project Goal:
A project is successful when the needs of the stakeholders have been met. A
stakeholder is anybody directly or indirectly impacted by the project.
Step 2: Project Deliverables:
Using the goals you have defined in step 1, create a list of things the project needs to
deliver in order to meet those goals. Specify when and how each item must be delivered.
Step 3: Project Schedule:
Create a list of tasks that need to be carried out for each deliverable identified in step2.
For each task identify the following:
 The amount of effort (hours or days) required to complete the task
 The resource who will carryout the task
Step 4 :Supporting Plans


Human Resource Plan
Identify by name the individuals and organisations with a leading role in the
project. For each describe their roles and responsibilities on the project.



Communications Plan:
Create a document showing who needs to be kept informed about the project and
how they will receive the information.



Risk Management Plan
Risk management is an important part of project management. Although often
overlooked, it is important to identify as many risks to your project as possible
and be prepared if something bad happens.

Inputs:
The following are the inputs for the project plan,
 Start or ending dates.
 List of tasks that need to be completed.
 Sub tasks and links for them.
 Create any links between major tasks.
 Specific amount time for each task.
10




Assign resources for each task.
Create task information for each item you put into the list.

Deliverables:
A complete plan for the entire project.
Example for project plan:

S.NO

01

MILESTONE /
DELIVERABLE NAME

Planing:
Requirement definition document

MILESTONE / DELIVERABLE
DESCRIPTION

TIME
LINE
(hrs)

The customer must be interviewed to
understand & clearly record requirements

3

02

Requirement analysis:
Software requirement
specification & test plan

Function, non-functional software &
requirements are clearly recorded

5

03

Design:
High Level Deign

The flow of information between different
modules is represented using DFD’, UML
diagram & sequence diagram

4

04

Data design:
Database design

Select the database. Create the tables and
define the fields in the appropriate tables.

1

05

Interface design:
User Interface Design

06

Implementation

07

Testing:
Unit Testing

08

Integration & System Testing

09

Document and help manual

Using the selected language design the
user interface so that it is conveniently
used by all users
The code is written for the identified
functional requirements and linked with
GUI and database. This must also be
traceable to DFD’s and SRS.
Individual modules are tested by the
programmer to verify the functionality.
Integrate the tested individual modules
and test if any errors have occurred and
finally validation testing is done against
the SRS
The help manual is prepared in English for
the beginners using the software

Viva Questions:
11

1

10

3

3

3

1) What is a project plan?
A.
Project planning is part of project management, which relates to the use of
schedules such as Gantt charts to plan and subsequently report progress within the project
environment.
2) What is risk management?
A. Risk management is concerned with identifying risks and drawing up plans to
minimize their effect on a project.
3) What is called a milestone?
A. A milestone is the end of a stage that marks the completion of a work package or
phase, typically marked by a high level event such as completion, endorsement or signing
of a deliverable, document or a high level review meeting.
4)Give some examples for project risks.
A.





Time and cost estimates too optimistic
Customer review and feedback cycle too slow
Unexpected budget cuts
Unclear roles and responsibilities.

5) What is a project schedule?
A. A schedule consists of a list of a project's terminal elements with intended start and
finish dates. Terminal elements are the lowest element in a schedule, which is not further
subdivided. Those items are often estimated in terms of resource requirements, budget
and duration, linked by dependencies and scheduled.

12

13

2

SOFTWARE REQUIREMENT ANALYSIS

Objective:
To gain a deeper understanding of the Software Requirement Specification phase
and to review the requirements engineering process.

Background


A requirement is a statement of a behavior or attribute that a system must possess
for the system to be acceptable to a stakeholder.



Software Requirement Specification (SRS) is a document that describes the
requirements of a computer system from the user's point of view.

Study:


Requirements analysis in systems engineering and software engineering,
encompasses those tasks that go into determining the needs or conditions to meet
for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.



Requirements analysis is critical to the success of a development project.
Requirements must be documented, actionable, measurable, testable, related to
identified business needs or opportunities, and defined to a level of detail
sufficient for system design. Requirements can be functional and non-functional.

Requirements analysis includes three types of activity:




Eliciting requirements: the task of communicating with customers and users to
determine what their requirements are. This is sometimes also called requirements
gathering.
Analyzing requirements: determining whether the stated requirements are
unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
Recording requirements: Requirements might be documented in various forms,
such as natural-language documents,use cases,user stories, or process
specifications.

Requirements Engineering Process:
Requirements engineering process consists of four phases:

14






Requirements elicitation: getting the customers to state exactly what the
requirements are.
Requirements analysis: making qualitative judgments and checking for
consistency and feasibility of requirements.
Requirements validation: demonstrating that the requirements define the system
that the customer really wants.
Requirements management: the process of managing changing requirements
during the requirements engineering process and system development, and
identifying missing and extra requirements.

Writing Requirements:
Requirements always need to be correct, unambiguous, complete, consistent, and
testable.
Recommendations When Writing Requirements
 Never assume: others do now know what you have in mind.
 Use meaningful words; avoid words like: process, manage, perform, handle, and
support.
 State requirements not features:
o Feature: general, tested only for existence.
o Requirement: specific, testable, measurable.
 Avoid:
o Conjunctions: ask yourself whether the requirement should it be split into
two requirements.
o Conditionals: if, else, but, except, although.
o Possibilities: may, might, probably, usually.
Writing Specifications:
Specification is a description of operations and attributes of a system. It can be a
document, set of documents, a database of design information, a prototype, diagrams or
any combination of these things.
Specifications are different from requirements: specifications are sufficiently complete ─
not only what stakeholders say they want; usually, they have no conflicts; they describe
the system as it will be built and resolve any conflicting requirements.
Creating specifications is important. However, you may not create specifications if:
 You are using a very incremental development process (small changes).
 You are building research or proof of concept projects.
 You rebuilding very small projects.
 It is not cheaper or faster than building the product.

15

Software Requirement Specification (SRS):
An SRS document specifies:
 The required behavior of a system in terms of: input data, required processing,
output data, operational scenarios and interfaces.
 The attributes of a system including: performance, security, maintainability,
reliability, availability, safety requirements and design constraints.
Remember that there is no “Perfect SRS”. However, SRS should be:












Correct: each requirement represents something required by the target system.
Unambiguous: every requirement in SRS has only one interpretation
Complete: everything the target system should do is included in SRS (no sections
are marked TBD-to be determined).
Verifiable: there exists some finite process with which a person/machine can
check that the actual as-built software product meets the requirements.
Consistent in behavior and terms.
Understandable by customers.
Modifiable: changes can be made easily, completely and consistently.
Design independent: doesn't imply specific software architecture or algorithm.
Concise: shorter is better.
Organized: requirements in SRS are easy to locate; related requirements are
together.
Traceable: each requirement is able to be referenced for later use (by the using
paragraph numbers, one requirement in each paragraph, or by using convention
for indication requirements).

Inputs:



Complete problem definition.
Clearly identified functional and non-functional requirements.



Project plan with milestones, timelines and deliverables.

Deliverables:


A detailed software requirement specification(SRS) document.

16

SRS document in IEEE format:
1) Introduction
1.1) Purpose
1.2) Scope
1.3)Abbreviations
1.4) References
1.5) Technologies

2) Overall Description
2.01) Product Perspective
2.02) Software Interface
2.03) Hardware Interface
2.04) Communication Interface
2.05) Product Function
2.06) User Characteristics
2.07) Constraints
2.08) Use-Case Model Survey
2.09) Architecture diagram
2.10) Database design
2.11) Assumptions and Dependencies

3) Specific Requirements
3.1) Use-Case Reports
3.2) Supplementary Requirement

Viva Questions:
1) What are the types of requirements?
A.








Customer requirements.
Functional requirements.
Non – functional requirements.
Performance requirements
Design requirements.
Derived requirements.
Allocated requirements.

17

2) Differentiate functional and non-functional requirements.
A.


Functional requirements explain what has to be done by identifying the
necessary task, action or activity that must be accomplished. Functional
requirements analysis will be used as the top level functions for functional
analysis.



Non-functional requirements are requirements that specify criteria that can be
used to judge the operation of a system, rather than specific behaviors.

3) What are the steps in requirement engineering?
A. Requirements Engineering can be divided into discrete chronological steps:







Requirements elicitation,
Requirements analysis and negotiation,
Requirements specification,
System modeling,
Requirements validation,
Requirements management.

4) What is requirement management?
A. Requirements Engineering can be divided into discrete chronological steps:







Requirements elicitation,
Requirements analysis and negotiation,
Requirements specification,
System modeling,
Requirements validation,
Requirements management.

5) Why is requirement management important?
A. Requirements management is important because, by organizing and tracking the
requirements and managing the requirement changes, you improve the chances of

18

completing the project on time and under budget. Poor change management is a key
cause of project failure.

19

3

DATA MODELING AND IMPLEMENTATION

Objective:
To gain a deeper understanding of the data modeling which includes : entityrelationship diagram (ERD) and data flow diagram (DFD).

Background:
Modeling consists of building an abstraction of reality. These abstractions are
simplifications because they ignore irrelevant details and they only represent the relevant
details (what is relevant or irrelevant depends on the purpose of the model).

Study:
Data modeling in software engineering is the process of creating a data model by
applying formal data model descriptions using data modeling techniques.
Data modeling is a method used to define and analyze data requirements needed
to support the business processes of an organization. The data requirements are recorded
as a conceptual data model with associated data definitions. Actual implementation of the
conceptual model is called a logical data model. To implement one conceptual data model
may require multiple logical data models. Data modeling defines not just data elements,
but their structures and relationships between them.Data modeling techniques and
methodologies are used to model data in a standard, consistent, predictable manner in
order to manage it as a resource. The use of data modeling standards is strongly
recommended for all projects requiring a standard means of defining and analyzing data
within an organization, eg using data modeling:




to manage data as a resource;
for the integration of information systems;
for designing databases/data warehouses;

The Elements of the Analysis Model
The generic analysis model consists of:
 An entity-relationship diagram (data model).
 A data flow diagram (functional model).
 A state transition diagram (behavioral model).

20

Entity Relationship Diagram
An entity relationship diagram (ERD) is one means of representing the objects and their
relationships in the data model for a software product.
Entity Relationship diagram notation:
Entity

Relationship
Steps to create an ERD:
 Define “objects” by underlining all nouns in the written statement of scope:
producers/consumers of data, places where data are stored, and “composite” data
items.
 Define “operations” by double underlining all active verbs: processes relevant to
the application and data transformations.
 Consider other “services” that will be required by the objects.
 Then you need to define the relationship which indicates “connectedness”: a
"fact" that must be "remembered" by the system and cannot be or is not computed
or derived mechanically.
Data Flow Diagram
A data flow data diagram is one means of representing the functional model of a software
product. DFDs do not represent program logic like flowcharts do.
Data flow diagram notation:
External entity

Process

Data flow
Control flow

Data store

21

Data Flow Diagram Guidelines:
 All icons must be labeled with meaningful names.
 Always show external entities at level 0.
 Always label data flow arrows.
 Do not represent procedural logic.
 Each bubble is refined until it does just one thing.
Implementation:

Implementation is the realization of an application, or execution of a plan
idea, model, design, specification, standard, algorithm, or policy.

In computer science, an implementation is a realization of a technical
specification or algorithm as a program, software component, or other computer
system.
Project implementation steps:
 Prepare the infrastructure.
 Analyze the problem and select suitable implementation language.
 Install the required servers and software needed for implementation.
 Select the appropriate data base
 Perform final verification
 Implement new processes and procedures.
 Monitor the solution.

Inputs:
Data Flow Diagram :


Isolated data objects and grammatical parse to determine operations.



External entities (producers and consumers of data).



Level 0 DFD “Context Diagram” (one single process).



The flow to maintain data flow continuity.

Entity Relationship Diagram:


Objects identified from the problem statement.



Operations that are relevant to the application and data transformations.



Services that will be required by the objects.

22



Relationship which indicates “connectedness”: a "fact" that must be
"remembered" by the system and cannot be or is not computed or derived
mechanically.

Deliverables:
Example for University ER Diagram:

University ER Diagram
Degree
Name

StudentID

Birth date

SSN

DName

OfficeNumber
OfficePhone

Department

Student

Sex

DCode

Major In

College
Class

Minor In

Address
City

State

Zip

Offer

CName
Grade_Report
Letter Grade

CourseDesc
Instructor

Year

Course
CNumber

GPA
Credits

Section

Numeric Grade

SectionNumber

Belong_To

Semester

23

Example for Banking DFD Diagram:
Cash Withdrawal:

24

Implementation Example Source code:

Private Sub cmdExit_Click()
End
End Sub
Private Sub cmdLogin_Click()
flag = True
If (txtUsername.Text = "") Then
MsgBox "Enter a valid Username", vbCritical + vbOKOnly, "Error"
flag = False
txtUsername.SetFocus
ElseIf (txtPassword.Text = "") Then
MsgBox "Enter a valid Password", vbCritical + vbOKOnly, "Error"
flag = False
txtPassword.SetFocus
End If
If flag = True Then
rs.Close
rs.Open "Select Password from Login where Username = '" & txtUsername.Text &
"'", con, adOpenDynamic, adLockOptimistic

If rs.EOF = True Then 'If Search is found

25

MsgBox "User not found", vbCritical + vbOKOnly, "Error"
Else
If (rs.Fields("Password") <> txtPassword.Text) Then
MsgBox "Invalid Password", vbCritical + vbOKOnly, "Error"
txtPassword.Text = ""
txtPassword.SetFocus
Else
user = txtUsername.Text
If (txtUsername.Text = "admin") Then
userAdmin = True
Else
userAdmin = False
End If
frmMain.Show
Unload Me
End If
End If
End If
End Sub
Private Sub Form_Load()
Set con = New ADODB.Connection
Set rs = New ADODB.Recordset
con.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=hall.mdb;Persist Security
Info=False"

26

rs.Open "select * from Login", con, adOpenDynamic, adLockBatchOptimistic
End Sub

Viva Questions:
1. What is Data modeling?
Data modeling in software engineering is the process of creating a data
model by applying formal data model descriptions using data modeling
techniques.
2. What are the inputs to Data Flow Diagram?
 Isolated data objects and grammatical parse to determine operations.
 External entities (producers and consumers of data).
 Level 0 DFD “Context Diagram” (one single process).
 The flow to maintain data flow continuity.
3. What are the inputs to ER Diagram?





Objects identified from the problem statement.
Operations that are relevant to the application and data transformations.
Services that will be required by the objects.
Relationship which indicates “connectedness”: a "fact" that must be
"remembered" by the system and cannot be or is not computed or derived
mechanically.

4. What are Project Implementation steps?
 Prepare the infrastructure.
 Analyze the problem and select suitable implementation language.
 Install the required servers and software needed for implementation.
 Select the appropriate data base
 Perform final verification
 Implement new processes and procedures.
 Monitor the solution.
5. What are the steps to create ERD?
 Define “objects” by underlining all nouns in the written statement of scope:
producers/consumers of data, places where data are stored, and
“composite” data items.
 Define “operations” by double underlining all active verbs: processes
relevant to the application and data transformations.
 Consider other “services” that will be required by the objects.
27



Then you need to define the relationship which indicates “connectedness”:
a "fact" that must be "remembered" by the system and cannot be or is not
computed or derived mechanically.

28

4

SOFTWARE TESTING

Objective:
To gain a deeper understanding of the Software Testing phase and to detect
software failures so that defects may be uncovered and corrected.

Background:
 Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test.
 Software testing also provides an objective, independent view of the software to
allow the business to appreciate and understand the risks at implementation of the
software.

Study:
Test techniques include, but are not limited to, the process of executing a program
or application with the intent of finding software bugs.
Software testing can also be stated as the process of validating and verifying that a
software program/application/product:
1. Meets the business and technical requirements that guided its design and
development;
2. Works as expected; and
3. Can be implemented with the same characteristics.
Software testing, depending on the testing method employed, can be implemented at
any time in the development process. However, most of the test effort occurs after the
requirements have been defined and the coding process has been completed. As such, the
methodology of the test is governed by the software development methodology adopted.
Different software development models will focus the test effort at different points in
the development process. Newer development models, such as Agile, often employ test
driven development and place an increased portion of the testing in the hands of the
developer, before it reaches a formal team of testers. In a more traditional model, most of
the test execution occurs after the requirements have been defined and the coding process
has been completed.

29

Functional vs non-functional testing
Functional testing refers to tests that verify a specific action or function of the code
found in the code requirements documentation, development methodologies work from
use cases or user stories.
Non-functional testing refers to aspects of the software that may not be related to a
specific function or user action, such as scalability or security. Non-functional testing
tends to answer such questions as "how many people can log in at once".
Defects and failures
One common source of expensive defects is caused by requirement gaps, A common
source of requirements gaps is non-functional requirements such as testability, scalability,
maintainability, usability, performance, and security.
Software faults occur through the following processes. A programmer makes an error
(mistake), which results in a defect (fault, bug) in the software source code. If this defect
is executed, in certain situations the system will produce wrong results, causing a failure..
A defect can turn into a failure when the environment is changed.
Static vs. dynamic testing
Reviews, walkthroughs, or inspections are considered as static testing, whereas actually
executing programmed code with a given set of test cases is referred to as dynamic
testing.
Software verification and validation
Software testing is used in association with verification and validation:



Verification: Have we built the software right? (i.e., does it match the
specification).
Validation: Have we built the right software? (i.e., is this what the customer
wants).

The terms verification and validation are commonly used interchangeably in the industry;
it is also common to see these two terms incorrectly defined. According to the IEEE
Standard Glossary of Software Engineering Terminology:
 Verification is the process of evaluating a system or component to determine
whether the products of a given development phase satisfy the conditions imposed at
the start of that phase.
 Validation is the process of evaluating a system or component during or at the end
30

of the development process to determine whether it satisfies specified requirements.
Testing methods



White box testing is when the tester has access to the internal data structures and
algorithms including the code that implement these.
Black box testing treats the software as a "black box"—without any knowledge
of internal implementation. Black box testing methods include: equivalence
partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based
testing, traceability matrix, exploratory testing and specification-based testing.

31

Testing levels
Tests are frequently grouped by where they are added in the software development
process, or by the level of specificity of the test.

 Unit testing refers to tests that verify the functionality of a specific section of
code, usually at the function level. In an object-oriented environment, this is
usually at the class level, and the minimal unit tests include the constructors and
destructors.
 Integration testing is any type of software testing that seeks to verify the
interfaces between components against a software design. Software components
may be integrated in an iterative way or all together.
 Regression testing focuses on finding defects after a major code change has
occurred. Specifically, it seeks to uncover software regressions, or old bugs that
have come back. Such regressions occur whenever software functionality that was
previously working correctly stops working as intended.
 Acceptance testing can mean one of two things:
1. A smoke test is used as an acceptance test prior to introducing a new build
to the main testing process, i.e. before integration or regression.
2. Acceptance testing performed by the customer, often in their lab
environment on their own hardware, is known as user acceptance testing
(UAT). Acceptance testing may be performed as part of the hand-off
process between any two phases of development







Alpha testing is simulated or actual operational testing by potential
users/customers or an independent test team at the developers' site.
Beta testing comes after alpha testing The software is released to groups of
people so that further testing can ensure the product has few faults or bugs
Non-functional testing verifies that the software functions properly even when it
receives invalid or unexpected inputs. Non-functional testing, especially for
software, is designed to establish whether the device under test can tolerate
invalid or unexpected inputs, thereby establishing the robustness of input
validation routines as well as error-handling routines
Performance testing is executed to determine how fast a system or sub-system
performs under a particular workload. It can also serve to validate and verify other
quality attributes of the system, such as scalability, reliability and resource usage.
Load testing operates under a specific load, whether that be large quantities of
data or a large number of users. This is generally referred to as software
scalability. The related load testing activity of when performed as a nonfunctional activity is often referred to as endurance testing.

32






Volume testing is a way to test functionality. Stress testing is a way to test
reliability. Load testing is a way to test performance.
Stability testing checks to see if the software can continuously function well in or
above an acceptable period. This activity of non-functional software testing is
often referred to as load (or endurance) testing.
Usability testing is needed to check if the user interface is easy to use and
understand.
Security testing is essential for software that processes confidential data to
prevent system intrusion by hackers.

Inputs:
Software testing process can produce several artifacts.
Test plan
A test specification is called a test plan. The developers are well aware what test
plans will be executed and this information is made available to management and
the developers. Some companies have a higher-level document called a test
strategy.
Traceability matrix
A traceability matrix is a table that correlates requirements or design documents to
test documents. It is used to change tests when the source documents are changed,
or to verify that the test results are correct.
Test case
A test case normally consists of a unique identifier, requirement references from a
design specification, preconditions, events, a series of steps (also known as
actions) to follow, input, output, expected result, and actual result. Clinically
defined a test case is an input and an expected
Test script
The test script is the combination of a test case, test procedure, and test data.
Initially the term was derived from the product of work created by automated
regression test tools.
Test suite
The most common term for a collection of test cases is a test suite. The test suite
often also contains more detailed instructions or goals for each collection of test
cases. It definitely contains a section where the tester identifies the system
configuration used during testing. A group of test cases may also contain
prerequisite states or steps, and descriptions of the following tests.
Test data
In most cases, multiple sets of values or data are used to test the same
functionality of a particular feature. All the test values and changeable
environmental components are collected in separate files and stored as test data. It
is also useful to provide this data to the client and with the product or a project.
Test harness

33

The software, tools, samples of data input and output, and configurations are all
referred to collectively as a test harness.

Deliverables:
 Completely tested source code without any errors.
 The various errors which are encountered during the testing must be clearly
Documented.

Viva Questions:
1. What is a test plan?
A test specification is called a test plan. The developers are well aware
what test plans will be executed and this information is made available to
management and the developers. Some companies have a higher-level document
called a test strategy.
2. What is a test data?
In most cases, multiple sets of values or data are used to test the same
functionality of a particular feature. All the test values and changeable
environmental components are collected in separate files and stored as test data. It
is also useful to provide this data to the client and with the product or a project.
3. Differentiate white box and black box testing.
White box testing is when the tester has access to the internal data structures
and algorithms including the code that implement these.
Black box testing treats the software as a "black box"—without any
knowledge of internal implementation. Black box testing methods include:
equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing,
model-based testing, traceability matrix, exploratory testing and specificationbased testing.
4. What is a software verification?
Verification: Have we built the software right? (i.e., does it match the
specification).
5. What is software Validation?
Validation is the process of evaluating a system or component during or at the
end of the development process to determine whether it satisfies specified requirements

34

35

5

SOFTWARE DEBUGGING

Objectives:
To gain a deeper understanding of software debugging.

Background:
Debugging is a methodical process of finding and reducing the number of bugs, or
defects, in a computer program or a piece of electronic hardware, thus making it behave
as expected. Debugging tends to be harder when various subsystems are tightly coupled,
as changes in one may cause bugs to emerge in another. Many entire books have been
written about debugging (see below: Further reading), as it involves numerous aspects,
including: interactive debugging, control flow, integration testing, log files, monitoring,
memory dumps, Statistical Process Control, and special design tactics to improve
detection while simplifying changes.

Study:
As software and electronic systems have become generally more complex, the
various common debugging techniques have expanded with more methods to detect
anomalies, assess impact, and schedule software patches or full updates to a system.
The words "anomaly" and "discrepancy" can be used, as being more neutral
terms, to avoid the words "error" and "defect" or "bug" where there might be an
implication that all so-called errors, defects or bugs must be fixed. Instead, an impact
assessment can be made to determine if changes to remove an anomaly would be costeffective for the system, or perhaps a scheduled new release might render the change(s)
unnecessary.
Not all issues are life-critical or mission-critical in a system. Also, it is important
to avoid the situation where a change might be more upsetting to users, long-term, than
living with the known problem(s). Basing decisions of the acceptability of some
anomalies can avoid a culture of a "zero-defects" mandate, where people might be
tempted to deny the existence of problems so that the result would appear as zero defects.
Various debugging techniques:

 Print debugging is the act of watching (live or recorded) trace statements, or print
Statements, that indicate the flow of execution of a process.
 Remote debugging is the process of debugging a program running on a system
Different than the debugger. To start remote debugging, debugger connects to a
Remote system over a network. Once connected, debugger can control the
execution of the program on the remote system and retrieve information about its
state.

36

 Post-mortem debugging is the act of debugging the memory dump (or core
of a process. The dump of the process space could be obtained automatically by the
system, or by a programmer-inserted instruction, or manually by the interactive
user. Crash dumps (core dumps) are often generated after a process has terminated
due to an unhandled exception.
Steps involved in debugging process:
Unlike software development, debugging is inherently iterative. (I mean development in
general, realizing that in complex projects development can and should be iterative, too).
Debugging, in general, consists of three main stages:
1. Describe the bug.
Maybe this isn't part of debugging itself, but it's so important that I include it here.
You should get as much detail from the user as possible: product version, OS
version, all conditions needed to reproduce the bug.
2. Get the program snapshot when the bug 'appears'.
Try to reproduce the bug and catch the state (variables, registers, files, etc.) and
action (what the program is doing at the moment, which function is running).
Sometime this is simple: e.g. the program crashes and you can just switch to your
debugger to see the problem. But in other cases you have to perform many
iterations to catch the snapshot. You maybe even have to return to 1 in some
cases. In other cases you will return here from the next step.
3. Analyze the snapshot (state/action) and search for the cause of the bug.
It is possible that the state and action might be wrong, so a substep in this stage is
to determine whether they are correct or not. The following state/action
combination classification can be useful in guiding further analysis ('+' & '-'
indicate 'correct' & 'wrong', respectively ):
o +/+ : unreproducible bug;
You have an incorrect description or different environments (OS, etc.)
o +/- : a simply found bug;
You have to add some checking (NULL pointer, divide by zero, etc.) or
additional implementation of something
o -/+ : a bug requiring a search for its source, origin;
Methods you can use include
 tracing from previous moments,
 tracing of places where the state components are used/changed
 tracing with different input data
 your experience may indicate key places in the program (e.g., the
start of user input processing)
o -/- : same as -/+ plus additional difficulty, but due to the difficulty of
situation in some cases some work-around may be enough decision, i.e.
making action correct (+).

37

4. Fix the bug.
Ideas about bug fixing may occur at any stage of the debugging process, but only
one may be implemented, which 1) fixes the class of bugs which the described
one belongs to, and doesn’t introduce other bugs in other places and/or with other
input data.

Inputs:
 The following test cases are the inputs for the debugging phase.

38

Deliverables:
 A text document which contains the errors traced out during the debugging and the
corresponding measures to be taken.

Viva Questions:
1. What is print debugging?
Print debugging is the act of watching (live or recorded) trace statements, or print
statements, that indicate the flow of execution of a process.
2. What are Debuggers?
Debuggers are software tools which enable the programmer to monitor the
execution of a program, stop it, re-start it, set breakpoints, change values in memory and
even, in some cases, go back in time. The term debugger can also refer to the person who
is doing the debugging.
3. What is remote debugging?
Remote debugging is the process of debugging a program running on a system
different than the debugger. To start remote debugging, debugger connects to a remote
system over a network. Once connected, debugger can control the execution of the
program on the remote system and retrieve information about its state.

4. What is anti-debugging?
Anti-debugging is "the implementation of one or more techniques within computer code
that hinders attempts at reverse engineering or debugging a target process".The types of
technique are:







API-based: check for the existence of a debugger using system information
Exception-based: check to see if exceptions are interfered with
Process and thread blocks: check whether process and thread blocks have been
manipulated
Modified code: check for code modifications made by a debugger handling
software breakpoints
Hardware- and register-based: check for hardware breakpoints and CPU registers
Timing and latency: check the time taken for the execution of instructions.

39

5. What are the steps to improve debugging?
 Build smarter debugging tools. Since these tools would be used in almost all
stages of debugging, it would be useful to “teach” them the program and the
program itself should help debuggers.
 Create a system/DB of key documentation about the program useful in debugging,
for example "If there is a problem in aspect A, then look (set breakpoints, etc.) in
key places A1, A2, … ". The DB should support searching.

DOCUMENTATION AND USER MANUALS

Documentation:
Software documentation is the written record of facts about a software system
recorded with the intent to convey purpose, content and clarity. The recording process
usually begins when the need for the system is conceived and continues until the system
no longer in use.

Types:



User documentation
System documentation

User documentation:
It refers to those documents,containing descriptions of the functions of a system
without reference to how these functionsare implemented.

S.No

Document

1.
2.

System overview
Installation guide

3.

Beginner’s guide

4.

Reference guide

5.
6.
7.

Enhancement
Quick reference card
System administration

Function
Provides general description of system’s functions
Describes how to set up the system, customize it to
local hardware needs and configure it to particular
hardware and other software resources.
Provides simple explanations of how to start using the
system.
Provides in-depth description of each system facility
and how it can be used.
Booklet contains a summary of new features.
Servers as a factual lookup
Provides information on services such as net-working,
security and upgrading.

System documentation:
40

It refers those documentation containing all facets of system, including analysis,
specification, design, implementation, testing, security, etc.

User manual:
A user guide or user's guide, also commonly known as a manual, is a
technical communication document intended to give assistance to people using a
particular system.It is usually written by a technical writer, although user guides are
written by programmers, product or project managers, or other technical staff,
particularly in smaller companies.
User guides are most commonly associated with electronic goods, computer
hardware and software.
Most user guides contain both a written guide and the associated images. In the
case of computer applications, it is usual to include screenshots of how the program
should look, and hardware manuals often include clear, simplified diagrams. The
language used is matched to the intended audience, with jargon kept to a minimum or
explained thoroughly.
As the name implies, User Guides are written to help people understand an software
application or IT system. They are also called User Manuals. When writing a User Guide,
use simple language with short sentences. This writing style helps the user understand the
application.
User Guides are the first port of call when something needs to be read. As many people
read user guides when frustrated and after having lost patience with the software, you
need to write your material to address their concerns quickly.
User Guides are often written for non-technical individuals. The level of content and
terminology differs considerably from, for example, a System Administration Guide,
which is more detailed and complex.
This rest of article offers some guidelines to consider when writing your User Guide,
such as:


Identifying your audience



Writing sections



Defining style guide and standards



Delivery formats

Identifying Your Audience

41

As with all types of writing, the first step is to define your TARGET AUDIENCE. Your
target audience are the people who will user your document. As different readers have
different requirements, you need to consider their specific requirements


Identify the target audience



Identify their level of technical knowledge



Identify how they will use the guide

Audience Definitions
In the planning process, develop an audience definition that identifies:


The user



The system



The tasks

Software is used to do specific things. Users want to know what the software can do for
them, for example, how to print a page in landscape.
They are generally not interested in the nitty-gritty technical details; they want to click a
button and get a result. The User Guide is to teach them how the software helps them to
do something.
Depending on the guide in question, you may need to address several audiences. For
example:


Programmers who will troubleshoot the program



IT Managers who want to know the resources the program requires



Project Managers who want to confirm that the original requirements were met.

If you are writing for more than one audience, develop an audience definition for each
one. Examine the definitions and see if you can address all audience types with one
document. In many situations, you may need to write a number of documents, of which
the users guide is only one.



When planning, use the audience definition to focus your decisions.
42



When writing, the audience definition serves as a guide for the documentation
team and as a benchmark for evaluating the results.

Here are some questions that will help define your audience's needs:


Where will they use the document, for example, in the office, at home, in their
car?



How much experience have they of using your application?



Is this guide an upgrade to an existing application?



Is your application new? If so, you may want to include a Getting Started
document to introduce the software.



How will they use the user guide?



Will they install the software by themselves or do so over the internet?



What level of detail is required?



Will graphics help their understanding of how to use your product?

Writing the User Guide
Each user guide is comprised of front page, body sections, and a back page. The
following section describes what each of these needs to contain.
Front Page (cover pages)
Include a cover page, table of contents, and a preface, if necessary.
Cover and Title Page
If the user guide is copyrighted, include a copyright notice.
Copyright © 2003 The Name Of Your Company.
Place the copyright notice on the cover (and also the title page).
Disclaimer
Include a standard disclaimer inside the front cover that outlines the Terms and
Conditions for using this guide.
Preface
43

Use this section to reference other documents related to the software. Make sure you refer
to the correct release number for all software and documents that you refer to. If
necessary, include a section on "How to use this guide" as an introduction.
Contents
You must include a table of contents. the only exception is if your guide is less than ten
pages, in which case you should probably refer to it as a Getting Started guide or
Reference Guide.
If this user guide is more than twenty pages, include an index at the end of the document.
Body of the guide
This is the heart of the guide. In the main body, separate the procedures (also called
instructions) from reference materials. This will help the user navigate their way through
the guide much faster.
Procedures
Procedures help the user perform specific tasks. They are also known as instructions or
tasks. Examples of these may include:


When, why, and how you can perform a task, for example, printing a document,
cropping an image, uploading a file.



What the screen will show after you perform a task, for example, an updated view
of your bank balance.



Examples of tasks and program operation.

Writing procedures
Writing procedures involves the following tasks:


Identifying the major tasks



Separating each major task into subtasks



Writing a series of steps that walk the user through each subtask



Using an "if-then" approach when explaining decisions that users can make.

Chunking text
44

Breaking large pieces of information into smaller piece of information is called
"chunking."
When writing user guides, you can separate information by menu options and their
respective consequences, for example, showing the user the results of each action.
Subtasks that need to be performed can be divided into chunks. Each chunk can form a
new chapter or section within the guide.
Use a consistent format for each section, for instance:


Introduce each section with an overview of the task to be performed



Describe the inputs and outputs. In other words, what the user must enter into the
system and what the system will do as a result.



Describe the procedures for accomplishing these tasks.

Number your steps
When writing procedures, number each step and use the imperative form of verbs, for
example:
Press ENTER
or
Click "Yes" and press ENTER to submit your details.
Using the If-Then Approach
When users are allowed to make decisions, use an If-Then approach to show the different
result for each decision they make.
If you choose "Yes," the program will make Firefox your default web
browser. If you choose "No," it will set Opera as your default browser.
Use diagrams to illustrate more complicated procedures.

45

Reference Materials
User turn to reference material when they need detailed information on a specific topic,
for example, settings or parameters they must enter.
Reference materials can include:


Program options, for example, different menus and buttons that are presented to
the user



Keyboard options, for example, hold AltGr and 4 to show the Euro symbol



Error messages that may arise when you use the application



Troubleshooting tips to resolve these issues



Frequently asked questions that the user may have about the software

Back Matter
Add a Glossary of Terms and an Index towards the end of the document.
Glossary
The glossary should cover all acronyms and industry terms used in the document. Help
the user understand your material. Do not alienate them by using jargon and assuming
that they know the meaning on these words.


A short glossary can appear at the front before the table of contents



A larger glossary should appear in the back matter.

Highlight glossary terms (by italics, for instance) the first time they appear in text.
Index
Any guide longer than 20 pages benefits from an index. An index helps users locate
specific items very fast without having to search through the entire document manually.
Large documents without an index are impossible to use efficiently.

46

Establishing Standards
As well as writing the guide, you also need to consider how the document will be
delivered, for example, as a book, online or a PDF.
Areas that need consideration include:


Format (the design and layout of the pages)



Style (elements affecting readability, such as font, size, color)



Other requirements that are specific to each delivery format. For example, PDFs
may need security settings applied so material cannot be copied; partner logos
may need to be added; terms and conditions may need to be updated.

Document Format and Structure
If you are writing a user guide for a client, rather then your own company, check if they
use a specific style guide or have a preference for how the document should be presented.
Check this with the client during the planning phase.
Use a document map to organize the guide. To do this:


Use headings for organizing information.



Include page numbers and section titles on every page, either in footers or
headers.



Consider using dual columns. This lets you put headings in the left-hand column
and the text in the right-hand column.

Style
Use an appropriate style. Decide on the technical level of your language, how you
address the user, and conventions that are required.
Technical Language
Match the level of technical language with the audience ¯s level of proficiency. Always
underestimate the knowledge of your readers rather than overestimate it.
Limit technical terms to those the user will encounter. If you must define a large number
of terms, use a glossary to supplement definitions in the text.

47

Addressing the User
When writing procedures, use the active voice (e.g. Click this) and address users directly
(write "you" rather than "the user").
When explaining an action, use the "command" form of the verb:
"Choose an option from the menu and press [ENTER]."

Presenting your material
You can improve the readability of your documents by using specific formats to
distinguish different types of information.
For example, you can distinguish the user's input from the system's response by:


Indenting text



Using columns to layout text



Providing illustrations or photographs that highlight key areas



Using different fonts and type features (bold, italics and underline)

Nonverbal devices, such as icons or diagrams, help supplement verbal instructions.

48

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close