Process Models

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

​

Brings order to chaos.

Enables common communication formats,

to exchange complex and abstract ideas / insights,

efficiently and visually. A picture says a thousand words.

Who am I?

Thank you for stopping by.

​

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

​

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

​

You can view the Introducing Myself, if you want to know a little more about who I am.

​

All my presentations and materials are free and available at my blog post: Software Engineering.

​

​

Don’t let me uphold you,

continue your journey, go to next slide.

2

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

Agenda

• Intro
• Quick Look
• Prescriptive Process Models
• The Waterfall Model
• Incremental Process Models
• Evolutionary Process Models
• A Final Word on Evolutionary Processes
• Component-Based Development
• The Unified Process
• A Brief History
• Phases of the Unified Process
• Product And Process
• Summary

​

​

Intro

• Reasonably effective roadmap for software teams
• Work and the products produced remain on "the edge of chaos"
• The edge of chaos is defined as�“A natural state between order and chaos, a grand compromise between structure and surprise”

​

Strike a balance between the need to impart order in a chaotic world and the need to be adaptable when things change constantly

Quick Look

• What is it?
• Roadmap for software engineering work
• Defines activities, actions and tasks, the degree of iteration, the work products, and the organization of the work that must be done
• Who does it?
• Software engineers and their managers
• People who have requested the software have a role to play in the process of defining, building, and testing
• Why is it important?
• Provides stability - Becomes quite chaotic if left uncontrolled

​

Quick Look

• What are the steps?
• Process model provides you with the "steps" you'll need to perform disciplined software engineering work
• What is the work product ?
• Customized description of the activities and tasks defined by the process
• How do I ensure that I've done it right?
• There are a number of software process assessment mechanisms
• However, the quality, timeliness, and long-term viability of the product you build are the best indicators of the efficacy of the process that you use

Prescriptive Process Models

Strives for structure and order in software development.

Prescriptive Process Models

Strives for structure and order in software development

• “Prescriptive", a set of process elements:
• Activities
• Actions
• Tasks
• Work products
• Quality assurance
• Change control mechanisms
• Also prescribes a process flow/work flow -that is, the manner in which the process elements are interrelated to one another

Prescriptive Process Models

The Waterfall Model

The Waterfall Model

Also called “classic life cycle” is the oldest paradigm.

Used when the requirements for a problem are…

• Well understood
• Well defined
• Reasonably stable

​

The Waterfall Model

V-model - A variation in the representation of the waterfall model

Depicts the relationship of quality assurance actions associated with communication, modelling, and early construction activities.

​

• No fundamental difference between the “Waterfall” and the V-model
• Provides a way of visualizing how verification and validation actions are applied to earlier engineering work

The Waterfall Model

The Waterfall Model

Among the problems that are some times encountered are:

1. Real projects rarely follow the sequential flow that the model proposes
2. It is often difficult for the customer to state all requirements explicitly
3. The customer must have patience - A working version of the program(s) will not be available until late in the project time span

​

Can lead to "blocking states" in which some project team members must wait for other members of the team to complete dependent tasks.

Incremental Process Models

Produce the software in increments.

Incremental Process Models

Produce the software in increments

Incremental Process Models

• Combines the elements' linear and parallel process flows
• Each linear sequence produces deliverable "increments" of the software.
• Example: word-processing software
1. Deliver basic file management, editing, and document production functions
2. More sophisticated editing and document production capabilities
3. Spelling and grammar checking
4. Advanced page layout capability

The first increment is often a core product - Basic requirements

As a result of use and/or evaluation, a plan is developed for the next increment

Evolutionary Process Models

Software evolves over a period of time.

Evolutionary Process Models

Software evolves over a period of time…

Business and product requirements often change as development proceeds

• A set of core requirements is well understood
• The details have yet to be defined

Evolutionary models are iterative. Characterized in a manner that enables you to develop increasingly more complete software versions

​

2 common evolutionary process models

• Prototyping
• The Spiral Model

​

Prototyping

To better understand what is to be built when requirements are fuzzy.

Prototyping

Prototyping

• Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features.
• The developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take

Prototyping paradigm may offer the best approach.

Assists you and other stakeholders to better understand what is to be built when requirements are fuzzy.

Ideally, it serves as a mechanism for identifying requirements.

Prototyping

• Some prototypes are built as “throwaways“
• Others are evolutionary in the sense that the prototype slowly evolves into the actual system.

​

Both stakeholders and software engineers like the prototyping paradigm.

​

Can be problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software
2. You often make implementation compromises in order to get a prototype working quickly

​

Spiral Model

An evolutionary process model which couples iterative prototyping with small 2-4 weeks systematic waterfalls/rituals based iteration/sprints.

Spiral Model

Spiral Model

It is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.

​

Risk-driven Process Model with 2 main distinguishing features:

1. A cyclic approach for incrementally growing a system's degree of definition and implementation while decreasing its degree of risk
2. A set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions

Spiral Model

Software is developed in a series of evolutionary releases

• During early iterations, the release might be a model or prototype
• During later iterations, increasingly more complete versions are produced

​

• Is divided into a set of framework activities defined by the software engineering team
• Each of the framework activities represent one segment of the spiral path
• Risk is considered as each revolution is made
• Anchor point milestones - a combination of work products and conditions that are attained along the path of the spiral are noted for each evolutionary pass

Evolutionary Process Models

Spiral Model

​

1. The first circuit around the spiral might result in the development of a product specification
2. Subsequent passes around the spiral might be used to develop a prototype
3. …and then progressively more sophisticated versions of the software

​

Spiral Model

• Each pass through the planning region results in adjustments to the project plan
• Cost and schedule are adjusted based on feedback derived from the customer after delivery
• In addition, the project manager adjusts the planned number of iterations required to complete the software

​

Spiral Model

Later, a circuit around the spiral might be used to represent a�"product enhancement project“

…remains operative until the software is retired.

​

• The spiral model is a realistic approach to the development of large-scale systems and software
• Uses prototyping as a risk reduction mechanism
• Demands a direct consideration of technical risks at all stages of the project - Should reduce risks before they become problematic

A Final Word on Evolutionary Processes

Modern computer software is characterized by:

• Continual change
• Very tight time lines
• Emphatic need for customer/user satisfaction

In many cases, time-to-market is the most important management requirement - If a market window is missed, the software project itself may be meaningless.

The challenge for software teams and their managers is to establish a proper balance between these critical project and product parameters and customer satisfaction.

Component-Based Development Model

Provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built.

​

Component-Based Development

• Component-based development model incorporates many of the characteristics of the spiral model
• Evolutionary in nature, demanding an iterative approach to the creation of software

​

Component based development model comprises applications from pre-packaged software components.

Component-Based Development

Modelling and construction activities begin with the identification of candidate components.

• Can be designed as either conventional software modules or object-oriented classes or packages of classes

​

Incorporates the following steps using an evolutionary approach.

1. Available component-based products are researched and evaluated for the application domain in question
2. Component integration issues are considered
3. A software architecture is designed to accommodate the components
4. Components are integrated into the architecture
5. Comprehensive testing is conducted to ensure proper functionality

Component-Based Development

​

Leads to software reuse…

​

Reusability provides software engineers with a number of measurable benefits including

• A reduction in development cycle time
• A reduction in project cost if component reuse becomes part of your organization's culture

Unified Process (UP)

Defines a use case driven, architecture - centric, iterative and incremental process flow.

Provides the evolutionary feel that is essential in modern software development.

​

​

Phases of the Unified Process

Inception Phase

• Encompasses both customer communication and planning activities
• Requirements for the software are identified
• Rough architecture for the system is proposed
• Later, the architecture will be refined and expanded
• Plan for iterative, incremental nature
• Identifies resources, assesses major risks, defines a schedule, and establishes a basis for the phases that are to be applied as the software increment is developed
• Requirements are described through a set of preliminary use cases

Elaboration Phase

• Encompasses the communication and modeling activities
• Refines and expands the preliminary use cases
• Expands the architectural representation to include 5 different views of the software
• use case model
• analysis model
• design model
• implementation model
• deployment model
• Often creates an "executable architectural base line" that represents a "first cut“ executable system
• Plan is reviewed to ensure scope, risks, and delivery dates

Construction Phase

• Identical to the construction activity defined for the generic software process

Using the architectural model as input, acquires the software components that will make each use case operational for end users.

• Analysis and design models that were started during the elaboration phase are completed to reflect the final version of the software increment
• All necessary and required features and functions for the software increment are then implemented in source code
• Tests are designed and executed
• Use cases are used to derive a suite of acceptance tests that are executed prior to the initiation of the next UP phase

Transition Phase

• Encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity
• Software team creates the necessary support information that is required for the release e.g.
• User manuals
• Troubleshooting
• Guides
• Installation procedures
• Etc…

Production Phase

• Deployment activity of the generic process
• The ongoing use of the software is monitored
• Support for the operating environment (infrastructure ) is provided
• Defect reports and requests for changes are submitted and evaluated

​

It is likely that at the same time the construction, transition, and production phases are being conducted.

• Work may have already begun on the next software increment…

This means that the 5 UP phases do not occur in a sequence, but rather with staggered concurrency – In parallel.

Product and Process

If the process is weak, the end product will undoubtedly suffer…but…

• People derive as much (or more) satisfaction from the creative process as they do from the end product
• An artist enjoys the brush strokes as much as the framed result
• A writer enjoys the search for the proper metaphor as much as the finished book

​

As creative software professional, you should also derive as much satisfaction from the process as the end product.

A Brief History

During the early 1990s James Rumbaugh, Grady Booch, and Ivar Jacobson began working on a "unified method" that would combine the best features of each of their individual object-oriented analysis and design methods and adopt additional features proposed by other experts in object-oriented modeling.

​

The result was UML - By 1997, UML became a de facto industry standard for object-oriented software development

• Represent both requirements and design models

Summary

Each model suggests a somewhat different process flow, but all perform the same set of generic framework activities:

• Communication
• Planning
• Modeling
• Construction
• Deployment

Emphasize measurement, planning, and self-direction as key ingredients for a successful software process.

Methodology Comparison

Framework for Comparing different Process models Meta Model.

Methodology Comparison

What is it?

• Framework for Comparing different Process models Meta Model -> Model that tells something about models (Juts like Meta Data, Tells something about the data) Purpose?
• Academic -> To improve process models - Practical -> To choose a process model, before starting working.�

The Challenge

• Different process models contains different aspects. How do we measure pears and bananas?
• Models change- continuously > Are you looking at the newest “version” (Not released version, but a dynamic ongoing change)?
• Commercial models -> Info is not always available.
• Same terms for different things (Controller -> MVC/GRASP) or different terms for the same thing (Artifact/Work-product/Item).

Avison & Fitzgerald ’s Framework (A&V)

• A Meta-model for comparing different process models. A&V has put together a set of criteria's, to compare process models.

Philosophy (Principle)

• Paradigm -> A specific way of thinking about the problems
• Objectives -> The purpose of the system.
• Domain -> Is it a specific problem or a more comprehensive challenge (such as which applications should be used in an organization)?
• Target -> In which situation is it useful?
• Model -> The View of the world (Objects/Data/Events/…).
• Techniques and Tools - (EG. UML/Pair Programming…).
• Scope -> Are we only taking care of the process (Waterfall/Scrum)?, the development (XP) or a combination (UP).
• Outputs -> Analysis-, design-, and prototypes, a running system etc.

Practice

• Background -> Commercial/Academic?
• Use base -> Numbers and types of users of the methodology.
• Participants -> Types and skill levels.

Product

• Software, documentation, training.

Avison & Fitzgerald ’s Framework (A&V)

• Avison – Information System Development
• Avison_Information Systems Development_Ch_27.pdf
• Methodology Comparison Example
• Methodology Comparison Example.pdf
• Boehm & Turners Radar Chart
• Boehm & Turners Radar Chart.pdf
• Introduction to System Development Methodologies - YouTube
• https://www.youtube.com/watch?v=rm6D0uNHP8A

​

Questions?

Anything? What’s on your mind? Come on ask me anything…

​

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

​

Please share your feedback here