(powerpoint)

5-1

Course Topics

No. Topic1 Course Introduction

2 Setting the Stage for Effective Systems Design

3 Key Components of Effective Systems Design

4 Building Quality into Systems Design

5 Overview of Systems Design Management, Approaches, and Products

6 Automating Systems Design

7 Challenge Exercise

8 Conclusion

5-2

Topic Objectives

By the end of this topic, you should be able to:

Describe systems design management concerns

Describe the difference between Enterprise Architecture and Systems Architecture

Describe systems design considerations Describe systems design approaches Identify systems design artifacts

5-3

Topic Outline

Systems design management concerns Enterprise Architecture Systems Architecture Systems design considerations Systems design approaches Systems design deliverables

5-4

Why does it take so long? Why does it cost so much? Why does it have errors?

— Research shows that 60% to 80% of system errors are present in the design before coding begins

Why doesn’t it meet my needs?— “That’s what I said, but that’s not what I meant.”

Management Concerns

Source: Center for Business and Technology. Overland Park, Kansas, 2006.http://www.centerforbusiness.org

http://www.centerforbusiness.org/

Possible Reasons

Miscommunication— Developers do not understand what is needed— Users are not really sure of what they want— Users have erroneous expectations

Unrealistic schedules— Poor or optimistic estimation

5-5

5-6

Possible Reasons, cont.

Recruiting staff with appropriate skills Access to experienced staff when needed Inadequate participation by experienced end

users Inadequate design processes Lack of appropriate design tools Funding reduced or reallocated Change in priorities

Common Threads

Common threads throughout any project— Risk management— Change control— Managing user expectations— Communications

5-7

Risk Management: Risk Types

5-8

Project — Unclear system requirements— Budget— Schedule— Adequate staffing— Team turnover— Team skill level

Technical — Change in technologies— State/Department technical constraints

Risk Management: Types, cont.

Business — Right decision makers— Lack of management commitment— Change in management personnel— Change in management business strategy— Change in policy— Lack of user commitment

5-9

Risk Management: Methodology

Risk management is a systematic process of "identifying, analyzing and responding to project risk" and then taking steps necessary to reduce the risk to an acceptable level.

5-10

Source: Project Management Institute (PMI) PMBOK® Guide. www.pmi.org

http://www.pmi.org/

Risk Management: Why

Increases the probability of project success Prevents surprises Assists in meeting deadlines Controls costs

5-11

Risk Management: Processes

Risk identification Risk assessment Risk evaluation Mitigation planning Risk control Risk reporting

5-12

Risk Management: More Info

Risk Management for Child Welfare Information Systems - Online Training Course

See References/Reading List for more information

5-13

On-line Courses. http://www.state-itc.org/cw_resources.html

Reading List: “Making Smart IT Choices: Understanding Value and Risk in Government IT Investments.” University at Albany, State University of New York, Center for Technology in Government. Sharon S. Dawes, Theresa A. Pardo, Stephanie Simon, Anthony M. Cresswell, Mark F. LaVigne, David F. Andersen, and Peter A. Bloniarz. April, 2004. http://www.ctg.albany.edu/publications/guides/smartit2

http://www.state-itc.org/cw_resources.html

http://www.ctg.albany.edu/publications/guides/smartit2

Change Control: Processes

Identify change Control change Change is properly implemented Report changes to others

5-14

Managing User Expectations

Under Promise and Over Deliver See References/Reading List for more

information

5-15

Reading List: “Managing User Expectations.” Michael Leicht and Dr.Vicki Sauter, University of Missouri at St. Louis. November 29, 1999. http://www.umsl.edu/~sauterv/analysis/user_expectations.html

http://www.umsl.edu/~sauterv/analysis/user_expectations.html

Communications

Communicate, communicate, communicate— Issues— Risks— Budget— Schedule

Who— Project Sponsor, Steering Committees,

Commissioner

5-16

Relationships

Regardless of the type of project, IT or otherwise, relationships with the project team and stakeholders can make or break the possibilities for success

5-17

Topic Outline

5-18


Enterprise Architecture: Definition

Current and future structure and behavior of an organization’s processes, information systems and personnel are aligned with the organization’s goals and strategic direction

5-19

Source: Wikipedia – Enterprise Architecture. http://en.wikipedia.org/wiki/Enterprise_architecture

http://en.wikipedia.org/wiki/Enterprise_architecture

Enterprise Architecture: Components

E

5-20

BusinessArchitecture

TechnologyArchitecture

InformationTechnology

Strategies

Goals

Processes

Personnel

Applications

Interfaces

Hardware

Networks

Security

DATA

Conceptual

Logical

Physical

Enterprise Architecture, cont.

Enterprise Architecture includes the explicit relationship among these components:— Business strategies— Business processes— Organization charts— System and interface diagrams— Technical inventories— Network topologies

5-21

Enterprise Architecture, cont.

Advantages— Reusability— Efficiency— Consistency1

Examples— Web Standards, Policies and Guidelines— Access to a central database

— CIOs are looking to standardize on one integrated platform for information management2

5-22

Sources:1 Daniel, Diann. The Rising Importance of the Enterprise Architect. CIO. March 31, 2007.

http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect2 CIO2CIO Reports. Information Management. http://www.cio2cioreports.com/

http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect

http://www.cio2cioreports.com/

Enterprise Architecture Example

5-23

Enterprise Architecture Example, cont.

5-24

Enterprise Architecture Example, cont.

Example 5.1, Commonwealth of VA Enterprise Architecture

5-25

Example 5.1

Enterprise Architecture Framework

Frameworks are commonly used to organize enterprise architecture into different views— Example 5.2, Architectural Frameworks

Examples

5-26

Example 5.2

Enterprise Architecture Framework, cont.

More Information— “Concepts of Framework for Enterprise

Architecture: Background, Description and Utility,” by John Zachman

5-27

Source: Zachman, John A. “Concepts of Framework for Enterprise Architecture: Background, Description, and Utility.” © 1993-1997. http://apps.adcom.uci.edu/EnterpriseArch/Zachman/zachman3_files/zachman3.htm

http://apps.adcom.uci.edu/EnterpriseArch/Zachman/zachman3_files/zachman3.htm

Service-Oriented Architecture (SOA)

What is SOA?— A collection of services— More technically, an application architecture in which

functions are exposed as independent services What is a business service?

— A single-purpose business function that is translated to technology which is reusable and accessible by any application on any platform with the appropriate permissions

5-28

Service-Oriented Architecture Example: Common Client ID

BEFORE

AFTER

5-29

Child Support Child Welfare TANF

Client ID

Child Support Child Welfare TANF

Common Client ID Service

Client IDClient ID

Service-Oriented Architecture, cont.

SOA is not— A formal methodology for service description — Dependent on any development language— Dependent on web-services technology1

It is one possible tool at an enterprise architect’s disposal2

Sources:1 District of Columbia Case Study in Service-Oriented Architecturehttp://www.state-itc.org/ntc2007/accessible/NTC2007-BELL_BIRDSONG-DELOITTE_DC/800x600/slide1.html2 Daniel, Diann. The Rising Importance of the Enterprise Architect. CIO. March 31, 2007.

http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect5-30

http://www.state-itc.org/ntc2007/accessible/NTC2007-BELL_BIRDSONG-DELOITTE_DC/800x600/slide1.html

http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect

Service-Oriented Architecture, cont.

More Information— SOA Overview and Guide to SOA Research1

— Twelve Common SOA Mistakes and How to Avoid Them2

Sources: 1 Abrams, Charles, and Shulte, Roy W. 3 January 2008. Gartner Research. www.gartner.com[Registration required. Summary available at no charge. Full document requires subscription.]2 Natis, Yefim V. and Pessini, Massimo. 26 October 2007. Gartner Research. www.gartner.com[Registration required. Summary available at no charge. Full document requires subscription.]

5-31

http://www.gartner.com/

http://www.gartner.com/

Topic Outline

5-32


Systems Architecture: Definition

An architectural model whose primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system

5-33

Source: http://en.wikipedia.org/wiki/Software_Architectural_Model

http://en.wikipedia.org/wiki/Software_Architectural_Model

5-34

Systems Architecture: Models

Architecture model Component-level model User interface model

Architecture Model

Organization of programs (modules, objects)

How programs interact Structure of data used by the programs Development Model

5-35

Software Component Definitions

A software component is a self-contained building block that encapsulates both data and processing that is applied to the data

A nearly independent and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture

5-36

Source: Brown, A. W. and K. C. Wallnan. Engineering of Component-Based Systems. Proceedings of the 2nd IEEE International Conference on Engineering of Complex Computer Systems (ICECCS '96) .

Component-Level Model

Functionally independent Re-useable (stored in a Library)

— Screen presentation, Navigation— Menu bars— Help— Printing— Audit trails— Security access levels: who, how— Single Sign on

5-37

User Interface Model

User Interface— The design of interfaces between software

components External interface to other systems Design of the interface between a human

and the computer

5-38

Systems Architecture, cont.

IEEE 1016 Systems Architecture document— Introduction

— Design overview — Requirements traceability matrix

— Systems Architectural Design — Chosen systems architecture — Discussion of alternative designs — System interface description

5-39

Source: IEEE 1016-1998, also known as the 1016 Standard for Software Design Description, is an IEEE standard that specifies the form of the document used to specify systems architecture and application design in a software related project. http://www.ieee.org

http://www.ieee.org/

Systems Architecture, cont.

— Detailed Description of Components— Component n — Component n+1

— User Interface Design— Description of the user interface

— Screen image — Objects and actions

5-40

Topic Outline

5-41


5-42

Systems Design Considerations

Meet the needs and provide value to the customer

Design should be traceable to the requirements

Always consider the architecture of the system

Design should always begin with the data

Data

Goal of the organization is to enable the business to use information effectively

Data design is an essential element of architectural design— Helps to simplify program flow— Makes design and implementation of

components easier— Makes processing more efficient

5-43

Systems Design Considerations, cont.

Use solid requirements— Clear, complete, detailed, attainable, testable

Plan realistic schedules— Adequate time for planning, design, testing, bug

fixes, retesting, changes and documentation Stick to initial requirements to the extent

possible— Defend against excessive change requests

5-44


Establish and require frequent communications in multiple formats— Formal inspections— Walkthroughs— Accessible documentation— Meeting minutes

— Fully document decisions— Demos

5-45


Collaboration— Joint Application Development (JAD)

— Representative cross-section of users— Consensus list

— Objectives— Services/Functions— Constraints— Performance criteria

— Use cases— How the system will be used— Use cases drive analysis and modeling activities

5-46


Prototyping— Higher acceptance level from the client— Client becomes familiar with the solution— Client involvement from the very start— Minimizes changes downstream

— Example 5.3, UC22 – Client Demographics storyboard excerpt (VA)

5-47

Example5.3

Source: http://www.ganthead.com

http://www.ganthead.com/


ISO/IEC 9126-1 Quality Attributes— Functionality— Reliability— Efficiency— Maintainability— Portability— Usability

— Accessibility

5-48

Topic Outline

5-49


In 1970, less than 1 percent of the public could define what computer software meant

1980s and early 1990s—Wide variety of object-oriented analysis (OOA) and design

(OOD) methods

— Source: Pressman, Roger, Software Engineering, sixth edition

5-50

Brief History

Brief History, cont.

1996 – Abundance of modeling languages was slowing down the adoption of object technology— Under the leadership of the “three amigos” Grady

Booch, James Rumbaugh, Ivar Jocobson — International consortium called the UML Partners was

organized— Combined the best object-oriented features

— “Unified Method”— Resulted in a “Unified Modeling Language (UML)”

— Robust notation for modeling and development of OO Systems

5-51

Brief History, cont.

1997 - UML 1.1 was adopted in November UML is now an international standard1

UML 2.0 adopted in October 20042

5-52

Sources:1 ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling

Language (UML) Version 1.4.22 http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Unified_Modeling_Language

UML Modeling

Ability to model all elements of a computer-based system

5-53

UML Modeling

5-54

Diagrams

StructureDiagrams

Behavior Diagrams

Class Diagram

ComponentDiagram

ObjectDiagram

CompositeDiagram

DeploymentDiagram

PackageDiagram

ActivityDiagram

Use CaseDiagram

StateDiagram

InteractionDiagrams

SequenceDiagram

InteractionOverviewDiagram

CommunicationDiagram

TimingDiagram

UML Modeling, cont.

Structure diagrams— Emphasize what things must be in the system

Behavior diagrams— Emphasize what must happen in the system

Interaction diagrams— Emphasize the flow of control and data among

the things in the system

5-55

UML Modeling, cont.

Content— Content to be provided by the application

Functional— What actions to apply to the content

Interaction— How the user interacts with the application

Configuration— Infrastructure where the application resides

5-56

System Design Approaches, cont.

Traditional Waterfall Incremental Iterative Rapid Application Development (RAD) Spiral Agile Unified (UP) Hybrid

“Our profession goes through methodologies like a 14-year-old goes through clothing.”

Stepen Hawrysh and Jim Ruprecht

5-57

5-58

Traditional Waterfall Model

Analysis

SystemsDesign

Code

Test

Implementation

MaintenanceRequirements

Waterfall, cont.

Sequential flow Approval at each phase completion Product delivered at the end Rework requires going back to the

beginning

5-59

Waterfall, cont.

Advantages— Deliverable at the end of each phase— Each phase can be estimated

Disadvantages— Projects rarely follow the sequential flow— Working version will not be available until the

end of the project— Changes may require substantial rework

5-60

Terminology Cross Walk

5-61

Communication project initiation requirements

Analysis

SystemsDesign

Code

Test

Implementation

MaintenanceRequirements

Planning estimating scheduling tracking

Modeling analysis design Develop

code test

Deploy delivery support feedback

Incremental

Increment # 1

Increment #2

Increment # n

5-62

ComPlan

ModelDevelop

Deploy

ComPlan

ModelDevelop

Deploy

Com- CommunicationPlan-PlanningModel-ModelingDevelop-ConstructionDeploy-Implement

Incremental, cont.

Waterfall model applied in an iterative fashion

Combines elements of the waterfall model with approvals

First increment contains basic requirements Second increment starts prior to first

increment deployment

5-63

Incremental, cont.

Advantages— Delivers an operational product— Next increment builds on the first

Disadvantages— Requires several increments to deliver a

complete system

5-64

Iterative

5-65

Quick Plan

ModelingQuick Design

Develop Prototype

DeploymentDeliveryFeedback

Communication

Start

Iterative, cont.

General requirements Quick design leads to a prototype Customer sees a working version It is meant to help define requirements It is NOT meant to be a deployable solution

— Example 5.4, Iterative Flow Diagram (VA)

5-66

Example5.4

Iterative, cont.

Advantages— Good way to refine objectives when

requirements are fuzzy Disadvantages

— User sees what appears to be a robust working system

— Developers may be forced to implement a prototype

5-67

Rapid Application Development (RAD)

Multiple Teams

5-68

Com Plan

Model

Develop

Model

Develop

ModelDevelop

Deploy


Rapid Application Development, cont.

High speed adaptation of the waterfall model Requirements are well understood Project scope is limited Project data

— Data already exists Project team

— Team is small (probably ten or less)

5-69


Project Technical Architecture— Technical Architecture is defined and the key

components are in place Project technical requirements

— Technical requirements are reasonable and within the current capabilities of the technology

Project decisions— Decisions can be made by a small number of people

5-70


Requires multiple RAD teams working in parallel

Fully functioning system within 60-90 days

5-71


Advantages— Can deliver an application in a short time

Disadvantages— Each module needs to be completed on time— Potential communications issues among teams— Teams need to be committed to rapid-fire

activities

5-72

SpiralSeries of Releases

5-73

Com

Plan

Model

Develop

Deploy


Start

Spiral, cont.

Couples iterative prototyping with controlled aspects of waterfall

Series of releases Each release expands in complexity Each release has a set of work products Budget and time frames revisited with each

release

5-74

Spiral, cont.

Advantages— Rapid deployment of increasingly more

complete versions of the software reduces risk— Set of anchor or control points

Disadvantages— When will the entire system be completed?

5-75

Agile

Built on the foundations of Iterative Rapid incremental delivery of software Informal methods Minimal work products Active and continuous communications

between developers and customers Processes user feedback rather than planning

as the primary control mechanism

5-76

Source: Wikipedia. Software Development Process.

Agile, cont.

Must collaborate – face to face Team must have decision-making authority Must be adaptable to constant change Most bang for the buck

— Won’t say exactly when the bang will be— Won’t say how big a buck will be required

5-77

Source: Wikipedia. Software Development Process.

Agile Process Models

Agile process models include:— Extreme Programming (XP)

— Object-oriented software— Driven by user stories (features and functions)— Pair Programming— Prototype

5-78

Sources:1 www.extremeprogramming.org2 www.extremeprogramming.com

http://www.extremeprogramming.org/

http://www.extremeprogramming.com/

Agile Process Models, cont.

— Adaptive Software Development1

— Project initiation sets release cycles— Joint Application Design (JAD) sessions— Focus groups for feedback— Adjustments for subsequent cycles

— Scrum2

— Small working groups— Frequent software increments (30 days)— Daily status meetings (15 minutes)

5-79

Sources:1 www.adaptivesd.com2 www.controlchaos.com

http://www.adaptivesd.com/

http://www.controlchaos.com/

Agile Process Models - Others

Additional Agile process models references— Example 5.5, Additional Agile Models

5-80

Example5.5

Agile Process Models, cont.

5-81

Agile, cont.

Advantages— Adaptability to rapidly changing project and

technical conditions— Incremental software releases— Allows for user feedback

Disadvantages— Minimum documentation— Constant changes - when does it get done?

5-82

Unified Process Terminology Cross Walk

5-83

Plan

Model

DevelopDeploy

Com

InceptionElaboration

Transition

Release


Construction

Start

Unified Process

5-84Source: Rational Unified Process White paper. http://medlem.spray.se/perlin27/rup.htm

http://medlem.spray.se/perlin27/rup.htm

Unified Process, cont.

Inception— User collaboration— Business requirements defined— Initial Use Case (10-20% complete)

Elaboration— Refined and expanded use case (80% complete)— Modeling

5-85


Construction— Code generation— System testing— User manuals

Transition — User testing— Operation manual— Data conversion— Training

5-86


Best principles of Agile Software Development

Use case-driven Iterative and Incremental Unified Modeling Language (UML)

5-87


Advantages— Creates and maintains models— Customer view of a system (use case)— Iterative and Incremental

Disadvantages— Heavy reliance on modeling (UML)

— Configuration management— Keeping models updated

5-88

Hybrids

State of Virginia — Waterfall through Design— Iterative with a 22-day approval cycle

— Example 5.6, ChildWINS 22-day review (VA)

5-89

Example5.6

Topic Outline

5-90


Use Case

Business use case— Captures who (actor) does what (interaction) with

the system, for what purpose (goal), without dealing with internal system information

— Describes the What A complete set of use cases

— Specifies all the different ways to use the system— Defines all behavior required of the system without

specifying how the system does it

5-91

Use Case, cont.

Business use case example— Actor enters client ID to search for client record

information — System accepts request and determines if client

exists— Example 5.7, UC22 - Client Demographics Use

Case (VA)

5-92

Example5.7

Requirements Traceability

Before executable code is created, the system requirements and design must be verified

Verification includes— Walkthroughs and inspections of requirements

documents, analysis documents, and design documents

5-93

Requirements Traceability, cont.

Reduces the risk of requirements errors by— Assisting with clarifying requirements— Determining impact of proposed system

changes

5-94


A proven engineering technique that links system requirements— Backward to their sources (e.g., stakeholders,

federal and State laws and regulations)— Forward to the resulting system development

work products— Example 5.8, UC22 - Traceability Matrix excerpt (VA)

5-95

Example5.8


The most effective testing is driven by the business rules and requirements since you want to know whether the system does what it is intended to do for the business

Use cases are the logical place to start— If you do not follow a use case format for

requirements, start with individual, specific requirements

5-96

Systems Design Deliverables

Every business use case and system use case should have corresponding test cases and scripts that test the system’s functionality and verify that the requirements are met

5-97

Systems Design Deliverables, cont.

5-98

Architecture— Overall system structure/framework

— How to handle user interaction— How to handle internal processing tasks

— Data flow model/diagrams— Entity-Relationship Diagram

— Data objects and their relationships— Logical Data Model— Physical Data Model— Data Conversion Plan


Component-level— Detailed processing logic — Component diagrams

— Detailed set of specifications for each module— Example 5.9, CAPS Design Document (TX)

— Sequence Diagrams— How events cause transitions from object to object

5-99

Example5.9


— Activity Diagrams— Flow of interaction

— Example 5.7, UC22-Client Demographics Use Case (VA) - Page 7 of 8

— Design classes— Example 5.10, Domain Model (VA)— Example 5.11, Design Class Document (VA)

5-100

Examples 5.7, 5.10 & 5.11


Interface— Technical Interface Design

— Example 5.12, DFPS Interfaces (TX)— Example 5.13, IMPACT Central Registry (TX)— Example 5.14, IMPACT Interfaces (TX)— Example 5.15, IMPACT DARS ECI Interface (TX)— Screen designs/user interface model

— Look and feel— How the end user navigates— Color schemes, text size, font, placement— Report layouts

5-101

Examples 5.12, 5.13, 5.14, 5.15


Other considerations— Security Plan/impacts— Hardware capacity planning— Network impact planning— Bandwidth

5-102

5-103

Exercise

Using the Design Approaches from the previous slides, or from your own experience:1. Describe your State/county’s approach (or

approaches) to design.2. What do you like or dislike about each

approach? Why?3. Contribute your results to a full class

discussion.Time: 20 minutes

5-104

Exercise Results

Class List: States’ Approaches to Systems Design1.2.3.4.5.

Topic Summary

Project failures are a result of unclear requirements and/or excessive changes

Common threads throughout a project are risk management, change control, managing user expectations and communications

5-105

Topic Summary, cont.

Regardless of the type of project, IT or otherwise, relationships with the project team and stakeholders can make or break the possibilities for success

Design starts with Enterprise Architecture - the relationship between the business, technology and information

5-106

Topic Summary, cont.

Systems Architecture illustrates potential tradeoffs in systems design

In designing a system, collaborate, collaborate, collaborate

There is no right or wrong design approach. Pick one that works for you.

5-107

(powerpoint)

Business

managing user

software development

enterprise

enterprise

oriented architecture

registration

client demographics

rising importance