SE

MODULE I
Software is a program or set of programs containing instructions which provide desired functionality . And Engineering is the
processes of designing and building something that serves a particular purpose and find a cost effective solution to problems.
Software Engineering is a systematic approach to the design, development, operation, and maintenance of a software system.

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress in user requirements and the environment on
which the program is working.
o Huge Programming: It is simpler to manufacture a wall than to a house or building, similarly, as the measure of
programming become extensive engineering has to step to give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering ideas, it would be simpler to re-create
new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let down the cost of computer and
electronic hardware. But the cost of programming remains high if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature of programming hugely depends upon the environment in
which the client works. If the quality of the software is continually changing, new upgrades need to be done in the existing
one.
o Quality Management: Better procedure of software development provides a better and quality software product.
Importance of Software Engineering
1. Reduces complexity: Big software is always complicated and challenging to progress. Software engineering has a great
solution to reduce the complication of any project. Software engineering divides big problems into various small issues. And
then start solving each small issue one by one. All these small problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hardwork and software engineers are highly paid experts. A lot of
manpower is required to develop software with a large number of codes. But in software engineering, programmers project
everything and decrease all those things that are not needed. In turn, the cost for software productions becomes less as
compared to any software that does not use software engineering method.
3. To decrease time: Anything that is not made according to the project always wastes time. And if you are making great
software, then you may need to run many codes to get the definitive running code. This is a very time-consuming procedure,
and if it is not well handled, then this can take a lot of time. So if you are making your software according to the software
engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and they need lots of patience, planning, and
management. And to invest six and seven months of any company, it requires heaps of planning, direction, testing, and
maintenance. No one can say that he has given four months of a company to the task, and the project is still in its first stage.
Because the company has provided many resources to the plan and it should be completed. So to handle a big project
without any problem, the company has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered the software, then it should work for at least its
given time or subscription. And if any bugs come in the software, the company is responsible for solving all these bugs.
Because in software engineering, testing and maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the standards. Software standards are the big target of
companies to make it more effective. So Software becomes more effective in the act with the help of software engineering.

SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) is a systematic process for building software that ensures the quality and
correctness of the software built. SDLC process aims to produce high-quality software that meets customer expectations. The
system development should be complete in the pre-defined time frame and cost. SDLC consists of a detailed plan which explains
how to plan, build, and maintain specific software. Every phase of the SDLC life cycle has its own process and deliverables that
feed into the next phase. SDLC stands for Software Development Lifecycle.
Why SDLC?
Here, are prime reasons why SDLC is important for developing a software system.
o It offers a basis for project planning, scheduling, and estimating
o Provides a framework for a standard set of activities and deliverables
o It is a mechanism for project tracking and control
o Increases visibility of project planning to all involved stakeholders of the development process
o Increased and enhance development speed
o Improved client relations
o Helps you to decrease project risk and project management plan overhead
SDLC Phases
The entire SDLC process divided into the following stages:

Phase 1: Requirement collection and analysis:

The requirement is the first stage in the SDLC process. It is conducted by the senior team members with inputs from all the
stakeholders and domain experts in the industry. Planning for the quality assurance requirements and recognization of the risks
involved is also done at this stage.
This stage gives a clearer picture of the scope of the entire project and the anticipated issues, opportunities, and directives which
triggered the project.
Requirements Gathering stage need teams to get detailed and precise requirements. This helps companies to finalize the
necessary timeline to finish the work of that system.
Phase 2: Feasibility study:
Once the requirement analysis phase is completed the next step is to define and document software needs. This process
conducted with the help of 'Software Requirement Specification' document also known as 'SRS' document. It includes everything
which should be designed and developed during the project life cycle.
There are mainly five types of feasibilities checks:
o Economic: Can we complete the project within the budget or not?
o Legal: Can we handle this project as cyber law and other regulatory framework/compliances.
o Operation feasibility: Can we create operations which is expected by the client?
o Technical: Need to check whether the current computer system can support the software
o Schedule: Decide that the project can be completed within the given schedule or not.
Phase 3: Design:
In this third phase, the system and software design documents are prepared as per the requirement specification document. This
helps define overall system architecture.
This design phase serves as input for the next phase of the model.
There are two kinds of design documents developed in this phase:
High-Level Design (HLD)
• Brief description and name of each module
• An outline about the functionality of every module
• Interface relationship and dependencies between modules
• Database tables identified along with their key elements
• Complete architecture diagrams along with technology details
Low-Level Design(LLD)
• Functional logic of the modules
• Database tables, which include type and size
• Complete detail of the interface
• Addresses all types of dependency issues
• Listing of error messages
• Complete input and outputs for every module
Phase 4: Coding:
Once the system design phase is over, the next phase is coding. In this phase, developers start build the entire system by writing
code using the chosen programming language. In the coding phase, tasks are divided into units or modules and assigned to the
various developers. It is the longest phase of the Software Development Life Cycle process.
In this phase, Developer needs to follow certain predefined coding guidelines. They also need to use programming tools like
compiler, interpreters, debugger to generate and implement the code.
Phase 5: Testing:
Once the software is complete, and it is deployed in the testing environment. The testing team starts testing the functionality of
the entire system. This is done to verify that the entire application works according to the customer requirement.
During this phase, QA and testing team may find some bugs/defects which they communicate to developers. The development
team fixes the bug and send back to QA for a re-test. This process continues until the software is bug-free, stable, and working
according to the business needs of that system.
Phase 6: Installation/Deployment:
Once the software testing phase is over and no bugs or errors left in the system then the final deployment process starts. Based on
the feedback given by the project manager, the final software is released and checked for deployment issues if any.
Phase 7: Maintenance:
Once the system is deployed, and customers start using the developed system, following 3 activities occur
o Bug fixing - bugs are reported because of some scenarios which are not tested at all
o Upgrade - Upgrading the application to the newer versions of the Software
o Enhancement - Adding some new features into the existing software
The main focus of this SDLC phase is to ensure that needs continue to be met and that the system continues to perform as per the
specification mentioned in the first phase.

Software Processes
The term software specifies to the set of computer programs, procedures and associated documents (Flowcharts, manuals, etc.)
that describe the program and how they are to be used.
A software process is the set of activities and associated outcome that produce a software product. Software engineers mostly
carry out these activities. These are four key process activities, which are common to all software processes. These activities are:
1. Software specifications: The functionality of the software and constraints on its operation must be defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.
These activities are complex activities in themselves, and they include subactivities such as requirements validation, architectural
design, and unit testing. Processes also include other activities, such as software configuration management and project planning
that support production activities
However, when describing processes, it is also important to describe who is involved, what is produced, and conditions that
influence the sequence of activities:
 1. Products or deliverables are the outcomes of a process activity. For example, the outcome of the activity of architectural
design may be a model of the software architecture.
2. Roles reflect the responsibilities of the people involved in the process. Examples of roles are project manager, configuration
manager, and programmer.
3. Pre- and postconditions are conditions that must hold before and after a process activity has been enacted or a product
produced. For example, before architectural design begins, a precondition may be that the consumer has approved all
requirements; after this activity is finished, a postcondition might be that the UML models describing the architecture have
been reviewed.

Adaptive vs. Predictive Planning

 Many factors can affect the chosen project development method of an organization or project team. When evaluating which
approach to take, consider whether the project is familiar territory with a predictable path, or a new frontier with uncertain
outcomes.
 Known projects can usually rely upon a predictive method of planning. Predictive planning provides a linear, specific
development plan structured around producing a pre-determined end result within a specific timeframe.
 Evolving projects that face changing conditions are best suited for adaptive planning. Adaptive planning involves breaking a
project into small components over an undetermined timeline to allow ultimate flexibility in directing the course of the
project.
 Whereas the outputs from predictive planning are expected and knowable, adaptive planning may yield surprising outcomes.
Due to the incremental nature of adaptive planning, the overall result of a project may differ substantially from the original
intent. The challenge associated with adaptive planning is to remain flexible and open to change, while not becoming
irresolute.
 The planning approach selected by an organization will lend itself to a specific project development methodology. Whereas
an organization with a predictive mindset might choose to utilize a “waterfall” approach, adaptive teams may choose “agile”
techniques.

Comparison between Adaptive model and Predictive model

Parameters Predictive Adaptive

Phases Overlapping and sequential Parallel, sequential and overlapping

High-level planning Yes Yes

High-level scope Yes Yes

Detailed Planning At the starting stage of the project. Only of iteration

It is used only when the product is It is used when the project is not understood
When to use understood appropriately. appropriately, rapidly changing environments.

Involvement of customer While changing the scope and in beginning Continuous

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.
 1. Requirements analysis and definition The system’s services, constraints, and goals are established by consultation with
system users. They are then defined in detail and serve as a system specification.
2. System and software design The systems design process allocates the requirements to either hardware or software
systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental
software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units.
Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing The individual program units or programs are integrated and tested as a complete system
to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.
5. Operation and maintenance Normally, this is the longest life-cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the
implementation of system units, and enhancing the system’s services as new requirements are discovered.
Waterfall Model - Application
Some situations where the use of Waterfall model is most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
Advantages of the Waterfall Method
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Disadvantages of Waterfall method
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high
with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or
challenges early.

Iterative Model
An iterative life cycle model does not start with a full specification of requirements. In this model, the development begins by
specifying and implementing just part of the software, which is then reviewed in order to identify further requirements. Moreover,
in iterative model, the iterative process starts with a simple implementation of a small set of the software requirements, which
iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed. Each release of
Iterative Model is developed in a specific and fixed time period, which is called iteration.
Furthermore, this iteration focuses on a certain set of requirements. Each cycle ends with a usable system i.e., a particular
iteration results in an executable release. Iterative Model allows accessing previous phases, in which the changes are made
accordingly. The final output of the product is revived at the end of the Software Development Life Cycle (SDLC). Typically
iterative development is used in conjunction with incremental development, in which a longer software development cycle is split
into smaller segments that are built upon each other.
 The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and check by an analyst
whether requirements will fulfil or not. Analyst checks that need will achieve within budget or not. After all of this, the
software team skips to the next phase.
2. Design: In the design phase, team design the software by the different diagrams like Data Flow diagram, activity diagram,
class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are written in the coding language and transformed into computer
programmes which are called Software.
4. Testing: After completing the coding phase, software testing starts using different test methods. There are many test
methods, but the most common are white box, black box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work environment.
6. Review: In this phase, after the product deployment, review phase is performed to check the behaviour and validity of the
developed product. And if there are any error found then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the working environment there may be some
bugs, some errors or new updates are required. Maintenance involves debugging and new addition options.
Iterative Model - Application
• Requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while working on the project.
• Resources with needed skill sets are not available and are planned to be used on contract basis for specific iterations.
• There are some high-risk features and goals which may change in the future.
Iterative Model - Pros and Cons
The advantages of the Iterative and Incremental SDLC Model are as follows −
• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
• Easier to manage risk - High risk part is done first.
• With every increment, operational product is delivered.
• Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission-critical projects.
• During the life cycle, software is produced early which facilitates customer evaluation and feedback.
The disadvantages of the Iterative and Incremental SDLC Model are as follows −
• More resources may be required.
• Although cost of change is lesser, but it is not very suitable for changing requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life
cycle.
• Defining increments may require definition of the complete system.
• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which is a risk.
• Highly skilled resources are required for risk analysis.
• Projects progress is highly dependent upon the risk analysis phase.

Incremental Model
Incremental Model is a process of software development where requirements divided into multiple standalone modules of the
software development cycle. In this model, each module goes through the requirements, design, implementation and testing
phases. Every subsequent release of the module adds function to the previous release. The process continues until the complete
system achieved.
 The various phases of incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the
requirements. And the system functional requirements are understood by the requirement analysis team. To develop the
software under the incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the
development method are finished with success. When software develops new practicality, the incremental model uses style
and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each existing function as well as additional
functionality. In the testing phase, the various methods are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development system. It involves the final coding
that design in the designing and development phase and tests the functionality in the testing phase. After completion of this
phase, the number of the product working is enhanced and upgraded up to the final system product
Types of Incremental model –
1. Staged Delivery Model – Construction of only one part of the project at a time.
2. Parallel Development Model – Different subsystems are developed at the same time. It can decrease the calendar time
needed for the development, i.e. TTM (Time to Market), if enough Resources are available.

Staged Parallel

Advantages Of Incremental Model

• Initial product delivery is faster.
• Lower initial delivery cost.
• Core product is developed first i.e main functionality is added in the first increment.
• After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be quickly
identified because few changes are made within any single iteration.
• It is generally easier to test and debug than other methods of software development because relatively smaller changes are
made during each iteration. This allows for more targeted and rigorous testing of each element within the overall product.
• With each release, a new feature is added to the product.
• Customer can respond to feature and review the product.
• Risk of changing requirement is reduced
• Workload is less.
Disadvantages Of Incremental Model
• Requires good analysis.
• Resulting cost may exceed the cost of the organization.
• Each phase of an iteration is rigid and do not overlap each other
• As additional functionality is added to the product, problems may arise related to system architecture which was not evident
in earlier prototypes.

RAD Model
Rapid application development came as a response to problems when applying the waterfall model to software development.
Software is uniquely different than other types of engineering because changes can be made almost immediately and even very
late in the development process.
RAD is based on four core concepts:
• Reusable code in an accessible repository
• Quick prototyping
• Constant client feedback
• Building usable software as quickly as possible
The client and developer work together to create an end product that functions exactly as the client wants.
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or
functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled
into a working prototype.
This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their
requirements.
Diagram of RAD-Model:

The phases in the rapid application development (RAD) model are:

Business modelling: The information flow is identified between various business functions.
Data modelling: Information gathered from business modelling is used to define data objects that are needed for the business.
Process modelling: Data objects defined in data modelling are converted to achieve the business information flow to achieve
some specific business objective. Description are identified and created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the actual system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the 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.
• RAD lets you break the project down into smaller, more manageable tasks.
• The task-oriented structure allows project managers to optimize their team’s efficiency by assigning tasks according to
members’ specialties and experience.
• Clients get a working product delivered in a shorter time frame.
• Regular communication and constant feedback between team members and stakeholders increases the efficiency of the
design and build process.
With a shorter planning phase and a focus on highly iterative design and construction, RAD teams are able to accomplish more in
less time without sacrificing client satisfaction.
A win-win for both project managers and clients.
Disadvantages of RAD model:
• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
When to use RAD model:
• RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.
• It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along
with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to
produce the system in a short span of time (2-3 months).
What About RAD Vs. Agile? Are They the Same Thing?
When you look at RAD vs. Agile, they are very similar concepts. Both are reactions to the standard waterfall method. The
differences between RAD and Agile are still emerging, as they aren’t usually seen as conflicting. However, there are some key
distinctions you can make.
Agile is a set of principles about software development. It focuses mostly on breaking down the project into features, each built in
a different sprint (usually focusing on the most difficult one first). In some ways, it still uses the basic waterfall concepts, but
creates dozens of iterations to get more feedback and testing done as each feature is finished.
RAD is more focused on prototypes. In RAD, the primary focus is to get something usable in front of the client as quickly as
possible to get feedback. In the RAD model, you may show the client something still in the development phase, whereas Agile will
usually wait until a specific feature is designed and built before showing it.
Also, RAD tends to be less focused on the UI/UX in favor of functionality, while Agile is more likely to consider the design as an
essential part of the product.
What is “Agility”?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
Yielding
• Rapid, incremental delivery of software
An Agile Process
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
Principles of Agility
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in
• development. Agile processes harness change for
• the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time
scale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the
job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity -the art of maximizing the amount of work not done -is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Methodologies
Dynamic System Development Methodology (DSDM)
It is an agile framework for software projects. It was used to fine-tune the traditional approaches. The most recent version of
DSDM is called DSDM Atern. The name Atern is a short for Arctic Tern - a seabird that can travel vast distances that represents
many features of the method which are natural ways of working such as prioritization and collaboration.
Scrum
It is the most popular agile framework, which concentrates particularly on how to manage tasks within a team-based
development environment. Scrum uses iterative and incremental development model, with shorter duration of iterations. Scrum
is relatively simple to implement and focuses on quick and frequent deliveries.
Extreme Programming (XP)
It is a type of agile software development. It advocates frequent releases in short development cycles, which is intended to
improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its
name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels.
(Extreme Programming is a software-development discipline that organizes people to produce higher-quality software more
productively.) XP addresses the analysis, development, and test phases with novel approaches that make a substantial difference
to the quality of the end-product.
Test-driven Development (TDD)
It is a software development process that relies on the repetition of a very short development cycle: first the developer writes an
automated test case that defines a desired improvement or a new function, then it produces the least amount of code to pass
that test, and finally brings the new code to acceptable standards.
Lean
It is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end-
customer to be wasteful, and thus a target for elimination. Working from the perspective of the customer who consumes a
product or service, the term value is defined as any action or process that a customer would be willing to pay for. Lean is centered
on preserving value with less work.
Kanban
It is a system to improve and keep up a high level of production. Kanban is one method through which Just-In-Time (JIT), the
strategy the organizations employ to control the inventory expenses, is achieved. Kanban became an effective tool in support of
running a production system as a whole, and it proved to be an excellent way for promoting improvement.
Conclusion
Over the last 10 years, there is an ever-increasing volume of success stories, where companies have dramatically improved the
success and performance of their IT development teams and projects with agile practices. This has caused agile to be widely
adopted across a variety of industries, including media and technology, large corporates, and even government.
Agile Framework helps teams to benefit from:
• Faster Time to Deliver/ Market
• Reduce Uncertainty and Risk
• Increase Return on Investment (ROI) by focusing on Customer Value
Among these different agile methodologies, Scrum has proved to be extremely successful worldwide over the last 20 years
 XP Model
Extreme Programming (XP) is an agile software development framework that
aims to produce higher quality software, and higher quality of life for the
development team. XP is the most specific of the agile frameworks regarding
appropriate engineering practices for software development.

Values and principles of Extreme Programming

XP has simple rules that are based on 5 values.
• 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 efforts. The purpose of
this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that
it is easier to maintain, support, and revise.
• 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.
XP principles derive from these values and reflect them in more concrete ways.
Most researchers denote 5 XP principles as:
• 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.
Some of the basic activities that are followed during software development by using XP model are given below:
• Coding: The concept of coding which is used in XP model is slightly different from traditional coding. Here, coding activity
includes drawing diagrams (modeling) that will be transformed into code, scripting a web-based system and choosing among
several alternative solutions.
• Testing: XP model gives high importance on testing and considers it be the primary factor to develop a fault-free software.
• Listening: The developers needs to carefully listen to the customers if they have to develop a good quality software.
Sometimes programmers may not have the depth knowledge of the system to be developed. So, it is desirable for the
programmers to understand properly the functionality of the system and they have to listen to the customers.
• Designing: Without a proper design, a system implementation becomes too complex and very difficult to understand the
solution, thus it makes maintenance expensive. A good design results elimination of complex dependencies within a system.
So, effective use of suitable design is emphasized.
• Feedback: One of the most important aspects of the XP model is to gain feedback to understand the exact customer needs.
Frequent contact with the customer makes the development effective.
• Simplicity: The main principle of the XP model is to develop a simple system that will work efficiently in present time, rather
than trying to build something that would take time and it may never be used. It focuses on some specific features that are
immediately needed, rather than engaging time and effort on speculations of future requirements.
Extreme Programming Practices
XP suggests using 12 practices while developing software. As XP is defined by values and principles, its practices also represent
them and can be clustered into four groups.

1. Test-Driven Development:Is it possible to write a clear code quickly? The answer is yes, according to XP practitioners. The
quality of software derives from short development cycles that, in turn, allow for receiving frequent feedback. And valuable
feedback comes from good testing. XP teams practice test-driven development technique (TTD) that entails writing an
automated unit test before the code itself. According to this approach, every piece of code must pass the test to be released.
So, software engineers thereby focus on writing code able to accomplish the needed function. That’s the way TDD allows
programmers to use immediate feedback to produce reliable software. You can learn more about improving software
testing in our dedicated article.
2. The Planning Game:This is a meeting that occurs at the beginning of an iteration cycle. The development team and the
customer get together to discuss and approve a product’s features. At the end of the planning game, developers plan for the
upcoming iteration and release, assigning tasks for each of them.
3. On-site Customer:According to XP, the end customer should fully participate in development. The customer should be
present all the time to answer team questions, set priorities, and resolve disputes, if necessary.
4. Pair Programming:This practice requires two programmers to work jointly on the same code. While the first developer
focuses on writing, the other one reviews code, suggests improvements, and fixes mistakes along the way. Such teamwork
results in high-quality software, faster knowledge sharing but takes 15 to 60 percent more time. In this regard, it’s more
reasonable trying pair programming for long-term projects.
5. Code Refactoring:To deliver business value with well-designed software in every short iteration, XP teams also use
refactoring. The goal of this technique is to continuously improve code. Refactoring is about removing redundancy,
eliminating unnecessary functions, increasing code coherency, and at the same time decoupling elements. Keep your code
clean and simple, so you can easily understand and modify it when required would be the advice of any XP team member.
6. Continuous Integration:Developers always keep the system fully integrated. XP teams take iterative development to
another level because they commit code multiple times a day, which is also called continuous delivery. XP practitioners
understand the importance of communication. Programmers discuss which parts of the code can be re-used or shared. This
way, they know exactly what functionality they need to develop. The policy of shared code helps eliminate integration
problems. In addition, automated testing allows developers to detect and fix errors early, before deployment.
7. Small Releases:This practice suggests releasing the first version quickly and further developing the product by making small
and incremental updates. Small releases allow developers to frequently receive feedback, detect bugs early, and monitor
how the product works in production. One of the methods of doing so is the continuous integration practice (CI) we
mentioned before.
8. Simple Design:The best design for software is the simplest one that works. If any complexity is found, it should be removed.
The right design should pass all tests, have no duplicate code, and contain the fewest possible methods and classes. It should
also clearly reflect the programmer’s intent.
XP practitioners highlight that chances to simplify design are higher after the product has been in production for
some time. Don Wells advises writing code for those features you plan to implement right away rather than writing
it in advance for other future features: “The best approach is to create code only for the features you are
implementing while you search for enough knowledge to reveal the simplest design. Then refactor incrementally to
implement your new understanding and design.”
9. Coding Standards:A team must have common sets of coding practices, using the same formats and styles for code writing.
Application of standards allows all team members to read, share, and refactor code with ease, track who worked on certain
pieces of code, as well as make the learning faster for other programmers. Code written according to the same rules
encourages collective ownership.
10. Collective Code Ownership:This practice declares a whole team’s responsibility for the design of a system. Each team
member can review and update code. Developers that have access to code won’t get into a situation in which they don’t
know the right place to add a new feature. The practice helps avoid code duplication. The implementation of collective code
ownership encourages the team to cooperate more and feel free to bring new ideas.
11. System Metaphor:System metaphor stands for a simple design that has a set of certain qualities. First, a design and its
structure must be understandable to new people. They should be able to start working on it without spending too much time
examining specifications. Second, the naming of classes and methods should be coherent. Developers should aim at naming
an object as if it already existed, which makes the overall system design understandable.
12. Programmer’s work conditions:40-Hour Week. XP projects require developers to work fast, be efficient, and sustain the
product’s quality. To adhere to these requirements, they should feel well and rested. Keeping the work-life balance prevents
professionals from burnout. In XP, the optimal number of work hours must not exceed 45 hours a week. One overtime a week
is possible only if there will be none the week after.
Roles
Although Extreme Programming specifies particular practices for your team to follow, it does not really establish specific roles for
the people on your team. Depending on which source you read, there is either no guidance, or there is a description of how roles
typically found in more traditional projects behave on Extreme Programming projects. Here are four most common roles
associated with Extreme Programming:
The Customer:The Customer role is responsible for making all of the business decisions regarding the project including:
What should the system do (What features are included and what do they accomplish)?
• How do we know when the system is done (what are our acceptance criteria)?
• How much do we have to spend (what is the available funding, what is the business case)?
• What should we do next (in what order do we deliver these features)?
The XP Customer is expected to be actively engaged on the project and ideally becomes part of the team.
The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all
of the business related information about a project. Your team needs to make sure that you get a complete picture of the business
perspective, but have some means of dealing with conflicts in that information so that you can get clear direction.
The Developer:Because XP does not have much need for role definition, everyone on the team (with the exception of the
customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories
identified by the Customer. Because different projects require a different mix of skills, and because the XP method relies on a
cross functional team providing the appropriate mix of skills, the creators of XP felt no need for further role definition.
The Tracker:Some teams may have a tracker as part of their team. This is often one of the developers who spends part of their
time each week filling this extra role. The main purpose of this role is to keep track of relevant metrics that the team feels
necessary to track their progress and to identify areas for improvement. Key metrics that your team may track include velocity,
reasons for changes to velocity, amount of overtime worked, and passing and failing tests.
 This is not a required role for your team, and is generally only established if your team determines a true need for keeping track of
several metrics.
The Coach:If your team is just getting started applying XP, you may find it helpful to include a Coach on your team. This is usually
an outside consultant or someone from elsewhere in your organization who has used XP before and is included in your team to
help mentor the other team members on the XP Practices and to help your team maintain your self discipline.The main value of
the coach is that they have gone through it before and can help your team avoid mistakes that most new teams make.
When to use XP
It’s important to make sure a company’s size, structure, and expertise, as well as the staff’s knowledge base allow for applying XP
practices. These are the factors to consider.
Highly-adaptive development. XP was designed to help development teams adapt to fast-changing requirements.
Risky projects. Teams applying XP practices are more likely to avoid problems connected with working on a new system,
especially when a product owner sets strict deadlines for a project.
Small teams. XP practices are efficient for teams that don’t exceed 12 people.
Automated testing. Another factor that can influence the choice of XP is the developers’ ability to create and run unit tests.
Available customer participation. As XP requires customers, developers and managers work side-by-side, make sure your client
can spend time in the office until a project ends.
Applications of Extreme Programming (XP)
• Small projects: XP model is very useful in small projects consisting of small teams as face to face meeting is easier to achieve.
• Projects involving new technology or Research projects: This type of projects face changing of requirements rapidly and
technical problems. So XP model is used to complete this type of projects.
Conclusion
Extreme Programming is a software development approach based on values of simplicity, communication, feedback, and courage.
Companies that build their workflow on XP principles and values create a competitive yet motivational atmosphere within and
between teams. Programmers appreciate each other’s project input, deliver software quickly because they can distinguish relevant
tasks from unnecessary ones. They react quickly to feedback realizing it’s a reasonable criticism aimed at making a product better.
XP teams don’t consider each technical challenge as a problem but think of it as a way to develop skills.

Adaptive Software Development (ASD)

Adaptive Software Development has evolved from RAD practices. The team aspects also were added to these practices.
Companies from New Zealand to Canada, for a wide range of project and product types, have used adaptive Software
Development.
Jim Highsmith published Adaptive Software Development in 2000.
Adaptive Software Development practices provide ability to accommodate change and are adaptable in turbulent environments
with products evolving with little planning and learning.
Adaptive Software Development is a method to build complex software and system. ASD focuses on human collaboration and
self-organisation.
ASD “life cycle” incorporates three phases namely:
1. Speculation
2. Collaboration
3. Learning
1. Speculation:
During this phase project is initiated and planning is conducted. The project plan uses project initiation information like project
requirements, user needs, customer mission statement etc, to define set of release cycles that the project wants.
2. Collaboration:
It is the difficult part of ASD as it needs the workers to be motivated. It collaborates communication and teamwork but
emphasizes individualism as individual creativity plays a major role in creative thinking. People working together must trust each
others to
• Criticize without animosity,
• Assist without resentment,
• Work as hard as possible,
• Possession of skill set,
• Communicate problems to find effective solution.
3. Learning:
The workers may have a overestimate of their own understanding of the technology which may not lead to the desired result.
Learning helps the workers to increase their level of understanding over the project.
Learning process is of 3 ways:
1. Focus groups
2. Technical reviews
3. Project post-mortem
Speculate - Collaborate - Learn Cycle as a Whole
As you observe from the Speculate-Collaborate-Learn cycle, given above, it is obvious that the three phases are nonlinear and
overlap.
We observe the following from an Adaptive framework.
• It is difficult to Collaborate without Learning or to Learn without Collaborating.
• It is difficult to Speculate without Learning or to Learn without Speculating.
• It is difficult to Speculate without Collaborating or to Collaborate without Speculating.
Adaptive Software Development Lifecycle has six basic characteristics −
• Mission focused
• Feature based
• Iterative
• Time-boxed
• Risk driven
• Change tolerant
Mission-focused
For many projects, the overall mission that guides the team is well articulated, though the requirements may be uncertain at the
beginning of the project. Mission statements act as guides that encourage exploration in the beginning but have a narrow focus
over the course of a project. A mission provides boundaries rather than a fixed destination. Mission statements and the
discussions that result in those statements provide direction and criteria for making critical project tradeoff decisions.
Without a clear mission and a constant mission refinement practice, iterative lifecycles become oscillating lifecycles, swinging
back and forth with no progress in the development.
Feature-based
The Adaptive Software Development Lifecycle is based on application features and not on tasks. Features are the functionality
that are developed during an iteration based on the customer’s priorities.
Features can evolve over several iterations when the customers provide feedback.
The application features that provide direct results to the customer after implementation are primary. A customer-oriented
document such as a user manual is also considered as a feature. The other documents such as the data model, even if defined as
deliverables are always secondary.
Iterative
The Adaptive Software Development Lifecycle is iterative and focuses on frequent releases in order to obtain feedback, assimilate
the resulting learning and setting the right direction for further development.
Time-boxed
In Adaptive Software Development Lifecycle, the iterations are time-boxed. However, one should remember that time-boxing in
Adaptive Software Development is not about time deadlines. It should not be used to make the team work for long hours
challenging a collaborative environment or for compromising on the quality of the deliverables.
In Adaptive Software Development, time-boxing is considered as a direction for focusing and forcing hard tradeoff decisions as
and when required. In an uncertain environment, in which change rates are high, there needs to be a periodic forcing function
such as a timebox to get the work finished.
Risk-driven
In Adaptive Software Development, the iterations are driven by identifying and evaluating the critical risks.
Change-tolerant
Adaptive Software Development is change-tolerant, viewing change as the ability to incorporate competitive advantage, but not
as a problem for development.

Adaptive Software Development practices can be illustrated as follows −

• Speculate − Initiation and planning

o Project Initiation
o Establishing time-box for the entire project
o Decide on the number of iterations and assign a time-box to each one
o Develop a theme or objective for each of the iterations
o Assign features to each iteration
• Collaborate − Concurrent feature development
o Collaboration for distributed teams
o Collaboration for smaller projects
o Collaboration for larger projects
• Learn − Quality Review
o Result quality from the customer's perspective
o Result quality from a technical perspective
o The functioning of the delivery team and the practices team members are utilizing
o The project status
Project Initiation
Project Initiation involves −
• Setting the project's mission and objectives
• Understanding constraints
• Establishing the project organization
• Identifying and outlining requirements
• Making initial size and scope estimates
• Identifying key project risks
Iterations and Time-box
• Iterations usually vary from four to eight weeks.
• Some projects work best with two-week iterations.
• Some projects might require more than eight weeks.
Develop a Theme or Objective
This is something similar to the Sprint Goal in Scrum. Each iteration should deliver a set of features that can demonstrate the
product functionality making the product visible to the customer to enable review and feedback.
Assign Features
• Development team should come up with the feature estimates, risks, and dependencies and provide them to the customer.
• Customers should decide on feature prioritization, using the information provided by the development team.
Collaborate ─ Concurrent Feature Development
During the Collaborate phase, the focus is on the development. The Collaborate phase has two activities −
• The Development team collaborate and deliver working software.
• The project managers facilitate collaboration and concurrent development activities.
Collaboration is an act of shared creation that encompasses the development team, the customers and the managers. Shared
creation is fostered by trust and respect.
Teams should collaborate on −
• Technical problems
• Business requirements
• Rapid decision making
Following are the practices relevant to the Collaborate phase in Adaptive Software Development −
• Collaboration for distributed teams
• Collaboration for smaller projects
• Collaboration for larger projects
Collaboration for Distributed Teams
In the projects involving distributed teams, the following should be considered −
• Varying alliance partners
• Broad-based knowledge
• The way people interact
• The way they manage interdependencies
Collaboration for Smaller Projects
In the smaller projects, when team members are working in physical proximity, Collaboration with informal hallway chats and
whiteboard scribbling should be encouraged, as this is found to be effective.
Collaboration for Larger Projects
Larger projects require additional practices, collaboration tools, and project manager interaction and should be arranged on the
contextual basis.
Result Quality from the Customer's Perspective
These sessions are designed to explore a working model of the application and record customer change requests.
Result Quality from a Technical Perspective
• Determine what is not working.
• What the Team needs to do more.
• What the Team needs to do less.
The Project Status
• Where is the project?
• Where is the project versus the plans?
• Where should the project be?

Dynamic Systems Development Method (DSDM)

DSDM is an agile software development methodology. It is
an iterative, incremental approach that is largely based on
the Rapid Application Development (RAD) methodology.
The method provides a five-phase framework
consisting of:
• Feasibility study
• Business study
• Functional model / prototype iteration
• Design and build iteration
• Implementation

Feasibility study
In this phase the problem is defined and the technical feasibility of the desired application is verified. Apart from these routine
tasks, it is also checked whether the application is suitable for Rapid Application Development (RAD) approach or not. Only if the
RAD is found as a justified approach for the desired system, the development continues.
 Business study
In this phase the overall business study of the desired system is done. The business requirements are specified at a high level and
the information requirements out of the system are identified. Once this is done, the basic architectural framework of the desired
system is prepared.
The systems designed using Rapid Application Development (RAD) should be highly maintainable, as they are based on the
incremental development process. The maintainability level of the system is also identified here so as to set the standards for
quality control activities throughout the development process.
Functional Model Iteration
This is one of the two iterative phases of the life cycle. The main focus in this phase is on building the prototype iteratively and
getting it reviewed from the users to bring out the requirements of the desired system. The prototype is improved through
demonstration to the user, taking the feedback and incorporating the changes. This cycle is repeated generally twice or thrice
until a part of functional model is agreed upon. The end product of this phase is a functional model consisting of analysis model
and some software components containing the major functionality
Design and Build Iteration
This phase stresses upon ensuring that the prototypes are satisfactorily and properly engineered to suit their operational
environment. The software components designed during the functional modeling are further refined till they achieve a
satisfactory standard. The product of this phase is a tested system ready for implementation.
There is no clear line between these two phases and there may be cases where while some component has flown from the
functional modeling to the design and build modeling while the other component has not yet been started. The two phases, as a
result, may simultaneously continue.
Implementation
Implementation is the last and final development stage in this methodology. In this phase the users are trained and the system is
actually put into the operational environment. At the end of this phase, there are four possibilities, as depicted by figure :
• Everything was delivered as per the user demand, so no further development required.
• A new functional area was discovered, so return to business study phase and repeat the whole process
• A less essential part of the project was missed out due to time constraint and so development returns to the functional model
iteration.
• Some non-functional requirement was not satisfied, so development returns to the design and build iterations phase.
Dynamic System Development Method (DSDM) assumes that all previous steps may be revisited as part of its iterative approach.
Therefore, the current step need be completed only enough to move to the next step, since it can be finished in a later iteration.
This premise is that the business requirements will probably change anyway as understanding increases, so any further work
would have been wasted.
According to this approach, the time is taken as a constraint i.e. the time is fixed, resources are fixed while the requirements are
allowed to change. This does not follow the fundamental assumption of making a perfect system the first time, but provides a
usable and useful 80% of the desired system in 20% of the total development time. This approach has proved to be very useful
under time constraints and varying requirements.
DSDM Model Limitations
• It is a relatively new model. It is not very common. So it is difficult
to understand.
DSDM Model Advantages
• Active user participation throughout the life of the project and
iterative nature of development improves quality of the product.
• DSDM ensures rapid deliveries.
• Both of the above factors result in reduced project costs
DSDM Principles:
DSDM has nine fundamental principles revolving around the business needs:

1. Active user involvement: the first and most crucial principle is user involvement. User, the people who will be using the final product,
must be actively involved throughout the project development. It helps in reducing the errors which may occur due to user perception
and thus reduces the cost of rework as well. DSDM emphasis on working with a small and selected group of users and stay in touch
with them continually, rather than meeting them occasionally in periodic meetings and review sessions.
2. Empowered teams: To proceed quickly and smoothly, this model encourages and empower teams to take decisions. Below are some
areas where decision making as a team is very critical
• Requirements decision
• Prioritizing the activities and features delivery
• Details of technical requirements
• Which functionality needs to add in a given incremental
3. Frequent delivery: A frequent delivery of value to the customer ensures that the errors/bugs get identified, worked upon, and
resolved/ reversed/fixed at an early stage. The source of the error and root cause is also found and fixed. It applies to all, requirement
documents (user stories), working models as well as on program codes.
4. Fitness for business: In DSDM, our focus is to deliver software which is efficient enough to solve a business need and accepts changes
or enhancement in a later iteration. DSDM focuses on satisfying business needs first and doesn’t allow to create ad-hoc software. It
keeps the process flow simple and effective.
5. Incremental development: To keep the big project simple and less complicated, it becomes crucial to decompose it into multiple
small feature projects. Every delivery ensures a new feature gets delivered to the client. This incremental development and delivery
continue until the delivery of the complete set of business required features.
6. Reversible changes: In DSDM iteration happens through small increments. As all the stages of development are well known to
developers, so changes here are reversible. Therefore, the fear of total loss of work is also very less.
7. Base-line the requirements: Some high-level baselines need to be set to limit the degree of freedom to make changes. During the
business agreement phase, the Business and Development Team discuss and agree on the baseline when the change requests and
requirements would be “frozen.”
8. Integrated testing: In DSDM, testing is done as early as in the development phase to ensure that the product does not have any
technical flaws. Developers and team leads cross-check even the testing documents. It helps in fixing issues at a very early stage and
reduces rework and therefore reduces cost and time.
9. Stakeholder collaboration: It is crucial to have an atmosphere of trust and honesty to get precise requirements and honest feedback
on a resultant product. In DSDM, Business staff and developer collaboration are very crucial to deliver value. Clear business
requirement and honest feedback help in fast development which further leads to timely delivery of the project.
Four values: below are the four values of DSDM:
1. Individual: Like Agile in DSDM also value people. In the end, these are the people who are working physically on the project and know
the practical part better. Their experience and expertise add more value to the project as compared to tools, documents, or process
flows.
2. Working software: It is very crucial that a shared understanding and a standard definition of “Working software” exists between all
the parties interested in the software.
Note – Working software is the software that has successfully gone through all the stages of development and testing and ready to hit
the market now. It will be the version of the software that will be used by the end-user
3. Collaboration: It is one of the essential values for effective delivery. It is because getting people in one room to make a decision will
be more productive, less time taking, and efficient than sharing emails for weeks to make a decision. Here are a few examples of
Collaboration –
• Cross-functional team
• Co-location with the client
• Facilitating workshop
4. Response to changes: DSDM welcomes all the required modifications and accommodates them. It values and responds to all the
changes in a very innovative way, mainly through prioritizing them.
Project structure in DSDM:
The DSDM project process flow consists of 7 phases, which are organized in a rich set of roles and responsibilities and are
supported by some core techniques. Below is the part of the structure of a DSDM system process flow.
• Roles and responsibilities
• Team organization and size
• Tools and techniques
• Phase to rule them/ Process Flow
Roles and Responsibilities:
There are three leading roles in DSDM –
Project level roles:
• Directors
• Project Owners
• Project Managers
Their responsibility is to control the project as a whole. They will not be working on the project but will be responsible for getting
the work done and keep the business updated about the current situation. They act as a connection between the User and
Development team. These are usually executive level people and work directly with the business. They are also called
the Ambassadors.
Solution Development Roles:
• Developers
• Testers
They work as the “heart” of the project. They are the main driving force as they work on ground zero and are responsible for the
development of the product/solution.
Supporting Roles:
• DSDM Coach
• Workshop Facilitator
These people have good practical knowledge of all the areas of business. They assist and guide everyone working on it
continuously throughout the project until delivery. They have a good understanding of the DSDM framework as well as of
development.
Team Organization and Size:
In DSDM, a project team may consist of one or two groups, whereby one group takes the responsibility to run the tests on another
group’s delivery.
As per organizational research, team size should not be less than five members, excluding external experts. External experts are
the experienced executive level people who support projects externally.
And if the project is big and more work is to be delivered, then a multi-team structure is required.
Tools and Techniques:
The main focus of DSDM is that the product is delivered frequently in each iteration. Different tools, techniques, and, practices are
used to support the whole DSDM process.
• The Timeboxing,
• The MoSCow prioritization,
 • Facilitated workshops,
• Iterative development,
• Modeling and prototyping techniques.

Timeboxing:
Timeboxing is one of the most crucial core practices. It is similar to what a milestone is in tradition software development
methods or what a sprint is in the Scrum Agile Method. Timeboxing is the amount of work to be done in a fixed given time.
One software development project will have multiple time boxes, and every time box is assigned one specific objective.
Timeboxing helps in achieving the target in time. Usually, for a project duration of a time box can be from two weeks to a
maximum of 6 weeks but not more than that.
Benefits of having Time Boxing:
• Focus on delivering the product on time.
• People stay focused as per priority and do not deviate, and thus improves productivity.
• All members know what the other person is doing and how long it is going to take to complete that activity.
• Decreases dependency and delegation of work as every member is occupied and has to give deliverables in time.
It’s like a healthy eating habit, “Eat a tiny portion of food at small intervals.”
Let’s understand it with the help of an example. We all love our student life & we all have gone through it. During exams, even if there
is a sufficient gap between the two reviews, we always used to study on the last 1 or 2 days. And our parents used to tell us to do a
little every day. The correct approach would have been
• Make a schedule
• Divide your syllabus into small portions
• Prioritize them
• Assign timelines to every part
• Finish portion in the assigned time
This systematic approach to finish the assigned work in committed time is called Timeboxing.

Facilitated Workshops:
Facilitated Workshops means providing a workshop where team members and developers can work on a clear pre-set of
deliverables. To get access to this workshop, they coordinate with a neutral person who is called Workshop facilitator. The
facilitator will be guiding the team through a process to achieve its objectives, expertly. This process that facilitator guide through
includes-
• Defining the objective,
• Identifying appropriate participants,
• Creating an agenda,
• Managing the logistics and
• Distributing any pre-reading to participants.
The motive behind having a workshop is to encourage collaborative working and enable team decisions in a short time. It allows
knowledge sharing too.
It’s like a classroom, you can discuss only one topic from a specific subject at a particular time, and the purpose of that discussion will
be focused, that is, to make the classroom understand that particular topic.
Benefits of having a Workshop include:
• Provide an ideal environment for exploring new ideas and encourages quick and systematic growth of those ideas.
• A broader range of stakeholders can take decisions.
• Everyone is aware of discussions and decisions.
• Decision making is quick & accurate.

MoSCoW Prioritization:
• Must-Have: The requirements that are fundamental and must conform to the solution.
• Should Have: The things that are important for the business solution.
• Could Have: The requirements that are important but can more easily be left out for a short while.
• Won’t Have: The requirements that can wait and include in later development.
Benefits of MoSCoW are:
• It allows business expectations to set at the Project level.
• Ensures that the team delivers the Must-Haves first
• Ensures that they deliver most or all of the Should Haves
• If time allows developers may deliver some of the Could Haves too.
• You want to purchase a big car with the following features-
Let’s define prioritization in the above case as per MoSCoW:
• Must have
• Seven seater car for off-roading and road trips
• Should have
• 2000cc engine
• Good Mileage
• Navigation System
 • Good boot space
• Could have
• Yellow color car
• Sunroof
• Won’t have
• Bluetooth
• Child seat.

Scrum (software development)

Scrum is the type of Agile framework. It is a framework within which people can address complex adaptive problem while
productivity and creativity of delivering product is at highest possible values. Scrum uses Iterative process.
Silent features of Scrum are:
• Scrum is light-weighted framework
• Scrum emphasizes self-organization
• Scrum is simple to understand
• Scrum framework help the team to work together
Foundation of Scrum
Scrum is based on three pillars. Transparency, Inspection, and Adaptation.
Transparency: Transparency allows everyone on the Scrum Team and outside to align and optimize the goals of the Scrum Team,
self-organize based on the available information and adapt based on the feedback. Transparency improves decision making,
removes duplication and wasteful efforts and reduces silo behavior.
Inspection: In the presence of information available transparently, the members of the Scrum Team are able to inspect any
deviation of actual results compared with expected results. Regular inspection and adaptation is built-in in to the design of the
Scrum Framework.
Adaptation: Due to regularly and rapidly moving goals, customer needs, market conditions, competition, etc. there is an ongoing
need to adjust the direction of the products/services/solutions, organizations offer. Scrum Events offer opportunities for regular
Inspection and Adaptation.
Who is in the Scrum?
In rugby, the forwards are involved in the scrum. In software development, three roles are defined in the scrum framework:
The scrum team does the work. It is the individuals who are working together in the sprints to produce the products.The Team is
self-organizing and cross-functional. That means the team comprises of analysts, designers, developers, testers, etc. as
appropriate and as relevant to the project.
The scrum master is part of the scrum team makes sure the team works in compliance with the scrum rules. This is not a
manager.
o making the process run smoothly
o removing obstacles that impact productivity
o organizing and facilitating the critical meetings
The product owner represents the customer. This role prioritizes the backlog and coordinates the scrum teamwork. The product
owner is a role similar to project manager in more traditional project management frameworks.The Product Owner is the sole
person responsible for managing the Product Backlog. Product Backlog management includes-
• Expressing Product Backlog items clearly.
• Ordering the Product Backlog items to best achieve goals and missions.
• Optimizing the value of the work the Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.
• Ensuring that the Team understands items in the Product Backlog to the level needed.
What are the Scrum Values?
1. Focus: Focus on delighting the customer by delivering highest value features first.
2. Openness: Being open to all stakeholders with information about the work.
3. Respect: Respect for people and their freedom to express.
4. Courage: Being courageous to challenge mediocrity, the status quo, top-down command, and hierarchy.
5. Commitment: Committing to serving customers through valuable and quality products.

Scrum Process Framework

In Scrum, the prescribed events are used to create regularity. All events are time-boxed events, such that every event has a
maximum duration. The events are described more elaborately in the subsequent chapters.
Sprint
The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially releasable product increment is
created and this duration remains constant for all the sprints in the project. We cannot have varying durations for the different
sprints in a project. A new Sprint starts immediately after the conclusion of the previous Sprint.
A Sprint should be cancelled if the Sprint Goal becomes obsolete. This might occur if the organization changes direction or if
market or technology conditions change. A sprint can be cancelled only by product owner, though others have an influence on
the same.
If a Sprint is cancelled, and part of the work produced during the sprint is potentially releasable, the Product Owner typically
accepts it. All the incomplete Sprint Backlog Items are put back into the Product Backlog.
Sprints consist of the Sprint planning, daily scrums, the development work, the Sprint review, and the Sprint retrospective.
• In Sprint planning, the work to be performed in the Sprint is planned collaboratively by the Scrum Team.
• The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to synchronize the activities and create a
plan for that day.
• A Sprint Review is held at the end of the Sprint to inspect the Increment and make changes to the Product Backlog, if
needed.
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this meeting, the Scrum
Team is to inspect itself and create a plan for improvements to be enacted during the subsequent Sprint.
Sprint Planning
The work to be performed in the Sprint is planned in the Sprint Planning Meeting. Sprint Planning Meeting is of duration of
maximum of four hours for two weeks sprints and eight hours for one month Sprints. It is the responsibility of the Scrum Master
to ensure that the meeting takes place and that all the required attendees are present and understand the purpose of the
scheduled meeting. The Scrum Master moderates the meeting to monitor the sustenance of discussion and closure on time.
Sprint Planning focuses on the following two questions -
• What needs to be and can be delivered in the Sprint Increment?
• How will the work needed for the execution of Sprint be achieved?
The inputs to this meeting are -
• The Product Backlog
• The latest product Increment
• Projected capacity of the Team during the Sprint
• Past performance of the Team
The Scrum Team discusses the functionality that can be developed during the Sprint. Product Owner provides clarifications on
the Product Backlog items. The team selects the items from the Product Backlog for the Sprint, as they are the best to assess what
they can accomplish in the Sprint.
The Scrum Team then comes up with Sprint Goal. The Sprint Goal is an objective that provides guidance to the Team on why it is
building the Product Increment. The Team then decides how it will build the selected functionality into a working product
Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the
Sprint Backlog.
Work during a sprint is estimated during sprint planning and may be of varying size and/or effort. By the end of the Sprint
Planning meeting, the work is divided into tasks of duration of one day or less. This is to enable the ease of work allocation, and
tracking the completion. If the Team realizes that it has too much or too little work, it can renegotiate the selected Product
Backlog items with the Product Owner.
The Team may also invite others (not part of Scrum Team) to attend the Sprint Planning meeting to obtain technical or domain
advice or help in estimation
Daily Scrum Meetings
The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily to quickly understand the work since the last
Daily Scrum Meeting and create a plan for the next 24 hours. This meeting is also referred to as Daily Stand up Meeting.
The Daily Scrum Meeting is held at the same time and same place every day to reduce complexity.
During the meeting, each Team member explains -
• What did he do yesterday that helped the Team meet the Sprint Goal?
• What will he do today to help the Team meet the Sprint Goal?
• Does he see any impediments that prevent him or the Team from meeting the Sprint Goal?
Daily Scrum is mistaken to be a status tracking event, though, in fact, it is a planning event.
The input to the meeting should be how the team is doing toward meeting the Sprint Goal, and the output should be a new or
revised plan that optimizes the team’s efforts in meeting the Sprint Goal.
Though the Scrum Master coordinates the Daily Scrum Meeting and ensures that the objectives of the meeting are met, the
Meeting is the responsibility of the Team.
If necessary, the Team may meet immediately after the Daily Scrum Meeting, for any detailed discussions, or to re-plan the rest of
the Sprint’s work.
Following are the benefits of Daily Scrum Meetings -
• Improve communication within the Team.
• Identify impediments, if any, in order to facilitate an early removal of the same, so as to minimize impact on the Sprint.
• Highlight and promote quick decision-making.
• Improve the Team’s level of knowledge.
Sprint Review
A Sprint Review is held at the end of every Sprint. During the Sprint Review, a presentation of the increment that is getting
released is reviewed. In this meeting, the Scrum Team and the stakeholders collaborate to understand what was done in the
Sprint. Based on that, and any changes to the Product Backlog during the Sprint, the attendees arrive at the next steps required
that could optimize value. Thus, the objective of Sprint Review is to obtain feedback and progress unitedly.
The Sprint Review is normally held for two hours for two week sprints and for four hours for one month sprints.
The Scrum Master ensures that -
• The meeting takes place.
• The participants understand the purpose.
• The meeting is focused on the required agenda and is completed within the required duration.
The Sprint Review includes the following aspects -
• Attendees include the Scrum Team and key stakeholders, as invited by the Product Owner.
• The Product Owner explains what Product Backlog items have been completed during the sprint and what has not been
completed.
• The Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
• The Team demonstrates the work that it has completed and answers questions, if any, about the Increment.
• The entire group then discusses on what to do next. Thus, the Sprint Review provides valuable input to Sprint Planning of
the subsequent Sprint.
• The Scrum Team then reviews the timeline, budget, potential capabilities, and marketplace for the next anticipated release
of the product increment.
• The outcome of the Sprint Review is an updated Product Backlog, which defines the probable Product Backlog items for the
next Sprint.
Sprint Retrospective
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is usually a one hour meeting
for two-week duration sprints and a three hour meeting for one month duration Sprints.
The purpose of the Sprint Retrospective is to -
• Combine the learnings from the last Sprint, with regards to people, relationships, process, and tools.
• Identify the major items that went well and potential improvements.
• Creation of a plan for implementing improvements to increase product quality.
The Sprint Retrospective is an opportunity for the Scrum Team to introspect and improve within the Scrum process framework so
as to make the next Sprint outcome more effective.

Simply the Terms

Product backlog: The product backlog is a prioritized features list containing every desired feature or change to the product. Note: The term
“backlog” can get confusing because it’s used for two different things. To clarify, the product backlog is a list of desired features for the product.
The sprint backlog is a list of tasks to be completed in a sprint.
Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during which the product owner presents the top items on
the product backlog to the team. The Scrum team selects the work they can complete during the coming sprint. That work is then moved from the
product backlog to a sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete
in the sprint.
Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s
work and helps the team stay on track. All team members are required to attend the daily scrum.
Sprint review meeting: At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which,
the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal
way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective, which is a meeting during which the team
(including its ScrumMaster and product owner) reflect on how well Scrum is working for them and what changes they may wish to make for it to
work even better.

Product Backlog
▪ The Product Backlog is an ordered list of features that are needed as part of the end product and it is the single source of
requirements for any changes to be made to the product.
▪ The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be
made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and
value. These items are normally termed as User Stories. The Product Owner is responsible for the Product Backlog, including
its content, availability, and ordering.
▪ A Product Backlog is an evolving artifact. The earliest version of it may contain only the initially known and best understood
requirements. The Product Backlog gets developed as the product, and the environment in which it will be used, progress.
The Product Backlog constantly changes to incorporate what is required to make it effective. As long as a product exists, its
Product Backlog also exists.
▪ As the product being built is used and gains value, the Product Backlog becomes a larger and more exhaustive list. Changes
in business requirements, market conditions, or technology, cause changes in the Product Backlog, making it a live artifact.
▪ Product Backlog refinement means adding detail, estimates, and priority order to the Product Backlog items. This is an
ongoing process performed by the Product Owner and the Team. The Scrum Team decides how and when refinement is to
be done.
▪ Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
▪ Higher-ordered Product Backlog items are usually clearer and more detailed than lower-ordered ones. More precise
estimates are made based on the greater clarity and increased detail. The lower the order, the lesser is the detail.
▪ Product Backlog items that may likely be the candidate requirements for the upcoming Sprint are refined so that these items
can be developed during the Sprint. Product Backlog items that can be developed by the Team within one Sprint are
deemed to be ready for selection in a Sprint planning meeting.
 Sprint Backlog
▪ The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product
Increment and realizing the Sprint Goal.
▪ The Sprint Backlog is a forecast by the Team about what functionality will be made available in the next Increment and the
work needed to deliver that functionality as a working product Increment.
▪ The Sprint Backlog is a plan with enough detail that can be understood but the Team to track in the Daily Scrum. The Team
modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence
occurs as the Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
▪ As new work is required, the Team adds it to the Sprint Backlog. As work is performed or completed, the estimated
remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Team can
change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Team
plans to accomplish during the Sprint, and it belongs solely to the Team.
Increment
▪ The Increment is the sum of all the Product Backlog items completed during a Sprint combined with the increments of all
previous Sprints. At the end of a Sprint, the new Increment must be a working product, which means it must be in a useable
condition.
▪ The purpose of each Sprint is to deliver Increments of potentially releasable functionality.
▪ Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose
to release it immediately.
▪ Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
▪ As Scrum Teams mature, it is expected that their definitions of Increments expands to include more stringent criteria for
higher quality. Any one product should have a definition of Increment that is a standard for any work done on it.
Sprint Burn-Down Chart
▪ At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Team tracks this total
work remaining for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work
throughout the Sprint, the Team can manage its progress.
▪ Sprint Burn-Down Chart is a practice for trending the work expended by the Scrum Team. This has been proven to be a
useful technique in monitoring the Sprint progress towards the Sprint Goal.
▪ The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount
with work remaining at previous Sprint Reviews to assess progress toward completing the projected work by the desired
time for the goal. This information is shared with all stakeholders.
▪ The sprint tracking is usually done using Burn-Down Chart. Burn-Down Chart shows the remaining effort in day-wise number
of hours.

For example, let us consider a 2-week sprint -

Sprint Duration: 2 Weeks
No. of Days per Week: 5
No. of Hrs. per Day: 6
No. of Resources: 6
Hence, total remaining effort at the beginning of sprint is 2*5*6*6 = 360 hrs.
Therefore, in an ideal scenario, 36 hours of work gets reduced in the remaining work and the
burn-down chart looks as follows –

If the sprint work is done as planned daily, the scrum progress is almost aligned to the ideal bar.
If the sprint work gets delayed and time commitment is not met, the burn-down chart looks as
follows -

But, as the burn-down chart is drawn daily, and the slippage is known early, corrective actions
can be taken to meet the sprint time line. Suppose, the team stretches to meet the timeline, the
burn-down chart looks as follows -

Thus, at any point in time in a Sprint, the total work remaining in the Sprint can be visualized
and possibility of meeting sprint timeline can be improved.
Conclusion
Burn-down charts aid the Scrum team to keep track of their progress and what needs to be done
to meet the sprint goal.

Advantage of using Scrum framework:

• Scrum framework is fast moving and money efficient.
• Scrum framework works by dividing the large product into small sub-products. It’s like a divide and conquer strategy
• In Scrum customer satisfaction is very important.
• Scrum is adaptive in nature because it have short sprint.
• As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time
Disadvantage of using Scrum framework:
• Scrum framework do not allow changes into their sprint.
• Scrum framework is not fully described model. If you wanna adopt it you need to fill in the framework with your own details like
Extreme Programming(XP), Kanban, DSDM.
• It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition.
• The daily Scrum meetings and frequent reviews require substantial resources.

Computer Aided Software Engineering (CASE)

Computer aided software engineering (CASE) is the implementation of computer facilitated tools and methods in software
development. CASE is used to ensure a high-quality and defect-free software. CASE ensures a check-pointed and disciplined
approach and helps designers, developers, testers, managers and others to see the project milestones during development.
CASE can also help as a warehouse for documents related to projects, like business plans, requirements and design specifications.
One of the major advantages of using CASE is the delivery of the final product, which is more likely to meet real-world
requirements as it ensures that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development. It generates a framework for organizing
projects and to be helpful in enhancing productivity. There was more interest in the concept of CASE tools years ago, but less so
today, as the tools have morphed into different functions, often in reaction to software developer needs. The concept of CASE also
received a heavy dose of criticism after its release.
Advantages of the CASE approach:
• As special emphasis is placed on redesign as well as testing, the servicing cost of a product over its expected lifetime is
considerably reduced.
• The overall quality of the product is improved as an organized approach is undertaken during the process of development.
• Chances to meet real-world requirements are more likely and easier with a computer-aided software engineering approach.
• CASE indirectly provides an organization with a competitive advantage by helping ensure the development of high-quality
products.

CASE Tools
• CASE Tools is stands for Computer Aided Software Engineering Tools. As the name suggests, these are the tools which are
used to automate the processes while developing software product through software development life cycle (SDLC).
• The CASE Tools are capable of automating the tasks in almost every phase of software development life cycle reducing the
workload of developers and other team members. They are application programs which are designed to perform specific
tasks.
• By automating the various processes of software development life cycle, the risk of errors & fault decreases and efficiency &
functionality increases. Also, CASE Tools are efficient enough to reduce the time consumption effectively making the cost of
the project in control.
• The scope of CASE tools goes throughout the SDLC.
• CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage:
• Central Repository - CASE tools require a central repository, which can serve as a source of common, integrated and
consistent information. 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.

Case Tools Types

▪ Diagram tools
These tools are used to represent system components, data and control flow among various software components and
system structure in a graphical form.
For example, Flow Chart Maker tool for creating state-of-the-art flowcharts, Dia, Microsoft visio.
▪ Process Modelling Tools
Process modelling is method to create software process model, which is used to develop the software. Process modeling
tools help the managers to choose a process model or modify it as per the requirement of software product.
 For example, EPF Composer
▪ Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling and resource planning. Managers
have to strictly comply project execution with every mentioned step in software project management. Project management
tools help in storing and sharing project information in real-time throughout the organization.
For example, Dashboards, Project Scheduling, Project Reporting, Creative Pro Office, Trac Project, Basecamp.
▪ Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all phases of SDLC and after the
completion of the project.
Documentation tools generate documents for technical users and end users. Technical users are mostly in-house
professionals of the development team who refer to system manual, reference manual, training manual, installation
manuals etc. The end user documents describe the functioning and how-to of the system such as user manual.
For example, Webhelp, MarkdownPad, Doxygen, DrExplain, Adobe RoboHelp for documentation.
▪ Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in the diagrams, data
redundancies or erroneous omissions.
For example, Artemis, Zoho Desk, Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total
analysis.
▪ Design Tools
These tools help software designers to design the block structure of the software, which may further be broken down in
smaller modules using refinement techniques. These tools provide detailing of each module and interconnections among
modules.
For example, Adobe Illustrator, Photoshop, Animated Software Design
▪ Configuration Management Tools
An instance of software is released under one version. Configuration Management tools deal with –
Version and revision management
Baseline configuration management
Change control management
CASE tools help in this by automatic tracking, version management and release management.
For example, Fossil, Git, Accu REV.
▪ Change Control Tools
These tools are considered as a part of configuration management tools. They deal with changes made to the software after
its baseline is fixed or when the software is first released. CASE tools automate change tracking, file management, code
management and more. It also helps in enforcing change policy of the organization.
▪ Programming Tools
These tools consist of programming environments like IDE (Integrated Development Environment), in-built modules library
and simulation tools. These tools provide comprehensive aid in building software product and include features for
simulation and testing.
For example, Dreamweaver, Net-Beans, Vim, Atom, Cscope to search code in C, Eclipse.
▪ Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype provides initial look and feel of the
product and simulates few aspects of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create hardware independent user interfaces and
design. These tools help us to build rapid prototypes based on existing information. In addition, they provide simulation of
software prototype.
For example, Framer, Principle, Serena prototype composer, Mockup Builder.
▪ Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so on. Web tools also
provide live preview of what is being developed and how will it look after completion.
For example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
▪ Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process and methods adopted to develop the
software product in order to ensure conformance of quality as per organization standards. QA tools consist of configuration
and change control tools and software testing tools.
For example, Selenium, Appium, SoapTest, AppsWatch, JMeter.
▪ Maintenance Tools
Software maintenance includes modifications in the software product after it is delivered. Automatic logging and error
reporting techniques, automatic error ticket generation and root cause Analysis are few CASE tools, which help software
organization in maintenance phase of SDLC.
For example, Bugzilla for defect tracking, HP Quality Center.