Modelling the Process and Life Cycle

1
Modelling the Process and Life Cycle

• Software development usually involves the
  following stages
• Requirements analysis and definition
• System design
• Program design
• Program implementation (writing the program)
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance

2
What is a process?

• A series of steps involving activities,
  constraints and resources that produce an
  intended output of some kind
• Characteristics of a process
• prescribes all of the major process activities
• uses resources, subject to a set of constraints
  (such as a schedule), and produces intermediate
  and final results
• may be composed of sub-processes that are linked
  in some way.
• each process activity has an entry and exit
  criteria, so we know when each activity begins
  and ends

3
What is a process? (continued)

• activities are organised in a sequence, so that
  it is clear when one activity is performed
  relative to the other activities
• a set of guiding principles that explain the
  goals of each activity
• constraints or controls may apply to an activity,
  resource or product.
• e.g. budget or schedule may constrain length of
  time activity may take

4
Reasons for modelling a process

• Common understanding of the activities, resources
  and constraints
• Helps in the finding of inconsistencies,
  redundancies and omissions
• Help evaluate candidate activities for their
  appropriateness in meeting the goals, such as
  building high-quality software.
• Every process should be tailored for the special
  situation in which it will be used. Building a
  model helps the team understand where that
  tailoring is to occur

5
Waterfall model
6
Waterfall model advantages

• Very useful in helping developers layout (very
  high-level view) what they need to do
• Simplicity makes it easy to explain to
  customers (who are not familiar with software
  developers)
• Explicitly states which intermediate products are
  necessary in order to begin next stage

7
Waterfall model disadvantages

• Failure to treat software as a problem solving
  process. Software is a creation process not a
  manufacturing process. Software evolves as the
  problem is understood and the alternatives are
  evaluated.
• In particular, creation involves trying a little
  of this or that, developing and evaluating
  prototypes, assessing the feasibility of
  requirements, contrasting several designs,
  learning from failure and eventually settling on
  a satisfactory solution to the problem

8
Waterfall model disadvantages

• It provides no guidance of how each activity
  transforms one artefact into another, such as
  requirements to design. Thus the model provides
  no guidance to managers and developers on how to
  handle changes to products and activities that
  are likely to occur during development.
• If requirements change during coding, what
  changes do we make to design and code?

9
Software development in reality
10
Process models

• The software development process can help control
  the thrashing by including activities and
  sub-processes that enhance understanding.
• Prototyping is such a sub-process a prototype is
  a partially developed product that enables
  customers and developers to examine some aspect
  of the proposed system and decide it is suitable
  or appropriate for the finished product.

11
Prototyping model
12
Prototyping model

• Prototyping can be the basis of an effective
  process model. This model allows all or part of
  the system to be constructed quickly to
  understand or clarify issues.
• The overall goal is to reduce risk and
  uncertainty in development.

13
Phased development model
14
Phased development model

• This is used to reduce cycle time. The system is
  designed so that it can be delivered in pieces,
  enabling users to have some functionality while
  the rest is being developed. There are usually
  two systems functioning in parallel the
  production system and the development system

15
Incremental model

• In the incremental model, the system as specified
  in the requirements is partitioned into
  sub-systems by functionality. The releases are
  defined by beginning with one small functional
  sub-system and then adding functionality with
  each new release.

16
Iterative model

• This model delivers a full system at the very
  beginning and then changes the functionality of
  each sub-system with each new release.

17
Phased development advantages

• Training can begin on an early release. The
  training process allows developers to observe
  how certain functions are executed, suggesting
  enhancements for later releases.
• In this way, the developers can be very
  responsive to the users

18
Phased development advantages

• Markets can be created early for functionality
  that has never before been offered
• Frequent releases allow developers to fix
  unanticipated problems as they are reported
• The development team can focus on different areas
  of expertise with different releases.

19
Question

• Should a development organisation adopt a single
  process model for all of its software
  development? Discuss the pros and cons.

20
Answer

• Pros
• Standardization of training, terminology, the
  collection of process metrics, planning and
  estimation. Works well if the projects are very
  similar in nature.
• Cons
• Adopting a single standard process may
  unnecessarily constrain some projects from using
  the process that is best suited to the problem
  and the solution.

21
Question

• Suppose your contract with the customer specifies
  that you use a particular software development
  process. How can work be monitored to enforce
  the use of this process?

22
Answer

• Conformance to a particular process is often
  checked with the use of milestones. That is, the
  process is defined in such a way that there are
  tangible products in the process whose existence
  indicates that particular process steps have been
  carried out.
• For example, when using the waterfall process.
  These intermediate products, or milestones, could
  be a requirements document, a design document,
  the code itself, test documents etc. The timing
  of these products indicate whether or not the
  process was being followed as planned.

23
Answer (continued)

• Another way to monitor use of a process is by
  measuring effort. Developers working on the
  project could be required to report the effort
  they spent on different process activities. By
  tracking when effort is spent on which
  activities, progress through the steps of the
  process could be monitored.

24
The Rational Unified Process

• a process framework that can be adapted and
  extended to suit the needs of an adopting
  organization.
• general and comprehensive enough to be used "as
  is," i.e., out-of-the-box, by many
  small-to-medium software development
  organizations, especially those that do not have
  a very strong process culture.

From an article by Philippe Kruchten (check
course webpage)
25
The Rational Unified Process

• Can also modify, adjust, and expand the RUP to
  accommodate the specific needs, characteristics,
  constraints, and history of its organization,
  culture, and domain.
• Process should not be followed blindly,
  generating useless work and producing artefacts
  that are of little added value.
• Instead, must be made as lean as possible while
  still fulfilling its mission to help developers
  rapidly produce predictably high-quality
  software.

From an article by Philippe Kruchten (check
course webpage)
26
The RUP Captures Software Development Best
Practices

• RUP captures many of modern software
  development's best practices in a form suitable
  for a wide range of projects and organizations
• Develop software iteratively.
• Manage requirements.
• Use component-based architectures.
• Visually model software.
• Continuously verify software quality.
• Control changes to software.

From an article by Philippe Kruchten (check
course webpage)
27
Develop Software Iteratively

• Most software teams still use a waterfall process
  for development projects, completing in strict
  sequence the phases of requirement analysis,
  design, implementation/integration, and test.
• idles key team members for extended periods
• defers testing until the end of the project
  lifecycle, when problems tend to be tough and
  expensive to resolve
• pose a serious threat to release deadlines
• By contrast, RUP represents an iterative approach
  that is superior

From an article by Philippe Kruchten (check
course webpage)
28
Manage Requirements

• Requirements management is a systematic approach
  to eliciting, organising, communicating, and
  managing the changing requirements of a
  software-intensive system or application.

From an article by Philippe Kruchten (check
course webpage)
29
Continuously Verify Quality

• There is no worker in charge of quality in the
  RUP
• Because quality is not added to a product by a
  few people.
• Instead, quality is the responsibility of every
  member of the development organization.
• In software development, our concern about
  quality is focused on two areas
• product quality
• process quality.

From an article by Philippe Kruchten (check
course webpage)
30
Continuously Verify Quality (continued)

• Product quality -- The quality of the principal
  product being produced (the software or system)
  and all the elements it comprises (for example,
  components, subsystems, architecture, and so on).
• Process quality -- The degree to which an
  acceptable process (including measurements and
  criteria for quality) was implemented and adhered
  to during the manufacturing of the product.

From an article by Philippe Kruchten (check
course webpage)
31
Rational Unified Process
From an article by Philippe Kruchten (check
course webpage)
32
From an article by Philippe Kruchten (check
course webpage)
33
Agile Methods

• Agile manifesto focuses on four simple value
  statements, which defines preferences
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Respond to changes over following a plan

34
Agile Processes

• Extreme Programming(XP)
• Crystal
• Scrum
• Adaptive Software Development

35
Extreme Programming(XP)

• Leveraging the creativity of developers and
  minimising the amount of administration overhead
• Emphasises four characteristics of agility
• Communication
• Simplicity
• Courage
• Feedback

36
XP (continued)

• Communication
• Continual interchange between customers and
  developers
• Simplicity
• Encourages developers to select the simplest
  design or implementation to address the needs of
  the customer
• Courage
• Commitment to delivering functionality early and
  often
• Feedback
• Loops are built into various activities during
  development process

37
Crystal

• Collection of approaches based on the notion that
  every project needs a different set of policies,
  conventions and methodologies
• Suggests the following
• quality of the projects and processes improves as
  the quality of the people involved improves
• Productivity increases through better
  communication and frequent delivery because there
  is less need for intermediate products

38
Scrum

• Uses iterative development, where each 30-day
  iteration is called a sprint
• During a sprint, implement the products
  backlog of prioritised requirements
• Multiple self-organising and autonomous teams
  implement product increments in parallel
• Coordination is done at a brief daily status
  meeting called a scrum

39
Adaptive Software Development

• has six basic principles
• A mission that acts as a guideline
• Features are viewed as the crucial point of the
  customer value
• Iteration is important
• Change is embraced
• Fixed delivery times
• Risk is embraced

40
ASD (continued)

• A mission that acts as a guideline
• setting out the destination but not prescribing
  how to get there
• Features are viewed as the crucial point of the
  customer value
• so the project is organised around building
  components to provide features
• Iteration is important
• so redoing is as critical as doing

41
ASD (continued)

• Change is embraced
• so that change is viewed not as a correction but
  as an adjustment to the realities of software
  development
• Fixed delivery times
• force the developers to scope down the
  requirements essential for each version produced
• Risk is embraced
• so that the developer tackles the hardest
  problems first