Стандарты ЕСПД и их роль в разработке и адаптации жизненного цикла
Жизненный цикл программного продукта - методологическая основа программой инженерии. Процессы и требования к разрабатываемой системе. Задачи разработки архитектуры программного обеспечения. Роль стандартов ЕСПД в разработке и адаптации жизненного цикла.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | лекция |
| Язык | русский |
| Дата добавления | 24.08.2013 |
| Размер файла | 48,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Стандарты ЕСПД и их роль в разработке и адаптации жизненного цикла
Жизненный цикл определяет всего лишь структуру декомпозиции работ. Их детализация, техники выполнения и метрики измерения - вопрос программной инженерии.
Методологическую основу программой инженерии составляет понятие жизненного цикла программного продукта. Впервые о жизненном цикле заговорили в 1968 году в Лондоне, где состоялась встреча 22-х руководителей проектов по разработке программного обеспечения. На встрече анализировались проблемы и перспективы проектирования, разработки, распространения и поддержки программ. Было констатировано, что применяющиеся методы разработки ПО требуют постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC - Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации программного средства.
стандарт программный жизненный цикл
1. Жизненный цикл программного обеспечения
Жизненный цикл ПО - это период времени, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации (IEEE Std. 610.12 - 19990 Standard Glossary of Software Engineering Terminology).
Понятие жизненного цикла занимает центральное место в технологии программирования. Потребность в этом понятии возникла в связи с превращением процесса разработки программ в инженерную дисциплину.
Это понятие не является специфическим для программирования. Оно возникло и развивалось сначала применительно к техническим системам. В частности, еще несколько десятилетий назад наши экономисты выражали свое беспокойство по поводу того, что зарубежный потребитель сравнительно дешевым советским тракторам предпочитает канадские, цена которых в несколько раз выше. Оказалось, что полная стоимость последних с учетом затрат всего периода существования машин (включая их техническое обслуживание и ремонт) получается в конечном счете в несколько раз меньше. Не случайно вопрос технологичности не только с точки зрения изготовления, но и последующей эксплуатации, имеет в технике первостепенное значение.
В качестве основных видов деятельности, выполняемых при создании ПО, принято рассматривать проектирование -- выделение отдельных модулей и определение связей между ними с целью минимизации зависимостей между частями проекта и достижения лучшей его обозримости в целом, кодирование -- разработку кода отдельных модулей и тестирование, т.е. проверку работоспособности программной системы.
Однако для корректного с точки зрения инженерии и экономики рассмотрения вопросов создания сложных систем необходимо, чтобы были затронуты и вопросы эксплуатации системы, внесения в нее изменений, а также самые первые действия в ходе ее создания -- анализ потребностей пользователей и идентификация функций, реализующих эти потребности. Без этого невозможно, с одной стороны, учесть реальную эффективность системы в виде отношения полученных результатов ко всем сделанным затратам и, с другой стороны, правильно оценивать в ходе разработки степень соответствия создаваемого ПО реальным нуждам пользователей и заказчиков.
Таким образом, первоначальное отношение к понятию жизненного цикла как к циклу разработки постепенно трансформировалось и стало рассматриваться как проекция пользовательского понятия «время жизни ПО» на понятие разработчика «технологический цикл (или цикл разработки)».
В ходе жизненного цикла программное обеспечение проходит через анализ предметной области, сбор требований, проектирование, кодирование, тестирование, сопровождение и другие виды деятельности. Каждый вид представляет собой достаточно однородный набор действий, выполняемых для решения одной задачи или группы тесно связанных задач в рамках разработки, эксплуатации и сопровождения ПО.
При этом создаются и перерабатываются различного рода артефакты -- создаваемые человеком информационные сущности - документы, в достаточно общем смысле участвующие в качестве входных данных и получающиеся в качестве результатов различных деятельностей.
На различных этапах в создание и эксплуатацию программного обеспечения вовлекаются люди, выполняющие различные роли. Каждая роль может быть охарактеризована как абстрактная группа заинтересованных лиц, участвующих в деятельности по созданию и эксплуатации системы, решающих одни и те же задачи или имеющих одни и те же интересы по отношению к ней. Примерами ролей являются: бизнес-аналитик, архитектор, проектировщик пользовательского интерфейса, программист-кодировщик, технический писатель, тестировщик, руководитель проекта по разработке, работник отдела продаж, конечный пользователь, инженер по поддержке и т.п.
Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «International Technology - Software Life Cycle Processes» (ГОСТ ИСО МЭК 12207-99 Информационные технологии. Жизненный цикл программного обеспечения). В данном стандарте программный продукт определяется как набор компьютерных программ, процедур и, возможно связанных с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.
Стандарт ISO/IEC 12207 определяет общую структуру жизненного цикла ПО в виде 3 ступенчатой модели, состоящей из процессов, видов деятельности и задач. Каждый процесс разделен на набор действий, каждое действие - на набор задач, каждая задача характеризуется определенным методом решения, исходными данными, в том числе, полученными от других процессов, и результатами. Любой процесс увязан с определенными артефактами и ролями заинтересованных лиц. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения. Всего в стандарте ISO/IEC 12207 определено 18 процессов, 74 вида деятельности и 224 различные задачи.
В соответствии со стандартом все процессы жизненного цикла ПО разделены на группы (см. рис 4.1.):
Рис. 4.1. Жизненный цикл ПО.
Хотя стандарт описывает вводимые элементы в терминах их целей и результатов, тем самым задавая неявно возможные взаимосвязи между ними, он не определяет четко структуру этих связей, возможную организацию элементов в рамках проекта и метрики, по которым можно было бы отслеживать ход работ и их результативность. Таким образом, жизненный цикл - это всего лишь «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы.
2. Основные процессы ЖЦ ПО
Процесс приобретения ПО определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. В ходе данного процесса заказчик должен осознать свои потребности в программной системе, проанализировать требования к ней, принять решение относительно приобретения, разработки или усовершенствования существующего ПО. На основе проведенного анализа он должен подготовить заявочные предложения, которые лягут в основу контракта с поставщиком. Эти предложения должны содержать требования к системе, условия ее функционирования и технические ограничения, а также другие условия контракта. Процесс приобретения завершается в тот момент, когда оказались выполненными все условия приемки, в том числе, сработали все необходимые тесты.
В процессе поставки организация-поставщик рассматривает заявочные предложения заказчика и, при необходимости, вносит в них свои коррективы, подготавливает договор с ним, осуществляет планирование выполнения работ (при этом работы могут выполняться своими силами или с привлечением субподрядчика), разрабатывает организационную структуру проекта, технические требования к среде разработки и ресурсам, мероприятия по управлению проектом и др.
Процесс разработки определяет действия и задачи, выполняемые разработчиком в процессе создания программного обеспечения и его компонентов в соответствии с заданными требованиями. Данный процесс включает, в том числе, оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности программного продукта и его соответствия стандартам качества. Также должны быть разработаны материалы (методические и учебные), необходимые для подготовки и обучения персонала и т.д.
Разработке ПО предшествует подготовительная работа, которая начинается с выбора модели жизненного цикла ПО, соответствующей масштабу, значимости и сложности проекта. Именно модель ЖЦ будет определять все последующие действия и задачи разработчика. Кроме того, на данном этапе разработчик должен выбрать, адаптировать к условиям проекта и согласовать с заказчиком используемые стандарты, методы и средства разработки, а также составить план выполнения работ.
Первой фазой разработки ПО является анализ требований к системе. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Для ответа на этот вопрос, во-первых, необходимо понять, какие именно потребности пользователей призвана обеспечить будущая система, а во-вторых, задокументировать это понимание, т.к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
Список требований к разрабатываемой системе должен включать:
· совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение);
· описание выполняемых системой функций;
· ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации и пр.).
Анализ требований к разрабатываемой системе является важнейшим среди всех этапов ЖЦ. Именно здесь лежит ключ к успеху всего проекта. В практике создания больших программных систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Требования к системе оцениваются, исходя из критериев реализуемости и возможности проверки при тестировании.
Помимо требований к системе перед началом разработки должны быть сформулированы требования к программному обеспечению. Для решения этой задачи служит анализ требований к программному обеспечению, в процессе которого для каждого компонента ПО определяются следующие характеристики:
· функциональные возможности, включая характеристики производительности и среды функционирования компонента;
· внешние интерфейсы;
· спецификации надежности и безопасности;
· эргономические требования;
· требования к используемым данным;
· требования к установке и приемке;
· требования к пользовательской документации;
· требования к эксплуатации и сопровождению.
Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.
Важнейшую роль в процессах жизненного цикла создания программного обеспечения играет проектирование. Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:
· Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) - описание высокоуровневой структуры и организации компонентов системы;
· Детализированная архитектура (software detailed design) - описывающая каждый компонент в том объеме, который необходим для конструирования.
В строгом значении архитектура программного обеспечения (software architecture) представляет собой описание подсистем и компонентов программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется.
Любая система может рассматриваться с разных точек зрения - например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурное представление может быть определено, как частный аспект программной архитектуры, отражающий специфические свойства программной системы. В свою очередь, дизайн системы можно рассматривать как комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе.
Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО:
· трансформацию требований к ПО в архитектуру, определяющую на высоком уровне абстракции структуру программного обеспечения и состав его компонентов;
· разработку и документирование программных интерфейсов ПО;
· разработку предварительной версии пользовательской документации;
· разработку и документирование предварительных требований к тестам и плана интеграции ПО.
Архитектура компонентов должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.
Детальное проектирование ПО (рабочий план разработки ПО) включает следующие задачи:
· описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования;
· разработку и документирование детального проекта ПС;
· обновление (при необходимости) пользовательской документации;
· разработку и документирование требований к тестам и плана тестирования компонентов ПО;
· обновление плана интеграции ПО.
Кодирование и тестирование ПО подразумевает решение следующих задач:
· разработку (кодирование) и документирование каждого компонента ПО, а также создание совокупности тестовых процедур и данных для тестирования;
· тестирование каждого компонента ПО на соответствие предъявляемым требованиям. При этом результаты тестирования компонентов должны быть задокументированы;
· обновление (при необходимости) пользовательской документации;
· обновление плана интеграции ПО.
Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование, и тестировании агрегированных модулей. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование - это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации. В процессе интеграции также производится оформление и проверка полного комплекта документации на систему.
Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации. Квалификационное тестирование выполняется для каждого компонента программного обеспечения по всем разделам требований при широком варьировании тестов. При этом также проверяются полнота технической и пользовательской документации и ее адекватность самим компонентам ПО.
Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПО и баз данных. Если устанавливаемое ПО заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором.
Приемка ПО предусматривает оценку результатов квалификационного тестирования системы и документирование результатов оценки, которое производится заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПО заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.
Примечание: Главная особенность индустрии разработки программного обеспечения состоит в том, что основные трудозатраты и сложности концентрируются на начальных этапах жизненного цикла (анализ и проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают трудные, часто неразрешимые проблемы и, в конечном счете, могут привести к провалу всего проекта.
Процесс эксплуатации охватывает действия и задачи организации, эксплуатирующей программную систему. На этом этапе устанавливаются эксплуатационные стандарты, и проводится эксплуатационное тестирование, после чего система передается пользователям. Эксплуатация системы выполняется в предназначенной для этого среде в соответствии с пользовательской документацией. Поддержка пользователей заключается в оказании им помощи при обнаружении ошибок в процессе эксплуатации.
Процесс сопровождения активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации или адаптации программной системы. Согласно стандарту IEEE - 90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям. При этом изменения, вносимые в существующее ПО, не должны нарушать его целостность. Для осуществления действий по сопровождению программного продукта организация - разработчик создает специальную службу сопровождения, в задачи которой входит:
· анализ проблем и запросов на модификацию ПО;
· модификация программного продукта;
· его проверка и приемка;
· перенос ПО в другую среду;
· снятие ПО с эксплуатации.
Анализ проблем и запросов на модификацию ПО необходим для определения основных характеристик возможной модификации. К ним относятся: тип модификации (корректирующая, улучшающая, профилактическая или адаптирующая к новой среде), масштаб (т.е. размер модификации, ее стоимость и время реализации), критичность (воздействие на производительность, надежность или безопасность).
На основе проведенного анализа делается оценка целесообразности проведения модификации, и предлагаются возможные варианты ее проведения. В итоге утверждается один из них. При анализе учитывается влияние планируемой модификации на существующую систему и интерфейсы с другими системами.
Модификация ПО предусматривает определение компонентов ПО, их версий и документации, подлежащих модификации, и внесение в них необходимых изменений в соответствии с правилами процесса разработки. Сделанные изменения тестируются и проверяются по критериям, определенным в документации. При подтверждении корректности изменений в программах производится корректировка документации.
Проверка и приемка заключаются в проверке целостности модифицированной системы и утверждении внесенных изменений.
При переносе ПО в другую среду выполняется конвертирование программ и данных в новую среду. С целью облегчения перехода к новой системе предусматривается параллельная эксплуатация программного обеспечения в старой и новой среде в течение некоторого периода, когда происходит обучение пользователей и привыкание к работе в новой среде.
Снятие ПО с эксплуатации осуществляется по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документация подлежат архивированию в соответствии с договором. Чаще всего это происходит при переходе на новую систему.
3. Вспомогательные процессы жизненного цикла ПО
Процесс документирования предусматривает формализованное описание информации, созданной в течение всего жизненного цикла. Этот процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как менеджеры, технические специалисты и пользователи системы.
Согласно стандарту IEEE - 90 под конфигурацией программного обеспечения понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в программах. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях жизненного цикла. В процессе управления конфигурацией применяются административные и технические процедуры для определения состояния компонентов ПО в системе, их описания и подготовки соответствующих отчетов.
Общие принципы и рекомендации по управлению конфигурацией отражены в стандарте ISO/IEC CD 12207 - 2:1995 “Information Technology - Software Life Cycle Processes. Part 2. Configuration Management for Software”. Этот стандарт предлагает установить правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПО и их версии. При этом каждому компоненту и его версиям должен соответствовать однозначно обозначаемый комплект документации. При проведении модификаций ПО должен осуществляться контроль конфигурации, в процессе которого отслеживаются затраты на модификацию, оценивается ее эффективность, а также соответствие измененных компонентов их документации. Кроме того, согласно стандарту должны подготавливаться отчеты обо всех реализованных и отвергнутых модификациях компонентов ПО. Совокупность этих отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций. Стандарт также рекомендует проводить оценку конфигурации, в процессе которой оценивается функциональная полнота компонентов ПО, а также соответствие их физического состояния текущему техническому описанию. Итоговое действие по управление конфигурацией - это управление выпуском и поставка, в процессе которых изготавливаются эталонные копии программ и документации для хранения и поставки пользователям в соответствии с порядком, принятом в организации.
Процесс обеспечения качества обеспечивает гарантии того, что программный продукт и процессы его жизненного цикла соответствуют заданным требованиям, а также выработанным и утвержденным планам работ. При этом под качеством мы понимаем совокупность свойств, характеризующих способность программного обеспечения удовлетворять заданным требованиям и нуждам всех заинтересованных сторон.
Процесс призван обеспечить гарантированное соответствие процессов жизненного цикла, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам. Для этого должны быть обеспечены качество продукта, качество процесса и прочие показатели качества системы.
Для получения достоверных оценок качества создаваемого программного обеспечения процесс обеспечения его качества должен происходить независимо от разработчиков. Для этого могут использоваться результаты других вспомогательных процессов: верификации, аттестации, совместной оценки, аудита и разрешения проблем.
Верификация в узком смысле означает формальное доказательство правильности ПО. В процессе верификации проверяются следующие условия:
· непротиворечивость требований к системе и степень учета потребностей пользователя;
· возможности поставщика выполнить заданные требования;
· соответствие выбранных процессов ЖЦ ПО условиям договора;
· адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;
· соответствие проектных спецификаций заданным требованиям;
· корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, логики и т.д.
· соответствие кода проектным спецификациям и требованиям;
· тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
· корректность интеграции компонентов ПО в систему;
· адекватность, полнота и непротиворечивость документации.
Верификация может проводиться самим исполнителем или другим специалистом данной организации, либо независимым экспертом (в этом случае говорят о независимой верификации). Верификация должна как можно раньше интегрироваться с использующими ее процессами: поставкой, разработкой, эксплуатацией и сопровождением.
Процесс аттестации (или процесс проверки соответствия) предусматривает определение полноты соответствия заданных требований и созданной системы или программного продукта их конкретному функциональному назначению. Под аттестацией обычно понимается подтверждение и оценка достоверности проведенного тестирования ПО. Аттестация должна гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестация может проводиться с различными степенями независимости. Ее можно проводить на начальных стадиях жизненного цикла ПО или как часть работы по его приемке.
Примечание: Результаты процессов верификации и аттестации должны быть открыты для пользователей и других заинтересованных сторон.
Процесс совместной оценки сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, инструментальными и аппаратными средствами программного проекта. Он предназначен для оценки состояния работ по проекту и применяется как на уровне управления проектом, так и на уровне его технической реализации. Его цель - поддержание общего понимания продвижения к целям, поставленным в договоре. Данный процесс может выполняться любыми сторонами, участвующими в договоре на разработку и поставку программного продукта, при этом одна сторона проверяет другую. Результаты проверок должны быть доведены до всех заинтересованных сторон, а мероприятия, вытекающие из проверок, отслежены вплоть до завершения.
Аудит - это ревизия, проводимая компетентным органом (лицом) в целях обеспечения независимой оценки степени соответствия ПО или процессов установленным требованиям. Аудит проводится при достижении предварительно определенных вех и служит для определения соответствия реальных работ и отчетов установленным требованиям, планам и контрактам. Аудиторы должны быть независимы от разработчиков ПО. Они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования.
Процесс разрешения проблем предусматривает анализ и разрешение проблем, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов независимо от их происхождения (включая обнаруженные несоответствия). Каждая обнаруженная проблема должна быть идентифицирована, описана в отчете, проанализирована и устранена.
4. Организационные процессы жизненного цикла ПО
Процесс управления состоит из действий и задач, выполняемых любой стороной, управляющей своими процессами. Он включает такие действия как определение области управления, планирование, выполнение и контроль.
Главное, чтобы при определении области управления менеджер был уверен в том, что располагает достаточным количеством ресурсов (персоналом, оборудованием и пр.), необходимых для решения поставленной управленческой задачи.
Создание инфраструктуры. Цель данного процесса - создание и подержание стабильной инфраструктуры, необходимой для успешного функционирования всех остальных процессов. Инфраструктура программного проекта включает в себя технологии и стандарты, а также совокупность аппаратных, программных и инструментальных средств для разработки, эксплуатации или сопровождения ПО. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией.
Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла ПО. Он основан на анализе достоинств и недостатков каждого процесса. Такому анализу способствует накопление организационной, технической, экономической и другой информации по реализованным проектам. Целью процесса усовершенствования является повышение производительности труда всех участвующих специалистов за счет развития используемой технологии и методов управления, выбора соответствующих им инструментальных средств и обучения персонала.
Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Содержание процесса обучения определяется требованиями к проекту. При этом должны учитываться необходимые ресурсы и технические средства обучения, а также иметься в наличии методические материалы для обучения пользователей.
Важно понимать, что стандарт ISO/IEC 12207 не определяет последовательность выполнения процессов и их разбиение во времени, адресуя этот вопрос работам по адаптации стандарта к условиям и окружению конкретного программного проекта.
Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного цикла, а также применение соответствующих методологий, детализирующих процедуры выполнения процессов, работ и задач в рамках заданных границ (содержания) жизненного цикла программного обеспечения, организационной структуры и ролевой ответственности в конкретной организации (ее подразделении) и/или в проектной группе.
5. Стандарты ЕСПД и их роль в разработке и адаптации жизненного цикла
Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе - то есть при ссылке на них в договоре на разработку (поставку) ПС.
Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела. К числу основных недостатков ЕСПД можно отнести:
· ориентацию на единственную, «каскадную» модель жизненного цикла ПО;
· отсутствие четких рекомендаций по документированию характеристик качества программного средства;
· отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;
· нечетко выраженный подход к документированию ПС как товарной продукции;
· отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю («хелпов»);
· отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.
Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПС. Эта позиция основана на следующем:
· стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПС;
· предусмотренный стандартами ЕСПД состав программных документов вовсе не такой «жесткий», как некоторым кажется: стандарты позволяют вносить в комплект документации на ПС дополнительные виды документов;
· стандарты ЕСПД позволяют вдобавок мобильно изменять структуры и содержание установленных видов программных документов исходя из требований заказчика и пользователя.
При этом стиль применения стандартов может соответствовать современному общему стилю адаптации стандартов к специфике проекта: заказчик и руководитель проекта выбирают уместное в проекте подмножество стандартов и ПД, дополняют выбранные ПД нужными разделами и исключают ненужные, привязывают создание этих документов к той схеме ЖЦ, которая используется в проекте.
Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведенные в таблице 4.1.
Табл. 4.1. Группы стандартов ЕСПД.
|
Kод группы |
Наименование группы |
|
|
0 |
Общие положения |
|
|
1 |
Основополагающие стандарты |
|
|
2 |
Правила выполнения документации разработки |
|
|
3 |
Правила выполнения документации изготовления |
|
|
4 |
Правила выполнения документации сопровождения |
|
|
5 |
Правила выполнения эксплуатационной документации |
|
|
6 |
Правила обращения программной документации |
|
|
7 |
Резервные группы |
|
|
8 |
||
|
9 |
Прочие стандарты |
Обозначение стандарта ЕСПД строят по классификационному признаку. Обозначение стандарта ЕСПД должно состоять из:
· числа 19 (присвоенных классу стандартов ЕСПД);
· одной цифры (после точки), обозначающей код классификационной группы стандартов, указанной таблице;
· двузначного числа (после тире), указывающего год регистрации стандарта.
Перечень документов ЕСПД
1. ГОСТ 19.001-77 ЕСПД. Общие положения.
2. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.
3. ГОСТ 19.102-77 ЕСПД. Стадии разработки.
4. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
5. ГОСТ 19.104-78 ЕСПД. Основные надписи.
6. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
7. ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
8. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
9. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
10. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.
11. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
12. ГОСТ 19.402-78 ЕСПД. Описание программы.
13. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
14. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
15. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
16. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
17. ГОСТ 19.504-79 ЕСПД. Руководство программиста.
18. ГОСТ 19.505-79 ЕСПД. Руководство оператора.
19. ГОСТ 19.506-79 ЕСПД. Описание языка.
20. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
21. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
22. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
23. ГОСТ 19.781-90. Обеспечение систем обработки информации.
Из всех стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике.
ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требование к содержанию и оформлению. (Переиздан в ноябре 1987г с изм.1).
Техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта ПС.
Техническое задание должно содержать следующие разделы:
· введение;
· основания для разработки;
· назначение разработки;
· требования к программе или программному изделию;
· требования к программной документации;
· технико-экономические показатели;
· стадии и этапы разработки;
· порядок контроля и приемки;
· в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (Переиздан в ноябре 1987г с изм.1).
Устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Виды программ приведены в таблице 4.2, виды программных документов - в таблице 4.3, а виды эксплуатационных документов в таблице 4.4.
Табл. 4.2. Виды программ
|
Вид программы |
Определение |
|
|
Компонент |
Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса |
|
|
Комплекс |
Программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса |
Табл. 4.3. Виды программных документов
|
Вид программного документа |
Содержание программного документа |
|
|
Спецификация |
Состав программы и документации на нее |
|
|
Ведомость держателей подлинников |
Перечень предприятий, на которых хранят подлинники программных документов |
|
|
Текст программы |
Запись программы с необходимыми комментариями |
|
|
Описание программы |
Сведения о логической структуре и функционировании программы |
|
|
Программа и методика испытаний |
Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля |
|
|
Техническое задание |
Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
|
|
Пояснительная записка |
Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
|
|
Эксплуатационные документы |
Сведения для обеспечения функционирования и эксплуатации программы |
Табл. 4.4. Виды эксплуатационных документов
|
Вид эксплуатационного документа |
Содержание эксплуатационного документа |
|
|
Ведомость эксплуатационных документов |
Перечень эксплуатационных документов на программу |
|
|
Формуляр |
Основные характеристики программы, комплектность и сведения об эксплуатации программы |
|
|
Описание применения |
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств |
|
|
Руководство системного программиста |
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения |
|
|
Руководство программиста |
Сведения для эксплуатации программы |
|
|
Руководство оператора |
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы |
|
|
Описание языка |
Описание синтаксиса и семантики языка |
|
|
Руководство по техническому обслуживанию |
Сведения для применения тестовых и диагностических программ при обслуживании технических средств |
В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
Табл. 4.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды
|
Код вида документа |
Вид документа |
Стадии разработки |
||||
|
Эскизный проект |
Технический проект |
Рабочий проект |
||||
|
компонент |
комплекс |
|||||
|
- |
Спецификация |
- |
- |
! |
+ |
|
|
05 |
Ведомость держателей подлинников |
- |
- |
- |
? |
|
|
12 |
Текст программы |
- |
- |
+ |
? |
|
|
13 |
Описание программы |
- |
- |
? |
? |
|
|
20 |
Ведомость эксплуатационных документов |
- |
- |
? |
? |
|
|
30 |
Формуляр |
- |
- |
? |
? |
|
|
31 |
Описание применения |
- |
- |
? |
? |
|
|
32 |
Руководство системного программиста |
- |
- |
? |
? |
|
|
33 |
Руководство программиста |
- |
- |
? |
? |
|
|
34 |
Руководство оператора |
- |
- |
? |
? |
|
|
35 |
Описание языка |
- |
- |
? |
? |
|
|
46 |
Руководство по техническому обслуживанию |
- |
- |
? |
? |
|
|
51 |
Программа и методика испытаний |
- |
- |
? |
? |
|
|
81 |
Пояснительная записка |
? |
? |
- |
- |
|
|
90-99 |
Прочие документы |
? |
? |
? |
? |
|
|
Условные обозначения: |
||||||
|
+ |
- документ обязательный; |
|||||
|
! |
- документ обязательный для компонентов, имеющих самостоятельное применение; |
|||||
|
? |
- необходимость составления документа определяется на этапе разработки и утверждения технического задания; |
|||||
|
- |
- документ не составляют. |
Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
ГОСТ 19.102-77. ЕСПД. Стадии разработки
Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения (см. табл. 4.6).
Табл. 4.6. Стадии разработки, этапы и содержание работ
|
Стадии разработки |
Этапы работ |
Содержание работ |
|
|
Техническое задание |
Обоснование необходимости разработки программы |
Постановка задачи.Сбор исходных материалов.Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ. |
|
|
Научно-исследовательские работы |
Определение структуры входных и выходных данных.Предварительный выбор методов решения задач.Обоснование целесообразности применения ранее разработанных программ.Определение требований к техническим средствам.Обоснование принципиальной возможности решения поставленной задачи. |
||
|
Разработка и утверждение технического задания |
Определение требований к программе.Разработка технико-экономического обоснования разработки программы.Определение стадий, этапов и сроков разработки программы и документации на нее.Выбор языков программирования.Определение необходимости проведения научно-исследовательских работ на последующих стадиях.Согласование и утверждение технического задания. |
||
|
Эскизный проект |
Разработка эскизного проекта |
Предварительная разработка структуры входных и выходных данных.Уточнение методов решения задачи.Разработка общего описания алгоритма решения задачи.Разработка технико-экономического обоснования. |
|
|
Утверждение эскизного проекта |
Разработка пояснительной записки.Согласование и утверждение эскизного проекта |
||
|
Технический проект |
Разработка технического проекта |
Уточнение структуры входных и выходных данных.Разработка алгоритма решения задачи.Определение формы представления входных и выходных данных.Определение семантики и синтаксиса языка.Разработка структуры программы.Окончательное определение конфигурации технических средств. |
|
|
Утверждение технического проекта |
Разработка плана мероприятий по разработке и внедрению программ.Разработка пояснительной записки.Согласование и утверждение технического проекта. |
||
|
Рабочий проект |
Разработка программы |
Программирование и отладка программы |
|
|
Разработка программной документации |
Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77. |
||
|
Испытания программы |
Разработка, согласование и утверждение программы и методики испытаний.Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний.Корректировка программы и программной документации по результатам испытаний. |
||
|
Внедрение |
Подготовка и передача программы |
Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.Передача программы в фонд алгоритмов и программ. |
Примечания:
1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.
ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов
Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.
· Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика.
· Номер издания программы или номер редакции. номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).
· Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы.
ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам
Настоящий стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных.
Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей:
· титульной;
· информационной;
· основной.
Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.
ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом
Программные документы оформляют:
· на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом;
· допускается оформление на листах формата А3;
· при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
· на листах типографических форматов при изготовлении документа типографским способом.
Расположение материалов программного документа осуществляется в следующей последовательности:
титульная часть:
· лист утверждения (не входит в общее количество листов документа);
· титульный лист (первый лист документа);
информационная часть:
· аннотация;
· лист содержания;
основная часть:
· текст документа (с рисунками, таблицами и т.п.)
· перечень терминов и их определений;
· перечень сокращений;
· приложения;
· предметный указатель;
· перечень ссылочных документов;
часть регистрации изменений:
· лист регистрации изменений.
Перечень терминов и их определений, перечень сокращений, приложения, предметных указатель, перечень ссылочных документов выполняются при необходимости.
ГОСТ 19.402-78 ЕСПД. Описание программы
Состав документа «Описание программы» в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.502-78 ЕСПД. Описание применения, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора.
Есть также группа стандартов, определяющая требования к фиксации всего набора программ и ПД, которые оформляются для передачи ПС. Они порождают лаконичные тексты учетного характера и могут быть полезны для упорядочения всего объема сопроводительной документации.
Надо также выделить ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний, который (в адаптированном виде) может использоваться для разработки документов планирования и проведения испытательных работ по оценке готовности и качества ПС.
Наконец, последний по году принятия стандарт ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные графические и правила выполнения. Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.
Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также относящихся к документированию ПС и принятых не так давно, как большая часть ГОСТ ЕСПД.
ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения. Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.
ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.
Стандарты комплекса ГОСТ 34
ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в «Особенностях» ГОСТ 34. Объектами стандартизации являются автоматизированные системы (АС) различных (любых!) видов и все виды их компонентов, а не только ПО и БД.
Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается, отталкиваясь от этого содержания.
Из всех существующих и не реализованных групп документов приведем только примеры стандартов из Группы 0 «Общие положения» и Группы 6 «Создание, функционирование и развитие АС» . Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов) . Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.
Для общего случая разработки АС стадии и этапы ГОСТ 34 приведены в таблице 4.7.
Табл. 4.7. Стадии и этапы ГОСТ 34.
|
1. ФТ - Формирование требований к АС. |
1.1. Обследование объекта и обоснование необходимости создания АС;1.2. Формирование требований пользователя к АС;1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания); |
|
|
2. РК - Разработка концепции АС. |
2.1. Изучение объекта;2.2. Проведение необходимых научно-исследовательских работ;2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя2.4. Оформление отчета о выполненной работе |
|
|
3. ТЗ - Техническое создание АС. |
3.1. Разработка и утверждение технического задания на задание. |
|
|
4. ЭП - Эскизный проект. |
4.1. Разработка предварительных проектных решений по системе и ее частям;4.2. Разработка документации на АС и ее части. |
Подобные документы
Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
презентация [874,4 K], добавлен 19.09.2016Процессы Oracle CDM. Стадии и этапы выполнения работ по созданию автоматизированной системы (АС). Основные модели жизненного цикла ПО. Требования к содержанию документов. Основная проблема спирального цикла. Работы, выполняемые при разработке проекта.
презентация [194,1 K], добавлен 14.10.2013Общая характеристика основных моделей жизненного цикла: каскадная, инкрементная, спиральная. Стадия как часть процесса создания программного обеспечения, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта.
презентация [159,1 K], добавлен 27.12.2013Жизненный цикл информационных систем. Процессы документирования и управления конфигурацией. Использование каскадного и спирального подходов к построению ИС. Их преимущества и недостатки. Процесс разработки программного обеспечения по каскадной схеме.
презентация [350,6 K], добавлен 09.11.2015Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.
презентация [1,0 M], добавлен 11.05.2015Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
курсовая работа [1,8 M], добавлен 20.11.2010Стадии жизненного цикла ИС и его стандарты. Методологии, поддерживающие спиральную модель. Каскадная и инкрементная модели, их достоинства и недостатки. Основные, вспомогательные и организационные процессы жизненного цикла. Сравнительный анализ моделей.
курсовая работа [186,4 K], добавлен 21.05.2015Жизненный цикл программного обеспечения - непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятия его из эксплуатации. Подход к определению жизненного цикла ПО Райли, по Леману и по Боэму.
реферат [39,1 K], добавлен 11.01.2009Характеристика программных средств, использованных при разработке сайта. Параметры аппаратных средств для демонстрации ПП. Особенности архитектуры программного обеспечения. Анализ модели жизненного цикла программного продукта. Построение Gant-диаграммы.
курсовая работа [886,9 K], добавлен 30.05.2015Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014
