Software Development in Project and Product Contexts

The requirements for planning and traceability of development and testing vary according to the context. Likewise, the appropriateness of a particular lifecycle model for the development of a specific product also depends on the contexts within which it is developed and used. The following project-and product-based factors play a role in deciding which model to use:

• The company’s business priorities, project objectives, and risk profile. For example, if time-to-market is a primary requirement.
• The type of product being developed. A small (perhaps department-internal) system has a less demanding development process than a large project designed for multi-year use by a huge customer base, such as our VSR-II case study project. Such large products are often developed using multiple models.
• The market conditions and technical environment in which the product is used. For example, a product family developed for use in the Internet of Things (IoT) can consist of multiple types of objects (devices, services, platforms, and so on), each of which is developed using a specific and suitable lifecycle model. Because IoT objects are used for long periods of time in large numbers, it makes sense if their operational usage (distribution, updates, decommissioning, and so on) is mirrored in specific phases or catalogs of tasks within the lifecycle model. This makes developing new versions of such a system particularly challenging.
• Identified product risks. For example, the safety aspects involved in designing and implementing a vehicle braking system.
• Organizational and cultural aspects. For example, the difficulties generated by communication within international teams can make iterative or agile development more difficult.

Mixing development models in the VSR-II project

One of the objectives of the VSR-II project is to make it “as agile as possible”, so the DreamCar module and all the browser-based front-end components and subsystems are developed in an agile Scrum environment. However, because they are safety-critical, the ConnectedCar components are to be developed using the traditional V-model.

Prototyping [URL: Prototyping] is also an option early on in a project and, once the experimental phase is complete, you can switch to an incremental approach for the rest of the project.

Tailoring

A development model can and should be adapted and customized for use within a specific project. This adaptation process is called “tailoring”.

Tailoring can involve combining test levels or certain testing activities and organizing them especially to suit the project at hand. For example, when integrating off-the-shelf commercial software into a larger system, interoperability tests at the integration testing stage (for example, when integrating with existing infrastructure or systems) can be performed by the customer rather than the supplier, as can acceptance testing (functional and non-functional operational and customer acceptance tests).

The tailored development model then comprises a view of the required activities, timescales, and objectives that is binding for all project participants. Any detailed planning (schedules, staffing, and infrastructure allocation) can then utilize and build upon the tailored development model.

Attributes of good testing

Regardless of which lifecycle model you choose, your tailoring should support good and effective testing. Your testing approach should include the following attributes:

• Testing and its associated activities are included as early as possible in the lifecycle—for example, drafting test cases and setting up the test environment (see the principle of early testing above).
• For every development activity, a corresponding test activity is planned and executed.
• Test activities are planned and managed specifically to suit the objectives of the test level they belong to.
• Test analysis and test design begin within the corresponding development phase.
• As soon as work products (requirements, user stories, design documents, code etc.) exist, testers take part in discussions that refine them. Testers should participate early and continuously in this refinement process.