Team:Concordia-Montreal/Engineering
Engineering Success
We followed best practices to ensure the engineering success of our project.
In order to ensure the engineering success of AstroBio, we conducted research to understand what are the common steps taken as part of a standard engineering design process. Based on our software requirements, we came up with a series of steps that have guaranteed a successful project.
Research
We considered the possibility of building a desktop versus a web app for AstroBio. The following criteria were key factors in our decision to implement AstroBio as a web app:
Installation Advantages
By implementing AstroBio as a web app, it can be launched by simply visiting the URL. This makes it easier for the user to start working on their research whenever they need to. It does not require big files or consume storage. Additionally, no registration is required which further facilitates accessibility.
Automatic Updates
Given that AstroBio is hosted online, we can take care of any software updates automatically without disrupting users. Moreover, users can also use the latest version of the software.
Cross-Platform Availability
AstroBio is not reliant on hardware or system specifications to run. The app can be launched from any device or platform. The only requirement is Internet access.
Resource Savings
In comparison to desktop apps, as a web app Astro simply requires significantly less processing power, increasing the overall accessibility of software.
Design
In terms of designing AstroBio, a Design Thinking approach was followed. This approach is user-centric. Our goal was to focus on the users first, seeking to understand their needs, and coming up with innovative solutions that would meet their needs. Design thinking can be further broken down into five phases: Empathize, Define, Ideate, Prototype and Test.
Design Thinking can be thought of as non-linear, iterative process that allows a software development team to understand users, define problems, and come up with innovative solutions to a problem (Interaction Design Foundation, 2020). The process itself involves five phases: Empathize, Define, Ideate, Prototype, and Test. These stages are not sequential, meaning that they can be implemented in parallel, and they can be repeated as many times as needed.
Empathize
The first stage of the Design Thinking process is Empathize. The goal is to gain an empathic understanding of the users you are designing for and the problem at hand. It involves observing, engaging, and conversing with the people you are designing for.
Why is Empathy so important?
Empathy is crucial to any human-centered design process. In the case of AstroBio, it allowed designers and software developers to put aside their assumptions and to gain the best possible understanding of users, their needs, and their problems.
User Interviews
There are many different approaches that can be used to empathize with users from creating journey maps to asking what-how-why when it comes to their needs. We opted to conduct user interview for this stage of the process.
We asked questions, recorded responses from stakeholders to collect data to build User Personas, examine the user experience, and assess the usability of AstroBio.
To find the list of all the stakeholders we consulted with, refer to the Human Practices section of the wiki.
Define
During the Define stage, all the information gathered during the Empathize phase was used to define the core problems faced by users. We developed User Personas based on our interviews with potential AstroBio users. The goal was to understand the scenarios in which users found themselves in when carrying out their work.
User Personas
Personas can be fined as fictional characters, which are created to represent how end users will utilize a product. They made the software design task less complex and provided a meaningful archetype which we later used to assess our progress (Interaction Design Foundation, 2020). We asked ourselves questions such as:
"What are the user's motivations?”
“What are the user's goals and frustrations?”
Ideate
The goal of the Ideate phase is to construct a meaningful and actionable problem statement, also known as a Point Of View (POV) (Interaction Design Foundation, 2020). We created POVs combining three elements: the user's occupation, tasks, and purpose.
POVs were articulated as follows:
As a [ occupation ], I need to [ task ] so that I can [ purpose ].
POVs were later transformed into User Stories which were then used to guide the development of features for AstroBio.
Prototype
The Prototype phase is all about producing scale-down version of the software. Before implementing any changes into AstroBio, we used Balsamiq>/a> to validate ideas, design considerations, as well as other aspects. This allowed us to quickly identify where refinements and changes would be needed.
Balsamiq
Balsamiq is a tool used to build screen interfaces for websites and software applications. We used Balsamiq to quickly come up with mockups.
Test
From a Design Thinking perspective, the Test phase is about gathering feedback in order to come up with ways to improve the quality of the software design.
Feedback Capture Grid
Typically, this kind of grid, includes four quadrants: Likes, Criticisms, Questions, and Ideas (Interaction Design Foundation, 2020).
All the positive feedback went into the Likes quadrant, negative comments about the prototype were placed in the Criticisms quadrant, any questions or doubts were placed in the Questions quadrant, and suggestions for improvements went into the Ideas quadrant.
After a test session, the software development team would discuss and determine what user interface changes would actually be implemented into AstroBio.
Build
To build AstroBio, we opted to follow Agile Development practices in order to accelerate software delivery and to better manage competing priorities when it came to software features.
Agile Development
Agile Software Development relies on a set of methodologies that are based on iterative development. This approach consists in grouping software development tasks into small development cycles that are repeated until a final product is achieved. Agile processes promote the rapid delivery of software and emphasize engagement with end users.
In general, Agile Development refers to any development process that is aligned with the concepts of the Agile Manifesto. This Manifesto was conceived by leading software development experts based on their experience on what techniques work or do not work in this field.
For our project, we followed a subset of Agile called Scrum.
Scrum can be defined as lightweight process framework centered around accelerated delivery, fast feedback, and continuous improvement.
Scrum Framework
Product Backlog
Our product backlog includes all the list of features that needed to be part of the final version of AstroBio.
To capture all these product features, the first step we took was to create User Stories. These stories captured software requirements from the user’s perspective. The product backlog can be thought of as a list of User Stories. The product backlog can be thought of as a list of user stories.
To view all the features that were implemented, download the AstroBio Product Backlog documentation.
User Stories
User stories are informal descriptions that focus on what the user wants to be able to achieve with the software without going into technical specifications. We created using as follows:
As a [ occupation ], I need to [ task ] so that I can [ purpose ].
To view all User Stories that were created, download the AstroBio User Stories documentation.
Sprint Planning
We held sprint planning meetings to select the order in which product backlog items would be implemented. Items from the product backlog were chosen based on priority and moved into a sprint backlog.
Sprint Backlog
Product backlog items or user stories were further broken down into sprint tasks. Each task was given a description, an assignee, and a deadline. To keep track of tasks, we implemented scrum boards.
Scrum Boards
Scrum boards are visual frameworks used to display the progression of software development tasks. These boards are known today as one of the most useful agile techniques. We created these boards using Asana. Our boards included the following:
User Stories: each user story came directly from the product backlog.
Sprint Tasks: each sprint task was derived out of a specific user story.
Task Workflow: typically, a task card followed a workflow until completion was achieved. We employed a simple workflow to organize all of our task cards: “To Do”, “In Progress”, and “Complete”.
By using Scrum boards, we were able to spot workflow bottlenecks quickly. For example, if the “In Progress” section contained several cards that were awaiting for activity, it was evident there was a delay. If that was the case, possible solutions were discussed during our weekly stand-up meetings. Since all the cards had assignees, it was also easy to spot which team member needed additional support.
Without a doubt the boards also helped us save time on unnecessary meetings or progress reports. They worked as a centralized task repository that keep everyone on the loop regarding how the project was progressing. Thanks to this factor, weekly meetings ran smoothly.
4Ls Retrospective
A retrospective is a meeting in which the software development team looks back on their experiences after a given sprint. It is important to note that 4L stands for:
Liked: What did you like about the sprint? What worked really well?
Learned: What did you learn? This included technical as well as non-technical knowledge.
Longed for: What resources did you want to use during the sprint that were not available?
Lacked: What did not work? What things could the team do better?
Retrospectives took place at the end of each sprint and lasted approximately 30 minutes. The software division’s team lead served as a retrospective facilitator. The findings were openly discussed, evaluated, and included in future sprints. In other words, the results were used to keep track of lessons learned and to ensure continuous improvement throughout our project.
The 4Ls retrospectives did not only allow us to assess AstroBio’s code base, they helped us assess our performance as a team and to evaluate the quality of our results. Moreover, these retrospectives encouraged us to acknowledge positive experiences and to remain factual in the face of challenges.
After setting the tone and preparing a virtual space for the retrospective, the facilitator guided the team to uncover useful insights regarding what worked well, and why. The idea was to guarantee that good working practices and procedures were maintained. By sharing the knowledge that was acquired during a specific sprint, team members were able to learn from others, and enhance their own knowledge base.
It was always communicated that no learning experience was too small to share with the group. When it came to what was longed for and what lacked, the team had the opportunity to determine what was needed and to prioritize future tasks based on these findings. Hosting online retrospective brought the team closer together and allow us to truly concentrate on taking action.
Test
In terms of testing AstroBio, we performed functional, as well as non-functional software testing.
Functional Testing
Functional testing implies making sure that each function of the software behaves as specified in the requirements. For AstroBio, we tested of all the functionalities by entering specific inputs to verify whether the actual results were matching the expected output.
Non-functional Testing
Non-functional refers to making sure the software is performing efficiently. The goal of this kind of testing is to improve the experience of the user.
Improve
To ensure continuous improvements for AstroBio, retrospectives were conducted. In layman's terms, retrospectives are meetings where the software team gathers together to discuss how to take steps that will improve their working practices. Conducting retrospectives was also part of the Agile Development methodology we employed to build AstroBio.
References
Interaction Design Foundation. (2020, August). Design Thinking. Retrieved from Interaction Design Foundation: https://www.interaction-design.org/literature/topics/design-thinking
National Aeronautics and Space Administration. (2018, January 30). Engineering Design Process. Retrieved from https://www.nasa.gov/audience/foreducators/best/edp.html
Science Buddies. (n.d.). The Engineering Design Process. Retrieved from https://www.sciencebuddies.org/science-fair-projects/engineering-design-process/engineering-design-process-steps
Agile Alliance. (n.d.). What is Agile? Retrieved from https://www.agilealliance.org/agile101/
Cluster, K. (2019). Agile Project Management: Learn How To Manage a Project With Agile. Independent Publisher.
Scrum.org. (n.d.). What is SCRUM? Retrieved from https://www.scrum.org/resources/what-is-scrum
Our 2020-2021 iGEM project is generously supported by
