1. SEC 308 Yazılım Mühendisliği Software Process Models

2. A Layered Technology Software Engineering tools methods process model
a “quality” focus
Software Engineering

3. Definition Process Methods Tools
Defines who is doing what, when, and how to reach a certain goal.
Forms the basis for management control of software projects.
Methods
technical “how to” for building software
Broad array of tasks: communication, requirements analysis, design modeling, program construction, testing, and support
Tools
Automated support for process and methods

4. A Process Model
A structured set of activities required to develop a software system
Prescribe a set of process elements
Framework activities
Software engineering actions
Tasks
Work products
Quality assurance and
Change control mechanisms for each project
Each process model also prescribes a workflow

5. Plan-driven and agile processes
Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.
In practice, most practical processes include elements of both plan-driven and agile approaches.
There are no right or wrong software processes

6. A Process Framework Software Process Process framework
Modeling activity
Software Engineering action: Analysis
work tasks: requirements gathering,
elaboration, negotiation,
specification, validation
work products: analysis model
and/or requirements spec
milestones & deliverables
QA checkpoints
Software Engineering action: Design
work tasks: data design, architectural, interface design,
component design
work products: design model
and/or design specification …
Umbrella Activities
Process framework
Framework activity 1
work tasks
work products
milestones & deliverables
QA checkpoints
Framework activity n
Umbrella Activities

7. Process Flow
Executes each of the framework activities in sequence, beginning with communication and culminating with deployment
Process flow describes how the framework activities and the actions and tasks that occur within each framework activities are organized with respect to sequence and time.
Repeats one or more of the activities before proceeding to the next

8. Process Flow (cont.)
Executes the activities in a “circular” manner, each circuit through the five activities leading to a more complete version of the software
Executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software in parallel with construction of another aspect of the software

9. Key Question What actions are appropriate for a framework activity,
given the nature of the problem to be solved,
the characteristics of the people doing the work, and
the stakeholders who are sponsoring the project?
Different project demand different task sets
Software team chooses the task set based on
Problem and project characteristics
Characteristics of the project team

10. Example I
For a small, relatively simple project, task set for requirements gathering
Make a list of stakeholders for the project
Invite all stakeholders to an informal meeting
Ask each stakeholder to make a list of features and functions required
Discuss requirements and build a final list
Prioritize requirement
Note areas of uncertainty

11. Example II For a larger, more complex software project,
Make a list of stakeholders for the project
Interview each stakeholder separately to determine overall wants and needs
Build a preliminary list of functions and features based on stakeholder input
Schedule a series of facilitated application specification meetings
Conduct meetings
Produce informal user scenarios as part of each meeting
Refine user scenarios based on stakeholder feedback
Build a revised list of stakeholder requirements
Use quality function deployment techniques to prioritize requirements
Package requirements so that they can be delivered incrementally
Note constraints and restrictions that will be placed on the system
Discuss methods for validating the system

12. Build & Fix Model
Product is constructed without specifications or any attempt at design
Ad-hoc approach and not well-defined
Simple two phase model

13. Build & Fix Model - Drawbacks
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

14. The Waterfall Model (Classic Life Cycle)
Suggests a systematic, sequential approach to software development
It reinforces the notion of “define before design” and “design before code”.
Works best when
Requirements of a problem are reasonably well understood
Well-defined adaptations or enhancements to an existing system must be made
Requirements are well-defined and reasonably stable

15. The Waterfall Model

16. V-Model

17. The Waterfall Model - Drawbacks
It is difficult to define all requirements at the beginning of a project
This model is not suitable for accommodating any change
A working version of the system is not seen until late in the project’s life
It does not scale up well to large projects.
Real projects are rarely sequential.

18. The Incremental Model
It combines elements of the waterfall model applied in an iterative fashion
It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered
When it is used, the first increment is often a core product; basic requirements are addressed, but many supplementary features remain undelivered
The core product is used by customer. As a result, a plan is developed for next increment

19. The Incremental Model

20. The Incremental Model
This model focuses on the delivery of an operational product with each increment
Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments
Increments can be planned to manage technical risks

21. The RAD Model
RAD (Rapid Application Development) is an incremental SW process model that emphasizes a short development cycle
RAD model is a “high-speed” adaptation of the waterfall model, achieved by using a component-based construction approach
If a business application modularized in a way that enables each major function to be completed in less than 3 months, it is a candidate for RAD

22. The RAD Model

23. The RAD Model Build a rapid prototype
Give it to user for evaluation & obtain feedback
Prototype is refined with active participation of users

24. The RAD Model - Drawbacks
Not an appropriate model in the absence of user participation.
For large, but scalable projects, RAD requires sufficient human resources to create right number of RAD teams
Highly specialized & skilled developers are not easily available.
If a system cannot be properly modularized, building the components necessary or RAD will be problematic
Reusable components are required to reduce development time.
RAD may not be appropriate when technical risks are high

25. Evolutionary Process Models
Evolutionary models are iterative
They are characterized in a manner that enables SW engineers to develop increasingly more complete versions of the software
Example models
Prototyping model
The Spiral model
Concurrent model

26. Evolutionary Models: Prototyping
The prototype may be a usable program but is not suitable as the final software product.
The code for the prototype is thrown away. However, experience gathered helps in developing the actual system.
The development of a prototype might involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model.

27. Evolutionary Models: Prototyping

28. Evolutionary Models: Prototyping - Drawbacks
The customer sees what appears to be a working version of SW, unaware that in the rush to get it working we haven’t considered overall quality or long-term maintainability
The developer often makes implementation compromises in order to get prototype working quickly

29. Evolutionary Models: Spiral
Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
Provides the potential for rapid development of increasingly more complete versions of the software
A risk-driven process model generator
It has two main distinguishing features
Cyclic approach - Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk
A set of anchor point milestones - A combination of work products and conditions that are attained along the path of the spiral

30. Evolutionary Models: Spiral

31. Evolutionary Models: Spiral
Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software
The circuits around the spiral might represent
Concept development project
New Product development project
Product enhancement project
The spiral model demands a direct consideration of technical risks at all stages of the project

32. Evolutionary Models: Spiral - Drawbacks
Difficult to convince customers that evolutionary approach is controllable
Demands considerable risk assessment expertise and relies on this expertise for success
If major risks are uncovered and managed, problems will occur

33. Evolutionary Models: Concurrent
Sometimes called concurrent engineering
Can be represented schematically as a series of framework activities, software engineering actions and tasks, and their associated states
Defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks
Defines a network of activities
E. g. The modeling activity which existed in none state while initial communication was completed, now makes a transition into under development state. If customer indicates that changes in requirements must be made, modeling activity moves from under development state into awaiting changes state

34. Evolutionary Models: Concurrent

35. Evolutionary Models: Concurrent
Is applicable to all types of software development and provides an accurate picture of the current state of project
All activities exist concurrently but reside in different states
Events generated at one point in the process network trigger transitions among the states

36. Other Process Models
Component-based development—the process to apply when reuse is a development objective
Formal methods—emphasizes the mathematical specification of requirements
AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects
Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

37. The Unified Process (UP)
It is a use-case driven, architecture-centric, iterative and incremental software process
UP is an attempt to draw on the best features and characteristics of conventional s/w process models
Also implements many of the best principles of agile software development
UP is a framework for object-oriented software engineering using UML (Unified Modeling Language)

38. Phases of The Unified Process

39. Phases of UP - Inception
Defines scope of the project
Encompasses both customer communication and planning activities
Fundamental business requirements are described through a set of preliminary use-cases
A use-case describes a sequence of actions that are performed by an actor (e.g., a person, a machine, another system) as the actor interacts with the software
A rough architecture for the system is also proposed

40. Phases of UP - Elaboration
Encompasses customer communication and modeling activities
Refines and expands the preliminary use-cases
Expands the architectural representation to include five different views of the software
The use-case model
The analysis model
The design model
The implementation model
The deployment model
In some cases, elaboration creates an “executable architectural baseline” that represents a “first cut” executable system

41. Phases of UP - Construction
Makes each use-case operational for end-users
As components are being implemented, unit tests are designed and executed for each
Integration activities (component assembly and integration testing) are conducted
Use-cases are used to derive a suite of acceptance tests

42. Phases of UP - Transition
Involves many activities like delivering, training, supporting, and maintaining the product.
Software is given to end-users for beta testing
The software team creates the necessary support information
User manuals
Trouble-shooting guides
Installation procedures
At the conclusion of the transition phase, the software increment becomes a usable software release

43. Phases of UP - Production
Coincides with the deployment activity of the generic process
The on-going use of the software is monitored
Support for the operating environment (infrastructure) is provided
Defect reports and requests for changes are submitted and evaluated

44. Unified Process Work Products
Inception
Vision document
Initial use-case model
Elaboration
Analysis model, design model
Construction
Implementation model, deployment model, test model
Transition
Delivered software, beta test reports, general user feedback

45. Initial Development & Evolution Cycles

46. Iterations & Workflow of Unified Process

47. Selection of a Process Model
Selection of a model is based on:
Requirements
Development team
Users
Project type and associated risk

48. Based On Characteristics Of Requirements

49. Based On Status Of Development Team

50. Based On User’s Participation

51. Based On Type Of Project With Associated Risk

53. The Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” Kent Beck et al

54. What is “Agility”? Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed
Yielding …
Rapid, incremental delivery of software

55. Agility and the Cost of Change

56. An Agile Process
Is driven by customer descriptions of what is required (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a heavy emphasis on construction activities
Delivers multiple ‘software increments’
Adapts as changes occur

57. Agility Principles - I
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face–to–face conversation.

58. Agility Principles - II
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity – the art of maximizing the amount of work not done – is essential.
The best architectures, requirements, and designs emerge from self–organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

59. Extreme Programming (XP)
The most widely used agile process, originally proposed by Kent Beck
XP Planning
Begins with the creation of “user stories” by listening
Customer assigns a value to the story.
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

60. Extreme Programming (XP)
XP Design
Follows the KIS principle
Encourage the use of CRC cards
For difficult design problems, suggests the creation of “spike solutions”—a design prototype
Encourages “refactoring”—an iterative refinement of the internal program design
XP Coding
Recommends the construction of a unit test for a story before coding commences
Encourages “pair programming”
XP Testing
All unit tests are executed daily (whenever code is modified)
“Acceptance tests” are defined by the customer and executed to assess customer visible functionality

61. Extreme Programming (XP)

62. Adaptive Software Development
Originally proposed by Jim Highsmith
ASD — distinguishing features
Mission-driven planning
Component-based focus
Uses “time-boxing”
Explicit consideration of risks
Emphasizes collaboration for requirements gathering
Emphasizes “learning” throughout the process

63. Adaptive Software Development

64. Dynamic Systems Development Method
Promoted by the DSDM Consortium
DSDM—distinguishing features
Similar in most respects to XP and/or ASD
Nine guiding principles
Active user involvement is imperative.
DSDM teams must be empowered to make decisions.
The focus is on frequent delivery of products.
Fitness for business purpose is the essential criterion for acceptance of deliverables.
Iterative and incremental development is necessary to converge on an accurate business solution.
All changes during development are reversible.
Requirements are baselined at a high level
Testing is integrated throughout the life-cycle.

65. Dynamic Systems Development Method

66. Scrum Originally proposed by Schwaber and Beedle
Scrum—distinguishing features
Development work is partitioned into “packets”
Testing and documentation are on-going as the product is constructed
Work occurs in “sprints” and is derived from a “backlog” of existing requirements
Meetings are very short and sometimes conducted without chairs
“Demos” are delivered to the customer with the time-box allocated

67. Scrum

68. Crystal Proposed by Cockburn and Highsmith
Crystal—distinguishing features
Actually a family of process models that allow “maneuverability” based on problem characteristics
Face-to-face communication is emphasized
Suggests the use of “reflection workshops” to review the work habits of the team

69. Feature Driven Development
Originally proposed by Peter Coad et al
FDD—distinguishing features
Emphasis is on defining “features”
a feature “is a client-valued function that can be implemented in two weeks or less.”
Uses a feature template
<action> the <result> <by | for | of | to> a(n) <object>
A features list is created and “plan by feature” is conducted
Design and construction merge in FDD

70. Feature Driven Development

71. Agile Modeling Originally proposed by Scott Ambler
Suggests a set of agile modeling principles
Model with a purpose
Use multiple models
Travel light
Content is more important than representation
Know the models and the tools you use to create them
Adapt locally