17

Chapter 17 Current Trends in System Development

Systems Analysis and Design in a Changing World, 5th Edition

17

2

Learning Objectives

Explain the foundations for the adaptive development methodologies

List and describe the features of the Unified Process system development methodology

List and describe the features of Agile Modeling Compare and contrast the features of Extreme

Programming and Scrum development Explain the importance of Model-Driven Architecture on

enterprise-level development Describe frameworks and components, the process by

which they are developed, and their impact on system development

17

3

Overview

The IS discipline is dynamic and always changing More complex system requirements have

necessitated a whole new set of tools The Unified Process (UP) Radical, adaptive approaches, including Agile

Development, Extreme Programming, and Scrum Model-Driven Architecture for enterprise-level systems Object frameworks and components to increase

productivity and quality

17

4

Software Principles and Practices Ubiquitous computing is the current trend in our society

Using computer technology in every aspect of our lives The effort to develop current solutions is demanding Current trends in modeling and development processes use

five important principles Abstraction

Process of extracting core principles from a set of facts or statement

Example: Metamodels describe the characteristics of another model

Models and modeling An abstraction of something in the real world,

representing a particular set of properties

17

5

Software Principles and Practices (cont’d)

Patterns Standard solutions to a given problem or templates

that can be applied to a problem Reuse

Building standard solutions and components that can be used over and over again

Methodologies A process—including the rules, guidelines, and

techniques—that defines how systems are built

17

6

Adaptive Approaches to Development

Opposite end of spectrum from predictive approaches (recall Chapter 2)

Allow for uncertainty Use empirical controls, not predictive controls

Describe processes that are variable and unpredictable Monitor progress and make corrections on the fly

17

7

Adaptive Approaches to Development— Characteristics

Less emphasis on up-front analysis, design, and documentation

More focus on incremental development More user involvement in project teams Reduced detailed planning

Used for near-term work phases only Tightly control schedules by fitting work into discrete

time boxes More use of small work teams that are self-organizing

17

8

The Unified Process (UP)

Object-oriented system development methodology (system development process)

Offered by Rational/IBM, UP developed by Booch, Rumbaugh, and Jacobson

UP should be tailored to organizational and project needs

Highly iterative life cycle Project will be use-case driven and modeled using

UML

17

9

The Unified Process Life Cycle

UP life cycle Includes four phases which consist of iterations Iterations are “mini-projects”

Inception – develop and refine system vision Elaboration – define requirements and design and

implement core architecture Construction – continue design and implementation

of routine, less risky parts Transition – move the system into operational mode

17

10

The Unified Process Life Cycle

Figure 17-1

17

11

UP Phases and Objectives

Figure 17-2

17

12

The UP Disciplines UP defines disciplines used within each phase Discipline – set of functionally related development

activities Each iteration includes activities from all disciplines Activities in each discipline produce artifacts – models,

documents, source code, and executables Learning CIS/MIS means learning techniques from these

disciplines Six main UP development disciplines

Business modeling, requirements, design, implementation, testing, and deployment

Three additional support disciplines Project management, configuration and change management,

and environment

17

13

The UP Disciplines (cont’d)

Six main UP development disciplines Business modeling, requirements, design,

implementation, testing, and deployment Three additional support disciplines

Project management, configuration and change management, and environment

17

14

UP Disciplines Used in Varying Amounts in Each Iteration

Figure 17-3

17

15

UP Life Cycle Model Showing Phases, Iterations, and Disciplines

Figure 17-4

17

16

The Agile Development Philosophy and Modeling

Agile Development Principles A philosophy and set of guidelines for developing

software in an unknown, rapidly changing environment Requires agility – being able to change direction

rapidly, even in the middle of a project Agile Modeling Principles

A philosophy about how to build models, some of which are formal and detailed and others are sketchy and minimal

17

17

Adaptive Methodologies Using Agile Modeling

Figure 17-5

17

18

The Agile Development Philosophy and Values

Responding to change over following a plan An agile project is chaordic – both chaotic and ordered

Individuals and interactions over processes and tools Working software over comprehensive

documentation Customer collaboration over contract negotiation

17

19

Agile Modeling Principles

AM is about doing the right kind of modeling at the right level of detail for the right purposes Use models as a means to an end instead of building

models as end deliverables Does not dictate which models to build or how formal

to make those models Has basic principles to express the attitude that

developers should have as they develop software

17

20

Agile Modeling Principles

Figure 17-6

17

21

Agile Modeling Practices

Figure 17-7

17

22

Extreme Programming (XP)

An adaptive, agile development methodology created in the mid-1990s

Takes proven industry best practices and focuses on them intensely

Combines those best practices (in their intense form) in a new way to produce a result that is greater than the sum of the parts

17

23

XP Core Values Communication

In open, frequent verbal discussions Simplicity

In designing and implementing solutions Feedback

On functionality, requirements, designs, and code Courage

In facing choices such as throwing away bad code or standing up to a too-tight schedule

17

24

Some XP Practices

Planning Users develop a set of stories to describe what the

system needs to do Testing

Tests are written before solutions are implemented Pair programming

Two programmers work together on designing, coding, and testing

Simple designs “KISS” and design continuously

17

25

Some XP Practices (cont’d)

Refactoring Improving code without changing what it does

Owning the code collectively Anyone can modify any piece of code

Continuous integration Small pieces of code are integrated into the system

daily or more often System metaphor

Guides members towards a vision of the system

17

26

Some XP Practices (cont’d)

On-site customer Intensive user/customer interaction required

Small releases Produce small and frequent releases to user/customer

Forty-hour work week Project should be managed to avoid burnout

Coding standards Follow coding standards to ensure flexibility

17

27

XP Core Values and Practices

Figure 17-8

17

28

XP Project Activities

System-level activities Occur once during each development project Involve creating user stories to planning releases

Release-level activities Cycle multiple times – once for each release Are developed and tested in a period of no more than a few

weeks or months Iteration-level activities

Code and test a specific functional subset in a few days or weeks

17

29

XP Development

Approach

Figure 17-9

17

30

Scrum

A quick, adaptive, and self-organizing development methodology Named after rugby’s system for getting an out-of-play

ball into play Responds to a current situation as rapidly and

positively as possible A truly empirical process control approach to

developing software

17

31

Scrum Philosophy

Responsive to a highly changing, dynamic environment

Focuses primarily on the team level Team exerts total control over its own organization and

work processes Uses a product backlog as the basic control

mechanism Prioritized list of user requirements used to choose

work to be done during a Scrum project

17

32

Scrum Organization

Product owner The client stakeholder for whom a system is being built Maintains the product backlog list

Scrum master Person in charge of a Scrum project

Scrum team or teams Small group of developers Set their own goals and distribute work among

themselves

17

33

Scrum Practices

Sprint The basic work process in Scrum A time-controlled mini-project Firm 30-day time box with a specific goal or deliverable

Parts of a sprint Begins with a one-day planning session A short daily Scrum meeting to report progress Ends with a final half-day review

17

34

Scrum Software Development Process

Figure 17-10

17

35

Project Management and Adaptive Methodologies

Project time management Smaller scope and focused on each iteration Realistic work schedules

Project scope management Users and clients are responsible for the scope Scope control consists of controlling the number of

iterations Project cost management

More difficult to predict because of unknowns Project communication management

Critical because of open verbal communication and collaborative work

17

36

Project Management and Adaptive Methodologies (cont’d)

Project quality management Continual testing and refactoring must be scheduled

Project risk management High-risk aspects addressed in early iterations

Project human resource management Teams organize themselves

Project procurement management Integrating purchased elements into the overall project Verifying quality of components Satisfying contractual commitments

17

37

Model-Driven Architecture

Model-Driven Architecture (MDA) is an OMG (Object Management Group) initiative Built on the principles of abstraction, modeling, reuse,

and patterns Provides companies with a framework to identify and

classify all system development work being done in an enterprise

MDA extracts current systems features and information and combines them into a platform independent model (PIM)

17

38

Model-Driven Architecture (cont’d)

Platform-independent model (PIM) Describes system characteristics that are not specific

to any deployment diagram Uses UML

Platform-specific model (PSM) Describes system characteristics that include

deployment platform requirements A set of standard transformations by the OMG move

a PSM to a PIM

17

39

Software Development

and MDA

Figure 17-11

17

40

Metamodels and Transitions between PIM, PSM, and Code

Figure 17-12

17

41

Partial Metamodel of UML Class Diagram

Figure 17-13

17

42

Object Frameworks

A set of classes that are designed to be reused in a variety of programs

The classes within an object framework are called foundation classes Can be organized into one or more inheritance

hierarchies Application-specific classes can be derived from

existing foundation classes

17

43

Object Framework Types

User-interface classes Commonly used objects within a GUI

Generic data structure classes Linked lists, binary trees, and so on, and related processing

operations Relational database interface classes

Classes to create and perform operations on tables Classes specific to an application area

For use in a specific industry or application type

17

44

Impact on Design and Implementation

Frameworks must be chosen early in the project Systems design must conform to specific

assumptions about application program structure and operation that the framework imposes

Design and development personnel must be trained to use a framework effectively

Multiple frameworks might be required, necessitating early compatibility and integration testing

17

45

Components Software modules that are fully assembled and ready

to use Reusable packages of executable code

Have well-defined interfaces to connect them to clients or other components Public interfaces and encapsulated implementation

Standardized and interchangeable Updating a single component does not require

relinking, recompiling, and redistributing an entire application

17

46

Component Standards and Infrastructure

Interoperability of components requires standards to be developed and readily available

Components might also require standard support infrastructure Software components have more flexibility when they

can rely on standard infrastructure services to find other components

Networking standards are required for components in different locations

17

47

CORBA and COM+

CORBA (Common Object Request Broker Architecture) is a standard for software component connection and interaction developed by the OMG An object request broker (ORB) provides component

directory and communication services The Internet Inter-ORB Protocol (IIOP) is used to

communicate among objects and ORBs Component Object Model Plus (COM+) is a standard

for software component connection and interaction developed by Microsoft

17

48

Enterprise JavaBeans

Part of the Java programming language’s extensive object framework (JDK)

A JavaBean can execute on a server and communicate with clients and other components using CORBA A JavaBean implements the required component

methods and follows the required naming conventions of the JavaBean standard

Platform independent

17

49

Components and the Development Life Cycle

Component purchase and reuse is a viable approach to speeding completion of a system Purchased components can form all or part of a newly

developed or re-implemented system Components can be designed in-house and deployed

in a newly developed or re-implemented system

17

50

Using Purchased Components— Implications

Standards and support software of purchased components must become part of the technical requirements definition

A component’s technical support requirements restrict the options considered during software architectural design

17

51

Monitoring System Performance

Examine component-based designs to estimate network traffic patterns and demands on computer hardware

Examine existing server capacity and network infrastructure to determine their ability to accommodate communication among components

Upgrade network and server capacity prior to development and testing

Test system performance during development and make any necessary adjustments

Continuously monitor system performance after deployment to detect emerging problems

Redeploy components, upgrade server capacity, and upgrade network capacity to reflect changing conditions

17

52

Services

New method of software reuse enabled by Internet—external services identified and used for applications

Called Web services and service-oriented architecture (SOA)

Microsoft .NET is service standard based on SOAP Java 2 Web Services (J2WS) is service standard for

services in Java

17

53

Component Communication Using SOAP

Figure 17-14

17

54

Summary

Adaptive development methodologies Unified Process (UP) Agile Modeling and Agile Development

Flexibility in an unpredictable business world Extreme Programming (XP)

Tests are written first; programmers work in pairs Scrum

Defines a specific goal that can be completed within four weeks