ANALISA PERANCANGAN

SISTEM

PRADITA UNIVERSITY
Penilaian UAS Tugas
40 % 30%

UTS 30%
Lecture 3
Methodologie
Content:
Explain the Characteristics of a Good
Analysis Method
Explain Why Use a Methodology
Describe the three categorizes of system
development methodologies
 Introduction

• The process of system analysis and its planning includes various stages.
• Over the years various methodologies have been defined for this process.
• The methodologies themselves constitute a method that regulates the various
stages in the process of planning and developing the information system.
• Each methodology has its own advantages and disadvantages but, generally, the
correct methodology must be adapted to the required system.
Introduction

- A methodology is a formalized approach to implementing the SDLC.

- Justified by experience

- A methodology may or may not prescribe a Life Cycle Model.

- The methodology will vary depending on whether the emphasis is on

businesses processes or on the data that supports the business.
Systems Development Methodologies

 Characteristics of a Good Analysis Method

• Graphical with supporting text.
• Allow system to be viewed in a top-down and
partitioned fashion.
• Minimum redundancies.
• Reader should be able to predict system behavior.
• Easy to understand by user.
Systems Development Methodologies

 Why Use a Methodology?

• Distilled experience/best practice
• Ensures user involvement
• Helps inexperienced analysts
• Provides planning and control
WATERFALL DEVELOPMENT MODEL

Sometimes called the classic life cycle or the waterfall model,

the linear sequential model suggests a systematic, sequential
approach5 to software development.

With waterfall development- based methodologies, the analysts

and users proceed sequentially from one phase to the next.
WATERFALL DEVELOPMENT MODEL

Sometimes called the classic life cycle or the waterfall model,

the linear sequential model suggests a systematic, sequential
approach to software development.

With waterfall development- based methodologies, the analysts

and users proceed sequentially from one phase to the next.
Software requirements analysis. The requirements gathering process is intensified
and focused specifically on software.
Design. Software design is actually a multistep process that focuses on four distinct
attributes of a program: data structure, software architecture, interface representations,
and procedural (algorithmic) detail.
Code generation. The design must be translated into a machine-readable form. The
code generation step performs this task.
Testing. Once code has been generated, program testing begins. The testing process
focuses on the logical internals of the software, ensuring that all statements have been
tested, and on the functional externals; that is, conducting tests to uncover errors and
ensure that defined input will produce actual results that agree with required results
Support. Software will undoubtedly undergo change after it is delivered to the
customer (a possible exception is embedded software).
  The advantages of waterfall development-based methodologies are:
 The system requirements are identified long before programming begins.
 Changes to the requirements are minimized as the project proceeds.
 Good for project management
 Results in solid, well-constructed systems

 The disadvantages of waterfall development-based methodologies are:

 The design must be completely specified before programming begins.
 A long time elapses between the completion of the system proposal in the
analysis phase and the delivery of the system.
Rapid Application Development (RAD)

 RAD-based methodologies adjust the SDLC phases to get some part of

system developed quickly and into the hands of the users.
 Most RAD-based methodologies recommend that analysts use special
techniques and computer tools to speed up the analysis, design, and
implementation phases, such as CASE (computer-aided software
engineering) tools.
Rapid Application Development (RAD)

• Five key factors

 Extensive user involvement
 Joint Application Design sessions
 Prototyping
 Integrated CASE tools
 Code generators
Rapid Application Development (RAD)

• RAD is a general strategy rather than a single methodology

• Goals
• To analyze a business process rapidly
• To design a viable system solution through intense
cooperation between users and developers
• To get the finished application into the hands of the users
quickly
• Traditional SDLC steps are followed, but phases are combined
• Iteration is limited to design and development phases
Joint Application Development

 JAD (Joint Application Development) is a methodology that involves the

client or end user in the design and development of an application, through
a succession of collaborative workshops called JAD sessions. System
development personal at IBM developed JAD in the late 1970s and began
teaching the approach through workshops in 1980
 As systems grew in size and complexity, it become impossible to make it
one-shot pass through stages. Developers were always looping back and
reading things to come up with a system that satisfied the users. In
response to this limitation, system developers apply a technique called
prototype.

Joint Application Development

 Joint Application Development (JAD)

 Joint Application Development (JAD) can replace a series of interviews with
the user community
 JAD is a technique that allows the analyst to accomplish requirements
analysis and design the user interface with the users in a group setting
 Brings together key users, managers and systems analysts
 Purpose: collect system requirements simultaneously from key people
 Objective is to analyze the existing system, obtain user input and
expectations, and document user requirements for the new system
 End Result
 Documentation detailing existing system
 Features of proposed system
Joint Application Development

 JAD Participants and Roles

 During the development process, the IT staff would collect information from
users, define system requirements, and construct the new system
 At various stages of the process, the IT staff might ask users to review the
design, offer comments, and submit changes
 IT professionals now recognize that successful systems must be user oriented,
and user need to be involved, formally or informally, at every stage of system
development
 One popular strategy for user involvement is a JAD team approach, which
involves a task force of users, managers, and IT professionals that work
together to gather information, discuss business need, and define the new
system requirements
Joint Application Development

 JAD Participants and Roles

 A (JAD) team usually meets over a period of days or weeks in special
conference room or at an off-site location
 JAD participants should be insulated from the distraction of day-to-day
operations
 Objective is to analyze the existing system, obtain user input and
expectations, and document user requirements for the new system
Joint Application Development

 JAD participants and roles

 Project leader
 Top management
 Managers
 Users
 Systems analysts and other IT staff members
 recorder
Joint Application Development

 Preparing for the JAD Sessions

 Time commitment – ½ day to several weeks
 Strong management support is needed to release key participants from their
usual responsibilities
 Careful planning is essential
Joint Application Development

 JAD Advantages and Disadvantages

 Advantages
 Allows key users to participate effectively
 When properly used, JAD can result in a more accurate statement
of system requirements, a better understanding of common goals,
and a stronger commitment to the success of the new system
 Disadvantages
 More expensive and can be cumbersome if the group is too large
relative to the size of the project
Prototyping methodology

 Prototyping methodology perform the analysis, design and implementation

phases concurrently.
 All three phases are performed repeatedly in a cycle until the system is
completed.
 A prototype is a smaller version of the system with a minimal amount of
features.
Prototyping methodology

 Quickly converts requirements to working version of system

 Once the user sees requirements converted to system, will ask for
modifications or will generate additional requests
 Most useful when:
 User requests are not clear
 Few users are involved in the system
 Designs are complex and require concrete form
 History of communication problems between analysts and users
 Tools are readily available to build prototype
Prototyping methodology

 Types of prototypes
 Prototype are of two types
 Evolutionary
 Evolutionary prototype is continually refined until it contains all of
the functionality that the users require of the new system
 A requirements prototype
 Developed as a way to define the functional requirements of the
new system when the users are unable to determine exactly what
they want
 A requirements prototype review the requirements, features are
added, users are able to define the processing required for the new
system
Prototyping methodology

 Prototyping methodology
 Development of an Evolutionary Prototype
1. Identify user needs: the developer interviews users to obtain an
idea of what is required from the system
2. Develop a prototype: the developer uses one or more
prototyping tools to develop a prototype
3. Determine if the prototype is acceptable: the users decide if the
prototype is satisfactory or not. If not the prototype is go back to
the step one
4. Use the prototype: the prototype becomes the production system
Prototyping methodology

 Guidelines for Developing a Prototyp

1. Work in manageable modules.
2. Build the prototype rapidly.
3. Modify the prototype in successive iterations.
4. Stress the user interface
Prototyping methodology

 Prototyping methodology
 Development of a Requirements Prototype
 The first three steps to develop a requirements prototype
are the same as those taken to develop an evolutionary
prototype. The next steps are as follows
4. Code the new system: the developer uses the prototype as the
basis for coding the new system
5. Test the new system
6. Determine if the new system is acceptable: the users advises the
developer whether the system is acceptable or not. If not go
back to step four
7. Put the new system into production
Prototyping-based Methodology
Prototyping methodology
 Advantages:
 Most important functionalities are considered as and when they
arrive
 Consistency between requirements is checked in each iteration
 Customers feel the progress of the development process
 Developer can use the prototype in any iteration as a source for
winning customer contracts
 Disadvantages:
 Identifying the most important subset of requirements at any
stage is a tedious task
 Establishing consistency in each iteration is a repetitive work,
particularly when new subset of requirements bear no
relationships with the existing ones
 Sharing data with other systems is often not considered
 Project deadline cannot be estimated
Lecture give cse study and students compare one
methodology with another
[1] System Analysis and Design, Sixth Edition Authors: Gary B. Shelly, Thomas J.
Cashman and Harry J. Rosenblatt , Publisher: SHELLY CASHMAN SEWIES.
[2] Modern Systems Analysis and Design Third Edition Authors: Jeffrey A. Hoffer , Joey
F. George, Joseph S. Valacich Publisher: prentice hall
[3] Systems analysis and design methods Authors: Jeffrey L.; Bentley, Lonnie D.,
Dittman, Kevin Publisher: McGraw-Hill
[4] System Analysis and Design Authors: Kendal&Kendal, publishing as Prentice Hall
See u Next
Lecture