Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
iCarnecie_SSD2_RU_v5 (2).docx
Скачиваний:
18
Добавлен:
23.12.2018
Размер:
6.54 Mб
Скачать

4.5 Проектирование программного обеспечения

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

Последовательность чтения:

  • Цель изучения: Знание основ программирования.

  • 4.5.1 Введение в разработку крупномасштабных систем (Large-Scale Software) . Цель изучения: Знание процесса создания программного обеспечения.

  • 4.5.2 Модель открытого кода (Open source) . Цель изучения: Понимание открытого программного обеспечения ("open source"), разработка и знание GPL, the Gnu Public License (Публичная лицензия), типовой лицензии открытого программного обеспечения.

  • Parsons/Oja, Chapter 12-Section B Цель изучения: Понимание различных типов языков программирования и технологий программирования.

  • 4.5.3 Средства для создания и управления программным обеспечением Цель изучения: Знание средств, используемых программистами.

4.5.1 Введение в разработку крупномасштабных программных систем (Large-Scale Software).

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

  • Определение и пересмотр задачи

  • Планирование решения задачи

  • Кодирование решения

  • Общая оценка и тестирование

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

Когда измеряются затраты на разработку (всего часов), то оказывается, что написание кода программы — это относительно незначительная часть процесса создания программного обеспечения. Для нетривиальных программ, особенно крупномасштабного коммерческого программного обеспечения, программист не может только сидеть и писать коды программ. Вместо этого, каждый, вовлеченный в создание программного обеспечения, должен разделять понимание того, что должно делать программное обеспечение и из чего оно состоит. Процесс создания программного обеспечения начинается с определения потребности и проходит через серию фаз разработки, ведущих к поставке и использованию. Однако, детали того, как происходит этот процесс еще далеки от полного понимания и часто они являются объектом споров, а также темами многочисленных международных конференций. На практике процесс разработки редко устойчив и редко легко управляем. Половина всех проектов программного обеспечения отменяются до завершения, и большинство из тех, которые завершены, не удовлетворяют требованиям, указанным пользователями. Фактически, "разработка программного обеспечения" — одна из самых быстро растущих областей профессиональных интересов в содружестве программного обеспечения. Мы представляли процесс разработки в первом курсе программы SSD (Software Systems Development), SSD1 Введение в Информационные Системы. Был представлен следующий процесс программирования:

  1. Определение и пересмотр задачи (Define or redefine the problem)

  2. . Планирование решения задачи (Plan a solution to the problem)

  3. . Кодирование (Code the solution)

  4. Общая оценка и тестирование (Evaluate and test everything)

Ниже рисунок модели.

Определе-ние /пересмотр

Оценка/ Тестирование

Планирование

Кодиро-вание

Рисунок 1. Процесс разработки программного обеспечения.

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

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

Определение и переопределение задачи

  1. Осознание потребности (в программном продукте): возможно всеобщее понимание потребности, возможно пришедшее вследствие маркетинга или менеджмента, возможно источником является техническая группа, или потребность в разработке определяется контрактом.

  2. Спецификация (функциональные требования): это процесс опроса заинтересо­ванных сторон о требованиях к системе программного обеспечения. Хорошо сделать несколько циклов и протестировать предложения, сфокусировавшись на группе непосредственных пользователей.

Планирование решения задачи

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

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

Кодирование решения

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

  2. . Тестирование решения программистом: Сначала программист исследует программу на корректность. На следующем уровне, команды разработчиков встречается на сессиях обзора кода (code review sessions) для чтения и обсуждения работы. Полное тестирование проводиться руководителями проекта.

  3. Прием системы: Дополнительная группа некоторое время работает с программным обеспечением со смоделированными или реальными установками. Прием системы может быть достаточно формальным или неожиданно не формальным.

Общая оценка и тестирование

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

  2. Модернизация: Теперь начинается модернизация с возврата к первому шагу процесса.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]