- •Министерство образования российской федерации Воронежский государственный технический университет а.Г. Остапенко г.А. Кащенко и.В.Давыдов Морев д.Е.
- •Воронеж 2001
- •Рецензенты: Остапенко г.А.
- •Введение
- •Методы разработки программного обеспечения
- •Подходы к разработке программного обеспечения
- •Планирование разработки программного обеспечения
- •Основные типы языков программирования.
- •Процедурное программирование
- •Функциональное программирование
- •Логическое программирование
- •Объектно-ориентрованное программирование
- •Процедуры.
- •Модули.
- •Абстрактные типы данных.
- •Построение программного обеспечения по объектно-ориентированной методике
- •2.1. Функционирование объектно-ориентированного программного обеспечения
- •2.2. Классы. Отношения между классами
- •Этапы построения программного обеспечения
- •2.4. Объектно-ориентированный анализ
- •Информационные модели
- •Жизненные циклы
- •Модели процессов
- •2.5. Нотация для объектно-ориентированного проектирования
- •2.6. Объектно-ориентированное проектирование – ood
- •2.7. Заключительное замечание
- •Основные недостатки:
- •3. Средства объектно-ориентированного программирования
- •Средства объектно-ориентированного рограммирования Turbo-Pascal
- •Понятие “объект”
- •Статические и виртуальные методы. Полиморфизм Статические методы
- •Виртуальные методы. Полиморфизм
- •Конструкторы и деструкторы
- •3.1.5. Сравнимость данных типа объект
- •3.1.6. Динамический вызов объектов
- •3.2. Средства объектно-ориентированного
- •Понятие “класс”
- •Компоненты классов. Доступ к ним.
- •Дружественные функции
- •Конструкторы и деструкторы
- •Статические члены классов
- •3.2.6. Перегрузка операций
- •3.2.7. Виртуальные функции
- •3.2.8. Динамическое создание объектов
- •3.2.9. Проверьте свои знания!
- •Литература:
- •Оглавление
- •Воронежский государственный технический университет,
- •394026 Воронеж, Московский просп. 14
Планирование разработки программного обеспечения
Рассмотрим коротко этапы разработки программного обеспечения.
Этап 1. Анализ требований. Программный продукт, в принципе, может разрабатываться для рынка или для конкретного заказчика. В первом случае анализу подлежат потребности рынка, тенденции развития программных и технических средств. Во втором случае необходимо выяснить потребности заказчика, возможности их удовлетворения. Анализ требований выполняется системным аналитиком. Системный аналитик (называемый иногда еще постановщиком задачи) должен, образно говоря, превращать пользовательскую задачу в программистскую задачу. Результатом работы системного аналитика является специфика требований, содержащая:
функциональные требования;
ограничения на среду реализации;
интерфейс пользователя, формы ввода/вывода;
количественные характеристики.
Специфика должна полностью отражать требования заказчика и не быть противоречивой. Естественно, полностью удовлетворить эти требования при разработке сложных программных комплексов невозможно (см. выше).
Этап 2. Проектирование спецификаций. На этом этапе спецификация требований превращается в спецификацию программного обеспечения. Другими словами, на основе спецификации требований определяется структура создаваемого программного обеспечения; для каждого программного модуля определяется его внешняя спецификация.
Результаты работы:
перечень необходимых модулей;
описание передачи данных между модулями;
перечень подпрограмм и функций для каждого модуля;
описание структур данных (вводимых, выводимых, передаваемых между модулями);
описание файлов.
Специфика должна полностью отражать требования заказчика и не быть противоречивой. Естественно, полностью удовлетворить эти требования при разработке сложных программных комплексов невозможно (см. выше).
Кроме этого, могут быть даны описания ключевых алгоритмов. Желательная последовательность действий при проектировании спецификации:
четко выделить функции каждого модуля, исходя из спецификаций требований;
организовать модули в иерархическую структуру;
определить потоки данных меду модулями;
определить структуру файлов;
определить структуры данных, передаваемых между модулями;
спроектировать ключевые алгоритмы;
определить состав подпрограмм в каждом модуле.
Для каждой подпрограммы проектировщик должен определить:
выполняемые функции;
структуры данных (вход, выход, обращение к файлам);
коды возврата, соответствующие успешному или аварийному завершению подпрограммы);
побочные эффекты.
Этап 3. Реализация. При качественном выполнении предыдущих этапов реализацию
можно распараллеливать. Разработчик каждой подпрограммы должен строго следовать заданной спецификации. Для облегчения понимания подпрограмм желательно определить принципы кодирования, например:
в составных именах первые буквы частей писать большими буквами (FilePos);
использовать стандартные префиксы для переменных и функций определенного назначения (IO_String);
имена констант, макросов, глобальных переменных писать большими буквами;
использовать в именах переменных суффиксы, указывающие их тип (NextPTR - указатель).
Этот этап завершается тестированием модулей в отдельности.
Этап 4. Комплексное тестирование и объединение модулей. Проверяется работа программного обеспечения в целом и взаимодействие модулей. При разработке программного продукта (Программный продукт = программа + документация) параллельно разработке должна разрабатываться документация. Поэтому составление документации не рассматривается как отдельный этап. После выполнения перечисленных этапов может начинаться первоначальная эксплуатация программного продукта.
Возникает вопрос, как определить, сколько времени требуется для разработки программного продукта. Допустим, что известен приблизительный объем разрабатываемого продукта в строках исходного текста. Этот объем может быть определен экспертным путем по аналогии с уже существующими разработками. Некоторые подходы к оценке объема нового программного продукта по количеству исходных данных описаны в [4].
Пусть KDL – объем разрабатываемого программного обеспечения в тысячах строк исходного текста.
В первом приближении рекомендуют следующие формулы определения трудоемкости, в человеко – месяцах,
E = 0.8*KDL^(1/3) (1)
E = 1.4*KDL^(1/4) (2)
Результаты вычислений по этим формулам приведены в табл. 1.1.
Таблица 1.1.
-
KDL
E по формулам
1
2
4
1.3
2.0
8
1.6
2.3
50
2.9
3.7
100
3.7
4.4
Более точно трудоемкость и время разработки можно определить по модели СОСОМО (COnctructive COst MOdel) [3]. Рекомендуется формула
E = a*KDL^b,
где a, b – зависят от характеристик проекта;
Для прикладных систем, разрабатываемых в существующих средах небольшими по численности коллективами (системы обработки данных, банковские системы); a=3.2; b=1.05.
Разработка базового программного обеспечения (операционные системы, системы управления базами данных): a=3.0; b=1.12.
Встроенные системы, системы реального времени, компьютерные системы навигации с высокими требованиями к надежности: a=2.8; b=1.20.
Для уточнения трудоемкости может быть дополнительно учтен ряд показателей, объединенных в следующие группы:
Показатели программного продукта:
требуемая надежность программного продукта (RELY);
объем базы данных (DATA);
сложность продукта (CPLX);
Показатели ЭВМ:
наличие ограничений на время выполнения (TIME);
наличие ограничений на объем ОЗУ (STOR);
Показатели разработчиков:
компетентность системного аналитика (ACAD);
опыт разработки прикладных систем (AEXP);
квалификация программистов (PCAD);
опыт работы со средой разработки (LEXP);
Показатели процесса проектирования:
использование современных методов разработки программ (MODP);
использование инструментальных средств разработки программ (TOOL).
Коэффициенты для перечисленных показателей приведены в табл. 1.2., номинальные значения всех коэффициентов равны единице.
Таблица 1.2.
Показатель |
Очень мало |
Мало |
Номинал |
Высоко |
Очень высоко |
Сверхвысоко |
RELY |
0.75 |
0.88 |
1.0 |
1.15 |
1.4 |
|
DATA |
|
0.94 |
1.0 |
1.08 |
1.16 |
|
CPLX |
0.7 |
0.85 |
1.0 |
1.15 |
1.30 |
1.65 |
TIME |
|
|
1.0 |
1.11 |
1.30 |
1.66 |
STOR |
|
|
1.0 |
1.06 |
1.21 |
1.56 |
ACAD |
1.46 |
1.19 |
1.0 |
0.86 |
0.71 |
|
AEXP |
1.29 |
1.13 |
1.0 |
0.91 |
0.82 |
|
PCAD |
1.42 |
1.17 |
1.0 |
0.95 |
|
|
LEXP |
1.14 |
1.07 |
1.0 |
0.95 |
|
|
MODP |
1.24 |
1.10 |
1.0 |
0.91 |
0.82 |
|
TOOL |
1.24 |
1.10 |
1.0 |
0.91 |
0.83 |
|
В зависимости от характеристик разрабатываемого программного продукта выбирается комплект значений всех показателей, их произведение дает уточнение трудоемкости.
Таблица 1.3.
Этап |
|
Объем, % |
|
|
|
Малый 2 KDL |
Промежуточный 8 KDL |
Средний 32 KDL |
Большой 128 KDL |
Проектирование |
16 |
16 |
16 |
16 |
Детальное проектирование |
26 |
25 |
24 |
23 |
Кодирование и тестирование модулей |
42 |
40 |
38 |
36 |
Объединение и комплексное тестирование |
16 |
19 |
22 |
25 |
Объем разрабатываемого ПО оказывает влияние и на относительную трудоемкость этапов разработки, что иллюстрируется табл. 1.3.
Пример. Допустим, что требуется разработать программу автоматизации работы конторы. В результате анализа выявлено, что программное обеспечение может быть реализовано четырьмя модулями. Разработка относится к наименьшему уровню сложности.
Требуемые модули:
- ввод данных 0.6 KDL;
- преобразование данных 0.6 KDL;
- запросы 0.8 KDL;
- генератор отчетов 1.0 KDL;
------------------
Итого 3.0 KDL.
Определим значения уточняющих показателей:
сложность проекта высокая CPLX=1.15;
наличие ограничений на объем ОЗУ высокие STOR=1.06;
опыт разработки прикладных систем мал AEXP=1.13;
квалификация программистов низка PCAD = 1.17;
Остальные показатели имеют номинальные значения (равны единице). Значение поправочного коэффициента
EAF = 1.15*1.06*1.13*1.17 = 1.61 a=3.2; b=1.05
Ei = 3.2*3^1.05 = 10.14 человеко-месяцев
E = EAF*Ei = 1.61*10.14 = 16.3
Распределение трудоемкости по этапам работы.
Проектирование 0.16*16.3 = 2.6 чел.-мес.
Детальное проектирование 0.258*16.3 = 4.2 чел.-мес.
Кодирование и тестирование модулей 0.4166*16.3 = 6.8 чел.-мес.
Объединение и комплексное тестирование 0.165*16.3 = 2.7 чел.-мес.
Примечание. В табл. 1.2. нет данных для объема 3 тысяч строк исходного текста (KDL). Поэтому для определения относительного объема каждого этапа используем линейную интерполяцию и получим значения 0.252; 0.4166 и 0.165.
Следующим шагом планирования является определение длительности разработки при известном объеме работы в человеко-месяцах. Рекомендуются следующие формулы:
Фирма IBM M = 44*E^0.36;
COCOMO M=25*E^0.38.
Таблица 1.4.
Этап |
|
Объем, % |
|
|
|
Малый 2 KDL |
Промежуточный 8 KDL |
Средний 32 KDL |
Большой 128 KDL |
Проектирование |
19 |
19 |
19 |
19 |
Программирование |
63 |
59 |
55 |
51 |
Сборка |
18 |
22 |
26 |
30 |
Распределение времени разработки между этапами дано в табл. 1.4.
Продолжение примера. М = 2.5*E^0.38 = 2.5*16.3^0.38 = 7.23 месяцев. Продолжительность отдельных этапов:
проектирование 0.19*7.23=1.37 месяцев;
программирование 0.623*7.23=4.5 месяцев;
сборка 0.1866*7.23=1.35 месяцев.
Коэффициенты 0.623 и 0.1866 получены через линейную интерполяцию. Используя табл. 1.2 и 1.3 можно определить желательное количество людей для выполнения отдельных этапов разработки:
проектирование 2.6/1.37 = 1.9 человек;
программирование (4.2+6.8)/4.5 = 2.4 человек;
сборка 2.7/1.35 = 2 человек.
Получается следующий примерный календарный план выполнения работ (в табл. 1.5 задано количество занятых людей).
Работа начнется с этапа проектирования, выполняемого системными аналитиками. Этой работой заняты 2 специалиста. Им требуется немногим больше месяца для завершения работы. В начале второго месяца могут быть выданы задания программистам, работающим над модулями ввода и преобразования. Работу над модулями запросов и генератором отчетов можно начинать на завершающей стадии выполнения модулей ввода и преобразования. Объединение и комплексное тестирование начинаются после завершения работ над модулями.
Таблица 1.5.
Выполняемая работа |
|
|
|
Месяцы работы |
|
|
|
|
|||||
Проектирование |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|||||
Программирование модулей |
2 |
2 |
|
|
|
|
|
|
|||||
- ввод |
|
1 |
1 |
1 |
|
|
|
|
|||||
- преобразование |
|
1 |
1 |
1 |
|
|
|
|
|||||
- запросы |
|
|
|
1 |
1 |
1 |
|
|
|||||
- отчеты |
|
|
|
1 |
1.5 |
1 |
|
|
|||||
Сборка |
|
|
|
|
|
|
2 |
2 |
|||||
Итого занятых людей |
2 |
2 |
2 |
2 |
2.5 |
3 |
2 |
1 |