SOFTWARE ENGINEERING

Syllabus
Unit Details
1. Introduction: What is software engineering? Software Development Life
Cycle, Requirements Analysis, Software Design, Coding, Testing,
Maintenance etc.
Software Requirements: Functional and Non-functional requirements,
User Requirements, System Requirements, Interface Specification,
Documentation of the software requirements.
Software Processes:
Process and Project, Component Software Processes.
Software Development Process Models.
Waterfall Model.
Prototyping.
Iterative Development.
Rational Unified Process.
The RAD Model
Time boxing Model.

Agile software development: Agile methods, Plan-driven and agile

development, Extreme programming, Agile project management, Scaling
agile methods.
 Syllabus
Unit Details
4. Verification and Validation: Planning Verification and Validation, Software
Inspections, Automated Static Analysis, Verification and Formal Methods.
Software Testing: System Testing, Component Testing, Test Case Design, Test
Automation.
Software Measurement: Size-Oriented Metrics, Function-Oriented Metrics,
Extended Function Point Metrics
Software Cost Estimation: Software Productivity, Estimation Techniques,
Algorithmic Cost Modelling, Project Duration and Staffing .

5. Process Improvement: Process and product quality, Process Classification,

Process Measurement, Process Analysis and Modeling, Process Change, The
CMMI Process Improvement Framework.
Service Oriented Software Engineering: Services as reusable components,
Service Engineering, Software Development with Services.
Software reuse: The reuse landscape, Application frameworks, Software
product lines, COTS product reuse.
Distributed software engineering: Distributed systems issues, Client–server
computing, Architectural patterns for distributed systems, Software as a service.
 Syllabus
Unit Details
2. Socio-technical system: Essential characteristics of socio technical systems,
Emergent System Properties, Systems Engineering, Components of system such
as organization, people and computers, Dealing Legacy Systems.
Critical system: Types of critical system, A simple safety critical system,
Dependability of a system, Availability and Reliability, Safety and Security of
Software systems.
Requirements Engineering Processes: Feasibility study, Requirement solicitation
and analysis, Requirements Validations, Requirements Management.
System Models: Models and its types, Context Models, Behavioral Models, Data
Models, Object Models, Structured Methods.
3. Architectural Design: Architectural Design Decisions, System Organization,
Modular Decomposition Styles, Control Styles, Reference Architectures.
User Interface Design: Need of UI design, Design issues, The UI design Process,
User analysis, User Interface Prototyping, Interface Evaluation.
Project Management
Software Project Management, Management activities, Project Planning,
Project Scheduling, Risk Management.
Quality Management: Process and Product Quality, Quality assurance and
Standards, Quality Planning, Quality Control, Software Measurement and
Metrics.
References:
Software Engineering, edition,
Ian Somerville

Software Engineering
Pankaj Jalote Narosa Publication
Introduction Software Engineering:

Software engineering is essential for the functioning of government,

society and national and international businesses and institutions. We
can’t run the modern world without software. National infrastructures
and utilities are controlled by computer-based systems and most
electrical products include a computer and controlling software.
Industrial manufacturing and distribution is completely computerized,
as is the financial system. Entertainment, including the music industry,
computergames and film and television, is software-intensive.More
than75% of the world’s population have a software-controlled mobile
phone, almost all of these will be Internet-enabled. Software systems
are abstract and intangible. They are not constrained by the properties
of materials, governed by physical laws or by manufacturing processes.
This simplifies software engineering, as there are no natural limits to
the potential of software. However, because of the lack of physical
constraints, software systems can quickly become extremely complex,
difficult to understandand expensive to change. There are many
different types of software system, from simple embedded systems to
complex, worldwide information systems.
Introduction Software Engineering:

What is software?
Computer programs and associated documentation. Software
products may be developed for a particular customer or may be
developed for a general market.
What is software engineering?
Software engineering is an engineering discipline that is
concerned with all aspects of software production from initial
conception to operation and maintenance.
What is the difference between software engineering and
system engineering?
System engineering is concerned with all aspects of computer-
based systems development including hardware, software and
process engineering. Software engineering is part of this more
general process.
 Software Engineering:
Software engineering is an engineering discipline that is
concerned with all aspects of software production from the early
stages of system specification through to maintaining the system
after it has gone into use. In this definition, there are two key
phrases:1.Engineering discipline Engineers make things work.
They apply theories, methods and tools where these are
appropriate. However, they use them selectively and always try
to discover solutions to problems even when there are no
applicable theories and methods. Engineers also recognize that
they must work to organizational and financial constraints so they
look for solutions within these constraints.
2.All aspects of software production Software engineering is not
just concerned with the technical processes of software
development includes activities such as software project
management and the development of tools, methods and
theories to support software development.
Software Engineering Definition
The seminal definition:
[Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines.
The IEEE definition:
Software Engineering: (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study of
approaches as in (1).
 Essential attributes of good software
Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to meet the
changing needs of customers. This is a critical attribute because software change
is an inevitable requirement of a changing business environment.

Dependability and Software dependability includes a range of characteristics including reliability,

security security and safety. Dependable software should not cause physical or economic
damage in the event of system failure. Malicious users should not be able to
access or damage the system.

Efficiency Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time,
memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is designed. This
means that it must be understandable, usable and compatible with other systems
that they use.
SDLC
• Software Development Life Cycle (SDLC)
• A software life cycle model (also termed process model) is a
pictorial and diagrammatic representation of the software life
cycle. A life cycle model represents all the methods required
to make a software product transit through its life cycle
stages. It also captures the structure in which these methods
are to be undertaken.
• In other words, a life cycle model maps the various activities
performed on a software product from its inception to
retirement. Different life cycle models may plan the necessary
development activities to phases in different ways. Thus, no
element which life cycle model is followed, the essential
activities are contained in all life cycle models though the
action may be carried out in distinct orders in different life
cycle models. During any life cycle stage, more than one
activity may also be carried out
What is SDLC?
SDLC is a process followed for a software project, within a
software organization. It consists of a detailed plan describing
how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the
quality of software and the overall development process.
SDLC framework includes the following steps:
 :
Stage1: Planning and requirement analysis
Requirement Analysis is the most important and necessary stage in SDLC.
The senior members of the team perform it with inputs from all the
stakeholders and domain experts in the industry.
Planning for the quality assurance requirements and identifications of the risks
associated with the projects is also done at this stage.
Business analyst and Project organizer set up a meeting with the client to
gather all the data like what the customer wants to build, who will be the end
user, what is the objective of the product. Before creating a product, a core
understanding or knowledge of the product is very necessary.
For Example, A client wants to have an application which concerns money
transactions. In this method, the requirement has to be precise like what kind
of operations will be done, how it will be done, in which currency it will be
done, etc.
Once the required function is done, an analysis is complete with auditing the
feasibility of the growth of a product. In case of any ambiguity, a signal is set
up for further discussion.
Once the requirement is understood, the SRS (Software Requirement
Specification) document is created. The developers should thoroughly follow
this document and also should be reviewed by the customer for future
reference.
Stage2: Defining Requirements
Once the requirement analysis is done, the next stage is to certainly represent
and document the software requirements and get them accepted from the
project stakeholders.
This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and
developed during the project life cycle.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the requirements
specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.
This DDS is reviewed by all the important stakeholders and based on various
parameters as risk assessment, product robustness, design modularity, budget
and time constraints, the best design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product
along with its communication and data flow representation with the external
and third party modules (if any). The internal design of all the modules of the
proposed architecture should be clearly defined with the minutest of the
details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the
product is built. The programming code is generated as per DDS
during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without
much hassle.
Developers must follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters,
debuggers, etc. are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java and PHP
are used for coding. The programming language is chosen with
respect to the type of software being developed.
:

Stage5: Testing
After the code is generated, it is tested against the requirements to
make sure that the products are solving the needs addressed and
gathered during the requirements stage.
During this stage, unit testing, integration testing, system testing,
acceptance testing are done.
Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it
is deployed.
Then based on the assessment, the software may be released as it is
or with suggested enhancement in the object segment.
After the software is deployed, then its maintenance begins.
Stage7: Maintenance
Once when the client starts using the developed systems, then the real
issues come up and requirements to be solved from time to time.
This procedure where the care is taken for the developed product is
known as maintenance.
:

SDLC Models
There are various software development life cycle models defined and
designed which are followed during the software development
process. These models are also referred as Software Development
Process Models". Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed
in the industry −
Waterfall Model
Iterative Model
Spiral Model
V-Model
Big Bang Model
Other related methodologies are Agile Model, RAD Model, Rapid
Application Development and Prototyping Models.
Waterfall Model:
The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process
begins only if the previous phase is complete. In this waterfall model, the
phases do not overlap.
Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach, the
whole process of software development is divided into separate phases. In
this Waterfall model, typically, the outcome of one phase acts as the input for
the next phase sequentially.
Waterfall Model:
 : sequential phases in Waterfall model are −
The
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.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap.
Iterative Model - Design
Iterative process starts with a simple implementation of a subset of the
software requirements and iteratively enhances the evolving versions until
the full system is implemented. At each iteration, design modifications are
made and new functional capabilities are added. The basic idea behind this
method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time.
Iterative and Incremental development is a combination of both iterative
design or iterative method and incremental build model for development.
"During software development, more than one iteration of the software
development cycle may be in progress at the same time." This process may be
described as an "evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various
builds. During each iteration, the development module goes through the
requirements, design, implementation and testing phases. Each subsequent
release of the module adds function to the previous release. The process
continues till the complete system is ready as per the requirement.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes through these phases
in iterations called Spirals.
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 phase 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.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final design in
the subsequent spirals.
Construct or Build
The 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.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the 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.
V-Model
The V-model is an SDLC model where execution of processes happens in a sequential manner
in a V-shape. It is also known as Verification and Validation model.
The V-Model is an extension of the waterfall model and is based on the association of a
testing phase for each corresponding development stage. This means that for every single
phase in the development cycle, there is a directly associated testing phase. This is a highly-
disciplined model and the next phase starts only after completion of the previous phase.
RAD (Rapid Application Development)
This model is based on prototyping and iterative development with no specific planning
involved. The process of writing the software itself involves the planning required for
developing the product.
Rapid application development is a software development methodology that uses minimal
planning in favor of rapid prototyping. A prototype is a working model that is functionally
equivalent to a component of the product.
In the RAD model, the functional modules are developed in parallel as prototypes and are
integrated to make the complete product for faster product delivery. Since there is no detailed
preplanning, it makes it easier to incorporate the changes within the development process.
RAD projects follow iterative and incremental model and have small teams comprising of
developers, domain experts, customer representatives and other IT resources working
progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that the prototypes
developed are reusable.
RAD model distributes the analysis, design, build and test phases into a series of short, iterative
development cycles.
Following are the various phases of the RAD Model −
Business Modelling
The business model for the product under development is designed in terms of flow of
information and the distribution of information between various business channels. A complete
business analysis is performed to find the vital information for business, how it can be obtained,
how and when is the information processed and what are the factors driving successful flow of
information.
Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form
sets of data objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects are established and defined in detail in
relevance to the business model.
Process Modelling
The data object sets defined in the Data Modelling phase are converted to establish the
business information flow needed to achieve specific business objectives as per the business
model. The process model for any changes or enhancements to the data object sets is defined
in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object are
given.
Application Generation
The actual system is built and coding is done by using automation tools to convert process and
data models into actual prototypes.
Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are independently
tested during every iteration. However, the data flow and the interfaces between all the
components need to be thoroughly tested with complete test coverage.
Prototyping:
Prototype is a working model of software with some limited functionality. The prototype
does not always hold the exact logic used in the actual software application and is an
extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out
before implementation. It also helps understand the requirements which are user
specific and may not have been considered by the developer during product design.
Following is a stepwise approaches:
Basic Requirement Identification
This step involves understanding the very basics product requirements especially in
terms of user interface.
Developing the initial Prototype
The initial Prototype is developed in this stage, where the very basic requirements are
showcased and user interfaces are provided. These features may not exactly work in the
same manner internally in the actual software developed.
Review of the Prototype
The prototype developed is then presented to the customer and the other important
stakeholders in the project. The feedback is collected in an organized manner and used
for further enhancements in the product under development.
Time Boxing Model in Software Engineering:
• In time boxing model, development is done iteratively as in the iterative
enhancement model. However, in time boxing model, each iteration is done in a
timebox of fixed duration. The functionality to be developed is adjusted to fit the
duration of the timebox. Moreover, each timebox is divided into a sequence of fixed
stages where each stage performs a clearly defined task (analysis, implementation,
and deploy) that can be done independently. This model also requires that the time
duration of each stage is approximately equal so that pipelining concept is employed
to have the reduction in development time and product releases.
• There is a dedicated team for each stage so that the work can be done in pipelining.
Thus, stages should be chosen in such a way that each stage perform some logical
unit of work that becomes the input for next stage.
Table Advantages and Disadvantages of the Time boxing Model
Advantages Disadvantages
1.Speeds up the development process 1.Project management becomes more
and shortens the delivery time complex.
2.Well suited to develop projects with a 2.Not suited to projects in which entire
number of features in short time period. development work cannot be divided into
multiple iterations of almost, equal
duration.
Rational Unified Process (RUP) is a software development process for object-oriented
models. It is also known as the Unified Process Model. It is created by Rational
corporation and is designed and documented using UML (Unified Modeling Language).
This process is included in IBM Rational Method Composer (RMC) product. IBM
(International Business Machine Corporation) allows us to customize, design, and
personalize the unified process.
Phases of RUP :
• Inception –
– Communication and planning are main.
– Identifies Scope of the project using use-case model allowing managers to estimate costs and time required.
– Customers requirements are identified and then it becomes easy to make a plan of the project.
– Project plan, Project goal, risks, use-case model, Project description, are made.
– Project is checked against the milestone criteria and if it couldn’t pass these criteria then project can be either
cancelled or redesigned.
• Elaboration –
– Planning and modeling are main.
– Detailed evaluation, development plan is carried out and diminish the risks.
– Revise or redefine use-case model (approx. 80%), business case, risks.
– Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can be
cancelled or redesigned.
– Executable architecture baseline.
• Construction –
– Project is developed and completed.
– System or source code is created and then testing is done.
– Coding takes place.
• Transition –
– Final project is released to public.
– Transit the project from development into production.
– Update project documentation.
– Beta testing is conducted.
– Defects are removed from project based on feedback from public.
• Production –
– Final phase of the model.
– Project is maintained and updated accordingly.
Functional vs Non Functional Requirements:
• Requirements analysis is very critical process that enables the success of a system or
software project to be assessed. Requirements are generally split into two
types: Functional and Non-functional requirements.
• Functional Requirements: These are the requirements that the end user specifically
demands as basic facilities that the system should offer. All these functionalities need to
be necessarily incorporated into the system as a part of the contract. These are
represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are basically the requirements stated by the
user which one can see directly in the final product, unlike the non-functional
requirements.
• Non-functional requirements: These are basically the quality constraints that the system
must satisfy according to the project contract. The priority or extent to which these
factors are implemented varies from one project to other. They are also called non-
behavioral requirements.
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
 Functional Requirements Non Functional Requirements

A functional requirement defines a system or its A non-functional requirement defines the quality
component. attribute of a software system.

It places constraints on “How should the software

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

Non-functional requirement is specified by technical

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

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of the software. Helps you to verify the performance of the software.
User Requirement:
The User Requirements Specification describes the business needs for what users
require from the system. User Requirements Specifications are written early in the
validation process, typically before the system is created. They are written by the
system owner and end-users, with input from Quality Assurance. Requirements
outlined in the URS are usually tested in the Performance Qualification or User
Acceptance Testing. User Requirements Specifications are not intended to be a
technical document; readers with only a general knowledge of the system should be
able to understand the requirements outlined in the URS.
The URS is generally a planning document, created when a business is planning on
acquiring a system and is trying to determine specific needs. When a system has already
been created or acquired, or for less complex systems, the user requirement
specification can be combined with the functional requirement document.
The URS should include:
• Introduction – including the scope of the system, key objectives for the project, and
the applicable regulatory concerns
• Program Requirements – the functions and workflow that the system must be able
to perform
• Data Requirements – the type of information that a system must be able to process
• Life Cycle Requirements – including how the system will be maintain and users
trained
 Software requirement Documentation:
In the entire software development cycle that follows, requirement gathering, analyzing
and software requirements documentation have a major role to play.
These requirements are known to be the key identifier of the perception of the business
stakeholder for the system, its integration, behavior, and its environment. Further, the
entire business operations are known to run accordingly.
Importance:
• There are many different elements that makeup SRS in software engineering to be an
integral part. Its ability to communicate the actual operation and objective of the
software to the stakeholders is one of the most essential among all.
• All the elements of the product are specifically mentioned before the developers
write a single line of coding. The narratives, visuals including tables and graphs, and
specifications make it all very clear. Developing an SRS is equally important
irrespective of the fact that software is being developed in-house or there is the
involvement of any external development resources. Some major objectives of SRS
are as follows:
• An accurate explanation of the work that needs to be actually accomplished.
• Clear details and easy management for software developers and designers.
• Utilizing case scenarios for testing teams.
• Bringing up customer requirements into features.
• Updatable source of truth in relation to software development.
• Fetches input from various stakeholders.
Best Practices for Software Requirement Documentation:
Since this is going to be an essential task in a software development process, you need to be
sure that you use the best methods and tactics and in order to prepare the required
documentation.
1. Tangible
You should be sure that the requirements are measurable and concrete. There should be no use
of abstract terms like excellent, good, efficient etc. Rather you should try to include more
measurable and quantitative terms in the same.
2. Atomic
It should be ensured that the requirements are specific and presentable at the basic level.
Breaking down the high-level requirements as per the different atomic levels would easily bring
up appropriate clarity in the SRS document.
3. Valuable/ Important
The client would always prove to be the best judge for their business requirements. Therefore,
once the documentation is prepared to get it reviewed by the client should be taken into
consideration. This is something really important and generally the best idea.
4. Complete and Accurate
Rather than being open-ended and ambiguous, the requirements should be well defined and
complete. The details should be accurate enough to reflect the business perspectives and needs
of the client very clearly.
5.Modifiable
Perfect requirement documentation is the one whose organizational structure is well defined
and is easily adaptable. It should avoid any redundancies and should be modifiable as per
requirements.
6.Traceable
The required documentation should be prepared such that it can pace way to the origin of
development and also back to the present documents prepared by the SRS.
Computer Aided Software Engineering(CASE)
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
There are number of CASE tools available to simplify various stages of Software Development
Life Cycle such as Analysis tools, Design tools, Project management tools, Database
Management tools, Documentation tools.
Components of CASE Tools

Fig: Computer Aided Software Engineering(CASE)

Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information
regarding management is stored. Central repository also serves as data dictionary.
Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from Requirement
gathering to Testing and documentation.
Agile Methodology
What is Agile Methodology?
AGILE methodology is a practice that promotes continuous iteration of development
and testing throughout the software development lifecycle of the project. In the Agile
model, both development and testing activities are concurrent, unlike the Waterfall
model.
What is Agile Software Development?
The Agile software development methodology is one of the simplest and effective
processes to turn a vision for a business need into software solutions. Agile is a term
used to describe software development approaches that employ continual planning,
learning, improvement, team collaboration, evolutionary development, and early
delivery. It encourages flexible responses to change.
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
What are the Different Types of Agile Methodologies?
Scrum
Scrum is similar to Kanban in many ways. For instance, Scrum typically uses a Scrum Board,
which is similar to a Kanban Board, and also groups tasks into columns based on progress.
Unlike Kanban, Scrum focuses on breaking a project down into sprints, and only planning and
managing one sprint at a time. Scrum also has unique project roles, including a scrum master
and Product Owner.
Extreme Programming (XP)
Extreme Programming (XP) was designed for Agile software development projects. It focuses
on continuous development and customer delivery and uses intervals or sprints similar to a
scrum methodology. However, XP also has 12 supporting processes that are specific to the
world of software development:
• Planning Game
• Small Releases
• Customer Acceptance Tests
• Simple Design
• Pair Programming
• Test-Driven Development
• Refactoring
• Continuous Integration
• Collective Code Ownership
• Coding Standards
• Metaphor
• Sustainable Pace
What is Extreme Programming?
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a software.
extreme Programming (XP) was conceived and developed to address the specific needs of software development by
small teams in the face of vague and changing requirements.
Extreme Programming is one of the Agile software development methodologies. It provides values and principles to
guide the team behavior. The team is expected to self-organize. Extreme Programming provides specific core practices
where −
Each practice is simple and self-complete.
Combination of practices produces more complex and emergent behavior.
Extreme Programming Advantages:
• Slipped schedules − and achievable development cycles ensure timely deliveries.
• Cancelled projects − Focus on continuous customer involvement ensures transparency with the customer and
immediate resolution of any issues.
• Costs incurred in changes − Extensive and ongoing testing makes sure the changes do not break the existing
functionality. A running working system always ensures sufficient time for accommodating changes such that the
current operations are not affected.
• Production and post-delivery defects: Emphasis is on − the unit tests to detect and fix the defects early.
• Misunderstanding the business and/or domain − Making the customer a part of the team ensures constant
communication and clarifications.

Values of extreme programming

• Communication. Everyone on a team works jointly at every stage of the project.
• Simplicity. Developers strive to write simple code bringing more value to a product, as it saves time and effort.
• Feedback. Team members deliver software frequently, get feedback about it, and improve a product according to
the new requirements.
• Respect. Every person assigned to a project contributes to a common goal.
• Courage. Programmers objectively evaluate their own results without making excuses and are always ready to
respond to changes.
These values represent a specific mindset of motivated team players who do their best on the way to achieving a common
goal.
Principles of extreme programming
• Rapid feedback. Team members understand the given feedback and react to it right
away.
• Assumed simplicity. Developers need to focus on the job that is important at the
moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself)
principles.
• Incremental changes. Small changes made to a product step by step work better
than big ones made at once.
• Embracing change. If a client thinks a product needs to be changed, programmers
should support this decision and plan how to implement new requirements.
• Quality work. A team that works well, makes a valuable product and feels proud of
it.
Dynamic Systems Development Method (DSDM)
The Dynamic Systems Development Method (DSDM) cropped up out of the need to
provide a common industry framework for rapid software delivery. Part of DSDM is the
mandate that rework is to be expected, and any development changes that occur must
be reversible. Like Scrum, XP, and FDD, DSDM uses sprints. This framework is based on
eight key principles:
• Focus on the business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally from firm foundations
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control
Crystal
Crystal is actually a family of Agile methodologies, including Crystal Clear, Crystal Yellow,
Crystal Orange, Crystal Red, and more. Each methodology has its own unique framework.
Which one you choose is dependent on several project factors, such as your team size,
your project priorities, and project criticality. The belief is that different projects require
a slightly different set of policies, practices, and processes based on their unique
characteristics.
Key Differences Between Plan-driven and Agile Project Management Methodologies
The principles of agile:
• There are 12 key principles that still guide agile project management today.
• Customer satisfaction is always the highest priority and is achieved through rapid and continuous
delivery.
• Changing environments are embraced at any stage of the process to provide the customer with a
competitive advantage.
• A product or service is delivered with higher frequency.
• Stakeholders and developers collaborate closely on a daily basis.
• All stakeholders and team members remain motivated for optimal project outcomes, while teams are
provided with all the necessary tools and support, and are trusted to accomplish project goals.
• Face-to-face meetings are deemed the most efficient and effective format for project success.
• A final working product is the ultimate measure of success.
• Sustainable development is accomplished through agile processes whereby development teams and
stakeholders are able to maintain a constant and ongoing pace.
• Agility is enhanced through a continuous focus on technical excellence and proper design.
• Simplicity is an essential element.
• Self-organizing teams are most likely to develop the best architectures and designs and to meet
requirements.
• Regular intervals are used by teams to improve efficiency through fine-tuning behaviors.

What is agile project management?

Agile project management is an iterative approach to managing software development projects that
focuses on continuous releases and incorporating customer feedback with every iteration.
Software teams that embrace agile project management methodologies increase their development
speed, expand collaboration, and foster the ability to better respond to market trends.
Scaling agile
Scaling agile means that there are hundreds of agile teams working in different business
units. There is no part of the business which is untouched by the agile approach. The
idea to deploy agile teams throughout the organization may sound challenging but the
fact of the matter is that various organizations are at this very moment going through
the agile transformation.
example of scaling agile:
Bosch
Bosch, a leading global supplier of technology and services with more than 400,000
associates and operations in 60-plus countries, is going through an agile transformation.
Bosch decided to stay relevant in a globalized economy by scaling agile.
The first step in scaling agile was to identify which business functions will continue with
the traditional approach. The new business functions were chosen to be run with agile
teams. This created a dual organization, one which is working on a traditional model and
another one which runs on agile approach.
Scrum is a framework for agile project management that uses fixed-length iterations of
work, called sprints. There are four ceremonies that bring structure to each sprint.
The four ceremonies of scrum