MULUNGUSHI UNIVERSITY

CENTER FOR INFORMATION COMMUNICATION TECHNOLOGY

EDUCATION. (CICTE)

PROJECT PROPOSAL REPORT

PROJECT TITLE: PHP SOURCE CODE ENCRYPTION/OBFUSCATION

SYSTEM.

NAME: ERIC CHONGO

STUDENT NUMBER: 56012025

PROGRAMME: BACHELOR OF COMPUTER SCIENCE IV

SUPERVISOR: DR D. KUNDA
DECLARATION

I Eric Chongo confirm that the work submitted is my own and the appropriate credit has been given where
reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered
plagiarism.

Author: Eric Chongo

Date:

Signature……………………….……….

Supervisor: Dr D. Kunda

Date:

Signature……………………….……….

1
DEDICATION
This project is dedicated to my father and mother for everything they have done for me since I was born.

ACKNOWLEDGEMENT

First and foremost, I would like to express my deepest gratitude to my Guide, Dr. Douglas Kunda, who has
encouraged and supported me during the project work. I am also grateful to my family, friends, and
colleagues for their valuable help and support during the entire period.

2
Contents
LIST OF ACRONYMS ....................................................................................................................................... 4
CHAPTER 1 INTRODUCTION ..................................................................................................................... 4
1.1 Introduction .....................................................................................................................................................5
1.2 Aim ............................................................................................................................................................6
1.3 Objectives ..................................................................................................................................................6
1.4 Project Justification ...................................................................................................................................6
1.5 Project scope..............................................................................................................................................7
1.6 Summary....................................................................................................................................................7
CHAPTER 2 LITERATURE REVIEW ............................................................................................................. 8
2.1 Software Security Attacks ...............................................................................................................................8
2.2 Software Protection Techniques ......................................................................................................................8
2.2 Code Obfuscation Techniques and Schemes ...................................................................................................9
2.2.1 Identifier Renaming Obfuscation.........................................................................................................9
2.2.2 Control Flow Obfuscation ....................................................................................................................9
2.2.3 Obfuscation Schemes Using Additional Mechanisms ........................................................................11
2.3 Measuring Effectiveness of Code Obfuscation and De-Obfuscation Techniques .........................................11
2.4 Examples of existing source code obfuscators ..............................................................................................12
2.4.1 PHP PROTECT .....................................................................................................................................12
2.4.2 FOPO FREE PHP OBFUSCATOR 2015 ..................................................................................................14
2.4.3 srcProtector 2015. .............................................................................................................................15
2.5 System comparison........................................................................................................................................18
CHAPTER 3 METHODOLOGY/APPROACH ...............................................................................................19
3.1 SDLC .............................................................................................................................................................19
3.2 SDLC Models ................................................................................................................................................20
3.2.1 Spiral Model .......................................................................................................................................20
3.2.2 Extreme Programming (XP) ...............................................................................................................22
3.2.3 The Waterfall Method .......................................................................................................................24
3.2.4 V-Shaped Model ................................................................................................................................26
Module Design: ...........................................................................................................................................27
Validation Phases ........................................................................................................................................28
4.0 Risk and Quality Management ..............................................................................................................31
4.1 Scheduling and Work plan ............................................................................................................................34
4.2 Effort Costing ..........................................................................................................................................36
Conclusion ...................................................................................................................................................39

3
List of Figures.
Figure 1 ................................................................................................................................................................12
Figure 2 ................................................................................................................................................................13
Figure 3 ................................................................................................................................................................13
Figure 4 ................................................................................................................................................................14
Figure 5 ................................................................................................................................................................14
Figure 6 ................................................................................................................................................................16
Figure 7 ................................................................................................................................................................16
Figure 8 ................................................................................................................................................................17
Figure 9 ................................................................................................................................................................18
Figure 10 ..............................................................................................................................................................19
Figure 11 ..............................................................................................................................................................21
Figure 12 ..............................................................................................................................................................22
Figure 13 ..............................................................................................................................................................24
Figure 14 ..............................................................................................................................................................26
Figure 15 ..............................................................................................................................................................31
Figure 16 ..............................................................................................................................................................32
Figure 17 ..............................................................................................................................................................34
Figure 18 ..............................................................................................................................................................35
Figure 19 ..............................................................................................................................................................38

LIST OF ACRONYMS
SSI_______________________ SERVER SIDE INCLUDES
HTML_____________________ HYPER TEXT MARK UP LANGUAGE
PHP______________________ PHP HYPERTEXT PREPROCESSOR
SPMA_____________________ SELF PROTECTING MOBILE AGENTS
JVM______________________ JAVA VIRTUAL MACHINE
SRC_______________________ SOURCE CODE
SDLC______________________ SOFTWARE DEVELOPMENT LIFE CYCLE
DDS______________________ DESIGN DOCUMENT SPECIFICATION
SRS_______________________ SOFTWARE REQUIREMENT SPECIFICATION
XP________________________ EXTREME PROGRAMMING
RAD______________________ RAPID APPLICATION DEVELOPMENT
HLD______________________ HIGH LEVEL DESIGN
LLD_______________________ LOW LEVEL DESIGN
COCOMO__________________ THE CONSTRUCTIVE COST MODEL
ASP.NET___________________ ACTIVE SERVER PAGES
JSP_______________________ JAVA SERVER PAGES

4
CHAPTER 1 INTRODUCTION

1.1 Introduction

According to Gutmans, Andi, Stig and Derick (2004) every day more and more businesses depend on PHP to
run their applications which are critical for their business. This generates new jobs opportunities and increases
the demand for PHP developers. While the difficulty of starting with PHP remains unchanged and very low, the
possibilities offered by PHP today allow developers to extend far beyond humble HTML applications. Support
of XML makes PHP the best language available for processing XML and, joined with new SOAP support, a perfect
platform for generating and using Web Services. PHP is one of the most popular languages for Web
development. By April 2014, PHP was being used by a remarkable 82.1% of sites according to W3Techs -World
Wide Web Technology Surveys (2015). This high percentage is probably because of widespread need for
dynamic web pages. One of the surely substantial problem for those developing PHP web applications or pages
is lack of free and high-quality solutions for source code protection. By “source code protection” commonly
two things are considered: 1) protecting source code to be viewed/modified by others and 2) limiting protected
application execution to exact Internet domain or time period. At this time, there are some solutions for
protecting PHP source code which, generally, belong to two main groups. First group contains PHP source code
obfuscators, which are usually free, work with source code and provide very low level protection. Second group
contains PHP encoders, which work with PHP opcode, thus provide higher level of protection, but are
commercial and require using proprietary closed-source PHP extension in production environment.

PHP encoders provide higher level of protection but, there are two main problems when using them. First
problem is limited lifetime of encoded product because source code is converted to op-code by current
version of PHP interpreter, and then op-code is encoded. This means that encoded solution becomes
unusable with future versions of PHP interpreters that include some important change of how source code is
transformed to op-code. Because of this, developers are forced to buy new versions of encoders and to
recompile source code each time PHP version on Web server is upgraded. Frequent replacements of
application files in production environment are usually an excruciating task. Second problem with using PHP
encoders is reliance on “third trusted part” -author of encoder. This means that whole security of application
depends of company that develops encoder. If encoder or extension is compromised (source code is revealed
to public), all solutions encoded with that encoder are compromised, too. Additionally, encoded PHP scripts
are not protected from encoder authors. In this paper we are analyzing possibilities and issues with creating
solution for high-quality protection of PHP scripts. Standard cryptology models are used for this analysis.
Based on the results of this analysis, we propose a novel model for solution that provides solid protection of
PHP source code on both source code and opcode levels and is not based on trusted third party.

5
1.2 Aim

The aim of this project is to develop a web based source code encryption system that enables PHP
programmers to protect their code from being manipulated.

1.3 Objectives

The objectives for the project are as follows:

 Ensuring that PHP-based applications are distributed with the knowledge that the developers source
code is protected.
 To ensure that even after encryption the code still functions the same.
 To be able to decrypt the source code only by the authorized known owner.
 To protect users from executing malicious code.
 To enable developers, manage the encryption process (No third party).

1.4 Project Justification

Attackers use source code disclosure attacks to try to obtain the source code of server-side applications. The
basic role of Web servers is to serve files as requested by clients. Files can be static, such as image and HTML
files, or dynamic, such as ASP, JSP and PHP files. When the browser requests a dynamic file, the Web server
first executes the file and then returns the result to the browser. Hence, dynamic files are actually code
executed on the Web server.

Using a source code disclosure attack, an attacker can retrieve the source code of server-side scripts, such as
ASP, PHP and JSP. Obtaining the source code of server-side scripts grants the attacker deeper knowledge of
the logic behind the Web application, how the application handles requests and their parameters, the structure
of the database, vulnerabilities in the code and source code comments. Having the source code, and possibly
a duplicate application to test on, helps the attacker to prepare an attack on the application.

Obfuscation or encryption schemes scramble the names of identifiers, remove comments and formatting. But
the obfuscated/encrypted code runs exactly like the original, with no overhead and no special runtime support
needed. Obfuscators/Encrypters depend on the inherent difficulty in understanding programs in general. With
these techniques source code is protected.

6
1.5 Project scope

The project scope will include the following functionalities; login authentication to know the owner of the
source code for future decryption/deobfuscation and other security reasons, the system will also be able to
upload and encrypt a .PHP/ or an entire project (.zip,.tar.gz or .rar format).

1.6 Summary

This chapter introduced the project title as the PHP Source Code Encryption/Obfuscation System. The author
has also stated the aim, objectives, scope and justification of the project.
The next chapter is literature review which shall include a review of the existing systems that are used in the
encryption of source code of different types of languages.

7
CHAPTER 2 LITERATURE REVIEW

2.1 Software Security Attacks

Software is prone to various security attacks described by Collberg and Nagra (2009). These attacks
include the following:
 Malicious reverse engineering of software to understand its functionality
 Stealth of software IP such as proprietary algorithms and code
 BORE (Break Once and Run Everywhere) attack
 Altering software functionality by tampering software
 Software hacking such as bypassing security checks (for example, license
checking functionality)
 Software piracy to create unauthorized copies of software

These attacks are classified into three broad categories:

 Malicious Reverse engineering
 Software Piracy
 Software Tampering

2.2 Software Protection Techniques

Collberg and Thomborson (2002) take a look at some of the protection techniques developed for protecting
software namely obfuscation, watermarking and tamper-proofing.

 Code Obfuscation:
Code obfuscation is a technique used to protect software against malicious
reverse engineering attacks. Code obfuscation is semantic preserving
transformation which maintains functionality of original program while it
makes understanding of obfuscated program harder for an attacker.

 Code Watermarking:
Code watermarking is a technique used to protect software against software
piracy attacks. In code watermarking, developer inserts a message called
“watermark” into software (using secret key) to prove ownership of software.

8
  Tamper-proofing:
Tamper-proofing is a technique used to protect software against tampering
attacks. In tamper-proofing, tamper-proofing code such as parity bits is used
to protect software against tampering attacks.

2.2 Code Obfuscation Techniques and Schemes

This section presents literature on code obfuscation techniques and schemes. The first subsection presents
techniques specific to identifier renaming (a type of layout obfuscation). The second subsection focuses on
techniques specific to control flow transformation. The last subsection presents various obfuscation schemes
described in the literature in which code obfuscation is combined with additional mechanisms (such as time
sensitive codes).

2.2.1 Identifier Renaming Obfuscation

In identifier renaming (or scrambling identifiers) technique original meaningful names are replaced with
random meaningless names. It is one-way transformation (as original meaningful names cannot be recovered
by attackers) without any cost overhead. It is widely supported by commercial (such as Dash O) and open
source (such as ProGuard) code obfuscators. Ceccato and others (2009) present results of experimental
assessment of source code obfuscation performed by applying identifier renaming technique. They perform
experimentation on two types of software systems (car and chat software) with two types of attackers (naive
and experienced attackers) and on two types of attack tasks (program comprehension and modification). They
conclude that if code is obfuscated using identifier renaming, attacker's efforts are increased to perform
successful attack. This paper also shows that even for experienced attackers, it requires at least double time to
complete an attack. However, Chan and Yang (2004) use intelligent identifier renaming for layout obfuscation.
They exploit the gap between definition of legal identifiers for Java compiler and definition of legal identifier
for Java Virtual Machine (JVM). For example, JVM allows keywords (such as "false", "int") as valid identifiers
while Java compiler does not allow these names as valid identifiers. Syntactic and semantic errors are
introduced at java byte code 18 level. Thus, if the obfuscated byte code is decompiled, the generated code
cannot be recompiled due to the errors introduced.

2.2.2 Control Flow Obfuscation

This subsection presents literature survey on code obfuscation techniques based on transformation of control
flow of a program.

9
According to Low. D. (1998) thesis report, Low focuses on control flow obfuscation technique for software
protection. Control flow transformations hide algorithms used in programs by introducing new fake control
flows and by creating features (for example, unstructured control flow graph) at object level which have no
source code equivalent. This paper describes control flow obfuscation techniques such as construction of
opaque predicates (described in the next paragraph), aggregate obfuscation, ordering obfuscation and so on.
Collberg and others (1997) describe a method for creating cheap, resilient and stealthy static analysis.

Opaque constructs to protect code against static analysis. Opaque predicates are Boolean valued expressions
whose outcome is known to obfuscator, but it is difficult for automatic de-obfuscator to deduce the outcome.
Their basic idea is to create and manipulate dynamic data structure (such as graphs) containing alias variables
maintaining certain conditions. These conditions are used to manufacture opaque predicates when needed.
Their approach produces cheap (less computation overhead), resilient (to static analysis) and stealthy opaque
predicates.

Madou and others (2006) list three approaches to code obfuscation, namely source code obfuscation, bytecode
obfuscation and binary obfuscation. They evaluate effectiveness of source code level transformations. They
suggest that control flow flattening, insertion of opaque predicates and conversion of reducible control flow
graph to irreducible control flow graph are the most effective source code obfuscations (as compiler cannot
remove these obfuscations during its optimization phase) to hide control flow of a software. Wang (2001)
presents an obfuscation technique in which program control flow is flattened and alias variables (manipulated
using global arrays and functions) are introduced into program to decide control flow. This technique
transforms high level control transfers to indirect addressing (of dispatcher variable) through aliased pointers.
Theoretical basis for difficulty of understanding obfuscated code is un-decidability of aliases using static
analysis. This paper concludes that attacker needs to perform dynamic analysis to analyze obfuscated code.
Chow (2001) presents obfuscation of control flow of program by embedding an instance "I" of hard
combinatorial problem "C" by applying semantic preserving transformations. Solution to the instance is key "K"
which is known to obfuscator but de-obfuscator needs to detect it. It is hard to deduce the key by static analysis
of obfuscated code.
This chapter extends earlier research on control flow flattening code obfuscation technique.
According to Shrittwieser and Katzenbeisser (2002) most of the existing obfuscation techniques resist static
reverse engineering attacks only but these fail against dynamic attacks. This paper introduces obfuscation
scheme that applies the concept of software diversification to control flow graph to enhance its complexity.
Control flow of obfuscated code depends upon program’s input data and thus attacker's efforts are shifted
from static analysis to dynamic analysis. Their approach makes dynamic analysis harder as attacker needed to
execute program multiple times on different inputs to generate traces to obtain complete view of the
program.

10
2.2.3 Obfuscation Schemes Using Additional Mechanisms
This subsection presents obfuscation schemes developed using combination of existing obfuscation techniques
and additional mechanisms, such as use of self-modification, time sensitive codes and use of distributed
system. Kanzaki and Monden (2010) propose a systematic method for protecting software against dynamic
analysis attack. A program is protected by a method containing many time sensitive codes which are
overwritten by dummy (fake) codes using self-modifying mechanism. If execution time of a guard code block
is within predetermined range, time sensitive code becomes original one. If execution time is out of range,
time sensitive code becomes the fake one. This approach resists dynamic reverse engineering attacks but it
requires accurate profiling information (such as estimation of time taken by guard code) of original code before
obfuscating it. Falcarin and others (2011) present an obfuscation approach based on deployment of incomplete
application. Code of application arrives from trusted network entity as a flow of mobile code blocks which are
arranged in memory with different customized layout.
This approach defeats static and dynamic attacks due to deployment of incomplete application and code
mobility respectively.

2.3 Measuring Effectiveness of Code Obfuscation and De-

Obfuscation Techniques

Collberg and others (2009) describe measures such as potency, resilience and cost to evaluate quality of code
obfuscation transformations. Madou and others (2006) discuss potential of dynamic and hybrid (static-
dynamic) attacks on software. They propose a realistic attack model where an attacker can inspect each
instruction and data value at every program point. In this attack approach, dynamic instrumentor is used to
trace execution of original program and instrumentation information is gathered for attacking software. They
validate this approach through a case study on software watermarking algorithm. Anckaert and others (2007)
evaluate control flow obfuscating transformations on four software complexity metrics: control, control flow,
data and data flow. They evaluate three transformations: control flow flattening, static disassembly thwarting
and transformations based on opaque predicates. For example, they show that control flow flattening
increases the cyclomatic number (a software complexity metric) as each basic block is considered for flattening.

A basic block is a sequence of code statements having single entry and exit points. Karnick and others (2007)
provide a method to measure program obfuscation using measures (such as potency, cost). These measures
are broken down into sub measures (for example, cost is broken into sub measures - memory, storage and
runtime). Analytical metrics are developed to quantify performance of code obfuscation. For example,
obfuscation measure is function of metric parameters: potency, resilience and cost.

11
2.4 Examples of existing source code obfuscators

2.4.1 PHP PROTECT (2015)

PHP Protect is a free PHP obfuscation tool.
It is designed to help PHP developers protect their intellectual property. Any time you give your PHP source
code to someone else your intellectual property can be used and altered without your permission. PHP
Protect is a PHP obfuscator which provides you with a free way to obfuscate your PHP source code. Current
version supports variable name replacement in a way that it will be difficult to read and alter your source
code.
User Guide
The first thing you will see is the welcome screen which tells you which version of PHP protect you are using
and if there is a new version available.
Now move to the obfuscate tab, you will see this -

Figure 1

You will need to choose a source folder - where your PHP files are in and then choose a destination folder.
The entire source folder will be copied into the destination folder so that you can use and test the obfuscated
code right away. Also very important: the destination folder WILL BE DELETED every time you run the
obfuscator. Once the obfuscate button is pressed the process begins. If your source folder is very large this
can take some time.

12
Figure 2

Figure 3

After obfuscation is successful, you now have an obfuscated copy of your source folder. The small window
tells you how many different variables were in the files and how many of them were changed during the
obfuscation process.

13
2.4.2 FOPO FREE PHP OBFUSCATOR (2015)

Free Online PHP Obfuscator

FOPO creates equivalent PHP obfuscated code which requires no special server runtime for execution. It's not
one-way encryption but it will keep curious eyes away from your code. Submitted code gets deleted
immediately after obfuscation and is not stored in any way. It is a very simple software to use, all you need to
do is paste your source code and it is automatically obfuscated/encrypted.
The example below shows normal code (figure 4) and how it is encrypted in figure 5.

Original code Encrypted/obfuscated code

Figure 4

Figure 5

14
2.4.3 srcProtector (2014)

srcProtector for PHP is a tool designed to encrypt your PHP code and therefore make it impossible to be read
and modified. It is created for your PHP applications which source code you don`t want to reveal to your
customers or you want to protect this code against misuse or theft. The encoded scripts are fully functional as
originals but the code is unreadable.

srcProtector is probably the most powerful and sophisticated PHP encryption tool that does not use
compilation to bytecode. With srcProtector you don`t need any loader to be installed on server and encoded
scripts have no additional requirements on the server configuration.
This tool encrypts variables, constants, functions and class names, removes comments and formatting from your
PHP code and encodes strings included in your code. It also changes whole structure of the code without
performance decrease. The encrypting algorithm is very safe and maintains compatibility for most of
applications.

Features
 srcProtector produces unreadable encrypted code - encrypts variables, functions, class names,
constants and strings, remove comments and whitespaces.
 No special requirements of encoded applications. These applications do not need any other libraries,
extensions, or any special loader - Encoded application has same requirements as the original.
 Possibility to preserve line breaks to track errors.
 Optionally you can pack the file content into 'eval' expression, to make the code harder to
understand.
 You can lock the application for use on specific domain names, or set the expiration date for the
application.
 Simple to use - just pick files, check settings and run the encoder through the application GUI.
 Very sophisticated code analysis engine that securely parses your code, keeps its functionality or
warns you about parts of your application that may cause issues in an encoded application and helps
you avoid them.
 Support for object oriented and non-object oriented programming style.
 Support for PHP versions up to PHP 5.6.
 Ability to encrypt applications based on framework or plugins for content management systems.

15
Example of code before encoding

Figure 6

After code obfuscation

Figure 7

16
And encoded into "eval" expression

Figure 8

Problem Information
They are several obfuscators, but we have so far reviewed only three systems namely PHP protect, the FOPO
free online obfuscator and srcProtect. Although all these systems are practical and useful in their fields of use,
they have their own limitations in their working. Advantages of PHP protect from the programmer’s
perspective include: Clean and appealing interface, Easy navigation of the interface, it can obfuscate/encrypt
a whole folder of PHP source code and is also safe to use. However, PHP protect has its limitation, like
installation is a process and we are not assured that it can work on any platform or operating system. The FOPO
free online obfuscator on the other hand has some good features too. First of all, it is free and easy to use, plus
it is an online based application hence it can be accessed anywhere. But it being an online app can also be a
disadvantage because sometimes it may be difficult to access it due to internet failure or slow connections. For
srcProtect the only limit we are aware about is that it is not free. They are many others with different
functionalities. In the system being developed the aim is to have all these functionalities available in one
system.

17
 2.5 System comparison
Figure 9

FOPO free SrcProtect PHP protect Proposed

obfuscator system
Application Type Web installed installed Web

Language(s) PHP, HTML Html, PHP,

JavaScript
Data Storage No No No MySQL,

Operating Platform All All Windows OS All

Authentication (login) No No No Yes

File obfuscation Yes Yes Yes Yes

Full package/folder No No Yes Yes

obfuscation
Zip, .rar obfuscation No No No Yes

Deobfuscation No No No Yes

 The system is to be web based.

 It is an easy and simple system; users do not have to spend days learning how to use it.
 Clients are able to access the system easily.
 This system should have most of the other existing system’s functions.
 This system will have a user login authentication part for more security purposes.

18
CHAPTER 3 METHODOLOGY/APPROACH

3.1 SDLC
SDLC is the acronym of Software Development Life Cycle. It is also called as Software development process.
The software development life cycle (SDLC) is a framework defining tasks performed at each step in the
software development process. ISO/IEC 12207 is an international standard for software life-cycle processes. It
aims to be the standard that defines all the tasks required for developing and maintaining software. It consists
of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life
cycle defines a methodology for improving the quality of software and the overall development process.

Figure 10 is a graphical representation of the various stages of a typical SDLC.

Figure 10

19
3.2 SDLC Models

There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development. The following are some of the models
reviewed:
 Spiral Model
 Extreme Programming Model
 Waterfall Model
 V-Model

The other related methodologies are Agile Model, RAD Model – Rapid Application
Development and Prototyping Models.

3.2.1 Spiral Model

Boehm (2000) says the spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software
project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral,
starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds
on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a
process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk
analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The
evaluation phase allows the customer to evaluate the output of the project to date before the project continues
to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral
represents cost.
Spiral model sectors
1. Objective setting: Specific objectives for the phase are
identified.
2. Risk assessment and reduction: Risks are assessed and
activities are put in place to reduce the key risks.
3. Development and validation: A development model
for the system is chosen which can be any of the
general models.
4. Planning: The project is reviewed and the next phase
of the spiral is planned [1].

20
Fig. 11 Spiral Model of the Software Process.

Figure 11

WinWin Spiral Model

The original spiral model according to Boehm (2000), began each cycle of the spiral by performing the next
level of elaboration of the prospective system's objectives, constraints and alternatives. A primary difficulty in
applying the spiral model has been the lack of explicit process guidance in determining these objectives,
constraints, and alternatives. The Win-Win Spiral Model [Boehm 94] uses the theory W (win-win) approach
[Boehm 89b] to converge on a system's next-level objectives, constraints, and alternatives. This Theory W
approach involves identifying the system's stakeholders and their win conditions, and using negotiation
processes to determine a mutually satisfactory set of objectives, constraints, and alternatives for the
stakeholders. In particular, as illustrated in the figure, the nine-step Theory W process translates into the
following spiral model extensions:
1. Determine Objectives: Identify the system life-cycle stakeholders and their win conditions and
establish initial system boundaries and external interfaces.

2. Determine Constraints: Determine the conditions under which the system would produce win-lose or
lose lose outcomes for some stakeholders.

21
 3. Identify and Evaluate Alternatives: Solicit suggestions from stakeholders, evaluate them with respect
to stakeholders' win conditions, synthesize and negotiate candidate win-win alternatives, analyze,
assess, resolve win-lose or lose-lose risks, record commitments and areas to be left flexible in the
project's design record and life cycle plans.

4. Cycle through the Spiral: Elaborate the win conditions evaluate and screen alternatives, resolve risks,
accumulate appropriate commitments, and develop and execute downstream plans [8].

Advantages
1. High amount of risk analysis.
2. Good for large and mission-critical projects.
3. Software is produced early in the software life cycle.

Disadvantages
1. Can be a costly model to use.
2. Risk analysis requires highly specific expertise.
3. Project’s success is highly dependent on the risk
analysis phase.
4. Doesn’t work well for smaller projects.

3.2.2 Extreme Programming (XP)

Extreme programming is an agile development methodology that is employed in the development of a number
of software (Beck, 2000). It was implemented to help in the management of software development since
development costs for software are expensive. Beck (2000) states that Expreme programming as a
development discipline that “addresses risk at all levels of the development process.” Sommerville (2011)
illustrates the phases of the of XP as shown in figure 12:

Figure 12

22
Figure 12: Phases of XP. Sommerville (2011)
Extreme programming has a number of principles. These principles according to Sommerville (2011) are:

Incremental Development: Development is done in small increments which are released frequently and
added to the overall system. The requirements are based on scenarios called user stories which define the
functionality of the component to be developed.

Customer Involvement: In extreme programming, it is advised, practical and mandatory to have a customer
on-site as part of the development team. The customer is there to clarify the various operations of the
system.

People, not process: The people, not process principle also employs facets such as collective ownership of
the system code, and a sustainable development process. Sommerville (2011).

Embrace of chance: According to Sommerville (2011), “Change is embraced through regular system releases
to customers, test-first development, refactoring to avoid code degeneration, and continuous integration of
new functionality.”

Simplicity: Simplicity of code is very important for XP. Refactoring is utilized to improve code quality and the
use of simple designs that do not unnecessarily anticipate future system
changes are employed. Sommerville (2011).

Advantages
1.Lightweight methods suit small-medium size projects.
2.Produces good team cohesion.
3. Emphasizes final product.
4. Iterative.
5. Test based approach to requirements and quality assurance.
Disadvantages
1. Difficult to scale up to large projects where documentation is essential.
2. Needs experience and skill if not to degenerate into code-and-fix.
3. Programming pairs is costly.
4. Test case construction is a difficult and specialized skill.

23
3.2.3 The Waterfall Method
The waterfall method takes a step-by-step method of software development where output from one phase of
software development leads to the next phase. Sommerville (2011) names these phases as “specification,
development, validation, and evolution” and illustrates them as shown in figure 13:

Figure 13

Figure 13: Waterfall method. Sommerville (2011)

As mentioned earlier, the output from a preceding phase produces the input for the succeeding phase. Before
the steps in the diagram above, the developer is first of all to undertake a feasibility study. This study will
evaluate aspects such as technical feasibility, economic feasibility, technical feasibility and operational
feasibility to see if the system in question is feasible in the aforementioned aspects. Each of the phases
performs a unique task that is distinct but furthers the development of the software.

The phases explained are:

Requirements analysis and Definition:
On this phase, “the system’s services, constraints, and goals are established by consultation with system users”
Sommerville 2011). Requirements may be gathered through interviews, surveys, polls and other information
gathering techniques. The details from the information gathering should be well detailed since they are used
to create a system specification document.

System and Software design:

During this phase, the developers “allocate the requirements to either hardware or software systems by
establishing an overall system architecture” (Sommerville, Software Engineering, 9th edition, 2011). It is during
this phase that relational schema, class diagrams, communication diagrams, entity relationship diagrams, use

24
case diagrams and other design diagrams are generated from the specification document. The output for this
phase is the design document.

Implementation (Coding) and unit testing:

It is during this phase that the design document from the precious phase is realized and is put into use.
Sommerville (2011) expresses this as “the software design is realized as a set of programs or program units.”
Implementation is also called coding. Sommerville (2011) defines unit testing as involving the verification of
whether each unit meets its specifications. The diagrams from the systems design phase will be used for the
implementation phase.

Integration and System Testing:

During this testing phase, individual units, components and modules of the application are integrated and
tested as a complete system rather than individual components. This is done to ensure that the software meets
the system specifications and requirements. After this testing is performed, the system is then delivered to the
customer (Sommerville, Software Engineering, 9th edition, 2011).

Operation and maintenance:

After the software is completed and delivered to the customer, the final phase left is the operation and
maintenance. According to Sommerville (2011), this is “Normally (although not necessarily) the longest life
cycle phase.” He further states that “Maintenance involves correcting errors which were not discovered in
earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s
services as new requirements are discovered.”

 Advantages :

1. Easy to understand and implement.

2. Widely used and known (in theory!).
3. Reinforces good habits: define-before- design, design-before-code.
4. Identifies deliverables and milestones.
5. Document driven, URD, SRD, … etc. Published documentation standards, e.g. PSS-05.
6. Works well on mature products and weak teams.
 Disadvantages :
1. Idealized, doesn’t match reality well.
2. Doesn’t reflect iterative nature of exploratory development.
3. Unrealistic to expect accurate requirements so early in project.
4. Software is delivered late in project, delays discovery of serious errors.
5. Difficult to integrate risk management.

25
6. Difficult and expensive to make changes to documents, ”swimming upstream”.
7. Significant administrative overhead, costly for small teams and projects.

3.2.4 V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes,
Easterbrook (2001). Each phase must be completed before the next phase begins. Testing is emphasized in
this model more than the waterfall model. The testing procedures are developed early in the life cycle before
any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle
model just like the waterfall model. Before development is started, a system test plan is created. The test
plan focuses on meeting the functionality specified in requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in
this phase in order to test the pieces of the software systems ability to work together. However, the low-level
design phase lies where the actual software components are designed, and unit tests are created in this
phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the
path of execution continues up the right side of the V where the test plans developed earlier are now put to
use.

The below figure illustrates the different phases in V-Model of SDLC.

Figure 14

26
Verification Phases
Following are the Verification phases in V-Model:

Business Requirement Analysis :

This is the first phase in the development cycle where the product requirements are understood from the
customer perspective. This phase involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and need to be managed well, as most
of the customers are not sure about what exactly they need. The acceptance test design planning is done at
this stage as business requirements can be used as an input for acceptance testing.

System Design:
Once you have the clear and detailed product requirements, it’s time to design the complete system. System
design would comprise of understanding and detailing the complete hardware and communication setup for
the product under development. System test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for actual test execution later.

Architectural Design:
Architectural specifications are understood and designed in this phase. Usually more than one technical
approach is proposed and based on the technical and financial feasibility the final decision is taken. System
design is broken down further into modules taking up different functionality. This is also referred to as High
Level Design (HLD).
The data transfer and communication between the internal modules and with the outside world (other
systems) is clearly understood and defined in this stage. With this information, integration tests can be
designed and documented during this stage.

Module Design:
In this phase the detailed internal design for all the system modules is specified, referred to as Low Level
Design (LLD). It is important that the design is compatible with the other modules in the system architecture
and the other external systems. Unit tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage. Unit tests can be designed at this stage based
on the internal module designs.

Coding Phase:
The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The
best suitable programming language is decided based on the system and architectural requirements. The
coding is performed based on the coding guidelines and standards. The code goes through numerous code

27
reviews and is optimized for best performance before the final build is checked into the repository.

Validation Phases
Following are the Validation phases in V-Model:

 Unit Testing
Unit tests designed in the module design phase are executed on the code during this validation phase. Unit
testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be
uncovered by unit testing.

 Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are performed to test
the coexistence and communication of the internal modules within the system.

 System Testing
System testing is directly associated with the System design phase. System tests check the entire system
functionality and the communication of the system under development with external systems. Most of the
software and hardware compatibility issues can be uncovered during system test execution.

 Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves testing the
product in user environment. Acceptance tests uncover the compatibility issues with the other systems
available in the user environment. It also discovers the nonfunctional issues such as load and performance
defects in the actual user environment.

V- Model application is almost same as waterfall model, as both the models are of
sequential type. Requirements have to be very clear before the project starts, because it
is usually expensive to go back and make changes. This model is used in the medical
development field, as it is strictly disciplined domain. Following are the suitable scenarios
to use V-Model:
 Requirements are well defined, clearly documented and fixed.
 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 There are no ambiguous or undefined requirements
 The project is short.

28
WHY CHOOSE V-Model ?
The advantage of V-Model and the reason it was chosen for this project is that it’s very easy to understand
and apply. The simplicity of this model also makes it easier to manage. The disadvantage is that the model is
not flexible to changes and just in case there is a requirement change, which is very common in today’s
dynamic world, it becomes very expensive to make the change. Otherwise the V-Model suits this project and
relates best to it especially because of how small the project is.

Conclusion
Variety in SDLC models and frameworks is great. Most of the prominent ones have been discussed, but there
are numerous other models, many of them hybrid in nature and designed to respond to specific needs of specific
projects or simply to attempt a flawless approach by combining various models and reducing their individual
weaknesses. This great variety means that the process of choosing which model to adopt for a particular
development project can be complicated. Nevertheless, there are certain fundamental aspects of the project that
can facilitate the decision.

29
Why use PHP as the programming language?
According to php.net (2015):
 Excellent documentation. It has really good documentation with helpful user-contributed gotchas
and code snippets. You can also find tons of tutorials, etc. around the web.

 Easy deployment. There are tons of hosting companies like Dreamhost that will, for a few dollars a
month, give you a server running PHP so you can make a website really easily.

 Optimized for making web applications quickly. PHP is designed to work well with the web, and so
things like accessing the GET and POST and working with HTML and URLs are built-ins in the PHP
language. This makes it really concise and straightforward to make a website.

 Open Source PHP is Open Source. This means it is readily available and absolutely free! If you are
planning to get PHP developers help and they have a good background in C and Java, they will do
excellently in PHP. If the truth be spoken, PHP is actually much simpler than the rest and so you can
stay assured of fabulous results.

 Stability, Flexibility and Speed are the chief qualities that attract programmers to choose PHP.

Technologies to be used
 Hypertext Markup Language (HTML).
 Edraw for drawing use cases, class diagrams, object sequence diagrams
 Apache for a web server.
 Firefox, internet explorer and chrome web browser
 Java script

30
4.0 Risk and Quality Management

4.1 Introduction
According to Hu, Zhang, Ngai, Cai, & Liu (2012), “The software industry has become one of the fastest-growing
industries.” They, at the time, estimated that the software market would have an estimated value of US$300
Billion as of 2014. They further stated that “software development is yet a high-risk activity” and quote the
CHAOS Summary 2009 by stating that “the success rate of global (mainly U.S. and European) software projects
is only 32%.” It is with these figures in mind that we need to study more about software risk management. In
project management, risk management is one of the most important operations a developer can ever
undertake. According to Sommerville (2011), “Risk management involves anticipating risks that might affect
the project schedule or the quality of the software being developed, and then taking action to avoid these
risks.” In simplistic terms, Sommerville (2011) defines a risk as “something that you’d prefer not to have
happen” to the project. McManus (2012) better defines a risk as “a problem that could cause some loss or
threaten the success of our project, but which hasn’t happened yet.”
Risk Analysis
Stern & Arias (2011) state that “There are various methods that have been developed to analyse the risk factors
within any given project.” They site five risk analysis methods which are BOEHM, RISKIT, SEI-SRE, SERUM and
SERIM. In this write-up, we will discuss BOEHM, RISKIT and SERIM.
BOEHM
BOEHM according to Adler & Leonard (1999) is a software risk managenment model developed by Dr Barry
Boehm which “focuses on the concept of ‘risk exposure’ as defined by the relationship where the probability
of an unsatisfactory outcome and the loss due to the unsatisfactory outcome determine the valence of the risk
event.” In this model, we make use of a risk management level matrix as shown in the figure 15.

Figure 15

Figure 15 Risk Management Matrix. Adler & Leonard (1999)

31
RISKIT
According to Islam, Mouratidis, & Weippl (2014), the RISKIT methodology is a “methodology, which provides
a complete conceptual framework for risk management using a goal/expectation approach from the
stakeholders and risks which threaten the goals.” Stern & Arias (2011) state that “RISKIT follows seven
different steps of implementation.” The main characteristics of RISKIT according to Stern & Arias (2011) are
that the RISKIT method provides precise and unambiguous definitions for risks, the RISKIT method results in
explicit definition of objectives, constraints and other drivers that influence the project, the RISKIT
method is aimed at modelling and documenting risks qualitatively, the RISKIT method can use both
ratio and ordinal scale risk ranking information to prioritise risks reliably, the RISKIT method uses the
concept of utility loss to rank the loss associated with risk, different stakeholder perspectives are explicitly
modelled in the RISKIT method and that the RISKIT method has an operational definition and training
support.
Application to Project
For this project five (5) risks related to this project were identified and the risk register was used to present
the risks associated with the project. According to Patterson & Neailey (2002), “a Risk Register tool is
generally used as a means of recording and documenting the information generated through the use of
Project Risk Management”. Five risks associated with this project are loss of data through theft or damage of
the hard drive, limited testing resources, requirements inflation, use of unfamiliar tools during
implementation and schedule flaws. After identifying the risks, the risk register was used to tabulate the
risks, their probability, impact, score, result, owner and response as shown in table 2 below.

Figure 16

Ref Risk Identification RISK EVALUATION (1, 2 or 3) Risk Risk Owner Risk Response
Result

Probability Impact Score

1 Limited testing
resources
2 Inaccurate change
priorities
(a) (b) (a*b)
1 2 2 Low Risk Developer Make sure the system is
not too complex. It
should be a simple and
straight forward system
2 3 6 Medium Developer When non-essential
Risk changes are prioritized
impacting critical
schedules. This must be
avoided.

32
3 Requirements 2 3 6 Medium Developer Define which
changes Risk requirements are flexible
and which ones are fixed.
4 Use of unfamiliar 1 3 3 Low Risk Developer Use tutorials or seek help
tools during from people who are
project familiar with the tools
implementation
5 Loss of saved data 3 2 6 High Risk Developer Frequently Back up work
on hard on an external hard drive
drive(theft or or on the university
damage) repository(SVN)

Risk and Quality Management Conclusion

In conclusion, Li, Li, Wu, & Song (2012) state that “In the modern information-based society, the world is now
seriously dependent on software systems that control key facilities in areas such as energy, communications,
manufacturing, finance, government and defense, to name a few.” It is with this in mind that we can safely
say risk assessment in software design and development has become not only practical but essential to the
software and business communities. The importance of this is that we now have a realistic view of not only
the optimistic but presimmistic views of the project. This is important since software has a high failure rate
and since software is still geberally costly, it is important to assess the risks involved with developing a
software. Though what has been done in the project is relatively not complicated, “Risk analysis and planning
are complex, resulting in difficulties to manage risks effectively through subjective judgment” in the real
setting. (Hu, et al., 2013).

33
4.1 Scheduling and Work plan

Scheduling and work plan for the project was done for the project implementation work plan. To perform the
scheduling and work plan, the use of Project libre was needed.

Implementation Phase
Figure 17 below shows the work breakdown structure for the implementation phase of the project:

Figure 17

34
The work breakdown structure is graphically illustrated by a Gantt chart which is shown in figure 18 below:

Figure 18

35
4.2 Effort Costing

There is a need for a comprehensive set of tools and techniques that can help us in our analysis. Types of
software costing methods include COCOMO (James, 2009), COCOMO II (Stellman & Greene, 2006), Function
Point Analysis (Garmus & Herron, 2001) and SEER-SEM (Galorath & Evans, 2006) to name a few. For
simplicity, consistency and clarity’s sake, we will be using the COCOMO II method to estimate the project’s
size and cost. “The Constructive Cost Model (COCOMO) is a software cost and scheduling estimating method
developed by Barry Boehm in the early 1980s.” (Stellman & Greene, 2006). Since then, “Boehm and his
colleagues have updated the original COCOMO, called COCOMO II that accounts for recent changes in the
software engineering technology.” (Puntambekar, 2009). Puntambekar (2009) further explains that COCOMO
II is applicable for business software, object-oriented software, software created by using spiral or
evolutionary development models. Sutter (2004) explains that COCOMO II includes the Application
Composition Model – Suitable for projects built with modern GUI-builder tools, the Early Design Model – To
get rough estimates of a project’s cost and duration before fixing the entire architecture and the Post-
Architecture Models – Used for the actual development and maintenance of a software product.
Details of COCOMO II
A COCOMO II calculation application can be found on the UCS website (Kishore & Kishore, 2008). Sommerville
(2011) explaind the cocomo inclusions as:
The application-composition model
According to Sommerville (2011), the formula for effort computation for system prototypes as: PM = (NAP ×
(1-%reuse/100))/PROD. Where PM is effort estimate in person-months, NAP is the total number of
application points in the delivered system; %reuse is an estimate of the amount of reused code and PROD is
the application-point productivity as shown in figure 19.

Figure 19

Figure 19: Application-point productivity from Sommerville (2011)

36
The early design mode
The assumption made is that the user requirements have been agreed and initial stages of the design process
are being done. According to Mall (2009), the formula for this mode is: Effort = KSLOC×πicostdriveri. The cost
drivers include “product reliability and complexity, the extent of reuse, platform difficulty, personnel
experience, CASE support, and schedule. KSLOC stands for Kilo Source Lines of Code. Sommerville (2011) on
the hand uses the formula: Effort = A × Sizeb × M. Where A = 2.94, Size is the size of the system expressed in
KSLOC and B reflecting the extra effort required as the project increases. M =
PERS×RCPX×RUSE×PDIF×PREX×FCIL×SCED. Where PERS is the personnel capability, RCPX is the product
reliability and complexity, RUSE is the reuse required, PDIF is the platform difficulty, PREX is the personnel
experience, FCIL are the support facilities and SCED is the schedule. Each of these is evaluated on a scale of 1
to 6.
The post-architecture level
“The COCOMO II Post-Architecture model is significantly more accurate when calibrated to an organization
Dillibabu & Krishnaiah (2004). The formula for this model is the same as the formula used in the early design
estimates in principle. The formula according to Sommerville (2011) is PM = A × Sizeb × M.
Figure 20 below shows the inputs and outputs in COCOMO II online software (Madachy 2015)

37
Figure 20

Summary
Summary for the calculation of cost and estimation an online COCOMOII calculation model was used, which
gave the amount of K 86, 947.84 for the development of the system. The following table shows the summary
information
Summary
Effort 4 Person-months
Duration 8 Months
Staffing No Staffing Generated
Costs K86, 947.84 (7168*12.13) ($1 – 12.13)
On 27th October 2015

38
Conclusion
The proposal began with a discussion on the merits of the PHP language. It was found to be a robust, fully-
featured language that employs a simple, C-like syntax, making it easy to learn and develop in. As a language
with a well-developed community, PHP enjoys regular updates and bug fixes and is endowed with a
comprehensive set of documentation and example code. Although the language is associated with many
security flaws, it was determined that these flaws generally occur as a result of poor programming practice on
the part of PHP developers rather than core issues with the language itself. Code obfuscation was introduced
as an obstacle to automated code dissection.

Various methods of obfuscation were presented and it was determined that a combination of these techniques
greatly complicated the deobfuscation process. Obfuscaton is not 100% protective but it makes an attacker
have problems with understanding code hence it helps protect and secure source code.

With enough time and resources, it can always be broken, but the question is price. If we have an algorithm
we want to obfuscate, and the money and resources the attacker needs to invest in order to break those
obfuscations exceeds the amount of money he would have used to hire people to create a similar algorithm,
then we succeeded. Therefore, to further straighten our obfuscator, we could add more features to it, such as
breaking and joining classes, learning the original code “common language” and using when generating dead
code, and making the exception predicates span over more levels of the calling stack. If we’ll use several
obfuscation methods we’ll surely make the code much more difficult to understand, and therefore costlier to
deObfuscate.

39
APPENDIX A: REFERENCES

B. Anckaert, M. Madou, B. D. Sutter, B. D. Bus, K. D. Bosschere, and B. Preneel. "Program obfuscation: a

quantitative approach", In QoP '07: Proc. of the 2007 ACM Workshop on Quality of protection, pages 15-20,
New York, NY, USA, 2007. ACM.

Barry Boehm, "Spiral Development: Experience, Principles, and Refinements", edited by Wilfred J.
Hansen, 2000.

Beck, K. Extreme Programming Explained: Embrace Change. Medford: Addison-Wesley Professional, 2000.

C. Collberg, C. Thomborson, and D. Low, "A taxonomy of obfuscating transformation", Technical report 148,
Department of computer science, the University of Auckland, Auckland, New Zealand, 1997.
C. Collberg and J. Nagra. "Surreptitious Software: Obfuscation, Watermarking, and Tamper proofing for
Software Protection", Addison Wesley Professional, 2009.

Chow, S., Gu, Y., Johnson, H., and Zakharov, V.A.: "An Approach to the Obfuscation of Control-Flow of
Sequential Computer Programs", In the proceedings of 4th International Conference on Information Security,
LNCS Volume 2200. Pages 144-155. Springer-Verlag. Malaga, Spain. 2001.

Dillibabu, R., & Krishnaiah, K. (2004). Cost estimation of a software product using COCOMO II.2000 model – a
case study. International Journal of Project Management, 302. 2004.

Falcarin, P.; Di Carlo, S.; Cabutto, A.; Garazzino, N.; Barberis, D.; "Exploiting code mobility for dynamic binary
obfuscation", Internet Security (WorldCIS), 2011 World Congress on Publication Year: 2011 , Page(s): 114 – 120

Gutmans, Andi, Stig Bakken, and Derick Rethans. “PHP 5 Power Programming (Bruce Perens' Open Source
Series)“. Prentice Hall PTR, 2004

http://phpobfuscator.net/index.html (accessed on 01.11.2015)

http://w3techs.com/technologies/overview/programming_language/all
(accessed on 12.05.2015)

http://www.phpprotect.info/ (accessed on 01.11.2015)

40
https://www.php.net/ (accessed on 01.11.2015)

Islam, S., Mouratidis, H., & Weippl, E. R. (2014). An empirical study on the implementation and evaluation of a
goal-driven software development risk management model. Information and Software Technology, 117–133.

J. Chan and W. Yang, "Advanced obfuscation techniques for java bytecode", JOURNAL OF SYSTEMS AND
SOFTWARE, vol. 71, no. 1, pp. 1-10, Apr.2004

Low, D. (1998). "Java Control Flow Obfuscation", Master's thesis. University of Auckland, Auckland, New
Zealand.

M. Ceccato, M. DiPenta, J. Nagra, P. Falcarin, F.Ricca, M. Torchiano, and P. Tonella. "The effectiveness of source
code obfuscation: an experimental assessment", In IEEE International Conference on Program Comprehension
(ICPC 2009). IEEE CS Press, 2009

Madou M, Anckaert B, De Bus, De Bosschere K, Cappaert J. Preneel, "On the Effectiveness of Source Code
Transformations for Binary Obfuscation", Proc. of the International Conference on Software Engineering
Research and Practice (SERP06), June. 2006.

Sebastian Schrittwieser and Stefan Katzenbeisser, "Code Obfuscation against Static and Dynamic Reverse
Engineering", Vienna University of Technology, Austria, Darmstadt University of Technology, Germany

Stellman, A., & Greene, J. Applied Software Project Management. Sebastopool: O'Reilly Media, Inc. 2006

Steve Easterbrook, "Software Lifecycles", University of Toronto Department of Computer Science, 2001.

Stern, R., & Arias, J. C. Review or Risk Management Methods. Business Intelligence Journal, 59-78. 2011

Sommerville, I. (2011). Software Enginering, 9th Edition. Boston: Pearson Education.

Wang, C., Hill, J., Knight, J.C., and Davidson, J.W.: "Protection of software based survivability mechanisms", In
Proceedings of the 2001 conference on Dependable Systems and Networks. IEEE Computer Society. Pages 193-
202. 2001

41
APPENDIX B: RESOURCES USED IN PROJECT
Languages:
PHP: for the encryption codes or algorithims
Javascript: for embedding functions from external files(methods)
HTML: Used for creating the website on which the application will run.
Database Systems
MySQL: Used as the database management system for the project

42
APPENDIX C: DIAGRAMS

43