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


1.5
date	92.12.14.09.45.05;	author lacey;	state Exp;
branches;
next	1.4;

1.4
date	92.12.14.09.22.04;	author gaubert;	state Exp;
branches;
next	1.3;

1.3
date	92.12.14.06.31.42;	author gaubert;	state Exp;
branches;
next	1.2;

1.2
date	92.12.14.05.40.30;	author gaubert;	state Exp;
branches;
next	1.1;

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


desc
@@


1.5
log
@*** empty log message ***
@
text
@%
% Describe specific techniques that were learned from the class and applied
% to the project.  Below are just a few examples of text that can
% be included in this section. Feel free to add more sections are you
% feel necessary.
%
\chapter{Techniques Learned and Applied}
\section{Methods and Processes}

  Many software engineering methods and processes were learned as a result of 
designing \xplan\ for our groups CPS 470 class project.  Some of these are
software engineering methods, software engineering tools, business management
tools, technical writing and communications skills, and team engineering 
skills are explained below.

The process that was involved in the creation of the \xplan\ project
started with a project description, a project plan, then a
requirements specification. Next, a preliminary design was done for
the project followed by the detailed design.  Lastly, a testing
specification and user manual was written.

The project description involved writing out an understanding of what
the group thought of the project. Simple, medium, and hard versions
of the project were written. The goal was to implement the medium
version of the project. 

The project plan was the next step in the production of the \xplan\ project.
Within this document, the group made estimates of the project, defined
the major milestones, defined the major tasks that were involved, and
defined the resources that were used in the production of xplan.
The tasks defined the major parts of the project that had to be done.
These included the requirements specification, preliminary design,
detailed design, testing specifications, the coding phase, and the
user manual. These tasks were broadened by the use of
MS-Project. MS-Project allowed all of the tasks for the project to be
laid out in a pictorial format. Gantt and PERT charts showed the
format and direction of the project.

Next, the requirements specification gave the overall description of
the project, the constraints of the project, the information flow
representation within the project, a functional description of the
project as a whole with a functional description of the of the
specific partitions, functions, of the project. The requirements
specifications also listed the performance requirements of the
project, the design constraints, the behavioral description, the
validation criteria, and the performance bounds. Data flow and control
flow diagrams were used in the information flow representation section to show
the flow of control of data within the system. This also helped in
understanding the functional partitions that were used in the project.
This part of the software was designed to help the customer and programmer
understand what the program was to do as a finished product. This
phase was also the backbone of the rest of the phases within the
software engineering process. 

The requirements specification was used as a guide for the preliminary
design phase of the project. This phase defined the main structure of
the project, the interfaces between functions and modules, the test
provisions or guidelines that were to be taken, and how the external
file structure was to be maintained. Each module was was explained in
detailed as to what it's function was how it was to be implemented and
how it was to be integrated to the rest of the modules. Within this
phase all functions were thoroughly defined and structured with the rest
of the system. This gave the project the organization, structure,
and integration methods that it needed in order to start the detailed
design phase.


The detailed design phase incorporated all of the material used in the
preliminary design but extended upon the program description language
(PDL), structure charts, and the use of a data dictionary to define
the names of all of the global variables, where and how they are used.
This also uses the popular notation, demarco notation, in giving a
description of the variable.  PDL, on the other hand, is a method of
coding that shows the implementation details of the function or
module. This was very useful in the coding phase and helps in showing
the functionality of the program to the programmer. Lastly, 
structure charts were used in this phase to help break down the
function calls within the program.


The next phase was the testing phase. This phase was used to test the
individual modules with test data to ensure the validity of the
program as a whole. The techniques used were white and black box testing.
White box testing tries to execute all commands or lines of code in
the program, while black box testing uses the modules as a black box
where the input is fed in and the outputs are examined. This leads to
the coding stage.

The coding stage used all of the previous documents as a guide in
the programming of \xplan. The detailed design was more helpful than
other documents because it shows the implementation details needed in
this phase.


The implementation details helped to improve our awareness of what is
to go into the project but the documentation requirements for \xplan\ also
improved our technical writing and communications skills.
Furthermore, we learned a lot about how to work in a team environment,
and how to communicate complex technical ideas to our peers.  The team
work required us to refine our skills because other people would be
reviewing and using our work and they evaluated it from a different
perspective than we do when something is done individually.  They many
different perspectives helped to contribute lots of good ideas for
designing and implementing our project.  That was important because
the selection, evaluation, and implementation of different complex
ideas is what the professional software engineer does on a daily
basis.  Finally, the emphasis on software quality assurance was an
important part of the skills we learned while designing and
implementing \xplan.  The process of building quality into a design
before implementing it is important, because it makes us more
productive software engineers who design better software that is
maintainable.


\section{Tools}

  In the course of designing and implementing \xplan\, we learned how
to use several tools that are useful for software development.  For
example, our programming skills utilizing C and Unix improved, because
the \xplan\ project was a large piece of software.  The processes of
configuration management using RCS was a good experience because it
kept track of various stages of design development in the group in a
consistent way.  The OpenWindows Developer Guide 3.0 was a good CASE
tool to learn, because many useful applications utilizing C, Unix, and
X Windows can have useful and complex Graphical User Interfaces
developed quickly and efficiently.  \LaTeX\ was a good document
processing system to use, because it facilitated writing large
documents in which several different people contribute, text, tables,
equations, postscript figures, GUI screen dumps, and diagrams.  Flex
and Bison were used for entering files to \xplan. We also used
several other useful tools such as the emacs editor, vi, xfig, and the
dbx debugger. Finally, one important tool we learned and worked with
was MS Project. MS Project gave our group insight as to what was
expected of our tool.
@


1.4
log
@*** empty log message ***
@
text
@d90 1
a90 1
the programming of xlpan. The detailed design was more helpful than
d109 1
a109 1
implementing xplan.  The process of building quality into a design
d130 1
a130 1
and Bison were used for inputing files to xplan. We also used
@


1.3
log
@*** empty log message ***
@
text
@d30 1
a30 1
defined the resources that were used in the production of \xplan\.
d109 1
a109 1
implementing \xplan\.  The process of building quality into a design
d130 1
a130 1
and Bison were used for inputing files to \xplan\. We also used
@


1.2
log
@ll *.tex
@
text
@d30 1
a30 1
defined the resources that were to be used in the production of \xplan\.
d52 1
a52 1
phase is also the backbone of the rest of the phases within the
d63 2
a64 2
of the system. This will give the project the organization, structure,
and integration methods that it needs in order to start the detailed
d81 1
a81 1
The next phase was the testing phase. This phase is used to test the
@


1.1
log
@Initial revision
@
text
@d11 1
a11 1
designing xplan for our groups CPS 470 class project.  Some of these are
d16 5
a20 23
   In designing our project, we often used structured analysis and design
techniques to develop and communicate xplan's design and ideas for 
implementation.  For example, the numerous data flow diagrams and control flow
diagrams help us to clearly organize our thinking regarding how our project
would be designed.  Writing processing narratives describing how the diagrams
worked help us to develop the software solution.  From that information, the
program description language (PDL) was the detailed design implementation of 
our ideas.  The above methods when performed in the organized way taught in 
CPS 470, helped us to take our ideas from a vague and conceptual phase into a 
clear and organized format.  Learning how to work out details in the design 
phase is the most important skill we learned for software engineering.  
Furthermore, the processes of thinking about testing specifications and user 
manuals as part of the design phase of software engineering helped us to 
further refine our ideas.  Basically, the various documents and the necessary 
work that went into preparing the xplan documents taught us how to get our 
software designed in a logical and detailed way before we started coding.
Once the design is good, we learned that most of the problems with 
implementation will be related to the coding, syntax, and learning the 
details of the implementation environment.  The coding phase will be much 
easier once we are professional software engineers, because we will be 
experience in all the details of the hardware and software tools used to 
implement a detailed design.  Since we are students, we are still learning 
those things and gaining experience.
d22 4
a25 7
  Technical review milestones were an important thing we learned in CPS 470.
The processes of reviewing our work from a critical perspective was better
than just assuming everything we designed was correct.  The critical review 
of all of xplan's designs, and design documentation helped us to catch many 
design errors before we started coding.  Thus, we were more efficient in the 
implementation phase of engineering xplan because several critical problems
were worked out early in the design phase.  
d27 74
a100 5
  In CPS 470, we also learned many valuable practical business skills.  The 
documentation requirements for xplan improved our technical writing and
communications skills.  Furthermore, we learned a lot about how to work in a 
team environment, and how to communicate complex technical ideas to our peers.
The team work required us to refine our skills because other people would be
d102 11
a112 10
perspective than we do when something is done individually.  They many 
different perspectives helped to contribute lots of good ideas for designing
and implementing our project.  That was important because the selection, 
evaluation, and implementation  of different
complex ideas is what the professional software engineer does on a daily basis.
Finally, the emphasis on software quality assurance was an important part of
the skills we learned while designing and implementing xplan.  The process of 
building quality into a design before implementing it is important, because it
makes us more productive software engineers who design better software that 
is maintainable.
a113 10
   Finally, the object oriented analysis and design techniques were useful 
skills we learned.  Although we did not use an object oriented language like 
C++, the object oriented analysis techniques helped us to think about certain 
aspects of the xplan project such as the database portion.  If a user wanted 
to extend xplan, the database and graphical user interface are highly coupled.
Thus, more advanced features using object oriented methods could be designed
and then added to xplan by modifying the graphical user interface and call
back functions. The object oriented methods we learned in CPS 470 taught us
how to design software in a modular way so that it's code can be reused and 
the addition of future enhancements can be accommodated.
d117 11
a127 10
  In the course of designing and implementing xplan,  we learned how to use 
several tools that are useful for software development.  For example, our 
programming skills utilizing C and Unix improved, because the xplan project 
was a large piece of software.  The processes of configuration management 
using RCS was a good experience because it kept track of various stages of 
design development in the group in a consistent way.  The OpenWindows 
Developer Guide 3.0 was a good CASE tool to learn, because many useful 
applications utilizing C, Unix, and X Windows can have useful and complex 
Graphical User Interfaces developed quickly and efficiently.  LaTeX was a good
document processing system to use, because it facilitated writing large
d129 6
a134 11
equations, postscript figures, GUI screen dumps, and diagrams.  Flex and Bison
were used for inputing files to xplan. We also used several other useful tools
such as the emacs editor, vi, xfig, the dbx debugger, etc... Furthermore, on 
important tool we learned and worked with was MS Project.  In addition to
learning how to use MS Project for business applications, we learned the 
process of critically evaluating a competitors piece of software and designing
a different piece of software to perform the same function, but provide the 
user better features.  That is a good academic simulation of a real industry
experience.  Finally, it was a good experience designing and implementing 
xplan with the tools available to us in CPS470 because they are the same tools
that are used in industry.
@
