Электронные библиотеки и инструментарий Internet’a

1. Коллекции информационных ресурсов;

2. БД Интернета;

3. Поисковые средства;

4. Системы AI (мультиагенты).

7. Репозитории.

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

Три уровня репозитория:

• Модельный;

• Программного интерфейса;

• Окружения.

8. Средства поддержки коллективной разработки

Проблема разделения ресурсов.

1. Системы разделения файлов.

   1. Системы управления версиями файлов (для отслеживания изменений между версиями файлов и разделения доступа к ним).

   2. Системы управления правами пользователей (для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве). Мастер пространство.

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

2. Средств поддержки работы виртуальных групп.

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

Методологии программирования

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

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

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

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

Разные направления в программировании (в том числе и в методологиях) родились на основе четырех главных моделей алгоритмов:

1. Абстрактные вычислительные машины Тьюринга и Поста -> методология императивного программирования.

2. От рекурсивных функций Гельберта и Аккермана -> методология структурного программирования.

3. Идея λ-исчисления Чёрча, Шейнфинкеля и Карри -> методология функционального программирования.

4. Нормальные алгорифмы Маркова -> методология логического программирования и обработка символьной информации.

Способ описания алгоритма определяет ядро методологии.

1. Методология императивного программирования;

2. Методология ООП;

3. Методология функционального программирования;

4. Методология программирования в ограничениях;

5. Методология логического программирования.

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

Еще один способ классификации методологий – на основе отображения структур языка. Основные структуры языка – данные, управление и логика (9 отображений).

1. Данные->данные – Отображают процесс укрупнения данных и операций над ними, и приводит к методам модульности и абстрактных типов данных.

2. Управление->управление. Это отображение связано с понижением уровня структуры управления языка моделирования и идея структурного программирования.

3. Логика->логика. В основе логического программирования.

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

5. Данные->логика. Дает возможность по совокупности операций с данными построить логическую структуру. Методология программирования в ограничениях.

6. Управление->данные. Лежит в основе методов интерпретации, определяет методологию «доступ ориентированного программирования».

7. Управление->логика. Лежит в основе методов расшифровки смысла задачи. Методы обратного программирования.

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

9. Логика->управление. Может быть использовано в системах структурного синтеза.

Каждая из 3-х структур языка состоит из разнородных подструктур, следовательно, на основе их можно построить более детальную классификацию.

1. Методология императивного программирования.

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

Основное синтаксическое понятие – оператор (атомарные и структурные). Средство структурирования – подпрограмма.

Методы: метод изменения состояния вычислителя и метод управления потоком исполнения.

Языки: Fortran, Algol, Pascal, C и др.

Класс задач: задачи, в которых последовательное выполнение команд является естественным, например, управление современными аппаратными средствами.

2. Методология ООП.

Основана на методах объектно-ориентированной декомпозиции (концепции инкапсуляции, наследования и полиморфизма), абстрактных типах данных, пересылке сообщений. Статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы – в терминах обмена сообщениями между объектами. Одно из основных понятий – класс.

Класс описывает структуру и функционирование множества объектов с подобными характеристиками, атрибутами и поведением.

Средство структурирования: класс.

Языки: Симула, Java, C++, Delphi (Object Pascal), C#.

Класс задач: практически любая предметная область, особенно для создания и взаимодействия элементов графического интерфейса.

3. Методология функционального программирования.

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

Языки: LISP, РЕФАЛ, ML, VIRANDA.

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

4. Методология логического программирования.

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

Языки: Prolog, Леаф (leaf), Mercury.

5. Методология программирования в ограничениях.

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

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

Пример: поиск методом отсеивания.

Языки: IDEAL, OPL, УТОПИСТ (универсальные текстовые описания терминов).

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

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

7. Методология императивного параллельного программирования.

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

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

Языки: ALGOL68, Конкурент-Паскаль, Modula 2, ADA, LINDA и др.

8. Методология программирования, управляемого потоками данных.

Операции выполняются не последовательно, а в зависимости от готовности данных.

9. Методология доступ-ориентированного программирования.

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

10. Методология нейронно-сетевого программирования.

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

Технологии программирования (3.10.2006)

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

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

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

В истории развития существует 4 этапа.

1. Стихийное программирование.

До середины 60-х. гг. XX в. Отсутствуют сформулированные ТП. Решаются задачи вычислительного характера, они четко сформулированы.

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

2. Структурный подход к программированию.

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

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

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

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

Модульное программирование.

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

Надежные программы – до 100 тыс. операторов.

Минусы: ошибки в интерфейсе при вызове программ выявляются только при выполнении программ.

3. Объектный подход.

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

- при использовании ОО-языков сохраняется зависимости модулей ПО от адресов экспортируемых полей и методов структур и форматов данных.

4. Компонентный подход и развитие case-технологий.

С середины 90-х гг.

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

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

CASE-технологии – это разработка ПО с использованием компьютерной поддержки всех этапов жизненного цикла ПО.

Основные технологические подходы

1. Ранние

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

2. Каскадные (водопадные)

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

К этой группе относятся:

1. Каскадный подход.

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

+ легко вести планирование работ и формировать бюджет.

2. Каскадно-возвратный.

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

+ более высокая гибкость (по сравнению с первым подходом);

- по сравнению с первым подходом – запаздывание в достижении результата.

3. Каскадно-итерационный.

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

4. Каскадный подход с перекрывающимися процессами.

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

5. Каскадный подход с подпроцессами (≈ 4 подход).

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

6. Спиральный подход.

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

3. Каркасные.

Представляет собой каркас для процессов. Каркас включает четыре основные фазы:

1. Начало: определение бизнес-целей проекта;

2. Исследование: разработка плана и архитектуры проекта;

3. Построение: создание системы;

4. Внедрение: поставка конечным пользователям.

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

Особенности подхода:

• итеративность;

• гибкость;

• раннее определение архитектуры;

• контроль качества;

• раннее выявление и устранение рисков;

• возможность конфигурации, настройки.

Пример: рациональный унифицированный процесс.

3. Генетические технологические подходы.

Разработка нового программного продукта осуществляется на основе элементов уже имеющегося ПО.

1. Синтезирующее программирование.

Синтез программы по ее спецификации, т.е. программа строится на основе документа, написанного на языке спецификаций и является базисом для последующей реализации. При реализации доопределяют детали, которые нельзя выразить на языке спецификаций; выбирают язык и аппаратную платформу и фиксируют отображение понятий языка спецификации на язык реализации и аппаратно-программную платформу. Возможна автоматическая генерация ПО по спецификации (CDL, LOTOS, UML).

2. Сборочное (расширяемое).

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

Виды:

• Модульное сборочное программирование;

• ОО-сборочное программирование;

• Компонентное сборочное программирование;

• Аспектно-ориентированное сборочное программирование.

3. Конкретизирующее программирование.

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

Паттерн – это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте.

Паттерн состоит из четырех основных элементов:

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

• задачи (описание, когда следует применять паттерн для конкретизации);

• решения (абстрактное описание элементов дизайна и отношения между ними);

• результатов (следствий применения паттернов).

+ упрощают повторное использование удачных проектных и архитектурных решений.

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

5. Подходы на основе формальных преобразований.

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

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

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

• ящика с состояниями в котором выделяются внутренние состояния, показывающие элементы истории стимулов.

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

Три принципа использования ящиков:

1. Все определенные при проектировании данные скрыты (инкапсуляция);

2. Все процессы определены как использующие ящики последовательно или параллельно;

3. Каждый ящик занимает определенное место в системной иерархии.

Отладка заменяется формальной верификацией (проверка корректности).

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

Формальные синтезирующие подходы (логические и трансформационные).

• Формальное сборочное программирование (рассматривает спецификацию как набор существующих компонент);

• Формальное конкретизирующее программирование.

5. Подходы быстрой разработки (прототипирование).

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

1. Итерационная разработка прототипа и тесное взаимодействие с заказчиком.

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

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

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

2. Итеративная разработка.

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

3. Постадийная разработка.

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

7. Адаптивные технологические подходы.

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

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

Применяются, если не удается точно сформулировать требования к ПО (например, при разработке систем AI). Например, компьютерный дарвинизм.

Существует авторская, коллективная и общинная разработка.

Авторская (жизненный цикл ПО поддерживается одним человеком) – высокая производительность за счёт исключения межличностных коммуникаций, тех документации, работ по разбиению проекта на составляющие, распределению работ, координации деятельности исполнителей, исключение контроля за работой. Объём авторской разработки в 5-20 раз меньше по сравнению с индустриальными. Меньше количество ошибок. Сравнительно небольшой размер ПО. Высокая длительность проекта.

Коллективная разработка

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

Командные роли бригады главного программиста: Главный программист,

Дублёр (заместитель главного),

Администратор (менеджер),

Редактор (технический писатель),

Языковед (эксперт в языках программирования),

Инструментальщик,

Отладчик,

Делопроизводитель.

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

Общинная разработка

3 основных фактора:

• Децентрализованность разработки;

• Разработка ведется на базе открытых исходных текстов;

• Большое количество внешних тестеров (β-тестеры).

Жизненный цикл по

Жизненный цикл – совокупность взаимосвязанных процессов изменения состояния продукции при ее создании и использовании. (ISO 9000).

Выделяют 6 стадий:

1. Маркетинг;

2. Проектирование;

3. Производство;

4. Обращение;

5. Эксплуатация (потребление);

6. Утилизация.

Жизненный цикл ПО – весь период от момента возникновения замысла ПО до прекращения всех видов его использования (когда фирма прекращает его сопровождение).

Особенности программных средств (их жизненного цикла):

1. Противостояние: неформальный характер требований и формализованный объект разработки.

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

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

4. Программное средство при эксплуатации не расходуется и не расходует используемых ресурсов.

ГОСТ Р ИСО/МЭК 12207-99.

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

1. Основные;

2. Вспомогательные;

3. Организационные.

1. Основные

   1. Процесс заказа (приобретение).

   2. Процесс поставки.

   3. Процесс разработки

      1. Подготовительная работа (выбор модели жизненного цикла, стандартов, методов, средств разработки, составление плана работы).

      2. Анализ требований к системе (функциональность, надежность, безопасность, интерфейс).

      3. Проектирование архитектуры системы (не только ПО, но и всего комплекса).

      4. Анализ требований к ПО.

      5. Проектирование архитектуры ПО.

      6. Детальное проектирование ПО (модули).

      7. Кодирование и тестирование ПО.

      8. Интеграция ПО.

      9. Квалификационное тестирование ПО.

      10. Интеграция системы.

      11. Квалификационное тестирование системы (в том числе документации).

      12. Установка ПО на оборудование заказчика.

      13. Приемка ПО.

   4. Процесс эксплуатации (работа оператора).

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

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

• документирование;

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

• обеспечение качества;

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

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

• Процесс совместного анализа (оценка состояния работ и их результатов по проекту).

• Процесс аудита (определение соответствия требованиям, планам и условиям договора).

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

3. Организационные

   1. Процесс управления

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

   3. Процесс усовершенствования (определяет оценку, измерение, контроль и усовершенствование процессов жизненного цикла).

   4. Процесс обучения (первоначальное и последующее обучение персонала)

(по стандарту)

Классические процессы жизненного цикла

1. Возникновение и исследование идеи

2. Планирование

3. Формирование требований и анализ задачи

4. Проектирование

5. Программирование

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

7. Ввод в действие

8. Эксплуатация и сопровождение

9. Завершение эксплуатации

График

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

Иногда стадии объединяют в более крупные временные рамки – фазы.

Существует несколько подходов к образованию фаз. Один из них:

Или:

Начальная фаза -> середина -> кризис -> окончание.

Стадии разработки, регламентированные гост 19.102 «Стадии разработки»

1. ТЗ: постановка задачи, НИР (научно-исследовательские работы), разработка и утверждение ТЗ.

2. Эскизный проект: анализ требований, разработка спецификаций к проекту.

3. Технический проект: определение структуры программного продукта.

4. Рабочий проект: все работы по реализации программ.

5. Внедрение: работы по передаче программного продукта пользователю.

Все процессы объединены моделью.

Модели жизненного цикла

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

ГОСТ Р ИСО|МЭК 12207-99.

1. Каскадная;

2. Эволюционная;

3. Формирующая;

4. Модель заранее планируемого улучшения продукта;

5. Спиральная модель;

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

Анализ ->проектирование->программирование->проектирование ->сопровождение

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

Спиральная модель базируется на каскадной модели и макетировании (прототипировании – для уточнения требований задачи), к которой добавляется анализ риска. Модель включает 4 действия, представленными квадрантами спирали, которые на первом витке выполняется в соответствии с начальными требованиями, а на последующих – на основе требований заказчика, которые возникают при оценивании. Действия следующие:

1. Планирование – определение целей, вариантов, ограничений.

2. Анализ риска – анализ вариантов и распознавание риска.

3. Конструирование – разработка ПП очередного уровня (может быть реализована классической моделью).

4. Оценивание – оценка заказчиком текущих результатов проектирования.

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

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

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

Инкрементная модель - в отличие от спиральной не содержит анализа риска.

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

Классические и технологические процессы.

1. Возникновение и исследование идеи.

1) Возникновение и первичное исследование идеи.

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

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

2) Детальное исследование идеи – выработка концепции, постановки задачи, создание одностраничного списка проекта.

3) Экспертиза идеи специалистами, принятие решения о начале процесса планирования. На данном этапе специалисты должны подтвердить или поправить все предположения, на которых базируется проект, и выявить и охарактеризовать все критические стороны в проекте. В случае положительного решения – будет выполнен процесс планирования проекта.

2. Управление идеей

Длится весь жизненный цикл ПО. Цель управления – создание условий для получения максимальной прибыли в минимальные сроки, взаимодействие с другими коллективами разработчиков. В деятельности по управлению существует 5 направлений (стратегий):

1. Оперативная стратегия;

2. Финансовая;

3. Маркетинговая;

4. Стратегия в области исследования и развития ПО;

5. Стратегия человеческих отношений.

3 составные части управления:

Производственная

Финансовая

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

4 уровня управления:

1. Высший менеджмент (председатель совета директоров);

2. Управляющие среднего уровня;

3. Управляющие первичного уровня (руководители проектов и т.п.);

4. Нижний уровень (инженер).

Основные характеристики управления:

• Направленность на достижение конкретных целей (четкое задание целей);

• Координирование выполнения взаимосвязанных действий;

• Ограниченная протяженность во времени;

• Уникальность и важность;

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

1. Гедонизм – заинтересованность людей делать то, что им приятно и уклоняться оттого, что им неприятно.

2. Инстинкты – автоматическая природная предрасположенность вести себя определенным образом.

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

4. Когнитивная теория – рациональное поведение людей в направлении будущего.

5. Потребности – осознанная недостаточность чего-либо:

а) Первичные или физические – необходимы для выживания.

б) Вторичные – психологические потребности в уважении и др.

Выделяют особенности европейского, Российского, японского и др. менеджмента.

Методы управления проектом:

Метод критического пути. Указываются критические сроки.

Метод анализа и оценки программ

Метод сетевого планирования.

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

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

Организационные задачи, решаемые при планировании:

1. Анализ документации на полноту, содержание;

2. Назначение начальной и конечной дат.

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

Оценка времени выполнения работ и затраты на нее. Методы:

1. Сверху – вниз. По крупным блокам аналогичного проекта.

2. Снизу – вверх. По составленному графику работ (данные по трудозатратам берутся у исполнителей).

3. Методы норм работы (по средним срокам выполнения данных работ в данной компании).

4. Методика исторических отношений. Стоимость данного проекта относится к стоимости другого проекта пропорционально отношению их объемов в некоторой степени n (n подбирается опытным путем).

5. Методика приближенных вычислений. Планирование на основе приближенных формул.

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

Основные практики управления проектом, рекомендуемые сетью менеджеров по разработке ПО:

1. Формальное управление рисками.

2. Согласованность интерфейсов.

3. Формальные проверки проекта.

4. Планирование и управление на основе метрик (метрика – числовые оценки, накопленные в предыдущих проектах).

5. Контроль качества на детальном уровне.

6. Свободный доступ к информации о ходе проекта.

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

8. Конфигурационное управление.

9. Ответственность и отчетность руководства перед сотрудниками.

3. Формирование требований к программному продукту.

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

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

- для разработки текстов программ (конструирование и кодирование).

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

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

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

В спецификации выделяют 2 части:

1. Функциональная спецификация, описывающая функции программы.

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

Внешнее описание ПС = определение требований + спецификация качества + функциональная спецификация.

3 уровня формализации спецификации:

1. словесная спецификация.

2. модельные и структурированные спецификации (построение схем, диаграмм и др.).

3. формальная спецификация (на основе математических формализмов).

По способу представления спецификации выделяют:

1. Спецификации, имеющие текстовое представление (текстовые и формальные);

2. Представление с помощью информационных объектов (модельные).

4. Определение требований к пс.

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

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

1. Управляемая пользователем разработка. Требования определяются заказчиком, когда заключает договор с коллективом разработчиков. В этом случае разработчик должен выяснить: понятны ему требования заказчика или нет.

2. Контролируемая пользователем разработка. С-требования - требования, сформулированные заказчиком. На основе их разработчик формулирует детальные требования, которые получили названия D-требований. D-требования включают:

-функциональные требования (что система должна делать)

-нефункциональные - производтельность (скорость, пропускная способность, эффективность использования памяти)

-надежноть и доступность

-интерфейсные требования

-ограничения на точность

-инструменты и язык

-стандарты, платформыОбратные требоывния (что не должна делать система)

3. Независимая от пользователя разработка (при перспективе широкого применения разработанного ПС).

Наиболее предпочтителен вариант 2.

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

1-заказ

2-поставка

3-разработка (анализ требований к системе, к программному обеспечению)

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

Основные варианты реализации заказа:

-покупка готового программного продукта, удовлетворяющего определенным требованиям

-разработка программного продукта или обеспечение программной услуги собственными силами

-то же самое, но на договорной основе

-комбинация вышеперечисленного

-модернизация программного продукта или услуги

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

В любом случае заказчик должен получить гарантии, что:

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

-имеется в наличии соответствующая документация

-соблюдены права собственности, использования, лицензирования и гарантии

-предусмотрена последующая поддержка программного продукта

Требования формулируются на основе описанной заказчиком концепции или потребностей заказчика.

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

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

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

-пользователи плохо представляют, что им нужно

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

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

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

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

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

Анализ требований к системе включает следуюущие работы:

-анализ применения разрабатывамой системы с точки зрения определния требований к ней (анализ предметной области)

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

-документирование требований

Оценка требований производится по критериям:

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

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

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

-требования к внешним интерфейсам

-квалификационные требования

-требования безопасности

-требования защиты

-эргономические требования

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

-требования по вводу в действие, приемке, эксплуатации, сопровождению

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

-требования к обслуживанию пользователя

Оценка требований производится по следующим критериям:

-учет требований к системе и проекту системы

-внешняя согласованность с требованиями к системе

-внутренняя согласованность требований к объектам между собой

-тестируемость требований

-выполнимость программного проекта

-возможность эксплуатации и сопровождения

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

Документы:

-внешнее описание (спецификация) -

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

Внешее описание=определние требований+функц.спецификация+спецификация качества.

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

Функц. спецификация состоит из частей:

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

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

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

-техническое задание

-заявка на подряд

-др.

Спецификация качества пс

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

Примитивы:

1. функциональность - выражается через завершенность.

2. надежность - завершенность, точность, автономность, устойчивость, защищенность.

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

4. эффективность - временная эффективность, эффективность по ресурсам (памяти), эффективность по устройствам.

5. сопровождаемость:

а) изучаемость: С- документированность, информативность, понятность, структурированность, удобочитаемость.

б) модифицируемость: расширяемость, модифицируемость, структурированность, модульность.

6. Мобильность - независимость от устройств, автономность, структурированность, модульность.

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

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

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

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

11. Защищенность – способность ПС противостоять преднамеренным или нечаянным деструктивным действиям пользователя.

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

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

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

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

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

17. Эффективность по устройствам – экономичность использования устройств (машины для решения поставленной задачи).

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

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

20. Структурированность – характеризует ПС с точки зрения организации взаимосвязанных частей в единое целое.

21. Удобочитаемость – характеризует легкость восприятия текста программы.

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

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

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

25. Независимость от устройств – характеризует способность ПС работать на разнообразном виде аппаратуры.

Вмеждународном стандарте ИСО 9000 ТЗ - документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации в договоре.

В РФ - ГоСТ 19.201 - 78г. Там указан порядок составления, изменения, согласования и т.п. ТЗ.

Разделы ТЗ:

1.Введение:

-наименование

-краткая характеристика области применения программного продукта

2.Основания для разработки

-документы, на сновании которых ведется разработка

-наименование и условное обозначение темы разработки

3.Назначение разработки

-Описываются функц. и эксплуатационные характеристики

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

-требования к функц. характеристикам - состав ф-ий, вх-вых данных, временные характеристики

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

-условия эксплуатации - температура воздуха, давление и т.д., вид обслуживания, квалификация персонала

-требования к составу и параметрам технических средств - машины, память..

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

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

-требования к транспортирванию и хранению

-специальные требования

5.Требования к программной документации

Указывается состав программной документации и требования к ней

6.Технико-экономические показатели

-экономическая эффективность

-предполагаемая годовая потребность

-экономические преимущества по сравнению с аналогами

7.Стадии и этапы разработки

-содержание работ

-сроки

-исполнители

8.Порядок контроля и приемки

-виды испытаний

-общие требования к приемке работы

9. Приложения - при необходимости (научные работы, схемы алгоритмов, расчеты и т.п.)

Функциональная спецификация

Состоит из 3 частей:

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

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

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

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

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

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

а) спецификация качества с верху – это проверка со стороны разработчиков требований к ПС.

б) функциональная спецификация – выполняется разработчиком;

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

3. Пользовательский контроль – контроль заказчика.

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

Методы анализа и построения спецификации:

В структурной методологии - методы ведения структурного анализа:

- диаграммы потоков данных;

- диаграммы потоков управления;

- таблица решений;

- сети Петри;

- диаграммы зависимости;

- диаграммы декомпозиции;

- диаграммы функционального моделирования.

Пример:

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

В объектно-ориентированной методологии применяются следующие методы:

- КОК карты (класс, ответственность, кооперация);

- диаграммы вариантов использования;

- диаграммы классов;

- диаграммы состояний;

- диаграммы деятельности;

- диаграммы последовательности;

Пример:

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

Проектирование (разработка архитектуры пс)

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

-разработка и документальное оформление технического проекта для каждого компонента

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

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

-разработка и документальное оформление проекта БД

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

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

-уточнение требований к сборке программных средств

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

-совместный анализ технического проекта

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

Проектирование выполняется на 2-х уровнях:

1. Проектирование архитектуры ПС в целом (проектирование «в большом»).

2. Детальное проектирование – проектирование модулей (проектирование «в малом»).

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

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

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

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

В совокупности программную архитектуру описывают 4 структуры:

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

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

3. Процессная – описывает поведение системы во время выполнения программы.

4. Физическая – определяет отображение элементов ПС на аппаратное обеспечение.

Также используют другие структуры: структура вызовов, структура потоков, данных, структура потоков управления, структура классов.

Проектирование системной архитектуры:

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

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

Разработчик должен (в процессе проектирования системной архитектуры):

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

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

3-выполнить привязку системной архитектуры и требований к системе относительно установленных объектов. Эта привязка должна быть оформлена документально.

4-Системная архитектура и требования к объектам архитектуры должны быть оценены с цчетом следующих критериев:

-учет требований к системе

-соответствие требованиям к системе

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

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

-возможности эксплуатации и сопровождения

Эта оценка должна быть документально оформлена.

Проектирование программной архитектуры:

Ведется на основании требований, предъявляемых к ПО. Ясное описание архитектуры особенно важно, если в разработке участвует много программистов.

Созданием архитектуры занимаются самые опытные в команде разработчики.

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

-выделение программных подсистем и отображение на них внешних функций

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

Разработчик должен выполнить ряд работ для каждого программного объекта архитектуры:

1-трансформировать требования к программному объекту в архитектуру, которая описывает общую структуру обхекта и определяет компоненты объекта. Архитектруа программного проекта д.б. задокументирвоана.

2-разработать и докуменатльно формит общий (эскизный) проект внешних и внутренних интерфейсов программного объета

3-разработать и документально оформить эскизный проект БД

4-разработать и документально оформить предварительные версии документации пользователя

5-определить и документально оформит предварительные общие требования к испытаниям программного объекта и график сборки программного продукта

6-оценить архитектуру программного объекта, эскизные проекты и интерфейсы к БД по критериям:

-учет требований к программному объекту

-внешняя согласованность с требованиями к программному объекту

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

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

-возможность технического проектиования

-возможность эксплуатации и сопровождения

Затем все оформить документально

7-Провести совместный анализ оценки состояний, результатов работ по проекту

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

Критерии выбора архитектур:

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

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

-простота - простота понимания и простота реализации. Простота всегда является целью проектирования.

-эффективность - экономия машинного времени и экономия памяти

Основные классы архитектур.

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

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

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

Пример: архитектура ОС системы THE (предложенная Дейкстрой):

0: обработка всех прерываний и выделение центрального процессора программам в пакетном режиме. Только этот уровень осведомлен о мультипрограммных аспектах системы.

1: управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная память.

2: связь с консолью оператора. Только этот слой знает технические характеристики консоли.

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

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

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

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

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

Шоу и Горлан предложили использовать каталог архитектурных стилей, в котором выделили:

1-независимые компоненты - взаимодействующие системы с событиями, неявный и явный вызов

2-поток данных - пакетно-последовательная архитектура (архитектура канала и фильтра)

3-обработка централизованных данных - хранилище и классная доска

4-виртуальная машина (интерпретаторы и ситемы с правилами)

5- вызов с возвратом (главная программа вызывает подпрограмму, объектно-ориентир, слоевые архитектуры)

В совокупности программные архитектуры описывают 4 структуры:

1. Логическая (концептуальная)

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

2. Модульная

Определяет организацию программноо средства как совокупности модулей

3. Процессная

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

4. Физическая

Определяет отображение элементов программного обеспечения на аппаратное

Кроме этих структур используются и другие:

5. Структура выходов

6. Структура потоков управления

7. Структура потоков данных

8.Структура использования

9.Структруа классов

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

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

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

1. Объектно-ориентированная методология.

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

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

2. Структурная методология.

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

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

3. Метод расширения ядра. Основное внимание уделяется выделению множества вспомогательных функций и модулей.

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

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

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

- размер

- прочность

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

- рутинность модуля.

Размер измеряется числом операторов или строк. Рекомендуется размер от нескольких десятков до нескольких сотен операторов.

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

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

2. функционально прочный;

3. Информационно прочный модуль – выполняет операции над одной и той же структурой данных (наивысшая степень прочности).

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

1. Худший вариант – сцепление по содержимому (один модуль имеет прямые ссылки на содержание другого модуля).

2. Сцепление по общей области (памяти).

3. Наилучшим видом сцепления является параметрическое сцепление (сцепление по данным).

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

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

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

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

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

Блочно-иерархический подход к программированию предполагает выделение и создание частей ПО и последующуюсборку из них программного объекта.

Основ. принципы подъода:

-непротиворечивость компонентов

-полнота без излишеств

-формализация

-повторяемость -необх-ть исп-я повторяемых блоков

-локальная оптимизация - оптимизация в пределах одного уровня локализации

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

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

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

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

Преобладают:

- структурная (функциональная: рассматривает структуру системы в терминах иерархии функций и передачи информации) и

- объектная (рассматривает структуру объектов связи между ними, а также поведение системы в терминах обмена сообщений между объектами)

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

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

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

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

Основные методы проектирования архитектуры - это

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

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

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

В обънетно-ориентированной методологии применяется

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

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

При техническом проектировании:

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

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

РЕАЛИЗАЦИЯ

РЕАЛИЗАЦИЯ - все процессы, направленные на воплощение технических решений этапа проектирования в программный код, включая сборку системы, с целью получения программного продукта в соответствии с техническим заданием.

Процессы реализации по ГОСТ 12.207:

1- программирование и тестирование программных средств

2- сбока программных средств

3- сборка системы

1-

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

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

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

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

Сборка программных средств завершается совместным анализом.

3. Сборка системы.

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

- Подготовить проведение квалификационных испытаний системы и обеспечить готовность к ним собранной системы.

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

Методы и технологии (на этапе реализации).

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

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

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

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

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

-низходящей разработки

-конструктивный

-архитектурный

Методы разработки структуры программы

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

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

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

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

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

Особенности:

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

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

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

Минусы:

- излишний объем программирования;

- неизвестность для тестируемого;

- непонятность глобальной задачи.

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

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

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

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

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

III. Конструктивный подход

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

IV. Архитектурный подход

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

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

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

Разновидности методов:

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

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

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

1. Статический контроль.

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

3. Сквозной контроль.

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

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

Достоинства стандартизации:

-единообразие позволяет избежать путиницы

-исключени произвольных параметров повышает точность

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

Недостатки:

-стандарты могут оказатся ограниченными или слишком громозкими для применения

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

Способы улучшения стиля делятся на:

1)универсальные -

--улучшения читаемости - комментарии:

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

---оглавление- включает название, размещение, ф-ию каждого программного модуля

---пояснительные - описание логики программы и изменения данных (10 строк кода - 1 комментарий), должны содержать дополнительную информацию.

Выделение комментариев осуществляют пустыми строками, спец. символами, либо в спец. выделенной колонке.

Кроме комментариев исп-ют пропуск строк, исп-е табуляции.

--оптимизация идентификаторов -

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

При поименовании файлов рекомендуется определенный префикс или суффикс.

Рекомендуется использовать стандартные сокращения (удал. глас букв, начало слова предпочтительнее, аббревиатура - менее 15 символов)

--оптимизация оформления

Исп-ют перенос, размещение операторов, упорядочение по алфавиту списков, отступы и др.

2) связанные с конкретными языками

Порядок разработки программного модуля:

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

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

3. Программирование (кодирование) модуля. При реализации должны быть учтены все требования, указанные в спецификации. Для получения удобочитаемого кода рекомендуется использовать принципы структурного программирования.

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

5. Поверка модуля. Ручная проверка внутренней логики модуля.

6. Компиляция. Получение исполняемого кода.

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

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

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

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

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

Сущность метода – разбиение процесса разработки текста модуля на ряд шагов:

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

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

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

1. Начало модуля, т.е. первое предложение или заголовок (спецификацию);

2. Раздел описаний на базовом языке (для процедур и функций – только их внешнее оформление);

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

4. Последнее предложение (конец).

Следование:

Обобщенный оператор 1

Обобщенный оператор 2

Разветвление:

Если условие, то

Обобщенный оператор

Иначе

Обобщенный оператор

ВСЕ ЕСЛИ

Повторение:

ПОКА условие ДЕЛАТЬ

Обобщенный оператор

ВСЕ ПОКА

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

Методы контроля:

1. Статическая проверка текста модуля.

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

3. Доказательство свойств программного модуля.

При проектировании модулей также используют:

• диаграммы сущность-связь;

• структурные карты;

• диаграммы Варнье-Орри;

• диаграммы переходов состояний;

• блок схемы;

• схемы экранов;

• псевдокод.

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

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

На основе структурной методологии для анализа требований проектирования могут быть применены следующие системы:

Silverrim Model Sphere

Oracle Designer

Erwin

ДРАКОН

CASE средства

На основе объектно-ориентированной методологии:

Rational Rose

Together Control Center

В процессе программирования – трансляторы.

Разновидности трансляторов: компиляторы, декомпиляторы, интерпретаторы.

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

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

Интерпретатор – непосредственное исполнение текста.

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

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

Существует ряд декомпиляторов:

Mocha, Crema, Sourse Tee Java Decompiler, Jad.

Помимо трансляторов применяются системы генерации трансляторов.

С точки зрения существующих алгоритмов все языки, порождающие грамматики делятся на 2 класса:

1. LL(n)

Анализаторы построены по принципу снизу-вверх: SYNTAX, DEPOT, LLGEN.

2. LR(n)

Анализаторы построены по принципу сверху-вниз: BISON, PSYACC.

Системы анализа корректности программного кода – близки к системам синтаксического анализа. Разрабатываются для языков со слабым контролем типов и выполняют большее количество проверок, чем стандартные анализаторы. К ним относятся: Lint, PCLint, FlereLint.

В связи с развитием программ декомпиляции существуют программы шифраторы.

(?)

усложнители декомпиляции:

- общее усложнение.

- целенаправленное усложнение (против конкретного декомпилятора).

Основная идея - в ухудшении кода

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

Пример: Make, GNUMake, Jmh.

Тестирование и отладка.

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

Функции тестирования:

Обнаружение ошибок.

Демонстрация соответствия функций программы ее назначению.

Демонстрация реализации требований к характеристикам программы.

Отображение надежности программного средства.

Информационные потоки тестирования можно представить следующим образом:

Рисунок.

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

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

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

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

Основные принципы тестирования:

1. Известные результаты тестирования.

2. Избегать тестирования автором

3. Необходимо изучить результаты каждого теста.

4. Проверять действие на неверных данных.

5. Проверять на неожиданные эффекты при побочных данных.

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

Процессы

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

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

2.Проводится тестирование каждого модуля и БД

3.Результаты тестирования оформляются документально

-квалификационные испытания программных средств:

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

2.Затем при необходимости уточняют документацию пользователя

3. Проект оценивается по критериям:

--тестового покрытия требований

--критерий соответствия ожидаемым результатам

--возможность сборки и тестирования системы

--возможность эксплуатации и сопровождения

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

-квалификационные испытания системы

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

Отладка.

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

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

Отладка = тестирование + поиск ошибок + их исправление.

Отладка – самый сложный этап создания ПО.

Сложность отладки обусловлена:

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

2. Психологический дискомфорт: поиск собственных ошибок в ограниченное время.

3. Возможно взаимовлияние ошибок в разных частях программы.

4. Отсутствие четко сформулированных методов отладки.

То есть при подготовке тестирования и отладки перед разработчиком возникает 2 задачи:

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

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

Виды ошибок.

По этапу обработки:

Ошибки компиляции.

Ошибки компоновки.

Ошибки выполнения.

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

2. Ошибки компоновки – ошибки обнаруженные компоновщиком при объединении модулей. Связаны с проблемами при разрешении внешних ссылок.

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

Причины появления ошибок выполнения:

1. Неверное определение исходных данных. Происходит, если возникают ошибки передачи, ошибки преобразования, ошибки перезаписи, ошибки данных, ошибки ввода-вывода.

2. Логические ошибки:

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

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

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

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

- неправильная реализация алгоритмов и др.

3. Ошибки накопления погрешности результатов числовых вычислений. Возникают при игнорировании ограничений разрядной сетки (отбрасывание сотых разрядов и др.).

Существуют другие классификации:

- ошибки общего вида.

- ошибки специального вида.

Отслеживание ошибок:

1. Ошибка должна быть зарегистрирована;

2. Выполнение первичного анализа.

3. Выявление причины ошибки.

4. Окончательный анализ ошибки.

5. Принятие решения о работе над исправлением ошибки.

6. Исправление ошибки.

7. Интегрирование исправления в основное пространство.

8. Подтверждение исправления ошибки.

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

1. По цели тестирования:

   1. выявления факта наличия ошибки.

   2. локализация ошибки, выявление причины.

   3. аттестация программного средства.

2. По виду программного документа, на основе которого строятся тесты:

   1. автономное: нисходящее, восходящее.

   2. комплексное:

      1. тестирование архитектуры.

      2. тестирование внешних функций.

      3. тестирование качества ПС.

      4. тестирование документации.

      5. определение требований.

3. По стратегии проектирования тестов:

   1. белого ящика.

   2. оптимальное (серого ящика).

   3. черного ящика.

4. По способу формирования наборов тестовых данных:

   1. детерминированное.

   2. случайное.

5. По направленности тестирования:

   1. статическое.

   2. динамическое.

6. По способу реализации:

   1. ручное

      1. инспекция исходных текстов;

      2. сквозные просмотры;

      3. проверка за столом;

      4. оценка правильности.

   2. выполнение

      1. тестирование маршрутов.

         1. покрытие операторов;

         2. покрытие решений;

         3. покрытие условий;

         4. покрытие решений/условий;

         5. комбинаторное покрытие циклов;

      2. тестирование потоков данных;

      3. Тестирование циклов

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

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

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

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

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

• возможность полной реализации плана тестирования.

Недостатки восходящего тестирования:

• тестовые данные готовятся не в той форме, которая рассчитана на пользователя (исключение – головной модуль).

• большой объем отладочного программирования.

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

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

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

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

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

Недостатки нисходящего тестирования:

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

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

Этапы автономного тестирования:

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

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

3. Проверка текста модуля с целью выявления наличия тестов для всех циклов и следующих ситуаций:

а) тело цикла не выполняется ни разу,

б) тело цикла выполняется 1 раз,

в) выполняется max число раз.

+ разработка недостающих тестов.

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

Комплексное тестирование.

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

Тестирование архитектуры.

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

Тестирование внешних функций.

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

Тестирование качества.

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

Тестирование документации по применению.

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

Тестирование определения требований к ПС.

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

Ручное тестирование.

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

Основными методами ручного контроля являются:

1. Инспекция исходных текстов.

2. Сквозные просмотры.

3. Проверка за столом.

4. Метод оценки программ.

1. Инспекция исходных текстов. Проводится группой специалистов, в которую входят: автор программы, проектировщик, специалист по тестированию и координатор (компетентный программист, но не автор программы).

Общая процедура инспекции:

1. Участникам группы заранее выдается листинг программы и спецификация на нее.

2. Программист рассказывает о логике работы программы и отвечает на вопросы инспекторов.

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

В группу таких вопросов могут входить:

- контроль обращения к данным: все ли переменные инициализированы, не превышается ли допустимый размер массивов и т. д.

- контроль вычислений: правильно ли записаны выражения, корректно ли выполняются вычисления над не арифметическими переменными.

- контроль передачи управления: при циклах, вызове модулей и т. п.

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

Инспекция является способом раннего выявления частей программы с большой вероятностью содержания ошибок.

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

Процедуры сквозного просмотра:

1. Участникам выдают листинг программ и спецификацию на нее.

2. Участники предлагают ряд тестов.

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

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

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

Процесс оценки включает:

1. Выбор администратора процесса, который создает группу из 6 – 20 участников, занимающихся разработкой сходных программ.

2. Каждому участнику предлагается представить для рассмотрения 2 программы подобного назначения: наилучшую и наихудшую.

3. Отобранные программы случайным образом распределяются между участниками (по 4 на каждого: 2 наилучшие, 2 наихудшие).

4. Программист просматривает программы и заполняет анкету, в которой оценивает качество программы по 7-ми бальной шкале.

Структурное тестирование (тестирование по маршрутам).

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

Недостатки:

• невозможно исчерпывающее тестирование маршрутов;

• не позволяет обнаружить пропущенные маршруты;

• не позволяет выявить ошибки, зависящие от обрабатываемых данных;

• не дает гарантии, что программа правильна.

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

На основе анализа этого графа составляются наборы тестовых данных по следующим критериям:

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

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

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

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

Для данной задачи:

1. a = 2, b = 0, x = 4

Путь 1-2-3-4-5-6

Условия 1)да 2)да 3)да 4)да

2. a = 1, b = 1, x = 1

Путь 1-2-4-6

Условия: 1)нет 2)нет 3)нет 4)нет

5. Комбинаторное покрытие условий. Требует создания множества тестов, чтобы все возможные комбинации результатов условий в каждом решении и все операторы выполнялись по крайней мере 1 раз.

Для этого примера:

В данном случае четырем тестам соответствуют пути (это совпадение).

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

Особенности потокового графа

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

1. Граф стоится отображением управляющей структуры программы.

2. Узлы (вершины) соответствуют линейным участкам программы (один или несколько операторов).

3. Дуги отображают поток управления.

4. Различают операторные и предикатные узлы (1 и 2 дуги соответственно на выходе).

5. Предикатные узлы соответствуют простым условиям в программе. Составные – несколько предикатных узлов.

6. Замкнутые области, образованные несколькими дугами и узлами, называются регионами.

7. Окружающая граф среда рассматривается как дополнительный регион (R₁…R_n).

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

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

Независимые пути:

1-8

1-2-3-7а-7б-1-8

1-2-4-5-7а-7б-1-8

1-2-4-6-7а-7б-1-8

Способы вычисления цикломатической сложности:

1. Она равна количеству регионов потокового графа (R=4).

2. Определяется по формуле V(G) = E – N +2, где Е – количество дуг, N – количество узлов (V(G) = 11 – 9 + 2 = 4).

3. Определяется по формуле V(G) = p + 1, где p – количество предикатных узлов.

Тестирование потоков данных.

Анализируется информационная структура программы.

1. В (1) определяем значения переменных a, b;

2. Значение a используем в вершине (4), значение b – в (3) и (6)

3. В (4) определяется значение c, которое используется в (6)

Тестируются также циклы, набор тестов может обеспечить:

1. прогон всего цикла.

2. гарантированный один проход цикла.

3. два прохода цикла.

4. n проходов цикла.

Функциональное тестирование (тестирование черного ящика).

Проверяется поведение программы и ее соответствие спецификации.

Методы формирования тестовых наборов:

1. Эквивалентное разбиение. Область всех возможных наборов входных данных по каждому параметру разбивают на конечное число групп – классов эквивалентности. Наборы данных такого класса определяют по принципу обнаружения одних и тех же ошибок. Например, если X может быть ≥ 1 и ≤ 999, то 3 класса: один правильный (1≤ X ≤999) и 2 неправильных (X < 1 и X > 999). То есть при выборе классов перебирают ограничения, установленные для каждого входного значения в ТЗ или спецификации.

   Ограничения на значения	Правильные классы	Неправильные классы

2. Анализ граничных условий. Граничные – значения на границах классов эквивалентности входных значений или около них. Правила применения:

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

   2. Если входное условие удовлетворяет дискретному ряду, то требуются тесты для min и max значений и значений чуть больше.

   3. Если существуют ограничения выходных значений, то целесообразно аналогичным образом тестировать и их.

   4. Для упорядоченных множеств следует сосредоточить внимание на 1 или последнем элементе множества.

3. Анализ причинно следственных связей. Используется алгебра логики.

Причина – отдельное входное условие или класс эквивалентности.

Следствие – выходное условие или преобразование подсистем.

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

Построение тестов:

• строят таблицы причинно следственных связей при применении метода к спецификации.

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

• Каждую строку таблицы преобразуют в тест.