Software Engineering

Sunday, 7 February 2021

WBS- Work Breakdown Structure

WBS (Work Breakdown Structure) using MS Project can be achieved by Right click on the attribute Task name and then insert WBS field then the structure of the project will be as shown in fig

Wednesday, 3 February 2021

Reverse Engineering and Re-Engineering

Software Reverse Engineering

Software Reverse Engineering is a process of recovering the design, requirement specifications and functions of a product from an analysis of its code. It builds a program database and generates information from this.

The purpose of reverse engineering is to facilitate the maintenance work by improving the understandability of a system and to produce the necessary documents for a legacy system.

Reverse Engineering Goals:

Cope with Complexity.
Recover lost information.
Detect side effects.
Synthesise higher abstraction.
Facilitate Reuse.

Steps of Software Reverse Engineering:

1.Collection Information:

This step focuses on collecting all possible information (i.e., source design documents etc.) about the software.

2.Examining the information:

The information collected in step-1 as studied so as to get familiar with the system.

3.Extracting the structure:

This step concerns with identification of program structure in the form of structure chart where each node corresponds to some routine.

4.Recording the functionality:

During this step processing details of each module of the structure, charts are recorded using structured language like decision table, etc.

5.Recording data flow:

From the information extracted in step-3 and step-4, set of data flow diagrams are derived to show the flow of data among the processes.

6.Recording control flow:

High level control structure of the software is recorded.

7.Review extracted design:

Design document extracted is reviewed several times to ensure consistency and correctness. It also ensures that the design represents the program.

8.Generate documentation:

Finally, in this step, the complete documentation including SRS, design document, history, overview, etc. are recorded for future use.

Software Re-Engineering

Software Re-Engineering is the examination and alteration of a system to reconstitute it in a new form. The principles of Re-Engineering when applied to the software development process is called software re-engineering. It affects positively at software cost, quality, service to the customer and speed of delivery. In Software Re-engineering, we are improving the software to make it more efficient and effective.

Re-Engineering Goals:

Boost up productivity
Processes in continuity
Improvement opportunity
Reduction in risks
Saves time
Optimization

Re-Engineering cost factors:

The quality of the software to be re-engineered.
The tool support availability for engineering.
The extent of the data conversion which is required.
The availability of expert staff for Re-engineering.

Software Re-Engineering Activities:

1. Inventory Analysis:

Every software organisation should have an inventory of all the applications.

Inventory can be nothing more than a spreadsheet model containing information that provides a detailed description of every active application.
By sorting this information according to business criticality, longevity, current maintainability and other local important criteria, candidates for re-engineering appear.
The resource can then be allocated to a candidate application for re-engineering work.

2. Document reconstructing:

Documentation of a system either explains how it operates or how to use it.

Documentation must be updated.
It may not be necessary to fully document an application.
The system is business-critical and must be fully re-documented.

3. Reverse Engineering:

Reverse engineering is a process of design recovery. Reverse engineering tools extract data, architectural and procedural design information from an existing program.

4. Code Reconstructing:

To accomplish code reconstructing, the source code is analysed using a reconstructing tool. Violations of structured programming construct are noted and code is then reconstructed.

The resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced.

5. Data Restructuring:

Data restructuring begins with a reverse engineering activity.

Current data architecture is dissected, and the necessary data models are defined.

Data objects and attributes are identified, and existing data structure are reviewed for quality.

6. Forward Engineering:

Forward Engineering also called as renovation or reclamation not only for recovers design information from existing software but uses this information to alter or reconstitute the existing system in an effort to improve its overall quality.

STLC- Software Testing Life Cycle

There are following six major phases in every Software Testing Life Cycle Model (STLC Model):

Each of these stages has a definite Entry and Exit criteria, Activities & Deliverables associated with it.

What is Entry and Exit Criteria in STLC?

Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before testing can begin.

Exit Criteria: Exit Criteria defines the items that must be completed before testing can be concluded

You have Entry and Exit Criteria for all levels in the Software Testing Life Cycle (STLC)

Requirement Phase Testing or Requirement Analysis :

Requirement Phase Testing also known as Requirement Analysis in which test team studies the requirements from a testing point of view to identify testable requirements and the Quality Analysis (QA) team may interact with various stakeholders to understand requirements in detail. Requirements could be either functional or non-functional. Automation feasibility for the testing project is also done in this stage. The following are the Activities in Requirement Phase Testing

Identify types of tests to be performed.
Gather details about testing priorities and focus.
Prepare Requirement Traceability Matrix (RTM).
Identify test environment details where testing is supposed to be carried out.
Automation feasibility analysis (if required).
Deliverables of Requirement Phase Testing

Test Planning :

Test Planning in STLC is a phase in which a Senior Quality Analysis QA manager determines the test plan strategy along with efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations and the testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase. The following are the Activities in Test Planning

Preparation of test plan/strategy document for various types of testing
Test tool selection
Test effort estimation
Resource planning and determining roles and responsibilities.
Training requirement
Deliverables of Test Planning
Test plan /strategy document.
Effort estimation document.

Test Case Development Phase

The Test Case Development Phase involves the creation, verification and rework of test cases & test scripts after the test plan is ready. Initially, the Test data is identified then created and reviewed and then reworked based on the preconditions. Then the QA team starts the development process of test cases for individual units. The following are the Activities in Test Case Development

Create test cases, automation scripts (if applicable)
Review and baseline test cases and scripts
Create test data (If Test Environment is available)
Deliverables of Test Case Development
Test cases/scripts
Test data

Test Environment Setup

Test Environment Setup decides the software and hardware conditions under which a work product is tested. It is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development Phase. Test team may not be involved in this activity if the development team provides the test environment. The test team is required to do a readiness check (smoke testing) of the given environment. The following are the Activities in Test Environment Setup Activities

Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build

Test Execution Phase

Test Execution Phase is carried out by the testers in which testing of the software build is done based on test plans and test cases prepared. The process consists of test script execution, test script maintenance and bug reporting. If bugs are reported then it is reverted back to development team for correction and retesting will be performed. The following are the Activities in Test Execution Phase

Execute tests as per plan
Document test results, and log defects for failed cases
Map defects to test cases in RTM
Retest the Defect fixes
Track the defects to closure
Deliverables of Test Execution
Completed RTM with the execution status
Test cases updated with results
Defect reports

Test Cycle Closure

Test Cycle Closure phase is completion of test execution which involves several activities like test completion reporting, collection of test completion matrices and test results. Testing team members meet, discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from current test cycle. The idea is to remove process bottlenecks for future test cycles. The following are the Activities in Test Cycle Closure

Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical Business Objectives, Quality
Prepare test metrics based on the above parameters.
Document the learning out of the project
Prepare Test closure report
Qualitative and quantitative reporting of quality of the work product to the customer.
Test result analysis to find out the defect distribution by type and severity.

Sunday, 24 January 2021

Software Testing

Software Testing is evaluation of the software against requirements gathered from users and system specifications. Testing is conducted at the phase level in software development life cycle or at module level in program code. Software testing comprises of Validation and Verification.

Software Verification deals by Developer

Verification is the process of confirming if the software is meeting the business requirements, and is developed adhering to the proper specifications and methodologies.

• Verification ensures the product being developed is according to design specifications.

• Verification answers the question– "Are we developing this product by firmly following all design specifications ?"

• Verifications concentrates on the design and system specifications.

Software Validation deals by Tester

Validation is process of examining whether the software satisfies the user requirements. It is carried out at the end of the SDLC. If the software matches requirements for which it was made, it is validated.

• Validation ensures the product under development is as per the user requirements.

• Validation answers the question – "Are we developing the product which attempts all that user needs from this software ?".

• Validation emphasizes on user requirements.

Target of the test are -

Errors- These are actual coding mistakes made by developers. In addition, there is a difference in output of software and desired output, is considered as an error.

Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can cause system to fail.

Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when fault exists in the system.

Testing Approaches :

Tests can be conducted based on two approaches

1. Functionality testing or Black-Box testing

2. Implementation testing or White-Box testing

When functionality is being tested without taking the actual implementation in concern it is known as black-box testing. The other side is known as white-box testing where not only functionality is tested but the way it is implemented is also analyzed.

Black-box testing :

It is carried out to test functionality of the program and also called ‘Behavioral’ testing. The tester in this case, has a set of input values and respective desired results. On providing input, if the output matches with the desired results, the program is tested ‘ok’,

Black-box testing techniques:

In this testing method, the design and structure of the code are not known to the tester, and testing engineers and end users conduct this test on the software.

Equivalence class -

The input is divided into similar classes. If one element of a class passes the test, it is assumed that all the class is passed.

Boundary values -

The input is divided into higher and lower end values. If these values pass the test, it is assumed that all values in between may pass too.

Cause-effect graphing -

In both previous methods, only one input value at a time is tested. Cause (input) – Effect (output) is a testing technique where combinations of input values are tested in a systematic way.

Pair-wise Testing -

The behavior of software depends on multiple parameters. In pairwise testing, the multiple parameters are tested pairwise for their different values.

State-based testing -

The system changes state on provision of input. These systems are tested based on their states and input.

White-box testing techniques:

It is conducted to test program and its implementation, in order to improve code efficiency or structure. It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester. Programmers of the code conduct this test on the code.

A. Control-flow Testing

The purpose of the control-flow testing to set up test cases which covers all statements and branch conditions. The branch conditions are tested for both being true and false, so that all statements can be covered.

B. Control Structure Testing

Control structure testing is a part of White Box Testing. It includes the following methods:

Conditional Testing
Loop Testing
Data Validation Testing
Branch Testing/Path Testing

1. Conditional Testing

It is an approach to design test cases to exercise the logical conditions contained in a program module of an application.

2. Loop Testing

Loop testing is a white box testing technique that focuses exclusively on the validity of a loop construct.

Types of Loops

a) Simple Loop

b) Nested Loop

c) Concatenated Loop

d) Unstructured Loop

a) Simple Loop Testing

A simple loop is tested in the following way:

a. Skip the entire loop.

b. Make 1 pass through the loop.

c. Make 2 passes through the loop.

d. Make m passes through the loop where m<n, n is the maximum number of passes through the loop.

e. Make n, n-1, n+1 passes through the loop.

b) Nested Loop Testing

A nested loop is tested in the following way.

a. Start the innermost loop.

b. Conduct a simple loop test for the innermost loop.

c. Work outward, conducting a test for the next loop keeping all other loops at a minimum.

d. Continue until all the loops are tested.

c) Concatenated Loop Testing

To test the concatenated loops, the procedure is if the loops are independent then test them as simple loops otherwise test them as nested loops.

d) Unstructured Loop Testing

To test the unstructured loops we needs to restructure their design.

3. Data Validation Testing

In data validation testing it selects the test paths of a program according to the locations of definitions in the program.

In this type of testing the each statement in a program is assigned a unique statement number and each function does not modify its parameter or global variables.

In this type of testing the tester checks for the data which is calculated during the navigation on a different page and it is also known as data flow.

4. Branch Testing/Path Testing

A branch is the outcome of a decision, so branch testing simply measures which decision outcomes have been tested. In this testing it takes a more in-depth view of the source code.

Data-flow testing -

This testing technique emphasis to cover all the data variables included in the program. It tests where the variables were declared and defined and where they were used or changed.

Path Testing :

• Path Testing is another white box testing technique first proposed by Tom McCabe, which focuses in identifying independent paths in a program.

• The idea is to design test cases to exercise all independent paths at least once during testing.

• A easy way to identify paths in the program is the control flow graph ( CFG ).

• CFG (control flow graph) describes the flow of control in the program through program graph which consists of finite set of nodes and a finite set of directed edges.

• The nodes represent the executable blocks or the lines in the program .

• The edges represent flow of controls.

• CFG(control flow graph) mainly involves sequence, selection and iterative representation in the program flow.

Cyclomatic Complexity Model :

• It is also called conditional complexity and used to indicate the complexity of the given program.

• It was developed by Thomas J McCabe in 1976.

• It is computed using the control flow graph of the given program using the formula :

Cyclomatic Complexity Model (M) = E – N + 2P

Example 1:

Cyclomatic Complexity Model (M) = E – N + 2P

where E=8,N=7,P=1

(M) = 8 – 7 + 2*1

(M) = 1 + 2

(M) = 3

In the above example, we can see there are few conditional statements that is executed depending on what condition .Here there are 3 paths of condition that need to be tested to get the output.

Path 1 : 1,2,3,5,6,7

Path 2 : 1,2,4,5,6,7

Path 3 : 1,6,7

Example 2:

Cyclomatic Complexity Model (M) = E – N + 2P

where E = edge or Number of Edges in the control flow graph

E = 8

N = node or Number of Nodes in the control flow graph

N = 7

P =Number of connected components or Predicate node or Number of Nodes in the exit points

P = 1 ( for single Program the value of p=1)

Therefore the Cyclomatic Complexity Model (M) is

M = E – N + 2P

M = 8 – 7 + 2*1

M = 1 + 2

M = 3

Thursday, 21 January 2021

Software Quality Assurance

Software Testing is a process used to identify the correctness ,completeness, quality of the developed computer software

It also help to identify errors, gaps or missing requirement

It is done either manually or using software tools

General characteristics of strategic Testing

To perform effective testing, a software team should conduct technical reviews

Testing begins at the component level and work towards the integration of entire computer based system

Different testing techniques are appropriate at different points in time

Testing is done by developer of software and for large projects by an independent test group

Testing and debugging are different activities but debugging must be accommodated in any test strategy

Testing Strategies

Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design, and code generation.

It is not unusual for a software development organization to pay between 30 and 40 percent of total project effort on testing.

The engineer creates a series of test cases that are intended to "defeat" the software that has been built.

In fact, testing is the one step in the software process that could be viewed (psychologically, at least) as destructive rather than constructive.

Type of Testing Approach

Verification and Validation approach:

Verification: "Are we building the product right?"

Verification refers to the set of activities that ensure that software correctly implements a specific function.

Validation: "Are we building the right product?

Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.

SOFTWARE QUALITY ASSURANCE :

SOFTWARE QUALITY ASSURANCE (SQA) is a set of activities for ensuring quality in software engineering processes (that ultimately result in the quality of software products).

SQA Activities

It includes the following activities:

• Process definition and implementation

• Auditing

• Training

SQA Processes include:

• Software Development Methodology

• Project Management

• Configuration Management

• Requirements Development/Management

• Estimation

• Software Design

• Testing

Once the processes have been defined and implemented, Quality Assurance has the following responsibilities:

• identifying weaknesses in the processes

• correcting those weaknesses to continually improve the processes

The quality management system under which the software system is created is normally based on one or more of the following models/standards:

• CMM

• Six Sigma

• ISO 9000

Capability Maturity Model (CMM) :

CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1987.
It is not a software process model. It is a framework which is used to analyses the approach and techniques followed by any organization to develop a software product.
It also provides guidelines to further enhance the maturity of those software products.
It is based on profound feedback and development practices adopted by the most successful organizations worldwide.
This model describes a strategy that should be followed by moving through 5 different levels.
Each level of maturity shows a process capability level. All the levels except level-1 are further described by Key Process Areas (KPA’s).