Программное обеспечение

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

Модель  программного процесса

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

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

     В соответствии с двумя типами процессов  – основных и дополнительных –  можно говорить о двух типах моделей процесса: модели процесса разработки (модели жизненного цикла) и модели организации работ по выполнению разработки.

     К первым типам моделей (модели жизненного цикла) относятся модели, в которых  описывается порядок выполнения действий по созданию продукта. К наиболее известным моделям относятся:

• Водопадная (каскадная) модель – процесс разбивается но последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям.
• Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований.
• Компонентная модель предполагает сборку продукта из заранее написанных частей – компонент. Основной упор делается на интеграцию и совместное тестирование компонент.
• Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям.

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

     Ко  второму типу моделей – моделей организации работ относятся:

• Модель потока работ (workflow model) — показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам.
• Модель потоков данных (data flow model) — представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями.
• Ролевая модель — показывает роли людей, участвующих в программном процессе, а также действия и результаты, за которые они отвечают.

Методы  программной инженерии

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

     Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:

• Метод структурного анализа и проектирования Том ДеМарко (1978);
• Метод сущность-связь проектирования информационных систем Чен (1976);
• Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991).

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

     Методы  должны включать в себя следующие  компоненты:

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

Что такое CASE

     CASE - Computer Aided System Engineering - различного рода инструментальные программы, используемые для поддержки процесса создания программ CASE средства могут быть классифицированы по нескольким признакам:

     • По уровню применения:

     - Upper CASE -средства анализа требований

     - Middle CASE - средства проектирования

     - Low CASE - cсредства разработки приложений

     • Специализированные

     - Средства проектирования баз  данных

     - Средства реинжиниринга (восстановления) модели (формирование ERD на основе  анализа схем БД или формирования  диаграмм на основе анализа программных кодов)

     • Вспомогательные

     - Планирования и управления проектом

     - Конфигурационного управления

     - Тестирования

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

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

     Computer Aided System Engineering - использование компьютеров для поддержки процесса создания программ.

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

 

 
Свойства  хорошей программы

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

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

     • Надежность (dependability). Надежность ПО включает такие элементы как:

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

       Безопасность – сбои в работе  программы не должны приводить  к опасным последствиям (авариям);

       Защищенность от случайных или преднамеренных внешних воздействий (защита от «дурака», вирусов, спама).

     • Эффективность (efficiency). ПО не должно впустую  тратить системные ресурсы, такие  как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т.п.

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

     Следует отметить, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных усилий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя.

 

 
Основные  трудности

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

     • Наследование ранее созданного ПО (legacy systems). Существует достаточно много  систем, созданных много лет назад, морально устаревших, но продолжающих работать. Проблема наследования таких систем состоит в их сопровождении – поддержке и развитии.

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

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

Профессиональные  и этические требования

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

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

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

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

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