Course Topics

1
Course Topics
2
Topic Objectives

• By the end of this topic, you should be able to
• Define systems design
• Identify its purpose
• Describe its context within a System Development
  Lifecycle (SDLC)
• List 4 different CWIS systems design scenarios
• Describe systems design activities, roles, and
  skills
• Identify risks to CWIS system quality in systems
  design phase

3
Topic Outline

• Systems design definition
• Purpose
• Context within an SDLC
• CWIS systems design scenarios
• Systems design activities, roles, and skills
• Risks to CWIS system quality in systems design
  phase

4
Purpose of Systems Design

• The system requirements define WHAT is to be
  produced
• The systems design describes HOW it will be
  produced

• Source http//www.tessella.com/literature/Supple
  ments/swdesign_UML.htm

5
Systems Design Definition

• Design is a meaningful engineering
  representation of something that is to be built
• Example representations from architecture
• Architectural blueprints
• Scale model
• Example representations from computer systems
• Screen layouts
• Prototype system

• Source Pressman, Roger S. http//www.rspa.com/s
  pi/design-engineering.htmldesignprinciples

6
Systems Design Definition, cont.
An effective systems design should be

• 1 - Traced to a
• customer's
• requirements

2 - Assessed for quality against a set of
predefined criteria for 'good' design.

• Source Pressman, Roger S. http//www.rspa.com/s
  pi/design-engineering.htmldesignprinciples

7
Systems Design Definition, cont.

• Design focuses on four major areas
• Architecture
• Functional Modules
• Interfaces
• Data

• Source Pressman, Roger S. http//www.rspa.com/s
  pi/design-engineering.htmldesignprinciples

8
CWIS Design Focus Areas

• Architecture
• Enterprise
• Systems
• Functional modules. Examples include
• Search
• Intake
• Investigation
• Case Management

9
CWIS Design Focus Areas, cont.

• Interfaces
• Three Federally required interfaces
• (bi-directional) for SACWIS systems
• Title IV-A (Temporary Assistance for Needy
  Families)
• Title IV-D (Child Support)
• Title XIX (Medicaid)
• State interfaces. Examples include
• State/county financial systems
• Courts

10
CWIS Design Focus Areas, cont.

• Data
• Federally required data
• Adoption and Foster Care Analysis Reporting
  System (AFCARS)
• National Child Abuse and Neglect Data System
  (NCANDS)
• Chafee National Youth in Transition Database
  (NYTD)
• State-required data. Examples include
• State-specific data elements
• Payment information
• Contract service providers

11
Topic Outline

• Systems design definition
• Purpose
• Context within an SDLC
• CWIS systems design scenarios
• Systems design activities, roles, and skills
• Risks to CWIS system quality in systems design
  phase

12

Systems Design Occurs within an SDLC
A Systems Development Lifecycle (SDLC) is a
framework for system development with defined
phases.
13
Systems Design Methodology in Traditional/Waterfa
ll SDLC
14
Topic Outline

• Systems design definition
• Purpose
• Context within an SDLC
• CWIS systems design scenarios
• Systems design activities, roles, and skills
• Risks to CWIS system quality in systems design
  phase

15
CWIS Systems Design Scenarios

• Scenario 1 New System Development
• Example Ohio SACWIS
• Scenario 2 System Redesign
• Legacy application
• Example State of Texas combined 12 different
  legacy systems
• SACWIS transfer systems
• See Example 2.1

16
CWIS Systems Design Scenarios, cont.

• Scenario 3 Enhancements (add new functionality)
• Scenario 4 Maintenance Requests (do not add new
  functionality)

17
Topic Outline

• Systems design definition
• Purpose
• Context within an SDLC
• CWIS systems design scenarios
• Systems design activities, roles, and skills
• Risks to CWIS system quality in systems design
  phase

18
Key Activities in Systems Design

• Validate requirements
• Develop product specifications
• Develop high level design
• Develop design documents
• Develop test plans
• Develop detailed design
• Code
• Perform test activities

19
A Word About Roles

• A role is a function a person plays in the
  completion of certain activities in the project
  plan
• A role is not a description of a person or a job
  title
• A single person may play several different roles
  throughout the project lifecycle

Source Virginia Department of Social Services.
Software Development Lifecycle Methodology (SDLM)
Reference Manual, Version 3.0.1. May 14, 2007.
20
CWIS Project Personnel Roles

• Functional/program
• CWIS project functional/program manager
• Child Welfare business analysts
• Technical
• CWIS project technical manager
• CWIS project systems designers
• CWIS security administrator
• Infrastructure team
• Network and server technicians, database
  administrator (DBA)

21
CWIS Project Personnel Roles, cont.

• Help or Service Desk
• Super Users
• Members of user community
• First level support to local users
• Trainers for new functionality
• Primary liaisons with State project team

22
A Closer Look At the Roles of

• Systems Designers
• Analyze, design and modify networks, computer
  systems, and websites1
• Business Analysts
• Gather business requirements from various areas
  in the organization and translate them into
  functional system design specifications that can
  be successfully executed by IT development teams2

• Sources
• http//targetjobs.co.uk/career-clueless/single-job
  -description.aspx?DescID1200
• George Brown College Information Systems Business
  Analyst program.
• http//www.georgebrown.ca/Marketing/FTCal/caet/T4
  05.aspx

23
Cross-Functional Skills Needed for These Roles

• Communication
• Presentation and writing skills
• Requirements elicitation
• Meeting facilitation
• Child Welfare program knowledge
• Child Welfare automated system operation and
  users

24
A Day in the Life of a CWIS

• Systems Designer
• Business Analyst

25
Topic Outline

• Systems design definition
• Purpose
• Context within an SDLC
• CWIS systems design scenarios
• Systems design activities, roles, and skills
• Risks to CWIS system quality in systems design
  phase

26
System Successes

• Numerous everyday activities are enhanced by
  effective systems design
• Online shopping and banking
• Tax return e-filing and refunds
• Smart phones
• Child Welfare caseworkers using mobile technology
  (PDAs, Tablet Pcs, Digital Pens)

27
System Failures

• Unfortunately, costly and highly publicized
  system failures have been traced to
  now-predictable causes, including ineffective
  systems design
• Many studies document these causes of failure and
  lessons learned
• Lack of clear communication is a persistent theme

Source Charette, Robert N. "Why Software
Fails." IEEE Spectrum Special Report. September
2005. http//www.spectrum.ieee.org/sep05/1685

28
System Failures, cont.

• Project objectives
• This study1 found that project objectives not
  fully specified was the leading cause of runaway
  projects at 51
• Poor and/or changing requirements
• The second leading cause of late projects2 was
  frequent changes in design/implementation
  (resulting from requirements changes) at 50

Sources 1 Cole, Andy. Runaway Projects
Cause and Effects. Software World (UK). 1995.
26(3), p. 3-5. 2 Van Genuchte, Michiel. Why
is Software Late? An Empirical Study of Reasons
For Delay in Software Development. IEEE Trans.
Software Eng. 17(6) 582-590 (1991)
29
System Failure Example

• Allstate set out in 1982 to automate all of its
  office operations. They set a 5-year timetable
  and an 8 million budget. Six years and 15
  million later, Allstate set a new deadline and
  readjusted its sights on a new budget of 100
  million. In 1993, the office automation system
  was abandoned after deployment, costing 130
  million.

Source The Long, Dismal History of Software
Project Failure. May 15, 2006.
http//www.codinghorror.com/blog/archives/000588.h
tml
30
Picturing the Challenges
1
2
3
How the customers described what they wanted
How the analysts understood it
How the designers designed it
Source The Project Cartoon.com Beta at
http//www.projectcartoon.com
31
Picturing the Challenges, cont.
4
5
6
How the project was documented
How change requests were applied
What the customers really needed
32
Risks to CWIS System Quality

• Which of the following do you perceive as risks
  to the quality of your State's CWIS system during
  the systems design phase? (Check all that apply.)

33
Systems Design Risks (from survey)

• Unclear, incomplete, or undocumented
  requirements
• Insufficient collaboration between key
  stakeholders
• Lack of good elicitation or facilitation skills
• Ineffective communication between functional and
  technical teams
• Lack of effective organizational change
  management processes
• No clear understanding of software quality or
  accessibility attributes 
• Inadequate design impact assessment and approval
  processes
• Lack of automated design tools
• Lack of collaboration tools
• Other (please describe)

34
Exercise

• Using the issues from the previous slides, or
  from your own experience
• Select your States Top 5 Issues that pose a
  risk to CWIS system quality during the systems
  design phase
• Share the results with a classmate
• Contribute your results to a full class
  discussion
• Time 20 minutes

35
Exercise Results

• Class List Top 5 Issues that pose a risk to
  CWIS system quality during the systems design
  phase
• 1.
• 2.
• 3.
• 4.
• 5.

36
Topic Summary

• Effective systems design should be
• Traced to a customer's requirements
• Assessed for quality against a set of predefined
  criteria for 'good' design
• CWIS systems design focuses on
• Architecture
• Functional Modules
• Interfaces
• Data

37
Topic Summary, cont.

• There are typically four CWIS systems design
  scenarios
• CWIS program/functional and technical team
  members play interdependent roles in the systems
  design process that require a combination of
  strong communication, business, and technical
  skills