SRS

36
Software Proposal August, 2007 PREPARED FOR: CEO Personi Bangladesh Co. ##, Panthopath DHAKA – 1212 PREPARED BY: Raqibul Islam 507-Senpara Parbata Mirpur, Dhaka-126

Transcript of SRS

Page 1: SRS

Software Proposal

August, 2007

PREPARED FOR:CEOPersoni Bangladesh Co.##, PanthopathDHAKA – 1212

PREPARED BY:

Raqibul Islam507-Senpara ParbataMirpur, Dhaka-126

Page 2: SRS

TABLE OF CONTENTSTABLE 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 33.1.1 Methodology 33.1.2 Resource 43.1.3 Deliverables 4

3.2 System Analysis 53.2.1 Methodology 53.2.2 Resource 53.2.3 Deliverables 6

3.3 System Design 63.3.1 Methodology 63.3.2 Designing UI Forms and Reports 73.3.3 Designing Interface and Dialogues 83.3.4 Designing Data Model 83.3.5 Designing Process Model 93.3.6 Resource 93.3.7 Deliverables 9

3.4 Software Development 93.4.1 Methodology 93.4.2 Application Architecture 103.4.3 Coding Convention 113.4.4 Technology 113.4.5 Resource 113.4.6 Deliverables 11

3.5 Testing and Deployment 123.5.1 Testing Case Generation 123.5.2 Installation and Deployment 123.5.3 Quality Assurance Plan 123.5.4 Deliverables 12

3.6 Adaptation to New System 133.6.1 Business Model Transition 133.6.2 Hands-on Training 133.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.0 Copy Right and Legal Issues 21

11.0 Conclusions 21

APPENDIX A: GLADIATOR TEAM

APPENDIX B: Resume

APPENDIX C: Successful Completions

APPENDIX D: Project Gantt Chart

1

Page 3: SRS

1.1. SHORT DESCRIPTION OF THE PROJECT 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.2. PROJECT OBJECTIVES AND GOALSPROJECT 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

Page 4: SRS

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.3. TECHNICAL PROPOSALTECHNICAL 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.1 Methodology

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

Page 5: SRS

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.

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.2 Resource

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.3 Deliverables

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

Start

Draft Specification

Page 6: SRS

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.1 Methodology

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.

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

5

Page 7: SRS

3.2.2 Resource

Systems Analyst, Requirement Elicitation Team and Design Team

3.2.3 Deliverables

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.1 Methodology

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.

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

6

Page 8: SRS

will be developed from the use case descriptions along with the data requirements

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.2 Designing 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.

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

Page 9: SRS

3.3.3 Designing 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.4 Designing 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:

Fig-6 Designing Data Model

8

Page 10: SRS

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.

3.3.5 Designing 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.6 Resource

During this phase, System Analysis and Design team along with the Development team will

be partnering in the project.

3.3.7 Deliverables

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.1 Methodology

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

Page 11: SRS

3.4.2 Application 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

Fig-7 Desktop Application Architecture

Web Application Architecture

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.

Fig-9 EWUAIS Application Layout

10

The desktop application architecture

as shown in the fig. 7 shows different

layers and will be based on OOAD.

The middle tier application

framework communicates to the

application layer and the data layer is

separated from the application layer

for the data independence issues of

the application

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.

Page 12: SRS

3.4.3 Coding 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.4 Technology

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.5 Resource

During this phase, System Development team along with the Design and Testing team will

be partnering in the project.

3.4.6 Deliverables

Application Modules

11

Page 13: SRS

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.1 Test 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.2 Installation 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.3 Quality 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.4 Deliverables

The primary deliverables are test plan and the test result

12

Page 14: SRS

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.1 Business 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.2 Hands-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.3 Deliverables

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

4.4. DEVELOPMENT TEAM DEVELOPMENT TEAM

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

10.

Fig-10 Team Organisation for the SDLC

13

Project Manager

Software Engineers System Analysts

Programmers

RequirementAnalysts

RequirementModeler

Documenters Designers Quality & TestingEngineers

Page 15: SRS

Major Responsibilities

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:

14

Page 16: SRS

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

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.

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.

Fig-12 Development Team Hierarchy

Table-2: Development Team

15

System Analyst

RequirementAnalyst

RequirementModeler

Scribe

Unit co-ordinatorfrom ASF

IT Personnel fromASF

Software Engineer

Documenter Programmer Graphic Designer

Page 17: SRS

Person Name Assigned Responsibility

A.B.Siddique Software Engineer and Team

Lead

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.

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

Team Leader

Documenter Test Engineer

Page 18: SRS

5.5. FINANCIAL PROPOSALFINANCIAL PROPOSAL

A cost estimation is indicated in Table 4 below.

Table 4: Cost Estimate

Type of Cost DescriptionApprox. Cost

(Hour x Tk/hr)Total

Development

Cost

Phase 1 System Analysis &

Design

Requirement Elicitation

System Analysis

System Design

(Provision for 10 meetings)

840X250 = Tk.210000/-

224X250 = Tk.56000/-

192X250 = Tk.48000/- Tk.542000/-

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

Phase 3 Implementation and

Testing

312X250=Tk.78000/-

Training Cost Training on the usage of

EWUAIS

80 X 200 = 16000/- Tk. 16000/-

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

17

Page 19: SRS

Total = Tk.5,63,000/-

6.6. PROJECT SCHEDULE PROPOSALPROJECT 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

Requirement Elicitation

System Analysis

System Design

840

224

192

Day 1 – Day 21

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.

18

Page 20: SRS

7.7. OPERATIONAL REQUIREMENTSOPERATIONAL 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

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

Software Requirements

Operating System and necessary drivers for the scanner device

8.8. MAINTENANCE AND UPGRADE 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.9. END USER TRAININGEND 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.

19

Page 21: SRS

10.10. COPY RIGHT AND LEGAL ISSUES 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.11. CONCLUSIONSCONCLUSIONS

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.

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.

20

Page 22: SRS

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

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:

21

Page 23: SRS

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:

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.

22

Page 24: SRS

APPENDIX B: RESUME

23

Page 25: SRS

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).

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

24

Page 26: SRS

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

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.

25

Page 27: SRS

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

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:

26

Page 28: SRS

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

MedicalDiaries.com- On going

SoftExpo2004 Event Site – On Going

27

Page 29: SRS

APPENDIX D: PROJECT GANTT CHART

28