Best Practices of Software Engineering
Objectives: Best Practices of SE • Explore the symptoms and root causes of software development problems • Explain Rational’s six best practices for software development • Look at how Rational’s best practices address the root causes of software development problems
Software Development Situation Analysis
World economies increasingly software dependent
Applications expanding in size, complexity, & distribution
Business demands increased productivity & quality in less time
Not enough qualified people
Software Development is a Job for Teams Challenges Performance Engineer
• Larger teams • Specialization • Distribution
Analyst
• Rapid technology change
Project Manager
Developer Tester Release Engineer
How Are We Doing? Performance Engineer
Analyst
Project Manager
Developer Tester Release Engineer
Symptoms of Software Development Problems • • • • • • • •
Inaccurate understanding of end-user needs Inability to deal with changing requirements Modules that don’t fit together Software that’s hard to maintain or extend Late discovery of serious project flaws Poor software quality Unacceptable software performance Team members in each other’s way, unable to reconstruct who changed what, when, where, why • An untrustworthy build-and-release process
Treating Symptoms Does Not Solve the Problem Root Causes
Symptoms
insufficient requirements
end-user needs
ambiguous communications
changing requirements
brittle architectures
modules don’t fit
overwhelming complexity
hard to maintain late discovery
undetected inconsistencies
poor quality
poor testing
poor performance
subjective assessment
colliding developers build-and-release
Diagnose
waterfall development uncontrolled change insufficient automation
Root Causes of Software Development Problems • • • • • • • • • •
Insufficient requirements management Ambiguous and imprecise communications Brittle architectures Overwhelming complexity Undetected inconsistencies among requirements, designs, and implementations Insufficient testing Subjective project status assessment Delayed risk reduction due to waterfall development Uncontrolled change propagation Insufficient automation
Best Practices Address Root Causes Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Best Practices Develop iteratively Manage requirements Use component architectures Model the software visually Verify quality Control changes
Addressing Root Causes Eliminates the Symptoms Symptom s end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-andrelease
Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity
Best Practices develop iteratively manage requirements use component architectures
undetected inconsistencies
model the software visually
poor testing
verify quality
subjective assessment
control changes
waterfall development uncontrolled change insufficient
Best Practices of Software Engineering
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Best Practices Enable High-Performance Teams Results • More Successful projects
Performance Engineer
Analyst
Project Manager
Developer Develop Iteratively
Tester Use Manage Component Requirements Architectures
Control Changes
Model Visually
Verify Quality
Release Engineer
Practice 1: Develop Software Iteratively Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Practice 1: Develop Software Iteratively • An initial design will likely be flawed with respect to its key requirements • Late-phase discovery of design defects results in costly over-runs and/or project cancellation
The time and money spent implementing a faulty design are not recoverable
Waterfall Development Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing
T I M E
Waterfall Development Delays Reduction of Risk R I S K
Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing
T I M E
Apply the Waterfall Iteratively to System Increments Iteration 1
Iteration 2
R
Iteration 3
R D
R D
C
D C
T
C T
T
T I M E
• Earliest iterations address greatest risks • Each iteration produces an executable release, an additional increment of the system • Each iteration includes integration and test
Iterative Development Accelerates Risk Reduction
R I S K
Iterative
Waterfall
Iteration Iteration Iteration Iteration Iteration Iteration Iteration
T I M E
Iterative Development Characteristics • Critical risks are resolved before making large investments • Initial iterations enable early user feedback • Testing and integration are continuous • Objective milestones provide short-term focus • Progress is measured by assessing implementations • Partial implementations can be deployed
Apply Best Practices Throughout the Life Cycle Phases Process Workflows
Inception Elaboration
Construction
Transition
Business Modeling Requirements Analysis & Design Implementation Test Deployment
Supporting Workflows Configuration Mgmt Management Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. Iter. #n+1 #n+2
Iterations
Iter. #m
Iter. #m+1
Problems Addressed by Iterative Development Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Solutions Enables and encourages user feedback Serious misunderstandings evident early in the life cycle Development focuses on critical issues Objective assessment thru testing Inconsistencies detected early Testing starts earlier Risks identified and addressed early
Practice 2: Manage Requirements Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Practice 2: Manage Requirements • Elicit, organize, and document required functionality and constraints • Evaluate changes and determine their impact • Track and document tradeoffs and decisions Requirements are dynamic -Expect them to change during software development
Definitions: Requirements and Their Management • A requirement is a condition or capability to which the system must conform • Requirements management is a systematic approach to – Eliciting, organizing, and documenting the requirements of the system, and – Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system
Agreement on What the System Should Do The Goal
Customer User Community
System To Be Built
Requirements Verification
Adapted from Al Davis
Surrogate Goal
Requirements
Requirements Trace To Many Project Elements
How To Catch Requirements Errors Early • Effective problem analysis and elicitation of user needs • Gain agreement with the customer/user on the requirements • Model interaction between the user and the system • Establish a baseline and change control process • Maintain forward and backward traceability of requirements • Use an iterative process
Problems Addressed by Requirements Man Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Solutions
A disciplined approach is built into requirements management Communications are based on defined requirements Requirements can be prioritized, filtered, and traced Objective assessment of functionality and performance Inconsistencies are more easily detected RM tool provides a repository for requirements, attributes and tracing, with automatic links to documents
Practice 3: Use ComponentBased Architectures Develop Iteratively
Manage Use Verify Requirements Component Quality Architectures
Model Visually
Control Changes
Verify Quality
Software Architecture Defined • Software architecture encompasses significant decisions about the organization of a software system – Selection of the structural elements and their interfaces by which a system is composed – Behavior as specified in collaborations among those elements – Composition of these structural and behavioral elements into progressively larger subsystems – Architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition
Architectural Concerns • Software architecture is concerned with structure and behavior and context: – Usage – Functionality – Performance – Resilience – Reuse – Comprehensibility – Economic and technological constraints and tradeoffs – Aesthetics
Resilient, Component-Based Architectures • Good architectures meet their requirements, are resilient, and are component-based • A resilient architecture enables – Improved maintainability and extensibility – Economically-significant reuse – Clean division of work among teams of developers – Encapsulation of hardware and system dependencies • A component-based architecture permits – Reuse or customization of existing components – Choice of thousands of commercially-available components – Incremental evolution of existing software
Example: Component-Based Architecture Lead Tracking User Interface
Licensing User Interface
User Interface Mechanisms Customer
Key: - Purchased - Built - New
Oracle
Product
Vantive
License
Problems Addressed by Component Architectures Solutions Root Components facilitate resilient architectures Causes
Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Reuse of commercially available components and frameworks is facilitated Modularity enables separation of concerns Components provide a natural basis for configuration management Visual modeling tools provide automation for component-based design
Practice 4: Visually Model Software Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Practice 4: Visually Model Software • Capture the structure and behavior of architectures and components • Show how the elements of the system fit together • Hide or expose details as appropriate for the task • Maintain consistency between a design and its implementation • Promote unambiguous communication Visual modeling improves our ability to manage software complexity
What Is the UML? • The Unified Modeling Language (UML) is a language for • • • •
Specifying Visualizing Constructing Documenting
the artifacts of a software-intensive system
Diagrams Are Views of a Model A model is a complete description of a system from a particular perspective Use Case Use Case Diagrams Activity Diagrams Diagrams
Scenario Scenario Diagrams Sequence Diagrams Diagrams
Scenario Scenario Diagrams Collaboration Diagrams Diagrams
Use Case Use Case Diagrams Use Case Diagrams Diagrams
State State Diagrams Class Diagrams Diagrams
Model
Deployment Diagram
State State Diagrams Object Diagrams Diagrams
State State Diagrams State Diagrams Diagrams
Component Component Diagrams Component Diagrams
Diagrams
Visual Modeling Using UML Diagrams Use-Case Diagram
Class Diagram
State Diagram
add file
DocumentList FileMgr
Document add( ) delete( )
fetchDoc( ) sortByName( )
name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( )
FileList
Use Case 1
fList add( ) delete( )
Actor A
Openning
close file
1
Actor B close file Reading
Closing
rep
Use Case 2
File
Repository (from Persistence)
read( )
<<entity>> Customer name addr receive() withdraw() fetch() send()
GrpFile
name : char * = 0 read( ) open( ) create( ) fillFile( )
readDoc( ) readFile( )
Domain Expert
Writing
add file [ numberOffile==MAX ] / flag OFF
read() fill the code..
Use Case 3
Deployment Diagram
UI
Class
MFC
DocumentApp ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼-¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö
RogueWave
Repository
Persistence
9: sortByName ( )
DocumentList
Windows95
Window95
Windows95
global
User Interface Definition
FileManager
mainWnd : MainWnd 1: Doc view request ( )
¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE
L
2: fetchDoc( )
gFile : GrpFile
4: create ( ) 8: fillFile ( )
user : »ç¿ëÀÚ fileMgr : FileMgr
Package Diagram
¹®¼-°ü¸® ¾ÖÇø´
Windows NT
Document
Solaris
¹®¼-°ü¸® ¿£Áø.EXE
Alpha UNIX ÀÀ¿ë¼-¹ö.EXE Windows NT
GraphicFile
3: create ( )
File
IBM Mainframe
FileList
6: fillDocument ( ) µ¥ÀÌŸº£À̽º¼-¹ö
7: readFile ( ) 5: readDoc ( )
document : Document
repository : Repository
Collaboration Diagram mainWnd user
ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡¿äûÇÑ´Ù.
fileMgr : FileMgr
document : Document
gFile
Component Diagram
Forward Engineering (Code Generation) and Reverse Engineering
repository
Source Code edit, compile, debug, link
1: Doc view request ( )
2: fetchDoc()
3: create ( )
4: create ( )
5: readDoc ( )
È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
È-¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°· Î Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡ º¸¿©ÁØ´Ù.
9: sort ByName ( )
Sequence Diagram
Executable System
Problems Addressed by Visual Modeling Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Solutions
Use cases and scenarios unambiguously specify behavior Models capture software designs unambiguously Non-modular or inflexible architectures are exposed Unnecessary detail hidden when appropriate Unambiguous designs reveal inconsistencies more readily Application quality starts with good design Visual modeling tools provide support for UML modeling
Practice 5: Verify Software Quality Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Practice 5: Verify Software Quality
Software problems are 100 to 1000 times more costly to find and repair after deployment Cost
Development
Deployment
Iterative Development Permits Continuous Testing Iteration 1
Iteration 2
R
R D
R D
C
T I M E
Iteration 3 D
C
C
T
T
T
Test
Test
Test
Automated Tests
Requirements
Testing in an Iterative Environment
Iteration 1
Iteration 2 Iteration 3
Iteration 4
Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4
Automation Reduces Testing Time and Effort One Manual Test Cycle 13,000 Tests 2 Weeks
6 People
Test Automation 13,000 Tests 6 hours 1 Person
Run More Tests More Often
Dimensions of Software Quality Type
Why?
How?
Reliability
Does my app leak memory?
Analysis tools and code instrumentation
Functionality
Does my app do what’s required?
Test cases for each scenario implemented
Application Performance
Does my app respond acceptably?
Check performance for each use case/scenario implemented
System Performance
Does my system perform under production load?
Test performance of all use cases under authentic and worst-case load
Problems Addressed by Verifying Quality Root Causes
Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Solutio Testing provides objective ns project status assessment Objective assessment exposes inconsistencies early Testing and verification are focused on high risk areas Defects are found earlier and are less expensive to fix Automated testing tools provide testing for reliability, functionality, and performance
Practice 6: Control Changes to Software Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Control Changes
Verify Quality
Practice 6: Control Changes to Software • • • • • • •
Multiple developers Multiple teams Multiple sites Multiple iterations Multiple releases Multiple projects Multiple platforms
Without explicit control, parallel development degrades to chaos
Three Major Aspects of a CM System
Concepts of Configuration & Change Management • Decompose the architecture into subsystems and assign responsibility for each subsystem to a team • Establish secure workspaces for each developer – Provide isolation from changes made in other workspaces – Control all software artifacts - models, code, docs, etc. • Establish an integration workspace • Establish an enforceable change control mechanism • Know which changes appear in which releases • Release a tested baseline at the completion of each iteration
Change Control Supports All Other Best Practices •
Develop iteratively
•
Manage requirements • Use component architectures
Progress is incremental only if changes to artifacts are controlled To avoid scope creep, identify, assess and approve all changes Components must be reliable, i.e., the correct versions of all constituent parts found
•
Model visually
To assure convergence, incrementally control models as designs stabilize
•
Verify quality
Tests are only meaningful if the versions of the items under test are known and the items protected from changes
Problems Addressed by Controlling Changes Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
Soluti ons Requirements change workflow is defined and repeatable Change requests facilitate clear communications Isolated workspaces reduce interference from parallel work Change rate statistics are good metrics for objectively assessing project status Workspaces contain all artifacts, facilitating consistency Change propagation is controlled Changes maintained in a robust, customizable system
Best Practices Reinforce Each Other
Develop Iteratively
Ensures users involved as requirements evolve
Manage Requirements
Validates architectural decisions early on
Use Component Architectures
Addresses complexity of design/implementation incrementally Measures quality early and often
Evolves baselines incrementally
Model Visually
Verify Quality
Control Changes
Summary: Best Practices of Software Engineering •
The result is software that is – On Time – On Budget – Meets Users Needs
Performance Engineer
Analyst
Project Manager Develop Iteratively
Use Manage Component Requirements Architectures
Control Changes
Model Visually
Developer Verify Quality
Tester Release Engineer