Жизненный цикл программного обеспечения: понятие, стандарты, процессы. Жизненный цикл программного обеспечения (ЖЦ ПО) Что входит в жизненный цикл программного обеспечения
Жизненный цикл программного обеспечения
Жизненный цикл программного обеспечения - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. (Стандарт IEEE Std 610.12)
Необходимость определения этапов жизненного цикла (ЖЦ) ПО обусловлена стремлением разработчиков к повышению качества ПО за счет оптимального управления разработкой и использования разнообразных механизмов контроля качества на каждом этапе, начиная от постановки задачи и заканчивая авторским сопровождением ПО. Наиболее общим представлением жизненного цикла ПО является модель в виде базовых этапов - процессов, к которым относятся:
Системный анализ и обоснование требований к ПО;
Предварительное (эскизное) и детальное (техническое) проектирование ПО;
Разработка программных компонент, их комплексирование и отладка ПО в целом;
Испытания, опытная эксплуатация и тиражирование ПО;
Регулярная эксплуатация ПО, поддержка эксплуатации и анализ результатов;
Сопровождение ПО, его модификация и совершенствование, создание новых версий.
Данная модель является общепринятой и соответствует как отечественным нормативным документам в области разработки программного обеспечения, так и зарубежным. С точки зрения обеспечения технологической безопасности целесообразно рассмотреть более подробно особенности представления этапов ЖЦ в зарубежных моделях, так как именно зарубежные программные средства являются наиболее вероятным носителем программных дефектов диверсионного типа.
Стандарты жизненного цикла ПО
ГОСТ 34.601-90
ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)
Графическое представление моделей ЖЦ позволяет наглядно выделить их особенности и некоторые свойства процессов.
Первоначально была создана каскадная модель ЖЦ, в которой крупные этапы начинались друг за другом с использованием результатов предыдущих работ. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.
Наиболее специфической является спиралевидная модель ЖЦ. В этой модели внимание концентрируется на итерационном процессе начальных этапов проектирования. На этих этапах последовательно создаются концепции, спецификации требований, предварительный и детальный проект. На каждом витке уточняется содержание работ и концентрируется облик создаваемого ПО, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации оцениваются:
Риск превышения сроков и стоимости проекта;
Необходимость выполнения ещё одной итерации;
Степень полноты и точности понимания требований к системе;
Целесообразность прекращения проекта.
Стандартизация ЖЦ ПО проводится по трем направлениям. Первое направление организуется и стимулируется Международной организацией по стандартизации (ISO - International Standard Organization) и Международной комиссией по электротехнике (IEC - International Electro-technical Commission). На этом уровне осуществляется стандартизация наиболее общих технологических процессов, имеющих значение для международной кооперации. Второе направление активно развивается в США Институтом инженеров электротехники и радиоэлектроники (IEEE - Institute of Electrotechnical and Electronics Engineers) совместно с Американским национальным институтом стандартизации (American Na-tional Standards Institute-ANSI). Стандарты ISO/IEC и ANSI/IEEE в основном имеют рекомендательный характер. Третье направление стимулируется Министерством обороны США (Department of Defense-DOD). Стандарты DOD имеют обязательный характер для фирм, работающих по заказу Министерства обороны США.
Для проектирования ПО сложной системы, особенно системы реального времени, целесообразно использовать общесистемную модель ЖЦ, основанную на объединении всех известных работ в рамках рассмотренных базовых процессов. Эта модель предназначена для использования при планировании, составлении рабочих графиков, управлении различными программными проектами.
Совокупность этапов данной модели ЖЦ целесообразно делить на две части, существенно различающихся особенностями процессов, технико-экономическими характеристиками и влияющими на них факторами.
В первой части ЖЦ производится системный анализ, проектирование, разработка, тестирование и испытания ПО. Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах существенно зависят от объекта и среды разработки. Изучение подобных зависимостей для различных классов ПО позволяет прогнозировать состав и основные характеристики графиков работ для новых версий ПО.
Вторая часть ЖЦ, отражающая поддержку эксплуатации и сопровождения ПО, относительно слабо связана с характеристиками объекта и среды разработки. Номенклатура работ на этих этапах более стабильна, а их трудоемкость и длительность могут существенно изменяться, и зависят от массовости применения ПО. Для любой модели ЖЦ обеспечение высокого качества программных комплексов возможно лишь при использовании регламентированного технологического процесса на каждом из этих этапов. Такой процесс поддерживается средствами автоматизации разработки, которые целесообразно выбирать из имеющихся или создавать с учетом объекта разработки и адекватного ему перечня работ.
Стандарты жизненного цикла ПО
- ГОСТ 34.601-90
- ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)
Методологии разработки ПО
- Rational Unified Process (RUP).
- Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
- Экстремальное программирование (Extreme Programming , XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
Стандарт ГОСТ 34.601-90
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
- Формирование требований к АС
- Обследование объекта и обоснование необходимости создания АС
- Формирование требований пользователя к АС
- Оформление отчета о выполнении работ и заявки на разработку АС
- Разработка концепции АС
- Изучение объекта
- Проведение необходимых научно-исследовательских работ
- Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
- Оформление отчета о проделанной работе
- Техническое задание
- Разработка и утверждение технического задания на создание АС
- Эскизный проект
- Разработка предварительных проектных решений по системе и ее частям
- Технический проект
- Разработка проектных решений по системе и ее частям
- Разработка документации на АС и ее части
- Разработка и оформление документации на поставку комплектующих изделий
- Разработка заданий на проектирование в смежных частях проекта
- Рабочая документация
- Разработка рабочей документации на АС и ее части
- Разработка и адаптация программ
- Ввод в действие
- Подготовка объекта автоматизации
- Подготовка персонала
- Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
- Строительно-монтажные работы
- Пусконаладочные работы
- Проведение предварительных испытаний
- Проведение опытной эксплуатации
- Проведение приемочных испытаний
- Сопровождение АС.
- Выполнение работ в соответствии с гарантийными обязательствами
- Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели.
Стандарт ISO/IEC 12207/ и его применение
Стандарт ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы , действия и задачи, которые должны быть выполнены во время создания ПО.
Каждый процесс разделен на набор действий, каждое действие - на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения. Связи по входным данным при этом сохраняются.
Процессы жизненного цикла ПО
- Основные:
- Приобретение (действия и задачи заказчика, приобретающего ПО)
- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
- Эксплуатация (действия и задачи оператора - организации, эксплуатирующей систему)
- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение - внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
- Вспомогательные
- Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
- Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
- Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
- Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
- Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
- Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
- Аудит (определение соответствия требованиям, планам и условиям договора)
- Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
- Организационные
- Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
- Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
- Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
- Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
- Инициирование приобретения
- Подготовка заявочных предложений
- Подготовка и корректировка договора
- Надзор за деятельностью поставщика
- Приемка и завершение работ
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
- Формирование требований к системе
- Формирование списка программных продуктов
- Установление условий и соглашений
- Описание технических ограничений (среда функционирования системы и т. д.)
Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями
Модель жизненного цикла ПО - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ПО включает в себя:
- Стадии;
- Результаты выполнения работ на каждой стадии;
- Ключевые события - точки завершения работ и принятия решений.
Стадия - часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
Модели жизненного цикла ПО
Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует
К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:
- Задачная модель;
- каскадная модель (или системная) (70-85 г.г.);
- спиральная модель (настоящее время).
Задачная модель
При разработке системы "снизу-вверх" от отдельных задач ко всей системе (задачная модель) единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. Однако в отдельных случаях такая технология может оказаться целесообразной:
- Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);
- Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).
Общий вывод: достаточно большую эффективную информационной системы таким способом создать невозможно.
Каскадная модель
Каскадная модель жизненного цикла была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе(рис. 1). Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
- на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Этапы проекта в соответствии с каскадной моделью:
- Формирование требований;
- Проектирование;
- Реализация;
- Тестирование;
- Внедрение;
- Эксплуатация и сопровождение.
Рис. 1. Каскадная схема разработки
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания систем никогда полностью не укладывался в такую жесткую схему. В процессе создания постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения принимал следующий вид (рис. 2):
Рис. 2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационным системам "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания программного обеспечения, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.
Спиральная модель
Для преодоления перечисленных проблем была предложена спиральная модель жизненного цикла (рис. 3), которая была разработана в середине 1980-х годов Барри Боэмом. Она основывается на начальных этапах жизненного цикла: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов.
Прототип - действующий компонент ПО, реализующий отдельные функции и внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 3. Спиральная модель ЖЦ ИС
Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
- небольшую команду программистов (от 2 до 10 человек);
- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
- повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:
- фаза определения требований и анализа;
- фаза проектирования;
- фаза реализации;
- фаза внедрения.
На каждой итерации оцениваются:
- риск превышения сроков и стоимости проекта;
- необходимость выполнения еще одной итерации;
- степень полноты и точности понимания требований к системе;
- целесообразность прекращения проекта.
Преимущества итерационного подхода:
- Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
- При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта).
- Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие.
- Итерационный подход упрощает повторное использование компонентов (реализует компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
- Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
- Итерационный подход дает возможность совершенствовать процесс разработки - анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.
ЖЦ ПО – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Процессы ЖЦ ПО:
Основные,
Вспомогательные,
Организационные.
Основные:
1. Приобретение – действия и задачи заказчика, приобретающего ПО;
2. Поставка – действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой;
3. Разработка – действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов;
4. Эксплуатация – действия и задачи оператора организации, эксплуатирующей систему;
5. Сопровождение – внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
Вспомогательные:
1. Документирование – формализованное описание информации, созданной в течение ЖЦ ПО;
2. Управление конфигурацией– применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями;
3. Обеспечение качества– обеспечение гарантий того, что ПО и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам;
4. Верификация – определение того, что программные продукты полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями;
5. Аттестация – определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению;
6. Совместная оценка– оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами;
7. Аудит – определение соответствия требованиям, планам и условиям договора;
8. Разрешение проблем– анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов.
Организационные:
1. Управление – действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами;
2. Создание инфраструктуры– выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО;
3. Усовершенствование – оценка, измерение, контроль и усовершенствование процессов ЖЦ;
4. Обучение – первоначальное обучение и последующее постоянное повышение квалификации персонала.
В 2002 г. был опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение – поддержка создания компьютеризированных систем.
Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:
1. Договорные процессы:
Приобретение (внутренние решения или решения внешнего поставщика);
Поставка (внутренние решения или решения внешнего поставщика);
2. Процессы предприятия:
Управление окружающей средой предприятия;
Инвестиционное управление;
Управление ЖЦ ИС;
Управление ресурсами;
Управление качеством;
3. Проектные процессы:
Планирование проекта;
Оценка проекта;
Контроль проекта;
Управление рисками;
Управление конфигурацией;
Управление информационными потоками;
Принятие решений.
Определение требований;
Анализ требований;
Разработка архитектуры;
Внедрение;
Интеграция;
Верификация;
Переход;
Аттестация;
Эксплуатация;
Сопровождение;
Утилизация.
Определение и установка взаимосвязей исходя из задач и целей.
Создание основных процессов ЖЦ ПО по ИС (ISO/IEC 15288)
| Процесс (исполнитель процесса) | Действия | Вход | Результат |
| Приобретение (заказчик) | - Инициирование - Подготовка заявочных предложений - Подготовка договора - Контроль деятельности поставщика - Приемка ИС | - Решение о начале работ по внедрению ИС - Результаты обследования действий заказчика - Результаты анализа рынка ИС/ тендера - План поставки/ разработки - Комплексный тест ИС | - Технико-экономическое обоснование внедрения ИС - Техническое задание на ИС - Договор на поставку/ разработку - Акты приемки этапов работы - Акт приемно-сдаточных испытаний |
| Поставка (разработчик ИС) | - Инициирование - Ответ на заявочные предложения - Подготовка договора - Планирование исполнения - Поставка ИС | - Техническое задание на ИС - Решение руководства об участии в разработке - Результаты тендера - Техническое задание на ИС - План управления проектом - Разработанная ИС и документация | - Решение об участии в разработке - Коммерческие предложения/ конкурсная заявка - Договор на поставку/ разработку - План управления проектом - Реализация/ корректировка - Акт приемно-сдаточных испытаний |
| Разработка (разработчик ИС) | - Подготовка - Анализ требований к ИС - Проектирование архитектуры ИС - Разработка требований к ПО - Проектирование архитектуры ПО - Детальное проектирование ПО - Кодирование и тестирование ПО - Интеграция ПО и квалифицированное тестирование ПО - Интеграция ИС и квалифицированное тестирование ИС | - Техническое задание на ИС - Техническое задание на ИС, модель ЖЦ - Подсистемы ИС - Спецификации требования к компонентам ПО - Архитектура ПО - Материалы детального проектирования ПО - План интеграции ПО, тесты - Архитектура ИС, ПО, документация на ИС, тесты | - Используемая модель ЖЦ, стандарты разработки - План работ - Состав подсистем, компоненты оборудования - Спецификации требования к компонентам ПО - Состав компонентов ПО, интерфейсы с БД, план интеграции ПО - Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам - Тексты модулей ПО, акты автономного тестирования - Оценка соответствия комплекса ПО требованиям ТЗ - Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ |
Стадии создания систем (ISO/IEC 15288)
СРС: Создать техническое задание для проекта «Очередь» на сайте www.mastertz.ru
Модели ЖЦ ПО:
1. каскадная,
2. спиральная,
3. итерационная.
Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта.
Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
|
|
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Уильямса Эдварда Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Прототип – действующий компонент ПО, реализующий отдельные функции и внешние интерфейсы.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
Рис. 21. Спиральная модель ЖЦ ПО
На каждой итерации оцениваются:
1. Риск превышения сроков и стоимости проекта;
2. Необходимость выполнения еще одной итерации;
3. Степень полноты и точности понимания требований к системе;
4. Целесообразность прекращения проекта.
Один из примеров реализации спиральной модели - RAD.
Основные принципы RAD:
1. Инструментарий должен быть нацелен на минимизацию времени разработки;
2. Создание прототипа для уточнения требований заказчика;
3. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;
4. Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию;
5. Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей;
6. Управление проектом должно минимизировать длительность цикла разработки.
Итерационная модель: естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей.
Рис. 22. Итерационная модель ЖЦ ПО
Аннотация.
Введение.
1. Жизненный цикл ПО
Введение.
Шаги процесса программирования по Райли
Введение.
1.1.1. Постановка задачи.
1.1.2. Проектирование решения.
1.1.3. Кодирование алгоритма.
1.1.4. Сопровождение программы.
1.1.5. Программная документация.
Вывод к п. 1.1
1.2. Определение ЖЦПО по Леману.
Введение.
1.2.1 Определение системы.
1.2.2. Реализация.
1.2.3. Обслуживание.
Вывод к п. 1.2.
1.3. Фазы и работы ЖЦПО по Боэму
1.3.1. Каскадная модель.
1.3.2. Экономическое обоснование каскадной модели.
1.3.3. Усовершенствование каскадной модели.
1.3.4. Определение фаз жизненного цикла.
1.3.5. Основные работы над проектом.
Литература.
Введение
Промышленное применение компьютеров и растущий спрос на программы поставили актуальные задачи существенного повышения производительности разработки ПО , разработки индустриальных методов планирования и проектирования программ, переноса организационно-технических, технико-экономических и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения компьютеров. Комплексный подход к процессам разработки, эксплуатации и сопровождения ПО выдвинул ряд насущных проблем, решение которых исключит «узкие места» в проектировании программ, уменьшит сроки завершения работ, улучшит выбор и адаптацию существующих программ, а может быть и определит судьбу систем со встроенными ЭВМ.
В практике разработок больших программных проектов зачастую отсутствует единый подход к оцениванию затрат труда, сроков проведения работ и материальных затрат, что сдерживает повышение производительности разработки ПО, а в конечном счете – эффективное управление жизненным циклом ПО. Поскольку программа любого типа становится изделием (кроме, может быть, учебных, макетных программ), подход к ее изготовлению во многом должен быть аналогичен подходу к производству промышленной продукции, и вопросы проектирования программ становятся чрезвычайно важными. Эта идея лежит в основе книги Б.У. Боэма «Инженерное проектирование программного обеспечения», которую мы использовали при написании данной курсовой работы. В этой книге под проектированием ПО понимается процесс создания проекта программного изделия.
1 Жизненный цикл ПО
ВВЕДЕНИЕ
ЖЦПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения (ЖЦПО), шагов процесса программирования, каскадная и спиральная модели. Но все они содержат общие основополагающие компоненты: постановка задачи, проектирование решения, реализация, обслуживание.
Наиболее известной и полной, пожалуй, является структура ЖЦПО по Боэму, включающая восемь фаз. Она и будет представлена в дальнейшем наиболее подробно.
Одним из возможных вариантов может послужить описание верхнего уровня по Леману, включающее три основные фазы и представляющее описание ЖЦПО в самом общем случае.
И, для разнообразия, – приведем шаги процесса программирования, представленные Д.Райли в книге «Использование языка Модула-2». Это представление, по-моему, является весьма простым и привычным, с него и начнём.
1.1 Шаги процесса программирования по Райли
Введение
Процесс программирования включает четыре шага (рис. 1):
постановка задачи, т.е. получение адекватного представления о том, какую задачу должна выполнить программа;
проектирование решения уже поставленной задачи (в общем, такое решение является менее формальным, чем окончательная программа);
кодирование программы, т. е. перевод спроектированного решения в программу, которая может быть выполнена на машине;
сопровождение программы, т.е. непрекращающийся процесс устранения в программе неполадок и добавления новых возможностей.
Рис. 1.Четыре шага программирования.
Программирование начинается с того момента, когда пользователь , т.е. тот, кто нуждается в программе для решения задачи, излагает проблему системному аналитику. Пользователь и системный аналитик совместно определяют постановку задачи. Последняя затем передается алгоритмисту , который отвечает за проектирование решения. Решение (или алгоритм) представляет последовательность операций, выполнение которых приводит к решению задачи. Поскольку алгоритм часто не приспособлен к выполнению на машине, его следует перевести в машинную программу. Эта операция выполняется кодировщиком. За последующие изменения в программе несет ответственность сопровождающий программист. И системный аналитик, и алгоритмист, и кодировщик, и сопровождающий программист – все они являются программистами.
В случае большого программного проекта число пользователей, системных аналитиков и алгоритмистов может оказаться значительным. Кроме того, может возникнуть необходимость вернуться к предшествующим шагам в силу непредвиденных обстоятельств. Все это служит дополнительным аргументом в пользу тщательного проектирования программного обеспечения: результаты каждого шага должны быть полными, точными и понятными.
1.1.1 Постановка задачи
Одним из наиболее важных шагов программирования является постановка задачи. Она выполняет функции контракта между пользователем и программистом (программистами). Как и юридически плохо составленный контракт, плохая постановка задачи бесполезна. При хорошей постановке задачи как пользователь, так и программист ясно и недвусмысленно представляют задачу, которую необходимо выполнить, т.е. в этом случае учитываются интересы как пользователя, так и программиста. Пользователь может планировать использование еще несозданного программного обеспечения, опираясь на знание того, что оно может. Хорошая постановка задачи служит основой для формирования ее решения.
Постановка задачи (спецификация программы ); по существу, означает точное, полное и понятное описание того, что происходит при выполнении конкретной программы. Пользователь обычно смотрит на компьютер, как на черный ящик: для него неважно, как работает компьютер, а важно, что может компьютер из того, что интересует пользователя. При этом основное внимание фокусируется на взаимодействии человека с машиной.
Характеристики Хорошей Постановки Задачи:
Точность , т.е. исключение любой неоднозначности. Не должно возникать вопросов относительно того, каким будет вывод программы при каждом конкретном вводе.
Полнота , т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода.
Ясность , т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи – это единственный контракт между ними.
Часто требование точности, полноты и ясности находятся в противоречии. Так, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения. Например, некоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что студент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, студент вообще может не уловить основной смысл вопроса из-за большого количества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований.
Стандартная форма постановки задачи.
Рассмотрим следующую постановку задачи: «Ввести три числа и вывести числа в порядке».
Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли выражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены.
Очевидно, что подобная постановка не отвечает на множество вопросов. Если же учесть ответы на все вопросы, то постановка задачи станет многословной и трудной для восприятия. Поэтому Д. Райли предлагает для постановки задачи пользоваться стандартной формой, которая обеспечивает максимальную точность, полноту, ясность и включает:
наименование задачи (схематическое определение);
общее описание (краткое изложение задачи);
ошибки (явно перечислены необычные варианты ввода, чтобы показать пользователям и программистам те действия, которые предпримет машина в подобных ситуациях);
пример (хороший пример может передать сущность задачи, а также проиллюстрировать различные случаи).
Пример. Постановка задачи в стандартной форме.
НАЗВАНИЕ
Сортировка трех целых чисел.
ОПИСАНИЕ
Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему.
Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».
Выводятся три введенных целых числа, причем все три выводятся на одной строке. Смежные числа разделяются пробелом. Числа выводятся от меньшего к большему, слева направо.
1) Если введено менее трех чисел, программа ждет дополнительного ввода.
2) Строки ввода, кроме первых трех, игнорируются.
3) Если какая-либо из первых трех строк содержит более одного целого числа, то программа завершает работу и выдает сообщение.
Жизненный цикл ПО. Стадии и этапы
Жизненный цикл ИС - ряд событий, происходящих с системой в процессе ее создания и использования.
Стадия - часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
Жизненный цикл традиционно моделируется в виде некоторого числа последовательных этапов (или стадий, фаз). В настоящее время не выработано общепринятого разбиения жизненного цикла программной системы на этапы. Иногда этап выделяется как отдельный пункт, иногда - входит в качестве составной части в более крупный этап. Могут варьироваться действия, производимые на том или ином этапе. Нет единообразия и в названиях этих этапов.
Традиционно выделяются следующие основные этапы ЖЦ ПО:
Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.
Жизненный цикл ПО. Каскадная модель
каскадная модель (70-80г.г.) ≈ предполагает переход на следующий этап после полного окончания работ по предыдущему этапу,
Основным достижением каскадной модели является завершенность стадий. Это дает возможность планирования затрат и сроков. Кроме того, формируется проектная документация, обладающая полнотой и согласованностью.
Каскадная модель применима к небольшим программным проектам, с четко поставленными и не изменяемыми требованиями. Реальный процесс может выявить неудачи на любой стадии, что приводит к откату на одну из предыдущих стадий. Модель такого производства ПО – каскадно-возвратная
Жизненный цикл ПО. Поэтапная модель с промежуточным контролем
поэтапная модель с промежуточным контролем (80-85г.г.) ≈ итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; однако, время жизни каждого из этапов растягивается на весь период разработки,
Основные этапы решения задач
Целью программирования является описание процессов обработки данных (в дальнейшем - просто процессов).
Данные (data) - это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация (information) - это смысл, который придается данным при их представлении.
Обработка данных (data processing) - это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на носителях данных.
Совокупность носителей данных, используемых при какой-либо обработке данных называется информационной средой (data medium).
Набор данных, содержащихся в какой-либо момент в информационной среде - состояние информационной среды.
Процесс можно определить как последовательность сменяющих друг друга состояний некоторой информационной среды.
Описать процесс - значит определить последовательность состояний информационной среды. Чтобы по заданному описанию требуемый процесс порождался автоматически на каком-либо компьютере, необходимо, чтобы это описание было формализованным.
Критерии качества ПО
Коммерческое изделие (продукт, услуга) должны удовлетворять требованиям потребителя.
Качество – объективная характеристика товара (продукции, услуги), показывающая степень удовлетворенности потребителя
Характеристики качества:
Работоспособность – система работает и реализует требуемые функции.
Надежность – система работает без отказов и сбоев.
Восстанавливаемость .
Эффективность – система реализует свои функции наилучшим образом.
Экономическая эффективность – минимальная стоимость конечного продукта при максимальной прибыли.
Характеристики качества:
Учет человеческого фактора - удобство эксплуатации, быстрота обучения работе с ПП, удобство сопровождения, внесения изменений.
Переносимость (мобильность) – переносимость кода на другую платформу или систему.
Функциональная полнота – возможно наиболее полная реализация внешних функций.
Точность вычисления
Свойства алгоритма.
Результативность означает возможность получения результата после выполнения конечного количества операций.
Определенность состоит в совпадении получаемых результатов независимо от пользователя и применяемых технических средств.
Массовость заключается в возможности применения алгоритма к целому классу однотипных задач, различающихся конкретными значениями исходных данных.
Дискретность - возможность расчленения процесса вычислений, предписанных алгоритмом, на отдельные этапы, возможность выделения участков программы с определенной структурой.
Способы описания алгоритмов
Существуют следующие способы описания (представления) алгоритмов:
1. словесное описание;
2. описание алгоритма с помощью математических формул;
3. графическое описание алгоритма в виде блок-схемы;
4. описание алгоритма с помощью псевдокода;
5. комбинированный способ изображения алгоритма с использованием словесного, графического и др. способов.
6. с помощью сетей Петри.
Словесное описание алгоритма представляет собой описание структуры алгоритма на естественном языке. Например, к приборам бытовой техники, как правило, прилагается инструкция по эксплуатации, т.е. словесное описание алгоритма, в соответствии с которым данный прибор должен использоваться.
Графическое описание алгоритма в виде блок-схемы – это описание структуры алгоритма с помощью геометрических фигур с линиями связи.
Блок схема алгоритма – это графическое представление метода решения задачи, в котором используются специальные символы для отображения операций.
Символы, из которых состоит блок-схема алгоритма, определяет ГОСТ 19.701-90. Этот ГОСТ соответствует международному стандарту оформления алгоритмов, поэтому блок-схемы алгоритмов, оформленные согласно ГОСТ 19.701-90, в разных странах понимаются однозначно.
Псевдокод – описание структуры алгоритма на естественном, но частично формализованном языке. В псевдокоде используются некоторые формальные конструкции и общепринятая математическая символика. Строгих синтаксических правил для записи псевдокода не предусмотрено.
Рассмотрим простейший пример. Пусть необходимо описать алгоритм вывода на экран монитора наибольшего значения из двух чисел.
Рисунок 1 - Пример описания алгоритма в виде блок-схемы
Описание этого же алгоритма на псевдокоде:
2. Ввод чисел: Z, X
3. Если Z > X то Вывод Z
4. Иначе вывод Х
Каждый из перечисленных способов изображения алгоритмов имеет и достоинства и недостатки. Например, словесный способ отличается многословностью и отсутствием наглядности, но дает возможность лучше описать отдельные операции. Графический способ более наглядный, но часто возникает необходимость описать некоторые операции в словесной форме. Поэтому при разработке сложных алгоритмов лучше использовать комбинированный способ.
Виды алгоритмов
линейные;
ветвящиеся;
циклические.
· Линейный алгоритм - набор команд (указаний), выполняемых последовательно друг за другом.
· Разветвляющийся алгоритм - алгоритм, содержащий хотя бы одно условие, в результате проверки которого ЭВМ обеспечивает переход на один из двух возможных шагов.
· Циклический алгоритм - алгоритм, предусматривающий многократное повторение одного и того же действия (одних и тех же операций) Над новыми исходными данными. К циклическим алгоритмам сводится большинство методов вычислений, перебора вариантов. Цикл программы - последовательность команд (серия, тело цикла), которая может выполняться многократно (для новых исходных данных) до удовлетворения некоторому условию.
Си.Типы данных.
Тип данных – это описание диапазона значений, которые может принимать переменная, указанного типа. Каждый тип данных характеризуется:
1. количеством занимаемых байт(размером)
2. диапазоном значений которые может принимать переменная данного типа.
Все типы данных можно разделить на следующие виды:
1. простые (скалярные) и сложные (векторные) типы;
2. базовые (системные) и пользовательские(которые определил пользователь).
В языке СИ систему базовых типов образуют четыре типа данных:
1. символьный,
2. целочисленный,
3. вещественный одинарной точности,
4. вещественный двойной точности.
Структура программы на Си.
1. Операторы языка C++
Операторы управляют процессом выполнения программы. Набор операторов языка С++ содержит все управляющие конструкции структурного программирования.
Составной оператор ограничивается фигурными скобками. Все другие операторы заканчиваются точкой с запятой.
Пустой оператор – ;
Пустой оператор – это оператор, состоящий только из точки с запятой. Он может появиться в любом месте программы, где по синтаксису требуется оператор. Выполнение пустого оператора не меняет состояния программы.
Составной оператор – {...}
Действие составного оператора состоит в последовательном выполнении содержащихся в нем операторов, за исключением тех случаев, когда какой-либо оператор явно передает управление в другое место программы.
Оператор обработки исключений
try { <операторы> }
catch (<объявление исключения>) { <операторы> }
catch (<объявление исключения>) { <операторы> }
...
catch (<объявление исключения>) { <операторы> }
Условный оператор
if (<выражение>) <оператор 1>
Оператор-переключатель
switch (<выражение>)
{ case <константное выражение 1>: <операторы 1>
case <константное выражение 2>: <операторы 2>
...
case <константное выражение N>: <операторы N>
}
Оператор-переключатель предназначен для выбора одного из нескольких альтернативных путей выполнения программы. Вычисление оператора-переключателя начинается с вычисления выражения, после чего управление передается оператору, помеченному константным выражением, равным вычисленному значению выражения. Выход из оператора-переключателя осуществляется оператором break. Если значение выражения не равно ни одному константному выражению, то управление передается оператору, помеченному ключевым словом default, если он есть.
Оператор цикла с предусловием
while (<выражение>) <оператор>
Оператор цикла с постусловием
do <оператор> while <выражение>;
В языке C++ этот оператор отличается от классической реализации цикла с постусловием тем, что при истинности выражения происходит продолжение работы цикла, а не выход из цикла.
Оператор пошагового цикла
for ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Тело оператора for выполняется до тех пор, пока условное выражение не станет ложным (равным 0). Начальное выражение и выражение приращения обычно используются для инициализации и модификации параметров цикла и других значений. Начальное выражение вычисляется один раз до первой проверки условного выражения, а выражение приращения вычисляется после каждого выполнения оператора. Любое из трех выражений заголовка цикла, и даже все три могут быть опущены (не забывайте только оставлять точки с запятой). Если опущено условное выражение, то оно считается истинным, и цикл становится бесконечным.
Оператор пошагового цикла в языке С++ является гибкой и удобной конструкцией, поэтому оператор цикла с предусловием while используется в языке С++ крайне редко, т.к. в большинстве случаев удобнее пользоваться оператором for.
Оператор разрыва
break;
Оператор разрыва прерывает выполнение операторов while, do, for и switch. Он может содержаться только в теле этих операторов. Управление передается оператору программы, следующему за прерванным. Если оператор разрыва записан внутри вложенных операторов while, do, for, switch, то он завершает только непосредственно охватывающий его оператор.
Оператор продолжения
continue;
Оператор продолжения передает управление на следующую итерацию в операторах цикла while, do, for. Он может содержаться только в теле этих операторов. В операторах do и while следующая итерация начинается с вычисления условного выражения. В операторе for следующая итерация начинается с вычисления выражения приращения, а затем происходит вычисление условного выражения.
Оператор возврата
return [<выражение>];
Оператора возврата заканчивает выполнение функции, в которой он содержится, и возвращает управление в вызывающую функцию. Управление передается в точку вызывающей функции
If (логическое выражение)
оператор;
If (логическое выражение)
оператор_1;
оператор_2;
<логическое выражение> ? <выражение_1> : <выражение_2>;
Если значение логического выражения истинно, то вычисляется выражение_1, в противном случае вычисляется выражение_2.
switch (выражение целого типа)
case значение_1:
последовательность_операторов_1;
case значение_2:
последовательность_операторов_2;
case значение_n:
последовательность_операторов_n;
default:
последовательность_операторов_n+1;
Ветку default можно не описывать. Она выполняется, если ни одно из вышестоящих выражений не удовлетворено.
Оператор цикла.
В Турбо Си имеются следующие конструкции, позволяющие программировать циклы: while, do while и for . Их структуру можно описать следующим образом:
Цикл с проверкой условия наверху:
Оператор выбора
Если действия, которые необходимо выполнить в программе, зависят от значения некоторой переменной, можно использовать оператор выбора. При этом в C++ в качестве переменных в операторе выбора можно использовать только численные. В общем виде запись оператора выбора выглядит так:
switch(переменная)
{
case значение1:
действия1
break;
case значение2:
действия2
break;
...
default:
действия по умолчанию
}
Ключевое слово break необходимо добавлять в конец каждой ветви. Оно останавливает выполнение операции выбора. Если его не написать, после выполнения действий из одной ветви выбора продолжится выполнение действий из следующих ветвей. Однако иногда такое свойство выбора бывает полезным, например если необходимо выполнить одни и теже действия для различных значений переменной.
switch(переменная)
{
case значение1:
case значение2:
действия1
break;
case значение3:
действия2
break;
...
}
Пример использования выбора:
int n, x;
...
switch(n)
{
case 0:
break; //если n равна 0, то не выполняем никаких действий
case 1:
case 2:
case 3:
x = 3 * n; //если n равна 1, 2 или 3, то выполняем некоторые действия
break;
case 4:
x = n; //если n равна 4, то выполняем другие действия
break;
default:
x = 0; //при всех других значениях n выполняем действия по умолчанию
}
Си.Цикл: цикл с параметром
Общая форма записи
for (инициализация параметра; проверка условия окончания; коррекция параметра) {
блок операций;
for - параметрический цикл (цикл с фиксированным числом повторений). Для организации такого цикла необходимо осуществить три операции:
§ инициализация параметра - присваивание параметру цикла начального значения;
§ проверка условия окончания - сравнение величины параметра с некоторым граничным значением;
§ коррекция параметра - изменение значения параметра при каждом прохождении тела цикла.
Эти три операции записываются в скобках и разделяются точкой с запятой (;). Как правило, параметром цикла является целочисленная переменная.
Инициализация параметра осуществляется только один раз - когда цикл for начинает выполняться. Проверка условия окончания осуществляется перед каждым возможным выполнением тела цикла. Когда выражение становится ложным (равным нулю), цикл завершается. Коррекция параметра осуществляется в конце каждого выполнения тела цикла. Параметр может как увеличиваться, так и уменьшаться.
Пример
#include
int main() {
for(num = 1; num < 5; num++)
printf("num = %d\n",num);
Си. Цикл с предусловием
Общая форма записи
while(выражение) {
блок операций;
}
Если выражение истинно (не равно нулю), то выполняется блок операций, заключенный в фигурные скобки, затем выражение проверяется снова. Последовательность действий, состоящая из проверки и выполнения блока операций, повторяется до тех пор, пока выражение не станет ложным (равным нулю). При этом происходит выход из цикла, и производится выполнение операции, стоящей после оператора цикла.
Пример
int k=5;
int i=1;
int sum=0;
while(i <=k) {
При построении цикла while, в него необходимо включить конструкции, изменяющие величину проверяемого выражения так, чтобы в конце концов оно стало ложным (равным нулю). Иначе выполнение цикла будет осуществляться бесконечно (бесконечный цикл), например
блок операций;
}
while - цикл с предусловием, поэтому вполне возможно, что тело цикла не будет выполнено ни разу если в момент первой проверки проверяемое условие окажется ложным.
Си. Цикл с постусловием
Цикл с постусловием do...while
Общая форма записи
блок операций;
} while(выражение);
Цикл с постусловием
Цикл do...while - это цикл с постусловием, где истинность выражения проверяется после выполнения всех операций, включенных в блок, ограниченный фигурными скобками.Тело цикла выполняется до тех пор, пока выражение не станет ложным, то есть тело цикла с постусловием выполнится хотя бы один раз.
Использовать цикл do...while лучше использовать в тех случаях, когда должна быть выполнена хотя бы одна итерация, либо когда инициализация объектов, участвующих в проверке условия, происходит внутри тела цикла.
Пример . Ввести число от 0 до 10
#include
#include
int main() {
system("chcp 1251");
printf("Введите число от 0 до 10: ");
scanf("%d", &num);
} while((num < 0) || (num > 10));
printf("Вы ввели число %d", num);
getchar(); getchar();
Определение функций
Рассмотрим определение функции на примере функции sum.
В языках C и C++, функции не должны быть определены до момента их использования, но они должны быть ранее объявлены. Но даже после всего этого, в конце концов, эта функция должна быть определена. После этого прототип функции и ее определение связываются, и эта функция может быть использована.
Если функция ранее была объявлена, она должна быть определена с тем же возвращаемым значением и типами данных, в противном случае, будет создана новая, перегруженная функция. Заметьте, что имена параметров функции не должны быть одинаковыми.