Структурное программирование

Общая информация о разработке ПО

Свою историю процесс разработки программного обеспечения берет непосредственно от теории качества управления, появившейся в послевоенных США и Японии. Одними из известнейших основоположников теории качества являются:

• Э. Деминг — американский учёный, статистик и консультант по менеджменту. Больше всего известен благодаря усовершенствованному циклу Шухарта, после этого названному циклом Деминга;
• Дж. Джуран — американский специалист в области качества, академик Международной академии качества (МАК). Автор множества книг по менеджменту и теории качества. Дж. Джуран первым обосновал переход от контроля качества к управлению качеством;
• Ф. Кросби — бизнесмен и автор нескольких книг по теории качества, который внес вклад в теорию менеджмента и практики менеджмента качества. В 1979 году Кросби основал консалтинговую компанию по управлению финансами Philip Crosby Associates, Inc.

Благодаря этим известным личностям, были разработаны методы построения качества и менеджмента на производствах. С течением времени теория качества вышла за пределы производств, повлияв на многие сферы. Одной из них является разработка программного обеспечения.

К ключевым процессам разработки ПО относятся:

1. Анализ — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей и документирование;
2. Проектирование — процесс создания проекта программного обеспечения (ПО);
3. Программирование — процесс создания компьютерных программ;
4. Документирование — печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом;
5. Тестирование —- процесс исследования, испытания программного продукта, цель которого  —  проверка соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.

К основным типам рисков разработки ПО относятся:

1. Непродуманные сроки и нереалистичный бюджет;
2. Отсутствие квалифицированных разработчиков;
3. «Плавающие» требования;
4. Трата большого количества ресурсов на оптимизацию;
5. Слабая производительность системы;
6. Разная классификация специалистов из разных отделов.

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

Структурная схема организации ПО процедуры управления потоками сети Х.25

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

На рис. 1 приведена упрощенная структурная схема организации этого программного обеспечения.

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

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

Рис. 1. Структурная схема организации программного обеспечения безошибочного обмена информационными кадрами на канальном уровне сети Х.25

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

Фоновые программы, которые не выполняют функцию управления потоком, на рисунке изображены в виде одного квадрата. К ним относятся функции установления и разъединения соединения, функции взаимодействия с сетевым уровнем сети Х.25 и другие функции.

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

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

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

Это объясняется тем, что для обеспечения качества передачи данных важно не потерять пакет данных, а для качества передачи речи и видео важна величина задержки приема пакета при передаче.

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

О_п32 – очередь пакетов на передачу с сетевого уровня на канальный уровень;

О_повт – очередь «I» (информационных) кадров на случай необходимости повторной передачи кадров в канал;

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

О_п23 – очередь пакетов, подлежащих передаче с канального уровня на сетевой уровень.

Приведем упрощенные структурные схемы основных фоновых программ передачи (P1_ПД, P2_ПД, P3_ПД, P4_ПД, P5_ПД, P6_ПД, P7_ПД), приема (P1_ПМ, P2_ПМ, P3_ПМ, P4_ПМ) с кратким описанием их функционирования. Напомним, что фоновые программы запускаются диспетчером программ ДП. По завершению работы фоновая программа возвращает управление ДП.

Этапы создания программных продуктов

Приведём все основные этапы создания программного продукта. Всего их пять. Они так или иначе характерны для любой методологии разработки ПО: будь то классическая водопадная, либо современные гибкие методологии (Agile software development) – во всех из них разработчики проходят через следующие этапы создания программного обеспечения:

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

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

Проектирование программного продукта

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

Разработка. Когда требования сформулированы и архитектура готова – команда начинает разработку ПП. На этапе разработки также выполняется документирование системы.

Тестирование. После разработки необходимо произвести тестирование системы в целом, тем самым подтвердить её соответствие требованиям заказчика.
Здесь стоит сказать, что модульные тесты (unit-тесты; т.е. тесты отдельных частей программы) обычно выполняются на этапе разработки программистом, разрабатывавшем конкретный модуль.
Когда все тесты пройдены, программное обеспечение готово к выпуску.

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

Примечание 1: Следует как можно тщательнее подходить к формированию предварительных требований и проектированию, поскольку стоимость исправления ошибок после выпуска ПО, допущенных на этих этапах, обычно в 2-10 (!) раз выше, чем стоимость исправления ошибок сделанных на этапе программирования (Стив Макконнелл “Совершенный код”).

Примечание 2: Очень часто случается, что заказчик уже после составления требований к ПО (т.е. во время проектирования и разработки) объявляется и радостно сообщает исполнителю свои новые идеи или рассказывает о какой-нибудь “классной” функции, которую нужно добавить в приложение… Бывают случаи, когда это труднореализуемо и сопряжено с пересмотром архитектуры. В данной ситуации можно посоветовать сказать разработчику примерно следующее: “Отлично придумано! Мне нравится! Тогда я пересмотрю свою смету и сроки работы и потом сообщу Вам!”. Практически всегда это срабатывает и гасит пыл заказчика, и он отказывается от новых идей и изменений в проекте.

Похожие:

Документы