Технология разработки программного обеспечения

Санкт-Петербургский государственный университет телекоммуникаций

им. проф. М.А. Бонч-Бруевича

__________________________________________________________________

 

 

 

 

 

А.Е. Жолдасова

 

Технология разработки

программного обеспечения

 

Конспект лекций

 

специальность 230105 - Программное обеспечение вычислительной техники и автоматизированных систем

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Санкт-Петербург

2009 г.

 

Содержание курса:

1.Инженерия программного обеспечения: введение

1.1. Роль инженерии программного обеспечения в проектировании систем

1.2. История инженерии программного обеспечения: краткий курс

1.3. Роль программного инженера

1.4. Жизненный цикл программного обеспечения

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

2.1. Понятие модели процесса создания ПО

2.2. Важность моделей процесса создания ПО

2.3 Основные этапы создании программного обеспечения

2.3.1. Анализ осуществимости

2.3.2. Выявление, понимание и спецификация требований

2.3.3. Определение архитектуры программного обеспечения и рабочий проект

2.3.4. Кодирование и тестирование модулей

2.3.5. Сборка и системное тестирование

2.3.6. Поставка, развертывание и сопровождение ПО

2.3.7. Прочие виды деятельности

2.4 Обзор моделей процесса производства программного обеспечения

2.4.1. Каскадные модели

2.4.1.1Критическая оценка каскадной модели

2.4.2. Эволюционные модели

2.4.3. Модель, основанная на преобразовании

2.4.4. Спиральная модель

2.4.5. Оценка моделей процесса

3. Унифицированный язык моделирования.

3.1Способы применения UML

3.2 Архитектура, управляемая моделью, и исполняемый UML

3.3 История UML.

3.4 Диаграммы UML.

3.5 Процесс разработки с использованием UML.

3.5.1 Анализ требований

3.5.2 Проектирование

3.5.3 Документирование

3.5.4 Понимание унаследованного кода

 

1.Инженерия программного обеспечения: введение

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

Можно охарактеризовать программную инженерию как "применение принципов инженерной разработки к программному обеспечению". Более строго стандарт Std 610.12-1990 (Standard Glossary of Software Engineering Terminology) Института инженеров по электротехнике и электронике (IEEE) определяет суть программной инженерии как применение систематизированного, научного и рассчитываемого подхода к созданию, функционированию и сопровождению программного обеспечения.

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

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

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

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

 

1.1. Роль инженерии программного обеспечения в проектировании систем

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

Такие требования, как: "система не должна бездействовать более одной секунды в течение 20 лет" или "когда телефонная трубка снята, звучит гудок в течение полсекунды", — могут быть удовлетворены комбинацией настройки оборудования, программного обеспечения и устройств специального назначения. Решение того, как наилучшим образом отвечать всем требованиям, основано на принятии компромиссных решений. Системы управления электростанцией или дорожным движением, банковские системы, системы администрирования больниц — вот дополнительные примеры, демонстрирующие необходимость рассматривать программное обеспечение как компонент более крупной системы.

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

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

 

1.2. История инженерии программного обеспечения: краткий курс

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

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

Тогда, в начале 1960-х, было выполнено очень мало больших программных проектов, и делали это настоящие эксперты из компьютерных пионеров. Скажем, операционная система CTSS, разработанная в Массачусетском технологическом институте, была действительно большим проектом, и сделали ее высокообразованные и целеустремленные индивидуумы. С середины и до конца 1960-х предпринимались попытки построить по-настоящему большие системы на промышленной основе. Из них наиболее документированным стал проект разработки операционной системы OS 360 для семейства компьютеров IBM 360. Те, кто работал с крупными проектами, быстро поняли, что производство больших программных систем значительно отличается от разработки малых. Возникли принципиальные трудности масштабирования при попытке привнести приемы написания малых программ в проектирование больших. Приблизительно в это время и придумали термин "software engineering". Тогда всюду проходили конференции по обсуждению проблем, возникающих перед большими проектами трудностей сдачи обещанного продукта. Большие программные проекты повсеместно выходили за рамки бюджета и установленные сроки, в связи с чем тогда же родился термин "software crisis" — программный кризис.

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

Были предложены и опробованы многие решения. Одни считали, что выход из положения заключается в улучшении приемов менеджмента. Другие предлагали по-иному организовать команду разработчиков. Третьи выступали за усовершенствование языков программирования и средств разработки. Многие призывали к введению внутренних учрежденческих стандартов наподобие унифицированных соглашений кодирования. Кое-кто предлагал математические и формализованные подходы. Недостатка в идеях не было. Окончательное мнение было единодушным: программное обеспечение нужно строить так же, как инженеры строят другие большие сложные системы — мосты, нефтеперерабатывающие заводы, фабрики, корабли и самолеты. Вопрос был в том, чтобы рассматривать конечную программную систему как комплексный продукт, а его разработку — как инженерную работу. Инженерный поход требовал управления, организации, инструментария, теорий, методологий и технических приемов. Так родилась программная инженерия.

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