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 1.3.2 1.3.3 1.3.4 1.3.5

2

Company Profile .................................................................................................................................................... 8 System Description ................................................................................................................................................ 8 Project Execution ................................................................................................................................................... 8 Impact Analysis...................................................................................................................................................... 8 Concluding Remarks.............................................................................................................................................. 8

Company Profile.................................................................................................................................... 9 2.1 Brief History ........................................................................................................................ 9 2.2 Mission ................................................................................................................................ 9 2.3 Core Strategy..................................................................................................................... 10 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5

2.4 2.5 2.5.1 2.5.2 2.5.3

Talent .................................................................................................................................................................... 10 Team ..................................................................................................................................................................... 10 Talk ....................................................................................................................................................................... 11 Tech....................................................................................................................................................................... 11 Trust ...................................................................................................................................................................... 11

Development Methodology................................................................................................ 11 Core Competencies ........................................................................................................... 12 Mobile Applications............................................................................................................................................. 12 Online Payment and Banking Solution............................................................................................................... 12 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

3.3 3.4 3.5 3.5.1 3.5.2

3.6

Use Cases.............................................................................................................................................................. 15

Scope ................................................................................................................................. 15 System Architecture........................................................................................................... 16 System Components........................................................................................................... 17 Agent..................................................................................................................................................................... 17 Client..................................................................................................................................................................... 19

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 4.1.2

User Interface Narrations ..................................................................................................................................... 42 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 internationallytrained, 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 CTO

Stephen Tahjar Software Engineer

Craig Owensby CEO

Dion Software Engineer

Johan Cindra Software Engineer

Isak Rickyanto Software Engineer

Krishna W Karang Project Manager

Denymon Software Engineer

Ryan Wijaya 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 lowlevel 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

Query Application Usage

Log current activity

<>

Creat e Project MTC System

Query Idle Time

generate

MTC User

view

Report

Project Profile

<>

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

Initial Project Subdirectories

initialized by

0..*

0..*

works in

1..*

1 MTC User

1 Project Profile 1..*

0..*

has

Activities

1.. 1

1

initialized by

1..1

1 Profile Template 1

Specifies

0..*

consists of

(f rom Bu si ne ss Use -Case Mo del)

1

1

1

1

1

has

Project

An application may be used in more than one project.

0..*

Project Applications

Initial Activity Types

1

0..1

User Preferences 1..1

External Activities

Categorizes

Computer Activities utilized in 1

initialized by 1.. *

Activity Types

1..1

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

hook notifications

Agent

window messages

Windows System mtcagent.dll

process boundary

Main Window

method calls

Business Logic

method calls

mtcclient.exe

DataAccess Objects

SQL queries

Local Database

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

The mouse was moved or its buttons was pressed.

AM_MOUSE

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

ActivityMonitor

TFrmMain 1

1.. 1

1

1

MonitoringState

State_A

State_C

State_B MonitoringState1

ActivityState

ActivityContext 1

State_E

State_D

State_F

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 objectoriented 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 project_status status_id: AUTOINC

status_id: AUTOINC (FK) project_name: VARCHAR(40) description: BLOB(1,1) project_start: Timestamp project_finish: Timestamp root_folder: Alpha(18) dt_lastchanged: Timestamp

status_name: VARCHAR(40) dt_lastchanged: Timestamp

project_application application_id: AUTOINC (FK) project_id: AUTOINC (FK)

folder_exists: BOOLEAN dt_lastchanged: Timestamp

activity_name: VARCHAR(40) description: BLOB(1,1) dt_lastchanged: Timestamp

executable_file: VARCHAR(255) application_name: VARCHAR(255) description: BLOB(1,1) file_exists: BOOLEAN dt_lastchanged: Timestamp

dt_lastchanged: Alpha(18)

project_folder project_id: AUTOINC (FK) folder_name: VARCHAR(255)

project_activity_type project_id: AUTOINC (FK) activity_type_id: AUTOINC

application application_id: AUTOINC

application_project_file application_id: AUTOINC (FK) project_id: AUTOINC (FK) folder_name: VARCHAR(255) (FK) file_name: VARCHAR(255) (FK) dt_lastchanged: Alpha(18)

project_activity project_id: AUTOINC (FK) activity_id: AUTOINC activity_type_id: AUTOINC (FK) application_id: AUTOINC (FK) folder_name: VARCHAR(255) (FK) file_name: VARCHAR(255) (FK) description: BLOB(1,1) activity_start: Timestamp activity_finish: Timestamp dt_lastchanged: Timestamp

project_file project_id: AUTOINC (FK) folder_name: VARCHAR(255) (FK) file_name: VARCHAR(255) file_exists: BOOLEAN dt_lastchanged: Timestamp

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 status names are defined by the project_status table.

project_status (status_id) 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 Field Name

Type

Constraints

Description

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 Field Name

Type

Constraints

Description

application_id

Integer

Primary key and foreign key to

Specifies the application involved in the relation. 21

application (application_id) project_id

Integer

Primary key and foreign key to

Specifies the project involved in 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 Field Name

Type

Constraints

Description

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_activity_type Field Name

Type

Constraints

Description

project_id

Integer

Primary key and foreign key to

Defines the project that this 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 Field Name

Type

Constraints

Description

project_id

Integer

Primary key and foreign key to project

Defines the project that this activity belongs to.

(project_id) activity_id

Integer

Primary key

Uniquely identifies the activity

activity_type_id

Integer

Primary key and foreign key to

Defines the type of this activity.

project_activity_type (activity_type_id) application_id

folder_name

Integer

Varchar(255)

Foreign key to application (application_id)

States the current application during this activity.

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

Field Name

Type

Constraints

Description

project_id

Integer

Primary key and foreign key to project

Defines the project that 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 Field Name

Type

Constraints

Description

project_id

Integer

Primary key and foreign key to project

Defines the project that this file belongs.

(project_id) Folder_name

Varchar(255)

Primary key and foreign key to project_folder

Defines the folder that 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

Field Name

Type

Constraints

Description

Application_id

Integer

Primary key and foreign key to application (application_id)

Defines the application that this file belongs to.

project_id

Integer

Primary key and foreign key to project

Defines the project that this folder belongs.

(project_id) Folder_name

Varchar(255)

Primary key and foreign key to project_folder

Defines the folder that this file belongs.

(folder_name) 24

File_name

Varchar(255)

Primary key and foreign key to project_file (file_name)

Defines the file of the project file.

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 activity_type_id: AUTOINC template_id: INTEGER (FK)

project_template_folder folder_id: AUTOINC 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

Field Name

Type

Constraints

Description

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

Field Name

Type

Constraints

Description

project_template_id

Integer

Primary key and foreign key to project_template

Defines which project template that this folder belongs.

(project_template_id)

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

Field Name

Type

Constraints

Description

project_template_id

Integer

Primary key and foreign key to project_template

Defines which project template that this activity belongs.

(project_template_id)

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 toplevel 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

The last known currentApplication is automatically recorded as an activity

MTC Start up

application switch

Monitoring 1 no application switch for tpShortApp seconds

(B) note currentApplication

The popup dialog displays the last known currentApplication application switch no application switch for tpLongApp Monitoring (C) display seconds 2 application popup user is idle

(F) record idle time

popup dialog answered

application switch

(A) Record currentApplication

(D) record application usage activity answer popup dialog

user is idle

(E) Record last activity before going idle

tpPeriodicPopup elapsed

Monitoring 3

Monitoring Idle time (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

Monitoring 2

MonitoringState2

Monitoring 3

MonitoringState3

(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 the Current Project Directory

Create TFileWriteMonitor thread instance

Start TFileWriteMonitor thread

Initialize table of file timestamps for 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 current file being worked on

Notify the activity monitor that a file write has occurred Activity monitor notified

Generate an OnFileWrite event for each modified file 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... TFrmGenReport

Startup

Project|New...

Report|By Project

Report|By Period

TFrmNewProjectWizard

TFrmProjectMgmt Project|Edit...

TFrmMain

Manage|Projects... Settings|Preferences

Manage|Exit

TFrmEditProject

TFrmConfigDialog Manage|Preferences

shutdown

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 Project

Open the project window and chose New Project Wizard

Success

A new project was created.

Edit Project

Open the project window and double-click on a project

Success

The Project’s data was displayed, ready for editing.

Log Activity

Open the MTC main window and click on log activity.

Success

The Log Activity dialog was displayed.

Hibernate Computer

Start MTC in debugging mode. Use other applications for a while and then hibernate the computer.

Success

The activity monitoring engine moved to State_A just before the computer hibernates.

Generate Report

Open the project window then choose Report|By Project...

Success

The project report is 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 subphases, 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 subphase was to implement the rest of the functionalities while continuing the testing of the system. ID 1

Task Name Design/Planning

2

Requirements Specification

3

System Architecture Plan

4 5

W

Feb 3, '02 S T M

F

Feb 17, '02 T S W

Mar 3, '02 S T M

F

Mar 17, '02 T S W

Mar 31, '02 S T M

F

Apr 14, '02 T S

W

Apr 28, '02 S T M

F

May 12, '02 T S W

May 26, '02 S T M

Ju F

Evaluate System Architecture 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-ofsite. 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.

ID 1

Task Name 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

35

System Description

36

Source Code Documentation

37

Code File Monitoring component

38

Integrate File Monitoring component

39

System Description

40

Debugging

41

Testing

6, '02 T

S

Feb 3, '02 W S

Mar 3, '02 T M

F

Mar 31, '02 T S

Apr 28, '02 W S T

May 26, '02 M F

Jun 23, '02 T S W

Jul 21, '02 S T

M

Aug 18, '02 F T

Sep 15, '02 S W

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 quickstart 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