Software Engineering                                         Jim Murphy
CSCI-112                                                 Fall 2001

System can mean many things but we want it to include:
Software, Hardware, People, Database, Documentation
and Procedures - not functions our program calls but how things
are done within and between the system components above.

The author distinguishes Information Engineering when dealing
with the information needed to run a business and Product
Engineering when we want to translate a customer's wishes
into a working product.  But if you look at the diagrams on
pages 238 and 240 you will see that abstractly there is no
difference.  Is a payroll program/system IE or PE?

IE now encompasses large integrated systems rather than trying
to hook together isolated pieces that had each been designed
and implemented separately

In IE at the highest level we have the enterprise as a whole and
Information Strategy Planning with concern for goals and
objectives for the entire organization - also at this level is the
forming of an enterprise model which includes an organization
chart identifying divisions or departments and their various
business functions (engineering, marketing, sales etc.) and the
interrelationships between them

 Business Area Analysis at the next lower level analyzes in
detail one area or division of this organization at a time
The processes of this area are identified and modeled and
the flow of information is elaborated in a flow model as in
the figures on pages 248 and 249 for the sales function

At the lower two levels of the IE hierarchy software engineers
build needed products for the enterprise with Product Engineering
a problem solving activity including:
System analysis - identify the customer needs more precisely
is there a market? What are the limits on cost and schedule?
How does the proposed product compare with the competition?
All this can be put in a "system concept document" similar to
our second assingment - see page 253.
 
Evaluate the feasibility of the proposed system, economically,
technically, legally, and what are the alternatives if any
The technical feasibility in connection with the limits of cost
and schedule may be the most difficult to estimate if the specs
of the product are at all fuzzy which they may well be at this point
Do we have the people to pull it off?  Is the available hardware
up to the task?   See page 255 to see what to include in such a
study - you may want to say something about the cost/benefit
analysis in your own second or third assignment.
Statistical analysis or optimization models or simple simulations
on spread sheets may be of some help here

Allocate functions to various system components - hardware,
software, people, database etc.  Note your semester project could
range from a single program to a larger system where the
software is only a smaller component of this system

Determine cost and schedule constraints

In modeling the product architecture you will want to examine
at least:
User Interface Processing, 
Input Processing 
Process and Control Functions
Output Processing
Maintenance and Self-Test

This does not mean that the "code" will be subdivided this way
as for example in an object-oriented programming language
An architecture flow diagram as on page 262 can provide more
details of the model especially if each piece is further expanded
in an AFD hierarchy as on page 263

A system specification following an outline such as that given
on page 265 can serve as the foundation for people working in
Software, Hardware, People,  and Database

As software engineers we can pick it up at this point to begin
the requirements analysis phase of product development ending
with the Software Requirements Specification as outlined on
page 291 and turned in by you for assignment three
Note that after reading Chapter 11 you may want to base your
analysis on Chapter 20 instead if you are following an object-
oriented approach