9. Software Design

9.1 Architecture Design

• Architectural design is concerned with understanding how a system should be organized and designing the overall structure of that system.
• It is the first stage in the software design process, and the critical link between design and requirements engineering.
• It identifies the main structural components in a system and the relationships between them
• The output of this design process is a description of the software architecture.
• Design software architectures at two levels of abstraction:
  • Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. This chapter is mostly concerned with program architectures.
  • Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.
• Software architecture affects performance, robustness, distributability, and maintainability
• Individual component: implement functional requirements
• System architecture: fulfill non-functional requirement
• Non-functional requirement also influenced by individual component, but mostly by system architecture.

Advantages

• Stakeholder communication: Architecture may be used as a focus of discussion by system stakeholders.
• System analysis: Means that analysis of whether the system can meet its non- functional requirements is possible
• Large-scale reuse: The architecture may be reusable across a range of systems. Product-line architectures may be developed.

representations

• Simple, informal block diagrams showing entities and relationships are the most frequently used method for documenting software architectures
• But these have been criticized because they lack semantics, do not show the types of relationships between entities nor the visible properties of entities in the architecture

Architectural Design Decisions

• Architectural design is a creative process so the process differs depending on the type of system being developed.
• However, a number of common decisions span all design processes and these decisions affect the non- functional characteristics of the system.
  

Architectural views

• A logical view, which shows the key abstractions in the system as objects or object classes.
• A process view, which shows how, at run-time, the system is composed of interacting processes.
• A development view, which shows how the software is decomposed for development.
• A physical view, which shows the system hardware and how software components are distributed across the processors in the system.
• Related using use cases or scenarios (+1)

9.1.1 Architectural patterns

• Patterns are means of representing, sharing and reusing knowledge.
• An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.
• Patterns should include information about when they are and when the are not useful.
• Patterns may be represented using tabular and graphical descriptions.

MVC Pattern
Model-View-Controller(MVC pattern)

This pattern is the basis of interaction management in many web-based systems.
It includes three major interconnected components:

• Model: central component of the pattern that directly manages the data, logic and rules of the application.
• View：can be any output representation of information, such as a chart or a diagram.
• Controller: accepts input and converts it to commands for the model or view, enables the interconnection between the views and the model.

Layered Pattern

Layered Pattern: the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it.
This layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users.
Performs poorly in the high-performance applications, because it is not efficient to go through multiple layers to fulfil a business request. It is a good choice for situations with a very tight budget and time constraints

Repository Patterns

Client-server Patterns

Pipe and Filter Patterns

9.2 Component-level Design

• Component-level design occurs after the first iteration of architectural design has been completed.
• A complete set of software components is defined during architectural design.
• But the internal data structures and processing details of each component are not represented at a level of abstraction that is close to code.
• Component-level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component.
• A component-level design can be represented using some intermediate representations (e.g. graphical, tabular, or text-based) that can be translated into source code.

9.2.1 Component

• A software component is a modular building block for computer software.
• It can be used to review for correctness and consistency with other components.
• It can be used to access whether data structure, interfaces and algorithms will work.
• It should provide sufficient information to guide implementation.

9.2.2 Views of component

Object-oriented view

• From an object-oriented viewpoint, a component is a set of collaborating classe.
• Each class within a component is fully elaborated to include all attributes and operations that are relevant to its implementation.
• All interfaces that enable the classes to communicate and collaborate with other design classes are also defined.

Traditional view

• Traditionally, a component is a functional element of a program that incorporates
  • processing logic
  • the internal data structures that are required to implement the processing logic.
  • an interface that enables the component to be invoked and data to be passed to it.

Process-related view

• Emphasis is placed on building system from existing components maintained in a library rather than creating each component from scratch.
• As the software architecture is developed, you choose components or design patterns from the catalog and use them to populate the architecture.

9.2.3 Component-level design process

9.3 User Interface Design

User interface design creates an effective communication medium between a human and a computer.

• A poorly designed user interface will force user to commit mistakes.
• Users can get easily frustrated using a poorly designed interface regardless of computational power or content

The golden rule

• Place the user in control
  • Provide for flexible interaction
  • Allow user interaction to be interruptible and undoable
  • Design for direct interaction with object that appear on the screen.
  • Show the visibility of system status
  • Users are much more forgiving when they have information about what is going on and are given periodic feedback about the status of the process.
• Reduce the user’s memory
  • Reduce demand on short-term memory.
  • Establish meaningful defaults:
    • Default should be what the majority of your users will want
    • Use smart defaults(geolocation, automatic calculation)
    • Don’t use defaults for input fields that require user attention such as signing up to newsletters or accepting terms of use.
  • Avoid jargon and system-oriented terms
  • When designing a product, it’s important to use language that is easy to read and understand.
  • The visual layout of the interface should be based on a real-world metaphor.
  • Using metaphors in UI design allows users to create a connection between the real world and digital experiences.
  • When choosing a metaphor for UI, select the one that will enable users to grasp the finest details of the conceptual model.
• Make the interface consistent
  • All visual information is organized according to design rules that are maintained throughout all screen displays

9.3.1 Interface Design Process

The analysis and design process for user interfaces is iterative and can be represented using a spiral model.

Interface analysis
UI design analysis focuses on the users’ goals, and the tasks they perform within a system (the application or product) to achieve those goals

• User analysis is the process of studying what type of person might use the application or product in question.
  • User Interviews: The software team meets with the end-users to better understand their needs, motivations, work culture, and a myriad of other issues.
  • Sales Input: Sales people meet with customers and users to help developers categorize users and better understand their requirements.
  • Marketing Input: Market analysis can be invaluable in the definition of market segments while providing an understanding of how each segment might use the software in different ways
  • Support Input: Support staff talks with users on a daily basis, making them the most likely source of information on what works and what doesn’t, and what they like and what they don’t.
  • The following set of questions (adapted from [Hac98]) will help you to better understand the users of a system
    • Are users trained professionals, technician, clerical, or manufacturing workers?
    • What level of formal education does the average user have?
    • Are the users capable of learning from written materials or have they expressed a desire for classroom training?
    • Are users’ expert typists or keyboard phobic?
    • What is the age range of the user
    • Will the users be represented predominately by one gender?
    • How are users compensated for the work they perform?
    • Do users work normal office hours or do they work until the job is done?
• Task analysis is the process of studying how users accomplish the tasks they set out to perform using a software system / application or other product.
  • The goal of task analysis is to answer the following questions:
    • What work will the user perform in specific circumstances
    • What tasks and subtasks will be performed as the user does the work
    • What specific problem domain objects will the user manipulate as work is performed?
    • What is the sequence of work tasks — the workflow
    • What is the hierarchy of tasks?
  • The techniques below are applied to the user interface:
    • Use-cases define basic interaction.
    • Task elaboration refines interactive tasks
    • Object elaboration identifies interface objects (classes)
    • Workflow analysis defines how a work process is completed when several people (and roles) are involved

9.3.2 Interface Design Steps

Once interface analysis has been completed, all tasks required by the end-user have been identified in detail

• Using information developed during interface analysis, define interface objects and actions (operations)
• Define events (user actions) that will cause the state of the user interface to change. Model this behavior.
• Depict each interface state as it will actually look to the end-user.
• Indicate how the user interprets the state of the system from information provided through the interface.

9.3.3 User Interface Design Patterns

available for

• The complete UI
• Page layout
• Forms and input
• Tables
• Direct data manipulation
• Navigation
• Searching
• Page elements
• e-Commerce

9.3.4 User Interface Design Issues

• Response time: System response time has 2 important characteristics: length and variability.
  • Length: It’s reported that 47% of consumers expect a web page to load in two seconds or less. Users are easily frustrated with performance and usability issues like load times, small images, and network availability.
  • Variability: Variability refers to the deviation from average response time, and in many ways, it is the most important response time characteristic
• Help facilities: Help must be available for all system functions. Include help menus, print documents.
• Error handling: describe the problem in a language the user can understand. Never blame the user for the error that
  • Provides constructive advice for recovering from the error
  • Indicates any negative consequences of the error (e.g., potentially corrupted data files) so that the user can check to ensure that they have not occurred or correct them if they have.
• Application accessibility: especially for the physically challenged.
• Internationalization: The Unicode standard has been developed to address the daunting challenge of managing dozens of natural languages with hundred of characters and symbols.
  • User interfaces should be designed to accommodate a generic core of functionality that can be delivered to all who use the software

9.3.5 Design Evaluation

Once you create an operational user interface prototype, it must be evaluated to determine whether it meets the needs of the user.

• Effectiveness:
  • The accuracy and completeness with users achieve certain goals.
  • Measures: quality of solution, error rates
• Efficiency:
  • The relation between the effectiveness and the resources expended in achiecving them
  • Measures: task completion time, learning time, number of clicks
• Satisfaction:
  • The users’ comfort with and positive attitudes towards the use of the system.
  • Measures: attitude rating scales

• Preparation
  • Determine goals of the usability testing
  • Write the user tasks
  • Recruit participants
• Sessions
  
• Results Analysis
  • Test the system, not the users
  • Respect the data and users’ responses. Do not make excuses for designs that failed.
  • If possile, use statistical summaries
  • Pay close attention to areas where users were frustrated / took a long time / could not complete tasks.
  • Note aspects of the design that worked and make sure they are incorporated in the final product.

9.3.6 Design and Implementation

Software design and implementation is the stage in the software engineering process at which an executable software system is developed.

• Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements.
• Implementation is the process of realizing the design as a program. These two activities are invariably interleaved.

Implementation Issues
Focus here is not on programming, although this is obviously important. other implementation issues that are often not covered in programming texts:

• Reuse: Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code.
  • From the 1960s to the 1990s, most new software was developed from scratch, by writing all code in a high-level programming language. Costs and schedule pressure mean that this approach became increasingly unviable, especially for commercial and Internet-based systems. An approach to development based around the reuse of existing software emerged and is now generally used for business and scientific software.
  • Reuse levels
    • The abstraction level: At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software.
    • The object level: At this level, you directly reuse objects from a library rather than writing the code yourself.
    • The component level: Components are collections of objects and object classes that you reuse in application systems.
    • The system level: At this level, you reuse entire application systems.
  • Reuse costs
    • The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs.
    • Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high.
    • The costs of adapting and configuring the reusable components or systems to reflect the requirements of the that you are developing.
    • The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed.
• Configuration management: During the development process, you have to keep track of the many different versions of each software component in a configuration management system.
  • Configuration management is the name given to the general process of managing a changing software system.
  • The aim of configuration management is to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system.
  • Management Activities
    • Version management, where support is provided to keep the different versions of software components. track of Version management systems include facilities to coordinate development by several programmers.
    • System integration, where support is provided to help define what versions of components are used to developers create each version of a system. This description is then used to build a system automatically by compiling and linking the required components.
    • Problem tracking, where support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed
• Host-target development: Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
  • More generally, we can talk about a development platform and an execution platform. A platform is more than just hardware. It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment.
  • Development platform usually has different installed software than execution platform; these platforms may have different architectures.
  • Development platform tools
    • An integrated compiler and syntax-directed editing system that allows you to create, edit and compile code.
    • A language debugging system.
    • Graphical editing tools, such as tools to edit UML models.
    • Testing tools, such as Junit that can automatically run a set of tests on a new version of a program.
    • Project support tools that help you organize the code for different development projects.
• Open source development: an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process.
  • Its roots are in the Free Software Foundation (www.fsf.org), which advocates that source code should not be proprietary but rather should always be available for users to examine and modify as they wish.
  • Open source software extended this idea by using the Internet to recruit a much larger population of volunteer developers. Many of them are also users of the code.
  • The best-known open source product is, of course, the Linux operating system which is widely used as a server system and, increasingly, as a desktop environment.
  • Other important open source products are Java, the Apache web server and the mySQL database management system
  • License models: A fundamental principle of open-source development is that source code should be freely available, this does not mean that anyone can do as they wish with that code

---

10. Software Testing

Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use.

When you test software, you execute a program using artificial data.

You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes.

Program testing goals

• To demonstrate to the developer and the customer that the software meets its requirements.
  • For custom software, this means that there should be at least one test for every requirement in the requirements document. For generic software products, it means that there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release.
• To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification
  • Defect testing is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.

Validation and defect testing

• The first goal leads to validation testing: You expect the system to perform correctly using a given set of test cases that reflect the system’s expected use.
• The second goal leads to defect testing: The test cases are designed to expose defects. The test cases in defect testing can be deliberately obscure and need not reflect how the system is normally used.

Testing process goals

• Validation testing
  • To demonstrate to the developer and the system customer that the software meets its requirements.
  • A successful test shows that the system operates as intended.
• Defect testing
  • To discover faults or defects in the software where its behaviour is incorrect or not in conformance with its specification
  • A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.

Input-output model

10.1 Verification and validation (V & V)

Testing is part of a broader process of software verification and validation (V & V)

These two processes are concerned with checking that software being developed meets its specification and delivers the functionality expected by the people paying for the software.

These checking processes start as soon as requirements become available and continue through all stages of the development process.

Verification vs validation
Verification and validation are not the same thing, although they are often confused

• Verification: Are we building the product right?
  • The aim of verification is to check that the software meets its stated functional and non-functional requirements.
• Validation: Are we building the right product?
  • The aim of validation is to ensure that the software meets the customer’s expectations.
  • More essential and general process: requirements specifications do not always reflect the real wishes or needs of system customers and users

V & V confidence
Aim of V & V is to establish confidence that the system is ‘fit for purpose’. That is, the system must be good enough for its intended use

Depends on system’s purpose, user expectations and marketing environmen.

• Software purpose: The level of confidence depends on how critical the software is to an organisation. (safety-critical system v.s. a prototype)
• User expectations: Users may have low expectations of certain kinds of software.
• Marketing environment: Getting a product to market early may be more important than finding defects in the program.

10.2 Inspections and testing

• Software inspections Concerned with analysis of the static system representation to discover problems (static verification)
  • May be supplement by tool-based document and code analysis.
• Software testing Concerned with exercising and observing product behaviour (dynamic verification)
  • The system is executed with test data and its operational behaviour is observed.

10.2.1 Software inspections

These involve people examining the source representation with the aim of discovering anomalies and defects.

Inspections not require execution of a system so may be used before implementation.

They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.).

They have been shown to be an effective technique for discovering program errors.

Advantages

• During testing, errors can mask (hide) other errors. Because inspection is a static process, you don’t have to be concerned with interactions between errors
• Incomplete versions of a system can be inspected without additional costs. If a program is incomplete, then you need to develop specialized test harnesses to test the parts that are available.
• As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability.

Disadvantages

• Inspections can check conformance with a specification but not conformance with the customer’s real requirements.
• Inspections cannot check non-functional characteristics such as performance, usability, etc.
• Inspections and testing are complementary and not opposing verification techniques.
• Both should be used during the V & V process.

10.3 Stages of testing

• Development testing, where the system is tested during development to discover bugs and defects. System designers and programmers are likely to be involved. Development testing includes all testing activities that are carried out by the team developing the system.
  • Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
    • It is a defect testing process.
    • Individual functions or methods within an object.
    • Object classes with several attributes and method. Complete test coverage of a class involves:
      • Testing all operations associated with an object.
      • Setting and interrogating all object attributes.
      • Exercising the object in all possible states.
    • Composite components with defined interfaces used to access their functionality.
  • Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.
  • System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions.
• Release testing, where a separate testing team test a complete version of the system before it is released to users. Check that the system meets the requirements of system stakeholders.
• User testing, where users or potential users of a system test the system in their own environment. The ‘user’ may be an internal marketing group. Acceptance testing where the customer formally tests.

10.3.1 Unit testing

Automated testing

• Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention.
• In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests.
• Unit testing frameworks provide generic test classes that you extend to create specific test cases. They can then run all of the tests that you have implemented and report, often through some GUI, on the success of otherwise of the tests.

Automated test components

• A setup part, where you initialize the system with the test case, namely the inputs and expected outputs.
• A call part, where you call the object or method to be tested.
• An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.

Unit test effectiveness

• Testing is expensive and time consuming, so it is important that you choose effective unit test cases. Effectiveness, in this case, means two things:
  • The test cases should show that, when used as expected, the component that you are testing does what it is supposed to do.
  • If there are defects in the component, these should be revealed by test cases.
• This leads to 2 types of unit test case:
  • The first of these should reflect normal operation of a program and should show that the component works as expected.
  • The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that these are properly processed and do not crash the component.

Testing strategies

• Partition testing: You identify groups of inputs that have common characteristics and should be processed in the same way. You should choose tests from within each of these groups.

  • Input data and output results often fall into different classes where all members of a class are related.
  • Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.
  • Test cases should be chosen from each partition.
    
  • A good rule of thumb for test case selection is to choose test cases on the boundaries of the partitions, plus cases close to the midpoint of the partition.
  • You identify partitions by using the program specification or user documentation and from experience where you predict the classes of input value that are likely to detect errors.
  • When you use the specification of a system to identify equivalence partitions, this is called ‘black-box testing’.
  • Supplemented by ‘white-box testing’

• Guideline-based testing: You use testing guidelines to choose test cases. These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components.

  We can also use testing guidelines to help choose test cases. It encapsulates knowledge of what kinds of test cases are effective for discovering errors.

  • Test software with sequences which have only a single value.
  • Use sequences of different sizes in different tests.
  • Derive tests so that the first, middle and last elements of the sequence are accessed.
  • Test with sequences of zero length.
  • Choose inputs that force the system to generate all error messages.
  • Design inputs that cause input buffers to overflow.
  • Repeat the same input or series of inputs numerous times.
  • Force invalid outputs to be generated.
  • Force computation results to be too large or too small.

10.3.2 Component testing

• Software components are often composite components that are made up of several interacting objects
• You access the functionality of these objects through the defined component interface
• Testing composite components should therefore focus on showing that the component interface behaves according to its specification. You can assume that unit tests on the individual objects within the component have been completed
• Interface testing
  • Components A, B, and C have been integrated to create a larger component or subsystem.
  • The test cases are not applied to the individual components but rather to the interface of the composite component created by combining these components.
  • Note: Interface errors in the composite component may not be detectable by testing the individual objects -> interactions between the objects in the component
  • Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.
• Interface types
  • Parameter interfaces: Data passed from one method or procedure to another.
  • Shared memory interfaces: Block of memory is shared between procedures or functions.
  • Procedural interfaces: Sub-system encapsulates a set of procedures to be called by other sub-systems.
  • Message passing interfaces: Sub-systems request services from other sub-systems.
• Interface errors
  • Interface misuse: A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order.
  • Interface misunderstanding: A calling component embeds assumptions about the behaviour of the called component which are incorrect.
  • Timing errors: The called and the calling component operate at different speeds and out-of-date information is accessed.
• Interface testing guidelines
  • Design tests so that parameters to a called procedure are at the extreme ends of their ranges.
  • Always test pointer parameters with null.
  • Design tests which cause the component to fail.
  • Use stress testing in message passing systems.
  • In shared memory systems, vary the order in which components are activated.

10.3.3 System testing

• System testing during development involves integrating components to create a version of the system and then testing the integrated system.
• The focus in system testing is testing the interactions between components
• System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces.
• System testing obviously overlaps with component testing but thereare two important differences:
  • During system testing, reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested
  • Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an individual process. In some companies, system testing may involve a separate testing team with no involvement from designers and programmers.
  • Use-case testing
    • The use-cases developed to identify system interactions can be used as a basis for system testing.
    • Each use case usually involves several system components so testing the use case forces these interactions to occur.
    • The sequence diagrams associated with the use case documents the components and interactions that are being tested.
• Testing policies: Exhaustive system testing is impossible so testing policies which define the required system test coverage may be developed.
  • All system functions that are accessed through menus should be tested.
  • Combinations of functions (e.g. text formatting) that are accessed through the same menu must be tested.
  • Where user input is provided, all functions must be tested with both correct and incorrect input.

10.4 Test-driven development

Test-driven development (TDD) is an approach to program development in which you inter-leave testing and code development.

Tests are written before code and ‘passing’ the tests is the critical driver of development.

You develop code incrementally, along with a test for that increment. You don’t move on to the next increment until the code that you have developed passes its test.

TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes.

• Start by identifying the increment of functionality that is required. This should normally be small and implementable in a few lines of code.
• Write a test for this functionality and implement this as an automated test.
• Run the test, along with all other tests that have been implemented. Initially, you have not implemented the functionality so the new test will fail.
• Implement the functionality and re-run the test.
• Once all tests run successfully, you move on to implementing the next chunk of functionality.

Benefits

• Code coverage: Every code segment that you write has at least one associated test so all code written has at least one test.
• Regression testing: A regression test suite is developed incrementally as a program is developed.
  • Regression testing is testing the system to check that changes have not ‘broken’ previously working code.
  • In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program
  • Tests must run ‘successfully’ before the change is committed.
• Simplified debugging: When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified.
• System documentation: The tests themselves are a form of documentation that describe what the code should be doing.

10.5 Release testing

Release testing is the process of testing a particular release of a system that is intended for use outside of the development team.

The primary goal of the release testing process is to convince the supplier of the system that it is good enough for use. Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use.

Release testing is usually a black-box testing process where tests are only derived from the system specification.

Release testing and system testing
Release testing is a form of system testing.

Important differences:

• A separate team that has not been involved in the system development, should be responsible for release testing.
• System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).

10.5.1 Requirements based testing

Requirements-based testing involves examining each requirement and developing a test or tests for it.

10.5.2 Scenario testing

Scenario testing is an approach to release testing where you devise typical scenarios of use and use these to develop test cases for the system.

A scenario is a story that describes one way in which the system might be used.

Scenarios should be realistic and real system users should be able to relate to them.

Features tested by scenario

• Observing how the system behaves in response to different inputs.
• Use deliberate mistakes, such as inputting the wrong keyphrase to decode records, to checks the response of the system to errors.
• Carefully note any problems that arise, including performance problems (e.g., response time)

101.5.3 Performance testing

To conduct performance test:

• An operational profile: a set of tests that reflect the actual mix of work that will be handled by the system.
• Construct: If 90% of the transactions in a system are of type A; 5% of type B; and the remainder of types C, D, and E → design the operational profile so that the vast majority of tests are of type A.

Stress testing

• Stressing the system by making demands that are outside the design limits of the software.
• Two reasons:
  • It tests the failure behavior of the system.
  • It stresses the system and may cause defects to come to light that would not normally be discovered.

10.6 User testing

User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.

User testing is essential, even when comprehensive system and release testing have been carried out. The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.

• Alpha testing: Users of the software work with the development team to test the software at the developer’s site.
• Beta testing: A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
• Acceptance testing: Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

• Define acceptance criteria: Ideally, it should take place early in the process before the contract for the system is signed. In practice, detailed requirements may not be available and there may be significant requirements change during the development process.
• Plan acceptance testing: It involves deciding on the resources, time, and budget for acceptance testing and establishing a testing schedule. Discussion about
  • the required coverage of the requirements;
  • the order in which system features are tested;
  • risks to the testing process and how to mitigate them.
• Derive acceptance tests: Once acceptance criteria have been established, tests have to be designed to check whether or not a system is acceptable. Acceptance tests should aim to test both the functional and non-functional characteristics (e.g., performance) of the system.
• Run acceptance tests: The agreed acceptance tests are executed on the system. Ideally, take place in the actual environment where the system will be used. Practically, a user testing environment may have to be set up to run these tests.
• Negotiate test results: It is very unlikely that all of the defined acceptance tests will pass and that there will be no problems with the system. The developer and the customer have to negotiate to decide if the system is good enough to be put into use. They must also agree on the developer’s response to identified problems.
• Reject/accept system: This stage involves a meeting between the developers and the customer to decide on whether or not the system should be accepted. If the system is not good enough for use, then further development is required to fix the identified problems. Once complete, the acceptance testing phase is repeated.

Agile methods and acceptance testing
In agile methods, the user/customer is part of the development team and is responsible for making decisions on the acceptability of the system.

Tests are defined by the user/customer and are integrated with other tests in that they are run automatically when changes are made.

There is no separate acceptance testing process.

Main problem here is whether or not the embedded user is ‘typical’ and can represent the interests of all system stakeholders

---

11. Project Management

An essential part of software engineering. Projects need to be managed because professional software engineering is always subject to organizational budget and schedule constraints. Ensure that the software project meets and overcomes these constraints as well as delivering high-quality software.

Good management cannot guarantee project success BUT a bad management may result:

• Late deliver
• Increase cost
• Fail to meet the expectations of customers

Criteria for Project Management

• Deliver the software to the customer at the agreed time.
• Keep overall costs within budget.
• Deliver software that meets the customer’s expectations.
• Maintain a happy and well-functioning development team.

Challenges in Project Management

• The product is intangible. Software cannot be seen or touched.
• Large software projects are often ‘one-off’ projects. Lessons learned from previous projects may not be transferable to new projects.
• Software processes are variable and organization specific. software processes vary quite significantly from one organization to another, cannot reliably predict when a particular software process is likely to lead to development problems.

Manager’s Responsibilities

• Project Planning: Planning, estimating and scheduling project development, assigning people to tasks, and supervising them.
• Reporting: Reporting on the progress of a project to customers and to the managers of the company developing the software.
• Risk management: Assess the risks that may affect a project, monitor these risks, and take action when problems arise.
• People management: Choose people for their team and establish ways of working.
• Proposal writing: Writing a proposal to win a contract to carry out an item of work.

A Good Project Manager

• Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability.
• Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.
• Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.
• Problem solving. An effective software project manager can diagnose the technical and organizational issues.
• Managerial identity. A good project manager must take charge of the project. They must have the confidence to assume control when necessary and the assurance to allow good technical people to follow their instincts.
• Achievement. A competent manager must reward initiative and accomplishment to optimize the productivity of a project team.
• Influence and team building. An effective project manager must be able to “read” people; they must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals.

11.1 Risk management

Risk management involves anticipating risks that might affect the project schedule or the quality of the software being developed, and then taking action to avoid these risks.

Three related categories of risks:

• Project risks: Risks that affect the project schedule or resources (e.g., loss of an experienced designer).
• Product risks: Risks that affect the quality or performance of the software being developed (e.g., failure of a purchased component to perform as expected).
• Business risks: Risks that affect the organization developing or procuring the software (e.g., a new product from competitors).

These risk types overlap.

11.1.1 Risk Management Process

Risk identification
Identify possible project, product, and business risks.

• First stage of the risk management process, concerning with identifying major risks.
• Can be a team process
• Can solely rely on managers’ experiences
• Risk Checklist:
  • Technology risk
  • People risk
  • Organizational risk
  • Tool risk
  • Requirement risk
  • Estimation risk

Risk analysis
Assess the likelihood and consequences of these risks.

• To consider each identified risk and make a judgment about the probability and seriousness of that risk.
• Probability: Very low ($<10\%$), low ($10–25\%$), moderate ($25–50\%$), high ($50–75\%$), or very high ($>75\%$)
• Seriousness
  • catastrophic (threaten the survival of the project)
  • serious (would cause major delays)
  • tolerable (delays are within allowed contingency)
  • insignificant

Risk planning
Plans to address the risk, either by avoiding it or minimizing its effects on the project.

• To consider each of the key risks that have been identified, and develops strategies to manage these risks.
• To think of actions that you might take to minimize the disruption to the project if the problem identified in the risk occurs.
• To think about information that you might need to collect while monitoring the project so that problems can be anticipated.

Three categories of strategies

• Avoidance strategies: Following these strategies means that the probability that the risk will arise will be reduced. (e.g., Defective components)
• Minimization strategies: Following these strategies means that the impact of the risk will be reduced. (e.g., Staff illness)
• Contingency plans: Following these strategies means that you are prepared for the worst and have a strategy in place to deal with it. (e.g., Organizational financial problems)

Risk monitoring
Regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk.

• Risk monitoring is the process of checking that your assumptions about the product, process, and business risks have not changed.
• Regularly assess each of the identified risks to decide whether or not that risk is becoming more or less probable.
• Also think about whether or not the effects of the risk have changed.

11.2 Managing People

The software process (and every software project) is populated by stakeholders who can be categorized into one of five constituencies:

• Senior managers who define the business issues that often have a significant influence on the project.
• Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work.
• Practitioners who deliver the technical skills that are necessary to engineer a product or application.
• Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.
• End users who interact with the software once it is released for production use.

People working in a software organization are its greatest assets. Costs a lot to recruit and retain good people. Ensure that the organization gets the best possible return on its investment.

Unfortunately, however, good software engineers are not necessarily good people managers. They have strong technical skills but may lack the softer skills.

Four critical factors in people management:

• Consistency: People in a project team should all be treated in a comparable way.
• Respect: Different people have different skills and managers should respect these differences.
• Inclusion: People contribute effectively when they feel that others listen to them and take account of their proposals.
• Honesty: Should always be honest about what is going well and what is going badly in the team.

Motivating People
A project manager, you need to motivate the people that work with you so that they contribute to the best of their abilities. Motivation means organizing the work and the working environment to encourage people to work as effectively as possible.

Maslow (1954) suggests that people are motivated by satisfying their needs.

• People working in software development organizations are not usually hungry or thirsty or physically threatened by their environment.
• To satisfy social needs, you need to give people time to meet their co-workers and provide places for them to meet.
• To satisfy esteem needs, you need to show people that they are valued by the organization.
• To satisfy self-realization needs, you need to give people responsibility. for their work, assign them demanding (but not impossible) tasks, and provide a training programme where people can develop their skills.

Personality type also influences motivation.

• Task-oriented people, who are motivated by the work they do. In software engineering, these are people who are motivated by the intellectual challenge of software development.
• Self-oriented people, who are principally motivated by personal success and recognition. They are interested in software development as a means of achieving their own goals.
• Interaction-oriented people, who are motivated by the presence and actions of co-workers. As software development becomes more user-centered, interaction-oriented individuals are becoming more involved in software engineering.

11.3 Software Team and Teamwork

11.3.1 The Software Team

Four “organizational paradigms” for software engineering teams:

• A closed paradigm structures a team along a traditional hierarchy of authority.
• A random paradigm structures a team loosely and depends on individual initiative of the team members.
• An open paradigm attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm.
• A synchronous paradigm relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves.

11.3.2 Teamwork

It is clearly impossible for everyone in a large group to work together on a single problem, large teams are usually split into a number of groups.

Putting together a group that has the right balance of technical skills, experience, and personalities is a critical management task.

In a cohesive group, members think of the group as more important than the individuals who are group members.

Benefits of creating a cohesive group:

• The group can establish its own quality standards. Because these standards are established by consensus, they are more likely to be observed than external standards imposed on the group.
• Individuals learn from and support each other. People in the group learn from each other. Inhibitions caused by ignorance are minimized as mutual learning is encouraged.
• Knowledge is shared. Continuity can be maintained if a group member leaves. Others in the group can take over critical tasks and ensure that the project is not unduly disrupted.
• Refactoring and continual improvement is encouraged Group members work collectively to deliver high-quality results and fix problems, irrespective of the individuals who originally created the design or program.

Good project managers should always try to encourage group cohesiveness

• Organize social events.
• Naming the group and establishing a group identity and territory.
• Explicit group-building activities such as sports and games.
• Be inclusive.

Whether or not a group is effective depends, to some extent, on the nature of the project and the organization doing the work. However, apart from project and organizational issues, there are three generic factors that affect team working:

• The people in the group
• The group organization
• Technical and managerial communications

11.3.3 Selecting group members

Many software engineers are motivated primarily by their work. Software development groups, therefore, are often composed of people who have their own ideas about how technical problems should be solved.

A group that has complementary personalities may work better than a group that is selected solely on technical ability.

• People who are motivated by the work are likely to be the strongest technically.
• People who are self-oriented will probably be best at pushing the work forward to finish the job.
• People who are interaction-oriented help facilitate communications within the group

11.3.4 Group organization

Organizational Questions to be considered:

• Should the project manager be the technical leader of the group?
• Who will be involved in making critical technical decisions, and how will these be made?
• How will interactions with external stakeholders and senior company management be handled?
• How can groups integrate people who are not colocated?
• How can knowledge be shared across the group?

11.3.5 Group communications

It is absolutely essential that group members communicate effectively and efficiently with each other and with other project stakeholders.

• Group members must exchange information on the status of their work, the design decisions that have been made, and changes to previous design decisions.
• They have to resolve problems that arise with other stakeholders and inform these stakeholders of changes to the system, the group, and delivery plans.
• Good communication also helps strengthen group cohesiveness. Group members come to understand the motivations, strengths, and weaknesses of other people in the group.

The effectiveness and efficiency of communications is influenced by:

• Group size: As a group gets bigger, it gets harder for members to communicate effectively.
• Group structure: People in informally structured groups communicate more effectively than people in groups with a formal, hierarchical structure.
• Group composition: People with the same personality types may clash and, as a result, communications can be inhibited
• The physical work environment: The organization of the workplace is a major factor in facilitating or inhibiting communications.
• The available communication channels: face-to-face, e-mail messages, formal documents, telephone, and Web 2.0 technologies such as social networking and wikis