Этапы разработки программного продукта

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

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

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

 

2.1.3. Модифицированный  нисходящий метод

 

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

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

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

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

 

 

2.1.4. Метод большого скачка.

 

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

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

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

 

 

 

 

 

2.1.5. Бета - тестирование  программного обеспечения.

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

 

Качественный  и эффективный результат можно гарантировать лишь только при ответственном и детальном исполнение каждого из приведенных этапов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. Немного из  теории справочных систем

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

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

Иметь графические  материалы по вопросам использования  программы.

Быть доступной  для вызова из любой формы программы.

Иметь контекстные  описания и удобную систему поиска информации.

Иметь минимально возможный размер.

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

 

 

 

 

Тестирование  и принятие в эксплуатацию

 

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

 

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

 

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

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

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

 

Требования  к документации

 

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

 

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

 

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

 

Внедрение и  сопровождение разработанной программной  системы

 

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

 

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

 

Замена версий и управление конфигурацией

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

 

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

 

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

 

Процедуры запросов на замену версий

 

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

 

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