You are on page 1of 117

W|I|N|D|U

Analyst, Design and


Development System

SILABUS

W|I|N|D|U
Tujuan :
Mengenalkan dan
menggunakan berbagai
model pengembangan
sistem perangkat lunak,
analisa terstruktur,
analisa berorientasi objek,
serta testing dan
implementasi

N
o
1.

2.

Target :
Pemula dan Menengah

Peralatan :
Komputer dengan Sistem
Operasi Windows atau
Linux
Netbeans 6.5
Sparx Enterise Architect
Redmine Project
Management

3.

4.

Materi

Tujuan

Keterangan

Metode Pengembangan Sistem


Perangkat Lunak
a.
Waterfall Model
b.
Spiral Model
c.
RAD (Rapid Application
Development )
d.
Prototyping
e.
Agile Development

Analisa Terstruktur
a.
DFD (Data Flow Diagram)
b.
ERD (Entity Relation Diagram)
c.
LRS (Logical Structure
Record)
d.
Flowchart
e.
Workflow

Analisa Berorientasi Objek (UML)


a.
Use Case Diagram
b.
Activity Diagram
c.
Sequence Diagram
d.
Deployment Diagram

Testing Dan Implementasi


a.
Black Box
b.
White Box
c.
Web Project Management

Peserta dapat
mengenal dan
menggunakan
berbagai model
pengembangan
sistem perangkat
lunak

Peserta dapat
mengenal dan
menggunakan
analisa terstruktur

Peserta dapat
mengenal dan
menggunakan UML
(Unified Modeling
Languange)

Peserta dapat
mengenal dan
menggunakan cara
melakukan testing
dan implementasi
serta aplikasi
project
management

W|I|N|D|U

Technological Obsolescence
Water Fall
SDLC
Spiral
Prototype
RAD
Agile

W|I|N|D|U

Technological Obsolescence

W|I|N|D|U

Analyst, Design and Development System

Water Fall

The Art of Lean Software Development: A Practical and


Incremental Approach

W|I|N|D|U

Analyst, Design and Development System

Water Fall

Web Engineering, Emilia Mendes and Nile Mosley.

W|I|N|D|U

Analyst, Design and Development System

Development Process

SAVILLA
7

W|I|N|D|U

Analyst, Design and Development


System

Water Fall

Software Engineering and Testing


By B. B. Agarwal, S. P. Tayal, M.
Gupta

W|I|N|D|U

Analyst, Design and Development System

Feasibility Study
A definition of the problem
Determination of technical and
economic viability
Alternative solutions and their expected
benefits
Required resources, costs, and delivery
dates in each proposed alternative
solution
Software Engineering and Testing
By B. B. Agarwal, S. P. Tayal, M.
Gupta

W|I|N|D|U

Analyst, Design and Development System

Requirement Analysis and


Sprecification
Called Software Requirement
Specification(SRS)
Detailed statement of problem
Possible alternative solution to problem
Functional requirements of the software
system
Constraint on the software system
Software Engineering and Testing
By B. B. Agarwal, S. P. Tayal, M.
Gupta

10

W|I|N|D|U

Analyst, Design and Development System

Design and Specification. The goal of


the design phase is to transform the
requirements specified in the SRS
document into a structure that is
suitable for implementation in some
programming language.
Traditional Design Approach
Object-Oriented Design Approach
Software Engineering and Testing
By B. B. Agarwal, S. P. Tayal, M.
Gupta

11

W|I|N|D|U

Analyst, Design and Development


System

Coding and Module Testing.


This phase in which we actually write programs using a
programming language.
coding can be subject to company-wide standards, which
may define the entire layout of programs, such headers
for comments in every unit, naming conventions for
variables and sub-programs, the maximum number of
lines in each component, and other aspects that company
deems worthy of standardization.
Module testing is also often subject to company
standards, including a precise definition of a test plan
(White Box or Black Box or Mix)
Module testing is the main quality-control activity that is
carried out in this phase.
Software Engineering and Testing
By B. B. Agarwal, S. P. Tayal, M.
Gupta

12

W|I|N|D|U

Analyst, Design and Development System

Coding And Module Testing


System is done in three phases
Alpha Testing is conducted by the softwaredevelopment team at the developer's site
Beta Testing is performed by a group of friendly
customers in the presence of the softwaredevelopment team
Acceptance Testing is performed by the
customers themselves. if the software is
successful in acceptance testing, the products
is installed at the customer's site.
Software Engineering and Testing
By B. B. Agarwal, S. P. Tayal, M.
Gupta

13

W|I|N|D|U

Analyst, Design and Development System

Delivery and Maintenance


The Delivery of Software is often done in two stages.
in the first stage, the application is distributed among a selected group if customers prior
to its official rlease.
in the second stage, the product is distributed to the customers.

Maintenenance
The set of activities that are performed after the system is delivered to the
customer.
Consists of correcting any remaining errors in the system (corrective
maintenance), adapting the application to changes in the environment
(adaptive maintenance), and improving, changing, or adding features and
qualities to the application (perfective maintenance).
60% from costs
20% Corrective and Adaptive Maintenance
50% Perfective Maintenance

Software Engineering and Testing


By B. B. Agarwal, S. P. Tayal, M.

14

W|I|N|D|U

Analyst, Design and


Development System

MAINTENANCE
Corrective Maintenance Activities
triggered by software faults encountered during the use of the software.

Preventive Maintenance Activities


Dealing with weakness and vulnerabilities identified by the development
team during or after deploying the software an that were nit dealt with in
the installed software

Perfective Maintenance Activities


Dealing with requests to improve the efficiency of the algorithms and data
structures, as well as user interface interactions in the design.

Adaptive Maintenance Activities


Requests from software stakeholders to adapt the software to different
operating environments, user interface styles, social contexts, or new
government regulations and standards.

Software Engineering
By Kassem A. Saleh

15

W|I|N|D|U

Analyst, Design and Development


System

Software Developmet
Life Cycle( SDLC)
The System
Develoment Life
Cycle (SDLC) model,
also called the
waterfall model, is
one of the most
popular development
models used in the
software industry. The
origin version of this
model was presented
by Wiston Royce In
1970.
Systems Analysis and Design
By Gary Shelly, Harry J. Rosenblatt

16

W|I|N|D|U

Analyst, Design, an Development System

SDLC Phases

17

W|I|N|D|U

Analyst, Design and Development System

Spiral

http://www.maxwideman.com/papers/linearity/spiral.htm

a refinement of the traditonal


waterfall model, explicity
recognizing the development
cycles in a large software
project.
This model incorporates risk
analysis into the process and
allows developers, as well as
clients, to stop the process,
depending on expected returns
from new requirements.

Planning : the detemining of


project objectives, alternatives,
and constraints

Risk analysis : The analys of


alternatives and the
identification and solution of
risks

Engineering : The development


and testing of the product

Customer evaluation : The


assessment
of the results of the
Software
Development:
Building
engineering.

Reliable Systems

18

W|I|N|D|U

Analyst, Design and Development


System

Prototyping

http://www.enggpedia.com/answers/2057/advantage
s-prototype-software-development-instead-waterfall

The prototyping model is suitable


for projects for which either the
user requirements or the
underlying technical aspects are
not well understood, however all
the risks can be identified before
project starts.
compare the prototyping model
can be used if the risks are a few
and can be determined at the
start of the project. The spiral
model, on other hand, is useful
when the risks are difficult to
anticipate at the beginning of the
project, but are likely to crop up
as the development proceeds.

FUNDAMENTALS OF SOFTWARE
ENGINEERING
By RAJIB MALL

19

W|I|N|D|U

Analyst, Design, and Development


System

Rapid Application Development


methodologies in an effort to decrease
development times.
incorporates an umbrella of methodologies
based on spiral, iterative development
technologies.
RAD techniques range from the simple use
of GUI development tools so quickly build
prototypes, to process incorporating
complete, cross functional business analyst.
Software Development: Building Reliable
Systems

20

W|I|N|D|U

Analyst, Design and Development


System

Agile Development
(2000)
Individuals and
Interactions over
processes and tools
Working software
over comprehensive
documentation
Customer
Colaburation
Responding to
change over
following a plan

The Art of Lean Software Development: A Practical and


Incremental Approach

21

W|I|N|D|U

Analyst, Design and Development System

Extreme Programming

http://www.extremeprogramming.org/map/project.html
22

W|I|N|D|U

Analyst, Design and Development System

Extreme Programming
- pair programming : accelerates the
excange of knowledge between
developers, between developer and
testers, ang generally with the team.
- An on-site customer : is available for
questions with regard to the
requiements at any ime, and takes
decisions in this respect. together with
the tester, the on-site customer
prepares funtioal tests, which can also
be used for acceptance tests later on.
- Continuous Integration : ensures
that small steps help minimize the risk
of changes, and walks thrverify that the
entier system through all tests to
cotinuously verify that the entire
system is faultless

it's possible to keep the cost of


changing software from rising
dramatically with time

Web.Engineering.The.Discipline.of.Systematic.Development.of.Web.Appli
cations.Jul.2006.
John.Wiley.and.Sons.
23
Extreme Programming Pocket Guide By Chromatic

W|I|N|D|U

Analyst, Design and Development System

SCRUM
Scrum is a management framework for incremental product development
using one or more cross-functional, self-organizing teams of about seven
people each.
It provides a structure of roles, meetings, rules, and artifacts. Teams are
responsible for creating and adapting their processes within this framework.
Scrum uses fixed-length iterations, called Sprints, which are typically two
weeks or 30 days long. Scrum teams attempt to build a potentially
shippable (properly tested) product increment every iteration.
24

W|I|N|D|U

Analyst, Design and Development


System

Scrum Master

http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Sc
rum.htm

25

W|I|N|D|U

DFD (Data Flow Diagram)


ERD (Entity Relation Diagram)
LRS (Logical Structure Record)
Flowchart
Workflow

26

W|I|N|D|U

Data Flow Diagrams


Supplementary material to support Bennett,
McRobb and Farmer:
Object Oriented Systems Analysis and Design
Using UML, (4th Edition), McGraw Hill, 2005.

27

W|I|N|D|U

In This Presentation You Will Learn:

What data flow diagrams (DFDs) are


What DFDs can be used for
Why DFDs are not used in objectoriented analysis and design
Variations in notation for DFDs

28

W|I|N|D|U

What are DFDs?

Data flow diagrams (DFDs) are one of


the diagramming techniques used in
structured systems analysis and
design
Data flow diagrams show:
Data flowing through a system to or
from users (external entities)
The processes that transform the data
The data stores that hold the data
29

W|I|N|D|U

Campaign
Manager

What do DFDs look like?

Client name +
Campaign name

Budget surplus

Budget

Campaigns

30

2.4
Check
Campaign
Budget

Cost

Adverts

W|I|N|D|U

Elements of DFDs

External Entities
People, organizations or systems that
the system being modelled
communicates with
Rather like actors, except an external
entity is not necessarily a direct user of
the system
Campaign
Typically trigger processes
Manager

31

W|I|N|D|U

Elements of DFDs

Processes
Processes that transform data
in some way
Named and numbered
Normally require at least one
input and produce at least one
output
Inputs / outputs (I/O) may flow
to or from other processes,
data stores or external entities

2.4
Check
Campaign
Budget

32

W|I|N|D|U

Elements of DFDs

Data Stores
Represent the places where data is
stored
Typically files or database tables
In a manual system can represent
physical data stores, like card indexes or
filing systems
Campaigns

33

W|I|N|D|U

Elements of DFDs

Data Flows
Flows of data between:
external entities and processes
processes and other processes
processes and data stores

Can be simple data elements or complex


data structures
Client name +
Campaign name

34

W|I|N|D|U

Data Dictionaries

DFDs are supported by data dictionary


entries
Each element is defined in a data
dictionary

Data elements - name and data type


Data structures - name and composition
Data flows - name and content
Data stores - name and data structures
contained
Processes - name and specification of the
process, for example in Structured English
35

W|I|N|D|U

Levels of DFDs

Context Diagram
Shows the system and the external
entities with which it interacts

Top Level Diagram


Shows the main processes in the system
- a decomposition of the context
diagram process

Lower Level Diagrams


Decomposition of the processes in the
top level - can be successively
decomposed

36

Context Diagram

W|I|N|D|U

Staff Assignment
Campaign
Manager

Payment
Accountant

Campaign

Staff

Client

Budget

Agate
Campaign
Management
System

Staff Grade
Advert Completion
Client Contact

Staff
Contact

Advert
Campaign
Staff

Concept Note
Concept Note

Staff

37

Top Level Diagram (Level 0)

W|I|N|D|U

Client
Campaign
Manager

Staff

Clients

1.
Record
Clients

Staff

Client

4.
Maintain
Staff

Staff Grade

Staff Members

Staff Assignment

Payment

Staff

Campaign
Budget

Accountant

Staff
2.
Plan and
Manage
Campaigns

Campaigns

Concept Note

Campaign

Contact
Cost + Completion Date

5.
Manage
Adverts

Staff
Contact
Client Contact

Adverts

Advert
Campaign
Staff

Advert Completion

3.
Prepare
Adverts

Advert

6.
Browse
Concept
Notes

Concept Note
Notes

Concept
Note

Staff

Concept
Note
38

Level 1 Diagram

W|I|N|D|U

Staff Members
Client Contact

Staff
5.1
Set Client
Contact
Contact
Adverts

Advert Completion
5.2
Set Advert
Completed

Completion Date

39

W|I|N|D|U

Data Dictionary

Advert Completion = Advert Name +


Completion Date
Advert Name = Name of advert.
Format: X(40)
Completion Date = Date on which
advert was completed. Format:
dd/mm/yyyy.

40

W|I|N|D|U

Data Dictionary

Client Contact = Staff ID + Advert


Name
Staff = Staff ID + First Name + Last
Name + Start Date + Grade + Date
Of Birth
Staff Members = {Staff}
Contact = Staff ID

41

W|I|N|D|U

Process Definition

Process 5.1 Set Client Contact


BEGIN
FIND Staff in Staff Members with
Staff ID that matches Staff ID in
Client Contact
Contact = Staff ID
Write Contact to Adverts using
Advert Name
END
42

W|I|N|D|U

Types of DFD

In some approaches different kinds of


DFD are produced:
Current physical - existing system with
physical stores, manual processes and
physical descriptions of I/O
Current logical - abstraction of current
physical to eliminate the way its done
now
Proposed logical - proposed new system
43

W|I|N|D|U

What DFDs can be used for

Modelling existing systems that are


to be re-engineered using an objectoriented approach
Modelling data flows in systems that
do no more than transform data
Modelling business processes in
existing manual systems
Determining the automation
boundary for a system (what is to be
computerized)
44

W|I|N|D|U

Why DFDs arent used in O-O

In DFDs a clear separation is made


between processes and stored data
It is assumed that all data is visible
to any process that needs to access
it
In an O-O system the processes that
operate on data are the methods of
the classes that contain the data as
attributes
Data is encapsulated within objects,
and may be hidden too

45

W|I|N|D|U

Variations in Notation

We have used the notation from


Yourdon (1989) because it is the
simplest to draw!
Alternatives include
Structured Analysis and Design
Technique (SADT)
Structured Systems Analysis and Design
Method (SSADM)

46

SADT

W|I|N|D|U

Campaign
Manager

Client name +
Campaign name

Budget surplus

Budget

Campaigns

2.4
Check
Campaign
Budget

Cost

Adverts

47

SSADM

W|I|N|D|U

Campaign
Manager

Client name +
Campaign name

2.4
Check
Campaign
Budget

Budget surplus
Budget

D1 Campaigns

Cost

D2 Adverts

48

W|I|N|D|U

SSADM

SSADM probably has the most


complex notation, which we have not
covered here, including:
Flows and stores of physical materials
Notation for duplicate elements
appearing in the same diagram
Special numbering systems for manual
and transient data stores

49

W|I|N|D|U

Other Structured Techniques

In a structured approach, data


structures are usually modelled
separately in an Entity-Relationship
Diagram (ERD), but ERDs dont show
processes
Entity Life Histories show the events
that affect entities over time
Structure Diagrams show program
structure as a tree hierarchy of
modules

50

W|I|N|D|U

Summary

In this presentation you have learned


about:
What data flow diagrams (DFDs) are
What DFDs can be used for
Why DFDs are not used in objectoriented analysis and design
Variations in notation for DFDs

51

W|I|N|D|U

References

Yourdon (1989)
Skidmore, Mills and Farmer (1994)
(For full bibliographic details, see Bennett,
McRobb and Farmer)

52

W|I|N|D|U

Entity Relation Diagram

Entity

An entity is a specific thing about which an information system collects


information
An entiti is an individual and identifiable specimen of a thing, a person or a
notion of the real world imaginations, i. f., Its. An Object
An object that represents a useful model of a problem-domain or solution domain
is called an entity
An entity is as any distinguishable person, thing, event or concept about which
information is kept
An entity is a thing which can be distinctly identified
An entity is a distinguishable object taht is tobe represented in the database
A data entity represents some 'thing' that is to stored for later reference. The
term entity refers to the logical representation of data
An entity is a person, place, or thing about which information must be kept
The word entity means anything about which we store information.
Entities are 'thing' that exist independently of other entities
An entity is a thing, concept, or object which involve information. It;s not a single
thing but rather a representation of like or similiar things that dhstr
characteristics or properties.
Well-distinguishable
objects whichFoundations
exists in ther real of
world
are called entities
Entity-Relationship
Modeling:
Database

Technology

53

W|I|N|D|U

Entity Relation Diagram

Entity-Relation diagrams provide a way to document the


entities a database along with attributes that describe
them. There are two most commonly used are Chen (Dr.
Peter P. S. Chen) and Information Engineering (IE), which
grew out of work by James Martin and Clive Finkelstein.
Both the Chen and Information Engineering models use
rectangles to represent entities.
Each Entity 's name appears the rectangle and is expressed
in the singular

Relational Database Design


Clearly Explained

54

W|I|N|D|U

Entity Relation Diagram

Relational Database Design


Clearly Explained

55

W|I|N|D|U

Entity Relation Diagram

Chen
Entity
Relationship

Atribut (Identifier)

1 : 1
1 : N
N : M

Cardinality
56

W|I|N|D|U

Entity Relation Diagram

Information Engineering (Martin)


Exactly one
Zero or one
More than one
Zero, one or more
One or more
57

Entity Relation Diagram

W|I|N|D|U

1 to 1
Chen
A

Information Engineering
A

A1

58

W|I|N|D|U

Entity Relation Diagram

Weak Entity
A Weak entity is introduced into ER
Diagram (Chen), it indicates that the
relationship between that entity and at
least one of its parents is mandatory.

Relational Database Design


Clearly Explained

59

W|I|N|D|U

Entity Relation Diagram

1 to M (Chen)
Customer_last_name

Customer_first_name

Customer_street

Order_numb
Customer_number

Customer_city

Customer_state

CUSTOMER

D
o

ORDER

Order_date

Credit_exp_date

Customer_zip

Order_filled

Customer_phone

Credit_card_numb

60

W|I|N|D|U

Entity Relation Diagram

1 to M (IE/Martin)

Relational Database Design


Clearly Explained

61

W|I|N|D|U

Entity Relation Diagram

M to N (Many to Many) (Chen)


DISTRIBUTO
R

CUSTOMER
1

ACTOR

D
o

Ha
s

Sup
ply

M
ORDER

M
Co
nt
ain

ITEM

PRODUCER

Has

62

W|I|N|D|U

Entity Relation Diagram

M to N (Many to Many) (IE/Martin)

Relational Database Design


Clearly Explained

63

W|I|N|D|U

Logical Record Structure

DISTRIBUTOR
customer_numb
CUSTOMER
(pk)
distributor_numb
customer_first_nam
(pk)
e
distributor_name
customer_last_nam
distributor_street
e
distributor_city
customer_street
distributor_state
customer_city
distributor_zip
customer_state
distributor_phone
customer_zip
distributor_contact
customer_phone
contact_person_ext
credit_card_num
card_exp_date
ORDER
ITEM
order_numb
item_numb
customer_numb
title
(fk)
distributor_numb
order_date
(fk)
order_filled
retail_price
release_date
Database Analysis and Design
genre
by I. T. Hawryszkiewycz

ACTOR
actor_numb
(pk)
actor_name
HASACTOR
actor_numb (pk)(fk)
item_numb (pk)(fk)
description
HASPRODUCER
producer_name (pk)
(fk)
Item_numb (pk)(fk)
description
PRODUCER
producer_name
(pk)
studio
64

W|I|N|D|U

Flowchart

Flowchart

https://www.cs.ucy.ac.cy/~nicolast/courses/cs654/lectures/Flow
65
charting.pdf

W|I|N|D|U

Flow Chart

Flowcharts: Plain & Simple


By Joiner Associates, Sue Reynard

66

W|I|N|D|U

Flowchart

Flowcharts: Plain & Simple


By Joiner Associates, Sue Reynard

67

W|I|N|D|U

Workflow

Flowchart + Actor (Swimline)


a process workflow model supports
understanding and assesssing a
progress design

Workflow Modeling: Tools for Process Improvement and


Applications Development

68

W|I|N|D|U

Workflow

Workflow Modeling: Tools for Process Improvement and


Applications Development

69

W|I|N|D|U

Workflow

Workflow Modeling: Tools for Process Improvement and


Applications Development

70

W|I|N|D|U

Workflow

Workflow Modeling: Tools for Process Improvement and


Applications Development

71

W|I|N|D|U

Workflow

Workflow Modeling: Tools for Process Improvement and


Applications Development

72

W|I|N|D|U

Use Case Diagram


Activity Diagram
Sequence Diagram
Deployment Diagram

73

W|I|N|D|U

Modeling Application

Can we build Skyscraper like


build dog house?

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
74
Retschitzegger

W|I|N|D|U

Modeling Applications

FUNDAMENTAL

(Software Engineering)

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
75
Retschitzegger

W|I|N|D|U
Modeling

Modeling Applications

Specifics in Engineering

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
76
Retschitzegger

W|I|N|D|U

Modeling Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
77
Retschitzegger

W|I|N|D|U

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

78

W|I|N|D|U

Use Case - Modeling


Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
79
Retschitzegger

W|I|N|D|U

Activity Diagram - Modeling


Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
80
Retschitzegger

W|I|N|D|U

Multiplicity
Unspecified
Exactly One

Zero or More

0..*

Zero or More

One or More

1..*

Zero or One (optional value)

0..1

Specified Range

2..4

Multiple, Disjoint Ranges

2, 4..6

81

W|I|N|D|U

Class Diagram - Modeling


Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
82
Retschitzegger

W|I|N|D|U

State Diagram - Modeling Applications

Web Engineering, The Discipline of Systematic Development of Web


83
Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner

W|I|N|D|U

Modeling Web Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
84
Retschitzegger

W|I|N|D|U

What Is a Sequence
Diagram?

A sequence diagram is an interaction


diagram that emphasizes the time
ordering of messages.
The diagram shows:
The objects participating in the
interaction.
The sequence of messages exchanged.

Sequence Diagram
85

W|I|N|D|U

Sequence Diagram - Modeling


Web Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
86
Retschitzegger

W|I|N|D|U

Sequence Diagram - Modeling Web


Applications

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
87
Retschitzegger

W|I|N|D|U

Black Box
White Box
Web Project Management

88

W|I|N|D|U

Testing and Project


Management

Black and White

Software Testing
By Milind G. Limaye

89

W|I|N|D|U

Testing and Project


Management

Black Box
Requireme
nt

Input

BLACK BOX

Output

Events

90

W|I|N|D|U

Testing Dan Project


Management

Black Box
Black Box involves testing
system/components considering inputs,
outputs and general functionalities as defined
in requirement specifications.
It does not consider any internal processing
by the system.
Black box testing is independent of platform,
database, and system to make sure that the
system works as per requirement defined as
well as implied ones.
Software Testing
By Milind G. Limaye

91

W|I|N|D|U

Testing and Project


Management

Advantage
Blackbox testing is the only method to prove
that software does what it is supposed to do
and it does not do something which can
cause a problem to user/customer
It is the only method to show that software is
living and it really works
Some types of testing can be done only by
black box testing methodologies, for
example, performance and security
Software Testing
By Milind G. Limaye

92

W|I|N|D|U

Testing and Project


Management

Disadvantage
Some logical errors in coding can be
missed in black box testing.
Some redudant testing is possible as
requirements may execute the same
branch of code again and again.

Software Testing
By Milind G. Limaye

93

W|I|N|D|U

Testing and Project


Management

Black Box
TestCase Designing Methodologies
Black Box testing methodology defines how
the user is going to interact with the system
without any assumption about how the
system is built.

Test Data definiton


Black Box is mainly driven by the test data
used during testing. It may not be feasible to
test all possible data which user may be using
while working with application.
Software Testing
By Milind G. Limaye

94

W|I|N|D|U

White Box

Input

Testing and Project


Management
Design
Specificatio
ns

WHITE BOX

Output

Events,
Standards
Software Testing
By Milind G. Limaye

95

W|I|N|D|U

Testing and Project


Management

White Box Advantages


Only white box testing can ensure that defined
process, procedures, and methods of development
have really been followed during software testing
White cos testing and verification can give early
warning, if something is not done properly. Its the
most cost effective way of finding defects as it
helps in reducing stage contamination
Some characteristics of software work product can
be verified only. There is no chance of validating
them. for Example, code complexity, commenting
styles, and reuse.
Software Testing
By Milind G. Limaye

96

W|I|N|D|U

Testing and Project


Management

White Box Disadvantages


It does not ensure that user requirements are met
correctly. There is no execution of code and one
does not know whether it will really ork or not.
It does not establish whether decisions, conditions,
paths, and statements covered during reviews are
sufficient or not for the given set requirements.
Sometimes, white box testing is dominated by the
use of checklists. Some defects in checklists may
reflect directly in the work product. On must do a
thorough analysis of all defects.
Software Testing
By Milind G. Limaye

97

W|I|N|D|U

Gray Box

Input

Testing and Project


Management
Requirements,
Design
Specifications

GRAY BOX

Output

Events,
Standards
Software Testing
By Milind G. Limaye

98

W|I|N|D|U

Testing and Project


Management

Gray Box Testing


Gray Box testing is done on the basic of
the internal structures of software as
defined by requirements, designs,
coding standards, and guidelines as well
as the functional and nonfunctional
requirement specifications.
Gray box testing combines verification
techniques with validation techniques
where one can ensure that software is
Software Testing
built correctly, and also works.
99
By Milind G. Limaye

W|I|N|D|U

Testing And Project


Management

Advantages
Gray box testing tries to combine the
advantages of white box testing and black box
testing. It check whether the work product
works in a correct manner, both functionally as
well as structurally

Disadvantages
Generally, gray box testing is conducted with
some automation tools. Knowledge of such
tools along with their configuration is essential
for performing gray box testing.
100

W|I|N|D|U

Testing and Project


Manajemen

Web Project
Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
101
Retschitzegger

W|I|N|D|U

Web Project Management

Project management is a human activity to shape the actions


of other humans. This human centered perspective requires
Web project managers to have enormous conflict-solving
competency, and Web teams to have an interdisciplinary
understanding. Consequently, the model used to
developWeb applications has to be very flexible, allowing for
a strongly iterative-incremental development, and involving
the contractor frequently. This means that tools and
techniques used in Web project management are particularly
characterized by the current transition from traditional
software development methods towards agile methods.
Consistent use of integrated tools is just as essential as
consequent risk management during the entire project cycle.

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
102
Retschitzegger

W|I|N|D|U

Web Project Management

From

Software Project Management to


Web Project Management

Objectives of Software Project


Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
103
Retschitzegger

W|I|N|D|U

Web Project Management

From

Software Project Management to


Web Project Management

The Tasks of Software Project Management


Leadership: Organize, control, lead staff,
inform.

Development: Set, plan, and define objectives.

Monitoring: Check and control.

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
104
Retschitzegger

W|I|N|D|U

Web Project Management

Conflicting Areas in Projects

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
105
Retschitzegger

W|I|N|D|U
Specifics

Web Project Management

of Web Project Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
106
Retschitzegger

W|I|N|D|U

Web Project Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
107
Retschitzegger

W|I|N|D|U

Web Project Management

Challenges

in Web Project
Management

Leadership challengers

Unique software systems: Software systems


are frequently developed from scratch.
Extremely technical leadership perspective:
Project management has been dominated by
technology freaks,

Poor planning: Many software products are


characterized
byofunclear
orDevelopment
incomplete
Web Engineering,
The Discipline
Systematic
of Web
Applications,
edited by objectives,
Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
108
planning

Retschitzegger

W|I|N|D|U

Web Project Management

Development

Challenges

Individuality of programmers: Even today,


many software development projects are
seen as an art rather than a technique.

High number of alternative solutions: In


software development, there is virtually an
unlimited number of alternatives to solve a
specific problem.

Rapid technological change: The rapid


technological development of hardware
Web Engineering,
The Discipline
of Systematic
Development
of Web
and software
makes
it more
difficult
to
Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
109
plan
and
organize
software
projects.
Retschitzegger

W|I|N|D|U
Monitoring

Web Project Management


Challenges

The immaterial state of software products: The


intangibility of software products makes them hard to
control. It is very difficult to determine how much of a
software product is actually completed, and the
programmer has a wide range of possibilities to veil the
actual development state. Since Web projects are
characterized by parallel development of functionality
and content, the product is more tangible for
customers and the project manager. And since Web
projects are subject to short iteration cycles, they are
usually easier to check. For these reasons, this
challenge is of less significance in Web projects.

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
110
Retschitzegger

W|I|N|D|U

Web Project Management

Development-related

Challenges in

Web Projects
Novelty

Dynamics

Parallelism

Continuity

Juvenile

Immaturity

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
111
Retschitzegger

W|I|N|D|U

Web Project Management

Multidisciplinarity: Since a Web application is composed of


content, hypertext structure, and presentation for an ideally
very broad audience, Web developers have to have different
special domain knowledge.
Parallelism: While the tasks in traditional software projects are
divided by development specific aspects, Web projects are
typically divided by problems. The result is that subgroups of a
Web project team are similarly composed with regard to their
expertise, which means that many parallel developments have to
be coordinated
Small size: Due to short development cycles and often a rather
limited budget, Web project teams are composed of a small
number of team members (around six on average,and rarely
more than ten (Reifer 2002, McDonald and Welland 2001a)).

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
112
Retschitzegger

W|I|N|D|U

Web Project Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
113
Retschitzegger

W|I|N|D|U

The

Web Project Management

Web Project Manager

Inspire all project members with the


project objectives.

Be capable of leading a multidisciplinary


team.

Create the willingness and readiness for


(democratic) cooperation.

Constantly motivate the team and solve


conflicts.

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
114
Retschitzegger

W|I|N|D|U

Web Project Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
115
Retschitzegger

W|I|N|D|U
Risk

Web Project Management

Management

Web Engineering, The Discipline of Systematic Development of Web


Applications, edited by Gerti Kappel, Birgit Proll, Siegfried Reich, Werner
116
Retschitzegger

W|I|N|D|U

ISO 9126

117