SYSTEM DEVELOPMENT METHODS

1
63901 SYSTEM DEVELOPMENT METHODS Teddy
So teddyso_at_i-cable.com
2
Teaching Strategy 8 x 3 Lecture Hours 4 x 3
Tutorial Hours Aims and Objectives This course
aims to discuss how to use structured techniques
and methods to analyze, design and implement a
system that utilizes a database. Aspects of
Human Computer Interface relevant to type of
system will be considered. Multimedia and
web-based approaches will also be discussed.
3
On completion of this course, students should be
able to explain the purpose, structure and
scope of a traditional methodology and select
and justify appropriate methods of analysis,
design and implementation or for a particular
component or application, be it traditional,
multimedia or web-based. analyze and develop
different views of a system apply structured
analysis, design and implementation techniques
to develop a simple prototype, with a suitable
interface, from conception through to
implementation. Demonstrate a knowledge of the
fundamental issues of HCI by applying interface
design principles to a prototype.
4
Content Typical techniques to be included are
user requirements capture, process models, data
models, event models and enquiry access
paths Correlation of different views of a system
such as process-data, process-event, data-event
models Structured Techniques for analysis and
design using a method such as SSADM Use of CASE
tool to check for consistency Introduction to
the concept and use of a Database Management
System Implementation of a Database to include
queries, forms and reports to meet user
requirement specification Human Computer
Interface overview, user skills and
characteristics Perceptual ability including
perception, cognition and memory Interface
design considerations, including icons, screen
layouts and interaction styles Task analysis and
interface evaluation A comparison of multimedia
and web-based approaches with the structured
approach adopted for the development of a
prototype.
5
Assessment An ASSIGMENT weighted at 50 (due on
week 12) An EXAMINATION length 1.5 HOURS
weighted at 50 (week 14) Reference
Books Avison, D. Fitzgerald, G. (2002).
Information Systems Development, McGraw
Hill. Valacich, George and Hoffer. (2003).
Essentials of Systems Analysis and Design (Second
Edition). Pearson Prentice Hall. Preece, Rogers
and Sharp. (2002). Interaction Design Beyond
Human Computer Interaction, Wyllie.
6
Medium of Instruction -- ENGLISH
7
ISSUE OF PLAGIARISM A VERY SERIOUS OFFENCE IN
ACADEMIC WORLD
8
Definition of Plagiarism
9
The Worst Consequence
10
Tool to help Identifying Plagiarism
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
Consequence? Grade -- F Suspension 3 months
21
Suggestion If you have any question ASK
22
Developing Systems System development is a
gradual progression from the clients initial
vague ideas about the problem, via a series of
transitional stages to a completely formal
statement, expressed in a programming language,
which can be executed on a machine.
23
What is a System?
24
What is a System?
A system is a set of objects or elements which
are viewed as a whole.
A system is a set of objects or elements which
are viewed as a whole and designed to achieve a
purpose.
A system is an interrelated set of objects or
elements which are viewed as a whole and
designed to achieve a purpose.
25
Normally an organization will adopt a specific
method of approach to developing a project which
they might refer to as the system or project
life cycle, methodology or project plan. This
framework provides a standard method of approach
to the system developers work which is
specified and documented before work starts.
The same framework or methodology will generally
be used for all projects developed within the
organization.
26
However it is increasingly being realized that
different applications requires different
approaches. System developers are becoming
aware that it is impossible for one single
development methodology to prescribe how to
tackle the great variety of tasks and situations
encountered.
27
In recent decades many system development life
cycle (SDLC) models have been proposed and used
including waterfall, fountain, spiral, build and
fix, rapid prototyping (rapid application
development), incremental, and synchronize and
stabilize. Among them the oldest and the best
known, is the waterfall model -- a sequence of
stages in which the output of each stage becomes
the input for the next.
28
(No Transcript)
29
(No Transcript)
30
The system life cycle is an attempt to establish
a structured approach to system analysis and
design. It divides the development of a system
into stages. It specifies the general nature of
the activities involved at each stage, the
sequence in which these activities should be
ordered and the output or deliverables from each
stage.
31
Advantages of Using System Life Cycle The
activities involved at each stage are defined,
documented and agreed. This helped when training
new staff. Among established staff it means that
a consistent approach to system development is
achieved. Communication between teams of system
developers is improved by adopting an agreed
approach Each stage can be used as milestone by
managers
32
Disadvantages of Using System Life Cycle ?
33
Stages in the System Life Cycle 1. Problem
Definition 2. Feasibility study 3.
Analysis 4. System design 5. Detailed
design 6. Implementation 7. Maintenance
34
1. Problem Definition It provides an initial
description of the problem area by means of a
written statement of the clients current
problem and the objectives of the new
system The problem, as stated by the client and
interpreted by the developer The objectives of
the new system The scope and size of the project
which areas are to be considered, who will be
involved, etc. Preliminary ideas, from both the
client and the developer, on how the system
might be developed. Recommended action for the
next stage in the development of the system
35
2. Feasibility Study The feasibility study
investigates whether there is a practical
solution to the problem outlined in the initial
problem definition. In particular it examines
the technical, financial and organizational
feasibility of the project Can it be
done? Can we afford it? Will the proposed new
system fit in existing procedure?
36
At the end of this stage a feasibility study
report is presented by the system developer to
the client and a decision is made whether or not
to proceed. A typical feasibility study report
usually includes Introduction Definition of
boundaries and scope of project Requirements Alt
ernative solutions considered Recommendations Pr
oject plan Conclusions and recommendations
37
3. Analysis This stage is divided into several
sections Fact Finding Current Physical
Model Current Logical Model Required Logical
Model Fact Finding The analysis begins with a
period of fact finding in order to build up a
detailed picture of the clients current
problems, and the needs and wishes for the new
system. This is a continuation of the process of
requirements capture.
38
Current Physical Model The next job is to sort
out what has been discovered and document it in
a way that will help organize the material. It
may be useful to begin by documenting how the
system functions currently. However sometimes
system developers will not attempt to document
these physical details. Because they feel that if
too attention is paid to how the existing system
functions, the new design will be constrained by
the current system as the developers are
accustomed to view the system from one view
point and will be unable to come up with a
radically new and more appropriate design.
39
Current Logical Model From the detail of how the
existing system works, the developer should
extract exactly what the system does as the new
system has to perform all tasks done by the
existing system plus some new functions solving
the new problems and meet clients new
additional requirements. Some of the physical
details will be changed in the new system
eventually so they will be dropped, thus leaving
the logical model as the deliverable at this
stage.
40
Required Logical Model It aims to specify what
must be done to solve the problems and meet the
requirements specified in the problem definition
and the feasibility. The deliverable from this
stage is the requirements specification which is
a logical model of the required system without
specifying the implementation.
41
Why there is no Required Physical Model at this
stage?
42
Experiences show that if the decision of
implementation is made too soon, the design of
the new system might be constrained by the
limitations of the hardware and software
selected.
43
4. System Design To determine how the problem is
solved in general. The deliverables of this
stage will be the outlines of several different
technical solutions which all meet the
requirements specified in previous stages.
What is your clients choice? A very cheap
solution which barely does the job and no
more? A medium price solution which does the job
well, plus some additional features designed by
system developer from his experiences? A high
cost solution that all functions the client could
ever need are included?
44
The proposed alternative solutions might be
different in System boundaries The proposed
systems might affect different functions of
different parts of the organization Automation
boundaries Some proposed solutions might leave
some functions to operate manually, while some
will computerize them Hardware Different
alternative solutions might propose different
hardware to be implemented Software Different
programming languages or integrated packages
might be proposed Design strategies The proposed
developments of a system might be different (e.
g. traditional life cycle vs. prototyping) User
Interface The designs of different alternative
solutions might be different Cost
45
5. Detailed Design Once one of the alternative
solutions is selected, the new system is now
specified in detail the hardware, the
software, etc. It is often referred as the
technical design specification which
includes Program design and specification Spec
ification of the user interface Specification of
the report layouts and other system
outputs Files and records specifications Hardwar
e specifications Implementation schedule What
is missed here?
46
6. Implementation In this stage the system should
be physically built. The programs are written
and tested. The supporting documentation should
be produced. The deliverables in this stage
include Program listings, test plans and
supporting documentation Hardware Manual or
operating procedures Manual or clerical
procedures User manual The changeover will take
place in the clients site. The data from the
old system will be converted into the new system.
Users training will begin. The step of
installation is sometimes listed as a separate
stage in the life cycle. After the installation,
system development team will only be involved in
maintaining and modifying the system.
47
7. Maintenance The maintenance stage starts as
soon as the system is officially handed over to
the client. Maintenance may mean to find and
correct errors which are not detected before the
system is handed over, or it may mean to modify
the system so as to meet clients evolving
requirements. In either case the system
developer will start at the beginning of the
cycle again to ascertain the clients
requirements.
48
Methodologies A software development methodology,
or structured method, is usually based on a life
cycle model of system development and has a
number of development phases with a set of steps
and rules for each phase. Whereas a life cycle
roughly divides the development of a system into
stages, a methodology takes a life cycle and
further divides each of the stages into a number
of steps. A methodology will prescribe in great
detail what tasks are involved in each step, the
nature of each task, the order in which the
tasks need to be done, what documents are
produced at each stage and what documents are
required as input to each stage. In summary, it
provides a detailed plan for producing a system.
49
Why Do We Need a Methodology? Methodologies
represent the knowledge and wisdom gained by
system developers through trial and error over a
number of decades. A methodology provides a
recipe to inexperienced system developers to
follow. Building a system involves constructing
many different models of the system. Each model
is only a partial description of the whole
system. To understand the whole system we have
to understand how the models relate to and
complement each other. A methodology provides a
framework, an agreed structure, in which these
models can be related to each other. Using a
methodology helps with the management of the
whole project by breaking down the development
process into small tasks, specifying the order
in which they should be done and the
inter dependencies of the tasks. This helps with
planning, scheduling and monitoring the progress
of the system.
50
Different Methodologies, Models and
Paradigms In the past few decades different
methodologies have been developed. Different
methodologies are suitable for different kinds
of systems Structured Systems Analysis and
Design Method (SSADM) JSD and Information
Engineering Rapid Application Development
(RAD) Object Orientation Extreme
51
Requirements Capture Subjective evidence
suggests that errors in requirements may account
for approximately 50 of the total cost of
debugging a software system.
52
Different developers have different
interpretations on the term requirements
capture. Requirement Elicitation --
requirements are drawn out by talking to clients
and users. Requirements specification --
emphasizes the task of describing rather than
identifying the requirements. Requirement
capture covers the phases of identifying
requirements (elicitation), describing them in
an appropriate language or notation
(specification), and checking with the client
that the description accurately records his
needs and wishes (validation).
53
What kind of requirements do we need?
54
Function and Non-functional Requirements Besides
functional requirements, which state what the
system was to do, what its inputs and outputs
were and how these were linked, in recent years
developers find that the non-functional
requirements are also important.
Non-functional requirements can be divided
into - non-functional requirements of the
system - non-functional requirements arising
from external sources.
55
Some typical non-functional requirements of the
system include Usability Does the system
attract or scare its targeted users? Is the
right level of help provided? Are options
clearly displayed and easy to follow? Does the
workflow fit in with the users preferred way of
working? Performance Does the system respond
quickly enough for the users needs? Can it cope
with the required volume of transactions
efficiently? What happen if the volume of
transactions exceeds the specified capacity of
the system? Reliability Can the client have
confidence that the system will perform
consistently as expected? Security How easy is
it for non-authorized users to access the system
and read or modify confidential data?
56
Non-functional requirements that arise from
external sources include Methods of operation,
such as the clients existing procedures Physical
constraints, such as the layout of the
accommodation available International quality
control standards, such as ISO/9001
57
Requirements Elicitation Requirements capture
begins with the task of finding out as much as
possible about the clients organization, their
current problems and what they would like the new
system to do for them. Good communication
skills, both verbal and written, are essential
for requirements elicitation. Requirements
elicitation includes observation, study of
relevant documents, interview, and
questionnaire. Among these different types of
activities, face-to-face interview might be the
most effective method.
58
What factors / elements are important to an
interview?
59
Interview Essentials Preparation Convenience
Dress Code Body Language
60
Types of Question When conducting interviews
there are different types of question which can
be asked and it is important to know which kinds
to use Open Ended Questions avoiding terse
replies and inviting the interviewee to develop
their opinions. These tend to start who, where,
what, when, why, e.g. "What does your job
involve?" Closed Questions seeking precise
information, e.g. "Do you have...?" or "Have you
done...?" Rhetorical Questions which do not
require an answer, e.g. "We all want to improve
productivity, dont we? Leading or Loaded
Questions Questions that suggest the answer,
e.g. "I believe in the strict control of
expenditure and debtors, what about you?
Sometimes loaded questions can put people in a no
win situation, e.g. "When did you stop beating
your husband?"
61
Try to avoid using loaded or rhetorical questions
since they serve no useful purpose. Loaded
questions in particular may cause offence
because they imply that you already know the
answer and will stick to it regardless of what
the person actually says. A useful approach is
to use open questions to get the big picture and
progressively move towards closed questions as
more detail is uncovered.
62
Listening Skills You need to show the interviewee
that you are listening to their answers and that
you are interested by Making eye contact when
speaking and listening Adopting a relaxed
posture -- leaning slightly forward conveys
interest, leaning back conveys boredom Using
verbal reassurance -- e.g. "I see what you mean"
but dont overdo it Paraphrasing -- restating
in summary format your understanding of what the
interviewee has said Clarifying -- dont be
afraid to tell the interviewee that you dont
understand something but be careful how you say
it, e.g. "Im sorry but I didnt quite
understand the last part, could you take me
through it again" is obviously preferable to "You
didnt explain that very clearly can you say it
again".
63
Document Collection There are many standard
documents commonly in use in organizations, some
have been mentioned already, e.g. profit and
loss statements, balance sheets, bills,
pay-slips. Others include order forms,
application forms, delivery notes, invoices,
business letters etc. These can provide very
useful information to the systems analyst. Other
sources of data include existing computer
systems and their documentation, the internet,
tables of data in magazines and newspapers.
64
Requirements Specification Requirements
specification involves examining the information
to filter out the important and relevant issues
and record them in an appropriate format. The
techniques of process modeling, data modeling,
and entity life histories are commonly used for
recording requirements through language and
diagrams. One of the most effective ways of
recording requirements is rapid prototyping.
Rapid prototyping allows clients to see how the
requirements are translated into computer
system. It is particularly useful when
requirements are uncertain.
65
Requirements Validation Validating requirements
is essential from the earliest stages of
requirements capture. When interviewing the
clients and users there should be constant
feedback to ensure that the developer has fully
understood what is said. Initial validation is
also carried out by taking notes during the
interview and later producing a written summary
to the interviewees. Although the structured
modeling techniques are designed to be
user-friendly and to facilitate validation, one
of the most effective methods of validating the
requirements specification is simply to talk
through it with the client and users, as the
clients original requirements are usually
expressed in natural language.