CIS 231 - Software Engineering
==============================

GOAL OF COURSE: REFLECTIVE PROBLEM SOLVING

	Managing
	Controlling
	Documenting
	Making the entire process visible

One of the primary purposes of this class is to be able to 
communicate with others.

Who is a stakeholder? They are the people who have something
invested. There might be several stakeholders. You must always
keep their view in mind.

If the stakeholder is a stock holder, what are they looking for?
The stock to go up and make money.

If the stakeholder is a worker, what are they looking for?
Good working conditions, good 'demands'.

Today's topic:  GROUPS
======================
All these "players" have to form groups and function properly.
How do they do this? The last thing we want is a group to be
dis-functional. Dis-functional is always screwing something up.

HOW do you get to know those other people?? 

MBTI - Myers-Briggs Type Indicator. Psychology type test.
=========================================================

This is a test developed back in the 1930's and 40's. 
It trys to classify a person's preference of behavior.

This does NOT at all indicate a person's skill level.
This should also not indicate an EXCUSE - for getting out of something.

This was used for trying to identify how people might be put
together to form an efficent cohesive working group.

Thinkers - did all the initial coding
Feelers - do all the debugging. :)

There are four scales: (for myers-biggs)

Intreversion	Extreversion
Senseing	Intuitive
Thinking	Feeling
Judging 	Perceiving

Intrevert might QUIETLY REFLECT on their activities. You might
go off quietly to think about it.

An Extraverted problem solver would go talk about it, seeking
clarification. You're reflecting, but in a different way.

If you're not a reflective problem solver, you might be a 
REPULSIVE problem solver. You might code something not thinking.

If you are extreverted, you might not get a response as quickly
because you take longer to get to the problem solving point.

Judging - Perceiving
====================

When you're judging, you're talking about the real of reaching
a decision point. This is applying a deadline.  Perceiving is 
wanting to look at alternatives ; brainstorming. However, you might
generate sooooooo many alternatives, you might turn into indecision,
which can appear to look like procrastination.

The group "zig-zag" -  you want to use the I and the E an the
J and the P to synchronize activities.

S -->> N
     /
   /
T -->> F

Sensing - sort of taking in, gathering facts. 
Intuition - is the use of previous knowledge, facts.

You prefer to do one or the other...you MUST do BOTH.

If you become more sensing, you take more time to explore
the facts before you use them.

Gather Information  -->>  Use the Information
                               /

                   /

         /
You must discipline yourself to Sense and then
Intuition. Naturally, you just don't do this.


Then, you next phase, thinking-feeling, you want
to implement or carry out the solution. Then you
must answer the question - how did the solution
meet the goal?

Isn't this EXTREMELY close to POLYA? :-)

I -> E -> J -> P  -- how you should act as an individual and
as a group. Synchronize. What do you want to do first? 


Brainstorming - > Using the information

Evaluating -> Considering...

Review:

What happens in 

"S" - sensing. Gathering facts and gathering information.

I or E - Intrevertion or Extreversion - perhaps reflecting and 
gathering some facts. you might have written a list of questions,
or tried to reach consensus on what is the data we're gathering,
and what are the answers? You may cycle through several iterations
of this.

N - Intuition - Use the facts and information. Share those ideas.

T - Thinking - Make and implement and carry out the solution. Actually DOING 
it (for the party)

F - Feeling - Where you evaluate your solution to see how reasonabe
it was....learn from it.

According to Polya:

S - Understand the problem.
N - Devise a plan.

Walk Through - Cretique the solution before implementation. Causes
you to want to go back and revisit. Try and re-evaluate possible
problems.

What does this have to do with software? Develop it. Charge
for it. If you charge too much, you might loose the customer.
If you charge too little, you won't recoup your cost.

If something isn't released on time, someone else will release
software, too, and you'll loose your market share. Sometime, your
software isn't "tested" and "perfect" - and you'll loose your
marketshare.

Next Topic: RISKS

Chapter One
===========

Product. What is a product? Well, it is something you produce.
Now...how do you produce it? You use some process.

That process must be:

Understandable
Systematic      /           Not random
Rigorious       \           or Ad Hoc
Standards
Planned

the process is NOT Random - or Ad Hoc.

Our product that we are concerned with is the 
Software System, spercifically, the software
development life cycle process.

In order to do this, we must make it:
VISIBLE AND DOCUMENT

*************************************************
WE NEED TO MAKE THE PROCESS VISIBLE AND DOCUMENT 
IT....SO PEOPLE CAN UNDERSTAND IT
*************************************************

What is a system? A purposeful collection of components
that solve a given problem.

Read the RISK OF COMPUTING...from the ACM jan. library

What about software engineers vs civil engineers? We
try to be good at it and use standards.

What kind of standards do we need? : 

Planning:

Make sure things don't happen at a whim -  that they
are planned in some type of structure.

The Idea of Reuse: When you PLAN to reuse another 
module, you are practicing good programming practice.

Library: This is where you want to put modules you wish
to reuse. Many of these libraries are made standard by
a committee at some point.

All of this leads to Object Oriented Programming.  Why
is this? We rely on objects and reuse. Hopefully, at the
base of the OOP process, we have standards for using it.

As technology has evolved and the use of computers has
evolved. Back in the 40's and 50's, there might be 5
computers required in the world? We were using 4-5 
monolithic computers computing balistics.

Of course today we have signifigantly different uses of
computers. Will the previous libraries work? Maybe or 
maybe not. We have to add new libraries or modify the 
existing ones.

cstack and tqueue - are libraries already in c++!! :)

How are product evolved over the years?
========================================

The 1990's were sort of generic products - the shrink
wrapped products existed. 

Timeline:

1950's - everything is all custom software. someone bought
one of those 'five' machines and someone wrote the software
for it. this was the trend through the 90's.

1980's - we started changing with the commodore 64 , et cetera.
this starts a transition period early in the 80's. 

Even today, though, there are several firms that will find 
customized code. They find a ninche that will keep the floating. :)

BESPOKE software -  ? ? 

FAMOUS COMPUTER SCIENTISTS TALKING ABOUT THE FUTURE
===================================================

Carver Mead: Talked about Moore's Law - basically about
every 1 1/2 year - computing power can double.
Eventually, the computer won't be able to go any faster
because it can't get any smaller.

He's thinking biological computing? - He's thinking a
computer..with a processor as small as a piece of DNA,
could have the computing power of a mainframe. He said
science fiction took us 50 years to catch up with 
science fiction (From the 50's). How he thinks it'll be
only 10 years.

PATTY MAES - she's from MIT
==========

Her research groups from MIT - have cameras where they
hook into your glasses. Softwear and Hardwear.
This would require CUSTOM software again.

Perhaps we are moving full circle on this.

Vin Cref - credited with part of the inventor of the internet.
He established internet protocol and ip addresses.


1/25/2000
==========

We previously touched on periods of software -- have 
we come full circle? Check out the timeline on page 5.
We started around 1950 -- with mainframes, we find outselves
today -- more in the pc era, but that actually belongs
in the 1980's. 

Back then, it was custom mainframe and batch software.
It ran without user intervention. That was the way
that software was developed and was supposed to run.

Today, it's the information age. We have more information
today than we had back then! Think of the internet as a
type of batch environment. Go out to the web and find
"interesting sites". 

Again, we're working on information which is so vast,
we're trying to automatically enter internet data...
via a batch mode.

On page 7 - there were some problems listed. Basically,
the risks of computing - some problems. What, exactly,
does it mean if you allow something to come to maturity?

You've completed, you understand a task at hand. Your
experiences. By the time something has reached maturity,
a new version has come out. We don't allow technology,
or the supporting technology, to be fully understood. 
By the time it IS, we have a new version out for the
program.

Software in the industry
========================

Hardware is tangible, but software is part of the control
and part. With hardware - how do you tell if it's good
or not? (look at page 11) - you plug it in.

With software, it's not as easy. Examine page 11. :)

Unfortunately, hardware has a lifetime. Something,
mechanical, might wear out eventually. This is to
be expected just like a car would go out or a water
pump would go on.

Software is supposed to be the other way around - it
should get better and better as the years go on.
Software, instead, has these spikes or periods - software
is used for a period, than abandoned and upgraded.

Now-a-days, you're seeing increased failure rates from software
being released so early - and so you are forced to add on patches
all the time.

Software Crisis
================

He talks about the cruelty of really teaching computer science.
We don't know through enough formal systematic processes to stop
this failure. The engineering failure can't be helped - because
of wear and tear. He said...oh! a bug in the program? little bugs
came into the software? He said..NO! - you put them there!
Why? Because you did it WRONG.  Your process is wrong. Your logic
is wrong. The systems and standards you use are WRONG. This was
back in the 1990 , 1991 conference.

He coined this term back in the 1960's and 70's - he called for
stronger software engineering principles. He says you haven't
learned yet! All testing just tries to find the bugs - but it 
doesn't find ALL the bugs.  Why does your testing find such
a low percentage of bugs?

Dikstra says you have to test everything with FORMAL STANDARDS
to avoid the software crisis. Have formal DOCUMENTATION proving
it's bug-free. You're supposed to program using provable predicate
logic.  oh...GOD!!

Do programming languages let you shoot yourself in the foot?
Um...unfortunately...yes.

REUSE
=====

There might be spare parts available. If something goes wrong
with your car - simply replace the bad part with the spare part.

Some of the areas mentioned on page 15:

look at the breath of the types of applications:

operating systems, servers, compilers, editors, et cetera
real time software...

(monitoring systems, process control)

business software - mostly of interest to the IS folks.
Must be without question reliable, free of error, and secure
many companies were dumping millions and millions into 
KNOWLEDGE MANAGEMENT. Hewlett Packard recently highered
a CHIEF KNOWLEDGE OFFICER - at about 2 million. ;-)

This is managing, controlling, and desciminating the
company's knowledge.

Finally - the MTYHS. :)
Conventional wisdom or common sense wisdom, most likely.

REMEMBER !!!!!!!!!!! --
TOTAL QUALITY MANAGEMENT


2/3/2000
========

Which software model is the best to use? Well, the model
to use is based on what is actually needed.

What does a prototype mean? To build a full blown model
and see if you are moving in the right direction?

For a prototype, you can show a _LOT_ in a short amount of
time. Of course, your employeer might expect a deliverable
in a week or so. Your goal was only to capture an overall
behavior and not a complete behavior.

Do an interface using visual basic - as part of a team.

Step 1: Draw the interface out on paper
Step 2: Design the interface in Visual Basic

In doing this, don't be afraid to throw it away if necessary.

Make visible and document what you've done so you'll know in
the future to do it or do something else.

Mockup
Prototype
Check feasibility
Find Flaws

These steps help you save time on:
Define
Develop 
Maintain (enhancements, corrections)

This might correct a mistake or a misunderstanding. 

Consider behaviors! - give it the best look and feel
you can.

Capture the right solution. If not, start over.
Keep documented solution.

RAD - Rapid Application Development. Based upon the
linear model, but again, we're talking about a short
time frame. This model says you go through the sequential
linear process very quickly on a very small, well understood
compartmentalized piece of a problem.

EVOLUTIONARY MODEL
==================

It evolves. Here, it grows from one generation to another.
Perhaps you should break up the larger project into multiple
projects.

The programs are DEPENDENT on visibility and documentation.

SPIRAL MODEL
=============

Almost amusing. :)  When Nicolli taught this course, just
about everyone religiously used the spiral model.  In senior
project - it was more of a buzz phrase. :)  People were not
really using it.

The waterfall keeps cycleing over and over again (for the spiral)

Risks? - Can you deliver this in a week? Are you going to work
20 hours a day on this? The risk is - he's going to walk.

Actual engineering - and construction - customer evaluations ; 
you test it. Each time around, we have a go-no go. I think that's
best. It sounds like a big project compartmentalized more rapid
development. It's a hybrid of just about everything.

We can revisit multiple parts of this process. Therefore, we can
do the construction and the planning with a better sense of reuse.

The more we use this model, the more we see more reuse is discussed
and considered. The only variable were the people who claimed they
were using the spiral model weren't necessarily doing ONLY spiral.
If we could get people to use the spiral model and we see more 
DOCUMENTED REUSE - then the spiral model might be adopted.

4th GENERATION language - is there a magic silver bullet? (like
visual basic or something?) - there is no magical interface where
you can type in "solve the problem" and it'll solve it for you. :)
You STILL have to deal with DETAILS.

A PROJECT - One of our goals is to do a project and put into place
all of these ideas and principles that we are talking about. we're 
trying to get to a phase where we've devloped a pretty good unerstand
ing of the project and solutions towards the process. Such as prototyping,
perhaps if time permits, go through incrementintly and go through several
interations. 

First thing we have to do is come up with a problem. Do this in a group
setting. Things to resolve:

Form Groups
===========

Start thinking towards an interesting project

The complexity of the problem shouldn't be trivial. It can be a 
larger type of problem.

Our main focus will be on the process of design!!
[product vs process]

Establish a meeting time
Establish MBTI
Pick a PROJECT
Pick a method - (use prototyping early on)
What logic rules do we play by?


Be more ambitious and daring. =)

Haukur Ragnarsson	316-3735	4vikings@bellsouth.net
Mark Burrell		341-4088	burl1@hotmail.com
Ronald McKee		341-4088	rmckee@ametro.net

Thursday afternoons, 3 pm, 

Mark has a chess game he's playing with.

2/8/2000
=========

Talking about the projects - what were some good ideas?
Do three-deminsional tic-tac-toe? 

You could have 01 and -1 's - and 0 is the initial
value. look for 3's o -3's.....to determine your next move.

Models in Chapter two....

We've pretty much ended chapter two...we've ended with the
product and the process. The last paragraph of chapter two
needs to be reviewed - as the creative process.

So...what does the rest of the chapter talk about? The process
should not only be creative, but it should also be systematic.

How does it work? - how do we do this? It all depends on the 
situation. Evaluate the facts.

CHAPTER THREE
==============

Managing the process. This is what we're starting to get involved
in -- in working with our project. The first thing we need to do
is work on managing the process.

Processes have to be managed...they have to be controlled. Today,
people feel badly about it...it evaluates pressure...the boss might
not be treating you fairly.  It's poor management. That's power 
tripping. 

Many people in management positions are not good at what they're doing.
Sometimes people don't manage the process or control the process. Instead
they just show they can manipulate what is happening - through fear or
something.

We need to learn how to manage and control the process.
THE RIGHT WAY. :)

The book evaluates the three P's  :

People - who are the players? Who are the stakeholders?

You have:

The development team: 

the management

the customer:

Thank goodness, everyone is not identical to everyone else. How people
think , the people involved, are all different.

You even have the customer, the client, and the end user. They might
all be different people.

Everyone who has a different attitude in a software situation - 
Bubba and Joe are actually stake holders, as well.

2/10/2000
=========

Who might be the best choice for a software enginnering job?

Is the leader possibly the best software engineer?

It's probably the person with the best management and leadership
skills, but not necessarily your best software engineer.

You might wind up with a person who has to report to someone with
less experience than he actually has.

You have to seperate the management from the technical nature.
Sometimes you are better off to not use your best software engineer,
but instead, use a competent software engineer who might also be
good in management.

Problems might arise because your best software engineer might be
asked to do something differently -- even thought he may know a 
better way.

There should be a mentoring role or a guidence role played by
the leader.

The manager should be an overseerer to an extent, and the good
(best) software engineer should actually lead the engineering
section. The manager is an overall oversearer.

Part of leadership is also the right to evaluate.

Why not form a partnership? Both guys kind of oversee each other.

Those _3_ P's - would be:

People ; Problem ; Process

[p62]

2/15/2000
=========

Today, we're talking about leadership , decision making roles
We're talking about identifcation of a leader, and the leader
being clear with everyone else.

People - - 

Stakeholders

Team
====
Leader - Rabbit or Lion? ;-)

Technical Staff - might have your database expert, tecnical experts.

Library - Primary purpose is to make it visible and to
document it. This is a technical writer or clarical person.
Version control is also VERY important. Dr. Doran gave an
example IDENTICAL to the one I came up with in senior project.
Someone will overwrite someone else's stuff. There are version
control packages which will assist you in not only the version
documentation, but also in not overwriting anyone's stuff.
This is technically the job of the software librarian.

If you are given the opportunity to step into a managerial
role , would you take it? There was no clear answer, just
several advantages and disadvantages.

If you remove a good leader and put in a weaker leader, everything
is going to suffer.

There are good reasons for managing:

GUIDING: This ties into the idea of a leader. HE/she is going to 
guide and give an example for the others. IF the leader is going
to say "ya'll all work all weekend, if you need me, call me on the
golf course" - no one is going to want to be there.

You want to gain a breath of experience - where you would want to
get an idea of what to do. Those experts provide examples as to
what to do.

Perhaps you might be put in terms of managing the network aspect
if you're the network admin. OR .. if you are an interface person,
you might manage that part of the interface.

COACHING: You guide and instruct. 

DOMAIN EXPERT: If you get hired for another group of people, you
might need to bring in someone who is more familiar with that
group of people. That person assists you.

THE PROBLEM
===========

Problems Scope - how much of the problem can you actually handle?
You could be the mocho programmer who says give me any problem,
i can handle it. :)  Why is that a bad attitude? How many hours
can you actually work? How much can you do and actually be
effective?

Experience - How much can be acheived based on past experience?
How much can be accomplished? How do you know how long it takes?
You don't. There are tools that can help you estimate what to do
in the about of time you can do. You can plug it into the kokomo
model - and see if it can be done or not.

What might we see on the test?
===============================

chapter 1-3

Back at the beginning of the semester, 

What is the MBTI?

What is the point of the course? - Reflective Problem Solving
We're talking about the piece of software we are developing.

How should we view the software product? What type of domain?
WHat type of application? How have they changed and evolved 
over the years? (over 20 years...)  How have the types of
systems changed? 

Our behavior should still be rigirous and systematic.

In the old days, software engineering might have been better.
To do it wrong would have been downright PAINFUL. (punchcards,
terrible environments, be SURE you do it the right way!)

Can we afford failure? We discussed Y2k and other risks of failure.
Discussed curves in chapter one - figure 1.4 - our attempt to avoid
failure, in a sense, creates more failure. Moral of the story:
The ideal curve, the bottom curve, is what we want. If we're truely
software enginners, follow these guidelines of this curve. 

PRACTICE IT.......and make it a HABIT.

If you practice the proper curve, one failure does not lead to 
cascading failures. How do we achieve this? We look into processes,
methods...models...

Chapter 2 :

The process. Total Quality Management! More spercifically, QUALITY.
You should always try to assure quality in everything we do. 
(example in chapter 1 - if you have quality, which curve will you
be closer to? the idealized curve, obviously).

How do we assure that quality should take place? A well understood,
systamatic, rigorous process. It is __VISIBLE__ and it is __DOCUMENTED__.
Why do all those surveys? it's a visible form.

How many shops use a systematic process? About 10 percent.
Should be a process....because without it, you fall into the
90% of failures.

Review models - extensions of models.

Chapter 3 : 

Who are the stakeholders? The people involved. How about the
problem and how can it be broken up? How is it affected?

MBTI - be aware and discuss the whole notion of groups and
teams and how you can control and manage from a point of
view (good vs bad). 

TEST FORMAT:

definitional stuff - short answer , fill in the blank.
example: what is software engineering?  (p 25)

??what are 4 things that could be accounted for in maintainance???
	
how many layers are in pressman's model?

what is the advantage of the waterfall model?
clear, documentational

disadvantage?
doesn't handle change too well.

2/24/2000
=========

Chapter 4
=========

What is a metric? - Definition starts with lord Kelvin. It's basically
a measurement. We use a kelvin scale. We measure tests when they are
given back - to see how our performance is.

Works we use often:
Metric
Quality

it's ways we measure these. - and there is a meaning associated with
the measurements.

For us, 0 to 100 have sort of an intrensic meaning.

The scales - the meanings - is what provides us information.
There are so many things we take for granted, because we do not
know necessarily what the true meaning is.

How did they evolve?
====================

Often these measurements were derived from some type of observation.
You might build an instrument or device to measure the temperature.
Maybe some sort of imperical study - of a large sample - it might be
nothing more than the average of many many people. (for example, 98.6
for human body)

How does this apply to software?
================================
We're still trying to get quality - which is at the foundation of
our model. We want something that has meaning. Someone might say
"this software is good" - how do you know if it's good? "Well, it
returns a 72" - how ? what does that mean? someone might have 
developed a scale - though large scale surveys or the average of the
working programs...

All of this sits upon a theory that says there should be some reason
that is the foundation for all of this. You don't just make it up as
you go along. Often - we say "how could someone not like the program?"
It's so good :)

How does all of this REALLY fit into computer science?
======================================================

What are some of these metrics and how do they fit?

LOC - Line of Code - What are some of the theories here? - did you
take a course in computer archetecture and organization?
Each line of code has a cost associated with it. Is this a good
utilization of a scale? it depends on how the code will be 
evaluated. How many cpu cycles is it? How efficient is it?

More complex code brings areas of function point or function count-
which is a measure of decomposition. How many pieces did you 
decompose the problem into?

2/29/2000
==========

(pressman tape 2)

When you initiate a new project - you generally are creating
change.

We move using technology all the time - like every six months.
Therefore, we don't understand the technology we have.

Rodney Dangerfield -  Back to School

Don't use Lines of Code as a reference for measurement.

3/2/2000
=========

Walk-Through? We'll be back to visit this term...

an organized inspection - to improve and make the critique greater,
but it does involve time and resources.


For Next Time:

Be productive. Work on description ; requirements ; definition


SPRING BREAK
=============

3/14/2000
==========

Chapter 5 - Project Planning

Bottom Line - the experience is tied to the learning curve.

Things that make a difference:

Complexity - talk about the problem. It's a hard problem which
has not been solved before. This increases the complexity of the
problem. This could also be derived from how much experience you
have in the area. This comes from the complexity and novelty of
doing a project in a new environment. If you did not know how
to play chess, you'd have to learn first. If Interprocess communication
is a complexity, talk about it.

Size - Try to come up with a metric - a way of measuring how large what
you are doing is. We discussed function points and lines of code. These
could be used to estimate the duration of the project. Is the project
linear? You determine this from previous experience. (If you don't have
much, say so) From this point, these are _ESTIMATES_ based on experience.

Risk - One often fails to discuss this factor. One risk is the fact that
you might not be successful. Example: Too hard, external factors (people
leaving the company), et cetera. If you promose something and can not
deliver - people get discouraged. If all things do not go well, you move
into CRISIS MANAGEMENT.

Uncertainty - 

Have a contingency plan - a backup plan for a problem that might need
to be dealt with.


3/16/2000
==========

You should try to plan a normal routine / script - and hope it goes
well. Of course, if it does not, you move into crisis management 
again.

If it is a formal analytical problem, we're trying to get from
start to finish

Input  -- >>   Output

Write this down - like - in psudocode.

Try to account for possible problems / risks in your plan.

Models for doing this:

COCOMO - Construction Cost Model - You must make an estimate
on time and duration (not to mention cost) - it'll be three
weeks to doing this. 

How do we estimate the costs of the model? Well, one thing we
do is look at the amount of time involved in arriving at the
number of lines of code we have.

Semi - Attached - we might have a little experience with it

Embedded - brand new project , no experience with it

These equasions in the book will answer to the duration
of the project.

So, we might be generating 3000 lines of code- we would say
the complexity isn't too bad. However, there's more - and
continue to multiply...

Numbers used in this model came from imperical studies and
experience.

What is involed in outsourcing? Instead of writing 5,000 lines
of code, you might write 3,000 lines  - but you still have to
put the two of them together. It's no longer an 'organic' problem.

What is the biggest risk here? The outsourcing. What is they 
screw up? What if they screw up as they're working?

Outsourcing is not always the answer - there are additional 
costs involved here. A study took place, and outsourcing
does not always save money. In addition, sometimes they
did not help at ALL.

The scope of the problem leads to the complexity of the problem.

COCOMO
  __

Middle letters - cost.

This is an ESTIMATE - based on experience

3/21/2000
=========

FIGURE OUT THE COCOMO MODEL - meet with the team

Chapter 7 - Scheduling - 

What does a schedule do? Well, it manages time and resources.

What are some of our resources?
===============================

People - 

Cost - need to have a handle on how long it's going to take.

Schedule - What happens during that time

There are time dependencies - you require certain people who are
involved in certain phases of the project. 

Formal Analytical Problem Picture...

Input.........................Output

To make it visible and document what we are doing:

1) Identify the tasks we have to do and their duration.
   Also - what task depends on what other task?
   These tasks are a series of systems - some have other sub-systems.


3/30/2000
=========

Milestones, SChedules, Risks - are the next step

Final part - high level addressing of the analysis of getting
into the design of the solution.

Project due last day of class.

TEST - Tuesday, the 4th of April.
==================================

Start with project planning - points in there
	function point
	lines of code
	kokomo

Explain what each of these ideas mean and are used for
Where did they come from? [imperical studys and data]

Use the formula....to determine an amount

"You're given this problem, your team thinks you need
x number lines of code. You have a certain degree of
experience. Justify how long you think this will take."

Under what conditions can you do this in six months with?

This is a semi-detatched problem...

Fudge factor - add in extra time for confusion, et cetera...

(Risk)

will have advantages and disadvantages...

you want to avoid risk if possible, setup a continguency plan
avoid CRISIS management

Gain a level of experience so we can plan and manage it...

(chapter 7)

Resource Management / Scheduling
How do we work around the amount of people we have, the amount
of time we have, et cetera

Homework assignment - do an activity graph - this will wind up
on paper somewhere.....

(chapter 10)

Understand the systems - what we need to construct.

How does having an effective view of what you're going to do
impact the bottom line?

If we try to automate a bad process, we're going to get a BAD
SYSTEM!!!.  If you take a process , we don't make it effective,
robust - we've developed an expensive software system that is a
disaster. :) It does not make the business process any better.

Automating something is not always the best way to go.
Paper and pencil is still sometimes the more effective way
to solve a problem.

4/11/2000
=========

We are trying to achieve the development of a SYSTEM.

We're moving from a "world view" down to decomposition.

We decompose from a "global view" to actual detail.

This leads to LITERATE programming - (coined by Don Kenute) - 
a famous programmer at Stanford - Where you really tell a
story.

This is a perfect tie-in because as we talk about decomposing
or our view of a system we're trying to develop.

Information Engineering? - What are we trying to capture?
Information. Lets talk about knowledge / Information Engineering  / 
Knowledge Management:

Information or knowledge is a RESOURCE - some, a most valueable
resource.

Companies have gone on this now where they have a CKO

Chief Knowledge Officer  - [hewlett packard recently hired
someone to be their CKO....to the tune of several million...]
This is considered important. You want to do all of this and
try to minimize the paths - do it right the FIRST time.

PRODUCT
=======

(Section 6?)

The different pieces of the product need to be reconized:
[you'll see this eventually in senior project]
Sometimes these points are ignored or not even addressed

Identify the need - motivate the person, et cetera

Identify how it impacts the bottom line

Identify the feasibility - how possible is it to even do?

Economics - how much does it cost?

Learning curves? - [learning perl? the language?]

In chapter 10, you have the part of what you need in
senior project

Review page 265...

Feasibility? - Build prototypes, simulations

CHAPTER 11 - [Requirements...]

Requirements come from an initial conversation with your client.

You need a way of actually extracting what they want...

SIGN OFF ON IT

meetings DO NOT WORK if you don't plan!

Maybe it should look more like a preliminary users manual?!

Answer the client's answers in this document. If you use this
system, it should look and behave in this manner.

Next up - the data, the control


4/18/2000
==========

Lets write up a description of a problem - later, to do a gramatical
parse with it...leading to an ER-diagram.

4/25/2000
=========

Design concepts and principals - Mainly chapter 13.

We've been talking about design since the first days of the 140
sequence - pressman talks a lot about the design.

Basic moral here - don't rush through the design - it should be
slow and detailed.

What exactly is TESTING ? 
=========================

Use the idea of testing as "debugging and finding errors". However,
it should also include verifying and proving that we did it correctly.

Testing is really verifying or proving that we did something correctly.
Generally, we have to come back to the design for this. You must verify
the logic has been thought of and implemented correctly. 

This is the difference between testing and debugging. We're using this
design, sort of, as a "proof".

There is a planned testing event - it comes directly from the design.
It should lead to an event, an activity, that should be planned for
during the testing phase.

We'll talk about common ideas we've seen before - spercifically a
test plan.

Check for expected inputs - make sure the outputs appear right.
Check for boundries, limits, and other not-expected inputs.

Layers of Design
================

Intellicual Design
Archetectural Design
INTERFACE DESIGN! - (How can that data be shown to the user 
                     in the most useful way?)

Proceedural Design - must be documented and explained, as actual
events are taking place.

What is PROCESS?
=================

A visible activity which was in place.

It's also "iterative" - it's something that must continue as
an ongoing process.

Define what the activities are and how/why do they iterate 
(repeat over and over and over...)

What does it mean to do it just once? It becomes the normal
expected behavior. Hopefully, through and through, we adopt
the good process habits, and not the bad ones.

Another thing we should consider would be testing and actual
walk-throughs. It's better to test as we go along than to 
'test on the fly' - test WITH the design.

Constraints
Alternatives
Feasibility

The evolving process
====================

These materials and these processes change every few years
and evolve as industry evolves.

Something that is very current and very new - UML - universal
modeling language. This is an object-oriented approach to design.

Design Principals:
===================

Make a note of REUSE - this should be one of the driving forces
whenever we are designing and trying to solve a problem. Reuse
should be PLANNED FOR as we go about the design .

We should plan for reusing of libraries or simply reuse segments
of code.

Reuse code (which is obvious), but also reuse KNOWLEDGE.

Create and leave behind a knowledge repository and a coding
repository.

4/27/2000
==========

We're going to finish up some pressman topics in chapter 13...
Cohesion and Coupleing.

We've heard these as we went alone - on figure 13.6, the 
single-minded, one single identifiable module...

Doing one function does not always cause another instruction
to occur.

Types of Cohesion:

Functional ....................................... Coincidental

(High Cohesion)                                    (Low Cohesion)

The higher the degree of cohesion, the less chance, scatterbrained,
et cetera feeling of keeping things together.

Modular design helps considerably with this. You still have to write
code, generally even proceedural code, but organizing it makes it much
better.

TEMPERAL COHESION
=================

You might write a program where certain things have to do with 
certain events - you might have to initialize items to their 
"home" position.

At the "beginning" point in time, reset everything to "home."

At the "end" point, write info to the file, close the file,
whatever...

COUPLEING
=========

This talks about the intercommunication between the modules,
the data flows.  We've visualised this using our data flow
diagrams.

We want to minimize coupleing...we want a function with ONE
parameter rather than 50.  If you've got 50 parameters you're
sending in, you're trying to do _TOO MUCH_. 

Most of the time here, we're going to deal with data coupleing.
Send the minimum amount of information necessary.

CONTROL COUPLEING
==================

You often see this one - control is some of the data and information
from one module to another.  This controls what's going to happen.
You might send an error flag through this or some other type of signal,
good or bad.

STAMP / TRAMP COUPLEING / HOBO COUPLEING
========================================

This is a piece of data you send from proceedure to
proceedure until it finds where it needs to be.

The piece of data has no decernable destination.

FINAL WORDS
===========

"Do not sell the book" - haha
"Habit" - be sure to develop good habits for these steps.

Concentrate - 
	Stuff since second test
	chapters 10,11,12,13
	data, data flow, definition, entity relationship, modeling
	
take problem statement, identify the entities, do a grammatical parse,
START with the OBJECTS.

data flow diagram - discuss in general why we want to model and 
represent, and what is found and achieved as we decompose and form
more levels.

Work with a simple problem statement, go through a data model, 
idenfity the entities, talk about the relationships, be reasonable.

Don't "contribe" artifical relationships - only sane relationships. :)

Go through a very simple data flow diagram - using pressman's ideas.
(Start at the top level with the context and put it in with the external
world (external inputs to external outputs)).

Level 1 - account for externals, but now you have temporary data storage,
some variables, perhaps.

Not necessarily something elaborate, but enough to get by.

Think of the "project" as a practice for the test.

Review old tests....philosophical and foundational material. :)

Individually do a homework - do one or the other on page 367, puts
you in the mood for the test. <groan!>

Do one of the last two questions - #15 or 16.

Bring to exam.

Review points to ponder for each chapter... ? maybe?

fill in blank
short answer
bigger thing will be a data modeling question