Software Proposal

August, 2007

PREPARED FOR:
CEO
Personi Bangladesh Co.
##, Panthopath
DHAKA – 1212

PREPARED BY:

Raqibul Islam
507-Senpara Parbata
Mirpur, Dhaka-126
 TABLE OF CONTENTS
1.0 Short Description of the Project 2
2.0 Project Objectives and Goals 2
3.0 Technical Proposal 3
3.1 Requirements Elicitation 3
3.1.1 Methodology 3
3.1.2 Resource 4
3.1.3 Deliverables 4
3.2 System Analysis 5
3.2.1 Methodology 5
3.2.2 Resource 5
3.2.3 Deliverables 6
3.3 System Design 6
3.3.1 Methodology 6
3.3.2 Designing UI Forms and Reports 7
3.3.3 Designing Interface and Dialogues 8
3.3.4 Designing Data Model 8
3.3.5 Designing Process Model 9
3.3.6 Resource 9
3.3.7 Deliverables 9
3.4 Software Development 9
3.4.1 Methodology 9
3.4.2 Application Architecture 10
3.4.3 Coding Convention 11
3.4.4 Technology 11
3.4.5 Resource 11
3.4.6 Deliverables 11
3.5 Testing and Deployment 12
3.5.1 Testing Case Generation 12
3.5.2 Installation and Deployment 12
3.5.3 Quality Assurance Plan 12
3.5.4 Deliverables 12
3.6 Adaptation to New System 13
3.6.1 Business Model Transition 13
3.6.2 Hands-on Training 13
3.6.3 Deliverables 13
4.0 Development Team 14
5.0 Financial Proposal 18
6.0 Project Schedule Proposal 19
7.0 Operational Requirements 20
8.0 Maintenance and Upgrade 20
9.0 End User Training 20
10.0Copy Right and Legal Issues 21
11.0Conclusions 21
APPENDIX A: GLADIATOR TEAM
APPENDIX B: Resume
APPENDIX C: Successful Completions
APPENDIX D: Project Gantt Chart

1
1. SHORT DESCRIPTION OF THE PROJECT

Proprietor

Personi Bangladesh Co. (PBC) is one of the leading cosmetic item importer of international brand
Perosni ®
and huge amount of other brand cosmetic products. It also purchases fashion item from
local market as secondary business. They sell their products through the company owned show
rooms and local market.

Each and every day there are numbers of transaction going on through PBC’s account section.
Account maintaining a system for this purpose from the beginning. But as the business increases
Accounts facing some problem and the company wants a software for the account section in view
to reliable and faster transaction.

The PBC’s stock deals with lots of products that are in or out from the stockpile. Currently the
company has paper based manual system, which has no accountability and very difficult to
monitor. The company wants a computer-based automatic system to monitor the stock.

The company management make decision based on imaginary information collected by oral
conversation. The management feels for statistical report in this area.

As Personi Bangladesh Ltd is growing fast they need speed all possible sector in the company with
the help of information technology. Intelligent Technology understood their thirst and will to provide
solution to meet up their needs.

Intelligent Technology is going to develop a software system which will be a multi-user system
based on windows that utilise Visual basic, PHP and MySQL technology would be needed for cost
effectiveness. The proposed system should leave scope for the future modifications, expansion
and transfer of data.

2. PROJECT OBJECTIVES AND GOALS

A. Objectives
Acid Survivors Management System intends to meet the following objectives:
(1) Create interactive and effective desktop application modules
(2) Create web application module
(3) Create necessary security and custom features
(4) Provide simple, intuitive and user friendly GUI
(5) Provide necessary administrative support for both desktop and web applications

2
 B. Major Functions
Acid Survivors Management System intends to provide the followings:
(1) Effective data management on the desktop application module
(2) Flexible reporting and query
(3) Authorisation and processing
(4) Data exchange and export options
(5) Data security and backup

3. TECHNICAL PROPOSAL

Software Development Life Cycle plays a critical role in the development of a new system and
GLADIATOR TEAM is planning to incorporate standard procedures to keep track of the project.

3.1 REQUIREMENT ELICITATION

The first life cycle activity is the requirement elicitation that helps to determine what information and
information processing services are needed to support selected objectives and functions of the
EWU. During this process, the requirements gathering team would attempt to discover important
information about how different responsibilities are performed at EWU at the current scenario and
how EWU would need to perform their job in order to meet future business conditions.

A study of the current operations would be carried out by the requirements elicitation team and the
results of the requirements determination would be structured as follows:

• Process – the sequence of data movement and handling operations within the system
• Logic and timing – the rule by which data are transformed and manipulated and an
indication of what triggers data transformation
• Data – the inherence structure of data independent of how or when it is processed

3.1.1Methodology
Joint Application Design (JAD) methodology will be used as part of the elicitation. The Users,
Managers, and system developers will be brought together within the timeframe of the phase
for a series of intensive structured meetings to identify the system requirements and design
details.

JAD sessions will be conducted at EWU under the direction of JAD session leader. The group
engaged from EWU to take part in the JAD should cover the broad outline of the EWUAIS.
The session will be conducted as shown in figure 1.

The JAD group will be formed according to the module of EWUAIS and the group will be
interacting from the perspective of the proposed system. The group will be always lead by the

3
 session leader and will share ideas and opinions on the requirements of the application
module within the system. The identified requirements will be analysed and a draft
specification will be prepared. This draft specification will be further reviewed and finalised for
the module of the proposed system. During the meeting minutes will be taken by the scribe
proposed by either party. This process will be carried out for all the application modules.

Start

Identify Groups for the Module

Share Ideas and Opinions [TOR]

Analyze Requirements

Generate Specification Review the Specs

Draft Specification

Fig-1 Requirements Elicitation Process

All the draft specification of different modules will be consolidated and intra-module interaction will
be identified by the JAD and final activity model will be drafted.

3.1.2Resource
During this phase, there is involvement of different resources from either party and they are as
follows:

• Requirement Elicitation team from GLADIATOR TEAM

• Unit Managers and IS people from EWU
• Meeting arrangements

3.1.3Deliverables
The primary deliverables from requirements determination are as follows:

• Transcript of Interviews
• Notes from observations and analysis of documents
• Sets of forms, reports
• Activity diagram
• Software Requirement Specification (SRS)

4
3.2 SYSTEM ANALYSIS

This phase immediately follows the requirement elicitation phase and starts with the software
requirement specification generated by the requirement elicitation phase. The next process follows
are requirements structuring and strategies for the subsequent system design.

3.2.1Methodology
SRS of EWU will be analysed to create Process and Logic Model and Conceptual Data Model.

In the Process and Logic Model, graphical symbol will be used to represent the functions, or
processes, which capture, manipulate, store and distribute data between a system and its
environment and between components within a system. During the process and logic-
modelling phase, processing elements of EWUAIS will be identified together with the
transformation of the data and the processing logic along with the timing of the event and the
structure of data within the system.

In the Conceptual Data Model, graphical representation will be used for the EWU data
requirements. During the data-modelling phase, EWU business rules will be identified along
with the inter-relationships among the data for different units of EWU. The constraints will be
identified for intra-module relationships and will be mapped into the data model. Both the
methodologies are shown in figure 2 and figure 3.

Identify Source and Sink Indentify Entity

Identify Process Identify Attributes

Identify Data Flow Identify Relationships

Link to Data Store Identify Degree and Constraints

Fig-2 Process and Logic Modelling Fig-3 Data Modelling

5
 3.2.2Resource
Systems Analyst, Requirement Elicitation Team and Design Team

3.2.3Deliverables
The deliverable from the system analysis phase are as follows:

• Context Data Flow Diagram (DFD)

• Level-0 DFD
• Description of each DFD components
• E-R Model

3.3 SYSTEM DESIGN

System Design phase will blend the outcome of the requirements elicitation and analysis phase of
the EWUAIS. This phase will elaborate system design methodology in relation to system analysis.

The popular system design methodologies are Object-Oriented Analysis and Design (OOAD) and
Rapid Application Development (RAD). Both OOAD and RAD draw on principles fundamental to
all systems analysis and design approaches. OOAD truly blends analysis with design through the
evolution of techniques but RAD is more of a general strategy of developing information systems.

3.3.1Methodology
Considering the challenging domain requirements, an easy expansion of the future system,
increased internal consistency across analysis, design and programming activities,
GLADIATOR TEAM will use OOAD as the methodology for the EWUAIS design and
implementation. The methodology is shown in the figure 4.

* Map Requirements
* Use Case Diagram
* Use Case Description * Capture Domain Model
* Class Diagram
* Sequence Diagram

USE CASE MODEL STATIC MODEL DYNAMIC MODEL

Deployment Model Component Model

* Network Diagram

* Package Diagram

Fig-4 OOAD based on UML

As shown in figure 4, the SRS and the activity models will be used to generate Use Case
models to comply with the OOAD methodology. Use case modelling will be comprised of
Use Case diagram and description of each use case in standard template. The static
model will be developed from the use case descriptions along with the data requirements

6
 elaboration in E-R model. The static model will be comprised of class diagram. Further
iteration will be used for the conformity of the static model with the use cases.

The dynamic model will be developed from the static model to capture business logic
requirements associated with the static model. The component model will be realised from
the context of the business processing and association of the static model. The
deployment model will be developed from the application environment at EWU.

3.3.2Designing UI Forms and Reports

Designing UI forms and Reports is a user-focused activity that typically follows a
prototyping approach.

System inputs and outputs – user interface forms and reports – will be identified during
requirements structuring in system analysis phase. During analysis phase, prototypes of
forms and reports will be developed based on DFD which would comply with the
requirement of the data flow to the data store and at the same time with the conceptual
framework of the data model, ERD as shown in the figure 5 below.

Data Flow Diagram ERD

Static Model

Prototype UI Forms and

Reports

Failed Usability Test

Review
Prototype

Qualified Test

Accepted UI Form
and Report

Fig-5 Designing UI Forms and Reports

Prototype of UI forms and reports will be reviewed by EWU and if changes are needed,
construction-evaluate-refinement cycle will be repeated until the design is accepted. All the
designs of UI form and report will be verified by EWU and will be assessed for the usability
test based on speed, accuracy and satisfaction. Usability will be measured based on time
to learn and speed of performance.

7
3.3.3Designing Interface and Dialogues
The designing of interface and dialogue is a user-focused activity. Interface design focuses
on how information is provided to and captured from users and Dialogue design focuses on
the sequencing of interface displays.

During the design process of the user interface, the interaction method will be chosen
carefully to maximise human-computer interaction issues. During the analysis phase of the
project, user-activities will be grouped together and will be structured as the standard
windows convention to create useful menu interaction. The menu design will guide the end
user for specific task. Menu hierarchies will be created not more than one sub-menu
options. All the short cuts defined for the menu options will be chosen based on the
common windows convention and will be consistent throughout the entire application. The
hot-keys will be assigned wherever required using the same convention. Icon graphics will
be used for the quick access to task identified during the structuring of the requirements.

UI Forms will have all the fields self-explanatory and will follow the natural order of the
printed entry forms. The navigation sequence will be according to the printed forms and
reports for the efficient keying in of the data. The data entry field will provide sufficient
validation of data at the level of forms to reduce data anomalies. The default values along
with necessary customisation of the entry field will be finalised during the analysis phase of
the project. The navigation procedure will be flexible and consistent throughout the entire
system and across the system. Besides providing feedback, status information, prompting
cues, providing help, error, and warning messages will be incorporated.

3.3.4Designing Logical Data Model

Logical data modelling has three purposes. First, in logical data modelling, normalisation
process will be used for the desirable property of the data model. The second purpose of
the logical data model will be to create a smooth transition from logical to physical
database design based on a data model. The final purpose of logical data modelling is to
develop a data model that reflects the actual data requirements based on forms and
reports of EWU. The following figure 6 shows the logical data modelling steps:

Compare Both the Model

Develop Logical Data Model for each form and report
and create one final
using Normalization Principle
Logical Data Model

Combine all Normalized user views into One Logical

Translate conceptual ERD
Data Model
into Normalized Relations
(VIEW INTEGRATION)

Fig-6 Designing Data Model

The Relational data model will be used for the logical database design. This phase will
identify keys, mapping cardinalities besides the refinement of the conceptual data model.

8
 3.3.5Designing the Process Model
During this phase, data flow diagrams will be converted into structure charts. Structure
charts graphically represent system design. This structure chart will form the basis for the
structure of the system.

3.3.6Resource
During this phase, System Analysis and Design team along with the Development team
will be partnering in the project.

3.3.7Deliverables
The major deliverables at this phase are:

• UML Models
• User Interface Layouts
• Report Layouts
• Custom Interface Design Layout
• GUI Model
• Physical Data Model

3.4 SOFTWARE DEVELOPMENT

Software Development phases will be co-ordinated with the requirements elicitation and
structuring process. This phase will transform the requirements into meaningful abstraction
through the data structure, algorithm and coding of the business processes.

3.4.1Methodology
The software development methodology will be evolved around a framework that would
support the application architecture. This framework will be developed during the analysis
phase, which would be reusable design part of the system represented by a set of abstract
classes. This would lead to highest reusability of the design and implementation. The
development methodology will be governed by the following for the performance reasons:

• Modularity of the design

• Reusability of the design
• Extensibility
• Inversion of control
• Process adaptation

9
3.4.2Application Architecture
The proposed system for EWUAIS will follow n-tier application architecture for the web
along with the desktop application needs as shown in figure 7 and figure 8.

Desktop Application Architecture The desktop application architecture as

shown in the fig. 7 shows different
Win32 Visual Basic Env
layers and will be based on OOAD. The

Application Framework
middle tier application framework
communicates to the application layer
Application Module and the data layer is separated from the
application layer for the data
Data Layer independence issues of the application
Data

Fig-7 Desktop Application Architecture

Web Application Architecture The web application architecture is shown in the

figure 8. Both the desktop and web application
module will share the same data repository for the
consistent representation of the ASMS within the
organization and throughout the application. The
web server-side processing will be clustered into
application framework and the library shown in the
figure will be common to all the web application
modules. The common data security through user
validation will be used and authorization will be
controlled using desktop modules.

Fig-8 Web Application Architecture

The overall EWUAIS application based on the above architecture shown in the figure 7
and 8 is shown in the figure 9 below.

WEB DESKTOP
Modules Modules

WWW Server DB Server

WWW Users ASF Intranet
ASMS
Data
Store

Fig-9 EWUAIS Application Layout

10
3.4.3Coding Conventions
Industry standard coding conventions will be followed which depends on the
comprehension of the software system. The coding convention will be elaborated from the
code maintenance point of view. Good coding techniques will be followed. The coding
conventions are divided into three distinct sections:

Names – The naming scheme is one of the most influential aids to understanding the
logical flow of an application. A name should tell “what” rather than “how” and should be
long enough to be meaningful.

• Class Name – Name starts with capital letter and for every new word, the first
character is represented using capital letter.
• Method Name – Name starts with small letter and for every new word, the first
character is represented using capital letter.
Variables - The variables are named according to the followings:
• Appending computation qualifiers (Avg, Sum, Min, Max etc) to the end of a
variable name where appropriate
• Boolean variables is named using Is which implies Yes/No or True/False values
such as checkIsFound
Comments – Comments will be followed for all the internal logic and flow. During any
updates of codes, date and time stamp will be preserved for the version control purpose.

3.4.4Technology
For Desktop Application Modules:

• Front-end Tool: Microsoft Developer 2000 (MS VisualBasic 6.0)

• Report Tool: ActiveReport
• Backend: MySQL
For Web Application Modules:
• Front-end Tool: PHP and JavaScript
• Report Tool: HTML and JavaScript
• Backend: MySQL

3.4.5Resource
During this phase, System Development team along with the Design and Testing team will
be partnering in the project.

3.4.6Deliverables
Application Modules

11
3.5 TESTING AND DEPLOYMENT

Testing and Deployment phase will finalize the SDLC life cycle and the target solution will be taken
for the dry run. This phase will carry out functional test of different application modules and
processes based on functional specification.

3.5.1Test Case Generation

A functional specification often describes the external view of an object or a procedure
indicating the options by which a service could be invoked. The testers will use this to write
down test cases from a black box testing perspective.

The functional specification will be used so that the test generation activity could happen in
parallel with the development of the code. This is ideal from several dimensions. Firstly, it
gains parallelism in execution, removing a serious serialization bottleneck in the
development process. By the time the software code is ready, the test cases are also ready
to be run against the code. Secondly, it forces a degree of clarity from the perspective of a
designer and an architect, so essential for the overall efficiencies of development. Thirdly,
the functional specifications become documentation that can be shared with the customers
to gain an additional perspective on what is being developed.

3.5.2Installation and Deployment

The EWUAIS solution will be configured and necessary transformation will be made from
existing data model to the solution platform. The necessary prerequisite condition will be
meet and EWUAIS will be installed in the designated servers of the AFS and will be tested
with the data.

3.5.3Quality Assurance Plan

The purpose of this Software Quality Assurance Plan (SQAP) is to define the techniques,
procedures, and methodologies that will be used at GLADIATOR TEAM to assure timely
delivery of the software that meets specified requirements within project resources.

As part of the QAP, all the analysis, design, development and coding works within the
scope of the project will be reviewed, reported and audited. Audits will occur at the end of
each development phase. Audit reports contain the recommended actions for correction or
improvement. Copies of scheduled and unscheduled audits and reviews will be kept by
EWU and GLADIATOR TEAM.

3.5.4Deliverables
The primary deliverables are test plan and the test result

12
3.6 ADAPTATION TO NEW SYSTEM

Design and implementation of EWUAIS would bring changes in the business process of the EWU
and perhaps new role would be required with new responsibility. This change adaptation is
important to utilise EWUAIS to its full throttle.

3.6.1Business Model Transition

The new EWUAIS will lead to a new business process model based on which EWUAIS
would interact and exchange within different units of the EWU. The change that has
occurred during the evolution of EWUAIS would be traced back and will be used as the
guideline for the new business model within EWU.

3.6.2Hands-on Training
The changes in the business model due to the evolution of EWUAIS will be identified and
there will be training on the adaptation of the new process within the framework of EWU.

3.6.3Deliverables
The deliverables at this phase are documentation based on change management.

4. DEVELOPMENT TEAM

The GLADIATOR TEAM project team consist full members to support SDLC as shown in the figure
10.

Project Manager

Software Engineers System Analysts

Requirement Requirement
Analysts Modeler

Programmers Documenters Designers Quality & Testing

Engineers

Fig-10 Team Organisation for the SDLC

Major Responsibilities

13
• Project Manager
- Guide the team in the right direction
- Manage Technical and Financial aspects of the project
- Manage staff mobilisation
- Co-ordinate with EWU and the development team
- Ensure continuous monitoring, quality control, general supervision and quality output.
- Ensure just-in-time delivery of the deliverables.
• Software Engineer/System Analyst
- Build/discover business cases
- Module Prototyping
- Develop design/technical documentation
- Supervise documentation activities
- Lead and co-ordination the developers team
- Reporting to the project manager
• Requirement Analysts
- Co-ordinate with the EWU and the EWU IT department to collect the requirements.
- review the use cases of the software
• Requirement Modeller
- Build-up system activity model
- Develop Structure charts
- Develop use cases
- Develop data flow diagrams
• Quality & Testing Engineer
- Unit Testing
- Process Testing
- Ensure the fulfilment of operations in the business cases.
• Programmer
- Write codes as per the specifications outlined by the Software Engineer
- Follow coding conventions
• Documenter
- Produce design documentation as well as software manual on how to use the software.
- Follow specified templates.

• Graphic Designer
- design interface, GIF, animation for the software.

Development Team:

Project Manager : Syed Akhter Hossain

Analysis and Design Team:

The analysis and design team shown in the figure 11 will collect the requirements from
EWU and build up test cases and software model that would be the basis of the software

14
development. In this phase, the analysts team from GLADIATOR TEAM would jointly work
with unit co-ordinator and IT personnel from EWU to collect the requirement for a better
understanding of the domain matter.

System Analyst

Requirement Requirement IT Personnel from Unit co-ordinator

Analyst Modeler ASF from ASF

Scribe

Fig-11 Analysis and Design Team Hierarchy

The assigned members of the team and the responsibility is shown in the table-1.

Table –1: Analysis Team

Person Name Assigned Responsibility

Raqibul Hasan System Analyst

Sumon Requirement Analyst

Rasel Requirement Analyst

Robin Requirement Modeler

Development Team:

The Development team shown in the figure 12 would implement the software model as
designed by the analysts team. In this phase, the work of writing codes, designing graphics
will be done.

Software Engineer

Documenter Programmer Graphic Designer

Fig-12 Development Team Hierarchy

Table-2: Development Team

Person Name Assigned Responsibility

A.B.Siddique Software Engineer and Team

Lead

15
 Robin Documenter

Shumon Designer & Documenter

Raqibul Hasan Designer & Programmer

Rasel Programmer

Testing Team

The Testing Team would ensure that the software deliverables confront to the requirements
and standard quality is maintained.

Team Leader

Documenter Test Engineer

Fig-13 Testing Team Hierarchy

Table-3: Testing Team

Person Name Assigned Responsibility

A.B.Siddique Team Leader

Sumon Testing Engineer

Robin Testing Engineer

16
5. FINANCIAL PROPOSAL

A cost estimation is indicated in Table 4 below.

Table 4: Cost Estimate

Approx. Cost
Type of Cost Description Total
(Hour x Tk/hr)
Development Phase 1 System Analysis &
Cost Design

• Requirement Elicitation 840X250 = Tk.210000/-

• System Analysis 224X250 = Tk.56000/-

192X250 = Tk.48000/-
• System Design Tk.542000/-

(Provision for 10 meetings)

Phase 2 Software development 600X250=Tk.150000/-

Phase 3 Implementation and 312X250=Tk.78000/-

Testing

Training Cost Training on the usage of 80 X 200 = 16000/- Tk. 16000/-

EWUAIS

Miscellaneous Documentation, Manual, CD 1 X 5000 = 5,000/- Tk. 5,000/-

etc

Total = Tk.5,63,000/-

17
6. PROJECT SCHEDULE PROPOSAL

GLADIATORTEAM@EWU ensures the compliance with the proposed deadline.

The expected time frame (schedule) associated with the project is indicated in Table 5 below.

Table 5: Project Schedule

Description Man Hours Duration

Phase 1 System Analysis & Design Day 1 – Day 21

• Requirement Elicitation 840

• System Analysis 224

192
• System Design

Phase 2 Software development 600 Day 22 – Day 41

Phase 3 Implementation and Testing 312 Day 42 – Day 62

TOTAL 2168 62 Days

All these days indicate the working days and the Day 1 stands from the day of acceptance of this
proposal and issuing of work order.

Please see the attached Gantt Chart for the detailed breakdown of the workflow in Appendix-D.

7. OPERATIONAL REQUIREMENTS

Before the installation of EWUAIS, site preparation will be completed and EWUAIS will be
installed in the designated workstations of the EWU. The necessary hardware and application
support software will be provided by EWU to GLADIATOR TEAM.

Hardware Requirements

• LAN settings with the PC equipped with the image acquisition device like scanner

18
 • RAM: 512MB for the server, AGP:32MB

Software Requirements

• Operating System and necessary drivers for the scanner device

8. MAINTENANCE AND UPGRADE

GLADIATOR TEAM will provide maintenance service pas per the contract and all the future
upgrade of both the desktop module as well as the web application module will be under the
maintenance agreement of the GLADIATOR TEAM.

9. END USER TRAINING

GLADIATOR TEAM will provide necessary training to the EWU people and the end user for the
effective utilisation of EWUAIS in the business model of EWU. The training needs will be
identified during the analysis phase of the project. GLADIATOR TEAM will provide User Manual,
which would be used as one of the guideline during the training session. The no of days required
for the training will be finalised later and according to the financial proposal, roughly 20hours of
training time is estimated for EWUAIS end users.

10.COPY
10.COPY RIGHT AND LEGAL ISSUES

GLADIATOR TEAM would hand over all the codes to EWU but EWU will not redistribute or use
existing code in any form in other similar nature of work without prior permission from GLADIATOR
TEAM.

11.CONCLUSIONS
11.CONCLUSIONS

GLADIATOR TEAM would like to thanks EWU for the opportunity given to present this proposal for
consideration. GLADIATOR TEAM also hope that the above-mentioned proposal would be
acceptable to the EWU board and look forward for a healthy relationship.

19
Please do not hesitate to contact either A.B.Siddique , Student of CSE, Dept of CSE and Project
Manager, GLADIATOR TEAM (mobile – 01199025738) or Md. Raqibul Islam, Student of CSE,
Dept of CSE and, GLADIATOR TEAM (mobile – 01915604490) for any further information and
clarification.

APPENDIX A: GLADIATOR TEAM

GLADIATOR TEAM since its establishment in 2006 at East West University to support research
and development holds it mission to provide EWU students with real-world experience in
designing and developing quality software for business organisations.

GLADIATOR TEAM believes in quality as the first principal both in software development and in
training and mentoring.

GLADIATOR TEAM at the university intends to act as the bridge between the software industry
and the academia and is dedicated to synthesise the demand of the industry with the technology

20
based society by cultivating the software development, mentoring and practising the software
engineering principles.

GLADIATOR TEAM believes in long-term consistent and continual development in the promotion
of business activities. Besides delivering effective and time managed software solutions at a
competitive cost, GLADIATOR TEAM intends to provide mentoring and training to produce
professionals at an affordable cost. The business growth is the prime objective of the GLADIATOR
TEAM in order to extend the services to a large segment of the society as well as create human
resource, create employment, which in turn brings revenue to the GLADIATOR TEAM to be of
good size.

The center has established the following goals to fulfil its mission:

♦ Meet the custom software needs of the local market

♦ Build the software development expertise of the local market
♦ Provide professional development experiences for EWU students

GLADIATOR TEAM will pursue the following critical strategies:

• Build software projects based on custom needs

• Accelerate software product/services development by strengthening RND team
• Extend links with national and international key technology center
• Seek new market segments/applications for software products/services
• Industry attachment with the GLADIATOR TEAM

What we offer:

• eCommerce and Internet Services:

GLADIATOR TEAM delivers end-to-end eCommerce and Internet solutions which includes intranet
and extranet strategy, security consulting and audits, development of intranet and extranet
applications, Web site and content development, content management solutions, Web hosting and
ASP services. GLADIATOR TEAM in future intends to have alliances with the leaders in the web
industry.

• Supply Chain Management:

GLADIATOR TEAM solutions help clients gain a competitive edge and enhance customer value by
synchronising the management of the flow of physical goods and associated information from
souring through consumption. The solutions include reengineering of demand management and
other management process.

• Customer Relationship Management:

21
GLADIATOR TEAM services span the reengineering of customer-centric processes and the
design, development, implementation and maintenance of packaged solutions as well as the
automation of the processes.

• Custom Application Development:

GLADIATOR TEAM ensures proven software development methodology and quality management
system which shorten application development time frames and provide significant business
benefits to our customers.

• Application Maintenance:

GLADIATOR TEAM incorporates mature application maintenance approach which includes three
inter-linked processes – adaptive maintenance, preventive maintenance, and corrective
maintenance.

APPENDIX B: RESUME

22
 APPENDIX C: SUCCESSFUL COMPLETIONS

East West University

GLADIATOR TEAM (GLADIATOR TEAM), owned by East West University, has been contributing
for the development of the university in computerisation of its various academic and non-
academic matters.

1. University Management Information System (UMIS).

23
 Platform: Windows 9x/NT.
Tools Used: Visual Basic, SQL Server / Oracle.
Reporting Tool : Active Reports
Purpose:
♦ Student Information Management.
♦ Grade Tabulation and Processing.
♦ UMIS Administrative Processing.
♦ Online Course Advising and Add/Drop/Withdraw.
♦ All sorts of reporting facility.

2. Course Instruction Evaluation System

Platform: Windows 9x/NT.
Model: Standalone.
Tools Used: Visual Basic, MS Access, ActiveX, Crystal Reports.
Purpose:
♦ Semester end student feedback processing.
♦ Grading the course instruction.
♦ All sorts of related reports.

3. Human Resource Management System

Platform: Windows 9x/NT.
Model: Standalone.
Tools Used: Visual Basic, MS Access, ActiveX.
Reporting Tool : Active Reports
Purpose:
♦ Manage annual leave of the employees.
♦ Track the increments.
♦ Relevant report options.

4. Online Room Scheduling And Booking System

Platform: Windows 2000 Advanced Server
Model: Web Application (Java Servlet).
Web Server: Apache, Apache Jserv
Tools Used: Sun JDK1.3, JSDK2.0
Purpose:
o Check Teacher and Room Schedule
o Find available room number in available time
o Room Booking.

5. EWU Bulletin Board

Platform: Windows 2000 Advanced Server

24
 Model: Web Application (ASP)
Web Server: IIS
Tools Used: VBScript
Purpose:
o Paperless communication
o Effective communication

6. EWU Dynamic Web Portal ( www.ewubd.edu )

Platform: Linux
Model: Web Application
Web Server: Apache
Tools Used: PHP
Purpose:
o Administrative Information
o Course Information
o Admission Information
o Academic Calendar
o Events

7. EWU Library MIS

Platform: Windows/NT
Model: Client/Server, Web Application
Web Server: Apache.
Tools Used: Visual Basic, Java Servlet, MSSQL Server.
Purpose:
o Library Information
o Booking, Issue and Requisition
o Use of Barcode

Document And Resource Center, Ministry of Women And Children Affairs

1. DRC Office
Platform: Windows 9x/NT.
Model: Standalone.
Tools Used: Visual Basic, MS Access..
Reporting Tool: Active Reports
Purpose:
♦ Storing client information.
♦ Relevant report options.

HSBC Bank

25
 1. Automation of Export and Import (EIA)
Platform: Windows 9x/NT.
Model: Standalone.
Tools Used: Visual Basic, MS Access / SQL Server
Reporting Tool : Active Reports
Purpose:
♦ Uploading Export and Import data from external files.
♦ Generate reports for Bangladesh Bank.

2. Collection MIS (CMIS)

Platform: Windows 9x/NT.
Model: Network / Multi-user.
Tools Used: Visual Basic, MSSQL Server 2000
Reporting Tool : Active Reports
Purpose:
♦ A customisable solution to import and export register automation.
♦ Generate reports for Bangladesh Bank.

3.DC Archive
Platform: Windows 9x/NT.
Model: Multi-user.
Tools Used: Visual Basic, MS Access
Reporting Tool : Active Reports
Purpose:
♦ A customisable solution to tag Exp DC with Back to Back LC information
♦ Generate reports ( Monitoring Sheet , Bill Information etc.)

3.SPMIS – Shanchai Patra Management Information System

Platform: Windows 9x/NT.
Model: Multi-user.
Tools Used: Visual Basic, MS Access
Reporting Tool : Active Reports
Purpose:
♦ A customisable solution of Shanchai Patra Management System
♦ Generate reports for Bangladesh Bank and internal purpose

On Going Projects

♦ EWU Asset Management – Test Run

♦ Human Resource Information System – HSBC –On Going

26
♦ MedicalDiaries.com- On going
♦ SoftExpo2004 Event Site – On Going

APPENDIX D: PROJECT GANTT CHART

27