В рамках специфических моделей жизненного цикла , которые предписывают правила организации разработки ПО в рамках данной отрасли или организации, определяются более конкретные процессы разработки . Отличаются они от стандартов, прежде всего, большей детальностью и четким описанием связей между отдельными видами деятельности , определением потоков данных (документов и артефактов) в ходе жизненного цикла . Таких моделей довольно много, ведь фактически каждый раз, когда некоторая организация определяет собственный процесс разработки , в качестве основы этого процесса разрабатывается некоторая модель жизненного цикла ПО . В рамках данной лекции мы рассмотрим лишь несколько моделей. К сожалению, очень тяжело выбрать критерии, по которым можно было бы дать хоть сколько-нибудь полезную классификацию известных моделей жизненного цикла .
Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла , которая, как считается, была впервые четко сформулирована в работе и впоследствии запечатлена в стандартах министерства обороны США в 70-80-х годах XX века. Эта модель предполагает последовательное выполнение различных видов деятельности , начиная с выработки требований и заканчивая сопровождением, с четким определением границ между этапами, на которых набор документов, созданный на предыдущей стадии, передается в качестве входных данных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла . Предлагаемая в статье последовательность шагов разработки показана на рис. 2.2 . "Классическая" каскадная модель предполагает только движение вперед по этой схеме: все необходимое для проведения очередной деятельности должно быть подготовлено в ходе предшествующих работ .
Однако, если внимательно прочитать статью , оказывается, что она не предписывает следование именно этому порядку работ , а, скорее, представляет модель итеративного процесса (см. рис.2.3) - в ее последовательном виде эта модель закрепилась, по -видимому, в представлении чиновников из министерств и управленцев компаний, работающих с этими министерствами по контрактам. При реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могут быть изменения требований, смена подрядчиков, изменения политик разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.).
Работать в соответствии с этой моделью можно, только если удается предвидеть заранее возможные перипетии хода проекта и тщательно собирать и интегрировать информацию на первых этапах, с тем чтобы впоследствии можно было пользоваться их результатами без оглядки на возможные изменения.
Среди разработчиков и исследователей, имевших дело с разработкой сложного ПО , практически с самого зарождения индустрии производства программ (см., например, ) большую популярность имели модели эволюционных или итеративных процессов, поскольку они обладают большей гибкостью и способностью работать в меняющемся окружении.
Итеративные или инкрементальные модели (известно несколько таких моделей) предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части.
На первой итерации разрабатывается кусок системы, не зависящий от других. При этом большая часть или даже полный цикл работ проходится на нем, затем оцениваются результаты и на следующей итерации либо первый кусок переделывается, либо разрабатывается следующий, который может зависеть от первого, либо как-то совмещается доработка первого куска с добавлением новых функций. В результате на каждой итерации можно анализировать промежуточные результаты работ и реакцию на них всех заинтересованных лиц, включая пользователей, и вносить корректирующие изменения на следующих итерациях. Каждая итерация может содержать полный набор видов деятельности - от анализа требований до ввода в эксплуатацию очередной части ПО .
Каскадная модель с возможностью возвращения на предшествующий шаг при необходимости пересмотреть его результаты, становится итеративной .
Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат.
Вместе с гибкостью и возможностью быстро реагировать на изменения, итеративные модели привносят дополнительные сложности в управление проектом и отслеживание его хода. При использовании итеративного подхода значительно сложнее становится адекватно оценить текущее состояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки и ресурсы, необходимые для обеспечения определенного качества результата.
Развитием идеи итераций является
представление окончательных документов, метрик процесса, критериев начала и завершения задач и перехода к следующему шагу процесса; подбор методов тестирования для выбранного класса ПС для проверки правильности выполнения задач тестирования; разработка специальных шаблонов документов для документирования процесса тестирования относительно каждого шага процесса тестирования.Т.е. делается предположение, что каждая работа будет выполнена настолько тщательно, что после ее завершения и перехода к следующему этапу возвращения к предыдущему не потребуется.
Разработчик проверяет промежуточный результат разными известными методами верификации и фиксирует его в качестве готового эталона для следующего процесса.
Согласно данной модели ЖЦ работы и задачи процесса разработки обычно выполняются последовательно, как это представлено в схеме. Однако вспомогательные и организационные процессы (контроль требований, управление качеством и др.) обычно выполняются параллельно с процессом разработки. В данной модели возвращение к начальному процессу предусматривается после сопровождения и исправления ошибок.
Особенность такой модели состоит в фиксации последовательных процессов разработки программного продукта. В ее основу положена модель фабрики, где продукт проходит стадии от замысла до производства, затем передается заказчику как готовое изделие, изменение которого не предусмотрено, хотя возможна замена на другое подобное изделие в случае рекламации или некоторых ее деталей, вышедших из строя.
Недостатки этой модели:
- процесс создания ПС не всегда укладывается в такую жесткую форму и последовательность действий;
- не учитываются изменившиеся потребности пользователей, изменения во внешней среде, которые вызовут изменения требований к системе в ходе ее разработки;
- большой разрыв между временем внесения ошибки (например, на этапе проектирования) и временем ее обнаружения (при сопровождении), что приводит к большой переделке ПС.
При применении каскадной модели могут иметь место следующие факторы риска:
- требования к ПС недостаточно четко сформулированы, либо не учитывают перспективы развития ОС, сред и т.п.;
- большая система, не допускающая компонентной декомпозиции, может вызвать проблемы с размещением ее в памяти или на платформах, не предусмотренных в требованиях;
- внесение быстрых изменений в технологию и в требования может ухудшить процесс разработки отдельных частей системы или системы в целом;
- ограничения на ресурсы (человеческие, программные, технические и др.) в ходе разработки могут сузить отдельные возможности реализации системы;
полученный продукт может оказаться плохим для применения по причине недопонимания разработчиками требований или функций системы или недостаточно проведенного тестирования. Преимущества реализации системы с помощью каскадной модели следующие:
- все задачи подсистем и системы реализуются одновременно (т.е. ни одна задача не забыта), а это способствует установлению стабильных связей и отношений между ними;
- полностью разработанную систему с документацией на нее легче сопровождать, тестировать, фиксировать ошибки и вносить изменения не беспорядочно, а целенаправленно, начиная с требований (например, добавить или заменять некоторые функции) и повторить процесс.
Каскадную модель можно рассматривать как модель ЖЦ, пригодную для создания первой версии ПО с целью проверки реализованных в ней функций. При сопровождении и эксплуатации могут быть обнаружены разного рода ошибки, исправление которых потребует повторного выполнения всех процессов, начиная с уточнения требований.
2.2.2. Инкрементная модель ЖЦ
Первая создаваемая промежуточная версия системы (выпуск 1) реализует часть требований, в последующую версию (выпуск 2) добавляют дополнительные требования и так до тех пор, пока не будут окончательно выполнены все требования и решены задачи разработки системы. Для каждой промежуточной версии на этапах ЖЦ выполняются необходимые процессы, работы и задачи, в том числе, анализ требований и создание новой архитектуры, которые могут быть выполнены одновременно.
Процессы разработки технического проекта ПС, его программирование и тестирование, сборка и квалификационные испытания ПС выполняются при создании каждой последующей версии.
В соответствии с данной моделью ЖЦ, процессы которой практически такие же, что и в каскадной модели, ориентир делается на разработку некоторой законченной промежуточной версии, а задачи процесса разработки выполняются последовательно или частично параллельно для ряда отдельных промежуточных структур версии.
Работы и задачи процесса разработки следующей версии системы с дополнительными требованиями или функциями могут выполняться неоднократно в той же последовательности для всех промежуточных версий системы. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки версии путем проверки частично реализованных требований в каждой промежуточной версии и так до получения законченного варианта системы. Вспомогательные и организационные процессы ЖЦ обычно выполняются параллельно с процессом разработки версии системы и к концу разработки будут собраны данные, на основании которых может быть установлен уровень завершенности и качества изготовленной системы.
При применении данной модели необходимо учитывать следующие факторы риска:
- требования составлены с учетом возможности их изменения при реализации продукта;
- все возможности системы требуется реализовать с начала;
- быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;
- ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к затягиванию сроков сдачи системы в эксплуатацию.
Данную модель ЖЦ целесообразно использовать, в случаях когда:
- желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта;
- система декомпозируется на отдельные составные части, которые можно реализовывать как некоторые самостоятельные промежуточные или готовые продукты;
- возможно увеличение финансирования на разработку отдельных частей системы.
Жизненный цикл программного обеспечения
Одним из базовых понятий методологии проектирования ПО является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Модели жизненного цикла ПО
Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи стадий и этапов, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПО и специфики условий, в которых последняя создается и функционирует. Основные модели ЖЦ следующие.
1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.
Для этой модели характерна автоматизация отдельных несвязанных задач, не требующая информационной интеграции и совместимости, программного, технического и организационного сопряжения.
Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.
Недостаток : неприменимость к большим и сложным проектам из-за изменчивости требований к системе в течение длительного проектирования.
2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;
Модель предусматривает обобщение полученных проектных решений отдельных задач в общесистемные решения. При этом возникает потребность в пересмотре ранее сформулированных требований.
Достоинство: возможность оперативно вносить коррективы в проект.
Недостаток: при большом числе итераций растет время проектирования, возникают расхождения в проектных решениях и документации, запутывается функциональная и системная архитектура созданной ПО. Необходимость в перепроектировании старой или создании новой системы может возникнуть сразу после этапа внедрения или эксплуатации.
3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.
При проектировании архитектуры системы сначала определяется состав функциональных подсистем и решаются общесистемные вопросы (организация интегрированной базы данных, технология сбора, передачи и накопления информации). Затем формулируются отдельные задачи и разрабатывается технология их решения.
При программировании сначала разрабатываются головные программные модули, а затем - модули, исполняющие отдельные функции. Сначала обеспечивается взаимодействие модулей между собой и с базой данных, а затем - реализация алгоритмов.
Достоинства:
1. сокращение число итераций и, следовательно, число ошибок и несоответствий, которые необходимо исправлять;
2. сокращение сроков проектирования;
3. упрощение создания проектной документации.
Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).
Спиральная модель лежит в основе технологии быстрой разработки приложений или RAD-технологии (rapid application development), которая предполагает активное участие конечных пользователей будущей системы в процессе ее создания. Основные стадии информационного инжиниринга следующие:
· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.
· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.
· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;
· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.
Здравствуйте, уважаемые хабровчане! Думаю будет кому-то интересно вспомнить какие модели разработки, внедрения и использования программного обеспечения существовали ранее, какие модели в основном используются сейчас, зачем и что это собственно такое. В этом и будет заключаться моя небольшая тема.
Собственно, что же такое жизненный цикл программного обеспечения
- ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования. Говоря другими словами, это время от начального момента создания какого либо программного продукта, до конца его разработки и внедрения. Жизненный цикл программного обеспечения можно представить в виде моделей.
Модель жизненного цикла программного обеспечения
- структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Эти модели можно разделить на 3 основных группы:
- Инженерный подход
- С учетом специфики задачи
- Современные технологии быстрой разработки
Модель кодирования и устранения ошибок
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.Данная модель имеет следующий алгоритм:
- Постановка задачи
- Выполнение
- Проверка результата
- При необходимости переход к первому пункту
Каскадная модель жизненного цикла программного обеспечения (водопад)
Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.Преимущества:
- Последовательное выполнение этапов проекта в строгом фиксированном порядке
- Позволяет оценивать качество продукта на каждом этапе
- Отсутствие обратных связей между этапами
- Не соответствует реальным условиям разработки программного продукта
Каскадная модель с промежуточным контролем (водоворот)
Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку . Относится к первой группе моделей.V модель (разработка через тестирование)
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.
Модель на основе разработки прототипа
Данная модель основывается на разработки прототипов и прототипирования продукта.Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:
- Прояснить не ясные требования (прототип UI)
- Выбрать одно из ряда концептуальных решений (реализация сцинариев)
- Проанализировать осуществимость проекта
- Горизонтальные и вертикальные
- Одноразовые и эволюционные
- бумажные и раскадровки
Вертикальные прототипы - проверка архитектурных решений.
Одноразовые прототипы - для быстрой разработки.
Эволюционные прототипы - первое приближение эволюционной системы.
Модель принадлежит второй группе.
Спиральная модель жизненного цикла программного обеспечения
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Преимущества:
- Быстрое получение результата
- Повышение конкурентоспособности
- Изменяющиеся требования - не проблема
- Отсутствие регламентации стадий
Большое спасибо за внимание!
Аннотация.
Введение.
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) Если введено менее трех чисел, программа ждет дополнительного ввода.