Best Practices of Software Engineering

Best Practices of Software Engineering
2
Objectives
What we will learn:
 Best Practices of Software Engineering
3
Best Practices Reinforce Each Other
Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Validates architectural
decisions early on
Addresses complexity of
design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Ensures users are involved
as requirements evolve
4
Develop Iteratively
 Iterative development produces an
executable
1. Initial
Planning
2. Planning
3. Requirements
4. Analysis & Design
5. Implementation
7. Deployment
6. Test
8. Evaluation
Management
Environment
(on-going)
Each iteration
results in an
executable release
5
Managing Requirements
Ensures that you
 solve the right problem
 build the right system
by taking a systematic approach to
 eliciting
 organizing
 documenting
 managing
the changing requirements of a software
application.
6
Use Component Architectures
Software architecture needs to be:
 Meets current and future
requirements
 Improves extensibility
 Enables reuse
 Encapsulates system
dependencies
 Reuse or customize
components
 Select from commercially
available components
 Evolve existing software
incrementally
Component-based Resilient
7
Purpose of a Component-Based Architecture
 Basis for reuse
 Component reuse
 Architecture reuse
 Basis for project management
 Planning
 Staffing
 Delivery
 Intellectual control
 Manage complexity
 Maintain integrity Systemsoftware
Middleware
Businessspecific
Applicationspecific
Component-based
architecture with
layers
8
SOA
9
Model Visually (UML)
 Captures structure and behavior
 Shows how system elements fit together
 Keeps design and implementation
consistent
 Hides or exposes details as appropriate
 Promotes unambiguous communication
 The UML provides one language for all
practitioners.
10
Visual Modeling with the Unified Modeling Language
Dynamic
Diagrams
 Multiple views
 Precise syntax and semantics
Activity
Diagrams
Models
Static
Diagrams
Sequence
Diagrams
Communication
Diagrams
State Machine
Diagrams
Deployment
Diagrams
Component
Diagrams
Object
Diagrams
Class
Diagrams
Use-Case
Diagrams
11
Continuously Verify Quality
CCoosstt
Inception Elaboration Construction Transition
Software problems are
100 to 1000 times more costly
to find and repair after deployment
 Cost to Repair Software
 Cost of Lost Opportunities
 Cost of Lost Customers
12
Testing Dimensions of Quality
Peerrffoorrmaannccee
Reelliiaabbiilliittyy
 Test that the application
behaves consistently
and predictably.
 Test the online response
under average and
peak loading.
Functtiionalliittyy
 Test the accurate
workings of each
usage scenario.
Ussaabbiilliittyy
 Test application
from the perspective
of convenience to the
end user.
Suuppppoorrttaabbiilliittyy
 Test the ability to
maintain and support the
application under
production use.
13
Workspace
Management
Process
Integration
Parallel
Development
Build
Management
Configuration
Management is more
than just check-in
and check-out
Manage Change
 To avoid confusion, have:
 Secure workspaces for each developer
 Automated integration/build management
 Parallel development
14
Manage Change (continued)
 Unified Change Management (UCM)
involves:
 Management across the lifecycle
• System
• Project management
 Activity-based management
• Tasks
• Defects
• Enhancements
 Progress tracking
• Charts
• Reports
15
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Rational Unified Process Implements Best Practices
Best Practices
Process Made Practical
16
Achieving Best Practices
 Iterative approach
 Guidance for activities
and artifacts
 Process focus on
architecture
 Use cases that drive
design and
implementation
 Models that abstract
the system
17
A Team-Based Definition of Process
A process defines Who
is doing What
,
When
, and How
, in order
to reach a certain
goal.
New or changed
requirements
New or changed
system
Software Engineering
Process
18
Process Structure - Lifecycle Phases
The Rational Unified Process has four phases:
 Inception
– Define the scope of the project
 Elaboration
– Plan the project; specify features and
baseline architecture
 Construction
– Build the product
 Transition
– Transition the product into the end-user
community
Inception
Elaboration
Construction
Transition
Time
19
Bringing It All Together: The Iterative Approach
Disciplines
group
activities
logically.
In an
iteration
,
you walk
through all
disciplines.
20
Iterative development and the unified process
21
Objectives
What we will learn:
 Define an iterative and adaptive process.
 Define fundamental concepts in the Unified
Process.
22
Unified Process
 Iterative development
Iitaevdopmtrevn is a skillful approach to
software development, and lies at the heart of how
OOA/D is presented
 The Unified Process
is an example iterative
process for projects using OOA/D
 In particular, the Rational Unified Process or RUP
is a
detailed refinement of the Unified Process
 The UP is very flexible and open, and encourages
including skillful practices from other iterative
methods,
 such as from Extreme Programming (XP), Scrum, and
so forth
23
From sequential to iterative lifecycle
R: requirements; D: design; C: coding, unit test; T: integration,
test
Time
R
D
C
T
R
D
C
T
R
D
C
T
R
D
C
T
24
Iterative Development
 ID is the best practice using the UP to develop software
 Development is organized into a series of short, fixedlength
(for example, four week) mini-projects called
iterations;
the outcome of each is a tested, integrated,
and executable system. Each iteration includes its own
requirements analysis, design, implementation, and
testing activities.
Requirements
D esign
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
Requirements
D esign
4 weeks (for example)
The system grows
incrementally.
Feedback from
iteration N leads to
refinement and
adaptation of the
requirements and
design in iteration
N+1.
Iterations are fixed in
length, or tim eboxed .
T im e
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
25
Iterations
 Each iteration must result in production quality
code. This implies that each iteration includes
exhaustive testing!
 The code may be incomplete (e.g., with stubs for
functions identified but not yet implemented).
 Note the contrast with rapid prototyping
methodologies.
 Early iterations should address high-risk parts of
the system.
26
Example
in a three-week iteration early in the project, perhaps one hour
Monday morning is spent in a kickoff meeting with the team clarifying
the tasks and goals of the iteration. Meanwhile, one person reverseengineers
the last iteration's code into UML diagrams (via a CASE
tool), and prints and displays noteworthy diagrams. The team spends
the remainder of Monday at whiteboards, working in pairs while agile
modeling, sketching rough UML diagrams captured on digital
cameras, and writing some pseudocode and design notes. The
remaining days are spent on implementation, testing (unit,
acceptance, usability, …), further design, integration, and daily builds
of the partial system. Other activities include demonstrations and
evaluations with stakeholders, and planning for the next iteration.
We should avoid:
 A rush to code
 A long drawn-out design step that attempts to perfect all details
of the design before programming.
27
Benefits of iterative development
 less project failure, better productivity, and lower
defect rates
 early rather than late mitigation of high risks
 early visible progress
 early feedback
 user engagement, and adaptation, leading to a refined
system that more closely meets the real needs of the
stakeholders
 managed complexity
 the learning within an iteration can be methodically
used to improve the development process itself,
iteration by iteration
28
Agile Methods
 Agile development methods usually apply
timeboxed iterative and evolutionary
development, employ adaptive planning, promote
incremental delivery, and include other values
and practices that encourage agility rapid and
flexible response to change.
29
Agile Process Example
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
2 0 %
2%
requirements
software
3 0 %
5%
requirements
software
5 0 %
8%
9 0 % 9 0 %
2 0 %
1 0 %
requirements workshops
Imagine this will
ultimately be a 2 0 -
iteration project.
In evolutionary iterative
development, the
requirements evolve
over a set of the early
iterations, through a
series of requirements
workshops (for
example) . Perhaps
after four iterations and
workshops, 9 0 % of the
requirements are
defined and refined.
Nevertheless, only
1 0 % of the software is
built.
1 2 3 4 5 ... 2 0
week 1
M T W T h F
week 2
M T W T h F
week 3
M T W T h F
kickoff meeting
clarifying iteration
goals with the team.
1 hour
team agile
modeling &
design,
UML
whiteboard
sketching.
5 h o u rs
start
coding &
testing
a 3-week iteration
d e -scope
iteration
goals if
too much
w o rk
final check-in
and codefreeze
for the
iteration
baseline
demo and
2-day
requirements
workshop
next
iteration
planning
meeting;
2 h o u rs
Most OOA/D and
applying UML during
this period
U s e -case modeling
during the workshop
30
The Agile Principles ( Not in Details)
 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
 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.
31
The Agile Principles
 7. Working software is the primary measure of progress.
 8. Agile processes promote sustainable development.
 9. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
 10. Continuous attention to technical excellence and good
design enhances agility.
 11. Simplicity the art of maximizing the amount of work not
done is essential.
 12. The best architectures, requirements, and designs
emerge from self-organizing teams.
 13. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
32
UP Best Practices and Concepts
 tackle high-risk and high-value issues in early
iterations
 continuously engage users for evaluation, feedback,
and requirements
 build a cohesive, core architecture in early iterations
 continuously verify quality; test early, often, and
realistically
 apply use cases
 model software visually (with the UML)
 carefully manage requirements
 practice change request and configuration
management
33
The UP Phases
A UP project organizes the work and iterations across
four major phases:
 1. Inception
 approximate vision, business case, scope, vague estimates.
 2. Elaboration
 refined vision, iterative implementation of the core
architecture, resolution of high risks, identification of most
requirements and scope, more realistic estimates.
 3. Construction
 iterative implementation of the remaining lower risk and
easier elements, and preparation for deployment.
 4. Transition
 beta tests, deployment.
34
Schedule-oriented terms in the UP
in c. elaboration construction transition
iteration p h a se
development cycle
release
A stable executable
subset of the final
product. The end of
each iteration is a
minor release.
increment
The difference
(delta) between the
releases of 2
subsequent
iterations.
final production
release
At this point, the
system is released
for production use.
m ilestone
An iteration endpoint
when some
significant decision
or evaluation
occurs.
35
Inception
Purpose:
 Establish some initial common vision for the objectives of
the project,
 Determine if it is feasible, and
 Decide if it is worth some serious investigation in
elaboration.
 The good idea—specifying the end-product vision and its
business case and defining the scope of the project
 Concluded by the lifecycle objective (LCO) milestone
Inception
Elaboration
Construction
Transition
36
Inception phase
 Lasts for one iteration
 Is basically a feasibility study
 Doesn't involve requirements analysis
 Identify most important Use Cases
 Write Vision
 Write Business Case & Development Case
37
Objectives of the Inception Phase
 Establish the project’s software scope and
boundary conditions
 Discriminate critical use cases of the system
 Exhibit at least one candidate architecture
 Estimate overall cost and schedule for entire
project
 Estimate risks
38
Activities of the Inception Phase
 Formulate scope of project
 Plan and prepare business case
 Evaluate alternatives for risk management,
staffing, project plan, and trade-offs between cost,
schedule, and profitability
 Synthesize candidate architecture
 Evaluate trade-offs in design and assess
make/buy/reuse decisions so that cost, schedule,
and resources can be estimated
39
Outcome of the Inception Phase
 Vision document
 Use-case model survey
 Initial project glossary
 Initial business case
 Business context
 Success criteria
 Financial forecast
 Initial risk assessment
 Project plan, which shows phases / iterations
40
Milestone: Lifecycle Objective
 Evaluation criteria for inception phase:
 Stakeholder concurrence on scope definition and
cost and schedule estimates
 Requirements understanding – evidenced by fidelity
of primary use cases
 Credibility of cost and schedule estimates, priorities,
risks, and development process
 Depth / breadth of any architectural prototype
 Actual expenditures versus planned expenditures
Inception
Elaboration
Construction
Transition
Lifecycle
Objective
41
Rational Unified Process – Inception
Business Modeling
B u s i n e s M o d e l i n g
Requirements
R e q u i r e m e n t s
Analysis & Design
Workflows
W o r k f l o w s
Inceptio
n
Elaboration
Phases
Construction
Transiti
on
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
P r o j e c t M a n a g e m e n t
Environment
E n v i r o n m e n t
Iterations
Initial
E
#
1
E
#
2
C
# 1
C
# 2
C
#
n
T
#1
T
#2
Content
Time
42
Elaboration Phase
 Purpose: analyze problem domain, establish a sound
architectural foundation, develop project plan, and eliminate
project’s highest-risk elements
 An executable architecture prototype built in one or more
iterations
 address critical use cases identified in inception phase –
expose project’s major technical risks.
Inception
Elaboration
Construction
Transition
43
Elaboration phase
 Multiple iterations
 Mainly analysis
 Flesh out Use Cases
 Add more Use Cases
 Supplemental specification
 Glossary
 Lots of customer involvement
 Some design
 Some implementation
 Wide, rather than high, implementation
44
Objectives of the Elaboration Phase
 Define, validate, and baseline the architecture as
rapidly as practical
 Baseline the vision
 Baseline a high fidelity plan for the construction
phase
 Demonstrate that the baseline architecture will
support this vision for a reasonable cost in a
reasonable time
45
Activities of the Elaboration Phase
 Vision is elaborated
 A solid understanding is established of the most
critical use cases
 The process, infrastructure, and development
environment are elaborated
 The architecture is elaborated and the
components are selected
46
Outcomes of the Elaboration Phase
 A use-case model in which all use cases have
been identified in the use-case model survey, all
actors have been identified, and most use-case
descriptions have been developed
 Supplementary requirements that capture the
nonfunctional requirements and any requirements
that are not associated with the specific use case
47
Outcomes of the Elaboration Phase (continue)
 A software architecture description
 An executable architectural prototype
 A revised risk list and a revised business case
 A development plan for the overall project
 An updated development case that specifies the
process to be used
 A preliminary user manual (optional)
48
Milestone: Lifecycle Architecture
 Examine
 detailed system objectives and scope
 choice of architecture
 resolution of major risks
Inception
Elaboration
Construction
Transition
Lifecycle
Architecture
49
Evaluation Criteria
 Is the vision of the product stable?
 Is the architecture stable?
 Does the executable demonstration show that the major
risk elements have been addressed and credibly resolved?
 Is the construction phase plan sufficiently detailed and
accurate? Is it backed up with a credible basis for the
estimates?
 Do all stakeholders agree:
 current vision can be achieved if the current plan is
executed to develop the complete system, in the context
of the current architecture?
 Is the actual resource expenditure versus planned
expenditure acceptable?
50
Rational Unified Process – Elaboration
Business Modeling
B u s i n e s M o d e l i n g
Requirements
R e q u i r e m e n t s
Analysis & Design
A n a l y s i s & D e s i g n
Workflows
W o r k f l o w s
Inceptio
n
Elaboration
Phases
Construction
Transiti
on
Implementation
I m p l e m e n t a t i o n
Test
T e s t
Deployment
Configuration &
C o n f i g u r a t i o n &
Change Management
C h a n g e M a n a g e m e n t
Project Management
P r o j e c t M a n a g e m e n t
Environment
E n v i r o n m e n t
Iterations
Initial
E
#
1
E
#
2
C
# 1
C
# 2
C
#
n
T
#1
T
#2
Content
Time
51
The Construction Phase
 Purpose: all remaining components and
application features are developed and integrated
into the product, and all features are tested
thoroughly
Inception
Elaboration
Construction
Transition
52
Construction phase
 Multiple iterations
 Some analysis
 Mainly design and implementation
 Add additional paths to Use Cases
53
Objectives of the Construction Phase
 Minimize development costs by optimizing
resources and avoiding unnecessary scrap and
rework
 Achieve adequate quality as rapidly as practical
 Achieve useful versions (
, 
, and other test
releases) as rapidly as practical
54
Activities of the Construction Phase
 Resource management, resource control, and
process optimization
 Complete component development and testing
against the defined evaluation criteria
 Assessment of product releases against
acceptance criteria for the vision
55
Outcome of the Construction Phase
 Product ready to put in the hands of its end users
 Product consists of
 Software product itself – integrated on the
adequate platforms
 User manuals
 Description of the current release
56
Milestone: Initial Operational Capability
 Decide whether software, sites, and users are
ready to become operational without exposing
project to high risks
 Called a b
b
release

N.B. b
. b
release often confused with a test
Inception
Elaboration
Construction
Transition
Initial
Operational
Capability
57
Evaluation Criteria for the Construction Phase
 Is this product release stable and mature enough
to be deployed in the user community?
 Are all stakeholders ready for the transition into
the user community?
 Are the actual resource expenditures versus
planned expenditures still acceptable?
58
Rational Unified Process – Construction
Business Modeling
B u s i n e s M o d e l i n g
Requirements
R e q u i r e m e n t s
Analysis & Design
A n a l y s i s & D e s i g n
Workflows
W o r k f l o w s
Inceptio
n
Elaboration
Phases
Construction
Transiti
on
Implementation
I m p l e m e n t a t i o n
Test
T e s t
Deployment
D e p l o y m e n t
Configuration &
C o n f i g u r a t i o n &
Change Management
C h a n g e M a n a g e m e n t
Project Management
P r o j e c t M a n a g e m e n t
Environment
E n v i r o n m e n t
Iterations
Initial
E
#
1
E
#
2
C
# 1
C
# 2
C
#
n
T
#1
T
#2
Content
Time
59
Transition Phase
 Purpose: move software product into user
community
 Occurs when baseline mature enough to be
deployed in the end-user domain
 some useable subset has been completed to an
acceptable level of quality
 user documentation is available so transition to
user will provide positive results for all parties
Inception
Elaboration
Construction
Transition
60
Transition phase
 Several iterations
 Beta testing
 Deployment
 Development of support artifacts
 Beta testing to validate the new system against user
expectations
 Parallel operation with the legacy system that the project is
replacing
 Conversion of operational databases
 Training of users and maintainers
 Rollout of the product to the marketing, distribution, and
sales teams
61
Objectives of the Transition Phase
 Achieve user self-supportability
 Achieve stakeholder concurrence that deployment
baselines are complete and consistent with the
evaluation criteria of the vision
 Achieve the final product baseline as rapidly and
cost-effectively as practical
62
Activities of the Transition Phase
 Deployment-specific engineering – cutover,
commercial packaging and production, sales
rollout, and field personnel training
 Tuning activities, including bug fixing and
enhancement for performance and usability
 Assessing the deployment baselines against the
vision and the acceptance criteria for the product
63
Milestone: Product Release
 Decide whether
 objectives were met
 another development cycle should start
 This milestone may coincide with the end of the
inception phase for the next cycle
Inception
Elaboration
Construction
Transition
Product
Release
64
Evaluation Criteria
 Evaluation criteria for transition phase
includes:
 Is the user satisfied?
 Are actual resources expenditures versus
planned expenditures still acceptable?
65
Rational Unified Process – Transition
Business Modeling
Requirements
Analysis & Design
Workflows
W o r k f l o w s
Inceptio
n
Elaboration
Phases
Construction
Transiti
on
Implementation
I m p l e m e n t a t i o n
Test
T e s t
Deployment
D e p l o y m e n t
Configuration &
C o n f i g u r a t i o n &
Change Management
C h a n g e M a n a g e m e n t
Project Management
P r o j e c t M a n a g e m e n t
Environment
E n v i r o n m e n t
Iterations
Initial
E
#
1
E
#
2
C
# 1
C
# 2
C
#
n
T
#1
T
#2
Content
Time
66
Timeline for Initial Development Cycles
I
10%
E
30%
C
50%
T
10%
Time
67
Iterations, Releases, and Milestones
Inception
Elaboration
Construction
Transition
Time
Iteration
#1
Iteration
#2
Iteration
#3
Iteration
#4
Iteration
#5
Iteration
#6
Iteration
#7
Iteration
#8
Internal
Release
Minor
Milestone
First External
Release
(e.g., “
”)
Final
Release
68
The UP Disciplines
 A discipline is a set of activities (and related artifacts –
Work Products) in one subject area
 Business Modeling
 When developing a single application, this includes
domain object modeling. When engaged in large-scale
business analysis or business process reengineering,
this includes dynamic modeling of the business
processes across the entire enterprise.
 Requirements
 Requirements analysis for an application, such as
writing use cases and identifying non-functional
requirements.
 Design
 All aspects of design, including the overall architecture,
objects, databases, networking, and the like.
69
The UP Disciplines
 UP involves a lot of disciplines (not just programming):
 Business Modeling
 Requirements
 Design
 Implementation
 Project Management
 Testing
 Environment
 Deployment
 Configuration
 Change Management
 …and more…
70
Rational Unified Process – Two Dimensions
Business Modeling
Requirements
Analysis & Design
Workflows
W o r k f l o w s
Inception
Elaboration
Phases
Construction
Transition
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
Iterations
Initial
E
#
1
E
#
2
C
#
1
C
#
2
C
#
n
T
#1
T
#2
Content
Time
71
UP artifacts
 UP includes dozens of artifact types, including:
 Vision
 Business Case
 Development Case -- Choice of artifacts for a project,
discipline & schedule for each.
 Phase Plan -- What activities and artifacts will be done
in each phase?
 Iteration Plan -- Exactly what use cases, etc will be done
in each iteration?
 Use Case
 Domain Model
 State Diagram
72
UP artifacts (continued)
 More UP artifacts:
 Design Model
 Data Model
 Supplementary Specification
 Glossary
 Risk List
 Risk Management Plan
 Prototype
 Software Architecture Document
 Implementation Model
 Test Model
73
UP artifacts (continued)
 Almost all artifacts are optional.
 Formats of artifacts are fairly loose.
 Create only those which add value to your final
product.
 In your semester project, you won't get to choose
-- certain artifacts are required.
74
You Know You Didn't Understand UP When…
 You try to define most of the requirements before starting design or
implementation.
 try to define most of the design before starting implementation;
 try to fully define and commit to an architecture before iterative
programming and testing.
 You spend days or weeks in UML modeling before programming, or
you think UML diagramming and design activities are a time to fully
and accurately define designs and models in great detail.
 you regard programming as a simple mechanical translation of these into
code.
 You think that inception = requirements, elaboration = design, and
construction = implementation.
 You think that the purpose of elaboration is to fully and carefully define
models, which are translated into code during construction.
 You believe that a suitable iteration length is three months long, rather
than three weeks long.
 You think that adopting the UP means to do many of the possible
activities and create many documents, and you think of or experience
the UP as a formal, fussy process with many steps to be followed.
 You try to plan a project in detail from start to finish; you try to
speculatively predict all the iterations, and what should happen in each
one.