Showing papers on "V-Model (software development) published in 2013"
26 Aug 2013
TL;DR: A new approach is proposed, called "sliced V-model", where documents are split into work items and these work items are linked between the documents, forming small and independent "V" shapes, which downsizes the efforts for keeping documents updated, simplifies the management of trace ability and increases flexibility.
Abstract: Companies requiring a formal software process model tend to choose the V-model. Having its advantages in a strong focus on verification and validation, the main drawbacks of the V-model are the need to create a large amount of documentation, to keep this documentation continuously updated and to manage trace ability of requirements implementation and testing. As it is based on the waterfall process model the timing behavior of the V-model is considered to be stiff. Additional complexity arises whenever teams work together in globally distributed environments. All these aspects reduce the software productivity of the teams when using the V-model. It is known that agile processes solve some of the mentioned problems. However, agile processes are not always accepted in formal environments, e.g., if certification bodies need to approve safety critical developments. This article proposes a new approach, called "sliced V-model", where documents are split into work items and these work items are linked between the documents, forming small and independent "V" shapes. Working with such so-called "V" slices downsizes the efforts for keeping documents updated, simplifies the management of trace ability and increases flexibility. Since the sliced V-model requires the utilization of a web-based repository, it is easy to apply in globally distributed teams. An example of successful implementation in a globally operating industry company is shown.
12 citations
BMW1
TL;DR: This chapter describes the approach to develop software components along the well-known V-Model, from the analysis phase to the test phase of the function oriented development process, and all tools supporting the different phases are demonstrated.
Abstract: The number of software supported systems in vehicles is constantly growing. All carmakers have more or less problems to handle the high number of software functions. Because, traditionally, each function is implemented by a separate control unit, also the number of control units has reached a tremendous level. The key points to master this situation are reusing und integration of functions. The AUTOSAR standard supports both approaches by defining standardized interfaces for software components. This chapter describes the approach to develop software components along the well-known V-Model. All process phases, from the analysis phase to the test phase of the function oriented development process are shown. Furthermore, all tools supporting the different phases are demonstrated.
4 citations
1 Jan 2013
TL;DR: By enabling feature testing with these data’s, this research attempts to answer the question "Requirements Engineering, Development and Testing – Skills Needed by Future Tester", concerned with the feature testing era.
Abstract: Every day many of us have been introduced to latest Testing life cycle, Tools, webinars, articles and books published by testing vendors. By enabling feature testing with these data’s, our research attempts to answer the question "Requirements Engineering, Development and Testing – Skills Needed by Future Tester". It is concerned with the feature testing era that examine the area of Requirements Engineering, Development and Testing through the development models, which are known as software development life cycle. At presents there are different development models namely, waterfall, Spiral, RAD, V Model, W Model, Systems of Systems, Safety critical systems, Prototyping, Extreme programming and Agile Model. These have resulted in testing era asking a new set of questions to testers, like what sort of Skills Needed by Future Tester?, Factors driving these changes include business dynamics, changes in underlying technology, a deeper understanding of quality and user experience, and now we are at an interesting journey on what the future holds for this discipline, moving into a zone of what sort of skills are becoming inevitable for Future Testers community. When there is a future testing model arrives, this paper examines all these future stuffs with a detailed analysis.
1 citations
1 Jan 2013
TL;DR: By conducting semi structured interviews with seven medical device software organisations, a deeper insight was gained into how the challenges experienced impact on the development of medical device software.
Abstract: Medical device software organisations face challenges not faced by generic software development organisations. These challenges include the adherence to regulatory controls. Regulatory bodies require medical device software organisations to provide objective evidence that the software they are developing is safe and reliable. To produce this, regulatory bodies require a number of deliverables which must be achieved. However, they do not dictate which Software Development Life Cycle (SDLC) must be followed in order to achieve these deliver-ables. Despite not dictating which SDLC must be followed when developing medical device software, organisations typically develop their software in accordance with a Plan-Driven software development lifecycle. By conducting semi structured interviews with seven medical device software organisations, we gained a deeper insight into how the challenges experienced impact on the development of medical device software. The interviews also attempted to learn from the participants how they believe the challenges experienced can be overcome. The aim of this paper is to explain the methodology used to perform interviews with medical device software organisations and to present these interviews.