Summary

• We have had on average about two meetings per week they all have been productive.  But we decided in one of our latest meetings that all of us (with the exception of Bill) need to start putting more effort into the project.  We should each be putting in approximately 15 hrs/week and we’re currently under that estimate.  Our goal is to increase our total project effort, evenly distribute our tasks and ensure everyone is putting in the same amount of effort.
• We have developed baseline planning (both long-term and short-term) and process documents (general practices and specific cycle steps).  They have been sent to Chad (client) and to Professor Hilburn for review.  We have reviewed these documents as a team.
• We feel that the J2EE environment setup will take a lot of effort so we will be beginning this effort over break.  Brian is currently heading up this task.
• We have decided to setup Issue Tracker which will keep track of our current tasks and keep the team (and other interested parties) up to date about the status of these tasks.  Our Issue Tracker (developed by Doug) will also be responsible for bug tracking.
• Besides our website, we have decided to not use the SE machines for project and instead, use external machines (mostly Bill’s and Brian’s computers).  We feel we have more control over these machines and they are accessible to everyone.
• Our short term plan has an initial list of items to be done.  Every item has someone responsible for the task and dates have been assigned where applicable.  This will ensure task efficiency once we return from break.
• Our initial approach of the first cycle will concentrate on the plug-ins for extensibility.  We feel these will be crucial to a successful project and are going to begin attacking this topic early on.
• Elicitation meeting with AFRL planned (although not confirmed) for Jan 7^th.  Between now and then are team will be developing elicitation questions for that meeting.

Upcoming activities

• Research of J2EE

Environment setup (Oracle, Issue Tracker, Java Enterprise)

Summary

• Project planning was discussed between Professor Hilburn and the team.  We made several changes based on his suggestions:
• Project Planning worksheet was devised to plan out the major deliverables and tasks for all 3 cycles (with the last 2 cycles having very rough estimates)
• Major cycle 1 tasks were taken from this worksheet and entered into the Task Tracker (renamed from Issue Tracker) as “major tasks”
• Task Tracker now has separate views for major and minor tasks.  The major task view will serve as our reference for planning.
• Dynamic code loading (to be used for plug-ins) has been researched by Bill and appears to be technically feasible.
• Based on Chad’s comments to our Kickoff document, and additional information we found to be important, we have created a Vision and Scope document which will act as our finalized Kickoff document.
• We have decided to use Apache as the Web server for our project.  This was decided because AFRL’s environment is currently using Apache and there were no additional risks discovered from using Apache.
• Product Architecture has been discussed further and we are continuing to make progress on this. 

Upcoming activities

• Initial Requirement documentation will be completed and inspected in the upcoming week

Continued development of our product architecture

Summary

• Our SRS has been drafted and formally inspected by our team.  It is also being reviewed by Professor Hilburn before being sent to DDET on 1/26/04.  There was much discussion in our group about the importance of requirements in order for us to understand how our requirements would be documented.
• Documentation on our process has been improved by Bill’s creation of a Process Intro document which organizes our process documentation by the scope of its applicability.  We have also created a Requirements Process which includes the details of the procedures used during requirements development and why they are important.
• Our team has developed an initial idea of the architecture to use on this project.  This is based on a discussion of our architecture during the previous week and a prototype of plug-in interfaces which Brian has developed.
• Tracking of risks and the management of our tasks will be improvement by our new weekly agenda format.  We have essentially improved our process by reviewing our risks and keeping up-to-date on tasks during our weekly meetings.  Risks are especially important to us since our process is based on the Spiral model.

Upcoming activities

• DDET review of ESDI SRS
• Initial architecture diagram
• Documentation of plug-in interfaces
• Initial ESDI Test Plan
• Completion of disjoint prototypes (UI, performance…etc)

Summary

• Our U.I. prototype and functional prototype have been integrated and has been reviewed with AFRL as of 1/30/2004 via a phone walkthrough.
• A new architecture diagram has been developed using ideas generated from our functional prototype. Further revisions will be made to the diagram next week.
• Our team will have two end-of-cycle presentations. Due to Chad’s availability we will be giving a presentation to AFRL during week 9. We give a second presentation to the SE department during week 10.
• We have decided that more detailed planning for the subsequent cycle will occur at the end of the current cycle. Thus our cycle 2 planning will be done by the end of next week.
• We have created a new document “StakeholderInfo” which contains the responsibilities and contact information for stakeholders of the ESDI project. We will determine the most convenient way to share this information among stakeholders (perhaps on our team website).
• We have not come to a decision about whether we want to use code inspections or not. Code inspections could help us find defects early on but our team needs to determine if they will be useful enough given the effort they will require. This possible addition to our testing strategy will be decided on next week.

Upcoming activities

• Initial Test Plan
• Cycle 1 analysis (postmortem)
• Revised architecture diagram
• Planning for next cycle