Continuing Best PracticesContinuing Best Practices
►Slide information taken in large part Slide information taken in large part from former Rational Corporation from former Rational Corporation slides and the RUP textbook - slides and the RUP textbook - considerably modified and considerably modified and supplemented for classroom use.supplemented for classroom use.
►Additional information taken from Additional information taken from other sources.other sources.
Practice 2: Manage Practice 2: Manage RequirementsRequirements
Control Changes
Develop Iteratively
Use Component
ArchitecturesManage Manage
RequirementsRequirements
Model Visually
VerifyQuality
A report by Standish Group cites forty percent of software projects fail. According to them, the mail causes of failure are: (note: there are others…) poor requirements management; ((eliciting) capturing, (documenting)
modeling, verification; prototyping…)incorrect definition of requirements
from the start of the project; and (feedback, verification…)poor requirements management throughout the development lifecycle. (handling Change!!! Addressing Risk)(Source: Chaos Report, http://www.standishgroup.com).
Requirements are dynamic -- Expect them to change during software development
Change cannot be stopped, but it can be managed!!
Practice 2: Manage Practice 2: Manage RequirementsRequirements
► Elicit, organize, and document Elicit, organize, and document required functionality and constraintsrequired functionality and constraints
► Evaluate changes and determine impactsEvaluate changes and determine impacts► Track and document tradeoffs and Track and document tradeoffs and decisions decisions ► Getting comprehensive system Getting comprehensive system requirements is a requirements is a continuous processcontinuous process► Obtaining a complete, exhaustive set of Obtaining a complete, exhaustive set of
requirements prior to development is requirements prior to development is impossible! (except for trivial applications)impossible! (except for trivial applications)
Definitions: Requirements and Their Definitions: Requirements and Their ManagementManagement
► AA requirement requirement is a condition or capability to which the is a condition or capability to which the system must conformsystem must conform
► Requirements managementRequirements management is a systematic approach to is a systematic approach to Eliciting, organizing, and documenting the requirements of the Eliciting, organizing, and documenting the requirements of the
system, & system, & Establishing and maintaining agreement between the customer/user Establishing and maintaining agreement between the customer/user
and the project team on the changing requirements of the systemand the project team on the changing requirements of the system
► Requirements specify ‘Requirements specify ‘whatwhat’ the system must do - not how!’ the system must do - not how!
► Requirements Management will be successful only if it Requirements Management will be successful only if it allows for uncertainty early in developmentallows for uncertainty early in development
► Requirements Management must ensure Requirements Management must ensure requirements requirements coveragecoverage over time. (What does this mean to you?) over time. (What does this mean to you?)
How To Catch Requirements How To Catch Requirements Errors Errors EarlyEarly
► Effectively analyze the problem and elicit user needs Effectively analyze the problem and elicit user needs
► Gain agreementGain agreement with the customer/user on the requirements with the customer/user on the requirements
► ModelModel interaction interaction between the user and the system between the user and the system
► Establish a baseline and change control processEstablish a baseline and change control process
► Maintain forward and backward Maintain forward and backward traceabilitytraceability of requirements of requirements
► Use an Use an iterative development processiterative development process
► Create a ‘Create a ‘sharablesharable’ model with customers’ model with customers
► For a given iteration, For a given iteration, all requirements need not be known up all requirements need not be known up frontfront; however, before ; however, before developingdeveloping that iteration, all that iteration, all requirements should be known.requirements should be known.
Problems Addressed by Requirements Problems Addressed by Requirements ManagementManagement
Root CausesRoot Causes SolutionsSolutionsA 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
Insufficient Insufficient requirementsrequirements
Ambiguous Ambiguous communicationscommunications
Brittle architecturesBrittle architectures Overwhelming Overwhelming
complexitycomplexity Subjective assessment Subjective assessment Undetected Undetected
inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient Insufficient
automationautomation
Use Use Component Component
ArchitecturesArchitectures
Practice 3: Use Component-Based Practice 3: Use Component-Based ArchitecturesArchitectures
Control Changes
Develop Iteratively
Manage Requirements
Model Visually
VerifyQuality
Software architecture is a much misunderstood discipline by the industry
Some say that software architecture is the development product that yields the greatest ROI with respect to quality, schedule, and cost…
I wholeheartedly AGREE!
Software Architecture DefinedSoftware Architecture Defined► Software architectureSoftware architecture addresses major addresses major
decisionsdecisions about the about the organizationorganization of a of a software system.software system.
Selection of the Selection of the structural elementsstructural elements and their and their interfacesinterfaces by which a system is composed by which a system is composed (packages, subsystems, …)(packages, subsystems, …)
► Addresses how the application will be built….Addresses how the application will be built….► Behavior as specified in collaborations among those elementsBehavior as specified in collaborations among those elements► Composition of these structural and behavioral elements into Composition of these structural and behavioral elements into
progressively larger subsystemsprogressively larger subsystems
Architectural style guides Architectural style guides thisthis organization, these organization, these elements and their interfaces, their collaborations, elements and their interfaces, their collaborations, and their compositionand their composition
Architecture is part of design – addresses questions Architecture is part of design – addresses questions on on HOWHOW the system will be built. the system will be built.
Resilient, Component-Based Resilient, Component-Based
ArchitecturesArchitectures ► Good architectures meet their requirements, are Good architectures meet their requirements, are
resilient,resilient, and are and are component-basedcomponent-based ► A A resilientresilient architecture enables architecture enables
Improved maintainability and extensibilityImproved maintainability and extensibility Economically-significant reuseEconomically-significant reuse Clean division of work among teams of developersClean division of work among teams of developers Encapsulation of hardware and system dependenciesEncapsulation of hardware and system dependencies
► A A component-basedcomponent-based architecture permits architecture permits Reuse or customization of existing components Reuse or customization of existing components Choice of thousands of commercially-available componentsChoice of thousands of commercially-available components Incremental evolution of existing softwareIncremental evolution of existing software
Problems Addressed by Component Problems Addressed by Component ArchitecturesArchitectures
Components facilitate Components facilitate resilient architectures resilient architectures
Reuse of commercially Reuse of commercially available components and available components and frameworks is facilitatedframeworks is facilitated
Modularity enables separation Modularity enables separation of concernsof concerns
Components provide a natural Components provide a natural basis for configuration basis for configuration managementmanagement
Visual modeling tools provide Visual modeling tools provide automation for component-automation for component-based designbased design
Root CausesRoot Causes SolutionsSolutions Insufficient requirementsInsufficient requirements Ambiguous Ambiguous
communicationscommunications
Brittle architecturesBrittle architectures Overwhelming Overwhelming
complexitycomplexity Subjective assessment Subjective assessment Undetected Undetected
inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development
Uncontrolled changeUncontrolled change Insufficient automationInsufficient automation
Practice 4: Visually Model SoftwarePractice 4: Visually Model Software
Control Changes
Develop Iteratively
Use Component
Architectures
Manage Requirements
VerifyQualityModel Model
VisuallyVisually
A Model is a simplification of reality that produces a complete description of something from a specific perspective.
We build models when we cannot fully comprehend the complexity of some things.
Modeling helps the development team visualize, specify, construct, and document thestructure and behavior of a system’s architecture.
We will use a standard modeling language, UML (Unified Modeling Language).
Visual modeling improves our abilityto manage software complexity
Practice 4: Visually Model SoftwarePractice 4: Visually Model Software
► Use to:Use to: Capture (model) both the structure (static) and behavior Capture (model) both the structure (static) and behavior
(dynamic) of architectures and components(dynamic) of architectures and components Show how the elements of system fit together and Show how the elements of system fit together and
collaborate to provide functionality (dependencies, etc.)collaborate to provide functionality (dependencies, etc.) Hide / expose details as appropriate for the task - Implies Hide / expose details as appropriate for the task - Implies
a hierarchy (helps greatly when dealing with a hierarchy (helps greatly when dealing with complexity…)complexity…)
Maintain consistency between a design and its Maintain consistency between a design and its implementationimplementation
Promote unambiguous communication via standard Promote unambiguous communication via standard modeling language, UMLmodeling language, UML
What Is the UML?What Is the UML?
►The Unified Modeling Language (UML) The Unified Modeling Language (UML) is a language foris a language for
►SpecifyingSpecifying►VisualizingVisualizing►ConstructingConstructing►DocumentingDocumenting
the the artifactsartifacts of a software-intensive of a software-intensive systemsystem
UML is an industry standard and is platform independent!It defines a graphical modeling language for presenting models and defines the semantics for each graphical element from different perspectives
Diagrams Are Views of a ModelDiagrams Are Views of a ModelA model is a completedescription of a systemfrom a particularperspective
DeploymentDiagrams
DeploymentDiagrams
use-caseDiagrams
use-caseDiagrams
ScenarioDiagrams
ScenarioDiagramsScenario
Diagrams
ScenarioDiagramsSequence
Diagrams
SequenceDiagrams
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsState
Diagrams
StateDiagrams
ComponentDiagrams
ComponentDiagramsComponent
Diagrams
ComponentDiagramsComponentDiagrams
ComponentDiagrams
Models
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsObject
Diagrams
ObjectDiagrams
ScenarioDiagrams
ScenarioDiagramsScenario
Diagrams
ScenarioDiagramsCollaboration
Diagrams
CollaborationDiagrams
ActivityDiagrams
ActivityDiagrams
StateDiagrams
StateDiagramsState
Diagrams
StateDiagramsClass
Diagrams
ClassDiagrams
Know these!!!!!
We use UML to provide nine different diagrams and five (4+1) major views: Use Case View, Logical View, Process View, Implementation View, and Deployment View
Explain:
Visual Modeling Using UML Visual Modeling Using UML DiagramsDiagrams
Actor A
use-case 1
use-case 2
Actor B
user : »ç¿ëÀÚ
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fillDocument ( )
4: create ( )
8: fillFile ( )
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
UI
MFC
RogueWave
global
DocumentApp
Persistence Window95
¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®.EXE
WindowsNT
¹®¼ °ü¸® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼ ¹ö.EXE
AlphaUNIX
IBM Mainframe
µ¥ÀÌŸº£À̽º¼ ¹ö
Windows95
¹®¼ °ü¸® ¾ÖÇø´
ºÐ»ê È °̄æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ̧ 𵨠- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö - À ´̄нº ̧ Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö
Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr : FileMgr
repositorydocument : Document
gFile
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
9: sortByName ( )
ƯÁ¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
È ÀÏ°ü̧ ®ÀÚ´Â Àоî¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È ̧é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ̧ §º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡
º¸¿©ÁØ´Ù.
Customernameaddr
withdraw()fetch()send()
receive()
<<entity>>
Forward Engineering (Code Generation)and
Reverse Engineering
Executable System
User InterfaceDefinition
Domain Expert
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close file
use-case 3
Source Code edit, compile, debug, link
Use-Case Diagram Class Diagram
Collaboration Diagram
Sequence Diagram
Component Diagram
State Diagram
Package Diagram
Deployment DiagramClass
Single, common modeling language used throughoutMaps the artifacts between business engineering, requirements capture, and analysis, design, and testing .
Problems Addressed by Visual Problems Addressed by Visual ModelingModeling
use-cases and scenarios use-cases and scenarios unambiguously specify unambiguously specify behaviorbehavior
Models capture software Models capture software designs unambiguously designs unambiguously
Non-modular or inflexible Non-modular or inflexible architectures are exposedarchitectures are exposed
Unnecessary detail hidden Unnecessary detail hidden when appropriatewhen appropriate
Unambiguous designs reveal Unambiguous designs reveal inconsistencies more readilyinconsistencies more readily
Application quality starts Application quality starts with with good designgood design
Visual modeling tools Visual modeling tools provide support for UML provide support for UML modelingmodeling
Root CausesRoot Causes SolutionsSolutions Insufficient Insufficient
requirementsrequirements Ambiguous Ambiguous
communicationscommunications Brittle architecturesBrittle architectures Overwhelming Overwhelming
complexitycomplexity Subjective assessmentSubjective assessment Undetected Undetected
inconsistenciesinconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient automationInsufficient automation