Enterprise Cargo Management System (ECMS)

1. Enterprise Cargo Management System(ECMS) SE18S07 ISS SE18T7S

2. 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 Agenda ISS SE18T7S

3. Project Background

4. Project Background • 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. Requirements Overview • 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. Technical Risks and Mitigation

13. 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. Race Conditions-Problem Result with no updates Race condition here

15. Race Conditions-Solution After request event fired

16. 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. 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. Development Approach • A reference model developed for an important use case (Air Job) including UIwidgets, 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. Flow of Development Activities Requirement Gathering, UI Prototype and Analysis Continuous Integration and Test Entity and DAO Implementation Design and Development Of Use Cases Experimental Reference application development Improvement And updates in Reference App

20. Software Architecture

22. Software Components

23. Dual layer MVC architecture

24. UI Layer Data Package

25. JSON Parsing 3 1 2 5 4

26. 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.

27. Spring MVC Architectural View

28. Data Base Layer

29. Transition Strategy

30. Transition Strategy<1>User Interface Layer

31. Static Structure (1)

32. Static Structure (2)

33. Dynamic Structure

34. Asynchronous calls to server

35. Communication Between UI and Service Layer

36. Transition Strategy<2>Service Layer

37. Static Structure

38. Dynamic Structure

39. Transition Strategy<3>Persistence Layer

40. Static Structure

41. Dynamic Structure

42. Deployment Structure

43. Quality Assurance Practices

44. 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/Documents

45. 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.

46. 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.

47. 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.

48. Testing Strategy and Practices (cont’d) • Test Case Reference no indicated in the issue raised, so that developer can recreate the steps to duplicate the issue.

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

50. 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.