Выбор методов и средств разработки; концепции и реализации программных процессов

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

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

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

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

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

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

— требования к передаче технических и программных средств, данных и знаний (опыта) от разработчика к сопроводителю;

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

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

— определить проблемную область (тип программного продукта);

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

Разработка программного кода модуля

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

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

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

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

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

Тема 4. Тестирование и отладка модулей ПО

Не нашли, что искали? Воспользуйтесь поиском по сайту: