Software Engineering Body of Knowledge (v3) (2014) (811503), страница 70
Текст из файла (страница 70)
Butusers should be notified if there is anything thatimpedes the smooth execution of the program.Nothing is more frustrating than an unexpectedtermination or behavioral deviation of softwarewithout any warning or explanation. To be userfriendly, the software should report all error conditions to the users or upper-level applicationsso that some measure can be taken to rectify thesituation or to exit gracefully. There are severalguidelines that define what constitutes a gooderror message: error messages should be clear, tothe point, and timely.First, error messages should clearly explainwhat is happening so that users know what isgoing on in the software. Second, error messages should pinpoint the cause of the error, if atall possible, so that proper actions can be taken.Third, error messages should be displayed rightwhen the error condition occurs.
According toJakob Nielsen, “Good error messages should beexpressed in plain language (no codes), preciselyindicate the problem, and constructively suggesta solution” [9*]. Fourth, error messages shouldnot overload the users with too much information and cause them to ignore the messages alltogether.However, messages relating to security accesserrors should not provide extra information thatwould help unauthorized persons break in.15.3. Software RobustnessSoftware robustness refers to the ability of software to tolerate erroneous inputs. Software is saidto be robust if it continues to function even whenerroneous inputs are given.
Thus, it is unacceptable for software to simply crash when encountering an input problem as this may cause unexpected consequences, such as the loss of valuabledata. Software that exhibits such behavior is considered to lack robustness.Nielsen gives a simpler description of softwarerobustness: “The software should have a lowerror rate, so that users make few errors duringthe use of the system and so that if they do makeerrors they can easily recover from them. Further,catastrophic errors must not occur” [9*].There are many ways to evaluate the robustness of software and just as many ways to makesoftware more robust. For example, to improverobustness, one should always check the validityof the inputs and return values before progressing further; one should always throw an exception when something unexpected occurs, andone should never quit a program without firstgiving users/applications a chance to correct thecondition.16. Basic Developer Human Factors[3*, c31–32]Developer human factors refer to the considerations of human factors taken when developingsoftware.
Software is developed by humans, readby humans, and maintained by humans. If anything is wrong, humans are responsible for correcting those wrongs. Thus, it is essential to writesoftware in a way that is easily understandableby humans or, at the very least, by other softwaredevelopers. A program that is easy to read andunderstand exhibits readability.The means to ensure that software meet thisobjective are numerous and range from properarchitecture at the macro level to the particularcoding style and variable usage at the micro level.But the two prominent factors are structure (orprogram layouts) and comments (documentation).13-24 SWEBOK® Guide V3.016.1. StructureWell-structured programs are easier to understandand modify.
If a program is poorly structured, thenno amount of explanation or comments is sufficientto make it understandable. The ways to organize aprogram are numerous and range from the properuse of white space, indentation, and parentheses tonice arrangements of groupings, blank lines, andbraces. Whatever style one chooses, it should beconsistent across the entire program.16.2. CommentsTo most people, programming is coding.
Thesepeople do not realize that programming alsoincludes writing comments and that comments arean integral part of programming. True, commentsare not used by the computer and certainly do notconstitute final instructions for the computer, butthey improve the readability of the programs byexplaining the meaning and logic of the statementsor sections of code. It should be remembered thatprograms are not only meant for computers, theyare also read, written, and modified by humans.The types of comments include repeat of thecode, explanation of the code, marker of thecode, summary of the code, description of thecode’s intent, and information that cannot possibly be expressed by the code itself.
Some comments are good, some are not. The good onesare those that explain the intent of the code andjustify why this code looks the way it does. Thebad ones are repeat of the code and stating irrelevant information. The best comments are selfdocumenting code. If the code is written in such aclear and precise manner that its meaning is selfproclaimed, then no comment is needed.
But thisis easier said than done. Most programs are notself-explanatory and are often hard to read andunderstand if no comments are given.Here are some general guidelines for writinggood comments:• Comments should be consistent across theentire program.• Each function should be associated withcomments that explain the purpose of thefunction and its role in the overall program.• Within a function, comments should begiven for each logical section of coding toexplain the meaning and purpose (intention)of the section.• Comments should stipulate what freedomdoes (or does not) the maintaining programmers have with respect to making changes tothat code.• Comments are seldom required for individual statements.
If a statement needs comments, one should reconsider the statement.17. Secure Software Development andMaintenance[11*, c29]Due to increasing malicious activities targetedat computer systems, security has become a significant issue in the development of software. Inaddition to the usual correctness and reliability,software developers must also pay attention tothe security of the software they develop. Securesoftware development builds security in softwareby following a set of established and/or recommended rules and practices in software development. Secure software maintenance complementssecure software development by ensuring the nosecurity problems are introduced during softwaremaintenance.A generally accepted view concerning softwaresecurity is that it is much better to design securityinto software than to patch it in after software isdeveloped.
To design security into software, onemust take into consideration every stage of the software development lifecycle. In particular, securesoftware development involves software requirements security, software design security, softwareconstruction security, and software testing security. In addition, security must also be taken intoconsideration when performing software maintenance as security faults and loopholes can be andoften are introduced during maintenance.17.1. Software Requirements SecuritySoftware requirements security deals with theclarification and specification of security policyand objectives into software requirements, whichComputing Foundations 13-25lays the foundation for security considerations inthe software development. Factors to considerin this phase include software requirements andthreats/risks.
The former refers to the specificfunctions that are required for the sake of security; the latter refers to the possible ways that thesecurity of software is threatened.17.2. Software Design SecuritySoftware Design security deals with the designof software modules that fit together to meetthe security objectives specified in the securityrequirements. This step clarifies the details ofsecurity considerations and develops the specificsteps for implementation.
Factors consideredmay include frameworks and access modes thatset up the overall security monitoring/enforcement strategies, as well as the individual policyenforcement mechanisms.17.3. Software Construction SecuritySoftware construction security concerns the question of how to write actual programming code forspecific situations such that security considerationsare taken care of. The term “Software ConstructionSecurity” could mean different things for differentpeople. It can mean the way a specific function iscoded, such that the coding itself is secure, or it canmean the coding of security into software.Most people entangle the two together withoutdistinction.
One reason for such entanglement isthat it is not clear how one can make sure that aspecific coding is secure. For example, in C programming language, the expression of i<<1 (shiftthe binary representation of i’s value to the left byone bit) and 2*i (multiply the value of variable iby constant 2) mean the same thing semantically,but do they have the same security ramification?The answer could be different for different combinations of ISAs and compilers. Due to this lackof understanding, software construction security—in its current state of existence—mostlyrefers to the second aspect mentioned above: thecoding of security into software.Coding of security into software can beachieved by following recommended rules. A fewsuch rules follow:• Structure the process so that all sectionsrequiring extra privileges are modules.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
