A project life cycle consists of phases, which allow better control and manageability of the project. The project begins with the project request, which can originate from end user groups, departments within an organization, or other organizations.
In this case, the project request is initiated at an organizational level by the top management of the company. After the project request, the project undergoes the following phases:
-
Project initiation
-
Project execution
-
Project deployment
In the project initiation phase, the objectives, scope, risks, and costs associated with the project are identified. This phase also involves identifying milestones and deadlines and the team based on the required skills. In addition, a comprehensive plan is prepared for the activities to be performed during the various phases of the project life cycle. The complexity of this phase depends upon the size and complexity of the project.
The project execution phase involves coordination of the resources to execute the plan. This phase is further divided in to the following stages:
-
Requirements analysis
-
High-level design
-
Low-level design
-
Construction
-
Integration and testing
-
User acceptance testing
The final phase in a project life cycle, which is the project deployment phase needs explanation before discussing the other stages in detail. As the name suggests, during this phase, the application is deployed at the client location. In addition, support is provided to the client for a particular period that takes care of any bugs that might occur in the application after deployment.
The various stages in the project execution phase are discussed in the following sections.
Requirements Analysis
This phase involves identifying the various functional requirements of the application. The development team studied the current manual system of the employee handbook and interviewed the employees to identify their requirements.
The reference application has two types of users, authors and readers. The development team identified the following requirements for the content authors:
-
Authoring content should be easy. It should be possible for the author to select the parts, chapters, and sections from a list wherever required.
-
It should be easy to make changes to any existing policy.
-
It should be possible for the authors to hide the documents that they are currently working on from the readers.
-
After the content authoring, publishing should be easy.
-
It should be possible to specify that certain policies and procedures apply to only specific employees.
-
Only authorized users should be allowed to update the content.
For the readers, the following requirements were identified:
-
The application interface should be simple so that readers can use the application without extensive training.
-
The application organization should be simple to help readers navigate to different parts easily.
-
Readers should be able to keep track of changed policies.
-
Readers should be able to search documents based on specified criteria.
-
Readers who are not connected to the network all the times should be able to access the policies and procedures locally. At the same time, they should be able to receive any updates made to the documents.
Based on the identified requirements, the development team decides to create a reference application, which is a database named Handbook, using Domino Designer R6.
High-Level Design
In the high-level design phase, the working of the application is identified. The various user interface screens are identified and presented to the client for approval. Based on the client feedback, the various user interface screens are finalized.
To identify the various user interface screens for the Handbook database, first identify how the authors and readers interact with the database.
The user interactions can be classified as content authoring and content access. The content authoring allows the authorized authors to create, modify, and delete documents. The corporate office makes the policy decisions and a team from the HR department is responsible for keeping the documents up-to-date.
The content access, on the other hand, is limited to reading the existing policies and procedures. The employees access the content through a Topics index. They may also use the search facility to locate any content that matches specific criteria. The employees are scattered in branch offices and client sites in addition to the corporate office; all the employees should be able to access the Handbook database. The different employees can access the Handbook database in various ways or modes.
Depending on how the users access the database, the users are classified into two categories. The first set of users access the database directly from the server over a local area network. As already mentioned, the employees are scattered across branch offices. For these employees, the database is replicated to the servers in the branch offices. The employees in branch offices access the local replicas available on their respective servers. The replicas are kept in synch using low-priority replications between the corporate office server and branch office servers. These replications happen once in a day, usually during the night. Therefore, any changes made to the content during the working hours is available to the branch offices the next day.
The second set of users are the employees located at the client sites and those who belong to the marketing department. They can connect to the branch office or corporate office using dial-up connectivity. Such users are called mobile users. It is not possible for these users to remain connected to the server for long periods. Therefore, a local replica copy is maintained on their workstations. Instructions will be given to them to replicate their Handbook database at least once day, preferably during the evening or night.
After identifying the user interaction with the database and the different modes in which different employees access the database, the development team identified the various user interface screens for the database.
Readers can access individual documents using a view named Topics index
Mixing the older versions with the latest versions of documents will unnecessarily confuse the readers. Therefore, the older versions of documents should be listed in a separate view whose design is similar to the Topics index view.
Similar to the Topics index view, which is available to all the users, readers, and content authors, the database should include a view that is available exclusively to the content authors. This view is similar to the Topics index view in design, but it lists the documents that are currently being authored.
Next, to provide the personalization feature that enables users to keep the documents they refer to most in a specific place for quick retrieval on demand, the database should allow users to create personal folders. If these folders are stored on the user's desktop, lot of space can also be saved on the server.
After identifying the various forms and views, the database should provide an interface that connects these design elements for easy access. To connect the various database design elements, Notes provides navigators, outlines, and framesets. The first user interface screen connects the various database design elements.
To implement the search feature, you do not need to create a search engine exclusively. Instead, Notes provide this engine as a basic feature, called the Full Text Search feature, of the platform. To provide search capabilities to the application, you simply need to enable the full text search by creating a full text search index.
Low-Level Design
During the low-level design phase, a detailed design of the various software modules is prepared using the high-level design. The team decides on the various standards, such as naming conventions for forms, views, and fields for a project. All these specifications are documented so that consistency can be maintained among the various modules for an application.
Construction
During the construction phase, various components of the application are coded. The various specifications identified during the low-level design are used to accomplish this. For the Handbook database, the forms, views, and other elements are constructed.
Integration and Testing
In the integration and testing phase, various tests and validations are carried out on the various modules and their integration functionality is checked. For the Handbook database, all the forms, views, navigators, outlines, framesets, and agents would be integrated and tested.
User Acceptance Testing
In the user acceptance testing phase, various tests are carried out based on the predefined acceptance criteria given by the client. In addition, system support is provided to troubleshoot any issues or bugs identified at this phase. For the Handbook database, a few employees can be asked to use the application and give feedback on it
| 
Disclaimer
