Strategic Issues

Strategic Issues

• The best strategy will fail if a series of overriding issues are not addressed. Tom Gilb argues that a software testing strategy will succeed when software testers.
• Specify product requirements in a quantifiable manner long before testing commences.
• Objective of testing is to find errors, a good testing strategy also assesses other quality characteristics such as portability, maintainability, and usability.
• State testing objectives explicitly.
• The specific objectives of testing should be stated in measurable terms.
• Understand the users of the software and develop a profile for each user category.
• Develop a testing plan that emphasizes “rapid cycle testing.
• Build “robust” software that is designed to test itself.
• Use effective technical reviews as a filter prior to testing.
• Conduct technical reviews to assess the test strategy and test cases themselves
• Develop a continuous improvement approach for the testing process.

Short note on Software Testing Strategic

Short note on Software Testing Strategic

• The software process may be viewed as the spiral illustrated in Figure.
• Initially, system engineering defines the role of software and leads to software requirements analysis, where the information domain, function, behavior, performance, constraints, and validation criteria for software are established.
• Moving inward along the spiral, you come to design and finally to coding.

Software Testing Strategic

• Unit testing begins at the vortex of the spiral and concentrates on each unit (e.g., component, class, or WebApp content object) of the software as implemented in source code.
• Integration testing, where the focus is on design and the construction of the software architecture.
• Validation testing, where requirements established as part of requirements modeling are validated against the software that has been constructed.
• Finally, system testing, where the software and other system elements are tested as a whole…
• Process from a procedural point of view :
• Testing within the context of software engineering is actually a series of four steps that are implemented sequentially.
• The steps are shown in Figure :

Introduction - strategy for software testing | Verification and Validation (V & V)

Introduction - strategy for software testing

• Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.
• A strategy for software testing provides a road map that describes the steps to be conducted as part of testing.
• Any testing strategy must incorporate 
• Test planning,
• Test case design,
• Test execution,
• Resultant data collection and Evaluation.

What Testing Shows

A Strategy Approach to software testing

• Testing is a set of activities that can be planned in advance and conducted systematically.
• For this reason a template for software testing—a set of steps into which you can place specific test case design techniques and testing methods—should be defined for the software process.
• Generic characteristics of Strategy Approach to software testing.
• To perform effective testing, you should conduct effective technical reviews. By doing this, many errors will be eliminated before testing commences.
• Testing begins at the component level and works “outward” toward the integration of the entire computer-based system.
• Different testing techniques are appropriate for different software engineering approaches and at different points in time.
• Testing is conducted by the developer of the software and (for large projects) an independent test group.
• Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

Verification and Validation (V & V)

• Software testing is one element of a broader topic that is often referred to as verification and validation (V&V).
• Verification refers to the set of tasks that ensure that software correctly implements a specific function.
• Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.
• Boehm states this another way:
• Verification: “Are we building the product right?”
• Validation: “Are we building the right product?”

Who Tests the Software?

Short note on Reviews Guidelines

Short note on Reviews Guidelines

• Review the product, not the producer.
• Set an agenda and maintain it.
• Limit debate and rebuttal.
• spending time debating the question, the issue should be recorded for further discussion off-line.
• Enunciate (Identify) problem areas, but don't attempt to solve every problem noted.
• Review is not a problem-solving session. The solution of a problem can often be accomplished by the producer alone or with the help of only one other individual. Problem solving should be postponed until after the review meeting.
• Take written notes.
• Limit the number of participants and insist upon advance preparation.
• Develop a checklist for each product that is likely to be reviewed.
• Allocate resources and schedule time for FTRs.
• Conduct meaningful training for all reviewers.
• Review your early reviews.

Short note on Formal Technical Reviews. (FTR)

Short note on Formal Technical Reviews. (FTR)

• Formal technical review (FTR) is a software quality control activity performed by software engineers (and others).
• The objectives of an FTR are:
• (1) To uncover errors in function, logic, or implementation for any representation of the software;
• (2) To verify that the software under review meets its requirements;
• (3) To ensure that the software has been represented according to predefined standards
• (4) To achieve software that is developed in a uniform manner;
• (5) To make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation
• The FTR is actually a class of reviews that includes walkthroughs and inspections

The Review Meeting:

• Every review meeting should abide by the following constraints:
• Between three and five people (typically) should be involved in the review.
• Advance preparation should occur but should require no more than two hours of work for each person.
• The duration of the review meeting should be less than two hours. Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software.
• For example, rather than attempting to review an entire design, walkthroughs are conducted for each component or small group of components.

Review Summary Report

• What was reviewed?
• Who reviewed it?
• What were the findings and conclusions?

The Players of Review Meeting

• Producer—the individual who has developed the work product
• Informs the project leader that the work product is complete and that a review is required.
• Review leader—evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation.
• Reviewer(s)—expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work.
• Recorder— a reviewer who records (in writing) all important issues raised during the review.

Short note on Informal Reviews

Short note on Informal Reviews

• Informal reviews include
• A simple desk check of a software engineering work product with a colleague,
• A casual meeting (involving more than two people) for the purpose of reviewing a work product,
• The review-oriented aspects of pair programming.
• A simple desk check or a casual meeting conducted with a colleague is a review.
• However, because there is no advance planning or preparation, no agenda or meeting structure, and no follow-up on the errors that are uncovered,
• the effectiveness of such reviews is considerably lower than more formal approaches. But a simple desk check can and does uncover errors that might otherwise propagate further into the software process. 

Review Metrics & their use

Review Metrics & their use

• Introduction : Technical reviews are one of many actions that are required as part of good software engineering practice.
• Each action requires dedicated human effort.
• The following review metrics can be collected for each review that is conducted
• Preparation effort, Ep—the effort (in person-hours) required to review a work product prior to the actual review meeting.
• Assessment effort, Ea— the effort (in person-hours) that is expending during the actual review
• Rework effort, Er— the effort (in person-hours) that is dedicated to the correction of those errors uncovered during the review
• Work product size, WPS—a measure of the size of the work product that has been reviewed (e.g., the number of UML models, or the number of document pages, or the number of lines of code)
• Minor errors found, Errminor—the number of errors found that can be categorized as minor (requiring less than some pre-specified effort to correct)
• Major errors found, Errmajor— the number of errors found that can be categorized as major (requiring more than some pre-specified effort to correct)

What Are Reviews? | Errors and defects | Defect Amplification

What Are Reviews?

• Introduction : Software reviews are a “filter” for the software process.
• Reviews are applied at various points during software engineering and serve to uncover errors and defects that can then be removed.
• Software reviews “purify” software engineering work products, including requirements and design models, code, and testing data.
• Technical reviews – TR (Peer Reviews) are the most effective mechanism for finding mistakes early in the software process.
• Six Steps are employed (Planning-Preparation-Structuring meeting Noting error-Making correction-Verifying correction)

What Do We Look For?

• Errors and defects
• Error — A quality problem found before the software is released to end users
• Defect — A quality problem found only after the software has been released to end-users
• The primary objective of technical reviews is to find errors during the process so that they do not become defects after release of the software. 
• The obvious benefit of technical reviews is the early discovery of errors so that they do not propagate to the next step in the software process.

Defect Amplification (Extension / Increase)

• A defect amplification model can be used to illustrate the generation and detection of errors during the design and code generation actions of a software process. 

A Design Pyramid for WebApp

A Design Pyramid for WebApp

• Introduction
• The creation of an effective design will typically require a diverse set of skills.
• Sometimes, for small projects, a single developer may need to be multi-skilled. 
• For larger projects, it may be advisable and/or feasible to draw on the expertise of specialists:
• Web engineers,
• Graphic designers,
• Content developers,
• Programmers,
• Database specialists,
• Information architects, 
• Network engineers,
• Security experts,
• Testers.
• In Design pyramid for WebApps, each level of the pyramid represents a design action… 

Interface Design

• Where am I? The interface should
• provide an indication of the WebApp that has been accessed
• Inform the user of location in the content hierarchy
• What can I do now? The interface should always help the user understand his current options
• what functions are available?
• what links are live?
• what content is relevant?
• Where have I been, where am I going? The interface must facilitate navigation. 
• Provide a “map” (implemented in a way that is easy to understand) of where the user has been and what paths may be taken to move elsewhere within the WebApp.

Aesthetic Design

• Aesthetic design, also called graphic design.
• Layout Issues :
• Don’t be afraid of white space.
• Emphasize content.
• Organize layout elements from top-left to bottom right.
• Group navigation, content, and function geographically within the page.
• Don’t extend your real estate with the scrolling bar.
• Consider resolution and browser window size when designing layout.

Content Design

• Develops a design representation for content objects
• For WebApps, a content object is more closely aligned with a data object for conventional software.
• Represents the mechanisms required to instantiate their relationships to one another.
• Analogous to the relationship between analysis classes and design components.
• A content object has attributes that include content-specific information
• Implementation-specific attributes that are specified as part of design

Architecture Design

• Content architecture focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation.
• The term information architecture is also used to predict structures that lead to better organization, labeling, navigation, and searching of content objects.
• WebApp architecture addresses the manner in which the application is structured to manage user interaction, handle internal processing tasks, effect navigation, and present content.
• Architecture design is conducted in parallel with interface design, aesthetic design and content design.
• Content architecture :
• Four different content structures :
• (1) Linear structures
• (2) Grid structure
• (3) Hierarchical structures
• (4) Networked or “pure web” structure

• WebApp architecture
• WebApp architecture describes an infrastructure that enables a Web-based system or application to achieve its business objectives.
• The Model-View-Controller (MVC) architecture is one of a number of suggested WebApp infrastructure models that decouple the user interface from the WebApp functionality and informational content.

Model-View-Controller (MVC) architecture

• Model :
• The model (sometimes referred to as the “model object”) contains all application-specific content and processing logic, including all content objects, access to external data/information sources, and all processing functionality that is application specific.
• View :
• The view contains all interface specific functions and enables the presentation of content and processing logic, including all content objects, access to external data/information sources, and all processing functionality required by the end user.
• Controller :
• The controller manages access to the model and the view and coordinates the flow of data between them. 

Navigation Design

• Begins with a consideration of the user hierarchy and related use cases.
• Each actor may use the WebApp somewhat differently and therefore have different navigation requirements
• As each user interacts with the WebApp, it encounters a series of navigation semantic units (NSUs)
• NSU—“a set of information and related navigation structures that collaborate in the fulfillment of a subset of related user requirements” 

Navigation Semantic Units

• Navigation semantic unit
• Ways of navigation (WoN)—represents the best navigation way or path for users with certain profiles to achieve their desired goal or sub-goal. Composed of …
• Navigation nodes (NN) connected by Navigation links

Navigation Syntax

• Individual navigation link—text-based links, icons, buttons and switches, and graphical metaphors..
• Horizontal navigation bar—lists major content or functional categories in a bar containing appropriate links. 
• Vertical navigation column
• lists major content or functional categories
• lists virtually all major content objects within the WebApp.
• Sitemaps—provide an all-inclusive tab of contents for navigation to all content objects and functionality contained within the WebApp.

Component-Level Design

• WebApp components implement the following functionality
• Perform localized processing to generate content and navigation capability in a dynamic fashion
• Provide computation or data processing capability that are appropriate for the WebApp’s business domain
• Provide sophisticated database query and access
• Data interfaces with external corporate systems. 

WebApp Design Goals

WebApp Design Goals

• Introduction :
• Jean Kaiser suggests a set of design goals that are applicable to virtually every WebApp regardless of application domain, size, or complexity.
• The following are the set of design goals to apply webApp
• Simplicity
• Consistency
• Identity
• Robustness
• Navigability
• Visual Appeal 
• Compatibility

• Simplicity 
• Content should be informative but to the point and should use a delivery mode (e.g., text, graphics, video, audio) that is appropriate to the information that is being delivered.
• Architecture should achieve WebApp objectives in the simplest possible manner.
• Navigation should be straightforward and navigation mechanisms should be naturally obvious to the end user.
• Functions should be easy to use and easier to understand.
• Consistency
• This design goal applies to virtually every element of the design model.
• Content should be constructed consistently
• e.g., text formatting and font styles should be the same across all text documents;
• Graphic art should have a consistent look, color scheme, and style)
• Identity
• Establish an “identity” that is appropriate for the business purpose.
• Robustness (Strength)
• The user expects robust content and functions that are relevant to the user’s needs.
• Navigability
• Navigation should be simple and consistent.
• It should also be designed in a manner that is predictable.
• The user should understand how to move about the WebApp without having to search for navigation links or instructions.
• Visual appeal
• The look and feel of content, interface layout, color coordination, the balance of text, graphics and other media, navigation mechanisms must appeal to end-users
• Compatibility
• WebApp will be used in a variety of environments (e.g., different hardware, Internet connection types, operating systems, browsers)
• It must be designed to be compatible with each.

WebApp Design Quality

WebApp Design Quality

• Introduction:
• There are essentially two basic approaches to design:
• The artistic ideal of expressing yourself
• The engineering ideal of solving a problem for a customer.
• Design is the engineering activity that leads to a high-quality product. This leads us to a recurring question that is encountered in all engineering disciplines: What is quality?

• Some other quality attributes
• Security
• WebApps have become heavily integrated with critical corporate and government databases. E-commerce applications extract and then store sensitive customer information. 
• Rebuff (Reject) external attacks
• Exclude unauthorized access
• Ensure the privacy of users/customers
• Availability
• The measure of the percentage of time that a WebApp is available for use.
• Scalability
• Can the WebApp and the systems with which it is interfaced handle significant variation in user or transaction volume… If numbers of users are extend…
• Time to Market 
• although time-to-market is not a true quality attribute in the technical sense, it is a measure of quality from a business point of view.

WebApp Design Patterns

WebApp Design Patterns

• There are two dimensions in WebApp Design Patterns:
• The design focus of the pattern and its level of granularity.
• Design focus identifies which aspect of the design model is relevant (e.g., information architecture, navigation, interaction).
• Granularity identifies the level of abstraction that is being considered (e.g., does the pattern apply to the entire WebApp, to a single Web page, to a subsystem, or an individual WebApp component?).

• Design Focus 
• WebApp patterns can be categorized using the following levels of design focus
• Information architecture patterns relate to the overall structure of the information space, and the ways in which users will interact with the information. 
• Navigation patterns define navigation link structures, such as hierarchies, rings, tours, and so on. 
• Interaction patterns contribute to the design of the user interface.
• Presentation patterns assist in the presentation of content as it is presented to the user via the interface.
• Functional patterns define the workflows, behaviors, processing, communication, and other algorithmic elements within a WebApp.

• Design Granularity: When a problem involves “big picture” issues, you should attempt to develop solutions (and use relevant patterns) that focus on the big picture. 
• In terms of the level of granularity, patterns can be described at the following levels. 
• Architectural patterns. This level of abstraction will typically relate to patterns that define the overall structure of the WebApp, indicate the relationships among different components. 
• Design patterns. These address a specific element of the design such as an aggregation of components to solve some design problem, relationships among elements on a page, or the mechanisms for effecting component-to-component communication. 
• Component patterns. This level of abstraction relates to individual small-scale elements of a WebApp.

User interface Design Patterns

User interface Design Patterns

• Hundreds of user interface (UI) patterns have been proposed in recent years. 
• Most fall within one of the following 10 categories of patterns : 
• (1) Pattern: TopLevelNavigation 
• Brief Description: Used when a site or application implements a number of major functions. Provides a top-level menu, often coupled with a logo or identifying graphic, that enables direct navigation to any of the system’s major functions. 
• (2) Pattern: CardStack 
• Brief Description: Used when a number of specific subfunctions or content categories related to a feature or function must be selected in random order. [e.g. DropDownList]
• (3) Pattern: Fill-in-the-Blanks 
• Brief description: Allow alphanumeric data to be entered in a “text box.” 
• (4) Pattern: SortableTable
• Brief description: Display a long list of records that can be sorted by electing a toggle mechanism for any column label. 
• (5) Pattern: BreadCrumbs 
• Brief description: Provides a full navigation path when the user is working with a complex hierarchy of pages or display screens. 
• (6) Pattern: EditInPlace
• Brief description: Provide simple text editing capability for certain types of content in the location that it is displayed.
• (7)  Pattern: SimpleSearch 
• Brief description: Provides the ability to search a website or persistent data source for a simple data item described by an alphanumeric string.
• (8) Pattern: Wizard
• Brief description: Takes the user through a complex task one step at a time, providing guidance for the completion of the task through a series of simple window displays.
• (9) Pattern: ShoppingCart 
• Brief description: Provides a list of items selected for purchase. 
• (10) Pattern: ProgressIndicator 
• Brief description: Provides an indication of progress when an operation takes longer than n seconds.

Component Level Design Patterns

Component Level Design Patterns

• Component-level design patterns provide you with proven solutions that address one or more subproblems extracted from the requirements model. 

• In many cases, design patterns of this type focus on some functional element of a system. 

• For example: Searching is a very common problem, it should come as no surprise that there are many search-related patterns like… 

• AdvancedSearch
• HelpWizard
• SearchArea
• SearchTips
• SearchResults
• SearchBox

Architectural Pattern

Architectural Pattern 

• Architectural patterns for software define a specific approach for handling some characteristic of the system.
• Bosch and Booch define a number of architectural pattern domains.
• Access control :
• There are many situations in which access to data, features, and functionality delivered by an application is limited to specifically defined end users.
• Concurrency :
• There are a number of different ways in which an application can handle concurrency, and each can be presented by a different architectural pattern.
• Distribution:  
• The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environment.Twosubproblems are considered:
• (1) the way in which entities connect to one another,
•  For example The most common architectural pattern established to address the distribution problem is the Broker pattern. Abroker acts as a “middleman” between the client component and a server component. 
•  Persistence : 
•  Persistent data are stored in a database or file and may be read or modified by other processes at a later time. 
• two architectural patterns areused to achieve persistence 
• —A DatabaseManagementSystem 
• --- Application LevelPersistence pattern that builds persistence features into the application architecture

Pattern-Based Design | Thinking in Patterns | Design Tasks

Pattern-Based Design

• A software designer begins with a requirements model (either explicit or implied) that presents an abstract representation of the system. 
• The requirements model describes the problem set, establishes the context.

Thinking in Patterns

Shalloway and Trott suggest the following approach that enables a designer to think in patterns: 

• 1. Be sure you understand the big picture—the context in which the software to be built resides. The requirements model should communicate this to you. 
• 2. Examining the big picture, extract the patterns that are present at that level of abstraction.
• 3. Begin your design with ‘big picture’ patterns that establish a context for further design work. 
• 4. “Work inward from the context” looking for patterns at lower levels of abstraction that contribute to the design solution. 
• 5. Repeat steps 1 to 4 until the complete design is fleshed out. 
• 6. Refine the design by adapting each pattern to the specifics of the software you’re trying to build.

Design Tasks

• Examine the requirements model and develop a problem hierarchy. 
• Determine if a reliable pattern language has been developed for the problem domain.
• Beginning with a broad problem, determine whether one or more architectural patterns are available for it.
• Using the collaborations provided for the architectural pattern, examine subsystem or component level problems and search for appropriate patterns to address them.
• Repeat steps 2 through 5 until all broad problems have been addressed. 

Design Patterns | Effective Patterns | Kinds (Types) of Patterns | Frameworks | Difference between design patterns and Frameworks | Describing a Pattern | Pattern Languages

 Design Patterns

• Each of us has encountered a design problem and silently thought: I wonder if anyone has developed a solution to for this?
• What if there was a standard way of describing a problem (so you could look it up), and an organized method for representing the solution to the problem?
• Design patterns are a codified method for describing problems and their solution allows the software engineering community to capture design knowledge in a way that enables it to be reused.
•  Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use the solution a million times over without ever doing it the same way twice.
• Christopher Alexander, 1977
• “a three-part rule which expresses a relation between a certain context, a problem, and a solution.”

Effective Patterns

• Coplien characterizes an effective design pattern in the following way:
• It solves a problem: Patterns capture solutions, not just abstract principles or strategies. 
• It is a proven concept: Patterns capture solutions with a track record, not theories. 
• The solution isn't obvious (Clear): Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. 
• It describes a relationship: Patterns don't just describe modules but describe deeper system structures and mechanisms. 
• The pattern has a significant human component (minimize human intervention). All software serves human comfort or quality of life.

 Kinds (Types) of Patterns

• Architectural patterns describe broad-based design problems that are solved using a structural approach. 
• Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. 
• Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture.
• Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end-users. 
• WebApp patterns address a problem set that is encountered when building WebApps and often incorporates many of the other patterns categories just mentioned.
• As per Gamma and his colleagues, focus on three types that are relevant to object oriented design :
• Creational patterns focus on the “creation, composition, and representation of objects.
• Structural patterns focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure.
• Behavioral patterns address problems associated with the assignment of responsibility between objects and the manner in which communication is effected between objects.

Frameworks

• Patterns themselves may not be sufficient to develop a complete design.
• In some cases, it may be necessary to provide an implementation- specific skeletal (Outline sketch) infrastructure, called a framework, for design work.
• A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain.
• The plug points enable you to integrate problem specific classes or functionality within the skeleton. 
• In object-oriented context, a framework is a collection of cooperating classes.

Difference between design patterns and Frameworks

Gamma and his colleagues describe the differences between design. patterns and frameworks in the following manner: 

• 1. Design patterns are more abstract than frameworks. 
• Frameworks can be in material form in code, but only examples of patterns can be embodied in code. 
• A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly... 
• 2. Design patterns are smaller architectural elements than frameworks.
• A typical framework contains several design patterns but the reverse is never true. 
• 3. Design patterns are less specialized than frameworks. 
• Frameworks always have a particular application domain. In contrast, design patterns can be used in nearly any kind of application.

Describing a Pattern

• Pattern name—describes the essence of the pattern in a short but expressive name
• Problem—describes the problem that the pattern addresses 
• Motivation—provides an example of the problem 
• Context—describes the environment in which the problem resides including application domain 
• Forces—lists the system of forces that affect the manner in which the problem must be solved; includes a discussion of limitation and constraints that must be considered 
• Solution—provides a detailed description of the solution proposed for the problem 
• Intent—describes the pattern and what it does 
• Collaborations—describes how other patterns contribute to the solution 
• Related patterns—cross-references related design patterns

Pattern Languages

• A pattern language encompasses a collection of patterns 
• each described using a standardized template. 
• interrelated to show how these patterns collaborate to solve problems across an application domain. 
• A pattern language is analogous to a hypertext instruction manual for problem-solving in a specific application domain. 
• The problem domain under consideration is first described hierarchically, beginning with broad design problems associated with the domain and then refining each of the broad problems into lower levels of abstraction.