> For the complete documentation index, see [llms.txt](https://pmse.gitbook.io/pmse-dhdk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pmse.gitbook.io/pmse-dhdk/1.-project-charter/1.5-activities.md).

# 1.5 Activities

The activities are categorized according to the <mark style="color:blue;">**software development lifecycle (SDLC)**</mark> stages and project management methodologies like <mark style="color:blue;">**Agile**</mark> and <mark style="color:blue;">**PRINCE2**</mark>. The estimation of the duration for each activity, including the number of days and hours, is based on the <mark style="color:blue;">**scope of work**</mark> and <mark style="color:blue;">**complexity**</mark>. The workweek is Monday through Friday.

{% embed url="<https://docs.google.com/spreadsheets/d/1NE9BxSrAw_s9Yvl9eryydHaDkaPCpqYVBbu450JMh9M/edit?usp=sharing>" fullWidth="true" %}
Activities table from Project Plan.
{% endembed %}

The project begins with a kickoff meeting on November 4, 2024, lasting one day and requiring four hours of effort from the Project Manager to establish goals, deliverables, and team roles. This focused meeting is a single-session activity that efficiently sets the foundation for the project. The requirements gathering phase follows, spanning five days from November 5 to November 11, 2024, with an estimated 20 hours of effort. This phase involves multiple meetings with stakeholders, discussions, and documentation to ensure thorough engagement and comprehensive requirement collection. The gathered requirements are validated over three days, from November 12 to November 14, 2024, with 12 hours of effort. This step is critical to ensuring completeness and accuracy and includes careful review and stakeholder consultations, which are less time-intensive than the initial gathering phase.

From November 15 to November 26, 2024, the model design phase takes place, involving the NLP Specialist and Software Developer in creating the prototype's architecture over eight days with an effort of 32 hours. Designing the prototype architecture involves technical discussions, conceptualization, and documentation, which necessitate collaboration and iterative refinement. Functional analysis is conducted from November 27 to December 2, 2024, over four days and requiring 16 hours, during which the team thoroughly reviews the requirements to resolve ambiguities. The UX design phase occurs from December 3 to December 5, 2024, taking three days and 12 hours of effort by the UX/UI Designer to craft a user-friendly interface. This phase includes designing wireframes and ensuring usability, aligning with the foundational goals of user experience design.

Subsequently, the system architecture design phase, lasting seven days from December 6 to December 16, 2024, involves the NLP Specialist and Software Developer in designing the system's overall structure with 28 hours of effort. This phase is essential for planning APIs, integration points, and data flows, requiring detailed documentation and review. The prototype development phase spans 15 days from December 17, 2024, to January 21, 2025, with 75 hours of effort by the NLP Specialist and Software Developer to create a functional demo. This phase is time-intensive, involving significant coding and integration work to address technical challenges while delivering a polished prototype. Unit testing of individual modules follows, conducted by the QA Team over five days from January 22 to January 28, 2025, with an estimated 20 hours of effort. This allows for creating test cases, running tests, and resolving issues to ensure that components perform as expected.

On January 29, 2025, the Project Manager presents the prototype to the user in a one-day session requiring four hours, collecting valuable feedback. This focused session ensures actionable insights are gathered to refine the application. Based on this feedback, the full application development begins on January 30 and continues until February 19, 2025, spanning 15 days with 75 hours of effort from the Software Developer. This period allows for the implementation of feedback, ensuring the application aligns with stakeholder expectations. System integration testing is conducted over 10 days, from February 20 to March 5, 2025, with 40 hours of effort by the QA Team to ensure seamless component interaction. This thorough testing process includes creating test cases, running end-to-end tests, and resolving any identified issues.

User acceptance testing (UAT) follows from March 6 to March 12, 2025, taking five days and 20 hours of effort, validating the application's alignment with user expectations. This phase involves end-user testing and feedback to ensure the system meets requirements. The final application is deployed over three days from March 13 to March 17, 2025, requiring 12 hours of effort by the Deployment Team. This step includes system setup, configuration, and final verification. The project concludes with a roll-out and feedback gathering phase, lasting five days from March 18 to March 24, 2025, involving 20 hours of effort by the Project Manager to collect user insights and make any necessary adjustments. This ensures a smooth transition to production and allows for final refinements, completing the project efficiently while maintaining high-quality outcomes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://pmse.gitbook.io/pmse-dhdk/1.-project-charter/1.5-activities.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.