Software Engineering Body of Knowledge (v3) (2014) (811503), страница 17
Текст из файла (страница 17)
In somescripting languages, scripts are called batch filesor macros.Programming languages are the most flexibletype of construction languages. They also containthe least amount of information about specificapplication areas and development processes—therefore, they require the most training and skillto use effectively.
The choice of programming language can have a large effect on the likelihood ofvulnerabilities being introduced during coding—for example, uncritical usage of C and C++ arequestionable choices from a security viewpoint.There are three general kinds of notation usedfor programming languages, namely• linguistic (e.g., C/C++, Java)• formal (e.g., Event-B)• visual (e.g., MatLab).Linguistic notations are distinguished in particular by the use of textual strings to representcomplex software constructions. The combination of textual strings into patterns may have asentence-like syntax.
Properly used, each suchstring should have a strong semantic connotationproviding an immediate intuitive understandingof what will happen when the software construction is executed.Formal notations rely less on intuitive, everyday meanings of words and text strings and moreon definitions backed up by precise, unambiguous, and formal (or mathematical) definitions.Formal construction notations and formal methods are at the semantic base of most forms of3-6 SWEBOK® Guide V3.0system programming notations, where accuracy,time behavior, and testability are more importantthan ease of mapping into natural language.
Formal constructions also use precisely defined waysof combining symbols that avoid the ambiguityof many natural language constructions.Visual notations rely much less on the textualnotations of linguistic and formal constructionand instead rely on direct visual interpretationand placement of visual entities that represent theunderlying software. Visual construction tends tobe somewhat limited by the difficulty of making“complex” statements using only the arrangement of icons on a display. However, these iconscan be powerful tools in cases where the primaryprogramming task is simply to build and “adjust”a visual interface to a program, the detailedbehavior of which has an underlying definition.3.3. Coding[1*]The following considerations apply to the software construction coding activity:• Techniques for creating understandablesource code, including naming conventionsand source code layout;• Use of classes, enumerated types, variables,named constants, and other similar entities;• Use of control structures;• Handling of error conditions—both anticipated and exceptional (input of bad data, forexample);• Prevention of code-level security breaches(buffer overflows or array index bounds, forexample);• Resource usage via use of exclusion mechanisms and discipline in accessing seriallyreusable resources (including threads anddatabase locks);• Source code organization (into statements, routines, classes, packages, or otherstructures);• Code documentation;• Code tuning,3.4. Construction Testing[1*]Construction involves two forms of testing,which are often performed by the software engineer who wrote the code:• Unit testing• Integration testing.The purpose of construction testing is to reducethe gap between the time when faults are insertedinto the code and the time when those faults aredetected, thereby reducing the cost incurred tofix them.
In some instances, test cases are written after code has been written. In other instances,test cases may be created before code is written.Construction testing typically involves asubset of the various types of testing, whichare described in the Software Testing KA. Forinstance, construction testing does not typicallyinclude system testing, alpha testing, beta testing,stress testing, configuration testing, usability testing, or other more specialized kinds of testing.Two standards have been published on the topicof construction testing: IEEE Standard 829-1998,IEEE Standard for Software Test Documentation,and IEEE Standard 1008-1987, IEEE Standardfor Software Unit Testing.(See sections 2.1.1., Unit Testing, and 2.1.2.,Integration Testing, in the Software Testing KAfor more specialized reference material.)3.5. Construction for Reuse[2*]Construction for reuse creates software that hasthe potential to be reused in the future for thepresent project or other projects taking a broadbased, multisystem perspective.
Construction forreuse is usually based on variability analysis anddesign. To avoid the problem of code clones, itis desired to encapsulate reusable code fragmentsinto well-structured libraries or components.The tasks related to software construction forreuse during coding and testing are as follows:Software Construction 3-7• Variability implementation with mechanisms such as parameterization, conditionalcompilation, design patterns, and so forth.• Variability encapsulation to make the software assets easy to configure and customize.• Testing the variability provided by the reusable software assets.• Description and publication of reusable software assets.3.6. Construction with Reuse[2*]Construction with reuse means to create newsoftware with the reuse of existing softwareassets.
The most popular method of reuse is toreuse code from the libraries provided by the language, platform, tools being used, or an organizational repository. Asides from these, the applications developed today widely make use of manyopen-source libraries. Reused and off-the-shelfsoftware often have the same—or better—qualityrequirements as newly developed software (forexample, security level).The tasks related to software construction withreuse during coding and testing are as follows:• The selection of the reusable units, databases, test procedures, or test data.• The evaluation of code or test reusability.• The integration of reusable software assetsinto the current software.• The reporting of reuse information on newcode, test procedures, or test data.3.7. Construction Quality[1*]In addition to faults resulting from requirementsand design, faults introduced during constructioncan result in serious quality problems—for example, security vulnerabilities. This includes notonly faults in security functionality but also faultselsewhere that allow bypassing of this functionality and other security weaknesses or violations.Numerous techniques exist to ensure the quality of code as it is constructed.
The primary techniques used for construction quality include• unit testing and integration testing (see section 3.4, Construction Testing)• test-first development (see section 2.2 in theSoftware Testing KA)• use of assertions and defensive programming• debugging• inspections• technical reviews, including security-oriented reviews (see section 2.3.2 in the Software Quality KA)• static analysis (see section 2.3 of the Software Quality KA)The specific technique or techniques selecteddepend on the nature of the software being constructed as well as on the skillset of the softwareengineers performing the construction activities.
Programmers should know good practicesand common vulnerabilities—for example, fromwidely recognized lists about common vulnerabilities. Automated static analysis of code forsecurity weaknesses is available for several common programming languages and can be used insecurity-critical projects.Construction quality activities are differentiated from other quality activities by their focus.Construction quality activities focus on code andartifacts that are closely related to code—suchas detailed design—as opposed to other artifactsthat are less directly connected to the code, suchas requirements, high-level designs, and plans.3.8. Integration[1*]A key activity during construction is the integration of individually constructed routines, classes,components, and subsystems into a single system.
In addition, a particular software systemmay need to be integrated with other software orhardware systems.Concerns related to construction integrationinclude planning the sequence in which components will be integrated, identifying what hardware is needed, creating scaffolding to supportinterim versions of the software, determiningthe degree of testing and quality work performedon components before they are integrated, and3-8 SWEBOK® Guide V3.0determining points in the project at which interimversions of the software are tested.Programs can be integrated by means of eitherthe phased or the incremental approach.
Phasedintegration, also called “big bang” integration,entails delaying the integration of componentsoftware parts until all parts intended for releasein a version are complete. Incremental integrationis thought to offer many advantages over the traditional phased integration—for example, easiererror location, improved progress monitoring,earlier product delivery, and improved customerrelations. In incremental integration, the developers write and test a program in small pieces andthen combine the pieces one at a time.
Additionaltest infrastructure, such as stubs, drivers, andmock objects, are usually needed to enable incremental integration. By building and integratingone unit at a time (for example, a class or component), the construction process can provide earlyfeedback to developers and customers.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
