(This is the old data prior to the compilation of the Project Plan into one document)

 

Project Plan

(Due January 24th)

(Draft is "due" January 22nd, please post it here)

 

These are the notes I brought in for the January 19th meeting. They're very rough, but you might find them useful. They're basically just a summary of Robert's slides and the textbook, so you can check those sources for more information.

~ David

 

I have found a template we could use to combine our contributions. It's just an option to consider, feel free to take a look and voice some feedback:

- Project Plan Option

- Project Plan Template

~ Brett

 

At the meeting, we decided to include only the six elements Robert told us to. They are

1. Project scope (Kwabena)

• Project scope edited to fit template (David Sharpe)

1. Project schedule (Brett)

1. Team organization (Vincent)   

                       * Team Organization Version 1.1 ( Vincent)                                            

1. Technical description of system (Vincent)
2. Configuration management plan (Dave Fawcett) *UPDATED Jan-23-2008*
3. Documentation plan (David Sharpe)

 

If I've mixed up your assignment, please fix it (I was just going from memory).

 

When your document is more or less ready, please post a link to it on this page. If you need ideas for your portion of the plan, please ask for help via email or the wiki.

~ David Sharpe

 

---

 

Ok so I uploaded it and you can access it via the list above (click on the area with my name next to it). I'm not done but am looking for more ideas.

~ David Fawcett

 

---

 

Just post the Organization, Plz help me to make it better. And I am working on Tech description, it should be done by tonight.

~ Yuan Huang ( Vincent )

 

---

 

1. I am applying some finishing touches to my part. I have a couple of classes to attend, so it will take a little longer, say by 5-6pm tonight, I will have my part posted by then.

2. I am writing everything that will start the document. What I am submitting includes the Introduction, the purpose of plan, goals and objectives, and the scope definition.

3. The paper will be found here from my uleth homepage.

~ Kwabena

 

---

 

David, I read over your section, the configuration management plan, and it looks good. Talking about SVN does adequately cover the need to track changes in our code, but the textbook suggests that the configuration management plan should also explain how we plan to track changes in our "requirements, design, test plans, and documents" (p. 124).

 

There is one very important tool that we will be using to track changes in those things: the project binder itself. On Robert's project page, he mentions that he wants us to include "at the beginning of every document a (potential) list of revisions including: date, description of change, reason, author." In the future, the project binder is going to include detailed project requirements and the system design document. As such, the revision pages are going to be a big part of our tracking.

 

I'll have my section up tonight.

~ David Sharpe

 

---

 

Great work, Brett. Very professional looking. I like the work breakdown and the timeline especially: they go together nicely. I also like the "Software Development Process" section.

 

I'm going to reuse your deliverables table. I agree that it does belong in schedule section, but it's also the overall point of my documentation section.

 

I think you said you have a template you thought we could use for integration? edit: Oh, there is is (see top of page).

~ David Sharpe

 

---

 

David, because it has to do more with code than deliverables, you should probably mention "doxygen". From Robert's project page: "doxygen, a documentation generation package you are required to use for the project." I'm not too sure what the "required" will mean if we choose a language not supported by Doxygen: I'm assuming he'll be flexible.

 

I'm mentioning SVN and Doxygen in my section, but only to refer him to yours.

 

Oh, and Brett, I like the looks of that template. It's simple and effective.

~ David Sharpe

 

---

 

Vincent, I just read the team organization document. I like what you've written, it's brief and to the point, and that's all we need for that section, but I'm going to try to think up some more applicable potential roles to be filled. Something like,

 

 

Due to the small size of the project team, our team will be organized in an egoless structure, where the entire group will make all of the decisions together, and vote on the options. Each person on the project team will need to take some responsibility for the key project roles:

 

1. requirements analysts
2. system designers
3. program designers
4. programmers
5. testers
6. librarian
7. quality assurance

 

Good work!

~David Sharpe

 

---

 

I edited your section to fit the template Brett posted, Kwabena. I had to move some stuff around, but everything fits in nicely. I added a paragraph to the "Beyond our Scope" part.

~David Sharpe

 

---

 

 

David, I just update the new team organization document. 

~Yuan Huang ( Vincent )

 

 

---

 

 

I just uploaded my 'current' final copy of Configuration Management, have a look at it and let me know what you think. I tried to follow the pattern I've seen emerge from the rest of the documentation! I also added mention of doxygen and the tracking of documents/design/plans

 

EDIT: BTW, Brett I have to say I'm very impressed with both the template and the breakdowns.. not to mention the timeline. Nice work! xD

 

~ David Fawcett