Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Systems Analysis and Design 3. System Analysis Romi Satria Wahono WA/SMS: +6281586220090 1.

Presentasi serupa


Presentasi berjudul: "Systems Analysis and Design 3. System Analysis Romi Satria Wahono WA/SMS: +6281586220090 1."— Transcript presentasi:

1 Systems Analysis and Design 3. System Analysis Romi Satria Wahono WA/SMS:

2 Romi Satria Wahono SD Sompok Semarang (1987) SMPN 8 Semarang (1990) SMA Taruna Nusantara Magelang (1993) B.Eng, M.Eng and Ph.D in Software Engineering from Saitama University Japan ( ) Universiti Teknikal Malaysia Melaka (2014) Research Interests: Software Engineering, Intelligent Systems Founder dan Koordinator IlmuKomputer.Com Peneliti LIPI ( ) Founder dan CEO PT Brainmatics Cipta Informatika 2

3 Contents 1.Introduction 2.Project Planning 3.System Analysis 4.System Design 5.System Implementation 3

4 Recap Identifying the business value of the new project is a key to success The system request describes an overview of the proposed system. The feasibility study is concerned with insuring that technical, economic, and organizational benefits outweigh costs and risks Project estimation methods: simply method, function point and use case point 4

5 3. System Analysis 5

6 Learning Objectives 1.Understand how to create a requirements definition 2.Become familiar with requirements analysis techniques 3.Understand when to use each requirements analysis technique 4.Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation 5.Understand when to use each requirements- gathering technique 6.Understand the system analysis and design using UML 6

7 SDLC and Deliverables 7

8 Requirement Gathering 8

9 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 1.Functional 2.Nonfunctional 9

10 Functional Requirement Defines the functions of the system must carry out Specifies the process that must be performed Examples: Diagrams: Activity Diagrams Use Case Diagrams Problem Statements: Must search for inventory Must perform these calculations Must produce a specific report 10

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

12 12

13 Requirement Gathering Methods 1.Document Analysis 2.Interviews 3.Joint Application Design (JAD) 4.Questionnaires 5.Observation 13

14 1. 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 14

15 2. Interviews Most commonly used technique Very natural If you need to know something, you ask someone Five basic steps: 1.Selecting interviewees 2.Designing interview questions 3.Preparing for the interview 4.Conducting the interview 5.Post-interview follow-up 15

16 3. Joint Application Design (JAD) Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague Include 10 to 20 users Tend to last 5 to 10 days over a three week period 16

17 JAD Meeting Room JPEG Figure 5-5 Goes Here 17

18 4. Questionnaire 1.Selecting participants Using samples of the population 2.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 18

19 4. Questionnaire 3.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 4.Questionnaire follow-up Send results to participants 19

20 5. 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 20

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

22 Business Process Analysis 22

23 Business Process Analysis Steps 23

24 Business Process Analysis Strategies 1.BPA (Business Process Automation) 2.BPI (Business Process Improvement) 3.BPR (Business Process Reengineering) 24

25 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 25

26 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 26

27 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 27

28 Strategy Comparation BusinessBusinessBusiness BusinessBusinessBusiness ProcessProcessProcess ProcessProcessProcess Automation ImprovementReeingineering Potential Business Low-ModerateModerateHigh Value Project Cost LowLow-ModerateHigh Breadth of Analysis NarrowNarrow-ModerateVery Broad Risk LowLow-ModerateVery High 28

29 Barriers to Requirements Gathering 29

30 Barriers to Requirements Elicitation 1.The "Yes, But" Syndrome 2.The "Undiscovered Ruins" Syndrome 3.The "User and the Developer" Syndrome 30

31 The "Yes, But" Syndrome For whatever reason, we always see two immediate, distinct, and separate reactions when the users see the system implementation for the first time. 1."Wow, this is so cool; we can really use this, what a neat job" and so on. 2."Yes, but, hmmmmm, now that I see it, what about this... ? Wouldn't it be nice if... ? Whatever happened to... ?“ 31

32 The "Yes, But" Syndrome The "Yes, But" syndrome is human nature and is an integral part of application development. We should plan to avoid or significantly reduce this syndrome by applying techniques that get the "Buts" out early. In so doing, we elicit the "Yes, But" response early, and we then can begin to invest the majority of our development efforts in software that has already passed the "Yes, But" test. 32

33 The "Undiscovered Ruins" Syndrome In many ways, the search for requirements is like a search for undiscovered ruins. The more you find, the more you know remain. You never really feel that you have found them all, and perhaps you never will. Indeed, software development teams always struggle to determine when they are done with requirements elicitation. When have they found all the requirements or at least enough requirements? 33

34 The "User and the Developer" Syndrome Communication gap between the user and the developer. Users and developers are typically from different worlds, may even speak different languages, and have different backgrounds, motivations, and objectives. 34

35 The "User and the Developer" Syndrome Reasons for this problem and some suggested solutions 35

36 Key Points Requirements elicitation is complicated by three endemic syndromes. The "Yes, But" syndrome stems from human nature and the users' inability to experience the software as they might a physical device. Searching for requirements is like searching for "Undiscovered Ruins"; the more you find, the more you know remain. The "User and the Developer" syndrome reflects the profound differences between these two, making communication difficult. 36

37 Analysis and Design using UML 37

38 Analysis Design Paradigm and Diagrams 1.Data-oriented  DFD 2.Process-oriented  Flowchart 3.Object-oriented (data + process)  UML 38

39 Sejarah UML In the 90s many people creating OO diagramming languages Three different ones created by Grady Booch, Ivar Jacobson, James Rumbaugh Joined forces with Rational (company) to create Unified Modeling Langauge (UML) Booch, Jacobson, Rumbaugh 39

40 Sejarah UML 2011  UML

41 What is the UML? UML: Unified Modeling Language UML can be used for modeling all processes in the development life cycle and across different implementation technologies (technology and language independent) UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system UML is a communication tool – for the team, and other stakeholders 41

42 The Triangle of Success in Software Dev. Notation : Standard Tools : Support Standard and Process Process : Customer- Oriented Methodology 42

43 UML Tools Rational Rose Visual Paradigm Enterprise Architect Microsoft Visio Star UML Netbeans UML Plugin 43

44 UML 2.0 Diagrams UML version 2.0 has 14 diagrams in 2 major groups: 1.Structure Diagrams 2.Behavior Diagrams 44

45 UML 2.0 Diagram 45

46 UML Structure Diagrams Represent the data and static relationships in an information system 1.Class Diagram 2.Object Diagram 3.Package Diagram 4.Deployment Diagram 5.Component Diagram 6.Composite Structure Diagram 46

47 Structure Diagrams 1.Class Diagrams Common vocabulary used by analyst and users Represent things (employee, paycheck,…) Shows the relationships between classes 2.Object Diagrams Similar to class diagrams Instantiation of a class diagram Relationships between objects 3.Package Diagrams Group UML elements together to form higher level constructs 47

48 Structure Diagrams 4.Deployment Diagrams Shows the physical architecture and software components of system For example, network nodes 5.Component Diagrams Physical relationships among software components Example – Client/Server (Which machines run which software) 6.Composite Structure Illustrates internal structure of a complex class 48

49 UML Behavior Diagrams Depict the dynamic relationships among the instances or objects that represent the business information system 1.Activity Diagram 2.Sequence Diagram 3.Communication Diagram 4.Interaction Diagram 5.Timing Diagram 6.Behavior State Machine 7.Protocol State Machine 8.Use Case Diagrams 49

50 Behavior Diagrams 1.Activity Diagrams Model processes in an information system Example: Business workflows, business logic 2.Interaction Diagrams Shows interaction among objects 3.Sequence Diagrams Time-based ordering of the interaction 4.Communication Diagrams Communication among a set of collaborating objects of an activity 50

51 Behavior Diagrams 5.Interaction Diagrams Overview of flow of control of a process 6.Timing Diagrams Show how an object changes over time 7.State Machines Examines behavior of one class Models the different states and state transitions an object can experience 8.Use-Case Diagrams Shows interaction between the system and environment Captures business requirements 51

52 UML Problems 1.UML is modeling notation, it is not a development process or a methodology UML driven development process? 2.UML is too complex, difficult to understand quickly Should we use all UML diagrams? 52

53 UML Process (EA Sparx) 1.Display the boundary of a system and its major functions using use cases and actors 2.Model the organization’s business process with activity diagram 3.Illustrate use case realizations with sequence diagrams 4.Represent a static structure of a system using class diagrams 5.Reveal the physical implementation architecture with deployment diagrams 53

54 UML Process (EA Sparx) 1.Use Cases Diagram 2.Activity Diagram 3.Sequence Diagram 4.Class Diagram 5.Deployment Diagrams 54

55 UML Process (Kendal, 2011) 1.A use case diagram, describing how the system is used. Analysts start with a use case diagram 2.An activity diagram, illustrating the overall flow of activities. Each use case may create one activity diagram 3.Sequence diagrams, showing the sequence of activities and class relationships. Each use case may create one or more sequence diagrams 4.Class diagrams, showing the classes and relationships. Sequence diagrams are used to determine classes 5.Statechart diagrams, showing the state transitions. Each class may create a statechart diagram, which is useful for determining class methods 55

56 (Kendall and Kendall, 2011) 56

57 UML Process (Barclay, 2004) 57

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

59 Case Study: ATM System 59

60 ATM System 60

61 ATM System Layar Kotak Uang Kotak Kartu Kotak Kuitansi 61

62 Masukkan PIN: Kotak Uang Kotak Kartu Kotak Kuitansi 62

63 Menu Utama 1. 1.Melihat Saldo 2. 2.Mentransfer Uang 3. 3.Mengambil Uang 4. 4.Logout Kotak Uang Kotak Kartu Kotak Kuitansi 63

64 Menu Melihat Saldo 1. 1.Saldo anda adalah …. Kotak Uang Kotak Kartu Kotak Kuitansi 64

65 Menu Mentransfer Uang 1. 1.No Account Penerima: Kotak Uang Kotak Kartu Kotak Kuitansi 65

66 Menu Mentransfer Uang 1. 1.Jumlah uang yang dikirim: Kotak Uang Kotak Kartu Kotak Kuitansi 66

67 Menu Mentransfer Uang 1. 1.Uang berhasil terkirim Kotak Uang Kotak Kartu Kotak Kuitansi 67

68 Menu Mengambil Uang 1. 1.Jumlah uang yang diambil: Kotak Uang Kotak Kartu Kotak Kuitansi 68

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

70 Use Case Diagram 70

71 Use Case Diagram (Alternatif) 71

72 Activity Diagram: Memasukkan Kartu 72

73 Activity Diagram: Memasukkan PIN 73

74 Activity Diagram: Mengecek Saldo 74

75 Activity Diagram: Mentransfer Uang 75

76 Activity Diagram: Mengambil Uang 76

77 Activity Diagram: Melakukan Logout 77

78 Sequence Diagram: Memasukkan Kartu 78

79 Type of Class 1.Boundary Class Class yang berhubungan dengan actor (user interface) 2.Control Class Class yang berhubungan dengan pemrosesan, komputasi, penghitungan, dsb 3.Entity Class Class yang berhubungan dengan data (flat file or database) 79

80 Sequence Diagram: Memasukkan PIN 80

81 Sequence Diagram: Mengecek Saldo 81

82 Sequence Diagram: Mentransfer Uang 82

83 Sequence Diagram: Mengambil Uang 83

84 Sequence Diagram: Melakukan Logout 84

85 Class Diagram 85

86 Deployment Diagram (3 Tier) 86

87 Data Model 87

88 User Interface Design 88

89 User Interface Design (Netbeans) 89

90 Business Process Identification 90

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

92 Use Case Diagram 92

93 Use Case Diagrams Summarized into a single picture All of the use cases for the part of the system being modeled Use case represents the discrete activities performed by the user Use Case Diagram tells what the system will do Good for communicating with users 93

94 Syntax for an Use Case Diagram 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 <> <> 94

95 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 95

96 System 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 96

97 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 97

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

99 Extends Relationship Extends Use Case to include Optional behavior Arrow points from the extension Use Case to the base Use Case  extend  Make Appointment Make Payment Arrangement 99

100 Include Relationship Include one Use Case from within another Arrow points from base Use Case to the included Use Case  include  Create New Patient Make New Patient Appointment 100

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

102 Use Case Diagram for Appointment System 102

103 Use Case Diagram with Specialized Actor 103

104 Extend and Include Relationships 104

105 Studi Kasus: ATM System 105

106 ATM System 106

107 ATM System Layar Kotak Uang Kotak Kartu Kotak Kuitansi 107

108 Masukkan PIN: Kotak Uang Kotak Kartu Kotak Kuitansi 108

109 Menu Utama 1. 1.Melihat Saldo 2. 2.Mentransfer Uang 3. 3.Mengambil Uang 4. 4.Logout Kotak Uang Kotak Kartu Kotak Kuitansi 109

110 Menu Melihat Saldo 1. 1.Saldo anda adalah …. Kotak Uang Kotak Kartu Kotak Kuitansi 110

111 Menu Mentransfer Uang 1. 1.No Account Penerima: Kotak Uang Kotak Kartu Kotak Kuitansi 111

112 Menu Mentransfer Uang 1. 1.Jumlah uang yang dikirim: Kotak Uang Kotak Kartu Kotak Kuitansi 112

113 Menu Mentransfer Uang 1. 1.Uang berhasil terkirim Kotak Uang Kotak Kartu Kotak Kuitansi 113

114 Menu Mengambil Uang 1. 1.Jumlah uang yang diambil: Kotak Uang Kotak Kartu Kotak Kuitansi 114

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

116 Use Case Diagram 116

117 Use Case Diagram (Alternatif) 117

118 Exercise: Business Process Identification 1.Lihat kembali System Request yang sudah anda buat 2.Lakukan business process identification dengan membuatkan Use Case Diagram untuk System Request tersebut 118

119 Exercise: Systems Analysis and Design Lakukan sistem analysis and design yang menghasilkan diagram: 1.Use Case Diagram Pilih salah satu aplikasi di bawah: 1. 1.Aplikasi Rental Mobil 2. 2.Aplikasi Pengelolaan Klinik 3. 3.Aplikasi Pengelolaan Apotik 4. 4.Aplikasi Pengelolaan Service Mobil 5. 5.Aplikasi Penjualan Motor 6. 6.Aplikasi Pengelolaan Perpustakaan 7. 7.Aplikasi Penjualan Buku Online 8. 8.Aplikasi Penjualan Tiket Kereta Online 9. 9.Aplikasi Manajemen Universitas Online Aplikasi Penjualan Laptop Online Aplikasi Perpustakaan Digital Aplikasi Pengelolaan Project Software 119

120 Business Process Modeling 120

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

122 Business Process Modeling with Activity Diagrams 122

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

124 Syntax for an Activity Diagram 124

125 Activity Diagram Example 125

126 Creating Activity Diagrams 1.Set the context or scope of the activity being modeled 2.Identify the activities and control/object flows between activities 3.Identify any decisions made 4.Look for opportunities for parallelism 5.Draw the diagram 126

127 Business Process Modeling with BPMN 127

128 128

129 129

130 130

131 131

132 Credit Application 132

133 Purchase Request 133

134 Shipment Process of a Hardware Retailer 134

135 The Pizza Collaboration 135

136 Order Fulfillment and Procurement 136

137 Studi Kasus: ATM System 137

138 Activity Diagram: Memasukkan Kartu 138

139 Activity Diagram: Memasukkan PIN 139

140 Activity Diagram: Mengecek Saldo 140

141 Activity Diagram: Mentransfer Uang 141

142 Activity Diagram: Mengambil Uang 142

143 Activity Diagram: Melakukan Logout 143

144 Exercise: Business Process Modeling 1.Lihat kembali System Request dan Use Case Diagram yang sudah anda buat 2.Lakukan business process modeling dengan membuatkan Activity Diagram untuk setiap Use Case yang dibuat 3.Yang harus dibuat: System Request, Feasibility Analysis, Project Size Estimation (FP) (DOC dan XLS), Use Case Diagram, Activity Diagram (EAP) 144

145 Exercise: Systems Analysis and Design Lakukan sistem analysis and design yang menghasilkan diagram: 1.Use Case Diagram 2.Activity Diagram Pilih salah satu aplikasi di bawah: 1. 1.Aplikasi Rental Mobil 2. 2.Aplikasi Pengelolaan Klinik 3. 3.Aplikasi Pengelolaan Apotik 4. 4.Aplikasi Pengelolaan Service Mobil 5. 5.Aplikasi Penjualan Motor 6. 6.Aplikasi Pengelolaan Perpustakaan 7. 7.Aplikasi Penjualan Buku Online 8. 8.Aplikasi Penjualan Tiket Kereta Online 9. 9.Aplikasi Manajemen Universitas Online Aplikasi Penjualan Laptop Online Aplikasi Perpustakaan Digital Aplikasi Pengelolaan Project Software 145

146 Business Process Realization 146

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

148 Sequence Diagram 148

149 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 149

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

151 Sequence Diagram 1.Susun Sequence Diagram untuk setiap Use Case yang dibuat 2.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 151

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

153 Studi Kasus: ATM System 153

154 Sequence Diagram: Memasukkan Kartu 154

155 Sequence Diagram: Memasukkan PIN 155

156 Sequence Diagram: Mengecek Saldo 156

157 Sequence Diagram: Mentransfer Uang 157

158 Sequence Diagram: Mengambil Uang 158

159 Sequence Diagram: Melakukan Logout 159

160 Exercise: Sequence Diagram 1.Lihat kembali System Request, Use Case Diagram, dan Activity Diagram yang sudah anda buat 2.Lengkapi diagram tersebut dengan Sequence Diagram untuk setiap Use Case yang dibuat 160

161 Exercise: Systems Analysis and Design Lakukan sistem analysis and design yang menghasilkan diagram: 1.Use Case Diagram 2.Activity Diagram 3.Sequence Diagram Pilih salah satu aplikasi di bawah: 1. 1.Aplikasi Rental Mobil 2. 2.Aplikasi Pengelolaan Klinik 3. 3.Aplikasi Pengelolaan Apotik 4. 4.Aplikasi Pengelolaan Service Mobil 5. 5.Aplikasi Penjualan Motor 6. 6.Aplikasi Pengelolaan Perpustakaan 7. 7.Aplikasi Penjualan Buku Online 8. 8.Aplikasi Penjualan Tiket Kereta Online 9. 9.Aplikasi Manajemen Universitas Online Aplikasi Penjualan Laptop Online Aplikasi Perpustakaan Digital Aplikasi Pengelolaan Project Software 161

162 Collaboration Diagram 162

163 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 163

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

165 Example Collaboration Diagram 165

166 State Machine Diagram 166

167 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 167

168 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 168

169 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 169

170 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 170

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

172 Example Behavioral State Machine Diagram 172

173 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 173

174 Estimating Project Size with Use Case Points Gustav Karner (1993) 174

175 Actor and Use Case Weighting Tables Actor TypeDescriptionWeighting Factor SimpleExternal System with well-defined API1 AverageExternal System using a protocol- based interface, e.g., HTTP, TCT/IP, SQL 2 ComplexHuman3 Use-Case TypeDescriptionWeighting Factor Simple1-3 transactions5 Average4-7 transactions10 ComplexMore than 7 transactions15 Unadjusted Use Case Points (UUCP) = UAW + UUCW Unadjusted Use Case Weighting (UUCW) Unadjusted Actor Weighting (UAW) 175

176 Technical Complexity Factors Factor Number DescriptionWeight T1Distributed system2.0 T2Response time or throughput performance objectives 1.0 T3End-user online efficiency1.0 T4Complex internal processing1.0 T5Reusability of code1.0 T6Easy to install0.5 T7Ease of use0.5 T8Portability2.0 T9Ease of change1.0 Technical Complexity Factor (TCF) = (0.01 * TFactor) 176

177 Environmental Complexity Factors Factor Number DescriptionWeight E1Familiarity with system development process in use 1.5 E2Application experience 0.5 E3Object-oriented experience 1.0 E4Lead analyst capability 0.5 E5Motivation 1.0 E6Requirements stability 2.0 E7Part time staff E8Difficulty of programming language Environmental Factor (ECF) = (-0.03 * EFactor) 177

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

179 Person Hour Multiplier (PHM) If the sum of (number of Efactors ECF1 through ECF6 assigned value 3) ≤ 2 PHM = 20 Else If the sum of (number of Efactors ECF1 through ECF6 assigned value 3) = 3 or 4 PHM 28 Else Rethink project; it has too high of a risk for failure 179

180 Person Hour Multiplier (PHM) Let F1 = Number of ECF1 to ECF6 that are < 3 Let F2 = Number of ECF7 and ECF8 that are > 3 If F1 + F2 <= 2 PHM = 20 Else if F1 + F2 = 3 or 4 PHM = 28 Else Scrap the project 180

181 Use Case Points in EA 181

182 182

183 Effort Estimation from PM Defined Effort Estimation of Sistem ATM UCP= 32PHM= 20 PH= 20*32 = 640 PM = 640/8/22 = 3.6 PM = 640/10/26 = 2.4 (10 Jam/hari dan sabtu masuk  ) TIME (M)= 3.0 * PM 1/3 TIME (M) = 3.0 * 3.4 1/3 TIME (M) = 4.5 TIME (M)= 3.9 (LEMBUR  ) 183

184 Budget (Custom Software) PekerjaanMan-MonthMonthBudgetTotal Planning Analysis Design Implementation Training

185 Budget (Generic Software) ProductTotal LMS Teleconference Chatting eLibrary

186 Exercise: Project Size Estimation 1.Lihat kembali Use Case Diagram, dan Sequence Diagram yang telah anda buat 2.Estimasi Project Size, Effort dan Time dengan menggunakan Use Case Point 186

187 Exercise: System Analysis untuk System Request 1.Lihat kembali System Request yang sudah anda buat 2.Lakukan system analysis dengan membuat diagram di bawah: 1.Use Case Diagram 2.Activity Diagram 3.Sequence Diagram 3.Buat project baru di Sparx EA, buat 3 package dengan nama sama dengan 3 diagram di atas 187

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


Download ppt "Systems Analysis and Design 3. System Analysis Romi Satria Wahono WA/SMS: +6281586220090 1."

Presentasi serupa


Iklan oleh Google