17
Chapter 17 Current Trends in System
Development
Systems Analysis and Design in a
Changing World, 5th Edition
Learning Objectives






17
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
2
17
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
3
17
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
4
Software Principles and Practices
(cont’d)

Patterns


Standard solutions to a given problem or templates
that can be applied to a problem
Reuse


17
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
5
17
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
6
Adaptive Approaches to
Development— Characteristics
17
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

7
17
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

8
17
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

9
17
The Unified Process Life Cycle
Figure 17-1
10
17
UP Phases and Objectives
Figure 17-2
11
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


17
Business modeling, requirements, design, implementation,
testing, and deployment
Three additional support disciplines

Project management, configuration and change management, and
environment
12
17
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
13
UP Disciplines Used in Varying
Amounts in Each Iteration
Figure 17-3
17
14
17
UP Life Cycle Model
Showing Phases, Iterations, and Disciplines
Figure 17-4
15
The Agile Development Philosophy
and Modeling

Agile Development Principles


17
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
16
Adaptive Methodologies Using Agile
Modeling
17
Figure 17-5
17
The Agile Development Philosophy
and Values

17
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

18
17
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
19
Agile Modeling Principles
17
Figure 17-6
20
17
Agile
Modeling
Practices
Figure 17-7
21
17
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

22
17
XP Core Values

Communication


Simplicity


In designing and implementing solutions
Feedback


In open, frequent verbal discussions
On functionality, requirements, designs, and code
Courage

In facing choices such as throwing away bad code or
standing up to a too-tight schedule
23
17
Some XP Practices

Planning


Testing


Tests are written before solutions are implemented
Pair programming


Users develop a set of stories to describe what the
system needs to do
Two programmers work together on designing, coding,
and testing
Simple designs

“KISS” and design continuously
24
17
Some XP Practices (cont’d)

Refactoring


Owning the code collectively


Anyone can modify any piece of code
Continuous integration


Improving code without changing what it does
Small pieces of code are integrated into the system
daily or more often
System metaphor

Guides members towards a vision of the system
25
17
Some XP Practices (cont’d)

On-site customer


Small releases


Produce small and frequent releases to user/customer
Forty-hour work week


Intensive user/customer interaction required
Project should be managed to avoid burnout
Coding standards

Follow coding standards to ensure flexibility
26
17
XP Core Values and Practices
Figure 17-8
27
17
XP Project Activities

System-level activities



Release-level activities



Occur once during each development project
Involve creating user stories to planning releases
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
28
17
XP
Development
Approach
Figure 17-9
29
17
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
30
17
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
31
17
Scrum Organization

Product owner



Scrum master


The client stakeholder for whom a system is being built
Maintains the product backlog list
Person in charge of a Scrum project
Scrum team or teams


Small group of developers
Set their own goals and distribute work among
themselves
32
17
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
33
Scrum Software Development
Process
17
Figure 17-10
34
Project Management and Adaptive
Methodologies

Project time management




Users and clients are responsible for the scope
Scope control consists of controlling the number of
iterations
Project cost management


Smaller scope and focused on each iteration
Realistic work schedules
Project scope management


17
More difficult to predict because of unknowns
Project communication management

Critical because of open verbal communication and
collaborative work
35
Project Management and Adaptive
Methodologies (cont’d)

Project quality management


High-risk aspects addressed in early iterations
Project human resource management


Continual testing and refactoring must be scheduled
Project risk management


17
Teams organize themselves
Project procurement management



Integrating purchased elements into the overall project
Verifying quality of components
Satisfying contractual commitments
36
17
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)
37
17
Model-Driven Architecture (cont’d)

Platform-independent model (PIM)



Platform-specific model (PSM)


Describes system characteristics that are not specific
to any deployment diagram
Uses UML
Describes system characteristics that include
deployment platform requirements
A set of standard transformations by the OMG move
a PSM to a PIM
38
17
Software
Development
and MDA
Figure 17-11
39
Metamodels and Transitions between
PIM, PSM, and Code
17
Figure 17-12
40
Partial Metamodel of UML Class
Diagram
17
Figure 17-13
41
17
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
42
17
Object Framework Types

User-interface classes


Generic data structure classes


Linked lists, binary trees, and so on, and related processing
operations
Relational database interface classes


Commonly used objects within a GUI
Classes to create and perform operations on tables
Classes specific to an application area

For use in a specific industry or application type
43
17
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

44
17
Components

Software modules that are fully assembled and ready
to use


Have well-defined interfaces to connect them to
clients or other components


Reusable packages of executable code
Public interfaces and encapsulated implementation
Standardized and interchangeable

Updating a single component does not require
relinking, recompiling, and redistributing an entire
application
45
Component Standards and
Infrastructure
17
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
46
17
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
47
17
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
48
Components and the Development
Life Cycle

17
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
49
Using Purchased Components—
Implications
17
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

50
17
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
51
17
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

52
Component Communication Using
SOAP
17
Figure 17-14
53
17
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
54