
- •Вопрос1
- •Вопрос2
- •Вопрос1
- •Вопрос2 (не знаю то или не то)
- •Вопрос1
- •Вопрос2
- •Вопрос1
- •Вопрос2
- •Вопрос1
- •Вопрос2 (Так то не то, но к теме вопроса относится, можно масло накидать)
- •Вопрос1
- •Маленьким кажется ответ тебе если, то припиши ещё и приемущества (снизу написаны)
- •Вопрос2 (Так то не то, но к теме вопроса относится, можно масло накидать[2])
- •Вопрос1 Преимущества каскадной модели
- •Недостатки каскадной модели
- •Вопрос2 (не знаю, то или не то)
- •Вопрос1
- •Вопрос2
- •Вопрос1
- •Вопрос2
- •Билет10
- •Вопрос1
- •Вопрос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 базируется на трех группах процессов : основные процессы ЖЦ ПО (приобретение ПО заказчиком, поставка программного продукта поставщиком заказчику, разработка (создание ПО), эксплуатация ПО пользователем, сопровождение службой сопровождения); вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией (учет версий), обеспечение качества, верификация (определение соответствия требованиям), аттестация (удостоверение правильности), совместная оценка (соответствие характеристик ПО исходным требованиям), аудит (процессы ревизии), решение проблем (устранение дефектов и ошибок)); организационные процессы (управление проектами, создание инфраструктуры проекта (выбор аппаратных и программных средств, технологии, стандартов, т.д.), определение, оценка и улучшение (корректировка) самого ЖЦ, обучение пользователя).