HLD Sample

This document of Cybage Software Pvt. Ltd. is for restricted circulation. No part of this publication

may be reproduced, stored in a retrieval system or transmitted in any form or by any means

recording, photocopying, electronic and mechanical, without prior written permission of Cybage

Software Pvt. Ltd.

Cybage Software Pvt. Ltd.

Document Name

High Level Design (HLD)

Version No. x.x

Release Date dd/mm/yy

Document ID SSS /// DDD EEE PPP /// 111 ... 000 /// HHH LLL DDD

QMS Ver. No: 1.0 Confidential Release Dt:

DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 2 of 34

HLD History

Ver.

No

Release

Date

Created By /

Modified By

and Date

Reviewed By

and Date

Approved By

and Date Remarks and Changes Made

x.x dd/mm/yy XY AB Initial Draft

Distribution List

Sr.

No. Name Role Organization Name

1. XY President Client

2. YY Senior VP of Technology Client

3. XX Vice President Business

Development Client

4. AB Delivery Head Cybage

5. ZZ Sr. Project Manager Cybage

6. LS Architect Cybage

7. VC Project Leader Cybage

8. RP System Analyst Cybage

9. PR Sr. Software Engineer Cybage


DD/MM/YYYY

Doc. Template Ver.


Table of Content

1 Introduction .......................................................................................................... 5

1.1 Purpose of the Document ........................................................................................................ 5

1.2 Objective of HLD ...................................................................................................................... 5

1.3 Scope of HLD ........................................................................................................................... 5

1.4 Acronyms and Definitions ........................................................................................................ 5

1.5 Reference ................................................................................................................................. 5

2 System Overview ................................................................................................. 6

2.1 System Overview ..................................................................................................................... 6

3 Design Considerations ......................................................................................... 7

3.1 Technology Consideration ....................................................................................................... 7

3.2 Identity Management ................................................................................................................ 7

3.3 Design Consideration for Development ................................................................................... 9

3.4 Single-Tenant Database vs Multi-Tenant Database .............................................................. 10

3.5 System IPR Decision Consideration ...................................................................................... 12

3.6 Rich User Interface Architecture ............................................................................................ 12

3.7 Design Consideration of Existing Application (IAS and Splendid CRM) ................................ 14

3.8 Design Consideration for the future provision ........................................................................ 14

3.9 Design should consider for partial offline model .................................................................... 15

3.10 Design Consideration of Application Performance and Scalability framework ...................... 16

3.11 Assumptions, Dependencies, and Open Issues .................................................................... 16

3.11.1 Assumption ..................................................................................................................... 16

3.11.2 Dependencies ................................................................................................................. 17

3.12 General Constraints ............................................................................................................... 17

3.13 Goals and Guidelines ............................................................................................................. 18

4 Organization of System ...................................................................................... 18

5 Architecture ........................................................................................................ 19

5.1 System Architecture ............................................................................................................... 20

5.1.1 Client Supplied Infrastructure ......................................................................................... 21

5.1.2 System Site Architecture................................................................................................. 22

5.1.3 High Level Technical Architecture .................................................................................. 23

5.1.4 System Logical Architecture ........................................................................................... 24

5.1.4.1 System Development Project Setup .......................................................................................... 24

5.1.4.2 Technologies Identified ............................................................................................................. 25

5.1.4.2.1 Exchange 2007 ..................................................................................................................... 26


DD/MM/YYYY

Doc. Template Ver.


6 Flow Diagram ..................................................................................................... 29

7 Design Limitations .............................................................................................. 29

8 Appendix ............................................................................................................ 30

8.1 Blue Whale CRM .................................................................................................................... 30

8.2 Evaluation of Sharepoint Portal Server .................................................................................. 30

8.3 Acroprint Evaluation for Time and Attendance ...................................................................... 30

8.4 High Level Design Document and their explanation for each component ............................. 31

8.4.1 Metadata Services .......................................................................................................... 31


DD/MM/YYYY

Doc. Template Ver.


Introduction

This plan will be used for managing all the High-level designs of project.

1.1 Purpose of the Document

The purpose of this plan is to

Identify different design approaches.

Identify core modules/sub-systems of the system and sub-system boundary.

Identify the best suitable technology for various sub-systems.

Identify areas that need R&D.

Identify third party components required in the system.

Identify components, state, life cycle, and communication mechanisms between different

sub-systems, and also identify the external interface.

Identify various usage scenarios.

1.2 Objective of HLD

1. To provide an overview of the entire system.

2. To provide a module-wise breakup of the entire system.

3. To provide introduction and high level working of every module involved.

1.3 Scope of HLD

This HLD covers all areas of system.

1.4 Acronyms and Definitions

This sub-section includes the definitions of all acronyms required to interpret the HLD properly.

Sr.

No. Acronyms Definitions

1.

2. RADCONTROLS TELERIK CONTROL SUITE USED FOR

3. PROPERTY PROPERTY MEANS THE PHYSICAL HOTEL.

4. CLIENT CLIENT REFERS TO USER WHO PURCHASES THIS

SYSTEM

5. COMPANY

COMPANY REFERS TO PROPERTY WHICH IS A

HOTEL. ACCOUNTING SYSTEM WORKS AT A

PROPERTY LEVEL.

1.5 Reference

This sub-section provides a complete list of all documents referenced elsewhere in the HLD with

the details of the sources from which the references can be obtained.


DD/MM/YYYY

Doc. Template Ver.


List of reference document

a. System Architecture

b. System Features

c. Splendid CRM Architecture

d. System Database Design Document

e. Splendid CRM Database Design Document

f. Microsoft Exchange white paper

g. System Exchange Presentation

h. System Back Office Discussion

i. System Architecture Discussion

j. System Architecture Session 2

k. System Reporting Discussion

l. Time and Attendance Evaluation

m. SQL Reporting Service

n. MICR Check Printing

2 System Overview

2.1 System Overview

System is accounting system build for hospitality industry to cater Accounting and Sales CRM for

small and midsize property.

System is web enabled hosting solution for hospitality industry.

System includes Accounting, Sales CRM, Hotel Operations, Payroll and MIS Reports.

System will have Back Office to manage clients, clients properties, services and clients

users.

System is business to consumer B2C product.

System will sell the product in the form of modules, user licenses by roles.

System will be Rich Internet based Application running on the client browser. This includes

Web 2.0 and Ajax.

System Clients will buy license for one or more property (hotel). Each Property will run as an

independent company to perform Accounting, Sales CRM, Hotel Operations and Payroll

modules.

To maintain System application we need to build the Back Office module which holds

information about the System client and their multiple properties and users. This back office

is used by the System Back Office User to provide support to the System Clients.

System is segment in two sections

1. System Client

2. System Back Office

a. System Admin


DD/MM/YYYY

Doc. Template Ver.


b. System Back Office Sales Agent

SYSTEM CLIENT SYSTEM BACK OFFICE

This includes the following list of modules

System Client Admin

Hotel Operation

o Sales CRM

o NA function

o GM Function

Time and Attendance

Initiate Payables

Work flow

Accounting

o GL, AR, AP etc.

o Payroll

MIS Reporting

This includes

System Back Office Admin

o Masters Management

o Agent Management

System Back Office Sales and Customer

Service

o Client Management

o Property Management

o License Management

System Back Office Operations

o Accounting

3 Design Considerations

This section refers to the decision made for building System. The supporting document to derive

the decision would be available either as a part of the appendix or as a part of the reference

section

3.1 Technology Consideration

Client Browser requirement is IE 6.0 and above.

Application must be hosted on IIS and should run in Windows Environment.

One or more Activex controls will be used in project. So while running on the client side

user is required to activate and allow running the activex controls.

Minimum Resolution required is 1024x768

We need to come up with emulator which runs on the client browser and does the require

client side setting to run our browser base application

3.2 Identity Management

User Identity : For user identity below listed parameters will be accepted through browser

user interface a. User Name: b. Email: c. Password: Alphanumeric (6 digit minimum) d. CAPTCHA: Graphic Image

System is a single sign on application to run Accounting, Sales CRM, Payroll, Hotel

Operations and MIS Reports based on user role and permission


DD/MM/YYYY

Doc. Template Ver.


When user is created in System, system should send invitation mail to user at a given

alternative email id.

Created user will have account in active directory and email will be created System

domain in MS Exchange.

We need additional function for check user availability (on the user screen)

User is authenticated against the back office database and then based on the location of

the database it gets relocated to that place.

User when logged in success full will have a. Associated property(s) (if the user created at property level) b. Associated client c. Associated connection string which is stored in back office database d. User role e. User Authorization for folders, exchange user groups f. User Permissions

User is locked means (user made an attempt for three times and could not log into

system). Supervisor will go and unlock the user.

All the places where the password is taken as an input we need to ask the CAPTCHA

image. For example when general manager is going to print payroll checks.

When the user is disabled we need the ability to transfer their mails to other users

account. This would be achieving through the request placed by supervisor user who has

the access. Either it would be a manual process or we shall run some windows service to

transfer info.

Asp.net forms authentication is used for System architecture. IAS does not have any strong

password policy and it uses plain text to store the password in the database table. We shall be

using 3DES encryption logic for password.

Authentication

method Description Examples

ASP.NET forms Identity management systems that are not based on

Windows by integrating with the ASP.NET forms

authentication system. ASP.NET authentication enables

to work with identity management systems that implement

the MembershipProvider interface. You do not need to

rewrite the security administration pages or manage

shadow Active Directory, directory service accounts.

Lightweight

Directory Access

Protocol (LDAP)

SQL database or

other database

Other ASP.NET-

based forms


DD/MM/YYYY

Doc. Template Ver.


Authentication

method Description Examples

authentication

solutions

3.3 Design Consideration for Development

System Architecture will be defined taking IAS architecture as a reference. Every module in the

System should follow System architecture for building each component of the application.

All the namespaces used in IAS will be changed in System architecture.

For example: IAS Namespace refers to Enterprise as a root name space which will be changed

to SystemEnterprise

Naming convention: As per our discussion we will keep the same naming convention that 3rd

party tool is using i.e. IAS.

Steps to Upgrade IAS to System will be manual Process which will be defined in the detail

design document when starting the development activity

Steps to Upgrade SplendidCRM to System will be manual Process which will be defined in the

detail design document when starting the development activity

Database: In System we will have separate database for each client and that client can have

multiple property whose data will be stored in the same database. a For e.g:

i. Client 1 DB [Physical database] i. Property 1 ii. Property 2

ii. Client 2 DB i. Property 1 ii. ..

iii. b Some of the benefits listed below for having separate database for each client are as

follows: i. Easy to implement ii. Meta data identifies database instance for each tenant iii. Number of tenants per database server is low iv. Able to monetize the data extension/isolation feature v. Scalable vi. Performance is better vii. Availability for the application will be 99.99 because unless the application

database fails.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 10 of 34

viii. Database performance improves as the number user hitting a database is low ix. Offisite database synch can be achieved easily

Physical Database Name for each client requires some pattern which will be defined in the back

office detail document at the time of development.

Any changes made in the System back office for the client data will require notification to the

client through email.

Windows Service will be created for making many of the background services. This process will

run for the client which is for all the properties rather than running service for each property

Some of the background process will be scheduled as a sql server job will run for each property

Supporting reports such as W-4, W-2, 1099 needs to be generated through system, so

somebody can manually write the data into actual form.

Further we will be using adobe form template then we will use other way to implement to display

form with template.

Non user access to System can be done through:

i. Acro Print / any 3

rd party tool which records timesheet: In this scenario data from 3

rd party

tool will be pushed to System indirectly and required timesheet data can be captured.

ii. Web Access: We can ask the same User Identity as stated in point 3 for access.

3.4 Single-Tenant Database vs Multi-Tenant Database

Decision taken in the favor Multi-Tenant Database

Each client will have their own physical database.

1: Single Tenant


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 11 of 34

2: Multiple Tenants


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 12 of 34

3.5 System IPR Decision Consideration

The long term future of the application is to produce some white label product which can be

available for the larger hospitality operator such as Hilton or Marriot.

The IPR valuation depends on the own application vs license application such as Sharepoint

server portal, which does not add valuation for white label products so it was not included in

the product development.

Sharepoint functionality objectives are still taken into account to achieve through

development.

Functionality Explanation

Email Email function is taken care using Exchange 2007.

Task Calendar is taken care of exchange 2007

Calendar Calendar is taken care of exchange 2007

Document Mgmt. Document management when evaluated from the SRS and it found that

documents are attached to a given process and there are hardly any

documents which are generic in nature.

These documents are process centric for example: Night auditor uploads

the document for a given specified date while closing the day of business.

Sales Contract Document is to be attached to the given opportunity or lead

and it is dynamically generated from the data

Work flow Product has certain part to have work flow that will be achieved through

windows work flow foundation

Messaging Messaging is done at client level and not across the client. Each client who

owns one or more property exchange messaging which will be taken care

in the application itself under Corporate

3.6 Rich User Interface Architecture

To achieve rich user interface which will be good, crisp graphics and looks, also should be a

ajaxified.

User look should be similar to office 2007.

Proof of concept is developed onsite in front of client and is being approved.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 13 of 34

Telerik control have been selected for creating rich user interface which will comply web 2.0

standards

o To visit the link www.telerik.com

Telerik Control suite comes with rich 18 controls

We have taken Telerik controls Q1 2007 for the base development.

In future if there are new releases from the telerik and if required to integrate then we need to

upgrade the application with new release from telerik controls.

Dashboard element is associated with defined roles

User Presentation Needs to be customized based on different verticals

Illustration purpose

o Hotel Operations

Sales CRM

GM

o Travel Verticals

Sales CRM

The application user interface will be different and their way of function would be different and

also the web section in the dashboard those would differ based on the verticals selected.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 14 of 34

3.7 Design Consideration of Existing Application (IAS and Splendid CRM)

IAS is taken as based for architecture and Quick books are taken as a reference for User

Interface and Functionality. IAS database, tables, procedures and middleware Web Service will

be taken in the development where as the user interface is going to redevelop and 80-85%

functionality will be based on quick book.

From the current IAS application we would be considering database and middleware

component. Limitation which has been discussed and will be address in the application

development

Current IAS does the data saving directly from the dataset into the datatables, and not using the

stored procedure.

For example: If we are designing the new Invoice screen it will include customer, invoice details,

bank details in one single screen while saving this records more than one table gets affected.

This will be done through using the stored procedures and these stored procedures will have

the business rule validation.

Front end component will be redeveloped to make the user experience rich and novice user can

use the system at ease. For example when the user going to create an invoice in the

accounting module, it will show the user something similar to paper invoice.

There shall be new web service methods to be added in the middleware to accomplish the new

user look and feel to achieve the new System architecture.

Splendid CRM Module is selected as a base CRM Module due to its functionality which has

been near to our requirement SRS.

Exchange Synch with CRM Database for each property should be stored different.

Contacts Synch is tied with User Roles

IAS Application and CRM Application will be merged into System architecture. System

Architecture guideline will define the merger process.

Splendid CRM database tables and procedures will be merged in to IAS database and the

middleware web services need to be developed and it should follow the same pattern as IAS

web services.

3.8 Design Consideration for the future provision

Web services developed as a part of the System will also be exposed for the interaction with

external entity


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 15 of 34

Interaction with external entity will happen only through the web services which has the

additional parameter as the login token

Any future enhancement should follow the System architecture guideline and needs to be

validated before implementing the changes

3.9 Design should consider for partial offline model

System Offline Model is a subset of the enterprise System application. System Offline is a web

enabled application running at a client machine with the local database and local IIS.

Offline application used when System main application is not reach.

System offline model would have few functions from Accounting and Payroll.

System offline database will have synch data from the central server.

When the data is changed from System offline then it will synch with central server.

Synch interval would be setting on the client side and this admin can change.

Offline model will have specific function such as payroll printing or processing at offline.

New user will not be created in case of offline model.

User will be validated from the local database against the central back office database.

User logging in the offline would not have email, connectivity.

Client side database would be SQL server express for storing the particular property

information.

Any change comes into System main application during the enhancement the changes are to

replace in the offline model.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 16 of 34

3.10 Design Consideration of Application Performance and Scalability framework

The above diagram describes the performance and scalability frame on which we will be evaluating

the effectiveness of application performance.

The details about the each parameter will be taken in the detail design document when building the

application framework.

3.11 Assumptions, Dependencies, and Open Issues

3.11.1 Assumption

System Architecture will be build taking the IAS major release and tomorrow if the architecture

of the IAS is changed in the future release still System Architecture would not be changed

For example if the IAS comes up with the change in architecture in 2008 release then we will

not change the System architecture, but will provide mechanism to integrate the functionality

Client Side Deployment for the staging and production will be done from Cybage team.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 17 of 34

3.11.2 Dependencies

Each new change coming in the future release would be aligned and would be merged into

System architecture as per the development guide line

Import and export data with other entity such as time and attendance or payroll integration.

These dependencies will be evaluated and will develop the bridges as required.

Acroprint Printer is a dependency item. If it stops entering then time will not be able to capture

3.12 General Constraints

During the development if there is a new release from the IAS or Splendid CRM with new

functionality then those will be carried out manually with the document and with approval from

client

During the development while storing the data in the CRM and storing the data in Accounting

would have different field names for the same functions which needs attention

System Development depends on Exchange which due to changes in configuration or due to

lack of service packs will not give the result as desired

Client Side environment is exclusive client responsibility so changes made in the client

environment will have some side effect which seems to be constraint

Client browser if not correctly set then System application will fail to run.

Client browser if not allowed to install active will fails to run the application especially in some

part of the application.

Some of the constraint will come for the check printing for which the printer setup requires

special attention which would require combine testing and documentation from cybage as well

as Client.

Generally popup will be avoided in the development but if there seems no alternative to achieve

the functionality then we may add the popup screen

While interacting with the exchange synchronizing the data field size might differ, this might

truncate the data.

http://msdn2.microsoft.com/en-us/library/bb508823.aspx


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 18 of 34

Some of the interop dependency might arise due to use of some of the base windows dll in the

exchange communication. This fixes need to be done as and when it arises

SQL 2005 will be upgraded to SQL 2008 only after stable release.

Any Error raise due to Service packs or any of the updates from Microsoft will not be in the

purview of Cybage. Cybage will find the fix and resolve them to the capacity of the knowledge of

the problem

Hardware configuration is not decided as of now. This decision will be taken once the

application moves to alpha version and would be nearing to beta version.

End user environment will be decided only after the development stage reaches the alpha

version but still some of the base line end-user environment are documented in the design

consideration

Verification and validation requirement needs to approve from the System for accounting

module.

3.13 Goals and Guidelines

System accounting will be developed along the guideline of quickbooks

System CRM would be developed along the guideline of splendidCRM

System Look and feel will be on the line of Office2007.

4 Organization of System

Hotel Application Architecture with Roles


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 19 of 34

Internet

CEO

CFO/COO

Investors

Partners

Bankers

Accountant

Book Keeper

Front Desk

Sales Manager

General Manager

Night Auditor

Hotel / Property

Hotel Back Office

Corporate Office

CPA

5 Architecture

The purpose of this section is to derive the initial architecture modeling which helps us achieving the below objective.

1. Improved productivity. You can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths.

2. Reduced technical risk. Your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system just because youve modeled it doesnt mean you have to build it.

3. Reduced development time. Initial architecture modeling enables you to make better cost and time estimates for your project, two pieces of information which management will want.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 20 of 34

4. Improved communication. Having a high-level architecture model helps you to communicate what you think youre going to build and how you think that youll build it, two more critical pieces of information desired by management.

5.1 System Architecture

This section provides a high level overview of how the functionalities and features of the system

were divided and then assigned to sub-systems or components.

Below diagram displays the physical architecture required to build the system when it goes live.

Based on the resource availability and client confirmation we may go for similar infrastructure for

the staging site.

This is the based proposed representation of the application to be hosted. Actual setup at the

client will be different and that can be available as per the network diagram provided by the

client.

Following are the objectives achieved with the above diagram.

a. Every user will log into the system from the same site.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 21 of 34

b. Back Office User and Sales Agent will also use the Site to login and perform

SYSTEMLIV back office operations

c. Every user in the System will have one associated active directory account

associated email address.

d. Exchange 2007 will be used for all sort of communication. Click here to read more

details Exchange 2007

5.1.1 Client Supplied Infrastructure

As per the diagram below, with the trusted segment there will be one additional box for the

application web server which runs System application.

In the internal network database would reside and will allow database access.

Big IP plays roles for load balancing and load sharing

Network infrastructure is total taken care by client and we do not need to make any changes.

We can recommend if we need some amendments.

Deployment document and setting will be made with keeping the existing client infrastructure

design


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 22 of 34

Any changes in the design would be notified from the client and we shall be making changes

in the deployment document.

5.1.2 System Site Architecture


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 23 of 34

System Site Architecture represent of how the different type of user is going to interact with System

Site and perform different activities

There are three groups of people involved who shall access the site

Type of User Login url

Back Office Admin /Admin

Back Office Sales Agent /Agent

Back Office Customer Support /Agent

System Client (Owner) /client

System Client (GM, Sales Mgr, CPA,

Financial Controller, Book keeper)

/client

Every User Who logs into the system will have see dashboard based on the role the user plays.

5.1.3 High Level Technical Architecture

System will be built on the multi-tenant SaaS model where the each client database would be

different database and would be connected based on the user and would be dynamic. The detail

technical details are as follows

Please refer to appendix for detail information


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 24 of 34

5.1.4 System Logical Architecture

Below is the System logical architecture which displays what the different projects are going to be

there to develop the complete solution and deploy on the site. This gives you higher level idea of how

the System site is going to be developed and also the different sections going to be in the

development process

5.1.4.1 System Development Project Setup

Developer Notes:

Based on the site architecture the project development structure will be as follows


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 25 of 34

System Solution

System Accounting

System CRM

System WebServices

System Accounting Webservice

System CRM Webservice

System Hotel Operation Webservice

System Back Office Webservice

System Authentication Webservice

System Payroll Webservice

System Hotel Operation

System Payroll

System BackOffice

System Reporting

System Document (this web site will take care of all the document being uploaded across all

the document)

System Plugin for Exchange for exchange connectivity

Databases

Back Office Database (one for SYSTEM which holds all the System clients)

System Databases

Accounts (tables, views, triggers, procedures)

CRM (tables, views, triggers, procedures)

Payroll (included in Accounts)

Hotel Operation (tables, views, triggers, procedures)

The above solution structure helps us achieve the below goals

Development will be independent and each individual can be assigned a sub section in the

whole solution

For integrating purpose and scalability this is more flexible

Document will be stored on the virtual path rather than the physical path this allows

independence of physical location of the document storage.

5.1.4.2 Technologies Identified

The list of the technologies used in the System Project is as follows

Functions Tools / Technologies Remarks

Web Pages ASP.NET

Language VB.NET

Development IDE Visual Studio 2005

Database SQL 2005

.net framework .NET 3.0


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 26 of 34

Version Control VSS

Diagram Visio

Documentation MS office

Third party control Telerik Controls

Unified Messaging Exchange 2007

Reporting Tool Logixml

Bug Tracking System TTPro Same as eTravelStores

Web Server IIS 6.0 with Windows 2003

Scripting Language Javascript / Vbscript

Style Sheet CSS

Add. Tech Xml based protocol exchange

Xilga tools For FAQs, Email

Analytics http://www.google.com/analytics/

IP Blocking We will use ip blocking database supplied

from client and also the interface need to

be created to configure from back office

as well as System client admin

Unit Testing NUnit

Publishing Visual Studio 2005

Code Documenting Visual Studio 2005

5.1.4.2.1 Exchange 2007

Applications that use Microsoft Exchange Server 2007 can access configuration settings and data by

using many different programming technologies. The topics in this section describe how to apply

these different technologies in Exchange 2007 collaborative applications.

Exchange Web Service Architecture for Adding Contacts, Task, Email and Calendar into exchange

from System System.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 27 of 34

The following table lists the programming technologies that you can use to access Exchange 2007

settings and data.

Programming Technology Description

Microsoft ActiveX Data

Objects (ADO)

Applications use ADO to access data in the Exchange store by using

familiar database programming techniques.

Backup and Restore The Exchange Storage Engine (ESE) manages the storage groups and

databases that Exchange 2007 uses. To support better performance

and better integration with failure recovery systems, the ESE includes

an API for backup and restore.

Collaboration Data Objects

(CDO)

The CDO group of Component Object Model (COM) objects is the

primary way that applications access and control configuration settings,

users, messages, and other information in Exchange 2007.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 28 of 34

Exchange OLE DB

(ExOLEDB) provider

Applications use the ExOLEDB provider on the local server to access

the items in the Exchange store.

Lightweight Directory

Access Protocol (LDAP)

Exchange 2007 supports the programmatic access of data at is stored

in Active Directory by using the Internet standard LDAP.

MAPI

Exchange 2007 supports e-mail and collaboration clients that use

MAPI. MAPI uses remote procedure call (RPC) networking for client-to-

server connections.

Microsoft.Exchange.Data

Managed APIs

The Microsoft.Exchange.Data namespace provides a wide variety of

types that facilitate tasks such as reading and writing Multipurpose

Internet Mail Extensions (MIME) data, converting message bodies and

other text from one encoding to another, reading and writing Transport

Neutral Encapsulation Format (TNEF) data, reading and writing

calendars and appointments, converting message formats, and

extending the transport behavior of Exchange 2007.

Schema The Exchange store holds both data items and properties that describe

the items. Designing and managing the Exchange store schema is a

significant part of creating an effective Exchange collaborative

application.

Search The Exchange 2007 content indexing and search functions support full-

text and property search queries over information in the Exchange

store.

Store Events Collaboration and workflow applications can receive automatic

notification when events occur in the Exchange store. You can register

code that will be executed when the triggering event occurs.

Volume Shadow Copy

Service (VSS)

The Volume Shadow Copy Service feature in Windows Server 2003

can be used to create applications that back up and restore Exchange

2007. VSS provides an infrastructure that enables third-party storage

management programs, business programs, and hardware providers to

cooperate in creating and managing shadow copies. Solutions that are

based on this infrastructure can use the shadow copies to back up and

restore one or more Exchange 2007 databases.

Exchange Web Services Applications that use Exchange Web Services can access data store

items. The applications can access these items locally or remotely by

using a SOAP version 1.1 or version 1.2 message.

WebDAV Remote client applications can use the WebDAV protocol to access

items and property information in the Exchange store.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 29 of 34

6 Flow Diagram

Each module in the System Solution itself is a project by itself which are termed as module. Flow

diagram of each module is available in the detail design document looking at the SRS and

reverse engineering existing application

System Module wise flow diagram displayed in each module

a. Hotel Operation

a. Sales CRM

b. Night Auditor

b. Accounts

a. Payroll

c. Back Office

7 Design Limitations

IAS accounting system and splendid CRM System needs to be backward compatible as to

support any future release and those need to be merged with existing system

Splendid CRM is developed for one company so the company identity needs to be

established in each table and also in each stored procedure

Splendid CRM is developed using two tier architecture with c-sharp as language which needs

to be fit in System architecture with vb.net as a base language

System Solution is based on already existing application bought from the market with source

code. There is likely hood of any bug or error which might cause some issue in current

System design.

Splendid CRM is developed in the two-tier architecture with database and asp.net pages. The

application is built using c-sharp where as the development platform selected for the project

is vb.net as a language

Database architecture selected for the project is multi-tenant instead of single-tenant. This

does add additional operational effort.

System architecture is hybrid solution which is mix of one or more existing solution so there is

a lot more dependency involved while migrating and creating System solution and changing

the way it is being coded

User interface should look like office 2007 and to match exactly like office 2007 might be a

challenge. Practically we can achieve the office 2007 like functionality to the extent of 80%.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 30 of 34

Splendid CRM is developed in c-sharp as language and it is built using user control

architecture.

8 Appendix

8.1 Blue Whale CRM

a. Blue Whale CRM

We are not going to Use Blue Whale CRM as a base CRM application. For some of the

functionality which refers blue whale we would be taking as defined in CRM Section of SRS.

8.2 Evaluation of Sharepoint Portal Server

Currently System is not going to use Sharepoint 2007 in their development

Client has listed down all the activities which they think would be done by SharePoint?

Client has idea that using SharePoint will make the application rich in terms of user

interface and also leverage on displaying personalization

Sharepoint is not a preferred choice is because we are not utilizing the full potential of the

application.

SharePoint will be bottle neck while creating our IPR to go to market with white label

SharePoint Licensing Issue does not provide the advantage for System to built

application based on sharepoint

8.3 Acroprint Evaluation for Time and Attendance

b. Integrating Acroprint Biometric Time and Attendance Application

Problem Answer

Where does the employee information be

entered?

a. First enter into System and then export to file

b. Import file to acroprint application and the scan

finger print info and setup

Or vice versa.

Acroprint outputs time and attendance file

which can be sent to payroll module and then

gets processing

c.

Acroprint requires some manual interaction

where ever it is installed

d.

Architecture to communicate for acroprint data

with System.

e.


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 31 of 34

8.4 High Level Design Document and their explanation for each component

The process services expose interfaces that smart clients and/or the Web presentation tier can

invoke, and kick off a synchronous workflow or long-running transaction that will invoke other

business services, which interact with the respective data stores in order to read and write business

data.

Security services are responsible for controlling access to end-user and back-end software services.

The most significant difference is the addition of metadata services, which are responsible for

managing application configuration for individual tenants.

Services and smart clients interact with the metadata services in order to retrieve information that

describes configurations and extensions that are specific to each tenant

We have not included smart client enabled application in the current scope of the development. The

design is made to address them in the future needs

8.4.1 Metadata Services

The metadata service provides customers with the primary means of customizing and configuring the

application to meet their needs. Typically, customers can make configuration changes in four broad

areas:

Workflow and business rulesTo be of use to a wide range of potential customers, a

business-critical application has to be able to accommodate differences in workflow. For

example, one customer of an invoice tracking application may require each invoice to be

approved by a manager; a second customer may require each invoice to be approved by

two managers in sequence; a third may require two managers to approve each invoice, but

allow them to work in parallel. When appropriate, customers should be able to configure the

way in which the application's workflow aligns with their business processes.

Extensions to the data modelFor many data-driven applications, one size definitely

doesn't fit all. Even with relatively simple, task-specific applications, customers may chafe

under the restrictions imposed by a static, unchanging set of data fields and tables. An

extensible data model gives customers the freedom to make an application work their way,

instead of forcing them to work its way.

Access controlTypically, each customer is responsible for creating individual accounts

for end users, and for determining which resources and functions each user should be

allowed to access. Access rights and restrictions for each user are tracked by using security

policies, which should be configurable by each tenant.

To provide customers with flexibility in configuring the software as necessary, these options are

organized into hierarchical configuration units known as scopes, each of which contains options for

making changes in each of the four areas listed above. Every customer has a top-level scope that it

can configure as needed, and the customer may establish one or more scopes underneath the top


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 32 of 34

level in an arbitrary hierarchy. A relationship strategy determines how and whether child nodes inherit

and override configuration settings from parent nodes.

For example, a typical customer that purchases enterprise-wide access to your application may have

several business units with distinct needs, all of which must follow certain company-wide standards,

but also must be able to configure some aspects of the application individually. Within each business

unit as well, there may be organizational groups that have their own special configuration needs. For

each of these identified organizational units, the customer can establish a scope that gives the group

access to the configuration options that it may set or change.

Ideally, customers should be able to configure the application through a wizard, or through simple,

intuitive screens that present all available options without causing information overload and that

clearly distinguish between options that can and cannot be changed within a given scope.

Approach Security Patterns

Extensibility

Patterns Scalability Patterns

Separate

Databases

Trusted Database

Connections

Secure Database Tables

Tenant Data Encryption

Custom Columns Single Tenant

Scaleout

Shared

Database,

Separate

Schemas

Trusted Database

Connections

Secure Database Tables


Custom Columns Tenant-Based

Horizontal

Partitioning

Shared

Database,

Shared Schema

Trusted Database

Connections

Tenant View Filter


Preallocated

Fields

Name-Value

Pairs

Tenant-Based

Horizontal

Partitioning

Comparision of the time and cost for application development using Shared Approach vs Isolated

Approach


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 33 of 34

Applications optimized for a shared approach tend to require a larger development effort than

applications designed using a more isolated approach (because of the relative complexity of

developing a shared architecture), resulting in higher initial costs. Because they can support more

tenants per server, however, their ongoing operational costs tend to be lower.

If you need to bring your application to market more quickly than a large-scale development effort

would allow, you may have to consider a more isolated approach.

Custom fields and Data Definition

Meta-data / data dictionary required

3 general approach

o Separate database for each tenant

o Shared database, a canned set of extended fields

o Shared Database, any number of extended fields

Trade off between each of the approach

Dedicated Tenant Database

1. Approach: i. Separate database for each tenant ii. Database maintains data dictionary

2. Advantages:

i. Easy to implement ii. Meta data identifies database instance for each tenant

3. Tradeoff:

i. Number of tenants per database server is low ii. Infrastructure cost of providing service rise quickly

4. When to use:

i. When tenant has data isolation requirements ii. Able to monetize the data extension/isolation feature


DD/MM/YYYY

Doc. Template Ver.

No. 1.1 Page 34 of 34

Shared Database, fixed set of extensions

1. Approach: i. All tenants data in one database. ii. Pre-defined set of custom fields

2. Advantages:

i. Easy to implement ii. Maximize number of tenants per database server

3. Tradeoff:

i. Tendency to results in sparse table ii. When to use: iii. When data co-mingling is OK iv. Easy to anticipate pre-defined custom fields

Same database, variable custom extensions

1. Approach a. All tenants in one database b. Variable number of custom fields c. Name-value pair in separate tables

2. Advantage

a. Unlimited number/option for custom fields

3. Tradeoff a. Increase index/search/query/update complexity

4. When to use

a. OK to co-mingle tenant data b. Custom fields are high value features c. Difficult to predict custom fields

HLD Sample

Documents

Transcript of HLD Sample