Adv ISAD Class 4

Advanced Information Systems
Analysis and Design

Class 4: Design, Implementation, and Testing
Alan R. Hevner
University of South Florida
September 13, 2018 Copyright © 2018 Alan R. Hevner 1

Class 4 Outline
 Design Principles and Methods
 Design Principles
 Architecture Design
 Detailed Design
 Component Based Development of Software Systems
 Components and Middleware Connection
 Service Oriented Architectures
 Web Services
 Opportunities and Challenges
 Coding and Implementation
 Software Testing
 Testing Objectives
 Why is Testing So Hard?
 Software Inspections
 Functional and Structural Testing

Purposes of Design
 The Design Activity transforms the
specification into a Design Artifact.
 The end purpose of the design is to
produce detail and information suitable for
the coding activity.
 The end-user of the design are
programmers and testers.

What Is a Design?
 A design is a presentation of the software
system organization.
 software architecture
 data structures
 algorithms
 In addition, a design provides the framework
for partitioning the requirements into
“subsystems”.

Step-wise Refinement
 Step-wise refinement provide intellectual control
by delaying complex system details until an
appropriate level of detail is achieved.
 In short, complexity should be pushed down into
the details where the problem can be subdivided
and the complexity can be looked at as it relates to
each of the individual subsystems.

Information Hiding
 Information hiding can be though of as a “need
to know” approach to data and algorithms.
 Only code or modules that really need to know
how data is manipulated (algorithms) or how it is
represented (data structures) should have
visibility.
 Why? This approach helps prevent designers
from designing in dependencies on data
implementation.

The Designer's Art and Craft
 The designer acquires experience as time
goes on.
 Very seldom is the “art” actually codified, but
there are some fundamental rules and
notions that can be taken advantage of, but
these rules are not foolproof, nor are they a
substitute for training, thought and good
judgment!
Common Services
 It’s often helpful to identify common service
functions early, such as sting handling functions.
 Common services are functions that are needed by
more than one subsystem or module.
 Early identification allows us to prevent multiple
implementation of the same function. This would
destroy our system’s “cohesion”.

Major Data Structures
 Major data structures fall into two camps:
Permanent and temporary.
 The permanent data structures are the data
structures (such as global data) that will persist
for the entire duration of the system activity.
 The temporary data may be common data
structures that are used to pass information
between routines (such as parameter lists) that
will be discarded after it has served its functions.
Major Algorithms
 The major algorithms are the procedures that ‘do
the work’ of the system.
 For a payroll system, an algorithm that computes
withholding for taxes is clearly a major algorithm.
 There can be multiple functions that involve major
algorithms: if the payroll system is for international
use, the withholding algorithm would probably be
different for each country!

High-level (“Architectural”) Design
 Architecture is usually the product of the designer’s
experience. After building printer firmware for
several years, a designer would call upon
experience of previous printer systems to build the
next.
 Development organizations may have pre-defined
architectures for all systems (e.g., client-server
architectures)
 Architectural design is typically presented in the top
levels of the system hierarchy and in the effective
use of common services.

Traceability Matrices
 Traceability Matrices allow us to track the
partitioning of the requirements into the
individual subsystems.
 In addition, these matrices allow us to find
which requirements are fulfilled by each
subsystem.
 Remember, a single requirement may be
assigned to more than one subsystem!

Subsystem Interfaces
 In general, it is best to minimize the number
of interfaces to each subsystem. This can
help reduce “coupling”, but not always. At
least it can localize coupling problems to
select locations.
 Subsystem interfaces should always, in my
opinion, return a success/failure code.

Environment Interfaces
 In addition to subsystems, the “environment”
has an interface, sometimes beyond our
immediate control.
 An example of the “environment” interface
would be operating system calls, calls to an
off-the-shelf library (such as a string handling
library and so on.)

Detailed Design
 “Detailed Design” is essentially the
decomposition of subsystems into “work
packages” or software modules for the code-
smiths (programmers).
 This activity focuses on the final step of
decomposition, but still leaves room for the
code-smith’s art: it stops short of code itself!

Defining Module Interfaces
 Module interfaces are essentially of two types:
internal and external.
 Visibility of the internal interfaces are unique to
the module itself: this is the idea of information
hiding. Most modern programming languages
have features that support this.
 External interfaces should be limited to expose
only the functionality that is required by the rest
of the subsystem or system.
Specifying the Module Functions
 Usually module functions can be easily specified:
public function names, input parameters, output
parameters, and error codes.
 Occasionally, when a ticklish or unique algorithm
is needed, it can be specified using “pseudocode”.
 Be careful not to over specify: the code-smiths
have skill sets that will be brought to bear that add
value. We often gain little or nothing by over-
specifying modules.

Module Documentation
 The documentation for the modules will vary
from group to group, but should as a
minimum include:
 Name of the module.
 Description of parameters.
 Name of the module source code file.
 Pseudocode for key algorithms.
 Error conditions and codes returned by the
module.
Dieter Rams’ Principles of Good Design
1. Good design is innovative.
2. Good design makes a product useful.
3. Good design is aesthetic.
4. Good design makes a product understandable.
5. Good design is unobtrusive.
6. Good design is honest.
7. Good design is long-lasting.
8. Good design is thorough down to the last detail.
9. Good design is environmentally friendly.
10. Good design is as little design as possible.

Component Based Software
Development (CBSD)
 Business Objectives
 Time-to-Market
 Adaptability
 Supporting Integration
 Business Alignment
 Upgradeable
 Information Systems Objectives
 Productivity
 Quality
 Cost Reduction
 Manageable Processes
 Personnel Skills
 Control over Outsourcing and Acquisition

What is a Software Component?
 Essential Characteristics
 Identifiable
 Traceable
 Replaceable by component offering the same services
 Interfaces must not change
 Accurate documentation
 Desirable Characteristics
 Implementation is hidden
 Independent of other components
 Encapsulated
 Reuse dynamically
 Adaptable services
 Plug compatible
 Certified and authenticated

Commercial Off-The-Shelf (COTS)
Components
 Source
 Independent Commercial Item
 Special version of Commercial Item
 Component produced by Contract
 Existing Component from External Sources
 Component produced In-House
 Modification Required
 Extensive reworking of code
 Internal code revision
 Necessary tailoring and customization
 Simple Parameterization
 Little to no modification

Component Based Development
Process
 Understand
 Business Model
 Component Architecture
 Provision
 Acquire
 Subscribe
 Modify
 Wrap
 Create
 Assemble
 Implement
 Execution
 Deployment

Customer Business Strategy Market
Demands Demands
Periodic Reviews
Evolutionary Requirementsn (E-Cycle n)

CBSD Life Cycle
(E-Cycle)
Requirements Reviews (QA)
Requir ements
Repository
Development
Incremental Process
Architecturen (E-Cycle n)
To Test
Rep.
Flow Legend:
Development Ext ernal

Control Architecture Reviews (QA)
Ar chitecture
Repository
Process Information
Traces Designn (E-Cycle n)
Design
Repository
Design Reviews (QA)
Component Acquisition
SCM
Component Component Assemblyn
• Reuse Repository (E-Cycle n)
• Purchase From Reqs.
Rep.
• Implement Integration Testing

Test Suite (QA)
Repository
Unit Testing (QA)
System Incremental Releasen SCM

(E-Cycle n) Release
Repository
System Integration Testing (QC)
Release Deploymentn (E-Cycle n)

Component Provider Solution Assembler
 Division of labour  Choice of alternative
 Specialisation of skills implementations
 Containment of complexity  Mix best of breed
 Outsourcing supply  Improved fit and completeness
 Customisation of solution
 Reuse of designs and  Quality of ready made
components components
 Plug and play interoperability
 Customisation of solution
Solution User
 Replacement with alternative
components
 Upgradeability of components
 Maintenance of components
 Incremental replacement
Units of exchange
We catalog
components We sell
We identify
components
components
We execute
We design
components
components
We build
components
Application Delivery for E-Business
Application
Service
Providers Components Frameworks
Component Market
Workflow Multiple
XML Engines Devices Business
CBDi Methods and Techniques

Process
Platforms and Technologies
COM+ Modeling
EJB
Middleware
CEE Service/Interface
Architecture
Message
Brokers EAI
Messaging Component
Architecture
Application Legacy Packaged External New Legacy
Servers Apps Apps Agencies Component Rejuvenation

Source: CBDi Forum
Use Workflow and Enterprise Application
Integration (EAI) to Glue Together
Workflow EAI
• Manage business process • Technical and semantic conversion
• Change dynamically • Wrap legacy systems
• Reuse Business Services • Change integration rules dynamically
The Component Market
 Everything’s a component
 Do we need to be more specific, or more generic?
 Difficult to talk about issues of the ‘market’ when it seems so imprecise
 Difficult to convince consumers when the term seems so broadly applied
 Is it the
 Component Market?
 Reusable Asset Market?
 Packaged Software Market?
 The “Components that encapsulate their implementation…only accessible
via published interfaces…binary executables…etc, etc….” Market?
Models Class Components Frameworks Applications

Libraries
What Could Fuel Growth?
 The Operating Platform
 Operating environment geared towards components
 ORACLE/IBM/etc – EJB
 Microsoft – COM+
 MSDN Component Resources
 Making it easier to build components
 Framework-based Platform
 Microsoft .NET
 Oracle
 Platform vendors promote components, ‘encourage’ ISVs
 Higher Value Components
 Frameworks
 Supersede current Packaged Application market
 Standardization
 B2B processes requires consensus
 Standardized industry frameworks
 More off-the-shelf implementation of business components
 Continued pressures on IT
 Delivery on-time, on-budget
 Skills shortage

What Might Inhibit Market Growth?
 Commoditization
 Growth in volume, but not in dollars
 Platform expansion
 Generic components and services provided as part of
the platform
 Technology centric
 Components not independent enough
 Consumers desire solutions not components
 Packaged application vendors improve their act

Commoditization – Part of the Platform
• Differentiated Competitive Competitive Competitive
• Need to retain Advantage Advantage Advantage
control Systems Systems Systems
Extensions Business Services Framework

2000’s
Extensions Application Services Framework
Component Model 1990’s

• Commoditised
• Where, how and
who provides
Database 1980’s
becomes irrelevant
to competitive Operating System
advantage systems
Hardware

Certifier
Supply Chain Roles
Authoring Author Domain
Application Web
Hosting Service Service
Provider Provider
Value Added Value Added Software Custom Requirements

Service Component Royalty Component
Broker Broker Clearing Clearing Software
Selling
(Reseller) (Reseller) House House
Service
Portal
Payment
Systems Integrator
Consuming
IT Organization
IT Operations Micro Billing

Agent
Using
End User Organization

Service Oriented Architectures (SOA)
 SOA is a variation of Component-Based
Development that includes the integration of
Web Services
 SOA is key to interoperability and flexibility
requirements for on-demand business.
 SOA supports end-to-end integration across the
enterprise and among business supply chain
partners.
 SOA provides a business process model that
allows customers to respond quickly to new
customer requirements, new business
opportunities, and competitive threats.
Web Services
 A web service is an application function packaged
as a reusable component and available via a Web
interface.
 Functional Description - Provides information or
changes information from one consistent state to
another.
 Quality of Service requirements
 Interoperability
 Location Transparency
 Loose Coupling
 Well-Defined Interfaces (Web Services Description
Language - WSDL)
 Stateless Service Design
 Service Granularity (Fine-Grained vs. Coarse-Grained)
IBM Tutorial on SOA
 IBM Service-Oriented Architecture and Web
Services at
http://www.ibm.com/developerworks/webservices/newto/

SOA Connection Technologies
 XML is the common language for Web
Services.
 SOAP provides the protocols for
exchanging information on the Web.
 UDDI is the standard for publishing
services on the Web via a Services
Registry.

Request-Response Message Exchange

Brokered Message Exchange

SOA Development Models

Unique Aspects to SOA Development
 Service Categorization and Aggregation

 Policies and Aspects
 Meet-in-the-Middle Processes
 Semantic Brokering
 Service Harvesting and Knowledge
Brokering

SOA Modeling Template

Automotive Work Order Example

Class Diagram of Work Order

Services Model of Work Order

Business Process Model for Work
Order

Business Interaction Model for Work
Order

Technical Challenges
 Data size explosion
 XML tagging and textual representation
 Performance issues
 10x to 100x slowdown
 Protocol stew
 E-Utilities
 Quality of Service
 Legal consequences
 Support levels
 Dynamically configurable web services
 Context aware components

Software as a Service (SaaS)
 Gartner Report (2/19/2009)
 SaaS Assumptions
 SaaS is less expensive than on-premises software
(True, short-term)
 SaaS is faster to implement than on-premises software
(True for simple requirements)
 SaaS is priced as a utility model (False in most cases)
 SaaS does not integrate with on-premises applications
and/or data sources (False)
 SaaS is only for simple, basic requirements (False, but
there are complexity limits)
Coding and Implementation
 Writing software code is the essence of
software development
 An essential skill for all activities in the SDLC
 New paradigms of software development
have reduced the percentage of the system
that must be coded from scratch
 New coding is required in new value-added
applications and critical system interfaces

What is Code?
 P. Ford, “What is Code?” Bloomberg
Business, June 11, 2015 Issue
http://www.bloomberg.com/graphics/2015-
paul-ford-what-is-code/
 This is an excellent survey of current state-
of-the-art programming languages and
environments

Programming Languages
 Sort through the plethora of coding options
and learn the ones relevant to your needs
 A list of languages can be found at:
 https://en.wikipedia.org/wiki/Comparison_of_programming_languages
 Most Popular Languages (2018)

 https://stackify.com/popular-programming-languages-
2018/?utm_referrer=https%3A%2F%2Fwww.bing.com%2F

Testing Objectives
 Find defects
 Maximize bug count
 Block premature product releases
 Help managers make ship / no-ship decisions
 Minimize technical support costs
 Assess conformance to specification
 Conform to regulations
 Minimize safety-related lawsuit risk
 Find safe scenarios for use of the product
 Assess quality
 Verify correctness of the product
 Assure quality
 You cannot test quality into a software system!!

Software Development Process V-Model
Customer Acceptance
Requirements Analysis Test Scripts Field Test
System Test Scripts

Software Architecture System Integration
System Test
Subsystem
Software Design Test Scripts Subsystem Integration
Subsystem Test
Implementation
Unit Test
Testing During Requirements
 Customer/Stakeholder Interactions
 Inspect the Requirements for:
 Correctness – Do we have the right requirements?
 Completeness – Is everything there?
 Compatibility – Are they consistent?
 Achievable – Can they be designed and
implemented?
 Reasonable – Do requirements tradeoffs make
sense?
 Testable – Can we know if product meets
requirements?
 Develop Customer Acceptance Test Cases

Testing During Design
 Architecture Reviews
 Design Inspections
 Structural Design
 Top-Down Decomposition
 Bottom-Up Composition
 Data Design
 Logic Design
 Traceability between Requirements and
Design
 Goodness of the Design
 Develop System/Subsystem Integration Test
Cases
Testing During Implementation
 Code Inspections
 Traceability from Requirements to
Design to Code
 Documentation Inspections
 Develop and Execute Unit Test Cases
 Emphasis on Structural Testing
 Move completed modules into
Integration Testing
System/ Subsystem Integration
Testing
 Use Incremental Development to
Manage Complexity of Integration
 Top-Down Integration
 Drivers and Stubs
 Bottom-Up Integration
 Harnesses
 Customer Acceptance Testing

 Beta Testing – Questionable value?

Testing in Maintenance and
Enhancement
 Maintenance accounts for ~70% of software
cost.
 Bugsfound during system operation
 Enhancements required by the customer
 Scheduled releases will include both bug fixes
and new features
 Averagetwo scheduled releases per year
 Emergency releases for critical fixes
 Regression Testing – Run all previous test
cases again to ensure that fix does not have
side effects
Why Is Testing So Hard?
 Whittaker Paper
“This difficult, time-consuming process (testing) requires
technical sophistication and proper planning. Testers must
not only have good development skills – testing often
requires a great deal of coding – but also be
knowledgeable in formal languages, graph theory, and
algorithms. Indeed, creative testers have brought many
related computing disciplines to bear on testing problems,
often with impressive results.” (p. 71)

Four Phases of Testing
1. Modeling the software’s environment
2. Selecting test scenarios
3. Running and evaluating test scenarios
4. Measuring testing progress

Modeling the Software’s
Environment
 Software Interfaces
 Human Interfaces (Mouse, Keyboard)
 Software Interfaces (API’s)
 File System Interfaces (OS, Databases)
 Communication Interfaces (Devices)
 Thorough Testing must include both valid

and invalid inputs from all external
interfaces.
Selecting Test Scenarios
 Goal is best test data adequacy criteria
 Sample criteria:
 Each source statement executed
 Each branching structure executed on each of its
branches
 Each data structure initialized and used
 Each input and output used
 Each interface exercised
 Tests have same statistical properties as input
domain
 Tests have same operational profile as typical user

Running and Evaluating Test
Scenarios
 Automate as much as possible
 Scenario evaluation – Did the test result
in the expected output?
 Test Oracle can be automated or human
 Failure Reproduction
 Environmental conditions
 Regression Testing
 Prioritize and Minimize regression tests

Measuring Testing Progress
 Testing Metrics are controversial
 Isa high bug count good or bad?
 Coverage metrics are useful
 When do we stop testing and release the

product?
 Bug Discovery Stability
 Testability
 Reliability models
 Operational profiles of usage
 Credible track record

Introduction to Software
Inspection
 Introduced in IBM in early 1970’s by Fagan
 Evolved into IEEE STD 1028-1988
 Claims
 80% of defects detected early
 Fielded defects reduced by factor of 10
 Productivity increased by reducing rework time
 Competitive advantage via higher quality products

Software Inspection Process
 IEEE STD 1028-1988 Flowchart
 Planning
 Overview
 Preparation
 Examination meeting
 Rework
 Follow-up

Software Inspections
 Objectives
 To find defects in the artifact
 Inspection Teams
3 to 6 members include author
 Roles
Moderator Recorder
Reader Domain Experts
Testers Requirements Engineers

Software Inspections
 Work Products – Artifacts
 All SW Development Products (e.g.,
Requirements, Design, Code, Documentation,
Test Cases, etc.)
 Meeting Time Limits
2 hours max for level of concentration
 Outputs
 Listof defects
 Inspection Report

Formal Technical Peer Reviews
 Variations of Inspections are defined by:
 Objective
 Number of Participants
 Preparation
 Roles
 Meeting Duration
 Work Product Size and Maturity
 Outputs
 Process Discipline
 Examples – Walkthroughs, Milestone Reviews

Initiating Inspections on a Project
 Read Books and Success Stories

 Sell the Software Development Process
Leaders
 Convince Management of Benefits
 Develop an Inspection Insertion Plan
 Customize Inspections to your Project
 Obtain Training in Inspections

Software Testing Types
 Functional (Black Box) Testing
 Testing on Inputs to Outputs
 Functional testing focuses on the essential functions
of the system.
 Sometimes this is called “requirements-based
testing”, and can happen at different levels within the
system.
 Structural (White Box) Testing
 Control Flow Paths
 Data Flow Paths

Test Oracles
 Test oracles check the output of the program
against the specification.
 Automated testing must include automated
Oracles.
 In the case of oracles, this permits the test writer
to write the test, the let the oracle determine if
the outputs are valid or not.
 Developing testing oracles is a challenging task.

Normal vs. Exception Test Cases
 Test cases that test what the how the system
translates expected inputs (“normal” mode) into
outputs are “normal”.
 Test cases that look at what the system does
when invalid or erroneous inputs occur are the
“exception” test cases.
 Requirements should not only specify how the
system should operate when things are going
well, but they should also specify what the
system should do when things go wrong!
Interface Testing
 Interfaces are the boundaries between
subsystems.
 Similar to fault-based testing, the tester
tries to imagine how the software might
malfunction by passing out-of-range or
invalid parameters, incorrect parameters,
and so on.

Boundary-Value Tests
 Boundary-value tests are design to test at
the extremes of the permissible value
range.
 Good test cases are, for instance,
 one less that the permissible value,
 the most extreme permissible value,
 and one more than the extreme permissible
value
in the case of integers.
Structural (Program-Based)
Testing
 In addition, if the code is “open” for examination
by the tester, the tester can also select values
based on the way the program is put together.
 Some of the more interesting test cases would
come from examining control flow within the
program (if, then, else, switch) or
computations, such as those that may cause
arithmetic exceptions, such as overflow or divide
by zero errors.

Variations on Coverage Testing
 There are different “types” of coverage
testing that cover different aspects of the
program.
 Control-flow testing
 Path coverage
 Branch Coverage
 The differences are subtle, but important.

Control-flow Graphs and Coverage
 Control flow graphs reflect the number of

decision points in a program that can
transfer or re-direct the program flow.
 In control-flow coverage, the possible
flows of the program through the path are
checked to make sure that each statement
is executed by some test (node coverage).

Path Coverage
 In the case of path coverage, the control-
flow graph is checked against the test
cases to ensure that every possible path is
taken.
 Path coverage requires that each possible
path and it’s variations are checked.
 The notion here is that different paths can
(and usually do) result in different data
transforms.
Branch Coverage
 Branch coverage requires that all branches of a
program to be taken, which results in statement
coverage.
 Unlike statement coverage, however, all
branches must be covered.
 Think about a switch statement that has some
“cases” that do not terminate in “break”
statements. Instead, the control “drops through”
to the next case statement. Statement coverage
does not require each “case” to be tested, but
branch coverage does!
Data Flow Coverage
 A concept similar to control-flow coverage is
dataflow coverage (except that it focuses on the
use of data, not control.)
 We need to follow paths in the program from the
point at which a variable is defined or set to the
point in which it is used. (“def-use” pairs.)
 Think of the “define/set” and “use” relations as
nodes, then consider the similarities to control-
flow graph testing.
Choosing a Testing Method in
Practice
 Practical restraints very often influence the
choice of methods:
 Resources available: How much time is
available, and how many people?
 Feasibility: Can it be done in a reasonable
amount of time? (Such as full branch
coverage testing)
 Process: Is the testing process mature
enough to support the method?

Automated Testing
 Automated testing can fall into two areas:
automated application of tests and automatic
test generation.
 Automatic test generation uses a formal
representation of the specification to build test
script that can be applied by a test harness to
the system under test.
 Automated Testing Tools:
 IBMRational Testing Suite
 HP Quality Center

Class 4 Discussion Questions
 What programming languages do you know

and use? Do you think it is important to stay
current with new programming languages?
 Why is software testing so hard?

Quiz 1 Review
 Covers material from Classes 1 – 5
 Open book, Take home quiz
 One week to complete
 Posted at noon on September 24
 Due at end of day on October 1
 Estimated effort = 2 to 4 hours

Class 1 Outline
 Introduction to Course
 Instructor and Students
 Syllabus
 Expectations
 Information Systems Development
 Software Engineering in Information Systems
Development
 Software Development Concepts
 Software Development Principles
 Ethics and Professional Conduct

Class 2 Outline
 Software Development Processes and Methods – Definitions
 Plan-Driven Processes and Methods
 Waterfall Development Models
 Spiral Development Models
 V-Model with Incremental Development and Cleanroom Concepts
 Agile Processes and Methods
 The Agile Manifesto
 Rational Unified Process (RUP)
 Extreme Programming
 Control in Flexible Software Development
 DevOps
 Concepts
 Industry Status
 Risk Management
 Risk Identification, Analysis, and Control
 Using Risk to Balance Discipline and Agility
 Designing the Right Process and Method for Your Project
 Cost Estimation for Software Projects
August 30, 2018 Copyright © 2018 Alan R. Hevner 89

Class 3 Outline
 Cleanroom Software Engineering
 Requirements Definitions and Properties
 Quality Attributes
 Quality Attributes for a Telemedicine System (LeRouge et al. 2004
paper)
 Software System Specification
 Formal Specification Languages
 Model-Driven Specification
 Architecture-Centric Specification
 Component-Based Software Development
 Hybrid Specification Approaches

Class 4 Outline
 Design Principles and Methods
 Design Principles
 Architecture Design
 Detailed Design
 Component Based Development of Software Systems
 Components and Middleware Connection
 Service Oriented Architectures
 Web Services
 Opportunities and Challenges
 Coding and Implementation
 Software Testing
 Testing Objectives
 Why is Testing So Hard?
 Software Inspections
 Functional and Structural Testing

Class 5 Outline
 Rob Schaaf’s Presentation on Project
Management
 Requirements
 Project Management Basics
92 Copyright © 2018 Alan R. Hevner September 13, 2018

Adv ISAD Class 4

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Adv ISAD Class 4

Încărcat de

Drepturi de autor:

Formate disponibile

Advanced Information Systems

Analysis and Design

September 13, 2018 Copyright © 2018 Alan R. Hevner 1

September 13, 2018 Copyright © 2018 Alan R. Hevner 2

September 13, 2018 Copyright © 2018 Alan R. Hevner 3

September 13, 2018 Copyright © 2018 Alan R. Hevner 4

September 13, 2018 Copyright © 2018 Alan R. Hevner 5

September 13, 2018 Copyright © 2018 Alan R. Hevner 6

September 13, 2018 Copyright © 2018 Alan R. Hevner 8

September 13, 2018 Copyright © 2018 Alan R. Hevner 10

September 13, 2018 Copyright © 2018 Alan R. Hevner 11

September 13, 2018 Copyright © 2018 Alan R. Hevner 12

September 13, 2018 Copyright © 2018 Alan R. Hevner 13

September 13, 2018 Copyright © 2018 Alan R. Hevner 14

September 13, 2018 Copyright © 2018 Alan R. Hevner 15

September 13, 2018 Copyright © 2018 Alan R. Hevner 17

September 13, 2018 Copyright © 2018 Alan R. Hevner 19

September 13, 2018 Copyright © 2018 Alan R. Hevner 20

September 13, 2018 Copyright © 2018 Alan R. Hevner 21

September 13, 2018 Copyright © 2018 Alan R. Hevner 22

September 13, 2018 Copyright © 2018 Alan R. Hevner 23

Evolutionary Requirementsn (E-Cycle n)

Development Ext ernal

• Implement Integration Testing

System Incremental Releasen SCM

System Integration Testing (QC)

Release Deploymentn (E-Cycle n)

September 13, 2018 Copyright © 2018 Alan R. Hevner 24

CBDi Methods and Techniques

September 13, 2018 Copyright © 2018 Alan R. Hevner 27

Models Class Components Frameworks Applications

September 13, 2018 Copyright © 2018 Alan R. Hevner 30

September 13, 2018 Copyright © 2018 Alan R. Hevner 31

Extensions Business Services Framework

Component Model 1990’s

September 13, 2018 Copyright © 2018 Alan R. Hevner 32

Value Added Value Added Software Custom Requirements

IT Operations Micro Billing

End User Organization

September 13, 2018 Copyright © 2018 Alan R. Hevner 33

September 13, 2018 Copyright © 2018 Alan R. Hevner 36

September 13, 2018 Copyright © 2018 Alan R. Hevner 37

September 13, 2018 Copyright © 2018 Alan R. Hevner 38

September 13, 2018 Copyright © 2018 Alan R. Hevner 39

September 13, 2018 Copyright © 2018 Alan R. Hevner 40

 Service Categorization and Aggregation

September 13, 2018 Copyright © 2018 Alan R. Hevner 41

September 13, 2018 Copyright © 2018 Alan R. Hevner 42

September 13, 2018 Copyright © 2018 Alan R. Hevner 43

September 13, 2018 Copyright © 2018 Alan R. Hevner 44

September 13, 2018 Copyright © 2018 Alan R. Hevner 45

September 13, 2018 Copyright © 2018 Alan R. Hevner 46

September 13, 2018 Copyright © 2018 Alan R. Hevner 47

September 13, 2018 Copyright © 2018 Alan R. Hevner 48

September 13, 2018 Copyright © 2018 Alan R. Hevner 50

September 13, 2018 Copyright © 2018 Alan R. Hevner 51

 Most Popular Languages (2018)

September 13, 2018 Copyright © 2018 Alan R. Hevner 52

 You cannot test quality into a software system!!

September 13, 2018 Copyright © 2018 Alan R. Hevner 53

System Test Scripts

Software Design Test Scripts Subsystem Integration

September 13, 2018 Copyright © 2018 Alan R. Hevner 55

 Customer Acceptance Testing