Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007), страница 4

Теперьфункционируют уже три версии системы (рис. 2.7).A’’BCA’’’BCABCIIIIIIРис. 2.7 — Система после исправления двух ошибокВо многих случаях большая часть усилий разработчиков затрачивается на повторное обнаружение ошибок, выявленных ранее в других версиях. Чтобы исключить лавинообразное нарастание версий, системы обычно корректируются в определенныепромежутки времени, называемые периодами обновления.Многочисленные проблемы, возникающие на этапе сопровождения системы, должны решаться с привлечением концепции «базы данных системы».

Формирование такой концепции начинается на этапе определения спецификаций. Эта базаданных должна учитывать требования различных заказчиков ивключать средства индикации, тестирования и устранения ошибок, применяемые для корректировки систем.Контрольные вопросы1.2.3.4.5.6.7.8.9.Этапы разработки программного обеспечения.Анализ требований, предъявляемых к системе.Жизненный цикл программного обеспечения.Функциональные спецификации. Определение спецификаций.Проектирование.

Кодирование.Тестирование: программное, системное, оценочное исравнительное.Сбой системы, выброс, ошибка. Испытания. Верификация системы.Правильность и надежность программ.Эксплуатация и сопровождение. Периоды обновления.213 МЕТОДЫ РАЗРАБОТКИ ПРОГРАММНОГООБЕСПЕЧЕНИЯ КАК НАУЧНАЯ ДИСЦИПЛИНАИз приведенного нами обзора этапов разработки программного обеспечения ясно, что каждый этап разработки оказывает влияние на другие более ранние этапы (технология«синтез — анализ»). Так, процесс написания спецификаций оказывает влияние на анализ исходных требований. На этапепроектирования вскрываются ошибки, допущенные в процессенаписания спецификаций. На этапах кодирования, тестированияи эксплуатации выявляются проблемы, решить которые можнолишь на этапе проектирования.

В связи со всем вышесказанным, основные цели научной дисциплины «методы разработкипрограммного обеспечения» можно сформулировать следующим образом:1) разработка методов управления сложными системами;2) повышение надежности и правильности программногообеспечения;3) развитие методов более точного прогнозирования затрат на создание программного обеспечения.Совокупность этих проблем разделяется на методы управления разработкой и методы ведения разработки.Методы управления разработкой имеют отношение к эффективной организации работы исполнителей.Методы проведения разработки охватывают техническиеприемы работы программистов, способствующие повышениюпроизводительности их труда.3.1 Методы управления разработкойРуководитель проекта контролирует два основных ресурса — исполнителей и вычислительные средства.

Следовательно,его основная цель — оптимизировать эти ресурсы. Успех разработки в сильной степени зависит от того, насколько руководитель следит за ходом разработки. Задержка проекта на год складывается из множества однодневных задержек.Обычно наибольшие трудности возникают при построении интерфейса между модулями, написанными различнымипрограммистами. Поскольку количество таких интерфейсов при22N исполнителях соответствует N(N–1)/2 и возрастает пропорционально квадрату числа исполнителей, проблема становится довольно сложной при разработке проекта группой из 4-х и болеечеловек.Пример. Программист может написать в течение годапрограмму, включающую 5000 строк, а проектируемая системадолжна содержать 50000 строк, и ее разработка должна быть завершена в течение двух лет.

Очевидно, что для создания такойсистемы достаточно пяти программистов. Однако эти пять программистов должны взаимодействовать друг с другом, а этотребует времени и в определенной степени снижает производительность труда, поскольку взаимное непонимание приводит кдополнительным затратам на тестирование (рис. 3.1).Рис. 3.1 — Для группы из 5 человек имеем 10 взаимосвязейПусть каждый из путей взаимодействия обходится программисту в 250 строк/год. В этом случае каждый программистможет составить лишь 4000 строк/год, а в течение двух лет будет составлено лишь 40000 строк. Это означает, что для написания программы из 50000 строк нужны 8 программистов, каждый из которых пишет 3250 строк/год (рис.

3.2). Для управления их работой нужен руководитель.23Рис. 3.2 — 8 исполнителей — 28 связейОднако простой подсчет строк кода не является достоверной оценкой эффективности труда программиста. Учет всехфакторов, влияющих на производительность программистов,крайне сложен. Следовательно, необходимо использовать методы и приемы ограничения «коммуникационного взрыва» и увеличения производительности труда программистов.3.1.1 Выполнение проектаПрограммное обеспечение обычно разбивают на три категории: управляющие программы (например, операционныесистемы — ОС); системные программы (например, компиляторы); прикладные программы (обработка данных, счетнаяпрограмма и др.).Статистика показывает, что программист в течение годаспособен написать и отладить управляющую программу длинойпримерно 600 строк, системную программу длиной 2000 строки прикладную длиной 6000 строк.Естественно, что к этим цифрам нужно относиться оченьосторожно, т.к.

неясно, что понимать под строкой кода. Включаются ли сюда комментарии и объявления данных? Или это генерируемая транслятором машинная команда? Как учесть программы, хранящиеся в библиотеке? Следует ли исходить из24строк или операторов начального текста? В зависимости от ответов на эти вопросы количество строк кода может меняться в2–4 раза.Эффективность действия отдельного программиста в значительной мере зависит от типа задачи. Организация работыпрограммиста также влияет на результаты труда.

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

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

При создании бригады исходят из того,что программисты имеют различные уровни квалификации. Организация бригады главного программиста является одним изпутей уменьшения количества коммуникаций (рис. 3.3).25Рис. 3.3 — Снижение количества взаимосвязей при использованиибригады главного программиста3.1.2 Методика оценки затратОдним из важнейших аспектов процесса разработки программного обеспечения является оценка необходимых ресурсовили требуемых затрат.3.1.2.1 Методика инженерно-технической оценки затратБазовая методика оценки затрат заключается в следующем:Шаг 1. Формируются общие требования к системе исходяиз существующего технического задания.

Потенциальных разработчиков информируют о том, что ожидают от системы. Этотдокумент именуют «списком пожеланий». Для более точногоопределения требуемых ресурсов проводится анализ требований.Шаг 2. Собирается аналогичная информация, напримерданные о подобных системах.Шаг 3. Отбираются основные релевантные данные.Шаг 4. Проводится предварительная оценка.Шаг 5. Проводится окончательная оценка системы.Основной этап этой работы — шаг 4. При его выполнении проводятся следующие действия.Шаг 4а. Сравнение проектируемой системы с подобнымиуже разработанными системами.Шаг 4б. Разбиение системы на части и сравнение каждойиз этих частей с подобными ей частями других систем.Шаг 4в.

Планирование работ и оценка затрат на каждыймесяц.26Шаг 4г. Разработка соглашений, которые могут быть использованы при работе.Отметим, что реализация шага 4а при отсутствии достаточного опыта может занять довольно продолжительный период времени. Шаг 4б требует тщательного определения понятия«часть системы». Не отличается строгим регламентом и шаг 4г,так как нет адекватного набора стандартных соглашений.Поэтому в реальной практике используются различные модификации рекомендуемого метода, базирующиеся либо на болееформализованных понятиях, либо на субъективных оценках.Метод экспертных оценок.

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