- •Технология программирования, основные этапы развития: «стихийное» программирование, структурное программирование, объектно-ориентированное программирование, компонентное программирование.
- •Особенности функционирования сложных программных средств: работа в реальном времени, многообразие функций, надежность функционирования.
- •Проблемы проектирования сложных программных средств: рациональное структурное построение, технология разработки, стандартизация; блочно-иерархический подход.
- •Жизненный цикл программного обеспечения, процессы жизненного цикла, связь между процессами.
- •Основные процессы жизненного цикла: приобретение, поставка, разработка, эксплуатация, сопровождение.
- •Вспомогательные процессы жизненного цикла: документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем.
- •Организационные процессы жизненного цикла: управление, создание инфраструктуры, усовершенствование, обучение.
- •Модели жизненного цикла: поэтапная, каскадная, спиральная, переиспользования и реверсивной инженерии.
- •Способ быстрой разработки приложений (rad): условия применения, стадии жизненного цикла, достоинства и недостатки.
- •Определение метода и технологии
- •Требования к технологии
- •Оценка качества процессов создания программного обеспечения: международные стандарты серии iso 9000, cmm, spice.
- •Понятийный аппарат метрической теории программ – принципы количественного анализа качества объектов с расплывчатыми свойствами.
- •Модель и метрики оценки сложности Боэма.
- •Модель и метрики оценки сложности Холстэда.
- •Модель и метрики оценки сложности Мак-Кейба (основанные на потоковых графах).
- •Модель и метрики, основанные на информационных потоках.
- •Методы оценки качества программного обеспечения: анкетирование, рабочие списки, контрольные задачи, метрики. Государственные стандарты в области оценки качества программного обеспечения.
- •Модули, сцепление и связность - критерии независимости модулей, библиотеки ресурсов.
- •Программирование с защитой от ошибок: проверка выполнения операций, контроль промежуточных результатов, снижение погрешностей результатов, обработка исключений; сквозной структурный контроль.
- •Технологические требования: выбор архитектуры по, выбор типа пользовательского интерфейса, выбор подхода к разработке, выбор языка и среды программирования.
- •Планирование процесса проектирования, виды планов: календарный, индивидуальный, сетевой график разработки и проектирования программного обеспечения.
- •4.2. Функции программного обеспечения для календарного планирования
- •4.3. Виды календарного планирования (календарные графики, диаграммы Гантта)
- •Спецификации по при структурном подходе: формальные модели, зависящие от подхода к разработке и не зависящие от подхода – диаграммы переходов состояний, математические модели предметной области.
- •2.2.5 Границы моделирования
- •2.2.6 Выбор наименования контекстного блока
- •2.2.8 Нумерация блоков и диаграмм
- •1.1.1 I Модели idef3
- •1.1.2 Диаграммы
- •1.1.3 Единица работы. Действие
- •1.1.4 Связи
- •1.1.5 Соединения
- •1.1.6 Указатели
- •1.1.7 Декомпозиция действий
- •Построение моделей idef3: диаграммы, нумерация блоков и диаграмм, сценарий, границы моделирования, определение действий и объектов.
- •1.2.2 Определение действий и объектов
- •1.2.3 Последовательность и параллельность
- •3.2 Синтаксис и семантика диаграмм потоков данных
- •3.2.1 Функциональные блоки
- •3.2.2 Внешние сущности
- •3.2.4 Хранилища данных
- •3.2.5 Ветвление и объединение
- •3.3.2 Нумерация объектов
- •Структуры данных: несвязанные, с неявными связями, с явными связями; иерархические модели Джексона-Орра.
- •Моделирование данных – диаграммы «сущность-связь» (erd): сущность, связь, атрибут.
- •Метод Баркера.
- •Метод idef1.
Способ быстрой разработки приложений (rad): условия применения, стадии жизненного цикла, достоинства и недостатки.
Разработка спиральной модели жизненного цикла программного обеспечения и CASE-
технологий позволили сформулировать условия, выполнение которых сокращает сроки создания
программного обеспечения.
Современная технологии проектирования, разработки и сопровождения программного
обеспечения, должна отвечать следующим требованиям:
• поддержка полного жизненного цикла программного обеспечения;
• гарантированное достижение целей разработки с заданным качеством и в установленное время;
• возможность выполнения крупных проектов в виде подсистем, разрабатываемых группами
исполнителей ограниченной численности (3-7 человек) с последующей интеграцией составных
частей, и координации ведения общего проекта;
• минимальное время получения работоспособной системы;
• возможность управления конфигурацией проекта, ведения версий проекта и автоматического
выпуска проектной документации по каждой версии;
• независимость выполняемых проектных решений от средств реализации (СУБД, операционных систем, языков и систем программирования);
• поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.
Этим требованиям отвечает технология RAD (Быстрая разработка приложений). Эта технология ориентирована на максимально быстрое получение первых версий разрабатываемого программного обеспечения. Она предусматривает выполнение следующих условий:
• ведение разработки небольшими группами разработчиков (3-7 человек), каждая из которых
проектирует и реализует отдельные подсистемы проекта - позволяет улучшить управляемость
проекта;
• использование итерационного подхода способствует уменьшению времени получения
работоспособного прототипа;
• наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца,
существенно увеличивает эффективность работы.
Процесс разработки при этом делится на следующие этапы: анализ и планирование
требований пользователей, проектирование, реализация, внедрение.
На этапе анализа и планирования требований формулируют наиболее приоритетные
требования, что ограничивает масштаб проекта.
На этапе проектирования, используя имеющиеся CASE-средства, детально описывают
процессы системы, устанавливают требования разграничения доступа к данным и определяют
состав необходимой документации. При этом для наиболее сложных процессов создают
частичный прототип: разрабатывают экранную форму и диалог. По результатам анализа процессов определяют количество так называемых функциональных точек и принимают решение о количестве подсистем и, соответственно, команд, участвующих в разработке.
Под функциональной точкой в технологии RAD понимают любой из следующих
функциональных элементов разрабатываемой системы:
• входной элемент приложения (входной документ или экранная форма);
• выходной элемент приложения (отчет, документ или экранная форма);
• запрос (пара «вопрос/ответ»);
• логический файл (совокупность записей данных, используемых внутри приложения);
• интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Нормы, рассчитанные исходя из экспертных оценок, для систем со значительной повторяемостью кодов определяются следующим образом:
• менее 1 тыс. функциональных точек- 1 человек;
• от 1 до 4 тыс. функциональных точек - одна команда разработчиков;
• более 4 тыс. функциональных точек - одна команда на каждые 4 тыс. точек.
В соответствии с этими нормами разрабатываемую систему делят на подсистемы, слабо
связанные по данным и функциям, и точно определяют интерфейсы между различными частями.
Использование CASE-средств при этом позволяет избежать неконтролируемого искажения
данных при передаче информации о проекте со стадии на стадию.
Далее разработка ведется группами разработчиков, которые продолжают прорабатывать свои части системы. Действия различных групп разработчиков при этом должны быть хорошо
скоординированы.
На этапе реализации выполняют итеративное построение реальной системы, причем при этом для контроля над выполнением требований к создаваемой системе привлекаются будущие
пользователи. Части постепенно интегрируют в систему, причем при подключении каждой части выполняют тестирование. На завершающих этапах разработки определяют необходимость создания соответствующих баз данных, которые разрабатываются и подключаются к системе. Далее формулируют требования к аппаратным средствам, устанавливают способы увеличения производительности и завершают подготовку документации по проекту.
На этапе внедрения проводят обучение пользователей и осуществляют постепенный переход на новую систему, причем эксплуатация старой версии продолжается до полного внедрения новой системы.
Технология RAD хорошо зарекомендовала себя для относительно небольших проектов, разрабатываемых для конкретного заказчика. Такие системы не требуют высокого уровня
планирования и жесткой дисциплины проектирования. Однако эта технология не применима для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, т. е. программ с большим процентом уникального кода. Не годится она и в случае создания приложений, от которых зависит безопасность людей, например, систем управления самолетами или атомными электростанциями, так как технология RAD предполагает, что первые несколько версий не будут полностью работоспособны, что в данном случае полностью исключается.
Метод и технология проектирования программного обеспечения, требования к технологии, формализация и автоматизация стадий и этапов жизненного цикла, стандартизация процесса проектирования и разработки: стандарт проектирования, стандарт оформления проектной документации, стандарт интерфейса пользователя, государственные стандарты, стандарты предприятия. Эволюция методов и средства программной инженерии.
Основные определения (система понятий, описывающих ТС ПО)
Технология создания ПО — упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.
Технологический процесс — совокупность взаимосвязанных технологических операций.
Технологическая операция — основная единица работы, выполняемая определенной ролью, которая:
• подразумевает четко определенную ответственность роли;
• дает четко определенный результат (набор рабочих продуктов), базирующийся на определенных исходных данных (другом наборе рабочих продуктов);
• представляет собой единицу работы с жестко определенными границами, которые устанавливаются при планировании проекта.
Рабочий продукт — информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией.
Роль — определение поведения и обязанностей отдельного лица или группы лиц в среде организации-разработчика ПО, осуществляющих деятельность в рамках некоторого технологического процесса и ответственных за определенные рабочие продукты.
Руководство — практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.
Инструментальное средство (CASE-cpedcmeo) — программное средство, обеспечивающее автоматизированную поддержку деятельности, выполняемой в рамках технологических операций.
Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.). Согласно этим нормативам ТС ПО должна поддерживать следующие процессы:
• управление требованиями;
• анализ и проектирование ПО;
• разработка ПО;
• эксплуатация;
• сопровождение;
• документирование;
• управление конфигурацией и изменениями;
• тестирование;
• управление проектом.
Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств).
Соответствие стандартам означает также, в частности, использование общепринятых, стандартных нотаций и соглашений. Для того чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение проектных стандартов ставит разработчиков в зависимость от фирмы — производителя данного средства, делает затруднительным формальный контроль корректности проектных решений и снижает возможности привлечения дополнительных
коллективов разработчиков, смены исполнителей и отчуждения проекта, поскольку число специалистов, знакомых с данным методом (нотацией), может быть ограниченным.
Другим важным требованием является адаптируемость к условиям применения, которая достигается за счет поставки технологии в электронном виде вместе с CASE-средствами и библиотеками процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии должны включать средства, обеспечивающие их адаптацию и развитие по результатам выполнения конкретных проектов. Процесс адаптации заключается в удалении ненужных процессов и действий ЖЦ ПО, в изменении неподходящих или в добавлении собственных процессов и действий, а также методик, стандартов и руководств.