ekz-puch
.pdf
1
Оглавление |
|
1.Программная инженерия. Понятия программных средств (ПС) и информационной |
|
технологии. CASE-технология. Принципы разработки ПС. ................................................. |
2 |
2.Модели жизненного цикла ПС.............................................................................................. |
2 |
3. Анализ требований и определение спецификации ПС. Требования к спецификации |
|
ПС. Формальные модели предметной области. ..................................................................... |
3 |
4.Методология IDEF0. Функциональные диаграммы: назначение, правила разработки, |
|
пример составления. Количественный анализ функциональных диаграмм. ...................... |
4 |
5.Методика составления календарного плана. Пример составления плана. ....................... |
5 |
6. Стандарты и методики. Виды и группы стандартов. ......................................................... |
6 |
7.Методика Oracle CDM и ее особенности. Международный стандарт ISO/IEC |
|
12207:1995-08-01, его структура, особенности. ..................................................................... |
7 |
8.Стандарты ГОСТ 34, ГОСТ Р. Общая характеристика ЕСПД. Достоинства и |
|
недостатки ЕСПД. Содержание технического задания и описание программы по ЕСПД. |
|
..................................................................................................................................................... |
8 |
9.Виды программ и программных документов. Виды эксплуатационных документов. |
|
Обозначение программ и программных документов. Стадии разработки ПС в |
|
соответствии с ЕСПД. ............................................................................................................... |
9 |
10. Правила оформления пояснительной записки по ГОСТ 7.32-2001. Рекомендации по |
|
стилю изложения материала................................................................................................... |
10 |
11.Профили открытых информационных систем. Принципы формирования и группы |
|
профилей. ................................................................................................................................. |
15 |
12. Показатели качества ПС. Объекты уязвимости. Дестабилизирующие факторы. ....... |
17 |
13.Основные понятия надежности. Стандарт ССНТ. Показатели надежности |
|
восстанавливаемых и невосстанавливаемых систем и их. статистическое определение.18 |
|
14.Методы обеспечения надежности на разных этапах жизненного цикла |
|
вычислительных систем.......................................................................................................... |
20 |
15.Выбор показателей надежности........................................................................................ |
21 |
16.Математические модели надежности ПС. Зависимость надежности от времени. ...... |
22 |
Прогнозирующие модели ........................................................................................................... |
22 |
17.Способы обеспечения и повышения надежности ПС. Методы введения структурной |
|
избыточности. Дуальное, N-версионное и модифицированное дуальное |
|
программирование................................................................................................................... |
23 |
Многоверсионное программирование Концепция многоверсионного программирования.23 |
|
18.Повышение надежности ПС с помощью избыточности ОС. Метод контрольных |
|
функций. ................................................................................................................................... |
24 |
Метод контрольных функций. ................................................................................................... |
24 |
19.Тестирование ПС. Стратегии тестирования. Виды тестирования. Аксиомы |
|
тестирования. ........................................................................................................................... |
25 |
20.Протоколы тестирования. Отчет о тестировании. .......................................................... |
26 |
21.Понятие рынка ПС. Сертификация ПС. ........................................................................... |
27 |
22.Модели качества процессов конструирования. ............................................................... |
28 |
23. Основные направления интеллектуализации ПС. Упреждающие компьютеры......... |
29 |
24.Адаптивное и адаптируемое программное обеспечение. Общая характеристика |
|
состояния. ................................................................................................................................. |
30 |
2
1.Программная инженерия. Понятия программных средств (ПС) и информационной технологии. CASE-технология. Принципы разработки ПС.
Программная инженерия (англ. software engineering) — приложение систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению (ISO/IEC/IEEE 24765:2017)
CASE - Computer Aided Software Engineering (CASE) - это система автоматизированной разработки программного обеспечения [4, 16 - 18].
CASE-средства это совокупность методов и способов проектирования и разработки программ с помощью автоматизированных инструментов, которые ориентированы на реализацию отдельных процессов ЖЦ для разных предметных областей. На первых порах их появления сложились специальные CASE-пакеты для военных, коммерческих и др. применений. Среди таких средств были такие:
1)ассемблеры, анализаторы, компиляторы, интерпретаторы;
2)символические отладчики, пакеты программ;
3)анализа гребований и систем;
4)редактирование, интеграция текстов и генерация отдельных программ поддержки операций ЖЦ.
2.Модели жизненного цикла ПС.
Модель ЖЦ ПС – это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь программы от установления требований к ней до прекращения ее использования.
Модели ЖЦ ПС несколько отличаются терминологией и графическим представлением этапов и их взаимодействия. Однако во всех отражен ряд базовых этапов, к которым присоединяются или из которых выделяются другие этапы, характеризующиеся менее четкими целями.
Наиболее известными являются:
-каскадная модель,
3
-эволюционная модель,
-модель формальной разработки,
-модель разработки на основе ранее созданных компонентов,
-итерационные модели.
Каскадная модель - реализует принцип однократного выполнения каждого вида деятельности в виде заранее ограниченных и однозначно упорядоченных во времени стадий и этапов, осуществляемых как бы в их естественных границах. В обобщенной каскадной модели выделяют 8 этапов:
На первом этапе путем консультаций с заказчиком определяются цели и функции, а также ограничения на создаваемое ПС.
На этапе предварительного (эскизного) проектирования вырабатываются требования к аппаратным средствам и программному обеспечению, разрабатывается архитектура программы.
При детальном проектировании подробно описываются компоненты ПС и их взаимосвязи.
На следующей стадии архитектура ПС реализуется в виде множества разработанных и отлаженных программных единиц.
Далее отдельные программы интегрируются и тестируются в виде целостной системы.
Затем ПС сопровождается документами и передается в эксплуатацию.
3. Анализ требований и определение спецификации ПС. Требования к спецификации ПС. Формальные модели
предметной области.
Требования к ПС являются исходным документом для разработки внешнего описания ПС - спецификации требований.
Разработка ПС начинается с этапа формулирования требований к ПС, на котором, исходя из довольно смутных пожеланий заказчика, должен быть получен документ, достаточно точно определяющий задачи разработчиков ПС.
Спецификация требований играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Более того,
4
оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС.
Спецификация требований является исходным документом для трех параллельно протекающих процессов:
разработки текстов (и кодированию) программ, входящих в ПС,
разработки документации по применению ПС и
разработки существенной части комплекта тестов для тестирования ПС.
Ошибки и неточности в спецификации требований трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три параллельных процесса. Это требует особенно серьезных мер по их предупреждению.
Спецификация требований содержит две самостоятельные части:
Функциональная спецификация ПС описывает поведение ПС, то есть перечисляет функции, которые должна выполнять ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции.
Спецификация качества ПС определяет цели разработки ПС. Спецификация качества, в отличие от функциональной спецификации, реализуется неформализованно и играет роль
ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ разрабатываемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС.
4.Методология IDEF0. Функциональные диаграммы: назначение, правила разработки, пример составления. Количественный анализ функциональных диаграмм.
IDEF0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).[1]
5
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.
По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении(например, «производить услуги»).
На диаграмме функциональный блок изображается прямоугольником (рис.). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input);
правая сторона имеет значение «Выход» (Output);
нижняя сторона имеет значение «Механизм» (Mechanism).
5.Методика составления календарного плана. Пример составления плана.
Содержание и методы построения календарных графиков, безусловно, зависят от того, для какой задачи и в какой отрасли они используются. Производство металлоконструкций и проект по разработке сайта авиакомпании – совершенно разные задачи, и для всех из них существует наиболее подходящий метод построения календарного плана.
Чтобы построить реальный календарный план необходимо привлечь к его составлению руководителей подразделений, задействованных в проекте, либо экспертов.
Рассмотрим наиболее популярные и простые в применении методы построения календарных графиков.
Табличный план-график
6
Ленточный график Ганта (Gantt chart)–
Это гистограмма, длина столбиков которой пропорциональна продолжительности выполнения операций. Существуют две разновидности графика Ганта, которые отображают загрузку производственных мощностей и сроки выполнения производственных заданий
Цикловые графики
Строятся в последовательности, обратной ходу какого-либо циклического процесса. Графики по нескольким циклическим процессам соединяются в общий – консолидированный график выполнения задачи
Объемно-календарный график
В отличие от статического циклового (календарного) позволяет увязать желаемые сроки выполнения заказов с полноценной загрузкой производственных подразделений на всех стадиях производства. Этот объемно-календарный график, кроме решения чисто плановых задач, позволяет вести активный контроль и регулирование хода производства для удержания производственного процесса в плане-графике (рис.4).
6. Стандарты и методики. Виды и группы стандартов.
Виды стандартов
Существующие на сегодняшний день стандарты можно несколько условно разделить на несколько групп по следующим признакам:
7
по предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования информационных систем и программного обеспечения;
по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандарты (например, ГОСТы, ANSI, IDEFO/1), стандарты международных консорциумов и комитетов по стандартизации (например, консорциума OMG), стандарты «дефакто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например,
Microsoft ODBC);
по методическому источнику. К этой группе относятся различного рода методические материалы ведущих фирм-разработчиков программного обеспечения, ' -,' 1фйрм-консультантов, научных центров, консорциумов по стандартизации.
Ниже мы рассмотрим следующие стандарты и методики, касающиеся организации жизненного цикла информационных систем и программного обеспечения:
методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ;
международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла продуктов программного обеспечения;
отечественный комплекс стандартов ГОСТ 34.
7.Методика Oracle CDM и ее особенности. Международный стандарт ISO/IEC 12207:1995-08-01, его
структура, особенности.
Методика Oracle CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях - Designer/2000).
8
Эта методика возникла как развитие разработанной версии Oracle
CASE-Method (Custom Development Method), известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р.
Баркера. CDM теснейшим образом опирается на использование инструментария Oracle.
Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:
методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов;
поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта;
ориентация на реализацию приложений в архитектуре клиентсервер с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;
Методика CDM выделяет следующие процессы:
-RD - Определение производственных требований,
-ES - Исследование существующих систем,
-TA - Определение технической архитектуры,
-DB - Проектирование и построение БД,
-MD - Проектирование и реализация модулей,
-CV - Конвертирование данных,
-DO - Документирование,
-TE - Тестирование,
-TR - Обучение,
-TS - Переход к новой системе,
-PS - Поддержка и сопровождение.
8.Стандарты ГОСТ 34, ГОСТ Р. Общая характеристика ЕСПД. Достоинства и недостатки ЕСПД. Содержание технического задания и описание программы
по ЕСПД.
ГОСТ 34, который должен фиксировать результаты проведенных работ. Жизненный цикл процесса создания АСУ согласно ГОСТ 34 (ГОСТ 34.601-90) включает следующие стадии: Формирование требований к АС Разработка
9
концепции АС Техническое задание Эскизный проект Технический проект Рабочая документация Ввод в действие Сопровождение АС
Формирование требований к АС На начальном этапе создания АС согласно требованиям ГОСТ 34 необходимо проведение обследования объекта автоматизации. В рамках обследования происходит сбор и анализ данных об организации, производственной структуре и функционировании объекта автоматизации.
Разработка концепции АС Исходя из результатов, проведенных исследований объекта автоматизации, согласно ГОСТ 34 разрабатывается несколько вариантов концепций АС, удовлетворяющих требованию пользователей. Концепции АС могут быть представлены заказчику в виде отчета о выполненных работах, или отдельного документа «Концепция АС», или стать частью аналитического отчета
Эскизный и технический проект В данной статье мы объединяем два этапа жизненного цикла разработки АС по ГОСТ 34 всвязи с аналогичностью проводимых работ. На данных этапах происходит разработка проектных решений АС и создание технической документации
Сопровождение АС Этап сопровождения АС подразумевает выполнение работ по гарантийному и послегарантийному обслуживанию систем
9.Виды программ и программных документов. Виды эксплуатационных документов. Обозначение программ и
программных документов. Стадии разработки ПС в соответствии с ЕСПД.
Согласно ГОСТ 19.101 77 «Виды программ и программных документов» программы делятся на компоненты и комплексы. Компонент это программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. Комплекс это программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.
Указанный стандарт определяет в качестве программных документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программы. Все документы делятся на две группы: программные (таблица1) и эксплуатационные (таблица 2).
Вид программного документа |
Содержание программного документа |
|
|
Спецификация |
Состав программы и документации на нее |
|
|
Ведомость держателей подлинников |
Перечень предприятий, на которых хранят подлинники |
|
программных документов |
|
|
Текст программы |
Запись программы с необходимыми комментариями |
|
|
Описание программы |
Сведения о логической структуре и функционировании |
|
|
|
10 |
|
|
|
|
|
|
|
|
программы |
|
|
|
|
|
Программа и методика испытаний |
|
Требования, подлежащие проверке при испытании |
|
|
|
программы, а также порядок и методы их контроля |
|
|
|
|
|
Техническое задание |
|
Назначение и область применения программы, |
|
|
|
технические, технико-экономические и специальные |
|
|
|
требования, предъявляемые к программе, |
|
|
|
необходимые стадии и сроки разработки, виды |
|
|
|
испытаний |
|
|
|
|
|
Пояснительная записка |
|
Схема алгоритма, общее описание алгоритма и (или) |
|
|
|
функционирования программы, а также обоснование |
|
|
|
принятых технических и технико-экономических |
|
|
|
решений |
|
|
|
|
|
|
|
|
|
|
|
||
Вид документа |
Содержание документа |
||
|
|
||
Ведомость эксплуатационных |
Перечень эксплуатационных документов на программу |
||
документов |
|
|
|
|
|
||
Формуляр |
Основные характеристики программы, комплектность и |
||
|
сведения об эксплуатации программы |
||
|
|
||
Описание применения |
Сведения о назначении программы, области применения, |
||
|
применяемых методах, классе решаемых задач, |
||
|
ограничениях на применение, минимальной конфигурации |
||
|
технических средств |
||
|
|
||
Руководство системного |
Сведения для проверки, обеспечения функционирования и |
||
программиста |
настройки программы на условия конкретного применения |
||
|
|
||
Руководство программиста |
Сведения для эксплуатации программы |
||
|
|
||
Руководство оператора |
Сведения для обеспечения процедуры общения оператора с |
||
|
вычислительной системой в процессе выполнения |
||
|
программы |
||
|
|
||
Описание языка |
Описание синтаксиса и семантики языка |
||
|
|
||
Руководство по техническому |
Сведения для применения тестовых и диагностических |
||
обслуживанию |
программ при обслуживании технических средств |
||
|
|
|
|
10. Правила оформления пояснительной записки по ГОСТ 7.32-2001. Рекомендации по стилю изложения
материала.
Пояснительная записка может быть выполнена одним из следующих способов: