Software Project Management

lumpysteerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

84 εμφανίσεις

INFO 503

Lecture #2

1

Introduction to Information

Systems Analysis

Information Systems Development

Fact Finding Techniques


INFO 503

Glenn Booker

INFO 503

Lecture #2

2

System Development Life Cycle


A System Development Life Cycle is the
process used for developing a system


A life cycle is a management tool for
planning, conducting, and controlling

an activity


Software and System life cycles are similar,
differing in the details of each activity

INFO 503

Lecture #2

3

Methodology


A methodology, such as FAST, implements
a life cycle by defining activities


Each activity has roles and responsibilities,
creates work products, and uses tools

and techniques


Major recurring theme in the text


Methodology should cover entire life cycle

INFO 503

Lecture #2

4

Capability Maturity Model


Level 1 =
Initial

chaos


no

consistent processes


Level 2 =
Repeatable

processes for a project


Level 3 =
Defined

processes across

an organization


Level 4 = Quantitatively
Managed

projects


Level 5 = Processes
Optimized

continuously

INFO 503

Lecture #2

5

Groundwork


Any system development should first define
its general scope


What kind of product will be created?


What order of magnitude for time frame and
number of resources are available for this
effort? (e.g. week, month, year, or $10k, $1M)


What is the current state of similar products?


What will make this product special?

INFO 503

Lecture #2

6

Ten Principles of System
Development

1.
Get the system users involved

2.
Use a problem
-
solving approach

3.
Establish phases and activities

4.
Document throughout Development

5.
Establish standards

6.
Manage the Process and Projects

7.
Justify systems as capital investments

8.
Don’t be afraid to cancel or revise scope

9.
Divide and conquer

10.
Design systems for growth and change

INFO 503

Lecture #2

7

1. Get the System Users Involved


Encourage owners, users, and developers to
work cooperatively and collaborate


Get everyone involved in defining
requirements and discussing changes


Document decisions well


Education of owners and users can help
overcome biases and fears

INFO 503

Lecture #2

8

2. Use a Problem
-
Solving
Approach


The methodology (life cycle) is an approach


Study the problem and its context


Define the requirements of a solution


Identify possible solutions and pick one


Design and implement the solution


Observe the solution’s impact, and refine it


Don’t skip steps!

INFO 503

Lecture #2

9

3. Establish Phases and Activities


Major FAST phases are:


Scope Definition (led by system owners)


Problem and Requirements Analysis (users)


Logical Design and Decision

Analysis (designers)


Physical Design and Integration (builders)


Construction and Testing


Installation and Delivery

p. 89 (75)

INFO 503

Lecture #2

10

3. Establish Phases and Activities


Higher levels are business
-
driven; lower are
technology
-
driven


Each phase is broken down into activities
and tasks to make them manageable


Development is often iterative, with
frequent back
-
tracking to refine
requirements and the design


Be sure not to get stuck in iteration!

INFO 503

Lecture #2

11

4. Document throughout Development


In order for large projects to succeed,
programs need to be documented and
agreed upon
before

they’re developed


Necessary for coordination across
stakeholders, and to leave a comprehensible
legacy for maintenance

INFO 503

Lecture #2

12

5. Establish Standards


Standards should be used for both creation
of the information system itself, and for the
processes used to create the system


Records assumptions and measure progress


May include document style standards, file
and variable naming conventions, and file
organization conventions…

INFO 503

Lecture #2

13

5. Establish Standards


System development standards may
describe, for every phase of the life cycle:


Activities (what happened?)


Responsibilities (who did it and why?)


Documentation requirements (tailor from
corporate standard templates)


Quality checks (peer review, defect prevention)

INFO 503

Lecture #2

14

6. Manage the Process and Projects


Deliberate process and project management
ensures that your organization 1) has
defined processes, and 2) they are actually
used, and 3) you can determine how to
improve them


Benefits not only this program, but others

in the future too


INFO 503

Lecture #2

15

7. Justify Systems as

Capital Investments


Information systems often outlive many
projects, hence are capital investments


Make sure alternatives are well investigated
(do you buy the first house you see?)


Analyze the cost
-
effectiveness of all major
alternatives, including both development
and operational costs


Manage risks during development

INFO 503

Lecture #2

16

8. Don’t be afraid to

Cancel or Revise Scope


The iterative nature of development makes
it tempting to implement a not
-
good system


Feature and schedule creep can sneak

up quietly, one good decision after another


Avoid getting stuck by choosing
creeping
commitment

points during development


At each, consider cancellation, projected
system cost, schedule, and feature scope

INFO 503

Lecture #2

17

9. Divide and Conquer


Every system is part of a larger system
(supersystem) and most contain smaller
systems (subsystems)


Interaction with supersystem can change
requirements during system development


Defining subsystems can help make project
design more manageable

INFO 503

Lecture #2

18

10. Design Systems for

Growth and Change


Business needs change over time


During system maintenance (support),
maintenance cost grows as the system
requirements evolve and hardware wears
out; system becomes obsolete


Hence need to design systems so that they
can be replaced some day

INFO 503

Lecture #2

19

FAST Methodology


An information system project starts when:


Problems

keep your organization from reaching
its business goals or objectives


Opportunities

arise when a new capability is
identified (e.g. new features)


Directives

from outside your organization
mandate new features or requirements

(e.g. laws, regulations)

INFO 503

Lecture #2

20

PIECES Review Criteria

Assess new projects for their:


P
erformance improvement potential


I
nformation or data improvement


E
conomic or cost improvement


C
ontrol or security improvement


E
fficiency improvement (people or process)


S
ervice to customer, supplier, staff, etc.

INFO 503

Lecture #2

21

FAST Phases

1.
Scope Definition
[in 4
th

Ed.: Survey Phase]

(system owner)

2.
Problem Analysis
[Study Phase]

(analyst)

3.
Requirements Analysis
[Definition

Phase]

(analyst)

4.
Logical Design
[not separate in 4
th

Ed.]

5.
Decision Analysis
[Configuration

Phase]

(designer)

p. 96 (83)

key overview

INFO 503

Lecture #2

22

FAST Phases


Procurement Phase
[Version 4 separate only;
or blend into other phases]
(designer)

6.
Physical Design & Integration
[Design
Phase]

(designer)

7.
Construction & Testing
[Construction

Phase]

(builder)

8.
Installation & Delivery
[Delivery Phase]

(builder)

INFO 503

Lecture #2

23

1. Scope Definition


This is a sanity check to see if the project

is worth looking at


If so, define the project team, budget,

and schedule (very rough)


Involves sponsors and managers, plus

user involvement


Deliver a feasibility study and project plan

INFO 503

Lecture #2

24

2. Problem Analysis


Study existing system (automated or not)
for problems and opportunities


Is the new & improved system

worth having?


Run by system analyst, with user and

owner involvement


Define system objectives, and success
criteria for new system

INFO 503

Lecture #2

25

3. Requirements Analysis


Now define and prioritize detailed system
and business requirements


Consider also what it does NOT do


Do NOT describe HOW it does anything


System analyst and many users do this


Create models of data, process, interface,
and geography perspectives…

INFO 503

Lecture #2

26

3. Requirements Analysis


Might use prototyping to

verify requirements


Present requirements and models in a
requirements statement


“Time boxing” is placing requirements

into staged deliveries for implementation
(hence start to think of priorities)

INFO 503

Lecture #2

27

4. Logical Design


The logical design phase is when various
models are developed to describe the logical
functions of the system


This typically includes data, process, and/or
object models


Beware of getting stuck in
analysis paralysis


INFO 503

Lecture #2

28

5. Decision Analysis


Identify candidate solutions, analyze them,
and recommend the best one


Done by system analyst, with support from
all others, and maybe consultants


May start before requirements are done


May include make
-
or
-
buy decisions, and
define an application architecture…

INFO 503

Lecture #2

29

5. Decision Analysis


Evaluate each solution for technical,
operational, economic, and

schedule feasibility


Produce a system proposal for

owners’ approval


Often includes procurement phase for

off
-
the
-
shelf applications

INFO 503

Lecture #2

30

Procurement Phase


Major system components are often
acquired, not built from scratch


See COTS tool reports (Commercial
-
Off
-
The
-
Shelf software) by the SEI, STSC


Vendors “help” system analyst and users


Study existing market & future trends, then
generate a RFP or RFI (see References)…

INFO 503

Lecture #2

31

Procurement Phase


Evaluate vendors’ proposals; pick the

one that meets requirements and is most
cost effective


Negotiate contractual and licensing needs to
obtain products, installation, training, etc.

INFO 503

Lecture #2

32

6. Physical Design & Integration


Turn requirements into plans for the
builders, iteratively, until plans are
complete (Rapid Application Development)


Analyst and specialists involved


Database, program, human and system
interfaces are all designed using

iterative prototyping…

INFO 503

Lecture #2

33

6. Physical Design & Integration


Iterate:


Define base system


Define database, load with data, and review
with users


Define inputs, and review with users


Define outputs, and review with users


Define interfaces, and review with users


Define other controls, and implement. Repeat.

INFO 503

Lecture #2

34

7. Construction & Testing


Now build the real system and its interfaces


System builders lead the team


Design specifications are main input


Write code, then conduct unit test, and
system test


May deliver system in stages

INFO 503

Lecture #2

35

8. Installation & Delivery


Install new system and place it

into operation


May include data conversion and loading to
initialize system, and training of end users


Users provide feedback (problem reports) to
identify initial support issues


INFO 503

Lecture #2

36

System Operation and Maintenance


While system is in use:


Assist users (help desk)


Fix bugs


Recover system after failures


Adapt to new requirements

(implement new features)

INFO 503

Lecture #2

37

Cross Life Cycle Activities


These may overlap many (or all) other
phases of development


Fact
-
finding


Help collect information about systems,
requirements, and user preferences;


Most important early in life cycle

INFO 503

Lecture #2

38

Cross Life Cycle Activities


Documentation is generated to record

the work accomplished so far, and plan
future activities


Presentations are a formal packaging, in
writing or orally, of some documentation


“Dog and pony shows” are presentations

made to upper management or sponsors

INFO 503

Lecture #2

39

Cross Life Cycle Activities


Estimation and measurement are performed
throughout the life cycle (see INFO 630)


Estimation is to predict the amount of time,
effort, cost, and benefits of some activity within
system development


Measurement is to determine the actual amount
of what was estimated


“Earned value” is one way of comparing them

INFO 503

Lecture #2

40

Cross Life Cycle Activities


Feasibility analysis is performed early in a
project to determine its potential benefits


Recall mention of technical, operational,
economic, and schedule feasibility


Project management is the deliberate
planning and control of a project to achieve
the desired goal (creation of a product)

INFO 503

Lecture #2

41

Cross Life Cycle Activities


Process management is the conscious
definition and management of the processes
used to conduct a project, using standards to
define typical work products (deliverables)


Data and documents from all phases should
be stored, such as in a repository

INFO 503

Lecture #2

42

Methodology Options


Systems can be build from scratch,
purchased off
-
the
-
shelf, or some of both


Methodologies can be very rigid
(prescriptive), or flexible (adaptive)


Methodologies can be model
-
driven (draw
pictures first, e.g. FAST) or product
-
driven
(build something and see if it works)

p. 108 (n/a)

INFO 503

Lecture #2

43

Model
-
Driven Development


Most methods for analysis and design focus
on using models to capture thoughts


Structured analysis focuses on processes, such
as the data flow diagram


Information engineering focuses on data, such
as the entity relationship diagram


Object oriented analysis and design blend data
and process into objects

INFO 503

Lecture #2

44

RAD and COTS


Rapid Application Development (RAD)
focuses on iterative development of
prototypes with lots of user input


Often uses time boxing to limit the effort on
each iteration


Commercial Off The Shelf (COTS)
products can be used as the entire system,

or significant portions of a developed one

INFO 503

Lecture #2

45

CASE Tools


Computer Assisted Software Engineering

(or Systems Engineering) tools use an
information system (customized database)
which is devoted to managing a system
development effort


CASE tools may include compilers, design
and diagram tools, quality and document
management tools, and generate code

INFO 503

Lecture #2

46

CASE Tools


Upper CASE Tools focus on early
development activities


requirements and
high level design phases; may also be able
to reverse engineer code


Lower CASE Tools focus on (you guessed
it!) later development activities


detailed
design, construction (coding),
implementation, and perhaps support

INFO 503

Lecture #2

47

CASE and ADE Tools


CASE Tools are noted for pretty graphical
capabilities
-

diagrams, flow charts, etc.


They store projects in repositories


Price is high in both $$$ and learning curve


Compilers have evolved into Application
(or Integrated) Development Environments
(ADE or IDE)


may include debuggers and
interface tools, testing and version control

INFO 503

Lecture #2

48

Fact Finding and Information
Gathering


Fact finding is the formal process of

using various techniques to collect
information about system requirements

and user preferences


Facts are the basis for modeling


Conclusions about the system are also
drawn from these facts


So facts are, like, really important :)

INFO 503

Lecture #2

49

Fact Finding and Information
Gathering


Fact finding is most important during the
planning and analysis phases, but still

useful during the rest of the life cycle


Seven techniques to choose from; often

use several on any given project


Fact finding may also discover business
rules


how does the system need to
respond under different conditions?

INFO 503

Lecture #2

50

Requirements


Fact finding may give info at various levels
of detail, depending on the audience


Requirements

capture what and/or how the
system needs to be able to support its users


A requirement is more precise than a user
need
,
but more vague than a
specification


Defining requirements is a key output from
fact finding and information gathering

See also INFO627

INFO 503

Lecture #2

51

Requirements


A Need defines the basis for requirements, such as
“the system must support 20 simultaneous users”


A Requirement defines what capability the system
must fulfill to meet the need, “the system must
handle 1000 tps from 20 simultaneous users”


A Specification defines how to measure the
requirement, such as the protocol or
test
conditions
to be used

tps = transactions per second

INFO 503

Lecture #2

52

Requirements


Many requirements are functional


they
describe
what

the system can do


Non
-
functional requirements describe
how

the system performs the functional req’ts


Performance, cost, control (security), efficiency
(resource usage), and the “ilities” (reliability,
availability, maintainability, usability, etc.)

INFO 503

Lecture #2

53

Fact Finding and Information
Gathering


Techniques are:


Sampling


Research and Site Visits


Observation of the Work Environment


Questionnaires


Interviews


Prototyping

p. 243 (623)

INFO 503

Lecture #2

54

Sampling


Works well for study of an existing system


Comes before interviews; may include:


Look for organization chart


Investigate project history


Look for high level mission or policies


Charters for each organization affected


Processes and procedures in use

INFO 503

Lecture #2

55

Sampling


And study existing system documents


Inputs


Outputs


Program documentation


Data dictionaries


User and maintenance manuals

INFO 503

Lecture #2

56

Sampling


If you know a lot about the consistency of
data, can use statistical sampling techniques


A
random sample

should be truly random,
not just convenient


A
stratified sample

may be used to avoid
important special cases

See also INFO 630

INFO 503

Lecture #2

57

Research and Site Visits


Research may use various sources, such as:


The Internet (e.g. for vendors)


Trade and professional journals (AITP, AIS,
IEEE, ACM, etc.)


Company
-
specific intranets


Government agencies (SEI, STSC, etc.)


Site visits are to see the existing system

INFO 503

Lecture #2

58

Observation of the Work Environment


Participate in, or watch the existing system
being used


Should determine what kind of data to
collect, when, and how (what forms)


Should already understand the process
being observed somewhat


Can use sampling for large numbers

of observations

INFO 503

Lecture #2

59

Observation of the Work Environment


Determine who, what, where, why, and how


Obtain permission from supervisor


Inform subject of reason for visit


Keep a low profile; don’t interrupt


Take copious notes, and review them


Focus on important activities


Don’t make assumptions

INFO 503

Lecture #2

60

Questionnaires


Can be efficient for large audiences


But hard to guarantee responses, or fairness


Can use free format, but hard to analyze


Fixed format may include:


Multiple choice (Y/N or A/B/C/..)


Rating (5
-
point from strongly agree to

strongly disagree)


Ranking (importance, or % or time)

INFO 503

Lecture #2

61

Interviews


Provide more personal information about
body language, inflection, tone, etc.


Take a lot more time, but are often liked


Can be structured or unstructured (rare)


Structured tend to use open
-
ended questions
rather than closed
-
ended ones (yes/no)


Need to be well prepared, take good notes

INFO 503

Lecture #2

62

Prototyping


Prototyping, or discovery prototyping,

tends to use very specialized tools, and

may define and refine prototypes with

direct user involvement


Can be part of a RAD development approach


Highly iterative; helps clarify requirements


Easy to omit quality and performance req’ts

INFO 503

Lecture #2

63

Ethics


Many professional organizations, such as
the
AITP
,
IEEE
, the
Computer Ethics
Institute
, and
ACM
have defined standards
of professional conduct


Such standards should be used for guidance
when dealing with information which may
be sensitive, such as pricing structure, profit
data, or employee personal data