iP:
Level-10
tP:
Level-10
Level-10
: Add a GUI Add a GUI to Duke. Use the JavaFX technology to implement the GUI.
Refer to the JavaFX tutorial @SE-EDU/guides to learn how to get started with JavaFX.
There are two non-trivial steps to take here:
You are cautioned against trying to do both in one go. Instead, complete the JavaFX tutorial as a separate project before adding a GUI to Duke.
.jar
file is smaller than 10MB, most likely JavaFX libraries are not inside it.As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the decision of the project direction.
Admin tP: Expectations
project expectations
The high-level learning outcome of the team project (tP):
Accordingly, the tP is structured to resemble an intermediate stage of a non-trivial real-life brownfield software project in which you will,
The focus of the tP is to learn the following aspects:
TIC4001 vs TIC4002
TIC4002 focuses on aspect 6 in particular, as TIC4001 already covered 2-5 above (but you should improve on the 2-5 in this module as well).
The tP uses a generic application called AddressBook-Level3 (AB3) (from https://se-education.org) as the starting point.
You may develop any product provided it is meant for users who can type fast, and prefer typing over mouse/voice commands. Therefore, Command Line Interface (CLI) is the primary mode of input.
Admin tP Contstraints → Constraint-Typing-Preferred
Admin tP Contstraints → Recommendation-CLI-First
Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via CLI, compared to a hypothetical GUI-only version of the app. For example, adding a new entity via the CLI should be faster than entering the same data through a GUI form.
Therefore, the input to the app needs to be primarily CLI. The GUI is used primarily to give visual feedback to the user. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users. Therefore, give CLI alternatives to mouse/GUI inputs, if applicable.
Also keep in mind:
Weigh the pros/cons and choose the one that suits you. Note that creating a novel/unique/interesting product will NOT earn you extra marks in this module. While those qualities are important in real world projects, and we do allow you room to go in those directions in this module, they are not the focus of this module
You are allowed to reuse the project idea/code from TIC4001, as long as it fits the TIC4002 requirements/constraints.
You are expected to:
Why the need to narrow down the user profile?
How narrow can we make the target market?
The size of the target market is not a grading criterion. You can make it as narrow as you want. Even a single user target market is fine as long as you can define that single user in a way others can understand (reason: project evaluators need to evaluate the project from the point of view of the target users).
Example 1: If the product targets TIC4002 instructors, there can be features that are applicable to them only, such as the ability to see a link to a student's project on GitHub
Example 2: If your app manages contacts, you can optimize its features based on,
Your project will be graded based on how well the features match the target user profile and how well the features fit-together.
The expected level of functionality to be added by a 5-person team is roughly the equivalent effort taken to create AB3 functionality. Furthermore, we expect a team to reach that level if each member puts in an effort equivalent to the effort they put into the iP. So, if the question is "If our team do x, y, and z, is that enough?", the answer is "Yes, if it requires each member to put in about an iP worth of effort". Some examples likely to meet that criterion:
You will get full marks for implementation effort if you meet the expectation stated above. There are no extra marks for exceeding that bar. You are better off spending that effort in improving other aspects of the project. Try to avoid adding more features than necessary, unless you are doing it out of interest. As mentioned elsewhere, a functionality just the right size and of high quality will earn more marks than a functionality bigger (or more difficult, or more interesting/novel) but of lower quality.
If you wish to add the following features to your app, we recommend (but not require) you to follow similar features in AB4 in order to reduce the effort required.
Some examples:
Example enhancements
Tip: Contribute to all aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. Reason: If you limit yourself to certain aspects only, you could lose marks allocated for the aspects you did not do. In addition, the final exam assumes that you are familiar with all aspects of the project.
Tip: Do all the work related to your enhancement yourself. Reason: If there is no clear division of who did which enhancement, it will be difficult to divide project credit (or assign responsibility for bugs detected by testers) later.
In other words, we recommend that the work to be divided primarily based on features rather than components. The latter has the risk of a team member becoming a single point of failure and you becoming too reliant on other team members e.g., what if the person assigned to an important component doesn't deliver on time?.
🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.
Team-tasks are the tasks that someone in the team has to do.
Examples of team-tasks
Here is a non-exhaustive list of team-tasks:
Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.
Recommended roles and responsibilities
This is a non-exhaustive list; you may define additional roles.
Model
, UI
, Storage
, etc. Note that being in charge of a component doesn't mean you are the only one who should be modifying that component. Rather, you are the one who's expected to, know that component best, review changes done to that component in v1.3-v1.4, act as the gate keeper of its quality, help others when they face difficulties while modifying that component etc.Ensure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it. Reason: when everyone is responsible for everything, no one is.
Admin tP: Constraints
Your project should comply with the following constraints. Reason: to increase comparability among projects and to maximize applicability of module learning outcomes in the project.
The final product should be a result of evolving/enhancing/morphing the given code base. However, you are allowed to replace all existing code with new code, as long as it is done incrementally. e.g. done in small steps, each producing a working product
Reason: To simulate a brownfield project.
The product should be targeting users who can type fast and prefer typing over other means of input.
Reason: to increase comparability of products, and to make feature evaluation easier for peer evaluators.
The product should be for a single user i.e. (not a multi-user product).
Reason: multi-user systems are hard to test, which is unfair for peer testers who will be graded based on the number of bugs they find.
The product needs to be developed in a breadth-first incremental manner over the project duration. While it is fine to do less in some weeks and more in other weeks, a reasonably consistent delivery rate is expected. For example, it is not acceptable to do the entire project over the recess week and do almost nothing for the remainder of the semester.
Reasons: 1. To simulate a real project where you have to work on a code base over a long period, possibly with breaks in the middle. 2. To learn how to deliver big features in small increments.
The data should be stored locally and should be in a human editable text file.
Reason: To allow advanced users to manipulate the data by editing the data file.
Do not use a Database Management System e.g., MySQLDBMS to store data.
Reason: Using a DBMS to store data will reduce the room to apply OOP techniques to manage data. It is true that most real world systems use a DBMS, but given the small size of this project, we
need to optimize it for TIC4002
module learning outcomes; covering DBMS-related topics will have to be left to database modules or level 3 project modules.
The software should follow the Object-oriented paradigm primarily (but you are allowed to mix in a bit other styles when justifiable).
Reason: For you to practice using OOP in a non-trivial project.
The software should work on the Windows, Linux, and OS-X platforms. Even if you are unable to manually test the app on all three platforms, deliberately avoid using OS-dependent libraries and OS-specific features.
Reason: Peer testers should be able to use any of these platforms.
The software should work on a computer that has version 11 of Java i.e., no other Java version installed.
The software should work without requiring an installer.
Reason: Testers may not want to install your product on their computer.
The software should not depend on your own remote server.
Reason: Anyone should be able to use/test your app any time, even after the semester is over.
The use of third-party frameworks/libraries is allowed but only if they,
and is subjected to prior approval by the teaching team.
Reason: We will not allow third-party software that can interfere with the learning objectives of the module.
Please post in the forum your request to use a third-party libraries before you start using the library. Once a specific library has been approved for one team, other teams may use it without requesting permission again.
Reason: The whole class should know which external software are used by others so that they can do the same if they wish to.
Package everything into a single JAR file.
Reason: Requiring the users to download more files can cause complications in the final peer testing session.
If you are unable to package everything into a JAR file, package the JAR file and other files needed into a single zip file.
The file sizes of the deliverables should not exceed the limits given below.
Reason: It is hard to download big files during the practical exam due to limited WiFi bandwidth at the venue:
Product (i.e., the JAR/ZIP file): 100MB (Some third-party software -- e.g., Stanford NLP library, certain graphics libraries -- can cause you to exceed this limit)
Documents (i.e., PDF files): 15MB/file (Not following the recommended method of converting to PDF format can cause big PDF files. Another cause is using unnecessarily high resolution images for screenshots).
The DG and UG should be PDF-friendly. Don't use expandable panels, embedded videos, animated GIFs etc.
Reason: The UG and DG used in the final grading will be in PDF format:
In addition, you are strongly encouraged to follow these recommendations as they can help increase your project score.
It is OK to use a reliable public API e.g., Google search but we recommend that you have a fallback mechanism (e.g., able to load data using a data file if the network is down).
Reason: During the mass peer-testing session, the network access can be intermittent due to high load. If your feature cannot be tested due to lack of Internet, that will have to be counted as a major bug, to be fair to those whose app is being tested and bugs found being penalized.
If you use NUS data (e.g., scrape data from an NUS website), please work with NUS IT directly to get their approval first. Even well-intentioned use of NUS data without approval can get you into serious trouble (has happened before). The teaching team will not be able to get approval for you as the use of NUS data is not a module requirement.
Avoid implementing hard-to-test (both for manual testing as well as automated testing) features or features that make your product hard-to-test.
Reason: testability is a grading criterion. If you choose to implement such a feature, you will need to spend an extra effort to reach an acceptable level of testability.
Here are some examples of features that are hard-to-test:
Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via CLI, compared to a hypothetical GUI-only version of the app. For example, adding a new entity via the CLI should be faster than entering the same data through a GUI form.
Therefore, the input to the app needs to be primarily CLI. The GUI is used primarily to give visual feedback to the user. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users. Therefore, give CLI alternatives to mouse/GUI inputs, if applicable.
Also keep in mind:
If you are not sure if your product complies with a certain constraint/recommendation, please seek clarification by posting in the forum (preferred) or emailing the supervisor.
Admin tP: Grading → Criteria Used for Grading the Product Design
Evaluates:
Evaluated by:
Admin tP → PE → Grading Instructions for Product Design
Evaluate based on the User Guide and the actual product behavior.
Criterion | Unable to judge | Low | Medium | High |
---|---|---|---|---|
target user |
Not specified | Clearly specified and narrowed down appropriately | ||
value proposition |
Not specified | The value to target user is low. App is not worth using | Some small group of target users might find the app worth using | Most of the target users are likely to find the app worth using |
optimized for target user |
Not enough focus for CLI users | Mostly CLI-based, but cumbersome to use most of the time | Feels like a fast typist can be more productive with the app, compared to an equivalent GUI app without a CLI | |
feature-fit |
Many of the features don't fit with others | Most features fit together but a few may be possible misfits | All features fit together to for a cohesive whole |
In addition, feature flaws reported in the PE will be considered when grading this aspect.
Note that 'product design' or 'functionality' are not critical learning outcomes of the tP. Therefore, the bar you need to reach to get full marks will be quite low. For example, the Medium
level in the rubric given in the panel above should be enough to achieve full marks. Similarly, only cases of excessive 'feature flaw' bugs will affect the score.
These are considered feature flaws:
The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
Hard-to-test features
Features that don't fit well with the product
Features that are not optimized enough for fast-typists or target users