INTRODUCTION

• 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 Engineering is a systematic, disciplined,
quantifiable study and approach to the design,
development, operation, and maintenance of a software
system.
•A software process (also knows
as software methodology) is a set of related activities
that leads to the production of the software.
• A Software Project is the complete procedure
of software development from requirement gathering
to testing and maintenance, carried out according to
the execution methodologies, in a specified period of
time to achieve intended software product.
• A Software engineer is a person who develop and
maintain the software product.
Goals of software engineering
• Accuracy
• Reliability – The software product performs exact task
under the specified time slot.
• Testability
• Reusability
• Adjustability – The ability to be modified or make some
changes in software product for another purposes.
• Cost-effectiveness
• Efficiency
Advantages of Software Engineering
• User satisfaction that fulfills the requirements of the
user.
• Flexible product.
• Better documentation.
• Cost-effective techniques
• Save time.
• Comfortable working environment.
Programming in the small vs.
Programming in the large
• A small program can be written without using software
engineering principles.
• In the large software product, the software engineering
principles are necessary to achieve a good quality software
cost-effectively.
Building construction analogy
• To build a small wall – bricks, cement etc.,
• To build a large multistoried building - difficult to
extend your idea about a small wall construction into
constructing
• A large building, requisite knowledge about the strength
of materials, testing, planning, architectural design, etc.
Programming in the small vs. programming in the
large contd.
•In industry it is usually needed to develop large
programs to accommodate multiple functions at
various levels.
•To develop large programs - use software
engineering principles
•Without using software engineering principles it
would be difficult to develop large programs.
Programming in the small vs. programming in
the large contd.
• The problem is that the complexity and the difficulty
levels of the programs increase exponentially with their
sizes
• For example, a program of size 1,000 lines of code has
some complexity. But a program with 10,000 LOC is not 10
times more difficult to develop, but may be 100 times
more difficult unless software engineering principles are
used.
• Thus, Software engineering helps to reduce the
programming complexity.
Complexity and the difficulty levels of the
programs vs program sizes
Techniques that software engineering uses to tackle the problem of exponential growth
of problem complexity with its size:
Software engineering principles use two important techniques to reduce problem
complexity are
1. Abstraction and
2. Decomposition.
Abstraction:
• A problem can be simplified by omitting irrelevant details.
• The main purpose of abstraction is to consider only those aspects of the problem that are
relevant for a certain purpose and suppress other aspects that are not relevant for the
given purpose.
• Once the simpler problem is solved, then the omitted details can be taken into
consideration to solve the next lower-level abstraction, and so on.
• Abstraction is a powerful way of reducing the complexity of the problem.
A HIERARCHY OF ABSTRACTION
Decomposition:
• A complex problem is divided into several smaller problems and then the
smaller problems are solved one by one.
• Any random decomposition of a problem into smaller parts will not help.
• The problem has to be decomposed such that each component of the
decomposed problem can be solved independently and then the solution
of the different components can be combined to get the full solution.
A good decomposition of a problem as
• Should minimize interactions among various
components. If the different subcomponents
are interrelated, then the different components
cannot be solved separately and the desired
reduction in complexity will not be realized.
Characteristics that differentiate a small
program from a large software product
Small program:
• Individuals develop the small programs for personal use are
small in size with limited functionality
• The programmer himself is the sole user
• A single developer is involved
• User interface may not be so important because programmer is
the sole user.
• Very little documentation is expected
• A program can be developed according to the programmer’s
individual style of development
 Characteristics that differentiate a small
program from a large software product
Large Software product:
• Large software products are extremely large.
• A large number of developers are involved.
• User interface must be very important because
developers of that product and users of that product are
totally different.
• It must be well documented.
• It must be developed using software engineering
principles
Small program vs large software products
 Symptoms of the software crisis
• Organizations are spending larger and larger portions of their budget on
software.
• The software products turned out to be more expensive than the hardware.
Other software product problems to the customers are:
• Software products are difficult to alter, debug, and enhance
• Use resources non-optimally
• Often fail to meet the user requirements
• Far from being reliable
• Frequent crashes and are often delivered late.
• Among these, the trend of increasing software costs is probably the most
important symptom of the present software crisis.
Factors that have contributed to the making of the
present software crisis:
• Larger problem sizes,
• Lack of adequate training in software engineering,
• Increasing skill shortage, and
• Low productivity improvements.
Possible solutions to the above software crisis:
• The solution to the present software crisis can possibly
come from a spread of software engineering practices
among the engineers, coupled with further advancements
in the software engineering discipline itself.
 Software project failures and importance
of software quality and timely availability
Software-Related Failures
• Programming errors - Errors such as incorrect storage size
can be catastrophic
• Passive failures - Software, node, and link failures can cut off
sub-systems
• Active failures - Faulty software can interfere with other sub-
systems
• Byzantine failures - Malicious agents can actively interfere
with system operation
The software failure can be classified as:
• Transient failure: These failures only occur with specific inputs.
• Permanent failure: This failure appears on all inputs.
• Recoverable failure: System can recover without operator help
• Unrecoverable failure: System can recover with operator help only.
• Non-corruption failure: Failure does not corrupt system state or data.
• Corrupting failure: It damages the system state or data.
Epic Software Failures
• European Space Agency’s Ariane 5 Explosion
• Hospital Radiation Incident
• London Ambulance Service
• Denver Airport Baggage Handler
• East Coast Blackout(cascading power plant failures)
• AT&T Switch Failure -$Billion bug
• FAA’s Advanced Automation System
• NASA Mars Lander, Pathfinder, and Spirit
• Juspay – in india – data breach
• Yahoo – data breach
European Space Agency
• Ariane 5 Failure
• Ariane 4 SRI (Inertial Reference Systems) software reused on new
Ariane 5
• Operand Error exception due to overflow in converting 64bit FP to 16bit
INT
• Launcher disintegrated after 39 sec because of high aerodynamic loads
• Cause: Unknown Reuse Risk in Business Case
Medical Radiation Incident
• Machine provide graphical user interface
• Hospital workers selected options via fields
• Tab-key & Shift-Tab combination used to move between fields
• Some hospital workers used up & down arrows to move between rows
of fields
• Moved cursor, but internally, didn’t change fields
• Result: Data entered in wrong fields some patients over-radiated and
did not survive
London Ambulance Service
• Computer Aided Dispatch System to automate human-intensive
processes of manual dispatch
• Call Taking (assumed to be better)
• Receive calls, record incident details, pinpoint location
• System went live on 26th October 1992
• Taken offline next day and reverted to semi-manual dispatching on 28th
October 1992
• Increased incident errors
• increased number of exceptions
• increased incorrect information
Result: 20–30 people speculated to have died as a result of ambulances
arriving too late
Why do Software Projects Fail?
• Unrealistic or unarticulated project goals
• don’t meet all the requirements - cost, schedule, quality, or requirements objectives
• Inaccurate estimates of needed resources or lack of resources
• Badly defined system requirements or Changing requirements
• Poor reporting of the project's status
• Unmanaged risks
• Poor communication: clients, developers, & users or lack of user participation
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics or lack of Stakeholder involvement
• Commercial pressures

Source: Robert Charette Article

Software failures may be due to :
• Bugs,
• Ambiguities,
• Oversights
• Misinterpretation of the specification that the software is supposed
to satisfy,
• carelessness or incompetence in writing code,
• inadequate testing,
• incorrect or unexpected usage of the software
• other unforeseen problems.
What are the causes of software project
failure?
• Beginning the programming before understanding the Problem
• The project team has an unrealistic idea about how much work is involved
• Complex problems often seem simple before they are attempted
• Optimistic/Impossible deadlines result from not thinking through the work
• Defects injected early but discovered late
• Poor Programming habits and no accountability for work
• The team does not have a good sense of the overall health of the project
• Managers trying to test the quality of the software
• Assumes testers will catch all of the defects
• When testers miss defects, everyone blames them for not being perfect
How can software projects succeed?
• Make sure all decisions are based on openly shared
information
• Don’t second-guess your team members’ expertise
• Introduce software quality from the very beginning of the
project
• Don’t impose an artificial hierarchy on the project team
• Remember that the fastest way through the project is to use
good engineering practices
Importance of software quality
• A software quality factor is a non-functional requirement for a software
program that is not called upon by the customer’s contract, but
nevertheless is a desirable requirement that enhances the software
program quality.
Issues that affect the quality of the code are as follows:
• Readability
• Low complexity
• Ease of maintenance, testing, debugging, fixing, modifying and portability
• Low resource consumption
• Number of compilations or lint warnings
• Robust input validation and error handling, established by software fault
injection
software quality factors
• Understandability
• Completeness
• Conciseness – minimal code
• Portability
• Consistency
• Maintainability - facilitate updates for satisfying new requirements
• Testing - a complex design leads to poor testability.
• Usability - Graphical User Interface (GUI).
software quality factors
• Reliability - product is expected to perform correctly over a
period of time.
• Structuredness - block-structured language
• Efficiency - The fulfilment of purpose without wasting resources
• Security - The ability of protecting data against unauthorized
access and withstanding malicious interference with its
operations and the ability to withstand malicious, intelligent
attackers.
• Security mechanisms - access control, authentication and encryption
• Quality control target not only on detecting the
defective devices and removes them but also on
determining the causes behind the defects. Thus, quality
control aims at correcting the reasons for bugs and not
just rejecting the products. The next breakthrough in
quality methods was the development of quality
assurance methods.
• The primary premise of modern quality assurance is that
if an organization's processes are proper and are
followed rigorously, then the products are obligated to
be of good quality. The new quality functions include
guidance for recognizing, defining, analyzing, and
improving the production process.
• Total quality management (TQM) advocates that the
procedure followed by an organization must be
continuously improved through process measurements.
TQM goes stages further than quality assurance and
aims at frequently process improvement. TQM goes
beyond documenting steps to optimizing them through
a redesign. A term linked to TQM is Business Process
Reengineering (BPR).
Engineering Approach to Software
Development
• Software Engineering is the systems engineering approach for software product/application development.
It is an engineering branch associated with analyzing user requirements, design, development, testing, and
maintenance of software products.
• Some basic principles of good software engineering are –
❖ One of the basic software Engineering principles is Better Requirement analysis which gives a clear vision of the project. At
last, a good understanding of user requirements provides value to its users by delivering a good software product that meets
users’ requirements.

❖ All designs and implementations should be as simple as possible mean the KISS (Keep it Simple, Stupid) principle should be
followed. It makes code so simple as a result debugging and further maintenance become simple.

❖ Maintaining the vision of the project is the most important thing throughout complete development process for the success of
a software project. A clear vision of the project leads to the development of the project in the right way.

❖ Software projects include a number of functionalities, all functionalities should be developed in a modular approach so that
development will be faster and easier. This modularity makes functions or system components independent.

❖ Another specialization of the principle of separation of concerns is Abstraction for suppressing complex things and delivering
simplicity to the customer/user means it gives what the actual user needs and hides unnecessary things.

❖ Think then Act is a must-required principle for software engineering means before starting developing functionality first it
requires to think about application architecture, as good planning on the flow of project development produces better results.

❖ Sometimes developer adds up all functionalities together but later find no use of that. So following the Never add extra
principle is important as it implements what actually needed and later implements what are required which saves effort and
time.
❖ When other developers work with another’s code they should not be surprised and should not waste their time in
getting code. So providing better Documentation at required steps is a good way of developing software projects.

❖ Law of Demeter should be followed as it makes classes independent on their functionalities and reduces connections
and inter dependability between classes which is called coupling.

❖ The developers should develop the project in such a way that it should satisfy the principle of Generality means it
should not be limited or restricted to some of cases/functions rather it should be free from unnatural restrictions and
should be able to provide service to customers what actually they need or general needs in an extensive manner.

❖ Principle of Consistency is important in coding style and designing GUI (Graphical User Interface) as consistent
coding style gives an easier reading of code and consistency in GUI makes user learning easier in dealing with
interface and in using the software.

❖ Never waste time if anything is required and that already exists at that time take the help of Open source and fix it in
your own way as per requirement.

❖ Performing continuous validation helps in checking software system meets requirement specifications and fulfills its
intended purpose which helps in better software quality control.

❖ To exit in current technology market trends Using modern programming practices is important to meet users’
requirements in the latest and advanced way.

❖ Scalability in Software Engineering should be maintained to grow and manage increased demand for software
applications.
• There are several basic principles of good software engineering approach that are commonly followed by
software developers and engineers to produce high-quality software. Some of these principles include:
1. Modularity: Breaking down the software into smaller, independent, and reusable components or modules. This
makes the software easier to understand, test, and maintain.
2. Abstraction: Hiding the implementation details of a module or component and exposing only the necessary
information. This makes the software more flexible and easier to change.
3. Encapsulation: Wrapping the data and functions of a module or component into a single unit, and providing
controlled access to that unit. This helps to protect the data and functions from unauthorized access and
modification.
4. DRY principle (Don’t Repeat Yourself): Avoiding duplication of code and data in the software. This makes the
software more maintainable and less error-prone.
5. KISS principle (Keep It Simple, Stupid): Keeping the software design and implementation as simple as
possible. This makes the software more understandable, testable, and maintainable.
6. YAGNI (You Ain’t Gonna Need It): Avoiding adding unnecessary features or functionality to the software. This
helps to keep the software focused on the essential requirements and makes it more maintainable.
7. SOLID principles: A set of principles that guide the design of software to make it more maintainable, reusable,
and extensible. This includes the Single Responsibility Principle, Open/Closed Principle, Liskov Substitution
Principle, Interface Segregation Principle, and Dependency Inversion Principle.
8. Test-driven development: Writing automated tests before writing the code, and ensuring that the code passes all
tests before it is considered complete. This helps to ensure that the software meets the requirements and
specifications.
 SOFTWARE PROCESS MODEL
• There are various software development models which is
used in software development life cycle to represent the
process of building a software.
• SDLC models defines all the phases of software
development.
• SDLC models can have a different methodology but
the phases remains the same.
• The development team chooses the best SDLC model
to develop a software product so that the efficient
and reliable software product is developed.
38
• By using SDLC models, you can develop a software
product in a systematic and nice way.
• Here are some important SDLC models given below-
•Waterfall Model
•Iterative Waterfall Model
•Agile Model
•Spiral Model
•Prototype Model
•V model
•RAD model
39
1. Waterfall Model :-
• In software engineering, the first software development
model is Waterfall model.
• In the 1970, Winston Royce proposed the model for software
development , the model is called the waterfall model.
• Waterfall model is also called Linear-sequential life cycle
model because this model specifies the software development
process in a linear sequence manner.
• In the waterfall model, the output of the previous phase will
be the input to the next phase in the software development
life cycle.
40
• Each phase has contains
various different tasks and
different activity to
complete the process.
• In this model, we cannot go
back to the previous phase
to alter any thing if we come
to the next phase.
• Overlapping is not done
with the phases/stages of
software development life
cycle.
41
Advantages of waterfall model :
• It is easy to use and understand.
• No overlapping between the phases.
• This model is suitable for small projects.
• It is a linear sequence model. It works in a flow step by step
• High visibility because output of each phase is generated for the next
phase
• It provides more flexibility.
• Better documentation for the employees.
• Low cost.
• It is easy to maintain.

42
 Disadvantages of waterfall model :
• This model does not work well for large projects.
• We cannot go back at previous phase to change
anything or any requirement.
• No changes can be made in the project.
• It can take a long time to complete the project.
• If customer does not satisfied with the project then it
is hard to change the requirements.
• High risk to make a project
43
 Iterative Waterfall Model
• Iterative Waterfall Model is the extension of the Waterfall
model.
• This model is almost same as the waterfall model except some
modifications are made to improve the performance of the
software development.
• The iterative waterfall model provides customer’s feedback
paths from each phase to its previous phases.
• There is no feedback path provided for feasibility study
phase, so if any change is required in that phase then iterative
model doesn’t have scope for modification or making
corrections.
44
• Iterative waterfall allows to go
back on the previous phase
and change the requirements
and some modification can
done if necessary.
• This model reduces the
developer’s effort and time
required to detect and correct
the errors.
• In iterative waterfall model,
next phase can only begins
when the previous phase is
completed as waterfall model.
45
 Advantages of Iterative Waterfall Model :-
• Iterative waterfall model is very easy to understand and use.
• Every phase contains feedback path to its previous phase.
• This is an simple to make changes or any modifications at
any phase.
• By using this model, developer can complete project earlier.
• Customer involvement is not required during the software
development.
• This model is suitable for large and complex projects.

46
Disadvantages of Iterative Waterfall Model :-
• There is no feedback path for feasibility study phase.
• This model is not suitable if requirements are not clear.
• It can be more costly.
• There is no process for risk handling.
• Customer can view the final project. there is no prototype
for taking customer reviews.
• This model does not work well for short projects.
• If modifications are required repeatedly then it can be more
complex projects.

47
 Evolutionary Process Model
• Evolutionary process model resembles the iterative enhancement
model.
• The same phases are defined for the waterfall model occurs here in a
cyclical fashion.
• This model differs from the iterative enhancement model in the sense
that this does not require a useful product at the end of each cycle. In
evolutionary development, requirements are implemented by category
rather than by priority.
• Following are the evolutionary process models.
1. The prototyping model
2. The spiral model

48
 Spiral Model
• In 1986, the spiral model was proposed by Barry Boehm.
• Spiral model is based on the evolutionary model which is the
combination of linear sequential model and iterative software
development model.
• This model is suitable for large and complex projects.
• Spiral model is based on spirals (iterations) to develop a project.
• A phase in the software development life cycle is a loop of the
spiral.
• This model works very well for large projects because it involves
constant improvements until a final product is not build.
49
• The whole development process
is completed in the 4 phases.
• The spiral model has four phases
in a spiral:
• Planning
• Risk analysis
• Development and testing
• Evaluation

50
 Phases of spiral model :
• Planning :
• The requirements are collected from the clients. Feasibility
study is done in this phase. It includes cost estimation,
schedule, objectives are defined and other resources for the
iteration to develop a software project.
• Risk analysis :
• In the second phase of development, risks are identified and
find different solutions to remove risks. If any risk is find out
during the phase then alternate solutions are designed and
implemented the best way among them.
52
•Development and testing :
•After risk analysis phase is completed, the
software product is developed and tested at the
end of each iteration so there is development and
testing applied at same phase.
•Evaluation :
•In the last phase, the feedback is taken from the
customer and evaluate the developed project
after completion of each iteration. To carry
on next iteration, evaluation phase is completed.
53
Advantages of Spiral Model :

• This model is good for large and complex projects.

• Updates are received to the customer at each
iteration.
• Spiral model is suitable to change the requirements
at any time, any phase.
• Risks are analyzed after each iteration.
• Documentation is clearly defined and
understandable.
54
Disadvantages of Spiral Model :

• Spiral model is not good for small projects.

• This model is more complex and difficult to
understand if a new employee is entered in the
project development.
• It can be much expensive.
• Fast development and software is built at the SDLC .
• Not defined end points of the project , so it can take
a long time to develop or iterations can be go
infinitely.
55
 Prototype Model
• Software Prototyping :
• Software Prototyping is the process of creating a prototype of
the software product. the prototype is an incomplete form of
software program to evaluate customer satisfaction.
• Prototype model is the extension of iterative waterfall model.
• Prototype model is one of the most popular used software
development model in which prototype is built and tested to
evaluate the customer satisfaction.

56
•Prototype model proposes the system in
which a prototype is developed before
developed the whole software product.
•This model is used when all the
requirements and resources are not clearly
defined at the beginning of the phases.
57
58
 Steps followed by the Prototyping Model :-
• Requirement Recognition and Gathering : This step requires
primary requirements so that a prototype is created.
• Prototype Development : Prototype is built on the basis of
the requirement of the customer and this is developed to take
the customer’s reviews.
• Customer Reviews : Prototype is send to the customer and
take reviews of the customer.
• After taking the customer reviews, developer starts to make
the whole software product.
• If customer is not satisfied then it can be discarded and again
create the prototype.

59
 Advantages of Prototype Model :-
• It provides higher customer satisfaction and get reviews from
customers.
• Requirements can change easily according to the customer. It
means this model has high adaptability.
• Errors can be removed so fast and early hence it saves a lot of
cost.
• It gives high flexibility.
• Prototype model increases the involvement of customers.
• Developers can identify the missing functionality very easily.
• This model helps to reduce the risks related to the software.

60
 Disadvantages of prototype model :-
• This model can be more costly.
• Prototype model can be more complex if a prototype is
reviewed by the customers again and again.
• It does not provide clear documents.
• This model can take more time to develop a software
product.
• If a customer refuses to accept the prototype ,then
there may be wastage of a lot of cost and developer’s
efforts.
61
 RAD Model
• Rapid Application Development model firstly introduced by
IBM in 1980’s.
• RAD Model is generally based on the prototype model and
iterative approach.
• This model is used to completing the process of software
product developing in a very short time.
• The entire project is divided into various small modules and
each module is allocated to different party to finish the working
of the small modules.
• After that, all small modules are combined together to obtain
the final project.
62
•If your project can be divided into many parts or
modules then the Rapid application development
model is used.
•Each module is developed like the waterfall
model.
•The process of RAD model is building the Rapid
prototype and deliver it to the clients and taking
the reviews from them . If customer is satisfied
then SRS document is created and designing
phase is start.

63
64
Process of RAD Model :-
There are four phases in this model :-
1-Requirement Analysis:-
• There are various approaches which is used in requirement
planning like brainstorming , task analysis ,form analysis ,user
scenario etc. This phase consists plan or designing of each
module which contains data, methods and other resources.
2- Customer Evaluation:-
• In this phase, developer evaluates the customer satisfaction by
delivering the prototype and taking the reviews from them. If the
customer is satisfied then developer starts implementation.
65
3- Construction :-
•Prototype is refining and all the modification
,correction and improvements is done in this
phase. This phase helps us to convert the
process and modules into the final working
product.
4- Cut Over :-
•This is the last stage of the RAD model. In this
phase, all the independent modules are
evaluated separately .The tools and sub-parts of
product makes the testing of the product very
easy.
66
 Advantages of RAD Model :-
• RAD model completes the project in a short period of time.
• The progress and development of project can be check on
various stages .
• This model uses the powerful techniques and tools.
• reduce cost because very less developers are needed.
• Prototype is delivered to the customer so the customer is
satisfied.
• It has more flexibility and adaptability to acquire the new
requirements.
• Reusability of the components is increased.
67
 Disadvantages of RAD Model :-
•Team leader must to do work with developers to
complete the work on time.
•Customer involvement are needed
•This model works only when the requirements
are clearly specified.
•This model can be more complex if prototype is
refined again and again.
•RAD model is not suitable for the short projects.
68
V Model
• V-model is also a part of SDLC MODEL .
• V- model is also called Verification and Validation model .
• This model is the extension of the Waterfall Model.
• The V form of the V model shows the various phases of the
verification and validation phases.
• In this model one phase for verification and other for
validation and the coding phase joins the both phases
verification and Validation .so that makes the V shape so this
model is called V-model.
69
• This process starts from the top left i.e. verification phase
towards the top right phases i.e. validation phases and
follows a linear improvement like waterfall model.
• This model mainly use for testing phase .
• The next phase of development start after completing first
phase.
• In the waterfall model testers involves in the last phase of
the model but this model overcomes the drawbacks of the
waterfall model.
• In V model ,testers involves in the early phases of the
development process.
70
71
Process of V Model:
This model consists two main phases :
1- Verification phase
2- Validation phase
Verification :
• Verification is the process to verify that the software product
development phase to determine that specified requirements meet or
not ? In this phase, there is no need to execute the code for testing.
Validation :
• Validation is the process to verify that the software product fulfills the
customer requirements and expectations or not. In this phase, there is
need of execution of the code.

72
 Phases of Verification Stage:
• Requirement Analysis : In this phase, developers collects
information from customers about the software.
• System Design : When the requirements are defined clearly then
implement and design the complete hardware and
communication setup for developing product and choose the
programming language and databases.
• System Architecture : Architectural specifications are designed in
this phase. The system design is splits further into modules taking
up different working. This is also called High Level Design (HLD).
• In this stage, communication and transformation of data between
the internal modules and the outer world is clearly specified.
73
•Module Design : In this phase the system breaks
down into small modules. The detailed design of
modules is specified, it is also called the Low-
Level Design (LLD).
•Implementation/ Coding Phase : This is the last
phase of the V-Shape model. Module design is
transformed into the code. The coding is done
based on the coding principles and standards in
a particular selected programming language.
74
Phases of Validation Stage :
• Unit Testing : Unit testing is a type of white box testing
.These Unit Test Plans are executed to remove bugs at
code level. Unit Test Plans are created during the
module design phase.
• Integration Phase : In the integration testing, the
integration test cases are executed which were
developed in the High level design phase. Integration
testing is a testing process in which unit tested modules
are integrated and evaluated. It verifies that the
modules work together as expected or not .
75
•System Testing : System testing is done
corresponds with the system design phase.
•It tests the functional and non-functional
requirements and evaluate the whole system
functionality and the communication of the
system with external systems.
•Acceptance Testing : This testing is done to check
that the delivered system meets user’s
requirement or not? Nonfunctional testing such
as Load, Stress etc. are also done in this phase.
76
 Advantages of V Model :-
1- It works very well for small project according to their
requirement
2- This model is very simple, easy and useful.
3- This is a high quality model and all the phases are completed
at once.
4- This model is use to track the process of project management
.
5- This model saves a lot of time and efforts.
6- Testing is starting at the initial phase so there is no issue of
bugs.
77
Disadvantages of V Model :-
1- This model can not be use for large project.
2- This model is not good if customer’s requirements are not
clear.
3- There are lots of risk.
4- This model is not easy for complex projects .
5- Client have no prototype and involvement during the
software development.
6- This model contains less flexibility.
7- It is hard to go back and alter the working of the system if
new requirements are met.
78
AGILE MODEL

•AGILE methodology is a practice that

promotes continuous iteration of development
and testing throughout the software
development lifecycle of the project.
•Both development and testing activities are
concurrent unlike the Waterfall model

79
The agile software development emphasizes on
four core values.
• Individual and team interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

82
Agile Vs Waterfall Method

• Agile and Waterfall model are two different methods

for software development process. Though they are
different in their approach, both methods are useful
at times, depending on the requirement and the type
of the project.

83
 Agile Model
•Agile method proposes incremental
and iterative approach to software
design
•The agile process is broken into
individual models that designers work
on
•The customer has early and frequent
opportunities to look at the product and
make decision and changes to the
project
Waterfall Model
•Development of the software flows
sequentially from start point to end
point.
•The design process is not broken into
an individual models
•The customer can only see the product
at the end of the project

•Agile model is considered unstructured •Waterfall model are more secure

compared to the waterfall model because they are so plan oriented

84
•Small projects can be implemented very •All sorts of project can be estimated and
quickly. For large projects, it is difficult to completed.
estimate the development time.

•Error can be fixed in the middle of the •Only at the end, the whole product is
project. tested. If the requirement error is found or
any changes have to be made, the project
has to start from the beginning

•Development process is iterative, and the •The development process is phased, and
project is executed in short (2-4) weeks the phase is much bigger than iteration.
iterations. Planning is very less. Every phase ends with the detailed
description of the next phase.

•Documentation attends less priority than •Documentation is a top priority and can
software development even use for training staff and upgrade the
software with another team
85
•Every iteration has its own testing phase. It •Only after the development phase, the testing
allows implementing regression testing every phase is executed because separate parts are
time new functions or logic are released. not fully functional.

•In agile testing when an iteration end, shippable •All features developed are delivered at once
features of the product is delivered to the after the long implementation phase.
customer. New features are usable right after
shipment. It is useful when you have good
contact with customers.

•Testers and developers work together •Testers work separately from developers

•At the end of every sprint, user acceptance is •User acceptance is performed at the end of the
performed project.
•It requires close communication with developers •Developer does not involve in requirement and
and together analyze requirements and planning planning process. Usually, time delays between
tests and coding

86
Agile Methodology

87
Scrum
•SCRUM is an agile development method which
concentrates specifically on how to manage
tasks within a team-based development
environment.
•Scrum believes in empowering the development
team and advocates working in small teams
(say- 7 to 9 members).
88
It consists of three roles, and their responsibilities are
explained as follows:

89
•Scrum Master
•Master is responsible for setting up the team,
sprint meeting and removes obstacles to
progress
•Product owner
•The Product Owner creates product backlog,
prioritizes the backlog and is responsible for the
delivery of the functionality at each iteration
•Scrum Team
•Team manages its own work and organizes the
work to complete the sprint or cycle
90
Product Backlog
• This is a repository where requirements are tracked
with details on the no. of requirements(user stories)
to be completed for each release.
• It should be maintained and prioritized by Product
Owner, and it should be distributed to the scrum
team.
• Team can also request for a new requirement addition
or modification or deletion
91
 Process flow of Scrum Methodologies:
Process flow of scrum testing is as follows:
• Each iteration of a scrum is known as Sprint
• Product backlog is a list where all details are entered to get
the end-product
• During each Sprint, top user stories of Product backlog are
selected and turned into Sprint backlog
• Team works on the defined sprint backlog
• Team checks for the daily work
• At the end of the sprint, team delivers product functionality
92
 eXtreme Programming (XP)
• Extreme Programming technique is very helpful when there is
constantly changing demands or requirements from the
customers or when they are not sure about the functionality
of the system.
• It advocates frequent "releases" of the product in short
development cycles, which inherently improves the
productivity of the system and also introduces a checkpoint
where any customer requirements can be easily
implemented.
• The XP develops software keeping customer in the target.
93
94
•Business requirements are gathered in terms of
stories. All those stories are stored in a place
called the parking lot.
•In this type of methodology, releases are based
on the shorter cycles called Iterations with span
of 14 days time period. Each iteration includes
phases like coding, unit testing and system
testing where at each phase some minor or
major functionality will be built in the
application.
95
Phases of eXtreme programming:
•There are 6 phases available in XP method, and
those are explained as follows:
• Planning
• Analysis
• Design
• Execution
• Wrapping
• Closure
96
Planning
• Identification of stakeholders and sponsors
• Infrastructure Requirements
• Security related information and gathering
• Service Level Agreements and its conditions
Analysis
• Capturing of Stories in Parking lot
• Prioritize stories in Parking lot
• Scrubbing of stories for estimation
• Define Iteration SPAN(Time)
• Resource planning for both Development and QA teams 97
Design
• Break down of tasks
• Test Scenario preparation for each task
• Regression Automation Framework
Execution
• Coding
• Unit Testing
• Execution of Manual test scenarios
• Defect Report generation
• Conversion of Manual to Automation regression test cases
• Mid Iteration review
• End of Iteration review
98
Wrapping
• Small Releases
• Regression Testing - Testing the modified parts of the code
• Demos and reviews
• Develop new stories based on the need
• Process Improvements based on end of iteration review comments
Closure
• Pilot Launch - experimental trial
• Training
• Production Launch
• SLA Guarantee assurance - level of service expected by a customer
• Review SOA strategy
• Production Support
99
 Role of software engineering towards
successful execution of large software
projects
Computer Scientist
• Proves theorems about algorithms, design languages, defines knowledge
representation schemes, who has infinite time
Engineer
• Develops a solution for an application-specific problem for a client
• Uses computers and languages, tools, techniques and methods
Software engineer
• Works in multiple application domains
• Has only 3 months
• While changes occur in requirements and available technology
 General Role of Software Engineer
He must be a
•Good programmer
• Well-versed in data structures and algorithms
•Fluent in one or more programming languages
•Familiar with several design approaches
•Structured approach
• Object-oriented approach
• Able to translate vague requirements and desires into precise
specifications
• Able to converse with a user of a system in terms of
application rather in computers
• Able to move among several levels of abstraction at different
stages of a project
• Develop skills about allow him to build a variety of models
and to reason about those models in order to guide choices of
many trade-offs faced in the software development process
• Need communication skills and interpersonal skills
• Needs the ability to schedule work both of his own and that
of others
 Emergence of software engineering as
a discipline
Myth 1: Computers are more reliable than the devices they have replaced.
• Considering the reusability of the software, it can undoubtedly be said that
the software does not fail.
• However, certain areas which have been mechanized have now become
prone to software errors as they were prone to human errors while they
were manually performed.
• For example, Accounts in the business houses.
Myth 2: Software is easy to change.
• Yes, changes are easy to make - but hard to make without introducing
errors. With every change the entire system must be re-verified.
• Myth 3: If software development gets behind scheduled,
adding more programmers will put the development back on
track.
• Software development is not a mechanistic process like
manufacturing. In the words of Brooks: “adding people to a
late software project makes it later”.
Myth 4: Testing software removes all the errors.
• Testing ensures presence of errors and not absence. Our
objective is to design test cases such that maximum number of
errors is reported.
Myth 5: Software with more features is better software.
• This is exactly the opposite of the truth. The best programs are
those that do one kind of work.
Myth 6: Aim has now shifted to develop working
programs.
•The aim now is to deliver good quality and efficient
programs rather than just delivering working
programs.
•Programs delivered with high quality are
maintainable.
The above list is unending. These myths together with
poor quality, increasing cost and delay in the
software delivery have lead to the emergence of
software engineering as a discipline.