2023-04-26

SOFTWARE DUE
DILIGENCE
PROJECT ALPHA
 Page |2

TABLE OF CONTENTS
1 INTRODUCTION .............................................................................................................................................. 3

2 EXECUTIVE SUMMARY ................................................................................................................................... 4

2.1 Software development processes and organization ................................................................................. 4

2.2 Software Code Quality and Technical Debt ............................................................................................... 4

3 TECHNICAL ANALYSIS ..................................................................................................................................... 5

3.1 System Design Overview ........................................................................................................................... 6

3.2 Code Quality .............................................................................................................................................. 7

3.3 Code Quality Trends and Predicted Future of Code Quality ..................................................................... 8

3.4 Team Dynamics ......................................................................................................................................... 9

3.5 Security .................................................................................................................................................... 12

3.6 Open-Source ............................................................................................................................................ 12

4 INTERVIEWS ................................................................................................................................................. 14
4.1 Background, Purpose, and Scope ............................................................................................................ 14

4.2 Team, Roles, and Organization ................................................................................................................ 14

4.3 Requirements Process ............................................................................................................................. 15

4.4 Development Process and Release Processes ......................................................................................... 15

4.5 QA, Test ................................................................................................................................................... 15

5 NEXT STEPS .................................................................................................................................................. 16

5.1 Recommendations and Topics to Discuss ............................................................................................... 16

6 TERMINOLOGY ............................................................................................................................................. 17

7 TOOLS ........................................................................................................................................................... 17

8 AUTHORS ..................................................................................................................................................... 18

APPENDIX A. ARCHITECTURAL OVERVIEW....................................................................................................... 20

APPENDIX B. LIST OF DEVELOPERS .................................................................................................................. 23

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |3

1 I NTRODUCTION

System Verification has conducted a Software Due Diligence of project Alpha. The purpose of the
Software Due Diligence is to provide an assessment of how well the project compares with peers
when it comes to software code quality, scalability of technology, organization, and architecture.
This report is based on a technical analysis of the software source code. It is performed with state-
of-the-art tools to identify complex code with high maintenance costs, and/or security vulnerabilities
considering the historical evolution of the code. The technical analysis is further supplemented by in-
depth interviews with key employees in the development organization of project Alpha.
This document shall be considered as an independent review and data driven foundation for further
discussions. It shall not be considered a recommendation whether to invest in project Alpha.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |4

2 E XECUTIVE S UMMARY
2.1 SOFTWARE DEVELOPMENT PROCESSES AND ORGANIZATION

Based on our interviews the project Alpha is managing the process of feature definition and
requirement breakdown well. They have overbridged the challenges related to having a
development site in Hanoi and provide efficient ways of gathering and follow up features to be
developed. All processes, as requirements, development, and test, are structured and documented,
and the tools used are supporting them well.
However, as shown in the technical analysis, there is a need to improve code quality to avoid many
of the problems related to it, and to reach a steady flow through the development life cycle. The
end-to-end flow could be dramatically improved by increasing maturity within the Development,
DevOps and Test Team, and getting automated CI/CD pipeline in place, where automated tests are
included prior to any deployment. This will in the long term have a high impact on lower the cost of
getting new features into production.

2.2 SOFTWARE CODE QUALITY AND TECHNICAL DEBT

The code quality ranks below the average of what would be expected. This means higher
maintenance costs and higher costs developing the software further.
A targeted effort to prioritize refactoring to break the negative trend in code quality should be
made. By doing so the code quality will increase together with the maintainability and the ability to
comprehend the code.
Open-source dependencies are well-documented, but with a result below reasonable expectation.
The most acute problem is a potential missing license which demands immediate further
investigation.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |5

3 T ECHNICAL A NALYS IS

Overall code quality varies in the project with products

having higher, and lower, code quality than the average
in the complete project.
The analysis displays prioritized technical debt in all
products where the product Resource Central stands
Code Quality out with more than 50% of the estimated refactoring
work.
Investments should be made to refactor the part of the
code with lower quality to increase the maintainability
and to make the code less error prone.

Looking at the team dynamics in the complete Alpha

project unveils that the code familiarity, e.g., the code
written by active developers is generally low.
Especially two of the products suffer from very low code
familiarity. Low code familiarity is considered a risk,
Team Dynamics especially in combination with low overall code quality.
Furthermore, eight developers are identified as key
contributors in the complete Alpha project in terms of
experience. It is of great importance to secure these
eight persons to not deteriorate the knowledge of the
codebase even further.

The result from the security analysis is on par with the

top of class assessments performed by System
Verification in the past. The result from these tests
states that the project is on top of security with only
three issues found.
Security All in all, this should ensure that the security is good and
up to standard.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |6

All the dependencies used in the project are well

documented in the documentation that has been
handed over as a part of the transaction.
Throughout the dependencies there are 194
vulnerabilities (critical, high, medium) found in the
Open-source project, where the vast majority is found in the Office
Place product. This result is well above what we
Vulnerabilities
normally see in a project of similar size.
There is also a potential licensing problem with one
dependency within the Office Place product. This needs
immediate attention since this can be very costly and
complex to solve.

3.1 SYSTEM DESIGN OVERVIEW

Project Alpha has chosen to have a technical architecture mainly written in C#, JavaScript, and
TypeScript. All languages are well-known and popular, meaning that the choice of technology does
reduce the risk of not finding developers with good experience of the languages chosen.
The code itself is documented in different ways depending on the scenario. They are using the self-
explained code convention, in-code class and methods description, and in-code comments to
document the actual code. Above that they have API specifications, and core framework
documentation to work as a guide for developers building applications on their solution.

LAN GUAGES FILES LINES OF C ODE

C# 4,525 759,686

JavaScript 1,780 502,577

TypeScript 773 36,425

Table 1 Top languages used in Resource Central.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |7

LAN GUAGES FILES LINES OF C ODE

JavaScript 6,058 646,581

C# 10,181 466,289

TypeScript 5,925 180,625

Table 2 Top languages used in Office Place.

LAN GUAGES FILES LINES OF C ODE

C# 1,702 432,987

JavaScript 192 187,349

Table 3 Top languages used in Digital Signage.

The analyzed products in project Alpha consist of Resource Central, Office Place, and Digital Signage.
The Workspace product is also included as a part of the Digital Signage codebase. The respective
architectural overview of the products can be found in Appendix A.
Looking through the high-level architecture, the division of the products is good with no change
coupling detected; meaning if two (or more) modules change together over time.

3.2 CODE QUALITY

The codebase of project Alpha is of varying quality with one product being on par with that of the
Code Quality Index, while the other two are below. The index is based on multiple similar analyses
performed against other companies. All three products have prioritized technical debt to address,
but naturally the amount is bigger in the two products with lower quality.

3.2.1 RESOURCE CENTRAL

The overall quality of this product is on par with the average score of the project Alpha codebase.
There is also a higher rate of abandoned code which makes the refactoring work a potential risk
since the current team doesn´t have full knowledge of the product codebase.
Re-factoring these parts of the code, in the top prioritized files, will approximately cost 4500 man-
hours estimated on our experience and various studies. The monetary cost varies depending on the
salary situation in the country of development and how extensive the verification needs to be.

3.2.2 OFFICE PLACE

The overall quality of this product is above that of the average score of the project Alpha codebase.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |8

Re-factoring these parts of the code, in the top prioritized files, will approximately cost 500 man-
hours estimated on our experience and various studies. The monetary cost varies depending on the
salary situation in the country of development and how extensive the verification needs to be.

3.2.3 DIGITAL SIGNAGE

The overall quality of this product is below that of the average score of the project Alpha codebase.
From a codebase perspective, the Workspace product is included in this product. The code quality of
the Workspace product is on par with the average for the complete project Alpha codebase.
Re-factoring these parts of the code, in the top prioritized files, will approximately cost 1800 man-
hours estimated on our experience and various studies. The monetary cost varies depending on the
salary situation in the country of development and how extensive the verification needs to be.

3.3 CODE QUALITY TRENDS AND PREDICTED FUTURE OF CODE QUALITY

This section of the report will give insights into predicted code quality in the coming 6 months. How
will the code quality evolve if the project chooses not to take additional actions on identified
technical debt? This prediction is partly based on historical trends but also on collected data from
similar project analyses made in the past.
A negative trend is always good to act upon early, otherwise the re-factoring work tends to be both
harder and more expensive. Code of lower quality is also both harder to maintain and easier to
create defects in.

10 Overall quality in the Resource Central product is

5 and with slight negative trend over the last year.
5 Invest in refactoring the code to break the
negative trend. By continuously investing in
0 refactoring work the code quality will increase
and with that the maintainability together with
the readability.
Resource Central

10 Overall quality in the Office Place product is 7 and

with slight negative trend over the last year.
5 Invest in refactoring the code to break the
negative trend. By continuously investing in
0 refactoring work the code quality will increase
and with that the maintainability together with
the readability.
Office Place

W W W . SY ST E MV E R I FI C A T IO N . C O M
 Page |9

10 Overall quality in the Digital Signage product is

close to 4 and with a negative trend over the last
5 year, but especially over the last month. This
negative trend is because impairments have been
0 made to the files containing prioritized technical
debt. Refactoring of the prioritized technical debt
will break the trend and increase overall code
Digital Signage quality and maintainability.

3.4 TEAM DYNAMICS

Organizational trends are good for further discussions about the team’s composition and
performance. What are the underlying factors to the eventual problems? Is Alpha project facing an
architecture that is hard to develop on, or is the team working in the wrong way?
Combining this data with the understanding of areas with potential Knowledge Loss makes it easier
for decision makers on where to broaden/share knowledge to secure good progress in the project.

3.4.1 ORGANIZATIONAL TRENDS

Adding or removing people in a project always comes at a cost due to lower code familiarity and
repeated on-boarding effects. Sometimes a development effort is appropriately staffed, but it takes
time for people to get up to speed with a new codebase. Hence, the team composition in terms of
experience is an important factor.
Figure 1, Figure 2, and Figure 3 unveils the number of active authors in respective product. The
number of active authors (black dotted line) has been consistent over time for Resource Central and
Digital Signage, although an increase with a following decrease can be seen for Resource Central. A
high increase in active authors for Office place is seen in early 2022, but in the last 6 months this
increase has gradually rippled down with a 50% loss in active authors. Alpha has a strategy in place
to retain key developers that have been in the company for a long term. In combination with this
long-term strategy, they also try to recruit new talents directly from the universities. In this latter
group there are developers more willing to move on and the fluctuations seen in the graphs below
can be explained by this.
A complete list of active developers with their respective experience can be found in Appendix B.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 10

Figure 1 Development output relative the number of authors for Resource Central

Figure 2 Development output relative the number of authors for Office Place

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 11

Figure 3 Development output relative the number of authors for Digital Signage

3.4.2 CODE FAMILIARITY

The overall code familiarity in the Alpha portfolio is 47%. This result is on the lower scale of what
could be considered as good code familiarity. Having low code familiarity in conjunction with low
code quality is considered a risk. Developers less familiar with complex code entails a greater
likelihood of introducing new errors during development.
The current code familiarity level is calculated as an average over all three products. Assessed
individually, there are two products with very low code familiarity. For those two products the risk is
naturally higher for creating erroneous code.
Table 4 shows the code familiarity per product; meaning how much of the code in respective
product is written, or known, by an active contributor. One key developer for the Office Place
product has recently left the company. This drop in code familiarity is explained by the alternative
figure in Table 4 for the Office Place product.

PRODUCT CODE FAMILIA RITY

Resource Central 28%

Office Place 38% (72%)

Digital Signage 99%

Table 4 Code familiarity per product.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 12

The authors listed in Table 5 are identified to be the top, active, contributors in project Alpha.
Securing these people is crucial for the consistency of the project.

PRIMARY FILE
AUTHOR PRODUCT MONTHS
OWNER

Dung Nguyen Van Resource Central 60 522

Cuong Tran Duc Resource Central 43 260

Hung Le Van Resource Central 47 160

Hoang Bui Thai Office Place 15 4,228

Pham Ngoc Chinh Office Place 16 1,542

Binh Tat Vu Office Place 15 1,087

Hung Giang Van Digital Signage 42 600

Long Nguyen Xuan Digital Signage 39 187

Table 5 Top contributors in terms of primary file owner for the different products.

3.5 SECURITY

The Alpha project has been analyzed using an external security tool. Going through the result states
that the project is on top of security with only three issues found:

 2 medium severity issues related to exposed ports.

 1 low severity issue related to stealing cookies.
This result is very good and on par with the assessments carried out by us in the past. Despite these
issues, the overall security is good and up to standard.

3.6 OPEN-SOURCE

Getting the full picture of known vulnerabilities in the open-source dependencies together with
open-source license compliance is important for potential investors. License issues can be complex,
up to interpretation, and costly over time.
The three different products Resource Central, Office Place, and Digital Signage have all been
scanned for both vulnerabilities and license compliancy within the dependencies used.
The scan resulted in 258 vulnerabilities of different severities among the three products distributed
between the products as below:
 Resource Central: 5 critical, 27 high, and 11 medium

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 13

 Office Place: 30 critical, 85 high, and 28 medium

 Digital Signage: 3 critical, 2 high, and 3 medium.
N.B. Only vulnerabilities of medium severity and above are listed.
This result is higher than what we normally see, especially for the Office Place product. All
vulnerabilities should be manually investigated to exclude any possible false-positives with the
prioritization critical to medium.
The result reveals two mutual problems within the vulnerabilities. Either the dependency is using an
outdated version with known vulnerabilities or the lockfile needs to be updated. The lockfile
vulnerabilities are easily fixed by updating the dependencies listed in the lockfile without having to
update the dependency file. Outdated dependencies are easily updated if the version step is minor
or micro, e.g., 1.x.x to 1.y.y. In that case backwards compatibility should be guaranteed. However, in
the case of major revision change there are most likely changes made to the public API. These
updates require more investigative work prior to the actual update. Otherwise, the risk is that the
service stops working post update.
Licenses have been checked for all dependencies used throughout the codebase (Resource Central,
Office Place, and Digital Signage). A possible violation can be seen for bzip2-1.0.6 dependency for
add-on-products/BFF repo for the Office Place product. No valid license can be found for this
dependency, and this must be immediately investigated. For all other dependencies there are valid
licenses, although the risk for any dependency using General Public License (GPL) is higher. Especially
in the case when the product using these dependencies is offered as on-prem solutions.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 14

4 I NTERVIEWS

4.1 BACKGROUND, PURPOSE, AND SCOPE

In addition to the technical analysis, where a data-driven approach is conducted using a subset of
tools, System Verification has had four interviews to cover the more process related aspects of the
software development life cycle. The people interviewed are presented in Table 6.

INTERVIEWEE DATE SCOPE

Simon Fisker 2023-04-13 Requirement process

Minh Nguyen 2023-04-13 Development process

Ben Phung
Son Le Thanh

Minh Nguyen 2023-04-14 Quality Assurance process

Son Le Thanh
Chi Nguyen Thi Van

Minh Nguyen 2023-04-14 Deploy and DevOps processes

Son Le Thanh
Table 6 Interviewed persons.

The purpose of the interviews was to complement the technical analysis in assessing the ways of
working with respect to the different phases of the development life cycle, including scalability of
organization, technology, and architecture. During the interviews we covered, for example, history
of product(s), team compositions, roles, vision and goals, requirements elicitation, development
process, iterations and cadence, tool usage, test strategy and release process.
The Interviews were perceived as both positive and open. The topics mentioned above were
discussed in detail and we tried to challenge the answers and find improvement areas. More results
are provided in the following sections.

4.2 TEAM, ROLES, AND ORGANIZATION

Team consists of a management lead and 3 different Product Owners, each driving their own
development team setup consisting of in total 4 team leads, 27 developers, and 14 testers cross
different sites.
The organization manages a mid to large sized customer base and is streamlined to manage this in a
good way. Working with these type of customers points out the importance of communication,
process maturity, and a well-established way of working.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 15

Once every quarter, management and organization meet to update (led by the PO’s) the upcoming
scope and backlog items, by doing a strategic directive adjustment.

4.3 REQUIREMENTS PROCESS

Product owners are running the requirements process in a classical agile way. A roadmap is defined
and updated on quarterly basis, where the team in Hanoi is involved. There is a high level of
involvement of customers as input-source for new development, combined with support and feature
requests from the product strategy backlog. When handed over to the development team the
requirements are broken down to technical tasks, test cases are created prior to development and
product owners are validated those to secure and validate expected outcome.
As a foundation of all further activities, the maturity of the requirement process is a prerequisite to
enable a steady flow through the development life cycle. This is even more important when the
requirement team is not at the same location as the development team such as in the project Alpha
team structure with one part in Denmark and one in Vietnam.
Based on the interviews we believe that team Alpha has solved those challenges well and shows a
high maturity through the whole requirements process.

4.4 DEVELOPMENT PROCESS AND RELEASE PROCESSES

As mentioned above the requirement breakdown process provides a good foundation for the
development teams. Then, by using SCRUM methodology, sprints and backlog are planned, technical
tasks sorted, estimated, and executed with a clear definition of done.
Sprints are developed in 2-week sprints and going to production in 2-3 services releases per year.
Additionally, another 2-4 hard fixes are released yearly.
The development team adopted a DevOps approach (2019) and is currently developing a pipeline to
improve the stability in the development process ahead.
As a structured way of working is in place regarding development activities, it was mentioned during
the interviews a need of more maturity within the development teams (the results from the
technical analysis in terms of code quality confirms that observation) and to introduce a skilled
DevOps resource to help them going forward to a full implemented DevOps set up.
From our point of view a survey should be conducted to identify skills needed and set a resource
strategy to set a good foundation to improve in those areas.

4.5 QA, TEST

Even in the QA processes the Alpha team showed a structured and documented way of working. The
testers create test cases early in the process and as soon as features are under test an efficient
feedback loop is in place where the Product Owner could act and give necessary feedback to both
developers and testers. Additionally, load and stress tests are included in the overall scope of test
activities.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 16

However, as shown in the defect’s statistics provided in the VDR, a clear QA strategy is missing to
reduce the number of defects that is showing a negative trend. Note that a QA strategy should not
only address the test processes but also prevent and reduce the number of defects in general,
meaning addressing QA within the development process (code guideline, unit test, static analysis,
and code reviews). The high level of testers (12 testers for 24 developers) might indicate a way to
solve the problem in a reactive way instead. Additionally, there is a low coverage of automated tests
that could help to identify defects earlier to avoid unnecessary cost related to manual tests.
However, as mentioned during the interviews there is a lack of competence within this area.

5 N EXT S TEPS

5.1 RECOMMENDATIONS AND TOPICS TO DISCUSS

Below we list points and topics we believe are of top priority in further discussions with the project
Alpha team.

 Immediately investigate the missing license for one of the open-source dependencies to rule
out a potential false-positive.
 Secure key developers to mitigate the low code familiarity.
 Invest in more senior developers to increase maturity.
 Break the negative code quality trends by refactoring.
 Invest to finalize DevOps gateway maturity in the pipeline.
 Integrate more skilled testers for automated tests.
 Increase automated test coverage suite.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 17

6 T ERMINOLOGY

Code Quality Index: A weighted average on Code quality. The average is derived from numerous
analyses made of similar projects.
Technical Debt: Technical debt is code with low Code quality and could be compared to paying
interest on a bank loan - the bigger the loan, the bigger the interest. This code requires frequent
work by the development teams and such code is very likely to have a direct effect on the business
and product roadmap since each change is more expensive and carries an unnecessarily high
delivery risk.
Prioritized Hotspots: Hotspots are files where you have most development activity. If a Hotspot also
has low code quality, it is a Prioritized Hotspot.

 Low code quality in a development hotspot is expensive and should be prioritized in terms of
quality improvements.
 Low code quality in stable parts, i.e., a non-hotspot, has lower priority in terms of quality
improvements.

7 T OOL S

Below is a description of the main tools used for this assessment:

CodeScene: CodeScene is a behavioral code analysis tool providing code visualizations based on
version-control data and machine learning algorithms that identify social patterns and hidden risks in
code.
Debricked: Debricked automates the process of managing vulnerabilities in open-source
dependencies. Continuously identify, prevent, and fix vulnerabilities with this tool.
Furthermore, the tool checks for license compliance.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 18

8 A UTHORS

Marcus Lundström

Marcus is a product specialist within Software Assessments at System Verification, and he is a

member of our senior inhouse Tech Team. He has 15 years of experience from Sony, Ericsson, E.ON
et. al, and has held different senior development and leadership roles during his career. Marcus
knowledge goes all the way from hands on programming to test and test management, and he holds
deep knowledge of the latest development trends and tools.
Jonas Elmer

Jonas is a technical test specialist with 19 years of experience from companies such as Sony, Ikea,
Qlik and Axis. As a professional he is always looking for new solutions to complex problems, and he
has been a very appreciated team player on many of his assignments. He is not only a skilled
technical tester, but Jonas also possesses a strong solution-oriented mind.
Eric Järdemar

Eric is a senior leader and test manager with strong focus on delivering tangible results. He has been
working with software quality since 2005 and during the years he has gained great understanding of
software development from an end-to-end perspective. During his career he has held roles at e.g.,
E.ON., Borg Warner, Securitas and Trelleborg, and he has been involved in all parts of the QA
process, from requirements to acceptance through every step of software development life cycle.
His main focus is within analysis and QA process improvement, where he helps setting up and
implement test strategies based on customer specific needs in order to reach their quality goals. Eric
is also team and delivery manager of our Tech Team that work with different types of Software
Assessments.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 19

Christian Holmberg

Christian has been working in the tech industry the last 15 years, and he is known for being a very
skilled product manager and product owner. Christian’s focus has always been the interaction
between tech and people, and he emphasizes an agile and data driven approach when facing new
challenges. Christian has held many different senior roles on Sony Mobile, and he is part of System
Verifications extended Tech Team.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 20

Appendix A. A RCHITECT URAL O VE RVIEW

Figure 4 Architectural overview of Resource Central.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 21

Figure 5 Architectural overview of Office Place.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 22

Figure 6 Architectural overview of Digital Signage.

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 23

Appendix B. L IST OF D EVELOP ERS

ROLE AND EXPERIEN CE OF RESPECTIVE

NA ME PRODUCT
PRODUCT

Hung Giang Van Digital Signage Developer, 42 months

Long Nguyen Xuan Digital Signage Developer, 39 months

Ninh Nguyen Huu Digital Signage Developer, 15 months

Trung Tran Duc Digital Signage Developer, [no data]

Duc Doan Minh Digital Signage Developer, 1 month

Hung Pham Van Digital Signage Developer, [no data]

Minh Nguy Phan Office Place Developer, 16 months

Hoang Bui Thai Office Place Developer, 15 months

Binh Vu Tat Office Place Developer, 16 months

Hoa Nguyen Thi Office Place Developer, 1 month

Dai Phung Van Office Place Developer, 12 months

Chi Nguyen Thi Van Office Place Developer, 10 months

Quynh Dang Thi Office Place Developer, 0 months

Bich Dinh Thi Office Place Developer, 5 months

Tuan Tran Manh Office Place Developer, 15 months

Huy Tran Tuan Office Place Developer, 21 months

Ha Tran Thu Office Place Developer, 0 months

Long Ta Quang Office Place Developer, 16 months

Chinh Pham Ngoc Office Place Developer, 17 months

Hung Ta Phi Office Place Developer, 8 months

Ha Nguyen Hoang Office Place Developer, 0 months

W W W . SY ST E MV E R I FI C A T IO N . C O M
 P a g e | 24

Hung Dang Hong Resource Central Developer, 12 months

Thanh Nguyen Van Resource Central Developer, 59 months

Hung Le Van Resource Central Developer, 47 months

Dung Nguyen Van Resource Central Developer, 60 months

Tuyen Nguyen Quang Resource Central Developer, 23 months

Huy Dao Tuan Resource Central Developer, 4 months

Suu Ha Van Resource Central Developer, 8 months

Thanh Hoang Ngoc Resource Central Developer, 1 months

Loc Nguyen Bao Resource Central Developer, 3 months

Anh Nguyen Le Hoang Resource Central Developer, 6 months

Tuan Nguyen Anh Resource Central Developer, 53 months

Long Le Thanh Resource Central Developer, 5 months

Phuc Le Khac Resource Central Developer, 0 months

W W W . SY ST E MV E R I FI C A T IO N . C O M