GUJARAT TECHNOLOGICAL UNIVERSITY

V.V.P. ENGINEERING COLLEGE, RAJKOT

Department
Of
Computer Engineering

SOFTWARE ENGINEERING
(3150711)

PREPARED BY:
PROF. NIKHILESH N. GIRNARA
 INDEX

Sr. No. Content Page No.

1 Introduction to Software and Software Engineering 1

2 Agile Development 21

3 Managing Software Project 29

4 Requirement Analysis and Specification 38

5 Software Design 49

6 Software Coding and Testing 59

7 Quality Assurance and Management 72

8 Software Maintenance and Configuration Management 80

9 DevOps 89

10 Advanced Topics in Software Engineering 99

 Software Engineering (3150711)

Unit: 1
Introduction to Software and Software Engineering
1.1 The Evolving Role of Software:

Software Evolution is a term which refers to the process of developing software

initially, then timely updating it for various reasons, i.e., to add new features or to
remove obsolete functionalities etc.

The evolution process includes fundamental activities of change analysis, release

planning, system implementation and releasing a system to customers.

The cost an impact of these changes is accessed to see how much system is affected by
the change and how much it might cost to implement the change. If the proposed
changes are accepted, a new release of the software system is planned. During release
planning, all the proposed changes (fault repair, adaptation, and new functionality) are
considered.

A design is then made on which changes to implement in the next version of the system.
The process of change implementation is an iteration of the development process
where the revisions to the system are designed, implemented and tested.

Figure: Evolving role of software

1.2 Software: A Crisis on the Horizon and Software Myths

Software is a general term for the various kinds of programs used to
operate computers and related devices. (The term hardware describes the physical
aspects of computers and related devices.)
Software can be thought of as the variable part of a computer and hardware the
invariable part.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 1
 Software Engineering (3150711)

Software is often divided into application software (programs that do work users are
directly interested in) and system software (which includes operating systems and
any program that supports application software).

Software Crisis is a term used in computer science for the difficulty of writing useful and
efficient computer programs in the required time.

Software crisis was due to using same workforce, same methods, same tools even though
rapidly increasing in software demand, complexity of software and software challenges. With
increase in the complexity of software, many software problems arise because existing
methods were insufficient.

Since the early days of computing, the myths regarding the software engineering float around
the industry.

There are numbers of attributes included in the myths, that make them includes. In
developing a software, the developers put their extreme dedication and hard work.

A great majority of software related problems arises because of the myths that formed during
the software development’s initial stages. The most of the pressure and strain are on the
managers, who own the responsibilities of the software development.

Software Myths :

Management myths
1. Members acquires all the information.
2. Adding more people can reduce the time gap.
3. The management can relax themselves by outsourcing its project.
2. Customer myths
1. Software is malleable as a result of which changes are easy to accommodate.
2. Its easy functionality understood.
3. Developer myths
1. Once the code is delivered, the software can be called complete.
2. The software’s success depends on the product’s produced quality.
3. The assessment of the software quality can be addressed after the execution of the
program
4. The product, which is delivered after the project’s completion can be called working
program.

1.3 Software Engineering: A Layered Technology

Software engineering is a detailed study of engineering to the design, development
and maintenance of software.

Software engineering was introduced to address the issues of low-quality software

projects. Problems arise when software generally exceeds timelines, budgets, and

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 2
 Software Engineering (3150711)

reduced levels of quality. It ensures that the application is built consistently, correctly,
on time and on budget and within requirements.

The demand of software engineering also emerged to cater to the immense rate of
change in user requirements and environment on which application is supposed to be
working.

Software engineering is an engineering branch associated with development of

software product using well-defined scientific principles, methods and procedures. The
outcome of software engineering is an efficient and reliable software product.
Software project management has wider scope than software engineering process as it
involves communication, pre and post delivery support etc.
IEEE defines software engineering as: The application of a systematic, disciplined,
quantifiable approach to the development, operation and maintenance of software.

We can alternatively view it as a systematic collection of past experience. The

experience is arranged in the form of methodologies and guidelines.

A small program can be written without using software engineering principles. But if
one wants to develop a large software product, then software engineering principles
are absolutely necessary to achieve a good quality software cost effectively.

A Layered Technology:

Figure: Software engineering Layers

Divided into 4 layers:-

1. A quality Process:-
1. Any engineering approach must rest on an quality.
2. The "Bed Rock" that supports software Engineering is Quality Focus.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 3
 Software Engineering (3150711)

2. Process:-
1. Foundation for SE is the Process Layer
2. SE process is the GLUE that holds all the technology layers together and enables
the timely development of computer software.
3. It forms the base for management control of software project.
3. Methods:-
1. SE methods provide the "Technical Questions" for building Software.
2. Methods contain a broad array of tasks that include communication requirement
analysis, design modeling, program construction testing and support.
4. Tools:-
1. SE tools provide automated or semi-automated support for the "Process" and
the "Methods".
2. Tools are integrated so that information created by one tool can be used by
another.

1.4 Software Process Model:

A software process model is a simplified representation of a software process. These
generic models are abstractions of the process that can be used to explain different
approaches to the software development.
They can be adapted and extended to create more specific processes. Software
development process is the process of dividing software development work into
distinct phases to improve design, product management, and project management.
For example, there are many specific software development processes that fit the spiral
life-cycle model.

A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities are:

1. Software specifications: The functionality of the software and constraints on its

operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.

A software process model is a specified definition of a software process, which is

presented from a particular perspective. Models, by their nature, are a simplification, so
a software process model is an abstraction of the actual process, which is being
described.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 4
 Software Engineering (3150711)

Process models may contain activities, which are part of the software process, software product, and the
roles of people involved in software engineering. Some examples of the types of software process models
that may be produced are:

Process Flow – Describe how the framework activities and the actions and tasks that
occur within each framework activity are organized with respect to sequence and time.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 5
 Software Engineering (3150711)

Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the
consumer product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products
defects after putting into use due to ineffective testing technique. For example,
Software testing typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop and
the money involved. For example, Development of the FAA's Advanced
Automation System cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the
software takes longer than the estimated time to develop, which in turn leads to
cost shooting up. For example, one in four large-scale development projects are
never completed.

1.5 The Linear Sequential Model:

The linear sequential model sometimes called the classic life cycle or the
waterfall model suggests a systematic, sequential approach to software development
that begins at the system level and progresses through communication,
planning, modeling, construction, and deployment.

Linear sequential model for software engineering is also known as waterfall model.
The linear sequential model suggests a systematic sequential approach to software
development that begins at the system level and progresses through analysis, design,
coding, testing, and support.

Waterfall is also referred to as a linear-sequential life cycle model. It is very simple to

understand and use. In a waterfall model, each phase must be completed before the next
phase can begin and there is no overlapping in the phases. The waterfall model is the
earliest SDLC approach that was used for software development.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 6
 Software Engineering (3150711)

1. Communication Phase:
 Requirement are gathered
 The problem is specified along with the desired service objectives (goals).
 The constraints are identified.
 The system specification is produced from the requirement analysis. This
document should clearly define the product function.
2. Planning Phase:
 Planning is a critical activity in software development.
 A good plan is based on the requirements of the system and should be done
before later phase begin.
 However detailed requirement is not necessary for planning. It includes
activities like:
 Cost estimation to find best affordable cost.
 Task scheduling and timeline management.
 Work organization and team structure designing.
3. Modeling Phase:
 The system specification are translated into a software representation.
 The software engineer at this stage is concerned with:
i) Data Structure ii) Software Architecture iii) Algorithm detail and iv) Interface representation
4. Construction Phase:
 Coding is done.
 The implementation and testing is done.
 The designers are translated into the software domain.
 Detailed documentation from the design phase can significantly reduce the
coding effort.
 Testing at this stage focuses on making sure that errors are identified and the
software meets its required specification.
 All the program units integrated and tested to ensure that the complete system
meets the software requirements.
5. Deployment Phase:
 After construction the software is delivered to the customer.
 The system is handed over to the customer and will be used the first time by
them.
 All the problems which did not arise during the previous phase will be solved in
this last phase.
 Maintenance part is largest and never ending phase of software development.
 In this phase the software is updated to:
1. Meet the changing customer needs.
2. Adapted to accommodate change in the external environment.
3. Correct errors and oversights previously undetected in the testing phase.
4. Enhancing the efficiency of the software.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 7
 Software Engineering (3150711)

Advantages of Linear Sequential Model:

 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.

Disadvantages of Linear Sequential Model:

 Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk
of changing.

1.6 The Prototyping Model:

Prototype is a working model of software with some limited functionality. The

prototype does not always hold the exact logic used in the actual software application
and is an extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out
before implementation. It also helps understand the requirements which are user
specific and may not have been considered by the developer during product design.
The Software Prototyping refers to building software application prototypes which
displays the functionality of the product under development, but may not actually hold
the exact logic of the original software.
Software prototyping is becoming very popular as a software development model, as it
enables to understand customer requirements at an early stage of development.
It helps get valuable feedback from the customer and helps software designers and
developers understand about what exactly is expected from the product under
development.
The different phases of Prototyping model are:
1. Communication:
 In this phase, developer and customer meet and discuss the overall objectives of
the software.
2. Quick design:
 Quick design is implemented when requirements are known.
 It includes only the important aspects like input and output format of the
software.
 It focuses on those aspects which are visible to the user rather than the detailed
plan.
 It helps to construct a prototype.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 8
 Software Engineering (3150711)

Figure: The Prototyping Model

3. Modeling quick design:
 This phase gives the clear idea about the development of software because the
software is now built.
 It allows the developer to better understand the exact requirements.

4. Construction of prototype:
 The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback :

 If the user is not satisfied with current prototype then it refines according to the
requirements of the user.
 The process of refining the prototype is repeated until all the requirements of
users are met.
 When the users are satisfied with the developed prototype then the system is
developed on the basis of final prototype.

Advantages of Prototyping Model:

 Prototype model need not know the detailed input, output, processes,
adaptability of operating system and full machine interaction.
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the
user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 9
 Software Engineering (3150711)

 It identifies the missing functionality easily. It also identifies the confusing or

difficult functions.

Disadvantages of Prototyping Model :

 The client involvement is more and it is not always considered by the

developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.

1.7 The RAD Model:

The RAD (Rapid Application Development) model is based on prototyping and

iterative development with no specific planning involved. The process of writing the
software itself involves the planning required for developing the product.
Rapid Application Development focuses on gathering customer requirements through
workshops or focus groups, early testing of the prototypes by the customer using
iterative concept, reuse of the existing prototypes (components), continuous
integration and rapid delivery.
1. Business Modeling:
 The information flow among business functions is modeled in a way that answer
the following questions:
 What information drives the business process?
 What information is generated?  Where does the information go?
 Who generates it?  Who processes it ?

Figure: RAD Model

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 10
 Software Engineering (3150711)

2.Data Modeling:
 The characteristics/attributes of each object are identified and the relationships
between these objects are defined.
3.Process Modeling:
 The data objects defined in the data-modeling phase are transformed to achieve
the information flow necessary to implement a business function.
 Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.
4.Application Generation:
 RAD assumes the use of the fourth generation techniques and tools like VB, C++,
Delphi etc.
 Rather than creating software using conventional third generation programming
languages.
 The RAD works to reuse existing program components.
 In all cases, automated tools are used to facilitate construction of the software.
5. Testing and Turnover:
 Since the RAD process emphasizes reuse, many of the program components
have already been tested.
 This minimizes the testing and development time.
 However, new components must be tested and all interfaces must be fully
exercised.
 If a business application can be modularized to that each major function can be
completed within the development cycle then it is a right candidate for the RAD
model.
 In this case, each team can be assigned a model, which is then integrated to form
a whole.

When to use RAD Methodology ?

 When a system needs to be produced in a short span of time (2-3 months)
 When the requirements are known.
 When the user will be involved all through the life cycle.
 When technical risk is less.
 When there is a necessity to create a system that can be modularized in 2-3
months of time.
 When a budget is high enough to afford designers for modeling along with the
cost of automated tools for code generation.

Advantages of RAD Model:

 Flexible and adaptable to changes.
 It is useful when you have to reduce the overall project risk.
 It is adaptable and flexible to changes.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 11
 Software Engineering (3150711)

Disadvantages of RAD Model:

 It can't be used for smaller projects.
 When technical risk is high, it is not suitable.
 Requires highly skilled developers/designers.
 High dependency on modeling skills

1.7 The Evolutionary Process Model:

Evolutionary model is a combination of Iterative and Incremental model of software

development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial
requirements and architecture envisioning need to be done.

It is better for software products that have their feature sets redefined during
development because of user feedback and other factors. The Evolutionary
development 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.

Feedback is provided by the users on the product for the planning stage of the next
cycle and the development team responds, often by changing the product, plan or
process. Therefore, the software product evolves with time. All the models have the
disadvantage that the duration of time from start of the project to the delivery time of a
solution is very high. Evolutionary model solves this problem in a different approach.

Evolutionary model suggests breaking down of work into smaller chunks, prioritizing
them and then delivering those chunks to the customer one by one. The number of
chunks is huge and is the number of deliveries made to the customer.

The main advantage is that the customer’s confidence increases as he constantly gets
quantifiable goods or services from the beginning of the project to verify and validate
his requirements. The model allows for changing requirements as well as all work in
broken down into maintainable work chunks.

Application of Evolutionary Model:

 It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants
to start using the core features instead of waiting for the full software.
 Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.
Advantages:
 In evolutionary model, a user gets a chance to experiment partially developed
system.
 It reduces the error because the core modules get tested thoroughly.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 12
 Software Engineering (3150711)

Disadvantages:
 Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.

1.8 The spiral Model:

The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.

This Spiral model is a combination of iterative development process model and

sequential linear development model i.e. the waterfall model with a very high emphasis
on risk analysis. It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.

Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it looks
like a spiral with many loops. The exact number of loops of the spiral is unknown and
can vary from project to project.

Each loop of the spiral is called a Phase of the software development process. The
exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks. As the project manager dynamically
determines the number of phases, so the project manager has an important role to
develop a product using spiral model.

 Spiral model is a risk driven process model.

 It is used for generating the software projects.
 In spiral model, an alternate solution is provided if the risk is found in the risk
analysis, then alternate solutions are suggested and implemented.
 It is a combination of prototype and sequential model or waterfall model.
 In one iteration all activities are done, for large project's the output is small.

Figure: The Spiral Model

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 13
 Software Engineering (3150711)

1. Objectives determination and identify alternative solutions: Requirements

are gathered from the customers and the objectives are identified, elaborated and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with
that solution is identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, Prototype is built for the best possible
solution.
3. Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third
quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for the
next phase is started.

When to use Spiral Model ?

 When there is a budget constraint and risk evaluation is important.

 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer
feedback.
 Significant changes are expected in the product during the development cycle.

Advantages of Spiral Model :

 It reduces high amount of risk.

 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.

Disadvantages of Spiral Model :

 It can be costly to develop a software model.

 It is not used for small projects.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 14
 Software Engineering (3150711)

1.9 Agile Process Model:

 The meaning of Agile is swift or versatile."Agile process model" refers to a

software development approach based on iterative development. Agile methods
break tasks into smaller iterations, or parts do not directly involve long term
planning.
 The project scope and requirements are laid down at the beginning of the
development process. Plans regarding the number of iterations, the duration and
the scope of each iteration are clearly defined in advance.
 Each iteration is considered as a short time "frame" in the Agile process model,
which typically lasts from one to four weeks. The division of the entire project
into smaller parts helps to minimize the project risk and to reduce the overall
project delivery time requirements. Each iteration involves a team working
through a full software development life cycle including planning, requirements
analysis, design, coding, and testing before a working product is demonstrated to
the client.

Following are the phases in the Agile model are as follows:

 Requirements gathering
 Design the requirements
 Construction/ iteration
 Testing/ Quality assurance
 Deployment
 Feedback

1.Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility.

2.Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to
your existing system.

3.Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a
working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 15
 Software Engineering (3150711)

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

1.10 Iterative Process Model:

An iterative life cycle model does not start with a full specification of requirements.
In this model, the development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements.

Moreover, in iterative model, the iterative process starts with a simple implementation
of a small set of the software requirements, which iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed. Each
release of Iterative Model is developed in a specific and fixed time period, which is
called iteration.

Furthermore, this iteration focuses on a certain set of requirements. Each cycle ends
with a usable system i.e., a particular iteration results in an executable release.
Iterative Model allows accessing previous phases, in which the changes are made
accordingly.

The final output of the product is revived at the end of the Software Development
Life Cycle (SDLC). Typically iterative development is used in conjunction with
incremental development, in which a longer software development cycle is split into
smaller segments that are built upon each other. Hence, iterative model is used in
following scenarios:

 When the requirements of the complete system are clearly defined and
understood.
 The major requirements are defined, while some functionalities and requested
enhancements evolve with the process of the development process.
 A new technology is being used and is being learnt by the development team,
while they are working on the project.
 If there are some high risk features and goals, which might change in the future.
 When the resources with needed skill sets are not available and are planned to be
used on contract basis for specific iterations.

Process of Iterative Model:

 The process of Iterative Model is cyclic, unlike the more traditional models that
focus on a rigorous step-by-step process of development. In this process, once
the initial planning is complete, a handful of phases are repeated again and
again, with the completion of each cycle incrementally improving and iterating
on the software. Other phases of the iterative model are described below:

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 16
 Software Engineering (3150711)

Figure: Iterative Process Model

Advantages of Iterative Model:

 Some working functionality can be developed and early in the software
development life cycle (SDLC).
 It is easily adaptable to the ever changing needs of the project as well as the
client.
 It is best suited for agile organizations.
 It is more cost effective to change the scope or requirements in Iterative model.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily
managed.
 One can get reliable user feedback, when presenting sketches and blueprints of
the product to users for their feedback.

Disadvantages of Iterative Model:

 More resources may be required.

 Although cost of change is lesser, but it is not very suitable for changing
requirements.
 More management attention is required.
 It is not suitable for smaller projects.
 Highly skilled resources are required for skill analysis.
 Project progress is highly dependent upon the risk analysis phase.
 Defining increments may require definition of the complete system.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 17
 Software Engineering (3150711)

1.11 The Incremental Model:

Incremental Model is a process of software development where requirements are
broken down into multiple standalone modules of software development cycle.
Incremental development is done in steps from analysis design, implementation,
testing/verification, maintenance.

Each iteration passes through the requirements, design, coding and testing phases.
And each subsequent release of the system adds function to the previous release until
all designed functionality has been implemented.

The system is put into production when the first increment is delivered. The first
increment is often a core product where the basic requirements are addressed, and
supplementary features are added in the next increments. Once the core product is
analyzed by the client, there is plan development for the next increment.

Figure: Incremental Model

Characteristics of an Incremental module includes
 System development is broken down into many mini development projects.
 Partial systems are successively built to produce a final total system.
 Highest priority requirement is tackled first.
 Once the requirement is developed, requirement for that increment are frozen.

Advantages of Incremental Model:

 You can develop prioritized requirements first.
 Initial product delivery is faster.
 Customers get important functionality early.
 Requirements changes can be easily accommodated.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 18
 Software Engineering (3150711)

Disadvantages of Incremental Model:

 Requires effective planning of iterations.
 Requires efficient design to ensure inclusion of the required functionality and
provision for changes later.
 Well-defined module interfaces are required, as some are developed long before
others are developed.
 Total cost of the complete system is not lower.

1.12 Component Based Development:

Component-based development (CBD) techniques involve procedures for
developing software systems by choosing ideal off-the-shelf components and then
assembling them using a well-defined software architecture. With the systematic
reuse of coarse-grained components, CBD intends to deliver better quality and output.

Component-based development is a procedure that accentuates the design and

development of computer-based systems with the help of reusable software
components. With CBD, the focus shifts from software programming to software
system composing.

Component-Based Development offers yet another approach to that of software

development.Software applications are built using components, and these
components can come from a number of different sources, be written in several
different programming languages, etc.

Component-based development (CBD) is a procedure that accurate the design and

development of computer-based systems with the help of reusable software
components. With CBD, the focus shifts from software programming to software
system composing.

The key goals of CBD are as follows:

 Save time and money when building large and complex systems
 Enhance the software quality
Some advantages of CBD include:
 Minimized delivery
 Improved Efficiency
 Improved quality
1.12 Process:
Process means a program in execution. Process execution must progress in
sequential order. It is also called task. Task is single instance of an executable
program.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 19
 Software Engineering (3150711)

Process is an active entity that requires a set of resources, including a processor,

program counter, registers to perform its function. Multiple processes may be
associated with one program.

A process is used as a fundamental unit for resources allocation in operating system.

Product and Process:

Product:
In the context of software engineering, Product includes any software manufactured
based on the customer’s request. This can be a problem solving software or computer
based system. It can also be said that this is the result of a project.

Process:
Process is a set of sequence steps that have to be followed to create a project. The
main purpose of a process is to improve the quality of the project. The process serves
as a template that can be used through the creation of its examples and is used to
direct the project.

The main difference between a process and a product is that the process is a set of
steps that guide the project to achieve the convenient product. While on the other
hand, the product is the result of a project that is manufactured by a wide variety of
people.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 20
 Software Engineering (3150711)

Unit: 2
Agile Development
2.1 Agility and Agile Process Model:

Agility:

 Effective (rapid and adaptive) response to change.

 Effective communication among all stakeholders.
 Drawing the customer onto the team.
 Organizing a team so that it is in control of the work performed.
 The motivation of the agile approach is already clear from the choice of name.
 Agile means to be swift or versatile and refers to rapid reaction to changes in
framework conditions.
 Changes attributable to new technology,

Agile principles:
 The highest priority of this process is to satisfy the customer.
 Acceptance of changing requirement even late in development.
 Frequently deliver a working software in small time span.
 Throughout the project business people and developers work together on daily
basis.
 Projects are created around motivated people if they are given the proper
environment and support.
 Face to face interaction is the most efficient method of moving information in the
development team.
 Primary measure of progress is a working software.
 Agile process helps in sustainable development.
 Continuous attention to technical excellence and good design increases agility.
 From self organizing teams the best architecture, design and requirements are
emerged.
 Simplicity is necessary in development.

Agile Process Model:

The Agile model was primarily designed to help a project to adapt to change requests
quickly. So, the main aim of the agile model is to facilitate quick project completion.
To accomplish this task agility is required. Agility is achieved by fitting the process to
the project, removing activities that may not be essential for a specific project. Also,
anything that is wastage of time and effort is avoided.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 21
 Software Engineering (3150711)

Actually Agile model refers to a group of development processes. These processes share
some basic characteristics but do have certain subtle differences among themselves.
A few Agile SDLC models are given below:
 Extreme programming (XP)
 Feature-driven development
 Scrum
 Lean development
 Unified process

In the Agile model, the requirements are decomposed into many small parts that can be
incrementally developed. The Agile model adopts Iterative development.
Each incremental part is developed over an iteration. Each iteration is intended to be
small and easily manageable and that can be completed within a couple of weeks only.
At a time one iteration is planned, developed and deployed to the customers. Long-term
plans are not made.
Agile model is the combination of iterative and incremental process models. Steps
involve in agile SDLC models are:
 Requirement gathering
 Requirement Analysis
 Design
 Coding
 Unit testing
 Acceptance testing

2.2 Extreme Programming:

Extreme Programming is a software development methodology designed to improve

the quality of software and its ability to properly adapt to the changing needs of the
customer or client.
Software Engineering involves −
Creativity
Learning and improving through trials and errors
Iterations
Extreme Programming builds on these activities and coding. It is the detailed (not the
only) design activity with multiple tight feedback loops through effective
implementation, testing and refactoring continuously.

 The Extreme Programming is commonly used agile process model.

 It uses the concept of object-oriented programming.
 A developer focuses on the framework activities like planning, design, coding
and testing. XP has a set of rules and practices.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 22
 Software Engineering (3150711)

Figure: The Extreme Programming Process

The XP Process:
The XP process comprises four framework activities:
1. Planning: Planning starts with the requirements gathering which enables XP
team to understand the rules for the software. The customer and developer work
together for the final requirements.
2. Design: The XP design follows the 'keep it simple' principle. A simple design
always prefers the more difficult representation.
3. Coding: The coding is started after the initial design work is over. After the initial
design work is done, the team creates a set of unit tests which can test each
situation that should be a part of the release.
The developer is focused on what must be implemented to pass the test. It is an
important concept in coding activity.
4. Testing: Validation testing of the system occurs on a daily basis. It gives the XP
team a regular indication of the progress. 'XP acceptance tests' are known as the
customer test.
Advantages of Extreme Programming:
 Fever documentation is required.
 Collaboration with customer.
 Flexibility to developer.
 Easy to manage.
Disadvantages of Extreme Programming:
 Depends heavily on customer interaction.
 Transfer on technology to new team members may be quite challenging due to
lack of documentation.

2.3 Other process models of Agile Development and Tools:

1. Dynamic Systems Development Method (DSDM):

Dynamic Systems Development Method is an iterative approach to software
development but adds additional discipline and structure to the process. Central to
DSDM is the principle that “any project must be aligned to clearly defined strategic
goals and focus upon early delivery of real benefits to the business.”

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 23
 Software Engineering (3150711)

 Dynamic Systems Development Method (DSDM) is an organized, common-sense

process focused on delivering business solutions quickly and efficiently.
 It is similar in many ways to SCRUM and XP, but it has its best uses where the
time requirement is fixed.
 The DSDM Consortium was looking to create a more advanced version of a RAD
framework that also had agile principles, although the term “Agile” was not
exactly the formal marker that it is today.
 DSDM focuses on delivery of the business solution, rather than just team activity.
 It makes steps to ensure the feasibility and business sense of a project before it is
created.

Figure: DSDM Life Cycle (with permission of the DSDM consortium)

Key Principles of the Dynamic Systems Development Method

1. Focus on the Business Need: DSDM teams must establish a valid business case and
ensure organizational support throughout the project.
2. Deliver on Time: Work should be time-boxed and predictable, to build confidence in
the development team.
3. Collaborate: DSDM teams must involve stakeholders throughout the project and
empower all members of the team to make decisions.
4. Quality: To ensure high quality, the level of quality should be agreed with the business
at the start of the project. This is enforced through continuous testing, review, and
documentation.
5. Build Incrementally from Firm Foundations: Teams must do Enough Design Work
Up Front (EDUF) to ensure they know exactly what to build, but not too much to slow
development.
6. Developer Iteratively: Take feedback from the business and use this to continually
improve with each development iteration. Teams must also recognize that details
emerge as the project or product develops and they must respond to this.
7. Communicate Continuously and Clearly: Holding daily stand-up sessions,
encouraging informal communication, running workshops and building prototypes are
all key DSDM tools. Communicating through documents is discouraged - instead,
documentation must be lean and timely.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 24
 Software Engineering (3150711)

8. Demonstrate Control: The Project Manager and Team Leader should make their plans
and progress visible to all and focus on successful delivery.

Advantages of Dynamic Systems Development Method:

 Projects are delivered on time, whilst still allowing flexibility
 Progress can be easily understood across the organization
 Business cases are at the core of the DSDM model, ensuring delivered projects have
real business value.
Disadvantages of the Dynamic Systems Development Method
 Large management overhead and costly implementation makes this unsuitable for
small organizations
 DSDM can be restrictive and inhibit developer creativity. Projects are likely to be
completed exactly as specified, even if more elegant solutions are available.

2. Scrum:
Scrum is an agile development methodology used in the development of Software
based on iterative and incremental processes. Scrum is adaptable, fast, flexible and
effective agile framework that is designed to deliver value to the customer throughout
the development of the project.

The primary objective of Scrum is to satisfy the customer’s need through an

environment of transparency in communication, collective responsibility and
continuous progress. The development starts from a general idea of what needs to be
built, elaborating a list of characteristics ordered by priority (product backlog) that
the owner of the product wants to obtain.

Scrum Methodology & Process

Scrum is precisely an evolution of Agile Management. Scrum methodology is based on a

set of much defined practices and roles that must be involved during the software
development process. It is a flexible methodology that rewards the application of the 12
agile principles in a context agreed by all the team members of the product.

Scrum is executed in temporary blocks that are short and periodic, called Sprints, which
usually range from 2 to 4 weeks, which is the term for feedback and reflection. Each
Sprint is an entity in itself, that is, it provides a complete result, a variation of the final
product that must be able to be delivered to the client with the least possible effort
when requested.

The process has as a starting point, a list of objectives/ requirements that make up the
project plan. It is the client of the project that prioritizes these objectives considering a
balance of the value and the cost thereof, that is how the iterations and consequent
deliveries are determined.

On the one hand the market demands quality, fast delivery at lower costs, for which a
company must be very agile and flexible in the development of products, to achieve
short development cycles that can meet the demand of customers without undermining

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 25
 Software Engineering (3150711)

the quality of the result. It is a very easy methodology to implement and very popular
for the quick results it gets.

Scrum methodology is used mainly for software development, but other sectors are
also taking advantage of its benefits by implementing this methodology in their
organizational models such as sales, marketing, & HR teams etc.

Figure: Scrum process Flow

3. Feature-Driven Development (FDD):

Feature-Driven Development (FDD) is one of the agile processes not talked or written
about very much. Often mentioned in passing in agile software development books and
forums, few actually know much about it.

However, if you need to apply agile to larger projects and teams, it is worthwhile taking
the time to understand FDD a little more.

The natural habitat of Scrum and XP-inspired approaches is a small team of skilled and
disciplined developers. It remains a significant challenge to scale these approaches to
larger projects and larger teams. Some have been successful but many have struggled.

Feature-driven development (FDD) is an iterative and incremental

software development process.It is a lightweight or Agile method for developing
software.

FDD blends a number of industry-recognized best practices into a cohesive whole.

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and
programmatic software process.

The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as
project stakeholders or eXtreme Programming (XP) calls customers.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 26
 Software Engineering (3150711)

 Originally proposed by Peter Coad

 FDD—distinguishing features
Emphasis is on defining “features”
a feature “is a client-valued function that can be implemented in two
weeks or less.”
 A features list is created and “plan by feature” is conducted
 Design and construction merge in FDD

Figure: Feature Driven Development Model

Overview of the 5 processes of FDD:

1. Developing an overall model
2. Building the feature list
3. Planning by feature
4. Designing by feature
5. Building by feature

 Scrum, we use XP programming, FDD and more, so I think it can be interesting to

make a brief comparison of those 3.
 Feature Driven Design has a bit of eXtreme Programming as well as a bit
of Scrum but adding to them Domain Driven Design techniques.
 What is great is that it is very easy to work in large teams using FDD. It’s actually
extremely scalable.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 27
 Software Engineering (3150711)

2.3 Agile Modeling:

Agile modeling (AM) is a methodology for modeling and

documenting software systems based on best practices.. It is part of the agile
software development tool kit.

Agile modeling is a supplement to other agile development methodologies such as

Scrum, extreme programming (XP), and Rational Unified Process (RUP).

 Agile Modeling (AM) is a practice-based methodology for effective modeling and

documentation of software-based systems.
 Simply put, Agile Modeling (AM) is a collection of values, principles, and practices
for modeling software that can be applied on a software development project in
an effective and light-weight manner.
 Suggests a set of agile modeling principles
◦ Model with a purpose
◦ Use multiple models
◦ Content is more important than representation
◦ Know the models and the tools you use to create them
◦ Adapt locally

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 28
 Software Engineering (3150711)

Unit: 3
Managing Software Project
3.1 Software Metrics (Process, Product and Project Metrics):
A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including
measuring software performance, planning work items, measuring productivity, and
many other uses.

Within the software development process, many metrics are that are all connected.
Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.

Software metrics is a standard of measure that contains many activities which involve
some degree of measurement. It can be classified into three categories: product metrics,
process metrics, and project metrics.

 Process metrics can be used to improve software development and

maintenance. Examples include the effectiveness of defect removal during
development, the pattern of testing defect arrival, and the response time of the
fix process.
 Product metrics describe the characteristics of the product such as size,
complexity, design features, performance, and quality level.
 Project metrics describe the project characteristics and execution. Examples
include the number of software developers, the staffing pattern over the life
cycle of the software, cost, schedule, and productivity.

Scope of Software Metrics:

Software metrics contains many activities which include the following −
 Cost and effort estimation
 Productivity measures and model
 Data collection
 Quantity models and measures
 Reliability models
 Performance and evaluation models
 Structural and complexity metrics
 Capability – maturity assessment
 Management by metrics
 Evaluation of methods and tools

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 29
 Software Engineering (3150711)

3.2 Software Project Estimations:

Project estimation is a process of forecasting or approximating
the project parameters like cost, time, effort etc., for a successful completion of
the project.

The four major parameters that control the software projects are time, requirements,
resources people, infrastructure/materials and money, and risks. This is one of the
reasons why making good estimates of these variables like time and resources
required for a project is very critical.

But if the estimation is lower than the project needs it will affect the progress of the project
due to the lack of enough time, money, infrastructure/materials, or people.

The four basic steps in Software Project Estimation are:

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Objectives:

 To introduce the fundamentals of software costing and pricing.

 To describe three metrics for software productivity assessment.
 To explain why different techniques should be used for software estimation.
 To describe the COCOMO algorithmic cost estimation model.

Observation on Estimation

Planning requires you to make an initial commitment, even though it’s likely that this
“commitment” will be proven wrong. Estimation carries natural risk and this risk leads
to uncertainty:-
Project complexity.
Project size
The degree of structural uncertainty.

Estimation Guidelines

One should keep the following guidelines in mind while estimating a project −
 During estimation, ask other people's experiences. Also, put your own
experiences at task.
 Resources working on multiple projects take longer to complete tasks because
of the time lost switching between them.
 Include management time in any estimate.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 30
 Software Engineering (3150711)

 Always build in contingency for problem solving, meetings and other

unexpected events.
 Allow enough time to do a proper project estimate. Rushed estimates are
inaccurate, high-risk estimates. For large development projects, the estimation
step should really be regarded as a mini project.
 Use developer-based estimates, as the estimates prepared by people other than
those who will do the work will be less accurate.
 Use several different people to estimate and use several different estimation
techniques.

1. Lines of code:

LOC is a software metric used to measure the size of a computer program by

counting the number of lines in the text of the program's source code.
SLOC is typically used to predict the amount of effort that will be required to
develop a program, as well as to estimate programming
productivity or maintainability once the software is produced.

The size is estimated by comparing it with the existing systems of same kind. The
experts use it to predict the required size of various components of software and
then add them to get the total size.

 The LOC (Line of Code) is a product size metric in software engineering.

 Here, the number of lines in the code are counted and based on the number of
lines the cost is calculated.
 There is no definite clear picture of how to count number of lines because the
length and complexity of the code is different in different languages.
 It only depends on the length but not on complexity and functionality.

Let us consider one simple example

 Based on historical data, assume the average productivity is as follows:

 Number of LOC per month: $500 LOC/month.
 The cost per month: $9000
 Therefore, cost estimation per line of code is $9000/$500 = $18 / LOC
 Consider one more example with code snippet:

for ( i=0; i<50; i++ )

printf (“LOC”); // Number of LOC

 From the above example we have

 2 physical lines of code.
 2 logical line of code (printf statement and for statement)
 1 comment line
 The same code snippet can be written in a different style

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 31
 Software Engineering (3150711)

for ( i=0; i<50; i++ )

{
printf (“LOC”);
}
/* How many lines are there in the above code snippet */
 There are
 5 physical line of code.
 2 statement of lines.
 1 comment line.
Advantages :
 Universally accepted and is used in many models like COCOMO.
 Estimation is closer to developer’s perspective.
 Simple to use.
Disadvantages :
 Different programming languages contains different number of lines.
 No proper industry standard exist for this technique.
 It is difficult to estimate the size using this technique in early stages of
project.

2. Function Points:
A Function Point (FP) is a unit of measurement to express the amount of business
functionality, an information system (as a product) provides to a user. FPs measure
software size.

They are widely accepted as an industry standard for functional sizing. A function
point (FP) is a component of software development which helps to approximate the
cost of development early in the process.

It is a process which defines the required functions and their complexity in a piece
of software in order to estimate the software's size and scope upon completion.

A function point calculates software size with the help of logical design and
performance of functions as per user requirements.

It also helps in determining the business functionality of a software application.

A function point has a number of benefits, including increase in productivity and

reduction in the risk of inflation of created code. The number of function points in a
code depends on function complexity.

Based on a combination of program characteristics :

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 32
 Software Engineering (3150711)

◦ External inputs and outputs

◦ User interactions
◦ External interfaces
◦ Files used by the system
 A weight is associated with each of these.
Advantages:
 It can be applied early in the software development life cycle.
 It is independent of the programming language, technology, techniques.
 Creation of more function points can define productivity goal as opposed to LOC.
 They can be counted early and often.
 They can be used for GUI systems.
Disadvantages:
 It needs subjective evaluations with a lot of judgment involved.
 Without historical data, it is difficult to improve estimating skill.
 Function points do not reflect language, design, or style differences.
 Function points are designed for estimating commercial data processing
applications.

3.3 Software Project Planning:

A Software Project is the complete methodology of programming advancement from
requirement gathering to testing and support, completed by the execution procedures,
in a specified period to achieve intended software product.

Once a project is found to be possible, computer code project managers undertake

project designing. Project designing is undertaken and completed even before any
development activity starts. Project designing consists of subsequent essential
activities:
Estimating the subsequent attributes of the project:
 Project size: What’s going to be downside quality in terms of the trouble and time
needed to develop the product?
 Cost: What proportion is it reaching to value to develop the project?
 Duration: However long is it reaching to want complete development?
 Effort: What proportion effort would be required?

 Project Planning helps in :

 Facilitating communication
 Monitoring/measuring the project progress, and
 Provides overall documentation of assumptions/planning decisions

 The Project Planning Phases can be broadly classified as follows:

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 33
 Software Engineering (3150711)

 Development of the Project Plan

 Execution of the Project Plan
 Change Control and Corrective Actions

Project Planning is an ongoing effort throughout the Project Lifecycle. The Project
Planning tasks ensure that various elements of the Project are coordinated and
therefore guide the project execution.

A detailed plan stating stepwise strategy to achieve the listed objectives is an integral
part of any project.
Planning consists of the following activities:
1. Set objectives or goals
2. Develop strategies
3. Develop project policies
4. Determine courses of action
5. Making planning decisions
6. Set procedures and rules for the project
7. Develop a software project plan
8. Prepare budget
9. Conduct risk management
10. Document software project plans

3.4 Project Scheduling and Tracking:

Project Scheduling helps to establish a roadmap for project managers together with
estimation methods and risk analysis. Project scheduling and Tracking begins with the
identification of process models, identification of software tasks and activities,
estimation of effort and work and ends with creation of network of tasks and making
sure it gets done on time. This network is adapted on encountering of changes and
risks.

The objective of software project scheduling is to create a set of engineering tasks that
will enable to complete the job in time.

Project scheduling is a mechanism to communicate what tasks need to get done and
which organizational resources will be allocated to complete those tasks in what
timeframe.

A project schedule is a document collecting all the work needed to deliver

the project on time. In project management, a schedule is a listing of a project's
milestones, activities, and deliverables, usually with intended start and finish dates.
Software project scheduling is an activity that distributes estimated effort across the
duration of project cycle by allocating effort to each specific task that is associated with
all process.
Project scheduling occurs during the planning phase of the project. You have to ask
yourself three questions to start:

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 34
 Software Engineering (3150711)

1. What needs to be done?

2. When will it be done?
3. Who will do it?
Tracking Project Schedules:

 Periodic project status meetings with each team member reporting progress and
problems
 Evaluation of results of all work product reviews
 Comparing actual milestone completion dates to scheduled dates
 Comparing actual project task start-dates to scheduled start-dates
 Informal meeting with practitioners to have them asses subjectively progress to
date and future problems
 Use earned value analysis to assess progress quantitatively

3.5 Risk analysis and Management:

Project Risk Analysis and Management is a process which enables the analysis and
management of the risks associated with a project. Properly undertaken it will increase the
likelihood of successful completion of a project to cost, time and performance objectives.

Project risk analysis and management can be used on all projects, whatever the
industry or environment, and whatever the timescale or budget.

In this guide, the term ‘PRAM’ encompasses processes, techniques and methods that
enables the analysis and management of the risks associated with a project.

Risk Analysis is a process that helps you identify and manage potential problems that
could undermine key business initiatives or projects.
To carry out a Risk Analysis, you must first identify the possible threats that you face,
and then estimate the likelihood that these threats will materialize.

Risk Analysis can be complex, as you'll need to draw on detailed information such as
project plans, financial data, security protocols, marketing forecasts, and other relevant
information. However, it's an essential planning tool, and one that could save time,
money, and reputations.

When to Use Risk Analysis:

Risk analysis is useful in many situations:
 When you're planning projects, to help you anticipate and neutralize possible
problems.
 When you're deciding whether or not to move forward with a project.
 When you're improving safety and managing potential risks in the workplace.
 When you're preparing for events such as equipment or technology failure, theft,
staff sickness, or natural disasters.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 35
 Software Engineering (3150711)

 When you're planning for changes in your environment, such as new competitors
coming into the market, or changes to government policy.

Following are the categories of the risk:

1. Project risk: If the project risk is real then it is probable that the project schedule
will slip and the cost of the project will increase.
It identifies the potential schedule, resource, stakeholders and the requirements
problems and their impact on a software project.
2. Technical risk: If the technical risk is real then the implementation becomes
impossible.
It identifies potential design, interface, verification and maintenance of the problem.
3. Business risk: If the business risk is real then it harms the project or product.

Managers can plan their strategy based on four steps of risk management which
prevails in an organization.

1. Risk Identification:
 Risk identification is a process for identifying and recording potential
project risks that can affect the project delivery.
 Documenting the risks: Identified risks should be documented in a risk register
and a risk breakdown structure, along with their causes and consequences.
 Product-specific risks - the project plan and software statement of scope are
examined to identify any special characteristics of the product that may threaten
the project plan.
 Generic risks - are potential threats to every software product (product size,
business impact, customer characteristics, process definition, development
environment, technology to be built, staff size and experience)

2. Risk Projection:
 Risk projection, also called risk estimation, attempts to rate each risk in two
ways—the likelihood or probability that the risk is real and the consequences of
the problems associated with the risk, should it occur.
 The project planner, along with other managers and technical staff, perform
four risk projection activities:
1) Establish a scale that reflects the perceived likelihood of a risk.
2) Estimate the impact of the risk on the project and the product.
3) Note the overall accuracy of the risk projection so that there will be no
misunderstandings.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 36
 Software Engineering (3150711)

3. Risk Refinement:
 Also called Risk assessment
 Refines the risk table in reviewing the risk impact based on the following three
factors.
a. Nature: Likely problems if risk occurs
b. Scope: Just how serious is it?
c. Timing: When and how long
 Process of restating the risks as a set of more detailed risks that will be easier to
mitigate, monitor, and manage.
 CTC (condition-transition-consequence) format may be a good representation
for the detailed risks (e.g. given that <condition> then there is a concern that
(possibly) <consequence>).

4. Risk Mitigation:
 Risk mitigation planning is the process of developing options and actions to
enhance opportunities and reduce threats to project objectives.
 Risk mitigation implementation is the process of executing risk
mitigation actions.
 Risk mitigation is one element of risk management, and its implementation will
differ by organization.
 Although the principle of risk mitigation is to prepare a business for all
potential risks, a proper risk mitigation plan will weigh the impact of each risk
and prioritize planning around that impact.
 Risk mitigation focuses on the inevitability of some disasters and is used for
those situations where a threat cannot be avoided entirely.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 37
 Software Engineering (3150711)

Unit: 4
Requirement Analysis and Specification
4.1 Understanding the Requirement:
The process to gather the software requirements from client, analyze and document
them is known as requirement engineering Requirements analysis, also
called requirements engineering, is the process of determining user expectations for
a new or modified product.

These features, called requirements, must be quantifiable, relevant and detailed.

In software engineering, such requirements are often called functional specifications.

The goal of requirement engineering is to develop and maintain sophisticated and

descriptive SRS (System Requirements Specification) document.

This is the process of discovering, analyzing, defining, and documenting the

requirements that are related to a specific business objective.

And it's the process by which you clearly and precisely define the scope of the project,
so that you can assess the timescales and resources needed to complete it.A focused and
detailed business requirements analysis can help you avoid problems like these.

This is the process of discovering, analyzing, defining, and documenting the

requirements that are related to a specific business objective.

And it's the process by which you clearly and precisely define the scope of the project,
so that you can assess the timescales and resources needed to complete it.

Software requirements can be broadly classified into two groups:

 Functional or problem domain requirements

 Non-functional or solution domain requirements

In a problem domain, the focus is on the functional or business requirements.

It is recommended that you create a domain model of your functional requirements

before you start thinking of the solution domain.

In a solution domain, we focus on how to deliver the solution for functional or business
requirements.

Some of the important non-functional requirements of an application are:

Quality attributes such as security, high availability, scalability, performance, and

reliability.
 Message format, transport, and protocol
 Data format and transformation

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 38
 Software Engineering (3150711)

 User interface
 Integration
 Runtime infrastructure
 Networking and communication
 Constraints such as the use of specific RDBMS System, protocols, and standards

4.2 Requirement Modeling:

Requirements modeling in software engineering identifies the requirements that a
software application or system must meet in order to solve the business problem.

Requirements are divided into functional (what the system will have to do) and non-
functional (constraints within which the system will have to perform).

Requirements modeling in software engineering are essentially the planning stage of a

software application or system. Generally the process will begin when a business or an
entity, for example an educational institution, approaches a software development team
to create an application or system from scratch or update an existing one.

Requirements modeling comprise several stages or 'patterns': scenario-based

modeling, data modeling, flow-oriented modeling, class-based modeling and behavioral
modeling.
Each of these stages/patterns examines the same problem from a different perspective.
The appropriate approach to take will depend on the type of system and the
organizational standards, in some cases they are domain specific modeling languages
which are used.

A functional requirement specifies something that the application or system should

do.

Often this is defined as a behavior of the system that takes input and provides output.
For example, a traveler fills out a form in an airline's mobile application with his/her
name and passport details (input), submits the form, and the application generates a
boarding pass with the traveler's details (output).

Non-functional requirements, sometimes also called quality requirements, describe

how the system should be, as opposed to what it should do.

Non-functional requirements of a system include performance (e.g. response time),

maintainability, and scalability, among many others.

Following are the requirement modeling strategies:

1. Flow Oriented Modeling
2. Class-based Modeling

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 39
 Software Engineering (3150711)

1. Flow Oriented Modeling:

It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

i. Data flow model

 It is a graphical technique. It is used to represent information flow.

 The data objects are flowing within the software and transformed by
processing the elements. The data objects are represented by labeled arrows.
 Transformation is represented by circles called as bubbles.
 DFD shown in a hierarchical fashion. The DFD is split into different levels. It
also called as 'context level diagram'.

ii. Control flow model :

 Large class applications require a control flow modeling.

 The application creates control information instated of reports or displays.
 The applications process the information in specified time.
 An event is implemented as a Boolean value.
For example, the Boolean values are true or false, on or off, 1 or 0.

iii. Control Specification:

 A short term for control specification is CSPEC.

 It represents the behavior of the system.
 The state diagram in CSPEC is a sequential specification of the behavior.
 The state diagram includes states, transitions, events and activities.
 State diagram shows the transition from one state to another state if a
particular event has occurred.

iv. Process Specification

 A short term for process specification is PSPEC.

 The process specification is used to describe all flow model processes.
 The content of process specification consists text, Program Design
Language(PDL) of the process algorithm, mathematical equations, tables or
UML activity diagram.

2. Class based Modeling:

Class based modeling represents the object. The system manipulates the operations.
The elements of the class based model consist of classes and object, attributes,
operations, class – responsibility - collaborator (CRS) models.
Classes:
Classes are determined using underlining each noun or noun clause and enter it into
the simple table.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 40
 Software Engineering (3150711)

Classes are found in following forms:

External entities: The system, people or the device generates the information that
is used by the computer based system.
Things: The reports, displays, letter, signal are the part of the information domain
or the problem.
Occurrences or events: A property transfer or the completion of series or robot
movements occurs in the context of the system operation.
Roles: The people like manager, engineer, salesperson are interacting with the
system.
Organizational units: The division, group, team are suitable for an application.
Places: The manufacturing floor or loading from the context of the problem and the
overall function of the system.
Structures: The sensors, computers are defined a class of objects or related classes
of objects.
Attributes:
Attributes are the set of data objects that are defining a complete class within the
context of the problem.
For example, 'employee' is a class and it consists of name, Id, department,
designation and salary of the employee are the attribute.

4.3 Requirement Specification (SRS):

The requirements are specified in specific format known as SRS. A software
requirements specification (SRS) is a document that captures complete description
about how the system is expected to perform.

The SRS is a specification for a specific software product, program, or set of applications
that perform particular functions in a specific environment. It serves several goals
depending on who is writing it. First, the SRS could be written by the client of a system.
Second, the SRS could be written by a developer of the system.

The software requirement specification is an official document. It shows the detail

about the performance of expected system.

SRS indicates to a developer and a customer what is implemented in the software. SRS
is useful if the software system is developed by the outside contractor. SRS must include
an interface, functional capabilities, quality, reliability, privacy etc.

Software requirements specification establishes the basis for an agreement between

customers and contractors or suppliers on how the software product should function.

This is achieved through detailed and continuous communications with the project
team and customer throughout the software development process.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 41
 Software Engineering (3150711)

Why SRS?
In order to fully understand one’s project, it is very important that they come up with a
SRS listing out their requirements, how are they going to meet it and how will they
complete the project.

It helps the team to save upon their time as they are able to comprehend how are going
to go about the project. Doing this also enables the team to find out about the
limitations and risks early on.

The specific goals of the SRS are:

 Facilitating reviews.
 Describing the scope of work.
 Providing a reference to software designers (i.e. navigation aids, document
structure).
 Providing a framework for testing primary and secondary use cases.
 Including features to customer requirements.
 Providing a platform for ongoing refinement (via incomplete specs or questions).

Figure: Basic specification of SRS

Qualities of SRS:

1) Correct 2) Unambiguous 3) Complete 4) Consistent

5) Modifiable 6) Verifiable 7) Traceable, and
8) Ranked for importance and/or stability

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 42
 Software Engineering (3150711)

Characteristics of SRS:
 The SRS should be complete and consistence.
 The modification like logical and hierarchical must be allowed in SRS.
 The requirement should be easy to implement.
 Each requirement should be uniquely identified.
 The statement in SRS must be unambiguous means it should have only one
meaning.
 The entire requirement must be valid for the specified project.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 43
 Software Engineering (3150711)

4.4 Requirement Analysis and Requirement Elicitation:

Requirement Elicitation and Analysis is the process of interacting with customers
and end-users to find out about the domain requirements, what services the system
should provide, and the other constrains.

Analyst, requirement analysis is the most important part of any Job. It will help you
determining the actual needs of stakeholders.

At the same time, enable you to communicate with the stakeholders in a language they
understand (like charts, models, flow-charts,) instead of complex text.

Here are the main activities involve in requirement analysis:

 Identify customer's needs.
 Evaluate system for feasibility.
 Perform economic and technical analysis.
 Allocate functions to system elements.
 Establish schedule and constraints.
 Create system definitions.

Requirements analysis is critical to the success or failure of a systems or software

project. The requirements should be documented, actionable, measurable, testable,
traceable, related to identified business needs or opportunities, and defined to a level of
detail sufficient for system design.

Figure: Requirement Analysis and Requirement Elicitation

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 44
 Software Engineering (3150711)

Requirement elicitation is the practice of collecting the requirements of a system

from users, customers and other stakeholders. This practice is also sometimes referred
to as "Requirement Gathering".

Requirements elicitation is a part of the requirements engineering process, usually

followed by analysis and specification of the requirements.

Requirements elicitation practices include interviews, questionnaires, user observation,

workshops, brainstorming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered

through an elicitation process.

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really
need.

There are a number of requirements elicitation methods.

1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
1. Interviews:

Objective of conducting an interview is to understand the customer’s expectations from

the software. It is impossible to interview every stakeholder hence representatives
from groups are selected based on their expertise and credibility.
Interviews maybe be open ended or structured.
1. In open ended interviews there is no pre-set agenda. Context free questions may
be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.

2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally a document is prepared which consists of the list of requirements and their
priority if possible.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 45
 Software Engineering (3150711)

3. Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system

Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the inputs
from the meeting.
4. Quality Function Deployment:

In this technique customer satisfaction is of prime concern, hence it emphasizes on the

requirements which are valuable to the customer.

3 types of requirements are identified –

 Normal requirements – In this the objective and goals of the proposed software
are discussed with the customer. Example – normal requirements for a result
management system may be entry of marks, calculation of results etc
 Expected requirements – These requirements are so obvious that the customer
need not explicitly state them. Example – protection from unauthorised access.
 Exciting requirements – It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. Example – when an
unauthorized access is detected, it should backup and shutdown all processes.

The major steps involved in this procedure are –

1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorised as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off

5. Use Case Approach:

This technique combines text and pictures to provide a better understanding of the
requirements. The use cases describe the ‘what’, of a system and not ‘how’. Hence they
only give a functional view of the system.
The components of the use case deign includes three major things – Actor, Use cases,
use case diagram.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 46
 Software Engineering (3150711)

1. Actor – It is the external agent that lies outside the system but interacts with it
in some way. An actor maybe a person, machine etc. It is represented as a stick
figure. Actors can be primary actors or secondary actors.
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.
2. Use cases – They describe the sequence of interactions between actors and the
system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
3. Use case diagram – A use case diiagram graphically represents what happens
when an actor interacts with a system. It captures the functional aspect of the
system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.

4.5 Requirement Engineering:

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process.

Requirement engineering provides the appropriate mechanism to understand what the

customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable
solution, specifying the solution clearly, validating the specifications and managing the
requirements as they are transformed into a working system.

Thus, requirement engineering is the disciplined application of proven principles,

methods, tools, and notation to describe a proposed system's intended behavior and its
associated constraints.
The process to gather the software requirements from client, analyze and document
them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process:
It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

1. Feasibility study:
 When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.
 Referencing to this information, the analysts does a detailed study about
whether the desired system and its functionality are feasible to develop.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 47
 Software Engineering (3150711)

 This feasibility study is focused towards goal of the organization.

 This study analyzes whether the software product can be practically
materialized in terms of implementation, contribution of project to organization,
cost constraints and as per values and objectives of the organization.

2. Requirement Gathering:
 If the feasibility report is positive towards undertaking the project, next phase
starts with gathering requirements from the user.
 Analysts and engineers communicate with the client and end-users to know
their ideas on what the software should provide and which features they want
the software to include.

3. Software Requirement Specification :

 SRS is a document created by system analyst after the requirements are
collected from various stakeholders.
 SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing,
Security, Quality, Limitations etc.

4. Software Requirement Validation:

 After requirement specifications are developed, the requirements mentioned in
this document are validated.
 User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly.
 This results in huge increase in cost if not nipped in the bud.
 Requirements can be checked against following conditions -
 If they can be practically implemented
 If they are valid and as per functionality and domain of software
 If there are any ambiguities (complex)
 If they are complete
 If they can be demonstrated

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 48
 Software Engineering (3150711)

Unit: 5
Software Design
5.1 Design Concepts and Design Principle:
Software design is a phase in software engineering, in which a blueprint is developed to
serve as a base for constructing the software system. IEEE defines software design as
'both a process of defining, the architecture, components, interfaces, and other
characteristics of a system or component and the result of that process.'
In the design phase, many critical and strategic decisions are made to achieve the
desired functionality and quality of the system. These decisions are taken into account
to successfully develop the software and carry out its maintenance in a way that the
quality of the end product is improved.
The core design concepts in software engineering should be followed to create a
successful program or application. This lesson will go through those main design
concepts and explain how each one plays a role in software development.

In the field of software development, there are many stages of planning and analysis
before the project is finalized and development can formally begin. Design always
comes before development and functional design makes coding and maintenance very
simple.
The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has
evolved. They are as follows:

1. Abstraction - Abstraction is the process or result of generalization by reducing

the information content of a concept or an observable phenomenon, typically in
order to retain only information which is relevant for a particular purpose. It is
an act of Representing essential features without including the background
details or explanations.
2. Refinement - It is the process of elaboration. A hierarchy is developed by
decomposing a macroscopic statement of function in a step-wise fashion until
programming language statements are reached. In each step, one or several
instructions of a given program are decomposed into more detailed instructions.
Abstraction and Refinement are complementary concepts.
3. Modularity - Software architecture is divided into components called modules.
4. Software Architecture - It refers to the overall structure of the software and the
ways in which that structure provides conceptual integrity for a system. Good
software architecture will yield a good return on investment with respect to the
desired outcome of the project, e.g. in terms of performance, quality, schedule
and cost.
5. Control Hierarchy - A program structure that represents the organization of a
program component and implies a hierarchy of control.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 49
 Software Engineering (3150711)

6. Structural Partitioning - The program structure can be divided into both

horizontally and vertically. Horizontal partitions define separate branches of
modular hierarchy for each major program function. Vertical partitioning
suggests that control and work should be distributed top down in the program
structure.
7. Data Structure - It is a representation of the logical relationship among
individual elements of data.
8. Software Procedure - It focuses on the processing of each module individually.
9. Information Hiding - Modules should be specified and designed so that
information contained within a module is inaccessible to other modules that
have no need for such information.
Design Principles:
Developing design is a cumbersome process as most expansive errors are often introduced
in this phase. Moreover, if these errors get unnoticed till later phases, it becomes more
difficult to correct them. Therefore, a number of principles are followed while designing the
software.
 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” between the software and
the problem as it exists in the real world.
 The design should be structured to accommodate change.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize conceptual (semantic) errors.

5.2 Architectural Design:

The software needs the architectural design to represents the design of software.

IEEE defines architectural design as “the process of defining a collection of hardware

and software components and their interfaces to establish the framework for the
development of a computer system.”

The software that is built for computer-based systems can exhibit one of these many
architectural styles.

Requirements of the software should be transformed into an architecture that describes

the software's top-level structure and identifies its components.

An architectural design performs the following functions.

1. It defines an abstraction level at which the designers can specify the functional and
performance behavior of the system.
2. It acts as a guideline for enhancing the system (when ever required) by describing
those features of the system that can be modified easily without affecting the system
integrity.
3. It evaluates all top-level designs.
4. It develops and documents top-level design for the external and internal interfaces.
5. It develops preliminary versions of user documentation.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 50
 Software Engineering (3150711)

6. It defines and documents preliminary test requirements and the schedule for
software integration.
7. Information regarding the application domain for the software to be developed.
8. Using data-flow diagrams.
9. Availability of architectural patterns and architectural styles.

Architectural design is of crucial importance in software engineering during which the

essential requirements like reliability, cost, and performance are dealt with.

 This task is represents as the software engineering paradigm is shifting from

monolithic, stand-alone, built-from-scratch systems to componentized, evolvable,
standards-based, and product line-oriented systems.
 Also, a key challenge for designers is to know precisely how to proceed from
requirements to architectural design.
 To avoid these problems, designers adopt strategies such as reusability,
componentization, platform-based, standards-based, and so on.
 Though the architectural design is the responsibility of developers, some other
people like user representatives, systems engineers, hardware engineers, and
operations personnel are also involved.
 All these stakeholders must also be consulted while reviewing the architectural
design in order to minimize the risks and errors.

Architectural design can be represented using the following models.

1. Structural model: Illustrates architecture as an ordered collection of program
components.
2. Dynamic model: Specifies the behavioral aspect of the software architecture and
indicates how the structure or system configuration changes as the function changes
due to change in the external environment.
3. Process model: Focuses on the design of the business or technical process, which
must be implemented in the system.
4. Functional model: Represents the functional hierarchy of a system.
5. Framework model: Attempts to identify repeatable architectural design patterns
encountered in similar types of application. This leads to an increase in the level of
abstraction.

5.3 Component level Design:

Component-level design occurs at the stage in software engineering following the
architectural design of the software. It translates that design into a more
detailed design before the actual coding of the software begins. A component is the
basic building block of the software.

The objective of this design is to transform the design model into functional software.
To achieve this objective, the component-level design represents -the internal data
structures and processing details of all the software components (defined during
architectural design) at an abstraction level, closer to the actual code. In addition, it
specifies an interface that may be used to access the functionality of all the software
components.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 51
 Software Engineering (3150711)

The component-level design can be represented by using different approaches. One

approach is to use a programming language while other is to use some intermediate
design notation such as graphical (DFD, flowchart, or structure chart), tabular
(decision table), or text-based (program design language) whichever is easier to be
translated into source code.
The component-level design provides a way to determine whether the defined
algorithms, data structures, and interfaces will work properly. This level of design
defines the interface, algorithms, data structures and communication methods of
each component.
Note that a component (also known as module) can be defined as a modular building
block for the software. However, the meaning of component differs according to how
software engineers use it.

Simply put, a component, sometimes also called a module, is basic building block for
the software application or system being designed.

A more technical description of a component is that it is a replaceable and reusable set

of functions which is part of a system and incorporates implementation and exposes a
set of interfaces.

5.4Function Oriented Design:

A functional approach to design is therefore most likely to be successful when the
amount of system state information is minimized and information sharing is explicit.

Systems whose responses depend on a single stimulus or input and which are not
affected by input histories are naturally functionally-oriented.

In function-oriented design, the system is comprised of many smaller sub-systems

known as functions. These functions are capable of performing significant task in the
system. The system is considered as top view of all functions.
 Function oriented design inherits some properties of structured design where
divide and conquer methodology is used.
 This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their
operation.
 These functional modules can share information among themselves by means of
information passing and using information available globally.
 Another characteristic of functions is that when a program calls a function, the
function changes the state of the program, which sometimes is not acceptable by
other modules.
 Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 52
 Software Engineering (3150711)

Design Process:
 The whole system is seen as how data flows in the system by means of data flow
diagram.
 DFD depicts how changes data and state of entire system functions.
 The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.
 Each function is then described at large.

5.5 Object Oriented Design:

Object-oriented design (OOD) is the process of using an object-oriented
methodology to design a computing system or application. This technique enables
the implementation of a software solution based on the concepts of objects.

The OOD process takes the conceptual systems model, use cases, system relational
model, user interface (UI) and other analysis data as input from the OOA phase.

This is used in OOD to identify, define and design systems classes and objects, as
well as their relationship, interface and implementation.

Object oriented design works around the entities and their characteristics instead of
functions involved in the software system. This design strategies focuses on entities
and its characteristics. The whole concept of software solution revolves around the
engaged entities.

Let us see the important concepts of Object Oriented Design:

1. Objects - All entities involved in the solution design are known as objects.

 For example, person, banks, company and customers are treated as objects.
Every entity has some attributes associated to it and has some methods to
perform on the attributes.

2. Classes - A class is a generalized description of an object. An object is an instance of a

class.

 Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
 In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.

3. Encapsulation - In OOD, the attributes (data variables) and methods (operation on

the data) are bundled together is called encapsulation.

 Encapsulation not only bundles important information of an object together, but

also restricts access of the data and methods from the outside world. This is
called information hiding.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 53
 Software Engineering (3150711)

4. Inheritance -”Inheritance is the process through which one Object can access or
acquire property or data of another object of another class.”

 Hierarchical classification
 Parent-Child relationship between classes
 Concept of Re-usability
 We can say, existing class may have original features and new class can have
combined features of both classes.

5. Polymorphism - It’s another concept of Reusability.

 Polymorphism means to take more than one form with different characteristics.
 The operation to perform task may exhibit different behaviors in different
instances, depends on type of data.
 This is called polymorphism, which allows a single interface performing tasks for
different types.

Design Process:
Software design process can be perceived as series of well-defined steps. Though it
varies according to design approach (object oriented), yet It may have the following
steps involved:
 A solution design is created from requirement or system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.

5.6 User Interface Design:

User interface is the front-end application view to which user interacts in order to use
the software. User interface (UI) design is the process of making interfaces in software
or computerized devices with a focus on looks or style.
Designers aim to create designs users will find easy to use and pleasurable.
UI design typically refers to graphical user interfaces but also includes others, such as
voice-controlled ones.
This could be the control buttons of a radio, or the visual layout of a webpage.
User interface designs must not only be attractive to potential users, but must also be
functional and created with users in mind.
The software becomes more popular if its user interface is:
 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interface screens

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 54
 Software Engineering (3150711)

There are two types of User Interface:

1. Command Line Interface :
 CLI has been a great tool of interaction with computers until the video display
monitors came into existence.
 CLI is first choice of many technical users and programmers.
 CLI provides a command prompt, the place where the user types the command
and feeds to the system.
 A text-based command line interface can have the following elements:
 Command Prompt - It is text-based notified that is mostly shows the context in
which the user is working.
 It is generated by the software system.

ii) Cursor - It is a small horizontal line or a vertical bar of the height of line, to
represent position of character while typing.
 It moves as the user writes or deletes something.

iii) Command - A command is an executable instruction.

 It may have one or more parameters.
 Output on command execution is shown inline on the screen.
 When output is produced, command prompt is displayed on the next line.
2. Graphical User Interface:
 Graphical User Interface provides the user graphical means to interact with the
system.
 GUI can be combination of both hardware and software. Using GUI, user
interprets the software.
 Typically, GUI is more resource consuming than that of CLI.
 With advancing technology, the programmers and designers create complex GUI
designs that work with more efficiency, accuracy and speed.
 GUI Elements :
 GUI provides a set of components to interact with software or hardware.

Figure: Elements of GUI

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 55
 Software Engineering (3150711)

 Every graphical component provides a way to work with the system. A GUI
system has following elements such as:
 Window - An area where contents of application are displayed. Contents in a
window can be displayed in the form of icons or lists, if the window
represents file structure.
 Tabs - If an application allows executing multiple instances of itself, they
appear on the screen as separate windows. Tabbed Document
Interface has come up to open multiple documents in the same window.
 Menu - Menu is an array of standard commands, grouped together and
placed at a visible place (usually top) inside the application window. The
menu can be programmed to appear or hide on mouse clicks.
 Icon - An icon is small picture representing an associated application. When
these icons are clicked or double clicked, the application window is opened.
Icon displays application and programs installed on a system in the form of
small pictures.
 Cursor - Interacting devices such as mouse, touch pad, digital pen are
represented in GUI as cursors. On screen cursor follows the instructions from
hardware in almost real-time. Cursors are also named pointers in GUI
systems. They are used to select menus, windows and other application
features.

There are difference characteristics of good user interface:

1) Clarity 2) Familiarity 3)Responsiveness
4) Efficiency 5) Consistency

Benefits of Good Interface Design:

 Higher revenue
 Increase user efficiency and satisfaction
 Reduced development costs
 Reduced support costs

5.7 Web Application Design:

Web application design is an important stage when building a web application. It
focuses on the look and feel of the web application.

The design stage encompasses several different aspects, including user interface design
(UI), usability (UX), content production, and graphic design. Within this post, we
focused mainly on UI and UX design.

Web Applications are web sites combined with server side programming which provide
functionalities such as interacting with users, connecting to back-end databases, and
generating results to browsers.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 56
 Software Engineering (3150711)

Examples of Web Applications are Online Banking, Social Networking, Online

Reservations, eCommerce / Shopping Cart Applications, Interactive Games, Online
Training, Blogs, Online Forums, Content Management Systems, etc.

For every interface design, either for traditional software or for WebApp, should have
the usability characteristics like response time; help facilities, error handling, menu and
command labeling, application accessibility, etc.

When should we emphasize Web App design?

 When content and function are complex.
 When the size of the Web App encompasses hundreds of content objects,
functions, and analysis classes.
 When the success of the Web App will have a direct impact on the success of the
business.

Web App Design Principles:

 Anticipation: A WebApp should be designed so that it anticipates the user’s
next move.
 Communication let the user know the status of any activity initiated by him
through some text message or through some image.
 Consistency must be maintained through the WebApp. For example navigation
controls, icons or menus must be consistent. With respect to its color, shape
throughout the design.
 Efficiency: The design of the interface must optimize the end user’s work
efficiency.
 Flexibility is the integral part of the interface design. The user may explore the
application in some random fashion.
 Readability: Information presented should be readable to all the users.
 Learnability: The application must be designed to minimize learning time.
 Main the work integrity through the system.
 Latency reduction should minimize the waiting time for user and use that
waiting for some internal operation to complete.

Some of the basic goals of Web Application Design :

1) Consistency 2) Identity 3) Robustness
4) Navigability 5) Visual appeal 6) Compatibility

 Security
Reduce external attacks
Exclude unauthorized access
Ensure the privacy of users/customers
 Availability
The measure of the percentage of time that a WebApp is available for use

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 57
 Software Engineering (3150711)

 Scalability
Can the WebApp and the systems with which it is interfaced handle
significant variation in user or transaction volume.

Quality Dimensions for End-Users:

 Time
 Structural
 Content
 Accuracy and Consistency
 Response Time and Latency
 Performance

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 58
 Software Engineering (3150711)

Unit: 6
Software Coding & Testing
6.1 Coding standard and coding guidelines:
Coding Standard:
A coding standard gives a uniform appearance to the codes written by different
engineers. It improves readability, and maintainability of the code and it reduces
complexity also. It helps in code reuse and helps to detect error easily.

The main goal of coding phase is to transform the design produced after requirements
are collected and analyzed, into code by using some languages.

Good software development organizations want their programmers to maintain to

some well-defined and standard style of coding called coding standards. They usually
make their own coding standards and guidelines depending on what suits their
organization best and based on the types of software they develop.

It is very important for the programmers to maintain the coding standards otherwise
the code will be rejected during code review.
Purpose of Having Coding Standards:
 A coding standard gives a uniform appearance to the codes written by different
engineers.
 It improves readability, and maintainability of the code and it reduces complexity
also.
 It helps in code reuse and helps to detect error easily.
 It promotes sound programming practices and increases efficiency of the
programmers.

Coding Guidelines:

Following are some coding guidelines generally followed by most of the software
organizations:
 Use simple coding styles that can be easily understood by other programmers.
 Avoid using complex conventions.
 Do not use identifiers for different purposes.
 The codes should be well documented.
 The functions and procedures should be short, it should not be too lengthy.
 Avoid using Go to statements.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 59
 Software Engineering (3150711)

6.2 Code Review:

Code Review is the act of consciously and systematically convening with one's fellow
programmers to check each other's code for mistakes, and has been repeatedly shown
to accelerate and streamline the process of software development like few other
practices can.

In the coding phase, the design documents are translated into codes. Each software
organizations have their own standards and formatting style for writing codes. All the
software developers strictly follow the standard organizations of uniform code pattern.

Code review is necessary after completion of each of the modules of a software under
construction. In this phase, as many errors are possible are uncovered and resolved.
The code review is very economical, since errors are detected and corrected early in the
development stages.
Code review consists of following three activities:
1. Testing
2. Debugging, and
3. Correcting the errors
Following are some of review techniques generally used:
 Code walkthrough is used to detect algorithmic and logical errors.
 Code inspection is used to detect common programming errors.
 Clean room testing.

1. Code Walkthrough:
 A walkthrough is a term describing the review process at an abstract level.
 It is an informal code analysis technique.
 The term is often used in software industry to describe the process of inspecting
algorithms and source code to find out logical error by paths through the
algorithms or code as determined by input conditions.
 Code Walkthrough is a form of peer review in which a programmer leads the
review process and the other team members ask questions and spot possible
errors against development standards and other issues.
 Before the walkthrough meeting, the preparation by reviewers and then a
review report with a list of findings.

2. Code Inspection:
 Code Inspection is the most formal type of review, which is a kind of avoid the
defect multiplication at a later stage.
 The main purpose of code inspection is to find defects and it can also spot any
process improvement if any.
 Once the code is written for a module; it is first verified before it is used by other.
 Inspection was started for detecting faults in code, and was later applied for
design, requirement etc.
 Preparation before the meeting is essential, which includes reading of any
source documents to ensure consistency.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 60
 Software Engineering (3150711)

 The inspection process is the most formal type of review based on rules and
checklists and makes use of entry and exit criteria.
 After the meeting, a formal follow-up process is used to ensure that corrective
action is completed in a timely manner.

3. Cleanroom Testing:
 The strategy and tactics of classroom testing are basically different from
traditional testing strategies and tactics.
 Traditional methods generate a set of test cases to find the design and coding
errors.
 The primary goal of clean room testing is to validate software requirements by
showing the statistical samples of use-cases that have been executed
successfully.

6.3 Software Documentation:

Software documentation is written material, images, or video instructions that come
with computer software. As a rule, software documentation explains how to use a
program or a service.

However, there may be different types of software documentation, depending on the

audience it is created for. Here are some examples of the software documentation
types:

 Requirements documentation - Typically created in the beginning of a

software development project. Has the goal to clearly and precisely specify the
expectations in regards to the software being created. May include functional
requirements, limitations, hardware or software requirements, compatibility
requirements, and so on.
 Architecture documentation - Defines the high-level architecture of the
software system being created. May describe the main components of the
system, their roles and functions, as well as the data and control flow among
those components.
 Technical documentation - Documentation of the software code, algorithms,
APIs. Written for the technical audience like software developers.
 End user documentation - Refer to User Guide.

As a rule, there’s a special team in a company occupied with technical writing - the
documentation team. Although, workflows can differ. In some companies, support, dev
or QA can do documentation authoring.

The technical documentation is important and it is easily accessible. It is well organized.

Also it is specific, details and an accurate. Software engineer develops a software
configuration i.e., programs, data and documents. All these attributes are amenable to
testing.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 61
 Software Engineering (3150711)

Verification evaluates all the documentation, planning, coding, requirements and

specifications. The complete test plan for integration testing is documented in a test
specification. The performance requirements must be attained and documentation
must be correct.

The documentation section describes each of the work produced as part of the software
process. These include:
Project documents (e.g., project plan)
Models (e.g., ER diagrams, class diagrams)
Technical documents (e.g., specifications, test plans)
User documents (e.g., help files)

Documentation testing is conducted in following two phases:

1. Review and inspection
2. Actual test of application is accordance with documentation.

Following are the list of questions that must be answered while conducting
documentation testing:
Are all modes of use are described accurately?
Is description of the sequence of each interaction accurate?
Are all the terminologies, menu descriptions and system responses are in
advance with the actual program?
Is the table of contents and index accurate and complete?
Are hyperlinks correct and accurate?
Is design navigation is appropriate?
All these questionnaires must be checked and answered by the independent third party.

6.4 Testing Strategies:

Software Testing is a process of evaluating the functionality of a software application to
find any software bugs. It checks whether the developed software met the specified
requirements and identifies any defect in the software in order to produce a quality
product.

Testing is an important activity in software development process. Before the start of the
development, testing is planned and is conducted very systematically.

In order to implement the testing, there are various testing strategies defined in the
software engineering literature. All these strategies provided a testing template to the
developers.

Following are the characteristic that process the testing templates:

 The developer should conduct the successful technical reviews to perform

the testing successful.
 Testing starts with the component level and work from outside toward the
integration of the whole computer based system.
 Different testing techniques are suitable at different point in time.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 62
 Software Engineering (3150711)

 Testing is organized by the developer of the software and by an independent

test group.
 Debugging and testing are different activities, then also the debugging should
be accommodated in any strategy of testing.
 Testing focuses on finding errors whereas debugging starts after a bug has
been identified in the software.

1. Unit testing:
It focuses each of the components individually and ensures that it should work
properly as per requirements.
2. Integration testing :
An integration testing focuses on the construction and design of the software. The
test cases also focus on inputs and outputs during integration.
3. Validation testing :
Check all the requirements like functional, behavioral and performance
requirement are validate against the construction software.
4. System testing:
System testing confirms all system elements and performance are tested entirely.

Sr. No. Verification Validation

1. Verification is the process to find The validation process is checked whether
whether the software meets the the software meets requirements and
specified requirements for particular expectation of the customer.
phase.
2. It estimates an intermediate product. It estimates the final product.

3. The objectives of verification are to The objectives of the validation are to check
check whether software is whether the specifications are correct and
constructed according to satisfy the business need.
requirement and design specification.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 63
 Software Engineering (3150711)

4. It describes whether the outputs are It explains whether they are accepted by
as per the inputs or not. the user or not.
5. Verification is done before the It is done after the verification.
validation.
6. Plans, requirement, specification, Actual product or software is tested under
code are evaluated during the validation.
verifications.

6.5 Testing Techniques:

Testing is a process of executing a program with the aim of finding error. To make our
software perform well it should be error free. If testing is done successfully it will
remove all the errors from the software.

Principles of Testing:-

(i) All the test should meet the customer requirements.

(ii) To make our software testing should be performed by third party.
(iii) Exhaustive testing is not possible. As we need the optimal amount of testing
based on the risk assessment of the application.
(iv) All the test to be conducted should be planned before implementing it.
(v) Start testing with small parts and extend it to large parts.

Once the software is developed it should be tested in a proper manner before the
system is delivered to the user. For this, two techniques that provide systematic
guidance for designing tests are used.

These techniques are discussed here.

 Once the internal working of software is known, tests are performed to ensure
that all internal operations of the software are performed according to
specifications.
 This is referred to as white box testing.
 Once the specified function for which the software has been designed is known,
tests are performed to ensure that each function is working properly.
 This is referred to as black box testing.

1. White Box Testing:

 White box testing (also called structural testing or glass box testing) is
performed to test the program internal structure.
 The goal of White Box testing is to verify all the decision branches, loops,
statements in the code.
 To perform white box testing, the tester should have a thorough knowledge
of the program internals along with the purpose of developing the software.
 During this testing, the entire software implementation is also included with
the specification.
 This helps in detecting errors even with unclear or incomplete software
specification.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 64
 Software Engineering (3150711)

Figure: White box testing

The goal of white box testing is to ensure that the test cases (developed by software
testers by using white box testing) exercise each path through a program.

The test cases also ensure the following.

1. All independent paths within the program have been exercised at least once.
2. All internal data structures have been exercised.
3. All loops (simple loops and nested loops) have been executed at and within
their specified boundaries.
4. All segments present between the controls structures (like 'switch' statement)
have been executed at least once.
5. Each branch (like 'case' statement) has been exercised at least once.
6. All the logical conditions as well as their combinations have been executed at
least once for both true and false paths.

White box testing involves the testing of the software code for the following:
 Internal security process
 Broken or poorly structured paths in the coding processes
 The flow of specific inputs through the code
 Expected output
 The functionality of conditional loops
 Testing of each statement, object, and function on an individual basis

2. Black Box Testing:

 Black box (or functional) testing checks the functional requirements and
examines the input and output data of these requirements.
 When black box testing is performed, only the sets of 'legal' input and
corresponding outputs should be known to the tester and not the internal
logic of the program to produce that output.
 Hence to determine the functionality, the outputs produced for the given sets
of input are observed.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 65
 Software Engineering (3150711)

Figure: Black box Testing

This method is named so because the software program, in the eyes of the tester, is
like a black box; inside which one cannot see.
This method attempts to find errors in the following categories:
 Incorrect or missing functions
 Interface errors
 Errors in data structures or external database access
 Behavior or performance errors

The black box testing is used to find the errors listed below.
1. Interface errors such as functions, which are unable to send or receive data
to/from software.
2. Incorrect functions that lead to undesired output when executed.
3. Missing functions and erroneous data structures.
4. Erroneous databases, which lead to incorrect outputs when the software uses
the data present in these databases for processing.
5. Incorrect conditions due to which the functions produce incorrect outputs
when they are executed.
6. Termination errors such as certain conditions due to which a function enters
a loop that forces it to execute indefinitely.

Here are the generic steps followed to carry out any type of Black Box Testing.
 Initially, the requirements and specifications of the system are examined.
 Tester chooses valid inputs (positive test scenario) to check whether SUT
(System Under Test) processes them correctly. Also some invalid inputs
(negative test scenario) are chosen to verify that the SUT is able to detect them.
 Tester determines expected outputs for all those inputs.
 Software tester constructs test cases with the selected inputs.
 Software tester compares the actual outputs with the expected outputs.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 66
 Software Engineering (3150711)

6.6 Test suites Design:

Test suite is a container that has a set of tests which helps testers in executing and
reporting the test execution status. It can take any of the three states namely Active, In
progress and completed.
A Test case can be added to multiple test suites and test plans. After creating a test
plan, test suites are created which in turn can have any number of tests.
The test suite is created to describe following parameters:
 What is to be tested?
 Define the preconditions.
 Define the post conditions.
 Assign various test steps that are to be followed.
 Also record the result of ongoing test case.

A test suite is a set of machines that is usually considered as a platform to test the
web apps. These machines are designed in such a way that they behave like a client-
side environment for testing the Web Apps.

On the other hand the labs are specially equipped and designed for usability testing.
The test labs allow the monitoring of various users testing the applications.

Following are some goals that of designing a test suite:

Always provide a very clear environment for testing.
For enhancing the productivity, provide rapid test and review prototypes.
For testing the connectivity and network performance, provide proper
environment over the production servers.
Also provide clean environment for usability testing.

A well designed test suite should address the following points:

 Provide compatibility with the browsers that are commonly used by the
majority of the users.
 The platform used must be compatible for the sites used by the majority of the
users.
 Consider the budget parameters while designing the test suite.

6.7 Testing Conventional Applications:

For the conventional software, there are various test strategies available for use.In
first one, the team waits for a product development to be completed and then start
conducting tests.

In another approach, the developer conducts the test on a daily basis as the
development proceeds and one part of the program is completed. These strategies
are chosen by the development team based on the product and convenience of the
team.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 67
 Software Engineering (3150711)

The team starts with an incremental view of testing and test individual program
units. Then moving ahead with integration of the units, and finalizing the tests of
overall system.

Different types of tests are mentioned below:

1. Unit Testing
2. Integration Testing
3. Regression Testing
4. Smoke Testing

1. Unit Testing is a level of software testing where individual units/ components of

a software are tested.

 A unit is the smallest testable part of any software. It usually has one or a few
inputs and usually a single output.
 In procedural programming, a unit may be an individual program, function,
procedure, etc.

2.Integration Testing also known as integration and testing (I&T), is a software

development process which program units are combined and tested as groups in
multiple ways.
 In this context, a unit is defined as the smallest testable part of an application.

3.Regression Testing is defined as a type of software testing to confirm that a

recent program or code change has not adversely affected existing features.
 Regression Testing is nothing but a full or partial selection of already
executed test cases which are re-executed to ensure existing functionalities work
fine.
4. Smoke Testing Smoke testing is defined as a type of software testing that
determines whether the deployed build is stable or not.
 Smoke testing is a process where the software build is deployed to QA
environment and is verified to ensure the stability of the application.
 It is also called as "Build verification Testing" or “Confidence Testing.”

6.8 Testing Object Oriented Applications:

In object-oriented (OO) paradigm, software engineers identify and specify the objects
and services provided by each object. In addition, interaction of any two objects and
constraints on each identified object are also determined. The main advantages of OO
paradigm include increased reusability, reliability, interoperability, and extendibility.

With the adoption of OO paradigm, almost all the phases of software development have
changed in their approach, environments, and tools.

Though OO paradigm helps make the designing and development of software easier, it
may pose new kind of problems. Thus, testing of software developed using OO
paradigm has to deal with the new problems also.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 68
 Software Engineering (3150711)

OO program should be tested at different levels to uncover all the errors. At the
algorithmic level, each module (or method) of every class in the program should be
tested in isolation.

Developing Test Cases in Object-oriented Testing

The methods used to design test cases in OO testing are based on the conventional
methods. However, these test cases should encompass special features so that they can
be used in the object-oriented environment.
The points that should be noted while developing test cases in an object-oriented
environment are listed below.
1. It should be explicitly specified with each test case which class it should test.
2. Purpose of each test case should be mentioned.
3. External conditions that should exist while conducting a test should be clearly stated
with each test case.
4. All the states of object that is to be tested should be specified.
5. Instructions to understand and conduct the test cases should be provided with each
test case.
As many organizations are currently using or targeting to switch to the OO paradigm,
the importance of OO software testing is increasing.
The methods used for performing object-oriented testing are discussed in this section.

1. State-based Testing
 State-based testing is used to verify whether the methods (a procedure that is
executed by an object) of a class are interacting properly with each other.
 This testing seeks to exercise the transitions among the states of objects based
upon the identified inputs.
2. Fault-based Testing
 Fault-based testing is used to determine or uncover a set of possible faults.
 In other words, the focus of tester in this testing is to detect the presence of
possible faults.
 Fault-based testing starts by examining the analysis and design models of OO
software as these models may provide an idea of problems in the
implementation of software.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 69
 Software Engineering (3150711)

3. Scenario-based Testing
 Scenario-based testing is used to detect errors that are caused due to incorrect
specifications and improper interactions among various segments of the
software.
 The use of scenarios in testing is a common way of describing how a user might
accomplish a task or achieve a goal within a specific context or environment.
 Note that these scenarios are more context- and user specific instead of being
product-specific.
 The testing strategy for web and mobile applications use the basic principles for
all software testing and also applies the strategies and tactics of object-oriented
testing.

6.9 Testing Web and Mobile Applications:

Whether it comes to testing web or mobile applications, the aim is to ensure that an app
is user-friendly and functions properly under different circumstances, even if it’s
already in production.

The testing strategy for web and mobile applications use the basic principles for all
software testing and also applies the strategies and tactics of object-oriented testing.

Following steps summarizes the approach:

 The content model for Web and Mobile Applications are reviewed to uncover
errors.
 The interface model is reviewed to ensure that all use cases can be accommodated.
 The design model for web and Mobile Applications are reviewed to uncover
navigation errors.

 The user interface is tested to uncover errors in presentation or navigation

mechanics.
 Each functional component is unit tested.
 Navigation throughout the architecture is tested.
 The Web and Mobile Applications are implemented in a variety of different
environment of configurations.
 Security testes are conducted.
 Performance tests are conducted.
 The Web and Mobile Applications are tested by a controlled and monitored
population of end users.

6.10 Testing Tools (Win runner, Load runner):

Software Testing tools are the tools which are used for the testing of software.
Software testing tools are often used to assure firmness, thoroughness and
performance in testing software products.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 70
 Software Engineering (3150711)

Unit testing and subsequent integration testing can be performed by software testing
tools. These tools are used to fulfill all the requirements of planned testing activities.
These tools also work as commercial software testing tools. The quality of the software
is evaluated by software testers with the help of various testing tools.

The Test Manager is an automated software testing tool is used in day to days testing
activities. Such Test Management tools are used to facilitate regular Software
Development activities, automate & mange the testing activities.

We know that testing a software application is how tedious and painful. It consumes
lot of time and man hours. Eventually heavy investment is required. Also there are
possibilities of mistakes using manual testing.

Sometimes it is quite impossible to test all feature of software thoroughly before the
final delivery of the product to the client. In order to control testing in a proper way,
some automated tools are used to uncover the errors and correct then accordingly.
The examples of these automated tools are as follows:
1. WinRunner
2. LoadRunner
Win Runner is the most used Automated Software Testing Tool.
Main Features of Win Runner are :
 Developed by Mercury Interactive
 Functionality testing tool
 Supports C/s and web technologies such as (VB, VC++, Java, HTML, Power Builder, Cibell
(ERP))
 To Support .net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can use QTP
(Quick Test Professional).
 Winrunner run on Windows only.
 Xrunner run only UNIX and linux.
 Tool developed in C on VC++ environment.
 To automate our manual test win runner used TSL (Test Script language like c)

 Load Runner is a software testing tool from Micro Focus.

 It is used to test applications, measuring system behavior and performance under
load.
 Load Runner can simulate thousands of users concurrently using application
software, recording and later analyzing the performance of key components of
the application.
 Load Runner simulates user activity by generating messages between
application components or by simulating interactions with the user interface
such as key presses or mouse movements.

The messages and interactions to be generated are stored in scripts. Load Runner can
generate the scripts by recording them, such as logging HTTP requests between a client
web browser and an application's web server.

Load testing is to test that if the application works fine with the loads that result from
large number of simultaneous users, transactions and to determine weather it can
handle peak usage periods.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 71
 Software Engineering (3150711)

Unit: 7
Quality Assurance and Management
7.1 Quality Concepts and Software Quality Assurance:
Software quality is an abstract concept. “In the context of software
engineering, software quality measures how well software is designed (quality of
design), and how well the software conforms to that design (quality of conformance). It
is often described as the 'fitness for purpose' of a piece of software.”

The most software developers will agree that high-quality software is an important
goal.

In the most general sense, software quality is conformance to explicitly stated,

functional and performance requirements, explicitly documented development
standards, and implicit characteristics that are expected of all professionally developed
software.

The definitions emphasizes three important points:

1. Software requirements are the basis for software quality measurement. It

requirements are not satisfied then obviously it will yield low quality software.

2. For the development processes, some standards specified that define the
development criteria. These development criteria will guide software engineering
process. If the criteria are not followed properly then the quality of the product
will be quite low.

3. These are two types of requirements:

 Implicit requirements and
 Explicit requirements

Even if the explicit requirements are considered, the quality may be degraded if it fails
to meet implicit requirements.

Software quality is an complex mix of factors that will vary across different
applications and the customers who request them.

The factors that affect software quality can be categorized in two broad groups:
Factors that can be directly measured (e.g., defects uncovered during testing), and
Factors that can be measured only indirectly (e.g., usability or maintainability)

Software Quality Assurance:

SQA (Software Quality Assurance) is a planned and systematic method for evaluation of
the quality of software product, standards, processes, and procedures.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 72
 Software Engineering (3150711)

Quality Assurance is popularly known as QA Testing, is defined as an activity to ensure

that an organization is providing the best possible product or service to customers. QA
focuses on improving the processes to deliver Quality Products to the customer.

An organization has to ensure, that processes are efficient and effective as per the
quality standards defined for software products.

It assures that the standards and procedures once established are followed throughout
the software development life cycle.
Quality assurance has a defined cycle called PDCA cycle or Deming cycle. The
phases of this cycle are:

1. Plan -------- 2.Do -------- 3.Check ---------4.Act

Figure: PDCA Cycle

These above steps are repeated to ensure that processes followed in the organization
are evaluated and improved on a periodic basis.

Let's look into the above steps in detail -

1. Plan - Organization should plan and establish the process related objectives and
determine the processes that are required to deliver a high-Quality end
product.
2. Do - Development and testing of Processes and also "do" changes in the processes
3. Check - Monitoring of processes, modify the processes, and check whether it meets
the predetermined objectives
4. Act - Implement actions that are necessary to achieve improvements in the
processes

SQA insures that there are clear and achievable standards these can evaluate the
compliance of the software application product with established standards.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 73
 Software Engineering (3150711)

The process monitoring activity in an SQA ensures that the appropriate steps are
carried out during the development process. The SQA standards monitor all the
processes by comparing the actual steps carried out during the development process.

The SQA also ensures that the Management Plan specifies that methods that should be
used by the monitoring activity of SQA process.

Difference between Quality Control and Quality Assurance:

Sr. Quality Control Quality Assurance

No.
1. QC is a process which deliberates on It is a process which deliberates on
fulfilling the quality request. providing assurance that quality request
will be achieved.
2. A QC aim is to identify and improve the A QA aim is to prevent the defect.
defects.
3. QC is a method to verify quality. QA is the technique of managing quality
4. QC always involves executing the QA does not involve executing the
program. program.
5. Testing team is responsible for QC. All team members are responsible for QA.
6. QC Example: Validation. QA Example: Verification
7. QC Means Action for executing the QA means Planning for doing a process.
planned process.

7.2 Software Reviews (Formal Technical Reviews):

The FTR (Formal Technical Review) is a software quality assurance activity with the
objectives to uncover errors in function, logic or implementation for any representation
of the software; to verify that the software under review meets its requirements; to
ensure that the software has been represented according to predefined standards; to
achieve software that is developed in a uniform manner and to make projects more
manageable.

FTR (Formal Technical Review) is also a learning ground for junior developers to know
more about different approaches to software analysis, design and implementation. It
also serves as a backup and continuity for the people who are not exposed to the
software development so far.

FTR (Formal Technical Review) activities include walkthroughs, inspection and round
robin reviews and other technical assessments. The above-mentioned methods are
different FTR (Formal Technical Review) formats

The software reviews can be considered as the filter in the software process. The
software reviews are applied throughout the development process at different point of
time. The main purpose of software reviews is to purify all these activities.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 74
 Software Engineering (3150711)

The main motive behind the software reviews is to uncover the errors that can be
corrected later on. The technical reviews are having their own significant since the
developers can find errors of others but it is very difficult to find their own errors.

 A formal technical review (FTR) is a software quality assurance activity

performed by software engineers.
 FTR (Formal Technical Review) is also a learning ground for junior developers
to know more about different approaches to software analysis, design and
implementation.
 Reviews that include walkthroughs, inspection reviews and other small group
technical assessment of software.
 It also serves as a backup and continuity for the people who are not exposed to
the software development so far.

The objectives of the FTR are:-

1) To uncover errors in function, logic, or implementation for any representation
of the software.
2) To verify that the software under review meets its requirements.
3) To ensure that the software has been represented according to predefined
standards.
4) To achieve software that is developed in a uniform manner.
5) To make projects more manageable.

7.3 Software Reliability:

Software reliability is defined as: – The probability of failure-free software operation
for a specified period of time in a specified environment.
Reliability is the probability of failure-free operation of a system over a specified time
within a specified environment for a specified purpose.
An Informal definition: Reliability is a measure of how closely a system matches its
stated specification.
Another Informal Definition: Reliability is a measure of how well the users perceive a
system provides the required services.
 It is difficult to define the term objectively.
 Difficult to measure user expectations,
 Difficult to measure environmental factors.
 It’s not enough to consider simple failure rate:
Not all failures are created equal; some have much more serious
consequences.
Might be able to recover from some failures reasonably.
A failure corresponds to unexpected runtime behavior observed by a user of the
software.
A fault is a static software characteristic which causes a failure to occur.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 75
 Software Engineering (3150711)

Improving Reliability:
1. Primary objective: Remove faults with the most serious consequences.
2. Secondary objective: Remove faults that are encountered most often by users.
 Fixing N% of the faults does not, in general, lead to an N% reliability
improvement.
 90-10 Rule: 90% of the time you are executing 10% of the code.
 One study showed that removing 60% of software “defects” led to a 3%
reliability improvement.

The Cost of Reliability:

In general, reliable systems take the slow, steady route:
 Trusted implementation techniques
 Few uses of short-cuts, tricks
 Use of redundancy, run-time checks, type-safe pointers
Users value reliability highly.
Cost of software failure often far outstrips the cost of the original system:
 Data loss
 Down-time
 Cost to fix

7.4 The Quality Standards:

1. ISO 9000:
ISO 9000 is defined as a set of international standards on quality management
and quality assurance developed to help companies effectively document
the quality system elements needed to maintain an efficient quality system. They are
not specific to any one industry and can be applied to organizations of any size.

ISO 9000 can help a company satisfy its customers, meet regulatory requirements,
and achieve continual improvement. It should be considered to be a first step or the
base level of a quality system.

The ISO is an organization established to formulate standarardization. In this

consortium there are 63 countries. ISO (International Standards Organization)
published its 9000 series for formulation of standards back in 1987.

Actually ISO certification works as references to compare various software vendors to

check the quality. If a vendor does good in its development then can be awarded ISO
9000 certification.

The ISO 9000 certification is provided if and only if the ISO 9000 series standards are
followed.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 76
 Software Engineering (3150711)

All these standards are designed to improve the quality of the product.
Following are various of ISO 9000 series:
 ISO 9001
 ISO 9002
 ISO 9003
In the following section, we will focus on some of the limitations of ISO 9000
certification:
 ISO 9000 does not guarantee 100% for setting up an high quality system.
 It does not provide any guidelines for defining the process.
 There is no continuous process improvement.

2. CMM (Capability Maturity Model):

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
analyse 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.

Figure: CMM Level model

In CMMI models with a staged representation, there are five maturity levels designated
by the numbers 1 through 5.
1.Initial 2.Managed 3. Defined 4.Quantitatively Managed and, 5. Optimizing

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 77
 Software Engineering (3150711)

Level-1: Initial –
 No KPA’s defined.
 Processes followed are adhoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.

Level-2: Managed–
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar natured
projects.

Level-3: Defined –
 At this level, documentation of the standard guidelines and procedures takes
place.
 It is a well defined integrated set of project specific software engineering and
management processes.

Level-4: Quantitatively Managed –

 At this stage, quantitative quality goals are set for the organization for software
products as well as software processes.
 The measurements made help the organization to predict the product and process
quality within some limits defined quantitatively.

Level-5: Optimizing –
 This is the highest level of process maturity in CMM and focuses on continuous
process improvement in the organization using quantitative feedback.
 Use of new tools, techniques and evaluation of software processes is done to
prevent recurrence of known defects.

3. Six sigma for SE:

Six sigma is a disciplined approach towards process improvement. It was first used by
General Eclectic (GE) Corporation back in 1995. Many companies across the globe now
are using Six Sigma standards and finding it useful.

Six Sigma is the process of producing high and improved quality output. This can be
done in two phases – identification and elimination. Six Sigma is a quality management
methodology used to help businesses improve current processes, products or services
by discovering and eliminating defects.

The goal is to streamline quality control in manufacturing or business processes so

there is little to no variance throughout.

The main purpose behind using Six Sigma is to improve the process for the
development of the products faster and reasonable cost. The six sigma approach

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 78
 Software Engineering (3150711)

uncovers many errors and corrects it. Thus we can say that six sigma is a systematic
approach to achieve perfection.

Basically the Six Sigma is an approach that is based on measurement strategy and
obviously focuses on process improvement.

The six sigma has following two sub methodologies:

1. The Six Sigma DMAIC process and
2. The Six Sigma DMADV process

 The DMAIC stands for define, measure, analyze, improve, control.

 The DMADV stands for define, measure, analyze, design, verify.

7.5 SQA Plan:

The SQA plan is a document that specifies the process to be followed in each step of the
software development and the procedures to be followed in each activity of such a
process.

The purpose of this Software Quality Assurance Plan (SQAP) is to define the
techniques, procedures, and methodologies that will be used at the Center for Space
Research (CSR) to assure timely delivery of the software that meets specified
requirements within project resources.

SQA is the mainly responsible for leading the Quality Initiative in the CMMI
organization.
 SQA is responsible for conducting many associated process improvement
activities in the organization.
 SQA is involved with these CMMI Process Improvement activities: Process
Improvement Planning

SQA Benefits:
SQA has a host of benefits. It ensures that software built as per SQA procedures are of
specified quality. SQA helps to:

1. Eliminate errors when they are still inexpensive to correct

2. Improves the quality of the software
3. Improving the process of creating software
4. Create a mature software process

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 79
 Software Engineering (3150711)

Unit: 8
Software Maintenance and Configuration Management

8.1 Types of Software Maintenance:

Software Maintenance is the process of modifying a software product after it has been
delivered to the customer. The main purpose of software maintenance is to modify and
update software application after delivery to correct faults and to improve
performance.
Need for Maintenance –
Software Maintenance must be performed in order to:
 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features,
and telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.

Figure: Software Maintenance Process

Categories of Software Maintenance –

Maintenance can be divided into the following:
1. Corrective maintenance:
Corrective maintenance of a software product may be essential either to rectify
some bugs observed while the system is in use, or to enhance the performance of
the system.
2. Adaptive maintenance:
This includes modifications and updating when the customers need the product to
run on new platforms, on new operating systems, or when they need the product
to interface with new hardware and software.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 80
 Software Engineering (3150711)

3. Perfective maintenance:
A software product needs maintenance to support the new features that the users
want or to change different types of functionalities of the system according to the
customer demands.
4. Preventive maintenance:
This type of maintenance includes modifications and updating to prevent future
problems of the software. It goals to attend problems, which are not significant at
this moment but may cause serious issues in future.
There are number of reasons, why modifications are required, some of them are
briefly mentioned below:
1. 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.
2. Client Requirements - Over the time, customer may ask for new features or
functions in the software.
3. 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.
4. Organization Changes - If there is any business level change at client end, such as
reduction of organization strength, acquiring another company, organization into
new business, need to modify in the original software may arise.

8.2 Re-Engineering:
Software Re-engineering is a process of software development which is done to
improve the maintainability of a software system. Re-engineering is the examination
and alteration of a system to reconstitute it in a new form. This process encompasses a
combination of sub-processes like reverse engineering, forward engineering,
reconstructing etc.
Re-engineering is the reorganizing and modifying existing software systems to make them
more maintainable.
Objectives of Re-engineering:
 To describe a cost-effective option for system evolution.
 To describe the activities involved in the software maintenance process.
 To distinguish between software and data re-engineering and to explain the
problems of data re-engineering.

Reengineering is the term used for a radical change processes in the organization.
Reorganising and modifying existing software systems to make them more
maintainable.
Sometimes the concept of Business Process Reengineering is used. A variety of
reengineering work products (e.g., analysis model, design model, test procedures) are
product.
The final output is the reengineered business process and/or the engineered software
that supports it.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 81
 Software Engineering (3150711)

Re-engineering Cost Factors:

 The quality of the software to be re-engineered
 The tool support available for re-engineering
 The extent of the required data conversion
 The availability of expert staff for re-engineering

Advantages of Re-engineering:
 Reduced Risk: As the software already exists, the risk is less as compared to new
software development. Development problems, staffing problems and
specification problems are the lots of problems which may arise in new software
development.
 Reduced Cost: The cost of re-engineering is less than the costs of developing new
software.

System Re-Engineering: Re-structuring or re-writing part or all of a

legacy system without changing its functionality.
Applicable where some but not all sub-systems of a larger system require frequent
maintenance. Re-engineering involves adding effort to make them easier to maintain.
The system may be re-structured and re-documented.
FTR assess the analysis and design models, specialized reviews consider business
applicability and compatibility, testing is applied to uncover errors in content,
functionality, and interoperability.

8.3 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 is the process of design recovery. In reverse engineering the data,
architectural and procedural information is extracted from a source code.
Reverse engineering is the process of discovering the technological principles of a
human made device, object or system through analysis of its structure, function and
operation. Reverse engineering is taking apart an object to see how it works in order to
duplicate or enhance the object.
Reverse Engineering Goals:
 Cope with Complexity.
 Recover lost information.
 Detect side effects.
 Synthesize higher abstraction.
 Facilitate Reuse.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 82
 Software Engineering (3150711)

Why is software reverse engineering needed?

 Reverse engineering skills are also used to detect and neutralize viruses and
malware, and to protect intellectual property.
 Computer programmers proficient in SRE will
be needed should software components like these need to be maintained,
enhanced, or reused.

Following are some important purpose of Reverse Engineering:

 Security auditing
 Enabling additional features
 Used as learning tools
 Developing compatible products cheaper than that are currently available in the
market.

Following are three important parameters to be considered for a reverse

engineering process:
1. Abstraction Level
2. Completeness
3. Directionality

1. Abstraction Level:
 In this level, the design information is extracted from the source code.
 It is the highest level in the reverse engineering process.
 It is always expected that the abstraction level for any reverse engineering
process must be high.
 When the level of abstraction is high, then it becomes easy for the software
developer to understand the program.
2. Completeness:
 The completeness is nothing but the details available through the abstraction
level of reverse engineering process.
 For example from the given source code it is very easy to develop the complete
procedural design.
3. Directionality:
 The directionality of a reverse engineering process is a method of extracting
information from the source code and making it available to the software
developers.
 The software developers can use this information during the maintenance
activity.

Reverse Engineering Activities:

 Understanding Process
 Understanding Data
 Understanding User Interfaces

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 83
 Software Engineering (3150711)

8.4 Forward Engineering:

Forward engineering is the process of building from a high-level model or concept to
build in complexities and lower-level details. This type of engineering has different
principles in various software and database processes.
Generally, forward engineering is important in IT because it represents the 'normal’
development process. For example,building from a model into an implementation
language. This will often result in loss of semantics, if models are more semantically
detailed, or levels of abstraction.
Forward engineering is thus related to the term 'reverse engineering,’ where there is an
effort to build backward, from a coded set to a model, or to unravel the process of how
something was put together.
Forward Engineering applies of all the software engineering process which includes
SDLC to recreate an existing application. It is about to fulfill new requirements of the
users into reengineering.
In most of the cases, forward engineering is not the method to just create a new version
of an older program but the new users and new technologies. New requirements are
also integrated into the reengineering process.
Let no other documentation must be modified for any requirement changes.
In this situation, we have the following options available with us:
We can be lost with too many modifications and necessary design changes.
We can understand the working of modules and functions to make the
modifications easy.
We can redesign the part of software that suffered with requirement modifications
and recode them accordingly.
Or finally we can redesign from start and code again from beginning itself.

Figure: Forward Engineering Vs Reverse Engineering

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 84
 Software Engineering (3150711)

Difference between Forward Engineering and Reverse Engineering:

Sr. Forward Engineering Reverse Engineering

No.
1. In forward engineering, the In reverse engineering or backward
application are developed with the engineering, the information is collected from
given requirements. the given application.
2. Forward Engineering is high Reverse Engineering or backward engineering
proficiency skill. is low proficiency skill.
3. Forward Engineering takes more time While Reverse Engineering or backward
to develop an application. engineering takes less time to develop an
application.
4. The nature of forward engineering is The nature of reverse engineering or
Prescriptive. backward engineering is Adaptive.
5. In forward engineering, production is In reverse engineering, production is started
started with given requirements. by taking existing product.
6. The example of forward engineering The example of backward engineering are
are construction of electronic kit, research on Instruments etc.
construction of DC MOTOR etc.

8.5 The SCM Process:

System Configuration Management (SCM) is an arrangement of exercises which
controls change by recognizing the items for change, setting up connections between
those things, making/characterizing instruments for overseeing diverse variants,
controlling the changes being executed in the current framework, inspecting and
revealing/reporting on the changes made.

It is essential to control the changes in light of the fact that if the changes are not
checked legitimately then they may wind up undermining a well-run programming.

It aims to control cost and work effort involved in making changes to the software
system. The primary goal is to increase productivity with minimal mistakes.

Configuration Management helps organizations to systematically manage, organize, and

control the changes in the documents, codes, and other entities during the Software
Development Life Cycle.

The primary reasons for Implementing Software Configuration Management

System are:
 There are multiple people working on software which is continually updating.
 It may be a case where multiple version, branches, authors are involved in a
software project, and the team is geographically distributed and works
concurrently.
 Changes in user requirement, policy, budget, schedule need to be
accommodated.
 Software should able to run on various machines and Operating Systems.
 Helps to develop coordination among stakeholders.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 85
 Software Engineering (3150711)

 SCM process is also beneficial to control the costs involved in making changes to
a system.

SCM defines a mechanism to deal with different technical difficulties of a project plan. In
a software organization, effective implementation of software configuration
management can improve productivity by increased coordination among the
programmers in a team.

SCM helps to eliminate the confusion often caused by miscommunication among team
members. The SCM system controls the basic components such as software objects,
program code, test data, test output, design documents, and user manuals.

The SCM system has the following advantages:

 Reduced redundant work.

 Effective management of simultaneous updates.
 Avoids configuration-related problems.
 Facilitates team coordination.
 Helps in building management; managing tools used in builds.
 Defect tracking: It ensures that every defect has traceability back to its source.

8.6 Identification of Object in the Software Configuration:

To control and manage software configuration items, each must be separately named
and then organized using an object-oriented approach. Two types of objects can be
identified: basic objects and aggregate objects.

A basic object is a "unit of text" that has been created by a software engineer during
analysis, design, code, or test.

For example, a basic object might be a section of a requirements specification, a source

listing for a component, or a suite of test cases that are used to exercise the code. An
aggregate object is a collection of basic objects and other aggregate objects. Design
Specification is an aggregate object. Conceptually, it can be viewed as a named
(identified) list of pointers that specify basic objects such as data
model and component N.

The object name is a character string that identifies the object unambiguously.
The object description is a list of data items that identify the SCI type (e.g., model
element, program, data) represented by the object, a project identifier, and change
and/or version information.

Resources are “entities that are provided, processed, referenced or otherwise required
by the object”.

 To control and manage software configuration items, each should be separately

named and then organized using an object oriented approach.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 86
 Software Engineering (3150711)

 Two types of objects can be identified : Basic objects and aggregate objects
 A basic object is a unit of information that has been created by a software
engineer during analysis, design, code or test. For example, a basic object might
be a section of requirements specification, part of design model or a source code
of component.
 An aggregate object is a collection of basic objects. Each object has a set of
distinct features that identify it uniquely: a name, a description, a list of
resources.
 Configuration object identification can also consider the relationships that exist
between named objects. For example, using the simple notation :
o Class diagram <part-of> analysis model;
o Analysis model <part-of> requirements specification;

8.7 Version Control and Change Control:

Version control: Version control combines procedures and tools to manage different
versions of configuration objects that are created during the software process.

A version control system implements or is directly integrated with four major

capabilities:

1. A project database (repository) that stores all relevant configuration objects

2. A version management capability that stores all versions of configuration object.
3. A make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software.

 In addition, version control and change control systems often implement an

issue tracking (also called as bug tracking) capability that enables the team to
record and track the status of all outstanding issues associated with each
configuration object.
 A number of version control systems establish a change set - a collection of all
changes (to some baseline configuration) that are required to create a specific
version of the software.
 A change set captures all changes to all files in the configuration along with the
reason for the changes and details of who made the changes and when.
 A number of named change sets can be identified for an application or system. A
number of different automated approaches to version control have been
proposed over the last two decades.

Change Control: In a change control process, a change request is submitted and

evaluated to assess technical merit, potential side effects, overall impact on other
configuration objects and system functions and the projected cost of change.

 The results of evaluation are presented as a change report, which is used by a

change control authority (CCA) – a person or a group who makes the final
decision on the status and priority of the change.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 87
 Software Engineering (3150711)

 An Engineering Change Order (ECO) is generated for each approved change. The
ECO describes the change to be made, the constraints that must be respected and
the criteria for review and audit.
 A version control system updates the original file once the change has been
made. As an alternative, the objects can be checked out of the project database,
the change is made and appropriate SQA activities are applied. The object is then
checked into the database and appropriate version control mechanisms are used
to create the next version of the software.
 These version control mechanisms, integrated within the change control
process, implement two important elements of change management – access
control and synchronization.
 Access control governs which software engineers have authority to access and
modify a particular configuration object.
 Synchronization control helps to ensure that parallel changes, performed by two
different people do not overwrite one another.

For such projects, change control combines human procedures and automated tools to
provide a mechanism for the control of change.

A change request is submitted and evaluated to assess technical merit, potential side
effects, overall impact on other configuration objects and system functions, and the
projected cost of the change.

The results of the evaluation are presented as a change report, which is used by a
change control authority. (CCA)—a person or group that makes a final decision on the
status and priority of the change.

An engineering change order (ECO) is generated for each approved change. The ECO
describes the change to be made, the constraints that must be respected, and the
criteria for review and audit.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 88
 Software Engineering (3150711)

Unit: 9
DevOps
9.1 Overview:
DevOps is the combination of cultural philosophies, practices, and tools that increases
an organization’s ability to deliver applications and services at high velocity: evolving
and improving products at a faster pace than organizations using traditional software
development and infrastructure management processes.

This speed enables organizations to better serve their customers and compete more
effectively in the market.

Under a DevOps model, development and operations teams are no longer “siloed.”
Sometimes, these two teams are merged into a single team where the engineers work
across the entire application lifecycle, from development and test to deployment to
operations, and develop a range of skills not limited to a single function.
In some DevOps models, quality assurance and security teams may also become more
tightly integrated with development and operations and throughout the application
lifecycle. When security is the focus of everyone on a DevOps team, this is sometimes
referred to as DevSecOps.
These teams use practices to automate processes that historically have been manual
and slow. They use a technology stack and tooling which help them operate and evolve
applications quickly and reliably.
These tools also help engineers independently accomplish tasks (for example,
deploying code or provisioning infrastructure) that normally would have required help
from other teams, and this further increases a team’s velocity.
In simple words, DevOps can be defined as an alignment of development and IT
operations with better communication and collaboration.

Figure: DevOps Concept

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 89
 Software Engineering (3150711)

Benefits of DevOps:
 Speed
 Rapid Delivery
 Reliability
 Scale
 Improved Collaboration
 Security

9.2 Problem Case Definition:

Most people in the IT industry have heard of DevOps, yet many are confused on what it
really means. We will discuss why DevOps is necessary to improve your IT
department and your business.

Why DevOps?
You might have heard the following statements about DevOps:
 DevOps is a close collaboration between Development team and Operations.
 DevOps is using Automation.
 DevOps is treating your infrastructure as code.
 DevOps is frequent and smaller deployments to production.
 DevOps is using Agile Methodologies.
“DevOps” upon the world, there is no denying that DevOps has evolved into a global
movement.
Of course, DevOps has its detractors. Negative opinions range from the misguided
(“DevOps is a new name for a Sys Admin”) to the dismissive (“DevOps is just some crazy
Devs trying to get rid of Ops” or “DevOps is just crazy some Ops trying to act like Devs
so they will be better liked”) to the outright offended (whose arguments tend to defy
logic).
I’ve spent the past nine months or so overcoming resistance to the DevOps movement
in both public forums and inside client companies. During that time, I’ve begun to notice
a common misconception that I think is fueling much of the negative initial reaction that
some people have to DevOps ideas. I want to take a shot at clearing it up now:

DevOps is not a technology problem.

Technology plays a key part in enabling solutions to DevOps problems. However,

DevOps itself is fundamentally a business problem.

What does the business have to do with DevOps?

The most fundamental business process in any company is getting an idea from
inception to where it is making you money.

Within that business process there are all kinds of activity that needs to happen, some
technology-driven and some human-driven. This is where all of the different functions

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 90
 Software Engineering (3150711)

of IT come into play. Developers, QA, Architecture, Release Engineering, Security,

Operations, etc each do their part to fulfill that process.

But if you take away the context of the business process, what have you got? You’ve got
a bunch of people and groups doing their own thing. You lose any real incentive to fight
inefficiency, duplication of effort, conflicts, and disconnects between those groups. It’s
every person for them, literally.

But you know what else happens if you remove the context of the business process?
Your job eventually goes away. Enabling the business is why we get paychecks and
why we get to spend our time doing what we do. If there is no business to enable or we
don’t do any business enabling, this all just turns into a hobby. And by definition, it’s
pretty difficult to get paid for a hobby.

The whole point of DevOps is to enable your business to react to market forces as
quickly, efficiently, and reliably as possible. Without the business, there is no other
reason for us to be talking about DevOps problems, much less spending any time
solving them.

9.3 DevOps: Benefits of Fixing Application Development Challenges:

DevOps enables developers and operations to work closely as a team throughout all
phases of application development and production support.

As more businesses rush to beat the competition with the help of technology, software
development has become more than just a sound investment. It is a major revenue
channel and the main strategic benefit of a modern business.

That is why it is crucial to ensure the quality, performance, and security of your
product, as well as a fast time to market. For the last decade, businesses and software
development teams around the world have been relying on the agile methodology as a
way to improve team efficiency and adaptability.

However, with the increased focus on the business value of software products,
traditional methods are no longer enough. There is a need for more effective ways to
build and deploy software.
Benefits of fixing application:
1. Reduced chance of product failure.
2. Improved flexibility and support.
3. Faster time to market.
4. Better team efficiency.
5. Clear product vision within the team.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 91
 Software Engineering (3150711)

Challenges of fixing application:

1. Transition challenges (both technical and organizational)
2. Lack of talent
3. Toolset choice

9.4 DevOps Adoption Approach through Assessment:

DevOps is a re-organization practice that focuses on automated environments,
provisioning, and process improvement to reduce cycle time by removing bottlenecks
and also an organizational culture shift that promotes breaking down silos and
minimizing hand-offs.

While this may seem easy on paper, it is not so simple to execute without strong
support from the organization. Here, discuss what it takes to deliver a successful
DevOps project through the different stages of the development lifecycle.

The journey starts with the user (e.g. customer, client, software requirement,
enhancement request, bug fix, line-of-business, features, idea) in mind. User feedback is
an integral part of the process with ongoing development and deployment practices.

DevOps fosters a higher degree of collaboration and ongoing, real-time communication

between traditionally disparate workflows of developers, IT operations, quality
assurance, and infrastructure teams.

Figure: DevOps adoption approach

9.5 DevOps Importance and Benefits:
DevOps—the amalgamation of development (Dev) and operations (Ops) teams—is an
organizational approach that enables faster development of applications and easier
maintenance of existing deployments.

By enabling organizations to create stronger bonds between Dev, Ops and other
stakeholders in the company, DevOps promotes shorter, more controllable iterations
through the adoption of best practices, automation and new tools.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 92
 Software Engineering (3150711)

DevOps is not a technology, but it covers everything from the organisation to culture,
processes and tooling.

Initial steps usually include Continuous integration and continuous delivery (CI/CD),
real-time monitoring, incident response systems and collaboration platforms.

Benefits of DevOps
 Maximizes Efficiency with Automation
 Optimizes the Entire Business
 Improves Speed and Stability of Software Development and Deployment
 Gets You to Focus on What Matters Most: People

9.6 DevOps Principles and Practices:

For a long time, development and operations were isolated modules. Developers wrote
code; the system administrators were responsible for its deployment and integration.
As there was limited communication between these two silos, specialists worked
mostly separately within a project.

That was fine when Waterfall development dominated. But since Agile and continuous
workflow have taken over the world of software development, this model is out of the
game. Short sprints and frequent releases occurring every two weeks or even every day
require a new approach and new team roles.

Today, DevOps is one of the most discussed software development approaches. It is

applied in Facebook, Netflix, Amazon, Etsy, and many other industry-leading
companies. So, if you are considering embracing DevOps for the sake of better
performance, business success, and competitiveness, you take the first step and hire a
DevOps engineer.

But first, let’s look at what DevOps is all about and how it helps improve product
delivery.

Successful, long-lasting movement have a clear manifesto outlining goals and principles.
Many DevOps adopters may not be aware of the DevOps Manifesto nor how successful
DevOps requires keeping a clear focus on principles, practices, and value (instead of
infrastructure tooling).

DevOps Principles
DevOps value is derived in the core principles that started the movement:
 Iterative
 Incremental
 Continuous
 Automated
 Self-service
 Collaborative
 Holistic

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 93
 Software Engineering (3150711)

9.7 7 C’s of DevOps Lifecycle for Business Agility:

As the main focus of DevOps is to serve the customer better and faster, so it is
important that all the stakeholders have better end-to-end visibility of operations,
planning, integration, testing, monitoring, delivery, and feedback.

DevOps currently ranges over the whole association including client benefit,
advertising, item proprietors, program administrators, and distinctive levels of
engineers, discharge or construct groups and framework group.

The fundamental focal point of DevOps is to serve the client better and speedier.
Therefore; it is essential for every partner to have better end-to-end accepting of
activities.

These activities are arranging, mixing, testing, checking, conveyance, and criticism. This
is the 7C approach of DevOps which requires a rich combination of procedures and
devices to robotize the consistent data trade and execution.

Figure: 7 C’s of DevOps Lifecycle

The 7 C’s are as follows:

 Continuous Planning
 Continuous Development
 Continuous Deployment
 Continuous Integration
 Continuous Testing
 Continuous Delivery and Monitoring
 Continuous Feedback

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 94
 Software Engineering (3150711)

9.8 DevOps and Continuous Testing:

Continuous Testing is defined as a software testing type that involves a process of
testing early, testing often, test everywhere, and automate. It is a strategy of evaluating
quality at every step of the Continuous Delivery Process.

The goal of Continuous Testing is test early and tests often. The process involves
stakeholders like Developer, DevOps, QA and Operational system.

Key Points of Continuous Testing

 Continuous Testing’s primary goal is assessing business risk coverage.

 Continuous Testing provides instant insight on whether a release candidate is too
risky to proceed through the delivery pipeline.
 Continuous Testing expects testing to be embedded within the development process,
not tacked on at the end.
 Continuous Testing is seamlessly integrated into the software delivery pipeline and
DevOps toolchain.
 Continuous Testing expects a stable test environment with valid test data to be
available for each and every test run.
 Continuous Testing delivers actionable feedback appropriate for each stage of the
delivery pipeline.

9.9 How to Choose Right DevOps Tool:

The traditional separation between software development teams and information
technology operations teams once caused many problems throughout the production
process.

Then came the idea of DevOps, which has its roots in the Agile methodology and
integrates the two teams to improve collaboration and productivity. There are actually
many different definitions of the term “DevOps,” and the concepts behind it are
multilayered.

But most will agree at least that continuity and automation are big parts of DevOps, and
certain DevOps tools help team members ensure that those two elements will be
implemented as efficiently as possible.

Of course, your organization’s specific needs will determine which tools are best for
you, but here are what many consider to be the top DevOps tools.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 95
 Software Engineering (3150711)

As to the best practices for choosing DevOps tools you can use to approach your
DevOps implementation, these can be boiled down to seven steps.

1.Step 1: Understand the collaboration and shared tools strategy for the Dev, QA, and
infrastructure automation teams.
2.Step 2: Use tools to capture every request.
3.Step 3: Use agile Kanban project management for automation and DevOps requests
that can be dealt with in the tooling.
4.Step 4: Use tools to log metrics on both manual and automated processes.
5.Step 5: Implement test automation and test data provisioning tooling.
6.Step 6: Perform acceptance tests for each deployment tooling.
7.Step 7: Ensure continuous feedback between the teams to spot gaps, issues, and
inefficiencies.

9.10 Challenges with DevOps Implementation:

DevOps as we know it is an amalgamation of Development and Operations. It
emphasizes better collaboration between teams and tighter integration of tools that
ultimately lead to valued process mapping.

Over the years, DevOps has gained global recognition among IT professionals and
experts who have not only given it a thought but have also gone a step ahead to
implement it within their organizations, leaving behind manual interventions and
working towards an automated synced world.

You could easily identify automation as one of the major pillars of this movement.
However, despite its widespread popularity, why does DevOps implementation
continue to remain a challenge for some? Let us look into some of the challenges faced
during implementation.

Speaking in terms of technological goals, even though we are well aware of the fact
that DevOps aims to achieve the ultimate in automation and integration, practical
implementation of it is still a far cry.

Implementing new schools of thought has always been a struggle, even if it is about
replacing older methods with newer ones. Here are some of the challenges that people
often face during DevOps implementation.

Here are some of the challenges that people often face during DevOps
implementation.
 Lack of a Standard Definition for DevOps
 Dearth of Vision
 Shortage of Tool Knowledge
 Choice of Tools
 Lack of Tool Integration
 Cultural Challenges
 Isolated Teams
 Risk Analysis

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 96
 Software Engineering (3150711)

9.11 Must Do Things for DevOps:

DevOps assimilates development and operations teams to improve the collaboration
process. A DevOps Engineer will work with IT developers to facilitate better
coordination among operations, development, and testing functions by automating and
streamlining the integration and deployment processes.

DevOps aims at coupling a tighter alignment between IT operations and

businesses.This new phenomenon is taking over the corporate boardrooms by storm
and bringing in new methodologies and principles to streamline the creation and
deployment of software in the new ‘software is eating the world’ era.

A DevOps Engineer must be able to manage the IT infrastructure as per the supported
software code dedicated in multi-tenant or hybrid cloud environments.

There is a need to have a provision for required resources and for getting the
appropriate deployment model, validating the release and monitoring performance.

9.12 Best Practices for Successful DevOps Implementation:

Implementation of DevOps practices helps an organization deliver faster, better, high-
quality and reliable software relying on the culture of cooperation and collaboration
among all functions of an organization.

It calls for fundamental cultural changes and modification of legacy programming

practices. Here are the core DevOps best practices that help an organization achieve the
goals of effective communication and collaboration, smoother operations and bug-free
code.

DevOps is a clear indication of its ability to help companies grow. When a company
implements DevOps and practices well, then there will be an improvement in its
software products.

Good DevOps implementation helps a company to deliver better, faster, top-quality and
reliable software. This is possible because of the cooperation amongst all the
departments in a company. For this implementation to work well, then there must be
changes and modifications in the programming practices. The following are key
practices that will lead to a successful implementation.

10 Best Practices for Successful DevOps Implementation:

1) Evaluate the need to implement DevOps practice.

2) Break the organizational silos & encourage collaboration.
3) Put Customer / end-user satisfaction at the center.
4) Don’t jump start, instead, start small and then scale up.
5) Automate wherever possible.
6) Select tools that are compatible with each other.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 97
 Software Engineering (3150711)

7) Define performance reviews for team and an individual.

8) Ensure real-time visibility into the project.
9) Integrate and deliver continuously.
10) Achieve better results with monitoring & feedback.

9.13 Mapping My App to DevOps-Measure and Feedback:

Value stream mapping brings the metrics you need to deliver on the promise of DevOps.
And the faster, more frequent, and more continuous feedback you have, the .VSM helps
companies measure the value they are receiving from DevOps tools and practices. ...
SAP S/4HANA app migration: Lessons from the trenches.

DevOps - Measure :

 A better approach identifies intended outcomes and measurable

characteristics for each outcome.

 Let’s consider a common scenario: a team adopts DevOps to increase their

velocity. High velocity is a common trait among DevOps teams, plus it may be
measured, tracked, and used to prioritize decisions.

Accelerate correlates these ideas and technical practices with four metrics:

 Lead Time: The time from code written to entering production.

 Deployment Frequency: How often deploys happen.
 Mean-Time-To-Recover (MTTR): How quickly can teams restore service after
production outages.
 Change Fail Rate: What percentage of deploys result in service impairment or
an outage.

DevOps-Feedback :

 Feedback loops are a key enabler for modern delivery.

 In order to link customers to DevOps, you need to focus on user delivery
needs by amplifying and shortening your feedback loops.
 New position in the delivery process, developers has an enhanced
responsibility to users and depends on user feedback to constantly deliver
value.
 1. Testers: Get involved with actual users
 2. Ops: Take the operations as a service approach
 3. Product owners: Share with the team
 4. Continuous feedback is key

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 98
 Software Engineering (3150711)

Unit: 10
Advanced topics in Software Engineering

10.1 Component Based Software Engineering:

Component Based Software Engineering (CBSE) is a process that focuses on the
design and development of computer-based systems with the use of reusable software
components.

CBSE seems quite similar to conventional or object-oriented software engineering. The

process begins when a software team establishes requirements for the system to be
built using conventional requirements elicitation techniques.

CBSE Framework Activities

Framework activities of Component Based Software Engineering are as follows:-

1. Component Qualification:

This activity ensures that the system architecture define the requirements of the
components for becoming a reusable component. Reusable components are
generally identified through the traits in their interfaces. It means “the services
that are given, and the means by which customers or consumers access these
services ” are defined as a part of the component interface.

2. Component Adaptation:

This activity ensures that the architecture defines the design conditions for all
component and identifying their modes of connection. In some of the cases,
existing reusable components may not be allowed to get used due to the
architecture’s design rules and conditions. These components should adapt and
meet the requirements of the architecture or refused and replaced by other, more
suitable components.

3. Component Composition:

This activity ensures that the Architectural style of the system integrates the
software components and forms a working system. By identifying connection and
coordination mechanisms of the system, the architecture describes the
composition of the end product.

4. Component Update:

This activity ensures the updation of reusable components. Sometimes, updates

are complicated due to inclusion of third party (the organization that developed

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 99
 Software Engineering (3150711)

the reusable component may be outside the immediate control of the software
engineering organization accessing the component currently.).

Various Components :

1.Component—a nontrivial, nearly independent, and replaceable part of a system

that fulfills a clear function in the context of a well-defined architecture.

2.Run-time software Component—a dynamic bindable package of one or more

programs managed as a unit and accessed through documented interfaces that can
be discovered in run time.

3.Software Component—a unit of composition with contractually specified and

explicit context dependencies only.

4.Business Component—the software implementation of an “autonomous”

business concept or business process.

5.Qualified components—assessed by software engineers to ensure that not only

functionality, but performance, reliability, usability, and other quality factors follow
to the requirements of the system or product to be built.

6.Adapted components—adapted to modify (also called mask or wrap) unwanted

or undesirable characteristics.

7.Assembled components—integrated into an architectural style and

interconnected with an appropriate infrastructure that allows the components to be
coordinated and managed effectively.

8.Updated components—replacing existing software as new versions of

components become available.

An individual software component is a software package, a web service, a web

resource, or a module that encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and
functions inside each component are semantically related (just as with the contents of
classes).

Because of this principle, it is often said that components are modular and cohesive.
However, when a component needs to use another component in order to function, it
adopts a used interface that specifies the services that it needs.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 100
 Software Engineering (3150711)

10.2 Client/Server Software Engineering:

Client/server software engineering blends conventional principles, concepts, and
methods discussed earlier in the text with elements of object-oriented and component-
based software engineering.

C/S architectures dominate the landscape of computer-based systems. In C/S

architectures, software residing on one computer (the client) requests services or data
from another computer (the server).

The process model used in C/S software engineering is evolutionary beginning with
requirements elicitation. Functionality is allocated to subsystems of components that
are assigned to either the client or the server side of the C/S architecture.

Design focuses on integration of existing components and creation of new components.

Implementation and testing must exercise both the client and server functionality
within the context of the component integration standards and the C/S architecture.

C/S software engineering relies on the same SQA practices as other software
engineering processes. Formal technical reviews are used to assess the quality of the
analysis and design models. Specialized reviews consider issues associated with
component integration and middleware. Testing is used to uncover errors at the
component, subsystem, client, and sever levels.

There are different software process models were introduced. Although any of them
could be adapted for use during the development of software for c/s systems, two
approaches are most commonly used:

1. An evolutionary paradigm that makes use of event-based and/or object-oriented

software engineering.
2. Component based software engineering that draws on a library of COTS and in-house
software components.

Client/server systems are developed using the classic software engineering activities
analysis, design, construction, and testing—as the system evolves from a set of general
business requirements to a collection of validated software components that have been
implemented on client and server machines.

Software Components for Client/Server Systems:

Instead of viewing software as a monolithic application to be implemented on one

machine, the software that is appropriate for a c/s architecture has several distinct
subsystems that can be allocated to the client, the server, or distributed between both
machines:

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 101
 Software Engineering (3150711)

1.User interaction/presentation subsystem. This subsystem implements all

functions that are typically associated with a graphical user interface.

2.Application subsystem. This subsystem implements the requirements defined by

the application within the context of the domain in which the application operates.

3.Database management subsystem. This subsystem performs the data manipulation

and management required by an application.

Data manipulation and management may be as simple as the transfer of a record or as

complex as the processing of sophisticated SQL transactions.

Figure: Client/Server Architecture

Structure of Client /Server System

File servers - The client requests specific records from a file. The server transmits
these records to the client across the network.

Database servers - The client sends structured query language (SQL) requests to
the server. These are transmitted as messages across the network. The server
processes the SQL request and finds the requested information, passing back the
results only to the client.

Transaction servers - The client sends a request that invokes remote procedures at
the server site. The remote procedures are a set of SQL statements.

A transaction occurs when a request results in the execution of the remote

procedure with the result transmitted back to the client.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 102
 Software Engineering (3150711)

Groupware servers - When the server provides a set of applications that enable
communication among clients (and the people using them) using text, images,
bulletin boards, video, and other representations, a groupware architecture exists.

10.3 Web Engineering:

Web Engineering is the application of systematic, disciplined and quantifiable
approaches to development, operation, and maintenance of Web- based applications. It
is both a pro-active approach and a growing collection of theoretical and empirical
research in Web application development.

Web engineering homework help provides all the related and important information in
a simplest way which is comprehend by users and learners easily and all the
assignment related work is done on time under the supervision of best online experts.

Web engineering is the process used to create high-quality Web Apps. Web engineering
is not a perfect clone of software engineering, but it borrows many of software
engineering’s.

Fundamental concepts and principles, emphasizing the same technical and

management activities. Web Engineering (WebE) is concerned with the establishment
and use of sound scientific, engineering, and management principles and disciplined
and systematic approaches to the successful development and maintenance of high
quality Web-based systems and applications.

Web Engineering Process :

The characteristics of Web-based systems and applications have a profound influence

on the WebE process.

Immediacy and continuous evolution dictate an iterative, incremental process model

that produces WebApp releases in rapid fire sequence.

The network-intensive nature of applications in this domain suggests a population of

users that is diverse (thereby making special demands on requirements elicitation and
modeling) and an application architecture that can be highly specialized (thereby
making demands on design).

Because WebApps are often content driven with an emphasis on aesthetics, it is likely
that parallel development activities will be scheduled within the WebE process and
involve a team of both technical and non-technical people (e.g., copywriters, graphic
designers).

Frame work for Web Engineering:

As WebApps evolve from static, content-directed information sources to dynamic, user-

directed application environments, the need to apply solid management and
engineering principles grows in importance.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 103
 Software Engineering (3150711)

To accomplish this, it is necessary to develop a WebE framework that encompasses an

effective process model, populated by framework activities and engineering tasks.

Figure: The WebE Process Model

 The WebE process begins with a formulation—an activity that identifies the
goals and objectives of the WebApp and establishes the scope for the first
increment.

1.Planning : estimates overall project cost, evaluates risks associated with the
development effort, and defines a finely granulated development schedule for the initial
WebApp increment, with a more coarsely granulated schedule for subsequent
increments.

2.Analysis : establishes technical requirements for the WebApp and identifies the
content items that will be incorporated.

 Requirements for graphic design (aesthetics) are also defined.

 The engineering activity incorporates two parallel tasks illustrated on the right
side of Figure. Content design and production are tasks performed by
nontechnical members of the WebE team.

The intent of these tasks is to design, produce, and/or acquire all text, graphics, audio,
and video content that are to become integrated into the WebApp.

Page generation is a construction activity that makes heavy use of automated tools for
WebApp creation.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 104
 Software Engineering (3150711)

Testing exercises WebApp navigation; attempts to uncover errors in applets, scripts,

and forms; and helps ensure that the WebApp will operate correctly in different
environments (e.g., with different browsers).

Each increment produced as part of the WebE process is reviewed during customer
evaluation. This is the point at which changes are requested (scope extensions occur).

10.4 Re-Engineering:
Software Re-engineering is a process of software development which is done to
improve the maintainability of a software system. Re-engineering is the examination
and alteration of a system to reconstitute it in a new form. This process encompasses a
combination of sub-processes like reverse engineering, forward engineering,
reconstructing etc.
Re-engineering is the reorganizing and modifying existing software systems to make them
more maintainable.
Objectives of Re-engineering:
 To describe a cost-effective option for system evolution.
 To describe the activities involved in the software maintenance process.
 To distinguish between software and data re-engineering and to explain the
problems of data re-engineering.

Reengineering is the term used for a radical change processes in the organization.
Reorganising and modifying existing software systems to make them more
maintainable.
Sometimes the concept of Business Process Reengineering is used. A variety of
reengineering work products (e.g., analysis model, design model, test procedures) are
product.
The final output is the reengineered business process and/or the engineered software
that supports it.
Re-engineering Cost Factors:
 The quality of the software to be re-engineered
 The tool support available for re-engineering
 The extent of the required data conversion
 The availability of expert staff for re-engineering

Advantages of Re-engineering:
 Reduced Risk: As the software is already existing, the risk is less as compared to
new software development. Development problems, staffing problems and
specification problems are the lots of problems which may arise in new software
development.
 Reduced Cost: The cost of re-engineering is less than the costs of developing new
software.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 105
 Software Engineering (3150711)

System Re-Engineering: Re-structuring or re-writing part or all of a

legacy system without changing its functionality.
Applicable where some but not all sub-systems of a larger system require frequent
maintenance. Re-engineering involves adding effort to make them easier to maintain.
The system may be re-structured and re-documented.
FTR assess the analysis and design models, specialized reviews consider business
applicability and compatibility, testing is applied to uncover errors in content,
functionality, and interoperability.

10.5 Computer-Aided Software Engineering:

Computer aided software engineering (CASE) is the implementation of computer
facilitated tools and methods in software development. CASE is used to ensure a high-
quality and defect-free software. CASE ensures a check-pointed and disciplined
approach and helps designers, developers, testers, managers and others to see the
project milestones during development.

CASE can also help as a warehouse for documents related to projects, like business
plans, requirements and design specifications. One of the major advantages of using
CASE is the delivery of the final product, which is more likely to meet real-world
requirements as it ensures that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development.
It generates a framework for organizing projects and to be helpful in enhancing
productivity.
There was more interest in the concept of CASE tools years ago, but less so today, as the
tools have morphed into different functions, often in reaction to software developer
needs. The concept of CASE also received a heavy dose of criticism after its release.

CASE Tools:

The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes.

Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development life cycle.

CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 106
 Software Engineering (3150711)

Central repository is a central place of storage where product specifications,

requirement documents, related reports and diagrams, other useful information
regarding management are stored. Central repository also serves as data dictionary.

Figure: Components of CASE Tools

1.Upper Case Tools - Upper CASE tools are used in planning, analysis and design
stages of SDLC.

2.Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.

3.Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.

CASE tools can be grouped together if they have similar functionality, process activities
and capability of getting integrated with other tools.

Case Tools Types:

 Diagram tools
 Process Modeling Tools
 Project Management Tools
 Documentation Tools
 Analysis Tools
 Design Tools
 Configuration Management Tools
 Change Control Tools
 Programming Tools
 Prototyping Tools
 Web Development Tools
 Quality Assurance Tools
 Maintenance Tools

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 107
 Software Engineering (3150711)

The advantages of the CASE approach include:

As special emphasis is placed on redesign as well as testing, the servicing cost of a
product over its expected lifetime is considerably reduced.

The overall quality of the product is improved as an organized approach is

undertaken during the process of development.

Chances to meet real-world requirements are more likely and easier with a
computer-aided software engineering approach.

CASE indirectly provides an organization with a competitive advantage by helping

ensure the development of high-quality products.

10.6 Software Process Improvement:

Software Process Improvement (SPI) methodology is defined as a sequence of tasks,
tools, and techniques to plan and implement improvement activities to achieve specific
goals such as increasing development speed, achieving higher product quality or
reducing costs.

SPI can be considered as process re-engineering or change management project to

detect the software development lifecycle inefficiencies and resolve them to have a
better process. This process should be mapped and aligned with organizational goals
and change drivers to have real value to the organization.

Software Process Improvement (SPI) methodology is defined as definitions of

sequence of tasks, tools and techniques to be performed to plan and implement
improvement activities.

Software process improvement is usually one of the most important areas an

organization considers when improving the overall performance of its business
processes and practices.

As part of the improvement process, the CMMI uses a systematic, evidence based
approach which can be applied to any business problem.

In fact, the Capability Maturity Model Integration (CMMI) developed by the Software
Engineering Institute at Carnegie Mellon Institute, grew out of the need to develop
better quality software for industry and the government.

Broadsword applies its unique methodology called Agile CMMI to software process
improvement.

Defining and implementing processes is only part of the improvement picture.The real
key is getting the community to embrace and use the processes.

Agile CMMI uses Agile methods, such as incremental delivery, continuous build and
collaboration to support implementation and acceptance of the process.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 108
 Software Engineering (3150711)

Another key difference in its approach to improving software processes is

Broadsword’s emphasis on using language that software developers and project
managers understand, such as object orientation, encapsulation and other concepts
associated with software development.

10.7 Emerging Trends in Software Engineering:

It is style of software development which is focused on public availability and
communication. Usually communication happens using internet.

It is used in freeware, open source software and commons based peer production. It is
also used in agile development model. It is generally used in development of free
software.

It is very compatible with free software. They meets online for software development. It
is evolution of integrated development environment.

Typical functionalities are:

 Version control system
 Bug tracking system
 To do list
 Mailing list
 Document management system
 Forum

They also involve users in the collaborative development. It is used in most

technological disciplines.

Model-Driven Development:
 It is software design approach for development of software system.
 It provides guidelines for structuring of specifications.
 It is kind of domain engineering.
 It is launched by object management group.
 It defines system functionalities using platform independent model.

Model driven development is shown below:

 Documentation  Pattern/Patterns composition
 Precision  Build and deployment
 Test artifacts  Sketches and blue prints

Test Driven Development:

 It is software development process which relies on repetition of very short
development cycle.
 First, developer writes test cases which define a desired improvement.
 It is related to test first programming concept of extreme programming.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 109
 Software Engineering (3150711)

Challenges of global software development:

 Communication breakdown
 Coordination breakdown
 Control breakdown
 Culture clash
 Ability to gain market share
 Greater flexibility and variable staffing model
 Lower cost labor
 Access to broader set of skilled workers
 Ability to leverage outsourcing providers with specialized skill.

Prepared By: Prof. Nikhilesh Girnara (V.V.P. Engg. College - Rajkot) Page 110