722.3 Evaluation criteria for tool selection

Choose tools based on their merit, not just popularity.

Overview

Selecting a tool or technology for a software project is not simply a matter of personal preference. Software engineers must evaluate options based on how well each tool aligns with project goals, technical constraints, and user needs. In this section, you will learn how to justify your technology choices using structured evaluation criteria. These criteria will be used to support the rationale in your System Design Specification (SDS).

Even though all students are using a standard tech stack—HTML, CSS, JavaScript, Flask, and SQLite—you are expected to reflect on how these tools specifically support the design and implementation of your solution.

Evaluation table: Template

Use the table below to evaluate each major tool in your project. You may adapt or extend it to suit your documentation style.

Tool / Technology	Function in Project	Strengths	Limitations / Trade-offs	Why it's appropriate
HTML / CSS	Build user interface and page layout	Universally supported, easy to style and customise	Requires manual handling of responsive design unless using frameworks	Gives full control over UI, simple to learn and maintain
JavaScript	Add interactivity and handle client-side validation	Runs in browser, excellent for dynamic feedback	Can become complex if not modularised well	Enables responsive UX and supports validation before sending data
Flask (Python)	Process requests and render dynamic content	Lightweight, flexible, integrates with Python	Not suited for very large-scale systems	Ideal for single-developer projects with custom routing needs
SQLite	Store and retrieve persistent data	Lightweight, no server setup, SQL-compatible	File-based storage, not for high concurrency	Perfect for local development and prototyping
Codio	Development environment	Accessible anywhere, Git integration, browser-based preview	Requires setup for Flask apps and terminal use	Supports full-stack development in a school setting

Sample criteria for evaluation

Use these when completing your evaluation table and writing your justification:

• Suitability for purpose – Does the tool directly support the required functionality?

• Ease of use / learning curve – Can you use it efficiently within the project timeframe?

• Community support – Is documentation or help readily available online?

• Compatibility – Does it work well with other parts of the stack (e.g. Flask + SQLite)?

• Performance – Does it handle the expected scale of data and users?

• Security – Are there built-in features or best practices for safe handling of user data?

• Maintainability – Will the codebase be easy to modify, test, and extend?

• Licensing / availability – Is it open-source or freely available to use?

How to use this in your SDS

Each technology listed in your SDS should be accompanied by a concise written justification, drawing on the above evaluation. Avoid vague language like "I just like it" or "It’s easy" without explaining why.

Example: I chose Flask because it supports flexible route handling and integrates well with Python, which I am already comfortable using. It also works smoothly with SQLite for local data storage, making it suitable for a solo project that doesn’t need enterprise-scale infrastructure.

Resources

In your System Design Specification (SDS), you must justify each tool and technology used in your project. This section provides a model response, illustrating how to craft a concise and well-structured justification that reflects your understanding of the system requirements and development process.

The example below is written in a manner that would be suitable for inclusion in the SDS, specifically under the 'Tool selection and justification' section.

Tool justification example for the Secure Bug Tracker project

Front-end (HTML, CSS, JavaScript)

The front-end of the application is built using standard web technologies. HTML provides a semantic structure for each page, allowing users to navigate and interact with the interface. CSS is used to ensure a consistent and responsive design that is accessible across devices, while JavaScript enables client-side validation and dynamic behaviour, such as form handling and updating elements without reloading the page. These technologies are universally supported, require no installation for users, and can be tested directly in the browser or Codio’s live preview. This makes them suitable for a solo project where cross-platform accessibility is essential.

Back-end (Flask - Python)

Flask is used as the back-end framework to handle routing, session management, and integration with the SQLite database. Flask is lightweight, easy to customise, and integrates well with Python, a language I am confident using. Its use of Jinja2 templates allows dynamic HTML rendering without introducing complexity. Flask’s flexibility allows me to structure the application clearly and scale it incrementally as features are added. Codio supports Flask development natively, making setup and deployment straightforward within the school’s infrastructure.

Database (SQLite)

SQLite is a file-based relational database that meets the requirements of this project. It enables me to store bug reports, user credentials, and comments without requiring a separate server process. As the project is expected to have a small dataset and limited concurrent access, SQLite offers a perfect balance between simplicity and functionality. It supports standard SQL queries, helping me develop portable and transferable skills. Codio allows me to inspect and manage SQLite databases directly from the terminal.

Development environment (Codio)

Codio is used as the central development platform. It provides an in-browser IDE with full terminal access, support for Python and Flask, and integration with Git and GitHub. The consistent environment ensures I can develop, test, and debug across all layers of the stack in one place. Codio also simplifies package management and virtual environment setup, removing barriers to getting started with Flask and SQLite.

Version control (Git and GitHub) Git is used for local version control, with all commits pushed to a private GitHub repository. This enables me to document development progress, track changes, and revert to previous versions when necessary. GitHub also enables issue tracking and documentation through a README file and a project board. Version control is essential for maintaining an organised and traceable development process, particularly when iterating or debugging. Git and GitHub are fully supported in Codio, with workflows aligned to industry standards.