%\documentstyle[landscape,fleqn,a4j,12pt,epsf]{jarticle}
\documentstyle[12pt,eclepsf]{article}

\textheight 260mm
\topmargin -10mm
\textwidth 180mm
\oddsidemargin -7mm

\pagestyle{myheadings}
\markright{(Software Engineering)}

\begin{document}
\begin{LARGE}


%% ========== title ==========

\vspace*{.6in}
\begin{center}
\begin{Huge}
\noindent
{\bf Software Engineering}\\
\end{Huge}

\vspace{1in}
Dokuz Eyl\"{u}l University \\
%%Information Science Department \\
14 March -- 26 May, 2000\\
\end{center}

%========== Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 1 \\
\hspace*{1in}\\
\hspace*{1in}Introduction
\end{Huge}


% ========== lecture will be based on the book: ==========
\clearpage
\noindent
$\Box$ {\bf This lecture will be based on the book:}\\
\begin{itemize}
\item S. L. Pfleeger:
   \begin{itemize}
   \item[]{\it Software Engineering: Theory and practice.}
   \item[] Prentice Hall, 1999.
   \end{itemize}
\end{itemize}


%% ========== Contents ==========
\clearpage
\noindent
$\Box$ {\bf Contents:}\\

\begin{itemize}
\item [ 1.] What is Software Engineering?
\item [ 2.] Why Software Engineering?
\item []
\item [ 3.] Planning and Managing the Project.
\item [ 4.] Capturing the Requirement.
\item [ 5.] Designing the System. 
\item [ 6.] Writing the Programs. 
\item [ 7.] Testing the Programs. 
\item [ 8.] Testing the System. 
\item [ 9.] Delivering the System. 
\item[]
\item [10.] Evaluating Products. 
\item [11.] Improving Processes.
\end{itemize}

%% ========== what is software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf What is Software Engineering?}\\

\begin{itemize}
\item An engineering that helps us 
   \begin{itemize}
   \item[] to design \& develop ``{\it high quality software.}''\\
   \end{itemize}
\item[]
\item What then is a ``{\it high quality software}?''
   \begin{itemize}
   \item more efficient;
   \item more precise;
   \item easier to modify;
   \item easier to use;
   \item easier to understand.\\
   \end{itemize}
\item[]
\item The term ``{\it Software Engineering}'' was first used \\
      in 1968 at a NATO conference.       
\end{itemize}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Why Software Engineering?}\\

\hspace*{1in}\\

\begin{itemize}
\item Badly developed system\\ 
      {\bf would cost more} than properly developed.
\item[]
\item Improperly designed or programmed software \\
      {\bf would threaten our lives.}
\item[]
\item Sometimes it is\\ 
      {\bf impossible to test.}\\
\end{itemize}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 1-1:}\\
\begin{center}
In 1985, Internal Revenue Service in US \\
hired Sperry Corporation to build \\
an automated federal income tax form processing system \\
{\bf \$103,000,000}\\

$\Downarrow$\\

proved inadequate \\
({\bf running cost was nearly twice} what was expected)\\

$\Downarrow$\\

had to be replaced soon \\
extra {\bf \$90,000,000} was needed! \\

$\Downarrow$\\

%furthermore 
a delay to return refunds to the taxpayers caused
{\bf \$40,200,000} (interest) \&
{\bf \$22,300,000} (overtime wages) \\
\end{center}

%\hspace*{1in}\\

\begin{flushright}
\begin {large}
K. Sawyer (1985) ``The mess at the IRS.''\\
Washington Post National Weekly Edition,\\
November 11, pp.6--7. \\
\end{large}
\end{flushright}


\begin{center}
$\Downarrow$\\

In 1996, it had not improved yet \\

\hspace*{1in}\\

Congressman J Lightfoot's words: \\ 
``{\bf A \$4-billion fiasco} \\
that is floundering because of inadequate planning.''
\end{center}

\begin{flushright}
\begin {large}
Los Angels Times, March 29 (1996)
\end{large}
\end{flushright}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 1-2:}\\
\begin{center}
On June 4 1996, \\

\hspace*{1in}\\

the Ariane-5\\
(a space rocket belonging to the European Space Agency)\\

\hspace*{1in}\\

veered off course 40 seconds after being launched and performed perfectly,\\

\hspace*{1in}\\

due to an {\it error} of the embedded software.\\

\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\

It was destroyed by remote control.\\

\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\

The total cost of the disaster was {\bf \$500,000,000}.\\

\end{center}

\hspace*{1in}\\
\hspace*{1in}\\

\begin{flushright}
\begin {large}
J. L. Lions et al.\ (1996) \\
``Ariane 5 Flight Failure.''\\
Report by the inquiry board,\\
European Space Agency.
\end{large}
\end{flushright}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 1-3:}\\

\begin{itemize}
\item Y2K
\end{itemize}

%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 2-1:}\\
\begin{center}
THERAC-25\\
(a radiation therapy machine)\\

\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\

the software designers had not anticipated\\
the use of ``arrow keys'' in non standard way\\

\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\

issued a highly concentrated dose of radiation\\
when low levels were intended.

\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\

killed several patients.
\end{center}

%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 2-2:}\\
\begin{center}
In December 1995, \\

\hspace*{1in}\\

An American Airline's jet\\

\hspace*{1in}\\

crashed in Colombia;

\hspace*{1in}\\

{\bf killed all but 4 of the 163 people aboard.}

\hspace*{1in}\\
$\Uparrow$\\
\hspace*{1in}\\

One-letter code for ``Cali'' was the same as the one for ``Bogota''\\
132 miles in the opposite direction.
\end{center}

\hspace*{1in}\\
\hspace*{1in}\\

\begin{flushright}
\begin {large}
Washington Post,\\ 
August 24, 1996 \\
(Associated Press)
\end{large}
\end{flushright}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 2-3:}\\
\begin{center}
In 1996, \\

\hspace*{1in}\\

Two police officers \\
in the Lothian and Borders region of Scotland \\
were using a radar gun \\
to identify speeding motorists on the Berwickshire moors.\\

\hspace*{1in}\\

Suddenly, their radar gun locked up, \\
with a speed indication of over 300 miles per hour.\\

\hspace*{1in}\\

Seconds later, a low-flying Harrier jet flew by.\\

\hspace*{1in}\\

The Harrier's target seeker had recognized the radar \\
and thought it to belong to an enemy.\\

\hspace*{1in}\\

(Fortunately, the Harrier was operating unarmed, \\
since normal behavior would have triggered \\
only an automated retaliatory missile!)\\

\hspace*{1in}\\

\end{center}

\hspace*{1in}\\
\hspace*{1in}\\

\begin{flushright}
\begin {large}
Pilot magazine, 1996
\end{large}
\end{flushright}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Example 3:}\\
\begin{itemize}
\item Strategic Defense Initiative (US)
   \begin{itemize}
   \item proposed by President Regan (1985).
   \item at least 10,000,000 lines of code.
   \end{itemize}
\item[]
\item Space Shuttle (US)
   \begin{itemize}
   \item computers on the ground $\Rightarrow$ 3,000,000,000 lines of code. 
   \item shuttle $\Rightarrow$ 100,000 lines of code.\ \footnote{B. Rensburger (1985)
         ``The Software is too Hard. Washington Post National Weekly Edition,
           November 11, pp.10-11.''}\\
   \end{itemize}
\end{itemize}

\begin{center}
$\Downarrow$\\
\hspace*{1in}\\
no way of testing the code, line by line.\\
\end{center}

\begin{itemize}
\item[]
\item[]
\item Atomic Power Plant\\
\end{itemize}

\begin{center}
$\Downarrow$\\
\hspace*{1in}\\
$10^9$ safety critical
\end{center}


%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Safety Critical:}\\

\begin{center}

System in which {\it failure} poses a threat to life or health \\

should have a reliability of at least $10^9$ \\

\hspace*{1in}\\
$\Downarrow$ \\
\hspace*{1in}\\

System can fail no more often than \\
once in $10^9$ hours of operation.

\end{center}

%% ========== why software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf Fault, Error, and Failure}\\

\begin{itemize}
\item A {\bf fault} occurs when a human makes a mistake, called {\bf error},
      in performing some software activity.
\item[]
\item A {\bf failure} is a departure from the system's required behavior.
\end{itemize}


%% ========== Wasserman's discipline of Software Engineering ==========
\clearpage
\noindent
$\Box$ {\bf Wasserman's discipline of Software Engineering:}\\

\begin{itemize}
\item A. I. Wasserman:
   \begin{itemize}
   \item[] ''Toward a Discipline of Software Engineering.''
   \item[] {\it Software}, Vol.10, No.6, pp23--31, IEEE, 1996.\\
   \end{itemize}
\item[]
\end{itemize}

\begin{center}
$\Downarrow$\\
\hspace*{1in}\\
\hspace*{1in}\\
Why software development today is different \\ from 10 or 20 years ago.
\end{center}


%% ========== reference ==========
\clearpage
\noindent
$\Box$ {\bf 7 factors that have changed software engineering:}\\
\hspace*{.3in}Wasserman (1996) \\

\begin{itemize}
\item criticality of {\it time}
\item lower hardware costs and\\ greater development and maintenance cost
\item powerful PC
\item networking
\item object-oriented technology
\item GUI
\item unpredictability of {\ waterfall model}\\
\end{itemize}


\begin{center}
\hspace*{1in}\\
\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\
\hspace*{1in}\\
Shift from the traditional ``Waterfall Model''\\ 
to the modern ones.
\end{center}

%% === Wasserman's discipline of Software Engineering ===
\clearpage
\noindent
$\Box$ {\bf Wasserman's discipline of
                     Software Engineering:}\\

\begin{itemize}
\item try {\it abstraction} of the problem
\item build {\it models}
\item produce {\it prototyping}
\item make {\it architecture} of a system clear
\item evaluate {\it developing process}
\item make it possible to {\it reuse} items from previous development
\item {\it quantify} improvement
\item establish tools
\end{itemize}

%========== Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 2 \\
\hspace*{1in}\\
\hspace*{1in}Planning and Managing the Project 
\end{Huge}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Planning the Project:}\\

\begin{center}
$\bullet$ How much the project will cost \\
\hspace*{1in}\\
and \\
\hspace*{1in}\\
$\bullet$ how long the project will take? \\
\end{center}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Divide and Conquer Strategy:}\\
(Analysis and Synthesis)\\

\begin{itemize}
\item[(1)] Break the problem into its component parts.
\item[(2)] Devise a solution for each part.
\item[(3)] Put the pieces together to form a coherent whole.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf To apply the strategy to planing the project:}\\

\begin{center}
$\bullet$ By examining the project carefully \\

\hspace*{1in}\\
$\Downarrow$ \\
\hspace*{1in}\\

$\bullet$ we can separate development into a succession of {\bf phases.}\\

\hspace*{1in}\\
$\Downarrow$ \\
\hspace*{1in}\\

$\bullet$ Each phase is composed of {\bf steps.}\\
\hspace*{1in}\\
$\Downarrow$ \\
\hspace*{1in}\\
$\bullet$ Each step can be subdivided further into {\bf activities.}\\
\end{center}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent

$\Box$ {\bf Process Model:}\\

\begin{center}
A {\bf process model} also provides \\
\hspace*{1in}\\
a view of the {\bf phases} and {\bf steps.}\\
\hspace*{1in}\\
\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\
\hspace*{1in}\\
We will be back this issue later in detail.
\end{center}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Activity and Milestone}\\

\begin{itemize}
\item[]
\item Developers can point to \\
   \begin{itemize}
   \item {\bf activities}
      \begin{itemize}
      \item to show what work is under way.
      \end{itemize}   
   \item[]
   \item {\bf milestones} 
      \begin{itemize}
      \item to show what works have been completed.
      \end{itemize}
   \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Activity and Milestone?}\\

\begin{itemize}
\item A {\bf activity:} 
   \begin{itemize}
   \item a part of the project that takes place \\
         {\it over a period of time.}
   \end{itemize}
\item[]
\item {\bf milestone:} 
   \begin{itemize}
   \item the completion of an activity: \\
         {\it a particular point in time.}
   \item[]
   \item indicates (to developers and customers) that\\
         a measurable level of progress has been made, \\
         e.g.,
      \begin{itemize}
      \item completion of the user's manual;
      \item performance of a given set of calculations;
      \item demonstration of the system's ability.   
      \end{itemize}
   \end{itemize}
\end{itemize}

\hspace*{1in}\\
\hspace*{1in}\\
Note:\\
Each {\bf activity} is characterized by a {milestone.}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf 4 parameters to describe an activity}\\

\begin{itemize}
\item {\bf precursor:} 
   \begin{itemize}
   \item an event (or set of events) that must occur 
         before the activity starts, or
   \item a conditions that allows the activity to start
   \end{itemize}
\item[]
\item {\bf duration:} 
   \begin{itemize}
   \item time needed to complete the activity \\
   \end{itemize}
\item[]
\item {\bf due date:} 
   \begin{itemize}
   \item date by which the activity must be completed \\
   \end{itemize}
\item[]
\item {\bf end point:} 
   \begin{itemize}
   \item a milestone or {\it deliverable}
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf deliverable:}\\

\begin{itemize}
\item {\bf documents} 
\item {\bf demonstrations of:} 
   \begin{itemize}
   \item function
   \item subsystems
   \item accuracy
   \item reliability
   \item security
   \item performance
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Activity Graph:}\\

\begin{itemize}
\item relationships among activities expressed\\ 
      by the 4 parameters.
   \begin{itemize}
   \item node $\Rightarrow$ the project milestones
   \item arch $\Rightarrow$ activities
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=activity-graph.eps,width=16cm,height=20cm}
 \end{center}
\end{figure}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Slack Time:}\\

\noindent
\{Slack Time\} \\
\indent
= \{Available Time\} -- \{Actual Time\}\\

\hspace*{2in} or \\

= \{The latest time an activity may begin 
    without delaying the project\}
 -- \{The earliest time the activity may begin\}\\

\hspace*{1in}\\

\noindent
NOTE:\\
\indent
the longest path $\Leftarrow$ \{Slack time\} = 0  


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=activity-2.eps,width=16cm,height=10cm}
 \end{center}
\end{figure}


%% ========== Planning and Managing the Project ==========
\clearpage
\hspace*{1in}\\
\hspace*{1in}\\
\begin{center}
Since {\bf critical path} has no slack,\\
\hspace*{1in}\\
\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\
\hspace*{1in}\\
there is {\it no margin for error.}\\
\hspace*{1in}\\
\hspace*{1in}\\
$\Downarrow$\\
\hspace*{1in}\\
\hspace*{1in}\\
Thus the {\bf activity graph} \\
helps us to understand \\
{\it the impact of a schedule slippage.}
\end{center}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf Critical Path Method} also\\
\begin{itemize}
\item[] shows us
   \begin{itemize}
   \item the minimum amount of time it will take to
         complete the project;
   \end{itemize}
\item[]
\item[] reveals
   \begin{itemize}
   \item activities that are most critical to completing
         the project on time.
   \end{itemize}
\end{itemize}

\hspace*{1in}\\

\noindent
NOTE:\\
\indent
There may be more than one critical path.  


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf The Longest Path}\\
\begin{itemize}
\item[-] has a slack of zero 
         for each of its nodes (activities);
\item[]
\item[-] determines whether or not the project is 
        on schedule.\\
\end{itemize}

\begin{center} $\Downarrow$ \\ \end{center}

\begin{itemize}
\item[]
\item That's why this is called the {\it critical path}.
\end{itemize}


%% koko
%% table


%% ========== what is software engineering? ==========
\clearpage

\noindent
$\Box$ {\bf The Shortest Path Algorithm.}\\

\noindent
Notation:\\
$S$: the node to start with, $T$: The goal;\\
$E(U)$: energy of node $U$ 
(the shortest distance from $S$)\\
$e(U)$: energy of node $U$\\
$-------------------------$ \\
\noindent
Step 1
   \begin{itemize}
   \item Assign energy zero to S: $E(S)=0$.
   \item Assign label $\infty$ to all nodes 
                    other than S: $e(S)= \infty$.
   \end{itemize}
\noindent
Step 2
   \begin{itemize}
   \item FOR each of the nodes $U_i$
                    that was already assigned an energy
      \begin{itemize}
      \item FOR each $V_j$ that are directly 
            reachable from $U_i$
         \begin{itemize}
            \item IF $E(U_i)+r(U_i,V_j)<e(W_j)$\\
                  THEN $e(V_j) = E(U_i)+r(U_i,V_j)$
         \end{itemize}   
      \item Find a minimum value of labels 
            among nodes that were not assigned an energy yet,
            and assign energy of that value to the point(s).
      \end{itemize}
   \end{itemize}
\noindent
Step 3
   \begin{itemize}
   \item Repeat step 2 until all nodes are assigned 
                    an energy.
   \end{itemize}
\noindent
Step 4
   \begin{itemize}
   \item Pick up arcs when $E(A)-E(B) = r(A,B)$
   \end{itemize}


%% ========== figure ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=shortest.eps,width=16cm,height=20cm}
 \end{center}
\end{figure}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf The above example is too simplified, however.}\\

\begin{itemize}
\item What happens if the activity graph has loops?
   \begin{itemize}
   \item[e.g.] requirements to be respecified
   \end{itemize}
\item[]
\item Durations are always clear to be exact?
  \begin{itemize}
  \item[$\rightarrow$]To each activity we can assign 
                      a probable duration according to 
                      some probability distribution, 
                      so that each activity has an expected 
                      value and a variance.
  \item[$\rightarrow$]{\it Gaussian distribution} 
                       instead of exact duration
  \item[$\rightarrow$]Program Evaluation and Review Technique
                      (PERT).
  \item[e.g.]Those activities most likely to 
                      be bottlenecks can be identified.
  \end{itemize}
      \begin{itemize}
      \item[*]  F. S. Hiller and G.J. Liberman (1967)\\
                {\it Introduction to Operations Research.}\\
                Holden-Day, San Francisco, US.
      \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf Exercise}\\

\begin{itemize}
\item [1] List its precursors and compute the activity's
          earliest start time, the latest one, and the slack
          time.
\item[]
\item [2] Find the critical Path.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Critical Path Method (CPM)} \\

\begin{itemize}
\item Who must wait for what \\ 
      as the project is being developed?
\item Which activities must be completed on schedule \\ 
      to avoid delay?
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Estimation:}\\

\begin{itemize}
\item Time (Schedule) Estimation
\item Cost Estimation
\item Effort Estimation
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

affect {\it resource allocation} and 
       {\it project feasibility};

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

must be done {\it as early as possible};

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

must be repeated throughout the project.

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Cost Estimation:}\\

\begin{itemize}
\item How much the project is likely to cost?\\
   \begin{itemize}
   \item Cost overruns can cause customers 
         to cancel projects.
   \item[]
   \item Cost underestimate can force a project team 
         to invest much of their time without financial 
         compensation.
   \item[]
   \item A good cost estimate helps the project manager 
         to know how many developers will be required 
         and to arrange for the appropriate staff to be 
         available when they are needed.
   \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Cost for what?}\\

\begin{itemize}
\item[{\bf (1)}] Facilities cost for:
   \begin{itemize}
   \item items that provide the physical environment 
         in which the developers will work
         $\Rightarrow$ well-understood.
      \begin{itemize}
      \item hardware, space, furniture, telephones, modems,
            heating and air-conditioning, cables, disks, 
            paper, pens, photocopiers, etc.
      \end{itemize}
   \item[]
   \item new environment to be created 
         $\Rightarrow$ difficult to estimate.
      \begin{itemize}
      \item a security vault, a raised floor,
            temperature or humidity controls, or
            special furniture.
      \end{itemize}
   \item[]
   \item other hidden cost
      \begin{itemize}
      \item e.g., a programmer needs a space 
         \begin{itemize}
         \item a minimum of 100 square feet of floor\\
               with 30 square feet of work space;
         \item quiet, free from telephone call, 
               uninvited visitors,
         \item in order to be effective.
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage

\begin{itemize}
\item[{\bf (2)}] Software and tools to support 
                 development efforts.
   \begin{itemize}
   \item to design and code the system;
   \item to capture requirements;
   \item to organize documentation;
   \item to test the code;
   \item to keep track of changes;
   \item to generate test data;
   \item to support group meetings;
   \item and more.     
   \end{itemize}
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ called\\

{\bf Computer-aided Software Engineering (CASE)}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Effort Estimation:}\\

\begin{itemize}
\item How many {\it staff-days} of effort will be required 
      to complete the project?
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

Cost component with the greatest degree of uncertainty.


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
In a project,

\begin{itemize}
\item work style
\item how team members are organized
\item ability
\item interest
\item experience
\item training
\item other employee characteristics \\
\end{itemize}

\noindent
$\Rightarrow$ 
affect the time it takes to complete a task.\\

\noindent
More over, when a group of workers must 
communicate and consult with one another,

\begin{itemize}
\item {\bf effort}
\end{itemize}

\noindent
$\Rightarrow$ is required to shorten the time 
for meeting, documentation, training and so on.

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf How can we estimate it?}\\

\begin{itemize}
\item Judgment by Experts
\item Algorithmic Way
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Expert Judgment:}\\

\begin{itemize}
\item informal technique that depends on
   \begin{itemize}
   \item competence
   \item experience
   \item objectivity
   \item perception of estimator
   \end{itemize}
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ 
\hspace{.4in}Efforts to be less informal.\\

\begin{itemize}
\item[(1)] Using analogy of the past
\item[(2)] Delphi Technique
\item[(3)] Software Cost(Effort) Matrix
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf (1) Analogy from previous experiences:}\\

\begin{itemize}
\item ask several experts to estimate
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

``This team is similar to that team, 
  so the point is $\cdots$''

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

\begin{itemize}
\item[$\cdot$] a pessimistic prediction $\Rightarrow (x)$ 
\item[$\cdot$] an optimistic one        $\Rightarrow (y)$ 
\item[$\cdot$] a most likely guess      $\Rightarrow (z)$ 
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

\hspace*{.2in}$(x+4y+z)/6$\\

\noindent
(the means of the beta probability distribution)


\hspace{1in}\\
\hspace{1in}\\
\hspace{1in}\\

\noindent
This relies too much on the experts' ability
to determine which projects are similar and in what ways.

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf (2) Delphi Technique:}\\

\begin{itemize}
\item Experts are asked to make predictions {\it secretly.}
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

Average estimate is calculated and presented to them.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

Again, they are asked to revise his/her estimate.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

The average when no one revised any more is adopted.

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf (2+1) Variations of Delphi:}\\

\begin{itemize}
\item They discuss when their estimates are feed-backed.
\item[]
\item Points of each expert are circulated anonymously\\
      among them.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf (3) Software Cost Matrix:}
        \footnote{R.W.Wolverton (1974)
         ``The Cost of Developing Large-scale Software.''
           IEEE Computer, 23(9) pp.8--24.}\\

\begin{itemize}
\item row $\Rightarrow$ The type of software.
   \begin{itemize}
   \item Control
   \item Input/Output
   \item Pre/Post processor
   \item Algorithm
   \item Data management
   \item etc.
   \end{itemize}
\item[]
\item column $\Rightarrow$ difficulty
   \begin{itemize}
   \item Old (O) or New (N) ?
   \item Easy (E), Modest (M), or Hard (H)?
   \end{itemize}
\item[]
\item entry $\Rightarrow$ cost per line of code
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\begin{table}[hbtp]
\begin{center}
\begin{tabular}{c c c c c c c} \hline \hline
\multicolumn{1}{c}{type of software} & 
\multicolumn{6}{c}{Difficulty} \\
\cline{2-7} 
& OE  & OM & OH & NE & NM & NH        \\ \hline
Control            & 21 & 27 & 30 & 33 & 40 & 49 \\ 
Input/output       & 17 & 24 & 27 & 28 & 35 & 43 \\
Pre/post processor & 16 & 23 & 26 & 28 & 34 & 42 \\
Algorithm          & 15 & 20 & 22 & 25 & 30 & 35 \\
Data management    & 24 & 31 & 35 & 37 & 46 & 57 \\
\hline \hline
\end{tabular} 
\end{center}
\end{table}

\hspace*{1in}\\

\begin{center}
$\Downarrow$\\
\hspace*{1in}\\
Though this example is based on specific company\\ 
(TRW: Software developing company in US),\\
\hspace*{1in}\\
$\Downarrow$\\ 
\hspace*{1in}\\
applicable to your environment.
\end{center}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Example of using software cost matrix:}\\


\begin{itemize}
\item A system with three modules.
   \begin{itemize}
   \item Input/Output module 
         that is old and easy (100 lines).
   \item Algorithm module 
         that is new and hard (200 lines).
   \item Data management module
         that is old and moderate (100 lines).
   \end{itemize}
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

$100 \times 17 + 200 \times 35 + 100 \times 31 = 11.800 $  

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ Pros and cons:\\

\begin{itemize}
\item Subjective;
\item[]
\item Non-linearity
   \begin{itemize}
   \item Two people cannot produce code twice as fast as one,
         but extra time may be needed.
      \begin{itemize}
      \item communication
      \item coordination
      \item accommodation of differences 
            in interest, ability, experience, etc.\\
      \end{itemize}
   \end{itemize}
\item Too dependent on data;\\
\item Too simple.
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

{\bf Algorithmic Method}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ {\bf Algorithmic Method:}\\
\hspace{1in}\\

\noindent
Relationship between effort and the factors 
that influence it.\\

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\
\hspace{1in}\\

\noindent
Effort $E$ is represented as a function of these factors:\\


$E = f(x_1, x_2, \cdots, x_n).$ \\

\noindent
where, e.g.,\\

\indent
$x_1 = $ project size\\
\indent
$x_2 = $ experience\\
\indent
$x_3 = $ application type\\
\indent
$\cdots\cdots$


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ Most of the models acknowledge that \\

\noindent
project size $(S)$ is most influential.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

$E = (a + b S^c)\cdot m(\mbox{\bf X}).$ \\

\noindent
where\\

$\mbox{\bf X} = (x_1, x_2, \cdots, x_n).$ \\


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
(1) {\bf Walston et al.\ (1977)}
\footnote{Walston et al.\ (1977) 
``A Method of Programming Measurement and Estimation.``
IBM Systems Journal, 16(1) pp54--73.}\\
\hspace*{2in}...One of the first of such models.\\

$E = 5.25S^{0.91}\cdot m(\mbox{\bf X}).$ \\

\noindent
Size was measured as lines of code including comments\\
(if they did not exceed 50\% of the total lines.)

\hspace{1in}\\
\hspace*{1in}$\Uparrow$ 
\hspace{.4in}$m(\mbox{\bf X})$ is modified by 29 factors\\

\begin{itemize}
\item[1.] Number of pages of documentation 
         per 1000 lines of codes.
\item[2.] Ratio of average staff size to project duration 
         (people per month)
\item[3.] Previous experience with applications 
         of similar size and complexity
\item[4.] Previous experience with the programming language
\item[]$\cdots$
\item[29.]Overall complexity of code
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\hspace{1in}\\
\hspace{1in}\\

\noindent
Walston et al.'s methods was applied to IBM's\\

\begin{itemize}
\item the data built systems
\item with 4000 -- 467,000 lines
\item written in 28 different languages
\item on 66 computers.
\end{itemize}

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

12 -- 11,758 person-month effort

%% ========== Planning and Managing the Project ==========
\clearpage
\hspace{1in}\\
\hspace{1in}\\

\noindent
In conclusion \\

\begin{displaymath}
E = 5.25S^{0.91}\cdot m(\mbox{\bf X}).\\
\end{displaymath}

\noindent
where\\

\begin{displaymath}
m(\mbox{\bf X}) = \sum_{i=1}^{29} {c_i \cdot w_i},
\end{displaymath}

\hspace*{1in}\\
\noindent
where\\

\begin{displaymath}
c_i = \left\{ 
   \begin{array}{rl}
   1 \hspace{.3in} & 
         \mbox{if the factor increases productivity}, \\ 
   0 \hspace{.3in} & \mbox{if no effect}, \\ 
  -1 \hspace{.3in} & \mbox{if it decreases productivity}, \\ 
\end{array} \right.
\end{displaymath}

\hspace*{1in}\\
\noindent
and $w_i$ represents importance of each factor, i.e.,

\begin{displaymath}
\sum_{i=1}^{29} {w_i}= 1
\end{displaymath}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
(2) {\bf Bailey et al.\ (1981)}
\footnote{Bailey et al.\ (1977) 
``A meta-model for Software Development Resource 
  Expenditures.''
Proceedings of the International Conference on 
Software Engineering. pp.107-116.}\\

\noindent
proposed a {\it meta-model} for building estimation equation
that reflects your own company's characteristics.\\

$E = 5.5 + 0.73 \cdot X^{0.91}\cdot m(\mbox{\bf X}),$ \\

\noindent
where $m(\mbox{\bf X})$ is modified with
\begin{itemize}
\item[-] methodology (9 items; 45 points)
\item[-] complexity (7 items; 35 points) 
\item[-] experience (5 items; 25 points)
\end{itemize}
judged by the project manager.\\

\hspace*{1in}\\
\noindent
They demonstrated the model using a data base of 
18 projects written in Fortran at NASA.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ after minimization of the error \\

it was found that the result was very accurate.

%% ========== Planning and Managing the Project ==========
\clearpage
\hspace{1in}\\
\hspace{1in}\\

\noindent
Adjustment is as follows:

\begin{displaymath}
m(\mbox{\bf X}) = \left\{ 
   \begin{array}{ll}
   R         \hspace{.3in} & \mbox{if} R \ge  1, \\ 
   1/(2-1/R) \hspace{.3in} & \mbox{if} R <    1, \\ 
\end{array} \right.
\end{displaymath}

\hspace*{1in}\\

\noindent
where
\begin{displaymath}
R = \frac {\mbox{actual effort}}{\mbox{predicted effort}}.
\end{displaymath}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
(3) {\bf Boehm (1981)}
\footnote{B.W.Boehm (1981) Software Engineering Economics.
Plentice Hall.}\\

$E = bS^c \dot m(\mbox{\bf X}).$ \\

\noindent
Modification is somewhat more sophisticated, dividing
development into 3 periods.


%% ========== Planning and Managing the Project ==========
\clearpage
\begin{itemize}
\item Stage 1
   \begin{itemize}
   \item the model acknowledges that 
         lines of code are impossible to know; 
   \item instead, they use  {\it number of server and client 
         data tables}, and the percentage of {\it reusable 
         parts from previous projects}
         ({\it object points)}.
   \item $c$ is set to be 1.
   \end{itemize}
\item Stage 2 
   \begin{itemize}
   \item still not enough information as to size;
   \item size is estimated by degree of 
      \begin{itemize}
      \item reuse
      \item breakage
      \item maintenance
      \end{itemize}
      ({\it function-point calculation})
   \item $c \in [1.01, 1.26]$ depending on
      \begin{itemize}
      \item the degree of novelty of the system 
%     \item conformity  
      \item early architecture and risk resolution 
      \item team cohesion
      \item process maturity.
      \end{itemize}
   \end{itemize}
\item Stage 3 
   \begin{itemize}
      \item sizing can be done in terms of 
            {\it line of codes.}
      \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Management} \\
\begin{itemize}
\item What is a risk?
   \begin{itemize}
   \item An unwelcome events during development/maintenance.
   \end{itemize}
\item[]
\item Risk Management.
   \begin{itemize}
   \item Plans to avoid, or if inevitable, minimize them.
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Impact} \\
\hspace*{2in}... A loss associated with a risk.\\

\begin{itemize}
\item A loss of time, quality, money, control, 
      understanding, etc.\\
\end{itemize}

\noindent
e.g.,\\
\noindent
A dramatical requirement change after the design is done.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$  What happens?\\

\begin{itemize}
\item[-] loss of control and understanding\\
         if the new requirements are unfamiliar.
\item[-] losses of time and money\\
         if the design is not flexible.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Probability} \\
\hspace*{2in}... the likelihood that a risk will occur.\\

\noindent
e.g.,\\
\noindent
When a system that is being developed on one machine\\
\noindent
will be ported to another when the system is fully tested.

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ \\

\noindent
The likelihood that the new machine will not delivered\\
by the vendor

\hspace{1in}\\
\hspace{1in}\\

\noindent
Note:\\
probability = 1 \\
\hspace*{1in}$\Downarrow$\\
\noindent
the risk is called a {\bf problem}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Control} \\
\begin{flushright}
... What we can do to minimize or avoid the impact?\\
\end{flushright}

\hspace{1in}\\

\noindent
$\bullet$ A set of actions 
           taken to reduce or eliminate a risk.\\

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ e.g.,\\
\hspace{1in}\\

\noindent
- If the requirements may change after design,\\
\begin{itemize}
\item[$\Rightarrow$] we should create a flexible design.\\
\end{itemize}

\hspace{1in}\\

\noindent
- If the 2nd machine is not ready,\\
\begin{itemize}
\item[$\Rightarrow$] we may identify other models 
                     that have the same functionality 
                     and performance and run the software 
                     until the new model is delivered.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Quantification of the effect of a risk.} \\

\hspace{1in}\\

\noindent
$\bullet$ \{Risk Impact\} $\times$ \{Risk Probability\}
$\Rightarrow$ \{Risk Exposure\}\\

\hspace{1in}\\
\hspace*{1in}$\Downarrow$ e.g.,\\
\hspace{1in}\\

\begin{itemize}
\item[-] The cost to redesign to new requirements 
         = \$50,000; 
\item[-] The likelihood of the requirements change 
         after design = 0.3.\\
\end{itemize}

%\hspace{1in}\\
\hspace*{1in}$\Downarrow$ then\\
%\hspace{1in}\\

Risk Exposure = \$ 15,000.\\

\hspace{1in}\\

\noindent
Note:\\
Risk Probability and risk impact can change over time.\\

\hspace*{1in}$\Downarrow$ \\

\noindent
The project manager should track them over time.


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Two major sources of risk.} \\

\begin{itemize}
\item Generic risks
   \begin{itemize}
   \item misunderstanding the requirements
   \item losing key personnel
   \item insufficient time for testing
   \item etc.
   \end{itemize}
\item[]
\item Project specific risks
   \begin{itemize}
   \item a software needed for the development \\
         will not be ready on time.
   \item etc.
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Management Activities.} \\

\begin{itemize}
\item Risk Assessment
   \begin{itemize}
   \item understanding what may occur 
         during development and maintenance.
   \end{itemize}
\item[]
\item Risk Control
   \begin{itemize}
   \item[] (later in detail)
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Assessment.} \\
\hspace*{1in}\\
\begin{itemize}
\item Identify the risks\\
   \begin{itemize}
   \item Check list
      \begin{itemize}
      \item If the system you are building is similar 
            to previous one, you have a checklist of 
            problems that may occur;
      \item If it's new, you may augment the check list 
            with analysis.
      \end{itemize}
   \item[]
   \item Decomposition
      \begin{itemize}
      \item By decompose the process into small pieces,
            you may anticipate problems that may arise.
      \end{itemize}
   \item[]
   \item Assumption and Decision analysis
      \begin{itemize}
      \item Analyze your assumptions and 
            decisions you made, as to:
         \begin{itemize}
         \item how the project will be done;
         \item who will do it;
         \item with what resources.
         \item[] (each one is assessed 
                to know risks involved.)         
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Assessment.} \hfill (cont'd)\\

\begin{itemize}
\item Analyze them.
   \begin{itemize}
   \item By identifying them after identification,
         you can understand:
      \begin{itemize}
      \item when, why and where they might occur.
      \end{itemize}
   \item[]
   \item Many techniques to enhance understanding
      \begin{itemize}
      \item system dynamics models
      \item cost models
      \item performance models
      \item network analysis
      \item decision analysis
      \item quality risk factor analysis
      \end{itemize}
\item[]
\item Prioritize them.
    \begin{itemize}
    \item enables limited resources 
          to be given the most threatening one.
    \end{itemize}
       \begin{itemize}
       \item by Risk Exposure
       \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Risk Control} \\

{\it control} instead of {\it eliminate}\\
\hspace*{1in}$\Downarrow$ i.e.,\\
\indent
{\it minimize} the risk\\

\begin{itemize}
\item Risk reduction
   \begin{itemize}
   \item avoiding the risk
      \begin{itemize}
      \item by changing requirements
      \end{itemize}
   \item[]
   \item transferring
      \begin{itemize}
      \item by allocating risks to other systems
      \item by buying insurance to cover financial loss
      \end{itemize}
   \item[]
   \item assuming the risk
      \begin{itemize}
      \item by accepting it and controlling it\\
            with the project's resources.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ The cost of reducing the risk.} \\

\noindent
$\{\mbox{risk leverage\}} = $\\
\begin{displaymath}
\frac{\{\mbox{risk exposure before reduction \}} - 
      \{\mbox{the one after reduction\}}}
     {\{\mbox{cost of risk reduction\}}}
\end{displaymath}

\hspace*{1in}\\
\hspace*{1in}\\

\noindent
$\bullet$ If the value is not high enough 
          to justify the action,\\

\hspace*{1in}$\Downarrow$ then\\

\noindent
use other less costly or more effective reduction techniques.


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Summary: Risk Management} \\
\begin{itemize}
\item Risk Management
   \begin{itemize}
   \item Risk Assesment
      \begin{itemize}
      \item Risk Identification
         \begin{itemize}
         \item Check List
         \item Decomposition
         \item Assumption Analysis
         \item Dicision Analysis
         \end{itemize}
      \item Risk Analysis
         \begin{itemize}
         \item System Dynamics
         \item Performance Models
         \item Cost Models
         \item Network Analysis
         \item Quality Risk Factor Analysis
         \end{itemize}
      \item Risk Prioritization
         \begin{itemize}
         \item Risk Exposure
         \item Risk Reduction
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
\begin{itemize}
\item Risk Management (cont'd)
   \begin{itemize}
   \item Risk Control
      \begin{itemize}
      \item Risk Reduction
         \begin{itemize}
         \item Buying Information
         \item Risk Avoidance
         \item Risk Transfer
         \item Risk Reduction Leverage
         \item Development Process
         \end{itemize}
      \item Risk Management Planning
         \begin{itemize}
         \item Risk Element Planning
         \item Risk Plan Integlation
         \end{itemize}
      \item Risk Resolutions
         \begin{itemize}
         \item Risk Mitigation
         \item Risk Monitering and Reporting
         \item Risk Reassessment
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}


%========== Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 3 \\
\hspace*{1in}\\
\hspace*{1in}Capturing the Requirements
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\begin{itemize}
\item Chap.\ 2 Planning (How we plan a project?)\\
      (Preparation)
   \begin{itemize}
   \item How long will it take?
   \item How much will it cost?
   \item What resorece are needed?
   \end{itemize}
\item[]
\item Chap.\ 3 Capturing Requirement\\
      (We now start)
   \begin{itemize}
   \item How to capture? (Elicitation)
   \item How to document?
   \item How to review? (Verification, Validation)
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage 
{\bf $\Box$ Capturing the Requirements} \\

\hspace*{1in}\\
\hspace*{1in}\\

\noindent
Requirement $\Leftarrow$ subscribed by customer to developer.

\hspace*{1in}\\
\hspace*{1in}\\

\noindent
Captureing it $\Rightarrow$ Understanding of what the customers\\
\hspace*{2.05in}and users expect the system to do.



%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Contents} \\

\begin{itemize}
\item Two types of requirement.
   \begin{itemize}
   \item Functional \& Non-functional
   \end{itemize}
\item[]
\item How to document them.
   \begin{itemize}
   \item Static descriptions \& Dynamic ones
   \end{itemize}
\item[]
\item How to review them for 
   \begin{itemize}
   \item Correctness, Completness and Consistency.
   \end{itemize}
\item[]
\item Requirements specification.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Requirenent} \\

\hspace*{1in}$\Downarrow$ is
\begin{itemize}
\item[] a description 
        of something the system is capable of doing 
        in order to fulfil the system's purpose.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ A survey by Standish group}\footnote{The
Standish Group: The CHAOS Report (1994);
The Scope of Software Engineering. 
Software Engineering 2(2), pp.126--137.}\\

\noindent
(over 350 companies about their 
 over 8000 software projects.)\\

\begin{itemize}
\item 31\% projects were canceled before 
        they were copmleted.
%%\item Only 9\% in large companies and 
%%      16\% in small companies were delivered
%%      on time and cost what they were budgeted.
\end{itemize}

\hspace*{1in}\\
\noindent
Why?
\begin{itemize}
\item[1.] imcomplete requirements (13.1\%)
\item[2.] lack of user involvement (12.4\%)
\item[3.] lack of resorces (10.6\%)
\item[4.] unrealistic expectations (9.9\%)
\item[5.] lack of executive support (9.3\%)
\item[6.] changing requirements and specifications(8.7\%)
\item[7.] lack of planning (8.1\%)
\item[8.] system no longer needed (7.5\%)
\end{itemize}



%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ A survey by Standish group \hfill Cont'd \\


To find and fix a requirement problem, it costs:\\

\begin{table}[hbtp]
\begin{center}
\begin{tabular}{l r c l} 
$\cdot$ & \$ 1   & $\Leftarrow$ & 
during the requirements definition process;\\
$\cdot$ & \$ 5   &$\Leftarrow$  & during design;\\
$\cdot$ & \$ 10  &$\Leftarrow$  & during coding;\\
$\cdot$ & \$ 20  &$\Leftarrow$  & during unit testing;\\
$\cdot$ & \$ 200 &$\Leftarrow$  & after delivery.\\
\end{tabular} 
\end{center}
\end{table}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Process of determinging the requirements.}\\

\begin{itemize}
\item[1.] Elicitation
   \begin{itemize}
   \item By asking questions;
   \item By demonstrating similar systems;
   \item By developing prototypes of all or part 
         of the proposed system.
   \end{itemize}
\item[2.] Documentation
   \begin{itemize}
   \item So that developers and customers agree on 
         what the system should do.
   \item Rewritten in a more mathematical way 
         (Formal Language), so that the designers can 
         transform requirements into a good system design.
   \end{itemize}
\item[3.] Verification
   \begin{itemize}
   \item ensures that the requirements are complete, 
         correct and consistent.
   \end{itemize}
\item[4.]Validation
   \begin{itemize}
   \item makes sure that we have described what 
         the customer intends to see in the final product.
   \end{itemize}
\end{itemize}


%% =======================================
\clearpage
\noindent
{\bf $\Box$ Documentation:}\\
\begin{itemize}
\item Internal documentation
   \begin{itemize}
   \item[$\star$] At a level appropriate for a programmer
   \end{itemize}
\item External documentation
   \begin{itemize}
   \item[$\star$] Intended to be read also by those who may never look 
            at the actual code.\\
   \end{itemize}
\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Elicitation:}\\

\begin{itemize}
\item A variety of techniques exists to determin 
      what the users and customers really want and need.
\item[]
\item Categories of requirements
   \begin{itemize}
   \item[(1)] Absolutely must be met.
   \item[(2)] Highly desirable but not necessary.
   \item[(3)] Possible but could be eliminated.
      \begin{itemize}
      \item if the system will cost too much or take too 
            long to develop, (3) can be dropped, and (2) 
            can be analyzed for elimination and postponement.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Requirements specify not ``how'' but ``what.''}\\


\noindent
Requirements do not specify how the system is 
to be implemented.\\

\hspace*{1in}$\Downarrow$ i.e.,\\

\noindent
A requirement addresses the purpose of the system 
without regard for how the system is to be implemented.\\

\hspace*{1in}$\Downarrow$ \\

\noindent
Some system characteristics having nothing to do with 
the purpose of the system such as
\begin{itemize}
\item Implementation-specific descriptions.
   \begin{itemize}
   \item What database management system to use?
   \item How much memory the computer is to have?
   \item What programming language must be used 
         to develop the system?
   \end{itemize}
\end{itemize}
should be deleted from any requirements specification\\

\hspace*{1in}$\Downarrow$ \\

\noindent
Requirements identify the what of the system, while
the design identifies the how.


%% ========== Planning and Managing the Project ==========
\clearpage
\begin{center}
{\bf $\Box$ Two kinds of requirements document:\\

Definition \& Specification}\\
\end{center}

\begin{itemize}
\item Requirements definition
   \begin{itemize}
   \item A listing of everything the customer 
         expects the system to do.\\
   \item Written in terms that the customer can understand.
   \item[] \hspace*{1in}$\Downarrow$
   \item[] An understanding (between customer and developer)
           of what the customer needs or wants.\\
   \end{itemize}
\item[]
\item Requirements Specification
   \begin{itemize}
   \item Restates the requirement definition in technical 
         terms for the development and design.\\
   \item Should be written by {\it requirements analysts} 
         and designers.
   \end{itemize}
\end{itemize}

\hspace*{1in}\\

\noindent
Note that:\\
{\bf Configuration Management Methods}
which are used throughout the development
begin here by linking the definition and specification.


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Configuration Management Methods:}\\

\begin{itemize}
\item A set of procedures that track:
   \begin{itemize}
   \item the requirements that define 
         what the system should do;
   \item the design modules that are generated from
         the requirements;
   \item the program code that implements the design;
   \item the tests that verify the functionality 
         of the sysem;
   \item the documents that describe the system.
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ To make requirment testable:}\\

\begin{itemize}
\item Robertson's proposal:
   \begin{itemize}
   \item Do not use adverb and adjective for
         a quantitative description.
         \begin{itemize}
         \item[] e.g., immediately $\Rightarrow$ 5 miniutes\\
         \end{itemize}
   \item Do not use pronouns.
         \begin{itemize}
         \item[] e.g., they $\Rightarrow$ users \\
         \end{itemize}
   \item Make sure that every noun is defined in exactly one place.
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Functional/Non-functional Requirement:}\\

\begin{itemize}
\item Functional requirements
   \begin{itemize}
   \item describes an interaction 
         between the system and its environments.
      \begin{itemize}
      \item[e.g.,] 
         \item What states are acceptable 
               for the system to be in?
         \item How the system behaves given stimmuli?
         \end{itemize}
   \end{itemize}
\item[]
\item Non-functional requirements
   \begin{itemize}
   \item describes an {\it restrictions} on the system 
         that limits our choices for a solution.
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Three purposes of requirement:}\\

\begin{itemize}
\item allow {\bf developers} to explain their understanding 
      of how the customer wants the system to work;\\
\item tell {\bf designers} what functionality and characteristics
      the system is to have;\\
\item tell the {\bf test team} what to demonstrate to convince 
      the customer that the system being delivered is 
      what was ordered.
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ Assume now that you are a customer ordering:\\

\begin{itemize}
\item Bus booking system.
\item[]or
\item A convenience store system.\\
\end{itemize}

\noindent
What are your requirements?


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
$\Box$ Toy example of requirements for a bus booking system.\\

\begin{itemize}
\item Input from a terminal should be date, time destination,
      place of departure and male/female to the master computer
      from any of 20 terminals
\item Which sheets are free for the request?
\item Male should not be seated next to female.
\item The final answer should be your seat is \#... or no seat.
\item etc
\end{itemize}



%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Check List:}\\

\begin{itemize}
\item Are the requirements 
   \begin{itemize}
   \item correct? (without errors?)
   \item consistent?
      \begin{itemize}
      \item inconsistent if it is impossible to fulfil
            multiple requirements simultaneously
      \end{itemize}
   \item complete?
      \begin{itemize}
      \item Are all possible states, state changes, 
            inputs, described?
      \end{itemize}
   \item realistic?
   \item verifiable?
   \item tracable?
      \begin{itemize}
      \item The system shall provide real-time response 
            to queries.
            \hspace*{1in} $\Downarrow$\\
            ... respond to queries 
            in not more than 2 seconds.
      \item In identifying the position of the satelite,  
            position should be fairy precise.\\
            \hspace*{1in} $\Downarrow$\\
            ... position error shall be less than 50 feet 
            along orbit, less than 30 feet off orbit. 
      \end{itemize}
   \item Each one really needed by customers?
   \end{itemize}
\end{itemize}

\hspace*{1in}\\
\hspace*{1in}$\Downarrow$ \\
\hspace*{1in}\\
{\bf Then how to express them?}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ How to express Requirements:}\\

\noindent
For many years,\\
requirements were specified in the customer's natural language.\\

\hspace*{1in}$\Downarrow$ \\

\noindent
imprecise and unambiguous\\

\noindent
e.g., ``{\it available}''\\
* for customers: 
\begin{itemize}
\item[-]The system is ``{\it unavailable''} to the user, when users are 
        unable to use a terminal because system backup is in progress.
\end{itemize}
* for developers:
\begin{itemize}
\item[-]The system is still functional and hence ``{\it available''}.\\
\end{itemize}

\hspace*{1in}$\Downarrow$ \\

\noindent
Software engineers have investigated many ways to define requirements
in a more rigorous way.\\

\hspace*{1in}$\Downarrow$ \\

Formal notations. (e.g. in {\it z}.)


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Static \& Dynamic description:}\\

\noindent
A system description lists:

\begin{itemize}
\item[$\cdot$]the system entities or objects;
\item[$\cdot$]their attributes;\\
              (including the functions that can be performed 
               to them or by them);
\item[$\cdot$]their relationships with each other.
\end{itemize}

\hspace*{1in}$\Downarrow$ \\

\noindent
$\bullet$ Relationship among its entities. \\

\hspace*{1in}$\Downarrow$\\

\noindent
Difficult to explain how the system reacts over a period of time.\\

\hspace*{1in}$\Downarrow$ That's why it's called\\

\noindent
\hspace*{.9in}{\bf static}\\


\hspace*{1in}$\Downarrow$ \\

\noindent
When time is not important in the system's operation,\\

\hspace*{1in}$\Downarrow$ \\

it is usuful and adequate.



%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Static \& Dynamic description:} \hfill cont'd\\

\noindent
$\bullet$ Description of a system in terms of states and stimuli.\\

\hspace*{1in}$\Downarrow$ \\

\noindent
\hspace*{.8in}{\bf dynamic}\\

\hspace*{1in}$\Downarrow$ \\

\noindent
The system is considered to be in a particular state 
until some stimulus causes it to change its state.\\

\noindent
starting by describing all possible states and stimuli.


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Formal System Descriptions:\\

\noindent
1. Static Descriptions}\\

\begin{itemize}
%%item Indirect Reference
\item Recurrence Relations
   \begin{itemize}
   \item Initial condition is defined.
   \item The transformation rule 
         from one condition to the next is described.
   \end{itemize}
\item[]
\item Axiomatic Definition
   \begin{itemize}
   \item Basic system properties are specified $\Rightarrow$ {\bf axioms}.
   \item The behavior of the system $\Rightarrow$ {\bf theorems}.
         (in the sense that the behaviour generates new properties.)\\
   \end{itemize}
\item[]
\item Expression as a language
   \begin{itemize}
   \item Usually by Backus-Naur form.
   \end{itemize}
\item[]
%\item Data abstraction
\item etc.
\end{itemize}


\hspace*{1in}\\
\hspace*{1in}\\
Note that:
They are usufull only when time is not important.

%% ========== Planning and Managing the Project ==========
%\clearpage
%\noindent
%{\bf $\Box$ Ways to describe a system statically} \hfill cont'd\\
%\begin{itemize}
%\item Data abstraction
%   \begin{itemize}
%   \item If the data manipulated by a system determine the actions taken,
%   \item then requirements can be defined by data instead of by functions.
%   \item Describe data by forming a data-type dictionary, 
%         called {\bf class}.
%   \item Each kind of data is called an {\bf object} and is given a name.
%   \item The dictionary contains the names in alphabetical order.
%   \item Each object is an {\bf instance} of the class to which it belongs.
%   \item Define {\bf actions} permissible with the data and data types.
%   \item Describe methods (actions) to manipulate data. 
%   \end{itemize}
%\end{itemize}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Formal System Descriptions:} \hfill cont'd\\

\noindent
{\bf 2. Dynamic Description}\\
\hfill ... How to describe a system in terms of states and stimuli.\\

\begin{itemize}
%%item Indirect Reference
\item Decision Tables
   \begin{itemize}
   \item Describe a system as a set of
      \begin{itemize}
      \item possible conditions satisfied by the stsatem at a given time;
      \item rules for reacting to the stimuli 
            when certain sets of the conditions are met;
      \item actions to be taken.
      \end{itemize}
   \end{itemize}
\item[]
\item Transition Diagrams.
   \begin{itemize}
   \item Draw a circle for each state in the system;
   \item For each state and possible imput, 
         draw a directed arrow to indicate the state transition.
         (in the sense that the behaviour generates new properties.)\\
   \end{itemize}
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Dicision table:}
\begin{table}[hbtp]
\begin{center}
\begin{tabular}{c c c}
      &   rule-1   &   rule-2   \\ \hline
Condition-1 & T    &     F      \\ 
Condition-2 & F    &     F      \\ 
Condition-3 & --   &     T      \\ \hline
action-1    &      &            \\
action-2    &      &            \\ \\
\end{tabular} 
\end{center}
\end{table}

\noindent
{\bf $\Box$ Transition diagram and table:}
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=transition-dgrm.eps,width=16cm,height=4cm}
 \end{center}
\end{figure}

\begin{table}[hbtp]
\begin{center}
\begin{tabular}{c c c}
      &   0    &   1   \\ \hline
$S_1$ & $S_2$  & $S_1$ \\ 
$S_2$ &        &       \\ 
$S_3$ &        &       \\ 
\end{tabular} 
\end{center}
\end{table}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
2. Dynamic Description \hfill cont'd\\

\begin{itemize}
\item Fence Diagram
\item[]
\item UML (Unified Modeling Language)
\item[]
\item Event Tables.
   \begin{itemize}
   \item raw: states
   \item column: events
   \item cell: action/no-action/not-possible\\
         no-action: when an event that was for another state was occured.)
   \end{itemize}
\item[]
\item Petrinet
\end{itemize}


%% ========== Planning and Managing the Project ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=fence-dgrm.eps,width=16cm,height=18cm}
 \end{center}
\end{figure}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Event Table:}
\begin{table}[hbtp]
\begin{center}
\begin{tabular}{c c c c}
      &   Event-1        &   Event-2   &  Event-3 \\ \hline
State-1 & action 1       &   no action &          \\ 
State-2 &                &             &          \\ 
State-3 & not possible   &             &          \\
\end{tabular} 
\end{center}
\end{table}


%% ========== Planning and Managing the Project ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=uml.eps,width=16cm,height=12cm}
 \end{center}
\end{figure}

%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
Decision Tables, Transition Diagrams Event Tables\\

\hspace{1in} $\Downarrow$\\

\noindent
only useful for systems whose states and events occur in sequence.\\

\hspace{1in} $\Downarrow$\\

\noindent
How about, when several events occur at once?\\

\hspace{1in} $\Downarrow$\\

\noindent
The systm must perform parallel processing.\\

\hspace{1in} $\Downarrow$\\

\noindent
We need to {\bf synchronize} events.\\

\hspace{1in} $\Downarrow$\\

\noindent
Description by {\bf Petri Nets.}


%% ========== Planning and Managing the Project ==========
\clearpage
\noindent
{\bf $\Box$ Petri Net:}\\

\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=petrinet-1.eps,width=16cm,height=12cm}
 \end{center}
\end{figure}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Synchronization in Petri Net:}\\

\noindent
$\bullet$ Events that occur are represented by tokens.\\
$\bullet$ Transitions are described by firing rules.\\

\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=petrinet-2.eps,width=16cm,height=10cm}
 \end{center}
\end{figure}


%% ========== Planning and Managing the Project ==========
\clearpage

\noindent
{\bf Note:
No one approach is universally applicable to all systems.}\\

\begin{itemize}
\item Some are better at capturing 
   \begin{itemize}
   \item[] non-functional requirements than others $\Rightarrow$
   \end{itemize}
\item[] it may be best to use
   \begin{itemize}
   \item one approach to record the functional ones;
   \item another to describe the constraints.
   \end{itemize}
\item[]
\item Some are good at describing deta requirement,
   \begin{itemize}
   \item one approach for data;
   \item another to process or time-related activities
   \end{itemize}
\end{itemize}
 

%========== Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 4 \\
\hspace*{1in}\\
\hspace*{1in}Designing the System
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\begin{itemize}
\item So far we have studied
   \begin{itemize}
   \item Planning;
   \item Capturing requirement.
   \end{itemize}
\item[] Now we are going into
   \begin{itemize}
   \item Designing.\\
   \end{itemize}
\item[]
\end{itemize}

\begin{itemize}
\item In this chapter, we look at
   \begin{itemize}
   \item {\it conceptual} and {\it tecnical} Design
   \item styles, and techniques;
   \item what is good design;
   \item validating designs;
   \item documenting the design.
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Designers move back and forth among activities like:}\\

\begin{itemize}
\item understanding the requirements;
\item proposing possible solutions;
\item testing aspects of a solution for feasibility;
\item presenting possibilities to the customers;
\item documenting the design for the programmer.
\end{itemize}

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Conceptual \& Technical Desings:}\\

\begin{itemize}
\item Conceptual Design:
   \begin{itemize}
   \item What the system is to do.
      \begin{itemize}
      \item[] $\Rightarrow$ for customer
      \end{itemize}
   \end{itemize}
\item[]
\item Technical Design:
   \begin{itemize}
   \item How the system is to work.
      \begin{itemize}
      \item[] $\Rightarrow$ for programmer
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Conceptual \& Technical Desings:} \hfill cont'd\\

\begin{itemize}
\item A good conceptual design:
   \begin{itemize}
   \item should be written in the customer's language;
   \item should contain no technical jargon;
   \item describes the functions of the system;
   \item is independent of implementation.\\
   \end{itemize}
\item Technical desigh includes:
   \begin{itemize}
   \item a description of the hardware components and their functions;
   \item the hierarchy and function of the software components;
   \item data structures and their flow.
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Decomposition \& Modularity:}\\

\noindent
To design a system is to determine a set of components and intercomponent 
interfaces.\\

\hspace*{1in} $\Downarrow$\\

\noindent
decomposition of the design into modules.\\

\hspace*{1in} $\Downarrow$\\

\noindent
A system is called {\it modular} when each activity of the system 
is performed by exactly one component, and  when the inputs and outputs 
of each componet are well-defined.\\

\hspace*{1in} $\Downarrow$ How we separate the desing?\\

\begin{itemize}
\item Five ways suggested by Wasserman:
   \begin{itemize}
   \item Modular decomposition
   \item Data-oriented decomposition
   \item Event-oriented decompositon
   \item Outside-in design
   \item Object-oriented design
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Decomposition \& Modularity:}\hfill cont'd\\

\noindent
Decomposition starts with 
a high-level depiction of the system's key elements,\\

\hspace*{1in} $\Downarrow$then\\   

\noindent
creates lower-level looks at 
how the system's features and functions will fit together.\\

\hspace*{1in} $\Downarrow$e.g.,\\

\begin{itemize}
\item Modular decomposition
   \begin{itemize}
   \item based on
      \begin{itemize}
      \item assigning functions to components
      \end{itemize}
   \item high-level description of 
      \begin{itemize}
      \item functions to be implemented
      \end{itemize}
   \item lower-level description of 
      \begin{itemize}
      \item how each component will be organized and related to others.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Decomposition \& Modularity:}\hfill cont'd\\

\begin{itemize}
\item Data-oriented decomposition
   \begin{itemize}
   \item based on
      \begin{itemize}
      \item external data structures.
      \end{itemize}
   \item high-level description
      \begin{itemize}
      \item dipicts general data structures.
      \end{itemize}
   \item lower-level descriptions provide 
      \begin{itemize}
      \item detail on what data elements will be involved, and
      \item how the are related.
      \end{itemize}
   \end{itemize}
\item Event-oriented decompositon
   \begin{itemize}
   \item based on
      \begin{itemize}
      \item events that the system must handle, and
      \end{itemize}
   \item[] uses
      \begin{itemize}
      \item information about how events change the system's state.
      \end{itemize}      
   \item high-level description catalogs
      \begin{itemize}
      \item the various states
      \end{itemize}
   \item lower-level descriptions describe
      \begin{itemize}
      \item how state transformation take place.
      \end{itemize}
   \end{itemize}


\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Decomposition \& Modularity:}\hfill cont'd\\

\begin{itemize}
\item Outside-in design
   \begin{itemize}
   \item based on
      \begin{itemize}
      \item user inputs to the system.
      \end{itemize}
   \item high-level description lists
      \begin{itemize}
      \item all possible inputs.
      \end{itemize}
   \item lower-level descriptions address 
      \begin{itemize}
      \item what the system does 
            with each input and what outputs are produced.
      \end{itemize}
   \end{itemize}
\item Object-oriented design
   \begin{itemize}
   \item identifies classes of objects and ther interrelationships.
      \begin{itemize}
      \item assigning functions to components
      \end{itemize}
   \item at the highest-level
      \begin{itemize}
      \item each object type is described.
      \end{itemize}
   \item at lower-levels 
      \begin{itemize}
      \item the object attributes and actions are discussed.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Top-down Design or Bottom-up?}\\

\noindent
Three design levels:

\begin{itemize}
\item Architecture design:
   \begin{itemize}
   \item designs
      \begin{itemize}
      \item system capabilities.
      \end{itemize}
   \item described by modules and their interconnections.
   \end{itemize}
\item Code design
   \begin{itemize}
   \item involves
      \begin{itemize}
      \item algorithms and data structures.
      \end{itemize}
   \item described by programming language's primitives.
   \end{itemize}
\item Executable design
   \begin{itemize}
   \item involves
      \begin{itemize}
      \item the code design at a lower level of details such as
         \begin{itemize}
         \item memory allocations
         \item data formats
         \item bit patterns
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\

\noindent
Back and forth in reality.


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=topdown.eps,width=16cm,height=20cm}
 \end{center}
\end{figure}

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Modularity and Levels of Abstraction:}\\

\noindent
In a modular design, each component has well defined inputs and outputs,
and a clearly stated purpose;\\

\hspace*{1in} $\Downarrow$ furthermore \\

\noindent
modular components are organized in a hierarchy 
as the result of decomposition.\\


\hspace*{1in} $\Downarrow$ \\

\noindent
By combining modular components with several levels of abstruction, 
we get several different views of the system.\\

\hspace*{1in} $\Downarrow$ So, \\

\noindent
we can investigate the system one level at a time.\\

\hspace*{1in} $\Downarrow$ \\

\noindent
As we need more detail about a portion of the system, 
we move to lower levels of abstraction.

%The abstract top levels hide the detail of the functional 
%or data componetns from us.
%In a similar way, modularity hides detail.


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=bus-booking.eps,width=16cm,height=20cm}
 \end{center}
\end{figure}

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Modularity and Levels of Abstreaction:} \hfill cont'd\\

\hspace*{.8in}Bonus: \\

\hspace*{1in} $\Downarrow$ \\

\noindent
We can design differnet components in different ways.\\

\hspace*{1in} $\Downarrow$ e.g.\\

\noindent
- the user interface with object-oriented,\\
- security part with state-transition diagram,\\
- etc

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Design styles:}\\

\begin{itemize}
\item Pipes and Filters
   \begin{itemize}
   \item Filters can be re-used easily.
   \item It is easy to add new filters and remove old ones.
   \item Concurrent execution is allowed.
   \end{itemize}
%\item Object-oriented
%\item Implicit Invocation
\item Layering
  \begin{itemize}
   \item Layers are hierarchical:
      \begin{itemize}
      \item Each layer provides services to the one next higher.
      \end{itemize}
   \item Each layer has access to some/all of the other layers\\ 
         or only to adjacent layer.
   \end{itemize}
%\item Repositories
%\item Process Control
\item Client-server
  \begin{itemize}
   \item Under a distributed system.
   \item a {\it client} requests an service (action) and 
         a {\it server} responds to the request.
   \end{itemize}
\item etc
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=design-style.eps,width=16cm,height=20cm}
 \end{center}
\end{figure}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Layered Architecture:}\\

\begin{itemize}
\item Easy to implement abstraction
   \begin{itemize}
   \item each layer $\Rightarrow$ increasing level of abstraction.
   \end{itemize}
\item Easy to modify/add/remove.
   \begin{itemize}
   \item Because a layer usually affects only two adjacent layers 
   \end{itemize}
\item Easy to reuse a layer.
\item[]
\item But note that it is not always easy to structure a systme in layers.
\end{itemize}



%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Home work:}
\begin{itemize}
\item[1.] Choose one of the following toy projects. 
   \begin{itemize}
   \item [(1)] A long-distance bus seat booking system.
   \item [(2)] ATM system for a bank.
   \item [(3)] A system for a convenience store.
   \end{itemize}
\item[2.] Assume that you are a customer and submit requirement
          in daily English for the system that you chose above.

\item[3.] Describe a {\it requirment definition} of the requirment
          submitted above.
\item[4.] When you describe a {\it requirments specification} for the above,
          which do you use (1) static or (2) dynamic way and what technique
          in it will you pick up for that.?
\item[5.] Describe it by using the technique that you chose above.
\item[6.] Decompose the problem and describe both {\it conceptual}
          and {\it technical design}
\item[5.] Which style do you use for which module?
\item[6.] Discuss ``concurrency'' for the poblem you chose.
\item[7.] Discuss about fault,failure and error for the poblem you chose.
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Concurrency:}

\noindent
How to maintain consistency of the data shared among components 
that execute concurrently.\\

\begin{itemize}
\item[1.] {\bf By carefull timing.}
   \begin{itemize}
   \item   One way to handle concurrency by prescribing the amount
           of time allocated to the performance of any action.
   \item[] \hspace*{1in}$\Downarrow$ Careful {\it timing} can ensure that
   \item   one action does not interfere with another.
   \item[] \hspace*{1in}$\Downarrow$ However, what happens
   \item if the system should react to external events 
         like the sensor data change.
   \item[] \hspace*{1in}$\Downarrow$
   \end{itemize}
\item[2.] {\bf By synchronization}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Concurrency:}\hfill cont'd\\

\begin{itemize}
\item[2.] Syncronization of concurrent processes.
   \begin{itemize}
   \item {\bf Mutual exclusion}
      \begin{itemize}
      \item When one process is accessing a data elements, 
            no other process can affect that element.
      \item[] \hspace*{1in} or
      \item If two operations can affect the state of {\it a shared object},
            then they sould be executed using this scheme, 
      \item[] \hspace*{1in} e.g.,
      \item if an operation tests the state of an object, 
            then the object should be locked so that the state does not 
            change during the test is done and action is taken 
      \end{itemize}
   \item[]
   \item {\bf Process/component priority}
      \begin{itemize}
      \item The one with higher priority can win the battle between the two,
            locking out the other until the higher-priority one is completed.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Concurrency:}\hfill cont'd\\

\noindent 
We want to design systems so that they are always correct 
independent of the timing.\\

\hspace*{1in} $\Downarrow$ Two methods for the purpose.\\
\begin{itemize}
\item {\bf Monitors}
   \begin{itemize}
   \item A monitor is an abstract component that controls 
         the mutual exclusion of a particular process.\\
      \begin{itemize}
      \item {\bf M} $\Rightarrow$ the monitor of a process {\bf P}
      \item {\bf A, B} $\Rightarrow$ concurrent two components.
      \item[] --------------------------------
      \item When component {\bf A} wishes to execute {\bf P}, 
            it must consult {\bf M} to obtain access to {\bf P}.
      \item If component {\bf B} wishes to execute, as {\bf A} 
            is executing {\bf P}, then {\bf M} suspends {\bf B}
            until {\bf A} finished with {\bf P} and afterwords
            {\bf M} activates {\bf B} to allow its access to {\bf P}.
      \end{itemize} 
   \item[]
   \item The monitor has usually a condition cheker to make sure 
         that conditions are satisfied 
         for invoking the requested process.      
   \end{itemize}
\item[]
\item {\bf Gardians}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Concurrency:}\hfill cont'd\\

\begin{itemize}
\item {\bf Gardians}
   \begin{itemize}
   \item A task that is always running with its only purpose 
         being to control access to a resorce 
         (a data-sturcture or a process)\\
      \begin{itemize}
      \item {\bf G} $\Rightarrow$ a guardian of a resource {\bf R}.
      \item {\bf T} $\Rightarrow$ a task.
      \item[] --------------------------------
      \item {\bf T} must issue a request to {\bf G} to use {\bf R}
         \begin{itemize}
         \item[] (Interaction of T and G is called a {\it rendezvous.})
         \end{itemize}
      \item {\bf G} suspends {\bf T} until the condition checker says that
                    the condition is fulfilled.
      \item[] \hspace*{1in} $\Downarrow$ Thus
      \item {\bf G} always reacts to a valid task.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ What is good design:}
\begin{itemize}
\item Component Independence.
\item Exception Identification and Handling.
\item Fault Prevention and Fault Tolerance.
\item Psychological Effect
\end{itemize}

\hspace*{1in}\\

\noindent
{\bf $\Box$ Component independence:}
\begin{itemize}
\item six levels of coupling
   \begin{itemize}
   \item  content coupling
   \item  common coupling
   \item  control coupling
   \item  stamp coupling
   \item  data coupling
   \item  uncoupling
   \end{itemize}
\item seven levels of cohesion
   \begin{itemize}
   \item  coincidentally cohesive component
   \item  logically cohesive component
   \item  temporally cohesive component
   \item  procedurally cohesive component
   \item  communicationally cohesive component
   \item  sequential cohesive component
   \item  functional cohesive component
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Component Independence:}\\

\noindent 
The degree of component independence in terms of:\\

\begin{itemize}
\item {\bf coupling}
   \begin{itemize}
   \item {\bf content coupling}
      \begin{itemize}
      \item When one component modifies an internal data 
            in another component.
      \item When one component branch into the middle of another component.
      \end{itemize}
   \item {\bf common coupling}
      \begin{itemize}
      \item When it is difficult to know which component is responsible 
            for having changed a particular variable.
      \item[] \hspace*{1in}$\Downarrow$ e.g.,
         \begin{itemize}
         \item component-1 $\Rightarrow v=0;$
         \item component-2 $\Rightarrow \mbox{increment} v;$
         \item component-3 $\Rightarrow v=u+w;$
         \end{itemize}
      \end{itemize}
   \item {\bf control coupling}
      \begin{itemize}
      \item When one component passes parameters to another component 
            to control the activity of the component.
      \end{itemize}
   \item {\bf stamp coupling}
      \begin{itemize}
      \item When a data-structure is used to pass information 
            from one component to another.
      \item When the the data-structure itself is passed.
      \end{itemize}
   \end{itemize}
\end{itemize}

%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{itemize}
\item[]
   \begin{itemize}
   \item {\bf data coupling}
      \begin{itemize}
      \item When only data instead of data-structures are passed.\\
            (If coupling should exist this is the most deirable.)
      \end{itemize}
   \item {\bf uncoupling}
      \begin{itemize}
      \item When components have no interconnections at all
            (Completely independent.)
      \end{itemize}
   \item[]
   \end{itemize}
\item {\bf cohesion}
\item[] the degree of {\it cohesiveness} among the internal parts of 
        a component.
\item[] \hspace*{1in}$\Downarrow$
\item[] ``glue'' a component is constructed with.
\item[] \hspace*{1in}$\Downarrow$ So our goal is
\item[] to make each component as cohesive as possible
\item[] \hspace*{1in}$\Downarrow$ so that
\item[] every part of a component's processing was related 
        to the component's singular function.\\
   \begin{itemize}
   \item {\bf conincidentally cohesive component}
      \begin{itemize}
      \item The worst degree of cohesion
      \item Parts in a component are un-related to one another.
      \item[] \hspace*{1in}$\Downarrow$ i.e.
      \item unrelated functions, processes or data are 
            in the same component for reasons of convenience.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{itemize}
\item[]
   \begin{itemize}
   \item {\bf logically cohesive component}
      \begin{itemize}
      \item The next higher level of cohesion 
            (still not desirable.)
      \item several logically related functions or data-elements are 
            in the same component.
      \item[] \hspace*{1in}$\Downarrow$ e.g.
      \item all kinds of inputs regardless of 
            where they are from or how they are used
      \item[] \hspace*{1in}$\Downarrow$
      \item differnet pupose for different components
      \item[] \hspace*{1in}$\Downarrow$
      \item many unrelated functions in one place
      \end{itemize}
   \item {\bf temporally cohesive component}
      \begin{itemize}
      \item When a component performs several functions in sequence 
            but the functions are related only by the {\it timing}.
      \end{itemize}
   \end{itemize}
\item[] When components are logically or temporally cohesive,
        it is difficult to modify a system function $X$.
        Since logically or temporally cohesive components performs several 
        different functions, all components that include the part 
        related to the function should be searched. 
   \begin{itemize}
   \item {\bf procedurally cohesive component}
      \begin{itemize}
      \item When several functions are together in a component 
            just to ensure the order to be performed,
      \item[] \hspace*{1in}$\Downarrow$ e.g.,
      \item[] data must be entered before they can be checked and 
              then manipulated. 
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{itemize}
\item[]
   \begin{itemize}
   \item {\bf communicationally cohesive component}
      \begin{itemize}
      \item When several functions are together in a component 
            because they produce or operate on the same data set,
      \item[] \hspace*{1in}$\Downarrow$ e.g.,
      \item[] unrelated data are fetched together because they are in a disk.
      \end{itemize}
   \item {\bf sequential cohesive component}
      \begin{itemize}
      \item When the output from one part of a component is 
            input of the next part.
      \item The component may still not constrain all of the processing 
            that relats to a function.
      \end{itemize}
   \item {\bf functional cohesive component}
      \begin{itemize}
      \item Every processing element is essential to the perfromance 
            of a single function and all essential elements are contained 
            in one component.
      \item[] \hspace*{1in}$\Downarrow$
      \item[] \hspace*{.7in}Our ideal.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault \& Failure: revisited}\\

\begin{itemize}
\item Not every {\it fault} corresponds to a {\it failure}.
\item Developers see {\it faults} while customers see {\it failures}.
\item Correct {\it fault} before it becomes a {\it failure}.\\
\end{itemize}

\hspace*{1in}\\

\noindent
{\bf $\Box$ A good design should}\\

\begin{itemize}
\item detect fault;
\item correct fault;
\item tolerate fault.
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Detection:}\\
\begin{itemize}
\item Anticipate when failures will occur \\
      $\Rightarrow$ {\bf active fault detection,}
\item[rather] than
\item waiting {\it failures} to occur \\
      $\Rightarrow$ {\bf passive fault detection.}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Detection:} \hfill cont'd\\
\begin{itemize}
\item Use of redundancy
   \begin{itemize}
   \item results of two different processes for the same purpose 
         are compared to determine if they are the same
   \item If two funtionally equivalent systems are designed 
         by two different design teams at two differnet times 
         using diffent techniques, the chance of the same fault 
         occuring simultaneously is very small.
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ further
\item[] $n$-version programming
\item[] \hspace*{1in}$\Downarrow$ e.g.,
   \begin{itemize}
   \item[] In the system for the space shuttle,
   \item[] seven computers vote to determine the next operation.
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Correction:}\\

\noindent 
fixes the damage done by the fault and 
changes the product to eliminate the fault.\\

\hspace*{1in}$\Downarrow$ So, \\

\noindent
a good design should include a strategy to handle faults 
as they are found,\\

\hspace*{1in}$\Downarrow$ e.g. \\

\noindent
Stop the system when a failure occurs,\\
\hspace*{1.2in}or\\
\noindent
record the failure and 
keep the state of the system at the moment of the failure 
so that we can return to fix it later. 


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Tolerance:}\\

\noindent 
Usually, correcting a fault is too expensive, risky and incovenient.\\

\hspace*{1in}$\Downarrow$ So, \\

\noindent
Design minimizes the damage instead of a correction.\\

\hspace*{1in}$\Downarrow$ e.g. \\

\noindent
A banking system may switch to a backup processor 
or make duplicate copies of data and transactions.\\

\hspace*{1in}$\Downarrow$ But \\

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Tolerance:} \hfill cont'd\\

\noindent
It is said that there is no faultless system in the world.\\

\hspace*{1in}$\Downarrow$ That is, \\

\noindent
the more complex systems are, 
the more likely to have significant faults.\\

\hspace*{1in}$\Downarrow$ And, \\

\noindent
the code to implement fault tolerance may itself contain failures
which may cause irreparable damage.\\

\hspace*{1in}$\Downarrow$ \\

\noindent
Are there any techniques that designs fault-tolerant without adding risk?\\

\hspace*{1in}$\Downarrow$ e.g. \\

\noindent
Fault tree analysis\\
Failure-mode anlysis


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Tree Analysis:}\\

\noindent
Trees that display the logical path from effect to cause.\\

\noindent
1. Identify possible failures.
\begin{itemize}
\item[] e.g.
   \begin{itemize}
   \item by using a set of guidewords to know how the system might
         deviate from its intended behavior, such as:
      \begin{itemize}
      \item what if 
         \begin{itemize}
         \item no data or control signal was sent or received?
         \item the volume of the data is too much or the flow is too fast?
         \item the volume of the data is too low or the flow is too slow?
         \item the data or control signal is incomplete?
         \item the data or control signal has another component?
         \item the signal arrives too early for the clock?
         \item the signal arrives too late for the clock?
         \item the signal arrives too early in the expected sequence?
         \item the signal arrives too late in the expected sequence?
         \end{itemize}
      \end{itemize}
  \end{itemize}
\end{itemize}
\noindent


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Fault Tree Analysis:} \hfill cont'd\\

\noindent
2. Build a graph
\begin{itemize}
\item whose nodes are
   \begin{itemize}
   \item failures;
   \item single component;
   \item system function; or
   \item entire system.
   \end{itemize}
\item and edges indicate
   \begin{itemize}
   \item the relationships among nodes, i.e.,
      \begin{itemize}
      \item AND
      \item OR
      \item $n$-of-$m$
         \begin{itemize}
         \item $n$ components' failure out of $m$ redundant components
               lead to a system failure.\\
         \end{itemize}
      \end{itemize}
  \end{itemize}
\end{itemize}

\noindent
3. Search for several types of design weaknes such as 
\begin{itemize}
\item {\it single points of failure}.
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\begin{figure}[bhtp]
 \begin{center}
   \epsfile{file=fault-tree.eps,width=16cm,height=12cm}
 \end{center}
\end{figure}

%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Design Validation \& Verification:}\\

\begin{itemize}
\item Validation
   \begin{itemize}
   \item Does the design satisfy all requirements specified by the cusotmer?
   \end{itemize}
\item Verification
   \begin{itemize}
   \item Does the quality of design is high enough?
   \end{itemize}
\end{itemize}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Mathematical Validation:}\\

\begin{itemize}
\item[1.] Break the system into a set of processes,\\
          so that each process has 
   \begin{itemize}
   \item a set of inputs
   \item a set of expected outputs
   \item a set of assetions about the processes.
   \end{itemize}
\item[2.] For each process, demonstrate:
   \begin{itemize}
   \item[(1)] if the set of inputs is formulated correctly, 
              it is transformed properly into the set of expected outputs.
   \item[(2)] the process terminates without failure.
   \end{itemize}
\end{itemize}

\hspace*{1in}$\Downarrow$\\

{\bf This proves that the design is correct.}\\

\hspace*{1in}$\Downarrow$\\

time-consuming \& expensive\\

\hspace*{1in}$\Downarrow$\\

less formal methods\\

\hspace*{1in}$\Downarrow$\\

\noindent
{\bf $\Box$ Card \& Glass's Method:}\\


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Card \& Glass's Method:}\\

\begin{itemize}
\item With the goal of seaking a good predictor of {\it faults},\\
      they discuss:
   \begin{itemize}
   \item the distribution of faults does not depend on 
         the type of {\it coupling} in design.
   \item components with larger spans of control tended to have 
         a higher fault rate;
   \item more cohesive modules had lower fault rates.
   \end{itemize}
\item They pointed out that:
   \begin{itemize}
   \item design complexity involves:
      \begin{itemize}
      \item complexity within each component
      \item complexity of their relationships
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== 
\clearpage
\noindent
{\bf $\Box$ Card \& Glass's Method:}\hfill cont'd\\

\begin{itemize}
\item They defined a mesure of system complexity as:
\end{itemize}
\begin{displaymath}
C=S+D.
\end{displaymath}
\noindent
Here,
\begin{itemize}
\item[$\cdot$] $S$ is called the structural 
              (between-component) complexity,
\item[$\cdot$] $D$ is called the data 
              (within-component) complexity.
\end{itemize}
and are given as:
\begin{displaymath}
S=\frac{\sum f^2(i)}{n}, \hspace{.5in}D=\frac{V(i)}{f(i)+1},
\end{displaymath}
where
\begin{itemize}
\item[$\cdot$] $f(i)$ is the fan-out of component $i$,
\item[$\cdot$] $V(i)$ is the number of input and output variables 
               in component $i$
\item[$\cdot$] $n$ is the number of components.
\end{itemize}



%========== New Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 5 \\
\hspace*{1in}\\
\hspace*{1in}Writing the Programs
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\

\noindent
Most software is developed by teams.\\
\hspace*{1in}$\Downarrow$\\
Cooperation and coordination is required.\\
\hspace*{1in}$\Downarrow$\\ So,
it is important for others to be able to understand:
\begin{itemize}
\item what you have written?
\item why you have written?
\item how it fits in with their work?
\end{itemize}


%% ========== 
\clearpage
\noindent
{\bf $\Box$ What are said to be important:}\\ 

\begin{itemize}
\item Standardization;
   \begin{itemize}
   \item[$\cdot$] Throw your own method away. Standardize!
   \end{itemize}
\item Importance of comments;
   \begin{itemize}
   \item[$\cdot$] header comment
   \item[$\cdot$] other program comment
      \begin{itemize}
      \item[] e.g.,
      \item[] cases where the denominator might be zero
      \item[] \hspace*{1in}$\Downarrow$ should be pointed out
      \item[] when this might occur and how it is handled. \\
      \end{itemize}
   \end{itemize}
\item meaningful variable name
   \begin{itemize}
   \item[$\cdot$] $i=i+1$;   /* increment i */
   \item[$\cdot$] $i=i+1$;   /* set counter to read next case */
   \item[$\cdot$] $ \mbox{case\_counter} = \mbox{case\_counter} + 1 $;\\
   \end{itemize}
\item Start by pseudocode;\\
\item Revising and rewriting not patching;\\
   \begin{itemize}
   \item[$\cdot$] Find an essential solution instead of tentative one.
   \end{itemize}
\item Revision control.
\end{itemize}


%% ========== 
\clearpage
\noindent
{\bf $\Box$ The Revision Control System (RCS):}\\

\begin{itemize}
\item manages multiple revisions of files;
\item automates the storing, retrieval, logging, 
      identification, and merging of revisions;
\item is useful for text that is revised frequently,
      or that is revised by multiple person.\\
\end{itemize}

\hspace*{1in}\\

\noindent
{\bf $\Box$ The basic user interface::}\\

\begin{itemize}
\item {\bf ci} (check in)
   \begin{itemize}
   \item deposits the contents of a file into
         an archival file called an RCS file 
         which  contains all revisions of a particular file.  
   \end{itemize}
\item {\bf co} (check out) 
   \begin{itemize}
   \item retrieves revisions from an RCS file.\\
   \end{itemize}
\end{itemize}


%% ========== 
\clearpage
\noindent
{\bf $\Box$ How to use RCS::}\\

\noindent
Suppose	you  have a  file f.c that you wish to put under
control of RCS.	\\

\begin{itemize}
\item[1.] Make a directory named RCS by:
   \begin{itemize}
   \item[]\% mkdir RCS.
   \end{itemize}
\item[2.] Then invoke the check-in command
   \begin{itemize}
   \item[]\% ci f.c
      \begin{itemize}
      \item This  command  creates  an  RCS file in the RCS directory,
            stores f.c into it, and deletes	f.c
      \item If it is the first version, it asks you for a description.  
         \begin{itemize}
         \item[] enter description, terminated with single '.' \\
               NOTE: This is NOT the log message!\\
               $>>$ 
         \end{itemize}
      \item The description should be a synopsis of the contents  
            of  the  file.   
      \item All  later check-in  commands  will  ask  you  
            for a log entry, which should summarize the changes 
            that you made.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== 
\clearpage
\begin{itemize}
\item[3.] Files in the RCS directory are called RCS files; 
          the  others  are  called  working  files.  
          To get back the working file f.c in the previous example, 
          use the  check-out  command
   \begin{itemize}
   \item[]\% co f.c
      \begin{itemize}
      \item This  command  extracts	the  latest revision from the RCS
            file and writes it into f.c.  
      \item If you want to edit f.c, you must lock it as you check it 
            out with the command
      \end{itemize}
   \item[]\% co -l f.c
   \end{itemize}
\item[4.] You can now edit f.c
\item[5.] Suppose	after  some editing you want to know what changes
          that you have made.  The command
   \begin{itemize}
   \item[]\% rcsdiff f.c
      \begin{itemize}
      \item tells you  the	difference  between  the  most	 recently
            checked-in  version  and  the working file.  
      \end{itemize}
   \end{itemize}
\item[6.] You can check the file back in by invoking
   \begin{itemize}
   \item[]\% ci f.c
      \begin{itemize}
         \item This increments the revision number properly.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ========== 
\clearpage
\begin{itemize}
\item[7.] If ci complains with the message
   \begin{itemize}
   \item[] ci erro: no lock set by (your-name),
   \end{itemize}
\item[]then you have tried to check in a file even though you did
       not lock it when you checked it out.  Of course, it is too
       late now to do the check-out with locking, because another
       check-out  would  overwrite  your modifications.  
       Instead, invoke
   \begin{itemize}
   \item[]\% rcs -l f.c
      \begin{itemize}    
      \item This command will lock the latest revision for you, unless
            somebody  else  got  ahead  of you already.  
      \end{itemize}
   \end{itemize}
\item[] Locking assures that you, and only you, can check  in  the
        next  update.
\item[] Even if a revision is  locked,  it can still be checked 
        out for reading, compiling, etc.  
\item[] If  your  RCS  file  is private, i.e., if you are the only  
        person who is going to deposit revisions into  it,  strict
        locking	is not needed and you can turn it off.	If strict
        locking is turned off, the owner of the RCS file need  not
        have  a	lock  for check-in; all others still do.  
        Turning strict locking off and on is done with the commands
   \begin{itemize}
   \item[]\% rcs -U f.c
   \item[]\% rcs -L f.c
   \end{itemize}
\end{itemize}


%% ========== 
\clearpage
\begin{itemize}
\item To avoid the deletion of the working file during  check-in\\
      (in  case  you  want  to  continue  editing or compiling), invoke
   \begin{itemize}
   \item[]\% ci -l f.c, or 
   \item[]\% ci -u f.c
      \begin{itemize}
      \item These commands check in	f.c as usual, but perform 
             an implicit check-out.  
      \item The first form also locks the checked in revision, 
      \item the second one doesn't.  
      \end{itemize}
   \end{itemize}
\item[] Thus, these  options save  you one check-out operation.  
        The first form is useful if you want to continue editing, 
        the second one if you just  want  to read the file.  
        Both update the identification markers in your working  file.
\item[] You can give ci the number you want assigned to a checked
        in revision. Assume all your revisions were numbered 1.1,
        1.2, 1.3, etc., and you would like to start release 2.
\item   The command
   \begin{itemize}
   \item[]\% ci -r2   f.c, or
   \item[]\% ci -r2.1 f.c, etc.
   \end{itemize}
\item[]assigns the number 2.1 to the new revision.  
\end{itemize}


%% ========== 
\clearpage
\begin{itemize}
\item  The corresponding co commands
   \begin{itemize}
   \item[]\% co -r2 f.c, and
   \item[]\% co -r2.1 f.c
   \end{itemize}
\item[]retrieve the latest revision numbered 2.x
       and the revision 2.1, respectively.
       (co without a revision number selects the latest revision) \\
       For example, to start a branch at revision 1.3, invoke
   \begin{itemize}
   \item[]\% ci -r1.3.1 f.c
   \end{itemize}
\item[]This command starts a branch numbered 1 at  revision  1.3,
       and  assigns  the number 1.3.1.1 to the new revision.  
\item RCS can put special strings for identification  into  your
      source  and  object  code.  To obtain such identification,
      place the marker
   \begin{itemize}
   \item[] \$Id\$
   \end{itemize}
\item[] into your text, for instance inside a comment.	RCS  will
        replace this marker with a string of the form
   \begin{itemize}
   \item[] \$Id: (filename) (revision) (date) (time) (author) (state)~\$
   \end{itemize}
\item With such a marker on the first page of each module, you
      can always see with which revision you are working.  RCS
      keeps the markers up to date automatically.
\end{itemize}


%% ========== 
\clearpage
\begin{itemize}
\item You may also find it useful to put the marker  
   \begin{itemize}
   \item \$Log\$
   \end{itemize}
\item[] into your text, inside a comment. This marker accumulates 
        the log messages that are requested during check-in.   
        Thus, you can maintain the complete  history of your file
        directly inside it.  
\end{itemize}


%% ========== 
\clearpage
\noindent
Thus RCS:
\begin{itemize}
\item Store and retrieve multiple revisions of text.
   \begin{itemize}
   \item RCS saves all old revisions in a space  efficient  way.
         Changes no longer destroy the original, because the
         previous revisions  remain  accessible.	Revisions
         can  be  retrieved  according to ranges of revision
         numbers, symbolic names, dates, authors, and states.
   \end{itemize}
\item Maintain a complete history of changes.  
   \begin{itemize}
   \item RCS logs all changes automatically. Besides  the  text  of
         each  revision, RCS stores the author, the date and
         time of check-in, and a log message summarizing the
         change.  The logging makes it easy to find out what
         happened to a module,  without  having  to  compare
         source listings or having to track down colleagues.
   \end{itemize}
\item Resolve access conflicts.  
   \begin{itemize}
   \item When two  or  more  programmers
         wish  to  modify  the  same revision, RCS alerts the 
         programmers and prevents one modification from corrupting the other.
   \end{itemize}
\item Maintain a  tree  of  revisions.  
   \begin{itemize}
   \item RCS can maintain separate lines of development for 
         each module.   It stores  a tree structure that 
         represents the ancestral relationships among revisions.
   \end{itemize}
\item Merge revisions and resolve conflicts.
   \begin{itemize}   
   \item Two  separate  lines  of development of a module 
         can be coalesced by merging.  If the revisions to  be  
         merged affect the  same  sections of code, RCS alerts 
         the user about the overlapping changes.
   \end{itemize}
\item Control releases and configurations.  
   \begin{itemize}
   \item Revisions can be  assigned symbolic names and marked 
         as released, stable, experimental, etc.  With these  
         facilities, configurations  of  modules can be 
         described simply and directly.
   \end{itemize}
\item Automatically identify  each  revision  with  name,
      revision number, creation time, author, etc.  
   \begin{itemize}
   \item The identification is like a stamp that can be embedded
         at  an appropriate place in the text of a revision.
         The identification makes it  simple  to	determine
         which  revisions of  which modules make up a given
         configuration.
   \end{itemize}
\item Minimize secondary storage.  
   \begin{itemize} 
   \item RCS needs little extra space for the revisions 
         (only the differences).  If intermediate revisions 
         are deleted, the corresponding deltas are compressed accordingly.
   \end{itemize}
\end{itemize}


%========== New Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 6 \\
\hspace*{1in}\\
\hspace*{1in}

Testing the Program
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\

\begin{center}
----------------------------------------------------------------------\\


Are tests in order to show a program performs properly?\\

\hspace*{1in}\\
$\Downarrow$ No!\\
\hspace*{1in}\\

Test a program to show the existence of a {\it fault.}
\end{center}


%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ Again again, Fault \& Failure:}\\

\noindent
The failure may be the result of any of the following faults:\\

\begin{itemize}
\item The specificatin may be wrong or have a missing requirement. 
\item The specification may contain a requirement 
      that is impossible to implement.
\item The system design may contain a fault.
\item The program design may contain a fault
\item The program code may be wrong.\\
\end{itemize}

\hspace*{1in}\\
\hspace*{1in}\\

\noindent 
A software fault is called a bug?\\

\hspace*{1in}$\Downarrow$\\

\noindent
Did the fault wander into the code from some external source?




%% ========== An example of activity graph (figure) ==========
\clearpage
\noindent
{\bf $\Box$ A Fault of Omission/Commission:}
\begin{itemize}
\item A fault of omission
   \begin{itemize}
   \item A fault when some key aspect of the code is missing
      \begin{itemize}
      \item[]e.g.\\
             when a variable is not initialized.
      \end{itemize}
   \end{itemize}
\item A fault of commision
   \begin{itemize}
   \item A fault when some key aspect of the code is incorrect,
      \begin{itemize}
      \item[]e.g.\\
             when variables are initialized to the wrong value.
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Types of Faults:}\\

\begin{itemize}
\item Algorithmic faults
\item Syntax faults
\item Computation and precision faults
\item Documentation faults
\item Stress or overload faults
\item Capacity or boundary faults
\item Timing or coordination faults
\item Throughput or performance faults
\item Recovery faults
\item Hardware and system software faults
\item Standards and procedures faults
\end{itemize}


%% ==================================================
\clearpage
\begin{itemize}
\item Algorithmic faults
   \begin{itemize}
   \item It occurs when a component's algorithm or logic does not 
         produce the proper output for a given input.
      \begin{itemize}
      \item[$\star$] forget to initialize variables.
      \item[$\star$] forget to test for a particular condition 
                     such as division by zero.
      \item[$\star$] compare variables of inappropriate data types.
      \end{itemize}
   \end{itemize}
\item Syntax faults
   \begin{itemize}
   \item Fortunately, compilers cathch many of them nowadays.
      \begin{itemize}
      \item[$\star$] The first US space mission to Venus failed 
                     by a missing comma in a Fortran do loop.
      \end{itemize}
   \end{itemize}
\item Computation and precision faults
   \begin{itemize}
   \item It occurs when a formula's implementation is wrong or 
         does not compute the result to the required degree of accuracy.
      \begin{itemize}
      \item[$\star$] combine integer and fixed- or floating-point variables. 
      \item[$\star$] improper use of floating-point data, unexpected 
                     truncation cause less-than-acceptable precision.
      \end{itemize}
   \end{itemize}
\item Documentation faults
   \begin{itemize}
   \item When the documentation does not mathch 
         what the program actually dees.
   \end{itemize}
\item Stress or overload faults
   \begin{itemize}
   \item When the data structres are filled over their capacity
   \end{itemize}
\item Capacity or boundary faults
   \begin{itemize}
   \item When the system's performance becomes unacceptable 
         as system activity reaches its specified limit.
   \end{itemize}
\item Timing or coordination faults
   \begin{itemize}
   \item When the code coordinating events is inadequate.
   \end{itemize}
\item Throughput or performance faults
   \begin{itemize}
   \item When the system does not perform at the speed 
         prescribed by the requirement.
   \end{itemize}
\item Recovery faults
   \begin{itemize}
   \item When a failure is encountered and the system does not 
         behave as the designers desire of as the customer requires.
      \begin{itemize}
      \item[$\star$] if a power failure occurs.
      \end{itemize}
   \end{itemize}
\item Hardware and system software faults
   \begin{itemize}
   \item When the supplied hardware and system software do not actually work
         according to the documented operating conditions and procedues.
   \end{itemize}
\item Standards and procedures faults
   \begin{itemize}
   \item When the organizational standards and procedures 
         have not been followed.
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Test Organization:}\\

\begin{itemize}
\item Unit test
   \begin{itemize}
   \item verifies that the component functions properly.
   \end{itemize}
\item Integration test
   \begin{itemize}
   \item verifies that the components work together.
   \end{itemize}
\item Function test
   \begin{itemize}
   \item verifies if the functions described 
         by the developer's requirements specification 
         of software and hardware are actually performed. 
   \end{itemize}
\item Performance test
   \begin{itemize}
   \item compares the system with the remainder of 
         these software and hardware requirements.
   \end{itemize}
\item Acceptance test
   \begin{itemize}
   \item the system is checked against the customer's 
         requirements description.
   \end{itemize}
\item Installation test
   \begin{itemize}
   \item is run to make sure that the system still functions 
         in the environment in which it will be used.
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Unit Test:}\\

\begin{itemize}
\item Examining the code
\item Proving Code Correct
\item Testing Program Components
   \begin{itemize}
   \item Testing vs. Proving
   \end{itemize}
\item Comparing Techniques
\end{itemize}

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Examining the code:}\\

\begin{itemize}
\item Walk-throughs or Inspections?
   \begin{itemize}
   \item Walk-through
      \begin{itemize}
      \item code and documentation are presented to the review team
            and the team comments on their correctness
      \item the programmer leads the discussion
      \item informal
      \end{itemize}
   \item Inspection
      \begin{itemize}
      \item review team checks the code and documentation against 
            a prepared list of concerns.
      \item more formal
      \item e.g.
         \begin{itemize}
         \item 1st meeting for an overview of the code and 
               for a description of the inspection goals.
         \item[]\hspace*{1in} $\Downarrow$
         \item member prepare for a 2nd meeting noting faults found
         \item[]\hspace*{1in} $\Downarrow$
         \item[]\hspace*{0.85in} $\cdots$
         \item in the meeting members report what they have found recording 
            additional faults in discussing individuals'findings.
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Examining the code:} \hfill cont'd\\

\noindent
Typical task of inspection at Hewlett Pckard (Grady, 1977)\\

\begin{itemize}
\item planning for an inspection {\bf (2 hours)}
\item[] \hspace*{1in} $\Downarrow$
\item team meeting {\bf (30 mins)}
\item[] \hspace*{1in} $\Downarrow$
\item individual preparation {\bf (2 hours)}
\item[] \hspace*{1in} $\Downarrow$
\item recording individual's findings {\bf (90 mins)}
\item[] \hspace*{1in} $\Downarrow$
\item team brainstorming the findings and recommendaing actions to be taken
      {\bf (30 mins)}
\item[] \hspace*{1in} $\Downarrow$
\item write and release a sumary {\bf (30 mins)}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Examining the code:} \hfill cont'd\\

\noindent
Software Engineer Researchers' investigations\\

\begin{itemize}
\item Fargam (1976)
   \begin{itemize}
   \item 67\% of the faults eventually detected were found by inspection.
   \item Inspection group had 38\% fewer failures during the first 
         7 months of operation than walk-through.\\
   \end{itemize}
\item Ackerman et al. (1986)
   \begin{itemize}
   \item 93\% of all faults in a 6000 line business application 
         were found by inspection
   \end{itemize}
\item Jones(1977)
   \begin{itemize}
   \item 85\% of the total faults found are by inspection.
   \item (no other method removed even half)
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Proving Code Correct:} \\


\begin{itemize}
\item A code has been
   \begin{itemize}
   \item[] \hspace*{1in}$\Downarrow$
   \item[(1)]coded by you
   \item[] \hspace*{1in}$\Downarrow$
   \item[(2)] examined by you
   \item[] \hspace*{1in}$\Downarrow$
   \item[(3)] reviewed by a team
   \item[] \hspace*{1in}$\Downarrow$
   \item[(4)] {\bf proving the code}
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Formal Proof of a Code:} \\

\begin{itemize}
\item view the code as a flow of statements (assertion)
   \begin{itemize}
   \item[] statement $\Rightarrow$
      \begin{itemize}
      \item combinations of logical variables \\
            (each of which is true or false)
      \item connected by the logical connectives such as
         \begin{itemize}
         \item conjunction
         \item disjunction
         \item negation
         \item implication
         \item equivalence
         \item universal quantifier
         \item existential quantifier
         \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}
      

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ An Example of a Proof:} \\

\begin{itemize}
\item[] $T'(N)=T(N);$\\
        $\mbox{{\it exchange\_not\_occur}}=0;$
\item[] {\bf while} ({\it exchange\_not\_occur} $< N$)
   \begin{itemize}
   \item[]{\bf for} ($i=0$ to $N$)
      \begin{itemize}
      \item[] {\bf if} $(T'(i) > T'(i+1))$
           \begin{itemize}
           \item[] exchange $T'(i)$ with $T'(i+1)$;
           \end{itemize}
      \item[]{\bf else}
           \begin{itemize}
           \item[] {\it exchange\_not\_occur} ++;
           \end{itemize}
      \end{itemize}
   \end{itemize}
\end{itemize}

\hspace*{1in}\\
\hspace*{1in}\\

\begin{itemize}
\item[$A_{s}$:] ($T$ is an array) {\bf AND} ($T$ is of size $N$)
\item[$A_{f}$:] ($T'$ is an array) {\bf AND} ($\forall i$ if $i<N$ then
$(T'(i) \le T'(i+1))$ 
{\bf AND} 
($\forall i$ if $i \le N$ then $\forall j (T'(i) = T'(j))$
{\bf AND} 
($T$ is of size $N$)
\item[]
\item $A_i \rightarrow A_j$
\item[]
\item ({\it exchange\_not\_occur} = FALSE) {\bf AND}
      ($i<N$) {\bf AND} ($(T'(i) > T'(i+1)$) 
      $\rightarrow$ ($T'(i)$ is exchanged with $T'(i+1)$)
\item ({\it exchange\_not\_occur} = FALSE) {\bf AND} ($i \ge N$)\\
      $\rightarrow$ ($T'(i)$ is stored)
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Other Proof Technique:} \\

\noindent
The {\bf logical proof} ignores the structure of the programming 
    language employed.\\

\hspace*{1in} $\Downarrow$\\

\noindent
The {\it logical proof} proves that 
the components design is correct, not necessarily its implementation.\\

\hspace*{1in} $\Downarrow$\\

\noindent 
{\bf symbolic execution technique}\\

\hspace*{1in} $\Downarrow$\\

\noindent
is a simulated execution of the code using symbols 
instead of data variables.\\

\hspace*{1in} $\Downarrow$\\

\noindent
The program is viewed as having an input state dermined 
by the input data and conditions\\

\hspace*{1in} $\Downarrow$\\

\noindent
As each line of the code is executed, the technique checks to see 
whether its state has changed \\

\hspace*{1in} $\Downarrow$\\

\noindent
Each state change is saved.\\

\hspace*{1in} $\Downarrow$\\

\noindent
Program execution is viewed as a series of state changes.\\

\hspace*{1in} $\Downarrow$\\

\noindent
The final state of each path should be an output state.\\

\hspace*{1in} $\Downarrow$\\

\noindent The program is correct if each possible input state 
generates the proper ouptut state.\\

\hspace*{1in} $\Downarrow$ e.g.\\

\begin{itemize}
\item[$\cdot$]$a=b+c;$
\item[$\cdot$]{\bf if} ($a>b$)\hspace*{.5in} $task\_1()$;
\item[$\cdot$]{\bf else} \hspace*{.5in} $task\_2()$;\\
\end{itemize}

\hspace*{1in} $\Downarrow$ \\

\noindent
The condition $a>d$ is treated as two possible states:\\
\hspace*{1in}
$a>d$ is {\it false} \hspace{.3in}and\hspace{.3in} $a>d$ is {\it true}\\
instead of testing a large number of possible values\\


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Automated Theorem Proving:} \\

\begin{itemize}
\item The ideal theorem prover would read in any program 
\item[]and
\item produce as its output 
   \begin{itemize}
   \item[]either
   \item[$\star$] a statement confirming the code's correctress
   \item[] or
   \item[$\star$] the location of a fault\\
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ but unfortunately\\ 
\item it is equivalent to the {\it halting problem for Turing machine}\\
(i.e., no solution)
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Proof or Test?} \\

\begin{itemize}
\item proof
   \begin{itemize}
   \item how a program will work in a hypothetical environment 
         described by the design and requirment.
   \end{itemize}
\item testing
   \begin{itemize}
   \item how a program works in its actual environment
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Choosing test cases:} \\

\begin{itemize}
\item A test case:
   \begin{itemize}
   \item a particular choice of input data to be used in testing the program.
   \end{itemize}
\item A test:
   \begin{itemize}
   \item a finite collection of test cases.\\
   \end{itemize}
\end{itemize}

\hspace*{1in}$\Downarrow$ But,\\

\noindent
how do we choose test cases to know the program works correctly,
not only for the test cases but for all input?\\

\hspace*{1in}$\Downarrow$\\

\noindent
Separate the input into equivalence classes\\

\hspace*{1in}$\Downarrow$ so that,\\


%% ==================================================
\clearpage
\hspace*{1in}\\

\hspace*{1in}$\Downarrow$\\

\noindent
the classes should meet the criteria:
\begin{itemize}
\item Every possible input belongs to one of the classes.
   \begin{itemize}
   \item[$\star$] The classes should cover the entire set of input data.
   \end{itemize}
\item No input datum belongs to more than one class.
   \begin{itemize}
   \item[$\star$] The classes should be disjoint.
   \end{itemize}
\item If the execution code demonstrates a fault when a particular class 
      member is used as input, 
\item[]\hspace*{1in}$\Downarrow$ then
\item[] the same fault can be detected using 
      any other member of the class as input.
   \begin{itemize}
   \item[$\star$] any element of the class represents all elements of 
                  that class.
   \item[] (or at least)
   \item[$\star$] the probability should be high that every other element 
                  in that class will reveal the same fault.
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Choosing test cases:} \hfill cont'd\\

\noindent 
Examples:

\begin{itemize}
\item Input of three real numbers $a$, $b$, and $c$.
   \begin{itemize}
   \item[$\star$] $a>b>c$, \hspace{.2in}$b>c>a$, \hspace{.2in}$c>b>a$, 
                  $\cdots$
   \item[$\star$] $a>$0, $b>$0, $c>$0, \hspace{.2in}$a<$0, $b>$0, $c>$0, 
                  \hspace{.2in}$\cdots$
   \item[$\star$] What if they are coeficients of a quadratic equation?
   \end{itemize}
\item For a positive input value:
   \begin{itemize}
   \item[$\cdot$] a very large positive integer
   \item[$\cdot$] a positive integer
   \item[$\cdot$] a positive, fixed-point decimal
   \item[$\cdot$] anumber greater than 0, but less than 1
   \item[$\cdot$] zero
   \item[$\cdot$] negative number
   \end{itemize}
\item[](Some data are purposely chosen to be improper: we test them 
        to check that the code handles incorrect data gracefully.)
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Choosing test cases:} \hfill cont'd\\

\noindent
$\bullet$ Furthermore, we can add test cases
\begin{itemize}
\item[$\star$] to test all branches, or
\item[$\star$] to exercise as many paths as possible.\\
\end{itemize}

\noindent
$\bullet$ If loops are involved, we may include test cases that 
\begin{itemize}
\item[$\star$] loop once;
\item[$\star$] many times;
\item[$\star$] not at all.\\
\end{itemize}

\noindent 
$\bullet$ If the algorithm includes the trigonometric function,
\begin{itemize}
\item[$\star$] test extremities such as 0, 90, 180, 270, and 360 degrees.
\end{itemize}





%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Test Thoroughness} \\

\noindent
To convince that the test exhibit all possible behavior:

\begin{itemize}
\item Statement testing
   \begin{itemize}
   \item Every statement in the component is executed at least once 
         in some test.
   \end{itemize}
\item Branch testing
   \begin{itemize}
   \item For every decision point in the code, each branch is chosen 
         at least once in some test.
   \end{itemize}
\item Path testing
   \begin{itemize}
   \item Every distinct path through the code is executed 
         at least once in some test.
   \end{itemize}
\item Definition-use path testing
   \begin{itemize}
   \item Every path from every definition of every variable 
         to every use of that definition is exercised in some test.
   \end{itemize}
\item All-uses testing
   \begin{itemize}
   \item The test set includes at least one path from every definition 
         to every use that can be reached by that definition.
   \end{itemize}
%%\item All-predicate-uses/some-computational-uses testing
%%   \begin{itemize}
%%   \item (next page)
%%   \end{itemize}
%%\item All-computational-used/some-predicate-uses testing
%%   \begin{itemize}
%%   \item (next page)
%%   \end{itemize}
\end{itemize}


%% ==================================================
%%\clearpage
%%\noindent
%%{\bf $\Box$ Test Thoroughness} \hfill cont'd\\
%%
%%\begin{itemize}
%%\item All-predicate-uses/some-computational-uses testing
%%   \begin{itemize}
%%   \item For every variable and every devinition of that variable, a test 
%%         includes at least one path from the definition to every predicate 
%%         use: if there are definitions not covered by that description, 
%%         then include computational uses so that every definition is 
%%         covered.
%%   \end{itemize}
%%\item All-computational-used/some-predicate-uses testing
%%   \begin{itemize}
%%   \item For every variable and every definition of that variable, a test 
%%         includes at least one path from the definition to every 
%%         computaitonal use: if there are definition not covered by that 
%%         description, then include predicate uses so that wevery 
%%         definition is covered.
%%   \end{itemize}
%%\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ How about random test?}\\

\begin{itemize}
\item Ntafos's comparison (1984) 
   \begin{itemize}
   \item[] on seven mathematical programs with knwon faults.
   \end{itemize}
\end{itemize}

\begin{table}[hbtp]
\begin{center}
\begin{tabular}{c c c}               \hline \hline
Random    & Branch   & All-uses   \\ \hline
79.5\%    &  85.5\%  & 90.0\%     \\ \hline \hline
\end{tabular} 
\end{center}
\end{table}

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Integration Testing:} \\

\noindent
After being satisfied that individual components are working correctly\\

\hspace*{1in}$\Downarrow$\\

we must combine them into a working system.\\

\hspace*{1in}$\Downarrow$ But how?\\

\begin{itemize}
\item Big-bang Integration
   \begin{itemize}
   \item After all components are tested in isolation, 
         they are mixed together as the final system and tested 
         if it works.
   \item Many programmers use this for small systems, 
         but it is not proctical for large ones.
      \begin{itemize}
      \item it is difficult to find the cause of any failure.
      \item interface faults cannot be distinguished easily 
            from other types of faults.
      \end{itemize}
   \end{itemize}
\item Bottom-up Integration
   \begin{itemize}
   \item The lowest-level components should be tested by
         {\bf component driver}, a special code to call a particular 
         component and passes a test case to it.
   \item Though the top level components are usually the most important 
         but the last to be tested.
   \item It is difficult when much of the system's processing depends 
         on timing.
   \end{itemize}
\item Top-down Integration
   \begin{itemize}
   \item using {\bf stub}, a special purpose program to simulated 
         the activity of the missing component, because a component being 
         tested may call that is not yet tested;
   \item a very large number of stubs may be required when the lowest 
         system level contains many general-purpose routines.
   \end{itemize}
\item Sandwich Integration
   \begin{itemize}
   \item is made up of three layers:
      \begin{itemize}
      \item Top layer $\Rightarrow$ topdown integration
      \item Target layer
      \item Bottom layer $\Rightarrow$ bottom-up integration
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Testing Tools:} \\

\begin{itemize}
\item Code Analysis Tools
   \begin{itemize}
   \item Static vs. Dynamic Analysis
      \begin{itemize}
      \item static $\Rightarrow$ analysis before it is run.
      \item dynamic $\Rightarrow$ during the program is running.
      \end{itemize}
   \item Static Analysis
      \begin{itemize}
      \item Code analyzer
         \begin{itemize}
         \item check syntax or items not been defined.
         \item can generate a symbol table to record 
               where a variable is first defined and when it is used.
         \end{itemize}
      \item Structure checker
         \begin{itemize}
         \item generate a graph depicting the logic flow.
         \item can read a program and 
               (1) check all loops marking statements 
               that are never executed and (2) note the presence of branches 
               from the middle of a loop.
         \item list all possible path through the program
         \end{itemize}
      \item Data analyzer
         \begin{itemize}
         \item reviews (1) data structures and (2) data declarations, and
         \item notes conflictions of data definitions and illegal usage.
         \item notify us  when a denominator may be set to zero
         \item check whether arguments to a subroutine are passed properly.
         \end{itemize}
\clearpage
      \item Link cheker
         \begin{itemize}
         \item review component interfaces and 
               note improper linkage among components. 
         \end{itemize}
      \item Sequence checker
         \begin{itemize}
         \item checks whether coded in the proper sequence of events.
         \item The input/output components may be checked here 
               to see if the events are coded in the proper sequence,\\
               \hspace*{1in}$\Downarrow$ e.g.\\
               all files are opened before they are modified?
         \end{itemize}
      \item what else by static analysis?
        \begin{itemize}
        \item information about fan-in and fan-out;
        \item the number of operators and operands';
        \item the number of decision points;
        \item several measures of the code's structural complexity, and
        \item warn us about possible faults to be fixed 
              before formal tests are run.
        \end{itemize}
   \end{itemize}  
\clearpage 
   \item Dynamic Analysis
      \begin{itemize}
      \item during several parallel operations are performed concurrently:
      \item captures the states during a program run by a series of 
            {\it snapshots}; 
      \item lists the number of times
         \begin{itemize}
         \item a component is called
         \item a line of code is executed
         \end{itemize}
     \item reports whether a decision point branched in all directions;
     \item gives statistics such as the percentage of statements, 
           paths and branches that have been covered by 
           the set of test cases run.
     \item Statistics can be generated as for particular variables:
           their first value, last value, minimum, maximum, $\cdots$.
     \item Breakpoints can be defined so that when a variable attains or 
           exceeds a certain value, the occurence is reported,
           or stopped allowing the tester to check the conditions.
     \item Control flow can be traced backward or forward from 
           a break point and can be tested with different data.
     \end{itemize}
   \end{itemize}
\clearpage
\item Test Execution Tools
   \begin{itemize}
   \item Capture and replay
      \begin{itemize}
      \item capture key strokes, input, and responses;
      \item[] \hspace*{1in}$\Downarrow$
      \item compare the responces with expected one 
            for the testcases specified;
      \item analyse the discrepancy going back to its cause
      \item[] \hspace*{1in}$\Downarrow$ After fixing a fault,
      \item check if the fault has been corrected 
            without introducing new fault
      \end{itemize}
   \item Automatic generation of drivers
      \begin{itemize}
      \item such that it enables us to
         \begin{itemize}
         \item[1.] set all appropriate state variables to prepare for 
                   a given test case, and then run the test case;
         \item[2.] simulate keyboard input and other data-related response;
         \item[3.] compare actual outcome to expected outcome and 
                   report diferences;
         \item[4.] track which paths have been traversed during the run;
         \item[5.] set variables to prepare for the next test case;
         \item[6.] interact with a debugger, so that faults can be traced 
                   and fixed 
         \end{itemize}
      \end{itemize}
\clearpage
   \item Automated testing environment
      \begin{itemize}
      \item These tools above can be connected to
         \begin{itemize}
         \item a testing database;
         \item measurement tools,
         \item code analysis tools, 
         \item text editors
         \item simulation and modeling tools
         \end{itemize}
     \item[] so that it automates the test as much as possible.  
     \end{itemize}
   \end{itemize}
\item Test Case Generators
   \begin{itemize}
   \item Structural test case generators
      \begin{itemize}
      \item is based on
         \begin{itemize}
         \item the structrur of the source code.
         \end{itemize}
      \item lists test cases for path, branch, or statement.
      \end{itemize}
   \item Others
      \begin{itemize}
      \item are based on
         \begin{itemize}
         \item data flow;
         \item functional testing (i.e., on exercising all possible 
               states that affect the completion of a given function);
         \item the state of each variable in the input domain.
         \end{itemize}
      \end{itemize}
   \item Random sets of test data genarators
   \end{itemize}
\end{itemize}

\noindent
{\bf Note:}
Finding evidence of a fault is not the same as locating the fault itself.
Test will always involve the manual effort required to trace a problem back 
to itys root cause. 
The automation assists but does not replace this human roll.

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Testing Tools:} \hfill summary\\

\begin{itemize}
\item Code Analysis Tools
   \begin{itemize}
   \item Static Analysis
      \begin{itemize}
      \item Code analyzer
      \item Structure checker
      \item Data analyzer
      \item Link cheker
      \item Sequence checker
      \end{itemize}  
   \item Dynamic Analysis
   \end{itemize}
\item Test Execution Tools
   \begin{itemize}
   \item Capture and replay
   \item Automatic generation of drivers
   \item Automated testing environment
   \end{itemize}
\item Test Case Generators
\end{itemize}

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ When to Stop Testing:} \\

\noindent
Establishing test objectives\\
\hspace*{1in}$\Downarrow$\\
Designing test cases\\
\hspace*{1in}$\Downarrow$\\
Writing test cases\\
\hspace*{1in}$\Downarrow$\\
Testing test cases\\
\hspace*{1in}$\Downarrow$\\
Executing tests\\
\hspace*{1in}$\Downarrow$\\
Evaluating test results\\

\noindent
\hspace*{1in}$\Downarrow$But\\

\noindent
when a test can be said to be over,\\

\noindent
answering the software is free of faults and \\

\noindent
performs the functions as specified in the requirements?


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ When to Stop Testing:} \hfill cont'd\\

\begin{itemize}
\item Myres (1979) reports that:
   \begin{itemize}
   \item[] As the number of detected faults increases, the probability of 
           the existence of more undetected faults increases.\\
   \end{itemize}
\item Fault Seeding (Mills, 1972)
   \begin{itemize}
   \item   One member of the test team intentionally {\it seed}
           a known number of faults in a program.\\
   \item[] \hspace*{1in}$\Downarrow$\\
   \item   The other members locate as many faults as possible.\\
   \item[] \hspace*{1in}$\Downarrow$
   \end{itemize}
\end{itemize}
\begin{displaymath}
\frac{\mbox{detected-seeded-faults}}{\mbox{total-seeded-faults}}=
\frac{\mbox{detected-nonseeded-faults}}{\mbox{total-nonseeded-faults}}
\end{displaymath}

\begin{itemize}
\item[]
   \begin{itemize}
   \item[] \hspace*{1in}$\Downarrow$\\
   \item But are seeded faults representative of the actual ones?
         (We don't know what are the typical faults before we've found them.)
   \item[]
   \item[] \hspace*{1in}$\Downarrow$
   \end{itemize}
\clearpage
\item Using two testing teams.
   \begin{itemize}
   \item Use two independent test teams for the same program.\\
      \begin{itemize}
      \item $x$ $\Rightarrow$ the number of faults detected by G-1;
      \item $y$ $\Rightarrow$ by G-2;
      \item $q$ $\Rightarrow$ both by G-1 \& G-2;
      \item $n$ $\Rightarrow$ total number of faults.\\
      \end{itemize}
   \item Effectiveness of test:
   \item[] \hspace*{.5in} $E_1 = x/n$ \hspace{.2in} $E_2 = y/n$.\\
   \item[] \hspace*{1in}$\Downarrow$
   \item But $n$ is unknown to us.\\
   \item[] \hspace*{1in}$\Downarrow$ so,\\
   \item G-1 found $q$ of the $y$ faults that G-2 found, i.e.
   \item[] \hspace*{.5in} $E_1 = q/y$\\
   \item[] \hspace*{1in}$\Downarrow$\\
   \item[] \hspace*{.5in} $n=q/E_1\cdot E_2$\\
   \item[] \hspace*{1in}$\Downarrow$ e.g.,\\
   \item[] \hspace*{.5in} $x=25$, \hspace{.2in} $y=30$, \hspace{.2in} $q=15$.
   \end{itemize}
\clearpage
\item Using Confidence.\\
   \begin{itemize}
   \item the likelihood that the software is fault free.\\
   \item[] \hspace*{1in}$\Downarrow$\\
   \item a program is fault free with a 95\% level of confidence.\\
         (the probability that the software has no faults is 0.95)\\
      \begin{itemize}
      \item $S$ $\Rightarrow$ the number of faults seeded;
      \item $s$ $\Rightarrow$ the number of seeded faults detected;
      \item $N$ $\Rightarrow$ the number of actual faults to be claimed\\
            (we claime that the code has only $N$ faults)\\
      \end{itemize}
   \item[] \hspace*{1in}$\Downarrow$ The confidence level is given as:\\
   \item[] \hspace{.7in} 
$c=\frac
{
\left(
\begin{array}{c}
S\\
s-1
\end{array}
\right)
}
{
\left(
\begin{array}{c}
S+N+1\\
N+s
\end{array}
\right)
}
$\\





   \item[] assuming that all faults have an equal probability of 
           being detected, not likely to be true though.\\
   \item[] \hspace*{1in}$\Downarrow$\\
\clearpage
   \item Test the program until we have found all $S$ of the seeded faults.\\
   \item[] \hspace*{1in}$\Downarrow$\\
   \item The confidence level is given as:
   \item[] \hspace*{.7in} $c=s/s+1$\\
   \item[] \hspace*{1in}$\Downarrow$\\
   \item[] If required level of confidence is 98\%
   \item[] \hspace*{.7in} $c=s/s+1=98/100
           \hspace*{.2in} \Rightarrow \hspace*{.2in} s=49$\\
   \end{itemize}
\end{itemize}


%========== New Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 7 \\
\hspace*{1in}\\
\hspace*{1in}

Testing the System
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\

\begin{center}
----------------------------------------------------------------------\\

\hspace*{1in}\\
Requirment Analysis\\
$\Downarrow$\\
System Design\\
$\Downarrow$\\
Program Design\\
$\Downarrow$\\
Unit/Integration Testing\\
$\Downarrow$\\
System Testing\\
$\Downarrow$\\
Maintenance
\end{center}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Soureces of Faults:} \\
\begin{itemize}
\item Requirement Analysis
   \begin{itemize}
   \item Incorrect, missing or unclear requirements/translation;
   \end{itemize}
\item System Design
   \begin{itemize}
   \item Incorrect/unclear design specification
   \end{itemize} 
\item Program design
   \begin{itemize}
   \item Incorrect/unclear design specification
   \item Misinterpretation of system design
   \end{itemize} 
\item Program Implementation
   \begin{itemize}
   \item Misinterpretation of program design
   \item Incorrect documentation
   \item incorrect syntax/semantics
   \end{itemize} 
\item Unit/Integration Testing
   \begin{itemize}
   \item Incomplete test procedures
   \item New faults introduced when old ones corrected
   \end{itemize} 
\item System Testing
   \begin{itemize}
   \item Incomplete test procedures
   \end{itemize} 
\item Maintenance
   \begin{itemize}
   \item Incorrect user documentation
   \item Human mistakes
   \item New faults introduced when old one corrected
   \item Changes in requirements
   \end{itemize} 
\end{itemize} 


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ System Test:} \\
{\bf Function} $\rightarrow$ {\bf Performance} $\rightarrow$ 
{\bf Acceptance} $\rightarrow$ \\ {\bf Implementation}\\

\begin{itemize}
\item {\bf Function Test}
   \begin{itemize}
   \item checks if the integrated system performs its functions 
         as specified in the requirements.
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ called
\item[] {\bf (functioning system)}
\item[] 
\item {\bf Performance Test}
   \begin{itemize}
   \item compares the integrated components with the 
         nonfunctional system requirements, which includes
      \begin{itemize}
      \item security, accuracy, speed, and reliability
      \end{itemize}
   \item At this point, the system works as the designer's 
         interpretation of the requirements specification.
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ called
\item[] {\bf (verified  system)}\\
   \begin{itemize}
   \item further compares the system with the customer's expectations 
         by reviewing the requirements definition document
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ if we are satisfied it is called
\item[] {\bf (validated system)}
\clearpage
\item {\bf Acceptance Test}
   \begin{itemize}
   \item assures the customers that the system they requested 
         is the system that was built.
   \end{itemize}
\item[] \hspace*{1in}$\Downarrow$ if we are satisfied it is called
\item[] {\bf (accepted system)}\\
\item {\bf Installation Test}
   \begin{itemize}
   \item is run  in its actual environment, and 
   \item allows users to exercise system functions.
   \end{itemize}
\end{itemize}

\hspace*{1in}\\


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ For example:} \\
\begin{itemize}
\item A {\bf function test} of a bank account package
   \begin{itemize}
   \item verifies if the package can correctly 
      \begin{itemize}
      \item credit a deposit;
      \item enters a withdrawal;
      \item calculates interst;
      \item prints the balance;
      \item etc.
      \end{itemize}
   \end{itemize}
\item A {\bf performance test}
   \begin{itemize}
   \item evaluates 
      \begin{itemize}
      \item the speed with which calculations are made;
      \item the precision of the computation;
      \item the security precautions required;
      \item the response time to user inquiry.
      \end{itemize}
   \end{itemize}
\item What about in {\bf acceptance test}?
\item What about in {\bf installation test}?
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Incremental Test:} \\

\noindent
A system can be regarded as a nested set of subsystems.\\

\hspace*{1in}$\Downarrow$\\ 

\noindent
Each level is responsible for
performing at least the functions of those subsystems.\\

\hspace*{1in}$\Downarrow$ Similarly,\\ 

\noindent
We can divide the test into a nested sequence of subsystems,\\

\hspace*{1in}$\Downarrow$ and \\ 

\noindent
perform the test on one subsystem at a time.\\

\hspace*{1in}$\Downarrow$\\ 

\noindent
Subsystem division is based on functionality,\\

\hspace*{1in}$\Downarrow$ e.g.,\\ 

\noindent
$\bullet$ the most critical functionality\\
$\bullet$ desirable ones\\
$\bullet$ least needed ones\\

\hspace*{1in}$\Downarrow$\\ 

%% ==================================================
\clearpage

\noindent
\hspace*{1in}$\Downarrow$\\ 

\noindent
Each larger subsystem contains all the susystems preceding it.\\

\noindent
\hspace*{1in}$\Downarrow$ For example, \\ 

\noindent
the star network whose center receives messages from several terminals, 
and each of which captures data from sensors and transmits them 
to the central one for processing.\\

\noindent
\hspace*{1in}$\Downarrow$ Devide into 6 levels: \\ 

\begin{itemize}
\item[1. ] test the central computer's general functions;
\item[2. ] test the central computer's message translation function;
\item[3. ] test the central computer's message assimilation function;
\item[4. ] test each terminal in the stand-alone mode;
\item[5. ] test each terminal's message sending function; 
\item[6. ] test central computer's message receiving function
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Function Testing} (more in detail) \\

\begin{itemize}
\item We now need not know which component is responsible,
\item[] \hspace*{1in}$\Downarrow$ rather
\item[] we must know what the system is to do.\\
\item test one function at a time\\
\item functions may be defined in a nested way, such as:
   \begin{itemize}
   \item[$\cdot$] function 1
      \begin{itemize}
      \item[$\cdot$]  function 1.1
         \begin{itemize}
         \item[$\cdot$]  function 1.1.1
         \item[$\cdot$]  function 1.1.2
         \item[$\cdot$]  function 1.1.3
         \end{itemize}
      \item[$\cdot$]  function 1.2
      \end{itemize}
   \item[$\cdot$] function 2
   \item[$\cdot$] $\cdots$
   \end{itemize}
\clearpage
\item Test cases should be from the requirements document\\
\item[] \hspace*{1in}$\Downarrow$ A tool (Elmendorf 1973, 1974)\\
\item[] converts the natural language of requirements definitions 
        to a formal specification that can be used to enumerate test cases.
\item[] \hspace*{1in}$\Downarrow$
\item[] by examinning the semantics of the requirements
\item[] \hspace*{1in}$\Downarrow$
\item[] it restates them as logical relationships between 
        inputs ({\bf cause}) and outputs/transformation ({\bf effects})
\item[] \hspace*{1in}$\Downarrow$
\item[] A Boolean graph
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ To Create a Cause and effect graph}\\

\begin{itemize}
\item[1. ] The requirements are separated so that each requirement 
           describes a single function;
\item[2. ] All causes and effects should be described;
\item[3. ] The numbered causes and effects become nodes of the graph;
\item[4. ] Place causes on the left-hand side of an arc  and effects
           on the right.\\
\item[] \hspace*{1in}$\Downarrow$ using relations:\\
\item if A then B;
\item if A and B then C;
\item if A or B then C;
\item if not (A and B) then C;
\item if not (A or B) then C;
\item if neithe (A or B) then C;
\item if not A then B;
\item exactly one of A and B can be invoked;
\item at most one of A and B can be invoked;
\item at least one of A and B can be invoked
\item Effect A masks the observance of effect B
\item The invocation of A requires the invocation of B
\end{itemize}



\clearpage
\hspace*{1in}\\
\begin{itemize}
\item[] \hspace*{1in}$\Downarrow$\\
\item Decision table
   \begin{itemize}
   \item raw $\Rightarrow$ each cause/effect
   \item column $\Rightarrow$ testcases
   \item entity for cause  $\Rightarrow$ $T$, $F$ or \#
         (True, False, Dont-care)\\
         entity for effect   $\Rightarrow$ $A$ or $P$
         (Absence, Presence)
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Performance Tests:}\\

\noindent
Types of Performance Tests\\

\begin{itemize}
\item Stress tests
   \begin{itemize}
   \item test the upper bound limit case of the system.
   \item For example, see if
      \begin{itemize}
      \item if the requirements state that a system is to handle
            up to specified number of devices or users, a stress test 
            evaluates system performance when all those devices or users 
            are active simultaneously.\\
      \end{itemize}
   \end{itemize}
\item Volume tests
   \begin{itemize}
   \item address the handling of large amounts of data in the system.
   \item For example, see if
      \begin{itemize}
      \item data structures such as queues or stacks have been defined
            to be large enough to handle all possible situations.
      \item fields, records and files can accommodete all expected data, 
            if it's a data base system.
      \item the system reacts correctly when data sets reach their 
            maximum size.
      \end{itemize}
   \end{itemize}
\clearpage
\item Configuration tests
   \begin{itemize}
   \item analyze the various software and hardware configurations 
         specified in the requirements.
   \end{itemize}
\item Compatibility tests
   \begin{itemize}
   \item are needed when a system interfaces with other systems
   \item e.g.,
      \begin{itemize}
      \item if the system is to communicate with a large database,
            the speed and accuracy of data retrieval should be tested.
      \end{itemize}
   \end{itemize}
\item Regression tests
   \begin{itemize}
   \item are needed when the system is replacing an existing one.
       \begin{itemize}
       \item it should guarantee that the new system's performance 
             is at least as good as toe old one.
       \end{itemize}
   \end{itemize}
\item Security tests
\item Timing tests
   \begin{itemize}
   \item evaluate time to respond to a user
   \item if a transaction must take place within a specified time, 
         the test performs that transaction and verify that 
         it fulfills the requirement.
   \item the test should be perfromed with stress test so that
         it garantees the performance even when the system 
         is extremely active.
   \end{itemize}
\clearpage
\item Environmental tests
   \begin{itemize}
   \item look at the system's ability to perform at the installation site.
   \item including tolerances for heat, humidity, motion, 
         chemical presence, electrical or magnetic fields, 
         disruption of power and so on;
   \end{itemize}
\item Quality tests
   \begin{itemize}
   \item evaluate the system's reliability, maintainabiliyt 
         and availability.
   \item including mean time to failure and mean time to repair, 
         or average time to find and fix a fault
   \end{itemize}
\item Recovery tests
   \begin{itemize}
   \item adress response to the presence of faults or 
         to the loss of data, power, devices or sercices.
   \item We also subject the system to a loss of system resources 
         and see if it recovers properly.
   \end{itemize}
\item Maintenatnce tests
   \begin{itemize}
   \item address the need for diagnostic tools and procedures 
         to help in finding the source of problems.
   \item supplying diagnostic programs, memory maps, 
         traces of transaction, circuit diagrams, and so on.
   \item it should be verified that the aids exist and 
         they function properly.
   \end{itemize}
\clearpage
\item Documantation tests
\item Human factor tests
   \begin{itemize}
   \item investigate the user interface.
   \item examine display screens, messages, report formats, etc.
   \item also called usability tests
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Reliability, Availability, and Maintainability:}\\

\begin{itemize}
\item definiton:
   \begin{itemize}
   \item software reliability
      \begin{itemize}
      \item the probability that a system will operate without failure 
            under given conditons for a given time interval
      \end{itemize}
   \item software availability
      \begin{itemize}
      \item the probability that a system is operating successfully 
            according to specification at a given point in time, 
      \end{itemize}
   \item software maintainability
      \begin{itemize}
      \item the probability that, for a given condition of use, 
            a maintenace activity can be carried out within a stated time 
            interval and using stated procedures and resources\\
      \end{itemize}
   \end{itemize}
\item Can we predict the length of time to the next failure?
   \begin{itemize}
   \item Prot {interfailure times} to see if reliability is growing.
      \begin{itemize}
      \item type-1 uncertainty
         \begin{itemize}
         \item unpredictable uncertainty
         \item We cannot predict which fault will trigger the next failure.
         \end{itemize}
      \item type-2 uncertainty
         \begin{itemize}
         \item reflects our lack of knowledge
         \end{itemize}
      \end{itemize}
   \end{itemize}
\clearpage
\item How to measure them?
   \begin{itemize}
   \item assign value from 0 (unreliable, unavailable, or unmaintainabel)
         to 1 (completely reliable, alwqays available, and 
               completely maintainabel)
   \item mean-time-to-failure (MTTF) of interfailure time $t_1, t_2, 
         \cdots,t_{i-1}$.
   \item mean-time-to-repair (MTTR)
   \item mean-time-between-failure (MTBF)
      \begin{itemize}
      \item MTBF = MTTF + MTTR
      \end{itemize}
   \item Shooman (1993)
      \begin{itemize}
      \item R = MTBF / (1 + MTBF)
      \item A = MTBT / (MTBF + MTTR)
      \item M = 1 / (1 + MTTR)   \\
      \end{itemize}
   \end{itemize}
\item Reliability Stable/Growing
   \begin{itemize}
   \item if the interfailure times stay the same $\Rightarrow$ stable
   \item[] if the interfailure times increases $\Rightarrow$ growing
   \item if we can define a probability density function $f(t)$,
         the likelifood that a software will fail in 
         a time interval $ t_1, t_2$ is $f(t)dt$
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Reliability Prediction Model:}\\

\begin{itemize}
\item The simplest model:
   \begin{itemize}
   \item $t_i=(t_{i-1}+t_{i-2})/2$
   \item $t_i=(t_{i-1}+t_{i-2}+\cdots+t_{i-n})/n$\\
   \end{itemize}
\item The Jelinski-Moranda Model
   \begin{itemize}
   \item under two assumption of
      \begin{itemize}
      \item There is no type-2 uncertainty\\
            (fault corrections are perfect: fix the fault causing 
             the failure without introducing no new faults)
      \item fixing any fault contributes equally to improving
            the reliability\\
      \end{itemize}
   \end{itemize}
\item The Musa Model\\
\item The Littlewood Model
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ System Test:} \\

\begin{itemize}
\item {\bf Function Test}
   \begin{itemize}
   \item checks if the integrated system performs its functions 
         as specified in the requirements.
   \end{itemize}
\item {\bf Performance Test}
   \begin{itemize}
   \item compares the integrated components with the 
         nonfunctional system requirements, which includes
   \end{itemize}
\item {\bf Acceptance Test}
   \begin{itemize}
   \item assures the customers that the system they requested 
         is the system that was built.
   \end{itemize}
\item {\bf Installation Test}
   \begin{itemize}
   \item is run  in its actual environment, and 
   \end{itemize}
\end{itemize}



%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Acceptance Testing:}\\

\begin{itemize}
\item Customer's chance to verify that what was wanted is what was built.\\
\item Test are written, conducted and evaluated by the customers (with
      assistance from the developers only when the customer requests 
      an answer to a technical question.)\\
\item Three ways the customer evaluate
   \begin{itemize}
   \item A benchmark test
   \item A pilot test
   \item A parallel test
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Three ways the customer evaluate:}\\

\begin{itemize}
\item {\bf A benchmark test}
   \begin{itemize}
   \item When a customer has special requirments.\\
   \item Two or more development teams are asked to produce systems.\\
   \item One system will be chosen for purchase, 
         based on the success of benchmark test.
      \begin{itemize}
      \item[] \hspace*{1in}$\Downarrow$
      \item how the systems meet the benchmark criteria under a set 
            of test cases that are prepared by the customer.\\
      \end{itemize}      
   \end{itemize}
\item {\bf A pilot test}
\item {\bf A parallel test}
\clearpage
\item {\bf A pilot test}
    \begin{itemize}
    \item installs the system on an experimental basis;\\
    \item relying on the everday working of the system 
          to test each function;\\
    \item much less fromal and structured than a benchmark test;\\
    \item sometimes we pilot the system before the customer
          runs the real pilot test
       \begin{itemize}
       \item our in-house test $\Rightarrow$ Alpha test
       \item the customer's pilot $\Rightarrow$ Beta test\\
       \end{itemize}
    \item this approach is common when systems are 
          for a wide variety of customers;\\
    \item we must choose beta test sites so that 
          they represent all kinds of system usage\\
    \end{itemize}
 \item {\bf A parallel test}
      \begin{itemize}
      \item if a new system is replacing an existing one
      \item new one should be operated in parallel with the old one.  
      \end{itemize}
\end{itemize}



%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Installation Testing:}\\

\begin{itemize}
\item The final round of testing.\\
\item involves installing the system at user sites.\\
\item We attach the proper number and kind of devices to the main
      processor and establish communications with other systems.\\
\item Tests focus on
   \begin{itemize}
   \item Completeness of the installed system;
   \item Verification of any functional or non-functional 
         characteristics that may be affected by site conditions.\\
   \end{itemize}
\clearpage
\item When building large systems, there is sometimes a long lag
      between the initial specification and the first viewing of 
      even part of a system
\item[] \hspace*{1in} $\Downarrow$
\item[] Customer's needs may change
\item[] \hspace*{1in} $\Downarrow$
\item[] Aftter acceptance test, which requirements are not satistified and 
        which must be deleted revised or added because of changing needs.
\item[] \hspace*{1in} $\Downarrow$
\item[] When the customer is satisfied with the results
\item[] \hspace*{1in} $\Downarrow$
\item[] testing is completed
\item[] \hspace*{1in} $\Downarrow$
\item[] The system is formally delivered
\end{itemize}




%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Test Documentation:}\\

\begin{itemize}
\item {\bf Test Plan}
   \begin{itemize}
   \item describes the system itself and the plan for testing 
         all functions and characteristics.
   \end{itemize}
\item {\bf Test Specification and evaluation}
   \begin{itemize}
   \item details each test and,
   \item defines the criteria for evaluating each feature.
   \end{itemize}
\item {\bf Test Description}
   \begin{itemize}
   \item presents the test data and procedures for individual tests.
   \end{itemize}
\item {\bf Test Analysis Report}
   \begin{itemize}
   \item describes the results of each test
   \end{itemize}
\item {\bf Problem Report}
   \begin{itemize}
   \item \hspace*{1in}$\cdots$
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ An Example of a Test Description:}\\
\begin{large}
\begin{description}
\item[] {\bf INPUT DATA:}
\item[] Input data are to be provided by the LIST program. 
        The program generates randomly a list of $N$ Words of 
        alphanumeric characters; each word is of lenght $M$. 
        The program is invoked by calling 
            \begin{itemize}
            \item[] RUN LIST$(N,M)$ 
            \end{itemize}
        in your test driver. The output is placed in global 
        data area  LISTBUF. The test datasets to be used for this 
        test are as follows:
           \begin{itemize}
           \item[] CASE 1: Use LIST with $N=5$, $M=5$.
           \item[] \hspace*{1in}$\cdots$
           \item[] CASE 6: Use LIST with $N=150$, $M=10$.\\
           \end{itemize}
\item[] {\bf INPUT COMMANDS:}
\item[] The SORT routine is invoked by using the command:
            \begin{itemize}
            \item[] RUN SORT(INBUF,OUTBUF) or
            \item[] RUN SORT(INBUF)\\
            \end{itemize}
\item[] {\bf OUTPUT DATA}
\item[] If two parameters are used, the sorted list is placed in OUTBUF.
        Otherwise, it is placed in INBUF.\\
\item[] {\bf SYSTEM MESSAGES:}
\item[] During the sorting process, the following message is displayed:
           \begin{itemize}
           \item[] ``Sorting... Please wait...''
           \end{itemize}
\item[] Upon completion, SORT displays the following message on the screen:
           \begin{itemize}
           \item[] ``Sorting completed''
           \end{itemize}
\item[] To halt or terminate the test before the completion message 
        is displayed, press CONTROL-C on the keyboard.
\end{description}
\end{large}

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ An Example of a Test Script:}\\

\begin{large}
\begin{itemize}
\item[-] Press function key 4: Access data file.
\item[-] Screen will ask for the name of the date file. Type 'sys:test.txt'
\item[-] Menu will apear, reading
   \begin{itemize}
   \item[$\cdot$] delete file
   \item[$\cdot$] modify file
   \item[$\cdot$] rename file
   \end{itemize}
\item[] Place cursor next to 'modify file' and press RETURN key.
\item[-] Scree will ask for record number. Type '4017'.
\item[-] Screen will fill with data field for record 4017:
   \begin{itemize}
   \item[] Record number: 4017
   \item[] X: 0042 Y: 0036
   \item[] Soil type: clay
   \item[] $\cdots$
   \end{itemize}
\item[-] Press function key 9: modify
\item[-] Entries on screen will be highlighted. Move cursor to VEGETATION 
         field. Type 'grass' over 'kudzu' and press RETURN key.
\item[-] Press function key 16: Return to previous screen.
\item[-] Menu will appear. reading
   \begin{itemize}
   \item[$\cdot$] delete file
   \item[$\cdot$] modify file
   \item[$\cdot$] rename file
   \end{itemize}
\item[] To verify that the modification has been recorded, 
        place cursor next to 'modify file' and press RETURN key.
\item[-] Screen will ask for record number, Type '4017'.
\item[] \hspace*{1in}$\cdots$
\end{itemize}
\end{large}

%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Problem Report:}\\

\noindent
- Questions that are to be asked

\begin{itemize}
\item Where did the problem occur? (locations)
\item When did it occur? (timing)
\item What was observed? (symptom)
\item What were the consequences? (result)
\item How did it occur? (mechanism)
\item Why did it occur? (cause)
\item How much was the user of business affected? (severity)
\item How much did it cost? (cost)
\end{itemize}

%% ==================================================
\clearpage
\noindent
- Examples of answers from {\bf developer's understanding}\\

\begin{itemize}
\item {\bf Location:} module number;
\item {\bf Timing:} phases of development during which 
      fault was created, detected, and corrected;
\item {\bf Symptom:} error message reported, or activity that revealed fault;
\item {\bf Result:} failure caused by the fault;
\item {\bf Mechanism:} how the source was created, detected and corrected;
\item {\bf Cause:} type of human error that led to the fault;
\item {\bf Severity:} refers to sevrity of a failure;
\item {\bf Cost:} time or effort to locate and correct 
            (or, analysis of cost if fault had bee identified earlier)
\end{itemize}

%% ==================================================
\clearpage
\noindent
- Examples of answers from {\bf user's view}\\
\begin{itemize}
\item {\bf Location:} installation where the failure was observed; 
\item {\bf Timing:} clock time;
\item {\bf Symptom:} error message or indication of failure; 
\item {\bf Result:} description of failure, such as
   \begin{itemize}
   \item operationg system crash
   \item service degraded
   \item loss of data
   \item wrong output
   \item no output
   \end{itemize}
\item {\bf Mechanism:} cjaom pf events, including keyboard commands and 
           state data leading to failure;
\item {\bf Cause:} reference to possible faults leading to failure;
\item {\bf Severity:} impact on business;
\item {\bf Cost:} cost to fix plus cost of lost business;
\end{itemize}

%========== New Chapter ==========
\clearpage
\begin{Huge}
\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\
\noindent
Chapter 8 \\
\hspace*{1in}\\
\hspace*{1in}

Maintaining the System
\end{Huge}

\hspace*{1in}\\
\hspace*{1in}\\
\hspace*{1in}\\


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Lehman's System Categorizaiton:}\\

\noindent
Why are some systems more prone to change than others?\\

\begin{itemize}
\item {\bf S-systems} (Specifiable-)
   \begin{itemize}
   \item Systems that are possible to be defined by a specification 
         formally and completely .
   \item The solution is well-known.
   \item[] \hspace*{1in}$\Downarrow$
   \item[] The developer's concern is 
      \begin{itemize}
      \item not on the correctness of the solution,
      \item but on the correctness of the implementation of the solution
      \end{itemize}
   \item If the world changes a completly new problem must be specified.\\
   \end{itemize}
\item {\bf P-systems} (Practical-)
\item {\bf E-system} (Embedded-)
\clearpage
\item {\bf P-systems} (Practical-)
   \begin{itemize}
   \item Systems whose requirments specification are written 
         from the abstract description of the problem.\\
   \item are based on a practical abstraction of the problem 
         rather than on a completely defiend specification\\
   \item When it's difficult/impossible to describe a realworld problem, 
   \item[]\hspace*{1in}or
   \item when theoretical solution to a problem exists but implimenting the
         solution is impractical or impossible,
   \item[] \hspace*{1in}$\Downarrow$
   \item[] we must develop an approximate solution that is more practical 
           to build and use.\\
   \item When the solution is unsuitable the problem abstraction may be
         canged and the requirements may be modified to make the solution 
         more realistic.\\
   \item The solution is acceptable if the results make sense in the world
         where the problem is embedded,
            \begin{itemize}
            \item  while in a S-system the solution 
                   is acceptable if the specifications are correct.
            \end{itemize}
\clearpage
   \item Many things can change in a P-system 
         when the solution is compared with the world,
       \begin{itemize}
       \item the abstraction may change
       \item the requirements may need to be altered
       \item the implementation may be affected.\\
       \end{itemize}
   \item The system resulting from the changes is 
      \begin{itemize}
      \item not a new solution to a new problem 
      \item but a modification of the old solution 
            to find a better fit to the problem.\\
      \end{itemize}
   \end{itemize}
\clearpage
\item {\bf E-system} (Embedded-)
   \begin{itemize}
   \item The system that changes as the world changes, and\\
   \item are likely to undergo almost constant change,
   \item[] while
      \begin{itemize}
      \item S-systems are unlikely to change and
      \item P-systems are subject to incremental change,
      \end{itemize}
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ How much change can we expect?}\\

\begin{itemize}
\item S-systems will have little of no change.\\
\item P-systems will have much more.\\
\item E-systems are likely to change continually.\\
\item[]\hspace*{1in}$\Downarrow$ average\\
\item \hspace{.5in} the 80-20 rules\\
      (20\% of the effort is in development and 80\% is in maintenance.)\\
\item[]\hspace*{1in}$\Downarrow$ 
\item maintenance stage = evolutionary
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Evolve or Discard?}\\

\begin{itemize}
\item Is the cost of maintenance too high?
\item Is the system reliability unacceptable?
\item Can the system no longer adapt to further change within 
      a reasonable amount of time?
\item Is system performance still beyond prescribed constraints?
\item Are system functions of limited usefulness?
\item Can other systems do the same job better, faster, or cheaper?
\item Is the cost of maintaining the hardware great enough to justify 
      replacing it with cheaper, newer hardware?\\
\item[]\hspace*{1in}$\Downarrow$ \\
\item cost from seystem creation to retirement = life-cycle cost
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Lows of Software Evolution} (Lehman, 1980)\\

\begin{itemize}
\item {\bf Continuing change}
   \begin{itemize}
   \item A program  becomes progressively less usuful. The decay continues 
         until it is more cost-effective to replace the system with 
         a recreated version.
   \end{itemize}
\item {\bf Increasing complexity}
   \begin{itemize}
   \item As an evolving program is continually changed, 
         its structure deteriorates and its complexity increases (unless 
         work is done to maintain or reduce it).
   \end{itemize}
\item {\bf Fundamental law}
   \begin{itemize}
   \item Program evolution is subject to a dynamic that makes 
         the programming process 
%%(and hence measures of global project and system attributes,) 
         self-regulating with statistically-determinable trends 
         and invariance.
   \end{itemize}
\item {\bf The Law of Conservation I}
   \begin{itemize}
   \item During the active life of a program, the global activity rate 
         in a programming project is statistically invariant.
   \end{itemize}
\item {\bf The Law of Conservation II}
   \begin{itemize}
   \item During the active life of a program, the rate of changes, 
         addition, and deletions of the successive releases 
         of an evolving program is statistically invariant.
   \end{itemize}
\end{itemize}


%% ==================================================
\clearpage
\noindent
{\bf $\Box$ Lows of Software Evolution} (Lehman, 1980) \hfill cont'd\\

\begin{itemize}
\item {\bf The 1st law says that:}
   \begin{itemize}
   \item large systems are never complete but they continue to evolve;\\
   \item the systems grow as we add more features, apply more constraints, 
         interact with other systems, support a larger number of users, 
         and so on.\\
   \item they also change because their environment changes;\\
   \item the are ported to other platforms or rewritten in new languages.\\
   \end{itemize}
\item {\bf The 2nd law is partly due to:}
   \begin{itemize}
   \item our hasty patches to fix problems;\\
   \item the lack of time to maintain the elegance of a design or 
         the consistency of approach.\\
   \end{itemize}
\clearpage
\item {\bf The 3rd law says:}
   \begin{itemize}
   \item software systems exhibit regular behaviors and trends 
         that we can measure and predict.\\
   \end{itemize}
\item {\bf The 4th law says:}
   \begin{itemize}
   \item there are no wild or wide fluctuations in organizational 
         attributes, such as productivity.\\
   \item At some point, resoruces and output reach an optimum level, and 
         adding more resources does not change the output significantly.\\
   \end{itemize}
\item {\bf The 5th law says:}
   \begin{itemize}
   \item After a while, the effects of subsequent releases make very little 
         difference in overall system functionality.
   \end{itemize}
\end{itemize}




\end{LARGE}
\end{document}

