H AMMITEC* συνέταξε ένα δεκαπεντάλογο οδηγιών για το ποιοτικό software, επαναφέροντας στο προσκήνιο ένα χρόνιο προβληματισμό των μελών της, επιχειρώντας με αυτό τον τρόπο να πείσει όλους τους εμπλεκόμενους ότι υπάρχει επιτακτική ανάγκη να γίνουν βελτιώσεις στο ναυτιλιακό software.
To σχετικό έργο υλοποιήθηκε από την εσωτερική ομάδα εργασίας “Software Quality” της AMMITEC, η οποία αποτελείται από μέλη της και στελέχη ΙΤ ναυτιλιακών εταιρειών, μετά από προσπάθειες και συναντήσεις αρκετών μηνών. Στόχος της AMMITEC είναι να δημιουργήσει ένα ανοικτό δίαυλο επικοινωνίας ανάμεσα στους vendors και τις ναυτιλιακές εταιρείες, o oποίος θα συμβάλει ώστε να γίνει το ναυτιλιακό software περισσότερο ποιοτικό, ασφαλές, αποτελεσματικό, αξιόπιστο και πιο εύκολα διαχειρίσιμο από τους ναυτικούς (οι οποίοι σήμερα έχουν πολύ μεγάλο φόρτο εργασίας).
Η ΑΜΜΙΤΕC δίνει μεγάλη βαρύτητα, επίσης, στην ασφάλεια του παρεχόμενου λογισμικού, λαμβάνοντας υπόψη τα σημαντικά προβλήματα που έχουν προκύψει από τα cyber attacks που έχουν κτυπήσει το χώρο το τελευταίο διάστημα. Ο δεκαπεντάλογος ποιοτικού software της AMMITEC συντάχθηκε βάσει των ISO Software Quality Standards (ISO/IEC 25051:2014), διαχειρίζεται την ποιότητα των «έτοιμων προς χρήση προϊόντων λογισμικού» και καλύπτει τους περισσότερους τύπους ναυτιλιακού software.
* Η ΑΜΜΙΤΕC αποτελεί ένα μη κερδοσκοπικό επιστημονικό οργανισμό που ενώνει υπό την σκέπη της τους ICT Managers των διεθνών ναυτιλιακών εταιρειών, αλλά και οποιονδήποτε άλλο εμπλέκεται στον τομέα της Πληροφορικής και Επικοινωνιών στη ναυτιλία.
Aκολουθεί ο δεκαπεντάλογος της AMMITEC (στα αγγλικά, όπως έχει συνταχθεί από την ομάδα εργασίας Software Quality της AMMITEC).
1. User’s Forum: We request the immediate implementation of a FORUM on the developer’s official site. The Forum must be at the disposal of all Registered Users and allow the dialogue between the users. It should also allow the upload of screenshots and videos, accompanied by suggestions for improvements or solutions to well documented problems.
2. Functionality and Correctness: Functionality and correctness, is the conformity of the software with actual requirements and specifications. When/if the software is tested against the specifications given by the vendor, it should be found in full agreement with them. In case of disagreement, the vendor is required to fully comply with the specifications.
3. Help should be:
a. Online (for fast access). It usually contains the manual.
b. Context sensitive (for precise help on the topic the user is currently interested in).
c. User Editable (allows the user to add personal notes).
d. Should contain FAQs, pictures, diagrams & video.
e. A Tutorial (or a CBT or a Demo) should be available for each application. Absolutely necessary for Vessel Applications.
Good support is essential to a good user experience. Effective support should have the following characteristics:
a. Continuously improve user’s interface and documentation, based on customer feedback
b. Continuously improve the FAQs List and publish them.
c. Customers should be encouraged to look at documentation: Help, FAQs, Forum etc. before calling support.
4. Usability and Accessibility: Usability is the degree to which software can be used by specified users to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use. User interfaces are the only visible parts of software according to the viewpoint of the user. So, simplicity, taking less time to complete a job and fast learnability are very important. In short, principles like “Don’t Make me Think” & ”Don’t Make me Click” should be the guiding principles of the user interface.
5. Effective error/bug handling: When a program comes across an error, it should make the error known using Plain English language. No jargon is allowed. The program should provide the user with a Screen Capture utility which includes the user’s description of the problem and notifies both the developer and the shore office. Recovery from Errors is an extremely important characteristic of software (especially for vessel software), and it should try it’s best to guide users to recover fast from errors without the need for human intervention.
6.Proper Documentation/ Manuals: Typically, the user documentation describes each feature of the program, and assists the user in realizing these features. A good user manual should go so far as to provide thorough troubleshooting assistance. It is very important for user manuals not to be confusing, and be kept up to date. User documents need not be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable.
User documentation is considered to constitute a contract specifying what the software will do.
However, there are two broad ways in which user documentation can be organized:
a. Tutorial: A tutorial approach is considered the most useful for a new user, in which they are guided through each step of accomplishing particular tasks. An absolute necessity for vessel applications.
b. Task Oriented: The manual must explain how a certain Task is accomplished. The format should be «If you want to achieve “THIS” then “DO THAT” ». An Index of Tasks is also necessary. This is important especially if a Task involves a large sequence of clicks and is not part of a menu. Usually Tasks are explained during the Training, but few users can memorize them.
7. Performance and Efficiency: Performance is mostly about response time of the software. This response time should be within acceptable user limits (e.g. max. a few seconds), and should not increase if transaction load increases. Efficiency must be supported with resource utilization. Optimal source/performance ratio must be aimed.
8. Scalability and reliability: A scalable system responds to user actions in an acceptable amount of time, even when load increases (e.g. number of users, amount of data, etc.). Reliability also stands for the integrity and consistency of the software even under high load conditions. The vendor should provide proof of this capability.
9. Flexibility and Extensibility: Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Extensibility is the ability of software to add functionality without damaging system, so it may be thought as a subset of flexibility. The vendor should provide proof of this capability.
10. Customization and configuration:
Configuration is the normal set-up of the software, such as parameters/user preferences, layout and naming of fields, and workflows. They are user defined and since they do not require changes to the source code, they form a good feature of a program.
Customization, on the other hand, requires changes to the source code and usually implies deviations from the official specification in order to meet additional/different requirements of a company. The problem usually is that customizations are performed under heavy pressure and in short time limits that affect badly the quality of the code and leads to problems with configuration.
Try to reduce Customization with built-in flexible Configuration.
11.Installation is easy and is all inclusive: Installation on a vessel should be a well prepared and organized job. It should be possible to be carried out by a crew member in most cases and the installation package should include everything that is required (for example, no external libraries or DLLs should be required).
12.Version control and formal user update: Users should be updated as soon as new software release is installed. A description of all the changes must be supplied and the e-manuals must be updated asap. A detailed Log of changes is kept by the developer and the IT Manager. All upgrades should be first implemented in a test environment, tested and once accepted, migrated to the “live” environment.
13. Security: the data exchanged via email or other non-encrypted way between Vessel and Office, must be encrypted. Direct access to the Database must obey the Security Laws of each company. Data exchanged via a VPN channel, is considered secure at the moment. The software must meet the password complexity best practices, i.e. password complexity, password frequent changes etc.
14. Communications between Vendor and Client: Clear-cut instructions should be set by the Vendor describing the methods of communications whenever any support is needed (i.e. points of contacts for all modules from both the client and the vendor). Set procedures should be followed from both parties else control and monitoring will be lost, as anyone will be able to contact whoever they believe is appropriate. The Vendor should also comply with client’s communications policies (e.g. who is allowed to submit tickets, communication language should be that of the Client, etc.).
15.SLA: SLAs should be clear and penalties should be stated when commitments are not met. Contracts: Pricing and support agreement policies should be very clear. Special attention should be given to pricing schemes during systems updates and versions upgrades.