Технология разработки программного обеспечения
Определение технологии конструирования программного обеспечения (ПО).
Классический жизненный цикл.
Макетирование, инкрементная модель, быстрая разработка приложений.
Модели качества процессов конструирования.
Процесс руководства проектом.
Планирование проектных задач.
Размерно-ориентированные метрики.
Функционально-ориентированные метрики.
Выполнение оценки проекта на основе LOC- и FP метрик.
Классические методы анализа.
Структурный анализ.
Диаграммы потоков данных и их описание. - http://poznayka.org/s19868t1.html
Методы анализа, ориентированные на структуры данных.
Основы проектирования и его особенности, структурирование системы, модульность.
Виды связности модулей.
Сцепление модулей.
Понятие сложности программной системы.
Метод структурного проектирования.
Типы информационных потоков (преобразование, запрос).
Метод проектирования Джексона. - http://lektsii.com/2-19268.html
http://elab.pro/pluginfile.php/999/mod_resource/content/1/06.%20Лекция.%20Проектирование.pdf
https://studfiles.net/preview/1444532/page:31/
Унифицированный язык моделирования (UML).
Модели реализации объектно-ориентированных программных систем. Компонентные диаграммы и их использование.
Автоматизация конструирования визуальной модели программных систем.
Определение технологии конструирования программного обеспечения (ПО).
Технология конструирования программного обеспечения (ТКПО)-система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.
Термин «конструирование программного обеспечения» описывает детальное создание рабочей программной системы посредством комбинации кодирования, верификации (проверки), модульного тестирования, интеграционного тестирования и отладки.
Данная область знаний связана с другими областями. Наиболее сильная связь существует с проектированием (Software Design) и тестированием (Software Testing). Причиной этого является то, что сам по себе процесс конструирования программного обеспечения затрагивает важные аспекты деятельности по проектированию и тестированию. Кроме того, конструирование отталкивается от результатов проектирования, а тестирование (в любой своей форме) предполагает работу с результатами конструирования. Достаточно сложно определить границы между проектированием, конструированием и тестированием, так как все они связаны в единый комплекс процессов жизненного цикла и, в зависимости отвыбранной модели жизненного цикла и применяемых методов (методологии), такое разделение может выглядеть по-разному.
Различают: методы, средства и процедуры ТКПО.
Методы обеспечивают решение задач:
планирования и оценки проекта;
анализа системных и программных требований;
проектирования алгоритмов, структур данных и программных структур;
кодирования;
тестирования;
сопровождения.
Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов
Процедуры–соединяют методы и средства в непрерывную технологическую цепь разработки.
Процедуры определяют:
порядок применения методов и средств;
формирование отчетов в соответствии с требованиями;
контроль качества и координирование изменений;
формирование “вех” (промежуточных этапов) для оценки прогресса.
Таким образом, процесс конструирования ПО состоит из последовательности шагов, использующих:
методы;
утилиты;
процедуры.
Классический жизненный цикл.
Очень часто классический жизненный цикл называют каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе. К тому же этапы идут один за одним. Начав один этап, мы не можем вернуть назад
Жизненный цикл ПО:
Анализ
Проектирование
Разработка
Тестирование
Развёртывание
Использование
Эмпирический закон:
30% - анализ и проектирование
40% - реализация проекта
30% - откладка и тестирование
Задачи этапа анализа: Составление списка требований к разрабатываемой системе и среде её функционирования. (должны понять, для кого мы должны создать ПО, для специалистов или для широкого круга пользователей, должны понять, к какой платформе мы создаём ПО и т.д)
Ранжировать список требований: реализовать первоочередные требования. Так же выявить несовместимые требования (Например, чтоб одновременно компьютер не был подключён к сети и показывал прогноз погоды в браузере).
Задачи этапа проектирования: Фиксируются методы и методики, используемые для реализации намеченной функциональности, фиксируются необходимые для реализации проекта технологии, определяется состав оборудования, определяется необходимость прототипирования отдельных модулей системы, составления финансового и календарного плана.
Этап разработки:
Проектирование структуру ПО – структуры классов, структуру данных и т.д.
Проектирование интерфейса
Проектирования структуры документации
Тестирование – это, посвящённый обнаружению и устранению ошибок, однако уровень качества проекта закладывается в процессе разработки.
Сопровождение – это внесение изменений в эксплуатируемое
ПО, а так же
Обучение пользователей
Информационная поддержка пользователей
Служба технической поддержки
Создание новых версий ПО
Плюсы:
Позволяет предсказать затраты на проект
Управляемость проекта
Чёткие сроки сдачи
Минусы:
Минусы:
Отсутствие гибкости (может измениться внешняя среда, требования заказчика, могут быть обнаружены ошибки в анализе)
Получается задуманная, а не необходимая система
Макетирование, инкрементная модель, быстрая разработка приложений.
Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемое™ продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования — снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.
Основная цель макетирования – снять неопределённости в требованиях заказчика. Макетирование (прототипирование) – это процесс создания моделитребуемого программного продукта. Модель может принимать одну из трёх форм: 1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); 2) работающий макет (выполняет некоторую часть требуемых функций); 3) существующая программа (характеристики которой затем должны быть улучшены). Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нём внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования: - заказчик может принять макет за продукт; - разработчик может принять макет за продукт. Инкрементная модель является классическим примером инкремент-ной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновкистраницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики ифункциональность. По своей природе инкрементный процесс итеративен, но в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.
Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования, концепция, созданная для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня
Принципы RAD технологии направлены на обеспечение трёх основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.
Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки
RAD-технология не является универсальной, то есть её применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод).
Модели качества процессов конструирования.
В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model — СММ) Института программной инженерии при американском университете Карнеги-Меллон.
Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.
Базовым понятием модели СММ считается зрелость компании [61], [62]. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.
Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения.
Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.
Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости (рис. 1.9) и предусмотрен плавный, поэтапный подход к совершенствованию процессов — можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.
Рис. 1.9. Пять уровней зрелости модели СММ
Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.
Для перехода на повторяемый уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов.
Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.
С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.
Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.
Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:
предотвращения дефектов;
управления изменениями технологии;
управления изменениями процесса.
Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.
Процесс руководства проектом.
Руководство программным проектом является защитной деятельностью программной инженерии, пронизывающей все виды основной деятельности – подготовку, планирование, моделирование, контруирование и развёртывание.
Цель любого программного проекта состоит в производстве определённого программного продукта. Понятие «продукт» задаёт не только текст на языки программирование и откомпилированный двоичный код. Например, туда включаются документация, отчёты по промежуточным итогам, результат проверок, оценки качества и и т.д.
Персонал должен быть организован как эффективная команда, в которой обеспечено эффективное взаимодействие и которая мотивирована на выполнение работы с высоким качеством. Требования к продукту должны быть переданы (без искажений) от заказчика к разработчикам, правильно разбиты на части и распределены для обработки между инженерами команды. Процесс должен быть адаптирован как к персоналу, так и к продукту. Должна быть правильно сконфигурирована среда для выполнения процесса, разумно выбран такой набор рабочих задач, который гарантирует оптимальную загрузку персонала. Наконец, организация проекта должна быть нацелена на успешную работу команды
Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ.