Software Engineering Body of Knowledge (v3) (2014) (811503), страница 46
Текст из файла (страница 46)
This topic is related to the Formal Analysis section in the Software Requirements KA.This section addresses specification languages,program refinement and derivation, formal verification, and logical inference.• Specification Languages: Specificationlanguages provide the mathematical basisfor a formal method; specification languages are formal, higher level computerlanguages (in other words, not a classic3rd Generation Language (3GL) programming language) used during the softwarespecification, requirements analysis, and/or design stages to describe specific input/output behavior.
Specification languages arenot directly executable languages; they are9-8 SWEBOK® Guide V3.0typically comprised of a notation and syntax,semantics for use of the notation, and a set ofallowed relations for objects.• Program Refinement and Derivation: Program refinement is the process of creating alower level (or more detailed) specificationusing a series of transformations. It is throughsuccessive transformations that the softwareengineer derives an executable representationof a program.
Specifications may be refined,adding details until the model can be formulated in a 3GL programming language or inan executable portion of the chosen specification language. This specification refinement ismade possible by defining specifications withprecise semantic properties; the specificationsmust set out not only the relationships betweenentities but also the exact runtime meanings ofthose relationships and operations.• Formal Verification: Model checking isa formal verification method; it typicallyinvolves performing a state-space exploration or reachability analysis to demonstratethat the represented software design has orpreserves certain model properties of interest. An example of model checking is ananalysis that verifies correct program behavior under all possible interleaving of event ormessage arrivals. The use of formal verification requires a rigorously specified modelof the software and its operational environment; this model often takes the form of afinite state machine or other formally definedautomaton.• Logical Inference: Logical inference is amethod of designing software that involvesspecifying preconditions and postconditionsaround each significant block of the design,and—using mathematical logic—developingthe proof that those preconditions and postconditions must hold under all inputs.
Thisprovides a way for the software engineer topredict software behavior without havingto execute the software. Some IntegratedDevelopment Environments (IDEs) includeways to represent these proofs along with thedesign or code.4.3. Prototyping Methods[1*, c12s2] [3*, c2s3.1] [6*, c7s3p5]Software prototyping is an activity that generallycreates incomplete or minimally functional versions of a software application, usually for trying out specific new features, soliciting feedbackon software requirements or user interfaces, further exploring software requirements, softwaredesign, or implementation options, and/or gainingsome other useful insight into the software.
Thesoftware engineer selects a prototyping method tounderstand the least understood aspects or components of the software first; this approach is incontrast with other software engineering methodsthat usually begin development with the mostunderstood portions first. Typically, the prototyped product does not become the final softwareproduct without extensive development reworkor refactoring.This section discusses prototyping styles, targets, and evaluation techniques in brief.• Prototyping Style: This addresses the variousapproaches to developing prototypes. Prototypes can be developed as throwaway codeor paper products, as an evolution of a working design, or as an executable specification.Different prototyping life cycle processes aretypically used for each style. The style chosen is based on the type of results the projectneeds, the quality of the results needed, andthe urgency of the results.• Prototyping Target: The target of the prototype activity is the specific product beingserved by the prototyping effort.
Examplesof prototyping targets include a requirementsspecification, an architectural design elementor component, an algorithm, or a humanmachine user interface.• Prototyping Evaluation Techniques: A prototype may be used or evaluated in a number of ways by the software engineer orother project stakeholders, driven primarilyby the underlying reasons that led to prototype development in the first place. Prototypes may be evaluated or tested againstthe actual implemented software or againstSoftware Engineering Models and Methods 9-9a target set of requirements (for example, arequirements prototype); the prototype mayalso serve as a model for a future softwaredevelopment effort (for example, as in a userinterface specification).4.4. Agile Methods[3*, c3] [6*, c7s3p7] [7*, c6, App.
A]Agile methods were born in the 1990s from theneed to reduce the apparent large overhead associated with heavyweight, plan-based methods usedin large-scale software-development projects.Agile methods are considered lightweight methods in that they are characterized by short, iterative development cycles, self-organizing teams,simpler designs, code refactoring, test-drivendevelopment, frequent customer involvement, andan emphasis on creating a demonstrable workingproduct with each development cycle.Many agile methods are available in the literature; some of the more popular approaches,which are discussed here in brief, include RapidApplication Development (RAD), eXtreme Programming (XP), Scrum, and Feature-DrivenDevelopment (FDD).• RAD: Rapid software development methodsare used primarily in data-intensive, businesssystems application development.
The RADmethod is enabled with special-purpose database development tools used by softwareengineers to quickly develop, test, and deploynew or modified business applications.• XP: This approach uses stories or scenariosfor requirements, develops tests first, hasdirect customer involvement on the team(typically defining acceptance tests), usespair programming, and provides for continuous code refactoring and integration. Storiesare decomposed into tasks, prioritized, estimated, developed, and tested. Each increment of software is tested with automatedand manual tests; an increment may bereleased frequently, such as every couple ofweeks or so.• Scrum: This agile approach is more projectmanagement-friendly than the others. Thescrum master manages the activities withinthe project increment; each increment iscalled a sprint and lasts no more than 30days.
A Product Backlog Item (PBI) list isdeveloped from which tasks are identified,defined, prioritized, and estimated. A working version of the software is tested andreleased in each increment. Daily scrummeetings ensure work is managed to plan.• FDD: This is a model-driven, short, iterative software development approach usinga five-phase process: (1) develop a productmodel to scope the breadth of the domain, (2)create the list of needs or features, (3) buildthe feature development plan, (4) developdesigns for iteration-specific features, and(5) code, test, and then integrate the features.FDD is similar to an incremental softwaredevelopment approach; it is also similar toXP, except that code ownership is assignedto individuals rather than the team.
FDDemphasizes an overall architectural approachto the software, which promotes building thefeature correctly the first time rather thanemphasizing continual refactoring.There are many more variations of agile methods in the literature and in practice.
Note thatthere will always be a place for heavyweight,plan-based software engineering methods as wellas places where agile methods shine. There arenew methods arising from combinations of agileand plan-based methods where practitioners aredefining new methods that balance the featuresneeded in both heavyweight and lightweightmethods based primarily on prevailing organizational business needs. These business needs,as typically represented by some of the projectstakeholders, should and do drive the choice inusing one software engineering method overanother or in constructing a new method from thebest features of a combination of software engineering methods.9-10 SWEBOK® Guide V3.01.1. ModelingPrinciples1.2. Propertiesand Expression ofModels1.3. Syntax,Semantics, andPragmatics1.4. Preconditions,Postconditions, andInvariants2. Types of Models2.1. InformationModeling2.2. BehavioralModeling2.3. StructureModelingc4s1.1p7,c4s6p3,c5s0p3c5s2,c5s3c2s2.2.2p6c5s0c10s4p2,c10s5p2p4c4s4c7s2.2c7s2.1,c7s2.3,c7s2.4c7s2.5,c7s3.1,c7s3.2c8s1c9s2c5s4c5s3c43. Analysis of Models3.1. Analyzing forCompleteness3.2. Analyzing forConsistency3.3. Analyzing forCorrectnessc4s1.1p7,c4s6c4s1.1p7,c4s6pp8–11pp8–11c4s7.1,c4s7.23.4. Traceability3.5. InteractionAnalysispp8–11c10, c11c29s1.1,c29s5c5Boehm and Turner 2003[7*]c5s01. ModelingBrookshear 2008[6*]Sommerville 2011[3*]c2s2Wing 1990[5*]Mellor and Balcer 2002[2*]c2s2,c5s1,c5s2Page-Jones 1999[4*]Budgen 2003[1*]MATRIX OF TOPICS VS.
REFERENCE MATERIALBoehm and Turner 2003[7*]Brookshear 2008[6*]Wing 1990[5*]Page-Jones 1999[4*]Sommerville 2011[3*]Mellor and Balcer 2002[2*]Budgen 2003[1*]Software Engineering Models and Methods 9-114. SoftwareEngineering Methods4.1. HeuristicMethods4.2. Formal Methods4.3. PrototypingMethods4.4. Agile Methodsc18c2s2.2,c7s1,c5s4.1c27c12s2c2s3.1c7s3p5c3c7s3p7c13, c15,c16pp8–24c6, app.A9-12 SWEBOK® Guide V3.0REFERENCES[1*] D. Budgen, Software Design, 2nd ed.,Addison-Wesley, 2003.[2*] S.J.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
