PHILIPPINE COLLEGE OF SCIENCE AND TECHNOLOGY

Old Nalsian Road, Nalsian, Calasiao, Pangasinan, Philippines 2418

Tel. No. (075)522-8032/Fax No. (075)523-0894/Website: [Link]
ISO 9001:2015 CERTIFIED, Member: Philippine Association of Colleges and Universities (PACU),
Philippine Association of Maritime Institutions (PAMI)

CHAPTER IV

RESULTS AND DISCUSSIONS

A. Technical Design

This presents the comprehensive representation of the technical side of the project. The different
design which are interrelated to explain the project.

a) System Design
This and the following section should provide sufficient information for a
developer to produce the system. The detailed content will depend upon the approach to
the design process that is to be used.

According to one source there are over 30 different object design

methodologies and notations of which UML is perhaps the best known. If the
project is to follow the traditional waterfall approach, its documentation will differ
from a development approach based on RAD or DSDM. Moreover, an Object-
oriented design (OOD) based philosophy for the design using UML would be
different from one based on another design methodology such as SSADM or
Yourdon.

Depending upon the approach to be taken the software may be produced

using coding statements or it may be automatically generated by an application
development tool or a mixture of both. For the example presented in the rest of this
section we will assume that new IDA projects move towards the use of Unified
Modeling Language (UML) and OOD based methodologies. One goal of OOD is
to create a collection of reusable software objects that can be reused across other
IDA projects, in effect offering some significant savings in development costs.
With the proposal to create a IDA Reference Architecture a central library of
objects could be reused across projects that have similar aims and objectives ‘to
collect information’ but whose application areas (health, tourism, employment,
environment, Customs, etc) vary.

b) Data, Object and Process Modeling

The following is a list of definitions for this template based on the UML
approach to system design, Terms covering the development of software using the
Unified Modelling Language (UML) approach – which is recommended if an OOD
view of the system is to be developed – should be included for completeness.
 PHILIPPINE COLLEGE OF SCIENCE AND TECHNOLOGY
Old Nalsian Road, Nalsian, Calasiao, Pangasinan, Philippines 2418
Tel. No. (075)522-8032/Fax No. (075)523-0894/Website: [Link]
ISO 9001:2015 CERTIFIED, Member: Philippine Association of Colleges and Universities (PACU),
Philippine Association of Maritime Institutions (PAMI)

Class Diagram Describes the structure of a system

Object Diagram Expresses possible object combinations of a specific Class
Diagram
State chart Diagram Expresses possible states of a class (or a system)
Activity Diagram Describes activities and actions taking place in a system
Sequence Diagram Shows one or several sequences of messages sent among a
set of objects
Collaboration Describes a complete collaboration among a set of objects
Diagram
Use-case Diagrams Illustrates the relationships between use cases
Component A special case of a Class Diagram used to describe
Diagram components within a software system
Deployment A special case of a Class Diagram used to describe
Diagram hardware within the overall system architecture
System Block A diagram showing the major components of the system
diagram with its interconnections and external interfaces

c) System Security
Traditionally, computer science programs have focused on producing
programmers with a foundation to become good application developers but not
necessarily security experts. As a result, developers today are by and large unaware of
the myriad ways they can introduce security problems into their code. There is also
currently a misalignment between stakeholders across the software development life-
cycle: • Misaligned priorities - Development teams are focused on product innovation
to meet business needs. Vulnerabilities stemming from code defects are seen as
potential problems, therefore not a priority compared to feature functionality and on-
time delivery. QA teams are concerned about buggy software and customer
dissatisfaction. Security teams are focused on the availability and protection of
sensitive assets – they are tasked with securing in-house and commercial applications,
often having to address vulnerabilities exposed by software code after it is deployed.

a. Factors concerning system security.

• Misaligned process - Security audits and QA testing happen at the end
of the development cycle where issues are most expensive to fix and when
developers are focused on getting the release out and moving on to the next
release. Audits are typically done late in the cycle to avoid having security
experts review and re-review code that is likely to change before release. Also,
security audits typically happen outside the standard development workflow,
which means developers are likely to ignore security issues identified during
the audit because it is hard to go back and change “working” code without
causing an expensive and lengthy testing cycle. Therefore, security issues
identified late present business stakeholders a difficult decision between time
 PHILIPPINE COLLEGE OF SCIENCE AND TECHNOLOGY
Old Nalsian Road, Nalsian, Calasiao, Pangasinan, Philippines 2418
Tel. No. (075)522-8032/Fax No. (075)523-0894/Website: [Link]
ISO 9001:2015 CERTIFIED, Member: Philippine Association of Colleges and Universities (PACU),
Philippine Association of Maritime Institutions (PAMI)

to market and security. • Misaligned tools - Developers resist changes to their

workflow and find it difficult to use tools designed for security experts. They
require too much security expertise and do not provide directly actionable
information for fixing defects. Putting security auditing tools in the hands of a
developer is not a practical solution as these tools are designed to find every
possible issue resulting in a high false positive rate. Developers will often
ignore the tools analysis results if they have to wade through a high volume of
noise to identify critical defects that must be fixed.

“The need to consider security and privacy “up front” is a fundamental

aspect of secure system development. The optimal point to define
trustworthiness requirements for a software project is during the initial
planning stages. This early definition of requirements allows development
teams to identify key milestones and deliverables, and permits the integration
of security and privacy in a way that minimizes any disruption to plans and
schedules.”

d) Software Development

a. Software Development Life Cycle

The life cycle defines a methodology for improving the quality of
software and the overall development process.

b. Software Specification
Also software requirements specification (SRS) is a description of a
software system to be developed. It lays out functional and non-functional
requirements, and may include a set of use cases that describe user interactions
that the software must provide.

Software requirements specification establishes the basis for an agreement

between customers and contractors or suppliers (in market-driven projects,
these roles may be played by the marketing and development divisions) on what
the software product is to do as well as what it is not expected to do. Software
requirements specification permits a rigorous assessment of requirements
before design can begin and reduces later redesign. It should also provide a
realistic basis for estimating product costs, risks, and schedules.

c. Hardware Specification
The hardware specification captures all necessary information and files
from a Development Kit (DK) hardware design that are required for a software
developer to develop, debug, and deploy software applications for that
hardware. Typically, a hardware designer who develops hardware Software
development kit (SDK) exports this specification files to a directory. The
 PHILIPPINE COLLEGE OF SCIENCE AND TECHNOLOGY
Old Nalsian Road, Nalsian, Calasiao, Pangasinan, Philippines 2418
Tel. No. (075)522-8032/Fax No. (075)523-0894/Website: [Link]
ISO 9001:2015 CERTIFIED, Member: Philippine Association of Colleges and Universities (PACU),
Philippine Association of Maritime Institutions (PAMI)

software developer then imports this file using Software development kit
(SDK). The examples of a hardware specification are:

Minimum Hardware specification

Hardware and software requirements may vary depending on the machine
and operating system.

The minimum hardware specifications to install and effectively operate

Server are:
• Dual-core x86 CPU running at 2GHz.
• 4GB RAM (physical).
• A block-based storage device (hard disk, SSD, EBS, iSCSI).

Recommended specifications
The recommended hardware specifications to install and effectively operate
Server include:
• Four core 64-bit x86 CPU running at 3GHz; six cores when using
Cross Datacenter Replication (XDCR) and Views.
• 16GB RAM (physical).
• A local block-based storage device (hard disk, SSD). Network file
systems such as CIFS and NFS are not supported.
Minimum:

• Windows 7, 8, 10, Server 2008, Server 2012, 64 bits (PC or Mac computers
using Boot Camp).
• Any CPU (Intel i5/i7/Xeon recommended).
• Any GPU that is compatible with OpenGL 3.2. (integrated graphic cards
Intel HD 4000 or above).
• Small projects (under 100 images at 14 MP): 4 GB RAM, 10 GB HDD Free
Space.
• Medium projects (between 100 and 500 images at 14 MP): 8 GB RAM, 20
GB HDD Free Space.
• Large projects (between 500 and 2000 images at 14 MP): 16 GB RAM, 40
GB HDD Free Space.
• Very Large projects (over 2000 images at 14 MP): 16 GB RAM, 80 GB
HDD Free Space.

Recommended:
• Windows 7, 8 64 bits.
• CPU quad-core or hexa-core Intel i7/Xeon.
 PHILIPPINE COLLEGE OF SCIENCE AND TECHNOLOGY
Old Nalsian Road, Nalsian, Calasiao, Pangasinan, Philippines 2418
Tel. No. (075)522-8032/Fax No. (075)523-0894/Website: [Link]
ISO 9001:2015 CERTIFIED, Member: Philippine Association of Colleges and Universities (PACU),
Philippine Association of Maritime Institutions (PAMI)

• GeForce GPU compatible with OpenGL 3.2 and 2 GB RAM.

• Hard disk: SSD.
• Small projects (under 100 images at 14 MP): 8 GB RAM, 15 GB SSD Free
Space.
• Medium projects (between 100 and 500 images at 14 MP): 16GB RAM, 30
GB SSD Free Space.
• Large projects (over 500 images at 14 MP): 32 GB RAM, 60 GB SSD Free
Space.
• Very Large projects (over 2000 images at 14 MP): 32 GB RAM, 120 GB
SSD Free Space

d. Program Specification
Also known as functional specification (also, functional spec, specs,
functional specifications document (FSD), functional requirements
specification, or Program specification) in systems engineering and software
development is the documentation that describes the requested behavior of an
system. The documentation typically describes what is needed by the system
user as well as requested properties of inputs and outputs (e.g. of the software
system). A functional specification is the more technical response to a matching
requirements document, e.g. the Product Requirement Document "PRD". Thus
it picks up the results of the requirements analysis stage. On more complex
systems multiple levels of functional specifications will typically nest to each
other, e.g. on the system level, on the module level and on the level of technical
details.