Жизненный цикл и этапы разработки по. Жизненный цикл программного обеспечения (ЖЦ ПО) Основные этапы жизненного цикла программного средства

Аннотация.

Введение.

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) Если введено менее трех чисел, программа ждет дополнительного ввода.

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

Жизненный цикл что это такое в формальном понимании?

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

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

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

Начальные требования

  • постановка задачи;
  • анализ взаимных требований будущего ПО к системе;
  • проектирование;
  • программирование;
  • кодирование и компиляция;
  • тестирование;
  • отладка;
  • внедрение и сопровождение программного продукта.

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

Стандарты процессов жизненного цикла программного обеспечения

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

  • ГОСТ 34.601-90;
  • ISO/IEC 12207:2008;
  • Oracle CDM.

Для второго международного стандарта имеется российский аналог. Это ГОСТ Р ИСО/МЭК 12207-2010, отвечающий за системную и программную инженерию. Но жизненный цикл программного обеспечения, описываемый в обоих правилах, является идентичным по сути. Объясняется это достаточно просто.

Виды ПО и апдейты

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

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

Пример на основе программы FL Studio

Изначально виртуальная студия-секвенсор FL Studio имела название Fruity Loops. Жизненный цикл ПО в его первичной модификации истек, но приложение несколько трансформировалось и приобрело нынешний вид.

Если говорить об этапах жизненного цикла, сначала на стадии постановки задачи задавалось несколько обязательных условий:

  • создание барабанного модуля по типу ритм-машин вроде Yamaha RX, но с применением one-shot-сэмплов или секвенций в формате WAV, записанных в студиях вживую;
  • интеграция в операционные системы Windows;
  • возможность экспорта проекта в форматах WAV, MP3 и OGG;
  • совместимость проектов с дополнительным приложением Fruity Tracks.

На стадии разработки были применены средства языков программирования «Си». Но платформа выглядела достаточно примитивно и не давала конечному пользователю необходимого качества звучания.

В связи с этим, на стадии тестирования и отладки разработчикам пришлось пойти по пути немецкой корпорации Steinberg и применить в требованиях к основному звуковому драйверу поддержку режима Full Duplex. Качество саунда стало выше и позволило изменять темп, высоту тона и накладывать дополнительные FX-эффекты в режиме реального времени.

Завершением жизненного цикла этого ПО принято считать выход первой официальной версии FL Studio, которая, в отличие от своих прародителей, обладала уже интерфейсом полноценного секвенсора с возможностью редактирования параметров на виртуальном 64-канальном микшерном пульте с неограниченным добавлением аудио-дорожек и MIDI-треков.

Этим не ограничилось. На стадии управления проектом была введена поддержка подключения плагинов формата VST (сначала второй, а потом и третьей версии), в свое время разработанного компанией Steinberg. Грубо говоря, любой виртуальный синтезатор, поддерживающий VST-host мог подключаться к программе.

Неудивительно, что вскоре любой композитор мог использовать аналоги «железных» моделей, например, полные комплекты звуков некогда популярного Korg M1. Дальше - больше. Применение модулей вроде Addictive Drums или универсального плагина Kontakt позволило воспроизводить живые звуки реальных инструментов, записанных со всеми оттенками артикуляции в профессиональных студиях.

При этом разработчики постарались добиться и максимального качества, создав поддержку для драйверов ASIO4ALL, которые оказались на голову выше режима Full Duplex. Соответственно, повысился и битрейт. На сегодняшний день качество экспортируемого звукового файла может составлять 320 кбит/с при частоте дискретизации 192 кГц. А это профессиональный звук.

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

Перспективы развития

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

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

Даже в случае с ОС Windows такие тенденции можно заметить невооруженным взглядом. Вряд ли сегодня найдется хоть один юзер, использующий системы вроде модификаций 3.1, 95, 98 или Millennium. Их жизненный цикл закончился после выхода версии XP. Но вот серверные версии на основе технологий NT все еще актуальны. Даже Windows 2000 на сегодняшний день является не только весьма актуальной, но и по некоторым параметрам установки или безопасности даже превосходящей самые новые разработки. То же самое касается системы NT 4.0, а также специализированной модификации Windows Server 2012.

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

Но если говорить о том, что развитие ПО любого типа (управляющего или прикладного) не стоит на месте, можно только Ведь сегодня дело касается не только компьютерных систем, а и мобильных устройств, в которых применяемые технологии зачастую опережают компьютерный сектор. Появление процессорных чипов на основе восьми ядер - чем не самый лучший пример? А ведь еще далеко не каждый ноутбук может похвастаться наличием такого «железа».

Некоторые дополнительные вопросы

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

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

Но в компьютерных технологиях сегодня отдается предпочтение развитию автоматизированных систем управления (АСУ), которые применяются на производстве. Даже операционные системы, в сравнении со специализированными программами, проигрывают.

Те же среды на основе Visual Basic остаются намного более популярными, нежели Windows-системы. А о прикладном ПО под UNIX-системы речь не идет вообще. Что говорить, если практически все коммуникационные сети тех же Соединенных Штатов работают исключительно на них. Кстати, системы вроде Linux и Android тоже изначально создавались именно на этой платформе. Поэтому, скорее всего, у UNIX перспектив намного больше, чем у остальных продуктов вместе взятых.

Вместо итога

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

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

К тому же, иногда жизненные циклы могут зависеть от актуальности средств разработки. Если, допустим, какой-то язык программирования устаревает, никто же не будет писать программы на его основе, и уж тем более - внедрять их в автоматизированные системы управления на производстве. Тут уже на первый план выходят даже не программисты, а маркетологи, которые должны своевременно реагировать на изменения компьютерного рынка. И таких специалистов в мире найдется не так уж и много. Высококвалифицированные кадры, способные держать руку на пульсе рынка, становятся наиболее востребованными. И именно они зачастую являются так называемыми «серыми кардиналами», от которых зависит успех или проигрыш определенного программного продукта в сфере IT.

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

Конечно, такие технологии в мире являются запрещенными, однако многие из нас даже не догадываются о том, что они все равно могут использоваться и воздействовать на подсознание определенным способом. Чего только стоит «зомбирование» новостными каналами или интернет-сайтами, не говоря уже о применении более мощных средств, вроде воздействия инфразвуком (такое было применено в одной оперной постановке), вследствие чего человек может испытывать страх или неадекватные эмоции.

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

Но не нам судить об этом. Возможно, в ближайшее время будут разработаны средства, определяющие такие угрозы. Пока это только теория, но, как считают некоторые аналитики и эксперты, до практического применения осталось совсем немного. Если уже создают копии нейронных сетей человеческого мозга, то что говорить?

Аннотация.

Введение.

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) Если какая-либо из первых трех строк содержит более одного целого числа, то программа завершает работу и выдает сообщение.


Рис. 5.2.

Такими аспектами являются:

  1. договорный аспект, в котором заказчик и поставщик вступают в договорные отношения и реализуют процессы приобретения и поставки;
  2. аспект управления, который включает действия управления лицами, участвующими в ЖЦ ПО (поставщик, заказчик, разработчик, оператор и др.);
  3. аспект эксплуатации, включающий действия оператора по предоставлению услуг пользователям системы;
  4. инженерный аспект, который содержит действия разработчика или службы сопровождения по решению технических задач, связанных с разработкой или модификацией программных продуктов;
  5. аспект поддержки, связанный с реализацией вспомогательных процессов, с помощью которых службы поддержки предоставляют необходимые услуги всем остальным участникам работ. В этом аспекте можно выделить аспект управления качеством ПО, включающий процессы обеспечения качества, верификацию, аттестацию, совместную оценку и аудит.

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

5.6. Модели и стадии ЖЦ ПО

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

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

Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ , выполнение которых необходимо и достаточно для создания ПО , соответствующего заданным требованиям.

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

  1. формирование требований к ПО;
  2. проектирование (разработка системного проекта);
  3. реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
  4. тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
  5. ввод в действие (внедрение);
  6. эксплуатация и сопровождение;
  7. снятие с эксплуатации.

Некоторые специалисты вводят дополнительно начальную стадию – анализ осуществимости системы. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПО .

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

Стадия формирования требований к ПО включает следующие этапы.

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

    • модели "AS-IS" ("как есть"), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом работает данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
    • модели "TO-BE" ("как должно быть"), отражающей представление о новых технологиях работы организации.

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

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

Стадия проектирования включает следующие этапы.

  1. Разработка системного проекта ПО. На этом этапе дается ответ на вопрос "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки, план отладки ПО и контроль качества.

    Основу системного проекта составляют модели проектируемой системы, которые строятся на модели "TO-BE". Результатом разработки системного проекта должна быть одобренная и подтвержденная спецификация требований к ПО: функциональные, технические и интерфейсные спецификации, для которых подтверждена их полнота, проверяемость и осуществимость.

  2. Разработка детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПО, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла требованиям?"

Результатом детального проектирования является разработка верифицированной спецификации ПО , включающей:

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

Завершением стадии детального проектирования является сквозной

Жизненный цикл ПО. Стадии и этапы

Жизненный цикл ИС - ряд событий, происходящих с системой в процессе ее создания и использования.

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

Жизненный цикл традиционно моделируется в виде некоторого числа последовательных этапов (или стадий, фаз). В настоящее время не выработано общепринятого разбиения жизненного цикла программной системы на этапы. Иногда этап выделяется как отдельный пункт, иногда - входит в качестве составной части в более крупный этап. Могут варьироваться действия, производимые на том или ином этапе. Нет единообразия и в названиях этих этапов.

Традиционно выделяются следующие основные этапы ЖЦ ПО:

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

Проектирование,

Кодирование (программирование),

Тестирование и отладка,

Эксплуатация и сопровождение.

Жизненный цикл ПО. Каскадная модель

каскадная модель (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++, функции не должны быть определены до момента их использования, но они должны быть ранее объявлены. Но даже после всего этого, в конце концов, эта функция должна быть определена. После этого прототип функции и ее определение связываются, и эта функция может быть использована.

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