If required changes are identified in testing, the replacement lifecycle may start at stage 1, 2 or 3 of the ‘V-Model’ – additionally, stage 5 of waterfall may become stage 1 of ‘Spiral’. The V-Model allows organisation of phases with a focus on and the allowance for a recursive path at each past-halfway stage.
Each lower level is of less complexity than the one above, to create a central implementation phase that is the least complex of all. Each layer matches up conceptually with the opposite. E.g. the final stage of operations and maintenance relate/refer directly to the initial layer concept of operations – additionally, ‘Testing and Integration’ definitions relate directly to the opposite preceding ‘Design’ layer.
V-Model is modified as ‘Dual-Vee’ to include ‘mini-cycles’ for more compartmentalised projects. Two variants, the Entity vee and Architecture vee are able to be interconnected in plan design, the former provides a project overview while the latter defines the process for individual component development of processing entities such as objects, modules or increments.
There are SDLCs and then there are SDA (Software Development Approaches), many of which incorporate specific SDLCs with augmentations. SDLCs are predictive or adaptive, defining course of development, whilst SDAs are structured or object oriented to define the organisation of the system’s parts. Their usage provides established frameworks for software development, beneficially supporting planning, operations and management.
Base cycle for typical Agile+Lean developments
There are even methodologies for the initial stage of development, to aid the transition into deep design and construction.
The maintenance / support phase (MS), generally at the end of a cycle, is considered as methodology applicable. Recommended structural approaches to MS are availability of ‘helpdesk’ support personnel, planned maintenance and defined activities for enhancement of the system.
Regarding systems that are already established and only require maintenance and incremental improvement of forthcoming requirements, DevOps (Development + Operations) is a good choice for a further development methodology to apply as it dictates a focus on equal priority of users, shortening feedback loops at level and a promise to experiment.
Focusing on reversing the eager objection to change found in separated groups within the same organisation, DevOps attempts to join the influences of the Operations, Development and Quality Assurance teams and other organisational structures.
Scheduling time to communicate with eachother to create an Agile workflow within a structured collaborative environment, DevOps implementation leads to producing more applications faster by using application support services from an assortment of DevOps tools such as ‘test automation’, ‘application release automation’ and ‘code merging’.
One aspect of investigation and design to be considered, that is often overlooked, is the project’s development environment. Developments are generally ill-prepared for if team and organisational dynamics, politics, regulations, competition and methodology are not considered and a balance between financing, scope, resources and time is not maintained.
Choice of the top-level dictates the validity of modelling, context diagrams can be used to aid with establishment of a top-level. Context diagrams can use a centered object that all other relevant objects are interacting with or a sub-process of. The center object in a working context diagram should be treated as the highest-level to be modelled.
“Depending on the use case or user, there are different tools that do what we need to do” Bryan Lari, director of Anderson institutional analytics at the University of Texas.