Software creation technology

Software creation technology (software engineering
software) is a science that is developing rapidly, especially in recent years. This is primarily determined by the continuously increasing complexity of software (software) and the desire to minimize the development time of software products. Traditional software development technologies no longer provide the quality of a product that satisfies customer requirements, is at the right time, provide high-quality development support. To help developers, computer-aided design software products (CASE technologies) have been created, which, however, do not reduce the specialist’s role and requirements
his qualifications. There is very little knowledge of a certain programming language and experience in using it to create a high-quality commercial software product. You must have special knowledge in the design of software systems.

Today in the world there are a huge number of different processes for creating software. Nevertheless, the technologies that consider the full life cycle of a software development project, combining a scientific approach, a serious base of research and have a history of real use and adaptation, are relatively few. A special place in this list is the technology of the company Rational Software.

In an overloaded information society, it is difficult to find a field of human activity in which computer equipment would not be used. For several decades of evolution, hardware (Hardware) has achieved unprecedented progress - and the computing power that only some scientific institutions could afford to acquire only fifteen years ago, and whose maintenance required a whole staff of specialists, is available to almost every engineer today. However, it is not possible to use these computational powers without software. And it is in this area, despite the significant increase in the availability of hardware resources, there are significant problems.

So, according to American researchers, in the 1980s, only 14% of software development projects were completed successfully (meaning not only meeting customer requirements, but also completion on time with budget (Chaos Report)). Today, after several decades of evolution of programming languages, development tools, almost unlimited availability of computer time (compared to the 70s and 80s), the percentage of successfully completed projects is only 26% (the data were presented at one of G. Buch's seminars.).

In the USSR, in the production of software, the results were significantly better and the following were the objective prerequisites for this:

the planned organization was optimally combined with the cascade model;
project performance monitoring was not focused on meeting customer requirements, but on meeting the agreed vehicle first;
as a rule, highly qualified specialists of specialized institutes were engaged in software development;
because of the implementation of mainly MIC-oriented projects, the budgets were not actually limited (by today's standards).

For a number of reasons, the Soviet school of software development ceased its development, and many achievements were lost. In market conditions (rapidly changing requirements, limited budgets, a focus on results, high competition for highly qualified personnel), the use of old developments of the Soviet school is limited to very narrow areas.

In any production technology is used determines the best achievable performance. Due to the specificity of software production (virtually zero replication cost, a very fast aging process, etc.). The technology for its creation is very strongly tied to human resources and therefore should include organizational and management aspects. Today in the world there are a huge number of different processes for creating software. Nevertheless, the technologies that consider the full life cycle of a software development project, combining a scientific approach, a serious base of research and have a history of real use and adaptation, are relatively few. From the methodologies and technologies that have received some recognition at the moment, the following can be called: Datarun, CMM, Microsoft Solution Framework (MSF), Oracle Method, Rational Unified Process (RUP), SADT (IDEFx).

A special place in this list is the technology of the company Rational Software. In the methodology, which is an integral part of Rational technology, the most modern process-oriented approach has been applied: since software development is production, then, like in any production, when identifying problems in products (symptoms), it is necessary to correct the process (eliminate the causes of ). A feature of the technology is that leading developers in the field of software development, such as G. Butch (OOAP), J. Rumbaugh (OMT), A. Jacobson (Objectory), who made a significant contribution to the theory and practice of modern software. In addition, this technology has been developed and tested with the participation of the US military.

Symptoms and causes of problems

In the process of forming the methodology and its improvement, Rational conducted a study of software development processes in more than a thousand organizations. As a result of the study, the most common symptoms were identified and the causes of problems leading to the disruption of the project were identified (see Table 1).

According to the author, the separation of symptoms from the causes of problems arising during software development is very significant. As practice shows, these symptoms are more often interpreted as features inherent in software development as a whole, and not as a consequence of the inadequacy of the development process, since the effect can only be temporary when symptoms are eliminated. For example, “later identifying deficiencies” is only a symptom of a more significant problem, such as “inadequate testing”. A "inadequate testing" is associated with the use of the "Waterfall" model, in which the solution of this problem is structurally excluded (testing occurs at a very late stage, when error correction is not feasible without a serious change in the timing of implementation).

We list some causes of problems:

Insufficient management of requirements makes it uncontrollable to change the volume of work and jeopardizes the possibility of implementing the project on time.
A fragile architecture that breaks easily under the influence of changes in requirements or technology. One example is the architecture, which is built on one-time components within the technology, does not provide for reuse, which makes the architecture itself inflexible, since a significant change in the program can be viewed as creating a new program with reusing previously created components.
The subjective determination of the status of a project is known, as a rule, "90% is done, and another 90% remains." In other words, the developers believe that 90% of the work has been done, but its completion requires the same amount of resources and time to achieve 100% readiness.

Causes of problems and best practices

As noted earlier, only the elimination of the cause can permanently eliminate the risk associated with it.

And only by eliminating the sources of problems, you can achieve a steady improvement in the efficiency of software development. In the course of the research, best practices for eliminating the sources of problems in software development processes were also collected and summarized (Fig. 1).

Best practices are a set of software development approaches tested on many real-world projects that, when used together, address the causes of problems in software development. An interesting fact is that the “best practices” are not so named because they can easily identify their contribution to the success of the project, but rather because they are used in every organization to achieve steady success in software development.

Practice No. 1. Iterative development process

The essence of iterative practice can be best commented on visually (Fig. 2).

As you can see, as a result, the product goes through several development life cycles (requirements processing, development, coding and testing) using the Waterfall model. The blue line shows the magnitude of the risk of project failure. The breakdown into subsystems has long been used in the development process to reduce the complexity of a separately developed module. However, in this case, the point is not only to break down the tasks in structure into modules, but also the design process itself in time. At the same time, it is necessary to allocate work associated with the most significant risks in the initial iterations, before substantial funds are invested in the development.

Of course, from the point of view of management, such an approach is much more complicated, but it provides a real basis for managing risks and complexity in a project. The phased approach in the Waterfall model is much simpler from the point of view of the formal execution of project management functions, but does not provide sufficient project controllability, and all problems associated with errors or shortcomings of the initial stages are clarified only during the integration process.

Practice # 2. Requirements Management

Requirements management is a systematic approach to retrieving, organizing and documenting system requirements, establishing and maintaining agreements between users / customers with the development team on system requirements changes.

The exact requirements model is important precisely because it brings together all the other elements of the project. Requirements determine what needs to be done, what will be designed, and what will be tested. Changes in requirements, as a rule, affect almost all the elements that are the results of the development process. Requirements are the starting point for planning an iteration, including to determine the effort that needs to be spent to get a result.

Speaking of requirements management in the Rational approach, we cannot but mention the use case (Use Case). The script is the main structuring element of the text description of the designed system, organized in accordance with the objectives pursued by the user when using this system.

The presence of documented requirements in the project makes the subject matter of the communication within the project; helps to overcome difficulties by setting priorities, assigning other attributes of requirements, filtering and tracking dependencies between requirements (traceability); allows you to objectively monitor the status of the project based on the implemented functionality.

Practice # 3. Using Component Architecture

Architecture in software is one of the most complex concepts. The program architecture, together with the requirements, is a bridge between the system use area (end user) and the solution area. It defines the structure, behavior and context of the system. Such important features of the system as usability, functionality, component reuse, implementation complexity of individual modules, flexibility, performance, etc., depend on it.

According to the authors of Software Architecture in Practice: "software architecture is such a component of development results that gives the highest return on investment".

The word "component" is used in the modern world in various contexts. In this case, the practically independent substitution part of the system is meant, which responds to a specific function in the context of a well-defined architecture. The essential feature of this approach is the obligatory use and correspondence of the interface documentation when interacting both inside and outside the system. As a result, components become elements of reuse and internal evolution, which makes them a natural object for managing software configuration.

The most common platforms for building a component architecture are:

Microsoft COM,
Sun Enterprise Java Beans,
CORBA

Practice number 4. Visual modeling

The purpose of visual modeling is to provide the most effective means of communication for displaying the structure and behavior of the architecture and components; reflection of the relationship between the elements of the system; Concealment (or vice versa, disclosure) of implementation details - depending on the tasks and what the developer faces.

The use of a standard modeling language (UML) allows all team members to use the complex and, nevertheless, fairly accurate and short elements of visual modeling in the process of information exchange. The Rational UML methodology is used to specify, visualize, construct, and document all artifacts of the software development process. (Here the artifact - any result of the action document, model, source code).

Together with an iterative approach, visual modeling allows you to effectively track and distribute "inter-iteration" changes in the designed application within the development team. Many teams tried to do this before, but the volume of work on the reflection in the models of inevitable changes in architecture and design (made during the implementation and testing stages) turned out to be too large. Only the use of a tool that implements a direct and inverse transformation model <-> code, reduces the amount of labor during these operations.

The use of use case diagrams (use-cases) allows to visualize the requirements for the system behavior in terms of actors and goals. In the process of modeling, the following disadvantages of the system architecture can be easily identified as the lack of modularity and flexibility.

Practice number 5. Quality control

Quality is a rather complicated term and is found in many areas of human activity. In the terminology of Rational, quality (quality) is defined as "a characteristic that demonstrates the achievements of a manufactured product that meets or exceeds requirements, according to previously established parameters and criteria, and made according to a previously agreed process." According to this definition, quality is not only compliance, it also must include parameters and criteria for their evaluation — to demonstrate the achievement of the required quality, as well as the implementation of the process — to control the fact that the resulting product meets the required degree of quality (and there are repeated and managed).

In many organizations, testing takes from 30 to 50% of development resources. However, the number of errors in the software detected by the customer indicates that the software is not sufficiently tested before delivery.

Many people believe that continuous testing is ideal, recalling the golden era of large computers with batch testing, but until the automatic testing tool that is available to modern tasks is not possible. Continuous testing becomes feasible only with reduced time and labor through automation.

The data obtained by Rational as a result of automating the testing process in a real customer is as follows: 13000 tests were performed with the help of six people in two weeks; after automation, the same tests were performed at 6:00 with the help of one person.

Verification of system functionality in Rational technology is tightly integrated using scripts. Each use case is a reflection of every aspect of the functioning of the system and is the ideal basis for testing.

Thus, automated continuous testing (together with requirements management) provides an objective assessment of the degree of project implementation; allows you to find errors and inaccuracies as they occur; may be focused on high risk areas; defects detected at an early stage are much cheaper to correct. In addition, automated tools that allow you to test not only the functionality, but also reliability and performance, are practically not implemented for manual testing methods.

Practice # 6. Change Management

One of the key and complex concepts in software development is the change management paradigm. Rational highlights the following main issues:

simultaneous change (when two or more processes change one same artifact - the last one that makes changes destroys the changes of the other);
limited message (lack of flexibility to report changes that have occurred);
many versions (when developing quite often there are many versions of the same artifact with different degrees of readiness).

The following main components of change management can be distinguished.

The management of change requests (Change Request Management) corresponds to the infrastructure necessary to control the impact on cost and timing of the necessary corrections for an existing product.

Configuration Management is the activity of defining configurations, building, marking and storing versions of artifacts.

Measurement describes the state of the product, based on the types, number and significance of the identified deficiencies during the development.

Безусловно, столь краткое рассмотрение не может осветить все аспекты применения лучших практики показать все взаимосвязи между ними. Как видно из таблицы 2, для устранения одной причины проблемы задействуется несколько практик. Лучшие практики формируют основу для подисциплинного рассмотрения технологии разработки ПО, представленного в Rational Unified Process (RUP).

Процесс разработки

Любой практик, прочитав первую часть статьи, скажет: "Теория это хорошо, но от теории к практике еще ой как далеко. Необходимо развивать и внедрять процессы, связанные с перечисленными практиками, разрабатывать поддерживающие элементы и т. Д. И это все огромная работа, которую тоже необходимо делать ... ".

Безусловно, технология не состоит только из теоретических исследований.

Для успешного применения методологии необходимо установление адекватного процесса разработки. И именно развернутый шаблон процесса вместе с достаточным для его реализации комплексом инструментария предлагает Rational. Описанные шесть лучших практик легли в основу Rational Unified Process (RUP).

Естественно, что шаблон имеет определенную направленность. В силу упомянутых связей с военными заказами, RUP наиболее близок к системе ценностей советской научной школы, так как он в первую очередь ориентирован на разработку уникальных систем высокой сложности. Но, как показала мировая практика применения, уменьшения сроков разработки, повышение качества получаемых продуктов с увеличением удельного соотношение функциональность / цена, приводят к коммерческой рентабельности внедрения и использования этого процесса.

Описание RUP

Сам процесс поставляется Rational в виде гипертекстовой базы знаний с качественно выполненным классификатором и средством поиска.

На высоком уровне абстракции RUP содержит три аспекта: фазы, дисциплины, и лучшие практики. Первый аспект представляет собой динамичный вид системы и описывает процесс с точки зрения фаз, итераций и вех разработки, второй аспект представляет собой статический вид процесса и описывает процесс с точки зрения ролей, артефактов и дисциплин, третий аспект представляет собой косой срез концепций, которые легли в основу процесса (лучших практик).

При ближайшем рассмотрении каждый аспект, будь то фаза или дисциплина, имеет полное подробное описание с точки зрения концепций, необходимых артефактов и руководств по их создания. Кроме того, в нем содержатся дополнительные элементы, такие как рекомендации по использованию инструментария, глоссарий, список внешних источников (практически все серьезные работы в области инженерии ПО), примеры и рекомендации по конфигурации процесса в организации для различных типов деятельности.

Фазы

Жизненный цикл системы разбивается на циклы, каждый из которых представляет собой новую версию системы, устанавливается заказчику. RUP определяет четыре стадии отдельного цикла (см. Табл. 3).

Кого-то может удивить отсутствие стадии поддержки системы, однако это естественно, потому что, по сути, она совпадает со стадией Transition. В зависимости от типа и сложности продукта стадии могут отличаться по времени и количеству итераций.

Models

Они играют значительную роль в RUP, практически в каждой дисциплине рассматривается несколько основных для нее моделей. Перечислим их:

бизнес-модель - модель бизнес-процессов и бизнес-окружения, она может быть использована для определения требований для поддерживает информационной системы;
модель сценариев - отражает то, что должна делать система и ее окружения;
дизайн-модель - модель объектов, описывает реализацию сценариев использования системы. Она может быть рассмотрена как абстракция модели реализации;
модель реализации - коллекция компонентов и реализуемых подсистем, их содержат;
модель тестов - содержит все тестовые варианты и процедуры, необходимые для тестирования системы.

В подходе Rational для отображения моделей используется Unified Modeling Language (UML). С точки зрения процесса UML является стандартом описания для артефактов разработки и моделирования (семантических моделей, синтаксических нотаций и диаграмм), то есть той информации, которая необходима для обеспечения взаимодействия в процессе разработки и поддержки программного обеспечения. UML не определяет, каким образом использовать его возможности для получения результата, какие модели должны быть построены и в какой последовательности.

Disciplines

Бизнес-моделирования. В ходе бизнес-моделирования выясняется структура и динамика организации заказчика, делаются определенные шаги для определения целей и возможностей совершенствования бизнес-процессов с использованием информационных технологий, устанавливается взаимопонимание по решаемой задачи между разработчиком и заказчиком.

Требования. Основной задачей, решаемой в этой дисциплине, является установление соглашения с пользователями и другими лицами, заинтересованными в проекте, о том, что система должна делать, определяются границы и ограничения, накладываемые на разработку системы и сама система. При решении этой задачи обеспечивается базис для планирования технического содержания итераций расчета затрат (средств и времени), лучшего понимания разработчиками требований к системе. Кроме того, может быть осуществлено определение пользовательского интерфейса системы, с фиксацией внимания на потребностях и целях пользователей.

Анализ и дизайн. В рамках этой дисциплины проводится трансформации требований в дизайн будущей системы, разрабатывается архитектура и адаптируется дизайн к используемой среде разработки.

Реализация. В рамках этой дисциплины проводится определение организации кода в терминах реализуемых подсистем, организованных в слои (layers), реализуются классы и объекты, проводится объединение разработанных компонентов в рабочие элементы.

Testing. В рамках тестирования рассматривается верификация взаимодействия объектов, проверяется корректная работа интегрируемых компонентов, контроль выполнения всех требований к системе, выявление и точная идентификация дефектов, касающиеся разработки ПО.

Поставка (Deployment). В рамках этой дисциплины объединены все действия, связанные с передачей системы пользователям.

Управление конфигурациями и изменениями. Эта дисциплина контролирует изменение и целостность всех артефактов проекта. Для этой цели осуществляется идентификация элементов конфигурации, осуществляется ограничение и аудирование изменений на этих элементов, определяются и управляются конфигурации этих элементов.

Управление проектом. Дисциплина управления проектом в программной инженерии - это искусство балансирования конкурирующих целей, управления рисками и преодоления препятствий для успешного завершения продукта, удовлетворяет требованиям как заказчиков (оплачивают поставки), так и пользователей продукта.

Для решения этой задачи в RUP представлены готовые к использованию шаблоны основных документов (MS Project, MS Word) для управления проектом, а также комплекс пособий для планирования, кадрового обеспечения, исполнения и контроля проекта.

Среда (Environment). Эта дисциплина фиксирует внимание на действиях, необходимых для построения процесса разработки в рамках проекта и организации, с учетом таких параметров среды, как процессы и инструменты. Именно по изучению этой дисциплины необходимо начинать планирование внедрения тех или иных элементов RUP. Кроме того, в последней версии RUP появился отдельный комплекс пособий для построения индивидуальных процессов разработки ПО, основанных на RUP.

People

Несмотря на полноту и инструментальную поддержку RUP, для достижения успеха внедрения этой технологии необходимы люди, которые смогут правильно применить и использовать эти инструменты и знания.

Для достижения этой цели доступны следующие возможности:

бесплатное ознакомление с пробными версиями продуктов;
большое количество книг, посвященных использованию и внедрению процесса;
сообщество разработчиков Rational Developer Network (для зарегистрированных пользователей);
обучение персонала;
институт консультантов (менторов), предоставляющих свои услуги через сеть партнеров.

Говоря о людях, нельзя не вспомнить, что предлагаемая линейка продуктов предназначена и оптимизирована не только для использования на уровне организации и команды разработчиков, но и для отдельно взятого разработчика.

In conclusion, it should be noted that RUP is not a panacea, however, in the personal opinion of the author (and the opinion of leading methodologists who are trying to look further into the fundamentals of software engineering), this is the best start an organization can make towards successful process-oriented reference. software development projects.