Download presentation
Presentation is loading. Please wait.
Published byDiane Ward Modified over 6 years ago
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
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
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)
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
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
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
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.