Knowledge Management System Project Proposal for DPI Crownlands

This project proposal outlines the development of a Knowledge Management System (KMS) for DPI Crownlands, aiming to enhance organizational productivity and streamline business operations. The proposal details the system's architecture, functionalities, and integration and testing phases, adhering to the SDLC cycle. It emphasizes the importance of various testing methodologies, including unit, integration, system, and user acceptance testing, to ensure a bug-free and reliable system. The document also covers the implementation method, risk assessment and mitigation strategies, and the training program designed to equip users with the necessary skills to operate the KMS effectively. Furthermore, it addresses maintenance aspects, application support, periodic system maintenance, and backup procedures to ensure the long-term stability and functionality of the system. The goal is to create a centralized knowledge repository that improves transparency, optimizes resource utilization, and enhances customer satisfaction.

Student Details
PROJECT PROPOSAL
ASSESSMENT 3

Contents
Cover Letter for Sponsor........................................................................................................................2
Executive Summary:..............................................................................................................................3
Introduction (Project Overview):.......................................................................................................4
Review of the Features and functionalities offered by the project:...................................................4
Development of the System (SDLC Phase 4)..........................................................................................5
Architecture:......................................................................................................................................5
Graphical Representation of the Communication flow within the system:...................................6
Integration and Testing (Phase 5 of SDLC).............................................................................................9
Testing Analogy to be followed for the project:..............................................................................10
Unit Testing.....................................................................................................................................10
Integration Testing..........................................................................................................................11
System Testing:................................................................................................................................12
User Acceptance Testing:................................................................................................................13
Implementation (SDLC Phase 6)..........................................................................................................13
Implementation method:................................................................................................................13
Risk Assessment and Mitigation:.........................................................................................................15
Installation of the project................................................................................................................15
Training Delivery:.............................................................................................................................15
User Documentation for the project:..............................................................................................16
Maintenance: (SDLC Phase 7)..............................................................................................................16
Application Support Desk................................................................................................................16
Periodic System Maintenance.........................................................................................................17
System backup and support Environment in case of transitions and changes................................17
Conclusion...........................................................................................................................................17
References...........................................................................................................................................18
1

Cover Letter for Sponsor
[
Mr XYZ,
Designation
Organization
]
Subject: Detailed Proposal for Knowledge Management System for DPI Crownlands.
Dated: xx/xx/xxxx
Respected,
Following our conversation earlier today, the detailed proposal for the project follows this
letter which would help you learn further about our targets and the approach that we intend to
follow for making this project a great success.
As discussed with you previously, the KMS solution we intend to develop is focussed on
streamlining the operational approach and in turn enhancing the productivity of the business
operations at DPI Crownlands. With this project we intend to address the following set of objectives:
 Increased Organizational Productivity.
 Enables the organization to ensure governance, reporting and visibilities for the business
maps.
 A centralised location for all the knowledge relevant to the business operations or a
centralised repository to the knowledge.
 Automatic reference to the information and data.
In order to go ahead with the project I would like to request a financial (value-in kind) assistance
approval from the senior management of the organization (You). A detailed proposal for the system
architecture and other operational specifications is attached for further reference.
Please feel free to contact me in case of any further explanation.
Sincerely,
[
Closure
]
2

Executive Summary:
The organization DPI Crownlands faces certain difficulties following the changing legislation.
The report intends to discuss about the development of a Knowledge Management System
or KMS as a business mapping software in order to increase the productivity of the
organization and the key operations performed by it.
The report or the proposal is structured consistent with the flow of SDLC cycle (following
step 4, System Development). The report has initially described the system architecture of
the purposed software and how the steps like black box testing, unit testing, user
acceptance testing will play a crucial role in determining that the developed project is free
from every logical as well as technical bug.
The report has also highlighted the crucial elements that will be part of the training program
which will help the client side to learn the operational as well as the administrative end of
the KMS. Towards the end, the proposal describe the change and risk management activities
that will be followed during the management of this project.
3

Introduction (Project Overview):
In order to bring a high degree of transparency in the business and the process as well as
crucial data available to all the stakeholders such as business partners, customers, staff etc.
the Department of Primary industry or DPI Crownlands, intends to use a Knowledge
management System. The KMS or the Knowledge management System will allow these
stakeholders to learn about how the processes ae being performed within the industry and
how more efficiency ca be brought into the same.
With the same aim, Assessment 2 purposed the idea of a KMS or Business mapping
Software that will provide:
Targeted benefits:
 Improved standards of Knowledge management by describing the business process and other
standards so as the same can be sued to create corporate knowledge, which will be further shared to
carry out different tasks and activities. (Dowling, 2013)
 Enhanced Strategic Visibility: Additionally, the KMS will help the organization in identifying
business risks and requirements in order to optimise the efforts. (Al-Ahmad, 2012)
Review of the Features and functionalities offered by the project:
Features:
 Documenting and Standardizing Business process
 Creating a repository for business knowledge
 Integration of Process Maps to ensure that risks, requirements and inconsistencies
can be identified.
 Resource and effort optimisation
 Improved customer satisfaction (Karim et al., 2016)
Functional and Non-functional Specifications:
 Information Storage:
o Must be able to keep records of the information about customers and other
stakeholders.
o Must be able to keep track of the business processes and activities that the
organization intends to perform.
 Retrieval of information:
o The System must be capable of retrieving the information on the basis of
different filters, queries, guidelines and other specific requirements of the
operator.
 Collaboration and Mining of knowledge:
o The system must be capable of collaborating with the information collected
from different sources, keep track of the information sources, and then
effectively mine the required knowledge from the system.
 The Processes and the activities should be controlled and guided by the defined set
of policies and laws as defined by the organization or the government
administration.
4

 The Developed system should be able to automate the storage, management, and
analysis of the key information elements stored within the system.
 The GUI of the developed application should be easy to use an interactive.
 The Developed system must provide a support section to help the new users learn
about the basic operating approach of the system.
(Design of Patient Monitoring System(PMS) Application using Security Design Patterns in
Architecture Phase of Secure SDLC, 2016)
Development of the System (SDLC Phase 4)
As highlighted in Assessment 2, the project will be developed on the basis of the Agile
Development methodology to ensure continuous improvement for the project on the basis
of the inputs and feedbacks received.
Architecture:
The following Architecture for the System was highlighted in the previous Assessment.
Representation of the different modules:
Inputs Resources
In order to develop this Architecture the project team will need inputs from different
stakeholders associated with the project.
5

As highlighted in the above figure the inputs for stakeholders, pre-existing data records,
evaluation techniques, operating environment of the organization and the knowledge forms
(policies and regulations) will be the key contributors required to develop the architecture
of the Knowledge management system.
Graphical Representation of the Communication flow within the system:
User Control Flow:
6

The given figure defines how the control will flow throughout the application and the way
through which the admin and the regular users can interact with the application or the
system. Each user will be assigned a different permission set on the basis of their roles
within the application. (Karim et al., 2016)
The following figure defines different layers of the application or the system:
(Bansal & Kumar, 2014)
For example, as in case of the admin, the person will have the permissions to control, the
cache, configure data base and filters, configure database properties, etc. Similarly, a regular
user can only interact with the system with help of messages with the Theme or UI of the
System acting as the sole intermediate. (Rozenes, 2011)
Graphical Representation for some of the Use Cases for the Purposed System:
Following are some of the example Use cases and the Control flow for the system:
1. Top layer use case
Top layer use case defining the permissions every actor or user will have corresponding to
their roles in the system.
7

(Bansal & Kumar, 2014)
2. User Authentication use case:
(Bansal & Kumar, 2014)
3. Knowledge Access Use case
8

(Bansal & Kumar, 2014)
Programming languages and technologies used:
In order to develop the Web based Knowledge Management System, following programming
languages will be used:
Front end:
HTML, CSS, XML. (User Interface layer)
Backend:
PHP, Java Script
Database Management
SQL
Integration and Testing (Phase 5 of SDLC)
The integration and testing phase of Software or System Development lifecycle deals with two key
processes or operations that include:
 Testing of the developed modules
 Integration of the Developed Unit Modules
The Development Phase of the System Development Life cycle delivers working modules for each
specific requirement of the project. Once the modules are developed, they are then tested for
functionalities and technical reliability (Jindal, 2016). Further on, once the developed modules are
deemed free of any possible logical as well as technical error they are then integrated into a single
consolidated module or the complete solution, or System. After, integration, the system is then
9

again tested for inter-modular and intra modular communication and compatibilities to ensure that
the developed system or software is reliable to address the key requirements of the user group.
(K.Pandey & Batra, 2013)
Testing Analogy to be followed for the project:
Unit Testing
Cycle for the Modules:
10
Unit Testing Integration
Testing
System
Testing
Acceptance
Testing

As evident in the above cycle the focus of the unit testing approach is to fix the functionalities of
each of the module. The Unit tests are executed on each modules in order to identify the bugs and
errors that are present in the module. Further on the basis of the reviews received from the testing
approach, the codes are then reviewed and the necessary changes are being made. (K.Pandey & Batra,
2013)
Selected Unit Testing Approach for the project:
For this particular project the Unit Testing will be done on the basis of the following mentioned
techniques:
 Functional Testing:
Under this black box testing technique the functionality of the developed module will be tested. For
example
o Boundary value analysis or testing will be conducted to obtain the point of failure for
the project.
o Input domain testing can be used to obtain the constraints related to the inputs
given to the KMS where the system might exhibit n unusual behaviour. (Pradhan,
2014)
Following the functional testing, the second phase of unit testing will include a rigorous structural
testing approach to be used for:
 Statement testing to ensure that each code instruction of the project or system is tested
at least once for syntax as well as its functionality.
 Path Testing where each possible conditional path of the project source will be tested
for integrity.
In order to perform any type of testing the foremost requirement is to develop the test cases that
will be used to test the behaviour and the functionalities of the code written for each module.
Some of the Test Cases for the Unit testing will include:
 User Authentication
o Correct password and user name
o Empty User Name and password
o Empty user name but correct password
o Incorrect password.
Etc.
 Knowledge discover query:
o Adding a new user group
o Adding a new information element
o Updating the information elements
o Modifying the information
o Deleting the information etc.
Similarly other modules of the System will be tested against different condition set and
circumstances.
11