1

CHAPTER 10 1

SOFTWARE ENGINEERING MODELS AND METHODS 2

ACRONYMS 3

3GL 3RD GENERATION LANGUAGE

BNF BACKUS-NAUR FORM

FDD FEATURE-DRIVEN

DEVELOPMENT

IDE INTEGRATED DEVELOPMENT

ENVIRONMENT

KA KNOWLEDGE AREA

PBI PRODUCT BACKLOG ITEM

RAD RAPID APPLICATION

DEVELOPMENT

UML UNIFIED MODELING

LANGUAGE

XP EXTREME PROGRAMMING

INTRODUCTION 4

Software engineering models and methods 5 impose structure on software engineering 6 with the goal of making that activity 7 systematic, repeatable, and ultimately 8 more success-oriented. Using models 9 provides an approach to problem solving, 10 a notation, and procedures for model 11 construction and analysis. Methods 12 provide an approach to the systematic 13 specification, design, construction, test, 14 and verification of the end-item software 15 and associated work products. 16

Software engineering models and methods 17 vary widely in scope—from addressing a 18 single software life-cycle phase to 19 covering the complete software life cycle. 20 The emphasis in this Knowledge Area 21 (KA) is on software engineering models 22

and methods that encompass multiple 23 software life-cycle phases, since methods 24 specific for single life-cycle phases are 25 covered by other KAs. 26

BREAKDOWN OF TOPICS FOR 27 SOFTWARE ENGINEERING MODELS 28 AND METHODS 29

This chapter on software engineering 30 models and methods is divided into four 31 main topic areas: 32

Modeling – discusses the general 33 practice of modeling and presents 34 topics in modeling principles; 35 properties and expression of models; 36 modeling syntax, semantics, and 37 pragmatics; and pre-conditions, post-38 conditions, and invariants. 39

Types of Models – briefly discusses 40 models and aggregation of sub-models 41 and provides some general 42 characteristics of model types 43 commonly found in the software 44 engineering practice. 45

Analysis of Models – presents some of 46 the common analysis techniques used 47 in modeling to verify completeness, 48 consistency, correctness, traceability, 49 and interaction. 50

Software Engineering Methods – 51 presents a brief summary of 52 commonly used software engineering 53 methods. The discussion guides the 54 reader through a summary of heuristic 55 methods, formal methods, 56 prototyping, and agile methods. 57

The breakdown of topics for the Software 58 Engineering Models and Methods KA is 59 shown in Figure 1. 60

2

61 Figure 1 Breakdown of topics for the Software Engineering Models and Methods KA 62

1 Modeling 63

Modeling of software is becoming a 64 pervasive technique to help software 65 engineers understand, engineer, and 66 communicate aspects of the software to 67 appropriate stakeholders. Stakeholders are 68 those persons or parties who have a stated 69 or implied interest in the software (for 70 example, user, buyer, supplier, architect, 71 certifying authority, evaluator, developer, 72 software engineer, and perhaps others). 73

While there are many modeling 74 languages, notations, techniques, and tools 75 in the literature and in practice, there are 76 unifying general concepts that apply in 77 some form to them all. The following 78 sections provide background on these 79 general concepts. 80

1.1 Modeling Principles 81

[1 c2s2, c5s1, c5s2; 2 c2s2; 3 82 c8s0] 83

Modeling provides the software engineer 84 with an organized and systematic 85 approach for representing significant 86 aspects of the software under study, 87 facilitating decision-making about the 88 software or elements of it, and 89 communicating those significant decisions 90 to others in the stakeholder communities. 91 There are three general principles guiding 92 such modeling activities: 93

Model the Essentials – good models 94 do not usually represent every aspect 95 or feature of the software under every 96 possible condition. Modeling typically 97 involves developing only those 98

Software Engineering Models and Methods

Modeling Types of ModelsAnalysis of

Models

Software Engineering

Methods

Modeling Principles

Properties and Expression of Models

Syntax, Semantics, & Pragmatics

Pre-conditions, Post-conditions, & Invariants

Information Modeling

Behavioral Modeling

Structure Modeling

Analyzing for Correctness

Analyzing for Completeness

Traceability

Interaction Analysis

Heuristic Methods

Formal Methods

Prototyping Methods

Agile Methods

Analyzing for Consistency

3

aspects or features of the software that 99 need specific answers, abstracting 100 away any non-essential information. 101 This approach keeps the models 102 manageable and useful. 103

Provide Perspective – modeling 104 provides views of the software under 105 study using a defined set of rules for 106 expression of the model within each 107 view. This perspective-driven 108 approach provides dimensionality to 109 the model (for example, a structural 110 view, behavioral view, temporal view, 111 and other views as relevant). 112 Organizing information into views 113 focuses the software modeling efforts 114 on specific concerns relevant to that 115 view using the appropriate notation, 116 vocabulary, methods, and tools. 117

Enable Effective Communications – 118 modeling employs the application 119 domain vocabulary of the software, a 120 modeling language, and semantic 121 expression (in other words, meaning 122 within context). When used rigorously 123 and systematically, this modeling 124 results in a reporting approach that 125 facilitates effective communication of 126 software information to project 127 stakeholders. 128

A model is an abstraction or 129 simplification of a software component. A 130 consequence of using abstraction is that 131 no single abstraction completely describes 132 a software component. Rather, the model 133 of the software is represented as an 134 aggregation of abstractions, which—when 135 taken together—describe only selected 136 aspects, perspectives, or views—only 137 those that are needed to make informed 138 decisions and respond to the reasons for 139 creating the model in the first place. This 140 simplification leads to a set of 141 assumptions about the context within 142 which the model is placed that should also 143

be captured in the model. Then, when 144 reusing the model, these assumptions can 145 be validated first to establish the 146 relevancy of the reused model within its 147 new use and context. 148

1.2 Properties and Expression of 149 Models 150

[1 c5s2, c5s3; 3 c6s1.1p7, c7s3p2, 151 c8s0p4] 152

Properties of models are those 153 distinguishing features of a particular 154 model used to characterize its 155 completeness, consistency, and 156 correctness within the chosen modeling 157 notation and tooling used. Properties of 158 models include the following: 159

Completeness – the degree to which 160 all requirements have been 161 implemented and verified within the 162 model. 163

Consistency – the degree to which the 164 model contains no conflicting 165 requirements, assertions, constraints, 166 functions, or component descriptions. 167

Correctness – the degree to which the 168 model satisfies its requirements and 169 design specifications and is free of 170 defects. 171

Models are constructed to represent real-172 world objects and their behaviors to 173 answer specific questions about how the 174 software is expected to operate. 175 Interrogating the models—either through 176 exploration, simulation, or review—may 177 expose areas of uncertainty within the 178 model and the software to which the 179 model refers. These uncertainties or 180 unanswered questions regarding the 181 requirements, design, and/or 182 implementation can then be handled 183 appropriately. 184

The primary expression element of a 185 model is an entity. An entity may 186

4

represent concrete artifacts (for example, 187 processors, sensors, or robots) or abstract 188 artifacts (for example, software modules 189 or communication protocols). Model 190 entities are connected to other entities 191 using relations (in other words, lines or 192 textual operators on target entities). 193 Expression of model entities may be 194 accomplished using textual or graphical 195 modeling languages; both modeling 196 language types connect model entities 197 through specific language constructs. The 198 meaning of an entity may be represented 199 by its shape, textual attributes, or both. 200 Generally, textual information adheres to 201 language-specific syntactic structure. The 202 precise meanings related to the modeling 203 of context, structure, or behavior using 204 these entities and relations is dependent 205 on the modeling language used, the design 206 rigor applied to the modeling effort, the 207 specific view being constructed, and the 208 entity to which the specific notation 209 element may be attached. Multiple views 210 of the model may be required to capture 211 the needed semantics of the software. 212

When using models supported with 213 automation, models may be checked for 214 completeness and consistency. The 215 usefulness of these checks depends greatly 216 on the level of semantic and syntactic 217 rigor applied to the modeling effort in 218 addition to explicit tool support. 219 Correctness is typically checked through 220 simulation and/or review. 221

1.3 Syntax, Semantics, and 222 Pragmatics 223

[2 c2s2.2.2p6; 3 c8s0, c8s5] 224

Models can be surprisingly deceptive. The 225 fact that a model is an abstraction with 226 missing information can lead one into a 227 false sense of completely understanding 228 the software from a single model. A 229 complete model (“complete” being 230

relative to the modeling effort) may be a 231 union of multiple sub-models and any 232 special function models. So, examination 233 and decision-making relative to a single 234 model within this collection of sub-235 models may be problematic. 236

Understanding the precise meanings of 237 modeling constructs can also be difficult. 238 Modeling languages are defined by 239 syntactic and semantic rules. For textual 240 languages, syntax is defined using a 241 notation grammar that defines valid 242 language constructs (for example, Backus-243 Naur Form (BNF)). For graphical 244 languages, syntax is defined using 245 graphical models called meta-models. As 246 with BNF, meta-models define the valid 247 syntactical constructs of a graphical 248 modeling language; the meta-model 249 defines how these constructs can be 250 composed to produce valid models. 251

Semantics for modeling languages specify 252 the meaning attached to the entities and 253 relations captured within the model. For 254 example, a simple diagram of two boxes 255 connected by a line is open to a variety of 256 interpretations. Knowing that the diagram 257 on which the boxes are placed and 258 connected is an object diagram or an 259 activity diagram can assist in the 260 interpretation of this model. 261

As a practical matter, there is usually a 262 good understanding of the semantics of a 263 specific software model due to the 264 modeling language selected, how that 265 modeling language is used to express 266 entities and relations within that model, 267 the experience base of the modeler(s), and 268 the context within which the modeling has 269 been undertaken and so represented. 270 Meaning is communicated through the 271 model even in the presence of incomplete 272 information through abstraction; 273 pragmatics explains how meaning is 274 embodied in the model and its context and 275

5

communicated effectively to other 276 software engineers. 277

There are still instances, however, where 278 caution is needed regarding modeling and 279 semantics. For example, any model parts 280 imported from another model or library 281 must be examined for semantic 282 assumptions that conflict in the new 283 modeling environment; this may not be 284 obvious. Check the documented model 285 assumptions. While modeling syntax may 286 be identical, the model may mean 287 something quite different in the new 288 environment, which is a different context. 289 Also, consider that as software matures 290 and changes are made, semantic discord 291 can be introduced. With many software 292 engineers working on a model part over 293 time coupled with tool updates and 294 perhaps new requirements, there are 295 opportunities for the unchanged portions 296 of the model to represent something 297 different from the original author’s intent 298 and initial model context. 299

1.4 Pre-conditions, Post-300 conditions, and Invariants 301

[2 c4s4; 4 c10s4p2, c10s5p2p4] 302

When modeling functions or methods, the 303 software engineer typically starts with a 304 set of assumptions about the state of the 305 software prior to, during, and after the 306 function or method executes. These 307 assumptions are essential to the correct 308 operation of the function or method and 309 are grouped, for discussion, as a set of 310 pre-conditions, post-conditions, and 311 invariants. 312

Pre-conditions – a set of conditions 313 that must be satisfied prior to 314 execution of the function or method. If 315 these pre-conditions do not hold prior 316 to execution of the function or 317 method, the function or method may 318 produce erroneous results. 319

Post-conditions – a set of conditions 320 that is guaranteed to be true after the 321 function or method has executed 322 successfully. Typically, the post-323 conditions represent how the state of 324 the software has changed, how 325 parameters passed to the function or 326 method have changed, or how the 327 return value has been affected. 328

Invariants – a set of conditions within 329 the operational environment that 330 persist (in other words, do not change) 331 during execution of the function or 332 method. These invariants are relevant 333 and necessary to the software and the 334 correct operation of the function or 335 method. 336

2 Types of Models 337

A typical model consists of an 338 aggregation of sub-models. Each sub-339 model is a partial description and is 340 created for a specific purpose; it may be 341 comprised of one or more diagrams. The 342 collection of sub-models may employ 343 multiple modeling languages or a single 344 modeling language. The Unified 345 Modeling Language (UML) recognizes a 346 rich collection of modeling diagrams. Use 347 of these diagrams, along with the 348 modeling language constructs, brings 349 about three broad model types commonly 350 used: information models, behavioral 351 models, and structure models. 352

2.1 Information Modeling 353

[1 c7s2.2; 3 c8s3] 354

Information models provide a central 355 focus on data and information. An 356 information model is an abstract 357 representation that identifies and defines a 358 set of concepts, properties, relations, and 359 constraints on data entities. The semantic 360 or conceptual information model is often 361 used to provide some formalism and 362

6

context to the software being modeled as 363 viewed from the problem perspective, 364 without concern for how this model is 365 actually mapped to the implementation of 366 the software. The semantic or conceptual 367 information model is an abstraction and, 368 as such, includes only the concepts, 369 properties, relations, and constraints 370 needed to conceptualize the real- world 371 view of the information. Subsequent 372 transformations of the semantic or 373 conceptual information model lead to the 374 elaboration of logical and then physical 375 data models as implemented in the 376 software. 377

2.2 Behavioral Modeling 378

[1 c7s2.1, c7s2.3, c7s2.4; 2 c9s2; 3 379 c8s2, c8s4.3] 380

Behavioral models identify and define the 381 functions of the software being modeled. 382 Behavior models generally take three 383 basic forms: state machines, control-flow 384 models, and data-flow models. State 385 machines provide a model of the software 386 as a collection of defined states, events, 387 and transitions. The software transitions 388 from one state to the next by way of a 389 guarded or unguarded triggering event 390 that occurs in the modeled environment. 391 Control-flow models depict how a 392 sequence of events causes processes to be 393 activated or deactivated. Data-flow 394 behavior is typified as a sequence of steps 395 where data moves through processes 396 toward data stores or data sinks. 397

2.3 Structure Modeling 398

[1 c7s2.5, c7s3.1, c7s3.2; 3 c8s4; 4 399 c4] 400

Structure models illustrate the physical or 401 logical composition of software from its 402 various component parts. Structure 403 modeling establishes the defined 404 boundary between the software being 405

implemented or modeled and the 406 environment in which it is to operate. 407 Some common structural constructs used 408 in structure modeling are composition, 409 decomposition, generalization, and 410 specialization of entities; identification of 411 relevant relations and cardinality between 412 entities; and the definition of process or 413 functional interfaces. Typical structure 414 diagrams provided by the UML for 415 structure modeling, for example, include 416 class, component, object, deployment, and 417 packaging diagrams. 418

3 Analysis of Models 419

The development of models affords the 420 software engineer an opportunity to study 421 and understand the structure, function, and 422 assembly considerations associated with 423 software. Analysis of constructed models 424 is needed to ensure that these models are 425 complete, consistent, and correct enough 426 to serve their intended purpose for the 427 stakeholders. 428

The sections that follow briefly describe 429 the analysis techniques generally used 430 with software models to ensure that the 431 software engineer and other relevant 432 stakeholders gain appropriate value from 433 the development and use of models. 434

3.1 Analyzing for Completeness 435 [3 c6s1.1p7, c7s3; 5 pp8–11] 436

In order to have software that fully meets 437 the needs of the stakeholders, 438 completeness is critical—from the 439 requirements capture process to code 440 implementation. Completeness is the 441 degree to which all of the specified 442 requirements have been implemented and 443 verified. Models may be checked for 444 completeness by a modeling tool that uses 445 techniques such as structural analysis and 446 state-space reachability analysis (which 447 ensure that all paths in the state models 448

7

are reached by some set of correct inputs); 449 models may also be checked for 450 completeness manually by using 451 inspections or other review techniques. 452 Errors and warnings generated by these 453 analysis tools and found by inspection or 454 review indicate probable needed 455 corrective actions to ensure completeness 456 of the models. 457

3.2 Analyzing for Consistency 458

[3 c6s1.1p7, c7s3, c20s1; 5 pp8–11] 459

Consistency is the degree to which models 460 contain no conflicting requirements, 461 assertions, constraints, functions, or 462 component descriptions. Typically, 463 consistency checking is accomplished 464 with the modeling tool using an 465 automated analysis function; models may 466 also be checked for consistency manually 467 using inspections or other review 468 techniques. As with completeness, errors 469 and warnings generated by these analysis 470 tools and found by inspection or review 471 indicate the need for corrective action. 472

3.3 Analyzing for Correctness 473

[5 pp8–11] 474

Correctness is the degree to which a 475 model satisfies its requirements and 476 design specifications, is free of defects, 477 and ultimately meets the stakeholders’ 478 needs. To analyze a model for correctness, 479 one analyzes it—either manually (for 480 example, through the use of inspections or 481 other review techniques) or automatically 482 (using the modeling tool)—searching for 483 possible defects (for example, syntax, 484 function, or data errors) and then 485 removing or repairing confirmed defects 486 before the software is released for use. 487

3.4 Traceability 488

[3 c7s3.1p3, c7s4.2pp3–6] 489

Developing software typically involves 490 the use, creation, and modification of 491 many work products such as, for example, 492 planning documents, process 493 specifications, requirements 494 specifications, diagrams, designs and 495 pseudo-code, handwritten and tool-496 generated code, manual and automated 497 test cases and reports, and files and data. 498 These work products may be related 499 through various dependency relationships 500 (for example, uses, implements, tests). As 501 software is being developed, managed, 502 maintained, or extended, there is a need to 503 map and control these traceability 504 relationships to maintain requirements 505 consistency with the overall software end-506 item(s) and work products. Use of 507 traceability typically improves the 508 management of software work products 509 and software process quality. Traceability 510 also enables change analysis once the 511 software is developed and released, since 512 relationships to software work products 513 can easily be traversed to assess change 514 impact. Modeling tools typically provide 515 some automated or manual means to 516 specify and manage traceability links 517 between requirements, design, code, 518 and/or test entities as may be represented 519 in the models and to other software work 520 products. 521

3.5 Interaction Analysis 522

[2 c10, c11; 3 c16s1.1, c16s5; 4 c5] 523

Interaction analysis focuses on the 524 communications or control flow relations 525 between entities used to accomplish a 526 specific task or function within the 527 software model. This analysis examines 528 the dynamic behavior of the interactions 529 between different portions of the software 530 model, including other software layers 531 (such as the operating system, 532 middleware, and applications). It may also 533 be important for some software 534

8

applications to examine interactions 535 between the computer software 536 application and the user interface 537 software. Some software modeling 538 environments provide simulation facilities 539 to study aspects of the dynamic behavior 540 of modeled systems. Stepping through the 541 simulation provides an analysis option for 542 the software engineer to review the 543 interaction design and verify that the 544 different parts of the software work 545 together to provide the intended functions. 546

4 Software Engineering 547 Methods 548

Software engineering methods provide an 549 organized and systematic approach to 550 developing software for a target computer. 551 There are numerous methods from which 552 to choose and it is important for the 553 software engineer to choose an 554 appropriate method or methods for the 555 software development task at hand; this 556 choice can have a dramatic effect on the 557 success of the software project. Use of 558 these software engineering methods 559 coupled with people of the right skill set 560 and tools enables the software engineers 561 to visualize the details of the software and 562 ultimately transform the representation 563 into a working set of code and data. 564

Selected software engineering methods 565 are discussed below. The topic areas are 566 organized into discussions of Heuristic 567 Methods, Formal Methods, Prototyping 568 Methods, and Agile Methods. 569

4.1 Heuristic Methods 570

[1 c13, c15, c16; 3 c8s5, c14, c17s3] 571

Heuristic methods are those experience-572 based software engineering methods that 573 have been and are fairly widely practiced 574 in the software industry. This topic area 575 contains three broad discussion 576 categories: structured analysis and design 577

methods, data modeling methods, and 578 object-oriented analysis and design 579 methods. 580

Structured Analysis and Design 581 Methods – The software model is 582 developed primarily from a functional 583 or behavioral viewpoint, starting from 584 a high-level view of the software 585 (including data and control elements) 586 and then progressively decomposing 587 or refining the model components 588 through increasingly detailed designs. 589 The detailed design eventually 590 converges to very specific details or 591 specifications of the software that 592 must be built (in other words, coded) 593 and verified. 594

Data Modeling Methods – The data 595 model is constructed from the 596 viewpoint of the data or information 597 used. Data tables and relationships 598 define the data models. This data 599 modeling method is used primarily for 600 defining and analyzing data 601 requirements supporting database 602 designs or data repositories typically 603 found in business software, where data 604 is actively managed as a business 605 systems resource or asset. 606

Object-Oriented Analysis and Design 607 Methods – The object-oriented model 608 is represented as a collection of 609 objects that encapsulate data and 610 relationships and interact with other 611 objects through methods. Objects may 612 be real-world items or virtual items. 613 The software model is constructed 614 using diagrams to constitute selected 615 views of the software. Progressive 616 refinement of the software models 617 lead to a detailed design. The detailed 618 design is then either evolved through 619 successive iteration or transformed 620 (using some mechanism) into the 621 implementation view of the model, 622

9

where the code and packaging 623 approach for eventual software 624 product release and deployment is 625 expressed. 626

4.2 Formal Methods 627

[1 Cc18; 3 c10; 5 pp8–24] 628

Formal methods are software engineering 629 methods used to specify, develop, and 630 verify the software through application of 631 a rigorous mathematically based notation 632 and language. Through use of the 633 specification language, the software 634 model can be checked for consistency (in 635 other words, lack of ambiguity), 636 completeness, and correctness in a 637 systematic and automated or semi-638 automated fashion. 639

This section addresses specification 640 languages, program refinement and 641 derivation, formal verification, and logical 642 inference. 643

Specification Languages – 644 Specification languages provide the 645 mathematical basis for a formal 646 method; specification languages are 647 formal, higher-level computer 648 languages (in other words, not a 649 classic 3rd Generation Language 650 (3GL) programming language) used 651 during the software specification, 652 requirements analysis, and/or design 653 phases of the software development 654 project to describe specific 655 input/output behavior. Specification 656 languages are not directly executable 657 languages; they are typically 658 comprised of a notation and syntax, 659 semantics for use of the notation, and 660 a set of allowed relations for objects. 661

Program Refinement and Derivation – 662 Program refinement is the process of 663 creating a lower-level (or more 664 detailed) specification using a series of 665

transformations. It is through 666 successive transformations that the 667 software engineer derives an 668 executable representation of a 669 program. Specifications may be 670 refined, adding details until the model 671 can be formulated in a 3GL 672 programming language or in an 673 executable portion of the chosen 674 specification language. This 675 specification refinement is made 676 possible by defining specifications 677 with precise semantic properties; the 678 specifications must set out not only 679 the relationships between entities but 680 also the exact run-time meanings of 681 those relationships and operations. 682

Formal Verification – Model checking 683 is a formal verification method; it 684 typically involves performing a state-685 space exploration or reachability 686 analysis to demonstrate that the 687 represented software design has or 688 preserves certain model properties of 689 interest. An example of model 690 checking is an analysis that verifies 691 correct program behavior under all 692 possible interleaving of event or 693 message arrivals. The use of formal 694 verification requires a rigorously 695 specified model of the software and its 696 operational environment; this model 697 often takes the form of a finite state 698 machine or other formally defined 699 automaton. 700

Logical Inference – Logical inference 701 is a method of designing software that 702 involves specifying pre-conditions and 703 post-conditions around each 704 significant block of the design, and—705 using mathematical logic—developing 706 the proof that those pre-conditions and 707 post-conditions must hold under all 708 inputs. This provides a way for the 709 software engineer to predict software 710

10

behavior without having to execute the 711 software. Some Integrated 712 Development Environments (IDEs) 713 include ways to represent these proofs 714 along with the design or code. 715

4.3 Prototyping Methods 716

[1 c12s2; 3 c17s4; 6 c7s3p5] 717

Software prototyping is an activity that 718 generally creates incomplete or minimally 719 functional versions of a software 720 application, usually for trying out specific 721 new features, soliciting feedback on 722 requirements or user interfaces, further 723 exploring requirements, design, or 724 implementation options, and/or gaining 725 some other useful insight into the 726 software. The software engineer selects a 727 prototyping method to understand the 728 least understood aspects or components of 729 the software first; this approach is in 730 contrast with other development methods 731 which usually begin development with the 732 most understood portions first. Typically, 733 the prototyped product does not become 734 the final software product without 735 extensive development rework or 736 refactoring. 737

This section discusses prototyping styles, 738 targets, and evaluation techniques in brief. 739

Prototyping Style – This addresses the 740 various approaches to developing 741 prototypes. Prototypes can be 742 developed as throwaway code or paper 743 products, as an evolution of a working 744 design, or as an executable 745 specification. Different prototyping 746 life-cycle processes are typically used 747 for each style. The style chosen is 748 based on the type of results the project 749 needs, the quality of the results 750 needed, and the urgency of the results. 751

Prototyping Target – The target of the 752 prototype activity is the specific 753

product being served by the 754 prototyping effort. Examples of 755 prototyping targets include a 756 requirements specification, an 757 architectural design element or 758 component, an algorithm, or a human-759 machine user interface. 760

Prototyping Evaluation Techniques – 761 A prototype may be used or evaluated 762 in a number of ways by the software 763 engineer or other project stakeholders, 764 driven primarily by the underlying 765 reasons that led to prototype 766 development in the first place. 767 Prototypes may be evaluated or tested 768 against the actual implemented 769 software or against a target set of 770 requirements (for example, a 771 requirements prototype); the prototype 772 may also serve as a model for a future 773 software development effort (for 774 example, as in a user interface 775 specification). 776

4.4 Agile Methods 777

[3 c17s1, c17s2, c17s3; 6 c7s3p7; 7 778 c6, App. A] 779

Agile methods were born in the 1990s 780 from the need to reduce the apparent large 781 overhead associated with heavyweight, 782 plan-based development methods used in 783 large-scale software-development 784 projects. Agile methods are considered 785 lightweight methods in that they are 786 characterized by short, iterative 787 development cycles, self-organizing 788 teams, simpler designs, code refactoring, 789 test-driven development, frequent 790 customer involvement, and an emphasis 791 on creating a demonstrative working 792 product with each development cycle. 793

Many agile methods are available in the 794 literature; some of the more popular 795 approaches, which are discussed here in 796 brief, include pair programming, Rapid 797

11

Application Development (RAD), 798 eXtreme Programming (XP), scrum, and 799 Feature-Driven Development (FDD). 800

Pair Programming – Software 801 engineers work in pairs, sitting at one 802 workstation, to design and program 803 the software. The pair programming 804 process promotes collective ownership 805 of the software, informal code review, 806 and continuous code refactoring. 807

RAD – Rapid software development 808 methods are used primarily in data-809 intensive, business-systems 810 application development. The RAD 811 method is enabled with special-812 purpose database development tools 813 used by software engineers to quickly 814 develop, test, and deploy new or 815 modified business applications. 816

XP – This approach uses stories or 817 scenarios for requirements, develops 818 tests first, has direct customer 819 involvement on the team (typically 820 defining acceptance tests), uses pair 821 programming, and provides for 822 continuous code refactoring and 823 integration. Stories are decomposed 824 into tasks, prioritized, estimated, 825 developed, and tested. Each increment 826 of software is tested with automated 827 and manual tests; an increment may be 828 released every couple of weeks or so. 829

Scrum – This agile approach is more 830 project-management friendly than the 831 others. The scrum master manages the 832 activities within the project increment; 833 each increment is called a sprint and 834 lasts about 30 days. A Product 835 Backlog Item (PBI) list is developed 836 from which tasks are identified, 837 defined, prioritized, and estimated. A 838 working version of the software is 839 tested and released in each increment. 840

Daily scrum meetings ensure work is 841 managed to plan. 842

FDD – This is a model-driven, short, 843 iterative software development 844 approach using a five-phase process: 845 (1) develop a product model to scope 846 the breadth of the domain, (2) create 847 the list of needs or features, (3) build 848 the feature development plan, (4) 849 develop designs for iteration-specific 850 features, and (5) code, test, and then 851 integrate the features. FDD is similar 852 to an incremental software 853 development approach; it is also 854 similar to XP, except that code 855 ownership is assigned to individuals 856 rather than the team. FDD emphasizes 857 an overall architectural approach to 858 the software, which promotes building 859 the feature correctly the first time 860 rather than emphasizing continual 861 refactoring. 862

There are many more variations of agile 863 methods in the literature and in practice. 864 Note that there will always be a place for 865 heavyweight, plan-based software 866 engineering methods as well as places 867 where agile methods shine. There are new 868 methods arising from combinations of 869 agile and plan-based methods where 870 practitioners are defining new methods 871 that balance the features needed in both 872 heavyweight and lightweight methods 873 based primarily on prevailing 874 organizational business needs. These 875 business needs, as typically represented 876 by some of the project stakeholders, 877 should and do drive the choice in using 878 one software engineering method over 879 another or in constructing a new method 880 from the best features of a combination of 881 software engineering methods. 882

883

884

12

RECOMMENDED REFERENCES FOR 885 SOFTWARE ENGINEERING MODELS 886 AND METHODS 887

[1] D. Budgen, Software Design, 2nd 888 ed., New York: Addison-Wesley, 889 2003. 890

[2] S.J. Mellor and M.J. Balcer, 891 Executable UML: A Foundation 892 for Model-Driven Architecture, 1st 893 ed., Boston: Addison-Wesley, 894 2002. 895

[3] I. Sommerville, Software 896 Engineering, 8th ed., New York: 897 Addison-Wesley, 2006. 898

[4] M. Page-Jones, Fundamentals of 899 Object-Oriented Design in UML, 900

1st ed., Reading, MA: Addison-901 Wesley, 1999. 902

[5] J.M. Wing, "A Specifier's 903 Introduction to Formal Methods," 904 Computer, IEEE CS Press, vol. 23, 905 no. 3, pp. 8, 10 – 23, 1990. 906

[6] J.G. Brookshear, Computer 907 Science: An Overview, 10th ed., 908 Boston: Addison-Wesley, 2008. 909

[7] B. Boehm and R. Turner, 910 Balancing Agility and Discipline: 911 A Guide for the Perplexed, 912 Boston: Addison-Wesley, 2003. 913

914

915

916

917

13

MATRIX OF TOPICS VS. REFERENCE MATERIAL 918

Boe

hm

Bro

oksh

ear

Bu

dge

n

Mel

lor

Pag

e-Jo

nes

Som

mer

vill

e

Win

g

1. Modeling

1.1 Modeling Principles C2S2, C5S1, C5S2 C2S2 C8S0

1.2 Properties and Expression of Models C5S2, C5S3 C6S1.1P7,

C7S3P2, C8S0P4

1.3 Syntax, Semantics, and Pragmatics C2S2.2.2P6 C8S0, C8S5

1.4 Pre-conditions, Post-conditions, and Invariants

C4S4 C10S4P2,

C10S5P2P4

2. Types of Models

2.1 Information Modeling C7S2.2 C8S3

2.2 Behavioral Modeling C7S2.1, C7S2.3,

C7S2.4 C9S2 C8S2, C8S4.3

2.3 Structure Modeling C7S2.5, C7S3.1,

C7S3.2 C4 C8S4

3. Analysis of Models

3.1 Analyzing for Completeness C6S1.1P7, C7S3 PP8-11

3.2 Analyzing for Consistency C6S1.1P7, C7S3,

C20S1 PP8-11

3.3 Analyzing for Correctness PP8-11

3.4 Traceability C7S3.1P3,

C7S4.2P3 – 6

3.5 Interaction Analysis C10, C11 C5 C16S1.1, C16S5

4. Software Engineering Methods

4.1 Heuristic Methods C13, C15, C16 C8S5, C14, C17S3

4.2 Formal Methods C18 C10 PP8-24

4.3 Prototyping Methods C7S3P5 C12S2 C17S4

4.4 Agile Methods C6, App. A

C7S3P7 C17S1, C17S2,

C17S3

919

14

List of Further Readings 920

921

None. 922