Introduction to Software Engineering

• A systematic collection of good development practices and

techniques
• Software engineering discusses systematic and cost-effective
techniques for software development.

EVOLUTION
• Software engineering principles have evolved over the last sixty
years
• The early programmers used an ad hoc programming style, where
a program is quickly developed without making any specification,
plan, or design. This style was widely adopted by the programmers
in the early years of computing history.
• Software engineering principles are now being widely used in
industry
 A Solution to the Software Crisis
• Organizations are spending increasingly larger portions of
their budget on software
• Software products are difficult to alter, debug, and enhance
• Often fail to meet the user requirements
 Impact of Software Engineering
• 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 LIFE CYCLE MODELS
• A software development life cycle (SDLC) model (also called
software life cycle model and software development process
model ) describes the different activities that need to be
carried out for the software to evolve in its life cycle.
• An SDLC graphically depicts the different phases through
which a software evolves.
 Waterfall Model
• Waterfall model is the simplest model of software
development
• All the phases of SDLC will function one after another in linear
manner. That is, when the first phase is finished then only the
second phase will start and so on.
• In this approach, the whole process of software development
is divided into separate phases. Typically, the outcome of one
phase acts as the input for the next phase sequentially.
• Requirement Gathering and analysis − All possible
requirements of the system to be developed are captured in
this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first
phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the
system is first developed in small programs called units, which
are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the
implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-
functional testing is done; the product is deployed in the
customer environment or released into the market.
• Maintenance − There are some issues which come up in the
client environment. To fix those issues, patches are released.
Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the
customer environment.
 Prototype Model
• The prototype model requires that before carrying out the
development of actual software, a working prototype of the
system should be built.
• A prototype is a toy implementation of the system.
• In many instances, the client only has a general view of what
is expected from the software product.
• In such a scenario where there is an absence of detailed
information regarding the input to the system, the processing
needs, and the output requirement, the prototyping model
may be employed.
 Evolutionary model
• In the evolutionary model, all the work is done during the
development phase.
• In this model, all work divided into small chunks or modules.
• The user feedback is very helpful for the development of the
next stage because after the completion of one stage we get
the feedback to the user, the user feedback is very essential
for the development of the next phase.
• In the evolutionary model, all work divided into smaller
chunks. These chunks present to the customer one by one.
The confidence of the customer increased.
• It is very useful in a large project where you can easily find a
module for step by step implementation.
• The evolutionary model is used when the users need to start
using the many features instead of waiting for the complete
software.
• The big advantage of the evolutionary model is that the user
has checked every stage during the development and it is
helpful in achieving customer confidence.
 Spiral Model
• The spiral model, initially proposed by Boehm, is an
evolutionary software process model that couples the
iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model.
• Using the spiral model, the software is developed in a series
of incremental releases.
• Objective setting: Each cycle in the spiral starts with the
identification of purpose
• Risk Assessment and reduction: The next phase in the cycle is
to calculate these various alternatives based on the goals and
constraints. The focus of evaluation in this stage is located on
the risk perception for the project.
• Development and validation: The next phase is to develop
strategies that resolve uncertainties and risks.
• Planning: Finally, the next step is planned. The project is
reviewed, and a choice made whether to continue with a
further period of the spiral.
Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
• Suitable for large-scale products.
• New functionality or changes can be accommodated at later
stages.
• Efficient cost estimation.
• Development is fast.
• Proper risk management.
Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• It is not suitable for small projects as it is expensive.
• It is much more complex than other SDLC models. ...
• Too much dependable on Risk Analysis and requires highly
specific expertise.
• Difficulty in time management. ...
• Spiral may go on indefinitely.
• End of the project may not be known early.
 Feasibility study
• The objective of the feasibility study is to establish the
reasons for developing the software that is acceptable to
users, adaptable to change and conformable to established
standards.
• To analyze whether the software will meet organizational
requirements.
• To determine whether the software can be implemented
using the current technology and within the specified budget
and schedule.
• To determine whether the software can be integrated with
other existing software.
 Types of Feasibility
• technical feasibility,
• operational feasibility, and
• economic feasibility.
• Technical feasibility assesses the current resources (such as
hardware and software) and technology, which are required
to accomplish user requirements in the software within the
allocated time and budget.
• Operational feasibility assesses the extent to which the
required software performs a series of steps to solve business
problems and user requirements. This feasibility is dependent
on human resources (software development team)
• Economic feasibility determines whether the required
software is capable of generating financial gains for an
organization. It involves the cost incurred on the software
development team, estimated cost of hardware and software,
cost of performing feasibility study, and so on.
 Types of Requirements
• Functional Requirements
• Non-Functional Requirements
 Functional requirements
• Functional requirements define what a software system
should do.
• Functional requirement implementation in a system is
planned in the System Design phase
• Tells about the behavior of a function or feature.
• The user will pass input and check whether the output is
correctly displayed.
• Functional requirements form the skeleton of Software
system implementation
• These are mostly visible to the customer.
• Example, Profile photo on Facebook should be visible on
login.
Types of Functional Requirements
• Interoperability: Requirement describes whether a software
system is interoperable across different systems. Example:
email service systems like Gmail allows importing emails from
other mail exchange servers like Yahoo.com or
Rediffmail.com.
• Security: The functional requirement describes the security
aspect of software requirements. Example: the social
networking site Facebook. A user’s data should be secure and
must not be leaked to an outsider.
• Accuracy: Accuracy defines a data entered into the system is
correctly calculated and used by the system and that the
output is correct. Example an online banking solution, when
the user receives a fund, the amount received should be
correctly credited to the account and no variation in the
accuracy is accepted.
• Compliance: Compliance functional requirements validate
that the developed system is compliant to Industrial
standards. Example can be from a Web-based application for
the railway ticketing system. The website should follow the
cyber security guidelines and comply with the World Wide
Web in terms of accessibility.
 Non-functional requirements
• Non-functional requirements in software engineering refer to
the characteristics of a software system that are not related to
specific functionality or behavior.
• They describe how the system should perform, rather than
what it should do.
• Examples of non-functional requirements include:
• Performance: This is related to the speed, scalability, and
responsiveness of the system. For example, system should be
able to handle a certain number of concurrent users.
• Security: This is related to the protection of the system and its
data from unauthorized access.
• Usability: This requirements related to the ease of use and
understandability of the system for the end-users.
• Reliability: This requirements related to the system’s ability to
function correctly and consistently under normal and
abnormal conditions.
• Maintainability: This requirements related to the ease of
maintaining the system, including testing, debugging, and
modifying the system.
• Portability: This requirements related to the ability of the
system to be easily transferred to different hardware or
software environments.
• Compliance: This requirements related to adherence to laws,
regulations, industry standards, or company policies.
Types of Non-functional requirements
Types of Non-functional requirements
• Usability: This requirements related to the ease of use and
understandability of the system for the end-users.
• Performance: This is related to the speed, scalability, and
responsiveness of the system. For example, system should be
able to handle a certain number of concurrent users.
• Reliability: This requirements related to the system’s ability to
function correctly and consistently under normal and
abnormal conditions.
• Portability: This requirements related to the ability of the
system to be easily transferred to different hardware or
software environments.
• Compliance: This requirements related to adherence to laws,
regulations, industry standards, or company policies.
 Differences between
Functional Requirements Non Functional Requirements

A non-functional requirement defines the quality attribute of a

A functional requirement defines a system or its component.
software system.

It places constraints on “How should the software system fulfill

It specifies “What should the software system do?”
the functional requirements?”

Non-functional requirement is specified by technical peoples e.g.

Functional requirement is specified by User.
Architect, Technical leaders and software developers.

It is mandatory. It is not mandatory.

 Advantages of Non-functional
Requirement
• They ensure the reliability, availability, performance, and
scalability of the software system
• They help in constructing the security policy of the software
system.
• They ensure good user experience, ease of operating the
software, and minimize the cost factor.
• Increased user satisfaction: By ensuring that the system has
good usability and meets the user’s performance and security
expectations, engineers can increase user satisfaction with
the system.
 Requirements gathering
• Requirements gathering is the process of understanding what
you are trying to build and why you are building it.
• Requirements gathering is often regarded as a part of
developing software applications
• however, be applied to any product or project
 Three Main Sub-processes of
Requirements Gathering
• Requirements elicitation is the process of asking for
and collecting top-level requirements from all relevant stakeholders
• Requirements documentation organizes the input from
the requirements elicitation process into whatever format
is appropriate for your organization. This formatting may include:
– User stories
– Functional decompositions
– Feature descriptions
• Requirements confirmation is the process of making sure all
stakeholders and team members have a common
understanding of what you’re trying to build.
 Requirements Analysis
• Requirement analysis is significant and essential activity after
elicitation.
• We analyze, refine, and scrutinize the gathered requirements
to make consistent and unambiguous requirements.
• This activity reviews all requirements and may provide a
graphical view of the entire system.
• After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
• Here, we may also use the interaction with the customer to
clarify points of confusion and to understand which
requirements are more important than others.
 Software Requirement Specification
• The final output is the software requirements specification
document (SRS)
• An analyst typically will analyze some parts of the problem
and then write the requirements for that part.
• All the information for specification comes from analysis
• Essentially, what passes from requirements analysis activity to
the specification activity is the knowledge acquired about the
system.
• The SRS is written based on the knowledge acquired during
analysis.
 Characteristics of an SRS
• A good SRS is
• 1. Correct
• 2. Complete
• 3. Unambiguous
• 4. Verifiable
• 5. Consistent
• 6. Ranked for importance or stability
• 7. Modifiable
• 8. Traceable
• An SRS is correct if every requirement included in the SRS
• An SRS is complete if everything the software is supposed to
do and the responses of the software are specified in the SRS.
• An SRS is unambiguous if and only if every requirement stated
has one and only one interpretation.
• An SRS is verifiable if and only if every stated requirement is
verifiable.
• An SRS is consistent if there is no requirement that conflicts
with another
• Generally, all the requirements for software are not of equal
importance. Some are critical, others are important but not
critical, and there are some which are desirable but not very
important.
• An SRS is modifiable if its structure and style are such that any
necessary change can be made easily while preserving
completeness and consistency.
• An SRS is traceable if the origin of each of its requirements is
clear and if it facilitates the referencing of each requirement
in future development
 Components of an SRS
• 1. Functionality
• 2. Performance
• 3. Design constraints imposed on an implementation
• 4. External interfaces
• Functional requirements specify which outputs should be
produced from the given inputs. They describe the
relationship between the input and output of the system.
• Performance Requirements of an SRS specifies the
performance constraints on the software system.
• Design Constraints are a number of factors in the client's
environment that may restrict the choices of a designer.
• External Interface Requirements should specify the interface
with other software the system will use or that will use the
system.
 Structure of a Requirements
Document
• All the requirements for the system have to be included in a
document that is clear and concise.
• There can be many ways to structure a requirements
document.
• One of the main ideas of standardizing the structure of the
document is that with an available standard, each SRS will fit a
certain pattern, which will make it easier for others to
understand
• The general structure of an SRS is shown
 Agile development
• Agile means able to move quickly and easily.
• Able to think quickly, solve problems, and have new ideas
• Quick, smart, and clever.
• Agile project management is an iterative approach to
managing software development projects that focuses on
continuous releases and incorporating customer feedback
with every iteration.
• It's most frequently used by software development teams, but
its principles can be applied in almost any industry.
• It's not easy to get an entire company to change its culture
overnight and adopt an “Agile mindset”
 Agile Process
• Is driven by customer descriptions of what is required
(scenarios)
• Develops software iteratively with a heavy emphasis on
construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
 Agile Principles
• Early and Continuous Delivery of Valuable Software
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software
• Embrace Change
Welcome changing requirements, even late in development
• Frequent Delivery
Deliver working software frequently
• Business and Developers Together
Business people and developers must work together daily
throughout the project.
 Agile Principles
• Motivated Individuals
Give them the environment and support they need, and trust
them to get the job done.
• Face-to-Face Conversation
The most efficient and effective method of information to and
within a development is face-to-face conversation.
• Working Software
Working software is the primary measure of progress.
• Sustainable Development
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
 Agile Principles
• Technical Excellence
Continuous attention to technical excellence and good design
enhances agility.
• Simplicity
maximizing the amount of work not done—is essential
• Self-Organizing Teams
The best architectures, requirements, and designs emerge from
self-organizing teams.
• Regular Reflection and Adjustment
At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
 Agility and cost of change
• Reduced cost of change
An agile process reduces the agility and cost of change because
software is released in increments and change can be better
controlled
• Increased Agility
Effective (rapid and adaptive) response to change
 Increased collaboration
Effective communication among all stakeholders
• Improved Quality
Organizing a team so that it is in control of the work performed
Agility and cost of change
 Human factors
• Competency: The staff should be competent, ie, must have
the specific skills necessary software and know the
technologies involved in a particular project or initiative.
• Collaboration: the good old ability to work in a team is also
essential. People should cooperate among themselves and
with all involved
• Focus: all team members must be focused on one common
goal: to deliver the customer an increment of working
software in agreed time.
• Decision making: the development team should have the
freedom to control their own destiny.
 Human factors

• Trust and respect: the team must be consistent and must

demonstrate trust and respect needed to make a strong team.
• Self organization: is the team itself should organize to
perform the work. You need to look at every moment what
else can be improved in the process so that it fits more to the
environment.
 Extreme Programming (XP)
• Extreme Programming (XP) is an Agile
development method that uses pairs of
programmers who work off a detailed
specification.
• It provides values and principles to guide the
team behavior.
• The team is expected to self-organize.
• There is a high level of customer involvement.
 Extreme Programming
• eXtreme Programming (XP) is a lightweight, efficient, low-risk,
flexible, predictable, scientific, and fun way to develop a
software.
• “Extreme Programming” improves a software project in five
essential ways :
1) Communication,
2) Simplicity,
3) Feedback,
4) Respect and
5) Courage.
 XP values
• Communication plays a major role in the success of a project.
Problems with projects often arise due to lack of communication.
Some of the common problems are −
– A developer may not tell someone else about a critical change in the
design.
– A developer may not ask the customer the right questions
• Simplicity Extreme Programming believes in ‘it is better to do a
simple thing today and pay a little more tomorrow to change it’
than ‘to do a more complicated thing today that may never be used
anyway’
• Feedback - Every iteration commitment is taken seriously by
delivering a working software. The software is delivered early to the
customer and a feedback is taken so that necessary changes can be
made if needed.
 XP values
• Courage - Extreme Programming provides courage to the
developers in the following way −
– To focus on only what is required
– To communicate and accept feedback
– To tell the truth about progress and estimates
– To refactor the code
– To adapt to changes whenever they happen
– To throw the code away (prototypes)
• Respect - is a deep value. In Extreme Programming,
– Everyone respects each other as a valued team member.
– Everyone contributes value such as enthusiasm.
– Developers respect the expertise of the customers and vice versa.
XP Process
Extreme Programming Frame work activities
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.
The XP process comprises four framework activities:

3. Coding
• 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.
• Two people are assigned to create the code. 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