search

damiwee / pe

0 stars 0 forks source link

Developer guide: non functional requirements/ glossary missing OS requirements #14

Open damiwee opened 4 weeks ago

damiwee commented 4 weeks ago

Perhaps consider mentioning the OS requirements.

image.png

image.png

nus-se-script commented 3 weeks ago

Team's Response

It is a given that Java can run anywhere.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Including operating system (OS) requirements in a developer guide is essential for several reasons:

  1. Compatibility: Developers need to know which operating systems are supported by the software they are developing. This information ensures that the software will function correctly on the intended platforms and avoids compatibility issues that may arise if the software is deployed on unsupported or incompatible operating systems.

  2. Development Environment Setup: Operating system requirements provide developers with guidance on setting up their development environment. Different operating systems may require different tools, libraries, or configurations to develop and build the software successfully. Including OS requirements helps developers ensure they have the necessary environment to work effectively.

  3. Testing and Quality Assurance: Knowing the supported operating systems allows developers to plan and execute comprehensive testing procedures. They can verify that the software functions as expected on each supported OS and identify any platform-specific issues that need to be addressed. This helps maintain the overall quality and reliability of the software across different environments.

In response to your comment "Java can run anywhere", while Java's "write once, run anywhere" principle is generally true and has been a key advantage of the language, there are some instances where it may not hold entirely true:

  1. Platform-Specific Features: Java's core libraries provide cross-platform functionality, but certain platform-specific features may not be fully supported across all environments. Applications relying heavily on platform-specific functionality may encounter limitations when running on certain platforms.

  2. Performance Variations: While Java's bytecode is platform-independent, the performance of Java applications can vary across different platforms and JVM implementations. Factors such as JVM optimizations, hardware capabilities, and underlying operating system performance can affect the runtime performance of Java applications.

  3. Embedded Systems: In some embedded systems or specialized environments with limited resources, a full JVM implementation may not be feasible or practical. In such cases, alternative runtime environments or optimizations may be required, limiting Java's ability to run seamlessly everywhere.

  4. Native Integration: Java applications may require interaction with native code or system libraries, which can introduce platform dependencies. While Java provides mechanisms for native integration (e.g., JNI), managing platform-specific dependencies and ensuring compatibility across different platforms can be challenging.

  5. Security Restrictions: Some platforms or environments may impose security restrictions that limit the execution of Java applications or restrict certain Java features. Adhering to security policies and permissions across different platforms may impact Java's ability to run without constraints.

Overall, while Java's platform independence allows it to run on a wide range of devices and operating systems, there are nuances and considerations to be aware of, particularly in cases involving platform-specific features, performance optimizations, resource-constrained environments, native integration, and security restrictions.

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** This is not a cosmetic issue. Within the context of this course, it is generally understood to use Java 11 and most mainstream OS should work. However, external developers may not have knowledge of this and this can cause them great inconvenience when trying to set up their development environment. As such, after further consideration, I would argue to raise the severity label to medium from my initial low severity label. ![image.png](https://raw.githubusercontent.com/damiwee/pe/main/files/d7e7aca3-bec7-4df8-ad35-0547bb2c585f.png)