Хотите получать новые статьи блога
прямо себе на почту?
Укажите свой e-mail:


WorldSkills Russia
Яндекс.Метрика Интернет-издание Профобразование

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

0

План:

  1. Общие принципы разработки ПО
  2. Общесистемные принципы
  3. Жизненный цикл программного обеспечения
  4. Составление требований к программному продукту и разработка технического задания на программный продукт
    • Преимущества, получаемые в результате составления ТЗ
    • Структура технического задания
    • Этапы подготовки технического задания

1. Общие принципы разработки ПО

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

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

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

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

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

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

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

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

2. Общесистемные принципы

При создании и развитии ПО рекомендуется применять следующие общесистемные принципы:

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

3. Жизненный цикл программного обеспечения

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

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

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

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

Значение спецификаций:

  1. Спецификации являются заданием на разработку ПО и их выполнение – закон для разработчика.
  2. Спецификации используются для проверки готовности ПО.
  3. Спецификации являются неотъемлемой частью программной документации, облегчают сопровождение и модификацию ПО.

Второй стадией является проектирование ПО. На этом этапе:

  1. Формируется структура ПО и разрабатываются алгоритмы, задаваемые спецификациями.
  2. Устанавливается состав модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов.
  3. Выбирается структура информационных массивов.
  4. Фиксируются межмодульные интерфейсы.

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

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

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

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

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

Распределение времени и стоимости затрат по отдельным стадиям жизненного цикла программного обеспечения представлено в таблицах 1 и 2.

Таблица 1. Затраты по стадиям жизненного цикла ПО
(Сведения из разных источников)

Стадии жизненного цикла программного обеспечения Гласс Р.
Нуазо Р.
Энкарначчо Ж. Боэм Б. Федорчук-
Черненький
Вишняков Среднее
Определение требований и спецификаций 10 15 6 6 6 8,6
Проектирование 10 12 18 5 6 10,2
Программирование 10 12 9 7 6 8,8
Отладка 20 15 17 15 14 16,2
Сопровождение 50 50 50 67 68 56,2
Всего 100 100 100 100 100 100

Таблица 2. Основные параметры стадий жизненного цикла ПО

Стадии жизненного цикла программного обеспечения Количество ошибок, % Обнаружение ошибок, % Затраты на устранение ошибок, %
Определение требований и спецификаций 9
Проектирование 61-64 6
Программирование 36-39 10
Отладка 10 12
Сопровождение 54 63

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

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

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

Как видно, область инженерного программирования, к счастью (или к несчастью), не столь проста.

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

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

При разработке современного коммерческого прикладного программного продукта есть два основных момента, которые требуют обязательного документального подтверждения: договорные отношения (контракт) и требования к конечному результату – техническое задание (ТЗ). Основная цель написания ТЗ – устранение двусмысленностей о том, что именно будет являться конечным продуктом. Юридически техническое задание оформляется как приложение к договору оказания услуг по разработке и подписывается обеими сторонами. Техническое задание – исходный документ для разработки программного продукта, содержащий основные технические требования, предъявляемые к продукту и исходные данные для разработки. В ТЗ указываются назначение продукта, область его применения, целевая аудитория, стадии разработки проектной и программной документации, её состав, сроки исполнения и т.д., а также особые требования, обусловленные спецификой программного продукта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчетов и моделирования. Вызвано это тем, что крупные проекты требуют серьезного проектного исследования. Обычно на эти исследования выделяется отдельный бюджет и порой не меньший, чем на непосредственную разработку проекта. Связано это с тем, что точную оценку стоимости крупного проекта можно дать только после точного его описания (которое и составляет ТЗ), а заказчик может отказаться от дальнейшего сотрудничества, хотя разработчик уже понес существенные трудозатраты. Не всякий заказчик готов к такой постановке вопроса. Как правило заказчик не является профессионалом в области высоких технологий, и задача им ставится на общем уровне: «мы бы хотели увидеть вот это, может это, а может еще и это». При этом зачастую представители заказчика вообще не придают особого значения составлению технического задания на разработку проекта. Казалось бы, все уже ясно, видение проекта есть, осталось просто оформить его в рабочую модель. Зачем разводить лишнюю бумажную волокиту?

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

а) Преимущества, получаемые в результате составления ТЗ

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

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

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

б) Структура технического задания

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

В Российской Федерации действует ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», который рекомендует такую структуру ТЗ:

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

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

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

Таблица 3. Основные этапы подготовки технического задания

Наименование этапа Содержание работ
1 Описание предметной области
  • краткое введение в предметную область
  • выделить элементы предметной области, их взаимосвязи
  • определить особенности и ограничения предметной области
  • используемые термины и сокращения
2 Цель создания системы
  • сформулировать цель создания системы – как ответ на вопрос что за процесс в предметной области будет автоматизирован
  • назначение системы, существующие аналоги
  • целевая аудитория, ожидаемый уровень использования
3 Детализация функций системы
  • изучение потребностей заказчика
  • подготовить описание функции системы
4 Анализ категорий пользователей
  • выделение категорий пользователей
  • определение функциональных требований пользователей каждой категории
5 Определение ограничений
  • анализ аппаратных особенностей и ограничений
  • анализ топологии и особенностей развертывания
  • определение технологических ограничений
6 Формирование и утверждение совокупного списка требований к системе
  • если система предполагает интерактивность в общении с пользователем, то определить функциональные требования (описывают в динамике сценарии взаимодействия посетителя с системой) и структуру данных
  • выделить специфические требования (например, многоязычность, требования к дизайну экранов монитора)
  • прочие требования (например, какая документация должна быть предоставлена разработчиком)
  • сформировать список требований
7 Выработка архитектурного решения
  • выбор технологической платформы
  • если система должна реализовывать специфическую бизнес-логику, в которой обычно хорошо разбирается заказчик и плохо – исполнитель, эта логика должна быть задокументирована в техническом задании максимально подробно
  • подготовка модульной структуры системы
  • подготовка детализированного описания подсистем
8 Подготовка календарного плана
  • оценка сложности реализации подсистем
  • выделение работ, построение сетевого графика
  • оценка сроков выполнения работ
9 Завершающий этап
  • согласование процесса приемки работ
  • компоновка из полученных материалов текста технического задания

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

  1. Охарактеризуйте общие принципы разработки ПО.
  2. В чем заключаются общесистемные принципы разработки?
  3. Охарактеризуйте стадии жизненного цикла ПО.
  4. Какие стадии жизненного цикла требуют наибольших затрат и почему?
  5. На каких стадиях жизненного цикла затраты на устранение ошибок максимальны и почему?
  6. Что представляет собой техническое задание? Дайте определение понятию.
  7. Какова основная цель написания ТЗ?
  8. Как юридически оформляется ТЗ?
  9. Какой документ регламентирует правильность составления ТЗ?
  10. Назовите основные разделы технического задания.
  11. Назовите основные этапы разработки ТЗ и работы выполняемые на каждом из этапов.

Возникли вопросы?
Тогда смело пишите комментарий — рада буду ответить!
Агрегирование и групповые функции