Systems Analysis and Design in a Changing World, Fourth Edition

1

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

2
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
Software Principles and Practices

• 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
• Models and modeling
• An abstraction of something in the real world,
  representing a particular set of properties
• 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

4
Adaptive Approaches to Development

• Opposite end of spectrum from predictive
  approaches
• Allow for uncertainty
• Use empirical controls, not predictive controls
• Describe processes that are variable and
  unpredictable
• Monitor progress and make corrections on the fly

5
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

6
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

7
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

8
The Unified Process Life Cycle (Figure 16-1)
9
UP Phases and Objectives (Figure 16-2)
10
The UP Disciplines

• 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
• 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

11
UP Disciplines Used in Varying Amounts in Each
Iteration (Figure 16-3)
12
UP Life Cycle Model Showing Phases, Iterations,
and Disciplines (Figure 16-4)
13
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

14
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

15
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

17
Agile Modeling Principles (Figure 16-6)
18
Agile Modeling Practices (Figure 16-7)
19
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

20
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

21
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
• 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
• 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

22
XP Development Approach (Figure 16-9)
23
Scrum

• A quick, adaptive, and self-organizing
  development methodology
• Responds to a current situation as rapidly and
  positively as possible
• A truly empirical process control approach to
  developing software
• 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

24
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

25
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

26
Project Management and 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

• Project quality management
• Continual testing and refactoring must be
  scheduled
• Project risk management
• High-risk aspects addresses in early iterations
• Project human resource management
• Teams organize themselves
• Project procurement management
• Integrating purchased elements into the overall
  project
• Verifying quality or components
• Satisfying contractual commitments

27
Model-Driven ArchitectureGeneralizing 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
• 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

28
Software Development and MDA (Figure 16-11)
29
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

30
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

31
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

32
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

33
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

34
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

35
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

36
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

37
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

38
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