Software development is impossible without understanding the so-called life cycle programs. An ordinary user may not need to know this, but it is desirable to learn the basic standards (it will be said later why this is necessary).
What is the life cycle in the formal sense?
Under the life cycle of any, it is customary to understand the time of its existence, starting from the development stage and until the moment of complete abandonment of use in the chosen field of application, up to the complete removal of the application from use.
In simple terms, information systems in the form of programs, databases, or even operating systems are in demand only if the data and the opportunities they provide are relevant.
It is believed that the definition of life cycle does not apply in any way to test applications, such as beta versions, which are the most unstable in operation. The software life cycle itself depends on many factors, among which one of the main roles is played by the environment in which the program will be used. However, one can distinguish General terms used in defining the life cycle concept.
Initial requirements
- formulation of the problem;
- analysis of mutual requirements of future software to the system;
- design;
- programming;
- coding and compilation;
- testing;
- debugging;
- implementation and maintenance of the software product.
Software development consists of all the above-mentioned stages and cannot do without at least one of them. But to control such processes, special standards are established.
Software Life Cycle Process Standards
Among the systems that predetermine the conditions and requirements for such processes, today only three main ones can be named:
- GOST 34.601-90;
- ISO/IEC 12207:2008;
- Oracle CDM.
For the second international standard there is a Russian equivalent. This is GOST R ISO / IEC 12207-2010, which is responsible for systems and software engineering. But the life cycle software, described in both rules, is essentially identical. This is explained quite simply.
Types of software and updates
By the way, for most of the currently known multimedia programs, they are the means of saving the main configuration settings. The use of this type of software is, of course, rather limited, but understanding the general principles of working with the same media players does not hurt. And that's why.
In fact, they have a software life cycle only at the level of the update period for the version of the player itself or the installation of codecs and decoders. And audio and video transcoders are essential attributes of any audio or video system.
Example based on FL Studio
Initially, the virtual studio-sequencer FL Studio was called Fruity Loops. The life cycle of the software in its primary modification has expired, but the application has been somewhat transformed and acquired its current form.
If we talk about the stages of the life cycle, at first, at the stage of setting the task, several mandatory conditions were set:
- creating a drum module similar to rhythm machines like the Yamaha RX, but using one-shot samples or WAV sequences recorded live in studios;
- integration into Windows operating systems;
- the ability to export the project in WAV, MP3 and OGG formats;
- project compatibility with the additional application Fruity Tracks.
At the development stage, the tools of the C programming languages were used. But the platform looked rather primitive and did not allow the end user required quality sound.
In this regard, at the stage of testing and debugging, the developers had to follow the path of the German corporation Steinberg and apply Full Duplex mode support in the requirements for the main sound driver. The quality of the sound has become higher and allows you to change the tempo, pitch and apply additional FX effects in real time.
The end of the life cycle of this software is considered to be the release of the first official version of FL Studio, which, unlike its ancestors, already had a full-fledged sequencer interface with the ability to edit parameters on a virtual 64-channel mixing console with unlimited addition of audio tracks and MIDI tracks.
This was not limited. At the project management stage, support was introduced for connecting plug-ins in the VST format (first the second, and then the third version), once developed by Steinberg. Roughly speaking, any virtual synthesizer that supports VST-host could connect to the program.
It is not surprising that soon any composer could use analogues of the "iron" models, for example, the complete sets of sounds of the once popular Korg M1. Further more. The use of modules like Addictive Drums or the universal Kontakt plug-in made it possible to reproduce the live sounds of real instruments recorded with all shades of articulation in professional studios.
At the same time, the developers tried to achieve maximum quality by creating support for ASIO4ALL drivers, which turned out to be head and shoulders above the Full Duplex mode. Accordingly, the bitrate also increased. To date, the quality of the exported audio file can be 320 kbps at a sampling rate of 192 kHz. This is professional sound.
As for the initial version, its life cycle could be called completely finished, but such a statement is relative, since the application has only changed its name and gained new features.
Development prospects
What are the stages of the software life cycle is already clear. But the development of such technologies is worth mentioning separately.
Needless to say, any software developer is not interested in creating a fleeting product that is unlikely to stay on the market for a few years. In the future, everyone is looking at its long-term use. This can be achieved in different ways. But, as a rule, almost all of them come down to the release of updates or new versions of programs.
Even in the case of Windows, such trends can be seen with the naked eye. It is unlikely that today there will be at least one user using systems like modifications 3.1, 95, 98 or Millennium. Their life cycle ended after the release of the XP version. But server versions based on NT technologies are still relevant. Even Windows 2000 today is not only very up-to-date, but even surpasses the latest developments in some installation or security parameters. The same applies to the NT 4.0 system, as well as a specialized modification of Windows Server 2012.
But in relation to these systems, support is still declared at the highest level. But the sensational Vista in its time is clearly experiencing the decline of the cycle. Not only did it turn out to be unfinished, but there were so many errors in itself and gaps in its security system that one can only guess how such an untenable solution could be released to the software market.
But if we talk about the fact that the development of software of any type (control or application) does not stand still, it is only possible. After all, today it concerns not only computer systems, but also mobile devices, in which the technologies used are often ahead of the computer sector. The emergence of processor chips based on eight cores - than not the most best example? But not every laptop can boast of having such a hardware.
Some additional questions
As for the understanding of the software life cycle, it is possible to say that it ended at some specific point in time, it is very conditional, because software products still have support from the developers who created them. Rather, the ending refers to legacy applications that do not meet the requirements modern systems and cannot work in their environment.
But even taking into account technical progress many of them may soon become untenable. That's when you will have to make a decision either to release updates, or to completely revise the entire concept that was originally incorporated into the software product. Hence the new cycle, which involves changing the initial conditions, the development environment, testing and possible long-term application in a certain area.
But in computer technology Today, preference is given to the development of automated control systems (ACS), which are used in production. Even operating systems, in comparison with specialized programs, lose.
The same Visual Basic-based environments remain much more popular than Windows systems. And we are not talking about application software for UNIX systems at all. What can I say, if almost all communication networks of the same United States work exclusively for them. By the way, systems like Linux and Android were also originally created on this platform. Therefore, most likely, UNIX has much more prospects than other products combined.
Instead of total
It remains to add that in this case only general principles and stages of the software life cycle. In fact, even the initial tasks can differ very significantly. Accordingly, differences can be observed at other stages.
But the basic technologies for developing software products with their subsequent maintenance should be clear. For the rest, one should take into account the specifics of the software being created, the environments in which it is supposed to work, and the capabilities of the programs provided to the end user or production, and much more.
In addition, sometimes life cycles can depend on the relevance of development tools. If, for example, some programming language becomes obsolete, no one will write programs based on it, and even more so - implement them in automated systems production management. Here, not even programmers, but marketers come to the fore, who must respond in a timely manner to changes in the computer market. And there are not so many such specialists in the world. Highly qualified personnel capable of keeping abreast of the market are becoming the most in demand. And it is they who are often the so-called "gray cardinals", on which the success or failure of a certain software product in the IT field depends.
Although they do not always understand the essence of programming, they are clearly able to determine software life cycle models and the duration of their use, based on global trends in this area. Effective management often produces more tangible results. Yes, at least PR technologies, advertising, etc. The user may not need some application, but if it is actively advertised, the user will install it. This is already, so to speak, a subconscious level (the same effect of the 25th frame, when information is put into the user's mind regardless of himself).
Of course, such technologies are prohibited in the world, but many of us do not even realize that they can still be used and affect the subconscious in a certain way. What is the “zombification” of news channels or Internet sites worth, not to mention the use of more powerful means, such as exposure to infrasound (this was used in one opera production), as a result of which a person may experience fear or inadequate emotions.
Returning to the software, it is worth adding that some programs use a sound signal at startup to attract the user's attention. And studies show that such applications are more viable than other programs. Naturally, the life cycle of the software also increases, no matter what function it was originally assigned to. And this, unfortunately, is used by many developers, which raises doubts about the legality of such methods.
But it is not for us to judge this. It is possible that in the near future tools will be developed to identify such threats. So far, this is only a theory, but, according to some analysts and experts, before practical application there is very little left. If they are already creating copies of the neural networks of the human brain, then what can I say?
The concept of "life cycle" implies something that is born, develops and dies. Like a living organism, software products are created, operated, and evolve over time.
Life cycle software includes all stages of its development: from the emergence of a need for it to the complete cessation of its use due to obsolescence or the loss of the need to solve relevant problems.
There are several phases of the existence of a software product during its life cycle. There are as yet no generally accepted names for these phases and their number. But there is no particular disagreement on this issue. Therefore, there are several options for breaking down the software life cycle into stages. The question of whether a particular partition is better than others is not the main one. The main thing is to properly organize software development taking into account them.
According to the duration of the life cycle, software products can be divided into two classes: small And big time life. These classes of programs correspond to a flexible (soft) approach to their creation and use and a hard industrial approach to the regulated design and operation of software products. In scientific organizations and universities, for example, the development of first-class programs prevails, while in design and industrial organizations - the second.
Software products with a short lifespan are created mainly to solve scientific and engineering problems, to obtain specific results of calculations. Such programs are usually relatively small. They are developed by one specialist or a small group. main idea program is discussed by one programmer and end user. Some details are put on paper, and the project is implemented within a few days or weeks. They are not intended for replication and transfer for subsequent use in other teams. As such, such programs are part of a research project and should not be considered disposable software products.
Their life cycle consists of a long period of system analysis and formalization of the problem, a significant stage of program design and a relatively short time of operation and obtaining results. The requirements for functional and design characteristics, as a rule, are not formalized; there are no formalized program tests. Their quality indicators are controlled only by developers in accordance with their informal ideas.
Software products with a short lifespan
Maintenance and modification of such programs is not mandatory, and their life cycle is completed after receiving the results of calculations. The main costs in the life cycle of such programs fall on the stages of system analysis and design, which last from a month to 1 ... 2 years, as a result
that the life cycle of a software product rarely exceeds 3 years.
Software products with a long service life created for regular information processing and management. The structure of such programs is complex. Their sizes can vary over a wide range (1...1000 thousand commands), but they all have the properties of cognizability and the possibility of modification in the process of long-term maintenance and use by various specialists. Software products of this class can be replicated, they are accompanied by documentation as industrial products and are software products alienated from the developer.
Software products with a long service life
Their design and operation are carried out by large teams of specialists, which requires the formalization of the software system, as well as formalized testing and determination of the achieved quality indicators of the final product. Their life cycle is 10...20 years. Up to 70...90% of this time falls on operation and maintenance. Due to mass replication and long-term maintenance, the total costs during the operation and maintenance of such software products significantly exceed the costs of system analysis and design.
All subsequent presentation focuses on the development of large (complex) software tools for managing and processing information.
Generalized model life cycle The software product might look like this:
I. System analysis:
a) research;
b) feasibility study:
operational;
Economic;
Commercial.
II. Software design:
a) design:
Functional decomposition of the system, its architecture;
External software design;
Database design;
Software architecture;
b) programming:
Internal software design;
External design of software modules;
Internal design of software modules;
Coding;
Debugging programs;
Program layout;
c) software debugging.
III. Evaluation (testing) of software.
IV. Software use:
a) operation;
b) support.
I. System analysis. At the beginning of software development, a system analysis is carried out (its preliminary design), during which the need for it, its purpose and main functional characteristics are determined. The costs and possible efficiency of the application of the future software product are estimated.
At this stage, a list of requirements is compiled, that is, a clear definition of what the user expects from the finished product. Here, goals and objectives are set, for the sake of which the project itself is being developed. In the phase of system analysis, two directions can be distinguished: research and feasibility analysis.
Research begins from the moment the development manager realizes the need for software.
The work consists in planning and coordinating the actions necessary to prepare a formal handwritten list of requirements for the developed software product.
Research ends when the requirements are formed in such a way that they become visible and, if necessary, can be modified and approved by the responsible manager.
Feasibility study There is technical part research and begins when the intention of the management is strong enough that a project manager is appointed to organize the design and distribution of resources (labor).
The work consists in the study of the proposed software product in order to obtain a practical assessment of the possibility of implementing the project, in particular, the following are determined:
- operational feasibility , Will the product be comfortable enough for practical use?
- economic feasibility , Is the cost of the developed product acceptable? What is this cost? Will the product be a cost effective tool in the hands of the user?
- commercial feasibility, Will the product be attractive, marketable, easy to install, serviceable, easy to learn?
These and other questions need to be addressed mainly when considering the above requirements.
The feasibility study ends when all requirements have been collected and approved.
Before continuing further work on the project, it is necessary to make sure that all the necessary information is received. This information must be accurate, understandable and enforceable. It should be a complete set of requirements that satisfy the user for the developed software product, drawn up in the form of a specification.
In case of non-compliance this requirement it is possible to significantly slow down the implementation of the project in the future due to repeated repeated requests to the user for clarification of incorrectly interpreted details, unspecified conditions and, as a result, it will be necessary to rework the already developed parts of it.
Often during the period of system analysis, a decision is made to stop further software development.
II. Software design. Design is the main and decisive phase of the software life cycle, during which a software product is created and 90% gets its final form.
This phase of life covers different kinds project activity and can be divided into three main stages: design, programming and debugging of a software product.
Construction software development usually starts as early as the feasibility study phase, as soon as some preliminary goals and requirements for it are fixed on paper.
By the time the requirements are approved, work in the design phase will be in full swing.
At this segment of the life of the software, the following is carried out:
Functional decomposition of the problem being solved, on the basis of which the architecture of the system of this problem is determined;
External software design, expressed in the form of its external interaction with the user;
Database design, if necessary;
Software architecture design - definition of objects, modules and their interfacing.
Programming begins already in the construction phase, as soon as the main specifications for the individual components of the software product become available, but not before the approval of the requirements agreement. The overlap between the programming and construction phases results in savings in overall development time, as well as providing validation of design decisions, and in some cases impacts key issues.
At this stage, the work associated with the assembly of the software product is performed. It consists in a detailed internal design of a software product, in the development of the internal logic of each module of the system, which is then expressed in the text of a particular program.
The programming phase ends when the developers have finished documenting, debugging, and linking the individual parts of the software product into a whole.
Software Debugging is carried out after all its components are debugged separately and assembled into a single software product.
III. Evaluation (testing) of software. In this phase, the software product is subjected to rigorous system testing by a group of non-developers.
This is done to ensure that the finished software product meets all requirements and specifications, can be used in the user's environment, is free from any defects, and contains necessary documentation that accurately and completely describes the software product.
The evaluation phase begins once all the components (modules) have been put together and tested, i.e. after complete debugging of the finished software product. It ends after receiving confirmation that the software product has passed all tests and is ready for operation.
It goes on just as long as programming.
IV. Use of the software. If system analysis is a call to action, design is an attack and a return with a victory, then using a software product is a daily defense, vital, but usually not honorable for developers.
Such a comparison is appropriate in view of the fact that during the use of a software product, errors that have crept in during its design are corrected.
The use phase of the software product begins when the product is transferred to the distribution system.
This is the time during which the product is in operation and used effectively.
At this time, staff training, implementation, configuration, maintenance and, possibly, expansion of the software product are carried out - the so-called ongoing design.
The use phase ends when the product is withdrawn from use and the activities mentioned above cease. Note, however, that the software product may be used by someone else for a long time after the use phase as defined here has ended. Because this someone can fruitfully use the software product even without the help of a developer.
The use of the software product is determined by its operation and maintenance.
Operation of the software product consists in its execution, its functioning on a computer for processing information and in obtaining the results that are the purpose of its creation, as well as in ensuring the reliability and reliability of the data issued.
Software maintenance consists in maintenance, development of functionality and improvement of the operational characteristics of the software product, in replication and porting of the software product to various types of computing facilities.
Accompaniment plays a vital role feedback from the operational phase.
During the operation of the software, it is possible to detect errors in programs, and it becomes necessary to modify them and expand their functions.
These improvements, as a rule, are carried out simultaneously with the operation of the current version of the software product. After checking the prepared adjustments on one of the software instances, the next version of the software product replaces the previously used ones or some of them. At the same time, the process of operating the software product can be practically continuous, since the replacement of the software product version is short-term. These circumstances lead to the fact that the process of operating a version of a software product usually runs in parallel and independently of the maintenance phase.
Overlap between software product lifecycle phases
Overlaps between different phases of the software product life cycle are possible and usually desirable. However, there should be no overlap between non-contiguous processes.
Feedback between phases is possible. For example, during one of the external design steps, errors in the formulation of goals may be discovered, then you need to immediately return and correct them.
The considered model of the life cycle of a software product, with some changes, can also serve as a model for small projects.
For example, when a single program is being designed, it is often done without designing the architecture of the system and
database design; the processes of initial and detailed external design often merge together, etc.
Hello, dear Khabrovites! I think it will be interesting for someone to remember what models of development, implementation and use of software existed earlier, what models are mainly used now, why and what it actually is. This will be my little topic.
Actually, what is software life cycle- a series of events that occur with the system in the process of its creation and further use. In other words, this is the time from the initial moment of creating a software product to the end of its development and implementation. The software life cycle can be represented in the form of models.
Software life cycle model- a structure containing the processes of action and tasks that are carried out during the development, use and maintenance of a software product.
These models can be divided into 3 main groups:
- Engineering approach
- Taking into account the specifics of the task
- Modern Rapid Development Technologies
Coding and error handling model
A completely simple model, typical for university students. It is according to this model that most students develop, let's say, laboratory work.This model has the following algorithm:
- Formulation of the problem
- Performance
- Checking the result
- If necessary, go to the first point
Waterfall Software Life Cycle Model (Waterfall)
Algorithm this method, which I present in the diagram, has a number of advantages over the algorithm of the previous model, but also has a number weighty shortcomings.Advantages:
- Sequential execution of project stages in a strict fixed order
- Allows you to evaluate the quality of the product at each stage
- Lack of feedback between stages
- Does not correspond to the real conditions of software product development
Cascade Model with Intermediate Control (Whirlpool)
This model is almost equivalent in algorithm to the previous model, however, it has feedbacks with each stage of the life cycle, while generating a very significant drawback: 10x increase in development costs. It belongs to the first group of models.V model (development through testing)
This model is closer to modern methods The algorithm, however, still has a number of shortcomings. It is one of the main practices of Extreme Programming.
Model Based Prototype Development
This model is based on prototyping and product prototyping.prototyping used in the early stages of the software life cycle:
- Clarify unclear requirements (UI prototype)
- Choose one of a number of conceptual solutions (implementation of scenarios)
- Analyze project feasibility
- Horizontal and vertical
- Disposable and evolutionary
- paper and storyboards
vertical prototypes - verification of architectural solutions.
Disposable prototypes - for rapid development.
evolutionary prototypes are the first approximation of an evolutionary system.
The model belongs to the second group.
Spiral Software Life Cycle Model
The Spiral Model is a software development process that combines both design and incremental prototyping to combine the benefits of bottom-up and bottom-up concepts.
Advantages:
- Fast results
- Increasing competitiveness
- Changing requirements are not a problem
- Lack of stage regulation
Thank you very much for your attention!
Software Life Cycle Standards
- GOST 34.601-90
- ISO/IEC 12207:1995 (Russian analogue - GOST R ISO/IEC 12207-99)
Standard GOST 34 .601-90
Iterative model
An alternative to the sequential model is the so-called iterative and incremental development model. iterative and incremental development, IID ), which also received from T. Gilba in the 70s. Name evolutionary model. This model is also called iterative model And incremental model .
The IID model breaks down the life cycle of a project into a series of iterations, each of which resembles a "mini-project", including all development processes applied to the creation of smaller pieces of functionality, compared to the project as a whole. The purpose of each iterations- obtaining a working version of the software system, including the functionality defined by the integrated content of all previous and current iterations. The result of the final iteration contains all the required functionality of the product. Thus, with the completion of each iteration, the product receives an increment - increment- to its possibilities, which are consequently developed evolutionarily. Iteration, incrementality and evolution in this case is the expression of the same meaning in different words from slightly different points of view.
According to T. Gilba, “evolution is a technique designed to create the appearance of stability. The chances of successfully building a complex system are maximized if it is implemented in a series of small steps, and if each step contains a well-defined success, as well as the possibility of "rolling back" to the previous successful stage in case of failure. Before putting into action all the resources intended to create a system, the developer has the opportunity to receive feedback signals from the real world and correct possible errors in the project.
The IID approach also has its negative sides, which are, in essence, back side merits. First, a holistic understanding of the possibilities and limitations of the project has been missing for a very long time. Secondly, when iterating, you have to discard some of the work done earlier. Thirdly, the conscientiousness of specialists in the performance of work is still declining, which is psychologically understandable, because they are constantly dominated by the feeling that “anyway, everything can be redone and improved later” .
Various variants of the iterative approach are implemented in most modern development methodologies (RUP , MSF , ).
spiral model
Each iteration corresponds to the creation of a fragment or version of the software, at which the goals and characteristics of the project are specified, the quality of the results obtained is assessed, and the work of the next iteration is planned.
At each iteration, the following are evaluated:
- the risk of exceeding the terms and cost of the project;
- the need to perform another iteration;
- the degree of completeness and accuracy of understanding the requirements for the system;
- expediency of terminating the project.
It is important to understand that the spiral model is not an alternative to the evolutionary model (IID model), but a specially developed version. Unfortunately, the spiral model is often mistakenly used either as a synonym for the evolutionary model in general, or (no less erroneously) is mentioned as a completely independent model along with IID.
A distinctive feature of the spiral model is the special attention paid to the risks that affect the organization of the life cycle and milestones. Boehm formulates the 10 most common (prioritized) risks:
- Lack of specialists.
- Unrealistic timeline and budget.
- Implementation of inappropriate functionality.
- Designing the wrong user interface.
- Perfectionism, unnecessary optimization and honing of details.
- An unending stream of change.
- Lack of information about external components that define the environment of the system or are involved in the integration.
- Shortcomings in the work performed by external (in relation to the project) resources.
- Insufficient performance of the resulting system.
- The gap in the qualifications of specialists in different fields.
Today's spiral model defines the following general set of control points:
- Concept of Operations (COO) - the concept (use) of the system;
- Life Cycle Objectives (LCO) - goals and content of the life cycle;
- Life Cycle Architecture (LCA) - life cycle architecture; here it is possible to speak about the readiness of the conceptual architecture of the target software system;
- Initial Operational Capability (IOC) - the first version of the created product, suitable for trial operation;
- Final Operational Capability (FOC) is a finished product deployed (installed and configured) for real operation.
Software Development Methodologies
- Microsoft Solutions Framework (MSF). Includes 4 phases: analysis, design, development, stabilization, involves the use of object-oriented modeling.
- Extreme Programming Extreme Programming, XP). The methodology is based on teamwork, effective communication between the customer and the contractor throughout the entire IS development project. Development is carried out using successively refined prototypes.
- ESPD - complex state standards Russian Federation that establish interrelated rules for the development, execution and circulation of programs and program documentation.
Literature
- Bratishchenko V.V. Design of information systems. - Irkutsk: Publishing House of BGUEP, 2004. - 84 p.
- Vendrov A.M. Designing software for economic information systems. - M .: Finance and statistics, 2000.
- Grekul V.I., Denishchenko G.N., Korovkina N.L. Design of information systems. - M.: Internet University information technologies- INTUIT.ru, 2005.
- Mishenin A.I. Theory of economic information systems. - M .: Finance and statistics, 2000. - 240 p.
Notes
Wikimedia Foundation. 2010 .
See what the "Software Life Cycle" is in other dictionaries:
The period of development and operation of software, in which the following stages are usually distinguished: 1 the emergence and study of an idea; 2 requirements analysis and design; 3 programming; 4 testing and debugging; 5 commissioning the program; 6… … Financial vocabulary
software life cycle - … Technical Translator's Handbook
software life cycle- 3.7 software life cycle; software lifecycle: A sequence of successive processes for the creation and use of software for a programmable building safety-related or ... ...
software life cycle- A sequence of successive processes of creating and using software, occurring over a period of time that begins with the development of a general software concept and ends when ... ... Comprehensive security and anti-terrorist protection of buildings and structures
Software life cycle- Software lifecycle: a period of time that includes the stages: development of software requirements, software development, coding, testing, integration, installation, and ... ... Official terminology
life cycle— 4.16 life cycle development of a system, product, service, project or other human-made entity from the concept stage through to retirement Source … Dictionary-reference book of terms of normative and technical documentation
This is the process of its construction and development. Life cycle information system a period of time that begins from the moment a decision is made on the need to create an information system and ends at the moment of its complete withdrawal from ... ... Wikipedia
The life cycle of an information system is the process of its construction and development. The life cycle of an information system is a period of time that begins from the moment a decision is made on the need to create an information system and ends in ... ... Wikipedia, O. V. Kazarin. The book discusses the theoretical and applied aspects of the problem of protecting software from various kinds of malicious actions. Special attention paid to models and methods of creating ...
Annotation.
Introduction.
1. Software life cycle
Introduction.
Riley Programming Process Steps
Introduction.
1.1.1. Formulation of the problem.
1.1.2. Solution design.
1.1.3. Algorithm coding.
1.1.4. Program support.
1.1.5. Software documentation.
Conclusion to paragraph 1.1
1.2. Definition of ZhTsPO according to Lehman.
Introduction.
1.2.1 System definition.
1.2.2. Implementation.
1.2.3. Service.
Conclusion to item 1.2.
1.3. Phases and Works of the Life Cycle Program according to Boehm
1.3.1. cascade model.
1.3.2. Economic justification cascade model.
1.3.3. Improvement of the cascade model.
1.3.4. Definition of life cycle phases.
1.3.5. Basic work on the project.
Literature.
Introduction
The industrial application of computers and the growing demand for programs have set urgent tasks for a significant increase in software development productivity, the development of industrial methods for planning and designing programs, the transfer of organizational, technical, technical, economic and socio-psychological methods, patterns and methods from the sphere of material production to the sphere of computers. A complex approach to the processes of development, operation and maintenance of software put forward a number of pressing problems, the solution of which will eliminate the "bottlenecks" in the design of programs, reduce the completion time, improve the selection and adaptation of existing programs, and perhaps determine the fate of systems with embedded computers.
In the practice of developing large software projects, there is often no unified approach to the assessment of labor costs, terms of work and material costs, which hinders the increase in productivity of software development, and ultimately - effective management software life cycle. Since a program of any type becomes a product (except, perhaps, educational, mock-up programs), the approach to its production should be similar in many respects to the approach to the production of industrial products, and software design issues become extremely important. This idea underlies B.U. Boehm "Software Engineering Design", which we used to write this term paper. In this book, software design refers to the process of creating a design for a software product.
1 Software life cycle
INTRODUCTION
LCPE is a continuous process that starts from the moment a decision is made on the need to create software and ends at the moment it is completely withdrawn from operation.
There are several approaches to defining the phases and activities of the software life cycle (SLLC), programming process steps, waterfall and spiral models. But they all contain common fundamental components: problem statement, solution design, implementation, maintenance.
The most famous and complete, perhaps, is the structure of the life cycle according to Boehm, which includes eight phases. It will be presented in more detail later.
One of the possible options may be the description of the upper level according to Lehman, which includes three main phases and represents the description of the life cycle program in the most general case.
And, for a change, here are the steps of the programming process presented by D. Riley in the book “Using the Modula-2 Language”. This idea, in my opinion, is very simple and familiar, and we will start with it.
1.1 Riley Programming Process Steps
The programming process includes four steps (Fig. 1):
problem statement, i.e. getting an adequate idea of what task the program should perform;
designing a solution to an already posed problem (in general, such a solution is less formal than the final program);
program coding, i.e. translation of the designed solution into a program that can be executed on a machine;
program support, i.e. an ongoing process of fixing bugs in the program and adding new features.
Rice. 1.Four programming steps.
Programming starts from the moment when user, i.e. someone who needs a program to solve a problem poses a problem system analyst. The user and the system analyst jointly define the problem statement. The latter is then transferred algorithmist who is responsible for designing the solution. A solution (or algorithm) is a sequence of operations, the execution of which leads to the solution of a problem. Since the algorithm is often not adapted to be executed on a machine, it should be translated into a machine program. This operation is performed by the encoder. The accompanying programmer is responsible for subsequent changes to the program. And the system analyst, and the algorithmist, and the coder, and the accompanying programmer - they are all programmers.
In the case of a large software project, the number of users, system analysts, and algorithms can be significant. In addition, it may be necessary to revert to previous steps due to unforeseen circumstances. All this serves as an additional argument in favor of careful software design: the results of each step should be complete, accurate and understandable.
1.1.1 Statement of the problem
One of the most important steps programming is a problem statement. It functions as a contract between the user and the programmer(s). Like a legally poorly drafted contract, a bad mission statement is useless. With a good problem statement, both the user and the programmer clearly and unambiguously represent the task to be performed, i.e. in this case, the interests of both the user and the programmer are taken into account. The user can plan to use the software that has not yet been created, based on the knowledge that it can. A good statement of the problem serves as the basis for the formation of its solution.
Formulation of the problem (program specification); essentially means an accurate, complete, and understandable description of what happens when a particular program is executed. The user usually looks at the computer as a black box: it does not matter to him how the computer works, but it is important that the computer can do what the user is interested in. The focus is on the interaction between man and machine.
Characteristics of a Good Problem Statement:
Accuracy, i.e. exclusion of any ambiguity. There should be no question as to what the output of the program will be for any given input.
completeness, i.e. considering all options for a given input, including erroneous or unexpected input, and determining the appropriate output.
Clarity, i.e. it should be understandable to both the user and the system analyst, since the problem statement is the only contract between them.
Often the requirements for accuracy, completeness and clarity are in conflict. Thus, many legal documents are difficult to understand because they are written in a formal language that allows you to formulate certain provisions with the utmost precision, excluding even the most insignificant discrepancies. For example, some questions in exam papers sometimes phrased so precisely that the student spends more time understanding the question than answering it. Moreover, the student may not grasp the main meaning of the question at all due to the large number of details. The best problem statement is the one that achieves a balance of all three requirements.
The standard form of problem statement.
Consider the following statement of the problem: "Enter three numbers and output the numbers in order."
Such a statement does not satisfy the above requirements: it is neither precise, nor complete, nor understandable. Indeed, should the numbers be entered one per line, or all the numbers on one line? Does the expression "in order" mean ordering from largest to smallest, from smallest to largest, or the same order in which they were introduced.
It is obvious that such a statement does not answer many questions. If we take into account the answers to all questions, then the problem statement will become wordy and difficult to understand. Therefore, D. Riley proposes to use the standard form for setting the problem, which ensures maximum accuracy, completeness, clarity and includes:
task name (schematic definition);
general description ( summary tasks);
errors (unusual input options are explicitly listed to show users and programmers the actions the machine will take in such situations);
example ( good example can convey the essence of the problem, as well as illustrate various cases).
Example. Statement of the problem in the standard form.
NAME
Sort three integers.
DESCRIPTION
Input and output of three integers, sorted from smallest to largest.
Three integers are entered, one number per line. In this case, an integer is one or more consecutive decimal digits, which may be preceded by a plus sign "+" or a minus sign "-".
The three entered integers are output, with all three displayed on the same line. Adjacent numbers are separated by a space. Numbers are displayed from smallest to largest, from left to right.
1) If less than three numbers are entered, the program waits for additional input.
Loading...