Жизненный цикл программного обеспечения

FSSM предоставляет оценки трудозатрат для деятельности по разработке, не охватывает оценки трудозатрат для деятельности по развертыванию и обслуживанию, хотя измерения могут предоставить достаточную информацию о размере программного обеспечения, которая может быть полезна для понимания огромного объема работы по развертыванию и обслуживанию. Усилия по управлению проектом также не покрываются.Можно применить FSSM после завершения работ по разработке, это делается в основном для целей анализа затрат / производительности или для будущих ссылок на проекты программного обеспечения.2.4 Основные этапы жизненного цикла программного обеспеченияВ некоторой степени все жизненные циклы программного обеспечения содержат одни и те же основные этапы разработки программного обеспечения, хотя детали и порядок этих этапов могут сильно отличаться[17].В этом разделе дается краткий обзор этих фаз, которые позже сформируют основные строительные блоки различных моделей жизненного цикла. Помните, что, согласно Def. 1.18, этап содержит набор логически связанных действий, которые могут быть связаны, а могут и не быть связаны во времени.Одним из первых шагов в большинстве жизненных циклов программного обеспечения является анализ (требований): Определение 1.30 (Анализ требований). В процессе изучения пользователю необходимо прийти к определению требований к системе, оборудованию или программному обеспечению. (SEVOCAB) В то время как каскадные модели жизненного цикла пытаются выполнить полный анализ требований в начале разработки, итеративные и инкрементные модели жизненного цикла, в той или иной степени, начинают с отдельных частей анализа требований, но затемвыполнить некоторые или все другие действия по разработке, прежде чем продолжить анализ требований.На основе результатов анализа требований необходимо разработать решение: Определение 1 (Дизайн). Процесс определения архитектуры программного обеспечения, компонентов, модулей, интерфейсов и данных для системы программного обеспечения для удовлетворения заданных требований.(SEVOCAB) При необходимости можно выделить различные уровни и типы дизайна, такие как предварительный проект, детальный проект, функциональный дизайн, архитектурный дизайн, дизайн интерфейса и т. д.После проектирования реализуются результаты проектирования:Определение 2 (реализация). Процесс преобразования дизайна в аппаратные компоненты, программные компоненты или и то, и другое. (SEVOCAB)Чтобы убедиться, что внедренная система работает должным образом, ее обычно тестируют: Определение 3 (Тест). Деятельность, при которой система или компонент выполняется в определенных условиях, результаты наблюдаются или записываются, и выполняется оценка некоторого аспекта системы или компонента. (SEVOCAB)Обратите внимание, что согласно этому определению термин «тест» требует, чтобы система была запущена. Иногда используется более широкое определение тестирования, которое также включает другие формы анализа системы, в частности обзоры и статический анализ.После внедрения и тестирования программной системы ее развертывают:Определение 4 (Развертывание). Этап проекта, на котором система вводится в эксплуатацию и решаются проблемы с переключением (SEVOCAB)Существует множество вариантов наименования и точного содержания этого этапа разработки, например, развертывание или переход.Наконец, система вводится в эксплуатацию для фактического использования:Определение 5 (Операции). Постоянное выполнение действий, которые производят один и тот же продукт или предоставляют повторяющиеся услуги. (SEVOCAB)Это определение несколько шире, чем необходимо в данном контексте, поскольку операции программных систем будут предоставлять (повторяющиеся) услуги, но не какие-либо физические продукты.Две тесно связанные задачи, которые в разной степени необходимо выполнять в рамках всего процесса разработки, - это проверка и валидация (иногда сокращенно «V & V»):Определение 6 (Проверка). Подтверждение посредством предоставления объективных свидетельств того, что указанные требования были выполнены (ISO / IEC 12207: 2008, SEVOCAB) Определение 7 (Подтверждение). В контексте жизненного цикла - набор действий, обеспечивающих и обретающих уверенность в том, что система способна выполнять предполагаемое использование, цели и задачи. (ИСО / МЭК 12207: 2008, SEVOCAB).Основное различие между обеими задачами состоит в том, что верификация строится на существующей спецификации результата и проверяет («проверяет»), что результат был создан в соответствии с этой спецификацией. Например, результаты фазы тестирования могут быть проверены путем проверки того, что все заявленные требования к программному обеспечению тестируются. При помощиэтого же теста затем можно убедиться, что требования к программному обеспечению были реализованы правильно.Валидация, с другой стороны, начинается с неформальных потребностей заинтересованных сторон в качестве справочного материала и проверяет, соответствует ли результат этим потребностям. В результате проверка исходных требований, например использование отзывов, это важный шаг, так как эти начальныетребования по определению не могут быть проверены, но сформируют основу для всех последующих этапов проверки. В регулируемых средах, где окончательной системе потребуется некоторая форма юридического подтверждения, чтобы ее можно было использовать, термин «проверка» часто используется специально для всех задач, необходимых для подготовки к получению такого юридического подтверждения.Чтобы лучше различать верификацию и валидацию, часто говорят, что валидация касается «правильных действий», а верификация - «правильных действий». ITIL использует разные формулировки и рассматривает их под другим углом, но обсуждает те же концепции в различии между «пригодностью для использования» (полезность), которая проверяется валидацией, и «пригодностью для использования» (гарантия), которая проверяется проверка.С верификацией тесно связана концепция прослеживаемости. Чтобы убедиться, что определенный результат соответствует определенной части спецификации, необходимо четко определить, какой результат, как ожидается, будет реализовывать эту часть спецификации, и какая часть спецификации содержит требования к этому результату.Определение 8 (Прослеживаемость). Степень, в которой могут быть установлены отношения между двумя или более продуктами процесса разработки, особенно между продуктами, имеющими отношения предшественник-преемник или главный-подчиненный. (SEVOCAB).Прослеживаемость обычно в основном используется в контексте прослеживаемости требований, когда результаты связаны с соответствующими требованиями.ЗаключениеВ заключении отметить, что в условиях современных организаций, как частных, так и государственных, технология каскадной модели для разработки ПО активно распространяется. Благодаря ей происходит ускорение передачи информации, что безусловно будет способствовать развитию организации в целом с увеличением его доходов.Технологии управления данными об изделиях постоянно модернизируются. Их применение способствует ускорению производства технических изделий. Поэтому производство различного ПО необходимо для повышения качества выпускаемой продукции и, как следствие, для повышения дохода специализированных в этой области предприятий.В данной работе достигнута основная цель – описан жизненный цикл программного обеспечения.В данном реферате были решены следующие задачи:приведеныосновные понятия, связанные с моделями жизненного цикла;описаныпроцессы, протекающие при использовании моделей жизненного цикла программного обеспечения.Также в процессе написания данного доклада применялись современные и классические источники литературы, а также материалы, которые выложены в глобальной сети Интернет.Список использованной литературыФуфаев Д.Э., Фуфаев Э.В. Разработка и эксплуатация автоматизированных информационных систем. Учебник. — 3-е изд., стер. — М.: Академия, 2014. — 304 с.Волков Г.Г., Глинский О.Ю. Компьютерные информационные технологии. БГЭУ: Бобруйск, 2010. – 86 с.Маликов Р.Ф. Основы разработки компьютерных моделей сложных систем. Учебное пособие. — Уфа: Изд-во БГПУ, 2012. — 257 с.Цыцаркин Ю.М., Скоз Е.Ю. Процессы в САПР (Адаптация стандарта ИСО/ MЭK 12207). УДК 681.3 Учеб. пособие - Рязан. гос. радиотехн. акад. Рязань, 2003. 48 с.Прокопенко Д.В., Шибеко В.Н. Управление разработкой программного обеспечения. Учебно-методическое пособие. — Гомель: Гомельский государственный технический университет им. П.О. Сухого (ГГТУ), 2020. — 75 с.Скитер Н.Н., Кузнецов С.Ю. Управление жизненным циклом информационных систем. Учебное пособие. — Волгоград: Волгоградский государственный технический университет, 2020. — 64 с.Dale Nell, Weems Chip, Richards Tim. C++ Plus Data Structures (Conv.). 6th Edition. — Jones & Bartlett Learning, 2018. — 1345 p.Родионова Т.Е. Технологии программирования. С++. Учебное пособие. Примеры. — Ульяновск: УлГТУ, 2018. — 115 с.Маркина Т.А. Управление проектами в информационных технологиях. чебное пособие. – СПб: Университет ИТМО, 2016. – 88 с.Федорова Г.Н. Информационные системы. Учебник для студентов учреждений сред. проф. образования. — 3-е изд., стер. — М. : Академия, 2013. — 208 с.Schach S.R. Object-Oriented Software Engineering. McGraw-Hill Science/Engineering/Math, 2007. — 578 p.Баженова И.В. Практика по получению первичных профессиональных умений и навыков. Учебное пособие. — Красноярск: Сибирский федеральный университет, 2018. — 124 с.Зубкова Т.М. Технология разработки программного обеспечения. Учебное пособие. — Оренбург: Оренбургский государственный университет, 2017. — 468 с. Волк В.К. Введение в программную инженерию. Курган: Курганский государственный университет, 2018. — 156 с.Семахин А.М. Методы верификации и оценки качества программного обеспечения. Курган: Курганский государственный университет, 2018. — 150 с. (Процессы жизненного цикла программного обеспечения.)Singh Jasveer. Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication. Wiley, 2017. — 448 p. (Mapping of the Usage of the FSSM in the SoftwareLife Cycle, and Source of Input Information for the FSSM)Kneuper Ralf. Software Processes and Life Cycle Models. Springer, 2018. — 345 p. (Major PhasesWithin Software Life Cycles)