Introduction

The Food Management Improvement Project (FMIP) is a capacity-development initiative by the World Food Programme (WFP) and the National Disaster Risk Management Commission (NDRMC), and aimed at increasing the efficiency and accountability of the DRMFSS food-assistance supply-chain. The Commodity & Allocation Tracking System (CATS) is an internet-based computer system to track DRMFSS commodities from annual allocation through to distribution to beneficiaries, and forms the backbone of FMIP. The aim of the system is to improve the availability of logistics data, and thereby make the allocation processes and physical movement of donated food and non-food commodities much more visible. 

Development phases scope

CATS has been developed in two phases, with the Phase 1 focusing on physical commodity movements at the three strategic NDRMC Hubs - Adama, Diredawa and Kombolcha. The second phase focused on Federal level (upstream) and Regional (downstream) processes and reporting. For the first phase the three hubs, sitting at the center of the overall NDRMC commodity movement process, were selected as the first target for development for two reasons:

• All planning work and subsequent NDRMC- and donor-reporting either impact or are based upon the physical commodity movements that occur at the hubs; and
• Although one of the most technically complex part of the DRMFSS operation, it is also one of the best understood - on the basis that warehouse operations anywhere in the world are essentially very similar: recording of commodity receipts, internal movements, adjustments and operations, and commodity dispatches.

The second phase meanwhile focused on upstream (Federal) and downstream (Regional) planning and reporting processes. This also focuses on covering functionality which was already part of existing systems – Relief Management System (RMS) and Transport Bidding System (TBS). As part of the development the following areas were covered:

• Relief planning and allocation
• Resource allocation (dispatch) and planning
• Regional assessment and monthly requests
• Framework bidding and contracting
• Delivery notification
• Regional reporting based on CMPM formats
• KPI reports

History

Development of CATS Phase 1 ran from February to June 2012, and was released to the three hubs for field-testing in May 2012, just before the start of the 2004 Ethiopian Fiscal Year (EFY) (July 2012), in time for the NDRMC annual stock take. On 26 June 2012, a formal evaluation of CATS Phase 1 was held, attended by the then Deputy Director of NDRMC (then DRMFSS), where CATS was very well-received.
Phase II of CATS development was conducted from June 2013 – July 2014 and was accepted as the primary reporting and commodity tracking system for NDRMC. In order to make the transition to CATS smooth, it was decided to have a six month Pilot phase where both CATS and the existing manual systems run in parallel until Jan 2015. Development of fixes and minor improvements took place during the pilot phase to ensure CATS is fit for NDRMC reporting and tracking needs. On Feb 2015 the development and support of CATS was transferred to NDRMC/FMIP and flagged the end of pilot phase. On June 2015 a review assessment was conducted and identified a number of concerns and issues in CATS rollout. The issues and concerns are documented in CATS Workplan Jul-Dec 2016 (v1.0). The following list summarizes the major issues identified:

• Unreliable connectivity and power environment creating CATS outage both at the hubs and central locations
• Lower than expected CATS usage from NDRMC staff creating delay in data entry and creating data backlog
• Outstanding features which are either incomplete or not-implemented caused inconvenience to users

Considering the above concerns it was decided to bring on-board the development team to address CATS technical issues during an extended pilot phase running for one year starting Feb 2016.

Scope

The scope of this document is to conduct a detailed assessment of all existing CATS software assets and is divided into the following sections:

• A section on the development approach and practices used to develop CATS, highlighting good practices that were executed during the development as well as lessons that need to be addressed during the SLA period.
• The second section documents technical aspect of the product covering database design, transactions, user experience, operation, data replication and other technological concerns. 
• The final section provides conclusions and recommendations based on information gathered from the assessment made on the current codebase.

Objectives of the Technical Review

The main aim of this technical review is to fully understand the current state of CATS, by focusing on the following three objectives:

1. Understand and document code and database changes that took place during the time from Feb 2015 – Feb 2016 where by CATS support and development was handled internally. As the SLA involves supporting and maintaining existing CATS codebase it makes perfect sense to conduct this review to answer questions such as:
   • Understand and identify changes made to CATS during this above mentioned period and document changes
   • Make sure that database schema is in accordance with design
   • Take lessons from the pilot phase and identify areas of improvement in usability, performance, security and fitness to business environment.
2. Work towards a sustainable model of supporting and maintain CATS in the future. This involves identifying technical areas which could create issues in the long run to manage and operate CATS in NDRMC data centre.

• Areas that could present challenges for NDRMC IT to manage and operate CATS.
• Deployment and configuration concerns related with infrastructure, servers, SSL etc.

1. Reassess: Use the extended pilot phase as an opportunity to re-examine and rethink some of the design assumptions to improve CATS' chance of adoption within NDRMC.
2. Use as an input for defining and prioritizing CATS product roadmap for the reminder of the extended pilot phase.

Data Sources

In preparing this document, the following information sources have been consulted:

• CATS Work plan Jul – Dec 2016
• Phase I & II functional requirement documents
• Outstanding issues list from JIRA
• CATS wiki
• Discussion with FMIP and CATS development team

Development Process and Tools

From the very beginning CATS has been developed using agile software development methodology. The main reasons for selecting this approach was:

• Agile methodologies allow the development team to incrementally build the product without the need to conduct extensive analysis and design activities. This allows the team to build the product as it learns the existing NDRMC business processes.
• It allows delivery of frequent small releases for users to test and approve.
• It's based on a prioritized list of requirements whereby items with high value to the business are addressed first to give users a chance to experience the product early-on in the development cycle.
• It allows continuous improvement of identifying and adopting the best development approach throughout the development process.

Product Backlog

A list of all user requirements are kept in a list called the Product Backlog. This is a prioritized list of features and requirements identified by NDRMC for the development team to implement. The team uses Atlassian JIRA to track and manage the product backlog. During the pilot phase the development team continuously captured issues coming from users in JIRA for prioritization and subsequent resolution.
JIRA usage was down by a significant percentage during the time where CATS was supported internally. This is attributed to the workload of supporting and maintaining the code-base by a single developer. One measure taken by the SLA development team when it started it support contract was to go back and try to capture as much issues as possible into JIRA for further references. This helped the team not only to ensure that historical data of the project is kept in JIRA but also provided a good opportunity to experience the extent of changes made during that time.

Support request handling vs feature development

In the previous phase of development the team adopted the approach of separating user support request handling and feature development. This was possible because CATS was still in early stages of development and was never intended to be used in mission-critical scenarios. In addition most user requests end up being either bugs on the existing codebase or improvements on implemented features.
For the SLA period the recommendation is to adopt a unified approach to handling both support requests and feature developments since it would be difficult to support and maintain two different versions of the same application with a relatively small team (compared to the previous phases). This will allow the team to be more agile in its release schedule and planning. Each release will include both support request resolutions as well as new features deployed to the same environment.

Source code management

CATS code is publicly available on Github is developed using an open source model distributed source model. During the previous phases development was done on a single branch (versions of a code in a git source code repository) called master. Which means that everyone makes changes and commits updates to the same branch ultimately to be deployed to live environment. This model is acceptable since during development phases changes can be pushed to live environment without out the risk of breaking the deployed application causing outage to users until the issue is fixed.
During the SLA period the team adopted a Gitflow model called topic-branches where by each change reside in its own branch until it's tested and merged to mainline branches. In this model there are at least three mainline branches representing corresponding environments.

• The master branch represents code changes which are currently deployed to live environment.
• Release branch represents the next wave of changes to be deployed to live environment pending tests and approval for release
• Develop branch represents the most recent new features added to the product. This branch can be considered as the bleeding-edge of CATS codebase.

Having separated branches representing different environments gives the team confidence and flexibility in making changes and implementing bugfixes. Changes can be pushed to live environments quickly for urgent issues without waiting for other features to be completed.
Github will continue to be used as the platform of choice for managing CATS source code with one variation. In previous phases the main CATS source code was maintained under a Github account owned by the development company but at the start of the SLA period a decision was made to move it to NDRMC owned account to ensure sustainability and feeling of ownership from the client.

Documentation for changes

No standardized protocol in place to guide developers how to document the changes made both in code repository and database.

Product Design & Implementation

The development of CATS was dictated by specifications documented on "05 - Functional Requirements (Phase 2 & 3).pdf" (hereafter referred to as the "Functional Requirements" document) was the key document which outlined list of functional requirements that must be incorporated into the end product. On the basis of that document, this section assesses the state of CATS application and provides an overview of the requirements, scope, technical architecture and development platform employed. 

Assumptions

A number of key assumptions were made during the development of CATS that had a direct impact on the design and implementation of the product. These are:

• The system to be developed needs to follow the current NDRMC process. It shall not impose process changes.
• Due to different challenges observed at the stores, Hub module should only function at the office/hub level (not at the stores where the physical receive and dispatch takes place). This makes the system a data-recording application, rather than a live transactional system at the centre of operations.
• The key documents that the system needs to capture physical stock movement at the hubs are the "GRNs" and "GINs" (Goods Receiving Notes and Goods Issuing Notes)
• The system needs to be able to track SI numbers and/or any equivalent organization level project codes that will allow tracing of commodities from initial receipt to final distribution.
• There are activities that need to be accomplished by different units of NDRMC for the downstream processes to start. For example receipt planning should be conducted at Federal Logistics for Hubs to start capturing GRNs.
• The system is going to be used by Federal units (Early Waring, Logistics, Procurement and Finance), Regions and Hubs.

Requirements

CATS was developed and implemented in two phases which focused on different aspects of NDRMC supply chain. The first phase focused on capturing commodity movement at the three NDRMC hubs while the second phase was about implementing upstream and downstream processes at the Federal and Regional levels.

Hub requirements

The key processes identified and implemented as part of the Hub module include automating the process of to be a part of the first phase of the project are mostly driven from the following source documents:

• Goods Received Note (GRN) – this is a document that is issued by the storekeeper when accepting incoming commodities.
• Goods Issue Note (GIN) – a document that is prepared and issued by the storekeeper when releasing commodities for dispatch

The major hub related activities that are captured by CATS Phase 1 include:

1. Receiving commodities: Recording the transfer of ownership when commodities are unloaded at the DRMFSS warehouse from different sources including WFP, non-WFP Donor, or as a result of a local purchase.
2. Warehousing activities that take place within the duration of the time that a commodity is stored in DRMFSS warehouses. These processes cover the different aspects of warehouse management, including:
   1. Adjustments (due to loss and damage)
   2. Internal movements (between stores)
   3. Stock-takes
3. Dispatching commodities from DRMFSS: Recording of the outward movement of commodities according to the instructions received from DRMFSS Logistics for FDPs, other warehouses based on Goods Issue Note documents prepared by the storekeeper.

Early warning requirements

Early waring is mainly engaged with planning and resource allocation activities within NDRMC supply chain. The following key business processes have been implemented and covered within CATS.

1. HRD requirement: twice a year EW unit prepares HRD document which represent total number of beneficiaries to be covered in relief assistance. HRD preparation and reporting including approval workflow is implemented in CATS.
2. Gift certificate: capability to capture gift certificates was actually initially implemented during the first phase of development. During the second phase additional features such as linking gift certificates with receipt planning, approval workflow and reporting was added.
3. Needs assessment
4. Monthly request
5. Resource allocation and planning: EW conducts a periodic (monthly or per round) planning of resources for distribution – activity called resource allocation. Allocation of resources based on requirements found on HRD document as well as modification as per request from regions.
6. Donors directory

PSNP requirements

Within CATS PSNP is mostly involved at the planning and allocation phases. It should be noted that CATS doesn't provide support for cash assistance since its primary focus is on food commodity tracking. The following features are included as part of PSNP planning implementation:

1. PSNP annual planning: annual planning of food assistance per woreda.
2. Monthly requests
3. Monthly allocation

Logistics requirements

Logistics comprises a significant part of CATS functionalities as it sits at the center of NDRMC supply chain. Almost all business processes within Logistics are a continuation of upperstream ones or trigger downstream activities making functionalities in this unit critical for CATS' smooth operation. The following are list of features implemented as requirements from Logistics unit:

1. Receipt planning: planning for incoming commodities to be received at the hubs is conducted at Federal Logistics level. The major tasks are allocating which hub should receive how much amount, give unique project code for commodities and track status of receiving operation by following up how much is received and how much is remaining.
2. Dispatch allocation: based on resource allocation coming from Early Warning and PSNP units, logistics allocates resources from its central warehouses for dispatch. Here the main task is to allocate dispatch requests from available project code or SI as well as indicate from which hub the mentioned dispatch is conducted.
3. Bid planning: for procurement to conduct framework tendering and contracting it should have list of Woreda and FDP included in a given period (six month). Logistics prepares distribution plan for the coming six months based on HRD and PSNP Annual Plan documents. This feature is a mandatory process that's conducted by Logistics which has a direct impact on bid processing in Procurement as well as dispatches at the Hubs.
4. Transport order preparation based on monthly/round allocations existing bid winner transporters. This means every month/round Logistics will prepare Transport Orders for each transporter indicating from which warehouse the dispatch is from, the destination FDPs and the type and amount of commodities to transport. CATS generates this information on the fly hence users are not required to encode information because allocations, dispatch plans as well as transporter bids are already in the database.
5. Stock status reporting and analytics allows Logistics to get statistics and information about current stock from the hubs. This requires that the hubs regularly capture stock movement information (receipts, dispatch, transfer etc.)
6. Transporter performance
7. Contract administration
8. Bid status tracking
9. Transporters directory
10. Transporter payment request, processing and tracking

Finance & Procurement requirements

Finance and procurement unit is responsible for processing transporter payments; preparing and evaluating bids, contracting transporters and managing transport contracts. The list of features implemented in CATS to support finance and procurement include:

1. Transporter payment tracking
2. Check preparation and payment record keeping
3. RFQ and price quotation
4. Bid evaluation (financial)
5. Transporter performance

Region user requirements

Whenever regions are involved in CATS processes, they are either triggering processes (in the case of monthly requests) or providing the tail end of reporting (delivery and distribution). In addition there are functionalities used for performing periodic assessments which are used as inputs for preparing annual/semi-annual plans by other units (Early warning and PSNP). At present CATS includes features used by region users such as:

1. Monthly request for Early Warning and PSNP. On monthly basis regions submit their request for assistance from both Early Warning and PSNP through CATS. This request is then processed by Federal units as per the region's request.
2. Needs assessments conducted at periodic intervals to be used as inputs for Federal level planning. This feature is also available for Early Warning section since both EW and regions conduct similar kind of assessments at periodic intervals.
3. Delivery reporting of commodities for dispatch operations. Each month/round Hubs dispatch commodities to FDPs utilizing third-party transporters. The current implementation of CATS allows Regions to report delivered commodities and corresponding amounts through CMPM reporting formats.
4. Distribution reporting of commodities for a particular month is implemented in CATS by basing the format on CMPM designed reporting formats.

Database design

Development of CATS followed a model-first approach whereby structure of the database is dictated by the object model. This approach was chosen because it fits appropriately with the agile way of development the team was following. It didn't require the team to conduct an extensive database schema design ahead of time instead the team evolved the database schema along with the application. This approach has its own advantages and limitations as listed below.
Advantages of model-first approach:

• Database schema evolves together with application logic (model objects)
• Since it focuses on model relations of objects rather than database structure, it gives flexibility to developers on how to design and model the database.
• It was the right fit for a frequently changing database model
• It allowed developers to implement business logic purely in the application layer and not at the database.
• No need for dedicated database developer

Disadvantages of model-first approach:

• It's difficult to have a consistent database model since each developer makes changes to the database
• Naming conventions are difficult to enforce
• Allowed creation of duplicated tables/fields in the database. A number of tables and fields remained unused in the database or are simply contain null values.
• Limitation to follow industry accepted database modelling and design practices means the current database model could suffer from issue related with data duplication and performance.

Database schema and ER diagrams

The following section illustrates the current database model in the form of relational model. It also outlines list of tables and columns which are not used by the application layer in anyway.

Logistics ER diagram

Finance ER diagram

Early Warning ER diagram

Procurement ER diagram

PSNP ER diagram

Regional ER diagram

Hub ER diagram

Database assessment findings

A preliminary assessment on the current database schema identified a number of issues in relation to consistency and database design best practices. This issue include:

• Enforcement of constraints at the database layer such as required fields, foreign-key uniqueness and size of content in the field
• Relationships are enforced at the application layer and not at the database itself. This kind of implementation is suspected to cause performance issues during data retrieval.
• Naming inconsistency throughout the database.

This section outlines findings of the assessment for each table. It should be noted that tables not listed below does not necessarily mean that they are free from the above limitations rather it's intended to highlight the fact that a proper database refactoring should take place to ensure that CATS database is in accordance with common database design best practices and documented well.

Object-table mapping

In a layered application architecture the middle-ware or application layer serves as a bridge between the object model layer and the relational world of RDBMS. This section documents tables which are not used from the application layer.

Orphaned fields – fields that are found in none null/orphaned tables

New tables created

The following table includes database tables added after the pilot phase as well as during after SLA contract

Service layer middle-ware implementation

CATS adopted a layered architecture to implement its middle layer business logic. This implementation utilizes the repository pattern to access data from the data access layer and exposes business capabilities to the web layer through service classes. The following diagram illustrates the architecture used to implement CATS:

The web layer is the main presentation tier of CATS. It's implemented using ASP.NET MVC and Angular JS Javascript frameworks. One rule of thumb in such kind web application architecture is to move all business logic implementations to lower levels so that they can be reused. The web layer consumes services defined at the middleware by delegating business logic and data manipulation to it.
Service layer is mainly responsible for implementing business rules of the application. This is where all of CATS business logic should be implemented to make it easy to maintain and evolve business rules when the need to change them arises.
Repositories are responsible for providing convenient way of fetching and updating data – CRUD (Create, Read, Update and Delete) operations. By themselves repositories are not capable of communicating with the underlying database but enlist the service of Entity Framework ORM (part of .NET framework stack) to do the job for them.

Service layer implementation

Based on the above assumption the team conducted its assessment which are documented below.

Business logic leaking to other layers

The majority part of the business logic manipulations are done on the controller classes using LINQ query manipulation and other business logic calculations. If business logic is implemented on controller classes then the role of service classes become obsolete. Currently the service layer is mostly used for CRUD operation and if we leave it as it is, it has no value other than being additional layer between the data layer project and web user interface project.
For example under Hub area on view _ReceivePartial.cshtml unit conversion is implemented at the view layer. In some cases, the unit conversion and some business rule constants are directly used on the UI. It is difficult changing the constants and reuses the unit conversion on other user interfaces.

Codebase following defined architecture

During the technical review of the project's service layer and other projects which has dependency on it, the following nine technical issues are identified.

Code transaction

There are partial or intermediate saves with in a single business transaction. But Save changes must be called exactly ones after the business transaction complete. Each action of the project or service methods will either commit or roll back all changes in an atomic manner when it might in fact end up doing a partial roll-back or commit, leaving the system in an inconsistent state.
Example:

• In logistic area on delivery controller EditGRN action.
• In Early warning area on Relief Requisition controller cancel Changes action.
  
  

Code Size (line of code)

Methods should not have more than an average of 30 code lines (not counting line spaces and comments).There are methods which has more than 100 line of code.
Example:

• In Earlywarning area on Request controller GetRequestWithPlan action
• In Logistics area on Delivery controller EditGRN action
• In Cats.services.logistics project on TransferService service PostSIAllocation method

A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
Some of classes in CATS's project have more than 900 lines of code.
Example:

• In Earlywarning area RequestController has 1457 line of codes
• In Procrument area PricequatationController has 1215 line of codes
• In Procrument area TransportOrderController has 1215 line of codes

Code Readability

Suggestion: format the code and write comment.

Unused Commented Codes

Suggestion: remove all unused comments. If the comments are required for future use, write comment which informs other developers the reason why it is commented and its future purpose.

Unused Using(S) Namespace

Suggestion: remove all unused namespaces.

View Models

View models exist on web project (cats), service and model.
Suggestion: Better to reorganize into a single new project or put into one of the projects.

Return True After Unit of Work Save Method

There might be conditions that entity framework save changes return 0 after execution.
Suggestion: make unit work return true if the entity framework SaveChanges method return greater than or equal to 1, else return false

Code Comment Or Code Documentation

No code comment is written for the majority part of the project.
Suggestion: write comment for complicated methods and for other programming elements.

Exception Handling

Generally, the way how the exception handling and log implementation is designed. But, it is not implemented on all the controllers throughout the application.
Suggestion: Implement all the exception handling and logging on all controllers

Transaction pattern implementation

CATS uses double-entry transaction pattern to implement stoke transactions and track commodity movement. Detail information about CATS transaction pattern can be found on CATS wiki at https://ndrmcc.atlassian.net/wiki/display/CATS/Accounting+Patterns+in+CATS. This section assesses the current implementation by comparing to the design on the wiki. It also provides recommendation on how to solve identified problems with the implementation.

1. As the wiki documentation states transactions Table is compact. A key guideline stores only numeric values (foreign keys and amount values)
2. Double entry accounting used to represent the stock movements
3. Even Though it is stated on wiki to use accounting patterns to only represent actual physical movement of stock, instead of using it to represent both the plan aspect and the actual receipt and issue information. In actual implementation plan part of receiving and dispatch had accounting patterns and transaction implemented   
4. Even Though it is stated on wiki to Design the application with the assumption that lack of one part of the workflow does not lock the next person. CATS waits for the input from one process to continue from another process. For example:
   1. If the person who does the receipt among the hubs doesn't do the data entry until the receipt plan is done at logistics.
   2. If Early Warning logistics planner does not process requisition, logistics data encoder won't be able to do dispatch allocation.
5. Partitioned design deployment needs to be incorporate to enhance the overall CATS performance   

Transactions which are not implemented

Challenges in implementing documented pattern

Implementing the documented pattern on the planning aspect of the system is challenging because the planning is continuously changing.

Other concerns related with transaction pattern

Transaction table is designed to store all transaction related fields, which results

• Performance problem to access transaction related service.
• Empty columns on the table.
• Server response time is affected due to low performance
• Extensive data redundancy
• Inaccurate data (transaction table is not normalized )

Data replication

List of tables which are replicated to hubs

The current implementation of replication replicated all table. However, this are list of tables that are mandatory for the proper functioning of the Hub module. This list is found by logging the calls to the database while using the pages on hub module. If a table is missing among this list pages will not work correctly.

How data partitioning is handled and implemented

CATS has many tables containing a number of columns and rows greatly which affects system performance. E.g. transaction and log tables. Data partitioning is not implemented on all tables. Implementing data partitioning on all data intensive tables of CATS, by applying both vertical and horizontal partitioning to most of CATS tables would greatly help optimize the server response time.

Data replication conflicts

Data replication conflict is handled by SQL Server conflict resolution tool. "Last one wins" is used.

Data security and confidentiality

List of tables which store sensitive data

Tables and fields that need to be secured but data is not secured

1. UserProfile (table)
2. Password (field) – Encrypted
3. TransactionBidQuotation (table)
4. Tariff (field) – Not Encrypted

On the application side the following files contain sensitive information but are not encrypted:

• Cats did not implement the full security features of MVC platform, this may result severe damage.
• Controllers are not authorized at all.
• Web.config contains sensitive data, but it is not secured yet.
• Sensitive pages are not TSL/SSL based.

Note: Further security risk assessment from user perspective should be conducted. User experience and engagement:

Rate of usage from end users

Table dbo.log is intended to capture users' activities that goes around CATS system, this may include read, write, update, delete and more. This table consists the following fields: date, thread, level, message, exception, loguser. So far the system captures the number of logins and log outs, message type, and activity, however, it is not fully implemented throughout CATS' entire layers.
Performance is the other key parameter that can be used to measure users' interaction towards CATS. CATS is experiencing performance issues at some pages, the following screen names are some of them: login, dispatch (hub), TransporterPerformance (logistics).
Number of steps required to accomplish a given task is another key measuring parameter, back and forth among screens is also another overhead.

User engagement level

Since CATS is process based implementation it would make it possible to capture the lifetime of a given task. A task has starting and ending points, through its journey different statuses reflected; to mention them out: approved, verified, completed, pending, rejected and so on. Collecting different statuses and combining them with the user experience could tell the completion rate of the task, however CATS is not working in such a way. Many CATS' tables consists of status indicator-field.

User Interface Consistency

The user interfaces of all pages on each case team's uses two different themes and theme changing feature is not currently working. Pages have different kinds of controls for the same kind of usage.
E.g. To display grid like data structure the system used kendo, Telerik and normal bootstrap table controls on different pages. This created different look and feel on pages because this controls have different skins. In general pages have inconsistent UI design, look and feel.

Screen flow map

List of CATS activities and screen flow map document
Early Warning
Gift Certificate

Needs Assessment
Humanitarian Requirement Document (HRD):

Monthly Request

Ration











Logistics
Dispatch Allocation:

Transport Order




Assign Transporter:

Receipt Plan from Local Purchase:

Receipt Plan from Transfer:





Receipt Plan from Donation:

Receipt Plan from Loan:

Receipt Plan from Swap:





Bid Planning:

Contract Admin:


Payment Request:

Hub
Receiving:


Dispatch:


Incoming Transport Orders:










Procurement:
Bid:

Bid Status:










Price Quotation:

Generate Winner:

Winner Status:

Transporter

Finance
Payment Request:


Cheque:

Deployment and operation

Process of pushing changes to production environment

Step 1: Take (Get assigned) an issue on jira to work on
Step 2: Pull remote bugfix branch to local to get up to date version of CATS
Step 3: Create a new local branch with the issue number
Step 4: Make all the changes and commits that are related with the issue specifically on that branch only
Step 5: When the issue is resolved, checkout to the bugfix branch and get the latest version of CATS
Step 6: Merge the issue branch with bugfix and push to the remote branch
Step 7: Commit the changes made to resolve the issue on jira
Step 8: Jenkins, our continuous integration tool, regularly pulls and builds the changes made on that day

Database change management

Step 1: Generate scripts of the changes made to the database
Step 2: During release, we take database snapshots of the database we want to update before we run those change scripts.
Step 3: Run generated database script and make sure all changes are incorporated to destination (dev environment server) and changes doesn't affect the data consistency on dev environment server Security of deployment parameters – user names, password, and configuration files …

Security of deployment parameters

How deployment parameters such as user names, password, and configuration files are secured?
No security measure is in place to protect 'user names', 'configuration files' etc … except for 'passwords' which are encrypted by SQL Database Server.

Configuration and deployment instructions

This is for configuration and deployment instruction for provisioning new instance of CATS. No documented guideline found for deploying a new instance of CATS

User manual and help instruction

This is a report on irregularities found while comparing the latest user manual against the application pages.

User manual

Points looked to discover irregularities are

1. Available Info on the application page but Missing on the manual
2. Available Info on the Manual but Not on the application page.

While going page by page we tried to document pages that are consistent working.
Finding summary

User Manual Review Detail

Accessibility of contextual instruction in the application.

Currently the user manual is not embedded within the system for usage by the end user. On pages of the system there is not much info about what the page is about, How to use and which pages that it is related or dependent on.
Our Suggestions are to add tooltips on buttons and links, create a help button for each page so that on selection it will show help information for the selected page, remove ambiguous UI control names, Include one or two lines of page description (what it is about, how it affect the system) on each page and include a Help button under the Top menu dropdown which will redirect to a separate help web page with searching feature and Proper categorization.

Business workflows

A subsystem that tracks the status of tasks that goes through multiple areas. It helps to track the history of each task at different statuses. For example, it stores task action performed date, performed by, comment and the recently added feature "attaching a file".
Problems found:

• Workflow is not implemented throughout the system.
• The business process definition for workflow does not work on administrator page.
• Implementing a workflow on a business process is very complicated and time consuming for the developers.
• The current workflow implementation should be revised and updated with a better design.

Recommendations

Based on the findings from the review assessment the following recommendations are suggested to be conducted during the extended pilot phase.

Database Design

• • Remove unwanted/unused database rows and tables from the database and make sure that deleted fields won't create system malfunction because it can hinder the performance of the whole system.
  • The logical design of the database, including the relationships between tables, is the core of an optimized relational database. A good logical database design can lay the foundation for optimal database and application performance.
  • Maintain the database relationship which currently implemented on Service layer and ids columns should be captured on relation table on some tables which holds the text values from related tables.

Service layer and middleware implementation

• • To remove business logic leakage from other layers, Conduct a detailed assessment and refactor codebase by moving all business logic into service layer.
  • For the sake of safe complete transaction, call unit of work save changes method after all business transaction complete. Avoid calling unit of work save changes method for each partial transaction.
  • For a better code readability , format the code and write comment
  • Remove unused commented code(s) and namespaces(s)
  • Write comment for complicated methods and for other programming elements.
  • Reorganize view models into a single new project (Data Transfer Object) or put into one of the projects rather putting into different layers of the project.
  • Instead of executing 'return true' statement at the end of each transaction , make the unit work return true if the entity framework SaveChanges method return number greater than or equal to 1, else return false
  • Implement all the exception handling and logging on all controllers
  • Query and business logic code optimization for better performance

Transaction Pattern

• Breakdown transaction table in to number tables for better normalization.
• Reduce redundant information to increase the speed of updates and improve concurrency. Reducing data also improves the speed of backups and data replication, because less data has to be backed up and replicate.
• Employ Data Partitioning to big and unused/rarely used/ tables for better query performance.
• Enforce strict implementation of code first approach
• Normalization must be used as required, to optimize the performance.
• Use constraints (foreign key, check, not null ...) for data integrity. Don't provide whole control to application code.
• Document database design with ER schemas and instructions. Also write comment lines for triggers, stored procedures and other scripts.
• Use bit fields for Boolean values.

Data Replication

• Reconfigure replication to use only the database tables needed by the hub module.
• Look for better technologies to replace the current implementation of data replication.
• Carry out a rigorous testing on the currently implemented data replication

Data security and confidentiality

Based on what's reviewed, it is clear that the entire system requires clear security feature
implementations.
Looking from both sides (Database and Application), there are some workarounds that can be done
to achieve such functionalities:

• Database side: tables or fields that are presumed to contain sensitive data require full content encryption.
• Application side:
  • Implement the proper MVC security features: Controllers and actions should be annotated properly.
  • The file Web.Config has to be somehow secured enough – Encryption can be done for specific sections within the config file: those where sensitive data is stored in are for example: ConnectionString, AppSettings,
• If possible, implement TSL/SSL security features. Such security protection can be obtained from third party service provider companies: this will guarantee that the entire system is safe and protected: e.g.: COMODO (https://www.comodo.com) is a renowned company that provides different real time protections against different cyber-attacks.

User experience and engagement

• • The user interfaces should be designed in a way to increase productivity, ease of use and decrease users learning curve we should implement best practices of web app UI Development. Some of this best practices are:   across pages assign the same and consistent naming for buttons and links that do similar operations, place these buttons around the same location on the pages and Give more emphasis to important elements of the interface in order to make users focus on them. 
  • Some activities require number of steps to accomplish a given task ,minimize some screen workflow activities to follow a simpler steps so that users won't get tired of going back and forth in each screen

Deployment and operation

• Process of pushing changes to production environment: Start using automated continuous deployment tools like GO.CD or Jenkins.
• Database change management : Employ automated source control tools like LIQUIBASE for database versioning
• Security of deployment parameters : Encrypt all sensitive data in database and files
• Configuration and deployment instructions : Document a standard guideline for deploying CATS

User Manual and help instruction

• The use of a user manual is to assist the end user anytime for the proper usage of the system therefore the user manual should be available to the end user easily. We suggest that the user manual to be available online embedded within the main system, so whenever the end user is in need of help on a page, a help button on top of the page can redirect to the help page for the selected page. The online user manual should also have a search feature and frequently asked page.
• Organize the angular and any other JavaScript codes in to separate file using MVC design pattern so that is easy to maintain the project and it improves the readability of the UI code.

Business workflow

• • Revise the current workflow implementation and update with a better design
  • The workflow business process definition should be done on the administrator page.