Meeting Thinking and Coding - Internship Report

Internship Report:
Meeting, Thinking and Coding (MTC)

Personal Edition
September 16, 2002

Sasmito Adibowo
Faculty of Computer Science

University of Indonesia
ABSTRACT
MTC (Meeting, Thinking, Coding) is an activity monitoring software developed by
PT Code Jawa to record the daily activities for computer-intensive workers.
Targeted for business-Windows platforms, this program is developed initially for
Code Jawa’s internal use. Further product path of the system will be commercial
marketing of the system.
This report describes the internship period in which the intern developed the
MTC system. Along with the system description of MTC, the report also includes
the company profile, project execution, impact analysis and it is finally
terminated with several conclusions and suggestions by the intern.
With courtesy of Code Jawa, this report is made available for the general public
under the GNU Free Documentation License. A copy of this license is provided in
the appendices.
2
PREFACE
The writer utters his praise and thanks to The One God since for only by His
blessing and mercy that the writer was able to complete his internship in a
software development company in Indonesia and to have completed this
internship report.
Within this opportunity, the writer would like to express his deepest thanks to
those parties who had helped in the process. This gratitude especially goes to:
1. Mom and Dad, who have given the undying support and love for all this
time, thank you for the support given during this internship.
2. Mr Dadan Hardianto, as the Academic Advisor who have given suggestions,

criticism, direction and guidance both during the internship and the
writing of this report.
3. Mr Iwan Tantra as the Chief Technology Officer for the opportunity and
trust that he provides. Also for his understanding for the project’s overdue.
4. Mr Krishna W Karang as the Project Manager for his guidelines during this
internship.
5. Dion, colleague and alumni whom at many opportunities gave the writer a
ride home at late nights.
6. All colleagues at Code Jawa for their various help and support: Johan,
Stephen, Isak, Denymon, Ryan and others.
7. All civitas academica of the Faculty of Computer Science, University of

Indonesia without exemption.
This internship realization is a part of the curriculum that applies at the Faculty
of Computer Science, University of Indonesia, have given the writer a priceless
experience. Thanks.
Jakarta, September 2002
The Writer
3
This document may be freely distributed in terms of the GNU Free Documentation
License, courtesy of Code Jawa
License statement:
Copyright (c) 2002 Sasmito Adibowo.
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.1 or any later version
published by the Free Software Foundation; with no Invariant Sections, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy
of the license is included in the section entitled "GNU Free Documentation
License".
Amendment Record
Version Date Author Change

1.0 September 12, 2002 Adib Initial Revision
1.1 September 11, 2002 Adib File monitoring algorithms
1.5 December 23, 2002 Adib Completing changes proposed by Krishna
1.6 January 09, 2003 Adib Additional contents requested from Dadan Hardianto
1.7 April 30, 2003 Adib Final corrections after examination.
4
TABLE OF CONTENTS
1 Foreword................................................................................................................................................ 7
1.1 Background ......................................................................................................................... 7
1.2 Job Description and Internship Objective........................................................................... 7
1.3 Report Organization............................................................................................................ 7
1.3.1 Company Profile .................................................................................................................................................... 8
1.3.2 System Description ................................................................................................................................................ 8
1.3.3 Project Execution ................................................................................................................................................... 8
1.3.4 Impact Analysis...................................................................................................................................................... 8
1.3.5 Concluding Remarks.............................................................................................................................................. 8
2 Company Profile.................................................................................................................................... 9
2.1 Brief History ........................................................................................................................ 9
2.2 Mission ................................................................................................................................ 9
2.3 Core Strategy..................................................................................................................... 10
2.3.1 Talent .................................................................................................................................................................... 10
2.3.2 Team ..................................................................................................................................................................... 10
2.3.3 Talk ....................................................................................................................................................................... 11
2.3.4 Tech....................................................................................................................................................................... 11
2.3.5 Trust ...................................................................................................................................................................... 11
2.4 Development Methodology................................................................................................ 11
2.5 Core Competencies ........................................................................................................... 12
2.5.1 Mobile Applications............................................................................................................................................. 12
2.5.2 Online Payment and Banking Solution............................................................................................................... 12
2.5.3 Custom Server-side Component Development .................................................................................................. 12
2.6 Company Culture .............................................................................................................. 12
2.7 Organization Chart ........................................................................................................... 13
3 System Description.............................................................................................................................. 14
3.1 Development Methodology................................................................................................ 14
3.2 Product Functions ............................................................................................................. 14
3.2.1 Use Cases.............................................................................................................................................................. 15
3.3 Scope ................................................................................................................................. 15
3.4 System Architecture........................................................................................................... 16
3.5 System Components........................................................................................................... 17
3.5.1 Agent..................................................................................................................................................................... 17
3.5.2 Client..................................................................................................................................................................... 19
3.6 Database Design ............................................................................................................... 19
3.6.1 Working Tables .................................................................................................................................................... 20
Project ................................................................................................................................................................................ 20
Application......................................................................................................................................................................... 21
project_application ............................................................................................................................................................ 21
project_status ..................................................................................................................................................................... 22
project_activity_type ......................................................................................................................................................... 22
project_activity .................................................................................................................................................................. 23
project_folder..................................................................................................................................................................... 23
project_file ......................................................................................................................................................................... 24
application_project_file..................................................................................................................................................... 24
3.6.2 Template Tables ................................................................................................................................................... 25
Project_template ................................................................................................................................................................ 25
Project_template_folder .................................................................................................................................................... 26
Project_template_activity_type......................................................................................................................................... 26
3.7 Behavioral Model and Description ................................................................................... 27
3.7.1 Application Events ............................................................................................................................................... 27
Application Switch ............................................................................................................................................................ 27
Power Change.................................................................................................................................................................... 27
5
Hide Popup ........................................................................................................................................................................ 27
File Write ........................................................................................................................................................................... 27
3.7.2 State-Transition Diagram..................................................................................................................................... 27
3.7.3 File Monitoring Algorithm .................................................................................................................................. 29
3.8 User Interface Design ....................................................................................................... 30
3.8.1 TFrmMain............................................................................................................................................................. 31
3.8.2 TFrmApplicationMgmt........................................................................................................................................ 32
3.8.3 TFrmEditApplication........................................................................................................................................... 32
3.8.4 TFrmGenReport ................................................................................................................................................... 33
3.8.5 TFrmProjectMgmt ............................................................................................................................................... 33
3.8.6 TFrmNewProjectWizard...................................................................................................................................... 34
Select Project Type............................................................................................................................................................ 34
Enter Project Information.................................................................................................................................................. 35
Define Project Activity Types........................................................................................................................................... 35
3.8.7 Define Project Folders.......................................................................................................................................... 36
Work on Project................................................................................................................................................................. 36
3.8.8 TFrmEditProject................................................................................................................................................... 37
Profile................................................................................................................................................................................. 37
Activity Types ................................................................................................................................................................... 37
Applications....................................................................................................................................................................... 38
Folders................................................................................................................................................................................ 38
TFrmEditProjectActivityType.......................................................................................................................................... 39
TFrmConfigDialog............................................................................................................................................................ 39
TFrmAboutDialog............................................................................................................................................................. 39
TFrmActivityPopup .......................................................................................................................................................... 40
3.9 Testing Environment ......................................................................................................... 40
3.10 Test Cases.......................................................................................................................... 41
4 Project Execution................................................................................................................................. 42
4.1 Materials Provided............................................................................................................ 42
4.1.1 User Interface Narrations ..................................................................................................................................... 42
4.1.2 High-Level Description – System Requirements Specification......................................................................... 42
4.2 New Design........................................................................................................................ 42
4.3 Project Plan....................................................................................................................... 43
4.4 Project Realization ............................................................................................................ 43
5 Impact Analysis ................................................................................................................................... 45
6 Concluding Remarks........................................................................................................................... 46
6.1 Job Experience .................................................................................................................. 46
6.2 General Suggestions.......................................................................................................... 46
6.3 Suggestions Related to the Project.................................................................................... 47
7 Bibliography ........................................................................................................................................ 48
6
1 Foreword
1.1 Background
The need to measure a software development effort is increasing, proportional to

the importance of software systems in today’s businesses. In such efforts, both
employers and clients need to keep track their progress to ensure that they’re
getting their money’s worth. But money spent in software development projects is
often difficult to correlate with the effort given by the developers – let alone
linking it with the project’s progress.
Traditionally, the developers are required to hand in a periodic written report to

their managers. Using these reports, the manager then relays the information to
the clients or employers (depending on whether it is a contracted or in-house
project). The system works well to some extent, but it has at least two drawbacks.
First, the information contained in the reports is often incomplete, distorted and
heavily filtered. Second, programmers often view writing reports as an overhead –
and indeed it is – which sometime impedes productivity.
As a software development company, Code Jawa attempts to address this issue

by providing a software solution. It is an automated work-tracking software that
logs a programmer’s day working in one or more software projects. Called MTC,
the software may also be generalized for use by other computer-intensive
knowledge-workers.
1.2 Job Description and Internship Objective
The intern was assigned to design and implement the MTC system. Design of the
system was continued from a previous project that was postponed.
As a temporary employee, the intern only receives an hourly wage, without

additional benefits normally provided to full-time employees.
1.3 Report Organization
The report is written to fulfill one of the requirements imposed on all internship
courses by the faculty. It serves the readers to gain an insight on the internship
period done by the writer.
Other than faculty requirements for the report, the organization on which the
internship took place has another requirement. All written communication and
documents within the company are in English. Therefore, this report is also
written in the language.
Following this section, organization of the report is as follows:
7
1.3.1 Company Profile
This section describes the organization in which the internship took place. It
articulates a brief history of the organization, mission, strategies, core
competencies and culture.
1.3.2 System Description

This section describes the product of the work that was done during the
internship period. It is a subset of the System Description document produced
during development.
1.3.3 Project Execution

This section describes the project’s execution during the internship. It provides
the initial timeline when the project was planned and the actual timeline when it
was executed. Provided along with the timelines are the grounds on why the
timeline was set, taking human factors into account
1.3.4 Impact Analysis

This section provides an analysis by the writer on the impact of the project to the
organization.
1.3.5 Concluding Remarks

This section articulates the writer’s opinion on the internship experience as an
overall. Additionally, the writer provides several suggestions for both the
organization and for further development of the product.
8
2 Company Profile
This section describes the organization in which the internship took place. It
articulates a brief history of the organization, mission, strategies, core
competencies and culture.
2.1 Brief History
Code Jawa’s track record goes back to 1996, when it was founded as Infoskape
by Iwan Tantra and some US-educated programmers fresh back from working in
US software companies. Their idea was a classic case of entrepreneurial vision:
Become the most advanced software design house in Indonesia.
Infoskape's initial contract was with the country's largest mobile telecom
company, Telkomsel, and the scope of that project was matched by a long-term
relationship to create and enable an internet based subscriber recruitment
management structure that would link hundreds of sales points across
Indonesia's vast archipelago. From there evolved a variety of projects that
involved a broad range of subscriber management functions, including SIM Card
distribution, usage monitoring for fraud management, and projects involving
sales channel management.
Infoskape was also retained by pointAhead.com to create a major e-commerce

platform that would enable "internet neophytes" to create stores online and sell
their Indonesian artwork and handicrafts directly to the West without having
several layers of middle men.
In between these major contracts, Infoskape built for itself a reputation of being
the best software house around, ranging from projects building web sites to
wireless SMS products to server side business functions.
Its next phase was to work as an offshore outsourcing staff for Spotcast
Communications, which is how Iwan Tantra, the founder of Infoskape, met Craig
Owensby, the founder of Spotcast.
When Spotcast's technology and US team were sold to Leap Wireless in early
2001, the two realized that their team in Indonesia was now available for a new
purpose - becoming a value-optimized option for offshore outsourcing.
In its new form, and with its new mission, Code Jawa focuses on creating a
business structure and corporate culture that meet the needs of US, European,
Australian, and other developed economy companies seeking a strategy for low
cost software development within a much leaner capital market and new
pressures to generate "real" ROI for the capital already invested.
2.2 Mission
This is the mission statement of Code Jawa:
9
To provide a value-optimized software development outsourcing option,
recognized for excellence throughout the world.
It intends to fulfill its mission by:
• Combining Indonesia's most talented programmers with internationally-

trained, highly- experienced Project Managers and Design Consultants;
• Assembled and managed under proven high-tech leadership emphasizing a

disciplined yet flexible development model;
• Creating a collaborative, communications-oriented, client-vendor

relationship that extends through the software development life-cycle;
• Bridging the physical and conceptual distance between the East and West
and leveraging the strengths of both in generating creative, effective, and
inexpensive software solutions for the clients.
2.3 Core Strategy
Code Jawa relies on a unique “5 T” strategy: Talent, Team, Talk, Tech and Trust.
Being the basis for its corporate culture and business approach, this strategy
enables the company to be comparable to those in the US or Europe. Its
Jawanese Magic combines the east to the west – utilizing Indonesia’s finest
programmers and design consultants with US management and standards.
2.3.1 Talent
From design specialists to programmers, each staff’s talents are measured from
his or her credentials, capability, and creativity. Credentials must include an
international or local tier-one university degree in Computer Science/Engineering
and proven development experience with a high technology company. Capabilities
must include mastery of various programming technologies, and may require
proven design and project management expertise with an international company.
While creativity is defined as the skill that effectively uses knowledge in order to
devise out-of-the-box solutions. This fuzzy factor differentiates a Code Jawa
programmer from everyone else.
2.3.2 Team
Code Jawa teams combine talent and organization to create performance. Project
teams are constructed to meet specific objectives. Using “best practices
management,” each team member is focused to the client’s needs and project
objectives. When the project’s schedule is agreed upon, the team recognizes that
they need to put in more time should they fall behind. After the project, the team
is rated both individually and collectively. This means that the team’s structure is
not a way to avoid responsibility, but to generate greater productivity and
accountability.
10
2.3.3 Talk
Communications are fundamental to Code Jawa. Clients are always engaged in
active talk with the development team, through phone calls and other
communication methods. Should the need arise, the team’s schedule will be
adjusted to overlap the client’s time zone.
In Code Jawa, communication skills are rated on a par with programming skills.
Since a lot of talk avoids mistakes and helps in creating better software.
2.3.4 Tech
While creating software that meets client’s needs is the ultimate goal, Code Jawa
also takes responsibility to make sure that it is on the cutting edge of technology.
State-of-the-art technologies are combined with experience across a variety of
functional needs to generate world-class software. It is done using a technique
that they call the Jawanese Magic.
2.3.5 Trust
Being a software development company that are often handed with highly
confidential “proof-of-concept” prototyping projects, intellectual property rights is
an important issue in Code Jawa. Often, temptations are imposed on the
employees to recognize that a new idea that clients have entrusted to Code Jawa
for development is a "big idea." Like programmers in the US and Europe, the
temptation may at times are too great. Therefore, the company have very
stringent policies on how coding is done to ensure that highly sensitive materials
are handled only within its offices. Employees are routinely reminded of the
results of any breach of client's confidentiality, including immediate dismissal
and aggressive criminal action.
2.4 Development Methodology
Code Jawa focuses on a hybrid Iterative/Evolutionary SDLC that proceeds from

specification to design through an iterative construction phase. Only when the
final design is agreed upon, then they move on to final coding, qualifying and
deployment. This ensures that lessons learned during prototyping can be
incorporated as new specifications leading to needed design changes before final
delivery. The goal is to deliver the software that clients actually need and then to
be there for the next phase evolution.
• Figure 1 Code Jawa SDLC
11
2.5 Core Competencies
Code Jawa’s core competencies roots from its vast experience in developing IT
solutions. Although most of its projects are rapid prototyping, proof-of-concept
solutions, often clients renew the contract to include construction of the final
system for deployment or commercial use.
The following lists the main areas of Code Jawa’s core competencies:
2.5.1 Mobile Applications
• Mobile portal with SMS, Interactive SMS, WAP and VRU delivery channels
• Custom handheld applications on Palm and Pocket PC;
• Mobile location personalization
• Subscriber acquisition, management, and administration business

processes
• Third party rating processes - micro-billing
• Profiling and dynamic content management and delivery
2.5.2 Online Payment and Banking Solution
• End-to-end mobile banking based on WAP and SIM Toolkit
• End-to-end Internet banking
• Payment gateway solutions for banks and online/offline merchants
2.5.3 Custom Server-side Component Development

Server-side components are the heart of Code Jawa’s solution framework.
Collectively called the Code Jawa Applications Framework (CJAF), they are loosely
coupled components existing independently across multiple servers. Together
they provide foundations for myriad solutions such as:
• E-Business and E-Commerce
• Back-end, legacy system integration business information systems
• Custom XML-based browser applications
• Personalized content management and delivery systems
2.6 Company Culture
Code Jawa has a loosely-bound culture – office formality is not considered

essential by its employees. To enhance creative atmosphere, the management
does not pose artificial barriers to the programmers. As an element of its core
strategy, Code Jawa emphasizes on strong internal communications in its
12
development team. The programmers are encouraged to discuss their issues with
their colleagues; even those colleagues that are not directly related to his project.
2.7 Organization Chart
Code Jawa focuses on a team-based organization structure. This structure

results in a compact chain of command with minimal bureaucracy. In correlation
with the “talk” part of the 5 Ts strategy, each member of the team is freely able to
consult freely to other members even though the consulted team member is not
related to the particular project.
Iwan Tantra Craig Owensby

CTO CEO
Stephen Tahjar Dion Isak Rickyanto Denymon

Software Engineer Software Engineer Software Engineer Software Engineer
Johan Cindra Krishna W Karang Ryan Wijaya

Software Engineer Project Manager Web Designer
The intern was placed in the team as a Software Engineer Intern. This position is
equivalent to other software engineers only differing in terms of pay, work times,
and benefit policies.
13
3 System Description
This section describes the product of the work that was done during the
internship period. It is a subset of the System Description document produced
during development.
The internship assignment in Code Jawa was to implement the prototype version
of MTC. Regarded as a personal edition, this is proof-of-concept prototype is to be
used internally in Code Jawa offices. On its success, Code Jawa will continue the
development of the full-fledged enterprise version for commercial use.
3.1 Development Methodology
The development of MTC follows Code Jawa’s iterative evolutionary model.

Initially, a Functional Description and System Requirements Specification
document is written to establish the initial specification of MTC. Then the
development continues iteratively in a bottom-up manner, developing the low-
level components and core functionalities prior to other functionalities.
3.2 Product Functions
MTC is a system that allows a company to monitor its project resources. The term
resources would be interpreted as human resources, time resources and
information resources. MTC is not made to be a supervisor for each project team
member, but it is made to optimize progress by monitoring some significant
variables of an ongoing project, which are:
• Applications that are used by each team member within a day
• Time activities on employee’s workdays (how do they spend their working time?)
• At the end of each project, MTC would be able to create a report that shows the
working pattern of each team member (what application that is mostly used, what
kind of activity that they mostly spend), and another report to the client that
include chargeable times for invoice purposes.
The goal of MTC is to provide reports that:
• Show the daily activities of the employee.
• Show how much time spent on each kind of activity.
• Show the activities done on a project and how much time spent in it.
This information would allow managers to gain input on efficiency improvement
as well as justifying work product to clients.
The main advantage of MTC compares to other project management tools or

activity-tracking tools is that with MTC users are occasionally reminded to enter
in ongoing activities as it happens. This feature overcomes the problem with
traditional activity tracking system. With traditional tools, the users will have to
intentionally open the system and manually enter in work information, which is
done at the end of the day -- or worse, accumulated at the end of the week.
Accuracy of this method is obviously questionable because most programmers
14
hate to document. With MTC, documentation is done subconsciously during work
time.
3.2.1 Use Cases
<<include>>
Query Application Usage Log current activity
Creat e Project
Query Idle Time
MTC System MTC User
Project Profile
generate view
<<include>>
Report
Edit Project
The MTC system queries the user’s activities while he/she is working on the
computer. It occasionally asks the user “What you were doing?” and records
various states of the computer at the time. It also records the start/stop times of
the activities and categorizes those activities. The user may also explicitly ask
MTC to record the current activity.
Activities are related to a project. Therefore, MTC provides basic functionalities to

create and modify project data. This includes a project’s profile and other
information regarding the project.
The activity data are then used to generate reports in various views. It serves to
assess the user’s activities on various projects. Reports may be generated at any
time, and are based on the currently available data.
3.3 Scope
MTC Personal Edition focuses on monitoring the activities for an employee during
work time. It is meant to be personal – placing the user at the center of the
system, providing full control on it.
15
Pr oject Subdirectories initialized by Initial Project Subdirectories
0..* 0..*
works in has 1 1.. 1 1..1 1

Project Project Profile 1 initialized by Profile Template
1 1..* 1 1..*
1 1
1 1 Specifies
MTC User 0..*
consists of 0..*
(f rom Bu si ne ss Use -Case Mo del)
An application may Project Applications Initial Activity Types
0..* be used in more
has 1
1 Activities than one project.
0..1
User Preferences
1..1
External Activities Computer Activities utilized in initialized by

1
1.. *
1..1
Categorizes Activity Types
1..n
A user of MTC has a set of preferences that determines the system’s behavior for
that user. The user works on one or more projects that are monitored by MTC. A
minimum of one project must exist in the system; this default is referred to as the
non-project project.
Every project has a profile that determines the activity types, project applications,
and directories that contains the project’s files. MTC store a list of known
applications, some of which are used in one or more projects.
Categorized by activity types, an activity may be an external activity or a

computer activity. Not using computers, external activities are those that MTC are
not able to specifically monitor. While computer activities are monitored directly
by MTC. Each computer activity involves the use of an application.
A project template defines the initial settings for a project. These predefined
options are the activity types and subfolder names that will be used for keeping
the project files. There are several pre-defined templates provided by the system.
They are available for selection when the user creates a new project.
3.4 System Architecture
Physically, MTC is separated into two parts: a small agent module and a large
client module. The agent module listens to system messages, while the client
module implements the majority of MTC’s functionalities.
16
Data-
hook window Main method Business method SQL Local
Agent Access
notifications messages
Window calls
Logic calls queries
Database
Objects
Windows
System process
boundary mtcclient.exe
mtcagent.dll BDE Engine
Placed in the dynamic-link library mtcagent.dll, the agent module listens to the
system’s messages by inserting itself into Windows’ global hook chain. It is called
by Windows at several events, and then the client module is notified of that event
as requested.
The client module receives agent notifications and then processes those
messages. Located in the main executable, mtcclient.exe, it implements the entire
user interface, the business logic, and the data access objects layers. Agent
messages are received by the main window, processed by the business logic,
which then may manipulate the database using the data-access objects.
The main window listens for agent messages posted in its message queue. The
agent messages are received in the form of a user-defined window message. Upon
reception of this message, the main window decodes it and then calls the
appropriate method in the business logic layer.
The business logic layer contains the business-processing parts of MTC. Apart
from receiving event notifications from the main window, it also runs
autonomously as a different thread separate from the main user interface.
The data access object layer manages the interaction between the business logic
and the database. It handles data-manipulation requests from the business logic
and implements them as SQL queries to the local database.
The personal edition of MTC uses a local (file-based) database. This allows MTC to
be used without requiring a database server. The local database uses the Borland
Paradox database engine, the default engine provided with Borland C++ Builder,
the development environment used in constructing MTC.
Each user of MTC owns a copy of the schema instance. In this setup, database
security is enforced by the operating system by protecting the data files that
make up the database.
3.5 System Components
3.5.1 Agent
As previously described, the agent module is a dynamic-link library which
implements callback functions that monitors events in the Windows global hook
chain. It installs WH_CBT, WH_KEYBOARD and WH_MOUSE hooks.
17
The WH_CBT hook callback function monitors for window-activation events. While
the WH_KEYBOARD and WH_MOUSE callback functions monitors for keyboard and mouse
activities, respectively.
When the agent receives a hook notification, it then posts it to the client window
through a user-defined window message. Since a posted window message cannot
carry much data with it, extra data that accompany the hook notification are
placed in the agent’s data area organized as a queue. It is called the agent
message data queue. The data items are then retrieved by the client window upon
receiving notification from the agent.
Being a global hook, the module may be called from within different processes,
thus different address spaces. Therefore, it requires a shared data area to
maintain its data across the different processes that it may be placed. The shared
data is implemented as a fixed-size buffer in a file-mapping object. Access to the
buffer is moderated through a mutex object, one of several synchronization
methods provided by the operating system. Although mutex objects are suspected
to be slower than critical section objects, the former is selected because it may be
shared among processes.
The shared data area contains the client’s window handle, the agent’s hooks
handles, agent message data queue, and the number of references to the data
area. The queue is implemented as a circular buffer which size is set at compile
time of the agent. Initially, the queue is empty and the handles are set to zero.
The client initializes the agent by calling the InstallHooks() function in the agent.
This function takes a window handle of the client window that will receive the
agent’s notifications. Only one window at a time may be listening to the agent;
subsequent requests will be ignored.
When the client is about to terminate, it should call the RemoveHooks() function in
the agent so that it will remove itself from the Windows global hook chain.
Removal of the hooks also allows another listener window to be registered with
the agent. If the client terminates unexpectedly -- or otherwise its window handle
becomes invalid -- the agent will detect this condition and automatically removes
itself from the hook chain.
The agent notifies the client by placing the message data in its internal queue and
then posting a UWM_AGENT_NOTIFY user-defined window message to the client’s
message queue. When the client receives this message, it must call
GetAgentMessageData() function to retrieve the message data from the agent’s
queue.
Agent messages are of type AgentMessage struct. It contains the message type and
a union containing the detailed data of the message. The following are the types
of messages that may be sent by the agent.
Message Type Meaning
AM_NULL This message has no meaning; therefore, it should not be handled.
AM_CBT_ACTIVATE A topmost window has been activated.
AM_KEYPRESS The keyboard was pressed.
18
AM_MOUSE The mouse was moved or its buttons was pressed.
3.5.2 Client
The client receives agent notifications via its main window, TFrmMain. The main
window processes the notifications and then calls the appropriate methods in the
business logic layer. Classes in the business logic then manipulate the database
through the classes in the data access object layer.
1.. 1 1.. 1
TFrmMain ActivityMonitor ActivityContext ActivityState
1 1 1 1
MonitoringState State_A State_C State_E
State_B State_D State_F

MonitoringState1 MonitoringState3
MonitoringState2 MonitoringStateIdle
The business logic that interfaces with the main window is the ActivityMonitor
class. It is a thin wrapper around an instance of ActivityContext, which the latter
is an active class descended from the VCL TThread class.
Business processing is primarily done in the ActivityContext class. It is an

extended state machine implemented by employing the state pattern. The state
machine runs in its own thread, separate from the user interface. Each of the
state class is a singleton class, subclass of ActivityContext. These singleton
classes stores their data not in their own instances, but as member variables in
ActivityContext.
The data access classes are ProjectDAO and ApplicationDAO. These classes perform
the database manipulation upon request of the classes in the business logic
layer. Their operation is supported by value objects that functions as object-
oriented counterparts of the database records.
3.6 Database Design
This section describes the database schema of MTC. It lists the tables, its fields
and the relations between those tables.
The personal edition of MTC uses a local (file-based) database. This allows MTC to
be used without requiring a database server. The local database uses the built-in
Borland Paradox engine. The field types are specified using Paradox’s type names.
19
Each user of MTC owns a copy of the schema instance. In this setup, database
security is enforced by the operating system by protecting the data files that
make up the database.
3.6.1 Working Tables

This section describes the tables actively used by MTC during its operation. These
tables are continuously updated while MTC is running.
project
project_id: AUTOINC application
project_status project_application application_id: AUTOINC
status_id: AUTOINC (FK)
status_id: AUTOINC project_name: VARCHAR(40) application_id: AUTOINC (FK) executable_file: VARCHAR(255)
status_name: VARCHAR(40) description: BLOB(1,1) project_id: AUTOINC (FK) application_name: VARCHAR(255)
dt_lastchanged: Timestamp project_start: Timestamp description: BLOB(1,1)
dt_lastchanged: Alpha(18)
project_finish: Timestamp file_exists: BOOLEAN
root_folder: Alpha(18) dt_lastchanged: Timestamp
dt_lastchanged: Timestamp
project_folder
project_id: AUTOINC (FK) application_project_file
folder_name: VARCHAR(255) application_id: AUTOINC (FK)
project_id: AUTOINC (FK)
folder_exists: BOOLEAN
folder_name: VARCHAR(255) (FK)
file_name: VARCHAR(255) (FK)
dt_lastchanged: Alpha(18)
project_activity_type project_activity
project_id: AUTOINC (FK) project_id: AUTOINC (FK)
activity_type_id: AUTOINC activity_id: AUTOINC
activity_name: VARCHAR(40) activity_type_id: AUTOINC (FK)
description: BLOB(1,1) application_id: AUTOINC (FK)
dt_lastchanged: Timestamp folder_name: VARCHAR(255) (FK) project_file
file_name: VARCHAR(255) (FK) project_id: AUTOINC (FK)
description: BLOB(1,1) folder_name: VARCHAR(255) (FK)
activity_start: Timestamp file_name: VARCHAR(255)
activity_finish: Timestamp
file_exists: BOOLEAN
Project
The project table contains the records about the various projects that are
managed by MTC. Activities recorded by MTC will always be related to a project.
Additionally there is a project called non-project that may be used to associate
activities that are not normally related to a project. This default project has a
project_id value of 0.
Project
Field Name Type Constraints Description

project_id Integer Primary key The project’s unique identification.
status_id Integer Foreign key to The project’s current status. The
project_status status names are defined by the
(status_id) project_status table.
project_name Varchar(40) None The name of the project. This

name should be unique, but it is
not required to be so.
Description Blob(1,1) None A free-form text that describes the
project.
20
project_start Timestamp None The project’s start date.
project_finish Timestamp None The project’s finish date.
root_folder Varchar(255) None The root folder in the local
computer which contains all of the
data files relating to the project.
dt_lastchanged Timestamp None The last time this project’s record
was updated.
Application
The application table contains a list of applications that are used by the projects.
This table always contains an application record called no application that has an
application_id value of 0.
Application

application_id Integer Primary key The application’s unique
identification.
executable_file Varchar(255) None The name of the application’s
executable file, specified without a
path specification. This field should
be unique, but it is not required to
be so.
application_name Varchar(255) None The descriptive name of the
application. This name should be
unique, but it is not required to be
so.
description Blob(1,1) None A free-form text that describes the
project.
file_exists Boolean None Unused
dt_lastchanged Timestamp None The last time this application’s
record was updated.
project_application
The project_application table acts as a many-to-many link between the project
table and the application table. This table lists which applications are used by
which projects and vice-versa.
project_application

application_id Integer Primary key and Specifies the application involved
foreign key to in the relation.
21
application
(application_id)
project_id Integer Primary key and Specifies the project involved in

foreign key to the relation.
project
(project_id)
dt_lastchanged Timestamp None The last time this record was

updated.
project_status
The project_status table acts as a lookup table for project status. It defines the
allowable values for a project’s status.
project_status

Status_id Integer Primary key Uniquely identifies the status
name.
Status_name Varchar(40) None The text used to name the status.
This field should be unique, but it
is not required to be so.
dt_lastchanged Timestamp None The last time this record was
updated.
project_activity_type
The project_activity_type table defines the activity types available for each
project. A project has its own types of activities. These activity types are used to
categorize the various activities for MTC. For every project there is always a
default activity type called uncategorized activity. This activity type as an
activity_type_id value of 0.

project_id Integer Primary key and Defines the project that this
foreign key to activity type belongs to.
project
(project_id)
activity_type_id Integer Primary key Uniquely identifies this activity

type.
activity_name Varchar(40) None The name of the activity. This
name should be unique, but it is
not required to be so.
description Blob(1,1) None Free-form text about the activity
22
type.
dt_lastchanged Timestamp None The last time that this activity type
was updated.
project_activity
This table stores the basic unit of activity stored by MTC. Activities are
categorized by an activity type, and are related with a project and an application.
project_activity

project_id Integer Primary key and foreign Defines the project that
key to project this activity belongs to.
(project_id)
activity_id Integer Primary key Uniquely identifies the

activity
activity_type_id Integer Primary key and foreign Defines the type of this
key to activity.
(activity_type_id)
application_id Integer Foreign key to States the current

application application during this
(application_id) activity.
folder_name Varchar(255) Foreign key to Unused
project_file
(folder_name)
file_name Varchar(255) Foreign key to Unused

project_file
(file_name)
description Blob(1,1) None Free-form text

describing the activity.
activity_start Timestamp None The starting date/time of
the activity.
activity_finish Timestamp None The ending date/time of
the activity
dt_lastchanged Timestamp None Unused
project_folder
The project_folder table is only partially used and is present to facilitate further
development.
project_folder
23
key to project this folder belongs to.
(project_id)
Folder_name Varchar(255) Primary key The folder’s name

Folder_exists Boolean None Unused
Dt_lastchanged Timestamp None Unused
project_file
The project_file table is currently unused and is present to facilitate further
development.
project_file

key to project this file belongs.
(project_id)
Folder_name Varchar(255) Primary key and foreign Defines the folder that
key to project_folder this file belongs.
(folder_name)
File_name Varchar(255) Primary key Unused

File_exists Boolean None Unused
Dt_lastchanged timestamp None Unused
application_project_file
The application_project_file table is currently unused and is present to facilitate
further development.
Application_project_file

Application_id Integer Primary key and foreign Defines the application
key to application that this file belongs to.
(application_id)
key to project this folder belongs.
(project_id)
Folder_name Varchar(255) Primary key and foreign Defines the folder that
key to project_folder this file belongs.
(folder_name)
24
File_name Varchar(255) Primary key and foreign Defines the file of the
key to project_file project file.
(file_name)
Dt_lastchanged timestamp None Unused
3.6.2 Template Tables

This section describes the static template tables. These tables contain static data
that are not normally updated.
project_template
template_id: AUTOINC
template_name: VARCHAR(20)
project_template_activity_type project_template_folder
activity_type_id: AUTOINC folder_id: AUTOINC
template_id: INTEGER (FK) template_id: INTEGER (FK)
activity_name: VARCHAR(40) folder_name: VARCHAR(255)
The project templates define the initial settings for a newly created project.
Therefore, when new projects are created, several aspects of the project are
already configured.
Project_template
The project_template is the master table that stores the pre-defined project
settings (project templates). Data contained in this and its detail tables are not
meant to be updated.
Project_template

project_template_id Integer Primary key Uniquely identifies the project
template.
template_name Varchar(255) none The displayed name of the
project template. This name
should be unique.
25
Project_template_folder
The project_template_folder table defines the folder names of a project template.
When a new project is created, the folders are auto-created based on the project
template.
project_template_folder

project_template_id Integer Primary key and foreign Defines which
key to project_template project template
(project_template_id) that this folder
belongs.
folder_id Integer Primary key Uniquely
identifies the
project template
folder.
folder_name Varchar(255) None Defines the
folder’s name.
This field should
be unique.
Subfolders are
specified using a
relative path
name.
Project_template_activity_type
The project_template_activity_type defines the initial activity types for a new
project. For each project template, there is always an activity type called
uncategorized activity that has an activity_type_id value of 0.
project_template_folder

project_template_id Integer Primary key and foreign Defines which
key to project_template project template
(project_template_id) that this activity
belongs.
activity_type_id Integer Primary key Uniquely
identifies the
activity type.
activity_name Varchar(255) None The activity
name. This field
should be unique.
26
3.7 Behavioral Model and Description
This section describes the events responded by MTC and its internal state
machine. These events are the primary inputs of the business logic layer, while
the state machine comprises the majority of the layer.
3.7.1 Application Events

This section lists the application-defined events of MTC. These events are the
primary triggers of the activity monitor state machine transitions.
Application Switch
This event is raised when the user switches to another application. It is obtained
by the agent from the CBT hook chain and then relayed to the client.
Idle User
This event is raised when the user is idle. It is inferred when the keyboard and
mouse has not been used for a prolonged amount of time. Keyboard and mouse
activities are sent by the agent, and then the client will decide whether a
significant amount of inactivity has occurred.
Power Change
This event is raised when the computer is entering suspend or hibernate mode. It
is obtained from a window message -- WM_POWER -- that is broadcasted to all top-
level windows upon power state changes.
Hide Popup
This event is raised when the popup window – TFrmActivityPopup – has been
dismissed by the user. The window reports this event to the activity monitor.
File Write
This event is raised when a file located within the current project’s directory (or
its subdirectories) is written. File writes are detected by the TDirectoryMonitor
component, and notified to the activity monitor via the main form.
3.7.2 State-Transition Diagram

This section provides the state-transition diagram of the activity monitor. It is
implemented in the ActivityContext class as an extended state machine. In order
for the diagram to be comprehensible, it only depicts the significant state
transitions of the machine.
27
MTC Start up The last known
currentApplication is
application switch automatically recorded
as an activity
application switch
Monitoring (A) Record
1 currentApplication
The popup dialog
displays the last known (D) record application
no application
application currentApplication usage activity
switch for
tpShortApp switch no application
seconds switch for answer
tpLongApp popup dialog
(B) note Monitoring seconds (C) display
currentApplication 2 application popup
user is idle user is idle
(F) record tpPeriodicPopup elapsed

idle time (E) Record last activity Monitoring
before going idle 3
popup dialog Monitoring Idle time

answered (popup displayed)
user is idle
There are three time parameters involved in the state machine: tpShortApp,
tpLongApp, and tpPeriodicPopup. These parameters are configured at run-time, and
must consist of increasing values in the order listed. That is, tpShortApp <
tpLongApp < tpPeriodicPopup.
Initially, the system is in the Monitoring 1 state. At this state, it waits for the user
to switch application. When another application becomes active, it records the
application in the (A) Record currentApplication state. The system will then
automatically return to Monitoring 1.
When any one application have been active for tpShortApp seconds, the system
will assume that the user is working on the application. It then proceeds to state
(B) note currentApplication to record the current application as active and being
worked on. Afterwards, the system will move to state Monitoring 2.
When in Monitoring 2 and the user have not switched applications for tpLongApp
seconds, it is assumed that he/she is doing a significant activity in the
application. Therefore, a popup window is displayed asking the user about the
activity in progress. The system moves to state (C) display application popup in
order to show the popup window. On the contrary, if the user is only using an
application for a short time – thus switch to another application – the system will
move back to state (A) record currentApplication.
Since the state Monitoring 2 assumes that an activity is taking place, it is

expected that the keyboard or mouse is being used – there are key presses
and/or mouse clicks/movements. If that is not the case, then the user is
considered idle. The system then proceeds to state (E) record last activity bofore
going idle and then to the Monitoring Idle Time state. In this state, the popup
window is displayed along with a timer that shows how long the user has been
idle.
When the user answers the popup window and then closes it, the system will be
in state (F) record idle time and then goes to state (B) note currentApplication.
28
When the system is in state (C) display application popup, it will display a popup
window which prompts the user to enter information about his/her current
activity. Should the user fills in the activity information then closes it, the system
will move to state (D) record application usage activity to record the information
given by the user. On the other hand, if the popup window is displayed for a very
long time and there is no keyboard/mouse activity, the user is considered idle. In
this condition, the system moves to state (E) record last activity before going idle.
After recording the activity information in state (D) record application usage
activity, the system will then proceed to the Monitoring 3 state. Should the user
switches to another application, the system will go back to state (A) record
currentApplication. If the system remains in this state for longer than
tpPeriodicPopup (which by default is set to one hour), the system will move to
state (C) display application popup to periodically ask the user what he/she is
doing. As in most other states, if there is no keyboard mouse/activities for a
significant amount of time, the system will move to state (E) record last activity
before going idle.
The following table maps the state names in the previous state diagram to each of
the implementing state classes pictured in the class diagram in section 3.5.2.
Each class that implements a state is a leaf class (lowest in the inheritance
hierarchy).
State Name Implementing Class
Monitoring 1 MonitoringState1
(A) Record currentApplication State_A
(B) note currentApplication State_B
(C) display application popup State_C
(D) record application usage activity State_D
(E) record last activity before going idle State_E
(F) record idle time State_F
Monitoring idle time (popup displayed) MonitoringStateIdle
3.7.3 File Monitoring Algorithm
The file monitoring code is done in the TDirectoryMonitor component. This

component watches a directory for file-write events in the directory and its
subdirectories. When one or more file are written, the component generates an
OnLastWrite event for each file, providing the event handler with the full path
name of the file, along with its timestamps of before and after the write had
happened.
29
: Activ ityMonitor : TFrmMain : TDirectoryMonitor : TFile Wr iteMonitor
Current Project
Selected
get Current
Project directory
Activate file monitoring on Create TFileWriteMonitor

the Current Project Directory thread instance
Start TFileWriteMonitor Initialize table of file timestamps for

thread the files in the monitored directory
Waiting for
file writes
thread terminated
a file was written
Begin
directory scan
For all files, compare the last-write

timestamp to the one in the table.
Record the modified file as the Notify the activity monitor

current file being worked on that a file write has occurred Generate an OnFileWrite
event for each modified file
Activity monitor
notified Event
Generated
End directory
scan
Clean-up thread
instance
File Monitoring Algorithm
TDirectoryMonitor relies on the Windows API function FindFirstChangeNotification

to monitor the directory. When called with a directory name, the function
provides a handle that can be blocked upon until there are certain types of events
happened to the files within the directory. The component creates a thread (an
instance of TFileWriteMonitor) that block on this object to wait for file-write
events.
Prior to blocking on the returned handle, the thread records the timestamps of all
files within the monitored directory. Then it blocks on the given handle, waiting
for file-write events to occur. When it unblocks, it then re-scans the files for
changes in its last-write timestamp. When the timestamp change, the component
raises the OnLastWrite event for the file.
3.8 User Interface Design
This section describes the general user-interface flow of MTC. It provides the state
diagrams of the user interface, along with sample screenshots of each state. Since
30
the user interface consists of Windows-based forms, the state diagram is drawn
without explicit returning state transition lines.
Add...
Manage|Applications... TFrmApplicationMgmt TFrmEditApplication
Edit...
Manage|Report...
Settings|Application List... Project|New...
TFrmGenReport Report|By Project

TFrmNewProjectWizard
Startup Report|By Period TFrmProjectMgmt

Project|Edit...
Manage|Projects...
TFrmMain Settings|Preferences
Manage|Exit TFrmEditProject
TFrmConfigDialog
shutdown Manage|Preferences
Edit...
TFrmAboutDialog Add...
Help|About MTC... Help|About MTC...
TFrmActivityPopup TFrmEditProjectActivityType
Log Activity
Figure 2 MTC User Interface States
3.8.1 TFrmMain
This is the main form that is presented at MTC startup. It displays the current
project and provides a set of commands to access more functionalities of MTC.
The current project drop-down box also serves to set the current project. Activities
that are being monitored by MTC are related to this project.
This form is automatically hidden when it loses keyboard focus. Clicking on

MTC’s tray icon will re-display the form, which by default will be placed on the
upper-right quadrant of the screen.
31
3.8.2 TFrmApplicationMgmt
This form functions as the user interface in managing the list of applications
known by MTC. It provides functionalities to add, modify, and remove application
records. The form is displayed as a modal dialog box.
3.8.3 TFrmEditApplication
This form is used to add or modify an application’s record.
32
3.8.4 TFrmGenReport
This form is used to generate reports about the activities that are monitored by
MTC. It may generate three types of report. They are annual report, daily project
report, and summarized project report.
3.8.5 TFrmProjectMgmt
The project management form is used to create new projects, modify existing
projects, and access most of MTC’s functionalities.
33
3.8.6 TFrmNewProjectWizard
This form serves to assist users in creating a new project. It guides the user
stepwise in creating the project.
Select Project Type
In this step, the user is presented with a list of pre-defined project templates.
These templates will determine the default settings for the next steps in the
project creation.
34
Enter Project Information
This step instructs the user to enter the project’s name, it’s status, start/finish
dates, and enter a description about the project.
Define Project Activity Types
A list of available activity types of the project is displayed. This list is populated
according to the selected project template. The user may add, modify, or remove
these activity types before continuing to the next step.
35
3.8.7 Define Project Folders
This step defines the project’s root folder and its subfolders. The root folder by
default is derived from the project’s name and placed under the user’s My
Documents folder. The list of subfolders is obtained from the project template
specified earlier in the project. Upon completion of this step, the project’s folder
and subfolders are automatically created.
Work on Project
This is the final step of the wizard. The user is provided with an option to make
the newly created project as the current project.
36
3.8.8 TFrmEditProject
This form allows the user to modify the information about a project. They are the
project’s profile, activity types, applications, and its folders.
Profile
Activity Types
37
Applications
Folders
38
TFrmEditProjectActivityType
This form allows the user to add or modify an activity type of a project.
TFrmConfigDialog
This form allows the user to modify the time parameters of MTC’s activity monitor
and its database path.
TFrmAboutDialog
39
This form displays MTC’s version and copyright information.
TFrmActivityPopup
This form serves to gather information about the user’s current activity. Apart
from being invoked by user-interface commands, it may also be occasionally
displayed by the activity monitor.
3.9 Testing Environment
MTC was tested on three personal computers aside from the inter’s own
development PC. They are, the CTO’s notebook, the project manager’s notebook
and one of the software engineer’s workstation. Specifications of the computers
are as follows:
FIC Notebook
• Windows 2000 Professional Edition, service pack 2
• Pentium II 366 Mhz
• 128MB RAM
• 5.9GB Harddrive
Toshiba Notebook
• Windows 2000 Professional Edition, service pack 1
• Pentium II 200 Mhz
• 128MB RAM
• 10GB Harddrive
• Dell Notebook
Dell Notebook
40
• Windows XP Professional Edition
• Pentium III 700Mhz
• 128MB RAM
• 10GB Harddrive
Mugen Workstation
• Pentium III 800Mhz
• Windows 2000 Server, service pack 2.
• 256MB RAM
• 40GB Harddrive
3.10 Test Cases
Test Name Flow Description Test Result Remarks
Create Open the project window and chose New Success A new project was
Project Project Wizard created.
Edit Project Open the project window and double-click Success The Project’s data was
on a project displayed, ready for
editing.
Log Activity Open the MTC main window and click on Success The Log Activity dialog
log activity. was displayed.
Hibernate Start MTC in debugging mode. Use other Success The activity monitoring
Computer applications for a while and then hibernate engine moved to
the computer. State_A just before the
computer hibernates.
Generate Open the project window then choose Success The project report is
Report Report|By Project... displayed on-screen
ready for printing.
41
4 Project Execution
This section describes the project’s execution during the internship. It describes
how the project was re-opened, and timelines its continuation. Provided along
with the timelines are the grounds on why the timeline was set, taking human
factors into account
4.1 Materials Provided
Being a postponed project, the design of MTC was partially worked on. Code Jawa
provides the intern with several documents that elicits the ideas for MTC as a
software product. The following describes those documents. Because of copyright
restrictions, they cannot be included here in the report.
4.1.1 User Interface Narrations

Alternatively called user stories within Code Jawa, these documents describe in a
storytelling manner on how a user will use MTC in his or her day-to-day
activities. These stories are arranged chronographically from the time the user
starts MTC until he or she shuts down the system. There are several versions of
this document, each provided by different members of the Code Jawa team.
4.1.2 High-Level Description – System Requirements Specification

HLD-SRS documents are provided to the client as part of Code Jawa’s software
development methodology. It contains abstract description for the system. Since
HLD-SRSs are made prior to the agreement on a Letter of Intent, they are
deliberately made vague to inhibit copyright infringements in case the client
decides to employ other software development firm.
In case of MTC, the HLD-SRS document is made for internal use only. Included in
the document are the general description, functional description, technical
description, and release plan.
4.2 New Design
Continuing the preliminary design by Code Jawa’s team, the intern produced a
Functional Description – System Requirements Specification document. In Code
Jawa’s methodology, FD-SRSs are provided to the client when a contract has
been agreed. They build on the previous HLD-SRS to provide a more detailed
description of the system.
The intern wrote an FD-SRS document for MTC. The FD-SRS of MTC details
those sections that are still vague in the HLD-SRS. In addition to those contained
in HLD-SRS, the document includes sections such as system design architecture,
behavioral model and description, and database table definitions.
42
4.3 Project Plan
Initially, the project schedule is set optimistically. The schedule was based on the
intern’s previous experiences working in academic assignments and several
software development projects. A small amount of buffer time was always
provided at the end of each phase to anticipate minor setbacks.
The development of the system was to be divided into three phases. They are the
planning, construction, and documentation stages. Not much analysis was done
since the project is primarily a proof-of-concept prototype.
The first phase was to establish a preliminary design of the system that also serve
as a plan for its implementation. In this phase, a document entitled Functional
Description and System Requirements Specification was written. This document
was to act as a guide in the implementation process that followed.
The second phase is the system construction. Further divided into two sub-
phases, it consists of primarily writing and debugging program code. Coding in a
bottom-up manner, the first sub-phase was to construct the lower-level
functionalities that will be required to test the rest of the system. The second sub-
phase was to implement the rest of the functionalities while continuing the
testing of the system.
Feb 3, '02 Feb 17, '02 Mar 3, '02 Mar 17, '02 Mar 31, '02 Apr 14, '02 Apr 28, '02 May 12, '02 May 26, '02 Ju
ID Task Name W S T M F T S W S T M F T S W S T M F T S W S T M F T S W S T M F
1 Design/Planning
2 Requirements Specification
3 System Architecture Plan
4 Evaluate System Architecture
5 Implementation / Debugging
6 Low-Level System Components
7 User Interface Components
8 Complete Prototype
9 Evaluate Design
10 Re-design architecture
11 Implement re-design
12 Alpha testing
The final phase was system documentation. In this phase, the source code was to
be cleaned up and augmented with comments that would be the source of the
generated documentation. Additionally, a System Description document was to be
written. This document, along with the documentation automatically generate the
source code, serves to assist programmers in the maintenance and further
developments of the system.
4.4 Project Realization
The first few weeks, the project was ahead of schedule. The requirements
specification phase was done without much problem. Development continued
smoothly to the low-level components, and the data-management functionalities
smoothly.
Unfortunately, at the end of March, the project schedule was disrupted because
of an incident -- unrelated to the project -- that was experienced by the intern.
Although not impacting any physical damage, this incident heavily affects the
intern’s schedule and morale. Therefore, the project is intermittently disrupted.
Rough periods occurred at April-May, where the development continued out-of-

site. At the start of April, this method of work went well. At mid April, a milestone
43
release was made. This release revealed that an extensive modification of the
activity monitor was required. Development then continued to adjusting the
activity monitor and completing the last set of features.
During the final phases of development, the people at Code Jawa were occupied
with another project. Therefore, the out-of-site method was a bit difficult because
of communications barriers. Although the gross period was more than expected,
when calculated on an hourly period the project was completed on time.
Finally, the project was completed at September 2002. The project results a
working prototype of the MTC system, and its documentation that will assist
Code Jawa’s developers to further extend and maintain the system. The System
Description documentation consists of two parts:
• Human-written document that provides a global overview of the system.
• Generated documentation from the source code comments that provides

detailed descriptions of each classes, methods, and functions.
6, '02 Feb 3, '02 Mar 3, '02 Mar 31, '02 Apr 28, '02 May 26, '02 Jun 23, '02 Jul 21, '02 Aug 18, '02 Sep 15, '02
ID Task Name T S W S T M F T S W S T M F T S W S T M F T S W
1 Initial Briefings
2 Draft System Requirements
3 Studying Code Jawa Methodologies
4 Project Planning
5 System Requirements
6 Study Code Jawa Frameworks
7 Code Preliminary Frameworks
8 System Requirements
9 Agent Module and Framework
10 Entity-Relationship Diagram
11 Agent Module and Framework
12 User Interface and Project Management func
13 Activity Management functions
14 Preliminary Business Logic
15 Idle Session Monitoring
16 Application Switch Monitoring
17 Research Low-level API functions
18 Business Logic Redesign
19 Re-implement new design
20 Re-implement activity monitor
21 Stabilize Agent Module
22 Bug fixes
23 Feedback
24 Bug Fixes
25 Plan for New Project Wizard
26 Implement New Project Wizard
27 Implement Project Reports
28 Meeting for New Project Wizard
29 Implement Project Reports
30 Implement Configuration Dialog
31 Bug fixes
32 New requirement on reporting
33 Debugging Reporting
34 Testing
36 Source Code Documentation
37 Code File Monitoring component
38 Integrate File Monitoring component
40 Debugging
41 Testing
44
5 Impact Analysis
The advent of MTC enables Code Jawa to more closely monitor the progress of its
programmers. Some of the reports generated by MTC may be given to the client in
order to keep track of the progress of the project and to justify the costs
associated with the project.
This prototype of MTC will initially be used by Code Jawa’s Chief Technology
Officer to ensure that the activity monitor state machine implemented in the
system is suitable for the typical workflow of a programmer or an analyst. Should
the system proved effective, it will be used by the programmers of Code Jawa.
The flexibility of the state pattern implemented in the machine allows for easy
modification of its behavior.
After Code Jawa’s internal use of the system, MTC is planned to be extended into
an enterprise version. In this more advanced version, the system will comprise of
a client-server system in which it will act as a project-management system as well
as a monitoring tool.
The product will be one of Code Jawa’s mass-market packaged products intended
for companies that possess a large amount of workers whom intensively work
with computers. These companies will not only include other software
development organizations, but also consultants, advertising companies,
Internet-content companies and publishing companies. Any computer-intensive,
project-based organizations will benefit from the use of MTC.
45
6 Concluding Remarks
In this section, the intern provides some conclusions that are obtained from the
internship period. These are personal opinions of the intern, and do not reflect
any of the company’s views. Additionally, the intern also provides some
suggestions both to the company and to other interns of the faculty.
6.1 Job Experience
Working in a small company as a software developer has the advantage of

freedom and independence. It allows one to interact better with other employees
in the office, and there is less bureaucratic overhead to comply. The hacker
environment that is common in small companies allows one to use the preferred
development tools better suited for the job, instead of the tools dictated by
management because of company policies.
On the other hand, a small company may not possess the rigidity of more mature
organizations. The lack of procedures and standards sometimes require the
programmer to invent his/her own, which may conflict with others. These include
the style of source code comments, documentation formats, and especially
development methodology.
What may be a professional trait as a programmer is the lack of diversity in the

job. Since coding is the main job function, most work time is spent in front of a
PC, churning out or correcting program code. This may be the cause of the lack of
social and communication skills pertinent in most programmers. Different from
those open-source hackers that are also required to document their code and
communicate with users, it seems that a running software and extensive feature
set are the topmost priorities for closed-source, small-company programmers.
Past successes may also become an obstacle for naïve software developers. Being
over-confident, the intern did not anticipates that the amount of stress and the
interference of other problems external to the project might hinder the
productivity of the developer. Attending to classes full-time at 18 credits, having
an internship (which officially worth three credits, but in reality takes at least 20
hours a week not including transport overhead), and teaching a class for three
credits a week seemed like an easy thing to do at first. Now it is apparent that the
amount of activity incurred (although still being manageable), lead to a significant
amount of stress. The carelessness caused by the intense pressure in turn allows
an accident to occur, which eventually disrupts the whole activities of the intern.
6.2 General Suggestions
It would be advantageous if new programmers to the company are given a quick-

start guide to ease their adaptation to the organization’s practices and norms.
This guide should introduce the company’s standards, methodologies, and the
facilities provided (such as the company’s LAN and groupware system).
46
In the areas of development methodology, it may be useful to provide a CASE
system that guides both programmers and project managers in the course of each
project. The methodology should be augmented with standardized forms and
guidelines for the documents involved in the project, including the requirements
specification and system description documents.
6.3 Suggestions Related to the Project
Currently adhering to the work patterns of Code Jawa’s CTO, the state machine
of MTC’s activity monitor may not suite to other employee’s work habits. Ideally,
research should be done to elicit common work patterns of computer-intensive
workers, including their use of applications, patterns of keyboard/mouse
activities, and the time spent between read/think/write cycles during work.
Acknowledging that this type of psychological research may be expensive, it may
be worthwhile in order to perfect MTC’s monitoring engine, which in turn enables
the system to provide better reports about the employee’s activities.
47
7 Bibliography
Austern, Matthew H. Generic Programming and the STL: Using and Extending the
C++ Standard Template Library. Addison Wesley Longman, Inc, 1999.
Borland. Borland C++ Builder Help. Inprise Corporation, 2000.
Booch, Grady, et. al. The Unified Modeling Language User Guide. Addison-Wesley
Longman, Inc, 1999.
Cormen, Thomas H, et. al. Introduction to Algorithms. The Massachusetts Institute

of Technology, 1990.
Gamma, Erich, et. al. Design Patterns: Elements of Reusable Object-Oriented

Software. Addison-Wesley Publishing Company, 1995.
Microsoft. Microsoft® Win32® Programmer's Reference. Microsoft Corporation,

1996.
Pressman, Roger S. Software Engineering: A Practitioner’s Approach Fifth Edition.

McGraw-Hill Higher Education, 2001.
Solomon, David A, Mark E Russinovich. Inside Microsoft Windows 2000 Third

Edition. Microsoft Press, 2000.
Telles, Matt. High Performance Borland C++ Builder. The Coriolis Group, Inc,
1997.
Whitten, Bentley, et.al. System Analysis and Design Methods. McGraw-Hill,

1999.
48

Meeting Thinking and Coding - Internship Report

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Meeting Thinking and Coding - Internship Report

Transféré par

Droits d'auteur :

Formats disponibles

Internship Report:

Meeting, Thinking and Coding (MTC)

September 16, 2002

Faculty of Computer Science

2. Mr Dadan Hardianto, as the Academic Advisor who have given suggestions,

7. All civitas academica of the Faculty of Computer Science, University of

Jakarta, September 2002

Copyright (c) 2002 Sasmito Adibowo.

Version Date Author Change

The need to measure a software development effort is increasing, proportional to

Traditionally, the developers are required to hand in a periodic written report to

As a software development company, Code Jawa attempts to address this issue

1.2 Job Description and Internship Objective

As a temporary employee, the intern only receives an hourly wage, without

1.3 Report Organization

Following this section, organization of the report is as follows:

1.3.2 System Description

1.3.3 Project Execution

1.3.4 Impact Analysis

1.3.5 Concluding Remarks

2.1 Brief History

Infoskape was also retained by pointAhead.com to create a major e-commerce

This is the mission statement of Code Jawa:

It intends to fulfill its mission by:

• Combining Indonesia's most talented programmers with internationally-

• Assembled and managed under proven high-tech leadership emphasizing a

• Creating a collaborative, communications-oriented, client-vendor

2.3 Core Strategy

2.4 Development Methodology

Code Jawa focuses on a hybrid Iterative/Evolutionary SDLC that proceeds from

• Figure 1 Code Jawa SDLC

2.5.1 Mobile Applications

• Custom handheld applications on Palm and Pocket PC;

• Mobile location personalization

• Subscriber acquisition, management, and administration business

• Third party rating processes - micro-billing

• Profiling and dynamic content management and delivery

2.5.2 Online Payment and Banking Solution

• End-to-end mobile banking based on WAP and SIM Toolkit

• End-to-end Internet banking

• Payment gateway solutions for banks and online/offline merchants

2.5.3 Custom Server-side Component Development

• E-Business and E-Commerce

• Back-end, legacy system integration business information systems

• Custom XML-based browser applications

• Personalized content management and delivery systems

2.6 Company Culture

Code Jawa has a loosely-bound culture – office formality is not considered

2.7 Organization Chart

Code Jawa focuses on a team-based organization structure. This structure

Iwan Tantra Craig Owensby

Stephen Tahjar Dion Isak Rickyanto Denymon

Johan Cindra Krishna W Karang Ryan Wijaya

3.1 Development Methodology

The development of MTC follows Code Jawa’s iterative evolutionary model.

3.2 Product Functions

The main advantage of MTC compares to other project management tools or

3.2.1 Use Cases

Activities are related to a project. Therefore, MTC provides basic functionalities to

works in has 1 1.. 1 1..1 1

External Activities Computer Activities utilized in initialized by

Categorized by activity types, an activity may be an external activity or a

3.4 System Architecture

3.5 System Components