1. IntroAndChapter1

7/29/2019 1. IntroAndChapter1

1/29

Copyright Dr. H. Joel Jeffrey, Ph.D. 1

CSCI 663

Chapter 1


2/29


Software development as a student

Professor hands you assignment

You code the assignment

You run the tests the professor tells you to run

You doc it

You hand it in


3/29


Real world software development

You are part of team that decides on whatcode will do

You are part of team that decides howit will do it

You code part of project

You define the tests you need to make, to be sure yourcode will not break

You test your code

Someone else tests your code together with other

people's code Someone installs your product on client computers

Client decides whether to pay you


4/29


A few years later...

You get promoted, are a manager

After which you never:

design

code

test

Instead:

You are responsible for having other people do thesethings


5/29


Which means...

Life in the real world: nothing like anything you havedone in computing so far.

This course: all the otherstuff.

The undergraduate A&D course (CSCI 467/567): Good

in t ro course. Programming: much more than you learn in your first

course.

Same with A&D/software engineering: much more to

than you learn in your first A&D course Goal of this course: you are prepared for real world

SW development, and prepared to manage real worldSW development.


6/29


Goal of this course in more detail

Give you an edge over your competition

Most IT professionals:

Good at design & programming.

Mediocre to poor at understanding customers & their ITneeds

Poor at understanding their clients.

This course: Much more advanced knowledge

about How organizations work

What you do with your customers


7/29


You will gain..

Knowledge of how to deal with clients

Skills for dealing with customers

Very sophisticated procedures for doing

frequent tasks Ex:

How do find out what your customers want and need

How to design a meeting/presentation

How to estimate a software project

What to do when the project slips its schedule


8/29


In the real world:

What matters: producing systems that

Meet the needs of your clients

they agree meets their needs

Not: Software efficiency, system power, technical

elegance & sophistication, etc.


9/29


Why this emphasis?

Most A&D courses: focus is on technical

content: architecture, good designs, patterns,

programming techiniques

This course: how to work with clients, how to runmeetings, how to understand clients, how to

manage SW projects and teams

Why the difference?


10/29


Because...

What we study in here is what matters the most

in real world SW development:

Biggest effect on SW project success

Biggest effect on satisfying SW clients


11/29


Industry track record


12/29


Industry track record

28% success

23% failure (cancelled)

49% challenged.

Challenged: over budget, over time, and fewer

features/functions than planned.

Summary: 28% delivered what was promised, at

the promise time, for the promised price!!


13/29


How "challenged"?

Cost overruns: 45%

Time overruns: 63%

Features: 67%

This is shameful. By academic standards, the

industry gets an F.


14/29


Not due to technical problems

20% of software project failures due to a failure

of technology

Overwhelmingly, causes are:

Bad job on the requirements

Lack of customer involvement


15/29


Relationship between technical and non-technical

Figure - ground


16/29


Two faces or a vase?


17/29


Software development figure/ground

Vase:technical

Faces: human/

organizational


18/29


Figure/ground: the real point

When you're looking at the faces, the vase isgone can't see it, ask questions about it,

analyze it. And vice versa.


19/29


No sloppy talk!

Technical and human/org intimately intertwined Changing one changes the others

Talking about one IS talking about the other

BUT: Usually: we are very careful and precise in describing the

system. We are very sloppy, loose, intuitive, crude, vague in describing

the client's organization and what they need.

pop psychology

no specification of who what system used for

abstractions

THIS IS NOT GOOD ENOUGH!

Being sloppy about client org IS being sloppy about thesystem!


20/29


Needed:

Resources for being as precise in describing thecustomers as we are in describing the designand code.

Sloppiness: deadly in code, and deadly in talking

about customer needs Human system model: only such resource

available Communities & intentional action parametric

formulations Applications to software engineering situations &

tasks


21/29


Learning to be precise about clients

Major goal of next 6 weeks: learn to specify

client work completely and precisely

Nothing left out

Nothing added

ONLY way to do this: learn to dissect

ordinary English to find the logical

structure of client org and its work Be warned: this is HARD


22/29


Let's start: What is software engineering?

1. Simplest definition: Developing SW in the RW

2. Better: Developing SW for use by a group ofpeople

3. Better yet: Development of a SW system byone grp of people for use by another grp ofpeople

4. A complete, formal definition: the outcome of

the work practices of one group of people is aSW system which is to be used in the workpractices of another group of people.


23/29


Definition 1 vs. Definition 4

Definition 1: correct, but not helpful

Definition 4: result of the work practices of onegrp of people is a SW system which is to be

used in the work practices of anothergrp of people.

Define formally!


24/29


Payoff

We can be as precise & rigorous about the

human/organizational set of facts as we are

about the technical ones


25/29


3-part system

Computer

system

Producers Clients

3

componentsof 1 system!

Human

systems


26/29


Implications

The facts we need, as analysts, include are 2

distinct kinds of objects, processes, events, and

situations:

Technical Human/organizational.

Technical facts and human/organization facts

are not separate sub-systems; they are two

views of one system: figure/ground

Neitheris the whole story.


27/29


Decisions

One system, not separate sub-systems.

Result: each kind of fact affects the other kind:

technical things affect the human/organizational

and vice versa.

Result: There is no such thing as a purely

technical decision

(a choice about technical things, like code and datastructures based on technical attributes and

characteristics).


28/29


Facts NEVER speak for themselves

Many think: the facts speak for themselves

Put the technical facts and attributes on a scale; the

side of the scale with the most reasons wins

Never, never, never! Brute fact: ALL decisions are made by

individual persons, based on whatever they

consider relevant relevant, some of which may

are technical.


29/29


Good analysts must be able to...

Understand the whole story, including the

technical and the human/organizational aspects

i.e., the human-technical system.

Recognize when a situation calls for a focus on oneor other

Switch focus when called for

Recognize when thing are going wrong due to

aspects of the other world Ex: System does not provide functions to gather data unique

to how thus client does due diligence, because of their

company philosophySystem

functioning Client

practiceClient values

1. IntroAndChapter1

Documents