1. SE18S07 1ISS SE18T7S Metric NoName A0006361U AYE THET MON A0065958L NG SIEW LENG A0065772X PRAGATI A0019692X TIN LAI WAI A0065741E VARUN TAK A0065913A ZHANG SHUDONG

2. Agenda Project Background Requirements Overview Global Use Case Diagram Analysis Use Case Technical Risks and Mitigation Software Architecture Transition Strategy Quality Assurance Practices Project Schedule & Effort Lesson Learnt Q&A 2ISS SE18T7S

3. Project Background

4. Our client, WWW Cargo Pte Ltd, is a private company offering a one-stop total logistics package It provides freight forwarding operations, customs brokerage, transportation & third party warehousing/distribution needs The company management feels the urgency to bring the company operational efficiency to a next high level relying on enterprise IT system SE18 Team 07 have taken up the opportunity to propose and implement the ECMS for WWW Cargo Pte Ltd to assist and automate its daily end-to-end business operations. The new system is expected to ease their daily operations which is currently very much manual in nature, to a large extent. ECMS will span across the following business functions in WWW Cargo for work automation: Marketing Department Customer Service Department Operations Department

5. Requirements Overview

6. Customer Profile Management (Marketing Staff) Maintain customers’ profiles with their supplier information. Agent Profile Management (Marketing Staff) Maintain agents’ profiles with the branch details Shipment Tracking Management (Customer Service Staff) Track shipment by creating new shipment, updating shipment status with email notification feature Sea & Air Import Document Processing (Operation Staff) Maintain air & sea import jobs and generate all the necessary documents as required. User Administration Maintain list of user accounts with their user name, password and access rights, allow change of password

7. Global use case diagram

9. Analysis Use Case Maintain Air Freight Job Records (Add)

11. Analysis Use Case Maintain Air Freight Job Records (Delete)

12. Analysis Use Case – Maintain Air Freight Job Records (Delete)

13. Technical Risks and Mitigation

14. Race Conditions During the coding, many race conditions are discovered, because of asynchronous nature of the requests. Among such scenarios the most encountered one is, when a code segment is in under UPDATE or CREATE operation, during this time sending a SELECT request for the same record within the same session is found to be a race condition. Above race condition identified, and resolved by using afterRequest event handle the SELECT request to update the UI Store. 14

15. Race Conditions-Problem Race condition here Result with no updates 15

16. Race Conditions-Solution After request event fired 16

17. Technical Challenges Novelty of technology at UI layer. ExtJS 4.0 released in April 2011, hence not a mature online contents to study the technology. ExtJS documentation studied and referenced. Wiki pages were used to share the knowledge within the team. www.code.google.com/p/iss2011s7/w/list JSON Parser wasn't able to parse, if object properties contain null values Work around Null values are replaced with empty string before it transmitted from server to UI layer. Long term fix strategy JSON Parser to be fixed. 17

18. Technical Challenges Handling complex objects at UI Layer (ExtJS) Mapping between objects Communication and parsing of Complex object from UI to Service Layer. Additional Transfer Objects used to communicate. Lazy Fetching Lazy fetching was not able to achieve because of JSON Parser limitation of unable to handle null values, where lazy fetching operations are tend to contain null values for contained complex objects. 18

19. Development Approach A reference model developed for an important use case (Air Job) including UI widgets, controllers, services and DAOs. After full requirement analysis Entities and DAO layer interfaces are finalized, and implemented. Individual was assigned use cases to construct both UI components and Service components. 19

20. Flow of Development Activities Requirement Gathering, UI Prototype and Analysis Requirement Gathering, UI Prototype and Analysis Experimental Reference application development Experimental Reference application development Design and Development Of Use Cases Design and Development Of Use Cases Entity and DAO Implementation Entity and DAO Implementation Improvement And updates in Reference App Improvement And updates in Reference App Continuous Integration and Test Continuous Integration and Test 20

21. Software Architecture

22. 22

23. Software Components Third party Software Component and libraries VendorLicense JDK/ JREOracle Sun License (most of it also under GPL) Spring Framework 3.0Spring Source Spring libraries are licensed under the terms of the Apache License, Version 2.0.Apache License, Version 2.0 Ext JS 4.0Sencha ExtJs 4.0 is available in dual licensing scheme; however, we have used it under the licensing terms of GNU GPL license v3.GNU GPL license v3 Hibernate CoreJBOSS Community The GNU Lesser General Public License version 2.1 (LGPLv2.1) Tomcat 7.0ApacheApache Tomcat is developed under the Apache License version 2Apache License version 2

24. Dual layer MVC architecture

25. UI Layer Data Package

26. JSON Parsing 1 2 3 45

27. Following are key features of Spring framework, which ECMS application enjoys: Annotation Driven Architecture. IOC or Dependency Injection by its Component Scanning mechanism, which saves the time for instantiation of user objects. Decoupling between Dispatcher and Mapping and View resolving mechanism. Aspect Oriented Programming model Spring in-built role based security.

28. Spring MVC Architectural View

29. Data Base Layer

30. Transition Strategy

31. Transition Strategy User Interface Layer

32. Static Structure (1)

33. Static Structure (2)

34. Dynamic Structure

35. Asynchronous calls to server

36. Communication Between UI and Service Layer

37. Transition Strategy Service Layer

38. Static Structure

39. Dynamic Structure

40. Transition Strategy Persistence Layer

41. Static Structure

42. Dynamic Structure

43. Deployment Structure

44. Quality Assurance Practices

45. Quality Plan Prepared and approved at the beginning of project Soft filing system approach followed. Filing location – Google Project - ISS2011S7 Location - https://iss2011s7.googlecode.com/svn/trunk/Documentshttps://iss2011s7.googlecode.com/svn/trunk/Documents Document s MGMT Communi cation PlansQualityReports Tech Specificati on UserWorkSCM

46. Document Review Procedure Review of documents done as per the schedule in the project plan. Review Forms used to capture the defects found in the documentation. Approval to the document given after the changes requested in the review form were made and verified by an assigned reviewer.

47. Software Configuration Management Simple Configuration Management system for code implementation was selected. Main Features – All development changes done on main trunk. Feature by feature tagged and released for system testing Last test run done on fully integrated system. Tag VersionFeatures 0.1Air Documents Processing 0.2Sea Documents Processing 0.3Customer Profile Management 0.4Agent Profile Management + User Administration 0.5Shipment Tracking Management 0.6Full integrated system 1.0Initial Release

48. Testing Strategy and Practices Test plan and cases created and approved after internal review. Issues found during system testing logged using Issue Tracker (corrective actions). Issues notified to the developer automatically Issue fixes notified to tester on change of status by developer so that retesting can be done.

49. Testing Strategy and Practices (cont’d) Feature Based Testing Raise corrective actions Developer fixes bugs Fully Integrated System Testing Retesting Test Case Reference no indicated in the issue raised, so that developer can recreate the steps to duplicate the issue.

50. Testing Metrics Test Coverage = 75% Test Run (V0.1 – 0.5) Test Coverage = 95% Test Run (V0.6)

51. Acceptance Procedure User invited to do the multiple round of acceptance testing. First Round focus on functionality testing (completed) Second Round focus on non-functionality requirements (ongoing) Feedbacks given in the first round of acceptance testing gave us following metrics – Based on the functionality handled, user has accepted the new software, and the system will be deployed and supported by us for the next 2 months. SeverityNo of Open Points Critical / Severe0 High / Major0 Medium / Minor8 Low / Very Minor13 Total22

52. Project Schedule & Effort - Plan Vs Actual

53. Phase 1 – Planning & Requirement Scoping 29 th Jan 2011 – 8 th April 2011

56. Phase 2 – Requirement Analysis & High Level Design 29 th Jan 2011 – 8 th April 2011

57. Phase 3 – Implementation till Delivery

59. Phase 3 – Detailed Design, Implementation till Delivery 20 th August 2011 – Feb 2012

62. Lessons Learnt

63. Numerous discoveries on technology (for eg: communication and parsing of complex objects from UI to service layer, JSON parser can’t parse object with null values) Constantly looking for reuse throughout all phases Implementation phase – make use of prototyping in design phase to produce technical framework for automation of CRUD use case implementation Analysis & Testing - produce use case analysis and test case for one set CRUD and to be referenced for the remaining - key to small team with big system Consistent project tracking is key to meeting deadlines Identify slippages early and allow prompt action for resolution Deployment of right people for right task Swapping of roles in phase 3