Software Engineering The Multiview Approach And Wisdm

Post on 14-Jan-2015

4,175 views 1 download

Tags:

description

 

transcript

1

WEB Information System

Development Methodology

2

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.

3

Information Systems

Key components of Information Systems

Organizations

Human

Technologies

4

Information Systems

Paper-based IS

Computer-based IS

WEB-based IS

5

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.

6

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!

7

Some Terminologies

Software development methodology

Software development process

Software development model

Software life-cycle

Software process model

8

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

a “quality” focus

process model

methods

tools

9

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.

10

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.

11

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:

The General Process Model

12

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

Requirements

13

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

Design

14

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

Implementation

15

• 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

Testing

16

Life-Cycle of a Software

Feasibility

Requirements

Design

Coding

Testing

Operations

Maintenance

17

Umbrella Activities

Software project management

Software quality assurance

Software configuration management

Reusability management

Risk management

18

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

19

Waterfall model

Waterfall

• Systematic stepwise refinement of a complex

problem into smaller and smaller problems.

20

Waterfall model

• Requirements analysis and definition

• System and software design

• Implementation and unit testing

• Integration and system testing

• Operation and maintenance

21

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.

22

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.

23

Evolutionary development

Evolutionary

• System is developed using a prototype and

refined through user feedbacks.

• Changes is seen as the norm of the model.

24

Evolutionary development

Communicat ion

Quick p lan

Const ruct ion

of

prot ot ype

Mod e ling

Qu ick de sig n

De live ry

& Fe e dback

Deployment

requirements

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

25

Evolutionary development

26

Evolutionary development

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.

27

Evolutionary development

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.

28

Iterative /

incremental

Iterative Development

• System is developed in chunks of functionality.

• The overall system is developed incrementally.

29

Iterative Development

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analy s is

des ign c ode

t es t

increment # 1

increment # 2

delivery of

1st increment

delivery of

2nd increment

delivery of

nt h increment

increment # n

project calendar t ime

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analy s is

des ign c ode

t es t

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analy s is

des ignc ode

t es t

30

Iterative Development

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.

31

Spiral model

32

V-Model

33

Web Design and Development

34

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.

35

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

36

Web Methodology Disciplines

Web Engineering

Hypertext

InformationEngineering

RequirementsEngineering

System Analysisand Design

Multimedia

Human-ComputerInteraction

Testing

Project Management

SoftwareEngineering

Modellingand Simulation

37

Special features of Web Projects

Network intensiveness

Concurrency

Unpredictable load

Performance.

Availability

Data driven.

Content sensitive.

Continuous evolution

Immediacy

Security

Aesthetics

38

Alternatives for WEB IS acquisition

In-house development

Outsourcing

• Development of IS

• Application service providers

39

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.

40

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.

mxiixm
Rectangle

41

WISDM

IS DEVELOPMENT METHODS

CHANGE AGENTSMultiple

perspectives:

•Technical (T)

•Organizational (O)

•Personal (P)

SITUATION

History

Would-be developers

of an information

system

WISDM - Web IS

Development

Methodology

(emergent)

Organizational

Analysis

Work

Design

Information

Analysis

Technical

DesignUser

satisfaction

Value

creation

Requirements

specification

Software

model

ANALYSIS

DESIGN

TE

CH

NIC

AL

User interface

HCI

SO

CIO

42

WISDM as emerging methodology

from the Multiview framework

Situation Developers

TechnologyOrganisationHumans

Work

DesignUser

satisfaction

Technical

DesignSoftware

model

HCI

User interface

Organizational

AnalysisValue creation

(human activity systems)

Information

AnalysisRequirements

specification

SO

CIO

TE

CH

NIC

AL

ANALYSIS

DESIGN

43

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.

44

Organizational Analysis

Work

DesignUser

satisfaction

Technical

DesignSoftware

model

HCI

User interface

Organizational

AnalysisValue creation

(human activity systems)

Information

AnalysisRequirements

specification

SO

CIO

TE

CH

NIC

AL

ANALYSIS

DESIGN

45

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?

46

Work design

Work

DesignUser

satisfaction

Technical

DesignSoftware

model

HCI

User interface

Organizational

AnalysisValue creation

(human activity systems)

Information

AnalysisRequirements

specification

SO

CIO

TE

CH

NIC

AL

ANALYSIS

DESIGN

47

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.

48

Quality workshop, WebQualCategory WebQual 4.0 Questions

Usability

Information

Service

Interaction

Overall

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

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

16. Has a good reputation

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

23. My overall view of this website

(Vidgen, Tab. 7-4)

49

Quality workshop,

WebQual

50

Technical Development

Work

DesignUser

satisfaction

Technical

DesignSoftware

model

HCI

User interface

Organizational

AnalysisValue creation

(human activity systems)

Information

AnalysisRequirements

specification

SO

CIO

TE

CH

NIC

AL

ANALYSIS

DESIGN

51

Information Analysis

Elements of the analysis model

• Data model

• Flow model

• Class model

• Behavior model

52

Technical Design

Elements of the design model

• Data design

• Architectural design

• Component design

• Interface design

• Aesthetic design

• Navigation design

53

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

54

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.

55

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.

56

Size of square relative to time spent on workflows

Inception Elaboration Construction Transition

Project Phases

1 2 3 4 5 6 7 8Iterations within each phaseRequirements

Design

Implementation

Test

Workflows

RUP Phases

57

Sample

UP Disciplines

Business

Modeling

Requirements

Design

Implementation

...

incep-

tionelaboration construction

transi-

tion

...

RUP Phases

58

RUP Phases

sof t ware increment

Release

refact oring

business analysis

formulat ion

it erat ion plan

analysis model

content

iterat ion

funct ion

conf igurat ion

design model

content

architecture

navigat ion

interface

coding

component t est

accept ance t est

cust omer use

cust omer evaluat ion

59

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

60

WUP – Complementing the RUP

For each phase:

Inputs for each phase and iteration of the RUP

UP–activities Web–specific activities

61

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.

62

Technical Development

User

requirementsSystem Model

• Use Case diagram

• Activity diagram

• Interaction Diagrams

• Sequence diagram

• Collaboration diagram

• Class diagram

• State diagram

• Component diagram

• Deployment diagram

An Object-Oriented Technique (UML)

63

Technical Development

64

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.

65

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.

66

Use Case Diagram

67

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.

68

Sequence Diagrams

69

Sequence Diagram

70

Collaboration Diagram

71

Collaboration Diagram

72

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

73

Class Diagrams

74

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.

75

State Diagrams

76

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.

77

Activity Diagrams

78

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.

79

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

Combined deployment and

component diagram

80

Software Requirement

Specification (example)

TABLE OF CONTENTSExecutive Summary

I. PROJECT SCOPE

II. REQUIREMENTS DEFINITION2.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

81

Design Document (example)

TABLE OF CONTENTSExecutive Summary IV

1. INTRODUCTION

2. DESIGN OF THE FOOD SYSTEM2.1 Modular Structure of the System

2.2 Menu Structures

2.3 Modules detailed design2.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 Requirements2.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

82

Web Design Pyramid

Interface

design

Aesthetic design

Content design

Navigation design

Architecture design

Component design

user

technology