Client Layer
The Client Layer consists of, typically, a thin client that is browser running on a user’s desktop.
The Client’s communication to the Application Server processes, residing on Tier 2 is through
HTTP.
Application Server Tier
Application server tier would host the Web Logic application server.
Web Controller
A gateway servlet is deployed to listen to all client requests. Servlets listen for HTTP requests
and hands over the control to appropriate Application Controller. The listener removes all the
HTTP specific details from the request and passes only the event details to the application
controller. Typically, there is only one controller for an application.
Application Controller
The application controller gives a business event view for the Client listeners and on the other
side, translates them into application events. Business components are designed as small
loosely coupled and cohesive components. The controller maps an incoming business event
into one or many application events. Application controllers are normal Java Classes and they
help in navigation between business components. The main responsibilities of the Application
Controller are:
• Validate if the request can be processed
• Identify the Event Processor for incoming request
• Pass on the event specific details to the Event Processor
Event Handlers
This component implements the logic to navigate between different business components to
meet the business event. These Java classes make one or more method call to Business
Interface to process the event. The main responsibilities of Event-Processors are:
• Breaks application event into specific business interface method calls handling various units
to maintain the integrity
• Makes business method calls with the appropriate parameter
• Handles Errors
• Summarizes the responses from the various methods calls to be passed on as the response
• Formation of appropriate error responses
Business Components
Business components are highly cohesive and loosely coupled. They meet the requirements of a
particular functional requirement. They are transparent to the nature of the calling client. The
parameters in these components are made highly configurable to meet the fast changing
business. The Business layer is designed in three layers:
• Infrastructure Components
• Business Interface
• Business Implementation
Infrastructure Components: System level functionalities such as DB connection pooling, thread
pooling, Security validations and so on. requirements can be broadly classified into
infrastructure requirements. These requirements get repeated in every application development.
The components that are not specific to any business function or domain fall into this layer.
These components are highly configurable, as the usage scope will be universal.
Business Interface: This layer gives bird’s eye view on the functional requirements. This view
changes very rarely across different implementation of the same application. This clear
demarcation brings in reusability across similar functional domain. Java Interfaces are normally
used to define classes in this layer.
Business Implementation: Business implementation bridges the gap between application
requirements and the Business Interface. The components in this layer are broken down into
Business Workflow handlers, data models and event processors.
Data Access Components
These are set of Java Classes for interacting with the database for all the data manipulation
operations, query or executing any database stored procedures.
1.4 Technical Developing environment developing tools and OS
Following is the Technical development environment.
Platforms UNIX based (Solaris, Linux, AIX,HP-UX)
User Interface Browser Based GUI (IE 6.x/Netscape 7.x)
Web Server iPlanet 6.1/Weblogic 8.1
Security Server Authentication: Armor/Any LDAP based
Authorization Intellect Armor
Reporting Intellect Reports
App Server Weblogic 7.x/8.x
Load balancing Weblogic clustering, Oracle RAC
Databases Oracle 9i/10g
Ops Environment Server: Solaris 8.x/Red Hat AS 3.0
Client: Windows 2000 Workstations
Client: Windows 2000 Workstations
Integration/Messaging Intellect Integrator
Languages Java, Pro*C,JavaScript, PL/SQL
Standards adopted J2EE
1.5 Methodology for designing the system
We follow the Waterfall methodology for the development.the methodology is described as
under.
This is a linear sequential model using the principles of structured system analysis and design.
In this methodology, first comes the analysis related phases, then the design phase, followed by
the construction, with testing related phases completing the process. This methodology is called
the waterfall methodology because each phase flows naturally into the next phase like water
over a series of falls.
The process forces the analysis team to precisely define their requirements. It is much easier to
build something if the exact requirements are known.
Phase Diagram
In this methodology, phases are very tightly coupled with the software-engineering tasks, as
shown in the diagram.
Lifecycle Description
Process
Key Steps Deliverable Verification and Validation
1. Project Initiation
Entry Criteria: Identification of a piece of work as a project
Exit Criteria: Senior Management approval
Initiate Project
L0 Estimates Project Initiation Report (PIR) Project Management Review (PMR)
2. Requirement Study
Entry Criteria: Signed contract/ MOU/ LOI/ Work order
Exit Criteria: RDD sign off
Prepare for requirements study
Plan for requirements study Requirements Study Initiation Document Review
Define the Requirements Requirements Definition Document User Review
Internal Review
User Sign-off
Plan the Project
L1 Estimates Project Quality and Software Configuration Management (SCM) Plans /
Consolidated Project Plans
Project Schedule PPR
3. Analysis
Entry Criteria: Completion of Requirement study
Exit Criteria: Analysis/Functional specification model reviewed and approved
Prepare for Analysis
Revisit Estimates, Risks and Plans Updated Plans
Detailed schedule for the phase Project Plan Review (PPR)
Analyze Requirements
Trace functional specifications to requirements Analysis/Functional Specifications Document
that includes functional architecture
Traceability Matrix User Review
Internal Review
User Sign-off
4. Design
Entry Criteria: Completion of Analysis
Exit Criteria: Detailed design reviewed
Prepare for Design
Revisit Estimates, Risks and Plans
L2 Estimates Updated Plan Documents
Management Processes
Process Area
Process
Key Steps Deliverable Applicable Duration / Frequency
1.Project Management
Project Planning Project, Quality and Software Configuration Management (SCM) plans/
consolidated plans Initially, after completion of requirements study
Subsequently, plans are revisited at the beginning of each phase
Re-planning is also required at any point in time for reasons like—drastic changes in
requirements/ project scope, excessive slippage, unmanageable defects etc.
Project Tracking: Status Reporting Senior Management Reporting
Status Reports internal to Project
Customer Status Reports After start of Requirements Study on a monthly basis
Status Reports internal to Project on a weekly / fortnightly basis as per plan
Customer Status Report as agreed with the customer as per the plan
Project Tracking: Project Status Review Project Status Review (PSR) Minutes After start of
Requirements Study
Fortnightly frequency till project completion
Project Tracking: Project management review Project Management Review (PMR) On
completion of Project Initiation Report
Monthly frequency till project completion
Quantitative Management: Metrics Collection Metrics for Development (M-DV) Form On
completion of project initiation
Monthly frequency till project completion
Quantitative Management: Tracking of Goals Consolidated Plan Part II/ Goal Tracking
Worksheet On completion of Requirements Study
As per the identified frequency in plan
At the minimum on completion of each phase
2. Quality Management
Language Standards Part of Project Plan
Reviews Review Form For all deliverables as identified in lifecycle description
Software Quality Assurance: Monthly planning and tracking SQA Status Report After project
initiation
Software Quality Assurance: Software Process Audit PCI Initially on completion of RS or as
per SQA plan
On completion of each phase or as per SQA plan
Defect Prevention Task Kick-off Meeting (TKM) Minutes Start of Requirements Study
Start of each Phase as per the criteria stated in Defect Prevention Process and / or Project
Quality Plan
Defect Prevention Causal Analysis Meeting (CAM) Minutes End of Functional Specifications.
End of each phase as per the criteria stated in Defect Prevention Process and / or Project
Quality Plan
3. Software Configuration Management
Change Control Software Change Form Any change required in any CI after it has been
baselined
Version Control Versions of CI Any change required in any CI after it has been baselined
Release Control Release Notes
SQA Certificate Release of documents, prototype and system
Perform Configuration Audits Audit Trail Report
Issues Once per month except during system testing.
At least on a weekly basis, and at the end of each round of testing during system testing.
Tracking, Reporting and Review of Configuration Management activities Change Status Report
DBA Report Fortnightly
Fortnightly
4. Project Administration and Miscellaneous
All other miscellaneous standards, procedures and guidelines would be applicable as defined in
IQMS.
Project Administration
Handover
Password Envelope
Copyright Message
Project Folder