Chapter 17 Current Trends in System Development

1
Chapter 17 Current Trends in System Development

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

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

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

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

5
Software Principles and Practices (contd)?

• 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 processincluding the rules, guidelines, and
  techniquesthat defines how systems are built

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

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

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

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

10
The Unified Process Life Cycle
Figure 17-1
11
UP Phases and Objectives
Figure 17-2
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

13
The UP Disciplines (contd)?

• 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

14
UP Disciplines Used in Varying Amounts in Each
Iteration
Figure 17-3
15
UP Life Cycle Model Showing Phases, Iterations,
and Disciplines
Figure 17-4
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
Adaptive Methodologies Using Agile Modeling
Figure 17-5
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

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

20
Agile Modeling Principles
Figure 17-6
21
Agile Modeling Practices
Figure 17-7
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

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

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

25
Some XP Practices (contd)?

• 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

26
Some XP Practices (contd)?

• 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

27
XP Core Values and Practices
Figure 17-8
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

29
XP Development Approach
Figure 17-9
30
Scrum

• A quick, adaptive, and self-organizing
  development methodology
• Named after rugbys 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

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

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

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

34
Scrum Software Development Process
Figure 17-10
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

36
Project Management and Adaptive Methodologies
(contd)?

• 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

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)?

38
Model-Driven Architecture (contd)?

• 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

39
Software Development and MDA
Figure 17-11
40
Metamodels and Transitions between PIM, PSM, and
Code
Figure 17-12
41
Partial Metamodel of UML Class Diagram
Figure 17-13
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

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

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

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

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

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

48
Enterprise JavaBeans

• Part of the Java programming languages 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

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

50
Using Purchased Components Implications

• Standards and support software of purchased
  components must become part of the technical
  requirements definition
• A components technical support requirements
  restrict the options considered during software
  architectural design

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

52
Services

• New method of software reuse enabled by
  Internetexternal 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

53
Component Communication Using SOAP
Figure 17-14
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