System/Software Process

• A structured set of activities required to develop a software system.

• The system process is the way in which we produce software.
• A system process (also knows as software methodology) is a set of
related activities that leads to the production of the software.
• These activities may involve the development of the system from the
scratch, or, modifying an existing system.
• There are also supporting activities such as configuration and change
management, quality assurance, project management, user
experience.
• When we talk about a process, we usually talk about the activities in it.

Activities involved in System/Software Process

• There are four major activities involved in System process:
• System specification : Define the main functionalities of the system and
the constrains around them.(defining what the system should do)
• System design and implementation The system is to be designed and
programmed.(defining the organization of the system and implementing the system;)
• System verification and validation The system must conforms to it’s
specification and meets the customer needs.(checking that it does what the
customer wants;)
• System evolution (software maintenance): The system is being modified
to meet customer and market requirements changes.(changing the system in
response to changing customer needs.)
 System/Software Process Model
• A system process model is an abstract/simplified
representation of a process.
• It presents a description of a process from some
particular perspective
• When we describe and discuss processes, we
usually talk about the activities in these processes
such as specifying a data model, designing a user
interface, etc. and the ordering of these activities.
• Some methodologies are sometimes known as
System development life cycle (SDLC)
methodologies, though this term could also be Fig: SDLC Phases
used more generally to refer to any methodology.

• SDLC Phases: 3.Design:Convert recommended solution to system

specifications
• 1.Planning Phase: Identify, analyze, prioritize, and arrange
• Logical Design
IS needs
• functional features described independently of
• Project Identification and Selection computer platform
• Two Main Activities • Concentrates on business aspects of the system
• Identification of need • Physical Design
• Prioritization, arrangement and translation of need into a • logical specifications transformed to technology-
development schedule specific details
• Helps organization to determine whether or not resources should be • Technical specifications
dedicated to a project.
• Project Initiation and Planning
4.Implementation:Code, test, install, and support the
information system
• Two Activities
Hardware and software installation
• Formal preliminary investigation of the problem at hand
• Programming
• Presentation of reasons why system should or should not be
developed by the organization • User Training
• Documentation
• 2.Analysis:Study and structure system requirements
5.Maintenance:Systematically repair and improve the
• Study of current procedures and information systems information system
• Determine requirements • System changed to reflect changing conditions
• Study current system • System obsolescence
• Structure requirements and eliminate redundancies
• Generate alternative designs
• Compare alternatives
Recommend best alternative
Approaches to System/Systems Development
• Process-Oriented Approach
• Focus is on flow, use and transformation of data in an information system
• Involves creating graphical representations such as data flow diagrams and charts
• Data are tracked from sources, through intermediate steps and to final
destinations
• Natural structure of data is not specified
• Data-Oriented Approach
• Depicts ideal organization of data, independent of where and how data are used
• Data model describes kinds of data and business relationships among the data
• Business rules depict how organization captures and processes the data

Plan Driven Vs Agile Process

• Plan-driven Process
• A plan-driven approach to software
engineering is based around separate
development stages with the outputs to be
produced at each of these stages planned in
advance.
• Not necessarily waterfall model – plan-driven,
incremental development is possible
• Iteration occurs within activities.
• Agile Process
• Specification, design, implementation and
testing are inter-leaved and the outputs from
the development process are decided through
a process of negotiation during the software
development process.
Generic Process models
• The waterfall model:
This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate
process phases such as requirements specification, software design, implementation, testing, and so on.
• Incremental and iterative development:
• This approach interleaves the activities of specification, development, and validation.
• The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
• Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving
versions until the full system is implemented
• Integration and configuration
• The system is assembled from existing configurable components. May be plan-driven or agile.
• Reuse-oriented software engineering:
• This approach is based on the existence of a significant number of reusable components.
• The system development process focuses on integrating these components into a system rather than developing them from scratch.
• These models are not mutually exclusive and are often used together, especially for large systems development
• Rapid Software Development
• Rapid Application Development(RAD)
• Agile Methods
• Extreme Programming
• Rational Unified Process(RUP)
• In practice, most large systems are developed using a process that incorporates elements from all of these models.

• Sequential(Waterfall Model)
– The first published model of the software development process was Waterfall model. It was
proposed by Royce in 1970s.
– This model takes the fundamental process activities of specification, development,
validation and evolution and represents them as separate phases such as requirements
specification, software design, implementation, testing and maintenance
– In principle, the result of each phase is one or more documents that should be approved
and the next phase shouldn’t be started until the previous phase has completely been
finished.
– The waterfall model is an example of a plan-driven process—in principle, you must plan
and schedule all of the process activities before starting work on them
– This model is named “waterfall model” because its diagrammatic representation resembles
a cascade of waterfalls
– This model is easy to understand and reinforces the notion of “define before design” and
“design before code”.
– The model expects complete & accurate requirements early in the process, which is
unrealistic
 • Requirements analysis and definition:

The structure/phases of Waterfall – The system’s service, constraints and goals are established by
consultation with system users. They are often defined in detail and
model •
serve as a system specification.
System and software design:
– The system design process partitions the requirements to either
hardware or software systems.
– It establishes overall system architecture. Software design involves
identifying and describing the fundamental software system
abstractions and their relationship
• Implementation and unit testing:
– During this stage, the software design is realised as asset of programs
and program units.
– Unit testing involves verifying that each unit meets its specification.
• 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.
• Operation and maintenance:
– This is the longest life-cycle phase. The system is installed and put
into practical use.
– Maintenance involves correcting errors which were not discovered
earlier stages of the life-cycle, improving the implementation of
system units and enhancing the system’s services as new
requirements are discovered.

When to use?
In principle, the waterfall model should only be applied when requirements are well understood and
unlikely to change radically during development as this model has a relatively rigid structure which
makes it relatively hard to accommodate change when the process in underway.
Advantages/Strengths
Disadvantages/weaknesses
• Easy to understand, easy to use
• The drawback of the waterfall model is the difficulty
• Provides structure to inexperienced staff of accommodating change after the process is
• Sets requirements stability underway because of sequential nature
• Good for management control (plan, staff, • Not a good model for complex and object-oriented
track) projects.
• Works well when quality is more important • Does not reflect problem-solving nature of software
than cost or schedule development – iterations of phases.
• Easy to understand even by non-technical • Poor model for long and ongoing projects.
person, i.e customers. • Inflexible partitioning of the project into distinct
• Each phase has well defined inputs and stages
outputs. • This makes it difficult to respond to changing
• Easy to use as software development customer requirements
proceeds,
• Each stage has well defined deliverables. • This model is only appropriate when the
requirements are well-understood
• Helps the project manager in proper planning
of the project.
 Prototyping Model
• A prototype is a version of a system or part of the system that’s developed quickly to check the
customer’s requirements or feasibility of some design decisions.
• So, a prototype is useful when a customer or developer is not sure of the requirements, or of
algorithms, efficiency, business rules, response time, etc.
• In prototyping, the client is involved throughout the development process, which increases the
likelihood of client acceptance of the final implementation.
• While some prototypes are developed with the expectation that they will be
discarded(throwaway), it is possible in some cases to evolve from prototype to working
system(evolutionary).
• A software prototype can be used:
– In the requirements engineering, a prototype can help with the elicitation and validation of system
requirements.
– It allows the users to experiment with the system, and so, refine the requirements. They may get
new ideas for requirements, and find areas of strength and weakness in the software.
– Furthermore, as the prototype is developed, it may reveal errors and in the requirements. The
specification maybe then modified to reflect the changes.
– In the system design, a prototype can help to carry out deign experiments to check the feasibility of
a proposed design.
• For example, a database design may be prototyped and tested to check it supports efficient
data access for the most common user queries.

Prototype model phases

1. Requirements gathering and analysis:

A prototyping model begins with requirements analysis and the requirements of
the system are defined in detail.
2. Quick design:
When requirements are known, a preliminary design or quick design for the
system is created. A quick design helps in developing the prototype.
3. Build prototype:
Information gathered from quick design is modified to form the first prototype,
which represents the working model of the required system.
4. User evaluation:
Next, the proposed system is presented to the user for thorough evaluation of the
prototype to recognize its strengths and weaknesses such as what is to be added or
removed.
Comments and suggestions are collected from the users and provided to the
developer.
5. Refining prototype:
Once the user evaluates the prototype and if he is not satisfied, the current
prototype is refined according to the requirements. That is, a new prototype is
developed with the additional information provided by the user. The new
prototype is evaluated just like the previous prototype.
This process continues until all the requirements specified by the user are met.
Once the user is satisfied with the developed prototype, a final system is
developed on the basis of the final prototype.

6. Engineer product:
Once the requirements are completely met, the user accepts the final prototype.
The final system is evaluated thoroughly followed by the routine maintenance on
regular basis for preventing large-scale failures and minimizing downtime.
 Advantages/Disadvantages • Weaknesses:
• Advantages: – This model is time consuming and expensive.
– The developer loses focus of the real purpose of prototype
• Reduce the risk of incorrect user and hence, may compromise with the quality of the
software. For example, developers may use some inefficient
requirement algorithms or inappropriate programming languages while
• Good where requirement are developing the prototype.
changing/uncommitted – Prototyping can lead to false expectations. For example, a
situation may be created where the user believes that the
• Regular visible process aids development of the system is finished when it is not.
management – An unstable/badly implemented prototype often becomes
the final product.
• Support early product marketing • Require extensive customer collaboration
• Reduce Maintenance cost. – Costs customer money
• Errors can be detected much – Needs committed customer
earlier as the system is made side – Difficult to finish if customer withdraw
by side. – May be too customer specific, no broad market
• Difficult to know how long the project will last.
• Easy to fall back into the code and fix without proper
requirement analysis, design, customer evaluation, and
feedback.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
15

Iterative Model
• In the iterative model, the development starts with a limited number of finalized
and prioritized requirements.
• The deliverable is a working increment of the product.
• A set of activities ranging from requirements to code development is called
iteration.
• Based on the functionality of the increment and any or all of the new, modified,
pending requirements, the next lot of requirements is given to the subsequent
iteration.
• The outcome of the subsequent iteration is an enhanced working increment of the
product. This is repeated till the product accomplishes the required functionalities.
• The process of Iterative Model is cyclic, unlike the more traditional models that
focus on a rigorous step-by-step process of development.
• In this process, once the initial planning is complete, a handful of phases are
repeated again and again, with the completion of each cycle incrementally
improving and iterating on the software
Iterative Model Phases:
• Requirement Identification and Planning Phase:
– proper planning is done by the team, which helps them in mapping out the
specifications documents, establish software or hardware requirements and
generally prepare for the upcoming stages of the cycle.
• Analysis and Design Phase:
– an analysis is performed to point out the appropriate business logic, database
models and to know any other requirements of this particular stage.
– the technical requirements are established that will be utilized in order to
meet the need of analysis stage.

• Implementation Phase:
– the actual implementation and coding process is executed.
– All planning, specification, and design documents up to this point are coded
and implemented into this initial iteration of the project.
• Testing Phase:
– testing is initiated in the cycle to identify and locate any potential bugs or
issues that may have been in the software.
• Evaluation Phase:
– the entire team along with the client, examine the status of the project and
validate whether it is as per the suggested requirements.

When to use Iterative Model?

-When the requirements of the complete system are clearly defined and understood.
-The major requirements are defined, while some functionalities and requested enhancements
evolve with the process of the development process.
-A new technology is being used and is being learnt by the development team, while they are
working on the project.
-When the resources with needed skill sets are not available and are planned to be used on contract
basis for specific iterations.
Advantages Disadvantages
• It is easily adaptable to the ever changing needs of the project • More and skilled resources may be
as well as the client. required.
• It is best suited for agile organizations. • Although cost of change is lesser, but
• It is more cost effective to change the scope or requirements in it is not very suitable for changing
Iterative model. requirements.
• Parallel development can be planned.
• More management attention is
• Testing and debugging during smaller iteration is easy. required.
• Risks are identified and resolved during iteration; and each
iteration is an easily managed. • It is not suitable for smaller projects.
• In iterative model less time is spent on documenting and more • Project progress is highly dependent
time is given for designing. upon the risk analysis phase.
• One can get reliable user feedback, when presenting sketches
and blueprints of the product to users for their feedback.
 Risk Driven Approaches/Model
• As digital systems become part of everyday life for most of us that caused increase
in the development of software systems and applications hugely. The increasing
number also shows the worries of developers for risk of failure for different stages
of the development and different platforms including web. The management of risk
is very important factor to be considered for all software development processes.
• The risk-driven model guides developers to apply a minimal set of architecture
techniques to reduce their most pressing risks.
• It suggests a relentless questioning process: “What are my risks? What are the best
techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?”
• The Risk-Driven Model allows developers to design architecture by identifying their
most common risks and applying only architecture and design techniques that
mitigate them.
• The main element of the Risk-Driven Model is the promotion of risk to prominence.
It is possible to apply the Risk-Driven Model to essentially any software development
process, such as waterfall or agile, while still keeping within its spirit.

19

• To address failure risks, the earliest software developers invented design

techniques, such as domain modeling, security analyses, and
encapsulation that helped them build successful software
• The risk-driven model can be summarized in three steps:
– 1. Identify and prioritize risks
• Experienced developers have an easy time identifying risks, but what can be done if the
developer is less experienced or working in an unfamiliar domain?-Requirements
• Categorized risk by giving priority to stakeholders and their perceived difficulty by
developers.
– 2. Select and apply a set of techniques
• SWOT analysis, prototyping,etc.
– 3. Evaluate risk reduction
• If you have <a risk>, consider <a technique> to reduce it.
• To avoid wasting your time and money, you should choose architecture
techniques that best reduce your prioritized list of risk.

20
• Spiral Model:
– The spiral model is a risk-driven where the process is represented as spiral
rather than a sequence of activities.
– The spiral model was originally proposed by Boehm in 1988.
– In this model, process is represented as a spiral rather than as a sequence
of activities with backtracking from one activity to another.
– Each loop in the spiral represents a phase in the process.
– No fixed phases such as specification or design - loops in the spiral are
chosen depending on what is required
– Risks are explicitly assessed and resolved throughout the process
– It was designed to include the best features from the waterfall and
prototyping models, and introduces a new component; risk-assessment.

Structure/phases
• Determine Objectives, alternatives and Constraints: (Specific objectives for
the phase are identified)
– Objectives: functionality, performance, hardware/software interface, critical
success factors, etc.
– Alternatives: build, reuse, buy, sub-contract, etc.
– Constraints: cost, schedule, interface, etc.
• Evaluate alternatives ,identify, resolve risks: Risks are assessed and
activities put in place to reduce the key risks)
– Study alternatives relative to objectives and constraints
– Identify risks (lack of experience, new technology, tight schedules, poor process,
etc.
– Resolve risks (evaluate if money could be lost by continuing system development
• Development and validation: A development model for the system is
chosen which can be any of the generic models
– After risk evaluation, a development model for the system is chosen
which can be any generic model. After risk evaluation, a process model
for the system is chosen. So if the risk is expected in the user interface
then we must prototype the user interface. If the risk is in the
development process itself then use the waterfall model.
• Planning for next step: (The project is reviewed and the next phase of the
spiral is planned)
– The project is reviewed and a decision made whether to continue with a further
loop of the spiral. If it is decided to continue, plans are drawn up for the next phase
of the project.
– Develop various types of plan like project plan, configuration management
plan,test plan, installation plan etc.
 SpiralDisadvantages
model
Advantages
• The model requires expertise in risk management
• The model tries to resolve all possible risks involved and excellent management skills.
in the project starting with the highest risk.
• Time spent for evaluating risks too large for small
• Provides early indication of insurmountable risks, or low-risk projects
without much cost
• Time spent planning, resetting objectives, doing
• Users see the system early because of rapid risk analysis and prototyping may be excessive
prototyping tools
• The model is complex
• Critical high-risk functions are developed first
• Spiral may continue indefinitely
• The design does not have to be perfect
• Developers must be reassigned during non-
• Users can be closely tied to all lifecycle steps development phase activities
• Early and frequent feedback from users • May be hard to define objective, verifiable
• Cumulative costs assessed frequently milestones that indicate readiness to proceed
through the next iteration
When to use Spiral model?
• When creation of a prototype is appropriate • When costs and risk evaluation is important
• For medium to high-risk projects • Users are unsure of their needs
• Requirements are complex • New product line
Significant changes are expected(Research and Exploration)
• Long-term project commitment unwise because of potential changes to economic priorities

23

Rapid Application Development Model

 The Rapid Application Development (or RAD) model is based on prototyping and iterative model with
no (or less) specific planning.
 In RAD model, there is less attention paid to the planning and more priority is given to the
development tasks.
 It targets at developing software in a short span of time.
 RAD allows project managers and stakeholders to accurately measure progress and communicate in real
time on evolving issues or changes.
 The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development
is achieved by using component-based construction.
 If requirements are well understood and project scope is constrained, the RAD process enables a
development team to create a “fully functional system” within very short time periods (e.g., 60 to 90
days)
 RAD (Rapid Application Development) is a concept that products can be developed faster and of higher
quality through:
 Gathering requirements using workshops or focus groups
 Prototyping and early, reiterative user testing of designs
 The re-use of software components
 A rigidly paced schedule that refers design improvements to the next product version
 Less formality in reviews and other team communication
 RAD MODEL

Phases:
 Business modeling:
 The information flow among business functions is modeled in a way that answers the following questions:
 What information drives the business process?
 What information is generated? Who generates it?
 Where does the information go? Who processes it?
 Data modeling:
 The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the
business.
 The characteristics (called attributes) of each object are identified and the relationships between these objects defined.
 Process modeling:
 The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business
function.
 Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
 Application generation:
 RAD assumes the use of fourth generation techniques.
 Rather than creating software using conventional third generation programming languages the RAD process works to reuse existing
program components (when possible) or create reusable components (when necessary).
 In all cases, automated tools are used to facilitate construction of the software.
 Testing and turnover:
 Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time.
 However, new components must be tested and all interfaces must be fully exercised. Obviously, the time constraints imposed on a RAD
project demand “scalable scope”. If a business application can be modularized in a way that enables each major function to be completed in
less than three months, it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to
for
 When to use RAD Methodology?
 When a system needs to be produced in a short span of time (2-3 months)
 When the requirements are known
 When the user will be involved all through the life cycle
 When technical risk is less
 When a budget is high enough to afford designers for modeling along with the cost of automated tools for code
generation
 Advantages
 Flexible and adaptable to changes
 Makes use of reusable components, to decrease the cycle time
 It is useful when you have to reduce the overall project risk
 Due to code generators and code reuse, there is a reduction of manual coding
 Disadvantages
 Not Suitable for smaller Projects
 For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD
teams.
 If commitment is lacking from customers or developers, RAD projects will fail.
 RAD is not appropriate when technical risks are high. Heavy use of New technology requires high degree of
interoperability.

27

Agile methods
 Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of agile
methods.
 These methods:
 Focus on the code rather than the design
 Are based on an iterative approach to software development
 Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 The aim : reduce overheads in the software process (e.g. by limiting
documentation) and to be able to respond quickly to changing requirements without
excessive rework.
Agile Methodology
 AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software
development lifecycle of the project.
 Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning. The project
scope and requirements are laid down at the beginning of the development process. Plans regarding the number of
iterations, the duration and the scope of each iteration are clearly defined in advance.
 Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts from one to four weeks.
 The division of the entire project into smaller parts helps to minimize the project risk and to reduce the overall
project delivery time requirements.
 Each iteration involves a team working through a full software development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is demonstrated to the client.
 In the Agile model, both development and testing activities are concurrent, unlike the Waterfall model.
 Scrum and Kanban are two of the most widely used Agile methodologies.
 The agile software development emphasizes on four core values.
 Individual and team interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of
features; the final build holds all the features required by the customer.

Graphical Illustration of Agile model

Phases of Agile model
 Requirements gathering:
 In this phase, you must define the requirements. You should explain business opportunities and plan the
time and effort needed to build the project. Based on this information, you can evaluate technical and
economic feasibility.
 2. Design the requirements:
 When you have identified the project, work with stakeholders to define requirements. You can use the user
flow diagram or the high-level UML diagram to show the work of new features and show how it will
apply to your existing system.
 3. Construction/ iteration:
 When the team defines the requirements, the work begins. Designers and developers start working on
their project, which aims to deploy a working product. The product will undergo various stages of
improvement, so it includes simple, minimal functionality.
 4. Testing:
 In this phase, the Quality Assurance team examines the product's performance and looks for the bug.
 5. Deployment:
 In this phase, the team issues a product for the user's work environment.
 6. Feedback:
 After releasing the product, the last step is feedback. In this, the team receives feedback about the product and
works through the feedback.

 The most popular Agile methods include

 Rational Unified Process(RUP) (1994), Scrum (1995), Crystal Clear, Extreme Programming
(1996), Adaptive Software Development, Feature Driven Development, and Dynamic
Systems Development Method (DSDM) (1995).
 Agile Manifesto:
 Individuals and interactions − In Agile development, self-organization and motivation
are important, as are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of just
depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to change − Agile Development is focused on quick responses to change and
continuous development.
  Agile Principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant
pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity -- the art of maximizing the amount of work not done -- is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

 When to use agile?

 When frequent changes are required.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with a software team all the time.
 When project size is small to medium size.

Agile methodology
Advantages Disadvantages
 Is a very realistic approach to software development.  Not suitable for handling complex dependencies.
 Promotes teamwork and cross training.  More risk of sustainability, maintainability and
 Functionality can be developed rapidly and demonstrated. extensibility.
 Resource requirements are minimum.  An overall plan, an agile leader and agile PM practice is
 Suitable for fixed or changing requirements a must without which it will not work.
 Delivers early partial working solutions.  Depends heavily on customer interaction, so if
customer is not clear, team can be driven in the wrong
 Good model for environments that change steadily. direction.
 Minimal rules, documentation easily employed.  Transfer of technology to new team members may be
 Enables concurrent development and delivery within an overall quite challenging due to lack of documentation.
planned context.  Due to the shortage of formal documents, it creates
 Little or no planning required. confusion and crucial decisions taken throughout
 Easy to manage. various phases can be misinterpreted at any time by
 Gives flexibility to developers thus reducing development time. different team members.
 Frequent Delivery  Due to the lack of proper documentation, once the
 Face-to-Face Communication with clients. project completes and the developers allotted to
another project, maintenance of the finished project
 Efficient design and fulfils the business requirement. can become a difficulty.
 Anytime changes are acceptable.
Extreme Programming(XP)
 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.
 XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a software
 When XP is applicable?
 Dynamically changing software requirements
 Risks caused by fixed time projects using new technology
 Small, co-located extended development team
 The technology you are using allows for automated unit and functional tests
 What are the values of XP?
 Communication
 face to face discussion with the aid of a white board or other drawing mechanism;
 must be in communication with each other at all times
 Simplicity
 address only the requirements that you know about; don’t try to predict the future
 Feedback
 builds something, gathers feedback on your design and implementation, and then adjust your product going forward.
 Courage
 effective action in the face of fear
 Respect
 respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to
identify simple designs and solutions.

Why Extreme?
 Advantages Disadvantages
 Lightweight methods suit small-medium size projects.  Difficult to scale up to large projects
 Produces good team cohesion. where documentation is essential.
 Emphasizes final product.  Needs experience and skill if not to
 Iterative. degenerate into code-and-fix.
 Test based approach to requirements and quality assurance.
 Close contact with the customer
 No unnecessary programming work
 Stable software through continuous testing
 Error avoidance through pair programming
 Changes can be made at short notice

Extreme programming practices (a)

Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’. See Figures 3.5 and
3.6.

Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally add
functionality to the first release.

Simple design Enough design is carried out to meet the current requirements and no more.

Test-first development An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable.
 Extreme programming practices (b)
Pair programming Developers work in pairs, checking each other’s work and providing the support to
always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that no islands of
expertise develop and all the developers take responsibility for all of the code.
Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into the whole system.
After any such integration, all the unit tests in the system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is
often to reduce code quality and medium term productivity

On-site customer A representative of the end-user of the system (the customer) should be available
full time for the use of the XP team. In an extreme programming process, the
customer is a member of the development team and is responsible for bringing
system requirements to the team for implementation.

Scrum
 Scrum is a process framework that has been used to manage complex product
development since the early 1990s.
 Scrum is not a process or a technique for building products; rather, it is
a framework within which you can employ various processes and techniques.
 Scrum makes clear the relative efficacy of your product management and
development practices so that you can improve.
 The Scrum framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules.
Scrum
 Scrum is an agile method that focuses on managing iterative development rather than
specific agile practices.
 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.
 There are three phases in Scrum.
 The initial phase is an outline planning phase where you establish the general objectives for the
project and design the software architecture.
 This is followed by a series of sprint cycles, where each cycle develops an increment of the
system.
 The project closure phase wraps up the project, completes required documentation such as
system help frames and user manuals and assesses the lessons learned from the project.


Scrum terminology (a)

Scrum term Definition
Development team A self-organizing group of software developers, which should be no
more than 7 people. They are responsible for developing the software
and other essential project documents.
Potentially shippable The software increment that is delivered from a sprint. The idea is that
product increment this should be ‘potentially shippable’ which means that it is in a finished
state and no further work, such as testing, is needed to incorporate it
into the final product. In practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They
may be feature definitions for the software, software requirements,
user stories or descriptions of supplementary tasks that are needed,
such as architecture definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify
product features or requirements, prioritize these for development and
continuously review the product backlog to ensure that the project
continues to meet critical business needs. The Product Owner can be
but might also be a product manager in a software
company or other stakeholder representative.
 Scrum terminology (b)
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of
as a project manager. Others, however, may not always find it easy to
see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover in
a single sprint. Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for measuring
improving performance.

Scrum sprint cycle

 The Scrum sprint cycle
 Sprints are fixed length, normally 2–4 weeks.
 The starting point for planning is the product backlog, which is the list of work to be done
on the project.
 The selection phase involves all of the project team who work with the customer to select
the features and functionality from the product backlog to be developed during the sprint.
 Once these are agreed, the team organize themselves to develop the software.
 During this stage the team is isolated from the customer and the organization, with all
communications channelled through the so-called ‘Scrum master’.
 The role of the Scrum master is to protect the development team from external
distractions.
 At the end of the sprint, the work done is reviewed and presented to stakeholders. The
next sprint cycle then begins.

Scrum benefits
 The product is broken down into a set of manageable and understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and consequently team communication
is improved.
 Customers see on-time delivery of increments and gain feedback on how the
product works.
 Trust between customers and developers is established and a positive culture is
created in which everyone expects the project to succeed.
Other Various types of Software Process Model
 Build and Fix model(ad-hoc model)
 Product is constructed without specifications or any
attempt at design
 Adhoc approach and not well defined
 Simple two phase model:
 Build: In this phase, the software code is developed and passed on
to the next phase.
 Fix: In this phase, the code developed in the build phase is made
error free
 Suitable for small programming exercises of 100 or 200
lines
 Unsatisfactory for software for any reasonable size
 Code soon becomes unfixable & not enhanceable
 No room for structured design
 Maintenance is practically not possible

Rational Unified Process(RUP)

 Rational Unified Process (RUP) is a software development process for object-oriented models. It is
also known as the Unified Process Model.
 Developed by I.Jacobson, G.Booch and J.Rumbaugh.
 Software engineering process with the goal of producing good quality maintainable software within
specified time and budget.
 Developed through a series of fixed length mini projects called iterations.
 Maintained and enhanced by Rational Software Corporation and thus referred to as Rational Unified
Process (RUP).
 The Rational Unified Process (RUP) is iterative, meaning repeating; and agile. Iterative because all of
the process’s core activities repeat throughout the project. The process is agile because various
components can be adjusted, and phases of the cycle can be repeated until the software meets
requirements and objectives.
 RUP reduces unexpected development costs and prevents wastage of resources.
 RUP has the following key characteristics:
 Use-case driven from inception to deployment
 Architecture-centric, where architecture is a function of user needs
 Iterative and incremental, where large projects are divided into smaller projects
 Phases of RUP:

• Inception: (The core idea is envisioned) Fig: Initial Development and Evolution Cycle of
▪ defines scope of the project. RUP
• Elaboration: (Use cases and Architecture are designed)
▪ How do we plan & design the project?
▪What resources are required?
▪What type of architecture may be suitable?
• Construction: (Activities from design to completed products)
▪ the objectives are translated in design & architecture
documents.
• Transition : (Follow up activities to ensure customer satisfaction)
▪ involves many activities like delivering, training,
supporting, and maintaining the product.

 Advantages
 It allows you to deal with changing requirements regardless of whether they are coming
from the customer or from the project itself.
 It emphasizes the need for accurate documentation.
 It forces integration to happen throughout the software development, more specifically
in the construction phase.
 Disadvantages
 It mostly relies on the ability of experts and professionals to assign the activities to
individuals who should then produce pre-planned results in the form of artifacts.
 The integration in development process can also have an adverse impact on some more
fundamental activities during the stages of testing
Incremental Process model
• The incremental model combines the elements of waterfall
model and they are applied in an iterative fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the
customer for any suggested modifications.
• The next increment implements on the customer's suggestions
and add additional requirements in the previous increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed using
the incremental model.
• Advantages of incremental model:
• This model is flexible because the cost of development is low and initial
product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the software
life cycle.
• The customers can respond to its functionalities after every increment.
• Disadvantages of the incremental model:
• The cost of the final product may cross the cost estimated initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is broken
into small increments.
• The demands of customer for the additional functionalities after every
increment causes problem during the system architecture.

Evolutionary development Model

• Evolutionary model is based on the idea of developing an initial implementation, exposing to this to user
comment and refining it through many versions until an adequate system has been developed.
• Specification, development and validation activities are interleaved rather than separate, with rapid
feedback across activities.
• Evolutionary models are iterative. They are characterized in a manner that enables software engineers to
develop increasingly more complete versions of the software.
• Evolutionary process model resembles iterative development model.
• The same phases as defined for the waterfall model occur here in a cyclical fashion.
• This model differs from iterative development model in the sense that this does not require a useable
product at the end of each cycle.
• Eg. In simple database application one cycle might implement the graphical user interface, another file
manipulation, another queries, and another updates. All four cycles must complete before there is working
product available.
• In evolutionary development, requirements are implemented by category rather than by priority.
• This model is useful for projects using new technology that is not well understood.
• This is also used for complex projects where all functionality must be delivered at one time, but the
requirements are unstable or not well understood at the beginning.

52
Types:
1. Exploratory development:
Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood
requirements
2.Throw-away prototyping:
Objective is to understand the system requirements. Should start with poorly understood requirements

53

Advantages/Disadvantages of evolutionary development

• Advantages • Disadvantages
• An evolutionary approach is often • The process is not visible: Managers
more effective than waterfall need regular deliverables to measure
approaches in producing systems that progress. If systems are developed
meet the immediate needs of quickly, it is not cost-effective to
customers. produce documents that reflect every
• The advantage of software process version of the system.
that is based on an evolutionary • Systems are often poorly structured:
approach is that the specification can Continual change tends to corrupt the
be developed incrementally. software structure. Incorporating
• As users develop a better software changes becomes
understanding of their problem, this increasingly difficult and costly.
can be reflected in the software • Special Skills may be required
system.

54