RMIT Classification: Trusted

Process Model
ISYS2089 – Software Engineering Fundamental

Week 02
 RMIT Classification: Trusted

Overview
• Learning Outcomes
o CLO 1: explain and apply the main aspect of software
engineering
o CLO 2: evaluate requirements for a software system
• Purpose
o Understanding of the key concepts

• Topic Checklist
o Understand the different types of process model
o To be aware of process modeling to describe software
development processes explicitly
 RMIT Classification: Trusted

Objectives
• To be aware of a number of generic models to structure the software
development process

• To appreciate the pros and cons of these models, in particular those

of the classes of planning-driven and agile methods.

• To recognize that it is profitable to apply software product line

engineering when developing a series of similar systems.

• To be aware of process modelling as a way to describe software

development processes explicitly.

3
 RMIT Classification: Trusted

What is the Process Model

• A process model is a structured collection of
practices that describe the characteristics of
effective process.
• Many different software processes but all
involve:
• Specification – defining what the system
should do;
• Design and implementation – defining
the organization of the system and
implementing the system;
• Validation – checking that it does what the
customer wants;
• Evolution – changing the system in
response to changing customer
needs

4
 RMIT Classification: Trusted

How Is a Process Model Used?

A process model is used

• To help set process improvement objectives and priorities

• To help ensure stable, capable, and mature processes.

• As a guide for improvement of project and organizational

processes.

• With an appraisal method to diagnose the state of an

organization’s current practices.

5
 RMIT Classification: Trusted

Why Is a Process Model Important?

A process model provides

• A place to start improving.

• The benefit of a community’s prior experiences.

• A common language and a shared vision.

• A framework for prioritizing actions.

• A way to define what improvement means for an

organization.
6
 RMIT Classification: Trusted

Plan-driven (heavy) vs Agile (light)

Processes
• In Plan-driven processes all of the activities are
planned in advance and progress is measured against
this plan.
→ Plan drives everything!
• In Agile Processes planning is incremental and it is
easier to change the process to reflect changing
requirements.
• In practice, most practical processes include elements
of both plan-driven and agile. There are no right or
wrong software processes.
• What type of process would suit us for the assignment?

7
 RMIT Classification: Trusted

Common Process Models

▪ Process descriptions may also include:
o Products, which are the outcomes of a process activity
o Roles, which reflect the responsibilities of the people involved
o Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted.
▪ Common process models include:
o Code and Fix Model
o Waterfall model
o Spiral Model
o Iterative and incremental model
o Agile models (Scrum, XP, … )

8
 RMIT Classification: Trusted

Code and Fix Model

• Work from a brief specification of tasks

• Developers immediately translate tasks intocode.

• Testing is carried out after all development work is

completed
• Developers would have no idea if they were producing what the
customer wanted.
• Approach worked well for scientific applications and batched
programs where all development work is done by a single person.

• But this approach did not scale well for larger applications

• Need for better process models !

9
 RMIT Classification: Trusted

Waterfall

Follows a sequential, linear

process and is the most popular
version of the systems
development life cycle (SDLC)
for software engineering and IT
projects.
10
 RMIT Classification: Trusted

Advantages of Waterfall (1)

• Easy to use and manage: Because the Waterfall model follows the same
sequential pattern for each project, it is easy to use and understand. The team
doesn’t need any prior knowledge or training before working on a Waterfall
project. Waterfall is also a rigid model; each phase has specific deliverables
and review, so it’s easy to manage and control.

• Discipline is enforced: Every phase in Waterfall has a start and end point,
and it’s easy to share progress with stakeholders and customers. By
focusing on requirements and design before writing code, the team can reduce
the risk of a missed deadline.

11
 RMIT Classification: Trusted

Advantages of Waterfall (2)

• Requires a well documented approach: Waterfall

requires documentation for every phase, resulting in better
understanding of the logic behind the code and tests. It
also leaves a paper trail for any future projects or if
stakeholders need to see more detail about a certain
phase.

12
 RMIT Classification: Trusted

Disadvantages of Waterfall (1)

• Changes can’t be easily accommodated: Once the team completes
a phase, they can’t go back. If they reach the testing phase and realize
that a feature was missing from the requirements phase, it is very
difficult and expensive to go back and fix it.

• Software isn’t delivered until late: The project has to complete two to
four phases before the coding actually begins. As a result,
stakeholders won’t see working software until late in the life cycle.

13
 RMIT Classification: Trusted

Disadvantages of Waterfall (2)

• Gathering accurate requirements can be challenging: One of the
first phases in a Waterfall project is to talk to customers and
stakeholders and identify their requirements. However, it can be difficult
to pinpoint exactly what they want this early in the project. Often times,
customers don’t know what they want early on and instead, learn
and identify requirements as the project progresses.

14
 RMIT Classification: Trusted

What is Agile?

• A set of principles for software development under which

requirements and solutions evolve through the
collaborative effort of self-organizing cross functional
teams.

• Is an iterative approach to software delivery that builds

software incrementally from the start of the project, instead
of trying to deliver it all at once near the end.

15
 RMIT Classification: Trusted

Extra Info

What is Agile ?

What is Agile methodology ?

16
 RMIT Classification: Trusted

12 Principles of Agile Methodology

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.

17
 RMIT Classification: Trusted

12 Principles of Agile Methodology

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.

18
 RMIT Classification: Trusted

Advantages of Agile
• Change is embraced: With shorter planning cycles, it’s easy to accommodate and
accept changes at any time during the project. There is always an opportunity to
refine and reprioritize the backlog, letting teams introduce changes to the project in
a matter of weeks.

• End-goal can be unknown: Agile is very beneficial for projects where the end-goal
is not clearly defined. As the project progresses, the goals will come to light and
development can easily adapt to these evolving requirements.

• Faster, high-quality delivery. Breaking down the project into iterations

(manageable units) allows the team to focus on high-quality development, testing,
and collaboration. Conducting testing during each iteration means that bugs get
identified and solved more quickly. And the high-quality software can be delivered
faster with consistent, successive iterations.

19
 RMIT Classification: Trusted

Advantages of Agile
• Strong team interaction: Agile highlights the importance of frequent communication and
face-to-face interactions. Teams work together and people are able to take responsibility
and own parts of the projects.

• Customers are heard: Customers have many opportunities to see the work being
delivered, share their input, and have a real impact on the end product. They can gain a
sense of ownership by working so closely with the project team.

• Continuous improvement: Agile projects encourage feedback from users and team
members throughout the whole project, so lessons learned are used to improve future
iterations.

20
 RMIT Classification: Trusted

Disadvantages of Agile
• Planning can be less concrete: It can sometimes be hard to pin down a solid delivery date. Because
Agile is based on time-boxed delivery and project managers are often reprioritizing tasks, it’s possible
that some items originally scheduled for delivery may not be complete in time. And, additional sprints
may be added at any time in the project, adding to the overall timeline.

• Team must be knowledgeable: Agile teams are usually small, so team members must be highly
skilled in a variety of areas. They also must understand and feel comfortable with the chosen Agile
methodology.

• Time commitment from developers: Agile is most successful when the development team is
completely dedicated to the project. Active involvement and collaboration is required throughout the
Agile process, which is more time consuming than a traditional approach. It also means that the
developers need to commit to the entire duration of the project.

21
 RMIT Classification: Trusted

Disadvantages of Agile
• Documentation can be neglected: The Agile Manifesto prefers working software over
comprehensive documentation, so some team members may feel like it’s less important
to focus on documentation. While comprehensive documentation on its own does not
lead to project success, Agile teams should find the right balance between
documentation and discussion.

• Final product can be very different: The initial Agile project might not have a definitive
plan, so the final product can look much different than what was initially intended.
Because Agile is so flexible, new iterations may be added based on evolving customer

feedback, which can lead to a very different final deliverable.

22
 RMIT Classification: Trusted

Agile Development Cycle

23
 RMIT Classification: Trusted

Agile Development Cycle (1)

• Planning: Once an idea is deemed viable and feasible, the project team
comes together and works to identify features. The goal of this phase is to
break down the idea into smaller pieces of work (the features) then to
prioritize each feature and assign it to an iteration.

• Requirements analysis: This phase involves many meetings with

managers, stakeholders, and users to identify business requirements. The
team needs to gather information like who will use the product and how
they will use it. These requirements must be quantifiable, relevant, and
detailed.

24
 RMIT Classification: Trusted

Agile Development Cycle (2)

• Design: The system and software design is prepared from the requirements identified in
the previous phase. The team needs to think about what the product or solution will look
like. The test team also comes up with a test strategy or plan to proceed.

• Implementation, coding or development: This phase is all about creating and testing
features, and scheduling iterations for deployment (following the iterative and incremental
development approach [IID]). The development phase starts with iteration 0, because
there are no features being delivered. This iteration lays down the foundation for
development, with tasks like finalizing contracts, preparing the environments, and
funding.

25
 RMIT Classification: Trusted

Agile Development Cycle (3)

• Testing: Once the code has been developed, it is tested against the
requirements to make sure the product is actually solving customer needs and
matching user stories. During this phase, unit testing, integration testing,
system testing, and acceptance testing are done.

• Deployment: After testing, the product is delivered to customers for them to

use. However, deployment isn’t the end of the project. Once customers start
using the product, they may run into new problems that the project team will
need to address.

26
 RMIT Classification: Trusted

Popular Software Development

Process Models

Non-Agile Models Agile Models

• Waterfall • Scrum

• Rational Unified Process (RUP) • Extreme Programming (XP)

• V-model • Kanban

• Spiral Model • Agile Unified Process (AUP)

27
 RMIT Classification: Trusted

RUP

28
 RMIT Classification: Trusted

Phases
• Inception
o Initial scope, potential architecture, stakeholder
acceptance
• Elaboration
o Prove the systems architecture
• Construction
o Build working software, incremental basis, highest
priority first
• Transition
o Validate and deploy
 RMIT Classification: Trusted

Rational Unified Process (RUP)

• This methodology divides the development process into four distinct
phases that each involves Business Modelling, Analysis And Design,
Implementation, Testing, and Deployment.

• This is an object-oriented and web-enabled program development

methodology.

• This model also helps software developer for providing them

guidelines, templates, and examples for all aspects and stages of

software development.

30
 RMIT Classification: Trusted

Advantages of RUP
• This methodology emphasizes on accurate documentation

• It is proactively able to resolve the project risks that are associated with
the clients evolving requirements for careful changes and request
management

• Very less need for integration as the process of integration goes on

throughout the development process

31
 RMIT Classification: Trusted

Disadvantages of RUP
• The software developer needs to be expert in their work to develop
software under this methodology.

• The development process in this methodology is very complex and not

exactly organized.

• Integration throughout the process of software development adds the

confusion that causes more issues during the stages of testing.

• This process is too complex therefore it is very hard to understand.

32
 RMIT Classification: Trusted

V-Model

33
 RMIT Classification: Trusted

Spiral Model

34
 RMIT Classification: Trusted

Agile Unified Process (AUP)

http://www.youtube.com/watch?v=vmGMpME_phg&feature=related
 RMIT Classification: Trusted

Disciplines

• Model
o Understand business & problem domain
o Identify a viable solution

• Implementation
o Transform model(s) into executable code

• Test
o Ensure quality
o Verify that requirements are met
 RMIT Classification: Trusted

Disciplines

• Deployment
o Make system available to end users
• Configuration Management
o Manage access to project artifacts
o Control and manage changes
• Project management
o Managing risks, directing and coordinating people
• Environment
o Ensuring a proper process, guidance and tools
 RMIT Classification: Trusted

Releases

• Development release iteration

o Deployment to QA or demo area

• Production release iteration

o Deployment to production area

 RMIT Classification: Trusted

eXtreme Programming (XP)

Extreme Programming (XP) is a highly disciplined management method, 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.
 RMIT Classification: Trusted

eXtreme Programming (XP)

Taking proven practices to the extreme

• If testing is good, let everybody test all the time
• If code reviews are good, review all the time
• If design is good, refactor all the time
• If integration testing is good, integrate all the time
• If simplicity is good, do the simplest thing that
could possibly work
• If short iterations are good, make them really, really
short
 RMIT Classification: Trusted

Advantages of XP
• Extreme programming methodologies emphasis on customer
involvement

• This model helps to establish rational plans and schedules and to get
the developers personally committed to their schedules which are
surely a big advantage in the XP model

• This model is consistent with most modern development methods so,

developers are able to produce quality software

41
 RMIT Classification: Trusted

Disadvantages of XP
• Focused on the code rather than design. Lack of defect documentation
may lead to the occurrence of similar bugs in the future.

• Does not measure code quality assurance.

• Not the best option if the programmers are separated geographically.

42
 RMIT Classification: Trusted

Pair Programming

• Two people looking at one

machine, with one keyboard
and one mouse

• Two roles: implementation

and strategy

• All production code is written

in pairs
 RMIT Classification: Trusted

Kanban

• Video: https://www.youtube.com/watch?v=0xN4rrTaOEA

44
 RMIT Classification: Trusted

Scrum

• Video:
https://www.youtube.c
om/watch?v=vmGMp
ME_phg&ab_channel
=%C3%96rjanHillbom

45
 RMIT Classification: Trusted

Scrum Framework

Roles
Product Owner
Scrum Master
Team

Ceremonies
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting

Artifacts
Product backlog
Release backlog
Sprint backlog
Burndown charts
 RMIT Classification: Trusted

Scrum Roles
• Product Owner
❑ Possibly a Project Sponsor or Analyst
❑ Decides features, prioritise features, determines scope, cost

• Scrum Master
❑ Typically a Project Manager or Team Leader
❑ Responsible for enacting Scrum values and practices

❑ Remove impediments /politics, keeps everyone productive

• Project Team
❑ 5-10 members; Teams are self-organizing
❑ Cross-functional: QA, Programmers, UI Designers, etc.
❑ Membership should change only between sprints
 RMIT Classification: Trusted

Requirements with User

Stories
• Instead of Use Cases, Agile project owners do "user stories"

❑ Who (user role)

❑ What (goal)

❑ Why (reason)

• As a [user role], I want to [goal], so I can [reason]. Example:

❑ "Asa customer, I want to know the monthly repayment, so that I

can asses the affordability."
• Story points: Rating

❑ common scales: 1-10 (good for capturing relative complexity)

 RMIT Classification: Trusted
Product Backlog to Sprint
Backlogs
• Product backlog is a list of all desired
project features expressed as user stories

• User stories are assigned "story

points", such that each item has
value to users or customers

User stories from Product Backlog are

•
then then split into one or more Release
product backlog Backlogs based on priority by the
Product Owner.

• Release backlogs may form one or more

Sprint backlogs
 RMIT Classification: Trusted

Sprint Meeting

• Inputs
❑ Team capacity, Release backlog, Business needs, Current
product, appropriate technology

• Sprint Prioritization
❑ Evaluate Release backlog, Identify sprint goals
❑ Output: Sprint Goals

• Sprint Planning
❑ Decide steps to achieve sprint goal (design), Create sprint
backlog (tasks) from release backlog items (user stories),
Estimate sprint backlog in hours
❑ Output: Sprint Backlog
42
 RMIT Classification: Trusted

Daily Scrum Meeting

• Parameters
❑ Daily, ~15 minutes, Stand-up

• Not for problem solving

❑ Everyone is invited

❑ But only team members can talk

❑ Helps avoid time wasting

• Three questions answered by each team member:

❑ What did you do yesterday?

❑ What will you do today?

❑ What obstacles are in your way?

Copyright Dale Stanbrough 2009

 RMIT Classification: Trusted

Sample Product Backlog

Estimate
Backlog item (Story
Points or
hours)
Allow a customer to apply for a loan 3

As a customer, I want to know the loan repayment. 5

As a customer, I want to change the loan period. 3

As a manager, I can vary the interest rate 8

Improve interface 8
...
...
Copyright Dale Stanbrough 2009
 RMIT Classification: Trusted

Sprint Backlog

• Individuals choose the work tasks

❑Task is never assigned

• Estimated work remaining is updated daily

• Any team member can add, delete or change

• If work is unclear, define a sprint backlog item with
a larger amount of time and break it down later

53
 RMIT Classification: Trusted

Sample Sprint backlog

Tasks Mon Tue Wed Thu Fri

Code the front tier 14 8 4 2
Code the business logic 18 20 12 8 2
Test the front tier 8 10 8 8 4
Test the business logic 16 12 8 6 6
Web Design 12 6 8 2
Error Logging 6 2

Copyright Dale Stanbrough 2009

 RMIT Classification: Trusted

Sprint Burndown Chart

• A display of what work has been completed and

what is left to complete

• one for each developer or work item

• updated every day

• (make best guess about hours/points completed each day)

• variation: Release burndown chart

• shows overall progress

• updated at end of each sprint

55
 RMIT Classification: Trusted

Sample Burndown Chart

Hours

Copyright Dale Stanbrough 2009

 Tasks Mon Tue Wed Thu Fri
Code the front tier 14 8 4 2
Code the business logic 18 20 12 8 2
Test the front tier 8 10 8 8 44

75
60
45
Hours

30
15
0
Mon Tue Wed Thu Fri

Copyright Dale Stanbrough 2009

 RMIT Classification: Trusted

References:
• Software Engineering Institute's CMMI website:
http://www.sei.cmu.edu/cmmi/

• Systems Analysis and Design, Kendall and Kendall, Fifth Edition

• AUP, http://www.ambysoft.com

• XP, http://www.azzurri.co.jp

• http://www.tatvasoft.com/blog/top-12-software-development-
methodologies-and-its-advantages-disadvantages/#anchor5

58