Skip to content

Latest commit

 

History

History
61 lines (34 loc) · 4.07 KB

Process_Description.md

File metadata and controls

61 lines (34 loc) · 4.07 KB

Process Description

First Submission

click to expand

We can describe the first submission in 3 well-defined phases:

  1. Ideas Phase 1.1 Repository Structure
  2. Research Phase
  3. Artifacts Phase

In the first one, the main goal was to obtain approval for the project idea, in parallel to this, we also set up the repository structure, where we touched out protected branches and workflow and we tried to use tools that could foment good practices with commits.

In the second one, the goal was to go deeper into the idea with the most potential which in this case was "Real uses of Design Patterns". At this point, the team roles were defined, but not static, we take as reference the Scrum Framework:

  • Product Owner: Isaías Rodríguez, Marco Canché.
  • Scrum Master: Rodrigo Pacab, Marco Canché.
  • Develpment Team: José Luis Gutiérrez, Carlos Ruz.

As we can see, one person could take more than one role, that's what we say "not static".

As scrum uses sprints, all the tasks were grouped by sprints, and tasks that weren't complete, were passed to the next sprint. Each sprint took a long of 1 week.

You can take a look at our Github Project roadmap view.

Once we had enough information about the topic of the project, all that remained in the last phase was to start creating artifacts: requirements, use cases/user stories, use case diagrams, etc.

Documentation was done for all these phases, and meeting logs can be found in the repository.

Second Submission

click to expand

For the second submission, we focus on researching at least 5 design patterns, and demostrate how they work in a real world example. We still have the same roles and the same workflow, there were tries to improve the workflow, but we didn't have enough time to implement them, like automate the contribution metric through a Github Action.

As part of the new tasks in the Second Submission, was selecting which technology we were going to use to show the examples, at the end of the day we decided to use the Astro framework, which is a static site generator, that uses markdown files to render HTML content, this was a good choice because it was easy to use and it was fast to implement.

Finally we had to create the video and the slides, which were done in the last week of the sprint.

Third Submission

click to expand

Overall, throughout the three submissions, the process has been peculiar. Even halfway through the semester, we lacked clarity about the nature of the project as a whole, or rather, the execution of the project idea wasn't precisely defined. Despite being design pattern examples, would it simply be a repository? We merely provided a link to a Google Drive folder and that was it. Mentorship sessions helped clarify our ideas somewhat; the key advice was to focus more on example quality and seek a swift implementation. This led to investigating the use of Astro and publishing with markdown files. Essentially, our project took the form of a blog, something that didn't particularly excite the team, but it was what we had, and it needed to be done well.

This submission focuses on technically enhancing the documentation, paying attention to the instructional aspect: explaining the components comprising the system in question and offering a brief tutorial on its usage. Furthermore, the presentation of examples was improved by changing the default template of Astro's static web pages to that of a blog, providing an aesthetically pleasing and professional look. This also allowed potential scalability to more diverse topics through Astro's collections.

Regarding organization, the same format was maintained throughout the three submissions. However, there was a clear lack of discipline and follow-through on many of the planned sprints, as well as other tasks that could have automated processes, such as the contribution metric, which remained in the 'Icebox' and couldn't be implemented due to time constraints