Changing World, Fourth Edition · 2007-05-15 · (Object Management Group) initiative Built on the principles of abstraction, modeling, reuse, and patterns Provides companies with

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

Documents

Changing World, Fourth Edition · 2007-05-15 · (Object Management Group) initiative Built on the principles of abstraction, modeling, reuse, and patterns Provides companies with