Second Year Project — Software Development in Large Teams
Student Developer
Period
Location
Copenhagen, Denmark
Collaborated with IBM as part of ITU’s Software Development in Large Teams project, developing an MVP for an open-source platform that helps companies calculate CO₂ emissions from transportation through a working API.
Overview
As part of ITU’s Second Year Project: Software Development in Large Teams, I worked on a software project in collaboration with IBM. The goal was to build an MVP for an open-source solution that could help companies understand the environmental impact of their transportation activities.
Our team developed a web-based solution centred around calculating CO₂ emissions from transportation. Rather than only presenting information about sustainability, the project provided a working API through which transportation data could be processed and translated into estimated emissions.
My role
I worked as a Student Developer within a larger development team. Unlike smaller university projects, the focus was not only on implementing software but also on learning how a larger team organises, coordinates and delivers a shared product.
My work involved contributing to the development of the MVP while participating in the team’s Scrum process, collaborating with other developers and helping turn the requirements of an external industry partner into a working software solution.
The problem
Companies increasingly need to understand the environmental impact associated with transporting goods and operating transportation networks. Turning transportation activity into a meaningful CO₂ estimate, however, requires a consistent way of processing the underlying data and performing the calculation.
The project explored how this process could be exposed through an accessible, open-source solution so that organisations could calculate transportation-related emissions without having to build the underlying functionality themselves.
The solution
Together with the team, I contributed to an MVP that allowed transportation information to be translated into estimated CO₂ emissions. A working API formed an important part of the solution, providing a programmatic interface for performing the calculations.
The intention was to make the solution openly available and provide companies with a free starting point for incorporating transportation-emission calculations into their own workflows and applications.
Calculate estimated CO₂ emissions associated with transportation
Expose emission calculations through a working API
Provide a web-based interface around the underlying functionality
Develop the solution as an MVP that could be iterated on
Keep the project open-source and accessible to organisations
From transportation data to CO₂ estimate
A conceptual view of how the platform turns transportation information into an emissions result.
1
Transportation data
Transportation information is provided to the platform as the input for an emission calculation.
2
API request
The data is submitted through the API in a structured format.
3
Emission calculation
The system processes the transportation information and calculates the corresponding estimated CO₂ emissions.
4
CO₂ result
The calculated emission estimate is returned so it can be presented or consumed by another application.
Working in a large development team
A major part of the project was learning how software development changes when many developers contribute to the same product. Features could not be developed completely in isolation: interfaces, requirements and implementation decisions had to be coordinated across the team.
This gave me practical experience with collaborative development beyond simply dividing a project into independent tasks. Changes needed to fit into a shared codebase and a shared understanding of what the product was supposed to become.
Agile development with Scrum
The team organised the project using Scrum, working iteratively rather than attempting to design and implement the entire system upfront. Development was divided into smaller pieces of work that could be discussed, implemented and evaluated throughout the project.
Working this way gave me practical experience with agile software development and showed how regular communication, prioritisation and incremental delivery help coordinate a larger engineering team.
Collaboration with IBM
Working with IBM added an industry-facing dimension to the project. Instead of developing solely from an academic specification, the team also had to communicate with an external partner and translate project goals into concrete software requirements.
That experience helped bridge the gap between university software projects and professional development, particularly around communication, requirements and delivering something that another stakeholder could actually evaluate and use.
What I am responsible for
Contributing to the development of a transportation CO₂-emission calculation platform in collaboration with IBM
Developing functionality for the project’s MVP
Contributing to a working API for transportation-emission calculations
Working collaboratively within a larger software development team
Participating in Scrum and iterative development processes
Translating project requirements into working software
Collaborating with an external industry partner throughout the project
Engineering challenges
Coordinating development across a larger team where individual changes had to integrate into a shared product.
Turning the broad goal of calculating transportation-related CO₂ emissions into concrete software functionality.
Balancing technical implementation with requirements and feedback from an external industry partner.
Keeping development coordinated through iterative Scrum processes rather than treating the project as a collection of independent tasks.
What I learned
Building software in a larger team requires communication and coordination just as much as technical implementation.
Breaking a product into smaller iterative deliveries makes complex projects easier to coordinate and evaluate.
Working with an external partner taught me how requirements evolve through communication rather than arriving as a complete specification.
APIs provide a useful boundary between domain-specific calculations and the applications that want to consume them.
The project gave me practical experience applying Scrum and agile development beyond smaller university assignments.