LOGO FINAL STATUS REPORT ORDER FOOD ONLINE PROJECT Copy right by © Team 3 – K15T1

Company Logo Development Team OFO team contains 6 members:  Hanh Luong – T  Hao Tran – T  Hieu Le – T  Huy Nguyen – T  Thanh Le - T  Quang Nguyen - T094193

Team 3 – K15T1 Contents 1- Project Overview 2- Role 3- Schedule 4- Measurement report 5- Requirement overview 6- Design overview 7- Test 8- Productivity 9- Demo 10- Lesson learned

OFO Project Overview  This project develop a software that can put lunch dishes information to the system so that VLU teacher, employee can order food online and aware of how much capacity for each food. At the same time, canteen can statistic the number of food daily, monthly, quarterly and annually to adjust, updates the number of food according to customer requirement.  Software requirement (High level functional) includes:  Manage daily food  Customer register to order food  Manage order food and deliver food for customer  Statistic – Report about order food status  The project application process Waterfall

Role Roles Members Project Manager Requirement Engineer DesignerDeveloperTester Hanh LuongXXXX Hao TranXXXX Hieu Le XXXX Huy NguyenXXXX Thanh LeXXXX Quang NguyenXXXX Company Logo

Schedule

LOGO Measurement Report

Measurement overview  Goal 1: Pass 95% acceptance test case (test coverage is 100% requirements in SRS).  Goal 2: Pass 100% unit test case (test coverage is 50% functions in source code).  Goal 3: Improve productivity by 10% over month.  Goal 4: Ensure actual worked days delay (if has) within 10% estimated worked days.

Goal 1: Pass 95% acceptance test case (test coverage is 100% requirements in SRS). Metric:  Acceptance test coverage: (TR_AT/TR_SRS) * 100% TR_AT: Total Requirements in Acceptance Test TR_SRS: Total Requirements in SRS (System features) Formula: (12 /12) * 100 % = 100% (PASS)

Goal 1: Pass 95% acceptance test case (test coverage is 100% requirements in SRS). Metric:  Acceptance test pass rate: (TAT_P/TAT) * 100% TAT: Total Acceptance Test case TAT_P: Total Acceptance Test case Passed Formula: (66/66) * 100 % = 100 % (PASS)

Goal 2: Pass 100% unit test case (test coverage is 50% functions in source code). Metric:  Unit test coverage: (TF_U/TF_C) * 100% TF_U : Total Functions in Unit test TF_C : Total Functions in source Code (Win form: 108, Web form: 39) Formula: (86 /147) * 100 % = 59% (PASS)

Goal 2: Pass 100% unit test case (test coverage is 50% functions in source code). Metric  Unit test pass rate: (TUT_P/TUT) * 100% TUT_P : Total Unit Test case Passed TUT: Total Unit Test case Formula: (86/86) * 100% = 100% (PASS)

Goal 3: Improve productivity by 10% over month. Metric:  Productivity: Size/Effort Size: Number of activity/week Effort: Time/week Productivity of this month: 0,43 Week Actual team productivity Week 90,37 Week 100,44 Week 110,50 Week 120,39

Goal 3: Improve productivity by 10% over month.  Productivity of previous month: 0,35 Week Actual team productivity Week 50,47 Week 60,46 Week 70,37 Week 80,09

Goal 3: Improve productivity by 10% over month.  Productivity trend: [((S/E) – (SP/EP)) / (SP/EP)] * 100% S/E : Productivity of this month SP/EP: Productivity of previous month (0,43 – 0,35)/0,35 * 100% = 22,9 % (PASS)

Goal 4: Ensure actual worked days delay (if has) within 10% estimated worked days. Delay rate: [(Actual worked days - Estimated worked days)/ Estimated worked days] * 100% Formula: (76 – 70)/70 * 100% = 8,6 % (PASS) StartFinish Plan 24- Thg5 04- Thg8 Actual 24- Thg5 10- Thg8

Requirement - Overview

Design - Overview - Physic perspective - Dynamic perspective - Static perspective

Design – Physic perspective User machine Server Local area network Legend

Design – Dynamic perspective

Design – Static perspective WIN FORM WEB FORM

Number of defects in SRS Test - Quality - Month 1 OpenClose 36 There are 36 opened defects in document (more than 60 document pages). It proves that the SRS quality is not good. Otherwise, all of defects are fixed; we can conclude productivity of team in fixing defect is good.

Test - Quality - Month 1 Type# Defect Missing12 Wrong16 Redundant8 Total36 There are 3 defect types: Missing, Wrong, Redundant. Most defect focus on Wrong defect type (occupy 45 %), the reason is: team does not understand requirements clearly.

Test - Quality – Month 2 Type# Defect Change1 Wrong5 Improve5 Most of defect focus on Wrong and Improve Wrong defect type can take a lots time to fix. Team need to request more time

Test - Quality – Month 3 Function# Defect Đặt cơm13 Chỉnh sửa đơn đặt cơm15 Quản lí tài khoản1 Almost defects located in function "Đặt cơm" and "Chỉnh sửa đơn đặt cơm" (> 40 %) because 2 function require many complicated calculations. All defects are found on webform. The reason is Team is not good at technical on web

Test - Quality – Month 3 Company Logo According pie chart above, we can conclude that almost defined defects are fixed. Quality product is good. Since technical problems, there's 1 defect won't fix. This defect should be fixed in next release Type# Defect Defect fixed28 Defect won't fix1

Productivity  Status: Good  Week 1 to week 4 teams done very well and achieve goals quite high. Week 5 to week 8 due to the technical difficulties, final exam and number of team members, team spent more time than planned. Finally, from week 9 to week 12, team finished project with improved productivity and pass all goals that team planned

Demo DEMO

Lessons learned  More experience in teamwork  Apply new programming language (ASP.NET)  Experience full of software development process  …