CMPT 275 Software Engineering

1
CMPT 275Software Engineering

• Software life cycle

2
Why a Waterfall Process Model?

• Phases are performed once making the process
• Easy to follow
• One phase should not be started until the
  previous one is complete
• Easy to manage
• Documents need only be produced and approved once
  (this is a costly process)
• Parallels other engineering process models
• The waterfall method should only be used if the
  requirements are well understood

3
Why not ?

• Impractical to fully complete any one of
  thephases before starting the next one
• difficult to capture all requirements before
  proceeding to design
• Users dont get to see the results until the end
• problems may emerge only at the end when user
  realizes the product is not what was needed

4
Fixing the problems

• How can we modify these sequential life cycle
  model to address these problems
• Prototypes
• can be useful to show to the user to catch
  problems before implementation
• can also be misleading as the client must
  understand that the system is not almost ready
• Allow for return to earlier processes to update
  models to include changes to fix deficiencies
  found in later processes incorporate iteration
• Allow for an incremental approach of developing a
  basic solution, then adding additional
  functionality

5
Modified Waterfall Model
Project Planning
RequirementAnalysis
Design
Add some iteration
Implementation Testing
Maintenance
6
Evolutionary model

• Iterative and incremental (many waterfalls)
• Software system to be developed is partitioned
  into development phases (sub goals) that include
  some user driven subset of the functionality of
  the entire project (e.g. Critical Functionality,
  Required Functionality, Desired Functionality)
• Each phase has its own requirements analysis
  followed by design, implementation, and testing
• Each phase adds additional functionality to the
  project

7
Boehms spiral model
Unit Test
and test
System test
Acceptance test
After Boehm, 1987
8
Spiral model

• Round 0 Feasibility study
• Round 1 Requirements development
• Round 2 Development / test of system
• Risk analysis aspect is critical. In any round
  development can stop is risk is too high
• Requirements clearly defined and completely
  defined, risks are all low and a single round of
  development reduces to a waterfall
• Requirements clearly defined, but lowest risk in
  1st round, higher in 2nd reduces to evolutionary

9
Evolutionary Process Model - 1

• Advantages
• Helps assure modularity and maintainability
• Each version built on tested results of a
  previous version
• User/client feedback of first iteration (could be
  a prototype) provides opportunity to catch
  potential problems, or misunderstanding early
• Helps improve project time estimation
• Record time taken during first iteration
• Helps produce better estimations for next
  iterations
• Test plans can be expanded for new functionality
  in later iterations

10
Evolutionary Process Model - 2

• Disadvantages
• Because of overlapping iterations
• Synchronizing documentation
• Management overhead

11
Programming Paradigm

• The process life cycle models we have discussed
  were developed before the OO paradigm came into
  common use
• Some models can be adapted to the new paradigm
• What about life cycle models specifically for the
  OO paradigm?

12
OO Dividing Tasks

• During requirements analysis identify
  requirements or groups of requirements that have
  different priorities. As an example
• Core functionality (for OO a few use cases)
• Necessary additional functionality (for OO add
  use cases)
• Desired additional functionality ( for OO add
  more use cases)

13
OO Incremental Development

• A proposed approach for the example
• Develop the Core functionality. Get feedback from
  the client
• As a second iteration/increment add the necessary
  additional features, repeat the linear sequential
  process. Get more feedback
• Finally (time permitting) complete a third
  iteration/increment to add the desired additional
  functionality

14
The Rational Unified Process

• An iterative, incremental, use case driven
  process
• Each cycle (iteration) addresses a set of use
  cases
• Each cycle builds a set of software components
  that communicate through well designed interfaces
• Each cycle is composed of four phases (inception,
  elaboration, construction, transition)
• Using a series of UML based models stakeholders
  visualize what happens in each cycle and phase

15
The Rational Unified Process

• During each cycle several workflows (life cycle
  processes) are executed in parallel (at the same
  time)
• Support workflows Management, environment,
  assessment, deployment
• Engineering workflows requirements, design,
  implementation, test

16
Workflows
Jacobson, Booch, Rumbaugh 2001
17
Unified Software Development

• Inception
• Establish scope of system
• Identify core use cases, use then to help choose
  architecture
• Estimate schedule, feasibility, and resources
  needed
• Construction
• Components built (otherwise acquired) and
  integrated
• Resulting system verified/tested to satisfy
  requirements

18
Unified Software Development

• Elaboration
• Requirements elicitation and capture verification
  modeling
• Design of architecture
• Revise estimates of schedule and resources
• Transition
• Deployment and maintenance

19
Prototyping

• Build a mock up of the system for evaluation by
  client
• Helps confirm you are on the right track
• Mock-ups may be throwaway, that is rapidly
  constructed, (usually in a modeling language too
  inefficient for the final system) to illustrate
  the functionality of the system
• Mockups may be incremental, demonstrating some
  aspects of the system
• Beware the client may see the mock-up as an
  almost finished product, not a tool for
  interactive development with input from the client

20
CMPT 275Software Engineering

• Project Planning Scheduling

21
Term Project Deliverable 1

• Project plan List of activities
• Table of Contents
• Revision History
• Project overview
• Project planning
• Project schedule
• Risk management
• Team meeting agenda and minutes
• Team members and their roles

22
Example of Revision History
23
Project overview

• ½ page summary of goals of the project
• single spaced, 11-12 point font
• IN YOUR OWN WORDS
• Should be clear, concise, and as complete as
  possible
• Enumerate the primary functions of the product
  you will build

24
Term Project Deliverable 1

• Project plan List of activities
• Table of Contents
• Revision History
• Project overview
• Project planning
• Project schedule
• Risk management
• Team meeting 2 agenda and minutes
• Team members and their roles

25
Role of Phase Manager

• Responsible for the phase
• Takes care of difficulties or emergencies that
  arise
• Oversees the distribution of tasks for the phase
• Monitors progress on tasks to assure timely
  delivery
• The phase manager DOES NOT do all the work for
  the phase
• The phase manager should participate in the
  completing tasks for the phase he/she manages

26
Team members and their roles

• For each team member
• Name, email address, photo
• Software management role
• Project Progress, Caucus , External
  Communications, Internal communications,
  configuration
• List of phases managed
• Each team member should manage at least 1 phase
• If your team has 6 members the member without a
  management role should manage more than 1 phase

27
Term Project Deliverable 1

• Project plan List of activities
• Table of Contents
• Revision History
• Project overview
• Project planning
• Project schedule
• Risk management
• Team meeting agenda and minutes
• Team members and their roles

28
Term Project Other Phases

• Requirements Analysis (Deliverable 2, 3, client
  meetings)
• Gathering, analysis, and specification of
  Requirements
• High level (system level) design (Deliverable 5)
• User Manual (Deliverable 4)
• Low Level (object level) Design (Deliverable 5)
• Implementation and Testing (Deliverable 6,
  includes team presentation)
• Delivery of Completed Project, with up to date
  documentation (Deliverable 7)
• User acceptance test

29
Term lecture topics

• Week 12 Project Planning
• Week 2-4 Requirements Analysis
• Week 5-7 High Level Design
• Week 7-8 Low Level Design
• Week 8-9 Implementation
• Week 9-10 Testing
• Week 10-11 Presentations
• Week 12 Configuration Management
• Week 12 Project Management

30
Project Schedule An Example
USE MICROSOFT PROJECT TO PRODUCE YOUR GANTT
CHART
31
On your Gantt chart Include

• The Gantt chart in the previous slide illustrates
  the following items that you should include in
  your project schedule GANTT chart
• Milestones
• Due dates of deliverables
• Dates of important meetings (UAT, Client Meeting
  )
• Phases
• Start and end date of each phase
• Tasks (sub phases, activities)
• Start and end date of each task
• Tasks on critical path highlighted

32
Project Schedule Another Example
33
On your Gantt chart also include

• The Gantt chart in the previous slide illustrates
  the following additional items that you should
  include in your project schedule GANTT chart
• Tasks (activities)
• Names of resources (team members) responsible for
  each task
• Percentage of available time of resource on each
  task (when a resource is assigned to more than 1
  task at a time)
• Dependencies between tasks (does task A need to
  be finished before task B starts)

34
Updates to your Gantt chart

• Your original Gantt chart, submitted with
  deliverable 1 will contain full detail of tasks
  only for the first phases (project planning and
  requirements analysis) of the project.
• At the end of each phase of the project the Gantt
  chart should be updated to reflect the details of
  the next phase.
• The updated Gantt chart should be submitted with
  each phase of the project

35
Term Project Deliverable 1

• Project plan List of activities
• Table of Contents
• Revision History
• Project overview
• Project planning
• Project schedule
• Risk management
• Team meeting 2 agenda and minutes
• Team members and their roles

36
Risk Analysis

• A risk is a potential problem that would hinder
  the progress of an activity/project if it were to
  occur.
• To identify risks need to ask What could happen
  that would make our project late?
• Mitigate identified risks by making plans that
  detail how to avoid the risk or recover from the
  risk

37
Action Plan
What

• A set of steps that eliminates risk

• before the activity/project commences.

When
Before the risk occurs!
38
Contingency Plan
What

• A set of steps that reduces the impact of risk

• once it has occurred during an activity/project.

When
39
Risk Analysis

• Lets consider an example
• We are planning an awards dinner for a the
  participants of a programming competition.
• What can go wrong?

40
Consider our example

• Not enough food for all the participants.
• Action Plan 1 Estimate the maximum number of
  attendees and order food for that many people.
• May be expensive if not all participants attend

41
Consider our example

• Not enough food for all the participants.
• Action Plan 2 Send invitations with an RSVP.
  Order enough food for those who reply, plus a
  small additional amount (some may come even if
  they did not reply)
• Will better estimate the amount of food needed
• OTHER SUGGESTIONS?

42
In Class Exercise

• Choose a partner
• Discuss your term project
• Identify some risks
• Provide a contingency plan to mitigate one risk
• Provide an action plan to mitigate one risk
• Turn in 1 page with a summary of your risks and
  plans. I will mention some of them at the start
  of next lecture.