Génie logiciel

Software life cycle

•The software life cycle refers to all stages of software development, from its design to its disappearance.

•The purpose of such a division is to make it possible to define intermediate milestones that enable validation of software development, that is, conformity of software to identified requirements, and verification of the development process, that is to say adequacy of the methods used

The origin of this division comes from the observation that errors have a higher cost if they are detected later in the production process. The life cycle allows for rapid detection of errors and thus control of software quality, its production deadlines and associated costs.

•The software life cycle is usually at least the following stages:

Requirements and feasibility analysis

•that is, the identification, integration and formulation of the applicant’s (client’s) needs and any constraints, then estimating the feasibility of those needs;

•General specifications or design

•this includes the development of specifications for the general architecture of the software;

•Detailed design

•this step consists of precisely describing each subset of the software;

•Coding (Functions or programming) .

•is the translation into programming language of the features defined during the design phases;

•Unit tests

•they provide a means of individually checking whether each software subassembly has been manufactured according to specifications;

The combination of objects

•the objective is to ensure the interface of the different elements (modules) of the software. It is a matter of integration tests written in a document;

•Qualification (or recipe) .

•means verification of software conformity to initial specifications;

•Writing letters

•aims to generate information necessary for the implementation of the software and for subsequent developments;

•Putting into production

•is the on-site deployment of the software;

•Improve

•contains all corrective (corrective maintenance) and evolutionary (evolutionary maintenance) actions in the software.

The order and availability of each of these activities in the lifecycle depends on the choice of lifecycle model between the client and the development team. Lifecycle allows us to take into account, in addition to technical, organizational and less human aspects.

Software life cycle models

•be. Waterfall life cycle model

In this model the principle is very simple: each phase ends on a specific date with the production of certain documents or software. The results are described in terms of interactions between stages, subjected to a thorough review and we only proceed to the next stage if judged to be satisfactory.

•The original model had no possibility of going backwards. This is then added on the basis that a step merely challenges a previous step, which, in practice, has been shown to be inadequate.

•A major disadvantage of the waterfall lifecycle model is that the verification of correct system operation occurs too late: during the integration phase, or worse, during production.

V-shaped life cycle model

The Model V now remains the most popular life cycle and certainly the most used. It is a waterfall model in which testing and software development are done synchronously.

•The principle of this model is that in every decomposition a recomposition must be described and that every description of a component is accompanied by tests that make it match its description.

•This makes clear the organization of the final (validation-verification) and first (software construction) phases, and thus allows to avoid the well-known pitfall of software specification: stating a property that is impossible to verify objectively after eliminate it.

•However, this model still has the problem of checking the correct operation of the system too late.

Spiral life cycle model

•this model is much more general than the previous one. It emphasizes the risk assessment process: each cycle of the spiral occurs in four phases:

•Assessment, based on the results of previous cycles, or preliminary needs analysis, of the cycle goals, alternatives for achieving them and constraints;

•Risk assessment, alternatives analysis and, possibly, modeling;

•Development and evaluation of the chosen solution, the “classical” model (cascade or V) can be used here;

•Review results and next cycle analysis.

•Preliminary assessment is organized during the initial cycles. The model uses exploratory mockups to guide the design phase of the next cycle. The final cycle ends with the classical development process.

The incremental model

•In older models, software is divided into separately developed components and assembled at the end of the process.

•In incremental models only one set of components is created at a time: the increments are integrated into the previously created software kernel. Each increment is designed according to one of the previous models.

•The advantages of this type of model are as follows:

•each development is less complex;

•integrations are progressive;

•it is therefore possible to assign and commission each increment;

•allows for better control of time and power generation thanks to the possibility of overlapping (paralleling) the different phases.

•The risks of this type of model are as follows:

•call into question previous increments or worse in principle;

•inability to collect new increments.

•The cores, increments as well as their interactions with the rest of the world should therefore be specified at the beginning of the project. The increments should be as independent as possible, functionally, but also in terms of development time.

Methods of analysis and design

•Analysis and design methods provide standard methodology and notations that aid in quality software design. There are various ways to share these skills, e.g.

•Difference between composition and decomposition:

•It distinguishes, on the one hand, bottom-up methods that consist of building software by composition from existing modules and, on the other hand, top-down methods that recursively decompose the system until it reaches modules simply programmable ;

•Difference between functional (process-driven) and object-oriented:

•In functional (also called structured) strategy the system is seen as a hierarchical set of interacting units, each with a clearly defined function. Functions have a local state, but the system has a shared state, which is centralized and accessible to all functions. Object-oriented strategies consider that a system is a set of interacting objects. Each object has a set of attributes describing its state and the state of the system is described (in a decentralized way) by the state of the whole.

•VI- From structured programming to object oriented approach

•VI-1 Methods of operation or structured

•Functional methods (also called structured methods) originate from procedural languages. They highlight the functions to be performed and propose a hierarchical, top-down and modular approach.
•Each level is then expanded with respect to higher level inputs/outputs. Decomposition continues until controllable components are reached.

•The functional approach dissociates the problem of representing data from the problem of processing this data

•b. Object-oriented approach

•The approach views software as a collection of discrete, identified and characterized objects. An attribute is either an attribute (i.e. data indicating the state of an object), or a feature of an object's characteristics (i.e. a function). Software functionality then emerges from the interaction between the different objects that constitute it. One of the peculiarities of this approach is that it combines data and its associated processing into a single object.