Module 1

Introduction to Software
Engineering, Software Process
Models
Software Engineering
Computer Software - What is it?
• Software is a set of instructions, data or programs used to operate
computers and execute specific tasks.
• It is the product that software professionals build and then support
over the long term.
• It encompasses programs that execute within a computer of any size
and architecture, content that is presented as the computer programs
execute, and documents in both hardcopy and virtual forms that
encompass all forms of electronic media.
Computer Software- Who does it?
• Software engineers build and support it, and virtually everyone in the
industrialized world uses it either directly or indirectly.
Computer Software – Why is it important?
• Because it affects nearly every aspect of our lives and has become
pervasive in our commerce, our culture, and our everyday activities.
Computer Software – What are the steps?
• You build computer software like you build any successful product, by
applying an agile, adaptable process that leads to a high-quality result
that meets the needs of the people who will use the product.
• You apply a software engineering approach.
Computer Software – What is the work
product?
• From the point of view of a software engineer, the work product is the
programs, content (data), and documents that are computer software.
• But from the user’s viewpoint, the work product is the resultant
information that somehow makes the user’s world better.
Software Types
• System Software
• Application Software
• Engineering/Scientific Software
• Embedded Software
• Product line Software
• Web Applications
• Artificial Intelligence Software
Software Engineering
• Software engineering is an engineering discipline that is concerned
with all aspects of software production.
• Software engineering, basically, comprises a process, a set of methods,
and a collection of tools for managing and developing a software
system.
• Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance
of software that is, the application of engineering to software. (IEEE)
Software Engineering Principles
• Modularity: Breaking down the software into smaller, independent,
and reusable components or modules. This makes the software easier
to understand, test, and maintain.
• 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.
• 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.
• Don’t Repeat Yourself: Avoiding duplication of code and data in the
software. This makes the software more maintainable and less error-
prone.
• Keep It Simple: Keeping the software design and implementation as
simple as possible. This makes the software more understandable,
testable, and maintainable.
• 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.
• 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,
etc.
• 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.
• By following these principles, software engineers can develop software that is
more reliable, maintainable, and extensible.
• It’s also important to note that these principles are not mutually exclusive, and
often work together to improve the overall quality of the software.
Software Process – What is it?
• When you work to build a product or system, it’s important to go
through a series of predictable steps- a road map that helps you create
a timely, high-quality result.
• The road map that you follow is called a software process.
Software Process – Who does it?
• Software engineers and their managers adapt the process to their needs
and then follow it.
• The people who have requested the software have a role to play in the
process of defining, building, and testing it.
Software Process – Why is it important?
• Because it provides stability, control and organization to an activity
that can, if left uncontrolled, become quite chaotic.
• A modern software engineering approach must be “agile”.
• It must demand only those activities, controls and documentation that
are appropriate for the project team and the product that is to be
produced.
Software Process – What are the steps?
• At a detailed level, the process that you adapt depends on the software
that you are building.
• One process might be appropriate for creating software for an aircraft
avionic system, while an entirely different process would be indicated
for the creation of website.
Software Process– What is the work product?
• From software engineer’s point of view, the work products are the
programs, documents and data that are produced as a consequence of
the activities and tasks defined by the process.
Software Engineering layers
Software Engineering four layers
1. A quality focus: It defines the continuous process improvement
principles of software. It provides integrity that means providing
security to the software so that data can be accessed by only an
authorized person, no outsider can access the data. It also focuses on
maintainability and usability.
2. Process: It is the foundation or base layer of software engineering. It
is key that binds all the layers together which enables the development
of software before the deadline or on time. Process defines a framework
that must be established for the effective delivery of software
engineering technology. The software process covers all the activities,
actions, and tasks required to be carried out for software development.
Software Engineering four layers
3. Method: During the process of software development the answers to
all “how-to-do” questions are given by method. It has the information of
all the tasks which includes communication, requirement analysis,
design modeling, program construction, testing, and support.
4. Tools: Software engineering tools provide a self-operating system
for processes and methods. Tools are integrated which means
information created by one tool can be used by another.
Process
• Communication: It is the first and foremost thing for the
development of software. Communication is necessary to know the
actual demand of the client.
• Planning: It basically means drawing a map for reduced the
complication of development.
• Modeling: In this process, a model is created according to the client
for better understanding.
• Construction: It includes the coding and testing of the problem.
• Deployment:- It includes the delivery of software to the client for
evaluation and feedback.
Software Engineering layers- Process
Software Myths in Software Engineering
Software Myths in Software Engineering

• Software Myths are beliefs that do not have any pure evidence.
• Software myths may lead to many misunderstandings, unrealistic
expectations, and poor decision-making in software development
projects.
Some common software myths
• The Myth of Perfect Software: Assuming that it's possible to create bug-
free software. In Reality, software is inherently complex, and it's
challenging to eliminate all defects.
• The Myth of Short Development Times: Assuming that software can be
developed quickly without proper planning, design, and testing. In Reality,
rushing the development process can lead to better-quality software and
missed deadlines.
• The Myth of Linear Progression: The Development of software is in a
linear, predictable manner. In Reality, development is often iterative and can
involve unexpected setbacks and changes.
• The Myth of No Maintenance: It is thought that software development is
complete once the initial version is released. But in reality, the software
requires maintenance and updates to remain functional and secure.
• The Myth of User-Developer Mind Reading: It is assumed that
developers can only understand user needs with clear and ongoing
communication with users. But in reality, user feedback and collaboration
are essential for correct software development.
• The Myth of Cost Predictability: It is thought that the cost of the software
can be easily predicted, but in reality, many factors can influence project
costs, and estimates are often subject to change. There are many hidden
costs available.
• The Myth of Endless Features: It is believed that adding more features to
software will make it better. But in reality, adding more features to the
software can make it complex and harder to use and maintain. It may often
lead to a worse user experience.
• The Myth of No Testing Needed: It is assumed that there is no need to test
the software if the coder is skilled or the code looks good. But in reality,
thorough testing is essential to catch hidden defects and ensure software
reliability.
• The Myth of One-Size-Fits-All Methodologies: Thinking that a single
software development methodology is suitable for all projects. But in
reality, different methodologies should be used on the specific project.
• The Myth of "We'll Fix It Later": It is assumed that a bug can be fixed at
a later stage. But in reality, as the code gets longer and bigger, it takes a lot
of work to find and fix the bug. These issues can lead to increased costs and
project delays.
• The Myth of All Developers Are Interchangeable: It is believed that any
developer can replace another without any impact. But in reality, each
developer has unique skills and knowledge that can significantly affect the
project. Each one has a different method to code, find, and fix the bugs.
• The Myth of No User Training Required: It is assumed that users will
understand and use new software without any training. But in reality, users
need training and documentation to use the new software because the
different methods used by different developers can be unique.
• More Developers Equal Faster Development: It is believed that if there
are large no of coders, then the software development would take less time,
and the quality of the software would be of high quality. But in reality,
larger teams can lead to communication overhead and may only sometimes
result in faster development.
• Perfect Software Is Possible: The Idea of creating completely bug-
free software is a myth. In Reality, software development is complex,
and it's challenging to eliminate all defects.
• Zero-Risk Software: It is assumed that it's possible to develop
software with absolutely no risks. But in reality, all software projects
involve some level of risk, and risk management is a critical part of
software development.
Disadvantages of Software Myths

• Unrealistic Expectations: Software myths can create disappointment

and frustration among the stakeholders and developers. Sometimes,
the fake myth may lead to the no use of the software when it is
completely safe.
• Project Delays: Software myths will lead to more delays in the
completion of the projects and also increase the completion time of the
projects.
• Poor Quality Software: Myths such as "we can fix it later" or "we
don't need extensive testing" can lead to poor software quality.
Neglecting testing and quality assurance can result in buggy and
unreliable software.
• Scope Creep: Myths like "fixed requirements" can lead to scope creep
as stakeholders may change their requirements or expectations
throughout the project. This can result in a never-ending development
cycle.
• Ineffective Communication: Believing in myths can affect good
communication within development teams and between teams and
clients. Clear and open communication is crucial for project success,
and myths can lead to misunderstandings and misalignment.
• Wasted Resources: The Idea of getting "the perfect software" can
result in the allocation of unnecessary resources, both in terms of time
and money, which could be better spent elsewhere.
• Customer Dissatisfaction: Unrealistic promises made based on myths can
lead to customer dissatisfaction. When software doesn't meet exaggerated
expectations, clients may be disappointed and dissatisfied.
• Reduced Productivity: Myths can lead to reduced productivity, as team
members may spend time on unnecessary tasks or follow counterproductive
processes based on these myths.
• Increased Risk of Project Failure: The reliance on myths can significantly
increase the risk of project failure. Failure to address these myths can lead
to project cancellations, loss of investments, and negative impacts on an
organization's reputation.
• Decreased Competitiveness: Belief in myths can make an organization less
competitive in the market. It can hinder an organization's ability to innovate
and adapt.
Types of Software Myths

• Productivity Myths: More Developers can increase productivity and

will give a better software product.
• Quality Myths: The idea is to create fully bug-free software or to
create a software bug-free from the start of the software development.
Software bugs can be fixed at a later stage.
• Methodology Myths: A single software development method can be
used for all the software development, and software development
progresses linearly.
• Maintenance Myths:
• "No Maintenance required": Thinking that software development is
complete once the initial version is released, with no further updates or
maintenance needed.
• "Old Software Is Obsolete": The belief that older software is always inferior
to new software.
• Estimation Myths:
• "Cost Predictability": Thinking that the cost of a software project can be
accurately predicted from the outset.
• "Fixed Schedule": Believing that a project can adhere to a rigid schedule
without adjustments.
• Risk Myths: “Zero Risk Software": Assuming that it's possible to
develop software with absolutely no risks.
How to Avoid Software Myths

• Stay Informed: Keep up to date with the latest trends, practices, and
developments in the field of software engineering. Attend conferences,
read industry publications, and participate in online communities to
stay informed.
• Continuous Learning: Invest in ongoing education and professional
development. Software engineering is an evolving field, and staying
current is essential.
• Data-Driven Decision-Making: Make decisions based on data,
evidence, and real-world experiences rather than relying on anecdotal
evidence or common misconceptions.
• Testing and Validation: Don't rely solely on assumptions. Test your
software, gather data, and validate your ideas to confirm their
accuracy.
• Educate Team Members: Ensure that everyone on your development
team is aware of common software myths and is committed to
avoiding them. Knowledge sharing and education can help dispel
misconceptions.
• Risk Assessment: When dealing with software development
decisions, conduct risk assessments to identify potential pitfalls and
myths that might affect the project.
Process Models – What is it?
• The goal of a software process model is to provide guidance for
controlling and coordinating the tasks to achieve the end product and
objectives as effectively as possible.
• A software process model is an abstraction of the software
development process. The models specify the stages and order of a
process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are
performed.
Process Models – Who does it?
• Software engineers and their managers adapt a prescriptive process
model to their needs and then follow it.
• The people who have requested the software have a role to play as the
process model is followed.
Process Models – Why is it important?
• It provides stability, control and organization to an activity that can, if
left uncontrolled, become quite chaotic.
• Every process model must be adapted so that it is used effectively for a
specific software project.
Process Models – What are the steps?
• The process guides a software team through a set of framework
activities that are organized into a process flow that may be linear,
incremental, or evolutionary.
• The terminology and details of each process model differ, but the
generic framework activities remain reasonably consistent.
Process Models – What is the work
product?
• From software engineer’s point of view, the work products are the
programs, documents and data that are produced as a consequence of
the activities and tasks defined by the process.
Types of software process models

• Waterfall model
• V model
• Incremental Model
• Iterative model
• RAD model
• Spiral model
• Agile model
Generic Process Model
• Generic Process Model is a definitive description of processes.
• Generic Processes are designed to run outside a normal component or
on an application processor.
• These processes are not specific to any particular component, can be
used in any number of applications.
How does the Generic process model
work?
1. Communication: This is the first step in the software development
process which starts with the communication between the customer and
the developer.
2. Planning: This step consists of a complete estimation of the project,
scheduling for development of the project, and tracking.
3. Modeling: This step consists of complete requirement analysis and
project design like algorithm, flowchart, etc.
4. Construction: This step consists of code generation and its testing.
Coding will implement the design details using appropriate
programming languages.
5. Deployment: This step consists of delivering the final product to the
customer and take feedback. If there are any suggestions or addition of
other capabilities, then this change is required for improvement in
software quality.
Advantages and Disadvantages
• Testing activities like planning of test cases, test designing will be
done way before coding, which saves a lot of time
• Based on Waterfall Model, it lacks flexibility, and the delivery of
products is relatively fast.
• It has badly structured systems, and have higher failure chances that
user needs will not meet their expectations
• It is useful when there are long-life complex applications being built.
• It is not cost-effective and is static
• In the Evolutionary Process model, Incremental developments are
possible and new developments are reflected in the products.
• It has poor structure and has a high risk of failure in delivering the
product
• In RAD, it supports future development and maintenance, users can
reuse the system, and had a low risk of failure with reduced cost.
• Here, requirements are not always served and is not suitable for all
types of application development.
• In V model, it is similar to the waterfall model. It is designed in such a
manner that checks are automatically made by ensuring that
requirements are met.
• In Agile Model, requirements are delivered in a rapid manner with less
risk and software reliability
The Waterfall Model
1. Requirements analysis and specification phase:
• The aim of this phase is to understand the exact requirements of the
customer and to document them properly.
• Both the customer and the software developer work together so as to
document all the functions, performance, and interfacing requirement of the
software.
• It describes the "what" of the system to be produced and not "how.“
• In this phase, a large document called Software Requirement
Specification (SRS) document is created which contained a detailed
description of what the system will do in the common language.
2. Design Phase:
• This phase aims to transform the requirements gathered in the SRS
into a suitable form which permits further coding in a programming
language.
• It defines the overall software architecture together with high level and
detailed design.
• All this work is documented as a Software Design Document (SDD).
3. Implementation and unit testing:
• During this phase, design is implemented.
• If the SDD is complete, the implementation or coding phase proceeds
smoothly, because all the information needed by software developers
is contained in the SDD.
• During testing, the code is thoroughly examined and modified. Small
modules are tested in isolation initially. After that these modules are
tested by writing some overhead code to check the interaction between
these modules and the flow of intermediate output.
4. Integration and System Testing:
• This phase is highly crucial as the quality of the end product is
determined by the effectiveness of the testing carried out.
• The better output will lead to satisfied customers, lower maintenance
costs, and accurate results.
• Unit testing determines the efficiency of individual modules.
• However, in this phase, the modules are tested for their interactions
with each other and with the system.
5. Operation and maintenance phase:
• Maintenance is the task performed by every user once the software has
been delivered to the customer, installed, and operational.
When to use SDLC Waterfall Model?

• When the requirements are constant and not changed regularly.

• A project is short.
• The situation is calm.
• Where the tools and technology used is consistent and is not changing.
• When resources are well prepared and are available to use.
Advantages of Waterfall model

• This model is simple to implement also the number of resources that

are required for it is minimal.
• The requirements are simple and explicitly declared; they remain
unchanged during the entire project development.
• The start and end points for each phase is fixed, which makes it easy
to cover progress.
• The release date for the complete product, as well as its final cost, can
be determined before development.
• It gives easy to control and clarity for the customer due to a strict
reporting system.
Disadvantages of Waterfall model

• In this model, the risk factor is higher, so this model is not suitable for
more significant and complex projects.
• This model cannot accept the changes in requirements during
development.
• It becomes tough to go back to the phase. For example, if the
application has now shifted to the coding phase, and there is a change
in requirement, It becomes tough to go back and change it.
• Since the testing done at a later stage, it does not allow identifying the
challenges and risks in the earlier phase, so the risk reduction strategy
is difficult to prepare.
V Model
• V-Model also referred to as the Verification and Validation Model.
• In this, each phase of SDLC must complete before the next phase
starts.
• It follows a sequential design process same as the waterfall model.
• Testing of the device is planned in parallel with a corresponding stage
of development.
• Verification: It involves a static analysis method (review) done
without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.
• Validation: It involves dynamic analysis method (functional, non-
functional), testing is done by executing code. Validation is the process
to classify the software after the completion of the development
process to determine whether the software meets the customer
expectations and requirements.
• So V-Model contains Verification phases on one side of the Validation
phases on the other side. Verification and Validation process is joined
by coding phase in V-shape. Thus it is known as V-Model.
Verification Phase
• Business requirement analysis: This is the first step where product
requirements understood from the customer's side. This phase contains
detailed communication to understand customer's expectations and exact
requirements.
• System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements
document.
• Architecture Design: The baseline in selecting the architecture is that it
should understand all which typically consists of the list of modules, brief
functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. The
integration testing model is carried out in a particular phase.
• Module Design: In the module design phase, the system breaks down
into small modules. The detailed design of the modules is specified,
which is known as Low-Level Design
• Coding Phase: After designing, the coding phase is started. Based on
the requirements, a suitable programming language is decided. There
are some guidelines and standards for coding. Before checking in the
repository, the final build is optimized for better performance, and the
code goes through many code reviews to check the performance.
Validation Phase
• Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed
during the module design phase. These UTPs are executed to eliminate
errors at code level or unit level. A unit is the smallest entity which can
independently exist, e.g., a program module. Unit testing verifies that
the smallest entity can function correctly when isolated from the rest
of the codes/ units.
• Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and
tested independently can coexist and communicate among themselves.
• System Testing: System Tests Plans are developed during System
Design Phase. Unlike Unit and Integration Test Plans, System Tests
Plans are composed by the client?s business team. System Test ensures
that expectations from an application developer are met.
• Acceptance Testing: Acceptance testing is related to the business
requirement analysis part. It includes testing the software product in
user atmosphere. Acceptance tests reveal the compatibility problems
with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like
load and performance defects within the real user atmosphere.
When to use V-Model?

• When the requirement is well defined and not ambiguous.

• The V-shaped model should be used for small to medium-sized
projects where requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical
resources are available with essential technical expertise.
Advantage of V-Model

• Easy to Understand.
• Testing Methods like planning, test designing happens well before
coding.
• This saves a lot of time. Hence a higher chance of success over the
waterfall model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.
Disadvantage of V-Model:

• Very rigid and least flexible.

• Not a good for a complex project.
• Software is developed during the implementation stage, so no early
prototypes of the software are produced.
• If any changes happen in the midway, then the test documents along
with the required documents, has to be updated.
Incremental Process (RAD)
• Rapid Application Development (RAD) model is an incremental
software process model that focuses on short development cycle time.
• This model is a “high-speed” model which adapts many steps from
waterfall model in which rapid development is achieved by using
component based construction approach.
• 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.
Phases of RAD Model
• Business modeling
• Data modeling
• Process modeling
The RAD Model
RAD phases
1. Communication- It works to understand the business problem and the
information characteristics that the software must accommodate.
2. Planning- It is essential because multiple software teams work in
parallel on different system functions.
3. Modeling- It encompasses three major phases and establishes design
representations that serve as the basis for RAD’s construction activity.
• business modeling
• data modeling
• process modeling
4. Construction- It emphasizes the use of preexisting software
components and the application of automatic code generation.
5. Deployment- It establishes a basis for subsequent iterations, if
required.
Business Modeling
• The information flow among business functions is defined by
answering questions like what information drives the business process,
what information is generated, who generates it, where does the
information go, who process it and so on.
Data Modeling
• The information collected from business modeling is refined into a set
of data objects (entities) that are needed to support the business.
• The attributes (character of each entity) are identified and the relation
between these data objects (entities) is defined.
Process Modeling
• The data object 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.
When to use the RAD Model?

• Well-understood Requirements: When project requirements are stable and transparent,

RAD is appropriate.
• Time-sensitive Projects: Suitable for projects that need to be developed and delivered
quickly due to tight deadlines.
• Small to Medium-Sized Projects: Better suited for smaller initiatives requiring a
controllable number of team members.
• High User Involvement: Fits where ongoing input and interaction from users are
essential.
• Innovation and Creativity: Helpful for tasks requiring creative inquiry and innovation.
• Prototyping: It is necessary when developing and improving prototypes is a key
component of the development process.
• Low technological Complexity: Suitable for tasks using comparatively straightforward
technological specifications.
Advantages of RAD Model
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD Model
• The use of powerful and efficient tools requires highly skilled professionals.
• The absence of reusable components can lead to the failure of the project.
• The team leader must work closely with the developers and customers to
close the project on time.
• The systems which cannot be modularized suitably cannot use this model.
• Customer involvement is required throughout the life cycle.
• It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the project.
• Not every application can be used with RAD.
Applications of RAD
• This model should be used for a system with known requirements and
requiring a short development time.
• It is also suitable for projects where requirements can be modularized and
reusable components are also available for development.
• The model can also be used when already existing system components can
be used in developing a new system with minimum changes.
• This model can only be used if the teams consist of domain experts. This is
because relevant knowledge and the ability to use powerful techniques are a
necessity.
• The model should be chosen when the budget permits the use of automated
tools and techniques required.
Drawbacks of RAD
• It requires multiple teams or a large number of people to work on
scalable projects.
• This model requires heavily committed developers and customers. If
commitment is lacking then RAD projects will fail.
• The projects using the RAD model require heavy resources.
• If there is no appropriate modularization then RAD projects fail.
Performance can be a problem for such projects.
• The projects using the RAD model find it difficult to adopt new
technologies.
Evolutionary Process Model
• The evolutionary model is based on the concept of making an initial product and then
evolving the software product over time with iterative and incremental approaches with
proper feedback.
• In this type of model, the product will go through several iterations and come up when the
final product is built through multiple iterations.
• The development is carried out simultaneously with the feedback during the development.
• This model has a number of advantages such as customer involvement, taking feedback
from the customer during development, and building the exact product that the user
wants.
• Because of the multiple iterations, the chances of errors get reduced and the reliability and
efficiency will increase.
Evolutionary Model
Evolutionary Model
• The evolutionary model is also known as successive versions or incremental
models.
• The main aim of this evolutionary model is to deliver the products in total
processes over time.
• It also combines the iterative and collective model of the software
development life cycle (SDLC).
• Based on the evolutionary model, we can divide the development model
into many modules to help the developer build and transfer incrementally.
• On the other hand, we can also develop the skeleton of the initial product.
Also, it refines the project to increase levels of capability by adding new
functionalities in successive versions.
Characteristics of Evolutionary Model
• We can develop the evolutionary model with the help of an iterative
waterfall model of development.
• There are three types of evolutionary models. These are the Iterative
model, Incremental model and Spiral model.
• Many primary needs and architectural planning must be done to
implement the evolutionary model.
• When the new product version is released, it includes the new
functionality and some changes in the existing product, which are also
released with the latest version.
Characteristics of Evolutionary Model
• This model also permits the developer to change the requirement, and
the developer can divide the process into different manageable work
modules.
• The development team also have to respond to customer feedback
throughout the development process by frequently altering the
product, strategy, or process.
Prototyping Model
• It is the set of general objects that helps to create the software.
• We can not identify the input and output of requirement details.
• We can develop the program quickly with the help of this model.
• We have some different phases of using this prototyping model
Prototyping Model
Prototyping Model
• Communication- In this phase, the client and the developer should
have a meeting, and in that meeting, they discuss the main objective of
creating the project.
• Quick design- When we have the requirements known to the
developer, then the developer can implement the quick design. The
quick design includes implementing important aspects, such as the
input and output format of the software. The main focus of this project
is on the things visible to the user rather than the detailed plan. With
the help of this, we can also create the prototype of the project.
Prototyping Model
• Modelling quick design- In this phase, we can get a clear idea about
the software development because the software is now in the build
state. Also, it allows the developer to understand the project's basic
requirements.
• Construction of prototype-The customer evaluates the prototype of
the project.
• Deployment, delivery, feedback- If the client is unsatisfied with the
project, then the developer can recreate the project according to the
client's satisfaction. This process repeats until the client is fully
satisfied. After the client is happy, the project will be developed based
on the final prototype.
Advantages of the Prototyping Mode

• The prototype model does not need detailed input, output, processes,
adaptability of the operating system, or entire machine interaction.
• The user is fully active in the development process of this model.
• The development process is the best platform for users to understand
the project.
• We can easily detect the error with the help of this prototyping model.
• It also identifies the missing functionality very quickly.
• It also identifies the confusing or difficult functions.
Disadvantages of the Prototyping Model

• In this model, the involvement of the client is greater. So, it is not

always considered by the developer.
• The development time is longer, so it is a prolonged process.
• The developer has to perform so many changes according to the
client's demand. It disturbs the rhythm of the development process.
• When the user is confused with the prototype, then this prototype will
be thrown away.
Spiral Model
• This model is also known as the risk-driven process model.
• With the help of this spiral model, we can generate the software
project.
• During the risk analysis, if a risk is found, an alternate solution should
be suggested and implemented in the spiral model.
• We can also say that it combines the sequential or waterfall models
and the prototype models.
• All the required activities are done in one iteration. The output of the
large project is small.
Spiral Model
Spiral Model – Four Phases
A software project repeatedly passes through these phases in iterations called
Spirals.
1. Identification-
• This phase starts with gathering the business requirements in the baseline
spiral.
• In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in
this phase.
• This also includes understanding the system requirements by continuous
communication between the customer and the system analyst.
• At the end of the spiral the product is deployed in the identified market.
Spiral Model – Four Phases
2. Design-
• Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product
design and final design in the subsequent spirals.
3. Construct or Build-
• Construct phase refers to production of the actual software product at every
spiral.
• In the baseline spiral when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get
customer feedback.
• Then in the subsequent spirals with higher clarity on requirements and
design details a working model of the software called build is produced with
a version number. These builds are sent to customer for feedback.
Spiral Model- Four Phases
4. Evaluation and Risk-
• Analysis Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as
schedule slippage and cost overrun.
• After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
• Based on the customer evaluation, software development process
enters into the next iteration and subsequently follows the linear
approach to implement the feedback suggested by the customer. The
process of iterations along
Advantages of the Spiral Model

• The amount of risk should be reduced in this model.

• This model is best for large and critical projects.
• It provides the developer with solid approval and documentation
control.
• The software production time is less in this spiral model.
Disadvantages of Spiral Model

• We need a lot of financial support to develop a project.

• We should not use this model for a very small project.
The Concurrent process model
• The concurrent development model is called as concurrent model.
• The communication activity has completed in the first iteration and
exits in the awaiting changes state.
• The modeling activity completed its initial communication and then go
to the underdevelopment state.
• If the customer specifies the change in the requirement, then the
modeling activity moves from the under development state into the
awaiting change state.
• The concurrent process model activities moving from one state to
another state
Advantages of the concurrent model
• This model is applicable to all types of software development
processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent model
• It needs better communication between the team members. This may
not be achieved all the time.
• It requires to remember the status of the different activities.
Agile Software Development
• Agile software engineering combines a philosophy and a set of
development guidelines.
• The development stress delivery over analysis and design, and active
and continuous communication between developers and customer.
Who does it?
• Software engineers and other project stakeholders (managers,
customers, end-users) work together on an agile team, a team that is
self-organizing and in control of its own destiny.
• An agile team fosters communication and collaboration among all who
serve on it.
Why is it important?
• The modern business environment that spawns computer-based
systems and software products is fast-paced and ever-changing.
• Agile software engineering represents a reasonable alternative to
conventional software engineering for certain classes of software and
certain types of software projects.
• It has been demonstrated to deliver successful systems quickly.
What are the steps?
• Agile development might best be termed “software engineering lite”.
• The basic framework activities-customer communication, planning,
modeling, construction, delivery and evaluation-remain.
• But they morph into a minimal task set that pushes the project team
toward construction and delivery.
What is the work product?
• Customers and software engineers who have adopted the agile
philosophy have the same view- the only really important work
product is an operational “software increment” that is delivered to the
customer on the appropriate commitment date.
Agile Process
Agile Process
• Agile is a mindset and philosophy that guides the way teams work
together, while Agile methodologies are a set of practices that are used
to implement the Agile mindset.
• Understanding the distinction between the two is important for
organizations that want to adopt an Agile approach to software
development.
Agile Process
• Agility Principal
• Human Factors
Agility Principal
• 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.
Agility Principal
• 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.
Human Factors
• Competence- In an agile development “competence” encompasses
innate talent, specific software-related skills, and overall knowledge of
the process that the team has chosen to apply. Skill and knowledge of
process can and should be taught to all people who serve as agile team
members.
• Common focus- Although members of the agile team may perform
different tasks and bring different skills to the project, all should be
focused on one goal—to deliver a working software increment to the
customer within the time promised. To achieve this goal, the team will
also focus on continual adaptations (small and large) that will make
the process fit the needs of the team.
Human Factors
• Collaboration- Software engineering (regardless of process) is about
assessing, analyzing, and using information that is communicated to
the software team; creating information that will help all stakeholders
understand the work of the team; and building information (computer
software and relevant databases) that provides business value for the
customer. To accomplish these tasks, team members must collaborate
with one another and all other stakeholders.
• Decision making ability- Any good software team (including agile
teams) must be allowed the freedom to control its own destiny. This
implies that the team is given autonomy—decision-making authority
for both technical and project issues.
Human Factors
• Fuzzy problem solving ability-Software managers must recognize
that the agile team will continually have to deal with ambiguity and
will continually be buffeted by change. In some cases, the team must
accept the fact that the problem they are solving today may not be the
problem that needs to be solved tomorrow.
• Mutual trust and respect- The agile team must become what is called
“jelled” team . A jelled team exhibits the trust and respect that are
necessary to make them “so strongly knit that the whole is greater than
the sum of the parts.
Human Factors
• Self-organization- In the context of agile development, self-
organization implies three things:
1. The agile team organizes itself for the work to be done.
2. The team organizes the process to best accommodate its local
environment.
3. The team organizes the work schedule to best achieve delivery of the
software increment.
Agile Methodology
• Organizations must adopt the Agile mindset and culture, and then
choose the Agile methodology that aligns with their goals and culture.
• The Agile methodology is a way to manage a project by breaking it up
into several phases.
• It involves constant collaboration with stakeholders and continuous
improvement at every stage.
• Once the work begins, teams cycle through a process of planning,
executing, and evaluating.
Life cycle of Agile Methodology
Life cycle of Agile Methodology

1. Requirement Gathering-
• In this stage, the project team identifies and documents the needs and expectations
of various stakeholders, including clients, users, and subject matter experts.
• It involves defining the project’s scope, objectives, and requirements.
• Establishing a budget and schedule.
• Creating a project plan and allocating resources.
2. Design-
• Developing a high-level system architecture.
• Creating detailed specifications, which include data structures, algorithms, and
interfaces.
• Planning for the software’s user interface.
3. Development (Coding)-
• Writing the actual code for the software. Conducting unit testing to verify
the functionality of individual components.
4. Testing-
• This phase involves several types of testing:
• Integration Testing: Ensuring that different components work together.
• System Testing: Testing the entire system as a whole.
• User Acceptance Testing: Confirming that the software meets user
requirements.
• Performance Testing: Assessing the system’s speed, scalability, and
stability.
5. Deployment-
• Deploying the software to a production environment.
• Put the software into the real world where people can use it.
• Make sure it works smoothly in the real world.
• Providing training and support for end-users.
6. Review (Maintenance)-
• Addressing and resolving any issues that may arise after deployment.
• Releasing updates and patches to enhance the software and address
problems.
Types of Agile methodologies

• Scrum
• Lean software development
• Extreme programming
• Crystal
• Kanban
• Dynamic systems development method
• Feature-driven development
Extreme Programming (XP)
• 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.
XP values
1. Communication-
• Building software development process needs communication between
the developer and the customer.
• Communication is important for requirement gathering and discussing
the concept.
2. Simplicity-
• The simple design is easy to implement in code.
3. Feedback-
• Feedback guides the development process in the right direction.
4. Courage-
• In every development process there will always be a pressure
situation.
• The courage or the discipline to deal with it surely makes the task
easy.
5. Respect-
• Agile process should inculcate the habit to respect all team members,
other stake holders and customer.
The XP Process – Four Frameworks
1. XP Planning-
• Begins with the listening, leads to creation of “user stories” that
describes required output, features, and functionality. Customer
assigns a value(i.e., a priority) to each story.
• Agile team assesses each story and assigns a cost (development weeks.
If more than 3 weeks, customer asked to split into smaller stories)
• Working together, stories are grouped for a deliverable increment next
release.
• A commitment (stories to be included, delivery date and other project
matters) is made. Three ways:
 Either all stories will be implemented in a few weeks,
 High priority stories first, or
 The riskiest stories will be implemented first.
• After the first increment “project velocity”, namely number of stories
implemented during the first release is used to help define subsequent
delivery dates for other increments. Customers can add stories, delete
existing stories, change values of an existing story, split stories as
development work proceeds.
2. XP Design ( occurs both before and after coding as refactoring is
encouraged)-
• Follows the KIS principle (keep it simple) Nothing more nothing less than
the story.
• Encourage the use of CRC (class-responsibility-collaborator) cards in an
object-oriented context. The only design work product of XP. They identify
and organize the classes that are relevant to the current software increment.
For difficult design problems, suggests the creation of “spike solutions”—a
design prototype for that portion is implemented and evaluated.
• Encourages “refactoring”—an iterative refinement of the internal program
design. Does not alter the external behavior yet improve the internal
structure. Minimize chances of bugs. More efficient, easy to read.
3. XP Coding-
• Recommends the construction of a unit test for a story before coding
commences. So implementer can focus on what must be implemented
to pass the test.
• Encourages “pair programming”. Two people work together at one
workstation. Real time problem solving, real time review for quality
assurance. Take slightly different roles.
4. XP Testing-
• All unit tests are executed daily and ideally should be automated.
Regression tests are conducted to test current and previous
components.
• “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality.
Industrial XP
Industrial Extreme Programming(IXP) is an organic evolution of XP.
IXP incorporates new practices , they are-
• Reading assessment
• Project community
• Project chartering
• Test-driven management
• Retrospectives
• Continuous learning
• SSD:story-driven development
• DDD:domain-driven design
• Pairing
• Iterative usability
The XP-Debate
SCRUM
What?
• It is a type of Agile software engineering.
• Iterative and incremental framework for software engineering.
• Process with predefined set of practices and roles.

Why?
• To maximize teams ability to deliver quickly and respond to evolving and changing requirements.
• To develop functionality in smaller and stable increments have potentially deliverable product in
shorter periods of time.
•
How Scrum works?
• Form a Scrum Team-
• Scrum Master(Maintain the process)
• Product Owner(represents the stakeholders and the business)
• Team(cross functional group-developer, Quality assurance,
Architecture, Business Analysis)
• Team size(5-9 members)
• If need to scale( add more scrum teams)
Scrum Master
• Leads the team.
• Facilitates and co-ordinates to Everything.
• Helps removing obstacles.
• Safeguards the process.
• Acts as the “sheepdog” for the team.
• Can be anyone with necessary skills.
Product Owner
• Business oriented, defines product backlogs.
• Priorities the features.
• Owns vision of the product.
• Owns release dates/ cost.
• Open to negotiations with the team.
• Can be product/project/marketing manager.
Teams
• Developers, Quality assurance, Architects, Analysts, Tech writers,
Subject matter experts etc.
• Actually does the work.
• Responsible for the estimates and planning the work/risks.
• Do all the needful to deliver on schedule.
Basic Team Building Principles
• Trust
• Commitment
• Reliable
• Honesty
• Professionalism
• Effective Communication
• Self Organized and Self Led
SPRINT
• Basic unit of development in scrum.
• Time boxed(restricted to a specific duration) effort of a constant
length.
• Team decides the duration.
• Typically 1 to 4 weeks.
• Before sprint : planning meetings.
• After sprint : review/demo & retrospective.
Product Backlog
• Defined by product owner/team.
• Prioritized product owner.
• Revised and reprioritized before project starts and before each sprint.
Sprint Backlog
• Defined /Prioritized by Product Owner/Team.
• List of items to be done within the next sprint.
• Each feature is broken down into tasks.
• Each task is 4-16 hours of work.
Burn Down Chart
• Tracks the progress in labor or work units-done, total, left.
• In class, we use topics/slides covered.
Sprint Planning Meeting
• Held at the beginning of the sprint (every 7-28 days).
• Select what work is to be done.
• Prepare the sprint Backlog that details the time it will take to do that
work, with the entire team identify and communicate how much of the
work is likely to be done during the current sprint.
• Eight hours limit:-
( 1st four hours) Product Owner + Team: dialog for prioritizing the
product backlog.
(2nd four hours) Team only: hashing out a plan for the Sprint, resulting
in Sprint Backlog.
Sprint Review Meeting
• Held at the end of each Sprint cycle.
• Review the work that was completed and not completed.
• Present the completed work to the stake holders.
• Incomplete work cannot be demonstrated.
• Four hours time limit.
Sprint Retrospective
• Held at the end of each sprint cycle.
• All team members reflect on the past sprint.
• Two main questions are asked in the sprint retrospective.
• What went well during the sprint?
• What could be improved in the next sprint?
• Three hours limit.
Daily Scrum/Standup
• Held daily, same location and same time every day.
• The meeting starts precisely on time.
• All are welcome, but normally only the core roles speak.
• The meeting is time boxed to 15 minutes.
• What have done since yesterday?
• What are you planning to do today?
• Any impediments/stumbling blocks.
• Scrum Master facilitates resolution of impediments, although the resolution
should occur outside the Daily Scrum itself to keep it under it 15 minutes.
Definition of Done (DoD)
• What “Done” means should be defined BEFORE Sprint starts.
• Individual for each Sprint team.
• All sprint team members should agree.
• Cannot be changed once sprint starts.
• Should be concrete and measurable.
• Define deliverables for each Product Backlog item.
• “Sashimi”- a report that something is DONE.
Sprint Results
• If at the sprint Review Meeting the acceptance criteria of “Done” are
not met-the item(s) is NOT DONE and sprint failed.
• There are no “Partially Done” Sprints.
Abnormally Terminated Sprints
• The product owner can cancel a sprint if necessary with input from the
team, scrum master or management.
• Management may wish to cancel a sprint of external circumstanced
negate the value of the sprint goal.
• If a sprint is abnormally terminated, the next step is to conduct a new
Sprint Planning meeting, where the reason for the termination is
reviewed.
Inside the Sprint
• The document/testing done by delivery team.
• Daily scrums held to report progress/impediments.
• Product owner monitors the progress and backlog properties.
• Scrum master facilitates everything.
• Days are busy.
Sprint Retrospective
• Did we make the Sprint.
• What went well?
• What went not so well?
• How to improve?
• What to do in the next sprint?
Why it can fail?
• Lack of commitment and reliability.
• Incorrect time/work estimates.
• Ineffective use of the retrospective.
• Inability to get everyone on planning and daily meetings.
• Bad Scrum Masters or Product owner.
• Lack of team authority and decision making skills.
• Team’s inability to learn.
• State of denial.
Limitations
• Project Scope- Scrum is challenging for large complex projects with
geographically distributed teams and different time zones.
• Cannot be done in large teams and huge features (everything needs to
be broken down).
• Requires good Scrum Masters and Product owners.
• Some organizations require audit trial on everything done (military,
medical) need paperwork trial and proof.
Introduction to Agile Tools
• An agile tool is a software application or platform that enables teams
to manage and track their Agile projects more efficiently.
• Agile methodologies are increasingly becoming popular in project
management due to their flexibility and ability to adapt to changing
project requirements.
Introduction to Agile Tools
Jira: An Agile Tool

• Jira is the most widely used Agile tool which is mainly used for issue
tracking, bug tracking and agile project management.
• It is also used by a large number of clients and the users all over the
world.
• Jira tool is also used for backlog tracking and release planning , CI/CD
and developer tools integrations.
Features
• Jira offers multiple features such as project tracking, reporting,
tracking and collaborating with the team.
• Jira also provides tracking and planning tools which mainly helps the
teams to manage the dependencies, feature the requirements and
stakeholders one by one.
• Jira mainly offers issue prioritization and also allows the software
testers to point out the major issues in the software development and
products.
Kanbanize: An Agile Tool

• Kanbanize is a web based tool used in agile tool which increases

productivity and accelerates with the team output.
• Kanbanize is used to manage the workflow by using the Kanban
method, the customizable Kanban board can sync with any team
requirement.
Features
• Kanbanize offers flexible and customizable Kanban board where the
teams can customize to the fit and their needs.
• Kanbanize integrates with GitHub, Jira, Slack and with other multiple
tools.
• With the help of Kanbanize, teams can personalize the workflow for
multiple projects and teams.