Presentation is loading. Please wait.

Presentation is loading. Please wait.

Systems Analysis and Design with UML: System Analysis

Similar presentations


Presentation on theme: "Systems Analysis and Design with UML: System Analysis"— Presentation transcript:

1 Systems Analysis and Design with UML: System Analysis
Romi Satria Wahono

2 Romi Satria Wahono SD Sompok Semarang (1987) SMPN 8 Semarang (1990)
SMA Taruna Nusantara, Magelang (1993) S1, S2 dan S3 (on-leave) Department of Computer Sciences Saitama University, Japan ( ) Research Interests: Software Engineering, Intelligent Systems Founder dan Koordinator IlmuKomputer.Com Peneliti LIPI ( ) Founder dan CEO PT Brainmatics Cipta Informatika

3 Contents Introduction Project Planning System Analysis System Design
System Implementation

4 System Analysis romi@romisatriawahono.net Object-Oriented Programming

5 Learning Objectives Understand how to create a requirements definition
Become familiar with requirements analysis techniques Understand when to use each requirements analysis technique Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation Understand when to use each requirements-gathering technique Understand the business process modeling

6 Processes and Deliverables
Object-Oriented Programming Processes and Deliverables Process Product Planning Analysis Design Implementation System Proposal System Specification New System with Testing/Maintenance Plan

7 System Analysis and Design with UML
Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Use Case Diagram Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) Activity Diagram (Buat untuk setiap use case bila diperlukan (optional)) System Design Program Design Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun) Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E) Deployment Diagramn (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

8 System Analysis and Design with UML
Business Process Modeling Activity Diagram Use Case Diagram Business Process Realization Sequence Diagram Activity Diagram (optional) System Design Program Design Class Diagram Package Diagram Deployment Diagram User Interface Design Entity-Relationship Model

9 Requirement

10 What is a Requirement Business Requirement
Statement of what the system must do Focus on what the system must do, not how to do it There are 2 kinds of requirements Functional Nonfunctional

11 Functional Requirement
Defines the functions of the system must carry out Specifies the process that must be performed Examples: Must search for inventory Must perform these calculations Must produce a specific report

12 Nonfunctional Requirements
Deals with how the system behaves: Operational – Physical/technical environment Performance – Speed and reliability Security – Who can use the system Cultural & Political – Company policies, legal issues

13 Requirements Definition
Report that lists the functional and nonfunctional requirements All requirements must be traceable back to business requirements

14

15 Requirement Gathering

16 Requirement Gathering Methods
Interviews Joint Application Design (JAD) Questionnaires Document Analysis Observation

17 1. Interviews

18 Interviews Most commonly used technique Very natural
If you need to know something, you ask someone

19 Interviews - Five Basic Steps
Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

20 1. Selecting Interviewees
Need an interview schedule list all people to be interviewed when each will be interviewed for what purpose they will be interviewed The list may be informal… or it may be part of the Analysis Plan List is based on information needed

21 1. Selecting Interviewees
Good to get different perspectives Managers Users Ideally, all key stakeholders Select people for political reasons Interviewing is iterative List often grows by 50% to 75 %

22 2. Designing Questions Don't ask for information that can be obtained elsewhere Want to show interviewee respect Will get better information anyway

23 2. Designing Questions Types of Questions Examples
Closed-Ended Questions * How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions * What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions * Why? * Can you give me an example? * Can you explain that in a bit more detail?

24 Closed-Ended Questions
Requires a specific answer Often multiple choice Good for specific, precise info not "are there a lot of requests?" but "how many requests are there?" Analyst is control Doesn't uncover "why"

25 Open-Ended Questions Leave room for elaboration
Gives interviewee more control Yields more rich, deep info

26 Probing Questions Follow-up questions For clarification
Encouraged to expand answer Show your listening and interested

27 3. Preparing for the Interview
Prepare for the interview in the same way you would for a presentation Prepare general interview plan List of question Anticipated answers and follow-ups Segues between related topics Confirm interviewee's area of knowledge Don't ask questions that can't be answered Set priorities in case of time shortage

28 3. Preparing for the Interview
Structured Interviews with closed-ended questions take longer Don't try to "wing it" will need follow-up interviews user's don't like you to waste their time

29 4. Conducting the Interview
Appear professional and unbiased Build rapport (and trust) with interviewee Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee

30 4. Conducting the Interview Practical Tips
Don’t worry, be happy Pay attention Summarize key points Be honest Watch body language

31 5. Post-Interview Follow-Up
Prepare interview notes Prepare interview report within 48 hours Get buy-in from interviewee Look for gaps and new questions

32 2. Joint Application Development (JAD)

33 JAD Key Ideas Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague

34 JAD Meeting Room JPEG Figure 5-5 Goes Here

35 The JAD Session Include 10 to 20 users
Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Stay neutral Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

36 3. Questionaires

37 Questionnaire Steps Selecting participants
Using samples of the population Designing the questionnaire More important than interview questions Prioritize questions to grab attention Distinguish between Fact-oriented questions (specific answers) Opinion questions (agree – disagree scale) Test the questionnaire on colleagues

38 Questionnaire Steps Administering the questionnaire
Need to get good response rate Explain its importance & how it will be used Give expected response date Follow up on late returns Have supervisors follow up Promise to report results Questionnaire follow-up Send results to participants

39 4. Document Analysis

40 Document Analysis Provides clues about the "formal" existing As-Is system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements Do document analysis before interviews

41 5. Observation

42 Observation Users/managers often don’t remember everything they do
Validates info gathered in other ways Behaviors change when people are watched Keep low profile, don’t change the process Careful not to ignore periodic activities Weekly … Monthly … Annual

43 Selecting the Appropriate Techniques
Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Integration Low High Low Low Low of Info. User Medium High Low Low Low Involvement Cost Medium Low Low Low Low- Medium Medium

44 Business Process Analysis

45 The SDLC Process

46 Business Process Analysis Steps
Understanding the “As-Is” system Identifying improvement opportunities Developing the “To-Be” system concept

47 1. Understanding the “As-Is” System
To-Be derived from As-Is Can’t focus just on what users want, need to understand what they need Can’t focus just on dry analysis, need to listen to users’ experience

48 2. Identifying Improvement Opportunities
Need business and technology skills Business skills Improvements in business processes improve what we do Technology skills improve how we do it

49 3. Developing the “To-Be” System Concept
Starts out as a fuzzy set of possible improvement ideas Refined into a viable system concept Proposal presented to approval committee in the form of a system walk-through

50 Business Process Analysis Strategies
BPA (Business Process Automation) BPI (Business Process Improvement) BPR (Business Process Reengineering)

51 Business Process Automation
Makes almost no changes to business processes Just makes them more efficient Improves efficiency by automating the business processes Least impact on users They do the same things, just more efficiently

52 Business Process Improvement
Goal is to improve the business processes Change what the users do, not just how efficiently they do it Changes to business process must be decided first Decisions to change the business processes cannot be made by the analyst

53 Business Process Reengineering
“Fundamental rethinking and radical redesign of business processes to achieve dramatic improvements…” Throw away everything Start with a blank page Appealing, but very expensive and risky

54 Automation Improvement Reeingineering
Strategy Comparation Business Business Business Process Process Process Automation Improvement Reeingineering Potential Business Low-Moderate Moderate High Value Project Cost Low Low-Moderate High Breadth of Analysis Narrow Narrow-Moderate Very Broad Risk Low Low-Moderate Very High

55 Business Process Modeling
Object-Oriented Programming Business Process Modeling

56 System Analysis and Design with UML
Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Use Case Diagram Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) Activity Diagram (Buat untuk setiap use case bila diperlukan (optional)) System Design Program Design Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun) Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E) Deployment Diagramn (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

57 System Analysis and Design with UML
Business Process Modeling Activity Diagram Use Case Diagram Business Process Realization Sequence Diagram Activity Diagram (optional) System Design Program Design Class Diagram Package Diagram Deployment Diagram User Interface Design Entity-Relationship Model

58 Business Process Modeling with Activity Diagrams
Elements of an Activity Diagram Guidelines for Creating Activity Diagrams

59 BPM With Activity Diagrams
A number of activities support a business process across several departments Activity diagrams model the behavior in a business process

60 Actions and Activities
Performed for a specific business reason Names begin with a verb and end with a noun “Make Appointment” Each activity normally associated with a use case

61 Object Nodes Activity and Actions usually modify objects
Object nodes model these objects Objects represent a flow of information from between activities or actions

62 Control & Object Flows Control Flows (solid line)
Paths of execution through the business process Can only be attached to actions or activities Object Flows (dashed line) Model the flow of objects through a business process Show actual objects entering and exiting the system An object is on one end, an action or activity is on the other end

63 Control Nodes Initial – Only one, at top left
Final Activity – Stop the process Final Flow – Stop this flow only Decision – Guarded test conditions Merge – Following decisions Fork – Split parallel execution Join – Join parallel execution

64 Swimlanes The business process may be broken into persons of responsibility Identify this with swimlanes

65 Activity Diagram Example

66 Creating Activity Diagrams
Set the context or scope of the activity being modeled Identify the activities and control/object flows between activities Identify any decisions made Look for opportunities for parallelism Draw the diagram

67 Business Process Modeling with BPMN

68 Building Block of BPMN

69 Process Model in BPMN

70 Routing of Tasks Sequential Parallel Conditional Iterative

71 Sequential Routing

72 Parallel Routing

73 Conditional Routing

74 Conditional Routing: Binary Choice

75 Conditional Routing: Exclusive Choice

76 Conditional Routing: Event-Based Choice

77 Iterative Routing

78 Events and Triggers

79 Event Types Used for Triggers

80 Data Objects and Annotations
a documents (operating procedures) a database any Information that is used or updated by the process

81 Cases and States: Intermediate Event

82 Organization Structure and Roles: Swimlanes

83 Recap of Building Blocks for BPMN

84

85 BPMN Notation Business Process Diagram Elements
Core Set of Diagram Elements Complete Set of Diagram Elements

86 Core Set of Diagram Elements
The core set of modeling elements enable the easy development simple Business Process Diagrams that will look familiar to most Business Analysts (a flowchart diagram)

87 Complete Set of Diagram Elements: Events
An Event is something that “happens” during the course of a business process These Events affect the flow of the Process and usually have a trigger or a result They can start, interrupt, or end the flow

88 Complete Set of Diagram Elements: Activities
An activity is work that is performed within a business process An activity can be atomic or non-atomic (compound) The types of activities that are a part of a Process Model are: Process Sub-Process Task

89 Complete Set of Diagram Elements: Activities
A Sub-Process can be in an expanded form that shows the process details of the a lower-level set of activities

90 Complete Set of Diagram Elements: Connections
A Sequence Flow is used to show the order that activities will be performed in a Process A Message Flow is used to show the flow of messages between two entities that are prepared to send and receive them An Association is used to associate information and artifacts with flow objects

91 Complete Set of Diagram Elements: Gateways
Gateways are modeling elements that are used to control how Sequence Flows interact as they converge and diverge within a Process If the flow does not need to be controlled, then a Gateway is not needed

92 Complete Set of Diagram Elements: Swimlanes
A Pool is a “swimlane” and a graphical container for partitioning a set of activities from other Pools, usually in the context of B2B situations A Lane is a sub-partition within a Pool and will extend the entire length of the Pool, either vertically or horizontally

93 Complete Set of Diagram Elements: Artifacts
Data Objects are not flow objects (i.e., connected through Sequence Flow), but they do provide information about how documents, data, and other objects are used and updated within a Process Text Annotations are a mechanism for a modeler to provide additional information for the reader of a BPMN diagram Groups provide a mechanism to visually organize activities

94 BPMN Examples

95 Shipment Process of a Hardware Retailer

96 The Pizza Collaboration

97 Order Fulfillment and Procurement

98 Stock Maintenance Process

99 Procurement sub-process

100 Exercise: Business Process Modeling
Lihat kembali System Request yang telah anda buat Lakukan business process modeling dengan membuat dua diagram di bawah: Activity Diagram Business Process Modeling Notation (BPMN)

101 Use Case Diagram

102 Use Case A formal way of representing how a business interacts with its environment The discrete activities performed by the user Use cases are logical models that describe the activities of a system Used to document the As-Is system, or to develop the To-Be system

103 Use Case Diagrams Summarized into a single picture
All of the use cases for the part of the system being modeled Use Case Diagram tells what the system will do Good for communicating with users

104 Use Case Diagram Syntax
Actor person or system that derives benefit from and is external to the subject Use Case Represents a major piece of system functionality Association Relationship Include Relationship Extend Relationship Generalization Relationship <<includes>> <<extends>>

105 Use Case Use Case A major piece of system functionality
Can extend other Use Cases Placed inside system boundary Labeled with descriptive verb-noun phrase Use Case

106 System Boundary Boundary
Includes the name of the system inside or on top Represents the scope of the system Actors are outside the scope of the system Boundary

107 Actor A person or another system that interacts with the current system A role, not a specific user Provides input, receives output, or both actor Actor/Role

108 Association Relationship
Links actor and the Use Case Shows two-way communication If one-way, arrows are used * is for "multiplicity of the Association" * *

109 extend Extends Relationship
Extends Use Case to include Optional behavior Arrow points from the extension Use Case to the base Use Case extend Make Pmt Arrangements extend Make Appointment

110 include Include Relationship
Include one Use Case from within another Arrow points from base Use Case to the included Use Case include Record Availability include Manage Schedule

111 Generalization Relationship
A specialized Use Case to a more generalized Use Case Arrow points from specialized to general Use Case Make Old Appointment Make Appointment

112 Use Case Diagram for Appointment System

113 Use Case Diagram with Specialized Actor

114 Sample Use Case

115 Extend and Include Relationships

116 Studi Kasus: ATM System

117 ATM System

118 User Interface Design Layar Kotak Uang Kotak Kartu Kotak Kuitansi

119 Masukkan PIN: Kotak Uang Kotak Kartu Kotak Kuitansi

120 Menu Utama Melihat Saldo Mengirim Uang Mengambil Uang Logout
Kotak Uang Kotak Kartu Kotak Kuitansi

121 Saldo anda adalah …. Menu Melihat Saldo Kotak Uang Kotak Kartu
Kotak Kuitansi

122 No Account Penerima: Menu Mengirim Uang Kotak Uang Kotak Kartu
Kotak Kuitansi

123 Jumlah uang yang dikirim:
Menu Mengirim Uang Jumlah uang yang dikirim: Kotak Uang Kotak Kartu Kotak Kuitansi

124 Uang berhasil terkirim
Menu Mengirim Uang Uang berhasil terkirim Kotak Uang Kotak Kartu Kotak Kuitansi

125 Jumlah uang yang diambil:
Menu Mengambil Uang Jumlah uang yang diambil: Kotak Uang Kotak Kartu Kotak Kuitansi

126 Uang berhasil diambil Menu Mengambil Uang Kotak Uang Kotak Kartu
Kotak Kuitansi

127 Activity Diagram (Business Process)

128 Activity Diagram with Partition (Business Process)

129 Use Case Diagram

130 Use Case Diagram (Multi Actors)

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152 Use Case Description

153 What are Use Case Descriptions?
Describe basic functions of the system using words What the user can do How the system responds

154 How Are Use Cases Created?
Each Use Case describes one and only one function But may have several paths that the user can take to accomplish that single function

155 Types of Use Cases Overview vs. Detail
High level overview of requirements Allows users and analysts to agree on major requirements Created early, documents only basic info Name, ID, primary actor, type, brief description Detail Once user & analyst agree Documents all information needed for the Use Case

156 Types of Use Cases Essential vs. Real
Describes only essential issues needed to understand the required functionality (e.g. "make appt") Real Goes further and describes a specific set of steps (e.g. "make entry into outlook database)

157 Elements of a Use Case Description
Contains all information needed to build Use Case diagrams But expresses it less formally Three basic parts: Overview information Relationships Flow of events

158 Elements of a Use Case Description
Use Case Name: ID: Importance Level: Primary Actor: Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows: Overview Relationships Flow of events

159

160 Overview Information Use Case Name Use Case ID Number Importance level
verb-noun phrase (Make Appt) Use Case ID Number Allows specific reference Importance level Can be fuzzy or based on detailed analysis Primary Actor Normally the trigger

161 Overview Information Use Case Type Stakeholders and interests
Overview, detail, essential, or real Stakeholders and interests Always includes the primary actor Brief Description One sentence captures the essence Trigger Event that causes Use Case to begin

162 Relationships Explains relationship of Use Case to:
Other Use Cases Users Four type of relationships Association Extend Include Generalization

163 Association Relationship
Documents the communication between the use case and the actors All actors are documented with the association relationship

164 Extend Relationship The extension of the functionality to handle optional behavior Make Appointment  Create New Patient If patient doesn’t exist in database, need to create new patient

165 Include Relationship Represents mandatory inclusion of another Use Case Enable functional decomposition Make Appointment  Make Payment Arrangements Make payment arrangements is complex enough to be a separate use case

166 Generalization Relationship
Allows use of Inheritance Gathers the common behavior is together Example: Make new Patient Appointment Make old Patient Appointment Both derived from Make Appointment

167 Flow of Events Describes the individual steps in the business process
Three type of flows Normal flow of events Sub-Flows Exceptional flows

168 Normal Flow of Events Includes only steps normally executed
Listed in the order that they are performed

169 Sub-Flows Normal flow of events are decomposed into sub-flows
Try to keep normal flow simple and understandable Can list each sub-flow as part of the Use Case If it make sense, can convert a sub-flow into its own Use Case

170 Exceptional Flows Flows that are anticipated, but not considered normal

171 Guidelines for Creating Use Case Descriptions
Write each step in “SVDPI” form Subject-Verb-Direct Object, Preposition, Indirect Object "The Patient contacts the office regarding an appointment" Allows easier identification of classes Clarify initiator and receivers of action Write from independent observer Write at same level of abstraction

172 Guidelines for Creating Use Case Descriptions
Ensure a sensible set of actions The use case represents a transaction Primary actor initiates action System validates request System processes request (changes state) System sends result to primary actor KISS – decompose if necessary Use plain language to indicate repetition

173 Exercise: Use Case Digram
Lihat kembali System Request yang sudah anda buat, lengkapi diagram tersebut dengan dua diagram UML di bawah: Activity Diagram Use Case Diagram

174 Sequence Diagram

175 System Analysis and Design with UML
Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Use Case Diagram Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) Activity Diagram (Buat untuk setiap use case bila diperlukan (optional)) System Design Program Design Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun) Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E) Deployment Diagramn (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

176 System Analysis and Design with UML
Business Process Modeling Activity Diagram Use Case Diagram Business Process Realization Sequence Diagram Activity Diagram (optional) System Design Program Design Class Diagram Package Diagram Deployment Diagram User Interface Design Entity-Relationship Model

177 Sequence Diagrams Illustrate the objects that participate in a use case Show the messages that pass between objects for a particular use-case over time

178 Sequence Diagram Syntax
AN ACTOR AN OBJECT A LIFELINE A FOCUS OF CONTROL A MESSAGE OBJECT DESTRUCTION anObject:aClass aMessage() x

179 Sequence Diagram Susun Sequence Diagram untuk setiap Use Case yang dibuat Mulai dari menarik Actor yang ada di Use Case Diagram, lanjutkan dengan membuat sequence detail dari berjalannya Use Case Catatan: Objek dari Lifeline di Sequence Diagram akan menjadi kandidat Class

180 Jenis Class Boundary Class: Control Class: Entity Class:
Class yang berinteraksi dengan aktor langsung (user interface) Form, input, UI ini masuk di sini Control Class: Class yang berhubungan dengan pemrosesan, penghitungan, kalkulasi, komputasi, query, dst Entity Class: Class yang berhubungan dengan data, penyimpanan data/file

181 Sequence Diagram: Memasukkan Kartu

182 Sequence Diagram: Memasukkan PIN

183 Sequence Diagram: Melihat Saldo

184 Sequence Diagram: Mengirim Uang

185 Sequence Diagram: Mengambil Uang

186 Sequence Diagram: Melakukan Logout

187 Activity Diagram

188 Activity Diagram Berbeda dengan Activity Diagram Business Process, Activity Diagram juga perlu dibuat untuk memperjelas Sequence Diagram Activity Diagram dibuat secara detail menjelaskan alur berjalannya Use Case (algoritma program) secara detail Seperti juga pada Sequence Diagram, Activity Diagram dibuat untuk tiap Use Case

189 Activity Diagram: Memasukkan Kartu

190 Activity Diagram: Memasukkan PIN

191 Exercise: Sequence Diagram
Lihat kembali System Request, Activity Diagram, BPMN, dan Use Case Diagram yang sudah anda buat Lengkapi diagram tersebut dengan Sequence Diagram dan Activity Diagram (detail) pada setiap Use Case yang dibuat

192 Collaboration Diagram

193 Collaboration Diagrams
Essentially an object diagram that shows Message passing relationships Instead associations Emphasize The flow of messages among objects Rather than timing and ordering of messages

194 Collaboration Diagram Syntax
AN ACTOR AN OBJECT AN ASSOCIATION A MESSAGE anObject:aClass aMessage()

195 Example Collaboration Diagram

196 State Machine Diagram

197 Behavioral State Machines
Some objects may change states often Some may change state and never change back Patient: new  current  former This is seen in the cells of the CRUD matrix

198 Behavioral State Machines
The behavioral state machine is a dynamic model that shows this The behavioral state machine shows The different states of an object The events That cause the object to change from one state to another

199 Components of Statechart Diagrams
States Determined by the values of the attributes Events Changes the state of an object e.g. changes the values of attributes

200 Components of Statechart Diagrams
Transitions Movement of an object from one state to another Often has a guard condition Actions Atomic process, takes "zero time" Activities Non-atomic, take a long time, can be started and stopped

201 Statechart Diagram Syntax
A STATE AN INITIAL STATE A FINAL STATE AN EVENT A TRANSITION aState anEvent

202 Example Behavioral State Machine Diagram

203 Building Behavioral State Machine Diagrams
Set the context Identify Initial state Final state All stable states Determine the order in which the object will pass through stable states Identify the events, actions, and guard conditions associated with the transitions Validate the diagram

204 Estimating Project Size with Use Case Points

205 Use Case Points Alternative to Function Point Approach
Classify actors and use cases as: Simple Average Complex (Gustav Karner, 1993)

206 Actor and Use Case Weighting Tables
Unadjusted Actor Weighting (UAW) Actor Type Description Weighting Factor Simple External System with well-defined API 1 Average External System using a protocol-based interface, e.g., HTTP, TCT/IP, SQL 2 Complex Human 3 Unadjusted Use Case Weighting (UUCW) Use-Case Type Description Weighting Factor Simple 1-3 transactions 5 Average 4-7 transactions 10 Complex More than 7 transactions 15 Unadjusted Use Case Points (UUCP) = UAW + UUCW

207 Technical Complexity Factors
Factor Number Description Weight T1 Distributed system 2.0 T2 Response time or throughput performance objectives 1.0 T3 End-user online efficiency T4 Complex internal processing T5 Reusability of code T6 Easy to install 0.5 T7 Ease of use T8 Portability T9 Ease of change Technical Complexity Factor (TCF) = (0.01 * TFactor)

208 Environmental Factors
Factor Number Description Weight E1 Familiarity with system development process in use 1.5 E2 Application experience 0.5 E3 Object-oriented experience 1.0 E4 Lead analyst capability E5 Motivation E6 Requirements stability 2.0 E7 Part time staff -1.0 E8 Difficulty of programming language Environmental Factor (EF) = (-0.03 * EFactor)

209 Unadjusted Actor Weighting (UAW)

210 Computing Use Case Points
Adjusted Use Case Points (UCP) = UUCP * TCF * ECF Effort in Person Hours = UCP * PHM

211 Person-Hours Multiplier
If the sum of (number of Efactors E1 through E6 assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) ≤ 2 PHM = 20 Else If the sum of (number of Efactors E1 through E6 assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) = 3 or 4 PHM 28 Else Rethink project; it has too high of a risk for failure

212 Adjusted Use Case Points (UCP)
UCP = UUCP * TCF * ECF Person Hour Multiplier (PHM)

213 Person Hour Multiplier (PHM)
Now it’s time to compute effort Let F1 = Number of E1 to E6 that are < 3 Let F2 = Number of E7 and E8 that are > 3 If F1 + F2 <= 2 PHM = 20 Else if F1 + F2 = 3 or 4 PHM = 28 Else Scrap the project

214 Calculate Effort Person Hours = UCP * PHM

215 Use Case Points in EA

216

217 Effort Estimation from Time Defined
TIME = 3.0 PM 1/3 4.1 = 3.0 * PM 1/3 PM = (4.1/3) 3 = 2.5 person-months

218 Budget (Custom Software)
Pekerjaan Man-Month Month Budget Total Planning 1 2 Analysis Design 4 Implementation 5 Training

219 Budget (Generic Software)
Product Total LMS Teleconference Chatting eLibrary

220 Exercise: Project Size Estimation
Lihat kembali Use Case Diagram, dan Sequence Diagram yang telah anda buat Estimasi Project Size, Effort dan Time dengan menggunakan Use Case Point Kirim file EAP ke

221 Object-Oriented Programming Referensi Alan Dennis et al, Systems Analysis and Design with UML 4th Edition, John Wiley and Sons, 2013 Kenneth E. Kendall and Julie E Kendall, Systems Analysis and Design 8th Edition, Prentice Hall, 2010 Hassan Gomaa, Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures, Cambridge University Press, 2011 Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis and Design 9th Edition, Course Technology, 2011 Howard Podeswa, UML for the IT Business Analyst 2nd Edition, Thomson Course Technology, 2009 Jeffrey A. Hoffer et al, Modern Systems Analysis and Design 6th Edition, Prentice Hall, 2012


Download ppt "Systems Analysis and Design with UML: System Analysis"

Similar presentations


Ads by Google