System 

Development Methods
CT00046‐3‐2

Process Oriented Methodologies
 Topic & Structure of the Lesson

 Principles of the process‐oriented methodologies. 
 Rapid Application Development (RAD) 
 Rational Unified Process (RUP) 
 SCRUM 
 Extreme Programming (XP) 
 Spiral Methods
 The strengths and weaknesses of the process‐oriented 
methodologies

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 2

 Slide 3 (of 17)

Learning Outcomes

By the end of this lecture, you should be able to :
1. Identify and explain the underlying principles of the process‐
oriented methodologies.
2. Describe the phases in the process‐oriented methodologies
3. Describe the strengths and weaknesses of the process‐
oriented methodologies

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 3

 Slide 4 (of 17)

Key Terms you must be able to use

If you have mastered this topic, you should be able to use the 
following terms correctly in your assignments and exams:
Process Oriented Methodologies
Rapid Application Development (RAD) 
Rational Unified Process (RUP) 
SCRUM 
Extreme Programming (XP) 
Spiral Methods

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 4

 Process Oriented Methodologies 
Principles

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 5

 Process Oriented Methodologies

 The proposed methodology can be applied to complex and 
distributed business processes.
 The business process is converted into functions in a system.
 Steps of Methods:
– Business process is studied
– Processes and tasks are broken down into smallest 
workable components.
– Each sub‐process can be assigned a time, cost and 
resources for it to complete.
– This can be shown in planning charts such as Gantt Chart, 
PERT Chart, Task Breakdown Structure, etc.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 6

 Rapid Application Development (RAD) 

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 7

 Rapid Application Development (RAD)

 ‘Fast’ methodology for fast / urgent projects

– Within days / weeks
 Rapid application development (RAD) is a team‐based
technique that speeds up information systems development
and produces a functioning information system.
 Companies use RAD to reduce cost and development time
and increase the probability of success.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 8

 Rapid Application Development (RAD)
Phases 

 The four phases of the RAD model are requirements analysis

and quick design, prototype cycles, testing, and
deployment.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 9

 Rapid Application Development (RAD)
Phases (continued)

 Analysis and Design
 Users, managers, and IT staff members discuss and agree on
business needs, project scope, constraints, and system
requirements. The requirements planning phase ends when
the team agrees on the key issues and obtains management
authorization to continue.
 During the design, users interact with systems analysts and
develop models and prototypes that represent all system
processes, outputs, and inputs. The RAD group or subgroups
typically use a combination of JAD techniques and CASE tools
to translate user needs into working models.
 Joint application development (JAD) is a technique that brings
users into the development process as active participants.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 10

 Rapid Application Development (RAD)
Phases (continued)

 Prototypes Cycles
 Develop
• Focuses on program and application development tasks.
Users continue to participate and still can suggest changes or
improvements as actual screens, or reports are developed.
• Development is a continuous, interactive process that allows
users to understand, modify, and eventually approve a
working model of the system that meets their needs.
 Demonstrate and Refine
• Developers demonstrate the progress and gather feedback
from users to improve prototypes and create the best
possible product.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 11

 Rapid Application Development (RAD)
Phases (continued)

 Test
– This step requires developers to test the software product and
ensure that all parts work together as per client’s expectations.
– Continue incorporating client feedback as the code is tested and
retested for its smooth functioning.
 Deployment
– This phase resembles the final tasks in the SDLC implementation
phase, including data conversion, user acceptance testing,
changeover to the new system, and user training.
– Compared with traditional methods, the entire process is
compressed. As a result, the new system is built, delivered, and
placed in operation much sooner.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 12

 Rapid Application Development (RAD)
Techniques

 Expert developers used.

 Uses tools (CASE Tools) for faster development and testing.
 CASE tools are powerful software used in computer‐aided
systems engineering to help systems analysts develop and
maintain information systems e.g., construction tools, data
dictionaries and, documentation tools.
 Uses minimal planning, analysis and documentation
 Uses Prototype for user feedback and review
 Users are involved in development

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 13

 Rapid Application Development (RAD)
Techniques (continued)

 Iterative and Incremental design approach with prototyping

 A system is developed through repeated cycles and in smaller
portions at a time.
 Build a series of prototypes and constantly adjusting them to
user requirements.
 Allows developers to take advantage of what was learned
during the development of earlier parts or versions of the
system.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 14

 Rapid Application Development (RAD)
Advantages and Disadvantages

 Advantages
 Systems can be developed more quickly with significant cost savings. 
 Cut development time and expense by involving users in every phase 
of systems development. 
 Because it is a continuous process, RAD allows the development team 
to make necessary modifications quickly, as the design evolves. 
 Disadvantages
 RAD stresses the mechanics of the system itself and does not 
emphasize the company’s strategic business needs. 
 The risk is that a system might work well in the short term, but the 
corporate and long‐term objectives for the system might not be met. 
 The accelerated time cycle might allow less time to develop quality, 
consistency, and design standards. 
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 15
 Rational Unified Process (RUP)

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 16

 Rational Unified Process (RUP)

 Originally developed by Booch, Rumbaugh, and Jacobson, who

previously developed UML at Rational Software (now part of
IBM).
 The RUP is now widely recognized as a highly influential
innovation in software development methodologies for
object‐oriented development using an adaptive approach.
 The original version of RUP defined an elaborate set of
activities and deliverables for every step of the development
process.
 More recent versions are streamlined, with fewer activities
and deliverables, simplifying the methodology.
 Much of the book’s methodology is loosely based on the
Unified Process (in an agile form).

17

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 17

 Rational Unified Process (RUP)
(continued)

 “plan a little, design a little, and code a little”

 Very careful development method, emphasis on quality of
product and process.
 Extensive and exclusive use of UML, and direct support for
Object‐Oriented Programming.
 Takes a holistic approach of the system:
 Architecture of the system determined
 Tasks are broken‐down into smaller components.
 Iterative & incremental approach applied to do all tasks.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 18

 Rational Unified Process (RUP)
Life Cycle

 The RUP Process Life Cycle model includes iterations and

phases.
 Each RUP phase is made up of iterations. The phases are
Inception, Elaboration, Construction, and Transition.

19

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 19

 Rational Unified Process (RUP)
Life Cycle (continued)

 Inception Phase: the basic idea and structure of the project

are determined.
 Elaboration Phase: to analyze the requirements and
necessary architecture of the system
 Construction Phase: when the coding and implementation
will take place.
 Transition Phase: when the finished product is finally released
and delivered to customers, also handle all post‐release
support, bug fixes, patches, and so forth.

20

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 20

 Rational Unified Process (RUP)
Disciplines 

 RUP Disciplines – a set of functionally related activities that

combine to enable the development process in a UP project
(each like a core development process):
 Business modeling
 Requirements
 Design
 Implementation
 Testing
 Deployment
 Configuration and change management
 Project management
 Environment 21

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 21

 Rational Unified Process (RUP)
Phases

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 22

 Rational Unified Process (RUP)
Phases (continued)

 All aspects of the RUP are based on a set of building blocks, which
are used to describe:
 ‘Who’ – Project member: an individual, or a group of
individuals together as a team, working on any activity in order
to produce artifacts.
 ‘What’ ‐ Artifacts: An artifact represents any tangible output
from the process e.g., design specification.
 ‘How’ ‐ Activities: A unit of work that a project member is to
perform. Activities should have a clear purpose, typically by
creating or updating artifacts.
 ‘When’ ‐ Workflows: Represents a sequence of activities, in
order to produce artifacts.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 23
 Rational Unified Process (RUP)
Phases (continued)
 Business Modeling:
 the business context (scope) of the project should be outlined.
 Requirements
 to define all potential requirements of the project, throughout the
software development life cycle.
 Analysis & Design ‐ transforms requirements into a design that can be
properly implemented.
 Implementation
 where most actual coding takes place, implementing and organizing
all the code that make up the whole of the system.
 Test ‐ perform various Testing
 Deployment
 constitutes the entire delivery and release process, to ensure that
the system meets customer’s expectations.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 24
 Rational Unified Process (RUP)
Phases (continued)

 Configuration & Change Management Workflow:

 Describe the various artifacts produced by the development team.
 Make sure that there is minimal overlap or wasted efforts
performing similar activities that result in identical or
conflicting artifacts.
 Project Management :
 Where all activities dealing with project management, from
pushing design objectives, risk management, overcoming delivery
constraints.
 Environment :
 Handles the setup and management of all software development
cycle, including the processes, tools, and team members
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 25
 Rational Unified Process (RUP)
Practices

Focuses early and often on users

Use case driven
Model driven – uses UML exclusively
Iterative, but provides management structure by
defining phases
Focuses on defining an architecture
Adaptable to the needs of a specific project
Can be made highly agile, but originally had heavy
ceremony
26

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 26

 SCRUM

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 27

 Scrum

 Another influential agile, iterative development methodology 
based on ideas from Rugby.
 A ‘team‐work’ based methodology.
 A Scrum begins quickly, is a very intense effort, involves the 
entire team, and usually only lasts for a short duration
 Scrum philosophy is the complete control a team exerts over 
its own organization and its work processes. Software is 
developed incrementally, and controls are imposed 
empirically—by focusing on things that can be accomplished.

28

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 28

 Scrum 
Organization
 User Stories/Inputs – developer & user determine general concepts.
 Product backlog – a prioritized list of user requirements used to 
choose work to be done in a Scrum project
 Only a few of the high‐priority items are worked on at a time
 Sprint Backlog is a subset of items from the product backlog that have 
been selected to be part of a Sprint.
 Product owner – the client stakeholder for whom the system is being 
built, responsible for business requirements, project backlog and 
priorities.
 Scrum master – the person in charge of a Scrum project—similar to a 
project manager, helps to solve the ‘gaps’ in the project such as 
solving problems or giving ideas.
 Scrum team is usually 5 to 9 people, from mixed skills.
 Scrum team sets own goals, organizes self, makes decisions 29

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 29

 Scrum 
Practices
 Sprint – a time‐controlled mini‐project that implements a 
specific portion of a system
 Firm 30‐day time box with a specific goal or deliverable
 The scope of that sprint is then frozen, and no one can 
change it—neither the product owner nor any other users
•Sprint backlog defines the scope
 Daily Scrum – a daily meeting of all members of the team to 
report progress (15 minutes max)
 Sprint final half‐day review meeting – scheduled to review and 
identify changes needed for the following sprints

30

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 30

 Scrum Methodology

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 31

 Scrum Methodology
SCRUM ceremonies that must take place. 

 Sprint Planning: This is where the team meets and decides

what they need to complete in the coming sprint
 This ceremony helps to set up the entire team for the
coming sprint, creating a smooth pathway for a
successful sprint.
 Sprint planning requires the participation of all the scrum
roles: the development team, scrum master and the
product owner.
 The planning, of course, is prior to the sprint. It typically
lasts for an hour or two.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 32

 Scrum Methodology
SCRUM ceremonies that must take place (continued)

 Daily Scrum: This is a standup meeting or a very short – 15‐

minute mini‐meeting – for the team to make sure they’re all
on the same page.
 It’s a way to ensure transparency across the team.
 Daily scrum demands accountability

 Sprint Review: This is another type of meeting, but one in

which the team demos what they shipped in the sprint.
 Demonstrates the finished work for the entire team, so
they can provide feedback and get feedback
from the stakeholders in the project.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 33
 Scrum Methodology
SCRUM ceremonies that must take place (continued)

 Sprint Retrospective: This is when the team reviews their

work, identifying what they did well and what didn’t go as
planned, so they can make the next sprint better.
 Because scrum is part of an agile process, it is all about
change, which includes getting feedback and quickly
acting on it.
 Scrum seeks continuous improvement, and the
retrospective is a method to make sure that the product
and development culture is constantly improving.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 34

 Extreme Programming (XP)

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 35

 Extreme Programming (XP)

 Very flexible methodology.
 Effective Programming / 
coding approach.
 For projects involving  
heavy coding / software 
building
 Uses most of the Agile 
Principles

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 36

 Extreme Programming (XP)
Core Values

 Communication—one of the major causes of project failure is

a lack of open communication among the right players at the
right time and at the right level
 Simplicity—XP includes techniques to reinforce keeping things
simple to make it a standard way of developing systems
 Feedback—as with simplicity, getting frequent, meaningful
feedback is recognized as a best practice of software
development
 Courage—developers always need courage to face the harsh
choice of doing things right or throwing away bad code and
starting over

37

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 37

 Extreme Programming (XP)
Practices

 Planning—XP planning focuses on making a rough plan quickly

and then refining it as things become clearer. This reflects the
Agile development philosophical dictum that change is more
important than detailed plans
 Testing—XP intensifies testing by requiring that the tests for
each use case (story) be written first—before the solution is
programmed
 Pair Programming—XP practice in which two programmers
work together on designing, coding, and testing software
 Simple Designs—XP conforms to the principles of Agile
Modeling. It accomplishes the desired result with as few
classes and methods as possible and that doesn’t duplicate
code
38

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 38

 Extreme Programming (XP)
Practices (continued)

 Refactoring the Code— refactoring is the technique of

improving the code without changing what it does. XP
programmers continually refactor their code to achieve a
simpler design
 Owning the Code Collectively —in XP, everyone is responsible
for the code. Collective ownership allows anyone to modify
any piece of code.
 Continuous Integration —this practice embodies XP’s idea of
“growing” the software. Small pieces of code—which have
passed the unit tests—are integrated into the system daily or
even more often
 On‐Site Customer —as with all adaptive approaches, XP
projects require continual involvement of users who can make
business decisions about functionality and scope 39

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 39

 Extreme Programming (XP)
Practices (continued)

 System Metaphor —a system metaphor should be easily

understood and well known to the members of the
development team. It can guide members toward a vision and
help them understand the system
 Small Releases —consistent with the entire philosophy of
growing the software, small and frequent releases provide
upgraded solutions to the users and keep them involved in the
project
 Forty‐Hour Week — the exact number of hours a developer
works are not the issue. The issue is that the project shouldn’t
be a death march that burns out every member of the team
 Coding Standards —developers should follow standards for
coding and documentation
40

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 40

 XP Activities:

Project Activities

Release Activities

Iteration Activities

41

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 41

 Extreme Programming (XP)
Techniques

 Small and frequent "releases" in short development cycles

 Development team – fully integrated
 Pair programming, stand‐up meetings
 Test driven development
 Close user involvement , testing
 Accept changing requirement at any time
 Simplicity in everything
 Tries to simplify all processes
 Produce high quality software.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 42

 Extreme Programming (XP)
Techniques (continued)

 Pair Programming
 Where two developers work using only one machine. 
 Each one has a keyboard and a mouse. 
 One programmer acts as a main driver who codes, while 
the other will serve as an observer who will check the 
code being written, proofread and spell check, while 
also figuring out where to go next. 
 These roles can be switched at any time.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 43

 SPIRAL

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 44

 Spiral Methods

 Spiral models initially were suggested in the 1990s by Barry Boehm, 
a noted software engineering professor. He stated that each 
iteration, or phase, of the model must have a specific goal that is 
accepted, rejected, or changed by the user, or client. 
 Thus, which enable the team to reach the overall project goal.
 Typically, each iteration in a spiral model includes planning, risk 
analysis, engineering, and evaluation.
 “Risk‐driven” process model. The next steps to be done is 
determined based on the ‘Risk’ pattern. 
 For projects which have high risk:
 Unclear / unfixed requirements
 Projects have too many independent components
 Projects have too many stakeholders which don’t agree with things.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 45

 Spiral Methods
Phases

Planning Risk Analysis

Evaluation
Engineering

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 46

 Spiral Methods
Phases (continued)

 Planning Phase
 Define objectives, constraints, and deliverables
 Risk Analysis
 Identify risks and develop acceptably resolutions
 Engineering Phase
 Develop a prototype that includes all deliverables and perform 
integration.
 Various functional testing was carried out.
 Evaluation phase
 Deploy system at the user’s site and perform assessment and 
user testing to develop objectives for the next iteration.
 Allows users to evaluate the output of the project to date before 
the project continues to the next spiral.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 47
 • Watch the following video about the phase in Spiral 
methods:
• Spiral Methods 

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 48

 Strengths and Weaknesses

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 49

 Strengths
In General

• Speeds up system development and delivers precisely what the 
customer wants, when the customer wants it, while fostering 
teamwork and empowering employees.
• Attempt to develop a system incrementally, by building a series of 
prototypes and constantly adjusting them to user requirements.
• Each iteration has a deliverable. 
– Often, each iteration also integrates a new piece into the growing total 
system. 
– Within each iteration, the new pieces are tested by themselves and as 
integrated with the rest of the system. 
– The users also get involved in testing the system’s ability to meet their 
business needs. 
– Hence, testing and quality control are spread across the entire project 
and usually provide a better‐tested and more robust system.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 50
 Weaknesses
In General

• The project scope isn’t well understood and that there will be many 
changes, updates, and refinements to the requirements as the 
project progresses. 
• Without a detailed set of system requirements, certain features 
requested by some users might not be consistent with the 
company’s larger game plan.
• Include weak documentation, blurred lines of accountability, and 
too little emphasis on the larger business picture.
• A long series of iterations might add to project cost and 
development time. 
• May not work as well for larger projects because of their complexity 
and the lack of focus on a well‐defined product.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 51

 Summary

 Process‐oriented methodologies can be applied to complex and distributed 
business processes where the business process is converted into functions in 
a system.
 RAD and RUP use iterative and incremental design approaches with 
prototyping, where a system is developed through repeated cycles and in 
smaller portions at a time, building a series of prototypes, and constantly 
adjusting them to user requirements.
 SCRUM is a teamwork methodology and has four essential ceremonies 
include sprint planning, daily meeting, sprint review, and sprint 
retrospective.
 XP releases small and frequent progress with a fully integrated development 
team to produce high‐quality software. It accepts changing requirements at 
any time, tries to simplify all processes.
 The Spiral is suitable for projects which have high risk where unclear 
requirements, projects that have too many independent components, and 
too many stakeholders who don’t agree with things.
CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 52
 Criteria RUP RAD SCRUM XP SPIRAL Method
Iterative and  Iterative and  Iterative and  Iterative and 
Development Iterative and Spiral
Incremental Incremental Incremental Incremental
Adaptive and  Risk‐Driven and 
Process Prescriptive Agile Agile
flexible Adaptive
Phases Four phases Three phases Three phases Five phases Four phases
Risk management 
Developer‐
Focus Process‐oriented Business‐oriented Team‐oriented and continuous 
oriented
improvement
Long cycles (4‐6  Short cycles (2‐4  Time‐boxed (2‐4  Time‐boxed (1‐3  Time‐boxed and 
Time
months) months) weeks) weeks) risk‐driven
Prioritized and  User stories and  Continuous risk 
Gathered and 
Requirements Prototyped Managed in a  frequent customer  analysis and 
Analyzed
Product Backlog interaction adaptation

Working software  Re‐evaluation of 
Detailed  Working 
Deliverables Working software and automated  project risks and 
documentation Prototypes
tests development plan
Roles for cross‐ Roles for cross‐ Roles for cross‐
Roles for  Roles for 
Team roles functional team  functional team  functional team 
specialists generalists
members members members
Frequent 
Pair programming 
Formal and  Informal and  Daily stand‐up  communication 
Communication and frequent 
structured flexible meetings and feedback from 
communication
stakeholders
Embraces change  Continuous risk 
Change  Controlled and  Responds to 
Embraces change and continuous  analysis and 
management documented change quickly
improvement adaptation
Emphasizes test‐
Emphasizes best  Emphasizes time‐ Emphasizes  Emphasizes risk 
driven 
Engineering practices and  to‐market and  delivering value to  analysis and 
development and 
standards quality customer adaptation
coding standards

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 53

 Question & Answer

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 54

 Next Session

• People Oriented Methodologies 

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 55

 References

 Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2015). Systems 
Analysis and Design in A Changing World. Cengage learning.
 Martin, R. C., Newkirk, J., & Koss, R. S. (2003). Agile 
Software Development: Principles, Patterns, and 
Practices (Vol. 2). Upper Saddle River, NJ: Prentice Hall.

CT046-3-2 – SYSTEM DEVELOPMENT METHODS Slide 56