Вопрос2 (не знаю то или не то)

Билет1

Вопрос1

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

 

Вопрос2

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

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

Наиболее близким и точным аналогом диаграмм деятельности являются математически строгие дракон-схемы визуального алгоритмического языка ДРАКОН. Более отдаленным аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.

Билет2

Вопрос1

…

Вопрос2 (не знаю то или не то)

Диаграммы состояний используются для описания поведения, реализуемого в рамках варианта использования, или поведения экземпляров класса (объектов), компонента, узла или системы в целом [23–26]. Поведение моделируется через автомат (англ. state machine), описывающий возможные последовательности состояний экземпляра сущности и переходы между ними на протяжении его жизненного цикла, начиная от создания и заканчивая уничтожением.

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

Билет3

Вопрос1

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

В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами серии ГОСТ 19.ХХХ - Единая система программной документации (ЕСПД): ГОСТ 19.001-77. ЕСПД. Общие положения; ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов; ГОСТ 19.102-77. ЕСПД. Стадии разработки; ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам; ГОСТ 19.201-78. ЕСПД. Техническое задание, требования к содержанию и оформлению; ГОСТ 19.201-78. ЕСПД. Схемы алгоритмов, программ, данных и систем и т.д.

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

Процессы создания ав­томатизированных систем, в состав которых входит и ПО, рег­ламентированы стандартами серии ГОСТ 34.ХХХ - Комплекс стандартов на АС: ГОСТ 34.601-90. Информационная технология. АС. Стадии создания; ГОСТ 34.602-89. Информационная технология. Техническое задание на создание АС; ГОСТ 34.603-92. Информационная технология. Виды испытаний АС; ГОСТ 34.201-89. Информационная технология. Виды, комплектность и обозначение документов при создании АС и т.д.

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

Основным зарубежным нормативным документом, наиболее полно и подро­б­но регламентирующим ЖЦ ПО, является международныйстандарт ISO/IEC 12207. (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.)

Этапы работ в ГОСТ соответствуют процессам в ISO / IEC 12207. Сопоставление разных стандартов (ГОСТ и ISO) показывает, что они в принципе регламентируют одни и те же работы при создании ПО. Но все же в отечественных разра­ботках целесообразно использовать современные международные стан­дарты.

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

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

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

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

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы ЖЦ ПО (приобретение ПО заказчиком, поставка про­граммного продукта поставщиком заказчику, разработка (создание ПО), эксплуатация ПО пользователем, сопровождение службой сопровождения); вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией (учет версий), обеспечение качества, верификация (определение соответствия требованиям), аттестация (удостоверение правильности), совместная оценка (соответствие характеристик ПО исходным требованиям), аудит (процессы ревизии), решение проблем (устранение дефектов и ошибок)); организационные процессы (управление проектами, создание инфраструктуры проекта (выбор аппаратных и программных средств, технологии, стандартов, т.д.), определение, оценка и улучшение (корректировка) самого ЖЦ, обучение пользователя).

Вопрос2

…

Билет4

Вопрос1

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

1. планирование разработки;
2. определение требований к системе;

2.1

выработка требований;

2.2

анализ требований;

1. проектирование системы;

3.1

проектирование архитектуры системы;

3.2

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

3.2.1

общее проектирование программного обеспечения;

3.2.2

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

1. реализация и тестирование системы;

4.1

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

4.1.1

создание отдельных программных модулей;

4.1.2

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

4.2

тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

4.3

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

1. выпуск системы;
2. эксплуатация системы;
3. завершение разработки.

Вопрос2

…

Билет5

Вопрос1

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

1. планирование разработки;
2. определение требований к системе;

2.1

выработка требований;

2.2

анализ требований;

1. проектирование системы;

3.1

проектирование архитектуры системы;

3.2

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

3.2.1

общее проектирование программного обеспечения;

3.2.2

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

1. реализация и тестирование системы;

4.1

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

4.1.1

создание отдельных программных модулей;

4.1.2

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

4.2

тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

4.3

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

1. выпуск системы;
2. эксплуатация системы;
3. завершение разработки.

Билет6

Вопрос1

(ВОТ ОСОБЕННОСТИ) Отличительным свойством каскадной модели можно назвать то, что она представ­ляет собой формальный метод, разновидность разработки "сверху вниз", она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору.

Билет7

Вопрос1

Недостатки каскадной модели

 

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

• в основе модели лежит последовательная линейная структура, в результате чего каждая попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;
• она не может предотвратить возникновение итераций между фазами, которые так часто встречаются при разработке ПО, поскольку сама модель создается согласно стандартному циклу аппаратного инжиниринга;
• она не отображает основное свойство разработки ПО, направленное на разреше­ние задач. Отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы персонала или коллективов;
• она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;
• интеграция всех полученных результатов происходит внезапно в завершающей стадии работы модели. В результате такого единичного прохода через весь про­цесс, связанные с интегрированием проблемы, как правило, дают о себе знать слишком поздно. Следовательно, проявятся не обнаруженные ранее ошибки или конструктивные недостатки, повысить степень риска при небольшом задаче вре­мени на восстановление продукта;
• у клиента едва ли есть возможность ознакомиться с системой заранее, это проис­ходит лишь в самом конце жизненного цикла. Клиент не имеет возможности вос­пользоваться доступными промежуточными результатами, и отзывы пользовате­лей нельзя передать обратно разработчикам. Поскольку готовый продукт не дос­тупен вплоть до окончания процесса, пользователь принимает участие в процессе разработки только в самом начале — при сборе требований, и в конце — во время приемочных испытаний;
• пользователи не могут убедиться в качестве разработанного продукта до оконча­ния всего процесса разработки. Они не имеют возможности оценить качество, ес­ли нельзя увидеть готовый продукт разработки;
• у пользователя нет возможности постепенно привыкнуть к системе. Процесс обуче­ния происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
• проект можно выполнить, применив упорядоченную каскадную модель, и привес­ти его в соответствие с письменными требованиями, что, однако, не гарантирует его запуска в эксплуатацию;
• каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, так как он не поддается гибкому моделированию;
• для каждой фазы создаются результативные данные, которые по его завершению считаются замороженными. Это означает, что они не должны изменяться на сле­дующих этапах жизненного цикла продукта. Если элемент результативных данных какого-либо этапа изменяется (что встречается весьма часто), на проект окажет негативное влияние изменение графика, поскольку ни модель, ни план не были рассчитаны на внесение и разрешение изменения на более поздних этапах жиз­ненного цикла;
• все требования должны быть известны в начале жизненного цикла, но клиенты редко могут сформулировать все четко заданные требования на этот момент раз­работки. Модель не рассчитана на динамические изменения в требованиях на про­тяжении всего жизненного цикла, так как получаемые данные "замораживаются". Использование модели может повлечь за собой значительные затраты, если тре­бования в недостаточной мере известны или подвержены динамическим измене­ниям во время протекания жизненного цикла;
• возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;
• модель основана на документации, а значит, количество документов может быть избыточным;
• весь программный продукт разрабатывается за один раз. Нет возможности раз­бить систему на части. В результате взятых разработчиками обязательств разрабо­тать целую систему за один раз могут возникнуть проблемы с финансированием проекта. Происходит распределение больших денежных средств, а сама модель едва ли позволяет повторно распределить средства, не разрушив при этом проект в процессе его выполнения;
• отсутствует возможность учесть переделку и итерации за рамками проекта.

 

Билет8

Вопрос1

Принципиальные особенности спиральной модели;

• отказ от фиксации требований и назначение приоритетов пользовательским требованиям;

• разработка последовательности прототипов, начиная с тре­бований наивысшего приоритета;

• идентификация и анализ риска на каждой итерации;

• использование каскадной модели для реализации оконча­тельного прототипа;

• оценка результатов по завершении каждой итерации и пла­нирование следующей итерации.

Вопрос2

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

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

 

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

 

Билет9

Вопрос1

Преимущества:

· Быстрое получение результата

· Повышение конкурентоспособности

· Изменяющиеся требования — не проблема

Недостатки:

· Отсутствие регламентации стадий

Вопрос2

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

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

 

Системный подход – это подход к:

 

 

a) изучению объектов и явлений;

b) построению научных теорий и гипотез;

c) проектированию техники.

 

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

 

Билет10

Вопрос1

Преимущества:

· Быстрое получение результата

· Повышение конкурентоспособности

· Изменяющиеся требования — не проблема

Недостатки:

· Отсутствие регламентации стадий

Вопрос2

Отмечают ряд следующих преимуществ объектно - ориентированного подхода:

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

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

Билет1

Вопрос1

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

 

Вопрос2

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

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

Наиболее близким и точным аналогом диаграмм деятельности являются математически строгие дракон-схемы визуального алгоритмического языка ДРАКОН. Более отдаленным аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.

Билет2

Вопрос1

…

Вопрос2 (не знаю то или не то)

Диаграммы состояний используются для описания поведения, реализуемого в рамках варианта использования, или поведения экземпляров класса (объектов), компонента, узла или системы в целом [23–26]. Поведение моделируется через автомат (англ. state machine), описывающий возможные последовательности состояний экземпляра сущности и переходы между ними на протяжении его жизненного цикла, начиная от создания и заканчивая уничтожением.

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

Билет3

Вопрос1

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

В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами серии ГОСТ 19.ХХХ - Единая система программной документации (ЕСПД): ГОСТ 19.001-77. ЕСПД. Общие положения; ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов; ГОСТ 19.102-77. ЕСПД. Стадии разработки; ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам; ГОСТ 19.201-78. ЕСПД. Техническое задание, требования к содержанию и оформлению; ГОСТ 19.201-78. ЕСПД. Схемы алгоритмов, программ, данных и систем и т.д.

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

Процессы создания ав­томатизированных систем, в состав которых входит и ПО, рег­ламентированы стандартами серии ГОСТ 34.ХХХ - Комплекс стандартов на АС: ГОСТ 34.601-90. Информационная технология. АС. Стадии создания; ГОСТ 34.602-89. Информационная технология. Техническое задание на создание АС; ГОСТ 34.603-92. Информационная технология. Виды испытаний АС; ГОСТ 34.201-89. Информационная технология. Виды, комплектность и обозначение документов при создании АС и т.д.

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

Основным зарубежным нормативным документом, наиболее полно и подро­б­но регламентирующим ЖЦ ПО, является международныйстандарт ISO/IEC 12207. (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.)

Этапы работ в ГОСТ соответствуют процессам в ISO / IEC 12207. Сопоставление разных стандартов (ГОСТ и ISO) показывает, что они в принципе регламентируют одни и те же работы при создании ПО. Но все же в отечественных разра­ботках целесообразно использовать современные международные стан­дарты.

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

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

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

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

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы ЖЦ ПО (приобретение ПО заказчиком, поставка про­граммного продукта поставщиком заказчику, разработка (создание ПО), эксплуатация ПО пользователем, сопровождение службой сопровождения); вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией (учет версий), обеспечение качества, верификация (определение соответствия требованиям), аттестация (удостоверение правильности), совместная оценка (соответствие характеристик ПО исходным требованиям), аудит (процессы ревизии), решение проблем (устранение дефектов и ошибок)); организационные процессы (управление проектами, создание инфраструктуры проекта (выбор аппаратных и программных средств, технологии, стандартов, т.д.), определение, оценка и улучшение (корректировка) самого ЖЦ, обучение пользователя).

Вопрос2

…

Билет4

Вопрос1

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

1. планирование разработки;
2. определение требований к системе;

2.1

выработка требований;

2.2

анализ требований;

1. проектирование системы;

3.1

проектирование архитектуры системы;

3.2

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

3.2.1

общее проектирование программного обеспечения;

3.2.2

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

1. реализация и тестирование системы;

4.1

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

4.1.1

создание отдельных программных модулей;

4.1.2

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

4.2

тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

4.3

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

1. выпуск системы;
2. эксплуатация системы;
3. завершение разработки.

Вопрос2

…

Билет5

Вопрос1

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

1. планирование разработки;
2. определение требований к системе;

2.1

выработка требований;

2.2

анализ требований;

1. проектирование системы;

3.1

проектирование архитектуры системы;

3.2

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

3.2.1

общее проектирование программного обеспечения;

3.2.2

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

1. реализация и тестирование системы;

4.1

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

4.1.1

создание отдельных программных модулей;

4.1.2

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

4.2

тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

4.3

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

1. выпуск системы;
2. эксплуатация системы;
3. завершение разработки.