]
]Functional correctness is usually the most important quality of a system. To achieve functional correctness, we should understand the specification well (we need to know what is the "correct" behavior expected in the first place).
In addition, a system requires to have many non-functional qualities, some explicitly mentioned, some only implied. The nature of the system decides which qualities are more important. Find out the relative importance of each quality, as you might have to sacrifice one to gain another. There are many to choose from such as Analyzability, Adaptability, Changeability, Compatibility, Configurability, Conformance, Efficiency, Fault tolerance, Installability/uninstallability, Interoperability Learnability, Localizability, Maintainability, Portability, Performance, Replaceablity, Reliability, Reusability, Security, Scalability, Stability, Supportability, Testability, Understandability, Usability.
Given next are some common NF qualities and some tips on achieving each.
You need to show that your system can perform without failure for the specified operating environment. If the system is expected to run for a long period, you should ensure that it indeed can. For example, monitor the memory usage while the system is in operation; if it keeps increasing, your system might have a memory leak which will crash it eventually.
Can your system withstand incorrect input? Will it gracefully terminate when pushed beyond the operating conditions for which it was designed? Does it warn the user when approaching the breaking point or simply crash without warning? If you can crash your system by providing wrong input values, then it is not a very robust system.
Maintainability is an important quality to have even if the instructor does not mention it explicitly. This is because you will maintain your code from the moment you write it. You will really regret writing unmaintainable code especially during bug fixing and modifying existing features towards the end of the project.
Maintainability starts with a simple and easy-to-understand design. Following a coding standard (and having other conventions such as naming conventions, standard file organizations etc.) really boost the maintainability.
Complexity of the code hinders maintainability. Limit the length of a method/function (if you cannot see the whole method in one screenshot, then it is probably too long), and the depth of nesting (how many levels is too many?).
A comprehensive suite of automated test cases can detect undesirable ripple effects of a change on the rest of the system. Having such tests indirectly helps maintainability.
Don't speculate; find out. Use appropriate tools (e.g., profilers) to find out where in the system you need to optimize for performance. If you try to optimize the parts that you think might be slow (especially, given your inexperience in the field), you could end up optimizing the wrong part. While you are busy looking for a super fast sorting algorithms, your system could be slow simply because you use Strings instead of StringBuffers.
Don't just claim; prove it. Provide results of performance testing to show how efficient your system is. If your system should be able to handle a million data items, provide evidence of how well it handles a million data items.
Benchmark. You can also consider benchmarking your system against other existing alternatives. You can also benchmark against previous versions of your own system to show how you improved the efficiency of your system over time.
Security is a prime concern for most systems, especially for multi-user systems with open access (such as Internet-based applications). If security is a top priority for your system, make sure you have it built into the system from the very beginning. It is much harder to secure a system built based on an unsecure architecture.
Under this aspect, you can address the following questions:
If you have a lot of duplicate code in your system (some code analyzers can easily find this out for you), you have not reused code well.
Testability does not come by default; some designs are more testable than others. To give a simple example, methods that have return values are easier to test than those that do not. If you give up testing some parts of your system because it is too difficult to test, you have a testability problem. If you have good testability, it is possible to test each part of your system in isolation and with ease. During integration, a system with good testability can be tested at each stage of the integration, integrating one component at a time.
How well can your system handle bigger loads (bigger input/output, more concurrent users, etc.)? Is the drop in performance (if any) reasonably reflect the increase in workload?
How easily can you change a certain aspect of your system? For example, can you change the database vendor or the storage medium (say, from a relational database to a file-based system) without affecting the rest of the system? Can you replace a certain algorithm in your system by replacing a component?
How easily can can you extend your system (to handle other types of input, do other types of processing, etc.)? For example, can you add functionality by simply plugging in more code, or do you need extensive changes to existing code to add functionality?
Does the usability of your system match the target user base? Is the operation intuitive to the target user base? Have you produced good user manuals? Does your system let users accomplish things with a minimal number of steps?
Most grading schemes have some amount of marks allocated for each NF quality. Unfortunately, not all NF qualities are easily visible during a product demo. Be sure to talk about them during the presentation, and in the report.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.9, Jan 2009, Copyrights: Damith C. Rajapakse |---