Software Engineering - Part 2

Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation. For assessing user requirements,
an SRS (Software Requirement Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed requirements in software terms.
The output of this process can directly be used into implementation in programming languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.

Software Design Levels

Software design yields three levels of results:
Architectural Design - The architectural design is the highest abstract version of the system. It
identifies the software as a system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.
High-level Design - The high-level design breaks the ‘single entity multiple component’ concept
of architectural design into less-abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the system along with all of its
components can be implemented in forms of modules. It recognizes modular structure of each
sub-system and their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules

Modularization
Modularization is a technique to divide a software system into multiple discrete and independent
modules, which are expected to be capable of carrying out task(s) independently. These
modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.
Modular design unintentionally follows the rule of ‘divide and conquer’ problem solving strategy,
this is because there are many other benefits attached with the modular design of a software.
Advantage of modularization: Smaller components are easier to maintain Program can be
divided based on functional aspects Desired level of abstraction can be brought in the program
Components with high cohesion can be re-used again Concurrent execution can be made
possible Desired from security aspect
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential execution, we
mean that the coded instruction will be executed one after another implying only one portion of
program being activated at any given time. Say, a software has multiple modules, then only one
of all the modules can be found active at any time of execution. In software design, concurrency
is implemented by splitting the software into multiple independent units of execution, like

[Link] 1
Software Engineering - Part 2
modules and executing them in parallel. In other words, concurrency provides capability to the
software to execute more than one part of code in parallel to each other. It is necessary for the
programmers and designers to recognize those modules, which can be made parallel execution.
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules based on
some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as a single entity but, may refer to each other
to work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design. There are seven types of
cohesion, namely –
Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of
breaking the program into smaller modules for the sake of modularization. Because it is
unplanned, it may serve confusion to the programmers and is generally not-accepted.
Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.
Temporal Cohesion - When elements of module are organized such that they are processed at
a similar point of time, it is called temporal cohesion.
Procedural cohesion - When elements of module are grouped together, which are executed
sequentially in order to perform a task, it is called procedural cohesion.
Communicational cohesion - When elements of module are grouped together, which are
executed sequentially and work on same data (information), it is called communicational
cohesion.
Sequential cohesion - When elements of module are grouped because the output of one
element serves as input to another and so on, it is called sequential cohesion.
Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly
expected. Elements of module in functional cohesion are grouped because they all contribute to
a single well-defined function. It can also be reused.
Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a program.
It tells at what level the modules interfere and interact with each other. The lower the coupling,
the better the program. There are five levels of coupling, namely -
Content coupling - When a module can directly access or modify or refer to the content of
another module, it is called content level coupling.

[Link] 2
Software Engineering - Part 2
Common coupling- When multiple modules have read and write access to some global data, it
is called common or global coupling.
Control coupling- Two modules are called control-coupled if one of them decides the function of
the other module or changes its flow of execution.
Stamp coupling- When multiple modules share common data structure and work on different
part of it, it is called stamp coupling.
Data coupling- Data coupling is when two modules interact with each other by means of passing
data (as parameter). If a module passes data structure as parameter, then the receiving module
should use all its components.
Ideally, no coupling is considered to be the best.
Software Maintenance
Software maintenance is widely accepted part of SDLC nowadays. It stands for all the
modifications and updation done after the delivery of software product. There are number of
reasons, why modifications are required, some of them are briefly mentioned below:
Market Conditions - Policies, which changes over the time, such as taxation and newly
introduced constraints like, how to maintain bookkeeping, may trigger need for modification.
Client Requirements - Over the time, customer may ask for new features or functions in the
software.
Host Modifications - If any of the hardware and/or platform (such as operating system) of the
target host changes, software changes are needed to keep adaptability.
Organization Changes - If there is any business level change at client end, such as reduction of
organization strength, acquiring another company, organization venturing into new business,
need to modify in the original software may arise
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine
maintenance tasks as some bug discovered by some user or it may be a large event in itself
based on maintenance size or nature. Following are some types of maintenance based on their
characteristics:
Corrective Maintenance - This includes modifications and updations done in order to correct or
fix problems, which are either discovered by user or concluded by user error reports.
Adaptive Maintenance - This includes modifications and updations applied to keep the software
product up-to date and tuned to the ever changing world of technology and business
environment.
Perfective Maintenance - This includes modifications and updates done in order to keep the
software usable over long period of time. It includes new features, new user requirements for
refining the software and improve its reliability and performance

[Link] 3
Software Engineering - Part 2
Preventive Maintenance - This includes modifications and updations to prevent future problems
of the software. It aims to attend problems, which are not significant at this moment but may
cause serious issues in future.
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire software
process cycle.

On an average, the cost of software maintenance is more than 50% of all SDLC phases. There
are various factors, which trigger maintenance cost go high, such as:
Real-world factors affecting Maintenance Cost
The standard age of any software is considered up to 10 to 15 years.
Older softwares, which were meant to work on slow machines with less memory and storage
capacity cannot keep themselves challenging against newly coming enhanced softwares on
modern hardware.
As technology advances, it becomes costly to maintain old software.

[Link] 4
Software Engineering - Part 2
Most maintenance engineers are newbie and use trial and error method to rectify problem.
Often, changes made can easily hurt the original structure of the software, making it hard for
any subsequent changes.
Changes are often left undocumented which may cause more conflicts in future.
Software-end factors affecting Maintenance Cost
Structure of Software Program
Programming Language
Dependence on external environment
Staff reliability and availability
Maintenance activities
IEEE provides a framework for sequential maintenance process activities. It can be used in
iterative manner and can be extended so that customized items and processes can be included.

These activities go hand-in-hand with each of the following phase:

[Link] 5
Software Engineering - Part 2
Identification & Tracing - It involves activities pertaining to identification of requirement of
modification or maintenance. It is generated by user or system may itself report via logs or error
messages. Here, the maintenance type is classified also.
Analysis - The modification is analyzed for its impact on the system including safety and security
implications. If probable impact is severe, alternative solution is looked for. A set of required
modifications is then materialized into requirement specifications. The cost of
modification/maintenance is analyzed and estimation is concluded.
Design - New modules, which need to be replaced or modified, are designed against
requirement specifications set in the previous stage. Test cases are created for validation and
verification.
Implementation - The new modules are coded with the help of structured design created in the
design step. Every programmer is expected to do unit testing in parallel.
System Testing - Integration testing is done among newly created modules. Integration testing
is also carried out between new modules and the system. Finally the system is tested as a
whole, following regressive testing procedures.
Acceptance Testing - After testing the system internally, it is tested for acceptance with the help
of users. If at this state, user complaints some issues they are addressed or noted to address in
next iteration.
Delivery - After acceptance test, the system is deployed all over the organization either by small
update package or fresh installation of the system. The final testing takes place at client end
after the software is delivered.
Maintenance management - Configuration management is an essential part of system
maintenance. It is aided with version control tools to control versions, semi-version or patch
management.
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 Validation
Validation is process of examining whether or not 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.
Software Verification

[Link] 6
Software Engineering - Part 2
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.
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.
Manual Vs Automated Testing
Testing can either be done manually or using an automated testing tool:

 Manual - This testing is performed without taking help of automated testing tools. The
software tester prepares test cases for different sections and levels of the code,
executes the tests and reports the result to the manager.
Manual testing is time and resource consuming. The tester needs to confirm whether or
not right test cases are used. Major portion of testing involves manual testing.

 Automated This testing is a testing procedure done with aid of automated testing tools.
The limitations with manual testing can be overcome using automated test tools.
A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done
with manual testing. But to check if the web-server can take the load of 1 million users, it is quite
impossible to test manually.
There are software and hardware tools which helps tester in conducting load testing, stress
testing, regression testing.
Testing Approaches
Tests can be conducted based on two approaches –
1. Functionality testing
2. Implementation 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.

[Link] 7
Software Engineering - Part 2
Exhaustive tests are the best-desired method for a perfect testing. Every single possible value
in the range of the input and output values is tested. It is not possible to test each and every
value in real world scenario if the range of values is large.
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’, and problematic
otherwise.

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.
Black-box testing techniques:

 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 pair-wise 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
It is conducted to test program and its implementation, in order to improve code efficiency or
structure. It is also known as ‘Structural’ testing.

[Link] 8
Software Engineering - Part 2

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.
The below are some White-box testing techniques:

 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.
 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.
Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs parallel to
software development. Before jumping on the next stage, a stage is tested, validated and
verified.
Testing separately is done just to make sure that there are no hidden bugs or issues left in the
software. Software is tested on various levels -
Unit Testing
While coding, the programmer performs some tests on that unit of program to know if it is error
free. Testing is performed under white-box testing approach. Unit testing helps developers
decide that individual units of the program are working as per requirement and are error free.
Integration Testing
Even if the units of software are working fine individually, there is a need to find out if the units if
integrated together would also work without errors. For example, argument passing and data
updation etc.
System Testing
The software is compiled as product and then it is tested as a whole. This can be accomplished
using one or more of the following tests:

 Functionality testing - Tests all functionalities of the software against the requirement.

[Link] 9
Software Engineering - Part 2
 Performance testing - This test proves how efficient the software is. It tests the
effectiveness and average time taken by the software to do desired task. Performance
testing is done by means of load testing and stress testing where the software is put
under high user and data load under various environment conditions.
 Security & Portability - These tests are done when the software is meant to work on
various platforms and accessed by number of persons.
Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of
testing where it is tested for user-interaction and response. This is important because even if the
software matches all user requirements and if user does not like the way it appears or works, it
may be rejected.

 Alpha testing - The team of developer themselves perform alpha testing by using the
system as if it is being used in work environment. They try to find out how user would
react to some action in software and how the system should respond to inputs.
 Beta testing - After the software is tested internally, it is handed over to the users to use
it under their production environment only for testing purpose. This is not as yet the
delivered product. Developers expect that users at this stage will bring minute problems,
which were skipped to attend.
Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested
thoroughly to detect if there is any negative impact of the added code. This is known as
regression testing.
Testing Documentation
Testing documents are prepared at different stages
Before Testing
Testing starts with test cases generation. Following documents are needed for reference –

 SRS document - Functional Requirements document

 Test Policy document - This describes how far testing should take place before releasing
the product.
 Test Strategy document - This mentions detail aspects of test team, responsibility matrix
and rights/responsibility of test manager and test engineer.
 Traceability Matrix document - This is SDLC document, which is related to requirement
gathering process. As new requirements come, they are added to this matrix. These
matrices help testers know the source of requirement. They can be traced forward and
backward.
While Being Tested
The following documents may be required while testing is started and is being done:

[Link] 10
Software Engineering - Part 2
 Test Case document - This document contains list of tests required to be conducted. It
includes Unit test plan, Integration test plan, System test plan and Acceptance test plan.
 Test description - This document is a detailed description of all test cases and
procedures to execute them.
 Test case report - This document contains test case report as a result of the test.
 Test logs - This document contains test logs for every test case report.
After Testing
The following documents may be generated after testing :

 Test summary - This test summary is collective analysis of all test reports and logs. It
summarizes and concludes if the software is ready to be launched. The software is
released under version control system if it is ready to launch.
Testing vs. Quality Control & Assurance and Audit
We need to understand that software testing is different from software quality assurance,
software quality control and software auditing.

 Software quality assurance - These are software development process monitoring

means, by which it is assured that all the measures are taken as per the standards of
organization. This monitoring is done to make sure that proper software development
methods were followed.
 Software quality control - This is a system to maintain the quality of software product. It
may include functional and non-functional aspects of software product, which enhance
the goodwill of the organization. This system makes sure that the customer is receiving
quality product for their requirement and the product certified as ‘fit for use’.
 Software audit - This is a review of procedure used by the organization to develop the
software. A team of auditors, independent of development team examines the software
process, procedure, requirements and other aspects of SDLC. The purpose of software
audit is to check that software and its development process, both conform standards,
rules and regulations.
Top Down Integration Testing
Top-down integration testing is an integration testing technique used in order to simulate the
behaviour of the lower-level modules that are not yet integrated. Stubs are the modules that act
as temporary replacement for a called module and give the same output as that of the actual
product.
The replacement for the 'called' modules is known as 'Stubs' and is also used when the
software needs to interact with an external system.

Bottom up testing
Each component at lower hierarchy is tested individually and then the components that rely
upon these components are tested.

[Link] 11
Software Engineering - Part 2

[Link] 12