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

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

Литература

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник., М.: 2003.

2. Орлов С.А., Цилькер Б.Я., Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с.

3. Смирнов А.А. Технологии программирования [Электронный ресурс]: учебное пособие/ Смирнов А.А., Хрипков Д.В.— Электрон. текстовые данные.— М.: Евразийский открытый институт, 2011.— 191 c.

4. Ковалевская Е.В. Методы программирования [Электронный ресурс]: учебное пособие/ Ковалевская Е.В., Комлева Н.В.— Электрон. текстовые данные.— М.: Евразийский открытый институт, 2011.— 320 c.

5. Дэвид Белладжио Стратегия управления конфигурацией программного обеспечения IBM Rational ClearCase [Электронный ресурс]/ Дэвид Белладжио, Том Миллиган— Электрон. текстовые данные.— М.: ДМК Пресс, 2008.— 384 c.

Этапы проектирования

Типовой проект предполагает реализацию следующих этапов разработки программного обеспечения:

1) анализ требований к проекту;

2) проектирование;

3) реализация;

4) тестирование продукта;

5) внедрение и поддержка.

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

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

Таким образом, проектированию обычно подлежат:

a) Архитектура ПО;

b) Устройство компонентов ПО;

c) Пользовательские интерфейсы.

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

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

Внедрение системы обычно предусматривает следующие шаги:

a) установка,

b) обучение пользователей,

c) эксплуатация.

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

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

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

1. Подготовка — сбор и обработка требований. Предварительное планирование этапов работ, сроков, ресурсов и стоимости.

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

3. Создание.

a) Дизайн — получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля.

b) Кодирование — получение исходного кода.

c) Тестирование — проверка программы на соответствие всем предъявляемым к ней требованиям.

d) Документирование — описание модели и структуры системы и ее компонентов, руководство по установке и сопровождению и пр.

 

 

Рис.1.1.

 

4. Поддержка.

a) Внедрение — установка программного обеспечения, обучение пользователей.

b) Сопровождение — исправление выявленных ошибок, поддержка пользователей.

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

 

UML-ДИАГРАММЫ

 

UML (Unified Modeling Language - унифицированный язык моделирования) – это язык графического описания для объектного моделирования в области разработки программного обеспечения. Он является языком широкого профиля. Это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. Язык был создан для определения, визуализации, проектирования и документирования программных систем.

Существует 13 официальных диаграмм UML 2.0, каждая из которых представляет собой различное представление разных аспектов системы. Наиболее распространенные из них представлены на рисунке 6.1, как средства моделирования сложной системы.

Рис.6.1

 

Взаимосвязь между основными диаграммами UML иллюстрирует рисунок 6.2.

 

Рис.6.2

В курсовом проекте предлагается использовать следующие диаграммы:

1) модель хранения данных;

2) вариантов использования;

3) классов;

4) деятельности (для одного из вариантов использования);

5) последовательности действий (для одного из вариантов использования);

6) состояний основного класса программы;

7) компонентов системы;

8) размещения программных компонентов системы.

Рассмотрим, как строится каждая из этих диаграмм.

 

Модель хранения данных

 

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

a) Логическая и

b) Физическая.

Более подробно модели данных изучаются в рамках дисциплины «Базы данных». Здесь они будут рассмотрены кратко, в объеме, необходимом для проектирования программной системы.

В логической модели данных отображаются ключевые сущности и взаимосвязи, относящиеся к важнейшей информации, которую приложению необходимо хранить в базе данных. Она связана с моделью классов, которые используются при проектировании программы. Логическая модель отражает ключевые логические сущности и их взаимосвязи, необходимые для соблюдения требований системы к постоянному хранению данных в соответствии с общей архитектурой приложения. В теории баз данных логическую модель еще называют моделью «сущность – связь» или ER -диаграммой (от Entity – сущность и Relationships – связь).

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

 

Рис. 6.3

 

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

 

Рис. 6.4

 

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

Пример логической модели данных для объекта «Клинические записи» приведен ниже на рис. 6.5.

 

 

Рис.6.5

 

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

Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым.

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

 

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

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

 

Рис. 6.6

 

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

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

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

 

Рис.6.7 Фрагмент модели базы данных

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

a) Ограничения, которые определяют допустимые значения данных в столбце или операции над данными:

- (ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец;

- проверка (Check) – ограничение, определяющее правило контроля данных;

- уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);

b) триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;

c) тип данных и пр.

 

6.2. Диаграммы вариантов использования

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

Цели построения диаграммы:

1) определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования;

2) сформулировать общие требования к функциональному проектированию системы;

3) разработать исходную концептуальную модель системы для ее последующей реализации;

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

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

Таким образом, основными компонентами ДВИ являются:

a) Актеры;

b) Прецеденты;

c) Отношения.

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

Рис. 6.8

 

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

Пример стандартного графического изображения актера приведен на рис. 6.9.

Актер всегда находится вне системы, его внутренняя структура никак не воспринимается.

Рис. 6.9

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

Прецедент (use case – юскейс) определяет последовательность действий, которая должна быть выполнена проектируемой системой при взаимодействии ее с соответствующим актером.

Отношения устанавливают связи между актерами и прецедентами (ВИ).

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

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

Виды отношений

1) ассоциативное (отношение ассоциации, association relationship);

2) расширения (extend relationship);

3) обобщения (generalization relationship);

4) включения (include relationship).

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

Рис. 6.10

 

Отношение расширения определяет взаимосвязь базового варианта использования с некоторым другим вариантом, функциональное поведение которого задействуется базовым не всегда, а только при выполнении некоторых дополнительных условий. Стрелка указывает на базовый вариант использования (см. рис. 6.11).

 

 

Рис. 6.11

Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования Б (или актер А может быть обобщен до актера Б). Стрелка указывает в сторону родительского ВИ (актера). Такие отношения изображены на рис. 6.12 и 6.13.

 

Рис. 6.12

Рис. 6.13

 

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

Рис. 6.14

 

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

Рис. 6.15

Примеры диаграмм вариантов использования

ДВИ процесса оформления заказа на покупку товара приведена на рис. 6.16, а Диаграмма прецедентов для процесса постройки дома – на рис. 6.17.

 

 

Рис. 6.16

 

 

Рис. 6.17

Диаграммы классов

 

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

Класс – это множество объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. На диаграмме он представляется прямоугольником, который может иметь вид, приведенный на рис. 6.18.

Рис. 6.18

 

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

Атрибут - это свойство, которое является общим для всех объектов данного класса. Общий формат записи атрибутов:

<квантор видимости> <имя атрибута> [кратность]: <тип атрибута> = <исходное значение> {строка-свойство}

Квантор видимости может принимать одно из следующих значений:

«+» - атрибут с областью видимости типа общедоступный (public).

«#» - атрибут с областью видимости типа защищенный (protected).

«-» - атрибут с областью видимости типа закрытый (private).

«~» - атрибут с областью видимости типа пакетный (package).

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

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

[нижняя граница .. верхняя граница]

Примеры: [0..1], [0..*], [1..3,5..7].

Тип атрибута - выражение, определяемое некоторым типом данных (в зависимости от языка программирования). В простейшем случае – осмысленная строка текста.

Пример:

цвет: Color

имяСотрудника[1..2]: String;

видимость: Boolean

Исходное значение служит для задания некоторого начального значения в момент создания отдельного экземпляра класса.

Пример:

цвет: Color = (255, 0, 0)

имяСотрудника[1..2]: String = ‘Иван Иванов’;

видимость: Boolean = истина

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

Пример:

заработнаяПлата: Currency = $500 {frozen}

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

Правила записи операций:

<квантор видимости> <имя операции> (список параметров):
<выражение типа возвращаемого значения> {строка-свойство}

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

<вид параметра> <имя параметра>: <выражение типа> = <значение по умолчанию>

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

{concurrency = имя},

где имя может принимать одно из следующих значений:

sequential (последовательная),

concurrent (параллельная),

guarded (охраняемая).

Примеры операций класса

+нарисовать(форма: Многоугольник=прямоугольник, цветЗаливки: Color=(0, 0, 255));

-изменитьСчетКлиента (номерСчета: Integer): Currency;

#выдатьСообщение(): (‘Ошибка деления на ноль’).

Отношения между классами

 

Базовыми отношениями на диаграмме классов являются:

a) отношения ассоциации (association);

b) отношения обобщения (generalization);

c) отношения агрегации (aggregation);

d) отношения композиции (composition);

e) отношения зависимости (dependency).

Отношение ассоциации свидетельствует о наличии произвольной связи между классами. Пример такого отношения приведен на рис. 6.19.

 

Рис. 6.19

 

Отношение обобщения является отношением классификации между более общим элементом (родителем или предком) и частным или специальным элементом (дочерним или потомком). Пример такого отношения приведен на рис. 6.20.

 

 

Рис. 6.20

 

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

 

Рис. 6.21

 

Отношение композиции является частным случаем отношения агрегации. Части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются составные части.Пример такого отношения приведен на рис. 6.22.

Рис. 6.22

 

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

 

Рис. 6.23

Пакеты служат для группировки элементов модели. Их представление на диаграмме имеет вид рис. 6.24. Любой пакет владеет своими элементами. Любой элемент может принадлежать только одному пакету.

Рис. 6.24

 

Пример диаграммы классов приведен на рис. 6.25.

Рис. 6.25

 

Диаграммы деятельности

 

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

1. Прямоугольники с закруглениями — действия;

2. Ромбы — решения;

3. Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий;

4. Чёрный круг — начало процесса (начальное состояние);

5. Чёрный круг с обводкой — окончание процесса (конечное состояние).

Стрелки идут от начала к концу процесса и показывают последовательность переходов.

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

Для каждого объекта на диаграмме выделяется, так называемая, беговая дорожка. Она соответствует объекту или роли. На дорожке отображаются только те деятельности, за которые отвечает конкретный объект. Она является важной частью диаграммы деятельности.

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

 

Рис. 6.26.

 

Диаграммы состояний класса

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

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

a) Круг, обозначающий начальное состояние.

b) Окружность с маленьким кругом внутри, обозначающая конечное состояния (если есть).

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

d) Стрелка, обозначающая переход. Название события (если есть), вызывающего переход, отмечается рядом со стрелкой. Здесь же записывается охраняющее выражение. Оно может быть добавлено перед «/» и заключено в квадратные скобки (название_события [охраняющее_выражение]), т.е. это выражение должно быть истинным, чтобы переход имел место. Если при переходе производится какое-то действие, то оно добавляется после «/» (название_события [охраняющее_выражение]/действие).

e) Толстая горизонтальная линия либо с множеством входящих линий и одной выходящей, либо с одной входящей линией и множеством выходящих. Она обозначает объединение и разветвление соответственно (как в диаграммах деятельности).

Пример простейшей диаграммы представлен на рисунке 6.32. В ней отображены два состояния DVD диска и переходы между ними. Действия для каждого состояния не указываются.

Рис. 6.32

 

Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели. Например, прохождение студентом некоторого учебного курса может быть представлено диаграммой сложного (составного) состояния, приведенной на рис. 6.33.

Рис. 6.33

 

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

Литература

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник., М.: 2003.

2. Орлов С.А., Цилькер Б.Я., Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с.

3. Смирнов А.А. Технологии программирования [Электронный ресурс]: учебное пособие/ Смирнов А.А., Хрипков Д.В.— Электрон. текстовые данные.— М.: Евразийский открытый институт, 2011.— 191 c.

4. Ковалевская Е.В. Методы программирования [Электронный ресурс]: учебное пособие/ Ковалевская Е.В., Комлева Н.В.— Электрон. текстовые данные.— М.: Евразийский открытый институт, 2011.— 320 c.

5. Дэвид Белладжио Стратегия управления конфигурацией программного обеспечения IBM Rational ClearCase [Электронный ресурс]/ Дэвид Белладжио, Том Миллиган— Электрон. текстовые данные.— М.: ДМК Пресс, 2008.— 384 c.

Этапы проектирования

Типовой проект предполагает реализацию следующих этапов разработки программного обеспечения:

1) анализ требований к проекту;

2) проектирование;

3) реализация;

4) тестирование продукта;

5) внедрение и поддержка.

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

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

Таким образом, проектированию обычно подлежат:

a) Архитектура ПО;

b) Устройство компонентов ПО;

c) Пользовательские интерфейсы.

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

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

Внедрение системы обычно предусматривает следующие шаги:

a) установка,

b) обучение пользователей,

c) эксплуатация.

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

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

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

1. Подготовка — сбор и обработка требований. Предварительное планирование этапов работ, сроков, ресурсов и стоимости.

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

3. Создание.

a) Дизайн — получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля.

b) Кодирование — получение исходного кода.

c) Тестирование — проверка программы на соответствие всем предъявляемым к ней требованиям.

d) Документирование — описание модели и структуры системы и ее компонентов, руководство по установке и сопровождению и пр.

 

 

Рис.1.1.

 

4. Поддержка.

a) Внедрение — установка программного обеспечения, обучение пользователей.

b) Сопровождение — исправление выявленных ошибок, поддержка пользователей.

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