Skip to content

Repo for the decide problem of group 26 in software fundamentals course

Notifications You must be signed in to change notification settings

dd2480-group26-2024/decide

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

78 Commits
 
 
 
 
 
 

Repository files navigation

DECIDE

DECIDE is a program that is a part of an Anti Ballistic Missile system (ABM system). DECIDE will determine whether to launch an interceptor based on radar information. DECIDE combines the information of whether some conditions are met with a logical system to determine whether the interceptor will fire or not, the output in the end is a boolean signal.

In order to run the program, specify the global parameters in the decide.py file. Then run the program by running calling DECIDE() in the main function. Then you can run the program by calling python3 decide.py

Reflection of way-of-working according to Essence checklist

The principles, constraints and tools used were all committed to and agreed upon in the initial stages. A recommendation for the approach is not available, although there is a document where each person reflected on their level of comfort with the different approaches. The context was decently understood in the beginning, we had not fully understood the contraints on the commit format intially. The constraints for the selection, acquisition and use of practices were known from the assignment instructions (language constraints) and implied from the described competencies of everyone in the initial document.

A discussion was held on the way-of-working which resulted in a document detailing our practices, the tools to be used as well as our individual experiences as programmers. Issues we're created on GitHub so that work could be divided equally and start quickly. At first a non-negotiable practice was missed, (Unit tests along with every pull request), however, the team quickly adapted to the addition and work continued smoothly. The principles, constraints and tools used were all committed to and agreed upon in the initial stages. A recommendation for the approach is not available, although there is a document where each person reflected on their level of comfort with the different approaches. The context was decently understood in the beginning, we had not fully understood the contraints on the commit format intially. The constraints for the selection, acquisition and use of practices were known from the assignment instructions (language constraints) and implied from the described competencies of everyone in the initial document.

The practices and tools adopted by the team are actively applied in real-world tasks, as agreed upon collectively. Regular reviews ensure their effectiveness, with code commits subject to pre-merge scrutiny. These tools and practices are tailored to fit the team's specific needs, determined through a collaborative decision-making process. Additionally, the team employs procedures, like Discord communication and scheduled meetings, to seek and address feedback, encouraging continuous improvement in the workflow.

We utilized GitHub and Discord for our project management and communications. GitHub was our primary platform for committing tasks and tracking progress, while Discord served as our main channel for discussing questions and clarifications related to the project. All group members were granted access and were admins to both the GitHub repository and the Discord server, enabling them to easily address questions and manage the tasks assigned to them. This accessibility ensured that everyone could contribute effectively to the project.

Every member was actively involved in the project as a whole. We consistently engaged in discussions to evaluate our current methods and the next steps, ensuring that our approach was always evolving to meet the project's needs. Each member adapted their use of Git and work schedules depending on their context and ensuring flexibility, and every deadline was met. The level of comfort with the practices also depended on how comfortable we were with Git. So it might varies a bit from one person to another. But everyone kept on improving and adapting their way of working until the final version.

Statement of contributions

Rémi Grasset: Wrote function LIC12, LIC13 and LIC14 with tests. Reviewed the pull requests during the second half of the project.

Anton Bölenius: Wrote LIC0-2 and additional tests, took initiative in planning and delegation of work in the scheduled meetings. Helped bugfix LIC9-11.

Toto Roomi: Worked on the LIC conditions 3-5 and the launch function, as well as their tests.

Kerem Robin Yurt: Wrote functions: LIC9-11, FUV, and also tests for those. Also wrote the PARAMETERS dictionary.

Marcus Jakobsson: I did the LIC6-8, the circumradius function, PUV and the respective tests for my functions.

To finilize the project everyone collaborated on the README, tests and DECIDE() function, as well as minor bug fixes.

About

Repo for the decide problem of group 26 in software fundamentals course

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages