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

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

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

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

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

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

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

Управление конфигурацией  и настройки защиты 

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

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

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

Управление конфигурацией  и обновление 

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

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

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

Тестирование  перед инсталляцией 

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

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

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

Создание документации пользователя

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

Документирование  — это важная часть в разработке программного обеспечения, но часто  ей уделяется недостаточно внимания.

Типы документации

Существует четыре основных типа документации на ПО:

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

техническая —  документация на код, алгоритмы, интерфейсы, API

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

маркетинговая

Архитектурная/проектная  документация 

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

Техническая документация 

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

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

Часто при составлении  технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. 

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

Пользовательская  документация 

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

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

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

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

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

Маркетинговая документация 

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

подогреть интерес  к продукту у потенциальных пользователей

информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали  с тем что они получат

объяснить положение  продукта по сравнению с конкурирующими решениями 

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

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

Метрика программного обеспечения (англ. software metric) — это  мера, позволяющая получить численное  значение некоторого свойства программного обеспечения или его спецификаций.

Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики  и практики информатики пытались перенести данный подход и в разработку программного обеспечения. Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».

Обобщённое программирование ( Шаблоны ) — парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно  применять к различным типам  данных, не меняя само это описание. В том или ином виде поддерживается разными языками программирования. Возможности обобщённого программирования впервые появились в 70-х годах  в языках CLU и Ada, а затем во многих объектно-ориентированных языках, таких как C++, Java, Object Pascal[1], D и языках для платформы .NET. 

Общий механизм 

Средства обобщённого  программирования реализуются в  языках программирования в виде тех  или иных синтаксических средств, дающих возможность описывать данные (типы данных) и алгоритмы (процедуры, функции, методы), параметризуемые типами данных. У функции или типа данных явно описываются формальные параметры-типы. Это описание является обобщённым и  в исходном виде непосредственно  использовано быть не может.