MIME-Version: 1.0 Content-Location: file:///C:/F06BB24E/Iteration1_Introduction.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 1

= Iteration 1: The First Pass Through

1      =    Project Info

1.1=       =   Name: The Puzzler – 3D Style

1.2=       =   Project Lead: Matthew Klump

1.3=       =   Project Sponsor: Jay Bockelman

1.4=       =   Project Goal: “To write a web-based ap= plication that will create, solve, display, and compare performances of a 3D hidden w= ord puzzle generator/solver by the middle of June, 2005.”

1.5=       =   Project Development Methodology: This will be iteratively driven starting NOW.

1.6=       =   Project Cycle Point: At this point, I am drafting plans for the under lying data structure(s), design documentation = for requirements, use cases, risks, testing, and flow of control.

1.7=       =   At this point my number one risk would be not finishing what I set out to do for this iteration, and having to carry some= of it over (hopefully not!).

1.8=       =   Next Steps to move on: If everything actually gets done listed for this iteration, the next thing to do would be the sequ= ence and class (CRC) diagrams, the work break down structure, and completion of = the high-level flow of program control diagram. Then after this and in later iterations this term, we’ll be refining most of what was done for the first and second pass throughs that should show at a not-so-high level how = the user interface and the code will be organized.

2      =    Introduction For<= /span> this first iteration, I intend to do the following action items:

2.1&= nbsp;       Rewrite this introduction to provide a more descriptive explanation for this iteration’s action items.

2.2&= nbsp;       Rewrite the “Requirements.xls” document correcting certain grammatical errors, spelling errors, and items = that belong more in the pseudo code section of the project design and documentat= ion such as requirement #1: “Create an automatic method…”, and lastly add certain critically overlooked requirements such as (1) bench mar= king measurements for performance of the application, (2) collecting the benched marked statistics for logging, and (3) help/documentation which will have t= he install and uninstall instructions.

2.3&= nbsp;       Rewrite the “UseCases.doc” and t= he “Use Cases Diagram.vsd” to reflect the missing requirements with the use cases, display the correct ways in which each use case in some form= or another “uses” another use case or actor on a use case (this sh= ould also communicate the flow of control to some extent), and last but not least compile together the missing preconditions and postconditions parallel to t= he “uses” head and tail arrows of the diagram in a separate docume= nt. This separate document will have references to the corresponding use cases.=

2.4&= nbsp;       Rewrite the “Risk Management.doc” file explaining which risk have been mitigated as described earlier, and wh= ich ones are sill being worked on as we speak.

2.5&= nbsp;       Write a Software Quality Assurance Plan (SQA= P) document using the “CST412_SQAPLAN.doc” template document that = will talk about how I plan to go about doing my test plans and my unit tests.

2.6&= nbsp;       Begin drafting the over all Test Plan and Un= it Test Plan in the “CST412_Unit-Test-Plan_Template.doc” document = that will supplement the Software Quality Assurance Plan content.

2.7&= nbsp;       Begin drafting a plan for the underlining da= ta structure (The Red/Black Tree) in which we’ll use for processing the dictionary and the puzzle (This will help to perpetuate how the algorithms I already have will be reused without truly starting from scratch and also how the ADO.NET database connection will use it’s notion of the “RecordSet”).

2.8&= nbsp;       Begin drafting the user interface prototype. This will help to perpetuate the UI design ideas we can up with on the boar= d a few weeks back.