Род деятельности программирования

1. Введение

Род деятельности программирования?

В 60-х – 70-х годах XX века данный вопрос активно обсуждался на научных конференциях. Существовало две популярных точки зрения:

Программирование это искусство,

Программирование это наука.

Дело в том, что разработка программного обеспечения (ПО) имеет ряд специфических особенностей [1].

§ Неформальный характер требований к ПО (постановка задачи), но формализованный объект разработки (программы). Тем самым, разработка ПО содержит определенные этапы формализации, а переход от неформального к формальному - неформален.

§ Разработка ПО носит творческий характер. Тем самым, эта разработка ближе к процессу проектирования сложных устройств, но не к их массовому производству.

В настоящий момент можно добавить к этим трактовкам еще одну:

Программирование это бизнес.

Рис 1.1. Динамика объёмов мировых IT - рынков

В IT-индустрии Россиии в 2006 году было занято 260 тыс. человек, а в организациях, использующих IT-технологии, трудилось 600 тыс. Общая потребность российской экономики в новых IT-кадрах в 2007 году составила 190 тыс. человек.

Ежегодно только специалистов по обслуживанию и внедрению системы «1С: Предприятие» требуется более 30 тыс. человек. В том же 2006 году российские вузы выпустили 25 тыс. IT-специалистов и 23 тыс. бакалавров.

По подсчетам компании Microsoft количество профессиональных разработчиков ПО в России на начало 2010 г. составило около 350 тыс. Эти данные получены на основе числа проданных лицензий на средства разработки.

По прогнозам к 2012 году ежегодная потребность российской экономики в новых IT-кадрах составит от 230 до 550 тыс. человек.

Условия успешности бизнеса

Продукт должен выходить на рынок

Интересным потенциальным пользователям, надлежащего качества,

Вовремя,

Расходы должны соответствовать изначальному бюджету.

Чтобы удовлетворить этим требованиям, программирование обрастает дополнительными видами деятельности:

Разработкой требований,

Планированием,

Тестированием,

Конфигурационным управлением,

Проектным менеджментом,

Созданием различной документации.

Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения… Технология = набор правил + методик + инструментов + процессы планирования,… Технология программирования (ТП) - технология разработки программного средства (ПС), включающая все процессы, начиная…

Международным комитетом при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE было создано ядро знаний SWEBOK (Software Engineering Body of Knowledge) (2001, 2003 гг.).

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

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

Кроме программистов, занимающихся непосредственно разработкой ПС, в программной инженерии задействованы:

Менеджеры, которые планируют и руководят проектом, отслеживают сроки его исполнения и затраты;

Инженеры службы ведения библиотек и репозитариев компонентов;

Технологи, которые определяют инженерные методы и стандарты, создают для проекта модель жизненного цикла ПС, удовлетворяющую его целям и задачам;

Тестировщики, которые проверяют правильность выполнения процесса разработки ПС путем тестирования, и на основе собранных данных проводят измерения характеристик качества;

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

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

Информатизация общества и технология программирования

Технология программирования играла разные роли на разных этапах развития программирования [1]. По мере повышения мощности компьютеров и развития средств программирования росла и сложность решаемых на компьютерах задач, что привело к повышенному вниманию к ТП.

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

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

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

Джон (Янош) Фон Нейман (28 декабря 1903 — 8 февраля 1957) Внес большой вклад в создание первых ЭВМ и разработку методов их применения. Широко известны «принципы фон Неймана», определяющие архитектуру современных компьютеров: принцип двоичного кодирования, принцип программного управления, принцип адресации памяти и т.д.

В шестидесятые годы происходило бурное развитие и широкое использование языков программирования высокого уровня (АЛГОЛ 60, ФОРТРАН, КОБОЛ и др.).

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

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

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

Джон Бэкус (1924 - 2007) Один из авторов языков программирования Фортран и Алгол. В 1950 году Бэкус начал работать программистом в фирме IBM. В 1953 году он предложил создать для компьютера IBM-704 язык, позволяющий записывать команды почти в обычной алгебраической форме, и компилятор для него. Большую популярность получила версия под названием “Фортран IV”, выпущенная в 1962 году. Лауреат премии Тьюринга 1977 года.

Эти события произошли в 1968 году: компьютерный дизайн интерфейса пользователя, «мышь», электронная почта, режим видеоконференции, гиперссылки, сеть ARPAnet, которая впоследствии превратилась в Интернет.

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

Обоснование и широкое внедрение нисходящей разработки и структурного программирования;

Развитие абстрактных типов данных и модульного программирования;

§ исследование проблем обеспечения надёжности и мобильности ПС;

Создание методики управления коллективной разработкой ПС;

Появление инструментальных программных средств (программных инструментов) поддержки технологии программирования.

Эдсгер Вайб Дейкстра (1930 - 2002) Автор работ в области применения математической логики при разработке компьютерных программ. Активно участвовал в разработке языка программирования Алгол. Написал первый компилятор Алгол-60. Один из авторов концепции структурного программирования. Выдвинул идею применения «семафоров» для синхронизации процессов в многозадачных системах, автор алгоритма нахождения кратчайшего пути на ориентированном графе с неотрицательными весами рёбер. Лауреат премии Тьюринга 1972 года.

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

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

Деннис Ритчи (родился 9 сентября 1941 года)   Специалист по системному программированию, автор и один из разработчиков языка С (Си), одного из самых универсальных языков программирования. На нем была написана почти вся операционная система UNIX, в разработке которой активно участвовал Ритчи. Лауреат премии Тьюринга 1983 года.

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

Вопросы:

1. Какими условиями определяется успешность бизнеса?

2. Дайте определение понятия технология.

3. Дайте определение понятия технология программирования.

4. Дайте определение понятия программная инженерия.

5. Что входит в ядро знаний SWEBOK?

6. Какие специалисты заняты в программной инженерии?

7. Охарактеризуйте ТП 50-х годов ХХ века.

8. Охарактеризуйте ТП 60-х годов ХХ века.

9. Охарактеризуйте ТП 70-х годов ХХ века.

10. Охарактеризуйте ТП 80-х годов ХХ века.

11. Охарактеризуйте ТП 90-х годов ХХ века.

12. Охарактеризуйте ТП ХХI века.

2. Процессы жизненного цикла программных средств

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

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

Под жизненным циклом программного средства (ЖЦПС) понимают весь период его разработки и эксплуатации, начиная от момента возникновения замысла ПС и кончая прекращением его использования. В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС [1, 7, 8, 10].

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

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

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

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

· Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется компьютерная технология (CASE-технология) разработки ПС.

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

Водопадный подход разработки ПС. Каскадная модель ЖЦ ПС

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

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

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

 

 

Рис. 2.1. Каскадная модель ЖЦ

Исследовательское программирование. Инкрементная модель ЖЦ ПС

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

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

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

Данную модель ЖЦ целесообразно использовать, в случаях когда:

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

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

Рис. 2.2. Инкрементная модель ЖЦ Прототипирование

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

Кроме этого, стандарт ISO/IEC 12207 предоставляет основу для принятия ряда других связанных с ним стандартов, таких как стандарты по управлению ПС, обеспечению качества, верификации и валидации, управления конфигурацией, метриками ПС и т.д.

Структура стандарта ГОСТ ISO/IEC 12207

Первый раздел описывает область применения данного стандарта.

1. Назначение. Устанавливает общую структуру процессов ЖЦ ПС, на которую можно ориентироваться в программной индустрии. Определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов.

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

3. Адаптация. Определяет набор процессов, работ и задач, предназначенных для адаптации к условиям конкретных программных проектов. Процесс адаптации заключается в исключении неприменяемых в условиях конкретного проекта процессов, работ и задач.

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

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

Второй раздел описывает стандарты, на которые есть ссылки.

ГОСТ Р ИСО 9001-96 Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

ИСО/МЭК 2382-1-93 Информационная технология. Словарь. Часть 1. Основополагающие термины

ИСО/МЭК 2382-20-90 Информационная технология. Словарь. Часть 20. Разработка систем

ИСО 8402-94 Управление качеством и обеспечение качества. Словарь

Третий раздел расшифровывает основные определения, которые используются в тексте стандарта.

Четвертый раздел описывает прикладную область применения данного стандарта. Этот раздел описывает структуру стандарта для удобства его использования.

Пятый раздел описывает основные процессы жизненного цикла ПС:

1. заказа;

2. поставки;

3. разработки;

4. эксплуатации;

5. сопровождения.

Шестой раздел описывает вспомогательные процессы:

1. документирования;

2. управления конфигурацией;

3. обеспечения качества;

4. верификации;

5. аттестации (валидация);

6. совместного анализа;

7. аудита;

8. решения проблем.

Седьмой раздел описывает организационные процессы:

1. управления;

2. создания инфраструктуры;

3. усовершенствования;

4. обучения.

В России и СНГ продолжают использоваться ГОСТы СССР, хотя они утратили обязательный характер и применяются добровольно.
ГОСТ 19.102 ЕСПД «Стадии разработки» устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем (Приложение 1).

Вопросы

1. Что такое жизненный цикл ПС?

2. Основное назначение моделей ЖЦ ПС?

3. Перечислите основные процессы ЖЦ ПС.

4. Назовите вспомогательные процессы ЖЦ ПС.

5. Опишите структуру стандарта ГОСТ ISO/IEC 12207.

6. Перечислите основные подходы организации процессов создания ПС и назовите основные виды моделей ЖЦ ПС.

7. Опишите суть водопадного подхода разработки ПС.

8. Опишите суть исследовательского программирования.

9. Опишите суть прототипирования при разработке ПС.

10. Опишите основные черты подходов формальных преобразований и сборочного программирования при разработке ПС.

11. Какие общие черты имеют инкрементная и эволюционная модели?

12. Как построить новую модель ЖЦ на основе стандарта ISO/IEC 12207?

3. Внешнее описание программного средства

Назначение внешнего описания

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

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

1. конструирования и кодирования программ, входящих в ПС;

2. разработки документации по применению ПС;

3. разработки комплекта тестов для тестирования ПС.

Определение требований к программному средству

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

Разработчик должен выполнить анализ области применения разрабатываемой системы с точки зрения определения требований к ней. Технические требования к системе должны охватывать [12]: функции и возможности системы; коммерческие и организационные требования; требования пользователя; требования безопасности и защиты; эргономические требования; требования к интерфейсам; эксплуатационные требования; требования к сопровождению; проектные ограничения и квалификационные требования.

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

Виды и свойства требований

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

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

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

Требования к ПС состоят из требований пользователей, системных, к атрибутам качества, функциональных и нефункциональных требований [2, 8].

Требования пользователей опираются на цели и задачи, которые позволит решать будущая система. К способам представления этого вида требований относятся варианты использования, сценарии, прецеденты, таблицы «событие-отклик» и т.п.

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

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

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

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

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

Требования должны обладать следующими важными свойствами [2, 8].

§ Ясность, недвусмысленность - однозначность понимания требований заказчиком и разработчиками.

§ Полнота и непротиворечивость.

§ Необходимый уровень детализации. Это могут быть описание свойств предметной области или техническое задание.

§ Прослеживаемость. Важно видеть то или иное требование в различных моделях, документах, в коде системы.

§ Тестируемость и проверяемость.

§ Модифицируемость. Определяет процедуры внесения изменений в требования.

Цикл работы с требованиями

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

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

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

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

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

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

Варианты формализации требований

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

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

Неформальная постановка требований в переписке по электронной почте. Хорошо работает в небольших проектах, при вовлеченности заказчика в разработку.

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

Требования в виде графа в одном из средств поддержки требований
(IBM Rational RequisitePro, DOORS, Borland CaliberRM и др.). Такое представление требований удобно при их частом изменении, при отслеживании выполнения, при «привязке» к задачам, людям, тестам, кодам.

Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

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

Известны три способа разработки требований к ПС [1]:

1. управляемая пользователем разработка;

2. контролируемая пользователем разработка;

3. независимая от пользователя разработка.

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

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

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

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

Структура внешнего описания

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

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

Спецификация качества программного средства

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

Общепринятой моделью, лежащей в основе оценки качества ПС, является модель, регламентированная в стандарте ISO/IEC 9126-1:2001 «Информационная технология. Оценка программного продукта. Характеристики качества и руководства по их применению». В соответствии с данным стандартом модель качества ПС представляет собой иерархическую структуру, состоящую из трех уровней [11].

1. Характеристики качества (цели) - то, что мы хотим видеть в ПС.

2. Атрибуты качества - свойства ПС, показывающие приближение к цели.

3. Метрики - количественные характеристики степени наличия атрибутов.

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

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

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

Легкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов.

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

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

Функциональность и надежность являются обязательными характеристиками качества ПС.

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

Каждое из этих свойств должно быть конкретизировано:

Оценка его наличия в ПС;

Степень обладания им этим ПС.

Определения используемых примитивов качества ПС Примитивы качества Свойство Завершенность Степень обладания …   С-документи рованность Наличие документации, … Зависимость характеристик качества от примитивов качества ПС Характеристики качества Примитивы…

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

Функциональная спецификация состоит из [1]:

Описания внешней информационной среды, к которой должны применяться программы разрабатываемого ПС;

2. определение функций ПС, определенных на множестве состояний этой информационной среды (внешние функции ПС);

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

В первой частиопределяются на концептуальном уровне:

Все используемые каналы ввода и вывода;

Все информационные объекты, к которым будет применяться разрабатываемое ПС;

Существенные связи между этими информационными объектами.

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

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

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

Ошибки взаимодействия с пользователем;

Попытки применить функцию к данным, не удовлетворяющим ограничениям, указанным в ее спецификации;

Получение результата, нарушающего заданное ограничение.

Для каждого такого случая должна быть определена реакция ПС.

Таким образом, внешнее описание определяет, что должно делать ПС, какими внешними свойствами должно обладать; не отвечает на вопрос, как должно быть устроено, как обеспечить требуемые свойства; определяет задачи, которые должны решить разработчики; должно быть понятно представителям заказчика. На его основании принимается решение на заключение договора на разработку ПС. Таким документом является техническое задание, требования к которому определяются ГОСТом 19.201 «Техническое задание. Требования к содержанию и оформлению» (Приложение 2).

Методы контроля внешнего описания ПС

Разработка внешнего описания должна завершаться проведением контроля правильности внешнего описания.

Имеются следующие методы контроля, применяемые на этом этапе [1]:

Статический просмотр;

Смежный контроль;

Пользовательский контроль;

Имитация.

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

Смежный контроль

§ Контроль функциональной спецификации - это ее проверка разработчиками требований к ПС и спецификации качества; § Контроль внешнего описания снизу - это его изучение и проверка… Пользовательский контроль - этот вид контроля внешнего описания подразумевает участие пользователя (заказчика) в…

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

Основные задачи разработки архитектуры ПС [1]:

Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

Определение способов взаимодействия между выделенными программными подсистемами.

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

Проектирование ПС – это процесс, следующий за этапами анализа и формирования требований. Модели анализа поставляют этапу проектирования исходные сведения для работы. Информационная модель описывает информацию, которую должно обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель закрепляет динамику системы. На выходе этапа проектирования – разработка данных, разработка архитектуры и процедурная разработка ПС [7].

 

Рис 4.1. Информационные потоки процесса разработки ПС

Особенности этапа проектирования

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

Обычно в проектировании выделяют две ступени [7]: предварительное проектирование и детальное проектирование.

Предварительное проектирование формирует абстракции архитектурного уровня.

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

Еще выделяют интерфейсное проектирование, цель которого - сформировать графический интерфейс пользователя (GUI).

 

Рис 4.2. Информационные связи процесса проектирования

 

Предварительное проектирование обеспечивает:

§ идентификацию подсистем;

§ определение основных принципов управления между частями системы.

Предварительное проектирование включает три типа деятельности:

1. Структурирование системы. Система структурируется на несколько подсистем. Определяется взаимодействие подсистем.

2. Моделирование управления. Определяется модель связи между частями системы.

3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульное соединение.

Основные классы архитектур программных средств

Различают следующие основные классы программных средств [1]:

Цельная программа;

Комплекс автономно выполняемых программ;

Слоистая программная система;

Комплекс параллельно выполняемых программ.

Комплекс автономно выполняемых программ состоит из набора программ. Любая из них может быть активизирована пользователем. При выполнении… Слоистая программная система состоит из упорядоченной совокупности программных… Фактически архитектура состоит из четырех уровней [8]:

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

 

	Интерфейс пользователя
	Управление вводом-выводом
	Драйвер устройства связи оператора и консоли
	Управление памятью
	Планирование задач и процессов
	Оборудование

Рис 4.3. Архитектура операционной системы

Слоистые системы:

Хорошо реализуются (при использовании операций нижнего слоя нужно знать лишь, что они делают);

Хорошо тестируются (отладка начинается с нижнего слоя и проводится послойно);

Хорошо модифицируются (можно заменить лишь один слой, не трогая остальные);

Сложны для разработки (тяжело определить, что к какому слою относится);

Менее эффективны, чем монолитные (для выполнения операций программе приходится проходить слои).

Разновидностью такой архитектуры является конвейер, который представляет собой последовательность программ, в которой стандартный вывод каждой… Рис. 4.4. Конвейер параллельно действующих программ

В комплексе автономно выполняемых программ для обеспечения взаимодействия достаточно описания внешней информационной среды и возможностей ОС для запуска программ;

В слоистой программной системе достаточно спецификации выделенных программных слоев и обычного аппарата обращения к процедурам;

В программном конвейере взаимодействие между программами обеспечивает ОС.

Архитектурные функции

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

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

Методы проектирования архитектуры программных средств

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

Другой вариант определения архитектуры - это множество представлений о ПС, каждое из которых отражает точку зрения определенной группы участников проекта (аналитиков, проектировщиков, кодировщиков, тестеров, пользователей и др.). Эти представления определяют решения по проектированию структуры ПС, разделения его на отдельные компоненты и их связь. Это происходит из-за разных видов деятельности [2]:

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

При проектировании, наоборот, на первое место выходят принципы реализации ПС;

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

При развертке у заказчика на ПС смотрят как на набор файлов, хранилищ данных и т. д.

 

Рис. 4.5. Множество представлений о ПС

Язык UML

Часто под архитектурой понимают лишь описание основных аспектов ПC, создаваемых архитектором при разработке дизайна системы. Для этих целей используется язык моделирования UML (Unified Modeling Language) [2].

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

В конце 60-х годов, в связи с поиском новых средств разработки ПО, рождением программной инженерии и исследованиями в области проектирования и разработки искусственных систем появился термин структурный анализ (structured analysis) систем. Одновременно был предложен диаграммный метод анализа и проектирования больших искусственных систем. Метод назывался SADT (Structured Analisys and Desing Technique), который стал основой серии военных стандартов США серии IDEF и широко распространился в индустрии. Однако диаграммный язык в SADT был очень скромным – набор блоков и связей между ними, с поддержкой декомпозиции блоков.

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

С развитием объектно-ориентированных средств разработки (конец 80-х – середина 90-х) структурный анализ превратился в объектно-ориентированный анализ и проектирование. Появилось большое количество методологий, и постепенно сложился единый язык моделирования, который и был закреплен в стандарте UML. Произошло это в 1997 году.

«Скелетом» UML является диаграммная структура. Каждый вид диаграмм является типом моделей, реализующим определенную точку зрения на программную систему. Виды диаграмм не являются строго обязательными в UML – их можно перемешивать, создавать свои собственные виды диаграмм. Тем не менее стандартные виды диаграмм являются определенным достоянием программной инженерии, так как отражают опыт многих исследователей и практиков: структурные диаграммы; поведенческие диаграммы; диаграммы последовательностей.

Контроль архитектуры программных средств

Для контроля архитектуры ПС используется смежный контроль и ручная имитация [1].

Смежный контроль архитектуры ПС:

§ сверху - это ее контроль разработчиками внешнего описания:

Разработчиками спецификации качества;

Разработчиками функциональной спецификации.

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

Вопросы: 1. Какие процессы входят в этап проектирования ПС? 2. Что такое архитектура ПС?

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

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

Основными характеристиками программного модуля являются [1, 7]:

Размер;

Связность;

Сцепление с другими модулями;

Рутинность.

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

Модуль Разные функции (какие-то параметры)

Поздравить с Новым годом (...)

Вывести собаку на прогулку (...)

Запастись продуктами (...)

Конец модуля

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

2. Логическая связность(СС = 1).Элементы логически связного модуля объединены в категорию по принципу функционального подобия, из этой категории выбирается выполняемое действие.

Модуль Пересылка сообщения

Переслать по электронной почте

Переслать по факсу

Послать в телеконференцию

Конец модуля

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

3. Временная связность (СС = 3). При такой связности части модуля не связаны друг с другом, они привязаны ко времени.

Модуль Инициализировать Систему

Перемотать МЛ 1; перемотать МЛ 2

переключатель 1 := выкл; переключатель 2 := вкл

Конец модуля

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

Модуль Вычисление средних значений

Используется Таблица-А, Таблица-В

Вычислить среднее по Таблица-А

Вычислить среднее по Таблица-В

Вернуть среднее Таблицы А, среднее Таблицы В

Конец модуля

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

5. Коммуникативная связность(СС = 7). При коммуникативной связности части модуля используют одни и те же данные.

Модуль Отчет и средняя зарплата

Используется Таблица зарплаты служащих

Сгенерировать Отчет по зарплате

Вычислить параметр Средняя зарплата

Вернуть Отчет по зарплате. Средняя зарплата

Конец модуля

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

6. Информационная связность(СС = 9). При данном виде связности элементы обработчики модуля образуют конвейер для обработки данных.

Модуль Прием и проверка записи

Прочитать запись из файла

Проверить контрольные данные в записи

Удалить контрольные поля в записи

Вернуть обработанную запись

Конец модуля

Сцепление модуля- мера его зависимости по данным от других модулей, это внешняя характеристика модуля, которую желательно уменьшать. Сцепление… 1. Сцепление по данным(СЦ= 1): модуль А вызывает модуль В, все входные и… 2. Сцепление по образцу(СЦ = 3): вкачестве параметров используются структуры данных.

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

В процессе разработки программы ее модульная структура может формироваться и использоваться по-разному для определения порядка программирования и отладки модулей, указанных в этой структуре. Обычно рассматриваются два метода [1, 4, 7]:

Метод восходящей разработки;

Метод нисходящей разработки.

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

Технологией программирования не рекомендуется восходящий порядок разработки программы по следующим причинам.

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

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

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

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

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

Текст головного модуля

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

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

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

Рис. 5.1. Первый шаг формирования модульной структуры
программы при конструктивном подходе

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

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

Контроль структуры программы

Для контроля структуры программы используются три метода [1]:

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

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

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

Смежный контроль снизу - это контроль спецификации модулей со стороны разработчиков этих модулей.

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

При разработке программного модуля принято придерживаться следующего порядка [1, 4]:

Изучение и проверка спецификации модуля, выбор языка программирования;

Выбор алгоритма и структуры данных;

Программирование модуля;

Шлифовка текста модуля;

Проверка модуля;

Компиляция модуля.

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

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

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

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

Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки (выполнение его на компьютере).

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

Структурное программирование

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

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

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

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

Пошаговая детализация

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

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

В качестве основного метода построения текста модуля ТП рекомендуется пошаговая детализация. Сущность этого метода заключается в разбиении процесса разработки текста модуля на ряд шагов [1, 4].

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

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

Этот процесс завершается, когда все уточняемые понятия будут в конечном счете выражены на базовом ЯП.

Пример: Удаление в файле записей до первой, удовлетворяющей заданному фильтру.

Установить начало файла

ПОКА не конец файла ДЕЛАТЬ

• Прочитать очередную запись

• ЕСЛИ очередная запись удовлетворяет фильтру ТО

• ВЫЙТИ

• ИНАЧЕ

• Удалить очередную запись из файла.

• ВСЕ ЕСЛИ

• ВСЕ ПОКА

• ЕСЛИ записи не удалены ТО

• НАПЕЧАТАТЬ "Записи не удалены".

• ИНАЧЕ

• НАПЕЧАТАТЬ "Удалено N записей".

• ВСЕ ЕСЛИ

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

Контроль программного модуля

Применяются следующие методы контроля программного модуля [1, 4].

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

Сквозное прослеживание представляет собой один из видов динамического контроля модуля на некотором наборе тестов.

Вопросы:

1. В чем заключается цель модульного программирования?

2. Назовите основные характеристики программного модуля.

3. Что определяет связность модуля?

4. Перечислите названия модулей с разными степенями связности по степени их возрастания.

5. Что такое сцепление модуля?

6. Какой модуль называется рутинным? Какой модуль зависит от предыстории?

7. Какая модульная структура программы используется в ТП?

8. Перечислите классические методы разработки структуры программы. Назовите предпочтительный метод.

9. Суть конструктивного подхода разработки структуры программы?

10. Суть целенаправленной конструктивной реализации разработки структуры программы?

11. Суть архитектурного подхода разработки структуры программы?

12. Какие существуют методы контроля структуры программы?

13. Перечислите шаги разработки программного модуля.

14. Основная суть структурного программирования?

15. Основные конструкции структурного программирования?

16. Почему в структурном программировании не рекомендуется использовать оператор GOTO?

17. Когда оператор GOTO рекомендуется использовать?

18. Почему построение блок-схем не рекомендуется при программировании модуля?

19. В каких случаях построение блок-схем эффективно при программировании модуля?

20. Суть метода пошаговой детализации при построении текста модуля?

21. Что описывается на первом шаге пошаговой детализации при построении текста модуля?

22. Чем завершается метод пошаговой детализации построения текста модуля?

23. В чем заключается статическая проверка текста модуля?

24. Суть сквозного прослеживания текста модуля?

6. Тестирование и отладка программного средства

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

Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения этих программ. Указанный набор данных называется тестом.

Отладка - многократное повторение процессов: тестирования, констатирующего наличие в ПС ошибки; поиска места ошибки в программах и документации ПС; редактирования программ и документации с целью устранения обнаруженной ошибки [1, 2, 3, 4, 7, 8, 10].

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

Рис. 6.1. Тестирование методом белого ящика

На рисунке видно, что на основе требований к системе создается реализация и тестовая модель системы [2]. Тестирование есть сопоставление двух этих представлений с целью выявить их несоответствия. Чем независимее друг от друга будут эти представления, тем больше прока от их сопоставления.

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

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

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

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

Тесты проектируются на основании:

1. спецификаций ПС (внешнего описания, описания архитектуры и спецификации модулей). Модули рассматриваются как черные ящики;

2. текстов программ с целью протестировать все пути выполнения каждой программы ПС.

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

Оптимальная стратегия проектирования тестов базируется на принципах [1, 7]: на каждую функцию - хотя бы один тест; на каждую область и на каждую границу изменения входной величины - хотя бы один тест; на каждую исключительную ситуацию, указанную в спецификациях, - хотя бы один тест.

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

Виды тестирования

Можно выделить следующие виды тестирования [2, 3, 7, 8].

Модульное тестирование (автономная отладка) - тестируется каждый отдельный модуль, в отрыве от остальной системы. Самый распространенный случай применения – тестирование модуля самим разработчиком, проверка того, что отдельные модули делают действительно то, что от них ожидается. Различные среды разработки поддерживают средства модульного тестирования, например, свободно распространяемая библиотека для Visual Studio NUnit. Созданные разработчиком модульные тесты часто включаются в пакет регрессионных тестов, и могут запускаться многократно.

Интеграционное тестирование – компоненты тестируются на совместимость, поскольку разные компоненты могут создаваться разными людьми, в разное время, по разным технологиям. Этот вид тестирования должен применяться самими программистами, чтобы удостовериться, что все живет вместе в первом приближении. Далее тонкости интеграции могут исследовать тестеровщики. «Ошибки на стыках» непросто обнаруживать и устранять. Во время разработки все компоненты вместе не готовы, интеграция откладывается, а в конце обнаруживаются трудные ошибки (их устранение требует существенной работы). Здесь выходом является ранняя интеграция системы и в дальнейшем использование практики постоянной интеграции.

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

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

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

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

Приемочное тестирование – тестирование, выполняемое при приемке системы заказчиков. Различные стандарты часто включают в себя наборы приемочных тестов.

Автономная отладка программного средства

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

При автономной отладке ПС каждый модультестируется в некотором программном окружении:

Модулей отлаживаемой программы, которые ужеотлажены;

§ модулей,управляющих отладкой - отладочные модули.

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

В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженнымимодулями.Такой процесс называется интеграцией программы. Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы [1, 7].

При восходящем тестировании окружение отлаживаемого модуля содержит только один отладочный модуль - ведущий в тестируемой программе.

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

Достоинствами восходящего тестирования являются:

Простота подготовки тестов;

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

К недостаткам восходящего тестирования относится то, что:

Тестовые данные готовятся не в той форме, которая рассчитана на пользователя;

Необходимо выполнять большой объем отладочного программирования;

Необходимо выполнять специальное тестирование сопряжения модулей.

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

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

Достоинствами нисходящего тестирования являются:

Возможность готовить тесты в форме, рассчитанной на пользователя;

Небольшой объем отладочного программирования (имитаторы модулей просты);

Отпадает необходимость тестирования сопряжения модулей.

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

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

Тестирование сопряжения модулей при нисходящем тестировании делается попутно каждым пропускаемым тестом, что считают достоинством нисходящего тестирования.

Нисходящее тестирование является предпочтительным.

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

Комплексная отладка ПС

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

Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые могут возникнуть у пользователя в реальных условиях. При комплексной отладке тестируется ПС в целом. Тесты готовятся по каждому из документов. Тестирование этих документов производится в порядке, обратном их разработке [1].

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

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

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

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

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

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

Всегда должен быть четко оговорен конечный результат тестирования. Еще до начала работ или на одной из ранних стадий должен быть создан и согласован с заказчиком набор тестов, успешный пропуск которых свидетельствует об успешном окончании работы в целом. Для регламентации этих работ можно применять ГОСТ 19.301 «Программа и методика испытаний. Требования к содержанию и оформлению» (Приложение 3).

Работа с ошибками

Как правило, описание ошибки в системе контроля ошибок имеет следующие основные атрибуты [2, 10]: § ответственного за ее проверку – тестеровщика, который ее нашел и проверяет,… § ответственного за ее исправление – разработчика, которому ошибка отправляется на исправление;

Базу данных для хранения ошибок;

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

Сетевой доступ, так как проекты все чаще оказываются распределенными;

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

Очень важным при работе с ошибками оказываются различные отчеты.

Заповеди отладки ПС

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

2. Нежелательно тестировать свою собственную программу.

3. Хорош тот тест, для которого высока вероятность обнаружения ошибки, а не тот, который демонстрирует правильную работу программы.

Готовить тесты для правильных, и для неправильных данных.

6. Каждый модуль подключать к программе только один раз, никогда не изменяя программу, чтобы облегчить ее тестирование. 7. Пропускать заново все тесты, связанные с проверкой работы какой-либо… Вопросы:

Корректировка для устранения обнаруженных ошибок или нереализованных задач;

Адаптация в изменившихся условиях эксплуатации;

Улучшение для повышения производительности или уровня сопровождения;

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

По стандарту IEEE 1219 процесс сопровождения начинается с момента передачи ПС в эксплуатацию и касается таких вопросов, как планирование деятельности по сопровождению.

Рис. 7.1. Работы в процессе сопровождения по стандарту IEEE 1219

Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе.

Рис. 7.2. Процесс сопровождения по стандарту ISO/IEC 14764

Работы по сопровождению в стандарте 14764 разбиты на задачи:

Реализация процесса;

Анализ проблем и необходимых модификаций;

Проведение модификаций (реализация изменений);

Оценка и принятие проведенных работ при сопровождении;

Миграция (на модифицированную или новую версию ПС);

Вывод из эксплуатации (прекращение эксплуатации ПС);

Многие работы по сопровождению похожи на аспекты деятельности по разработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и документирование. Специалисты по сопровождению должны отслеживать требования так же, как и инженеры-разработчики и обновлять документацию по мере разработки и выпуска новых релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или организации, отвечающие за сопровождение, в случае использования элементов процессов разработки в своей деятельности, адаптировали эти процессы в соответствии со своими потребностями. В то же время, деятельность по сопровождению обладает и определенными уникальными чертами, что приводит к необходимости использования специализированных процессов.

Уникальные работы по сопровождению

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

Бизнес - планирования (организационный уровень);

Планирования непосредственных работ по сопровождению;

Планирования версий (уровень программного средства);

Планирования обработки конкретных запросов на изменение.

Разработка программных системы, обычно, занимает от несколько месяцев до нескольких лет, сопровождение и активная эксплуатация систем занимает от нескольких лет до 5-10 лет и более. Проведение оценки ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества.

Вначале необходимо определить концепцию сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 должен касаться следующих вопросов:

Содержания деятельности по сопровождению;

Адаптации процесса сопровождения;

Идентификации организации, которая будет заниматься сопровождением;

Оценки стоимости сопровождения.

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

Планирование версий требует от персонала сопровождения выполнения задач:

Получения и сбора информации о датах размещения индивидуальных запросов и отчетов;

Достижения соглашения с пользователями о содержании последующих версий программного обеспечения;

Идентификации потенциальных конфликтов и возможных альтернатив реализации необходимых запросов;

§ оценки рисков для функционирования текущей версии ПС и разработки плана «отката» на немодифицированный вариант системы, в случае возникновения проблем, связанных с модификацией;

Информирования всех заинтересованных лиц.

Конфигурационное управление Конфигурационное управление является важным элементом процесса сопровождения.… Выделяются две основные задачи в конфигурационном управлении – управление версиями и управление сборками [2].

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.102-77
СТАДИИ РАЗРАБОТКИ
United system for program documentation. Development stages.

Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 срок введения установлен

с 01.01 1980 г.

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

2. Стадии разработки, этапы и содержание работ должны соответствовать указанным в таблице.

Таблица

Стадии разработки	Этапы работ	Содержание работ
1. Техническое задание	Обоснование необходимости разработки программы	Постановка задачи Сбор исходных материалов Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.
Научно-исследовательские работы	Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи
Разработка и утверждение технического задания	Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на неё. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания.
2. Эскизный проект	Разработка эскизного проекта	Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи Разработка технико-экономического обоснования.
Утверждение эскизного проекта	Разработка пояснительной записки. Согласование и утверждение эскизного проекта.
3. Технический проект	Разработка технического проекта	Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.
Утверждение технического проекта	Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта.
4. Рабочий проект	Разработка программы	Программирование и отладка программы.
Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
Испытания программы	Разработка, согласование и утверждение порядка и методики испытаний. Проведение предварительных государственных, межведомственных, приёмо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний.
5. Внедрение	Подготовка и передача программы.	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Примечания:

• 1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
• 2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

Переиздание. Ноябрь 1987 г.

ПРИЛОЖЕНИЕ 2

УДК 002:651.7/.78:006.354

Группа Т55

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.201-78 (СТ СЭВ 1627-79)
ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
United system for program documentation. Technical specification for development. Requirements to contents and form of presentation

Постановлением Государственного комитета СССР по стандартам
от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01. 1980 г.

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

ОБЩИЕ ПОЛОЖЕНИЯ

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений… 1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или…

СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

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

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

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

(Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8. В приложениях к техническому заданию, при необходимости, приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
• другие источники разработки.

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

ПРИЛОЖЕНИЕ 3

УДК 651.7/.78:002:006.354

Группа Т55

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.301-79* (СТ СЭВ 3747-82)
ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
United system for program documentation. Program and methods of testing. Requirements for contents and form of presentanion.

Постановлением Государственного комитета СССР по стандартам
от 11 декабря 1979 г. № 4753 срок введения установлен

с 01.01 1981 г.

Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Программа и методика испытаний», определенного ГОСТ 19.101-77.

Стандарт полностью соответствует СТ СЭВ 3747-82.

ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Структура и оформление документа устанавливается в соответствии с ГОСТ 19.105-78.

Составление информационной части (аннотации и содержания) является необязательным.

1.2. Документ «Программа и методика испытаний» должен содержать следующие разделы:

· объект испытаний;

· цель испытаний;

· требования к программе;

· требования к программной документации;

· состав и порядок испытаний;

· методы испытаний.

В зависимости от особенностей документа допускается вводить дополнительные разделы.

СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Объект испытаний» указывают наименование, область применения и обозначение испытуемой программы.

2.2. В разделе «Цель испытаний» должна быть указана цель проведения испытаний.

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

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

2.3, 2.4. (Измененная редакция, Изм. № 2). 2.5, 2.6. (Исключены, Изм. № 2).

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

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

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

2.7, 2.8. (Измененная редакция, Изм. № 2).

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

^*Переиздание (Ноябрь 1987 г.) с Изменениями № 1, 2, утвержденным в феврале 1982 г (ИУС 5-82, ИУС 9-83)

Список литературы

1· Жоголев Е.А. Технология программирования. – М., Научный Мир, 2004.- 216 с.

2· Кознов, Д.В. Бугайченко Д.Ю. Введение в программную инженерию. http://www.intuit.ru/department/se/inprogeng/

3· Котляров В.П. Основы тестирования программного обеспечения. http://www.intuit.ru/department/se/testing/

4· Мануйлов В.Г. Разработка программного обеспечения на Паскале. – М.: «ПРИОР», 1996. – 238 с.

5· Мееров И.Б., Сысоев А.В., Козинов Е.А. Технологии программирования на базе Microsoft Solutions Framework. http://www.intuit.ru/department/se/msfprog/

6· Мееров И.Б., Сысоев А.В., Козинов Е.А. Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF). http://www.software.unn.ru/msf/

7· Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. – СПб.: Питер, 2004.- 527 с.

8· Петрухин В.А., Лаврищева Е.М. Методы и средства инженерии программного обеспечения. http://www.intuit.ru/department/se/swebok/

9· Рекомендации по преподаванию программной инженерии и информатики в университетах: - М.: ИНТУИТ.РУ «Интернет Университет Информационных Технологий», 2007 – 462 с.

10· Терехов А.Н. Технология программирования: учебное пособие. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006.- 148 с. http://www.intuit.ru/ department/se/introprogteach/

11· Государственный стандарт РФ ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению».

12· Государственный стандарт РФ ГОСТ Р ИСО/МЭК 12207 -99 «Информационная технология. Процессы жизненного цикла программных средств».

13· Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Методические основы управления ИТ-проектами. http://www.intuit.ru/ department/itmngt/metbitm/

14· Скороход С.В. Управление проектами средствами Microsoft Project. http://www.intuit.ru/department/itmngt/pmmsproject/

15· Васючкова Т.С., Держо М.А., Иванчева Н.А., Пухначева Т.П. Управление проектами с использованием Microsoft Project. http://www.intuit.ru/department/itmngt/pmusemspr/