Systems Analysis and Design with UML: System Analysis

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

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

Contents Introduction Project Planning System Analysis System Design
System Implementation

System Analysis romi@romisatriawahono.net Object-Oriented Programming

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

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

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)

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

Requirement

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

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

Requirement Gathering

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

1. Interviews

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

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

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

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 %

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

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?

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"

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

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

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

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

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

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

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

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

The SDLC Process

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

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

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

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

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

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

Business Process Modeling
Object-Oriented Programming Business Process Modeling

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

Building Block of BPMN

Process Model in BPMN

Routing of Tasks Sequential Parallel Conditional Iterative

Sequential Routing

Parallel Routing

Conditional Routing

Conditional Routing: Binary Choice

Conditional Routing: Exclusive Choice

Conditional Routing: Event-Based Choice

Iterative Routing

Events and Triggers

Event Types Used for Triggers

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

Cases and States: Intermediate Event

Organization Structure and Roles: Swimlanes

Recap of Building Blocks for BPMN

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

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)

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

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

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

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

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

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

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

BPMN Examples

Shipment Process of a Hardware Retailer

The Pizza Collaboration

Order Fulfillment and Procurement

Stock Maintenance Process

Procurement sub-process

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)

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 Boundary

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

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

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

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

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)

Use Case Description

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

Exceptional Flows Flows that are anticipated, but not considered normal

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

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

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

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

Activity Diagram

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

Activity Diagram: Memasukkan Kartu

Activity Diagram: Memasukkan PIN

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

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

Unadjusted Actor Weighting (UAW)

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

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

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

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

Calculate Effort Person Hours = UCP * PHM

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 Analysis Design 4 Implementation 5 Training

Budget (Generic Software)
Product Total LMS Teleconference Chatting eLibrary

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

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

Systems Analysis and Design with UML: System Analysis

Similar presentations

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

Similar presentations

About project

Feedback

Log in

Auth with social network:

Systems Analysis and Design with UML: System Analysis

Similar presentations

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

Similar presentations

About project

Feedback