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

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

Такой подход к разработке ПО не новый и им активно пользуется множество людей начиная с 1970-х гг. По многим показателям он гораздо лучше, чем эволюционное проектирование в стиле «code and fix», однако и у него есть существенные недостатки, один из которых заключается в том, что невозможно заранее продумать все вопросы, с которыми придется столкнуться во время кодирования системы. Таким образом, в ходе работ непременно возникнет ситуация, когда у программистов появятся вопросы относительно спроектированного дизайна. Однако если проектировщики, закончив свою часть работы, уже переключились на другой проект, тогда программисты начинают самостоятельно решать сложившуюся проблему, отступая от уже принятых проектных решений и внося при этом в программный продукт долю энтропии. И даже если проектировщик еще работает над проектом и может помочь, все равно ему потребуется довольно много времени, чтобы выяснить ситуацию, внести изменения в диаграммы и уже затем менять код.

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

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

Основополагающие практики ХР

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

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

В основе ХР лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии ХР, а с другой - оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют.

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

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

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

Преимущества простого дизайна

В ХР очень популярны два лозунга: «Do the Simplest Thing that Could Possibly Work» («Ищите самое простое решение, которое может сработать») и YAGNI («You Aren't Going to Need It» - «Это вам не понадобится»). Оба они олицетворяют собой одну из практик ХР под названием простой дизайн [3].

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

Тем не менее ХР не советует заниматься созданием гибких компонентов и каркасов до того, как понадобится именно эта функциональность. Лучше, если эти структуры будут наращиваться по мере необходимости. Если сегодня необходим класс Money, который обрабатывает сложение, а не умножение, то в этот класс следует встраивать только сложение.

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

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

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

Такой стиль работы многим кажется абсурдным, и следует отметить, что они правы, однако при одном условии - абсурд получится, если эту практику начать применять в обычном процессе разработки, а все остальные практики ХР игнорировать. Если изменить существующий баланс между эволюционным и предварительным проектированием, то YAGNI становится очень полезным принципом.

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

В книге Extreme Programming Explained Кент приводит четыре критерия простой системы [21]:

• система успешно проходит все тесты;

• код системы ясно раскрывает все изначальные замыслы;

• в ней отсутствует дублирование кода;

• используется минимально возможное количество классов и методов.

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

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

Рефакторинг и принцип YAGNI

Процесс рефакторинга требует времени, но не добавляет новой функциональности. В тоже время по принципу YAGNI следует проектировать только для текущей функциональности, а не для того, что понадобится в будущем.

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

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

Наращивание архитектуры

Термин «архитектура» передает идею основных элементов системы, тех ее частей, которые трудно изменить. Они являются фундаментом, на котором можно построить все остальное [6].

Какую роль играет архитектура в эволюционном проектировании? Критики ХР считают, что эта методология вообще не признает работы над архитектурой, что вся суть ХР - сразу сесть за написание кода и надеяться на то, что рефакторинг решит все проблемы с проектированием. Приверженцы ХР - Кент Бек (Kent Beck), Рон Джеффриз (Ron Jeffries) и Боб Мартин (Bob Martin) - прилагают очень много сил, чтобы вообще избежать любого предварительного проектирования архитектуры.

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

UML и ХР

В идеале ХР полностью отрицает проектирование системы, в частности, методами UML. Тем не менее программисты все же часто используют на начальном этапе диаграммы UML, которые очень полезны для понимая разрабатываемого продукта. [2].

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

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

• нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае они не будут соответствовать программному коду;

• диаграммы находятся внутри сложного CASE-средства либо в папке, и никто туда не заглядывает.

И, наконец, последний аспект использования UML для документации - передача проекта в другие руки (например, от одной группы разработчиков другой). Согласно методологии ХР создание документации - такая же задача, как и все остальные, а значит, ее приоритет должен быть определен заказчиком. В этой ситуации может пригодиться UML, разумеется, при условии избирательности диаграмм, которые создавались с целью облегчения коммуникации. Следует отметить, что программный код - это основной репозиторий подробной информации, а диаграммы служат для обобщенного представления основных аспектов системы.

Суть проектирования. Программирование и тестирование

Для проектирования в ХР необходимы следующие качества:

• постоянное желание сохранять программный код простым и понятным насколько это возможно;

• наличие навыков рефакторинга, так чтобы с уверенностью вносить в систему изменения, как только в этом возникнет необходимость;

• хорошее знание паттернов: рассматривать их не просто как готовые решения, а оценивать своевременность и использовать постепенно, от простого к сложному;

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

Для того чтобы реализовать задачу, ответственный за нее программист прежде всего ищет себе партнера, поскольку окончательный код всегда пишется двумя людьми на одной машине. Если возникают вопросы о предмете или методах реализации, партнеры проводят короткую (15-минутную) встречу с заказчиком и/или программистами, осведомленными в вопросах кодирования задач, которые с наибольшей вероятностью будут связаны с кодом данной задачи в ходе реализации [1, 5].

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

• мы знаем простой способ заставить его работать, и мы действуем этим способом;

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

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

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

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

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

Преимущества парного программирования

• Парное программирование экономически оправдано. При использовании в организации ХР штат программистов должен возрасти вдвое. Так как квалифицированные кадры являются достаточно дорогими, то, казалось бы, расходы на создание программного обеспечения должны значительно возрасти. И это, действительно, так - затраты возрастают на 15%, но в то же время, как доказывают исследования, при парном программирование количество ошибок на 15% меньше, чем при одиночном. Если учесть стоимость исправления ошибок, обнаруженных на разных стадиях жизненного цикла продукта, включая внедрение, то сэкономленные на этом деньги значительно превосходят затраты на увеличение штата сотрудников.

• Быстрая обучаемость. При парном программировании специалисты перенимают приемы работы друг друга, значительно расширяют свои знания и передают свой опыт.

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

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

• Работа в паре улучшает общение в коллективе, помогает наладить понимание и взаимоотношения, что является крайне важным фактором с точки зрения психологии [12].

Тест

Основной метод ХР - это, безусловно, тестирование модулей (unit testing), является неотъемлемой частью повседневной работы каждого программиста. Две особенности и делают процесс тестирования в ХР гораздо более эффективным по сравнению с традиционными методами: программисты сами пишут свои тесты и делают это до начала кодирования.

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

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

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

Контрольные вопросы

1. Какие виды ошибок существуют?

2. Что такое тест?

3. Какими свойствами должен обладать тест?

4. Каковы критерии выбора тестов?

5. Дайте кратную характеристику каждому критерию выбора теста.

6. Опишите последовательность разработки тестов.

7. Перечислите аксиомы тестирования по Мэйерсу.

8. Что входит в понятие надежности ПО?

9. Какие виды отказов существуют?

10. Каковы количественные характеристики надежности программ?

11. Что представляют собой методы оценки и измерения характеристик надежности ПО?

12. Охарактеризуйте метод Миплса.

13. Охарактеризуйте метод Руднера.

14. Охарактеризуйте метод фирмы «Моторола».

15. Какие виды проектирования существуют?

16. Какой вид проектирования используется при экстремальном программировании?

17. Что включает в себя понятие «простой дизайн»?

18. Перечислите основополагающие практики ХР.

19. Что такое рефакторинг?

20. Чем характеризуется принцип YAGNI?

21. Почему простой дизайн имеет большое значение в ХР?

22. Как соотносятся UML и ХР?

23. Как происходит процесс программирования и тестирования ХР?

24. Перечислите достоинства парного программирования.

Лабораторный практикум

Лабораторная работа 1 Техническое задание на проектирование программы

Цель работы: ознакомиться с правилами написания технического задания.

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

Общие сведения

1. Требования к оформлению

1.1. Техническое задание оформляют в соответствии с ГОСТ 2.610-2006 на листах формата А4 и A3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 2.610-2006. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

1.3. Для внесения изменений и дополнений в техническое
задание на последующих стадиях разработки программы или
программного изделия к нему выпускают дополнение. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

1.4. Техническое задание должно содержать следующие разделы:

• название программы и область применения;

• основание для разработки;

• назначение разработки;

• технические требования к программе или программному изделию;

• технико-экономические показатели;

• стадии и этапы разработки:

• порядок контроля и приемки;

• приложения.

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

2. Содержание разделов

2.1. В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.2. В разделе «Основание для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;

• организация, утвердившая этот документ, и дата его утверждения;

• наименование и (или) условное обозначение темы разработки.

2.3. В разделе «Назначение разработки» должно быть указано
функциональное и эксплуатационное назначение программы
или программного изделия.

2.4. Раздел «Технические требования к программе или программному изделию» должен содержать следующие подразделы:

• требования к функциональным характеристикам;

• требования к надежности;

• условия эксплуатации;

• требования к составу и параметрам технических средств;

• требования к информационной и программной совместимости;

• требования к маркировке и упаковке;

• требования к транспортированию и хранению;

• специальные требования.

2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.

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

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик.

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

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

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

В разделе «Стадии и этапы разработки* устанавливают
необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

В приложениях к техническому заданию при необходимости приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;

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

• другие источники разработки.

Пример выполнения задания

1. Введение

Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электро-, теплоснабжением корпусов института».

2. Основание для разработки

2.1. Основанием для данной работы служит договор № ___ от _________ 20___ г.

2.2. Наименование работы:

2.3. «Модуль автоматизированной системы оперативно-диспетчерското управления теплоснабжением корпусов института».

2.4. Исполнители: ОАО «Лаборатория создания программного обеспечения.

2.5. Соисполнители: нет.

3. Назначение разработки

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

4.Технические требования

4.1. Требования к функциональным характеристикам

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

- сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков SA-94 на всех тепловых выходах;

- сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);

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

- выдачу рекомендаций по дальнейшей работе;

- отображение текущего состояния по набору параметров - циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров;

- визуализацию информации по расходу теплоносителя;

- текущую, аналогично показаниям счетчиков;

- с накоплением за прошедшие сутки, неделю, месяц - в виде почасового графика для информации за сутки и неделю;

- суточный расход - для информации за месяц.

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

По отдельному запросу осуществляются внутренние настройки.

В конце отчетного периода система должна архивировать данные.

4.1.2. Организация входных и выходных данных

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

Основной режим использования системы - ежедневная работа.

4.2. Требования к надежности

Для обеспечения надежности необходимо проверять корректность получаемых данных с датчиков.

4.3. Условия эксплуатации и требования к составу и параметрам технических средств

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

4.4. Требования к информационной и программной совместимости

Программа должна работать на платформах Windows.

4.5. Требования к транспортировке и хранению

Программа поставляется на лазерном носителе информации. Программная документация поставляется в электронном и печатном виде.

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

5. Требования к программной документации

Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой системы программной документации (ЕСПД); руководство пользователя, руководство администратора, описание применения.

6. Технико-экономические показатели

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

7. Порядок контроля и приемки

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

8. Календарный план работ

Название этапа	Сроки этапа	Чем закачивается этап
1. Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы.	01.02.20__ - 28.02.20__	Предложения по работе системы. Акт сдачи-приёмки
2. Разработка программного модуля по сбору и анализу информации со счётчиков и устройств управления. Внедрение системы для одного из корпусов ЧГУ.	01.03.20__ - 31.08.20__	Программный комплекс
3. Тестирование и отладка модуля. Внедрение системы во всех корпусах ЧГУ.	01.09.20__ - 30.12.20__	Готовая система контроля теплоснабжения, установленная в диспетчерском пункте Программная документация. Акт сдачи-приёма работ

Руководитель работ Сидоров А.В.

Рис. 1.1 Пример титульного листа на техническое задание

Индивидуальные задания

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

1. Разработка программного комплекса «Автотранспорт».

2. Разработка программного комплекса «Деканат института».

3. Разработка программного комплекса «Обслуживание банкомата».

4. Разработка программного комплекса «Управление гостиницей».

5. Разработка программного комплекса «Выдача кредитов в банке».

6. Разработка программного комплекса «Строительная фирма».

7. Разработка программного комплекса «Управление библиотечным фондом».

8. Разработка программного комплекса «АРМ работника склада».

9. Разработка программного комплекса «АРМ администратора ателье по ремонту оргтехники».

10. Разработка программного комплекса «АРМ администратора автосалона».

11. Разработка программного комплекса «АРМ администратора ресторана».

12. Разработка программного комплекса «АРМ сотрудника ЖЭСа».

13. Разработка программного комплекса «АРМ администратора аэропорта».

14. Разработка программного комплекса «АРМ работника отдела кадров».

15. Разработка программного комплекса «АРМ администратора спорткомплекса».

Лабораторная работа 2 Стадия разработки программного обеспечения «Эскизный проект»

Цель работы: научиться создавать формальные модели и на их основе определять спецификации разрабатываемого программного обеспечения.

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Анализ требований и определение спецификаций программного обеспечения» учебной дисциплины «Технология разработки программного обеспечения».

Теоретическая часть

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

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

Структурный анализ предполагает использование следующих видов моделей:

• диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

• диаграмм «сущность - связь» (ERD - Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

• диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

• функциональных диаграмм (методика SADT);

• спецификаций процессов;

• словаря терминов.

Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси - Шнейдермана.

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

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

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

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

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

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

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

Порядок выполнения работы

1. На основе технического задания из лабораторной работы №1 выполнить анализ функциональных и эксплуатационных требований к программному продукту.

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

3. Определить диаграммы потоков данных для решаемой задачи.

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

5. Определить функциональные диаграммы.

6. Определить диаграммы переходов состояний.

7. Определить спецификации процессов.

8. Добавить словарь терминов.

9. Оформить результаты, используя MS Office в виде эскизного проекта.

10. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен содержать:

1. Постановку задачи.

2. Документ «Эскизный проект», включающий:

• выбор метода решения и языка программирования;

• спецификации процессов;

• все полученные диаграммы;

• словарь терминов.

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

Допустим, на предыдущих стадиях разработки было составлено и утверждено техническое задание на создание информационной системы СУБД «Пенсионный Фонд», разработанное на основании ГОСТ 34.602 - 89 на написание ТЗ на автоматизированные системы управления от 01.01.1990 г.

Пояснительная записка к эскизному проекту

Данный документ является эскизным проектом на создание Системы Управления Базой Данных для Библиотечного Фонда Российской Федерации (СУБД «Библиотека»).

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

Рассмотрим пример эскизного проекта, титульный лист которого приведен на рис. 2.1.

Рис. 2.1 Титульный лист эскизного проекта

Ведомость эскизного проекта

Основные технические решения

Решения по структуре системы СУБД «Библиотека» будет представлять собой персональную систему управления локальной базой данных, работающей на одном компьютере.

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

Общая структура базы данных:

1. Анкеты организации, которые зарегистрированы в данном ПФ:

• тип предприятия (российская организация, физическое лицо, иностранная организация, обособленное подразделение);

• вид предприятия;

• регистрационный номер работодателя в ПФР.

2. Свидетельство: серия, номер.

3. Дата выдачи свидетельства.

4. ИНН.

5. КПП.

6. Наименование.

7. Юридический адрес.

8. Адрес постоянно действующего органа (при отличии от юридического).

9. Анкеты сотрудников этих организаций.

10. Сведения о стаже сотрудников этих организаций.

11. Таблица периодов работы со следующей структурой:

• Начало периода (дата).

• Конец периода (дата).

• Вид деятельности (работа, служба соцстрах, уход-дети, безр, реабилит, уход-инвд, профзаб, пересмотр).

• Наименование организации.

• Должность.

• Территориальные условия.

Работа системы СУБД «Библиотека» будет функционировать в однопользовательском режиме, а также будет способна:

• просматривать записи базы данных (в том числе и при помощи фильтров);

• добавлять новые записи;

• удалять записи;

• при входе в систему будет запрашиваться пароль.

Автоматизированная система должна выполнять следующие функции:

• сделать запись о пенсионном удостоверении;

• удалить информацию о пенсионном удостоверении;

• выдать справку о всех пенсионных удостоверениях;

• зарегестрировать новое предприятие в ПФ РФ;

• удалить предприятие из базы данных;

• выдать справку обо всех предприятиях, зарегистрированных в ПФ РФ;

• подсчитать пенсию для работников предприятий на основании стажа;

• выдать справку о пенсионных накоплениях работника.

Для реализации АС будет использоваться среда программирования Boland Delphi 7.0 и язык программирования Object Pascal.

Для подсчета пенсии будет использоваться следующий алгоритм. Вначале определяется стажевый коэффициент пенсионера. Он полагается равным 0,55 за общий трудовой стаж до текущей даты не менее 25 лет мужчинам и 20 лет женщинам. За каждый полный год стажа больше указанного стажевый коэффициент увеличивается на 0,01, но не более чем на 0,20.

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

Отношение заработков учитывается в размере не свыше 1,2. Для пенсионеров, проживающих на Крайнем Севере, учитываемое соотношение выше: от 1,4 до 1,9 в зависимости от установленного в централизованном порядке районного коэффициента к зарплате.

Затем стажевый коэффициент умножается на соотношение заработков и на 1671 руб. - утвержденную для расчетов среднемесячную зарплату в стране за III квартал 2001 г. Это и будет пересчитанный размер трудовой пенсии по новому законодательству в обычном случае. Если он оказался менее 660 руб., то размер пенсии повышается до этого гарантированного минимума.

Если пенсионер является инвалидом I группы или достиг к 1 января 2002 г. возраста 80 лет и более, рассчитанный в этом порядке размер пенсии по старости увеличивается на 450 руб.

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

Источники разработки

Данный документ разрабатывался на основании ГОСТ34.698 - 90 на написание ТЗ на автоматизированные системы управления от 01.01.1992 г.

Лабораторная работа 3 Стадия разработки программного обеспечения «Технический проект»

Цель работы: изучить вопросы проектирования программного обеспечения.

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Проектирование программного обеспечения» учебной дисциплины «Технология разработки программного обеспечения».

Теоретическая часть

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

Цель технического проекта - определение основных методов, используемых при создании информационной системы, и окончательное определение ее сметной стоимости.

Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием.

Технический проект программной системы подробно описывает:

• выполняемые функции и варианты их использования;

• соответствующие им документы;

• структуры обрабатываемых баз данных;

• взаимосвязи данных;

• алгоритмы их обработки.

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

При разработке технического проекта оформляются:

• ведомость технического проекта. Общая информация по проекту;

• пояснительная записка к техническому проекту. Вводная информация, позволяющая ее потребителю быстро освоить данные по конкретному проекту;

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

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

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

• описание используемого программного обеспечения.

• перечень программного обеспечения и СУБД, которые планируется использовать для создания информационной системы;

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

• проектная оценка надежности системы. Экспертная оценка надежности с выявлением наиболее благополучных участков программной системы и ее узких мест;

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

Структурная схема

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

Структурная схема определяется архитектурой разрабатываемого ПО:

• структуры обрабатываемых баз данных;

• взаимосвязи данных;

• алгоритмы их обработки.

Функциональная схема

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

Порядок выполнения работы

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

2. На основе уточненных и доработанных алгоритмов разработать структурную схему программного продукта.

3. Разработать функциональную схему программного продукта.

4. Оформить результаты, используя MS Office в виде технического проекта.

5. Сдать и защитить работу.

Лабораторная работа 4 Использование объектно-ориентированного программирования (ООП) для создания качественного программного обеспечения

Цель работы: познакомиться с принципами объектно-ориентированного программирования в среде Delphi. Написать и отладить программу линейного алгоритма, в которой присутствовали бы некоторые критерии и примитивы качественного программного обеспечения.

Общие сведения

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

Класс - это тип данных. Объект класса - переменная типа «класс». Из определения класса следует первое свойство ООП - инкапсуляция. Инкапсуляция данных означает, что они являются не глобальными - доступными всей программе, а локальными - доступными только малой ее части. Инкапсуляция автоматически подразумевает защиту данных. Для этого в структуре class используется спецификатор раздела private, содержащий данные и методы, доступные только для самого класса. Если данные и методы содержатся в разделе public, они доступны извне класса. Раздел protected содержит данные и методы, доступные из класса и любого его производного класса.

Интегрированная среда разработки Delphi

Среда Delphi визуально реализуется в виде нескольких одновременно раскрытых на экране монитора окон. Количество, расположение, размер и вид окон может меняться в зависимости от текущих нужд, что значительно повышает производительность работы. При запуске Delphi можно увидеть на экране картинку (рис. 4.1).

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

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

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

Окно текста программы предназначено для просмотра, написания и корректирования текста программы. В системе Delphi используется язык программирования Object Pascal. При первоначальной загрузке в окне текста программы находится текст, содержащий минимальный набор операторов для нормального функционирования пустой формы в качестве Windows-окна. При помещении некоторого компонента в окно формы текст программы автоматически дополняется описанием необходимых для его работы библиотек стандартных программ (раздел uses) и типов переменных (раздел type).

Рис. 4.1 Внешний вид окна Delphi. 1 - главное окно; 2 - основное меню; 3 - пиктограммы основного меню; 4 - окно инспектора объектов; 5 - окно текста программы; 6 - окно пустой формы, 7 - меню компонентов

Программа в среде Delphi составляется как описание алгоритмов, которые необходимо выполнить, если возникает определенное событие, связанное с формой (например, щелчок мыши на кнопке - событие OnClick, создание формы - OnCreate). Для каждого обрабатываемого в форме события с помощью страницы Events инспектора объектов в тексте программы организуется процедура (procedure), в которой записывается на языке Object Pascal требуемый алгоритм.

Переключение между окном формы и окном текста программы осуществляется с помощью клавиши F12.

Меню и команды Delphi

Для того чтобы выдать команду в среде Delphi, можно воспользоваться тремя основными способами:

с помощью меню;

с помощью полоски SpeedBar (инструментальной линейки);

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

Меню File

Команды выпадающего меню File можно использовать для работы как с проектами, так и файлами исходного кода.

К командам, работающим с проектами, относятся New, New Application, Open, Reopen, Save Project As, Save All, Close All, Add to Project и Remove from Project. С файлами исходного кода работают команды New, New Form, New Data Module, Open, Reopen, Save As, Save, Close и Print. Основной командой является File/New, которую можно использовать для вызова экспертов, для начала работы с новым приложением, наследования формы из уже существующей и т.д. Для того чтобы открыть проект или файл исходного кода, с которыми вы работали последний раз, используйте команду File/Reopen.

Меню Edit

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

...