17 chapter 17 current trends in system development systems analysis and design in a changing world,...
TRANSCRIPT
17
Chapter 17 Current Trends in System Development
Systems Analysis and Design in a Changing World, 5th Edition
17
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
17
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
17
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
17
5
Software Principles and Practices (cont’d)
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
17
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
17
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
17
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
17
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
17
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
17
13
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
17
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
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
17
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
17
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
17
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
17
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
17
25
Some XP Practices (cont’d)
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
17
26
Some XP Practices (cont’d)
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
17
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
17
30
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
17
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
17
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
17
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
17
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
17
36
Project Management and Adaptive Methodologies (cont’d)
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
17
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)
17
38
Model-Driven Architecture (cont’d)
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
17
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
17
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
17
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
17
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
17
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
17
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
17
48
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
17
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
17
50
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
17
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
17
52
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