head	1.3;
access;
symbols;
locks; strict;
comment	@% @;


1.3
date	92.10.28.10.04.23;	author marlow;	state Exp;
branches;
next	1.2;

1.2
date	92.10.28.07.23.54;	author marlow;	state Exp;
branches;
next	1.1;

1.1
date	92.10.25.17.58.46;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.3
log
@l
@
text
@
%
% In this section describe the methodology used to create
% the design of this system.  Include a description of
% any standard or non-standard diagramming or notation
% methods used.
%
\section{Design Methodology}

  The design of the \xplan\/ software has drawn upon a variety of techniques learned
and studied in Dr. Cheng's CPS 470 Software Engineering course at Michigan State
University.  We have approached our design from a variety of perspectives, and applied 
useful techniques where most appropriate for solving a particular problem.  The goal 
of our design effort is to produce a useful project planning tool which is simple to 
use and has a high quality factor.
  
  The issue of quality was addressed very early in the design phase, and has 
remained important throughout the \xplan\/ software design. First, the group utilizes the
class lecture and textbook advice regarding a high level of interaction with the 
software product's customer.  Various milestones have been set, and accomplished with
the design. These have been the creation, production, and customer review of the
Project Description, Project Plan, Requirements Specification, and Preliminary
Design Documents.  These documents have been important in building quality into our 
software product, because they have provided the customer with a representation of 
what the final product will be like, as it has been conceived, developed, and evolved 
through various stages of the design. These documents have been useful, because they
provide reality checks for both the customer and the software engineering development
group for the PERT/Gantt chart generator.  Expectations are defined and studied early
in the design phase, so that the customer knows exactly what to expect.  Also, the 
customer reviews of the above mentioned documents provide the group with valuable 
feedback from the customer.  Potential problems are identified early in the development
process, so serious questions about desireablity, practicality, and capability of 
methods, algorithms, and tools used to create and operate \xplan\/ can be addressed. 
Areas which may need further research and development are defined, and then addressed as 
necessary. All of this gives the group a lot of information to draw upon when proceeding 
to the detailed design and implementation of \xplan.  It is good engineering practice to 
study a problem, and become knowledgeable about its various aspects before going into the 
lab to develop a solution.

  One of the most attractive features of the \xplan\/ project planning tool software will
be its graphical interaction with the user which makes the tool simple to use.  To design
the graphical user interface for \xplan\/ with the aid of the guide development tools
for X Windows, the group has followed the human computer interface design guidelines
in chapter 14 of \cite{text}.  The \xplan\/ windows have been created to be 
consistent, well labeled, and follow in a logical manner where the user achieves the 
desired functionality by pointing and clicking with the mouse, and then inputing data from
the keyboard or an ASCII text file.  The amount of information that the user must memorize
to use \xplan\/ is minimal, since the graphical user interface was designed to be self
explanatory, and provide on-line help to the user.  The user sees the softwares data items
and control features grouped together in a logical manner, as they need to be used.  Since
\xplan\/ is a project planning tool, an efficient human computer interface was necessary to
make the tool attractive to the customer and other potential users.  Also, \xplan\/ is
designed to be fault tolerant, forgiving, and inform the user of the occurrence of errors, 
instead of catastrophic failure in case the user makes a mistake, enters invalid data, or a 
computational error in calculating the critical path of a PERT/Gantt chart occurs.
Furthermore, \xplan\/ will be a useful tool since the PERT/Gantt charts it produces can
be stored into a LaTeX formatted file which the user may incorporate in the
\LaTeX\ document processing system.  That was an early design decision to make \xplan\/
attractive to the customer and other potential users since \LaTeX\ is a powerful and
commonly used document processing software which is widely available at no or low cost
in many computing environments.  Basically, the \LaTeX\ output option is a value added 
feature of \xplan's\/ design.
  
  Regarding the actual process that our group is going through in designing \xplan\/, we
have been offered and taught a variety of useful methods.  The various methods such
as data oriented design, object oriented analysis and design, and structured design
techniques have been applied wherever useful in developing our design.  Also, it is
important to mention that a mixture or hybrid of these techniques learned in CPS 470
has helped us develop our design.  For example, data oriented design methods have
helped us define the information domain of our software.  By developing various levels
of data flow and control flow diagrams, we have been able to look at our project at
a practical level as we progress from the stages of brainstorming, high level overview
design, and into the detailed aspects of the design.  The data flow and control flow
diagrams help us to define the problem to be solved.  Furthermore, we are able to 
develop  processing narratives describing these diagrams actions and influence on the
project planing tools software design and implementation.  They help us to break down the
information and control issues into pieces which are manageable to analyze, understand,
and develop data structures, algorithms, and processing modules for.  Furthermore, as
we advanced towards performing the detailed design, we were able to use the data flow diagrams,
control flow diagrams, and processing narratives to develop a program design language
description (PDL) and structure charts for various modules of \xplan.  This is good, 
because we are always using what we have done as a foundation to gain a mature understanding of
 the scope of the software and to refine our ideas into realistic and practical solutions.
Eventually, we come to the time when we develop very detailed PDL's and processing 
narratives for all of our processing modules, data structures, and submodules.  Once we have 
accomplished the milestone of having the customer review our detailed design, and we
have critically reviewed it ourselves, we will be ready to proceed with the full 
implementation of the \xplan\/ software in a language which is best suited for our 
application, and the hardware and software environments our customer will want it to
run on.  Furthermore, by addressing issues of industry standards like ANSI C, Unix,
and X Windows for our softwares operating environment, we further build quality into
our product by having a high level of portability.  Portability also expands the 
ranges of customers we may offer our software too.

  In regards to the specific notation of items such as data flow diagrams, control flow
diagrams, structure charts, and program design language (PDL), that we have used in \xplan's\/
documentation, the reader is referred to the cps 470 class text \cite{text}.  Other 
issues addressed in our design have been the necessary hardware, software, and operating
system environments \xplan\/ requires for optimal operation.  These are important design
constraints, because the graphical nature of the user interface in X Windows has 
certain performance requirements of the xplan hardware and software environment for 
the user to use the tool in real time with near instantaneous response time to commands
and window functions.  Furthermore, the limitations of \xplan\/ itself are addressed so
the user will be able to know what the maximum performance level is.  The group has
studied the issue of how many items in a PERT/Gantt chart may be displayed on an X Windows
canvas, so the user will know the upper bound on how many tasks may be processed in a
particular PERT/Gantt chart.

  In summary, the PERT/Gantt chart generator group's design methodology is the following.
First identify the problem at hand, so the scope of the software solution may be developed
at an early stage.  Use whatever techniques best fit the problem, and produce a meaningful
analysis which can be refined into a plan for the software solution. Furthermore, the design
documentation, customer and team review milestones are important in keeping the project
on course and on schedule. When risks, critical issues, and problems are discovered and
addressed at an early stage, a more meaningful design can be developed at the detailed
design stage.  Finally, the methods of structured analysis, object oriented analysis and
design, and data oriented design methods are applied as they help to understand the problem,
and then facilitate the development of appropriate solutions as the level of detail in
design advances towards the implementation phase of the project.  Most importantly, the
customer oriented approach to software engineering will aid the development of quality
software that performs the way it is expected to. 
@


1.2
log
@*** empty log message ***
@
text
@d10 2
a11 2
  The design of the xplan software has drawn upon a variety of techniques learned
and studied in Dr. Cheng's cps 470 Software Engineering course at Michigan State
d18 2
a19 2
remained important throughout the xplan software design. First, the group utilizes the
class lecture and text book advice regarding a high level of interaction with the 
d33 1
a33 1
methods, algorithms, and tools used to create and operate xplan can be addressed. 
d36 1
a36 1
to the detailed design and implementation of xplan.  It is good engineering practice to 
d40 3
a42 3
  One of the most attractive features of the xplan project planning tool software will
be its graphical interaction with the user to make the tool simple to use.  To design
the graphical user interface for xplan with the aid of the guide development tools
d44 1
a44 1
of chapter 14 in the class text /cite{text}.  The xplan windows have been created to be 
d48 1
a48 1
to use xplan is minimal, since the graphical user interface was designed to be self
d51 2
a52 2
xplan is a project planning tool, an efficient human computer interface was necessary to
make the tool attractive to the customer and other potential users.  Finally, xplan is
d56 4
a59 4
Furthermore, xplan will be a useful tool since the PERT/Gantt charts it produces will
be able to be output into a LaTeX formatted file which the user may incorporate in the
LaTeX document processing software.  That was an early design decision to make xplan
attractive to the customer and other potential users since LaTeX is a powerful and
d61 2
a62 2
to the people who use machines like SPARCS with a Unix and X Windows environment.
In a sense, the LaTeX output option is a value added feature of xplan's design.
d64 1
a64 1
  Regarding the actual process that our group is going through in designing xplan, we
d68 1
a68 1
important to mention that a mixture or hybrid of these techniques learned in cps 470
d79 5
a83 3
we advanced to and performed the detailed design, we were able to use the data flow diagrams,control flow diagrams, and processing narratives to develop a program design language
description (PDL) and structure charts for various modules of xplan.  This is good, 
because we are always using what we have done as a foundation to gain a mature understanding of the scope of the software and to refine our ideas into realistic and practical solutions.
d88 1
a88 1
implementation of the xplan software in a language which is best suited for our 
d96 2
a97 2
diagrams, structure charts, and program design language (PDL), we have used in xplan's
documentation, the reader is referred to the cps 470 class text /cite{text}.  Other 
d99 1
a99 1
system environments xplan requires for optimal operation.  These are important design
d103 1
a103 1
and window functions.  Furthermore, the limitations of xplan itself are addressed so
d109 1
a109 1
  In summary, the PERT/Gantt chart generator groups design methodology is the following.
@


1.1
log
@Initial revision
@
text
@d9 111
@
