Software Engineering

Training Material
 Software Engineering – Training Material

SOFTWARE ENGINEERING

• Introduction About the company

Netkraft is a leading provider of creative Web professional services called e-

Business services. eBusiness is the complex fusion of business processes,
enterprise applications, and organizational structure necessary to create a high-
performance business model. In this environment, widespread use is made of
synergistic clusters, business ecosystems, coalitions, co-operative networks, or
outsourcing to create end-to-end value streams to link businesses, customers and
suppliers. NetKraft has built a reputation for quality products, outstanding
customer support and business values.

• Software Industry

 In India itself, Software industry growth has been phenomenal.

 IT field has enormously grown in the past 50 years.
 IT industry in India is expected to touch 10,000 crores of which software share
is dramatically increasing.

• Software Crisis

 Software cost/schedules are grossly inaccurate.

Cost overruns of several times, schedule slippage’s by months, or even years
are common.

 Productivity of people has not kept pace with demand

Added to it is the shortage of skilled people.

 Quality of software is than desired

Error rates of released software leave customer dissatisfied…Threatening the
very business.

• Software Myths

 Management Myths

 Software Management is different.

 Why change or approach to development?
 We have provided the state-of-the-art hardware.
 Problems are technical
 If project is late, add more engineers.
 We need better people.

 Developers Myths

 We must start with firm requirements

 Why bother about Software Engineering techniques, I will go to terminal
and code it.
 Once coding is complete, my job is done.
 How can you measure the quality..it is so intangible.

QMS/SE/TR01 Version 1.0 Page 2 of 12

 Software Engineering – Training Material

 Customer’s Myth

 A general statement of objective is good enough to produce software.

 Anyway software is “Flexware”, it can accommodate my changing needs.

 What do we do ?

 Use Software Engineering techniques/processes.

 Institutionalize them and make them as part of your development culture.
 Adopt Quality Assurance Frameworks : ISO, CMM
 Choose the one that meets your requirements and adopt where necessary.

• Software Engineering:

 Software Engineering is an engineering discipline concerned with the practical

problems of developing large software.

 Software Engineering discipline tracks both technical & non-technical problems

associated with software development.

 Challenge for Software Engineers is to produce high quality software with finite
amount of resources & within a predicted schedule.

 Apply Engineering Concepts to developing Software

 Apply Engineering Concepts to removing crisis.

• Software Quality Assurance:

Software quality assurance Software QA involves the entire software development

PROCESS - monitoring and improving the process, making sure that any agreed-
upon standards and procedures are followed, and ensuring that problems are found
and dealt with. It is oriented to 'prevention'.
OR
The purpose of Software Quality Assurance is to provide management with
appropriate visibility into the process being used by the software project and of the
products being built.

Software Quality Assurance involves reviewing and auditing the software products
and activities to verify that they comply with the applicable procedures and
standards and providing the software project and other appropriate managers with
the results of these reviews and audits.

• Verification:

 Verification typically involves reviews and meetings to evaluate documents,

plans, code, requirements, and specifications.
 The determination of consistency, correctness & completeness of a program at
each stage

QMS/SE/TR01 Version 1.0 Page 3 of 12

 Software Engineering – Training Material

• Validation:

 Validation typically involves actual testing and takes place after verifications are
completed.
 The determination of correctness of a final program with respect to its
requirements.

• Software Engineering Process

Consists of Three generic Phases:

 Definition, Development, and Maintenance.

1. Definition (What)
Customer Contact, Planning, Requirement Analysis.
2. Development Phase (How)
Design, Coding, Testing.
3. Maintenance Phase (Change)
Correction, Adaptation, Enhancement, Reengineering.
4. Support Activities
Quality Assurance, Configuration Management.

Software Life Cycle Models

• Prototyping Model
• Waterfall Model – Sequential
• Spiral Model
• V Model - Sequential

Prototyping Model of Software Development

A prototype is a toy implementation of a system; usually exhibiting limited functional

capabilities, low reliability, and inefficient performance. There are several reasons for
developing a prototype. An important purpose is to illustrate the input data formats,
messages, reports and the interactive dialogues to the customer. This a valuable
mechanism for gaining better understanding of the customer’s needs. Another
important use of the prototyping model is that it helps critically examine the technical
issues associated with the product development.
Requirements
Gathering

Quick
Design
Refine Build
Requirements Prototype

Customer
Customer evaluation of
Suggestions the prototype

Design

QMS/SE/TR01 Version 1.0 Page 4 of 12

 Software Engineering – Training Material

Acceptance by Customer
Implement

Test

Maintain

Classic Waterfall Model

In a typical model, a project begins with feasibility analysis. On successfully

demonstrating the feasibility of a project, the requirements analysis and project
planning begins. The design starts after the requirements analysis is complete, and
coding begins after the design is complete. Once the programming is completed, the
code is integrated and testing is done. On successful completion of testing, the system
is installed. After this, the regular operation and maintenance of the system takes
place.

System Requirements Analysis

Feasibility Feasibility And Project
Planning
Report Validation
Validation

Requirement Document
And Project Plan

System Detailed Design

Design
System Design
Verification Document Verification

Detailed
Design Document
Coding

Programs Testing and Integration

Verification

Test Plan, Test Report

And Manuals

Installation
Operation and Maintenance
Installation

QMS/SE/TR01 Version 1.0 Page 5 of 12

 Software Engineering – Training Material

Report
Typical Spiral Model

Developed by Barry Boehm in 1988. it provides the potential for rapid development of
incremental versions of the software. In the spiral model, software is developed in a
series of incremental releases. During early iterations , the incremental release might
be a paper model or prototype.

• Each iteration consists of

Planning, Risk Analysis, Engineering, Construction & Release & Customer
Evaluation.

Customer Communication: Tasks required to establish effective communication

between developer and customer.

Planning: Tasks required to define resources, timelines, and other project related
information.

Risk Analysis: Tasks required to assess both technical and management risks.

Engineering: Tasks required to build one or more representatives of the application.

Construction & Release: Tasks required to construct, test, install and provide user
support (e.g., documentation and training)

Customer evaluation: Tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage and
implemented during the installation state.

QMS/SE/TR01 Version 1.0 Page 6 of 12

 Software Engineering – Training Material

V – Process Model

RFP Process Feedback

Proposal Proposal Project Process

Study Review Project Process Process Review
Study
Accepted (Project Plan) Project
Proposal Closure Report

Actual Working System

Proposal
Requirement Acceptance
Acceptance Customer
Study Requirement Test Review
Review Test Plan
Requirement Delivered
Specification System

Approved Deliverable System

S.R.S
System Functional System
Analysis Specification System
Testing Certification
Review
Functional Test Plan Executable
Specification System

Approved Integrated Tested Code

S.R.S
Design Design Int.Test
Document Review Plan. Integration Integration
Testing
Design Unit Tested
Specification Code

Approved Unit Tested Code

S.D.S
Detailed Program Unit
Design Specification Unit Test Test Audit
Review T.P
Design Code
Specification

Approved
Legend S.P.S Entry Criteria
Coding Code
Inspection Task Validation
Design
Exit Criteria

QMS/SE/TR01 Version 1.0 Page 7 of 12

 Software Engineering – Training Material

What makes a good test engineer?

A good test engineer has a 'test to break' attitude, an ability to take the point of view
of the customer, a strong desire for quality, and an attention to detail. Tact and
diplomacy are useful in maintaining a cooperative relationship with developers, and an
ability to communicate with both technical (developers) and non-technical (customers,
management) people is useful. Previous software development experience can be
helpful as it provides a deeper understanding of the software development process,
gives the tester an appreciation for the developers' point of view, and reduce the
learning curve in automated test tool programming. Judgment skills are needed to
assess high-risk areas of an application on which to focus testing efforts when time is
limited.

What makes a good Software QA engineer?

The same qualities a good tester has are useful for a QA engineer. Additionally, they
must be able to understand the entire software development process and how it can fit
into the business approach and goals of the organization. Communication skills and the
ability to understand various sides of issues are important. In organizations in the
early stages of implementing QA processes, patience and diplomacy are especially
needed. An ability to find problems as well as to see 'what's missing' is important for
inspections and reviews.

• Testing

 An examination of the behavior of a program by executing on sample data sets.

 Testing comprises of set of activities to detect defects in a produced material.
 To unearth & correct defects
 To detect defects early & to reduce cost of defect fixing
 To avoid user detecting problems
 To ensure that product works as users expected it to.

Why Testing ?

• To unearth and correct defects.

• To detect defects early and to reduce cost of defect fixing.
• To ensure that product works as user expected it to.
• To avoid user detecting problems.

QMS/SE/TR01 Version 1.0 Page 8 of 12

 Software Engineering – Training Material

Types of Tests

Contract Other Tests

System Req. Spec. System Tests

Functional Spec. Functional Tests

H.LD. Integration Testing

L.L.D. Unit Testing

Test Life Cycle

• Identify Test Candidates

• Test Plan
• Design Test Cases
• Execute Tests
• Evaluate Results
• Document Test Results
• Casual Analysis/ Preparation of Validation Reports
• Regression Testing / Follow up on reported bugs.

Testing Techniques

• Black Box Testing

• White Box Testing
• Regression Testing
• These principles & techniques can be applied to any type of testing.

Black Box Testing

Testing of a function without knowing internal structure of the program.

White Box Testing

Testing of a function with knowing internal structure of the program.

QMS/SE/TR01 Version 1.0 Page 9 of 12

 Software Engineering – Training Material

Regression Testing

To ensure that the code changes have not had an adverse affect to the other modules
or on existing functions.

Functional Testing

 Study SRS
 Identify Unit Functions
 For each unit function
• Take each input function
• Identify Equivalence class
• Form Test cases
• Form Test cases for boundary values
• From Test cases for Error Guessing
 Form Unit function v/s Test cases, Cross Reference Matrix
 Find the coverage

Unit Testing:

The most 'micro' scale of testing to test particular functions or code modules. Typically
done by the programmer and not by testers
• Unit - smallest testable piece of software
• A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness
• Unit testing done to show that the unit does not satisfy the functional specification
and/ or its implemented structure does not match the intended design structure

Integration Testing:

Integration is a systematic approach to build the complete software structure specified

in the design from unit-tested modules. There are two ways integration performed. It
is called Pre-test and Pro-test.

1. Pre-test: the testing performed in Module development area is called Pre-test. The
Pre-test is required only if the development is done in module development area.
2. Pro-test: The Integration testing performed in baseline is called pro-test. The
development of a release will be scheduled such that the customer can break down
into smaller internal releases.

Alpha testing:

Testing of an application when development is nearing completion minor design

changes may still be made as a result of such testing. Typically done by end-users or
others, not by programmers or testers.

Beta testing:

QMS/SE/TR01 Version 1.0 Page 10 of 12

 Software Engineering – Training Material

Testing when development and testing are essentially completed and final bugs and
problems need to be found before final release. Typically done by end-users or others,
not by programmers or
System Testing:

• A system is the big component

• System testing is aimed at revealing bugs that cannot be attributed to a
component as such, to inconsistencies between components or planned interactions
between components
• Concern: issues, behaviors that can only be exposed by testing the entire
integrated system (e.g., performance, security, recovery).

Volume Testing:

The purpose of Volume Testing is to find weaknesses in the system with respect to its
handling of large amounts of data during short time periods. For example, this kind of
testing ensures that the system will process data across physical and logical
boundaries such as across servers and across disk partitions on one server.

Stress testing:

This refers to testing system functionality while the system is under unusually heavy or
peak load; it's similar to the validation testing mentioned previously but is carried out
in a "high-stress" environment. This requires that you make some predictions about
expected load levels of your Web site.

Usability testing:

Usability means that systems are easy and fast to learn, efficient to use, easy to
remember, cause no operating errors and offer a high degree of satisfaction for the
user. Usability means bringing the usage perspective into focus, the side towards the
user.

Security testing:

If your site requires firewalls, encryption, user authentication, financial transactions, or

access to databases with sensitive data, you may need to test these and also test your
site's overall protection against unauthorized internal or external access.

Test Plan:

A Test Plan is a detailed project plan for testing, covering the scope of testing, the
methodology to be used, the tasks to be performed, resources, schedules, risks, and
dependencies. A Test Plan is developed prior to the implementation of a project to
provide a well defined and understood project roadmap.

Test Specification:

A Test Specification defines exactly what tests will be performed and what their scope
and objectives will be. A Test Specification is produced as the first step in
implementing a Test Plan, prior to the onset of manual testing and/or automated test

QMS/SE/TR01 Version 1.0 Page 11 of 12

 Software Engineering – Training Material

suite development. It provides a repeatable, comprehensive definition of a testing

campaign

QMS/SE/TR01 Version 1.0 Page 12 of 12