12-bestpractices[revisi]

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View 12-bestpractices[revisi] as PDF for free.

More details

  • Words: 2,649
  • Pages: 55
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