Introduction to Computer Science

1
(No Transcript)
2
Objectives

• Explain the Agile Development philosophy
• 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 ever changing
• More complex system requirements have
  necessitated a whole new set of tools
• 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 in processes use
  five important principles

5
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

6
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

7
Adaptive Approaches to Development

• Allow for uncertainty
• Use empirical controls
• Describe processes that are variable and
  unpredictable
• Monitor progress and make corrections on the fly
• Share the following characteristics
• Less emphasis on up-front analysis, design, and
  documentation

8
Adaptive Approaches to Development (continued)

• More focus on incremental development
• More user involvement in project teams
• Reduced detailed planning
• Used for near-term work phases only
• Tightly controlled schedules by fitting work into
  discrete time boxes
• More use of small work teams that are
  self-organizing

9
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 sketchy
  and minimal

10
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

11
Figure 14-1 Adaptive methodologies
using Agile Modeling
12
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 attitude that
  developers should have as they develop software
  (Figure 14-2)

13
Figure 14-2 Agile Modeling
principles
14
The heart of AM is in its modeling practices,
which give the practitioner specific modeling
techniques
Figure 14-3 Agile Modeling practices
15
Extreme Programming

• An adaptive, agile development methodology
  created in the mid-1990s
• Extreme programming
• 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

17
Figure 14-4 XP core values and practices
18
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

19
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

20
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

21
Figure 14-5 The XP development
approach
22
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

23
Figure 14-6 Scrum software
development process
24
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

25
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

26
Scrum Practices

• Sprint
• The basic work process in Scrum
• A time-controlled miniproject
• 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

27
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

28
Project Management and 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 addresses in early iterations

29
Project Management and Methodologies (continued)

• Project human resource management
• Teams organize themselves
• Project procurement management
• Integrating purchased elements into the overall
  project
• Verifying quality or components
• Satisfying contractual commitments

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

31
Figure 14-7 Software development and MDA
32
Model-driven Architecture (continued)

• Platform-independent model (PIM)
• Describes system characteristics 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

33
Figure 14-8 Metamodels and
transitions between PIM, PSM, and code
34
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

35
Object Framework Types

• User-interface classes
• Commonly used objects within a GUI
• Generic data structure classes
• Linked lists, binary trees, etc., 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

36
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 may be required,
  necessitating early compatibility and integration
  testing

37
Components

• Software modules that are fully assembled and
  ready to use
• Reusable packages of executable code
• Has well-defined interfaces to connect it to
  clients or other components
• Public interface and encapsulated implementation
• Standardized and interchangeable
• Updating a single component does not require
  relinking, recompiling, and redistributing an
  entire application

38
Component Standards and Infrastructure

• Interoperability of components requires standards
  to be developed and readily available
• Components may 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

39
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

40
Enterprise JavaBeans

• Part of the Java programming languages extensive
  object framework (JDK)
• A JavaBean that 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

41
SOAP and .NET

• Simple Object Access Protocol (SOAP) is a
  standard for component communication over the
  Internet using HTTP and XML
• An open standard
• Does not have the infrastructure requirements or
  proprietary technology of CORBA and COM
• Adopted by Microsoft as the basis of its .NET
  distributed software platform
• Used for Web services

42
Figure 14-10 Component communication using
SOAP
43
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 reimplemented system
• Components can be designed in-house and deployed
  in a newly developed or reimplemented system

44
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

45
Using Purchased Components - Implications
(continued)

• Hardware and system software providing component
  services must be acquired, installed, and
  configured before testing begins
• Components and their support infrastructure must
  be maintained after system deployment

46
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

47
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

48
Summary

• Adaptive development methodologies
• Agile Modeling and Agile Development
• Flexibility in an unpredictable business world
• Extreme Programming
• Tests are written first
• Programmers work in pairs
• Scrum
• Defines a specific goal that can be completed
  within four weeks

49
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