16 Systems Analysis and Design in a Changing World, Fourth Edition.

16Systems Analysis and Design in a Changing World, Fourth Edition

16

Systems Analysis and Design in a Changing World, 4th Edition 2

Learning Objectives

Explain the foundations for the adaptive methodologies to development

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

List and describe the features of Agile Modeling

16


Learning Objectives (continued)

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

16


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

16


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

16


Software Principles and Practices (continued)

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

16


Software Principles and Practices (continued)

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

16


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

16


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

16


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

16


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

16


The Unified Process Life Cycle (Figure 16-1)

16


UP Phases and Objectives (Figure 16-2)

16


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

16


The UP Disciplines (continued)

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

16


UP Disciplines Used in Varying Amounts in Each Iteration (Figure 16-3)

16


UP Life Cycle Model Showing Phases, Iterations, and Disciplines (Figure 16-4)

16


The Agile Development Philosophy and Modeling

Agile Development

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

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

16


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

16


Adaptive Methodologies Using Agile Modeling (Figure 16-5)

16


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

16


Agile Modeling Principles (Figure 16-6)

16


Agile Modeling Practices (Figure 16-7)

16


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

16


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

16


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

16


Some XP Practices (continued)

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

16


Some XP Practices (continued)

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

16


XP Core Values and Practices (Figure 16-8)

16


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

16


XP Development

Approach (Figure 16-9)

16


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

16


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

16


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

16


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

16


Scrum Software Development Process (Figure 16-10)

16


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

16


Project Management and Adaptive Methodologies (continued)

Project communication management Critical because of open verbal communication

and collaborative work

Project quality management Continual testing and refactoring must be

scheduled

Project risk management High-risk aspects addressed in early iterations

16


Project Management and Adaptive Methodologies (continued)

Project human resource management

Teams organize themselves

Project procurement management

Integrating purchased elements into the overall project

Verifying quality of components

Satisfying contractual commitments

16


Model-Driven Architecture—Generalizing Solutions

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)

16


Model-Driven Architecture (continued)

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

16


Software Development

and MDA (Figure 16-11)

16


Metamodels and Transitions between PIM, PSM, and Code (Figure 16-12)

16


Partial Metamodel of UML Class Diagram (Figure 16-13)

16


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

16


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

16


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

16


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

16


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

16


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

16


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

16


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

16


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

16


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

16


Monitoring System Performance (continued)

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

16


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

16


Component Communication Using SOAP (Figure 16-14)

16


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

16


Summary (continued)

Model-Driven Architecture (MDA)

Provides techniques for large organizations to integrate all software and all software development across the entire enterprise

Software reuse is a fundamental approach to rapid development

Object frameworks provide a means of reusing existing software through inheritance

Components are units of reusable executable code that behave as distributed objects

16 Systems Analysis and Design in a Changing World, Fourth Edition.

Documents

u abstraction

u methodologies

u patterns

documentation u

overview u

lives u

uncertainty u

development characteristics