SYSTEM DEVELOPMENT
CLASS OBJECTIVES
To understand and identify the
challenges of modern information
systems acquisition and management
To acquire skills and strategies for
becoming effective and efficient in all
phases of planning, and managing
application development
To directly experience the methods and
practice of systems analysis and design
from the MIS perspective
2
REVIEW: ASSIGNMENT #1 AND THIS
CLASS
3
WHAT SAD TOPICS ARE A PRIORITY?
We only have 1-semester to study SAD!
Too many topics, so must prioritize and focus on the
key areas.
How shall we determine this?
Ans: We will interview MIS professionals to help us
determine priorities, needed skills, and important
tools/techniques
4
ASSIGNMENT #1: SAD AND MIS
Task is to interview an “MIS professional” about
SAD topics. “What should a successful MIS
person know?”
 http://itmvm.shidler.hawaii.edu/itm353/asst1.htm
 Reports will be aggregated to develop a set of
topics we will focus on this semester!
 ** NOT MUCH TIME TO COMPLETE THIS **


Have you signed up an MIS professional ?
5
EXERCISE: PLANNING A WEDDING

3 months from now; 200 guests (20% from out of
state); $15,000 budget





What do you need to do?
Who does what?
How do you get started?
What are the tradeoffs?
How confident are you that you can succeed?
CHAPTER 1
Project Team Roles and Skills
7
THE TAR PIT
Developing large software systems is "sticky"
 Projects usually emerge from the tar pit with
running systems, but most missed goals,
schedules, and budgets
 "No one thing seems to cause the difficulty – any
particular paw can be pulled away. But the
accumulation of simultaneous and interacting
factors brings slower and slower motion"
 Analogy meant to convey that it is hard to
discern the nature of the problem(s) facing
software development

8
WHY ARE SOFTWARE PROJECTS LATE?
Estimating techniques are poorly developed
Our techniques confuse effort with progress
Since we are uncertain of our estimates, we don't
stick to them
Progress is poorly monitored
When slippage is recognized, we add people ("like
adding gasoline to a fire")
9
OPTIMISM
"All programmers are optimists"
"All will go well" with the project – thus we don't plan for
slippage
However, with the sequential nature of our tasks, the
chance is small that all will go well
10
THE MYTHICAL MAN-MONTH
Cost does indeed vary as the product of the number
of people and the number of months
Progress does not!!
11
MMM - 2

The unit of man-month implies that people and
months are interchangeable
This is only true when a task can be partitioned
among many workers with no communication among
them
 When a task is sequential, more effort has no effect
on the schedule – many tasks in software engineering
have sequential constraints

12
MMM - 3
Most tasks require communication among workers
Communication consists of
Training
Sharing information (intercommunication)
Training affects effort at worst linearly
Intercommunication adds n(n-1)/2 to effort – if each
worker must communicate with every other worker
13
DEVELOPMENT TEAM
How should the development team be arranged?
The problem: good programmers are much better
than poor programmers
Typically 10 times better in productivity
Typically 5 times better in terms of program elegance
14
THE DILEMMA OF TEAM SIZE
Consider a 200-person project with 25 experienced
managers
The previous slide argues for firing the 175 workers
and use the 25 managers as the team
15
THE DILBERT VIEW
TWO NEEDS TO BE RECONCILED
For efficiency and conceptual integrity a small team
is preferred
To tackle large systems considerable resources are
needed
Some solutions:
Harlan Mill's Surgical Team approach – one person
performs the work, all others perform support tasks
Pair programming
17
THE PROPOSED SURGICAL TEAM
Surgeon – chief
programmer
 Co-pilot – like surgeon
but less experienced
 Administrator –
relieves surgeon of
administrative tasks
 Editor – proof-reads
documentation

2 Secretaries –
support administrator
and editor
 Program clerk –
tracks versions
 Toolsmith – supports
work of the Surgeon
 Tester
 Language lawyer

18
HOW IS THIS DIFFERENT?
Normally, work is divided equally – now only the
surgeon and copilot divide the programming work
 Normally each person has equal say – now
surgeon is the absolute authority
 Note communication paths are reduced

Normally 10 people -> 45 paths
 Surgical Team -> at most 13 paths

19
HOW DOES THIS SCALE?
Reconsider the 200 person team – communication
paths -> 19,900!
Create 20 ten-person surgical teams
Now only 20 surgeons must work together – 20
people -> 190 paths, two orders of magnitude less
Key problem is ensuring conceptual integrity of the
design (integration issues)
20
WHY DID THE
TOWER OF BABEL
FAIL?
Communication (the lack
of it) made it impossible
to coordinate
How do you
communicate in large
project teams? – informal
(telephone, email),
meetings, workbook
21
WHY DID THE TOWER OF BABEL FAIL? - 2

Workbook
Structure placed on project's documentation
 Technical prose lives a long time, best to get it
structured formally from the beginning, also helps
with distribution of information

22
WHY DID THE TOWER OF BABEL FAIL? - 3.

Team Dynamics
Teams can (and sometimes do) fail
 You will need to do some actual work to make your
team successful!


Let’s learn about the “One Bad Apple” syndrome
23
PROGRAMMING PROJECT EXAMPLE ROLES

A project leader


An architect


provides the fundamental design for the program, ensures
that design is implemented, finds alternatives when things
don't work or time is a problem
A requirements satisfaction lead


schedules meetings, keeps track of progress, tracks
and reports risks, assigns specific tasks and makes sure
they get done (or finds alternatives), is the communication
hub for the team
clarifies project requirements, ensures that requirements
are met by providing test cases, inspections,
checklists, etc.
A test lead

performs tests, analyses results, reports on tests
24
PROGRAMMING PROJECT EXAMPLE ROLES
-2

A lead programmer


breaks apart programming tasks into parts that can
be naturally integrated later, estimates programming
effort for parts, works with project leader to assign
programming tasks, performs critical-path programming
tasks, ensures that parts meet quality and functionality
expectations
A quality lead

ensures that the program and related materials meet
quality expectations, reports on quality issues, performs
quality improvement (i.e. clean-up) as needed, in
particular, is responsible for ensuring code has adequate
documentation, sets and ensures that user interface meets
usability expectations, establishes acceptable level of defect
(e.g. "bugs") tolerance, presents plans for improving quality
and enforcement of plan
25
PROJECT TEAM SKILLS AND ROLES
Projects should consist of a variety of skilled
individuals in order for a system to be successful.
 Six major skill sets an analyst should have
include:







Technical
Business
Analytical
Interpersonal
Management
Ethical
26
INTRO TO THE SDLC
A “Simple” Process for Making Lunch
Slide 28
IS A SDLC REALLY NECESSARY?
You have 5 mins to write instructions on how to
make a peanut butter and jelly sandwich
GO!!!
IS A DEVELOPMENT PROCESS REALLY
NECESSARY?

How can you help ensure…










you will make the correct thing?
you will make the thing correctly?
you did not leave out something important?
you did not add something unnecessary?
you will stay on budget (e.g. time)?
you make efficient/effective use of your time?
you can plan your effort realistically?
you do not get derailed by problems?
you are getting the best possible outcome?
you enable changes and updates later?
THE PROJECT AND ITS LIFECYCLE

The project
Moves systematically through phases where each
phase has a standard set of outputs (deliverables)
 Each deliverable is an input to the next phase
 Through a process of gradual refinement this results
in actual information system

PROJECT PHASES

Planning (or Initiation)


Analysis


How will the system work?
Implementation


Who, what, when, where will the system be?
Design


Why build the system?
System delivery
Maintenance/evolution
PLANNING
Identifying business value
 Analyze feasibility
 Develop work plan
 Staff the project
 Control and direct project

ANALYSIS
Information gathering
 Process modeling
 Data modeling

DESIGN
Physical design
 Architectural design
 User Interface design
 Database and file design
 Program design

IMPLEMENTATION
Construction
 Installation
 Transition

PROCESSES AND DELIVERABLES
Process
Product
Planning
Project Plan
Analysis
System Proposal
Design
Implementation
Slide 37
System
Specification
New System and
Maintenance Plan
SDLC METHODOLOGIES


A development process implements the SDLC
There are many development processes






Risk is the main determiner as to what process to use
(or to use one at all)
There are only two basic approaches



Waterfall
Spiral
Agile methods
RAD
Structured (or “data flow” oriented)
OOAD
Each approach has it benefits and liabilities
Context of the problem decides (for most modern
systems OOAD is best)
 However it is often useful to mix approaches

OBJECT-ORIENTED ANALYSIS AND DESIGN
Attempts to balance emphasis on data and process
Often uses Unified Modeling Language (UML) for
diagramming
Use-case Driven
Architecture Centric
Iterative and Incremental
Example methodology:
RUP
Slide
39
AGILE APPROACH
http://agilemanifesto.org/
SELECTING A DEVELOPMENT
METHODOLOGY
http://software-quality.blogspot.com/2006/10/riskbased-selection-for-agile.html
 http://www.construx.com/File.ashx?cid=817
 Mostly based on risk considerations
