Процесс создания программного обеспечения

Размещено на http://www.allbest.ru

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

1.1 Система управления торможением автомобиля

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

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

очень рано начать тестирование пользователями;

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

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

1.2 Система поддержки процесса сопровождения программного обеспечения

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

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка -- внесение новой функциональности и устранение ошибок.

Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз -- не происходит.

1.3 Интерактивная система просмотра железнодорожных расписаний для пассажиров

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

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

Однако, несмотря не все преимущества, данная модель также не стала панацеей. Основные ее проблемы лежали в плоскости взаимоотношений «заказчик-исполнитель»: первый был заинтересован в создании как можно более подробных прототипов для того, чтобы снизить риск получения неадекватной системы, в то же время для второго каждый новый прототип означал дополнительные затраты времени и ресурсов, а в итоге - снижение рентабельности проекта.

Выводы

Не существует единственной правильной модели процесса разработки ПО. Эффективный производственный процесс должен основываться на итеративности, инкрементальности, самоуправляемости команды и адаптивности. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.

Чтобы программный проект стал успешным, необходимо:

Четко ставить цели.

Определять способ достижения целей.

Контролировать и управлять реализацией.

Анализировать угрозы и противодействовать им.

Создавать команду.



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

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

- Многие этапы процесса создания ПО не документированы. Менеджерам проекта создания ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то экономически не выгодно документировать каждую версию системы.

- Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным.

- Часто требуются специальные средства и технологии разработки ПО. Это вызвано необходимостью быстрой разработки версий программного продукта. Но, с другой стороны, это может привести к несовместимости некоторых применяемых средств и технологий, что, в свою очередь, требует наличия в команде разработчиков специалистов высокого уровня.

Выводы

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

3. Объясните, как каскадную модель и эволюционную модель с прототипированием можно объединить со спиральной моделью разработки ПО

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

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

При таком смешанном подходе для прояснения "темных мест" в системной спецификации можно использовать прототипирование. Часть системных компонентов, для которых полностью определены требования, может создаваться на основе каскадной модели. Другие системные компоненты, которые трудно поддаются специфицированию, например пользовательский интерфейс, могут разрабатываться с использованием прототипирования.

Вывод

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



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

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

Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация-- детализированное математическое формальное описание системных функций. Дэвис (Davis) так объясняет причины этих различий.

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых системой функций. Два перечисленных вида требований можно определить следующим образом.

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

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

Выводы

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



5. Опишите основные этапы процесса проектирования ПО, укажите выходной результат каждого этапа

Процесс проектирования может включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование - это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирования, а следовательно, позволяют внести изменения в ранее созданные модели. На рис. 3.9 показана схема процесса проектирования ПО с указанием результата каждого этапа проектирования. Эта схема построена в предположении, что все этапы процесса проектирования выполняются последовательно. На практике эти этапы перекрываются вследствие неизбежных обратных связей от одного этапа к предыдущему и повторного выполнения некоторых проектных работ.

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

Ниже перечислены отдельные этапы процесса проектирования.

Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними.

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

Проектирование интерфейсов. Для каждой подсистемы определяется и документируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однозначными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функции. На этом этапе можно применить методы формальных спецификаций, рассмотренные в главе 9.

Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам.

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

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

Результаты проектирования

Рис. 1. Обобщенная схема процесса проектирования

Выводы

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



6. Назовите пять основных компонентов любых методов проектирования. Какие методы проектирования вы знаете? Опишите их компоненты. Оцените полноту этих методов

Каждый структурный метод включает такие компоненты, как модель процесса проектирования, стандартизованные нотации для представления структуры системы, форматы отчетов, правила и нормативные указания по проектированию. Хотя разработано большое количество таких методов, они имеют нечто общее. Структурные методы поддерживают все или по крайней мере некоторые из перечисленных ниже моделей систем.

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

Модель "сущность-связь", которая применяется для описания сущностей (объектов программной системы) и связей между ними. Эта модель часто используется при проектировании структур баз данных.

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

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

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



Выводы

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



7. Разработайте модель процесса тестирования исполняемой программы

программное обеспечение модель тестирование

Процесс тестирования представляет собой интерпретационный подход, направленный на поиск и выявление ошибок в ПО. Процесс тестирования состоит из нескольких этапов:

Тестирование компонентов. Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других.

Тестирование модулей. Программный модуль - это совокупность зависимых компонентов, таких как описание класса объектов, декларирование абстрактных типов данных и набор процедур и функций. Каждый модуль тестируется независимо от других системных модулей.

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

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

Приемочные испытания. Это конечный этап процесса тестирования, после которого система принимается к эксплуатации. Здесь система тестируется с привлечением данных, предоставляемых заказчиком системы, а не на основе тестовых данных, как было на предыдущем этапе. На этом этапе могут проявиться ошибки, допущенные еще на этапе определения системных требований, поскольку испытания с реальными данными могут дать иной результат, чем тестирование со специально подобранными тестовыми данными.

Пример тестирования:

Выводы

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



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

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

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

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

мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

средства разработки приложений, включая языки 4GL и генераторы кодов;

средства конфигурационного управления;

средства документирования;

средства тестирования;

средства управления проектом;

средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла (ЖЦ). Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

применяемым методологиям и моделям систем и БД;

степени интегрированности с СУБД;

доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).Вспомогательные типы включают:

средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

средства конфигурационного управления (PVCS (Intersolv));

средства тестирования (Quality Works (Segue Software));

средства документирования (SoDA (Rational Software)).

На сегодняшний день рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

Vantage Team Builder (Westmount I-CASE);

Designer/2000;

Silverrun;

ERwin+BPwin;

S-Designor;

CASE.Аналитик.

Кроме того, постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

Выводы

Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.



Заключение

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

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

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

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

Разработка спецификации ПО. Это фундамент любой программной системы. Спецификация определяет все функции и действия, которые будет выполнять разрабатываемая система.

Проектирование и реализация (производство) ПО. Это процесс непосредственного создания ПО на основе спецификации.

Аттестация ПО. Разработанное программное обеспечение должно быть аттестовано на соответствие требованиям заказчика.

Эволюция ПО. Любые программные системы должны модифицироваться в соответствии с изменениями требований заказчика.

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

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

Размещено на www.allbest.