Final Presentation

1. Final Presentation Mark Dubosky Eyob Kidanmariam Rashmi Nagaraja Challa Bonja Hakan Ordek Amara Kaba

2. General Project Information • External Deliverables Produced • Project Management Tool • Project Management Plan • Weekly Activity and Status Report • Internal Deliverables Produced • Software Design Document • Test Cases Document • Test Execution Document • User Manual Document

3. Project Information • Used MS Project to manage schedule • Created and used yahoo group page for communication and file management. • Regular weekly meeting to report status on individual assignment.

4. Product Information • Used Visual Studio .NET (C#) • Used MS Access for Database. • Total LOC Count ~1.5KLOC • Assuming the project to be ‘Organic’ and Using the default ‘Nominal’ value for all cost drivers • The amount effort needed is 4.9 PM • The actual effort expended is 2.2 PM

5. Our Initial Goals

6. Planned Vs Actual Effort

7. Planned Vs Actual (Schedule) 10/14 10/25 10/30 11/28 11/29 10/11 3 days (50%) Late Requirement 11/25 5 days (33%) Late 3 days (7.5%) Early Design Coding On Time Testing Plan Actual 10/13 11/23 10/6 10/18 11/20 10/11

8. Plan Evaluation • Our initial plan shows much higher effort. • Our initial schedule assumed much higher resource (in persons month) than actually available. • Created some challenge and room for adjustment.

9. Actual Outcome Evaluation • Used much less effort in all activities but finished late in earlier activities such as requirement analysis and design. • Adjustment was made to make sure all committed requirements can be completed and tested in time.

10. Adjustment on Schedule • New deadline was drafted by the team just for coding to ensure in time completion. • Team members put efforts needed within the scheduled timeframe; thus, deadline was met with no hindrance.

11. Testing • Definitions for Severity Level • Very High : system crashes; or there is a major function working incorrectly; or the data in the database is corrupted and the system can not be used. • High: there is a major function working incorrectly but there is a work around; or the query results are not correctly formatted or sized but the data is accurate; or the message or documentation is incorrect • Medium: there is a minor functional problem and there is a work around; the user interface has wrong terminology or confusing message. • Low: minor cosmetic looks problem; or functionally inconvenient but not incorrect.

13. Planning • Strength – Having enough buffer time and effort to compensate shortfalls. • Problem - Our initial plan with regard to effort estimation and scheduling was not realistic. • Cause - Resource, especially skill and time, was not delivered as promised. • Action – Re-draft a schedule to ensure in time completion of the most critical activity. • Lesson Learned – Must come up with the mechanism to assure the promised effort is really available.

14. Organizing • Strength – Used skill matrix to establish task assignment among team members. • Problem – Team members unable to complete assigned tasks in time. • Cause - Assignments given to individual members in earlier phases were too broad. • Action – We started to assign specific tasks with deadlines to individual members. • Lesson Learned – Task assigned to individual should always be specific and should include due date.

15. Monitoring • Strength – Tracking project progress through weekly status meeting. • Problem – Lack of accountability in terms of meeting a deadline for a specific assignment. • Cause – Assigned tasks were too broad and not be able to be tracked easily in weekly bases in early stages. • Action – Enforced specific tasks to be completed in time.

16. Adjusting • Adjusting the schedule to successfully complete activities on time. • Test case design started earlier than scheduled. • Coding schedule re-planned to ensure in time completion. • Adjusting the task assignment to be specific enough for monitoring.