In the first part, we chose to compare software development methodologies such indicators as the ratio of methodology to iterative development and the degree of formality in the design of working materials and in general in development. In this part, we use these metrics to compare the most well-known software development practices.
We'll see how it goes…
Alas, this is the most difficult category to describe - after all, it includes both the product of convulsive throwing of a beginner trying to complete his first project at any cost, as well as quite mature and well-established methodologies that have absorbed many years of and varied experience of specific development teams and even described in internal regulations. Since people who are able to develop their own methodology, as a rule, can themselves evaluate it in terms of iteration and formalization, we will focus on beginners. Alas, most often this means that the rules for conducting development either do not exist at all, or they have been developed and adopted, but are not being implemented. Natural in such conditions is an extremely low level of development formalism. So this is all clear.
Development "How it works"
How about an iterative approach? Alas, as a rule, it is not used in such projects. First of all, because it would allow even at the first iterations to evaluate the project as extremely dubious and requiring urgent intervention from higher management to restore order. After all, in an iterative project, the programmer’s traditional answer that everything is 90% ready for him only lasts until the completion of the first iteration…
Structural Methodologies
Structural Methodologies
Structural methods are a group of methodologies developed, as a rule, even before the widespread use of object-oriented languages. All of them involve waterfall development. Although, as it turned out, back in that article, which is often cited as the first presentation of the waterfall approach, it was said that it is desirable to start the project with the development of a prototype, that is, to perform at least two iterations.
Nevertheless, the basis of these methodologies is the sequential transition from work to work and the transfer of the results (documents) of the next stage to the participants of the next one.
Also, all these methodologies assume a highly formalized approach, although statements about a reasonable amount of documentation can be found in them. One of the non-obvious examples of the fact that software development methodologies developed not only in the West is a quote from a book published in our country in the early 1980s, which states that the degree of formalization of a programming task should be determined based on how well the analyst and programmer. And this despite the fact that the theme of the book involved the development of quite critical, as they are now called, systems, errors in which lead to serious losses or even disasters.
Agile Methodologies
Agile methodologies are based on ten principles, of which we will name only those that determine the assessment of these methodologies according to the selected parameters:
- the main thing is to satisfy the customer and provide him with the product as soon as possible;
- new releases of the product should appear every few weeks, in extreme cases - months;
- most effective method transfer of knowledge to the development participants and between them - personal communication;
- a running program is the best indicator of development progress.
Thus, these methods are clearly focused on iterative software development and minimal formalization of the process. However, with regard to the second point, it is necessary to make a reservation: these methods are focused on the minimum allowable for this project formalization level. At least one of the methodologies included in the flexible group - Crystal - has modifications designed to perform processes with a different number of participants and different criticality of the developed software (software criticality is determined by the possible consequences of errors, which can vary from minor financial losses to fixing a bug to a catastrophic one). So that further comparison with flexible methodologies is not pointless, we present short descriptions several of them.
eXtreme Programming, or XP (extreme programming)
The XP methodology, developed by Kent Beck, Ward Cunningham, and Ron Jeffries, is the best known of the agile methodologies today. Sometimes the very concept of "agile methodologies" is explicitly or implicitly identified with XP, which preaches sociability, simplicity, feedback and courage. It is described as a set of practices: the game of planning, short releases, metaphors, simple design, code refactoring (refactoring), test-ahead development, pair programming, collective code ownership, 40-hour workweek, constant customer presence, and code standards. Interest in XP grew from the bottom up - from developers and testers, tormented by painful process, documentation, metrics and other formalism. They did not reject discipline, but they were unwilling to follow the formal requirements senselessly and looked for new fast and flexible approaches to the development of high-quality programs.
When using XP, careful preliminary software design is replaced, on the one hand, by the constant presence of the customer in the team, ready to answer any question and evaluate any prototype, and on the other hand, regular code revisions (so-called refactoring). Thoroughly commented code is considered the basis of design documentation. A lot of attention in the methodology is given to testing. As a rule, for each new method, a test is first written, and then the actual method code is developed until the test starts to run successfully. These tests are stored in suites that are automatically executed after any code change.
While pair programming and the 40-hour work week are perhaps the most well-known features of XP, they are still supportive in nature and contribute to high developer productivity and reduced development errors.
Crystal Clear
Crystal is a family of methodologies that determine the required degree of formalization of the development process, depending on the number of participants and the criticality of tasks.
The Crystal Clear methodology is inferior to XP in terms of performance, but it is as easy to use as possible. It requires minimal effort to implement because it focuses on human habits. It is believed that this methodology describes the natural order of software development, which is established in sufficiently qualified teams, if they are not engaged in the purposeful implementation of another methodology.
Key Features of Crystal Clear:
- iterative incremental development;
- automatic regression testing;
- users are involved in active participation in the project;
- the composition of the documentation is determined by the project participants;
- as a rule, code version control tools are used.
In addition to Crystal Clear, there are several other methodologies in the Crystal family designed for larger or more critical projects. They differ in slightly more stringent requirements for the amount of documentation and supporting procedures, such as change and version control.
Feature Driven Development
Feature Driven Development (FDD) operates in terms of a system feature or feature that is fairly close to the RUP use case concept. Perhaps the most significant difference is an additional restriction: "each function must allow implementation in no more than two weeks." That is, if the use case is small enough, it can be considered a function, and if it is large, then it should be broken down into several relatively independent functions.
FDD includes five processes, with the last two being repeated for each feature:
- development general model;
- compiling a list of necessary system functions;
- planning work on each function;
- function design;
- function construction.
The work on the project involves frequent builds and is divided into iterations, each of which is implemented using a specific set of features.
Developers in FDD are divided into "class masters" and "chief programmers". The main programmers involve the owners of the involved classes to work on the next property. For comparison: in XP there are no personally responsible for classes or methods.
Common features
The list of flexible methodologies is currently quite wide. Nevertheless, the methodologies we have described give a very complete picture of the entire family.
Almost all agile methodologies use an iterative approach, in which only a limited amount of work associated with the release of the next release is planned in detail.
Almost all agile methodologies are focused on the most informal approach to development. If the problem can be solved in the course of a normal conversation, then it is better to do just that. And to draw up decision in paper form or electronic document necessary only when it is impossible to do without it.
Agile Methodologies
GOSTs
GOSTs, like the CMM requirements described in the next section, are not methodologies. They, as a rule, do not describe the software development processes themselves, but only formulate certain requirements for the processes, to which various methodologies correspond to one degree or another. Comparing requirements according to the same criteria by which we compare methodologies will help you immediately decide which methodologies you should use if you need to develop in accordance with GOST.
At present, the old GOSTs of the 19th and 34th series and the newer GOST R ISO IEC 122207 are in force in Russia. The GOSTs of the 19th and 34th series are strictly focused on the cascade approach to software development. Development in accordance with these GOSTs is carried out in stages, each of which involves the performance of strictly defined work, and ends with the release of a fairly large number of very formalized and extensive documents. Thus, immediately strict adherence to these standards not only leads to a waterfall approach, but also provides a very a high degree formalization of development.
GOST requirements
GOST 12207, in contrast to the standards of the 19th and 34th series, describes software development as a set of main and auxiliary processes that can operate from the beginning to the end of the project. Model life cycle can be selected based on the specifics of the project. Thus, this GOST does not explicitly prohibit the use of an iterative approach, but it does not explicitly recommend its use. GOST 12207 is also more flexible in terms of requirements for the formality of the development process. It contains only indications of the need to document the main results of all processes, but does not contain lists of required documents and instructions on their content.
Thus, GOST 12207 allows iterative and less formalized software development.
Development process maturity models (CMM, CMMI)
In addition to national and international standards, there are several approaches to certification of the development process. The most famous of them in Russia are, apparently, CMM and CMMI.
CMM (Capability Maturity Model) is a maturity model of software development processes, which is designed to assess the level of maturity of the development process in a particular company. According to this model, there are five levels of development process maturity. The first level corresponds to “how it goes” development, when developers go to each project as a feat. The second corresponds to more or less well-established processes, when it is possible with sufficient confidence to count on a positive outcome of the project. The third corresponds to the presence of developed and well-described processes used in the development, and the fourth corresponds to the active use of metrics in the management process to set goals and monitor their achievement. Finally, the fifth level refers to the company's ability to optimize the process as needed.
CMM and CMMI requirements
After the advent of CMM, specialized maturity models began to be developed to create information systems, for the process of selecting suppliers and some others. Based on them, an integrated CMMI model (Capability Maturity Model Integration) was developed. In addition, an attempt was made in CMMI to overcome the shortcomings of CMM that had manifested by that time - an exaggeration of the role formal descriptions processes, where the presence of certain documentation was valued significantly higher than just a well-established, but not described process. However, CMMI is also focused on using a highly formalized process.
Thus, the basis of the CMM and CMMI models is the formalization of the development process. They aim developers at the implementation of a process described in detail in the regulations and instructions, which, in turn, cannot but require the development of a large amount of project documentation for appropriate control and reporting.
The relationship of CMM and CMMI to iterative development is more indirect. Formally, neither of them put forward specific requirements for adhering to a waterfall or iterative approach. However, according to some experts, CMM is more compatible with the waterfall approach, while CMMI also allows for an iterative approach.
RUP
Of course, RUP is an iterative methodology. Although formally the mandatory execution of all phases or some minimum number of iterations is not indicated anywhere in RUP, the whole approach is focused on the fact that there are quite a lot of them. The limited number of iterations does not allow you to take full advantage of RUP. At the same time, RUP can also be used in almost cascading projects, which really include only a couple of iterations: one in the Build phase and the other in the Transfer phase. By the way, this is the number of iterations that is actually used in waterfall projects. After all, testing and trial operation of the system involves making corrections, which may involve certain actions related to analysis, design and development, that is, in fact, they are one more pass through all phases of development.
RUP Methodology
With regard to the formality of the methodology, RUP presents the user with a very wide range of possibilities. If you do all the work and tasks, create all the artifacts, and fairly formally (with an official reviewer, with the preparation of a full review in the form of an electronic or paper document, etc.) conduct all reviews, RUP can turn out to be an extremely formal, ponderous methodology. At the same time, RUP allows you to develop only those artifacts and perform only those works and tasks that are necessary in a particular project. And selected artifacts can be executed and reviewed with an arbitrary degree of formality. It is possible to require a detailed study and careful execution of each document, the provision of an equally carefully executed and formalized review, and even, following the old practice, to approve each such review at the scientific and technical council of the enterprise. Can you limit email or sketch on paper. In addition, there is always one more possibility: to form a document in your head, that is, to think about the relevant issue and make a constructive decision. And if this decision concerns only you, then limit yourself, for example, to a comment in the program code.
Thus, RUP is an iterative methodology with a very wide range possible solutions in terms of formalizing the development process.
Let's summarize the second part of the article. RUP, unlike most other methodologies, allows you to choose the degree of formalization and iteration of the development process in a wide range, depending on the characteristics of projects and the developing organization.
And why this is so important - we will discuss in the next part.
1. Cascade (English waterfall) - standard development model
Cascade development model - a model in which all stages of development are carried out sequentially - the next stage begins after the previous one is completed.
This model includes the following steps in the software development process:
First of all, the technical parameters of the future program are determined, as a result, a list of software requirements is approved. Next comes the transition to design, during which documentation is created that describes for programmers a plan and a way to implement the requirements.
After the design is completed, the programmers implement (construct) the project. At the implementation stage, all project components are integrated. Only after the full completion of these stages is testing and debugging of the finished product. Further, the software product can be implemented and, after implementation, provide support - introduce new functionality and eliminate errors.
The main advantages of waterfall development:
2. Agile software development methodology
A range of development methodologies software providing joint work representatives of the customer and developers. The agile development method is based on an iterative approach, the dynamic formation of requirements and their implementation in short stages.
The result of each such stage, including a cycle of iterations, is a miniature software project,
There are several agile development methods, the most famous are Scrum, Extreme Programming, DSDM.
The main advantages of agile development:
| risk minimization; gradual increase in functionality software product; a small amount of written documentation; launch of the basic version of the program as soon as possible. | |||
There are also disadvantages: |
|||
| the inability to accurately determine the project budget; the impossibility of determining the exact timing of project readiness; not suitable for state and budget organizations; requires motivation from responsible representatives of the customer. | |||
Agile Software Development ManifestoWe are constantly discovering better ways to develop software by developing directly and helping others. Thanks to the work done, we were able to realize that: People and interaction more important than processes and tools Working product more important than comprehensive documentation Cooperation with the customer more important than negotiating the terms of the contract Readiness for change is more important following the original plan That is, without denying the importance of what is on the right, we still appreciate what is on the left more. |
Agile development principles:
|
Customer satisfaction due to fast and uninterrupted delivery of the necessary software; |
Annotation: A flexible approach to software development, the basic principles of flexible development are considered. A list of techniques is provided that, to a certain extent, correspond to the principles of flexible software development. The key values and principles of agile development are analyzed.
You can download the presentation for this lecture.
Purpose of the lecture:
Gain an understanding of the purpose and basic principles of agile software development.
Introduction
Agile software development methodology focused on the use of an iterative approach, in which software is created gradually, in small steps, including the implementation of a certain set of requirements. It is assumed that the requirements may change. Teams using agile methodologies are formed from versatile developers who perform various tasks in the process of creating a software product.
When using agile methodologies, risk minimization is carried out by reducing development to a series of short cycles called iterations, lasting 2-3 weeks. An iteration is a set of tasks scheduled to be completed in a specific period of time. In each iteration, a workable version of the software system is created, in which the most priority (for this iteration) customer requirements. Each iteration performs all the tasks necessary to create working software: planning, requirements analysis, design, coding, testing, and documentation. While a single iteration is generally not enough to release new version product, it is understood that the current software ready for release at the end of each iteration. At the end of each iteration, the team re-prioritizes the requirements for the software product, possibly making adjustments to the system development.
Principles and meaning of agile development
For the agile development methodology, key postulates are declared that allow teams to achieve high performance:
- people and their interaction;
- delivery of working software;
- cooperation with the customer;
- response to change.
People and interaction. People are the most important part of success. Individual team members and good communications are essential for high-performing teams. To facilitate communication, agile practices involve frequent discussions of work results and changes to decisions. Discussions can be held daily for a few minutes and at the end of each iteration with an analysis of the results of the work and a retrospective. To communicate effectively in meetings, team members must adhere to the following key rules of conduct:
- respect for the opinion of each team member;
- be truthful in any communication;
- transparency of all data, actions and decisions;
- confidence that each participant will support the team;
- commitment to the team and its goals.
In addition to an effective team and good communications, perfect software tools are needed to create high-performance teams in agile methodologies.
Working software is more important than comprehensive documentation. All agile methodologies highlight the need to deliver small pieces of working software to the customer at predetermined intervals. Software, as a rule, must pass the level of unit testing, testing at the system level. The amount of documentation should be kept to a minimum. During the design process, the team should keep up to date a short document containing the rationale for the decision and a description of the structure.
Cooperation with the customer is more important than formal agreements under the contract. In order for the project to be successfully completed, regular and frequent communication with the customer is necessary. The customer must regularly participate in the discussion of the decisions made on the software, express their wishes and comments. Involving the customer in the software development process is necessary to create a quality product.
Responding quickly to change is more important than following a plan. The ability to respond to change largely determines the success of a software project. In the process of creating a software product, they often change customer requirements. Customers often don't know exactly what they want until they see it working. software. Agile methodologies look for feedback from customers in the process of creating a software product. Responsiveness to change is essential to create a product that delivers customer satisfaction and business value.
The tenets of agile development are supported by 12 principles. Agile specific methodologies define processes and rules that more or less conform to these principles. Flexible methodologies for creating software products are based on the following principles:
- The highest priority is to satisfy the customer's wishes through the delivery of useful software in a short time, followed by continuous updates. Agile methods imply rapid delivery of the initial version and frequent updates. The goal of the team is to deliver a working version within a few weeks of starting the project. Further software systems with gradually expanding functionality should ship every few weeks. The customer can start commercial operation of the system if he considers it functional enough. Also, the customer can simply get acquainted with the current version of the software, provide feedback with comments.
- Don't ignore changing requirements, even late in development. Flexible processes allow changes to be taken into account to ensure the competitive advantage of the customer. Teams using agile methodologies strive to make the program structure of high quality, with minimal impact of changes on the system as a whole.
- Deliver new working versions of the software frequently, at intervals of one week to two months, with a preference for shorter deadlines. At the same time, the goal is to deliver a program that meets the needs of the user, with a minimum of accompanying documentation.
- Customers and developers must work together throughout the project. It is believed that for a successful project, customers, developers, and all stakeholders must communicate often and in many ways to purposefully improve the software product.
- Projects should be implemented by motivated people. Give the project team a healthy working environment, provide the support they need, and trust that the team members will get the job done.
- The most effective and productive method of conveying information to the development team and exchanging opinions within it is a face-to-face conversation. In agile projects, the main mode of communication is simple human interaction. Written documents are created and updated incrementally as the software is developed and only when necessary.
- A working program is the main indicator of project progress. The approach of an agile project to completion is judged by how much available this moment the program meets the requirements of the customer.
- Agile processes encourage long-term development. Customers, developers and users must be able to maintain a constant pace indefinitely.
- A relentless focus on engineering excellence and quality design enhances the returns on agile technologies. Agile team members strive to create quality code by regularly refactoring.
- Simplicity is the art of achieving more by doing less. Team members solve current tasks as simply and efficiently as possible. If there is a problem in the future, then it is possible to make changes to the quality code at no great cost.
- The best architectures, requirements, and designs come from self-organizing teams. In flexible teams, tasks are assigned not to individual members, but to the team as a whole. The team itself decides how best to implement the requirements of the customer. Team members work collaboratively on all aspects of the project. Each participant is allowed to contribute to the common cause. No team member is solely responsible for the architecture, requirements, or tests.
- The team should regularly think about how to become even more effective, and then adjust and fine-tune their behavior accordingly. An agile team constantly adjusts its organization, rules, agreements, and relationships.
The above principles, to a certain extent, correspond to a number of software development methodologies:
| Agile Modeling | a set of concepts, principles and techniques (practices) that allow you to quickly and easily perform modeling and documentation in software development projects; |
| Agile Unified Process(AUP) | a simplified version of the IBM RationalUnifiedProcess(RUP), which describes a simple and understandable approximation (model) for building software for business applications; |
| OpenUP | it is an iterative-incremental method of software development. Positioned as a lightweight and flexible RUP option; |
| AgileDataMethod | a group of iterative software development methods in which requirements and solutions are achieved through the collaboration of different cross-functional teams; |
| DSDM | a methodology for developing dynamic systems based on the concept of rapid application development (RapidApplicationDevelopment, RAD). Represents an iterative and incremental approach that emphasizes continued user/consumer involvement in the process; |
| Extreme programming (XP) | extreme programming; |
| Adaptive software development (ADD) | adaptive software development; |
| Feature driven development (FDD) | development focused on the gradual addition of functionality; |
| Getting Real | an iterative approach without functional specifications used for web applications; |
| MSFfogAgileSoftwareDevelopment | Agile software development methodology from Microsoft; |
| Scrum | establishes rules for managing the development process and allows you to use existing coding practices by adjusting requirements or making tactical changes [ |
1.Coding
At the stage of software development, the following main actions are performed: coding; testing; development of a reference system for software; creating user documentation; creating a version and installing software,
Coding is the process of converting high-level and low-level design results into a finished software product. In other words, when coding, the description of the compiled PP model takes place by means of the selected programming language, which can be any of the existing languages. The choice of language is carried out either at the request of the customer, or taking into account the task being solved and personal experience developers.
When coding, it is necessary to follow the standard for the chosen language, for example, for the C language it is ANSI C, and for C++ it is ISO/IEC 14882 "Standart for the C++ ProgrammingLanguage".
In addition to the generally accepted standard for a programming language, a company can also use its own additional requirements for the rules for writing programs. Basically, they relate to the rules for formatting the text of the program.
Following the company's standard and rules allows you to create a program that works correctly, is easy to read, understandable to other developers, contains information about the developer, date of creation, name and purpose, as well as the necessary data for configuration management.
At the coding stage, the programmer writes programs and tests them himself. Such testing is called unit testing. All issues related to software testing are discussed in Chap. 10, it also describes the testing technology that is used at the stage of software development. This technique is called testing. "glass box" (glassbox); sometimes also called testing "white box" (whitebox) as opposed to the classical concept of a "black box" (blackbox).
In black box testing, the program is treated as an object whose internal structure is unknown. The tester enters data and analyzes the result, but he does not know how the program works. When selecting tests, a specialist looks for input data and conditions that are interesting from his point of view, which can lead to non-standard results. First of all, he is interested in those representatives of each class of input data, in which the errors of the program under test are most likely to appear.
When testing the "glass box" the situation is completely different. The tester (in this case, the programmer himself) develops tests based on knowledge of the source code to which he has full access. As a result, he receives the following benefits.
1. Direction of testing. The programmer can test the program in parts, develop special test subroutines that call the unit under test and pass the data of interest to the programmer. A single module is much easier to test exactly as a "glass box".
2.Full code coverage. The programmer can always determine which code fragments work in each test. It sees what other code branches are left untested, and can choose the conditions under which they will be tested. Here's how to track your reach program code the tests carried out.
3. Ability to control the flow of commands. The programmer always knows which function should be executed next in the program and what its current state should be. To find out if the program works as he thinks, the programmer can include debug commands in it that display information about the progress of its execution, or use a special software tool called the debugger. The debugger can do a lot of useful things: track and change the sequence of execution of program commands, show the contents of its variables and their addresses in memory, etc.
4. Ability to track data integrity. The programmer knows which part of the program must modify each data element. Tracking the state of the data (using the same debugger), he can identify errors such as data changes by the wrong modules, their incorrect interpretation or unsuccessful organization. The programmer can automate testing on his own.
5. Vision of internal boundary points. AT source code those boundary points of the program that are hidden from outside view are visible. For example, several completely different algorithms can be used to perform a certain action, and without looking at the code, it is impossible to determine which one the programmer has chosen. Another typical example would be a buffer overflow problem used to temporarily store input data. The programmer can immediately tell at what amount of data the buffer will overflow, and he does not need to conduct thousands of tests.
6. Possibility of testing, determined by the selected algorithm. For testing data processing that uses very complex computational algorithms may require special techniques. Matrix transformation and data sorting are classic examples. A tester, unlike a programmer, needs to know exactly which algorithms are used, so one has to refer to specialized literature.
Glass box testing is part of the programming process. Programmers do this work all the time, they test each module after it is written, and then again after integrating it into the system.
When performing unit testing, you can use either structural or functional testing techniques, or both.
Structural Testing is one type of glass box testing. Its main idea is the correct choice of the software path under test. In contrast to him functional testing belongs to the category of "black box" testing. Each function of the program is tested by taking its input and analyzing the output. In this case, the internal structure of the program is taken into account very rarely.
Although structural testing has a much more powerful theoretical basis, most testers prefer functional testing. Structural testing lends itself better to mathematical modeling, but this does not mean at all that it is more efficient. Each of the technologies allows you to identify errors that are missed in the case of using the other. From this point of view, they can be called equally effective.
The object of testing can be not only full path program (the sequence of commands that it executes from start to finish), but also its individual sections. It is absolutely unrealistic to test all possible ways of executing a program. Therefore, testers distinguish from all possible ways those groups that need to be tested necessarily. For selection, they use special criteria called coverage criteria (coveragecriteria), which determine a quite real (even if quite large) number of tests. These criteria are sometimes called logical coverage criteria, or completeness criteria.
3. Development of a help system for a software product. Creating User Documentation
It is advisable to appoint one of the project employees as the technical editor of the documentation. This employee can do other work, but his main task should be to analyze the documentation, even if other employees develop it.
It often happens that several people work on the creation of software, but none of them is fully responsible for its quality. As a result, software not only does not benefit from being developed more people, but also loses, because everyone subconsciously shifts responsibility to the other and expects that this or that part of the work will be done by his colleagues. This problem is solved by the appointment of an editor who is fully responsible for the quality and accuracy of technical documentation.
reference system The PP is formed on the basis of the material developed for the user manual. Forms and creates it responsible for the performance of this work. It can be either a technical editor or one of the developers together with a technical editor.
A well-documented PP has the following advantages.
1. Ease of use. If the PP is well documented, then it is much easier to apply. Users learn it faster, make fewer mistakes, and as a result, do their job faster and more efficiently.
2. Less cost technical support. When the user cannot figure out how to perform the actions he needs, he calls the software manufacturer to the technical support service. The maintenance of such a service is very expensive. A good manual, on the other hand, helps users solve problems on their own and reduces the need to contact the technical support group.
3. High reliability. Incomprehensible or sloppy documentation makes software less reliable, as its users are more likely to make mistakes, it is difficult for them to figure out what causes them and how to deal with their consequences.
Ease of escort. A huge amount of money and time is spent on analyzing problems that are generated by user errors. Changes made in new software releases are often just a change in the interface of old functions. They are introduced so that users finally figure out how to use the software and stop calling the technical support service. Good leadership to a large extent
Now in software engineering there are two main approaches to the development of IP software, the fundamental difference between which is due to different ways systems decomposition: functional-modular (structural) approach, which is based on the principle of functional decomposition, in which the structure of the system is described in terms of the hierarchy of its functions and the transfer of information between individual functional elements, and object oriented approach, which uses object decomposition, describes the structure of the IS in terms of objects and relationships between them, and the behavior of the system in terms of messaging between objects.
So, the essence of the structural approach to the development of IS software lies in its decomposition into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, they are divided into tasks, and so on up to specific procedures. At the same time, IS preserves the integrity of the representation, where all components are interconnected. When developing a system "from the bottom up", from individual tasks to the entire system, integrity is lost, problems arise when describing the information interaction of individual components.
The basic principles of the structural approach are:
o principle " divide and rule";
o principle hierarchical ordering - the principle of organizing component systems into hierarchical tree structures with the addition of new details at each level. Selection of two basic principles does not mean that the other principles are secondary, since ignoring any of them can lead to unpredictable consequences.
The main of these principles are:
o abstraction - highlighting the essential aspects of the system;
o consistency - validity and consistency of the elements of the system;
o data structuring - data should be structured and hierarchically organized.
Methodological foundations of software development technologies
Visual modeling. A software model is generally called a formalized description of a software system at a certain level of abstraction. Each model defines a specific aspect of the system, uses a set of diagrams and documents in a given format, and reflects the thoughts and activities of different people with specific interests, roles, or tasks.
Graphical (visual) models are tools for visualizing, describing, designing and documenting the system architecture. The composition of the models used in each specific project, and the degree of their detail in the general case, depend on the following factors:
o the difficulties of the designed system;
o the necessary completeness of its description;
o knowledge and skills of project participants;
o time allotted for design.
Visual modeling has greatly influenced the development of CASE tools in particular. The concept of CASE (Computer Aided Software Engineering) is used in a broad sense. The original meaning of this concept, limited only by the tasks of automating software development, has now acquired new meaning, covering most of the software life cycle processes.
CASE technology is a set of software design methods, as well as a set of tools that allow you to visually model a subject area, analyze this model at all stages of software development and maintenance, and develop an application in accordance with the information needs of users. Most existing CASE tools are based on structural or object-oriented analysis and design methods, using specifications in the form of diagrams or texts to describe external requirements, relationships between system models, system behavior dynamics, and software architectures.
Loading...