Software Engineering The Multiview Approach And Wisdm

WEB Information System
Development Methodology

1

Information Systems

Set of interacting components (people,
procedures, technologies) that
 together collect, process, store and distribute
information
 to support control, decision-making and
management in organizations.

2

Information Systems

Key components of Information Systems

 Organizations
 Human
 Technologies

3

Information Systems

WEB-based IS

Computer-based IS

Paper-based IS

4

Why IS Development Methodologies

 Average completion time for IS projects: 1.5 -5 years

 68% of projects overrun schedules

 65% exceed budgets

 75% face major redesign after initial implementation

Solution lies in better and more professional
approaches to development.

5

Why IS Development Methodologies

 A methodical approach to software
development results in fewer defects and,
therefore, ultimately provides shorter
delivery times and better value.
Remember:

Goal => High quality

High quality = project timeliness

Less rework!

6

Some Terminologies

 Software development methodology
 Software development process
 Software development model
 Software life-cycle
 Software process model

7

What is IS Development
Methodology
 A collection of procedures, techniques, tools
and documentation aids which helps the
system developers in their effort to
implement a new information system.
Software Engineering
tools

methods

process model

a “quality” focus

8

IS Development Methodologies

A methodology consists of phases, themselves
consisting of sub-phases, which

• help developers plan, manage, control and
evaluate IS projects,

• guide developers in their choice of techniques
at each stages of the projects.

9

Benefits of IS Development
Methodologies

 Subdivision of complex process into small
tasks.
 Facilitation of project management and control.
 Providing a framework for applying techniques.
 Skill specialization and division of labor
 Standardization, improving productivity and
quality.

10

The General Process Model
 There are a lot of process models, and many
companies adopt their own, but all have very similar
patterns. The general, basic model is shown below:

11

Requirements
• Business requirements are gathered in this phase.

• Who is going to use the system?
• How will they use the system?
• What data should be input into the system?
• What data should be output by the system?

• This produces a nice big list of functionality that the system
should provide, which describes functions the system should
perform, business logic that processes data, what data is
stored and used by the system, and how the user interface
should work.

12

Design

• The software system design is produced from the results of
the requirements phase.

• This is where the details on how the system will work is
produced.

• Architecture, including hardware and software,
communication, software design are all part of the deliverables
of a design phase.

13

Implementation
• Code is produced from the deliverables of the design phase
during implementation, and this is the longest phase of the
software development life cycle.

• For a developer, this is the main focus of the life cycle
because this is where the code is produced.

• Implementation my overlap with both the design and testing
phases.

• Many tools exists (CASE tools) to actually automate the
production of code using information gathered and produced
during the design phase.
14

Testing

• During testing, the implementation is tested against the
requirements to make sure that the product is actually solving
the needs addressed and gathered during the requirements
phase.

• Unit tests and system/acceptance tests are done during this
phase.

• Unit tests act on a specific component of the system, while
system tests act on the system as a whole

15

Life-Cycle of a Software
Feasibility

Requirements

Design

Coding

Testing

Operations

Maintenance

16

Umbrella Activities

 Software project management
 Software quality assurance
 Software configuration management
 Reusability management
 Risk management

17

IS Process Models

 Waterfall model
 Evolutionary model
 Iterative/incremental model

 Spiral model
 V-model
 Prototyping
 Agile software development
 Cleanroom Software Engineering
 Component Assembly Model
 Rational Unified Process

18

Waterfall model

Waterfall

• Systematic stepwise refinement of a complex
problem into smaller and smaller problems.

19

Waterfall model

• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance 20

Waterfall model
 The main drawback of the waterfall model is
the difficulty of accommodating change after
the process is underway. One phase has to
be completed before moving onto the next
phase.

21

Waterfall model problems

 Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.

 Therefore, this model is only appropriate when the
requirements are well-understood and changes
will be fairly limited during the design process.

 Few business systems have stable requirements.

22

Evolutionary development

Evolutionary

• System is developed using a prototype and
refined through user feedbacks.
• Changes is seen as the norm of the model.

23


Qu ick p lan
Quick
Com m unicat ion plan
requirements

Mo d e lin g
Modeling
Qu ick d e sig n
Quick design

Deployment
Deployment
De live r y
delivery & Const r uct ion
& Fe e dback Construction
feedback of
of prototype
pr ot ot ype

24


25

 Exploratory development
• Objective is to work with customers and to
evolve a final system from an initial outline
specification. Should start with well-understood
requirements and add new features as
proposed by the customer.
 Throw-away prototyping
• Objective is to understand the system
requirements. Should start with poorly
understood requirements to clarify what is really
needed.

26

 Problems
• Lack of process visibility;
• Systems are often poorly structured;
• Special skills may be required.
 Applicability
• For small or medium-size interactive systems;
• For parts of large systems (e.g. the user
interface);
• For short-lifetime systems.

27

Iterative Development

Iterative /
incremental

• System is developed in chunks of functionality.
• The overall system is developed incrementally.

28


increment # n
Co m m u n i c a t i o n
Pla nning

M ode ling
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

deliv ery of
increment # 2 nt h increment

Pla nning

M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Pla nning
M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k

1st increment

project calendar t ime

29

Advantages
 Generates working software quickly and early during the
software life cycle.
 More flexible – less costly to change scope and requirements.
 Easier to test and debug during a smaller iteration.
 Easier to manage risk because risky pieces are identified and
handled during its iteration.
 Each iteration is an easily managed milestone.

Disadvantages
 Each phase of an iteration is rigid and do not overlap each
other.
 Problems may arise pertaining to system architecture because
not all requirements are gathered up front for the entire software
life cycle.

30

Web Design and Development

33

Developments in Information Systems:

 Information systems are entering a new phase, moving
beyond the traditional automation of routine
organizational processes and towards the existing of
critical tactical and strategic enterprise processes.
 Development of such systems needs to concentrate on
organizational aspects , delivering systems that are
closer to the culture of organizations and the wishes of
individuals.

34

Where are we with web application
design methods?
• It’s a relatively new area, most significant work only
emerged from 1993 onwards
• Very much in the infancy stages
• No one solid method has emerged
• Few approaches have been severely tested
• We have most methods and technique components
we need in existence for a web method, in almost all
cases though they have just not been integrated
• So, currently we need to work around the issue by
forming ‘hybrid’ methods that share and borrow
techniques

35

Web Methodology Disciplines

Software
Multimedia Engineering Hypertext

Human-Computer Information
Interaction Engineering
Web Engineering

Testing Requirements
Engineering

Project Modelling System Analysis
Management and Simulation and Design

36

Special features of Web Projects
 Network intensiveness
 Concurrency
 Unpredictable load
 Performance.
 Availability
 Data driven.
 Content sensitive.
 Continuous evolution
 Immediacy
 Security
 Aesthetics
37

Alternatives for WEB IS acquisition

 In-house development
 Outsourcing
• Development of IS
• Application service providers

38

A strategy to Web IS
development
 Introduce WISDM to
• offer a methodology for the socio-technical view;
• illustrate a socio-technical framework.
 Use the RUP as powerful generic framework that
can be flexibly taylored and extended by special
techniques to suit the particular project.
 Introduce various techniques to complement RUP
activities in order to better address the specific
features of Web-IS such as
• User-orientation, broad view on requirements, specific
architectural patterns, graphic design, navigation, etc.

39

The Multiview Approach and
WISDM
 Multiview‘s fundamental assumption: An IS
methodology that relies overmuch on an
engineering approach and technical rationality is, by
itself, an insufficient foundation for IS development.
 Foundations of Multiview: Needs of computer
artefacts, organizations and individuals need to be
considered jointly!
 Major concern of Multivies: Negotiation between
technological, organizational, and human aspects of
IS development.

40

WISDM
CHANGE AGENTS
Multiple
Would-be developers
perspectives:
of an information
•Technical (T)
system
•Organizational (O)
•Personal (P)

IS DEVELOPMENT METHODS
ANALYSIS

Organizational Information
Analysis Analysis

TECHNICAL
WISDM - Web IS Value Requirements

SOCIO
Development creation specification
Methodology
(emergent) Work Technical
History
Design Design
User
HCI Software
satisfaction User interface model

DESIGN
SITUATION

41

WISDM as emerging methodology
from the Multiview framework
Humans
Organisation Technology
ANALYSIS
Analysis Analysis

TECHNICAL
Value creation Requirements
SOCIO

(human activity systems) specification

Work Technical
Design Design
User HCI Software
satisfaction model
User interface
Situation DESIGN Developers
42

WISDM Methods matrix and role
of the analyst

 There is no a priori ordering of the five apects of the
WISDM matrix

 Essential aspect: Analyst works on the joint basis of
the three (T, O, P) perspectives.

43

Organizational Analysis

ANALYSIS
Analysis Analysis

TECHNICAL
SOCIO


Work Technical
Design Design
User HCI Software
satisfaction model
User interface
DESIGN

44

Organizational Analysis
 Business (strategy)
• What business is the Organization in?
• What are the products and services?
 Products and services
• What are the sources of revenue?
• What are the benefits to the business actors?
 Who are the customers?
 Who are the competitors?
 Marketing strategy (How to compete)
• What is the organization’s marketing strategy?

45

Work design

ANALYSIS
Analysis Analysis

TECHNICAL
SOCIO


Work Technical
Design Design
User HCI Software
satisfaction model
User interface
DESIGN

46

Sociotechnical design
 Foundation: Genuine participation:
involves users, managers, developers, and
others who influence each other‘s plans
policies and decisions, thus affecting future
outcomes.
 Measure user satisfaction and quality.

47

Quality workshop, WebQual
Category WebQual 4.0 Questions
Usability 1. I find the site easy to learn to operate
2. My interaction with the site is clear and understandable
3. I find the site easy to navigate
4. I find the site easy to use
5. The site has an attractive appearance
6. The design is appropriate to the type of the site
7. The site conveys a sense of competency
8. The site creates a positive experience for me
Information 9. Provides accurate information
10. Provides believable information
11. Provides timely information
12. Provides relevant information
13. Provides easy to understand information
14. Provides information at the right level of detail
15. Presents the information in an appropriate format
Service 16. Has a good reputation
Interaction 17. It feels safe to complete transactions
18. My personal information feels secure
19. Creates a sense of personalization
20. Conveys a sense of community
21. Makes it easy to communicate with the organization
22. I feel confident that goods/services will be delivered as promised
Overall 23. My overall view of this website

(Vidgen, Tab. 7-4)
48

Quality workshop,
WebQual

49

Technical Development

ANALYSIS
Analysis Analysis

TECHNICAL
SOCIO


Work Technical
Design Design
User HCI Software
satisfaction model
User interface
DESIGN

50

Information Analysis

 Elements of the analysis model
• Data model
• Flow model
• Class model
• Behavior model

51

Technical Design

 Elements of the design model
• Data design
• Architectural design
• Component design
• Interface design
• Aesthetic design
• Navigation design

52

The Rational Unified Process
 RUP is an iterative software development process
framework created by the Rational Software
Corporation, a division of IBM since 2002.
 It has an underlying object-oriented model, using
Unified Modeling Language (UML).
 RUP is based on a set of six key principles:
• Adapt the process
• Balance stakeholder priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

53

Rational Unified Process Model

Phase iteration

Inception Elaboration Construction Transition

 Inception : Establish the business case for the system.
 Elaboration : Develop an understanding of the problem
domain and the system architecture.
 Construction : System design, programming and testing.
 Transition : Deploy the system in its operating environment.

54

RUP Phases

• Inception is concerned with determining the
scope and purpose of the project;
• Elaboration focuses requirements capture and
determining the structure of the system;
• Construction's main aim is to build the
software system;
• Transition deals with product installation and
rollout.

55

RUP Phases
Project
Phases Inception Elaboration Construction Transition
1 2 3 4 5 6 7 8
Iterations within
Requirements each phase

Design

Implementation

Test

Size of
square
Workflows relative to
time spent
on
workflows

56

RUP Phases

Sample incep- transi-
UP Disciplines elaboration construction
tion tion

Business
Modeling

Requirements

Design

Implementation

...
...

57

RUP Phases

accept ance t est
cust omer use
cust omer evaluat ion coding
component t est
Release
sof t war e incr ement

refact oring

design model
cont ent
analysis model archit ect ure
cont ent navigat ion
business analysis int erf ace
it erat ion
formulat ion f unct ion
it erat ion plan conf igurat ion

58

6 UP Best Practices that particularly
apply to web-based systems
 Develop iteratively
 Manage and trace requirements
 Utilize component architectures
 Model visually
 Verify quality
 Control changes

59

WUP – Complementing the RUP

For each phase:
Inputs for each phase and iteration of the RUP

UP–activities Web–specific activities

60

WUP – Initial tasks
 Discuss the topic of your web application and
corresponding visions with stakeholders.
 Decide which techniques/views (from the RUP or
web-specific) may be useful in your special case.
 Make a gross plan for the whole development cycle.
 Make a detailed plan for the next phase.
 Keep to RUP‘s phase structure and workflows but
vary the specific techniques and views found
relevant.

61

An Object-Oriented Technique (UML)
User
System Model
requirements

• Use Case diagram
• Activity diagram
• Interaction Diagrams
• Sequence diagram
• Collaboration diagram
• Class diagram
• State diagram
• Component diagram
• Deployment diagram
62


63

Unified Modeling Language (UML)

Object Oriented Analysis and Design

The Unified Modeling Language (UML) is a standard language for
specifying, visualizing, constructing, and documenting the artifacts of
software systems, as well as for business modeling and other non-
software systems.

64

Use Case Diagram

• A use case is a set of scenarios
that describing an interaction
between a user and a system.
• A use case diagram displays the
relationship among actors and
use cases.
• The two main components of a
use case diagram are use cases
and actors.
65

Use Case Diagram

66

Sequence Diagrams

Interaction diagrams model the behavior of use cases by describing
the way groups of objects interact to complete the task. The two
kinds of interaction diagrams are sequence and collaboration
diagrams. They demonstrate how the objects collaborate for the
behavior. 67

Sequence Diagrams

68

Sequence Diagram

69

Collaboration Diagram

70

Collaboration Diagram

71

Class Diagrams

Class diagrams are widely used to describe the types of objects
in a system and their relationships. Class diagrams model
class structure and contents using design elements such as
classes, packages and objects

72

State Diagrams

• State diagrams are used to describe the
behavior of a system.
• State diagrams describe all of the possible
states of an object as events occur.
• Each diagram usually represents objects
of a single class and track the different
states of its objects through the system.

74

Activity Diagrams

• Activity diagrams describe the
workflow behavior of a system.
• Activity diagrams are similar to
state diagrams because activities
are the state of doing something.
• The diagrams describe the state of
activities by showing the sequence
of activities performed.
• Activity diagrams can show
activities that are conditional or
parallel.

76

Activity Diagrams

77

Deployment Diagrams

• The deployment diagram
contains nodes and
connections.
• A node usually represents a
piece of hardware in the
system.
• A connection depicts the
communication path used by
the hardware to communicate
and usually indicates a
method such as TCP/IP.

78

Combined deployment and
component diagram

• The diagram shows two
nodes which represent two
machines communicating
through TCP/IP.
• Component2 is dependant
on component1, so changes
to component 2 could affect
component1.
• The diagram also depicts
component3 interfacing with
component1.

79

Software Requirement
Specification (example)
TABLE OF CONTENTS
Executive Summary
I. PROJECT SCOPE
II. REQUIREMENTS DEFINITION
2.1 END-USER BUSINESS FUNCTIONALITY
2.2 USE-CASES FUNCTIONALITY
2.3 WORKFLOWS/BUSINESS PROCESSES
2.4 NON-FUNCTIONAL REQUIREMENTS
2.5 DERIVED AND IMPLICITE REQUIREMENTS
2.6 INTERFACE REQUIREMENTS
2.7 REQUIREMENTS SPECIFICATIONS

80

Design Document (example)
TABLE OF CONTENTS
Executive Summary IV
1. INTRODUCTION
2. DESIGN OF THE FOOD SYSTEM
2.1 Modular Structure of the System
2.2 Menu Structures
2.3 Modules detailed design
2.3.1 Create Class (Module 1.2.1)
2.3.2 Update Class (Module 1.2.2)
…..
2.4 System Topology
2.5 Solutions for additional Requirements
2.6.1 Error handling
2.6.2 Database catalog design
2.6.3 Connections to other systems
2.6 Data dictionary
3. INTERFACE DESIGN
4. CONCLUSION
81

Web Design Pyramid

user

Interface
design

Aesthetic design

Content design

Navigation design

Architecture design

Component design

technology

82

Software Engineering The Multiview Approach And Wisdm

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Software Engineering The Multiview Approach And Wisdm (20)

More from guestc990b6 (12)

Recently uploaded (20)

Software Engineering The Multiview Approach And Wisdm