Creating a Custom Application for Lotus Notes, Domino with Domino Designer - An Example
If you spend your IT dollars wisely, you will find that well developed custom applications that automate and enable critical business process give a very high return on investment. Now that you have Lotus Notes installed through your organization, it is time for you to take a look at custom applications that can be quickly developed and deployed through your organizations. This note gives you a snapshot of what it takes to develop and deploy a custom application running on Lotus Notes or on Domino Server.
- Determine the business rationale for the investement – Justification
- Define the boundaries of the application – Scoping, Business Analysis
- Detail the application’s requirement – Systems Analysis
- Think through the technical design of the application – Architecture, Design
- Code the application and unit test it – Coding, Unit Testing
- System test the application against the requirements – Systems Testing
- Get the users of the applications to test it – User Acceptance Testing
- Roll out the application in the production environment – Deployment, Roll out
For this purpose, we will examine a Performance Appraisal System. Performance appraisal is a fairly standardized process that happens in many organizations, though each organization has its own quirks about how this is done. For our purpose, we will assume the following about the performance appraisal application:
Each employee is assigned one department
Each employee has a reporting manager
Each department has a department head
The HR person associated with the department initiates an appraisal process for each employee based on an appraisal calendar maintained outside the system.
The central element of the appraisal is the appraisal form which has a set of key performance areas based on the roles played by the employee.
The key performance areas have associated benchmarks which define performance rating on a scale of 1 – 5 (1 being poorest and 5 being the best performance)
The employee completes a self appraisal form and sends to his manager
The manager marks his observation and sends it to the departmental head
During the appraisal meeting, the employee and the manager (and optionally the department head) review the appraisal notes and finalize the appraisal comments and rating.
The manager creates action points for the next appraisal period and closes the appraisal
The manager makes any salary revisions necessary
Justification:
To determine the justification for the appraisal application, the following costs and benefits will be relevant:
Costs:
- Cost of developing the application
- Cost of training people on how to use the application
- Cost of maintaining the application
Benefits:
- Time saved in HR person co-ordinating the appraisal process
- Employee morale being good in having a transparent and efficient process; less grievances
- Employee motivation in having a clear dashboard for current appraisal period
- Minimizing paper, information loss
- Minimizing security risks of letting the appraisal documents lying around in an insecure place like the file system.
Detailed financial models are not within the scope of this analysis, but can be developed by plugging in $$ values to the costs and benefits.
Scoping, Business Anlaysis:
In this phase, the business champion along with Maarga’s architect essentially determines what goes inside the system and what stays outside. Some of the considerations for this example project include:
- Does the system interact with a bigger HR Information System for retrieving employee data?
- What kind of reports need to be included with the system?
- Does the appraisal system need to have extensive integration with the payroll system for integrating pay structure related details etc.
In general business anlaysis comes out with information including:
- Who are the users of this system?
- What will they use it for?
- Who are the other stakeholders in this system?
- What specific needs do they have of this system?
- For each use of the system, what exactly will the user do, and what will the system response be?
- What will be the system initiated actions?
- How will the system communicate with the users?
- How does a specific use case start? How will it terminate?
- What are repetitive behaviours within the system/tasks?
- What are the pre-requisites for a task to be done through the system?
- What happens after a specific task is completed through the system?
The details of all this analysis are captured in documents, screenshots, prototype applications etc. The requirements are typically numbered and prioritized. In some occasions, we might also write a user manual for the application, and make it the default requirements document for the application.
In our present system, the following are a starter set of use cases:
HR Manager:
- Scan and Manage the appraisal calendar
- Initiate Appraisal for an Employee
- Assign Appraising Manager to an Employee (if not picked up from the Notes Inventory)
- Manage Employees, Managers
- View progress of Appraisals (individual, consolidated)
- Block time in Appraising Manager’s calendars for appraisal purposes
- Review appraisal notes, and suggest corrections/training if necessary
Employee:
- Fill up Self Appraisal
- View the Manager’s Appraisal
- View action points for current appraisal cycle
- View Appraisal Comments, Rating
Manager:
- Appraise an Employee
- Finalize an appraisal, with appraisal comments, ratings, salary revision
- View and manage own calendar
Department Head:
- View status of appraisals of all employees in department
- View details of an individual appraisal
The User Requirements Document will further detail information to be on the appraisal form, the rating system, reporting structure etc.
The requirements phase will also explore usability by making mock user interfaces (either paper or Notes prototyping) and getting user feedback. Details of the operating environment including server to be used for deployment, Web vs. Notes vs. Mobile access etc. will also be detailed
Starting with this phase, Lotus Notes technology will take over. Some of the decisions taken in the Design phase include:
- What are the forms needed?
- What information needs to go into sub forms that can be reused across the application?
- How will validation and error checking be handled?
- How many databases does the application need? How will the databases interact among themselves?
- What views are needed? Which of these needs to be categorized? Which of these need to be sortable?
- How will the user interface goals be achieved? Which among the UI widgets provided by Domino Designer be used? Navigators, Frames, Framesets, Outlines, Pages, Smart Icons, Action Bars etc.
- What information needs to be configurable? Organization Name, Server name etc.
- Which tasks need to be automated through agents? Which of these agents need to be private vs. shared? Which of the agents need to be automatically run? On what schedule?
- What language to use for the application, for specific tasks? LotusScript vs. Java vs. Formula Language
- Which of the agents need to be restricted agents, based on the runtime situation as understood from requirements gathering phase?
- How will this application integrate with other applications? Will it output XML that can be used by external applications or make a connection using a standard database middleware?
- What will be coding conventions used for the project?
As a result of this phase, the output will include:
- A list of forms with field names, types
- A list of views
- A layout paradigm, with a list of design elements associated
- A list of agents with their expected performance and interfaces defined
- Assorted guidelines on coding conventions etc.
Coding and Unit Testing Phase:
During this phase, the developers involved in the project will take the design spec and translate it into code. They will first set up the development environment which matches the production environment to a reasonable extent. They will then proceed to create the design elements defined earlier, and test each element for desired functionality. A lot of the errors will be thrown up when integrating the disparate elements together, and even more when the complete system is being integrated. The developers will comment the code to explain their implementation of the different design decisions.
System testing is testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of Black box testing, and as such, should require no knowledge of the inner design of the code or logic.
A separate testing team will be involved in taking up the User Requirements Document and translating into a Test Plan and Test Cases. Put together all the test cases will test all the use cases outlined in the requirements document. A detailed log of test results will be kept with each test run, so that what fails and what succeeds are clear to all concerned.
After the system passes system testing without any critical errors, it will be sent to the customer for acceptance testing. During acceptance testing, a representative for each category of user will put the application through the paces to ensure that all the functionality is delivered as expected. Application testing will through up important insights into limitations/problems with the system when actually used by a real user (or a close approximation) in a real life situation. Such insights will be noted and implemented if the situation warrants it, or rolled into a future version as appropriate.
During deployment, all the concerned users will be trained on the use of the system. The notes application will be copied onto the production Domino server, and all access control will be set as per application requirements and organizational security policies. Any old data will be migrated into the new system and tested. The applications performance in the real environment will be monitored and then the application will be handed over to the maintenance team.