1. Project Portfolio
Discovery Life
By Jaco Koekemoer
Date: 2016-08-31
General Information
Environments
The environments that we worked in while I was at Discovery was the following:
• Local environment: This refers to the developer’s own PC, where initial
development is done.
• DEV environment: Once the developer is done developing in his local
environment, the code is deployed to a DEV environment, where the developer
can test his code changes. The DEV environment is a full environment, with all
Java code and a full database structure with test data.
• QA environment: Once the developer has tested on the DEV environment, the
code is promoted to the QA, or Quality Assurance, environment, which is also a
full test environment. There are dedicated testers that are employed to test the
code in this environment. Once the testers are done testing the code, the work to
be tested is handed over to the business area, who does their own testing
• Production environment: Once a quarter, all code that are tested in QA, the
new code is deployed to production, where it is used by business for performing
their required tasks.
Quality Management Software
Discovery uses quality management software for managing new requirements, and to
manage production defects. New requirements are logged in this software by various
potential parties in the company. The logged item is assigned to the Business Analysts
(BA) for preparing a business specification. Once the BA is done with the spec, the item
is assigned to the applicable Systems Analyst (SA) of the applicable system to which
the requirement applies. The SA would then either prepare a technical specification and
assign the work to a developer who will code the requirement under the supervision of
the SA, or the requirement would be assigned to a developer, who would create the
system spec and implement the requirement in code. Once the development is done,
the he/she assigns the item to a tester for testing, and from the tester to an individual in
business for testing. If database work is required, an item linked to the original item is
logged, which is assigned to the database development team.
Updating of Wiki pages

2. At times, I would use the knowledge that I had built up, to write up internal wiki pages,
which was accessible to all developers. The wikipages consisted mostly of explanations
of existing system components, and the business background to some systems.
Reverse Engineering
In order to understand current systems, and the code, I would have to perform some
reverse engineering. I did this by going through the code and drawing UML diagrams,
especially class diagrams, either by hand or using a UML tool. I would also type out
pseudocode in a Word document, as a means of translating the code to human
readable language. Mindmapping is also a tool that I used a lot in order to understand
system logic.
Note taking, ad hoc class diagrams, mind mapping
I tend to make a lot of notes in various forms, as a personal means of processing
through huge amounts of information, and to understand and gain knowledge. I
normally type up notes in a Word, draw ad hoc class diagrams, or create mind maps. I
find mind mapping especially helpful in meetings, for working through a new business
specification, and for reverse engineering code.
Process flow
In Discovery, we used the Waterfall model in a repetitive manner where process flow is
concerned. Requirements are gathered by Business analysts, who would perform
analysis from a business perspective. The developers and systems analysts would
perform a technical analysis. The developers would then write the code, after which
dedicated testers and the applicable business area would test the code. Thereafter, the
code is deployed to production on a quarterly basis.
Source Control
Source code was managed by the developers using GIT. Development efforts was
usually towards a single production deployment at the end of a quarter. A remote
branch would be created for a single release in GIT, while the developer would also
create a local copy of this branch. The developer would also create a separate branch
locally, based in this release branch
Build Tools
In Discovery, internal developers built custom tools for the compilation and deployment
of source code which was used by all developers, however, these tools were built
around Apache Ant. The developer was never required to modify or create Ant build
XML files, since the custom tools isolated the developer from this.
Unit Testing

3. As part of my development efforts, I include unit testing in order to test single units of
code.
Hands off
Due to the size of the systems at Discovery, there are certain aspects in the systems
team which Java developers never deals with, but rather, there are separate teams for
certain functions, which includes the following:
1. Business Analysis: Business analysts are responsible for gathering
requirements from users, which means that this is never performed by Java
developers.
2. Database Development: Java developers do not have access to create
database tables, stored procedures, or anything related. Rather, Java developers
have to formally request such work using the quality management software.
3. Database administration: DB administration aspects, such as access rights to
the database is also performed by a separate team.
4. Systems Infrastruction: The infrastructure of all environments, which includes
application server instances and deployment to QA and production environments
are handled by this infrastructure team, and not by Java developers, with
exception to the DEV environment, where a single individual in the Java
development team, usually a systems analyst, is responsible for deployment to
DEV.
5. Systems Architecture: Architectural aspects of the system, such as the system
framework, integration framework, or database access from a Java perspective,
is handled by a separate architecture team, and not by the Java development
team who implements business rules.
I was involved in implementing business rules received from business.
Technical Specifications: For larger projects, I was required to create a technical
specification, which is derived from the business specification received from a business
analyst, combined with my own analysis of the system and how the requirements are to
be fulfilled within existing system structures and components. This spec included a Use
Case View which depicts system requirements as UML use case diagrams in multiple levels of
granularity, a Process View consisting of UML sequence diagrams depicting the sequence in
which key requirements are fulfilled, a Logical View consisting of UML class diagrams, a Data
View depicting affected database tables that are created or modified, and User Interface
requirements depicting screens that are to be modified or created.
Patterns Used
Design patterns was also used in the system that I worked on, which includes the following:

4. • Factory Method: I would create a factory method when a class of a certain type had to
be created, based on certain conditions
• Template Method: I used this pattern for creating small frameworks, where a main
process is defined in a parent class, but the implementation of certain methods are
deferred to child classes.
• Singleton: Singletons was mostly applied to factory classes, which required only a
single instance, and which created other classes.
• Iterator: This pattern is synonymous with Java’s Collection Framework, so this pattern
was used only when dealing with this framework.
Discovery specific patterns
The following are some of the patterns that are used in Discovery Life systems:
• Command Pattern: The traditional GoF definition of this pattern was not applied to it’s
use in Discovery, but rather, a command represents a single unit of code that performs a
specific function, such as retrieving policies in the database.
• Populators: Populators are used to populated data that is related to a specific object. By
chaining populators together, an entire object, and all it’s data can be loaded from the
database.
SOLID Design Principals
Discovery also encouraged there developers to apply the following design principals from
SOLID when coding:
• Single Responsibility Principal
• Open Close Principal
• Liskov’s Substitution Principal
• Interface Segregation Principal
• Dependency Inversion Principal
I was made aware of these principals, but I did not fully apply them in my code as desired.
Production Support
The developers were also involved in performing production support, but this was a less
desirable function to perform.
Technical Designs
At times I was responsible for creating technical designs based on the business specifications
and my own analysis. I used a tool called Enterprise Architect for the creation of UML models,
mostly use case diagrams, class diagrams and sequence diagrams.
My strengths: I am a perfectionist in many areas of my life, which includes many aspects of my
coding. I am very meticulous in my work. I tend to unit test as much as I can. I also have to first
design and put down on paper what I have to develop before touching code. I rarely jump
straight into coding, especially with large projects.

5. My weaknesses: I tend to work slowly, because of the fact that I am so meticulous. I also tend
to become frustrated when facing cryptic exceptions in the code. I’m not always quick to see the
source of my own errors.
Conclusion
In conclusion, as a Java developer, I also worked as part of a team in a collaborative
effort, in order to complete projects. I also had to liase with other teams at times.
Furthermore, I was involved in training, guiding and assisting junior members of the
team. I also worked under a systems analyst, who provided me with guidance and
assistance, and who allocated development work to me.
Claims and Finance Projects
The following is a summary of the larger projects that I had to work on while I was working for
Discovery Life Systems, in the Claims development team and the Finance development team:
Legacy Claims
I built a component that had to access data from a legacy set of tables for viewing historic
claims. The development included database access via the current system framework, business
logic and user interface. Technology that was used is the struts web framework, Oracle
database, the company’s own custom framework for transactional operations and JDBC.
HPP Payments
The requirement was to augment the current payment solution in the system, for the creation
and validation of payments of one of the Discovery products. Before development started, I
used the business specification received from the Business Analyst, together with my own
analysis of the current system, and compiled a technical specification as described earlier in this
portfolio. The solution included user interface screens, the struts web framework, business logic,
and the company’s existing framework. The project also used webservices for calling a remote
system.
Convert UI for new application server (JSP to XHTML)
The company decided to change it’s application server used to run it’s internal system, and
therefore the system user interface artifacts had to be converted from JSP to XHTML. I was
responsible for this conversion on selected projects.
Dollar Life Plan
Discovery Life introduced this new product, for which I was responsible to create components
related to the searching, viewing and management of those payments for this product. This
work was done under the guidance of a systems analyst, who prepared the technical spec for
this project, while I did the development. The technology used in the project was JSF with
XHTML, the company’s Java based framework, and Oracle.
Intermediary Credit Control
This was the largest project that I worked on in Discovery, which consisted of roughly 165 new
and modified files. The project was a rewrite of 2 existing components. One component is used
by external brokers to capture payment requests on behalf of clients, while another component

6. is used by internal staff to receive and action those payment arrangements. I was responsible
for analysing the business spec, analysing the existing code, and then creating two new
technical specifications. I also implemented the solution. The project technology used the
company’s existing Java based framework, Primefaces and Oracle.
Embedded SQL
The project required me to analyse Java code that contained embedded SQL, and determining
how to move this embedded SQL to stored procedures in the database.
Fixing many production defects
I was also required to fix up many production defects in the system. A product defect was
logged by the business areas, which the developers received and fixed up for the next quarterly
production deployment.
WIKI Articles
I also believe in the sharing of knowledge in a development team, and so for this reason, I spent
a considerable amount of time writing articles for an internal wiki page for different teams that I
worked in. I took some of the notes that I had made over the years, and wrote articles,
explaining different parts of the system from a technical and business perspective.

7. is used by internal staff to receive and action those payment arrangements. I was responsible
for analysing the business spec, analysing the existing code, and then creating two new
technical specifications. I also implemented the solution. The project technology used the
company’s existing Java based framework, Primefaces and Oracle.
Embedded SQL
The project required me to analyse Java code that contained embedded SQL, and determining
how to move this embedded SQL to stored procedures in the database.
Fixing many production defects
I was also required to fix up many production defects in the system. A product defect was
logged by the business areas, which the developers received and fixed up for the next quarterly
production deployment.
WIKI Articles
I also believe in the sharing of knowledge in a development team, and so for this reason, I spent
a considerable amount of time writing articles for an internal wiki page for different teams that I
worked in. I took some of the notes that I had made over the years, and wrote articles,
explaining different parts of the system from a technical and business perspective.