I.
Introduction
1.1 Project Overview: This project aims to develop a new activity task management
system for EIAR to streamline the budget request process, minimize rejected project
proposals, and reduce paperwork. The current Activity Tracking System (ATS) is
inadequate, leading to inefficiencies and delays. This new system will provide a
centralized platform for managing research activities, facilitating better
communication and collaboration among researchers, administrators, and directors.
The improved efficiency will directly contribute to a reduction in the number of
rejected budget requests and the associated administrative burden.
1.2 Project Goals and Objectives:
* Reduce the number of rejected project proposals by 25% within six months of
implementation.
* Decrease the average processing time for budget requests by 50% within six
months.
* Improve researcher satisfaction with the budget request and project management
process by at least 75% (measured by a post-implementation survey).
* Reduce administrative paperwork related to project management by at least 40%
within six months.
1.3 Scope:
The system will encompass all aspects of project management from proposal
submission and budget request to Task assignment, progress Tracking, and final
Reporting. It will integrate with existing financial systems (we can specify IFMIS)
within the institute to facilitate budget management.
Features outside the core project management functions (for instance sophisticated
data analytic beyond basic reporting) will be considered in future phases.
1.4 Target Audience: Agricultural Researchers, Administrative Staff, Support Staff,
and Directors.
II. System Analysis
• 2.1 Current System Analysis: The current Activity Tracking System (ATS) suffers
from several critical issues: It's not easily operable; we can specify other issues, e.g.,
poor user interface, lack of reporting features, insufficient security, data
inconsistency, limited access control, etc.]. These problems result in delayed project
approvals, increased paperwork, and a higher rejection rate for budget requests.
2.2 Requirements Gathering:
The functional and non-functional requirements from the previous response, tailoring
them to this specific context. specific requirements:
* Proposal Submission Module: Online submission of research proposals with built-
in validation checks.
* Budget Request Module: Integrated budget request system with clear guidelines
and automated checks.
* Task Management Module:
➢Assign tasks to researchers,
➢set deadlines,
➢track progress,
➢and allow collaboration.
* Reporting and Analytic Module:
➢ Generate reports on project progress,
➢ budget utilization, and overall research productivity.
➢ Visualizations of key metrics.
* Communication Module:
➢ Facilitate communication between researchers, administrators, and directors
(e.g., built-in messaging or integration with existing communication systems).
* Access Control Module:
➢ Role-based access control to ensure data security and integrity. (Project admin,
researcher ,etc )
2.3 Use Case Diagram:
Create a use case diagram illustrating the interactions between different user roles
(Researchers, Administrators, Directors) and the system's functionalities.
2.4 Data Flow Diagram: Create a DFD to illustrate the flow of information within the
system, focusing on data related to project proposals, budget requests, and task
assignments.
III. System Design
3.1 System Architecture: Recommend a web-based application architecture. This
allows accessibility from various devices and locations. Consider using a three-tier
architecture (Presentation Tier, Application Tier, Data Tier). The technology stack
could include:
* Presentation Tier: A modern JavaScript
framework (React, Angular, [Link]) for the Front-end.
* Application Tier: A robust back-end framework (Python/Django, [Link],
PHP/Laravel) for handling business logic.
* Data Tier: A relational database management system (MySQL, PostgreSQL) for
storing project data.
3.2 Database Recommendations: Design a relational database schema with tables for:
* Projects (project ID, title, description, researcher, budget, start date, end date,
status)
* Tasks (task ID, project ID, description, assigned researcher, deadline, status)
* Users (user ID, role, name, contact information)
* Budget Requests (request ID, project ID, amount, status, justification)
* Reports (report ID, project ID, date generated, data)
3.3 User Interface (UI) Design: The UI should be intuitive and user-friendly, with
clear navigation and easy-to-understand forms. Consider using wireframes or
mockups to visualize the UI.
3.4 Module Design (Breakdown):
* Proposal Submission Module: Handles proposal submission, validation, and
routing to relevant administrators.
* Budget Request Module: Allows researchers to submit budget requests,
administrators to review and approve/reject requests, and provides budget tracking
capabilities.
* Task Management Module: Facilitates task assignment, progress tracking,
deadline management, and team collaboration. Includes features for updating task
status, adding comments, and attaching files.
* Reporting and Analytic Module: Provides various reports (e.g., project status
reports, budget utilization reports, task completion reports). Visualizations such as
charts and graphs are essential for data interpretation.
* Communication Module: Enables secure messaging between users within the
system.
* Access Control Module: Implements role-based access control to restrict access to
sensitive information based on user roles.
* User Management Module: Allows administrators to manage user accounts and
permissions.
3.5 Technology Stack: This should be detailed in section 3.1 and refined based on
feasibility and resource availability.
IV - VI: Follow the structure of the previous response for Implementation, Testing,
and Conclusion, tailoring them to the agricultural research institute's context.
This outline should help us significantly in developing the Task management
Tracking system full proposal. This is the first draft of system design as initial point
of view to add or remove the design part of functional or non functional part of the
system design to design the seamless system that is the problem solver add more
detail and specific information throughout this outline to create a comprehensive
proposal. When this system is accept and proceed the system development will
consider conducting interviews with stakeholders to gather detailed requirements and
ensure the system meets their needs.
The hardware and personnel requirements for system development:-
I. System Hardware Requirements (Variable based on scale):
• Development Machines: Developers will need powerful computers for coding,
compiling, testing, and running development servers. These should have:
* Processor: At least a quad-core processor (i5 or Ryzen 5 equivalent or better).
More cores are beneficial for larger projects.
* RAM: 16GB RAM minimum; 32GB or more is recommended, especially for
larger projects or if running virtual machines.
* Storage: A solid-state drive (SSD) is highly recommended for faster development
cycles. 512GB or 1TB is a good starting point.
* Operating System: Windows, macOS, or Linux (any distribution will work).
• Development Servers (optional, but recommended for larger projects): A server is
often used for testing and deploying the system. Requirements depend on the
anticipated load, but consider:
* Processor: At least a quad-core processor.
* RAM: 8GB to 32GB, depending on the scale of the system.
* Storage: SSD is strongly recommended. Size depends on the anticipated data
volume.
• Database Server (depends on the database chosen): A separate server for your
database (e.g., PostgreSQL, MySQL, MongoDB) might be necessary, especially for
larger systems. Hardware requirements depend on the database and expected data
volume.
II. Number of ICT Professionals:
The number of professionals needed depends on tour system's scope and complexity:
• Simple System (e.g., a small team's task manager): One skilled full-stack developer
might be sufficient. They'd handle front-end (user interface), back-end (server-side
logic and database), and potentially DevOps (deployment and infrastructure).
• Medium-Complexity System (e.g., a departmental task manager with user roles and
permissions): A team of 2-3 developers is recommended. This might include:
* One front-end developer (focus on user interface/user experience).
* One back-end developer (focus on server-side logic and database interactions).
* One DevOps engineer (focus on deployment, infrastructure, and server
management). We can give this role partially handled by one of the other developers
in smaller teams.
• Complex Enterprise-Level System (e.g., a company-wide task management system
with integration with other systems, sophisticated reporting, and high scalability): A
larger team is necessary, including:
* Multiple front-end developers.
* Multiple back-end developers.
* Database administrators.
* DevOps engineers.
* Project manager.
* Quality assurance (QA) testers.
In summary the system is very a complex system requires a team of 5-10 or even
more professionals. The hardware requirements are also directly proportional to
project scope and future anticipated load. Also we can consider cloud services (like
AWS, Azure, or Google Cloud) for Scalability and easier management, especially for
larger projects.