Systems Analysis and Design with UML: System Analysis

Contents Introduction Project Planning System Analysis System Design System Implementation

3. SYSTEM ANALYSIS romi@romisatriawahono.net Object-Oriented Programming 3. SYSTEM ANALYSIS http://romisatriawahono.net

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

SDLC and Deliverables Planning Analysis (System Specification) romi@romisatriawahono.net Object-Oriented Programming SDLC and Deliverables Planning (System Proposal) Analysis (System Specification) Design (System Specification) Implementation (New System) http://romisatriawahono.net

System Analysis and Design with UML Business Process Identification Use Case Diagram Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) 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 Diagram (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

Requirement Gathering

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

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

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

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

1. Interviews

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

2. Joint Application Development (JAD)

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

JAD Meeting Room JPEG Figure 5-5 Goes Here

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

3. Questionaires

Questionnaire Steps Selecting participants Designing the questionnaire 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

Questionnaire Steps Questionnaire follow-up 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

4. Document Analysis

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

5. Observation

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

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

Business Process Analysis

Business Process Analysis Steps

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

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

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

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

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

Business Process Identification

System Analysis and Design with UML Business Process Identification Use Case Diagram Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) 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 Diagram (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

Use Case Diagram

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

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

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

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

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

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

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

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

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

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

Use Case Diagram for Appointment System

Use Case Diagram with Specialized Actor

Sample Use Case

Extend and Include Relationships

Business Process Modeling romi@romisatriawahono.net Object-Oriented Programming Business Process Modeling http://romisatriawahono.net

System Analysis and Design with UML Business Process Identification Use Case Diagram Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) 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 Diagram (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

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

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

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

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

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

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

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

Activity Diagram Example

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

Business Process Modeling with BPMN

Credit Application

Purchase Request

Shipment Process of a Hardware Retailer

The Pizza Collaboration

Order Fulfillment and Procurement

Studi Kasus: ATM System

ATM System

User Interface Design Layar Kotak Uang Kotak Kartu Kotak Kuitansi

Masukkan PIN: Kotak Uang Kotak Kartu Kotak Kuitansi

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

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

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

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

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

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

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

Activity Diagram (Business Process)

Activity Diagram with Partition (Business Process)

Use Case Diagram

Use Case Diagram (Multi Actors)

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

Business Process Realization romi@romisatriawahono.net Object-Oriented Programming Business Process Realization http://romisatriawahono.net

System Analysis and Design with UML Business Process Identification Use Case Diagram Business Process Modeling Activity Diagram or Business Process Modeling Notation (BPMN) Business Process Realization Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity) 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 Diagram (arsitektur software dari sistem yang dibangun) User Interface Design (Buat UI design dari Boundary Class) Entity-Relationship Model (Buat ER diagram dari Entity Class)

Sequence Diagram

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

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

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

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

Sequence Diagram: Memasukkan Kartu

Sequence Diagram: Memasukkan PIN

Sequence Diagram: Melihat Saldo

Sequence Diagram: Mengirim Uang

Sequence Diagram: Mengambil Uang

Sequence Diagram: Melakukan Logout

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

Collaboration Diagram

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

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

Example Collaboration Diagram

State Machine Diagram

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

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

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

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

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

Example Behavioral State Machine Diagram

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

Estimating Project Size with Use Case Points

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

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

Actor and Use Case Weighting Tables 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

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.6 + (0.01 * TFactor)

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) = 1.4 + (-0.03 * EFactor)

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

Person Hour Multiplier (PHM) 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

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

Use Case Points in EA

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

Budget (Custom Software) Pekerjaan Man-Month Month Budget Total Planning 1 2 5000.000 10.000.000 Analysis 20.000.000 Design 4 4000.000 32.000.000 Implementation 5 3000.000 24.000.000 Training 8000.000 94.000.000

Budget (Generic Software) Product Total LMS 10.000.000 Teleconference 2.000.000 Chatting 4.000.000 eLibrary 20.000.000

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

romi@romisatriawahono.net 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, Course Technology, 2009 Jeffrey A. Hoffer et al, Modern Systems Analysis and Design 6th Edition, Prentice Hall, 2012 http://romisatriawahono.net