6.2. Требования к программному изделию

Вторая фаза ЖЦПИ — фаза определения требований к про­граммному изделию, которая является фазой "анализа проблемы". Главной целью этой фазы выступает разработка полной, непроти­воречивой и корректной совокупности требований к программному обеспечению на основе всестороннего изучения требований пользо­вателя. За выработку требований отвечает разработчик. В качестве участников этой фазы должны привлекаться пользователи, инжене­ры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение работы, как правило, назначается системный аналитик. Руководитель про­екта организует взаимные консультации и обсуждения, поскольку участники обсуждений могут иметь разное представление о конеч­ном продукте, и их взгляды должны синтезироваться в четкие и не­противоречивые формулировки требований.

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

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

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

6.3. Разработка логической модели программного изделия

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

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

Логическая модель должна удовлетворять следующим прави­лам:

1. Каждая функция в модели отражает единственную и четко определенную цель. Имена функций определяют, что должно быть сделано, а не как сделано.

2. Функции соответствуют уровню иерархии, на котором они представлены в модели.

3. Связи между функциями (функциональными блоками модели) минимизируют.

4. Каждая функция может разделяться не более чем на 7 под­функций следующего уровня.

5. В модели не должна присутствовать информация, связанная с последующей реализацией изделия, например, такие понятия, как модуль, файл, запись и т.п.

6. Для каждой функции приводятся входные данные.

7. Каждой функции соответствует список выходных данных (вы­ходных отчетов).